Vmware кластер из двух серверов

Vmware кластер из двух серверов

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

На платформе виртуализации VMware vSphere можно построить 2 разновидности кластеров: High-availability кластер (HA) и Distributed Resource Scheduler кластер (DRS).

HA-кластер будет означать, что определенное количество физических серверов объединяется в кластер и на них запускаются виртуальные машины. В случае выхода из строя одного из хостов, виртуальные машины запускаются на других серверах из группы, на которых предварительно было выделено для этого место. В итоге время простоя равно времени загрузки операционной системы «виртуалки».

Если необходимо сократить время простоя до минимального времени рекомендуется использовать технологию VMware Fault Tolerance. Основную идею опции можно описать как создание синхронно работающей реплики виртуальной машины на другом сервере и мгновенное переключение на неё при выходе из строя основного хоста.


Fault Tolerance

Технология VMware DRS используется для выравнивания нагрузки в кластере. Для этого на первоначальном этапе ресурсы кластера объединяются в пул и затем происходит балансировка нагрузки между хостами путем перемещения виртуальных машин. DRS может рекомендовать перемещение с необходимым подтверждением от администратора или делать это в автоматическом режиме. Происходит это с использованием утилиты «живой миграции» vMotion, благодаря которой миграция не требует остановки ВМ. Пользователи продолжают работать с одним экземпляром ВМ до тех пор, пока данные не будут перенесены на другой хост. В последний момент копируются последние изменения из оперативной памяти, пользователь видит незначительное кратковременное снижение быстродействие системы и через мгновение уже работает с той же ВМ, которая по факту уже находится на другом физическом сервере.

Принцип работы VMware HA + DRS

В случае с кластером VMware группа из 2-х и более серверов ESXi находится под централизованным управлением VMware vCenter Server. Собственно, создавать виртуальные машины можно и на одном хосте с установленным гипервизором VMware ESXi, но возможностей HA, DRS и прочих у вас не будет. Вы просто сможете «нарезать» ваш физический сервер на несколько виртуальных, а его неработоспособность будет означать простой всех ВМ.

Чтобы пользоваться всеми кластерными возможностями необходимо использовать платформу VMware vSphere, которая включает в себя сервер управления ESXi-хостами и СХД, так называемый и упомянутый выше, vCenter Server. Также для построения кластера потребуется подключение системы хранения данных. В ней в особенной кластерной файловой системе VMFS хранятся разделы с файлами виртуальных машин, которые доступны для чтения и записи всем ESXi-хостам кластера. По причине хранения в одном месте и независимости виртуальной машины от физической платформы достигается быстрое перемещение и восстановление при помощи HA, DRS, FT, vMotion.


Платформа VMware vSphere

VMware vCenter Server, если говорить упрощенно, является набором служб и базой данных. Каждая из служб занимается своим конкретным списком задач и взаимодействует с другими службами и/или хостами ESXi. vCenter Server – это некий командный пункт, которому подчиняются гипервизоры ESXi на хостах. Общение между ними происходит через хостовых агентов VPXA. Из панели управления vCenter Server можно делать даже больше, чем подключившись напрямую к ESXi. Если в ESXi вы сможете создавать/удалять виртуальные машины, то с помощью vCenter Server вы можете дополнительно создать и настроить для них кластер и все необходимые кластерные опции, часть из которых описана выше.

VMware vCenter Server может работать как на отдельной физическом сервере, так и внутри виртуальной машины на том же хосте, которым сам же и управляет.

Тема безусловно интересная и обширная, однако для развертывания подобных инфраструктур требуются большие материальные затраты. Если мы хотим пользоваться всеми возможностями, которые повышают отказоустойчивость и надежность системы, необходимо приобрести минимум два сервера и СХД, купить лицензию на платформу VMware VSphere у одного из дистрибьюторов. Установка, настройка и администрирование кластера VMware также потребует от вас временных и финансовых вложений.

Что делать в случае, если от вашей IT-инфраструктуры требуется высокая надежность, которую предоставляет платформа VMware vSphere, но нет возможности понести значительные капитальные вложения? Ответом на этот вопрос для многих корпоративных клиентов стало использование облачных технологий, а именно услуга аренды инфраструктуры (IaaS). Облачный провайдер обладает необходимым сетевым и серверным оборудованием, которое расположено в безопасных дата-центрах. IT-специалисты провайдера оказывают техническую поддержку 24*7, а бизнес может воспользоваться всеми преимуществами виртуализации в кластере VMware.

Клиенты не используют VMware vCenter Server. За управление кластерами и физическим оборудованием отвечает провайдер. Клиенты получают значительное количество возможностей управления своим виртуальным ЦОДом с помощью удобного портала самообслуживания VMware vCloud Director. Создание vЦОДа для клиента происходит в кратчайшие сроки, при этом может быть создано необходимое количество виртуальных машин с нужными характеристиками и операционными системами, маршрутизируемые и изолированные сети с любой топологией, настроены гибкие правила Firewall и многое другое.

Покупку минимум двух собственных серверов, СХД и лицензий с необходимостью дальнейшей настройки можно заменить использованием облака. Соглашение с провайдером будет предусматривать уровень доступности услуг (SLA). В случае, с Cloud4Y SLA равен 99,982%. Это означает, что максимально допустимая по соглашению недоступность сервиса составляет не более 15 минут в месяц. Кроме того, Cloud4Y устанавливает минимально допустимые показатели производительности CPU и RAM системы. Количество MIPS на одно vCPU составляет не менее 2900, что гарантирует клиентам заявленное быстродействие процессора. Также не допускается «переподписка» физической оперативной памяти. Это означает, что выделенная при создании виртуальной машины Configured Virtual RAM, которую будет видеть гостевая ОС, является 100% выделенной физической памятью, которая доступна виртуальной машине в любой момент времени. Это создает условия, при которых облачные серверы по производительности в любой момент времени могут полноценно заменить для клиентов физический сервер с соответствующими характеристиками, а благодаря виртуализации в кластере надежность и отказоустойчивость может оказаться выше, чем при использовании собственного оборудования.

Если вашему бизнесу требуется надежное IT-решение на основе кластера VMware, для принятия решения рекомендуем воспользоваться тестовым доступом к облаку Cloud4Y.

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

Постараюсь показать как же именно создается кластер высокой доступности vSphere и объяснить как он работает.

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

Корневым элементом инфраструктуры vSphere является датацентр, поскольку единственный vCenter может управлять до 300 ESX хостов, разбросанных географически. Создадим новый датацентр DC1 (подробности пропущу, это тривиально и не требует никаких настроек). В итоге у нас должна получиться примерно такая картинка:

Читайте также:  Sdcard upgrade failed please reboot что делать

Кластер с точки зрения 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 автоматически проверит все условия, и выдаст результат – можем ли мигрировать машину, и если нет, то почему.

Потерян один пинг, но сессии не разорвались, и работа продолжилась уже на другом хосте.

Более 5060 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru / Articles / Использование MSCS для кластеризации VirtualCenter и виртуальных машин на VMware ESX. Часть 1 – Общие понятия.

Использование MSCS для кластеризации VirtualCenter и виртуальных машин на VMware ESX. Часть 1 – Общие понятия.

Автор: Антон Ткач
Дата: 16/01/2009

Реклама:

Статья:

    Основные понятия

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

    Читайте также:  Bootstrap 4 прижать блок к низу

    Рисунок 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_MACHINESystemCurrentControlSetServicesDisk TimeOutValue. Возможна ситуация, когда при пересоздании кластера, система сбросит данное значение. В этом случае необходимо установить его заново.
    • Необходимо использовать режим eagerzeroedthick при создании vmdk файлов виртуальных машин. По умолчанию клиент VI или команда vmkfstools создают диски в формате zeroedthick. Преобразовать диск в формат eagerzeroedthick можно при импорте, клонировании или учеличении диска. Диски созданные из шаблонов также создаются в формате eagerzeroedthick.
    • Диски следует добавлять до настройки сетевых подключений, как указано в следующем KB: http://kb.vmware.com/kb/1513.

    В следующей статье мы расскажем о настройке кластера по модели «Cluster in a Box». Следите за обновлениями!

    Ссылка на основную публикацию
    The godfather вылетает при запуске
    Файл the godfather 2 the game_code.exe из Electronic Arts является частью Unified Registration code installer program. the godfather 2 the...
    Kms активатор windows 10 без вирусов
    Данный способ, благодаря которому утилита снимает ограничения, изначально использовался Microsoft для того, чтобы облегчить лицензирование платформ и пакета Office. KMSAuto...
    Kyocera fs 1025mfp сканирование по сети
    Возможно, клиент пытается сканировать через сетевой интерфейс, что у данных МФУ невозможно. Доступные технологии сканирования – TWAIN, WIA, сканирование в...
    Tmpfile1 в папке temp
    Файл tmpfile1.exe из - является частью -. tmpfile1.exe, расположенный в Unknown file path с размером файла unknown байт, версия файла...
    Adblock detector