Šiame straipsnyje noriu parodyti, kaip lengvai ir nemokamai galite sukurti svetainės (ar bet kurios kitos interneto paslaugos) perjungimo schemą, naudodami stebėjimo derinį. ir dinaminė DNS paslauga. Tai yra, iškilus bet kokioms pagrindinės svetainės problemoms (nuo problemos dėl „PHP klaidos“ puslapyje iki vietos trūkumo ar tiesiog įtartinai mažo užsakymų skaičiaus internetinėje parduotuvėje), nauji lankytojai bus nukreipti į antrą (trečią ir pan.) toliau) žinomą veikiantį serverį arba puslapyje „Atsiprašau“, kur mandagiai paaiškins, kad „yra problema, mes jau žinome ir jau taisome, mes greitai sutvarkys“ (ir tokiu atveju jūs jau tikrai žinosite ir galėsite taisyti).
Gyventi su nesėkme ar be jos?
Kol neatsiranda problemų, nėra didelio skirtumo. Bet kai taip nutinka, be perjungimo dažnai nutinka taip: bandote greitai išsiaiškinti, kokia yra problema, ji neveikia (atsarginės kopijos nediegiamos, programinė įranga dėl kokių nors priežasčių neveikia taip, kaip turėtų iš dokumentacijos ir t.t.), bet nėra laiko, nėra serverio - svetainės guli, klientai skambina, visi ant krašto, bandai kažkaip grubiai ir nešvariai sutvarkyti „juosta“, tada kažkaip atrodo, kad paleidžia su ramentais ir gyvybėmis. Manote, kad laisvalaikiu reikės detaliau išsiaiškinti ir gražiai viską perdaryti, bet nėra nieko pastovesnio už laikiną.
Dabar, kaip tai atsitinka gražioje versijoje su failais:
- Atsitinka klaida
- Klaida aptinkama automatiškai
- Įspėjimas išsiųstas
- Perjungiamas į vieną iš atsarginių serverių
- Ramiai ir be panikos problema sutvarkoma, pašalinama, o serveris vėl pradedamas veikti.
Žinoma, ši schema taip pat gali turėti savų problemų, bet vis tiek schema yra linijinė, kiekvienas etapas yra paprastas ir svarbiausia, kad ją būtų galima derinti atskirai, todėl šios schemos gedimo tikimybė yra daug mažesnė ir visi veiksmai gali būti automatizuoti ir atlikti greitai (skirtingai nei užduotis surasti ir taisyti nežinomą epinį šūdą). Jūsų lėktuvas nusileido tolimoje šalyje, įjungiate telefoną ir telegramoje matote pranešimą, kad sugedo serveris, bet viskas gerai, atsarginis serveris suaktyvintas, galite tęsti kelionę, nereikia atskristi arba remontuoti per SSH iš artimiausios kavinės su WiFi . Kai bus patogiau, tai išsiaiškinsi.
Ateitis jau čia!
Anksčiau pagrindinė problema, dėl kurios perkėlimas dažnai buvo nepriimtinas sprendimas, buvo išlaidų suma. Arba reikėjo pirkti brangią techninę įrangą (ir kviestis dar brangesnius specialistus). Arba kolūkis kažkas sudėtingo pagal vadovus (net susidūriau su tokiu variantu, kai du serveriai papildomai prijungiami nuliniu modemo kabeliu ir per jį siunčia širdies plakimą, kad reikiamu metu atsarginis serveris jį atpažintų ir perimtų kontrolė). Dabar yra paprastesnių ir nemokamų būdų. Jei turite svetainę su katėmis, jums dar nėra jokio pasiteisinimo neįdiegti jos perkėlimo!
Na, be to, failover schemai reikia kito serverio (o gal ir daugiau nei vieno), o anksčiau tai buvo didelės išlaidos, o dabar VDS galima gauti už centus.
Patikimiausia svetainė su katėmis
Norėdami praktiškai iliustruoti sprendimą su okerr + dynamic dns, atidarėme savo svetainę su katėmis . Mes nekenčiame kačių, todėl jų ten nebus daug. Iš viso yra trys svetainės, kiekviena iš jų atrodo maždaug vienodai (visos pagal tą patį šabloną), bet su skirtingais kačiukais, kad būtų lengva atskirti, ir kiekviena iš jų rašo techninę informaciją, kad pamatytų, kaip veikia pertvarkymas. Puslapis atnaujinamas kas 1 minutę, bet visada galite spustelėti įkelti iš naujo naršyklėje.
Techninėje informacijoje yra eilutė „status=OK“. Kartais serveriai apsimeta problemas ir rašo status=ERR. Pagrindinis serveris „atrodo, kad užstringa“ 20 minučių kas valandą (0:20, 1:20, 2:20, ...). Atsarginis serveris per 40 minučių. Paskutinis serveris („atsiprašau“) visada veikia. Kas valandą 0 minučių pirminis ir atsarginis serveriai „atkuriami“.
Jei atidarysite svetainę ir paliksite ją skirtuke, pamatysite, kad ji niekada nestringa (nors kiekvienas atskiras serveris periodiškai imituoja problemą), o iškilus problemai su serveriu, jis tiesiog „veikia“ tarp gyvų serverių. Pasikeis serverio paveikslėlis, pavadinimas ir adresas bei jo vaidmuo. Kartais galite pagauti momentą, kai status = ERR (problema jau egzistuoja, bet visa perjungimo schema dar neveikė), tačiau kitas atnaujinimas parodys puslapį iš veikiančios svetainės.
Perkėlimas naudojant okerr + dinaminį DNS
Pažiūrėkime, kaip tai veikia po gaubtu. Failuotojo užduotis yra užtikrinti, kad cat.okerr.com adresas visada nukreiptų į veikiančio serverio IP adresą.
Už kiekvieno serverio, kuriame yra mūsų kačių svetainė okerr, yra indikatorius, kuris kartą per minutę tikrina jo būseną.
Šioje ekrano kopijoje matome, kaip svetainė cat.okerr.com tikrinama iš alpha.okerr.com serverio. Puslapyje turi būti status=OK, ir, kaip matome aukščiau, mūsų indikatoriaus būsena dabar yra gerai. Kai serveris "nutrūks", bus ERR. (Tai tik vienas indikatoriaus pavyzdys, okerr stebi, todėl galite pridėti bet kokio tipo indikatorių, pvz., patikrinti laisvą vietą diske, naujų užsakymų skaičių duomenų bazėje ir net loginius rodiklius, pvz. , naktį bus vieni klaidų kriterijai, o dieną kiti) .
Projekto nustatymuose sukūrėme perjungimo schemą su šiais indikatoriais:
Schema turi tris rodiklius (trys serveriai), kurių prioritetas skiriasi. Pagrindinis svetainės serveris yra charlie, jei jis neveikia (neturės „status=OK“ arba tiesiog nepasiekiamas), tada bravo, o pastaruoju atveju - alfa. Dešinėje puslapio pusėje rodoma DNS įrašo būsena skirtinguose serveriuose.
Tiems, kurie pastebėjo, kad naudojamas pavadinimas cat.he.okerr.com: Mes naudojame šiek tiek sudėtingesnę schemą. Užuot tiesiog pakeitę cat.okerr.com DNS įrašą, mes keičiame cat.he.okerr.com (dinaminio DNS teikėjo ), o cat.okerr.com yra CNAME (alias), kuris nesikeičia, visada nurodo cat.he.okerr.com. „Hurricane“ mums labiau patinka kaip dinaminis DNS, ir jis turi raktus, skirtus valdyti vieną įrašą (o ne visą zoną), manome, kad tai yra saugesnė. Taip pat nereikia nurodyti pagrindinių slaptažodžių okerr, kad galėtumėte valdyti visą domeną, o tik subdomenui arba įrašui.
Nuo kritimo iki pakilimo
Žingsnis po žingsnio, kaip veikia ši schema:
- Serveryje iškilo problema (imituojama).
- okerr jutiklis tikrina kiekvieno serverio būseną kartą per minutę ir praneša pagrindiniam projekto serveriui okerr
- Atitinkamas serverio indikatorius pasikeičia iš OK į ERR
- Pasikeitus indikatoriaus būsenai, perskaičiuojamas perkrovimas ir apskaičiuojama, kurį adresą reikia nustatyti (jei reikia. Pavyzdžiui, jei veikia pagrindinis serveris, o kartu ir atsarginis serveris mirė, jokių pakeitimų nebus pagamintas)
- Šis adresas pranešamas dinaminei DNS tarnybai. Baigę šį etapą, dešinėje pamatysite būseną „sinchronizuota“.
- Labai greitai (sekundėmis) įrašas pasieks jūsų domeno DNS serverius (katės svetainėje tai yra ns1-ns5.he.net).
- Nuo šio momento kai kurie vartotojai jau bus naujajame tiesioginiame serveryje. Tačiau dar ne visi pasaulio DNS serveriai atnaujino įrašus, o senasis įrašas vis tiek gali būti kažkur talpykloje. Galite pamatyti, kaip „šoka“ viešuose DNS serveriuose esantys duomenys, rodydami naują arba seną reikšmę. Jei atnaujinsite perkrovos konfigūracijos puslapį, pats operatorius paprašys naujų duomenų iš DNS serverių.
- Duomenims stabilizavus, senas talpyklos įrašas visur supuvęs – visos 100% užklausų keliauja į naują serverį.
Norint pagreitinti 7 etapą (dažnai ilgiausią), dinaminio DNS įrašo TTL turėtų būti nustatytas kuo žemesnis. Paprastai paslaugos leidžia daryti 90–120 sekundžių intervalus. Tai visiškai pagrįstas kompromisas.
Be
Visa tai galima sukonfigūruoti per vakarą (jei jau turite atsarginį serverį). Tiek okerr, tiek dinaminės DNS paslaugos yra nemokamos. Norėdami gauti daugiau patikrinimų okerr ir trumpesnį patvirtinimo laikotarpį, turite baigti mokymą (iš savo profilio puslapio). Baigus lygis iš karto pakyla (20 indikatorių per valandą + 1 greitas, 10 minučių). O jei jų mažai, rašykite [apsaugotas el. paštu], greičiausiai bus galima padidinti (iki šiol visada buvo galimybė, niekada neatsisakiau, atvirkščiai, pati pasiūliau). Tiesiog iš pradžių nenoriu visiems visko žadėti, nesu tikra, kad turiu pakankamai galimybių tesėti žodį. Tačiau kol kas vartotojų nedaug, tad problemų didinant limitus nekyla.
Ką okerr apskritai gali padaryti – pažiūrėkite į svetainę . Apskritai tai yra stebėjimas (zabbix iš debesies), o failas yra puiki papildoma funkcija. Demonstraciją taip pat galite pasiekti iš svetainės be registracijos.
Pasikeitus indikatoriaus būsenai, el. paštu arba telegrama siunčiamas pranešimas. (Pažiūrėjome, kas vyksta, ir supratome, kad telegrama atrodo patikimiausias pasiuntinys. Ačiū RKN už testavimą nepalankiausiomis sąlygomis!) Teisingai sukonfigūravus okerr, bet koks pranešimas yra arba signalas „mesk viską, mums reikia tai pataisyti! , arba „užgeso šviesa! Iš okerros neturėtų būti jokių papildomų įspėjimų (jei yra, juos reikia sukonfigūruoti kažkaip kitaip). Pavyzdžiui, mūsų kačių svetainėje alfa serveris yra paskutinis ir niekada neklastoja klaidos. Jei jis guli, turime žinoti. Tačiau kiti serveriai nuolat apsimetinėja klaidas, todėl, kad negautų įspėjimų kelis kartus per valandą, tie indikatoriai turi būseną „tyli“.
Taip pat prasminga sukurti atsiprašau serverį (bet kuriame pigiausiame priegloboje), kuriame bus jūsų atsiprašymo puslapis (jei neveikia visi pagrindiniai ir atsarginiai serveriai) arba nukreips jus į okerr būsenos puslapį (pavyzdžiui, mūsų ) arba statuspage.io.
Šaltinis: www.habr.com