Hochverfügbarkeit und Lastenausgleich von privaten Netzwerkconnectors und -Anwendungen
In diesem Artikel wird erläutert, wie die Verteilung des Datenverkehrs mit Ihrer Anwendungsproxybereitstellung funktioniert. Sie erfahren, wie der Datenverkehr auf Benutzer und Connectors verteilt wird, und erhalten Tipps zur Optimierung der Connectorleistung. Sie erfahren außerdem, wie Datenverkehr zwischen Connectors und Back-End-App-Servern übertragen wird, und erhalten Empfehlungen für den Lastenausgleich zwischen mehreren Back-End-Servern.
Verteilung des Datenverkehrs auf Connectors
Connectors richten Verbindungen basierend auf den Prinzipien für Hochverfügbarkeit ein. Es gibt keine Garantie dafür, dass der Datenverkehr gleichmäßig auf Connectors verteilt wird, und es besteht keine Sitzungsaffinität. Die Verwendung variiert jedoch, und Anforderungen werden nach dem Zufallsprinzip an die Dienstinstanzen des Anwendungsproxys gesendet. Daher wird der Datenverkehr in der Regel fast gleichmäßig auf die Connectors verteilt. Die Abbildung und die Schritte veranschaulichen, wie Verbindungen zwischen Benutzern und Connectors hergestellt werden.
- Ein Benutzer auf einem Clientgerät versucht, auf eine lokale Anwendung zuzugreifen, die über den Anwendungsproxy veröffentlicht wurde.
- Die Anforderung durchläuft eine Azure Load Balancer-Instanz, die festlegt, welche Anwendungsproxy-Dienstinstanzen die Anforderung übernehmen sollen. Es sind Dutzende von Instanzen verfügbar, um die Anforderungen für den gesamten Datenverkehr in der Region zu akzeptieren. Mit dieser Methode kann der Datenverkehr gleichmäßig auf die Dienstinstanzen verteilt werden.
- Die Anforderung wird an Service Bus gesendet.
- Service Bus sendet ein Signal an einen verfügbaren Connector. Der Connector übernimmt die Anforderung dann von Service Bus.
- In Schritt 2 werden Anforderungen an verschiedene Anwendungsproxy-Dienstinstanzen gesendet, sodass Verbindungen eher mit unterschiedlichen Connectors hergestellt werden. Folglich werden Connectors fast gleichmäßig innerhalb der Gruppe verwendet.
- Der Connector übergibt die Anforderung an den Back-End-Server der Anwendung. Die Anwendung sendet dann die Antwort an den Connector zurück.
- Der Connector schließt die Antwort ab, indem eine ausgehende Verbindung mit der Dienstinstanz geöffnet wird, von der die Anforderung stammt. Diese Verbindung wird dann sofort geschlossen. Standardmäßig ist jeder Connector auf 200 gleichzeitige ausgehende Verbindungen beschränkt.
- Die Antwort wird dann von der Dienstinstanz an den Client zurückgegeben.
- Bei nachfolgenden Anforderungen von derselben Verbindung werden die Schritte wiederholt.
Eine Anwendung umfasst häufig viele Ressourcen und öffnet bei hoher Last mehrere Verbindungen. Jede Verbindung durchläuft die Schritte, um einer Dienstinstanz zugeordnet zu werden. Wenn die Verbindung keinem Connector zugeordnet wird, wählen Sie einen neuen verfügbaren Connector aus.
Bewährte Methoden für die Hochverfügbarkeit von Connectors
Aufgrund der Art und Weise, wie Datenverkehr für die Hochverfügbarkeit auf Connectors verteilt wird, ist es unerlässlich, dass in einer Connectorgruppe immer mindestens zwei Connectors enthalten sind. Drei Connectors werden bevorzugt, um einen zusätzlichen Puffer zwischen Connectors bereitzustellen. Informationen zum Ermitteln der richtigen Anzahl der benötigten Connectors finden Sie in der Dokumentation zur Kapazitätsplanung.
Platzieren Sie Connectors für verschiedene ausgehende Verbindungen, um einen Single Point of Failure zu vermeiden. Wenn Connectors dieselbe ausgehende Verbindung verwenden, kann sich ein Netzwerkproblem bei der Verbindung auf alle Connectors auswirken, die die Verbindung verwenden.
Vermeiden Sie die Erzwingung des Neustarts von Connectors, wenn sie mit Produktionsanwendungen verbunden sind. Dies kann sich negativ auf die Verteilung des Datenverkehrs auf Connectors auswirken. Das Neustarten von Connectors führt dazu, dass mehr Connectors nicht mehr verfügbar sind und dass Verbindungen mit dem verbleibenden verfügbaren Connector erzwungen werden. Dies führt zu einer anfänglich ungleichmäßigen Verwendung der Connectors.
Vermeiden Sie alle Arten von Inline-Untersuchungen der ausgehenden TLS-Kommunikation (Transport Layer Security) zwischen Connectors und Azure. Diese Art der Inline-Untersuchung führt zu einer Verschlechterung des Kommunikationsflusses.
Achten Sie darauf, dass automatische Updates für die Connectors ausgeführt werden. Wenn der Updaterdienst für private Netzwerkconnectors ausgeführt wird, werden die Connectors automatisch aktualisiert und erhalten die neuesten Upgrades. Wenn der Connector Updater-Dienst auf Ihrem Server nicht angezeigt wird, müssen Sie den Connector neu installieren, um Updates zu erhalten.
Datenverkehrsfluss zwischen Connectors und Back-End-Anwendungsservern
Ein weiterer wichtiger Bereich, in dem die Hochverfügbarkeit eine wichtige Rolle spielt, ist die Verbindung zwischen Connectors und den Back-End-Servern. Wenn eine Anwendung über den Microsoft Entra-Anwendungsproxy veröffentlicht wird, fließt der gesamte Datenverkehr von den Benutzern zu den Anwendungen über drei Hops:
- Die Benutzer stellen eine Verbindung mit dem öffentlichen Endpunkt des Microsoft Entra-Anwendungsproxydiensts in Azure her. Die Verbindung wird zwischen der ursprünglichen Client-IP-Adresse (öffentlich) des Clients und der IP-Adresse des Anwendungsproxy-Endpunkts hergestellt.
- Der private Netzwerkconnector ruft die HTTP-Anforderung des Clients vom Anwendungsproxydienst ab.
- Der private Netzwerkconnector stellt eine Verbindung mit der Zielanwendung her. Der Connector verwendet zum Herstellen der Verbindung seine eigene IP-Adresse.
Überlegungen zum Headerfeld „X-Forwarded-For“
In einigen Fällen (z. B bei der Überwachung oder beim Lastenausgleich) muss die ursprüngliche IP-Adresse des externen Clients in der lokalen Umgebung freigegeben werden. Um diese Anforderung zu erfüllen, fügt der private Microsoft Entra-Netzwerkconnector der HTTP-Anforderung das Headerfeld „X-Forwarded-For“ mit der ursprünglichen Client-IP-Adresse (öffentlich) hinzu. Die Informationen können dann vom entsprechenden Netzwerkgerät (Load Balancer, Firewall) oder von dem Webserver oder der Back-End-Anwendung gelesen und verwendet werden.
Bewährte Methoden für den Lastenausgleich zwischen mehreren Anwendungsservern
Der Lastenausgleich ist wichtig, wenn die Connectorgruppe, die der Anwendungsproxyanwendung zugewiesen ist, zwei oder mehr Connectors aufweist. Der Lastenausgleich ist auch wichtig, wenn Sie die Back-End-Webanwendung auf mehreren Servern ausführen.
Szenario 1: Die Back-End-Anwendung erfordert keine Sitzungspersistenz.
Im einfachsten Szenario erfordert die Back-End-Webanwendung keine Sitzungsbindung (Sitzungspersistenz). Eine Back-End-Anwendungsinstanz verarbeitet Benutzeranforderungen in der Serverfarm. Sie können einen Lastenausgleich der Ebene 4 verwenden und ohne Affinität konfigurieren. Mögliche Optionen sind Microsoft-Netzwerklastenausgleich und Azure Load Balancer oder ein Lastenausgleich von einem anderen Anbieter. Konfigurieren Sie alternativ eine DNS-Strategie (Domain Name System) mit Roundrobin.
Szenario 2: Back-End-Anwendung erfordert Sitzungspersistenz
In diesem Szenario erfordert die Back-End-Webanwendung die Sitzungsbindung (Sitzungspersistenz) während der authentifizierten Sitzung. Die Back-End-Anwendungsinstanz verarbeitet Benutzeranforderungen. Drei Anforderungen werden auf demselben Server in der Serverfarm ausgeführt. Dieses Szenario kann komplizierter sein, da der Client in der Regel mehrere Verbindungen mit dem Anwendungsproxydienst herstellt. Anforderungen über verschiedene Verbindungen werden möglicherweise in unterschiedlichen Connectors und Servern in der Farm empfangen. Da jeder Connector seine eigene IP-Adresse für diese Kommunikation verwendet, kann der Load Balancer die Sitzungsbindung nicht basierend auf der IP-Adresse der Connectors sicherstellen. Auch die Quell-IP-Affinität kann nicht verwendet werden. Es folgen einige Optionen für Szenario 2:
Option 1: Basieren Sie die Sitzungspersistenz auf einem Sitzungscookie, das vom Lastenausgleich festgelegt wird. Diese Option wird empfohlen, da die Last gleichmäßiger auf die Back-End-Server verteilt werden kann. Hierfür ist ein Lastenausgleich auf Schicht 7 mit dieser Funktion erforderlich, der den HTTP-Datenverkehr verarbeiten und die TLS-Verbindung beenden kann. Sie können Azure Application Gateway (Sitzungsaffinität) oder einen Lastenausgleich von einem anderen Anbieter verwenden.
Option 2: Basieren Sie die Sitzungspersistenz auf dem Headerfeld „X-Forwarded-For“. Für diese Option ist ein Lastenausgleich auf Schicht 7 mit dieser Funktion erforderlich, der den HTTP-Datenverkehr verarbeiten und die TLS-Verbindung beenden kann.
Option 3: Konfigurieren Sie die Back-End-Anwendung so, dass keine Sitzungspersistenz erforderlich ist.
Informationen zu den Anforderungen für den Lastenausgleich der Back-End-Anwendung finden Sie in der Dokumentation des Softwareherstellers.