Высокая доступность виртуальных машин – ЧАСТЬ 1

Обеспечение  высокой  доступности  приложений – одна из важнейших задач ИТ подразделения любой компании.  И требования  к доступности становятся все жестче для все большего круга задач.

Обычно под доступностью понимается  время, в течение которого приложение было доступно. Если приложение не было доступно 3 с половиной  дня за год, то доступность  его была порядка  99%. Если приложение было недоступно  порядка  часа за год, то доступность порядка 99,99% и т. д.

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

Самую высокую  доступность  обеспечат  решения,  встроенные  в само приложение, или кластеры  уровня  приложений между виртуальными машинами  (например,  Microsoft  Failover  Cluster). Следом  идет  VMware  Fault  Tolerance,  обеспечивающий  отличную  защиту, но лишь от сбоев сервера (не гостевой  ОС или приложения). Последним  идет VMware High  Availability,  который  дает наибольшие из этих трех вариантов  простои, зато чрезвычайно прост, дешев и налагает

Высокая доступность виртуальных машин

минимум условий на инфраструктуру и виртуальные машины. Поговорим про все эти решения.

7.1.1. VMware High Availability, HA

VMware High Availability, или кластер высокой доступности VMware, появился еще в третьей  версии  виртуальной инфраструктуры VMware.  C момента  появления это решение  приобрело  дополнительные возможности и лишилось  некоторых недостатков.

Текущая  версия VMware HA умеет делать две вещи:

Q  проверять доступность серверов ESX(i), проверяя доступность их управляющих интерфейсов. Используются сообщения пульса (heartbeat) собственного формата. В случае недоступности какого-то сервера делается попытка запустить работавшие на нем ВМ на других серверах кластера;

Q  проверять доступность  виртуальных машин, отслеживая сигналы пульса

(heartbeat) от VMware  tools. В случае их пропажи  ВМ перезагружается. Отвечающий за эту функцию компонент называется Virtual Machine Monitoring. Этот компонент  включается  отдельно и является необязательным. С недавних пор Virtual  Machine  Monitoring получил  возможность интегрироваться  со  сторонними  решениями,  такими  как  Symantec   ApplicationHA  – и отслеживать статус не только VMware  tools, но и приложений в гостевой ОС.

Для  создания  HA кластера  необходимо  создать объект «Cluster» в иерархии vCenter.  В контекстном меню объекта Datacenter выберите Add new Cluster, укажите имя создаваемого кластера и поставьте флажок HA (не имеет значения, стоит ли флажок DRS). Нажмите ОК.

Итак, кластер как объект vCenter вы создали. Осталось  два шага:

1.    Настроить HA кластер.

2.    Добавить в него серверы ESX(i).

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

Обратите внимание, что при включении HA для кластера или при добавлении сервера  в кластер  с включенным  HA в панели  Recent Tasks появляется задача

«Configuring HA». Проследите,  чтобы эта задача  для  всех серверов  окончилась

успешно. Если это не так, ознакомьтесь с сообщением об ошибке и решите проблему. Скорее всего, в этом вам поможет статья базы знаний  VMware  № 1001596 (http://kb.vmware.com/kb/1001596).

Условия для HA

На серверы и ВМ в кластере HA налагаются  следующие условия  – ВМ должны иметь возможность запуститься на любом из серверов кластера. То есть:

Q  ВМ  должны  быть  расположены на общих  хранилищах,  доступных  всем

серверам;

Q  ВМ должны быть подключены  к группам портов с такими именами, которые есть на всех серверах;

Q  к ВМ не должны  быть подключены  COM/LPT-порты, FDD  и CD-ROM серверов, образы iso и flp с приватных  ресурсов  – то есть все то, что препятствует включению ВМ на другом сервере. Также воспрепятствует перезапуску на другом сервере использование VMDirectPath.

Обратите  внимание,  что условия  HA весьма напоминают  условия  для VMotion (что логично),  но среди них нет условия  на совместимость процессоров. Его нет, потому что в случае HA виртуальные машины перезапускаются на других серверах, а не мигрируют  на горячую. А перезапуститься ВМ может на любом процессоре, в том числе и на процессоре другого производителя.

Также  есть некоторые  ограничения. Если  вы используете vSphere версии  до 4.1, то актуальны  следующие значения:

Q  если в HA кластере до 8 серверов, то на весь кластер не более 160 ВМ;

Q  если в HA кластере больше 9 серверов (максимум 32), то на каждом может быть не больше 40 ВМ.

Это не жестко прописанные ограничения, но настоятельно рекомендуемые.

Однако начиная с версии 4.1 произошли значительные изменения:

Q  серверов в кластере по-прежнему  может быть до 32;

Q  без условий  на количество  серверов в кластере число виртуальных машин на каждом сервере может достигать 320;

Q  всего в кластере может быть до 3000 виртуальных машин.

Эти ограничения (если  эти цифры  можно назвать ограничением) общие для кластеров HA и DRS.

Обратите внимание. 320 виртуальных машин на сервер – это абсолютный максимум. Он не может быть превышен не только в нормально работающей  инфраструк туре, но и после отказа сервера или нескольких – иначе HA не сможет включить все виртуальные машины с отказавших серверов.

Какие настройки доступны для кластера HA

Настройки VMware HA показаны на рис. 7.1.

Host Monitoring Status – если флажок Enable Host Monitoring не стоит, то HA не работает.  Снятие  его пригодится, если вы планируете  какие-то манипуляции с сетью, на которые HA может отреагировать, а вам бы этого не хотелось. Альтернатива снятию данного флажка – снятие флажка VMware HA для кластера (Clus ter  Features), но это повлечет  за собой удаление  агентов  HA с серверов  и сброс настроек.  Это неудобно, если функционал HA нужно восстановить  после завершения манипуляций. Также VMware рекомендует отключать HA снятием флажка  Enable Host Monitoring, когда вы добавляете  группы портов и виртуальные коммутаторы на серверы или помещаете часть серверов в режим обслуживания.

Admission Control – это настройка  резервирования ресурсов на случай сбоя. Вариант  «Allow VMs to be powered  on…» отключает какое-либо  резервирование, то есть HA кластер не ограничивает количество запущенных виртуальных машин. Иначе  – HA будет самостоятельно резервировать какое-то  количество  ресурсов.

Высокая доступность виртуальных машин

Рис. 7.1. Основные настройка кластера HA

Настройка способа  высчитывания необходимого  количества  ресурсов  делается в пункте Admission Control Policy.

Вариант  без резервирования может быть удобнее, потому что вы гарантиро-

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

Admission Control Policy – как именно HA должен обеспечивать резервирование ресурсов. Если мы хотим доверить HA кластеру контроль  за этим и выбрали  Admission Control = «Prevent VMs from being powered  on…», то здесь выбираем один из трех вариантов резервирования ресурсов:

Q  Host failures cluster tolerates – выход из строя какого числа серверов должен пережить кластер. При выборе этого варианта настройки HA следит за тем, чтобы ресурсов всех серверов минус указанное здесь число хватало бы на работу всех ВМ. В подсчете необходимых для этого ресурсов HA оперирует понятием «слот». О том, что это и как считает ресурсы HA, – чуть далее;

Q  Percentage of cluster resources – в этом случае HA просто резервирует указанную долю ресурсов всех серверов. Для расчетов текущего потребления используются настройки reservation каждой  ВМ, или  константы  256 Мб для памяти и 256 МГц для процессора, что больше. Кстати, 100% ресурсов в данном случае – это не физические ресурсы сервера, а ресурсы так называемого «root resource pool», то есть все ресурсы сервера минус зарезервированные гипервизором для себя;

Q  Specify a failover host – указанный сервер является «запаской». На этом сервере нельзя будет включать виртуальные машины – только HA сможет включить  на нем ВМ с отказавших  серверов. На него нельзя будет мигрировать ВМ с помощью VMotion, и DRS не будет мигрировать ВМ на этот сервер. Если включение ВМ на указанном запасном сервере не удалось (например, потому что он сам отказал), то HA будет пытаться  включить  ВМ на прочих серверах.

Обратите  внимание на рис. 7.2.

Рис. 7.2. Информация на закладке Summary для HA кластера

Здесь вы видите три варианта информации с закладки Summary для кластера с включенным HA. Эти три варианта соответствуют трем вариантам настрой ки Admission Control. Строка  Configures failover capacity напоминает о том,

Высокая доступность виртуальных машин

какое значение  вы дали настройке  резервирования ресурсов. В моем примере, сверху вниз:

Q  отказоустойчивость в один сервер настроена и отказоустойчивость в один

сервер есть – на последнее  указывает  Current failover capacity. По нажатии ссылки  Advanced Runtime Info открывается окно с дополнительной информацией по текущему состоянию кластера;

Q  резервирование 25% ресурсов  указано,  а свободно  в данный  момент 88% для процессора и 47% для памяти;

Q  резервным  сервером является сервер esxi2.vm4.ru. Зеленый значок напро-

тив его имени означает, что сервер доступен и на нем нет работающих ВМ. Желтый значок означал бы, что сервер доступен, но на нем есть работающие ВМ. Красный – что сервер недоступен, или агент HA на нем не работает правильно.

Какой из вариантов резервирования ресурсов использовать?

Я бы рекомендовал  или вообще отключить  Admission Control,  или использовать третий вариант резервирования – резервирование конкретного сервера.

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

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