> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/server/es/knowledge-base/how-to-articles/deploy-in-a-high-availability-or-load-balancing-environment.md). # Desplegar en un entorno de alta disponibilidad o de equilibrio de carga Despliegue Devolutions Server en un entorno de alta disponibilidad o de balanceo de carga en Windows, cubriendo el reenvío de IP, la sincronización de claves de cifrado y la conmutación por error de S {% hint style="info" %} El contenido de este artículo se aplica exclusivamente a los sistemas operativos Windows. {% endhint %} Siguiendo estas directrices, puede garantizar un despliegue de alta disponibilidad o de balanceo de carga robusto y seguro. En una configuración típica, los dispositivos cliente (ordenadores de sobremesa, portátiles y dispositivos móviles) se conectan a través de internet a un cortafuegos, que reenvía el tráfico a un balanceador de carga. El balanceador de carga distribuye entonces las solicitudes entre dos (o más) nodos de Devolutions Server. Por ejemplo: * Cortafuegos: `10.10.10.10` * Balanceador de carga: `10.11.11.11` * Nodo A de Devolutions Server: `10.12.12.50` * Nodo B de Devolutions Server: `10.12.12.51` ### Consideraciones clave * **Listas de IP permitidas y bloqueadas**: Estas funciones requieren la validación de la dirección IP del cliente para garantizar la seguridad y el cumplimiento normativo, normalmente con la [cabecera X-Forwarded-For](/server/es/knowledge-base/knowledge-base-articles/x-forwarded-for.md), que debe habilitarse en ***Administración*** – ***Configuración del servidor*** – ***Seguridad***.\ Además, [incluya la cabecera X-Forwarded-For en los registros de IIS](/server/es/knowledge-base/how-to-articles/add-x-forwarded-for-column-in-iis.md) para garantizar un seguimiento preciso de las direcciones IP de los clientes.
* **Cabeceras de respuesta HTTP**: Cada nodo de servidor debe añadir un identificador único y no descriptivo a las cabeceras de las respuestas HTTP. Este identificador, que podría ser tan genérico como «node1» o «node2», sirve para rastrear la ruta de las solicitudes a través de los distintos servidores sin revelar detalles sensibles del servidor, como el nombre de dominio completo (FQDN). Esta práctica es crucial no solo para trazar el recorrido de la solicitud, sino también para mantener la seguridad operativa, ya que limita la exposición de detalles de la infraestructura que podrían ser explotados. Las organizaciones centradas en una mayor seguridad deberían considerar precauciones adicionales, como utilizar valores aleatorios o con hash como identificadores para ocultar aún más las identidades de los servidores.\ \ Esto no es necesario para el funcionamiento, y cada balanceador de carga puede tener su propio método para lograrlo. Sin embargo, identificar el servidor que respondió a la solicitud puede ser un paso útil para la resolución de problemas.\ \ Consulte [Identificar el servidor que responde en una topología de alta disponibilidad](/server/es/knowledge-base/how-to-articles/identify-the-server-answering-on-a-high-availability-topology.md) para obtener más información. ### Arquitectura #### Balanceador de carga * **X-Forwarded-For y certificados SSL**: Al implementar el balanceo de carga, tenga en cuenta también los certificados SSL y la cabecera [X-Forwarded-For](/server/es/knowledge-base/knowledge-base-articles/x-forwarded-for.md).\ Utilice cualquier tecnología de balanceo de carga que pueda añadir la cabecera X-Forwarded-For a través de proxies o dispositivos intermedios. Esta cabecera debe eliminarse si se recibe de un cliente, y solo debe ser establecida por su equipamiento de red.\ La configuración adecuada de estos elementos garantiza conexiones seguras y un seguimiento preciso de las IP de los clientes en varios servidores. Consulte las consideraciones clave anteriores sobre las listas de IP permitidas y bloqueadas. * **Reglas de afinidad de cliente**: La asignación de reglas de afinidad de cliente garantiza que, cuando un cliente se conecta por primera vez, las solicitudes futuras del mismo cliente se dirijan al mismo servidor web, manteniendo la coherencia. * **Opciones de balanceo de carga**: Si no utiliza un balanceador de carga virtual o de hardware dedicado delante de los servidores web, el balanceo de carga por DNS puede ser una alternativa práctica. En este enfoque, se configuran varios registros DNS (A, AAAA o CNAME) para el mismo dominio. Cuando un cliente se conecta, el proveedor de DNS selecciona aleatoriamente uno de estos registros para responder.\ Por ejemplo, si **devolutions-server.mycorp.com** tiene dos registros A que apuntan a distintas IP para cada servidor web, el DNS responderá con uno de estos registros, distribuyendo así eficazmente la carga entre los servidores.\ Sin embargo, el balanceo de carga por DNS tiene limitaciones. Al carecer de comprobaciones de estado, si un servidor deja de funcionar, el proveedor de DNS puede seguir dirigiendo tráfico al servidor fuera de línea, lo que provoca conexiones fallidas. Este ejemplo se explica en este [artículo de Cloudflare sobre registros DNS](https://developers.cloudflare.com/load-balancing/load-balancers/dns-records/). #### Servidores web / servidores de aplicaciones En una configuración típica, se configuran dos servidores con IIS, cada uno ejecutando una instancia de Devolutions Server. Las consideraciones clave incluyen el cifrado, el reenvío de IP, la conmutación por error de SQL y la coherencia de SSL. * **Sincronización de las claves de cifrado**: Cada servidor requiere claves de cifrado coincidentes para descifrar los datos de la base de datos compartida. Tras instalar el primer servidor, exporte sus claves de cifrado e impórtelas en el segundo servidor para garantizar las capacidades de descifrado adecuadas. * **Configuración de X-Forwarded-For**: Configure la [cabecera X-Forwarded-For](/server/es/knowledge-base/knowledge-base-articles/x-forwarded-for.md) para mantener información precisa sobre las IP de los clientes en todos los servidores. Esto es esencial con fines de seguimiento y seguridad. Consulte las consideraciones clave anteriores sobre las listas de IP permitidas y bloqueadas. * **Configuración de la conmutación por error de la base de datos SQL**: En la Devolutions Server Console, siga los pasos que se indican a continuación para cada instancia de Devolutions Server. 1. Seleccione la instancia de Devolutions Server. 2. Vaya a ***Servidor*** – ***Editar***.
3. En ***Base de datos***, haga clic en ***Configuración avanzada***.
4. Haga clic en ***Más configuraciones***.
5. Establezca el ***Valor*** del ajuste ***MultiSubnetFailover*** en ***True***.
6. Haga clic en ***Ok*** para guardar los cambios y cerrar las ventanas. Este ajuste permite que la aplicación se conecte a varios servidores de bases de datos SQL en el [grupo de disponibilidad Always On](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server),garantizando una conmutación por error rápida cuando sea necesario. * **Garantizar la coherencia de los certificados SSL**: Dado que ambos servidores IIS sirven la misma URL a través de un balanceador de carga (a menos que utilice IIS ARR con un DNS round-robin u otro esquema de balanceo de carga), es fundamental que todos los certificados SSL coincidan y se sirvan correctamente a lo largo de toda la cadena. Asegúrese de que el balanceador de carga y ambos servidores IIS tengan certificados SSL coincidentes para proporcionar una conexión segura y unificada a los clientes. #### Servidores de bases de datos * **Configuración de SQL Servers en un grupo de disponibilidad Always On**: Para garantizar la alta disponibilidad, configure dos Microsoft SQL Servers en un [grupo de disponibilidad Always On](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server). Esta configuración sigue un modelo **Activo → Pasivo** con un quórum (o «testigo») para supervisar el estado de los servidores y activar la conmutación por error si uno de ellos deja de funcionar. * **Habilitar el modo de base de datos contenida**: La base de datos de Devolutions Server debe funcionar en [modo contenido](https://learn.microsoft.com/en-us/sql/relational-databases/databases/contained-databases), lo que permite que la autenticación viaje con la base de datos en lugar de gestionarse a nivel de servidor. Siga estos pasos para habilitar el modo contenido (también puede hacerse mediante comandos T-SQL): 1. Abra Microsoft SQL Server Management Studio. 2. Haga clic con el botón derecho en la base de datos de Devolutions Server y seleccione ***Propiedades***. 3. Vaya a ***Opciones*** y establezca el ***Tipo de contención*** en ***Parcial***. Este ajuste permite que los usuarios de la base de datos se desplacen con ella entre los servidores del grupo de disponibilidad. * **Creación de usuarios contenidos**: Con el modo contenido habilitado en la base de datos, puede crear usuarios vinculados directamente a ella.\ Estos pueden ser: * **Usuarios SQL con contraseñas**: Creados específicamente dentro de la base de datos contenida. * **Usuarios de Windows**: Integrados sin necesidad de un inicio de sesión del servidor MSSQL asociado a la base de datos maestra. Para mayor seguridad, se recomienda utilizar la autenticación de Windows en lugar de usuarios SQL con contraseñas. Sin embargo, tenga en cuenta que, si utiliza usuarios de Windows, la función de bóveda de infraestructura de Devolutions Server no podrá gestionar estos usuarios, ya que actualmente solo admite usuarios autenticados mediante SQL. * **Cliente Remote Desktop Manager**: Cuando utilice el cliente Remote Desktop Manager con un Microsoft SQL Server en una configuración de alta disponibilidad (HA), habilite la [configuración de conmutación por error multisubred](https://docs.devolutions.net/rdm/es/knowledge-base/knowledge-base-articles/sql-server-always-on-availability-groups). Este ajuste es especialmente beneficioso para instalaciones de alta disponibilidad de Microsoft SQL Server y no es necesario para Devolutions Server.\ Para configurar la conmutación por error multisubred en RDM: 1. En Remote Desktop Manager, vaya a ***Archivo*** – ***Espacios de trabajo***. 2. Seleccione el espacio de trabajo de Microsoft SQL Server en la lista de espacios de trabajo y, a continuación, haga clic en ***Editar espacio de trabajo***.
3. En la pestaña ***Avanzado***, haga clic en ***Más configuraciones***.
4. Establezca el ***Valor*** del ajuste ***MultiSubnetFailover*** en ***True***.
5. Haga clic en ***Ok*** y ***Guardar*** para guardar los cambios y cerrar las ventanas. Esta configuración permite que el cliente Remote Desktop Manager gestione varias subredes, garantizando una conmutación por error rápida entre servidores SQL en un entorno de alta disponibilidad. ### Proceso de verificación * **Validación del correo electrónico**: Compruebe que cualquier correo electrónico generado por el sistema contenga el URI público correcto, en lugar del nombre del servidor. Esto puede comprobarse utilizando la función de mensajería de Devolutions Server.
* **Historial e intentos de inicio de sesión**: La tabla ***LoginHistory*** contiene la dirección IP del cliente, no la de ningún servidor intermedio. La tabla ***LoginAttempts*** también muestra la dirección IP, pero existen más escenarios: * Fallos de inicio de sesión (p. ej., credenciales incorrectas) * IP en la lista de bloqueo * IP identificadas como nodo de salida TOR --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.devolutions.net/server/es/knowledge-base/how-to-articles/deploy-in-a-high-availability-or-load-balancing-environment.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.