Обзор приложений и решений Oracle в Azure

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

В этой статье вы узнаете о запуске решений Oracle с помощью инфраструктуры Azure.

Внимание

Oracle RAC и Oracle RAC OneNode не поддерживаются в инфраструктуре Azure Bare Metal.

Базы данных Oracle в инфраструктуре Azure

Oracle поддерживает запуск выпусков Базы данных 12.1 и выше Standard и Enterprise в Azure на образах виртуальных машин на основе Oracle Linux. Вы можете запускать базы данных Oracle в инфраструктуре Azure с помощью образов Oracle Database в Oracle Linux, доступных в Azure Marketplace.

  • Oracle Database 12.2 и 18.3 Enterprise Edition
  • Oracle Database 12.2 и 18.3 Standard Edition
  • Oracle Database 19.3
    Вы также можете использовать один из следующих подходов:
  • Настройте Базу данных Oracle на образе, отличном от Oracle Linux, доступном в Azure.
  • Создайте решение на пользовательском образе, который вы создаете с нуля в Azure.
  • Отправьте пользовательский образ из локальной среды.

Вы также можете настроить решение с несколькими подключенными дисками. Вы можете повысить производительность базы данных, установив Oracle Automated служба хранилища Management (ASM). Для обеспечения оптимальной производительности рабочих нагрузок Базы данных Oracle в Azure убедитесь в правильном размере образа виртуальной машины и выберите нужные параметры хранения на основе пропускной способности, операций ввода-вывода в секунду и задержки. Инструкции по быстрому созданию и запуску базы данных Oracle в Azure с помощью опубликованного образа виртуальной машины Oracle см. в статье "Создание базы данных Oracle на виртуальной машине Azure".

Развертывание образов виртуальных машин Oracle в Microsoft Azure

В этом разделе рассматриваются сведения о решениях Oracle на основе образов виртуальных машин, опубликованных Oracle в Azure Marketplace. Чтобы получить список доступных образов Oracle, выполните следующую команду с помощью Azure CLI или Azure Cloud Shell.

az vm image list --publisher oracle --output table –all

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

Внимание

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

Приложения на сервере Oracle Linux и WebLogic

Запуск корпоративных приложений на сервере WebLogic в Azure на поддерживаемых образах Oracle Linux. Дополнительные сведения см. в документации по WebLogic Oracle WebLogic Server в обзоре решения Azure.

WebLogic Server с интеграцией служб Azure

Oracle и Корпорация Майкрософт совместно используют веб-сервер WebLogic Server в Azure Marketplace в виде предложения приложение Azure. Дополнительные сведения об этих предложениях см. в статье "Что такое решения для запуска Oracle WebLogic Server".

Образы виртуальных машин Oracle WebLogic Server

Кластеризация поддерживается только в выпуске Enterprise Edition. Вы лицензируете использовать WebLogic кластеризация только при использовании выпуск Enterprise Oracle WebLogic Server. Не используйте кластеризация с выпуск Standard Oracle WebLogic Server. Многоадресная рассылка UDP не поддерживается. Azure поддерживает одноадресную рассылку по UDP, но не поддерживает ни многоадресную, ни широковещательную рассылку. Oracle WebLogic Server может использовать возможности одноадресной рассылки Azure UDP. Чтобы получить наилучшие результаты при использовании одноадресной рассылки по UDP, мы советуем не изменять размер кластера WebLogic и не размещать более 10 управляемых серверов. Oracle WebLogic Server ожидает, что общедоступные и частные порты будут одинаковыми для доступа T3. Например, при использовании Enterprise JavaBeans (EJB). Рассмотрим многоуровневый сценарий, в котором приложение уровня служб работает в кластере Oracle WebLogic Server, состоящем из двух или нескольких виртуальных машин, в виртуальной сети с именем SLWLS. Клиентский уровень расположен в другой подсети в рамках одной виртуальной сети, выполняющей простую программу Java, которая пытается вызвать EJB на уровне служб. Так как необходимо сбалансировать уровень служб, для виртуальных машин в кластере Oracle WebLogic Server необходимо создать общедоступную конечную точку с балансировкой нагрузки. Если указанный частный порт отличается от общедоступного порта, возникает ошибка. Например, если вы используете 7006:7008, следующая ошибка возникает, так как для любого удаленного доступа T3 Oracle WebLogic Server ожидает, что порт подсистемы балансировки нагрузки и порт управляемого сервера WebLogic будет одинаковым.

[java] javax.naming.CommunicationException [Root exception is java.net.ConnectException: t3://example.cloudapp.net:7006:

Bootstrap to: example.cloudapp.net/138.91.142.178:7006' over: 't3' got an error or timed out]

В предыдущем случае клиент обращается к порту 7006, который является портом подсистемы балансировки нагрузки, и управляемый сервер прослушивает 7008, который является частным портом. Это ограничение применяется только для доступа к каналу T3, а не к HTTP.

Чтобы избежать этой проблемы, используйте одно из следующих решений:

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

  • Включите следующий параметр JVM при запуске Oracle WebLogic Server: configCopy Dweblogic.rjvm.enableprotocolswitch=true

  • Ограничения для динамической кластеризации и балансировки нагрузки. Предположим, что вы хотите использовать динамический кластер в Oracle WebLogic Server и сделать его доступным через единственную общедоступную конечную точку с балансировкой нагрузки в Azure. Этот подход можно сделать до тех пор, пока вы используете фиксированный номер порта для каждого из управляемых серверов, а не динамически назначается из диапазона, и не запускайте более управляемые серверы, чем есть компьютеры, которые администратор отслеживает. На виртуальную машину должно быть не более одного управляемого сервера. Если конфигурация приводит к запуску нескольких серверов Oracle WebLogic, чем виртуальных машин, то для нескольких экземпляров oracle WebLogic Servers невозможно привязать к заданному номеру порта. То есть, если несколько экземпляров Oracle WebLogic Server используют одну и ту же виртуальную машину, другие экземпляры виртуальной машины завершаются ошибкой. Если вы настроите сервер администрирования для автоматического назначения уникальных номеров портов управляемым серверам, балансировка нагрузки невозможна, так как Azure не поддерживает сопоставление из одного общедоступного порта с несколькими частными портами, как и для этой конфигурации.

  • Несколько экземпляров Oracle WebLogic Server на виртуальной машине. В зависимости от требований к развертыванию можно рассмотреть возможность запуска нескольких экземпляров Oracle WebLogic Server на одной виртуальной машине, если виртуальная машина достаточно большая. Например, на средней виртуальной машине, содержащей два ядра, можно запустить два экземпляра Oracle WebLogic Server. Однако мы по-прежнему рекомендуем избежать внедрения отдельных точек сбоя в архитектуре. Запуск нескольких экземпляров Oracle WebLogic Server на одной виртуальной машине будет такой же одной точкой.

Использование по крайней мере двух виртуальных машин может быть лучшим подходом. Каждая виртуальная машина может запускать несколько экземпляров Oracle WebLogic Server. При этом все экземпляры Oracle WebLogic Server могут быть частью одного и того же кластера. Однако сейчас невозможно использовать Azure для балансировки нагрузки конечных точек, предоставляемых такими развертываниями Oracle WebLogic Server на одной виртуальной машине. Azure Load Balancer требует, чтобы серверы с балансировкой нагрузки распределялись между уникальными виртуальными машинами.

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

При использовании решений Oracle в Azure вы несете ответственность за реализацию решения высокого уровня доступности и аварийного восстановления, чтобы избежать простоя. Вы также можете реализовать высокий уровень доступности и аварийное восстановление для oracle Database выпуск Enterprise с помощью Data Guard, Active Data Guard или Oracle GoldenGate. Этот подход требует двух баз данных на двух отдельных виртуальных машинах, которые должны находиться в одной виртуальной сети, чтобы обеспечить доступ друг к другу через частный постоянный IP-адрес.

Мы рекомендуем разместить виртуальные машины в одном наборе доступности, чтобы разрешить Azure размещать их в отдельных доменах сбоя и доменах обновления. Если требуется геоизбыточность, настройте две базы данных для реплика te между двумя различными регионами и подключите два экземпляра с VPN-шлюз. Сведения о базовой процедуре установки в Azure см. в статье "Реализация Oracle Data Guard на виртуальной машине Linux Azure".

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

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

Вы можете эффективно обеспечить высокий уровень доступности для баз данных Oracle с помощью размещения томов зоны доступности Azure NetApp Files в сочетании с Oracle Data Guard для архитектуры высокого уровня доступности между зонами. Кроме того, для устранения затрат на лицензии Data Guard и запуска виртуальных машин в вторичной зоне можно использовать функцию реплика tion на основе хранилища Azure NetApp Files. Тома Azure NetApp Files можно поместить в зону доступности таким же образом, а затем реплика между зонами в пределах региона с помощью межзоны реплика tion (или в другой регион с помощью межрегиональных реплика tion).

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

Резервное копирование рабочих нагрузок Oracle

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

Развертывание приложений Oracle в Azure

Используйте шаблоны Terraform, AZ CLI или портал Azure для настройки инфраструктуры Azure и установки приложений Oracle. Вы также используете Ansible для настройки базы данных на виртуальной машине. Дополнительные сведения см. в статье Terraform в Azure.

Oracle сертифицировано следующие приложения для запуска в Azure при подключении к базе данных Oracle с помощью решения взаимодействия Oracle Cloud:

  • E-Business Suite
  • JD Edwards EnterpriseOne;
  • PeopleSoft;
  • приложения Oracle Retail;
  • Oracle Hyperion Financial Management

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

Поддержка JD Edwards

Согласно поддержке Oracle, JD Edwards EnterpriseOne версии 9.2 и выше поддерживаются в любом общедоступном облачном предложении, которое соответствует определенным минимальным техническим требованиям (MTR). Необходимо создать пользовательские образы, соответствующие спецификациям MTR для обеспечения совместимости операционных систем и программного обеспечения. Дополнительные сведения см. в разделе Doc ID 2178595.1.

Лицензирование

Развертывание решений Oracle в Azure основано на модели собственной лицензии. Эта модель предполагает, что у вас есть лицензии на использование программного обеспечения Oracle и что у вас есть текущее соглашение о поддержке с Oracle. Microsoft Azure является полномочной облачной средой для запуска базы данных Oracle. Таблица Oracle Core Factor не применима при лицензировании баз данных Oracle в облаке. Дополнительные сведения см. в таблице коэффициента ядра процессора Oracle. Вместо этого при использовании виртуальных машин с технология Hyper-Threading включено для баз данных выпуск Enterprise, подсчитывайте два виртуальных ЦП как эквивалентные одной лицензии Oracle Processor, если включена гиперпоточность, как указано в документе политики. Сведения о политике можно найти на странице Лицензирование программного обеспечения Oracle в среде облачных вычислений.
Для баз данных Oracle обычно требуется более высокая память и операций ввода-вывода. Поэтому рекомендуется использовать оптимизированные для памяти виртуальные машины для этих рабочих нагрузок . Чтобы оптимизировать рабочие нагрузки, рекомендуется использовать ограниченные виртуальные ЦП ядра для рабочих нагрузок Базы данных Oracle, требующих высокой памяти, хранилища и пропускной способности ввода-вывода, но не большого количества ядер. При переносе программного обеспечения и рабочих нагрузок Oracle из локальной среды в Microsoft Azure Oracle обеспечивает мобильность лицензий, как описано в статье Oracle и Microsoft Strategic Partnership Faq.

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

Теперь у вас есть общие сведения о текущих базах данных и решениях Oracle на основе образов виртуальных машин в Microsoft Azure. Теперь вы можете приступить к развертыванию своей первой базы данных Oracle в Azure.