Строим «облако». Часть Первая. Виртуализация

Лично я, основываясь на практическом опыте построения и внедрения «облаков», пришел к выводу – в «облаке» все должно быть виртуализовано по максимуму. Речь идет не только о гипервизоре, так что обо всем по порядку.

Гипервизор – программа или аппаратная схема, обеспечивающая или позволяющая одновременное, параллельное выполнение нескольких или даже многих операционных систем на одном и том же хост-компьютере (см. Wikipedia). «Облако» не должно вас ограничивать в выборе гипервизора – сегодня VMWare оправдывает свои деньги, а завтра, скажем, Microsoft выпустит отличный и существенно более дешевый Hyper-V, а послезавтра на первый план выйдет KVM в силу своей открытости. Так что вы всегда должны иметь выбор гипервизора, который актуален на текущий момент по соотношению цена/качество. Это сохранение инвестиций, оптимизация расходов. Тем более, что консоль управления базовой функциональностью гипервизоров все равно одна – соответствующее ПО (vCenter, Mircosoft VMM, KVM Appliance, пр.) просто подключается к «облаку» в роли провайдера ресурсов.

Виртуализация СХД – первый виртуализованный массив в мире появился у компании Hewlett-Packard и назывался HP Enterprise Virtual Array. Сегодня в портфолио каждого производителя СХД имеется не один виртуализованный массив, и все они по-своему хороши.

В чем суть виртуализации СХД:

Все жесткие диски объединяются в так называемые дисковые группы. Вы оперируете емкостью не нескольких дисков, собранных в RAID, а – всей дисковой группы, создавая там логические диски (LUN) уже с виртуальным уровнем RAID (vRAID). Данные на диск записываются в блочном виде и равномерно распределяются между всеми дисками той дисковой группы, в которой создан LUN.

Например, в дисковой группе из 24 дисков емкостью в 3,5 Тб файл, который вы записываете на LUN, делится на 24 равные части. Все операции по обслуживанию, такие как изменение объема LUN или ввод/вывод диска из дисковой группы, обновление прошивок, проводятся легко и в режиме online.

Преимущества такого подхода очевидны:

• более высокая отказоустойчивость. При выходе из строя одного из дисков, массиву нужно восстановить всего лишь 1/24 данных;
• скорость. Над вашими данными работают все 24 шпинделя из дисковой группы;
• абстрагирование от аппаратных ограничений. Роль играет пространство всей дисковой группы, а не отдельного диска. Вы легко можете ввести в группу новый диск и данные перераспределятся уже на 25 дисков без простоя;
• защита данных. Если диск изъят из массива, данные с него не могут быть считаны. Чтобы считать данные, необходимо взять все диски из дисковой группы и расставить их в том же порядке, в котором они стояли в исходном массиве.

Виртуализация ввода/вывода – еще несколько лет назад одно физическое подключение означало один физический сетевой адаптер с одним подключенным в него патчкордом. Сегодня у каждого производителя серверов существует множество технологий виртуализации ввода/вывода из сервера. У компании Hewlett-Packard не один год имеется технология, на которой основана вся концепция Converged Infrastructure, – HP Virtual Connect (VC). Как по мне, задумка достаточно хороша, а реализация наконец-то достигла уровня enterprise. Единственное ограничение, которое я заметил, – технология VC реализована только для blade-серверов и только для шасси с7000, хотя обещают выпуск сетевых адаптеров FlexFabric и для стоечных серверов. Потому вся следующая информация представлена для только для указанного оборудования.

Суть Virtual Connect заключается в следующем (без упоминания про технологию Flex-10):

• каждому серверу назначаются виртуальные МАС- и WWN-адресf, а также серийный номер, которые могут мигрировать от сервера к серверу. При управлении ПО VCEM такая миграция может быть выполнена автоматически по любому «событию» от сервера. С использованием технологии boot-from-SAN я смог эмулировать миграцию физических серверов в шасси, подобную миграции виртуальных машин на хост-сервере (только в режиме offline), так как с «переездом» WWN и МАС, адресов происходит миграция и презентованных LUN дисков (в том числе и с ОС), и настроек сети;
• виртуализация uplink-портов дала возможность абстрагироваться от downlink-портов серверов. Сколько бы у меня серверов ни было в шасси, я могу их подключить в инфраструктуру всего одним uplink-портом;
• в каждый порт сервера, а с использованием HP VC в самом простом сервере HP BL460c их становится восемь, а не два, можно подключить до 1065 VLAN. Я только один раз использовал эту функциональность, когда строил для одного большого украинского банка VDI-инфраструктуру на 5000 пользователей, которые подключались через 920 VLAN-сетей;
• модули VC объединяются в так называемый Virtual Connect Domain, в котором может быть до 4 шасси. А ввиду виртуализованных uplink-портов, серверы из одного шасси могут быть подключены через uplink-порты другого и мигрировать между шасси. Это повышает отказоустойчивость – при выходе из строя целого шасси серверы мигрируют в соседние и подключение происходит через другие uplink-порты.

У компании Cisco виртуализация ввода/вывода реализована на базе технологии Nexus. Принцип работы и цель те же самые – виртуализация WWN- и МАС-адресов серверов с использованием конвергенции со всеми вытекающими. У этой технологии есть свои плюсы:

• виртуализация WWN- и MAC-адресов реализована и для стоечных серверов;
• горизонтальное масштабирование. Для расширения на оборудование с другим шасси или даже в другом шкафу не требуется покупка полноценных коммутаторов, просто докупаются расширительные карты – fabric extender’ы. Получается дешевле;
• каждый сервер, подключенный в фабрику Nexus, имеет не восемь портов, а 116,

но также и минусы:

• для виртуализации ввода/вывода у Cisco необходимо, чтобы серверы были подключены к коммутатору Nexus, с любым другим коммутатором эта технология не работает (опять же, ограничение в выборе оборудования);
• трафик невозможно распределить внутри шасси. Для соединения двух серверов в одном шасси в обязательном порядке требуется внешний коммутатор L2 или L3. В решении НР трафик может коммутироваться внутри шасси;
• отсутствие прямой поддержки от производителя в Украине.

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

Строим «облако». Часть вводная. Пояснения