Виртуализация vSphere, Hyper-V, Xen и Red Hat

Более 5370 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes

VM Guru / News / Новые возможности VMware vSphere 7 Update 1 – vSphere Clustering Service (vCLS) как дополнительная защита кластера и служб DRS

Новые возможности VMware vSphere 7 Update 1 – vSphere Clustering Service (vCLS) как дополнительная защита кластера и служб DRS Реклама: Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1, а также обновленных функциях платформы для организации кластеров хранилищ VMware vSAN 7 Update 1. Одной из новых возможностей VMware vSphere 7 U1 стала служба vSphere Clustering Service (vCLS), которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Как вы знаете, кластер HA/DRS очень зависит от постоянной доступности сервисов vCenter, который является критическим звеном виртуальной инфраструктуры. Поэтому для него организовывают такие сервисы, как vCenter Server High Availability (VCHA), но и они не идеальны. Также проблема наблюдается при масштабировании кластеров в больших окружениях, которые объединяют онпремизные и облачные площадки, где масштабируемость vCenter является серьезной проблемой. Учитывая это, VMware придумала такую штуку — сажать на хосты кластера 3 служебных агентских виртуальных машины, составляющих vCLS Control Plane, которые отвечают за доступность кластера в целом: Таких виртуальных машин три в кластере, где 3 или более хостов, и две, если в кластере два хоста ESXi. Три машины нужны, чтобы обеспечивать кворум (2 против 1) в случае принятия решения о разделении кластера. Три этих виртуальных машин следят друг за другом и оповещают об этом кластерные службы vCenter: Это самокорректирующийся механизм, что значит, что если одна из агентских машин становится недоступной или выключенной, то службы vCLS пытаются самостоятельно наладить работу ВМ или включить ее. Есть 3 состояния служб vCLS: Healthy – как минимум 1 агентская ВМ работает в кластере, чтобы обеспечить доступность кластера развертываются 3 ВМ для кворума. Degraded – как минимум одна агентская машина недоступна, но DRS продолжает функционировать и исполнять свою логику. Такое может, например, произойти при передеплое служебных машин vCLS или после какого-то события, повлиявшего на их «включенность». Unhealthy – логика DRS не выполняется (балансировка или размещение ВМ), так как vCLS control-plane недоступна (то есть ни одной агентской ВМ не работает). Легковесные машины-агенты исполняются на хостах ESXi и лежат на общих хранилищах, если общие хранилища недоступны — то на локальных дисках. Если вы развернули общие хранилища после того, как собрали кластер DRS/HA (например, развернули vSAN), то рекомендуется перенести агентские ВМ с локальных хранилищ на общие. Сама гостевая ОС агентских ВМ очень легковесная, используется Photon OS следующей конфигурации: Диск в 2 ГБ — это тонкий диск, растущий по мере наполнения данными (thin provisioned). Эти машины не имеют своего нетворка, а также не видны в представлении Hosts and Clusters в клиенте vSphere. Агентские ВМ можно увидеть в представлении VMs and Templates где есть папка vCLS: Обратите внимание, написано, что для агентских ВМ управление питанием производится со стороны служб vCLS. Если вы попытаетесь выключить эти ВМ, то будет показано следующее предупреждение: При переводе кластера в режим обслуживания vCLS сам заботится о миграции агентских ВМ с обслуживаемых серверов и возвращении их обратно. Для пользователя это происходит прозрачно. И, конечно же, лучше не выключать эти ВМ вручную и не переименовывать папки с ними. Жизненный цикл агентских ВМ обслуживается со стороны vSphere ESX Agent Manager (EAM). EAM отвечает за развертывание и включение агентских ВМ, а также их пересоздание, если с ними что-то произошло. В анимации ниже показано, как EAM восстанавливает ВМ, если пользователь выключил и/или удалил ее: Важный момент для разработчиков сценариев PowerCLI — это необходимость обрабатывать такие ВМ, чтобы случайно не удалить их. Например, ваш скрипт ищет неиспользуемые и забытые ВМ, а также изолированные — он может по ошибке принять машины vCLS за таковые и удалить, поэтому их надо исключать в самом сценарии. В интерфейсе vSphere Client список агентских ВМ можно вывести в разделе «Administration > vCenter Server Extensions > vSphere ESX Agent Manager». У агентских ВМ есть свойства, по которым разработчик может понять, что это они. В частности: ManagedByInfo extensionKey == «com.vmware.vim.eam» type == «cluster-agent» ExtraConfig keys «eam.agent.ovfPackageUrl» «eam.agent.agencyMoId» «eam.agent.agentMoId» Основное свойство, по которому можно идентифицировать агентскую ВМ, это HDCS.agent, установленное в значение «true». В Managed Object Browser (MOB) выглядит это так: Ну и напоследок — небольшое демо технологии vSphere Clustering Service: Чтобы оставлять комментарии, вы должны быть зарегистрированы на сайте. Зал Славы Рекламодателя Все сайты о виртуализации:

01/06/2021:

Серия весенних вебинаров VMware продолжается

Вебинары VMC о виртуализации:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

Windows cluster with vmware

Доброго времени суток! Многоуважаемые инженеры по виртуализации, рад, что вы вновь посетили профильный блог Pyatilistnik.org. В прошлый раз мы с вами подробно разобрали механизм применения утилиты Robocopy и научились с ее помощью реализовывать всевозможные сценарии копирования данных. Сегодня я бы хотел вам рассказать, о создании общих дисков (Multi-writer) в VMware ESXI 5.5, 6.5 и выше, для кластерных решений Oracle RAC и Microsoft MSCS кластер.В век виртуализации, данная информация все больше становится актуальней.

Что такое общий диск Multi-writer в VMware ESXI

Сейчас уже очень сложно себе представить серьезный сервис без отказоустойчивости, которая может быть реализована на разных уровнях работы инфраструктуры. Очень частым решением выступает отказоустойчивый кластер, который подразумевает использование разных серверов для одного сервиса. Выход из строя одного из серверов не влияет на работоспособность предоставляемых услуг клиентам. Очень часто в кластерах используются общие диски, для хранения баз данных (Microsoft SQL или Oracle), файловые ресурсов. Общие диски могут презентованы, как отдельные LUN с СХД, через ISCSI протокол, через общий диск или RDM в случае с виртуальными машинами.

В данной заметке я опишу реализацию с помощью общего диска для виртуальных машин VMware ESXI 6.5. В некоторых случаях (как правило, в сценариях кластеризации) может потребоваться совместное использование одного и того же диска между двумя (или более) виртуальными машинами. Наиболее оптимальным способом является использование диска vmdk, физически расположенного на общем хранилище или локально на хосте ESXi. Если вы хотите использовать общие диски на разных хостах ESXi, то вы можете использовать только разделяемое хранилище

.На представленной ниже схеме вы видите:

1. Storage Array, по сути это ваша система хранения данных, на которой реализован RAID массив, по рекомендации производителя.
2. RAID массив порезан на LUN, это логически порезанное место на вашей системе хранения данных
3. Далее LUN презентуется хостам VMware ESXI 6.5 и размечается файловой системой VMFS 6. Где из LUN получаются разделы (Datastore-Volume) для гипервизора.
4. Далее на на Datastore уже разворачиваются виртуальные машины

Вот на таком общем VMFS Volume диске вы создаете общий VMDK диск, который будет доступен двум и более виртуальным машинам под чтение и запись. Сами виртуальные машины могут находится на разных физических хостах и разных географических локациях.Такой режим называется Multi-Writer VMDK, его часто применяют в построении кластеров MS SQL, Oracle RAC, такой режим работы диска применяется в технологии VMware Fault Tolerance.

Для чего применяют Multi-Writer диск

• Во первых, как я и писал выше для отказоустойчивости различных сервисов, сервера которых могут быть в разных ЦОДах.
• Во вторых для возможности обслуживания важных серверов, без их простаивания. Например, чтобы была возможность своевременно производить обновление Windows пакетов, другого программного обеспечения, иметь возможность перезагружать сервер
• В целях тестирования кластерных технологий, когда у вас нет СХД и нет возможности реализовать общий диск, по FC или ISCSI протоколу

Ограничения общих дисков VMware ESXI

Без некоторых нюансов все же не обошлось, хочу выделить некоторые ограничения при использовании общих дисков:

Например, при попытке сделать Storage vMotion вы получите ошибку:

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

• Вы не сможете на живую произвести расширение дисков, при попытке вы получите вот такую ошибку:

• Если вы вдруг разметите оба диска в NTFS на двух хостах и попытаетесь на них писать, создав на одном одну папку, а на втором вторую, то хосты эти папки не увидят, каждый свою, учтите, это вам не общий диск с синхронизацией файлов, Multi-Writer VMDK именно нужен для кластеризации.

Как подключить общий диск в VMware ESXI 6.5 и выше

Предположим, что общее внешнее хранилище (подключенное к каждому хосту ESXi с использованием iSCSI или Fibre Channel SAN) уже представлено всем хостам VMWare ESXi, на которых запущены виртуальные машины, которым вы хотите добавить общий виртуальный диск. На обеих виртуальных машинах вам нужно добавить новый контроллер SCSI. Объясню для чего нужно добавлять новый SCSI Controller. Когда вы создаете новую виртуальную машину ESXI у вас по умолчанию уже будет один LSI Logic SAS контроллер (SCSI Controller), но он работает во первых в режиме SCSI Bus Sharing «None», то есть не работает с общими дисками VMDK, это можно поправить при выключенной машине, но VMWare не рекомендует совмещать при работе обычных дисков и Multi-Writer VMDK дисков на одном LSI Logic SAS контроллере.

Поэтому нам первым делом необходимо в свойствах виртуальной машины добавить новый SCSI Controller.

Если посмотреть подсказку у LSI Logic SAS контроллера, то вы увидите три его режима:

• None — для работы с не кластерными Multi-Writer дисками
• Physical — виртуальные диски могут быть общими для виртуальной машины и физическим сервером
• Virtual — для работы с общим диском для нескольких виртуальных машин

Делается это через пункт «New Device» и нажатии кнопки Add, для SCSI Controller.

Далее у нового, добавленного контроллера вы в пункте «SCSI Bus Sharing» выберите тип «Virtual». Можете сохранить конфигурацию виртуальной машины, через нажатие кнопки «Ок»

Далее на первой машине, где мы только что добавили новый контроллер, вам нужно создать новый виртуальный диск, делается это так же, через пункт «New Device»

Откройте параметры нового виртуального диска. Для того, чтобы сделать его общим между виртуальными машинами VMware ESXI, вам необходимо выставить соответствующие настройки:

• Disk Provisioning — Делает толстый диск с занулением «Thick provision Eager zeroed thick disks», нужен для кластеризации, о типах дисков ESXI, читайте по ссылке.
• Sharing — тут вы как раз выбираете режим общего диска «Multi-Writer»
• Disk Mode — режим работы диска выставите «Independent Persistent» (Подробнее про режимы работы ESXI дисков), данный режим работы не позволит использовать vStorage APIs, что не даст создавать на таком диске снапшоты. Данный режим рекомендуется самим вендором VMware и его партнерами, такими как Oracle. Если бы мы разрешили создание снимков на этом диске, то это могло бы привести к потере данных. Так если у вас на этом диске быдет база SQL и вы будите использовать Veeam Backup, то у ваших резервных копий на уровне самого SQL могут быть проблемы при восстановлении из них, так как точка отсчета с которой нужно будет выстраивать цепочку бэкпов будет нарушена Veeam, который сдвинет точку бэкапа на себя. Если выставлен Independent Persistent, то в Veeam при создании бэкапа этой виртуальной машин можно исключить нужные диске, где стоят SQL или Oracle.
• Virtual Device Node — выберите наш новый LSI Logic SAS контроллер, работающий в режиме «SCSI Bus Sharing Virtual»

Далее я для своего удобства, хочу чтобы общие диски лежали в отдельной папке, а так как они по умолчанию создаются в папке с виртуальной машиной да и еще имеют имя дисков, как имя машины_цифра, я бы такое хотел поправить. Для этого я в конфигурации виртуальной машины удаляю все созданные диски, но я не ставлю галку «Delete files from datastore», то есть по сути на датасторе они остаются.

Далее я иду на датастор на котором находится виртуальная машина с общими дисками (Datastore — Browse Files).

Нахожу нужные мне Multi-Writer диски. Создаю новую папку

И перемещаю в новую папку общие диски, хочу отметить, что вы их можете переместить на любой общий между хостами ESXI датастор.

Я делаю «Move to» на тот же латасторе, но в новую папку. Этим я добьюсь, что буду видеть явным образом общие кластерные диски.

Так как я диски до этого удалил, для удобства, то мне их нужно заново добавить. Если вы до этого не удаляли, то сделайте эти действия только для второй виртуальной машины. Открываем настройки виртуальной машины и нажимаем добавить новое устройство, выбираем пункт «Existing Hard Disk», это у нас выбор существующего общего кластерного диска.

Указываем на каком датасторе у нас лежит Multi-Writer диск и выбираем нужный VMDK, в моем случае их семь.

Выставляем нужные параметры:

• Disk Provisioning — «Thick provision Eager zeroed thick disks»
• Sharing — «Multi-Writer»
• Disk Mode — «Independent Persistent»
• Virtual Device Node — выберите наш новый LSI Logic SAS контроллер, работающий в режиме «SCSI Bus Sharing Virtual»

Если такой диск не один, то добавляем все за один раз для экономии времени. Проделываем такое добавление общих дисков на всех виртуальных машинах, где планируется использовать Multi-Writer.

Далее уже в операционной системе Windows Server, зайдя в оснастку «Управление дисками» вы обнаружите ваши диски. Остается их только разметить в GPT формат и отдать под кластер.

Включение общего диска для ESXI 5.5 и ниже

В более ранних версиях гипервизора Vmware ESXI 5.5 и ниже, общий кластерный диск выключается таким образом. Вы заходите так же в свойства виртуальной машины и добавляете там новый SCSI Controller с типом работы «Virtual».

Затем вы создаете новый диск, указываете его размер и тип Thick Provision Eager Zeroed.

Далее Vmware ESXI 5.5 попросит вас выбрать Выбор LSI Logic SAS контроллер, обязательно укажите тот, что мы создали заранее и запомните порт SCSI к которому вы его подключаете в моем примере, это SCSI (1:0).

Далее в настройках виртуальной машины вам необходимо перейти на вкладку «Option — General» и нажать кнопку «Configuration Parameters».

В самом конце для каждого общего диска пишем в имени номер SCSI порта SCSI1: 0.sharing в поле «Value» пишем multi-writer.

Для второй виртуальной машины делаем те же действия, единственное на этапе создания диска, выбираем пункт существующего «Use an existing virtual disk»

Через кнопку «Browse» указываем путь до него.

Выбираем сам VMDK диск. После чего не забываем так же прописать на вкладке «Option — General» и нажать кнопку «Configuration Parameters», для каждого общего диска пишем в имени номер SCSI порта SCSI1: 0.sharing в поле «Value» пишем multi-writer.