Řešení potíží se stavem prostředků a příchozí dostupností

  • Článek

Tento článek je průvodcem pro zkoumání problémů, které mají vliv na dostupnost front-endových IP adres a back-endových prostředků vašeho nástroje pro vyrovnávání zatížení.

Kontrola stavu prostředku (RHC) pro Load Balancer se používá k určení stavu vašeho nástroje pro vyrovnávání zatížení. Analyzuje metriku dostupnosti cesty k datům za 2 minuty a určí, jestli jsou dostupné koncové body vyrovnávání zatížení, front-endová IP adresa a kombinace front-endových portů s pravidly vyrovnávání zatížení.

Poznámka: Pro Load Balancer úrovně Basic se nepodporuje RHC.

Následující tabulka popisuje logiku RHC používanou k určení stavu vašeho nástroje pro vyrovnávání zatížení.

Stav prostředku Popis
dostupný Váš prostředek load balanceru úrovně Standard je v pořádku a je dostupný.
Snížený výkon Váš standardní nástroj pro vyrovnávání zatížení má události iniciované platformou nebo uživatelem, které mají vliv na výkon. Metrika dostupnosti cesty k datům hlásí, že je to méně než 90 %, ale alespoň 25 % stavu po dobu nejméně dvou minut. Dochází k mírnému až závažnému snížení výkonu.
Neaktivní Váš prostředek load balanceru úrovně Standard není v pořádku. Metrika dostupnosti cesty k datům hlásila alespoň dvě minuty méně než 25 % stavu. Dochází k významnému snížení výkonu nebo nedostatku dostupnosti pro příchozí připojení. Příčinou nedostupnosti může být událostí uživatele nebo platformy.
Neznámý Stav prostředku pro váš prostředek load balanceru úrovně Standard se za posledních 10 minut neaktualizoval ani nepřijal informace o dostupnosti cesty k datům. Tento stav je přechodný a bude odrážet správný stav ihned po přijetí dat.

Informace o metrikách, které používáme

Dvě metriky, které se mají použít, jsou dostupnost cesty k datům a stav sondy stavu a je důležité pochopit jejich význam pro odvození správných přehledů.

Dostupnost cesty k datům

Metrika dostupnosti cesty k datům je generována příkazem PING tcp každých 25 sekund na všech front-endových portech, které mají nakonfigurovaná pravidla vyrovnávání zatížení a příchozího překladu adres (NAT). Tento příkaz PING protokolu TCP se směruje na všechny instance back-endu, které jsou v pořádku (vysílané). Pokud služba obdrží odpověď na příkaz ping, jedná se o úspěšnou odpověď a součet metriky se jednou iteuje. Pokud neexistuje žádná odpověď, nedojde k žádné iteraci. Počet této metriky je 1/100 z celkového počtu příkazů PING tcp za vzorkovací období. Proto chceme vzít v úvahu průměr, což je průměr součtu a počtu pro časové období. Data ukazují metriku dostupnosti cesty agregovanou průměrem, takže nám dává procento úspěšnosti příkazů TCP ping na front-endové IP adrese:port pro každé z vašich pravidel vyrovnávání zatížení a příchozího překladu adres (NAT).

Stav sondy stavu

Metrika stavu sondy stavu se generuje příkazem ping protokolu definovaného v sondě stavu. Tento příkaz ping se odešle do každé instance v back-endovém fondu a na portu definovaném v sondě stavu. U sond HTTP a HTTPS vyžaduje úspěšný příkaz ping odpověď HTTP 200 OK, zatímco u sond TCP se jakákoli odpověď považuje za úspěšnou. Po sobě jdoucí úspěch nebo selhání každé sondy určují stav instance back-endu a to, jestli je přiřazený back-endový fond schopný přijímat provoz. Podobně jako dostupnost cesty k datům používáme průměrnou agregaci, která nám během intervalu vzorkování říká průměrné úspěšné a celkové příkazy ping. Tato hodnota stavu sondy stavu označuje stav back-endu izolovaně od vašeho nástroje pro vyrovnávání zatížení tím, že kontroluje instance back-endu bez odesílání provozu přes front-end.

Důležité

Stav sondy stavu se vzorkuje na jednu minutu. To může vést k menším výkyvům v jinak stabilní hodnotě. Pokud jsou například dvě instance back-endu, jedna probírá se a jedna probírá dolů, může služba sondy stavu zaznamenat 7 vzorků pro instanci, která je v pořádku, a 6 pro instanci, která není v pořádku. To povede k dříve stabilní hodnotě 50, která se zobrazí jako 46,15 po dobu jedné minuty.

Diagnostika degradovaných a nedostupných nástrojů pro vyrovnávání zatížení

Jak je uvedeno v článku o stavu prostředků, degradovaný nástroj pro vyrovnávání zatížení je ten, který ukazuje dostupnost cesty k datům mezi 25 % a 90 %. Nedostupný nástroj pro vyrovnávání zatížení je jeden s dostupností cesty k datům menší než 25 % během dvouminutového období. Stejným postupem můžete prošetřit selhání, které vidíte v jakémkoli stavu sondy stavu nebo upozorněních na dostupnost cesty k datům, které jste nakonfigurovali. Podíváme se na případ, kdy jsme zkontrolovali stav prostředků a zjistili jsme, že nástroj pro vyrovnávání zatížení je nedostupný s dostupností cesty k datům 0 % – naše služba je mimo provoz.

Nejprve přejdeme na podrobné zobrazení metrik na stránce přehledů nástroje pro vyrovnávání zatížení na webu Azure Portal. Přejděte k zobrazení ze stránky prostředku nástroje pro vyrovnávání zatížení nebo odkazu ve zprávě o stavu prostředku. Dále přejdeme na kartu Dostupnost front-endu a back-endu a zkontrolujeme třicetminutové časové období, kdy došlo ke zhoršení nebo nedostupnosti stavu. Pokud vidíme dostupnost cesty k datům 0 %, víme, že došlo k problému, který brání provozu pro všechna naše pravidla vyrovnávání zatížení a příchozího překladu adres (NAT) a vidíme, jak dlouho tento problém trval.

Dalším místem, kde musíme hledat, je metrika stavu sondy stavu, abychom zjistili, jestli je cesta k datům nedostupná, protože nemáme žádné instance back-endu, které jsou v pořádku, abychom mohli obsluhovat provoz. Pokud máme alespoň jednu instanci back-endu, která je v pořádku pro všechna pravidla vyrovnávání zatížení a příchozích přenosů, víme, že není naše konfigurace, což způsobuje nedostupnost cest k datům. Tento scénář označuje problém s platformou Azure. I když problémy s platformou jsou vzácné, pošle se našemu týmu automatizovaná výstraha, která rychle vyřeší všechny problémy s platformou.

Diagnostika selhání sond stavu

Řekněme, že zkontrolujeme stav sondy stavu a zjistíme, že všechny instance se zobrazují jako poškozené. Toto hledání vysvětluje, proč je naše cesta k datům nedostupná, protože provoz nemá kam jít. Pak bychom měli projít následující kontrolní seznam, abychom vyloučili běžné chyby konfigurace:

  • Zkontrolujte využití procesoru pro vaše prostředky a zjistěte, jestli jsou pod vysokým zatížením.
  • Pokud používáte sondu HTTP nebo HTTPS, zkontrolujte, jestli je aplikace v pořádku a reaguje.
    • Ověřte funkčnost aplikace přímým přístupem k aplikacím prostřednictvím privátní IP adresy nebo veřejné IP adresy na úrovni instance přidružené k vaší back-endové instanci.
  • Zkontrolujte skupiny zabezpečení sítě použité u našich back-endových prostředků. Ujistěte se, že neexistují žádná pravidla s vyšší prioritou než AllowAzureLoadBalancerInBound , která blokuje sondu stavu.
    • Můžete to udělat tak, že navštívíte nastavení sítě back-endových virtuálních počítačů nebo škálovacích sad virtuálních počítačů.
    • Pokud zjistíte, že se jedná o problém se skupinou zabezpečení sítě, přesuňte stávající pravidlo Povolit nebo vytvořte nové pravidlo s vysokou prioritou, které povolí provoz AzureLoadBalancer.
  • Zkontrolujte operační systém. Ujistěte se, že vaše virtuální počítače naslouchají na portu sondy, a zkontrolujte pravidla brány firewall operačního systému a ujistěte se, že neblokují provoz sondy pocházející z IP adresy 168.63.129.16.
    • Naslouchající porty můžete zkontrolovat spuštěním netstat -a z příkazového řádku Windows nebo netstat -l z terminálu Linuxu.
  • Ujistěte se, že používáte správný protokol. Například sonda využívající protokol HTTP k oslouchající port pro aplikaci, která není http, selže.
  • Azure Firewall by neměl být umístěný v back-endovém fondu nástrojů pro vyrovnávání zatížení. Informace o správné integraci služby Azure Firewall se službou Azure Standard Load Balancer najdete v tématu Integrace služby Azure Firewall s nástrojem pro vyrovnávání zatížení.

Pokud jste prošli tímto kontrolním seznamem a stále hledáte selhání sond stavu, můžou se vyskytovat vzácné problémy s platformou, které mají vliv na službu sondy pro vaše instance. V tomto případě má Azure váš záda a pošle se našemu týmu automatizovaná výstraha, která rychle vyřeší všechny problémy s platformou.

Další kroky