logo

Частые вопросы

FAQ / Часто задаваемые вопросы

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

1. Являются ли настройки ZDS EC (например, 16:4) статическими?

Параметры схемы EC (Erasure coding) задаются при создании кластера и в текущей версии ZDS (v 1.x) не изменяются. Возможность изменения схемы появится в версии ZDS 2.1.

2. Как изменить схему EC или увеличить объём хранения?

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

Для увеличения объёма хранения изменение схемы EC не требуется – расширение выполняется за счёт добавления дисков.

Поддержка изменения схемы EC планируется в будущих версиях.

Мониторинг и метрики

1. Как посмотреть свободное место в хранилище?

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

Для использования:

  • необходимо подключить Prometheus к endpoint метрик;
  • для визуализации рекомендуется использовать Grafana с дашбордом из поставки.

2. Отдаёт ли ZDS информацию о свободном месте в метриках?

Да, ZDS возвращает информацию о свободном месте в своих метриках. Также в Мониторе отображаются предупреждения о нехватке места.

3. Поставляются ли Prometheus и Grafana вместе с решением?

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

Хранилища и группы хранения

1. Можно ли использовать резервное хранилище (failover, запись только при отказе основного)?

Подобный сценарий реализуется через механизм синхронных зеркал. Для обеспечения записи при частичной недоступности хранилищ используется конфигурация: два зеркала с параметром MIN SIZE = 1. См. Зеркалирование.

Поведение:

  • запись выполняется одновременно в оба хранилища
  • при отказе одного из хранилищ запись продолжается
  • при недоступности обоих хранилищ операция записи завершается ошибкой

2. Можно ли добавлять хранилища разного размера в группу?

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

3. Что происходит при переполнении одного из хранилищ?

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

  • запись объектов продолжается, пока хотя бы одно хранилище в группе остаётся доступным для записи
  • при исчерпании ёмкости хранилища, у которого не установлен предел ёмкости в параметрах группы хранения, возможна ошибка записи в бакет.

Особенности:

  • не все типы хранилищ корректно сигнализируют о достижении предельной ёмкости;
  • для ZDS информация о состоянии доступна через мониторинг.

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

Объекты записываются в группы хранения по приоритетам и с учетом политики жизненного цикла При загрузке. Далее объекты могут быть перемещены в другие группы хранения по правилам ЖЦ При хранении. Отображение места размещения конкретного объекта в настоящий момент не реализовано. Поддержка такой возможности появится в будущих версиях. См. Жизненный цикл.

Сайзинг

Есть ли публичный калькулятор сайзинга?

Нет, в настоящее время расчёт параметров системы рекомендуется выполнять сертифицированным интегратором. Это связано с тем, что конфигурация зависит от ряда факторов:

  • ожидаемой нагрузки (RPS);
  • размера объектов;
  • профиля использования;
  • требований к отказоустойчивости.

Мультикластер

1. Реплицируются ли настройки lifecycle?

Нет, политики lifecycle не реплицируются между кластерами и настраиваются независимо в каждом из них.

Это связано с тем, что настройки lifecycle зависят от локальной конфигурации хранения и применяются на уровне конкретного кластера.

База данных

1. Почему нет роли для установки PostgreSQL?

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

2. Есть ли документация по HA PostgreSQL?

В документации присутствуют только базовые настройки. Высокодоступные конфигурации:

  • проектируются индивидуально
  • не входят в стандартную документацию

Фоновые задачи

Когда рекомендуется использовать Kafka для обработки фоновых задач?

Использование Kafka для обработки фоновых задач определяется характером нагрузки и состоянием очереди задач. Рекомендуется переходить на обработку через Kafka в случаях, когда:

  • количество ожидающих обработки фоновых задач стабильно остаётся высоким;
  • наблюдается рост очереди задач.

При этом необходимо исключить влияние внешних факторов, таких как:

  • недоступность хранилища;
  • инфраструктурные ограничения.

Фиксированных пороговых значений (например, по количеству объектов) не предусмотрено.

S3 и работа с объектами

1. Можно ли создать несколько пар ключей для одного пользователя?

В текущей версии для каждого пользователя используется одна пара ключей доступа. Поддержка нескольких пар ключей находится в планах развития и ориентирована на ближайшие релизы.

2. С какого размера объекта используется multipart upload и можно ли изменить этот порог?

Использование multipart upload определяется на стороне клиента. Система не задаёт фиксированного порога, и поведение зависит от используемого клиента или SDK.

На практике multipart upload обычно применяется для объектов размером более 8–10 MB.

ZDS и отказоустойчивость

1. Гарантируется ли запись объекта при использовании синхронного хранилища, если получен ответ 200 OK?

Да, запись объекта гарантируется.

Если получен ответ 200 OK, это означает, что как минимум одна копия объекта успешно записана в хранилище. Система не использует кэш записи, поэтому ситуация, при которой данные остаются только в кэше без фактической записи, не возникает.

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

В текущей версии интерактивные показатели прогресса синхронизации не предоставляются.

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

3. Как отслеживается синхронизация хранилища после его восстановления в группе хранения?

После восстановления доступности хранилища синхронизация выполняется автоматически в рамках фоновых задач. Отслеживание процесса также осуществляется косвенно через мониторинг фоновых задач.

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

Дополнительно

Где найти информацию о поддерживаемых ОС, требованиях к сети и настройке базы данных?

Информация о системе приводится в документации по установке и эксплуатации конкретной версии поставки: пример для версии 2.8.

  1. Поддерживаемые операционные системы:
  • точные перечни дистрибутивов и версий указываются в документации соответствующей версии;
  • пользовательские рабочие места (веб-интерфейс) не ограничены ОС и могут использовать Linux, macOS и Windows.
  1. Требования к сети:
  • зависят от объёма данных, требуемой производительности (RPS), пропускной способности и требований к отказоустойчивости;
  • конкретные параметры (latency, пропускная способность, порты, схемы взаимодействия) приводятся в документации по развертыванию.
  1. Минимальные сетевые требования:
  • не задаются фиксированными значениями;
  • определяются исходя из нагрузки системы и архитектуры решения.
  1. Настройки базы данных:
  • в документации представлены базовые рекомендации по настройке;
  • детальные конфигурации, включая высокодоступные сценарии, определяются индивидуально в зависимости от архитектуры системы.