Selles artiklis näitan, kui lihtne ja tasuta on luua failover-skeem veebisaidi (või mõne muu internetiteenuse) jaoks, kasutades monitooringut ja dünaamilist DNS-i teenust. See tähendab, et igasuguste probleemide korral peamise saidiga (alates lehe „PHP Error” probleemidest kuni ruumi puudumise või lihtsalt kahtlaselt vähese tellimuste arvuni veebipoes) suunatakse uued külastajad teisele (kolmandale jne) teadaolevalt töötavale serverile või „Vabandame” lehele, kus neile sõbralikult selgitatakse, et „on probleem, me oleme juba teadlikud ja parandame peagi” (ja te sel juhul olete tõepoolest juba teadlik ja saate parandada).
Elada failoveri olemasolu või puudumisega?
Kun probleem hakkab tekkima, pole erilist vahet, kuni see juhtub. Kuid kui probleem ilmneb, siis ilma failoverita toimub sageli järgmist: proovite kiiresti aru saada, mis toimub, kuid see ei õnnestu (varukoopiad ei tööta, tarkvara mingil põhjusel ei käi vastavalt dokumentatsioonile jne), aega ei ole, serverid ja saidid on maas, kliendid helistavad, kõik on närvis, proovite kuidagi „linkida” asja kokku, kuni see kuidagi jälle tööle hakkab. Te arvate, et tulevikus oleks tark sügavamalt aru saada ja kõik korralikult üle teha, kuid ei ole midagi püsivamat kui ajutine.
Nüüd, kuidas see toimub kauni variandiga failover'iga:
- Tõrked tekivad
- Tõrge tuvastatakse automaatselt
- Teavitus saadetakse
- Käivitub üleminek ühele varuserveritest
- Rahu ja ilma paanikata selgitatakse probleem, fikseeritakse see ja server taaskäivitub.
Selles skeemis võivad loomulikult esineda omad tõrked, kuid see on siiski lineaarne skeem, kus iga etapp on lihtne ja oluline on see, et seda saab eraldi siluda. Seetõttu on selle skeemi tõrgete tõenäosus palju väiksem, ning kõik toimingud saab automatiseerida ja need toimivad kiiresti (erinevalt ülesandest leida ja parandada tundmatut epilist probleemi). Teie lennuk on maandunud kauges riigis, lülitate telefoni sisse ja näete Telegramis teavitust, et server on kukkunud, kuid kõik on korras, varu-server on aktiveeritud. Saate oma reisi jätkata, ei pea tagasi lendama ega SSH kaudu lähimast WiFi-kohvikust parandama. Lahendate selle siis, kui teile sobib.
Tulevik on juba siin!
Varem oli peamine probleem, mis tegi failover'i sageli vastuvõetamatuks lahenduseks, seotud sellega, kui palju see maksma läks. Ent oli vaja osta kallid seadmed (ning palgata veel kallimaid spetsialiste). Või mõelda välja midagi keerulist juhendite järgi (olen isegi näinud varianti, kus kaks serverit on ühendatud null-modemi kaabli kaudu ja edastavad selle kaudu heartbeat'i, et varuserver saaks õigel hetkel teada ja võtta juhtimise üle). Praegu on olemas lihtsamaid ja tasuta lahendusi. Kui teil on kasside tõttu kuulsust saanud veebisait — ei ole teil õigustatust, kui te pole endiselt failover'it rakendanud!
Lisaks vajab failover skeem ka serverit (või võib-olla isegi mitut) ja varem olid kulud suured, nüüd saab VDS-i võtta väga madala hinnaga.
Usaldusväärseim kasside veebisait
Praktilise näitena lahendusest okerr + dynamic dns oleme käivitanud oma kasside veebisaidi . Me ei salli kasside kohalolekut, seega neid seal peaaegu pole. Kokku on kolm saiti, mis kõik näevad välja enam-vähem samad (kõik on ühe шаблонil), kuid erinevate kassidega, et neid oleks lihtne eristada, ja igaüks annab tehnilist teavet, et näha, kuidas failover töötab. Leht uuendatakse ise iga minuti tagant, kuid alati saab brauseris vajutada reload nuppu.
Tehnilises teabes on rida “status=OK”. Mõnikord simuleerivad serverid probleeme ja kirjutavad status=ERR. Peamine server “nagu kukub” iga tunni 20. minutist (0:20, 1:20, 2:20 jne). Varu (backup) server 40. minutist. Viimane server (“sorry”-server) töötab alati. Iga tunni 0. minutis, peamine ja varu server “taastuvad”.

Kui avate saidi ning jätate selle vahekaardile, näete, et see ei kuku kunagi kokku (kuigi iga eraldi server simuleerib aeg-ajalt probleemi). Serveri probleemide korral liigub see lihtsalt elavate serverite vahel. Pilt, nimi ja serveri aadress ning selle roll muutuvad. Mõnikord võib tabada hetke, kui status=ERR (probleem on juba olemas, kuid terve failover-skeem ei ole veel käivitatud), kuid järgmine uuendus näitab teile lehte töökohalt.
Failover okerr + dünaamiline DNS
Vaadakem, kuidas see kapoti all töötab. Failoveri ülesanne on, et aadress cat.okerr.com viitaks alati töötava serveri IP-aadressile.
Iga meie окerr'is asuva serveri taga, mis hoiab meie kodulehte, on indikaator, mis kontrollib selle staatust kord minutis.

Sellel ekraanil näeme, kuidas kontrollitakse veebisaiti cat.okerr.com serverist alpha.okerr.com. Leht peab sisaldama status=OK ja nagu näeme ülal, on meie staatuse indikaator praegu OK. Kui server "katkeb", kuvatakse ERR. (See on ainult üks indikaatori näide, okerr on jälgimissüsteem, seega võib kinnitada igasuguseid indikaatoreid, näiteks kontrollida vaba kettaruumi, uute tellimuste arvu andmebaasis ja isegi loogilisi indikaatoreid, kus öösel on ühe tüüpi veakriteeriumid ja päeval teised).
Projektiseadetes oleme loonud failover skeemi nende indikaatoritega:

Skeemis on kolm indikaatorit (kolm serverit), erineva prioriteediga. Peamine server veebisaidi jaoks on charlie; kui see ei tööta (ei ole "status=OK" või lihtsalt kättesaamatu), siis toimib bravo ja viimase võimalusena alpha. Lehe paremas osas näidatakse DNS-kirje olekut erinevates serverites.
Neile, kes on märganud, et kasutatakse nime cat.he.okerr.com: kasutame veidi keerulisemat skeemi. Selle asemel, et lihtsalt muuta DNS-kirjet cat.okerr.com, muudame cat.he.okerr.com (dünaamiliste DNS-teenuste pakkujas, ), cat.okerr.com on CNAME (alias), which remains unchanged and always points to cat.he.okerr.com. We simply prefer Hurricane as our dynamic DNS, as it offers keys to manage individual records (rather than the entire zone), providing an added layer of security. You can also avoid specifying passwords-keys in okerr to manage the entire domain, only for a subdomain or record.
From drop to rise
Step by step, how this scheme works:
- A problem occurs (is simulated) on the server
- The okerr sensor checks the status of each server once a minute and reports to the main project server in okerr
- The indicator of the relevant server changes its status from OK to ERR
- When the indicator status changes, failover is recalculated, determining which address needs to be set (if necessary. For example, if the main server is operational while the backup has failed — no changes will occur)
- This address is reported to the dynamic DNS service. Upon completion of this stage, you will see the status 'synced' on the right
- Very soon (within seconds), the record will reach your domain's DNS servers (for the site, this is ns1-ns5.he.net).
- Alates sellest hetkest saavad mõned kasutajad juba uuele elavale serverile pääseda. Kuid mitte kõik DNS serverid maailmas ei ole veel kirjeid värskendanud ja kuskil võib veel olla varem salvestatud kirje. Avalikes DNS serverites võib näha, kuidas andmed "tantsivad", näidates kord uut, kord vana väärtust. Kui uuendada failover'i seadete lehte, küsib server endiselt uusi andmeid DNS serveritelt.
- Pärast seda, kui andmed on stabiliseerunud, on vana vahemälus olev kirje igal pool aegunud — kõik 100% päringutest suunatakse uuele serverile.
7. etapi (mis on sageli kõige pikem) kiirendamiseks tuleb dünaamilise DNS kirje TTL seadistada võimalikult madalale. Tüüpiliselt lubavad teenused intervalle 90–120 sekundit. See on täiesti mõistlik kompromiss.
Lisaks
Kõike seda saab seadistada ühe õhtu jooksul (kui teil on juba duplikaatserver). Nii okerr kui ka dünaamilise DNS-i teenused on tasuta. Okerris rohkemate kontrollide ja lühema kontrollimistähtaja saamiseks tuleks läbida koolitus (profiililehe kaudu). Koolituse lõpetamisel tõuseb kohe tase (20 indikaatorit tunni jooksul + 1 kiire, 10-minutiline). Ja kui seda jääb väheks — kirjutage support@okerr.com, tõenäoliselt on võimalik tõsta (praegu on alati olnud võimalus, kunagi ei ole keeldutud, vastupidi, olen ise pakkunud). Lihtsalt alguses ei taha ma kõigile kõike lubada, ei ole kindel, kas piisab ressurssidest, et oma sõna pidada. Aga praegu on kasutajaid vähe, seega pole limiitide tõstmisest probleeme.
Mida okerr üldse teha suudab — vaadake veebilehelt . Üldiselt on see jälgimine (zabbix pilves), ja failide haldamine on meeldiv lisafunktsioon. Samuti saab veebilehelt registreerimata demoversiooni külastada.
Indikaatori seisundi muutumisel saadetakse teavitus e-posti või Telegrami kaudu. (Vaatasime, mis toimub, ja selgus, et Telegram tundub olevat kõige usaldusväärsem sõnumitooja. Aitäh RKN-ile stressitesti eest!) Kui okerr on õigesti seadistatud, siis on iga teavitus kas signaal "jätke kõik kõrvale, peab parandama!" või "peate tagasi!". Okerilt ei tohi olla liigseid häireid (kui neid on, tuleb seadistada kuidagi teisiti). Näiteks meie kotosaidi server alpha on viimasena ja ei simuleeri kunagi viga. Kui see kokku kukub, peame sellest teadma. Kuid teised serverid simuleerivad pidevalt vigu, seetõttu, et mitte saada häireid mitu korda tunnis, on nende indikaatorite staatus "vaikne".
On mõtet luua ka sorry-server (igasugusele odavale hostimisele), mis kas kuvab teie vabanduse lehte (juhul, kui kõik peamised ja varuserverid on maas) või suunab okerri staatuse lehele (näiteks meie ) või statuspage.io.
Allikas: habr.com
