Системные требования для решения на базе Gluster

1. Версии zVirt Max

Поддерживаемая гиперконвергентная инфраструктура должна быть реализована на базе хостов виртуализации zVirt Max версии 1.2 и выше.

Не устанавливайте дополнительные пакеты после базовой установки, так как они могут вызвать проблемы с зависимостями при попытке менеджером управления установить пакеты из репозитория zVirt Max.

Не включайте дополнительные репозитории, кроме тех, которые предоставляются с дистрибутивом zVirt Max.

2. Хосты

Для развертывания полнофункционального решения SDS требуется не менее трех хостов. Также поддерживается масштабирование до 6, 9 или 12 хостов.

Каждый хост должен соответствовать следующим требованиям:

Не менее двух NIC (сетевых интерфейсных карты) на хост для разделения трафика данных и управления;
для небольших развертываний (хранилище до 48 ТБ):
- не менее 12 ядер;
- не менее 64 ГБ оперативной памяти (RAM);
для средних развертываний (хранилище до 64 ТБ):
- не менее 12 ядер;
- не менее 128 ГБ оперативной памяти (RAM);
для крупных развертываний (хранилище до 80 ТБ):
- не менее 16 ядер;
- не менее 256 ГБ оперативной памяти (RAM);

В случае использования хоста с бриком-арбитром, он должен соответствовать следующим требованиям:

Минимальные требования

4 ядра
8 ГБ оперативной памяти
Накопители:
- 100 ГБ для системы
- 10 ГБ для арбитра
Не менее двух NIC (сетевых интерфейсных карты):
- Для сети управления
- Для сети SDS

Рекомендуемые требования

8 ядер
16 ГБ оперативной памяти
Накопители:
- 100 ГБ для системы
- 10 ГБ для арбитра
Не менее двух NIC (сетевых интерфейсных карты):
- Для сети управления
- Для сети SDS

В качестве арбитра может выступать виртуальная машина. При этом она должна соответствовать описанным выше системным требованиям.

Если параметры арбитра соответствуют только минимальным требованиям, то такой хост не предназначен для запуска на нем виртуальных машин.

Чтобы избежать запуска ВМ на хосте либо не добавляйте его в кластер, либо создайте отдельный пустой центр данных и разместите хост в нем.

3. Виртуальные машины

Количество виртуальных машин, которые можно запустить в гиперконвергентном решении, сильно зависит от функций этих виртуальных машин и уровня их загрузки.

Ограничение максимального количества виртуальных машин и виртуальных процессоров см. в статье Максимальные показатели (Ограничения) zVirt Max 1.2.

4. ВМ Hosted Engine

Минимальные требования к вычислительным ресурсам ВМ Hosted Engine, описанные здесь, основаны на типичной установке малого и среднего размера. Точные требования варьируются в зависимости от размера и нагрузки. Подробнее см. в разделе Рекомендации по развертыванию Менеджера управления лучших практик.

Таблица 1. Требования к аппаратному обеспечению менеджера управления zVirt Max
Ресурс	Минимальные требования	Рекомендуемые требования
Процессор	4vCPU	8vCPU
Память	4 ГБ	32 ГБ
Жёсткий диск	51 ГБ	120 ГБ
Сетевой интерфейс	1 сетевой интерфейс (NIC) 1 Гбит/с

5. Сети

Для всех хостов в гиперконвергентной среде и для виртуальной машины Hosted Engine необходимо использовать полностью определенные доменные имена (FQDN), которые могут быть разрешены DNS как в прямом, так и в обратном направлении.

Если внешний DNS недоступен, например, в изолированной среде, убедитесь, что файл /etc/hosts на каждом хосте содержит сопоставления имен и адресов всех хостов и ВМ Hosted Engine.

Рекомендуется использовать DNS вместо /etc/hosts.

IPv6 поддерживается только в средах с адресами IPv6 (включая адреса DNS и шлюзов). Dual-stack (IPv4 и IPv6) среды не поддерживаются.

Рекомендуется использовать выделенные сети:

Внешняя сеть для управления и трафика виртуальных машин.
Внутренняя сеть для трафика Gluster и миграции виртуальных машин.

Рекомендуется, чтобы каждый хост имел два порта Ethernet, по одному для каждой сети. Это обеспечивает оптимальную производительность.

Для обеспечения высокой доступности рекомендуется разместить каждую сеть на отдельном сетевом коммутаторе. Для повышения отказоустойчивости обеспечьте отдельный источник питания для каждого коммутатора.

Внешняя сеть

Используется виртуализацией zVirt Max для трафика управления и трафика виртуальных машин.
Требуется не менее одно подключение Ethernet со скоростью 1 Гбит/с.
IP-адреса, используемые в этой сети, должны использовать подсети, отличные от внутренней сети.

Внутренняя сеть

Используется для трафика Gluster и миграции между хостами.
Требуется не менее одного подключения Ethernet со скоростью 10 Гбит/с.
Максимально допустимое время задержки между узлами - 5 миллисекунд.

Устройства сетевого ограждения, использующие IPMI, должны находиться в выделенной сети.

Перед началом процесса развертывания проверьте:

IP-адрес шлюза для хостов. Этот адрес должен отвечать на запросы ping.

Шлюз необходимо назначать только на том интерфейсе, который расположен во внешней сети.
IP-адрес сети управления (ovirtmgmt).
Полное доменное имя (FQDN) для виртуальной машины Hosted Engine.
MAC-адрес, который разрешается в FQDN и IP-адрес Hosted Engine.
IP-адрес хостов в сети Gluster.
Хосты в сети Gluster доступны друг для друга (например, по ICMP).
На интерфейсе Gluster не задан шлюз по умолчанию, если его наличие не требуется.

6. Хранилище

Хостам требуется хранилище для хранения конфигурации, журналов, дампов ядра и для использования в качестве пространства подкачки.

Минимальные требования и рекомендуемая схема разбиения хранилища:

/(root) - 55 ГБ
/home - 1 ГБ
/tmp - 1 ГБ
/boot - 1 ГБ
/var - 15 ГБ
/var/crash - 10 ГБ
/var/log - 8 ГБ
/var/log/audit - 2 ГБ
swap - 1 ГБ

Минимальный общий объём - 94 ГБ.

Как при автоматической, так и при ручной разбивке имейте ввиду:

Некоторые разделы могут быть созданы только в формате Thin LVM (например, /).
Anaconda резервирует 20% от размера тонкого пула в группе томов для будущего расширения метаданных. Это сделано для того, чтобы предотвратить нехватку места в готовой конфигурации при нормальных условиях использования. Перераспределение тонких пулов при установке также не поддерживается.
При автоматической разбивке swap-разделу выделяется пространство в соответствии с объемом установленной оперативной памяти. Это важно учитывать при расчете оставшегося пространства.
При автоматической разбивке, если размер хранилища меньше рекомендуемого, экономия будет производиться за счет раздела /.

6.1. Диски

Рекомендуется использовать SSD для достижения наилучшей производительности. Если используется HDD, также рекомендуется настроить небольшой SSD в качестве кэширующего тома LVM. Устройство кэша должно использовать тот же размер блока, что и другие тома.

Не размещайте брики тома Gluster на дисках с разными размерами блоков. Для проверки размера блока (в байтах) диска выполните следующую команду:

blockdev --getss <disk_path>

6.2. RAID

Поддерживаются конфигурации RAID5 и RAID6, но ограничения на конфигурацию RAID зависят от используемой технологии.

Диски SAS/SATA 7k поддерживаются с RAID6 (максимум 10+2). Диски SAS 10k и 15k поддерживаются со следующими конфигурациями:

RAID5 (максимум 7+1);
RAID6 (максимум 10+2).

RAID-контроллеры должны использовать кэш записи с флеш-памятью.

Также рекомендуется иметь не менее один диск горячей замены на каждом сервере.

6.3. JBOD

SDS поддерживает конфигурации JBOD и не требуют проверки архитектуры.

6.4. Логические тома

Логические тома, составляющие том gluster engine, должны использовать предварительное выделение пространства (thick). Это защищает Hosted Engine от ситуаций выхода за пределы пространства, изменения конфигурации тома, повышенных затрат ресурсов на ввод-вывод и миграции.

Логические тома для хранилища и дополнительные тома gluster должны использовать динамическое выделение пространства (thin). Это обеспечивает большую гибкость в конфигурации базовых томов.

Если тома с динамическим выделением пространства находятся на жестких дисках (HDD), настройте небольшой SSD в качестве lvmcache для повышения производительности. Устройство кэша должно использовать тот же размер блока, что и остальные тома.

6.5. Тома Gluster

Гиперконвергентная инфраструктура будет иметь 3 тома Gluster:

1 том engine для ВМ Hosted Engine.
1 том для образов дисков операционной системы ВМ.
1 том для других образов дисков ВМ.

Для минимизации требований к хранению резервных копий рекомендуется использовать раздельные тома для образов дисков операционной системы ВМ и для других образов дисков ВМ. Хранение данных виртуальной машины отдельно от образов операционной системы означает, что при нехватке места для хранения необходимо создавать резервные копии только тома, предназначенного для других образов дисков ВМ, поскольку образы операционной системы на предназначенном для них томе легче восстанавливать.

6.6. Типы томов

SDS на этапе развертывания поддерживает только следующие типы томов:

Реплицированные тома: три копии одних и тех же данных на трех бриках, распределенных по трем хостам.

Реплицированные тома рекомендуется использовать в средах, для которых важна высокая доступность и надежность.
Арбитражные реплицированные тома: две полные копии одних и тех же данных на двух бриках и один арбитр-брик, содержащий метаданные, распределенный по трем хостам.
Преимущества арбитражных реплицированных томов:
- Лучшая согласованность.
- Требуется меньше дискового пространства.
- Требуется меньше хостов.
Недостатки:
- Снижение производительности из-за необходимости обращения к арбитру.
- Более сложное восстановление данных.
- Зависимость от арбитра.

Распределенный том с одним бриком: 1 копия данных без репликации на другие брики.

Распределенный том с одним бриком имеет серьёзные недостатки:

Временные несоответствия записей каталогов и метаданных при возможных сбоях узлов.
Операции ввода-вывода блокируются или не выполняются из-за недоступности узла или возможных сбоев узла.
Высокая вероятность окончательной потери данных.

Распределенный том с одним бриком поддерживается только при развертывании SDS на одной ноде.

Обратите внимание, что в арбитражных томах хранятся только имена файлов, структура и метаданные. Это означает, что для достижения такого же уровня согласованности 3-сторонний арбитражный реплицированный том требует примерно 75% дискового пространства, необходимого для 3-стороннего реплицированного тома. Поскольку арбитр хранит только метаданные, трехсторонний арбитражный реплицированный том обеспечивает доступность, аналогичную двухстороннему реплицированному тому.

7. Масштабирование

При использовании автоматизации Ansible можно развернуть до 12 гиперконвергентных хостов и охватить томами необходимое количество узлов во время развертывания.

Развертывания на 1 хосте не могут быть масштабированы.

Другие развертывания могут быть масштабированы от минимума (3 хостов) до 6, 9 или 12 узлов.

Масштабирование развертывания возможно путем добавления дисков и расширения томов Gluster. Можно добавить диски на новые или существующие хосты и использовать их для создания новых или расширения существующих томов Gluster.