Vmware vsan что это

Обновлено: 02.07.2024

VMware Virtual SAN — это радикально упрощенное общее хранилище корпоративного класса для гиперконвергированной инфраструктуры, оптимизированное для работы с современными системами на основе флэш-накопителей. [Источник 1] Система VMware Virtual SAN (vSAN), ставшая дебютом компании в сфере виртуализации хранилищ, предоставляет пространство для виртуальных дисков, которые содержат необходимые при запуске виртуальных машин [1] данные.

Архитектура на основе флеш-накопителей обеспечивает кэширование, устойчивость данных и высокую предсказуемую производительность. А поскольку Virtual SAN встраивается в ядро vSphere, происходит оптимизация путей ввода-вывода и снижается воздействие на центральный процессор. Тогда как распределенная архитектура на основе гипервизора повышает производительность самих приложений. Благодаря встроенной интеграции Virtual SAN в гипервизор не требуется устанавливать дополнительный софт, а подход на основе политик значительно упрощает управление стандартными процессами. Достаточно сделать пару кликов, и система готова к работе. Кроме этого Virtual SAN интегрируется со всеми компонентами vSphere и управляется с помощью веб-клиента vSphere.

Содержание

История

Впервые компания VMware анонсировала продукт vSAN на международной конференции VMworld в августе 2013 года. Кроме того, VMware выпустила несколько бета-версий программы, чтобы будущие заказчики смогли заранее ее протестировать. Первые пользователи технологии отметили ее преимущества по целому ряду показателей. Например, специалисты Adobe Systems смогли благодаря встроенным механизмам реализации политик в vSAN избежать покупки нового аппаратного хранилища за счет более эффективного применения хранилищ, уже существующих на серверах организации. Сервис-провайдеру Itrica новое решение от VMware помогло выполнить масштабирование хранилища в ответ на потребности клиентов, а также позволило организовать управление этим хранилищем через тот же интерфейс, что использовался для контроля виртуальных машин. 10 февраля 2016 года VMware выпустила vSAN 6.2. Он создан специально для разворачивания хранилищ на основе флэш-памяти NAND и пополнил линейку гиперконвергентных продуктов компании.

Описание

Гиперконвергентная компьютерная система объединяет в одном комплексе не только управление вычислительными ресурсами, хранением данных и сетевыми функциями, что присуще конвергентным системам, но также дополнительные функции: дедупликация [2] , компрессия [3] и распределение данных по уровням хранения, шифрование данных и/или высокоуровневая аутентификация пользователей в рамках системы безопасности, гипервизор и т.п.

Архитектура

Архитектура, объединенная с гипервизором: компонент Virtual SAN встроен в ядро vSphere, что обеспечивает оптимизацию ввода-вывода и высочайший уровень производительности при минимальной нагрузке на ЦП.

Возможности архитектуры

Гибридная архитектура или архитектура, содержащая только флэш-накопители: Virtual SAN можно развернуть в качестве архитектуры, содержащей только флэш-накопители, где подключенная к серверу флэш-память используется и для кэширования, и для обеспечения устойчивости данных, предоставляя чрезвычайно высокий и стабильный уровень производительности. Кроме того, Virtual SAN может использоваться в качестве гибридного хранилища, в котором флэш-накопители на стороне серверов объединяются в пулы и выступают в роли кэша чтения/записи, а подключенные к серверу жесткие диски обеспечивают устойчивость данных.

Тип управления

Тип кеширования

Кэширование операций чтения и записи на стороне сервера:Virtual SAN сокращает время ожидания за счет ускорения операций ввода-вывода чтения и записи диска с помощью встроенного кэширования на основе использования флэш-накопителей на стороне сервера.

Возможности масштабирования

Гибкое горизонтальное и вертикальное масштабирование [4] без нарушения работы: увеличение емкости и повышение производительности хранилища данных Virtual SAN без прерывания рабочих процессов путем добавления узлов в кластер (горизонтальное масштабирование) или дисков в узел (вертикальное масштабирование).

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

Встроенная отказоустойчивость: Virtual SAN эффективно использует распределенные RAID-массивы и зеркалирование кэша для защиты от потерь данных в случае сбоя диска, узла,сети или стойки.Снимки и клоны Virtual SAN: новый дисковый форматVirtual SAN обеспечивает чрезвычайно эффективное создание масштабируемых снимков и клонов ВМ. Для одной ВМ поддерживается до 32 снимков и клонов.

Лояльность к оборудованию

Независимость от оборудования: компонент Virtual SANможет быть развернут на оборудовании любых поставщиков серверных решений. Это обеспечивает гибкость при формировании специализированных систем хранения в разнородных аппаратных средах.

Совместимость с другими продуктами

Концепция vSAN

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

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

Носитель, отданный для организации vSAN и объединенный в дисковую группу, используется полностью для организации системы хранения, его нельзя совместно использовать для других целей. Дисковые группы объединяются в пул, доступный всему кластеру vSphere, и организуют общее “внешнее” и отказоустойчивое хранилище, для передачи данных которого используется собственный протокол (FC [5] , iSCSI [6] или 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 представляет из себя объектное хранилище [7] , данные в котором хранятся в виде объектов, или “гибких контейнеров” (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-х хостов.

Решаемые задачи

Упрощение и ускорение инициализации ресурсов хранения и оптимизация управления ими с помощью единой консоли управления в средах vSphere и средств точного, ориентированного на ВМ управления уровнями обслуживания хранилища
Архитектура хранилища, объединенная с гипервизором, оптимизированная для флэш-накопителей и обеспечивающая чрезвычайно высокую производительность и быстрое реагирование
Балансировка ресурсов хранения с помощью автоматизированного процесса саморегуляции для обеспечения соответствия уровням обслуживания хранилища, назначенным виртуальным машинам
Интеграция с продуктами VMware
Низкий уровень начальных расходов — постепенное расширение с гибким линейным масштабированием производительности, ресурсов и издержек
Существенное снижение совокупной стоимости владения (до 50%)
Техническая поддержка со стороны VMware и основных OEM-поставщиков [8] серверных решений.

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

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

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

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

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

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

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

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

Преимущества и недостатки vSAN

Преимущества

Сравнивая vSAN с традиционными внешними СХД следует отметить, что: [Источник 3]

vSAN не требует организации внешнего хранилища и выделенной сети хранения;
vSAN не требует нарезки LUN-ов [9] и файловых шар [10] , презентования их хостам и связанной с этим настройки сетевого взаимодействия; после активации vSAN сразу становится доступной всем хостам кластера;
Передача данных vSAN осуществляется по собственному проприетарному протоколу; стандартные протоколы SAN/NAS (FC, iSCSI, NFS) для организации и работы vSAN не нужны;
Не нужен выделенный администратор СХД; настройка и сопровождение vSAN осуществляется администратором vSphere.

Недостатки

vSAN также имеет ряд недостатков по сравнению с другими хранилищами: [Источник 4]

Для использования VSAN 6 вы должны также использовать VMware vSphere 6. Нельзя использовать VSAN 6 на, например, vSphere 5.5U2. Однако не все готовы, или могут, прямо вот так, сейчас, перейти на новую vSphere. Тут и вопросы совместимости, и факт того, что из HCL vSphere 6 пропало множество популярных систем, да и просто, для многих компаний такое обновление затратно по времени и усилиям. Но — если вы не хотите мириться с многочисленными недостатками VSAN 5 — готовьтесь к переходу на vSphere 6, и никак иначе.

VSAN использует network RAID (а не распределенное хранение, как у Nutanix), со всеми присущими ему минусами. Он использует SSD как кэш, а не как storage tier (это значит, что емкость SSD не прибавляется к емкости хранения HDD, и не увеличивает ее, как увеличивает тиринг у Nutanix). Там отсутствует поддержка VAAI, Shadow Clones, меньше эффективная емкость SSD (всего 600GB write buffer максимум). Снэпшоты по-прежнему приводят к существенному (меньшему, чем в v5, но все равно весьма заметному) падению производительности. Также явно плохо реализована изоляция задач (проблема «шумного соседа») в рамках одного кластера, ресурсоемкая задача может сильно повлиять на работу других VM того же кластера.

Доступ к данным через сеть/отсутствие Data Locality

Важная особенность VSAN в том, что доступ к данным штатным образом осуществлятся через 10G сеть. Данные пишутся и читаются через сеть и коммутатор в нормальном, рабочем режиме (а не только при нештатной недоступности данных локально, как у Nutanix), что может вести к повышенному времени задержек и перегрузке «межнодовой» 10G-магистрали, а также меньшей надежности.

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

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

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

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

В первом посте про CloudLITE мы упомянули виртуальное хранилище VMware Virtual SAN (VSAN). Сегодня остановимся на этой технологии подробнее и расскажем, на что следует обратить внимание при создании VSAN для своего проекта.

Зачем вам VSAN

Традиционная архитектура включает три ключевых компонента:
• серверы,
• система хранения данных (СХД),
• сеть хранения данных, которая соединяет СХД с серверами через блочные (FC, FCoE, ISCSI) или файловые протоколы (NFS, SMB) с использованием соответствующих коммутаторов.

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

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

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

Когда же у вас проект (например, public cloud) растет скачками, добавление нового хранилища при минимальных возможностях автоматизации займет уйму времени. Вот тут-то и приходит на помощь конвергентная архитектура VSAN, позволяющая объединить в сервере вычислительные функции и функции хранения.

VSAN как конвергентное решение

Конвергентное решение позволяет создавать инфраструктуру из типовых блоков, объединяющих в себе сразу несколько функций (например, вычисление, хранение). Управление такой инфраструктурой осуществляется через единый интерфейс, а масштабирование – через добавление очередного блока.

В случае с VSAN каждый блок — это сервер. Не любой, конечно, но об этом чуть позже. Каким образом сервер выполняет функции СХД? VSAN собирает из локальных дисков серверов виртуальное «внешнее» хранилище, доступное для всех вычислительных узлов кластера виртуализации. При этом программная часть VSAN работает на тех же серверах, что и вычислительные узлы. Таким образом, на одном и том же сервере располагаются и вычислитель (compute node), и часть системы хранения данных (storage node) – все в одном флаконе.

Как это работает

На каждом сервере есть от 1 до 5 дисковых групп. В каждой группе – минимум один SSD-диск (необходимое условие для построения VSAN ) и от 1 до 7 HDD-дисков.
SSD-диски в этих дисковых группах составляют общий пул кэширования данных. VSAN в первую очередь читает данные в кэше; если данных в кэше нет, VSAN отправляется к HDD-дискам.

Для каждой виртуальной машины можно настроить свой FTT (failures to tolerate). По умолчанию это 2, т. е. все данные виртуальных машин пишутся сразу на 2 разных сервера кластера. Если один из серверов выйдет из строя, у нас будет синхронная реплика на другом, и все операции I/O пойдут на эту вторую копию.

На что обратить внимание при проектировании VSAN

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

1. Совместимость с аппаратным обеспечением. Хотя VSAN и дает определенную свободу в выборе «железа», имеет смысл оставаться в рамках списка гарантированно совместимого с VMware VSAN оборудования. Так вам не придется методом научного тыка подбирать совместимые контроллеры, адаптеры и пр. В случае с CloudLITE по совокупности технических и экономических характеристик мы выбрали Huawei FusionServer RH5885 V3. Эта модель имеет на борту более производительные PCIe флеш-карты (в сравнении с уже ставшими классическими SSD-дисками), которые, кстати, позволяют экономить «слоты для дисков» и создавать больше дисковых групп. В самое ближайшее время устроим ему unboxing. Следите за обновлениями :).

2. Сеть. В конфигурации с VSAN ВМ может работать в одном месте, а храниться – в другом. Это предъявляет достаточно высокие требования к сети: у вас должна быть как минимум 10 GB сеть.

3. Производительность дисковых контроллеров. Дисковый контроллер должен обеспечивать объемный буфер для большой очереди команд. Нагрузка на него будет значительная: контроллер будет отдавать данные, нужные не только этому серверу, но и всему кластеру. Например, при восстановлении выбывшей дисковой группы на новую группу нужно записать большой объем данных за короткое время. Скорость записи как раз и будет зависеть от производительности контроллера.

4. Объем дисков. В данной ситуации больше не означает лучше. Скорее наоборот. Хотя сейчас доступны диски по 4, 6 ТБ, VSAN лучше строить из дисков объемом 1 ТБ. Давайте представим аварийную ситуацию, когда в кэш у нас ничего не попадает (замена «полетевшей» дисковой группы, бэкап или восстанавление бэкапа): 6 ТБ диски будут восстанавливаться в 6 раз дольше, чем 1 ТБ диски (если отталкиватьcя от отношения скорости чтения к объему хранимых данных – IOPS/GB). Тут мы, конечно, говорим о worst case, но эти ситуации не из области фантастики. И чтобы желание использовать в VSAN объемные диски совсем отпало, просто представьте, сколько будут восстанавливаться данные на 7 жестких дисках по 6 ТБ.

5. Соотношение объема SSD к объему жесткого диска. Оно будет напрямую влиять на итоговую производительность дисковой группы: чем больше емкость SSD (чем больше данных будет в кэше), тем выше производительность. В CloudLITE для кэширования используются PCIe флеш-карты — они обладают меньшими задержками по сравнению с SSD. Кстати, в VSAN версии 6.0 поддерживаются дисковые группы, состоящие только из SSD.

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

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 представляет из себя объектное хранилище, данные в котором хранятся в виде объектов, или “гибких контейнеров” (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. Идея заключается в том, что на базе гипервизора VMware ESXi создан OVA-темплейт виртуальной машины, который предназначен для разворачивания компонента vSAN на хосте ESXi. Предоставляет возможности общего хранилища, с помощью которых малые и средние компании могут воспользоваться средствами обеспечения высокой доступности и автоматизации без использования дополнительного сетевого оборудования для хранения данных. Имеет ряд недостатков, таких как, отсутствует возможность масштабирования более 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. Можно так же через веб-интерфейс:

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

и открываем скачанный 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):

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

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

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

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

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

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

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

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

Использование хоста 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-устройство.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Готовая к будущему гиперконвергентная инфраструктура с максимальной гибкостью развертывания

Интегрированная гиперконвергентная инфраструктура (HCI) на базе vSAN в сочетании с vSphere позволяет управлять вычислительными ресурсами и ресурсами хранения с помощью единой интегрированной платформы. Выберите самый простой способ создания готовой к будущему HCI-инфраструктуры и гибридного облака с помощью интегрированного решения, которое позволяет повысить адаптивность бизнеса, ускорить процессы и сократить расходы.

Беспроблемный переход к HCI

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

Централизованное управление приложениями

Обеспечьте удобное управление виртуальными машинами и приложениями в контейнерах благодаря интеграции с VMware Tanzu.

Сокращение расходов

Оптимальное соотношение производительности и цены благодаря поддержке новейшей технологии хранения на базе стандартных серверов.

Гибкое развертывание

Повсеместное использование HCI благодаря самой обширной в отрасли экосистеме: 18 OEM-поставщиков серверов и стандартные облачные службы на основе ведущих публичных облаков, в том числе AWS, Azure, Google Cloud, Oracle Cloud, IBM Cloud и Alibaba Cloud.

Преимущества vSAN

Полная масштабируемость

Гибкое и эффективное масштабирование вычислительных ресурсов и ресурсов хранения в соответствии с потребностями приложений с помощью VMware HCI Mesh.

Упрощение процессов

Удобное развертывание новой инфраструктуры и приложений при минимальном обучении.

Инфраструктура, готовая для разработки

Обеспечьте возможности самообслуживания, необходимые разработчикам для создания масштабируемых приложений. Предоставьте ИТ-администраторам возможности управления, которые необходимы для управления ВМ и контейнерами.

Сценарии использования

Важные бизнес-приложения

Обеспечьте высокую производительность самых важных приложений — до 150 000 операций ввода-вывода в секунду на узел. Ускорьте развертывание с помощью высокоавтоматизированных процессов и сократите расходы по сравнению с устаревшими решениями для хранения данных.

Инфраструктура виртуальных рабочих мест (VDI)

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

Удаленные офисы и филиалы

Повысьте производительность локальной ИТ-среды при управлении из ЦОД. Начните с небольшой физической инфраструктуры, содержащей всего два узла, и расширяйте ее по мере необходимости. Контролируйте расходы с помощью гибких моделей лицензирования.

Аварийное восстановление

Сократите расходы на аварийное восстановление с помощью серверов HCI вместо специализированных массивов хранения. Управляйте средой аварийного восстановления из ЦОД. Обеспечьте оркестрацию и автоматизацию восстановления с помощью VMware Site Recovery Manager и vSphere Replication.

Удаленные офисы и филиалы

«Современные технологии становятся все более сложными. В то же время я как ИТ-менеджер небольшой компании должен работать с ограниченным штатом сотрудников. Мы больше не можем тратить слишком много времени на повседневное управление серверами. В связи с этим мы искали удобное решение, которым легко управлять. Вот почему мы выбрали VMware vSAN». — Джованни Говертс (Giovanni Govaerts), ИТ-менеджер, Modemakers «С помощью vSAN мы обеспечили согласованность архитектуры и процессов, чтобы перейти к многооблачной среде в будущем». — Стивен Уэст (Steven West), менеджер по управлению системами, Colin Biggers & Paisley «Развертывание vSphere и vSAN позволило избавиться от устаревшей трехуровневой архитектуры. Теперь у нас есть возможность внедрить упрощенную гиперконвергентную масштабируемую архитектуру, которая помогла нам снизить совокупную стоимость владения». — Акет Дингал (Aket Dingal), первый вице-президент и руководитель ИТ-отдела, JM Financial Asset Management Limited

Связанные ресурсы

Почему заказчики выбирают vSAN?

Узнайте, почему заказчики выбирают vSAN, чтобы упростить эксплуатацию ЦОД и снизить капитальные расходы.

Магический квадрант Gartner в сегменте HCI

VMware по-прежнему остается одним из лидеров магического квадранта в сегменте программного обеспечения для гиперконвергентной инфраструктуры.

Технические ресурсы на портале Tech Zone

Узнайте больше о vSAN: ознакомьтесь с эталонными архитектурами, руководствами по проектированию и эксплуатации, а также другими ресурсами!

Связанные продукты

Предоставляйте всем пользователям доступ к любым приложениям в любом облаке, обеспечивая беспрецедентные возможности масштабирования, с помощью VMware Secure Access и связанных продуктов.

vSphere

ПО для виртуализации серверов

Полностековое решение по виртуализации сети и системы безопасности

vRealize Cloud Management

Портфель продуктов для управления гибридным облаком

VMware Cloud Foundation

Платформа гибридного облака

Сравнение редакций

Standard

Оптимальное решение для гибридных сред с политиками хранения на уровне ВМ.

Advanced

Возможности редакции Standard в сочетании с механизмами эффективного использования емкости хранилища на основе флэш-накопителей.

Enterprise

Все возможности редакции Advanced, а также программно-определяемое шифрование данных на хранении и распределенные кластеры.

Enterprise Plus

Расширенное управление для оптимизации производительности, эффективное управление ресурсами и многое другое.

Вопросы и ответы

Беспроблемный переход благодаря интеграции vSAN с vSphere. Распространите преимущества виртуализации на хранилище с помощью имеющихся инструментов и наборов навыков.
Максимальная гибкость: вы можете использовать HCI на базе сертифицированных решений 18 поставщиков OEM-серверов, а также в качестве собственных сервисов на базе ведущих публичных облаков.
Возможности многооблачных сред: vSAN со встроенной системой безопасности на всех уровнях обеспечивает согласованность процессов от периметра до базового ЦОД и облака.
Традиционные и современные приложения на одной платформе.

Каковы требования к оборудованию для использования vSAN?

Для кластера vSAN необходимо по крайней мере два физических узла с выделенными локальными устройствами хранения и общим узлом-свидетелем. Дополнительные сведения см. в руководстве VMware по совместимости для систем и серверов и руководстве VMware по совместимости для vSAN.

Каковы требования к программному обеспечению для использования vSAN?

Решение vSAN интегрировано с VMware vSphere Hypervisor, поэтому нет необходимости устанавливать дополнительное ПО или развертывать виртуальные устройства контроллера хранилища на каждом узле в кластере, как в традиционном сценарии. Для настройки кластера vSAN и управления им требуется только vCenter Server.

Можно ли использовать имеющееся хранилище SAN или NAS в том же кластере, что и vSAN?

Да, vSphere может использовать традиционные хранилища данных с vSAN и vSphere Virtual Volumes. В большинстве случаев переносить ВМ между этими типами хранилищ данных можно с помощью vSphere Storage vMotion. Это упрощает миграцию имеющихся рабочих нагрузок при обслуживании или выводе из эксплуатации решения для хранения данных.

Где доступно руководство по определению размера кластера vSAN?

Чтобы оценить возможность миграции существующей среды на платформу vSAN, отправьте запрос на бесплатную оценку HCI. Собранные данные можно использовать вместе со средством определения размера vSAN ReadyNode Sizer, чтобы определить подходящие конфигурации сервера vSAN ReadyNode.

Емкость хранилища можно увеличить двумя способами: выполнить горизонтальное масштабирование кластеров посредством добавления узлов или вертикальное масштабирование существующих узлов посредством добавления ресурсов. Компонент Cluster Quickstart упрощает добавление вычислительных ресурсов и ресурсов хранилища в кластер vSAN.

Для vSAN доступны четыре варианта развертывания: совместно спроектированная готовая система, устройства Global Partner Appliance, узлы vSAN ReadyNode и развертывание по модели «как услуга» с помощью поставщиков облачных сервисов. Дополнительную информацию см. на странице Варианты развертывания vSAN.

Подробные инструкции по активации vSAN см. в документации по vSAN.

Где можно получить пошаговые инструкции по настройке vSAN?

Пошаговые инструкции по настройке кластера vSAN см. в документации по vSAN.

Узлы vSAN ReadyNode — это серверы x86, которые были предварительно настроены, протестированы и сертифицированы для использования с ПО VMware для HCI. Каждый сервер ReadyNode имеет оптимальную конфигурацию для vSAN с необходимым количеством ЦП, объемом памяти, числом сетей и контролеров ввода-вывода, а также объемом ресурсов хранения. Дополнительные сведения см. на странице Узлы vSAN ReadyNode.

Читайте также: