Один из часто задаваемых вопросов – как построить отказоустойчивый кластер 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 автоматически проверит все условия, и выдаст результат – можем ли мигрировать машину, и если нет, то почему.
Потерян один пинг, но сессии не разорвались, и работа продолжилась уже на другом хосте.
Антон Жбанков
Только я бы добавил, что VMotion собственно к HA отношения не имеет вообще(!!!), и акцентировал на этом внимание.
ибо очень часто с таким заблуждением сталкиваюсь.
строго не судите я начинающий.
как поднять кластер если уже на одном esx уже существуют несколько BM а на втором только esx server?.
А это не имеет значения, есть ли ВМ на ESX. Разница лишь в том, что HA будет работать только для машин, расположенных на общем хранилище.
Выключать уже существующие ВМ или куда-то перемещать для включения хоста в HA кластер необязательно.
спасибо большое!!!
Значить если на общем хранилище у меня несколько ВМ работают после включение
хостов (их у меня два) в HA кластер ВМ будут работать как работали!!! Мне это очень важно потому что есть ВМ котрые нельзя останавливать.
Да, будут. Включение хоста в кластер никак не влияет на работающие на нем ВМ.
1
Спасибо!
А если одна хост-машина “потухнет”. Он переключит ВМ на вторую?
И что будет когда первая хост-машина заработает, если настроено как в вашем примере?