> 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/de/knowledge-base/how-to-articles/deploy-in-a-high-availability-or-load-balancing-environment.md).

# In einer Hochverfügbarkeits- oder Lastverteilungsumgebung bereitstellen

{% hint style="info" %}
Der Inhalt dieses Artikels gilt ausschließlich für Windows-Betriebssysteme.
{% endhint %}

Wenn Sie diese Richtlinien einhalten, können Sie eine robuste und sichere Hochverfügbarkeits- oder Lastausgleichsbereitstellung sicherstellen.

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

### Wichtige Überlegungen

* **IP-Zulassungs- und Sperrlisten**: Diese Funktionen erfordern die Validierung der Client-IP-Adresse, um Sicherheit und Compliance zu gewährleisten, üblicherweise mit dem [X-Forwarded-For-Header](/server/de/knowledge-base/knowledge-base-articles/x-forwarded-for.md), der unter ***Administration*** – ***Server settings*** – ***Security*** aktiviert werden muss.\
  [Nehmen Sie außerdem den X-Forwarded-For-Header in die IIS-Protokolle auf](/server/de/knowledge-base/how-to-articles/add-x-forwarded-for-column-in-iis.md), um eine genaue Nachverfolgung der Client-IP-Adressen zu gewährleisten.

  <figure><img src="https://cdnweb.devolutions.net/docs/DVLS2044_2024_3.png" alt=""><figcaption></figcaption></figure>
* **HTTP-Antwortheader**: Jeder Serverknoten sollte den Headern von HTTP-Antworten eine eindeutige, nicht aussagekräftige Kennung hinzufügen. Diese Kennung, die so allgemein wie "node1" oder "node2" sein kann, dient dazu, den Pfad von Anfragen über verschiedene Server hinweg nachzuverfolgen, ohne sensible Serverdetails wie den vollqualifizierten Domänennamen (FQDN) offenzulegen. Diese Praxis ist nicht nur für die Abbildung des Anfrageverlaufs entscheidend, sondern auch für die Aufrechterhaltung der Betriebssicherheit, da sie die Offenlegung von Infrastrukturdetails begrenzt, die ausgenutzt werden könnten. Organisationen mit erhöhten Sicherheitsanforderungen sollten zusätzliche Vorsichtsmaßnahmen in Erwägung ziehen, etwa die Verwendung randomisierter oder gehashter Werte als Kennungen, um die Serveridentitäten weiter zu verschleiern.\
  \
  Dies ist für die Funktionalität nicht erforderlich, und jeder Load Balancer kann seine eigene Methode dafür haben. Die Identifizierung des Servers, der auf die Anfrage geantwortet hat, kann jedoch ein hilfreicher Schritt bei der Fehlerbehebung sein.\
  \
  Weitere Informationen finden Sie unter [Identify the server answering on a high-availability topology](/server/de/knowledge-base/how-to-articles/identify-the-server-answering-on-a-high-availability-topology.md).

### Architektur

#### Load Balancer

* **X-Forwarded-For und SSL-Zertifikate**: Berücksichtigen Sie bei der Implementierung des Lastausgleichs auch SSL-Zertifikate und den [X-Forwarded-For](/server/de/knowledge-base/knowledge-base-articles/x-forwarded-for.md)-Header.\
  Verwenden Sie eine beliebige Lastausgleichstechnologie, die den X-Forwarded-For-Header über zwischengeschaltete Proxys oder Geräte hinzufügen kann. Dieser Header sollte entfernt werden, wenn er von einem Client empfangen wird, und ausschließlich von Ihrer Netzwerkausrüstung gesetzt werden.\
  Eine ordnungsgemäße Konfiguration dieser Elemente stellt sichere Verbindungen und eine genaue Nachverfolgung der Client-IP über mehrere Server hinweg sicher. Siehe die wichtigen Überlegungen oben zu IP-Zulassungs- und Sperrlisten.
* **Client-Affinitätsregeln**: Die Zuweisung von Client-Affinitätsregeln stellt sicher, dass bei der ersten Verbindung eines Clients zukünftige Anfragen desselben Clients an denselben Webserver geleitet werden, wodurch Konsistenz gewahrt bleibt.
* **Lastausgleichsoptionen**: Wenn Sie keinen dedizierten virtuellen oder hardwarebasierten Load Balancer vor den Webservern verwenden, kann DNS-Lastausgleich eine praktische Alternative sein. Bei diesem Ansatz werden mehrere DNS-Einträge (A, AAAA oder CNAME) für dieselbe Domäne konfiguriert. Wenn ein Client eine Verbindung herstellt, wählt der DNS-Anbieter zufällig einen dieser Einträge aus, um zu antworten.\
  Wenn beispielsweise **devolutions-server.mycorp.com** zwei A-Einträge besitzt, die auf unterschiedliche IPs für jeden Webserver verweisen, antwortet das DNS mit einem dieser Einträge und verteilt so die Last effektiv auf die Server.\
  DNS-Lastausgleich hat jedoch Einschränkungen. Da er keine Gesundheitsprüfungen bietet, kann der DNS-Anbieter bei einem Serverausfall weiterhin Datenverkehr an den offline befindlichen Server leiten, was zu fehlgeschlagenen Verbindungen führt. Dieses Beispiel wird in diesem [Cloudflare-Artikel zu DNS-Einträgen](https://developers.cloudflare.com/load-balancing/load-balancers/dns-records/) erläutert.

#### Webserver / Anwendungsserver

In einer typischen Konfiguration werden zwei Server mit IIS eingerichtet, auf denen jeweils eine Instanz von Devolutions Server läuft. Zu den wichtigsten Überlegungen gehören Verschlüsselung, IP-Weiterleitung, SQL-Failover und SSL-Konsistenz.

* **Synchronisierung der Verschlüsselungsschlüssel**: Jeder Server benötigt übereinstimmende Verschlüsselungsschlüssel, um Daten in der gemeinsam genutzten Datenbank zu entschlüsseln. Exportieren Sie nach der Installation des ersten Servers dessen Verschlüsselungsschlüssel und importieren Sie sie auf den zweiten Server, um die ordnungsgemäße Entschlüsselungsfähigkeit sicherzustellen.
* **Konfiguration von X-Forwarded-For**: Richten Sie den [X-Forwarded-For-Header](/server/de/knowledge-base/knowledge-base-articles/x-forwarded-for.md) ein, um genaue Client-IP-Informationen über alle Server hinweg beizubehalten. Dies ist für Nachverfolgungs- und Sicherheitszwecke unerlässlich. Siehe die wichtigen Überlegungen oben zu IP-Zulassungs- und Sperrlisten.
* **Konfiguration des SQL-Datenbank-Failovers**: Führen Sie in der Devolutions Server Console die folgenden Schritte für jede Instanz von Devolutions Server aus.

  1. Wählen Sie die Devolutions Server-Instanz aus.
  2. Gehen Sie zu ***Server*** – ***Edit***.

     <figure><img src="https://cdnweb.devolutions.net/docs/DVLSCONSOLE2010_2024_3.png" alt=""><figcaption></figcaption></figure>
  3. Klicken Sie in ***Database*** auf ***Advanced settings***.

     <figure><img src="https://cdnweb.devolutions.net/docs/DVLSCONSOLE2011_2024_3.png" alt=""><figcaption></figcaption></figure>
  4. Klicken Sie auf ***More settings***.

     <figure><img src="https://cdnweb.devolutions.net/docs/DVLSCONSOLE2012_2024_3.png" alt=""><figcaption></figcaption></figure>
  5. Setzen Sie den ***Value*** der Einstellung ***MultiSubnetFailover*** auf ***True***.

     <figure><img src="https://cdnweb.devolutions.net/docs/DVLSCONSOLE2013_2024_3.png" alt=""><figcaption></figcaption></figure>
  6. Klicken Sie auf ***Ok***, um Ihre Änderungen zu speichern und die Fenster zu schließen.

  Diese Einstellung ermöglicht der Anwendung, sich mit mehreren SQL-Datenbankservern in der [Always On-Verfügbarkeitsgruppe](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server) zu verbinden, wodurch bei Bedarf ein schnelles Failover gewährleistet wird.
* **Sicherstellung der Konsistenz der SSL-Zertifikate**: Da beide IIS-Server dieselbe URL über einen Load Balancer bereitstellen (sofern Sie nicht IIS ARR mit DNS-Round-Robin oder einem anderen Lastausgleichsverfahren verwenden), ist es entscheidend, dass alle SSL-Zertifikate übereinstimmen und über die gesamte Kette hinweg ordnungsgemäß bereitgestellt werden. Stellen Sie sicher, dass der Load Balancer und beide IIS-Server übereinstimmende SSL-Zertifikate besitzen, um eine sichere, einheitliche Verbindung für Clients bereitzustellen.

#### Datenbankserver

* **Einrichtung von SQL Servern in einer Always On-Verfügbarkeitsgruppe**: Um Hochverfügbarkeit sicherzustellen, konfigurieren Sie zwei Microsoft SQL Server in einer [Always On-Verfügbarkeitsgruppe](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server). Dieses Setup folgt einem **Aktiv → Passiv**-Modell mit einem Quorum (oder "Witness"), das den Serverzustand überwacht und ein Failover auslöst, wenn ein Server ausfällt.
* **Aktivierung des Contained-Datenbankmodus**: Die Devolutions Server-Datenbank muss im [Contained-Modus](https://learn.microsoft.com/en-us/sql/relational-databases/databases/contained-databases) betrieben werden, wodurch die Authentifizierung mit der Datenbank mitwandert, anstatt auf Serverebene verwaltet zu werden. Führen Sie die folgenden Schritte aus, um den Contained-Modus zu aktivieren (kann auch über T-SQL-Befehle erfolgen):

  1. Öffnen Sie Microsoft SQL Server Management Studio.
  2. Klicken Sie mit der rechten Maustaste auf die Devolutions Server-Datenbank und wählen Sie ***Properties***.
  3. Gehen Sie zu ***Options*** und setzen Sie den ***Containment type*** auf ***Partial***.

  Diese Einstellung ermöglicht es Datenbankbenutzern, mit der Datenbank über die Server in der Verfügbarkeitsgruppe hinweg zu wandern.
* **Erstellen von Contained-Benutzern**: Wenn der Contained-Modus für die Datenbank aktiviert ist, können Sie Benutzer erstellen, die direkt mit ihr verknüpft sind.\
  Dies können sein:

  * **SQL-Benutzer mit Passwörtern**: Speziell innerhalb der Contained-Datenbank erstellt.
  * **Windows-Benutzer**: Integriert, ohne dass eine MSSQL-Serveranmeldung erforderlich ist, die mit der Master-Datenbank verknüpft ist.

  Für erhöhte Sicherheit wird empfohlen, die Windows-Authentifizierung anstelle von SQL-Benutzern mit Passwörtern zu verwenden. Beachten Sie jedoch, dass die Infrastruktur-Tresor-Funktion von Devolutions Server diese Benutzer nicht verwalten kann, wenn Sie Windows-Benutzer verwenden, da sie derzeit nur SQL-authentifizierte Benutzer unterstützt.
* **Remote Desktop Manager-Client**: Wenn Sie den Remote Desktop Manager-Client mit einem Microsoft SQL Server in einem Hochverfügbarkeits-Setup (HA) verwenden, aktivieren Sie die [Multi-Subnet-Failover-Konfiguration](https://docs.devolutions.net/rdm/de/knowledge-base/knowledge-base-articles/sql-server-always-on-availability-groups). Diese Einstellung ist speziell für Microsoft SQL Server-HA-Installationen von Vorteil und für Devolutions Server nicht erforderlich.\
  So konfigurieren Sie Multi-Subnet-Failover in RDM:

  1. Navigieren Sie in Remote Desktop Manager zu ***File*** – ***Workspaces***.
  2. Wählen Sie die Microsoft SQL Server-Datenquelle in der Datenquellenliste aus und klicken Sie dann auf ***Edit workspace***.

     <figure><img src="https://cdnweb.devolutions.net/docs/RDMW2084_2024_3.png" alt=""><figcaption></figcaption></figure>
  3. Klicken Sie auf der Registerkarte ***Advanced*** auf ***More settings***.

     <figure><img src="https://cdnweb.devolutions.net/docs/RDMW2085_2024_3.png" alt=""><figcaption></figcaption></figure>
  4. Setzen Sie den ***Value*** der Einstellung ***MultiSubnetFailover*** auf ***True***.

     <figure><img src="https://cdnweb.devolutions.net/docs/RDMW2086_2024_3.png" alt=""><figcaption></figcaption></figure>
  5. Klicken Sie auf ***Ok*** und ***Save***, um Ihre Änderungen zu speichern und die Fenster zu schließen.

  Diese Konfiguration ermöglicht dem Remote Desktop Manager-Client den Umgang mit mehreren Subnetzen und gewährleistet ein schnelles Failover zwischen SQL-Servern in einer Hochverfügbarkeitsumgebung.

### Überprüfungsprozess

* **E-Mail-Validierung**: Überprüfen Sie, dass jede systemgenerierte E-Mail die korrekte öffentliche URI enthält und nicht den Namen des Servers. Dies kann mit der Nachrichtenfunktion von Devolutions Server überprüft werden.

  <figure><img src="https://cdnweb.devolutions.net/docs/DVLS2045_2024_3.png" alt=""><figcaption></figcaption></figure>
* **Anmeldeverlauf und Anmeldeversuche**: Die Tabelle ***LoginHistory*** enthält die IP-Adresse des Clients, nicht die zwischengeschalteten Server. Die Tabelle ***LoginAttempts*** listet ebenfalls die IP-Adresse auf, allerdings gibt es hier weitere Szenarien:
  * Anmeldefehler (z. B. falsche Anmeldeinformationen)
  * Gesperrte IPs
  * Als TOR-Exit-Knoten identifizierte IPs


---

# 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/de/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.
