Proactive ha vmware что это
Новые возможности в vSphere 6.5
В частности, в vSphere 6.5 внедрены изменения в части высокой доступности, распределения ресурсов через DRS (Distributed Resource Scheduler) и работы с томами.
Блок High Availability теперь переименован в vSphere Availability. Процент резервных мощностей стал связан с количеством хостов, отказ которых система должна выдержать. В частности в кластере из 4-х узлов, если параметр «выдержать отказ хостов» установлен в 2, то резервная мощность автоматически устанавливается в 50%, а если параметр равен 1, то и резервная мощность устанавливается в 25%. Пользователь может самостоятельно поменять эти настройки, если нужно.
Теперь политика Admission Control по умолчанию использует процент ресурсов кластера, а не слоты. Это большой прогресс, поскольку может быть трудно вычислить политику слотов на основе запущенных виртуальных машин.
Ранее, рестарт виртуальных машин происходил без возможности настроить взаимную зависимость. Это было большой проблемой для многоуровневых приложений. Теперь специальный модуль Orchestrated Restarts (управляемые рестарты) дает возможность определить порядок, в котором нужно запускаться, например: сначала сервер баз данных, затем – сервер приложения и затем – веб-уровень.
Еще одна функция – Proactive HA. Это новая возможность в DRS, управлении распределенными ресурсами, которая освобождает хост как только получает уведомление о том, что у хоста снизилась работоспособность (degraded mode). Например, такие уведомления могут прийти от Dell OpenManage или от HP Enterpise Systems Insight Manager.
Как только у хоста замечено снижение работоспособности, Proactive HA переводит его в режим карантина, а DRS начинает переводить виртуальные машины с этого хоста. В отличие от режима обслуживания, когда хост невозможно использовать, режим карантина позволяет хосту обслуживать виртуальные машины, например в случаях, когда в кластере недостаточно ресурсов.
В DRS также внесены изменения в части балансирования нагрузки в кластере. Теперь DRS принимает во внимание утилизацию сети, когда перемещает виртуальные машины между хостами.
Когда VMware выпустит новую версию vRealize Operations (vROps), обещана поддержка предиктивной функциональности в DRS. То есть vROos будет собирать исторические данные об использовании ресурсов, и использовать аналитический прогноз, чтобы определить, стоит ли перемещать виртуальные машины. Это полезно для циклических нагрузок, таких как, например, большая нагрузка на SQL-сервер в конце месяца, когда запускается регулярный отчет.
В последнюю версию Virtual Volumes теперь добавлена репликация: пообъектная или группами.
Также появилась возможность заново использовать емкость хранения, когда удаляются виртуальные машины. Ранее для этого нужно было запускать Unmap, чтобы снова использовать такие блоки, теперь можно настроить повторное использование освободившихся блоков.
Как построить vSphere HA High Availability кластер VMware
High Availability – технология кластеризации, созданная для повышения доступности системы, и позволяющая, в случае выхода из строя одного из узлов ESXi, перезапустить его виртуальные машины на других узлах ESXi автоматически, без участия администратора.
Общие сведения High Availability
В прошлый раз шла речь о технологиях, используемых в VMware для обеспечения отказоустойчивой системы, в этой же статье подробнее остановимся на VMware HA – VMware High Availability (механизме высокой доступности).
Для того чтобы создать HA кластер, нам необходимо, чтобы все виртуальные машины этого кластера хранились на общем хранилище данных*. При этом если у нас выходит из строя один из узлов ESXi, все виртуальные машины с этого узла будут запущены на свободных слотах (мощностях) других ESXi узлов кластера.
*Общее хранилище данных может представлять собой не только «железную» СХД, но и быть программным. У VMware для этой цели есть продукт vSAN (virtual storage area network). У RedHat есть GlusterFS и т.д.
Список терминов
Последовательность создания VMware HA кластера
Isolation Response
Действия при прекращении получения сигналов доступности в кластере HA определяются значением Isolation Response, определяющим действие узла ESXi при прекращении им получения сигналов доступности кластера (Heartbeat). Прекращение получения сигналов доступности происходит из-за «изоляции» ESXi, например, в случае отказа сетевой карты.
Существует несколько предполагаемых сценариев развития событий:
Во втором случае следует выбрать Isolation Response – Power off либо Shutdown (установлен по умолчанию), если ESXi-хост перестал получать сигналы доступности, HA перенесет с общего хранилища ВМ, хранившиеся на этом хосте ESXi, на свободные ESXi-хосты. ESXi-хост должен автоматически выключаться, чтобы не возникало конфликтов двух одинаковых хостов.
По умолчанию Isolation Response установлен в режиме Power off. Мы не знаем как будут развиваться события в момент гипотетического отказа, поэтому мы рекомендуем оставлять значение IR в состоянии Power off, чтобы избежать риска появления в сети конфликтующих машин с одинаковыми сетевыми настройками.
Резервация ресурсов (Reservation)
При расчете параметра Failover Capacity кластер HA сначала создает слоты, определяемые параметром Reservation. Этот параметр рассчитывается по размеру максимальной из виртуальных машин, работающих на узлах кластера.
Параметр Failover Capacity
После расчета слотов определяется сам параметр Failover Capacity. Он измеряется в целых числах и обозначает, какое максимальное количество узлов в кластере одновременно может выйти из строя. При этом все машины должны продолжать функционировать.
Второй случай: 3 узла ESXi, по 4 слота на каждом, 4 виртуальные машины.
В этом случае, свободных слотов хватит, даже если упадет сразу 2 узла ESXi(в нашем случае, ВМ перенесутся на хост №1).
Технически параметр Failover Capacity рассчитывается следующим образом: из количества всех узлов в кластере мы вычитаем отношение количества виртуальных машин в кластере к количеству слотов на одном узле ESXi. Если получается не целое число, округляем вниз.
Для первого случая: 3-6/4=1.5 Округляем до 1;
Для второго случая: 3-4/4=2 Так и остается 2;
Admission Control
Admission Control мы условно разделили на состояние Admission Control (состояние ADC) и параметр Admission Control (параметр ADC).
Состояние ADC определяется соотношением реального уровня отказоустойчивости (FCap) и установленного администратором (NHF). Если FCap больше NHF, то кластер настроен корректно и проблем ожидать не следует. Если наоборот, то мы должны устанавливать параметр ADC.
Параметр ADC определяется администратором и может иметь два состояния:
При выборе параметра ADC следует заранее понять, как будет устроен кластер и для каких целей он необходим:
Во втором случае, поведение кластера может стать непредсказуемым (в худшем случае может дойти до такого, что ВМ опустят значение ADC до нулевого значения, тем самым сделав бесполезным технологию HA)
Рекомендации по созданию кластера vSphere HA
Мы представим общие рекомендации по созданию кластера HA:
esxi cluster
vSphere HA
Специалисты компании V-Grade, помогут сделать для Вас быстрый и правильный расчёт esxi cluster.
Достаточно написать письмо на почту с темой письма « VMware HA»vmware@v-grade.ru.
Так же можете задать вопросы на тему:
esxi cluster setup
vmware esxi cluster free
HA кластер
Работая с нами Вы, получите:
Контакты:
тел.: +7 (495)662-58-98
vmware@v-grade.ru
Часы работы: 10:00 до 20:00 по Москве.
Наши эксперты:
У нас есть конфигуратор VMware, лучшие цены, актуальные статьи. лучшие эксперты.
Русские Блоги
vSphere 6.5 High Availability New Features – Proactive HA
VSPhere 6.5 был выпущен, что содержит много новых функций, большинство из которых ждут.vSphere 6.5Последняя версия его отраслевой ведущей платформы виртуализации. Эта новая версия VSPhere имеет значительно упрощенный опыт, комплексную встроенную безопасность и универсальную прикладную платформу, которая может запускать любое приложение. Как и в каждой версии VSPhere, она продолжает предоставлять наилучшие возможности доступности и управления ресурсами для критических бизнес-приложений. VSPhere 6.5 также добавляет новые функции и улучшения. Мы обсудим новые функции, доступные для VSPhere 6.5 высокой доступности и DRS.
will talk about new features available with vSphere 6.5 High Availability & DRS.
отvSphere 6.5Благодаря ряду новых функций, предоставляемых высокой доступностью, мы подробно обсудим активность в этой статье.
Теперь vsphere 6.5Высокая доступность (HA) также может обнаружить аппаратный статус хоста ESXI и позволит вам эвакуировать виртуальную машину перед задачей оборудования с помощью проактивного га. Active Ha работает с аппаратными поставщиками мониторинговых решений для получения аппаратных компонентов (таких как память, вентиляторы, и мощность). Вы можете настроить VSPhere HA, чтобы ответить на неисправность аппаратного компонента. Эта функция активно избегает отключения виртуальной машины, обнаруживая сбои оборудования и помещают хост ESXI в режиме карантина или обслуживания в соответствии с опцией конфигурации. Вам необходимо включить DRS на кластере, чтобы использовать Active HA.
Если какой-либо аппаратный компонент нефункционал, и VSphere будет отмечен ненормальным аппаратным мониторингом, VSphere будет классифицировать пораженный хост ESXI в умеренную деградацию или суровую понижение в соответствии с отказом компонентов. VSPhere будет поместить пораженный хост ESXI в новом состоянии под названием «режим изоляции».
В режиме изоляции DRS не использует хост ESXI для новой виртуальной машины, а DRS постарается эвакуировать хост, если он не вызывает проблем с производительностью. Вы также можете настроить Active HA для размещения хоста Esxi в режиме обслуживания, который выполняет VMOTION виртуальной машины в других обычных хостах ESXI в кластере. Active Ha может реагировать на разные типы сбоев. В настоящее время поддерживаются пять неудач:
Как настроить VSPhere 6.5 Проактивное га?
Установите флажок «Открыть активный HA». Вы можете настроить параметры конфигурации в разделе «Активная ошибка и ответ HA»
Есть два уровня автоматизации VSPhere Autive Automation:
Руководство по эксплуатации:VCenter Server порекомендует только предложения миграции для виртуальных машин. Вам нужно вручную мигрировать виртуальную машину с хоста понижения.
автоматизация: Виртуальная машина будет мигрировать на множество здоровья, и хост введет в систему режима изоляции или обслуживания, в зависимости от настроенного уровня автоматизации Active HA.
Для частичных провалов хозяев существует три средства:
Ниже приведены детали трех операций по ремонту, которые определяют, что происходит в некоторых пониженных хостах:
vSphere 6.5 High Availability New Features – Proactive HA
POSTED BY MOHAMMED RAFFIC ON LAST UPDATED FEB 23, 2017 AT 6:18AM | PUBLISHED ON FEB 23, 2017 IN HIGH AVAILABILITY, VSPHERE 6.5 | 26139 VIEWS
vSphere 6.5 released with lot of new features that most of them were waiting for. vSphere 6.5, the latest version of its industry-leading virtualization platform. This new release of vSphere features a dramatically simplified experience, comprehensive built-in security, and a universal app platform for running any app. As usual with the release of each vSphere version,It continues to provide the best availability and resource management features for business critical application workloads. vSphere 6.5 also added new and improved features. We will talk about new features available with vSphere 6.5 High Availability & DRS.
From the multiple new features available from vSphere 6.5 High Availability, We will talk in detail about Proactive HA in this article.
vSphere 6.5 High Availability – Proactive HA
vSphere 6.5 High Availability (HA) now also detect the hardware conditions of the ESXi host and allow you to evacuate the Virtual machines before the hardware issues cause an outage to Virtual machines with the help of Proactive HA. Proactive HA works in conjunction with hardware vendors monitoring solutions to receive the health status of the hardware components such as memory, fans and power supplies. You can configure vSphere HA to respond according to the failure of hardware components. This feature proactively avoids the virtual machine downtime by detecting the hardware failures and place that esxi host in Quarantine Mode or Maintenance mode based on configuration option. You need to have DRS enabled on the cluster to make use of Proactive HA.
If any hardware components is failed and it is marked as unhealthy by hardware monitoring, vSphere will classify the affected ESXi host as either moderately degraded or severely degraded based on the component failure. vSphere will place that affected ESXi host into new state called “Quarantine Mode”.
In the Quarantine Mode, DRS will not use the ESXi host for new Virtual machine placements and also DRS will attempt to evacuate the host as long as it would not cause performance issue. You can also configure proactive HA to place the degraded ESXi hosts into Maintenance mode, which perform the vMotion of Virtual machine to other healthy ESXi hosts in the cluster. Proactive HA can respond to different types of failures. Currently, there are five failure events that are supported:
How to Configure vSphere 6.5 Proactive HA?
Select the checkbox “Turn on Proactive HA”. You can configure configuration options under “Proactive HA Failures and Responses”
There are two vSphere Proactive HA Automation Levels:
Manual: vCenter Server will suggest only the migration recommendations for virtual machines. You need to manually migrate the virtual machines out from the degraded hosts.
Automated: Virtual Machines will be migrated to healthy hosts and degraded hosts will be entered into remediation action either quarantine or maintenance mode depending on the configured Proactive HA automation level
There are three remediation actions for partial failed hosts:
Here are the detailed information of three Remediation actions which determine what happens to partially degraded hosts:
Select the check boxes to enable Proactive HA providers for this cluster. Proactive HA Providers appear below when their corresponding vSphere Web Client plugin has been installed and the providers monitor every host in the cluster. Click on the edit link to view/edit the failure conditions supported by the provider. Since I don’t have installed any of the Proactive HA providers vSphere Web client, It is not providing any information in my demo environment. That’s it. We are done with configuring vSphere 6.5 Proactive HA. I hope this is informative for you. Thanks for Reading!! Be social and share it in social media, if you feel worth sharing it.
VMware Proactive HA
You are a VMware Administrator. In your data center, there’s a vSphere 6.0 cluster running rock-solid! But, with the 6.0 end of support coming up March 12, 2020, you’re forced to look into the newer version of vSphere. You may have noticed that there’s been a couple of improvements and new features since 6.0 came out. In this post, I’ll walk you through the feature called Proactive HA, released in 6.5.
In short, Proactive HA is and extension of DRS that uses the vendor Health Provider to move VM’s off degraded hosts. You may think, but why?? Why does it have HA in the name if it’s not part of vSphere HA?! Well, it is not part of the vSphere HA architecture, and I’ll explain the difference. But, you do enable and configure it in the same GUI window as vSphere HA.
There are a couple of different states reported from the health provider, and it’s up to you as an admin to configure the responses. The severity levels are; Healthy, Moderate Degradation, Severe Degradation, and Unkown. I’ll jump directly to the recommended actions, and they are, Quarantine mode for Moderate and Maintenance mode for severe failure. In reality, the moderate state could be that one of ten fans failed, and the severe level could be a critical memory error.
Quarantine mode is where no new VM’s are allowed to run on the host, but the ones running will be allowed to stay on the host if the cluster resources are overcommitted.
Maintenance mode is straightforward. All VM’s will be moved off the host.
To enable Proactive HA, you need the following:
Steps to enable Proactive HA:
Modify the settings to:
Written by me, John Henriksson. I live and work in Sweden as Technical Partner Manager @ NetApp. You should connect with me on LinkedIn.
HA (High Available) кластер VMware vSphere на блейд-серверах HP BL460c и EVA
Практическим применением знаний о работе с массивами EVA и iLO в серверах ProLiant, которые вы получили чуть раньше, может стать развертывание высокодоступного кластера на vSphere.
Кластер может использоваться для предприятий среднего и крупного размера, чтобы уменьшить время внеплановых простоев. Поскольку для бизнеса важны такие параметры как доступность его сервиса или услуги клиенту в режиме 24×7, то такое решение основывается на кластере высокой доступности. В кластер всегда входят как минимум 2 сервера. В нашем решении серверы под управлением VMware отслеживают состояние друг друга, при этом в каждый момент времени ведущим будет только один из них, на нем будет разворачиваться виртальная машина с нашим бизнес-приложением. В случае отказа ведущего сервера его роль автоматически принимает второй, при этом для заказчика доступ к бизнес-приложению практически не прерывается.
1. Описание задачи
В данном примере мы опишем процесс создания высокодоступного кластера VMware на блейд-серверах BL460c G7. Оборудование состоит из блейд-корзины HP c7000 и двух блейд-серверов BL460c G7, где скофигурирован VMware HA(High Available)-кластер. В демо-центре HP в Москве сейчас доступны только модели блейд-серверов G7, но на основе описанного примера можно собрать кластер и на новых блейд-серверах Gen8. Конфигурирование, в целом, не будет различаться. Система хранения – HP EVA 4400. Для Ethernet и Fibre Channel подключений в корзине c7000 установлены 2 модуля HP Virtual Connect Flex Fabric в отсеках 1 и 2.
2. Описание компонентов
Virtual Connect FlexFabric — конвергентный виртуализированный модуль ввода/вывода для блейд-корзины с7000.
Модуль HP Virtual Connect FlexFabric использует технологии Flex-10, FCoE, Accelerated iSCSI для коммутации блейд-серверов и сетевой инфраструктуры (SAN и LAN) со скоростью 10Gb.
Из возможностей: перенос «профилей» (таблица MAC и WWN серверов) не только между разными лезвиями в шасси, но и на удалённые сайты, где есть такой же блейд-сервер.
Так же при использовании Virtual Connect каждый из двух портов сетевой карты блейд-сервера можно делить на 4 виртуальных порта 1GbE/10GbE/8Gb FC/iSCSI общей пропускной способностью 10GbE на порт. Это позволяет получить от 8 виртуальных портов на сервер (на BL460с G7), которые необходимо задавать при первой инициализации.
Единственное ограничение в том, что HP Virtual Connect FlexFabric не являются полноценными коммутаторами. Это аггрегаторы, для работы которых необходимо иметь отдельные Ethernet- и SAN-свитчи (в последней прошивке, правда, появилась возможность Direct Connect с HP P10000 3PAR).
Общий вид использованного оборудования отражается в Onboard Administrator.
Интегрированная в ProLiant BL460c G7 карта NC553i Dual Port FlexFabric 10Gb может работать с модулями HP Virtual Connect FlexFabric напрямую, без дополнительных мезонин-карт. Два модуля HP Virtual Connect FlexFabric установлены для отказоустойчивости путей связи связи блейд-серверов с системой хранения EVA 4400 и Ethernet-коммутаторами.
В данном примере будем рассматривать сценарий, когда трафик от модуля HP Virtual Connect FlexFabric разделяется на Ethernet-коммутаторы и FC-фабрику. FCoE в этом случае используется для коммутации модулей с блейд-серверами внутри корзины.
Для работы с различными протоколами модулям HP Virtual Connect FlexFabric необходимы трансиверы. В этом примере 4 Gb FC SFP трансиверы были установлены в порты 1 и 2 на каждом из модулей, а 10 Gb SFP+ трансиверы были установлены в порты 4 и 5. 10GbE-каналы использованы в данном тесте чтобы задействовать сетевое оборудование в нашем демо-центре.
Диаграмма показывает, что 3 порта сетевого адаптера NC553i Dual Port FlexFabric 10Gb сконфигурированы как FlexNIC для взаимодействия виртуальных машин между собой и для подключения к сетевой инфраструктуре. Оставшийся порт был сконфигурирован как FCoE для связи с SAN-инфраструктурой и системой хранения EVA 4400.
Вместе с каждым Virtual Connect модулем поставляется ПО для управления HP Virtual Connect Manager, для Enterprise модулей – HP Virtual Connect Enterprise Manager. С помощью Enterprise Manager можно управлять из одной консоли до 256 доменами (1 домен — 4 Blade системы с Virtual Connect).
После подключения модуля необходимо его сконфигурировать. Делается это либо подключением к Onboard Administrator самой корзины, либо по IP-адресу, который назначается модулю по умолчанию на заводе.
3. Настройка профилей в Virtual Connect Manager
После подключения HP FlexFabric мы должны определить домен, Ethernet-сеть, SAN-фабрику и серверные профили для хостов. Эти настройки производятся в HP Virtual Connect Manager или в командной строке. В нашем примере домен уже был создан, поэтому следующим шагом будет определение VC Sharing Uplink Sets для поддержки Ethernet сетей виртуальных машин с именами HTC-77-A и HTC-77-B. Включаем “Map VLAN tags” функцию в мастере установки.
Функция “Map VLAN tags” дает возможность использовать один физический интерфейс для работы с множеством сетей, используя Shared Uplink Set. Таким образом можно настроить множество VLANs на интерфейсе сетевой карты сервера. Параметры Shared Uplink Sets были заданы в мастере установки VCM. Пример задания SUS:
Обе сети «HTC-77-A» и «HTC-MGMT-A» были назначены: VLAN_Uplink_1 на порт 5 модуля 1; второй Shared Uplink Set (VLAN_Uplink_2) был назначен на порт 5 модуля 2, и включает в себя сети HTC-77-B (VLAN 20) и HTC-MGMT-B (VLAN 21). Пример создания сетей Ethernet в VCM:
Модуль HP Virtual Connect может создавать внутренную сеть без аплинков, используя высокопроизводительные 10Gb соединения с бэкплейном корзины с7000. Внутренняя сеть может быть использована для VMware vMotion, а также для организации отказоустойчивости сети. Трафик этой сети не выходит на внешние порты корзины c7000. В нашем случае были настроены 2 сети VMware vMotion. Для консоли управления были настроены две сети с именами HP-MGMT-A и HP-MGMT-B. Порт 6 модулей HP Virtual Connect FlexFabric в отсетках 1 и 2 был использован для подключения к консоли управления.
После этого начинается настройка фабрики SAN. Все довольно просто: в VCM выбрать Define – SAN Fabric. Выбираем SAN-1 модуль в отсеке 1, порт X1. Для второго модуля SAN-2 порт также X1. Пример настройки SAN:
Последним шагом будет «склеивание» всех ранее сделанных настроек в серверный профиль. Это можно сделать несколькими способами: например, через web-интерфейс VCM или через командную строку Virtual Connect – Virtual Connect Scripting Utility (VCSU). Перед установкой ОС необходимо проверить, что все системные, NIC и FC драйверы обновлены, а все параметры сети заданы. Пример создания профиля в CVM:
В VCM выбираем Define – Server Profile, вводим имя профиля и выбираем сетевые подключения профиля из созданных ранее.
В нашем случае все порты были назначены нами заранее: 6 Ethernet портов и 2 SAN порта на каждый профиль. Профили для отсека 11 и 12 идентичны, т.е. каждый сервер видит один и тот же набор портов. Суммарная скорость не превышает 10Гб/с на каждый порт сетевой карты сервера.
Если в будущем планируется расширение сети, то рекомендуется назначить нераспределенные (unassigned) порты в профиле. Делая так, можно в дальнейшем активировать эти порты без выключения и перезагрузки сервера.
При создании профиля по умолчанию доступны только 2 порта в разделе Ethernet. Чтобы добавить больше, необходимо вызвать контекстное меню правой кнопкой мыши и выбрать “Add connection”.
Назначаем скорость для каждого типа портов: портам управления – 500Mb/s, портам vMotion – 1Gb/s, портам SAN – 4Gb/s и портам виртуальных машин – 4.5Gb/s.
После создания профилей они привязываются к блейд-отсеку корзины в этом же меню.
4. Настройка кластера VMware
На этом настройки корзины завершены. Далее происходит удаленное подключение к самим блейдам и разворачивание VMware ESX 5.0, пример удаленной установки ОС на серверы ProLiant через iLO уже был описан.
В нашем случае вместо Windows в выпадающем меню установщика выбирается VMware и указывается путь к дистрибутиву.
После установки сервер перезагружается и можно приступать к настройке виртуальных машин. Для этого подключаемся к серверу ESX. Заходим в раздел Configuration, создаем 6 vmnics на каждый хост, как и в модуле Virtual Connect: Service Console (vSwitch0), VM Network (vSwitch1), vMotion (vSwitch2). Таким образом мы получаем отказоустойчивую конфигурацию, где каждой сети соответствую 2 vmnics.
Как только добавляются vmnics можно заметить, что каждому адаптеру автоматически задается скорость, заданная в серверном профиле, при конфигурации в Virtual Connect Manager.
После добавления vmnics объединяем их в группу с помощью vSwitch: вкладка Port – в поле Configuration выбираем vSwitch – Edit, выбираем NIC Teaming, убеждаемся, что оба vmnics видны. Балансировку нагрузки выбираем «Route based on the originating virtual port ID» — эти настройки рекомендуется ставить по умолчанию (подробнее об этом методе можно прочесть на сайте VMware.
5. Настройка дискового массива EVA 4400
В предыдущем обзоре было рассказано как работать с интерфейсом управления дисковыми массивами EVA — Command View.
В данном примере мы создаем LUN размером в 500 ГБ, который разделяется между двумя хостами виртуальных машин. По описанному в предыдущей статье методу создается виртуальный диск и презентуется двум хостам ESX. Размер LUN определяется типом ОС и ролями, которые данный кластер будет выполнять. Обязательным условием для кластера (в частности, для VMware vMotion) – LUN должен быть разделяемым. Новый LUN должен быть отформатирован в VMFS, и функция Raw Device mappings (RDMs) для виртуальных машин должна быть задействована.
6. Внедрение VMware HA и VMware vMotion
HP Virtual Connect в сочетании с VMware vMotion дает тот же уровень избыточности, как при использовании двух модулей VC-FC и двух модулей VC-Eth, за исключением того, что только 2 модуля HP FlexFabric необходимы. HP Virtual Connect FlexFabric дает возможность организовать отказоустойчивые пути к общему LUN и отказоустойчивого объединения сетевых интерфейсов (NIC Teaming) для работы в сети. Все настройки VMware vSphere отвечают Best Practices описанным в документе.
Была проведена проверка на доступность кластера. На одном из хостов была развернута виртуальная машина Windows 2008 Server R2.
Виртуальная машина вручную несколько раз была смигрирована с одного сервера на другой, во время мигации кластер оставался доступным.
HTC DC – наш DC, Demo-FlexFabric Cluster – наш кластер, Demo-ESX1 и Demo-ESX2 – хосты VMware, vmhba2 – SAS контроллеры блейд-серверов, подключенные к внутренней дисковой подсистеме. Vmhba0 и vmhba1 – два порта встроенных сетевых карт NC553i Dual Port FlexFabric 10Gb Adapter, подключенных к разделяемому LUN EVA 4400. Demo-VM-W2K8R2-01 – виртуальная машина.