Når systemer ligger i to eller flere miljøer, skal de kunne tale sammen, og brugerne skal kunne logge ind ét sted. Det kræver tre ting: en netforbindelse mellem miljøerne, navneopslag, der virker på tværs, og en identitet, der gælder begge steder. De tre ting er det, der gør hybrid drift mulig, og de mangler ofte i regnestykket.
Det gælder både, når hybrid er en overgang under et skifte, og når det er det varige mål. Hvornår det ene eller det andet er rigtigt, står i hybrid cloud. Her står det, der binder miljøerne sammen.
Netforbindelsen
Der er to hovedformer.
VPN over internettet. En krypteret tunnel mellem miljøerne, sat op mellem firewalls eller med en VPN-tjeneste hos udbyderen. Den er hurtig at etablere og afhænger af internetforbindelsen i begge ender. Svartid og båndbredde kan variere.
Fast forbindelse. En dedikeret linje eller et privat net mellem jeres lokation og udbyderens datacenter, ofte gennem en teleoperatør eller et knudepunkt i et datacenter. Den giver mere stabil svartid og båndbredde og tager længere tid at bestille og etablere. Der er flere parter involveret: jer, operatøren og udbyderen.
Valget afhænger af, hvad der skal over forbindelsen. Brugertrafik til et program kan ofte nøjes med VPN. Replikering af databaser, backup af store mængder og systemer, der kalder hinanden tit, kan kræve fast forbindelse. Nogle platforme stiller selv krav. Proxmox anbefaler fx, at klyngenettet har lav og stabil svartid og ligger på et særskilt fysisk net. En klynge kan derfor ikke uden videre strækkes over en VPN mellem to steder.
Adresser og navneopslag
To miljøer, der skal tale sammen, må ikke bruge de samme interne adresseområder. Overlap kan først blive opdaget, når forbindelsen sættes op, og kan kræve, at adresser ændres i et af miljøerne. Lav en adresseplan for alle miljøer, før forbindelsen bestilles.
Navneopslag skal virke på tværs. Et system i cloud skal kunne slå navne op på servere i eget miljø og omvendt. Det kræver, at DNS-servere i begge miljøer kender hinanden, eller at der er en fælles løsning. DNS i forbindelse med et skifte står i DNS, CDN og DDoS.
Identitet
Én identitet bør gælde for brugere og systemer på begge sider. Ellers opstår der to sæt brugere, to sæt rettigheder og to steder at lukke adgang, når en medarbejder stopper.
Typisk ligger identiteten ét sted, og det andet miljø stoler på den. Det binder: det miljø, der har identiteten, bliver en forudsætning for det andet. Ligger identiteten hos den udbyder, I er på vej væk fra, flytter afhængigheden ikke med serverne. Login som afhængighed set fra exit-planen står på exit-plan.dk om login og to-faktor.
Åbne løsninger findes. Keycloak er fx et open source-system til identitet og adgangsstyring under Apache 2.0 og et projekt i Cloud Native Computing Foundation. Der er ingen leverandør bag i traditionel forstand, så drift og support er brugerens eller en partners. Det er et eksempel på en byggesten pr. november 2026 og ikke en anbefaling.
Forbindelser, der er indbygget i platformen
Nogle platforme forudsætter selv en forbindelse. Microsofts Azure Local skal fx have forbindelse til Azure med højst en måneds mellemrum, fordi faktureringen sker dér. Microsoft angiver grænsen til 30 dage. Et miljø, der står hos jer, kan altså stadig være afhængigt af en forbindelse til udbyderen. Læs platformens krav til forbindelse, før miljøet planlægges som selvstændigt.
Når forbindelsen går ned
Planen skal svare på, hvad der sker, hvis forbindelsen mellem miljøerne afbrydes. Hvilke systemer holder op med at virke? Kan brugerne stadig logge ind? Kører replikeringen videre, når forbindelsen kommer igen, eller skal den startes forfra? Svarene afgør, om der skal en reserveforbindelse til, og om identiteten skal kunne virke lokalt i begge miljøer.
Hvad det kræver, og hvad det koster at lade være
Forbindelsen kræver en adresseplan, en netforbindelse med eventuel reserve, navneopslag på tværs, en fælles identitet og overvågning af det hele. Overslaget gives i uger, fordi faste forbindelser har leveringstid. Posterne er linjen eller VPN-tjenesten, udgående data mellem miljøerne, som kan afregnes hos udbyderen, firewalls, identitetsløsning og egne timer. Satserne er jeres egne.
Mangler forbindelsen i regnestykket, ser hybrid drift billigere ud, end den er. Opdages kravet sent, forsinker det hele skiftet, fordi en fast forbindelse ikke kan bestilles fra dag til dag.
Det skal I lade være med
- At bestille forbindelsen sidst · leveringstiden kan blive det, der bestemmer tidsplanen.
- At strække en klynge over en forbindelse, producenten ikke anbefaler · klyngenettet stiller krav til svartid.
- At lade identiteten blive hos den udbyder, I forlader, uden en beslutning · afhængigheden bliver så stående.
Det skal valget kunne vise
- ☐ En adresseplan uden overlap for alle miljøer.
- ☐ Forbindelsestype, båndbredde og reserve mellem miljøerne.
- ☐ Hvor identiteten ligger, og hvad der sker, hvis forbindelsen afbrydes.
- ☐ Udgående data mellem miljøerne, beskrevet som post i ord.
Kilder
- Proxmox VE wiki, Cluster Manager: https://pve.proxmox.com/wiki/Cluster_Manager
- Microsoft Learn, Azure Local billing: https://learn.microsoft.com/en-us/azure/azure-local/concepts/billing
- Keycloak: https://www.keycloak.org/
Senest gennemgået: november 2026.
Næste skridt
Tegn de miljøer, I har eller planlægger, og skriv forbindelse, adresseområde og identitet på hver streg mellem dem.
Læs også: Overvågning og logs · Rækkefølgen i infrastrukturen
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
