Ebben a cikkben azt szeretném bemutatni, hogy milyen egyszerűen és ingyenesen készíthet feladatátvételi sémát egy webhelyhez (vagy bármely más internetes szolgáltatáshoz) a figyelés kombinációjával. és dinamikus DNS szolgáltatás. Vagyis a főoldallal kapcsolatos bármilyen probléma esetén (az oldalon megjelenő „PHP-hiba” problémától a helyhiányig vagy egyszerűen csak gyanúsan kevés rendelés egy webáruház esetében) az új látogatók a második (harmadik, és így tovább) tovább) egy ismert működő szerverre, vagy a „Bocsánat” oldalon, ahol udvariasan elmagyarázzák, hogy „probléma van, már tudjuk, és már javítjuk. hamarosan megjavítja” (és ebben az esetben valójában már tisztában leszel, és meg tudod javítani).
Feladatátvétellel vagy anélkül élni?
Amíg valamilyen probléma nem történik, addig nincs sok különbség. Ám amikor ez megtörténik, feladatátvétel nélkül gyakran előfordul a következő: megpróbálod gyorsan rájönni, mi a probléma, de nem működik (a biztonsági mentések nem indulnak el, a szoftver valamilyen okból nem úgy működik, ahogy a dokumentáció szerint kellene stb.), de nincs idő, nincs szerver - az oldalak fekszenek, a kliensek hívnak, mindenki a szélén van, próbálod valahogy "szalaggal" durván és koszosan megjavítani, aztán valahogy beindul mankóval és életekkel. Azt gondolja, hogy szabadidejében részletesebben ki kell gondolnia, és mindent szépen újra kell készítenie, de nincs tartósabb az ideiglenesnél.
Most pedig nézzük meg, hogyan történik ez egy gyönyörű verzióban reszelővel:
- Hiba történik
- A hiba automatikusan észlelhető
- Riasztást küldenek
- Az egyik tartalék szerverre váltás átkerül
- Nyugodtan és pánikmentesen megoldják a problémát, kijavítják, és újra üzembe helyezik a szervert.
Ennek a sémának természetesen megvannak a maga problémái is, de ennek ellenére a séma lineáris, minden szakasz egyszerű, és a lényeg, hogy külön-külön is hibakereshető, így ennek a sémának a meghibásodásának esélye sokkal kisebb, ill. minden művelet automatizálható és gyorsan végrehajtható (ellentétben az ismeretlen epikus szar felkutatásával és kijavításával). A géped egy távoli országban szállt le, bekapcsolod a telefonodat és táviratban látod az értesítést, hogy a szerver lefagyott, de minden rendben, a tartalék szerver aktiválva van, folytathatod az utazást, nem kell visszarepülni vagy megjavítani SSH-n keresztül a legközelebbi WiFi-s kávézóból . Majd rájössz, amikor kényelmesebb lesz.
A jövő már itt van!
Korábban a fő probléma, amely gyakran elfogadhatatlan megoldássá tette a feladatátvételt, a költségek összege volt. Vagy drága hardvert kellett vásárolni (és még drágább szakembereket hívni). Vagy kollektív gazdaság valami bonyolult az útmutatók szerint (sőt olyan opcióval is találkoztam, hogy két szerver plusz egy null modem kábellel össze van kötve, és azon keresztül szívverést küldenek, hogy a megfelelő időben a tartalék szerver felismerje és átvegye ellenőrzés). Most vannak egyszerűbb és ingyenes módszerek. Ha van macskákkal foglalkozó webhelye, nincs mentség arra, hogy még ne alkalmazza a feladatátvételt!
Nos, emellett a feladatátvételi sémához még egy szerver kell (és talán több is), és korábban ez nagy kiadás volt, most fillérekért kaphat VDS-t.
A legmegbízhatóbb webhely macskákkal
Az okerr + dinamikus dns megoldás gyakorlatias szemléltetésére elindítottuk a macskákkal foglalkozó weboldalunkat . Gyűlöljük a macskákat, így nem lesz belőlük sok. Összesen három oldal van, mindegyik nagyjából ugyanúgy néz ki (mindegyik ugyanazon a sablonon), de különböző cicákkal, hogy könnyebb legyen megkülönböztetni, és mindegyik technikai információkat ír a feladatátvétel működéséről. Az oldal 1 percenként frissíti magát, de bármikor rákattinthat a böngészőben az újratöltés gombra.
A műszaki információk között van egy „status=OK” sor. Néha a szerverek problémákat színlelnek, és status=ERR-t írnak ki. Úgy tűnik, hogy a fő szerver minden óra 20 percében „összeomlik” (0:20, 1:20, 2:20, …). Biztonsági szerver 40 percen belül. Az utolsó szerver („sajnálom” szerver) mindig fut. Minden óra 0 percében az elsődleges és a tartalék szerver „visszaáll”.
Ha megnyitja az oldalt, és a lapon hagyja, látni fogja, hogy soha nem omlik le (bár minden egyes szerver időnként szimulál egy-egy problémát), és a szerverrel kapcsolatos probléma esetén egyszerűen „fut” az élő szerverek között. A szerver képe, neve, címe és szerepe megváltozik. Néha elkaphatja azt a pillanatot, amikor status = ERR (a probléma már létezik, de a teljes feladatátvételi séma még nem működött), de a következő frissítés egy oldalt mutat meg a működő webhelyről.
Feladatátvétel az okerr + dinamikus DNS-en
Lássuk, hogyan működik a motorháztető alatt. A fájlkezelő feladata annak biztosítása, hogy a cat.okerr.com cím mindig a működő szerver IP címére mutasson.
Az okerr-i macskaoldalunkat üzemeltető minden szerver mögött van egy jelző, amely percenként egyszer ellenőrzi az állapotát.
Ezen a képernyőképen azt láthatjuk, hogyan történik a cat.okerr.com webhely ellenőrzése az alpha.okerr.com szerverről. Az oldalnak tartalmaznia kell a status=OK értéket, és amint fentebb látjuk, a jelző állapota most rendben van. Amikor a szerver „megszakad”, hibaüzenet lesz. (Ez csak egy példa egy indikátorra, az okerr figyel, így bármilyen típusú jelzőt csatolhat, például ellenőrizheti a szabad lemezterületet, az új rendelések számát az adatbázisban, és akár logikai indikátorokat is pl. , éjszaka lesz néhány hibakritérium, nappal pedig mások).
A projektbeállításokban létrehoztunk egy feladatátvételi sémát a következő mutatókkal:
A sémának három mutatója van (három szerver), amelyek prioritása eltérő. Az oldal fő szervere a charlie, ha nem működik (nem lesz “status=OK” vagy egyszerűen nem elérhető), akkor bravo és az utóbbi esetben - alfa. Az oldal jobb oldalán látható a DNS-rekord állapota a különböző szervereken.
Azok számára, akik észrevették, hogy a cat.he.okerr.com nevet használják: Mi egy kicsit összetettebb sémát használunk. A cat.okerr.com DNS-rekordjának megváltoztatása helyett a cat.he.okerr.com webhelyet módosítjuk (a dinamikus DNS-szolgáltatón ), a cat.okerr.com pedig egy CNAME (alias), amely nem változik, mindig a cat.he.okerr.com webhelyre mutat. Jobban szeretjük a Hurricane-t, mint dinamikus DNS-t, és kulcsai vannak egyetlen bejegyzés (nem pedig egy teljes zóna) kezelésére, úgy gondoljuk, hogy biztonságosabb. Ezenkívül nem kell kulcsjelszavakat megadnia az okerr-ben a teljes tartomány kezeléséhez, hanem csak egy aldomainhez vagy rekordhoz.
A zuhanástól a felemelkedésig
Lépésről lépésre, hogyan működik ez a séma:
- Probléma lép fel (szimulálva) a szerveren
- Az okerr érzékelő percenként egyszer ellenőrzi az egyes szerverek állapotát, és jelentést készít az okerr fő projekt szerverének
- A megfelelő szerverjelző OK-ról ERR-re változik
- Amikor a jelző állapota megváltozik, a feladatátvétel újraszámításra kerül, és kiszámításra kerül, hogy melyik címet kell beállítani (ha szükséges. Ha például a fő szerver működik, és ezzel egyidejűleg a tartalék szerver is meghalt, akkor nem történik változás készült)
- Ezt a címet jelentették a dinamikus dns szolgáltatásnak. Ennek a szakasznak a befejezése után a jobb oldalon a „szinkronizált” állapot jelenik meg.
- Nagyon hamar (másodperceken belül) a rekord eléri a domain DNS-kiszolgálóit (a macska webhely esetében ez az ns1-ns5.he.net).
- Ettől a pillanattól kezdve néhány felhasználó már az új élő szerveren lesz. De még nem minden DNS-kiszolgáló frissítette a rekordokat a világon, és a régi rekord még mindig gyorsítótárban van valahol. Láthatja, hogyan „táncolnak” a nyilvános DNS-kiszolgálókon lévő adatok, új vagy régi értéket mutatva. Ha frissíti a feladatátvételi konfigurációs oldalt, az operátor maga kér új adatokat a DNS-kiszolgálóktól.
- Az adatok stabilizálása után a régi gyorsítótárazott rekord mindenhol elromlott - a kérések 100%-a az új szerverre megy.
A 7. szakasz (gyakran a leghosszabb) felgyorsítása érdekében a dinamikus DNS-rekord TTL-jét a lehető legalacsonyabbra kell állítani. A szolgáltatások általában 90-120 másodperces intervallumokat tesznek lehetővé. Ez egy teljesen ésszerű kompromisszum.
emellett
Mindez egy este alatt beállítható (ha már van tartalék szerver). Mind az okerr, mind a dinamikus DNS szolgáltatás ingyenes. Ha több csekket szeretne kapni az okerrben, és rövidebb ellenőrzési időszakot szeretne elérni, el kell végeznie egy képzést (a profiloldaláról). Befejezése után a szint azonnal emelkedik (20 jelzés óránként + 1 gyors, 10 perc). És ha kevés van belőlük írjon [e-mail védett], nagy valószínűséggel lehet majd növelni (eddig mindig volt lehetőség, soha nem utasítottam el, ellenkezőleg, magam ajánlottam fel). Csak kezdetben nem akarok mindenkinek mindent megígérni, nem vagyok benne biztos, hogy van-e elég kapacitásom a szavamhoz. De egyelőre kevés a felhasználó, így nincs probléma a limitek növelésével.
Mit tehet az okerr általában - nézze meg a webhelyet . Általában ez a figyelés (zabbix a felhőből), és a filer egy jó kiegészítő funkció. Az oldalról regisztráció nélkül is elérheti a demót.
Ha az indikátor állapota megváltozik, e-mailben vagy táviratban értesítést küldenek. (Megnéztük, hogy mi történik, és rájöttünk, hogy a távirat tűnik a legmegbízhatóbb üzenetküldőnek. Köszönet az RKN-nek a stressztesztért!) Ha az okerr megfelelően van beállítva, minden értesítés vagy egy jelzés: „dobj el mindent, javítanunk kell!” , vagy „világítanak!” Az okerrától nem jöhetnek extra riasztások (ha vannak, azokat valahogy másképp kell beállítani). Például a macskaoldalunknál az alfa szerver az utolsó, és soha nem hamisít hibát. Ha lefekszik, tudnunk kell. Más szerverek azonban folyamatosan hibákat színlelnek, ezért annak érdekében, hogy ne kapjanak óránként többszöri riasztást, ezek a jelzők „néma” állapotúak.
Szintén érdemes létrehozni egy sorry szervert (bármelyik legolcsóbb tárhelyen), amely vagy a bocsánatkérő oldalt tartalmazza (ha az összes fő és tartalék szerver leáll), vagy átirányítja az okerr állapotoldalára (például a miénk ) vagy statuspage.io.
Forrás: will.com