Архитектуры для Oracle Database Enterprise Edition в Azure

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

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

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

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

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

Важным отличием является то, что при реализации в 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, это можно сделать несколькими способами. Если у вас есть Diagnostics Pack для экземпляров Oracle, вы можете запустить отчет Oracle AWR, чтобы получить такие метрики, как IOPS, Мбит/с и ГиБ. Для баз данных без лицензии пакета Diagnostics Pack или для базы данных 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

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

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

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

Снимок экрана, на котором показано общее количество операций ввода-вывода для чтения и записи.

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

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

Настройте размер виртуальной машины с помощью аналогичной серии на основе ACU

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

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

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

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

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

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

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

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

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

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

• Задержка в сети выше, чем в локальном развертывании. Сокращение круговых путей по сети существенно влияет на производительность.
• Чтобы сократить круговые пути, консолидируйте приложения с высокими транзакциями или чатыми приложениями на одной виртуальной машине.
• Используйте виртуальные машины с ускоренным сетевым подключением для повышения производительности сети.
• Для некоторых дистрибутивов Linux рекомендуется включить поддержку TRIM/UNMAP.
• Установите Oracle Enterprise Manager на отдельной виртуальной машине.
• Огромные страницы по умолчанию не включены в Linux. Рекомендуется включить огромные страницы и задать use_large_pages = ONLY в базе данных Oracle. Этот подход может помочь повысить производительность. Дополнительные сведения см. USE_LARGE_PAGES.

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

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

• Диски ОС по умолчанию. Диски этого типа обеспечивают хранение постоянных данных и кэширование. Они оптимизированы для доступа к ОС при запуске и не предназначены для транзакционных рабочих нагрузок или рабочих нагрузок хранилищ данных (аналитических нагрузок).

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

  Снимок экрана: страница управляемого диска.

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

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

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

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

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

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

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

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

• Для пространства таблиц данных распределяйте рабочую нагрузку ввода-вывода на несколько дисков с помощью управляемого хранилища или управления автоматическим хранилищем Oracle (ASM).
• Используйте расширенное сжатие Oracle для уменьшения числа операций ввода-вывода для данных и индексов.
• Используйте отдельные диски данных для журналов повторяемых операций, а также табличных пространств temp и undo.
• Не размещайте файлы приложений на дисках операционной системы по умолчанию. Эти диски не оптимизированы для быстрой загрузки виртуальной машины и не могут обеспечить высокую производительность приложений.
• При использовании виртуальных машин серии M в хранилище класса «Премиум» включите write accelerator на диске журналов повтора.
• Рассмотрите возможность перемещения журналов повтора с высокой задержкой на диск категории "Ультра".

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

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

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

Чтобы максимально увеличить пропускную способность, по возможности начинайте с режима "Только для чтения" для кэширования узла. Помните, что для хранилища класса "Премиум" необходимо отключить препятствующие факторы при подключении файловой системы с использованием параметров "Только для чтения". Обновите файл /etc/fstab, добавив в него универсальные уникальные идентификаторы (UUID) дисков.

```html Снимок экрана страницы управляемого диска, на которой показан параметр только для чтения. ```

• Для дисков операционной системы используйте SSD класса Premium с кэшированием узла чтения и записи.
• Для дисков данных, содержащих следующее, используйте SSD класса Premium с кэшированием только для чтения: файлы данных Oracle, временные файлы, файлы управления, файлы отслеживания изменений, BFILEs, файлы для внешних таблиц и журналы флэш-памяти.
• Для дисков данных, содержащих файлы журналов изменений Oracle online, используйте SSD категории "Премиум" или "Ультра" без кэширования на уровне узла, опция Нет. Файлы журнала Oracle redo, архивированные, и резервные наборы диспетчера восстановления Oracle также могут находиться вместе с активными файлами журнала redo. Кэширование на узле ограничено 4095 ГиБ, поэтому не выделяйте премиум SSD больше, чем P50 с кэшированием на узле. Если требуется более 4 ТиБ хранилища, объедините несколько премиум SSD с использованием RAID-0. Используйте Linux LVM2 или Oracle Automatic Storage Management.

Если рабочие нагрузки сильно различаются между днем и вечером, и рабочая нагрузка ввода-вывода может это поддерживать, P1-P20 SSD класса Premium с функцией всплескового режима может обеспечить производительность, необходимую для ночных пакетных операций или ограниченных потребностей ввода-вывода.

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

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

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

• Jumpbox: для более безопасного доступа администраторы не должны напрямую подключаться к службам приложений или базам данных. Используйте jumpbox между компьютером администратора и ресурсами Azure.

  Диаграмма, показывающая топологию джампбокса.

  Компьютер администратора должен предоставлять доступ к Jumpbox только по IP-ограничениям. Jumpbox должен иметь доступ к приложению и базе данных.

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

Ресурсы

• Настройка Oracle ASM
• Настроить Oracle Data Guard
• Настройка Oracle GoldenGate
• Создание резервных копий и восстановление Oracle

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

• Создание полной виртуальной машины Linux с помощью Azure CLI
• Исследуйте примеры развертывания виртуальных машин с помощью Azure CLI.