"Bitrix24": "Бързо вдигнатото не се счита за паднало"

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

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

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

Bitrix.24 като SaaS

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

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

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

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

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

Това, което искаха, го получиха...

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

Балансьорът (тогава беше коляното на Amazon), който неизправните машини се маркираха като нездравословни, изключи разпределението на натоварването върху тях. Автоматичното мащабиране на Amazon работи: когато товарът нарасна, нови автомобили бяха добавени към групата за автоматично мащабиране, товарът беше разпределен към нови автомобили - всичко беше наред. С нашите балансьори логиката е приблизително същата: ако нещо се случи със сървъра на приложения, премахваме заявки от него, изхвърляме тези машини, стартираме нови и продължаваме да работим. Схемата се промени малко през годините, но продължава да работи: тя е проста, разбираема и няма трудности с това.

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

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

Запазихме ли всичко?

Имаме много клиенти от САЩ, много клиенти от Европа, много клиенти, които са по-близо до Изтока - Япония, Сингапур и т.н. Разбира се, огромна част от клиентите в Русия. Тоест работата е далеч от един регион. Потребителите искат бърз отговор, има изисквания за спазване на различни местни закони и в рамките на всеки регион запазваме два центъра за данни, плюс има някои допълнителни услуги, които отново са удобно разположени в рамките на един регион - за клиенти, които са в този регион работят. REST манипулатори, сървъри за авторизация, те са по-малко критични за работата на клиента като цяло, можете да ги превключвате с малко приемливо забавяне, но не искате да преоткривате колелото, как да ги наблюдавате и какво да правите с тях. Затова се опитваме да използваме максимално съществуващите решения, а не да развиваме някаква компетентност в допълнителни продукти. И някъде банално използваме превключване на ниво dns, а жизнеността на услугата се определя от същия dns. Amazon има услуга Route 53, но не е само dns, където можете да правите записи и това е - много по-гъвкаво и удобно е. Чрез него можете да изграждате гео-разпределени услуги с геолокации, когато го използвате, за да определите откъде идва клиентът и да му дадете определени записи - можете да го използвате за изграждане на failover архитектури. Същите проверки на здравето са конфигурирани в самия Route 53, вие задавате крайната точка, която се наблюдава, задавате метриките, задавате кои протоколи да определят "живостта" на услугата - tcp, http, https; задайте честотата на проверките, които определят дали услугата е жива или не. И в самия dns предписвате кое ще бъде основно, кое ще бъде вторично, къде да превключите дали проверката на здравето работи вътре в маршрут 53. Всичко това може да се направи с други инструменти, но по-удобното е, че ние го настройваме веднъж и след това изобщо не мислете за това как правим проверки, как превключваме: всичко работи от само себе си.

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

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

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

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

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

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

О, и вашият Amazon избяга ...

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

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

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

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

В края на март 2018 г. Roskomnadzor изпрати писмо до най-големите оператори, че планират да блокират няколко милиона ips на Amazon, за да блокират ... месинджъра Zello. Благодарение на същите тези доставчици - те успешно изтекоха писмото до всички и имаше разбиране, че връзката с Amazon може да се разпадне. Беше петък, изтичахме при колегите от servers.ru в паника, казвайки: „Приятели, имаме нужда от няколко сървъра, които няма да бъдат в Русия, не в Amazon, а например някъде в Амстердам“, за да в за да можем поне по някакъв начин да поставим нашия собствен vpn и прокси там за някои крайни точки, на които не можем да повлияем по никакъв начин, например крайни точки на същия s3 - не можете да опитате да създадете нова услуга и да получите различна ip, все още трябва да стигнем до там. За няколко дни ги настроихме тези сървъри, вдигнахме ги и като цяло бяхме подготвени до момента, в който започна блокирането. Любопитно е, че RKN, гледайки надигнатия шум и паника, каза: „Не, няма да блокираме нищо сега“. (Но това е точно до момента, в който започнаха да блокират телеграми.) След като настроихме опциите за байпас и осъзнахме, че блокирането не е въведено, ние все пак не започнахме да анализираме всичко. Да, за всеки случай.

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

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

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

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

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

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

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

Заключение

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

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

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

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