Что такое datastore vmware
Создаем хранилище VMFS Datastore
Это может быть локальный SCSI диск (с или без RAID), или общее хранилище (shared storage), такое как SAN устройство (iSCSI или Fibre Channel) или же NFS.
Устройство хранения и сервер ESX должны быть настроены таким образом, чтобы хранилище было видно и доступно серверу ESX.
Предварительно рекомендую познакомится со статьями: основы настройки хранилищ iSCSI, а также iSCSI с аутентификацией CHAP.
Мы предполагаем, что эти настройки уже выполнены, поэтому мы можем продолжить.
1. Перейдите на вкладку сервера «Configuration», затем выберите раздел «Storage».
2. Здесь можно увидеть список всех доступных устройств хранения данных, в нашем случае доступен только локальный диск. Нажмите кнопку Add Storage («Добавить хранилище»).
3. В качестве типа хранилища укажите «Disk/LUN» Нажмите кнопку Далее …
4. Перед вами появится список еще не задействованных LUN. Выберите LUN, который вы планируете использовать как хранилище VMFS и нажмите Далее.
5. Еще раз познакомьтесь со свойствами диска, после чего нажмите кнопку Далее
6. Укажите имя создаваемого хранилища имя, это имя в дальнейшем будет использоваться вами для его идентификации. Нажмите Далее.
В том случае, если у вас не будет виртуальных дисков размером больше чем 256 Гб каждый, то можете выбрать размер блока равный 1 Мб. Нажмите Далее …
8. Следующее окно обзорное – на нем отображается информация о устройстве хранения, разделе и информация о файловой системе. Нажмите кнопку Готово.
9. Запустится задача (task) с именем «Create VMFS Datastore». После окончания этого процесса, новое хранилище VMFS готово к использованию.
10. Это хранилище теперь видимо и доступно на вкладке «Storage» в разделе настроек сервера.
Технологии хранения данных VMware vSphere 6. Часть 2.2 – New School: Virtual Volumes (VVOL)
Представляю вашему вниманию заключительную публикацию о технологиях хранения VMware vSphere 6. В ней будет рассмотрена технология VVOL.
Описание технологии VVOL
Во всех редакциях VMware до vSphere 6 ВМ (виртуальные машины) хранились в виде файлов в файловой системе. В случае массива с блочным доступом использовалась собственная файловая система VMware – VMFS, для файловых хранилищ использовались NFS. Емкость массива делилась на LUNы или NFS-шары и презентовалась (монтировалась к) хостам ESXi в виде датастор (datastore). Датасторы, как правило, имеют большой объем (от 1 ТБ) и размещают на себе множество ВМ (5-10 и более). В первую очередь это связано с тем, что выделение отдельной datastore под каждую ВМ слишком неудобно и трудозатратно в плане администрирования.
При таком подходе гранулярность операций сопровождения хранилища ВМ силами массива находится на уровне datastore (LUN или NFS-шара целиком), а не на уровне отдельных ВМ. Имеются в виду такие операции, как снапшоты, репликация, дедупликация, шифрование, QoS. Они выполняются на уровне СХД, а не средствами гипервизора, что позволяет осуществлять их быстрее, при этом разгружая вычислительные ресурсы хостов и сеть передачи данных. В первую очередь это касается блочного доступа с VMFS, некоторые модели файловых массивов (например, NetApp) дают гранулярность на уровне отдельных ВМ – например, СХД позволяет сделать снапшот отдельной ВМ, а не datastore целиком.
Описанная выше традиционная технология хранения ВМ в vSphere 6 по прежнему поддерживается, но в дополнение к ней была разработана концепция Virtual Volumes (VVOL), предполагающая объектное хранение ВМ на массивах, поддерживающих данную технологию, независимо от их типа (блочные или файловые).
VVOL – это объект, содержащий файлы ВМ, виртуальные диски и их производные. СХД с поддержкой VVOL получает возможность непосредственной работы с данными объектами за счет собственных аппаратных ресурсов. Как правило, каждый VVOL имеет уникальный GUID для идентификации. Нет необходимости заранее выделять пространство под VVOL, они создаются автоматом при выполнении операций с ВМ: создание, клонирование, снапшотинг.
vSphere (хосты ESXi и vCenter) ассоциирует с ВМ один или несколько VVOL:
Благодаря VVOL мы получаем гранулярность управления хранилищем на уровне отдельных ВМ и можем напрямую задействовать для этого ресурсы СХД. VVOL позволяют использовать гибкие возможности управления хранилищем на основе политик SPBM. Деление данных ВМ на VVOL нескольких типов позволяет размещать их на хранилища с разным уровнем сервиса: VVOL данных на производительный tier с высоким уровнем сервиса, VVOL с конфигурацией или второстепенным диском ВМ на более простые tier.
Для хранения VVOL не нужны классические LUNы или NFS-шары. VVOL хранятся на условно «сыром» пространстве СХД в объектах, называемых storage container. Storage container-ы это логические единицы пространства массива, их количество и ёмкость определяются конкретной СХД и инфраструктурой. Как минимум 1 storage container должен быть создан на СХД, нельзя растягивать 1 storage container на несколько физических массивов.
Storage container-ы логически группируют VVOL из соображений администрирования или управления: можно создавать отдельные storage container-ы для разных заказчиков, департаментов или групп ВМ. Один storage container может включать несколько профилей сервиса, таким образом, на одном и том же storage container могут размещаться ВМ с разными требованиями к обслуживанию и политиками хранения.
Для интеграции СХД с vSphere, для того, чтобы vCenter и гипервизоры могли работать с VVOL и подключиться к storage container необходимо развертывание и регистрация на vCenter специального storage provider-а на базе VASA (VMware APIs for Storage Awareness) для VVOL, который должен разрабатываться и предоставляться производителем СХД.
Для доступа хостов ESXi к VVOL используются логические прокси ввода-вывода, называемы protocol endpoints. ESXi использует protocol endpoints для установления data-path по требованию между ВМ и её VVOL. Каждый VVOL подключен к определенному protocol endpoints. Как правило, СХД требует небольшое количество protocol endpoints, поскольку 1 protocol endpoints может обслуживать множество ВМ (сотни и тысячи).
VVOL поддерживают основные протоколы СХД: Fibre Channel, FCoE, iSCSI, и NFS, аналогично традиционном хранилищам vSphere.
Для поддержки VVOL необходимо использование HBA-адаптеров и версий драйверов для них, адаптированных к работе с (поддерживающих) VVOL.
На стороне СХД происходит конфигурирование protocol endpoints – по одному или несколько на storage container. Protocol endpoints являются частью СХД и предоставляются хостам вместе с ассоциированными storage container-ами через storage provider. vSphere Web Client отображает protocol endpoints, подключенные к инфраструктуре, через T10-based LUN WWN для блочных массивов и IP/DNS для файловых. Protocol endpoints поддерживают мультипафинг только для SCSI-вариантов подключений (для NFS не поддерживается).
Storage container-ы подключаются к инфраструктуре в виде virtual datastore, эти сущности являются их прямым отображением в vSphere Web Client. Virtual datastore аналогичны обычным datastore vSphere, могут отображать VVOL по именам ВМ, их можно монтировать и размонтировать. Однако их конфигурирование, в т.ч. изменение размера осуществляется на уровне СХД за пределами vSphere. Virtual datastore могут использоваться совместно с обычными VMFS и NFS datastore, а также с Virtual SAN.
Размещение ВМ на virtual datastore (с использованием VVOL) требует наличия политик хранения (SPBM). Политика хранения ВМ (VM storage policy) содержит наборы правил по размещению и качеству сервиса для ВМ и гарантирует их выполнение. При отсутствии конкретных политик система будет использовать политику по умолчанию без ограничений, в этом случае массив самостоятельно выберет оптимальное размещение ВМ на свое усмотрение.
Преимущества и недостатки VVOL
Важными преимуществами технологии являются поддержка создания снапшотов и клонов отдельных ВМ на уровне и за счет ресурсов СХД, а также обеспечение таких сервисов как репликация, шифрование, дедупликация и сжатие отдельных виртуальных дисков. Отдельно следует отметить поддержку SPBM, которая открывает большой потенциал управления хранением ВМ на основе политик.
Продукты VMware поддерживающие VVOL:
• VMware vSphere 6.0.x
• VMware vRealize Automation 6.2.x
• VMware Horizon 6.1.x
• VMware vSphere Replication 6.0.x
Продукты VMware НЕ поддерживающие VVOL:
• VMware vRealize Operations Manager 6.0.x to 6.1.0
• VMware Site Recovery Manager 5.x to 6.1.0
• VMware vSphere Data Protection 5.x to 6.1.0
• VMware vCloud Director 5
Технологии VMware поддерживающие VVOL:
• High Availability (HA)
• Linked Clones
• Native Snapshots
• NFS version 3.x
• Storage Policy Based Management (SPBM)
• Storage vMotion
• Thin Provisioning
• View Storage Accelerator/Content Based Read Cache (CBRC)
• Virtual SAN (VSAN)
• vSphere Auto Deploy
• vSphere Flash Read Cache
• vSphere Software Development Kit (SDK)
• vSphere API for I/O Filtering (VAIO)
• vMotion
• xvMotion
• VADP
Технологии VMware НЕ поддерживающие VVOL:
• Fault Tolerance (FT)
• IPv6
• Microsoft Failover Clustering
• NFS version 4.1
• Raw Device Mapping (RDM)
• SMP-FT
• Storage Distributed Resource Scheduler (SDRS)
• Storage I/O Control
Есть предположение, что VMware делает ставку на VVOL, их развитие, и в скором будущем технология станет совместима со всеми решениями вендора. Возможно, в перспективе VVOL станут основной технологией хранения VMware, которая приведет к постепенному уходу от устаревших традиционных хранилищ и прекращению их поддержки.
На момент публикации статьи из 200 (примерно) производителей систем хранения, продукты которых совместимых с vSphere (согласно VMware Compatibility Guide), лишь 18 поддерживают VVOL. Реальных отзывов о практическом использовании VVOL мне найти не удалось: ни в Интернетах, ни на форуме VMware VMUG (даже на буржуйском). Отсутствие совместимости VVOL c перечисленными выше технологиями на данном этапе заставит многих заказчиков отказаться от VVOL, поскольку несовместимая с VVOL технология или их набор зачастую могут оказаться важнее для многих инфраструктур.
Из этого можно сделать вывод, что теоретически технология VVOL очень интересная и полезная. Однако, на данном этапе её практичность и необходимость внедрения вызывают сомнения. Нужен положительный опыт применения в продакшене и нужна совместимость с другими важными фичами vSphere, пока этого нет.
Спасибо за внимание, на этом цикл статей по технологиям хранения vSphere 6 закончен. В следующей статье будут рассмотрены решения VMware для репликации и аварийного восстановления (DR): vSphere Replication и Site Recovery Manager (SRM).
Как подключить файловое хранилище к VMware ESXi
Файловое хранилище можно использовать для расширения возможностей хостов виртуализации VMware ESXi. Этот гипервизор позволяет смонтировать NFS-хранилище как Datastore, что даст возможность, например, хранить ISO-образы или редко запрашиваемые данные.
Обратите внимание, что услуга не подойдет для хранения дисков виртуальных машин.
Чтобы выполнить монтирование:
Пропишите статический маршрут в гипервизор. Это выполняется через консоль:
Проверьте, что новый маршрут появился в web-интерфейсе. 
Выберите пункт Mount NFS datastore для добавления Datastore. 
В поле NFS server укажите адрес хранилища, а в поле NFS share — идентификатор.
Выберите версию протокола NFS4, при этом не задавая имя пользователя и пароль. 
Новый Datastore появится в списке доступных. 
Теперь место в файловом хранилище можно использовать в любой момент, когда оно потребуется.
Теоретические основы VMware Virtual SAN 6.5
В данной статье я постарался раскрыть назначение VMware Virtual SAN, принципы её работы, требования, возможности и ограничения данной системы, основные рекомендации по её проектированию.
Концепция Virtual SAN
VMware Virtual SAN (далее vSAN) представляет собой распределенную программную СХД (SDS) для организации гипер-конвергентной инфраструктуры (HCI) на базе vSphere. vSAN встроен в гипервизор ESXi и не требует развертывание дополнительных сервисов и служебных ВМ. vSAN позволяет объединить локальные носители хостов в единый пул хранения, обеспечивающий заданный уровень отказоустойчивости и предоставляющий свое пространство для всех хостов и ВМ кластера. Таким образом, мы получаем централизованное хранилище, необходимое для раскрытия всех возможностей виртуализации (технологии vSphere), без необходимости внедрения и сопровождения выделенной (традиционной) СХД.
vSAN запускается на уровне кластера vSphere, достаточно запустить соответствующий сервис в управлении кластером и предоставить ему локальные носители хостов кластера – в ручном или автоматическом режиме. vSAN встроен в vSphere и жёстко привязан к ней, как самостоятельный продукт SDS, способный работать вне инфраструктуры VMware, существовать не может.
Аналогами и конкурентами vSAN являются: Nutanix DSF (распределенное хранилище Нутаникс), Dell EMC ScaleIO, Datacore Hyper-converged Virtual SAN, HPE StoreVirtual. Все эти решения совместимы ни только с VMware vSphere, но и с MS Hyper-V (некоторые и с KVM), они предполагают установку и запуск на каждом хосте HCI служебной ВМ, необходимой для функционирования SDS, в гипервизор они не встраиваются.
Важным свойством любой HCI, в т.ч. VMware vSphere+vSAN, является горизонтальная масштабируемость и модульность архитектуры. HCI строится и расширяется на базе идентичных серверных блоков (хостов или узлов), объединяющих вычислительные ресурсы, ресурсы хранения (локальные носители) и сетевые интерфейсы. Это может быть commodity-оборудование (серверы x86, в т.ч. брэндовые), поставляемое отдельно, либо уже готовые эплаенсы (например, Nutanix, vxRail, Simplivity). Комплексное ПО (например, vSphere+vSAN+средства_оркестровки_VMware) позволяет создать на базе этих блоков программно-определяемый ЦОД (SDDS), включающий среду виртуализации, SDN (программно-определяемая сеть), SDS, средства централизованного управления и автоматизации/оркестровки. Конечно, нельзя забывать про необходимость выделенного физического сетевого оборудования (коммутаторы), без которого невозможно взаимодействие между хостами HCI. При этом для организации сети целесообразно использовать leaf-spine архитектуру, оптимальную для ЦОД.
vSAN поднимается на уровне кластера хостов ESXi под управлением vCenter и предоставляет распределенное централизованное хранилище хостам данного кластера. Кластер vSAN может быть реализован в 2х вариантах:
• Гибридный – флэш-накопители используются в качестве кэша (cache layer), HDD обеспечивают основную ёмкость хранилища (capacity layer).
• All-flash — флэш-накопители используются на обоих уровнях: cache и capacity.
Расширение vSAN-кластера возможно путем добавления носителей в существующие хосты либо путем установки новых хостов в кластер. При этом необходимо учитывать, что кластер должен оставаться сбалансированным, это значит, что в идеале состав носителей в хостах (и сами хосты) должен быть идентичным. Допустимо, но не рекомендуется, включать в кластер хосты без носителей, участвующих в ёмкости vSAN, они также могут размещать свои ВМ на общем хранилище vSAN-кластера.
Сравнивая vSAN с традиционными внешними СХД следует отметить, что:
• vSAN не требует организации внешнего хранилища и выделенной сети хранения;
• vSAN не требует нарезки LUN-ов и файловых шар, презентования их хостам и связанной с этим настройки сетевого взаимодействия; после активации vSAN сразу становится доступной всем хостам кластера;
• передача данных vSAN осуществляется по собственному проприетарному протоколу; стандартные протоколы SAN/NAS (FC, iSCSI, NFS) для организации и работы vSAN не нужны;
• администрирование vSAN осуществляется только из консоли vSphere; отдельные средства администрирования или специальные плагины для vSphere не нужны;
• не нужен выделенный администратор СХД; настройка и сопровождение vSAN осуществляется администратором vSphere.
Носители и дисковые группы
На каждом хосте кластера vSAN должно быть минимум по одному кэш-носителю и носителю данных (capacity или data disk). Данные носители внутри каждого хоста объединяются в одну или несколько дисковых групп. Каждая дисковая группа включает только один кэш-носитель и один или несколько носителей данных для постоянного хранения.
Носитель, отданный vSAN и добавленный в дисковую группу, утилизируется полностью, его нельзя использовать для других задач или в нескольких дисковых группах. Это касается как кэш-носителя, так и capacity дисков.
vSAN поддерживает только локальные носители, либо диски, подключенные по DAS. Включение в пул хранения vSAN хранилищ, подключенных по SAN/NAS, не поддерживается.
Объектное хранилище
vSAN представляет собой объектное хранилище, данные в нем хранятся в виде «гибких» (flexible) контейнеров, называемых объектами. Объект хранит внутри себя данные или мета-данные, распределенные по кластеру. Ниже перечислены основные разновидности объектов vSAN (создаются отдельно для каждой ВМ):
Таким образом, данные каждой ВМ хранятся на vSAN в виде множества перечисленных выше объектов. В свою очередь каждый объект включает в себя множество компонентов, распределенных по кластеру в зависимости от выбранной политики хранения и объема данных.
Управление хранением данных на vSAN осуществляется с помощью механизма SPBM (Storage Policy Based Management), под воздействием которого находятся все хранилища vSphere начиная с версии 6. Политика хранения задает количество допустимых отказов (Number of failures to tolerate), метод обеспечения отказоустойчивости (репликация или erasure coding) и количество страйпов для объекта (Number of disk stripes per object). Заданное политикой количество страйпов определяет число носителей данных (capacity), по которым будет размазан объект.
Привязка политики к конкретной ВМ или её диску определяет количество компонентов объекта и их распределение по кластеру.
vSAN допускает изменение политики хранения для объектов на-горячую, без остановки работы ВМ. При этом в фоне запускаются процессы реконфигурации объектов.
При распределении объектов по кластеру vSAN контролирует, чтобы компоненты, относящиеся к разным репликам объекта и компоненты-свидетели (witness), разносились по разным узлам или доменам отказа (серверная стойка, корзина или площадка).
Witness и кворум
Свидетель (witness) – это служебный компонент, не содержащий полезных данных (только метаданные), его размер равен 2-4МБ. Он выполняет роль тайбрейкера при определении живых компонентов объекта в случае отказов.
Механизм вычисления кворума в vSAN работает следующим образом. Каждый компонент объекта получает определенное число голосов (votes) — 1 и более. Кворум достигается и объект считается «живым» если доступна его полная реплика и более половины его голосов.
Такой механизм вычисления кворума позволяет распределить компоненты объекта по кластеру таким образом, что в некоторых случаях можно обойтись без создания свидетеля. Например, при использовании RAID-5/6 или страйпинга на RAID-1.
Virtual SAN datastore
После включения сервиса vSAN в кластере vSphere появляется одноименное хранилище (datastore), на весь кластер vSAN оно может быть только единственным. Благодаря механизму SPBM, описанному выше, в рамках единого хранилища vSAN каждая ВМ или её диск может получить необходимый её уровень сервиса (отказоустойчивость и производительность) путем привязки к нужной политике хранения.
vSAN datastore доступно всем хостам кластера, вне зависимости от наличия у хоста локальных носителей, включенных в vSAN. При этом хостам кластера могут быть доступны хранилища (datastore) других типов: VVol, VMFS, NFS.
vSAN datastore поддерживает Storage vMotion (горячая миграция дисков ВМ) с хранилищами VMFS/NFS.
В рамках одного сервера vCenter можно создавать несколько кластеров vSAN. Поддерживается Storage vMotion между кластерами vSAN. При этом каждый хост может быть участником только одного кластера vSAN.
Совместимость vSAN с другими технологиями VMware
vSAN совместима и поддерживает большинство технологий VMware, в т.ч. требующих общего хранилища, в частности: vMotion, Storage vMotion, HA, DRS, SRM, vSphere Replication, снапшоты, клоны, VADP, Horizon View.
vSAN не поддерживает: DPM, SIOC, SCSI reservations, RDM, VMFS.
Аппаратные требования vSAN
Требования к устройствам хранения
Носители, контроллеры, а также драйверы и firmware должны быть сертифицированы под vSAN и отображаться в соответствующем листе совместимости VMware (секция Virtual SAN в VMware Compatibility Guide).
В качестве storage-контроллера может использоваться SAS/SATA HBA или RAID-контроллер, они должны функционировать в режиме passthrough (диски отдаются контроллером как есть, без создания raid-массива) или raid-0.
В качестве кэш-носителей могут использоваться SAS/SATA/PCIe –SSD и NVMe носители.
В качестве носителей данных могут использоваться SAS/SATA HDD для гибридной конфигурации и все перечисленные выше типы флэша (SAS/SATA/PCIe –SSD и NVMe) для all-flash конфигурации.
Требования к ОЗУ и ЦПУ
Объем памяти хоста определяется количеством и размером дисковых групп.
Минимальный объем ОЗУ хоста для участия в кластере vSAN — 8ГБ.
Минимальный объем ОЗУ хоста, необходимый для поддержки максимальной конфигурации дисковых групп (5 дисковых групп по 7 носителей данных), равен 32ГБ.
vSAN утилизирует порядка 10% ресурсов процессора.
Требования к сети
Выделенный адаптер 1Гбит/с для гибридной конфигурации
Выделенный или совместно используемый адаптер 10Гбит/с для all-flash конфигурации
Необходимо разрешить трафик мультикаст в подсети vSAN
Загрузочные носители
Для загрузки хостов с vSAN могут использоваться локальные USB или SD носители, а также SATADOM. Первые 2 типа носителей не сохраняют логи и трэйсы после перезагрузки, поскольку их запись осуществляется на RAM-диск, а последний сохраняет, поэтому рекомендуется использовать SATADOM-носители SLC-класса, обладающие большей живучестью и производительностью.
Конфигурационные максимумы vSAN 6.5
Максимум 64 хоста на кластер vSAN (и для гибрида и для all-flash)
Максимум 5 дисковых групп на хост
Максимум 7 capacity-носителей на дисковую группу
Не более 200 ВМ на хост и не более 6000 ВМ на кластер
Не более 9000 компонентов на хост
Максимальный размер диска ВМ – 62ТБ
Максимальное количество носителей в страйпе на объект – 12
Технологические особенности VMware Virtual SAN
Планирование состава кластера vSAN
Минимальное количество хостов кластера vSAN определяется числом допустимых отказов (параметр Number of failures to tolerate в политике хранения) и определяется по формуле: 2*number_of_failures_to_tolerate + 1.
При условии отработки 1 отказа vSAN допускает создание 2х- и 3х- узловых кластеров. Объект и его реплика размещаются на 2х хостах, на 3м размещается свидетель. При этом появляются следующие ограничения:
• при падении 1 хоста нет возможности ребилда данных для защиты от нового отказа;
• при переводе 1 хоста в режим обслуживания нет возможности миграции данных, данные оставшегося хоста на это время становятся незащищенными.
Это обусловлено тем, что ребилдить или мигрировать данные попросту некуда, нет дополнительного свободного хоста. Поэтому оптимально если в кластере vSAN используется от 4х хостов.
Правило 2*number_of_failures_to_tolerate + 1 применимо только при использовании Зеркалирования для обеспечения отказоустойчивости. При использовании Erasure Coding оно не работает, подробно это описано ниже в разделе «Обеспечение отказоустойчивости».
Для того, чтобы кластер vSAN был сбалансированным, аппаратная конфигурация хостов, в первую очередь это касается носителей и storage-контроллеров, должна быть идентичной.
Несбалансированный кластер (разная конфигурация дисковых групп хостов) поддерживается, но заставляет мириться со следующими недостатками:
• неоптимальная производительность кластера;
• неравномерная утилизация ёмкости хостов;
• отличия в процедурах сопровождения хостов.
Допускается размещение ВМ с сервером vCenter на vSAN датасторе, однако это приводит к рискам, связанным с управлением инфраструктурой при проблемах с vSAN.
Планирование кэша vSAN
Рекомендуется планировать размер кэша с запасом для возможности расширения capacity уровня.
В гибридной конфигурации 30% кэша выделяется на запись и 70% на чтение. All-flash конфигурация vSAN использует всю ёмкость кэш-носителей на запись, кэша на чтение не предусмотрено.
Рекомендуемый размер кэша должен быть не менее 10% от реальной ёмкости ВМ до репликации, т.е. учитывается полезное пространство, а не реально занятое (с учетом репликации).
В гибридной конфигурации дисковая группа будет утилизировать всю ёмкость установленного в неё флэш-носителя, при этом его максимальный объем не ограничен.
В all-flash конфигурации дисковая группа не может использовать более 600ГБ ёмкости установленного флэш-носителя, при этом оставшееся пространство не будет простаивать, поскольку кэшируемые данные будут записываться по всему объёму носителя циклически. В all-flash vSAN целесообразно использовать под кэш флэш-носители с большей скоростью и временем жизни по сравнению с capacity-носителями. Использование под кэш носителей объёмом более 600ГБ не повлияет на производительность, однако продлит срок службы данных носителей.
Такой подход к организации кэша в all-flash vSAN обусловлен тем, что флэш-capacity-носители и так быстрые, поэтому нет смысла кэшировать чтение. Выделение всей ёмкости кэша на запись, кроме её ускорения, позволяет продлить срок жизни capacity-уровня и снизить общую стоимость системы, поскольку для постоянного хранения можно использовать более дешевые носители, в то время как один более дорогой, производительный и живучий флэш-кэш будет защищать их от лишних операций записи.
Обеспечение отказоустойчивости
Отказоустойчивость ВМ и соотношение объема полезного и занимаемого в общем пространства хранилища vSAN определяются двумя параметрами политики хранения:
• Number of failures to tolerate – количество допустимых отказов, определяет количество хостов кластера отказ которых сможет пережить ВМ.
• Failure tolerance method – метод обеспечения отказоустойчивости.
vSAN предлагает 2 метода обеспечения отказоустойчивости:
• RAID-1 (Mirroring) – полная репликация (зеркалирование) объекта с размещением реплик на разных хостах, аналог сетевого raid-1. Позволяет пережить кластеру до 3-х отказов (хостов, дисков, дисковых групп или сетевых проблем). Если Number of failures to tolerate = 1, то создается 1 реплика (2 экземпляра объекта), пространство, реально занимаемое ВМ или её диском на кластере, в 2 раза больше её полезной ёмкости. Если Number of failures to tolerate = 2, имеем 2 реплики (3 экземпляра), реально занимаемый объем в 3 раза больше полезного. Для Number of failures to tolerate = 3, имеем 3 реплики, занимаем пространство в 4 раза больше полезного. Данный метод отказоустойчивости неэффективно использует пространство, однако предоставляет максимальную производительность. Может использоваться для гибридной и all-flash конфигурации кластера. Минимально необходимое количество хостов 2-3 (для отработки 1 отказа), рекомендуемый минимум – 4 хоста, дает возможность ребилда при отказе.
Ниже представлено распределение данных на уровне компонент кластера vSAN при использовании RAID-5 и RAID-6. C1-С6 (первая строка) – компоненты объекта, A1-D4 (цветные блоки) – блоки данных, P1-Р4 и Q1-Q4 (серые блоки) – блоки четности.
vSAN позволяет по-разному обеспечивать отказоустойчивость для различных ВМ или их дисков. В рамках одного хранилища можно для критичных к производительности ВМ привязать политику с зеркалированием, а для менее критичных ВМ настроить Erasure Coding для экономии пространства. Таким образом, будет соблюдаться баланс между производительностью и эффективным использованием ёмкости.
Ниже приводится таблица с минимальным и рекомендуемым количеством хостов или доменов отказа для различных вариантов FTM/FTT:
Домены отказа
vSAN вводит понятие доменов отказа (fault domain) для защиты кластера от отказов на уровне серверных стоек или корзин, которые логически группируются в эти домены. Включение этого механизма приводит к распределению данных для обеспечения их отказоустойчивости не на уровне отдельных узлов, а на уровне доменов, что позволит пережить отказ целого домена – всех сгруппированных в нем узлов (например, серверной стойки), поскольку реплики объектов будут обязательно размещаться на узлах из разных доменов отказа.
Количество доменов отказа вычисляется по формуле: number of fault domains = 2 * number of failures to tolerate + 1. vSAN минимально требует 2 домена отказа, в каждом по 1 или несколько хостов, однако рекомендуемое количество равно 4, поскольку допускает возможность ребилда в случае отказа (2-3 домена не дают возможность ребилда, некуда). Таким образом, метод подсчета числа доменов отказа аналогичен, методу подсчета количества хостов для отработки нужного числа отказов.
В идеале в каждом домене отказа, должно быть одинаковое количество хостов, хосты должны иметь идентичную конфигурацию, пространство одного домена рекомендуется оставлять пустым для возможности ребилда (например, 4 домена с отработкой 1 отказа).
Механизм доменов отказа работает не только при Зеркалировании (RAID-1), но и для Erasure Coding, в этом случае каждый компонент объекта должен размещаться в разных доменах отказа и формула расчета числа доменов отказа меняется: минимум 4 домена для RAID-5 и 6 доменов для RAID-6 (аналогично расчету числа хостов для Erasure Coding).
Дедупликация и сжатие
Механизмы дедупликации и сжатия (ДиС) поддерживаются только в all-flash конфигурации и могут быть включены только на кластер vSAN в целом, выборочное включение для отдельных ВМ или дисков с помощью политик не поддерживается. Использовать только одну из этих технологий тоже не получится, только обе сразу.
Включении ДиС заставляет объекты автоматически страйпиться на все диски в дисковой группе, это позволяет избежать ребалансировки компонентов и выявлять совпадения блоков данных из разных компонент на каждом диске в дисковой группе. При этом сохраняется возможность задать старайпинг объектов вручную на уровне политик хранения, в т.ч. за пределы дисковой группы. При включении ДиС нецелесообразно на уровне политики резервировать пространство под объекты (параметр Object Space Reservation, толстые диски), поскольку это не даст прироста производительности и отрицательно скажется на экономии проcтранства.
ДиС производится после подтверждения операции записи. Дедупликация производится до выгрузки данных из кэша над одинаковыми блоками 4К внутри каждой дисковой группы, между дисковыми группами дедупликация не производится. После дедупликации и перед выгрузкой данных из кэша производится их компрессия: если реально сжать 4K до 2К или меньше, то компрессия производится, если нет, то блок остается несжатым, чтобы избежать неоправданных накладных расходов.
В дедуплицированном и сжатом виде данные находятся только на уровне хранения (capacity), это приблизительно 90% объема данных кластера. При этом накладные расходы на ДиС составляют порядка 5% общей ёмкости кластера (хранение метаданных, хэшей). В кэше данные находятся в обычном состоянии, поскольку запись в кэш осуществляется гораздо чаще, чем в постоянное хранилище, соответственно накладные расходы и деградация производительности от ДиС в кэше были бы значительно больше, чем бонус от оптимизации его относительно малой ёмкости.
Следует отметить наличие вопроса выбора между малым числом больших дисковых групп или множеством маленьких. На больших дисковых группах эффекта от ДиС будет больше (он делается внутри групп, а не между ними). У множества мелких дисковых групп кэш работает более эффективно (его пространство возрастает за счет увеличения общего числа кэш-носителей), будет больше доменов отказа, что будет ускорять ребилд при отказе 1 дисковой группы.
Пространство, занимаемое цепочками снапшотов, также оптимизируется за счет ДиС.
Страйпинг объектов и количество компонент
Параметр политики хранения Number of disk stripes per object задает количество отдельных capacity-носителей, по которым будут распределены компоненты одной реплики объекта (диска ВМ). Максимальное значение этого параметра, а значит максимальная длинна страйпа, которую поддерживает vSAN, равно 12, в этом случае реплика объекта распределяется на 12 носителей. Если заданная длина страйпа превышает число носителей дисковой группе, значит реплика объекта будет растянута на несколько дисковых групп (скорее всего внутри 1 хоста). Если заданная длина страйпа превышает число носителей хоста, значит реплика объекта будет растянута на несколько хостов (например, все носители 1 хоста и часть носителей другого).
По умолчанию, длина страйпа задается равной 1, это значит, что страйпинг не производится и реплика (при размере до 255ГБ) размещается на 1 носителе в виде 1 компоненты.
Теоретически страйпинг может дать прирост производительности за счет распараллеливания в/в, если носители на которые страйпится объект не перегружены. Страйпинг объекта на несколько дисковых групп, позволяет распараллелить нагрузку не только по capacity-носителям, но и утилизировать ресурсы кэш носителей вовлеченных дисковых групп. VMware рекомендует оставлять параметр «число страйпов на объект» равным 1, как задано по умолчанию, и не страйпить объекты, за исключением тех случаев, когда страйпинг допустим, необходим и реально позволит повысить производительность. В общем случае считается, что страйпинг ощутимого прироста производительности дать не сможет. В гибридных конфигурациях эффект от страйпинга может быть положительным, особенно при интенсивном чтении, когда возникают проблемы с попаданием в кэш. Потоковая запись также может быть ускорена за счет страйпинга, в т.ч. в all-flash конфигурации, поскольку могут утилизироваться несколько кэш-носителей и распараллеливается вытеснение данных на постоянные носители.
Следует учитывать, что страйпинг приводит к значительному росту количества компонент кластера. Это важно для кластеров с большим количеством ВМ и объектов, когда лимит компонент на кластер (9000) может быть исчерпан.
Необходимо учитывать, что максимальный размер 1 компонента объекта равен 255ГБ, это значит, что если объект имеет большой размер, его реплика будет автоматически разбита на число компонентов, кратное 255. В таком случае, независимо от политики страйпинга компоненты реплики будут разнесены по нескольким носителям, если их очень много (больше, чем носителей на хосте или в кластере, например, создаем диск 62ТБ), то на носитель может попасть по несколько компонент одного объекта.
Планирование ёмкости кластера vSAN
При планировании размера хранилища кластера vSAN необходимо учитывать, что реально занимаемое пространство с учетом используемых методов отказоустойчивости (зеркало или EC) и количества допустимых отказов (от 1 до 3х) может значительно превышать полезную ёмкость кластера. Также необходимо учитывать воздействие методов оптимизации использования пространства (EC и ДиС).
Следует учитывать выделение пространства под swap-файлы (размер ОЗУ каждой ВМ) и хранение снапшотов.
При заполнении ёмкости vSAN на 80% начинается ребалансировка кластра – это фоновый процесс, перераспределяющий данные по кластеру и вызывающий значительную нагрузку, лучше не допускать его наступления. Порядка 1% пространства уходит при форматировании носителей кластера под файловую систему vSAN (VSAN-FS). Небольшая доля пространства уходит на метаданные ДиС (5%). Поэтому VMware рекомендует проектировать кластер vSAN с запасом ёмкости 30%, для того чтобы не доводить до ребалансировки.
Выбор storage-контроллера
vSAN рекомендует и поддерживает использование нескольких storage-контроллеров на одном хосте. Это позволяет увеличить производительность, ёмкость и отказоустойчивость на уровне отдельных узлов. При этом ни одна vSAN ready node не содержит более 1 storage-контроллера.
Рекомендуется выбирать контроллеры с максимально большой длиной очереди (не менее 256. Рекомендуется использовать контроллеры в режиме pass-through, когда диски напрямую презентуются гипервизору. vSAN поддерживает использование контроллеров в режиме raid-0, однако их применение приводит к дополнительным манипуляциям при сопровождении (например, при замене носителя). Внутренний кэш контроллера рекомендуется отключать, если невозможно, то настроить 100% на чтение; фирменные режимы акселерации контроллеров также необходимо отключать.
Отработка отказов
В случае отказа capacity-носителя его ребилд может быть произведен внутри той же дисковой группы или на другую группу (на том же хосте или на другом), это зависит от наличия свободного места.
Отказ кэш-носителя приводит к ребилду его дисковой группы целиком. Ребилд может быть произведен на тот же хост (если на нем есть еще дисковые группы и свободное место) или на другие хосты.
На случай отказа хоста для ребилда лучше предусмотреть как минимум 1 свободный хост, если нужно отработать несколько отказов, то и свободных хостов должно быть несколько.
Если компонент (диск или дисковый контроллер) деградировал (отказ компонента без возможности восстановления), то vSAN начинает его ребилдить немедленно.
Если компонент (потеря сети, отказ сетевой карты, отключение хоста, отключение диска) отсутствует (временное отключение с возможностью восстановления), то vSAN начинает его ребилдить отложенно (по умолчанию, через 60 мин).
Естественно, условием ребилда является наличие свободного места в кластере.
После отказа (носителя, дисковой группы, хоста, потери сети) vSAN останавливает в/в на 5-7 секунд пока оценивает доступность потерянного объекта. Если объект находится, то в/в возобновляется.
Если через 60 минут после отказа хоста или потери сети (начался ребилд), потерянный хост возвращается в строй (восстановлен или поднята сеть), vSAN сама определяет, что лучше (быстрее) сделать: доделать ребилд или синхронизировать вернувшийся хост.
Контрольные суммы
По умолчанию vSAN осуществляет подсчёт контрольных сумм для контроля целостности объектов на уровне политик хранения. Вычисление контрольных сумм производится для каждого блока данных (4KB), их проверка осуществляется как фоновый процесс на операциях чтения и для данных, остающихся холодными в течении года (scrubber). Данный механизм позволяет выявлять повреждения данных по программным и аппаратным причинам, например, на уровне памяти и дисков.
При обнаружении несоответствия контрольной суммы vSAN автоматически восстанавливает поврежденные данные путем их перезаписи.
Вычисление контрольных сумм можно отключить на уровне политик хранения. Частоту запуска scrubber-а (проверка блоков к которым не было обращений) при желании можно изменить в дополнительных настройках (параметр VSAN.ObjectScrubsPerYear) и выполнять такую проверку чаще, чем 1 раз в год (хоть раз в неделю, но возникнет допнагрузка).
Планирование сети vSAN
vSAN поддерживает nic-teaming с агрегированием портов и балансировкой нагрузки.
До версии 6.5 включительно vSAN требует поддержки мультикаст-трафика в своей сети. Если в одной подсети размещается несколько кластеров vSAN, необходимо назначить их хостам разные мультикаст-адреса, для разделения их трафика. Начиная с версии 6.6 vSAN не использует мультикаст.
При проектировании сети vSAN рекомендуется закладывать leaf-spine архитектуру.
vSAN поддерживает NIOC для выделения гарантированной полосы пропускания под свой трафик. NIOC может быть запущен только на distributed vSwitch, vSAN дает возможность их использования в любой редакции vSphere (они входят в лицензию vSAN).
vSAN поддерживает использование Jumbo-фреймов, однако VMware считает прирост производительности от их использования незначительным, поэтому даёт следующие рекомендации: если сеть их уже поддерживает – можно использовать, если нет, то для vSAN они совсем необязательны, можно обойтись без них.
Пример размещение объектов в кластере vSAN
Выше были описаны состав, структура и принципы размещения объектов и компонентов в кластере vSAN, методы обеспечения отказоустойчивости, использование политик хранения.
Теперь рассмотрим, как это работает на простом примере. В нашем распоряжении кластер vSAN из 4-х хостов в all-flash конфигурации. На рисунке ниже условно представлено, как в этом кластере будут размещаться 3 диска ВМ (вДиски).
вДиск-1 был привязан к политике хранения с отработкой 1 отказа (Failure To Tolerate (FTT) = 1) и использованием Erasure Coding (Fault Tolerance Method (FTM) = EC). Таким образом, объект вДиск-1 был распределен в системе в виде 4 компонент, по 1 на хост. Данные (data) вДиска внутри этих компонент записаны вместе с вычисленными значениями четностей (parity), фактически это сетевой RAID-5.
вДиск-2 и вДиск-3 были привязаны к политикам хранения с отработкой 1 отказа (FTT = 1) и зеркалированием (FTM = Mirror). Уточним, что вДиск-2 имеет полезный размер менее 255ГБ и для него задан размер страйпа по умолчанию (Number of disk stripes per object = 1). Поэтом объект вДиск-2 был размещен на кластере в виде 3х компонент на разных узлах: две зеркальные реплики и свидетель (witness).
вДиск-3, в данном случае, имеет полезный размер 500ГБ и для него задан размер страйпа по умолчанию. Поскольку 500ГБ больше 255ГБ, vSAN автоматически разбивает одну реплику объекта вДиск-3 на 2 компонента (Компонент1-1 и Компонент1-2) и кладет на Хост-1. Их реплики (Компонент2-1 и Компонент4-2) размещаются на хостах 2 и 4, соответственно. В данном случае свидетель отсутствует, поскольку алгоритм расчета кворума с использованием голосов позволяет без него обойтись. Необходимо отметить, что vSAN разместила вДиск-3 на пространстве кластера именно таким образом автоматически и на свое усмотрение, руками это задать не получится. С тем же успехом она могла разместить эти компоненты на узлах по-другому, например, одну реплику (Компонент1-1 и Компонент1-2) на Хост-4, вторую на Хост-1 (Компонент2-1) и Хост-3 (Компонент4-2). Либо могла выделить под реплики 2 хоста (2 компоненты на Хост-1 и 2 компоненты на Хост-3), а на третий разместить свидетеля (Хост-4), это уже 5 компонент, а не 4.
Конечно, автоматическое размещение объектов не является произвольным, vSAN руководствуется своими внутренними алгоритмами и старается равномерно утилизировать пространство и по возможности сократить количество компонент.
Размещение вДиск-2 тоже могло быть иным, общее условие – компоненты разных реплик и свидетель (если он есть) должны находиться на разных хостах, это условие отработки отказа. Так, если бы вДиск-2 имел размер чуть меньше 1,9ТБ, то каждая из его реплик состояла бы из 8 компонент (одна компонента не более 255ГБ). Такой объект можно было бы разместить на тех же 3х хостах (8 компонентов 1 реплики на Хосте-1, 8 компонентов 2 реплики на Хосте-2, свидетель на Хосте-3. Либо vSAN мог бы разместить его без свидетеля, распределив 16 компонентов обеих реплик по всем 4 хостам (без пересечения разных реплик на одном хосте)
Рекомендации по эффективному использованию пространства
Просто привожу таблицу из рекомендаций VMware:
Поддержка режима Stretched Cluster
vSAN поддерживает работу в режиме Stretched Cluster (растянутый кластер) с охватом 2х географически разнесенных площадок (сайтов), при этом общий пул хранения vSAN также распределяется между сайтами. Оба сайта являются активными, в случае выхода из строя одной из площадок, кластер использует хранилище и вычислительные мощности оставшегося сайта для возобновления работы рухнувших сервисов.
Подробное рассмотрение особенностей Stretched Cluster выходит за рамки данной публикации.