-
-
Implementar una instancia de NetScaler VPX
-
Optimice el rendimiento de NetScaler VPX en VMware ESX, Linux KVM y Citrix Hypervisors
-
Mejore el rendimiento de SSL-TPS en plataformas de nube pública
-
Configurar subprocesos múltiples simultáneos para NetScaler VPX en nubes públicas
-
Instalar una instancia de NetScaler VPX en un servidor desnudo
-
Instalar una instancia de NetScaler VPX en Citrix Hypervisor
-
Instalación de una instancia NetScaler VPX en la nube de VMware en AWS
-
Instalación de una instancia NetScaler VPX en servidores Microsoft Hyper-V
-
Instalar una instancia de NetScaler VPX en la plataforma Linux-KVM
-
Requisitos previos para instalar dispositivos virtuales NetScaler VPX en la plataforma Linux-KVM
-
Aprovisionamiento del dispositivo virtual NetScaler mediante OpenStack
-
Aprovisionamiento del dispositivo virtual NetScaler mediante Virtual Machine Manager
-
Configuración de dispositivos virtuales NetScaler para que usen la interfaz de red SR-IOV
-
Configuración de dispositivos virtuales NetScaler para que usen la interfaz de red PCI Passthrough
-
Aprovisionamiento del dispositivo virtual NetScaler mediante el programa virsh
-
Administración de las máquinas virtuales invitadas de NetScaler
-
Aprovisionamiento del dispositivo virtual NetScaler con SR-IOV en OpenStack
-
-
Implementar una instancia de NetScaler VPX en AWS
-
Configurar las funciones de IAM de AWS en la instancia de NetScaler VPX
-
Implementación de una instancia independiente NetScaler VPX en AWS
-
Servidores de equilibrio de carga en diferentes zonas de disponibilidad
-
Implementar un par de alta disponibilidad de VPX en la misma zona de disponibilidad de AWS
-
Alta disponibilidad en diferentes zonas de disponibilidad de AWS
-
Implementar un par de alta disponibilidad VPX con direcciones IP privadas en distintas zonas de AWS
-
Implementación de una instancia NetScaler VPX en AWS Outposts
-
Proteja AWS API Gateway mediante el firewall de aplicaciones web de Citrix
-
Configurar una instancia de NetScaler VPX para utilizar la interfaz de red SR-IOV
-
Configurar una instancia de NetScaler VPX para utilizar redes mejoradas con AWS ENA
-
Implementar una instancia de NetScaler VPX en Microsoft Azure
-
Arquitectura de red para instancias NetScaler VPX en Microsoft Azure
-
Configuración de varias direcciones IP para una instancia independiente NetScaler VPX
-
Configurar una configuración de alta disponibilidad con varias direcciones IP y NIC
-
Configurar una instancia de NetScaler VPX para usar redes aceleradas de Azure
-
Configure los nodos HA-INC mediante la plantilla de alta disponibilidad de NetScaler con Azure ILB
-
Instalación de una instancia NetScaler VPX en la solución Azure VMware
-
Configurar una instancia independiente de NetScaler VPX en la solución Azure VMware
-
Configurar una instalación de alta disponibilidad de NetScaler VPX en la solución Azure VMware
-
Configurar el servidor de rutas de Azure con un par de alta disponibilidad de NetScaler VPX
-
Configurar GSLB en una configuración de alta disponibilidad activa en espera
-
Configuración de grupos de direcciones (IIP) para un dispositivo NetScaler Gateway
-
Scripts de PowerShell adicionales para la implementación de Azure
-
Implementación de una instancia NetScaler VPX en Google Cloud Platform
-
Implementar un par de VPX de alta disponibilidad en Google Cloud Platform
-
Implementar un par de alta disponibilidad VPX con direcciones IP privadas en Google Cloud Platform
-
Instalar una instancia de NetScaler VPX en VMware Engine de Google Cloud
-
Compatibilidad con escalado VIP para la instancia NetScaler VPX en GCP
-
-
Automatizar la implementación y las configuraciones de NetScaler
-
Actualización y degradación de un dispositivo NetScaler
-
Consideraciones de actualización para configuraciones con directivas clásicas
-
Consideraciones sobre la actualización de archivos de configuración personalizados
-
Consideraciones sobre la actualización: Configuración de SNMP
-
Compatibilidad con actualización de software en servicio para alta disponibilidad
-
Soluciones para proveedores de servicios de telecomunicaciones
-
Equilibrio de carga del tráfico de plano de control basado en protocolos de diámetro, SIP y SMPP
-
Utilización del ancho de banda mediante la funcionalidad de redirección de caché
-
-
-
Autenticación, autorización y auditoría del tráfico de aplicaciones
-
Cómo funciona la autenticación, la autorización y la auditoría
-
Componentes básicos de la configuración de autenticación, autorización y auditoría
-
Autorización del acceso de los usuarios a los recursos de aplicaciones
-
NetScaler como proxy del servicio de federación de Active Directory
-
NetScaler Gateway local como proveedor de identidad de Citrix Cloud
-
Compatibilidad de configuración para el atributo de cookie SameSite
-
Configuración de autenticación, autorización y auditoría para protocolos de uso común
-
Solución de problemas relacionados con la autenticación y la autorización
-
-
-
-
Configuración de la expresión de directiva avanzada: Introducción
-
Expresiones de directivas avanzadas: trabajo con fechas, horas y números
-
Expresiones de directivas avanzadas: análisis de datos HTTP, TCP y UDP
-
Expresiones de directivas avanzadas: análisis de certificados SSL
-
Expresiones de directivas avanzadas: direcciones IP y MAC, rendimiento, ID de VLAN
-
Expresiones de directivas avanzadas: funciones de Stream Analytics
-
Ejemplos de tutoriales de directivas avanzadas para reescritura
-
-
-
Protecciones de nivel superior
-
Protección basada en gramática SQL para cargas útiles HTML y JSON
-
Protección basada en gramática por inyección de comandos para carga útil HTML
-
Reglas de relajación y denegación para gestionar ataques de inyección HTML SQL
-
Compatibilidad con palabras clave personalizadas para la carga útil HTML
-
Compatibilidad con firewall de aplicaciones para Google Web Toolkit
-
Comprobaciones de protección XML
-
-
-
Administrar un servidor virtual de redirección de caché
-
Ver estadísticas del servidor virtual de redirección de caché
-
Habilitar o inhabilitar un servidor virtual de redirección de caché
-
Resultados directos de directivas a la caché en lugar del origen
-
Realizar una copia de seguridad de un servidor virtual de redirección de caché
-
Habilitar la comprobación de estado TCP externa para servidores virtuales UDP
-
-
Traducir la dirección IP de destino de una solicitud a la dirección IP de origen
-
-
Descripción general del cluster
-
Administración del clúster de NetScaler
-
Grupos de nodos para configuraciones detectadas y parcialmente rayadas
-
Desactivación de la dirección en el plano posterior del clúster
-
Eliminar un nodo de un clúster implementado mediante la agregación de vínculos de clúster
-
Supervisión de la configuración del clúster mediante SNMP MIB con enlace SNMP
-
Supervisión de los errores de propagación de comandos en una implementación de clúster
-
Compatibilidad con logotipos preparados para IPv6 para clústeres
-
Enlace de interfaz VRRP en un clúster activo de un solo nodo
-
Casos de configuración y uso de clústeres
-
Migración de una configuración de HA a una configuración de clúster
-
Interfaces comunes para cliente y servidor e interfaces dedicadas para backplane
-
Conmutador común para cliente y servidor y conmutador dedicado para placa posterior
-
Supervisar servicios en un clúster mediante la supervisión de rutas
-
-
Configurar NetScaler como un solucionador de stubs con reconocimiento de seguridad no validante
-
Compatibilidad con tramas gigantes para DNS para gestionar respuestas de grandes tamaños
-
Configurar el almacenamiento en caché negativo de los registros DNS
-
Equilibrio de carga global del servidor
-
Configurar entidades GSLB individualmente
-
Cómo funciona el sistema de nombres de dominio con GSLB
-
Recomendaciones de actualización para la implementación de GSLB
-
-
Estado de servicio y servidor virtual de equilibrio de carga
-
Insertar atributos de cookie a las cookies generadas por ADC
-
Proteja una configuración de equilibrio de carga contra fallos
-
Administrar el tráfico de clientes
-
Configurar servidores virtuales de equilibrio de carga sin sesión
-
Reescritura de puertos y protocolos para la redirección HTTP
-
Insertar la dirección IP y el puerto de un servidor virtual en el encabezado de solicitud
-
Utilizar una IP de origen especificada para la comunicación de back-end
-
Establecer un valor de tiempo de espera para las conexiones de cliente inactivas
-
Gestionar el tráfico de clientes en función de la velocidad de tráfico
-
Utilizar un puerto de origen de un rango de puertos especificado para la comunicación de back-end
-
Configurar la persistencia IP de origen para la comunicación back-end
-
-
Configuración avanzada de equilibrio de carga
-
Aumenta gradualmente la carga en un nuevo servicio con un inicio lento a nivel de servidor virtual
-
Proteger aplicaciones en servidores protegidos contra los picos de tráfico
-
Habilitar la limpieza de las conexiones de servicios y servidores virtuales
-
Habilitar o inhabilitar la sesión de persistencia en los servicios TROFS
-
Habilitar la comprobación de estado TCP externa para servidores virtuales UDP
-
Mantener la conexión de cliente para varias solicitudes de cliente
-
Insertar la dirección IP del cliente en el encabezado de solicitud
-
Utilizar la dirección IP de origen del cliente al conectarse al servidor
-
Configurar el puerto de origen para las conexiones del lado del servidor
-
Establecer un límite en el número de solicitudes por conexión al servidor
-
Establecer un valor de umbral para los monitores enlazados a un servicio
-
Establecer un valor de tiempo de espera para las conexiones de clientes inactivas
-
Establecer un valor de tiempo de espera para las conexiones de servidor inactivas
-
Establecer un límite en el uso del ancho de banda por parte de los clientes
-
Conservar el identificador de VLAN para la transparencia de VLAN
-
-
Configurar monitores en una configuración de equilibrio de carga
-
Configurar el equilibrio de carga para los protocolos de uso común
-
Caso de uso 3: Configurar el equilibrio de carga en modo de Direct Server Return
-
Caso de uso 6: Configurar el equilibrio de carga en modo DSR para redes IPv6 mediante el campo TOS
-
Caso de uso 7: Configurar el equilibrio de carga en modo DSR mediante IP sobre IP
-
Caso de uso 8: Configurar el equilibrio de carga en modo de un brazo
-
Caso de uso 9: Configurar el equilibrio de carga en modo en línea
-
Caso de uso 10: Equilibrio de carga de los servidores del sistema de detección de intrusiones
-
Caso de uso 11: Aislamiento del tráfico de red mediante directivas de escucha
-
Caso de uso 12: Configurar Citrix Virtual Desktops para el equilibrio de carga
-
Caso de uso 13: Configurar Citrix Virtual Apps and Desktops para equilibrar la carga
-
Caso de uso 14: Asistente de ShareFile para equilibrar la carga Citrix ShareFile
-
Caso práctico 15: Configurar el equilibrio de carga de capa 4 en el dispositivo NetScaler
-
-
Configurar para obtener el tráfico de datos NetScaler FreeBSD desde una dirección SNIP
-
-
Compatibilidad con protocolos TLSv1.3 tal como se define en RFC 8446
-
Matriz de compatibilidad de certificados de servidor en el dispositivo ADC
-
Compatibilidad con plataformas basadas en chip SSL Intel Coleto
-
Compatibilidad con el módulo de seguridad de hardware Thales Luna Network
-
-
-
-
Configuración de un túnel de CloudBridge Connector entre dos centros de datos
-
Configuración de CloudBridge Connector entre el centro de datos y la nube de AWS
-
Configuración de un túnel de CloudBridge Connector entre un centro de datos y Azure Cloud
-
Configuración del túnel CloudBridge Connector entre Datacenter y SoftLayer Enterprise Cloud
-
Diagnóstico y solución de problemas de túnel CloudBridge Connector
-
-
Puntos a tener en cuenta para una configuración de alta disponibilidad
-
Sincronizar archivos de configuración en una configuración de alta disponibilidad
-
Restricción del tráfico de sincronización de alta disponibilidad a una VLAN
-
Configuración de nodos de alta disponibilidad en distintas subredes
-
Limitación de las conmutaciones por error causadas por monitores de ruta en modo no INC
-
Configuración del conjunto de interfaces de conmutación por error
-
Administración de mensajes de latido de alta disponibilidad en un dispositivo NetScaler
-
Quitar y reemplazar un NetScaler en una configuración de alta disponibilidad
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Cómo admite el sistema de nombres de dominio GSLB
El sistema de nombres de dominio (DNS) se considera una base de datos distribuida, que utiliza la arquitectura cliente/servidor. Los servidores de nombres son los servidores de la arquitectura y los solucionadores son los clientes que son rutinas de biblioteca instaladas en un sistema operativo que crean y envían consultas a través de la red.
La jerarquía lógica del DNS se muestra en el siguiente diagrama:
Nota:
Los servidores raíz de segundo nivel son responsables de mantener las asignaciones de servidor de nombres a direcciones para delegaciones de servidores de nombres dentro de los dominios .com, .net, .org, .gov, etc. Cada dominio de los dominios de segundo nivel es responsable de mantener las asignaciones de servidor de nombres a direcciones para los dominios organizativos de nivel inferior. A nivel de la organización, las direcciones de host individuales se resuelven para www, FTP y otros hosts que proporcionan servicios.
Delegación
El objetivo principal de la topología DNS actual es aliviar la carga de mantener todos los registros de direcciones en una sola autoridad. Esto permite la delegación de un espacio de nombres de organización a esa organización en particular. La organización puede delegar aún más su espacio en subdominios de la organización. Por ejemplo, en citrix.com puede crear subdominios llamados sales.citrix.com
education.citrix.com
, y support.citrix.com
. Los departamentos correspondientes pueden mantener su propio conjunto de servidores de nombres autorizados para su subdominio y, a continuación, mantener su propio conjunto de asignaciones de nombres de host a direcciones. Ningún departamento es responsable de mantener todos los registros de direcciones de Citrix. Cada departamento puede cambiar direcciones y modificar topologías, y no imponer más trabajo en el dominio u organización de nivel superior.
Beneficios de la topología jerárquica
Algunas de las ventajas de la topología jerárquica incluyen:
- Escalabilidad
- Agregar funcionalidad de almacenamiento en caché a los servidores de nombres de cada nivel, donde un host atiende una solicitud DNS que no tiene autoridad para un dominio determinado pero puede contribuir a la respuesta a la consulta y reducir la congestión y el tiempo de respuesta.
- El almacenamiento en caché también crea redundancia y resiliencia ante fallos del servidor. Si falla un servidor de nombres, es posible que los registros se puedan entregar desde otros servidores que tienen copias recientes en caché de los mismos registros.
Resolvers
Los solucionadores son el componente cliente del sistema DNS. Los programas que se ejecutan en un host que necesitan información del espacio de nombres de dominio utilizan el solucionador. El solucionador se ocupa de:
- Consulta de un servidor de nombres.
- Interpretación de respuestas (que pueden ser registros de recursos o un error).
- Devolver la información a los programas que la solicitaron.
El solucionador es un conjunto de rutinas de biblioteca que se compilan en programas como telnet, FTP y ping. No son procesos separados. Los solucionadores pueden crear una consulta, enviarla y esperar una respuesta. Y envíelo de nuevo (posiblemente a un servidor de nombres secundario) si no se responde dentro de un tiempo determinado. Este tipo de solucionadores se conocen como solucionadores de código auxiliar. Algunos solucionadores tienen la funcionalidad agregada a los registros en caché y respetan el tiempo de vida (TTL). En Windows, esta funcionalidad está disponible a través del servicio cliente DNS; se puede ver a través de la consola “services.msc”.
Servidores de nombres
En general, los servidores de nombres almacenan información completa sobre una parte determinada de un espacio de nombres de dominio (denominado zona). A continuación, se dice que el servidor de nombres tiene autoridad para esa zona. También pueden ser autorizados para varias zonas.
La diferencia entre un dominio y una zona es sutil. Un dominio es el conjunto completo de entidades, incluidos sus subdominios, mientras que una zona es solo la información de un dominio que no se delega en otro servidor de nombres. Un ejemplo de zona es citrix.com
, mientras que sales.citrix.com
es una zona separada si esa zona se delega en otro servidor de nombres dentro del subdominio. En este caso, la zona Citrix principal puede incluir citrix.com
it.citrix.com
, y support.citrix.com
. Dado que sales.citrix.com
está delegado, no forma parte de la zona sobre la que el servidor de nombres citrix.com
tiene autoridad. En el siguiente diagrama se muestran las dos zonas.
Para delegar correctamente un subdominio, debe asignar autoridad para el subdominio a distintos servidores de nombres. En el ejemplo anterior, ns1.citrix.com
no contiene información sobre el subdominio sales.citrix.com
. En su lugar, contiene punteros a los servidores de nombres autorizados para el subdominio ns1.sales.citrix.com
.
Servidores de nombres raíz y resolución de consultas
Los servidores de nombres raíz conocen las direcciones IP de todos los servidores de nombres autorizados para los dominios de segundo nivel. Si un servidor de nombres no tiene información sobre un dominio determinado en sus propios archivos de datos, solo necesita ponerse en contacto con un servidor raíz para comenzar a atravesar la rama adecuada de la estructura de árbol DNS para llegar finalmente al dominio dado. Esto implica una serie de solicitudes a varios servidores de nombres para ayudar con el recorrido del árbol y encontrar el siguiente servidor de nombres autorizado, con el que debe contactarse para obtener más resolución.
En el siguiente diagrama se muestra una solicitud DNS típica, suponiendo que no haya ningún registro almacenado en caché para el nombre solicitado durante la transversal. En el siguiente ejemplo se utiliza una simulación del dominio Citrix.
Consultas recursivas y no recursivas
En el ejemplo anterior se muestran los dos tipos de consultas que pueden producirse.
-
Consulta recursiva: La consulta entre el solucionador y el servidor de nombres configurado localmente es recursiva. Esto significa que el servidor de nombres recibe la consulta y no responde al solucionador hasta que se responde completamente a la consulta o se devuelve un error. Si el servidor de nombres recibe una referencia a la consulta, el servidor de nombres sigue la referencia hasta que el servidor de nombres finalmente recibe la respuesta (dirección IP) devuelta.
-
Consulta no recursiva: La consulta que el servidor de nombres configurado localmente realiza en el servidor de nombres de nivel de dominio autorizado posterior no es recursiva (o iterativa). Cada solicitud se responde inmediatamente con una referencia a un servidor autorizado de nivel inferior o la respuesta a la consulta, si el servidor de nombres consultado contiene la respuesta en sus archivos de datos o en su caché.
Almacenamiento en caché
Aunque el proceso de resolución está involucrado y podría requerir pequeñas solicitudes a varios hosts, es rápido. Uno de los factores que aumenta la velocidad de la resolución DNS es el almacenamiento en caché. Cada vez que un servidor de nombres recibe una consulta recursiva, es posible que tenga que comunicarse con otros servidores para llegar al servidor autorizado adecuado para la solicitud específica. Almacena toda la información que recibe para referencia futura. Cuando el siguiente cliente realiza una solicitud similar, como un host diferente pero en el mismo dominio, ya conoce el servidor de nombres autorizado para ese dominio y puede enviar una solicitud directamente allí en lugar de iniciarse en el servidor de nombres raíz.
También se puede almacenar en caché para respuestas negativas, como las consultas de hosts que no existen. En este caso, el servidor no debe consultar al servidor de nombres autorizado del dominio solicitado para averiguar que el host no existe. Para ahorrar tiempo, el servidor de nombres simplemente comprueba la memoria caché y responde con el registro negativo.
Los servidores de nombres no almacenan en caché los registros indefinidamente o, de lo contrario, nunca podrá actualizar las direcciones IP. Para evitar problemas de sincronización, las respuestas DNS contienen un tiempo de vida (TTL). Este campo describe el intervalo de tiempo para el que la caché puede almacenar un registro antes de descartarlo y comprobar con el servidor de nombres autorizado los registros actualizados. Si los registros no han cambiado, el uso de TTL también permite respuestas dinámicas rápidas desde dispositivos que realizan GSLB.
Tipos de registros de recursos
Varios RFC proporcionan una lista completa de los tipos de registros de recursos DNS y su descripción. En la tabla siguiente se enumeran los tipos de registros de recursos comunes.
Tipo de registro de recursos | Descripción | RFC |
---|---|---|
A | Dirección de host | RFC 1035 |
NS | Un servidor de nombres autoritativo | RFC 1035 |
MD | Un destino de correo (Obsoleto - usar MX) | RFC 1035 |
MF | Un reenviador de correo (Obsoleto - usar MX) | RFC 1035 |
CNAME | El nombre canónico de un alias | RFC 1035 |
JABONERA | Marca el inicio de una zona de autoridad | RFC 1035 |
SEMANAS | Descripción de un servicio bien conocida | RFC 1035 |
PTR | Un puntero de nombre de dominio | RFC 1035 |
HINFO | Información del host | RFC 1035 |
MINFO | Información sobre buzones de correo o listas de correo | RFC 1035 |
MX | Intercambio de correo | RFC 1035 |
TXT | Cadenas de texto | RFC 1035 |
AAAA | Dirección IP6 | RFC 3596 |
SRV | Selección de servidores | RFC 2782] |
Cómo admite GSLB DNS
GSLB utiliza algoritmos y protocolos que deciden qué dirección IP debe enviarse para una consulta DNS. Los sitios GSLB se distribuyen geográficamente y hay un servidor de nombres autorizado de DNS en cada sitio que se ejecuta como servicio en el dispositivo NetScaler. Todos los servidores de nombres de los distintos sitios implicados tienen autoridad para el mismo dominio. Cada uno de los dominios GSLB es un subdominio para el que se configura una delegación. Por lo tanto, los servidores de nombres GSLB son autorizados y pueden utilizar uno de los diversos algoritmos de equilibrio de carga para decidir qué dirección IP devolver.
Se crea una delegación agregando un registro del servidor de nombres para el dominio GSLB en los archivos de base de datos de dominio principal y un registro de direcciones posterior para los servidores de nombres que se utilizan para la delegación. Por ejemplo, si quiere utilizar GSLB para www.citrix.com
, se puede utilizar el siguiente archivo SOA de enlace para delegar solicitudes en servidores de nombres: Netscaler1 y Netscaler2. www.citrix.com
###########################################################################
@ IN SOA citrix.com. hostmaster.citrix.com. (
1 ; serial
3h ; refresh
1h ; retry
1w ; expire
1h ) ; negative caching TTL
IN NS ns1
IN NS ns2
IN MX 10 mail
ns1 IN A 10.10.10.10
ns2 IN A 10.10.10.20
mail IN A 10.20.20.50
### Old Configuration if www was not delegated to a GSLB name server
www IN A 10.20.20.50
### Updated Configuration
Netscaler1 IN A xxx.xxx.xxx.xxx
Netscaler2 IN A yyy.yyy.yyy.yyy
www IN NS Netscaler1.citrix.com.
www IN NS Netscaler2.citrix.com.
###
IN MX 20 mail2
mail2 IN A 10.50.50.20
###########################################################################
<!--NeedCopy-->
Entender BIND no es un requisito para configurar DNS. Todas las implementaciones de servidores DNS compatibles tienen un método para crear la delegación equivalente. Los servidores DNS de Microsoft se pueden configurar para la delegación siguiendo las instrucciones de Crear una delegación de zona.
Lo que diferencia a GSLB en el dispositivo NetScaler del uso del servicio DNS estándar para distribuir el tráfico es que los sitios GSLB de NetScaler intercambian datos mediante un protocolo propietario denominado Metric Exchange Protocol (MEP). Con MEP, los sitios de la GSLB pueden mantener información sobre todos los demás sitios. Cuando se recibe una solicitud DNS, el MEP considera las métricas de GSLB para determinar información como la siguiente:
- Sitio con el menor número de conexiones actuales
- Sitio más cercano al servidor LDNS, que envió la solicitud en función de los tiempos de ida y vuelta (RTT).
Hay varios algoritmos de equilibrio de carga que se pueden utilizar, pero GSLB es un DNS con el cerebro debajo que indica al servidor de nombres (alojado en el dispositivo NetScaler) qué dirección debe enviarse según las métricas de los sitios participantes.
Otros beneficios que ofrece GSLB son la capacidad de mantener la persistencia (o afinidad del sitio). Las respuestas a las consultas DNS entrantes se pueden comparar con la dirección IP de origen para determinar si esa dirección se dirigió a un sitio concreto en el pasado reciente. Si es así, se envía la misma dirección en la respuesta DNS para garantizar que se mantenga la sesión del cliente.
Otra forma de persistencia se obtiene a nivel de sitio mediante redireccionamientos HTTP o proxying HTTP. Estas formas de persistencia ocurren después de que se produce la respuesta DNS. Por lo tanto, si recibe una solicitud HTTP en un sitio que contiene una cookie para dirigir la solicitud a otro sitio participante, puede responder con una redirección o enviar la solicitud al sitio correspondiente.
Protocolo de intercambio de métricas
Metric Exchange Protocol (MEP) se utiliza para compartir los datos utilizados en los cálculos de GSLB entre sitios. Mediante conexiones MEP, se intercambian tres tipos de datos. Estas conexiones no tienen por qué estar seguras a través del puerto TCP 3011 o pueden ser seguras mediante SSL a través del puerto TCP 3009.
Se intercambian los tres tipos de datos siguientes y tienen sus propios intervalos y métodos de intercambio.
-
Intercambio de métricas del sitio: Este es un modelo de intercambio de encuestas. Por ejemplo, si site1 tiene una configuración para los servicios site2, cada segundo sitio1 solicita al sitio2 el estado de los servicios GSLB. Site2 responde con el estado y otros detalles de carga.
-
Intercambio de métricas de red: Este es el intercambio de información RTT de LDNS, que se utiliza en el algoritmo de equilibrio de carga dinámico de proximidad. Este es un modelo de intercambio push. Cada cinco segundos, cada sitio envía sus datos a otros sitios participantes.
-
Intercambio de persistencia: es para el intercambio de persistencia SOURCEIP. Este es también un modelo de intercambio push. Cada cinco segundos, cada sitio envía sus datos a otros sitios participantes.
De forma predeterminada, los servicios del sitio se supervisan a través de MEP basándose únicamente en la información de las encuestas. Si vincula monitores en función del intervalo de monitor, el estado se actualiza y puede controlar la frecuencia de las actualizaciones estableciendo el intervalo de supervisión en consecuencia.
Compartir
Compartir
En este artículo
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.