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

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

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

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

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

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

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

В примере используется один внешний 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-сертификат или сертификат с SAN для используемых FQDN. Требования к 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. Распространение сертификатов по узлам кластера

Поместите сертификат и ключ в каталог 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 оставьте соответствующим компоненту.

Чтобы не повторять параметры подключения, задайте общие переменные рядом с существующей переменной zakroma_storage_postgresql_host. Блоки компонентов ниже уже используют эти общие значения:

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"

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

Copy
1zakroma_storage_core:
2  postgresql_host: "{{ zakroma_storage_postgresql_host }}"
3  postgresql_port: "{{ zakroma_storage_postgresql_port }}"
4  postgresql_username: "{{ zakroma_storage_postgresql_username }}"
5  postgresql_password: "{{ zakroma_storage_postgresql_password }}"
6  postgresql_dbname: "{{ zakroma_storage_postgresql_dbname }}"
7  postgresql_schema_name: core
8  postgresql_sslmode: "{{ zakroma_storage_postgresql_sslmode }}"
9  postgresql_max_open_conns: "{{ zakroma_storage_postgresql_max_open_conns }}"
10  postgresql_max_idle_conns: "{{ zakroma_storage_postgresql_max_idle_conns }}"
11  postgresql_connection_timeout: "{{ zakroma_storage_postgresql_connection_timeout }}"
12  postgresql_target_session_attrs: "{{ zakroma_storage_postgresql_target_session_attrs }}"
13  # Остальные параметры zakroma_storage_core сохраните без изменений.

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

Для безопасной работы с конфигурациями 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_admin:
2  path: "<ADMIN_UI_FQDN>"
3
4zakroma_storage_nginx_proxy: false
5zakroma_storage_base_domain: "<BASE_DOMAIN>"
6
7zakroma_storage_gateway:
8  host: "<GATEWAY_FQDN>"
9  s3api_port: 8443
10  management_port: 6443
11  admin_console_location: "/opt/zakroma/zakroma-storage-admin/frontend/dist/admin-ui/"
12  tls:
13    enabled: true
14    certs:
15      - key: "/opt/certs/zakroma.key"
16        crt: "/opt/certs/zakroma.crt"
17  path_to_licence: "/opt/zakroma/zakroma-storage-gateway/bin/licence"
18
19  default_admin: "<LOCAL_ADMIN>"
20  auth:
21    auth_provider: file
22    user_provider: file
23    users:
24      - name: "<LOCAL_ADMIN>"
25        password: "<LOCAL_ADMIN_PASSWORD>"
26        groups:
27          - clouduser
28# Группа clouduser тут указана в качестве примера.

При использовании внешнего 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_cluster_server.interface сетевой интерфейс для межузлового взаимодействия. Если параметр оставить пустым, ZDS использует интерфейс по умолчанию.

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> files/zakroma.crt

Ожидаемый результат — 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.

Диагностика ошибок 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
1sleep 5
2sudo 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
5
6sudo systemctl is-enabled zakroma-storage-monolith.service
7sudo systemctl is-enabled zakroma-storage-gateway.service
8sudo systemctl is-enabled zakroma-ds-agent.service

Все сервисы должны иметь состояние Active: active (running), а команды проверки автозапуска — вернуть enabled.

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