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

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

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

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

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

Убедитесь, что DNS-имена разрешаются с Ansible-контроллера и со всех целевых узлов. Если вместо 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. Замените его на доменную зону своей инфраструктуры.

В таблицах указаны порты сервисов без использования балансировщиков, или с использованием балансировщиков, работающих в режиме TCP. При публикации через Nginx или балансировщик внешний порт обычно равен 443 и должен соответствовать фактической конфигурации. Сценарий Quick Start отдельно переопределяет порты S3 API и Admin UI на 6443 и 8444.

Базовый кластер и 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)

Подготовьте сертификаты или 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, а затем выполнить нужный playbook из каталога playbooks/.

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

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

Пример для одноузлового варианта:

Copy
1cd zakroma-roles-7.2.3
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. Роль ZDSv2 создаёт каталоги и назначает им владельца 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 ZDSv2 размещается на одном 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

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

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 не является обязательным компонентом стандартной установки. Проверка пакета Nginx требуется только для legacy-инсталляций, где используется отдельная конфигурация Nginx.

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

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