Непрерывность бизнес-процессов и аварийное восстановление для Oracle в акселераторе целевой зоны Виртуальные машины Azure

Статья
08/01/2024

В этой статье рассматриваются рекомендации и рекомендации, определенные в области проектирования целевой зоны Azure для обеспечения непрерывности бизнес-процессов и аварийного восстановления (BCDR). В этой статье описаны рекомендации по проектированию и рекомендации по вариантам BCDR для развертываний рабочих нагрузок Oracle на виртуальных машинах инфраструктуры Azure.

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

Начало работы

Чтобы создать отказоустойчивую архитектуру для рабочей нагрузки, определите требования к доступности для решения на основе целевой цели времени восстановления (RTO) и целевой точки восстановления (RPO) для различных уровней сбоя. RTO — это максимальное время, когда приложение остается недоступным после инцидента. RPO — это максимальный объем потери данных во время аварии. Определив требования к решению, создайте архитектуру, чтобы обеспечить установленные уровни устойчивости и доступности.

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

Настройка рабочей нагрузки для обеспечения высокой доступности

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

Выберите правильный вариант высокого уровня доступности

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

Использование Data Guard в режиме максимальной доступности для обеспечения высокой доступности

Data Guard в режиме максимальной доступности обеспечивает максимальную доступность с нулевой обещанием потери данных (RPO=0) для обычных операций. Для высокодоступной конфигурации двух серверов баз данных Oracle, созданных в рамках гибкой оркестрации Масштабируемые наборы виртуальных машин, Azure предоставляет доступность службы на уровне обслуживания (SLA) 99,95 % для экземпляров, распределенных по доменам сбоя. Azure предоставляет доступность служб на 99,99% для экземпляров, которые распределяются по зонам доступности. Дополнительные сведения см. в разделе "Высокий уровень доступности" для Масштабируемые наборы виртуальных машин.

Пошаговую настройку Data Guard в Azure см. в статье "Реализация Oracle Data Guard на виртуальной машине Azure под управлением Linux".

Использование Data Guard в максимальном режиме защиты для обеспечения высокой доступности

Если требуется транзакционная копия базы данных, рекомендуется использовать Data Guard в максимальном режиме защиты. Однако максимальный режим защиты не позволяет транзакциям продолжаться, если резервная база данных недоступна. Поэтому, несмотря на использование гибкой оркестрации масштабируемых наборов Виртуальные машины, соглашение об уровне обслуживания уменьшается до 99,9% x 99,9% = 99,8% при использовании максимального режима защиты. Эта конфигурация обеспечивает согласованную копию данных, но не обязательно повышает доступность.

Другие атрибуты этой архитектуры совпадают с максимальным режимом доступности. Например, RPO равен нулю, а RTO меньше или равно двум минутам.

Рассмотрите другие способы реализации высокой доступности

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

Использование зон доступности для повышения высокого уровня доступности

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

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

Использование кластеризации общего хранилища для обеспечения высокой доступности

Общие технологии кластеризации хранилища предоставляют уникальные атрибуты, которые помогут вам достичь бизнес-целей. Например, можно реализовать кластер Pacemaker и Corosync (PCS) с общим хранилищем. Управляемые диски или Azure NetApp Files можно использовать в качестве общего хранилища для экземпляров кластера PCS. Кластер PCS не дублирует данные. Она предоставляет виртуальную IP-службу со статическим IP-адресом или сетевым именем IP-адресов, которые не изменяются при отработках отказа.

Примечание.

Кластер PCS не является сертифицированным решением Oracle. Имейте в виду этот фактор при выборе архитектуры высокой доступности.

Использование групп размещения близкого взаимодействия

Чтобы обеспечить наименьшую возможную задержку, поместите виртуальные машины как можно ближе. Их можно развернуть в группе размещения близкого взаимодействия. Группа размещения близкого взаимодействия — это логическая группировка, которая гарантирует, что вычислительные ресурсы Azure физически находятся рядом друг с другом. Группы размещения близкого взаимодействия полезны для рабочих нагрузок, требующих низкой задержки.

Настройка рабочей нагрузки для аварийного восстановления

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

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

В этой статье рассматриваются сценарии, в которых сервер-источник и вторичные серверы находятся в Azure. Вы также можете использовать локальный сервер-источник и дополнительный сервер в Azure для аварийного восстановления. Дополнительные сведения см. в статье "Основной сайт" локального и аварийного восстановления в Azure.

Выберите правильный вариант аварийного восстановления

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

Использование Data Guard для аварийного восстановления

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

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

Если сайт аварийного восстановления находится в другом регионе, необходимо разработать сайт для отработки отказа в зависимости от ваших требований.

Задержка в одном центре обработки данных меньше задержки между центрами обработки данных, разделенными далеко друг от друга, и значительно меньше задержки между различными регионами. Поэтому наименее сложный и наименее дорогостоящий вариант — использовать Data Guard в максимальном режиме производительности для аварийного восстановления. Если потенциальная потеря данных в максимальном режиме производительности слишком высока, можно использовать режим максимальной доступности с механизмом Oracle Data Guard Far Sync. Но экземпляр Far Sync активирует лицензирование Active Data Guard в основной среде и резервной среде. Дополнительные сведения см. в разделе "Сведения о лицензии Oracle".

Кроме того, при отправке данных в регионах Или центрах обработки данных Azure вы оплачиваете исходящие расходы за данные, такие как журналы повторного входа, которые отправляются на сайт аварийного восстановления. Если вам не нужно реплицировать все данные в базе данных, можно использовать репликацию на основе Oracle Golden Gate для репликации только частичных данных по мере необходимости, что снижает затраты на исходящий трафик.

Пошаговые инструкции по настройке Data Guard в Azure см. в статье "Реализация Data Guard" на виртуальной машине Linux под управлением Linux.

Использование Golden Gate для аварийного восстановления

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

Вы можете использовать Golden Gate для репликации данных из базы данных-источника в базу данных-получатель в конфигурации аварийного восстановления. Golden Gate особенно практический, если необходимо защитить только некоторые данные. Чтобы избежать репликации ненужных данных, используйте Golden Gate для выборочной репликации таблиц и фильтрации строк таблиц во время репликации.

Пошаговое руководство по реализации Golden Gate в Azure см. в статье "Реализация Golden Gate" на виртуальной машине Azure под управлением Linux.

Использование резервного копирования для аварийного восстановления

Резервное копирование и восстановление — это традиционный метод для архитектуры аварийного восстановления. Существует два основных компонента резервного копирования в качестве метода аварийного восстановления для баз данных Oracle в Azure:

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

Существует несколько вариантов резервного копирования, которые можно использовать для репликации данных. Дополнительные сведения см. в стратегиях резервного копирования для Базы данных Oracle в Azure.

Рассмотрите возможность использования одного из следующих подходов к обслуживанию сайта аварийного восстановления:

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

Внимание

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

Подход 2. Развертывание и обслуживание масштабируемой версии рабочей среды. У вас есть версия, которая может правильно функционировать для небольшой рабочей нагрузки, и вы можете увеличить масштаб по мере необходимости во время отработки отказа для выполнения рабочей нагрузки. Этот метод часто используется, особенно для сложных развертываний, в которых вы не хотите рисковать созданием всей среды или если вы хотите быстро выполнить отработку отказа, чтобы обеспечить низкий уровень RTO.

Подход 3. Развертывание и обслуживание всего решения на сайте аварийного восстановления для самых быстрых времени RTO и отработки отказа. Этот метод увеличивает затраты из-за выполнения полностью избыточной инфраструктуры.

Рассмотрите другие способы реализации аварийного восстановления

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

Использование функции "Дальная синхронизация"

Far Sync не улучшает возможности высокой доступности, но вы можете использовать его для достижения нулевой защиты от потери данных для баз данных Oracle. Рабочая нагрузка может потребовать нулевой потери данных, если база данных-источник завершается ошибкой. Дополнительные сведения см. в статье о эталонных архитектурах Oracle в Azure.

Выбор правильной технологии репликации данных

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

Задержка. Время репликации обновления из базы данных-источника в базы данных-получатель для обеспечения высокой доступности и аварийного восстановления должно соответствовать требованиям вашего решения.

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

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

Потеря данных: объем потери данных, ожидаемый во время резкого сбоя базы данных-источника, должен соответствовать требованиям вашего решения.

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

Оптимизация экземпляра отработки отказа

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

В этой реализации база данных должна выполняться так же после отработки отказа. Поэтому необходимо настроить сервер-получатель с той же емкостью ЦП, памяти и ввода-вывода (I/O), что и основной сервер. Необходимо поддерживать высокую емкость с дополнительным сервером, что повышает затраты на Azure и расходы на лицензию Базы данных Oracle. Сервер-получатель обычно не обрабатывает запросы пользователей.

Azure предоставляет доступность на 99,9% для виртуальных машин в зоне доступности. Дополнительные сведения см. в разделе об уровне обслуживания об уровне обслуживания виртуальной машины. При использовании технологии репликации данных для поддержки вторичной реплики базы данных в одной зоне доступности, другой зоне доступности или другом регионе можно оптимизировать вторичную емкость.

При таком подходе база данных-получатель настроена с емкостью, которую она должна оставаться актуальной. При сбое база данных-получатель изменяется до той же емкости, что и база данных-источник. Эта операция возникает только в случае сбоя. Поэтому во время нормальной работы вы оплачиваете только часть стоимости основного сервера. База данных-источник не работает во время сбоя, поэтому вам не нужны другие лицензии базы данных Oracle.

Емкость, необходимая для работы базы данных-получателя в качестве назначения репликации, зависит от используемой технологии репликации. По сути, рабочая нагрузка, которая находится в системе обработки транзакционных транзакций (OLTP), имеет в основном запросы на чтение. Например, 90 % операций чтения и 10 % операций записи или 95 % операций чтения и 5 % операций записи являются общими в приложениях OLTP. Репликация данных по сути реплицирует результат записи запросов в исходной базе данных. С помощью этой настройки можно ожидать, что база данных-получатель будет работать с 1/10-й (если у вас есть 90 % операций чтения и 10 % записи) емкости базы данных-источника.

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

Настройка топологии сети для защиты служб и защиты данных

Чтобы обеспечить высокую доступность и аварийное восстановление, необходимо принять финансовые и бизнес-решения, которые сбалансируйте время восстановления или RTO, а также потенциальную потерю данных или RPO, с другими лицензиями Oracle, обслуживанием виртуальных машин и затратами на передачу данных. При размещении рабочей нагрузки на одной виртуальной машине Azure вы получаете базовую защиту от распространенных сбоев оборудования с низкой стоимостью. Но сбой на одной виртуальной машине, скорее всего, приводит к простою и потере данных. Таким образом, в рабочих средах включите по крайней мере одну базу данных-получатель Oracle, размещенную на отдельной виртуальной машине с Data Guard. В зависимости от требований используйте одну или несколько следующих конфигураций Data Guard для репликации данных:

Оптимальный RTO и RPO. Чтобы свести к минимуму задержку, включите базу данных-получатель Oracle на отдельной виртуальной машине в той же Масштабируемые наборы виртуальных машин гибкой оркестрации и в той же зоне доступности, что и база данных-источник. Эта конфигурация обеспечивает высокий уровень доступности и защиту от сбоя одного экземпляра.
Защита данных от сбоя центра обработки данных. Поместите базу данных-получатель Oracle во вторую зону доступности, чтобы обеспечить высокий уровень доступности и обеспечить защиту при сбое всей зоны доступности. Эта конфигурация может иметь до двух миллисекунд задержки между первичной и вторичной базой данных, что может повлиять на производительность, ОСРВ и RPOS.
Защита данных от регионального сбоя. Чтобы защититься от потенциальной потери данных из-за регионального сбоя Azure, можно разместить базу данных-получатель в другом регионе. Эта конфигурация может иметь от 30 миллисекунд до 300 миллисекунд задержки между регионами, поэтому вы можете не соответствовать целевым объектам RTO и RPO. Это решение лучше всего подходит для регионального аварийного восстановления, а не для обеспечения высокой доступности.

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

Data Guard обеспечивает высокий уровень доступности и в большинстве сценариев обеспечивает достаточную поддержку распространенных сбоев. Виртуальные машины можно разместить в Масштабируемые наборы виртуальных машин гибкой оркестрации. Чтобы уменьшить задержку в сети, все службы в одном решении должны находиться в одной зоне доступности, а службы должны совместно использовать одну и ту же виртуальную сеть.

Для дальнейшей защиты виртуальные машины можно стратегически разместить в отдельных зонах доступности, а не в одной зоне доступности. Такой подход может предотвратить простой во время сбоя центра обработки данных.
Для максимальной защиты можно разместить базу данных-получатель в другом регионе Azure из региона базы данных-источника. Для применения непрерывных обновлений можно использовать Data Guard для реализации пиринга глобальной виртуальной сети. Используйте этот подход для применения обновлений данных к дополнительному региону в частном порядке через магистраль Майкрософт. Ресурсы взаимодействуют напрямую без шлюзов, дополнительных прыжков или передачи через общедоступный Интернет.

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

Сводка по устойчивости к различным типам сбоев

Сценарий сбоя	Сценарий высокого уровня доступности Или аварийного восстановления Oracle в Azure	RPO/RTO
Сбой одного компонента, например узла, стойки, охлаждения, сети или сбоя питания	Data Guard с двумя узлами в одном и том же Масштабируемые наборы виртуальных машин гибкой оркестрации в одном центре обработки данных: — защищает от сбоя одного экземпляра. — вызывает простой, если весь центр обработки данных завершается сбоем.	Если вы используете Наблюдатель для быстрого запуска отработки отказа и MAX_AVAILABILITY или режима MAX_PROTECTION для Data Guard: — RPO равно нулю. — RTO меньше или равно 2 мин.
Сбой центра обработки данных	Data Guard с двумя узлами в отдельных зонах доступности: — защищает от сбоя центра обработки данных. — вызывает простой, если весь регион завершается ошибкой. — требуется дополнительная конфигурация отработки отказа для серверов приложений для управления задержкой сети.	— RPO меньше или равно 5 мин. — RTO меньше или равно 5 мин. Если вы используете режим MAX_PERFORMANCE и режим MAX_AVAILABILITY для Data Guard: — RPO равно нулю. — RTO меньше или равно 5 мин.
Сбой в регионе	Data Guard с двумя узлами в отдельных регионах Azure: — защищает от региональных сбоев. — требуется дополнительная конфигурация отработки отказа для серверов приложений для управления задержкой сети.	Если для Data Guard используется режим MAX_PERFORMANCE: — RPO больше или равно 10 мин. — RTO больше или равно 15 мин.
Все сценарии: сбой одного компонента, центра обработки данных и региона	Резервные копии, отправленные в другой регион Azure: — защита от региональных сбоев. — требуется настройка всей среды Azure в целевом регионе во время отработки отказа.	— RPO больше или равно 24 ч. — RTO больше или равно 4 ч.

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

Узнайте о рекомендациях по проектированию Oracle в Виртуальные машины безопасности акселератора целевой зоны в сценарии масштабирования предприятия.

Поделиться через