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


Перенос рабочих нагрузок Oracle в Azure

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

Сценарии миграции Oracle

При переносе рабочих нагрузок Oracle необходимо перенести базы данных и приложения. В этой статье рассматривается подход «поднять-и-переместить» для переноса приложений и баз данных. Подход «lift-and-shift» включает развертывание приложений Oracle на виртуальных машинах Azure. Для миграции базы данных доступны несколько вариантов. В этой статье приведены рекомендации, применимые к Oracle Database@Azure.

  • Программы на виртуальных машинах: запуск корпоративных приложений Oracle, таких как Siebel, PeopleSoft, JD Edwards, E-Business Suite, или настроенных приложений WebLogic Server на инфраструктуре Azure.

  • базы данных Oracle Standard Edition или Enterprise Edition на виртуальных машинах: В этом сценарии вы развертываете базу данных Oracle на виртуальной машине. Существует несколько вариантов, от самостоятельно управляемых баз данных до управляемых баз данных. Если вы предпочитаете решение для управляемой базы данных, просмотрите Tessell.

  • Oracle Database@Azure: Oracle Database@Azure — это служба базы данных Oracle, которая работает в Oracle Cloud Infrastructure (OCI) и находится в центрах обработки данных Майкрософт.

Заметка

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

Процесс миграции Oracle

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

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

Просмотрите ресурсы миграции, чтобы определить процесс миграции Oracle в Azure. Кроме того, вы можете сделать следующее:

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

Заметка

Если вы размещаете рабочую нагрузку в Oracle Database@Azure и хотите увеличить квоту, обратитесь к контакту Oracle.

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

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

  • Определите емкость данных: Определите объем данных для переноса и оценки текущей доступной емкости сетевого подключения из локальных сред в Azure. Используйте эти сведения, чтобы определить, можно ли скопировать данные непосредственно из локальных сред в Azure. Для начальной загрузки данных может потребоваться физическое устройство передачи данных, например Azure Data Box .

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

Это также относится к вашему приложению. Если вы не можете принять нарушение в повседневных операциях, необходимо выполнить миграцию через Интернет.

  • Определите средства для переноса рабочей нагрузки в Oracle на виртуальных машинах Azure: Два основных пути миграции находятся в автономном режиме и в сети.
Автономная миграция Миграция через Интернет
Однократная прямая копия базы данных. Начальная копия базы данных, за которой следует запись измененных данных во время миграции.
Требует, чтобы затронутое приложение было в автономном режиме во время миграции. Приложение может оставаться в сети во время миграции.
используемые средства : Data Box, DataPump, Oracle Recovery Manager (RMAN) используемые средства : DataGuard, Oracle Recovery Manager (RMAN), GoldenGate

Заметка

Если вы решите выполнить миграцию по сети, убедитесь, что правила брандмауэра настроены для разрешения передачи данных.

Действия, связанные с миграцией Oracle

В следующем разделе подробно описан процесс миграции. Шаги не обязательно являются последовательными. Некоторые действия можно выполнять параллельно.

  • Оценить версии исходной и целевой системы: оценить, являются ли локальные версии операционной системы, версии приложений и версии базы данных одинаковыми локальными и в Azure.

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

    • Если локальная база данных выполняется в крупной ОС, например Oracle Solaris, IBM Advanced Interactive eXecutive или Hewlett Packard Unix, процесс миграции базы данных включает преобразование endian. поддержка Azure только небольшие операционные системы. Это ограничение сокращает количество доступных средств для миграции. В частности, вы не можете использовать Oracle Data Guard или любой другой метод копирования файлов. Методы миграции, совместимые с преобразованием Endian, включают экспорт Oracle Data Pump или импорт Oracle Data Pump, кроссплатформенные транспортируемые пространства таблиц Oracle (XTTS), или служебные программы репликации данных, такие как Oracle GoldenGate, Quest SharePlex и Striim.

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

  • Оценить требования к доступности рабочей нагрузки во время миграции: Если необходимо свести к минимуму время простоя рабочей нагрузки, методы миграции, такие как Data Pump Export или Data Pump Import, могут не подойти для вашей рабочей нагрузки. В этом случае выполните этот четырехэтапный процесс:

    • Используйте RMAN для резервного копирования и восстановления всей базы данных в Azure. При необходимости выполните преобразование endian через XTTS. Результатом является база данных, которая является копией локальной базы данных-источника на определенный момент времени. Дополнительные сведения см. в разделе "Транспортировка данных на разных платформах".

    • Если оба источника используют формат с младшим байтом впереди, используйте Oracle Data Guard для синхронизации недавно восстановленной базы данных в Azure с исходной базой данных. Невозможно использовать Data Guard, если миграция включает преобразование big-endian в little-endian. Вместо этого используйте программу репликации данных на основе SQL, например Oracle GoldenGate, Quest SharePlex или Striim, чтобы синхронизировать только что восстановленную базу данных в Azure с исходной базой данных.

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

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

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

    • Для Oracle Data Guard требуется выпуск Enterprise Базы данных Oracle.

    • Oracle GoldenGate требует лицензий Oracle GoldenGate.

    Дополнительные сведения о лицензировании Oracle в Azure см. в статье "Лицензирование Oracle" в облачной среде вычислений.

Руководство по миграции Oracle Database@Azure

  • Убедитесь, что решение Oracle Database@Azure доступно в регионе, где вы хотите развернуть решение. Дополнительные сведения см. в разделе "Доступные регионы".

  • Рекомендуется использовать миграцию Oracle Zero Простоя для процесса миграции. Оцените стратегии миграции, чтобы определить наиболее подходящий подход для конкретных требований к миграции. Дополнительные сведения см. в миграции с нулевым простоем (ZDM). ZDM предоставляет возможность выбирать сценарии логической или физической миграции. Для получения дополнительной информации см. миграцию ZDM.

Заметка

Если выбрать автономную службу баз данных (ADB-S), помните, что поддерживаются только сценарии логической миграции.

Другие рекомендации

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

Справочник по длительности миграции на основе ExpressRoute

Следующая таблица служит только базовым показателем. Он не учитывает другие рабочие нагрузки, которые выполняются через то же подключение Azure ExpressRoute.

VMware может потребовать больше пропускной способности, чем указано. Оцените потребности пропускной способности на этапе PoC. Если вам нужна поддержка, обратитесь к локальному контакту.

Размер данных Пропускная способность 1 Гбит/с Пропускная способность 10 Гбит/с
1 ТБ 3 часа 15 минут
10 ТБ 1 день 3 часа
35 ТБ 4 дня 9 часов
80 ТБ 8 дней 20 часов
100 ТБ 11 дней 1 день
200 ТБ 21 дней 2 дня
500 ТБ 53 дня 5 дней

Если вы планируете использовать ExpressRoute для миграции, убедитесь, что его надежность соответствует вашим требованиям.

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