Azure Cosmos DB SQL SDK-Konnektivitätsmodi

  • Artikel

GILT FÜR: NoSQL

Die Art der Verbindungsherstellung zwischen einem Client und Azure Cosmos DB hat erhebliche Auswirkungen auf die Leistung, insbesondere im Hinblick auf die clientseitige Latenz. Azure Cosmos DB bietet ein einfaches und offenes RESTful-Programmiermodell über HTTPS, das Gatewaymodus genannt wird. Außerdem ist ein effizientes TCP-Protokoll enthalten, das ebenfalls RESTful in seinem Kommunikationsmodell ist und TLS für die anfängliche Authentifizierung und die Verschlüsselung des Datenverkehrs verwendet, den sogenannten direkten Modus.

Verfügbare Konnektivitätsmodi

Diese beiden Konnektivitätsmodi sind verfügbar:

  • Gatewaymodus

    Der Gatewaymodus wird auf allen SDK-Plattformen unterstützt. Wenn Ihre Anwendung in einem Unternehmensnetzwerk mit strengen Firewalleinschränkungen ausgeführt wird, ist der Gatewaymodus die beste Wahl, da er den HTTPS-Standardport und einen einzelnen DNS-Endpunkt verwendet. Im Gatewaymodus ist jedoch jeweils ein zusätzlicher Netzwerkhop erforderlich, wenn Daten in Azure Cosmos DB geschrieben oder daraus gelesen werden, was sich negativ auf die Leistung auswirkt. Der Gatewayverbindungsmodus wird auch empfohlen, wenn Sie Anwendungen in Umgebungen mit einer begrenzten Anzahl von Socketverbindungen ausführen.

    Beachten Sie bei Verwendung des SDK in Azure Functions – insbesondere beim Verbrauchstarif – die aktuellen Grenzwerte für Verbindungen.

  • Direkter Modus

    Der direkte Modus unterstützt Konnektivität über das TCP-Protokoll sowie die Verwendung von TLS für die anfängliche Authentifizierung und die Verschlüsselung des Datenverkehrs und bietet eine bessere Leistung, da weniger Netzwerkhops vorhanden sind. Die Anwendung verbindet sich direkt mit den Back-End-Replikaten. Der direkte Modus wird derzeit nur auf .NET- und Java-SDK-Plattformen unterstützt.

Azure Cosmos DB-Konnektivitätsmodi

Diese Konnektivitätsmodi entscheiden im Wesentlichen über die Weiterleitung von Datenebenenanforderungen (Lese- und Schreibvorgänge für Dokumente) vom Clientcomputer an Partitionen im Azure Cosmos DB-Back-End. Der direkte Modus ist die bevorzugte Option für eine optimale Leistung. Er ermöglicht es dem Client, TCP-Verbindungen direkt mit Partitionen im Azure Cosmos DB-Back-End herzustellen und Anforderungen direkt und ohne Vermittler zu senden. Im Gatewaymodus werden Anforderungen vom Client an einen sogenannten „Gatewayserver“ im Azure Cosmos DB-Front-End weitergeleitet, der wiederum Ihre Anforderungen an die entsprechenden Partitionen im Azure Cosmos DB-Back-End verteilt.

Dienstportbereiche

Wenn Sie den direkten Modus verwenden, müssen Sie sicherstellen, dass Ihr Client auf Ports zwischen 10000 und 20000 zugreifen kann, da Azure Cosmos DB dynamische TCP-Ports verwendet. Dies gilt zusätzlich zu den Gatewayports. Wenn Sie den direkten Modus auf privaten Endpunkten verwenden, wird unter Umständen der gesamte Bereich der TCP-Ports von 0 bis 65535 von Azure Cosmos DB verwendet. Wenn diese Ports auf Ihrem Client nicht geöffnet sind und Sie versuchen, das TCP zu verwenden, wird möglicherweise der 503-Fehler „Dienst nicht verfügbar“ angezeigt.

Die folgende Tabelle enthält eine Zusammenfassung der für verschiedene APIs verfügbaren Konnektivitätsmodi und der für die einzelnen APIs verwendeten Dienstports:

Verbindungsmodus Unterstütztes Protokoll Unterstützte SDKs API/Dienstport
Gateway HTTPS Alle SDKs SQL (443), MongoDB (10255), Tabelle (443), Cassandra (10350), Graph (443)
Direkt TCP (verschlüsselt über TLS) .NET SDK Java SDK Bei Verwendung von öffentlichen oder Dienstendpunkten: Ports im Bereich zwischen 10000 und 20000
Bei Verwendung von privaten Endpunkten: Ports im Bereich zwischen 0 und 65535

Verbindungsarchitektur im direkten Modus

Wie in der Einführung beschrieben, stellen Clients im direkten Modus eine direkte Verbindung mit den Back-End-Knoten über das TCP-Protokoll her. Jeder Back-End-Knoten stellt ein Replikat in einer Replikatgruppe dar, das zu einer physischen Partition gehört.

Routing

Wenn ein Azure Cosmos DB SDK im direkten Modus einen Vorgang ausführt, muss es auflösen, mit welchem Back-End-Replikat eine Verbindung hergestellt werden soll. Als Erstes muss bekannt sein, für welche physische Partition der Vorgang ausgeführt werden soll. Dazu erhält das SDK die Containerinformationen, die die Partitionsschlüsseldefinition von einem Gatewayknoten enthalten. Außerdem werden die Routinginformationen benötigt, die die TCP-Adressen der Replikate enthalten. Die Routinginformationen sind auch über Gatewayknoten verfügbar, und beide werden als Metadaten auf Steuerungsebene betrachtet. Sobald das SDK die Routinginformationen erhalten hat, kann es die TCP-Verbindungen zu den Replikaten öffnen, die zur physischen Zielpartition gehören, und die Vorgänge ausführen.

Jede Replikatgruppe enthält ein primäres Replikat und drei sekundäre. Schreibvorgänge werden immer an primäre Replikatknoten weitergeleitet, während Lesevorgänge von primären oder sekundären Knoten bereitgestellt werden können.

Diagram, in dem SDKs im direkten Modus die Container- und Routinginformationen vom Gateway fetchen, bevor die TCP-Verbindungen zu den Back-End-Knoten geöffnet werden

Da sich die Container- und Routinginformationen nicht häufig ändern, werden sie lokal auf den SDKs zwischengespeichert, sodass nachfolgende Vorgänge von diesen Informationen profitieren können. Die bereits eingerichteten TCP-Verbindungen werden ebenfalls bei mehreren Vorgängen wiederverwendet. Sofern in den SDK-Optionen nicht anders konfiguriert, werden Verbindungen über die Lebensdauer der SDK-Instanz permanent beibehalten.

Wie bei jeder verteilten Architektur können für Computer mit Replikaten Upgrades oder Wartungen durchgeführt werden. Der Dienst stellt sicher, dass die Replikatgruppe konsistent bleibt. Jede Replikatverschiebung bewirkt jedoch eine Änderung der vorhandenen TCP-Adressen. In diesen Fällen müssen die SDKs die Routinginformationen aktualisieren und über neue Gatewayanforderungen erneut eine Verbindung zu den neuen Adressen herstellen. Diese Ereignisse sollten sich nicht auf die P99-SLA insgesamt auswirken.

Anzahl der Verbindungen

Jede physische Partition verfügt über eine Replikatgruppe von vier Replikaten. Um die bestmögliche Leistung zu bieten, öffnen SDKs bei Workloads, die Schreib- und Lesevorgänge kombinieren, Verbindungen zu allen Replikaten. Gleichzeitige Vorgänge werden per Lastenausgleich auf vorhandene Verbindungen verteilt, um den Durchsatz jedes Replikats nutzen zu können.

Es gibt zwei Faktoren, die die Anzahl der TCP-Verbindungen bestimmen, die vom SDK geöffnet werden:

  • Anzahl der physischen Partitionen

    Im stabilen Zustand verfügt das SDK über eine Verbindung pro Replikat und physischer Partition. Je größer die Anzahl physischer Partitionen in einem Container ist, desto größer ist auch die Anzahl der geöffneten Verbindungen. Da Vorgänge über verschiedene Partitionen weitergeleitet werden, werden Verbindungen nach Bedarf eingerichtet. Die durchschnittliche Anzahl von Verbindungen ist dann die Anzahl der physischen Partitionen mal vier.

  • Anzahl gleichzeitiger Anforderungen

    Jede hergestellte Verbindung kann eine konfigurierbare Anzahl gleichzeitiger Vorgänge bereitstellen. Wenn die Anzahl gleichzeitiger Vorgänge diesen Schwellenwert überschreitet, werden neue Verbindungen zur Bereitstellung geöffnet, und es ist möglich, dass für eine physische Partition die Anzahl der geöffneten Verbindungen die Anzahl im stabilen Zustand übersteigt. Dieses Verhalten wird bei Workloads erwartet, die Spitzen in ihrem Betriebsvolumen aufweisen können. Für das .NET SDK wird diese Konfiguration durch CosmosClientOptions.MaxRequestsPerTcpConnection festgelegt. Für das Java SDK können Sie eine Anpassung über DirectConnectionConfig.setMaxRequestsPerConnection vornehmen.

Standardmäßig werden Verbindungen dauerhaft beibehalten, um die Leistung zukünftiger Vorgänge zu verbessern (das Öffnen einer Verbindung ist mit Rechenaufwand verbunden). In einigen Szenarien möchten Sie möglicherweise Verbindungen schließen, die eine Zeit lang nicht genutzt werden. Dabei sollte Ihnen bewusst sein, dass sich dies geringfügig auf zukünftige Vorgänge auswirkt. Für das .NET SDK wird diese Konfiguration durch CosmosClientOptions.IdleTcpConnectionTimeout festgelegt. Für das Java SDK können Sie eine Anpassung über DirectConnectionConfig.setIdleConnectionTimeout vornehmen. Es ist nicht ratsam, diese Konfigurationen auf niedrige Werte festzulegen, da dies dazu führen kann, dass Verbindungen häufig geschlossen werden und die Gesamtleistung beeinträchtigt wird.

Details zur sprachspezifischen Implementierung

Weitere Implementierungsdetails für eine bestimmte Sprache finden Sie unter:

Nächste Schritte

Für bestimmte Leistungsoptimierungen der SDK-Plattform: