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