🥇Failover: ни убива перфекционизмът и… леността

През лятото традиционно намаляват и купуваческата активност, и интензивността на промените в инфраструктурата на уеб проектите, казва ни Капитан Очевидност. Просто защото дори айтишниците, става, ходят на почивка. И CTO също. Колкото по-тежко е на тези, които остават на поста, но сега не е за това: вероятно затова лятото е най-добрият период, за да обмислим на спокойствие съществуващата схема за резервиране и да съставим план за нейното подобряване. В това ще ви бъде полезен опитът на Егор Андреев от AdminDivision, за който той разказа на конференцията Uptime day.

При изграждането на резервни площадки и при резервирането има няколко капана, в които можем да попаднем. И попадането в тях е абсолютно недопустимо. Перфекционизмът и… мързела ни съсипват в това, както и в много други неща. Опитваме се да направим всичко перфектно, но перфектно се прави не трябва! Трябва да правим само определени неща, но да ги направим правилно, да ги доведем до край, за да работят нормално.

Failover не е някаква забавна играчка „за кеф”; това е нещо, което трябва да направи точно едно — да намали времето на прекъсване, за да губи услугата, компанията, по-малко пари. И в всички методи на резервиране предлагам да мислим в следния контекст: къде са парите?

Първият капан: когато изграждаме големи надеждни системи и се занимаваме с резервиране — ние намаляваме броя на аварии. Това е огромно заблуждение. Когато се занимаваме с резервиране, вероятно нарастваме броя на аварии. И ако направим всичко правилно, то общо време на прекъсване ще намалим. Аварии ще има повече, но те ще се случват с по-малки разходи. Какво е резервирането? — това е усложняване на системата. Всяко усложнение — е лошо: появяват се повече елементи, повече зъбни колела, с други думи, повече компоненти — и следователно, по-висок шанс за повреда. И те наистина ще се счупят. И ще се повредят по-често. Прост пример: да речем, имаме един сайт, с PHP, MySQL. И спешно трябва да го резервираме.

И така, взимаме втория площад, строим идентична система… Сложността става два пъти по-голяма — имаме две единици. А освен това отгоре слагаме определена логика за прехвърляне на данни от едно място на друго — т.е. репликация на данните, копиране на статиката и така нататък. Така че логиката на репликация — обикновено е много сложна, и следователно, общата сложност на системата може да бъде не в 2, а 3, 5, 10 пъти по-голяма.

Втората примка: когато строим наистина големи сложни системи, фантазираме какво искаме да постигнем в крайна сметка. Вуаля: искаме да получим супернадеждна система, която работи абсолютно без престой, превключва се за половин секунда (или още по-добре — мигновено), и започваме да реализацияме мечтите си. Но тук също има нюанс: колкото по-малко е желаното време за превключване, толкова по-сложна става логиката на системата. Колкото по-сложна трябва да направим тази логика, толкова по-често системата ще се счупва. И може да попаднем в много неприятна ситуация: с всички сили се опитваме да намалим времето за престой, а всъщност всичко усложняваме, и когато нещо не върви както трябва, времето за престой в крайна сметка ще бъде повече. Често улавяш себе си в мисълта: ето… по-добре да не бяхме резервирали. По-добре да работеше едно и с разбираемо време за престой.

Как можем да се борим с това? Трябва да спрем да си лъжем, да спрем да се самозалъгваме, че сега ще строим космически кораб, но адекватно да разберем колко долго проектът може да остане. И за това максимално време ще избираме какви методи да използваме, за да повишим надеждността на нашата система.

Сега е времето за "истории от живота"… от живота, разбира се.

Пример номер едно

Представете си уебсайт на производител на тръби №1 в град N. На него е написано с големи букви — ТРЪБОПРОКАТЕН ЗАВОД №1. Малко по-долу — слоган: «Нашите тръби са най-кръглите тръби в N». И отдолу номерът на телефона на изпълнителния директор и неговото име. Разбираме, че е необходимо резервиране — това е много важен елемент! Започваме да разбираме от какво се състои. Html-статичност — тоест поредица от картинки, на които изпълнителният директор, всъщност, с партньора си обсъждат някаква нова сделка на маса в баня. Започваме да мислим за времето за престой. В ума ми изниква: трябва да лежите там максимум пет минути. И тук идва въпросът: а колко продажби са извършени от нашия сайт изобщо? Колко? Какво означава «нула»? А това означава: защото всички четири сделки от миналата година изпълнителят е направил на същата маса, със същите хора, с които ходят в банята и сядат на масата. И разбираме, че дори и ако сайтът стои един ден — нищо страшно няма да се случи.

Изходя от представената информация, имаме един ден за повдигане на тази история. Започваме да мислим за схема на резервиране. И избираме най-идеалната схема за резервиране за този пример: ние не използваме резервиране. Всичко това може да бъде издигнато от всеки администратор за половин час с почивките. Поставете уеб сървър, сложете файловете — готово. То ще заработи. Не е нужно да следите нищо и да отделяте особено внимание на нищо. Тоест изводът от пример номер едно е доста очевиден: услугите, които не е нужно да се резервират — не е нужно да се резервират.

Пример номер две

Блог на компанията: специално обучените публикуват новини там, например, участвахме на определено изложение, а ето сега и нов продукт. Да кажем, че става дума за стандартен PHP с WordPress, малка база данни и малко статично съдържание. В ума ми, разбира се, отново се появява идеята, че не можем да се отпускаме — „не повече от пет минути!“, това е всичко. Но нека помислим по-дълбоко. Какво прави този блог? Хората идват от Яндекс и Гугъл по определени търсения, по органичен трафик. Страхотно. А свързани ли са продажбите по някакъв начин с него? Освобождаване: не особено. Рекламният трафик отива на основния сайт, който е на друга машина. Започваме да мислим за резервна схема за блога. Наистина, за няколко часа е нужно да го възстановим и би било хубаво да сме подготвени за това. Разумно е да вземем машина от друг дата център, да заредим средата, т.е. уеб сървър, PHP, WordPress, MySQL и да я оставим в покой. В момента, в който разберем, че всичко е счупено, трябва да направим две неща — да възстановим mysql дампа от 50MB, който ще се зареди за минута и да възстановим някакво количество снимки от резервното копие. Това също не е много. По този начин за половин час всичко това се възстановява. Няма репликации или, моля, да не стане автоматичен failover. Извод: това, което можем бързо да възстановим от резервно копие — не трябва да се резервира.

Пример номер три, малко по-сложен

Интернет магазин. PHP с леко модифицирано open heart и mysql със солидна база данни. Доста много статично съдържание (в крайна сметка в интернет магазина има красиви HD изображения и всичко останало), Redis за сесии и Elasticsearch за търсене. Започваме да мислим за времето на престоят. И тук е ясно, че интернет магазин не може да остане в застой един ден безболезнено. Колкото по-дълго стой, толкова повече пари губим. Нужно е да ускорим нещата. А колко? Смятам, че ако останем в застой един час, никой няма да полудее. Да, ще загубим нещо, но ако започнем да се отчаяваме — ще стане само по-зле. Определяме схемата на допустимия застой на час.

Как може да резервирам всичко това? Колата е нужна във всеки случай: час време — това е наистина малко. Mysql: тук вече е нужна репликация, жива репликация, защото за час 100 ГБ в дамп вероятно няма да се събере. Статиката, снимките: отново, за час 500 ГБ може да не успеят да се влеят. Следователно, по-добре е веднага да се копират снимките. Redis: тук е по-интересно. В Redis сесиите съществуват — просто да вземем и да го погребем не можем. Защото това няма да е особено добре: всички потребители ще се окажат разлогинени, кошниците изчистени и така нататък. Хората ще трябва да въвеждат отново своя логин и парола, и много от тях може да се откажат и да не завършат покупката. Отново, конверсията ще падне. От друга страна, Redis е точно актуален, с последните влезли потребители, вероятно не е нужен. Добър компромис е да вземем Redis и да го възстановим от бекъп, вчерашен, или, ако го правите на всеки час, — от час назад. За щастие, възстановяването му от бекъп е копиране на един файл. Но най-интересната история е ElasticSearch. Кой е правил някога репликация на MySQL? Кой е правил репликация на ElasticSearch? И при кого тя работи нормално след това? Към какво целя: виждаме в нашата система някаква същност. Изглежда полезна — но е сложна.
Сложно в смисъл, че нашите колеги инженери нямат опит с нея. Или имат негативен опит. Или разбираме, че все още е доста нова технология с нюанси или недоразвита. Мислим... Чакай, elastic също е голям, възстановяването от бекъп отнема време, как да действаме? Разбираме, че elastic в нашия случай се използва за търсене. А как нашият интернет магазин продава? Отиваме при маркетолозите, питаме откъде идват хората. Те отговарят: "90% от Яндекс-маркет идват директно на страницата на продукта". И или купуват, или не. Следователно, търсенето е нужно на 10% от потребителите. А поддържането на репликация на elastic, особено между различни дата центрове в различни зони, действително е с много нюанси. Какво остава за нас? Подготвяме elastic на резервирана площадка и не правим нищо с него. Ако процесът се забави, той може би ще бъде включен по-късно, но не е сигурно. Всъщност, изводът е плюс-минус същият: услуги, които не влияят на финансите, не резервираме отново. За да остане схемата по-проста.

Пример номер четири, дори по-сложен

Интегратор: продажба на цветя, повикване на такси, продажба на стоки, по принцип, всичко, което се сетите. Сериозна работа, която работи 24/7 за голям брой потребители. С пълноценен интересен стек, където има интересни бази, решения, висока натовареност, и най-важното, не може да спи повече от 5 минути, иначе е болезнено. Не само и не толкова, защото хората няма да купят, а защото те ще видят, че работата не върви, ще се разочароват и може би няма да се върнат втори път.

Окей. Пет минути. Какво ще правим с това? В този случай, ние по-възрастни, с всички ресурси, изграждаме истинска резервна площадка, с репликация на всичко, и е възможно, дори да автоматизираме максимално превключването към тази площадка. И в допълнение към това, не бива да забравяме да направим едно важно нещо: всъщност, да напишем регламент за превключване. Регламентът, дори ако всичко и всяко е автоматизирано, може да бъде много прост. Неща от типа на "стартирайте този сценарий ansible", "в route 53 натиснете тази галка" и така нататък - но това трябва да бъде точен списък с действия.

И изглежда всичко е ясно. Превключването на репликацията е тривиална задача или тя сама ще се превключи. Пренаписването на домейна в DNS е от същия тип. Проблемът е в това, че когато такъв проект падне, започва паника и дори най-силните, опитни администратори могат да ѝ подлежат. Без ясна инструкция "отвори терминала, отиди тук, адресът на нашия сървър все още е такъв", срокът от 5 минути, отреден за реанимация, е труден за спазване. И плюс това, когато използваме този регламент, лесно можем да фиксираме промени в инфраструктурата, за пример — и съответно да променим регламента.
А ако системата за резервиране е много сложна и в даден момент сме направили грешка, можем да разбивме и нашата резервна площадка, а също така данните да станат невалидни на двете площадки — това ще бъде съвсем тъжно.

Пример номер пет, пълен хардкор

Международен сервиз с стотици милиони потребители по целия свят. Всички часови зони, които съществуват, висок товар на максимум, не може да има никакви прекъсвания. Минутата — и ще бъде тъжно. Какво да правим? Отново, резервиране по пълната програма. Направихме всичко, за което говорих в предишния пример, и даже малко повече. Идеалният свят, и нашата инфраструктура — тя по всички понятия е DevOps IaaC. Тоест всичко е в git и просто натискай бутона.

Какво липсва? Едно — учения. Без тях не може. Изглежда, че всичко при нас е идеално, всичко е под контрол. Натискаме бутона, всичко става. Дори и да е така — а ние разбираме, че така не става — нашата система взаимодейства с други системи. Например, това е DNS от Route 53, S3-хранилища, интеграция с някакви API. Невъзможно е да предвидим всичко в този хипотетичен експеримент. И докато наистина не отключим прекъсвача — няма да разберем дали работи или не.

На това, вероятно, е всичко. Не се мързелувайте и не прекалявайте. И да бъде с вас uptime!

Източник: habr.com