В продолжение статьи о
парадигме резервного копирования NetApp, хочу рассказать о недокументированной возможности преобразования «архивных копий» в «резервные» для серии
FAS. Отличительной чертой
СХД компании NetApp серии
FAS является то, что они все унифицированы. Унифицированность не только в том, что одно устройство предоставляет доступ хостам как по блочным, так и по файловым протоколам, но и по способу применения. Системы
FAS используются для виртуализации, для Data Compliance, для хранения архивных копий, для построения Disaster Recovery решений и т.д. Одна и та же
СХД может выполнять сразу множество функций. Так для каждой функции не нужно держать одно «специализированное» устройство, а в случае если срочно понадобится «запасная»
СХД, её всегда можно «перепрофилировать» из того что есть, к примеру из
СХД для архивации данных. Благодаря этой универсальности нет необходимости переобучаться под каждую из этих задач ведь операционная система, командная строка и все принципы настройки одни и те же для всех
FAS систем.
В этой статье я расскажу как построенное решение «Архивация данных на NetApp» переделать в решение «Disaster Recovery».
С точки зрения бизнеса Disaster Recovery и архивирование отличаются тем, что:
- Архивирование (SnapVault) — решение предназначено для длительного хранения и защиты данных от изменений, для последующего восстановления их туда, откуда они были скопированы (или в другое место).
- Disaster Recovery (SnapMirror) — хранение данных на резервном сайте, для переключения на него (и соответственно изменения данных), в случае катастрофы.
Поясню на примере: когда у вас есть хотя бы две
СХД с настроенной репликацией SnapMirror, в такой схеме одна из них играет роль источника (primary), а вторая роль приемника (Secondary). В случае аварии, при разрыве репликации (командой break, а не просто разрыв линка), принимающая (Secondary) система переведёт реплицируемое зеркало из режима read-only в режим read-write. Т.е. это инструмент для создания решения «Переключение на запасную площадку в случае аварии» (Disaster Recovery). Логично, чтобы обе системы были плюс-минус одинаковой производительности, чтобы обеспечить все переключённые узлы с одного сайта на другой, должным уровнем производительности.
В то время, как SnapVault предназначен для архивирования на резервную (Secondary) систему, чтобы потом из неё восстановить все данные обратно на первичную систему или вообще на третью систему. Стоит отметить, что для задач архивирования очень важно хранить данные в неизменённом состоянии все время. В данном случае вторичная система, куда складываются все архивы, может быть любой модели. Здесь логично иметь самую дешевую модель NetApp
FAS с медленными и дешевыми дисками большего объема. К примеру,
FAS2554 или FAS2520.
Резервное копирование данных бизнес-приложений – тема древняя, как Кобол, и вечная, как процесс исправления ошибок на Windows. Истинные джедаи системного администрирования вооружаются с этой целью самопальными скриптами, представляющими обычно такое же удивительно постмодерновое сочетание новейших технологий и допотопного мышления, как световой меч из «Звёздных Войн». Офисные же самураи, в отличие от джедаев из серверной комнаты, идут к своему менеджеру-даймё и выпрашивают у него десяток-другой «коку» риса на покупку разрекламированной фирменной обработки для бэкапа данных. (Для тех, кто не в курсе: «обработкой» называется программа на внутреннем языке 1С, а «коку» — это такая мера объёма, которой самураи меряют свою зарплату.)
