Эй Хабр!
Биз дагы бир абдан кызыктуу жана пайдалуу чыгарганыбызды эскертебиз Kubernetes үлгүлөрү жөнүндө. Мунун баары ""Брендан Бернс, демек, бизде бул сегментте иш бар . Бүгүн биз сизди MiniIO блогунан Kubernetesтеги маалыматтарды сактоо үлгүлөрүнүн тенденцияларын жана өзгөчөлүктөрүн кыскача баяндаган макаланы окууга чакырабыз.
Kubernetes салттуу тиркемелерди иштеп чыгуу жана жайылтуу моделдерин түп тамырынан бери өзгөрттү. Эми команда бир нече күндүн ичинде бир нече чөйрөдө, бардыгы Kubernetes кластерлеринин ичинде тиркемени иштеп чыгып, сынап жана орното алат. Технологиянын мурунку муундары менен мындай иш, адатта, айлар болбосо, жумаларды талап кылат.
Бул ылдамдатуу Kubernetes тарабынан берилген абстракциянын аркасында мүмкүн болот, башкача айтканда, Кубернетес физикалык же виртуалдык машиналардын төмөнкү деңгээлдеги деталдары менен өз ара аракеттенип, колдонуучуларга керектүү процессорду, эстутумдун керектүү көлөмүн жана контейнердин санын жарыялоого мүмкүндүк берет. башка параметрлер менен катар мисалдар. Кубернетести колдогон жана аны кабыл алуу тынымсыз кеңейип жаткан чоң коомчулук менен Kubernetes бардык контейнердик оркестр платформаларынын арасында кеңири айырма менен лидер болуп саналат.
Kubernetesти колдонуу өскөн сайын, анын сактоо үлгүлөрү боюнча башаламандык да күчөйт..
Ар бир адам Kubernetes пирогунун бир бөлүгү үчүн (б.а. маалыматтарды сактоо) атаандашкандыктан, маалыматтарды сактоо жөнүндө сөз болгондо, сигнал көп ызы-чууга чөгүп кетет.
Kubernetes тиркемелерди иштеп чыгуу, жайылтуу жана башкаруу үчүн заманбап моделди камтыйт. Бул заманбап модель маалыматтарды сактоону эсептөөдөн ажыратат. Kubernetes контекстинде бөлүнүүнү толук түшүнүү үчүн, сиз ошондой эле мамлекеттик жана жарандыгы жок тиркемелер деген эмне экенин жана маалымат сактагычы ага кантип туура келерин түшүнүшүңүз керек. Бул жерде S3 колдонгон REST API ыкмасы башка чечимдердин POSIX/CSI ыкмасына караганда айкын артыкчылыктарга ээ.
Бул макалада биз Кубернетестеги маалыматтарды сактоо үлгүлөрү жөнүндө сүйлөшөбүз жана алардын ортосундагы айырма эмнеде экенин жана эмне үчүн маанилүү экенин жакшыраак түшүнүү үчүн мамлекеттик жана жарандыгы жок тиркемелердин ортосундагы талашка токтолобуз. Тексттин калган бөлүгү тиркемелерди жана алардын маалыматтарды сактоо үлгүлөрүн контейнерлер жана Kubernetes менен иштөө боюнча мыкты тажрыйбалардын негизинде карайт.
Жарандыгы жок контейнерлер
Контейнерлер табиятынан жеңил жана эфемердик. Аларды оңой эле токтотууга, алып салууга же башка түйүнгө жайгаштырууга болот - бардыгы секунданын ичинде. Чоң контейнердик оркестрдик системада мындай операциялар дайыма болуп турат жана колдонуучулар мындай өзгөрүүлөрдү байкашпайт да. Бирок, кыймылдар контейнердин ал жайгашкан түйүнгө эч кандай көз карандылыгы болбосо гана мүмкүн болот. Мындай контейнерлер иштейт деп айтылат жарандыгы жок.
Мамлекеттик контейнерлер
Эгерде контейнер маалыматтарды локалдык түрдө тиркелген түзмөктөрдө (же блоктук түзүлүштө) сактаса, анда ал жайгашкан маалымат кампасы бузулган учурда контейнердин өзү менен бирге жаңы түйүнгө жылдырылышы керек болот. Бул маанилүү, анткени антпесе контейнерде иштеген тиркеме туура иштей албайт, анткени ал жергиликтүү медиада сакталган маалыматтарга кирүү керек. Мындай контейнерлер иштейт деп айтылат мамлекеттик.
Таза техникалык көз караштан алганда, мамлекеттик контейнерлер башка түйүндөргө да жылдырылышы мүмкүн. Бул адатта бөлүштүрүлгөн файл тутумдарын же контейнерлерди иштеткен бардык түйүндөргө тиркелген тармактык сактагычты колдонуу менен жетишилет. Ошентип, контейнерлер маалыматтарды туруктуу сактоо үчүн көлөмгө жете алышат жана маалымат бардык тармакта жайгашкан дисктерде сакталат. Мен бул ыкманы чакырам "мамлекеттик контейнер ыкмасы", жана макаланын калган бөлүгүндө мен аны бирдейлик үчүн деп атайм.
Кадимки абалды билдирүүчү контейнердик ыкмада, бардык тиркеме бөлүктөрү бирдиктүү бөлүштүрүлгөн файл тутумуна тиркелет — бул колдонмонун бардык маалыматтары жайгашкан жалпы сактагычтын бир түрү. Кээ бир вариациялар мүмкүн болсо да, бул жогорку деңгээлдеги ыкма.
Эми келгиле, эмне үчүн мамлекеттик контейнер ыкмасы булут-борбордук дүйнөдө анти-үлгү экенин карап көрөлү.
Булуттагы тиркеме дизайны
Адаттагыдай, тиркемелер маалымат базаларын структуралаштырылган маалыматты жана локалдык дисктерди же бөлүштүрүлгөн файл тутумдарын колдонушкан, анда бардык структураланбаган же жарым структураланган маалыматтар ташталган. Структуризацияланбаган маалыматтардын көлөмү көбөйгөн сайын, иштеп чыгуучулар POSIX өтө эле сүйлөп жатканын, олуттуу чыгымдарды жана акыр аягында чындап чоң масштабга өтүүдө колдонмонун иштешине тоскоол болгонун түшүнүштү.
Бул, негизинен, маалыматты сактоонун жаңы стандартынын, башкача айтканда, булуттагы сактагычтын пайда болушуна өбөлгө түздү, ал биринчи кезекте REST API негизинде иштейт жана тиркемени жергиликтүү маалымат сактагычын түйшүктүү тейлөөдөн бошотту. Бул учурда, тиркеме эффективдүү түрдө жарандыгы жок режимге өтөт (анткени мамлекет алыстан сакталган). Заманбап тиркемелер ушул факторду эске алуу менен нөлдөн баштап курулган. Эреже катары, тигил же бул түрдөгү маалыматтарды (логдор, метаберилиштер, блобдор ж.б.) иштеткен ар кандай заманбап тиркеме булут-багытталган парадигмага ылайык курулат, мында мамлекет аны сактоо үчүн атайын арналган программалык камсыздоо тутумуна өткөрүлүп берилет.
Статистикалуу контейнер ыкмасы бул парадигманы так башталган жерине кайтарууга мажбурлайт!
Маалыматтарды сактоо үчүн POSIX интерфейстерин колдонуу менен, тиркемелер штаттык режимде иштегендей иштешет жана ушундан улам алар булут-борбордук дизайндын эң маанилүү жоболорунан, башкача айтканда, кирүүчүлөргө жараша колдонмо жумушчу жиптеринин өлчөмүн өзгөртүү мүмкүнчүлүгүнөн четтешет. киргизүү.жүктөө, учурдагы түйүн иштебей калганда жаңы түйүнгө өтүү ж.б.у.с.
Бул жагдайды кылдаттык менен карап чыгып, биз маалымат дүкөнүн тандап жатканда, биз кайра-кайра POSIX жана REST API дилеммасына туш болуп жатабыз, БИРОК Kubernetes чөйрөлөрүнүн бөлүштүрүлгөн мүнөзүнөн улам POSIX көйгөйлөрүнүн кошумча курчушу менен. Өзгөчө,
- POSIX сүйлөшүүчү: POSIX семантикасы ар бир операциянын операциянын абалын сактоого жардам берген метаберилиштер жана файл дескрипторлору менен байланыштырылышын талап кылат. Бул реалдуу наркы жок олуттуу чыгымдарга алып келет. Объекттерди сактоо API'лери, айрыкча S3 API, бул талаптардан арылуу менен, тиркеменин күйүп, андан кийин чалууну "унутуп" калышына мүмкүндүк берет. Сактоо тутумунун жообу иш-аракеттин ийгиликтүү же жокпу, көрсөтөт. Эгер ал ишке ашпай калса, колдонмо кайра аракет кыла алат.
- Тармактык чектөөлөр: Бөлүштүрүлгөн системада, ошол эле тиркелген медиага маалыматтарды жазууга аракет кылган көптөгөн тиркемелер болушу мүмкүн дегенди билдирет. Демек, тиркемелер маалымат өткөрүү жөндөмдүүлүгү үчүн (маалыматтарды ЖМКга жөнөтүү үчүн) бири-бири менен атаандашпайт, бирок сактоо тутумунун өзү физикалык дисктер аркылуу маалыматтарды жөнөтүү менен бул өткөрүү жөндөмдүүлүгү үчүн атаандашат. POSIXтин тилдүүлүгүнөн тармактык чалуулардын саны бир нече эсеге көбөйөт. Башка жагынан алганда, S3 API кардардан серверге келип чыккан жана сервердин ичинде болгон тармактык чалуулардын ортосундагы так айырманы камсыз кылат.
- коопсуздук: POSIX коопсуздук модели адамдын жигердүү катышуусу үчүн иштелип чыккан: администраторлор ар бир колдонуучу же топ үчүн белгилүү бир мүмкүнчүлүк деңгээлин конфигурациялайт. Бул парадигманы булут-борбордук дүйнөгө көнүү кыйын. Заманбап тиркемелер API негизиндеги коопсуздук моделдеринен көз каранды, мында кирүү укуктары саясаттардын жыйындысы катары аныкталат, кызмат эсептери, убактылуу эсептик дайындар ж.б. бөлүнөт.
- контролдо: Статистикалуу контейнерлерде кээ бир башкаруу чыгымдары бар. Кеп маалыматтарга параллелдүү жетүүнү синхрондоштуруу, маалыматтардын ырааттуулугун камсыз кылуу жөнүндө болуп жатат, мунун баары маалыматка жетүү моделдерин колдонууну кылдат карап чыгууну талап кылат. Кошумча программалык камсыздоону орнотуу, көзөмөлдөө жана конфигурациялоо, кошумча иштеп чыгуу аракеттерин айтпаганда да.
Контейнер маалыматтарын сактоо интерфейси
Container Storage Interface (CSI) Kubernetes көлөмдүү катмарынын көбөйүшүнө чоң жардам берип, аны жарым-жартылай үчүнчү тараптын сактагыч сатуучуларына аутсорсингге өткөрүп бергени менен, ал ошондой эле кокусунан түрдө контейнердик ыкманы колдонуу үчүн сунушталган ыкма деген ишенимге салым кошкон. Kubernetes маалыматтарды сактоо.
CSI Kubernetesте иштеп жатканда эски тиркемелерди ыктыярдуу блокторду жана файлдарды сактоо системаларын камсыздоо үчүн стандарт катары иштелип чыккан. Жана, бул макалада көрсөтүлгөндөй, мамлекеттик контейнердик мамиленин (жана анын учурдагы түрүндө CSI) мааниси бар жалгыз жагдай - бул тиркеменин өзү эски тутум болгондо, анда объект сактагыч API үчүн колдоо кошуу мүмкүн эмес. .
CSIди учурдагы формасында колдонуу, башкача айтканда, заманбап тиркемелер менен иштөөдө көлөмдөрдү жогорулатуу, биз POSIX стилинде маалыматтарды сактоо уюштурулган системаларда пайда болгон болжолдуу көйгөйлөргө туш болоорун түшүнүү керек.
Жакшыраак мамиле
Бул учурда, көпчүлүк тиркемелер мамлекеттик же жарандыгы жок иш үчүн атайын иштелип чыккан эмес экенин түшүнүү маанилүү. Бул жүрүм-турум системанын жалпы архитектурасына жана жасалган конкреттүү дизайн тандоосуна жараша болот. Келгиле, мамлекеттик колдонмолор жөнүндө бир аз сүйлөшөлү.
Негизи, бардык колдонмо маалыматтар бир нече кеңири түрлөргө бөлүнөт:
- Журнал маалыматтары
- Убакыт белгисинин дайындары
- Транзакция маалыматтары
- Метадайындар
- Контейнер сүрөттөрү
- Blob (экилик чоң объект) маалыматтары
Бул маалымат түрлөрүнүн баары заманбап сактоо аянтчаларында абдан жакшы колдоого алынат жана бул конкреттүү форматтардын ар биринде маалыматтарды жеткирүү үчүн ылайыкташтырылган бир нече булуттук платформалар бар. Мисалы, транзакция маалыматтары жана метаберилиштер CockroachDB, YugaByte ж.б. сыяктуу заманбап булуттук маалымат базасында болушу мүмкүн. Контейнер сүрөттөрү же блоб маалыматтары MiniIO негизиндеги докер реестринде сакталышы мүмкүн. Убакыт белгисинин маалыматтары InfluxDB сыяктуу убакыт сериясынын маалымат базасында сакталышы мүмкүн, ж.б. Биз бул жерде ар бир маалымат түрү жана анын тиркемелери жөнүндө майда-чүйдөсүнө чейин кирбейбиз, бирок жалпы идея локалдык дискти орнотууга таянган туруктуу маалыматтарды сактоодон качуу.
Кошумчалай кетсек, колдонмолор үчүн убактылуу файлдар сактагычы катары кызмат кылган убактылуу кэш катмарын камсыз кылуу көбүнчө эффективдүү, бирок тиркемелер чындыктын булагы катары бул катмардан көз каранды болбошу керек.
Колдонмонун штаттык сактагычы
Көпчүлүк учурларда тиркемелерди жарандыгы жок сактоо пайдалуу болгону менен, берилиштерди сактоо үчүн иштелип чыккан тиркемелер – маалымат базалары, объект дүкөндөрү, ачкыч-маанилердин дүкөндөрү – абалга ээ болушу керек. Келгиле, бул колдонмолор эмне үчүн Kubernetesте жайгаштырылып жатканын карап көрөлү. Мисал катары МинИОну алалы, бирок ушул сыяктуу принциптер башка чоң булуттагы сактагыч тутумуна да тиешелүү.
Булуттагы тиркемелер контейнерлерге мүнөздүү ийкемдүүлүктү толук пайдалануу үчүн иштелип чыккан. Бул алар жайылтыла турган чөйрө жөнүндө эч кандай божомолдорду жасашпайт дегенди билдирет. Мисалы, MiniIO системаны дисктердин жарымы иштебей калса дагы иштөө үчүн жетиштүү ийкемдүүлүк менен камсыз кылуу үчүн ички өчүрүү коддоо механизмин колдонот. MiniIO ошондой эле проприетардык сервердик хэшинг жана шифрлөө аркылуу берилиштердин бүтүндүгүн жана коопсуздугун башкарат.
Мындай булут-борбордук колдонмолор үчүн жергиликтүү туруктуу көлөмдөр (PV) резервдик сактоо катары эң ыңгайлуу. Жергиликтүү PV чийки маалыматтарды сактоо мүмкүнчүлүгүн камсыз кылат, ошол эле учурда бул PV үстүндө иштеген тиркемелер маалыматтарды масштабдоо жана өсүп жаткан маалымат талаптарын башкаруу үчүн маалыматты өз алдынча чогултат.
Бул ыкма CSI негизиндеги PVларга караганда алда канча жөнөкөй жана масштабдуураак, алар системага маалыматтарды башкаруунун жана ашыкча катмарларынын өз катмарларын киргизет; кеп бул катмарлар, адатта, абалды көрсөтүү үчүн иштелип чыккан колдонмолор менен карама-каршы келет.
Эсептөөлөрдөн маалыматтарды ажыратууга карай күчтүү кыймыл
Бул макалада биз тиркемелердин абалын сактабастан иштөөгө кантип багыт алганы же башкача айтканда, маалыматтарды сактоо аны эсептөөдөн ажыратылганы жөнүндө сүйлөштүк. Жыйынтыктап айтканда, бул тенденциянын кээ бир реалдуу мисалдарын карап көрөлү.
, көрүнүктүү маалыматтарды аналитика платформасы, адаттагыдай эле абалга ээ жана HDFSде жайгаштырылган. Бирок, Spark булут-борбордук дүйнөгө өткөн сайын, платформа `s3a` аркылуу жарандыгы жок колдонулууда. Spark абалды башка системаларга өткөрүү үчүн s3a колдонот, ал эми Spark контейнерлери толугу менен жарандыгы жок иштейт. Чоң маалыматтарды аналитика жаатындагы башка ири ишканалар, атап айтканда, , , Алар ошондой эле маалыматтарды сактоо жана алар боюнча эсептөөлөрдү бөлүү менен иштөөгө өтүп жатышат.
Окшош схемаларды башка ири аналитикалык платформалардан да көрүүгө болот, анын ичинде Presto, Tensorflow to R, Jupyter. Алыскы булут сактоо тутумдарына абалды түшүрүү менен, колдонмоңузду башкаруу жана масштабдоо бир топ жеңилдейт. Мындан тышкары, бул тиркеменин ар кандай чөйрөлөргө көчүрүлүшүн жеңилдетет.
Source: www.habr.com