Актуализация!. В коментарите един от читателите предложи да опитам (възможно е, той самият да работи върху него), затова добавих раздел за това решение. Освен това написах , защото процесът се различава значително от другите.
Честно казано, се отказах и спрях от (поне за сега). Ще използвам . Защо? Защото става въпрос за хранилище! Кой би предположил, че ще се занимавам повече с хранилищата, отколкото със самия 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 има , с който се правят офлайн резервни копия на моментни снимки, което е по-удобно от резервирането на ниво файлове с Velero-Restic. Написах , за да улесня управлението на резервните копия и възстановяванията с този плъгин. Като цяло, много ми харесва OpenEBS, но производителността му...
Rook също е с отворен код и се различава от другите варианти в списъка по това, че е оркестратор на хранилище, който извършва сложни задачи по управление на хранилището с различни бекенди, например , и други, което значително улеснява работата. Имах проблеми с EdgeFS, когато го пробвах преди няколко месеца, така че тестовете ми бяха основно с 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, но най-хубавото е, че можете да направите snapshot и backup на цялото приложение (в селектора на ресурсите се нарича releases на Helm или „flex apps“), включително томове и други ресурси, така че можете да се минете без Velero. Всичко щеше да е чудесно, ако не беше един малък детайл: ако възстановявате (или „импортирате“, както се нарича в Robin) приложението в нов клъстер — например, в случай на възстановяване след авария — възстановяването, разбира се, работи, но продължението на backup на приложението не е възможно. В това издание това просто не е възможно, а разработчиците го потвърдиха. Това, меко казано, е странно, особено като се вземат предвид останалите предимства (например, невероятно бързи backup и възстановявания). Разработчиците обещават да поправят всичко в следващото издание. Производителността, като цяло, е добра, но забелязах странност: ако стартирате бенчмарк директно на том, свързан към хоста, скоростта на четене е много по-висока, отколкото в същия том, но от вътре на пода. Всички останали резултати са идентични, но в теория не би трябвало да има разлика. Въпреки че работят по това, бях разочарован от проблема с възстановяването и backup-а — мислех, че най-накрая намерих подходящо решение и даже бях готов да платя за него, когато ми трябваше повече пространство или повече сървъри.
Тук нямам много да кажа. Това е платен продукт, еднакво страхотен и скъп. Производителността е просто чудо. Досега това е най-доброто представяне. В Slack ми казаха, че цената започва от $205 на месец за нода, както е посочено в Google GKE Marketplace. Не знам дали ще е по-евтино, ако се закупи директно. Във всеки случай, не мога да си го позволя, така че бях много и много разочарован, че лицензът за разработчици (до 1 ТБ и 3 ноди) е практически безполезен с Kubernetes, освен ако не се задоволявате с статично подготвяне. Надявах се, че корпоративният лиценз автоматично ще бъде понижен до ниво на разработчик в края на пробния период, но не стана. Лицензът за разработчици може да се използва само директно с Docker, а настройката в Kubernetes е много неудобна и ограничена. Разбира се, предпочитам отворен код, но ако имах парите, определено бих избрал Portworx. Досега производителността му просто не може да се_compare с другите варианти.
Добавих този раздел след публикуването на публикацията, когато един читател предложи да опитам Linstor. Изпробвах го и ми хареса! Но трябва да се задълбоча още. В момента мога да кажа, че производителността е добра (резултатите от бенчмарка съм добавил по-долу). По същество, получих същата производителност, каквато имах и при директно свързания диск, без никакви загуби. (Не питайте защо цифрите на Portworx са по-добри от бенчмарка на диска директно. Нямам представа. Може би магия.) Така че Linstor изглежда много ефективен засега. Инсталирането му не е трудоемко, но не е и толкова лесно, колкото другите варианти. Първо се наложи да инсталирам Linstor (ядрен модул и инструменти/услуги) и да настроя LVM за тънко разпределение и поддръжка на снимки извън Kubernetes, директно на хоста, а след това да създам ресурсите, необходими за използване на хранилището от Kubernetes. Не ми хареса, че не проработи на CentOS и се наложи да използвам Ubuntu. Не е страшно, разбира се, но е малко дразнещо, защото в документацията (която, между другото, е страхотна) се споменават няколко пакета, които не могат да бъдат намерени в указаните репозитории Epel. В Linstor има снимки, но няма off site резервни копия, така че отново се наложи да ползвам Velero с Restic за архивиране на томовете. Бих предпочел снимки вместо архиви на ниво файлове, но това е абсолютно приемливо, ако решението е производително и надеждно. Linstor има отворен код, но предлага платена поддръжка. Ако разбирам правилно, може да се използва без ограничения, дори ако нямате договор за поддръжка, но това трябва да се уточни. Не знам колко е проверен Linstor за Kubernetes, но самото хранилище е извън Kubernetes и, изглежда, решението не е ново, така че вероятно вече е тествано в реални условия. Има ли решение, което да ме накара да се променя и да се върна към Kubernetes? Не знам, не знам. Трябва да се работи още, да се проучи репликацията. Ще видим. Но първото впечатление е добро. Определено бих предпочел да използвам собствените си Kubernetes клъстери, вместо Heroku, за да получа повече свобода и да науча нещо ново. Тъй като инсталирането на Linstor не е толкова просто, колкото другите, скоро ще напиша публикация за това.
Бенчмаркове
За съжаление, съхраних малко записи за сравнение, защото не помислих, че ще пиша за това. Имам само резултати от основни бенчмаркове fio, и само за клъстери с един възел, така че за реплицирани конфигурации все още нямам цифри. Но от тези резултати може да се получи примерна представа за това, какво да очаквате от всеки вариант, защото ги сравнявах на одинакови облачни сървъри, 4 ядра, 16 ГБ оперативна памет, с допълнителен диск от 100 ГБ за тестваните томове. Проведох бенчмаркове три пъти за всяко решение и изчислих средния резултат, плюс нулирах настройките на сървъра за всеки продукт. Всичко това е абсолютно не научно, просто за да разберете общо. В другите тестове копирах 38 ГБ снимки и видео от тома и на тома, за да тествам четенето и записването, но цифрите, за съжаление, не запазих. Накратко: Portworx беше значително по-бърз.
За бенчмарка на томовете използвах този манифест:
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
