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

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

Растянутый кластер — это расширение конфигурации базового кластера Закрома.Хранение, узлы которого размещены на двух площадках и используют одну общую базу данных 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 в этот сценарий не входят: группы keycloak, java и kafka в поставляемом инвентаре используются только при установке этих компонентов по аналогии с базовым кластером.

Kafka и сервис seclog

Kafka нужна для работы сервиса seclog, который в поставке выключен (zakroma_storage_seclog.enable: false). Если seclog требуется, установите Kafka ролями java и kafka по аналогии с разделом 2.3 статьи Установка мультикластера и задайте параметры подключения в zakroma_storage_kafka.

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

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

Все шесть экземпляров Закрома.Хранение используют одинаковую конфигурацию и одну БД. Любой экземпляр может принять клиентский запрос. На узлах каждой площадки работает HAProxy с keepalived: клиенты обращаются к VIP — S3 API на порту 443, Admin UI на порту 8443, — а HAProxy распределяет запросы между всеми шестью экземплярами Закрома.Хранение. TLS терминируется на узлах Закрома.Хранение. Каждый экземпляр должен иметь сетевой доступ к API обоих кластеров ZDS, поскольку политика бакета может записывать объект на обе площадки.

Выбор схемы VIP

В примере узлы площадок находятся в разных широковещательных доменах (L2), поэтому используются два VIP — по одному на площадку. Нагрузку между площадками распределяет внешний балансировщик, DNS-RR или GSLB, см. Рекомендации по балансировке.

Если площадки находятся в одном L2-домене, можно использовать один VIP для обеих площадок: задайте в haproxy-ha-site-1.yml и haproxy-ha-site-2.yml одинаковые haproxy_ha_keepalived_virtual_ip и haproxy_ha_keepalived_virtual_router_id, а haproxy_ha_keepalived_priority — уникальными на всех шести узлах.

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

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

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

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

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

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

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

Установка

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

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

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

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

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

2. Инвентарь Ansible из поставки

Начиная с поставки 8.1.0 пример растянутого кластера входит в архив: используйте каталог inventories/stretched-cluster. Параметры двух независимых ZDS-кластеров задаются в файлах дочерних групп group_vars/zakroma-zds-site-1.yml и group_vars/zakroma-zds-site-2.yml, балансировщики площадок — в group_vars/haproxy-ha-site-1.yml и group_vars/haproxy-ha-site-2.yml. Файла group_vars/zakroma-zds-v2-ec.yml в этом инвентаре нет — не создавайте его.

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

Отредактируйте inventories/stretched-cluster/hosts: замените имена узлов и IP-адреса. Если Keycloak и Kafka не устанавливаются, удалите узел site1-keycloak-1 из группы certificates, а также группы keycloak, java и kafka.

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[haproxy-ha-site-1]
18site1-storage-1 ansible_host=192.0.2.11 haproxy_ha_keepalived_priority=110
19site1-storage-2 ansible_host=192.0.2.12 haproxy_ha_keepalived_priority=100
20site1-storage-3 ansible_host=192.0.2.13 haproxy_ha_keepalived_priority=90
21
22[haproxy-ha-site-2]
23site2-storage-1 ansible_host=198.51.100.11 haproxy_ha_keepalived_priority=110
24site2-storage-2 ansible_host=198.51.100.12 haproxy_ha_keepalived_priority=100
25site2-storage-3 ansible_host=198.51.100.13 haproxy_ha_keepalived_priority=90
26
27[haproxy-ha:children]
28haproxy-ha-site-1
29haproxy-ha-site-2
30
31[zakroma-zds-site-1]
32site1-storage-1 ansible_host=192.0.2.11 zakroma_zds_node_name=site1-storage-1
33site1-storage-2 ansible_host=192.0.2.12 zakroma_zds_node_name=site1-storage-2
34site1-storage-3 ansible_host=192.0.2.13 zakroma_zds_node_name=site1-storage-3
35
36[zakroma-zds-site-2]
37site2-storage-1 ansible_host=198.51.100.11 zakroma_zds_node_name=site2-storage-1
38site2-storage-2 ansible_host=198.51.100.12 zakroma_zds_node_name=site2-storage-2
39site2-storage-3 ansible_host=198.51.100.13 zakroma_zds_node_name=site2-storage-3
40
41[zakroma-zds-v2-ec:children]
42zakroma-zds-site-1
43zakroma-zds-site-2
44
45[zakroma-log-collector:children]
46zakroma-storage
47zakroma-zds-v2-ec

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

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

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

Исходный файл содержит блок узла site1-keycloak-1 с файлами keycloak.crt и keycloak.key. Если Keycloak не устанавливается, удалите весь блок site1-keycloak-1 из host_cert_config. Для шести узлов Закрома.Хранение и ZDS измените при необходимости имена узлов, имена файлов, каталог назначения, владельца и права. В примере один комплект сертификата и ключа распространяется на все узлы Закрома.Хранение и 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. Не заменяйте файл приведёнными ниже фрагментами целиком: сохраните остальные параметры поставки и измените только перечисленные параметры. Общий файл применяется ко всем шести узлам Закрома.Хранение.

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

Copy
1zakroma_storage_admin_version: 2.10.1
2zakroma_storage_version: 2.10.1

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-vault. Пример шифрования пароля PostgreSQL:

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

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

После ввода пароля Vault введите значение переменной и, не нажимая Enter, нажмите Ctrl+D — так в значение не попадёт перевод строки.

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

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: 8443
9
10zakroma_storage_base_domain: "<BASE_DOMAIN>"
11
12zakroma_storage_gateway:
13  s3api_port: 6443
14  management_port: 8444
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-monolith/bin/licence"
22  default_admin: "<LOCAL_ADMIN>"
23  auth:
24    auth_provider: file
25    user_provider: file
26    users:
27      - name: "<LOCAL_ADMIN>"
28        password: "<LOCAL_ADMIN_PASSWORD>"
29        groups:
30          - clouduser
31# Группа clouduser указана в качестве примера.
32
33zakroma_storage_cdn:
34  enable: false

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

5.3. Настройка ключей шифрования данных в БД

Для новой инсталляции задайте ключи шифрования данных в БД scrambler_keys в блоках zakroma_storage_gateway и zakroma_storage_core, а при использовании сервиса notification — и в zakroma_storage_notification, до первого запуска плейбука sample-play-zakroma-storage.yml. Порядок генерации ключа и ротации приведён в инструкции базового кластера. Если в существующей инсталляции ключи не использовались, оставьте scrambler_keys: []: записи в БД зашифровать уже нельзя. Все шесть экземпляров используют одну БД, поэтому ключи задаются один раз в общем файле zakroma-storage.yml.

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

Отредактируйте inventories/stretched-cluster/group_vars/zakroma-zds-site-2.yml. Файл поставки отличается от файла площадки 1 только ключами доступа и именем группы:

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. Настройка балансировщиков площадок

На каждой площадке HAProxy с keepalived устанавливается на три узла Закрома.Хранение. Ниже приведены значения для схемы с отдельным VIP на каждой площадке; для общего L2-сегмента используйте один VIP по разделу «Выбор схемы VIP». Frontend-ы уже описаны в haproxy_ha_frontends и получают порты из переменных в zakroma-storage.yml; на обеих площадках HAProxy распределяет запросы между всеми шестью узлами группы zakroma-storage.

Отредактируйте inventories/stretched-cluster/group_vars/haproxy-ha-site-1.yml и inventories/stretched-cluster/group_vars/haproxy-ha-site-2.yml. Измените только параметры keepalived:

Зашифруйте пароль VRRP и добавьте полученный блок в оба файла:

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

Если вместо haproxy-ha используется внешний балансировщик, см. Рекомендации по балансировке.

9. Проверка инвентаря 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 и haproxy-ha должны содержать по две дочерние группы по три узла, а 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-кластеров.

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

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

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-monolith/bin/licence

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

11. 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-zds-v2-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-zds-v2-preflight.yml \
13  --limit zakroma-zds-site-2

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

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

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

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

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'

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

13. Последовательная установка 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

Установите балансировщики обеих площадок:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
2  -i inventories/stretched-cluster/hosts \
3  playbooks/sample-play-haproxy-ha.yml \
4  --ask-vault-pass

В PLAY RECAP для всех шести узлов должны быть unreachable=0 и failed=0. Убедитесь, что каждый VIP назначен ровно одному узлу — узлу с наибольшим haproxy_ha_keepalived_priority в его VRRP-группе:

Copy
1ANSIBLE_CONFIG=ansible.cfg ansible \
2  -i inventories/stretched-cluster/hosts haproxy-ha \
3  -m command -a 'ip -brief address show'

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

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

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

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

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

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

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

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

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

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

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

Copy
1sudo systemctl status --no-pager --full \
2  zakroma-storage-monolith.service \
3  zakroma-ds-agent.service \
4  haproxy.service \
5  keepalived.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. Подробная проверка сервисов приведена в Проверке статуса сервисов.

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

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

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 убедитесь, что оба хранилища группы доступны и объект записан без ошибок зеркалирования.

18. Проверка недоступности 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

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

Повторно выполните плейбуки с теми же инвентарём 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
14
15ANSIBLE_CONFIG=ansible.cfg ansible-playbook \
16  -i inventories/stretched-cluster/hosts \
17  playbooks/sample-play-haproxy-ha.yml \
18  --ask-vault-pass

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

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

После шагов 16–19 сверьте результаты с таблицей.