Подготовка среды к гибридному и многооблачнному сценарию

Методология Cloud Adoption Framework Ready позволяет клиентам подготовить среду к внедрению облака. Методология включает технические акселераторы, такие как целевые зоны Azure, которые являются стандартными блоками любой среды внедрения облака Azure.

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

Гибридная и многооблачная среда в целевых зонах

Целевые зоны Azure — это выходные данные среды Azure с несколькими скриптами, для которых используется следующая учетная запись:

• Масштабировать
• Управление безопасностью
• Сеть
• Идентификация
• Управление затратами
• Наблюдение

Рекомендации по вашей среде могут немного отличаться при подготовке к гибридному развертыванию и развертыванию с несколькими облаками. Согласованная среда для любого гибридного и многооблачного развертывания требует рассмотрения:

• Топология сети и подключения
• Унифицированные элементы управления операционными процессами для операций, управления, безопасности и соответствия требованиям
• Унифицированные и согласованные дисциплины автоматизации, опыт разработки и методики DevOps в разнородных средах

Azure Arc включает гибридные и многооблачные архитектуры и содержит набор технологий. Каждая архитектура включает все критически важные области проектирования и рекомендации по созданию успешного развертывания.

Оценка набора облачных решений

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

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

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

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

  • Fabrikam является гибридным клиентом с большими инвестициями в стареющие центры обработки данных. Ее самые высокие приоритеты — это затраты и управление. Устаревшие ИТ-приоритеты и устаревшая инфраструктура технологий препятствуют инновациям Fabrikam, что приводит к внедрению некоторых ранних облачных решений.

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

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

• Клиент с несколькими облаками: большинство рабочих нагрузок размещаются в другом общедоступном облаке, например Google Cloud Platform (GCP) или Amazon Web Services (AWS). Стратегические решения приводят к нескольким рабочим нагрузкам, живущим в Azure или на пограничных устройствах. Клиенты часто переходят из гибридного смешивания в azure-first, так как их облачная стратегия зрела, но мы также поддерживаем клиентов, которые решили сделать гибридный или многооблачный смешивает их приоритет. Azure играет роль в каждом типе смеси.

  • Tailwind Traders — это клиент с несколькими облаками. Как и Contoso, он переехал в облако, но не использовал Azure для этого. У него есть некоторые локальные ресурсы центра обработки данных и пограничные устройства. Tailwind Traders является ранним внедрением других облаков на раннем этапе запуска, и его самым большим приоритетом является рост. Требования к розничной торговле клиентов и потребность в улучшенных операциях, позволяющих эффективно масштабировать гибридный и многооблачный рост.

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

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

Общие сведения об Azure Arc

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

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

• Управление приложениями Kubernetes в масштабе: используйте методы DevOps для развертывания приложений Kubernetes и управления ими в разных средах. Убедитесь, что вы последовательно развертываете и настраиваете приложения из системы управления версиями.

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

• Включите самостоятельный доступ к виртуальным машинам: используйте управление доступом на основе ролей Azure (RBAC), чтобы предоставить самостоятельное обслуживание своим ресурсам VMware vSphere и System Center диспетчер виртуальных машин через Azure. Выполнение операций жизненного цикла и питания виртуальных машин из портал Azure и автоматизации сборки с помощью шаблонов Azure, API и пакетов SDK.

Моментальный снимок клиента Azure Arc

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

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

С помощью Azure Arc в качестве гибридной и многооблачной плоскости управления эти клиенты могут использовать существующие ИТ-инвестиции и текущие операционные методики в не распространяемом виде. Чтобы продолжить использование своих текущих методик, клиенты подключены к этим ресурсам:

• Серверы с поддержкой Azure Arc, VMware vSphere с поддержкой Azure Arc или System Center с поддержкой Azure Arc диспетчер виртуальных машин
• Серверы SQL
• Кластеры Kubernetes

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

Azure Arc расширяет API Azure Resource Manager (ARM), чтобы вы могли представлять любую рабочую нагрузку в качестве первого класса гражданина в Azure. Это расширение обеспечивает основу для реализации унифицированных операций, управления, соответствия, безопасности и управления в масштабе. Она реализована с помощью:

• Централизованный мониторинг
• Ведение журнала
• Телеметрия
• Политики
• Управление исправлениями
• Отслеживание изменений
• Управление запасами
• Обнаружение угроз
• Безопасность управление уязвимостями и аудит

Настройка исходной среды Azure

Для каждой облачной смеси вам потребуется среда Azure для поддержки, управления облачными ресурсами и управления ими. Методология готовности Cloud Adoption Framework предоставляет несколько шагов, которые помогут вам подготовить среду:

• Ознакомьтесь с тем, что такое целевая зона Azure?

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

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

• Узнайте, как перенести существующие среды Azure в концептуальную архитектуру целевой зоны Azure.

Azure Arc в качестве акселератора целевой зоны

Ресурсы Azure Arc могут быть частью любого приложения. Вот некоторые примеры.

• Серверы с поддержкой Azure Arc, VMware vSphere с поддержкой Azure Arc и System Center с поддержкой Azure Arc диспетчер виртуальных машин, представляющие ИТ-ресурсы, развернутые за пределами Azure. Целевые службы Azure Arc, такие как VMware vSphere с поддержкой Azure Arc и System диспетчер виртуальных машин Center с поддержкой Azure Arc, проектируют ИТ-ресурсы, развернутые в VMware vCenter и System Center диспетчер виртуальных машин управляемые локальные центры обработки данных в Azure.
• Управляемые клиентом кластеры Kubernetes в многооблачной среде.
• Данные, приложения и службы машинного обучения с поддержкой Azure Arc, работающие на границе.

Подписки целевой зоны приложений также могут содержать ресурсы Azure Arc и обычные ресурсы Azure.

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

Распространенные примеры ресурсов Azure Arc в целевых зонах Azure

В следующих примерах показано, как проектируете ресурсы Azure Arc в качестве ресурсов метаданных в целевых зонах Azure.

Пример. Проецирование контроллеров домена за пределами Azure

Многие клиенты развертывают домен Active Directory службы (AD DS) в своих средах. Контроллеры домена являются критически важным компонентом AD DS и общей архитектурой клиентов.

В концептуальной архитектуре целевой зоны Azure есть подписка выделенной целевой зоны удостоверений, предназначенная для размещения ресурсов на основе удостоверений. Эту подписку можно разместить в Azure с помощью виртуальных машин контроллера домена AD DS (DC). Вы также можете проецирования его в Azure из любого другого расположения с помощью серверов с поддержкой Azure Arc.

Пример 2. Проектирование локальных центров обработки данных в Azure

Большинство клиентов по-прежнему имеют локальные центры обработки данных в своих средах. Объемы этих центров обработки данных могут отличаться от отдельных серверов до крупных виртуализированных сред.

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

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

Пример 3. Проецирование ресурсов удаленного приложения в Azure

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

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

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

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

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

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

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

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

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

• Клиенты должны ознакомиться с руководством по акселератору целевой зоны с поддержкой Azure Arc, чтобы ознакомиться с рекомендациями по проектированию в критически важных областях проектирования.

Если клиенты не имеют или не планируют развертывать целевую зону Azure в данный момент:

• Клиенты должны ознакомиться с руководством по акселератору целевой зоны с поддержкой Azure Arc, чтобы ознакомиться с рекомендациями по проектированию в критически важных областях проектирования.

Следующие шаги

Дополнительные сведения о гибридном и многооблачном облаке см. в следующих статьях.

• Ознакомьтесь с обзором акселератора целевой зоны с поддержкой Azure Arc для гибридной и многооблачной среды.

• Узнайте, как развернуть песочницу Azure Arc для ускорения внедрения гибридных или многооблачных архитектур.