Хранение данных

Содержание

Хранение данных#

AIC предусматривает возможность хранения, использования и управления данными с применением различных типов систем хранения, в том числе программно-определяемых СХД (Ceph и др). Планирование подключения СХД к AIC необходимо проводить исходя из требований предъявляемых ПК СВ «Брест».

Для построения облачного хранилища данных используются следующие базовые технологии хранения:

Filesystem — файловая технология хранения;
NFS (Network File System) — сетевая файловая система;
LVM (Logical Volume Manager) — блочная технология хранения (менеджер логических томов);
Ceph — программно-определяемое хранилище с файловым и блочным интерфейсами доступа;
Raw Device Mapping — прямое подключение к ВМ существующих блочных устройств, используется только для организации хранилища образов;
iSCSI-Libvirt — прямое подключение к ВМ существующих устройств iSCSI, используется только для организации хранилища образов.

Технологии хранения данных в AIC

Технологии хранения	Методы передачи данных между хранилищем образов и системным хранилищем
Filesystem	ssh — образы копируются с помощью ssh-протокола; shared — образы экспортируются в соответствующий каталог системного хранилища на узле виртуализации; qcow2 — аналогично shared, но для образов формата qcow2. Образы создаются и передаются с помощью команды qemu-img с использованием оригинального образа в качестве опорного файла
Ceph	ceph — все образы экспортируются в Ceph-пулы; ssh — rbd-файл, ассоциируемый с образом, экспортируется в файл локальной файловой системы узла виртуализации
LVM	fs_lvm — образы хранятся как обычные файлы, при создании ВМ они выгружаются в логические тома (LV); lvm_lvm — создаются отдельные группы LVM-томов для хранилища образов и системного хранилища; lvm_thin — создаются отдельные группы LVM-томов для хранилища образов и системного хранилища, но системное хранилище организуется индивидуально для каждого узла виртуализации
Raw Devices	dev — образы представляют собой существующие блочные устройства в узлах
iSCSI libvirt	iscsi — образы представляют собой компоненты iSCSI target

Подробная информация о типах хранилищ и их настройке приведена в документации на ПК СВ «Брест».

Варианты использования СХД#

Аппаратные СХД#

При использовании аппаратных СХД, подключаемых к AIC по протоколам Fibre Channel (FC) или iSCSI необходимо учитывать возможности по обеспечению надежности и доступности, предоставляемые этими системами хранения данных.

Количество интерфейсов и контроллеров для подключения к СХД определяется архитектурой СХД. Рекомендуется использование не менее 2-х каналов (портов) для подключения к каждой системе хранения данных.

Пример подключения Сервера Контроля Облачных Ресурсов (СКОР) к СХД:

Программно-определяемые хранилища#

При необходимости использовании программно-определяемых СХД необходимо тщательное планирование ресурсов. Так же предъявляются повышенные требования к подготовке инженерного состава, обеспечивающего сопровождение системы.

Компоненты программно-определяемой СХД Ceph:

OSD (Object Storage Daemon) — это системный сервис объектного хранилища в Ceph. Предоставляет функции:

Хранение объектов: OSD управляет хранением объектов на локальных носителях данных (например, жестких дисках). Обеспечивает репликацию данных для обеспечения отказоустойчивости.
Обеспечение доступа: OSD предоставляет доступ к объектам через сеть. Отвечает за передачу данных между клиентами и хранилищем.
Управление состоянием: OSD следит за состоянием данных, обнаруживает и восстанавливает поврежденные блоки. Управляет компактацией данных для оптимизации пространства.
Распределение данных: Ceph автоматически распределяет данные между OSD для балансировки нагрузки.

OSD — это ключевой компонент Ceph, обеспечивающий надежное и масштабируемое хранение объектов.

MON (Monitor): MON — это системный сервис контроля в Ceph. Отвечает за следующие задачи:

Отслеживание состояния кластера: Мониторы следят за состоянием всех узлов в кластере, включая OSD (объектное хранилище), MDS (сервер метаданных) и другие мониторы.
Хранение метаданных: MON хранит информацию о состоянии кластера, конфигурации и другие метаданные.
Принятие решений: принимает решения о перераспределении данных, добавлении новых узлов и других аспектах управления кластером.

MDS (Metadata Server): MDS — это системный сервис сервера метаданных в Ceph. Его задача — управление метаданными файловой системы.

Координирование доступа к файловой системе: MDS синхронизирует доступ к общему кластеру OSD и обеспечивает целостность метаданных.
Управление пространством и именами файлов: Он отвечает за имена файлов, директории, разрешения и другие аспекты файловой системы.

Примечание

При использовании программно-определяемой СХД (SDS) Ceph следует учитывать следующие ограничения:

В тестовой среде возможно использование серверов бКОР для запуска сервисов SDS Ceph (OSD, MON, MDS).
В продуктивных средах использование серверов бКОР для запуска сервисов SDS Ceph категорически не рекомендуется и не является поддерживаемой конфигурацией.

При установке Ceph в тестовом окружении на серверы бКОР, требуется учитывать повышенные требования к ресурсам предъявляемые этой SDS.

Использование SDS Ceph с аппаратными СХД возможно, но не может быть рекомендовано к использованию в продуктивных средах.

Пример расположения сервисов Ceph и подключения к сетям в тестовом окружении:

В продуктивном окружении для установки SDS Ceph необходимо выделение отдельных физических серверов с дисками, которые будут выступать в качестве отдельного хранилища, и на которых будут запущены службы Ceph OSD. Так же требуется выделение отдельных серверов для работы служб MON и MDS.

Минимальное рекомендуемое количество серверов с MON и MDS — 3 (три) единицы.

Минимальное рекомендуемое количество серверов с OSD — 3 (три) единицы.

Расчет требований к аппаратным характеристикам каждого OSD сервера выполняется следующим образом:

каждый диск, используемый для хранения данных — это отдельная служба OSD;
на каждый запущенный экземпляр OSD требуется минимум — 1 процессорное ядро;
на каждый 1 ТБ дискового пространства на физическом диске требуется 1 ГБ ОЗУ.

Таким образом, в случае использования сервера с 12 дисками по 6 TB, для работы OSD, потребуется: минимум 12 ядер CPU и 72 ГБ RAM.

Примечание

Расчет требуемых аппаратных ресурсов зависит от множества параметров и не может быть универсальным для всех сценариев использования Ceph. Для получения дополнительной и формации о расчете требуемых ресурсов рекомендуется обратиться к документации Ceph.

Резервное копирование в AIC#

В качестве СРК данных для пользовательских виртуальных машин используется решение RuBackup, которое обеспечивает их хранение на стороне выделенных серверов СРК.

СРК RuBackup, обеспечивает хранение конфигурационных данных компонентов платформы и резервных копий ВМ бКОР на выделенную СХД в Блоке управления.

Архитектура СРК выполнена на основе клиент-серверной архитектуры. Минимально рекомендуемый набор компонент серверной части состоит из основного сервера, выполняющего роль управления резервным копированием и медиа сервера. Для хранения метаданных используется СУБД PostgreSQL являющаяся частью СРК.

RuBackup сервер устанавливается на выделенной виртуальной машине в Блоке Контроля Облачными Ресурсами.

Схема резервного копирования платформы:

В таблицах приведены списки ресурсов, подлежащих резервному копированию.

Целевые объекты на уровне ОС

Ресурс	Содержимое	Источник	Расписание
/home	Содержит данные пользователей системы	Filesystem	Ежедневно, полный
/etc	Содержит конфигурационные файлы системы	Filesystem	Ежедневно, полный
/opt/rubackup/keys/	Ключи используемые для защитного преобразования резервных копий	Filesystem	Ежедневно, полный

Целевые объекты на уровне контроллеров домена

Ресурс	Содержимое	Источник	Расписание
База данных ALD Pro (только копия данных LDAP)	Содержит базу данных домена и его конфигурацию	ALD Pro	Ежедневно, полный
База данных ALD Pro (полная копия)	Содержит базу данных домена и его конфигурацию	ALD Pro	Еженедельно, полный

Целевые объекты ПК СВ «Брест»

Ресурс	Содержимое	Источник	Расписание
Шаблоны виртуальных машин	Содержит шаблоны для создания ВМ	rubackup-brest-template	Еженедельно, полный
Виртуальные машины	Данные виртуальных машин	rubackup-brest	Еженедельно, полный
База данных PostgreSQL	Содержит конфигурацию ПК СВ	rubackup-postresql	Ежедневно, полный
/var/lib/one/.one	Пароль пользователя oneadmin (необходим для восстановления БД)	Filesystem	Ежедневно, полный

Резервное копирование виртуальных машин БКР#

В качестве системы резервного копирования в AIC используется ПО Rubackup. ПО Rubackup включает (но не ограничивается) следующие функциональные возможности:

полное, инкрементальное и дифференциальное резервное копирование;
автоматическая верификация сделанных резервных копий (размер файлов, md5sum, электронная подпись);
аналитика — построение плана резервного копирования с прогнозированием требуемых ресурсов;
глобальное расписание, обеспечивающее автоматическое создание резервных копий клиентов;
локальное расписание для клиента, позволяющее управлять резервным копированием самостоятельно;
полноценное управление системой из командной строки;
графический интерфейс управления как для пользователя, так и для администратора СРК;
Автоматическое перемещение резервных копий на другие носители и удаление устаревших копий;
создание срочных резервных копий по инициативе клиента или администратора;
стратегии резервного копирования, позволяющие выполнять автоматические групповые операции с клиентами СРК;
управление устройствами для хранения резервных копий, возможность их распределять по разным хранилищам в зависимости от выбранной политики;
количество одновременных сессий ограничено только аппаратными характеристиками сервера. Параллельные сессии доступны как для СРК в целом, так и для отдельного клиента;
хранение резервных копий в СХД, ленточных библиотеках и, облаке S3;
система уведомлений пользователей о событиях;
сжатие резервных копий на клиенте или на сервере;
защитное преобразование резервных копий по алгоритмам ГОСТ 34-12-2015 (Kuznyechik), Anubis, ARIA, CAST6, Camellia, Kalyna, MARS, AES, Serpent, Simon, SM4, Speck, Treefish, Twofish;
локальный лист запретов (с regexp) для каждого клиента, ограничивающий доступную для копирования информацию;
фиксация всех действий администратора и пользователей в базе данных и системном журнале.

Базовая конфигурация RuBackup, поставляемая в составе AIC, не предусматривает выполнения операций резервного копирования и восстановления виртуальных машин Блока Клиентских Ресурсов. Для резервного копирования виртуальных машин БКР требуется покупка дополнительных лицензий на ПО Rubackup, а так же проектирование системы резервного копирования, исходя из инфраструктуры и потребностей разворачиваемого решения.

Для обеспечения максимального уровня отказоустойчивости и быстродействия при промышленной эксплуатации, рекомендуется использовать в качестве конфигурационной базы RuBackup СУБД PostgreSQL в отказоустойчивой конфигурации с использованием решения Patroni, развернутом на отдельно стоящих машинах, построенного с использованием твердотельных накопителей, подключенных через шину PCI Express (NVMe SSD).

Для промышленных и высоконагруженных сред рекомендуется установка СРК RuBackup в многонодовой конфигурации, включающей в себя:

Основной сервер RuBackup.
Резервный сервер.
Медиа сервер(ы).

Подробная информация о рекомендуемой конфигурации компонент СРК RuBackup приведена в документации.

В случае необходимости резервное копирование образов виртуальных машин и конфигурации машин, а также параметров настройки средств виртуализации и сведений о событиях безопасности может быть дополнительно реализовано с использованием встроенных средств ПК СВ «Брест», с помощью встроенных в средства виртуализации ОС СН ALSE механизмов резервного копирования (инструментов командной строки virsh backup-begin, virsh dumpxml и virsh snapshot-create), а также встроенных в ОС СН средств резервного копирования:

Комплекс программ Bacula.
Инструмент копирования rsync.
Инструменты архивирования и копирования tar, cpio, gzip, cp.

Версии