Wirtualne centrum danych: perspektywa sieci

Aplikacje migrowane ze środowiska lokalnego mogą korzystać z bezpiecznej, ekonomicznej infrastruktury platformy Azure, nawet przy minimalnych zmianach aplikacji. Przedsiębiorstwa mogą chcieć dostosować swoje architektury, aby zwiększyć elastyczność i wykorzystać możliwości platformy Azure.

Platforma Microsoft Azure oferuje usługi i infrastrukturę w warstwie Hiperskala z możliwościami i niezawodnością klasy korporacyjnej. Te usługi i infrastruktura oferują wiele opcji łączności hybrydowej, dzięki czemu klienci mogą uzyskiwać do nich dostęp za pośrednictwem Internetu lub prywatnego połączenia sieciowego. Partnerzy firmy Microsoft mogą również zapewnić rozszerzone możliwości, oferując usługi zabezpieczeń i urządzenia wirtualne zoptymalizowane pod kątem uruchamiania na platformie Azure.

Klienci mogą używać platformy Azure do bezproblemowego rozszerzania infrastruktury na chmurę i tworzenia architektur wielowarstwowych.

Co to jest wirtualne centrum danych?

Chmura rozpoczęła się jako platforma do hostowania aplikacji publicznych. Przedsiębiorstwa rozpoznały wartość chmury i zaczęły migrować wewnętrzne aplikacje biznesowe. Te aplikacje przyniosły większe bezpieczeństwo, niezawodność, wydajność i koszty, które wymagały większej elastyczności podczas dostarczania usług w chmurze. Nowe usługi infrastruktury i sieci zostały zaprojektowane w celu zapewnienia elastyczności. Nowe funkcje zapewniają elastyczną skalę, odzyskiwanie po awarii i inne zagadnienia.

Rozwiązania w chmurze zostały początkowo zaprojektowane do hostowania pojedynczych, stosunkowo izolowanych aplikacji w spektrum publicznym, które działały dobrze przez kilka lat. Ponieważ korzyści wynikające z rozwiązań w chmurze stały się jasne, wiele obciążeń na dużą skalę było hostowanych w chmurze. Rozwiązywanie problemów związanych z zabezpieczeniami, niezawodnością, wydajnością i kosztami jest niezbędne dla wdrożenia i cyklu życia usługi w chmurze.

Na poniższym przykładowym diagramie wdrażania w chmurze czerwone pole wyróżnia lukę zabezpieczeń. Żółte pole przedstawia możliwość optymalizacji wirtualnych urządzeń sieciowych między obciążeniami.

Wirtualne centra danych pomagają osiągnąć skalę wymaganą dla obciążeń przedsiębiorstwa. Skala musi sprostać wyzwaniom związanym z uruchamianiem aplikacji na dużą skalę w chmurze publicznej.

Implementacja wirtualnego centrum danych obejmuje więcej niż obciążenia aplikacji w chmurze. Zapewnia również usługi sieciowe, zabezpieczeń, zarządzania, DNS i Active Directory. W miarę migrowania większej liczby obciążeń na platformę Azure przedsiębiorstwa należy wziąć pod uwagę infrastrukturę i obiekty obsługujące te obciążenia. Dobre zarządzanie zasobami pomaga uniknąć wzrostu oddzielnego zarządzanego "wysp obciążenia" z niezależnymi przepływami danych, modelami zabezpieczeń i wyzwaniami dotyczącymi zgodności.

Koncepcja wirtualnego centrum danych zawiera zalecenia i projekty wysokiego poziomu do implementowania kolekcji oddzielnych, ale powiązanych jednostek. Te jednostki często mają typowe funkcje pomocnicze, funkcje i infrastrukturę. Wyświetlanie obciążeń jako wirtualnego centrum danych pomaga zmniejszyć koszty wynikające z korzyści skali. Pomaga również w zoptymalizowaniu zabezpieczeń za pośrednictwem centralizacji składników i przepływu danych oraz łatwiejsze operacje, zarządzanie i inspekcje zgodności.

Uwaga

Wirtualne centrum danych nie jest określoną usługą platformy Azure. Zamiast tego różne funkcje i możliwości platformy Azure są łączone w celu spełnienia wymagań. Wirtualne centrum danych to sposób myślenia o obciążeniach i użyciu platformy Azure w celu zoptymalizowania zasobów i możliwości w chmurze. Zapewnia modułowe podejście do świadczenia usług IT na platformie Azure przy jednoczesnym poszanowaniu ról i obowiązków organizacyjnych przedsiębiorstwa.

Wirtualne centrum danych ułatwia przedsiębiorstwom wdrażanie obciążeń i aplikacji na platformie Azure w następujących scenariuszach:

• Hostowanie wielu powiązanych obciążeń.
• Migrowanie obciążeń ze środowiska lokalnego na platformę Azure.
• Zaimplementuj wymagania dotyczące współużytkowanych lub scentralizowanych wymagań dotyczących zabezpieczeń i dostępu w obciążeniach.
• Wymieszaj metodykę DevOps i odpowiednio scentralizowaną it dla dużego przedsiębiorstwa.

Kto powinien zaimplementować wirtualne centrum danych?

Każdy klient, który decyduje się na wdrożenie platformy Azure, może skorzystać z wydajności konfigurowania zestawu zasobów do wspólnego użycia przez wszystkie aplikacje. W zależności od rozmiaru nawet pojedyncze aplikacje mogą korzystać z wzorców i składników używanych do tworzenia implementacji VDC.

Niektóre organizacje mają scentralizowane zespoły lub działy it, sieci, zabezpieczeń lub zgodności. Implementacja VDC może pomóc w wymuszaniu punktów zasad, oddzielnych obowiązków i zapewnia spójność podstawowych składników. Zespoły aplikacji mogą zachować swobodę i kontrolę, która jest odpowiednia dla ich wymagań.

Organizacje korzystające z metodyki DevOps mogą również korzystać z koncepcji VDC, aby zapewnić autoryzowane kieszenie zasobów platformy Azure. Ta metoda zapewnia, że grupy DevOps mają całkowitą kontrolę w ramach tego grupowania na poziomie subskrypcji lub w grupach zasobów w wspólnej subskrypcji. Jednocześnie granice sieci i zabezpieczeń pozostają zgodne. Zgodność jest definiowana przez scentralizowane zasady w sieci piasty i centralnie zarządzanej grupie zasobów.

Zagadnienia dotyczące implementowania wirtualnego centrum danych

Podczas projektowania wirtualnego centrum danych należy wziąć pod uwagę następujące kluczowe problemy:

Tożsamość i usługa katalogowa

Usługi tożsamości i katalogów są kluczowymi możliwościami zarówno lokalnych, jak i chmurowych centrów danych. Tożsamość obejmuje wszystkie aspekty dostępu i autoryzacji do usług w ramach implementacji VDC. Aby upewnić się, że tylko autoryzowani użytkownicy i procesy uzyskują dostęp do zasobów platformy Azure, platforma Azure używa kilku typów poświadczeń do uwierzytelniania, w tym haseł kont, kluczy kryptograficznych, podpisów cyfrowych i certyfikatów. Uwierzytelnianie wieloskładnikowe firmy Microsoft zapewnia dodatkową warstwę zabezpieczeń na potrzeby uzyskiwania dostępu do usług platformy Azure. Silne uwierzytelnianie z szeregiem łatwych opcji weryfikacji (połączenie telefoniczne, wiadomość SMS lub powiadomienie aplikacji mobilnej) umożliwia klientom wybór preferowanej metody.

Duże przedsiębiorstwa muszą definiować procesy zarządzania tożsamościami, które opisują zarządzanie poszczególnymi tożsamościami, ich uwierzytelnianie, autoryzację, role i uprawnienia w obrębie lub w obrębie VDC. Cele tego procesu mogą zwiększyć bezpieczeństwo i produktywność, jednocześnie zmniejszając koszty, przestoje i powtarzalne zadania ręczne.

Organizacje przedsiębiorstwa mogą wymagać wymagającej kombinacji usług dla różnych linii biznesowych. Pracownicy często mają różne role w przypadku różnych projektów. VDC wymaga dobrej współpracy między różnymi zespołami, z których każda ma określone definicje ról, aby systemy działały z dobrym ładem. Macierz obowiązków, dostępu i praw może być złożona. Zarządzanie tożsamościami na VDC jest implementowane za pomocą identyfikatora Entra firmy Microsoft i kontroli dostępu opartej na rolach platformy Azure (Azure RBAC).

Usługa katalogowa to udostępniona infrastruktura informacyjna, która lokalizuje, zarządza, zarządza i organizuje codzienne elementy i zasoby sieciowe oraz zarządza nimi. Te zasoby mogą obejmować woluminy, foldery, pliki, drukarki, użytkowników, grupy, urządzenia i inne obiekty. Każdy zasób w sieci jest uznawany za obiekt przez serwer katalogu. Informacje o zasobie są przechowywane jako kolekcja atrybutów skojarzonych z tym zasobem lub obiektem.

Wszystkie usługi biznesowe online firmy Microsoft opierają się na identyfikatorze Entra firmy Microsoft na potrzeby logowania i innych potrzeb związanych z tożsamością. Microsoft Entra ID to kompleksowe, wysoce dostępne rozwiązanie do zarządzania tożsamościami i dostępem w chmurze, które łączy podstawowe usługi katalogowe, zaawansowane zarządzanie tożsamościami i zarządzanie dostępem do aplikacji. Identyfikator Entra firmy Microsoft może integrować się z lokalna usługa Active Directory, aby włączyć logowanie jednokrotne dla wszystkich aplikacji lokalnych hostowanych w chmurze i lokalnie. Atrybuty użytkownika lokalna usługa Active Directory można automatycznie synchronizować z identyfikatorem Entra firmy Microsoft.

Każdy konkretny dział, grupa użytkowników lub usługi w usłudze katalogowej musi mieć minimalne uprawnienia wymagane do zarządzania własnymi zasobami w ramach implementacji VDC. Tworzenie struktury uprawnień wymaga równoważenia. Zbyt wiele uprawnień może utrudniać wydajność, a zbyt mało lub luźne uprawnienia mogą zwiększyć ryzyko bezpieczeństwa. Kontrola dostępu oparta na rolach platformy Azure (RBAC) platformy Azure pomaga rozwiązać ten problem, oferując szczegółowe zarządzanie dostępem dla zasobów w implementacji VDC.

Infrastruktura zabezpieczeń

Infrastruktura zabezpieczeń odnosi się do podziału ruchu w określonym segmencie sieci wirtualnej implementacji VDC. Ta infrastruktura określa, jak ruch przychodzący i wychodzący są kontrolowane w implementacji VDC. Platforma Azure jest oparta na architekturze wielodostępnej, która uniemożliwia nieautoryzowany i niezamierzony ruch między wdrożeniami. Odbywa się to przy użyciu izolacji sieci wirtualnej, list kontroli dostępu, modułów równoważenia obciążenia, filtrów adresów IP i zasad przepływu ruchu. Translator adresów sieciowych oddziela ruch sieciowy od ruchu zewnętrznego.

Sieć szkieletowa platformy Azure przydziela zasoby infrastruktury do obciążeń dzierżawy i zarządza komunikacją z maszynami wirtualnymi i z tych maszyn. Funkcja hypervisor platformy Azure wymusza separację pamięci i procesów między maszynami wirtualnymi i bezpiecznie kieruje ruch sieciowy do dzierżaw systemu operacyjnego gościa.

Łączność z chmurą

Wirtualne centrum danych wymaga łączności z sieciami zewnętrznymi w celu oferowania usług klientom, partnerom lub użytkownikom wewnętrznym. Ta potrzeba łączności odnosi się nie tylko do Internetu, ale także do sieci lokalnych i centrów danych.

Klienci kontrolują usługi, do których można uzyskiwać dostęp i uzyskiwać dostęp z publicznego Internetu. Ten dostęp jest kontrolowany przy użyciu usługi Azure Firewall lub innych typów wirtualnych urządzeń sieciowych (WUS), niestandardowych zasad routingu przy użyciu tras zdefiniowanych przez użytkownika i filtrowania sieci przy użyciu sieciowych grup zabezpieczeń. Zalecamy, aby wszystkie zasoby dostępne z Internetu są chronione przez usługę Azure DDoS Protection.

Przedsiębiorstwa mogą wymagać połączenia wirtualnego centrum danych z lokalnymi centrami danych lub innymi zasobami. Ta łączność między platformą Azure i sieciami lokalnymi jest kluczowym aspektem projektowania efektywnej architektury. Przedsiębiorstwa mają dwa różne sposoby tworzenia tych połączeń: tranzyt przez Internet lub za pośrednictwem prywatnych połączeń bezpośrednich.

Sieć VPN typu lokacja-lokacja platformy Azure łączy sieci lokalne z wirtualnym centrum danych na platformie Azure. Link jest ustanawiany za pośrednictwem bezpiecznych szyfrowanych połączeń (tunele IPsec). Połączenia sieci VPN typu lokacja-lokacja platformy Azure są elastyczne, szybkie do utworzenia i zwykle nie wymagają więcej zakupów sprzętowych. Na podstawie standardowych protokołów branżowych większość bieżących urządzeń sieciowych może tworzyć połączenia sieci VPN z platformą Azure przez Internet lub istniejące ścieżki łączności.

Usługa ExpressRoute umożliwia połączenia prywatne między wirtualnym centrum danych a dowolnymi sieciami lokalnymi. Połączenia usługi ExpressRoute nie przechodzą przez publiczny Internet i zapewniają większe bezpieczeństwo, niezawodność i większe szybkości (do 100 Gb/s) oraz spójne opóźnienia. Usługa ExpressRoute zapewnia korzyści wynikające z reguł zgodności skojarzonych z połączeniami prywatnymi. Za pomocą usługi ExpressRoute Direct można łączyć się bezpośrednio z routerami firmy Microsoft przy użyciu szybkości 10 Gb/s lub 100 Gb/s.

Wdrażanie połączeń usługi ExpressRoute zwykle wiąże się z angażowaniem się z dostawcą usługi ExpressRoute (usługa ExpressRoute Direct jest wyjątkiem). W przypadku klientów, którzy muszą szybko rozpocząć pracę, często używa się sieci VPN typu lokacja-lokacja do nawiązywania łączności między wirtualnym centrum danych a zasobami lokalnymi. Po zakończeniu fizycznego połączenia z dostawcą usług zmigruj łączność za pośrednictwem połączenia usługi ExpressRoute.

W przypadku dużej liczby połączeń sieci VPN lub usługi ExpressRoute usługa Azure Virtual WAN to usługa sieciowa, która zapewnia zoptymalizowaną i zautomatyzowaną łączność między oddziałami za pośrednictwem platformy Azure. Usługa Virtual WAN umożliwia nawiązywanie połączeń z platformą Azure i konfigurowanie urządzeń oddziałów w celu komunikowania się z platformą Azure. Łączenie i konfigurowanie można wykonać ręcznie lub przy użyciu preferowanych urządzeń dostawcy za pośrednictwem partnera usługi Virtual WAN. Korzystanie z preferowanych urządzeń dostawcy umożliwia łatwe użycie, uproszczenie łączności i zarządzanie konfiguracją. Wbudowany pulpit nawigacyjny usługi Azure WAN zapewnia błyskawiczne szczegółowe informacje dotyczące rozwiązywania problemów, które mogą pomóc zaoszczędzić czas i umożliwiają łatwe wyświetlanie łączności typu lokacja-lokacja na dużą skalę. Usługa Virtual WAN udostępnia również usługi zabezpieczeń z opcjonalną usługą Azure Firewall i menedżerem zapory w koncentratorze usługi Virtual WAN.

Łączność w chmurze

Sieci wirtualne platformy Azure i komunikacja równorzędna sieci wirtualnych to podstawowe składniki sieciowe w wirtualnym centrum danych. Sieć wirtualna gwarantuje granicę izolacji dla wirtualnych zasobów centrum danych. Komunikacja równorzędna umożliwia komunikację między różnymi sieciami wirtualnymi w tym samym regionie świadczenia usługi Azure, między regionami, a nawet między sieciami w różnych subskrypcjach. Przepływy ruchu mogą być kontrolowane wewnątrz i między sieciami wirtualnymi przez zestawy reguł zabezpieczeń określonych dla sieciowych grup zabezpieczeń, zasad zapory (usługi Azure Firewall lub wirtualnych urządzeń sieciowych) oraz niestandardowych tras zdefiniowanych przez użytkownika.

Sieci wirtualne to punkty zakotwiczenia integracji produktów platformy jako usługi (PaaS) platformy Azure, takich jak Azure Storage, Azure SQL i inne zintegrowane usługi publiczne z publicznymi punktami końcowymi. Za pomocą punktów końcowych usługi i usługi Azure Private Link możesz zintegrować usługi publiczne z siecią prywatną. Możesz nawet korzystać z usług publicznych prywatnych, ale nadal korzystać z zalet usług PaaS zarządzanych przez platformę Azure.

Omówienie wirtualnego centrum danych

Topologie

Wirtualne centrum danych można utworzyć przy użyciu jednej z tych topologii wysokiego poziomu na podstawie Twoich potrzeb i wymagań dotyczących skalowania:

W topologii płaskiej wszystkie zasoby są wdrażane w jednej sieci wirtualnej. Podsieci umożliwiają sterowanie przepływem i segregację.

W topologii usługi Mesh komunikacja równorzędna sieci wirtualnych łączy wszystkie sieci wirtualne bezpośrednio ze sobą.

Topologia piasty komunikacji równorzędnej i szprych jest odpowiednia dla aplikacji rozproszonych i zespołów z delegowanymi obowiązkami.

Topologia usługi Azure Virtual WAN może obsługiwać scenariusze biura oddziału na dużą skalę i globalne usługi WAN.

Topologia koncentratora komunikacji równorzędnej i szprych oraz topologia usługi Azure Virtual WAN używają projektu piasty i szprych, który jest optymalny dla komunikacji, udostępnionych zasobów i scentralizowanych zasad zabezpieczeń. Koncentratory są tworzone przy użyciu koncentratora komunikacji równorzędnej sieci wirtualnej (oznaczonego jako Hub Virtual Network na diagramie) lub koncentratora usługi Virtual WAN (oznaczonego jako Azure Virtual WAN na diagramie). Usługa Azure Virtual WAN została zaprojektowana pod kątem komunikacji między oddziałami i oddziałami na platformę Azure lub pozwala uniknąć złożoności tworzenia wszystkich składników osobno w koncentratorze komunikacji równorzędnej sieci wirtualnych. W niektórych przypadkach wymagania mogą wymagać projektowania koncentratora komunikacji równorzędnej sieci wirtualnych, takiego jak potrzeba użycia wirtualnych urządzeń sieciowych w koncentratonie.

W topologii piasty i szprych piasta jest centralną strefą sieciową, która kontroluje i sprawdza cały ruch między różnymi strefami, takimi jak Internet, lokalnie i szprychy. Topologia piasty i szprych pomaga działowi IT centralnie wymuszać zasady zabezpieczeń. Minimalizuje również ryzyko błędnej konfiguracji i ekspozycji.

Piasta często zawiera typowe składniki usługi używane przez szprychy. Poniżej przedstawiono typowe usługi centralne:

• Infrastruktura usługi Active Directory systemu Windows jest wymagana do uwierzytelniania użytkowników innych firm, które uzyskują dostęp z niezaufanych sieci przed uzyskaniem dostępu do obciążeń w szprychy. Obejmuje ona powiązane usługi Active Directory Federation Services (AD FS)
• Usługa rozproszonego systemu nazw (DNS) służy do rozpoznawania nazw obciążenia w szprychach i uzyskiwania dostępu do zasobów lokalnych i w Internecie, jeśli usługa Azure DNS nie jest używana
• Infrastruktura kluczy publicznych (PKI) służy do implementowania obciążeń logowania jednokrotnego
• Sterowanie przepływem ruchu TCP i UDP między strefami sieci szprychy a Internetem
• Sterowanie przepływem między szprychami i środowiskiem lokalnym
• W razie potrzeby sterowanie przepływem między jedną szprychą a drugą

Wirtualne centrum danych zmniejsza całkowity koszt dzięki użyciu współużytkowanej infrastruktury piasty między wieloma szprychami.

Rolą każdej szprychy może być hostowanie różnych typów obciążeń. Szprychy zapewniają również modularne podejście do powtarzających się wdrożeń tych samych obciążeń. Przykłady obejmują tworzenie i testowanie, testowanie akceptacyjne użytkowników, przedprodukcję i produkcję. Szprychy mogą również dzielić różne grupy w obrębie organizacji i umożliwiać ich tworzenie. Grupy DevOps są dobrym przykładem tego, co mogą zrobić szprychy. Wewnątrz szprychy można wdrażać podstawowe obciążenia lub złożone obciążenia wielowarstwowe z kontrolą ruchu między warstwami.

Ograniczenia subskrypcji i wiele piast

Ważne

Na podstawie rozmiaru wdrożeń platformy Azure może być potrzebna strategia wielu centrów. Podczas projektowania strategii piasty i szprych zapytaj "Czy ta skala projektu może używać innej sieci wirtualnej koncentratora w tym regionie?" i "Czy ten projekt może być skalowany w wielu regionach?" O wiele lepiej jest zaplanować projekt, który skaluje się i nie potrzebuje go, niż planować i potrzebować go.

Skalowanie do pomocniczego (lub większej liczby) centrum zależy od kilku czynników, zwykle na podstawie ograniczeń z natury na dużą skalę. Pamiętaj, aby przejrzeć limity subskrypcji, sieci wirtualnej i maszyny wirtualnej podczas projektowania pod kątem skalowania.

Na platformie Azure każdy składnik, niezależnie od typu, jest wdrażany w ramach subskrypcji platformy Azure. Izolacja składników platformy Azure w różnych subskrypcjach platformy Azure może spełniać różne wymagania biznesowe, takie jak konfigurowanie różnych poziomów dostępu i autoryzacji.

Pojedyncza implementacja VDC może skalować w górę dużą liczbę szprych. Chociaż, podobnie jak w przypadku każdego systemu IT, istnieją limity platformy. Wdrożenie centrum jest powiązane z określoną subskrypcją platformy Azure, która ma ograniczenia i limity (na przykład maksymalną liczbę komunikacji równorzędnej sieci wirtualnych. Aby uzyskać szczegółowe informacje, zobacz Azure subscription and service limits, quotas, and constraints (Limity, limity przydziału i ograniczenia usługi platformy Azure). W przypadkach, gdy limity mogą być problemem, architektura może być skalowana w górę, rozszerzając model z jednej szprychy do klastra piasty i szprych. Wiele koncentratorów w co najmniej jednym regionie świadczenia usługi Azure można połączyć za pomocą komunikacji równorzędnej sieci wirtualnych, usługi ExpressRoute, wirtualnej sieci WAN lub sieci VPN typu lokacja-lokacja.

Wprowadzenie wielu koncentratorów zwiększa nakład pracy nad kosztami i zarządzaniem systemem. Jest to uzasadnione tylko ze względu na skalowalność, limity systemu, nadmiarowość, replikację regionalną na potrzeby wydajności użytkownika końcowego lub odzyskiwanie po awarii. W scenariuszach wymagających wielu centrów wszystkie centra powinny dążyć do oferowania tego samego zestawu usług w celu ułatwienia działania.

Wzajemne połączenia między szprychami

Wewnątrz jednej szprychy lub płaskiej konstrukcji sieci można zaimplementować złożone obciążenia wielowarstwowe. Konfiguracje wielowarstwowe można zaimplementować przy użyciu podsieci, które są jednym dla każdej warstwy lub aplikacji w tej samej sieci wirtualnej. Sterowanie ruchem i filtrowanie odbywa się przy użyciu sieciowych grup zabezpieczeń i tras zdefiniowanych przez użytkownika.

Architekt może chcieć wdrożyć obciążenie wielowarstwowe w wielu sieciach wirtualnych. Dzięki komunikacji równorzędnej sieci wirtualnych szprychy mogą łączyć się z innymi szprychami w tym samym centrum lub różnych piastach. Typowym przykładem tego scenariusza jest sytuacja, w której serwery przetwarzania aplikacji znajdują się w jednej szprychy lub w sieci wirtualnej. Baza danych jest wdrażana w innej szprychy lub sieci wirtualnej. W takim przypadku łatwo jest połączyć szprychy z komunikacją równorzędną sieci wirtualnych, co pozwala uniknąć przesyłania przez koncentrator. Wykonaj staranną architekturę i przegląd zabezpieczeń, aby upewnić się, że pomijanie centrum nie pomija ważnych punktów zabezpieczeń ani inspekcji, które mogą istnieć tylko w centrum.

Szprychy mogą również łączyć się ze szprychą, która działa jako piasta. To podejście tworzy hierarchię dwu poziomów. Szprycha na wyższym poziomie (poziom 0) staje się piastą niższych szprych (poziom 1) hierarchii. Szprychy implementacji VDC są wymagane do przekazywania ruchu do centralnego koncentratora. Ruch może następnie być przesyłany do miejsca docelowego w sieci lokalnej lub w publicznym Internecie. Architektura z dwoma poziomami piast wprowadza złożony routing, który eliminuje korzyści wynikające z prostej relacji piasty i szprych.

Chociaż platforma Azure umożliwia złożone topologie, jedną z podstawowych zasad koncepcji VDC jest powtarzalność i prostota. Aby zminimalizować nakład pracy w zakresie zarządzania, prosta konstrukcja piasty i szprych to architektura referencyjna VDC zalecana przez nas.

Składniki

Wirtualne centrum danych składa się z czterech podstawowych typów składników: Infrastruktura, Sieci obwodowe, Obciążenia i Monitorowanie.

Każdy typ składnika składa się z różnych funkcji i zasobów platformy Azure. Implementacja VDC składa się z wystąpień wielu typów składników i wielu odmian tego samego typu składnika. Na przykład może istnieć wiele różnych, logicznie oddzielonych wystąpień obciążeń reprezentujących różne aplikacje. Te różne typy składników i wystąpienia są używane do kompilowania VDC.

Poprzednia architektura koncepcyjna wysokiego poziomu VDC przedstawia różne typy składników używane w różnych strefach topologii piasty i szprych. Diagram przedstawia składniki infrastruktury w różnych częściach architektury.

Ogólnie rzecz biorąc, prawa dostępu i uprawnienia mogą być oparte na grupach. Obsługa grup, a nie poszczególnych użytkowników ułatwia konserwację zasad dostępu, zapewniając spójny sposób zarządzania nimi między zespołami, co pomaga zminimalizować błędy konfiguracji. Przypisywanie i usuwanie użytkowników do i z odpowiednich grup pomaga zachować aktualne uprawnienia określonego użytkownika.

Każda grupa ról może mieć unikatowy prefiks nazw. Ten prefiks ułatwia identyfikowanie obciążenia, z którym jest skojarzona grupa. Na przykład obciążenie obsługujące usługę uwierzytelniania może mieć grupy o nazwach AuthServiceNetOps, AuthServiceSecOps, AuthServiceDevOps i AuthServiceInfraOps. Role scentralizowane lub role, które nie są powiązane z określoną usługą, mogą być poprzedzone aplikacją Corp. Przykładem jest CorpNetOps.

Wiele organizacji używa odmiany następujących grup w celu zapewnienia poważnego podziału ról:

• Centralny zespół IT o nazwie Corp ma prawa własności do kontrolowania składników infrastruktury. Przykłady to sieć i zabezpieczenia. Grupa musi mieć rolę współautora w subskrypcji, kontroli nad piastą i uprawnieniami współautora sieci w szprychach. Duże organizacje często dzielą te obowiązki związane z zarządzaniem między wieloma zespołami. Przykłady to grupa operacji sieciowych CorpNetOps z wyłącznym naciskiem na sieć i operacje zabezpieczeń grupy CorpSecOps odpowiedzialnej za zaporę i zasady zabezpieczeń. W tym konkretnym przypadku należy utworzyć dwie różne grupy do przypisania tych ról niestandardowych.
• Grupa tworzenia i testowania o nazwie AppDevOps ponosi odpowiedzialność za wdrażanie obciążeń aplikacji lub usług. Ta grupa pełni rolę współautora maszyny wirtualnej dla wdrożeń IaaS lub co najmniej jednej roli współautora usługi PaaS. Aby uzyskać więcej informacji, zobacz Role wbudowane platformy Azure. Opcjonalnie zespół deweloperów/testów może potrzebować wglądu w zasady zabezpieczeń (sieciowe grupy zabezpieczeń) i zasady routingu (trasy zdefiniowane przez użytkownika) wewnątrz centrum lub określonej szprychy. Oprócz roli współautora dla obciążeń ta grupa będzie również potrzebować roli czytelnika sieci.
• Grupa operacji i konserwacji o nazwie CorpInfraOps lub AppInfraOps ponosi odpowiedzialność za zarządzanie obciążeniami w środowisku produkcyjnym. Ta grupa musi być współautorem subskrypcji na obciążeniach w dowolnej subskrypcji produkcyjnej. Niektóre organizacje mogą również ocenić, czy potrzebują grupy zespołu pomocy technicznej eskalacji z rolą współautora subskrypcji w środowisku produkcyjnym i centralnej subskrypcji centrum. Druga grupa rozwiązuje potencjalne problemy z konfiguracją w środowisku produkcyjnym.

VDC został zaprojektowany tak, aby centralne grupy zespołów IT, które zarządzają centrum, miały odpowiednie grupy na poziomie obciążenia. Oprócz zarządzania zasobami centrum centralny zespół IT może kontrolować dostęp zewnętrzny i uprawnienia najwyższego poziomu w ramach subskrypcji. Grupy obciążeń mogą również kontrolować zasoby i uprawnienia swojej sieci wirtualnej niezależnie od centralnego zespołu IT.

Wirtualne centrum danych jest partycjonowane w celu bezpiecznego hostowania wielu projektów w różnych liniach biznesowych. Wszystkie projekty wymagają różnych środowisk izolowanych (deweloperskich, UAT i produkcyjnych). Oddzielne subskrypcje platformy Azure dla każdego z tych środowisk mogą zapewnić naturalną izolację.

Na powyższym diagramie przedstawiono relację między projektami organizacji, użytkownikami, grupami i środowiskami, w których wdrażane są składniki platformy Azure.

Zazwyczaj w it środowisko (lub warstwa) to system, w którym wdrożono i wykonano wiele aplikacji. Duże przedsiębiorstwa używają środowiska programistycznego (w którym zmiany są wprowadzane i testowane) oraz środowiska produkcyjnego (z którego korzystają użytkownicy końcowi). Te środowiska są oddzielone, często z kilkoma środowiskami przejściowymi między nimi, aby umożliwić wdrożenie etapowe (wdrożenie), testowanie i wycofywanie, jeśli wystąpią problemy. Architektury wdrażania różnią się znacznie, ale zwykle następuje podstawowy proces rozpoczynania programowania (DEV) i zakończenia procesu produkcyjnego (PROD).

Typowa architektura dla tych typów środowisk wielowarstwowych obejmuje metodykę DevOps na potrzeby programowania i testowania, funkcji zdefiniowanej przez użytkownika dla środowiska przejściowego i produkcyjnego. Organizacje mogą używać jednej lub wielu dzierżaw firmy Microsoft Entra do definiowania dostępu i praw do tych środowisk. Na poprzednim diagramie przedstawiono przypadek, w którym są używane dwie różne dzierżawy firmy Microsoft Entra: jedna dla metodyki DevOps i UAT, a druga wyłącznie dla środowiska produkcyjnego.

Obecność różnych dzierżaw firmy Microsoft Entra wymusza separację między środowiskami. Ta sama grupa użytkowników, takich jak centralny zespół IT, musi uwierzytelniać się przy użyciu innego identyfikatora URI, aby uzyskać dostęp do innej dzierżawy firmy Microsoft Entra. Dzięki temu zespół może modyfikować role lub uprawnienia środowiska DevOps lub środowiska produkcyjne projektu. Obecność różnych uwierzytelniania użytkowników w celu uzyskania dostępu do różnych środowisk zmniejsza możliwe awarie i inne problemy spowodowane przez błędy ludzkie.

Typ składnika: infrastruktura

Ten typ składnika to miejsce, w którym znajduje się większość infrastruktury pomocniczej. Jest to również miejsce, w którym scentralizowane zespoły IT, zabezpieczeń i zgodności spędzają większość czasu.

Składniki infrastruktury zapewniają wzajemne połączenia dla różnych składników implementacji VDC i znajdują się zarówno w piastze, jak i szprychach. Odpowiedzialność za zarządzanie i utrzymywanie składników infrastruktury jest zwykle przypisywana do centralnego zespołu IT lub zespołu ds. zabezpieczeń.

Jednym z głównych zadań zespołu infrastruktury IT jest zagwarantowanie spójności schematów adresów IP w całym przedsiębiorstwie. Prywatna przestrzeń adresowa IP przypisana do implementacji VDC musi być spójna i nie nakładać się na prywatne adresy IP przypisane w sieciach lokalnych.

Translator adresów sieciowych na lokalnych routerach brzegowych lub w środowiskach platformy Azure może uniknąć konfliktów adresów IP, ale dodaje komplikacje do składników infrastruktury. Prostota zarządzania jest jednym z kluczowych celów VDC. Używanie translatora adresów sieciowych do obsługi problemów z adresami IP, chociaż prawidłowe rozwiązanie, nie jest zalecanym rozwiązaniem.

Składniki infrastruktury mają następujące funkcje:

• Tożsamości i usługi katalogowe: dostęp do każdego typu zasobu na platformie Azure jest kontrolowany przez tożsamość przechowywaną w usłudze katalogowej. Usługa katalogowa przechowuje nie tylko listę użytkowników, ale także prawa dostępu do zasobów w określonej subskrypcji platformy Azure. Te usługi mogą istnieć w chmurze lub mogą być synchronizowane z tożsamością lokalną przechowywaną w usłudze Active Directory.
• Sieci wirtualne: Sieci wirtualne są jednym z głównych składników VDC i umożliwiają utworzenie granicy izolacji ruchu na platformie Azure. Sieć wirtualna składa się z jednego lub wielu segmentów sieci wirtualnej, z których każdy ma określony prefiks sieci IP (podsieć: IPv4 lub podwójny stos IPv4/IPv6). Sieć wirtualna definiuje wewnętrzny obszar obwodowy, w którym maszyny wirtualne IaaS i usługi PaaS mogą ustanowić prywatną komunikację. Maszyny wirtualne (i usługi PaaS) w jednej sieci wirtualnej nie mogą komunikować się bezpośrednio z maszynami wirtualnymi (i usługami PaaS) w innej sieci wirtualnej. Jest to prawdą, nawet jeśli obie sieci wirtualne są tworzone przez tego samego klienta, w ramach tej samej subskrypcji. Izolacja to właściwość krytyczna, która zapewnia, że maszyny wirtualne klienta i komunikacja pozostają prywatne w sieci wirtualnej. Jeśli jest wymagana łączność między sieciami, następujące funkcje opisują, jak można to osiągnąć.
• Komunikacja równorzędna sieci wirtualnych: podstawową funkcją używaną do tworzenia infrastruktury VDC jest komunikacja równorzędna sieci wirtualnych, która łączy dwie sieci wirtualne w tym samym regionie. To połączenie odbywa się za pośrednictwem sieci centrum danych platformy Azure lub korzystania z sieci szkieletowej platformy Azure na całym świecie w różnych regionach.
• Punkty końcowe usługi sieci wirtualnej: punkty końcowe usługi rozszerzają prywatną przestrzeń adresową sieci wirtualnej w celu uwzględnienia przestrzeni PaaS. Punkty końcowe rozszerzają również tożsamość sieci wirtualnej na usługi platformy Azure za pośrednictwem bezpośredniego połączenia. Punkty końcowe umożliwiają zabezpieczanie krytycznych zasobów usługi platformy Azure w sieciach wirtualnych.
• Usługa Private Link: usługa Azure Private Link umożliwia dostęp do usług Azure PaaS (na przykład Azure Storage, Azure Cosmos DB i Azure SQL Database) oraz hostowanych przez platformę Azure usług klientów/partnerów za pośrednictwem prywatnego punktu końcowego w sieci wirtualnej. Ruch między siecią wirtualną a usługą odbywa się za pośrednictwem sieci szkieletowej firmy Microsoft, eliminując ekspozycję z publicznego Internetu. Możesz również utworzyć własną usługę Private Link w sieci wirtualnej i dostarczyć ją prywatnie klientom. Środowisko konfiguracji i użycia przy użyciu usługi Azure Private Link jest spójne w usługach PaaS platformy Azure, należących do klienta i udostępnionych usługach partnerskich.
• Trasy zdefiniowane przez użytkownika: ruch w sieci wirtualnej jest domyślnie kierowany na podstawie tabeli routingu systemu. Trasa zdefiniowana przez użytkownika to niestandardowa tabela routingu, którą administratorzy sieci mogą skojarzyć z co najmniej jedną podsiecią, aby zastąpić zachowanie tabeli routingu systemu i zdefiniować ścieżkę komunikacji w sieci wirtualnej. Obecność tras zdefiniowanych przez użytkownika gwarantuje ruch z przesyłania szprych przez określone niestandardowe maszyny wirtualne lub wirtualne urządzenia sieciowe oraz moduły równoważenia obciążenia obecne zarówno w piastze, jak i szprychach.
• Sieciowe grupy zabezpieczeń: sieciowa grupa zabezpieczeń to lista reguł zabezpieczeń, które działają jako filtrowanie ruchu w źródłach adresów IP, miejscach docelowych IP, protokołach, portach źródłowych IP i portach docelowych IP (nazywanych również pięcioma krotkami warstwy 4). Sieciową grupę zabezpieczeń można zastosować do podsieci, wirtualnej karty sieciowej skojarzonej z maszyną wirtualną platformy Azure lub obu tych elementów. Sieciowe grupy zabezpieczeń są niezbędne do zaimplementowania prawidłowego sterowania przepływem w koncentratonie i w szprychach. Poziom zabezpieczeń zapewniany przez sieciową grupę zabezpieczeń jest funkcją otwartych portów i w jakim celu. Klienci mogą stosować więcej filtrów dla poszczególnych maszyn wirtualnych za pomocą zapór opartych na hoście, takich jak iptables lub Zapora systemu Windows.
• DNS: usługa DNS zapewnia rozpoznawanie nazw dla zasobów w wirtualnym centrum danych. Platforma Azure udostępnia usługi DNS na potrzeby rozpoznawania nazw publicznych i prywatnych . Strefy prywatne zapewniają rozpoznawanie nazw w sieci wirtualnej i w sieciach wirtualnych. Strefy prywatne mogą obejmować wiele sieci wirtualnych w tym samym regionie oraz między regionami i subskrypcjami. W przypadku rozpoznawania publicznego usługa Azure DNS udostępnia usługę hostingu dla domen DNS, zapewniając rozpoznawanie nazw przy użyciu infrastruktury platformy Microsoft Azure. Dzięki hostowaniu swoich domen na platformie Azure możesz zarządzać rekordami DNS z zastosowaniem tych samych poświadczeń, interfejsów API, narzędzi i rozliczeń co w przypadku innych usług platformy Azure.
• Zarządzanie grupą zarządzania, subskrypcją i grupą zasobów. Subskrypcja definiuje naturalną granicę, aby utworzyć wiele grup zasobów na platformie Azure. To rozdzielenie może dotyczyć funkcji, segregacji ról lub rozliczeń. Zasoby w subskrypcji są zbierane razem w kontenerach logicznych nazywanych grupami zasobów. Grupa zasobów reprezentuje grupę logiczną do organizowania zasobów w wirtualnym centrum danych. Jeśli Twoja organizacja ma wiele subskrypcji, konieczny może być sposób na wydajne zarządzanie dostępem, zasadami i zgodnością dla tych subskrypcji. Grupy zarządzania platformy Azure zapewniają poziom zakresu powyżej subskrypcji. Subskrypcje można organizować w kontenery znane jako grupy zarządzania i stosować warunki ładu do grup zarządzania. Wszystkie subskrypcje w grupie zarządzania automatycznie dziedziczą warunki zastosowane do tej grupy zarządzania. Aby wyświetlić te trzy funkcje w widoku hierarchii, zobacz Organizowanie zasobów w przewodniku Cloud Adoption Framework.
• Kontrola dostępu oparta na rolach platformy Azure (RBAC) platformy Azure: kontrola dostępu oparta na rolach platformy Azure może mapować role organizacyjne i prawa dostępu do określonych zasobów platformy Azure. Dzięki temu można ograniczyć użytkowników tylko do określonego podzestawu akcji. Jeśli synchronizujesz identyfikator entra firmy Microsoft z lokalna usługa Active Directory, możesz użyć tych samych grup usługi Active Directory na platformie Azure, które są używane lokalnie. Dzięki kontroli dostępu opartej na rolach platformy Azure można udzielić dostępu, przypisując odpowiednią rolę użytkownikom, grupom i aplikacjom w odpowiednim zakresie. Zakres przypisania roli może być subskrypcją platformy Azure, grupą zasobów lub pojedynczym zasobem. Kontrola dostępu oparta na rolach platformy Azure umożliwia dziedziczenie uprawnień. Rola przypisana w zakresie nadrzędnym przyznaje również dostęp do zawartych w nim elementów podrzędnych. Dzięki kontroli dostępu opartej na rolach platformy Azure możesz segregować obowiązki i udzielać tylko użytkownikom, których potrzebują do wykonywania swoich zadań. Na przykład jeden pracownik może zarządzać maszynami wirtualnymi w ramach subskrypcji, podczas gdy inny może zarządzać bazami danych programu SQL Server w tej samej subskrypcji.

Typ składnika: sieci obwodowe

Składniki sieci obwodowej (nazywanej czasem siecią DMZ) łączą lokalne lub fizyczne sieci centrum danych wraz z dowolną łącznością z Internetem. Obwód zazwyczaj wymaga znacznego czasu inwestycji ze strony zespołów ds. sieci i zabezpieczeń.

Pakiety przychodzące mogą przepływać przez urządzenia zabezpieczające w centrum przed dotarciem do serwerów zaplecza i usług w szprychach. Przykłady obejmują zaporę, identyfikatory i adresy IP. Przed opuszczeniem sieci pakiety powiązane z Internetem z obciążeń mogą również przepływać przez urządzenia zabezpieczeń w sieci obwodowej. Ten przepływ umożliwia wymuszanie, inspekcję i inspekcję zasad.

Składniki sieci obwodowej obejmują:

• Sieci wirtualne, trasy definiowane przez użytkownika oraz sieciowe grupy zabezpieczeń
• Wirtualne urządzenia sieciowe
• Azure Load Balancer
• aplikacja systemu Azure Gateway z zaporą aplikacji internetowej (WAF)
• Publiczne adresy IP
• Usługa Azure Front Door z zaporą aplikacji internetowej (WAF)
• Azure Firewall i Azure Firewall Manager
• Standardowa ochrona przed atakami DDoS

Zazwyczaj centralny zespół IT i zespoły ds. zabezpieczeń ponoszą odpowiedzialność za definicję wymagań i działanie sieci obwodowych.

Na powyższym diagramie przedstawiono wymuszanie dwóch obwodów z dostępem do Internetu i sieci lokalnej, zarówno w centrum DMZ. W centrum DMZ sieć obwodowa do Internetu może być skalowana w górę w celu obsługi wielu linii biznesowych przy użyciu wielu farm zapór aplikacji internetowych (WAFs) lub usługi Azure Firewalls. Centrum umożliwia również łączność lokalną za pośrednictwem sieci VPN lub usługi ExpressRoute zgodnie z potrzebami.

Uwaga

Na powyższym diagramie w DMZ Hubsystemie wiele z następujących funkcji można połączyć ze sobą w koncentratorze usługi Azure Virtual WAN (na przykład sieci wirtualne, trasy zdefiniowane przez użytkownika, sieciowe grupy zabezpieczeń, bramy sieci VPN, bramy usługi ExpressRoute, usługi Azure Load Balancers, usługi Azure Firewalls, menedżera zapory i usługi DDOS). Korzystanie z koncentratorów usługi Azure Virtual WAN może znacznie ułatwić tworzenie sieci wirtualnej koncentratora i VDC, ponieważ większość złożoności inżynieryjnej jest obsługiwana przez platformę Azure podczas wdrażania koncentratora usługi Azure Virtual WAN.

Sieci wirtualne. Centrum jest zwykle oparte na sieci wirtualnej z wieloma podsieciami hostujących różne typy usług. Te usługi filtrować i sprawdzać ruch do lub z Internetu za pośrednictwem usługi Azure Firewall, urządzeń WUS, zapory aplikacji internetowej i aplikacja systemu Azure wystąpień bramy.

Trasy zdefiniowane przez użytkownika. Korzystając z tras definiowanych przez użytkownika, klienci mogą wdrażać zapory, systemy wykrywania nieautoryzowanego dostępu/adresy IP oraz inne urządzenia wirtualne. Mogą one kierować ruch sieciowy przez te urządzenia zabezpieczeń na potrzeby wymuszania zasad granic zabezpieczeń, inspekcji i inspekcji. Trasy zdefiniowane przez użytkownika można tworzyć zarówno w centrum, jak i szprychach, aby zagwarantować, że ruch będzie przesyłany przez określone niestandardowe maszyny wirtualne, wirtualne urządzenia sieciowe i moduły równoważenia obciążenia używane przez implementację VDC. Aby zagwarantować, że ruch generowany na podstawie maszyn wirtualnych przesyłanych szprych do odpowiednich urządzeń wirtualnych, należy ustawić trasę zdefiniowaną przez użytkownika w podsieciach szprychy. W tym celu należy ustawić adres IP frontonu wewnętrznego modułu równoważenia obciążenia jako następny przeskok. Wewnętrzny moduł równoważenia obciążenia rozkłada ruch wewnętrzny na urządzenia wirtualne (pula wewnętrznej bazy danych modułu równoważenia obciążenia).

Azure Firewall to zarządzana usługa zabezpieczeń sieci, która chroni zasoby usługi Azure Virtual Network. Jest to stanowa zarządzana zapora o wysokiej dostępności i skalowalności chmury. Możesz centralnie tworzyć, wymuszać i rejestrować zasady łączności aplikacji i sieci w subskrypcjach i sieciach wirtualnych. Usługa Azure Firewall używa statycznego publicznego adresu IP do zasobów sieci wirtualnej. Umożliwia to zewnętrznym zaporom identyfikowanie ruchu pochodzącego z danej sieci wirtualnej. Usługa jest w pełni zintegrowana z usługą Azure Monitor na potrzeby rejestrowania i analiz.

Jeśli używasz topologii usługi Azure Virtual WAN, usługa Azure Firewall Manager to usługa zarządzania zabezpieczeniami, która zapewnia centralne zasady zabezpieczeń i zarządzanie trasami dla obwodów zabezpieczeń opartych na chmurze. Współpracuje ona z koncentratorem usługi Azure Virtual WAN, zasobem zarządzanym przez firmę Microsoft, który umożliwia łatwe tworzenie architektur piasty i szprych. Gdy zasady zabezpieczeń i routingu są skojarzone z koncentratorem, jest nazywane zabezpieczonym koncentratorem wirtualnym.

Wirtualne urządzenia sieciowe. W centrum sieć obwodowa z dostępem do Internetu jest zwykle zarządzana za pośrednictwem wystąpienia usługi Azure Firewall lub farmy zapór lub zapory aplikacji internetowej (WAF).

Różne linie biznesowe często używają wielu aplikacji internetowych, które mają tendencję do występowania różnych luk w zabezpieczeniach i potencjalnych luk w zabezpieczeniach. Zapory aplikacji internetowej to specjalny typ produktu używany do wykrywania ataków na aplikacje internetowe i protokół HTTP/HTTPS bardziej efektywnie niż ogólna zapora. W porównaniu z tradycyjną technologią zapory WAFs mają zestaw określonych funkcji chroniących wewnętrzne serwery internetowe przed zagrożeniami.

Zapora usługi Azure Firewall lub urządzenia WUS używa wspólnej płaszczyzny administracyjnej z zestawem reguł zabezpieczeń w celu ochrony obciążeń hostowanych w szprychach i kontrolowania dostępu do sieci lokalnych. Usługa Azure Firewall ma wbudowaną skalowalność, natomiast zapory urządzenia WUS można ręcznie skalować za modułem równoważenia obciążenia. Ogólnie rzecz biorąc, farma zapory ma mniej wyspecjalizowane oprogramowanie w porównaniu z zaporą aplikacji internetowej, ale ma szerszy zakres aplikacji do filtrowania i sprawdzania dowolnego typu ruchu wychodzącego i przychodzącego. Jeśli jest używane podejście urządzenia WUS, można je znaleźć i wdrożyć w witrynie Azure Marketplace.

Zalecamy użycie jednego zestawu wystąpień usługi Azure Firewall lub urządzeń WUS dla ruchu pochodzącego z Internetu. Użyj innego dla ruchu pochodzącego ze środowiska lokalnego. Użycie tylko jednego zestawu zapór dla obu jest zagrożeniem bezpieczeństwa, ponieważ nie zapewnia obwodu zabezpieczeń między dwoma zestawami ruchu sieciowego. Użycie oddzielnych warstw zapory zmniejsza złożoność sprawdzania reguł zabezpieczeń, co pozwala jasno stwierdzić, które reguły odpowiadają przychodzącym żądaniom sieciowym.

Usługa Azure Load Balancer oferuje usługę warstwy 4 (TCP/UDP), która może dystrybuować ruch przychodzący między wystąpienia usługi zdefiniowane w zestawie o zrównoważonym obciążeniu. Ruch wysyłany do modułu równoważenia obciążenia z punktów końcowych frontonu (publicznych punktów końcowych adresów IP lub prywatnych punktów końcowych ip) może być dystrybuowany z translacją adresów zaplecza lub bez ich translacji do zestawu pul adresów IP zaplecza (takich jak wirtualne urządzenia sieciowe lub maszyny wirtualne).

Usługa Azure Load Balancer może sondować kondycję różnych wystąpień serwera. Jeśli wystąpienie nie zareaguje na sondę, moduł równoważenia obciążenia przestaje wysyłać ruch do wystąpienia o złej kondycji. W wirtualnym centrum danych zewnętrzny moduł równoważenia obciążenia jest wdrażany w centrum i szprychach. W centrum moduł równoważenia obciążenia jest używany do efektywnego kierowania ruchu między wystąpieniami zapory. W szprychach moduły równoważenia obciążenia są używane do zarządzania ruchem aplikacji.

Usługa Azure Front Door (AFD) to wysoce dostępna i skalowalna platforma przyspieszania aplikacji internetowych firmy Microsoft, globalna usługa równoważenia obciążenia HTTP, ochrona aplikacji i sieć dostarczania zawartości. Uruchamianie w ponad 100 lokalizacjach na brzegu globalnej sieci firmy Microsoft, AFD umożliwia tworzenie, obsługę i skalowanie dynamicznej aplikacji internetowej i zawartości statycznej. Usługa AFD zapewnia aplikacji światowej klasy wydajność użytkownika końcowego, ujednoliconą automatyzację konserwacji regionalnej/sygnaturowej, automatyzację BCDR, ujednolicone informacje o kliencie/użytkowniku, buforowanie i szczegółowe informacje o usłudze.

Platforma oferuje:

• Umowy dotyczące wydajności, niezawodności i obsługi poziomu usług (SLA).
• Certyfikaty zgodności.
• Inspekcja praktyk zabezpieczeń, które są opracowywane, obsługiwane i natywnie obsługiwane przez platformę Azure.

Usługa Azure Front Door udostępnia również zaporę aplikacji internetowej (WAF), która chroni aplikacje internetowe przed typowymi lukami w zabezpieczeniach i ekspozycjami.

aplikacja systemu Azure Gateway to dedykowane urządzenie wirtualne dostarczające zarządzany kontroler dostarczania aplikacji. Oferuje ona różne funkcje równoważenia obciążenia warstwy 7 dla aplikacji. Umożliwia ona optymalizację wydajności farmy internetowej przez odciążanie żądań SSL intensywnie korzystających z procesora CPU do bramy aplikacji. Zapewnia również inne funkcje routingu warstwy 7, takie jak okrężna dystrybucja ruchu przychodzącego, koligacja sesji oparta na plikach cookie, routing oparty na ścieżkach URL i możliwość hostowania wielu witryn internetowych za pojedynczą bramą aplikacji. Zapora aplikacji internetowych jest również udostępniana w ramach jednostki SKU zapory aplikacji internetowych w usłudze Application Gateway. Zapewnia ona ochronę aplikacji internetowych przed typowymi internetowymi lukami w zabezpieczeniach. Bramę aplikacji można skonfigurować jako bramę dostępną z Internetu, bramę tylko do użytku wewnętrznego lub kombinację obu tych bram.

Publiczne adresy IP. W przypadku niektórych funkcji platformy Azure można skojarzyć punkty końcowe usługi z publicznym adresem IP, aby zasób był dostępny z Internetu. Ten punkt końcowy używa translatora adresów sieciowych do kierowania ruchu do wewnętrznego adresu i portu w sieci wirtualnej na platformie Azure. Ta ścieżka stanowi podstawową metodę przekazywania ruchu zewnętrznego do sieci wirtualnej. Możesz skonfigurować publiczne adresy IP, aby określić, który ruch jest przekazywany i jak i gdzie jest tłumaczony na sieć wirtualną.

Usługa Azure DDoS Protection zapewnia więcej możliwości ograniczania ryzyka za pośrednictwem podstawowej warstwy usług , która jest dostrojona specjalnie do zasobów sieci wirtualnej platformy Azure. Ochrona przed atakami DDoS jest prosta do włączenia i nie wymaga żadnych zmian aplikacji. Zasady ochrony są dostosowywane za pośrednictwem dedykowanych algorytmów monitorowania ruchu i uczenia maszynowego. Zasady są stosowane do publicznych adresów IP skojarzonych z zasobami wdrożonymi w sieciach wirtualnych. Przykłady obejmują moduł równoważenia obciążenia platformy Azure, bramę aplikacji platformy Azure i wystąpienia usługi Azure Service Fabric. Dzienniki generowane przez system są dostępne niemal w czasie rzeczywistym za pośrednictwem widoków usługi Azure Monitor podczas ataku i historii. Ochronę warstwy aplikacji można dodać za pośrednictwem zapory aplikacji internetowej usługi Azure Application Gateway. Ochrona jest dostępna dla publicznych adresów IP IPv4 i IPv6 platformy Azure.

Topologia piasty i szprych używa komunikacji równorzędnej sieci wirtualnych i tras zdefiniowanych przez użytkownika w celu prawidłowego kierowania ruchu.

Na diagramie trasa zdefiniowana przez użytkownika zapewnia, że ruch przepływa z szprychy do zapory przed przekazaniem do środowiska lokalnego za pośrednictwem bramy usługi ExpressRoute (jeśli zasady zapory zezwalają na ten przepływ).

Typ składnika: monitorowanie

Składniki monitorowania zapewniają widoczność i alerty ze wszystkich innych typów składników. Wszystkie zespoły mogą mieć dostęp do monitorowania składników i usług, do których mają dostęp. Jeśli masz scentralizowane zespoły pomocy technicznej lub zespoły operacyjne, wymagają zintegrowanego dostępu do danych dostarczonych przez te składniki.

Platforma Azure oferuje różne typy usług rejestrowania i monitorowania w celu śledzenia zachowania zasobów hostowanych na platformie Azure. Ład i kontrola obciążeń na platformie Azure opiera się nie tylko na zbieraniu danych dziennika, ale także na możliwości wyzwalania akcji na podstawie określonych zgłoszonych zdarzeń.

Azure Monitor. Platforma Azure obejmuje wiele usług, które indywidualnie wykonują określoną rolę lub zadanie w obszarze monitorowania. Razem te usługi zapewniają kompleksowe rozwiązanie do zbierania, analizowania i działania na dziennikach generowanych przez system z aplikacji i zasobów platformy Azure, które je obsługują. Mogą również pracować nad monitorowaniem krytycznych zasobów lokalnych w celu zapewnienia hybrydowego środowiska monitorowania. Zrozumienie dostępnych narzędzi i danych jest pierwszym krokiem w opracowywaniu pełnej strategii monitorowania aplikacji.

Istnieją dwa podstawowe typy dzienników w usłudze Azure Monitor:

• Metryki to wartości liczbowe , które opisują jakiś aspekt systemu w określonym punkcie w czasie. Są lekkie i mogą obsługiwać scenariusze niemal w czasie rzeczywistym. W przypadku wielu zasobów platformy Azure dane zebrane przez usługę Azure Monitor będą widoczne bezpośrednio na stronie przeglądu w witrynie Azure Portal. Na przykład przyjrzyjmy się dowolnej maszynie wirtualnej i zobaczysz kilka wykresów wyświetlających metryki wydajności. Wybierz dowolny wykres, aby otworzyć dane w Eksploratorze metryk w witrynie Azure Portal, co umożliwia wykres wartości wielu metryk w czasie. Wykresy można wyświetlić interaktywnie lub przypiąć do pulpitu nawigacyjnego, aby wyświetlić je z innymi wizualizacjami.

• Dzienniki zawierają różne rodzaje danych zorganizowanych w rekordy z różnymi zestawami właściwości dla każdego typu. Zdarzenia i ślady są przechowywane jako dzienniki wraz z danymi wydajności, które można połączyć na potrzeby analizy. Dane dzienników zbierane przez usługę Azure Monitor można analizować za pomocą zapytań, aby szybko pobierać, konsolidować i analizować zebrane dane. Dzienniki są przechowywane i odpytywane z usługi Log Analytics. Zapytania można tworzyć i testować przy użyciu usługi Log Analytics w witrynie Azure Portal, a także bezpośrednio analizować dane przy użyciu tych narzędzi lub zapisywać zapytania do użycia z wizualizacjami lub regułami alertów.

Usługa Azure Monitor może zbierać dane z różnych źródeł. Możesz myśleć o monitorowaniu danych dla aplikacji w warstwach, od aplikacji, dowolnego systemu operacyjnego i usług, na których polega, aż do samej platformy Azure. Usługa Azure Monitor zbiera dane z każdej z następujących warstw:

• Dane monitorowania aplikacji: dane dotyczące wydajności i funkcjonalności napisanego kodu, niezależnie od platformy.
• Dane monitorowania systemu operacyjnego gościa: dane dotyczące systemu operacyjnego, na którym działa aplikacja. Ten system operacyjny może być uruchomiony na platformie Azure, w innej chmurze lub lokalnie.
• Dane monitorowania zasobów platformy Azure: dane dotyczące działania zasobu platformy Azure.
• Dane monitorowania subskrypcji platformy Azure: dane dotyczące operacji i zarządzania subskrypcją platformy Azure oraz kondycją i działaniem samej platformy Azure.
• Dane monitorowania dzierżawy platformy Azure: dane dotyczące działania usług platformy Azure na poziomie dzierżawy, takich jak Microsoft Entra ID.
• Źródła niestandardowe: można również dołączać dzienniki wysyłane ze źródeł lokalnych. Przykłady obejmują zdarzenia serwera lokalnego lub dane wyjściowe dziennika systemu urządzeń sieciowych.

Monitorowanie danych jest przydatne tylko wtedy, gdy może zwiększyć wgląd w działanie środowiska obliczeniowego. Usługa Azure Monitor zawiera kilka funkcji i narzędzi, które zapewniają cenny wgląd w aplikacje i inne zasoby, od których zależą. Rozwiązania i funkcje monitorowania, takie jak application insights i Azure Monitor dla kontenerów, zapewniają szczegółowe informacje na temat różnych aspektów aplikacji i określonych usług platformy Azure.

Rozwiązania do monitorowania w usłudze Azure Monitor to spakowane zestawy logiki, które zapewniają szczegółowe informacje dotyczące określonej aplikacji lub usługi. Obejmują one logikę zbierania danych monitorowania dla aplikacji lub usługi, zapytań do analizowania tych danych i widoków na potrzeby wizualizacji. Rozwiązania do monitorowania są dostępne od firmy Microsoft i partnerów w celu zapewnienia monitorowania różnych usług platformy Azure i innych aplikacji.

W przypadku takiej kolekcji bogatych danych ważne jest podjęcie proaktywnych działań dotyczących zdarzeń wykonywanych w danym środowisku, zwłaszcza gdy same zapytania ręczne nie będą wystarczające. Alerty w usłudze Azure Monitor aktywnie powiadamiają o krytycznych warunkach i potencjalnie próbują podjąć działania naprawcze. Reguły alertów oparte na metrykach zapewniają alerty niemal w czasie rzeczywistym na podstawie wartości liczbowych. Reguły alertów oparte na dziennikach umożliwiają złożoną logikę między danymi z wielu źródeł. Reguły alertów w usłudze Azure Monitor używają grup akcji, które zawierają unikatowe zestawy adresatów i akcji, które mogą być współużytkowane przez wiele reguł. Na podstawie wymagań grupy akcji mogą używać elementów webhook, które powodują uruchamianie akcji zewnętrznych lub integrowanie alertów z narzędziami ITSM.

Usługa Azure Monitor umożliwia również tworzenie niestandardowych pulpitów nawigacyjnych. Pulpity nawigacyjne platformy Azure umożliwiają łączenie różnych rodzajów danych, w tym metryk i dzienników, w jednym okienku w witrynie Azure Portal. Opcjonalnie możesz udostępnić pulpit nawigacyjny innym użytkownikom platformy Azure. Elementy w usłudze Azure Monitor można dodawać do pulpitu nawigacyjnego platformy Azure oprócz danych wyjściowych dowolnego zapytania dziennika lub wykresu metryk. Możesz na przykład utworzyć pulpit nawigacyjny, który łączy kafelki, które pokazują graf metryk, tabelę dzienników aktywności, wykres użycia z usługi Application Insights i dane wyjściowe zapytania dziennika.

Na koniec dane usługi Azure Monitor są natywnym źródłem dla usługi Power BI. Power BI to usługa analizy biznesowej, która udostępnia interaktywne wizualizacje w różnych źródłach danych. Jest to również skuteczny sposób udostępniania danych innym osobom w organizacji i poza nią. Usługę Power BI można skonfigurować tak, aby automatycznie importować dane dziennika z usługi Azure Monitor, aby korzystać z tych dodatkowych wizualizacji.

Usługa Azure Network Watcher udostępnia narzędzia do monitorowania, diagnozowania i wyświetlania metryk oraz włączania lub wyłączania dzienników dla zasobów w sieci wirtualnej na platformie Azure. Jest to wielowymiarowa usługa, która umożliwia wykonywanie następujących funkcji i nie tylko:

• Monitorowanie komunikacji między maszyną wirtualną a punktem końcowym.
• Wyświetlanie zasobów w sieci wirtualnej i ich relacjach.
• Diagnozowanie problemów z filtrowaniem ruchu sieciowego do lub z maszyny wirtualnej.
• Diagnozowanie problemów z routingiem sieciowym z maszyny wirtualnej.
• Diagnozowanie połączeń wychodzących z maszyny wirtualnej.
• Przechwytywanie pakietów do i z maszyny wirtualnej.
• Diagnozowanie problemów z bramą sieci wirtualnej i połączeniami.
• Określanie względnych opóźnień między regionami platformy Azure i dostawcami usług internetowych.
• Wyświetlanie reguł zabezpieczeń dla interfejsu sieciowego.
• Wyświetlanie metryk sieci.
• Analizowanie ruchu do lub z sieciowej grupy zabezpieczeń.
• Wyświetlanie dzienników diagnostycznych dla zasobów sieciowych.

Typ składnika: Obciążenia

Składniki obciążenia to miejsce, w którym znajdują się rzeczywiste aplikacje i usługi. To miejsce, w którym zespoły deweloperów aplikacji spędzają większość czasu.

Możliwości obciążeń są nieograniczone. Poniżej przedstawiono tylko kilka możliwych typów obciążeń:

Aplikacje wewnętrzne: aplikacje biznesowe mają kluczowe znaczenie dla operacji przedsiębiorstwa. Te aplikacje mają pewne typowe cechy:

• Interakcyjne: dane są wprowadzane, a wyniki lub raporty są zwracane.
• Oparte na danych: intensywne wykorzystanie danych z częstym dostępem do baz danych lub innego magazynu.
• Zintegrowane: oferują integrację z innymi systemami w organizacji lub poza nią.

Witryny internetowe dostępne dla klientów (połączone z Internetem lub połączone wewnętrznie): większość aplikacji internetowych to witryny internetowe. Platforma Azure może uruchamiać witrynę internetową za pośrednictwem maszyny wirtualnej IaaS lub witryny usługi Azure Web Apps (PaaS). Aplikacje internetowe platformy Azure integrują się z sieciami wirtualnymi w celu wdrażania aplikacji internetowych w strefie sieciowej szprychy. Witryny internetowe połączone wewnętrznie nie muszą uwidaczniać publicznego punktu końcowego internetu, ponieważ zasoby są dostępne za pośrednictwem prywatnych adresów routingu nieinternetowych z prywatnej sieci wirtualnej.

Analiza danych big data: jeśli dane muszą być skalowane w górę do większych woluminów, relacyjne bazy danych mogą nie działać prawidłowo pod ekstremalnym obciążeniem lub bez struktury danych. Usługa Azure HDInsight to zarządzana, w pełni spektrum, usługa analizy typu open source w chmurze dla przedsiębiorstw. Można używać struktur typu open source, takich jak Hadoop, Apache Spark, Apache Hive, LLAP, Apache Kafka, Apache Storm i R. HDInsight. Obsługuje to wdrażanie w sieci wirtualnej opartej na lokalizacji, którą można wdrożyć w klastrze we szprychach wirtualnego centrum danych.

Zdarzenia i komunikaty: Usługa Azure Event Hubs to platforma przesyłania strumieniowego danych big data i usługa pozyskiwania zdarzeń. Może odbierać i przetwarzać miliony zdarzeń na sekundę. Zapewnia małe opóźnienia i konfigurowalne przechowywanie czasu, co umożliwia pozyskiwanie ogromnych ilości danych na platformie Azure i odczytywanie ich z wielu aplikacji. Pojedynczy strumień może obsługiwać potoki w czasie rzeczywistym i wsadowe.

Usługę obsługi komunikatów w chmurze można zaimplementować w sposób wysoce niezawodny między aplikacjami i usługami za pośrednictwem usługi Azure Service Bus. Oferuje ona asynchroniczne komunikaty obsługiwane przez brokera między klientem a serwerem, ustrukturyzowaną obsługą komunikatów typu pierwszy na pierwszym wyjściu (FIFO) oraz publikuje i subskrybuje możliwości.

Te przykłady ledwo tworzą powierzchnię typów obciążeń, które można utworzyć na platformie Azure. Możesz utworzyć wszystko, od podstawowej aplikacji internetowej i SQL do najnowszej wersji w usłudze IoT, danych big data, uczenia maszynowego, sztucznej inteligencji i o wiele więcej.

Wysoka dostępność: wiele wirtualnych centrów danych

Do tej pory ten artykuł koncentruje się na projektowaniu pojedynczego VDC, opisując podstawowe składniki i architektury, które przyczyniają się do odporności. Funkcje platformy Azure, takie jak Azure Load Balancer, urządzenia WUS, strefy dostępności, zestawy dostępności, zestawy skalowania i inne możliwości, które ułatwiają uwzględnianie solidnych poziomów umowy SLA w usługach produkcyjnych.

Jednak ze względu na to, że wirtualne centrum danych jest zwykle implementowane w jednym regionie, może to być podatne na awarie, które mają wpływ na cały region. Klienci, którzy wymagają wysokiej dostępności, muszą chronić usługi za pośrednictwem wdrożeń tego samego projektu w co najmniej dwóch implementacjach VDC wdrożonych w różnych regionach.

Oprócz problemów z umową SLA kilka typowych scenariuszy korzysta z uruchamiania wielu wirtualnych centrów danych:

• Regionalna lub globalna obecność użytkowników końcowych lub partnerów.
• Wymagania dotyczące odzyskiwania po awarii.
• Mechanizm przekierowywania ruchu między centrami danych pod kątem obciążenia lub wydajności.

Obecność regionalna/globalna

Centra danych platformy Azure istnieją w wielu regionach na całym świecie. Podczas wybierania wielu centrów danych platformy Azure należy wziąć pod uwagę dwa powiązane czynniki: odległości geograficzne i opóźnienie. Aby zoptymalizować środowisko użytkownika, oceń odległość między każdym wirtualnym centrum danych a odległością od każdego wirtualnego centrum danych do użytkowników końcowych.

Region świadczenia usługi Azure hostujący wirtualne centrum danych musi być zgodny z wymaganiami prawnymi każdej jurysdykcji prawnej, w ramach której działa Twoja organizacja.

Odzyskiwanie po awarii

Projekt planu odzyskiwania po awarii zależy od typów obciążeń i możliwości synchronizowania stanu tych obciążeń między różnymi implementacjami VDC. Najlepiej, aby większość klientów potrzebowała szybkiego mechanizmu przełączania w tryb failover, a to wymaganie może wymagać synchronizacji danych aplikacji między wdrożeniami uruchomionymi w wielu implementacjach VDC. Jednak podczas projektowania planów odzyskiwania po awarii należy wziąć pod uwagę, że większość aplikacji jest wrażliwa na opóźnienia, które mogą być spowodowane przez tę synchronizację danych.

Synchronizacja i monitorowanie pulsu aplikacji w różnych implementacjach VDC wymaga od nich komunikacji za pośrednictwem sieci. Wiele implementacji VDC w różnych regionach można połączyć za pośrednictwem:

• Komunikacja typu piasta-koncentrator wbudowana w koncentratory usługi Azure Virtual WAN w różnych regionach w tej samej usłudze Virtual WAN.
• Komunikacja równorzędna sieci wirtualnych w celu połączenia koncentratorów między regionami.
• Prywatna komunikacja równorzędna usługi ExpressRoute, gdy koncentratory w każdej implementacji VDC są połączone z tym samym obwodem usługi ExpressRoute.
• Wiele obwodów usługi ExpressRoute połączonych za pośrednictwem sieci szkieletowej firmy, a wiele implementacji VDC połączonych z obwodami usługi ExpressRoute.
• Połączenia sieci VPN typu lokacja-lokacja między strefą piasty implementacji VDC w każdym regionie świadczenia usługi Azure.

Zazwyczaj koncentratory usługi Virtual WAN, komunikacja równorzędna sieci wirtualnych lub połączenia usługi ExpressRoute są preferowane w przypadku łączności sieciowej ze względu na większą przepustowość i spójne poziomy opóźnień podczas przechodzenia przez sieć szkieletową firmy Microsoft.

Uruchom testy kwalifikacji sieci, aby sprawdzić opóźnienie i przepustowość tych połączeń oraz zdecydować, czy replikacja danych synchronicznych lub asynchronicznych jest odpowiednia na podstawie wyniku. Ważne jest również, aby rozważyć te wyniki w celu optymalnego celu czasu odzyskiwania (RTO).

Odzyskiwanie po awarii: przekierowywanie ruchu z jednego regionu do innego

Zarówno usługa Azure Traffic Manager , jak i usługa Azure Front Door okresowo sprawdzają kondycję usługi punktów końcowych nasłuchiwania w różnych implementacjach VDC. Jeśli te punkty końcowe nie powiedzą się, usługa Azure Traffic Manager i usługa Azure Front Door będą automatycznie kierować do następnego najbliższego VDC. Usługa Traffic Manager używa pomiarów użytkownika w czasie rzeczywistym i systemu DNS do kierowania użytkowników do najbliższego (lub następnego najbliższego podczas awarii). Usługa Azure Front Door to zwrotny serwer proxy w ponad 100 lokacjach brzegowych sieci szkieletowej firmy Microsoft, który umożliwia kierowanie użytkowników do najbliższego punktu końcowego nasłuchiwania.

Podsumowanie

Podejście do migracji wirtualnego centrum danych polega na utworzeniu skalowalnej architektury, która optymalizuje użycie zasobów platformy Azure, obniża koszty i upraszcza ład systemu. Wirtualne centrum danych jest typowe w oparciu o topologie sieci piasty i szprych (przy użyciu komunikacji równorzędnej sieci wirtualnej lub koncentratorów usługi Virtual WAN). Typowe usługi udostępnione udostępniane w centrum oraz określone aplikacje i obciążenia są wdrażane w szprychach. Wirtualne centrum danych jest również zgodne ze strukturą ról firmy, gdzie różne działy, takie jak centralny dział IT, DevOps i operacje i konserwacja, współpracują ze sobą podczas wykonywania określonych ról. Wirtualne centrum danych obsługuje migrowanie istniejących obciążeń lokalnych na platformę Azure, ale także zapewnia wiele zalet wdrożeń natywnych dla chmury.

Informacje

Dowiedz się więcej o możliwościach platformy Azure omówionych w tym dokumencie.

Funkcje sieciowe
Azure Virtual Networks
Grupy zabezpieczeń sieci
Punkty końcowe usługi
Link prywatny
Trasy zdefiniowane przez użytkownika
Wirtualne urządzenia sieciowe
Publiczne adresy IP
Usługa DNS platformy Azure

Równoważenie obciążenia
Azure Front Door
Azure Load Balancer (warstwa 4)
Application Gateway (warstwa 7)
Azure Traffic Manager

Łączność
Komunikacja równorzędna sieci wirtualnych
Wirtualna sieć prywatna
Wirtualna sieć WAN
ExpressRoute
ExpressRoute Direct

Tożsamość
Tożsamość Microsoft Entra
Uwierzytelnianie wieloskładnikowe firmy Microsoft
Kontrola dostępu na podstawie ról na platformie Azure
Role wbudowane platformy Azure

Monitorowanie
Network Watcher
Azure Monitor
Log Analytics

Najlepsze praktyki
Grupa zarządzania
Zarządzanie subskrypcjami
Zarządzanie grupami zasobów
Limity subskrypcji platformy Azure

Bezpieczeństwo
Azure Firewall
Menedżer zapory
Zapora aplikacji internetowej usługi Application Gateway
Zapora aplikacji internetowej usługi Front Door
Azure DDoS

Inne usługi platformy Azure
Azure Storage
Azure SQL
Azure Web Apps
Azure Cosmos DB
HDInsight
Event Hubs
Service Bus
Azure IoT
Azure Machine Learning

Następne kroki

• Dowiedz się więcej na temat komunikacji równorzędnej sieci wirtualnych, podstawowej technologii topologii piasty i szprych.
• Zaimplementuj identyfikator Entra firmy Microsoft, aby użyć kontroli dostępu opartej na rolach platformy Azure.
• Opracuj model zarządzania subskrypcjami i zasobami przy użyciu kontroli dostępu opartej na rolach platformy Azure, która pasuje do struktury, wymagań i zasad organizacji. Najważniejszym działaniem jest planowanie. Przeanalizuj, w jaki sposób reorganizacje, fuzje, nowe linie produktów i inne zagadnienia będą wpływać na początkowe modele, aby zapewnić skalowanie w celu zaspokojenia przyszłych potrzeb i wzrostu.