SpaceVM: с нуля до кластера за 15 минут

Предлагаем вашему вниманию пошаговый мануал, позволяющий за 15 минут из «чистого» инсталла получить рабочий кластер SpaceVM с общим хранилищем, сетями и ролями контроллеров. Все это — через понятный веб-интерфейс плюс пару CLI-команд там, где это действительно уместно. Поехали!

Что понадобится

Прежде чем браться за настройку, стоит определить минимальный набор ресурсов, необходимых для того, чтобы весь процесс разворачивания кластера на SpaceVM 6 занял заявленные 15 минут. Кстати, на момент публикации уже вышла новая версия платформы — SpaceVM 7. По ней мы также подготовим отдельный обзор.

Серверы

Минимум три машины. Такая конфигурация выбрана не случайно:

• Два контроллера. Они отвечают за управление кластером и хранят реплицированную базу данных. Один из них будет master, второй — slave. Такая схема нужна, чтобы обеспечить отказоустойчивость: если один контроллер «упал», второй продолжает управлять кластером.

• Еще одна машина — node. Рабочая вычислительная нода, на которой будут запускаться виртуальные машины.

При желании можно обойтись и меньшим числом серверов (например, поставить контроллер и node на одной машине), но тогда теряется весь смысл кластера и отказоустойчивости. В продакшене — всегда минимум три.

Сети

Необходимо как минимум две подсети:

• Management-сеть. Через нее происходит вся служебная коммуникация: доступ к веб-интерфейсу, взаимодействие между контроллерами, управление узлами. В примере используется подсеть 10.1.251.0/24.

• Сеть хранилища. По ней узлы кластера общаются с NAS или SAN. Для производительности ее лучше физически разделять от management-сети. В примере это подсеть 10.1.252.0/24.

Опционально добавляется еще одна или несколько сетей для виртуальных машин. Их можно строить на том же «железе», но правильнее выделять VLAN под каждую группу сервисов.

Хранилище

Общее сетевое хранилище — обязательный компонент для кластера. В нашем случае это NAS, который отдает LUN по iSCSI. На нем будет лежать файловая система GFS2, доступная одновременно всем серверам кластера. Это позволяет:

• запускать виртуалки на любом узле,

• делать live migration без остановки сервисов,

• обеспечивать единое пространство данных.

Без сетевого хранилища кластер работать не сможет: у каждого узла будут свои локальные диски, а значит, ни о какой миграции и отказоустойчивости речи быть не может.

Доступы и учетки

Для подключения серверов к кластеру нужен SSH-доступ под root. Через него SpaceVM разворачивает агента и синхронизирует настройки. Для работы с интерфейсом используется учетка admin, которая создается автоматически при установке. Ее мы используем на всех этапах первичной настройки.

Первый вход и базовая навигация

После установки SpaceVM вы получаете базовую готовую систему, для первоначального запуска которой достаточно задать IP-адрес и сетевые параметры. При этом и контроллер, и вычислительные ноды разворачиваются из одного образа, что упрощает внедрение и сокращает количество подготовительных этапов по сравнению с рядом других платформ.

Первое, что мы делаем, — заходим в веб-интерфейс под пользователем admin. Обычно это адрес контроллера, например https://10.1.251.30/. Интерфейс выглядит минималистично: слева дерево объектов (локации, кластеры, серверы, сети), справа подробности выбранного элемента.

Начинаем с «Локаций». Здесь по умолчанию висит одна площадка с названием «Default location». Чтобы не путаться в дальнейшем, особенно если инфраструктура будет расти, сразу дадим ей осмысленное название. К примеру, если разворачиваем тестовую площадку в Москве — называем просто «Москва».

Далее открываем раздел «Кластеры». Система уже создала первый пустой кластер — в нем мы и будем работать. Нажимаем «Редактировать» и меняем имя на короткое и удобное для CLI и документации. Пусть это будет SVM. В дальнейшем все операции — добавление серверов, подключение хранилищ, настройка сетей — будут происходить внутри этого кластера. Так у нас появляется понятная структура: «площадка → кластер → серверы и сервисы».

Эти простые шаги сильно экономят время в будущем: не приходится вспоминать, где находится «Default» или «Cluster1», а интерфейс сразу отражает реальную архитектуру.

Подключаем серверы

Теперь нужно завести в систему все наши физические узлы. В примере используется три сервера: два контроллера и одна node. На одном из контроллеров уже доступен веб-интерфейс, через него можно добавить остальные узлы кластера.

Открываем «Серверы» и жмем «Добавить сервер». Заполняем поля

• Имя (например, srv2 или controller-slave — выбирайте что-то по роли узла, а не по случайному принципу).

• IP-адрес сервера (в management-сети, в нашем примере — 10.1.251.31).

• Пользователь: root.

• Порт: 22 (SSH).

• Пароль root-пользователя.

Нажимаем «Проверить соединение». Если все хорошо, система подключается по SSH и автоматически синхронизирует информацию о сервере. Повторяем процедуру для всех машин.

Через несколько секунд в списке серверов вы увидите ресурсы: количество ядер, доступную память, состояние (например, «Исправен»). При этом система сразу создает «Пул ресурсов» с нашими тремя серверами. Это значит, что при создании виртуальных машин мы можем выбрать конкретный сервер или отдать управление планировщику.

Есть нюанс: если раньше на этих серверах оставались ISO-образы или виртуальные диски, то после добавления они могут не отобразиться. Чтобы вернуть их в каталог, достаточно выделить сервер и нажать «Сканировать». После этого все локальные ресурсы снова станут доступны в интерфейсе.

Сети: внешний доступ к NAS и сеть для ВМ

Для работы кластера нам нужны минимум две сети: одна для управления (management), вторая — для трафика к хранилищу. В дальнейшем добавим еще сеть для виртуальных машин. В нашем примере на каждом сервере два физических интерфейса:

• ens2 — уже используется как management (10.1.251.0/24).

• ens1 — свободный, отдан под NAS (10.1.252.0/24).

Внешняя сеть для NAS

Заходим в «Внешние сети → Создать». Даем имя, например NAS. Указываем подсеть 10.1.252.0/24. Добавляем все три сервера в эту сеть.

Для каждого выбираем физический интерфейс eno1 и задаем IP-адреса:

• 10.1.252.100 для master-контроллера,

• 10.1.252.101 для slave-контроллера,

• 10.1.252.102 для node.

Если используется VLAN (в примере это VLAN 2), то прописываем его прямо здесь. После сохранения сеть сразу поднимается, и в свойствах можно проверить, что все серверы видят друг друга по новой подсети.

Виртуальная сеть для ВМ

Теперь создаем сеть, к которой будут подключаться виртуальные машины. Переходим в «Виртуальные сети → Создать». Придумываем имя (например, vm-net), указываем VLAN (в нашем случае — 191) и добавляем все сервера. Виртуальная сеть не требует ручной настройки IP на хостах — система сама создает виртуальный свитч.

Если в кластере нет отдельной внешней сети для доступа ВМ, можно использовать дефолтный виртуальный коммутатор default. Он уже висит на интерфейсе ens2 (той самой management-сети) и создается системой автоматически. Но лучше сразу разделять сервисные сети и сетевой трафик виртуалок.

Итого: у нас есть management-сеть, отдельная сеть для доступа к NAS и виртуальная сеть для будущих машин. В дальнейшем именно на этих сетях будут строиться кластерные транспорты и храниться диски.

Назначение ролей контроллеров

Теперь, когда транспорт создан, нужно распределить роли между контроллерами. В SpaceVM всегда есть один master-контроллер и один или несколько slave-контроллеров.

• Master — основной, через него мы управляем кластером в веб-интерфейсе и CLI. На нем хранится «главная» копия базы данных конфигурации.

• Slave — дублирует данные и может автоматически принять управление, если master перестанет отвечать.

Сделать это можно через CLI.

На master-контроллере

Подключаем slave к кластеру:

controller add <IP-slave>

Система запросит пароль root от slave-контроллера и установит доверие между узлами.

Дальше назначаем текущий сервер master-ролей:

controller role master

На slave-контроллере

Делаем симметричный шаг:

controller add <IP-master>

Опять вводим root-пароль — теперь slave «знает» про master.

Назначаем этому серверу роль:

controller role slave

Проверка статуса

На master-контроллере выполняем:

controller status

В ответ получаем список известных контроллеров и их роли. Если все сделано правильно:

• master отображается как «active»;

• slave виден в состоянии «connected»;

• репликация базы данных включена.

Важно понимать, что при смене роли интерфейс контроллера может кратковременно перезапускаться. Это нормально: кластер пересобирает связи и перезапускает сервисы, чтобы зафиксировать новое состояние.

Подключение сетевого хранилища

Следующий шаг после настройки транспорта и ролей контроллеров — подключить общее хранилище. Именно оно станет тем местом, где будут лежать образы дисков виртуальных машин и куда получат равноправный доступ все узлы кластера.

В нашем сценарии используется NAS, который отдает блочные устройства по протоколу iSCSI. SpaceVM поддерживает и другие варианты (NFS, Ceph и т.д.), но iSCSI — самый прямой путь, если у вас уже есть сетевое хранилище.

Делаем так:

1.      Заходим в раздел «Сетевые хранилища → Блочные».

2.      Нажимаем «Добавить».

3.      В форме указываем:

o    имя (например, iscsi-nas),

o    тип — iSCSI,

o    список серверов, которые будут подключаться (в нашем случае все три),

o    IP-адрес NAS (например, 10.1.252.251).

4.      Жмем «Получить доступный target». Система опрашивает NAS и показывает список доступных target’ов. Обычно это ровно тот, что вы подготовили под кластер.

5.      Сохраняем настройки.

После сохранения в карточке хранилища появится список LUN — это блочные устройства, которые экспортирует NAS. Там же видно их размер, состояние и ID.

Если том новый, его нужно отформатировать. В интерфейсе есть опция «Форматировать» — аккуратно используем ее только на пустом LUN, потому что данные при этом будут уничтожены.

С этого момента все узлы кластера «видят» один и тот же блочный том. Это основа для дальнейшего шага — создания пула данных на общей файловой системе GFS2.

Создание пула данных

Теперь, когда у нас есть общий iSCSI-том, нужно превратить его в распределенное хранилище, которое понимают все серверы. Для этого используется файловая система GFS2 (Global File System 2).

Зачем нужен отдельный пул? Дело в том, что сами по себе LUN — это просто блочные устройства. Чтобы на них можно было создавать виртуальные диски и мигрировать их между узлами, поверх них нужно развернуть кластерную файловую систему. В SpaceVM это делается через «Пулы данных».

Пошагово:

1. Переходим в раздел «Пулы данных → Добавить пул».

2. В форме задаем:

o    имя (например, gfs2-pool),

o    тип — GFS2,

o    выбираем ранее найденный LUN.

3. Подтверждаем создание. Если кластерный транспорт еще не настроен, система дополнительно предложит выбрать сети для его работы.

SpaceVM форматирует выбранный LUN в GFS2 и монтирует его на всех серверах кластера. В результате мы получаем общее пространство, которое видно каждому узлу.

В карточке пула можно сразу проверить:

• список серверов, которые подключены к пулу,

• общий объем,

• сколько занято и сколько свободно.

С этого момента можно создавать виртуальные машины и размещать их диски в GFS2-пуле. Через веб-интерфейс SpaceVM можно загрузить ISO-образы в хранилище, создать виртуальную машину и открыть ее консоль непосредственно из интерфейса платформы. Также платформа поддерживает работу со снимками и резервным копированием виртуальных машин, что упрощает повседневное администрирование инфраструктуры.

Наличие ISO образа, подключённого к ВМ никак не влияет на процесс миграции и высокую доступность ВМ.

Ключевое преимущество здесь в том, что диск доступен сразу на всех узлах. Это означает:

• можно свободно мигрировать ВМ между серверами,

• отказ одного узла не приведет к потере доступа к данным,

• управление ресурсами становится централизованным.

Именно на этом шаге кластер SpaceVM превращается в полноценную инфраструктуру виртуализации с разделяемым хранилищем.

Финальная проверка

На этом этапе у нас есть:

— три синхронизированных сервера в общем пуле ресурсов;
— настроенные сети (внешняя к NAS и виртуальная для ВМ);
— GFS2-транспорт с кворумом;
— роли master/slave и репликация БД;
— общий GFS2-пул на iSCSI-LUN.

Можно сразу создавать первую ВМ и (когда будет что мигрировать) проверять live migration между хостами — инфраструктура к этому готова.

Итог

Весь путь — от «пустого» интерфейса до полноценного кластера — укладывается в четверть часа за счет разумных предустановок (виртуальный свитч default), минимального количества ручных шагов и прозрачной модели ролей контроллеров. Ключевые действия: добавить сервера, поднять две сети, создать GFS2-транспорт, назначить master/slave и подключить iSCSI-LUN под пул. Дальше — дело техники: шаблоны ВМ, политики и миграции.

Если нужно глубже — смотрите официальный гайд по тем же экранам: структура полностью совпадает с тем, что вы видели в этом сценарии.

P.S. В проде обязательно проверьте VLAN’ы, MTU под трафик хранилища и сетевые ACL’ы на NAS, а также резервирование доступа к iSCSI-target — это напрямую влияет на стабильность GFS2-кластера.