Архитектуры для oracle Database выпуск Enterprise в 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 Edition можно собрать те же важные метрики с помощью отчета 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.

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

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

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

Диски ОС по умолчанию. Диски этого типа обеспечивают хранение постоянных данных и кэширование. Они оптимизированы для доступа к ОС при запуске и не предназначены для транзакционных рабочих нагрузок или рабочих нагрузок хранилищ данных (аналитических нагрузок).
Управляемые диски. Управлять учетными записями хранения, используемыми для дисков виртуальной машины, будет Azure. Укажите тип диска и размер нужного диска. Для рабочих нагрузок Oracle чаще всего используется тип Premium (SSD). 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 могла обеспечить расширенные возможности управления.