HA (High Available) кластер VMware vSphere на блейд-серверах HP BL460c и EVA

VMWare

В vSphere 6.5 появилась встроенная возможность организации отказоустойчивого сервера vCenter High Availability (VCHA). Архитектурно решение VCHA реализации за счет создания пассивной копии сервера vCenter, которая выполняется на другом узле ESXi, чем обеспечивается высокая доступность экземпляра vCenter при аппаратных или программных проблемах.

Содержание:Архитектура высокой доступности сервера VMWare vCenter 6.5</li>Настройка высокой доступности vCenter</li></ul>

Архитектура высокой доступности сервера VMWare vCenter 6.5

Архитектура отказоустойчивого VCHA состоит из 3 узлов: активного, пассивного экземпляра vCenter Server Appliance и хоста-свидетеля. Активный экземпляр vCenter Appliance имеет два сетевых интерфейса: стандартный интерфейс управления (eth0) и специальный интерфейс HA (eth1). VCHA реплицирует данные с активной ноды на пассивную по HA сети. База данных активной копии vCenter реплицируется в синхронном режиме, а файловая система – в асинхронном. У пассивной копии также 2 сетевых интерфейса, однако основной его интерфейс eth0 с теми же FQDN, IP и MAC неактивен. Интерфейс активируется в случае сбоя основного экземпляра сервера vCenter. Свидетель является последним элементом архитектуры VCHA. Он используется для предоставления ресурса-кворума, информируя кластер о том, какой из узлов является активным в текущий момент времени. В нормальном режиме работы все три компонента кластера должны быть доступны.

При сбое, на пассивной ноде активируется интерфейса eth0. С помощью механизма Gratuitous ARP выполняется оповещение устройств в широковещательном домене о появлении новой привязки IP и MAC. Если оригинальная нода после сбоя опять появляется в сети, она снова становится активной и репликация восстанавливается. В том случае, если он полностью утрачена, ее можно удалить из конфигурации и пересоздать кластер VCHA.

Что потребуется для организации высокодоступного сервера vCenter

• vCenter Server Appliance версии 6.5
  • Лицензия vCenter Standard
  • Размер развертывания vCSA: Small, Medium или Large (но не tiny)
  • Встроенный или внешний Platform Services Controller (PSC)
• ESXi 5.5 и выше
  • Рекомендуется использовать как минимум 3 хоста
• Сеть vCenter HA
  • Отдельная HA сеть, отделенная от сети управления
  • Сетевая задержка между двумя узлами не более 10мс
  • Статические IP адреса на нодах

Настройка высокой доступности vCenter

Настройку HA для vCenter следует начать с создания новой отдельной HA сети. В нашем примере мы добавим группу портов HA в существующий виртуальный коммутатор. Т.к. мы используем стандартные виртуальные коммутаторы, группа портов HA добавится на 3 хостах.

После создания сети, щелкните ПКМ по серверу vCenter Server в разделе навигации клиента vSphere Web Client. В меню выберите vCenter HA Settings.

В меню vCenter HA нажмите на кнопку Configure в правом верхнем углу.

Есть два варианта настройка HA.

• Basic – автоматическое клонирование сервера и настройка всех трех узлов
• Advanced – настраиваемый вариант развёртывания, клонирование сервера и настройка узлов кластера выполняется в ручном режиме.

Мы остановился на самом простом — автоматическом варианте Basic.

Укажем IP адрес и подсеть для HA интерфейса на активной ноде. В качестве сети нужно выбрать созданную ранее выделенную сеть HA.

Укажите IP адрес пассивной (Passive) ноды и свидетеля (Witness).

Проверьте предложенный вариант развертывания. Внесите необходимые изменения, выбрав хост, кластер и VMFS хранилище.

Если все ОК, нажмите кнопку Finish для начала развертывания.

Запустите процесс клонирования и автоматической настройки трех узлов. Процесс выполнения развертывания можно отслеживать в разделе Recent Tasks.

После завершения развертывания в иерархии vCenter появятся два новых узла. Как вы видите, для пассивной копии vCenter добавлена постфикс –peer , а для свидетеля –witness.

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

Один из часто задаваемых вопросов – как построить отказоустойчивый кластер vSphere? На самом деле это очень просто, компания VMware прилагает огромные усилия к тому, чтобы конфигурирование ее продуктов и управление ими не занимали слишком много времени и сил у администраторов, и не требовалось запоминать трехэтажные комбинации команд. В частности создание кластерной файловой системы занимает буквально два-три клика мышкой, а дальше она автоматически подключается ко всем хостам, у которых есть доступ к соответствующему дисковому массиву.

Предполагается, что уже установлен vCenter Server и 2 ESX сервера, заданы IP адреса управляющих консолей и более ничего. Подключаемся к vCenter при помощи vSphere Client (его можно скачать с https://).

Корневым элементом инфраструктуры 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

• Рубрика:Virtualization,Без рубрики
• Автор: Anton Zhbankov
• Дата: Tuesday 01 Jun 2010

Практическим применением знаний о работе с массивами EVA и iLO в серверах ProLiant, которые вы получили чуть раньше, может стать развертывание высокодоступного кластера на vSphere. Кластер может использоваться для предприятий среднего и крупного размера, чтобы уменьшить время внеплановых простоев. Поскольку для бизнеса важны такие параметры как доступность его сервиса или услуги клиенту в режиме 24×7, то такое решение основывается на кластере высокой доступности. В кластер всегда входят как минимум 2 сервера. В нашем решении серверы под управлением VMware отслеживают состояние друг друга, при этом в каждый момент времени ведущим будет только один из них, на нем будет разворачиваться виртальная машина с нашим бизнес-приложением. В случае отказа ведущего сервера его роль автоматически принимает второй, при этом для заказчика доступ к бизнес-приложению практически не прерывается.

1. Описание задачи

В данном примере мы опишем процесс создания высокодоступного кластера VMware на блейд-серверах BL460c G7. Оборудование состоит из блейд-корзины HP c7000 и двух блейд-серверов BL460c G7, где скофигурирован VMware HA(High Available)-кластер. В демо-центре HP в Москве сейчас доступны только модели блейд-серверов G7, но на основе описанного примера можно собрать кластер и на новых блейд-серверах Gen8. Конфигурирование, в целом, не будет различаться. Система хранения – HP EVA 4400. Для Ethernet и Fibre Channel подключений в корзине c7000 установлены 2 модуля HP Virtual Connect Flex Fabric в отсеках 1 и 2.

2. Описание компонентов

Virtual Connect FlexFabric — конвергентный виртуализированный модуль ввода/вывода для блейд-корзины с7000. Модуль HP Virtual Connect FlexFabric использует технологии Flex-10, FCoE, Accelerated iSCSI для коммутации блейд-серверов и сетевой инфраструктуры (SAN и LAN) со скоростью 10Gb. Из возможностей: перенос «профилей» (таблица MAC и WWN серверов) не только между разными лезвиями в шасси, но и на удалённые сайты, где есть такой же блейд-сервер. Так же при использовании Virtual Connect каждый из двух портов сетевой карты блейд-сервера можно делить на 4 виртуальных порта 1GbE/10GbE/8Gb FC/iSCSI общей пропускной способностью 10GbE на порт. Это позволяет получить от 8 виртуальных портов на сервер (на BL460с G7), которые необходимо задавать при первой инициализации. Единственное ограничение в том, что HP Virtual Connect FlexFabric не являются полноценными коммутаторами. Это аггрегаторы, для работы которых необходимо иметь отдельные Ethernet- и SAN-свитчи (в последней прошивке, правда, появилась возможность Direct Connect с HP P10000 3PAR). Общий вид использованного оборудования отражается в Onboard Administrator. Интегрированная в ProLiant BL460c G7 карта NC553i Dual Port FlexFabric 10Gb может работать с модулями HP Virtual Connect FlexFabric напрямую, без дополнительных мезонин-карт. Два модуля HP Virtual Connect FlexFabric установлены для отказоустойчивости путей связи связи блейд-серверов с системой хранения EVA 4400 и Ethernet-коммутаторами. В данном примере будем рассматривать сценарий, когда трафик от модуля HP Virtual Connect FlexFabric разделяется на Ethernet-коммутаторы и FC-фабрику. FCoE в этом случае используется для коммутации модулей с блейд-серверами внутри корзины. Для работы с различными протоколами модулям HP Virtual Connect FlexFabric необходимы трансиверы. В этом примере 4 Gb FC SFP трансиверы были установлены в порты 1 и 2 на каждом из модулей, а 10 Gb SFP+ трансиверы были установлены в порты 4 и 5. 10GbE-каналы использованы в данном тесте чтобы задействовать сетевое оборудование в нашем демо-центре. Диаграмма показывает, что 3 порта сетевого адаптера NC553i Dual Port FlexFabric 10Gb сконфигурированы как FlexNIC для взаимодействия виртуальных машин между собой и для подключения к сетевой инфраструктуре. Оставшийся порт был сконфигурирован как FCoE для связи с SAN-инфраструктурой и системой хранения EVA 4400. Вместе с каждым Virtual Connect модулем поставляется ПО для управления HP Virtual Connect Manager, для Enterprise модулей – HP Virtual Connect Enterprise Manager. С помощью Enterprise Manager можно управлять из одной консоли до 256 доменами (1 домен — 4 Blade системы с Virtual Connect). После подключения модуля необходимо его сконфигурировать. Делается это либо подключением к Onboard Administrator самой корзины, либо по IP-адресу, который назначается модулю по умолчанию на заводе.

3. Настройка профилей в Virtual Connect Manager

После подключения HP FlexFabric мы должны определить домен, Ethernet-сеть, SAN-фабрику и серверные профили для хостов. Эти настройки производятся в HP Virtual Connect Manager или в командной строке. В нашем примере домен уже был создан, поэтому следующим шагом будет определение VC Sharing Uplink Sets для поддержки Ethernet сетей виртуальных машин с именами HTC-77-A и HTC-77-B. Включаем “Map VLAN tags” функцию в мастере установки. Функция “Map VLAN tags” дает возможность использовать один физический интерфейс для работы с множеством сетей, используя Shared Uplink Set. Таким образом можно настроить множество VLANs на интерфейсе сетевой карты сервера. Параметры Shared Uplink Sets были заданы в мастере установки VCM. Пример задания SUS: Обе сети «HTC-77-A» и «HTC-MGMT-A» были назначены: VLAN_Uplink_1 на порт 5 модуля 1; второй Shared Uplink Set (VLAN_Uplink_2) был назначен на порт 5 модуля 2, и включает в себя сети HTC-77-B (VLAN 20) и HTC-MGMT-B (VLAN 21). Пример создания сетей Ethernet в VCM: Модуль HP Virtual Connect может создавать внутренную сеть без аплинков, используя высокопроизводительные 10Gb соединения с бэкплейном корзины с7000. Внутренняя сеть может быть использована для VMware vMotion, а также для организации отказоустойчивости сети. Трафик этой сети не выходит на внешние порты корзины c7000. В нашем случае были настроены 2 сети VMware vMotion. Для консоли управления были настроены две сети с именами HP-MGMT-A и HP-MGMT-B. Порт 6 модулей HP Virtual Connect FlexFabric в отсетках 1 и 2 был использован для подключения к консоли управления. После этого начинается настройка фабрики SAN. Все довольно просто: в VCM выбрать Define – SAN Fabric. Выбираем SAN-1 модуль в отсеке 1, порт X1. Для второго модуля SAN-2 порт также X1. Пример настройки SAN: Последним шагом будет «склеивание» всех ранее сделанных настроек в серверный профиль. Это можно сделать несколькими способами: например, через web-интерфейс VCM или через командную строку Virtual Connect – Virtual Connect Scripting Utility (VCSU). Перед установкой ОС необходимо проверить, что все системные, NIC и FC драйверы обновлены, а все параметры сети заданы. Пример создания профиля в CVM: В VCM выбираем Define – Server Profile, вводим имя профиля и выбираем сетевые подключения профиля из созданных ранее. В нашем случае все порты были назначены нами заранее: 6 Ethernet портов и 2 SAN порта на каждый профиль. Профили для отсека 11 и 12 идентичны, т.е. каждый сервер видит один и тот же набор портов. Суммарная скорость не превышает 10Гб/с на каждый порт сетевой карты сервера. Если в будущем планируется расширение сети, то рекомендуется назначить нераспределенные (unassigned) порты в профиле. Делая так, можно в дальнейшем активировать эти порты без выключения и перезагрузки сервера. При создании профиля по умолчанию доступны только 2 порта в разделе Ethernet. Чтобы добавить больше, необходимо вызвать контекстное меню правой кнопкой мыши и выбрать “Add connection”. Назначаем скорость для каждого типа портов: портам управления – 500Mb/s, портам vMotion – 1Gb/s, портам SAN – 4Gb/s и портам виртуальных машин – 4.5Gb/s. После создания профилей они привязываются к блейд-отсеку корзины в этом же меню.

4. Настройка кластера VMware

На этом настройки корзины завершены. Далее происходит удаленное подключение к самим блейдам и разворачивание VMware ESX 5.0, пример удаленной установки ОС на серверы ProLiant через iLO уже был описан. В нашем случае вместо Windows в выпадающем меню установщика выбирается VMware и указывается путь к дистрибутиву. После установки сервер перезагружается и можно приступать к настройке виртуальных машин. Для этого подключаемся к серверу ESX. Заходим в раздел Configuration, создаем 6 vmnics на каждый хост, как и в модуле Virtual Connect: Service Console (vSwitch0), VM Network (vSwitch1), vMotion (vSwitch2). Таким образом мы получаем отказоустойчивую конфигурацию, где каждой сети соответствую 2 vmnics. Как только добавляются vmnics можно заметить, что каждому адаптеру автоматически задается скорость, заданная в серверном профиле, при конфигурации в Virtual Connect Manager. После добавления vmnics объединяем их в группу с помощью vSwitch: вкладка Port – в поле Configuration выбираем vSwitch – Edit, выбираем NIC Teaming, убеждаемся, что оба vmnics видны. Балансировку нагрузки выбираем «Route based on the originating virtual port ID» — эти настройки рекомендуется ставить по умолчанию (подробнее об этом методе можно прочесть на сайте VMware.

5. Настройка дискового массива EVA 4400

В предыдущем обзоре было рассказано как работать с интерфейсом управления дисковыми массивами EVA — Command View. В данном примере мы создаем LUN размером в 500 ГБ, который разделяется между двумя хостами виртуальных машин. По описанному в предыдущей статье методу создается виртуальный диск и презентуется двум хостам ESX. Размер LUN определяется типом ОС и ролями, которые данный кластер будет выполнять. Обязательным условием для кластера (в частности, для VMware vMotion) – LUN должен быть разделяемым. Новый LUN должен быть отформатирован в VMFS, и функция Raw Device mappings (RDMs) для виртуальных машин должна быть задействована.

6. Внедрение VMware HA и VMware vMotion

HP Virtual Connect в сочетании с VMware vMotion дает тот же уровень избыточности, как при использовании двух модулей VC-FC и двух модулей VC-Eth, за исключением того, что только 2 модуля HP FlexFabric необходимы. HP Virtual Connect FlexFabric дает возможность организовать отказоустойчивые пути к общему LUN и отказоустойчивого объединения сетевых интерфейсов (NIC Teaming) для работы в сети. Все настройки VMware vSphere отвечают Best Practices описанным в документе. Была проведена проверка на доступность кластера. На одном из хостов была развернута виртуальная машина Windows 2008 Server R2. Виртуальная машина вручную несколько раз была смигрирована с одного сервера на другой, во время мигации кластер оставался доступным. Схема кластера: HTC DC – наш DC, Demo-FlexFabric Cluster – наш кластер, Demo-ESX1 и Demo-ESX2 – хосты VMware, vmhba2 – SAS контроллеры блейд-серверов, подключенные к внутренней дисковой подсистеме. Vmhba0 и vmhba1 – два порта встроенных сетевых карт NC553i Dual Port FlexFabric 10Gb Adapter, подключенных к разделяемому LUN EVA 4400. Demo-VM-W2K8R2-01 – виртуальная машина.Литература: 1. HP Blade Server BL460c Gen8 2. HP Virtual Connect FlexFabric 3. Deploying a VMware vSphere HA Cluster with HP Virtual Connect FlexFabric 4. VMware Best Practices vSphere 5.0 5. VMware Virtual Networking ConceptsИспользуемые источники:

• https://vmblog.ru/nastrojka-vysokoj-dostupnosti-ha-dlya-vmware-vcenter-6-5/
• http://itband.ru/2010/06/vsphere-ha-cluste/
• https://habr.com/company/hp/blog/145859/