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

# Udrul i et miljø med høj tilgængelighed eller belastningsfordeling

Udrul Devolutions Server i et miljø med høj tilgængelighed eller belastningsfordeling på Windows, herunder videresendelse af IP, synkronisering af krypteringsnøgler og SQL-failover.

{% hint style="info" %}
Indholdet af denne artikel gælder udelukkende for Windows-operativsystemer.
{% endhint %}

Ved at følge disse retningslinjer kan De sikre en robust og sikker udrulning med høj tilgængelighed eller belastningsfordeling.

I en typisk opsætning opretter klientenheder (stationære computere, bærbare computere og mobile enheder) forbindelse via internettet til en firewall, som videresender trafikken til en belastningsfordeler. Belastningsfordeleren fordeler derefter anmodninger på to (eller flere) Devolutions Server-knuder. For eksempel:

* Firewall: `10.10.10.10`
* Belastningsfordeler: `10.11.11.11`
* Devolutions Server-knude A: `10.12.12.50`
* Devolutions Server-knude B: `10.12.12.51`

### Vigtige overvejelser

* **Tilladelsesliste og blokeringsliste for IP**: Disse funktioner kræver validering af klientens IP-adresse for at sikre sikkerhed og efterlevelse, normalt med [headeren X-Forwarded-For](/server/da/knowledge-base/knowledge-base-articles/x-forwarded-for.md), som skal aktiveres under ***Administration*** – ***Serverindstillinger*** – ***Sikkerhed***.\
  [Medtag også headeren X-Forwarded-For i IIS-loggene](/server/da/knowledge-base/how-to-articles/add-x-forwarded-for-column-in-iis.md) for at sikre nøjagtig sporing af klienternes IP-adresser.
* **HTTP-svarheadere**: Hver serverknude bør føje en entydig, ikke-beskrivende identifikator til headerne i HTTP-svar. Identifikatoren, som kan være så generisk som "node1" eller "node2", bruges til at spore anmodningens vej på tværs af forskellige servere uden at afsløre følsomme serveroplysninger som det fuldt kvalificerede domænenavn (FQDN). Denne praksis er afgørende, både for at kortlægge anmodningens rejse og for at opretholde driftssikkerheden, fordi den begrænser eksponeringen af infrastrukturdetaljer, der kan udnyttes. Organisationer med skærpet sikkerhed bør overveje yderligere forholdsregler, f.eks. at bruge tilfældige eller hashede værdier som identifikatorer for yderligere at sløre serveridentiteter.\
  \
  Det er ikke påkrævet for funktionaliteten, og hver belastningsfordeler kan have sin egen metode til at opnå det. Det kan dog være et nyttigt fejlfindingstrin at identificere den server, der svarede på anmodningen.\
  \
  Følg [Identificer den server, der svarer i en topologi med høj tilgængelighed](/server/da/knowledge-base/how-to-articles/identify-the-server-answering-on-a-high-availability-topology.md) for at få flere oplysninger.

### Arkitektur

#### Belastningsfordeler

* **X-Forwarded-For og SSL-certifikater**: Når belastningsfordeling implementeres, skal der også tages højde for SSL-certifikater og headeren [X-Forwarded-For](/server/da/knowledge-base/knowledge-base-articles/x-forwarded-for.md).\
  Brug en vilkårlig belastningsfordelingsteknologi, der kan tilføje headeren X-Forwarded-For via mellemliggende proxyer eller enheder. Headeren bør fjernes, hvis den modtages fra en klient, og kun angives af netværksudstyret.\
  Korrekt konfiguration af disse elementer sikrer sikre forbindelser og nøjagtig sporing af klientens IP på tværs af flere servere. Se de vigtige overvejelser ovenfor om tilladelsesliste og blokeringsliste for IP.
* **Regler for klienttilhørsforhold**: Tildeling af regler for klienttilhørsforhold sikrer, at når en klient først opretter forbindelse, sendes senere anmodninger fra den samme klient til den samme webserver, så sammenhængen bevares.
* **Valgmuligheder for belastningsfordeling**: Hvis De ikke bruger en dedikeret virtuel eller hardwarebaseret belastningsfordeler foran webserverne, kan DNS-belastningsfordeling være et praktisk alternativ. I denne fremgangsmåde konfigureres flere DNS-poster (A, AAAA eller CNAME) for det samme domæne. Når en klient opretter forbindelse, vælger DNS-udbyderen en af disse poster tilfældigt at svare med.\
  Hvis **devolutions-server.mycorp.com** f.eks. har to A-poster, der peger på forskellige IP-adresser for hver webserver, svarer DNS med en af disse poster og fordeler dermed belastningen på serverne.\
  DNS-belastningsfordeling har dog begrænsninger. Da den ikke har sundhedskontroller, kan DNS-udbyderen stadig sende trafik til den offline server, hvis en server går ned, hvilket giver mislykkede forbindelser. Eksemplet forklares i denne [artikel om DNS-poster hos Cloudflare](https://developers.cloudflare.com/load-balancing/load-balancers/dns-records/).

#### Webservere/programservere

I en typisk konfiguration konfigureres to servere med IIS, som hver kører en instans af Devolutions Server. Vigtige overvejelser omfatter kryptering, videresendelse af IP, SQL-failover og ensartede SSL-certifikater.

* **Synkronisering af krypteringsnøgler**: Hver server kræver matchende krypteringsnøgler for at dekryptere data i den delte database. Når den første server er installeret, skal De eksportere dens krypteringsnøgler og importere dem på den anden server for at sikre korrekt dekryptering.
* **Konfiguration af X-Forwarded-For**: Konfigurer [headeren X-Forwarded-For](/server/da/knowledge-base/knowledge-base-articles/x-forwarded-for.md) for at bevare nøjagtige oplysninger om klientens IP på tværs af servere. Det er vigtigt af hensyn til sporing og sikkerhed. Se de vigtige overvejelser ovenfor om tilladelsesliste og blokeringsliste for IP.
* **Konfiguration af SQL-databasefailover**: I Devolutions Server Console skal De følge trinnene nedenfor for hver instans af Devolutions Server.

  1. Vælg Devolutions Server-instansen.
  2. Gå til ***Server*** – ***Rediger***.
  3. Under ***Database*** skal De klikke på ***Avancerede indstillinger***.
  4. Klik på ***Flere indstillinger***.
  5. Angiv ***Værdi*** for indstillingen ***MultiSubnetFailover*** til ***True***.
  6. Klik på ***Ok*** for at gemme ændringerne og lukke vinduerne.

  Denne indstilling gør det muligt for programmet at oprette forbindelse til flere SQL-databaseservere i [Always On-tilgængelighedsgruppen](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server) og sikrer hurtig failover, når det er nødvendigt.
* **Ensartede SSL-certifikater**: Da begge IIS-servere betjener den samme URL-adresse via en belastningsfordeler (medmindre De bruger IIS ARR med DNS-round-robin eller en anden ordning for belastningsfordeling), er det afgørende, at alle SSL-certifikater matcher og betjenes korrekt i hele kæden. Sørg for, at belastningsfordeleren og begge IIS-servere har matchende SSL-certifikater, så klienterne får en sikker, samlet forbindelse.

#### Databaseservere

* **Opsætning af SQL Server i en Always On-tilgængelighedsgruppe**: For at sikre høj tilgængelighed skal De konfigurere to Microsoft SQL Server i en [Always On-tilgængelighedsgruppe](https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server). Opsætningen følger en **Active → Passive**-model med et kvorum (eller et "vidne"), der overvåger serverens tilstand og udløser failover, hvis en server går ned.
* **Aktivering af tilstanden indeholdt database**: Databasen til Devolutions Server skal køre i [indeholdt tilstand](https://learn.microsoft.com/en-us/sql/relational-databases/databases/contained-databases), så godkendelsen følger med databasen i stedet for at blive administreret på serverniveau. Følg disse trin for at aktivere indeholdt tilstand (det kan også gøres med T-SQL-kommandoer):

  1. Åbn Microsoft SQL Server Management Studio.
  2. Højreklik på databasen til Devolutions Server, og vælg ***Egenskaber***.
  3. Gå til ***Indstillinger***, og angiv ***Indeslutningstype*** til ***Delvis***.

  Denne indstilling lader databasebrugere flytte med databasen på tværs af servere i tilgængelighedsgruppen.
* **Oprettelse af indeholdte brugere**: Når indeholdt tilstand er aktiveret på databasen, kan De oprette brugere, der er knyttet direkte til den.\
  Det kan være:

  * **SQL-brugere med adgangskoder**: Oprettet specifikt i den indeholdte database.
  * **Windows-brugere**: Integreret uden at der kræves et MSSQL-serverlogon, der er knyttet til master-databasen.

  Af hensyn til sikkerheden anbefales det at bruge Windows-godkendelse i stedet for SQL-brugere med adgangskoder. Vær dog opmærksom på, at hvis De bruger Windows-brugere, kan infrastrukturboksen i Devolutions Server ikke administrere disse brugere, da den i øjeblikket kun understøtter SQL-godkendte brugere.
* **Klient til Remote Desktop Manager**: Når De bruger klienten til Remote Desktop Manager med en Microsoft SQL Server i en opsætning med høj tilgængelighed (HA), skal De aktivere [konfigurationen af failover på flere undernet](https://docs.devolutions.net/rdm/knowledge-base/knowledge-base-articles/sql-server-always-on-availability-groups). Indstillingen er særligt nyttig ved HA-installationer af Microsoft SQL Server og er ikke påkrævet for Devolutions Server.\
  Sådan konfigureres Multi-Subnet Failover i RDM:

  1. I Remote Desktop Manager skal De gå til ***Filer*** – ***Arbejdsområder***.
  2. Vælg arbejdsområdet Microsoft SQL Server på listen over arbejdsområder, og klik derefter på ***Rediger arbejdsområde***.
  3. På fanen ***Avanceret*** skal De klikke på ***Flere indstillinger***.
  4. Angiv ***Værdi*** for indstillingen ***MultiSubnetFailover*** til ***True***.
  5. Klik på ***Ok*** og ***Gem*** for at gemme ændringerne og lukke vinduerne.

  Denne konfiguration lader klienten til Remote Desktop Manager håndtere flere undernet og sikrer hurtig failover mellem SQL-servere i et miljø med høj tilgængelighed.

### Verifikationsproces

* **Validering af e-mail**: Kontrollér, at enhver systemgenereret e-mail indeholder den korrekte offentlige URI og ikke serverens navn. Det kan kontrolleres med meddelelsesfunktionen i Devolutions Server.
* **Logonhistorik og forsøg**: Tabellen ***LoginHistory*** indeholder IP-adressen for klienten, ikke for eventuelle mellemliggende servere. Tabellen ***LoginAttempts*** angiver også IP-adressen, men der er flere scenarier:
  * Mislykkede logon (f.eks. forkerte legitimationsoplysninger)
  * IP-adresser på blokeringslisten
  * IP-adresser, der er identificeret som en TOR-udgangsknude


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.