Introducción
Las organizaciones a menudo requieren un cierto nivel de tiempo de actividad del sistema para sus implementaciones de ArcGIS Enterprise, como el 99 por ciento del tiempo o más. Para estas organizaciones, implementar una estrategia para garantizar alta disponibilidad es crucial.
Alta Disponibilidad (HA), aunque relacionada con Recuperación ante Desastres (DR), es un concepto separado. Generalmente, HA se enfoca en evitar el tiempo de inactividad para la entrega del servicio, mientras que DR se enfoca en conservar los datos y recursos necesarios para restaurar un sistema a un estado aceptable previo después de un desastre.
Esta publicación se centrará en las mejores prácticas para configurar un load balancer local (Local Traffic Manager, LTM) en una sola ubicación para alta disponibilidad, y no incluirá consideraciones para configurar Global Traffic Manager (GTM) para failover automático entre diferentes ubicaciones.
Para lograr alta disponibilidad, debe reducir los puntos únicos de falla mediante duplicación y balanceo de carga.
Los load balancers actúan como un proxy inverso y distribuyen el tráfico a los servidores back-end. Se requiere un load balancer de terceros en una implementación altamente disponible de ArcGIS Enterprise para mejorar la capacidad y confiabilidad del software. Manejan el tráfico cliente hacia su portal y sitios de servidor, así como el tráfico interno entre los componentes del software.
ArcGIS Web Adaptor
Aunque ArcGIS Web Adaptor se considera un load balancer, es insuficiente para servir como el único load balancer en una implementación altamente disponible, ya que ArcGIS Web Adaptor también requiere redundancia para lograr alta disponibilidad.
ArcGIS Web Adaptor es un componente opcional, ya que los load balancers pueden reenviar solicitudes directamente a sus sitios de portal y servidor, sin embargo, es un componente recomendado. Las ventajas de usar web adaptors son:
- Proporciona una forma fácil de configurar una URL única para el sistema
- Permite elegir nombres de contexto para los diferentes componentes del sistema, por ejemplo portal, server, mapping, etc.
- Está integrado nativamente con otros componentes del software ArcGIS Enterprise, los sitios de portal y servidor, y manejará automáticamente las comprobaciones de salud y tareas de configuración, por ejemplo agregar una nueva máquina a un sitio de servidor
URL de contexto web
La URL de contexto web es la URL pública para el portal. Dado que cualquier elemento en portal tiene una URL - archivo, capa, mapa y aplicación, la propiedad WebContextURL del portal ayuda a construir las URLs correctas en todos los recursos que envía al usuario final.
Acceso externo y DNS
El portal ArcGIS Enterprise soporta solo un DNS para la URL pública del portal (la URL de contexto web), y actualmente no hay una forma soportada para cambiar la URL de contexto web sin rehacer tareas administrativas, por ejemplo federar sitios de servidor con su portal. Si su ArcGIS Enterprise requiere acceso externo, por ejemplo para permitir acceso a usuarios móviles, contratistas, socios o agencias sin VPN, o si anticipa que necesitará permitir acceso externo en el futuro, debe usar un nombre DNS resoluble externamente para la URL de contexto web del portal, por ejemplo https://gis.company.com/portal.
Para asegurar el acceso externo a ArcGIS Enterprise, es común alojar un load balancer en una DMZ, e implementar un Sistema Dividido de Nombres de Dominio (Split DNS), es decir, el acceso interno al DNS de ArcGIS Enterprise (por ejemplo gis.company.com) se resolverá a una IP interna del load balancer, por lo que los usuarios internos permanecerán detrás del firewall, y el acceso externo al DNS de ArcGIS Enterprise se resolverá a una IP externa (DMZ) del load balancer.
URLs usadas en federación
Diversas URLs diferentes se usan en una implementación altamente disponible de ArcGIS Enterprise.
URL de servicios
Esta es la URL usada por usuarios y aplicaciones cliente para acceder a sitios ArcGIS Server. Es la URL del load balancer que maneja el tráfico de ArcGIS Server y pasa las solicitudes ya sea al Web Adaptor del sitio servidor o directamente a las máquinas servidoras.
URL administrativa
Esta URL es usada por administradores e internamente por el portal para acceder a un sitio ArcGIS Server cuando se realizan operaciones administrativas. Esta URL también se usa para publicar servicios GIS con referencia a una tienda de datos registrada, por ejemplo geodatabase empresarial SQL Server, hacia un sitio servidor federado. Esto debe apuntar a un load balancer; si la URL administrativa apunta a una sola máquina en el sitio servidor y esa máquina está fuera de línea, la federación no funcionará. Esto puede ser la misma URL que la URL de servicios o puede ser un segundo load balancer (VIP) para cada URL administrativa del sitio servidor federado vía puerto 6443. Configurar un VIP dedicado para cada URL administrativa del sitio servidor federado vía puerto 6443 requerirá abrir este puerto para administradores y publicadores, y puede deshabilitar el acceso administrativo a través del web adaptor, proporcionando así controles adicionales de seguridad para la organización.
Recomiendo usar la misma URL que la URL de servicios ya que simplifica la configuración. El acceso administrativo a ArcGIS Server será controlado por autenticación y roles de usuario en ArcGIS Enterprise, similar al acceso administrativo al portal, por ejemplo Directorio Portal ArcGIS (portaladmin) y Configuración Organizacional. Para usar la URL del web adaptor como URL administrativa debe habilitarse el acceso administrativo en el web adaptor del servidor.
URL privada del portal
Esta es una URL interna usada por sus sitios servidor para comunicarse con el portal. Esto también debe apuntar a un load balancer y debería definirse antes de federar. Si federó sus sitios servidor antes de establecer privatePortalURL, siga los pasos 8 y 9 en el tema Configure an existing deployment for alta disponibilidad para actualizar la URL dentro de su implementación. Similar a la URL administrativa, esta puede ser la misma que la URL pública para el portal (la URL del contexto web del portal), o puede ser un segundo balanceador de carga (VIP) a través del puerto 7443.
Para simplificar la configuración, recomendaría usar la URL pública para el portal como la URL privada del portal. Si elige usar un VIP dedicado del balanceador de carga a través del puerto 7443 para la URL privada del portal, debe configurar el balanceador de carga para verificar la salud de las máquinas del portal.
Configuración del Balanceador de Carga
Configuración de Verificación de Salud
La capacidad más importante para usar es una Verificación de Salud. Como se describe en la documentación de verificación de salud del portal:
“La verificación de salud informa si la máquina Portal for ArcGIS que responde puede recibir y procesar solicitudes. Por ejemplo, antes de crear el portal, la URL de verificación de salud informa que el sitio no está disponible porque no puede aceptar solicitudes en ese momento.”
El portal ArcGIS Enterprise y el servidor tienen verificaciones de salud.
Cuando usa ArcGIS Web Adaptors, los web adaptors se encargan de realizar las verificaciones de salud contra el portal y los servidores. En este caso, puede configurar el balanceador de carga con una verificación básica TCP/443 o una verificación de página estática, con configuraciones estándar para tiempo de espera, disparador de fallos, intervalo de sondeo y umbral saludable.
Si configura el balanceador de carga para acceder directamente al portal y/o a los servidores, por ejemplo, si no incluye web adaptors en su arquitectura, o si usa una URL dedicada del balanceador de carga para la URL privada del portal (puerto 7443) o la URL administrativa federada del servidor (puerto 6443), debe configurar el balanceador de carga para verificar la salud de las máquinas del portal y servidor.
Hay algunas consideraciones importantes sobre las configuraciones de verificación de salud en el balanceador de carga. La mayoría de las organizaciones que usan un balanceador de carga utilizan una página estática como su verificación de salud (por ejemplo, index.html) para determinar si el servidor web está saludable. Este es un archivo estático que solo requiere una lectura desde disco. Además, la mayoría de los servidores web tienden a tener cuellos de botella con I/O más que con CPU.
Sin embargo, ArcGIS Server es diferente en que nuestra verificación de salud requiere una pequeña cantidad de CPU porque nuestra comprobación es más que solo una lectura desde disco, ya que el software necesita determinar si ciertos procesos están funcionales.
Con las verificaciones de salud hay un valor de tiempo límite en el sondeo. La mayoría de los administradores del balanceador de carga establecen un valor bajo para el tiempo límite porque las lecturas desde disco suelen ser muy rápidas (aunque a menudo dejan algo de margen para latencia pobre en la red).
Al usar un valor bajo para el tiempo límite con ArcGIS Server y cuando se usa una configuración multinodo, existe la posibilidad que una máquina supere ese tiempo límite bajo y una máquina saludable sea removida.
Esri recomienda un valor más alto para el tiempo límite, idealmente al menos 5 segundos. Dependiendo del sistema, podría necesitar aumentar este valor aún más. Debe monitorear su entorno y ajustar este valor según corresponda. Esto puede parecer un número alto para los Administradores de Red ya que una verificación en una página simple normalmente toma menos de 10 ms (más latencia en red).
Sin embargo, es crítico para los balanceadores distinguir entre cuando una máquina está simplemente lenta vs. cuando una máquina está realmente muerta y no responde. Si el portal o servidor está realmente caído y no escucha en ningún puerto, la mayoría de los balanceadores detectarán esto incluso antes que pasen 5 segundos, por lo que este tiempo límite no afecta fallos "normales" donde una máquina desaparece.
La segunda consideración es el disparador de fallo - cuántas veces debe fallar el sondeo antes de remover la máquina del balanceador.
Como regla general, los Administradores de Red configuran el disparador a más de 1 fallo porque no quieren que un solo problema en la red derribe el sistema. Como se mencionó arriba, un pequeño pico en uso CPU (común en sistemas ArcGIS Server) puede causar un tiempo límite, y no es deseable sacar una máquina por un solo pico CPU en una sola máquina.
Esri ha realizado pruebas internas significativas con balanceadores y encontró que configurar 5 fallos reduce dramáticamente falsos positivos mientras sigue detectando fallos reales. Encontramos que un valor 3 aún era muy susceptible a falsos positivos.
La tercera consideración es el intervalo entre sondeos. Esri ha encontrado que intervalos cada 30 segundos junto con 5 fallos fue un punto óptimo para detectar fallos reales e ignorar falsos positivos.
Con esta combinación, el valor esperado (usando término estadístico) o tiempo medio hasta detección es 1 minuto y 15 segundos antes detectar caída, con peor caso 2 minutos y 30 segundos. Es posible buscar un tiempo medio menor hasta detección pero a costa recibir falsos positivos.
Si se prefiere un tiempo medio menor hasta detección puede ser necesario aumentar capacidad para tener recursos suficientes para tolerar un fallo real en una máquina y falsos positivos sin sobrecargar las máquinas restantes.
La configuración final respecto a verificaciones es el umbral saludable para que el balanceador comience a enviar solicitudes nuevamente. Esri no tiene recomendación específica aquí ni hemos observado muchas diferencias en este número, pero típicamente vemos 3 sondeos saludables consecutivos antes reincorporar.
Limitación
Las configuraciones para limitación valen la pena considerarlas. ArcGIS Server está limitado por CPU lo que significa que la mayor parte del tiempo en solicitudes se usa CPU más que esperar I/O.
Esto significa que si hay 8 núcleos, ArcGIS Server puede manejar poco más que 8 solicitudes simultáneas desde un punto práctico. Si ArcGIS Server está ocupado comienza a poner solicitudes en cola hasta cientos esperando, y después rechaza conexiones. Cuando hay mucha cola resulta en tiempos largos esperando pero eventualmente se procesa solicitud.
ArcGIS Server tiene configuraciones para controlar este comportamiento así hay menos solicitudes abandonadas siendo procesadas pero también es buena práctica controlar esto a nivel del balanceador vía su capacidad para limitar.
Esri no tiene recomendación numérica porque depende mucho arquitectura específica y tipos solicitudes entrantes pero típicamente se limita a valores significativamente menores que lo usualmente configurado por Admins Red para Servidor Web.
Esto escapa control Admin Red pero aplicaciones cliente deben estar diseñadas para manejar evento limitación e intentar reintentos con intervalos crecientes (ejemplo: primer intento reintento inmediato, segundo espera 1 segundo, tercer reintento espera 5 segundos etc.).
Sesiones Pegajosas
Esri no recomienda sesiones pegajosas salvo circunstancias muy raras. Las sesiones pegajosas teóricamente pueden sobrecargar una máquina. Esri ha realizado pruebas con sesiones pegajosas buscando resultados que sobrecarguen nuestro GIS Server y esto no ocurrió. Tampoco hemos recibido reclamos clientes. Dicho esto dado nuestro software es stateless no vemos valor usar sesiones pegajosas.
Capa 4 vs. Capa 7
La configuración final a mencionar es si el balanceador hace enfoque "nivel 7" o "capa 4". Esto puede ser debate entre Admins Red pero abajo resumen conciso describiendo diferencias y ventajas cada uno.
Un balanceador capa 7 entiende http y https por lo tanto descifra contenido https y luego vuelve a cifrar. Porque entiende http y https puede cachear contenido y ahorrar solicitudes al servidor backend.
Un balanceador capa 4 ve todo tráfico como paquetes TCP sin saber qué significan; podrían ser ftp, https, smtp pero esto no importa a capa 4. Como resultado no necesita entender payload http y puede ser más rápido.
ArcGIS Server puede trabajar con cualquiera enfoque sin recomendación específica para Admins Red pero hay información útil conocer.
Cargas útiles ArcGIS Server pueden ser mucho mayores que páginas HTML, CSS y JS (cantidad exacta útil pero depende datos cliente). Esto implica mayor carga CPU en balanceador capa 7 descifrando/cifrando por solicitud.
Además dado muchos datos ArcGIS Server son dinámicos y cambian frecuentemente por defecto encabezados cache prohíben cache cliente/balanceador. Si datos cambian poco y cliente quiere usar capa 7 pueden cambiar/controlar estas configuraciones cache.
Resumen Recomendaciones
Verificación Salud
- Si configura sus balanceadores con ArcGIS Web Adaptors puede configurar balanceador con verificación básica TCP/443 o página estática contra servidores web
- Si configura balanceador para acceder directamente al portal y/o servidores (vía puertos 6443 y 7443), use Punto de comprobación de salud HTTPS:<\/SPAN>Portal:<\/SPAN>Solicitud: <\/SPAN>https:\/\/\/\/portaladmin\/healthCheck?f=json
O<\/SPAN>
<\/SPAN>https:\/\/:7443\/arcgis\/portaladmin\/healthCheck?f=json<\/A><\/SPAN><\/LI>Respuesta: {"status":"success"}<\/SPAN><\/LI><\/UL><\/LI>Servidor:<\/SPAN>Solicitud: <\/SPAN>https:\/\/\/\/rest\/info\/healthCheck?f=json
O<\/SPAN>
<\/SPAN>https:\/\/:6443\/arcgis\/rest\/info\/healthCheck?f=json<\/A><\/SPAN><\/LI>Respuesta: {"success":true}<\/SPAN><\/LI><\/UL><\/LI>Use un valor de tiempo de espera para la comprobación de salud más alto, al menos 5 segundos<\/SPAN><\/LI>Use un valor de 5 para el disparador de fallo<\/SPAN><\/LI>Use intervalos de sondeo de 30 segundos<\/SPAN><\/LI>Use 3 sondeos consecutivos saludables antes de reincorporarse<\/SPAN><\/LI><\/UL><\/LI><\/UL>Tasa de limitación <\/SPAN><\/P>Use una configuración de limitación a un valor significativamente más bajo que los servidores web típicos<\/SPAN><\/LI><\/UL>Sesiones persistentes<\/SPAN><\/P>No use sesiones persistentes<\/SPAN><\/LI><\/UL>Certificados<\/SPAN><\/H1>Los componentes de ArcGIS Enterprise vienen preconfigurados con certificados de servidor autofirmados, lo que permite que el software se pruebe inicialmente y le ayude a verificar rápidamente que su instalación fue exitosa. Sin embargo, en casi todos los casos, una organización debe solicitar un certificado a una autoridad certificadora (CA) confiable y configurar el software para usarlo. El certificado puede ser firmado por una CA corporativa (interna) o comercial. Se debe usar una CA comercial (known-CA) para DNS resolvible externamente, por ejemplo, DNS VIP del balanceador de carga; los certificados de dominio interno pueden usarse para servidores internos. <\/SPAN>
Para sistemas ArcGIS Enterprise con DNS resolvible externamente, si el método SSL del balanceador de carga es SSL-passthrough (el balanceador de carga no descifra ni vuelve a cifrar contenido https), no requiere certificado, y un certificado CA comercial debe instalarse en los servidores mapeados (por ejemplo, servidores web donde están instalados los web adaptors). Si el método SSL del balanceador de carga es re-cifrado SSL, un certificado CA comercial debe instalarse en el balanceador de carga.<\/SPAN><\/SPAN><\/P>
.png)
