Някак исторически ИТ индустрията е разделена на два условни лагера по някаква причина: тези, които са „за“ и тези, които са „против“. Освен това предметът на споровете може да бъде напълно произволен. Коя операционна система е по-добра: Win или Linux? На смартфон с Android или iOS? Трябва ли да съхранявате всичко в облаците или да го поставите в студено RAID хранилище и да поставите винтовете в сейф? Хората на PHP имат ли право да се наричат програмисти? Тези спорове понякога имат изключително екзистенциален характер и нямат друга основа освен спортен интерес.
Просто така се случи, че с появата на контейнерите и цялата тази любима кухня с докери и условни k8, започнаха дебатите „за“ и „против“ използването на нови възможности в различни области на бекенда. (Нека направим резервация предварително, че въпреки че Kubernetes най-често ще бъде посочван като оркестратор в тази дискусия, изборът на този конкретен инструмент не е от основно значение. Вместо това можете да замените всеки друг, който ви се струва най-удобен и познат .)
И, изглежда, това ще бъде обикновен спор между двете страни на една и съща монета. Толкова безсмислен и безмилостен, колкото вечната конфронтация между Win срещу Linux, в която адекватните хора съществуват някъде по средата. Но в случая с контейнеризацията не всичко е толкова просто. Обикновено в такива спорове няма правилна страна, но в случай на „използване“ или „неизползване“ на контейнери за съхранение на бази данни, всичко се обръща с главата надолу. Защото в известен смисъл и привържениците, и противниците на този подход са прави.
Светлата страна
Аргументът на Light Side може да бъде описан накратко с една фраза: „Здравейте, 2k19 е извън прозореца!“ Звучи като популизъм, разбира се, но ако се вникне в ситуацията в детайли, има своите предимства. Нека сега ги подредим.
Да приемем, че имате голям уеб проект. Може първоначално да е бил изграден на базата на подход на микроуслуга или в някакъв момент да е стигнал до него по еволюционен път - това всъщност не е много важно. Вие разпръснахте нашия проект в отделни микроуслуги, настроихте оркестрация, балансиране на натоварването и мащабиране. И сега с чиста съвест отпивате мохито в хамак по време на хабра ефекти, вместо да вдигате паднали сървъри. Но във всички действия трябва да сте последователни. Много често само самото приложение – кодът – е контейнеризирано. Какво друго имаме освен код?
Точно така, данни. Сърцето на всеки проект са неговите данни: това може да бъде или типична СУБД - MySQL, Postgre, MongoDB, или хранилище, използвано за търсене (ElasticSearch), хранилище на ключ-стойност за кеширане - например redis и т.н. В момента не сме ще говорим за криви опции за внедряване на бекенда, когато базата данни се срине поради лошо написани заявки, и вместо това ще говорим за осигуряване на толерантност към грешки на същата тази база данни при натоварване на клиента. В крайна сметка, когато контейнеризираме нашето приложение и му позволим свободно да се мащабира, за да обработва произволен брой входящи заявки, това естествено увеличава натоварването на базата данни.
Всъщност каналът за достъп до базата данни и сървърът, на който тя работи, се превръщат в ухо на иглата в нашия красив контейнерен бекенд. В същото време основният мотив на виртуализацията на контейнера е мобилността и гъвкавостта на структурата, което ни позволява да организираме разпределението на пиковите натоварвания в цялата налична за нас инфраструктура възможно най-ефективно. Тоест, ако не контейнеризираме и не разгърнем всички съществуващи елементи на системата в клъстера, правим много сериозна грешка.
Много по-логично е да се клъстерира не само самото приложение, но и услугите, отговорни за съхраняването на данни. Чрез клъстериране и разполагане на уеб сървъри, които работят независимо и разпределят натоварването помежду си в k8s, ние вече решаваме проблема със синхронизирането на данни - същите коментари към публикации, ако вземем за пример някаква медийна или блог платформа. Във всеки случай имаме вътрешно клъстерно, дори виртуално представяне на базата данни като ExternalService. Въпросът е, че самата база данни все още не е клъстерирана - уеб сървърите, разположени в куба, вземат информация за промените от нашата статична бойна база данни, която се върти отделно.
Усещате ли уловка? Използваме k8s или Swarm, за да разпределим натоварването и да избегнем срив на основния уеб сървър, но не правим това за базата данни. Но ако базата данни се срине, тогава цялата ни клъстерна инфраструктура няма смисъл - каква полза от празни уеб страници, които връщат грешка при достъп до базата данни?
Ето защо е необходимо да се клъстерират не само уеб сървърите, както обикновено се прави, но и инфраструктурата на базата данни. Само по този начин можем да осигурим структура, която работи пълноценно в един екип, но същевременно независими един от друг. Освен това, дори ако половината от нашия бекенд се „срути“ при натоварване, останалите ще оцелеят, а системата за синхронизиране на базите данни една с друга в рамките на клъстера и възможността за безкрайно мащабиране и внедряване на нови клъстери ще помогнат за бързо достигане на необходимия капацитет - само ако имаше стелажи в центъра за данни.
В допълнение, моделът на базата данни, разпределен в клъстери, ви позволява да занесете тази база данни там, където е необходима; Ако говорим за глобална услуга, тогава е доста нелогично да завъртите уеб клъстер някъде в района на Сан Франциско и в същото време да изпращате пакети при достъп до база данни в района на Москва и обратно.
Също така контейнеризацията на базата данни ви позволява да изградите всички елементи на системата на едно и също ниво на абстракция. Което от своя страна прави възможно управлението на същата тази система директно от код, от разработчици, без активното участие на администратори. Разработчиците смятат, че е необходима отделна СУБД за новия подпроект - лесно! написахте yaml файл, качихте го в клъстера и сте готови.
И разбира се, вътрешната работа е значително опростена. Кажете ми, колко пъти сте затваряли очи, когато нов член на екипа постави ръцете си в бойната база данни за работа? Коя всъщност е единствената, която имате и се върти в момента? Разбира се, тук всички сме възрастни и някъде имаме нов резервен вариант, а още по-далече - зад рафта с краставиците на баба и старите ски - друг резервен вариант, може би дори в хладилния склад, защото офисът ви вече е горял веднъж. Но все пак всяко въвеждане на нов член на екипа с достъп до бойната инфраструктура и, разбира се, до бойната база данни е кофа валидол за всички наоколо. Е, кой го познава, новак, може би е с кръстосани ръце? Страшно е, ще се съгласите.
Контейнеризацията и всъщност разпределената физическа топология на базата данни на вашия проект помага да се избегнат такива моменти на валидиране. Нямате доверие на новак? ДОБРЕ! Нека му дадем собствен клъстер, с който да работи и да изключим базата данни от другите клъстери - синхронизиране само чрез ръчно натискане и синхронно завъртане на два ключа (един за лидера на екипа, другия за администратора). И всички са щастливи.
И сега е време да се превърнем в противници на клъстерирането на бази данни.
Тъмна страна
Аргументирайки защо не си струва да контейнеризираме базата данни и да продължим да я изпълняваме на един централен сървър, ние няма да се сведем до реториката на ортодоксиите и твърдения като „дядовците управляваха бази данни на хардуер, и ние също!“ Вместо това, нека се опитаме да измислим ситуация, в която контейнеризацията действително би донесла осезаеми дивиденти.
Съгласете се, проектите, които наистина се нуждаят от основа в контейнер, могат да се преброят на пръстите на едната ръка от не най-добрия оператор на фреза. В по-голямата си част дори самото използване на k8s или Docker Swarm е излишно - доста често се прибягва до тези инструменти поради общия шум на технологиите и нагласите на „всемогъщия“ в лицето на половете да набутат всичко в облаци и контейнери. Ами защото сега е модерно и всички го правят.
В поне половината от случаите използването на Kubernetis или просто Docker в проект е излишно. Въпросът е, че не всички екипи или аутсорсинг компании, наети да поддържат инфраструктурата на клиента, са наясно с това. По-лошо е, когато се налагат контейнери, защото това струва определено количество монети на клиента.
Като цяло има мнение, че докер/куб мафията глупаво мачка клиенти, които възлагат тези инфраструктурни проблеми на външни изпълнители. В крайна сметка, за да работим с клъстери, се нуждаем от инженери, които са способни на това и като цяло разбират архитектурата на внедреното решение. Веднъж вече описахме нашия случай с изданието Republic - там обучихме екипа на клиента да работи в реалностите на Kubernetis и всички останаха доволни. И беше прилично. Често „внедрителите“ на k8s вземат инфраструктурата на клиента като заложник - защото сега само те разбират как работи всичко там; няма специалисти от страна на клиента.
Сега си представете, че по този начин възлагаме не само частта на уеб сървъра, но и поддръжката на базата данни. Казахме, че BD е сърцето, а загубата на сърцето е фатална за всеки жив организъм. Накратко, перспективите не са от най-добрите. Така че, вместо hype Kubernetis, много проекти просто не трябва да се занимават с нормалната тарифа за AWS, което ще реши всички проблеми с натоварването на техния сайт/проект. Но AWS вече не е на мода, а парадирането струва повече от пари - за съжаление и в ИТ средата.
ДОБРЕ. Може би проектът наистина се нуждае от клъстериране, но ако всичко е ясно с приложенията без състояние, тогава как можем да организираме прилична мрежова свързаност за клъстерирана база данни?
Ако говорим за безпроблемно инженерно решение, каквото е преходът към k8s, тогава основното ни главоболие е репликацията на данни в клъстерна база данни. Някои СУБД първоначално са доста лоялни към разпределението на данни между техните отделни инстанции. Много други не са толкова гостоприемни. И доста често основният аргумент при избора на СУБД за нашия проект не е възможността за репликация с минимални разходи за ресурси и инженеринг. Особено ако проектът не е първоначално планиран като микроуслуга, а просто се е развил в тази посока.
Смятаме, че няма нужда да говорим за скоростта на мрежовите устройства - те са бавни. Тези. Все още нямаме реална възможност, ако нещо се случи, да рестартираме екземпляр на СУБД някъде, където има повече, например мощност на процесора или свободна RAM. Много бързо ще се сблъскаме с производителността на виртуализираната дискова подсистема. Съответно, СУБД трябва да бъде прикован към собствен персонален набор от машини, разположени в непосредствена близост. Или е необходимо по някакъв начин отделно да се охлади достатъчно бързата синхронизация на данни за предполагаемите резерви.
Продължавайки темата за виртуалните файлови системи: Docker Volumes, за съжаление, не са безпроблемни. Като цяло, по въпрос като дългосрочно надеждно съхранение на данни, бих искал да се задоволя с най-технически простите схеми. А добавянето на нов абстракционен слой от FS на контейнера към FS на родителския хост само по себе си е риск. Но когато работата на системата за поддръжка на контейнери също срещне трудности при предаването на данни между тези слоеве, тогава това наистина е катастрофа. В момента повечето от проблемите, известни на прогресивното човечество, изглеждат изкоренени. Но разбирате, колкото по-сложен е механизмът, толкова по-лесно се чупи.
В светлината на всички тези „приключения“ е много по-изгодно и по-лесно да поддържате базата данни на едно място и дори ако трябва да контейнеризирате приложението, оставете го да работи самостоятелно и чрез шлюза за разпространение получавате едновременна комуникация с база данни, която ще се чете и записва само веднъж и на едно място. Този подход намалява до минимум вероятността от грешки и десинхронизация.
До какво водим? Освен това контейнеризацията на базата данни е подходяща, когато има реална нужда от нея. Не можете да напълните база данни с пълно приложение и да я завъртите, сякаш имате две дузини микроуслуги - това не работи по този начин. И това трябва да се разбере ясно.
Вместо продукция
Ако чакате ясно заключение „да виртуализирате базата данни или не“, тогава ще ви разочароваме: няма да е тук. Защото при създаването на всяко инфраструктурно решение човек трябва да се ръководи не от модата и прогреса, а преди всичко от здравия разум.
Има проекти, за които принципите и инструментите, които идват с Kubernetis, пасват перфектно и в такива проекти има спокойствие поне в бекенд зоната. И има проекти, които не се нуждаят от контейнеризация, а от нормална сървърна инфраструктура, защото те принципно не могат да се премащабират към модела на клъстера на микросервизите, защото ще паднат.
Източник: www.habr.com