От мануфактур к динамическим ЦОД

Облачные вычисления (cloud computing) уже не рассматриваются как нечто эфемерное – на реальных примерах сегодня можно убедиться в том, как из «заоблачного» представления они приобретают совершенно конкретные формы и превращаются в одно из основных направлений развития ИТ. Сопутствующий созданию облачных ЦОД процесс переноса различных операций с данными в облака можно сравнить с промышленной революцией двухвековой давности, когда в реальном секторе экономики совершился переход от кустарного производства к индустриальному.

В числе тех, кто первым вступил на путь новой промышленной революции, разумеется, IBM – на счету корпорации несколько подобных ЦОД на территории и за пределами США. Один из самых крупных и наверняка наиболее известных облачных ЦОД, ориентированных на обслуживание научных учреждений, строится при участии IBM и финансировании правительства Китая в научном парке Уси неподалеку от Шанхая. Государство этой страны, в отличие от России, сосредоточено на ИТ и придает новостройке общенациональное значение. О подлинных масштабах создаваемых облачных ЦОД свидетельствует, например, стоимость коммерческого центра в Северной Каролине с бюджетом в 360 млн долл. Академический ЦОД меньшего масштаба сооружается в Японии, его стоимость не превышает 50 млн долл. ЦОД подобного класса обычно сооружают в непосредственной близости от крупных узлов Internet, а есть примеры развертывания мощных ЦОД в университетах – с совместной инициативой по финансированию одного такого центра выступили HP, Intel и Yahoo.

ГетЕрогенность современных ЦОД

Характерной чертой современных облачных ЦОД является гетерогенность – они комплектуются практически всеми существующими на сегодняшний день типами компьютеров, от серверов-лезвий до мэйнфреймов.

В основном ЦОД собирают из двух противоположных по архитектуре, но взаимодополняющих друг друга вычислительных систем (рис. 1). На одном фланге стандартные стойки, набитые лезвиями, это могут быть высокопроизводительные кластеры или серверы, работающие в режиме «одно приложение – один сервер».

На другом фланге мэйнфреймы и мощные Unix-серверы, обеспечивающие надежность уровня «пять девяток», поддерживающие работу транзакционных систем и баз данных. Разумеется, между этими полюсами есть промежуточные варианты, в том числе различные специализированные устройства. Главнейшая проблема, возникающая при создании крупных ЦОД, заключается в том, что это не просто гора компьютеров, собранная под одной крышей, как это можно наблюдать в обычных центрах, которые предоставляют свои услуги по хостингу, – облачный ЦОД должен функционировать как единый управляемый технологический объект, как завод или фабрика. Перед нами полная аналогия того, что уже было в истории несколько столетий назад – индустриализация началась с объединения в одной мастерской (мануфактуре) ремесленников различных специальностей, а чтобы перейти к заводам, потребовались годы и создание принципиально новых технологий, нечто подобное неизбежно произойдет и в ИТ.

Что отличает ЦОД эпохи облака от вычислительного комплекса, который мы раньше называли ВЦ? Прежде всего, облачный ЦОД должен уметь динамически реагировать на изменения во внешней и внутренней среде, что пока реализуется с трудом – нынешнее оборудование еще не обладает соответствующими свойствами и, при видимом разнообразии, статично. На протяжении предшествующих шести десятилетий все информационные системы иначе как статичные не мыслились, что вообще-то странно, ведь в отличие от подавляющего большинства других технических систем именно информационные могут трансформироваться в процессе их эксплуатации. Вызревшая необходимость в переходе к динамической системной организации вызывается тремя причинами: потребность адаптации к изменяющимся внешним и внутренним условиям, насыщение избыточным оборудованием (overprovisioning) и структурная сложность, затрудняющая управление.

Виртуализация не панацея

Сейчас для избавления от эффекта силосной башни невозможно придумать что-то иное, чем виртуализация, которая во всех своих ипостасях становится основой современных ЦОД. Виртуализация позволяет представить в абстрактном логическом виде реальные поддерживающие физические ресурсы, что увеличивает оперативность и гибкость, снижает расходы. Виртуализация соответствует динамической природе облачных ЦОД, обеспечивая им такие качества, как управляемость, распределенность и, когда это нужно, изолированность ресурсов. Однако, когда говорят о виртуализации, по традиции вспоминают о том, что дело это не новое, что известна она еще со времен мэйнфреймов, но при этом обычно забывают – виртуализация только изменяет внешнее представление технологии, а сам предмет виртуализации остается неизменным. Виртуализация не панацея, и, абстрагируя ресурсы, она не изменяет собственных качеств виртуализуемого объекта – мэйнфрейм остается мэйнфреймом, RISC-сервер – RISC-сервером со всеми их достоинствами и недостатками. Эти компьютеры родом из другой исторической эпохи, они не задумывались для работы в динамической среде ЦОД, а если какой-то ресурс не обладает достаточной динамичностью, то виртуализация может компенсировать этот недостаток, но не исправить его.

Использование универсальных серверов в условиях ЦОД обходится слишком дорого, и среди причин высоких издержек на первом месте стоит ускоренное старение оборудования – обычным для серверов считается амортизационный период в три года. Для сравнения, в авиации срок эксплуатации летательных аппаратов исчисляется десятилетиями. Несмотря на виртуализацию, повышающую коэффициент полезного действия, загруженность серверов, работающих в условиях ЦОД, не превышает 25-30 %, поэтому, чтобы обеспечить работу в условиях пиковых нагрузок, приходится держать избыточный запас оборудования. Не меньше на удорожание ЦОД влияет перенос сложившейся практики обеспечения высокой готовности (HA, High Availability) и резервирования на случай аварийных ситуаций (DR, Disaster Recovery). Грубо говоря, HA требует удвоения комплекта оборудования, DR добавляет еще один, в итоге продуктивной работой занята одна треть всех серверов.

Для уменьшения стоимости ЦОД и придания им большей динамичности можно отказаться от использования гетерогенной среды, состоящей из универсальных серверов, и перейти к гомогенной на основе лезвий с виртуализацией 2.0, предполагающей виртуализацию всех ресурсов ЦОД. Основные преимущества лезвий: повышение плотности размещения оборудования на 35-45%; уменьшение числа источников питания; уменьшение на 70% количества кабелей; упрощение управления; отсутствие жесткой связи поддерживающей инфраструктуры с серверами – при появлении новых моделей ими можно заменить старые. Для обеспечения HA и DR не требуется удваивать или утраивать объем оборудования – достаточно иметь нужное количество резервных лезвий, минимум N+1. Достоинства лезвий настолько очевидны, что все аналитики предрекают им блестящее будущее, даже в нынешних условиях кризиса. И все же, несмотря на предсказания аналитиков о грядущем росте производства серверов-лезвий, следует признать, что их роль на системном уровне еще не осмыслена должным образом. Чаще всего из них собирают массивы, в которых каждое лезвие работает независимо, либо, реже, их используют в качестве компонентов для высокопроизводительных кластеров, то есть для устройств с весьма простой системной организацией.

Недавняя поучительная история

Практика показывает, что из автономных серверов можно собирать и сложные архитектуры. В 1997 году компания Tandem выпустила сервер NonStop Himalaya S-Series на процессорах MIPS R4400, в котором традиционная для того времени шинная архитектура или более современная с коммутатором была заменена сетевой на базе собственной сети ServerNet. Вместо шин Dynabus и FOX, объединявших процессоры в кольцо, появилось сетевое межсоединение «каждого с каждым» (peer-to-peer). Среди отзывов на новинку можно было встретить и такой: «Технология ServerNet, использованная в Tandem S70000, является революционной, она позволяет обеспечить системам с открытой архитектурой гибкость и масштабируемость, соответствующие драматическому росту потребностей, связанных с расширением услуг, предоставляемых Web-технологиями». Это было сказано 12 лет назад!

Сеть ServerNet относится к категории сетей SAN (System Area Network), ее не следует путать с сетью SAN (Storage Area Network). В ServerNet реализована виртуальная архитектура интерфейса VIA (Virtual Interface Architecture), разработанная совместно Intel, Microsoft, Compaq и Tandem, но реализованная только Tandem в отказоустойчивых компьютерах NonStop. Широкого распространения она не получила, поэтому в целом ServerNet нельзя признать удачным коммерческим начинанием, но тем не менее эта сеть стала прототипом InfiniBand. ServerNet обеспечивает объединение «каждого узла с каждым», но при том полностью децентрализована. На логическом уровне можно представить, что взаимодействие между узлами осуществляется посредством образования общей для них виртуальной памяти, но на самом деле «поставщик» и «получатель» самостоятельно управляют своими собственными буферами. На физическом уровне связь обеспечивают интерфейсные карты Network Interface Card, создающие частную сеть для каждого процесса. Этот подход гарантирует большую пропускную способность и меньшую задержку, чем традиционные, и даже, казалось бы, такая децентрализованная сеть, как Ethernet, имеет защищающее ее ядро, которое является непреодолимым бутылочным горлом.

Пример архитектуры, построенной на базе ServerNet, показан на рис 2. Система состоит из процессорных узлов и узлов ввода/вывода, объединенных друг с другом сетью SAN. Сеть ServerNet реализована посредством маршрутизатора, причем для обеспечения отказоустойчивости допускается построение двух независимых подсетей ServerNet: X и Y.

Дополнительной возможностью архитектуры является наличие специальной шины когерентности, служащей для согласования работы памяти, общей для нескольких процессорных узлов, и их кэшей при выполнении программ, рассчитанных на мультипроцессорную обработку в системе с разделяемой общей памятью. Компьютеры NonStop собирались из трех подсистем: процессорной, ввода/вывода и внешней памяти. Процессорная подсистема строилась на базе системных плат (SPU), каждая из которых включала по два микропроцессора MIPS R4400/200.

Серверы NonStop могли включать в себя тысячи процессоров и обеспечивать бесперебойную работу крупнейших объектов, таких как аэропорты, сети банкоматов, крупные банки. Готовность составляла «семь девяток» – не более трех секунд простоя в год. Естественно, цена этой надежности была очень высока, но если возвратиться в сегодняшний день, то мы обнаружим, что для повторения идеи NonStop Tandem имеются все условия. В 2006 году компания HP продолжила линию NonStop, собирая ее из лезвий BladeSystem c-Class. Использование технологий виртуализации межсоединений HP Virtual Connect обеспечило высокую архитектурную гибкость, что позволило назвать новые комплексы Adaptive Infrastructure in a Box, то есть адаптивными инфраструктурами из коробки.

Лезвия: пути и типы

С момента появления лезвий их развитие пошло по двум альтернативным путям, один стал массовым – его в 2001 году проложила компания RLX, а другой прокладывает компания Egenera со своей технологией BladeFrame, продвигаемой сегодня компаниями Fujitsu-Siemens и Dell.

Первый компьютер, построенный RLX на лезвиях, назывался System 324: в одну стандартную стойку высотой 42U удалось упаковать рекордное для своего времени количество процессоров – 324. Вскоре по этому пути с небольшими собственными вариациями пошли HP, IBM и Sun Microsystems. Этот путь предполагает, что серверы-лезвия одного типа собираются в стойки, а отдельные серверы агрегируются в систему с использованием стандартных коммутаторов. Чаще всего основным структурным компонентом является корзина на дюжину лезвий с собственным коммутатором. Компания BLADE Network Technologies распространила этот подход на всю стойку – выпускаемые ею коммутаторы RackSwitch высотой 1U имеют до 48 портов 10 GigabitEthernet, что позволяет оптимизировать охлаждение и сократить энергетические потери, но идея остается старой – добиться максимально высокой плотности размещения оборудования.

Несмотря на то что сегмент лезвий остается самым быстрорастущим среди остальных серверных направлений, он развивается не так быстро, как предполагалось. Первой реакцией на появление серверов-лезвий в 2001 году была мысль о том, что наконец-то можно будет собирать гибкие вычислительные системы. Прощайте, мэйнфреймы и мидфреймы, да здравствует принцип Lego! Однако, возникла пауза – сами лезвия нуждались в развитии, да и не менее важной оказалась проблема стандартизации. До сих пор нет отраслевых стандартов на лезвия, хотя сейчас делом стандартизации занимается консорциум Blade.org, контролируемый IBM.

Конструктивное решение, называемое лезвием, относится к категории изобретений, которые изначально, задумывались для узкого круга приложений. Но иногда так случается, что помимо воли самих изобретателей в их творениях открывается мощный потенциал, который выводит их за первоначальные границы и может оказать решающее влияние на выбор путей развития целой отрасли. Поначалу, когда говорили только о серверах-лезвиях, их рассматривали лишь как очередной этап миниатюризации серверов, логически следующий в цепочке: от мэйнфреймов к мини-ЭВМ, от корпусных конструкций к стоечным и к ультратонким серверам высотой 1U. Сам факт достижения рекордной плотности казался высочайшим достижением, однако скоро стало ясно: складывающаяся картина шире, и исключительно серверами, сейчас их иногда называют вычислительными лезвиями (Compute Blade), дело не ограничивается. Оказалось, что изобретение лезвий символизирует не просто очередную смену формфактора, а новый архитектурный подход, обеспечивающий широкому кругу систем высокую плотность, масштабируемость и гибкость.

Сегодня можно говорить о появлении самостоятельного направления в конструировании, получившего название Blade Computing (BC). Переход на BC предполагает сочетание в одной стойке различных функциональных компонентов – как массовых (это, прежде всего, микропроцессоры), так и специализированных (сетевые контроллеры, графические ускорители и т.п.), а также лезвий памяти и питания. Иным словами, из таких модулей можно собирать сложные системы по принципу Lego. Следует особо выделить еще одно важное преимущество нового конструктивного решения – переход на лезвия позволит избавить современные вычислительные системы от несоразмерного с их стоимостью короткого срока эксплуатации.

Пока преимущества лезвий в основном усматривались в возможности сконцентрировать в ограниченном пространстве значительную вычислительную мощность. Поэтому проектировщики стремились совместить на одной плате все комплектующие серверов: процессор и поддерживающий его чипсет, память и диски, сетевые интерфейсы и т.п., однако излишняя концентрация привела к ряду эксплуатационных проблем, например, особые трудности вызвало колоссальное тепловыделение. Помимо очевидного использования процессоров с меньшим энергопотреблением и более эффективных систем охлаждения, есть еще один подход – создание специализированных лезвий, позволяющий не только разрешить существующие проблемы, но и заметно развить идею Blade Computing.

Вычислительное лезвие (Compute Blade, CB). Лезвие данного типа содержит один или несколько процессоров и служит для «перемалывания чисел». Обычно на плате имеется некоторое количество памяти (кэш и оперативная память), а также, возможно, небольшой диск или флэш для первоначальной загрузки. Существующая тенденция свидетельствует о том, что CB будут освобождаться от вспомогательных компонентов в пользу процессоров. Примером CB могут служить платы семейства Intel Server Compute Blade от SBX44 до SBXD132. В 2008 году компания Sun выпустила несколько устройств такого типа – Sun Blade T6340 на двух процессорах SPARC T2+, каждый из которых имеет по восемь ядер. На плате может быть размещено до 8 Гбайт памяти, имеется два порта Gigabit Ethernet и место для двух дисков SAS. Наиболее характерными CB являются лезвия на процессорах AMD Opteron, из которых собирается суперкомпьютер Cray XT5. Плата XT4 комплектуется четырьмя двухъядерными процессорами, XT5 – восемью четырехъядерными.

Лезвие для хранения данных (Storage Blade, SB). С момента появления лезвий общая стратегия по отношению к системам хранения была достаточно простой – на лезвии нужно иметь минимальные диски, необходимые для работы операционной системы, а все остальное хранить на специализированных системах хранения. Но по мере повышения производительности серверов-лезвий оказалось, что заметным препятствием становится возрастающий трафик между ними и системами хранения. Тогда возникло разумное соображение приблизить часть систем хранения к лезвиям – так появились Storage Blade, которые сегодня производят HP, IBM, Fujitsu-Siemens и ряд других. Для характеристики SB придуман неплохой термин storage sidecar, буквально – мотоциклетная коляска. Большинство SB представляют собой сетевые накопители NAS, размещаемые непосредственно в стойке и подключаемые к ее коммуникационным каналам на задней панели. Примером служит дисковый модуль Sun Blade 6000, на котором можно установить до восьми дисков SAS общей емкостью 1,2 Тбайт.

Лезвия памяти. В изначальной парадигме память является атрибутом каждого сервера-лезвия, следовательно, общая организация системы может быть децентрализованной, что сегодня ассоциируется с кластерами, используемыми для высокопроизводительных вычислений, но для корпоративных приложений такая схема малопригодна. В то же время высокая пропускная способность коммуникационных систем, построенных на 10 или 20 Gigabit InfiniBand или 10 Gigabit Ethernet, подталкивает к идее создания специальных лезвий памяти, которые могли бы стать общим ресурсом для всех CB в стойке. Такая память будет медленнее, чем подключаемая по скоростным шинам на одной плате, но для целого ряда задач этого может оказаться вполне достаточно.

Помимо этих трех типов лезвий могут быть еще коммутирующие и маршрутизирующие лезвия, а также лезвия, обеспечивающие сетевой интерфейс.

Лезвия в сети PAN

Подход компании Egenera к построению систем из лезвий возвращает нас к тому, что когда-то делала компания Tandem, но теперь в роли системной сети SAN выступает собственная сеть PAN Egenera (Processor Area Network). PAN была предложена в 2000 году, она способна объединять не только процессоры, но и память, системы хранения, сетевые устройства и даже устройства типа DVD, собирая их в виртуальные кластеры. Наибольшую известность этой небольшой компании принес ее основной продукт Egenera PAN Manager, предназначенный для сборки серверов-лезвий в виртуализованный пул ресурсов.

Поначалу система BladeFrame, поставляемая Egenera, строилась из трех типов серверов высотой 1U, тогда их тоже называли лезвиями, что, по современным представлениям, неправильно. В ее состав входили процессорные лезвия (ProcessingBlade или pBlade), содержащие только процессоры Intel Xeon и оперативную память, в них нет дисков, следовательно, в отличие от обычных тонких серверов, они не имеют собственного состояния. Поэтому они полностью взаимозаменяемы в процессе эксплуатации. Более того, их можно заместить новыми без всяких изменений в работе приложений. Коммутирующие лезвия (Switch Blade или sBlade) соединяют серверы pBlade с основной панелью BladeFrame, называемой BladePlane, через интерфейс, близкий по типу к InfiniBand. Управляющие лезвия (Control Blade или cBlade) на модулях cBlade имели полное резервирование и несли программное обеспечение Egenera PAN Manager. Здесь же находятся порты 10/100 Base-T Ethernet, Gigabit Ethernet, Fibre Channel и порт ПК, выполняющий функции операторской консоли. cBlade обеспечивает интерфейс с внешней памятью NAS или SAN. Модули трех типов объединяются в систему посредством последовательных шин BladePlane. Их тоже две, основная и резервная. К BladePlane подключаются модули sBlade. Совместно они образуют надежный системный коммутатор (внутреннюю сеть TCP/IP).

С содержательной точки зрения современные реализации PAN изменились не сильно – на замену сверхтонких серверов пришли настоящие лезвия, теперь их четыре типа. В корзине может быть установлено до 24 процессорных лезвий, по четыре процессора на каждом, приложения могут работать под управлением ОС Windows, Linux или Solaris. Лезвия могут различаться по типу процессора, размеру памяти, но каждое лезвие pBlade подключается к двум коммутирующим лезвиям sBlade надежной внутренней сетью. Новыми являются виртуализующие лезвия vBlades, которые позволяют делить ресурсы процессорных лезвий. С лезвием vBlades можно консолидировать нагрузку множества серверов на одном pBlade, в том числе и задачи, работающие под управлением разных операционных систем. Лезвия vBlades соучаствуют в обеспечении готовности серверов pServers в своих локальных пулах и тем самым расширяют возможности системы обеспечения надежности PAN Manager High Availability failover and Disaster Recovery. В корзине устанавливается два коммутирующих лезвия sBlades, одно для внутренних коммутаций типа pBlade-to-pBlade, а второе для связи с LAN и SAN. Функцию управления осуществляют дублирующие друг друга лезвия cBlades, на них установлено ПО PAN Manager.

От традиционных серверов BladeFrame отличается большей гибкостью в образовании виртуальных серверов. Средствами PAN Manager администратор может динамически распределять ресурсы, создавая требуемое количество виртуальных серверов, менять их конфигурацию, перераспределять приложения между серверами. Но следует отличать такой способ фрагментации от разбиения на разделы в крупных SMP-серверах, где группа процессоров работает под управлением одной операционной системы. Серверы в BladeFrame не сливаются в один SMP-образ – каждый из них работает под управлением собственной операционной системы, а виртуальный сервер, по сути, является виртуальным кластером. В терминологии Egenera такие объединения называют Logical Processing Area Network (LPAN).

Виртуализация 2.0

В 2008 году почти одновременно глашатаи из IDC и Gartner с подачи Egenera ввели новый термин Virtualization 2.0. Компания Egenera претендует занять во второй волне виртуализации ту роль, которую заработала для себя VMware на первой. Если первая волна ассоциировалась с гипервизорами и виртуализацией единичного сервера, то вторая распространяется на весь ЦОД. Подход, предлагаемый Egenera, позволяет виртуализировать все ресурсы, образуя сети физических и виртуальных серверов, создавать группы серверов и перемещать их при необходимости, обеспечивая при этом высокую надежность и готовность. Реальным конкурентом Egenera может быть HP с технологией Opsware, купленной в 2007 году, и Cisco с технологией VFrame Data Center (VFrame DC).

Силос от ИТ

Нынешние ЦОД сохраняют родственность с классическими ВЦ – иногда их называют примерами silos of computing, то есть компьютингом, собранным из силосных вычислительных башен. Здесь каждая башня работает на определенного потребителя или приложение, существует отдельно от других и отдельно от других управляется. Слово silo прочно вошло в американский диалект английского языка; в частности, есть выражение information silo, применяемое для систем менеджмента, где отсутствует операционное взаимодействие, для обозначения людей, обладающих соответствующими свойствами. Говорят, например silo thinking (мышление), silo vision (видение) и silo mentality (ментальность), следствием чего становится silo effect. В программном обеспечении для преодоления негативных последствий silo technologies используют ПО промежуточного слоя и сервисные архитектуры.

Предшественники кластеров

Архитектура компьютеров Tandem опередила свое время – ей не хватило адекватных процессоров и сетевых технологий. http://www.osp.ru/cw/2005/42/372163

Виртуальный кластер из консервной банки

Объявленная еще в сентябре 2001 года система BladeFrame не похожа ни на что и представляет собой пул из 96 процессоров со свободным сетевым соединением.
http://www.osp.ru/os/2002/03/181254