Azure Arc a Azure Local: wyjaśnienie terminologii hybrydowej infrastruktury Microsoft

By Mirko Peters · 2026-08-22

Witamy ponownie w podcaście! Jeśli śledzicie nasze ostatnie odcinki o nowoczesnej architekturze IT w przedsiębiorstwach, wiecie, że dużo mówimy o strategiach chmury hybrydowej.

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

Titelbild: Azure Arc vs Azure Local: Clarifying Microsoft's Hybrid Infrastructure Terminology

Witamy ponownie w podcaście! Jeśli śledzicie nasze ostatnie odcinki o nowoczesnej architekturze IT w przedsiębiorstwach, wiecie, że dużo mówimy o strategiach chmury hybrydowej. Niedawno otrzymałem świetnego maila od słuchacza o imieniu Marcus z Chicago. Marcus napisał: „Próbuję zaprojektować infrastrukturę naszej firmy nowej generacji, ale za każdym razem, gdy czytam białą księgę Microsoft, gubię się w modnych hasłach. Jaka jest faktyczna różnica między Azure Arc a Azure Local? Czy to konkurencyjne produkty? Czy potrzebuję obu?”

Marcus, na pewno nie jesteś w tym sam. Microsoft ma dziś jeden z najbardziej kompleksowych ekosystemów hybrydowych na rynku, ale wraz z tym zakresem idzie ogromna ilość terminologii. Nazwy są zmieniane, skróty się przesuwają i nagle administratorzy IT oraz architekci chmury zastanawiają się, które narzędzie do czego służy. Dlatego właśnie chciałem poświęcić ten wpis rozłożeniu na czynniki pierwsze dwóch kluczowych filarów strategii hybrydowej Microsoft. Po przeczytaniu tego wpisu będziesz mieć pełną jasność co do tego, czym jest Azure Arc, czym jest Azure Local, czym się różnią i, co najważniejsze, jak mogą razem wzmocnić Twoją infrastrukturę.

Wprowadzenie: ewolucja hybrydowa Microsoft

Aby zrozumieć, gdzie dziś znajdują się Azure Arc i Azure Local, musimy na chwilę cofnąć się w czasie. Przez dziesięciolecia IT w przedsiębiorstwach było dwubiegunowe: obciążenia działały albo na własnych fizycznych serwerach w lokalnym centrum danych, albo w cudzym centrum danych. Potem nadeszła rewolucja chmury publicznej, prowadzona przez Microsoft Azure, Amazon Web Services i Google Cloud Platform. Nagle organizacje rzuciły się, by przenieść wszystko do chmury, obiecując nieograniczoną skalowalność i mniejsze nakłady kapitałowe.

Rzeczywistość szybko jednak dała o sobie znać. Przedsiębiorstwa zrozumiały, że nie wszystko nadaje się do chmury publicznej. Wymogi regulacyjne, przepisy o suwerenności danych, bardzo niskie opóźnienia na brzegu sieci oraz starsze aplikacje, których nie da się łatwo przebudować, sprawiły, że infrastruktura lokalna nie znikała. Jednocześnie organizacje nie chciały rezygnować z imponujących możliwości zarządzania, narzędzi bezpieczeństwa i wydajności programistów, które polubiły w Azure.

To spostrzeżenie zapoczątkowało erę chmury hybrydowej. Microsoft już wcześnie zrozumiał, że przyszłość nie należy wyłącznie do chmury publicznej, lecz do płynnego continuum rozciągającego się od brzegu sieci, przez centrum danych, aż po chmurę. Na przestrzeni lat Microsoft zbudował różne narzędzia, które wypełniają tę lukę. Niektóre zaprojektowano do zarządzania istniejącym sprzętem, inne do całkowitej modernizacji tego sprzętu. To prowadzi nas do dwóch głównych tematów dzisiejszego odcinka: Azure Arc, który odpowiada za zarządzanie i kontrolę, oraz Azure Local, który zapewnia właściwy fundament infrastruktury hiperkonwergentnej.

Odszyfrowanie terminologii: czym jest Azure Arc?

Zacznijmy od Azure Arc. Jeśli z tej sekcji zapamiętasz tylko jedno zdanie, niech będzie nim to: Azure Arc to płaszczyzna sterowania, a nie produkt infrastrukturalny.

Myśl o Azure Arc jak o czarodziejskiej różdżce, która rozciąga płaszczyznę sterowania Azure — ten sam interfejs zarządzania, którego używasz do maszyn wirtualnych, baz danych i klastrów Kubernetes w publicznej chmurze Azure — na Twoje własne centra danych, lokalizacje brzegowe, a nawet na konkurencyjne chmury, takie jak AWS i Google Cloud Platform.

Jak działa Azure Arc pod maską

U podstaw Azure Arc działa poprzez instalowanie lekkich agentów na istniejących zasobach, niezależnie od tego, gdzie się znajdują. Czy to fizyczny serwer Linux w szafie we Frankfurcie, maszyna wirtualna VMware w lokalnym biurze w Chicago, czy instancja Amazon EC2 — Azure Arc łączy ten zasób z powrotem z Azure. Po połączeniu zewnętrzny zasób zostaje odwzorowany w Azure Resource Manager (ARM). Nagle Twoje serwery spoza Azure pojawiają się obok natywnych maszyn wirtualnych Azure w portalu Azure.

To odwzorowanie odblokowuje rozbudowany zestaw możliwości natywnych dla chmury dla infrastruktury, która nigdy fizycznie nie łączy się z chmurą Azure:

Zunifikowane zarządzanie i zgodność: Usługę Azure Policy można zastosować do lokalnych serwerów, aby konfiguracje były zgodne z wymaganiami w całym środowisku.
Zaawansowane zabezpieczenia: Microsoft Defender for Cloud można rozszerzyć o monitorowanie zagrożeń i luk w zabezpieczeniach na serwerach spoza platformy Azure oraz klastrach Kubernetes.
Monitorowanie natywne dla chmury: Azure Monitor może zbierać dzienniki i metryki z lokalnej infrastruktury, zapewniając jeden widok do obserwowalności całego środowiska.
Usługi z obsługą Arc: Można nawet uruchamiać Azure SQL Managed Instance i Azure PostgreSQL na własnej lokalnej infrastrukturze, zarządzając nimi w całości z poziomu płaszczyzny sterowania Azure.

Co istotne, Azure Arc nie zależy od tego, jaki hiperwizor działa pod spodem. Nie zastępuje konfiguracji VMware, Hyper-V ani fizycznych serwerów bez wirtualizacji. Po prostu dodaje inteligentną warstwę zarządzania do tego, co już masz.

Wyjaśnienie terminologii: czym jest Azure Local?

Skoro rozumiemy już Azure Arc jako warstwę zarządzania, przejdźmy do strony infrastruktury: Azure Local. Jeśli Azure Arc to programowa płaszczyzna sterowania, która sięga wszędzie, to Azure Local jest rozwiązaniem hiperkonwergentnej infrastruktury (HCI) przeznaczonym do uruchamiania obciążeń lokalnie, w centrum danych lub na brzegu sieci.

Ta technologia może być znana pod wcześniejszą nazwą: Azure Stack HCI. Firma Microsoft niedawno zmieniła nazwę tej oferty na Azure Local i uprościła ją, aby lepiej odpowiadała jej podstawowej misji. Azure Local zapewnia nowoczesną, programowo definiowaną platformę obliczeniową, pamięci masowej i sieciową, którą uruchamiasz na zweryfikowanych urządzeniach sprzętowych we własnych lokalizacjach.

Architektura Azure Local

Azure Local łączy technologie Windows Server z zaawansowanym oprogramowaniem hiperkonwergentnym, aby zapewnić wirtualizację i pamięć masową klasy korporacyjnej. Do wirtualizacji wykorzystuje Hyper-V, a do wydajnej, programowo definiowanej pamięci masowej – Storage Spaces Direct.

Tym, co naprawdę wyróżnia Azure Local, jest głęboka, natywna integracja z publiczną chmurą Azure od samego początku. Tradycyjne platformy wirtualizacji wymagają narzędzi firm trzecich, aby połączyć się z chmurą, natomiast Azure Local jest domyślnie połączony z chmurą. Pozwala uruchamiać znane maszyny wirtualne z systemami Windows i Linux, a także klastry Azure Kubernetes Service (AKS) lokalnie, na sprzęcie, który fizycznie posiadasz i eksploatujesz.

Kluczowe funkcje Azure Local obejmują:

Wysoka dostępność i odporność: Wbudowane klastrowanie i replikacja pamięci masowej sprawiają, że lokalne obciążenia pozostają uruchomione nawet w razie awarii sprzętu.
Elastyczne formy fizyczne: Od wzmocnionych węzłów brzegowych instalowanych w sklepach detalicznych lub fabrykach po duże, wielowęzłowe klastry w centrach danych przedsiębiorstw – Azure Local skaluje się do dostępnej przestrzeni fizycznej.
Znana wirtualizacja: Jeśli Twój zespół zna już Hyper-V lub ogólne koncepcje wirtualizacji, wdrożenie Azure Local wiąże się z bardzo łagodną krzywą uczenia się.

Kluczowe różnice między zarządzaniem a infrastrukturą

Kiedy słuchacze pytają mnie o porównanie Azure Arc i Azure Local, moim pierwszym celem jest zawsze skorygowanie założenia pytania. Porównywanie Azure Arc z Azure Local jest trochę jak porównywanie pilota do telewizora. To nie są konkurencyjne technologie – działają na zupełnie różnych warstwach stosu IT.

Przeanalizujmy zasadnicze różnice w kilku kluczowych wymiarach:

1. Warstwa stosu

Azure Arc działa w całości na warstwie zarządzania i płaszczyzny sterowania. Jest usługą chmurową, która pozwala organizować, zarządzać i zabezpieczać zasoby. Azure Local działa na warstwie infrastruktury i obliczeń. Jest systemem operacyjnym i platformą hiperkonwergentną, która zapewnia fizyczne i wirtualne zasoby obliczeniowe oraz pamięci masowej, na których faktycznie wykonywane są Twoje aplikacje.

2. Zależność od sprzętu

Ponieważ Azure Arc to narzędzie do zarządzania oparte na agentach, praktycznie nie ma ono zależności sprzętowych. Agenta Arc można zainstalować na pięcioletnim serwerze Dell z przestarzałą wersją systemu Linux, na nowym serwerze HPE z systemem Windows, a nawet na maszynie wirtualnej hostowanej w usłudze AWS. Azure Local natomiast wymaga konkretnego, zweryfikowanego sprzętu od partnerów sprzętowych firmy Microsoft. Nie można po prostu zainstalować Azure Local na dowolnym sprzęcie leżącym w serwerowni; wymaga on certyfikowanych węzłów klastra, aby zapewnić wydajność, niezawodność i możliwość uzyskania wsparcia.

3. Główny cel

Celem Azure Arc jest zunifikowane zarządzanie – wprowadzenie spójności do rozproszonego portfolio IT obejmującego wiele chmur i środowiska lokalne. Celem Azure Local jest unowocześnienie lokalnej infrastruktury – zapewnienie natywnie chmurowej platformy HCI do uruchamiania obciążeń zwirtualizowanych i skonteneryzowanych dokładnie tam, gdzie powstają dane.

Kiedy używać Azure Arc, a kiedy Azure Local

Skoro ustaliliśmy, co robi każde z tych narzędzi, przejdźmy do podejmowania decyzji. Na sesjach planowania architektury: skąd wiadomo, kiedy sięgnąć po Azure Arc, a kiedy wdrożyć Azure Local?

Kiedy używać Azure Arc

Azure Arc warto wdrożyć, gdy chcesz objąć zarządzaniem z Azure infrastrukturę, którą już posiadasz i której nie planujesz wymieniać w najbliższym czasie. Na przykład:

Masz znaczące istniejące inwestycje w serwery VMware lub fizyczne serwery z systemem Linux w wielu globalnych centrach danych i chcesz mieć jeden widok w portalu Azure, aby zarządzać zgodnością, monitorować dzienniki i stosować zasady.
Uruchamiasz klastry Kubernetes w usługach AWS lub Google Cloud i chcesz używać usług Azure GitOps oraz Azure Policy do zarządzania wdrożeniami we wszystkich tych chmurach jednocześnie.
Chcesz uruchamiać usługi danych Azure, takie jak Azure SQL Managed Instance, lokalnie, bez migrowania całego podstawowego stosu wirtualizacji.

Kiedy używać Azure Local

Azure Local warto wdrożyć, gdy chcesz odnowić wiekową lokalną infrastrukturę lub zbudować nowe środowisko przetwarzania brzegowego, a jednocześnie chcesz, aby ta lokalna infrastruktura wyglądała i działała jak rozszerzenie chmury Azure:

Tradycyjna macierz SAN i stos wirtualizacji zbliżają się do końca cyklu życia, a Ty chcesz zastąpić je nowoczesną, programowo definiowaną infrastrukturą hiperkonwergentną, która natywnie integruje się z kopiami zapasowymi, odzyskiwaniem po awarii i monitorowaniem w Azure.
Potrzebujesz obliczeń i pamięci masowej o niskim opóźnieniu w lokalizacji brzegowej – na przykład w szpitalu, sklepie detalicznym lub zakładzie produkcyjnym – gdzie dane muszą być przetwarzane lokalnie, ale chcesz zarządzać tymi obciążeniami centralnie z chmury Azure.
Chcesz uruchamiać Azure Kubernetes Service (AKS) lokalnie, z pełnym wsparciem i bezproblemową integracją z istniejącymi potokami wdrożeniowymi w chmurze.

Jak oba rozwiązania współpracują w strategii hybrydowej

Tu dzieje się prawdziwa magia. Chociaż Azure Arc i Azure Local to odrębne produkty, firma Microsoft zaprojektowała je tak, aby lepiej działały razem. Klastry Azure Local są bowiem domyślnie automatycznie włączane do usługi Azure Arc!

Gdy wdrażasz klaster Azure Local w swoim centrum danych, infrastruktura bazowa jest zarządzana lokalnie, ale jej płaszczyzna sterowania jest w pełni zintegrowana z Azure Arc. Oznacza to, że nie musisz instalować oddzielnych agentów ani konfigurować złożonych tuneli, aby zarządzać infrastrukturą Azure Local – pojawia się ona natywnie w Twojej subskrypcji Azure od chwili jej inicjalizacji.

Przyjrzyjmy się rzeczywistemu scenariuszowi hybrydowemu, aby zobaczyć, jak ta synergia działa w praktyce. Wyobraź sobie dużą, globalną firmę logistyczną:

Na brzegu sieci: Firma prowadzi setki centrów realizacji zamówień na całym świecie. W każdym z nich wdraża małe, dwuwęzłowe urządzenia Azure Local, które przetwarzają etykiety wysyłkowe, uruchamiają lokalne instancje baz danych i zarządzają systemami automatyzacji magazynu z bardzo niskim opóźnieniem.
W całym przedsiębiorstwie: Firma posiada również starsze centra danych z mieszanką serwerów VMware i fizycznych, a także część obciążeń hostowanych w usłudze AWS. Agenty Azure Arc instaluje we wszystkich tych środowiskach, aby egzekwować bazowe zasady bezpieczeństwa i śledzić zgodność.
Zunifikowane zarządzanie: Dzięki portalowi Azure centralny zespół IT może sprawdzać stan brzegowych centrów realizacji (działających na Azure Local) obok swoich instancji AWS i starszych serwerów (zarządzanych za pomocą Azure Arc). Usługi Azure Policy używają do zapewnienia zgodności ze standardami szyfrowania we wszystkich lokalizacjach, a Azure Monitor służy do globalnego śledzenia wskaźników wydajności.

W tej architekturze Azure Local zapewnia odporny na awarie, wysokowydajny fundament na brzegu sieci, natomiast Azure Arc stanowi nadrzędną warstwę zarządzania i kontroli, która spaja całe hybrydowe środowisko w jedną całość.

Podsumowanie: uproszczenie drogi do hybrydowej chmury

Poruszanie się po hybrydowym ekosystemie chmury Microsoftu na pierwszy rzut oka może wydawać się przytłaczające, ale gdy przypiszesz terminologię do konkretnych warstw architektury, wszystko zaczyna mieć sens. Zapamiętaj złotą zasadę: Azure Arc to Twoja płaszczyzna zarządzania i kontroli dla wszystkiego, wszędzie, a Azure Local to nowoczesna infrastruktura hiperkonwergentna dla obciążeń lokalnych i brzegowych.

Planując architekturę przedsiębiorstwa na nadchodzący rok, nie traktuj tych technologii jako wyboru „albo-albo”. Zamiast tego zobacz, jak się wzajemnie uzupełniają. Używaj Azure Arc, aby ujednolicić i zarządzać istniejącymi, zróżnicowanymi inwestycjami IT, a Azure Local wykorzystaj wtedy, gdy chcesz zmodernizować infrastrukturę lokalną i brzegową, zyskując zwinność charakterystyczną dla rozwiązań chmurowych.

Mam nadzieję, że ten szczegółowy przegląd rozwieje wątpliwości dotyczące hybrydowej terminologii Microsoftu. Jak zawsze chętnie usłyszymy Twoje opinie. Czy obecnie używasz Azure Arc w środowiskach wielochmurowych? Czy wdrożyłeś Azure Local w swoich lokalizacjach brzegowych? Zostaw komentarz poniżej lub napisz do nas e-mail, a poruszymy Twoje pytania w kolejnym odcinku skrzynki słuchaczy. Do zobaczenia w następnym odcinku, a tymczasem projektuj architekturę z myślą o przyszłości!