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

Содержание

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

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

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

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

Технологии хранения данных в Платформе Astra Cloud

Технологии хранения	Методы передачи данных между хранилищем образов и системным хранилищем
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

Особенности функционирования хранилища BREST_LVM#

в BREST_LVM используется формат образа Qcow2 как в системном хранилище, так и в хранилище образов;
логический том, используемый в ВМ, будет увеличиться по мере использования диска ВМ;
при загрузке образы конвертируются в формат Qcow2;
персистентные образы подключаются к ВМ без предварительного копирования в системное хранилище;
хранилище поддерживает снимки состояния ВМ;
реализована возможность миграции образов и ВМ из других типов хранилищ в BREST_LVM;
загружаемые диски в форматах RAW и Qcow2 с опцией preallocation=full (заполнение неиспользованного места нулями) будут преобразованы в диски с preallocation=none (т.е. нули будут удалены). При этом логический том не будет автоматически уменьшен после записи на него конвертированного образа. В связи с этим, рекомендуется загружать диски в платформу в формате Qcow2 для экономии пространства хранилища;
загружаемые диски в формате Qcow2 с использованием опции compression (сжатие) будут преобразованы в Qcow2-формат на базе логического тома без сжатия. В этом случае, после «распаковки» размер тома в хранилище увеличится приблизительно в 3.26 раза;
оптимальное потребление пространства хранилища за счет хранения фактически занимаемого объема данных. Логические тома создаются по реальному размеру данных в образе с запасом в 8%, а не по виртуальному размеру, указанному в свойствах образа.

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

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

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

При использовании аппаратных СХД, подключаемых к Платформе Astra Cloud по протоколам 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 (CPU/RAM/SSD);

сегментации сетей хранения и ВМ;

отказоустойчивости через смешанные роли узлов;

изоляции зон отказа и обновлений.

При установке 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.

Резервное копирование в Платформе Astra Cloud#

В качестве СРК данных для служебных виртуальных машин используется решение 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	Ежедневно, полный

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

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

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

Базовая конфигурация RuBackup, поставляемая в составе Платформы Astra Cloud, не предусматривает выполнения операций резервного копирования и восстановления виртуальных машин Блока Виртуализации. Для резервного копирования виртуальных машин БВ требуется покупка дополнительных лицензий на ПО 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.

Версии