Оптимизация непрерывности бизнес-процессов и аварийного восстановления

При переносе ресурсов Oracle в Azure учитывайте надежность базы данных, а также надежность уровней виртуальных машин, подсетей виртуальной сети и компонентов хранилища.

Oracle в Azure "инфраструктура как услуга" (IaaS) может выполнять необходимые задачи устойчивости для самых ресурсоемких рабочих нагрузок Oracle. Чтобы эффективно использовать рекомендации, приведенные в этой статье, сначала определите ключевые показатели эффективности (KPI) устойчивости на основе бизнес-требований. Используйте требования к целевому времени восстановления (RTO) и целевой точке восстановления (RPO) в качестве базовых ключевых показателей эффективности, чтобы определить оптимальную архитектуру для рабочей нагрузки Oracle в Azure.

RTO — это максимальное количество времени, в течение всего времени, в течение времени, когда приложение остается недоступным после аварии, сбоя или сравнимого события

RPO — это максимальный объем потери данных после аварии, сбоя или сравнимого события.

Методы резервного копирования для защиты данных

Ниже перечислены три метода резервного копирования базы данных Oracle для рабочей нагрузки Oracle в Azure IaaS.

• Потоковая передача резервных копий. Для этого метода используйте Oracle диспетчер восстановления (RMAN). RMAN выполняет потоковую передачу резервных копий на последовательный ленточный носитель.

  К назначениям резервного копирования в Azure относятся:

  • Виртуальные ленточные библиотеки сторонних разработчиков, которые можно найти в Azure Marketplace.
  • Локальные и удаленные общие папки, например Хранилище BLOB-объектов Azure с протоколом сетевой файловой системы, Файлы Azure и Azure NetApp Files.

• Моментальные снимки уровня хранилища. Используйте Azure Backup для этого метода. Этот метод зависит от типа хранилища, используемого для файлов базы данных. Например, если вы используете управляемые диски Azure, такие как Azure SSD (цен. категория "Премиум"), Azure Backup интегрируется с базой данных Oracle. При использовании Azure NetApp Files можно использовать Azure NetApp Files возможности защиты данных, такие как Azure NetApp Files резервное копирование и репликация между регионами.

• Резервные копии на уровне виртуальной машины. Используйте Azure Backup для этого метода.

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

Рекомендации

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

• Оцените влияние стратегии резервного копирования на требования RTO и RPO.

• Проанализируйте доступные места назначения хранилища для резервных копий RMAN на основе задокументированных ограничений пропускной способности для каждого варианта. Выберите вариант, соответствующий вашим требованиям.

• Рассмотрите возможность использования Azure Backup для моментальных снимков уровня хранилища и рассмотрите возможность размещения моментальных снимков в парном регионе или зоне доступности для дополнительной защиты.

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

• Разрабатывайте и регулярно тестируйте планы резервного копирования и восстановления, чтобы предотвратить нежелательные сюрпризы в рабочей среде.

Защита служб и непрерывность бизнес-процессов

В этом разделе описывается, как улучшить общую высокую доступность (HA) и аварийное восстановление (DR) рабочей нагрузки Oracle в Azure IaaS путем реализации рекомендаций по защите служб и непрерывности бизнес-процессов (BC).

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

Azure предоставляет множество вариантов обеспечения высокого уровня доступности отдельных компонентов в архитектуре Oracle на IaaS. Например, вы можете:

• Разверните виртуальные машины в группах доступности, чтобы гарантировать отдельные домены сбоя и домены обновления.
• Create зоны доступности для защиты от сбоев центра обработки данных.
• Размещение развертываний в разных регионах для защиты от сбоев в полном регионе.

Различные возможности хранилища Azure обеспечивают разные уровни избыточности хранилища, например локально избыточное хранилище, хранилище, избыточное между зонами, и геоизбыточное хранилище. Рассмотрите каждый вариант при планировании развертывания рабочей нагрузки Oracle в Azure IaaS.

Вы также можете использовать Oracle Data Guard, который является средством для настройки защиты службы баз данных Oracle. Data Guard перенаправит и применяет журналы транзакций к одной или нескольким резервным базам данных. Этот процесс поддерживает точные копии базы данных-источника, в которую можно выполнить отработку отказа при плановом обслуживании или сценарии сбоя.

Data Guard имеет три режима репликации данных: максимальная защита, максимальная доступность и максимальная производительность. Каждый режим репликации предлагает разное сочетание режимов транспорта журналов и различные гарантии транзакций для приложения в базе данных-получателе.

В зависимости от стратегии, такой как стратегия нулевой задержки или нулевой потери данных, можно выбрать синхронную или асинхронную конфигурацию. Вы также можете реализовать отработку отказа с быстрым запуском в зависимости от требований к максимальному времени простоя. Доступны эталонные архитектуры, обеспечивающие восстановление менее чем за одну минуту или менее пяти минут и до четырех часов. Выпуск Enterprise Oracle Database включает Data Guard.

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

Рекомендации

• Рассмотрите возможности, которые Azure предоставляет для обеспечения высокого уровня доступности различных компонентов инфраструктуры в реализации Oracle в Azure IaaS.

• Тщательно выберите режим защиты базы данных, который соответствует вашим требованиям при использовании Data Guard для обеспечения высокой доступности и аварийного восстановления. Например, режим максимальной производительности минимизирует влияние на источник, но имеет наибольший потенциал для потери данных. Дополнительные сведения см. в статье BCDR для Oracle в Azure Виртуальные машины ускорителя целевой зоны и режимы защиты Oracle Data Guard.

• Рассмотрите возможность автоматизации процесса отработки отказа. Например, можно использовать быстрый запуск отработки отказа.

• Установите процедуры тестирования для процессов отработки отказа и проводите регулярное тестирование, чтобы избежать проблем.

• Создайте комплексное проектирование решения, используя собственные возможности Azure, такие как зоны доступности, и средства Oracle, такие как Data Guard, в соответствии с требованиями к высокой доступности и аварийному обеспечению. В следующих двух примерах используются собственные компоненты Azure и Oracle.

Create отработки отказа с пассивным режимом ожидания

В этом разделе описывается пример сценария отработки отказа для критически важных для бизнеса приложений Oracle в развертывании с двумя зонами доступности с пассивным резервным режимом.

Критически важные для бизнеса приложения Oracle, такие как Oracle E-Business Suite, требуют предотвращения сбоев и, следовательно, целостной архитектуры.

В этом примере:

• Имеет развертывание с двумя зонами доступности. Уровень приложений использует azure Site Recovery с пассивной вторичной виртуальной машиной.

• Используйте функцию быстрого запуска отработки отказа Data Guard. Чтобы получить максимальную доступность, рекомендуется установить два наблюдателя. Основной наблюдатель находится в зоне доступности 1, а дополнительный наблюдатель — во второй зоне доступности. Наблюдатели отслеживают и направляют трафик. Если база данных-источник недоступна, наблюдатель автоматически выполняет отработку отказа в базу данных-получатель. Data Guard выполняет повторную синхронизацию. Интервал времени синхронизации повтора зависит от конфигурации повтора.

• В Data Guard настроен режим защиты данных, например максимальная доступность, максимальная производительность или максимальная защита. Дополнительные сведения о выборе режима для требований рабочей нагрузки см. в разделе Режимы защиты Oracle Data Guard.

Следующая архитектура предназначена для порогового времени простоя менее пяти минут.

Create отработки отказа с активным резервным

В этом разделе описывается пример сценария отработки отказа для критически важных для бизнеса приложений Oracle в развертывании с двумя зонами доступности с активным резервным режимом.

В этом примере:

• Уровень веб-сервера, уровень приложений и уровень базы данных находятся в собственной подсети виртуальной сети.

• База данных-источник находится в зоне доступности 1.

• База данных, использующая Active Data Guard для репликации базы данных-источника в активный резерв, находится в третьей зоне доступности.

Примечание

Для этой установки требуется лицензия Active Data Guard.

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

Следующий шаг

Оптимизация безопасности