Programa del evento: arquitectura de clúster, esquema a prueba de fallos, escalamiento, Space Agent PC (VDA) y Space Gateway.
Ponente de hoy: Ruslán Belov, director de producto de Space VDI.
Hoy hablaremos de lo que se lanzó en las últimas versiones de Space VDI 5.3, que apareció después del cuarto trimestre de 2023, y Space VDI 5.4, que se lanzó hace apenas un mes.
El ecosistema VDI es un conjunto que incluye los siguientes componentes:
- plataforma en la nube Space VM para la gestión centralizada de la infraestructura,
- software Space Dispatcher (Space Disp) – gestor de conexiones de escritorios virtuales, responsable de conectar a los usuarios a los escritorios virtuales asignados,
- cliente de conexión propio Space Client a la infraestructura VDI con soporte para Windows, Linux y macOS.
Hoy vamos a hablar de Space Disp. Dividimos los cambios en 5 categorías: arquitectura de clúster, esquema a prueba de fallos, uso del escalamiento, Space Agent PC (VDA) y Space Gateway. Decidimos abandonar una única instancia del gestor y pasar a un multigestor. Esto nos permitió crear un esquema a prueba de fallos y ampliar las opciones de escalamiento de la propia infraestructura. Además, añadimos la posibilidad de conectar máquinas físicas y añadimos una funcionalidad como Space Agent PC, una utilidad que se instala en las máquinas físicas y permite transmitir información sobre su estado. En el futuro, a través de este agente se podrá gestionar la propia máquina y configurar su configuración. Para la seguridad, mejoramos nuestro gateway de seguridad informática.
Pasemos al tema de la arquitectura de clúster, definamos las entidades que se utilizarán aquí.
La primera entidad es HOST – una máquina virtual o un servidor físico con ASTRA Linux 1.7.5 preinstalado – «Smolensk», todavía no admitimos otros sistemas operativos. En el propio host con el sistema operativo se puede instalar un rol específico: Leader, Manager y DB (base de datos). Leader y Manager participarán en la distribución de la carga en el clúster de gestión, y la base de datos estará en el clúster de datos. También existe un elemento como el equilibrador (BL), que distribuye la carga entre los hosts.
El clúster de gestión puede actuar como Leader y Manager. Leader es el host principal, que asume las tareas de conexión y conducción de los servicios internos en segundo plano. Manager combina todos los contenedores Frontend y Backend. Esto se hace para que, en caso de fallo del Leader, sea posible obtener información sobre el estado de los contenedores y otros datos. En caso de fallo del Leader, existe la posibilidad de acceder a la propia interfaz web a través de Manager.
En cuanto al clúster de datos. Inicialmente, constaba solo de la propia base de datos, pero después de su expansión con la posibilidad de replicación. Desde la versión 5.4, en la replicación se utilizaban los medios estándar de las bases de datos. No hay restricciones en la configuración de la base de datos replicada y las propias opciones de replicación. Se garantiza el acceso a los datos de ambas DB.
Dado que han aparecido dos clústeres, para ellos serán necesarios al menos dos hosts, para que aparezcan al actualizar el gestor de 5.2 a 5.3, el host actual asume el rol de DB. Y el segundo host, que se configuró para un clúster de gestión específico, asumirá el rol de Leader. Si hay varios, los demás asumirán el rol de Manager. Los roles de Leader y Manager se instalan manualmente. Primero se actualiza la base de datos, después los propios hosts en el clúster de gestión.
Sobre la arquitectura de clúster. Debido a que hay dos clústeres, existe un esquema mínimo: dos hosts con el sistema operativo ASTRA Linux, por lo que es necesario tener dos licencias. Para la versión 5.3 se utiliza ASTRA Linux 1.7.4. El clúster de gestión, al igual que en el caso de una única instancia, puede admitir hasta 2000 conexiones. Ahora tenemos un esquema mínimo a prueba de fallos: tres elementos en el clúster de gestión: el propio Leader y dos Manager.
Según el algoritmo RAFT utilizado, para garantizar la tolerancia a fallos debe haber un número impar de hosts. En este caso, empieza a funcionar el equilibrador, que distribuye la carga entre los hosts. Este esquema mínimo se puede llamar el primer contorno, proporciona hasta 6000 conexiones. Si se necesitan menos conexiones, pero un esquema a prueba de fallos, solo es adecuada esta opción.
Si el líder y el gestor están en el mismo clúster y el líder no puede soportar la carga, transferirá las conexiones restantes al propio gestor.
También nos acercamos al segundo contorno. Como ya dije, tenemos un número impar de hosts en el clúster de gestión. Añadimos dos hosts adicionales, con lo que obtenemos un clúster de gestión con la posibilidad de hasta 10 mil conexiones y, por supuesto, no olvidamos que en cada host es necesario instalar ASTRA Linux, es decir, en este caso necesitamos 6 licencias de ASTRA Linux.
Este contorno fue el último para la versión 5.3. Como ya dije, nuestra mejora se hizo en el lado del clúster de datos. Es decir, Aquí añadimos dos hosts más al clúster de gestión, con lo que garantizamos 14 mil conexiones, 2 mil en cada host y 8 hosts. Y, en consecuencia, si necesitamos replicación, el esquema máximo con la posibilidad de tolerancia a fallos se muestra en la siguiente diapositiva.
Es decir, de nuevo, un número impar de hosts en el clúster de gestión, siete, y esta es la cantidad máxima, es decir, el gestor ya no lo admite. Si se necesitan más de 14000 conexiones, qué hacer en ese caso, lo evaluaremos en las siguientes diapositivas.
Aquí, entre el clúster de gestión y el clúster de datos, se utiliza una IP virtual, lo que nos permite acceder a cada base de datos. Es decir, vemos en esta diapositiva que ha aparecido un balanceador de carga en la base de datos. En caso de que en algún momento se requiera acceso a una réplica, esta puede convertirse en la principal. Y desde ella leeremos y escribiremos los datos.
En caso de que falle uno de los hosts, en este caso el líder, este asume el rol de administrador después de su reinicio. El rol de líder se transmite a lo largo de la cadena. Aquí ya se utiliza el algoritmo especificado, RAFT, se realiza una votación del líder libre, y el siguiente en la lista de los propios hosts que esté libre y pueda asumir este rol, lo ocupa. El balanceo es cíclico y también transmite sus conexiones a otros hosts. En el momento en que se desconecta el líder, se produce una pausa que dura aproximadamente 5 minutos. Durante este tiempo, los medios de orquestación y los contenedores que se encuentran en el líder, o en el host que falló, comienzan a migrar al host que asumió el rol de líder.
Como vimos en las primeras diapositivas, la disponibilidad de la interfaz estará garantizada en cualquier caso, y podemos rastrear su estado. Lo único que no estará disponible son algunos servicios en segundo plano y algunos procesos que se estaban ejecutando en el líder.
Precisamente estos cambios en el escalamiento con el lanzamiento de VDI 5.2 y VDI 5.3 se muestran en la diapositiva. Es decir, en general no han cambiado mucho. Vemos que el propio administrador de conexiones se ha hecho más grande. Han aparecido de 2 a 8 hosts en el propio administrador. Aquí indicamos que es sin replicación. La réplica se ha convertido en una parte fundamental del esquema. Se instala opcionalmente y en función de la necesidad de uso.
Y en este esquema también pudimos ver la posibilidad de conectar a dos mil o más usuarios. Antes, para hacer esto, era necesario instalar otro administrador de conexiones y conectarlo al mismo controlador, es decir, a los servidores de virtualización SpaceVM. De esta manera, teníamos más de dos mil conexiones, pero no había interconexión entre estos administradores. Es decir, en cada administrador era necesario instalar en el cliente una lista a la que nos conectamos. Y así, el primero libre estaba disponible. Era necesario regular de alguna manera, ya con medios internos, la agrupación de datos de los escritorios virtuales. Es decir, este administrador incluye este grupo, y este administrador – la contenedorización – incluye otro grupo.
Ahora, con la adición de la contenedorización, es decir, podemos proporcionar hasta 14 mil conexiones, y esta cantidad de conexiones es suficiente para el uso estándar, ya podemos operar con los propios pools y grupos de estos pools en función de la cantidad de conexiones que necesitemos.
Además, en caso de que fuera necesario utilizar más potencia, si no era suficiente la potencia de un clúster Space VM para procesar los escritorios, o teníamos momentos de procesamiento de alta carga, como por ejemplo el modelado, podíamos utilizar dos clústeres. Y así, para cada clúster necesitábamos un administrador adicional en caso de aumentar la misma cantidad de conexiones. Ahora también utilizamos un solo administrador y podemos agregarle varios clústeres. Es decir, no necesariamente deben ser dos, tres también es posible.
A continuación, opciones adicionales de escalamiento. Como antes, el administrador que estaba en una sola instancia, cuando era necesario aumentar las conexiones que la propia parte del administrador – el broker – no podía soportar, agregábamos un broker adicional.
Aquí existe la posibilidad de utilizar más de 14 mil conexiones, aquí están conectados dos multidispatchers a un solo controlador. Si el propio clúster permite soportar más de 14 mil conexiones y, en consecuencia, existe la posibilidad de calcular estas capacidades. O, si necesitamos aislar los datos, podemos hacerlo como se muestra en el escenario 4.
Estos escenarios han sido reelaborados a partir de los escenarios de las versiones anteriores a la 5.3. Ahora se ha añadido un escenario adicional. El pool físico nos permite calcular hasta 2000 clientes por host, y aquí la ventaja es que se puede utilizar este administrador no solo específicamente para alguna funcionalidad, es decir, escritorios virtuales o escritorios físicos, sino todo junto. Por ejemplo, tenemos 7 hosts con la posibilidad de conectar hasta 14000. Y podemos dividirlos por igual o de alguna manera dinámica. Y así, tenemos la posibilidad de configurar de forma flexible tanto la propia infraestructura como ahorrar en los propios recursos. Es decir, si no existe la propia potencia de Space VM que pueda proporcionarnos escritorios, pero existen dispositivos físicos a los que podemos dar acceso, podemos incluirlos en este esquema. Además, el uso de Space VM no requiere licencias adicionales y se pueden utilizar de inmediato.
Actualmente utilizamos exclusivamente ASRTA Linux como sistema operativo invitado, y en consecuencia el sistema operativo del propio escritorio. Y para la conexión recomendamos utilizar nuestro proyecto en este caso, si es necesario utilizar soluciones ofimáticas estándar. Pero también permite procesar la parte gráfica con modelado tridimensional. Pero si necesita soluciones de alta carga, con escenas dinámicas rápidas, y tiene un buen ancho de banda, puede utilizar el protocolo Loudplay.
Hace un mes lanzamos soluciones para sistemas operativos Unix, es decir, sistemas Linux, como Demi, ASRTA Linux, Ubuntu, y así ya podemos utilizarlos también en nuestras soluciones.
Para que podamos salir de Internet de forma segura, hemos desarrollado la pasarela Space Gateway. Esta pasarela se coloca entre los propios dispositivos cliente y el administrador. La propia pasarela tiene la posibilidad de configurar en sí misma un puerto público, y así bloquea el acceso a alguna parte de la infraestructura, es decir, al escritorio virtual o al propio escritorio físico, creando túneles. Es decir, al conectarse a un escritorio específico, el administrador transmite la información de que se requiere una conexión, esta conexión se envía a la pasarela, y la pasarela levanta un túnel con un rango de puertos configurado. De esta manera, los datos ya llegan desde el cliente hasta el clúster de gestión.
Ahora, sobre los cambios que se produjeron al pasar de la versión 5.3 a la 5.4. El cambio principal es que hemos renunciado a la única instancia de la posibilidad de utilizar el propio administrador. También hemos añadido opciones de registro, como la integración con ArcSight y el formato CEF. Se ha realizado la integración con los servicios de directorio de servicios como ADFS, lo que ha añadido capacidades tanto de autenticación de dos factores como de autogestión con los servicios de directorio y a través de este servicio. El cambio principal es la implementación de la gestión del pool de máquinas físicas, la optimización de los subsistemas de registro, los medios de integración con el sitio y otras capacidades de registro. Optimización de los subsistemas de seguridad. Con esto queremos decir que actualmente estamos trabajando en opciones con los portapapeles, la conexión a dispositivos externos, es decir, la conexión a través de USB de dispositivos como los propios soportes o las tarjetas inteligentes. Es decir, actualmente solo tenemos la posibilidad de encenderlos/apagarlos. La mejora del soporte de diversas funcionalidades estará en nuestras próximas versiones.
También se ha mejorado la gestión de las políticas de contraseñas. Aquí obligamos a los usuarios a cambiar la contraseña en caso de que el administrador proporcione al usuario su contraseña temporal, el usuario al iniciar sesión debe cambiarla. Esto permite mantener la confidencialidad de los datos y, en consecuencia, reforzar la seguridad.
También hemos rediseñado la propia interfaz web. Se ha mejorado la legibilidad y la claridad. Había momentos en que los colores no se percibían correctamente a través del protocolo de acceso remoto. Aquí también hemos realizado una reelaboración. Se ha aumentado la propia cantidad de máquinas virtuales para el pool estático. El número máximo posible era de 100 máquinas virtuales en el pool estático. Y en general recomendábamos utilizar el pool automático. Ahora los hemos aumentado hasta 1000 máquinas virtuales. Y en general, con el uso del multidispatcher, consideraremos la opción de aumentarlo en función de la cantidad de hosts.
Uno de los cambios se produjo precisamente en la inversionalidad. Ahora todos los componentes que se utilizan en el administrador los numeraremos por la parte menor. Es decir, por ejemplo, ahora habrá una versión para componentes como Space Agent y Space Gateway, también respectivamente 1.4 y 1.4. Y también ha finalizado la mejora de la parte gráfica del cliente Space Client.