Vmware vsan что это
Как мы тестировали VMware vSAN™: для чего это подходит на практике
Год назад я собрал дата-центр из стопки Intel NUC. Там была программная система хранения данных, которую не смогла порушить уборщица, пару раз развалившая кластер.
И вот теперь мы решили погонять vSAN на нескольких серверах в очень хорошей конфигурации, чтобы всецело оценить производительность и отказоустойчивость решения. Конечно, у нас был ряд успешных внедрений в продакшен у наших заказчиков, где vSAN успешно решает поставленные задачи, но провести всеобъемлющее тестирование не доводилось. Собственно, результатами тестов я и хочу сегодня поделиться.
Будем мучить хранилище нагрузкой, ронять его и всячески тестировать отказоустойчивость. За подробностями всех приглашаю под кат.
Что вообще такое VMware vSAN и зачем мы в это полезли?
Есть обычный серверный кластер для виртуальных машин. В нём куча независимых компонентов, гипервизор запускается непосредственно на железе, а хранилище конфигурируется отдельно на базе DAS, NAS или SAN. Медленные данные на HDD, горячие — на SSD. Всё привычно. Но тут возникает проблема развёртывания и администрирования этого зоопарка. Особенно весело становится в ситуациях, когда отдельные элементы системы от разных вендоров. В случае проблем стыковка тикетов для техподдержки разных производителей — своя особая атмосфера.
Есть отдельные железки, которые с точки зрения сервера выглядят как диски для записи.
И есть гиперконвергентные системы. В них вам выдают универсальный юнит, который берёт на себя всю головную боль по взаимодействию сети, дисков, процессоров, памяти и тех виртуальных машин, которые на них крутятся. Все данные стекаются в одну панель управления, и при необходимости можно просто добавить ещё пару юнитов для компенсации выросшей нагрузки. Администрирование очень сильно упрощается и стандартизируется.
VMware vSAN как раз и относится к решениям, на базе которых развёртывается
гиперконвергентная инфраструктура. Ключевой фишкой продукта является тесная интеграция с платформой виртуализации VMware vSphere, являющейся лидером среди решений по виртуализации, что позволяет развёртывать на серверах виртуализации программное хранилище для виртуальных машин за считаные минуты. vSAN непосредственно берёт на себя управление операциями ввода/вывода на низком уровне, оптимально распределяя нагрузку, занимается кэшированием операций чтения/записи и делает ещё кучу вещей с минимальной нагрузкой на память и процессор. Прозрачность работы системы несколько снижается, но в результате всё работает, что называется, automagically vSAN можно сконфигурировать как гибридное хранилище и в виде all-flash-варианта. Масштабируется как горизонтально добавлением новых узлов в кластер, так и вертикально, увеличивая количество дисков в отдельных узлах. Управление с помощью их же веб-клиента vSphere очень удобное за счёт тесной интеграции с другими продуктами.
Мы остановились на чистой all-flash конфигурации, которая по расчётам должна быть оптимальной по соотношению цены и производительности. Понятно, что суммарная ёмкость несколько ниже в сравнении с гибридной конфигурацией, использующей магнитные диски, но тут мы решили проверить, как это частично можно обойти, используя erasure coding, а также дедупликацию и компрессию на лету. В итоге эффективность хранения становится ближе к гибридным решениям, но существенно быстрее при минимальном оверхеде.
Как тестировали
Для тестирования производительности использовалось ПО HCIBench v1.6.6, которое автоматизирует процесс создания множества виртуальных машин и последующее сведение результатов. Само тестирование производительности выполняется средствами ПО Vdbench — одного из наиболее популярных ПО для синтетического нагрузочного тестирования. Железо было в следующих вариантах конфигурации:
Для каждой конфигурации выполнялся одинаковый набор тестов со следующими профилями нагрузки:
В целом система показала себя очень неплохо. По результатам тестирования мы поняли, что можем рассчитывать на показатели в районе 20 тысяч IOPS на узел. Для рядовых и высоконагруженных задач это хорошие показатели с учётом задержек в 5 мс. Ниже я привёл графики с результатами:
Итоговая таблица с результатами тестирования: 
Зелёным цветом отмечены активные данные, полностью попадающие в кэш.
Отказоустойчивость
Я вырубал один узел за другим, несмотря на возмущение машины, и смотрел на реакцию системы в целом. После отключения первого узла вообще ничего не произошло, кроме небольшого падения производительности, примерно на 10–15%. Потушил второй узел — часть виртуальных машин отключилась, но остальные продолжили работу с небольшой деградацией производительности. В целом живучесть порадовала. Перезапустили все узлы — система чуть задумалась и снова синхронизировалась без каких-либо проблем, все виртуальные машины запустились без каких-либо проблем. Как в своё время на NUC’ах. Целостность данных тоже не пострадала, что очень порадовало.
Общие впечатления
Программно-определяемые системы хранения данных (SDS) уже вполне зрелая технология.
Сегодня один из ключевых стоп-факторов, стоящих на пути внедрения vSAN, — это достаточно высокая стоимость лицензии в рублях. Если вы создаёте инфраструктуру с нуля, может получиться, что традиционная система хранения данных в сходной конфигурации будет стоить примерно столько же. Но при этом будет менее гибкой как с точки зрения администрирования, так и масштабирования. Так что сегодня при выборе решения для хранения данных виртуальных машин на платформе виртуализации vSphere стоит очень хорошо взвесить все плюсы и минусы использования традиционных решений и внедрения технологии программного-определяемого хранения.
Можно собрать решение на том же Ceph или GlusterFS, но при работе с инфраструктурой VMware подкупает тесная интеграция vSAN с отдельными компонентами, а также простота администрирования, развёртывания и заметно большая производительность, особенно на небольшом количестве узлов. Поэтому если вы уже работаете на инфраструктуре VMware, то вам будет гораздо проще с развёртыванием. Вы реально делаете десяток кликов и получаете работающую SDS из коробки.
Другой мотивацией к развёртыванию именно vSAN может быть использование её для филиалов, которое позволяет зеркалить узлы в удалённых подразделениях с witness хостом в дата-центре. Такая конфигурация позволяет получить отказоустойчивое хранилище для виртуальных машин со всеми технологиями и производительностью vSAN всего на двух узлах. Кстати, для использования vSAN есть отдельная схема лицензирования по количеству виртуальных машин, что позволяет сократить затраты в сравнении с традиционной схемой лицензирования vSAN по процессорам.
Архитектурно решение требует 10 Gb Ethernet с двумя линками на узел для адекватного распределения трафика при использовании all-flash решения. В сравнении с традиционными системами вы экономите место в стойке, экономите на SAN-сети за счёт отказа от Fibre Channel в пользу более универсального стандарта Ethernet. Для обеспечения fault tolerance требуется минимум три узла, на двух будут храниться реплики объектов с данными, а на третьем — witness объекты для этих данных, решает проблему сплитбрейна.
Теперь несколько вопросов к вам:
UPD: Совсем забыли написать конфигурацию стенда и параметры нагрузки:
1. Описание железа. Например:
Сервера – 4xDellR630, в каждом:
• 2xE5-2680v4
• 128GB RAM
• 2x10GbE
• 2x1GbE for management/VM Network
• Dell HBA330
Storage Config #1:
2xPM1725 800GB
6xToshiba HK4E 1.6TB
Storage Config #2:
1xPM1725 800GB
6xToshiba HK4E 1.6TB
2. Описание версий ПО:
vSphere 6.5U1 (7967591) (vSAN 6.6.1), т.е. патчи после Meltdown/Spectre
vCenter 6.5U1g
Latest supported drivers and FW by vSAN and ESXi for all components
LACP for vSAN and vMotion traffic (with NIOC shares/limits/reservation enabled)
All other setting are default
3. Параметры нагрузки:
• HCIBench 1.6.6
• Oracle Vdbench — 5.04.06
• 40VM per cluster (10 per node)
• 10 vmdk per VM
• 10GB size of vmdk and 100/50/25% Workload set percentage
• Warmup time-1800sec (0.5 hour), Test time 3600 (1 hour)
• 1 Threads per vmdk
vSAN в облаке на базе VMware
Задачи хранения и доступа к данным являются болевой точкой для любой информационной системы. Даже у хорошо спроектированной системы хранения данных (далее СХД) в процессе эксплуатации выявляются проблемы, связанные со снижением производительности. Отдельного внимания заслуживает комплекс проблем масштабирования, когда количество задействованных ресурсов приближается к установленным лимитам, заложенным разработчиками СХД.
Фундаментальной причиной возникновения этих проблем является традиционная архитектура, основанная на жесткой привязке к аппаратным характеристикам используемых устройств хранения данных. Большинство клиентов до сих пор выбирают способ хранения и доступа к данным с учетом характеристик физических интерфейсов (SAS / SATA / SCSI), а не реальных потребностей используемых приложений.
Еще десяток лет назад это было логичным решением. Системные администраторы тщательно выбирали накопители информации с требуемой спецификацией, например SATA/SAS, и рассчитывали на получение уровня производительности, исходя из аппаратных возможностей дисковых контроллеров. Борьба шла и за объемы кэшей RAID-контроллеров и за опции, предотвращающие потерю данных. Сейчас такой подход к решению проблемы не является оптимальным.
В текущих условиях при выборе СХД имеет смысл отталкиваться не от физических интерфейсов, а от производительности, выраженной в IOPS (количество операций ввода-вывода в секунду). Использование виртуализации позволяет гибко использовать существующие аппаратные ресурсы и гарантировать требуемый уровень производительности. Мы со своей стороны готовы предоставить ресурсы с теми характеристиками, которые реально необходимы приложению.
Виртуализация СХД
С развитием систем виртуализации требовалось найти инновационное решение для хранения и доступа к данным, одновременно обеспечивая отказоустойчивость. Это стало отправной точкой для создания SDS (Software-Defined Storage). Чтобы удовлетворять бизнес-потребностям, такие хранилища проектировались с разделением программного и аппаратного обеспечения.
Архитектура SDS в корне отличается от традиционной. Логика хранения стала абстрагироваться на программном уровне. Организация хранения стала проще за счет унификации и виртуализации каждого из компонентов такой системы.
Что же является основным фактором, препятствующим внедрению SDS повсеместно? Этим фактором чаще всего оказывается некорректная оценка потребностей используемых приложений и неверная оценка рисков. Для бизнеса выбор решения зависит от затрат на внедрение, исходя из текущих потребляемых ресурсов. Мало кто думает — что будет, когда объем информации и требуемая производительность превысит возможности выбранной архитектуры. Мышление на базе методологического принципа «не следует множить сущее без необходимости», более известного как «лезвие Оккама», обуславливает выбор в пользу традиционных решений.
Лишь немногие понимают, что необходимость в масштабировании и надежности хранения данных важнее, чем кажется на первый взгляд. Информация это ресурс, а следовательно, риск ее потери необходимо страховать. Что будет, когда традиционная СХД выйдет из строя? Потребуется воспользоваться гарантией либо купить новое оборудование. А если СХД снята с производства или у нее закончился «срок жизни» (так называемый EOL — End-of-Life)? Это может стать «черным днем» для любой организации, которая не сможет продолжать использовать привычные собственные сервисы.
Не существует систем, которые бы не имели ни одной точки отказа. Зато есть системы, которые способны без проблем пережить отказ одного или нескольких компонентов. И виртуальные, и традиционные СХД создавались с учетом того, что рано или поздно произойдет сбой. Вот только «лимит прочности» традиционных СХД заложен аппаратно, а вот в виртуальных СХД он определяется в программном слое.
Интеграция
Кардинальные перемены в IT-инфраструктуре всегда нежелательное явление, чреватое простоями и потерей средств. Только плавное внедрение новых решений дает возможность избежать негативных последствий и улучшить работу сервисов. Именно поэтому Selectel разработал и запустил облако на базе VMware, признанного лидера на рынке систем виртуализации. Созданная нами услуга позволит каждой компании решить весь комплекс инфраструктурных задач, в том числе и по хранению данных.
Расскажем о том, как именно мы решили вопрос с выбором системы хранения данных, а также какие преимущества дал нам этот выбор. Разумеется, что рассматривались как традиционные системы хранения данных, так и SDS. Чтобы четко понимать все аспекты эксплуатации и риски, предлагаем детально углубиться в тему.
Еще на этапе проектирования к СХД предъявлялись следующие требования:
На рынке SDS присутствует несколько программных решений, которые бы подошли нам для построения облака на базе VMware vSphere. Среди этих решений можно отметить:
Архитектура
В отличие от традиционных СХД вся информация не хранится в какой-то одной точке. Данные виртуальных машин равномерно «размазаны» между всеми хостами, а масштабирование осуществляется добавлением хостов или установкой на них дополнительных дисковых накопителей. Поддерживается два варианта конфигурации:
Традиционная трехуровневая сетевая модель (ядро / агрегация / доступ) имеет ряд существенных недостатков. Ярким примером являются ограничения Spanning-Tree протоколов.
В модели Spine-Leaf используется только два уровня, что дает следующие преимущества:
Физическое соединение обеспечивается с помощью нескольких 10GbE-линков на каждый сервер, пропускная способность которых объединяется с помощью протокола агрегации. Таким образом, каждый физический хост получает высокую скорость доступа ко всем объектам хранилища.
Обмен данными реализуется с помощью проприетарного протокола, созданного VMware, позволяющего обеспечить быструю и надежную работу сети хранения на Ethernet-транспорте (от 10GbE и выше).
Переход к объектной модели хранения данных позволил гибко подстраивать использование хранилища в соответствие с требованиями заказчиков. Все данные хранятся в виде объектов, которые определенным образом распределяются по хостам кластера. Уточним значения некоторых параметров, которыми можно управлять.
Отказоустойчивость
a. Mirroring (зеркалирование).
Представляет собой полное дублирование объекта, причем реплики всегда находятся на разных физических хостах. Ближайшим аналогом такого метода является RAID-1. Его использование позволяет кластеру штатно обработать до трех отказов любых компонентов (диски, хосты, потеря сети и прочее). Этот параметр настраивается посредством задания опции FTT.
По-умолчанию эта опция имеет значение 1, при этом для объекта создается 1 реплика (всего 2 экземпляра на разных хостах). При увеличении значения, количество экземпляров будет составлять N+1. Таким образом, при максимальном значении FTT=3 на разных хостах будут находиться 4 экземпляра объекта.
Такой метод позволяет достичь максимальной производительности в ущерб эффективности использования дискового пространства. Допускается использование как в гибридной, так и в AllFlash-конфигурации.
b. Erasure Coding (аналог RAID 5/6).
Изображение взято из блога cormachogan.com
Работа данного метода поддерживается исключительно на 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? Добро пожаловать в комментарии.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
VMware Virtual SAN
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 и пополнил линейку гиперконвергентных продуктов компании.
Описание
Архитектура
Архитектура, объединенная с гипервизором: компонент Virtual SAN встроен в ядро vSphere, что обеспечивает оптимизацию ввода-вывода и высочайший уровень производительности при минимальной нагрузке на ЦП.
Возможности архитектуры
Гибридная архитектура или архитектура, содержащая только флэш-накопители: Virtual SAN можно развернуть в качестве архитектуры, содержащей только флэш-накопители, где подключенная к серверу флэш-память используется и для кэширования, и для обеспечения устойчивости данных, предоставляя чрезвычайно высокий и стабильный уровень производительности. Кроме того, Virtual SAN может использоваться в качестве гибридного хранилища, в котором флэш-накопители на стороне серверов объединяются в пулы и выступают в роли кэша чтения/записи, а подключенные к серверу жесткие диски обеспечивают устойчивость данных.
Тип управления
Управление, основанное на политиках и ориентированное на ВМ: требования к хранилищу привязываются к индивидуальным виртуальным машинам или виртуальным дискам в виде политик хранения. Virtual SAN использует эти политики хранения для автоматизации выделения ресурсов и их балансировки. Таким образом, каждая виртуальная машина получает те ресурсы,которые были ей назначены.Управление с помощью единой консоли vSphere:Virtual SAN устраняет необходимость в обучении работе со специализированными интерфейсами хранилищ или в связанных с их использованием расходах. Инициализация теперь запускается двумя нажатиями кнопки.
Тип кеширования
Кэширование операций чтения и записи на стороне сервера:Virtual SAN сокращает время ожидания за счет ускорения операций ввода-вывода чтения и записи диска с помощью встроенного кэширования на основе использования флэш-накопителей на стороне сервера.
Возможности масштабирования
Гибкое горизонтальное и вертикальное масштабирование [4] без нарушения работы: увеличение емкости и повышение производительности хранилища данных Virtual SAN без прерывания рабочих процессов путем добавления узлов в кластер (горизонтальное масштабирование) или дисков в узел (вертикальное масштабирование).
Отказоустойчивость
Встроенная отказоустойчивость: Virtual SAN эффективно использует распределенные RAID-массивы и зеркалирование кэша для защиты от потерь данных в случае сбоя диска, узла,сети или стойки.Снимки и клоны Virtual SAN: новый дисковый форматVirtual SAN обеспечивает чрезвычайно эффективное создание масштабируемых снимков и клонов ВМ. Для одной ВМ поддерживается до 32 снимков и клонов.
Лояльность к оборудованию
Независимость от оборудования: компонент Virtual SANможет быть развернут на оборудовании любых поставщиков серверных решений. Это обеспечивает гибкость при формировании специализированных систем хранения в разнородных аппаратных средах.
Совместимость с другими продуктами
Взаимная совместимость с продуктами VMware: VirtualSAN эффективно использует компоненты VMware vSphereData Protection™ и vSphere Replication™ для защиты данных, резервного копирования, репликации и аварийного восстановления. Компонент Virtual SAN совместим с vRealizeAutomation и может быть установлен в сочетании с VMware®Horizon View™ в VDI-средах и с vCenter Site Recovery Manager в средах аварийного восстановления.
Концепция vSAN
Концепция vSAN заключается в том, что на каждом хосте ESXi может быть от 1 до 5 дисковых групп, которые в свою очередь содержат [Источник 2] :
vSAN предоставляет два метода обеспечения отказоустойчивости:
vSAN позволяет по-разному обеспечивать отказоустойчивость для различных ВМ или их дисков: в рамках одного хранилища можно для критичных к производительности ВМ привязать политику с зеркалированием, а для менее критичных ВМ — настроить Erasure Coding.
Для организации Virtual SAN можно использовать:
Решаемые задачи
Пример работы
Поскольку возможности 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):
Преимущества и недостатки vSAN
Преимущества
Сравнивая vSAN с традиционными внешними СХД следует отметить, что: [Источник 3]
Недостатки
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 того же кластера.
Важная особенность VSAN в том, что доступ к данным штатным образом осуществлятся через 10G сеть. Данные пишутся и читаются через сеть и коммутатор в нормальном, рабочем режиме (а не только при нештатной недоступности данных локально, как у Nutanix), что может вести к повышенному времени задержек и перегрузке «межнодовой» 10G-магистрали, а также меньшей надежности.
Проектирование VSAN
Относительная простота развертывания отнюдь не отменяет тщательного проектирования архитектуры VSAN. Вот несколько моментов, на которых стоит остановиться подробнее: [Источник 5]
При работающем решении уже нельзя будет на лету добавить дискового пространства под VSAN (storage node), не добавив при этом нового сервера, а значит процессоров и памяти. Вариант, когда сервер используется только в качестве хранилища (т. е. вычислительный узел этого сервера простаивает), возможен, но экономически невыгоден: фактически это возврат к традиционной конфигурации и отказ от преимуществ конвергентного решения.