Но прежде чем приступить к обсуждению данной технологии, предлагаю расставить все точки над i в терминологии и немного поговорить об истории развития подходов к построению инфраструктуры от классической трехуровневой архитектуры до гиперконвергентных систем.
Подходы к построению инфраструктуры
Классической на данный момент можно считать инфраструктуру, состоящую из трех компонентов:
- вычислительные мощности (серверы);
- системы хранения данных;
- сеть хранения данных.
Подобный ландшафт прочно укоренился как стандарт в центрах обработки данных и корпоративных развертываниях разного масштаба. Схема проверена временем, но не лишена очевидных недостатков:
- Каждый элемент структуры требует соответствующей компетенции для внедрения и поддержки.
- Интеграция данных решений усложняется по тем же причинам и увеличивает время, после которого вы получите готовый к использованию продукт.
- Масштабирование подобных систем также усложняется за счет различных интерфейсов управления и необходимости комплексно подходить к расширению того или иного модуля.
Понятие конвергенции сводится к простой идее: консолидация ролей для решения различных задач в рамках единой структуры. Этот подход зародился еще в середине прошлого века в средах передачи данных, объединив в рамках одних линий связи передачу разных типов трафика.
Вендоры по-своему трактуют данное понятие, обычно закладывая в него те или иные сильные стороны своих продуктов, но смысл от этого не меняется: конвергентный подход (интегрированный – по версии Gartner) к инфраструктуре нацелен на минимизацию издержек во внедрении, обслуживании и скорости развертывания путем объединения ролей в рамках единой системы, которая управляется из единого интерфейса.
Один из представителей вышеописанного подхода – Cisco UCS, совмещающий в рамках единого решения доступ как к вычислительным мощностям, так и к системе хранения с обслуживающей сетью. Управление решением осуществляется из единого Cisco UCS Manager, который дает возможность настроить любой модуль в системе – от сети до серверных профилей, которые позволяют в считанные секунды настроить новые серверы. В плане масштабируемости подобные системы не так гибки, как классическая инфраструктура, но по простоте наращивания тех или иных ресурсов сравнивать их нельзя. Если вы достигли предела производительности СХД в рамках всего шасси, можно увеличить ресурс, подключив к фабрике еще одно решение. В кратчайшие сроки вы получите готовый для работы продукт, управляемый все из того же менеджера. Это делает подобные системы крайне удобными в обслуживании, масштабировании и внедрении, а также дает большую гибкость в выделении ресурсов и плотность вычислительных мощностей.
Отличия конвергентной структуры от гиперконвергентной (HCI) в том, что первая собрана вендором, преднастроена и совмещает в себе все необходимые компоненты для развертывания служб и управления. В гиперконвергентной же структуре средствами программного обеспечения система собирается из различных блоков, в роли которых часто выступают классические стоечные серверы. Подход HCI базируется на идее Software-defined datacenter (SDDC), где все компоненты классической архитектуры виртуализированы и предоставляются «как сервис». Это дает колоссальные возможности в гибкости настройки, удобстве масштабирования и управлении системой в целом.
На практике данный подход, на примере продуктов VMware, выглядит следующим образом:
То есть берется необходимое под проект количество серверов, на которые устанавливаются гипервизоры, настраиваются программные хранилища и разворачиваются средства оркестрации.
Технология vSAN
Одним из лидеров в области предоставления программного обеспечения для создания гиперконвергентных программноопределяемых ЦОД являет компания VMware, а vSAN дополнил корзину продуктов компании в части software-defined storage. vSAN полностью интегрирован в гипервизор VSphere, не требует сторонних средств для развертывания и позволяет превратить стоечные серверы различной модификации в единый центр обработки данных без необходимости использования отдельных СХД или построения сети передачи данных.
Простыми словами: vSAN создает из локальных дисков различных серверов X86 единый datastore на весь кластер VSphere, доступный всем участникам (хостам) объединенной системы, а также обеспечивает отказоустойчивость решения.
С помощью vSAN на серверах создаются от 1 до 5 дисковых групп на сервер, которые включают в себя один обязательный SSD на группу для кеширования (cache tier) и до 7 дисков под данные (capacity tier). Дисковые группы на разных хостах виртуализации собираются в единое распределенное на весь кластер хранилище. Начиная с версии 6.0 также поддерживается All-flash-реализация.
Развернув кластер vSphere с технологией vSAN, мы получаем гибкую, отлично масштабируемую и достаточно простую в настройке и обслуживании систему, администрирование которой происходит из единого интерфейса. За управление vSAN отвечает компонент Storage Policy Based Management, в котором создаются политики, определяющие уровень отказоустойчивости и производительности. Политики мы можем применить точечно для каждой ВМ, определив необходимый уровень распространения данных по кластеру.
Накопители отдаются контроллером в режиме passthrough, без необходимости создания raid-массива. Конечно, никто не запретит развернуть систему и добавить, к примеру, raid-10 как capacity-диск в дисковую группу, но тогда попросту теряется часть накопителей, так как отказоустойчивость и логика повышения производительности системы хранения заложены в механизмы vSAN. Кроме того, есть риск потерять поддержку со стороны VMware.
Отказоустойчивость в vSAN строится по следующему принципу: вы определяете для ВМ Number of failures to tolerate, который по умолчанию равен 1 и обозначает количество хостов, падение которых не скажется на работоспособности данной ВМ. Сам же механизм распределения данных ВМ по кластеру vSAN определяется параметром Failure tolerance method, который описывает логику обеспечения отказоустойчивости. На данный момент используются два варианта:
- Mirroring (зеркалирование) – когда данные ВМ полностью дублируются на соседних хостах кластера. Количество зеркал зависит от параметра Number of failures to tolerate. К примеру, в кластере 4 хоста и данный параметр равен 1. Это означает, что при падении одного из хостов держателей данных этой ВМ все операции IO перейдут на хост c копией и начнется процесс rebuild, который попытается вернуть единственной копии данной ВМ установленный уровень допустимых отказов, то есть попросту будет произведено зеркалирование данных на «живой» хост. Данный метод затратен в плане потребления capacity, но дает максимальный выигрыш в производительности.
- Второй метод – Erasure Coding – унаследовал логику распределения ресурсов от RAID5 и RAID6. Согласно этой логике, кластер способен на отработку 1 или 2 отказов соответственно. Так как в данной конфигурации мы выигрываем в capacity, но проигрываем в производительности, метод поддерживает только All-Flash-хранилище. Алгоритм отработки отказа аналогичен соответствующим уровням RAID и минимальному количеству накопителей в группе. То есть при наличии 4 хостов мы имеем возможность отработать 1 отказ, при наличии 6 хостов – 2. Выигрыш по capacity в данном развертывании – 1,5 и 2 раза соответственно.
Этим возможности vSAN в плане отказоустойчивости не ограничиваются. Можно объединять хосты в так называемые домены (fault domain), настраивая отказоустойчивость не просто на уровне хостов, но и на уровне целой группы, которая, к примеру, может формироваться на основе принадлежности к стойке.
Функциональность vSAN может удовлетворить любого конечного пользователя продукта – от корпоративного сегмента до облачных провайдеров. Механизмы дедупликации и сжатия позволяют серьезно сэкономить на полезном пространстве, а технология кеширования значительно повысит производительность операций ввода/вывода. Нужно учесть, что для All-Flash-решений весь cache tier отдан на запись, так как производительность твердотельных накопителей позволяет отказаться от отдельного кеша на чтение. В гибридной структуре соотношение кеша 70/30 в пользу чтения.
vSAN тесно интегрирован с гипервизором vSphere, так что нам доступны все его технологии, такие как HA, vMotion и прочие возможности, в смежной работе.
Кому могут быть интересны гиперконвергентные решения?
Беря во внимание горизонтальную концепцию масштабирования гиперконвергентных систем на основе технологий VMware и параллельного наращивания производственных мощностей и объемов хранения, самым очевидным применением vSAN видится инфраструктура виртуальных рабочих столов, VDI. Данная концепция наращивания идеально впишется в дизайн технологии, а простота масштабирования и обслуживания позволят «отдавать» услугу максимально быстро и эффективно.
Это относится и к другим сервисам в портфелях IaaS-провайдеров, где используются сходные шаблоны ВМ. Дедупликация образов и теснота интеграции с другими решениями vSphere дают огромный профит в развертывании частных облаков. За счет снижения издержек на обслуживание, внедрения и простоты масштабирования конечный пользователь может получить услугу по более выгодным ценам без потери в качестве обслуживания и производительности.
Технология может быть интересна и компаниям, имеющим у себя готовый парк серверного оборудования и столкнувшимся с необходимостью выбора СХД под те или иные задачи. С одной стороны, vSAN снизит уровень необходимой экспертизы для внедрения, упростит обслуживание и администрирование, устранит требования к сети хранения данных. Но с другой – не стоит забывать о затратах на лицензирование и необходимости использовать схожее аппаратное обеспечение, в первую очередь – компоненты дисковой подсистемы. Это не жесткое правило, можно использовать диски с разным показателем скорости вращения, но в данном случае есть риск получить нестабильность datastore, который будет синхронизировать скорость работы по самому медленному накопителю.
В заключение отметим, что гиперконвергентные системы все больше укрепляют свои позиции на рынке. Доверие к ним растет, и, по результатам аналитики IDC, рост доли HCI за этот год составит 150% по сравнению с предыдущим. Gartner пророчит 20% от общей доли решений в пользу HCI к 2020 году. Это говорит о том, что данная архитектура созрела для противостояния с классической парадигмой, выдержала проверку временем, прочно войдя в бэкграунд IaaS-провайдеров и с каждым годом укрепляя позиции идеи Software-defined datacenter, которая если и не вытеснит прочие решения, то уверенно займет свою нишу в центрах обработки данных.
