I denne artikel vil jeg vise, hvor nemt og gratis du kan lave en failover-ordning for et websted (eller enhver anden internettjeneste) ved hjælp af en kombination af overvågning og dynamisk DNS-tjeneste. Det vil sige, at i tilfælde af problemer med hovedsiden (fra et problem med en "PHP-fejl" på siden, til mangel på plads eller blot et mistænkeligt lille antal ordrer i tilfælde af en onlinebutik), vil nye besøgende blive dirigeret til den anden (tredje, og så videre) yderligere) en kendt fungerende server, eller på "Beklager"-siden, hvor de høfligt vil forklare, at "der er et problem, vi er allerede klar over det og løser det allerede, vi vil ordne det snart” (og i dette tilfælde vil du faktisk allerede være ved det og kan reparere).
At leve med failover eller uden?
Indtil der opstår et eller andet problem, er der ikke den store forskel. Men når det sker, uden failover sker der ofte følgende: du forsøger hurtigt at finde ud af, hvad problemet er, det virker ikke (backups implementeres ikke, softwaren virker af en eller anden grund ikke, som den skal ud fra dokumentationen osv.), men der er ingen tid, ingen server - webstederne ligger ned, kunderne ringer, alle er på kanten, du forsøger på en eller anden måde at ordne det groft og beskidt "med tape", så ser det ud til, at det på en eller anden måde starter op med krykker og liv. Du tror, at du i din fritid bliver nødt til at finde ud af det mere detaljeret og lave det hele smukt om, men der er ikke noget mere permanent end midlertidigt.
Nu, hvordan dette sker i en smuk version med en filer:
- Der sker en fejl
- Fejlen opdages automatisk
- Alarm udsendes
- Skift til en af backup-serverne overføres
- Roligt og uden panik bliver problemet løst, rettet og serveren sat i drift igen.
Denne ordning kan selvfølgelig også have sine egne problemer, men alligevel er ordningen lineær, hvert trin er simpelt, og det vigtigste er, at det kan fejlsøges separat, så chancen for fejl i denne ordning er meget lavere, og alle handlinger kan automatiseres og udføres hurtigt (i modsætning til opgaven med at finde og rette ukendt episk lort). Dit fly er landet i et fjernt land, du tænder for din telefon og ser en notifikation i et telegram om, at serveren er gået ned, men alt er i orden, backup-serveren er aktiveret, du kan fortsætte din rejse, du behøver ikke at flyve tilbage eller reparere den via SSH fra den nærmeste cafe med WiFi . Du finder ud af det, når det er mere bekvemt.
Fremtiden er allerede her!
Tidligere var det største problem, der ofte gjorde failover til en uacceptabel løsning, mængden af omkostninger, det koster. Eller det var nødvendigt at købe dyrt hardware (og invitere endnu dyrere specialister). Eller i fællesskab dyrke noget kompliceret ifølge guiderne (jeg stødte endda på en mulighed, hvor to servere desuden er forbundet med et nulmodemkabel og sender et hjerteslag igennem det, så backup-serveren i det rigtige øjeblik genkender det og overtager kontrollen) . Nu er der nemmere og gratis måder. Hvis du har en hjemmeside med katte, er der ingen undskyldning for dig ikke at implementere failover for det endnu!
Tja, desuden har du brug for en anden server (og måske mere end én) til en failover-ordning, og før var dette en stor udgift, nu kan du få en VDS for øre.
Det mest pålidelige websted med katte
For praktisk at illustrere løsningen med okerr + dynamisk dns, lancerede vi vores hjemmeside med katte . Vi hader katte, så der vil ikke være mange af dem der. Der er tre steder i alt, hver af dem ser nogenlunde ens ud (alle på den samme skabelon), men med forskellige killinger for at gøre det nemt at skelne, og hver enkelt skriver teknisk information for at se, hvordan failover fungerer. Siden opdaterer sig selv en gang hvert 1. minut, men du kan altid klikke på genindlæs i browseren.
I den tekniske information er der en linje "status=OK". Nogle gange foregiver servere problemer og skriver status=ERR. Hovedserveren "synes at gå ned" 20 minutter af hver time (0:20, 1:20, 2:20, …). Backup server på 40 minutter. Den sidste server ("undskyld" server) kører altid. Ved 0 minutter af hver time "gendannes" den primære server og backup-serveren.
Hvis du åbner siden og efterlader den i fanen, vil du se, at den aldrig går ned (selvom hver enkelt server med jævne mellemrum simulerer et problem), og i tilfælde af et problem med serveren, "kører" den blot mellem live servere. Serverens billede, navn og adresse og dens rolle ændres. Nogle gange kan du fange det øjeblik, hvor status = ERR (problemet eksisterer allerede, men hele failover-skemaet har endnu ikke virket), men den næste opdatering vil vise dig en side fra arbejdsstedet.
Failover på okerr + dynamisk DNS
Lad os se, hvordan det fungerer under motorhjelmen. Filerens opgave er at sikre, at cat.okerr.com-adressen altid peger på IP-adressen på den fungerende server.
Bag hver af de servere, der hoster vores katteside i okerr, er der en indikator, der kontrollerer dens status en gang i minuttet.
I dette skærmbillede ser vi, hvordan webstedet cat.okerr.com kontrolleres fra alpha.okerr.com-serveren. Siden skal indeholde status=OK, og som vi ser ovenfor, er vores indikatorstatus OK nu. Når serveren "bryder", vil der være en ERR. (Dette er kun et eksempel på en indikator, okerr overvåger, så du kan vedhæfte enhver type indikator, for eksempel kontrollere ledig plads på disken, antallet af nye ordrer i databasen og endda logiske indikatorer, for eksempel , om natten vil der være nogle fejlkriterier, og om dagen andre).
I projektindstillingerne oprettede vi et failover-skema med disse indikatorer:
Ordningen har tre indikatorer (tre servere), forskellige i prioritet. Hovedserveren for webstedet er charlie, hvis det ikke virker (det vil ikke have "status=OK" eller er simpelthen ikke tilgængeligt), så bravo og i sidstnævnte tilfælde - alpha. Den højre side af siden viser status for DNS-posten på forskellige servere.
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 for cat.okerr.com, ændrer vi cat.he.okerr.com (på Dynamic DNS-udbyderen ), og cat.okerr.com er et CNAME (alias), som ikke ændres, altid peger på cat.he.okerr.com. Vi kan bare bedre lide Hurricane som en dynamisk DNS, og den har nøgler til at administrere en enkelt indgang (i stedet for en hel zone), vi tror, det er mere sikkert. Du behøver heller ikke angive nøgleadgangskoder i okerr for at administrere hele domænet, men kun for et underdomæne eller en post.
Fra at falde til at stige
Trin for trin, hvordan denne ordning fungerer:
- Der opstår et problem (simuleret) på serveren
- Okerr-sensoren tjekker status for hver server en gang i minuttet og rapporterer til hovedprojektserveren i okerr
- Den tilsvarende serverindikator skifter fra OK til ERR
- Når status for indikatoren ændres, genberegnes failover, og det beregnes, hvilken adresse der skal indstilles (hvis det er nødvendigt. Hvis f.eks. hovedserveren fungerer, og samtidig backup-serveren døde, sker der ingen ændringer. lavet)
- Denne adresse rapporteres til den dynamiske dns-tjeneste. Når du har gennemført denne fase, vil du se statussen "synkroniseret" til højre.
- Meget snart (sekunder) vil posten nå DNS-serverne på dit domæne (for kattesiden er det ns1-ns5.he.net).
- Fra dette øjeblik vil nogle brugere allerede være på den nye live server. Men ikke alle DNS-servere i verden har opdateret posterne endnu, og den gamle post kan stadig være cache et eller andet sted. Du kan se, hvordan dataene på offentlige DNS-servere "danser", og viser enten en ny eller gammel værdi. Hvis du opdaterer failover-konfigurationssiden, vil operatøren selv anmode om nye data fra DNS-serverne.
- Efter at dataene er stabiliseret, er den gamle cachelagrede post rådden overalt - alle 100 % af anmodningerne går til den nye server.
For at fremskynde trin 7 (ofte den længste), bør TTL for den dynamiske DNS-post sættes så lavt som muligt. Typisk tillader tjenester intervaller på 90-120 sekunder. Dette er et fuldstændig rimeligt kompromis.
derudover
Alt dette kan konfigureres på en aften (hvis du allerede har en backup-server). Både okerr og dynamiske DNS-tjenester er gratis. For at få flere checks i okerr og en kortere verifikationsperiode skal du gennemføre træning (fra din profilside). Efter afslutning stiger niveauet straks (20 indikatorer i timen + 1 hurtig, 10 minutter). Og hvis der er få af dem, så skriv til [e-mail beskyttet], højst sandsynligt vil det være muligt at øge (indtil videre har der altid været en mulighed, jeg har aldrig nægtet, tværtimod, jeg tilbød det selv). Det er bare, at jeg i første omgang ikke vil love alle alt, jeg er ikke sikker på, at jeg har nok kapacitet til at holde mit ord. Men indtil videre er der få brugere, så der er ingen problemer med at øge grænserne.
Hvad okerr generelt kan - se på hjemmesiden . Generelt er dette overvågning (zabbix fra skyen), og filerne er en fin ekstra funktion. Du kan også få adgang til demoen fra siden uden registrering.
Når indikatorstatus ændres, sendes en meddelelse via e-mail eller telegram. (Vi kiggede på, hvad der skete og indså, at telegram ser ud til at være den mest pålidelige messenger. Tak til RKN for stresstesten!) Med okerr konfigureret korrekt, er enhver notifikation enten et signal "slip alt, vi skal rette det!" , eller "lyser ud!" Der bør ikke være nogen ekstra advarsler fra okerra (hvis der er, skal de konfigureres anderledes). For eksempel, for vores katteside, er alfaserveren den sidste og forfalsker aldrig en fejl. Hvis han ligger ned, skal vi vide det. Men andre servere foregiver konstant fejl, derfor har disse indikatorer en "lydløs" status for ikke at modtage advarsler flere gange i timen.
Det giver også mening at oprette en beklager server (på enhver billigste hosting), som enten vil have din undskyldningsside (i tilfælde af at alle hoved- og backupservere er nede) eller vil omdirigere dig til statussiden på okerr (f.eks. vores ) eller statuspage.io.
Kilde: www.habr.com