Documentación de productos
ADC
14.1 - Current Release 13.1 13.0 12.1
Ver PDF

Función de persistencia para servidor virtual de conmutación de contenido

May 9, 2023
Contribución de: 
C

Las aplicaciones están pasando de arquitecturas monolíticas a arquitecturas de microservicios. En la arquitectura de microservicios pueden coexistir diferentes versiones de la misma aplicación. El dispositivo NetScaler 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 por etapas hasta que la aplicación se estabilice para absorber todo el tráfico. Además, debe haber servicios ininterrumpidos para el cliente.

La función de conmutación de contenido de NetScaler permite a NetScaler, el dispositivo, distribuir las solicitudes de los clientes entre varios servidores virtuales de equilibrio de carga en función de las directivas vinculadas al servidor virtual de conmutación de contenido.

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

En la conmutación 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 en versiones anteriores de la aplicación, dicho tráfico debe seguir siendo atendido únicamente por las versiones anteriores. Para cumplir con este requisito, el dispositivo NetScaler mantiene la persistencia en varios grupos de equilibrio de carga detrás de un servidor virtual de conmutación de contenido. La persistencia del servidor virtual de conmutación de contenido permite una transición perfecta de los clientes de una versión a otra.

Tipos de persistencia admitidos en el servidor virtual de conmutación de contenido

Los servidores virtuales de conmutación de contenido admiten los siguientes tipos de persistencia.

Tipo de persistencia Descripción
IP de origen IP DE ORIGEN. Las conexiones de la misma dirección IP del cliente forman parte de la misma sesión de persistencia. Para obtener más información, consulte Persistencia de la dirección IP de origen.
Cookie HTTP INSERTO PARA COOKIES. Las conexiones que tienen el mismo encabezado de cookie HTTP forman parte de la misma sesión de persistencia. El formato de la cookie que inserta el dispositivo NetScaler es: NSC_ = donde NSC_XXXX es el ID del servidor virtual que se deriva del nombre del servidor virtual. Para obtener más información, consulte Persistencia cookie HTTP.
ID de sesión SSL SESIÓN DE SESIÓN. Las conexiones que tienen el mismo ID de sesión SSL forman parte de la misma sesión de persistencia. Para obtener más información, consulte Persistencia del ID de sesión SSL.

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

Según el tipo de persistencia que haya configurado, el servidor virtual puede admitir 250 000 conexiones persistentes simultáneas o cualquier cantidad de conexiones persistentes hasta los límites impuestos por la cantidad de memoria del dispositivo NetScaler. La siguiente tabla muestra los tipos de persistencia que se incluyen en cada categoría.

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

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

Tipo de persistencia HTTP HTTPS TCP UDP/IP SSL_Bridge SSL_TCP RTSP SIP_UDP
SOURCEIP Sí Sí Sí Sí Sí Sí No No
INSERTO DE COOKIE Sí Sí No No No No No No
SESIÓN SSL No Sí No No Sí Sí No No

Soporte de persistencia de copias de seguridad

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

Cómo funciona la persistencia en el servidor virtual de conmutación de contenido

Escenario 1: Un servidor virtual de conmutación de contenido sin persistencia

El siguiente ejemplo ilustra la implementación de varias versiones de una aplicación con un servidor virtual de conmutación 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 conmutación de contenido del dispositivo NetScaler. El servidor virtual de conmutación de contenido evalúa la directiva y reenvía la solicitud al servidor virtual de equilibrio de carga (LB1) que ofrece la versión v1 de la aplicación.

persistence-cs2

Tenga en cuenta que se ha implementado una nueva versión v2 de la aplicación y debe estar expuesta a un subconjunto de usuarios. El nuevo servidor virtual de equilibrio de carga (LB2) que sirve a la versión v2 está vinculado al servidor virtual de conmutación de contenido mediante la directiva de conmutación de contenido correspondiente.

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 de las aplicaciones con estado fallan si se implementan varias versiones de la aplicación.

Escenario 2: servidor virtual de conmutación de contenido con persistencia

El siguiente ejemplo ilustra la implementación de varias versiones de la aplicación con un servidor virtual de conmutación 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 conmutación de contenido del dispositivo NetScaler. El servidor virtual de conmutación de contenido evalúa la directiva, crea una entrada de sesión persistente y reenvía la solicitud al servidor virtual de equilibrio de carga LB1 que ofrece 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 conmutación de contenido del dispositivo NetScaler. Se realiza una búsqueda de la sesión de persistencia y se extrae el servidor virtual de equilibrio de carga LB1 de la sesión de persistencia existente y la solicitud se reenvía a LB1. Con esta solución no se interrumpe la transacción existente; por lo tanto, se mantiene la naturaleza estatal 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 mediante una evaluación de directivas, ya que no existe ninguna sesión de persistencia para este cliente. El resultado es un despliegue exitoso de la versión más reciente de la aplicación sin interrumpir su estado.

Gracias al soporte de persistencia, los clientes pueden implementar varios contenidos o diferentes versiones de la aplicación sin problemas sin afectar a las transacciones existentes, específicamente en el caso de las aplicaciones con estado. No es posible sin persistencia en la imagen.

Configure el tipo de persistencia en el servidor virtual de conmutación de contenido mediante la CLI

En la línea de comandos, escriba:

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

Ejemplo:

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

Configure el tipo de persistencia en el servidor virtual de conmutación de contenido mediante la interfaz gráfica de usuario

  1. Vaya a Administración del tráfico > Conmutación de contenido > Servidores virtuales y haga clic en Agregar.

  2. En Configuración básica, configure los detalles de persistencia.

Función de persistencia para servidor virtual de conmutación de contenido
May 9, 2023
Contribución de: 
C
May 9, 2023
Contribución de: 
C

En este artículo

Comentarios sobre el sitio | Your privacy choices footer linkSus opciones de privacidad | Condiciones legales y de privacidad | Preferencias de cookies | Parámetros de consentimiento | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.