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

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

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

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

Bitrix24 като SaaS

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

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

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

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

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

Каквото искахме – това и получихме…

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

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

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

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

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

Имаме много клиенти от САЩ, много клиенти от Европа, много клиенти, които са по-близо до Изтока — Япония, Сингапур и така нататък. Разбира се, огромна част от клиентите са в Русия. Тоест, работата ни не е ограничена само в един регион. Потребителите искат бърз отговор, има изисквания за спазване на различни местни закони и в рамките на всеки регион резервираме по два дата центъра, плюс имаме някои допълнителни услуги, които, отново, е удобно да бъдат разположени в рамките на един регион — за клиентите, които работят в този регион. REST обработващи единици, сървъри за авторизация, те не са толкова критични за общата работа на клиента, можем да превключваме между тях с малка допустима закъснение, но не искаме да измисляме велосипеди, как да ги наблюдаваме и какво да правим с тях. Затова се стремим да използваме вече съществуващите решения, а не да развиваме собствена компетенция по допълнителни продукти. И на места просто използваме превключване на ниво DNS, като живостта на услугата определяме със същия DNS. В Amazon има услуга Route 53, но това не е просто DNS, в който можете да добавите записи и толкова — той е много по-гъвкав и удобен. През него можете да изградите гео-разпределени услуги с геолокации, когато с неговата помощ определяте откъде е дошъл клиентът и му давате нужните записи — с него можете да създадете failover архитектури. Същите health checks се настройват в самото Route 53, задавате endpoint-ите, които се наблюдават, задавате метрики, задавате по какви протоколи да определяте

Първото "но": как и с какво да резервираме самия 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 предлага услуга, наречена Lambda — това е безсървърно стартиране на код, който ще се изпълни при сработване на определени тригери.

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

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

Ой, а 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", но на практика такова още не е реализирано.

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

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

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

Заключение

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

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

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

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