Подготовка хостов

В главе приведены требования к хосту (хостам), которые должны быть выполнены до запуска install.sh. Инсталлятор намеренно не устанавливает эти компоненты (не изменяет пакеты и сетевую политику хоста) за исключением развёртывания бандлов.

Чек-лист подготовки хостов

Таблица 3.1. Чек-лист пререквизитов на хостах (по сценариям установки)

Сценарий	Требуется на хосте
Инфра + control-plane (online, без Engine)	Базовые Java 17 Python3 DNS/Nexus-креды Firewalld
Инфра + control-plane (offline, без Engine)	Базовые Java 17 Python3 bundleDir с артефактами Firewalld
+ Engine (StarRocks)	Дополнительно: ansible-core + sshpass galaxy: ansible.posix+community.general SSH-доступ к нодам LVM rootlv расширен license.jwt
BE/CN-ноды	CPU с AVX2 RHEL ≥9.8 / Ubuntu ≥22.04 NTP < 5c FE-ноды — Java 17
FE-ноды	Любая ОС с Java 17
Вынесенный Engine (multi-node)	engine.queryHost = FE leader IP

Engine-ноды настраиваются автоматически через bootstrap-host.yaml (пакеты, sysctl, лимиты, пользователь selena, порты). См. раздел 3.2.5 «Пререквизиты для Engine».

Описание пререквизитов

Примеры команд приведены для RHEL 9 (dnf), в Ubuntu замените на apt.

Базовые утилиты

Базовые утилиты: bash, awk, curl, tar, openssl, sha256sum, systemctl, — есть в RHEL и Ubuntu по умолчанию.

yq не требуется. deploy.yaml и artifacts.yaml парсятся встроенным awk-парсером (scripts/lib/common.sh → yaml_get). Сторонние исполняемые файлы не понадобятся.

Java 17

Java ≥17 (control-plane: CM + Keycloak)

sudo dnf install -y java-17-openjdk-headless

Python 3

Для работы скриптов инсталлятора (keycloak-realm.sh, engine.sh) на хосте должен быть установлен интерпретатор Python 3.

На большинстве дистрибутивов (Ubuntu, RHEL) Python 3 присутствует в базовой поставке, однако на minimal-образах он может отсутствовать. Убедитесь, что Python 3 установлен до запуска инсталлятора.

Инсталлятор проверяет наличие Python 3 на этапе preflight. При отсутствии — установка будет прервана с соответствующим сообщением.

примечание

Alembic-миграции (обновление схемы БД) используют встроенный интерпретатор Python из бандла (\${OPT_ROOT}/ide/runtime/bin/python3) и не требуют наличия системного Python на хосте.

Доступ к Nexus

Доступ к Nexus (для online-режима):

# DNS: hub.selena.sh не резолвится встроенным DNS тест-VM  
echo "194.190.8.222 hub.selena.sh" | sudo tee -a /etc/hosts 

# креды реестра (передаются install.sh как env)  
export NX_USER='<логин>'  
export NX_PASS='<пароль>'

В offline-режиме Nexus не используется — артефакты берутся из bundleDir.

Пререквизиты для Engine

примечание

Раздел актуален для сценариев, предусматривающих развертывание Engine (StarRocks) через Cluster Manager. Если Engine не разворачивается — этот раздел возможно пропустить.

Cluster Manager не выполняет установку StarRocks напрямую. Он запускает Ansible на хосте CM, который через SSH настраивает FE/BE-ноды.

ОС Engine-нод (для BE/CN)

ОС для BE/CN:

• Подходят: RHEL ≥9.8 / Ubuntu ≥22.04 / Astra 1.8 или иной EL9 с GLIBC_2.35
• Не подходят: RHEL 9.6, RHEL 8, Astra 1.7 (версия glibc ниже требуемой)

BE и CN — компоненты C++ (selena_be), требуют определённой версии системной библиотеки glibc. FE — Java-приложение, для него это не имеет значения.

Бандлы BE/CN собраны под glibc 2.35 (Ubuntu 22.04) и требуют символ _dl_find_object@GLIBC_2.35.

Таблица 3.2. Совместимость ОС с BE/CN

ОС BE-ноды	glibc	_dl_find_object@2.35	Статус запуска BE
RHEL 9.6	2.34	Нет	Ошибка: version 'GLIBC_2.35' not found → BE exit 1 → install-be.yaml timeout 9050
RHEL 9.8+	2.34	Есть (бэкпортирован Red Hat)	Запущен
Ubuntu 22.04 / 24.04	2.35 / 2.39	Есть	Запущен
Rocky Linux 9	2.34	Зависит от минорной версии	Аналогично RHEL 9
RHEL 8 / CentOS 8	2.28	Нет	Ошибка

warning

ldd --version на RHEL 9.6 и 9.8 показывает glibc 2.34 в обоих случаях. Однако Red Hat бэкпортирует некоторые символы из новых glibc в свежие минорные версии.
Проверка совместимости без запуска BE:

objdump -T /opt/selena/be/lib/selena_be | grep GLIBC_2.35 # какие 2.35-символы нужны
objdump -T /lib64/libc.so.6 | grep _dl_find_object # есть ли он в системном libc

CPU: AVX2 (для BE/CN)

StarRocks BE использует векторизацию на AVX2 — без него selena_be не стартует. Проверка:

grep -o avx2 /proc/cpuinfo | head -1 # должно вывести avx2

Требуются процессоры (≈ 2013 года и новее). В виртуальных средах AVX2 может быть скрыт от гостевой ОС, если не настроен проброс флагов CPU (passthrough). Это аппаратное требование, не подлежит программной настройке.

Синхронизация времени (для multi-node)

StarRocks требует расхождение часов между FE/BE-нодами менее 5 секунд. При превышении этого порога FE не может выбрать LEADER/FOLLOWER (в fe.log регистрируется ошибка: «time deviation between FE nodes is greater than 5s»). bootstrap-host.yaml не выполняет эту настройку — её необходимо обеспечить заранее на каждой ноде:

sudo dnf install -y chrony && sudo systemctl enable --now chronyd # RHEL  
# Ubuntu/Astra: systemd-timesyncd обычно уже активен (timedatectl)  
timedatectl # проверить: System clock synchronized: yes

Настройка Engine-нод

Настройки, выполняемые через bootstrap-host.yaml (автоматически):

• Установка пакетов (openjdk-17-headless/jre, mariadb, mariadb-client, tar, gzip, curl, firewalld).
• Применение параметров ядра (vm.max_map_count=262144).
• Настройка лимитов ресурсов для пользователя selena (nofile и nproc = 655350).
• Создание служебного пользователя и группы selena (UID/GID 10001).
• Открытие портов в firewalld.

примечание

JDK 17 требуется также на BE-нодах, поскольку selena_be использует JNI для работы с external catalogs (линковка с libjvm.so). StarRocks официально не рекомендует использование JRE вместо JDK. Однако в Ubuntu через apt устанавливается openjdk-17-jre-headless, чего достаточно для выполнения рантайма, но может быть недостаточно для компиляции UDF-функций.

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

• glibc-совместимая ОС (см. раздел 3.2.5.1)
• Поддержка AVX2 (раздел 3.2.5.1.1)
• Синхронизация времени через NTP (раздел 3.2.5.1.2)
• SSH-доступ от CM к Engine-нодам (раздел 3.2.5.4)
• Достаточное место в корневом разделе (раздел 3.2.5.5).

Аnsible + sshpass

Для управления Engine-нодами через Ansible установите на хосте CM пакеты ansible-core и sshpass:

sudo dnf install -y ansible-core sshpass

Galaxy-коллекции

Плейбуки CM (bootstrap-host.yaml и др.) используют модули из ansible.posix (например, ansible.posix.sysctl для vm.max_map_count=262144) и community.general.

sudo ansible-galaxy collection install ansible.posix community.general   
-p /usr/share/ansible/collections

⚠️ Флаг -p обязателен.

CM запускает Ansible от имени пользователя selena. Без флага коллекции устанавливаются в каталог пользователя, выполнившего команду (~/.ansible/collections), и не видны selena. Флаг -p /usr/share/ansible/collections помещает коллекции в системный каталог, доступный для всех пользователей, что обеспечивает их видимость для CM. Без этого возникает ошибка: couldn't resolve module/action 'ansible.posix.sysctl'.

Чтобы убедиться, что коллекции видны из контекста CM, выполните:

sudo -u selena ansible-galaxy collection list 2>/dev/null | grep -E 'posix|general'  
# фактические пути поиска коллекций под selena:  
sudo -u selena ansible-config dump 2>/dev/null | grep -i COLLECTIONS_PATH

Если путь переопределён (свой ansible.cfg рядом с плейбуками в /run/selena/cm/ansible/<id>/ или env) и /usr/share/ansible/collections не подхватывается, укажите его принудительно для сервиса CM:

echo 'ANSIBLE_COLLECTIONS_PATH=/usr/share/ansible/collections' | sudo tee -a /etc/selena/cm.env  
sudo systemctl restart selena-cm

SSH-доступ к FE/BE-нодам

Ansible с хоста CM подключается к Engine-нодам по SSH, используя учётную запись и ключ, указанные при регистрации ноды в CM. На каждой Engine-ноде должен присутствовать этот пользователь с настроенной аутентификацией по SSH-ключу и правом выполнения sudo без пароля (NOPASSWD).

При установке в режиме All-in-One инсталлятор автоматически создаёт локального пользователя selena-ansible с необходимыми настройками. Для отдельных нод (multi-node) учётную запись и ключ необходимо подготовить на каждой FE/BE-ноде вручную.

Root LVM

CM распаковывает StarRocks (engine-fe.tar.gz ≈1.2 ГБ, engine-be ≈1.4 ГБ) в /opt/selena, который располагается в корневом разделе. Многие облачные и enterprise-образы RHEL используют LVM с rootlv ≈2 ГБ и распаковка завершается с ошибкой: No space left on device (gtar: ... Cannot open: No space left).

OS-диск обычно 64 ГБ, но большая часть отдан в rootlv. Требуется расширить корневой раздел на каждой Engine-ноде:

sudo lvextend -l +100%FREE /dev/rootvg/rootlv # забрать весь свободный объём VG в root  
sudo xfs_growfs / # растянуть ФС (для xfs; для ext4 - resize2fs /)  
df -h / # проверка: должно стать ~40 ГБ

Альтернатива: заранее монтировать отдельный диск в /opt/selena. Без этого install-fe.yaml и install-be.yaml завершаются ошибкой на шаге распаковки архива.

License

Engine требует активную лицензию. Положить файл лицензии:

sudo install -d -m0755 /run/selena-input  
sudo cp <license.jwt> /run/selena-input/license.jwt

Без /run/selena-input/license.jwt engine-фаза пропускается с выдачей предупреждения, инфраструктура и control-plane при этом загружаются без ошибок.

Вынесенный Engine (multi-node)

Если Engine развёрнут на отдельных нодах (FE/BE не на хосте control-plane), IDE и MCP по умолчанию пытаются подключиться к StarRocks по адресу 127.0.0.1:9030. При отсутствии FE на локальном хосте возникает ошибка: (2002, "Can't connect to MySQL server on '127.0.0.1'").

engine:  
queryHost: 10.0.0.5 # IP FE-leader; all-in-one (FE на том же хосте) -> 127.0.0.1 (дефолт)

Инсталлятор передаёт указанный адрес в переменные IDE_SELENA_HOST и MCP_SELENA_HOST через detect_engine_query_host.

Для сценария «Инфра + control-plane» (online.deploy.yaml, без Engine) этап engine_bootstrap не выполняется, так как Engine устанавливается отдельно через CM. Сборка кластера производится вручную в CM UI/API.

Firewall (доступ к UI извне)

На RHEL-хостах по умолчанию активен firewalld. Открытие портов в облачной Security Group (NSG) недостаточно — необходимо также разрешить доступ на уровне хоста.

Выполните команды:

sudo firewall-cmd --permanent --add-port=8080/tcp --add-port=8088/tcp   
--add-port=10001/tcp --add-port=8412/tcp --add-port=3000/tcp  
sudo firewall-cmd --reload

Порты: 8080 (Keycloak), 8088 (CM), 10001 (IDE), 8412 (AI), 3000 (Grafana).

Preflight — проверка хоста

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

Preflight-проверки на этапе установки:

• Прерывание установки:
  • Неподходящая архитектура хоста (только amd64).
  • Отсутствуют базовые утилиты: systemctl, openssl, curl, tar, sha256sum, awk.
  • Порты заняты посторонними процессами.
  • Недоступен Nexus.
  • Не заданы переменные NX_USER и NX_PASS.
• Вывод предупреждения:
  • Недостаточны ресурсы хоста:
    CPU < 4 ядер, RAM < 8 ГБ, свободное место на /opt < 10 ГБ.
  • Выключены сервисы: postgres, keycloak, minio.

warning

Preflight проверяет ресурсы по порогу 4 vCPU / 8 ГБ, что ниже минимальных требований для All-in-One установки (8 vCPU / 32 ГБ). Прохождение preflight не гарантирует соответствие оборудования требованиям продукта.
Для offline-установки: Preflight проверяет наличие Ansible, Ansible Galaxy, sshpass и Galaxy-коллекций — при отсутствии установка прерывается.
Для online-установки: Ansible, Ansible Galaxy, sshpass и Galaxy-коллекции не проверяются. Их отсутствие будет обнаружено только на этапе установки Engine.