Функциональность¶

Управление СХД¶

Все системы хранения АЭРОДИСК используют единый интерактивный web-интерфейс на русском языке, позволяющий управлять всеми контроллерами СХД, установленными в системе, а также обеспечивающий:

• Поддержку протокола HTTP и защищенного HTTPS для доступа к web-интерфейсу

• Визуализацию контроллеров, дисков и портов ввода-вывода

• Визуализацию сенсоров и датчиков температуры

• Мониторинг состояния и нагрузки в реальном времени

• Логирование действий администратора

• Возможность выгрузки логов и статистики

• Командную строку (linux-like) для автоматизации операций

• Отправку оповещений по SMTP, SNMP, SYSLOG

• Управление через REST API

• Внешний мониторинг с помощью Grafana и Zabbix

REST API¶

Интерфейс прикладного программирования (API) необходим для взаимодействия с другими программными системами, такими как системы резервного копирования и мониторинга. API позволяет автоматизировать управление СХД, интегрировать необходимые функции во внешние системы и приложения: системы виртуализации, системы резервного копирования и восстановления, порталы самообслуживания в облачных инфраструктурах.

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

Высокая доступность¶

СХД АЭРОДИСК ENGINE поддерживает высокую доступность active-active. Это означает, что все системные контроллеры всегда используются при обработке данных. Дисковые группы (RDG и DDP) распределяются между всеми активными контроллерами. При этом администратор системы в случае необходимости (например, для обновления) может вручную переключать группы между контроллерами. При работе по протоколу Fibre Channel поддерживается технология ALUA, которая обеспечивает использование оптимальных путей для доступа к данным и быстрое переключение в случае аппаратных сбоев.

Кластерное ПО АЭРОДИСК работает как с блочным, так и с файловым доступом. Heartbeat между нодами выполняется с помощью интерконнекта. Кластер автоматически переключает оптимальные и неоптимальные пути, а также позволяет автоматически менять владельца групп хранения в следующих случаях:

• Отказ контроллера (смена владельца)

• Отказ задействованных во вводе-выводе портов СХД (смена владельца)

• Отказ порта на хосте (смена путей оптимальный—неоптимальный)

На примере ниже показана двухконтроллерная конфигурация, которая подключена к 2-м портам хоста, для которых средствами ОС настроен multipath. На СХД созданы 4 группы хранения: для 2-х из них назначен владельцем первый контроллер (контроллер-0), для 2-х других владельцем назначен второй контроллер (контроллер-1). Оба контроллера (и 4 группы) видны обоим портам хоста. Для DDP0 и RDG0 владельцем назначен контроллер-0; пути через этот контроллер для данной группы являются оптимальными. При этом существует неоптимальный путь (через интерконнект и контроллер-1), который задействуется в случае отказа основного порта на хосте. Для DDP1 и RDG1 обратная ситуация: владельцем является контроллер-1, через него лежит оптимальный путь, а через интерконнект и контроллер-0 — неоптимальный.

В любой момент администратор СХД может сменить владельца каждой из групп. Процесс смены владельца занимает примерно 5–10 секунд и происходит без прерывания ввода-вывода.

Эта же операция выполняется администратором для перевода контроллера в режим обслуживания, например, когда требуется аппаратное или программное обновление СХД.

Отказ порта¶

На схеме ниже представлена ситуация отказа порта на хосте, который был оптимальным для групп DDP0 и RDG0 (через контроллер-0). В этом случае СХД автоматически задействует неоптимальный путь через контроллер-1 и интерконнект, что сохранит доступ к данным, но с дополнительной задержкой. Может использоваться как внутренний интерконнект, так и внешние 25/40/100Гбит/с соединения.

Когда порт на хосте будет восстановлен, данные автоматически пойдут по оптимальному пути.

Отказ контроллера¶

На схеме ниже представлена ситуация отказа контроллера. В случае физической потери контроллера (или 2-х портов ввода-вывода на контроллере) система выполнит принудительную смену владельца всех групп хранения на отказавшем контроллере. Далее произойдёт смена владельца, что происходит без прерывания ввода-вывода.

Когда контроллер-0 снова вернется в строй, администратору нужно будет вручную сменить владельца на контроллер-0 обратно.

Файловый и блочный доступ¶

Блочный доступ обеспечивается путем предоставления блочного устройства (LUN) конечному хосту или хостам по протоколам Fibre Channel, iSCSI c поддержкой iSER или IB. Блочный доступ может предоставляться с LUN, созданных как на RDG, так и на DDP-группах. Протокол iSER (iSCSI Extensions for RDMA) поддерживается при наличии в СХД портов 25Gb Ethernet или 100Gb Ethernet.

Файловый доступ обеспечивается путем предоставления файловой системы по протоколам NFS и SMB (CIFS) конечному хосту или хостам. Для SMB (CIFS) может использоваться авторизация пользователей с помощью Active Directory. Файловый доступ работает только для RDG-групп.

LUN-ы и файловые системы создаются внутри RDG-групп. В рамках одной RDG-группы могут функционировать как LUN-ы, так и файловые системы. При этом размер RDG может быть динамично увеличен (т. е. в онлайн режиме) с помощью добавления дополнительных дисков в RDG. Для RDG как для файлового, так и для блочного доступа поддерживаются следующие уровни RAID

• RAID 1/10

• RAID 5/50

• RAID 6/60

• RAID 6P/60P (тройная чётность)

Для DDP для блочного доступа поддерживаются следующие уровни RAID:

• RAID 0

• RAID 1/10

• RAID 5

• RAID 6

Мгновенные снимки, клоны, связанные клоны¶

Мгновенные снимки (снэпшоты) и связанные клоны в RDG и DDP (в случае тонких лунов) используют модель переадресации при записи (Redirect-on-Write), т.е. СХД всегда пишет новые блоки данных в новое место, переставляя на них указатель, а старые блоки данных (т.е. на которые уже нет указателя) никогда не стираются, а помечаются системой как освобожденные. Этот механизм позволяет создавать любое количество снэпшотов и связанных клонов без какого-либо влияния на производительность СХД.

Снэпшоты создаются мгновенно и изначально не потребляют дисковое пространство, а растут по мере изменения данных.

Связанные клоны создаются мгновенно и сразу могут быть доступны серверу на чтение/запись при наличии маппинга (доступны только для RDG).

Полезной функцией является создание/удаление снэпшотов по расписанию (локальная репликация). Это применимо, если требуется сохранять резервные копии данных очень часто, что невозможно сделать внешними системами резервного копирования, т.к. в силу их специфики (высокая нагрузка на каналы, долгое время записи и пр.) они резервируют данные обычно не чаще чем раз в сутки.

В этом случае есть возможность настроить расписание снэпшотов, например, каждые 3 часа в течение суток со сроком хранения одни сутки. Через сутки снэпшоты начнут перезаписываться заново, а данные старше суток уже будут сохранены внешней системой резервного копирования.

Снэпклон – это гибрид клона и снэпшота. Снэпклоны создаются быстрее, чем классические клоны и изначально занимают ровно ту полезную емкость, которую занимает источник. При этом снэпклон, как и классический клон, может находиться в любой группе Восстановление данных из снэпшотов и связанных клонов можно выполнить двумя способами:

1. Откатить снэпшот/связанный клон, полностью перезаписав данные LUN/ФС. Это удобно, когда нужно быстро восстановить LUN/ФС полностью.

2. Присоединить связанный клон в виде отдельного LUN/ФС к хосту и восстановить данные с этого LUN. Такой способ подходит для ситуаций, когда не нужно восстанавливать LUN/ФС целиком, а нужно восстановить только некоторые объекты (файлы).

Снэпклоны и связанные клоны возможно также подключать к хосту в виде отдельных LUN или файловых систем.

Группы консистентности связанных клонов¶

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

Миграция блочных устройств «на лету»¶

СХД АЭРОДИСК ENGINE поддерживает функционал миграции блочных устройств на RDG и DDP «на лету» прозрачно для конечного потребителя. Функционал может быть полезен для перемещения данных на другой уровень RAID, например, с RAID5 на RAID10 для увеличения производительности. Также данные могут быть перемещены на другой тип дисков, например, с NLSAS-дисков на SSD-диски. Возможны любые направления перемещения блочных устройств между типами дисков и типами рейдов.

Миграция данных с внешних СХД¶

СХД АЭРОДИСК ENGINE позволяет провести онлайн миграцию данных блочных устройств с внешних СХД. Миграция проходит в несколько этапов. На первом этапе на СХД АЭРОДИСК ENGINE создается точная копия блочного устройства с внешней СХД. Блочное устройство с внешней СХД презентуется СХД АЭРОДИСК ENGINE и начинается внутреннее фоновое копирование данных с внешней СХД на блочное устройство на СХД АЭРОДИСК ENGINE. Хосту презентуется блочное устройство с СХД как еще один путь до существующего блочного устройства с параметром «резервный».

После завершения фонового копирования данных резервный путь до LUN на СХД АЭРОДИСК ENGINE становится основным и весь ввод/вывод переключается на него.

Последним шагом является отключение резервного пути старой блочной СХД.

Все манипуляции с путями и фоновым копированием для хоста являются полностью прозрачными.

Удалённая репликация блочных данных¶

Репликация является функцией, которая обеспечивает защиту данных, используя две и более СХД на различных площадках.

Репликация является необходимым компонентом технического решения, если требуется организовать план аварийного восстановления (DRP) нарезервной площадке.

Синхронная репликация обеспечивает абсолютную идентичность данных на обеих или более СХД.

При синхронной репликации транзакции записи применяются только после подтверждения их записи на всех участниках репликации, поэтому для синхронной репликации следует использовать каналы связи с высокой пропускной способностью и низкими задержками.

Синхронная репликация выполняется на уровне блочного устройства LUN. Для файловых систем синхронная репликация не поддерживается

Асинхронная репликация обеспечивает идентичность данных на СХД с задержкой, которая зависит от качества канала связи. Степень отставания полученных данных от исходных задавать нельзя.

При асинхронной репликации транзакции записи вначале подтверждаются и применяются на исходной СХД, и только после этого происходит передача данных на другие СХД. После получения реплики получатели подтверждают и применяют транзакции.

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

Исходя из этого, для асинхронной репликации не требуются каналы связи с высокой пропускной способностью и низкими задержками.

Синхронная и асинхронная репликацию могут использоваться одновременно. Режим репликации задается для каждого блочного устройства по отдельности.

Для репликации доступны следующие топологии: 1:1, 1:n, n:1, n:m. Хосты могут подключаться к СХД по FC и iSCSI. Каждый хост подключается только к локальной СХД.

Метрокластер¶

Для автоматизации процессов переключения между площадками можно создать метрокластер. В этой архитектуре присутствуют 2 СХД и арбитр, который управляет переключениями между площадками. Арбитр развертывается на виртуальном или физическом сервере под управлением Alt Linux. При работе в режиме метрокластера серверы подключаются к СХД только по протоколу iSCSI, причем каждый сервер должен иметь доступ к обеим СХД. Пример организации метрокластера представлен на картинке ниже.

Удаленная репликация файловых данных¶

СХД АЭРОДИСК ENGINE поддерживает репликацию данных в асинхронном режиме. Репликация построена на базе снэпшотов с синхронизацией изменений между системами хранения данных. Частота создания снэпшотов и, соответственно, максимальное отставание резервной СХД от основной, задается в интерфейсе управления.

Репликация данных между системами хранения данных всегда производится по IP-каналам. На вторую СХД передаются только вносимые изменения в асинхронном режиме. Поэтому особых требований к ширине каналов связи файловая репликация не предъявляет.

Доступ к данным возможен по протоколам CIFS и NFS. На файловый ресурс – источник возможны запись и чтение, на приемник – только чтение.

Ускорение ввода/вывода для HDD-дисков¶

Для реализации максимальной производительности и гибкости в СХД АЭРОДИСК ENGINE предусмотрена функция ускорения ввода/вывода для HDD-дисков. Данная функция разделяется на три подфункции:

• SSD-кэш (SSD RW)

• SSD-кэш и хранение метаданных (SSD RW + MCACHE);

• Online-tiering (SSD online-tiering)

3.13 VLAN и BONDING¶

Для ускорения операций ввода/вывода можно задействовать функционал объединения нескольких физических портов в один логический порт-BOND интерфейс. Поддерживаются как независимые от настроек коммутаторов BOND-интерфейсы, так и зависимые от настроек коммутаторов BOND-интерфейсы. Объединение нескольких физических интерфейсов дает увеличение пропускной способности, а также повышает уровень отказоустойчивости, так как в рамках BOND-интерфейса физический порт может выйти из строя и обмен данными при этом не прекратится. В BOND-интерфейс можно объединить до 16 физических однотипных интерфейсов.

Для разграничения сетевого доступа, а также для более гибкой настройки СХД под сетевую инфраструктуру заказчика можно задействовать механизм тегирования трафика – VLAN. VLAN могут быть назначены как на физические сетевые интерфейсы, так и на BOND-интерфейсы. VLAN могут быть применены как для файловых шар для протоколов NFS/CIFS, так и для блочного доступа по iSCSI.

Quality of Service¶

Настройка качества обслуживания (QoS) позволяет минимизировать эффект «шумного соседа». При правильной настройке этого параметра можно гарантировать, что все потребители ресурсов СХД будут работать так, как ожидает администратор системы. QoS в СХД АЭРОДИСК ENGINE назначаются на блочные устройства. Параметры качества обслуживания назначаются на уровне каждого конкретного LUN и могут ограничивать его потребление ресурсов в MB/s и IOPS. На картинке ниже приведен пример установки ограничений на LUN02, на котором по расписанию стартует множество ВМ, что является распространённым сценарием при использовании VDI.

Политика перестроения¶

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

При работе с пулами DDP задается максимальная скорость перестроения в МБ/с при выходе из строя диска в пуле. Настройка относится к каждому из дисков пула.

Виртуализация сторонних СХД¶

СХД АЭРОДИСК ENGINE позволяют виртуализовать дисковую емкость сторонних СХД по протоколам FC/iSCSI. Для этого на внешних СХД необходимо создать набор блочных устройств, который будет презентован СХД АЭРОДИСК ENGINE. После этого на презентованных блочных устройствах можно делать стандартные для СХД АЭРОДИСК виртуальные рейды: RDG и/или DDP, на которых впоследствии можно создавать объекты хранения – блочные устройства и файловые шары.

Дедупликация¶

Дедупликация – это процесс устранения дублей блоков данных при сохранении уникальных блоков для экономии дискового пространства.

На рисунке ниже приведен результат работы дедупликации.

Основное:

• В системах АЭРОДИСК применяется онлайн-дедупликация с фиксированным блоком

• Дедупликация работает на RDG, на SSD и на жёстких дисках

• Для RDG можно включать на конкретный LUN

• Для файловых систем дедупликация и компрессия включаются на уровне RDG в целом

• Делит входящие данные на равные блоки

• В СХД должен быть достаточный объём оперативной памяти для работы дедупликации

• Устраняет дубли только тогда, когда блоки на 100% совпадают

Процесс дедупликации происходит следующим образом:

• Снятие хэш-сумм с блоков данных

• Сравнение хэш-сумм

• При условии совпадения контрольных сумм блоков данных система вместо выделения нового дискового пространства под дубль добавляет ссылку в таблицу дедупликации, которая указывает на реально существующие данные, вместо того чтобы создавать их дубли

Дедупликация выполняется на блочном уровне, что особенно эффективно для больших объемов похожих данных. Например, при дедупликации хранилища виртуальных машин (ВМ) уникальными, как правило, являются только некоторые блоки данных, а идентичные данные, такие как гостевые ОС, шаблоны ВМ, клоны ВМ и прочие являются дублируемыми и, соответственно, при дедупликации не потребляют дополнительного объема.

Для 1 ТБ дедуплицируемых данных нужно резервировать не менее 1 ГБ ОЗУ на хэш-таблицу. Для SSD-дисков это несущественный объем, а вот для оперативной памяти – наоборот. Т. к. объем оперативной памяти СХД ограничен, то рекомендуется использовать дедупликацию при наличии SSD-дисков в СХД.

Компрессия¶

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

Для выполнения компрессии транзакций «на лету» используются выделенные ядра процессора и процесс компрессии никогда не конкурирует за ресурсы. В случае, если количество операций ввода/вывода велико и ресурсов выделенного ядра перестает хватать, система «на лету» автоматически выделяет под процесс компрессии дополнительные выделенные ядра.

Ролевая модель¶

Для разграничения прав доступа к управлению СХД в АЭРОДИСК ENGINE реализована ролевая модель управления. Она позволяет группировать набор прав доступа к элементам системы в соответствии с заданным набором правил для групп пользователей и повышает надёжность и эффективность управления системой в целом.

Супер-администратор системы (admin) создаёт группы пользователей и наборы правил для них в соответствии с должностями и функционалом сотрудников. Затем вновь создаваемые учетные записи могут быть привязаны к той или иной группе пользователей роли. Права пользователя зависят от тех правил, которые были заданы при создании группы. Можно использовать локальные учетные записи пользователей или использовать службу каталогов Active Directory для аутентификации.

Ограничения, заданные для той или иной группы, выполняются и для графического интерфейса управления, и для REST API.

Информационная безопасность¶

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

• Задание минимальной длины пароля

• Задание максимальной длины пароля

• Срок действия пароля в днях

• Обязательное использование букв верхнего регистра, букв верхнего регистра, цифр, спецсимволов

Возможна настройка параметров сессии для управления СХД:

• Максимальное число попыток входа

• Время блокировки пользователя в минутах

• Максимальная продолжительность сессии

• Список разрешенных IP адресов для подключение к интерфейсу управления

Также возможна выгрузка логов на внешние серверы по протоколу Syslog.

Авто-поддержка¶

Для обеспечения максимальной доступности систем хранения АЭРОДИСК предусмотрена функция автоматической поддержки. Данная опция обеспечивает:

• Автоматическую отправку диагностической информации в АЭРОДИСК в случае сбоя

• Автоматическое открытие обращений (тикетов) в АЭРОДИСК

Открытие обращений производится путем отправки диагностической информации в виде почтовых уведомлений от контроллеров СХД на серверы поддержки АЭРОДИСК. После прихода данной информации сообщения автоматически преобразуются в тикет и регистрируются, далее специалист АЭРОДИСК, имея необходимую входную информацию, приступает к работе по устранению сбоя.