|
|||||||
|
|||||||
|
|
Campo
|
Descripción
|
|
Dirección IP
|
Introduzca una nueva dirección IP virtual para que sea el punto de entrada de destino para acceder al Servidor Real. Esta IP es donde los usuarios o las aplicaciones apuntarán para acceder a la aplicación con equilibrio de carga.
|
|
Máscara/Prefijo de subred
|
Este campo es para la máscara de subred correspondiente a la red en la que se encuentra el ADC
|
|
Puerto
|
El puerto de entrada utilizado cuando se accede al VIP. Este valor no tiene que ser necesariamente el mismo que el del Servidor Real si se utiliza el Proxy Inverso.
|
|
Nombre del servicio
|
El nombre del servicio es una representación textual del propósito del VIP. Es opcional, pero le recomendamos que lo indique para mayor claridad.
|
|
Tipo de servicio
|
Hay muchos tipos de servicio disponibles para que usted los seleccione. Los tipos de servicio de capa 4 no pueden utilizar la tecnología flightPATH.
|
|
Campo
|
Descripción
|
|
Actividad
|
El campo Actividad puede utilizarse para mostrar y cambiar el estado del servidor real con equilibrio de carga.
En línea - Indica que el servidor está activo y recibe peticiones de carga equilibrada
Fuera de línea - El servidor está fuera de línea y no recibe peticiones
Drenaje - El servidor se ha colocado en modo de drenaje para que la persistencia se pueda vaciar y el servidor pase a un estado fuera de línea sin afectar a los usuarios.
Standby - El servidor ha sido puesto en estado de espera
|
|
Dirección IP
|
Este valor es la dirección IP del Servidor Real. Debe ser precisa y no debe ser una dirección DHCP.
|
|
Puerto
|
El puerto de destino de acceso en el Real Server. Si se utiliza un proxy inverso, puede ser diferente del puerto de entrada especificado en el VIP.
|
|
Ponderación
|
Este ajuste suele ser configurado automáticamente por el CAD. Puede modificarlo si desea cambiar la ponderación de la prioridad.
|
|
Opción
|
Descripción
|
|
Cluster
|
Cluster es el rol por defecto del ADC en la instalación, y la columna Primary/Mode indicará el modo en el que se está ejecutando actualmente. Cuando tenga un par de ADCs en HA en su centro de datos, uno de ellos mostrará Activo y el otro Pasivo
|
|
Manual
|
El rol Manual permite que el par ADC funcione en modo Activo-Activo para diferentes direcciones IP Virtuales. En estos casos, la columna Primaria contendrá una casilla junto a cada IP virtual única que se puede marcar para Activo o dejar sin marcar para Pasivo.
|
|
Stand-Alone
|
El ADC está actuando como dispositivo autónomo y no está en modo de Alta Disponibilidad. Por lo tanto, la columna Primaria indicará Stand-alone.
|
|
LED
|
Significado
|
|
l
|
En línea
|
|
l
|
Failover-Standby. Este servicio virtual es hot-standby
|
|
l
|
Indica que un "secundario" está esperando a un "primario".
|
|
l
|
El servicio necesita atención. Esta indicación puede ser el resultado de que un Servidor Real haya fallado en la comprobación del monitor de salud o haya sido cambiado manualmente a Offline. El tráfico seguirá fluyendo pero con una capacidad reducida del Servidor Real
|
|
l
|
Fuera de línea. Los servidores de contenido son inalcanzables, o no hay servidores de contenido habilitados
|
|
l
|
Encontrar el estado de las cosas
|
|
l
|
IPs virtuales no licenciadas o excedidas
|
|
Tipo de servicio
|
Puerto/Protocolo
|
Capa de servicio
|
Comentario
|
|
TCP de capa 4
|
Cualquier puerto TCP
|
Capa 4
|
El ADC no alterará ninguna información en el flujo de datos y realizará un equilibrio de carga estándar del tráfico de acuerdo con la política de equilibrio de carga
|
|
UDP de capa 4
|
Cualquier puerto UDP
|
Capa 4
|
Al igual que con el TCP de capa 4, el ADC no alterará ninguna información en el flujo de datos y realizará un equilibrio de carga estándar del tráfico de acuerdo con la política de equilibrio de carga
|
|
Capa 4 TCP/UDP
|
Cualquier puerto TCP o UDP
|
Capa 4
|
Es ideal si su servicio tiene un protocolo primario como el UDP, pero se retrocederá a TCP. El ADC no alterará ninguna información en el flujo de datos y realizará un equilibrio de carga estándar del tráfico de acuerdo con la política de equilibrio de carga
|
|
DNS
|
TCP/UDP
|
Capa 4
|
Se utiliza para equilibrar la carga de los servidores DNS.
|
|
HTTP
|
Protocolo HTTP o HTTPS
|
Capa 7
|
El CAD puede interactuar, manipular y modificar el flujo de datos utilizando flightPATH.
|
|
FTP
|
Protocolo de transferencia de archivos
|
Capa 7
|
Utilizar conexiones de control y de datos separadas entre el cliente y el servidor
|
|
SMTP
|
Protocolo simple de transferencia de correo
|
Capa 4
|
Utilizar cuando se equilibra la carga de los servidores de correo
|
|
POP3
|
Protocolo de la Oficina de Correos
|
Capa 4
|
Utilizar cuando se equilibra la carga de los servidores de correo
|
|
IMAP
|
Protocolo de acceso a mensajes de Internet
|
Capa 4
|
Utilizar cuando se equilibra la carga de los servidores de correo
|
|
RDP
|
Protocolo de escritorio remoto
|
Capa 4
|
Utilizar cuando se equilibra la carga de los servidores de Terminal Services
|
|
RPC
|
Llamada a procedimiento remoto
|
Capa 4
|
Utilizar al equilibrar la carga de los sistemas mediante llamadas RPC
|
|
RPC/ADS
|
RPC estática de Exchange 2010 para el servicio de libreta de direcciones
|
Capa 4
|
Utilizar cuando se equilibra la carga de los servidores Exchange
|
|
RPC/CA/PF
|
Exchange 2010 RPC estático para el acceso de clientes y carpetas públicas
|
Capa 4
|
Utilizar cuando se equilibra la carga de los servidores Exchange
|
|
DICOM
|
Imagen digital y comunicaciones en medicina
|
Capa 4
|
Se utiliza cuando se equilibra la carga de los servidores que utilizan protocolos DICOM
|
|
LED
|
Significado
|
|
l
|
Conectado
|
|
£
|
No se controla
|
|
l
|
Drenaje
|
|
l
|
Fuera de línea
|
|
l
|
Standby
|
|
l
|
No conectado
|
|
l
|
Estado de los hallazgos
|
|
l
|
Servidores reales sin licencia o con licencia superada
|
|
Opción
|
Descripción
|
|
En línea
|
Todos los Servidores Reales asignados en línea recibirán tráfico de acuerdo con la política de equilibrio de carga establecida en la pestaña Básica.
|
|
Drenaje
|
Todos los Servidores Reales asignados como Drenaje continuarán sirviendo a las conexiones existentes pero no aceptarán ninguna conexión nueva. La luz de estado parpadeará en verde/azul mientras el drenaje esté en proceso. Una vez que las conexiones existentes se hayan cerrado naturalmente, los Servidores Reales se desconectarán, y la luz de Estado será de color azul sólido. También puede ver estas conexiones navegando a la sección Navegación > Monitor > Estado.
|
|
Fuera de línea
|
Todos los Servidores Reales configurados como Desconectados serán inmediatamente desconectados y no recibirán ningún tráfico.
|
|
Standby
|
Todos los Servidores Reales configurados como Standby permanecerán desconectados hasta que TODOS los servidores del grupo Online fallen en sus comprobaciones de Server Health Monitor. El tráfico es recibido por el grupo en espera según la política de equilibrio de carga cuando esto sucede. Si un servidor del grupo Online pasa la comprobación de Server Health Monitor, este servidor Online recibirá todo el tráfico, y el grupo Standby dejará de recibir tráfico.
|
|
Opción
|
Descripción
|
|
El más rápido
|
La política de equilibrio de carga más rápida calcula automáticamente el tiempo de respuesta de todas las solicitudes por servidor suavizado en el tiempo. La columna Peso calculado contiene el valor calculado automáticamente. La entrada manual sólo es posible cuando se utiliza esta política de equilibrio de carga.
|
|
Round Robin
|
El Round Robin se utiliza habitualmente en los cortafuegos y en los equilibradores de carga básicos y es el método más sencillo. Cada servidor real recibe una nueva petición en secuencia. Este método sólo es adecuado cuando se necesita equilibrar la carga de las peticiones a los servidores de manera uniforme; un ejemplo serían los servidores web de búsqueda. Sin embargo, cuando se necesita equilibrar la carga en función de la carga de la aplicación o del servidor, o incluso asegurarse de que se utiliza el mismo servidor para la sesión, el método Round Robin es inapropiado.
|
|
Menos Conexiones
|
El equilibrador de carga llevará la cuenta del número de conexiones actuales a cada Servidor Real. El Servidor Real con la menor cantidad de conexiones recibe la nueva solicitud subsiguiente.
|
|
IP Bound
Afinidad/Persistencia de la Sesión de Capa 3
|
En este modo, la dirección IP del cliente constituye la base para seleccionar qué Servidor Real recibirá la solicitud. Esta acción proporciona persistencia. Los protocolos HTTP y de capa 4 pueden utilizar este modo. Este método es útil para redes internas en las que se conoce la topología de la red, y se puede confiar en que no hay "superproxies" en la parte superior. Con la Capa 4 y los proxies, todas las peticiones pueden parecer como si vinieran de un solo cliente, y como tal, la carga no sería uniforme. Con HTTP, la información de la cabecera (X-Forwarder-For) se utiliza cuando está presente para hacer frente a los proxies.
|
|
Basado en la lista IP
Afinidad/Persistencia de la Sesión de Capa 3
|
La conexión con el Servidor Real se inicia utilizando "Conexiones mínimas" entonces, la afinidad de la sesión se logra en base a la dirección IP del cliente. Se mantiene una lista durante 2 horas por defecto, pero esto puede ser cambiado usando un jetPACK.
|
|
Cookie de sesión
Afinidad/Persistencia de la Sesión de la Capa 7
|
Este modo es el método de persistencia más popular para el equilibrio de carga HTTP. En este modo, el ADC utiliza el equilibrio de carga basado en listas de IP para cada primera solicitud. Inserta una cookie en las cabeceras de la primera respuesta HTTP. Después, el ADC utiliza la cookie del cliente para dirigir el tráfico al mismo servidor back-end. Esta cookie se utiliza para la persistencia cuando el cliente necesita ir al mismo servidor back-end cada vez. La cookie expira una vez que se cierra la sesión.
|
|
Cookie persistente
Afinidad/Persistencia de la Sesión de la Capa 7
|
El modo de equilibrio de carga basado en la lista IP se utiliza para cada primera solicitud. El ADC inserta una cookie en las cabeceras de la primera respuesta HTTP. Después, el ADC utiliza la cookie del cliente para dirigir el tráfico al mismo servidor back-end. Esta cookie se utiliza para la persistencia cuando el cliente debe ir al mismo servidor back-end cada vez. La cookie expirará después de 2 horas, y la conexión será balanceada de acuerdo a un algoritmo basado en una lista de IPs. Este tiempo de expiración es configurable usando un jetPACK.
|
|
Cookie de sesión - Cookie de sesión ASP clásica
|
Active Server Pages (ASP) es una tecnología del lado del servidor de Microsoft. Con esta opción seleccionada, el ADC mantendrá la persistencia de la sesión en el mismo servidor si se detecta una cookie ASP y se encuentra en su lista de cookies conocidas. Al detectar una nueva cookie ASP, se equilibrará la carga utilizando el algoritmo de conexiones mínimas.
|
|
Cookie de sesión - Cookie de sesión ASP.NET
|
Este modo se aplica a ASP.net. Con este modo seleccionado, el ADC mantendrá la persistencia de la sesión en el mismo servidor si se detecta una cookie ASP.NET y se encuentra en su lista de cookies conocidas. Al detectar una nueva cookie ASP, se equilibrará la carga utilizando el algoritmo de conexiones mínimas.
|
|
Cookie de sesión - Cookie de sesión JSP
|
Java Server Pages (JSP) es una tecnología del lado del servidor de Oracle. Con este modo seleccionado, el ADC mantendrá la persistencia de la sesión en el mismo servidor si se detecta una cookie JSP y se encuentra en su lista de cookies conocidas. Al detectar una nueva cookie JSP, se equilibrará la carga utilizando el algoritmo de conexiones mínimas.
|
|
Cookie de sesión - Cookie de sesión JAX-WS
|
Los servicios web de Java (JAX-WS) son una tecnología del lado del servidor de Oracle. Con este modo seleccionado, el ADC mantendrá la persistencia de la sesión en el mismo servidor si se detecta una cookie JAX-WS y se encuentra en su lista de cookies conocidas. Al detectar una nueva cookie JAX-WS, se equilibrará la carga utilizando el algoritmo de conexiones mínimas.
|
|
Cookie de sesión - Cookie de sesión PHP
|
La página personal (PHP) es una tecnología del lado del servidor de código abierto. Con este modo seleccionado, el CAD mantendrá la persistencia de la sesión en el mismo servidor cuando se detecte una cookie de PHP.
|
|
Cookie de sesión - Persistencia de la cookie RDP
|
Este método de equilibrio de carga utiliza la cookie RDP creada por Microsoft basada en el nombre de usuario/dominio para proporcionar persistencia a un servidor. La ventaja de este método es que permite mantener la conexión con un servidor incluso si la dirección IP del cliente cambia.
|
|
Basado en cookies-ID
|
Un nuevo método muy parecido a "PhpCookieBased" y otros métodos de balanceo de carga, pero usando CookieIDBased y cookie RegEx h=[^;]+
Este método utilizará el valor establecido en el campo de notas del servidor real "ID=X;" como valor de la cookie para identificar el servidor. Esto, por lo tanto, significa que es una metodología similar a CookieListBased pero utiliza un nombre de cookie diferente y almacena un valor de cookie único, no la IP codificada, sino el ID del Servidor Real (leído en el momento de la carga.)
El valor por defecto es CookieIDName="h"; sin embargo, si hay un valor de anulación en la configuración de los ajustes avanzados del servidor virtual, utilícelo en su lugar. NOTA: Sobrescribimos la expresión de la cookie anterior para reemplazar h= con el nuevo valor si este valor está establecido.
La última parte es que si llega un valor de cookie desconocido y coincide con uno de los ID de servidor real, debería seleccionar ese servidor; de lo contrario, utilice el siguiente método (delegado.)
|
|
Basado en la lista de IPs compartidas
|
Este tipo de servicio sólo está disponible cuando el Modo de Conectividad está configurado como Pasarela o Retorno Directo al Servidor. Se ha añadido principalmente para dar soporte al equilibrio de carga de VMware.
|
|
Opción
|
Descripción
|
|
Ninguno
|
En este modo, el Servidor Real no se monitoriza y siempre está funcionando correctamente. El ajuste Ninguno es útil para situaciones en las que la monitorización perturba un servidor y para servicios que no deben unirse a la acción de conmutación por error del ADC. Es una vía para alojar sistemas poco fiables o heredados que no son primarios para las operaciones de H/A. Utilice este método de supervisión con cualquier tipo de servicio.
|
|
Eco Ping/ICMP
|
En este modo, el ADC envía una solicitud de eco ICMP a la IP del servidor de contenidos. Si se recibe una respuesta de eco válida, el ADC considera que el servidor real está en funcionamiento y el tráfico hacia el servidor continúa. También mantendrá el servicio disponible en un par H/A. Este método de monitorización se puede utilizar con cualquier tipo de servicio.
|
|
Conexión TCP
|
Se establece una conexión TCP con el Servidor Real y se interrumpe inmediatamente sin enviar ningún dato en este modo. Si la conexión tiene éxito, el ADC considera que el Servidor Real está en funcionamiento. Este método de monitorización se puede utilizar con cualquier tipo de servicio, y los servicios UDP no son actualmente apropiados para la monitorización de la conexión TCP.
|
|
ICMP inalcanzable
|
El ADC enviará una comprobación de salud UDP al servidor y marcará el Servidor Real como no disponible si recibe un mensaje ICMP de puerto inalcanzable. Este método puede ser útil cuando se necesita comprobar si un puerto de servicio UDP está disponible en un servidor, como el puerto DNS 53.
|
|
RDP
|
En este modo, una conexión TCP se inicializa como se explica en el método ICMP Unreachable. Después de que la conexión se inicialice, se solicita una conexión RDP de capa 7. Si el enlace se confirma, el ADC considera que el Real Server está en funcionamiento. Este método de monitorización se puede utilizar con cualquier servidor de terminales de Microsoft.
|
|
200 OK
|
En este método, se inicializa una conexión TCP con el Servidor Real. Una vez que la conexión tiene éxito, el ADC envía al Servidor Real una solicitud HTTP. Se espera una respuesta HTTP y se comprueba el código de respuesta "200 OK". El CAD considera que el Servidor Real está en funcionamiento si se recibe el código de respuesta "200 OK". Si el CAD no recibe un código de respuesta "200 OK" por cualquier motivo, incluidos los tiempos de espera, los fallos de conexión y otras razones, el CAD marca el Servidor Real como no disponible. Este método de monitorización sólo es válido para su uso con los tipos de servicio HTTP y HTTP acelerado. Si se utiliza un tipo de servicio de capa 4 para un servidor HTTP, se puede utilizar si SSL no está en uso en el Servidor Real o se gestiona adecuadamente mediante la función "Content SSL".
|
|
DICOM
|
Una conexión TCP se inicializa con el Real Server en modo DICOM, y se realiza una "Solicitud de Asociación" de Echoscu al Real Server en la conexión. Una conversación que incluye una "Associate Accept" del servidor de contenidos, una transferencia de una pequeña cantidad de datos seguida de una "Release Request", y luego una "Release Response" concluye con éxito el monitor. Si la monitorización no se completa con éxito, se considera que el Servidor Real está fuera de servicio por cualquier motivo.
|
|
Definido por el usuario
|
Cualquier monitor configurado en la sección de Monitorización del Servidor Real aparecerá en la lista.
|
|
Opción
|
Descripción
|
|
Por el anfitrión
|
El almacenamiento en caché por host se basa en la aplicación por nombre de host. Existirá una caché separada para cada dominio/nombre de host. Este modo es ideal para los servidores web que pueden servir varios sitios web en función del dominio.
|
|
Por Servicio Virtual
|
El almacenamiento en caché por servicio virtual está disponible cuando se elige esta opción. Sólo existirá una Caché para todos los dominios/hostnames que pasen por el servicio virtual. Esta opción es una configuración especializada para su uso con múltiples clones de un mismo sitio.
|
|
Opción
|
Descripción
|
|
Fuera de
|
Desactivar la compresión para el Servicio Virtual
|
|
Compresión
|
Cuando se selecciona, esta opción activa la compresión para el Servicio Virtual seleccionado. El CAD comprime dinámicamente el flujo de datos al cliente cuando lo solicita. Este proceso sólo se aplica a los objetos que contienen la cabecera content-encoding: gzip. Algunos ejemplos de contenido son HTML, CSS o Javascript. También puede excluir ciertos tipos de contenido utilizando la sección de Exclusiones Globales.
|
|
Opción
|
Descripción
|
|
Sin SSL
|
El tráfico de la fuente al ADC no está cifrado.
|
|
Todo
|
Carga todos los certificados disponibles para su uso
|
|
Por defecto
|
Esta opción hace que se aplique un certificado creado localmente llamado "Default" al lado del navegador del canal. Utilice esta opción para probar el SSL cuando no se haya creado o importado uno.
|
|
AnyUseCert
|
Utilizar cualquier certificado presente en el CAD que el usuario haya cargado o generado
|
|
Opción
|
Descripción
|
|
Sin SSL
|
El tráfico del ADC al Servidor Real no está encriptado. La selección de un certificado en el lado del navegador significa que "No SSL" puede ser elegido en el lado del cliente para proporcionar lo que se conoce como "SSL Offload".
|
|
Cualquier
|
El ADC actúa como cliente y aceptará cualquier certificado que presente el Servidor Real. El tráfico del ADC al Servidor Real se encripta cuando se selecciona esta opción. Utilice la opción "Cualquiera" cuando se especifique un certificado en el lado del Servicio Virtual, proporcionando lo que se conoce como "Puente SSL" o "Reencriptación SSL".
|
|
SNI
|
El ADC actúa como cliente y aceptará cualquier certificado que presente el Servidor Real. El tráfico del ADC al Servidor Real se encripta si se selecciona esta opción. Utilice la opción "Cualquiera" cuando se especifique un certificado en el lado del Servicio Virtual, proporcionando lo que se conoce como "Puente SSL" o "Reencriptación SSL". Elija esta opción para activar el SNI en el lado del servidor.
|
|
AnyUseCert
|
Aquí aparecen los certificados que haya generado o importado en el CAD.
|
|
Opción
|
Descripción
|
|
Proxy inverso
|
Reverse Proxy es el valor por defecto y funciona en Layer7 con compresión y caché. Y en Layer4 sin caché ni compresión. En este modo, su ADC actúa como proxy inverso y se convierte en la dirección de origen que ven los servidores reales.
|
|
Retorno directo del servidor
|
El Retorno Directo al Servidor o DSR como es ampliamente conocido (DR - Enrutamiento Directo en algunos círculos) permite que el servidor detrás del balanceador de carga responda directamente al cliente evitando el ADC en la respuesta. DSR sólo es adecuado para su uso con el balanceo de carga de capa 4. Por lo tanto, el almacenamiento en caché y la compresión no están disponibles con esta opción elegida.
Este modo sólo puede utilizarse con los tipos de servicio TCP, UDP y TCP/UDP.
El equilibrio de carga de capa 7 no funciona con este DSR. Además, no hay soporte de persistencia que no sea basado en la lista de IP. El balanceo de carga SSL/TLS con este método no es ideal ya que el soporte de persistencia de IP de origen es el único tipo disponible. El DSR también requiere que se realicen cambios en el Servidor Real. Por favor, consulte la sección de Cambios en el Servidor Real.
|
|
Puerta de enlace
|
El modo de puerta de enlace le permite enrutar todo el tráfico a través del ADC, permitiendo que los Servidores Reales sean enrutados a través del ADC a otras redes mediante las máquinas virtuales del ADC o las interfaces de hardware. El uso del dispositivo como dispositivo de puerta de enlace para los Servidores Reales es ideal cuando se ejecuta en modo multi-interfaz.
El balanceo de carga de la capa 7 con este método no funciona ya que no hay soporte de persistencia más que el basado en la lista IP. Este método requiere que el Real Server establezca su puerta de enlace por defecto a la dirección de la interfaz local del CAD (eth0, eth1, etc.). Por favor, consulte la sección de Cambios del Servidor Real.
Tenga en cuenta que el modo Gateway no admite la conmutación por error en un entorno de clúster.
|
