Hold Semaphore tilgængelig, når en applikationsnode stopper

Den dokumenterede aktiv-aktiv-arkitektur bruger flere Semaphore-applikationsnoder, en fælles PostgreSQL- eller MySQL-database, Redis-koordinering og en load balancer med HTTP- og WebSocket-understøttelse. Hver node kræver passende fælles indstillinger og en unik HA-identifikator. Planlæg afhængighedernes tilgængelighed sammen med applikationsnoderne. En anden proces alene giver ikke den fælles tilstand og koordinering, hele topologien kræver.

Arkitekturen her er aktiv-aktiv med ligeværdige applikationsnoder, der deltager i tjenesten. Den afhænger ikke af en dedikeret primær applikationsnode og en passiv reserve. Brug den aktuelle HA-vejledning til det understøttede design, og udled ikke en separat aktiv-passiv referencearkitektur af generelle tilgængelighedsformuleringer. Afklar tilstands- og failoveradfærd før installation, hvis infrastrukturen kræver en anden topologi.

Nej. Det dokumenterede HA-design kræver en fælles PostgreSQL- eller MySQL-database sammen med Redis. Databasen er den fælles kilde til applikationstilstand for de deltagende noder. Planlæg migrering, sikkerhedskopier og validering separat, hvis du kommer fra én node med anden lagring. Tilføjelse af applikationsnoder bør ikke være første test af, at den fælles database indeholder og leverer de nødvendige data.

Disse komponenter kræver egen robusthedsstrategi. Semaphores fler-nodedesign opretter ikke automatisk databasefailover, redundant belastningsfordeling eller en tilgængelig Redis-tjeneste. Identificer hver afhængigheds fejldomæne, gendannelsesproces og kapacitetskrav. Test hele vejen fra klientanmodning til opgaveresultat, så tilgængelighedsplanen dækker tjenesten, folk bruger, frem for kun antallet af kørende applikationsnoder.

Antag ikke uafbrudt igangværende eksekvering, blot fordi der er flere applikationsnoder. Adfærden afhænger af eksekveringsforløbet, den fejlramte komponent og den anvendte version. Test den opgavelivscyklus, du er afhængig af, herunder statusrapportering og runnerens deltagelse. Planlæg også opgraderingskompatibilitet og migrering bevidst frem for at se enhver versionsændring som en garanteret rullende opgradering uden nedetid. Tilgængelighed af brugerfladen og kontinuitet af opgaver er forskellige krav.

Høj tilgængelighed er en Enterprise-funktion. Begynd med nødvendige driftstider, vedligeholdelsesproces, gendannelsesmål og eksisterende database- og load balancer-tjenester. Brug den dokumenterede topologi til at finde mangler, og test derefter nodefjernelse, gendannelse af afhængigheder og sikkerhedskopier i et repræsentativt miljø. En arkitektursamtale er nyttig, når kravene er forretningskritiske, fordi hele installationen, ikke en enkelt funktionskontakt, bestemmer resultatet.

Det er formålet med at placere aktive applikationsnoder bag én belastningsfordelt tjenesteadresse. Load balanceren skal stoppe med at sende anmodninger til den utilgængelige node og understøtte både HTTP og WebSocket. Den tilbageværende node kræver stadig adgang til fælles database, Redis og ens applikationskonfiguration for at betjene projektet.

Nej. Flere eksekveringsplaceringer håndteres af runnere. Høj tilgængelighed handler om Semaphore-applikationslaget, mens runnere handler om opgaveplacering og tilgængelige systemer. En produktionsinstallation kan bruge begge: HA-applikationsnoder til fælles brugerflade og API samt projektrunnere nær privat infrastruktur.