Архитектуры для базы данных Oracle в Azure Виртуальные машины

Статья
06/13/2023

Область применения: ✔️ виртуальные машины Linux

В этой статье содержатся сведения о развертывании высокодоступной базы данных Oracle в Azure. Кроме того, в этом руководстве подробно рассмотрены вопросы аварийного восстановления. Все описанные здесь архитектуры были созданы на основе развертываний клиентов. Данное руководство применимо только к Oracle Database Enterprise Edition.

Если вы хотите узнать больше о максимизации производительности базы данных Oracle, см. статью "Проектирование" и реализация базы данных Oracle в Azure.

Необходимые компоненты

Понимание различных понятий Azure, таких как зоны доступности
База данных Oracle выпуск Enterprise 12c или более поздней версии
Осведомленность о последствиях лицензирования при использовании решений в этой статье

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

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

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

В этом руководстве описываются эталонные архитектуры для каждого из этих решений.

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

Oracle RAC в облаке

Кластер приложений Oracle Real (RAC) — это решение Oracle, помогающее клиентам достичь высокой пропускной способности, имея множество экземпляров, обращаюющихся к одному хранилищу баз данных. Этот шаблон представляет собой общую архитектуру. Хотя Oracle RAC можно использовать для обеспечения высокой доступности в локальной среде, oracle RAC не может использоваться только для обеспечения высокой доступности в облаке. Oracle RAC защищает только от сбоев на уровне экземпляра, а не от сбоев на уровне стойки или центра обработки данных. По этой причине Oracle рекомендует использовать Oracle Data Guard с базой данных, будь то один экземпляр или RAC, для обеспечения высокой доступности.

Как правило, клиентам требуется высокий уровень обслуживания для выполнения критически важных приложений. Oracle в настоящее время не сертифицируют или поддерживают Oracle RAC в Azure. Однако Azure предлагает такие функции, как зоны доступности и запланированные периоды обслуживания, которые помогают защититься от сбоев на уровне экземпляров. Помимо этих предложений, вы можете использовать Oracle Data Guard, Oracle GoldenGate и Oracle Sharding для обеспечения высокой производительности и устойчивости. Эти технологии могут помочь защитить базы данных от сбоев на уровне стоек, центра обработки данных и геополитических сбоев.

При запуске баз данных Oracle в нескольких зонах доступности с помощью Oracle Data Guard или GoldenGate вы можете получить соглашение об уровне обслуживания от 99,99%. В регионах Azure, где зоны доступности еще не присутствуют, можно использовать группы доступности и обеспечить соглашение об уровне обслуживания от 99,95 %.

Примечание.

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

Аварийное восстановление баз данных Oracle

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

Для Oracle Database Enterprise Edition удобной функцией аварийного восстановления является Oracle Data Guard. Вы можете настроить резервный экземпляр базы данных в сопряженном регионе Azure и настроить отработку отказа Data Guard для аварийного восстановления. Для нулевой потери данных рекомендуется развернуть экземпляр Oracle Data Guard Far Sync в дополнение к Active Data Guard.

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

Приложение может не разрешить потерю производительности при настройке экземпляра Far Sync в другой зоне доступности в режиме максимальной доступности (синхронно). В противном случае можно настроить экземпляр Far Sync в той же зоне доступности, что и база данных-источник. Для дополнительной доступности рекомендуется настроить несколько экземпляров Far Sync близко к базе данных-источнику и по крайней мере один экземпляр, близкий к резервной базе данных, если роль переходит. Дополнительные сведения см. в статье Oracle Active Data Guard Far Sync.

При использовании баз данных Oracle выпуск Standard существуют решения isV, которые позволяют настроить высокий уровень доступности и аварийное восстановление, например DBVisit Standby.

Эталонные архитектуры

Oracle Data Guard;

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

При использовании Oracle Data Guard можно также открыть базу данных-получатель для целей только для чтения. Эта конфигурация называется Active Data Guard. В Oracle Database 12c представлен компонент, называемый экземпляром Data Guard Far Sync. Этот экземпляр позволяет настроить конфигурацию защиты от потери данных для базы данных Oracle, которая не влияет на производительность.

Примечание.

Для использования Active Data Guard требуется дополнительная лицензия. Эта лицензия также необходима для использования компонента Far Sync. Обратитесь к представителю Oracle, чтобы обсудить последствия лицензирования.

Oracle Data Guard с быстрой отработкой отказа

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

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

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

На предыдущей схеме клиентская система обращается к пользовательскому приложению с серверной частью Oracle с помощью Интернета. Веб-интерфейс настроен в подсистеме балансировки нагрузки. Веб-интерфейс выполняет вызов к соответствующему серверу приложений, чтобы выполнить обработку. Сервер приложений отправляет запрос к базе данных-источнику Oracle. База данных Oracle была настроена для использования оптимизированной для операций в памяти виртуальной машины с поддержкой технологии Hyperthreading и ограниченным числом ядер виртуальных ЦП, чтобы сэкономить на стоимости лицензий и обеспечить максимальную производительность. Для обеспечения производительности и высокого уровня доступности используется несколько управляемых дисков ценовой категории "Премиум" или "Ультра".

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

В этом случае можно настроить другие наблюдатели или резервные базы данных в другой зоне доступности, AZ 1, чем зона, показанная в предыдущей архитектуре. Наконец, Oracle Enterprise Manager (OEM) отслеживает базы данных Oracle для доступности и производительности. OEM также дает возможность генерировать различные отчеты о производительности и использовании.

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

Примечание.

Так как развертывается только один экземпляр изготовителя оборудования, вам не нужно размещать виртуальную машину Oracle Enterprise Manager в группе доступности.
В настоящее время в конфигурации групп доступности не поддерживаются диски ценовой категории "Ультра".

Oracle Data Guard Far Sync

Oracle Data Guard Far Sync обеспечивает защиту от потери данных для баз данных Oracle. Эта возможность позволяет защититься от потери данных в случае сбоя компьютера с базой данных. Oracle Data Guard Far Sync нужно установить на отдельной виртуальной машине. Far Sync — это упрощенный экземпляр Oracle, который содержит только управляющий файл, файл пароля, файл spfile и резервные журналы. В нем нет файлов данных или файлов журнала повторов.

Для защиты от потери данных необходима синхронный обмен данными между базой данных-источником и экземпляром Far Sync. Экземпляр Far Sync получает файлы повтора из базы данных-источника в синхронном режиме и передает их сразу во все резервные базы данных в асинхронном режиме. Эта конфигурация также сокращает затраты на базу данных-источник, так как она должна отправить файлы повтора только в экземпляр Far Sync, а не во все резервные базы данных. Если происходит сбой экземпляра Far Sync, Data Guard автоматически использует асинхронную передачу данных в базу данных-получатель из базы данных-источника для защиты от потери данных. Для обеспечения надежности клиенты могут развертывать несколько экземпляров Far Sync для каждого экземпляра базы данных, включая первичные и вторичные.

На следующей схеме показана архитектура с высоким уровнем доступности с использованием Oracle Data Guard Far Sync.

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

На следующей схеме представлена архитектура, которая использует Oracle Data Guard FSFO и Far Sync для обеспечения высокой доступности и аварийного восстановления:

Oracle GoldenGate

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

Oracle GoldenGate позволяет настроить высокий уровень доступности базы данных, обеспечивая двунаправленную репликацию. Этот подход позволяет настроить конфигурацию с несколькими узлами или активными активными пользователями. На следующей схеме показана рекомендуемая архитектура для конфигурации "активный — активный" Oracle GoldenGate в Azure. В приведенной ниже архитектуре база данных Oracle настроена для использования оптимизированной для операций в памяти виртуальной машины с поддержкой технологии Hyperthreading и ограниченным числом ядер виртуальных ЦП, чтобы сэкономить на стоимости лицензий и обеспечить максимальную производительность. В архитектуре используется несколько дисков ценовой категории "Премиум" или "Ультра" (управляемые диски) для повышения производительности и доступности.

Примечание.

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

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

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

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

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

Уровень приложения и уровень базы данных можно настроить в отдельных подсетях. По возможности рекомендуется использовать Шлюз приложений Azure для балансировки трафика между серверами приложений. Шлюз приложений — это надежная подсистема балансировки нагрузки веб-трафика. Он обеспечивает сходство сеансов на основе файлов cookie, которое сохраняет сеанс пользователя на одном сервере, минимизируя конфликты в базе данных. В качестве альтернативы Шлюзу приложений можно использовать Azure Load Balancer и Диспетчер трафика Azure.

Oracle Sharding

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

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

Шаблон Sharding подходит для приложений OLTP с высокой пропускной способностью, которые не допускают простоев. Все строки с одним ключом сегментирования всегда гарантированно находятся на одном сегменте. Этот факт повышает производительность, обеспечивая высокую согласованность. Приложения, использующие сегментирование, должны иметь четко определенную модель данных и стратегию распределения данных, например согласованный хэш, диапазон, список или составной. Стратегия в основном обращается к данным с помощью ключа сегментирования, например customerId или accountNum. Сегментирование также позволяет хранить определенные наборы данных ближе к конечным клиентам, что помогает удовлетворить требования к производительности и соответствию требованиям.

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

Для обеспечения высокого уровня доступности резервные сегменты могут размещаться в той же зоне доступности, что и сегменты-источники. На случай аварийного восстановления резервные сегменты могут размещаться в другом регионе. Вы также можете развернуть сегменты в нескольких регионах для обслуживания трафика в этих регионах. Дополнительные сведения о настройке высокого уровня доступности и реплика подключении сегментированной базы данных см. в статье "Высокий уровень доступности сегментов".

Ниже приведены основные компоненты Oracle Sharding. Дополнительные сведения см. в обзоре сегментирования Oracle:

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

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

Рекомендуется использовать Oracle Data Guard с зонами доступности или группами доступности для обеспечения высокого уровня доступности каталога сегментов. Доступность каталога сегментов не влияет на доступность сегментированной базы данных. Простой в каталоге сегментов влияет только на операции обслуживания и многосегментные запросы в течение короткого периода, пока выполняется отработка отказа Data Guard. SDB продолжает маршрутизировать и запускать онлайн-транзакции. Сбой каталога не влияет на них.
Директора сегментов. Упрощенные службы, которые необходимо развернуть в каждом регионе или зоне доступности, в которой находятся сегменты. Директоры сегментов — это службы Global Service Manager (GSM), развертываемые в контексте Oracle Sharding. Для обеспечения высокой доступности рекомендуется развернуть по крайней мере один директор сегментов в каждой зоне доступности, в которую существуют сегменты.

При первоначальном подключении к базе данных директор сегментов настраивает сведения о маршрутизации и кэширует сведения для последующих запросов, которые обходят директора сегментов. После того как установлен сеанс с сегментом, все SQL-запросы и операции DML поддерживаются и выполняются в области заданного сегмента. Это быстрая маршрутизация, она используется для всех рабочих нагрузок OLTP, выполняющих транзакции внутри сегмента. Рекомендуется использовать прямую маршрутизацию для всех рабочих нагрузок OLTP, требующих высокой производительности и доступности. Кэш маршрутизации автоматически обновляется, когда сегмент становится недоступным или происходит изменение топологии сегментирования.

Чтобы обеспечить высокопроизводительную маршрутизацию, зависящую от данных, Oracle рекомендует использовать пул подключений для доступа к данным в сегментированной базе данных. Поддержка Oracle Sharding реализована в пулах подключений Oracle, библиотеках для конкретных языков и драйверах. Дополнительные сведения см. в разделе "Обзор сегментирования Oracle".
Глобальная служба. Глобальная служба аналогична обычной службе баз данных. Помимо всех свойств службы базы данных, глобальная служба имеет свойства для сегментированных баз данных. К этим свойствам относятся сходство регионов между клиентами и сегментами и реплика отказоустойчивость отложений. Для чтения и записи данных из сегментированной базы данных необходимо создать только одну глобальную службу. При использовании Active Data Guard и настройке реплика сегментов только для чтения можно создать другую глобальную службу для рабочих нагрузок только для чтения. Клиент может использовать эти глобальные службы для подключения к базе данных.
Базы данных сегментов. Базы данных сегментов — это базы данных Oracle. Каждая база данных реплика с помощью Oracle Data Guard в конфигурации брокера с включенным FSFO. Вам не нужно настраивать отработку отказа и репликацию Data Guard для каждого сегмента. Этот аспект автоматически настраивается и развертывается при создании общей базы данных. Если определенный сегмент завершается ошибкой, общий доступ Oracle выполняет отработку отказа подключения к базе данных из основного в резервный.

Вы можете развертывать сегментированные базы данных Oracle и управлять ими с двумя интерфейсами: графическим интерфейсом Oracle Enterprise Manager Cloud Control и служебной GDSCTL программой командной строки. Вы даже можете отслеживать доступность и производительность различных сегментов с помощью Cloud Control. Команда GDSCTL DEPLOY автоматически создает сегменты и соответствующие им прослушиватели. Кроме того, эта команда автоматически развертывает конфигурацию репликации, которая используется для обеспечения высокого уровня доступности на уровне сегментов, заданного администратором.

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

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

Дополнительные сведения см. в разделе "Методы сегментирования".

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

Дублированные таблицы хранятся во всех сегментах, тогда как сегментированные таблицы распределяются по разным сегментам. Рекомендуется дублировать небольшие и мерные таблицы и распределять или сегментировать таблицы фактов. Данные можно загрузить в сегментированную базу данных, используя каталог сегментов в качестве центрального координатора или запуская процесс Data Pump для каждого сегмента. Дополнительные сведения см. в разделе "Перенос данных в сегментированную базу данных".

Использование Oracle Sharding с Data Guard

Oracle Data Guard можно использовать для методов сегментирования, управляемого системой, сегментирования, определяемого пользователем, и составного сегментирования.

На следующей схеме представлена эталонная архитектура Oracle Sharding, в которой Oracle Data Guard используется для обеспечения высокого уровня доступности каждого сегмента. На схеме архитектуры показан метод составного сегментирования. Схема архитектуры, вероятно, отличается для приложений с различными требованиями к локальности данных, балансировке нагрузки, высокой доступности и аварийному восстановлению. Приложения могут использовать другой метод для сегментирования. Предоставляя данные возможности, Oracle Sharding позволяет выполнять эти требования и масштабировать их горизонтально и эффективно. Подобную архитектуру можно даже развернуть с использованием Oracle GoldenGate.

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

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

Каждое пространство сегментов содержит несколько групп сегментов. Каждая группа сегментов имеет несколько сегментов и является единицей реплика. Каждая группа сегментов содержит все данные в пространстве сегментов. Группы сегментов A1 и B1 являются группами-источниками, а группы сегментов A2 и B2 — резервными группами. Вы можете выбрать отдельные сегменты как единицу реплика tion, а не группу сегментов.

В предыдущей архитектуре директор global Service Manager (GSM)/shard развертывается в каждой зоне доступности для обеспечения высокой доступности. Рекомендуется развернуть по крайней мере один директор GSM/сегментов на центр обработки данных или регион. Кроме того, экземпляр сервера приложений развертывается в каждой зоне доступности, содержащей группу сегментов. Такая конфигурация обеспечивает приложению низкую задержку между сервером приложений и базой данных или группой сегментов. В случае сбоя базы данных сервер приложений в той же зоне, что и резервная база данных, сможет выполнять запросы сразу же после переключения роли базы данных. Шлюз приложений Azure и директор сегментов отслеживают задержку запросов и ответов и соответствующим образом перенаправляют запросы.

С точки зрения приложения клиентская система отправляет запрос на Шлюз приложений Azure или другие технологии балансировки нагрузки в Azure, которая перенаправляет запрос в регион, ближайший к клиенту. Шлюз приложений Azure также поддерживает прикрепленные сеансы, поэтому все запросы, поступающие от одного клиента, направляются на один и тот же сервер приложений. Сервер приложений использует пулы подключений в драйверах доступа к данным. Эта функция доступна в драйверах, таких как JDBC, ODP.NET и OCI. Драйверы могут распознавать ключи сегментирования, указанные в рамках запроса. Пул Oracle Universal Connection Pool (UCP) для клиентов JDBC позволяет клиентам сторонних приложений, таких как Apache TOMCAT и IIS, взаимодействовать с Oracle Sharding. Дополнительные сведения см. в разделе "Общие пулы UCP" для сегментирования баз данных.

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

Использование Oracle Sharding с GoldenGate

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

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

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

В предыдущей архитектуре группы сегментов A и B содержат одни и те же данные, но находятся в разных зонах доступности. Если оба сегмента группы A и shardgroup B имеют один и тот же коэффициент реплика tion 3, каждая строка или блок таблицы реплика по двум сегментированным группам. Если shardgroup A имеет коэффициент реплика tion 3 и сегментгрупп B имеет коэффициент реплика tion 2, каждая строка или блок реплика раз в двух группах сегментов.

Такая конфигурация предотвращает потерю данных в случае сбоя на уровне экземпляра или зоны доступности. Уровень приложения может выполнять чтение и запись данных в каждом сегменте. Чтобы свести к минимуму конфликты, Oracle Sharding назначает главный блок для каждого диапазона хэш-значений. Эта функция гарантирует, что запросы на запись для определенного блока направляются в соответствующий блок. Кроме того, Oracle GoldenGate обеспечивает автоматическое обнаружение конфликтов и разрешение для обработки любых конфликтов, которые могут возникнуть. Дополнительные сведения и ограничения реализации GoldenGate с помощью Oracle Sharding см. в статье Об использовании Oracle GoldenGate с сегментированной базой данных.

В предыдущей архитектуре для обеспечения высокого уровня доступности в каждой зоне доступности развертывается служба GSM (директор сегментов). Рекомендуется развернуть по крайней мере один директор GSM/сегментов на центр обработки данных или регион. Экземпляр сервера приложений развертывается в каждой зоне доступности, содержащей группу сегментов. Такая конфигурация обеспечивает приложению низкую задержку между сервером приложений и базой данных или группой сегментов. В случае сбоя базы данных сервер приложений в той же зоне, что и резервная база данных, сможет выполнять запросы сразу же после переключения роли базы данных. Шлюз приложений Azure и директор сегментов отслеживают задержку запросов и ответов и соответствующим образом перенаправляют запросы.

Установка исправлений и обслуживание

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

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

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

Ознакомьтесь с приведенными ниже справочными статьями Oracle, которые относятся к вашему сценарию.

Архитектуры для базы данных Oracle в Azure Виртуальные машины

Необходимые компоненты

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

Oracle RAC в облаке

Аварийное восстановление баз данных Oracle

Эталонные архитектуры

Oracle Data Guard;

Oracle Data Guard с быстрой отработкой отказа

Oracle Data Guard Far Sync

Oracle GoldenGate

Oracle Sharding

Использование Oracle Sharding с Data Guard

Использование Oracle Sharding с GoldenGate

Установка исправлений и обслуживание

Рекомендации по архитектуре и проектированию

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

Дополнительные ресурсы