Кластер Майкрософт представляет собой группу независимых серверов работающих совместно, на которых запущена служба Microsoft Cluster Service (MSCS). Тем самым обеспечивается высокая надежность, быстрое восстановление после сбоев и масштабируемость, упрощается управление ресурсами и приложениями. Кластер из нескольких серверов позволяет клиентам получить доступ к ресурсам и при выходе из строя одного из серверов или при необходимости планового выключения, ресурсы и приложения запускаются на другом доступном сервере из кластера, таким образом, достигается почти бесперебойная работа.
Приложения, использующие кластеризацию
Для того чтобы воспользоваться преимуществами кластерных решений необходимо использовать приложения, специально разработанные под кластеризацию. При использовании приложений такого типа в случае сбоя пользователи будут продолжать работу, в то время как приложение будет перезапущено на другом хосте. В основном это следующие приложения:
Приложения, не сохраняющие предыдущее состояние, такие как Web и VPN сервера.
Приложения, которые имеют встроенные возможности восстановления, такие как базы данных, почтовые и файловые сервера.
Кластерное ПО
На текущий момент ПО для кластеризации виртуальных машин разрабатывается различными вендорами, но компания VMware протестировала и гарантирует работу только кластера на основе Microsoft Cluster Service (MSCS). MSCS предоставляет возможность восстановления работы для таких приложений как сервера баз данных, почтовые и файловые сервера.
В данной статье рассматривается только традиционная «горячая» кластеризация с использованием службы Microsoft Cluster Service. VMware также поддерживает «холодную» кластеризацию - VMware HA, с использованием кластеров VirtualCenter. Особенности кластеризации на основе VMware HA, а также различия между двумя подходами рассматриваются в документе Resource Management Guide.
Особенности настройки аппаратной части
Настройка дисков с общим доступом. В основном такие диски используют приложения, работающие с динамически меняющимися данными, например, почтовые сервера и сервера баз данных. Диски с общим доступом должны располагаться в SAN, использующим Fibre Channel.
Настройка дополнительных сетевых подключений между узлами для мониторинга состояния узлов.
Необходимость использования кластеров в виртуализации
Из-за роста датацентров, сервер управления VirtualCenter становится критическим компонентом виртуальной инфраструктуры, и бесперебойная работа служб VirtualCenter является одним из важнейших факторов непрерывной работы ЦОД. В таблице 1 приведены основные последствия в случае выхода из строя VirtualCenter.
Таблица 1- Последствия отказа VirtualCenter.
Компонент
Последствия остановки VirtualCenter
Виртуальные машины
Не затронуты, управление осуществляется через прямое соединение с ESX.
ESX хосты
Не затронуты, управление осуществляется через прямое соединение с ESX.
Статистика производительности и мониторинга
Записи будут содержать разрывы в моменты не доступности VC, но доступны на ESX.
VMotion
Недоступен
VMware DRS
Недоступен
VMware HA
Агенты на ESX продолжают работу, обеспечивая отказоустойчивость, но состояние доступности серверов перестает обновляться. Admission control недоступен.
Основные модели конфигурации кластеров
Для того чтобы понять какие модели построения кластеров существуют, введем понятие кластерная модель. Кластерная модель или конфигурация дает понятие о том, как в кластере используется кворум ресурс. Для бесперебойной работы кластеру необходим так называемый кворум ресурс, который содержит все конфигурационные данные, необходимые для восстановления кластера. База данных кластера, размещается в реестре Windows Server 2003 на каждом хосте кластера и содержит информацию обо всех физических и логических элементах кластера, включая объекты кластера, их свойства и настройки. Когда один из хостов кластера выходит из строя, а затем вновь начинает работать, другие узлы кластера обновляют базу отказавшего хоста. Кворум ресурс позволяет кластерной службе поддерживать базу данных кластера в состоянии актуальном на последний момент.
Кворум ресурс, как и любой другой ресурс, используется только одним узлом в текущий момент времени. Узел находится в кластере только в том случае, если он может получить доступ к кворум ресурсу. Также узел может стать узлом кластера (или оставаться в уже существующем кластере), если он может взаимодействовать с узлом, который контролирует кворум ресурс.
Для кластеризации сервера VirtualCenter используется две конфигурации:
Кластер на основе кворум диска
Кластер на основе набора узлов большинства (MNS)
Универсальной рекомендации по выбору одной или другой конфигурации не существует. Выбор делается исходя из основных факторов, таких как доступность ресурсов – например, совместимое оборудование систем хранения, SAN – а также ограничения инфраструктуры, такие как расстояние между узлами кластера.
Кластер на основе кворум диска
Конфигурация кластера на основе кворум диска представлена на Рисунке – 1. В данной конфигурации к одному кворум диску по SAN подключаются два хоста кластера. Такую конфигурацию целесообразно применять при расположении хостов, подключенных по Fibre Channel, на небольшом расстоянии. Помните, что если вы включаете в кластер виртуальные машины, то должны соблюдать определенные требования, включающие в себя требования к системам хранения данных и сетевым подключениям.
Рисунок 1 - Кластер серверов VirtualCenter на основе кворум диска
Кластер на основе набора узлов большинства
Вторая конфигурация представлена на рисунке 2 - кластер на основе набора узлов большинства (MNS) со свидетелем общего файлового ресурса. Данная конфигурация является наиболее приемлемой для удаленных узлов и предлагается в качестве наиболее используемых. Кворум ресурс в данном случае, это общий файловый ресурс на выделенном сервере. Данный сервер не входит в кластер и на нем не установлены службы VirtualCenter. Выбор данного сервера зависит от многих факторов, но все же, идеальным кандидатом является сервер, на котором установлена база VirtualCenter. Поскольку этот сервер выполняет очень важную роль в функционировании VirtualCenter, рекомендуется создать для данного сервера отдельный кластер, чтобы быть уверенным, что сервер-свидетель общего файлового ресурса также защищен от сбоев. Другой вариант разместить сервер-свидетель на виртуальной машине и использовать механизм VMware HA, чтобы избежать риска сбоя аппаратной части. Основной недостаток данного подхода состоит в том, что используются три хоста и допускается отказ только одного хоста из кластера.
Рисунок 2 - Кластер на основе набора узлов большинства (MNS) со свидетелем общего файлового ресурса.
Сценарии кластеризации виртуальных машин
Службы кластеризации и виртуальные машины
Использование служб кластеризации на виртуальных машинах обеспечивает их высокую доступность с применением меньшего количества аппаратных ресурсов (физические машины и сетевые адаптеры). Существует несколько сценариев кластеризации виртуальных машин:
Создание кластера виртуальных машин на выделенном хосте (Cluster in a Box)
Создание кластера виртуальных машин на нескольких физических серверах (Cluster Across Boxes)
Создание кластера физических и виртуальных машин (Standby Host)
Создание кластера виртуальных машин на выделенном хосте (Cluster in a Box)
Cluster in a Box - кластер состоящий из двух виртуальный машин, расположенных на одном хосте ESX и подключенных к одному хранилищу (локальному или удаленному). Данный сценарий обеспечивает простую кластеризацию и позволяет избежать ошибок в ПО или администрировании, а также сбоев в работе операционных систем.
Рисунок 3 - Кластеры виртуальных машин на выделенном хосте
Создание кластера виртуальных машин на нескольких физических серверах (Cluster Across Boxes)
Cluster Across Boxes – кластер, состоящий из виртуальных машин, которые располагаются на различных физических хостах. В этом сценарии хранилище располагается на общем для хостов физическом устройстве, так что виртуальные машины имеют доступ к единым данным. Если виртуальная машина или физическая машина на узле 1 (Node 1) станет недоступна, данные будут доступны с узла 2 (Node 2). Применение такого тип кластера избавляет от риска выхода из строя из строя как аппаратной части самих хостов ESX, так и сбоев в работе ОС.
Рисунок 4 - Создание кластера виртуальных машин на нескольких физических серверах
Пример1. Создание кластера виртуальных машин из множества физических серверов
Расширенным сценарием Cluster Across Boxes является создание кластера из нескольких физических машин, преобразованных в виртуальные. Например, можно объединить четыре кластера состоящие из двух физических серверов каждый, в кластер из двух физических серверов с четырьмя виртуальными машинами. Такой сценарий приводит к существенному снижению затрат на оборудование и поддержку.
Рисунок 5 - Создание кластера виртуальных машин из множества физических серверов
Создание кластера физических и виртуальных машин (Standby Host)
Для создания самого простого кластерного решения с низкими требованиями к аппаратной части можно выбрать сценарий с одним хостом в режиме Standby. В данном сценарии каждой физической машине соответствует виртуальная машина на Standby хосте, и при выходе из строя какой либо физической машины она будет запущена как виртуальная машина на выделенном резервном хосте.
Рисунок 6 - Создание кластера физических и виртуальных машин.
Требования кластеров MSCS на ESX к аппаратной части
Применение одного из вышеперечисленных сценариев требует тщательного предварительного анализа и подготовки. В данной части рассматриваются основные требования к аппаратной части ESX хостов, систем хранения и виртуальных машин.
Требования к аппаратной части кластера на выделенном хосте ESX
Для настройки кластера виртуальных машин на выделенном хосте ESX требуется:
На хосте ESX 3х должен быть установлен один сетевой адаптер для сервисной консоли. Если виртуальные машины из кластера имеют выход во внешнюю сеть. компания VMware настоятельно рекомендует установку еще одного сетевого адаптера.
На хосте ESXi должен быть установлен один сетевой адаптер для работы VMkernel. Если виртуальные машины из кластера имеют выход во внешнюю сеть. рекомендуется установить еще один сетевой адаптер.
Локальный SCSI контроллер. Если планируется использование тома VMFS на SAN, необходимо использовать FC HBA (QLogic или Emulex).
Настроить общее хранилище для кластера на выделенном хосте можно используя либо виртуальный диск vmdk, либо удаленный LUN, используя RDM в режиме виртуальной совместимости (не сквозной RDM).
При настройке виртуальной машины следует учитывать следующее:
Необходимо использовать два виртуальных сетевых адаптера
Необходимо иметь в наличии один общий для двух виртуальных машин жесткий диск (кворум диск)
Возможно использование дополнительного общего диска для двух виртуальных машин используемого под данные. При создании жесткого диска для виртуальной машины автоматически создается соответствующий ей виртуальный SCSI контроллер.
Требования к аппаратной части кластера на нескольких физических серверах
Требования к аппаратной части кластера на нескольких физических серверах похожи на те, что были перечислены выше.
Для ESX хостов компания VMware рекомендует три сетевых адаптера на хост для внешних(public) сетевых соединений. Минимальная рекомендация:
На хосте ESX 3х должно быть установлено, по крайней мере, два сетевых адаптера выделенных под кластер один для внешней(public) сети, а один для внутренней(private) сети, дополнительный сетевой адаптер выделяется под сервисную консоль.
На хосте ESXi должно быть установлено, по крайней мере, два сетевых адаптера выделенных под кластер один для внешней(public) сети, а один для внутренней(private) сети, дополнительный сетевой адаптер выделяется под VMkernel.
Необходимо использовать RDM либо в режиме физической, либо виртуальной совместимости (сквозной или не сквозной RDM) В данной конфигурации нельзя использовать виртуальные диски для общего хранилища.
Общее хранилище должно располагаться на SAN.
Замечание: Требования к RDM различаются для ESX Server 3.0 и ESX Server 2.x.
Требования к аппаратной части кластера физических и виртуальных машин
Требования к аппаратной для кластера standby хоста (N+1) схожи с требованиями, предъявляемыми к кластеру на нескольких физических серверах.
Для хостов ESX компания VMware рекомендует три сетевых адаптера на хост для внешних (public) сетевых соединений. Минимальная рекомендация:
На хосте ESX 3х должно быть установлено, по крайней мере, два сетевых адаптера выделенных под кластер один для внешней(public) сети, а один для внутренней(private) сети, дополнительный сетевой адаптер выделяется под сервисную консоль.
На хосте ESXi должно быть установлено, по крайней мере, два сетевых адаптера выделенных под кластер один для внешней(public) сети, а один для внутренней(private) сети, дополнительный сетевой адаптер выделяется под VMkernel.
Необходимо использовать RDM в режиме физической совместимости (сквозной RDM). В данной конфигурации нельзя использовать в RDM режиме виртуальной совместимости (не сквозной RDM) для общего хранилища.
На ESX хосте не допускается использование множественности путей доступа (multipathing) к хранилищу.
Не поддерживается использование ПО множественности путей доступа (multipathing) сторонних производителей.
Для FC HBA (QLogic или Emulex) на физической Windows машине необходимо использовать SCSIport Miniport драйвер. Процесс восстановления кластера не отработает должным образом, если используется STORport Miniport драйвер.
Сводная информация по использованию общего хранилища
В таблице 2 приведена сводная информация о том, какая конфигурация общего хранилища возможна для каждого из сценариев.
Таблица 2 - Сводная информация по использованию общего хранилища
Кластер на выделенном хосте
Кластер на нескольких физических серверах
Кластер физических и виртуальных машин
Виртуальные диски
ДА
НЕТ
НЕТ
Сквозной RDM (режим физической совместимости)
НЕТ
ДА
ДА
Не сквозной RDM (режим виртуальной совместимости)
ДА
ДА
НЕТ
Различные ограничения и рекомендации вышеуказанных сценариев кластеризации
В данном параграфе рассматриваются ограничения и рекомендации сценариев кластеризации. Какие требования и рекомендации необходимо соблюдать при создании кластеров MSCS на VMware ESX:
VMware поддерживает ПО для кластеризации только сторонних производителей, которое указано в списках аппаратной совместимости. Последние обновления по поддержке версий ОС Майкрософт использующих MSCS, а также другая информация по совместимости аппаратной части указана в Storage/SAN Compatibility Guide for ESX Server 3.5 and ESX Server 3i.
Каждая виртуальная машина имеет по умолчанию пять PCI слотов. Под кластер используется четыре слота (два для сетевых адаптеров и два для адаптеров шины SCSI), оставляя один резервный слот для третьего сетевого адаптера (или другого устройства).
Виртуальные машины на данный момент эмулируют только SCSI-2 протокол резервации дисков(SCSI-2 disk reservation protocol), и не поддерживают приложения использующие SCSI-3.
Необходимо использовать LSILogic виртуальных SCSI адаптеров.
Возможна работа с Windows Server 2003 SP2 (32-bit или 64-bit) или Windows Server 2000 SP4. Рекомендуется использовать Windows Server 2003.
Необходимо использовать кластер, состоящий только из 2-х узлов.
Кластера с использованием хранилищ, подключенных по iSCSI или NFS, не поддерживаются.
NIC teaming для кластера не поддерживается.
Загрузочный диск ESX хоста следует размещать на локальном диске.
Не поддерживаются смешанные HBA-конфигурации с одновременным использованием QLogic и Emulex адаптеров на одном хосте.
Не поддерживаются конфигурации с одновременным использованием ESX Server 2.5 и ESX Server 3.0
Виртуальные машины в кластере не могут входить в состав кластеров VMware (DRS или HA).
Вы не можете использовать VMotion для виртуальных машин в кластере.
Следует установить I/O таймаут для виртуальной машины в значение 60 секунд или более изменяя следующий ключ реестра: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\ TimeOutValue. Возможна ситуация, когда при пересоздании кластера, система сбросит данное значение. В этом случае необходимо установить его заново.
Необходимо использовать режим eagerzeroedthick при создании vmdk файлов виртуальных машин. По умолчанию клиент VI или команда vmkfstools создают диски в формате zeroedthick. Преобразовать диск в формат eagerzeroedthick можно при импорте, клонировании или учеличении диска. Диски созданные из шаблонов также создаются в формате eagerzeroedthick.
Диски следует добавлять до настройки сетевых подключений, как указано в следующем KB: http://kb.vmware.com/kb/1513.
В следующей статье мы расскажем о настройке кластера по модели «Cluster in a Box». Следите за обновлениями!
RSS
