Много лет подряд VMware входит в рейтинг «магический квадрант» аналитической компании Gartner и занимает в нем сектор «Лидеры» в области гиперконвергентного (HCI) программного обеспечения. Среди вендоров чисто программных HCI компания VMware лидирует с большим отрывом, занимая 42,4 % мирового рынка.

Одним из важных элементов портфеля продуктов VMware является программно-определяемая система хранения данных (СХД) VMware vSAN, встроенная в гипервизор ESXi и работающая на серверах x86. Она способна объединять множество локально расположенных накопителей HDD и SSD в единое легко масштабируемое хранилище, управляемое с помощью политик vCenter, формируемых отдельно для каждой виртуальной машины.

vSAN работает на том же уровне, что и обслуживаемые гипервизором виртуальные машины, что обеспечивает максимальную доступность данных и высокую скорость работы СХД. При этом vSAN глубоко интегрирована с другими продуктами VMware, такими как vSphere и Tanzu.

Для того, чтобы возможности СХД соответствовали требованиям корпоративных и Enterprise-заказчиков, часть SSD-накопителей в ней объединяются в высокопроизводительный кэш, прочие же HDD или SSD формируют массив основного хранилища. Возможно также использование накопителей типов NVMe и PMEM.

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

Базовая архитектура и топология vSAN

Двухуровневая модель кэш/хранилище создается в виде дисковых групп. На одном сервере таких групп может быть до пяти включительно. В роли кэша каждой группы выступает накопитель с самой высокой скоростью записи – SSD или NVMe. Роль основной емкости для хранения данных в рамках одной группы используется до семи накопителей других типов с хорошими показателями скорости чтения. Возможны, например, комбинации твердотельных накопителей SLC/MLC и другие.

В рамках кластера vSphere все дисковые группы формируют единое хранилище данных, которое будет полностью распределено между узлами кластера. Таким образом обеспечивается отказоустойчивость решения. В случае выпадения любого узла, необходимые данные всегда можно найти на другом узле. Отказоустойчивости можно добиться и на уровне стоек, что позволяет защититься от потери питания стойки целиком или выхода из строя коммутатора top-of-rack.

Кластер vSAN может включать в себя от 3 до 64 серверов. На каждом из них рекомендуется использовать несколько дисковых групп, так как это положительно сказывается на производительности СХД в целом. Взаимодействие между серверами осуществляется по сети передачи данных. Гибридные СХД с использованием HDD обычно объединяются каналом с пропускной способностью 1 Гбит/с, для массивов, полностью состоящих из твердотельных накопителей, разумно использовать канал 10 Гбит/с. Масштабирование СХД может проводиться как путем добавления накопителей (Scale Up), так и добавлением серверов (Scale Out).

Важным свойством vSAN является возможность управления этой СХД при помощи политик Storage Policy Based Management (SPBM). Политика хранения может применяться не только к каждой виртуальной машине, но и к каждому диску внутри этой ВМ.

Давайте рассмотрим некоторые типовые сценарии использования vSAN для разных нужд.

СХД для катастрофоустойчивых решений

Одним из таких сценариев является построение растянутых катастрофоустойчивых кластеров DR/DA с синхронной репликацией данных между площадками. Кластеры vSAN, размещенные в двух разных ЦОД, дополняются «сервером-арбитром» с метаданными, находящимся в публичном облаке или на третьей площадке, удаленной от первых двух. При этом канал между двумя группами кластеров на разных площадках должен обеспечивать задержку не более 5 мс. Для связи с «арбитром» допустима задержка до 200 мс.

Если требуемые параметры по задержкам и связанности площадок выполнить невозможно, альтернативой может стать использование второй резервной площадки, управляемой другой копией vCenter и доступной с любой задержкой. В этом случае мы говорим об асинхронной репликации с заданным интервалом времени. Минимальное значение этого интервала – 5 мин.

Решение для филиалов

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

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

Экономически эффективным вариантом может стать и подключение двух узлов непосредственно друг к другу без коммутатора – через порты 10 Гбит/с при помощи двух перекрестных кабелей. При этом канал связи с Witness не требует большой пропускной способности.

Распределенная работа с традиционной архитектурой

После глобального перехода части сотрудников на удаленную работу встала проблема обслуживания приложений и настольных компьютеров пользователей. Очевидным ответом на эти вызовы стало VDI-решение VMware Horizon. При его использовании все данные остаются в ЦОД, там же работают и виртуальные машины с рабочими столами сотрудников. 

При таком сценарии отдельная традиционная СХД не оправдает ожиданий, так как, либо ее емкости окажется недостаточно для всех, либо она будет включать в себя избыточные резервы накопителей, что скажется на стоимости владения.

Удачным решением может стать vSAN, которая обеспечивает максимальную гибкость и, как уже говорилось, работает на одном уровне с виртуальными машинами и интегрирована в единую структуру управления VMware.

Ресурсы хранения для современных приложений

Компания VMware сейчас активно продвигает под брендом Tanzu собственную реализацию платформы контейнеризации Kubernetes, предназначенную для оркестрации cloud native-приложений. Они состоят из десятков или сотен постоянно обновляемых отдельных микросервисов.

Начиная с седьмой версии, vSAN может работать с такими приложениями через API-интерфейсы, для чего была разработана платформа Data Persistence Platform. Она является посредником между технологиями vSAN и теми подходами, которые используют для доступа к данным контейнеризованные приложения. 

Благодаря этому не происходит дублирования данных на уровне vSAN и уровне приложений, а также нет накладных расходов на взаимодействие через программные «прокладки», которые могли бы вызывать дополнительные задержки.

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

Если у вас остались вопросы, свяжитесь с нашими экспертами по решениям VMware - infra@syssoft.ru