Один из часто задаваемых вопросов — как построить отказоустойчивый кластер vSphere? На самом деле это очень просто, компания VMware прилагает огромные усилия к тому, чтобы конфигурирование ее продуктов и управление ими не занимали слишком много времени и сил у администраторов, и не требовалось запоминать трехэтажные комбинации команд. В частности создание кластерной файловой системы занимает буквально два-три клика мышкой, а дальше она автоматически подключается ко всем хостам, у которых есть доступ к соответствующему дисковому массиву.
Постараюсь показать как же именно создается кластер высокой доступности vSphere и объяснить как он работает.
Предполагается, что уже установлен vCenter Server и 2 ESX сервера, заданы IP адреса управляющих консолей и более ничего. Подключаемся к vCenter при помощи vSphere Client (его можно скачать с https://<vcenter>).
Корневым элементом инфраструктуры vSphere является датацентр, поскольку единственный vCenter может управлять до 300 ESX хостов, разбросанных географически. Создадим новый датацентр DC1 (подробности пропущу, это тривиально и не требует никаких настроек). В итоге у нас должна получиться примерно такая картинка:
Кластер с точки зрения VMware — это логическое объединение нескольких ESX хостов, причем кластер может быть не высокой доступности, и даже не иметь общего хранилища. Зачем такие кластеры? Например, для удобства управления — можно объединить несколько хостов в кластер и выдавать разрешения сразу на кластер, а не на каждый хост в отдельности.
Для начала создадим кластер без всего, пустой и одинокий.
А теперь добавим в него пару ESX хостов: esx-5b и esx-7b. Для этого достаточно просто кликнуть правой кнопкой по кластеру и сказать «Add Host».
Обращаю ваше внимание, что в VI3 кластеры были очень чувствительны к DNS, и хотя в vSphere 4 чувствительность несколько снизилась, в любом случае обеспечение высокой доступности DNS является первостепенной задачей. В маленьких инфраструктурах допустимо вручную править /etc/hosts, однако я не рекомендую этого делать и вообще без абсолютной необходимости что-то править в конфигах сервис-консоли вручную. Всегда есть вероятность при переезде забыть что и где было исправлено когда-то, и соотв. потратить уйму времени и сил, пытаясь понять почему все работает как-то странно.
Итак, у нас теперь есть небольшой кластер:
Кластер высокой доступности (HA — high availability) обеспечивает автоматический перезапуск ВМ в случае смерти одного из хостов на оставшихся в живых. Для ВМ это выглядит как выключение питания и включение через 15 секунд (тайм-аут по умолчанию). Подробнее о механизме работы HA можно прочитать здесь.
Кластер у нас есть, но как сделать из него кластер высокой доступности? Прежде всего нам необходимо общее хранилище, доступ к которому имеют все хосты кластера — у нас на каждом хосте пока только локальные диски.
Общее разделяемое хранилище мы будем строить на iSCSI (как построить его из подручных материалов — здесь), с использованием программного инициатора. Обратим свое внимание на настройку сети ESX хоста.
Очень важно понять особенность работы ESX с сетью. Прежде всего забудьте, что у сетевой карты (порта) может быть IP адрес, его здесь нет. В каждом ESX есть как минимум один виртуальный L2 коммутатор, который создается по умолчанию и называется vSwitch0. Все физические сетевые карты используются только одним способом — служат окном во внешнюю сеть, аплинком. С другой стороны vSwitch’а существуют портгруппы, которые бывают трех типов: Service Console (только для ESX), VMkernel и Virtual Machine Network. Виртуальные машины подключаются к виртуальной сети не напрямую, а в портгруппу типа Virtual Machine Network, причем конкретной портгруппе может быть присвоен VLAN ID, и в этом случае ESX будет разбирать трафик по разным портгруппам в соответствии с VLAN’ами.
Для работы IP Storage (NFS и программного iSCSI) нам требуется специализированная портгруппа типа VMkernel — по сути это специализированный виртуальный интерфейс, который как раз имеет свой собственный IP.
VMkernel сконфигурирован, переходим к подключению iSCSI хранилища.
Подключаем дисковое хранилище ко всем хостам кластера.
И создаем датастор с VMFS на iSCSI LUN.
Нажимаем Finish, ждем чуть-чуть, пока будет создана файловая система. Все хосты автоматически пересканируют свои HBA и подключат новый дастастор. В силу архитектуры VMFS для совместного использования несколькими хостами LUN должен быть презентован всем хостам под одним и тем же LUN ID.
Датастор для машин с требованием высокой доступности уже есть, теперь надо позаботиться о высокой доступности heartbeat сети, в случае ESX это портгруппа Service Console. На сервере установлена двухпортовая сетвая карта, поэтому будем использовать второй порт в качестве резервного. Заходим в свойства vSwitch0:
Как видно, аплинк на коммутаторе один, поэтому сначала добавим второй порт еще одним аплинком. У ESX есть одна очень приятная особенность — при выборе сетевого интерфейса мы видим трафик из какой сети пролетает мимо интерфейса. Это очень удобно, если у нас много сетевых интерфейсов и VLAN’ов, помогает не запутаться какой именно интерфейс нам нужен. Тем не менее, это не гарантированная информация, и не надо паниковать, если интерфейс видит не совсем то, что вы ожидали.
В свойствах vSwitch можно задать политику использования интерфейсов как на уровне vSwitch целиком, так и для каждой из портгрупп, чем мы и воспользуемся. vSwitch будет работать одновременно с двумя интерфейсами.
А вот Service Console получит доступ ко второму порту только если основной для нее, vmnic0, потеряет линк.
Включаем «Override vSwitch failover order», выбираем vmnic1 и перемещаем его в Standby.
На этом предварительная конфигурация закончена и мы можем включить режим HA для кластера. Все, что для этого нужно сделать — поставить одну галочку.
В свойствах кластера:
Настройки HA оставляем по умолчанию.
Создаем первую виртуальную машину в кластере, причем обязательно на разделяемом хранилище, и включаем ее. «HA Advanced Runtime info» покажет нам использование ресурсов (подробное описание — здесь).
***
Строго говоря, следующий материал по конфигурированию VMotion не имеет прямого отношения к HA-кластеру, и приводится лишь для демонстрации легкости конфигурирования.
***
А что нужно сделать, чтобы начала работать живая миграция, VMotion?
Для этого придется совершить поистине титаническое усилие: поставить еще одну галочку. На этот раз в свойствах портгруппы VMkernel — она используется как для IP Storage, так и для VMotion (а в случае ESXi еще и вместо Service Console).
Включить VMotion на интерфейсе VMkernel необходимо, разумеется, на обоих хостах.
Совершим первую живую миграцию ВМ.
Впрочем, можно и просто перетащить мышкой ВМ на хост
В меню миграции есть так же и дисковая миграция — в частности Storage VMotion, прозрачный переезд ВМ на другой датастор без выключения ВМ, но нас интересует смена хоста.
vСenter автоматически проверит все условия, и выдаст результат — можем ли мигрировать машину, и если нет, то почему.
Потерян один пинг, но сессии не разорвались, и работа продолжилась уже на другом хосте.
Антон Жбанков