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