Главная Virtualization, Без рубрики Конфигурация отказоустойчивого кластера VMware vSphere
  • Конфигурация отказоустойчивого кластера VMware vSphere

    Один из часто задаваемых вопросов – как построить отказоустойчивый кластер 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 автоматически проверит все условия, и выдаст результат – можем ли мигрировать машину, и если нет, то почему.

    Потерян один пинг, но сессии не разорвались, и работа продолжилась уже на другом хосте.

    Антон Жбанков

    http://blog.vadmin.ru

Комментарии

  1. Только я бы добавил, что VMotion собственно к HA отношения не имеет вообще(!!!), и акцентировал на этом внимание.
    ибо очень часто с таким заблуждением сталкиваюсь.

  2. строго не судите я начинающий.
    как поднять кластер если уже на одном esx уже существуют несколько BM а на втором только esx server?.

  3. А это не имеет значения, есть ли ВМ на ESX. Разница лишь в том, что HA будет работать только для машин, расположенных на общем хранилище.
    Выключать уже существующие ВМ или куда-то перемещать для включения хоста в HA кластер необязательно.

  4. спасибо большое!!!
    Значить если на общем хранилище у меня несколько ВМ работают после включение
    хостов (их у меня два) в HA кластер ВМ будут работать как работали!!! Мне это очень важно потому что есть ВМ котрые нельзя останавливать.

  5. Да, будут. Включение хоста в кластер никак не влияет на работающие на нем ВМ.

  6. Спасибо!

  7. А если одна хост-машина “потухнет”. Он переключит ВМ на вторую?
    И что будет когда первая хост-машина заработает, если настроено как в вашем примере?