Подготовка окружения к установке

Перед установкой Закрома.Хранение подготовьте инфраструктуру по шагам ниже.

1. Отключение SELinux

Убедитесь, что для Red Hat-based дистрибутивов SELinux отключён или переведён в режим Permissive.

2. Проверка и настройка DNS

Убедитесь, что DNS-имена разрешаются с управляющего сервера и со всех целевых узлов. Если вместо DNS используется /etc/hosts, одинаковые записи должны присутствовать на всех узлах.

Для S3 API с версии 2.9 используется единая схема адресации <workspace>.<FQDN>. Рабочая область global создаётся по умолчанию и доступна по адресу global.<FQDN>.

Значение zakroma_storage_base_domain должно соответствовать выбранному сценарию:

Несколько базовых доменов

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

Copy
1zakroma_storage_base_domain: "zakroma.internal,s3.company.internal"

Указывайте доменные имена без схемы http:// или https://, порта и пути. Для каждого домена подготовьте DNS-записи и TLS-сертификаты.

В инструкции используется пример домена zakroma.internal. Замените его на доменную зону своей инфраструктуры.

Порты S3 API и Admin UI зависят от схемы доступа. Балансировщик haproxy-ha из поставки опционален: можно использовать собственный балансировщик или DNS RR, см. Рекомендации по балансировке.

При публикации через собственный балансировщик или Nginx используйте порты его фактической конфигурации.

Базовый кластер, растянутый кластер и Single Node

В базовом и растянутом кластере записи S3 API и Admin UI указывают на VIP балансировщика. Порты в таблице приведены для Single Node, для других схем — см. таблицу выше.

Мультикластер

Для каждого кластера создайте собственную доменную зону:

Работа без ps/vs В стандартной схеме отдельные домены ps.<FQDN> и vs.<FQDN> не требуются.

• Path-style: endpoint https://<workspace>.<FQDN>, объект доступен по адресу https://<workspace>.<FQDN>/<bucket>/<object>. Для этой схемы достаточно DNS-записи *.<FQDN>.
• Virtual-hosted-style: endpoint остаётся https://<workspace>.<FQDN>, а запрос к объекту поступает на https://<bucket>.<workspace>.<FQDN>/<object>. Для каждой рабочей области потребуются DNS-имена <workspace>.<FQDN> и *.<workspace>.<FQDN>.

Для обратной совместимости Закрома.Хранение поддерживает домены классической схемы ps/vs. Если сохраняется legacy-конфигурация Nginx, настройте её отдельно: Настройка Nginx.

Проверка DNS

Проверяйте конкретное имя рабочей области, а не имя wildcard-записи. Например, для базового кластера:

Copy
1getent ahostsv4 test-workspace.zakroma.internal
2getent ahostsv4 global.zakroma.internal
3getent ahostsv4 zakroma-admin.zakroma.internal
4getent ahostsv4 postgresql.zakroma.internal
5
6dig +short A test-workspace.zakroma.internal
7dig +short A global.zakroma.internal

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

Copy
1getent ahostsv4 test-workspace.cluster-1.zakroma.internal
2getent ahostsv4 postgresql.cluster-1.zakroma.internal
3getent ahostsv4 zakroma-cdn.cluster-1.zakroma.internal
4
5getent ahostsv4 test-workspace.cluster-2.zakroma.internal
6getent ahostsv4 postgresql.cluster-2.zakroma.internal
7getent ahostsv4 zakroma-cdn.cluster-2.zakroma.internal

При использовании virtual-hosted-style дополнительно проверьте имя бакета:

Copy
1getent ahostsv4 test-bucket.test-workspace.zakroma.internal

3. Подготовка сертификатов (TLS/SSL)

Подготовьте wildcard-сертификат или сертификат, содержащий необходимые DNS-имена в расширении SAN.

Для базового кластера и Single Node:

• *.zakroma.internal — рабочие области S3 API при path-style, включая global;
• zakroma-admin.zakroma.internal;
• keycloak.zakroma.internal — при использовании Keycloak;
• kafka-ui.zakroma.internal — при использовании Kafka UI.

Для мультикластера:

• *.cluster-1.zakroma.internal и *.cluster-2.zakroma.internal;
• zakroma-admin.cluster-1.zakroma.internal и zakroma-admin.cluster-2.zakroma.internal;
• zakroma-cdn.cluster-1.zakroma.internal и zakroma-cdn.cluster-2.zakroma.internal;
• имена Keycloak и Kafka UI — при использовании соответствующих компонентов.

Wildcard-сертификат *.<FQDN> покрывает адрес <workspace>.<FQDN> и достаточен для path-style. Он не покрывает адрес <bucket>.<workspace>.<FQDN>: для virtual-hosted-style подготовьте для каждой рабочей области сертификат с SAN <workspace>.<FQDN> и *.<workspace>.<FQDN>. Маска *.*.<FQDN> стандартными TLS-клиентами не поддерживается.

Если PostgreSQL использует TLS, его сертификаты и доверенную цепочку подготовьте отдельно в соответствии со значением zakroma_storage_postgresql_sslmode.

Для legacy-схемы с Nginx path-style требует сертификат *.ps.<FQDN>. Для virtual-hosted-style сертификата *.vs.<FQDN> недостаточно: нужны SAN <workspace>.vs.<FQDN> и *.<workspace>.vs.<FQDN> для каждой рабочей области. Подробнее см. Настройка Nginx.

4. Подготовка управляющего сервера Ansible

1. Проверьте, что доступно SSH-подключение к каждому узлу.
2. Убедитесь, что пользователь имеет привилегированный (sudo) доступ.
3. Установите или обновите Ansible. Поддерживаются версии от 2.15.0 до 2.18.15. С другими версиями возможны ошибки при запуске плейбуков.
4. Установите пакет sshpass из дистрибутива вашей ОС, если планируется подключение к узлам по логину и паролю.
5. Рекомендуется запускать ansible-playbook из корневого каталога распакованной поставки, где находятся ansible.cfg, inventories/, playbooks/, roles/ и collections/: тогда относительные пути поставки работают без правок.
6. Указывайте файл конфигурации явно через переменную окружения ANSIBLE_CONFIG=ansible.cfg и запускайте плейбуки из корня распакованной поставки, указывая путь playbooks/<имя>.yml.

Пример для базового кластера:

Copy
1cd zakroma-roles-8.1.0
2ANSIBLE_CONFIG=ansible.cfg ansible-playbook -i inventories/base-cluster/hosts playbooks/sample-play-zakroma-storage.yml

Пример для Single Node:

Copy
1cd zakroma-roles-8.1.0
2ANSIBLE_CONFIG=ansible.cfg ansible-playbook -i inventories/single-node/hosts playbooks/sample-play-zakroma-zds-fs.yml

5. Настройка PostgreSQL

Настройте PostgreSQL согласно инструкции.

6. Подготовка дисковых устройств для ZDS

Выполните подготовку дисков на каждом узле группы zakroma-zds-v2-ec. Роль ZDS создаёт каталоги и назначает им владельца zakroma, но не создаёт LVM, файловые системы и точки монтирования.

Проверка дисков и необходимых пакетов

На узле должны быть установлены пакеты lvm2 и xfsprogs. Проверьте команды и выбранные устройства:

Copy
1command -v pvcreate
2command -v mkfs.xfs
3
4lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL
5sudo wipefs --no-act /dev/vdb

Создание LVM и XFS удаляет данные

Команды ниже предназначены для пустых дисков. Перед выполнением проверьте имя устройства и убедитесь, что оно не относится к системному диску, существующей VG или файловой системе с данными.

Создание PV, VG, LV и XFS

Базовая схема для ZDS: один физический диск — один PV — одна VG — один LV — одна точка монтирования. Не объединяйте независимые диски в общую VG без отдельно спроектированного RAID или другого уровня отказоустойчивости.

Пример подготавливает /dev/vdb, создаёт vg_zds_01/lv_zds_01, форматирует LV в XFS и монтирует его в /mnt/lvm1:

Copy
1sudo pvcreate /dev/vdb
2sudo vgcreate vg_zds_01 /dev/vdb
3sudo lvcreate --extents 100%FREE --name lv_zds_01 vg_zds_01
4
5sudo mkfs.xfs /dev/vg_zds_01/lv_zds_01
6sudo install -d -m 0755 /mnt/lvm1
7
8ZDS_UUID=$(sudo blkid -s UUID -o value /dev/vg_zds_01/lv_zds_01)
9FSTAB_LINE="UUID=${ZDS_UUID} /mnt/lvm1 xfs defaults,noatime,nodiscard 0 0"
10sudo grep -Fqx "$FSTAB_LINE" /etc/fstab || printf '%s\n' "$FSTAB_LINE" | sudo tee -a /etc/fstab
11
12sudo mount -a
13findmnt --target /mnt/lvm1

Повторите команды для каждого диска, изменяя устройство, VG, LV и точку монтирования:

Параметры XFS

Используйте параметры mkfs.xfs по умолчанию: они подходят для большинства инсталляций. Дополнительные параметры создания и монтирования ФС задавайте только после консультации с технической поддержкой.

Стандартное размещение данных и реестра БД

В стандартной схеме registry ZDS размещается на одном LV с данными:

Состояние фоновых задач можно разместить на постоянной файловой системе системного диска:

• /var/lib/zakroma-ds-agent/vacuum-state — состояние задачи vacuum;
• /var/lib/zakroma-ds-agent/scan-state — контрольные точки задачи scan.

Для сценариев base-cluster и multicluster измените только соответствующие пути в файле group_vars/zakroma-zds-v2-ec.yml выбранного inventory, сохранив остальные параметры секций. Фрагмент ниже не предназначен для полной замены секций: в поставке они содержат дополнительные параметры.

Copy
1zakroma_zds_drive:
2  list:
3    - index: 1
4      path: "/mnt/lvm1/data"
5      storageGroup: 1
6      storageClass: ""
7    - index: 2
8      path: "/mnt/lvm2/data"
9      storageGroup: 2
10      storageClass: "HDD"
11    - index: 3
12      path: "/mnt/lvm3/data"
13      storageGroup: 3
14      storageClass: "HDD"
15
16zakroma_zds_registry:
17  path: "/mnt/lvm1/system/db"
18
19zakroma_zds_background_window_jobs:
20  vacuum:
21    storePath: "/var/lib/zakroma-ds-agent/vacuum-state"
22  scan:
23    storePath: "/var/lib/zakroma-ds-agent/scan-state"

Смонтируйте LV до запуска Ansible

Если /mnt/lvm1, /mnt/lvm2 или /mnt/lvm3 не смонтированы, роль всё равно создаст каталоги по указанным путям, но они окажутся на системной файловой системе.

Схема размещения дисковых групп ZDS на примере трёх дисков

Отдельный LV для реестра БД ZDS

Для крупных инсталляций реестр БД рекомендуется разместить на отдельном LV. Такой LV может находиться в той же VG, что и data-LV, или в другой VG. Размер определяется по результатам сайзинга с технической поддержкой.

Если реестр БД и LV с данными создаются в одной VG, сначала зарезервируйте место под реестр БД, а оставшееся пространство отдайте LV с данными. Следующий пример использует размер 100G только для демонстрации синтаксиса:

Copy
1sudo pvcreate /dev/vdb
2sudo vgcreate vg_zds_01 /dev/vdb
3
4sudo lvcreate --size 100G --name lv_zds_registry vg_zds_01
5sudo lvcreate --extents 100%FREE --name lv_zds_01 vg_zds_01
6
7sudo mkfs.xfs /dev/vg_zds_01/lv_zds_registry
8sudo mkfs.xfs /dev/vg_zds_01/lv_zds_01
9
10sudo install -d -m 0755 /mnt/zds-registry /mnt/lvm1
11
12REGISTRY_UUID=$(sudo blkid -s UUID -o value /dev/vg_zds_01/lv_zds_registry)
13REGISTRY_FSTAB_LINE="UUID=${REGISTRY_UUID} /mnt/zds-registry xfs defaults,noatime,nodiscard 0 0"
14sudo grep -Fqx "$REGISTRY_FSTAB_LINE" /etc/fstab || printf '%s\n' "$REGISTRY_FSTAB_LINE" | sudo tee -a /etc/fstab
15
16DATA_UUID=$(sudo blkid -s UUID -o value /dev/vg_zds_01/lv_zds_01)
17DATA_FSTAB_LINE="UUID=${DATA_UUID} /mnt/lvm1 xfs defaults,noatime,nodiscard 0 0"
18sudo grep -Fqx "$DATA_FSTAB_LINE" /etc/fstab || printf '%s\n' "$DATA_FSTAB_LINE" | sudo tee -a /etc/fstab
19
20sudo mount -a

Для этой схемы измените только путь до реестра БД:

Copy
1zakroma_zds_registry:
2  path: "/mnt/zds-registry/db"

Не добавляйте /mnt/zds-registry или /mnt/zds-registry/db в zakroma_zds_drive.list: этот LV не используется для объектных данных.

Проверка перед установкой

До запуска Ansible убедитесь, что XFS смонтирована с ожидаемых LV:

Copy
1sudo pvs
2sudo vgs
3sudo lvs
4
5findmnt --target /mnt/lvm1
6findmnt --target /mnt/lvm2
7findmnt --target /mnt/lvm3
8findmnt -no SOURCE,FSTYPE,OPTIONS --target /mnt/lvm1
9
10sudo xfs_info /mnt/lvm1
11df -h /mnt/lvm1 /mnt/lvm2 /mnt/lvm3

Для схемы с отдельным LV для реестра БД дополнительно выполните:

Copy
1findmnt --target /mnt/zds-registry
2sudo xfs_info /mnt/zds-registry
3df -h /mnt/zds-registry

После выполнения роли проверьте фактические файловые системы и права каталогов:

Copy
1findmnt --target /mnt/lvm1/data
2findmnt --target /mnt/lvm1/system/db
3findmnt --target /var/lib/zakroma-ds-agent/vacuum-state
4findmnt --target /var/lib/zakroma-ds-agent/scan-state
5
6stat -c '%U:%G %a %n' \
7  /mnt/lvm1/data \
8  /mnt/lvm1/system/db \
9  /var/lib/zakroma-ds-agent/vacuum-state \
10  /var/lib/zakroma-ds-agent/scan-state

Для схемы с отдельным registry-LV замените в проверках /mnt/lvm1/system/db на /mnt/zds-registry/db.

7. Пакет Nginx

Nginx обязателен только в мультикластерном сценарии: он устанавливается на узлах Закрома.Хранение, принимает CDN-запросы на порту 443 или другом настроенном порту, терминирует TLS и проксирует их на локальный endpoint http://127.0.0.1:8099.

Для мультикластера и legacy-инсталляций Nginx версии от 1.14.1 до 1.29.1 должен быть доступен в репозиториях пакетного менеджера целевых узлов или уже установлен. С более ранними версиями возможны проблемы совместимости.

Инструкция по настройке: Настройка Nginx.

8. Балансировщик haproxy-ha

В базовом и растянутом кластере роль haproxy-ha устанавливает HAProxy и keepalived на узлы Закрома.Хранение. Перед установкой:

• выделите свободный IPv4-адрес (VIP) в сети узлов: один для базового кластера; для растянутого кластера — один общий при общем L2-сегменте площадок или по одному на площадку при L3;
• убедитесь, что пакеты haproxy и keepalived доступны в системных репозиториях целевых узлов;
• разрешите в сети VRRP (IP-протокол 112, multicast) между узлами одной VRRP-группы;
• на узлах с SELinux в режиме enforcing используйте keepalived версии 2.1 или новее: роль включает для HAProxy логический параметр SELinux haproxy_connect_any;
• подготовьте пароль VRRP-аутентификации длиной не более 8 символов и сохраните его в ansible-vault.

HAProxy работает в режиме TCP passthrough: TLS терминируется на узлах Закрома.Хранение, поэтому сертификат должен содержать DNS-имена Admin UI и S3 API, указывающие на VIP.