5.8 KiB
title, description, weight
| title | description | weight |
|---|---|---|
| Модель многоуровневого хранения | Стандартизированная таксономия хранения данных сервисов. | 15 |
Фреймворк навязывает стандартизированную таксономию хранения. Это гарантирует, что каждый сервис имеет предсказуемое местоположение для своих данных, что упрощает стратегии резервного копирования и распределение оборудования.
Таксономия хранения
Данные разделены на три логических Уровня (Tiers) на основе их требований к производительности, жизненного цикла и важности.
Уровень 1 (Tier 1): Конфигурации и Кэш
Путь: ${ROOT_NODE_DIR}/@tier1
- Содержимое: Конфигурационные файлы, небольшие базы данных SQLite, SSL-сертификаты, кэш приложений.
- Характеристики: Чрезвычайно высокая ценность, объем от низкого до среднего, требует минимальных задержек (latency).
- Оборудование: Высокоскоростные SSD-накопители, обычно общие с операционной системой.
Уровень 2 (Tier 2): Данные приложений
Путь: ${ROOT_NODE_DIR}/@tier2
- Содержимое: Пользовательские загрузки, большие базы данных, постоянное состояние приложений.
- Характеристики: Высокая ценность, объем от среднего до высокого, требует высокой надежности.
- Оборудование: Надежные HDD-кластеры, RAID-массивы или выделенные хранилища.
Уровень 3 (Tier 3): Временные файлы и объемные медиа
Путь: ${ROOT_NODE_DIR}/@tier3
- Содержимое: Логи, временные файлы, объемные медиа (фильмы, музыка) и другие некритичные большие данные.
- Характеристики: Низкая ценность, очень высокий объем.
- Оборудование: HDD большой емкости, оптимизированные для непрерывной последовательной записи/чтения (например, WD Purple). Обратите внимание, что Tier 3 слишком медленный для кэша.
Стратегия резервного копирования
Общие модули не навязывают конкретную стратегию резервного копирования и не предоставляют реализацию по умолчанию, обеспечивая полную гибкость на уровне узла. Ожидается, что операторы сами реализуют логику резервного копирования.
Пример: Резервное копирование с помощью Restic
Распространенной лучшей практикой является использование Restic для резервного копирования. Например, вы можете создать файл compose узла оператора для запуска Restic:
services:
restic:
image: restic/restic:0.18.1
container_name: operator-restic
volumes:
- ./@tier2/{project}/{service}/{data}:/data/@tier2/{project}/{service}/{data}:ro
- ./@tier1/{project}/{service}/{data}:/data/@tier1/{project}/{service}/{data}:ro
- ./@tier1/.operator/restic/cache:/var/restic-cache
environment:
RESTIC_REPOSITORY: "s3:example.com/bucket"
RESTIC_PASSWORD: ${RESTIC_PASSWORD}
# ... учетные данные AWS/S3
network_mode: "host"
entrypoint: [ "restic" ]
user: "0:0"
Реализация стратегии
Операторы могут реализовать свою стратегию, определив локальный Action в .operator/local/scripts/actions/sync/tiers. Диспетчер root затем сможет выполнить этот скрипт для запуска резервного копирования, позволяя детально контролировать способ сохранения данных.
Обоснование
- Оптимизация оборудования: Сопоставляя уровни с конкретным оборудованием (SSD для Tier 1, RAID для Tier 2, Purples для Tier 3), мы оптимизируем как производительность, так и стоимость.
- Выборочное резервное копирование: Отделение временных логов и объемных медиа (Tier 3) от критических конфигураций (Tier 1) предотвращает трату дорогостоящего места в хранилище резервных копий.
- Архитектурная ясность: Любой оператор может проинспектировать директорию Узла (Node) и сразу понять требования к хранению и приоритет его содержимого.