In dit artikel wil ik laten zien hoe je eenvoudig en gratis een failover-systeem voor een website (of enige andere internetdienst) kunt opzetten met een combinatie van monitoring en een dynamische DNS-service. Dat wil zeggen, in het geval van problemen met de hoofdwebsite (variërend van een 'PHP Error'-probleem op de pagina tot een gebrek aan ruimte of gewoon een verdacht laag aantal bestellingen in het geval van een webshop), zullen nieuwe bezoekers worden doorgestuurd naar een tweede (derde, enzovoorts) server die zeker werkt, of naar een 'Sorry'-pagina waar vriendelijk wordt uitgelegd dat 'er een probleem is, we zijn al op de hoogte en zijn het aan het oplossen, het wordt snel gerepareerd' (en in dit geval ben je daadwerkelijk alweer op de hoogte en kun je het probleem oplossen).
Leven met of zonder failover?
Totdat er een probleem zich voordoet — is er nauwelijks verschil. Maar als het gebeurt, gebeurt er vaak het volgende zonder failover: je probeert snel te achterhalen wat het probleem is, maar dat lukt niet (back-ups worden niet hersteld, de software werkt om de een of andere reden niet zoals in de documentatie beschreven, enzovoorts), en er is geen tijd, de servers-websites zijn down, klanten bellen, iedereen is nerveus, je probeert het grof en slordig 'met ducttape' op te lossen, vervolgens lijkt het weer op gang te komen met tijdelijke oplossingen en het blijft draaien. Je denkt dat je later alles grondig moet bekijken en mooi moet herstellen, maar er is niets permanenter dan tijdelijke oplossingen.
Nu, hoe dit er mooi uitziet met een failover:
- Error doet zich voor
- Error wordt automatisch gedetecteerd
- Een melding wordt verzonden
- Er wordt overgeschakeld naar een van de reserve-servers
- Kalm en zonder paniek wordt het probleem onderzocht, opgelost en de server wordt weer in gebruik genomen.
In dit systeem kunnen er natuurlijk ook eigen problemen ontstaan, maar toch is de opzet lineair, elke stap hier is eenvoudig en het belangrijkste is — je kunt het apart debuggen, waardoor de kans op een storing in dit systeem veel lager is, en alle acties kunnen worden geautomatiseerd en snel worden uitgevoerd (in tegenstelling tot de taak om een onbekend episch probleem te vinden en op te lossen). Je vliegtuig is geland in een ver land, je zet je telefoon aan en ziet in Telegram de melding dat de server is neergestort, maar alles is goed, de reserve-server is geactiveerd, je kunt je reis voortzetten; je hoeft niet terug te vliegen of via SSH vanuit het dichtstbijzijnde café met WiFi te repareren. Je kijkt ernaar wanneer het jou uitkomt.
De toekomst is er al!
Voorheen was het belangrijkste probleem dat failover vaak een onaanvaardbare oplossing maakte, de kosten. Je moest ofwel dure hardware kopen (en nog duurder personeel inhuren), ofwel iets complex creëren op basis van handleidingen (ik kwam zelfs een optie tegen waarbij twee servers met een null-modemkabel verbonden waren en heartbeat erop uitzonden, zodat de reserve-server op het juiste moment op de hoogte was en het beheer overnam). Tegenwoordig zijn er eenvoudigere en gratis manieren. Als je een website met katten hebt, heb je geen excuus meer als je failover nog niet hebt geïmplementeerd!
Bovendien heb je voor een failover-configuratie een server (of misschien meerdere) nodig, en dat was vroeger een grote kost. Nu kun je een VDS voor een habbekrats krijgen.
De meest betrouwbare website met katten
Voor een praktische illustratie van de oplossing met okerr + dynamic dns hebben we onze eigen website met katten gelanceerd . We houden niet van katten, dus ze zullen daar bijna niet zijn. Er zijn drie websites, die er allemaal ongeveer hetzelfde uitzien (allemaal op hetzelfde sjabloon), maar met verschillende kittens zodat ze gemakkelijk te onderscheiden zijn, en elke site geeft technische informatie om te laten zien hoe failover werkt. De pagina vernieuwt zichzelf elke minuut, maar je kunt altijd op vernieuwen klikken in de browser.
In de technische informatie staat de regel 'status=OK'. Soms simuleren servers problemen en schrijven ze status=ERR. De hoofdserver 'valt' om de 20 minuten van elk uur (0:20, 1:20, 2:20, ...). De reserve-server om de 40 minuten. De laatste server ('sorry'-server) draait altijd. Om de 0 minuten van elk uur, 'herstellen' de hoofd- en de reserve-server.
Als je de website opent en deze openlaat in een tabblad, zie je dat hij nooit uitvalt (hoewel elke afzonderlijke server af en toe een probleem simuleert), en in het geval van een serverprobleem, 'rent' hij gewoon tussen de actieve servers. De afbeelding, de naam en het adres van de server en zijn rol zullen veranderen. Soms kun je het moment vangen wanneer status=ERR is (het probleem is er al, maar het hele failover-schema is nog niet uitgewerkt), maar de volgende update laat je een pagina zien van de werkende site.
Failover op okerr + dynamic DNS
Laten we kijken hoe dit onder de motorkap werkt. De taak van de failover is ervoor te zorgen dat het adres cat.okerr.com altijd naar het IP-adres van de werkende server verwijst.
Achter elke server die onze katwebsite op okerr host, zit een indicator die eens per minuut zijn status controleert.
Op deze screenshot zien we hoe de site cat.okerr.com wordt gecontroleerd vanaf server alpha.okerr.com. De pagina zou status=OK moeten bevatten, en zoals we hierboven zien, is de status van onze indicator momenteel OK. Wanneer de server 'defect' is, wordt het ERR. (Dit is slechts één voorbeeld van een indicator; okerr is monitoring, dus je kunt elk type indicator koppelen, bijvoorbeeld het controleren van de vrije schijfruimte, het aantal nieuwe bestellingen in de database, en zelfs logische indicatoren, zoals verschillende foutcriteria 's nachts en overdag).
In de projectinstellingen hebben we een failover-schema met deze indicatoren gemaakt:
In het schema zijn er drie indicatoren (drie servers), verschillend in prioriteit. De hoofdserver voor de website is charlie; als deze niet werkt (niet 'status=OK' heeft of gewoon niet toegankelijk is), dan worden bravo en in laatste instantie alpha gebruikt. Aan de rechterkant van de pagina wordt de status van de DNS-registratie op verschillende servers weergegeven.
Voor degenen die hebben opgemerkt dat de naam cat.he.okerr.com wordt gebruikt: we gebruiken een iets complexer schema. In plaats van alleen de DNS-registratie van cat.okerr.com te wijzigen, wijzigen we cat.he.okerr.com (op een Dynamic DNS-provider ), en cat.okerr.com is een CNAME (alias) die niet verandert en altijd naar cat.he.okerr.com verwijst. We vinden Hurricane gewoon leuker als dynamische DNS, en het heeft sleutels voor het beheren van een afzonderlijke registratie (en niet het hele domein), wat wij veiliger vinden. Je kunt ook de wachtwoorden-sleutels voor het beheren van het hele domein niet op okerr opgeven, maar alleen voor een subdomein of registratie.
Van storing naar herstel
Stap voor stap hoe dit schema werkt:
- Er doet zich een probleem voor (gesimuleerd) op de server.
- De okerr-sensor controleert elke minuut de status van elke server en rapporteert dit aan de hoofserver van het project in okerr.
- De indicator van de betreffende server verandert de status van OK naar ERR.
- Bij een statuswijziging van de indicator wordt de failover opnieuw berekend en wordt vastgesteld welk adres moet worden ingesteld (indien nodig. Bijvoorbeeld, als de hoofdserver werkt en ondertussen is de reserve-server uitgevallen, zullen er geen wijzigingen plaatsvinden).
- Dit adres wordt gerapporteerd aan de dynamische DNS-service. Bij het voltooien van deze stap zie je aan de rechterkant de status 'gesynchroniseerd'.
- Zeer snel (in seconden) zal de registratie de DNS-servers van jouw domein bereiken (voor de katwebsite is dat ns1-ns5.he.net).
- Vanaf dit moment zullen sommige gebruikers al toegang hebben tot de nieuwe live server. Maar nog niet alle DNS-servers ter wereld hebben de records bijgewerkt, en ergens kan nog steeds de oude record in de cache staan. Je kunt zien hoe de gegevens op publieke DNS-servers 'dansen', waarbij soms de nieuwe en soms de oude waarde wordt weergegeven. Als je de pagina met de failover-instellingen bijwerkt, vraagt okerr zelf nieuwe gegevens op bij de DNS-servers.
- Nadat de gegevens zijn gestabiliseerd, is de oude gecachte record overal vervallen — 100% van de verzoeken gaat naar de nieuwe server.
Om stap 7 (vaak de langste) te versnellen, moet de TTL van het dynamische DNS-record zo laag mogelijk worden ingesteld. Gewoonlijk staan diensten intervallen van 90-120 seconden toe. Dit is een redelijke compromie.
Aanvullend
Dit kan je in een avond instellen (als je al een duplicate server hebt). Zowel okerr als de dynamische DNS-diensten zijn gratis. Om bij okerr meer controles en een kortere controleperiode te krijgen, moet je een training volgen (via de profielpagina). Na het voltooien wordt het niveau meteen verhoogd (20 indicatoren per uur + 1 snelle, 10 minuten durende). En als dat niet genoeg is — stuur een e-mail naar support@okerr.com, waarschijnlijk kunnen we dat verhogen (tot nu toe was er altijd een mogelijkheid, ik heb nooit geweigerd, integendeel, ik heb het zelf aangeboden). Maar ik wil niet beloven dat alles voor iedereen mogelijk is, ik ben niet zeker of we genoeg capaciteit hebben om ons woord na te komen. Maar momenteel zijn er nog niet veel gebruikers, dus er zijn geen problemen met het verhogen van de limieten.
Wat kan okerr eigenlijk — kijk op de website . In feite is dit monitoring (zabbix uit de cloud), en de filever is een leuke extra functie. Ook kun je zonder registratie de demo op de site bekijken.
Bij een wijziging van de status van de indicator wordt er een melding naar je e-mail of Telegram gestuurd. (We hebben hier gekeken wat er gebeurt en begrepen dat Telegram blijkbaar de meest betrouwbare messenger is. Bedankt RKF voor de stresstest!) Bij de juiste configuratie van okerr is elke melding ofwel een signaal 'stop alles, we moeten het repareren!', ofwel 'afgelast!'. Er zouden geen onnodige alerts van okerr moeten zijn (als die er zijn — moet je de configuratie anders instellen). Bijvoorbeeld, voor onze kattenwebsite simuliert de server alpha nooit een fout. Als hij uitvalt, moeten we dat weten. Maar de andere servers simuleren voortdurend fouten, daarom hebben we voor die indicatoren de status 'stil' ingesteld, zodat we niet meerdere keren per uur alerts ontvangen.
Het is ook verstandig om een sorry-server op te zetten (op een van de goedkoopste hostingdiensten), die ofwel uw excuses-pagina bevat (voor het geval dat al uw hoofd- en back-upservers uitvallen) of doorverwijst naar de statuspagina op okerr (bijvoorbeeld onze ) of statuspage.io.
Bron: habr.com
