Установка базового кластера

Назначение и ограничения

Базовый кластер — это минимальная отказоустойчивая конфигурация из трёх узлов с совмещёнными сервисами Закрома.Хранение и ZDS.

Сервис ZDS по умолчанию использует схему Erasure Coding 2+1. При недоступности одного узла чтение и запись продолжаются, если две оставшиеся части данных доступны. Политику хранения можно изменить для каждого бакета в Admin UI, выбрав вариант, доступный для текущего кластера.

Каждый экземпляр сервиса Закрома.Хранение является самодостаточным: S3 API и Admin UI доступны, пока работает хотя бы один экземпляр сервиса. Клиентские запросы можно направлять на любой доступный узел.

Доступ можно организовать через внешний балансировщик, DNS Round-Robin или комбинацию этих подходов. S3 API и Admin UI используют разные сетевые порты; внешний балансировщик может проксировать запросы к обоим сервисам в зависимости от URL. Выбор схемы, TLS-терминации и проверок доступности описан в статье Рекомендации по балансировке.

Ограничения отказоустойчивости

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

Устанавливаемые компоненты

Имена rutherford-* используются только в примере. Замените их реальными именами и IP-адресами из вашей инфраструктуры и используйте те же имена в инвентаре Ansible и переменных group_vars.

Схема установки

На каждом из трёх узлов совместно работают сервисы Закрома.Хранение и ZDS. Все экземпляры Закрома.Хранение подключаются к внешнему PostgreSQL.

Установку можно выполнять с одного из узлов кластера или с отдельного управляющего сервера.

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

Подготовка PostgreSQL, DNS и TLS

До начала установки:

1. Подготовьте PostgreSQL по инструкции Настройка PostgreSQL.
2. Рассчитайте требуемое количество подключений по инструкции Расчёт max_connections PostgreSQL.
3. Убедитесь, что FQDN PostgreSQL, узлов кластера, Admin UI и S3 API разрешаются с управляющего сервера и со всех целевых узлов.
4. Подготовьте wildcard-сертификат или сертификат, содержащий необходимые DNS-имена в расширении SAN. Требования к DNS, сертификатам, узлам и дискам приведены в Подготовке к установке.
5. Убедитесь, что лицензия и TLS-файлы доступны на управляющем сервере.

Установка

1. Получение и распаковка архива поставки zakroma-roles

Copy
1tar -xvzf zakroma-roles-<ВЕРСИЯ_АРХИВА>.tar.gz
2cd zakroma-roles-<ВЕРСИЯ_АРХИВА>

Проверьте структуру распакованной поставки:

Copy
1tree -L 1

В корне должны присутствовать как минимум ansible.cfg, files, inventories, playbooks, requirements.yml.template и roles.

Установка из локальных файлов

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

2. Настройка инвентаря Ansible для текущего кластера

Отредактируйте inventories/base-cluster/hosts. Оставьте в группах certificates, zakroma-storage и zakroma-zds-v2-ec только три узла базового кластера.

Замените имена узлов и IP-адреса. Значения zakroma_zds_node_name должны быть уникальными, постоянными и не должны меняться в процессе эксплуатации.

Copy
1[certificates]
2rutherford-2 ansible_host=192.168.1.2
3rutherford-3 ansible_host=192.168.1.3
4rutherford-4 ansible_host=192.168.1.4
5
6[zakroma-storage]
7rutherford-2 ansible_host=192.168.1.2
8rutherford-3 ansible_host=192.168.1.3
9rutherford-4 ansible_host=192.168.1.4
10
11# Не изменяйте zakroma_zds_node_name после ввода кластера в эксплуатацию.
12[zakroma-zds-v2-ec]
13rutherford-2 ansible_host=192.168.1.2 zakroma_zds_node_name=rutherford-2
14rutherford-3 ansible_host=192.168.1.3 zakroma_zds_node_name=rutherford-3
15rutherford-4 ansible_host=192.168.1.4 zakroma_zds_node_name=rutherford-4

Проверьте SSH-доступ и выполнение Python-модулей Ansible:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible -m ping -i inventories/base-cluster/hosts all

Ожидаемый результат: каждый узел отвечает SUCCESS и pong.

3. Распространение сертификатов по узлам кластера

Поместите сертификат и ключ в каталог roles/certificates/files/ в корне распакованной поставки на управляющем сервере. Затем отредактируйте inventories/base-cluster/group_vars/certificates.yml.

Исходный файл содержит блок узла rutherford-1 с файлами keycloak.crt и keycloak.key. В базовом сценарии Keycloak не устанавливается — удалите весь блок rutherford-1 из host_cert_config. Затем измените имена остальных хостов, имена файлов, каталог назначения, владельца и права. В примере сертификат распространяется на все три узла Закрома.Хранение и ZDS.

Copy
1---
2certificates_copy_source_path: "files"
3
4host_cert_config:
5  rutherford-2: # имя из инвентаря Ansible
6    certs:
7      - src_dir: "{{ certificates_copy_source_path }}"
8        dest_dir: "/opt/certs/"
9        cert_file: "zakroma.crt"
10        key_file: "zakroma.key"
11        owner: "zakroma"
12        group: "zakroma"
13        cert_permissions: "0644"
14        key_permissions: "0600"
15  rutherford-3: # имя из инвентаря Ansible
16    certs:
17      - src_dir: "{{ certificates_copy_source_path }}"
18        dest_dir: "/opt/certs/"
19        cert_file: "zakroma.crt"
20        key_file: "zakroma.key"
21        owner: "zakroma"
22        group: "zakroma"
23        cert_permissions: "0644"
24        key_permissions: "0600"
25  rutherford-4: # имя из инвентаря Ansible
26    certs:
27      - src_dir: "{{ certificates_copy_source_path }}"
28        dest_dir: "/opt/certs/"
29        cert_file: "zakroma.crt"
30        key_file: "zakroma.key"
31        owner: "zakroma"
32        group: "zakroma"
33        cert_permissions: "0644"
34        key_permissions: "0600"

4. Настройка Закрома.Хранение

Отредактируйте inventories/base-cluster/group_vars/zakroma-storage.yml. Не заменяйте файл приведёнными ниже фрагментами целиком: сохраните остальные параметры поставки без изменений и измените только перечисленные параметры.

4.1. Настройка подключения к PostgreSQL

В примере все три экземпляра Закрома.Хранение подключаются к одной базе данных PostgreSQL. Параметры подключения находятся в нескольких блоках исходного файла. Во всех блоках могут использоваться одинаковые хост, порт, пользователь, пароль, имя базы и SSL-режим; значение postgresql_schema_name оставьте соответствующим компоненту.

Количество схем или БД для компонента worker (шардов БД) определяется совместно с технической поддержкой в соответствии с требованиями к RPS и планируемому количеству объектов.

Задайте общие параметры подключения в существующих переменных zakroma_storage_postgresql_*:

Copy
1zakroma_storage_postgresql_host: "<POSTGRESQL_FQDN>"
2zakroma_storage_postgresql_port: 5432
3zakroma_storage_postgresql_username: "<POSTGRESQL_USER>"
4zakroma_storage_postgresql_password: "<POSTGRESQL_PASSWORD>"
5zakroma_storage_postgresql_dbname: "zakroma"
6zakroma_storage_postgresql_sslmode: "<POSTGRESQL_SSLMODE>"
7zakroma_storage_postgresql_max_open_conns: 10
8zakroma_storage_postgresql_max_idle_conns: 5
9zakroma_storage_postgresql_connection_timeout: "10s"
10zakroma_storage_postgresql_target_session_attrs: "read-write"

В поставляемой конфигурации компоненты уже используют общие переменные zakroma_storage_postgresql_*. Измените их значения; ссылки в блоках компонентов и имена схем оставьте без изменений.

Защита чувствительных данных

Для безопасной работы с конфигурациями Ansible и переменными используйте ansible-vault. Ниже приведён пример шифрования пароля PostgreSQL.

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-vault encrypt_string \
2  --name zakroma_storage_postgresql_password

Завершение ввода значения

После ввода Vault-пароля введите значение переменной. Чтобы завершить ввод без добавления перевода строки, не нажимая Enter, нажмите Ctrl+D.

Введите Vault-пароль и значение переменной, затем вставьте весь полученный YAML-блок с !vault вместо открытого zakroma_storage_postgresql_password. Если используются зашифрованные переменные, добавляйте при запуске Ansible ключ из примера в разделе распространения лицензии.

4.2. Настройка домена, TLS и локальной авторизации

Измените FQDN сервиса Admin UI, базовый домен, параметры TLS и параметры учётной записи локального администратора. Остальные параметры внутри блока zakroma_storage_gateway можно оставить без изменений.

Copy
1zakroma_storage_config_encrypt: false
2
3zakroma_storage_admin:
4  path: "<ADMIN_UI_FQDN>"
5  reverse_proxy:
6    enabled: false
7    port: 443
8
9zakroma_storage_base_domain: "<BASE_DOMAIN>"
10
11zakroma_storage_gateway:
12  host: "<GATEWAY_FQDN>"
13  s3api_port: 8443
14  management_port: 6443
15  admin_console_location: "/opt/zakroma/zakroma-storage-admin/frontend/dist/admin-ui/"
16  tls:
17    enabled: true
18    certs:
19      - key: "/opt/certs/zakroma.key"
20        crt: "/opt/certs/zakroma.crt"
21  path_to_licence: "/opt/zakroma/zakroma-storage-gateway/bin/licence"
22
23  default_admin: "<LOCAL_ADMIN>"
24  auth:
25    auth_provider: file
26    user_provider: file
27    users:
28      - name: "<LOCAL_ADMIN>"
29        password: "<LOCAL_ADMIN_PASSWORD>"
30        groups:
31          - clouduser
32# Группа clouduser тут указана в качестве примера.

При zakroma_storage_config_encrypt: true роль шифрует конфигурационные файлы через systemd LoadCredentialEncrypted=. Включайте параметр только на узлах с systemd версии 250 или новее и установленной утилитой systemd-creds.

При использовании внешнего Nginx см. Настройка Nginx. Роль zakroma-storage не устанавливает внешний балансировщик.

5. Настройка сервиса ZDS

Для установки сервиса хранения ZDS отредактируйте inventories/base-cluster/group_vars/zakroma-zds-v2-ec.yml. Сохраните неизменяемые параметры поставки и замените только значения, которые зависят от конфигурации вашего кластера.

5.1. Настройка API, межузлового взаимодействия и Erasure Coding

Задайте пару ключей доступа один раз в переменных zakroma_zds_access_key и zakroma_zds_secret_key. Блоки server, cluster_server и client используют эти значения. При необходимости также измените интерфейсы, порты и параметры TLS.

Copy
1# Укажите учётные данные ZDS один раз.
2zakroma_zds_access_key: "<ZDS_ACCESS_KEY>"
3zakroma_zds_secret_key: "<ZDS_SECRET_KEY>"
4
5zakroma_zds_protocol_prefix: "http://"
6
7zakroma_zds_server:
8  host: "0.0.0.0"
9  port: 8088
10  accessKey: "{{ zakroma_zds_access_key }}"
11  secretKey: "{{ zakroma_zds_secret_key }}"
12  tls:
13    enable: false
14    key: "/etc/zakroma/ssl/server.key"
15    crt: "/etc/zakroma/ssl/server.crt"
16
17zakroma_zds_publicServer_interface: ""
18
19zakroma_zds_cluster_server:
20  host: "0.0.0.0"
21  interface: ""
22  port: 8089
23  accessKey: "{{ zakroma_zds_access_key }}"
24  secretKey: "{{ zakroma_zds_secret_key }}"
25  tls:
26    enable: false
27    key: "/etc/zakroma/ssl/cluster.key"
28    crt: "/etc/zakroma/ssl/cluster.crt"
29
30zakroma_zds_client:
31  # Определите параметры доступа к ZDS (только для доступа сервиса Закрома.Хранение и для внутрикластерного взаимодействия)
32  accessKey: "{{ zakroma_zds_access_key }}"
33  secretKey: "{{ zakroma_zds_secret_key }}"
34
35zakroma_zds_providers:
36  # В данной секции задаются параметры по умолчанию для текущего хранилища.
37  # Их всегда можно переопределить для нового бакета через Admin UI
38  ec:
39    dataPart: 2
40    parityPart: 1
41    cleanup: false

Разделение публичного и кластерного трафика

zakroma_zds_publicServer_interface задаёт интерфейс, IPv4-адрес которого роль использует в nodes.hostPort для основного API ZDS на порту 8088. Если значение оставить пустым, роль использует ansible_default_ipv4.address.

Чтобы вынести межузловой трафик на отдельный интерфейс и порт, задайте zakroma_zds_cluster_server.interface. В этом случае роль создаст отдельные clusterServer и nodes.clusterHostPort на порту 8089. Если значение оставить пустым, отдельный кластерный endpoint не создаётся и межузловые запросы выполняются через nodes.hostPort на порту 8088.

5.2. Настройка служебных каталогов и дисков

Пути ниже приведены как пример. Замените их фактическими точками монтирования, которые существуют на каждом узле с сервисом ZDS.

Copy
1zakroma_zds_background_window_jobs:
2  vacuum:
3    enabled: true
4    storePath: "/mnt/lvm1/system/vacuum-state"
5  scan:
6    enabled: true
7    storePath: "/mnt/lvm1/system/scan-state"
8  # Измените данные параметры в соответствии с инструкцией для подготовки узла и вашей конфигурации сервера
9
10zakroma_zds_registry:
11  path: "/mnt/lvm1/system/db"
12  # Измените данные параметры в соответствии с инструкцией для подготовки узла и вашей конфигурации сервера
13
14zakroma_zds_hosts_group_name: "zakroma-zds-v2-ec"
15
16zakroma_zds_drive:
17  # Измените данные параметры в соответствии с инструкцией для подготовки узла и вашей конфигурации сервера
18  list:
19    - index: 1
20      path: "/mnt/lvm2/data"
21      storageGroup: 1
22      storageClass: ""
23    - index: 2
24      path: "/mnt/lvm3/data"
25      storageGroup: 2
26      storageClass: "HDD"
27    - index: 3
28      path: "/mnt/lvm4/data"
29      storageGroup: 3
30      storageClass: "SSD"

6. Проверка конфигурации

Проверьте, что инвентарь и YAML-файлы корректно загружаются Ansible:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-inventory \
2  -i inventories/base-cluster/hosts \
3  --list >/dev/null

7. Распространение сертификатов и лицензии по узлам кластера

Выполните плейбук для распространения сертификатов на целевые узлы:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-copy-certificates.yml

На каждом узле проверьте файлы, владельца и права.

Copy
1sudo stat -c '%U:%G %a %n' /opt/certs/zakroma.crt /opt/certs/zakroma.key
2openssl x509 -in /opt/certs/zakroma.crt -noout -subject -issuer -dates

Ожидаются владелец zakroma, права 644 для сертификата и 600 для ключа. На управляющем сервере проверьте цепочку исходного сертификата с доверенным CA:

Copy
1openssl verify -CAfile <CA_CERTIFICATE> roles/certificates/files/zakroma.crt

Ожидаемый результат — roles/certificates/files/zakroma.crt: OK.

Поместите лицензию в files/zakroma-licence/licence и убедитесь, что файл существует:

Copy
1test -f files/zakroma-licence/licence

Скопируйте лицензию на узлы Закрома.Хранение:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-copy-licence-file.yml \
4  --ask-vault-pass

Проверьте на одном из узлов, что лицензия находится по пути из zakroma_storage_gateway.path_to_licence:

Copy
1sudo test -f /opt/zakroma/zakroma-storage-gateway/bin/licence

8. Preflight-проверки перед установкой

После распространения сертификатов и лицензии выполните preflight-проверку Закрома.Хранение, затем ZDS:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-zakroma-storage-preflight.yml
4
5ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
6  -i inventories/base-cluster/hosts \
7  playbooks/sample-play-zakroma-zdsv2-preflight.yml

Переходите к установке только после успешного выполнения обоих плейбуков. В PLAY RECAP для всех узлов должны быть unreachable=0 и failed=0.

8.1. Диагностика ошибок preflight

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

9. Установка Закрома.Хранение и сервиса ZDS

Установите сервисы Закрома.Хранение:

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

В выводе Ansible PLAY RECAP должны быть unreachable=0 и failed=0. До установки ZDS на каждом узле проверьте доступность сервисов Закрома.Хранение:

Copy
1sudo systemctl status --no-pager --full \
2  zakroma-storage-monolith.service \
3  zakroma-storage-gateway.service

Для обоих сервисов должно быть указано состояние Active: active (running) и время работы с момента запуска. После этого установите сервис ZDS:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-zakroma-zds-v2-ec.yml

В выводе Ansible PLAY RECAP должны быть unreachable=0 и failed=0. На каждом узле проверьте сервис ZDS:

Copy
1sudo systemctl status --no-pager --full zakroma-ds-agent.service

Ожидаемое состояние — Active: active (running) с указанием времени работы сервиса.

После установки сервиса ZDS Ansible выводит адреса подключения ZDS к Закрома.Хранение:

Copy
1TASK [zakroma-zds : Вывод адресов подключения к ZDS] ***************************
2ok: [rutherford-2] => {
3    "msg": "Адреса подключения к ZDS: 192.168.1.2:8088, 192.168.1.3:8088, 192.168.1.4:8088"
4}

Скопируйте эти адреса: они понадобятся при добавлении кластера ZDS в Admin UI.

Проверка готовности

10. Проверка работоспособности сервисов и API

На каждом узле кластера выполните:

Copy
1sudo systemctl status --no-pager --full \
2  zakroma-storage-monolith.service \
3  zakroma-storage-gateway.service \
4  zakroma-ds-agent.service

Для каждого сервиса ожидаются Active: active (running) и состояние автозапуска enabled в строке Loaded. Значение preset не заменяет проверку текущего состояния автозапуска.

Проверьте, что Admin UI открывается по настроенному FQDN. Подробная проверка сервисов приведена в Проверке статуса сервисов.

11. Функциональная проверка S3

Откройте Admin UI по настроенному FQDN и подключите кластер ZDS, указав адреса подключения из вывода Ansible на шаге 9. Затем создайте рабочую область, бакет, разрешающую политику и S3-ключ тестового пользователя. Для проверки используйте отдельный тестовый объект, который после проверки можно удалить.

Передайте секретный ключ интерактивно:

Copy
1export AWS_ACCESS_KEY_ID='<S3_ACCESS_KEY>'
2read -rsp 'AWS Secret Access Key: ' AWS_SECRET_ACCESS_KEY
3export AWS_SECRET_ACCESS_KEY
4echo
5export S3_ENDPOINT='https://<WORKSPACE_FQDN>:<S3_API_PORT>'
6export S3_BUCKET='<TEST_BUCKET>'
7AWS_TLS_OPTION=''

Самоподписанный сертификат

Если S3 API использует самоподписанный сертификат, перед проверкой добавьте переменную среды AWS_TLS_OPTION='--no-verify-ssl'. Параметр отключает для AWS CLI проверку сертификата сервера, поэтому используйте его только для функционального теста. Для сертификата от доверенного центра сертификации оставьте переменную пустой.

Загрузите объект, проверьте его наличие, скачайте, сравните и удалите:

Copy
1object="base-cluster-$(date +%s).txt"
2printf 'S3 functional check\n' >/tmp/zakroma-s3-source.txt
3aws ${AWS_TLS_OPTION} --endpoint-url "$S3_ENDPOINT" s3 cp /tmp/zakroma-s3-source.txt "s3://${S3_BUCKET}/${object}"
4aws ${AWS_TLS_OPTION} --endpoint-url "$S3_ENDPOINT" s3 ls "s3://${S3_BUCKET}/${object}"
5aws ${AWS_TLS_OPTION} --endpoint-url "$S3_ENDPOINT" s3 cp "s3://${S3_BUCKET}/${object}" /tmp/zakroma-s3-downloaded.txt
6cmp /tmp/zakroma-s3-source.txt /tmp/zakroma-s3-downloaded.txt
7aws ${AWS_TLS_OPTION} --endpoint-url "$S3_ENDPOINT" s3 rm "s3://${S3_BUCKET}/${object}"
8rm -f /tmp/zakroma-s3-source.txt /tmp/zakroma-s3-downloaded.txt
9unset AWS_SECRET_ACCESS_KEY
10unset AWS_TLS_OPTION

Проверка успешна, если cmp не вывел различий, а объект удалён из бакета.

12. Повторный запуск и проверка идемпотентности

Повторно выполните плейбуки установки с тем же инвентарём Ansible и переменными group_vars:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/base-cluster/hosts \
3  playbooks/sample-play-zakroma-storage.yml
4
5ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
6  -i inventories/base-cluster/hosts \
7  playbooks/sample-play-zakroma-zds-v2-ec.yml

Успешный результат повторного запуска:

• в PLAY RECAP нет failed и unreachable;
• сервисы и функциональный S3-тест остаются рабочими;
• изменения в PLAY RECAP объяснимы, например, перезапуском сервиса после реального изменения конфигурации.