¿Cuántos servidores de sesión se deben distribuir? ¿Cuántos servidores MSS? ¿Qué método de autenticación emplea? ¿Hay otras consideraciones que se deben tener en cuenta? En esta sección, aprenderá a optimizar la distribución del servidor de sesión y MSS.
Contenido de esta sección:
Antes de iniciar la distribución, debe determinar el método de autenticación que desea utilizar. La autenticación valida la identidad del usuario a partir de determinadas credenciales, como una combinación de nombre de usuario/contraseña o un certificado de cliente. A continuación, la autorización se utiliza para determinar las sesiones a las que puede acceder cada usuario.
La autenticación y la autorización las proporciona MSS en una distribución de HACloud. Consulte Autenticación y autorización.
Determinar cuántos servidores de sesión y MSS necesita para satisfacer sus necesidades es el primer paso de la plantificación de la distribución. Independientemente de sus necesidades, Host Access for the Cloud puede distribuirse para proporcionar capacidad y alta disponibilidad.
Su solución dependerá de sus necesidades. Sin embargo, consulte Huella de distribución de alta disponibilidad para obtener un ejemplo de distribución ampliable y de alta disponibilidad.
Las principales preguntas a las que debe responder son:
¿Cuál es el número máximo de sesiones de host que se utilizarán simultáneamente?
¿Cuántos usuarios utilizarán el sistema?
¿Qué grado de disponibilidad debe ofrecer el sistema en caso de un fallo en varias áreas del sistema?
La ampliación es la capacidad de un sistema de gestionar distintos volúmenes de carga. Para aumentar la capacidad, un sistema puede ampliarse (verticalmente) mediante la ejecución de un servidor más potente o incrementarse de forma progresiva (horizontalmente) mediante la adición de más servidores o nodos.
En cada caso, existen desventajas que se deben tener en cuenta:
La ampliación vertical ofrece la simplicidad de contar con menos servidores. Sin embargo, aumenta el riesgo de un fallo significativo si el servidor deja de funcionar.
La ampliación horizontal incluye más servidores, pero extiende el riesgo a muchos servidores, por lo que, si uno deja de funcionar, esto afectará a una menor cantidad de usuarios.
Gracias a su mayor capacidad de recuperación, se recomienda una ampliación horizontal mediante la adición de más servidores o nodos cuando aumente la capacidad.
La alta disponibilidad es la capacidad de un sistema para seguir proporcionando servicios cuando se produce un fallo en alguna parte del sistema. Esta se consigue mediante la adición de redundancia en componentes clave del sistema.
NOTA:En esta guía, se aborda la provisión de la alta disponibilidad de los servicios centrales de Host Access for the Cloud. Sin embargo, la alta disponibilidad real se basa en la redundancia en muchas capas de todas las áreas de los sistemas, lo que sobrepasa el ámbito de este documento.
La alta disponibilidad en Host Access for the Cloud se consigue mediante:
La distribución de suficientes servidores de sesión y MSS para proporcionar la capacidad necesaria con función de capacidad de aumento (libre) para fallos.
El establecimiento de una capacidad de aumento adecuada para que, cuando falle un servidor y la carga se conmute por error a los servidores restantes, estos no vean comprometida su seguridad por la carga adicional.
El uso de equilibradores de carga para distribuir la carga y enviar a los usuarios a otros servidores en caso de fallo.
La réplica de datos entre servidores de MSS, que gestiona la agrupación en clúster de MSS.
Consulte la sección Huella de distribución de alta disponibilidad para obtener un ejemplo de cómo alcanzar estos requisitos.
El número de servidores de sesión necesarios se determina en función del número de sesiones de host simultáneas que se están ejecutando. Las sesiones de host generan más carga en el servidor de sesión que los usuarios, por lo que es necesario centrarse en la cantidad de sesiones de host necesarias en lugar de en la cantidad de usuarios.
|
Número de sesiones de host simultáneas |
Número de servidores de sesión necesarios |
|---|---|
|
Hasta 3.000 |
2 servidores de sesión |
|
Más de 3.000 |
(Número de sesiones de host necesarias) / 2.000 +1 (mínimo tres) |
Un único servidor de sesión admite 2000 sesiones de host simultáneas.
Un servidor de sesión presenta una capacidad de ampliación integrada para 1.000 usuarios adicionales en caso de conmutación por error.
Se necesita un mínimo de dos servidores de sesión para la alta disponibilidad.
El número de servidores de MSS necesarios se determina en función del número de usuarios simultáneos.
|
Número de usuarios simultáneos |
Número de servidores MSS necesarios |
|---|---|
|
Hasta 30.000 |
3 servidores MSS |
|
Más de 30.000 |
(Número de usuarios necesarios) / 10.000 +1 (debe ser un número impar) |
Un único servidor MSS admite 10.000 usuarios simultáneos.
Un servidor MSS presenta una capacidad de ampliación integrada para 5.000 usuarios adicionales en caso de conmutación por error.
Se necesita un mínimo de tres servidores MSS para la alta disponibilidad.
Se necesita un número impar de servidores MSS para la alta disponibilidad debido a la necesidad de un quórum de base de datos.
Puede distribuir servidores de sesión de una de estas dos formas:
Mediante el uso del método tradicional, es decir, la instalación de cada servidor de sesión en un servidor específico.
Mediante el uso de Docker para ejecutar cada servidor de sesión en un contenedor. Docker ofrece diversas ventajas, incluida una mayor flexibilidad en relación con la cantidad de servidores de sesión que puede ejecutar en un único servidor. Consulte Uso de Docker para obtener más información.
Deberá proporcionar equilibradores de carga para los servidores de sesión y MSS. Hay valores de configuración habituales que debe tener en cuenta:
Load Balancing Algorithm (Algoritmo de equilibro de carga): el algoritmo determina el servidor al que se envía el tráfico nuevo. Se recomienda "Least Connections" (Número mínimo de conexiones) o algo similar. Comprobar que esta opción distribuya adecuadamente la carga es fundamental para la estabilidad general del sistema. Si el equilibrador de carga no se ha configurado correctamente o no funciona de forma adecuada, se corre el riesgo de que se sobrecargue un servidor individual.
Session Persistence (Affinity/Sticky Sessions) (Persistencia de sesión, sesiones de afinidad/persistentes): se trata de la capacidad de enviar el mismo usuario al mismo servidor mediante varias peticiones. Tanto el servidor de sesión como el MSS son aplicaciones con estado y requieren que las sesiones persistentes estén habilitadas en sus equilibradores de carga. Se indica a continuación.
Health Check Endpoint (Puesto final de comprobación de estado): se trata de la dirección URL en el servicio de destino que se utiliza para determinar si la instancia presenta un buen estado y debería permanecer en servicio. Cada tipo de servidor proporciona su propia dirección URL de estado.
La sección Huella de distribución de alta disponibilidad proporciona valores de configuración recomendados para cada equilibrador de carga.
Existen tres opciones habituales para la gestión de TLS/SSL en un equilibrador de carga. La opción que elija dependerá de sus necesidades.
El certificado debe estar instalado en el equilibrador de carga en las dos primeras opciones. La tercera opción, la transferencia directa de TLS, no requiere un certificado en el equilibrador de carga. El plan de alta disponibilidad utiliza puentes TLS para proporcionar TLS de extremo a extremo, al mismo tiempo que permite la persistencia basada en cookies. Las opciones son:
TLS Termination/Offloading (Finalización/descarga de TLS): esta opción finaliza la conexión HTTPS en el equilibrador de carga y continúa con el servicio mediante HTTP.
TLS Bridging (Re-encryption) (Puentes TLS, recifrado): esta opción finaliza la conexión HTTPS en el equilibrador de carga y establece de nuevo una conexión HTTPS entre el equilibrador de carga y el servicio. Esto proporciona TLS de extremo a extremo y al mismo tiempo permite que el equilibrador de carga inyecte una cookie para la persistencia de la sesión.
TLS Passthrough (Required for X.509) (Transferencia directa de TLS, necesaria para X.509): el equilibrador de carga distribuye mediante proxy la conexión TLS sin descifrarla. La desventaja de esta opción es que, dado que no se puede inyectar una cookie, la persistencia debe basarse en la dirección IP de origen o un elemento similar.
Al utilizar la autenticación X.509, se debe establecer la opción de transferencia directa de TLS en los equilibradores de carga de Host Access for the Cloud y MSS, ya que los certificados de cliente se deben presentar a los servidores en el backend. Como se requiere la transferencia directa de TLS, es necesario un método no basado en cookies para la persistencia de sesión, como la dirección IP de origen para los equilibradores de carga del servidor de sesión y MSS. Esto es necesario porque con la transferencia directa de TLS, no hay posibilidad de que el equilibrador de carga descifre la conexión para establecer o incluso ver una cookie.
Los servicios de medición se ejecutan en cada servidor MSS de un clúster. Se requiere un mínimo de tres servidores MSS para garantizar una alta disponibilidad del servicio de medición. De este modo, garantiza que los clientes de emulación puedan seguir funcionando, aunque un servidor deje de estar disponible. Consulte Configuración de la medición.
El Administrador de ID de Terminal Server no admite actualmente la alta disponibilidad. Puede configurar un servidor pasivo, pero no se replicará el estado de los ID desde el servidor activo. Si el servidor activo no está disponible, aún podrá acceder al servidor pasivo, pero los ID no conservarán su estado actual. Consulte Configuración del Administrador de ID de Terminal.