Технология vmware vsan как элемент гиперконвергентной системы для облачных провайдеров

Описание тестового стенда

Железо

4 идентичных хоста в следующей конфигурации:

• Платформа — AIC SB302-LB (3U 16-Bay Storage Server, не сертифицирован под vSphere 6.2)
• Процессор — Intel Xeon CPU E5-2620 v4 @ 2.10GHz – 8 ядер, включен hyper-threading – 2шт.
• ОЗУ – 128 ГБ
• NVMe-flash — HGST Ultrastar SN100 Series NVMe SSD HUSPR3216ADP301 1,6ТБ PCIe – 2шт (сертифицирован под Virtual SAN 6.2, только под all-flash, но думаю это не принципиально)
• HDD — HGST Ultrastar 7K6000 HUS726020AL5214 2ТБ 7200 rpm SAS 12Гбит/с – 8шт (не сертифицирован под Virtual SAN 6.2, только под 6.5)
• Загрузочный носитель – SSD 60ГБ
• Дисковый контроллер — LSI Logic Fusion-MPT 12GSAS SAS3008 PCI-Express (сертифицирован под vSphere 6.2, но не сертифицирован под Virtual SAN 6.2)
• 2 порта 1GbE
• 2 порта IB 40Гбит/с – на HCA Mellanox ConnectX-2/ConnectX-3 в режиме IPoIB

IB-коммутатор Mallanox SB7790

ПО: VMware vSphere 6.2

vCenter Server Appliance 6.0.0.20100

ESXi 6.0.0.4600944

Версия драйвера Mallanox ConnectX-3 для VMware для работы в режиме IPoIB: MLNX-OFED-ESX-2.4.0.0-10EM-600.0.0.2494585

Описание кластера Virtual SAN

Пробная лицензия vSphere — полный фарш

vCenter Server Appliance развернут в виде ВМ на выделенном локальном загрузочном SSD одного из хостов

Кластер HA из 4х хостов, на нем же развернут кластер Virtual SAN (vSAN)

Virtual SAN задействует все носители 4х узлов кластера vSphere (за исключением загрузочных SSD): 8 идентичных дисковых групп (ДГ) – по 2 на хост; каждая ДГ включает 1 NVMe-flash под кэш и 4 HDD под capacity. Получаем гибридное хранилище с сырой общей ёмкостью 57,64ТБ — 32 capacity drive по 1,82ТБ (реальная ёмкость диска 2ТБ)

Интерфейс

http

Раздел — Cluster Hosts Information

«Deploy on Hosts»«Hosts»«Clear Read/Write Cache»«Host Username»«Host Password»«Hosts»«Deploy on Hosts»«Deploy on Hosts»«Deploy on Hosts»«EASY RUN»

Раздел — Vdbench Testing Configuration

«Test Name»/opt/output/results/http«Generate»«Upload parameter file»«Refresh»«Select a Vdbench parameter file»«Select a Vdbench parameter file»«Delete»Рекомендация
Меню «Select a Vdbench parameter file» кроме имен файлов параметров содержит строку «Use all». Вместо того, чтобы для каждого типа нагрузки, которому соответствует свой файл параметров, запускать отдельный тест, целесообразно подготовить набор файлов параметров под каждый тип интересующей нагрузки и выбрать «Use all». В этом случае фреймвёрк сам последовательно проведет все эти тесты и отдельно сохранит их результаты. Это удобно, поскольку продолжительность хорошего теста составляет не менее 1,5 часов, типов нагрузки которую нужно оценить много, отслеживать завершение и запускать каждый тест вручную неудобно, а так можно запустить разом всю последовательность, например, на ночь или на сутки и спокойно утром получить все результаты разом.«Prepare Virtual Disk Before Testing»«NONE»«ZERO»«RANDOM»«RANDOM»«Testing Duration»«Clean up VMs»

Настройка параметров Vdbench

«Generate»Number of Disks to Test«Number of Data Disk»«Re-Use The Existing VMs If Possible»Working-Set PersentageNumber of Threads per DiskBlock SizeI/O RateTest TimeWarmup TimeReporting interval

Рекомендации по планированию тестов

Каждое тестирование требует подбора правильных параметров исходя из характеристик хранилища и виртуальной инфраструктуры. Основной критерий правильных параметров: выжать из хранилища максимальные показатели производительности (IOPS и Throughput) и сохранить значения задержки (Latency) в разумных пределах. Разумные пределы задержки либо её чёткий порог у каждого свои и определяются задачей: кому-то нужна задержка < 4-10 мс (миллисекунд), кому-то некритично если будут десятки мс (даже пара сотен), а кому-то важны микросекунды.
В случае тестирования VMware vSAN для начала можно запустить «EASY RUN», посмотреть на его показатели и параметры, а затем пробовать их менять и перебирать для получения оптимального результата. Для других хранилищ при подборе параметров придется полагаться на собственный опыт и здравый смысл (провел тест, посмотрел отчет, попробовал увеличить нагрузку, либо снизить если задержки большие). Естественно это долгий процесс, может уйти не один день или даже неделя.
Параметры, с которыми можно поиграться:
• количество тестовых ВМ, минимум 2 ВМ на хост;
• количество вДисков, в среднем 10 вДисков на ВМ;
• объем вДисков, 1-10-20 ГБ на вДиск, возможно больше, все зависит от объемов хранилища и кэша;
• количество потоков на вДиск, про это я писал выше;
• доля пространства вДиска, про это я писал выше.
Очень важен суммарный объем пространства хранилища, которое будет тестироваться. Он складывается из пространства всех вДисков тестовых ВМ. Например, мы тестируем гибридное хранилище. Если суммарный объем помещается в кэш и не будет вытесняться на медленное постоянное хранилище, то мы получим крутую производительность. Если помещается в кэш, но занимает его почти полностью, так что логика хранилища всё равно начинает потихоньку вытеснять данные, мы получим более низкую производительность. Если суммарный объем занимает большую часть основного хранилища и во много раз превышает кэш, то мы проведем тест в самых жёстких условиях и производительность будет минимальной, но самой честной.
Кстати, это надо учитывать, анализируя показатели производительности, которые заявляют производители СХД. Ваш результат может оказаться сильно хуже, поскольку производитель всё протестил честно, но забыл упомянуть, что всё его тестируемое пространство находилось в кэше.

Сохранение и проверка конфигурации, запуск теста

«Save Configuration»«Validate»«All the config has been validated, please go ahead to kick off testing»«Test»«Save Result»

Особенности

Ускорение модернизации инфраструктуры с помощью VMware vSANTM превращает ИТ в стратегическое и экономическое преимущество для вашей компании. Благодаря использованию ведущих на рынке решений vSAN в качестве основы для гиперконвергированной инфраструктуры заказчики получают возможность развивать ЦОД без риска, управлять ИТ-расходами и готовиться к решению будущих задач. Решение vSAN, встроенное в ведущий на рынке гипервизор, обеспечивает оптимизированное для флэш-накопителей и безопасное хранилище для всех критических рабочих нагрузок vSphere.
vSAN базируется на стандартных серверах и компонентах x86, которые способствуют снижению совокупной стоимости владения на 50% по сравнению с традиционными хранилищами. Оно обладает адаптивностью, необходимой для удобства масштабирования ИТ-среды, и отличается первой в отрасли встроенной подсистемой шифрования для гиперконвергированной инфраструктуры. Новые усовершенствованные распределенные кластеры и интеллектуальные операции в 1 действие сокращают расходы, в результате чего становится более умеренной стоимость защиты среды (на 50% меньше, чем у ведущих традиционных решений) и упрощается повседневное управление. Кроме того, полная интеграция с VMware vSphere и всеми продуктами VMware делает это решение самой удобной платформой хранения для любых рабочих нагрузок виртуальных машин — важных баз данных, виртуальных компьютеров или приложений нового поколения.

2018

Virtual SAN V8 (build 12585)

В октябре 2018 года StarWind Software выпустила обновление своего продукта для создания отказоустойчивых программных хранилищ под виртуализацию StarWind Virtual SAN V8.

В Virtual SAN V8 (build 12585) от 25 октября появились:

• Виртуальная ленточная библиотека VTL и функции облачной репликации (Cloud Replication)
  • Добавлена поддержка ленточных устройств LTO8.
  • Добавлены команды PowerShell для управления устройствами VTL и настройками Cloud Replication.

• Демо-версия NVMf Target.

  • Простой NVMf Target можно создать в демонстрационных целях. Существующий NVMf initiator можно теперь использовать для соединения с этим таргетом.
  • Простые устройства RAM Disk и Flat Storage теперь поддерживаются. Например, рекомендуется использовать сетевые адаптеры Mellanox RDMA-enabled с последними драйверами от производителя.
  • Также можно использовать любые другие адаптеры, которые реализуют слой NetworkDirect API.
  • Учитывайте, что процесс установки StarWind VSAN перезаписывает конфигурационный файл NVMf Target.
  • Для обновленной версии запросите другой лицензионный ключ — как для издания Free, так и для триальной лицензии.

• Улучшения синхронной репликации.

• Изменения Management Console.

  • Раздел помощи был пермещен
  • Другие полезные ссылки были добавлены в меню Help.

• Улучшения ядра.

Обновление StarWind Virtual SAN v8 build 12146 и 12166

30 мая 2018 года компания StarWind объявила о выпуске обновления решения для создания программных iSCSI-хранилищ под виртуализацию — StarWind Virtual SAN.

В StarWind Virtual SAN v8 build 12146 и 12166 появилось:

• Для модуля Cloud Replication появилась поддержка Backblaze B2 Cloud Storage.
• Для синхронной репликации и режима обслуживания (maintenance mode) события, описанные в Event Log, стали более детализированными.
• Несколько изменено поведение кластера — теперь при ручном отключении двух партнерских HA-устройств на сервере оставшийся узел выпадает в состояние «not synchronized». Также если выпадает HA-устройство, а затем Witness-узел, то при возвращении Wintness-узла в онлайн — работоспособность кластера автоматически восстанавливается.
• Теперь отсутствует интервал в 30 секунд между отправкой email-нотификаций, также можно поменять SMTP-порт.
• Если хранилище создается на устройстве, которое некорректно сообщает о размере физического сектора, StarWind все равно позволяет его создать, но с предупреждением.
• Для управления модулем VTL появилась функциональность StarWindX PowerShell.
• Для LSFS была исправлена проблема на устройствах pre-V8R6 (при заполненности данными более 1,2 ТБ могла произойти потеря данных при рестарте сервиса). Были исправлены и некоторые проблемы апгрейда LSFS с релиза V8R5. Также было улучшено поведение LSFS при высоких нагрузках (изменена процедура дефрагментации).
• В Management Console была добавлена поддержка новой версии продукта StarWind VSA 2.0.
• Было сделано множество исправлений ошибок с HA-устройствами, снапшотами и хранилищами.

Дьявол в деталях

Хотим поделиться еще несколькими нюансами, не все из которых были задокументированы на момент реализации нашего проекта.

Не забудьте сконфигурировать Anti-affinity правила, чтобы оба узла виртуального кластера случайно не оказались на одном гипервизоре. Для этого потребуется лицензия VMware vSphere Enterprise Plus с ее функционалом DRS.

Даже несмотря на то, что использовать снапшоты нельзя, администраторы системы резервного копирования (СРК) могут случайно поставить на безагентский бэкап ваши виртуальные машины. Пара кликов мыши в консоли управления СРК — и кластер из двух узлов неработоспособен. Расследование инцидента показало следующее: СРК принудительно включает CBT на виртуальном диске (а как мы уже зафиксировали, данная технология не поддерживается с multi-writer диском) и при первой попытке записать что-то на виртуальный диск гипервизор сыпет ошибками. Чтобы избежать этого, мы рекомендуем:

добавить параметр ctkDisallowed=»true» (он был описан в базе знаний VMware, но по неизвестным причинам статья закрыта);

в СРК контрольно добавить в исключения общие диски узлов кластера.

Начиная с версии VMware vSphere 6.7 P01 (build 15160138) на vSAN можно не использовать общие диски в формате thick eager-zeroed. До этой версии общие диски приходилось создавать вручную из командной строки с помощью утилиты vmkfstools.

А с версии VMware vSphere 6.7 Update 3 (build 14320388) vSAN поддерживает SCSI-3 persistent резервации, но применение технологии SCSI-3 PR IO fencing с общими VMDK-дисками в Veritas Cluster не поддерживается. Для арбитража ситуации Split Brain требуется задействовать Coordination Point Server.

Проектирование VSAN

Относительная простота развертывания отнюдь не отменяет тщательного проектирования архитектуры VSAN. Вот несколько моментов, на которых стоит остановиться подробнее:

1. Совместимость с аппаратным обеспечением. Хотя VSAN и дает определенную свободу в выборе «железа», имеет смысл оставаться в рамках списка гарантированно совместимого с VMware VSAN оборудования. Так не придется наугад подбирать совместимые контроллеры, адаптеры и пр.
2. Сеть. В конфигурации с VSAN ВМ может работать в одном месте, а храниться – в другом. Это предъявляет достаточно высокие требования к сети: у вас должна быть как минимум 10 GB сеть.
3. Производительность дисковых контроллеров. Дисковый контроллер должен обеспечивать объемный буфер для большой очереди команд. Нагрузка на него будет значительная: контроллер будет отдавать данные, нужные не только этому серверу, но и всему кластеру. Например, при восстановлении выбывшей дисковой группы на новую группу нужно записать большой объем данных за короткое время. Скорость записи как раз и будет зависеть от производительности контроллера.
4. Объем дисков. В данной ситуации больше не означает лучше. Скорее наоборот. Хотя сейчас доступны диски по 4, 6 ТБ, VSAN лучше строить из дисков объемом 1 ТБ. Давайте представим аварийную ситуацию, когда в кэш ничего не попадает (замена «полетевшей» дисковой группы, бэкап или восстанавление бэкапа): 6 ТБ диски будут восстанавливаться в 6 раз дольше, чем 1 ТБ диски (если отталкиватьcя от отношения скорости чтения к объему хранимых данных – IOPS/GB).
5. Соотношение объема SSD к объему жесткого диска. Оно будет напрямую влиять на итоговую производительность дисковой группы: чем больше емкость SSD (чем больше данных будет в кэше), тем выше производительность. В CloudLITE для кэширования используются PCIe флеш-карты — они обладают меньшими задержками по сравнению с SSD. Кстати, в VSAN версии 6.0 поддерживаются дисковые группы, состоящие только из SSD.
6. Соотношение вычислительных мощностей к дисковому пространству. При проектировании VSAN нужно все тщательно просчитывать: соотношение процессоров, памяти и количество дисковых групп, а также рассчитать, в каком соотношении наращивать вычислительные мощности, чтобы это было экономически выгодно.

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

Пример работы

Поскольку возможности Virtual SAN достаточно многогранны, рассмотрим один из актуальных сценариев: конфигурации кластера хранилища VMware Virtual SAN 6.1 для удаленного офиса. Процедура достаточно простая. Для первоначальных шагов необходимо переключиться в консоль управления VMware vSphere Web Client и запустить процесс добавления двух физически доступных хостов в кластер (см. рисунок 1):

Рисунок 1 — Перемещение выбранных хостов в кластер

При перемещении хостов в кластер в окне Move Host into This Cluster необходимо определить, что именно вы хотите сделать с виртуальными машинами и пулом ресурсов. Возможен следующий вариант: поместить все виртуальные машины хоста в корневой пул кластера или создать новый пул. В приведенном примере оставляем значение по умолчанию.
Далее предлагаем рассмотреть, как добавляется диск, используемый в качестве хранилища. Для этого следует зайти в свойства кластера, выбрать закладку Manage и выполнить редактирование настроек как показано на рисунке. Есть два варианта добавления диска: ручной и автоматический (рисунок 2):

Рисунок 2 — Редактирование параметров Virtual SAN

Далее переходим к конфигурации расширяемого кластера VSAN, для этого необходимо перейти в закладку Fault Domains.
Первоначально необходимо настроить домены отказа, обозначив предпочтительный, первичный (Preferred fault domain) и вторичный домены отказа, задав каждому из них имена и закрепив за каждым соответствующий хост или набор хостов (рисунок 3):

Рисунок 3 — Настройка VSAN-кластера

Дальше предлагается настроить Witness Host, который будет определять и дифференцировать вышедший из строя узел. В окне Select a witness host необходимо выбрать узел, который будет хранить все Witness-компоненты VSAN-кластера (рисунок 4):

Рисунок 4 — Определение диск-группы

В окне Ready to complete следует проверить заданные параметры и, если все верно, завершить работу мастера. Теперь, когда настроена основная конфигурация, самое время выполнить проверку функциональности. Для этого создадим новую виртуальную машину и посмотрим на ее физическое расположение. В контекстном меню кластера выбираем опцию New Virtual Machine и создаем новую виртуальную машину. Используем политику VM Storage, заданную по умолчанию (рисунок 5):

Рисунок 5 — Обзор политики хранилища

После того как виртуальная машина была успешно развернута, проверим, где располагаются ее компоненты. В закладке Physical Disk Placement видно, что компоненты виртуальной машины разнесены должным образом согласно выполненной конфигурации (рисунок 6):

Рисунок 6 — Проверка «разнесенности» виртуальной машины

Концепция vSAN

Концепция vSAN заключается в том, что на каждом хосте ESXi может быть от 1 до 5 дисковых групп, которые в свою очередь содержат:

• Гибридная конфигурация: от 1 до 7 магнитных диска и обязательно — минимум один SAS/SATA SSD, или PCIe flash диск. Магнитные диски используются для хранения данных, а SSD, или Flash — в качестве кэша данных.
• “All-flash” конфигурация (доступна в vSAN 6.0 и выше): все диски группы могут использоваться, как для кэша, так и для хранения данных.

Носитель, отданный для организации vSAN и объединенный в дисковую группу, используется полностью для организации системы хранения, его нельзя совместно использовать для других целей. Дисковые группы объединяются в пул, доступный всему кластеру vSphere, и организуют общее “внешнее” и отказоустойчивое хранилище, для передачи данных которого используется собственный протокол (FC, iSCSI или NFS для обмена данными не нужны). Данные дисковых групп и блоки “четности” дублируются на одном, или нескольких хостах, в зависимости от выбранных параметров отказоустойчивости vSAN:

• Number of failures to tolerate — количество допустимых отказов, определяет количество хостов кластера отказ которых сможет пережить ВМ.
• Failure tolerance method — метод обеспечения отказоустойчивости.

vSAN предоставляет два метода обеспечения отказоустойчивости:

• RAID1 (Mirroring). По умолчанию Number of failures to tolerate равен одному, то есть данные дублируются на одном хосте: все операции чтения записи моментально синхронизируются на втором хосте (таким образом накладывая серьезные требования на пропускную способность сети, но об этом ниже). В случае отказа одного из хостов все операции чтения/записи будут перенаправлены на “зеркало”. Если Number of failures to tolerate равен двум, то данные реплицируются уже на двух хостах. Данный метод неэффективно использует дисковое пространство, однако обеспечивает максимальную производительность. Минимально необходимое количество хостов — 2–3 (для опеспечения одной отработки на отказ), рекомендуемое — 4 хоста (при отказе одного их хостов дает возможность ребилда).
• RAID5/6 (Erasure Coding). Поддерживается только “all-flash” конфигурация кластера. Позволяет кластеру отработать 1 (аналог RAID5), или 2 отказа (аналог RAID6). Минимальное количество хостов для отработки 1 отказа равно 4, для отработки 2-х отказов равно 6, рекомендуемые минимумы 5 и 7, соответственно, для возможности ребилда. Данный метод позволяет достичь значительно экономии дискового пространства в ущерб производительности, однако при “all-flash” конфигурации данной производительности может оказаться достаточно.

vSAN позволяет по-разному обеспечивать отказоустойчивость для различных ВМ или их дисков: в рамках одного хранилища можно для критичных к производительности ВМ привязать политику с зеркалированием, а для менее критичных ВМ — настроить Erasure Coding.

vSAN представляет из себя объектное хранилище, данные в котором хранятся в виде объектов, или “гибких контейнеров” (flexible containers), распределенных по всему кластеру. Управление хранением осуществляется с помощью политик Storage Policy Based Management. vSAN допускает изменение политики хранения без остановки ВМ, запуская в фоне процессы перераспределения. При распределении объектов по кластеру vSAN контролирует, чтобы компоненты корректно распределялись по разным узлам, или доменам отказа (fault domain).

Для организации Virtual SAN можно использовать:

• Классическая схема: гипервизор VMware ESXi, установленный на физическом серверном железе, диски которого объединяются в Virtual SAN.
• vSphere Virtual SAN Appliance. Идея заключается в том, что на базе гипервизора VMware ESXi создан OVA-темплейт виртуальной машины, который предназначен для разворачивания компонента vSAN на хосте ESXi.
• vSphere Storage Appliance. Предоставляет возможности общего хранилища, с помощью которых малые и средние компании могут воспользоваться средствами обеспечения высокой доступности и автоматизации без использования дополнительного сетевого оборудования для хранения данных. Имеет ряд недостатков, таких как, отсутствует возможность масштабирования более 3-х хостов.

VMware vSAN: системні вимоги

• Потрібно VMware vCenter Server 6.5 і хости з ESXi 6.5
• Мінімум 3 хоста в кластері (максимум 64), проте можна реалізувати vSAN і на двох хостах, але потрібно окремий хост-свідок
• Кожен сервера ESXi в кластері vSAN повинен мати як мінімум один SSD диск (флешку) для кеша, і як мінімум один SSD / HDD для даних
• Наявність SATA / SAS HBA або RAID-контролера в режимі pass-through або в режимі RAID 0
• Мінімум 1 ГБ мережева карта (рекомендується 10 Гб)
• Всі хости повинні бути підключені до мережі vSAN через мережу L2 або L3
• На фізичних комутаторах, які обробляють трафік vSAN повинна бути включено багатоадресне мовлення (мультикаст)
• Підтримуються як IPv4 так і IPv6.
• Інформацію про сумісність з конкретним залізом потрібно дивитися у відповідному документі на сайті VMware

Внимание к виртуальным дискам

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

Если есть внешняя СХД, то для подобной конфигурации на платформе виртуализации используют RDM-диски. В случае с vSAN применяются виртуальные VMDK-диски с дополнительными настройками. По умолчанию VMware vSphere защищает данные от ошибок администратора, позволяя подключить виртуальный жесткий диск в один момент времени только к одной виртуальной машине. Чтобы обойти это ограничение, для общих виртуальных дисков надо прописать вручную параметр .

Выключаем виртуальную машину и добавляем параметр вида в конфигурационный файл

Также важно не забыть для общих дисков в этом же конфигурационном файле добавить параметр для корректной работы кластерного ПО Veritas

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

1. Нельзя менять размер общего диска «на лету». Для этого придется выключать оба узла кластера и только после этого производить манипуляции с диском. Пожалуй, это самая больная тема. Когда заканчивается место на диске, где лежит критичная БД, становится не до шуток.

   

   

   

   

   

   

   

   

   

   

2. Нельзя использовать снапшоты для общих дисков. Соответственно, нельзя будет использовать средства безагентского резервного копирования для бэкапа данных. Как следствие, технология Change Block Tracking для инкрементального резервного копирования также не поддерживается.

3. Без Storage vMotion миграцию общих виртуальных дисков на горячую выполнить будет невозможно.

Хорошая новость — обычный vMotion для перемещения виртуальных машин между гипервизорами успешно работает.

Развертывание VMware Virtual SAN Appliance.

В настоящий момент актуальной версией VMware Virtual SAN Witness Appliance является . Переходим по и скачиваем OVA-темплейт, подключаемся к Vcenter Server’у через vSphere Client. Можно так же через веб-интерфейс:

 https://<IP_adress_of_vsphere_server>/vsphere-client/

или открываем в vSphere Client пункты меню:

File -> OVF Template

и открываем скачанный OVA-темплейт. В открывшемся мастере будет предложен масштаб для деплоймента (до 10, до 500, или более 500 виртуальных машин), для каждого из которых свои требования к ресурсам виртуальной машины (рис. 1).

Рис. 1. Требования для VMware Virtual SAN Appliance в зависимости от выбранного масштаба.

Если вы разворачивали VMware Virtual SAN Appliance на кластере хостов ESXi на момент настройки vSAN режим vSphere HA лучше отключить. Для этого открываем в vSphere Client по правой кнопкой на кластере “Edit Settings -> Cluster Features” и снимаем чек-бокс с “Turn On vSphere HA”, или переходим в веб-консоли vSphere (рис. 2):

Hosts and clusters -> Cluster_Name -> Manage -> Settings

Рис. 2. Выключение vSphere HA.

Выбираем носитель и формат диска (лучше выбрать “Thin Provision”), используемую сеть (Network Mapping) и задаем пароль. По завершению установки открываем консоль из vSphere Client, логинимся и настраиваем сеть.

Рис. 3. VSAN Port Group.

Можно создать для Virtual SAN трафика отдельный port group на распределенном свитче (distributed switch) (рис. 3). В принципе, для тестовых условий можно трафик не отделять — достаточно разрешить его на существующей виртуальной Сетевой коммутации (поставить чек-бокс, как показано на рис. 4).

Для того, чтобы настроить сеть vSAN VMkernel на распределенном свитче откройте веб-консоль vSphere и выберите режим просмотра “Networking”, а затем:

1. Выберите распределенный свитч, который нужно изменить.
2. Выберите “Manage host networking” и нажмите “Next”.
3. Кликните на “Attached Hosts”, выберите хосты, которые нужно ассоциировать с распределенным свитчем и нажмите “Next”.
4. Выберите “Manage VMkernel adapters”, нажмите “Next” и выберите “New adapter”.
5. На странице выбора выбора устройства выберите существующую группу портов и нажмите “Next”.
6. На странице “ Port properties” ставим чек-бокс на опции “Virtual SAN traffic” (рис. 4) и переходим к настройке VMkernel-адаптера: указываем Network Label, VLAD ID для разделения vSAN-трафика и IP Settings.

Для того, чтобы настроить сеть vSAN VMkernel на стандартном виртуальном свитче (standart virtual switch) в веб-консоли vSphere выбираем режим “Hosts and Clusters”, а затем:

1. Выбираем хост, который нужно сконфигурировать для vSAN, открываем вкладку “Manage” и выбираем “Networking”.
2. Выбираем “VMkernel Adapters”, кликаем на “Add host networking” и кликаем “Next”.
3. На странице выбора выбираем существующий стандартный свитч (standard switch), или создаем новый и кликаем “Next”. Если вы создаете новый, то убедитесь, что вы приаттачили к нему физический сетевой адаптер.
4. На странице “Port properties” ставим чек-бокс на опции “Virtual SAN traffic” (рис. 4) и переходим к настройке VMkernel-адаптера (аналогично п. 6 настройки распределенного свитча).

Рис. 4. Add vSAN traffic.

Подробней о настройке VMware SAN 5.5.x-6.5.x можно прочитать здесь (особое внимание стоит уделить ссылкам на vSphere 6.0 / vSphere 5.5 Networking Guide). Завершающим штрихом в настройке Virtual SAN будет назначение дисковых групп

Дисковая группа — это логический “контейнер” для дисков, используемых vSAN. Каждой дисковой группе нужен минимум один магнитный жесткий диск (HDD), тогда как максимально можно использовать 7. На каждую дисковую группу так же нужен один flash-диск, который является буфером и кэш-слоем для каждой дисковой группы. Очевидно, что любой диск имеет предельную пропускную способность, определенное количество IOPS. Если flash-диск был недоступен, то вся дисковая группа будет недоступна в течении того же промежутка времени. Таким образом, создание дополнительной дисковой группы может служить, как для отказоустойчивости, так и для повышения пропускной способности. Если в цифрах, то наглядный пример иллюстрирован здесь.

Назначаем (Claim) диски для кэша и данных (как показано на простейшем примере на рис. 5) по переходу в веб-консоли vSphere:

Hosts and clusters -> Cluster_Name -> Manage -> Setting -> Virtual SAN -> Disk Management -> Claim Disks

Рис. 5. Claming disks.

Интеграция

запустил облако на базе VMware

• отказоустойчивость;
• производительность;
• масштабирование;
• возможность гарантировать скорость работы;
• корректная работа в экосистеме VMware.

• Dell EMC ScaleIO;
• Datacore Hyper-converged Virtual SAN;
• HPE StoreVirtual.

Архитектура

Изображение взято из официальной документации

• AllFlash-конфигурация (только твердотельные накопители, как для хранения данных, так и для кэша);
• Hybrid-конфигурация (магнитные накопители для хранения данных и твердотельные для кэша).

• отсутствие привязки к производителю оборудования;
• повышенная отказоустойчивость;
• обеспечение целостности данных в случае сбоя;
• единый центр управления из консоли vSphere;
• удобное горизонтальное и вертикальное масштабирование.

Сеть

• предсказуемое расстояние между устройствами;
• трафик идет по наилучшему маршруту;
• легкость масштабирования;
• исключение ограничений протоколов уровня L2.

Отказоустойчивость

1. FTT (Failures To Tolerate). Обозначает количество отказов хостов, которые кластер способен обработать, не прерывая штатной работы.
2. FTM (Failure Tolerance Method ). Метод обеспечения отказоустойчивости на уровне дисков.
   a. Mirroring (зеркалирование).
   Изображение взято из блога VMware
   Представляет собой полное дублирование объекта, причем реплики всегда находятся на разных физических хостах. Ближайшим аналогом такого метода является RAID-1. Его использование позволяет кластеру штатно обработать до трех отказов любых компонентов (диски, хосты, потеря сети и прочее). Этот параметр настраивается посредством задания опции FTT.
   По-умолчанию эта опция имеет значение 1, при этом для объекта создается 1 реплика (всего 2 экземпляра на разных хостах). При увеличении значения, количество экземпляров будет составлять N+1. Таким образом, при максимальном значении FTT=3 на разных хостах будут находиться 4 экземпляра объекта.
   Такой метод позволяет достичь максимальной производительности в ущерб эффективности использования дискового пространства. Допускается использование как в гибридной, так и в AllFlash-конфигурации.
   b. Erasure Coding (аналог RAID 5/6).Изображение взято из блога cormachogan.com
   Работа данного метода поддерживается исключительно на AllFlash-конфигурациях. В процессе записи каждого объекта вычисляются соответствующие блоки четности, позволяющие однозначно восстановить данные при возникновении сбоя. Такой подход существенно экономит дисковое пространство по сравнению с Mirroring.
   Разумеется, работа подобного метода повышает накладные расходы, которые выражаются в снижении производительности. Тем не менее, с учетом производительности AllFlash-конфигурации, этот недостаток нивелируется, делая использование Erasure Coding приемлемым вариантом для большинства задач.
   Кроме того, VMware vSAN вводит понятие «доменов отказа», представляющих собой логическое группирование серверных стоек или дисковых корзин. Как только необходимые элементы сгруппированы, это приводит к распределению данных по разным узлам с учетом доменов отказа. Это позволяет кластеру пережить потерю целого домена, поскольку все соответствующие реплики объектов будут располагаться на других хостах в другом домене отказа.
   Минимальным доменом отказа является дисковая группа, представляющая собой логически связанные дисковые накопители. Каждая дисковая группа содержит в себе носители двух типов — cache и capacity. В качестве cache-носителей система позволяет использовать только твердотельные диски, а в качестве capacity-носителей могут выступать как магнитные, так и твердотельные диски. Кэширующие носители помогают ускорить работу магнитных дисков и уменьшить задержку при доступе к данным.