„Битрикс24“: „Бързо повдигнато не се счита за паднало“

В момента услугата „Bitrix24“ няма стотици гигабити трафик, нито огромен парк от сървъри (въпреки че съществуващите не са малко). Но за много клиенти тя е основен инструмент за работа в компанията, истински бизнес-критично приложение. Затова никак не е допустимо да се срива. А какво ако все пак сривът се е случил, но услугата е „възкръснала“ толкова бързо, че никой нищо не е забелязал? И как успявате да реализирате failover без загуба на качество на работа и клиенти? Александър Демидов, директор на облачните услуги на „Bitrix24“, разказа в нашия блог за еволюцията на системата за резервиране през 7-те години на съществуването на продукта.

„Започнахме „Bitrix24“ като SaaS преди 7 години. Главната трудност, вероятно, беше следната: преди старта на продукта в публичното пространство като SaaS, той съществуваше просто в формат на пакетно решение. Клиентите го купуваха от нас, инсталираха го на своите сървъри, създаваха корпоративен портал — общо решение за комуникация на служителите, съхранение на файлове, управление на задачите, CRM и всичко това. И през 2012 година решихме, че искаме да пуснем това като SaaS, администрирайки сами, осигурявайки отказоустойчивост и надеждност. Опитът ни бе натрупан в процеса, защото до този момент ние просто нямаше такъв — бяхме само производители на софтуер, не доставчици на услуги.

При старта на услугата, ние разбирахме, че най-важното е да осигурим отказоустойчивост, надеждност и постоянна достъпност на услугата, защото, ако имате обикновен сайт, например магазин, и той „падне“ за час — страдате само вие, губите поръчки, губите клиенти, но за вашия клиент — за него това не е много критично. Разстроен е, разбира се, но отива и пазарува на друг сайт. А ако това е приложение, на което зависи цялата работа в компанията, комуникацията, решенията, то ключовото е да спечелите доверието на потребителите, тоест да не ги подведете и да не „падате“. Защото цялата работа може да спре, ако нещо вътре не работи.

Битрикс.24 като SaaS

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

Типичното уеб приложение по това време беше един сървър, на който работеше някакъв код на php, база mysql, файловете се зареждаха, документи, картинки се слагаха в папката upload – и всичко това работеше. Уви, няма как да се стартира критично устойчив уеб-сервис на това. Там разпределен кеш не се поддържа, репликация на бази данни не се поддържа.

Формирахме изискванията: това умение да се разполага в различни локации, да поддържа репликация, идеално да се разполага в различни географски разпределени дата-центрове. Да се раздели логиката на продукта и самото съхранение на данни. Динамично да може да се мащабира според натоварването, статичните данни да бъдат изнесени на друг сървър. От тези съображения се оформиха, собствено, изискванията към продукта, който ние доразвивахме през цялата година. През това време в платформата, която стана единна — за кутийни решения и за нашия собствен сервиз — направихме поддръжка на онези неща, които бяха необходими за нас. Поддръжка на репликация на mysql на ниво самия продукт: т.е. разработчикът, който пише код — не се замисля как неговите заявки ще бъдат разпределени, той използва нашето api, а ние знаем как да разпределим правилно заявките за запис и прочит между мастери и слейвове.

Направихме поддръжка на ниво продукта на различни облачни обектни хранилища: google storage, amazon s3 — плюс, поддръжка на open stack swift. Затова това беше удобно и за нас като сервиз, и за разработчиците, които работят с кутийното решение: ако те използват просто нашето api за работа, те не се замислят къде в крайна сметка файлът ще бъде запазен, локално на файловата система или ще попадне в обектно файлово хранилище.

В крайна сметка, решихме веднага, че ще се резервираме на ниво цял дата център. През 2012 година стартирахме напълно в Amazon AWS, защото вече имахме опит с тази платформа — нашият собствен сайт беше там. Привлече ни фактът, че във всеки регион в Amazon има няколко зони на достъпност — по същество (в техните термини) няколко дата центъра, които са повече или по-малко независими един от друг и ни позволяват да резервираме на ниво цял дата център: ако например той внезапно излезе от строя, базите се репликират master-master, сървърите на уеб приложенията са резервирани, а статичният контент е прехвърлен в обектно хранилище s3. Натоварването се балансира — в онези времена с Amazon elb, но малко по-късно преминахме към наши собствени балансьори, защото ни трябваше по-сложна логика.

Каквото искахме — това и получихме...

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

Излезлите от строя машини балансьорът (тогава това беше Amazon elb) сам обозначаваше като unhealthy, спираше разпределението на натоварването на тях. Работеше Amazon Autoskaling: когато натоварването нарастваше, в автоскейлинг групата се добавяха нови машини, натоварването се разпределяше на новите машини — всичко беше добре. С нашите балансьори логиката е приблизително същата: ако нещо се случи с приложния сървър, премахваме исканията от него, изключваме тези машини, стартираме нови и продължаваме да работим. Схемата през всичките тези години малко се е променила, но продължава да работи: проста е, разбираема е и няма никакви затруднения с нея.

Работим по целия свят, върховете на натоварването при клиентите са абсолютно различни и, по-добрия начин, трябва да имаме възможност да извършваме различни сервизни работи с каквито и да било компоненти на нашата система по всяко време – незабележимо за клиентите. Затова имаме възможност да изключим от работа базата данни, преразпределяйки натоварването на втория дата център.

Как работи всичко това? — Превключваме трафика на работещ център за данни — ако това е авария в центъра за данни, то изцяло, а ако става дума за нашите планови работи с някоя от базите, то част от трафика, обслужващ тези клиенти, прехвърляме на втория център за данни, като спираме репликацията. Ако са нужни нови машини за уеб приложения, тъй като натоварването е нараснало във втория център за данни, те автоматично се стартират. Завършваме работата, репликацията се възстановява и връщаме цялото натоварване обратно. Ако трябва да направим отразяващи работи във втория ДЦ, например да инсталираме системни актуализации или да променим настройки втората база данни, то, като цяло, повтаряме всичко това, просто в обратна посока. А ако е авария, правим всичко просто: в системата за мониторинг използваме механизма event-handlers. Ако сработят няколко проверки и статусът премине в критичен, стартираме този обработчик, който може да изпълни определена логика. За всяка база е указано кой сървър е резервен за нея и къде трябва да прехвърлим трафика в случай на недостъпност. Исторически, ние използваме в някаква форма nagios или неговите клонове. Всъщност, подобни механизми съществуват почти във всяка система за мониторинг, но не използваме по-сложни в момента, но е възможно в бъдеще да го направим. Сега мониторингът сработва при недостъпност и има възможност нещо да се прехвърли.

Всичко ли сме резервирали?

Имаме много клиенти от САЩ, много клиенти от Европа, много клиенти, които са по-близо до Източна Азия - Япония, Сингапур и така нататък. Разбира се, голяма част от клиентите ни са в Русия. Тоест работим далеч извън един регион. Потребителите искат бързо време за отговор, има изисквания за спазване на различни местни закони, а в рамките на всеки регион резервираме два дата центъра, плюс има и допълнителни услуги, които, отново, е удобно да се разположат в рамките на един и същи регион - за клиенти, които работят в този регион. REST обработчици, сървъри за удостоверяване, те са по-малко критични за работата на клиента като цяло, при тях можем да сменяме с малка приемлива закъснение, но не искаме да изобретяваме велосипеди по отношение на това как да ги наблюдаваме и какво да правим с тях. Затова се опитваме максимално да използваме вече съществуващи решения, отколкото да развиваме собствена компетенция по допълнителни продукти. И някъде просто използваме превключване на ниво DNS, а жизнеността на услугата определяме с този същия DNS. В Amazon има услуга Route 53, но това не е просто DNS, в който можеш да добавиш записи и всичко - той е много по-гъвкав и удобен. С него можеш да изградите гео-разпределени услуги с геолокации, когато с негова помощ определяш откъде е дошъл клиентът и му предоставяш съответните записи - с него можеш да изградиш архитектури за failover. Същите проверки за здравословно състояние се конфигурират самия Route 53, задаваш endpoint-ите, които се наблюдават, задаваш метрики, задаваш по какви протоколи да определяш „живостта“ на услугата - TCP, HTTP, HTTPS; задаваш периодичността на проверките, с които да определяш, дали услугата е жива или не. А в самия DNS задаваш, кое ще бъде primary, кое ще бъде secondary, към какво да се превключва, ако сработи health-check в Route 53. Всичко това може да се направи с някакви други инструменти, но е удобно - настройваш го един път и после изобщо не мислим за това как се извършват проверките, как става превключването: всичко работи само.

Първото „но“: а как и с какво да резервираме самия route 53? Ако нещо се случи с него? За щастие, досега не сме се сблъсквали с такива проблеми, но отново, имам история, която да споделя, защо решихме, че все пак трябва да направим резервиране. Тук предварително се подготвяме. Няколко пъти на ден правим пълно извличане на всички зони, които имаме в route 53. API на Amazon позволява да ги предоставяме спокойно в JSON формат, и имаме няколко резервни сървъра, където конвертираме тези данни, извличаме ги под формата на конфигурации и имаме, грубо казано, резервна конфигурация. В случай на нещо, можем бързо да я развернем ръчно, без да загубим данните за dns настройки.

Второто "но": какво още не е резервирано? Самият балансировчик! Разпределението на клиентите по региони е направено много просто. Имаме домейни bitrix24.ru, bitrix24.com, .de — в момента имаме около 13 различни, които работят в различни зони. Решихме следното: всеки регион — със свои балансировачи. Така е по-удобно да се разпределят в зависимост от пиковото натоварване мрежи. Ако има проблем на ниво един балансировчик, той просто се извежда от експлоатация и се премахва от dns. Ако възникне проблем с група балансировачи, те се резервират на други платформи и превключването помежду им се извършва с помощта на същия route53, защото благодарение на краткия ttl, превключването става максимум в рамките на 2, 3, 5 минути.

Третото "но": какво още не е резервирано? S3, правилно. Когато съхраняваме файлове, които имаме при потребителите в s3, искрено вярвахме, че той е неуязвим и не е нужно нищо там да се резервира. Но историята показва, че нещата стават иначе. Всъщност, Amazon описва S3 като основен сервис, защото самият Amazon използва S3 за съхраняване на образи на машини, конфигурации, образи на AMI, моментни снимки… И ако s3 падне, както се случи веднъж през тези 7 години, в които експлоатираме bitrix24, той буквално тегли след себе си много други проблеми — недостъпност на старта на виртуалките, срив в работата на api и така нататък.

И да падне S3 може — това се е случвало веднъж. Затова стигнахме до следната схема: преди няколко години нямаше сериозни публични обектни хранилища в Русия и обмисляхме варианта да направим нещо свое… За щастие, не започнахме това, тъй като щяхме да се заплетем в експертизата, която нямаме, и със сигурност щяхме да направим грешки. В момента s3-съвместими хранилища предлага Mail.ru, Яндекс и още няколко доставчици. В крайна сметка решихме, че искаме, от една страна, резервиране, а от друга - възможност за работа с локални копия. За конкретно руския регион използваме услугата Mail.ru Hotbox, която е съвместима с s3 по api. Не ни бяха нужни сериозни доработки в кода на приложението, и направихме следния механизъм: в s3 има тригери, които реагират на създаването/изтриването на обекти, а Amazon предлага услуга на име Лямбда — това е serverless изпълнение на код, което ще се извърши при задействането на определени тригери.

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

На кодово ниво за всеки клиент сме предвидили и двете хранилища: едното е основно, а другото резервно. Ако всичко е наред, работим с това хранилище, което е по-близо до нас: тоест нашите клиенти, които са в Amazon, работят със S3, а тези, които са в Русия, работят с Hotbox. Ако се задейства флаг, трябва да се свърже резервно хранилище и ние прехвърляме клиентите на другото хранилище. Този флаг можем да задаваме независимо по региони и можем да ги превключваме напред-назад. На практика още не сме го ползвали, но сме предвидили механизма и смятаме, че рано или късно ще ни е нужен. Вече веднъж се случи.

Ой, а у вас Amazon побягна…

Този април – годишнина от началото на блокировките на Телеграм в Русия. Най-засегнатият оператор, който пострада, е Amazon. За съжаление, повече пострадаха руските компании, които работеха на международния пазар.

Ако компанията е глобална и Русия е съвсем малък сегмент за нея – 3-5% – то по един или друг начин тя може да ги пожертва.

Ако става въпрос за строго руска компания – убеден съм, че трябва да има локално разположение – просто на самите потребители ще им бъде удобно, комфортно, и рисковете ще са по-малко.

А ако компанията работи глобално и има приблизително равен брой клиенти в Русия и другаде по света? Свързаността на сегментите е важна и те трябва да работят помежду си по един или друг начин.

Още в края на март 2018 г. Роскомнадзор изпрати писмо до най-големите оператори, в което информира, че планират да блокират няколко милиона IP адреса на Amazon, за да блокират... месенджера Zello. Благодаря на тези оператори – те успешно излъчиха писмото, и така стана ясно, че свързаността с Amazon може да се прекъсне. Това беше в петък, в паника се обърнахме към колегите от servers.ru с думите: „Приятели, необходим ни е набор от сървъри, които да не са в Русия, не в Amazon, а например някъде в Амстердам“, за да имаме възможност поне по някакъв начин да установим собствено разположение. vpn и прокси за някакви endpoint’и, на които ние никак не можем да влияеме, например endpoint’и на същото s3 — не може да се опита да се издигне нова услуга и да се получи друг ip, все пак трябва да стигнем до там. За няколко дни ние настроихме тези сървъри, възстановихме ги и в общи линии, към момента на началото на блокировките, бяхме подготвени. Любопитно е, че РКН, след като видя шума и повдигнатата паника, каза: «Не, ние сега няма да блокираме нищо». (Но това беше точно до момента, когато започнаха да блокират телеграм.) Настройвайки възможностите за заобикаляне и разбирайки, че блокировката не е въведена, ние, все пак, не се захванахме с всичко това. Така, за всеки случай.

И ето, че през 2019 година ние все пак живеем в условия на блокировки. Аз вчера през нощта гледах: около милион ip продължават да бъдат блокирани. Всъщност, Amazon почти напълно беше разблокиран, на пика достигаше до 20 милиона адреса... Общо взето, реалността е такава, че свързаността, добра свързаност — може да я няма. Неочаквано. Може да я няма по технически причини — пожари, екскаватори, всичко такова. Или, както видяхме, не съвсем технически. Затова някой голям и значим, с собствени AS-ки, вероятно, може да управлява това с други средства — direct connect и други неща вече на ниво l2. Но в простия вариант, както ние или още по-малки, може за всеки случай да имаме резервиране на ниво сървъри, повдигнати някъде другаде, предварително настроени vpn, прокси, с възможност бързо да превключваме конфигурацията на тези сегменти, които са критични за вас по свързаност. Това ни беше от полза многократно, когато започнаха блокировките на Amazon, ние през тях пускахме в най-лошия случай точно трафик S3, но постепенно всичко това се разреши.

А как да резервираме... целия доставчик?

Сега нямаме сценарий за случай на пълен неуспех на Amazon. Имаме подобен сценарий за Русия. В Русия сме разположени при един доставчик, от когото избрахме да имаме няколко площадки. И преди година се сблъскахме с проблем: дори и да имаме два дата центъра, на нивото на конфигурацията на мрежата доставчикът може да има проблеми, които да засегнат и двата дата центъра. И можем да имаме недостъпност на двете площадки. Разбира се, така и стана. В крайна сметка преразгледахме архитектурата вътре. Тя не се промени значително, но за Русия сега имаме две площадки, които не са при един доставчик, а при двама различни. Ако при един нещо се случи, можем да превключим на другия.

Хипотетично разглеждаме възможността за резервиране на ниво друг доставчик за Amazon; може би Google, може би още някой... Но досега наблюдавахме на практика, че ако в Amazon се случат аварии на ниво една availability зона, то аварии на ниво целия регион са доста рядко явление. Затова теоретично имаме представа, че може би ще направим резервиране на "Amazon - не Amazon", но практиката все още не показва такова.

Няколко думи за автоматизацията

Винаги ли е нужна автоматизация? Тук е уместно да си припомним ефекта на Данинг-Крюгер. По оста "х" са нашите знания и опит, които придобиваме, а по оста "у" — увереността в нашите действия. Първо не знаем нищо и сме напълно неуверени. След това знаем малко и ставаме супер уверени — това е така нареченият "пик на глупостта", който добре се илюстрира с картинката "слабоумие и отвага". След това все пак сме научили нещо и сме готови да действаме. След това стъпваме на някакви сериозни грабли, попадаме в долината на отчаянието, когато изглежда, че знаем нещо, а всъщност не знаем много. След това, с нарастващия опит, ставаме по-уверени.

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

Заключение

За 7 години преминахме пътя от паника, когато нещо се проваляше, към разбирането, че проблеми не съществуват, а само задачи, които е необходимо — и можем — да решаваме. Когато строите някакъв сервис, погледнете на него отгоре, оценете всички рискове, които могат да възникнат. Ако веднага ги виждате — предвидете резервиране и възможност за изграждане на отказоустойчива инфраструктура, защото всяка точка, която може да излезе от строя и да доведе до неработоспособност на сервиза, непременно ще го направи. И дори ако ви се струва, че някои елементи от инфраструктурата определено няма да се повредят — като същия s3, пак имайте предвид, че те могат. И поне в теория имайте представа какво ще правите с тях, ако все пак нещо се случи. Имайте план за справяне с рисковете. Когато се замисляте дали да правите всичко автоматично или ръчно — оценете рисковете: какво ще стане, ако автоматизацията започне да превключва всичко — няма ли това да доведе до още по-лоша ситуация в сравнение с аварията? Може би, някъде е необходимо да се използва разумен компромис между използването на автоматизация и реакцията на дежурния инженер, който ще оцени действителната ситуация и ще разбере дали е нужно незабавно да превключи нещо или „да, но не сега“.

Разумен компромис между перфекционизма и реалните сили, времето, парите, които можете да похарчите за схемата, която в крайна сметка ще получите.

Текстът представлява допълнена и разширена версия на доклада на Александър Демидов на конференцията. Uptime ден 4.

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