> 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 d'équilibrage de charge

{% 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 avec équilibrage de charge.

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

### Considérations clés

* **Liste d'autorisation et liste de blocage d'adresses IP** : Ces fonctionnalités nécessitent la validation de l'adresse IP du client pour assurer la sécurité et la conformité, généralement à l'aide de l'[en-tête X-Forwarded-For](https://docs.devolutions.net/fr/server/kb/knowledge-base/use-x-forwarded-for/) qui doit être activé dans ***Administration*** – ***Paramètres du serveur*** – ***Sécurité***.\
  Veuillez également [inclure l'en-tête X-Forwarded-For dans les journaux IIS](https://docs.devolutions.net/fr/server/kb/how-to-articles/add-x-forwarded-for-column-iis/) 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 doit 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 chemin des requêtes à travers différents serveurs sans divulguer de détails sensibles sur le serveur, tels que le nom de domaine pleinement qualifié (FQDN). Cette pratique est essentielle non seulement pour cartographier le parcours des requêtes, mais aussi pour maintenir la sécurité opérationnelle, car elle limite l'exposition des détails d'infrastructure pouvant être exploités. Les organisations axées sur une sécurité renforcée devraient envisager des précautions supplémentaires, comme l'utilisation de valeurs aléatoires ou hachées comme identifiants pour masquer 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é](https://docs.devolutions.net/fr/server/kb/how-to-articles/identify-server-answering/) pour plus d'informations.

### Architecture

#### Équilibreur de charge

* **X-Forwarded-For et certificats SSL** : Lors de la mise en œuvre de l'équilibrage de charge, tenez également compte des certificats SSL et de l'en-tête [X-Forwarded-For](https://docs.devolutions.net/fr/server/kb/knowledge-base/use-x-forwarded-for/).\
  Utilisez toute technologie d'équilibrage de charge capable d'ajouter l'en-tête X-Forwarded-For via des proxys ou des équipements intermédiaires. Cet en-tête doit être supprimé s'il est reçu d'un client, et uniquement défini par votre équipement réseau.\
  Une configuration adéquate de ces éléments garantit 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 blocage 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 ultérieures de ce même client sont dirigées vers le même serveur Web, assurant ainsi la cohérence.
* **Options d'équilibrage de charge** : Si vous n'utilisez pas d'équilibreur de charge virtuel ou matériel dédié devant les serveurs Web, l'équilibrage de charge DNS peut être une alternative 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 aléatoirement 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, distribuant ainsi efficacement la charge sur les serveurs.\
  Cependant, l'équilibrage de charge DNS présente des limitations. Comme il ne dispose pas de vérifications de l'état, si un serveur tombe en panne, le fournisseur DNS peut tout de même diriger le trafic vers le serveur hors ligne, entraînant des échecs de connexion. Cet exemple est expliqué dans cet [article Cloudflare sur les enregistrements DNS](https://developers.cloudflare.com/load-balancing/load-balancers/dns-records/).

#### Serveurs Web / serveurs d'applications

Dans une configuration standard, deux serveurs sont configurés avec IIS, chacun exécutant une instance de Devolutions Server. Les considérations clés incluent le chiffrement, la transmission des adresses IP, le basculement SQL et la cohérence SSL.

* **Synchronisation des clés de chiffrement** : Chaque serveur nécessite des 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 second serveur pour assurer les capacités de déchiffrement appropriées.
* **Configuration de X-Forwarded-For** : Configurez l'[en-tête X-Forwarded-For](https://docs.devolutions.net/fr/server/kb/knowledge-base/use-x-forwarded-for/) pour maintenir des informations précises sur l'adresse IP du client à travers les serveurs. Cela 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 blocage d'adresses IP.
* **Configuration du basculement de 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. Accédez à ***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 si nécessaire.
* **Assurer la cohérence des certificats SSL** : Étant donné que les deux serveurs IIS servent la même URL via un équilibreur de charge (sauf si vous utilisez IIS ARR avec un DNS round-robin ou un autre schéma d'équilibrage de charge), il est crucial que tous les certificats SSL correspondent et soient correctement servis tout au long de la chaîne. Assurez-vous que l'équilibreur de charge et les deux serveurs IIS disposent de certificats SSL correspondants pour 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 des serveurs et déclencher le basculement si l'un d'eux 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 voyager avec 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 également être effectué à l'aide de commandes T-SQL) :

  1. Ouvrez Microsoft SQL Server Management Studio.
  2. Faites un clic droit sur la base de données Devolutions Server et sélectionnez ***Propriétés***.
  3. Accédez à ***Options*** et définissez le ***Type de relation contenant-contenu*** à ***Partiel***.

  Ce paramètre permet aux utilisateurs de la base de données de se déplacer avec la base de données 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 directement liés à celle-ci.\
  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é renforcée, 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 sera pas en mesure de gérer ces utilisateurs, car elle ne prend actuellement en charge que les utilisateurs authentifiés par SQL.
* **Client Remote Desktop Manager** : Lors de l'utilisation du client Remote Desktop Manager avec un Microsoft SQL Server dans une configuration de haute disponibilité (HA), activez la [configuration de basculement multi-sous-réseau](https://docs.devolutions.net/fr/rdm/kb/knowledge-base/sql-server-always-on-availability-groups/). Ce paramètre est spécifiquement bénéfique pour les installations HA de Microsoft SQL Server et n'est pas requis pour Devolutions Server.\
  Pour configurer le basculement multi-sous-réseau dans RDM :

  1. Dans Remote Desktop Manager, accédez à ***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 l'URI public correct, 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 des connexions et tentatives** : 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 couvre davantage de scénarios :
  * Échecs de connexion (par exemple, identifiants incorrects)
  * Adresses IP bloquées
  * 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:

```
GET https://docs.devolutions.net/server/fr/knowledge-base/how-to-articles/deploy-in-a-high-availability-or-load-balancing-environment.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.
