Ebben a cikkben azt szeretném bemutatni, hogyan lehet könnyedén és ingyenesen létrehozni egy failover rendszert egy weboldalhoz (vagy bármely más internetes szolgáltatáshoz) a monitorozás kombinációjával és a dinamikus DNS szolgáltatással. Tehát ha bármilyen probléma adódik a fő weboldallal (kezdve a „PHP Error” hibaüzenettől az oldalon, egészen addig, hogy a tárhely elfogyott, vagy egyszerűen gyanúsan kevés a rendelés egy online bolt esetében), az új látogatók egy második (harmadik, és így tovább) működő szerverre, vagy egy „Sajnáljuk” oldalra lesznek irányítva, ahol udvariasan elmagyarázzák, hogy „probléma merült fel, már tudunk róla és javítunk, hamarosan megoldjuk” (és valójában Ön is tudni fog arról, hogy a probléma fennáll és tudja orvosolni).
Élnél failover nélkül vagy sem?
Amíg nem történik valamilyen probléma, addig nem különösebben számít. De amikor bekövetkezik, failover hiányában gyakran a következő történik: megpróbálsz gyorsan kideríteni, mi a probléma, de nem sikerül (a biztonsági mentések nem működnek, a szoftver valamiért nem működik a dokumentáció szerint, stb.), de nincs idő, a weboldalak leállnak, az ügyfelek telefonálnak, mindenki ideges, próbálsz valahogy „ragasztóval” megoldani, majd valahogy mégiscsak beindul, de csak kötéssel és él. Azt hiszed, hogy majd szabadidődben részletesebben utánajársz és szép rendbehoznál mindent, de nincs állandóbb, mint a ideiglenes megoldás.
Most pedig nézzük, hogyan zajlik mindez egy jól megtervezett failover esetén:
- Hiba történik
- A hiba automatikusan észlelésre kerül
- Értesítés kiküldése
- A váltás egyik tartalék szerverre történik
- Nyugodtan és pánik nélkül kezeljük a problémát, orvosoljuk és a szerver ismét működőképes.
Ebben a megoldásban természetesen felmerülhetnek saját problémák, de mégis, a séma lineáris, minden lépés egyszerű, és ami a legfontosabb, külön-külön is tesztelhető, ezért az esélye a hiba előfordulásának sokkal alacsonyabb, és minden művelet automatizálható és gyorsan végrehajtható (ellentétben azzal a feladattal, hogy megtaláljuk és kijavítsuk egy ismeretlen, epikus hibát). A repülőgéped egy távoli országban landolt, bekapcsolod a telefonodat, és látod a Telegramon az értesítést, hogy a szerver megállt, de minden rendben van, aktiválódott a tartalék szerver, folytathatod az utadat, nem kell visszarepülnöd, vagy SSH-n keresztül javítanod a legközelebbi WiFi-s kávézóból. Akkor fogod kezelni, amikor megfelel neked.
A jövő már itt van!
Korábban a fő probléma, ami miatt a failover gyakran elfogadhatatlan megoldásnak számított, az annak költségében rejlett. Vagy drága hardvereket kellett vásárolni (és még drágább szakembereket hívni), vagy valami bonyolultat kellett házilag összerakni (én láttam már olyan megoldást is, ahol két szerver egy null-modem kábelen keresztül összekapcsolódik, és rajta heartbeat-et küldenek, hogy a tartalék szerver a megfelelő időben értesüljön, és átvegye az irányítást). Most már léteznek egyszerűbb és ingyenes megoldások. Ha van egy macskás weboldalad, akkor nincs mentséged, ha még nem valósítottad meg a failovert!
Ráadásul a failover séma megvalósításához egy (vagy akár több) szerverre is szükség van, amit korábban nagy költségként könyveltek el, most viszont VDS-t kaphatsz fillérekért.
A legmegbízhatóbb macskás weboldal
A megoldás praktikus illusztrálására az okerr + dinamikus dns segítségével elindítottuk a saját macskás weboldalunkat . A macskákat nem szeretjük, ezért ott majdnem nem lesznek. Összesen három weboldal van, mindegyik körülbelül ugyanúgy néz ki (minden azonos sablonon), de különböző cicákkal, hogy könnyen meg lehessen különböztetni őket, és mindegyik technikai információt ír, hogy látható legyen, hogyan működik a failover. Az oldal minden percben automatikusan frissül, de mindig rákattinthatsz a böngészőben a frissítésre.
A technikai információban szerepel egy sor, "status=OK". Néha a szerverek szimulálnak problémákat, és "status=ERR"-t írnak. A fő szerver „mintha leállna” minden óra 20. percében (0:20, 1:20, 2:20, …). A tartalék (backup) szerver 40 percben. Az utolsó szerver („sajnálom” szerver) mindig működik. Minden óra 0. percében a fő és a tartalék szerver „helyreáll”.
Ha megnyitod a weboldalt, és nyitva hagyod a fülön, láthatod, hogy az sosem esik le (bár minden egyes szerver időnként szimulál egy problémát), a szerverprobléma esetén egyszerűen "ugrik" a működő szerverek között. A kép, a név és a szerver címe, valamint a szerepe változni fog. Néha el lehet kapni azt a pillanatot, amikor a status=ERR (a probléma már fennáll, de az egész failover séma még nem működik), de a következő frissítés már egy működő weboldalt fog mutatni.
Failover okerr + dinamikus DNS
Nézzük meg, hogyan működik ez a háttérben. A filever feladata az, hogy a cat.okerr.com cím mindig a működő szerver IP címére mutasson.
Minden szerver mögött, amely a cat.okerr weboldalt tartja, van egy indikátor, amely percenként ellenőrzi annak állapotát.
Ezen a képernyőképen látjuk, hogyan ellenőrzi a cat.okerr.com weboldalt az alpha.okerr.com szerverről. A lapnak tartalmaznia kell a status=OK-t, és amint azt az előbb láttuk, az indikátorunk állapota most OK. Amikor a szerver "megsérül", ERR lesz. (Ez csak egy példája az indikátornak, az okerr egy monitorozás, tehát bármilyen típusú indikátort lehet hozzáadni, például ellenőrizni a szabad lemezhelyet, az új megrendelések számát az adatbázisban, és még logikai indikátorokat is, például éjjel más hiba kritériumok lehetnek, mint nappal).
A projekt beállításaiban létrehoztunk egy failover sémát ezekkel az indikátorokkal:
A sémában három indikátor van (három szerver), különböző prioritásokkal. A weboldal fő szervere a charlie, ha az nem működik (nincs "status=OK" vagy egyszerűen nem elérhető), akkor a bravo, és végső esetben az alpha. Az oldal jobb oldalán látható a DNS bejegyzés állapota különböző szervereken.
Aki észrevette, hogy a cat.he.okerr.com nevet használjuk: egy kicsit bonyolultabb sémát használunk. Ahelyett, hogy egyszerűen módosítanánk a DNS bejegyzést a cat.okerr.com címen, a cat.he.okerr.com -ot módosítjuk (a Dinamikus DNS szolgáltatónál ), míg a cat.okerr.com egy CNAME (alias), amely nem változik, mindig a cat.he.okerr.com -ra mutat. A Hurricane-t egyszerűen jobban szeretjük dinamikus DNS-ként, és van kulcsunk a különálló bejegyzés kezelésére (és nem az egész zóna), így ezt biztonságosabbnak tartjuk. Te is megadhatod az okerr-ben a jelszavakat-kulcsokat az egész domain irányítása helyett, csupán az aldomainhez vagy bejegyzéshez.
Az eséstől a felemelkedésig
Lépésről lépésre, hogyan működik ez a séma:
- Előfordul (szimulálva) probléma a szerveren
- Az okerr érzékelő percenként ellenőrzi minden szerver állapotát, és jelzi a projekt fő szerverének az okerr-en.
- A megfelelő szerver indikátora állapota OK-ról ERR-re változik.
- Az indikátor státuszának megváltozása esetén újraszámításra kerül a failover, és kiszámítódik, hogy melyik címet kell beállítani (ha szükséges. Például, ha az alapértelmezett szerver működik, míg a tartalék szerver elromlott — nem történik változás).
- Ez a cím továbbítódik a dinamikus DNS szolgáltatáshoz. Ennek a lépésnek a befejezése után jobbra látni fogja a 'szinkronizálva' státuszt.
- Hamarosan (másodpercen belül) a bejegyzés eljut a domainje DNS szervereihez (a köztudat szerint ezek ns1-ns5.he.net).
- Ettől a pillanattól kezdve néhány felhasználó már az új aktív szerverre fog eljutni. De még nem minden DNS szerver a világon frissítette a bejegyzéseket, és néhol még a régi bejegyzés tárolva lehet. Látni lehet, ahogy az adatok a nyilvános DNS szervereken 'táncolnak', mutatva az új és régi értékek váltakozását. Ha frissíti a failover beállítási oldalát, az okerr önállóan kérni fogja az új adatokat a DNS szerverektől.
- Miután az adatok stabilizálódtak és a régi cache-elt bejegyzés mindenhol lejárt — az összes 100% kérés az új szerverre irányul.
A 7. lépést (amely gyakran a leghosszabb) felgyorsítva a dinamikus DNS bejegyzés TTL-jét a lehető legalacsonyabbra kell állítani. Általában a szolgáltatások 90-120 másodperces intervallumokat engedélyeznek. Ez egy teljesen ésszerű kompromisszum.
További információ
Mindezt egy este alatt beállíthatja (ha már van egy duplikáló szervere). Az okerr és a dinamikus DNS szolgáltatások ingyenesek. Az okerr-ben több ellenőrzés és rövidebb ellenőrzési idő elnyeréséhez tréninget kell végezni (a profil oldaláról). A tréning elvégzése után azonnal emelkedik a szint (20 indikátor óránként + 1 gyors, 10 perces). Ha ez nem elegendő — írjon a support@okerr.com címre, valószínűleg lehetőség lesz rá, hogy emeljék (eddig mindig volt lehetőség, soha nem utasították el, éppen ellenkezőleg, maguktól kérdezték). Csak kezdetben nem akarok mindenkinek mindent megígérni, nem vagyok biztos benne, hogy elegendő kapacitás van a szavam megtartásához. De mivel a felhasználók száma alacsony, nincsenek problémák a limitek emelésével.
Mit tud egyáltalán az okerr — nézze meg a weboldalon. . Általában ez egy monitorozás (zabbix a felhőből), és a failover egy kellemes kiegészítő funkció. A weboldalról regisztráció nélkül beléphet a demóba.
Az állapotjelző változása esetén értesítés érkezik e-mailben vagy Telegramon. (Megnéztük, mi történik, és rájöttünk, hogy a Telegram a legmegbízhatóbb üzenetküldő. Köszönet az RKN-nek a stressztesztért!) A helyes okerr beállítással minden értesítés vagy azt jelenti: "mindent el kell dobni, javítani kell!", vagy "visszavonás!". Nem lehetnek felesleges értesítések az okerről (ha vannak, azt másképp kell beállítani). Például a mi kotószoftverünk esetében az alpha szerver soha nem szimulál hibákat. Ha elromlik, tudnunk kell. Más szerverek viszont folyamatosan szimulálnak hibákat, ezért hogy ne kapjunk értesítéseket óránként többször, azokon az állapotjelzőkön "csendes" státusz van.
Érdemes egy bocsánatkérő szervert is létrehozni (bármilyen olcsó tárhelyszolgáltatón), amely vagy a bocsánatkérő oldaladat tartalmazza (ha minden fő és tartalék szerver leállt), vagy átirányít a okerr állapotoldalára (például a mi ) vagy a statuspage.io-ra.
Forrás: habr.com
