W tym artykule chcę pokazać, jak łatwo i za darmo można stworzyć schemat failover dla strony internetowej (lub jakiejkolwiek innej usługi internetowej) na podstawie monitoringu i dynamicznej usługi DNS. Oznacza to, że w przypadku jakichkolwiek problemów z główną stroną (począwszy od problemów z „PHP Error” na stronie, a skończywszy na braku miejsca lub po prostu podejrzanie małej liczbie zamówień w przypadku sklepu internetowego), nowi odwiedzający będą kierowani na drugi (trzeci, itd.) w pełni funkcjonalny serwer lub na stronę „Przepraszamy”, gdzie zostanie im grzecznie wyjaśnione, że „jest problem, już o tym wiemy i naprawiamy, wkrótce się uda” (a w tym przypadku faktycznie będziesz już świadomy sytuacji i będziesz mógł to naprawić).
Żyć z failover czy bez?
Dopóki nie wystąpi jakiś problem — nie ma większej różnicy. Ale kiedy wystąpi, to bez failovera często dzieje się to: próbujesz szybko zrozumieć, co jest problemem, nie udaje się (kopie zapasowe nie działają, oprogramowanie nie działa zgodnie z dokumentacją itp.), a czasu nie ma, serwery-strony leżą, klienci dzwonią, wszyscy są zdenerwowani, próbujesz jakoś naprawić „na szybko”, a potem jakoś z pomocą obejścia uruchamia się i przeżywa. Myślisz, że w wolnej chwili trzeba by to wszystko znowu ogarnąć i zrobić ładnie, ale nie ma nic bardziej trwałego niż rozwiązania tymczasowe.
Teraz, jak to wygląda w ładnym wariancie z failoverem:
- Błąd występuje
- Błąd jest wykrywany automatycznie
- Wysyłane jest powiadomienie
- Następuje przełączenie na jeden z serwerów zapasowych
- Spokojnie i bez paniki rozwiązywana jest sprawa, naprawiana jest sytuacja i serwer znów wraca do pracy.
W tym schemacie mogą również wystąpić swoje problemy, ale jest to schemat liniowy, każdy etap jest prosty i co najważniejsze — można go odłączyć oddzielnie, dlatego ryzyko awarii tego schematu jest znacznie niższe, a wszystkie działania mogą być zautomatyzowane i realizowane szybko (w przeciwieństwie do zadania znalezienia i naprawienia nieznanej, epickiej usterki). Twój samolot wylądował w odległym kraju, włączasz telefon i widzisz w telegramie powiadomienie, że serwer padł, ale wszystko w porządku, aktywował się serwer zapasowy, możesz kontynuować swoją podróż, nie musisz wracać ani naprawiać po SSH z najbliższej kawiarni z WiFi. Rozwiążesz to, kiedy będzie to wygodne.
Przyszłość jest już tutaj!
Dawniej głównym problemem, który czynił failover często nieakceptowalnym rozwiązaniem, były koszty związane z jego wdrożeniem. Trzeba było albo kupić drogi sprzęt (i zatrudnić jeszcze droższych specjalistów), albo kombinować coś skomplikowanego według poradników (spotkałem się nawet z wariantem, w którym dwa serwery łączyły się dodatkowym kablem null-modem, aby przesyłać heartbeat i w odpowiednim momencie zapasowy serwer się o tym dowiadywał i przejmował kontrolę). Teraz są prostsze i darmowe sposoby. Jeśli masz stronę z kotami — nie masz usprawiedliwienia, jeśli jeszcze nie wdrożyłeś failoveru dla niej!
Ponadto, aby zrealizować schemat failover, potrzebny jest jeszcze serwer (a może i nie jeden), co kiedyś wiązało się z dużymi kosztami; teraz można wziąć VDS-a za grosze.
Najbardziej niezawodna strona z kotami
Dla praktycznej ilustracji rozwiązania z okerr + dynamic dns uruchomiliśmy naszą stronę z kotami . Nienawidzimy kotów, dlatego praktycznie ich tam nie będzie. Jest trzy strony, każda wygląda mniej więcej tak samo (wszystkie na tym samym szablonie), ale z różnymi kociakami, aby łatwo je odróżnić, i każda podaje informacje techniczne, aby zobaczyć, jak działa failover. Strona odświeża się sama co minutę, ale zawsze można kliknąć odśwież w przeglądarce.
W informacji technicznej znajduje się linijka „status=OK”. Czasami serwery symulują problemy i podają status=ERR. Główny serwer „jakby pada” co 20 minut każdej godziny (0:20, 1:20, 2:20, …). Zapewniający (backup) serwer o 40 minut. Ostatni serwer („sorry”-serwer) działa zawsze. O 0 minut każdej godziny główny i zapasowy serwer „przywracają się”.
Jeśli otworzysz stronę i pozostawisz ją na karcie — zobaczysz, że nigdy nie pada (choć każdy pojedynczy serwer okresowo symuluję problem), a w przypadku problemu z serwerem, po prostu „przemieszcza się” między działającymi serwerami. Będzie zmieniać się obrazek, nazwa i adres serwera oraz jego rola. Czasami można złapać moment, kiedy status=ERR (problem już jest, ale cały schemat failover jeszcze nie zadziałał), ale już następne odświeżenie pokaże Ci stronę z działającego serwera.
Failover na okerr + dynamic DNS
Zobaczymy, jak to działa pod maską. Zadaniem failovera jest, aby adres cat.okerr.com zawsze wskazywał na IP działającego serwera.
Za każdym z serwerów, które utrzymują naszą stronę kotów w okerr, znajduje się wskaźnik, który co minutę sprawdza jego stan.
Na tym zrzucie ekranu widzimy, jak sprawdzana jest strona cat.okerr.com z serwera alpha.okerr.com. Strona powinna zawierać status=OK, a jak widzimy u góry, status wskaźnika to obecnie OK. Gdy serwer „się zepsuje”, pojawi się ERR. (To tylko jeden przykład wskaźnika, okerr — to monitorowanie, więc można podłączyć dowolny typ wskaźnika, na przykład sprawdzający wolne miejsce na dysku, liczbę nowych zamówień w bazie, a nawet logiczne wskaźniki, na przykład w nocy będą jedno kryteria błędu, a w ciągu dnia inne).
W ustawieniach projektu stworzyliśmy schemat awaryjny z tymi wskaźnikami:
W schemacie są trzy wskaźniki (trzy serwery), różne pod względem priorytetów. Główny serwer dla strony to charlie, jeśli nie działa (nie będzie „status=OK” lub po prostu jest niedostępny), to następny jest bravo, a w ostatnim przypadku — alpha. W prawej części strony pokazany jest stan rekordu DNS na różnych serwerach.
Dla tych, którzy zauważyli, że używane jest imię cat.he.okerr.com: Używamy nieco bardziej skomplikowanej schemy. Zamiast po prostu zmieniać rekord DNS cat.okerr.com, zmieniamy cat.he.okerr.com (u dostawcy Dynamic DNS ), a cat.okerr.com to CNAME (alias), który się nie zmienia, zawsze wskazuje na cat.he.okerr.com. Hurricane po prostu bardziej nam odpowiada jako dynamiczny DNS i ma klucze do zarządzania pojedynczym rekordem (a nie całą strefą), co wydaje się nam bezpieczniejsze. Możesz również nie podawać w okerr haseł-kluczy do zarządzania całą domeną, a jedynie dla subdomeny lub rekordu.
Od upadku do wzlotu
Po krokach, jak działa ta schemata:
- Zdarza się (symuluje) problem na serwerze
- Czujnik okerr co minutę sprawdza stan każdego serwera i informuje główny serwer projektu w okerr
- Wskaźnik odpowiedniego serwera zmienia stan z OK na ERR
- Po zmianie statusu wskaźnika, przelicza się failover, oblicza, jaki adres należy ustawić (jeśli to konieczne. Na przykład, jeśli działa główny serwer, a w tym czasie awaryjny się zepsuł — nie będzie żadnych zmian)
- Ten adres jest przekazywany do usługi dynamicznego DNS. Po zakończeniu tego etapu po prawej zobaczysz status „zsynchronizowany”
- Bardzo szybko (w ciągu kilku sekund) rekord dotrze do serwerów DNS Twojej domeny (w przypadku strony kotów są to ns1-ns5.he.net).
- Od tego momentu niektórzy użytkownicy już będą trafiać na nowy serwer na żywo. Jednak nie wszystkie serwery DNS na świecie zaktualizowały rekordy, więc gdzieś może być jeszcze zbuforowany wcześniejszy wpis. Można zauważyć, że dane na publicznych serwerach DNS „skaczą”, pokazując to nową, to starą wartość. Jeśli odświeżysz stronę ustawień failover, okerr sam zażąda nowych danych z serwerów DNS.
- Po stabilizacji danych, stary zbuforowany rekord wszędzie wygasł — 100% zapytań trafia na nowy serwer.
Aby przyspieszyć 7 etap (często — najdłuższy), TTL dynamicznego rekordu DNS należy ustawić jak najniżej. Zazwyczaj usługi umożliwiają interwały 90-120 sekund. To całkiem rozsądny kompromis.
Dodatkowo
Wszystko to można skonfigurować w ciągu wieczoru (jeśli masz już serwer zapasowy). Zarówno okerr, jak i usługi dynamicznego DNS są darmowe. Aby uzyskać w okerr więcej sprawdzeń i krótszy okres kontroli, należy ukończyć szkolenie (ze strony profilu). Po ukończeniu poziom od razu wzrasta (20 wskaźników na godzinę + 1 szybki, 10-minutowy). A jeśli będzie ich za mało — napisz na support@okerr.com, prawdopodobnie będzie można je zwiększyć (dotychczas zawsze była taka możliwość, nigdy nie odmówiono, wręcz przeciwnie, sam proponowano). Po prostu na początku nie chcę obiecywać wszystkim wszystkiego, nie jestem pewien, czy wystarczy mocy, by dotrzymać słowa. Ale jak na razie użytkowników jest mało, więc nie ma problemów z zwiększaniem limitów.
Co może zrobić okerr — sprawdź na stronie . Właściwie to monitoring (zabbix w chmurze), a plikownik to miła funkcja dodatkowa. Można również wejść na stronę w wersji demo bez rejestracji.
Przy zmianie stanu wskaźnika — wysyłane jest powiadomienie na adres e-mail lub do Telegramu. (Zobaczyliśmy, co się dzieje i zrozumieliśmy, że wydaje się, że Telegram to najbardziej niezawodny komunikator. Dziękujemy RKN za test stresowy!) Przy odpowiednim skonfigurowaniu okerr, każde powiadomienie to albo sygnał „zostawcie wszystko, trzeba naprawić!”, albo „koniec!”. Nie powinno być zbędnych alertów od okerr (jeśli są — trzeba to jakoś ustawić inaczej). Na przykład dla naszej strony koto, serwer alpha to ostatni i nigdy nie symuluje błędu. Jeśli on padnie — musimy to wiedzieć. Reszta serwerów nieustannie symuluje błędy, dlatego, aby nie otrzymywać alertów kilka razy na godzinę, te wskaźniki mają status „cichy”.
Warto również zarejestrować serwer przepraszający (na najtańszym hostingu), który będzie albo zawierał Twoją stronę przeprosin (na wypadek, gdyby wszystkie główne i zapasowe serwery były niedostępne), albo przekieruje na stronę statusu na okerr (na przykład nasza ) lub statuspage.io.
Źródło: habr.com
