MSDN Library

Планирование миграции на Azure

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

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

Авторы: Стив Ховард (Steve Howard)
Рецензенты: Джеймс Подгорски (James Podgorski), Паоло Сальватори (Paolo Salvatori), Селцин Туркарслан (Selcin Turkarslan), Стюарт Озер (Stuart Ozer)

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

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

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

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

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

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

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

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

Наряду с преимуществами платформы, ориентированной на использование служб, Azure может размещать виртуальные машины. Эти виртуальные машины могут работать под управлением любой операционной системой, поддерживаемой платформой Azure, и приложения могут выполняться в них так же, как они выполняются в локальных компьютерах. Список поддерживаемых операционных систем см. в разделе Общие сведения о виртуальных машинах Azure. Эти виртуальные машины могут быть также частью архитектуры более крупного приложения, которое может включать экземпляры веб-ролей и рабочих ролей, а также другие компоненты Azure. Виртуальные машины предоставляют способ переноса некоторых служб или частей приложений, которые в ином случае не могли бы так несложно переноситься в Azure. Дополнительные сведения см. в Migration with Azure Virtual Machines.

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

Далее приводятся некоторые ключевые элементы планирования.

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

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

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

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

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

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

    • Использование реляционного хранилища. Проверьте данные, хранящиеся в реляционных базах данных. В реляционном хранилище должны находиться транзакционные и реляционные по своей природе данные или данные, для которых требуется истинно транзакционная обработка. Для хранения таких типов данных можно использовать базу данных SQL Azure (базу данных SQL) или SQL Server, выполняющийся в виртуальной машине. Другие типы данных можно хранить в таблицах Azure, в хранилище больших двоичных объектов Azure или на дисках Azure. Рекомендуется определить тип хранилища, необходимого для каждой части данных.

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

      • Размер базы данных. Базы данных SQL Azure в настоящее время ограничены объемом в 5 ГБ для баз данных выпуска Web Edition, а для баз данных Business Edition существует ограничение в 150 ГБ. Чтобы расширить емкость баз данных, используйте метод горизонтального масштабирования. Дополнительные сведения о методах горизонтального масштабирования Azure см. в разделе Горизонтальное масштабирование баз данных SQL Windows Azure. Наиболее актуальные сведения о доступных выпусках и размерах баз данных см. в разделе Учетные записи и выставление счетов в базе данных SQL Azure.

      • Число баз данных. По умолчанию база данных SQL поддерживает до шести серверов на одну подписку и 150 баз данных на каждом сервере баз данных SQL, включая базу данных master. Возможно расширение этого предела. Для получения дополнительных сведений свяжитесь с представителем службы поддержки пользователей на пользовательском портале Microsoft Online Services.

      • Межбазовые запросы. В настоящий момент база данных SQL не поддерживает межбазовые соединения или другие межбазовые запросы к базе данных. Если имеются объединения или соединения, которые требуют данных из нескольких баз данных в базе данных SQL, эту логику необходимо выполнить на уровне приложений вашего приложения.

      • Объекты среды CLR. База данных SQL в настоящее время не поддерживает хранимые процедуры CLR, агрегаты, триггеры или функции. Необходимо перенести хранимые процедуры, триггеры или функции в Transact-SQL для их выполнения в базе данных SQL. Сложная логика или такие операции, как статистическая обработка, которые не выполняются в Transact-SQL на уровне базы данных, должны быть перенесены на уровень приложений. Для этого можно использовать рабочую роль.

      • Типы данных. База данных SQL не поддерживает некоторые типы данных системы SQL Server. Наиболее актуальные сведения см. в статье Data Types (SQL Database) в библиотеке SQL MSDN.

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

      • Полнотекстовый поиск. База данных SQL Azure в настоящий момент не поддерживает полнотекстовый поиск. Если приложение выполняет полнотекстовые запросы символьных данных в таблицах SQL Server, может понадобиться рассмотреть миграцию базы данных на SQL Server в виртуальной машине Azure. Дополнительные сведения о SQL Server на виртуальной машине Azure см. в разделе Migrating with SQL Server in Azure Virtual Machines.

      • Лицензирование. Каждый месяц взимается плата за базу данных SQL выбранного размера. Для SQL Server требуется лицензия при выполнении системы в виртуальной машине Azure.

      • Вход и безопасность. Проверка подлинности Windows (встроенная безопасность) в базе данных SQL не поддерживается, но доступна для системы SQL Server, выполняющейся в виртуальных машинах Azure. Дополнительные рекомендации по безопасности и ограничения базы данных SQL рассмотрены в разделе Безопасность в базе данных SQL Azure: рекомендации и ограничения.

      • Сходные функции. Дополнительные сведения о подобии и различиях между SQL Server и базой данных SQL см. в разделе SQL Database Overview.

  • Вход и безопасность для пользователей. Благодаря новым сетевым улучшениям в Azure домен Active Directory локальной сети может быть расширен до Azure. Дополнительные сведения см. в Migration with Azure Virtual Machines. Подробные сведения об администрировании безопасности базы данных SQL см. в разделе Управление базами данных, именами для входа и пользователями в Базе данных SQL Azure.

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

  • Индустрия платежных карт (PCI) и другие нормативные требования. Перед перемещением приложения или компонента в Azure проверьте текущее состояние необходимой сертификации или нормативных требований. При наличии требований совместимости с PCI может понадобиться удалить некоторые части приложения и базы данных, предназначенных для переноса в Azure, и запустить гибридное приложение. Это позволяет сохранить преимущества Azure и облачных вычислений в большинстве компонентов, обеспечивая при этом жесткий контроль нормативных органов и совместимость частей данных и приложения, для которого это необходимо.

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

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

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

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

План миграции должен включать планы всестороннего тестирования функциональных возможностей и тестирования загрузки. Описание методологий тестирования выходит за рамки данной статьи. Далее перечисляются некоторые критически важные моменты, которые нужно помнить при тестировании.

  • Автоматизируйте скрипты теста

  • Протестируйте все уровни и компоненты приложения

  • Протестируйте соотношения действий, которые представляют реальные соотношения в системах

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

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

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

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

  • Средства. Определите средства, необходимые для разработки, тестирования и развертывания приложения Azure. Дополнительные сведения см. в разделах Средства Azure для Microsoft Visual Studio и Поддержка средств и программ базы данных SQL Azure.

  • Консультирование. Для миграции приложения может понадобиться консультация у специалиста по миграции. Помощь специалиста по миграции может сэкономить значительное время и финансовые ресурсы и решить общие проблемы.

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

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

Дополнительные сведения об API для управления развертыванием Azure см. в разделе Программные интерфейсы для Azure.

См. также

Показ:
© 2016 Microsoft