Рекомендации по непрерывности бизнес-процессов и аварийному восстановлению для Oracle Database@Azure
В этой статье рассматриваются факторы и рекомендации по обеспечению непрерывности бизнеса и аварийному восстановлению (BCDR), описанные в области разработки целевой зоны Azure. Он включает принципы Oracle Maximum Availability Architecture (MAA) для Oracle Database@Azure, используя Oracle Exadata Database Service.
Первым шагом в создании устойчивой архитектуры для баз данных Oracle, работающих в Oracle Database@Azure, является определение требований к доступности решения. Важно установить целевой объект времени восстановления (RTO) и целевой точки восстановления (RPO) для различных уровней сбоев, включая запланированные и незапланированные события. RTO определяет максимальное время простоя, которое может терпеть приложение или бизнес после сбоя. RPO указывает максимальную длительность потери данных, которую может терпеть приложение или бизнес. Перед началом разработки BCDR необходимо выполнить это предварительное условие. После установки требований решения вы можете разработать среду Oracle Database@Azure для соответствия требованиям RTO и RPO.
Дополнительные сведения см. в рекомендациях microsoft Azure Well-Architected Framework о том, как разработать стратегию аварийного восстановления.
Рекомендации по проектированию
Служба Oracle Exadata Database@Azure доступна в двух разных зонах доступности в пределах региона. Эта доступность помогает обеспечить надежность сервиса и восстановление после аварий. Чтобы проверить место развертывания Oracle Exadata Database в "Database@Azure", проверьте кластер виртуальной машины на портале Azure.
Oracle Exadata Database@Azure и его основные компоненты ограничены зоной доступности, в которой создается экземпляр. Служба не охватывает несколько зон и не охватывает несколько регионов. Чтобы достичь многозоновой или многорегиональной устойчивости, можно развернуть новые экземпляры Oracle Exadata Database@Azure в целевых зонах доступности или регионах.
Oracle Exadata Database@Azure предоставляет собственные технологии Oracle, такие как Кластеры приложений Oracle Real Для обеспечения высокой доступности (HA) и Oracle Data Guard для аварийного восстановления. Data Guard и Active Data Guard поддерживаются для архитектуры аварийного восстановления.
Oracle Exadata Database@Azure по умолчанию предоставляет высокую доступность для обеспечения отказоустойчивости экземпляра базы данных и защиты от сбоев на уровне оборудования. Эта архитектура соответствует серебряному уровню MAA . Запланированные операции обслуживания можно проводить в последовательном режиме. Однако архитектура с одной зоной по умолчанию имеет нулевую отказоустойчивость к сбоям на уровне сайта или региона.
Решение предоставляет автоматическую конфигурацию Data Guard для аварийного восстановления. Эта настройка помогает защититься от сбоев на сайте, требуя дополнительного развертывания Oracle Exadata Database@Azure в другой зоне доступности или регионе.
Сетевое подключение между основными и резервными экземплярами Oracle Exadata Database@Azure можно установить через сеть Azure и сеть Oracle Cloud Infrastructure (OCI). По умолчанию основной маршрут для этого подключения осуществляется через Azure.
Ниже перечислены три варианта резервного копирования, доступные для Oracle Exadata Database@Azure:
управляемое OCI резервное копирование: Этот вариант включает два интегрированных решения, которые являются Oracle Database Autonomous Recovery Service и Oracle Cloud Infrastructure Object Storage. Эти решения управляются с помощью консоли OCI.
Автономная служба восстановления предназначена для критически важных рабочих нагрузок корпоративного уровня, которые имеют строгие требования RTO и RPO. Она обеспечивает доступность с помощью соглашений об уровне обслуживания. Для получения дополнительной информации см. документ столпа общеоблачных сервисов, включая платформу Oracle как услугу и инфраструктуру как услугу.
Хранилище объектов OCI — это решение для резервного копирования общего назначения, подходящее для рабочих нагрузок с менее строгими требованиями RTO или RPO.
Эти решения позволяют автоматически планировать резервные копии баз данных и управлять ими с предопределенным периодом хранения. Дополнительные сведения см. в статье Управление резервным копированием и восстановлением базы данных в службе базы данных Exadata в выделенной инфраструктуре Oracle.
самостоятельное резервное копирование: можно настроить Oracle Exadata Database@Azure для потоковой передачи резервных копий базы данных в службы хранилища Azure, включая хранилище BLOB-объектов Azure, файлы Azure (через частные конечные точки) и Azure NetApp Files.
Для этого параметра требуется ручная настройка и текущее обслуживание.
Использование частных конечных точек с Oracle Database@Azure требует промежуточного прыжка через устройство маршрутизации, например сетевое виртуальное устройство (NVA). Это устройство может быть центральным узлом NVA, например, как Брандмауэр Azure, или NVA, не относящийся к продуктам Майкрософт. Для непроизводственных сред это может быть выделенная виртуальная машина, которая используется для пересылки IP-адресов, как в Deploy a local NVA. Дополнительные сведения см. в статье Планирование сети для Oracle Database@Azure.
решения для резервного копирования, отличные от Майкрософт: вы можете использовать решения для резервного копирования от сторонних производителей, доступные на Azure Marketplace, такие как Commvault, для управления и хранения резервных копий баз данных.
Рекомендации по проектированию
Чтобы создать устойчивую архитектуру, которая адаптирована к конкретным требованиям, рассмотрите следующие рекомендации BCDR для Oracle Exadata Database@Azure.
Необходимо настроить по крайней мере два экземпляра Oracle Exadata Database@Azure с Data Guard, чтобы помочь защититься от сбоев на одном сайте. Эта настройка соответствует золотому стандарту MAA.
BcDR с несколькими зонами
Архитектура BCDR с несколькими зонами рекомендуется для клиентов, которым требуется нулевая или почти нулевая RPO с избыточностью нескольких зон при выполнении требований к месту расположения данных в одном регионе.
Это решение включает дополнительное развертывание Oracle Exadata Database@Azure в другой зоне доступности в одном регионе. Чтобы обеспечить устойчивость к сбоям базы данных, кластера или зоны доступности, реализуйте резервную базу данных, расположенную в дополнительном экземпляре. Эта настройка обеспечивает защиту от сбоев на уровне сайта.
режим транспортировки повторов Data Guard: Настроить режим транспортировки повторов Data Guard в соответствии с требованиями к службам приложений и RPO:
целостности данных и нулевой потери данных: Если целостность данных и нулевой потери данных являются самыми высокими приоритетами, используйте режим максимальной доступности (SYNC). Этот режим синхронно реплицирует данные в резервную базу данных, которая гарантирует, что данные не будут потеряны.
производительность системы: если производительность системы является критической, а небольшая степень потери данных допустима, используйте режим максимальной производительности (ASYNC). В этом режиме используется асинхронная репликация, которая приводит к тому, что RPO немного больше нуля (или почти нулю).
Поддерживать симметричный резервный экземпляр: следует поддерживать симметричный резервный экземпляр с ресурсами, эквивалентными основной базе данных, чтобы обеспечить постоянную производительность во время переключения и отработки отказа. Кроме того, можно настроить базу данных ожидания с минимальными ресурсами и по мере необходимости динамически масштабировать кластер виртуальных машин после переключения или отказа. Однако этот подход может добавить дополнительное время для операций масштабирования и их отражения на уровне базы данных.
Автоматизация операций переключения: Используйте Oracle Data Guard Fast-Start для автоматизации операций переключения с целью минимизации RTO и уменьшения числа ошибок.
Заметка
Fast-Start Аварийное переключение не является управляемой службой и требует ручной настройки.
Для этой установки требуются дополнительные виртуальные машины с работающими наблюдателями Oracle Data Guard, чтобы включить отказоустойчивость Data Guard Fast-Start. Эти виртуальные машины наблюдателя отслеживают состояние базы данных и репликации, что автоматизирует процесс переключения при отказе.
Если требуется симметричная архитектура аварийного восстановления при отработке отказа, необходимо разместить экземпляр наблюдателя в месте, где настроено дополнительное развертывание Oracle Exadata Database@Azure.
Многорегиональный BCDR
Для многорегиональной стратегии BCDR реализуйте вторичное развертывание Oracle Exadata Database@Azure с резервной базой данных, расположенной в другом регионе, где доступна служба. Эта настройка обеспечивает защиту от полного регионального сбоя.
Настройте Data Guard для асинхронной репликации с целью регионального аварийного восстановления, на основании требований приложения и сетевых задержек между основным и вторичным регионами. Дополнительные сведения см. в статистике двухсторонней задержки в сети Azure.
Заметка
Автоматический Data Guard позволяет настроить только конфигурацию режима максимальной производительности (ASYNC) для развертываний между регионами.
- Рекомендации BCDR с несколькими зонами и многорегиональными ориентированы на устойчивость службы баз данных. Чтобы обеспечить общую устойчивость рабочей нагрузки, рассмотрите возможность использования служб Azure и таких функций, как масштабируемые наборы виртуальных машин Azure, Azure Site Recovery и Azure Front Door для разработки надежной архитектуры между зонами доступности или регионами.
Расширенные сценарии BCDR
Локальные и удаленные резервные базы данных
Чтобы устранить требования к надежной доступности и устойчивости служб в отношении региональных сбоев, рекомендуется реализовать несколько резервных баз данных для критически важных рабочих нагрузок.
Локальная резервная база данных в развертывании Oracle Exadata Database@Azure находится в другой зоне доступности в одном регионе. Эта настройка предоставляет жизнеспособное решение для задержко-чувствительных приложений, удовлетворяющее требованиям нулевой потери данных с помощью репликации SYNC Data Guard. Эта стратегия помогает обеспечить доступность службы, не влияя на пропускную способность приложения или общее время отклика.
Удаленная стендендбай база данных на экземпляре Oracle Exadata Database@Azure, расположенном в другом регионе, отвечает требованиям к региональному аварийному восстановлению.
Эта архитектура идеально подходит для критически важных рабочих нагрузок и требует не менее трех развертываний Oracle Exadata Database@Azure.
Заметка
Если из-за сценария отработки отказа требуется симметричная конфигурация, поместите дополнительную резервную базу данных на Oracle Exadata Database@Azure во вторичном регионе, в другой зоне доступности.
Архитектура Data Guard Far Sync
Вы можете выполнить требование для реализации репликации нулевой потери данных на любом расстоянии с помощью конфигурации Data Guard Far Sync. Этот подход включает размещение экземпляра дистанционной синхронизации ближе к основному развертыванию Oracle Exadata Database@Azure, фактически в другой зоне доступности в том же регионе, для синхронной отправки журналов повторов. Затем экземпляр удаленной синхронизации асинхронно передает эти журналы в страховочную базу данных, запущенную в дополнительном развертывании Oracle Exadata Database@Azure в другом регионе. Эта настройка эффективно приводит к нулевой репликации потери данных между регионами.
Если вы ищете симметричную архитектуру аварийного восстановления в случае отказа, поместите экземпляр дальнего сопряжения в отдельную зону доступности, где настроено дополнительное развертывание Oracle Exadata Database@Azure.
Заметка
Архитектура Far Sync требует лицензии Active Data Guard и должна быть настроена вручную.
Рекомендации по резервному копированию
Если вы планируете использовать резервные копии в качестве единственного решения для требований BCDR, помните, что RTO выше по сравнению с сценариями репликации, так как он основан на размере базы данных и используемых методах резервного копирования.
Резервное копирование данных в Azure: Для удовлетворения требований организации, которые предусматривают, что данные и резервные копии должны оставаться в Azure, рассмотрите следующие решения:
использовать автономную службу восстановления (ARS) в Azure: во время настройки политики резервного копирования выберите хранить данные резервного копирования в том же поставщике облачных служб, что и база данных для использования ARS в Azure.
Использовать службы хранилища: Использовать такие службы хранилища, как Blob Storage, Azure Files и Azure NetApp Files, чтобы монтировать хранилище в качестве точек сетевой файловой системы (NFS) на сервере базы данных и осуществлять потоковую передачу резервных копий Oracle Recovery Manager (RMAN) в хранилище.
долгосрочное хранение резервных копий: Если для организации требуется долгосрочное хранение резервных копий, можно настроить самостоятельно управляемые резервные копии RMAN в службе Azure Storage.
Конфигурации резервного копирования хранилища: Если резервные копии настроены для этих служб хранилища, рассмотрите следующие рекомендации.
Расписание с заданиями cron: Используйте задания cron на уровне узла базы данных для назначения резервных копий в определенное время, исходя из вашей стратегии резервного копирования.
Репликация резервных копий: Использовать базовые функции репликации хранилища из Azure, такие как зонально отказывоустойчивое хранилище и географически избыточное хранилище для репликации резервных копий.
Операции резервного копирования и восстановления: вручную выполняйте резервное копирование виртуальных машин Oracle Exadata Database@Azure для восстановления критически важных файлов в случае случайного удаления или повреждения. Дополнительные сведения см. в операциях резервного копирования и восстановления вычислительных узлов Oracle Exadata Cloud (идентификатор документа 2809393.1).
Другие рекомендации
Хранить данные в Azure: Если необходимо хранить данные исключительно в Azure, маршрутизировать трафик Data Guard через сеть Azure и настраивать резервные копии для пребывания в Azure.
тестирование резервного восстановления: тестирование отработки отказа и переключения операций для обеспечения их работоспособности в реальном сценарии аварии.
Используйте Oracle Fast-Start Failover для автоматизации этих операций, чтобы минимизировать количество ошибок, когда это возможно.
Используйте Oracle Application Continuity, чтобы бесшовно маскировать сбой на уровне приложения.
Данные в реальном времени и репликация: Для активно-активных сред рекомендуется использовать Oracle GoldenGate для интеграции данных и репликации в режиме реального времени. Для эффективной обработки конфликтов требуется осведомленность на уровне приложения.
Заметка
GoldenGate не входит в это решение и может нести дополнительные расходы на лицензирование.
свести к минимуму прерывания: Чтобы свести к минимуму прерывания для рабочей нагрузки, запланировать плановое обслуживание в нерабочие часы. Если вы можете, используйте обновления в режиме реального времени, чтобы обеспечить бесперебойный процесс.
Использовать инфраструктуру в качестве кода (IaC): Для более надежной автоматизации инфраструктуры разверните начальный экземпляр Oracle Exadata Database@Azure и кластеры виртуальных машин с помощью IaC. Дополнительные сведения об автоматизации oracle Database@Azure см. в кратком руководстве Oracle Database@Azure с модулями Terraform или OpenTofu.
Используйте проверенные модули Azure для развертывания экземпляров и кластеров виртуальных машин Oracle Exadata Database@Azure. Дополнительные сведения см. в следующих ресурсах:
Используйте IaC для развертывания баз данных в консоли OCI. Вы можете использовать IaC для репликации того же развертывания на сайт аварийного восстановления и минимизации риска человеческой ошибки.