Проектирование приложений Oracle
Перенос приложений Oracle в облако — это сложный процесс. Необходимо понять, какие функции поддерживают каждую версию приложения, чтобы можно было избежать проблем во время миграции или даже избежать неудачной миграции. Организации не хотят просто поднимать и сдвигать приложения. Они также хотят модернизировать архитектуру и соответствовать функциональным и нефункциональным требованиям. Эти требования следует изучить вместе с ключевыми шаблонами проектирования облачных приложений, чтобы обеспечить достижение целей миграции.
Примерами популярных приложений Oracle являются Siebel, E-Business Suite, JD Edwards и PeopleSoft. Эти приложения имеют сильные зависимости между уровнем приложения и уровнем базы данных. Разделение двух уровней между различными поставщиками облачных служб приводит к задержкам, которые могут привести к плохому интерфейсу для клиентов. Прежде чем решить, как разместить два уровня, всегда следует выполнить правильную техническую оценку.
Для каждого приложения следует отметить рекомендации по проектированию, предоставляемые поставщиком приложений, и учесть характеристики служб Azure, которые вы используете для каждой разработки. Облако Azure предлагает множество функций и возможностей, которые могут привести к выполнению, надежному, безопасному и высокодоступным решениям.
Дополнительные рекомендации по архитектуре см. в статье "Архитектура для приложений Oracle" с базой данных в Azure Виртуальные машины.
Рекомендации
Используйте следующие рекомендации для планирования миграции приложений Oracle в облако.
Сеть и безопасность
- Рассмотрите возможность настройки единого входа с помощью идентификатора Microsoft Entra. Клиенты могут использовать единый вход для подключения к приложениям Oracle через интернет-браузер. Дополнительные сведения см. в разделе "Включение единого входа" для корпоративного приложения.
- Рекомендуется использовать частное подключение к облачной установке. Azure предоставляет возможности частного подключения, такие как подключения Azure ExpressRoute и VPN-подключения типа "сеть — сеть".
- Если клиент обращается к приложению из Интернета, рассмотрите шлюз приложений. Шлюз приложений Azure предоставляет две встроенные функции. Он работает как брандмауэр веб-приложения и имеет встроенную подсистему балансировки нагрузки уровня 7. Шлюз приложений поддерживает доступ только через порт 443 (HTTPS).
- Другим вариантом защиты сети является Брандмауэр Azure. Этот компонент защищает веб-службы от распространенных эксплойтов и уязвимостей. Он обеспечивает высокую доступность приложений Oracle и помогает соответствовать требованиям соответствия требованиям.
- Рекомендуется настроить группы безопасности сети на уровне подсети, чтобы обеспечить разрешение трафика только на определенных портах и IP-адресах.
- Если приложению требуется протокол Secure Shell (SSH) или доступ к протоколу удаленного рабочего стола (RDP), разверните узел Бастиона Azure в качестве сервера перехода, чтобы обеспечить дополнительную безопасность для глубокой подготовки системы безопасности.
Уровни веб-приложений и веб-приложений
- Развертывание приложения на виртуальных машинах (виртуальных машинах). Группируйте эти виртуальные машины в гибком масштабируемом наборе виртуальных машин, чтобы повысить общую доступность.
- Если вам нужно приложение для автомасштабирования, рассмотрите возможность использования Azure Масштабируемые наборы виртуальных машин.
- Поместите виртуальные машины в одну зону доступности, чтобы их физически приблизить. Однако помните, что по мере роста объема ресурсов Azure одна зона доступности может охватывать несколько физических центров обработки данных. Расстояние между физическими центрами обработки данных может привести к задержке в сети, которая влияет на приложение. Чтобы получить виртуальные машины как можно ближе и достичь минимальной возможной задержки, разверните их в группе размещения близкого взаимодействия.
Уровень базы данных
- Рассмотрите возможность развертывания уровня базы данных в качестве первичного сервера, реплицированного на дополнительный сервер с помощью Oracle Data Guard.
- Если вы используете две зоны для развертывания основных и вторичных серверов в одном регионе, рассмотрите возможность использования конфигурации синхронной репликации Data Guard после проверки задержки сети между зонами в регионе.
- При развертывании основных и вторичных серверов в двух регионах рекомендуется использовать конфигурацию асинхронной репликации Data Guard.
- Если требуется стратегия репликации с нулевой потерей данных, рассмотрите возможность использования асинхронной конфигурации репликации.
- Помимо Data Guard, другие варианты интеграции включают Striim, Qlik, GoldenGate или Active Data Guard.
Резервное копирование и хранение данных
- Рекомендуется использовать Azure Backup для резервного копирования виртуальных машин приложений и баз данных.
- Рассмотрите возможность размещения резервных копий в другом регионе от основного региона, чтобы обеспечить дополнительную защиту от региональных сбоев.
- Попробуйте создать резервную копию базы данных с помощью компонентов хранилища, имеющих встроенные возможности репликации.
Аварийное восстановление
- Создайте надежную архитектуру, как в следующих примерах:
- Рассмотрите возможность использования встроенных решений аварийного восстановления Azure, таких как Azure Site Recovery.