> 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/fr/knowledge-base/how-to-articles/deploy-in-a-high-availability-or-load-balancing-environment.md). # Déployer dans un environnement à haute disponibilité ou à équilibrage des charges Déployer Devolutions Server dans un environnement de haute disponibilité ou d'équilibrage des charges sous Windows, en couvrant le transfert d'adresses IP, la synchronisation des clés de chiffrement e {% hint style="info" %} Le contenu de cet article s'applique exclusivement aux systèmes d'exploitation Windows. {% endhint %} En respectant ces directives, vous pouvez assurer un déploiement robuste et sécurisé en haute disponibilité ou en équilibrage des charges. Dans une configuration typique, les appareils clients (ordinateurs de bureau, ordinateurs portables et appareils mobiles) se connectent par Internet à un pare-feu, qui transfère le trafic à un équilibreur de charge. L'équilibreur de charge répartit ensuite les requêtes entre deux nœuds Devolutions Server (ou plus). Par exemple : * Pare-feu : `10.10.10.10` * Équilibreur de charge : `10.11.11.11` * Nœud A de Devolutions Server : `10.12.12.50` * Nœud B de Devolutions Server : `10.12.12.51` ### Considérations clés * **Liste d'autorisation et liste de rejet d'adresses IP** : Ces fonctionnalités nécessitent la validation de l'adresse IP du client afin d'assurer la sécurité et la conformité, généralement avec l'[en-tête X-Forwarded-For](/server/fr/knowledge-base/knowledge-base-articles/x-forwarded-for.md) qui doit être activé dans ***Administration*** – ***Paramètres du serveur*** – ***Sécurité***.\ [Incluez également l'en-tête X-Forwarded-For dans les journaux IIS](/server/fr/knowledge-base/how-to-articles/add-x-forwarded-for-column-in-iis.md) pour assurer un suivi précis des adresses IP des clients.
* **En-têtes de réponse HTTP** : Chaque nœud de serveur devrait ajouter un identifiant unique et non descriptif aux en-têtes des réponses HTTP. Cet identifiant, qui peut être aussi générique que « node1 » ou « node2 », sert à suivre le parcours des requêtes entre les différents serveurs sans divulguer de détails sensibles sur le serveur, comme le nom de domaine complet (FQDN). Cette pratique est essentielle non seulement pour cartographier le parcours des requêtes, mais aussi pour maintenir la sécurité opérationnelle, puisqu'elle limite l'exposition des détails de l'infrastructure qui pourraient être exploités. Les organisations soucieuses d'une sécurité accrue devraient envisager des précautions supplémentaires, comme l'utilisation de valeurs aléatoires ou hachées comme identifiants afin de masquer davantage l'identité des serveurs.\ \ Ceci n'est pas requis pour la fonctionnalité, et chaque équilibreur de charge peut avoir sa propre méthode pour y parvenir. Cependant, identifier le serveur qui a répondu à la requête peut être une étape de dépannage utile.\ \ Veuillez consulter [Identifier le serveur qui répond dans une topologie de haute disponibilité](/server/fr/knowledge-base/how-to-articles/identify-the-server-answering-on-a-high-availability-topology.md) pour plus d'information. ### Architecture #### Équilibreur de charge * **X-Forwarded-For et certificats SSL** : Lors de la mise en place de l'équilibrage des charges, tenez également compte des certificats SSL et de l'en-tête [X-Forwarded-For](/server/fr/knowledge-base/knowledge-base-articles/x-forwarded-for.md).\ Utilisez toute technologie d'équilibrage des charges pouvant ajouter l'en-tête X-Forwarded-For par l'intermédiaire de proxys ou d'appareils intermédiaires. Cet en-tête devrait être retiré s'il est reçu d'un client, et défini uniquement par votre équipement réseau.\ Une configuration adéquate de ces éléments assure des connexions sécurisées et un suivi précis des adresses IP des clients sur plusieurs serveurs. Consultez les considérations clés ci-dessus concernant la liste d'autorisation et la liste de rejet d'adresses IP. * **Règles d'affinité client** : L'attribution de règles d'affinité client garantit que lorsqu'un client se connecte pour la première fois, les requêtes futures provenant du même client sont dirigées vers le même serveur web, ce qui maintient la cohérence. * **Options d'équilibrage des charges** : Si vous n'utilisez pas d'équilibreur de charge virtuel ou matériel dédié devant les serveurs web, l'équilibrage des charges DNS peut être une solution de rechange pratique. Dans cette approche, plusieurs enregistrements DNS (A, AAAA ou CNAME) sont configurés pour le même domaine. Lorsqu'un client se connecte, le fournisseur DNS sélectionne au hasard l'un de ces enregistrements pour répondre.\ Par exemple, si **devolutions-server.mycorp.com** possède deux enregistrements A pointant vers des adresses IP différentes pour chaque serveur web, le DNS répondra avec l'un de ces enregistrements, répartissant ainsi la charge entre les serveurs.\ Cependant, l'équilibrage des charges DNS a ses limites. Comme il n'effectue pas de vérifications d'état, si un serveur tombe en panne, le fournisseur DNS peut tout de même diriger le trafic vers le serveur hors ligne, ce qui entraîne des connexions échouées. Cet exemple est expliqué dans cet [article de Cloudflare sur les enregistrements DNS](https://developers.cloudflare.com/load-balancing/load-balancers/dns-records/). #### Serveurs web / serveurs d'application Dans une configuration typique, deux serveurs sont mis en place avec IIS, chacun exécutant une instance de Devolutions Server. Les considérations clés comprennent le chiffrement, le transfert d'adresses IP, le basculement SQL et la cohérence SSL. * **Synchronisation des clés de chiffrement** : Chaque serveur a besoin de clés de chiffrement correspondantes pour déchiffrer les données de la base de données partagée. Après avoir installé le premier serveur, exportez ses clés de chiffrement et importez-les sur le deuxième serveur afin d'assurer des capacités de déchiffrement adéquates. * **Configuration de X-Forwarded-For** : Configurez l'[en-tête X-Forwarded-For](/server/fr/knowledge-base/knowledge-base-articles/x-forwarded-for.md) afin de conserver une information exacte sur l'adresse IP du client entre les serveurs. Ceci est essentiel à des fins de suivi et de sécurité. Consultez les considérations clés ci-dessus concernant la liste d'autorisation et la liste de rejet d'adresses IP. * **Configuration du basculement de la base de données SQL** : Dans la console Devolutions Server, suivez les étapes ci-dessous pour chaque instance de Devolutions Server. 1. Sélectionnez l'instance Devolutions Server. 2. Allez dans ***Serveur*** – ***Modifier***.
3. Dans ***Base de données***, cliquez sur ***Paramètres avancés***.
4. Cliquez sur ***Plus de paramètres***.
5. Réglez la ***Valeur*** du paramètre ***MultiSubnetFailover*** à ***True***.
6. Cliquez sur ***Ok*** pour enregistrer vos modifications et fermer les fenêtres. Ce paramètre permet à l'application de se connecter à plusieurs serveurs de base de données SQL dans le [groupe de disponibilité Always On](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server), assurant un basculement rapide lorsque nécessaire. * **Assurer la cohérence des certificats SSL** : Puisque les deux serveurs IIS desservent la même URL par l'intermédiaire d'un équilibreur de charge (sauf si vous utilisez IIS ARR avec un DNS à tour de rôle ou un autre mécanisme d'équilibrage des charges), il est essentiel que tous les certificats SSL correspondent et soient correctement desservis dans toute la chaîne. Assurez-vous que l'équilibreur de charge et les deux serveurs IIS possèdent des certificats SSL correspondants afin d'offrir aux clients une connexion sécurisée et unifiée. #### Serveurs de base de données * **Configuration de SQL Servers dans un groupe de disponibilité Always On** : Pour assurer la haute disponibilité, configurez deux Microsoft SQL Servers dans un [groupe de disponibilité Always On](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server). Cette configuration suit un modèle **Actif → Passif** avec un quorum (ou « témoin ») qui surveille l'état des serveurs et déclenche le basculement si un serveur tombe en panne. * **Activation du mode de base de données autonome** : La base de données Devolutions Server doit fonctionner en [mode autonome](https://learn.microsoft.com/en-us/sql/relational-databases/databases/contained-databases), ce qui permet à l'authentification de suivre la base de données au lieu d'être gérée au niveau du serveur. Suivez ces étapes pour activer le mode autonome (peut aussi être fait à l'aide de commandes T-SQL) : 1. Ouvrez Microsoft SQL Server Management Studio. 2. Cliquez avec le bouton droit sur la base de données Devolutions Server et sélectionnez ***Propriétés***. 3. Allez dans ***Options*** et réglez le ***Type de confinement*** à ***Partiel***. Ce paramètre permet aux utilisateurs de la base de données de se déplacer avec celle-ci entre les serveurs du groupe de disponibilité. * **Création d'utilisateurs autonomes** : Avec le mode autonome activé sur la base de données, vous pouvez créer des utilisateurs qui y sont directement liés.\ Il peut s'agir de : * **Utilisateurs SQL avec mots de passe** : Créés spécifiquement dans la base de données autonome. * **Utilisateurs Windows** : Intégrés sans nécessiter une connexion au serveur MSSQL associée à la base de données master. Pour une sécurité accrue, il est recommandé d'utiliser l'authentification Windows plutôt que des utilisateurs SQL avec mots de passe. Gardez toutefois en tête que si vous utilisez des utilisateurs Windows, la fonctionnalité de coffre d'infrastructure de Devolutions Server ne pourra pas gérer ces utilisateurs, puisqu'elle ne prend actuellement en charge que les utilisateurs authentifiés par SQL. * **Client Remote Desktop Manager** : Lorsque vous utilisez le client Remote Desktop Manager avec un serveur Microsoft SQL dans une configuration de haute disponibilité (HA), activez la [configuration de basculement multi-sous-réseaux](https://docs.devolutions.net/rdm/fr/knowledge-base/knowledge-base-articles/sql-server-always-on-availability-groups). Ce paramètre est particulièrement utile pour les installations HA de Microsoft SQL Server et n'est pas requis pour Devolutions Server.\ Pour configurer le basculement multi-sous-réseaux dans RDM : 1. Dans Remote Desktop Manager, allez dans ***Fichier*** – ***Espaces de travail***. 2. Sélectionnez l'espace de travail Microsoft SQL Server dans la liste des espaces de travail, puis cliquez sur ***Modifier l'espace de travail***.
3. Dans l'onglet ***Avancé***, cliquez sur ***Plus de paramètres***.
4. Réglez la ***Valeur*** du paramètre ***MultiSubnetFailover*** à ***True***.
5. Cliquez sur ***Ok*** et ***Enregistrer*** pour enregistrer vos modifications et fermer les fenêtres. Cette configuration permet au client Remote Desktop Manager de gérer plusieurs sous-réseaux, assurant un basculement rapide entre les serveurs SQL dans un environnement de haute disponibilité. ### Processus de vérification * **Validation des courriels** : Vérifiez que tout courriel généré par le système contient le bon URI public, plutôt que le nom du serveur. Ceci peut être vérifié à l'aide de la fonctionnalité de messagerie de Devolutions Server.
* **Historique et tentatives de connexion** : La table ***LoginHistory*** contient l'adresse IP du client, et non celle des serveurs intermédiaires. La table ***LoginAttempts*** répertorie également l'adresse IP, mais il y a davantage de scénarios : * Échecs de connexion (p. ex., mauvais identifiants) * Adresses IP sur la liste de rejet * Adresses IP identifiées comme nœud de sortie 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/fr/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.