У гэтым артыкуле я хачу паказаць, як лёгка і бясплатна можна зрабіць failover схему для вэб-сайта (або любога іншага інтэрнэт-сэрвісу) на камбінацыі маніторынгу і дынамічнага DNS сэрвісу. Гэта значыць, у выпадку любых праблем з асноўным сайтам (пачынаючы ад праблемы з "PHP Error" на старонцы, і да недахопу месца або проста падазрона малой колькасці заказаў у выпадку інтэрнэт-крамы), новыя наведвальнікі будуць накіраваны на другі (трэці, і так далей) заведама які працуе сервер, ці ж на «Sorry» старонку, дзе ім ветліва растлумачаць, што «ёсць праблема, мы ўжо ў курсе і ўжо чынім, хутка паправім» (а вы ў гэтым выпадку насамрэч будзеце ўжо ў курсе і зможаце правіць).
Жыць з failover ці без?
Пакуль не здарыцца нейкая праблема - розніцы асаблівай няма. А вось калі здарыцца, то без failover'а часта адбываецца наступнае: вы спрабуеце хутка разабрацца, у чым праблема, не атрымліваецца (бэкапы не разгортваюцца, софт чамусьці не працуе як яму вынікае з дакументацыі, ітд), а часу няма, сервера -сайты ляжаць, кліенты тэлефануюць, усё на нервах, спрабуеце неяк паправіць грубіянска і брудна «на скотчы», потым неяк накшталт запускаецца з мыліцамі і жыве. Вы думаеце, што ў вольны час трэба будзе падрабязней разабрацца і перарабіць усё хораша, але няма нічога больш сталага, чым часавае.
Цяпер, як гэта адбываецца ў прыгожым варыянце з файлаверам:
- Памылка адбываецца
- Памылка выяўляецца аўтаматычна
- Рассылаецца апавяшчэнне
- Пераводзіцца пераключэнне на адзін з рэзервовых сервераў
- Спакойна і без панікі разбіраецца праблема, выпраўляецца і сервер зноў уводзіцца ў строй.
У гэтай схеме, вядома таксама могуць узнікнуць свае запердыкі, але ўсё ж, схема лінейная, кожны этап тут просты і галоўнае - яго можна адладзіць асобна, таму шанец збою гэтай схемы значна ніжэй, а ўсе дзеянні могуць быць аўтаматызаваны і выконвацца хутка (у адрозненне ад задачы знайсці і выправіць невядомую епічную хрень). Ваш самалёт прызямліўся ў далёкай краіне, вы ўключаеце тэлефон і бачыце ў тэлеграме апавяшчэнне, што сервер упаў, але ўсё добра, актываваўся рэзервовы сервер, вы можаце працягваць сваю паездку, вам не трэба ні ляцець назад, ні правіць па SSH з бліжэйшага кафэ з WiFi . Разбярэцеся тады, калі будзе зручней.
Будучыня ўжо тут!
Раней, асноўная праблема, якая рабіла failover часта непрымальным рашэннем складалася ў суме затрат на яго. Або трэба было купляць дарагія жалязякі (і запрашаць яшчэ даражэйшых адмыслоўцаў). Або калгасіць нешта складанае па гайдах (мне трапляўся нават варыянт, калі два сервера звязваюцца дадаткова нуль-мадэмным кабелем, і ганяюць па ім heartbeat, каб у патрэбны момант запасны сервер пазнаў, і перахапіў кіраванне). Цяпер ёсць спосабы прасцей і бясплатныя. Калі ў вас ёсць сайт з коцікамі - няма вам апраўдання, калі вы яшчэ не рэалізавалі для яго failover!
Ну і акрамя таго, для failover схемы патрэбен яшчэ сервер (а можа быць і не адзін) і раней гэта было вялікімі выдаткамі, зараз можна ўзяць VDSку за капейкі.
Самы надзейны сайт з коцікамі
Для практычнай ілюстрацыі рашэння з okerr + dynamic dns мы запусцілі свой сайт з коцікамі . Коцікаў мы ненавідзім, таму іх там амаль не будзе. Усяго ёсць тры сайта, кожны выглядае прыкладна аднолькава (усё на адным шаблоне), але з рознымі кацянятамі каб было лёгка адрозніць, і кожны піша тэхнічную інфармацыю, каб убачыць, як працуе failover. Старонка абнаўляецца сама раз у 1 хвіліну, але заўседы можна націснуць reload у браўзэры.
У тэхнічнай інфармацыі ёсць радок "status = OK". Часам сервера сімулююць праблемы і пішуць status=ERR. Галоўны сервер "як бы падае" у 20 хвілін кожнай гадзіны (0:20, 1:20, 2:20, …). Запасны (backup) сервер у 40 хвілін. Апошні сервер (“sorry”-сервер) працуе заўсёды. У 0 хвілін кожнай гадзіны, асноўны і запасны сервер "аднаўляюцца".
Калі вы адкрыеце сайт, і пакінеце яго ва ўкладцы - убачыце, што ён ніколі не падае (хоць кожны асобны сервер перыядычна сімулюе праблему), а ў выпадку праблемы з серверам, проста "бегае" паміж жывымі серверамі. Будзе мяняцца карцінка, імя і адрас сервера і яго роля. Часам можна злавіць момант калі status=ERR (праблема ўжо ёсць, але ўся схема failover яшчэ не адпрацавала), але ўжо наступнае абнаўленне пакажа вам старонку з працоўнага сайта.
Failover на okerr + dynamic 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, окер сам запытае новыя дадзеныя з DNS сервераў.
- Пасля таго як дадзеныя стабілізаваліся, стары кэшаваны запіс усюды пратухла – усе 100% запытаў ідуць на новы сервер.
Каб 7 этап (часта - самы доўгі) паскорыць, TTL дынамічнай DNS запісу трэба ўсталяваць як мага ніжэй. Звычайна сэрвісы дазваляюць інтэрвалы 90-120 секунд. Гэта цалкам разумны кампраміс.
Дадаткова
Усё гэта можна наладзіць за вечар (калі ў вас ужо ёсць дублюючы сервер). І okerr і сэрвісы дынамічнага DNS бясплатныя. Каб атрымаць у okerr больш праверак і карацейшы перыяд праверкі трэба прайсці трэнінг (са старонкі профілю). Па праходжанні адразу ж падвышаецца ўзровень (20 індыкатараў па гадзіне + 1 хуткі, 10 хвілінны). А калі іх будзе мала - напішыце на [электронная пошта абаронена], Хутчэй за ўсё можна будзе павысіць (пакуль што заўсёды была магчымасць, ні разу не адмаўляў, наадварот, сам прапаноўваў). Проста першапачаткова я не хачу абяцаць усім усё, не ўпэўнены, што хопіць магутнасцяў, каб стрымаць слова. Але пакуль карыстальнікаў мала, так што з павышэннем лімітаў праблем няма.
Што можа okerr наогул - паглядзіце на сайце . Наогул, гэта маніторынг (zabbix з аблокі), а файлавер – гэта прыемная доп.функцыя. Таксама з сайта можна без рэгістрацыі зайсці ў дэма.
Пры змене стану індыкатара - адсылаецца апавяшчэнне на пошту ці Telegram. (Мы тут паглядзелі што адбываецца, і зразумелі, што, падобна, telegram – самы надзейны мэсанджар. Дзякуй РКН за стрэс-тэст!) Пры правільнай наладзе okerr, любое апавяшчэнне – гэта альбо сігнал “кідайце ўсё, трэба правіць!”, альбо “ адбой!”. Лішніх алертаў ад окера быць не павінна (калі яны ёсць - трэба наладжваць неяк інакш). Напрыклад, для нашага сайта сервер alpha апошні і ніколі не імітуе памылку. Калі ён ляжа - мы павінны ведаць. А вось іншыя сервера заўсёды сімулююць памылкі, таму, каб не атрымліваць алерты некалькі разоў у гадзіну, у тых індыкатараў стаіць статус "ціхі".
Мае сэнс таксама зрабіць sorry-сервер (на любым самым танным хостынгу), які будзе альбо мець вашу старонку выбачэнняў (на выпадак, калі ўсе асноўныя і запасныя серверы будуць ляжаць) ці перакіне на старонку статусу на okerr (вось напрыклад наша ) або statuspage.io.
Крыніца: habr.com