Modos de conectividad del SDK de SQL de Azure Cosmos DB

El modo en que un cliente se conecta a Azure Cosmos DB tiene importantes implicaciones de rendimiento, especialmente para la latencia observada del lado cliente. Azure Cosmos DB ofrece un modelo de programación RESTful sencillo y abierto a través de HTTPS denominado modo de puerta de enlace . Además, ofrece un protocolo TCP eficaz, que también es RESTful en su modelo de comunicación y usa TLS para la autenticación inicial y el cifrado del tráfico, denominado modo directo .

Modos de conectividad disponibles

Los dos modos de conectividad disponibles son:

• Modo de puerta de enlace

  El modo de puerta de enlace es compatible con todas las plataformas del SDK. Si la aplicación se ejecuta dentro de una red corporativa con restricciones estrictas de firewall, el modo de puerta de enlace es la mejor opción porque usa el puerto HTTPS estándar y un único punto de conexión DNS. La desventaja para el rendimiento, sin embargo, es que el modo de pasarela implica un salto de red adicional cada vez que se leen desde o se escriben datos a Azure Cosmos DB. También se recomienda el modo de conexión de puerta de enlace al ejecutar aplicaciones en entornos con un número limitado de conexiones de socket.

  Cuando use el SDK en Azure Functions, especialmente en el plan de consumo, tenga en cuenta los límites actuales de las conexiones.

• Modo directo

  El modo directo admite la conectividad a través del protocolo TCP, mediante TLS para la autenticación inicial y el cifrado del tráfico, y ofrece un mejor rendimiento porque hay menos saltos de red. La aplicación se conecta directamente a las réplicas de back-end. El modo directo solo se admite actualmente en plataformas de SDK de .NET y Java.

Estos modos de conectividad básicamente condicionan la ruta que las solicitudes del plano de datos (lecturas y escrituras de documentos) toman de la máquina cliente a particiones en el back-end de Azure Cosmos DB. El modo directo es la opción preferida para mejorar el rendimiento; permite al cliente abrir conexiones TCP directamente a particiones en el back-end de Azure Cosmos DB y enviar solicitudes directamentesin intermediarios. Por el contrario, en el modo de pasarela, las solicitudes realizadas por el cliente se enrutan a un servidor denominado pasarela en el front-end de Azure Cosmos DB que, a su vez, deriva sus solicitudes a las particiones adecuadas en el back-end de Azure Cosmos DB.

Intervalos de puertos de servicio

Al usar el modo directo, debe asegurarse de que el cliente pueda acceder a los puertos que oscilan entre 10000 y 20000 porque Azure Cosmos DB usa puertos TCP dinámicos. Esto se suma a los puertos de pasarela. Al usar el modo directo en puntos de conexión privados, Azure Cosmos DB puede usar el intervalo completo de puertos TCP de 0 a 65535. Si estos puertos no están abiertos en el cliente e intenta usar el protocolo TCP, es posible que reciba un error "503 Servicio no disponible".

En la tabla siguiente se muestra un resumen de los modos de conectividad disponibles para varias API y los puertos de servicio usados para cada API:

Modo de conexión	Protocolo admitido	SDK admitidos	API o puerto de servicio
Gateway	HTTPS	Todos los SDK	SQL (443), MongoDB (10255), Tabla (443), Cassandra (10350), Grafo (443)
Directo	TCP (cifrado mediante TLS)	SDK de .NET, SDK de Java	Al usar puntos de conexión de servicio o públicos: puertos en el intervalo de 10000 a 20000 Al usar puntos de conexión privados: puertos en el intervalo de 0 a 65535

Arquitectura de conexión en modo directo

Como se detalla en la introducción, los clientes de modo directo se conectan directamente a los nodos de back-end a través del protocolo TCP. Cada nodo back-end representa una réplica de un conjunto de réplicas que pertenece a una partición física.

Enrutamiento

Cuando un SDK de Azure Cosmos DB en modo directo realiza una operación, debe resolver a qué réplica de back-end se va a conectar. El primer paso es saber a qué partición física debe ir la operación y, para ello, el SDK obtiene la información del contenedor que incluye la definición de clave de partición de un nodo de puerta de enlace. También necesita la información de enrutamiento que contiene las direcciones TCP de las réplicas. La información de enrutamiento también está disponible en los nodos de puerta de enlace y ambos se consideran metadatos del plano de control. Una vez que el SDK obtiene la información de enrutamiento, puede continuar para abrir las conexiones TCP a las réplicas que pertenecen a la partición física de destino y ejecutar las operaciones.

Cada conjunto de réplicas contiene una réplica principal y tres secundarias. Las operaciones de escritura siempre se enrutan a los nodos de la réplica principal mientras que las operaciones de lectura se pueden atender desde nodos principales o secundarios.

Dado que la información de contenedor y enrutamiento no cambian a menudo, se almacena en caché localmente en los SDK para que las operaciones posteriores puedan beneficiarse de esta información. Las conexiones TCP ya establecidas también se reutilizan entre operaciones. A menos que se configure de otro modo a través de las opciones de SDK, las conexiones se mantienen permanentemente durante la vigencia de la instancia del SDK.

Al igual que con cualquier arquitectura distribuida, las máquinas que contienen réplicas pueden someterse a actualizaciones o mantenimiento. El servicio garantiza que el conjunto de réplicas mantiene la coherencia, pero cualquier movimiento de réplica provocaría que las direcciones TCP existentes cambiaran. En estos casos, los SDK deben actualizar la información de enrutamiento y volver a conectarse a las nuevas direcciones a través de nuevas solicitudes de puerta de enlace. Estos eventos no deben afectar al Acuerdo de Nivel de Servicio de P99 general.

Volumen de conexiones

Cada partición física tiene un conjunto de réplicas de cuatro réplicas, con el fin de proporcionar el mejor rendimiento posible, los SDK terminan abriendo conexiones a todas las réplicas para cargas de trabajo que mezclan operaciones de escritura y lectura. Las operaciones concurrentes equilibran la carga entre las conexiones existentes para aprovechar el rendimiento de cada réplica.

Hay dos factores que determinan el número de conexiones TCP que abre el SDK:

• Número de particiones físicas

  En un estado estable, el SDK tiene una conexión por réplica por partición física. Cuanto mayor sea el número de particiones físicas de un contenedor, mayor será el número de conexiones abiertas. A medida que las operaciones se enrutan hacia las distintas particiones, las conexiones se establecen a petición. El número medio de conexiones sería el número de particiones físicas por cuatro.

• Volumen de solicitudes simultáneas

  Cada conexión establecida puede servir un número configurable de operaciones simultáneas. Si el volumen de operaciones simultáneas supera este umbral, se abren nuevas conexiones para atenderlas y es posible que para una partición física, el número de conexiones abiertas supere el número de estado estable. Este comportamiento se espera para las cargas de trabajo que podrían tener picos en su volumen operativo. Para el SDK de .NET, maxRequestsPerTcpConnection establece esta configuración y, para el SDK de Java, puede personalizar mediante la clase DirectConnectionConfig.

De forma predeterminada, las conexiones se mantienen permanentemente para beneficiar el rendimiento de las operaciones futuras (la apertura de una conexión tiene sobrecarga computacional). Es posible que haya algunos escenarios en los que quiera cerrar las conexiones que no se usan durante algún tiempo, ya que esto podría afectar ligeramente a las operaciones futuras. Para el SDK de .NET, esta configuración se establece mediante IdleTcpConnectionTimeout y, para el SDK de Java, puede personalizar mediante la clase DirectConnectionConfig. No se recomienda establecer estas configuraciones en valores bajos, ya que puede provocar que las conexiones se cierren con frecuencia y afecten al rendimiento general.

Detalles de implementación específicos del lenguaje

Para obtener detalles de implementación sobre un lenguaje, consulte:

• Información de implementación del SDK de .NET
• Información del modo directo del SDK de Java

Pasos siguientes

Para optimizaciones específicas del rendimiento de la plataforma del SDK:

• Sugerencias de rendimiento del SDK de .NET V2
• Sugerencias de rendimiento del SDK de .NET V3
• Sugerencias de rendimiento del SDK de Java V4

¿Está intentando hacer la planificación de capacidad para una migración a Azure Cosmos DB? Puede utilizar información sobre su clúster de bases de datos existente para la planificación de capacidad.

• Si lo único que sabe es el número de vcores y servidores en su clúster de base de datos, lea sobre la estimación de unidades de solicitud mediante vCores o vCPUs.
• Si conoce las tasas de solicitudes típicas de la carga de trabajo de base de datos actual, lea sobre la estimación de unidades de solicitud mediante la herramienta de planeamiento de capacidad de Azure Cosmos DB.