Прывітанне, Хабр!
Нагадваем, што ў нас выйшла чарговая надзвычай цікавая і карысная. аб патэрнах Kubernetes. Пачыналася ўсё яшчэ з "Брэндана Бернса, і, зрэшты, праца ў гэтым сегменце ў нас . Сёння ж мы прапануем вам пачытаць артыкул з блога MinIO, коратка выкладае тэндэнцыі і спецыфіку патэрнаў захоўвання дадзеных у Kubernetes.
Kubernetes фундаментальным чынам змяніў традыцыйныя патэрны распрацоўкі і разгортвання прыкладанняў. Цяпер у каманды могуць сыходзіць лічаныя дні на распрацоўку, тэставанне і разгортванне прыкладання - у розных асяродках, і ўсё гэта ў межах кластараў Kubernetes. Такая праца з тэхналогіямі папярэдніх пакаленняў звычайна займала цэлыя тыдні, калі не месяцы.
Такое паскарэнне стала магчыма дзякуючы абстракцыі, якая забяспечваецца Kubernetes - гэта значыць, дзякуючы таму, што Kubernetes сам ажыццяўляе ўзаемадзеянне з нізкаўзроўневымі дэталямі фізічных або віртуальных машын, дазваляючы карыстачам аб'яўляць сярод іншых параметраў патрэбны працэсар, патрэбны аб'ём памяці, колькасць асобнікаў кантэйнераў. Паколькі падтрымкай Kubernetes занята велізарная супольнасць, а маштабы ўжывання Kubernetes увесь час пашыраюцца, ён з вялікім адрывам лідзіруе сярод усіх платформаў аркестрацыі кантэйнераў.
Па меры пашырэння выкарыстання Kubernetes расце і блытаніна з нагоды ужывальных у ім патэрнаў захоўвання дадзеных.
Пры ўсеагульнай канкурэнцыі за кавалак пірага Kubernetes (гэта значыць, за сховішча дадзеных), калі заходзіць гутарку аб захоўванні дадзеных, сігнал тут тоне ў моцным шуме.
Kubernetes увасабляе сучасную мадэль распрацоўкі і разгортвання прыкладанняў, а таксама кіравання імі. Такая сучасная мадэль адмацоўвае захоўванне дадзеных ад вылічэнняў. Каб цалкам зразумець такое адмацаванне ў кантэксце Kubernetes, таксама трэба зразумець, што такое прыкладанні, якія працуюць з захаваннем стану і без захавання стану, а таксама як з гэтым спалучаецца захоўванне дадзеных. Менавіта тут REST API падыход, які ўжываецца S3, валодае відавочнымі перавагамі ў параўнанні з падыходам POSIX/CSI, характэрным для іншых рашэнняў.
У гэтым артыкуле мы пагаворым аб патэрнах захоўвання дадзеных у Kubernetes і асобна кранем спрэчкі аб прыкладаннях, якія працуюць з захаваннем і без захавання стану, каб як след зразумець, у чым жа заключаецца розніца паміж імі, і чаму яна важная. Далей у тэксце будуць разгледжаны прыкладанні і прымяняюцца ў іх патэрны захоўвання дадзеных у святле найлепшых практык працы з кантэйнерамі і Kubernetes.
Кантэйнеры без захавання стану
Кантэйнеры па прыродзе сваёй легкаважныя і эфемерныя. Іх можна без працы спыняць, выдаляць ці разгортваць на іншым вузле - на ўсё гэта сыходзяць лічаныя секунды. У вялікай сістэме аркестрацыі кантэйнераў такія аперацыі адбываюцца ўвесь час, і карыстачы нават не заўважаюць такіх змен. Аднак, перасоўванні магчымыя, толькі калі ў кантэйнера няма ніякіх залежнасцяў ад вузла, на якім ён размешчаны. Аб такіх кантэйнерах кажуць, што яны працуюць без захавання стану.
Кантэйнеры з захаваннем стану
Калі кантэйнер захоўвае дадзеныя на лакальна падлучаных прыладах (або на блокавай прыладзе), то сховішча дадзеных, на якім ён размешчаны, давядзецца перамяшчаць на новы вузел разам з самім кантэйнерам - у выпадку адмовы. Гэта важна, паколькі ў адваротным выпадку прыкладанне, запушчанае ў кантэйнеры, не зможа правільна функцыянаваць, бо яму неабходна звяртацца да дадзеных, захаваным на лакальных носьбітах. Аб такіх кантэйнерах кажуць, што яны працуюць з захаваннем стану.
З чыста тэхнічнага пункта гледжання, кантэйнеры з захаваннем стану таксама можна перамяшчаць на іншыя вузлы. Звычайна гэта забяспечваецца пры дапамозе размеркаваных файлавых сістэм ці блокавых сеткавых сховішчаў дадзеных, прымацаваных да ўсіх вузлоў, на якіх працуюць кантэйнеры. Такім чынам, кантэйнеры атрымліваюць доступ да тамоў для персістэнтнага захоўвання дадзеных, і інфармацыя захоўваецца на дысках, якія знаходзяцца па ўсёй сетцы. Такі метад я назавукантэйнерным падыходам з захаваннем стану», і ў астатняй частцы артыкула так і буду называць яго дзеля аднастайнасці.
Пры тыповым кантэйнерным падыходзе з захаваннем стану ўсе поды прыкладанняў прымацоўваюцца да адной размеркаванай файлавай сістэме - атрымліваецца свайго роду падзялянае сховішча, дзе знаходзяцца ўсе дадзеныя прыкладанняў. Прытым, што магчымы некаторыя варыяцыі, гэта высокаўзроўневы падыход.
Цяпер жа давайце разбяромся, чаму кантэйнерны падыход з захаваннем стану ў хмарна-арыентаваным свеце з'яўляецца антыпатэрнам.
Воблачна-арыентаванае праектаванне прыкладанняў
Традыцыйна прыкладанні выкарыстоўвалі базы дадзеных для структураванага захоўвання інфармацыі і лакальныя дыскі ці размеркаваныя файлавыя сістэмы, куды скідаліся ўсе неструктураваныя ці нават паўструктураваныя дадзеныя. Па меры таго, як аб'ёмы неструктураваных дадзеных раслі, распрацоўнікі ўсвядомілі, што POSIX залішне "балбатлівы", спалучаны са значнымі выдаткамі і, у канчатковым выніку, замінае працы прыкладання пры пераходзе да сапраўды вялікім маштабам.
Гэта ў асноўным і паспрыяла з'яўленню новага стандарту захоўвання дадзеных, гэта значыць, воблачна-арыентаваных сховішчаў, якія працуюць пераважна на аснове REST API і вызваляюць дадатак ад цяжкага абслугоўвання лакальнага сховішчы дадзеных. У такім разе прыкладанне фактычна пераходзіць у рэжым працы без захавання стану (паколькі стан знаходзіцца ў выдаленым сховішчы). Сучасныя прыкладанні ўзводзяцца з нуля ўжо з улікам гэтага фактару. Як правіла, любое сучаснае прыкладанне, якое апрацоўвае дадзеныя таго ці іншага роду (лагі, метададзеныя, блобы і г.д.) пабудавана па хмарна-арыентаванай парадыгме, дзе стан пераносіцца ў спецыяльна выдзеленую для яго захоўвання софтверную сістэму.
Кантэйнерны падыход з захаваннем стану прымушае ўсю гэтую парадыгму адкаціцца роўна да таго, з чаго яна пачыналася!
Пры выкарыстанні інтэрфейсаў POSIX для захоўвання дадзеных прыкладання працуюць у тым жа духу, як калі б яны захоўвалі стан, і з-за гэтага адыходзяць ад найболей важных пастулатаў хмарна-арыентаванага праектавання, гэта значыць, ад магчымасці вар'іраваць памеры працоўных струменяў прыкладання ў залежнасці ад уваходнай нагрузкі, перамяшчацца на новы вузел, як толькі актуальны вузел адмовіць, і гэтак далей.
Прыгледзеўшыся да гэтай сітуацыі больш уважліва, выяўляем, што пры выбары сховішчы дадзеных мы зноў і зноў сутыкаемся з дылемай «POSIX супраць REST API», АЛЕ з дадатковым пагаршэннем праблем POSIX, абумоўленым размеркаванай прыродай асяродкаў Kubernetes. У прыватнасці,
- POSIX балбатлівы: семантыка POSIX патрабуе асацыяваць з кожнай аперацыяй метададзеныя і дэскрыптары файлаў, якія дапамагаюць падтрымліваць стан аперацыі. Гэта прыводзіць да значных выдаткаў, якія не маюць ніякай рэальнай каштоўнасці. API для захоўвання аб'ектаў, у прыватнасці, S3 API, пазбавіліся ад гэтых патрабаванняў, дазваляючы з дадаткам спрацаваць, а затым «забыцца» аб выкліку. Водгук сістэмы захоўвання дадзеных паказвае, паспяхова было выканана дадзенае дзеянне ці не. У выпадку няўдачы дадатак можа выканаць паўторную спробу.
- Сеткавыя абмежаванні: У размеркаванай сістэме маецца на ўвазе, што можа існаваць мноства прыкладанняў, якія спрабуюць запісаць дадзеныя на адзін і той жа прымацаваны носьбіт. Таму, мала таго, што прыкладанні будуць канкураваць сябар з сябрам за паласу перадачы дадзеных (каб адправіць дадзеныя на носьбіт), сама сістэма захоўвання дадзеных будзе канкураваць за гэтую паласу, рассылаючы дадзеныя па фізічных кружэлках. З-за гаманкі POSIX колькасць сеткавых выклікаў вырастае ў некалькі разоў. З іншага боку, S3 API забяспечвае дакладнае размежаванне сеткавых выклікаў паміж тымі, што паступаюць з кліента на сервер, і тымі, што адбываюцца ў межах сервера.
- бяспеку: Мадэль бяспекі POSIX разлічана на актыўны ўдзел чалавека: адміністратары канфігуруюць канкрэтныя ўзроўні доступу для кожнага карыстальніка або групы. Такая парадыгма складана адаптуецца пад воблачна-арыентаваны свет. Сучасныя прыкладанні залежаць ад мадэляў бяспекі, завязаных на API, дзе правы доступу вызначаюцца як набор палітык, вылучаюцца сэрвісныя акаўнты, часовыя ўліковыя дадзеныя і г.д.
- кіравальнасць: Кантэйнеры з захаваннем стану цягнуць пэўныя выдаткі, звязаныя з кіраваннем. Гаворка аб сінхранізацыі паралельнага доступу да дадзеных, аб забеспячэнні ўзгодненасці дадзеных, усё гэта патрабуе ўважліва ўзважыць, якія патэрны доступу да дадзеных выкарыстоўваць. Даводзіцца ўсталёўваць, кантраляваць і канфігураваць дадатковыя праграмы, не кажучы ўжо пра дадатковыя намаганні, якія затрачваюцца на распрацоўку.
Кантэйнерны інтэрфейс сховішчы дадзеных
Тады як інтэрфейс кантэйнернага сховішчы дадзеных (CSI) выдатна дапамог з распаўсюджваннем узроўня тамоў Kubernetes, часткова перадаўшы яго іншым вендарам сховішчаў дадзеных, але таксама выпадкова паспрыяў перакананні, што кантэйнерны падыход з захаваннем стану з'яўляецца рэкамендаваным метадам захоўвання дадзеных у Kubernetes.
CSI быў распрацаваны як стандарт прадастаўлення адвольных сістэм блокавага і файлавага захоўвання дадзеных атрыманых у спадчыну прыкладанням пры працы з Kubernetes. І, як было паказана ў гэтым артыкуле, адзіная сітуацыя, у якой мэтазгодны кантэйнерны падыход з захаваннем стану (і CSI ў яго цяперашняй форме) - калі само прыкладанне з'яўляецца ўспадкаванай сістэмай, у якой немагчыма дадаць падтрымку API аб'ектнага сховішчы дадзеных.
Важна разумець, што, выкарыстоўваючы CSI у яго цяперашняй форме, гэта значыць, мантуючы тамы пры працы з сучаснымі прыкладаннямі, мы сутыкнемся прыкладна з такімі ж праблемамі, што ўзнікалі і ў сістэмах, дзе захоўванне дадзеных арганізавана ў стылі POSIX.
Больш якасны падыход
У дадзеным выпадку важна разумець, што большасць прыкладанняў па сутнасці сваёй не заточаныя менавіта пад працу з захаваннем стану або без захавання стану. Такія паводзіны залежаць ад агульнай архітэктуры сістэмы і ад канкрэтных варыянтаў, абраных пры праектаванні. Пагаворым крыху аб прыкладаннях, якія захоўваюць стан.
У прынцыпе, усе дадзеныя прыкладанняў можна размеркаваць на некалькі шырокіх тыпаў:
- Дадзеныя логаў
- Дадзеныя пазнак часу
- Дадзеныя транзакцый
- метададзеныя
- Выявы кантэйнераў
- Дадзеныя блобаў (вялікіх двайковых аб'ектаў)
Усе гэтыя тыпы дадзеных вельмі добра падтрымліваюцца на сучасных платформах захоўвання дадзеных, і існуе некалькі хмарна-арыентаваных платформаў, прыстасаваных для пастаўкі дадзеных у кожным з гэтых канкрэтных фарматаў. Напрыклад, дадзеныя транзакцый і метададзеныя могуць знаходзіцца ў сучаснай хмарна-арыентаванай базе дадзеных, такі як CockroachDB, YugaByte і т.д. Выявы кантэйнераў або дадзеныя блобаў могуць захоўвацца ў рэестры docker, заснаваным на MinIO. Дадзеныя часавых пазнак могуць захоўвацца ў базе дадзеных часовых шэрагаў, напрыклад, InfluxDB і г.д. Не будзем тут удавацца ў дэталі кожнага тыпу дадзеных і адпаведных прыкладанняў, але агульная ідэя ў тым, каб пазбегнуць персістэнтнага захоўвання дадзеных, заснаванага на лакальным манціраванні дыскаў.
Акрамя таго, часцяком апыняецца эфектыўна падаць узровень часавага кэшавання, службоўца для прыкладанняў своеасаблівым сховішчам часавых файлаў, але прыкладанні не павінны залежаць ад гэтага ўзроўня як ад крыніцы ісціны.
Сховішча для прыкладанняў з захаваннем стану
Тады як у большасці выпадкаў карысна трымаць прыкладанні без захавання стану, тыя прыкладанні, што прызначаны для захоўвання дадзеных - напрыклад, базы дадзеных, аб'ектныя сховішчы, сховішчы ключоў і значэнняў - павінны захоўваць стан. Давайце разбяромся, чаму гэтыя прыкладанні разгортваюць на Kubernetes. У якасці прыкладу возьмем MinIO, але падобныя прынцыпы дастасавальныя і да любых іншых буйных хмарна-арыентаваных сістэм захоўвання дадзеных.
Воблачна-арыентаваныя прыкладанні праектуюцца з разлікам на максімальна эфектыўнае выкарыстанне гнуткасці, уласцівай кантэйнерам. Гэта азначае, што ў іх не робіцца ніякіх дапушчэнняў адносна таго асяроддзя, у якім яны будуць разгортвацца. Напрыклад, у MinIO выкарыстоўваецца ўнутраны механізм залішняга кадавання (erasure coding), які забяспечвае сістэме дастатковую ўстойлівасць, каб яна заставалася працаздольнай нават пры адмове паловы дыскаў. Таксама MinIO кіруе цэласнасцю і бяспекай дадзеных, выкарыстоўваючы ўласнае хэшаванне і шыфраванне на баку сервера.
Для такіх хмарна-арыентаваных прыкладанняў у якасці рэзервовага сховішча найболей зручныя лакальныя персістэнтныя тамы (PV). Лакальны PV дае магчымасць захоўвання волкіх дадзеных, тады як прыкладанні, якія працуюць па-над гэтымі PV, самастойна збіраюць інфармацыю, якая дазваляе маштабаваць дадзеныя і кіраваць якія растуць патрабаваннямі да дадзеных.
Гэты падыход значна прасцей і значна лепш маштабуецца ў параўнанні з PV на аснове CSI, якія прыўносяць у сістэму ўласныя ўзроўні кіравання дадзенымі і надмернасці; справа ў тым, што гэтыя ўзроўні звычайна канфліктуюць з прыкладаннямі, спраектаванымі па прынцыпе захавання стану.
Упэўнены рух да адмацавання дадзеных ад вылічэнняў
У гэтым артыкуле мы пагаварылі аб тым, як прыкладанні пераарыентуюцца на працу без захавання стану, або, іншымі словамі, захоўванне дадзеных абмяжоўваецца ад вылічэнняў над імі. У заключэнне разгледзім некалькі рэальных прыкладаў такога трэнду.
, знакамітая платформа для аналізу дадзеных, традыцыйна выкарыстоўвалася з захаваннем стану і з разгортваннем у файлавай сістэме HDFS. Аднак, па меры пераходу Spark а хмарна-арыентаваны мір, гэтая платформа ўсё актыўней выкарыстоўваецца без захавання стану з выкарыстаннем `s3a`. Spark ужывае s3a для перадачы стану ў іншыя сістэмы, тады як самі кантэйнеры Spark працуюць цалкам без захавання стану. Іншыя буйныя enterprise-гульцы ў галіне аналітыкі вялікіх дадзеных, у прыватнасці, , , таксама пераходзяць да працы з падзелам захоўвання дадзеных і вылічэнняў над імі.
Падобныя патэрны таксама прасочваюцца на іншых буйных аналітычных платформах, сярод якіх Presto, Tensorflow to R, Jupyter. Выгружаючы стан у выдаленыя хмарныя сістэмы захоўвання дадзеных, становіцца значна прасцей кіраваць вашым дадаткам і маштабаваць яго. Акрамя таго, гэта спрыяе партавальнасці прыкладання ў разнастайныя асяроддзі.
Крыніца: habr.com