В первом посте про CloudLITE мы упомянули виртуальное хранилище VMware Virtual SAN (VSAN). Сегодня остановимся на этой технологии подробнее и расскажем, на что следует обратить внимание при создании VSAN для своего проекта.
Традиционная архитектура включает три ключевых компонента:
• серверы,
• система хранения данных (СХД),
• сеть хранения данных, которая соединяет СХД с серверами через блочные (FC, FCoE, ISCSI) или файловые протоколы (NFS, SMB) с использованием соответствующих коммутаторов.
Для управления таким хозяйством необходимы три разных интерфейса, три разных компетенции и, по-хорошему, три разных специалиста.
Развертывание такой архитектуры занимает много времени, и быстрое масштабирование здесь тоже весьма нетривиальная задача.
Если ваш проект подразумевает прогнозируемое и планомерное масштабирование, на добавление нового хранилища есть неделя, а в штате есть специалисты, которые будут заниматься проектированием, то традиционная архитектура – ваш выбор.
Когда же у вас проект (например, public cloud) растет скачками, добавление нового хранилища при минимальных возможностях автоматизации займет уйму времени. Вот тут-то и приходит на помощь конвергентная архитектура 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. Вот несколько моментов, на которых нам хотелось бы остановиться подробнее:
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), не добавив при этом нового сервера, а значит процессоров и памяти. Вариант, когда сервер используется только в качестве хранилища (т. е. вычислительный узел этого сервера простаивает), возможен, но экономически невыгоден: фактически это возврат к традиционной конфигурации и отказ от преимуществ конвергентного решения.
VSAN позволил нам получить высокую производительность, сопоставимую с mid-range СХД.
За все время эксплуатации VSAN (с сентября 2014 года) показал очень высокий уровень доступности, в том числе и в составе enterprise-решений.
С марта система работает в кластере виртуализации интернет-магазина CloudLITE.ru.
Кстати, заходите на бесплатный тест-драйв :)
Зачем вам 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), не добавив при этом нового сервера, а значит процессоров и памяти. Вариант, когда сервер используется только в качестве хранилища (т. е. вычислительный узел этого сервера простаивает), возможен, но экономически невыгоден: фактически это возврат к традиционной конфигурации и отказ от преимуществ конвергентного решения.
9 месяцев — полет нормальный
VSAN позволил нам получить высокую производительность, сопоставимую с mid-range СХД.
За все время эксплуатации VSAN (с сентября 2014 года) показал очень высокий уровень доступности, в том числе и в составе enterprise-решений.
С марта система работает в кластере виртуализации интернет-магазина CloudLITE.ru.
Кстати, заходите на бесплатный тест-драйв :)
