Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Наладить резервное копирование СУБД Oracle инструментами того же вендора — просто. А если попытаться оптимизировать стоимость решения? Тогда возможные ИТ-инструменты стоит придирчиво рассмотреть в действии. Так и получилось: в поиске ответа на запрос заказчика обнаружилось, когда стоит «женить» Oracle и NBU, а когда лучше это не делать. Делимся опытом тестирования системы резервного копирования Veritas NBU для защиты данных в СУБД Oracle и интересными нюансами процесса настройки.
Один из наших клиентов — ритейлер федерального масштаба — озаботился резервированием данных в СУБД Oracle. По умолчанию для этого подходит Oracle Zero Data Loss Recovery Appliance (ZDLRA). Но стоит комплекс как круизный ледокол. К тому же ZDLRA не дал бы клиенту контролировать все процессы резервного копирования через единую консоль. Эти соображения заставили искать альтернативы. Одной из них стало устройство Veritas NetBackup Appliance 5240 — СРК среднего уровня с хорошей производительностью в стандартных условиях. Оптимизма добавляла и технология Copilot в арсенале Veritas, предназначенная специально для работы с СУБД Oracle.
Прежде чем испытывать Veritas NetBackup Appliance 5240 в «живой» инфраструктуре, заказчик попросил протестировать его. Мы собрали стенд и проверили решение в боевых условиях. Выводы оказались любопытными.
Сначала мы оценили, какие уникальные технологии могут ускорить процессы резервного копирования и восстановления. Поскольку речь шла о резервном копировании СУБД Oracle, а в качестве сетевого подключения использовался 10 GbE (никаких Fiber Channel), наиболее полезными оказались следующие инструменты Veritas:
Больше других надежду в контексте СУБД Oracle дарила технология NetBackup Copilot. В тестировании мы сфокусировались на проверке ее производительности в сравнении с обычными инкрементальными копиями БД.
Мы развернули тестовый стенд, который включал в себя NetBackup Master Server, NetBackup Media Server и Oracle Linux Server 6.7. NetBackup Appliance (выступал в роли NetBackup Media Server) был подключен к базе данных через два порта 10 GbE, а NetBackup Master Server развернули на виртуальной машине в среде виртуализации VMware vSphere 6.0.
В качестве источника РК использовали физический сервер с установленной ОС Oracle Linux Enterprise 6.7 и СУБД Oracle 19. Чтобы смоделировать работу системы в условиях, близких к требованиям заказчика, объем тестовой базы Oracle мы установили в размере 1 Tб в формате Bigfile. База данных находилась под нагрузкой, а объем изменений в течение 12 часов составлял 50-60% от изначального объема базы.
Итак, поехали! Мы запустили резервное копирование, но уровень производительности оказался удивительно низким — 2,3–2,8 TB/h. По результатам — привет из 90-х! В документах по работе Veritas NBU с СУБД Oracle готовых решений для сложившейся ситуации не было. Но сам факт наличия Copilot и хорошая производительность решения на стандартных задачах, как, например, резервное копирование файловых систем, наводили на мысль, что мы упускаем из виду какие-то моменты. Тогда вместе с коллегами из Veritas мы начали поиск тонких настроек NetBackup, которые повысили бы производительность.
Мы проверили несколько десятков настроек и нашли для них оптимальные значения. В числе параметров, которые влияли на производительность тестового стенда, оказались:
Мы возлагали большие надежды на NetBackup Copilot — все-таки эта технология изначально создавалась для работы с СУБД и использует Oracle incremental merge, чтобы перейти на схему резервного копирования forever incremental. При работе в режиме Copilot система взаимодействует с менеджером резервного копирования СУБД Oracle RMAN для запуска команд резервного копирования СУБД.
Если разложить процесс резервного копирования с использованием NetBackup Copilot по стадиям, он выглядит так:
Плюсов у такого решения много. Например, мгновенные снимки файловой системы NFS-хранилища устройства NetBackup Appliance могут автоматически дублироваться (перемещаться) на наиболее эффективный уровень хранения: диск, пул дедупликации, лента, облачное хранилище, или реплицироваться на устройство NetBackup на резервной площадке. Это делается за счет политик управления жизненным циклом (SLP).
Кроме этого, администраторы СУБД могут использовать утилиты резервного копирования и восстановления Oracle. Инкрементальные копии позволяют работать с большим количеством точек восстановления, а все копии находятся в файловом хранилище, которым не нужно управлять.
Насколько же быстро все это работает? После оптимизации и ручной настройки отдельных параметров мы получили вполне приличную скорость резервного копирования.
В таблице даны сводные результаты создания полной резервной копии с включенной и выключенной дедупликацией на клиенте, включенной и выключенной «срезкой» Redo logs, в условиях, когда СУБД находится под нагрузкой и без нагрузки.
Система резервного копирования NBU показала хорошую скорость записи резервных копий. Очевидным узким местом в нашем тесте оказалась дисковая подсистема Veritas Appliance в модели 5240 (количество дисков в RAID-группе и скорость работы интерфейса). В тестировании использовалась минимальная конфигурация с одной дисковой полкой.
Чтобы оценить производительность в режиме создания инкрементальных резервных копий, мы проводили копирование 2 раза в сутки в 10:00 и 22:00. СУБД находилась под нагрузкой, а дедупликация на клиенте была включена.
Время создания инкрементальных копий было намного меньше, но и скорость сессий резервного копирования также оказалась ниже.
В режиме Copilot ситуация выглядит иначе. В нашем тесте создание резервной копии происходило каждые 12 часов, а время резервного копирования фиксировалось от момента создания снапшота Oracle до окончания момента записи резервной копии в storage pool на устройстве NBU.
Результаты этого теста оказались средними. Однако стоит учитывать, что синтезирование резервной копии с последующей записью в storage pool происходило в NFS Share. Возможно, частично за низкую производительность отвечают дополнительные ограничения скорости чтения и записи NFS Share. К тому же для более «старших» моделей NetBackup Appliance существует технология Optimized Share, так что скорость работы в подобном режиме должна быть выше. Мы использовали Veritas Appliance в минимальной конфигурации с одной полкой, тогда как вендор рекомендует применять минимум две полки для режима Copilot.
Таким образом, главным преимуществом использования Copilot остается восстановление последней полной резервной копии без необходимости наката инкрементальных копий. Использование функции Instant Restore для быстрого доступа к СУБД еще в процессе восстановления также является большим плюсом.
Вернемся к случаю заказчика. Тестирование на синтетической БД оказалось полезным, так как помогло клиенту увидеть все «за» и «против» первоначально симпатичного решения. Поиграв с параметрами, мы пришли к выводу, что использовать Veritas NetBackup целесообразно для СУБД размером до 50 Тб, а также при суточных изменениях в БД не более 25%. Поскольку БД розничной сети менялись каждые сутки на 50%, то Veritas NetBackup не стал подходящим решением.
Побочный эффект нашего тестирования оказался ценным. Мы нашли оптимальные режимы для работы Veritas NBU вместе с СУБД Oracle. За счет настройки параметров и выбора режима (классическая копия или Copilot) можно создать достойную и более доступную альтернативу для резервного копирования и восстановления СУБД Oracle при относительно небольшом количестве суточных изменений в БД в десятки Тб. Для тех, кто уже пользуется СРК Veritas, такой выход оптимален. Это использование более доступной по стоимости СРК и управление всем резервным копированием через одну консоль.
Автор: Артем Хмеленко, инженер систем хранения данных «Инфосистемы Джет»
Один из наших клиентов — ритейлер федерального масштаба — озаботился резервированием данных в СУБД Oracle. По умолчанию для этого подходит Oracle Zero Data Loss Recovery Appliance (ZDLRA). Но стоит комплекс как круизный ледокол. К тому же ZDLRA не дал бы клиенту контролировать все процессы резервного копирования через единую консоль. Эти соображения заставили искать альтернативы. Одной из них стало устройство Veritas NetBackup Appliance 5240 — СРК среднего уровня с хорошей производительностью в стандартных условиях. Оптимизма добавляла и технология Copilot в арсенале Veritas, предназначенная специально для работы с СУБД Oracle.
Прежде чем испытывать Veritas NetBackup Appliance 5240 в «живой» инфраструктуре, заказчик попросил протестировать его. Мы собрали стенд и проверили решение в боевых условиях. Выводы оказались любопытными.
Плюсы Veritas NBU
Сначала мы оценили, какие уникальные технологии могут ускорить процессы резервного копирования и восстановления. Поскольку речь шла о резервном копировании СУБД Oracle, а в качестве сетевого подключения использовался 10 GbE (никаких Fiber Channel), наиболее полезными оказались следующие инструменты Veritas:
- Media Server Deduplication Pool (MSDP) — дедупликация данных «на лету», которая оптимизирует репликацию резервных копий между устройствами и создает синтетические полные резервные копии за время инкрементальных;
- NetBackup Optimized Duplication устраняет избыточность передаваемых данных за счет передачи только уникальных блоков, которые отсутствуют на принимающем устройстве;
- NetBackup Copilot сокращает время создания резервных копий СУБД Oracle, используя мгновенные снимки файловой системы устройства NetBackup и интеграцию с менеджером резервного копирования Oracle RMAN.
Больше других надежду в контексте СУБД Oracle дарила технология NetBackup Copilot. В тестировании мы сфокусировались на проверке ее производительности в сравнении с обычными инкрементальными копиями БД.
К тестированию готовы? Да, но нет
Мы развернули тестовый стенд, который включал в себя NetBackup Master Server, NetBackup Media Server и Oracle Linux Server 6.7. NetBackup Appliance (выступал в роли NetBackup Media Server) был подключен к базе данных через два порта 10 GbE, а NetBackup Master Server развернули на виртуальной машине в среде виртуализации VMware vSphere 6.0.
В качестве источника РК использовали физический сервер с установленной ОС Oracle Linux Enterprise 6.7 и СУБД Oracle 19. Чтобы смоделировать работу системы в условиях, близких к требованиям заказчика, объем тестовой базы Oracle мы установили в размере 1 Tб в формате Bigfile. База данных находилась под нагрузкой, а объем изменений в течение 12 часов составлял 50-60% от изначального объема базы.
Итак, поехали! Мы запустили резервное копирование, но уровень производительности оказался удивительно низким — 2,3–2,8 TB/h. По результатам — привет из 90-х! В документах по работе Veritas NBU с СУБД Oracle готовых решений для сложившейся ситуации не было. Но сам факт наличия Copilot и хорошая производительность решения на стандартных задачах, как, например, резервное копирование файловых систем, наводили на мысль, что мы упускаем из виду какие-то моменты. Тогда вместе с коллегами из Veritas мы начали поиск тонких настроек NetBackup, которые повысили бы производительность.
Мы проверили несколько десятков настроек и нашли для них оптимальные значения. В числе параметров, которые влияли на производительность тестового стенда, оказались:
- значения Jumbo Frame (размеры фреймов Ethernet, в которых можно передавать данные);
- политика передачи хэша (xmit_hash_policy), напрямую влияющая на скорость и эффективность резервного копирования;
- размеры буферов (Number Disk, Size Disk) Veritas Appliance требовалось менять для резервного копирования часто меняющейся БД
Использовать ли Copilot?
Мы возлагали большие надежды на NetBackup Copilot — все-таки эта технология изначально создавалась для работы с СУБД и использует Oracle incremental merge, чтобы перейти на схему резервного копирования forever incremental. При работе в режиме Copilot система взаимодействует с менеджером резервного копирования СУБД Oracle RMAN для запуска команд резервного копирования СУБД.
Если разложить процесс резервного копирования с использованием NetBackup Copilot по стадиям, он выглядит так:
- на устройстве NetBackup Appliance настраивается устройство хранения резервных копий, доступное серверу СУБД Oracle по протоколу NFS;
- после этого настраивается политика резервного копирования в консоли администрирования СРК NetBackup;
- сам процесс резервного копирования начинается с создания базовой копии (level-0), после чего выполняются только инкрементальные резервные копии (level-1);
- изменения, возникающие с момента создания базовой резервной копии level-0, применяются к образу, который актуализируется на момент создания последней резервной копии level-1;
- NetBackup создает мгновенные снимки образа резервной копии на NFS-хранилище устройства (используя функции интегрированного в устройство ПО InfoScale);
- каждая резервная копия и мгновенный снимок добавляются в каталог менеджера резервных копий Oracle RMAN и в служебную базу данных NetBackup.
Плюсов у такого решения много. Например, мгновенные снимки файловой системы NFS-хранилища устройства NetBackup Appliance могут автоматически дублироваться (перемещаться) на наиболее эффективный уровень хранения: диск, пул дедупликации, лента, облачное хранилище, или реплицироваться на устройство NetBackup на резервной площадке. Это делается за счет политик управления жизненным циклом (SLP).
Кроме этого, администраторы СУБД могут использовать утилиты резервного копирования и восстановления Oracle. Инкрементальные копии позволяют работать с большим количеством точек восстановления, а все копии находятся в файловом хранилище, которым не нужно управлять.
А если на скорость?
Насколько же быстро все это работает? После оптимизации и ручной настройки отдельных параметров мы получили вполне приличную скорость резервного копирования.
В таблице даны сводные результаты создания полной резервной копии с включенной и выключенной дедупликацией на клиенте, включенной и выключенной «срезкой» Redo logs, в условиях, когда СУБД находится под нагрузкой и без нагрузки.
| Type | Job Schedule | DB Load | Client deduplication | Redo logs | Elapsed Time | Speed TB/h |
| Backup | Full | Yes | Enable | Disable | 0:14:06 | 4,4 |
| Backup | Full | Yes | Disable | Disable | 0:18:22 | 4,2 |
| Backup | Full | Yes | Enable | Enable | 0:22:36 | 4,1 |
| Backup | Full | Yes | Disable | Enable | 0:30:07 | 3,6 |
| Backup | Full | No | Enable | Disable | 0:12:16 | 4,7 |
| Backup | Full | No | Disable | Disable | 0:16:45 | 4,2 |
| Backup | Full | No | Enable | Enable | 0:16:15 | 4,3 |
| Backup | Full | No | Disable | Enable | 0:17:40 | 3,9 |
Система резервного копирования NBU показала хорошую скорость записи резервных копий. Очевидным узким местом в нашем тесте оказалась дисковая подсистема Veritas Appliance в модели 5240 (количество дисков в RAID-группе и скорость работы интерфейса). В тестировании использовалась минимальная конфигурация с одной дисковой полкой.
Делаем инкрементальные копии
Чтобы оценить производительность в режиме создания инкрементальных резервных копий, мы проводили копирование 2 раза в сутки в 10:00 и 22:00. СУБД находилась под нагрузкой, а дедупликация на клиенте была включена.
| Type | Job Schedule | DB Load | Client deduplication | Elapsed Time | Speed TB/h |
| Backup | Incremental 10:00 | Yes | Enable | 0:10:58 | 2,2 |
| Backup | Incremental 22:00 | Yes | Enable | 0:09:58 | 2,2 |
| Backup | Incremental 10:00 | Yes | Enable | 0:10:03 | 2,3 |
| Backup | Incremental 22:00 | Yes | Enable | 0:09:04 | 2,2 |
| Backup | Incremental 10:00 | Yes | Enable | 0:11:13 | 2,3 |
| Backup | Incremental 22:00 | Yes | Enable | 0:12:01 | 2,2 |
| Backup | Incremental 10:00 | Yes | Enable | 0:12:21 | 2,3 |
| Backup | Incremental 22:00 | Yes | Enable | 0:10:53 | 2,5 |
| Backup | Incremental 10:00 | Yes | Enable | 0:12:03 | 2,3 |
| Backup | Incremental 22:00 | Yes | Enable | 0:12:04 | 2,2 |
| Backup | Incremental 10:00 | Yes | Enable | 0:12:13 | 2,3 |
| Backup | Incremental 22:00 | Yes | Enable | 0:12:01 | 2,2 |
| Backup | Incremental 10:00 | Yes | Enable | 0:12:21 | 2,3 |
| Backup | Incremental 22:00 | Yes | Enable | 0:10:53 | 2,5 |
Время создания инкрементальных копий было намного меньше, но и скорость сессий резервного копирования также оказалась ниже.
Включаем режим Copilot
В режиме Copilot ситуация выглядит иначе. В нашем тесте создание резервной копии происходило каждые 12 часов, а время резервного копирования фиксировалось от момента создания снапшота Oracle до окончания момента записи резервной копии в storage pool на устройстве NBU.
| Type | DB Load | Elapsed Time | Megabytes | Speed TB/h |
| Backup | Yes | 0:36:53 | 1 294 153 | 2,6 |
| Backup | Yes | 0:32:14 | 1 126 525 | 2,5 |
| Backup | Yes | 0:33:34 | 1 152 365 | 2,7 |
| Backup | Yes | 0:31:23 | 1 123 620 | 2,6 |
| Backup | Yes | 0:44:04 | 1 681 999 | 2,9 |
Результаты этого теста оказались средними. Однако стоит учитывать, что синтезирование резервной копии с последующей записью в storage pool происходило в NFS Share. Возможно, частично за низкую производительность отвечают дополнительные ограничения скорости чтения и записи NFS Share. К тому же для более «старших» моделей NetBackup Appliance существует технология Optimized Share, так что скорость работы в подобном режиме должна быть выше. Мы использовали Veritas Appliance в минимальной конфигурации с одной полкой, тогда как вендор рекомендует применять минимум две полки для режима Copilot.
Таким образом, главным преимуществом использования Copilot остается восстановление последней полной резервной копии без необходимости наката инкрементальных копий. Использование функции Instant Restore для быстрого доступа к СУБД еще в процессе восстановления также является большим плюсом.
Не больше 25% и в пределах 50 Тб
Вернемся к случаю заказчика. Тестирование на синтетической БД оказалось полезным, так как помогло клиенту увидеть все «за» и «против» первоначально симпатичного решения. Поиграв с параметрами, мы пришли к выводу, что использовать Veritas NetBackup целесообразно для СУБД размером до 50 Тб, а также при суточных изменениях в БД не более 25%. Поскольку БД розничной сети менялись каждые сутки на 50%, то Veritas NetBackup не стал подходящим решением.
Побочный эффект нашего тестирования оказался ценным. Мы нашли оптимальные режимы для работы Veritas NBU вместе с СУБД Oracle. За счет настройки параметров и выбора режима (классическая копия или Copilot) можно создать достойную и более доступную альтернативу для резервного копирования и восстановления СУБД Oracle при относительно небольшом количестве суточных изменений в БД в десятки Тб. Для тех, кто уже пользуется СРК Veritas, такой выход оптимален. Это использование более доступной по стоимости СРК и управление всем резервным копированием через одну консоль.
Автор: Артем Хмеленко, инженер систем хранения данных «Инфосистемы Джет»
