Архитектуры для выпуск Enterprise Базы данных Oracle в Azure

Статья
04/14/2023

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

Azure является домом для всех рабочих нагрузок Oracle, включая рабочие нагрузки, которые должны продолжать работать оптимально в Azure с Oracle. Если у вас есть пакет диагностики Oracle или репозиторий автоматической рабочей нагрузки (AWR), вы можете собирать данные о рабочих нагрузках. Используйте эти данные для оценки рабочей нагрузки Oracle, размера потребностей ресурсов и переноса рабочей нагрузки в Azure. Различные метрики, предоставляемые Oracle в этих отчетах, могут обеспечить понимание производительности приложений и использования платформы.

Эта статья поможет вам подготовить рабочую нагрузку Oracle для запуска в Azure и изучить лучшие решения архитектуры, чтобы обеспечить оптимальную облачную производительность. Данные, предоставляемые Oracle в Statspack и тем более в его потомке, AWR, помогает вам разработать четкие ожидания. Эти ожидания включают ограничения физической настройки через архитектуру, преимущества логической настройки кода базы данных и общую структуру базы данных.

Различия между двумя средами

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

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

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

	Реализация в локальной среде	Реализация в Azure
Сеть	Локальная или глобальная сеть	программно-определяемая сеть (SDN);
Группа безопасности	Средства ограничения портов и IP-адресов	Группа безопасности сети (NSG)
Устойчивость	MTBF	MTTR
Плановое техническое обслуживание	Установка исправлений и обновлений	Группы доступности с исправлениями и обновлениями, управляемыми Azure
Ресурс	Выделенные	Совместное использование с другими клиентами
Регионы	Центры обработки данных	Пары регионов
Память	Сеть SAN и физические диски	Хранилище под управлением Azure
Масштабировать	Вертикальное масштабирование	Горизонтальное масштабирование

Требования

Перед началом миграции рассмотрите следующие требования:

Определите реальную загрузку ЦП. Лицензии Oracle по ядрам, что означает, что изменение размера виртуальных ЦП может быть важным для снижения затрат.
Определите размер базы данных, хранилище резервных копий и темп роста.
Определите требования ввода-вывода, которые можно оценить на основе Oracle Statspack и отчетов AWR. а также с помощью средств мониторинга хранилища на уровне операционной системы.

Варианты конфигурации

Рекомендуется создать отчет AWR и получить из него некоторые метрики, чтобы помочь вам принимать решения о конфигурации. Кроме того, в среде Azure есть четыре области, которые можно настроить для повышения производительности:

размер виртуальной машины;
Пропускная способность сети
Типы дисков и их конфигурации
Настройки кэша дисков.

Создание отчета AWR

Если у вас уже есть база данных Oracle Enterprise Edition и вы планируете выполнить миграцию в Azure, это можно сделать несколькими способами. Если у вас есть пакет диагностики для экземпляров Oracle, можно запустить отчет Oracle AWR, чтобы получить метрики, такие как операции ввода-вывода в секунду, Мбит/с и ГиБ. Для этих баз данных без лицензии пакета диагностики или для базы данных Oracle выпуск Standard можно собирать те же важные метрики с отчетом Statspack после сбора моментальных снимков вручную. Основное различие между этими двумя методами создания отчетов заключается в том, что сбор AWR выполняется автоматически, а также предоставляет больше сведений о базе данных, чем Statspack.

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

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

Для запуска отчета AWR из командной строки используйте такую команду:

sqlplus / as sysdba
@$ORACLE_HOME/rdbms/admin/awrrpt.sql;

Основные метрики

Скрипт запрашивает следующие сведения:

Тип отчета: HTML или текст. HTML-отчет содержит дополнительные сведения.
Число дней, в течение которых моментальные снимки должны отображаться. Например, для часовых интервалов недельный отчет создает 168 идентификаторов моментальных снимков.
Начальный ИД SnapshotID для окна отчета.
Конечный ИД SnapshotID для окна отчета.
Имя отчета, создаваемого скриптом AWR.

При запуске отчета AWR в Real Application Cluster (RAC) файл отчета командной строки называется awrgrpt.sql, а не awrrpt.sql. Отчет g создает отчет для всех узлов в базе данных RAC в одном отчете. Этот устраняет необходимость запускать по одному отчету на каждом узле RAC.

Вы можете получить следующие метрики из отчета AWR:

имя базы данных, имя экземпляра и имя узла;
Версия базы данных для поддержки Oracle
ЦП/ядра;
SGA/PGA и помощники, чтобы сообщить вам, если недоуменные
общий объем памяти в ГБ;
процент загрузки ЦП;
ЦП базы данных;
операции ввода-вывода в секунду (чтение и запись);
Мбит/с (чтение и запись);
Пропускная способность сети
показатель задержек сети (низкий и высокий уровень);
основные события ожидания;
настройки параметров для базы данных;
Независимо от того, является ли база данных RAC, Exadata или используется расширенные функции или конфигурации

размер виртуальной машины;

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

Оценка необходимого размера виртуальных машин на основе использования ЦП, памяти или операций ввода-вывода из отчета AWR

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

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

На следующей схеме представлены общие показатели операций ввода-вывода для чтения и записи. На момент создания отчета для операций чтения зафиксирован показатель 59 ГБ, а для операций записи — 247,3 ГБ.

Выбор виртуальной машины

Далее на основе данных из отчета AWR следует выбрать размер виртуальной машины, который соответствует вашим требованиям. Дополнительные сведения о доступных виртуальных машинах см. в разделе "Оптимизированные для памяти размеры виртуальных машин".

Выбор размера виртуальных машин аналогичной серии на основе ACU

Выбрав виртуальную машину, обратите внимание на единицу вычислений Azure (ACU) для виртуальной машины. Можно выбрать разные виртуальные машины на основе значения ACU, которое соответствует вашим требованиям. Дополнительные сведения см. в статье Единицы вычислений Azure (ACU).

Снимок экрана: страница единиц ACU.

Пропускная способность сети

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

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

Общая пропускная способность сети зависит от следующих показателей:

объем трафика SQL*Net;
Количество серверов (исходящий поток, например Oracle Data Guard)
другие факторы, такие как репликация приложений.

Снимок экрана: пропускная способность SQL*Net.

С учетом требований к пропускной способности сети можно выбрать разные типы шлюзов. К этим типам относятся базовые, VPNGw и Azure ExpressRoute. Дополнительные сведения см. на странице цен на VPN-шлюз.

Типы дисков и их конфигурации

Ниже приведены некоторые советы по рассмотрению дисков.

Диски ОС по умолчанию. Диски этого типа обеспечивают хранение постоянных данных и кэширование. Они оптимизированы для доступа к ОС при запуске и не предназначены для транзакционных рабочих нагрузок или рабочих нагрузок хранилищ данных (аналитических нагрузок).
Управляемые диски. Управлять учетными записями хранения, используемыми для дисков виртуальной машины, будет Azure. Укажите тип диска и нужный размер диска. Тип чаще всего является премиум (SSD) для рабочих нагрузок Oracle. Azure самостоятельно создаст диск и будет управлять им. Диск, управляемый SSD уровня "Премиум", доступен только для оптимизированных для памяти и разработанных рядов виртуальных машин. Когда вы выберете определенный размер виртуальной машины, в меню отобразятся только доступные номера SKU для хранилища класса Premium с учетом этого размера.

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

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

Так как Oracle может быть интенсивной базой данных ввода-вывода, важно размер хранилища на основе скорости операций ввода-вывода, а не размера хранилища. Например, если требуемое значение операций ввода-вывода в секунду составляет 5000, но вам потребуется только 200 ГБ, вы все равно можете получить диск класса P30 класса Premium, даже если он поставляется с более чем 200 ГБ хранилища.

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

Снимок экрана: страница отчета AWR.

Например, скорость повторяемых операций составляет 12,200,000 байт в секунду, что равно 11,63 Мбит/с. Значение ввода-вывода в секунду составляет 12 200 000 / 2 358 = 5 174.

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

Настройки кэша дисков.

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

Безопасность

После настройки и настройки среды Azure необходимо защитить сеть. Вот несколько рекомендаций.

Политика NSG: вы можете задать NSG для подсети или сетевого адаптера. Чтобы обеспечить безопасность и принудительную маршрутизацию для таких компонентов, как приложения брандмауэра, проще управлять доступом на уровне подсети.
Jumpbox: для более безопасного доступа администраторы не должны напрямую подключаться к службам приложений или базам данных. jumpbox используется на промежутке между ресурсами Azure и компьютером администратора.

Компьютер администратора должен предоставлять доступ только к Jumpbox. Для Jumpbox следует предоставить доступ к базам данных и приложениям.
Частная сеть (подсети): рекомендуем устанавливать службу приложений и базу данных в разных подсетях, чтобы политика NSG могла обеспечить расширенные возможности управления.

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

Архитектуры для выпуск Enterprise Базы данных Oracle в Azure

Различия между двумя средами

Требования

Варианты конфигурации

Создание отчета AWR

Основные метрики

размер виртуальной машины;

Оценка необходимого размера виртуальных машин на основе использования ЦП, памяти или операций ввода-вывода из отчета AWR

Выбор виртуальной машины

Выбор размера виртуальных машин аналогичной серии на основе ACU

Пропускная способность сети

Рекомендации

Типы дисков и их конфигурации

Рекомендации по типу диска

Настройки кэша дисков.

Рекомендации по кэшу дисков

Безопасность

Ресурсы

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

Обратная связь

Обратная связь

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