Привет, Хабр.
А давайте поговорим про автоматизацию в мире систем хранения данных. Мы в компании АЭРОДИСК регулярно проводим опросы наших и не только наших заказчиков по желаемым функциям в наших продуктах. Желание клиента для нас, может быть, еще не закон, но желание нескольких десятков клиентов обязательно находит отражение в роадмапе. Одними из таких функций в новой версии программного обеспечения A-CORE 5.1.0 для СХД ВОСТОК-5 и ENGINE-5 явились управление СХД посредством REST API и группы консистентости при создании снимков данных на группе взаимозависимых томов. В нашей сегодняшней статье мы на наглядном (хоть и искусственном) примере покажем, зачем это нужно и как использовать этот функционал в системах хранения АЭРОДИСК. А послушать про это можно будет на вебинаре "Около ИТ", который пройдёт 6 июня 2023 г. в 15:00 – регистрируйтесь по ссылке.
Итак, немного теории
REST API – набор веб-сервисов, которые позволяют разработчикам взаимодействовать с системой хранения данных, используя HTTP-запросы. Данные API обеспечивают стандартный способ управления для автоматизированных систем, то есть обеспечивают автоматизацию обычного набора функций управления СХД: создание и удаление пулов и томов, маппинг томов, оркестрацию снимков данных, управление репликацией, QOS, файловыми системами и другие. REST API позволяет унифицировать управление СХД от разных производителей, интегрировать необходимые функции во внешние системы и приложения: системы виртуализации, системы резервного копирования и восстановления, порталы самообслуживания в облачных инфраструктурах и т.д.
Группы консистентности
Современные ИТ-ландшафты состоят из множества информационных систем, плотно связанных между собой потоками данных. Например, в ритейле покупка товара на кассе магазина отражается во многих ИТ-системах, включая CRM, склад, финансовую отчетность и планирование и т. д. То есть в каждый момент времени информационные системы связаны между собой, что приводит к дополнительным сложностям в обеспечении целостности данных при восстановлении из резервных копий. Представим себе, что из-за разницы во времени резервного копирования систем после сбоя и восстановления из резервной копии в одной системе товар был продан, а в другой – нет: не сходятся бухгалтерские балансы, на складах лежат неучтённые товары, происходят сбои в логистике и другие неприятные истории.
Если мы имеем дело с современной СХД, то тут на помощь приходит технология обеспечения консистентности групп томов (LUN). Объединив тома в логическую группу, СХД обеспечивает их связанность при операциях локальной или удаленной репликации. Если создаётся снимок данных, то можно быть уверенным, что снимок данных для всех томов в группе создается на определенный момент времени одновременно и синхронность систем будет обеспечена.
Настраиваемся
Для демонстрации работы функциональности мы организовали следующий тестовый стенд:
![](https://habrastorage.org/getpro/habr/upload_files/ec0/6bc/845/ec06bc84589d541ff7230678425d20ed.png)
Для эмулирования взаимозависимых ИТ-систем создадим экземпляр БД PostgreSQL, в который будем записывать тестовые данные с указанием timestamp. Исходя из данных, генерируемых в таблице, будем создавать одинаковые текстовые файлы на разных файловых системах. Естественно, чтобы у нас получился эксперимент, расположим базу данных и файловые системы на трех разных томах СХД (например, размером 200GB).
Итак, начнем
Создадим RDG группу RAID 6/60 (4+2) на дисковом массиве АЭРОДИСК:
![](https://habrastorage.org/getpro/habr/upload_files/a5b/5b8/822/a5b5b882210e7e65d11e98eadb1f1662.png)
![](https://habrastorage.org/getpro/habr/upload_files/23e/771/023/23e771023697c78ee997ccec11bede4a.png)
Создадим 3 логических тома на группе R00 объемом 200GB:
![](https://habrastorage.org/getpro/habr/upload_files/250/c57/7fe/250c577fe8586b105f4199fa405c6d92.png)
![](https://habrastorage.org/getpro/habr/upload_files/102/f89/2ef/102f892ef27c0e7f5244892609782e0f.png)
![](https://habrastorage.org/getpro/habr/upload_files/792/02e/686/79202e68625dca73864c9309a2a19dfe.png)
Сделаем маппинг томов размеров 200GB на сервер Ubuntu через FC:
![](https://habrastorage.org/getpro/habr/upload_files/50c/93d/7c1/50c93d7c1d3adcc1dbd66f6863ca3f65.png)
![](https://habrastorage.org/getpro/habr/upload_files/3ba/23d/a5c/3ba23da5c44ad7808d1d62eac76d6322.png)
Просканируем новые LUN на сервере Ubuntu:
root@tester:~# echo 1 > /sys/class/fc_host/host11/issue_lip
root@tester:~# echo 1 > /sys/class/fc_host/host0/issue_lip
![](https://habrastorage.org/getpro/habr/upload_files/3f2/8d6/403/3f28d64039fb254e970f110d2ba537de.png)
Проверим наличие трех блочных устройств размера 200GB:
![](https://habrastorage.org/getpro/habr/upload_files/873/d1e/641/873d1e6418299d1c8f096b84ae45531f.png)
![](https://habrastorage.org/getpro/habr/upload_files/749/224/c2d/749224c2d6c927fc6420fb6008afd36a.png)
Смонтируем созданные файловые системы в операционную систему в точки монтирования /vol6 /vol7 и /vol8.
Создадим табличное пространство и экземпляр базы данных PostgreSQL DB6. Для генерации набора тестовых данных используем python скрипт, вставляющий в таблицу БД db_test тестовые данные ID 100 .. 20000 и current_timestamp. После вставки данных создаем текстовые файлы с именем ID и минимальным текстом в точках монтирования /vol7 и /vol8.
Скрипт работает несколько минут, в результате чего мы имеем эмуляцию работы взаимосвязанных систем. Примерами из реальных ИТ систем могут быть конструкторские системы, хранящие чертежи на файловой системе с каталогом в СУБД, или системы управления медиа-контентом, также имеющие похожую структуру как в неструктурированных файловых системах, так и в структурированных СУБД.
![](https://habrastorage.org/getpro/habr/upload_files/fa9/fa3/3da/fa9fa33da3d553998449ac87fce5e214.png)
Итак, во время работы эмулятора нагрузки сделаем обычный аппаратный снимок томов файловой системы /vol7 и /vol8:
![](https://habrastorage.org/getpro/habr/upload_files/b85/c30/20e/b85c3020e09a531f803ff1dcbab695c1.png)
![](https://habrastorage.org/getpro/habr/upload_files/101/84a/56e/10184a56e640dcf16f2913e0dd249294.png)
![](https://habrastorage.org/getpro/habr/upload_files/6a9/098/a93/6a9098a9354aa3b34025ece01897dbdc.png)
Теперь попробуем восстановить аппаратные снимки двух томов и сделать маппинг восстановленных томов:
![](https://habrastorage.org/getpro/habr/upload_files/675/f53/da3/675f53da38ed4730dfecbd89bda6f979.png)
Можно увидеть, что из-за несинхронности времени создания снимков мы получаем разное количество файлов на восстановленных файловых системах:
![](https://habrastorage.org/getpro/habr/upload_files/709/086/695/7090866951421b4c758f03e80aa0e25b.png)
Данная проблема актуальна и при создании снимков вручную, и при использовании скриптов. Для решения этой проблемы мы реализовали функциональность «Группы консистентности», которая обеспечивает консистентность данных для всех томов, объединенных в группу.
Сделаем это по-новому
Создадим группу консистентности связанных клонов SAVEMYDATA и добавим тома VOL_1 и VOL_3:
![](https://habrastorage.org/getpro/habr/upload_files/db3/cc9/378/db3cc9378c17a4f8d182dd6995ba34c4.png)
Во время создания тестовых данных создадим связанные клоны для группы SAVEMYDATA:
![](https://habrastorage.org/getpro/habr/upload_files/c39/a57/d43/c39a57d43ecd0eb1f464cd05fb5a659c.png)
После создания клонов удалим файловые данные с /vol7 и /vol8 и восстановим данные со снимков, созданных в группе консистентности:
![](https://habrastorage.org/getpro/habr/upload_files/210/35a/a16/21035aa160e18ea01373fa34dc610b07.png)
Проверим восстановленные данные: как видно, файловые системы /vol7 и /vol8 синхронны:
![](https://habrastorage.org/getpro/habr/upload_files/dd1/e3e/971/dd1e3e971f8b075a1343511f8b9230b9.png)
А теперь про автоматизацию
Как видно, мы совершили множество действий для того, чтобы продемонстрировать работу лишь малой части функциональности СХД. Каждый день администраторы систем хранения данных работают с сотнями хостов и несколькими сотнями томов, а в таком окружении выполнять все настройки из графического интерфейса довольно трудоёмко. Традиционный помощник админа в этом – CLI или полноценный REST API для автоматизации рутинных операций и полноценной интеграции СХД в экосистему приложений.
В версии ПО A-Core 5.1.0 мы представили полноценный REST API для наших систем хранения данных, который поможет настроить и использовать СХД без множества операций в GUI. Какие типовые применения REST API мы видим:
выделение ёмкости, презентация хостам в больших ИТ ландшафтах;
создание типовых конфигураций для быстрого развёртывания;
интеграция в порталы самообслуживания;
интеграция с аппаратными снимками данных для резервного копирования;
интеграция с системами мониторинга конфигураций.
Все методы REST API, доступные для использования, описаны и доступны из интерфейса СХД по адресу https://controller_ip/api/docs. Там же можно найти примеры запросов и в режиме реального времени эти запросы создавать и выполнять.
![](https://habrastorage.org/getpro/habr/upload_files/9ec/dbc/ed3/9ecdbced36d60de147ba770b335e4f31.png)
![](https://habrastorage.org/getpro/habr/upload_files/e54/ef4/db0/e54ef4db08acbd2c7d166d6fd453ae26.png)
Пример автоматизации
Для примера давайте проделаем работу со снимками, которую мы выполняли в начале с помощью 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 июня по ссылке. На нём вы увидите демонстрацию работы технологий, поговорим о внутренней кухне разработки новых фич АЭРОДИСК, и, естественно, ответим на любые вопросы по теме и не по теме ?