Путешествие из локального в облако
Когда дело доходит до миграции в облако, можно выделить два основных ключа успеха этого процесса.
Во-первых, начинайте с малого. Это означает сфокусироваться на одной простой среде приложения. При перемещении в облако мы будем внедрять инструменты и запускать приложение в новой среде. Эти изменения могут затруднять определение того, насколько успешно перемещено приложение. Чем больше мы знаем о перемещаемом приложении или сервисе, тем больше шансов на успех.
Во-вторых, определите как успех выглядит для Вас, команды, организации. Шаги, предпринимаемые сейчас, готовят почву для успеха в будущем.
Миграция в облако - это нечеткое понятие и может выполняться по различным причинам. Некоторые из этих причин повлияют на то, сколько изменений вы готовы выдержать в процессе миграции в облако.
Поскольку работа будет осуществляться на оборудовании, находящемся под Вашим контролем, необходимы четкие представления о работоспособности приложения для правильного распределения количества ресурсов. Отсутствие этой информации может привести к чрезмерным затратам и отсутствию эффективности в сравнении с Вашим опытом работы в локальной среде.
Определение (взаимных) зависимостей
Правильно начинать миграцию с понимания того, с чем связано приложением. При миграции в облако некоторые сервисы и данные могут оставаться локальными и необходимо убедиться, что приложение сможет получить к ним доступ. Некоторые необходимо перенести в облако и разместить рядом с приложением. Пока нет четкого понимания, с чем связано приложение, существует риск нарушить поведения приложения в процессе перемещения.
Application Insights
Полезным инструментом в этом процессе является Application Insights. Хотя его основной функцией является мониторинг приложения, Application Insights может использоваться для формирования осведомленности о службах, к которым подключается приложение. Существует 2 основных метода интеграции Application Insights - Codeless Attach и с использованием SDK.
И хотя Application Insights - служба, работающая в Azure, Вы не ограничены в использовании только приложений Azure. Application Insights также предлагает простой доступ к рабочим нагрузкам, работающим в IIS через IIS (или Status Monitor М2).
Application Map
Application Map помогает визуализировать и отслеживать проблемы в распределенных приложениях.
Предположим, что большинство приложений обладает некоторыми внешними зависимыми объектами. Приложения без зависимых объектов обычно называются устройствами или виртуальными устройствами. Это, как правило, автономные экосистемы, где у Вас нет достаточного контроля.
Почти у всего остального есть какие-либо взаимодействия, и Application Map помогает обнаружить их. Это особенно полезно для приложений, когда нет команд, назначенных для их обслуживания или предоставляемых подрядчиками или консультантами.
Codeless Attach
Поговорим о сборе данных с помощью Application Insights. Первый метод - Codeless Attach- позволяет Application Insights отслеживать приложение без изменения кода. Настроить его на Windows Server довольно просто.
Сначала, установите модуль Power Shell Az.ApplicationMonitor.
Enable-ApplicationInsightsMonitoring -ConnectionString xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Теперь любое приложение, которое еще не ссылается на Application Insights SDK будет автоматически инструментировано.
Важный момент: если у приложения уже есть SDK, тогда нужно настроить приложение через код или файл конфигурации, чтобы связать с Application Insights. Это также означает, Вы не будете нарушать существующий мониторинг Application Insights, подключив его для других неинструментированных приложений.
Вы можете проверять состояние каждого веб-сайта в IIS с помощью Get-ApplicationInsightsMonitoringStatus cmdlet.
Другой вариант - включить Application Insights SDK в приложение. Недавние шаблоны .Net приложений уже включают Application Insights SDK; в таком случае речь идет о конфигурации инструментального ключа или о строке подключения.
Но Вы можете сделать гораздо больше: настроить отображение приложения в Application Map, установив имя облачной роли и/или имя облачного экземпляра. Несмотря на имена свойств, они могут быть использованы независимо от того, где запущено приложение. Они помогают идентифицировать приложение и сервер (или экземпляр сервиса), на которых запущено.
После того как приложение инструментировано, Вам нужно дать ему время поработать. Некоторые зависимости могут быть часто недоступны, поэтому продление периода обнаружения - на дни, недели или даже месяцы может помочь выявить доступные ресурсы.
В то время как Application Insights запущен для сбора сведений Application Map, у Вас есть возможность собирать данные о производительности. Это может стать основой того, как приложение должно работать в облаке. Вы увидите вызовы из приложения в зависимости. Это поможет оценить необходимость перемещения зависимости в облако (или же ее можно оставить локально на какое-то время), эффективность сервиса SKU, на котором Вы работаете: нужно ли его масштабировать или у Вас есть место для его уменьшения и экономии денег.
Теперь, когда у Вас есть какие-то данные о приложении и его зависимостях, можно приступать к планированию миграции.
Перемещение приложения и базы данных вместе имеет смысл, учитывая тесную связь и зависимость производительности страницы от результатов работы базы данных.
Путешествие из локального в облако. Эпизод 2
Вы знаете, на что похожа миграция? На переезд. Я дважды переезжал. Упаковка, переупаковка, сортировка отнимают много времени. Небольшие коробки я перевозил на машине, но крупногабаритные вещи с помощью компании-перевозчика. Главная проблема переезда, так же как и миграции приложения заключается во времени и усилиях, затраченных на то, чтобы собрать, разобрать и вернуться к нормальной жизни.
А что, если бы была возможность отключить электричество, газ, воду и переехать на грузовичке на новое место, где, подключившись к службам жизнеобеспечения, продолжить жить? В подобном сценарии переезда не рассматривается процесс разбора или выбрасывания вещей. Мы отключаемся и подключаемся к источникам энергии и возвращаемся к прежнему образу жизни. И если для домашнего переезда это не совсем разумно, то для хостинговой среды приложения - вполне. Лучший путь миграции в облако - наименее ухабистая дорога.
Что такое lift and shift?
Lift and shift - стратегия миграции, которая выбирает путь наименьшего сопротивления, позволяя повторно размещать существующую рабочую нагрузку без модификаций. Как и при переезде, собирается все, что есть в дата-центре и перемещается это в облако. Но в отличие от переезда на новое местожительства, здесь не снимаются стойки и не вытаскиваются серверы.
Миграция lift and shift перемещает существующий сервер с текущего хоста в облачный с использованием инструментов для репликации того, что запущено на локальном решении. Это означает, что наша база данных SQL, IIS конфигурация, параметры реестра и конфигурация ОС - части нового развертывания на Azure без необходимости переписывания части приложения для PaS. В этом случае происходит перемещение на виртуальные машины Azure и сокращается время работы и усилий.
Ограничения
Миграция требует принятия ряда решений после выбора стратегии.
Зачем нужна миграция? – один из популярнейших вопросов. Главная причина – меньшая зона ответственности. Управление сетями, rack - конфигурации, системы резервного копирования, устройства балансировки нагрузки и другие части инфраструктуры подвергают дополнительному риску. Приходится быть экспертами во всем оборудовании, понимать как части взаимосвязаны между собой. Это сложно сделать только с помощью процесса разработки ПО и документации. Позвольте Azure обрабатывать эти вещи, в то время как Вы работаете над приложением. Иногда приходится сталкиваться с таким возражением:" Разве в облаке не дороже?" Дороже может быть только в случае, если во внимание не принимаются ресурсы, создаваемые в облаке. Выяснение того, что нужно, сколько и когда поможет лучше определить расходы и принести максимальную ценность. Кто будет осуществлять lift and shift? Кто будет следить за каждым шагом процесса миграции? Кто обновляет DNS? Это только несколько вопросов, которы важно проработать команде.
Azure Migrate
Azure Migrate - набор инструментов в Azure, который помогает в процессе lift and shift, предоставляет возможность обнаружить и определить, как выглядит текущее развертывание приложения. Используйте центральный репозиторий для перемещения таких элементов как резервные копии сервера и баз данных.
Azure Migrate оценивает и подготавливает серверы, веб-приложения, виртуальные рабочие столы и даже большие неструктурированные данные.
Azure Migrate помогает выполнить оценку на существующем развертывании для определения готовности к облачной миграции. Изучите существующие VMWare, Hyper-V, Xen, или даже серверы другой облачной хостинговой компании. Ключевые части оценки включают определение места миграции, размер виртуальных машин, использование и производительность серверов. После завершения Azure Migrate составляет рейтинг успешности миграции. Станет понятно, готовы ли Вы перейти в облако ДО того, как выполните этот процесс.
После определения того, что нужно, можно реплицировать серверы с использованием Azure Migrate, установленным на виртуализированный сервер Windows. Программно-аппаратный комплекс разворачивается на решениях VMware или Hyper-V, с использованием шаблонов OVA или VHD. Программно-аппаратный комплекс будет координировать взаимодействие, безопасность и процесс миграции данных для приложений.
После завершения репликации сервера необходимо время, подходящее для завершения миграции наилучшим образом, чтобы перейти на хост в Azure. Произведите некоторые финальные изменения в DNS или расскажите команде о начале использования нового расположения при входе в определенные приложения. Это продолжает процесс коммуникации, упомянутый ранее.
Информация, приведенная здесь, общая. Лучший способ начать изучать как выглядит миграция на практике - обучающий модуль от Microsoft “Design your migration to Azure”. Вместе с модулем идет много полезной информации на сайте Microsoft Docs. В случае, если что-то пойдет не так, всегда поможет служба поддержки Azure.
