Microsoft AZ-700: Równoważenie obciążenia i zarządzanie ruchem — Przewodnik do nauki
Część Microsoft Azure Network Engineer AZ-700 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.
Podstawowe usługi Azure do równoważenia obciążenia i brzegowe
Azure dostarcza kilka wyspecjalizowanych warstw do dystrybucji ruchu: Azure Load Balancer (warstwa 4), Application Gateway (warstwa 7), Front Door (globalne dostarczanie i routing na brzegu sieci) oraz Traffic Manager (routing oparty na DNS). Wybierz Azure Load Balancer Standard dla produkcyjnych scenariuszy TCP/UDP wschód-zachód i północ-południe, gdzie wymagana jest wysoka przepustowość, redundancja strefowa i przewidywalne zachowanie SNAT; jednostka SKU Basic jest ograniczona i niezalecana dla krytycznych obciążeń. Application Gateway v2 wspiera autoskalowanie, redundancję strefową, WAF (WAF_v2) oraz natywny routing oparty na URL i hoście dla ruchu HTTP/S, podczas gdy v1 nie posiada autoskalowania i wiąże się z narzutem związanym z planowaniem pojemności. Front Door (Standard/Premium) zapewnia globalny Anycast, terminację TLS na brzegu sieci, szybkie przełączanie awaryjne (failover) oraz silnik reguł do modyfikacji nagłówków i ścieżek; wersja Premium dodaje zaawansowany WAF i wsparcie dla prywatnych źródeł (origin). Traffic Manager jest oparty na DNS i przydatny do routingu geograficznego, przełączania awaryjnego i dystrybucji ważonej, ale nie może zapewniać terminacji TLS ani działać jako odwrotny serwer proxy HTTP. Przy łączeniu usług, umieszczaj zasoby statyczne w CDN i używaj Front Door do globalnego routingu, a Application Gateway do regionalnych polityk L7 i dostępu do prywatnych backendów. Rozważ te porównania jednostek SKU przy wyborze komponentów:
- Azure Load Balancer: Basic vs Standard (wybierz Standard dla środowisk produkcyjnych: redundancja strefowa, domyślnie bezpieczny).
- Application Gateway: v1 vs v2 (v2 dla autoskalowania, szybszych aktualizacji WAF).
- Front Door: Standard vs Premium (Premium dla zaawansowanego WAF i Private Link do źródeł).
Sondy kondycji, reguły przepisywania i zachowanie Web Application Firewall
Sondy kondycji i mechanizmy kontroli WAF są kluczowe dla odpornych operacji w warstwie 7. Konfiguruj sondy kondycji z realistycznymi punktami końcowymi, które weryfikują pełną ścieżkę żądania (włączając w to nagłówki autoryzacyjne, jeśli są wymagane) i odpowiadają zachowaniu backendu; ustaw interwał sondowania i progi awarii, aby zrównoważyć szybkość wykrywania z fałszywymi alarmami (false positives). Sondy kondycji Application Gateway mogą nadpisać nagłówek hosta i sondować określoną ścieżkę; upewnij się, że ustawienia HTTP backendu (koligacja oparta na plikach cookie, drenaż połączeń, limity czasu bezczynności) odpowiadają potrzebom aplikacji. Reguły przepisywania (rewrite rules) istnieją zarówno w silnikach reguł Application Gateway, jak i Front Door i powinny być używane do normalizacji nagłówków, usuwania lub wstawiania prefiksów, czy przepisywania adresów URL dla routingu do backendu, ale pamiętaj, że przepisywanie może zakłócić heurystyki buforowania i podpisane adresy URL. Polityki WAF różnią się w zależności od platformy: WAF w Application Gateway chroni regionalne backendy za pomocą reguł zarządzanych przez OWASP i niestandardowych wykluczeń, podczas gdy WAF w Front Door Premium chroni na brzegu sieci i wspiera polityki globalne, ochronę przed botami oraz zaawansowane ograniczanie szybkości (rate-limiting). Częste pułapki to sondowanie statycznej strony kondycji, która odpowiada poprawnie, podczas gdy punkty końcowe aplikacji ulegają awarii, zapominanie o zezwoleniu na zakresy IP sond w grupach NSG oraz błędna konfiguracja nagłówków hosta, przez co backendy odrzucają żądania sond.
Globalne zarządzanie ruchem: Front Door, Traffic Manager i CDN
Front Door i Traffic Manager służą do globalnej dystrybucji, ale działają w różny sposób. Front Door funkcjonuje jako globalne, stanowe proxy HTTP/S z terminacją TLS na brzegu sieci, inteligentnym routingiem (opóźnienie, priorytet i dynamiczne przyspieszanie witryny), wbudowaną warstwą pamięci podręcznej CDN oraz silnikiem reguł do manipulacji nagłówkami/ścieżkami. Traffic Manager to selektor punktów końcowych oparty na DNS, wykorzystujący metody routingu takie jak priorytet, waga, wydajność i położenie geograficzne; doskonale sprawdza się w prostym przełączaniu awaryjnym i routingu zgodności, ale nie może odciążyć TLS ani wykonywać przepisywania na poziomie aplikacji. Azure CDN (opcje Standard Microsoft, Standard Verizon, Premium Verizon/Akamai) jest zoptymalizowany pod kątem treści statycznych i nadających się do buforowania i może być poprzedzony przez Front Door lub używany niezależnie; wybierz Premium CDN dla złożonych silników reguł, tarczy źródła (origin shield) i zaawansowanych opcji SSL. W przypadku routingu dla wielu witryn, użyj nasłuchiwaczy (listeners) opartych na hoście w Application Gateway do segregacji regionalnej, a Front Door do obsługi wielu witryn w różnych regionach z domenami niestandardowymi. Pamiętaj, że buforowanie DNS wpływa na szybkość przełączania awaryjnego w Traffic Manager, Front Door zapewnia szybkie przełączanie awaryjne na brzegu sieci, a konfiguracja źródła (origin) CDN powinna być zgodna ze strategiami czyszczenia (purge) i TTL, aby unikać nieaktualnej zawartości. W scenariuszach z prywatnym źródłem, Front Door Premium wspiera Private Link do zabezpieczenia źródeł; w przeciwnym razie rozważ użycie Application Gateway w regionalnym hubie.
Kompromisy projektowe, pułapki operacyjne i monitorowanie
Decyzje projektowe uwzględniają kompromis między wydajnością, kosztem a odpornością. Nadaj priorytet usłudze Front Door lub CDN w celu globalnego dostarczania treści i zmniejszenia opóźnień po stronie klienta, Application Gateway dla zaawansowanych kontroli polityk L7 blisko backendu, a Azure Load Balancer Standard dla surowej przepustowości TCP/UDP i przewidywalnego skalowania. Kompromisy kosztowe obejmują Front Door Premium/WAF i automatyczne skalowanie Application Gateway v2 w porównaniu do tańszych, ręcznie skalowanych alternatyw v1; zrównoważ koszty, konsolidując globalny routing na brzegu sieci (edge), jednocześnie zachowując regionalne bramy do inspekcji ruchu prywatnego. Pułapki operacyjne obejmują wyczerpanie portów SNAT, gdy wiele backendów inicjuje połączenia wychodzące z małego zestawu adresów NAT — użyj NAT Gateway lub dostosuj ustawienia SNAT i unikaj tzw. „hairpinningu” ruchu przez ten sam NAT. Innym częstym problemem jest zapominanie o otwarciu adresów IP sond w grupach NSG lub błędna konfiguracja niestandardowych domen i certyfikatów dla Front Door i App Gateway. W celu monitorowania włącz logi diagnostyczne i metryki dla każdej usługi (Load Balancer, App Gateway, Front Door, CDN), przesyłaj je do Log Analytics i używaj Traffic Analytics oraz Connection Monitor z usługi Network Watcher, aby uzyskać wgląd na poziomie przepływów. Skonfiguruj alerty dotyczące awarii sond, anomalii w przepustowości backendu i wykryć WAF, a także testuj przełączanie awaryjne (failover) za pomocą kontrolowanego ruchu, aby zweryfikować runbooki i procedury wycofywania zmian (rollback).
Problem praktyczny: Scenariusz użycia
Scenariusz: Firma Contoso Manufacturing działa w wieloregionowym środowisku Azure z dwoma regionalnymi hubami (EastUS i WestEurope), regionalnymi instancjami Application Gateway v2, parą pul aplikacji opartych na skalowalnych zestawach maszyn wirtualnych oraz istniejącą siecią CDN dla zasobów statycznych. Firma potrzebuje udostępnić pojedynczy globalny punkt końcowy z WAF na brzegu sieci i szybkim przełączaniem awaryjnym, jednocześnie zachowując możliwość prywatnej inspekcji ruchu w regionach.
Wyzwanie: Zapewnij globalny punkt końcowy HTTPS z WAF na brzegu sieci, szybkim przełączaniem awaryjnym między regionami oraz możliwością kierowania ruchu do regionalnych backendów Application Gateway (które są prywatne) bez publicznego eksponowania zasobów źródłowych (origin).
Zalecane podejście:
- Wdróż Azure Front Door Premium jako globalny punkt wejścia (SKU: Front Door Premium) z terminacją TLS, włącz politykę Front Door WAF (reguły niestandardowe + OWASP) i skonfiguruj pulę backendów dla każdego regionu, wskazującą na publiczny adres IP regionalnej bramy Application Gateway v2 z włączonym Private Link w celu bezpiecznej łączności z zasobem źródłowym.
- Skonfiguruj zasób źródłowy (origin) w Front Door jako Private Link do regionalnego frontendu Application Gateway i ustaw sondy kondycji (health probes) na chroniony punkt końcowy kondycji, który udostępnia Application Gateway; ustaw niskie interwały sondowania (np. 10s) i agresywny próg awarii (np. 3) w celu szybkiego przełączania awaryjnego.
- Zachowaj Application Gateway v2 w każdym regionie do routingu L7, przepisywania adresów URL i lokalnych reguł WAF dostosowanych do polityk regionalnych; włącz automatyczne skalowanie i przesyłanie logów diagnostycznych do Log Analytics.
- Użyj Azure CDN (Standard Microsoft) dla zasobów statycznych, które można buforować, umieszczając je za Front Door w celu optymalnej kontroli nad TTL i czyszczeniem pamięci podręcznej (purge); zaimplementuj monitorowanie i alerty dotyczące awarii sond Front Door oraz wskaźników blokowania przez WAF.
Uzasadnienie: Front Door Premium zapewnia WAF na brzegu sieci i szybkie globalne przełączanie awaryjne, podczas gdy Private Link zabezpiecza regionalne bramy jako zasoby źródłowe (origins); regionalny Application Gateway v2 umożliwia szczegółową kontrolę i inspekcję na poziomie L7 bez eksponowania maszyn wirtualnych backendu, równoważąc wydajność, bezpieczeństwo i odporność.
← Bezpieczeństwo sieciowe · Wszystkie domeny · Monitorowanie sieci i rozwiązywanie problemów →
Przećwicz te pytania → · Testy na czas na ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Zdaj egzamin →