Řešení Azure Load Balancer odezvy back-endového provozu
Tato stránka obsahuje informace o řešení potíží Azure Load Balancer dotazy.
Virtuální počítače za Load Balancer přechádřující nerovnoměrné rozdělení provozu
Pokud máte podezření, že členové back-endového fondu dostávají provoz, může to být z následujících důvodů. Azure Load Balancer distribuuje provoz na základě připojení. Nezapomeňte zkontrolovat distribuci provozu pro připojení, a ne pro jednotlivé pakety. Ověřte to pomocí Flow distribuce na předem nakonfigurované Load Balancer Přehledy řídicím panelu.
Mějte na Azure Load Balancer, že nepodporuje vyrovnávání zatížení založené na skutečném kruhovém dotazování, ale podporuje distribuční režim založený na hodnotách hash.
Příčina 1: Máte nakonfigurovanou trvalost relace.
Použití distribučního režimu trvalosti zdroje může způsobit nerovnoměrné rozdělení provozu. Pokud to není žádoucí, je trvalost relace aktualizace nastavená na Žádné, takže provoz se distribuuje mezi všechny instance, které jsou v pořádku, v back-endového fondu. Další informace o režimech distribuce pro Azure Load Balancer.
Příčina 2: Máte nakonfigurovaný proxy server
Klienti, kteří běží za nástroji prox, mohou být z pohledu Load Balancer za jednou jedinečnou klientskou aplikací.
Virtuální počítače za Load Balancer nereagují na provoz na nakonfigurovaných datových portech
Pokud je virtuální počítač back-endového fondu uvedený jako v pořádku a reaguje na sondy stavu, ale stále se neúčastní vyrovnávání zatížení nebo nereaguje na datový provoz, může to být z následujících důvodů:
- Load Balancer virtuální počítač back-endový fond nenaslouchá na datovém portu
- Skupina zabezpečení sítě blokuje port na virtuálním počítači Load Balancer back-endový fond.
- Přístup k Load Balancer ze stejného virtuálního počítače a síťové karty
- Přístup k internetovému Load Balancer z virtuálního počítače Load Balancer back-endový fond
Příčina 1: Load Balancer virtuální počítač back-end fondu nenaslouchá na datovém portu
Pokud virtuální počítač na datový provoz nereaguje, může to být buď kvůli tomu, že cílový port není na zapojených virtuálních počítači otevřený, nebo virtuální počítač na tomto portu nenaslouchá.
Ověřování a řešení
- Přihlaste se k back-endu virtuálního počítače.
- Otevřete příkazový řádek a spuštěním následujícího příkazu ověřte, že na datovém portu naslouchá aplikace:
netstat -an - Pokud port není uvedený se stavem LISTENING, nakonfigurujte správný port naslouchacího procesu.
- Pokud je port označený jako Naslouchání, zkontrolujte případné problémy v cílové aplikaci na tomto portu.
Příčina 2: Skupina zabezpečení sítě blokuje port na virtuálním počítači Load Balancer back-endový fond
Pokud jedna nebo více skupin zabezpečení sítě nakonfigurovaných v podsíti nebo na virtuálním počítači blokuje zdrojovou IP adresu nebo port, virtuální počítač nemůže reagovat.
Pro veřejný nástroj pro vyrovnávání zatížení se IP adresa internetových klientů použije ke komunikaci mezi klienty a back-endové virtuální počítače nástroje pro vyrovnávání zatížení. Ujistěte se, že ip adresa klientů je povolená ve skupině zabezpečení sítě virtuálního počítače back-endu.
- Vy list the network security groups configured on the back-end VM. Další informace najdete v tématu Správa skupin zabezpečení sítě.
- V seznamu skupin zabezpečení sítě zkontrolujte, jestli:
- Příchozí nebo odchozí provoz na datovém portu má interference.
- Pravidlo Odepřít všechny skupiny zabezpečení sítě na síťovém rozhraní virtuálního počítače nebo podsítě s vyšší prioritou, které povoluje testy Load Balancer provoz Load Balancer (skupiny zabezpečení sítě musí povolit IP adresu 168.63.129.16, což je port sondy).
- Pokud některý z pravidel blokuje provoz, odeberte tato pravidla a znovu je nakonfigurujte tak, aby povoloval datový provoz.
- Otestujte, jestli teď virtuální počítač začal reagovat na sondy stavu.
Příčina 3: Přístup k Load Balancer ze stejného virtuálního počítače a síťového rozhraní
Pokud se vaše aplikace hostovaná na back-end virtuálním počítači Load Balancer pokouší získat přístup k jiné aplikaci hostované ve stejném back-end virtuálním počítači přes stejné síťové rozhraní, jedná se o nepodporovaný scénář a selže.
Rozlišení Tento problém můžete vyřešit pomocí jedné z následujících metod:
- Nakonfigurujte samostatné virtuální počítače back-endu pro každou aplikaci.
- Nakonfigurujte aplikaci na virtuálních počítač se dvěma síťovými kartami, aby každá aplikace měla vlastní síťové rozhraní a IP adresu.
Příčina 4: Přístup k internímu Load Balancer front-endu ze zapojených virtuálních Load Balancer back-endový fond
Pokud je interní Load Balancer nakonfigurovaný uvnitř virtuální sítě a jeden z účastnických back-endových virtuálních počítače se pokouší o přístup k internímu front-endu Load Balancer, může dojít k selháním při mapování toku na původní virtuální počítač. Takový scénář se nepodporuje.
Rozlišení Existuje několik způsobů, jak tento scénář odblokovat, včetně použití proxy serveru. Vyhodnoťte Application Gateway proxy nebo jiné proxy služby třetích stran (například nginx nebo haproxy). Další informace o Application Gateway najdete v tématu Přehled Application Gateway
Podrobnosti Interní nástroje pro vyrovnávání zatížení nevykládají odchozí připojení k front-endu interního serveru Load Balancer protože oba jsou v privátním adresní prostoru IP adres. Veřejné nástroje pro vyrovnávání zatížení poskytují odchozí připojení z privátních IP adres v rámci virtuální sítě k veřejným IP adresám. U interních load balancerů tento přístup zabraňuje potenciálnímu vyčerpání portů SNAT v rámci jedinečného interního adresního prostoru IP adres, kde se překlad nevyžaduje.
Vedlejším efektem je, že pokud se odchozí tok z virtuálního počítače v back-end fondu pokusí tok do front-endu interního Load Balancer ve svém fondu a je namapovaný zpátky na sebe, dva části toku se neshodují. Protože se neshodují, tok selže. Tok bude úspěšný, pokud se tok nenamapuje zpět na stejný virtuální počítač v back-endového fondu, který vytvořil tok do front-endu.
Když se tok mapuje sám na sebe, zdá se, že odchozí tok pochází z virtuálního počítače do front-endu a odpovídající příchozí tok sám o sobě pochází z virtuálního počítače. Z pohledu hosta operačního systému se příchozí a odchozí části stejného toku neshodují uvnitř virtuálního počítače. Zásobník protokolu TCP nerozpozná tyto poloviny stejného toku jako součást stejného toku. Zdroj a cíl se neshodují. Když se tok mapuje na jakýkoli jiný virtuální počítač v back-end fondu, poloviny toku se shodují a virtuální počítač může na tok reagovat.
Příznakem tohoto scénáře jsou přerušované časové limity připojení, když se tok vrátí do stejného back-endu, ze kterého tok pochází. Mezi běžná alternativní řešení patří vložení vrstvy proxy serveru za interní Load Balancer a použití pravidel stylu direct server return (DSR). Další informace najdete v tématu Více front-endů pro Azure Load Balancer.
Můžete kombinovat interní Load Balancer s proxy serverem třetí strany nebo použít interní Application Gateway scénáře proxy s HTTP/HTTPS. K zmírnění tohoto problému můžete Load Balancer veřejný prostor, ale výsledný scénář je náchylný k vyčerpání SNAT. Vyhněte se tomuto druhému přístupu, pokud ho pečlivě nespravujte.
Další kroky
Pokud předchozí kroky problém nevyřeší, otevřete lístek podpory.