vmware vsan что это
Новые возможности vSAN
Узнайте, как легко внедрить гиперконвергентную инфраструктуру для повышения адаптивности и снижения совокупной стоимости владения с помощью нового выпуска VMware vSAN.
Внедрение гибридного облака с помощью удобной, надежной и готовой к будущему инфраструктуры
Технический обзор: новые возможности vSAN 7 Update 3
Ознакомьтесь с новыми возможностями и улучшениями, представленными в новейшем выпуске.
Предоставление сервисов с сохранением состояния на платформе vSAN Data Persistence
Обеспечьте снижение совокупной стоимости владения и повышение производительности приложений с помощью платформы vSAN Data Persistence, предоставляющей тесную интеграцию с инфраструктурой VMware и Kubernetes.
Лидер рынка HCI
vSAN остается ведущим решением для HCI: количество заказчиков составляет уже более 30 000, а его доля на рынке в 1-м квартале 2021 года превысила 43%.
Удовлетворение ваших потребностей с помощью vSAN
Ознакомьтесь с техническим обзором сценариев использования vSAN и материалами для конкретных отраслей.
Каталог конференции VMworld 2021 уже доступен
Более 600 сессий, 8 учебных программ, практикумы Hands-on Lab, консультации экспертов и многое другое.
Новые возможности vSAN 7 Update 3
Предоставление инфраструктуры ИИ и машинного обучения для разработчиков
* Решение Dell EMC ObjectScale приобретается отдельно
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
VMware vSAN
vSAN является основным структурным блоком программного ЦОД.
Содержание
Особенности
Ускорение модернизации инфраструктуры с помощью VMware vSANTM превращает ИТ в стратегическое и экономическое преимущество для вашей компании. Благодаря использованию ведущих на рынке решений vSAN в качестве основы для гиперконвергированной инфраструктуры заказчики получают возможность развивать ЦОД без риска, управлять ИТ-расходами и готовиться к решению будущих задач. Решение vSAN, встроенное в ведущий на рынке гипервизор, обеспечивает оптимизированное для флэш-накопителей и безопасное хранилище для всех критических рабочих нагрузок vSphere. vSAN базируется на стандартных серверах и компонентах x86, которые способствуют снижению совокупной стоимости владения на 50% по сравнению с традиционными хранилищами. Оно обладает адаптивностью, необходимой для удобства масштабирования ИТ-среды, и отличается первой в отрасли встроенной подсистемой шифрования для гиперконвергированной инфраструктуры. Новые усовершенствованные распределенные кластеры и интеллектуальные операции в 1 действие сокращают расходы, в результате чего становится более умеренной стоимость защиты среды (на 50% меньше, чем у ведущих традиционных решений) и упрощается повседневное управление. Кроме того, полная интеграция с VMware vSphere и всеми продуктами VMware делает это решение самой удобной платформой хранения для любых рабочих нагрузок виртуальных машин — важных баз данных, виртуальных компьютеров или приложений нового поколения.
vSAN for Desktop
Модель лицензирования vSAN for Desktop предоставляет специальный вариант лицензирования для пользователей VDI. Стоимость vSAN for Desktop рассчитывается по числу параллельных подключений в среде VDI. Продажа осуществляется пакетами по 10 или 100 лицензий. vSAN for Desktop входит также в состав пакетов Horizon Advanced и Enterprise с лицензией vSAN Advanced.
vSAN for ROBO
Решение vSAN for Remote Office Branch Office (ROBO) предназначено для удаленных офисов с низкими коэффициентами консолидации. Это решение продается пакетами по 25 виртуальных машин при использовании vSAN Standard, vSAN Advanced или vSAN Enterprise. Пакеты можно распределять между удаленными средами. Число виртуальных машин в каждой среде не может превышать 25.
Выбор подходящего оборудования
Компания VMware — это единственный поставщик, работающий со всеми ведущими производителями серверов x86, чтобы предоставить решение для создания гиперконвергированной инфраструктуры с наиболее широким набором вариантов развертывания и максимально гибкими условиями использования оборудования и программного обеспечения, а также лицензирования и поддержки. При выборе подходящей аппаратной платформы необходимо изучать материалы об узлах vSAN ReadyNode.
Преимущества
Сегодня каждая бизнес-задача представляет собой один или несколько IТ-проектов. В результате постоянной цифровой трансформации перед IТ-отделами встает необходимость в более удобном и экономичном подходе к инфраструктуре центра обработки данных, при котором не требовалось бы полное переобучение.
Будучи единственной встроенной платформой для программного хранилища vSphere, решение vSAN помогает заказчикам переходить на гиперконвергированную инфраструктуру без риска, при этом сокращая IТ-расходы и обеспечивая адаптивное решение, готовое к будущим изменениям в оборудовании, облаках и приложениях. vSAN предоставляет оптимизированное для флэш-накопителей и безопасное хранилище благодаря первому в отрасли встроенному решению для шифрования в гиперконвергированной инфраструктуре, причем по меньшей цене по сравнению с традиционными специализированными хранилищами и менее эффективными гиперконвергированными решениями.
За счет объединения серверных хранилищ в пул vSAN обеспечивает создание высокоустойчивого общедоступного хранилища, которое подходит для любой виртуализированной рабочей нагрузки, в том числе для важных бизнес-приложений, виртуальных компьютеров, удаленной IТ-инфраструктуры, а также для аварийного восстановления и интегрированной разработки и эксплуатации.
Архитектура и производительность. Тесно интегрированная с гипервизором архитектура vSAN находится непосредственно на пути передачи данных ввода-вывода, что обеспечивает быстрое и оптимальное размещение данных. Таким образом, в отличие от других виртуальных устройств для хранения и ПО для гиперконвергированной инфраструктуры, выполняющихся поверх гипервизора, vSAN обеспечивает высочайший уровень производительности без дополнительной нагрузки на ЦП и ресурсы памяти. Решение vSAN можно настроить как гибридное хранилище или как хранилище на основе флэш-накопителей, в котором обеспечивается выполнение до 6 млн операций ввода-вывода в секунду.
Возможности
Тесная интеграция с vSphere. Решение vSAN встроено в ядро vSphere, что обеспечивает оптимизацию ввода-вывода и производительность высочайшего уровня при минимальной нагрузке на процессор и память.
Оптимизация для работы с флэш-накопителями. Благодаря встроенному кэшированию на серверных флэш-накопителях vSAN сокращает время задержки хранилища. Последняя оптимизация в версии vSAN 6.6 обеспечивает скорость ввода-вывода на 50% выше, чем это было возможно ранее. Стоимость развертывания vSAN на основе флэш-накопителей не превышает 1 доллара на 1 ГБайт полезной емкости, что более чем в два раза ниже аналогичного показателя для конкурирующих гибридных гиперконвергированных решений.
Гибкое горизонтальное или вертикальное масштабирование без прерывания работы. Увеличение емкости и производительности без прерывания работы за счет добавления новых узлов в кластер (горизонтальное масштабирование) или дисков в существующие узлы (вертикальное масштабирование).
Исключение дублирования и сжатие. Исключение дублирования и сжатие на основе ПО оптимизируют емкость хранилища на основе флэш-накопителей и в 7 раз сокращают объем данных при минимальном дополнительном расходе памяти и ресурсов процессора.
Механизм Erasure Coding. Erasure Coding обеспечивает почти двукратное увеличение полезной емкости хранилища без влияния на уровень устойчивости данных. Благодаря одинарному или двойному контролю по четности обеспечивается устойчивость к одному или двум сбоям.
Область применения
Традиционная архитектура включает три ключевых компонента:
Для управления таким хозяйством необходимы три разных интерфейса, три разных компетенции и, по-хорошему, три разных специалиста.
Развертывание такой архитектуры занимает много времени, и быстрое масштабирование здесь тоже весьма нетривиальная задача.
Если ваш проект подразумевает прогнозируемое и планомерное масштабирование, на добавление нового хранилища есть неделя, а в штате есть специалисты, которые будут заниматься проектированием, то традиционная архитектура – ваш выбор.
Когда же у вас проект (например, 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 (storage node), не добавив при этом нового сервера, а значит процессоров и памяти. Вариант, когда сервер используется только в качестве хранилища (т. е. вычислительный узел этого сервера простаивает), возможен, но экономически невыгоден: фактически это возврат к традиционной конфигурации и отказ от преимуществ конвергентного решения. [Источник 2]
VMware vSAN™ на практике: для каких задач подходит
VMware vSAN™ на практике: для каких задач подходит
Сегодня многие компании делают ставку на гиперконвергентность, уходя от традиционной архитектурной модели к HCI. Хотите узнать почему? В статье мы ответим на этот вопрос и расскажем для каких задач подходит VMware vSAN™.
Конвергентная СХД
Традиционная архитектура за многие годы своего существования отлично себя зарекомендовала, она надежна, практична и универсальна. Все три ее компонента, а именно серверы, системы хранения данных (СХД) и сети хранения данных, взаимодействуют на высоких скоростях и обеспечивают хорошую отказоустойчивость, вот только ее строительство, обслуживание и масштабирование – задача долгового времени и больших денег. Когда результат нужен быстро, а в современном бизнесе, облачном или другом, потребность в вычислениях меняется очень динамично – удобнее становятся «кирпичики» конвергентных систем. Поэтому если вы строите инфраструктуру для ресурсоемких бизнес-задач или планируете ее масштабирование – обратите внимание на HCI.
VMware предлагает объединить на одном устройстве и вычислительные функции, и функции хранения – развернуть конвергентное программное решение VMware vSAN™. Такая конвергентная СХД не требует специальных устройств и сетей передачи данных, она работает прямо на сервере и способна выполнят ту же задачу, что и внешняя система хранения. Так в чем же отличие vSAN от простого дискового массива и для решения каких задач она может быть полезна.
Принцип работы
vSAN использует диски сервера для создания виртуального хранилища, которое доступно всем узлам кластера vSphere. Программно это работает на том же гипервизоре, что и сама платформа виртуализации, параллельно с вычислительной частью. Соответственно, на сервере одновременно работает и виртуальная СХД и виртуальные серверы – конвергенция. Для отказоустойчивости, необходимы несколько узлов, диски которых создадут единое пространство хранения доступные даже в случае аварии на одном из серверов. Теперь подробнее.
Каждый хост (узел кластера, сервер) является частью общего кластера vSAN и должен иметь хотя бы одну дисковую группу. Дисковая группа состоит из 1 диска для кэша (быстрый SSD) и от 1 до 7 дисков хранения (обычных HDD или также SSD). На сервере может быть до 5 таких групп, следовательно, максимальный объём хранения на одном сервере будет состоять из емкостей 35 дисков, а минимальный – одного.
Для того чтобы кластер vSAN работал требуется минимум 2 хоста, дисковые группы которых будут зеркальными для обеспечения непрерывной работы в случае отказа. Такая конфигурация работает только с методом отказоустойчивости Mirroring (аналог RAID1). В нем параметр Number of failures to tolerate равен единице, то есть данные с одного хоста сразу синхронизируется на другом. Добавив еще один хост и выставив параметр FTT=2 данные будут реплицироваться на двух серверах, что повышает степень отказоустойчивости, но делает использование дискового пространства еще менее эффективным. Максимальное значение FTT=3 позволяют иметь экземпляры данных на 4 разных хостах.
Если вы используете AllFlash-конфигурацию, то есть на узлах установлены только SSD-диски, то можно использовать метод Erasure Coding (аналог RAID 5/6). Запись на дисковые группы сопровождается вычислением соответствующих блоков четности, которые позволяют восстановить данные при сбое. Так можно существенно сэкономить дисковое пространство, но проиграть в скорости и времени восстановления. Минимальное число хостов необходимых для работы Erasure Coding – 4, но рекомендуется от 5 до 7.
Стандартный вариант организации vSAN использует хосты под управлением гипервизоров ESXi, но возможны решения с vSAN Appliance и Storage Appliance. При установленной vSphere, активировать vSAN можно без дополнительных плагинов и надстроек, а все управление выполняется из vCenter.
Особенности vSAN
Успешное внедрение vSAN зависит от многих факторов, но есть базовые требования и особенности, которые необходимо знать, чтобы не допустить ошибок.
Задачи для vSAN
Первая задача, которую успешно решает vSAN – это СХД для платформы виртуализации vSphere. Как мы писали в самом начале, можно собрать полноценный отказоустойчивый кластер из обычных серверов без необходимости покупки дополнительного оборудования хранения данных. Такое решение не только экономически эффективно, так как снижает капитальные затраты на СХД и сеть передачи данных, но и удобнее с точки зрения управления, к тому же быстро разворачивается.
Используя All-Flash дисковые группы, Erasure Coding и быструю сеть, можно построить довольно производительную СХД для бизнес-критичных приложений. В такой конфигурации очень уверенно себя чувствуют Oracle, MS SQL/Exchange, SAP и другие производительные приложения.
Легкое масштабирование путем добавления конвергентных узлов (вычислительные ресурсы и СХД) делает vSAN удобным для таких задач как VDI (новые пользователи – новый узел), контейнеры (надо развернуть больше контейнеров – добавляем узел), web-приложения (растет база и нагрузка – добавляем новый узел), облачные услуги (появляются новые клиенты – добавляем новый узел).
Использование растянутого кластера позволяет использовать vSAN для удаленных филиалов или резервных площадок. Каждый узел кластера в удаленном офисе может содержать копию данных центральной площадки, тем самым обеспечивая высокую скорость доступа, централизованное управление, а главное, отказоустойчивость в случае падения линии связи.
Заключение
Использование vSAN позволяет сократить расходы, дает возможность гибкой масштабируемости и простого управления единой экосистемой VMware. Решения HCI находятся на пике популярности, это обусловлено универсальностью и скоростью внедрения. Бизнес требует мгновенной реакции на изменения и такие конвергентные решения как vSAN позволяют дать быстрый, надежный и производительный результат.
Особенности VMware vSAN 6.5: FAQ и настройка кластера
VMware Virtual SAN (vSAN) это высокопроизводительное решение для хранения данных корпоративного класса для гиперконвергентной инфраструктуры. vSAN позволяет объединять SSD накопители и обычные диски, подключенные к локальным ESXi серверам, в общее высокоустойчивое хранилище данных, к которому могут обращаться все узлы кластера vSphere. Если ранее для обеспечения высокой доступности администраторам VMware нужно было использовать SAN, NAS или DAS, то в случае vSAN потребность в выделенном внешнем общем хранилища исключается, при этом добавляется новый программный уровень, который может использовать локальные диски отдельных локальных серверов для обеспечения такой же отказоустойчивости и набора функций SAN.
Поддержка vSAN встроена в ядро гипервизора, благодаря чему решения по выполнению операций ввода/вывода и перемещению данных принимаются максимально быстро (большинство других решений организации виртуальных сред хранения реализуется в виде отдельного аплайнса, работающего над гипервизором). В этой статье мы расскажем об основных особенностях VMware vSAN и покажем процесс развертывания и настройки vSAN 6.5.
Основные возможности VMware vSAN
VMware vSAN: системные требования
Лицензирование VMware vSAN
vSAN лицензируется в расчете по CPU, виртуальным машинам или конкурентным пользователю и поставляется в трех редакциях: Standard, Advanced и Enterprise.
Лицензия vSAN можно использовать на любой версии vSphere 6.5.
Есть дополнительные способы сэкономить за счет использовании пакета Virtual SAN для ROBO, или приобретения набора лицензий Standard илиAdvanced в количестве 25 штук для удаленных филиалов. Более подробную информацию о лицензировании vSAN смотрите на сайте VMware.
Настройка сети и портов vSAN
Создайте новый виртуальный коммутатор (New standard switch) и нажмите Next.
С помощью зеленого значка плюса привяжите физические адаптеры к коммутатору. В продуктивных средах желательно обеспечить дополнительное резервирование за счет использования несколько физических NIC.
Укажите имя порта VMkernel и, если нужно, его VLAN ID. Обязательно поставьте галку напротив опции Virtual SAN и нажмите Next.
Укажите сетевые параметры порта VMkernel.
Если вы настраиваете сеть vSAN на тестовом стенде с ограниченным количеством физических интерфейсов, выберите сеть управления (Management Network) и в списке поддерживаемых служб поставьте галку у пункта Virtual SAN. При такой конфигурации трафик vSAN будет идти через общую сеть управления, чего в продуктивных развертываниях делать не стоит.
Настройка vSAN
Как мы уже говорили, для настройки vSAN дополнительно доставлять что+то на гипервизор не нужно, весь функционал уже имеется. Вся что требуется от администратора – настроить vSAN через интерфейс веб клиента vSphere (vSAN пока не поддерживает модный HTML5 клиент).
Чтобы включить vSAN найдите нужный кластер в консоли vSphere и перейдите на вкладку Configure. Разверните раздел Virtual SAN и выберите General. В нем должно быть указано, что Virtual SAN не включен. Нажмите на кнопку Configure.
По умолчанию в хранилище vSAN будут добавлены любые подходящие диски. Чтобы вручную выбрать диски, измените параметр назначения дисков на Manual. Здесь же можно включить опцию сжатия данных, отказоустойчивости.
На странице валидации сети должны появится подтверждения о том, что каждый хост в кластере подключен к сети vSAN.
vSAN в облаке на базе VMware
Задачи хранения и доступа к данным являются болевой точкой для любой информационной системы. Даже у хорошо спроектированной системы хранения данных (далее СХД) в процессе эксплуатации выявляются проблемы, связанные со снижением производительности. Отдельного внимания заслуживает комплекс проблем масштабирования, когда количество задействованных ресурсов приближается к установленным лимитам, заложенным разработчиками СХД.
Фундаментальной причиной возникновения этих проблем является традиционная архитектура, основанная на жесткой привязке к аппаратным характеристикам используемых устройств хранения данных. Большинство клиентов до сих пор выбирают способ хранения и доступа к данным с учетом характеристик физических интерфейсов (SAS / SATA / SCSI), а не реальных потребностей используемых приложений.
Еще десяток лет назад это было логичным решением. Системные администраторы тщательно выбирали накопители информации с требуемой спецификацией, например SATA/SAS, и рассчитывали на получение уровня производительности, исходя из аппаратных возможностей дисковых контроллеров. Борьба шла и за объемы кэшей RAID-контроллеров и за опции, предотвращающие потерю данных. Сейчас такой подход к решению проблемы не является оптимальным.
В текущих условиях при выборе СХД имеет смысл отталкиваться не от физических интерфейсов, а от производительности, выраженной в IOPS (количество операций ввода-вывода в секунду). Использование виртуализации позволяет гибко использовать существующие аппаратные ресурсы и гарантировать требуемый уровень производительности. Мы со своей стороны готовы предоставить ресурсы с теми характеристиками, которые реально необходимы приложению.
Виртуализация СХД
С развитием систем виртуализации требовалось найти инновационное решение для хранения и доступа к данным, одновременно обеспечивая отказоустойчивость. Это стало отправной точкой для создания SDS (Software-Defined Storage). Чтобы удовлетворять бизнес-потребностям, такие хранилища проектировались с разделением программного и аппаратного обеспечения.
Архитектура SDS в корне отличается от традиционной. Логика хранения стала абстрагироваться на программном уровне. Организация хранения стала проще за счет унификации и виртуализации каждого из компонентов такой системы.
Что же является основным фактором, препятствующим внедрению SDS повсеместно? Этим фактором чаще всего оказывается некорректная оценка потребностей используемых приложений и неверная оценка рисков. Для бизнеса выбор решения зависит от затрат на внедрение, исходя из текущих потребляемых ресурсов. Мало кто думает — что будет, когда объем информации и требуемая производительность превысит возможности выбранной архитектуры. Мышление на базе методологического принципа «не следует множить сущее без необходимости», более известного как «лезвие Оккама», обуславливает выбор в пользу традиционных решений.
Лишь немногие понимают, что необходимость в масштабировании и надежности хранения данных важнее, чем кажется на первый взгляд. Информация это ресурс, а следовательно, риск ее потери необходимо страховать. Что будет, когда традиционная СХД выйдет из строя? Потребуется воспользоваться гарантией либо купить новое оборудование. А если СХД снята с производства или у нее закончился «срок жизни» (так называемый EOL — End-of-Life)? Это может стать «черным днем» для любой организации, которая не сможет продолжать использовать привычные собственные сервисы.
Не существует систем, которые бы не имели ни одной точки отказа. Зато есть системы, которые способны без проблем пережить отказ одного или нескольких компонентов. И виртуальные, и традиционные СХД создавались с учетом того, что рано или поздно произойдет сбой. Вот только «лимит прочности» традиционных СХД заложен аппаратно, а вот в виртуальных СХД он определяется в программном слое.
Интеграция
Кардинальные перемены в IT-инфраструктуре всегда нежелательное явление, чреватое простоями и потерей средств. Только плавное внедрение новых решений дает возможность избежать негативных последствий и улучшить работу сервисов. Именно поэтому Selectel разработал и запустил облако на базе VMware, признанного лидера на рынке систем виртуализации. Созданная нами услуга позволит каждой компании решить весь комплекс инфраструктурных задач, в том числе и по хранению данных.
Расскажем о том, как именно мы решили вопрос с выбором системы хранения данных, а также какие преимущества дал нам этот выбор. Разумеется, что рассматривались как традиционные системы хранения данных, так и SDS. Чтобы четко понимать все аспекты эксплуатации и риски, предлагаем детально углубиться в тему.
Еще на этапе проектирования к СХД предъявлялись следующие требования:
Использование традиционных аппаратных решений не могло обеспечить требуемый уровень масштабирования, поскольку невозможно постоянно наращивать объем хранилища из-за ограничений архитектуры. Также большую сложность представляло резервирование на уровне целого дата-центра. Именно поэтому мы обратили внимание на SDS.
На рынке SDS присутствует несколько программных решений, которые бы подошли нам для построения облака на базе VMware vSphere®. Среди этих решений можно отметить:
Указанные решения пригодны для использования c VMware vSphere, однако не встраиваются в гипервизор и запускаются отдельно. Поэтому выбор был сделан в пользу VMware Stretched vSAN™. Рассмотрим детально, как выглядит виртуальная архитектура такого решения.
Архитектура
В отличие от традиционных СХД вся информация не хранится в какой-то одной точке. Данные виртуальных машин равномерно «размазаны» между всеми хостами, а масштабирование осуществляется добавлением хостов или установкой на них дополнительных дисковых накопителей. Поддерживается два варианта конфигурации:
Процедура добавления дискового пространства не требует дополнительных настроек, например, создания LUN (Logical Unit Number, логических номеров дисков) и настройки доступа к ним. Как только хост добавлен в кластер, его дисковое пространство становится доступным для всех виртуальных машин. Такой подход имеет ряд существенных преимуществ:
Однако эта архитектура предъявляет повышенные требования к сетевой инфраструктуре. Для обеспечения максимальной пропускной способности, в нашем облаке сеть построена по модели Spine-Leaf.
Традиционная трехуровневая сетевая модель (ядро / агрегация / доступ) имеет ряд существенных недостатков. Ярким примером являются ограничения Spanning-Tree протоколов.
В модели Spine-Leaf используется только два уровня, что дает следующие преимущества:
Ключевой особенностью такой архитектуры является то, что она максимально оптимизирована для прохождения «горизонтального» трафика. Пакеты данных проходят только через один хоп, что позволяет четко оценивать задержки.
Физическое соединение обеспечивается с помощью нескольких 10GbE-линков на каждый сервер, пропускная способность которых объединяется с помощью протокола агрегации. Таким образом, каждый физический хост получает высокую скорость доступа ко всем объектам хранилища.
Обмен данными реализуется с помощью проприетарного протокола, созданного VMware, позволяющего обеспечить быструю и надежную работу сети хранения на Ethernet-транспорте (от 10GbE и выше).
Переход к объектной модели хранения данных позволил гибко подстраивать использование хранилища в соответствие с требованиями заказчиков. Все данные хранятся в виде объектов, которые определенным образом распределяются по хостам кластера. Уточним значения некоторых параметров, которыми можно управлять.
Отказоустойчивость
1. FTT (Failures To Tolerate). Обозначает количество отказов хостов, которые кластер способен обработать, не прерывая штатной работы.
2. FTM (Failure Tolerance Method ). Метод обеспечения отказоустойчивости на уровне дисков.
Представляет собой полное дублирование объекта, причем реплики всегда находятся на разных физических хостах. Ближайшим аналогом такого метода является RAID-1. Его использование позволяет кластеру штатно обработать до трех отказов любых компонентов (диски, хосты, потеря сети и прочее). Этот параметр настраивается посредством задания опции FTT.
По-умолчанию эта опция имеет значение 1, при этом для объекта создается 1 реплика (всего 2 экземпляра на разных хостах). При увеличении значения, количество экземпляров будет составлять N+1. Таким образом, при максимальном значении FTT=3 на разных хостах будут находиться 4 экземпляра объекта.
Такой метод позволяет достичь максимальной производительности в ущерб эффективности использования дискового пространства. Допускается использование как в гибридной, так и в AllFlash-конфигурации.
Работа данного метода поддерживается исключительно на AllFlash-конфигурациях. В процессе записи каждого объекта вычисляются соответствующие блоки четности, позволяющие однозначно восстановить данные при возникновении сбоя. Такой подход существенно экономит дисковое пространство по сравнению с Mirroring.
Разумеется, работа подобного метода повышает накладные расходы, которые выражаются в снижении производительности. Тем не менее, с учетом производительности AllFlash-конфигурации, этот недостаток нивелируется, делая использование Erasure Coding приемлемым вариантом для большинства задач.
Кроме того, VMware vSAN вводит понятие «доменов отказа», представляющих собой логическое группирование серверных стоек или дисковых корзин. Как только необходимые элементы сгруппированы, это приводит к распределению данных по разным узлам с учетом доменов отказа. Это позволяет кластеру пережить потерю целого домена, поскольку все соответствующие реплики объектов будут располагаться на других хостах в другом домене отказа.
Минимальным доменом отказа является дисковая группа, представляющая собой логически связанные дисковые накопители. Каждая дисковая группа содержит в себе носители двух типов — cache и capacity. В качестве cache-носителей система позволяет использовать только твердотельные диски, а в качестве capacity-носителей могут выступать как магнитные, так и твердотельные диски. Кэширующие носители помогают ускорить работу магнитных дисков и уменьшить задержку при доступе к данным.
Реализация
Поговорим о том, какие ограничения существуют в архитектуре VMware vSAN и зачем они нужны. Вне зависимости от используемых аппаратных платформ, архитектура предусматривает следующие ограничения:
Зачем это нужно? Пока указанные лимиты не превышены, система будет функционировать с заявленной производительностью, поддерживая баланс между производительностью и объемом хранения. Это позволяет гарантировать корректную работу всей виртуальной СХД в целом.
Помимо указанных ограничений следует помнить одну важную особенность. Не рекомендуется заполнять более 70% общего объема хранилища. Дело в том, что при достижении 80% автоматически запускается механизм ребалансировки, и система хранения начинает перераспределять данные по всем хостам кластера. Процедура достаточно ресурсоемкая и может серьезно сказаться на производительности дисковой подсистемы.
Чтобы удовлетворить потребности самых разных клиентов, нами было реализовано три пула хранения данных для удобства использования в различных сценариях. Давайте рассмотрим каждый из них по порядку.
Пул с быстрыми дисками
Приоритетом для создания этого пула было получить хранилище, которое обеспечит максимальную производительность для размещения высоконагруженных систем. Серверы из этого пула используют пару Intel® P4600 в качестве кэша и 10 Intel® P3520 для хранения данных. Кэш в этом пуле используется таким образом, чтобы чтение данных происходило напрямую с носителей, а операции записи происходили через кэш.
Для увеличения полезной емкости и обеспечения отказоустойчивости используется модель хранения данных под названием Erasure Coding. Такая модель схожа с обычным массивом RAID 5/6, но на уровне объектного хранилища. Чтобы исключить вероятность повреждения данных, vSAN использует механизм вычисления контрольных сумм для каждого блока данных, размером 4К.
Проверка осуществляется в фоновом режиме во время операций чтения/записи, а также для «холодных» данных, доступ к которым не запрашивался в течение года. При выявлении несовпадения контрольных сумм, а следовательно, повреждения данных, vSAN автоматически восстановит файлы путем перезаписи.
Пул с гибридными дисками
В случае с этим пулом, его основной задачей является предоставление большого объема данных, обеспечивая при этом хороший уровень отказоустойчивости. Для многих задач скорость доступа к данным не является приоритетной, гораздо более важен объем, а еще стоимость хранения. Использование твердотельных накопителей в качестве такого хранилища будет иметь необоснованно высокую стоимость.
Этот фактор и послужил причиной создания пула, который представляет собой гибрид из кэширующих твердотельных накопителей (как и в других пулах это Intel® P4600) и жестких дисков корпоративного уровня, разработанных компанией HGST. Гибридная схема работы ускоряет доступ к часто запрашиваемым данным, за счет кэширования операций чтения и записи.
На логическом уровне данные зеркалируются для исключения потери в случае сбоя оборудования. Каждый объект разбивается на идентичные компоненты и система распределяет их по разным хостам.
Пул с Disaster Recovery
Основной задачей пула является достижение максимального уровня отказоустойчивости и производительности. Задействование технологии Stretched vSAN позволило нам разнести хранилище между дата-центрами Цветочная-2 в Санкт-Петербурге и Дубровка-3 в Ленинградской области. Каждый сервер из данного пула оснащен парой емких и высокоскоростных накопителей Intel® P4600 для работы кэша и по 6 штук Intel® P3520 для хранения данных. На логическом уровне это 2 дисковые группы на хост.
AllFlash-конфигурация лишена серьезного недостатка — резкого падения IOPS и увеличения очереди дисковых запросов при увеличенном объеме операций произвольного доступа к данным. Так же, как и в пуле с быстрыми дисками операции записи проходят через кэш, а чтение осуществляется напрямую.
Теперь о главном отличии от остальных пулов. Данные каждой виртуальной машины зеркалируются внутри одного дата-центра и при этом синхронно реплицируются в другой, принадлежащий нам, дата-центр. Таким образом, даже серьезная авария, такая как полное нарушение связности между дата-центрами не станет проблемой. Даже полная потеря дата-центра не затронет данные.
Авария с полным отказом площадки — ситуация достаточно редкая, однако vSAN с честью может ее пережить, не потеряв данные. Гости проводимого нами мероприятия SelectelTechDay 2018 смогли собственными глазами увидеть, как кластер Stretched vSAN пережил полный отказ площадки. Виртуальные машины стали доступны уже через одну минуту после того, как все серверы на одной из площадок были выключены по питанию. Все механизмы сработали именно так, как было запланировано, а данные остались нетронутыми.
Отказ от привычной архитектуры хранения данных влечет за собой массу изменений. Одним из таких изменений стало появление новых виртуальных «сущностей», к которым относятся и witness appliance. Смысл этого решения в том, чтобы отслеживать процесс записи реплик данных и определять, какая из них является актуальной. При этом самих данных на witness-компонентах не хранится, только метаданные о процессе записи.
Этот механизм вступает в действие в случае аварии, когда в процессе репликации происходит сбой, результатом которого является рассинхронизация реплик.
Чтобы определить, какая из них содержит актуальную информацию, используется механизм определения кворума. Каждый компонент обладает «правом голоса», и ему присваивается некоторое количество голосов (1 и более). Такое же «право голоса» имеют и witness-компоненты, играющие роль арбитров, при возникновении спорной ситуации.
Кворум достигается только в том случае, когда для объекта доступна полная реплика и количество текущих «голосов» составляет более 50%.
Заключение
Выбор VMware vSAN, как системы хранения данных, стал для нас достаточно важным решением. Этот вариант прошел нагрузочное тестирование и проверку отказоустойчивости, прежде чем был включен в проект нашего облака на базе VMware.
По результатам тестов стало ясно, что заявленный функционал работает как положено и удовлетворяет всем требованиям нашей облачной инфраструктуры.
Есть о чем рассказать на основе собственного опыта работы с vSAN? Добро пожаловать в комментарии.