Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Центр миграции Azure предоставляет предварительные рекомендации по планированию рабочих нагрузок и реализации их миграции в Azure. В нем рассматриваются миграции из локальных сред и облачных платформ, таких как Amazon Web Services (AWS) и Google Cloud Platform (GCP).
Это важно
Это содержимое охватывает миграции с одной рабочей нагрузкой. Она не охватывает полные миграции центра обработки данных, перемещения регионов или гибридные рабочие нагрузки, которые выполняются одновременно в нескольких облаках.
Миграция в Azure включает сети, идентификацию, базы данных, вычислительные ресурсы, хранилище и пользовательские интеграции, созданные вашей командой за многие годы. В нескольких статьях и руководствах приведены рекомендации по этим компонентам.
Эта статья поможет определить, какие рекомендации применяются к вашей ситуации. В зависимости от того, где в настоящее время работает ваша рабочая нагрузка, вы получите рекомендацию по соответствующему руководству по миграции. Он также объясняет общую терминологию миграции и стратегии.
Кому следует читать эту статью
Эта статья помогает архитекторам рабочих нагрузок и инженерам приступить к миграции рабочих нагрузок в Azure из AWS, GCP или локального центра обработки данных. Используйте это руководство, чтобы решить, следует ли повторно разместить, реплатформировать или рефакторить.
Это руководство предназначено для:
Архитекторы рабочей нагрузки , которые перепроектировали аспекты архитектуры и проверили общую структуру в соответствии с бизнес-требованиями в Azure. Архитекторы устраняют пробелы, учитывая конкретные характеристики рабочей нагрузки и бизнес-ограничения.
Участники группы, работающей с нагрузкой, которые должны понять, как их обязанности изменяются во время и после миграции. Например, администраторы баз данных, которые управляют скриптами и выполняют ежедневные резервные копии в Amazon Relational Database Service, должны адаптироваться к выполнению тех же задач в Базе данных SQL Azure.
В этой статье описывается конкретное руководство по миграции для вашего сценария, поэтому вы можете начать планирование немедленно.
Стратегии миграции
Стратегии миграции зависят от риска, усилий и вознаграждения. Выберите стратегию на основе сложности рабочей нагрузки, временной шкалы и требуемого уровня изменений.
Повторное размещение (лифт и смена): Переместите рабочую нагрузку в инфраструктуру Azure без изменений кода. Такой подход является быстрым и низким риском. Она хорошо подходит для простых рабочих нагрузок, где скорость наиболее важна. Например, вы можете перенести веб-приложение из виртуальной машины Windows Server на виртуальную машину Azure. Вы получаете преимущества инфраструктуры Azure, не изменяя архитектуру рабочей нагрузки или код. Вы изменяете место, где выполняется веб-приложение, а не как оно выполняется.
Перенос платформы (миграция, корректировка и трансформация): Внесите минимальные изменения, чтобы воспользоваться преимуществами сервисов платформы Azure. Например, перенос базы данных SQL Server в Управляемый экземпляр SQL Azure для получения операционных преимуществ без перезаписи приложения.
Рефакторинг: Реструктурировать код для повышения производительности, масштабируемости или обслуживания без изменения внешнего поведения рабочей нагрузки. Например, рефакторинг монолитного приложения .NET с переходом на Службу приложений Azure, заменяя обработку пути к файлам Windows, обработку состояния сеанса и ведение логов на локальных дисках. Рефакторинг требует дополнительных усилий, но снижает долгосрочные операционные издержки.
Перепроектировать: Переработайте рабочую нагрузку, чтобы в полной мере воспользоваться всеми возможностями Azure. Например, измените веб-приложение для использования Функций Azure и Azure Cosmos DB вместо виртуальных машин и SQL Server. Этот подход требует значительных изменений кода, но обеспечивает наибольшее улучшение масштабируемости, производительности и затрат.
Вывести из эксплуатации: Выводите из эксплуатации рабочие нагрузки, которые вам больше не нужны. Используйте эту стратегию для устаревших или избыточных рабочих нагрузок или при замене функций программного обеспечения как службы (SaaS). Например, оставите локальный файловый сервер после переноса данных в файлы Azure и обучите пользователей получать доступ к файлам в новом расположении.
Заменить: Используйте готовую облачную службу вместо миграции существующей реализации. Рассмотрим этот вариант, если решение SaaS соответствует вашим требованиям лучше, чем перемещение рабочей нагрузки в Azure.
Перестроить: Создайте новую реализацию, когда стоимость других стратегий миграции перевешивает преимущества. Модернизация хорошо подходит для устаревших рабочих нагрузок, которым требуются фундаментальные изменения для эффективного выполнения в облаке. Например, перестройте настраиваемую систему управления отношениями клиентов (CRM) с помощью Dynamics 365, если существующую базу кода сложно поддерживать или не хорошо соответствовать службам Azure.
Сохранить: Сохраняйте рабочую нагрузку в локальной среде, если требования к соответствию, задержки или технические ограничения делают миграцию непрактичной. Например, сохраните устаревшую систему на мейнфрейме, которую невозможно легко переразместить или рефакторировать, или для которой отсутствует четкий путь миграции на Azure.
Большинство миграций рабочих нагрузок в Центре миграции Azure используют подходы повторного размещения или переплатформирования. Эти стратегии сводят к минимуму риск, сохраняя рабочие нагрузки функционально идентичными. Функциональные возможности должны соответствовать тем же ключевым показателям производительности (KPI), соглашениям об уровне обслуживания (SLA) и целям уровня обслуживания в Azure, которые она выполнила на исходной платформе. Сначала выполните миграцию, а затем оптимизируйте и модернизируйте.
Дополнительные сведения см. в разделе "Выбор стратегии миграции в облако".
Процесс миграции
Каждая миграция состоит из пяти этапов. Некоторые этапы пересекаются, и вы можете вернуться к предыдущим этапам по мере того как вы узнаете больше о требованиях рабочей нагрузки, но последовательность помогает отслеживать прогресс.
| Phase | Tasks | Результат |
|---|---|---|
| План | Оцените текущую рабочую нагрузку, определите зависимости, сопоставите исходные службы с эквивалентами Azure и определите критерии успешности. | Четкая документация по объемам миграции, необходимым изменениям и критериям завершения. |
| Подготовка | Настройте окружение Azure, включая посадочные зоны, сети, идентификацию и управление. Проектирование архитектуры целевого состояния. | Настроена среда Azure, готовая к получению рабочей нагрузки, при этом все архитектурные решения приняты до начала миграции. |
| выполнить | Перенос компонентов инфраструктуры, данных и приложений. Выполните итеративное тестирование и переключение. | Компоненты рабочей нагрузки, перенесенные в Azure. Рабочий трафик перенаправляется в Azure после успешной проверки рабочей нагрузки. |
| Evaluate | Убедитесь, что перенесенная рабочая нагрузка соответствует функциональным, производительности, безопасности и затратам в соответствии с базовыми показателями, заданными на этапе 1. | Подтверждение успешной миграции и правильность выполнения рабочей нагрузки в Azure. |
| Вывод из эксплуатации | Выведите из эксплуатации исходную среду. Удалите ресурсы, отмените подписки и завершите работу старой платформы. | Исходная рабочая нагрузка выключена. Azure теперь выполняет рабочую нагрузку исключительно. |
Руководство по миграции
В этом разделе перечислены типы рекомендаций по миграции, предоставляемых Azure. Каждое руководство помогает планировать миграцию и управлять ими.
Программа внедрения облачных технологий для Azure
Cloud Adoption Framework для Azure охватывает планирование на уровне организации. В нем описывается структура миграции, действия, которые необходимо выполнить, и что необходимо настроить перед перемещением рабочих нагрузок.
Если вы не знакомы с Azure, запустите здесь. Cloud Adoption Framework поможет вам подготовить организацию. В нем описывается настройка регистрации Azure, конфигурация зоны высадки платформы и приоритизация плана миграции. Выполните эти базовые действия перед перемещением рабочих нагрузок.
Центр архитектуры Azure
Центр архитектуры Azure предоставляет идеи решения, архитектуры, шаблоны проектирования и руководства по архитектуре для создания рабочих нагрузок в Azure.
Большинство миграций связано с переносом на другую платформу. Вы перемещаете инфраструктуру и уровень управления из исходного облака в Azure. Не все исходные компоненты имеют прямой эквивалент Azure, поэтому может потребоваться перепроектировать части архитектуры. Центр архитектуры Azure предоставляет общие сведения о вариантах технологий и помогает найти ближайшее соответствие.
Платформа Azure с продуманной архитектурой
Платформа Azure Well-Architected Framework предоставляет принципы создания надежных, безопасных, экономичных и эффективных облачных систем. В ней содержатся общие руководства по архитектуре и руководства по конкретной службе для служб Azure. В этих руководствах описаны основные рекомендации по принятию архитектурных решений для рабочей нагрузки. Используйте их для оценки архитектуры после миграции и поиска областей для улучшения.
Начните с исходной платформы
Чтобы приступить к работе, сравните возможности вашей нагрузки приложений и её служб с ближайшими эквивалентами в Azure. В следующих статьях приведены примеры сценариев и руководства по миграции уровня обслуживания для иллюстрации сравнений.
Средства миграции
Используйте следующие средства для поддержки задач миграции независимо от исходной платформы. Они помогают измерять успех миграции в отношении бизнес-целей.
| Инструмент | Цель |
|---|---|
| Перенос и модернизация Azure | Обнаружение и оценка ресурсов миграции, включая инфраструктуру, приложения и компоненты данных. |
| Well-Architected проверка оценки исходной платформы | Просмотрите и измеряйте бизнес-цели вашей архитектуры на исходной платформе. Эта оценка от исходного поставщика облачных служб помогает задать базовые показатели для ваших ожиданий в Azure. |
| Оценка результата проверки Well-Architected Azure | Оцените решения по архитектуре, чтобы определить регрессию из исходного базового плана и изучить возможности оптимизации. |
Следующий шаг
Cloud Adoption Framework охватывает последовательность миграции, планирование волн, сопоставление зависимостей и выравнивание заинтересованных лиц. Сведения о планировании на уровне организации или помощи в выборе стратегии миграции см. в разделе "Планирование миграции".