вторник, 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'ах, а еще лучше - подключенных через отдельные сетевые адаптеры, повысит доступность, но в то же время приведет к усложнению конфигурации кластера и потребует дополнительных настроек на сетевом оборудовании.

Все.

пятница, 15 апреля 2011 г.

Опыт проектов виртуализации

Решил поделиться с читателями неким обобщенным опытом, касаемо проектов виртуализации (и не только), снабдив их небольшими байками по теме. Заранее хочу подчеркнуть, что все истории выдуманы, и любое совпадение с реальными персонажами и ситуациями из жизни - чистая случайность.

1) Выбирайте оборудование и ПО, исходя из ваших потребностей.

Часто можно столкнуться с такими перегибами. Клиент покупает полную корзину блейд-серверов с двумя управляющими модулями, ethernet и FC коммутаторами для отказоустойчивости, но при этом "забывает" купить несколько FC кабелей, или же банально не хватает PDU с какими-нибудь розетками типа IEC320 C19 для подключения всех блоков питания, а после подключения, оказывается, что ИБП не тянут.

Или же клиент берет три четырехсокетных сервера, покупает по 4-ре лицензии vSphere Enterprise Plus и Windows Server Datacenter на каждый сервер, хотя никакой функционал Enterprise Plus использовать не планирует, да и виртуальных машин у него всего ~10 на весь кластер. А иногда, бывает, и по одной ВМ на сервер хочет оставить, чтобы "надежнее" и "производительнее".

2) "У нас мало денег, возможно, мы даже не сможем вам заплатить."

Это противоположная крайность (я о ней писал). У инженеров будет прекрасная возможность научиться работать с консолью Windows Server Core, а также научиться подключаться MMC оснасткой Hyper-V Manager с недоменных компьютеров.

Еще пример: раньше у заказчика были 2 сервера с 6-тью 18 ГБ SCSI жесткими дисками, а теперь стал один с 4-мя ВМ на нескольких 1 ТБ SATA дисках. Все работает и не тормозит... почти.

3) Смотреть HCL нужно до покупки оборудования.

Об этом случае я тоже рассказывал. Клиент купил FC библиотеку, надо бы подключить к серверу резервного копирования. А он, оказывается, в ВМ на VMware.

4) Не все, что работает - поддерживается, не все, что поддерживается - работает.

У заказчика на виртуальном сервере один из разделов зашифрован с помощью Secret Disk. Для работы данного ПО требуется USB ключ защиты Aladdin, который предусмотрительно "проброшен" в ВМ с помощью соответствующей функции (даже галочка для поддержки работы с vMotion стоит). Требуется перенести диски ВМ с одного хранилища на другое без простоя. Нам поможет Storage vMotion. Алле-оп! USB ключ после переноса остается, Secret Disk отваливается из-за его отсутствия.

5) Это не баг, это фича/by design.

Например, совсем недавно столкнулся с особенностями работы блейд-коммутаторов Brocade, которые после собственной перезагрузки не отображают WWN HBA серверов, на которых установлен VMware ESXi. И чтобы это исправить, нужно сами серверы перезагрузить.

6) Середина проекта - отличный способ начать всё сначала.

Проект по внедрению виртуализации на базе Microsoft Hyper-V. Все машины развернуты, AD поднята, Exchange установлен, почтовые ящики смигрированы, файловые папки перетащены. В какой-то момент выясняется, что Failover Cluster просто не отрабатывает (это не камень в огород Microsoft, просто так было). Недолгая переписка с поддержкой результатов не дала, а сроки и так были сорваны. Волевое решение - переход на VMware ESX. Два выходных дня и все виртуальные машины сконвертированы. А дизайн-проект и прочую документацию всегда можно переписать.

7) Нет ничего более постоянного, чем временное.

Предположим, вы с коллегой монтируете сервер и подключаете его разными кабелями:

(Вы): -Давай прикрутим этот прекрасный HP Cable Management Arm?
(Он): -Ой, так ломает, тут такая путаница в проводах, давай, я чуть попозже прикручу.
(прошло 2 месяца...)


Поэтому, например, чем дольше идет проект, тем меньше шансов обновить firmware для СХД или для одного из серверов.

8) Бумажка с паролями.

Мало у кого из клиентов инфраструктура подробно документирована. Часто он и сам не знает, что-какой сервер делает, особенно если предыдущий администратор уволился и толком дела никому не передал.

Нередки случаи, когда "базы у нас хранятся вот на этой СХД, но пароля от нее я не помню".

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

9) Приёмо-сдаточные испытания - прекрасный способ еще раз "обработать напильником".

Наверняка все так или иначе с этим сталкивались. Заказчик принимает систему, инженер исполнителя проверяет чек-лист, выполняя заранее описанные действия, и демонстрируя ожидаемый результат, вроде: "Проверить журнал событий и убедиться в отсутствии ошибок... Так, проверяем... ошибок не... есть." Дальше следует разбор полетов с судорожной попыткой инженера если уж не решить проблему, то придумать правдивую отмазку. Самый тяжелый случай был, когда в результате запуска и проверки работы одного из бизнес-приложений, описанного в требованиях в ТЗ, сервер просто уходил в перезагрузку... на глазах у заказчика.

10) Законы Мёрфи работают.

Пару раз были случаи, когда система ломалась или серверы зависали на следующий день (в одном из проектов буквально), после приёмо-сдаточных испытаний и подписания акта выполненных работ.

Купил один клиент MSA 2000i с двумя контроллерами, каждый к своему коммутатору подключен, оба блока питания запитаны от двух разных ИБП. Отдельный диск под hot spare. Сломалась эта MSA. Просто так.

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

Что хранится в базе VMware Guided Consolidation?

Многим из вас должно быть известно, что у VMware существует продукт, предназначенный для малого и среднего бизнеса, который позволяет автоматизировать процесс планирования, анализа и миграции физических серверов в виртуальную среду - VMware Guided Consolidation.


В различных книгах и руководствах по vSphere написано, что Guided Consolidation собирает и хранит большое количество параметров и счетчиков производительности серверов, однако, непосредственно из консоли vSphere Client администраторам доступно не так уж много информации.

Вдобавок, Guided Consolidation не имеет встроенных средств для формирования отчетов в отличии от того же Microsoft Assessment & Planning Toolkit.

Так что же именно собирает и хранит Guided Consolidation?

Для хранения базы Guided Consolidation использует формат Firebird. Сам файл с данными Collector.FDB размещается в папке '%programfiles%\VMware\Infrastructure\Guided Consolidation Server\Data'.

Для препарирования базы вы можете использовать Firebird ISQL Tool, который можно загрузить в составе дистрибутива с сайта разработчиков Firebird. Однако гораздо удобнее использовать для этих целей какой-нибудь сторонний инструментарий вроде RazorSQL.

Для подключения к файлу базы с помощью Firebird ISQL Tool используется следующая команда (перед подключением не забудьте скопировать базу во временную папку):
CONNECT <ПУТЬ_К_БАЗЕ> user "SYSDBA" password "masterkey";


Все данные, собираемые Guided Consolidation, хранятся в нескольких десятках таблиц.

Например, из таблицы PERF_HOUR_SUMMARY видно, что Guided Consolidation каждый час сохраняет в базе максимальное и минимально значение счетчиков загрузки процессора (в %) и свободной памяти (в байтах) для всех обследуемых серверов.

Кроме того, в базе хранятся и другие параметры (модель и частота процессора, объем оперативной памяти, свободное место на дисках и т.д.), которые можно найти в соответствующих таблицах "DESС_" или "INV_".
Остается неясным, насколько все эти данные важны при составлении Guided Consolidation рейтинга оптимальных хостов для размещения конвертированных ВМ. Возможно, что это просто 'хвосты', оставленные от старшего брата - Capacity Planner.