Архитектура решения
Управляющий слой и слой хранения данных
Закрома.Хранение состоит из двух независимо разворачиваемых сервисов в K8S и соответствующих Helm-чартов:
- Zakroma-Storage — управляющий слой: S3 API, Admin UI, обработка запросов, метаданных и фоновых задач.
- Zakroma-ZDS — слой хранения содержимого объектов. Узлы ZDS используют постоянные тома (PV) для формирования отказоустойчивого программно-определяемого хранилища.
Способ установки одного слоя не определяет способ установки другого. Zakroma-Storage и ZDS могут работать в Kubernetes, непосредственно на физических серверах или на виртуальных машинах. Возможны как совместное размещение сервисов на одних узлах, так и их разделение между разными узлами и инфраструктурными платформами.
При этом Kubernetes сам может быть развёрнут на физических серверах или виртуальных машинах.
Варианты размещения
| Zakroma-Storage | ZDS | Особенности |
|---|---|---|
| Kubernetes | Kubernetes | Отдельные Helm-релизы могут использовать разные неймспейсы, поддерживается множество инсталляций в рамках одного кластера K8s. ZDS использует постоянные тома (PV) для формирования кластера и хранения данных |
| Kubernetes | Физические серверы или виртуальные машины | Управляющий слой работает в подах, а ZDS — на выделенной аппаратной платформе с физическими дисками. Закрома.Хранение подключается к внешним адресам API ZDS. |
| Физические серверы или виртуальные машины | Физические серверы или виртуальные машины | Возможны отдельные либо совмещённые узлы Storage/ZDS; физические и виртуальные узлы можно использовать для разных слоёв. |
В одном из вариантов раздельной инсталляции Закрома.Хранение можно установить в Kubernetes, а ZDS — на трёх физических серверах с локальными дисками и EC 2+1 или с использованием репликации. PostgreSQL остаётся отдельной зависимостью сервисов Закрома.Хранение. Пользователи обращаются к Admin UI и S3 через Ingress, а компоненты Закрома.Хранение направляют запросы к внешним API-адресам ZDS. Узлы ZDS обмениваются данными между собой по отдельной сети. Helm-чарт Закрома.Хранение не устанавливает и не обслуживает физические узлы ZDS.
Поддерживается установка компонентов в разные Kubernetes-кластеры для Закрома.Хранение и ZDS, если между ними обеспечены необходимые сетевые связи. Перенос данных между кластерами ZDS и между платформами возможен из Admin-UI Закрома.Хранение.
Зависимости и сетевые связи
| Компонент или связь | Требование |
|---|---|
| PostgreSQL | Доступен компонентам Закрома.Хранение независимо от их размещения. Для продуктивной установки нужна отказоустойчивая конфигурация и расчёт ресурсов/подключений. |
| Входящий доступ к Закрома.Хранение | Для Kubernetes обычно используется готовый Ingress Controller; для стандартной установки — выбранная схема балансировки. Настройки TLS, Host, URI и заголовков должны сохранять работоспособность S3. |
| Закрома.Хранение → ZDS | Все адреса подключения, указанные при регистрации хранилища, должны разрешаться и быть доступны из компонентов Закрома.Хранение. Используйте API-порт ZDS из конфигурации выбранной установки. |
| ZDS → ZDS | Узлы должны обращаться друг к другу по стабильным адресам и портам API/межузлового взаимодействия из конфигурации ZDS. |
| Хранилище ZDS | Для установки в ОС подготовьте диски и точки монтирования; для Kubernetes — подходящие StorageClass и постоянные тома. Оцените реальные общие точки отказа нижележащего хранилища. |
| LDAP или Keycloak | При выбранном внешнем источнике пользователей обеспечьте сетевой доступ из Gateway к LDAP/Keycloak и настройте доверие Gateway к цепочке TLS-сертификатов этого сервиса. |
| Kafka | Нужна для включённых сценариев SecLog, Notification/Webhooks, мультикластера и соответствующих фоновых функций. Для базового сценария с обработкой фоновых задач через БД не требуется. |
В базовом Kubernetes-сценарии Admin UI и Management API доступны по одному имени <ADMIN_UI_FQDN>. Для S3 используются адреса рабочих областей <WORKSPACE>.<BASE_DOMAIN> и wildcard-запись *.<BASE_DOMAIN>, направленная на Ingress. Отдельное внешнее имя Gateway не требуется; компонент Gateway продолжает обрабатывать запросы внутри кластера. Подготовка записей описана в Подготовке Ingress, DNS и TLS.
Внутренние имена *.svc.cluster.local и адреса ClusterIP предназначены для сети конкретного Kubernetes-кластера. Для смешанной схемы или разных кластеров заранее организуйте маршрутизацию, DNS и, при необходимости, публикацию API ZDS с устойчивыми адресами. Внутренний headless Service сам по себе не публикует ZDS наружу. Не открывайте кластерный API ZDS в интернет.
Не переносите номера портов между Helm и стандартной установкой автоматически: в рассматриваемом ZDS-чарте 3.1.0 API работает на 8080, межузловой сервер — на 8081; у установки в ОС значения могут отличаться. TLS и сетевые ограничения должны соответствовать выбранным границам доверия, особенно при выходе запросов из сети Kubernetes.
Выбор инструкции установки
- Закрома.Хранение в Kubernetes: Варианты установки Закрома.Хранение Helm 6.0.4. Базовый пример устанавливает оба слоя в Kubernetes; при внешнем ZDS пропустите его Helm-установку и используйте фактические адреса готового хранилища.
- ZDS в Kubernetes: Варианты установки ZDS Helm 3.1.0. Этот слой можно установить независимо от способа размещения Закрома.Хранение.
- Закрома.Хранение и ZDS на физических серверах или VM: Поставки стандартной установки. Используйте инструкции выбранных компонентов и не запускайте установку второго слоя повторно, если он уже развёрнут отдельно.
- Совместимость чартов и ПО: Таблица соответствия версий.