Share via

Erőforrás állapotának és bejövő rendelkezésre állási problémáinak elhárítása

  • Cikk

Ez a cikk útmutató a terheléselosztó előtérbeli IP-címének és háttérerőforrásainak rendelkezésre állását befolyásoló problémák vizsgálatához.

A Terheléselosztó erőforrás-állapot-ellenőrzése (RHC) a terheléselosztó állapotának meghatározására szolgál. 2 perces időközönként elemzi az adatelérési útvonal rendelkezésre állási metrikáját annak megállapításához, hogy elérhetők-e a terheléselosztási végpontok, az előtérbeli IP-cím és az előtérbeli portok és a terheléselosztási szabályok.

Megjegyzés: Az RHC nem támogatott az alapszintű termékváltozatú Load Balancer esetében

Az alábbi táblázat a terheléselosztó állapotának meghatározására használt RHC-logikát ismerteti.

Erőforrás állapotadatai Leírás
Elérhető A standard terheléselosztó-erőforrás kifogástalan állapotú és elérhető.
Csökkentett teljesítményű A standard terheléselosztó platformmal vagy felhasználó által kezdeményezett eseményekkel rendelkezik, ami hatással van a teljesítményre. A Datapath rendelkezésre állási metrika 90%-nál kisebb, de legalább két percig 25%-nál nagyobb állapotban jelent meg. Közepes vagy súlyos teljesítménycsökkenést tapasztal.
Nem érhető el A standard terheléselosztó-erőforrás nem kifogástalan. A Datapath rendelkezésre állási metrika legalább két percig kevesebb, mint 25%-os állapotot jelentett. Jelentős teljesítménycsökkenést vagy a bejövő kapcsolatok rendelkezésre állásának hiányát tapasztalja. Előfordulhatnak olyan felhasználói vagy platformesemények, amelyek elérhetetlenséget okoznak.
Ismeretlen A standard terheléselosztó erőforrásának erőforrásállapota az elmúlt 10 percben nem frissítette vagy kapta meg az adatelérési út rendelkezésre állási adatait. Ez az állapot átmeneti, és az adatok beérkezésekor helyes állapotot fog tükrözni.

Az általunk használt metrikák ismertetése

A két használandó metrika az adatelérési út rendelkezésre állása és az állapotadat-mintavétel állapota , és fontos megérteni a jelentésüket a helyes megállapítások kinyeréséhez.

Adatútvonalak rendelkezésre állása

Az adatelérési útvonal rendelkezésre állási metrikáját 25 másodpercenként egy TCP-ping hozza létre minden olyan előtérporton, amelyen terheléselosztási és bejövő NAT-szabályok vannak konfigurálva. Ezt a TCP-pinget a rendszer az kifogástalan állapotú (mintavételezett) háttérpéldányokhoz irányítja. Ha a szolgáltatás választ kap a pingelésre, az sikeres válasz, és a metrika összege egyszer lesz iterálva. Ha nincs válasz, nem történik iteráció. A metrika száma a mintaidőszakonkénti összes TCP-ping 1/100-a. Ezért az átlagot szeretnénk figyelembe venni, amely az időszak összegének/darabszámának átlaga. Az adatok az elérési út átlagosan összesített rendelkezésre állási metrikáit jelenítik meg, így százalékos sikert adnak a TCP-pingek az előtérbeli IP:porton az egyes terheléselosztási és bejövő NAT-szabályok esetében.

Állapotadat-mintavétel állapota

Az állapotadat-mintavétel állapotmetrikája az állapotadat-mintavételben meghatározott protokoll pingelésével jön létre. Ezt a pingelést a rendszer a háttérkészlet minden példányára és az állapotadat-mintavételben meghatározott portra küldi. HTTP- és HTTPS-mintavételek esetén a sikeres pingeléshez HTTP 200 OK-válasz szükséges, míg a TCP-mintavételekkel minden válasz sikeresnek tekinthető. Az egyes mintavételek egymást követő sikerei vagy hibái határozzák meg a háttérpéldány állapotát, és hogy a hozzárendelt háttérkészlet képes-e fogadni a forgalmat. Az adatelérési út rendelkezésre állásához hasonlóan az átlagos összesítést használjuk, amely a mintavételezési időköz során az átlagos sikeres/teljes pingelést mutatja. Ez az állapotadat-mintavétel állapotértéke a háttérrendszer állapotát jelzi a terheléselosztótól elkülönítve úgy, hogy a háttérpéldányokat úgy irányítja ki, hogy nem küld forgalmat az előtéren keresztül.

Fontos

Az állapotadat-mintavétel állapotának mintavétele egy perc alapon történik. Ez kisebb ingadozásokhoz vezethet egy egyébként állandó értékben. Ha például két háttérpéldány, egy mintavételezett és egy le mintavételezett példány van, az állapotadat-mintavételi szolgáltatás 7 mintát rögzíthet az kifogástalan példányhoz, 6 pedig a nem kifogástalan állapotú példányhoz. Ez egy korábban stabil 50-höz vezet, amely 46,15 egyperces időközzel jelenik meg.

Csökkentett és nem elérhető terheléselosztók diagnosztizálása

Az erőforrás-állapotról szóló cikkben leírtak szerint a csökkentett terheléselosztó az adatelérési út 25–90%-os rendelkezésre állását mutatja. A nem elérhető terheléselosztó egy olyan, amelynek az adatelérési útja kevesebb mint 25%-os rendelkezésre állással rendelkezik, kétperces időtartam alatt. Ugyanezeket a lépéseket követve kivizsgálhatja a konfigurált állapotadat-mintavételi állapotban vagy az adatelérési útvonal rendelkezésre állási riasztásaiban megjelenő hibát. Megvizsgáltuk azt az esetet, amikor ellenőriztük az erőforrás állapotát, és úgy találtuk, hogy a terheléselosztó nem érhető el 0%-os adatelérési úttal – szolgáltatásunk leállt.

Először az Azure Portal terheléselosztó-elemzési oldalának részletes metrikák nézetét tekintjük meg. A nézetet a terheléselosztó erőforráslapjáról vagy az erőforrásállapot-üzenet hivatkozásából érheti el. Ezután a Frontend és a Háttér rendelkezésre állás lapjára lépünk, és áttekintjük annak az időszaknak a harminc perces időszakát, amikor a csökkentett vagy elérhetetlen állapot történt. Ha azt látjuk, hogy az adatelérési útvonal rendelkezésre állása 0%, tudjuk, hogy probléma van a terheléselosztási és bejövő NAT-szabályok forgalmának megakadályozásával, és láthatjuk, hogy mennyi ideig tartott ez a probléma.

A következő hely, ahol meg kell vizsgálnunk az állapotadat-mintavétel állapotát mérő metrikát annak megállapításához, hogy az adatelérési útvonal nem érhető-e el, mert nincsenek kifogástalan háttérpéldányaink a forgalom kiszolgálásához. Ha rendelkezünk legalább egy kifogástalan háttérpéldánysal az összes terheléselosztási és bejövő szabályunkhoz, tudjuk, hogy nem a mi konfigurációnk miatt nem érhetők el az adatelérési utak. Ez a forgatókönyv egy Azure-platformmal kapcsolatos problémát jelez. Bár a platformokkal kapcsolatos problémák ritkán fordulnak elő, a rendszer automatikus riasztást küld a csapatunknak az összes platformmal kapcsolatos probléma gyors megoldásához.

Állapotadat-mintavétel hibáinak diagnosztizálása

Tegyük fel, hogy ellenőrizzük az állapotadat-mintavétel állapotát, és megállapítjuk, hogy az összes példány kifogástalan állapotúként jelenik meg. Ez a megállapítás azt magyarázza, hogy az adatelérési útvonal miért nem érhető el, mivel a forgalomnak nincs hová mennie. Ezután az alábbi ellenőrzőlistán kell végighaladnunk, hogy kizárhassuk a gyakori konfigurációs hibákat:

  • Ellenőrizze az erőforrások cpu-kihasználtságát annak megállapításához, hogy nagy terhelés alatt vannak-e.
  • HA HTTP- vagy HTTPS-mintavételt használ, ellenőrizze, hogy az alkalmazás kifogástalan és rugalmas-e.
    • Ellenőrizze, hogy az alkalmazás működik-e, ha közvetlenül a háttérpéldányhoz társított magánhálózati IP-címen vagy példányszintű nyilvános IP-címen keresztül éri el az alkalmazásokat.
  • Tekintse át a háttérerőforrásainkra alkalmazott hálózati biztonsági csoportokat. Győződjön meg arról, hogy nincsenek magasabb prioritású szabályok, mint az AllowAzureLoadBalancerInBound , amely blokkolja az állapotmintát.
    • Ezt a háttérbeli virtuális gépek vagy virtuálisgép-méretezési csoportok hálózatkezelési beállításainak megtekintésével teheti meg.
    • Ha ezt az NSG-problémát tapasztalja, helyezze át a meglévő Engedélyezési szabályt, vagy hozzon létre egy új magas prioritású szabályt az AzureLoadBalancer-forgalom engedélyezéséhez.
  • Ellenőrizze az operációs rendszert. Győződjön meg arról, hogy a virtuális gépek figyelik a mintavételi portot, és áttekintik az operációs rendszer tűzfalszabályait, hogy ne blokkolják az IP-címről 168.63.129.16származó mintavételi forgalmat.
    • A figyelési portokat windowsos parancssorból vagy netstat -l Linux-terminálról futtatva netstat -a ellenőrizheti.
  • Győződjön meg arról, hogy a megfelelő protokollt használja. Egy HTTP-t használó mintavétel például nem HTTP-alkalmazás portfigyelőinek mintavétele meghiúsul.
  • Az Azure Firewall nem helyezhető el a terheléselosztók háttérkészletében. Az Azure Firewall integrálása az Azure Standard Load Balancerrel az Azure Firewall és a terheléselosztó megfelelő integrálásához című témakörben olvashat.

Ha áttekinti ezt az ellenőrzőlistát, és továbbra is állapotadat-mintavételi hibákat talál, előfordulhat, hogy ritka platformproblémák érintik a példányok mintavételi szolgáltatását. Ebben az esetben az Azure-nak van a háta, és a rendszer automatikus riasztást küld a csapatunknak az összes platformmal kapcsolatos probléma gyors megoldásához.

Következő lépések