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

Увеличить

Обновление прикладного ПО, миграция схемы базы данных, массовый импорт — любая из этих операций может закончиться так, что сервер нужно вернуть в состояние «как было час назад». Восстановление из резервной копии в таких случаях часто занимает часы. MegaRAID Recovery предлагает другой путь: зафиксировать состояние виртуального диска перед рискованной операцией и при необходимости быстро откатиться к этой точке на уровне RAID-контроллера.

Разберём, как устроена функция, где она полезна, чем снимок отличается от резервной копии и что проверить перед активацией.

Что такое MegaRAID Recovery

MegaRAID Recovery — программная функция для совместимых RAID-контроллеров LSI MegaRAID и Broadcom. Она добавляет аппаратно управляемые снимки (snapshots) виртуальных дисков: администратор фиксирует состояние тома в определённый момент и при необходимости возвращается к сохранённой точке.

Снимки создаёт и обслуживает сам контроллер, а не операционная система. Поэтому функция не зависит от файловой системы и гипервизора: для контроллера виртуальный диск — это набор блоков, и снимок фиксирует именно их состояние.

Recovery входит в пакет MegaRAID Advanced Software Options вместе с другими расширенными функциями:

На совместимом контроллере эти функции открываются постоянным ключом активации: заказать активацию MegaRAID Advanced Software Options.

Как работает снимок

В момент создания snapshot контроллер фиксирует состояние исходного виртуального диска. Дальше действует принцип отслеживания изменений: когда на исходный том записываются новые данные, контроллер сохраняет прежнее содержимое изменяемых блоков в отдельную область. Благодаря этому сохранённая точка продолжает представлять данные ровно на момент снимка, а исходный том продолжает работать в обычном режиме.

Из этого следуют три практических вывода.

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

Под изменения нужен резерв ёмкости. Прежние версии блоков где-то хранятся, и это пространство нужно выделить заранее. Если оно закончится, ожидаемая глубина восстановления может оказаться недоступной — причём обнаружится это в самый неподходящий момент.

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

Где пригодятся снимки

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

• обновление прикладного ПО;

• изменение структуры базы данных;

• установка системных обновлений и драйверов;

• массовая обработка или импорт данных;

• изменение конфигурации виртуальных машин;

• тестирование новой версии сервиса.

Типичный сценарий выглядит так: администратор останавливает запись в приложение, создаёт снимок, выполняет обновление и проверяет работу сервиса. Если всё в порядке, снимок удаляется или хранится по регламенту. Если обновление прошло неудачно — том откатывается к точке до начала работ, и сервис возвращается в рабочее состояние без длительного восстановления из бэкапа.

Согласованность данных

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

Поэтому перед созданием снимка для базы данных или виртуальной машины может потребоваться:

• остановить или приостановить запись в приложение;

• сбросить кэши операционной системы и СУБД на диск;

• перевести базу данных в режим, пригодный для резервного копирования;

• использовать средства самого приложения для фиксации согласованного состояния.

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

Чем snapshot отличается от резервной копии

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

MegaRAID Recovery помогает быстро вернуться к прежнему состоянию виртуального диска. Но снимок обычно хранится на том же контроллере и той же дисковой подсистеме, что и исходные данные. Если с этой подсистемой что-то случится, пострадают и данные, и снимки.

Снимок не защищает от:

• физической потери сервера;

• критического отказа всего массива или контроллера;

• пожара, затопления или кражи;

• ошибки, обнаруженной уже после удаления нужной точки;

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

Поэтому Recovery дополняет, но не заменяет независимые резервные копии по правилу 3-2-1 — три копии данных, на двух разных типах носителей, одна из которых хранится вне основной площадки, — и регулярные тесты восстановления.

Планирование снимков

Прежде чем включать Recovery в рабочей инфраструктуре, ответьте на несколько вопросов:

1. Какие виртуальные диски защищать? Обычно это тома с системами и данными, которые часто обновляются и дорого восстанавливаются из бэкапа.

2. Когда создавать снимки? Перед плановыми работами, по расписанию или в обоих случаях.

3. Сколько точек восстановления нужно? Больше точек — выше расход ёмкости и сложнее управление.

4. Какой объём зарезервировать под изменения? Это главный вопрос планирования (см. ниже).

5. Кто может создавать и удалять точки? Удаление снимка необратимо, и права на него стоит ограничить.

6. Как проверять восстановление? Откат тома — это ещё не восстановление сервиса. Нужен сценарий, подтверждающий, что приложение после отката работает.

Как оценить резерв ёмкости

Объём, необходимый для хранения изменений, зависит не столько от размера исходного тома, сколько от интенсивности записи и срока хранения снимка. Том на 2 ТБ с архивом, куда почти ничего не пишется, потребует минимального резерва. Том на 500 ГБ с активной базой данных может за сутки перезаписать значительную часть своих блоков.

Практичный подход:

• оцените, сколько данных записывается на том за типичный период хранения снимка — по статистике СУБД, мониторингу дисковой подсистемы или счётчикам ОС;

• заложите запас на пиковую нагрузку: ночные задания, пересборку индексов, массовые загрузки;

• настройте контроль заполнения резервной области и реагируйте на него до исчерпания.

Планирование только по объёму исходного тома без учёта интенсивности записи даёт неточный результат.

Что проверить перед активацией

Для подбора лицензии и безопасного включения Recovery потребуются:

• точная модель и чип RAID-контроллера;

• версия firmware;

• список уже активированных и доступных Advanced Software Options;

• конфигурация виртуальных дисков;

• свободная ёмкость для хранения изменений;

• актуальная и проверенная резервная копия.

Основные сведения о контроллере можно получить через StorCLI:

storcli show

storcli /c0 show

storcli /c0 /vall show

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

Перед созданием снимка и особенно перед откатом сверьте процедуру с руководством для установленной версии StorCLI или MegaRAID Storage Manager. Откат перезаписывает текущее состояние тома — всё, что было записано после снимка, будет потеряно.

Trial и постоянный ключ

Broadcom публикует 30-дневные trial-ключи MegaRAID Advanced Software Options для лабораторной оценки. Производитель ограничивает их применение non-production системами, поэтому trial подходит, чтобы:

• убедиться, что контроллер поддерживает функцию;

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

• оценить расход ёмкости при реальном профиле нагрузки;

• подготовить внутренний регламент для рабочей среды.

Проводите проверку на тестовых данных с заранее подготовленным сценарием отката — не на рабочих томах.

Для рабочей инфраструктуры нужна постоянная активация. Подготовьте модель контроллера, версию firmware и вывод storcli /c0 show. Serverbay проверит конфигурацию и подберёт ключ с Recovery, CacheCade Pro 2.0, FastPath и SafeStore.

Итоги

• MegaRAID Recovery даёт аппаратно управляемые снимки виртуальных дисков и быстрый откат к точке восстановления.

• Снимок создаётся за секунды, но требует заранее выделенного резерва ёмкости, объём которого зависит от интенсивности записи.

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

• Снимок хранится на той же дисковой подсистеме и не заменяет независимые резервные копии.

• Возможности зависят от модели контроллера и firmware; перед покупкой ключа и внедрением проверьте конфигурацию и отработайте сценарий на trial-ключе в тестовой среде.