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

В этой статье приведены рекомендации по Azure Cloud Adoption Framework и рекомендации по планированию емкости инфраструктуры для рабочих нагрузок Oracle в Microsoft Azure. В этой статье содержатся рекомендации и средства, которые помогут вам с этим процессом планирования.

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

Планирование емкости помогает выбрать соответствующую инфраструктуру для архитектуры Oracle в Azure. Для эффективной реализации этого процесса необходимо понимать емкость хранилища базы данных.

Рекомендации по планированию емкости

Планирование емкости для рабочих нагрузок Oracle в инфраструктуре Azure как услуга (IaaS) — это процесс, который требует глубокого понимания требований к рабочей нагрузке и доступных ресурсов Azure.

Общие рекомендации по производительности

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

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

  Заметка

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

• Сбор отчетов AWR для рабочей нагрузки базы данных:

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

  • На период, который характерен для пиковой нагрузки. Например, создайте отчет AWR во время процесса окончания месяца, если пиковая нагрузка — это процесс окончания месяца. Период времени должен включать только пиковое время загрузки и исключить длительные периоды низкой нагрузки. Если в отчет AWR включены периоды низкой нагрузки, статистика производительности представляет среднее значение, а не фактические требования к производительности рабочей нагрузки.

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

• Сбор отчетов AWR во время пиковой нагрузки и аналогичных сценариев. Сведения о том, как определить соответствующую конфигурацию SKU виртуальной машины и хранилища, см. в статье изменение размера ресурсов Azure на основе отчета Oracle AWR. Если вы управляете несколькими рабочими нагрузками базы данных Oracle и рассматриваете возможность объединения нескольких рабочих нагрузок на одних виртуальных машинах, используйте помощника по миграции Oracle (OMAT). OMAT — это средство автоматической оценки размера, которое создает оценку инфраструктуры на основе отчетов AWR и предоставляет рекомендации по возможным конфигурациям виртуальной машины и хранилища.

Рекомендации по вычислению

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

• При необходимости используйте ограниченные ядра. Ограниченные ядра обеспечивают емкость памяти и способность обработки, как у виртуальной машины большего SKU, с мощностью виртуального процессора, характерной для виртуальной машины меньшего SKU. Ограниченные ядра предпочтительнее с точки зрения затрат на лицензирование Oracle, так как лицензирование Oracle основано на ядрах процессора. Дополнительные сведения о том, как работает лицензирование Oracle в Azure, см. в разделе "Лицензирование программного обеспечения Oracle в среде облачных вычислений". Дополнительные сведения об ограниченных ядрах см. в размерах виртуальных машин Azure.

• Используйте оптимизированные для памяти виртуальные машины для рабочих нагрузок Oracle. Оптимизированные для памяти виртуальные машины имеют больше памяти для виртуальных ЦП, чем виртуальные машины общего назначения. Эти виртуальные машины предпочтительнее для рабочих нагрузок Oracle, которые обычно являются интенсивными в памяти. Дополнительные сведения об оптимизированных под память виртуальных машинах см. в размеры оптимизированных под память виртуальных машин.

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

Рекомендации по хранению

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

• Если вы используете управляемые диски, обязательно используйте SSD Azure premium, SSD Azure premium версии 2 или хранилище дисков Azure Ценовой категории "Ультра" для рабочих нагрузок Oracle. Для рабочих рабочих нагрузок Oracle не рекомендуется использовать SSD Azure уровня "Стандартный" или Azure Standard HDD. Дополнительные сведения об ограничениях SSD Премиум v2 и хранилища дисков "Ультра" см. в управляемых дисках Azure .

• Задержка диска может быть проблемой в зависимости от характеристик рабочей нагрузки. Дополнительные сведения о задержке дисков см. в типах управляемых дисков Azure.

• Если вы используете SSD класса Premium, настройте кэширование узла для ReadOnly для всех дисков данных и ReadWrite для класса OSDisk. Кэширование дисков узла не поддерживается для дисков размером более 4095 ГБ. Чтобы создать тома, объём которых превышает параметр P50 или 4 ТБ, выделить несколько дисков Premium SSD для создания полосатых логических томов RAID-0. Используйте диспетчер томов, например Логический Диспетчер Томов Linux версии 2 (LVM2), или выделите несколько дисков SSD уровня "Премиум" для создания групп дисков Oracle для автоматического управления хранилищами (ASM), чтобы удовлетворить требуемую емкость или необходимую пропускную способность.

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

• При использовании управляемых дисков с нагрузкой, требующей интенсивной записи, рекомендуется использовать хранилище дисков Ультра для журналов повторения.

• Если требования к пропускной способности превышают максимальную пропускную способность одной виртуальной машины, рассмотрите возможность использования сетевого хранилища, например Azure NetApp Files, так как виртуальная машина ограничена пропускной способностью сети или исходящего трафика, а не пропускной способностью диска для такой конфигурации.

• При частом использовании временных файлов Oracle рекомендуется выбрать SKU виртуальной машины с временным диском и разместить временные файлы на этом диске. Эта конфигурация снижает нагрузку ввода-вывода на диски данных.

Дальнейшие действия

• планирование миграции Oracle в Azure
• рекомендации по производительности для Oracle на виртуальных машинах Azure