Архитектура решения

ЗАКРОМА.Хранение

ЗАКРОМА.Хранение представляет собой гибридное объектное хранилище, совместимое с S3 API. Решение построено на микросервисной архитектуре для возможности масштабирования и высокой отказоустойчивости.

Отличительными особенностями решения является поддержка различных ресурсов хранения (сервера с дисками, другие S3, СХД, ленты, файловые системы) и возможность мгновенного расширения за счёт любого доступного ресурса хранения. Эта возможность обеспечивается за счет разделения управляющего слоя и слоя хранения. Благодаря такому подходу, решение поддерживает возможность создать неограниченное число классов хранения и объединить различные ресурсы хранения под одной крышей.

Компоненты приложения

Слой управления:

• Gateway -  сервис проверки входящего http(s) запроса, валидация, аутентификация через keycloak/LDAP, авторизация и перенаправление запроса в целевой сервис.
• Core - сервис хранения информации о структуре хранилища. Кэширует и обновляет управляющую информацию в БД.
• Worker – сервис работы с объектами. Обеспечивает работу с шардом БД.
• Composer – сервис управления, агрегирует информацию от Core и Worker, распределяет нагрузку по нескольким шардам БД.
• Admin UI – фронт-энд административной web-консоли для управления приложением. Взаимодействует с остальными сервисами через Gateway.
• Kafka (опционально) - менеджер очередей сообщений. Используется для записи аудит лога, механизма вебхуков и работы в мультикластерном режиме. Kafka позволяет включить этот функционал без потери производительности, обеспечивая асинхронное взаимодействие.
• Keycloak (опционально) – сервис получения списка пользователей, групп, интеграция с AD/SSO, аутентификация.

Слой хранения данных:

• Zakroma Data Strorage (ZDS) – Слой хранения поверх дисков с применением Erasure coding. Может быть развёрнут на серверах приложения или отдельно.

Слой хранения метаданных:

• PostgreSQL – хранение информации о структуре хранилища, объектах и метаданных объектов, политиках хранения, политиках доступа, настройках,  подключенных хранилищах. При росте количества объектов база данных шардируется средствами приложения и информация перераспределяется между шардами.

Варианты развертывания и установки

ЗАКРОМА.Хранение, состоящие из слоя управления, хранения данных и хранения метаданных возможно развернуть в нескольких вариантах, либо в их комбинации, где каждый слой располагается независимо от других.

• Kubernetes
• VM (виртуальные машины)
• BareMetal (физические сервера)

Установка, масштабирование и обновление происходит за счет автоматизации:

• для VM/BareMetal - в варианте бинарных пакетов, с помощью Ansible-ролей.
• для Kubernetes - в контейнерном варианте, с помощью Helm-chart.

По вариантам отказоустойчивого развёртывания выделяют следующие конфигурации:

• Одноузловая конфигурация (Single Node) для целей тестирования.
  • Простая конфигурация, без отказоустойчивости.
  • Подходит для целей тестирования.
• Многоузловая конфигурация в рамках одного кластера (Single Cluster) на одной площадке (например, на одном кластере Kubernetes).
  • Конфигурация, обеспечивающая отказоустойчивость в рамках площадки.
  • Катастрофаустойчивость можно реализовать за счёт бекапирования данных.
• Многоузловая конфигурация между несколькими кластерами (Stretched Cluster) на нескольких площадках (требуется 3 площадки)
  • Конфигурация, обеспечивающая отказоустойчивость и катастрофаустойчивость.
  • Требуется минимум 2 площадки для хранения данных и ещё одна для witness.
  • Возможна как синхронная, так и асинхронная репликация данных между площадками.
• Мультикластерная конфигурация (Multi Cluster) на нескольких площадках
  • Конфигурация, обеспечивающая отказоустойчивость и катастрофаустойчивость.
  • Возможна только асинхронная репликация данных между площадками.
  • Возможно независимое, не реплицируемое хранение данных на площадках.

Документация по установке

См. раздел DevOps

Варианты организации хранения данных

Место физического хранения файлов настраивается для каждого бакета независимо с помощью политик хранения, которые можно комбинировать между собой.

• Зеркалирование - это синхронная или асинхронная репликация объектов бакета на несколько Хранилищ.
• Расширение позволяет увеличить ёмкость бакета за счёт подключения нового хранилища. Для бизнес-приложений бакет будет выглядеть единым местом хранения, а операция расширения не требует остановки бизнес-приложений.

API

Хранилище обладает следующими интерфейсами:

• S3 API – основное API в соответствии с AWS S3.
• REST API – управляющее API. Используется в Admin UI и для автоматизации.
• CLI – командный интерфейс. Более полная поддержка операций через собственное консольное приложение zcli.

Управление доступом

В системе ЗАКРОМА.Хранение используется сервис Keycloak, обеспечивающий интеграцию с корпоративной службой каталогов AD/SSO. Это даёт возможность использовать существующую корпоративную систему управления пользователями для администрирования учётных записей и групп.

В системе различается управление доступом по видам:

• Администраторы приложения. Для администраторов приложения можно создавать и назначать роли, ограничивающие доступ к операциям в консоли администрирования. Это позволяет гибко разграничивать полномочия — например, можно выделить роль Сотрудник по ИБ и предоставить ей доступ только к журналу операций.
  Дополнительно, на уровне рабочих областей (тенантов) и отдельных бакетов можно назначать локальных администраторов, ответственных только за управление соответствующими объектами.
• Пользователи S3. Для использования S3 API у пользователя должен быть действующий access/secret token, а также права доступа на операции, указанные в Политике доступа для соответствующей рабочей области (тенанта) или бакета.

Управление политиками доступа обеспечивает гораздо более широкие возможности для настройки прав доступа, чем устаревшие списки доступа ACL.

Мониторинг

Встроенный мониторинг позволяет проанализировать работу фоновых процессов в хранилище. Для мониторинга нагрузки на хранилище в разрезе операций, тенантов и бакетов и другие метрики можно использовать стек Prometheus/Grafana. Для Grafana поставляются преднастроенные дашборды.

Мультикластерный режим работы

Ниже на схеме представлена концептуальная архитектурная схема работы решения, развёрнутого в двух датацентрах:

Каждый кластер обменивается событиями и объектами по реплицируемым рабочим областям (тенантам) или реплицируемым бакетам.

Каждый из кластеров может иметь собственные, отличающиеся политики хранения.

Стек технологий

• Golang (основной код приложения)
• Angular (admin-UI)
• Nginx (admin-UI, балансировка)
• PostgreSQL (хранение метаданных и политик, версия 16+)
• Kafka (опционально, нужна для асинхронных процессов)
• Keycloak (опционально)