|
|||||||
|
|||||||
|
|
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 a la que apuntarán los usuarios o las aplicaciones 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 CAD
|
|
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 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 proporcione 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 - Denota que el servidor está activo y recibiendo 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 acceso en el Real Server. Cuando se utiliza un proxy inverso, éste 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
|
El clúster es el papel por defecto del ADC en la instalación, y la columna Principal/Modo indicará el modo en el que se está ejecutando actualmente. Cuando tenga un par de ADC 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. Como tal, 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 una comprobación del monitor de salud o haya sido cambiado manualmente a Desconectado. 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
|
|
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 según 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
|
!!!
|
|
|
|
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 cuando se equilibra la carga de los sistemas que utilizan 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
|
RPC estático de Exchange 2010 para el acceso de los clientes y las 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 el 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 de forma natural, 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 será recibido por el grupo en espera según la política de equilibrio de carga cuando esto ocurra. Si un servidor del grupo Online pasa la comprobación del Monitor de Salud del Servidor, este servidor Online recibirá todo el tráfico, y el grupo Standby dejará de recibir tráfico.
|
|
Opción
|
Descripción
|
|
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 introducción 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 necesita equilibrar la carga en función de la carga de la aplicación o del servidor, o incluso asegurarse de que utiliza el mismo servidor para la sesión, el método Round Robin es inadecuado.
|
|
Conexiones mínimas
|
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 posterior.
|
|
Afinidad/Persistencia de la Sesión de Capa 3 - Vinculado a IP
|
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 las redes internas en las que se conoce la topología de la red y se puede confiar en que no hay "superproxies" aguas arriba. Con la capa 4 y los proxies, todas las peticiones pueden parecer que proceden de un solo cliente y, por tanto, 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.
|
|
Afinidad/Persistencia de la Sesión de Capa 3 - Basada en la lista de IP
|
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 cambiarse mediante un jetPACK.
|
|
Capa 7 Afinidad/Persistencia de la sesión - Cookie de sesión
|
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 enrutar 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.
|
|
Capa 7 Afinidad/Persistencia de la sesión - Cookie persistente
|
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 se equilibrará en carga según un algoritmo basado en la lista de IP. Este tiempo de expiración es configurable mediante un jetPACK.
|
|
Cookie de sesión - Cookie de sesión ASP clásica
|
Las páginas activas del servidor (ASP) son 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 de 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 y basada en el nombre de usuario/dominio para proporcionar persistencia a un servidor. La ventaja de este método es que el mantenimiento de la conexión a un servidor es posible incluso si la dirección IP del cliente cambia.
|
|
Basado en cookies
|
Un nuevo método muy parecido a "PhpCookieBased" y otros métodos de equilibrio de carga, pero utilizando 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 existe un valor de anulación en la configuración de los ajustes avanzados del servidor virtual, utilícelo en su lugar. NOTA: Si se establece este valor, sobrescribimos la expresión de la cookie anterior para sustituir h= por el nuevo valor.
La última parte es que si llega un valor de cookie desconocido y coincide con uno de los ID del servidor real, debe seleccionar ese servidor; de lo contrario, utilice el siguiente método (delegado.)
|
|
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 trastorna 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 del H/A. Utilice este método de monitorización con cualquier tipo de servicio.
|
|
Eco Ping/ICMP
|
En este modo, el CAD envía una solicitud de eco ICMP a la IP del servidor de contenidos. Si se recibe una respuesta 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
|
En este modo, se establece una conexión TCP con el Servidor Real y se interrumpe inmediatamente sin enviar ningún dato. Si la conexión tiene éxito, el CAD considera que el Servidor Real está en funcionamiento. Este método de monitorización se puede utilizar con cualquier tipo de servicio. Los servicios UDP son los únicos que actualmente no son 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 necesite 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 se confirma la conexión, el ADC considera que el Servidor Real 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 CAD envía al Servidor Real una solicitud HTTP. Se espera una respuesta HTTP y se comprueba el código de respuesta "200 OK". Si se recibe el código de respuesta "200 OK", el CAD considera que el Servidor Real está en funcionamiento. 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 un tipo de servicio de capa 4 está en uso para un servidor HTTP, es utilizable si SSL no está en uso en el Servidor Real o es manejado apropiadamente por la facilidad "Content SSL".
|
|
DICOM
|
Una conexión TCP se inicializa con el Servidor Real en modo DICOM, y se realiza una "Solicitud de Asociación" de Echoscu al Servidor Real 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, por cualquier motivo, el monitor no concluye con éxito, se considera que el Servidor Real no funciona.
|
|
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á un 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
|
|
Off
|
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á encriptado.
|
|
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 desde el CAD 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 CAD actúa como cliente y aceptará cualquier certificado que el Servidor Real presente. 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 CAD actúa como cliente y aceptará cualquier certificado que el Servidor Real presente. 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 habilitar 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
|
El Proxy Inverso es el valor por defecto y funciona en la Capa7 con compresión y caché. Y en la Capa4 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 equilibrador de carga responda directamente al cliente saltándose el ADC en la respuesta. DSR sólo es adecuado para su uso con el equilibrador 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.
El equilibrio de carga de capa 7 no funciona con este DSR. Además, no hay soporte de persistencia que no sea el basado en la lista de IP. El equilibrio 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 el tráfico de los Servidores Reales sea enrutado 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 puerta de enlace para los Servidores Reales es ideal cuando se ejecuta en modo multi-interfaz.
El equilibrio 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 Servidor Real establezca su puerta de enlace por defecto en la dirección de la interfaz local (eth0, eth1, etc.) del CAD. 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.
|
