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

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

  • Статья

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

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

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

Вопросы планирования ресурсов

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

Примечание.

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

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

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

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

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

Рекомендации по работе с хранилищем

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

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

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

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

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

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

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

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

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