Установка растянутого кластера

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

Растянутый кластер — это расширение конфигурации базового кластера Закрома.Хранение, узлы которого размещены на двух площадках и используют одну общую базу данных PostgreSQL.

На каждой площадке работает отдельный трёхузловой кластер ZDS. В примере используется схема Erasure Coding 2+1. Узлы разных площадок не входят в один кластер ZDS и не обмениваются межузловым трафиком ZDS. Связь между площадками на уровне данных организуется политикой зеркалирования Закрома.Хранение.

Для бакета создаётся группа хранения на ZDS-хранилище одной площадки, а ZDS-хранилище второй площадки добавляется в эту группу в качестве синхронного зеркала с помощью политики «Зеркалирование». Минимальное количество хранилищ, в которые запись должна завершиться успешно (MIN SIZE), задаётся равным одному. При штатной работе Закрома.Хранение записывает объект на обе площадки. При недоступности одной площадки запрос завершается после успешной записи в доступное хранилище, а недостающая копия дореплицируется фоновой проверкой после восстановления связи.

PostgreSQL — единая точка отказа

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

Если PostgreSQL недоступен, отказоустойчивость двух площадок ZDS и значение MIN SIZE = 1 не обеспечивают работоспособность единого управляющего кластера. Если сервер размещён на одной из площадок, отказ этой площадки останавливает весь кластер. Отказоустойчивый кластер PostgreSQL должен оставаться доступным при отказе любой из площадок и предоставлять всем узлам единый адрес подключения.

Сеть между площадками

Синхронное зеркалирование увеличивает задержку записи при доступности обеих площадок. Пропускную способность, задержку, тайм-ауты и поведение канала при потере пакетов необходимо проверить нагрузочным тестированием до ввода системы в эксплуатацию.

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

В базовом варианте используются локальные пользователи. Kafka, CDN, Keycloak, LDAP и Nginx в этот сценарий не входят.

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

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

Все шесть экземпляров Закрома.Хранение используют одинаковую конфигурацию и одну БД. Любой экземпляр может принять клиентский запрос. Каждый экземпляр должен иметь сетевой доступ к API обоих кластеров ZDS, поскольку политика бакета может записывать объект на обе площадки.

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

Подробные требования к ОС, дискам, DNS и сертификатам приведены в Подготовке окружения.

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

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

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

Сетевые взаимодействия

В текущей конфигурации кластерный трафик ZDS может быть изолирован в рамках одного датацентра/площадки. Экземплярам Закрома.Хранение необходим доступ между площадками к API удалённого ZDS на порту 8088.

Установка

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

Copy
1RELEASE_VERSION=7.2.4
2tar -xvzf "zakroma-roles-${RELEASE_VERSION}.tar.gz"
3cd "zakroma-roles-${RELEASE_VERSION}"

Проверьте наличие ansible.cfg, files, inventories, playbooks, requirements.yml.template и roles.

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

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

2. Создание каталога инвентаря Ansible

Создайте конфигурацию растянутого кластера из поставляемого базового примера. Файл параметров ZDS переименуйте в файл дочерней группы площадки 1; файл площадки 2 создаётся копированием уже настроенного файла на шаге 7:

Copy
1cp -a inventories/base-cluster inventories/stretched-cluster
2mv inventories/stretched-cluster/group_vars/zakroma-zds-v2-ec.yml \
3  inventories/stretched-cluster/group_vars/zakroma-zds-site-1.yml

Файл group_vars/zakroma-zds-v2-ec.yml в новом инвентаре Ansible оставаться не должен: параметры двух независимых ZDS-кластеров задаются в файлах дочерних групп. Остальные файлы group_vars базового примера (Keycloak, Kafka, Nginx) не применяются, так как их групп нет в инвентаре растянутого кластера.

3. Настройка инвентаря Ansible

Замените содержимое inventories/stretched-cluster/hosts:

Copy
1[certificates]
2site1-storage-1 ansible_host=192.0.2.11
3site1-storage-2 ansible_host=192.0.2.12
4site1-storage-3 ansible_host=192.0.2.13
5site2-storage-1 ansible_host=198.51.100.11
6site2-storage-2 ansible_host=198.51.100.12
7site2-storage-3 ansible_host=198.51.100.13
8
9[zakroma-storage]
10site1-storage-1 ansible_host=192.0.2.11
11site1-storage-2 ansible_host=192.0.2.12
12site1-storage-3 ansible_host=192.0.2.13
13site2-storage-1 ansible_host=198.51.100.11
14site2-storage-2 ansible_host=198.51.100.12
15site2-storage-3 ansible_host=198.51.100.13
16
17[zakroma-zds-site-1]
18site1-storage-1 ansible_host=192.0.2.11 zakroma_zds_node_name=site1-storage-1
19site1-storage-2 ansible_host=192.0.2.12 zakroma_zds_node_name=site1-storage-2
20site1-storage-3 ansible_host=192.0.2.13 zakroma_zds_node_name=site1-storage-3
21
22[zakroma-zds-site-2]
23site2-storage-1 ansible_host=198.51.100.11 zakroma_zds_node_name=site2-storage-1
24site2-storage-2 ansible_host=198.51.100.12 zakroma_zds_node_name=site2-storage-2
25site2-storage-3 ansible_host=198.51.100.13 zakroma_zds_node_name=site2-storage-3
26
27[zakroma-zds-v2-ec:children]
28zakroma-zds-site-1
29zakroma-zds-site-2

Группа [zakroma-zds-v2-ec] остаётся целью штатных плейбуков. Дочерние группы передают каждому узлу конфигурацию только его площадки.

4. Настройка сертификатов

Поместите сертификат и ключ в каталог roles/certificates/files/ в корне распакованной поставки на управляющем сервере. Затем отредактируйте inventories/stretched-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  site1-storage-1: # имя из инвентаря Ansible
Развернуть

5. Настройка общей конфигурации Закрома.Хранение

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

В примере используются версии из поставки 7.2.4:

Copy
1zakroma_storage_admin_version: 2.9.4
2zakroma_storage_gateway_version: 2.9.4
3zakroma_storage_version: 2.9.4

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

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

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

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

Copy
1zakroma_storage_postgresql_host: "postgresql.zakroma.internal"
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 ключ из примера в разделе распространения лицензии.

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

Измените FQDN Admin UI, базовый домен, параметры TLS и учётную запись локального администратора. Пути сертификата и ключа должны совпадать с указанными в шаге 4. Остальные параметры внутри zakroma_storage_gateway, включая ссылки на общие параметры PostgreSQL, сохраните.

Copy
1# Оставьте false, если требования systemd-credentials не проверены.
2zakroma_storage_config_encrypt: false
3
4zakroma_storage_admin:
5  path: "<ADMIN_UI_FQDN>"
6  reverse_proxy:
7    enabled: true
8    port: 443
9
10zakroma_storage_base_domain: "<BASE_DOMAIN>"
11
12zakroma_storage_gateway:
13  host: "<GATEWAY_FQDN>"
14  s3api_port: 8443
15  management_port: 6443
16  admin_console_location: "/opt/zakroma/zakroma-storage-admin/frontend/dist/admin-ui/"
17  tls:
18    enabled: true
19    certs:
20      - key: "/opt/certs/zakroma.key"
21        crt: "/opt/certs/zakroma.crt"
22  path_to_licence: "/opt/zakroma/zakroma-storage-gateway/bin/licence"
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 указана в качестве примера.
33
34zakroma_storage_cdn:
35  enable: false

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

Настройка внешнего балансировщика описана в статье Рекомендации по балансировке.

6. Настройка ZDS площадки 1

Отредактируйте inventories/stretched-cluster/group_vars/zakroma-zds-site-1.yml. Остальные параметры поставки оставьте без изменений.

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

Задайте пару ключей площадки 1 в переменных zakroma_zds_access_key и zakroma_zds_secret_key. Блоки server, cluster_server и client используют эти значения. В примере API работает по HTTP, а схема Erasure Coding задана как 2+1.

Copy
1zakroma_zds_version: 2.1.1
2
3zakroma_zds_access_key: "<SITE1_ZDS_ACCESS_KEY>"
4zakroma_zds_secret_key: "<SITE1_ZDS_SECRET_KEY>"
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  accessKey: "{{ zakroma_zds_access_key }}"
32  secretKey: "{{ zakroma_zds_secret_key }}"
33
34zakroma_zds_providers:
35  ec:
36    dataPart: 2
37    parityPart: 1
38    cleanup: false
39
40zakroma_zds_hosts_group_name: "zakroma-zds-site-1"

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

Укажите существующие каталоги для служебного состояния, реестра БД и данных. Пути в примере должны соответствовать подготовленным точкам монтирования на каждом из трёх узлов площадки 1.

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
9zakroma_zds_registry:
10  path: "/mnt/lvm1/system/db"
11
12zakroma_zds_drive:
13  defaultStorageClass: "HDD"
14  list:
15    - index: 1
16      path: "/mnt/lvm2/data"
17      storageGroup: 1
18      storageClass: "HDD"

Схема EC 2+1 требует не менее трёх доступных дисков в одной группе дисков storageGroup. В примере каждый из трёх узлов площадки предоставляет диск с storageGroup: 1.

7. Настройка ZDS площадки 2

Скопируйте настроенный файл площадки 1 и измените в копии только параметры, которые отличают площадку 2:

Copy
1cp inventories/stretched-cluster/group_vars/zakroma-zds-site-1.yml \
2  inventories/stretched-cluster/group_vars/zakroma-zds-site-2.yml

Copy
1zakroma_zds_access_key: "<SITE2_ZDS_ACCESS_KEY>"
2zakroma_zds_secret_key: "<SITE2_ZDS_SECRET_KEY>"
3zakroma_zds_hosts_group_name: "zakroma-zds-site-2"

Версия, схема EC, служебные каталоги и диски остаются такими же, как на площадке 1, если оборудование площадок идентично. При других точках монтирования измените zakroma_zds_registry, zakroma_zds_background_window_jobs и zakroma_zds_drive.list. Ключи площадок рекомендуется делать разными. Список узлов каждой площадки определяется только её группой в инвентаре Ansible: в конфигурации площадки 2 не должны присутствовать узлы площадки 1, и наоборот.

8. Проверка инвентаря Ansible и узлов

Проверьте иерархию групп и доступность узлов:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-inventory \
2  -i inventories/stretched-cluster/hosts --graph
3
4ANSIBLE_CONFIG=ansible.cfg ansible \
5  -i inventories/stretched-cluster/hosts all -m ping

В выводе графа родительская группа zakroma-zds-v2-ec должна содержать две дочерние группы по три узла, а zakroma-storage — все шесть узлов.

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

Проверьте имена узлов:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible \
2  -i inventories/stretched-cluster/hosts zakroma-zds-v2-ec \
3  -m setup -a 'filter=ansible_hostname'

Значения zakroma_zds_node_name должны совпадать с выбранными постоянными именами и быть уникальными в пределах своих ZDS-кластеров.

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

На управляющем сервере из корня распакованной поставки выполните плейбук для распространения сертификатов:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/stretched-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:zakroma, права 644 для сертификата и 600 для ключа. Команда openssl x509 должна показать ожидаемые значения субъекта и издателя сертификата, а текущая дата должна входить в срок его действия.

На управляющем сервере проверьте цепочку исходного сертификата с доверенным CA. Вместо <CA_CERTIFICATE> укажите путь к файлу сертификата центра сертификации:

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

Команда должна завершиться с кодом 0. Затем скопируйте лицензию на все шесть узлов Закрома.Хранение:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/stretched-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

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

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

Сначала проверьте общий слой Закрома.Хранение, затем каждую площадку ZDS отдельно:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/stretched-cluster/hosts \
3  playbooks/sample-play-zakroma-storage-preflight.yml
4
5ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
6  -i inventories/stretched-cluster/hosts \
7  playbooks/sample-play-zakroma-zdsv2-preflight.yml \
8  --limit zakroma-zds-site-1
9
10ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
11  -i inventories/stretched-cluster/hosts \
12  playbooks/sample-play-zakroma-zdsv2-preflight.yml \
13  --limit zakroma-zds-site-2

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

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

Если preflight завершился ошибкой, определите проблемный узел и параметр по сообщению Ansible. Команды из таблицы выполняйте на проблемном узле; вместо <POSTGRESQL_FQDN> и <POSTGRESQL_USER> укажите значения из zakroma-storage.yml. В примере используются порт 5432, база zakroma и пути ZDS из шага 6 — замените их в командах, если изменяли конфигурацию.

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

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

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

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible \
2  -i inventories/stretched-cluster/hosts zakroma-storage \
3  -b -m command -a 'systemctl status --no-pager --full zakroma-storage-monolith.service zakroma-storage-gateway.service'

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

12. Последовательная установка ZDS

Установите и проверьте площадку 1:

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

В PLAY RECAP для трёх узлов площадки должны быть unreachable=0 и failed=0. Проверьте сервис ZDS на узлах площадки 1:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible \
2  -i inventories/stretched-cluster/hosts zakroma-zds-site-1 \
3  -b -m command -a 'systemctl status --no-pager --full zakroma-ds-agent.service'

На каждом из трёх узлов ожидается состояние Active: active (running) с указанием времени работы сервиса. После успешной проверки установите площадку 2:

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

В PLAY RECAP для трёх узлов площадки должны быть unreachable=0 и failed=0. Проверьте сервис ZDS на узлах площадки 2:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible \
2  -i inventories/stretched-cluster/hosts zakroma-zds-site-2 \
3  -b -m command -a 'systemctl status --no-pager --full zakroma-ds-agent.service'

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

Задача «Вывод адресов подключения к ZDS» выполняется один раз за запуск плейбука, поэтому запуск по площадкам с --limit даёт отдельный список адресов для каждой площадки. Сохраните оба списка. Для примера это:

Copy
1site-1: 192.0.2.11:8088, 192.0.2.12:8088, 192.0.2.13:8088
2site-2: 198.51.100.11:8088, 198.51.100.12:8088, 198.51.100.13:8088

Настройка зеркалирования

13. Регистрация двух ZDS-хранилищ

В Admin UI откройте раздел Хранилища и создайте два хранилища типа ZDS версии v2.

При включении TLS в ZDS укажите HTTPS, включите проверку SSL и настройте доверенную цепочку сертификатов. Подробнее о регистрации см. Хранилища.

14. Создание группы хранения с синхронным зеркалом

Создайте тестовую рабочую область и бакет, затем откройте Настройки хранения бакета:

1. Нажмите Добавить группу хранения. В поле Хранилище выберите zds-site-1, укажите класс хранения HDD и схему хранения EC 2+1, сохраните группу.
2. Для созданной группы раскройте Политики хранения и в политике Зеркалирование нажмите Добавить хранилище. Выберите zds-site-2 и укажите тот же класс и схему хранения.
3. В контекстном меню добавленного хранилища включите переключатель Синхронно.
4. Установите минимальное количество хранилищ, в которые запись должна завершиться успешно, равным одному (MIN SIZE = 1, параметр minSize политики).
5. Дождитесь зелёного статуса доступности обоих хранилищ.

При такой конфигурации объект записывается на обе площадки, но для успешного ответа клиенту достаточно одной завершённой записи. Порядок создания группы описан в статье Настройка хранения бакета, поведение синхронных зеркал и параметра MIN SIZE — в статье Зеркалирование.

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

15. Проверка сервисов и состава ZDS-кластеров

На всех шести узлах проверьте systemd-сервисы:

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

Проверьте готовность каждого ZDS-кластера:

Copy
1curl -fsS -o /dev/null -w '%{http_code}\n' http://192.0.2.11:8088/readyz
2curl -fsS -o /dev/null -w '%{http_code}\n' http://198.51.100.11:8088/readyz

Обе команды должны вернуть HTTP 200.

Проверьте состав кластеров через /inner/status, используя ключи соответствующей площадки:

Copy
1curl -s -u '<SITE1_ZDS_ACCESS_KEY>:<SITE1_ZDS_SECRET_KEY>' http://192.0.2.11:8088/inner/status | jq '.nodeName, .nodes[].name'
2curl -s -u '<SITE2_ZDS_ACCESS_KEY>:<SITE2_ZDS_SECRET_KEY>' http://198.51.100.11:8088/inner/status | jq '.nodeName, .nodes[].name'

В ответе площадки 1 должны быть только site1-storage-1–site1-storage-3, а в ответе площадки 2 — только site2-storage-1–site2-storage-3. Подробная проверка сервисов приведена в Проверке статуса сервисов.

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

Создайте S3-ключ тестового пользователя и передайте секрет интерактивно. Для подключения используйте адрес S3 API на внешнем балансировщике; если внешний порт отличается от 443, добавьте его к S3_ENDPOINT:

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>'
6export S3_BUCKET='<TEST_BUCKET>'
7AWS_TLS_OPTION=''

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

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

Загрузите и прочитайте тестовый объект:

Copy
1object="stretched-cluster-$(date +%s).txt"
2printf 'Stretched cluster functional check\n' >/tmp/zakroma-stretched-source.txt
3aws ${AWS_TLS_OPTION} --endpoint-url "$S3_ENDPOINT" s3 cp \
4  /tmp/zakroma-stretched-source.txt "s3://${S3_BUCKET}/${object}"
5aws ${AWS_TLS_OPTION} --endpoint-url "$S3_ENDPOINT" s3 cp \
6  "s3://${S3_BUCKET}/${object}" /tmp/zakroma-stretched-downloaded.txt
7cmp /tmp/zakroma-stretched-source.txt /tmp/zakroma-stretched-downloaded.txt

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

17. Проверка недоступности ZDS одной площадки

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

1. Убедитесь, что исходный объект синхронизирован на обе площадки.
2. Штатными средствами тестовой инфраструктуры сделайте ZDS площадки 2 недоступным для узлов Закрома.Хранение, например запретив на межсетевом экране трафик к порту 8088/tcp узлов площадки 2.
3. Загрузите новый объект той же командой aws s3 cp. При MIN SIZE = 1 операция должна завершиться успешно записью на площадку 1.
4. Восстановите доступность площадки 2.
5. Дождитесь завершения фоновой проверки и восстановления зеркал.
6. Убедитесь в Admin UI, что оба хранилища снова доступны и для нового объекта отсутствуют ошибки синхронизации.
7. Повторите проверку в обратном направлении для площадки 1.

Если запись прекращается при недоступности одного хранилища, проверьте, что зеркало помечено как синхронное, а MIN SIZE группы равен 1, а не 2.

После проверки удалите тестовые объекты и переменные окружения:

Copy
1aws ${AWS_TLS_OPTION} --endpoint-url "$S3_ENDPOINT" s3 rm "s3://${S3_BUCKET}/${object}"
2rm -f /tmp/zakroma-stretched-source.txt /tmp/zakroma-stretched-downloaded.txt
3unset AWS_SECRET_ACCESS_KEY AWS_TLS_OPTION

18. Проверка идемпотентности

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

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/stretched-cluster/hosts \
3  playbooks/sample-play-zakroma-storage.yml
4
5ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
6  -i inventories/stretched-cluster/hosts \
7  playbooks/sample-play-zakroma-zds-v2-ec.yml \
8  --limit zakroma-zds-site-1
9
10ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
11  -i inventories/stretched-cluster/hosts \
12  playbooks/sample-play-zakroma-zds-v2-ec.yml \
13  --limit zakroma-zds-site-2

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

Итоговая проверка установки

После выполнения шагов 15–18 сверьте результаты с таблицей. Проверка недоступности площадки относится к её ZDS при работающих экземплярах Закрома.Хранение и доступной базе данных PostgreSQL; полный отказ инфраструктуры площадки в этот сценарий не входит.