Общие сведения о цикле миграции в Azure

Обновлено: Февраль 2015 г.

Жизненный цикл миграции — это стандартная методология, которая обеспечивает пошаговые инструкции для миграции приложений и переноса данных в Microsoft Azure. Основные шаги миграции включают анализ, миграцию приложений, перенос данных, тестирование и оптимизацию, работу и управление, как показано на приведенной далее диаграмме.

Жизненный цикл миграции Windows Azure

В этом разделе подробно объясняется каждый этап и приводятся ссылки на дополнительную информацию.

Azure также поддерживает Oracle на виртуальных машинах Azure. Дополнительные сведения см. в разделе Образы виртуальных машин Oracle для Azure.

Авторы: Кун Ченг (Kun Cheng), Селцин Туркарслан (Selcin Turkarslan), Норберто Гарсиа (Norberto Garcia)
Рецензенты: Паоло Сальватори (Paolo Salvatori), Стив Ховард (Steve Howard), Стюарт Озер (Stuart Ozer)

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

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

    • Ориентировано ли решение по развертыванию Azure на новых клиентов и пользователей?

    • Потребуется ли многопользовательский режим для обеспечения поддержки нескольких клиентов?

    • Отвечает ли приложение нормативным правилам при размещении данных в дата-центре корпорации Майкрософт, а не на клиентских сайтах?

    • Какие приложения больше подходят для облака с точки зрения архитектуры и стратегии?

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

    Ответы на эти вопросы влияют на разработку приложения и его поведение на платформе Azure.

  • Определение функциональных отличий. Можно ли запустить существующее приложение в Azure без каких-либо изменений? Например, база данных SQL Azure (база данных SQL) не поддерживает все функции, которые поддерживаются локальной системой SQL Server. Если необходимо переместить локальное приложение, использующее среду CLR, в базу данных SQL, потребуется изменить приложение и перенести логику среды CLR из SQL Server на уровень приложений или переписать логику среды CLR с помощью инструкций Transact-SQL, которые поддерживаются базой данных SQL. Обратите внимание, что база данных SQL в настоящее время не поддерживает SQL CLR.

    Начиная с выпуска Azure 2012, в Azure были добавлены новые возможности виртуальных машин. Виртуальные машины Azure позволяют выполнить миграцию существующих приложений SQL Server, построенных на платформе Windows Server, на платформу Azure с минимальными изменениями кода либо без изменений. Используя SQL Server на виртуальной машине Azure, администраторы и разработчики по-прежнему могут использовать те же доступные локально средства разработки и администрирования. Производительность реляционной базы данных на виртуальной машине Azure зависит от многих факторов, включая размер виртуальной машины, количество и конфигурации дисков, сети, конфигурации программного обеспечения базы данных и рабочей нагрузки приложения. Рекомендуется, чтобы разработчики провели тестирование своего приложения на виртуальных машинах различного размера и конфигурации хранения и выбрали наиболее подходящий вариант. Дополнительные сведения см. в Migrating with SQL Server on Virtual Machines.

  • Подготовка плана по производительности и масштабируемости. Многие прежние версии приложений были разработаны для тесной интеграции между логикой приложений и компонентами доступа к данным. Для прежних версий приложений имеет смысл разъединить компоненты приложения для лучшей работы и увеличения масштабируемости в Azure. Если приложение отправляет слишком много запросов, изучите возможность использования службы кэширования Azure или реализуйте собственный механизм кэширования для пакетного доступа к данным и уменьшения количества обращений приложения к данным. Если приложение, для которого нужно выполнить перенос, работает с большими базами данных или большим объемом транзакций, для перенесения в базу данных SQL, скорее всего, потребуется изменение модели базы данных. Это вызвано тем, что один экземпляр базы данных SQL может управлять ограниченным числом транзакций в секунду и имеет ограниченный размер базы данных. При работе с большими базами данных или большим объемом транзакций изучите возможность реализации горизонтально масштабируемой архитектуры с помощью нескольких баз данных в базе данных SQL или начните использовать методы горизонтального масштабирования, вместо дорогого вертикального масштабирования локальных систем. В качестве средства повышения производительности для таблиц со значительными объемами транзакций следует также рассматривать реализацию In-Memory OLTP или отложенной устойчивости. Дополнительные сведения об In-Memory OLTP см. в разделе In-Memory OLTP (оптимизация памяти). Дополнительные сведения об отложенной устойчивости см. в разделе Управление устойчивостью транзакций.

    Дополнительные сведения о вопросах производительности при использовании SQL Server в виртуальной машине см. в разделе Рекомендации по оптимизации производительности SQL Server в виртуальных машинах Azure и в техническом документе Указания по оптимизации производительности SQL Server в виртуальных машинах Azure.

    Для базы данных SQL Azure выпущена ограниченная расширенная предварительная версия базы данных SQL. Резервируя фиксированный объем ресурсов для базы данных SQL и ее вторичных реплик, расширенная служба обеспечивает более предсказуемую производительность для облачных приложений в сравнении с существующими выпусками базы данных SQL Web и Business. Дополнительные сведения об учетных записях расширенной базы данных SQL см. в разделах Управление расширенной базой данных и Руководство по расширенной предварительной версии базы данных SQL.

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

После этого этапа рекомендуется построить пилотный проект, поскольку он даст четкое понимание служб и средств платформы Azure.

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

Вообще говоря, большинство существующих локальных приложений можно запустить в облачных службах Azure с минимальными изменениями или без изменений, но это может создать проблемы производительности, масштабируемости и безопасности. Для оптимизации производительности и обеспечения масштабируемости в будущем рекомендуется рассмотреть вариант изменения приложения с помощью нескольких ролей перед миграцией в облачные службы Azure. Дополнительные сведения см. в Migrating Applications to Azure. Рекомендуется сначала переместить в облачные службы Azure приложение, а затем данные. Из соображений безопасности, производительности или по другим причинам некоторым частям приложения может потребоваться локальное размещение. Для этого требуется гибридное решение. Дополнительные сведения см. в разделе Построение гибридных решений с помощью Azure.

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

  • На существующей виртуальной машине уже может работать какое-либо приложение. Можно перенести эту виртуальную машину в Azure. В этом случае приложение, его параметры конфигурации и данные уже находятся на этой виртуальной машине. Однако может потребоваться загрузка большого VHD-файла в Azure. Также на виртуальной машине могут быть драйверы и модули аппаратной части, недоступные в Azure.

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

Дополнительные сведения о миграции существующих баз данных SQL Server в SQL Server виртуальной машины Azure см. в разделе Migrating with SQL Server on Virtual Machines.

Если используются облачные службы Azure, переместите реляционные данные из локальной системы SQL Server в базу данных SQL, а неструктурированные данные — в хранилище Azure, такое как хранилище больших двоичных объектов, таблиц или дисков Azure.

При использовании SQL Server на виртуальной машине Azure воспользуйтесь одним из двух подходов к миграции.

  • На существующей виртуальной машине уже могут быть данные. Можно передать эту виртуальную машину в виде VHD-файла в Azure.

  • Виртуальную машину можно построить в Azure. После этого необходимо загрузить данные в VHD-файле на Azure. После этого нужно присоединить загруженный VHD-файл или пустой диск к виртуальной машине в качестве диска данных. Диски данных можно использовать для хранения журналов и файлов данных SQL Server. Кроме того, можно использовать средства и методы, описанные в разделе Migrating with SQL Server on Virtual Machines, для выполнения миграции существующих баз данных SQL Server на SQL Server в виртуальной машине Azure.

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

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

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

См. также

Показ: