Citrix ADC

Compatibilidad con persistencia para el servidor virtual de cambio de contenido

October 4, 2021

Contribuido por:

Las aplicaciones están pasando de arquitecturas monolíticas a arquitecturas de microservicios. Diferentes versiones de la misma aplicación pueden coexistir en la arquitectura de microservicios. El dispositivo Citrix ADC debe admitir la implementación continua de aplicaciones. Se logra mediante plataformas que realizan implementaciones Canary (como Spinnaker). En una configuración de implementación continua, una versión más reciente de una aplicación se implementa automáticamente y se expone al tráfico del cliente en etapas hasta que la aplicación se mantiene estable para tomar tráfico completo. Además, debe haber servicios ininterrumpidos para el cliente.

La función de cambio de contenido Citrix ADC permite a Citrix ADC el dispositivo distribuir solicitudes de cliente entre varios servidores virtuales de equilibrio de carga en función de las directivas vinculadas al servidor virtual de cambio de contenido.

Para implementaciones continuas, la cambio de contenido se utiliza para seleccionar el servidor virtual de equilibrio de carga que sirve varias versiones de una aplicación.

En la cambio de contenido, la selección de un servidor virtual de equilibrio de carga para una versión de aplicación específica cambia en tiempo de ejecución debido al cambio en las directivas de cambio de contenido. Durante esta transición, si algunas sesiones están presentes con versiones anteriores de la aplicación, dicho tráfico debe seguir siendo servido únicamente por versiones anteriores. Para admitir este requisito, el dispositivo Citrix ADC mantiene la persistencia en varios grupos de equilibrio de carga detrás de un servidor virtual de cambio de contenido. La persistencia del servidor virtual de cambio de contenido permite una transición fluida de los clientes de una versión a otra.

Tipos de persistencia admitidos en el servidor virtual de cambio de contenido

Los siguientes tipos de persistencia se admiten en servidores virtuales de cambio de contenido.

Tipo de persistencia	Descripción
IP de origen	SOURCEIP. Las conexiones desde la misma dirección IP del cliente forman parte de la misma sesión de persistencia. Para obtener más detalles, vea Persistencia de la dirección IP de origen.
Cookie HTTP	COOKIEINSERT. Las conexiones que tienen el mismo encabezado HTTP Cookie son partes de la misma sesión de persistencia. El formato de la cookie que inserta el dispositivo Citrix ADC es: **NSC_ <vid_str of CSvserver> = <vid_str of Lbvserver> donde NSC_XXXX es el identificador del servidor virtual derivado del nombre del servidor virtual. Para obtener más información, consulte Persistencia de cookies HTTP.
ID de sesión SSL	SSLSESSION. Las conexiones que tienen el mismo ID de sesión SSL son parte de la misma sesión de persistencia. Para obtener más detalles, vea Persistencia de ID de sesión SSL.

Puede configurar un valor de tiempo de espera para la persistencia basado en cookies HTTP. Si establece el valor de tiempo de espera en 0, el dispositivo ADC no especifica el tiempo de caducidad, independientemente de la versión de la cookie HTTP utilizada. El tiempo de caducidad depende entonces del software cliente, y tales cookies son válidas solo si el software se está ejecutando.

Dependiendo del tipo de persistencia que haya configurado, el servidor virtual puede admitir 250.000 conexiones persistentes simultáneas o cualquier número de conexiones persistentes hasta los límites impuestos por la cantidad de memoria del dispositivo Citrix ADC. La siguiente tabla muestra qué tipos de persistencia pertenecen a cada categoría.

Tipo de persistencia	Número de conexiones persistentes simultáneas admitidas
IP de origen, ID de sesión SSL	250000
Cookie HTTP	Límite de memoria. En CookieInsert, si el tiempo de espera no es 0, el número de conexiones está limitado por la memoria.

Algunos tipos de persistencia son específicos de determinados tipos de servidor virtual. La tabla siguiente muestra cada tipo de persistencia e indica qué tipos de persistencia se admiten en qué tipos de servidor virtual.

Tipo de persistencia	HTTP	HTTPS	TCP	UDP/IP	Puente SSL_Bridge	SSL_TCP	RTSP	SIP_UDP
SOURCEIP	Sí	Sí	Sí	Sí	Sí	Sí	No	No
COOKIEINSERT	Sí	Sí	No	No	No	No	No	No
SSLSESSION	No	Sí	No	No	Sí	Sí	No	No

Compatibilidad con persistencia de copias de seguridad

Puede configurar el servidor virtual de cambio de contenido para que utilice el tipo de persistencia IP de origen como tipo de persistencia de copia de seguridad cuando falla el tipo de persistencia de cookies. Es útil para implementaciones Canary en la arquitectura de microservicios. Cuando se produce un error en el tipo de persistencia de cookies, el dispositivo vuelve a la persistencia basada en IP de origen solo cuando el explorador cliente no devuelve ninguna cookie en la solicitud. Sin embargo, si el explorador devuelve una cookie (no necesariamente la cookie de persistencia), se supone que el explorador admite cookies y, por lo tanto, la persistencia de la copia de seguridad no se activa.También puede establecer un valor de tiempo de espera para la persistencia de la copia de seguridad. Tiempo de espera es el período de tiempo para el que está en vigor una sesión de persistencia.

Cómo funciona la persistencia en el cambio de contenido del servidor virtual

Caso 1: Un servidor virtual de cambio de contenido sin persistencia

El siguiente ejemplo ilustra la implementación de varias versiones de una aplicación con un servidor virtual de cambio de contenido sin persistencia.

persistence-cs1

Cuando el cliente C1 envía una solicitud a la aplicación, la solicitud se envía al servidor virtual de cambio de contenido en el dispositivo Citrix ADC. El servidor virtual de cambio de contenido evalúa la directiva y reenvía la solicitud al servidor virtual de equilibrio de carga (LB1) que está sirviendo la versión v1 de la aplicación.

persistence-cs2

Considere una nueva versión v2 de la aplicación está implementada y tiene que estar expuesta a un subconjunto de usuarios. El nuevo servidor virtual de equilibrio de carga (LB2) que sirve la versión v2 está vinculado al servidor virtual de cambio de contenido mediante la directiva de cambio de contenido adecuada.

Cuando el cliente C1 envía una nueva solicitud, la directiva se evalúa de nuevo y la solicitud se reenvía al servidor virtual de equilibrio de carga LB2. Por lo tanto, las transacciones para aplicaciones con estado fallan si se implementan varias versiones de la aplicación.

Caso 2: Content switching server virtual con persistencia

El siguiente ejemplo ilustra la implementación de varias versiones de la aplicación con un servidor virtual de cambio de contenido con persistencia.

persistence-cs3

Cuando el cliente C1 envía una solicitud a la aplicación, la solicitud se envía al servidor virtual de cambio de contenido en el dispositivo Citrix ADC. El servidor virtual de cambio de contenido evalúa la directiva, crea una entrada de sesión de persistencia y reenvía la solicitud al servidor virtual de equilibrio de carga LB1 que sirve la versión v1 de la aplicación.

persistence-cs4

El mismo cliente C1 vuelve a solicitar la aplicación y la solicitud se envía al servidor virtual de cambio de contenido en el dispositivo Citrix ADC. Se realiza una búsqueda para la sesión de persistencia y el servidor virtual de equilibrio de carga LB1 se toma de la sesión de persistencia existente y la solicitud se reenvía a LB1. No se produce ninguna rotura de la transacción existente con esta solución; por lo tanto, se mantiene la naturaleza de estado de la aplicación.

persistence-cs5

Consideremos un nuevo cliente C2. La nueva solicitud C2 se envía a la versión más reciente de la aplicación a través de la evaluación de directivas, ya que no hay ninguna sesión de persistencia existente para este cliente. Resulta en una implementación correcta de la versión más reciente de la aplicación sin romper su estado.

Debido al soporte de persistencia, los clientes pueden implementar múltiples contenidos o diferentes versiones de la aplicación sin afectar las transacciones existentes, específicamente para aplicaciones con estado. No es posible sin persistencia en la imagen.

Configurar el tipo de persistencia en el servidor virtual de cambio de contenido mediante la CLI

En el símbolo del sistema, escriba:

set cs vserver <name> -PersistenceType <type> [-timeout <integer>]
<!--NeedCopy-->

Ejemplo:

set cs vserver Vserver-CS-1 -persistenceType SOURCEIP -timeout 60
<!--NeedCopy-->

Configurar el tipo de persistencia en el servidor virtual de cambio de contenido mediante la interfaz gráfica de usuario

Vaya a Administración del tráfico > Cambio de contenido > Servidores virtuales y haga clic en Agregar.
En Configuración básica, configure los detalles de persistencia.

La versión oficial de este contenido está en inglés. Para mayor comodidad, parte del contenido de la documentación de Citrix solo tiene traducción automática. Citrix no puede controlar el contenido con traducción automática, que puede contener errores, imprecisiones o un lenguaje inadecuado. No se ofrece ninguna garantía, ni implícita ni explícita, en cuanto a la exactitud, la fiabilidad, la idoneidad o la precisión de las traducciones realizadas del original en inglés a cualquier otro idioma, o que su producto o servicio de Citrix se ajusten a cualquier contenido con traducción automática, y cualquier garantía provista bajo el contrato de licencia del usuario final o las condiciones de servicio, o cualquier otro contrato con Citrix, de que el producto o el servicio se ajusten a la documentación no se aplicará en cuanto dicha documentación se ha traducido automáticamente. Citrix no se hace responsable de los daños o los problemas que puedan surgir del uso del contenido traducido automáticamente.

Compatibilidad con persistencia para el servidor virtual de cambio de contenido

October 4, 2021

Contribuido por:

October 4, 2021

Contribuido por:

En este artículo

Tipos de persistencia admitidos en el servidor virtual de cambio de contenido
Compatibilidad con persistencia de copias de seguridad
Cómo funciona la persistencia en el cambio de contenido del servidor virtual
Configurar el tipo de persistencia en el servidor virtual de cambio de contenido mediante la CLI
Configurar el tipo de persistencia en el servidor virtual de cambio de contenido mediante la interfaz gráfica de usuario