Sdílet prostřednictvím

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

Tento článek vysvětluje, jak distribuce provozu funguje při nasazení aplikačního proxy serveru. 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

Konektory 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 ani že existuje 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

  1. Uživatel na klientském zařízení se pokusí získat přístup k místní aplikaci publikované prostřednictvím proxy aplikací.
  2. 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.
  3. Požadavek je odeslán na službu Service Bus.
  4. 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í aplikační proxy služby, takže je pravděpodobnější, že připojení budou vytvořena s různými konektory. V důsledku toho se konektory ve skupině používají téměř rovnoměrně.
  5. Konektor předá požadavek na back-endový server aplikace. Aplikace pak odešle odpověď zpět do konektoru.
  6. 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í.
  7. Odpověď se pak předá klientovi z instance služby.
  8. Další požadavky ze stejného připojení opakují stejné kroky.

Aplikace má často mnoho prostředků a při zatížení otevírá více připojení. Každé připojení prochází kroky k přidělení 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 jako dodatečná ochrana mezi spoji. 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 kontroly v průběhu odchozí komunikace prostřednictvím 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 Connector Updater, musíte konektor přeinstalovat, abyste získali všechny aktualizace.

Tok provozu mezi konektory a backendový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 publikována prostřednictvím aplikačního proxy serveru Microsoft Entra, provoz od uživatelů k aplikacím prochází třemi skoky:

  1. 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.
  2. Privátní síťový konektor načítá požadavek HTTP klienta ze služby proxy aplikací.
  3. 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é, když má skupina konektorů přiřazená proxy aplikaci 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, když back-endová webová aplikace nevyžaduje trvalost relace. Instance back-endové aplikace zpracovává požadavky uživatelů v serverové farmě. Můžete použít vyrovnávač zatížení vrstvy 4 a nakonfigurovat ho bez afinity. 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 round-robin strategii DNS (Domain Name System).

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 soudržnost relace (trvalost relace). Instance back-endové aplikace zpracovává požadavky uživatelů. Požadavky běží na stejném serveru v 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 nelze 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 Azure Application Gateway (Spřažení relací) nebo vyrovnávač 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.

Další kroky