Продажи: 1-800-867-1389

Реализация плана миграции для Azure

Обновлено: Апрель 2014 г.

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

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

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

Авторы: Чэн Кун (Kun Cheng), Стив Ховард (Steve Howard)
Соавторы: Селсин Тюркаслан (Selcin Turkarslan)

Чтобы приложение, перенесенное в облако, работало правильно, необходимо знать, как выполнять его отладку и тестирование. Ниже приведен список методов, которые можно использовать для теста приложения.

  • Инструменты Azure для Microsoft Visual Studio. Можно построить приложение, а затем запускать и отлаживать его локально с помощью эмуляторов вычислений и хранения, которые предоставляются как часть инструментов Azure. Это позволяет разрабатывать приложения локально перед публикацией в Azure. Средства Azure для Microsoft Visual Studio расширяют возможности Visual Studio 2010 и позволяют тестировать приложение с помощью эмуляторов вычислений и хранилища, которые обеспечивают большую часть функций Azure. Рекомендуется выполнить этот тип проверки на ранних стадиях функционального тестирования. Дополнительные сведения см. в разделе Средства Azure для Microsoft Visual Studio.

  • SQL Server Data Tools. Средства SSDT предоставляют интегрированную среду в Visual Studio 2010, которую можно использовать для разработки баз данных, создания или изменения объектов баз данных и данных или выполнения запросов для всех поддерживаемых платформ SQL, в том числе облачной базы данных SQL Azure и локальной базы данных Microsoft SQL Server 2012. Это позволяет проверить решения проекта базы данных с помощью местной базы данных по умолчанию или базы данных SQL Azure путем изучения части приложения, отвечающей за доступ к реляционным данным. Дополнительные сведения см. в разделе SQL Server Data Tools. Примечание. Средства Azure для Microsoft Visual Studio и SSDT позволяют выполнять основные тесты функциональности и совместимости приложения с источниками данных в сети и вне сети. Для проверки реального облачного приложения с точки зрения функциональных возможностей, производительности и масштабируемости необходимо провести его тестирование на платформе Azure, на которой оно развертывается и выполняется.

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

  • Тестирование нагрузки Visual Studio. Если у приложения нет автоматической платформы теста, рекомендуется создать новую платформу тестирования и использовать средства тестирования нагрузки Visual Studio для моделирования с несколькими параллельно работающими пользователями.

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

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

Служба Синхронизация данных SQL (предварительная версия) предоставляет возможности синхронизации данных для баз данных SQL — SQL Server и база данных SQL. В настоящее время служба обеспечивает две основные функции:

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

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

Служба Синхронизация данных SQL (предварительная версия) — это хороший вариант для синхронизации локальных баз данных и экземпляров баз данных база данных SQL в следующих ситуациях.

  • Тестировать приложения следует параллельно.

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

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

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

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

Внимание! Система Синхронизация данных SQL (предварительная версия) в настоящее время доступна в качестве предварительной версии и предназначена для составления отзывов для будущих версий. Использовать эту предварительную версию в рабочих средах нельзя.

Дополнительные сведения о службе Синхронизация данных SQL (предварительная версия) см. в разделе Синхронизация данных SQL (предварительная версия).

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

Для того чтобы свести к минимуму время, необходимое для передачи данных во время перехода, следует переместить как можно больше данных в Azure до фактического перехода. Можно создать настраиваемое ETL-задание для перемещения измененных данных из локальной системы в среду Azure. При миграции из локальной системы SQL Server 2008 или более поздней версии рекомендуется использовать средства отслеживания измененных данных и отслеживания изменений, чтобы все измененные данные, и только измененные данные перемещались из локальной базы данных в экземпляр базы данных SQL Azure. Дополнительные сведения об этих двух функциях см. в разделе Отслеживание измененных данных в документации по SQL Server в сети. Для баз данных, не использующих отслеживание измененных данных и отслеживание изменений, необходимо создать систему отслеживания изменений и перенесенных данных. Во всех случаях минимальный объем данных для перемещения на момент перехода — это ключевой момент для минимизации времени простоя.

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

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

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

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

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

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

При выполнении фактического переноса приложения в Azure используются следующие подходы:

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

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

См. также

Была ли вам полезна эта информация?
(1500 символов осталось)
Спасибо за ваш отзыв
Показ:
© 2014 Microsoft