In dit artikel wil ik laten zien hoe eenvoudig en gratis je een failover-schema kunt maken voor een website (of een andere internetdienst) met behulp van een combinatie van monitoring en dynamische DNS-service. Dat wil zeggen dat in geval van problemen met de hoofdsite (van een probleem met een “PHP-fout” op de pagina, tot ruimtegebrek of simpelweg een verdacht klein aantal bestellingen in het geval van een online winkel), nieuwe bezoekers zullen worden doorverwezen naar de tweede (derde, enzovoort) verder) een bekende werkende server, of naar de “Sorry” -pagina, waar ze beleefd zullen uitleggen dat “er een probleem is, we zijn ons er al van bewust en zijn het al aan het oplossen, we zal het snel repareren” (en in dit geval bent u eigenlijk al op de hoogte en kunt u repareren).
Leven met failover of zonder?
Tot er zich een probleem voordoet, is er niet veel verschil. Maar als het gebeurt, zonder failover, gebeurt vaak het volgende: je probeert er snel achter te komen wat het probleem is, het werkt niet (back-ups worden niet geïmplementeerd, de software werkt om de een of andere reden niet zoals het zou moeten volgens de documentatie , enz.), maar er is geen tijd, geen server - de sites liggen stil, klanten bellen, iedereen staat op scherp, je probeert het op de een of andere manier ruw en vies op te lossen "met tape", en dan lijkt het op de een of andere manier op te starten met krukken en levens. Je denkt dat je het in je vrije tijd gedetailleerder moet uitzoeken en alles mooi opnieuw moet doen, maar er is niets blijvender dan tijdelijk.
Hoe dit nu gebeurt in een prachtige versie met een filer:
- Er gebeurt een fout
- De fout wordt automatisch gedetecteerd
- Er wordt een waarschuwing verzonden
- Het overstappen naar een van de back-upservers wordt overgedragen
- Rustig en zonder paniek wordt het probleem opgelost, gecorrigeerd en wordt de server weer in gebruik genomen.
Dit schema kan natuurlijk ook zijn eigen problemen hebben, maar toch is het schema lineair, elke fase is eenvoudig en het belangrijkste is dat er afzonderlijk fouten kunnen worden opgespoord, dus de kans op falen van dit schema is veel kleiner, en alle acties kunnen worden geautomatiseerd en snel worden uitgevoerd (in tegenstelling tot de taak van het vinden en repareren van onbekende epische onzin). Je vliegtuig is in een ver land geland, je zet je telefoon aan en ziet een melding in een telegram dat de server is gecrasht, maar alles is in orde, de back-upserver is geactiveerd, je kunt je reis voortzetten, je hebt geen om terug te vliegen of te repareren via SSH vanuit het dichtstbijzijnde café met WiFi. Je komt er wel achter wanneer het handiger is.
De toekomst is er al!
Voorheen was het grootste probleem dat failover vaak een onaanvaardbare oplossing maakte, de hoeveelheid kosten die het kost. Of het was nodig om dure hardware aan te schaffen (en nog duurdere specialisten uit te nodigen). Of collectieve boerderij iets ingewikkelds volgens de handleidingen (ik kwam zelfs een optie tegen waarbij twee servers extra verbonden zijn met een nulmodemkabel, en ze sturen daar een hartslag doorheen, zodat op het juiste moment de back-upserver het herkent en het overneemt controle). Nu zijn er eenvoudigere en gratis manieren. Als u een website met katten heeft, is er geen excuus om er nog geen failover voor te implementeren!
Nou ja, bovendien heb je voor een failover-schema een andere server nodig (en misschien meer dan één) en voorheen was dit een grote uitgave, nu kun je voor een paar centen een VDS krijgen.
De meest betrouwbare site met katten
Om de oplossing met okerr + dynamische dns praktisch te illustreren, hebben we onze website met katten gelanceerd . We haten katten, dus er zullen er niet veel zijn. Er zijn in totaal drie sites, elke site ziet er ongeveer hetzelfde uit (allemaal op dezelfde sjabloon), maar met verschillende kittens om het gemakkelijk te maken om ze te onderscheiden, en elke site schrijft technische informatie om te zien hoe failover werkt. De pagina wordt elke minuut bijgewerkt, maar u kunt altijd op 'herladen' in de browser klikken.
In de technische informatie staat de regel “status=OK”. Soms veinzen servers problemen en schrijven ze status=ERR. De hoofdserver “lijkt te crashen” om de 20 minuten van elk uur (0:20, 1:20, 2:20, …). Back-upserver in 40 minuten. De laatste server (“sorry” server) is altijd actief. Om de 0 minuten van elk uur worden de primaire en back-upservers “hersteld”.
Als u de site opent en op het tabblad laat staan, zult u zien dat deze nooit crasht (hoewel elke individuele server periodiek een probleem simuleert), en in het geval van een probleem met de server, deze eenvoudigweg tussen live servers "draait". De afbeelding, naam en adres van de server en zijn rol zullen veranderen. Soms kunt u het moment opvangen waarop status = ERR (het probleem bestaat al, maar het hele failover-schema heeft nog niet gewerkt), maar de volgende update toont u een pagina van de werkende site.
Failover op okerr + dynamische DNS
Laten we eens kijken hoe het werkt onder de motorkap. De taak van de filer is ervoor te zorgen dat het cat.okerr.com-adres altijd verwijst naar het IP-adres van de werkende server.
Achter elk van de servers die onze kattensite in okerr hosten, bevindt zich een indicator die de status ervan één keer per minuut controleert.
In deze schermafbeelding zien we hoe de site cat.okerr.com wordt gecontroleerd vanaf de alpha.okerr.com-server. De pagina zou status=OK moeten bevatten, en zoals we hierboven zien, is onze indicatorstatus nu OK. Wanneer de server “breekt”, zal er een ERR zijn. (Dit is slechts één voorbeeld van een indicator die okerr controleert, dus u kunt elk type indicator toevoegen, bijvoorbeeld de vrije ruimte op de schijf, het aantal nieuwe bestellingen in de database en zelfs logische indicatoren controleren , 's nachts zullen er enkele foutcriteria zijn, en overdag andere).
In de projectinstellingen hebben we een failover-schema gemaakt met deze indicatoren:
Het schema heeft drie indicatoren (drie servers), verschillend qua prioriteit. De hoofdserver voor de site is Charlie, als deze niet werkt (hij heeft geen “status=OK” of is simpelweg niet beschikbaar), dan bravo en in het laatste geval - alpha. De rechterkant van de pagina toont de status van het DNS-record op verschillende servers.
Voor degenen die hebben opgemerkt dat de naam cat.he.okerr.com wordt gebruikt: we gebruiken een iets complexer schema. In plaats van alleen het DNS-record van cat.okerr.com te wijzigen, veranderen we cat.he.okerr.com (op de dynamische DNS-provider ), en cat.okerr.com is een CNAME (alias), die niet verandert, verwijst altijd naar cat.he.okerr.com. We vinden Hurricane gewoon beter als een dynamische DNS, en het heeft sleutels om één enkele invoer te beheren (in plaats van een hele zone), we denken dat het veiliger is. Ook hoef je in okerr geen sleutelwachtwoorden op te geven om het hele domein te beheren, maar alleen voor een subdomein of record.
Van vallen naar stijgen
Stap voor stap hoe dit schema werkt:
- Er doet zich een probleem voor (gesimuleerd) op de server
- De okerr-sensor controleert één keer per minuut de status van elke server en rapporteert aan de hoofdprojectserver in okerr
- De overeenkomstige serverindicator verandert van OK in ERR
- Wanneer de status van de indicator verandert, wordt de failover opnieuw berekend en wordt berekend welk adres moet worden ingesteld (indien nodig). Als de hoofdserver bijvoorbeeld werkt en tegelijkertijd de back-upserver is overleden, worden er geen wijzigingen doorgevoerd. gemaakt)
- Dit adres wordt gerapporteerd aan de dynamische DNS-service. Na voltooiing van deze fase ziet u aan de rechterkant de status 'gesynchroniseerd'.
- Zeer binnenkort (seconden) zal de record de DNS-servers van uw domein bereiken (voor de cat-site is dit ns1-ns5.he.net).
- Vanaf dit moment zullen een aantal gebruikers al op de nieuwe live server staan. Maar nog niet alle DNS-servers ter wereld hebben de records bijgewerkt en het oude record kan nog ergens in de cache staan. Je kunt zien hoe de gegevens op openbare DNS-servers ‘dansen’, waarbij een nieuwe of oude waarde wordt weergegeven. Als u de failover-configuratiepagina bijwerkt, vraagt de operator zelf nieuwe gegevens op bij de DNS-servers.
- Nadat de gegevens zijn gestabiliseerd, is het oude in de cache opgeslagen record overal verrot - alle 100% van de verzoeken gaan naar de nieuwe server.
Om fase 7 (vaak de langste) te versnellen, moet de TTL van het dynamische DNS-record zo laag mogelijk worden ingesteld. Normaal gesproken staan bij services intervallen van 90-120 seconden toe. Dit is een volkomen redelijk compromis.
bovendien
Dit alles kan in een avond worden geconfigureerd (als u al over een backupserver beschikt). Zowel okerr als dynamische DNS-services zijn gratis. Om meer controles in okerr en een kortere verificatieperiode te krijgen, moet u de training voltooien (vanaf uw profielpagina). Na voltooiing gaat het niveau onmiddellijk omhoog (20 indicatoren per uur + 1 snelle, 10 minuten). En als er maar weinig zijn, schrijf dan naar [e-mail beveiligd], hoogstwaarschijnlijk zal het mogelijk zijn om te vergroten (tot nu toe is er altijd een kans geweest, ik heb nooit geweigerd, integendeel, ik heb het zelf aangeboden). Het is alleen dat ik in eerste instantie niet iedereen alles wil beloven, ik weet niet zeker of ik voldoende capaciteit heb om mijn woord te houden. Maar tot nu toe zijn er weinig gebruikers, dus er zijn geen problemen met het verhogen van de limieten.
Wat okerr in het algemeen kan doen - kijk op de website . Over het algemeen is dit monitoring (zabbix uit de cloud), en de filer is een leuke extra functie. U kunt ook zonder registratie toegang krijgen tot de demo vanaf de site.
Wanneer de status van de indicator verandert, wordt er een melding verzonden per e-mail of Telegram. (We keken naar wat er gebeurde en realiseerden ons dat telegram de meest betrouwbare boodschapper lijkt te zijn. Met dank aan RKN voor de stresstest!) Als okerr correct is geconfigureerd, is elke melding een signaal: “Laat alles vallen, we moeten het repareren!” , of “licht uit!” Er mogen geen extra waarschuwingen van de okerra zijn (als die er zijn, moeten ze op de een of andere manier anders worden geconfigureerd). Voor onze kattensite is de alfaserver bijvoorbeeld de laatste en maakt deze nooit een fout. Als hij gaat liggen, moeten we het weten. Maar andere servers veinzen voortdurend fouten, dus om niet meerdere keren per uur waarschuwingen te ontvangen, hebben deze indicatoren een "stille" status.
Het is ook zinvol om een sorry-server te maken (op elke goedkoopste hosting), die ofwel uw verontschuldigingspagina zal hebben (voor het geval alle hoofd- en back-upservers niet beschikbaar zijn) of u zal doorverwijzen naar de statuspagina op okerr (bijvoorbeeld de onze ) of statuspagina.io.
Bron: www.habr.com