Привет, Хабр.
А давайте поговорим про автоматизацию в мире систем хранения данных. Мы в компании АЭРОДИСК регулярно проводим опросы наших и не только наших заказчиков по желаемым функциям в наших продуктах. Желание клиента для нас, может быть, еще не закон, но желание нескольких десятков клиентов обязательно находит отражение в роадмапе. Одними из таких функций в новой версии программного обеспечения 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.
Итак, авторизуемся на СХД и получим token:
URL_auth = "https://my_ip/api/auth/token"
headers = {
"accept": "application/json",
"Content-Type": "application/x-www-form-urlencoded"
}
resp = requests.post(URL_auth, headers = headers ,data='grant_type=&username=admin&password=*****&scope=&client_id=&client_secret=')
tk = json.loads(resp.text)['access_token']
Сделаем снимок тома VOL_1 в группе R00:
URL_snaplun = "https://my_ip/api/rdg/snapshot"
auth_str = ("Bearer " + str(tk))
headers = {
'accept': 'application/json',
'Authorization': 'Bearer '+str (tk),
'Content-Type': 'application/json',
}
json_data = {
'pool': 'R00',
'lun': 'VOL_1',
}
response = requests.post (URL_snaplun, headers=headers, json=json_data)
Сделаем снимок тома VOL_3 в группе R00:
json_data = {
'pool': 'R00',
'lun': 'VOL_3',
}
response = requests.post (URL_snaplun, headers=headers, json=json_data)
После восстановления томов со снимков данных нам также понадобится процедура добавления маппингов, которую мы тоже сделаем с помощью REST-запросов. Авторизация и получение токена будут идентичны предыдущему шагу, создание же маппинга можно реализовать следующим кодом:
URL = "https://my_ip/api/fc/mapping"
auth_str = ("Bearer " + str(tk))
headers = {
'accept': 'application/json',
'Authorization': 'Bearer '+str (tk),
'Content-Type': 'application/json',
}
json_data = {
'group': 'host2_79',
'pool': 'R00',
'lun': 'VOL_1',
'lun_id': '1'
}
response = requests.post(URL_snaplun, headers=headers, json=json_data)
json_data = {
'group': 'host2_79',
'pool': 'R00',
'lun': 'VOL_3',
'lun_id': '3'
}
Процесс управления снимками данных в дальнейшем можно интегрировать с системой СРК или приложениями. Таким нехитрым образом процесс создания снимков и восстановления может быть выполнен одной командой. Применение REST-запросов для администрирования позволяет сэкономить множество кликов мышки в рутинных операциях и, надеюсь, сделает жизнь наших пользователей существенно проще.
Чтобы узнать больше про REST API и использование аппаратных снимков данных записывайтесь на наш вебинар "Около ИТ" 6 июня по ссылке. На нём вы увидите демонстрацию работы технологий, поговорим о внутренней кухне разработки новых фич АЭРОДИСК, и, естественно, ответим на любые вопросы по теме и не по теме
Интересные статьи
Интересные статьи
