> 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

{% 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 de haute disponibilité ou d'équilibrage des charges robuste et sécurisé.

![](https://cdnweb.devolutions.net/docs/docs_en_kb_KB4773.png)

### Considérations importantes

* **Liste d'autorisation et liste de rejet d'IP** : Ces fonctionnalités nécessitent la validation de l'adresse IP du client afin d'assurer la sécurité et la conformité, habituellement 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é***.\
  De plus, [incluez 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.

  <figure><img src="https://cdnweb.devolutions.net/docs/DVLS2044_2024_3.png" alt=""><figcaption></figcaption></figure>
* **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 pourrait être aussi générique que « node1 » ou « node2 », sert à suivre le chemin des requêtes à travers différents serveurs sans divulguer de détails sensibles du serveur comme le nom de domaine complet (FQDN). Cette pratique est essentielle non seulement pour cartographier le parcours de la requête, mais aussi pour maintenir la sécurité opérationnelle, car elle limite l'exposition des détails d'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 dissimuler davantage l'identité des serveurs.\
  \
  Cela 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 l'implémentation 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 IP des clients sur plusieurs serveurs. Consultez les considérations importantes ci-dessus concernant la liste d'autorisation et la liste de rejet d'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 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 choisit 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 IP différentes pour chaque serveur web, le DNS répondra avec l'un de ces enregistrements, répartissant ainsi efficacement la charge entre les serveurs.\
  Cependant, l'équilibrage des charges DNS a ses limites. Comme il n'effectue pas de vérification de l'état de santé, 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 configurés avec IIS, chacun exécutant une instance de Devolutions Server. Les considérations importantes comprennent le chiffrement, le transfert d'IP, le basculement SQL et la cohérence SSL.

* **Synchronisation des clés de chiffrement** : Chaque serveur a besoin de clés de chiffrement identiques pour déchiffrer les données dans 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) pour maintenir des renseignements précis sur l'IP du client entre les serveurs. Cela est essentiel à des fins de suivi et de sécurité. Consultez les considérations importantes ci-dessus concernant la liste d'autorisation et la liste de rejet d'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***.

     <figure><img src="https://cdnweb.devolutions.net/docs/DVLSCONSOLE2010_2024_3.png" alt=""><figcaption></figcaption></figure>
  3. Dans ***Base de données***, cliquez sur ***Paramètres avancés***.

     <figure><img src="https://cdnweb.devolutions.net/docs/DVLSCONSOLE2011_2024_3.png" alt=""><figcaption></figcaption></figure>
  4. Cliquez sur ***Plus de paramètres***.

     <figure><img src="https://cdnweb.devolutions.net/docs/DVLSCONSOLE2012_2024_3.png" alt=""><figcaption></figcaption></figure>
  5. Définissez la ***Valeur*** du paramètre ***MultiSubnetFailover*** à ***True***.

     <figure><img src="https://cdnweb.devolutions.net/docs/DVLSCONSOLE2013_2024_3.png" alt=""><figcaption></figcaption></figure>
  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 (à moins que vous utilisiez IIS ARR avec un DNS à tourniquet 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 ont des certificats SSL correspondants afin de fournir une connexion sécurisée et unifiée aux clients.

#### Serveurs de base de données

* **Configuration des serveurs SQL 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 ») pour surveiller l'état de santé des serveurs et déclencher 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), permettant à l'authentification de suivre la base de données plutôt que 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 définissez 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 avoir besoin d'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. Cependant, gardez à l'esprit que si vous utilisez des utilisateurs Windows, la fonctionnalité de coffre d'infrastructure de Devolutions Server ne pourra pas gérer ces utilisateurs, car elle prend actuellement en charge uniquement les utilisateurs authentifiés par SQL.
* **Client Remote Desktop Manager** : Lorsque vous utilisez le client Remote Desktop Manager avec un Microsoft SQL Server 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 spécifiquement avantageux pour les installations Microsoft SQL Server HA et n'est pas requis pour Devolutions Server.\
  Pour configurer le basculement multi-sous-réseaux dans RDM :

  1. Dans Remote Desktop Manager, naviguez vers ***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***.

     <figure><img src="https://cdnweb.devolutions.net/docs/RDMW2084_2024_3.png" alt=""><figcaption></figcaption></figure>
  3. Dans l'onglet ***Avancé***, cliquez sur ***Plus de paramètres***.

     <figure><img src="https://cdnweb.devolutions.net/docs/RDMW2085_2024_3.png" alt=""><figcaption></figcaption></figure>
  4. Définissez la ***Valeur*** du paramètre ***MultiSubnetFailover*** à ***True***.

     <figure><img src="https://cdnweb.devolutions.net/docs/RDMW2086_2024_3.png" alt=""><figcaption></figcaption></figure>
  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. Cela peut être vérifié à l'aide de la fonctionnalité de messagerie de Devolutions Server.

  <figure><img src="https://cdnweb.devolutions.net/docs/DVLS2045_2024_3.png" alt=""><figcaption></figcaption></figure>
* **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)
  * IP sur la liste de rejet
  * 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=<question>&goal=<endgoal>
```

`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.
