Sondy stavu Load Balanceru

Při použití pravidel vyrovnávání zatížení s Azure Load Balancer, je potřeba zadat sondy stavu, aby Load Balancer mohly zjistit stav koncového bodu back-endu. Konfigurace sondy stavu a odpovědí sondy určuje, které instance back-endových fondu budou přijímat nové toky. Sondy stavu můžete použít k detekci selhání aplikace v koncovém bodu back-endu. Můžete také vygenerovat vlastní odpověď na sondu stavu a použít sondu stavu pro řízení toku ke správě zatížení nebo plánovaných výpadků. Když sonda stavu selže, Load Balancer odesílání nových toků příslušné instanci, která není v pořádku. Na odchozí připojení to nemá vliv, má to vliv jenom na příchozí připojení.

Sondy stavu podporují více protokolů. Dostupnost konkrétního protokolu sondy stavu se liší podle Load Balancer SKU. Chování služby se navíc liší podle Load Balancer SKU, jak je znázorněno v této tabulce:

Konfigurace sondy

Konfigurace sondy stavu se skládá z následujících prvků:

• Doba trvání intervalu mezi jednotlivými testy
• Protokol sondy
• Port sondy
• Cesta HTTP, která se má použít pro HTTP GET při použití sond HTTP(S)

Porozumění signálu aplikace, detekci signálu a reakci platformy

Hodnota intervalu určuje, jak často bude sonda stavu testovat odpověď z instancí back-endového fondu. Pokud sonda stavu selže, okamžitě označí instance back-endu fondu jako špatné. Podobně při další sondě, která je v pořádku, označí sonda stavu instance back-endového fondu znovu jako v pořádku.

Chování můžeme ještě více ilustrovat pomocí příkladu, kdy byl interval sondy stavu nastavený na 5 sekund. Vzhledem k tomu, že čas odeslání sondy se synchronizuje s situací, kdy se aplikace může změnit stav, může celková doba uvedená v sondě stavu spadat do jednoho z následujících dvou scénářů:

1. Pokud vaše aplikace začne reagovat na sondu s časovým limitem těsně před doručením další sondy, bude detekce těchto událostí trvat 5 sekund plus doba trvání aplikace, která začíná signalizování časového limitu při příchodu sondy. Můžete předpokládat, že tato detekce bude trvat poněkud více než 5 sekund.
2. Pokud vaše aplikace začne reagovat na sondu s časovým limitem hned po doručení další sondy, detekce těchto událostí nezačne, dokud sonda nedorazí (a časový limit) plus dalších 5 sekund. Můžete předpokládat, že tato detekce bude trvat méně než 10 sekund.

V tomto příkladu po zjištění bude platforma chvíli trvat, než bude na tuto změnu reagovat. To znamená, že v závislosti na

1. když aplikace začne měnit stav a
2. při zjištění této změny (při odeslání další sondy stavu) a
3. kdy byla detekce komunikována napříč platformou

Můžete předpokládat, že reakce na odezvu sondy s časovým limitem bude trvat minimálně 5 sekund a maximálně po dobu 10 sekund, než bude reagovat na změnu signálu z aplikace. Tento příklad ilustruje, co se odehrává, ale není možné předpovídá přesnou dobu trvání nad rámec výše uvedených hrubých pokynů znázorněných v tomto příkladu.

Typy sond

Protokol používaný sondou stavu je možné nakonfigurovat na jednu z následujících možností:

• Naslouchače TCP
• Koncové body HTTP
• Koncové body HTTPS

Dostupné protokoly závisí na použité Load Balancer SKU:

Test protokolu TCP

Sondy PROTOKOLU TCP iniciují připojení provedením třísekunové otevřené handshake protokolu TCP s definovaným portem. Sondy PROTOKOLU TCP ukončí připojení pomocí handshake protokolu TCP se čtyřmi cestami blízko.

Minimální interval sondy je 5 sekund a minimální počet odpovědí, které není v pořádku, je 2. Celková doba trvání všech intervalů nesmí překročit 120 sekund.

Test protokolu TCP selže v případě, že:

• Naslouchací proces TCP v instanci během časového limitu vůbec nereaguje. Sonda se označí na základě počtu požadavků sondy s časovým limitem, které byly nakonfigurovány tak, aby před označením sondy nezodpovězeny nebyly.
• Sonda obdrží resetování protokolu TCP z instance.

Následující příklad ukazuje, jak můžete vyjádřit tento druh konfigurace sondy v Resource Manager šabloně:

    {
      "name": "tcp",
      "properties": {
        "protocol": "Tcp",
        "port": 1234,
        "intervalInSeconds": 5,
        "numberOfProbes": 1
      },

Test HTTP/HTTPS

Sondy HTTP a HTTPS se sestaví na sondě protokolu TCP a vydá HTTP GET se zadanou cestou. Obě tyto sondy podporují relativní cesty pro HTTP GET. Sondy HTTPS jsou stejné jako sondy HTTP s přidáním obálky protokolu TLS (Transport Layer Security, dříve označované jako SSL). Sonda stavu se označí, když instance během časového limitu odpoví stavem HTTP 200. Sonda stavu se ve výchozím nastavení pokouší kontrolovat nakonfigurovaný port sondy stavu každých 15 sekund. Minimální interval testu je 5 sekund. Celková doba trvání všech intervalů nesmí překročit 120 sekund.

Sondy HTTP/HTTPS mohou být užitečné také k implementaci vlastní logiky pro odebrání instancí z rotace nástroje pro vyrovnávání zatížení, pokud je port sondy také naslouchací proces pro samotnou službu. Můžete se například rozhodnout odebrat instanci, pokud je vyšší než 90 % využití procesoru, a vrátit stav HTTP, který není 200.

Pokud používáte Cloud Services webové role, které používají w3wp.exe, můžete také dosáhnout automatického monitorování webu. Selhání v kódu webu vrátí sondě nástroje pro vyrovnávání zatížení stav, který není 200.

Sonda HTTP/HTTPS selže, když:

• Koncový bod sondy vrátí jiný kód odpovědi HTTP než 200 (například 403, 404 nebo 500). Tím se sonda stavu okamžitě označí.
• Koncový bod sondy nereaguje vůbec během minimálního intervalu testu a 30sekudového časového limitu. Než se sonda označí jako nescházená, může se nezodpovězeno více požadavků sondy, dokud se nedosáhnou součtu všech intervalů časového limitu.
• Koncový bod sondy zavře připojení přes resetování protokolu TCP.

Následující příklad ukazuje, jak můžete vyjádřit tento druh konfigurace sondy v Resource Manager šabloně:

    {
      "name": "http",
      "properties": {
        "protocol": "Http",
        "port": 80,
        "requestPath": "/",
        "intervalInSeconds": 5,
        "numberOfProbes": 1
      },

    {
      "name": "https",
      "properties": {
        "protocol": "Https",
        "port": 443,
        "requestPath": "/",
        "intervalInSeconds": 5,
        "numberOfProbes": 1
      },

Chování sondy nahoru

Sondy stavu TCP, HTTP a HTTPS se považují za v pořádku a koncový bod back-endu jsou v pořádku, když:

• Sonda stavu je po spuštění virtuálního počítače úspěšná.

Každý koncový bod back-endu, který dosáhl stavu V pořádku, má nárok na příjem nových toků.

Chování při vypnutí sondy

Připojení TCP

Nová připojení TCP budou úspěšná pro zbývající koncový bod back-endu, který je v pořádku.

Pokud se sonda stavu koncového bodu back-endu nezdaří, na základě připojení TCP k tomuto koncovému bodu back-endu budou pokračovat.

Pokud všechny sondy pro všechny instance v back-endových fondech selžou, do back-endu se neposílají žádné nové toky. Standard Load Balancer umožní pokračování stanovených toků PROTOKOLU TCP. Základní Load Balancer ukončí všechny existující toky TCP do back-end fondu.

Load Balancer je předávková služba (neukončuje připojení TCP) a tok je vždy mezi klientem a hostem operačního systému a aplikace virtuálního počítače. Fond se všemi sondami ve stavu dolů způsobí, že front-end nereaguje na otevřené pokusy o připojení TCP (SYN), protože neexistuje žádný v pořádku back-endový koncový bod pro příjem toku a reakci pomocí SYN-ACK.

Datagramy UDP

Datagramy UDP se doručí do koncových bodů back-endu, které jsou v pořádku.

UDP je bez připojení a pro UDP se nesleduje žádný stav toku. Pokud selže nějaká sonda stavu koncového bodu back-endu, existující toky UDP se přesunou do jiné instance, která je v pořádku, v back-endového fondu.

Pokud všechny testy pro všechny instance v back-endového fondu selžou, existující toky UDP se ukončí pro load balancery basic a standardu.

ZDROJOVÁ IP adresa sondy

Load Balancer interního modelu stavu používá distribuovanou zkoumací službu. Zkušební služba se nachází na každém hostiteli, kde je možné virtuální počítače naprogramovat na vyžádání tak, aby generoval sondy stavu podle konfigurace zákazníka. Provoz sondy stavu je přímo mezi testovací službou, která generuje sondu stavu, a virtuálním počítačem zákazníka. Všechny Load Balancer stavu pocházejí z IP adresy 168.63.129.16 jako zdroje. Adresní prostor IP adres můžete použít uvnitř virtuální sítě, která není prostorem RFC1918. Při použití globálně vyhrazené IP adresy ve vlastnictví Microsoftu se snižuje pravděpodobnost konfliktu IP adres s adresním prostorem IP adres, který používáte uvnitř virtuální sítě. Tato IP adresa je stejná ve všech oblastech a nemění se a není bezpečnostním rizikem, protože pouze interní komponenta platformy Azure může z této IP adresy získat paket.

Značka služby AzureLoadBalancer identifikuje tuto zdrojovou IP adresu ve skupinách zabezpečení sítě a ve výchozím nastavení povoluje provoz sondy stavu.

Kromě sond Load Balancer stavu používají následující operace tuto IP adresu:

• Umožňuje agentovi virtuálního počítače komunikovat s platformou a signalovat, že je ve stavu Připraveno.
• Umožňuje komunikaci s virtuálním serverem DNS poskytovat filtrovaný překlad názvů zákazníkům, kteří nedefinují vlastní servery DNS. Toto filtrování zajistí, že zákazníci budou moci přeložit pouze název hostitele svého nasazení.
• Umožňuje virtuálnímu počítače získat dynamickou IP adresu ze služby DHCP v Azure.

Pokyny k návrhu

Sondy stavu se používají k tomu, aby vaše služba byla odolná a umožnila škálování. Chybná konfigurace nebo chybný návrhový vzor může mít vliv na dostupnost a škálovatelnost vaší služby. Prohlédněte si celý dokument a zamyslete se nad dopadem na váš scénář, když je tato odpověď sondy označená nebo označená a jaký to má vliv na dostupnost scénáře vaší aplikace.

Při návrhu modelu stavu pro vaši aplikaci byste měli testovat port v koncovém bodu back-endu, který odráží stav této instance a aplikační služby, kterou poskytujete. Port aplikace a port sondy nemusí být stejné. V některých scénářích může být žádoucí, aby se port sondy lichoce od portu, na který vaše aplikace poskytuje službu.

Někdy může být užitečné, když vaše aplikace vygeneruje odpověď sondy stavu, aby nejen detekuje stav vaší aplikace, ale také přímo signalizováno Load Balancer zda má vaše instance přijímat nebo nepřijišťovat nové toky. S odpovědí sondy můžete manipulovat, abyste aplikaci umožnili vytvořit backpressure a ohrobit doručování nových toků do instance tím, že selže sonda stavu nebo se připravíte na údržbu vaší aplikace a zahájíte vyprázdnění scénáře. Při použití Standard Load Balancer bude signál vypnutí sondy vždy umožnovat tokům PROTOKOLU TCP pokračovat, dokud nevypadne časový limit nečinnosti nebo ukončení připojení.

Pro vyrovnávání zatížení UDP byste měli vygenerovat vlastní signál sondy stavu z koncového bodu back-endu a použít sondu stavu TCP, HTTP nebo HTTPS, která cílí na odpovídající naslouchací proces, aby odrážela stav vaší aplikace UDP.

Při použití pravidel vyrovnávání zatížení portů s hasku s Standard Load Balancerse vyrovnává zatížení všech portů a jedna odpověď sondy stavu musí odrážet stav celé instance.

Sondu stavu, která přijímá sondu stavu, nepřikládejte přes proxy server do jiné instance ve vaší virtuální síti, protože tato konfigurace může ve vašem scénáři vést k kaskádovým selháním. Představte si následující scénář: Do back-endového fondu prostředku služby Load Balancer se nasadí sada zařízení třetích stran, která zajišťují škálování a redundanci zařízení, a sonda stavu je nakonfigurovaná tak, aby testoval port, který zařízení třetích stran používá pro servery nebo překládá na jiné virtuální počítače za zařízením. Pokud testujte stejný port, který používáte k překladu nebo proxy požadavků na ostatní virtuální počítače za zařízením, jakákoli odezva sondy z jednoho virtuálního počítače za zařízením označí samotné zařízení jako neschůdné. Tato konfigurace může vést k kaskádovým selháním celého scénáře aplikace v důsledku jednoho koncového bodu back-endu za zařízením. Triggerem může být přerušované selhání sondy, které způsobí, že Load Balancer označí původní cíl (instanci zařízení) a pak může zakázat celý scénář aplikace. Testujte místo toho stav samotného zařízení. Výběr sondy k určení signálu stavu je důležitým aspektem pro scénáře síťových virtuálních zařízení a musíte se obrátit na dodavatele aplikace, jestli je pro takové scénáře vhodný signál stavu.

Pokud v zásadách brány firewall nepovolíte zdrojovou IP adresu sondy, sonda stavu selže, protože se nemůže připojit k vaší instanci. Na druhé Load Balancer označí vaši instanci kvůli selhání sondy stavu. Tato chybné konfigurace může způsobit selhání scénáře aplikace s vyrovnáváním zatížení.

Aby Load Balancer sonda stavu vaší instance označovat, musíte tuto IP adresu povolit ve všech skupinách zabezpečení sítě Azure a zásadách místní brány firewall. Ve výchozím nastavení každá skupina zabezpečení sítě zahrnuje značku služby AzureLoadBalancer, která povoluje provoz sondy stavu.

Pokud chcete otestovat selhání sondy stavu nebo označit jednotlivé instance, můžete pomocí skupin zabezpečení sítě explicitně zablokovat sondu stavu (cílový port nebo zdrojovou IPadresu) a simulovat selhání sondy.

Nekonfigurujte virtuální síť s rozsahem IP adres vlastněný Microsoftem, který obsahuje adresu 168.63.129.16. Tyto konfigurace budou kolidovat s IP adresou sondy stavu a selžou váš scénář.

Pokud máte na virtuálním počítači více rozhraní, musíte se ujisit, že na sondu reagujete v rozhraní, na které jste ji obdrželi. Možná budete muset zdrojovou síťovou adresu přeložit na virtuálním počítači na základě rozhraní.

Nepo povolte časová razítka protokolu TCP. Povolení časových razítek protokolu TCP může způsobit selhání sond stavu kvůli zahození paketů PROTOKOLU TCP zásobníkem protokolu TCP hostového operačního systému virtuálního počítače, Load Balancer označení příslušného koncového bodu. Časová razítka protokolu TCP jsou u imagí virtuálních počítače s pevným zabezpečením ve výchozím nastavení pravidelně povolená a musí být zakázána.

Sledování

Veřejný i interní Standard Load Balancer stav sondy stavu koncového bodu a back-endu zpřístupňuje jako multidimenzionální metriky prostřednictvím Azure Monitor. Tyto metriky mohou využívat jiné služby Azure nebo partnerské aplikace.

Azure Monitor protokoly nejsou k dispozici pro veřejné i interní load balancery basic.

Omezení

• Sondy HTTPS nepodporují vzájemné ověřování s klientským certifikátem.
• Měli byste předpokládat, že sondy stavu selžou, pokud jsou povolená časová razítka protokolu TCP.
• Sonda stavu nástroje pro vyrovnávání zatížení základní SKU není u škálovací sady virtuálních počítačů podporovaná.

Další kroky

• Další informace o Load Balanceru úrovně Standard
• Začínáme vytvářet veřejný nástroj pro vyrovnávání zatížení v Resource Manager pomocí PowerShellu
• REST API pro sondy stavu
• Vyžádání nových schopností sondy stavu Load Balancer uservoice služby