Delen via

Connectiviteitsmodi voor Azure Cosmos DB SQL SDK

  • Artikel

VAN TOEPASSING OP: NoSQL

Hoe een client verbinding maakt met Azure Cosmos DB heeft belangrijke gevolgen voor de prestaties, met name voor waargenomen latentie aan de clientzijde. Azure Cosmos DB biedt een eenvoudig, open RESTful-programmeermodel via HTTPS, de gatewaymodus. Daarnaast biedt het een efficiënt TCP-protocol, dat ook RESTful is in het communicatiemodel en TLS gebruikt voor initiële verificatie en het versleutelen van verkeer, de zogenaamde directe modus.

Beschikbare connectiviteitsmodi

De twee beschikbare connectiviteitsmodi zijn:

  • Gatewaymodus

    De gatewaymodus wordt ondersteund op alle SDK-platforms. Als uw toepassing wordt uitgevoerd binnen een bedrijfsnetwerk met strikte firewallbeperkingen, is de gatewaymodus de beste keuze omdat deze gebruikmaakt van de standaard HTTPS-poort en één DNS-eindpunt. Het nadeel van de prestaties is echter dat de gatewaymodus een extra netwerkhop omvat telkens wanneer gegevens worden gelezen van of naar Azure Cosmos DB worden geschreven. We raden ook de gatewayverbindingsmodus aan wanneer u toepassingen uitvoert in omgevingen met een beperkt aantal socketverbindingen.

    Wanneer u de SDK in Azure Functions gebruikt, met name in het verbruiksabonnement, moet u rekening houden met de huidige limieten voor verbindingen.

  • Directe modus

    De directe modus ondersteunt connectiviteit via TCP-protocol, het gebruik van TLS voor initiële verificatie en het versleutelen van verkeer, en biedt betere prestaties omdat er minder netwerkhops zijn. De toepassing maakt rechtstreeks verbinding met de back-endreplica's. De directe modus wordt momenteel alleen ondersteund op .NET- en Java SDK-platforms.

De connectiviteitsmodi van Azure Cosmos DB

Deze connectiviteitsmodi vormen in wezen de route die door het gegevensvlak wordt aangevraagd ( documentlees- en schrijfbewerkingen) van uw clientcomputer naar partities in de Azure Cosmos DB-back-end. Directe modus is de voorkeursoptie voor de beste prestaties. Hiermee kan uw client TCP-verbindingen rechtstreeks openen naar partities in de Azure Cosmos DB-back-end en aanvragen rechtstreeksverzenden zonder intermediair. In de gatewaymodus worden aanvragen van uw client daarentegen gerouteerd naar een zogenaamde Gateway-server in de Azure Cosmos DB-front-end. Op deze manier worden uw aanvragen naar de juiste partitie(s) in de Azure Cosmos DB-back-end aangepast.

Servicepoortbereiken

Wanneer u de directe modus gebruikt, moet u ervoor zorgen dat uw client toegang heeft tot poorten tussen 10000 en 20000, omdat Azure Cosmos DB dynamische TCP-poorten gebruikt. Dit is naast de gatewaypoorten. Wanneer u de directe modus op privé-eindpunten gebruikt, kan het volledige bereik van TCP-poorten , van 0 tot 65535, worden gebruikt door Azure Cosmos DB. Als deze poorten niet zijn geopend op uw client en u probeert het TCP-protocol te gebruiken, krijgt u mogelijk de fout 503 Service Niet beschikbaar.

In de volgende tabel ziet u een overzicht van de connectiviteitsmodi die beschikbaar zijn voor verschillende API's en de servicepoorten die voor elke API worden gebruikt:

Verbindingsmodus Ondersteund protocol Ondersteunde SDK's API/servicepoort
Gateway HTTPS Alle SDK's SQL (443), MongoDB (10255), Table (443), Cassandra (10350), Graph (443)
Direct TCP (versleuteld via TLS) .NET SDK Java SDK Bij gebruik van openbare/service-eindpunten: poorten in het bereik van 10000 tot en met 20000
Bij gebruik van privé-eindpunten: poorten in het bereik van 0 tot en met 65535

Verbindingsarchitectuur voor directe modus

Zoals beschreven in de inleiding, maken clients in de directe modus rechtstreeks verbinding met de back-endknooppunten via het TCP-protocol. Elk back-endknooppunt vertegenwoordigt een replica in een replicaset die deel uitmaakt van een fysieke partitie.

Routering

Wanneer een Azure Cosmos DB SDK in de directe modus een bewerking uitvoert, moet deze oplossen met welke back-endreplica verbinding moet worden gemaakt. De eerste stap is weten naar welke fysieke partitie de bewerking moet gaan. Hiervoor verkrijgt de SDK de containergegevens die de definitie van de partitiesleutel van een gatewayknooppunt bevatten. Het heeft ook de routeringsinformatie nodig die de TCP-adressen van de replica's bevat. De routeringsgegevens zijn ook beschikbaar vanuit gatewayknooppunten en beide worden beschouwd als metagegevens van het besturingsvlak. Zodra de SDK de routeringsgegevens heeft verkregen, kunt u doorgaan met het openen van de TCP-verbindingen met de replica's die behoren tot de fysieke doelpartitie en de bewerkingen uitvoeren.

Elke replicaset bevat één primaire replica en drie secundaire replica's. Schrijfbewerkingen worden altijd doorgestuurd naar primaire replicaknooppunten terwijl leesbewerkingen kunnen worden uitgevoerd vanaf primaire of secundaire knooppunten.

Diagram dat laat zien hoe S D Ks in de directe modus de container en routeringsgegevens van de gateway ophaalt voordat de T C P-verbindingen met de back-endknooppunten worden geopend

Omdat de container- en routeringsgegevens niet vaak worden gewijzigd, worden deze lokaal opgeslagen in de SDK's, zodat volgende bewerkingen kunnen profiteren van deze informatie. De TCP-verbindingen die al tot stand zijn gebracht, worden ook opnieuw gebruikt voor alle bewerkingen. Tenzij anders geconfigureerd via de SDK-opties, worden verbindingen permanent onderhouden tijdens de levensduur van het SDK-exemplaar.

Net als bij elke gedistribueerde architectuur kunnen de machines met replica's upgrades of onderhoud ondergaan. De service zorgt ervoor dat de replicaset consistentie behoudt, maar elke replicaverplaatsing zorgt ervoor dat bestaande TCP-adressen worden gewijzigd. In deze gevallen moeten de SDK's de routeringsgegevens vernieuwen en opnieuw verbinding maken met de nieuwe adressen via nieuwe gatewayaanvragen. Deze gebeurtenissen mogen geen invloed hebben op de algehele SLA van P99.

Volume van verbindingen

Elke fysieke partitie heeft een replicaset van vier replica's, om de best mogelijke prestaties te bieden, zullen SDK's uiteindelijk verbindingen openen met alle replica's voor workloads die schrijf- en leesbewerkingen combineren. Gelijktijdige bewerkingen worden verdeeld over bestaande verbindingen om te profiteren van de doorvoer die elke replica biedt.

Er zijn twee factoren waarmee het aantal TCP-verbindingen wordt bepaald dat de SDK wordt geopend:

  • Aantal fysieke partities

    In een stabiele status heeft de SDK één verbinding per replica per fysieke partitie. Hoe groter het aantal fysieke partities in een container, hoe groter het aantal geopende verbindingen is. Wanneer bewerkingen worden gerouteerd over verschillende partities, worden verbindingen op aanvraag tot stand gebracht. Het gemiddelde aantal verbindingen is dan het aantal fysieke partities keer vier.

  • Volume van gelijktijdige aanvragen

    Elke tot stand gebrachte verbinding kan een configureerbaar aantal gelijktijdige bewerkingen leveren. Als het volume van gelijktijdige bewerkingen deze drempelwaarde overschrijdt, zijn nieuwe verbindingen geopend om ze te verwerken en is het mogelijk dat voor een fysieke partitie het aantal geopende verbindingen het vaste statusnummer overschrijdt. Dit gedrag wordt verwacht voor workloads die mogelijk pieken in hun operationele volume hebben. Voor de .NET SDK is deze configuratie ingesteld door CosmosClientOptions.MaxRequestsPerTcpConnection en voor de Java SDK kunt u aanpassen met behulp van DirectConnectionConfig.setMaxRequestsPerConnection.

Standaard worden verbindingen permanent onderhouden om te profiteren van de prestaties van toekomstige bewerkingen (het openen van een verbinding heeft rekenoverhead). Er kunnen enkele scenario's zijn waarin u mogelijk verbindingen wilt sluiten die gedurende enige tijd niet worden gebruikt. Dit kan enigszins van invloed zijn op toekomstige bewerkingen. Voor de .NET SDK is deze configuratie ingesteld door CosmosClientOptions.IdleTcpConnectionTimeout en voor de Java SDK kunt u aanpassen met behulp van DirectConnectionConfig.setIdleConnectionTimeout. Het is niet raadzaam om deze configuraties in te stellen op lage waarden, omdat verbindingen mogelijk vaak worden gesloten en invloed hebben op de algehele prestaties.

Details van taalspecifieke implementatie

Zie voor meer implementatiedetails met betrekking tot een taal:

Volgende stappen

Voor specifieke optimalisaties van sdk-platformprestaties: