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

VMware Virtual SAN (или vSAN) — концепция распределенного хранения данных, полностью интегрированная с VMware vSphere на уровне кластера. vSAN — это программная СХД, позволяющаяся абстрагироваться от “железного” хранилища данных и работать с пулами ресурсов, не заботясь о том, где размещены данные виртуальных машин. vSAN собирает из серверов софтварное хранилище, доступное для всех серверов кластера виртуализации, таким образом, позволяя объединить в сервере его вычислительные мощности и функции хранения данных в единый кластер vSphere. Масштабирование Virtual SAN происходит через добавление блока, роль которого выполняет сервер, а управление происходит через единую консоль — vCenter Server.

Концепция 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).

Классическая организация vSAN, с использованием хостов ESXi (возможно так же использование vSAN Appliance и Storage Appliance — об этом чуть ниже), не требует дополнительных плагинов к vSphere — для построения vSAN используются хосты ESXi, а управление доступно через vCenter. vSAN не требует нарезки LUN-ов и файловых шар, презентования их хостам и организации внешнего хранилища и выделенной сети хранения.

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

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

Требования:

  • vSAN не использует более 10% ресурсов процессора.
  • Объем памяти хоста определяется количеством и размером дисковых групп: минимально объем оперативной памяти для участия в кластере vSAN составляет 8Гб, тогда как максимальный (5 дисковых групп по 7 дисков) составляет 32Гб.
  • Не смотря на большой список поддерживаемых серверных платформ, все оборудование и контроллеры ввода-вывода должны быть совместимо с VMware Virtual SAN.
  • Отдельное внимание следует уделить дисковому контроллеру: он должен обеспечивать объемный буфер для большой очереди команд, потому как нагрузка на нем будет весьма ощутимая — он будет читать и писать данные не только для этого сервера, но и для всего кластера. В качестве дискового контроллера может использоваться SAS/SATA HBA или RAID-контроллер функционирующий в режиме “проброса” (passthrough). В этом случае диски отдаются системе, как есть, без создания RAID-массивов: RAID1, RAID5 и тд. В крайнем случае, имеет смысл использовать RAID0-массив для увеличения пропускной способности, тогда как “избыточность” других типов массивов не нужна ввиду отказоустойчивости.
  • Для загрузки хостов могут так же использоваться локальные USB, или SD носители, а также SATADOM. Объем таких носителей должен быть не менее 4Гб. При использовании SATADOM необходимо не менее 16 Гб.
  • 10Гб/с сеть, потому как ВМ может работать на одном сервере, а данные храниться — на другом. В случае отказа одного из серверов данным необходимо синхронизироваться за довольно так и короткий промежуток времени. В тестовых условиях для гибридных конфигцраций можно обойтись пропускной способностью 1Гб/с, но для для “all flash” конфигураций требуется сеть от 10Гб/c. 1Гб/c сеть будет поддерживаться для гибрдидных конфигураций поддерживается, как в версии 5.5, так и в 6.0, но для “all-flash” конфигураций 1Гб/c сеть не поддерживается.
  • Для построения кластера потребуется три хоста ESXi 6.0, управляемые с помощью vCenter Server 6.0, сконфигурированные в кластер. ESXi хосты в vSAN-кластере не могут быть членами какого-либо другого кластера.
  • Для кэширования необходимо минимум 1 SAS/SATA SSD, или PCIe flash disk, тогда как для данных виртуальных машин — по крайней мере 1 SAS, NL-SAS или SATA магнитный диск (HDD). Для “All Flash” конфигураций потребуется, как минимум 1 SAS/SATA SSD, или PCIe flash disk на каждый хост.
  • Объем дисков для дисковых групп может быть любым, но лучше всего использовать 1 или 2Гб (в случае выхода из строя одного из дисков большой объем будет дольше синхронизироваться).
  • Объем SSD, или flash-диска по отношению к объему дисковой группы будет напрямую влиять на производительность: чем больше данных в буфере — тем выше производительность. В гибридной конфигурации 30% кэша выделяется на запись и 70% на чтение. Рекомендуемый размер кэша должен быть не менее 10% от реальной ёмкости ВМ до репликации, т.е. учитывается полезное пространство, а не реально занятое (с учетом репликации). В гибридной конфигурации дисковая группа будет утилизировать всю ёмкость SSD-диска, тогда как максимальный его объем не ограничен.
  • Virtual SAN 6.0 так же поддерживает дисковые группы состоящие только из SSD, или “all-flash” конфигурацию, при которой vSAN использует всю ёмкость кэш-носителей на запись, тогда как кэша на чтение не предусмотрено. В all-flash конфигурации дисковая группа не может использовать более 600ГБ ёмкости установленного flash-носителя, поэтому в таких кластерах лучше использовать носители объемом до 800ГБ.
  • При масштабировании добавлении сервера в кластер следует учитывать не только накопители, но и вычислительные мощности. Использовать сервер только для хранения данных не только противоречит концепции vSAN, но и может оказаться экономически невыгодным.
  • Использование vSAN в промышленной среде подразумевает использование лицензии, которая назначается для кластера, лимит которой исчисляется количеством процессоров. Некоторые дополнительные функции (такие как, “all-flash” конфигурация, software checksum, лимитирование IOPS, дедупликация и декомпрессия) могут потребовать назначение отдельной лицензии для vSAN-кластера. За подробной информацией можно обратиться по этой ссылке.

При планировании инфраструктуры vSAN и подборе оборудования можно ознакомиться с примерами конфигураций, изложенными в виде:

Рекомендуется так же ознакомиться с официальной документацией:

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

В настоящий момент актуальной версией VMware Virtual SAN Witness Appliance является 6.2a. Переходим по этой ссылке и скачиваем 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.

Использование хоста ESXi для Virtual SAN.

Присоединение гипервизора ESXi в Virtual SAN кластер аналогично Virtual SAN Appliance. Разница, в основном, в том, что, минуя виртуализацию, можно использовать потенциал “реального железа”. Алгоритм действий для присоединения ESXi в домен Virtual SAN так же идентичен за исключением того, что используемые для vSAN диски на хосте ESXi необходимо размонтировать и удалить, прежде, чем они будут добавлены в кластер vSAN через веб-консоль vCenter Server’а.

“All-flash” конфигурация.

VMware Virtual SAN 6.0 поддерживает так же “all flash” конфигурацию — архитектуру позволяющую использовать устройства, как для кэширования, так и для записи. Для того, чтобы использовать all-flash-архитектуру нужно пометить диски для хранения информации, как flash-устройство.

Рис. 6. Включение доступа к хосту по SSH.

VMware официально поддерживает конфигурирование хостов и vSAN Appliance по SSH (есть и другие “неофициальные” методы, но он них позже). Включаем доступ по SSH в консоли (рис. 6), логинимся по SSH и для получения списка устройств и установленных флагов вводим:

# vdq -q

и для vSAN Appliance получаем вывод:

[
{
"Name" : "mpx.vmhba1:C0:T2:L0",
"VSANUUID" : "52b5ee15-30fa-7fab-a8bf-64ba871ffce5",
"State" : "In-use for VSAN",
"Reason" : "None",
"IsSSD" : "1",
"IsCapacityFlash": "0",
"IsPDL" : "0",
},
{
"Name" : "mpx.vmhba1:C0:T1:L0",
"VSANUUID" : "52233997-b3ab-64dd-11f0-1f969b06afb8",
"State" : "In-use for VSAN",
"Reason" : "None",
"IsSSD" : "0",
"IsCapacityFlash": "0",
"IsPDL" : "0",
},
{
"Name" : "mpx.vmhba1:C0:T0:L0",
"VSANUUID" : "",
"State" : "Ineligible for use by VSAN",
"Reason" : "Has partitions",
"IsSSD" : "0",
"IsCapacityFlash": "0",
"IsPDL" : "0",
},
]

или, например, для хоста ESXi:

[
{
"Name" : "naa.600605b00af00ed01fa5b5b8106725e4",
"VSANUUID" : "",
"State" : "Ineligible for use by VSAN",
"Reason" : "Has partitions",
"IsSSD" : "0",
"IsCapacityFlash": "0",
"IsPDL" : "0",
},
{
"Name" : "naa.600605b00af00ed01fa5bee91339621c",
"VSANUUID" : "",
"State" : "Ineligible for use by VSAN",
"Reason" : "Has partitions",
"IsSSD" : "0",
"IsCapacityFlash": "0",
"IsPDL" : "0",
},
{
"Name" : "t10.ATA_____KINGSTON_SV300S37A240G__________________50026B226501DD09____",
"VSANUUID" : "",
"State" : "Ineligible for use by VSAN",
"Reason" : "Has partitions",
"IsSSD" : "1",
"IsCapacityFlash": "0",
"IsPDL" : "0",
},
]

Вывод содержит имя устройства и набор флагов. Для отображения более компактного списка имен дисков (и их объема) можно использовать строку:

# esxcli storage core device list | grep -iE '( Display Name: | Size: )'

где, например, вывод для vSAN Appliance будет выглядеть:

Display Name: Local VMware Disk (mpx.vmhba1:C0:T2:L0)
Has Settable Display Name: false
Size: 10240
Queue Full Sample Size: 0
Display Name: Local VMware Disk (mpx.vmhba1:C0:T1:L0)
Has Settable Display Name: false
Size: 358400
Queue Full Sample Size: 0
Display Name: Local VMware Disk (mpx.vmhba1:C0:T0:L0)
Has Settable Display Name: false
Size: 8192
Queue Full Sample Size: 0

а вывод хоста ESXi:

Display Name: LSI Serial Attached SCSI Disk (naa.600605b00af00ed01fa5b5b8106725e4)
Size: 914688
Display Name: LSI Serial Attached SCSI Disk (naa.600605b00af00ed01fa5bee91339621c)
Size: 381024
Display Name: Local ATA Disk (t10.ATA_____KINGSTON_SV300S37A240G__________________50026B226501DD09____)
Size: 228936

В первую очередь необходимо проверить флаг “IsSSD”, если накопитель является твердотельным, поскольку при использовании SAS/SATA Host Bus Adapter’ов и RAID-контроллеров, есть вероятность, что хост не распознает носитель, как SSD. Очевидно, что это актуально в первую очередь для хостов ESXi, хотя синтаксис и логика управления дисками аналогична и для vSAN Appliance. Определяем тип дисков командой:

# esxcli storage nmp device list

и для каждого диска получим примерно следующий вывод:

naa.600605b00af00ed01fa5b5b8106725e4
Device Display Name: LSI Serial Attached SCSI Disk (naa.600605b00af00ed01fa5b5b8106725e4)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba2:C2:T0:L0;current=vmhba2:C2:T0:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba2:C2:T0:L0
Is USB: false

Нас интересует то, что в поле “Storage Array Type”. Теперь, чтобы пометить диск, как SSD, нужно создать правило назначения (в терминологии VMware — PSA claim rule). Вводим команду в следующем виде:

# esxcli storage nmp satp rule add --satp=Storage_Array_Type --device naa.device_id --option "enable_ssd"

Например:

# esxcli storage nmp satp rule add --satp=VMW_SATP_LOCAL --device naa.600605b00af00ed01fa5b5b8106725e4 --option "enable_ssd"

Если выполнение команды закончится сообщением:

Error adding SATP user rule: Duplicate user rule found for SATP VMW_SATP_LOCAL matching device naa.600605b00af00ed01fa5b5b8106725e4 PSP and PSP Options

необходимо сначала удалить и заново создать правило:

# esxcli storage nmp satp rule remove --satp=VMW_SATP_LOCAL --device naa.600605b00af00ed01fa5b5b8106725e4
# esxcli storage nmp satp rule add --satp=
VMW_SATP_LOCAL --device naa.600605b00af00ed01fa5b5b8106725e4 --option "enable_ssd"

Перезагружаем хост и заново проверяем:

# vdq -q
[
{
"Name" : "naa.600605b00af00ed01fa5b5b8106725e4",
"VSANUUID" : "",
"State" : "Ineligible for use by VSAN",
"Reason" : "Has partitions",
"IsSSD" : "1",
"IsCapacityFlash": "0",
"IsPDL" : "0",
},

Список устройств и флагов можно так же получить командой с дополнительным ключом “-H”, когда таблица выглядит более читабельно и удобная для парсинга при использовании скриптов:

# vdq -q -H

За дополнительной информацией по конфигурированию SSD можно обратиться к VMware KB201318.

Теперь можно приступить непосредственно к самой all-flash конфигурации. Вообще, все SSD определяются как flash-диски по умолчанию, однако возможны отдельные случаи, когда требуется сменить флаг “IsCapacityFlash” для определенного диска группы:

# esxcli storage nmp satp rule add -s VMW_SATP_LOCAL -d mpx.vmhba1:C0:T2:L0 -o enable_capacity_flash
# esxcli storage core claiming reclaim -d mpx.vmhba1:C0:T2:L0

Здесь аналогично может потребоваться сначала удалить правило, а затем создать его заново (команды “rule remove” и “rule add”).

Использование Virtual SAN All-Flash Configuration Utility.

Подключение по SSH к каждому из хостов ESXi, или vSAN Appliance помогает выявить проблемы с типом накопителей, а так же понять логику работы. Однако управление несколькими хостами удобней осуществлять из VMware Virtual SAN All-Flash Configuration Utility, которую можно скачать по прямой ссылке.

Рис. 7. Virtual SAN All-Flash Configuration Utility.

Для работы утилиты требуется:

  • PowerShell 2.0.
  • vSphere PowerCLI 5.5, или выше.
  • Интернет соединение для скачивания plink.exe (вручную создать папку c:\temp).
  • ESX(i)-хосты с одинаковым паролем.

Скачиваем, запускаем, указываем логин/пароль, выбираем хосты, выбираем диски и конфигурируем (рис. 7).