вторник, 26 апреля 2011 г.

VMware High Availability и проверка изоляции

Одной из функций высокодоступного кластера VMware является механизм проверки изоляции, который запускается, если сервер в течение некоторого времени (по умолчанию 12 секунд) не получает heartbeat сигналов от других членов кластера.

Изоляция возникает из-за ошибок конфигурирования оборудования или сбоя в работе сегмента сети, и может повлечь недоступность виртуальных машин.

Для определения изоляции узел посылает echo-запрос на специальные IP-адреса (isolation address).

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

По умолчанию в качестве адреса для проверки изоляции используется маршрутизатор по умолчанию.


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

С другой стороны, использование маршрутизатора по умолчанию в качестве адреса для проверки изоляции не является хорошей идеей, поскольку в небольших компаниях в качестве маршрутизатора может использоваться, например, ISA Server, развернутый в виртуальной машине. Это может привести к ситуации, когда сервер ESXi будет успешно пересылать пакеты любой из запущенных на нем ВМ (в пределах одного виртуального коммутатора), хотя в действительности окажется изолированным от физической сети.

Наконец, в ряде случаев, возможно и ложное срабатывание, когда все узлы кластера, подключенные к одному коммутатору, из-за кратковременной недоступности сети посчитают себя изолированными и остановят свои виртуальные машины.

Для предотвращения этой ситуации следует, во-первых, дублировать сетевое оборудование, во вторых, добавить проверку дополнительных адресов, прописав в Advanced Options настройках HA кластера параметры das.isolationaddress и/или das.isolationaddress{n}.

Первый параметр позволяет задать один дополнительный адрес для проверки изоляции, второй, точнее остальные - до десяти дополнительных адресов (в различных документах описывается, что параметры должны иметь значение das.isolationaddress1, das.isolationaddress2, ... das.isolationaddress10, хотя на практике мне удавалось задать и das.isolationaddress0; номер в названии параметра влияет на очередность при проверке).

Теоретически, у вас может быть до 11 дополнительных адресов для проверки изоляции. Только это вовсе не означает, что вам нужно задавать их все, поскольку проверка узлом каждого дополнительного адреса занимает 1 секунду, следовательно, реакция узла на изоляцию последует позже, что в свою очередь увеличит время, необходимое на перезапуск ВМ на других узлах.

Также для предотвращения ложного срабатывания можно задать параметр das.failuredetectiontime (по умолчанию используется значение 15000 миллисекунд), влияющий на время, в течение которого узлы будут пытаться отправлять друг-другу heartbeat'ы, до того как начать проверку на изоляцию.

Важно отметить, что использование параметров das.isolationaddress не отменяет маршрутизатор по умолчанию в качестве адреса для проверки изоляции. Чтобы не использовать маршрутизатор для проверки вам потребуется добавить параметр "das.usedefaultisolationaddress = false".

Учтите, что для изменения настроек уже существующего кластера, то вам потребуется отключить, а затем снова включить HA кластер, что приведет к повторной установке HA агентов на всех узлах.

Для проверки изоляции не обязательно использовать адреса в той же подсети, в которой расположены VMKernel интерфейсы, однако это будет крайне разумным решением. И вот почему.

Если для хранения виртуальных машин вы используете iSCSI или NFS хранилище, то в качестве адреса для проверки изоляции рекомендуется указывать один из интерфейсов хранилища. Это позволит избежать ситуации, когда из-за сетевой изоляции у ВМ пропадает доступ к виртуальным дискам, и сервер виртуализации держит их включенными, вместо того, чтобы остановить.

Однако с этим решением связан один важный момент. При добавлении узла в кластер требуется, чтобы все указанные адреса для проверки изоляции были доступны. Если хотя бы один из адресов недоступен, вы получите сообщение об ошибке: "Could not reach isolation address".

Проблема заключается в том, что echo-запрос отправляется с любого "ближайшего" VMKernel интерфейса (например, с интерфейса из той же подсети, где находится адрес для проверки изоляции), а не с того, который настроен для передачи управляющего трафика (Management traffic).

Наглядно эту ситуацию демонстрирует следующая картинка.

В данном примере IP адрес 10.0.0.4 соответствует VMKernel интерфейсу, на котором включен management traffic, а 10.0.1.4 - интерфейсу VMKernel, который используется только для передачи iSCSI трафика (адрес 10.0.0.254 соответствует маршрутизатору по умолчанию, 10.0.1.1 - хранилищу iSCSI). В момент проверки узла на изоляцию наблюдается следующее.

VMKernel пытается отправить echo-запрос на адрес 10.0.1.1 уже не с адреса 10.0.1.4, как делал это при создании кластера, а с 10.0.0.4. И если у вас не настроена маршрутизация между подсетями, то смысл в дополнительном адресе для проверки изоляции теряется.

Один последний момент, который я хотел рассмотреть - обеспечение избыточности для управляющих интерфейсов (Management Network) серверов ESXi. Управляющие интерфейсы используются узлами HA кластера для отправки heartbeat пакетов, согласования изменений в конфигурации и проверки изоляции.

По умолчанию, если вы создаете HA кластер, используя всего один управляющий интерфейс и один сетевой адаптер, то увидите следующее предупреждение.

Избыточность для управляющего трафика может достигаться двумя способами:
  • Подключение дополнительных сетевых адаптеров к управляющему интерфейсу.
  • Создание дополнительных VMKernel интерфейсов и назначение на них функции передачи управляющего трафика (Management traffic).
С первым вариантом все просто - добавили в vSwitch второй (третий, четвертый...) адаптер и переопределили на уровне VMKernel порядок их использования (рекомендуется настроить один из адаптеров как Active, остальные - Standby).
Данный вариант обеспечит защиту от сбоев оборудования: сгоревшего порта, сетевой карты, коммутатора (если они дублированы) или отключенного кабеля, однако не поможет в случае ошибок в конфигурации VLAN'ов, неправильным назначением сетевых настроек, ARP или IP spoofing'е и т.п.

Создание дополнительных управляющих VMKernel интерфейсов в отдельных VLAN'ах, а еще лучше - подключенных через отдельные сетевые адаптеры, повысит доступность, но в то же время приведет к усложнению конфигурации кластера и потребует дополнительных настроек на сетевом оборудовании.

Все.

Комментариев нет:

Отправить комментарий