Разработка архитектуры рабочей нагрузки перед миграцией
В этой статье описывается процесс и рекомендации по проектированию предполагаемого состояния перенесенной рабочей нагрузки в облаке. В статье рассматриваются действия, которые являются частью определения архитектуры рабочей нагрузки в рамках итерации.
Статья о добавочной рационализации указывает, что некоторые архитектурные предположения являются частью любого бизнес-преобразования, включающего миграцию. В этой статье описываются типичные предположения. Он также указывает на несколько препятствий, которых можно избежать, и определяет возможности повышения бизнес-ценности путем пересмотра архитектурных предположений. Эта добавочная модель для проектирования архитектуры помогает командам быстрее перемещаться и получать бизнес-результаты раньше.
Разработка базовой архитектуры на распространенных предположениях
Следующие предположения типичны для любых усилий по миграции:
- Предположите инфраструктуру как услугу (IaaS) рабочей нагрузкой. Перенос рабочих нагрузок в основном включает перемещение серверов из физического центра обработки данных в облачный центр обработки данных с помощью миграции IaaS. Обычно процесс требует минимальной переработки или перенастройки. Этот подход называется миграцией типа lift and shift.
- обеспечить согласованность архитектуры. Внесение изменений в базовую архитектуру во время миграции значительно увеличивает сложность. Отладка измененной системы на новой платформе представляет множество переменных, которые могут быть трудно изолировать. Рабочие нагрузки должны проходить только незначительные изменения во время миграции, и все изменения должны тщательно тестироваться.
- Планирование изменения размера ресурсов. Предположим, что локальные активы практически не используют ни один ресурс полностью. До или во время миграции ресурсы изменяются в соответствии с фактическими требованиями к использованию. Такие инструменты, как Azure Migrate и Modernize, обеспечивают определение размеров на основе фактического использования.
- Учесть требования к обеспечению непрерывности бизнес-процессов и аварийного восстановления (BCDR). Если у вас есть соглашение об уровне обслуживания (SLA) для рабочей нагрузки, уже согласованное с бизнесом, продолжайте использовать соглашение об уровне обслуживания после миграции в Azure. Если соглашение об уровне обслуживания еще не задано, определите его перед проектированием рабочей нагрузки в облаке, чтобы убедиться, что вы правильно разрабатываете.
- Планирование простоя миграции. Подобно несоответствию требованиям соглашения об уровне обслуживания, время простоя, возникающее при переводе рабочей нагрузки в производственную среду, может оказать негативное влияние на бизнес. Иногда решения, которые должны переходить с минимальным временем простоя, требуют изменения архитектуры. Прежде чем приступить к планированию выпуска, предполагается, что общее представление о требованиях к простою уже установлено.
- Определение шаблонов трафика пользователей и приложений. Существующие решения могут зависеть от существующих шаблонов и решений маршрутизации сети. Определите ресурсы, необходимые для поддержки текущего использования сети.
- План предотвращения конфликтов в сети. При консолидации центров обработки данных в один поставщик облачных служб, скорее всего, возникают конфликты в системе доменных имен (DNS) или других сетевых структурах. Во время миграции важно избежать этих конфликтов, чтобы избежать прерываний в рабочих системах, размещенных в облаке.
- Планирование таблиц маршрутизации. Убедитесь, что проект включает в себя план изменения таблиц маршрутизации при консолидации сетей или центров обработки данных. Рассмотрите требования к маршрутизации между центрами обработки данных.
Проектирование архитектуры для зоны приземления
На этапе готовности Cloud Adoption Framework ваша организация развернула службы общей платформы в рамках внедрения целевых зон Azure. В Подготовка посадочной зоны для миграции, вы подготовили посадочную зону для приема перенесенных рабочих нагрузок.
На основе этого планирования можно предположить, что существуют следующие компоненты миграции:
- Гибридное подключение подключает сети Azure к локальным сетям.
- Сетевые устройства безопасности, такие как брандмауэр Azure, обрабатывают проверку трафика за пределами рабочей нагрузки.
- Политики Azure для применения таких методов управления, как требования к ведению журнала, разрешенные регионы, запрещенные службы и другие элементы управления являются активными.
- В Azure Monitor настроена рабочая область журналов для совместного использования.
- Устанавливаются общие ресурсы идентификации для поддержки серверов, присоединенных к домену, или для других нужд по идентификации.
Если эти основные компоненты миграции не установлены, ваша организация должна немедленно вернуться к этапу готовности для решения этих потребностей. Без этих компонентов миграция, скорее всего, будет иметь задержки и неудачи и быть менее успешными.
Рабочая нагрузка, которую вы разрабатываете, имеет подписку, назначенную ей, в идеале с помощью процесса обработки виртуальных подписок. Подписка может содержать несколько рабочих нагрузок или только одну, в зависимости от того, как ваша организация организовала ресурсы для рабочих нагрузок. При переносе рабочей нагрузки с большим количеством сред приложений может быть даже несколько подписок на основе рекомендаций по средам приложений.
Проектирование сетевой архитектуры рабочей нагрузки
Запланируйте развертывание ресурсов для конкретных приложений в определенной подписке и запланируйте разработку выделенной виртуальной сети для рабочей нагрузки. Дополнительные сведения см. в руководстве по проектированию сетевой архитектуры. Особое внимание следует уделить сегментации виртуальных сетей.
В вашей сети, скорее всего, требуются ресурсы, такие как подсистемы балансировки нагрузки и другие ресурсы доставки приложений. Для планирования этих ресурсов в Azure можно использовать руководство по архитектуре уровня N.
Проектирование зависимостей рабочей нагрузки
Средства оценки миграции должны предоставить вам способ анализа зависимостей, таких как анализ зависимостей в службе "Миграция Azure" и "Модернизация". Это средство помогает определить взаимозависимости между серверами.
Помимо планирования архитектуры для самой рабочей нагрузки, может потребоваться рассмотреть зависимости между рабочими нагрузками. Например, для некоторых рабочих нагрузок может потребоваться частое взаимодействие. Если это так, планирование волн миграции и зависимостей для учета этого требования помогает успешно выполнить миграцию.
Вы можете использовать рекомендации в Центре архитектуры Azure, например для периферийных сети, чтобы спроектировать работу взаимосвязанных рабочих нагрузок после миграции.
Подготовка к внедрению конфиденциальных вычислений
Подмножество нагрузок, требующих соблюдения суверенитета, может привести к использованию конфиденциальных вычислений. В рамках развертывания суверенной зоны создаются управляющие группы для конфиденциальных вычислений.
В контексте суверенитета для использования конфиденциальных вычислений требуется Azure Key Vault и управляемые клиентом ключи в качестве вспомогательной службы. Дополнительные сведения см. в разделе о шифровании с использованием ключей, управляемых клиентом, в Microsoft Cloud для обеспечения суверенитета.
Обновление первоначальной оценки облака
По завершении проектирования архитектуры вернитесь к оценке облака, чтобы убедиться, что вы все еще находитесь в запланированном бюджете. При добавлении вспомогательных служб, таких как подсистемы балансировки нагрузки или резервные копии, затраты могут измениться. Хотя вы можете использовать такие инструменты, как кейсы, в Azure Migrate и Modernize для выполнения подробных упражнений по управлению затратами, следует периодически пересматривать ваши оценки по мере корректировки дизайна архитектуры.
Если вы знакомы с традиционными процессами закупки ИТ-ресурсов, оценка ресурсов в облаке может показаться незнакомой. При внедрении облачных технологий переход осуществляется от жесткой и структурированной модели капитальных расходов к гибкой модели операционных расходов. Планирование миграции в облако часто происходит при первом обнаружении этого изменения организацией или ИТ-командой.
В традиционной модели капитальных расходов ИТ-команда пытается объединить покупку мощности для нескольких рабочих нагрузок в различных программах. Этот подход центрирует пул общих ИТ-ресурсов, которые могут поддерживать каждый из этих решений. В облачной модели операционных расходов затраты могут быть напрямую связаны с потребностями поддержки отдельных рабочих нагрузок, команд или бизнес-единиц. Она дает организации более прямое распределение затрат на внутренних клиентов и бизнес-цели, которые они поддерживают. Этот более динамический подход к финансовому управлению часто называется FinOps. Несмотря на то, что FinOps не является конкретным вопросом, касающимся Azure, это может быть полезно для углубленного понимания FinOps. Дополнительные сведения см. в разделе Что такое FinOps?.
При разработке архитектуры рабочей нагрузки для миграции можно использовать калькулятор цен со сведениями об оценке, чтобы понять цену всей рабочей нагрузки.
Кроме того, после переноса рабочей нагрузки следует продолжать работать для оптимизации затрат на рабочую нагрузку. Дополнительные сведения о том, как организации могут улучшить свои навыки управления затратами, см. в Улучшение дисциплины управления затратами.
Знать, когда изменить архитектуру
Миграции, как правило, сосредоточены на обслуживании существующей архитектуры и переходе его на облачную платформу. Однако иногда может потребоваться повторное распределение рабочей нагрузки даже для миграции. В этом списке приведены примеры, когда перед миграцией может потребоваться внести изменения архитектуры:
- Оплата технического долга. Некоторые устаревающие рабочие нагрузки несут большой технический долг. Технический долг может привести к долгосрочным проблемам, увеличивая затраты на размещение у любого поставщика облачных услуг. Когда технический долг неестественно увеличивает затраты на размещение, следует оценить альтернативные архитектуры.
- Повышение надежности. Стандартные базовые показатели операций обеспечивают степень надежности и восстановления в облаке. Для некоторых команд рабочей нагрузки может потребоваться более высокие SLA, что может привести к изменениям архитектуры системы.
- высокозатратные рабочие нагрузки. Во время миграции необходимо оптимизировать все ресурсы для выравнивания размера с фактическим использованием. Для решения конкретных проблем с затратами могут потребоваться изменения архитектуры.
- требования к производительности. Если производительность рабочей нагрузки напрямую влияет на бизнес, может потребоваться дополнительная архитектура.
- Безопасные приложения. Требования к безопасности обычно реализуются централизованно и обычно применяются ко всем рабочим нагрузкам в портфеле. Некоторые рабочие нагрузки могут иметь определенные требования к безопасности, которые могут привести к изменениям архитектуры.
Каждый из этих критериев служит индикатором потенциального препятствия миграции. В большинстве случаев можно решить проблему после переноса рабочей нагрузки, оптимизировав размеры серверов, добавив новые серверы или внеся другие изменения. Однако если перед переносом рабочей нагрузки требуется какой-либо из этих критериев, удалите рабочую нагрузку из волны миграции и оцените ее по отдельности.
Azure Well-Architected Framework и Azure Well-Architected Review могут помочь в беседах с техническим владельцем конкретной рабочей нагрузки, чтобы рассмотреть альтернативные варианты развертывания этой нагрузки.
Затем рабочая нагрузка классифицируется как перепроектирование или модернизация в плане внедрения облака. Из-за дополнительного времени, необходимого для повторного развертывания рабочей нагрузки, рассмотрите эти альтернативные пути внедрения рабочей нагрузки отдельно от процесса миграции.
Контрольный список архитектуры
Вы можете использовать следующий контрольный список, чтобы убедиться, что вы охватываете критически важные архитектурные аспекты:
- Убедитесь, что архитектура соответствует соглашениям об уровне обслуживания для доступности, аварийного восстановления и восстановления данных.
- Убедитесь, что к структуре сети применены методики сегментации сети.
- Убедитесь, что вы планируете отслеживать и записывать журналы.
- Убедитесь, что виртуальные машины имеют соответствующий размер для фактического времени вычислений, которое требуется.
- Убедитесь, что размер и производительность ваших дисков соответствуют вашим реальным требованиям.
- Убедитесь, что вы планируете использовать службы балансировки нагрузки, если они необходимы. К службам могут относиться экземпляры Azure Load Balancer, Azure Application Gateway, Azure Front Door или Azure Traffic Manager.
- Убедитесь, что вы планируете использовать требования к суверенитету и конфиденциальным вычислениям, если они необходимы.