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

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

  • Статья

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

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

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

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

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

Высокий уровень доступности для баз данных 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.

Для репликации данных с длинным расстоянием рекомендуется использовать Far Sync. Far Sync — это функция Oracle Active Data Guard.

Примечание.

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

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

Примечание.

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

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

Oracle Data Guard;

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

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

Data Guard можно развернуть с помощью быстрого запуска отработки отказа (FSFO). Быстрая отработка отказа — это функция, предоставляемая в конфигурации брокера Data Guard. Эта функция позволяет автоматически выполнять отработку отказа в случае сбоя. Время использования клиентов по умолчанию — 30 секунд, но их можно настроить в соответствии с вашими требованиями. Это так называемое OperationTimeout является частью свойств Data Guard, которые вы определяете во время развертывания.

Как Data Guard работает с этим свойством

Задача "Защита данных" заключается в непрерывном мониторинге работоспособности и состояния первичной и вторичной базы данных. Как только вы включите быструю отработку отказа (FSFO), процесс наблюдателя активируется и проверяет состояние работоспособности на регулярном интервале, чтобы обеспечить высокий уровень доступности в любое время.

Теперь, если база данных-источник становится недоступной, наблюдатель и брокер Data Guard обнаруживают это прерывание. Таким образом, параметр OperationTimeout в 30 секунд указывает, сколько времени брокер должен ожидать ответа от базы данных-источника, прежде чем принимать какие-либо дальнейшие действия.

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

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

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

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

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

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

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

Схема, показывющая архитектуру Oracle Data Guard.

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

Примечание.

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

Кроме того, мы настоятельно рекомендуем развернуть Oracle Enterprise Manager, чтобы иметь общие сведения об уровне базы данных. Рекомендуется развернуть Azure Monitor со следующими метриками: отслеживайте диски:

  • Процент использования операций ввода-вывода в секунду на диск ОС
  • Процент использования операций ввода-вывода в секунду на диск данных
  • Диск данных считывает байт/с
  • Диск данных записывает байт/с
  • Длина очереди диска
  • Пропускная способность диска в процентах на lun

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

Виртуальная машина выбирается на основе оценки AWR. Дополнительные сведения см . в разделе "Планирование емкости Oracle". Мы настоятельно рекомендуем использовать ограниченные виртуальные ЦП ядра, чтобы сэкономить на затратах на лицензирование и повысить производительность.

Выбор типа диска зависит от выходных данных оценки AWR.

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

Ssd уровня "Премиум" версии 2 не поддерживается для файлов, ссылающихся на операционную систему. Дополнительные сведения см. в статье Deploy Premium SSD версии 2.

В качестве целевого файла Azure Premium используется служба резервного копирования. Это решение является наиболее производительным. Вы также можете использовать Хранилище BLOB-объектов Azure в качестве назначения резервного копирования. Всегда проверяйте, какой вариант подходит вам лучше всего. Также посетите стратегии резервного копирования базы данных Oracle.

Oracle Data Guard Far Sync

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

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

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

Схема, на которую показана база данных Oracle с помощью Far Sync в конфигурации Active Data Guard в разных регионах.

Примечание.

При планировании симметричного развертывания Far Sync обратите внимание, что вам потребуется еще один экземпляр Far Sync во втором регионе.

Oracle GoldenGate

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

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

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

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

    Рекомендуется использовать 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 для упрощения управления хранилищем для базы данных.
  • Введение в Oracle Data Guard
  • Настройте код приложения для добавления облачных шаблонов, которые могут помочь приложению быть более устойчивыми. Рассмотрим такие шаблоны, как шаблон повторных попыток, шаблон разбиения цепи и другие, определенные в руководстве по шаблонам облачного проектирования.

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

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