Despliegues globales
Las implantaciones de GO-Global a gran escala suelen ir mucho más allá de los Farm Hosts y los Farm Managers. En los entornos empresariales, suelen funcionar junto con numerosos sistemas de soporte diseñados para mejorar el rendimiento, la fiabilidad y la seguridad. Estos sistemas, incluidos cortafuegos, equilibradores de carga, cortafuegos de aplicaciones web (WAF), proxies inversos y herramientas de supervisión, garantizan que las aplicaciones GO-Global sigan siendo accesibles, resistentes y conformes con las normas de la organización.
Este artículo proporciona una guía detallada sobre la configuración de GO-Global para funcionar eficazmente dentro de infraestructuras de TI complejas que incluyen dichos componentes. Explica cómo GO-Global interactúa con cada sistema, describe las mejores prácticas de configuración y destaca las consideraciones clave para los administradores que gestionan implementaciones a gran escala o basadas en la nube.
Cortafuegos perimetral
Cuando un despliegue GO-Global es accesible desde Internet, un cortafuegos perimetral es generalmente la primera línea de defensa contra intrusiones. Los cortafuegos perimetrales suelen estar configurados para permitir conexiones entrantes en el puerto TCP 443, que es el puerto estándar para el tráfico HTTPS/TLS seguro.
Dado que el puerto 443 es el puerto estándar para el tráfico seguro, y dado que es el puerto que está abierto en la mayoría de los cortafuegos corporativos (cliente), los clientes de GO-Global que se conectan a través de Internet suelen configurarse para conectarse al puerto 443 en lugar del puerto estándar de GO-Global, 491. Esto se hace añadiendo el puerto en la URL (por ejemplo, &port=443) o especificando el puerto en la página de inicio de sesión GO-Global.html. Esto se hace añadiendo el puerto en la URL (por ejemplo, &port=443) o especificando el puerto en la página logon.html de GO-Global.
Cortafuegos de aplicaciones web (WAF)
Un cortafuegos de aplicaciones web (WAF) analiza las peticiones HTTP entrantes para identificar y bloquear las peticiones maliciosas. Los WAF también pueden dirigir el tráfico a diferentes servidores backend basándose en la información de las peticiones HTTP, pero esta no es su función principal. Su función principal es proporcionar seguridad y protección contra ataques como los ataques distribuidos de denegación de servicio (DDoS).
Algunos ejemplos de WAF son Cloudflare WAF, AWS WAF (Amazon Web Services), Azure Web Application Firewall, F5 Advanced WAF, Imperva WAF, Akamai Kona Site Defender, Fortinet FortiWeb, Barracuda WAF y Radware WAF.
Para analizar el tráfico HTTPS, los WAF deben terminar el TLS para poder descifrar las solicitudes. Cuando un WAF termina TLS, el parámetrotls de GO-Global debe añadirse a la URL del cliente o debe especificarse en la página logon.html de GO-Global.
Otra consideración para el tráfico GO-Global es que los WAF no pueden analizar el protocolo RXP propietario de GO-Global. Por lo tanto, cuando la comunicación entre un cliente GO-Global y un host pasa a través de un WAF, debe envolverse en solicitudes HTTP configurando GO-Global para que utilice un Websocket, o las funciones de análisis de datos del WAF deben deshabilitarse para el tráfico GO-Global.
Todos los clientes GO-Global de la versión 6.3.3 y posteriores admiten WebSockets. Sin embargo, en las versiones 6.3.2 y anteriores de GO-Global, sólo la aplicación Web de GO-Global admite WebSockets. AppController, el cliente nativo de GO-Global, no soporta WebSockets en la versión 6.3.2 y anteriores.
Si AppController versión 6.3.2 o anterior se utiliza con un WAF, el entorno debe configurarse para que el WAF no inspeccione el tráfico de AppController. Esto se puede hacer, por ejemplo, proporcionando otro punto final (dirección pública) para las conexiones de AppController que no utilizan el WAF, o configurando AppController para que se conecte en un puerto diferente y configurando el WAF para que pase el tráfico en este puerto sin inspeccionarlo.
Proxy inverso
Al igual que los WAF, los proxies inversos analizan las peticiones HTTP entrantes. Los proxies inversos tienen algunas características de seguridad, pero a diferencia de los WAF, la función principal de los proxies inversos es la gestión del tráfico, no la seguridad. Por ejemplo, los proxies inversos se utilizan a menudo cuando se proporcionan múltiples aplicaciones y servicios web desde el mismo punto final público. Enrutan las peticiones entrantes de diferentes aplicaciones a sus respectivos servidores de aplicaciones. También pueden utilizarse como equilibradores de carga para hosts de granjas GO-Global.
Algunos ejemplos de proxies inversos son Nginx, Apache HTTP Server, HAProxy, Traefik y Cloudflare. AWS Application Load Balancer y Azure Application Gateway tienen varias funciones, una de las cuales incluye servir como proxy inverso.
Al igual que los WAFs, los proxies inversos deben terminar el TLS para poder analizar las peticiones HTTP entrantes. Como con los WAFs, cuando TLS es terminado por un proxy inverso, el parámetrotls de GO-Global debe ser añadido a la URL del cliente o debe ser especificado en la página logon.html de GO-Global.
Al igual que los WAF, los proxies inversos no pueden analizar el protocolo RapidX (RXP) propiedad de GO-Global. Por lo tanto, al igual que con un WAF, cuando la comunicación entre un cliente y un host GO-Global pasa a través de un proxy inverso, debe envolverse en solicitudes HTTP configurando GO-Global para que utilice un WebSocket, o las funciones de análisis de datos del proxy inverso deben desactivarse para el tráfico GO-Global.
Y al igual que con un WAF, si AppController versión 6.3.2 o anterior se utiliza con un proxy inverso, el entorno debe configurarse para que el WAF no inspeccione el tráfico de AppController. Esto se puede hacer, por ejemplo, proporcionando otro punto final (dirección pública) para las conexiones de AppController que no utilizan el proxy inverso, o configurando AppController para que se conecte en un puerto diferente y configurando el proxy inverso para que pase el tráfico en este puerto sin inspeccionarlo.
Servidor web
Los hosts GO-Global disponen de un servidor web integrado que puede alojar la aplicación web GO-Global y sus archivos HTML y JavaScript de soporte. Cuando se utiliza el servidor web integrado de GO-Global, las solicitudes HTTP para los archivos web de GO-Global se reenvían a los hosts de granja GO-Global en la red interna.
En implementaciones de Internet, sin embargo, existen beneficios de seguridad al alojar los archivos web de GO-Global en un servidor web de terceros ubicado en la DMZ. Algunos ejemplos de servidores web de terceros son Apache HTTP Server, Nginx y Microsoft IIS (Internet Information Services).
Cuando se utiliza un servidor web de terceros, la aplicación web de GO-Global y los archivos asociados deben instalarse en el servidor web, ya sea mediante el instalador del host o copiando el contenido del directorio web de GO-Global en el servidor web.
Mientras que la mayoría de los servidores web de terceros tienen funcionalidad para manejar conexiones WebSocket, las conexiones WebSocket generalmente son manejadas por un balanceador de carga dedicado o un proxy inverso. Los administradores pueden configurar WAF y proxies inversos para enrutar las solicitudes HTTP de GO-Global a un servidor web y enrutar las conexiones WebSocket a los hosts de granja GO-Global o a un equilibrador de carga.
Alternativamente, cuando no se utiliza un WAF o proxy inverso, los administradores pueden crear un punto final diferente (dirección o puerto) para las conexiones WebSocket de GO-Global y especificar este punto final a través de los parámetros dehost y/o puerto en la URL del cliente o en la página logon.html de GO-Global.
Equilibrador de carga de red
Cuando se necesita más de un host de granja, se requiere un equilibrador de carga para distribuir las conexiones de usuario entre los hosts. El equilibrador de carga puede ser un proxy inverso o un equilibrador de carga de red.
En entornos en los que se accede a varias aplicaciones a través de un único punto final de Internet, el cortafuegos perimetral normalmente reenviará las conexiones a un proxy inverso (opcionalmente a través de un WAF). El proxy inverso puede entonces reenviar las conexiones directamente a los hosts de la granja (equilibrando la carga), o puede reenviar las conexiones indirectamente a los hosts a través de un equilibrador de carga de red.
Como alternativa, en entornos en los que GO-Global es la única aplicación a la que se accede a través del punto final de Internet, el cortafuegos perimetral puede reenviar las conexiones del puerto 443 directamente a un equilibrador de carga de red. Desde allí, el equilibrador de carga selecciona un host de granja y reenvía la conexión al host de granja en el puerto especificado en la consola de administración.
A diferencia de los proxies inversos, los equilibradores de carga de red no inspeccionan el tráfico ni lo enrutan en función del contenido de los datos. Generalmente enrutan el tráfico basándose en variables como el puerto de destino y la dirección IP de origen. Ejemplos de balanceadores de carga que pueden operar en la capa 4 y enrutar conexiones TCP (TLS se termina en los hosts GO-Global) son HAProxy, el balanceador de carga Azure y el balanceador de carga de red AWS.
Algunos equilibradores de carga de red pueden terminar TLS en el equilibrador de carga. Si el equilibrador de carga está configurado para terminar TLS, el parámetrotls de GO-Global debe añadirse a la URL del cliente o debe especificarse en la página logon.html de GO-Global.
Cuando un equilibrador de carga finaliza TLS, puede opcionalmente volver a cifrar los datos que transmite a los hosts de granja. Si los Farm Hosts están configurados para utilizar el protocolo TLS, el equilibrador de carga debe estar configurado para volver a cifrar los datos que envía a los Farm Hosts. Por el contrario, si el equilibrador de carga no vuelve a cifrar los datos, el protocolo de GO-Global debe establecerse en TCP y el cifrado debe establecerse en Ninguno.
Cuando un equilibrador de carga de red no finaliza TLS, pasa los datos a los hosts de la granja sin descifrarlos ni volver a cifrarlos. En esta configuración, el protocolo TLS debe estar activado en los hosts de la granja y el parámetrotls no debe especificarse en la URL del cliente ni en la página logon.html.
Cortafuegos Back-End
Se puede utilizar un cortafuegos back-end para limitar el acceso a los Farm Hosts a sistemas front-end específicos. Por ejemplo, si se utilizan proxies inversos para enrutar las conexiones a los hosts de granja, se puede configurar un cortafuegos back-end para que solo permita que los proxies inversos se conecten a los hosts de granja. En este ejemplo, el cortafuegos back-end debe configurarse para permitir que los proxies inversos se conecten a los hosts de la granja en el puerto especificado en Admin Console en Herramientas | Opciones de host | Seguridad | Puerto (491, por defecto), y el tráfico debe permitirse en ambas direcciones.
Si las aplicaciones que se ejecutan en los hosts de la granja deben acceder a Internet, el cortafuegos del back-end debe estar configurado para permitir este acceso.
Los hosts de granja GO-Global no requieren acceso a Internet. Sin embargo, si GO-Global se activa mediante una licencia de nube, el APS de los administradores de granjas debe poder conectarse a portal.graphon.com y cloud.graphon.com en el puerto 443.
Controlador de dominio
En la mayoría de las implementaciones, los hosts de granja son miembros de un dominio de Microsoft Active Directory (AD). En este entorno, es esencial que los hosts de granja mantengan comunicación con sus controladores de dominio. Esta conectividad les permite autenticar cuentas, recuperar información y configuraciones de usuario, cargar perfiles itinerantes y aplicar directivas de grupo. En las implementaciones de OpenID Connect, los clientes a menudo tienen que configurar la delegación restringida en los objetos informáticos AD de los hosts de granja.
Administración Cortafuegos
Un cortafuegos de administración puede utilizarse para limitar la capacidad de los usuarios de acceder a sistemas de administración como controladores de dominio y Farm Managers desde Farm Hosts. Por ejemplo, un cortafuegos de administración puede utilizarse para impedir que los usuarios que ejecutan aplicaciones en hosts de granja intenten conectarse a controladores de dominio y Farm Managers mediante Remote Desktop.
Si existe un cortafuegos de administración entre los Farm Hosts y los Farm Managers, el cortafuegos debe permitir que los Farm Hosts se conecten a los Farm Managers en el puerto especificado en Admin Console en Herramientas | Opciones de host | Seguridad | Puerto (491, por defecto), y se debe permitir el tráfico en ambas direcciones.
Si existe un cortafuegos de administración entre los Farm Hosts y los controladores de dominio, el cortafuegos debe configurarse para todas las comunicaciones en los puertos que Windows utiliza para comunicarse entre los controladores de dominio y los miembros del dominio. Consulte la documentación de Microsoft para obtener esta información.
Proveedor de identidad
Cuando se utiliza la autenticación de OpenID Connect, los hosts de granja deben poder abrir conexiones con el proveedor de identidad a través de la URL de token especificada en Admin Console en Herramientas | Opciones de host | Autenticación | Configurar los ajustes de OpenID Connect | URL de token.
Infraestructura de autoescalado
Los proveedores de servicios en la nube (CSP), como Amazon Web Services (AWS), Microsoft Azure, Oracle Cloud y Google Cloud (GCP), ofrecen funciones que pueden utilizarse para iniciar y detener automáticamente los hosts de granja a medida que aumenta o disminuye la carga. Cuando se utilizan estas funciones, los administradores suelen crear una imagen base ("gold") de un Farm Host que se puede replicar según sea necesario para dar soporte a los usuarios que se conectan al sistema.
Las imágenes de host de granja tienen GO-Global instalado y configurado, así como cualquier aplicación que los usuarios ejecutarán en los hosts de granja. Los administradores suelen automatizar la creación de estas imágenes mediante una combinación de secuencias de comandos de PowerShell y código de infraestructura desarrollado con una herramienta de infraestructura como código (IaC) como Terraform.
Consulte Automatización de la configuración de GO-Global para saber cómo instalar y configurar GO-Global mediante programación.
Las imágenes de host de granja suelen tener almacenadas las direcciones de su Farm Manager y Failover Farm Manager. Esto hace que el escalado (añadir hosts a una granja) sea sencillo. Cuando se inician nuevas instancias de host, se conectan automáticamente al Farm Manager, y la función de autoescalado del CSP suele encargarse de añadir la nueva instancia al grupo de destino del equilibrador de carga.
Los Farm Hosts obtienen las licencias de sus Farm Managers, por lo que no es necesario configurar las licencias cuando se inicia una nueva instancia de Farm Host. Cuando se inician las sesiones en un anfitrión de granja, el anfitrión obtiene los puestos de licencia del administrador de granja. Por lo general, se consume un puesto por cada sesión simultánea.
La ampliación (eliminación de hosts de una granja) suele ser un poco más complicada que la reducción. Esto se debe a que normalmente es deseable esperar para apagar una instancia de Granja hasta que todas las sesiones que se ejecutan en ella se hayan cerrado. En Desconectar un anfitrión de granja se describe cómo hacerlo.
Cuando se detiene un anfitrión de granja, se interrumpe la conexión del anfitrión con Farm Manager. Cuando esto sucede, el Farm Manager libera automáticamente los puestos que estaban en uso en el host. Por lo tanto, no hay riesgo de que los hosts que ya no existen consuman puestos. No es necesario hacer nada para borrar los hosts que se han apagado; esto se hace automáticamente.
Con GO-Global, la mejor métrica para controlar el autoescalado es generalmente el número de sesiones en ejecución. El número de sesiones en ejecución en un host o en una granja se puede obtener, respectivamente, de un host de granja o de un administrador de granja a través de los contadores de rendimiento de GO-Global o a través de la función PowerShell Get-GGSessions de GO-Global.
Zonas y regiones disponibles
Para proporcionar una alta disponibilidad, los proveedores de servicios en la nube (CSP) admiten despliegues multicentro de datos a través de zonas y regiones de disponibilidad. Las zonas de disponibilidad son uno o más centros de datos situados en la misma región geográfica. Las regiones CSP son áreas geográficas que contienen una o más zonas de disponibilidad. Los dominios de fallos CSP, también conocidos como grupos de disponibilidad, son recursos tolerantes a fallos ubicados en partes físicamente separadas de un único centro de datos.
GO-Global soporta despliegues a través de múltiples zonas de disponibilidad. Las zonas de disponibilidad en las que se despliega GO-Global pueden estar ubicadas dentro de la misma región CSP o en diferentes regiones CSP.
Dentro de una región CSP, GO-Global se implementa generalmente en al menos dos zonas de disponibilidad, con el Farm Manager principal ejecutándose en una zona de disponibilidad y el Farm Manager de conmutación por error ejecutándose en una zona de disponibilidad diferente. Los Farm Hosts pueden ejecutarse en cualquier número de zonas de disponibilidad dentro de la región, pero deben poder conectarse tanto al Farm Manager primario como al Farm Manager de conmutación por error.
Cuando se necesita una alta disponibilidad a través de las regiones CSP, o cuando los usuarios están ubicados en todo el mundo, GO-Global puede implementarse en múltiples regiones CSP con un equilibrador de carga DNS como Route 53 de AWS enrutando las conexiones de los clientes a través de las regiones. El equilibrador de carga DNS puede configurarse para admitir la conmutación por error activa-activa o activa-pasiva, según sea necesario.
Herramientas de seguimiento y observabilidad
Las herramientas de monitorización y observabilidad se utilizan para monitorizar el estado de los despliegues de GO-Global y emitir alertas cuando surgen problemas. GO-Global proporciona varias características que estas herramientas pueden utilizar para supervisar GO-Global.
La mayoría de las herramientas de observabilidad disponen de funciones para la ingesta de archivos de registro. Los archivos de registro de GO-Global están en formato HTML, por defecto, que la mayoría de las herramientas de observabilidad no soportan. Por lo tanto, GO-Global debe configurarse generalmente para grabar sus archivos de registro en formato de texto cuando sus registros vayan a ser ingeridos por una herramienta de observabilidad.
Además de sus archivos de registro, GO-Global registra eventos en el registro de aplicaciones de Windows. Los eventos que GO-Global registra en el registro de aplicaciones de Windows incluyen inicios y cierres de sesión, inicios de sesión de usuario e inicios y cierres de aplicación.
Para admitir la supervisión de Farm Hosts y Farm Managers, GO-Global proporciona una solicitud healthCheck. La solicitud healthCheck se puede utilizar para determinar si el Application Publishing Service se está ejecutando en un Farm Host o Farm Manager y, opcionalmente, si el sistema puede crear una sesión. Los equilibradores de carga, por ejemplo, pueden utilizar la solicitud healthCheck para comprobar el estado de los hosts de granja de su grupo de destino.
Los sistemas que envían solicitudes de healthCheck deben estar registrados en cada Farm Host o Farm Manager de destino. En concreto, la dirección IP del sistema que envía la solicitud debe aparecer en formato CIDR en la propiedad APIWhiteList del archivo HostProperties.xml del sistema de destino.
Además de estas herramientas, la API PowerShell de GO-Global se puede utilizar para obtener información detallada en tiempo de ejecución de Farm Hosts y Farm Managers. Por ejemplo, la función Get-GGSessions devuelve información sobre las sesiones que se ejecutan en un Farm Host o Farm Manager.
Conclusión
La implementación de GO-Global en un entorno a gran escala o integrado en la nube requiere una cuidadosa coordinación entre múltiples componentes de infraestructura. Configurando correctamente elementos como cortafuegos, equilibradores de carga, proxies inversos y sistemas de supervisión, los administradores pueden conseguir un entorno GO-Global seguro, escalable y de alto rendimiento que ofrezca una experiencia de usuario fluida.
Tanto si se implementa en las instalaciones, en la nube o en arquitecturas híbridas, los principios descritos en este artículo garantizan que GO-Global funcione eficazmente en las redes empresariales modernas, manteniendo la fiabilidad, la flexibilidad y el control en cada nivel de implementación.
¿Es usted un ISV que explora la entrega de aplicaciones basada en la nube? Póngase en contacto con nosotros para saber cómo GO-Global puede ayudarle a agilizar el acceso al software para sus usuarios finales. O descargue una versión de prueba gratuita para probarlo usted mismo.
