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 — це трохи як порівнювати пульт дистанційного керування з телевізором. Це не конкуруючі технології; вони працюють на абсолютно різних рівнях ІТ-стека.

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

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 варто розгортати, коли ви оновлюєте застарілу локальну інфраструктуру або створюєте нове периферійне середовище обчислень і хочете, щоб ця локальна інфраструктура працювала як продовження хмари 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 на своїх периферійних майданчиках? Залишайте коментар нижче або надішліть нам електронного листа для наступного випуску з відповідями на листи слухачів. До нових зустрічей, продовжуйте проєктувати майбутнє!