В тази статия искам да покажа колко лесно и безплатно можете да създадете схема за failover за уебсайт (или друга интернет услуга) с комбинация от мониторинг и динамична DNS услуга. Тоест, в случай на каквито и да било проблеми с основния сайт (от проблеми с „PHP Error“ на страницата до недостатъчно място или просто подозрително малък брой поръчки при интернет магазин), новите посетители ще бъдат пренасочени към втория (третия и така нататък) работещ сървър или към страница с надпис „Извинете“, където учтиво им се обяснява, че „има проблем, в курса сме и вече работим по него, скоро ще го поправим“ (а вие в този случай всъщност ще знаете за проблема и ще можете да работите по него).
Да живееш с failover или без него?
Докато не се случи някакъв проблем — няма особена разлика. Но когато се случи, без failover често се получава следното: опитвате се бързо да разберете в чем е проблемът, не успявате (бекъпите не се развиват, софтуерът по някаква причина не работи, както е описано в документацията и т.н.), а времето липсва, сървърите-сайтове не работят, клиентите звъннат, всички са напрегнати, опитвате се да поправите грубо и безредно „на скотча“, след това по някакъв начин стартира и живее с импровизирани решения. Мислите, че в свободното си време ще трябва да се зазнаете по-подробно и да направите всичко красиво, но няма нищо по-постоянно от временното.
Сега как става в красивия вариант с файловера:
- Случва се грешка
- Грешката се открива автоматично
- Изпраща се предупреждение
- Превключва се на един от резервните сървъри
- Спокойно и без паника се разглежда проблемът, поправя се и сървърът отново се въвежда в експлоатация.
В тази схема, разбира се, също могат да възникнат своите проблеми, но все пак схемата е линейна, всеки етап тук е прост и най-важното — може да бъде отладен отделно, така че шансът за провал на схемата е много по-малък, а всички действия могат да бъдат автоматизирани и извършени бързо (в отличие от задачата да намерите и поправите неизвестна епична неполадка). Вашият самолет е кацнал в далечна страна, включвате телефона и виждате в телеграм съобщение, че сървърът е паднал, но всичко е наред, резервният сървър активиран, можете да продължите пътуването си, не е нужно да летите обратно, нито да поправяте по SSH от най-близкото кафе с WiFi. Ще се разберете, когато бъде удобно.
Бъдещето вече е тук!
По-рано, основният проблем, който правеше failover често неприемливо решение, беше цената за него. Либо трябваше да купите скъпи устройства (и да наемете още по-скъпи специалисти). Либо да се опитате да направите нещо сложно по ръководства (бях виждал дори вариант, при който два сървъра свързват допълнително с нулев модем кабел и предават по него heartbeat, за да може в нужното време резервният сървър да научи и поеме управлението). Сега има по-прости и безплатни решения. Ако имате сайт с котки — нямате оправдание, ако все още не сте реализирали failover за него!
А освен това, за схемата на failover е нужен още един сървър (а може би и не само един) и по-рано това струваше много, сега може да вземете VDS за малко пари.
Най-надеждният сайт с котки
За практическа илюстрация на решението с okerr + динамичен DNS стартирахме нашия сайт с котки . Мразим котките, така че почти няма да ги видите там. Има три сайта, всеки от които изглежда горе-долу еднакво (всички на един шаблон), но с различни котета, за да могат да се различават лесно, и всеки показва техническа информация, за да видите как работи failover. Страницата се обновява сама на всеки 1 минута, но винаги можете да натиснете reload в браузъра.
В техническата информация има редица “status=OK”. Понякога сървърите симулират проблеми и показват status=ERR. Главният сървър “пада” на всеки 20 минути на всеки час (0:20, 1:20, 2:20, …). Резервният (backup) сървър в 40 минути. Последният сървър (“sorry”-сървър) работи постоянно. В 0 минута на всеки час главният и резервният сървър “възстановяват” действието си.
Ако отворите сайта и го оставите в таба — ще видите, че той никога не пада (въпреки че всеки отделен сървър периодично симулира проблем), а при проблем със сървъра просто “бяга” между работещите сървъри. Ще се променят изображението, името и адресът на сървъра и неговата роля. Понякога можете да уловите момента, когато status=ERR (проблемът вече е наличен, но цялата схема failover все още не е сработила), но следващото обновление ще ви покаже страницата от работещия сайт.
Failover на okerr + динамичен DNS
Нека видим как е устроено под капака. Задачата на файла е адресът cat.okerr.com винаги да сочи към IP адреса на работещия сървър.
За все сървъри, които поддържат нашия котосайт в okerr, има индикатор, който проверява състоянието му на всяка минута.
На този екран виждаме как се проверява сайтът cat.okerr.com от сървъра alpha.okerr.com. Страничката трябва да съдържа status=OK, и както виждаме отгоре, статусът на индикатора в момента ни е OK. Когато сървърът “счупи”, ще има ERR. (Това е само един пример за индикатор; окерр — това е мониторинг, така че можем да прикрепим всеки тип индикатор, например, да проверяваме свободното място на диска, броя на новите поръчки в базата, и дори логически индикатори, например, през нощта да имаме различни критерии за грешка, а през деня - други).
В настройките на проекта създадохме схема за failover с тези индикатори:
В схемата има три индикатора (три сървъра), различни по приоритети. Главният сървър за сайта е charlie; ако той не работи (не ще има “status=OK” или просто е недостъпен), тогава bravo и в последния случай — alpha. В дясната част на страницата се показва състоянието на DNS записа на различни сървъри.
За тези, които забелязаха, че се използва името cat.he.okerr.com: Използваме схема, която е малко по-сложна. Вместо просто да променяме DNS записа cat.okerr.com, ние променяме cat.he.okerr.com (на Dynamic DNS провайдера ), а cat.okerr.com е CNAME (алиас), който не се променя и винаги сочи към cat.he.okerr.com. Hurricane просто ни харесва повече като динамичен DNS и той разполага с ключове за управление на отделен запис (а не на цялата зона), което ни се струва по-безопасно. Можете също да не посочвате в okerr пароли-ключове за управление на целия домейн, а само за поддомейна или записа.
От падане към възстановяване
Стъпка по стъпка, как работи тази схема:
- Настъпва (симулира се) проблем на сървъра
- Сензорът okerr проверява веднъж в минута състоянието на всеки сървър и информира главния сървър на проекта в okerr
- Индикаторът на съответния сървър променя състоянието си от OK на ERR
- При смяна на статуса на индикатора, се преизчислява failover, изчислява се какъв адрес трябва да се зададе (ако е необходимо. Например, ако основният сървър работи, а докато резервният е паднал — няма да има промени)
- Този адрес се съобщава на услугата dynamic dns. След завършването на този етап вдясно ще видите статус “synced”
- Много скоро (в рамките на секунди) записа ще достигне до DNS сървърите на вашия домен (в случая на котосайта това е ns1-ns5.he.net).
- От този момент нататък, някои потребители вече ще попадат на новия жив сървър. Но все още не всички DNS сървъри в света са актуализирали записите си и на някъде все още може да е кеширано предишното запис. Може да се наблюдава как данните на публичните DNS сървъри "играят", показвайки то новото, то старото значение. Ако обновите страницата с настройки за failover, okerr автоматично ще поиска нови данни от DNS сървърите.
- След като данните се стабилизират, старият кеширан запис навсякъде е изтекъл — 100% от запитванията отиват на новия сървър.
За да ускорите 7 етап (често най-дългият), TTL на динамичния DNS запис трябва да се зададе колкото се може по-ниско. Обикновено услугите позволяват интервали от 90-120 секунди. Това е разумен компромис.
Допълнително
Всичко това може да се настрои за вечер (ако вече имате дублиращ сървър). И okerr, и услугите за динамичен DNS са безплатни. За да получите повече проверки в okerr и по-кратък период на проверка, трябва да преминете обучение (от страницата на профила). След преминаване веднага се повишава нивото (20 индикатора по час + 1 бърз, 10-минутен). Ако това е недостатъчно — пишете на support@okerr.com, вероятно ще можете да увеличите лимитите (досега винаги е имало възможност, никога не е било отказано, напротив, винаги е предлагано). Просто първоначално не искам да обещавам всичко на всички, не съм сигурен, че ще имам достатъчно ресурси, за да спазя думата си. Но в момента потребителите са малко, така че с увеличаването на лимитите няма проблеми.
Какво може всъщност okerr — вижте на сайта . Въобще, това е мониторинг (zabbix от облака), а файловерът е приятна допълнителна функция. Освен това, от сайта може да влезете в демо без регистрация.
При смяна на състоянието на индикатора — уведомление се изпраща на имейл или Telegram. (Погледнахме какво се случва и разкрихме, че, изглежда, Telegram е най-надеждният мессенджър. Благодаря на РКН за стрес теста!) При правилна настройка на okerr, всяко уведомление е или сигнал "оставете всичко, трябва да поправим!", или "отбой!". Не трябва да има излишни алерти от okerr (ако има, значи нещо трябва да се настрои иначе). Например, за нашия котосайт, сървърът alpha е последен и никога не симулира грешка. Ако той падне — трябва да знаем. Останалите сървъри обаче постоянно симулират грешки, затова, за да не получаваме аларми няколко пъти на час, тези индикатори имат статус "тих".
Също така има смисъл да направите сървър за съжаление (на най-евтиния хостинг), който ще има или вашата страница за извинение (в случай, че всички основни и резервни сървъри не работят), или ще пренасочи към страницата за статус на okerr (ето например нашата ) или statuspage.io.
Източник: habr.com
