Vmware vsan 7 настройка
Обновлено: 06.07.2024
обновлено январь 2015
VMware vSAN
Прислушавшись к совету в комментарии, решил обновить статью, используя более дешевые компоненты. В этой статье будет представлен типовой проект, построенный на технологии VMware vSAN.
SDS (software defined storage) – в настоящее время распределенные хранилища данных уже не просто модная тема для разговора, но проверенная в производственных системах технология, которая предлагает новый, более простой подход к построению кластеров на VMware. Вся система, как из кубиков, строится из одинаковых серверов, чем большая производительность требуется, тем больше серверов объединяются в кластер. Если мы добавляем в кластер один дополнительный сервер, то вместе с вычислительной мощностью (CPU и RAM) в общий пул добавляется общая полезная дисковая емкость.
Отдельно нужно сказать, что отказоустойчивость систем построенных на технологии VMware vSAN выше, чем у систем со стандартной архитектурой, которая часто не защищена от выхода из строя системы хранения данных. Мы принимаем на веру то, что СХД сама по себе максимально надежна и крайне мала вероятность того, что она может сломаться. В случае с подсистемой хранения vSAN, файлы виртуальных машин всегда хранятся, как минимум в двух экземплярах, которые постоянно синхронизируются (синхронно). Поэтому в случае выхода из строя любого хоста, работа виртуальных машин, которые работали на нем, восстановится в течении минуты (время перезагрузки ВМ).
Можно ли говорить о том, что стоимость проекта на VMware vSAN будет ниже, чем в классической архитектуре (серверы + СХД) серверной виртуализации? На самом деле, лицензирование VMware построено таким образом, что стоимость проектов получается равноценной, из-за стоимости лицензий vSAN. Но в России 2015 года, в тяжелой экономической ситуации, то программное обеспечение, которое раньше считалось пиратским, теперь переходит в разряд трофеев, поэтому в этой статье лицензии учитываться не будут, в отчаянной попытке экономии.
Проект на vSAN
В качестве хостов виртуализации будут рассчитаны серверы Supermicro, которые сама компания VMware часто рекомендует к использованию в своей референсной архитектуре. Больше всего для задач vSAN на мой взгляд подходит модель сервера SYS-2028U-TRT+, она есть в листе совместимости VMware и поддерживает компоненты, совместимые с vSAN. В дополнение к этому в базовой модели уже есть 4 x 10Gb интерфейса, которые будут нам нужны для репликации файлов виртуальных машин в vSAN, получается, что докупать HBA адаптеры не нужно.
10Gb коммутаторы для системы я выбрал самые бюджетные от Netgear XS708E. У них есть поддержка Jumbo Frames и необходимое количество портов. У нас будет выделенная 10Gb сеть для репликации vSAN и 10Gb сеть передачи данных для коммутации серверов и виртуальных машин между собой.
2 x CPU Intel Xeon E5-2620v3
128Gb DDR4 PC4-17000 (2133MHz)
1 x SSD Intel 530 Series 480Gb
5 x SAS Seagate 600Gb SAS 10k
RAID controller
4 x 10GBase-T портов
В результате всех экономий, на мой взгляд, получилась годная отказоустойчивая система, повторить функционал, которой на классической архитектуре будет очень дорого, т.к. потребуются как минимум две mid-range системы хранения.
Если типичная виртуальная машина у нас будет иметь характеристики 4vCPU 8Gb RAM Storage 70Gb, то на данной системе можно запустить 50 виртуальных машин.
В первом посте про 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), не добавив при этом нового сервера, а значит процессоров и памяти. Вариант, когда сервер используется только в качестве хранилища (т. е. вычислительный узел этого сервера простаивает), возможен, но экономически невыгоден: фактически это возврат к традиционной конфигурации и отказ от преимуществ конвергентного решения.
Материалы по системному и сетевому администрированию, информационной безопасности, администрированию баз данных и бизнес аналитике (BI).
четверг, 10 сентября 2020 г.
Рекомендации по проектированию VMware vSAN: Использование устройств хранения большого объема.
Больший объем хранилища эквивалентен большему объему потенциального ввода/вывода.
В общем виде хранение большого объема данных не отличается от хранения маленького объема. Но в окружениях с общим хранилищем (Shared Storage), отличие заключается в том, что больше данных, в форме виртуальных машин, может приводить к большему числу потенциальных чтений и записей.
Как в архитектуре гиперконвергентной инфраструктуры (HCI), так и в трехуровневой архитектуре, увеличение объема может приводить к возникновению узких мест в самых неожиданных местах. Например, трехуровневые архитектуры, как правило, генерируют больше нагрузки на контроллеры хранилища при увеличении объема сырого хранилища. Архитектура гиперконвергентной инфраструктуры (HCI) может увеличивать нагрузку на сеть при операциях записи с большего числа виртуальных машин на физических хостах.
Может показаться, что устройства высокой плотности могут обеспечить хорошую цену на один терабайт хранилища, но при этом они могут не справится с обеспечением рабочих нагрузок обращений к данным. Технический объем будет доступен, но при этом производительность обращения к данным будет не приемлемой. Для vSAN и VCF есть несколько путей приспособиться к этому.
Рекомендации для шины устройства и протокола.
Многие устройства высокой плотности привязаны к числовому значению объема и не предполагают уровней производительности и целостности, как правило ожидаемых в корпоративных окружениях. Флэш-устройства хранения с интерфейсом SATA относятся к данной категории. Такие устройства будут постоянно перегружены в борьбе за производительность и целостность из-за различных ограничений протокола, таких как: полудуплексная сигнализация, одно-командные очереди и более ресурсоемкая обработка ввода/вывода процессором. Устройства с SATA-подключением лучше подходят для конечных устройств и домашнего сегмента, так как характеристики SATA не рассчитаны на одновременный двунаправленный доступ к общему хранилищу.
Устройства высокой плотности могут создавать излишнюю нагрузку на общих адаптерах шины хоста (HBA), SAS в данном случае подходит лучше, чем SATA, но узкие места все равно могут возникать на общем контроллере, по мере увеличения траффика. Устройства NVMe не подвержены подобным проблемам, так как каждое устройство NVMe содержит собственный контроллер.
Рекомендация: Для устройств с большим объемом необходимо использовать как минимум устройства на базе SAS, идеальным же выбором на данный момент являются устройства NVMe.
Для устройств с большим объемом необходимо использовать как минимум устройства на базе SAS, идеальным же выбором на данный момент являются устройства NVMe.Рекомендации по проектированию дисковых групп (Disk Group).
Использование устройств со значительно большим объемом, неизбежно будет приводить к большему объему рабочих нагрузок, что в свою очередь может создавать дополнительный стресс на уровне буферизации. Это происходит из-за того, что дополнительные виртуальные машины обычно увеличивают агрегированный размер рабочего набора между хостами в кластере. Больший объем рабочих нагрузок, как правило, обозначает больше горячих данных. Несмотря на то, что vSAN Design and Sizing Guide описывает подбор размера уровня буфера в окружении с использованием только флэш-накопителей (All-flash) на базе информации о производительности, использование буфера большого объема для обеспечения большего объема рабочих нагрузок является разумным шагом.
Добавление большего числа дисковых групп на каждый хост, предоставляет больше доступной емкости буферизации, для поддержки дополнительных рабочих нагрузок. Не менее важно то, что больше дисковых групп увеличивают число возможных параллельных операций ввода/вывода.
Используйте больше дисковых групп на хост для увеличения параллелизации и общей емкости буферного кэша, для возможности поддержки больше объема активных/горячих данных.Рассчитывая необходимую производительность, зачастую слишком много внимания уделяют уровню хранения (Capacity Tier), особенно при увеличении емкости на хостах. Уровень буферизации (Buffer Tier) обеспечивает максимальное увеличение скорости ввода/вывода, а уровень хранения (Capacity Tier) обеспечивает максимальную скорость постоянного хранилища. Когда уровень хранения (Capacity Tier) не обладает достаточной высокой производительностью, длительная запись на высоком уровне может сокрушить возможности буфера. Скорость очистки буфера, обычно (но не всегда) зависит от производительности уровня хранения. В таком случае использование более быстрых флэш-устройств и/или их большего количества может увеличить производительность уровня хранения. Это поможет сократить задержку на уровне буфера за счет более быстрой очистки (передачи) и позволит избежать задержки на уровне гостевых виртуальных машин.
Если требуется обеспечить производительность уровня хранения, рекомендуется использовать высокопроизводительные устройства SAS или NVMe на уровне хранения.Рекомендации по времени эвакуации и восстановления.
Больший потенциальные объем обозначает более длительное время эвакуации, при условии использования исходной производительности сети.
Выполнить тест полной эвакуации хоста для определения общего времени, необходимого для эвакуации, и экстраполировать данное время на возможное значительное увеличение объема хранилища хоста. Если получается неприемлемое время, необходимо увеличение устройств хранения сопроводить расширением возможностей связанных коммутаторов.Рекомендации по количеству хостов.
Устройства высокой плотности провокационны, так как могут обеспечить необходимый объем при помощи меньшего числа устройств и/или хостов. Минимальное число хостов, необходимое для обеспечения определенного уровня устойчивости осталось прежним. Кроме того, несмотря на то, что каждый хост добавляет свою емкость, также он добавляет нагрузку на процессор и память, необходимую для обработки ввода/вывода. Значительное увеличение части ресурсов кластера может привести к возникновению узких мест.
Убедитесь, что количество хостов в кластере остается достаточным для поддержки необходимого уровня устойчивости.Итоги.
Устройства хранения высокой плотности открывают новые возможности для узлов vSAN. Гибкость архитектуры позволяет быстрее адаптировать практически любое решение vSAN. Также при проектировании следует учесть, чтобы кластер смог справится со всей возможной нагрузкой при обработке увеличенной емкости. Необходимо уделить отдельное внимание при проектировании решения с устройствами хранения высокой плотности, чтобы принять верные решения при покупке и получить ожидаемую производительность.
VMware Virtual SAN (vSAN) это высокопроизводительное решение для хранения данных корпоративного класса для гиперконвергентной инфраструктуры. vSAN позволяет объединять SSD накопители и обычные диски, подключенные к локальным ESXi серверам, в общее высокоустойчивое хранилище данных, к которому могут обращаться все узлы кластера vSphere. Если ранее для обеспечения высокой доступности администраторам VMware нужно было использовать SAN, NAS или DAS, то в случае vSAN потребность в выделенном внешнем общем хранилища исключается, при этом добавляется новый программный уровень, который может использовать локальные диски отдельных локальных серверов для обеспечения такой же отказоустойчивости и набора функций SAN.
Поддержка vSAN встроена в ядро гипервизора, благодаря чему решения по выполнению операций ввода/вывода и перемещению данных принимаются максимально быстро (большинство других решений организации виртуальных сред хранения реализуется в виде отдельного аплайнса, работающего над гипервизором). В этой статье мы расскажем об основных особенностях VMware vSAN и покажем процесс развертывания и настройки vSAN 6.5.
Примечание. Аналогом vSAN у Microsoft является технология Storage Spaces Direct (S2D), появившаяся в Windows Server 2016.
Основные возможности VMware vSAN
- Встроенный функционал защиты и обеспечения высокой доступности данных с отказоустойчивостью, асинхронной репликацией на большие расстояния и растянутыми кластерами между географически разнесенными сайтами.
- Использование распределенного RAID и зеркалирования кэша для защиты данных от потери отдельного диска, сервера или целой стойки
- Минимизация задержек хранилищ за счет ускорения операций чтения/записи с дисков за счет встроенного кэша на сервере, хранящиегося на локальных SSD дисках
- Программная дедупликация и сжатие данных при минимальными затратами ресурсов CPU и памяти
- Возможность без простоя наращивать емкость и производительность сети хранения за счет добавления новых серверов и дисков
- Политики хранения виртуальных машин позволяют автоматизировать балансировку и выделение ресурсов хранения и QoS.
- Полная интеграция со стеком VMware, включая vMotion, DRS, высокую доступность (High Availability), отказоустойчивость (Fault Tolerance), Site Recovery Manager, vRealize Automation и vRealize Operations.
- Поддержка iSCSI подключений
VMware vSAN: системные требования
- Требуется VMware vCenter Server 6.5 и хосты с ESXi 6.5
- Минимум 3 хоста в кластере (максимум 64), однако можно реализовать vSAN и на двух хостах, но потребуется отдельный хост-свидетель
- Каждый сервера ESXi в кластере vSAN должен иметь как минимум один SSD диск (флешку) для кэша, и как минимум один SSD/HDD для данных
- Наличие SATA/SAS HBA или RAID-контроллера в режиме pass-through или в режиме RAID 0
- Минимум 1 ГБ сетевая карта (рекомендуется 10 Гб)
- Все хосты должны быть подключены к сети vSAN через сеть L2 или L3
- На физических коммутаторах, которые обрабатывают трафик vSAN должна быть включено многоадресное вещание (мультикаст)
- Поддерживаются как IPv4 так и IPv6.
- Информацию о совместимости с конкретным железом нужно смотреть в соответствующем документе на сайте VMware
Лицензирование VMware vSAN
vSAN лицензируется в расчете по CPU, виртуальным машинам или конкурентным пользователю и поставляется в трех редакциях: Standard, Advanced и Enterprise.
- Enterprise лицензия – требуется для использования QoS и растянутых кластеров
- Advanced лицензия нужна для поддержки дедубликации, сжатия и RAID 5/6
- Standard – базовый функционал
Лицензия vSAN можно использовать на любой версии vSphere 6.5.
Есть дополнительные способы сэкономить за счет использовании пакета Virtual SAN для ROBO, или приобретения набора лицензий Standard илиAdvanced в количестве 25 штук для удаленных филиалов. Более подробную информацию о лицензировании vSAN смотрите на сайте VMware.
Настройка сети и портов vSAN
Перед настройкой vSAN нужно убедится, что на каждом хосте кластере настроен порт VMkernel для трафика vSAN. В веб-клиенте vSphere по очереди выберите каждый сервер, на котором вы хотите использовать vSAN. Выберите вкладку Configure-> Networking -> VMKernel Adapters -> нажмите Add Host Networking. Убедитесь, что выбран тип VMkernel Network Adapter и нажмите Далее.
Создайте новый виртуальный коммутатор (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.
Проверьте выбранные настройки и нажмите Finish. Дождитесь окончания выполнения задачи, после чего виртуальная сеть SAN объединит все локальные диски серверов выбранного кластера в распределенное хранилище vSAN. Данное хранилище представляет собой один единый VMFS датастор, на который вы сразу же можете поместить виртуальные машины. Настройки vSAN в дальнейшем можно будет изменить в том же разделе (вкладка кластера Configure -> Virtual SAN).
Читайте также: