Привет, Хабр! Меня зовут Даниил Киселёв, я специалист по техническому сопровождению Space. В этой статье я на практическом примере покажу, как в SpaceVM собрать программно-определяемое кластерное хранилище. Рассмотрим типовую конфигурацию, учитывая, что в реальном продакшене параметры и архитектурные решения могут отличаться.
Бизнес ожидает от СХД простых характеристик — чтобы данные были доступны всегда, а сбои и обслуживание не останавливали работу виртуальных машин и сервисов. Именно поэтому программно-определяемые хранилища становятся распространенным инструментом. На примере SpaceVM разбираем, как за считанные минуты собрать отказоустойчивое кластерное SDS, которое решает сразу несколько ключевых задач: снижает стоимость владения и обеспечивает стабильную работу в реальных условиях эксплуатации.
Вопрос о том, зачем вообще нужны программно-определяемые хранилища не лишен смысла. Объемы данных, которые приходится хранить бизнесам, постоянно растут, емкость хранилищ приходится постоянно наращивать, а многим компаниям приходится, к тому же, еще и обеспечивать соответствие требованиям регуляторов. Но стоимость аппаратных СХД и объем инвестиций в них перевешивают – и компании задумываются о переходе на SDS.
Они не только дешевле в принципе – экономия становится еще заметнее, если приходится иметь дело с неструктурированными данными. Есть и другие преимущества: можно абстрагироваться от аппаратной платформы и успешно побороть пресловутый vendor-lock. (это особенно важно в России), компании куда проще обеспечить независимость от вендорских санкций.
Программно-определяемые хранилища перестают быть экспериментальным решением в тот момент, когда инфраструктура выходит за рамки одного сервера или одной задачи. Рост числа виртуальных машин, регулярное расширение дисковой емкости и требования к высокой доступности данных быстро делают классическую СХД узким местом. В этот момент выбор SDS становится не вопросом технологий, а способом сохранить управляемость и предсказуемость инфраструктуры.
Наиболее заметно преимущества SDS проявляются в прикладных сценариях, с которыми сталкивается большинство компаний. Виртуализация «1С», CRM и биллинговых систем требует отказоустойчивости без кратного роста стоимости. VDI и удаленные рабочие места чувствительны к задержкам и неравномерной нагрузке. Файловые хранилища с неструктурированными данными плохо масштабируются в рамках монолитных массивов. Во всех этих случаях традиционные СХД начинают ограничивать развитие сервисов, а не поддерживать его.
Сложность заключается в том, что в разных виртуальных средах создание и управление SDS осуществляется тоже по-разному. О том, как решается эта задача на платформе SpaceVM, расскажем далее. При этом сфокусируемся на создании кластерного хранилища, которые становятся все более популярны благодаря своим надежности, простой масштабируемости и управлению.
Готовим сеть
Кластерное программно-определяемое хранилище в SpaceVM строится по многоуровневой архитектуре, в которой вычисления, сеть и хранение логически разделены, но управляются из единого контура.
На нижнем уровне располагаются физические серверы с локальными дисками, объединенными в RAID-массивы. Выше находится слой SDS на базе GlusterFS, который отвечает за агрегацию дискового пространства, репликацию данных и отказоустойчивость. Гипервизор SpaceVM использует этот слой как общее хранилище для образов дисков qcow2 виртуальных машин, абстрагируясь от конкретного оборудования.
На уровне каждого узла SpaceVM использует ZFS для управления локальными дисками и формирования разделов (бриков). Поверх ZFS-пулов строится кластерный слой SDS на базе GlusterFS, который отвечает за репликацию данных и их распределение между серверами. Такое разделение позволяет независимо управлять локальной надежностью хранения и кластерной отказоустойчивостью.
С точки зрения потоков данных виртуальная машина работает с единым логическим томом, тогда как внутри кластера операции записи и чтения распределяются между узлами с учетом выбранного типа тома и уровня репликации. Такое разделение позволяет масштабировать хранилище и вычислительные ресурсы независимо, устранять единичные точки отказа и обслуживать отдельные узлы без остановки сервисов. Именно поэтому корректная настройка сети и понимание архитектуры кластера становятся ключевыми факторами стабильной работы SDS.
Начинаем, конечно, с того, что вводим в панели администратора название сети (назовем ее для простоты Gluster), даем ее описание и, если требуется, указываем адрес подсети. Затем выбираем необходимый сервер и интерфейс, через который будет работать кластерный транспорт, - в нашем случае это будет 10 Гбит. В демонстрации используется сеть 10 Гбит; в реальных инсталляциях допустимы иные параметры, если они соответствуют требованиям по пропускной способности и задержкам.
Использование интерфейсов 10 Гбит для кластерного транспорта обусловлено не «запасом на будущее», а реальными нагрузками SDS. При активной записи и репликации данных сеть 1 Гбит быстро становится узким местом, что приводит к росту латентности и деградации производительности виртуальных машин. В кластере из нескольких узлов такие ограничения усиливаются, поэтому 10 Гбит рассматривается как базовый уровень для стабильной работы программно-определяемого хранилища.
Здесь же есть возможность агрегированный интерфейс. Нам потребуется еще создать внутренний интерфейс на каждом из серверов – у нас их будет три, для каждого будет актуальна та же самая процедура.
Затем проверяем настройки сети, при необходимости вводим тег VLAN и меняем MTU. Настройки MTU и VLAN оказывают заметное влияние на работу кластера. Использование увеличенного MTU позволяет сократить накладные расходы при передаче больших объемов данных, однако требует единообразной настройки на всех узлах и сетевом оборудовании.
Некорректные или неоднородные параметры сети могут приводить к трудно диагностируемым ошибкам, которые внешне проявляются как проблемы хранилища.
Далее, можно добавить резервированные пулы адресов. И после этого запускаем процесс создания сети.
После того, как она создана, нужно создать кластерный транспорт.
Для этого нужно зайти в кластерные хранилища, ввести в них название кластерного транспорта, задаем для него описание и выбираем созданную нами внешнюю сеть. Это нужно для того, чтобы трафик проходил именно через нее.
Подготовка хранилищ на узлах
Следующий шаг – подготовка хранилищ на узлах созданной сети. Для этого нам надо сформировать массивы RAID на каждом из серверов. Выбираем тип RAID: доступны stripe, mirror, RAIDZ1 и RAIDZ2 — это реализации отказоустойчивых схем хранения на уровне ZFS, функционально сопоставимые с RAID5 и RAID6, но реализованные с учетом архитектуры файловой системы. Тип RAID на узлах следует выбирать с учетом профиля нагрузки и логики работы SDS.
Зеркальные конфигурации обеспечивают минимальные задержки и предсказуемую производительность, тогда как схемы с контролем четности позволяют эффективнее использовать емкость. Важно учитывать, что локальный RAID не заменяет кластерную репликацию, а дополняет ее, снижая вероятность потери данных и ускоряя восстановление при отказах.
Можно собрать RAID из подключенных LUN, расположенных на внешнем хранилище iSCSI или FC. Для каждого массива вводится название и, опционально, описание. Эта процедура повторяется на каждом из серверов.
У каждого из серверов нам доступен просмотр статуса, монтаж и демонтаж дисков, выключение устройства для обслуживания. Можно также получить расширенные сведения ZFS тома, добавить устройства для горячей замены и расширить пулы в случае добавления дисков.
Создание SDS-тома
Следующий этап – создание программно-определяемого тома. Для этого в интерфейсе управления есть отдельный раздел. В нем выбираем функцию создания, определяем тип тома, реплицированный или дисперсный. Первый потребуется для обеспечения отказоустойчивости и надежности, второй позволяет объединять RAID различного размера, а кроме того, может обеспечивать более высокую производительность в ряде сценариев, в зависимости от профиля нагрузки и конфигурации кластера.
В нашем случае выберем реплицированный том, затем транспорт, через который будет работать том и пулы хранилищ из числа созданных на предыдущем этапе. В рамках демонстрационного кластера мы используем реплицированный том как наиболее универсальный вариант.
Кроме того, нужно выбрать размер записи, указать значение репликации тома (оно равно количеству томов).
Опционально можно указать использование арбитра — логического компонента, который не хранит пользовательские данные, а используется для обеспечения кворума и предотвращения split-brain-сценариев при отказе одного из узлов кластера.
SpaceVM позволяет создать пул данных автоматически – статус выполнения задания можно отследить в нижней части интерфейса.
Проверка пула данных
После того, как SDS-тома созданы, можно для каждого из них посмотреть, к каким серверам он смонтирован, проверить их доступность и активность. После создания тома стоит проверить через пул данных его корректность и объем.
Проверить надо и кластерный транспорт. На соответствующей вкладке можно видеть, что он подключен ко всем серверам, получить расширенные сведения о состоянии транспорта.
Проверка работоспособности
Затем, конечно, нужно проверить созданный SDS в работе.
Для этого нужно в соответствующем разделе выбрать виртуальную машину и перенести ее на созданный том. В ручном режиме выбираем пул ресурсов для миграции, режим с переносом локальных дисков, сеть, к которой будет подключена виртуальная машина и запускаем процесс миграции.
Миграция при этом происходит бесшовно, она продолжает работать во время переноса.
Отказоустойчивость
В такой конфигурации отказоустойчивость обеспечивается на двух уровнях: за счет локальных RAID-массивов на каждом сервере и за счет кластерной репликации данных между узлами. Это позволяет переживать отказ отдельных дисков или одного сервера без потери данных и остановки сервисов при соблюдении требований к кворуму кластера.
Как видим, процесс создания SDS-хранилища в среде SpaceVM укладывается в типовой рабочий сценарий администратора. Все основные операции выполняются через интерфейс управления и не требуют ручной настройки на уровне CLI. В демонстрационной конфигурации развертывание занимает минимальное время, тогда как в продакшене сроки и параметры могут варьироваться в зависимости от архитектуры, оборудования и требований к отказоустойчивости.
