NetApp SnapManager for Oracle & SAN сеть

SnapManager — это набор утилит компании NetApp позволяющих автоматизировать процессы снятия так называемых Application-Consistent Backup (Crash-Consistent Snapshots ^[1] (CCS) без остановки приложений, средствами СХД NetApp FAS серии, их архивации, резервного копирования, тестирования копий и архивов, клонирования, примапливания склонированных данных к другим хостам, восстановления и др. функциями через GUI интерфейс одним только лишь оператором приложения без привлечения специалистов по серверам, сети и СХД.

SnapManager for Oracle on Windows, Cloning Operation

Зачем вообще бэкапировать данные при помощи снапшотов и тем более средствами СХД? Дело в том, что большинство современных способов бэкапирования информации подразумевают длительность процесса, ресурсоёмкость: нагрузка на хост, загрузка каналов, занимание пространства и как следствие к деградации сервисов. Тоже касается и клонирования больших объемов информации для Dev/Test подразделений, увеличивая «временной разрыв» между актуальными данными и резервируемыми, это повышает вероятность того, что бэкап может оказаться «не восстановим». С применением «аппаратных» снапшотов компании NetApp, не влияющих на производительность и занимающий не положенные 100% резервной копии, а только лишь «разницу» (своего рода инкрементального бэкапа или лучше сказать обратного инкрементального бэкапа, на снятие и сборку которого не нужно тратить время), а также возможность передачи данных для резервирования и архивирования в виде снапшотов, позволяя более элегантно решать современные высокие требования бизнеса для подобных задач, уменьшая время передачи информации и нагрузку на хосты.

Компоненты SMO ^[2]

Утилита состоит из нескольких компонент: сервер, на выделенном хосте или виртуальной машине и агентов устанавливающихся на хостах с Резница между ACB и CCS ^[3]. Без купленных лицензиий SnapRestore и FlexClone, не будет доступен функционал соответственно моментального восстановления и моментального клонирования средствами СХД.

Интеграция SMO с Oracle

Лицензирование у SnapManager «поконтроллерное» в состав лицензии SnapManager входят и другие менеджеры для MS SQL, MS Exchange, MS Share Point, MS Hyper-V, VMWare vSphere, SAP, Lotus Domino и Citrix Xen Server.

SnapManager for MS SQL, Moving Operation

SnapCreator ^[4]

Пойдя по пути «оптимизации расходов», отказываясь от покупки лицензии SnapManager, нужно понимать, что управление потребуют дополнительных затрат времени и взаимодействия DBA с Server Admins, Сетевыми Администраторами и Админов СХД, для того, чтобы DBA получили вожделенную манипуляцию с DB. В то время как с SnapManager это можно выполнить нажатием пары кнопок в GUI интерфейсе, без привлечения разных специалистов и затрат времени.
Многие из выполняемых функций SnapManager можно выполнять при помощи бесплатной утилиты SnapCreator, также позволяющей интегрироваться с DB (а также большим количеством других приложений) приложениями для снятия консистентных снапшотов ACB средствами СХД. Но эта утилита не выполняет многих других удобных функций по управлению DB. Таких как клонирование DB, восстановление «in-Place», примапливание клона DB к другому хосту, автоматическое тестирование работоспособности и восстановления из архива и т.д.

Схема взаимодействия компонент SnapCreator

Scripting ^[5]

Большинство недостающего функционала в SnapCreator можно компенсировать при помощи скриптинга, который сейчас доступен с PowerShell командлетами в: DataOntap Toolkit ^[6], SnapCreator, OnCommand Unified Manager (OCUM) и многих других полезных утилит. На что несомненно потребуется время, для отладки под бизнес процессы.

Краткий ликбез по NetApp: ^[7]

Напомню парадигму устройства внутренней структуры СХД NetApp FAS: Диски объединяются в Рейд группы (RAID-DP), Рейд группы объединяются в Плексы (Plex. Используются в случае зеркалирования между СХД, аналог RAID1), Плексы объединяются в Агрегаты (Aggr), на Агрегатах создаются Вольюмы (FlexVol), данные в Вольюмах равномерно размазаны по всем дискам в Агрегате, в Вольюмах создаются Qtree (что-то типа папки, на которые можно назначать всякие квоты), Qtree не могут быть вложенными, далее внутри Qtree создаются LUN'ы.

Объекты СХД NetApp FAS

Интеграция ^[8]

SMO интегрируется с 10GR2, 11g R1/R2, 12cR1 (12.1.0.1) с технологиями RAC, RMAN, ASM, Direct NFS. Всё ниже написанное можно, как правило, также отнести и для SnapManager for MS SQL (SMSQL) и SnapCreator.

SnapManager for Oracle on Linux, Backing-up Operation

1) Что бэкапирует SMO: ^[9]

SMO бэкапирует только следующие данные:

• Data Files
• Control files
• Archive Redo logs (Archive Logs)

См. документ TR-3761 NetApp SnapManager 3.3.1 for Oracle ^[10], стр 12, таблица 1).
Redo Logs не бэкапируются, они могут бэкапироваться при помощи SnapMirror, смотри ниже ^[11].

1.1) Как бэкапируются, затираются и восстанавливаются Archive Logs: ^[12]

Средствами работает с Archive Logs ^[13].

2) Рекомендации по подготовке: ^[14]

Рекомендации по разбивке пространства на вольюмы и LUN'ы для SMO, как правило совпадают с рекомендациями "Oracle DB on NetApp".

Первым делом необходимо выключить автоматические снапшоты на вольюмах, их теперь будет инициировать Best Practices for Oracle Databases on NetApp Storage ^[15], стр. 11

Некоторые однотипные файлы от разных DB можно группировать и хранить в одном вольюме, другие разнотипные файлы нужно обязательно разделять:

• Каждый лун желательно ложить в отдельный Qtree. Это удобно в случае репликации SnapMirror Подробнее ^[16]
• Располагая каждый LUN в отдельный Qtree можно назначать квоты на её размер, генерируя алерты не на весь вольюм, а на отдельнй Qtree, при достижении определённого порога её заполненности. Это удобно для отслеживания состояния LUN по email без использования каких-либо дополнительных утилит.
• Temp Files обязательно нужно отделять от всех остальных данных, так как они очень сильно меняются в ходе эксплуатации DB и соответственно снапшоты снятые с таких данных, занимают на СХД ценное пространство.
• Снапшоты на Temp Files должны быть выключены
• Temp Files от всех DB можно складывать в один вольюм.
• Файлы DB Archive Logs, Redo Logs и собственно Data в случае с SAN каждый тип нужно держать на выделенном LUN 'е. Не стоит смешивать в одном луне файлы DB разных типов, к примеру, не стоит на одном луне держать файлы Archive Logs и Redo Log.
• LUN'ы содержащие файлы Archive Logs, Redo Log и собственно Data, каждый необходимо держать на выделенном вольюме. Т.е. для таких LUN'ов действует правило: один вольюм — один LUN (и не забываем про Qtree).
• Если, к примеру DB состоит из двух файлов Archive Logs и каждый из них лежит на отдельном LUN'е, то такие LUN'ы, в качестве исключения из правила, можно хранить в одном вольюме, т.е. иметь на один вольюм несколько LUN'ов. Тo же касается и других файлов DB, в том числе Data Files и Redo Logs.
• Копию Config Files от каждой DB желательно хранить вместе с соответствующими Redo Logs.
• Redo Logs от всех инстансов DB нужно отделять в отдельный вольюм.
• Archive Logs от всех инстансов DB нужно отделять в отдельный вольюм.
• Файлы для кластеризации от всех инстансов можно складывать в один вольюм, каждый в отдельную Qtree на этом вольюме.
• Undo Logs можно хранить с Temp Files, если их не требуется бэкапить и восстанавливать. Или вместе с Redo Logs, имея возможность их бэкапировать, восстанавливать и использовать на DR сайте (в случае применения репликации). Также можно держать Undo Logs на выделенном вольюме.

Все эти требования по отделению Redo Logs, Archive Logs, Data Files и Temp Files вытекают из следующего:

1. Temp Files не нужны для бэкапирования и восстановлени, но из-за того что они сильно изменяются в случае применения к ним снапшотов, будут нещадно поедать пространство на СХД, занимая его бесполезными данными.
2. Если хранить те же Temp Files вместе с другими типами файлов DB, которые будут бэкапироваться снапшотами, они поедают пространство (см. предыдущий пункт) и как следствие съев всё пространство могут привести к ситуации с уходом LUN'ов (в этом вольюме котором закончилось пространство) в Offline.
3. В случае с применением SnapMirror VSM репликации используются снапшоты, а если мы имеем «смешанные в одну кучу» данные от DB, то смотри два предыдущих пункта про Temp Files. Плюс ко всему прочему на удалённую систему будут постоянно отсылаться никому не нужные данные, загружая канал связи.
4. В случае с применением SnapMirror QSM или SnapVault репликации, вопрос с загрузкой канала связи можно обойти разместив данные в одном вольюме, данные которого необходимо реплицировать, в отдельный(ные) Qtree и реплицировать только их, не нагружая канал связи, но вопрос со снапшотами всё-равно не обойти (см. первые два пункта), так как снапшоты снимаются на весь вольюм «целиком».
5. С другой стороны «логика один LUN — один вольюм» исходит из возможной необходимости восстанавливать не все DB, а только одну или несколько. Для восстановления можно применять функционал SnapRestore с одним из подходов: SFSR или VBSR. VBSR более быстрый, так как не требует прохождения по структуре WAFL, так как VBSR работает на блочном уровне с вольюмами восстановятся все данные внутри него. Таким образом при хранении в одном вольюме нескольких DB или их частей, можно «нечаянно» заодно восстановить более старую версию (части) другой DB. Чтобы этого не происходило, в связи с чем имеем рекомендацию: один вольюм — один LUN, для всех данных которые возможно потребуется восстанавливать.
6. В случае использования файлового доступа, такого как NFS или Direct NFS, вместо блочного доступа, суть всего вышесказанного относительно разделения файлов DB по разным вольюмам сохраняется, с той только разницей, что экспорт NFS выполняется на уровне Qtree или Volume вместо LUN. А также возможностью более гранулярного восстановления файлов DB с применением SFSR.

2.1) Можно ли чтобы одна база жила на нескольких контроллерах (вольюмах) при использовании SnapManager? ^[17]

На уровне создания снапшотов это называется Consistency Groups ^[18], что поддерживается DataOntap 7.2 или выше. Но это требуется только в случае ASM. В случае без ASM, Oracle сам справляется с консистентностью бэкапа базы, которая распределена по разным контроллерам (вольюмам).

В виду нашего случая с применением SAN, хочу обратить ваше внимание на следующие нюансы:

2.2) Thin Provisioning: ^[19]

В случае использования Thin Provisioning и нескольких другие современные ОС ^[20]) или выше с поддержкой Logical Block Provisioning как определено в стандарте SCSI SBC-3 (что часто называют SCSI Thin Provisioning), который «объясняет» ОС, что LUN на самом деле «тонкий» и место на нём «на самом деле закончилось», запрещая проводить операции записи. Таким образом, ОС должна перестать писать в такой LUN, а он сам не будет переведен в Offline и останется доступен только на чтение для ОС (другой вопрос как на это отреагирует приложение). Этот функционал также предоставляет возможность использования Space Reclamation. Таким образом современные ОС теперь более адекватно работают в режиме тонкого планирования с LUN'ами.

2.3) SAN & SnapShots: ^[21]

В случае использования снапшотов (а в будут использованы ^[9]) и хранения нескольких в предыдущем пункте ^[19], что произойдёт. Ситуация частично решается выделением эмпирически подобранного резерва под снапшоты, настройки удаления более старых снапшотов (snap autodelete) и автоматического увеличения вольюма (volume autogrow). Но хочу обратить ваше внимание что высвобождение пространства произойдёт, уже после того, как Fractional reserve и почему LUN 'ы обычно только растут можно посмотреть тут ^[22].

2.4) Space Reclamation: ^[23]

В случае предыдущий пункт ^[19]. Space Reclamation, позволяет Thin проблему постоянного роста Thin LUN'ов ^[24]". Так как без Space Reclamation LUN'ы всегда только «ростут» в случае Thin LUN и даже для «толстых» LUN'ов отсутствие Space Reclamation выливается в «снапшоты-переростки», которые захватывают в себя никому не нужные уже давно удаленные блоки данных. По-сему Space Reclamation маст хэв.

3) Отображаются ли бэкапы в RMAN? ^[25]

Бэкапы созданные NetApp SnapManager 3.3.1 for Oracle ^[10], стр 11. Рекомендуется использовать что-то одно: или RMAN или SMO.

4) Планируется ли бэкапирование Redo Logs при помощи SMO в будущем? ^[11]

Бэкапирование Redo Logs и Archive Logs выполняются с помощью репликации SnapMmirror в синхронном, полу-синхронном или асинхронном режиме. Использование SnapMirror подразумевает применение снапшотов (без взаимодействия с Database recovery using SnapMirror Async and Sync ^[26], Глава 12, стр 17.

5) Можно ли Undo Log и Temp Files держать вместе? ^[27]

Undo Logs можно хранить вместе с Temp Files, Redo Logs или Archive Logs. Это не должно нарушать беспрактисов. SMO не работает с Temp Files по этому Undo Logs можно хнанить вместе с ними.
Если всё-же хранить Undo Logs вместе с Archive Logs или Redo Logs, то Undo Logs будет бэкапироваться (и соответственно занимать место) вместе с ними.

Для доступа к некоторым документам может понадобится NetApp NOW ID. Если вы берете СХД NetApp на тест, ваш дистрибютор/интегратор поможет загрузить их.

Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания и дополнения напротив прошу в комментарии

Автор: bbk

Источник ^[28]