Режимы подключения SDK для Azure Cosmos DB SQL

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: NoSQL

Режим подключения к Azure Cosmos DB серьезно влияет на производительность, в частности на задержку на стороне клиента. Azure Cosmos DB поддерживает простую открытую модель программирования на основе REST поверх HTTPS, которая называется режимом шлюза. Кроме того, доступен эффективный протокол TCP, который также основан на модели взаимодействия REST и использует TLS для первоначальной проверки подлинности и шифрования трафика (т. н. режим прямого подключения).

Доступные режимы подключения

Доступно два режима подключения:

  • Режим шлюза

    Режим шлюза поддерживается на всех платформах SDK. Так как в режиме шлюза используется стандартный порт HTTPS и одна конечная точка DNS, его рекомендуется использовать для приложений, запущенных в корпоративных сетях со строгими ограничениями брандмауэра. Но режим шлюза не обеспечивает максимальную производительность, поскольку задействует дополнительный сетевой узел при каждой операции чтения или записи данных в Azure Cosmos DB. Режим шлюза также рекомендуется использовать при запуске приложений в средах с ограниченным числом подключений к сокетам.

    При использовании пакета SDK в Функциях Azure, особенно в плане потребления, следует учитывать текущие ограничения на подключения.

  • Режим прямого подключения

    Прямой режим поддерживает подключение через протокол TCP, используя TLS для начальной проверки подлинности и шифрования трафика, а также обеспечивает более высокую производительность за счет меньшего количества сетевых прыжков. Приложение подключается непосредственно к серверным репликам. В настоящее время режим прямого подключения поддерживается только на платформах SDK .NET и Java.

Режимы подключения для Azure Cosmos DB

Эти режимы подключения, по сути, обслуживают маршрут, который запросы плоскости данных — операции чтения и записи документов — проходят от клиентского компьютера до секций в серверной части Azure Cosmos DB. Прямой режим является предпочтительным вариантом с более высокой производительностью, так как он позволяет клиенту открывать подключения TCP непосредственно к секциям в серверной части Azure Cosmos DB и отправлять запросы напрямую, без посредника. И наоборот, в режиме шлюза выполняемые клиентом запросы направляются на так называемый сервер шлюза в интерфейсной части Azure Cosmos DB, который, в свою очередь, направляет запросы соответствующим секциям в серверной части Azure Cosmos DB.

Диапазоны исходных портов

При использовании прямого режима необходимо убедиться, что клиент может получить доступ к портам в диапазоне от 10000 до 20000, так как Azure Cosmos DB использует динамические TCP-порты. Это в дополнение к портам шлюза. При использовании прямого режима в частных конечных точках полный диапазон TCP-портов — от 0 до 65535 может использоваться Azure Cosmos DB. Если эти порты не открыты в клиенте, и вы пытаетесь использовать протокол TCP, может появиться ошибка 503 Service Недоступно.

В таблице ниже приведены режимы подключения, поддерживаемые различными API-интерфейсами, и порты служб для них.

Режим подключения Поддерживаемый протокол Поддерживаемые пакеты SDK API и порт службы
Шлюз HTTPS Все пакеты SDK SQL (443), MongoDB (10255), Таблица (443), Cassandra (10350), Graph (443)
Напрямую TCP (зашифрован с помощью TLS) SDK для Java, SDK для .NET При использовании общедоступной конечной точки или конечных точек службы: порты в диапазоне от 10000 до 20000
При использовании частных конечных точек: порты в диапазоне от 0 до 65535

Архитектура режима прямого подключения

Как подробно описано во введении, клиенты режима прямого подключения будут напрямую подключаться к внутренним узлам по протоколу TCP. Каждый внутренний узел представляет собой реплику в наборе реплик, принадлежащем физической секции.

Маршрутизация

Когда пакет SDK для Azure Cosmos DB в режиме прямого подключения выполняет операцию, ему необходимо решить, к какой серверной реплике подключаться. Первым шагом является знание физической секции, к которой должна перейти операция, и для этого пакет SDK получает сведения о контейнере, включая определение ключа секции из узла шлюза. Кроме того, ему требуются сведения о маршрутизации, содержащие TCP-адреса реплик. Сведения о маршрутизации доступны также из узлов шлюза, и оба считаются метаданными уровня управления. После получения сведений о маршрутизации пакет SDK может перейти к открытию TCP-подключений к репликам, принадлежащим целевой физической секции, и выполнить операции.

Каждый набор реплик содержит одну первичную реплику и три вторичных. Операции записи всегда направляются на первичные узлы реплики, тогда как операции чтения могут обслуживаться с первичных или вторичных узлов.

Схема, на которой показано, как пакеты SDK в прямом режиме получают информацию о контейнере и маршрутизации от шлюза, прежде чем открывать TCP-подключения к серверным узлам.

Поскольку сведения о контейнере и маршрутизации меняются нечасто, они кэшируются локально в пакетах SDK, чтобы последующие операции могли воспользоваться этой информацией. Уже установленные TCP-подключения также повторно используются в операциях. Если иное не настроено с помощью параметров пакетов SDK, подключения постоянно сохраняются в течение всего времени существования экземпляра пакета SDK.

Как и в случае с любой распределенной архитектурой, на компьютерах с репликами может выполняться модернизация или обслуживание. Служба обеспечит согласованность набора реплик, но любое перемещение реплики приведет к изменению существующих TCP-адресов. В таких случаях пакетам SDK необходимо обновить сведения о маршрутизации и повторно подключиться к новым адресам через новые запросы шлюза. Эти события не должны влиять на общее соглашение об уровне обслуживания P99.

Объем подключений

Каждая физическая секция имеет набор из четырех реплик, чтобы обеспечить оптимальную производительность, пакеты SDK в конечном итоге открывают подключения ко всем репликам для рабочих нагрузок, которые сочетают операции записи и чтения. Параллельные операции распределяются по нагрузке между существующими подключениями, чтобы использовать пропускную способность, обеспечиваемую каждой репликой.

Существует два фактора, определяющих количество TCP-подключений, которые будут открыты пакетом SDK.

  • Количество физических секций

    В устойчивом состоянии пакет SDK будет иметь одно подключение для каждой реплики на физическую секцию. Чем больше количество физических секций в контейнере, тем больше будет количество открытых подключений. Так как операции направляются по разным секциям, подключения устанавливаются по запросу. В этом случае среднее количество подключений будет равно количеству физических секций, умноженному на четыре.

  • Объем параллельных запросов

    Каждое установленное подключение может обслуживать настраиваемое количество параллельных операций. Если объем параллельных операций превышает это пороговое значение, для их обслуживания будут открыты новые подключения, и возможно, что для физической секции количество открытых подключений превысит значение для устойчивого состояния. Это поведение ожидаемо для рабочих нагрузок, которые могут иметь пики в своем рабочем объеме. Для пакета SDK для .NET эта конфигурация задается с помощью CosmosClientOptions.MaxRequestsPerTcpConnection, а для пакета SDK для Java ее можно настроить с помощью DirectConnectionConfig.setMaxRequestsPerConnection.

По умолчанию подключения постоянно поддерживаются для повышения производительности будущих операций (открытие подключения имеет вычислительные издержки). В некоторых сценариях может потребоваться закрыть подключения, которые не используются в течение некоторого времени, при условии, что это незначительно повлияет на будущие операции. Для пакета SDK для .NET эта конфигурация задается с помощью CosmosClientOptions.IdleTcpConnectionTimeout, а для пакета SDK для Java ее можно настроить с помощью DirectConnectionConfig.setIdleConnectionTimeout. Не рекомендуется устанавливать для этих конфигураций низкие значения, так как это может привести к частому закрытию подключений и снижению общей производительности.

Сведения о реализации для конкретных языков

Для получения дополнительных сведений о реализации для конкретных языков см.:

Следующие шаги

Для конкретных оптимизаций производительности платформы SDK: