Aktiv-aktiv høj tilgængelighed (HA) i Semaphore UI

Introduktion #

Mange automatiseringsplatforme starter med en enkelt-knude-arkitektur (single-node). Én proces betjener brugerfladen, udfører opgaver, administrerer tidsplaner og håndterer opdateringer i realtid. Selvom denne opsætning er enkel, skaber den også et enkelt fejlpunkt (single point of failure). Hvis den pågældende proces stopper, stopper automatiseringen også.

For organisationer, der driver infrastrukturautomatisering i stor skala — især i DevOps- eller platform engineering-miljøer — kan nedetid for automatiseringssystemet blive en alvorlig driftsrisiko.

Det er her, Aktiv-Aktiv Høj Tilgængelighed (Active-Active High Availability - HA) kommer ind i billedet. Semaphore UI understøtter en arkitektur, hvor flere instanser kører samtidigt og deler arbejdsbelastningen. Dette sikrer, at automatiseringen fortsætter, selvom individuelle knuder fejler, samtidig med at det muliggør horisontal skalering.

Problemet med automatisering på en enkelt knude #

I en standardudrulning udfører én enkelt Semaphore UI-proces alle kerneopgaver:

• Betjener web-UI
• Håndterer API-anmodninger
• Udfører planlagte opgaver
• Kører automatiseringsopgaver
• Sender realtidsopdateringer til browseren

Denne arkitektur fungerer fint for små teams eller testmiljøer. Men den introducerer en kritisk begrænsning: Hvis den enkelte proces går ned, bliver hele systemet utilgængeligt. For produktionsmiljøer med mange brugere og automatiserede arbejdsgange skaber dette risici såsom:

• Afbrudte udrulninger
• Mislykkede planlagte opgaver
• Tab af operationel synlighed
• Nedetid under vedligeholdelse

For at eliminere denne flaskehals understøtter Semaphore UI aktiv-aktiv udrulning med høj tilgængelighed.

Hvad er aktiv-aktiv HA i Semaphore UI? #

I en aktiv-aktiv HA-arkitektur kører flere identiske Semaphore UI-instanser samtidigt bag en belastningsfordeler (load balancer). I modsætning til traditionelle failover-systemer er der ingen primær- eller standby-knude. Hver eneste instans er fuldt ud i stand til at håndtere UI-anmodninger, API-kald, planlagte opgaver og opgaveudførelse.

Trafikken fordeles over klyngen, og hvis én instans fejler, fortsætter de andre med at betjene anmodninger uden afbrydelse. Denne arkitektur forbedrer både systemets pålidelighed og udførelsesskalerbarheden.

Overordnet arkitektur #

En typisk aktiv-aktiv udrulning består af flere nøglekomponenter:

1. Belastningsfordeler (Load Balancer). Brugere opretter forbindelse via en belastningsfordeler såsom NGINX, HAProxy eller cloud-belastningsfordelere. Belastningsfordeleren distribuerer HTTP- og WebSocket-trafik over tilgængelige Semaphore-knuder.
2. Semaphore-knuder. Hver knude kører en identisk instans af Semaphore UI. Enhver knude kan modtage brugeranmodninger, starte automatiseringsopgaver, behandle planlagte opgaver og sende opdateringer i realtid. Da alle knuder er lige, har systemet intet enkelt fejlpunkt på applikationslaget.
3. Delt database. Alle instanser forbinder til en delt database som PostgreSQL eller MySQL. Databasen fungerer som den eneste sandhedskilde for persistente data, herunder: projekter, skabeloner, inventories, tidsplaner, opgavehistorik, brugerkonti og RBAC-konfiguration.
4. Redis-koordineringslag. Redis leverer koordineringslaget, der gør det muligt for flere knuder at opføre sig som et samlet system. Det udfylder tre vigtige funktioner:

• Distribuerede låse (Distributed Locks) sikrer, at kun én instans udfører et job eller trin ad gangen. Uden distribueret låsning kunne flere knuder forsøge at køre den samme opgave samtidigt.
• Delt opgavekø-tilstand. Redis vedligeholder opgavekøen, så jobs samles op af præcis én worker. Alle knuder ser den samme kø og koordinerer opgaveudførelsen.
• Pub/Sub-meddelelser gør det muligt for knuder at broadcaste begivenheder såsom opgaveopdateringer, klyngenotifikationer, cache-invalidering og UI-tilstandsopdateringer. Dette holder alle knuder synkroniseret i realtid.

Hvordan jobudførelse fungerer i en HA-klynge #

I en Semaphore-udrulning med flere knuder følger opgaveudførelsen et koordineret forløb:

1. En bruger trigger en opgave. En bruger starter et job via UI eller API. Anmodningen kan lande på en vilkårlig Semaphore-instans.
2. Opgavemetadata gemmes. Den modtagende knude skriver opgavemetadata til databasen og signalerer arbejdet via Redis.
3. En knude opfanger opgaven. En af de tilgængelige knuder henter opgaven fra Redis, erhverver en distribueret lås og markerer opgaven som kørende i databasen.
4. Opgaven udføres. Knuden udfører opgaven lokalt eller via distribuerede runnere / agenter. Fremskridt og logs skrives løbende tilbage til databasen.
5. Resultater broadcastes. Opgaveopdateringer udbredes via Redis Pub/Sub, så alle knuder og UI-klienter forbliver synkroniserede.

Horisontal skalering med flere runnere #

Høj tilgængelighed muliggør også horisontal skalering af opgaveudførelse. I stedet for kun at køre opgaver på selve Semaphore-knuderne kan udførelsen uddelegeres til flere runnere eller agenter. For store DevOps-teams understøtter denne arkitektur automatiseringsarbejdsbelastninger på virksomhedsniveau:

• distribuer arbejdsbelastning på tværs af infrastruktur
• skaler automatiseringskapacitet
• isoler udførelsesmiljøer for at begrænse fejlradius
• kør tusindvis af knuder parallelt

Fordele ved aktiv-aktiv Semaphore-udrulning #

Forbedret pålidelighed. Hvis én instans fejler, fortsætter andre med at betjene trafik og udføre opgaver.

Vedligeholdelse uden nedetid. Knuder kan opdateres eller genstartes uden at standse systemet.

Horisontal skalerbarhed. Yderligere Semaphore-knuder kan tilføjes bag belastningsfordeleren for at øge kapaciteten.

Ingen afhængighed af en primær knude. Alle knuder er lige, hvilket fjerner komplekse failover-mekanismer.

Ensartet tilstand på tværs af klyngen. Delt databaselagring og Redis-koordinering holder alle instanser synkroniserede.

Typiske anvendelsesscenarier #

Aktiv-aktiv Semaphore-udrulninger er almindelige i miljøer, der kræver kontinuerlig automatiserings-tilgængelighed:

• Store DevOps-teams. I organisationer, hvor mange ingeniører udløser automatiseringsopgaver i løbet af dagen, gør flere Semaphore-instanser det muligt at behandle jobs og anmodninger parallelt, hvilket forhindrer en enkelt knude i at blive en flaskehals.
• Virksomhedsinfrastruktur. Virksomheder, der administrerer store flåder af servere, virtuelle maskiner eller containere, er stærkt afhængige af automatisering til konfiguration og vedligeholdelse. Høj tilgængelighed hjælper med at sikre, at kritiske automatiseringsarbejdsgange forbliver operationelle.
• CI/CD-automatisering. Når Semaphore bruges som en del af CI/CD-pipelines, kan afbrydelser forsinke udrulninger og udgivelser. Aktiv-aktiv udrulninger hjælper med at holde pipelines kørende pålideligt, selv hvis individuelle knuder genstarter eller fejler.
• Platform Engineering. Platformteams bruger ofte Semaphore som en del af interne udviklerplatforme, der leverer self-service-automatisering. Høj tilgængelighed sikrer, at disse interne tjenester forbliver stabile og responsive for udviklingsteams.

Konklusion #

Aktiv-aktiv høj tilgængelighed gør det muligt for Semaphore UI at udvikle sig fra en enkelt automatiseringsserver til et modstandsdygtigt distribueret system. I stedet for at stole på én proces til at håndtere UI, planlægning og opgaveudførelse arbejder flere Semaphore-instanser sammen bag en belastningsfordeler, mens de deler tilstand gennem en database og Redis. Resultatet er en automatiseringsplatform, der forbliver tilgængelig, selv når individuelle knuder fejler, og som kan skaleres horisontalt i takt med, at arbejdsbelastningen vokser.

Understøttelse af aktiv-aktiv HA er tilgængelig i Semaphore Enterprise-udgaven. Ud over høj tilgængelighed indeholder Enterprise-versionen funktioner designet til større teams og produktionsmiljøer — såsom avanceret RBAC (rollebaseret adgangskontrol), der giver organisationer mulighed for at definere detaljerede tilladelser på tværs af projekter, teams og miljøer.

Hvis du overvejer en automatiseringsplatform med høj tilgængelighed til din infrastruktur, kan du anmode om en prøveversion af Enterprise-udgaven for at teste HA-arkitekturen og se, hvordan den passer ind i dine DevOps-arbejdsgange.