Tryby łączności zestawu SQL SDK usługi Azure Cosmos DB

  • Artykuł

DOTYCZY: NoSQL

W jaki sposób klient łączy się z usługą Azure Cosmos DB, ma istotne konsekwencje dla wydajności, zwłaszcza w przypadku zaobserwowanego opóźnienia po stronie klienta. Usługa Azure Cosmos DB oferuje prosty, otwarty model programowania RESTful za pośrednictwem protokołu HTTPS nazywany trybem bramy. Ponadto oferuje wydajny protokół TCP, który jest również resTful w modelu komunikacji i używa protokołu TLS do uwierzytelniania początkowego i szyfrowania ruchu, nazywanego trybem bezpośrednim.

Dostępne tryby łączności

Dwa dostępne tryby łączności to:

  • Tryb bramy

    Tryb bramy jest obsługiwany na wszystkich platformach zestawu SDK. Jeśli aplikacja działa w sieci firmowej z rygorystycznymi ograniczeniami zapory, tryb bramy jest najlepszym wyborem, ponieważ używa standardowego portu HTTPS i pojedynczego punktu końcowego DNS. Kompromis wydajności polega jednak na tym, że tryb bramy obejmuje dodatkowy przeskok sieciowy za każdym razem, gdy dane są odczytywane lub zapisywane w usłudze Azure Cosmos DB. Zalecamy również tryb połączenia bramy podczas uruchamiania aplikacji w środowiskach z ograniczoną liczbą połączeń gniazd.

    W przypadku korzystania z zestawu SDK w Azure Functions, szczególnie w planie Zużycie, należy pamiętać o bieżących limitach połączeń.

  • Tryb bezpośredni

    Tryb bezpośredni obsługuje łączność za pośrednictwem protokołu TCP, przy użyciu protokołu TLS na potrzeby uwierzytelniania początkowego i szyfrowania ruchu oraz zapewnia lepszą wydajność, ponieważ jest mniej przeskoków sieciowych. Aplikacja łączy się bezpośrednio z replikami zaplecza. Tryb bezpośredni jest obecnie obsługiwany tylko na platformach .NET i Java SDK.

Tryby łączności usługi Azure Cosmos DB

Te tryby łączności zasadniczo warunkują trasę żądaną przez płaszczyznę danych — odczyty i zapisy dokumentu — z maszyny klienckiej do partycji w zapleczu usługi Azure Cosmos DB. Tryb bezpośredni jest preferowaną opcją dla najlepszej wydajności — umożliwia klientowi otwieranie połączeń TCP bezpośrednio z partycjami w zapleczu usługi Azure Cosmos DB i wysyłanie żądań bezpośredniobez pośrednika. Natomiast w trybie bramy żądania wysyłane przez klienta są kierowane do tak zwanego serwera "Brama" w frontonie usługi Azure Cosmos DB, który z kolei wyśmiewał żądania do odpowiednich partycji w zapleczu usługi Azure Cosmos DB.

Zakresy portów usługi

W przypadku korzystania z trybu bezpośredniego należy upewnić się, że klient może uzyskiwać dostęp do portów z zakresu od 10000 do 20000, ponieważ usługa Azure Cosmos DB używa dynamicznych portów TCP. Jest to uzupełnienie portów bramy. W przypadku korzystania z trybu bezpośredniego w prywatnych punktach końcowych usługa Azure Cosmos DB może używać pełnego zakresu portów TCP — od 0 do 65535. Jeśli te porty nie są otwarte na kliencie i spróbujesz użyć protokołu TCP, może zostać wyświetlony błąd 503 Usługa niedostępna.

W poniższej tabeli przedstawiono podsumowanie trybów łączności dostępnych dla różnych interfejsów API i portów usługi używanych dla każdego interfejsu API:

Tryb połączenia Obsługiwany protokół Obsługiwane zestawy SDK Port interfejsu API/usługi
Brama HTTPS Wszystkie zestawy SDK SQL (443), MongoDB (10255), Tabela (443), Cassandra (10350), Graph (443)
Direct TCP (zaszyfrowane za pośrednictwem protokołu TLS) Zestaw JAVA SDK platformy .NET W przypadku korzystania z publicznych punktów końcowych/punktów końcowych usług: porty z zakresu od 10000 do 20000
W przypadku korzystania z prywatnych punktów końcowych: porty z zakresu od 0 do 65535

Architektura połączenia trybu bezpośredniego

Zgodnie z opisem we wprowadzeniu klienci trybu bezpośredniego będą łączyć się bezpośrednio z węzłami zaplecza za pośrednictwem protokołu TCP. Każdy węzeł zaplecza reprezentuje replikę w zestawie replik należącym do partycji fizycznej.

Routing

Gdy zestaw SDK usługi Azure Cosmos DB w trybie bezpośrednim wykonuje operację, musi rozpoznać replikę zaplecza, z którą ma nawiązać połączenie. Pierwszym krokiem jest poznanie partycji fizycznej, do której powinna przejść operacja, a w tym celu zestaw SDK uzyskuje informacje o kontenerze zawierające definicję klucza partycji z węzła bramy. Potrzebuje również informacji o routingu, które zawierają adresy TCP replik. Informacje o routingu są dostępne również z węzłów bramy, a oba są traktowane jako metadane płaszczyzny sterowania. Po uzyskaniu informacji o routingu zestaw SDK może otworzyć połączenia TCP z replikami należącymi do docelowej partycji fizycznej i wykonać operacje.

Każdy zestaw replik zawiera jedną replikę podstawową i trzy sekundy. Operacje zapisu są zawsze kierowane do węzłów repliki podstawowej, podczas gdy operacje odczytu mogą być obsługiwane z węzłów podstawowych lub pomocniczych.

Diagram przedstawiający sposób pobierania informacji o kontenerze i routingu z bramy przez protokół S D Ks w trybie bezpośrednim przed otwarciem połączeń T C P z węzłami zaplecza

Ponieważ informacje o kontenerze i routingu nie zmieniają się często, są buforowane lokalnie na zestawach SDK, dzięki czemu kolejne operacje mogą korzystać z tych informacji. Nawiązane już połączenia TCP są również ponownie używane w operacjach. O ile nie skonfigurowano inaczej za pomocą opcji zestawów SDK, połączenia są trwale utrzymywane w okresie istnienia wystąpienia zestawu SDK.

Podobnie jak w przypadku dowolnej architektury rozproszonej, maszyny przechowujące repliki mogą przechodzić uaktualnienia lub konserwację. Usługa zapewni, że zestaw replik zachowa spójność, ale każdy ruch repliki spowoduje zmianę istniejących adresów TCP. W takich przypadkach zestawy SDK muszą odświeżyć informacje o routingu i ponownie nawiązać połączenie z nowymi adresami za pośrednictwem nowych żądań bramy. Te zdarzenia nie powinny mieć wpływu na ogólną umowę SLA P99.

Liczba połączeń

Każda partycja fizyczna ma zestaw replik czterech replik, aby zapewnić najlepszą możliwą wydajność, zestawy SDK będą otwierać połączenia ze wszystkimi replikami dla obciążeń, które mieszają operacje zapisu i odczytu. Operacje współbieżne są równoważone w istniejących połączeniach, aby korzystać z przepływności zapewnianej przez każdą replikę.

Istnieją dwa czynniki, które określają liczbę połączeń TCP, które zostaną otwarte przez zestaw SDK:

  • Liczba partycji fizycznych

    W stanie stabilnym zestaw SDK będzie miał jedno połączenie na replikę na partycję fizyczną. Większa liczba partycji fizycznych w kontenerze, tym większa będzie liczba otwartych połączeń. Ponieważ operacje są kierowane między różnymi partycjami, połączenia są na żądanie nawiązywane. Średnia liczba połączeń to liczba partycji fizycznych razy cztery.

  • Liczba współbieżnych żądań

    Każde ustanowione połączenie może obsłużyć konfigurowalną liczbę operacji współbieżnych. Jeśli liczba operacji współbieżnych przekroczy ten próg, nowe połączenia będą otwarte w celu ich obsługi i możliwe, że w przypadku partycji fizycznej liczba otwartych połączeń przekracza liczbę stałego stanu. To zachowanie jest oczekiwane w przypadku obciążeń, które mogą mieć skoki wielkości operacyjnej. W przypadku zestawu SDK platformy .NET ta konfiguracja jest ustawiana przez element CosmosClientOptions.MaxRequestsPerTcpConnection, a dla zestawu SDK języka Java można dostosować przy użyciu polecenia DirectConnectionConfig.setMaxRequestsPerConnection.

Domyślnie połączenia są trwale utrzymywane w celu zwiększenia wydajności przyszłych operacji (otwarcie połączenia ma obciążenie obliczeniowe). Mogą wystąpić pewne scenariusze, w których można chcieć zamknąć nieużywane połączenia przez pewien czas, aby zrozumieć, że może to mieć wpływ na przyszłe operacje nieco. Dla zestawu SDK platformy .NET ta konfiguracja jest ustawiana przez element CosmosClientOptions.IdleTcpConnectionTimeout, a dla zestawu SDK języka Java można dostosować przy użyciu polecenia DirectConnectionConfig.setIdleConnectionTimeout. Nie zaleca się ustawiania tych konfiguracji na niskie wartości, ponieważ może to powodować częste zamykanie połączeń i wpływanie na ogólną wydajność.

Szczegóły implementacji specyficzne dla języka

Aby uzyskać więcej szczegółów dotyczących implementacji języka, zobacz:

Następne kroki

W przypadku określonych optymalizacji wydajności platformy SDK: