Абнаўленне!. У каментах адзін з чытачоў прапанаваў паспрабаваць (магчыма, ён сам над ім працуе), так што я дадаў падзел аб гэтым рашэнні. Яшчэ я напісаў , таму што працэс моцна адрозніваецца ад астатніх.
Калі сапраўды, я здаўся і адмовіўся ад (ва ўсякім разе, пакуль). Буду выкарыстоўваць . Чаму? З-за захоўвання! Хто б мог падумаць, што я буду больш важдацца са сховішчамі, чым з самім Kubernetes. Я выкарыстоўваю , таму што гэта нядорага і прадукцыйнасць добрая, і з самага пачатку я разгортваў кластары з дапамогай . Я не спрабаваў кіраваныя сэрвісы Kubernetes ад Google/Amazon/Microsoft/DigitalOcean і інш., інш., таму што ўсяму жадаў навучыцца сам. А яшчэ я эканомны.
Так што - так, я выдаткаваў плойму часу, спрабуючы вырашыць, якое сховішча абраць, калі прыкідваў магчымы стэк на Kubernetes. Я аддаю перавагу рашэння з адкрытым зыходным кодам, і не толькі з-за цаны, але я вывучыў пару-тройку платных варыянтаў з цікаўнасці, таму што ў іх ёсць бясплатныя версіі з абмежаваннямі. Я запісаў некалькі лічбаў з апошніх тэстаў, калі параўноўваў розныя варыянты і яны могуць зацікавіць тых, хто вывучае захоўванне ў Kubernetes. Хаця асабіста я пакуль з Kubernetes развітаўся. Яшчэ хачу згадаць , у якім можна наўпрост падрыхтоўваць тамы Hetzner Cloud, але я яго пакуль не спрабаваў. Я вывучаў хмарныя праграмна-вызначаныя сховішчы, таму што мне патрэбна была рэплікацыя і магчымасць хутка падлучаць сталыя тамы на любой надзе, асабліва ў выпадку збою нод і іншых падобных сітуацый. Некаторыя рашэнні прапануюць снапшоты на момант часу і off site бэкапы, а гэта зручна.
Я пратэставаў 6-7 рашэнняў для захоўвання:
Як я ўжо казаў , пратэставаўшы большасць варыянтаў са спісу, я спачатку спыніўся на OpenEBS. OpenEBS вельмі проста ўсталёўваць і выкарыстоўваць, але, калі сапраўды, пасля тэстаў з рэальнымі дадзенымі пад нагрузкай яго прадукцыйнасць мяне расчаравала. Гэта апенсорс, і распрацоўшчыкі на сваім заўсёды вельмі дапамагалі, калі мне патрэбна была дапамога. Нажаль, у яго вельмі нізкая прадукцыйнасць у параўнанні з іншымі варыянтамі, таму прыйшлося правесці тэсты нанова. Цяпер у OpenEBS 3 рухавічка сховішчы, але я публікую вынікі бенчмарку для cStor. Пакуль у мяне няма лічб для Jiva і LocalPV.
У двух словах, Jiva крыху хутчэй, а LocalPV наогул хуткі, не горш, чым бенчмарк дыска напрамую. Праблема з LocalPV у тым, што доступ да таго можна атрымаць толькі на той нодзе, дзе ён быў падрыхтаваны, а рэплікацыі зусім не. У мяне былі некаторыя праблемы з аднаўленнем бэкапу праз на новым кластары, таму што імёны нод адрозніваліся. Калі казаць пра бэкапы, у cStor ёсць , З якім можна рабіць off site бэкапы снапшотаў на момант часу, што зручней, чым бэкапы на ўзроўні файлаў з Velero-Restic. Я напісаў , Каб было прасцей кіраваць бэкапамі і аднаўленнямі з гэтым убудовай. У цэлым мне вельмі падабаецца OpenEBS, але вось яго прадукцыйнасць…
У Rook таксама адчынены зыходны код, і ад астатніх варыянтаў у спісе ён адрозніваецца тым, што гэта аркестратар сховішчы, які выконвае складаныя задачы па кіраванні сховішчам з рознымі бэкендамі, напрыклад , і іншыя, што значна спрашчае працу. У мяне былі праблемы з EfgeFS, калі я спрабаваў яго некалькі месяцаў таму, так што тэсціраваў я, у асноўным, з Ceph. Ceph прапануе не толькі сховішча блокаў, але і сховішча аб'ектаў, сумяшчальнае з S3/Swift і размеркаванай файлавай сістэмай. Што мне падабаецца ў Ceph, дык гэта магчымасць распаўсюдзіць дадзеныя тамы па некалькіх дысках, каб тым мог выкарыстоўваць больш дыскавай прасторы, чым змяшчаецца на адным дыску. Гэта зручна. Яшчэ адна класная функцыя - калі дадаеш у кластар дыскі, ён аўтаматычна пераразмяркоўвае дадзеныя па ўсіх дысках.
У Ceph ёсць снапшоты, але, наколькі я ведаю, іх нельга наўпрост выкарыстоўваць у Rook/Kubernetes. Праўда, я ў гэта не паглыбляўся. А вось off site бэкапаў няма, так што давядзецца выкарыстоўваць што-небудзь з Velero/Restic, але там толькі бэкапы на ўзроўні файлаў, а не снапшоты на момант часу. Затое ў Rook мне вельмі спадабалася простая праца з Ceph - ён хавае амаль усе складаныя штукі і прапануе прылады, каб мець зносіны з Ceph напроста для ўхілення няспраўнасцяў. Нажаль, на стрэс-тэсце тамоў Ceph у мяне ўвесь час узнікала , з-за якой Ceph становіцца нестабільным. Пакуль незразумела, баг гэта ў самім Ceph ці праблема ў тым, як Rook кіруе Ceph. Я павядзьмарыў з наладамі памяці, і стала лепей, але да канца праблема не вырашылася. У Ceph нядрэнная прадукцыйнасць, як відаць у бенчмарках унізе. А яшчэ ў яго добрая панэль маніторынгу.
Мне вельмі падабаецца Longhorn. Па-мойму, гэтае перспектыўнае рашэнне. Праўда, самі распрацоўшчыкі (Rancher Labs) прызнаюць, што для працоўнага асяроддзя ён пакуль не падыходзіць, і гэта відаць. У яго адкрыты зыходны код і нядрэнная прадукцыйнасць (хоць яе аптымізацыяй яны яшчэ не займаліся), але тамы вельмі доўга падключаюцца да поду, і ў горшых выпадках гэта займае 15-16 хвілін, асабліва пасля аднаўлення вялікага бэкапу або апгрэйду працоўнай нагрузкі. У яго ёсць снапшоты і off site бэкапы гэтых снапшотаў, але яны распаўсюджваюцца толькі на тамы, таму вам усё роўна трэба будзе нешта тыпу Velero для бэкапу астатніх рэсурсаў. Бэкапы і аднаўленні вельмі надзейныя, але непрыстойна павольныя. Сур'ёзна, проста залішне павольныя. Выкарыстанне працэсарных рэсурсаў і загрузка сістэмы часта падскокваюць пры працы з сярэднім аб'ёмам дадзеных у Longhorn. Ёсць зручная панэль маніторынгу, каб кіраваць Longhorn. Я ўжо казаў, што мне падабаецца Longhorn, але над ім трэба як след папрацаваць.
StorageOS - гэта першы платны прадукт у спісе. У яго ёсць версія для распрацоўнікаў з абмежаваным памерам кіраванага сховішчы ў 500 ГБ, але колькасць вузлоў, па-мойму, не абмежавана. У аддзеле продажаў мне сказалі, што кошт пачынаецца ад $125 у месяц за 1 ТБ, калі я правільна запомніў. Тамака ёсць базавая панэль маніторынгу і зручны CLI, але з прадукцыйнасцю дзеецца нешта дзіўнае: у некаторых бенчмарках яна суцэль прыстойная, але ў стрэс-тэсце тамоў хуткасць мне зусім не спадабалася. Увогуле не ведаю, што і сказаць. Таму я асабліва не разбіраўся. Тут няма off site бэкапаў і давядзецца таксама выкарыстоўваць Velero з Restic для бэкапу тамоў. Дзіўна, бо прадукт-то платны. А яшчэ распрацоўшчыкі не гарэлі жаданнем мець зносіны ў Slack.
Аб Robin я даведаўся на Reddit ад іх тэхдырэктара. Раней я пра яго і не чуў. Можа, таму што шукаў бясплатныя рашэнні, а Robin платнае. У іх даволі шчодрая бясплатная версія са сховішчам на 10 ТБ і трыма нодамі. У цэлым, прадукт суцэль годны і з прыемнымі функцыямі. Там выдатны CLI, але самае крутое - гэта тое, што можна рабіць снапшот і бэкап усяго прыкладання (у селектары рэсурсаў гэта называецца рэлізамі Helm або "flex apps"), уключаючы тамы і іншыя рэсурсы, так што можна абысціся без Velero. І ўсё было б цудоўна, калі б не адна маленькая дэталь: калі аднаўляць (або «імпартаваць», як гэта называецца ў Robin) прыкладанне на новым кластары - напрыклад, у выпадку аднаўлення пасля аварыі - аднаўленне, вядома, працуе, але працягнуць бэкап прыкладання нельга. У гэтым рэлізе гэта проста немагчыма, і распрацоўшчыкі пацвердзілі. Гэта, мякка кажучы, дзіўна, асабліва калі ўлічыць астатнія перавагі (напрыклад, неверагодна хуткія бэкапы і аднаўленні). Распрацоўнікі абяцаюць усё выправіць да наступнага рэлізу. Прадукцыйнасць, у цэлым, добрая, але я заўважыў дзівацтва: калі запусціць бенчмарк напроста на томе, падлучаным да хаста, хуткасць чытання значна вышэй, чым у тым жа томе, але знутры пода. Усе астатнія вынікі ідэнтычныя, але ў тэорыі розніцы быць не павінна. Хоць яны над гэтым і працуюць, я знерваваўся з-за праблемы з аднаўленнем і бэкапам - мне здалося, што я нарэшце знайшоў прыдатнае рашэнне, і я нават гатовы быў плаціць за яго, калі мне спатрэбіцца больш прасторы або больш сервераў.
Тут мне асабліва няма чаго сказаць. Гэта платны прадукт, аднолькава класны і дарагі. Прадукцыйнасць проста цуд. Пакуль гэта найлепшы паказчык. У Slack мне сказалі, што кошт пачынаецца ад $205 у месяц за ноду, як паказана ў гуглаўскім GKE Marketplace. Не ведаю, ці будзе танней, калі набываць напрамую. У любым выпадку, я не магу сабе такое дазволіць, так што я быў вельмі і вельмі расчараваны, што ліцэнзія распрацоўніка (да 1 ТБ і 3 ноды) практычна бескарысная з Kubernetes, калі толькі вы не здавольваецеся статычнай падрыхтоўкай. Я спадзяваўся, што карпаратыўная ліцэнзія аўтаматычна панізіцца да ўзроўню распрацоўшчыка ў канцы выпрабавальнага перыяду, але не здарылася. Ліцэнзію распрацоўніка можна выкарыстоўваць толькі напроста з Docker, а налада ў Kubernetes вельмі грувасткая і абмежаваная. Я, вядома, аддаю перавагу апенсорсу, але будзь у мяне грошы, я б сапраўды абраў Portworx. Пакуль што яго прадукцыйнасць проста не параўнаецца з іншымі варыянтамі.
Я дадаў гэты раздзел ужо пасля публікацыі паста, калі адзін чытач прапанаваў паспрабаваць Linstor. Я паспрабаваў, і мне спадабалася! Але трэба яшчэ пакапацца. Цяпер магу сказаць, што прадукцыйнасць нядрэнная (вынікі бенчмарку дадаў ніжэй). Па сутнасці, я атрымаў тую ж прадукцыйнасць, што і для дыска напрамую, зусім без выдаткаў. (Не пытайце, чаму ў Portworx лічбы лепш, чым бенчмарк дыска напрамую. Паняцці не маю. Магія, мусіць.) Так што Linstor пакуль здаецца вельмі эфектыўным. Усталёўваць яго не тое што б складана, але не так лёгка, як астатнія варыянты. Спачатку мне прыйшлося ўсталяваць Linstor (модуль ядра і прылады/сэрвісы) і наладзіць LVM для thin provisioning і падтрымкі снапшотаў за межамі Kubernetes, напроста на хасце, а потым стварыць рэсурсы, неабходныя для выкарыстання сховішча з Kubernetes. Мне не спадабалася, што ён не зарабіў на CentOS і прыйшлося выкарыстоўваць Ubuntu. Не страшна, вядома, але трохі ятрыць, таму што ў дакументацыі (яна, дарэчы, выдатная) згадваецца некалькі пакетаў, якія немагчыма знайсці ў паказаных рэпазітарах Epel. У Linstor ёсць снапшоты, але не off site бэкапы, так што тут зноў прыйшлося выкарыстоўваць Velero з Restic для бэкапу тамоў. Я б аддаў перавагу снапшоты замест бэкапаў на ўзроўні файлаў, але гэта можна стрываць, калі рашэнне будзе прадукцыйным і надзейным. У Linstor адчынены зыходны код, але ёсць платная падтрымка. Калі я правільна разумею, яго можна выкарыстоўваць без абмежаванняў, нават калі ў вас няма дамовы на падтрымку, але гэта трэба ўдакладніць. Я не ведаю, наколькі Linstor правераны для Kubernetes, але сам узровень захоўвання знаходзіцца за межамі Kubernetes і, судзячы па ўсім, рашэнне з'явілася не ўчора, так што, мусіць, ужо праверана ў рэальных умовах. Ці ёсць тут рашэнне, якое прымусіць мяне перадумаць і вярнуцца да Kubernetes? Не ведаю, не ведаю. Трэба яшчэ пакалупацца, вывучыць рэплікацыю. Пабачым. Але першае ўражанне добрае. Я зусім дакладна хацеў бы выкарыстоўваць свае ўласныя кластары Kubernetes замест Heroku, каб атрымаць больш свабоды і навучыцца новаму. Раз Linstor усталёўваецца не так проста, як іншыя, хутка я напішу пра гэта пост.
Арыенціры
На жаль, я захаваў мала запісаў аб параўнанні, бо не падумаў, што буду пра гэта пісаць. У мяне ёсць толькі вынікі базавых бенчмаркаў fio і толькі для кластараў з адным вузлом, так што для рэплікаваных канфігурацый у мяне пакуль няма лічбаў. Але па гэтых выніках можна атрымаць прыкладнае ўяўленне аб тым, чаго чакаць ад кожнага варыянту, таму што я параўноўваў іх на аднолькавых хмарных серверах, 4 ядры, 16 ГБ аператыўкі, з дадатковым дыскам на 100 ГБ для тэстоўваных тамоў. Я прагнаў бенчмаркі тройчы для кожнага рашэння і вылічыў сярэдні вынік, плюс скідаў налады сервера для кожнага прадукта. Усё гэта зусім не навукова, проста каб вы зразумелі ў агульных рысах. У іншых тэстах я капіраваў 38 ГБ фота і відэа з тома і на тым, каб пацясціць чытанне і запіс, але лічбы, нажаль, не захаваў. Калі сцісла: Portworkx быў значна хутчэй.
Для бенчмарка тамоў я выкарыстоўваў гэты маніфест:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: dbench
spec:
storageClassName: ...
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
name: dbench
spec:
template:
spec:
containers:
- name: dbench
image: sotoaster/dbench:latest
imagePullPolicy: IfNotPresent
env:
- name: DBENCH_MOUNTPOINT
value: /data
- name: FIO_SIZE
value: 1G
volumeMounts:
- name: dbench-pv
mountPath: /data
restartPolicy: Never
volumes:
- name: dbench-pv
persistentVolumeClaim:
claimName: dbench
backoffLimit: 4Спачатку я стварыў том з які адпавядае класам сховішчы, а потым запусціў заданне з fio за кадрам. Я ўзяў 1 ГБ, каб прыкінуць прадукцыйнасць і не чакаць занадта доўга. Вось вынікі:
Я вылучыў лепшае значэнне для кожнага паказчыка зялёным, а горшае - чырвоным.
Заключэнне
Як бачыце, у большасці выпадкаў Portworx паказаў сябе лепш за іншых. Але для мяне ён дарагі. Я не ведаю, колькі каштуе Robin, але там выдатная бясплатная версія, так што, калі вам патрэбен платны прадукт, можаце паспрабаваць (спадзяюся, яны хутка выправяць праблему з аднаўленнем і бэкапамі). З трох бясплатных у мяне менш за ўсё праблем узнікла з OpenEBS, але прадукцыйнасць у яго ні да д'ябла. Шкада, я не захаваў больш вынікаў, але, спадзяюся, вам дапамогуць прыведзеныя лічбы і мае каментарыі.
Крыніца: habr.com