Изначально
материал должен был повествовать о технологии конвергенции инфраструктуры
ввода-вывода для блейд-систем компании DELL, но оказалось, что есть много
интересного и по другим вендорам, поэтому данный пост посвящаю мои любимым: HP,
DELL, Cisco, Fujitsu, IBM и, конечно, Hitachi!
Про
DELL мы поговорим в отдельной статье!
Блейды,
лезвия, блейд-серверы, эффективность, виртуализация, конвергенция, плотность…
Все эти понятия постоянно фигурируют в презентациях и докладах основных мировых
производителей вычислительных платформ.
Отдельное
«БРАВО» необходимо выразить HP и их сотрудникам за прекрасный маркетинг и
видение конвергентной инфраструктуры предприятия на базе технологий VirtualConnect
FlexFabric и Flex-10. Это действительно круто, и благодаря фанатичным
сотрудникам технологию успешно получается продвигать на рынок!
Конечно,
стоит отметить и Cisco с их видением DataCenter 3.0, абсолютно новой
архитектурой построения I/O для блейд-систем на базе Fabric Interconnect с унифицированными
портами.
Это,
как раз, те два вендора, которые продвигают и популяризируют конвергентные сети
для предприятий любого размера.
У
меня сложилось следующее мнение, повторюсь, что это чисто мое ИМХО: HP, DELL, Fujitsu,
IBM – это классика построения блейд-решений. Хотя все они разные визуально и
отличаются подходами к построению, но архитектурные принципы в них заложены
схожие. Cisco – это новая концепция построения плотных вычислительных
комплексов с глубокой виртуализацией. Где-то, чуть впереди классических
решений, стоят блейд-системы компании Hitachi с их возможностью объединения
нескольких блейдов (макс. 4) в единое логическое целое по QPI шине, возможность
аппаратной виртуализации блейда (нарезание LPAR), а также PCIe слоты для
дополнительных карт расширения ввода-вывода. Решение молодое, понятное дело,
что за такими технологиями будущее, но сыроватое еще… Думаю, что внедрение
дублирующей QPI шины частично поможет решить вопрос…
Кстати,
один мой коллега уже давно предсказал экспансию Intel на рынок аппаратной
виртуализации J.
Матчасть
Многие
серверы среднего сегмента последнего поколения (mainstream), особенно блейды, в
базе комплектуются двумя портами 10 Гб/с.
Пайплайн
в 10 Гб/с (20 Гб/с на два порта) загрузить одному серверу очень тяжело.
Особенно тяжело будет его загрузить, если использовать порты только для TCP/IP трафика.
Существует
такое понятие как «best practice» - рекомендации по наилучшей конфигурации и
управлению чем либо. В случае разворачивания виртуализационного кластера от VMWare,
у каждого физического хост сервера желательно, что бы было минимум по 4x1 Гб/с
сетевых порта. Для чего? Вот для таких сетей:
·
менеджмент сеть (Management);
·
сеть ядра (VMkernel: это IP Storage,
vMotion);
·
сеть виртуальных машин (Guests или VMs);
·
дублирующая сеть (Fault Tolerance,
FT).
Список
можно продолжать и расширять выделяя каждую функцию в отдельную сеть.
В
случае, когда портов на физическом сервере не хватает, используют разделение
трафика на уровне VLANов и IP подсетей. Но это уже будет не «best practice» J.
Принимая
во внимание тот факт, что 10 Гб/с – это очень много, а он дорогой, а внедрять
его надо (роадмапы за плечами), был придуман способ улучшения утилизации этих
вот 10 Гб/с портов, а точнее – виртуализация инфраструктуры ввода-вывода.
Основная
идея виртуализации портов I/O заключается в том, что бы один 10 Гб/с физический
можно было разделить на несколько виртуальных, прозрачно для самого сервера и
операционной системы.
Так выглядит конвергенция
I/O у HP
В
данный момент индустриальным стандартом является деление каждого 10 Гб/с порта
на четыре виртуальных, но есть и исключения типа Cisco, которые умеют делить каждый
порт на 32 виртуальных адаптера. Более того, один, два или больше (в
зависимости от вендора) виртуальных адаптеров могут быть не просто NIC, а HBA с
полной поддержкой механизмов Offload Engine для протоколов iSCSI или FCoE.
А
так как у нас два порта на каждом сетевом адаптере, то мы получаем вдвойне
больше!
Основные
вендоры не выпускают «своих» собственных сетевых адаптеров для серверов, а
используют разработки специализированных компаний типа: Brocade, Broadcom, Emulex,
Intel, Mellanox, Qlogic. Единственным производителем «собственных» карт
является Cisco (VIC 1240 и VIC 1280). Таблица ниже наглядно показывает нам «who
is who»!
Vendor
|
Card type
|
Vendor Naming
|
Based On
|
HP
|
Flexible
LOM* Blade (FLB)
|
HP
530FLB (Flex-10)
|
Broadcom
BCM57810S
|
Flexible
LOM* Blade (FLB)
|
HP
554FLB (FlexFabric)
|
Emulex
BE3
|
Mezzanine
|
HP
530M (Flex-10)
|
Broadcom
BCM57810S
|
Mezzanine
|
HP
552M (Flex-10)
|
Emulex
BE3
|
Mezzanine
|
HP
554M (FlexFabric)
|
Emulex
BE3
|
DELL
|
NDC**
LOM
|
Broadcom
57810S-k NDC (CNA)
|
Broadcom
BCM57810S
|
NDC**
LOM
|
QLogic
QMD8262-k NDC (CNA)
|
Qlogic
P3+
|
NDC**
LOM
|
Intel
X520-k NDC (Eth.)
|
Intel
X520/82599
|
Mezzanine
|
Broadcom
57810S-k (CNA)
|
Broadcom
BCM57810S
|
Mezzanine
|
Intel
X520 (Eth.+)
|
Intel
X520
|
Mezzanine
|
QLogic
QME8262-k (CNA)
|
Qlogic
P3+
|
Mezzanine
|
Brocade
BR1741Mk (Eth.+)
|
Brocade
Catapult I
|
Cisco
UCS
|
Modular
LOM
|
VIC
1240
|
dark
forest
|
Mezzanine
|
VIC
1280
|
dark
forest
|
Mezzanine
|
Emulex
M73KR-E
|
dark
forest
|
Mezzanine
|
Qlogic
M73KR-Q
|
dark
forest
|
Fujitsu
|
LOM
|
MC-CNA112E
|
Emulex
BE3
|
Mezzanine
|
MC-CNA112E
|
Emulex
BE3
|
IBM BladeCenter
|
LOM
Interposer Card
|
10Gb
LOM Interposer Card
|
Emulex
BE3
|
Mezzanine
|
Broadcom
2-port 10Gb Virtual Fabric Adapter
|
Broadcom
57711
|
Mezzanine
|
Emulex
10GbE Virtual Fabric Adapter II for HS23
|
Emulex
BE3
|
Mezzanine
|
Brocade
2 port 10GbE Converged Network Adapter
|
Brocade
1007
|
Mezzanine
|
QLogic 2-port 10Gb
CNA
|
QLogic
ISP8112
|
Mezzanine
|
Mellanox 2-port 10Gb
Enet Expansion Card
|
Mellanox
ConnectX-2
|
Mezzanine
|
Intel 10Gb 2-port
Ethernet Expansion Card
|
Intel
82599
|
IBM Flex System
|
LOM
|
Embedded 10 Gb
Virtual Fabric Adapter
|
Emulex
BE3
|
Mezzanine
|
EN4132
|
Mellanox
Connect-X3
|
Mezzanine
|
CN4054
|
Dual-ASIC
Emulex BE3
|
Mezzanine
|
CN4058
|
Dual-ASIC
Emulex XE201
|
Mezzanine
|
EN4132 (for Power)
|
Mellanox
ConnectX-2
|
* - LOM = LAN on Motherboard
** - NDC = Network Daughter Card
Из
этой таблицы мы можем сделать следующие выводы:
·
Emulex является лидером по количеству
вендоров, которым они продают свои технологии (аплодисменты!), далее идут Broadcom,
Brocade, Mellanox, Intel и Qlogic;
·
Адаптер, построенный на одном и том же
контроллере, у разных вендоров может работать по-разному (думаю, что это
связано с продвижением проприетарных технологий конвергенции);
·
Cisco, как всегда, идут своим путем.
Подходы
к построению Converged Networking у всех вендоров разные: кто-то завязывает управление
на коммутаторах (Switch Dependent CNA Partitioning), кто-то оставляет
управление независимым от коммутаторов, т.е. отдельное для каждого
блейд-сервера (Switch Independent), а кто-то предлагает клиенту самому выбрать
как он хочет управлять своей инфраструктурой.
Вендор
|
Название технологии
|
Switch Dependency
|
Описание
|
HP
|
VirtualConnect
Flex-10 и FlexFabric
|
Dependent
|
Проприетарная
технология виртуализации I/O. Настройка каждого порта производится на сетевых
модулях (агрегаторах) ввода-вывода блейд шасси. Требует Top-of-Rack или Core коммутаторов
ядра LAN и SAN
|
DELL
|
nPAR
|
Independent
|
Настройка
каждого порта производится на уровне каждого блейд-сервера
|
Cisco
|
-
|
Dependent
|
Проприетарная
технология виртуализации I/O. Настройка каждого порта производится на внешних
агрегаторах / коммутаторах – Fabric Interconnect (FI). FI являются
центральной точкой управления всех блейд-серверов, т.к. само по себе
блейд-шасси не конфигурируется
|
Fujitsu
|
DynamicFabric
|
Independent
|
Используется
Emulex BladeEngine3. Возможна настройка CNA напрямую на каждом блейде, либо
через централизованную опциональную консоль управления (ServerView VIOM), которая
предоставляет некоторые возможности автоматизации (выделение адресов из
заранее предопределенных пулов)
|
IBM
BladeCenter
|
Virtual
Fabric
|
Dependent
|
В
режиме Virtual
Fabric
доступно
партиционирование CNA
|
IBM
FlexSystem
|
Virtual
Fabric
|
Dependent
or Independent
|
Возможны
несколько режимов партиционирования: с помощью Virtual Fabric и Switch Independent
|
Dependent или
Independent?
Хитрый
вопрос.
С
одной стороны у нас есть практика HP и Cisco, которые завязывают управление на
агрегационных модулях, при этом требуют дополнительных компонентов
инфраструктуры в виде выделенных коммутаторов для LAN и
SAN.
Возможен вариант реализации на коммутаторах с унифицированными портами, яркими
представителями которых являются семейства Cisco Nexus 5000 и 7000.
Специально
подчеркиваю термин агрегационный модуль, так как ни HP, ни Cisco не
называют свои железяки полноценными коммутаторами и просят выделять отдельное звено
ядра коммутации. Возможны варианты подключения FC, FCoE или
iSCSI
систем
хранения данных напрямую в данные модули. Таким образом, вы сможете обойтись как минимум без покупки выделенных FC коммутаторов.
Такой
подход дает возможность более глубокой интеграции и автоматизации сетевой
инфраструктуры на уровне создания блейд-профилей. Это правильный, но дорогой
подход.
С
другой стороны, если у вас есть возможность Switch Independent конфигурирования
ваших CNA,
вы можете не завязываться на производителе оборудования и организовывать ядро
коммутации (как минимум FC сети) на базе ваших
коммутаторов блейд-корзины. Т.к. в случае Switch Independent варианта
вы используете конвергентные коммутаторы, именно полноценные коммутаторы. Лишь
бы вам портов хватило! Да и вендоры, использующие Switch Independent конвергенцию
уже научились автоматизировать процесс управления инфраструктурой ввода-вывода.
В
конечном итоге мы видим, что виртуализацию инфраструктуры ввода-вывода
используют все ведущие производители блейд-систем. Какой подход выбрать? Это
индивидуальный вопрос каждого клиента, который необходимо хорошо проработать
перед внедрением нового комплекса. Он будет зависеть от многих факторов и
предпочтений.
Я буду рад вашим комментариям,
т.к. прекрасно понимаю, что существует огромное количество точек зрения!
