Привет, Хабр.

А давайте поговорим про автоматизацию в мире систем хранения данных. Мы в компании АЭРОДИСК регулярно проводим опросы наших и не только наших заказчиков по желаемым функциям в наших продуктах. Желание клиента для нас, может быть, еще не закон, но желание нескольких десятков клиентов обязательно находит отражение в роадмапе. Одними из таких функций в новой версии программного обеспечения A-CORE 5.1.0 для СХД ВОСТОК-5 и ENGINE-5 явились управление СХД посредством REST API и группы консистентости при создании снимков данных на группе взаимозависимых томов. В нашей сегодняшней статье мы на наглядном (хоть и искусственном) примере покажем, зачем это нужно и как использовать этот функционал в системах хранения АЭРОДИСК. А послушать про это можно будет на вебинаре "Около ИТ", который пройдёт 6 июня 2023 г. в 15:00 – регистрируйтесь по ссылке.

Итак, немного теории

REST API – набор веб-сервисов, которые позволяют разработчикам взаимодействовать с системой хранения данных, используя HTTP-запросы. Данные API обеспечивают стандартный способ управления для автоматизированных систем, то есть обеспечивают автоматизацию обычного набора функций управления СХД: создание и удаление пулов и томов, маппинг томов, оркестрацию снимков данных, управление репликацией, QOS, файловыми системами и другие. REST API позволяет унифицировать управление СХД от разных производителей, интегрировать необходимые функции во внешние системы и приложения: системы виртуализации, системы резервного копирования и восстановления, порталы самообслуживания в облачных инфраструктурах и т.д.

Группы консистентности

Современные ИТ-ландшафты состоят из множества информационных систем, плотно связанных между собой потоками данных. Например, в ритейле покупка товара на кассе магазина отражается во многих ИТ-системах, включая CRM, склад, финансовую отчетность и планирование и т. д. То есть в каждый момент времени информационные системы связаны между собой, что приводит к дополнительным сложностям в обеспечении целостности данных при восстановлении из резервных копий. Представим себе, что из-за разницы во времени резервного копирования систем после сбоя и восстановления из резервной копии в одной системе товар был продан, а в другой – нет: не сходятся бухгалтерские балансы, на складах лежат неучтённые товары, происходят сбои в логистике и другие неприятные истории.

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

Настраиваемся

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

Для эмулирования взаимозависимых ИТ-систем создадим экземпляр БД PostgreSQL, в который будем записывать тестовые данные с указанием timestamp. Исходя из данных, генерируемых в таблице, будем создавать одинаковые текстовые файлы на разных файловых системах. Естественно, чтобы у нас получился эксперимент, расположим базу данных и файловые системы на трех разных томах СХД (например, размером 200GB).

Итак, начнем

Создадим RDG группу RAID 6/60 (4+2) на дисковом массиве АЭРОДИСК:

Создадим 3 логических тома на группе R00 объемом 200GB:

Сделаем маппинг томов размеров 200GB на сервер Ubuntu через FC:

Просканируем новые LUN на сервере Ubuntu:

root@tester:~# echo 1 > /sys/class/fc_host/host11/issue_lip
root@tester:~# echo 1 > /sys/class/fc_host/host0/issue_lip

Проверим наличие трех блочных устройств размера 200GB:

Смонтируем созданные файловые системы в операционную систему в точки монтирования /vol6 /vol7 и /vol8.

Создадим табличное пространство и экземпляр базы данных PostgreSQL DB6. Для генерации набора тестовых данных используем python скрипт, вставляющий в таблицу БД db_test тестовые данные ID 100 .. 20000 и current_timestamp. После вставки данных создаем текстовые файлы с именем ID и минимальным текстом в точках монтирования /vol7 и /vol8.

Скрипт работает несколько минут, в результате чего мы имеем эмуляцию работы взаимосвязанных систем. Примерами из реальных ИТ систем могут быть конструкторские системы, хранящие чертежи на файловой системе с каталогом в СУБД, или системы управления медиа-контентом, также имеющие похожую структуру как в неструктурированных файловых системах, так и в структурированных СУБД.

Итак, во время работы эмулятора нагрузки сделаем обычный аппаратный снимок томов файловой системы /vol7 и /vol8:

Теперь попробуем восстановить аппаратные снимки двух томов и сделать маппинг восстановленных томов:

Можно увидеть, что из-за несинхронности времени создания снимков мы получаем разное количество файлов на восстановленных файловых системах:

Данная проблема актуальна и при создании снимков вручную, и при использовании скриптов. Для решения этой проблемы мы реализовали функциональность «Группы консистентности», которая обеспечивает консистентность данных для всех томов, объединенных в группу.

Сделаем это по-новому

Создадим группу консистентности связанных клонов SAVEMYDATA и добавим тома VOL_1  и VOL_3:

Во время создания тестовых данных создадим связанные клоны для группы SAVEMYDATA:

После создания клонов удалим файловые данные с /vol7 и /vol8 и восстановим данные со снимков, созданных в группе консистентности:

Проверим восстановленные данные: как видно, файловые системы /vol7 и /vol8 синхронны:

А теперь про автоматизацию

Как видно, мы совершили множество действий для того, чтобы продемонстрировать работу лишь малой части функциональности СХД. Каждый день администраторы систем хранения данных работают с сотнями хостов и несколькими сотнями томов, а в таком окружении выполнять все настройки из графического интерфейса довольно трудоёмко. Традиционный помощник админа в этом – CLI или полноценный REST API для автоматизации рутинных операций и полноценной интеграции СХД в экосистему приложений.

В версии ПО A-Core 5.1.0 мы представили полноценный REST API для наших систем хранения данных, который поможет настроить и использовать СХД без множества операций в GUI. Какие типовые применения REST API мы видим:

• выделение ёмкости, презентация хостам в больших ИТ ландшафтах;

• создание типовых конфигураций для быстрого развёртывания;

• интеграция в порталы самообслуживания;

• интеграция с аппаратными снимками данных для резервного копирования;

• интеграция с системами мониторинга конфигураций.  

Все методы REST API, доступные для использования, описаны и доступны из интерфейса СХД по адресу https://controller_ip/api/docs. Там же можно найти примеры запросов и в режиме реального времени эти запросы создавать и выполнять.

Пример автоматизации

Для примера давайте проделаем работу со снимками, которую мы выполняли в начале с помощью REST-запросов. Скрипты будем создавать с помощью нашего любимого Python.

Процесс управления снимками данных в дальнейшем можно интегрировать с системой СРК или приложениями. Таким нехитрым образом процесс создания снимков и восстановления может быть выполнен одной командой. Применение REST-запросов для администрирования позволяет сэкономить множество кликов мышки в рутинных операциях и, надеюсь, сделает жизнь наших пользователей существенно проще.

Чтобы узнать больше про REST API и использование аппаратных снимков данных записывайтесь на наш вебинар "Около ИТ" 6 июня по ссылке. На нём вы увидите демонстрацию работы технологий, поговорим о внутренней кухне разработки новых фич АЭРОДИСК, и, естественно, ответим на любые вопросы по теме и не по теме ????