Проще всего рассмотреть вопрос на примере распространенного сценария, когда с одной стороны существует заказчик с инфраструктурой, нуждающейся в бэкапе и репликации, с другой — IaaS-провайдер, способный «связать» клиента со своим облаком, обеспечив надежное, отказоустойчивое поле для выполнения поставленных задач.
NetApp и Oracle Database
Приходилось ли вам сталкиваться со SnapMirror, SnapVault, дедупликацией, компрессией и прочими фишками от NetApp? Многие скорее ответят «да», и это неудивительно. Ведь всем же известна народная мудрость: хранить все яйца в одной корзине чревато убытками, простоями в работе, репутацией. Потеря данных или недоступность критически важного сервиса могут поставить под угрозу существование самой компании. Поэтому, по понятным причинам, вопрос организации резервной инфраструктуры и выбор соответствующих решений входят в топ актуальных, которые, как правило, решаются еще на этапе планирования инфраструктуры предприятия.
# SnapMirror
SnapMirror известна как технология синхронной и асинхронной репликации на уровне дисковых массивов, которая происходит с использованием IP-сети. В основе технологии лежит концепция использования разностных снимков состояния соответствующего тома.
Синхронная репликация характеризуется тем, что сигнал «готово, записано», идущий от хранилища к записывающему приложению, не передается до тех пор, пока не происходит запись данных как на исходный (primary) том на стороне клиента, так и на реплику (secondary) в облаке IaaS-провайдера. Иными словами, берется блок данных, записывается на локальный том, а затем в обязательном порядке — на удаленный. Когда на удаленной площадке процесс записи выполняется успешно, в ответ посылается сигнал со статусом «записано», и только после этих манипуляций приложение получает команду «записано, продолжай дальше».
При асинхронной репликации в ходе записи локальная система сразу же отправляет сигнал приложению со статусом «записано», после чего с заданным интервалом отправляются обновления на удаленную площадку.
Технология синхронной асинхронной репликации SnapMirror
Особенности SnapMirror
Особенность SnapMirror заключается в хранении реплики на резервном сайте, чтобы была возможность переключиться на него в случае катастрофы.
Типовые случаи применения:
- Возобновление работы после чрезвычайной ситуации.
- Обеспечение репликации данных и доступа к ним из географически удаленных точек.
Важно понимать, что СХД на стороне клиента выступает источником, или primary СХД, на стороне облачного провайдера — приёмником, или secondary СХД, с позиции функционала SnapMirror между базами настраивается репликация. В случае разрыва реплики (а такое может произойти из-за аварии) принимающая сторона обеспечивает перевод реплицируемого зеркала в режим «чтение — запись» (read-write). В таком формате реплицируемый экземпляр будет работать до момента восстановления оборудования на сайте заказчика, после чего запустится SnapMirror в режиме обратной репликации, в результате чего на стороне клиента будет наблюдаться полное восстановление базы. Такой подход имеет определенное преимущество, ведь в случае «дизастера» всегда можно рассчитывать на запасной аэродром в виде облачной резервной площадки. В случае если происходит сбой основного экземпляра базы, включается режим обратной репликации и данные восстанавливаются из существующей реплики.
Кроме того, в SnapMirror используется механизм сжатия данных, что сокращает использование сетевых ресурсов до 70%, значительно повышая скорость восстановления основного экземпляра базы.
# SnapVault
Репликация хороша сама по себе, вот только вряд ли она поможет в случае повреждения данных, которые могут испортиться на уровне приложения. Что же происходит? Очевидно, при репликации «испорченные» фрагменты попадают в резервную систему, что в итоге порождает два одинаково плохих комплекта данных. Во избежание подобного следует воспользоваться технологией резервного копирования SnapVault.
Особенности SnapVault
Технология SnapVault обеспечивает резервное копирование, позволяя решать задачи длительного хранения и защиты данных от изменений для последующего восстановления в точку назначения, откуда данные были изначально скопированы.
Типовые случаи применения:
-
Централизованное хранение резервных копий данных.
-
Организация удаленной копии данных для Primary-систем в качестве DR-решения.
Технология резервного копирования SnapVault
В случае с клиентом и облачным провайдером суть использования SnapVault сводится к тому, что данные заказчика, располагающиеся на исходном томе, копируются на том-приемник в облако хостинг-провайдера согласно расписанию. Такая копия создается в режиме «только чтение» (read-only) и используется для различных задач.
Для проверки реализации мгновенного резервного копирования баз данных Oracle и тестирования функциональности SnapVault воспользуемся инфраструктурой на стороне заказчика (Production Site) и площадкой «ИТ-ГРАД», где все готово для проведения тестирования. В кластере Data ONTAP 8.2 на стороне Production Site клиента крутятся виртуальные машины с базами данных Oracle. Стандартно через WAN установлено подключение к Offsite backup Data ONTAP 8.2 кластера «ИТ-ГРАД».
Резервное копирование баз данных 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
По завершении SnapVault создал vault назначения в SVM и том назначения tenant_1_tenant_1_vol_vault, после чего мы запустили процесс начального резервного копирования. Рисунок ниже иллюстрирует статус бэкапа.
Тут отображаются детали резервной копии, а также статус, указывающий, что бэкап выполнялся в онлайн-режиме.
Если возникает необходимость бэкапить отдельно взятые файлы, каталоги или разделы на сервере баз данных, добиться этого можно с помощью 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-интерфейсе.
- Имеющиеся таблицы одновременно переводятся в режим резервного копирования.
- Дальше создаются SnapShot-копии соответствующих томов.
- Таблицы переводятся в обычный режим работы.
- Происходит переключение журналов и архивация журналов операций.
- Создается мгновенный снимок архивированных журналов операций.
Все описанные процессы происходят достаточно быстро. Кроме того, SnapManager для Oracle интегрируется с мгновенными снимками NetApp SnapShot, SnapMirror, SnapVault, обеспечивая быстрое и экономичное резервное копирование disk-to-disk на локальное или удаленное хранилище.
В заключение хочется подчеркнуть, что решения NetApp, предназначенные для баз данных Oracle, справляются с решением целого ряда актуальных задач, позволяя выстраивать эффективные пути взаимодействия между заказчиком и IaaS-провайдером. За счет гибких возможностей, широких функциональных возможностей и простоты реализации решения NetApp продолжают быть в тренде и пользоваться широкой популярностью, покрывая требования по организации резервных площадок в облаке для баз данных Oracle.
