Azure Arc и Azure Local: разбираемся в терминологии гибридной инфраструктуры Microsoft

By Mirko Peters · 2026-08-22

Добро пожаловать обратно в подкаст! Если вы следите за нашими недавними выпусками о современной корпоративной ИТ-архитектуре, вы знаете, что мы много говорим о стратегиях гибридного облака…

Automatically translated with AI from the original post. Read the English original

Добро пожаловать обратно в подкаст! Если вы следите за нашими недавними выпусками о современной корпоративной ИТ-архитектуре, вы знаете, что мы много говорим о стратегиях гибридного облака. Недавно я получил отличное письмо от слушателя по имени Маркус из Чикаго. Маркус написал: «Я пытаюсь спроектировать инфраструктуру нового поколения для нашей компании, но каждый раз, когда я читаю документ Microsoft, я теряюсь в модных словах. В чем на самом деле разница между Azure Arc и Azure Local? Это конкурирующие продукты? Нужны ли мне оба?»

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

Введение: эволюция гибридной модели Microsoft

Чтобы понять, где Azure Arc и Azure Local находятся сегодня, нужно ненадолго оглянуться назад. Десятилетиями корпоративные ИТ строились по принципу «или-или»: рабочие нагрузки либо жили на собственных физических серверах в локальном дата-центре, либо в дата-центре кого-то другого. Затем произошла революция публичного облака во главе с Microsoft Azure, Amazon Web Services и Google Cloud Platform. Внезапно организации начали спешно переносить всё в облако, обещая бесконечную масштабируемость и сокращение капитальных расходов.

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

Это осознание стало отправной точкой эры гибридного облака. Microsoft рано поняла, что будущее — не чисто публичное облако, а бесшовный континуум от периферии через дата-центр до облака. Со временем Microsoft создала несколько инструментов, чтобы перекинуть мост через этот разрыв. Одни инструменты были призваны управлять существующим оборудованием, другие — полностью модернизировать его. Это подводит нас к двум главным темам сегодняшнего выпуска: Azure Arc, который отвечает за управление и контроль, и Azure Local, который обеспечивает собственно основу гиперконвергентной инфраструктуры.

Расшифровка терминологии: что такое Azure Arc?

Начнём с Azure Arc. Если из этого раздела вы запомните только одно предложение, пусть это будет такое: Azure Arc — это плоскость управления, а не инфраструктурный продукт.

Представьте Azure Arc как волшебную палочку, которая расширяет плоскость управления Azure — ту самую управленческую среду, которой вы пользуетесь для управления виртуальными машинами, базами данных и кластерами Kubernetes в публичном облаке Azure, — на ваши собственные дата-центры, периферийные площадки и даже на конкурирующие облака, такие как AWS и Google Cloud Platform.

Как Azure Arc работает под капотом

По сути, Azure Arc работает, устанавливая легковесные агенты на ваши существующие ресурсы, где бы они ни находились. Будь то физический сервер Linux в стойке во Франкфурте, виртуальная машина VMware в вашем локальном офисе в Чикаго или экземпляр Amazon EC2 — Azure Arc подключает этот ресурс обратно к Azure. После подключения внешний ресурс проецируется в Azure Resource Manager (ARM). И вот ваши серверы, не относящиеся к Azure, появляются прямо рядом с нативными виртуальными машинами Azure на портале Azure.

Эта проекция открывает доступ к обширному набору облачных возможностей для инфраструктуры, которая на самом деле никогда не касается облака Azure:

• Единое управление и соответствие требованиям: Вы можете применять Azure Policy к локальным серверам, чтобы конфигурации оставались соответствующими требованиям во всей вашей инфраструктуре.
• Расширенная безопасность: Microsoft Defender for Cloud можно расширить для мониторинга угроз и уязвимостей на серверах вне Azure и в кластерах Kubernetes.
• Облачный мониторинг: Azure Monitor может собирать журналы и метрики из вашей локальной инфраструктуры, предоставляя единое окно для наблюдаемости.
• Службы с поддержкой Arc: Вы даже можете запускать Azure SQL Managed Instance и Azure PostgreSQL на собственной локальной инфраструктуре, полностью управляя ими через плоскость управления Azure.

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

Разбираемся в терминологии: что такое Azure Local?

Теперь, когда мы разобрались с Azure Arc как с уровнем управления, перейдём к инфраструктурной части: Azure Local. Если Azure Arc — это программно определяемая плоскость управления, которая охватывает всё, то Azure Local — это решение для гиперконвергентной инфраструктуры (HCI), предназначенное для запуска рабочих нагрузок локально, в вашем дата-центре или на периферии.

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

Архитектура Azure Local

Azure Local объединяет технологии Windows Server с продвинутым программным обеспечением гиперконвергентной инфраструктуры, обеспечивая виртуализацию и возможности хранения корпоративного уровня. Для виртуализации используется Hyper-V, а для высокопроизводительного программно определяемого хранилища — Storage Spaces Direct.

Что действительно выделяет Azure Local, так это глубокая, изначально встроенная интеграция с публичным облаком Azure. Традиционным платформам виртуализации для подключения к облаку требуются сторонние инструменты, тогда как Azure Local изначально рассчитан на подключение к облаку. Он позволяет запускать привычные виртуальные машины Windows и Linux, а также кластеры Azure Kubernetes Service (AKS) локально, на оборудовании, которым вы физически владеете и которое эксплуатируете.

Ключевые возможности Azure Local:

• Высокая доступность и отказоустойчивость: Встроенная кластеризация и репликация хранилища гарантируют, что локальные рабочие нагрузки продолжат работать даже при отказе оборудования.
• Гибкие форм-факторы: от прочных периферийных узлов, развёртываемых в магазинах или на производстве, до масштабных многоузловых кластеров в корпоративных дата-центрах — Azure Local масштабируется под имеющееся физическое пространство.
• Знакомая виртуализация: Если ваша команда уже знакома с Hyper-V или общими концепциями виртуализации, освоение Azure Local потребует очень небольшого времени.

Ключевые различия между управлением и инфраструктурой

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

Разберём основные различия по нескольким ключевым параметрам:

1. Уровень стека

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

2. Зависимость от оборудования

Поскольку Azure Arc — это инструмент управления на основе агентов, у него практически нет зависимостей от оборудования. Агент Arc можно установить на пятилетний сервер Dell с устаревшей версией Linux, новый сервер HPE с Windows или даже на виртуальную машину, размещённую в AWS. Azure Local, напротив, требует конкретного проверенного оборудования от партнёров Microsoft по аппаратным решениям. Нельзя просто установить Azure Local на любое случайное железо из серверной: нужны сертифицированные узлы кластера, чтобы обеспечить производительность, надёжность и возможность поддержки.

3. Основное назначение

Цель Azure Arc — единое управление, то есть внесение порядка в разрозненный мультиоблачный и локальный ИТ-портфель. Цель Azure Local — современная локальная инфраструктура: облачно-ориентированная платформа HCI для запуска виртуализированных и контейнеризированных рабочих нагрузок непосредственно там, где формируются данные.

Когда использовать Azure Arc, а когда Azure Local

Итак, мы разобрались, что делает каждый из этих инструментов. Теперь поговорим о принятии решений. На сессиях по планированию архитектуры как понять, когда стоит обратиться к Azure Arc, а когда развернуть Azure Local?

Когда использовать Azure Arc

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

• У вас большие существующие инвестиции в VMware или серверы Linux на «голом железе» в нескольких глобальных центрах обработки данных, и вы хотите видеть всё в одном окне на портале Azure, чтобы управлять соответствием требованиям, отслеживать журналы и применять политики.
• Вы используете кластеры Kubernetes в AWS или Google Cloud и хотите применять Azure GitOps и Azure Policy для управления развёртываниями во всех этих облаках одновременно.
• Вы хотите запускать службы данных Azure, такие как Azure SQL Managed Instance, локально, не мигрируя всю базовую среду виртуализации целиком.

Когда использовать Azure Local

Azure Local стоит развёртывать, когда вы хотите обновить устаревающую локальную инфраструктуру или построить новую периферийную (edge) вычислительную среду и при этом хотите, чтобы эта локальная инфраструктура ощущалась и работала как продолжение облака Azure:

• Ваша традиционная SAN-система и стек виртуализации подходят к концу жизненного цикла, и вы хотите заменить их современной программно-определяемой гиперконвергентной инфраструктурой, которая нативно интегрируется с резервным копированием, аварийным восстановлением и мониторингом Azure.
• Вам нужны вычисления и хранение с низкой задержкой в периферийной локации, например в больнице, розничном магазине или на производственном предприятии, где данные должны обрабатываться на месте, но вы хотите централизованно управлять этими рабочими нагрузками из облака Azure.
• Вы хотите запускать Azure Kubernetes Service (AKS) локально с полной поддержкой и бесшовной интеграцией в существующие конвейеры развёртывания в облаке.

Как они работают вместе в гибридной стратегии

Вот где и происходит настоящая магия. Хотя Azure Arc и Azure Local — это отдельные продукты, Microsoft спроектировала их так, чтобы они работали лучше вместе. Фактически кластеры Azure Local по умолчанию автоматически подключаются к Azure Arc!

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

Давайте посмотрим на реальный гибридный сценарий, чтобы увидеть, как этот синергетический эффект работает на практике. Представьте себе крупную глобальную логистическую компанию:

1. На периферии: Компания управляет сотнями центров выполнения заказов по всему миру. В каждом центре она развёртывает небольшие двухузловые устройства Azure Local, которые обрабатывают транспортные этикетки, запускают локальные экземпляры баз данных и управляют системами автоматизации склада с минимальной задержкой.
2. По всему предприятию: У компании также есть унаследованные центры обработки данных с смесью VMware и физических серверов, плюс некоторые рабочие нагрузки в AWS. Они устанавливают агенты Azure Arc во всех этих средах, чтобы применять базовые требования безопасности и отслеживать соответствие.
3. Единое управление: через Azure Portal центральная ИТ-команда может видеть состояние периферийных центров обработки заказов (работающих на Azure Local) наряду с экземплярами AWS и устаревшими серверами (управляемыми через Azure Arc). С помощью Azure Policy они обеспечивают соблюдение стандартов шифрования везде, а с помощью Azure Monitor отслеживают метрики производительности по всему миру.

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

Заключение: упрощаем путь к гибридному облаку

Разобраться в экосистеме гибридного облака Microsoft на первый взгляд может быть непросто, но когда вы сопоставляете терминологию с конкретными архитектурными уровнями, всё встаёт на свои места. Запомните главное правило: Azure Arc — это плоскость управления для всего и повсюду, а Azure Local — это современная гиперконвергентная инфраструктура для локальных и периферийных нагрузок.

Планируя корпоративную архитектуру на следующий год, не воспринимайте эти технологии как выбор «или-или». Лучше посмотрите, как они дополняют друг друга. Используйте Azure Arc, чтобы объединить и контролировать существующие разнородные ИТ-активы, а Azure Local применяйте, когда нужно модернизировать локальную и периферийную инфраструктуру с гибкостью облачных решений.

Надеюсь, этот подробный разбор внес ясность в путаницу вокруг гибридной терминологии Microsoft. Как всегда, мы будем рады вашим отзывам. Используете ли вы Azure Arc в мультиоблачных средах? Развернули ли вы Azure Local на периферийных площадках? Оставьте комментарий ниже или напишите нам на почту для следующего выпуска с ответами на вопросы слушателей. До новых встреч, продолжайте проектировать будущее!