Vysoká dostupnost a vyrovnávání zatížení vašich privátních síťových konektorů a aplikací

Článek
04/13/2024

Tento článek vysvětluje, jak funguje distribuce provozu s nasazením proxy serveru aplikace. Zjistěte, jak se provoz distribuuje mezi uživatele a konektory, a tipy pro optimalizaci výkonu konektoru. Zjistěte, jak provoz proudí mezi konektory a servery back-endových aplikací s doporučeními pro vyrovnávání zatížení mezi několika back-endovými servery.

Distribuce provozu mezi konektory

Připojení orům navazují svá připojení na základě principů pro zajištění vysoké dostupnosti. Neexistuje žádná záruka, že se provoz rovnoměrně distribuuje mezi konektory a že neexistuje spřažení relací. Využití se ale liší a požadavky se náhodně odesílají do instancí proxy aplikací. V důsledku toho se provoz obvykle distribuuje téměř rovnoměrně mezi konektory. Diagram a postup ukazují, jak jsou připojení vytvořena mezi uživateli a konektory.

Diagram znázorňující připojení mezi uživateli a konektory

Uživatel na klientském zařízení se pokusí získat přístup k místní aplikaci publikované prostřednictvím proxy aplikací.
Tento požadavek prochází službou Azure Load Balancer a zjišťuje, která instance služby proxy aplikací by měla požadavek přijmout. K dispozici jsou desítky instancí, které přijímají požadavky na veškerý provoz v dané oblasti. Tato metoda pomáhá rovnoměrně distribuovat provoz napříč instancemi služby.
Požadavek se odešle do služby Service Bus.
Service Bus signalizuje dostupný konektor. Konektor pak převezme požadavek ze služby Service Bus.
- V kroku 2 požadavky přejdou do různých instancí proxy aplikací, takže připojení budou pravděpodobně vytvořená s různými konektory. V důsledku toho se konektory ve skupině používají téměř rovnoměrně.
Konektor předá požadavek na back-endový server aplikace. Aplikace pak odešle odpověď zpět do konektoru.
Konektor dokončí odpověď otevřením odchozího připojení k instanci služby, ze které žádost přišla. Poté se toto připojení okamžitě zavře. Ve výchozím nastavení je každý konektor omezen na 200 souběžných odchozích připojení.
Odpověď se pak předá klientovi z instance služby.
Další požadavky ze stejného připojení opakují kroky.

Aplikace má často mnoho prostředků a otevírá více připojení při zatížení. Každé připojení prochází kroky, které se přidělují instanci služby. Pokud připojení není spárované s konektorem, vyberte nový dostupný konektor.

Osvědčené postupy pro vysokou dostupnost konektorů

Vzhledem k tomu, jak se provoz distribuuje mezi konektory pro zajištění vysoké dostupnosti, je důležité mít vždy aspoň dva konektory ve skupině konektorů. Preferují se tři konektory, které poskytují mezi spojnicemi další vyrovnávací paměť. Pokud chcete určit správný počet potřebných konektorů, postupujte podle dokumentace k plánování kapacity.
Umístěte konektory na různá odchozí připojení, abyste se vyhnuli jedinému bodu selhání. Pokud konektory používají stejné odchozí připojení, má problém se sítí dopad na všechny konektory, které ho používají.
Vyhněte se vynucení restartování konektorů při připojení k produkčním aplikacím. To by mohlo negativně ovlivnit distribuci provozu mezi konektory. Restartování konektorů způsobí nedostupnost více konektorů a vynutí připojení ke zbývajícímu dostupnému konektoru. Výsledkem je nerovnoměrné použití spojnic na začátku.
Vyhněte se všem formám vložené kontroly odchozí komunikace TLS (Transport Layer Security) mezi konektory a Azure. Tento typ vložené kontroly způsobuje zhoršení komunikačního toku.
Nezapomeňte udržovat automatické aktualizace spuštěné pro vaše konektory. Pokud je spuštěná služba Updater privátního síťového konektoru, vaše konektory se aktualizují automaticky a obdrží nejnovější upgrade. Pokud na serveru nevidíte službu Připojení or Updater, musíte konektor přeinstalovat, abyste získali aktualizace.

Tok provozu mezi konektory a back-endovými aplikačními servery

Další klíčovou oblastí, ve které je vysoká dostupnost faktorem, je propojení mezi konektory a back-endovými servery. Když je aplikace publikovaná prostřednictvím proxy aplikací Microsoft Entra, provoz od uživatelů do aplikací prochází třemi segmenty směrování:

Uživatel se připojí k veřejnému koncovému bodu proxy aplikace Microsoft Entra v Azure. Připojení se vytvoří mezi původní IP adresou klienta (veřejnou) a IP adresou koncového bodu proxy aplikace.
Privátní síťový konektor načítá požadavek HTTP klienta ze služby proxy aplikací.
Privátní síťový konektor se připojí k cílové aplikaci. Konektor používá k navázání připojení vlastní IP adresu.

Diagram uživatele, který se připojuje k aplikaci přes proxy aplikace

Důležité informace o polích hlavičky X-Forwarded-For

V některých situacích (například auditování, vyrovnávání zatížení atd.) je potřeba sdílet původní IP adresu externího klienta s místním prostředím. K vyřešení požadavku přidá privátní síťový konektor Microsoft Entra pole hlavičky X-Forwarded-For s původní IP adresou klienta (veřejné) do požadavku HTTP. Příslušné síťové zařízení (nástroj pro vyrovnávání zatížení, brána firewall) nebo webová nebo back-endová aplikace pak mohou tyto informace číst a používat.

Osvědčené postupy pro vyrovnávání zatížení mezi několika aplikačními servery

Vyrovnávání zatížení je důležité, pokud má skupina konektorů přiřazená aplikaci proxy aplikací dva nebo více konektorů. Vyrovnávání zatížení je také důležité, když používáte back-endovou webovou aplikaci na více serverech.

Scénář 1: Back-endová aplikace nevyžaduje trvalost relace

Nejjednodušším scénářem je situace, kdy back-endová webová aplikace nevyžaduje trvalost relace (trvalost relace). Instance back-endové aplikace zpracovává požadavky uživatelů v serverové farmě. Můžete použít nástroj pro vyrovnávání zatížení vrstvy 4 a nakonfigurovat ho bez spřažení. Mezi některé možnosti patří Vyrovnávání zatížení sítě Microsoftu a Azure Load Balancer nebo nástroj pro vyrovnávání zatížení od jiného dodavatele. Případně nakonfigurujte strategii DNS (Domain Name System) s kruhovým dotazem.

Scénář 2: Back-endová aplikace vyžaduje trvalost relace

V tomto scénáři vyžaduje back-endová webová aplikace během ověřené relace stickiness (trvalost relace). Instance back-endové aplikace zpracovává požadavky uživatelů. Požadavky se spouštějí na stejném serveru ve serverové farmě. Tento scénář může být složitější, protože klient obvykle vytváří více připojení ke službě proxy aplikací. Požadavky na různá připojení můžou dorazit na různé konektory a servery ve farmě. Vzhledem k tomu, že každý konektor používá pro tuto komunikaci vlastní IP adresu, nástroj pro vyrovnávání zatížení nemůže zajistit trvalost relace na základě IP adresy konektorů. Spřažení zdrojových IP adres se nedá použít. Tady je několik možností pro scénář 2:

Možnost 1: Založte trvalost relace na souboru cookie relace nastaveném nástrojem pro vyrovnávání zatížení. Tato možnost se doporučuje, protože umožňuje rovnoměrněji rozložit zatížení mezi back-endové servery. Vyžaduje nástroj pro vyrovnávání zatížení vrstvy 7 s touto funkcí, který dokáže zpracovat provoz HTTP a ukončit připojení TLS. Můžete použít Aplikace Azure Gateway (spřažení relací) nebo nástroj pro vyrovnávání zatížení od jiného dodavatele.
Možnost 2: Založte trvalost relace na poli hlavičky X-Forwarded-For. Tato možnost vyžaduje nástroj pro vyrovnávání zatížení vrstvy 7 s touto funkcí, který dokáže zpracovat provoz HTTP a ukončit připojení TLS.
Možnost 3: Nakonfigurujte back-endovou aplikaci tak, aby nevyžaduje trvalost relace.

Informace o požadavcích na vyrovnávání zatížení back-endové aplikace najdete v dokumentaci dodavatele softwaru.

Sdílet prostřednictvím