Эталонные архитектуры для Oracle Database Enterprise Edition в Azure

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

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

Предположения

  • Вы имеете представление о различных понятиях Azure, таких как зоны доступности.
  • Вы используете среду Oracle Database Enterprise Edition 12c или более поздней версии.
  • Вы знаете об условиях лицензирования, применяемого при использовании решений, описанных в этой статье, и вы согласны с ними.

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

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

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

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

Oracle RAC в облаке

Oracle Real Application Cluster (RAC) — это решение Oracle, которое помогает клиентам достичь высокой пропускной способности, обеспечивая доступ множества экземпляров к одному хранилищу базы данных (шаблон архитектуры Shared-all). Хотя Oracle RAC можно также использовать для обеспечения высокой доступности в локальной среде, одного этого решения недостаточно, чтобы обеспечить высокий уровень доступности в облаке, так как оно обеспечивает только защиту от сбоев на уровне экземпляра, а не на уровне стойки или центра обработки данных. По этой причине для обеспечения высокого уровня доступности Oracle рекомендует использовать Oracle Data Guard для базы данных (отдельного экземпляра или RAC). Клиентам обычно требуется соглашение о высоком уровне обслуживания для выполнения критически важных приложений. Решение Oracle RAC в настоящее время не сертифицировано или не поддерживается Oracle в Azure. Тем не менее платформа 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 вблизи от базы данных-источника и по крайней мере один экземпляра Far Sync вблизи от резервной базы данных (на случай смены их ролей). Дополнительные сведения об Oracle Data Guard Far Sync доступны в техническом документе по Oracle Active Data Guard Far Sync.

Если вы используете базы данных Oracle Standard Edition, то существуют решения независимых поставщиков программного обеспечения, такие как 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 with FSFO

Oracle Data Guard with Fast-Start Failover (FSFO) может повысить устойчивость за счет настройки брокера на отдельном компьютере. Брокер Data Guard и база данных-получатель запускают наблюдатель и отслеживают базу данных-источник во время простоя. Это также обеспечивает избыточность конфигурации наблюдателя Data Guard.

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

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

Схема, на которой представлена рекомендуемая архитектура для использования Oracle Data Guard в Azure с зонами доступности.

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

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

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

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

Oracle Database: использование групп доступности с брокером Data Guard (FSFO)

Примечание

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

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.

База данных Oracle: использование зон доступности с Data Guard Far Sync и брокером (FSFO)

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

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

Oracle Database: использование зон доступности для аварийного восстановления с помощью Service Guard Far Sync и брокера (FSFO)

Oracle GoldenGate

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

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

Oracle Database: использование зон доступности с брокером Data Guard (FSFO)

Примечание

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

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

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

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

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

Oracle Sharding

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

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

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

Ниже приведены основные компоненты Oracle Sharding. Дополнительные сведения об этих компонентах можно найти в документации по Oracle Sharding.

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

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

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

  • Директоры сегментов — упрощенные службы, которые необходимо развернуть в каждом регионе или зоне доступности, где хранятся сегменты. Директоры сегментов — это службы Global Service Manager (GSM), развертываемые в контексте Oracle Sharding. Для обеспечения высокого уровня доступности рекомендуется развернуть по крайней мере один директор сегментов в каждой зоне доступности, в которой существуют сегменты.

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

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

  • Глобальная служба — это служба, аналогичная обычной службе базы данных. В дополнение ко всем свойствам службы базы данных, глобальная служба имеет свойства для сегментированных баз данных, таких как сходство клиентов для сегмента, а также допустимая задержка репликации. Для чтения и записи данных в сегментированной базе данных необходимо создать только одну глобальную службу. Если используется Active Data Guard и настроены реплики только для чтения для сегментов, то можно создать еще одну глобальную службу для рабочих нагрузок только для чтения. Клиент может использовать эти глобальные службы для подключения к базе данных.

  • Сегментированные базы данных — это ваши базы данных Oracle. Каждая база данных реплицируется с помощью Oracle Data Guard в конфигурации брокера с включенной функцией Fast-Start Failover (FSFO). Вам не нужно настраивать отработку отказа и репликацию Data Guard для каждого сегмента. Она автоматически настраивается и развертывается при создании сегментированной базы данных. В случае сбоя конкретного сегмента Oracle Sharing автоматически выполняет отработку отказа подключений базы данных-источника на резервную базу данных.

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

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

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

Дополнительные сведения о различных методах сегментирования представлены в документации Oracle.

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

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

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

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

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

Oracle Database Sharding: использование зон доступности с брокером Data Guard (FSFO)

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

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

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

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

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

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

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

Oracle Database Sharding: использование зон доступности и GoldenGate

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

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

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

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

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

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

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

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

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

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

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

  • Для размещения Oracle Database рекомендуется использовать оптимизированную для операций в памяти виртуальную машину с поддержкой технологии Hyperthreading и ограниченным числом ядер виртуальных ЦП, чтобы сэкономить на стоимости лицензий и обеспечить максимальную производительность. Для обеспечения производительности и доступности используйте несколько управляемых дисков ценовой категории "Премиум" или "Ультра".
  • При использовании управляемых дисков имя диска или устройства может изменяться при перезагрузке. Вместо имени рекомендуется использовать идентификатор UUID устройства, чтобы обеспечить сохранение подключений при перезагрузке. Дополнительные сведения см. в статье Настройка программных массивов RAID на виртуальной машине Linux.
  • Используйте зоны доступности для обеспечения высокого уровня доступности в регионе.
  • Рассмотрите возможность использования дисков ценовой категории "Ультра" (если доступно) или "Премиум" для базы данных Oracle.
  • Рекомендуется настроить резервную базу данных Oracle в другом регионе Azure с использованием Oracle Data Guard.
  • Для уменьшения задержки между уровнем приложения и уровнем базы данных рекомендуется использовать группы размещения близкого взаимодействия.
  • Настройте Oracle Enterprise Manager для управления, мониторинга и ведения журнала.
  • Чтобы упростить управление хранилищем базы данных, рекомендуется использовать решение Oracle Automatic Storage Management (ASM).
  • Используйте Azure Pipelines для управления установкой исправлений и обновлений для базы данных, чтобы избавиться от простоев.
  • Настройте код приложения, чтобы добавить собственные шаблоны для облака, такие как шаблон повтора, шаблон прерывателя и другие шаблоны, определенные в руководстве по конструктивным шаблонам для облака. Это поможет повысить устойчивость вашего приложения.

Дальнейшие действия

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