Хостинг и репликация баз данных Oracle в облако NetApp сервис-провайдера

1-82

Решения NetApp для баз данных Oracle давно зарекомендовали себя как надежные инструменты, способные не только сократить затраты на ИТ, но и упростить инфраструктуру и минимизировать проблемы, связанные в том числе с репликацией и резервным копированием данных. В этом посте мы решили «окунуться» в особенности технологий NetApp, с помощью которых организуется резервная площадка для баз данных Oracle. Проще всего рассмотреть вопрос на примере распространенного сценария, когда с одной стороны существует заказчик с инфраструктурой, нуждающейся в бэкапе и репликации, с другой — IaaS-провайдер, способный «связать» клиента со своим облаком, обеспечив надежное, отказоустойчивое поле для выполнения поставленных задач.

NetApp и Oracle Database

Приходилось ли вам сталкиваться со SnapMirror, SnapVault, дедупликацией, компрессией и прочими фишками от NetApp? Многие скорее ответят «да», и это неудивительно. Ведь всем же известна народная мудрость: хранить все яйца в одной корзине чревато убытками, простоями в работе, репутацией. Потеря данных или недоступность критически важного сервиса могут поставить под угрозу существование самой компании. Поэтому, по понятным причинам, вопрос организации резервной инфраструктуры и выбор соответствующих решений входят в топ актуальных, которые, как правило, решаются еще на этапе планирования инфраструктуры предприятия.

# SnapMirror

SnapMirror известна как технология синхронной и асинхронной репликации на уровне дисковых массивов, которая происходит с использованием IP-сети. В основе технологии лежит концепция использования разностных снимков состояния соответствующего тома.

Синхронная репликация характеризуется тем, что сигнал «готово, записано», идущий от хранилища к записывающему приложению, не передается до тех пор, пока не происходит запись данных как на исходный (primary) том на стороне клиента, так и на реплику (secondary) в облаке IaaS-провайдера. Иными словами, берется блок данных, записывается на локальный том, а затем в обязательном порядке — на удаленный. Когда на удаленной площадке процесс записи выполняется успешно, в ответ посылается сигнал со статусом «записано», и только после этих манипуляций приложение получает команду «записано, продолжай дальше».

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

Технология синхронной асинхронной репликации SnapMirror

Технология синхронной асинхронной репликации SnapMirror

Особенности SnapMirror

Особенность SnapMirror заключается в хранении реплики на резервном сайте, чтобы была возможность переключиться на него в случае катастрофы.

Типовые случаи применения:

  • Возобновление работы после чрезвычайной ситуации.
  • Обеспечение репликации данных и доступа к ним из географически удаленных точек.

Важно понимать, что СХД на стороне клиента выступает источником, или primary СХД, на стороне облачного провайдера — приёмником, или secondary СХД, с позиции функционала SnapMirror между базами настраивается репликация. В случае разрыва реплики (а такое может произойти из-за аварии) принимающая сторона обеспечивает перевод реплицируемого зеркала в режим «чтение — запись» (read-write). В таком формате реплицируемый экземпляр будет работать до момента восстановления оборудования на сайте заказчика, после чего запустится SnapMirror в режиме обратной репликации, в результате чего на стороне клиента будет наблюдаться полное восстановление базы. Такой подход имеет определенное преимущество, ведь в случае «дизастера» всегда можно рассчитывать на запасной аэродром в виде облачной резервной площадки. В случае если происходит сбой основного экземпляра базы, включается режим обратной репликации и данные восстанавливаются из существующей реплики.

Кроме того, в SnapMirror используется механизм сжатия данных, что сокращает использование сетевых ресурсов до 70%, значительно повышая скорость восстановления основного экземпляра базы.

# SnapVault

Репликация хороша сама по себе, вот только вряд ли она поможет в случае повреждения данных, которые могут испортиться на уровне приложения. Что же происходит? Очевидно, при репликации «испорченные» фрагменты попадают в резервную систему, что в итоге порождает два одинаково плохих комплекта данных. Во избежание подобного следует воспользоваться технологией резервного копирования SnapVault.

Особенности SnapVault
Технология SnapVault обеспечивает резервное копирование, позволяя решать задачи длительного хранения и защиты данных от изменений для последующего восстановления в точку назначения, откуда данные были изначально скопированы.
Типовые случаи применения:
  1. Централизованное хранение резервных копий данных.
  2. Организация удаленной копии данных для Primary-систем в качестве DR-решения.
Технология резервного копирования SnapVault
Технология резервного копирования SnapVault

В случае с клиентом и облачным провайдером суть использования SnapVault сводится к тому, что данные заказчика, располагающиеся на исходном томе, копируются на том-приемник в облако хостинг-провайдера согласно расписанию. Такая копия создается в режиме «только чтение» (read-only) и используется для различных задач.

Для проверки реализации мгновенного резервного копирования баз данных Oracle и тестирования функциональности SnapVault воспользуемся инфраструктурой на стороне заказчика (Production Site) и площадкой «ИТ-ГРАД», где все готово для проведения тестирования. В кластере Data ONTAP 8.2 на стороне Production Site клиента крутятся виртуальные машины с базами данных Oracle. Стандартно через WAN установлено подключение к Offsite backup Data ONTAP 8.2 кластера «ИТ-ГРАД».

Резервное копирование баз данных Oracle между двумя площадками
Резервное копирование баз данных Oracle между двумя площадками

SnapVault создает первичные резервные копии наборов данных, включая виртуальные машины, базы данных Oracle и пользовательские данные. Эти бэкапы хранятся на диске того же самого кластера NetApp на стороне Production Site. В том числе создаются вторичные копии наборов данных, называемые offsite data backup, которые размещаются в кластере NetApp удаленной площадки «ИТ-ГРАД». В случае аварийного восстановления удаленная площадка в облаке IaaS-провайдера с offsite data backup используется в качестве основного хранилища.

Детализируя инфраструктуру заказчика, отметим, что имеются три виртуальные машины, которые крутятся на двух серверах в кластере Vmware vSphere 5.5, каждая из них подключена к четырехнодному кластеру NetApp Data ONTAP 8.2 на базе оборудования NetApp FAS 8040 с объемом выделенного хранилища в 20 Тб. Кластер NetApp использует single storage volume, где для каждой виртуальной машины выделены отдельные LUN’ы. Для моделирования нагрузки и создания набора дата-сетов мы использовали инструмент IOMeter, а для создания клонов томов и всех LUN’ов — FlexClone. Подытожили тест созданием резервной копии с помощью SnapVault.

Для конфигурации и работы со SnapVault использовали инструмент NetApp OnCommand System Manager. Первым делом создали vault relationship, что позволило определить так называемый primary storage object, или целевое хранилище, а также хранилище для резервной копии. Для создания привязки, что является обязательным, выбрали целевой том и том назначения, а также заготовленный для тестов SVM. Затем задали расписание и включили дедупликацию.

Пример создания Vault Relationship Пример создания Vault Relationship

По завершении SnapVault создал vault назначения в SVM и том назначения tenant_1_tenant_1_vol_vault, после чего мы запустили процесс начального резервного копирования. Рисунок ниже иллюстрирует статус бэкапа.

Просмотр статуса бэкапа в NetApp OnCommand System Manager Просмотр статуса бэкапа в NetApp OnCommand System Manager

Тут отображаются детали резервной копии, а также статус, указывающий, что бэкап выполнялся в онлайн-режиме.

Если возникает необходимость бэкапить отдельно взятые файлы, каталоги или разделы на сервере баз данных, добиться этого можно с помощью Open System SnapVault.

# Дедупликация и компрессия данных

Дедупликация и компрессия данных в известной степени позволяют экономить объемы данных для резервных копий и реплик баз данных, увеличивая полезную отдачу СХД. Компрессия может использоваться одновременно с дедупликацией, то есть оба процесса работают одновременно, хотя не исключены моменты, когда используется что-то одно. Компрессия данных «на лету» при выполнении бэкапа с помощью SnapVault экономит до 80 % объема на томе-приемнике. Нельзя не отметить и отличительную особенность SnapVault, которая заключается в возможности инициирования процесса дедупликации сразу по завершении передачи данных на систему-приемник. В последней версии Data ONTAP в рамках одного контроллера можно запустить до восьми процессов дедупликации. Если же их больше восьми, все «лишние» процессы встанут в очередь и запустятся по мере завершения предыдущих.

# Основные преимущества компрессии данных NetApp

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

Как экономится дисковое пространство за счет дедупликации и компрессии?

Таблица 1. Технологии NetApp и максимальная экономия дискового пространства (%)

Объект применения Компрессия Дедупликация Компрессия и дедупликация
Файловые службы:
домашние каталоги
50% 30% 65%
Файловые службы:
техническая документация
55% 30% 75%
Виртуальные службы 55% 70% 70%
Базы данных:Oracle ERP 65% 0% 65%

# Особенности настройки дедупликации и компрессии в SVM

В одной из статей мы рассказывали о том, как создаются SVM. Чтобы объяснить, как включить дедупликацию и/или компрессию в свойствах созданного тома, для большей наглядности воспользуемся менеджером NetApp OnCommand System Manager. В свойствах тома при его редактировании достаточно перейти в закладку Storage Efficiency и включить опцию использования эффективности хранилища (Enable Storage Efficiency). После этого станут доступными для редактирования опции дедупликации и компрессии.

Конфигурация опций дедупликации и компрессии Конфигурация опций дедупликации и компрессии

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

# SnapManager for Oracle

Кроме рассмотренных выше решений, у NetApp существует еще один инструмент, а правильнее сказать — набор утилит, предназначенных для управления бэкапами баз данных Oracle, восстановления из бэкапов, тестирования копий, создания клонов баз данных и других выполнения функций, которые можно запускать в интуитивно понятном GUI-интерфейсе.

Запуск мастера Oracle Clone Wizard Запуск мастера Oracle Clone Wizard

За счет реализованных в NetApp SnapManager для Oracle функций резервного копирования, восстановления, отката, клонирования можно существенно упростить и автоматизировать управление базами данных Oracle. С помощью SnapManager происходит значительное ускорение резервного копирования, что позволяет выполнять операции копирования чаще, не влияя на работу самого приложения.

NetApp SnapManager состоит из серверной части, которая ставится на выделенный хост / виртуальную машину и агентов, размещенных на хостах с базами данных Oracle. Работая на сервере / виртуальной машине, SnapManager напрямую взаимодействует с приложением. В SnapManager для Oracle предусмотрено как полное, так и частичное резервное копирование. Чтобы выполнить полное копирование базы данных Oracle, необходимы следующие действия:

  • Имеющиеся таблицы одновременно переводятся в режим резервного копирования.
  • Дальше создаются SnapShot-копии соответствующих томов.
  • Таблицы переводятся в обычный режим работы.
  • Происходит переключение журналов и архивация журналов операций.
  • Создается мгновенный снимок архивированных журналов операций.

Все описанные процессы происходят достаточно быстро. Кроме того, SnapManager для Oracle интегрируется с мгновенными снимками NetApp SnapShot, SnapMirror, SnapVault, обеспечивая быстрое и экономичное резервное копирование disk-to-disk на локальное или удаленное хранилище.

В заключение хочется подчеркнуть, что решения NetApp, предназначенные для баз данных Oracle, справляются с решением целого ряда актуальных задач, позволяя выстраивать эффективные пути взаимодействия между заказчиком и IaaS-провайдером. За счет гибких возможностей, широких функциональных возможностей и простоты реализации решения NetApp продолжают быть в тренде и пользоваться широкой популярностью, покрывая требования по организации резервных площадок в облаке для баз данных Oracle.

Опубликовано 09.06.2015 20:04:00 автором E.Yudina в разделе Решения, в разделе Функциональность

/* */

Посетите наш сайт!

IaaS облако IT-GRAD

Подпишитесь на блог!

IaaS для бизнеса по кирпичикам