Развитие серверных технологий в зеркале обзоров и пресс-релизов производителей напоминает пересказ олимпийского девиза «Выше, быстрее, сильнее»: все больше процессоров и ядер, все больше объемы оперативной памяти, все выше производительность; spec.org и tpc.org регистрируют все новые рекорды. Подобная картина наблюдается и с системами хранения данных: с публикацией обзоров новых систем в стиле «еще больше и еще быстрее» и пополнением списка рекордсменов на Storage Performance Council. Вместе с тем, в последние пять лет в IT-индустрии шли интересные, хоть и не слишком заметные технологические процессы.
Результатом этих процессов стало появление систем, которые, если продолжать олимпийско-спортивные аналогии, претендуют на рекорды не в узких дисциплинах вроде производительности или объема оперативной памяти на юнит, а в своего рода комплексном многоборье. Напомним, что олимпийское пятиборье в Древней Греции было не спортом в нынешнем понимании, а способом подготовки атлета как бойца. Именно о таких системах-«многоборцах» вообще и Cisco Unified Computing System в частности пойдет речь в этой статье.
Блеид-системы и «виртуализация-1»
Первоначальным мотивом создания серверных блейд-систем стала концентрация вычислительной мощности в единице объема: задача весьма актуальная для центров обработки данных, где цена объема или юнита в стойке весьма высока. Экономика в этом случае очень проста: стоимость ЦОДа включая затраты на оборудование помещения и инженерную инфраструктуру, является своего рода налогом на вычислительное ядро и чем больше серверов в единице объема ЦОДа, тем меньше удельные инфраструктурные затраты. Этот фактор был особенно существенным при модернизации ЦОДов; потребности в вычислительных мощностях растут, свободного пространства в стойках становится все меньше, и замена старых серверов на новые, хоть и более производительные, но в том же форм-факторе далеко не всегда решала проблему.
Решение в виде выноса в блейд-шасси систем питания и охлаждения отдельных серверов и принесение в жертву возможностей расширения серверов-лезвий по количеству устанавливаемых дисков и разъемов расширения (впрочем, такое пожертвование расширяемостью обернулось на самом деле преимуществом); использование внешних дисковых массивов, подключаемых по протоколу Fibre Channel, позволило увеличить надежность систем за счет выноса данных с локальных жестких дисков и резервирования по схеме N+1.
В результате блейд-система стала своего рода однокорпусной мини-стойкой серверов со встроенными резервированными Ethernet и Fibre Channel коммутаторами, системой мониторинга и IP-КУМ'ом, улучшенной ремонтопригодностью и, заодно, минимизацией количества кабельных подключений в шкафу.
Параллельно с увеличением количества процессоров в единице объема блейд-систем развивались технологии виртуализации. В 2003 году VMware выпустила Virtual Center и VMotion, а Microsoft приобрела компанию Connectix с ее продуктами Virtual PC и Vitual Server. И, наконец, в 2005 года Intel и AMD выпустили первые действительно двухъядерные однокристальные серверные процессоры: гонку тактовых частот CPU сменила «ядерная» гонка. Эти три составляющих - блейд-систеы высокой плотности, многоядерные процессоры и виртуализации, как оказалось, крайне удачно дополнили друг друга, образовав системную платформу для консолидации приложений.
Повышение мощности серверов в виртуальной среде позволило осуществить экономически оправданный переход к сценарию «одно приложение в одном экземпляре ОС», существенно упрощающий программные и системные зависимости, избавиться, наконец, от проблем программно-аппаратной совместимости за счет того, что операционные системы в виртуализированной среде «видят» одинаковые виртуализированные ресурсы, а гипервизор работает на стандартизированных серверах-лезвиях, что сократило трудоемкость администрирования; работа нескольких ОС со своими приложениями позволила повысить утилизацию аппаратных ресурсов за счет временного усреднения нагрузки. Последнее оказалось особенно эффективным в случае унаследованных приложений, написанных без учета паралеллизма и не способных использовать возможности многоядерных систем. И, наконец, за счет технологий перемещения виртуальных машин между различными физическими серверами (Vmware Vmotion и Microsoft Hyper-V Live Migraion) появилась возможность перераспределения нагрузки.
Однако такая консолидация оказалась все же неидеальной: пусть и виртуализованные, блейд-системы остались стойками серверов в миниатюре с сетями Ethernet и FC, объединяемыми встроенными коммутаторами. И с дополнительным уровнем коммутации: между виртуальными Ethernet-адаптерами, которые «видят» виртуализованные операционные системы, и физическим Ethernet-адаптером сервера находится виртуальный Ethernet-коммутатор гипервизора.
Рис. 1 Лишние коммутаторы в витруализованной блейд-системе: виртуальные гипервизора и физические блейд-сшасси (3 и 4, справа).
В результате, по сравнению с классическими сетями серверного ядра, появилось еще два уровня коммутации: виртуальные коммутаторы гипервизоров каждого сервера и встроенные коммутаторы в блейд-шасси. И зачастую все эти коммутаторы оказываются от различных производителей и, соответственно, управляются программными пакетами, что не упрощает задачу администрирования.
Пожалуй, единственным «монолитным» исключением на сегодняшний день являются блейд-системы c виртуальными коммутаторами Cisco Nexus 1000V под VMware vSphere. Однако и в этом случае остается проблема администрирования двух (Ethernet и FC) сетей в таких системах.
«Виртуализация-2»
Одновременно с корпоративными серверными системами в академическом мире развивались технологии высокопроизводительных вычислений (High Performance Computing , HPC). Особенностью высокопроизводительных вычислительных кластеров была необходимость интенсивного межпроцессного обмена между вычислительными узлами — фактически пересылки между областями оперативной памяти в стиле ccNUMA, которые требовали выделенной сети с гарантированной доставкой и крайне малыми задержками.
Ответом на это требование стала технология Infiniband, первая версия, спецификация которой была опубликована ITA в 2000 году. Эта технология с базовой скоростью 2,5 Гбит/с оказалась настолько хороша, что вскоре стала отраслевым стандартом универсального транспорта в в области HPC — от обеспечения межпроцессного взаимодействия, включая удаленный доступ к памяти (IPC/ RDMA) и межузлового транспорта IP до доступа к дисковым SCSI-устройствами с использованием RDMA.
К 2005 году на рынке появились компании, которые предлагали высокопроизводительные Infiniband-коммутаторы с унифицированным вводом-выводом: в серверы достаточно было установить 10 Гбит Infiniband-адаптеры (Host Channel Adapter, HCA) и подсоединить эти серверы к Infiniband-коммутатору с модулями-шлюзами в Ethernet LAN и Fibre Channel SAN, чтобы получить систему с универсальным конвергентным транспортом и великолепной управляемостью: на физическом HCA можно было конфигурировать виртуальные Ethernet, Fibre Channel и IB/IPC адаптеры с возможностью оперативного переконфигурирования и управления распределением полос пропускания. В таких системах радикально упрощалась архитектура: если в классических системах, в том числе и блейд-серверах, требовались три адаптера трех различных сетей — LAN/Ethernet, SAN/ FC и IPC, и соответственно, три порта трёх коммутаторов, то в Infiniband-варианте на один конвергентный адаптер приходился один порт универсального коммутатора: скорость в 10 Гбит, обеспечиваемой Infiniband, c запасом перекрывала суммарную полосу 1 Гбит Ethernet и 4 Гбит Fibre Chanel адаптеров того времени.
Неудивительно, что в том же 2005 году лидирующая в сетевых технологиях Cisco приобрела компанию Topspin, выпускавшую универсальные Infiniband-коммутаторы со шлюзами Fibre Channel и Ethernet и, что немаловажно, систему управления VFrame, то есть целостную систему виртуализации ввода-вывода для серверных ферм, включив ее в свою продуктовую линейку. Казалось бы, Infiniband был хорош всем, однако у него был один, но весьма существенный недостаток: это был не Ethernet.
Рис. 2 Виртуализация ввода-вывода.
Infiniband воспринимался как нишевая технология — в то время как Ethernet был технологией массовой, имел колоссальную инсталлированную базу и, что оказалось самым главным, был знаком огромному числу специалистов, как разработчикам, так и пользователям, тем более, что к этому времени уже появились протоколы доступа к системам хранения данных в Ethernet-сетях - iSCSI, iFCP и FCIP. Однако эти протоколы имели одну существенную проблему — они все работали поверх TCP/IP-стека, работающего в операционной системе сервера и требовали строгой приоритизации трафика обмена с дисковыми устройствами, что в случае высоких скоростей оборачивалось существенными затратами процессорных ресурсов. Для того, чтобы избавиться от этой проблемы, во все том же 2005 году в комитет по стандартам IEEE 802 компаниями Intel, Cisco и IBM было подано предложение Proposal for Traffic Differentiation in Ethernet Networks приоритизации трафика и обеспечению гарантированно доставки пакетов на канальный уровень, т.е. фактически, по переносу свойств Infiniband, обеспечивающих виртуализацию ввода-вывода, в Ethernet. Итогом дальнейших усилий по развитию этого предложения стала разработка протокола группы стандартов, известных сейчас под собирательным названием IEEE 802.1 Data Center Bridging (Data Center Ethernet - DCE в варианте Cisco либо Converged E nhanced Ethernet -CEE по версии IBM) и протокола Fibre Channel over Ethernet. Среди компаний - стартапов, работающих в этой области, одной из первых, представивших работающие прототипы комбинированных DCB Ethernet / FCoE коммутаторов, стала Nuova Systems, приобретенная в 2006 году Cisco.
Опыт, знания и специалисты, полученные в результате приобретения Topspin и Nuova, в сочетании с наработками Cisco сделали свое дело. Хотя в настоящее время у многих производителей в продуктовых линейках присутствуют DCB Ethernet и DCB/FC-коммутаторы, Cisco оказалась первой компанией, которая вывела на рынок законченное и максимально полное на сегодняшний день серверное решение c виртуализацией ввода-вывода — Unified Computing System (Cisco UCS) — серверную систему с единой конвергентной 10 Гбит DCB-сетью, объединяющей LAN и SAN сети и сквозной системой управления. Следует отметить, что Unified Computing System не является исключительно блейд-системой: она включает в себя Top-of-Rack коммутаторы UCS 6100 Series и в ее состав могут входить и сервера UCS C-Series в Rack-Mount исполнении.
В настоящий момент состав Cisco UCS выглядит следующим образом:
• UCS 6100 Series Fabric Interconnects: DCB Ethernet коммутаторы, доступные в двух вариантах: 20-портовый UCS 6120XP и 40-портовый UCS 6140XP.
• UCS 5100 Series Blade Server Chassis: 6 RU шасси, в которое можно установить до восьми серверов-лезвий и два сетевых модуля fabric extenders
• UCS 2100 Series Fabric Extenders: сетевые модули, соединяющие сервера-лезвия с UCS 6100 Fabric Interconnects, 4х10 Гбит DCB соединения на каждый.
• Сервера-лезвия B-Series серий B200, B230, B250 (до 384 GB RAM) B440 (до 4-х 8-ядерных процессоров серии Intel Xeon 7500).
• Rack-Mount сервера UCS.
• Конвергентные сетевые адаптеры UCS B-Series и C-Series.
• UCS Manager: система управления.
И самыми интересными в этом списке являются последние две строки.
Среди конвергентных сетевых адаптеров, которые используются в UCS, технологически наиболее необычным является двухпортовый 10 Гбит M81KR
Virtual Interface Card (VIC) для серверов-лезвий B-Series, разработанный для использования в стредах с массовой виртуализацией. В такой ситуации, как правило, сетевые интерфейсы виртуальных машин работают с физическим интерфейсом через виртуальный коммутатор гипервизора, и при этом возникают две проблемы: во-первых, коммутатор потребляет системные ресурсы сервера и, во-вторых, повышается сложность системы возникает еще один уровень коммутации и, соответственно, объект управления.
В M81KR VIC эта проблема решена необычным образом: адаптер представляется гипервизору в BIOS сервера как 128 независимых PCIe устройств, которые могут быть динамически сконфигурированы в качестве и Ethernet, и Fibre Channel адаптеров, с собственными MAC и WWN адресами. Далее для таких «физически-виртуальных» адаптеров в гипервизоре могут быть сконфигурированы прямые подключения виртуальных машин без задействования виртуального коммутатора. Создание, модификация и управление такими адаптерами производится из UCS Manager прозрачно и незаметно для гипервизора, задачи по сетевой конфигурации полностью переносятся из гипервизора в UCS Manager.
Такой подход дает еще один эффект: в UCS Manager можно создавать множество виртуальных аппаратных конфигураций системы, оформляя их в виде сервис-профилей под различные задачи и оперативно переключаясь между ними. Например, с дневного обслуживания виртуальной desktop-среды (VDI) на аналитические задачи в рабочее время, т.е. есть предоставлять вычислительную инфраструктуру как сервис (IaaS). И в заключение. В 2009 году в Network World появилась заметка с названием «Cisco UCS: it's an architecture, stupid!» (Cisco UCS: это архитектура, тормоз!). Это действительно так: серверные системы с конвергентным вводом-выводом, в сочетании с массовой виртуализацией и сквозным управлением действительно представляют собой новую архитектуру, идеально вписывающуюся в парадигму Cloud Computing, и Cisco UCS на сегодняшний день, похоже, является вершиной эволюции таких систем.
Рис. 3 Архитектура Cisco UCS
Чего ожидать в будущем? Появления систем хранения данных, подключаемых по DCB Ethernet, которые устранят необходимость в FC SAN сегментах и момента, когда 40 Гбит DCB Ethernet станет таким же доступным, как доступен сейчас 40 Гбит Infiniband.
Владимир КУРГ руководитель группы технического развития «Инком»
