I denne artikel vil jeg vise, hvordan du nemt og gratis kan oprette en failover-ordning for en hjemmeside (eller en hvilken som helst anden internetservice) ved hjælp af en kombination af overvågning og dynamiske DNS-tjenester. Det vil sige, i tilfælde af problemer med den primære hjemmeside (fra problemer med 'PHP Error' på siden til pladsmangel eller blot et mistænkeligt lavt antal bestillinger i tilfælde af en webshop), vil nye besøgende blive dirigeret til en anden (tredje osv.) fungerende server, eller til en 'Beklager'-side, hvor de venligt vil blive informeret om, at 'der er et problem, vi er klar over det og arbejder på at løse det, snart er det fikset' (og i dette tilfælde vil du rent faktisk allerede være klar over det og kunne løse det).
At leve med failover eller uden?
Indtil der opstår et problem, er der ikke meget forskel. Men når det sker, så sker der ofte følgende uden failover: du prøver hurtigt at finde ud af, hvad problemet er, men det lykkes ikke (backups kan ikke gendannes, softwaren fungerer af en eller anden grund ikke som dokumentationen antyder osv.), tidsfristen nærmer sig, serverne ligger nede, kunderne ringer, alle er nervøse, du prøver at rette op på det på en grov og klodset måde 'med tape', derefter nogenlunde får det til at køre med midlertidige løsninger. Du tænker, at du senere skal tage dig tid til at rydde op og få det til at se pænt ud, men der er ikke noget mere konstant end det midlertidige.
Nu, hvordan dette sker i en pæn version med failover:
- Fejl opstår
- Fejlen opdages automatisk
- Der sendes en notifikation
- Switches til en af de reserve-servere
- Problemet bliver roligt og uden panik løst, og serveren genindføres i drift.
Selvfølgelig kan der også opstå sine egne problemer i denne ordning, men alligevel er ordningen lineær, hvert trin her er enkelt, og vigtigst af alt - det kan testes separat, så chancen for systemfejl er meget lavere, og alle handlinger kan automatiseres og udføres hurtigt (i modsætning til opgaven at finde og rette den ukendte episke fejl). Dit fly er landet i et fjernt land, du tænder din telefon og ser en notifikation i telegrammet om, at serveren er nede, men alt er godt, den reserve-server er blevet aktiveret, du kan fortsætte din rejse, du behøver ikke at flyve tilbage eller rette noget via SSH fra den nærmeste café med WiFi. Du ordner det, når det passer bedre.
Fremtiden er allerede her!
Tidligere var det den primære udfordring, der gjorde failover til en uacceptabel løsning, omkostningerne til det. Enten skulle man købe dyre enheder (og hyre endnu dyrere specialister). Eller man måtte sammensætte noget kompliceret efter vejledninger (jeg har endda set en løsning, hvor to servere forbindes med et null-modem kabel for at overføre heartbeat, så backup-serveren i det rette øjeblik kan opdage det og overtage kontrollen). I dag findes der enklere og gratis metoder. Hvis du har en hjemmeside med katte — så har du ingen undskyldning for ikke at implementere failover for den!
Derudover kræver en failover-opsætning også en server (eller måske flere), og tidligere var det en stor udgift; nu kan man få en VDS til en slik.
Den mest pålidelige hjemmeside med katte
For praktisk illustration af løsningen med okerr + dynamic dns har vi lanceret vores egen hjemmeside med katte . Vi hader katte, så der vil næsten ikke være nogen der. Der er i alt tre hjemmesider, som alle ser nogenlunde ens ud (alle baseret på samme skabelon), men med forskellige killinger for at gøre det nemt at skelne dem, og hver server angiver tekniske oplysninger for at vise, hvordan failover fungerer. Siden opdateres automatisk hvert minut, men man kan altid klikke på opdater i browseren.
I de tekniske oplysninger er der en linje “status=OK”. Nogle gange simulerer serverne problemer og skriver status=ERR. Hovedserveren “går ned” hver 20. minut i hver time (0:20, 1:20, 2:20, ...). Backup-serveren gør det hver 40. minut. Den sidste server (“sorry”-serveren) kører altid. På 0 minutter hver time “genoprettes” hoved- og backupserveren.

Hvis du åbner hjemmesiden og lader den være åben i en fane — vil du se, at den aldrig går ned (selvom hver enkelt server periodisk simulerer problemet), og i tilfælde af et serverproblem, “løber” den blot mellem de aktive servere. Billedet, navnet og adressen på serveren samt dens rolle vil skifte. Nogle gange kan man fange et øjeblik, hvor status=ERR (problemet eksisterer allerede, men hele failover-systemet har endnu ikke reageret), men næste opdatering vil vise dig siden fra en aktiv server.
Failover med okerr + dynamic DNS
Lad os se, hvordan det fungerer under overfladen. Opgaven for failover er, at adressen cat.okerr.com altid skal pege på IP-adressen for den aktive server.
Bag hvert af serverne, der holder vores kattewebsted på okerr, er der en indikator, der hver minut tjekker dens tilstand.

På dette skærmbillede ser vi, hvordan webstedet cat.okerr.com tjekkes fra serveren alpha.okerr.com. Siden skal indeholde status=OK, og som vi kan se øverst, er indikatorens status lige nu OK. Når serveren "går ned", vil der være ERR. (Dette er kun ét eksempel på en indikator, okerr er en overvågning, så man kan tilføje enhver type indikator, for eksempel tjekke ledig plads på disken, antallet af nye ordrer i databasen og endda logiske indikatorer, hvor der f.eks. vil være én fejlstatus om natten og en anden om dagen).
I projektindstillingerne har vi oprettet en failover-skema med disse indikatorer:

I skemaet er der tre indikatorer (tre servere), som er forskellige i prioritet. Hovedserveren for webstedet er charlie, hvis den ikke fungerer (ikke vil have "status=OK" eller blot er utilgængelig), vil bravo have prioritet, og i sidste tilfælde vil alpha.
For dem, der har bemærket, at navnet cat.he.okerr.com bruges: Vi bruger et lidt mere komplekst skema. I stedet for blot at ændre DNS-posten cat.okerr.com, ændrer vi cat.he.okerr.com (på Dynamic DNS-udbyderen ), og cat.okerr.com er et CNAME (alias), der ikke ændres, men altid peger på cat.he.okerr.com. Vi kan godt lide Hurricane Electric som vores dynamiske DNS, og det har nøgler til at administrere en individuel post (og ikke hele zonen), hvilket vi mener er sikrere. Du kan også vælge ikke at angive adgangskoder/nøgler til at administrere hele domænet i okerr, men kun for underdomænet eller posten.
Fra nedbrud til genopretning
Her er trinene for, hvordan dette skema fungerer:
- Der opstår (simuleres) et problem på serveren
- Okerr-sensoren tjekker hvert minut tilstanden på hver server og rapporterer til hovedserveren i okerr
- Indikatoren for den relevante server ændrer tilstand fra OK til ERR
- Ved ændring af indikatorens status omberegnes failoveren, og der beregnes, hvilken adresse der skal indstilles (hvis nødvendigt. For eksempel, hvis den primære server fungerer, og reserve-serveren er nede — vil der ikke være nogen ændringer)
- Den adresse rapporteres til den dynamiske DNS-tjeneste. Når dette trin er afsluttet, vil du til højre se status “synced”
- Meget snart (sekunder) vil posten nå DNS-serverne for dit domæne (for kattewebstedet er dette ns1-ns5.he.net).
- Fra dette tidspunkt vil nogle brugere allerede blive sendt til den nye live-server. Men ikke alle DNS-servere i verden har opdateret deres poster endnu, og et eller andet sted kan den gamle post stadig være cachet. Man kan se, hvordan dataene på offentlige DNS-servere 'danser', og viser nogle gange den nye, nogle gange den gamle værdi. Hvis man opdaterer failover-indstillingerne, vil okerr selv anmode om nye data fra DNS-serverne.
- Når dataene er stabiliseret, og den gamle cachede post er udløbet overalt - alle 100% af forespørgslerne går til den nye server.
For at fremskynde det syvende trin (som ofte er det længste) skal TTL for den dynamiske DNS-post sættes så lavt som muligt. Tjenesterne tillader normalt intervaller på 90-120 sekunder. Det er en ganske rimelig kompromis.
Yderligere
Alt dette kan sættes op på en aften (hvis du allerede har en duplikerende server). Både okerr og de dynamiske DNS-tjenester er gratis. For at få flere tjek og en kortere tjekperiode i okerr skal man gennemføre træning (fra profil-siden). Ved afslutning hæves niveauet straks (20 indikatorer pr. time + 1 hurtig, 10 minutters). Og hvis det er for lidt - skriv til support@okerr.com, det vil sandsynligvis være muligt at hæve det (indtil videre har der altid været muligheder, aldrig blevet afvist, tværtimod, det har ofte været tilbudt). Jeg vil bare ikke lover alt til alle fra starten, jeg er ikke sikker på, der vil være tilstrækkelige ressourcer til at holde ord. Men indtil videre er der få brugere, så der er ikke problemer med at hæve grænserne.
Hvad kan okerr i det hele taget - se på hjemmesiden. . Det er egentlig overvågning (zabbix fra skyen), og filever er en god ekstra funktion. Man kan også få adgang til en demo fra siden uden registrering.
Når indicatorens status ændres - sendes der en meddelelse til e-mail eller Telegram. (Vi har kigget på, hvad der sker, og indset, at telegram sandsynligvis er den mest pålidelige messenger. Tak til RKN for stresstesten!) Ved korrekt opsætning af okerr, er enhver meddelelse enten et signal om 'drop alt, vi skal fixe det!', eller 'afblæs!'. Der skal ikke være unødvendige alarmer fra okerr (hvis der er, skal konfigurationen ændres). For eksempel, for vores katte-site simulerer server alpha aldrig en fejl. Hvis den går ned - skal vi vide det. Men de andre servere simulerer konstant fejl, så for ikke at modtage alarmer flere gange i timen, har de indikatorer status 'stille'.
Det giver også mening at oprette en sorry-server (på et hvilket som helst af de billigste hosting-tjenester), som enten kan have din undskyldningsside (i tilfælde af, at alle hoved- og backup-servere er nede) eller omdirigere til status-siden på okerr (her er for eksempel vores ) eller statuspage.io.
Kilde: habr.com
