Добавление witness appliance к vCenter Foundation и vSphere Essentials.

Posted Leave a commentPosted in vSAN, Виртуализация VMware

У VMware есть такие лицензии, как vSphere Essentials (Essentials и vSphere Essentials Plus) и vCenter Foundation. Особенность этих лицензий в том, что они позволяют управлять ограниченным количеством хостов ESXi.

vSphere Essentials и vSphere Essentials Plus. Эти два бандла применимы только к инфраструктуре, состоящей максимум из трех хостов.

vCenter Server Foundation поддерживал только три хоста. А с версии vSphere 6.5 Update 1 – количество хостов было увеличено до 4-х.

Очень часто эти лицензии упоминаются в контексте vSAN for ROBO. И не менее часто авторы высказывали сожаление по поводу того, что хотя witness appliance и не является полноценным хостом, т.е. на нем нельзя размещать вирутальные машины, но, тем не менее, с точки зрения лицензирования виртуальный ESXi считается как полноценный хост.

В этой связи радостной новостью оказался пост Дункана Эппинга: “Adding a fifth (virtual) ESXi host to vCenter Foundation: “К счастью, есть обходной путь. Это довольно просто, и это связано с порядком добавления хостов в vCenter Foundation. Если вы добавляете witness перед физическими узлами, то appliance не учитывается при лицензировании”.

Также Дункан делится ссылкой на официальную документацию VMware vCenter Server 6.5 Update 2 Release Notes:

“Не удается добавить witness virtual machine на сервер vCenter с лицензией Essentials

Когда witness host для stretched cluster (растянутого кластера) это appliance, который находится на виртуальной машине, он неправильно использует лицензию хоста. Эта проблема возникает из-за того, что vCenter Server считает, что witness appliance является физическим узлом. Если ваша лицензия не распространяется на дополнительный хост, вы не можете добавить witness appliance на сервер vCenter.

Обход проблемы: добавьте witness appliance VM в vCenter Server, прежде чем добавлять физические хосты.”

Вариант использования лицензии vSphere Essentials описан мной в статье Архитектура 2-node vSAN 6.6. Лицензирование vSAN ROBO.

Добавление хоста к vSAN Cluster

Posted Leave a commentPosted in vSAN, Виртуализация VMware

Как я писал в прошлой статье Гиперконвергентная инфраструктура. VMware vSAN. “Быстрее, выше, сильнее!”: “С помощью vSAN можно добавить один диск на один хост, заменить существующие диски на устройства большей емкости, добавить или заменить несколько дисков, а также добавить или заменить один или несколько хостов – все без нарушения существующих рабочих нагрузок. Добавление ресурсов выполняется всего несколькими щелчками мыши.” (далее…)

Гиперконвергентная инфраструктура. VMware vSAN. “Быстрее, выше, сильнее!”

Posted Leave a commentPosted in vSAN, Виртуализация VMware

В декабре 2017 года вышла статья Десять лучших гиперконвергентных решений 2017 года, которая начинается словами: “Сегмент гиперконвергентной инфраструктуры продолжает развиваться с головокружительной быстротой.” В статье не могли обойти вниманием и VMware vSAN:

“ПО виртуализации хранения vSAN (Virtual SAN), разработанное компанией VMware, весомо заявило о себе на рынке гиперконвергентной инфраструктуры, и последняя версия vSAN 6.6 включает встроенное, программно-конфигурируемое шифрование долговременно хранимых данных. Улучшения помогают также упростить выбор оборудования, и предложен не мешающий работе инструмент анализа, помогающий отслеживать рабочие нагрузки.” (далее…)

Архитектура 2-node vSAN 6.6. Лицензирование vSAN ROBO.

Posted Leave a commentPosted in vSAN, Виртуализация VMware

В статьях 2-node vSAN cluster. Witness Appliance FailureРежим обслуживания (maintenance) в 2-Node Direct Connect vSAN configuration я затронул вопросы функционирования 2-node VMware vSAN. Сейчас я подробнее остановлюсь на архитектуре 2-node vSAN кластера и лицензировании vSAN for ROBO.

Как я уже писал, vSAN – отличное решение для удаленных офисов и филиалов – Remote Office / Branch Office (ROBO).

(далее…)

Режим обслуживания (maintenance) в 2-Node Direct Connect vSAN configuration.

Posted Leave a commentPosted in vSAN, Виртуализация VMware

В прошлой статье 2-node vSAN cluster. Witness Appliance Failure я упоминал о таком режиме работы 2-node vSAN cluster как 2-node ROBO Direct Connect, позволяющем подключить 2 vSAN-хоста в удаленном офисе напрямую. Если вы используете именно такую схему, то необходимо учитывать один нюанс. При включении режима обслуживания на хосте, который отмечен как “preferred fault domain” (предпочтительный домен ошибок) могут возникнуть проблемы с его доступностью. О чем пишет Дункан Эппинг в своей статье Doing maintenance on a Two-Node (Direct Connect) vSAN configuration. Судя по комментариям эта проблема может и не возникнуть, но лучше подстраховаться. Тем более что решение довольно простое.  При выполнении обслуживания на хосте, который находится в “preferred fault domain” необходимо изменить предпочтительный домен ошибок: Change the Preferred Fault Domain:

  • В кластере vSAN выбрать Fault Domains and Stretched Cluster.
  • Выбрать secondary fault domain и нажать на иконку Mark Fault Domain as preferred  Stretched Cluster
  • Перевести хост в maintenance mode
  • Выполнить обслуживание.

2-node vSAN cluster. Witness Appliance Failure

Posted Leave a commentPosted in vSAN, Виртуализация VMware

В данной статье я рассмотрю роль vSAN Witness Appliance в 2-узловом кластере vSAN.

А чем интересен 2-node vSAN cluster? Прежде всего сферой его применения – он может быть очень эффективным в небольшой компании или филиале: 2-node vSAN for ROBO (remote office/branch office). В версии vSAN 6.5 была реализована  схема 2-node ROBO Direct Connect, позволяющая подключить 2 vSAN-хоста в удаленном офисе напрямую, без необходимости использования 10Gb коммутатора. Достаточно только кросс-сетевого кабеля! Учитывая, что 10Gb сетевое подключение требуется для all-flash конфигурации (и очень рекомендуется для гибридной) ROBO Direct Connect позволяет  значительно сократить затраты для построения производительной инфраструктуры. 

(далее…)

Предупреждение при проверке совместимости контроллера Intel VMD с vSAN

Posted Leave a commentPosted in vSAN, Виртуализация VMware

В статье Проверка совместимости оборудования с vSAN – инструмент vSAN HCL viewer я при тестировании данного инструмента выяснил, что мой контроллер Huawei ES3000 V2 показывал предупреждение vSAN Health check (vSAN Cluster> Monitor> Virtual SAN> Health), поскольку его тестирование на совместимость было проведено инженерами VMware уже после установки мной обновления ESXi.

Как оказалось, это не единичный случай. Согласно https://kb.vmware.com/s/article/55842 vSAN Health check может показывать ложное предупреждение также для контроллеров Intel VMD. В этом случае VMware предлагает игнорировать это предупреждение.

Отсюда можем сделать важный вывод: если вы получили подобное предупреждение, и ваш all.json не загружается автоматом – не ленитесь, обновляйтесь вручную.

Тестирование отработки отказа APD на iSCSI LUN

Posted Leave a commentPosted in Виртуализация VMware

Дункан Эппинг (Duncan Epping) в своем блоге Trigger APD on iSCSI LUN on vSphere поделился способом протестировать обработку отказа APD (All Paths Down).

APD – это когда хост-сервер ESXi не может получить доступ к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. В версии VMware vSphere 6.0 появился механизм VM Component Protection (VMCP), который позволяет обрабатывать эту ситуацию со стороны кластера высокой доступности VMware HA в том случае, если в нем остались другие хосты, имеющие доступ к виртуальной машине, оставшейся без “хост-хозяина”. (Более подробно о APD (All Paths Down) и PDL (Permanent Device Loss) можно почитать здесь VM Component Protection (VMCP) в VMware vSphere 6).

Так вот, попробовав различные вещи, такие как убийство демона iSCSI (он автоматически перезапускается без какого-либо влияния на рабочую нагрузку), Дункан Эппинг столкнулся с этой командой, которая вызвала APD:

  • SSH на хост, на котором вы хотите включить APD, выполните следующую команду
    esxcli iscsi session remove   -A vmhba65
  • Обязательно замените «vmhba65» на имя вашего адаптера iSCSI

Это вызвало APD, как свидетельство в fdm.log и vmkernel.log, и в конечном итоге привело к тому, что vSphere HA убил подвергнутую воздействию виртуальную машину и перезапустил ее на здоровом хосте.

Данный способ протестировать ответы APD может быть полезен в лабораториях или до того, как виртуальная инфраструктура войдет в продакшн.

PowerCLI. Дата файла DB VSAN HCL.

Posted Leave a commentPosted in PowerCLI, vSAN, Виртуализация VMware

В статье Проверка совместимости оборудования с vSAN – инструмент vSAN HCL viewer я затронул вопрос обновления файла all.json – базы данных (DB VSAN HCL), содержащей  информацию о поддерживаемых продуктах в руководствах по совместимости VMware и используемая при проверках vSAN Health.

Дата файла отображается в Configure\Health and Performance. Но дату также можно проверить через PowerCLI с помощью командлета Get-VsanClusterConfiguration:

Также существует команлет обновления DB VSAN HCL: Update-VsanHclDatabase, загружающий файл all.json непосредственно из интернета, но лично у меня он не отработал. Получилось обновиться лишь с помощью Update-VsanHclDatabase -FilePath all.json, т.е. путем ручного создания файла. Но при ручном  создании файла проще обновить базу вручную через консоль vCenter.

Кстати, отображаемая дата – это дата файла. Т.е. если мы обновимся со старого фала, то получим следующее:

Проверка совместимости оборудования с vSAN – инструмент vSAN HCL viewer.

Posted Leave a commentPosted in vSAN, Виртуализация VMware

Недавно я писал о том, как проверить совместимость IO-контроллеров, HDD и SSD дисков с различными версиями vSAN – vSAN Compatibility Guide. В данной статье я расскажу еще об одном интересном способе проверить совместимость оборудования с vSAN – инструменте vSAN HCL viewer.

vSAN HCL viewer создал Харальд Рупперт (Harald Ruppert) – инженер по эскалации vSAN в VMware и разместил по адресу https://hcl.captain-vsan.com/index.php.

Посмотрим как этот инструмент работает. (далее…)