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

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

  • Статья

Область применения: ✔️ виртуальные машины 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 выпуск 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 Data Guard в Azure с зонами доступности.

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

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

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

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

Схема, на котором показана база данных Oracle с помощью групп доступности с брокером Data Guard — FSFO.

Примечание.

  • Так как развертывается только один экземпляр изготовителя оборудования, вам не нужно размещать виртуальную машину 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.

Схема, на которую показана база данных Oracle с использованием зон доступности с Data Guard Far Sync и Broker — FSFO.

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

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

Схема, на которую показана база данных Oracle с использованием зон доступности для аварийного восстановления с data Guard Far Sync и Broker — FSFO.

Oracle GoldenGate

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

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

Схема, на которую показана база данных Oracle с использованием зон доступности с брокером Data Guard — FSFO.

Примечание.

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

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 в сегментированной базе данных, инициируются в каталоге сегментов. Каталог сегментов также содержит основную копию всех повторяющихся таблиц в SDB.

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

    Рекомендуется использовать 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.

Схема, демонстрирующая сегментирование баз данных Oracle с помощью зон доступности с помощью брокера Data Guard — FSFO.

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

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

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

В предыдущей архитектуре директор 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.

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

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

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

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

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

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

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

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