Microsoft AZ-104: Równoważenie obciążenia Azure i zarządzanie ruchem — Przewodnik do nauki

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Część Microsoft Azure Administrator Associate AZ-104 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Azure oferuje wielowarstwową ofertę usług do dystrybucji i ochrony ruchu: Azure Load Balancer (warstwa 4, TCP/UDP), Application Gateway (warstwa 7, HTTP/S), Azure Front Door (globalna usługa brzegowa warstwy 7), Azure Traffic Manager (oparty na DNS) oraz Azure CDN (buforowanie na brzegu sieci). Każda z nich jest przeznaczona dla określonego segmentu ścieżki żądania — od globalnego podejmowania decyzji DNS i brzegowych punktów POP, przez regionalny routing HTTP, aż po prywatny ruch wschód-zachód (east-west). Opanowanie tematu polega na wyborze odpowiedniej usługi dla danego protokołu i odbiorców, prawidłowym ich komponowaniu oraz konfigurowaniu sond kondycji i reguł, które zapewniają niezawodne przełączanie awaryjne (failover).

Azure Load Balancer (L4): jednostki SKU, elementy składowe, NAT/ruch wychodzący i Floating IP

Standard Load Balancer to load balancer warstwy 4 klasy produkcyjnej. Jest świadomy stref i redundantny strefowo (zone-aware/zone-redundant), obsługuje porty wysokiej dostępności (HA Ports), zaawansowaną diagnostykę i metryki, jest domyślnie bezpieczny (brak ruchu przychodzącego bez zdefiniowanych reguł), ma konfigurowalne reguły dla ruchu wychodzącego i obsługuje dużą skalę zaplecza. Basic to starsza jednostka SKU z ograniczoną skalą/funkcjonalnością i brakiem redundancji strefowej; jest w trakcie wycofywania i nie powinna być wybierana dla nowych wdrożeń.

Podstawowe komponenty definiują przepływ ruchu:

Frontend IP: Wirtualny adres IP (VIP) udostępniany klientom. Zewnętrzne load balancery używają publicznego adresu IP (Public IP) lub prefiksu publicznych adresów IP (Public IP Prefix); wewnętrzne load balancery używają prywatnego, statycznego adresu IP z podsieci. Wersja Standard obsługuje wiele frontendów oraz redundantne strefowo publiczne adresy IP.
Pula zaplecza: Interfejsy sieciowe (NIC), konfiguracje IP na interfejsach sieciowych lub instancje VM scale set w tym samym regionie/VNet. Jedna pula może obsługiwać wiele reguł. Wersja Standard obsługuje zaplecza obejmujące wiele stref w obrębie jednego regionu.
Sondy kondycji: Określają, które instancje zaplecza są w dobrej kondycji. Sondy TCP wykonują pełne uzgodnienie (handshake); sondy HTTP/HTTPS wysyłają żądanie GET na określoną ścieżkę i uznają kody odpowiedzi 200–399 za sukces. Kontrolujesz protokół, port, ścieżkę (dla HTTP/S), interwał oraz próg złej kondycji (liczba kolejnych niepowodzeń przed oznaczeniem instancji jako niedostępnej).
Reguły równoważenia obciążenia: Wiążą frontend (IP/port/protokół) z pulą zaplecza i sondą kondycji. Ustawienia reguły obejmują port zaplecza, protokół (TCP/UDP), trwałość sesji, limit czasu bezczynności oraz Floating IP (Direct Server Return).

Reguły NAT dla ruchu przychodzącego to translacje per-maszyna wirtualna, które przekierowują ruch z określonego portu frontendu na pojedynczy interfejs sieciowy/port zaplecza (na przykład w celu udostępnienia RDP lub SSH dla jednej maszyny wirtualnej bez równoważenia obciążenia). Nie używają one sondy kondycji i nie są mechanizmem skalowania w poziomie.

Reguły dla ruchu wychodzącego definiują zachowanie SNAT dla zapleczy Standard Load Balancer inicjujących połączenia z internetem za pośrednictwem publicznych frontendów load balancera. Pozwalają kontrolować, który frontend (lub które frontendy) dostarcza porty SNAT i ile portów jest przydzielanych na instancję zaplecza, co pomaga unikać wyczerpania portów SNAT przy wysokiej współbieżności połączeń wychodzących. Jeśli do podsieci jest dołączona usługa NAT Gateway, ma ona pierwszeństwo przed SNAT load balancera; preferuj NAT Gateway w celu zapewnienia spójnego i skalowalnego ruchu wychodzącego.

Floating IP (Direct Server Return) to opcja w regule używana, gdy docelowy adres IP/port musi być zachowany na całej ścieżce (end-to-end). Jest to wymagane w scenariuszach klastrowych, takich jak odbiorniki grup dostępności SQL Server Always On. W przypadku SQL AG należy użyć wewnętrznego Standard Load Balancer z sondą TCP (nie HTTP) na port sondy klastra i włączyć Floating IP w regule load balancera; nie należy sondować portu 1433 za pomocą HTTP, ponieważ SQL nie jest usługą działającą w oparciu o protokół HTTP.

Wybór między wewnętrznym a zewnętrznym load balancerem zależy od odbiorców i granicy bezpieczeństwa. Użyj wewnętrznego load balancera, gdy udostępniasz prywatny VIP wewnątrz sieci VNet lub za pośrednictwem łączności prywatnej (VPN/ExpressRoute) dla aplikacji biznesowych, baz danych i wirtualnych urządzeń sieciowych (NVA). Użyj zewnętrznego load balancera dla usług warstwy 4 dostępnych z internetu. W przypadku wewnętrznych load balancerów przypisz statyczny, prywatny adres IP frontendu w docelowej podsieci; w przypadku zewnętrznych load balancerów powiąż publiczny adres IP w wersji Standard (Standard Public IP) i opcjonalnie użyj wielu frontendów.

Cross-region Load Balancer zapewnia globalne równoważenie obciążenia w warstwie 4 typu anycast pomiędzy regionami. Wdrażasz Standard Public Load Balancer w każdym regionie (warstwa regionalna) i umieszczasz ich publiczne frontendy w puli zaplecza jednego, globalnego Load Balancera (warstwa globalna). Globalny load balancer używa sond kondycji do każdego regionalnego load balancera i kieruje klientów do najbliższego (pod względem opóźnień) regionu w dobrej kondycji, z zachowaniem symetrii przepływu opartej na haszowaniu 5-krotki (5-tuple hashing). Obsługuje tylko TCP/UDP — bez terminacji TLS — i uzupełnia regionalne bramy warstwy 7.

Application Gateway (L7) i Azure Front Door (globalny L7)

Application Gateway to regionalny odwrotny serwer proxy warstwy 7 z WAF. Terminujeruch HTTP/HTTPS, inspekcjonuje nagłówki i ścieżki oraz kieruje ruch do prywatnych lub publicznych backendów.

Kluczowe konstrukcje Application Gateway:

Odbiorniki (listeners): Wiążą publiczny adres IP/port/nazwę hosta i ustawienia SSL w celu akceptowania ruchu. SNI umożliwia obsługę wielu witryn TLS na jednym adresie IP. Używaj podstawowych odbiorników dla pojedynczej witryny, odbiorników dla wielu witryn (multi-site) do routingu opartego na hoście oraz hostów z symbolami wieloznacznymi (wildcard) dla szerokiego zasięgu.
Reguły routingu i ustawienia HTTP: Reguły mapują odbiorniki na pule zaplecza (backend pools) i określają ustawienia HTTP stosowane do backendów (protokół, port, nadpisywanie nagłówka hosta, koligacja oparta na plikach cookie, opróżnianie połączeń, limit czasu żądania). Możesz przekierowywać, przepisywać nagłówki lub kierować ruch na podstawie segmentów ścieżki URL.
Pule zaplecza (backend pools): Celami mogą być adresy IP kart sieciowych (NIC), nazwy FQDN, usługi App Service lub zestawy skalowania maszyn wirtualnych. Niestandardowe sondy kondycji (health probes) sprawdzają określone ścieżki/hosty i uwzględniają kody statusu oznaczające powodzenie.
WAF: Ochrona oparta na zestawie reguł OWASP Core Rule Set w trybie wykrywania lub zapobiegania, z niestandardowymi regułami, listami wykluczeń i przypisaniem do trasy w wersji v2. W wersji v2 obsługiwane jest automatyczne skalowanie i redundancja strefowa.

Zaawansowane wzorce L7:

Routing oparty na ścieżce URL: Kieruj ruch /api/* do mikrousług, a /images/* do statycznego źródła lub CDN, umożliwiając rozproszenie ruchu do mikrousług (fanout) za jednym adresem VIP.
Hosting wielu witryn (multi-site): Hostuj contoso.com i fabrikam.com na jednej bramie, używając odbiorników SNI i reguł opartych na nagłówku hosta. Przydatne do konsolidacji z silną izolacją za pomocą polityk WAF dla każdej witryny.
Terminacja SSL: Odciąż bramę z obsługi TLS w celu centralnego zarządzania certyfikatami i inspekcji WAF. Używaj szyfrowania end-to-end TLS (ponownego szyfrowania), gdy backendy wymagają szyfrowania lub walidacji certyfikatu klienta.

Azure Front Door zapewnia globalne równoważenie obciążenia i akcelerację HTTP/HTTPS na brzegu sieci (edge) dzięki anycast, split TCP i optymalizacji od POP do źródła. Jest najlepszym rozwiązaniem dla aplikacji dostępnych z internetu, które wymagają globalnego routingu, WAF na brzegu sieci i opcjonalnego buforowania na brzegu sieci (edge caching).

Globalne równoważenie obciążenia: Kieruje użytkowników do najzdrowszego źródła o najniższym opóźnieniu, używając sond kondycji z wielu punktów POP. Grupy źródeł (origin groups) obsługują przełączanie awaryjne (failover) oparte na priorytecie i opóźnieniu, z opcjonalną koligacją sesji.
WAF: Zarządzane reguły z ochroną przed botami, reguły niestandardowe, filtry geo/IP, ograniczanie szybkości (rate limiting) i przypisanie do trasy.
Buforowanie (caching): W wersjach Front Door Standard/Premium buforowanie na brzegu sieci jest zintegrowane; zdefiniuj zachowanie buforowania według ścieżki, kontroluj buforowanie z uwzględnieniem query string i wartości TTL oraz odciążaj globalnie zawartość statyczną.
Sondy kondycji: Sondy (HTTP/HTTPS) dla każdej grupy źródeł z konfigurowalną ścieżką, interwałem i protokołem, wysyłane z różnych punktów POP. Decyzje routingowe łączą informacje o kondycji i opóźnieniu.

Używaj Application Gateway do regionalnych potrzeb L7 (prywatne backendy, ruch wschód-zachód, złożone przepisywanie) oraz Front Door do globalnego L7, bezpieczeństwa na brzegu sieci i akceleracji. Są one często komponowane: Front Door na brzegu sieci, Application Gateway w każdym regionie i wewnętrzne load balancery (LBs) za bramami dla usług L4.

Traffic Manager (oparty na DNS) i Azure CDN

Traffic Manager to globalna dystrybucja ruchu oparta na DNS. Nie pośredniczy w ruchu (nie jest proxy); zamiast tego zwraca nazwę DNS/IP punktu końcowego na podstawie polityki i kondycji, pozostawiając klientom bezpośrednie połączenie. Kondycja jest sprawdzana za pomocą rozproszonych sond do punktów końcowych HTTP/HTTPS/TCP; niskie wartości TTL zmniejszają opóźnienie przełączania awaryjnego, ale zwiększają liczbę zapytań DNS.

Priorytet: Przełączanie awaryjne typu aktywny/pasywny. Ustaw główny punkt końcowy jako pierwszy; Traffic Manager będzie go obsługiwał, dopóki jest sprawny, a następnie przełączy się na kolejny priorytet.
Ważony: Dystrybuuj ruch według wag, aby wspierać stopniowe przełączanie lub testy A/B.
Wydajność: Wybierz punkt końcowy o najniższym opóźnieniu sieciowym z regionu użytkownika do punktu końcowego.
Geograficzny: Kieruj ruch na podstawie lokalizacji geograficznej użytkownika w celu zapewnienia suwerenności danych lub lokalizacji treści.
Wielowartościowy (multivalue): Zwróć wiele sprawnych punktów końcowych dla tej samej usługi, aby wspierać proste przełączanie awaryjne po stronie klienta. Możesz zagnieżdżać profile, aby tworzyć polityki hybrydowe (np. routing geograficzny na najwyższym poziomie, a następnie ważony w obrębie danej lokalizacji). Używaj Traffic Manager dla protokołów innych niż HTTP, usług, które nie korzystają z pośrednictwa na brzegu sieci, lub gdy potrzebujesz kontroli na poziomie DNS nad heterogenicznymi punktami końcowymi (Azure, on-premises, inne firmy).

Azure CDN odciąża zawartość statyczną i możliwą do buforowania do punktów obecności (POP) na brzegu sieci, aby zmniejszyć obciążenie źródła i opóźnienia.

Profile: Kontenery na jeden lub więcej punktów końcowych powiązanych z dostawcą/warstwą (np. z rodziny Microsoft, Akamai lub Verizon). Profile pomagają oddzielić środowiska lub centra kosztów.
Punkty końcowe: Zdefiniuj szczegóły źródła (nazwa hosta, nagłówek hosta źródła, protokół/port) oraz nazwę hosta na brzegu sieci. Możesz mieć wiele punktów końcowych w jednym profilu dla różnych aplikacji lub typów zawartości.
Reguły buforowania: Domyślne i niestandardowe reguły kontrolują wartości TTL, zachowanie oparte na ścieżce, obsługę query string (przekazywanie, ignorowanie lub buforowanie każdego unikalnego zapytania) oraz kompresję. Używaj reguł, aby wymusić buforowanie zasobów z krótkim TTL źródła lub aby ominąć buforowanie dla dynamicznych interfejsów API.
Domeny niestandardowe: Mapuj przyjazne nazwy hostów z TLS zarządzanym przez CDN. Zweryfikuj własność domeny za pomocą rekordu CNAME i włącz HTTPS z zarządzanymi certyfikatami. W razie potrzeby połącz z filtrowaniem geograficznym lub silnikiem reguł.

Wybory projektowe, integracja międzyregionalna i zachowanie sond kondycji

Wybór między wewnętrznymi a zewnętrznymi load balancerami zależy od grupy docelowej i ekspozycji trasy. Jeśli konsumenci znajdują się wyłącznie w sieciach prywatnych, użyj wewnętrznych LB, aby uniknąć publicznej ekspozycji i uprościć kontrolę NSG. Dla użytkowników internetowych lub partnerów używaj publicznych frontendów. W przypadku łączności wychodzącej na dużą skalę preferuj NAT Gateway zamiast SNAT load balancera; rezerwuj reguły wychodzące dla przypadków, w których frontend LB musi zapewniać SNAT.

Cross-region Load Balancer integruje się z regionalnymi Standard Public Load Balancerami, aby osiągnąć globalną odporność na awarie w warstwie 4 w trybie active-active dla usług TCP/UDP. Umieść publiczne frontendy regionalnych LB w puli zaplecza globalnego LB. Sondy kondycji na poziomie globalnym odzwierciedlają dostępność regionalną; routing kieruje ruch do regionu o najniższym opóźnieniu, który jest w dobrej kondycji, i automatycznie przełącza w tryb failover, jeśli cały region (lub jego regionalny LB) stanie się niedostępny. Połącz to rozwiązanie z Front Door, gdy potrzebujesz wsparcia dla obu protokołów (np. usługi TCP przez cross-region LB i HTTP/S przez Front Door) pod oddzielnymi adresami VIP.

Sondy kondycji są źródłem prawdy dla mechanizmu failover:

Sondy TCP: Działają dla każdej usługi TCP. Pomyślnie zakończone trójfazowe uzgadnianie (3-way handshake) oznacza sukces. Odpowiednie dla SQL, SMTP lub niestandardowych protokołów TCP.
Sondy HTTP/HTTPS: Weryfikują kondycję na poziomie aplikacji, żądając określonej ścieżki i oczekując odpowiedzi 200–399. Pozwalają na dostosowanie hosta/ścieżki i mogą rozróżniać częściowe awarie aplikacji. Sondy HTTPS weryfikują negocjację TLS, ale nie ważność certyfikatu poza procesem uzgadniania; używaj poprawnych nagłówków hosta dla aplikacji hostowanych wirtualnie.
Progi złej kondycji: Azure Load Balancer oznacza zaplecze jako niedostępne po N kolejnych nieudanych próbach sondy (konfigurowalne; domyślne interwały są krótkie, aby przyspieszyć failover). Application Gateway i Front Door sondują z wielu punktów obserwacyjnych i uznają źródło za niedostępne, gdy skumuluje się wystarczająca liczba kolejnych niepowodzeń w ich zestawie sond. Powrót do sprawności wymaga kolejnych udanych prób. Dostosuj interwał i próg, aby zrównoważyć czułość i niestabilność (flapping); upewnij się, że sondy docierają do lekkiego punktu końcowego, świadomego zależności.

Praktyczny scenariusz problemu

Firma Adobe musi globalnie udostępnić wieloregionową aplikację SaaS składającą się z frontendów webowych, mikrousług i grupy dostępności SQL Server Always On, z rygorystycznym bezpieczeństwem, szybkim failoverem i niskimi opóźnieniami dla użytkowników na całym świecie. Udostępniają również starszą usługę pozyskiwania telemetrii opartą na protokole TCP.

Umieść Azure Front Door Standard na brzegu sieci z polityką WAF i trasami dla www.adobe.com i api.adobe.com. Źródłami są Application Gateways w regionach East US i West Europe, zgrupowane z routingiem opartym na opóźnieniach i priorytetowym failoverem.

Dlaczego: Front Door zapewnia globalny anycast, WAF na brzegu sieci i opcjonalne buforowanie, aby przyspieszyć i chronić internetowy ruch HTTP/S; automatycznie wybiera najbliższy region w dobrej kondycji.

Wdróż Application Gateway v2 z WAF w każdym regionie. Skonfiguruj odbiorniki wielostanowiskowe (multi-site listeners) z SNI dla obu nazw hostów, routing oparty na ścieżce URL do mikrousług oraz niestandardowe sondy kondycji do /healthz na każdej usłudze. Włącz szyfrowanie SSL end-to-end z nadpisywaniem hosta zaplecza na FQDN usług.

Dlaczego: Application Gateway oferuje regionalny routing L7, inspekcję WAF blisko aplikacji, dystrybucję opartą na ścieżce (fanout) i polityki per-trasa; bezpiecznie łączy się z prywatnymi zapleczami i obsługuje przepisywanie nagłówków/przekierowania.

Wdróż wewnętrzny Standard Load Balancer w każdym regionie dla odbiornika (listenera) grupy dostępności SQL. Skonfiguruj statyczny prywatny frontend, sondę kondycji TCP na port sondy klastra Windows Failover Cluster oraz regułę równoważenia obciążenia z włączoną opcją Floating IP na port odbiornika.

Dlaczego: Odbiornik SQL wymaga warstwy 4 z bezpośrednim zwrotem od serwera (direct server return). Floating IP zachowuje semantykę miejsca docelowego, a sonda TCP dokładnie odzwierciedla przynależność do grupy dostępności (AG). Odzwierciedla to znany wymóg, że sondowanie HTTP na porcie 1433 jest nieprawidłowe.

Obsłuż statyczne zasoby webowe za pomocą reguł buforowania Azure Front Door dla /static/* z długim czasem życia (TTL) i rewalidacją, a także uruchom profil i punkt końcowy Azure CDN dla pobierania dużych plików multimedialnych pod adresem downloads.adobe.com z buforowaniem specyficznym dla ścieżki i wariacjami na podstawie ciągu zapytania (query string).

Dlaczego: Buforowanie w Front Door redukuje opóźnienia dla kluczowych statycznych treści webowych w ramach routingu brzegowego, podczas gdy dedykowany punkt końcowy CDN optymalizuje dostarczanie dużych obiektów i niezależność polityki buforowania dla pobieranych plików.

Opublikuj starszą usługę pozyskiwania telemetrii TCP za pośrednictwem regionalnego Standard Public Load Balancer w każdym regionie, a następnie umieść przed nimi Cross-region Load Balancer jako pojedynczy publiczny adres VIP. Skonfiguruj globalne sondy do każdego regionalnego LB i użyj routingu opartego na opóźnieniach.

Dlaczego: Usługa jest oparta na TCP, a nie HTTP; Cross-region Load Balancer zapewnia globalną warstwę 4 w trybie active-active z automatycznym failoverem i wyborem regionu o niskim opóźnieniu.

Dodaj Azure Traffic Manager z polityką priorytetu (Priority) tylko dla zewnętrznego punktu końcowego SFTP partnera hostowanego poza Azure, wymieniając główny punkt końcowy partnera i zapasowy hostowany w Azure.

Dlaczego: Traffic Manager jest oparty na DNS i może obejmować zewnętrzne punkty końcowe; zapewnia prosty failover active/passive dla celów innych niż HTTP i pochodzących od stron trzecich, gdy stosowanie proxy jest niepożądane.

Dla łączności wychodzącej z podsieci aplikacji, dołącz NAT Gateway i usuń zależność od SNAT wychodzącego z LB. Monitoruj wyniki sond oraz metryki LB/App Gateway/Front Door w Azure Monitor i dostosuj interwały sond/progi złej kondycji, aby wyeliminować niestabilność (flapping).

Dlaczego: NAT Gateway niezawodnie skaluje ruch wychodzący bez wyczerpania portów SNAT; precyzyjne dostrojenie sond kondycji zapewnia szybsze i stabilne działanie mechanizmu failover na wszystkich warstwach.

← Sieci wirtualne Azure · Wszystkie domeny · Magazyn Azure →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →