Некако, историјски гледано, ИТ индустрија је из било ког разлога подељена на два условна табора: оне који су „за“ и оне који су „против“. Штавише, предмет спора може бити потпуно произвољан. Који је ОС бољи: Вин или Линук? На Андроид или иОС паметном телефону? Да ли све треба да чувате у облацима или да то ставите на хладно РАИД складиште и ставите шрафове у сеф? Да ли ПХП људи имају право да се зову програмери? Ови спорови су понекад искључиво егзистенцијалне природе и немају другог основа осим спортског интереса.
Десило се да су са појавом контејнера и све ове омиљене кухиње са доцкером и условним к8с, почеле дебате „за“ и „против“ коришћења нових могућности у различитим областима позадинског дела. (Хајде да унапред направимо резерву да иако ће Кубернетес најчешће бити назначен као оркестратор у овој дискусији, избор овог алата није од суштинског значаја. Уместо тога, можете да замените било који други који вам се чини најпогоднијим и познатијим .)
И, чини се, ово би био једноставан спор између две стране истог новчића. Бесмислена и немилосрдна као вечита конфронтација Вин против Линука, у којој адекватни људи постоје негде на средини. Али у случају контејнеризације није све тако једноставно. Обично у оваквим споровима нема праве стране, али у случају „користити” или „не користити” контејнере за чување база података, све се окреће наопачке. Јер, у извесном смислу, и присталице и противници оваквог приступа су у праву.
Светла страна
Аргумент Светле стране може се укратко описати једном фразом: „Здраво, 2к19 је испред прозора!“ Звучи као популизам, наравно, али ако се детаљно удубите у ситуацију, то има своје предности. Хајде да их сада средимо.
Рецимо да имате велики веб пројекат. Могла је у почетку бити изграђена на бази микросервисног приступа, или је у неком тренутку до ње дошла еволутивним путем - то заправо и није толико важно. Распршили сте наш пројекат у засебне микросервисе, поставили оркестрацију, балансирање оптерећења и скалирање. И сада, мирне савести, пијуцкате мохито у висећој мрежи током хабра ефеката уместо да подижете пале сервере. Али у свим акцијама морате бити доследни. Врло често је само сама апликација — код — контејнеризована. Шта још имамо осим кода?
Тако је, подаци. Срце сваког пројекта су његови подаци: то може бити или типичан ДБМС - МиСКЛ, Постгре, МонгоДБ, или складиште које се користи за претрагу (ЕластицСеарцх), складиште кључ/вредност за кеширање - на пример, редис, итд. Тренутно нисмо говорићемо о погрешним опцијама имплементације бацкенд-а када се база података сруши због лоше написаних упита, а уместо тога ћемо говорити о обезбеђивању толеранције грешака ове базе података под оптерећењем клијента. На крају крајева, када контејнеришемо нашу апликацију и дозволимо јој да слободно скалира да обради било који број долазних захтева, то природно повећава оптерећење базе података.
У ствари, канал за приступ бази података и сервер на коме она ради постају иглена ушица у нашем прелепом позадинском делу контејнера. Истовремено, главни мотив виртуелизације контејнера је мобилност и флексибилност структуре, што нам омогућава да што ефикасније организујемо дистрибуцију вршних оптерећења кроз целокупну инфраструктуру која нам је на располагању. Односно, ако не контејнеризујемо и не уведемо све постојеће елементе система широм кластера, правимо веома озбиљну грешку.
Много је логичније груписати не само саму апликацију, већ и сервисе одговорне за чување података. Груписањем и постављањем веб сервера који раде независно и међусобно распоређују оптерећење у к8с-у, већ решавамо проблем синхронизације података – исти коментари на постове, ако за пример узмемо неки медиј или блог платформу. У сваком случају, имамо интра-кластер, чак и виртуелну, репрезентацију базе података као ЕктерналСервице. Питање је да сама база података још није груписана – веб сервери распоређени у коцки преузимају информације о променама из наше статичке борбене базе података, која се засебно ротира.
Да ли осећате улов? Користимо к8с или Сварм да дистрибуирамо оптерећење и избегавамо рушење главног веб сервера, али то не радимо за базу података. Али ако се база података сруши, онда цела наша кластерска инфраструктура нема смисла – чему су добре празне веб странице које враћају грешку у приступу бази података?
Због тога је потребно кластеровати не само веб сервере, како се то обично ради, већ и инфраструктуру базе података. Само на тај начин можемо обезбедити структуру која у потпуности функционише у једном тиму, али истовремено независна једни од других. Штавише, чак и ако се половина нашег позадинског система „сруши“ под оптерећењем, остатак ће преживети, а систем синхронизације база података једне са другом унутар кластера и могућност бесконачног скалирања и распоређивања нових кластера помоћи ће да се брзо постигне потребан капацитет - само да постоје регали у центру података .
Поред тога, модел базе података дистрибуиран у кластерима омогућава вам да ову базу података однесете тамо где је потребна; Ако говоримо о глобалном сервису, онда је прилично нелогично вртити веб кластер негде у области Сан Франциска и истовремено слати пакете приликом приступа бази података у Подмосковљу и назад.
Такође, контејнеризација базе података вам омогућава да изградите све елементе система на истом нивоу апстракције. Што, заузврат, омогућава управљање овим системом директно из кода, од стране програмера, без активног учешћа администратора. Програмери су сматрали да је за нови потпројекат потребан посебан ДБМС - лако! написао иамл датотеку, отпремио је у кластер и готови сте.
И наравно, интерни рад је знатно поједностављен. Реците ми, колико пута сте затворили очи када је нови члан тима ставио руке у борбену базу за посао? Који је, заправо, једини који имате и који се тренутно врти? Наравно, сви смо ми одрасли овде, а негде имамо свежу резерву, а још даље - иза полице са бакиним краставцима и старим скијама - још једну резерву, можда чак и у хладњачи, јер ти је канцеларија већ једном горела. Али свеједно, свако увођење новог члана тима са приступом борбеној инфраструктури и, наравно, борбеној бази података је канта валидола за све око себе. Па, ко га зна, новајлија, можда је кршне руке? То је страшно, сложићете се.
Контејнеризација и, у ствари, дистрибуирана физичка топологија базе података вашег пројекта помаже да се избегну такви моменти валидације. Не верујете новајлији? ОК! Хајде да му дамо сопствени кластер за рад и да искључимо базу података са осталим кластерима - синхронизација само ручним притиском и синхроном ротацијом два кључа (један за вођу тима, други за администратора). И сви су срећни.
А сада је време да се промените у противнике груписања база података.
Тамна страна
Аргументирајући зашто не вреди контејнерисати базу података и наставити да је покреће на једном централном серверу, нећемо се спустити на реторику ортодоксије и изјаве попут „дедови су водили базе података на хардверу, па ћемо и ми!“ Уместо тога, покушајмо да дођемо до ситуације у којој би контејнеризација заправо исплатила опипљиве дивиденде.
Слажем се, пројекти којима је заиста потребна база у контејнеру могу се набројати на прсте једне руке од стране не најбољег оператера глодалице. Углавном, чак је и сама употреба к8с-а или Доцкер Сварм-а сувишна – често се овим алатима прибегава због опште хајке технологије и ставова „свемоћног“ у личности полова да све гурне у облаци и контејнери. Па, зато што је то сада модерно и сви то раде.
У најмање половини случајева, коришћење Кубернетиса или само Доцкер-а на пројекту је сувишно. Проблем је у томе што нису сви тимови или спољне компаније ангажоване да одржавају инфраструктуру клијента тога свесни. Још је горе када се намећу контејнери, јер то клијенту кошта одређену количину новчића.
Генерално, постоји мишљење да доцкер/цубе мафија глупо слама клијенте који предају ова питања инфраструктури. Уосталом, да бисмо радили са кластерима, потребни су нам инжењери који су за то способни и генерално разумеју архитектуру имплементираног решења. Једном смо већ описали наш случај са Републичком публикацијом - тамо смо обучили клијентов тим да ради у реалности Кубернетиса и сви су били задовољни. И било је пристојно. Често „имплементари“ к8с узимају инфраструктуру клијента као таоца - јер сада само они разумеју како све тамо функционише; на страни клијента нема стручњака.
Сада замислите да на овај начин ангажујемо не само део веб сервера, већ и одржавање базе података. Рекли смо да је БД срце, а губитак срца је погубан за сваки живи организам. Укратко, изгледи нису најбољи. Дакле, уместо хипе Кубернетиса, многи пројекти једноставно не би требало да се замарају са нормалном тарифом за АВС, која ће решити све проблеме са оптерећењем на њиховом сајту/пројекту. Али АВС више није модеран, а разметање вреди више од новца - нажалост, иу ИТ окружењу.
ОК. Можда је пројекту заиста потребно груписање, али ако је све јасно са апликацијама без стања, како онда можемо организовати пристојну мрежну повезаност за кластеризовану базу података?
Ако говоримо о беспрекорном инжењерском решењу, што је прелазак на к8с, онда је наша главна главобоља репликација података у кластеризованој бази података. Неки ДБМС-ови су у почетку прилично лојални дистрибуцији података између својих појединачних инстанци. Многи други нису тако добродошли. И прилично често главни аргумент у избору ДБМС-а за наш пројекат није могућност реплицирања уз минималне трошкове ресурса и инжењеринга. Поготово ако пројекат у почетку није био планиран као микросервис, већ је једноставно еволуирао у овом правцу.
Мислимо да нема потребе да говоримо о брзини мрежних дискова – они су спори. Оне. Још увек немамо праву прилику, ако се нешто деси, да поново покренемо ДБМС инстанцу негде где има више, на пример, снаге процесора или слободне РАМ меморије. Врло брзо ћемо наићи на перформансе виртуелизованог подсистема диска. Сходно томе, ДБМС мора бити прикован за сопствени лични скуп машина које се налазе у непосредној близини. Или је потребно некако одвојено охладити довољно брзу синхронизацију података за наводне резерве.
Настављајући тему виртуелних система датотека: Доцкер волумени, нажалост, нису без проблема. Генерално, у таквом питању као што је дугорочно поуздано складиштење података, желео бих да се задовољим технички најједноставнијим шемама. А додавање новог слоја апстракције из ФС контејнера у ФС родитељског хоста је ризик само по себи. Али када рад система за подршку контејнеризацији такође наиђе на потешкоће са преносом података између ових слојева, онда је то заиста катастрофа. У овом тренутку, већина проблема познатих прогресивном човечанству изгледа да је искорењена. Али разумете, што је механизам сложенији, лакше се ломи.
У светлу свих ових „авантура“, много је исплативије и лакше држати базу података на једном месту, а чак и ако треба да контејнеризујете апликацију, пустите је да ради саму и да преко дистрибутивног гејтвеја прима истовремену комуникацију са базе података, која ће се читати и писати само једном и На једном месту. Овај приступ смањује вероватноћу грешака и десинхронизације на минимум.
до чега водимо? Штавише, контејнеризација базе података је прикладна тамо где постоји стварна потреба за њом. Не можете да напуните базу података са пуном апликацијом и завртите је као да имате два туцета микросервиса - то не функционише тако. И ово се мора јасно разумети.
Уместо резултата
Ако чекате јасан закључак „виртуелизовати базу података или не“, онда ћемо вас разочарати: неће бити овде. Јер при креирању било каквог инфраструктурног решења мора се водити не модом и напретком, већ, пре свега, здравим разумом.
Постоје пројекти за које се принципи и алати који долазе уз Кубернетис савршено уклапају, а у таквим пројектима влада мир барем у бацкенд области. А постоје пројекти којима није потребна контејнеризација, већ нормална серверска инфраструктура, јер суштински не могу да прескалују на модел микросервисног кластера, јер ће пасти.
Извор: ввв.хабр.цом