Перенос рабочих нагрузок Oracle на виртуальные машины Azure
В этой статье объясняется, как перенести рабочую нагрузку Oracle из локальной среды в azure Виртуальные машины (виртуальные машины). Он использует целевую зону для Oracle на виртуальных машинах Azure, предоставляя рекомендации по проектированию и рекомендации. Рекомендуемая стратегия включает структурированный подход к обнаружению, проектированию и развертыванию, а затем миграции данных и окончательной переключению.
Обнаружение
Миграция начинается с комплексной оценки портфеля продуктов Oracle. Эта оценка включает оценку версий базы данных Oracle, текущих и целевых операционных систем, а также приложений и их зависимостей.
При планировании миграции приложений Oracle, таких как Oracle (EBS, Siebel, PeopleSoft, JDE или других сторонних партнеров, таких как SAP или пользовательские приложения), рассмотрите приложения в рамках стратегии миграции.
Существующая среда базы данных Oracle может работать на автономных серверах, кластерах приложений Oracle Real (RAC) или решениях, отличных от Microsoft RAC.
Примечание.
Обратите внимание, что на виртуальной машине Azure не поддерживается кластеризация реальных приложений (RAC). Если это относится к вашей среде, убедитесь, что вы предоставляете отчеты RAC или отчеты PDB/CDB (в зависимости от архитектуры) со всех узлов RAC. Эти отчеты должны создаваться из одного и того же интервала времени, чтобы обеспечить согласованность. Наиболее точные рекомендации по размеру получаются путем создания этих отчетов во время пиковых периодов использования.
Для приложений определение размера инфраструктуры просто с помощью возможностей обнаружения службы "Миграция Azure".
На этапе обнаружения важно проверить все зависимости приложений. Вы должны решить, допустимо ли время простоя приложения во время миграции, так как это влияет на выбор средств миграции. На основе этого решения можно выбрать один из способов миграции в сети или в автономном режиме.
Если вы решили выполнить миграцию по сети, убедитесь, что необходимые порты брандмауэра открыты для упрощения процесса миграции.
Планирование сети является критическим шагом в течение периода миграции. Обязательно протестируйте пропускную способность, необходимую для передачи данных в Azure тщательно на основе размера набора данных.
Проект
Миграции приложений можно легко включить с помощью службы "Миграция Azure". Миграция Azure lift-and-shift приложения в Azure IaaS на основе первоначального обнаружения.
Если вы планируете перенести сторонние приложения Oracle, просмотрите требования к архитектуре перед выбором миграции на основе миграции Azure.
Планирование емкости для базы данных Oracle всегда проводится с помощью отчетов AWR, создаваемых в течение одного часа пиковых периодов. Помимо этого, важно настроить макет хранилища. Размер данных — это размер, на который необходимо сосредоточиться во время миграции, и принять решение о лучшем хранении. Чтобы узнать размер данных, можно использовать скрипт dbspace.
После создания отчетов AWR запустите средство поддержки миграции Azure Oracle (OMAT). Средство OMAT рекомендует правильный размер виртуальной машины и параметры хранилища, необходимые для базы данных Oracle в Azure IaaS. На следующем шаге необходимо установить архитектуру, тщательно оценивая ваши требования. Настоятельно рекомендуется разработать архитектуру с высокойнадежностью и устойчивостью при возникновении аварий или сбоев, как определено параметрами целевой точки восстановления (RPO) и целевой цели времени восстановления (RTO).
Если вам нужна поддержка создания архитектуры, просмотрите эталонные архитектуры Oracle. Он предлагает рекомендации по архитектуре для выбора оптимальной архитектуры решения на основе требований RPO и RTO. Подход RPO и RTO применим для разделения инфраструктуры RAC на архитектуру высокого уровня доступности и аварийного восстановления с помощью Oracle Data Guard.
Развертывание
На основе планирования емкости и архитектуры можно использовать Ansible для описания инфраструктуры и архитектуры как инфраструктуры как кода (IaC) и запуска целевой зоны с помощью Terraform или Bicep. Используйте действия GitHub, доступные для автоматизации развертывания.
Типы для миграции данных
Тип миграции данных зависит от решений, принятых на этапе обнаружения. Вы можете выбрать средства и методы, такие как Data Box, RMAN, Data Pump, GoldenGate, Striim, SharePlex и Data Guard на основе ваших предпочтений и требований.
Дополнительные рекомендации см. в статье "Планирование миграции Oracle", чтобы просмотреть характеристики миграции по сети и в автономном режиме.
Примечание.
Автономная миграция обычно занимает больше времени, чем миграция через Интернет. В результате такие инструменты, как Data Pump, не рекомендуется использовать для сценариев с большими размерами данных и строгими требованиями к низкой простоям.
Подход к миграции данных
После настройки инфраструктуры Oracle в Azure база данных Oracle устанавливается и переносятся связанные приложения, следующим шагом является передача данных из локальной базы данных Oracle в новую базу данных Oracle в Azure. Чтобы упростить эту задачу, рассмотрите возможность использования следующих средств Oracle:
Azure улучшает средства Oracle с правильным сетевым подключением, пропускной способностью и командами, которые используются следующими возможностями Azure для миграции данных.
- VPN-подключение
- Экспресс-маршрут. Надежность ExpressRoute является ключом. Ознакомьтесь с рекомендациями по устойчивости шлюза и каналов.
- AzCopy
- Data Box
Средства Oracle для миграции данных
На следующей схеме представлено пиктографическое представление общего портфеля миграции.
Для развертывания правильной архитектуры решения для переноса данных требуется одна из средств Oracle, а также инфраструктура Azure. Ознакомьтесь со следующими эталонными сценариями решения:
Сценарий-1. Использование резервного копирования и восстановления RMAN с функциями Azure, настройка восстановления на основе RMAN. Главное — сеть между локальной средой и Azure.
Сценарий-2. Подход к резервному копированию RMAN
Сценарий-3. Кроме того, настройка может быть изменена различными способами, как показано в следующем сценарии.
Сценарий-4. Data Pump и AzCopy — простой и прямой подход с помощью резервного копирования и восстановления насоса данных с помощью возможностей Azure.
Сценарий-5. Data Box — уникальный сценарий, в котором данные перемещаются между расположениями с помощью устройства хранения и физической отправки.
Прямая миграция
Теперь ваши данные переносятся, а серверы баз данных Oracle и приложения работают и работают. Выполните следующие действия, чтобы перенести бизнес-операции, выполняемые локально, на новую рабочую нагрузку Oracle и приложения в Azure IaaS.
- Запланируйте период обслуживания, чтобы свести к минимуму нарушения работы пользователей.
- Остановите действие базы данных в исходной базе данных Oracle.
- Выполните окончательную синхронизацию данных, чтобы убедиться, что все изменения записываются.
- Обновите конфигурации DNS, чтобы указать новую виртуальную машину Azure.
- Запустите базу данных Oracle на виртуальной машине Azure и проверьте подключение.
- Внимательно отслеживайте систему для любых проблем во время процесса переключение.
Задачи, выполняемые после переноса
После перехода убедитесь, что все бизнес-приложения работают должным образом, чтобы обеспечить бизнес-операции в тандеме с локальной средой.
- Выполните проверки, чтобы проверить согласованность данных и функциональные возможности приложений.
- Обновите документацию, включая сетевые схемы, сведения о конфигурации и планы аварийного восстановления.
- Реализуйте текущие процессы мониторинга и обслуживания для виртуальной машины Azure, в котором размещена база данных Oracle.
На протяжении всего процесса миграции важно эффективно взаимодействовать с заинтересованными лицами, включая владельцев приложений, ИТ-операционных групп и конечных пользователей, для управления ожиданиями и минимизации нарушений. Кроме того, рассмотрите возможность взаимодействия с опытными специалистами или консультационными службами, специализирующимися на миграции Oracle в Azure, чтобы обеспечить плавный и успешный переход.