Актуализация!. В коментарите един от читателите предложи да опитате (може би той сам работи върху това), така че добавих раздел за това решение. аз също писах защото процесът е много различен от останалите.
Честно казано, отказах се и се отказах (поне за сега). ще използвам . Защо? Заради съхранението! Кой би си помислил, че ще се забърквам повече със съхранението, отколкото със самия Kubernetes. използвам , защото е евтин и производителността е добра и от самото начало разположих клъстери с . Не съм пробвал управлявани от Kubernetes услуги от Google/Amazon/Microsoft/DigitalOcean и т.н., и т.н., защото исках сам да науча всичко. Освен това съм пестелив.
Така че - да, прекарах много време в опити да реша кое хранилище да избера, когато обмислях възможен стек на Kubernetes. Предпочитам решения с отворен код и то не само заради цената, но разгледах няколко платени варианта от любопитство, защото имат безплатни версии с ограничения. Записах няколко цифри от скорошни бенчмаркове, когато сравнявах различни опции, и те може да представляват интерес за тези, които изучават съхранение в Kubernetes. Въпреки че лично аз се сбогувах с Kubernetes досега. Също така искам да спомена , в който можете директно да предоставяте томове на Hetzner Cloud, но все още не съм го пробвал. Търсих облачно софтуерно дефинирано хранилище, защото имах нужда от репликация и възможност за бързо монтиране на постоянни томове на всеки възел, особено в случай на повреди на възел и други подобни ситуации. Някои решения предлагат моментни снимки и резервни копия извън сайта, което е удобно.
Тествах 6-7 решения за съхранение:
Както вече казах , след като тествах повечето опции от списъка, първоначално се спрях на OpenEBS. OpenEBS е много лесен за инсталиране и използване, но честно казано, след тестване с реални данни под натоварване, представянето му ме разочарова. Това е с отворен код и разработчиците са сами винаги много полезен, когато имах нужда от помощ. За съжаление, той има много лоша производителност в сравнение с други опции, така че трябваше да пусна тестовете отново. В момента OpenEBS има 3 механизма за съхранение, но публикувам сравнителни резултати за cStor. Все още нямам номера за Jiva и LocalPV.
Накратко, Jiva е малко по-бърза, а LocalPV като цяло е бърз, не по-лош от бенчмарка директно. Проблемът с LocalPV е, че томът може да бъде достъпен само на възела, където е предоставен, и изобщо няма репликация. Имах проблеми с възстановяването на резервно копие чрез на новия клъстер, защото имената на възлите бяха различни. Говорейки за резервни копия, cStor има , с който можете да правите резервни копия на моментни снимки извън сайта, което е по-удобно от архивирането на ниво файл с Velero-Restic. написах за да улесните управлението на архивиране и възстановяване с този плъгин. Като цяло наистина харесвам OpenEBS, но неговата производителност...
Rook също е с отворен код и се различава от останалите опции в списъка по това, че е оркестратор за съхранение, който изпълнява сложни задачи за управление на съхранение с различни бекендове, напр. , и други, което значително опростява работата. Имах проблеми с EfgeFS, когато го пробвах преди няколко месеца, така че тествах основно с Ceph. Ceph предлага не само блоково съхранение, но и обектно съхранение, съвместимо с S3/Swift и разпределена файлова система. Това, което харесвам в Ceph, е възможността за разпространение на обемни данни на множество дискове, така че томът да може да използва повече дисково пространство, отколкото може да се побере на един диск. Удобно е. Друга страхотна функция е, че когато добавите дискове към клъстера, той автоматично преразпределя данните между всички дискове.
Ceph има моментни снимки, но доколкото знам, те не могат да се използват директно в Rook/Kubernetes. Да си призная, не се задълбочих. Но няма резервни копия извън сайта, така че трябва да използвате нещо с Velero / Restic, но има само архиви на ниво файл, а не моментни снимки на момента. Това, което наистина харесвам в Rook обаче, е лекотата на работа с Ceph - той скрива почти всички сложни неща и предлага инструменти за директен разговор с Ceph за отстраняване на проблеми. За съжаление при стрес теста на обемите на Ceph винаги имах , което кара Ceph да стане нестабилен. Все още не е ясно дали това е грешка в самия Ceph или проблем в начина, по който Rook управлява Ceph. Поиграх си с настройките на паметта и стана по-добре, но проблемът не беше напълно разрешен. Ceph има добро представяне, както се вижда от бенчмарковете по-долу. Има и добро табло.
Много харесвам Longhorn. Мисля, че това е обещаващо решение. Вярно е, че самите разработчици (Rancher Labs) признават, че все още не е подходящ за производствена среда и това показва. Той е с отворен код и има прилична производителност (въпреки че все още не са го оптимизирали), но томовете отнемат много време, за да се прикачат към под, а в най-лошите случаи отнема 15-16 минути, особено след възстановяване на голям архив или надграждане на работното натоварване. Той има моментни снимки и резервни копия извън сайта на тези моментни снимки, но те се отнасят само за томове, така че все още имате нужда от нещо като Velero, за да архивирате останалите ресурси. Архивирането и възстановяването е много надеждно, но неприлично бавно. Сериозно, просто непосилно бавно. Използването на процесора и системното натоварване често се увеличават при работа със средно количество данни в Longhorn. Има удобно табло за управление на Longhorn. Вече казах, че харесвам Longhorn, но трябва да се работи правилно.
StorageOS е първият платен продукт в списъка. Има версия за разработчици с ограничен размер на управлявано хранилище от 500 GB, но не мисля, че има ограничение за броя на възлите. От отдела по продажбите ми казаха, че цената започва от $125 на месец за 1 TB, ако си спомням правилно. Има основно табло за управление и удобен CLI, но нещо странно се случва с производителността: в някои бенчмаркове тя е доста прилична, но при стрес теста на обемите скоростта изобщо не ми хареса. Като цяло не знам какво да кажа. Така че не разбрах наистина. Тук няма резервни копия извън сайта и ще трябва да използвате Velero с Restic за архивиране на томове. Странно, защото продуктът е платен. И разработчиците не бяха нетърпеливи да общуват в Slack.
Научих за Robin в Reddit от техния технически директор. Никога преди не бях чувал за него. Може би защото търсих безплатни решения, а Робин е платен. Те имат доста щедра безплатна версия с 10TB място за съхранение и три възела. Като цяло продуктът е доста приличен и с приятни характеристики. Има страхотен CLI, но най-готиното е, че можете да направите моментна снимка и архивиране на цялото приложение (наречено Helm издания или „flex apps“ в селектора на ресурси), включително томове и други ресурси, така че можете да правите без Velero. И всичко би било чудесно, ако не беше една малка подробност: ако възстановите (или "импортирате", както се нарича в Robin) приложение на нов клъстер - например, в случай на аварийно възстановяване - възстановяването, Разбира се, работи, но е забранено да продължите да архивирате приложението. В тази версия това просто не е възможно и разработчиците потвърдиха. Това е меко казано странно, особено когато имате предвид други предимства (например невероятно бързо архивиране и възстановяване). Разработчиците обещават да поправят всичко до следващото издание. Производителността като цяло е добра, но забелязах странно нещо: ако стартирате бенчмарка директно на том, прикрепен към хоста, скоростта на четене е много по-висока, отколкото в същия том, но от вътрешността на модула. Всички останали резултати са идентични, но на теория не би трябвало да има разлика. Въпреки че работят по него, бях разочарован от проблема с възстановяването и архивирането - струваше ми се, че най-накрая съм намерил подходящо решение и дори бях готов да платя за него, когато имах нужда от повече място или повече сървъри.
Тук нямам какво да кажа. Това е платен продукт, еднакво готин и скъп. Изпълнението е просто невероятно. Засега това е най-добрият показател. Slack ми каза, че цените започват от $205 на месец на възел, както е посочено в GKE Marketplace на Google. Не знам дали ще е по-евтино, ако купувате директно. Във всеки случай не мога да си го позволя, така че бях много, много разочарован, че лицензът за разработчици (до 1TB и 3 възела) е практически безполезен с Kubernetes, освен ако не сте доволни от статично предоставяне. Надявах се, че обемният лиценз автоматично ще премине към програмист в края на пробния период, но това не се случи. Лицензът за разработчици може да се използва само директно с Docker, а настройката в Kubernetes е много тромава и ограничена. Разбира се, предпочитам отворен код, но ако имах пари, определено бих избрал Portworx. Досега неговата производителност просто не може да се сравни с други опции.
Добавих този раздел след публикуването на публикацията, когато читател предложи да опитате Linstor. Пробвах го и ми хареса! Но все пак трябва да копаете. Сега мога да кажа, че представянето не е лошо (резултатите от бенчмарка са добавени по-долу). Всъщност получих същата производителност като за директното задвижване, без никакви допълнителни разходи. (Не питайте защо числата на Portworx са по-добри директно от бенчмарка на устройството. Нямам представа. Магия, предполагам.) Така че Linstor изглежда много ефективен досега. Инсталирането му не е толкова трудно, но не е толкова лесно, колкото другите опции. Първо трябваше да инсталирам Linstor (модул на ядрото и инструменти/услуги) и да настроя LVM за тънко осигуряване и поддръжка на моментни снимки извън Kubernetes, директно на хоста, и след това да създам ресурсите, необходими за използване на хранилище от Kubernetes. Не ми хареса, че не работи на CentOS и трябваше да използвам Ubuntu. Не е ужасно, разбира се, но малко досадно, защото документацията (която между другото е отлична) споменава няколко пакета, които не могат да бъдат намерени в посочените хранилища на Epel. Linstor има моментни снимки, но няма резервни копия извън сайта, така че тук отново трябваше да използвам Velero с Restic, за да архивирам томовете. Бих предпочел моментни снимки пред архивиране на ниво файл, но това може да се толерира, ако решението е едновременно ефективно и надеждно. Linstor е с отворен код, но има платена поддръжка. Ако разбирам правилно, може да се използва без ограничения, дори и да нямате договор за поддръжка, но това трябва да се изясни. Не знам как се тества Linstor за Kubernetes, но самият слой за съхранение е извън Kubernetes и очевидно решението не се е появило вчера, така че вероятно вече е тествано в реални условия. Има ли решение тук, което ще ме накара да променя решението си и да се върна към Kubernetes? Не знам. Все още трябва да копаем по-дълбоко, да изучаваме репликацията. Да видим. Но първото впечатление е добро. Определено бих предпочел да използвам собствените си клъстери Kubernetes вместо Heroku, за да имам повече свобода и да научавам нови неща. Тъй като Linstor не е толкова лесен за инсталиране като другите, скоро ще напиша публикация за него.
Бенчмаркове
За съжаление запазих малко записи на сравнението, защото не мислех, че ще пиша за него. Имам само резултати от сравнителния анализ на базовата линия на fio и само за клъстери с единичен възел, така че все още нямам числа за репликирани конфигурации. Но от тези резултати можете да получите груба представа какво да очаквате от всяка опция, защото ги сравних на едни и същи облачни сървъри, 4 ядра, 16 GB RAM, с допълнителен 100 GB диск за тестваните обеми. Пуснах бенчмарковете три пъти за всяко решение и изчислих средния резултат плюс нулиране на настройките на сървъра за всеки продукт. Всичко това е напълно ненаучно, само за да разберете най-общо. В други тестове копирах 38 GB снимки и видеоклипове от тома и за тестване на четене и писане, но, уви, не запазих числата. Накратко: 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 GB, за да преценя производителността и да не чакам много. Ето резултатите:
Маркирах най-добрата стойност за всеки показател в зелено и най-лошата в червено.
Заключение
Както можете да видите, в повечето случаи Portworx се представи по-добре от останалите. Но за мен е скъпо. Не знам колко струва Robin, но има страхотна безплатна версия, така че ако имате нужда от платен продукт, можете да го пробвате (надявам се скоро да оправят проблема с възстановяването и архивирането). От трите безплатни имах най-малко проблеми с OpenEBS, но производителността му е ужасна. Съжалявам, че не запазих повече резултати, но се надявам, че числата и моите коментари ще ви помогнат.
Източник: www.habr.com