Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Übersicht
In diesem Artikel wird erläutert, wie der Datenverkehr mit Ihrer Anwendungsproxy-Bereitstellung verteilt wird. Sie erfahren, wie Datenverkehr zwischen Benutzern und Connectors verteilt wird, sowie Tipps zum Optimieren der Connectorleistung und Empfehlungen für den Lastenausgleich zwischen mehreren Back-End-Servern.
Verteilung des Netzwerkverkehrs auf Anschlüsse
Connectors stellen ihre Verbindungen nach Prinzipien der Hochverfügbarkeit her. 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 Anfragen für den gesamten Traffic in der Region zu verarbeiten. Mit dieser Methode kann der Datenverkehr gleichmäßig auf die Dienstinstanzen verteilt werden.
- Die Anforderung wird an Service Bus gesendet.
- Der 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 Verbinder 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 nicht mit einem Verbinder gekoppelt ist, wird ein neuer verfügbarer Verbinder ausgewählt.
Bewährte Methoden für die Hochverfügbarkeit von Connectors
Aufgrund der Art und Weise, wie Datenverkehr für die Hochverfügbarkeit auf Konnektoren verteilt wird, ist es unerlässlich, dass eine Connectorgruppe immer mindestens zwei Konnektoren enthält. Es werden drei Steckverbinder bevorzugt, um zusätzlichen Puffer zwischen den Steckverbindern bereitzustellen. Um die richtige Anzahl von Connectors zu ermitteln, die Sie benötigen, befolgen Sie die Dokumentation zur Kapazitätsplanung.
Platzieren Sie Steckverbinder auf verschiedene ausgehende Verbindungen, um einen einzelnen Fehlerpunkt 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 es, den Neustart von Konnektoren zu erzwingen, wenn sie mit Produktionsanwendungen verbunden sind. Dies könnte sich negativ auf die Verteilung des Datenverkehrs über Connectors auswirken. Wenn Konnektoren neu gestartet werden, sind mehr Konnektoren nicht verfügbar, und die Verbindungen müssen auf die verbleibenden verfügbaren Konnektoren umgeleitet werden. Dies führt zu einer anfänglich ungleichmäßigen Verwendung der Verbinder.
Vermeiden Sie alle Arten von Inline-Untersuchungen der ausgehenden TLS-Kommunikation (Transport Layer Security) zwischen Connectors und Azure. Diese Art der Inline-Überprüfung führt zu einer Verschlechterung des Kommunikationsflusses.
Achten Sie darauf, dass automatische Updates für die Connectors ausgeführt werden. Wenn der Updater-Dienst für das private Netzwerk ausgeführt wird, aktualisieren Ihre Netzwerk-Connectors automatisch und erhalten die neuesten Updates. 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 Datenverkehr von Benutzern zu Anwendungen über drei Zwischenstationen:
- 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 Situationen, z. B. bei Prüfung und Lastenausgleich, ist die Weitergabe der ursprünglichen IP-Adresse des externen Clients an die lokale Umgebung eine Voraussetzung. Um die Anforderung zu beheben, fügt der private Microsoft Entra-Netzwerkconnector das X-Forwarded-For Kopfzeilenfeld mit der ursprünglichen Client-IP-Adresse (öffentlich) zur HTTP-Anforderung 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, über zwei oder mehr Connectors verfügt und 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 ihn konfigurieren, ohne Affinität einzustellen. Einige Optionen sind Microsoft Network Load Balancing und Azure Load Balancer oder ein Lastenausgleichsmodul eines anderen Anbieters. Konfigurieren Sie alternativ eine Round-Robin-Strategie für das Domain Name System (DNS).
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, die auf demselben Server in der Serverfarm verarbeitet werden. Dieses Szenario kann komplizierter sein, da der Client in der Regel mehrere Verbindungen mit dem Anwendungsproxydienst herstellt. Anforderungen über verschiedene Verbindungen können möglicherweise in unterschiedlichen Connectoren und Servern in der Farm ankommen. 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. Die Quell-IP-Affinität kann auch 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 Load Balancer von einem anderen Anbieter verwenden.
Option 2: Die Sitzungspersistenz auf dem Headerfeld „X-Forwarded-For“ basieren. 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.