Актуализация!. В коментарите един от читателите предложи да опитам (възможно е, че той сам работи над него), така че добавих раздел за това решение. Освен това написах , защото процесът се различава значително от другите.
Честно казано, се предадох и се отказах от (все пак засега). Ще използвам . Защо? Поради хранилищата! Кой би могъл да мисли, че ще се занимавам повече с хранилища, отколкото със самия Kubernetes. Използвам , защото е евтино и производителността е добра, и от самото начало разгръщах клъстери с помощта на . Не съм опитвал управлявани Kubernetes услуги от Google/Amazon/Microsoft/DigitalOcean и др. защото исках да се науча сам. Освен това съм пестелив.
Така че – да, прекарах много време, опитвайки се да реша кое хранилище да избера, когато разглеждах възможния стек за Kubernetes. Предпочитам решения с отворен код, не само заради цената, но и защото разгледах няколко платени варианта от любопитство, тъй като имат безплатни версии с ограничения. Записах няколко числа от последните тестове, когато сравнявах различни варианти, и те могат да заинтересуват тези, които изучават хранилищата в Kubernetes. Лично аз все още се разделих с Kubernetes. Искам също да спомена , в който може да се подготвят томове от Hetzner Cloud, но все още не съм го пробвал. Изучавал съм облачни софтуерно дефинирани хранилища, защото ми трябваше репликация и възможността бързо да свързвам постоянни томове на всяка нода, особено в случай на срив на нодите и други подобни ситуации. Някои решения предлагат снимки на момента и офлайн архиви, което е удобно.
Тествах 6–7 решения за хранилище:
Както вече казах , след като тествах повечето варианти от списъка, първоначално се спря на OpenEBS. OpenEBS е много лесен за инсталиране и използване, но, честно казано, след тестове с реални данни под натоварване производителността ме разочарова. Това е с отворен код и разработчиците в своя винаги много ми помагаха, когато имах нужда от помощ. За съжаление, производителността му е много ниска в сравнение с другите опции, затова трябваше да проведа тестовете отново. Сега OpenEBS има 3 двигателя за хранилище, но публикувам резултатите от бенчмарка за cStor. Все още нямам цифри за Jiva и LocalPV.
С две думи, Jiva е малко по-бърза, а LocalPV е изключително бърз, не по-лош от бенчмарка на диска директно. Проблемът с LocalPV е, че достъпът до него може да се получи само на нодата, където е бил подготвен, и не съществува репликация. Имах някои проблеми с възстановяването на бекапа чрез на новия кластер, защото имената на нодите се различаваха. Що се отнася до бекъпите, cStor разполага с , с който могат да се правят бекъпи на сnapshot-и към офсайт, което е по-удобно от бекъпи на файлово ниво с 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, но с производителността се случва нещо странно: в някои бенчмаркове е напълно прилична, но в стрес теста за томове скоростта изобщо не ми хареса. В общи линии, не знам какво да кажа. Затова не се задълбочавах особено. Тук няма офлайн резервни копия и ще се наложи да използвам Velero с Restic за резервни копия на томовете. Странно, нали? Все пак продуктът е платен. А и разработчиците не бяха особено желаещи да комуникират в Slack.
За Robin разбрах от тяхния технически директор в Reddit. Преди това не бях чувал за него. Може би защото търсех безплатни решения, а Robin е платено. Те предлагат доста щедра безплатна версия с хранилище от 10 ТБ и три ноди. Като цяло, продуктът е напълно достоен и с приятни функции. Имат отличен CLI, но най-якото е, че можете да направите моментална снимка и резервно копие на цялото приложение (в селектора на ресурсите това се нарича релизи на Helm или „flex apps“), включително томове и други ресурси, така че можете да се справите без Velero. И всичко щеше да е чудесно, ако не беше един малък детайл: при възстановяване (или „импортиране“, както го наричат в Robin) на приложение на нов клъстер - например, в случай на възстановяване след бедствие - възстановяването, разбира се, работи, но продължението на резервното копие на приложението е невъзможно. В текущия релиз това просто не е възможно, а разработчиците потвърдиха. Това, обичайно казано, е странно, особено като се имат предвид останалите предимства (например, невероятно бързи резервни копия и възстановявания). Разработчиците обещават да поправят всичко до следващия релиз. Производителността като цяло е добра, но забелязах странност: ако стартирате бенчмарк директно на том, свързан към хоста, скоростта на четене е много по-висока, отколкото в същия том, но от вътрешността на пода. Всички останали резултати са идентични, но теоретично не би трябвало да има разлика. Макар че работят по този въпрос, бях разочарован от проблема с възстановяването и резервното копие - помислих, че най-накрая открих подходящо решение и дори бях готов да плащам за него, когато ми е нужно повече пространство или повече сървъри.
Тук нямам много какво да кажа. Това е платен продукт, еднакво впечатляващ и ск expensive. Производителността е просто чудо. Досега това е най-добрият показател. В Slack ми казаха, че цената започва от 205 $ на месец за нода, както е посочено в GKE Marketplace на Google. Не знам дали ще бъде по-евтино, ако се купува директно. Във всеки случай, не мога да си позволя такова нещо, така че бях много и много разочарован, че лицензът за разработчици (до 1 ТБ и 3 ноди) е почти безполезен с Kubernetes, освен ако не се задоволявате със статична подготовка. Надявах се, че корпоративният лиценз автоматично ще бъде понижен до ниво на разработчик в края на пробния период, но това не случи. Лицензът за разработчици може да се използва само директно с Docker, а настройката в Kubernetes е много тромава и ограничена. Разбира се, предпочитам с отворен код, но ако имах пари, сигурно бих избрал Portworx. Досега производителността му просто не може да се сравнява с другите опции.
Добавих този раздел след публикуването на поста, когато един читател предложи да опитам Linstor. Опитах и ми хареса! Но трябва да проуча още. В момента мога да кажа, че производителността е добра (резултатите от теста за производителност добавих по-долу). В действителност получих същата производителност, както и при директен достъп до диска, напълно без загуби. (Не питайте защо Portworx има по-добри числа от теста на диска директно. Нямам представа. Магия, предполагам.) Така че в момента Linstor изглежда много ефективен. Инсталирането му не е точно сложно, но не е и толкова лесно, колкото останалите опции. Първо трябваше да инсталирам Linstor (модул на ядрото и инструменти/услуги) и да настроя LVM за thin provisioning и поддръжка на Snapshots извън Kubernetes, директно на хоста, а след това да създам ресурсите, необходими за използване на хранилището от Kubernetes. Не ми хареса, че не проработи на CentOS и трябваше да използвам Ubuntu. Не е ужасно, разбира се, но е малко дразнещо, защото в документацията (между другото, тя е отлична) се споменават няколко пакета, които не могат да бъдат намерени в посочените Epel репозитории. В Linstor има Snapshots, но няма оффсайт резервни копия, така че отново трябваше да използвам Velero с Restic за резервно копиране на томовете. Предпочитах Snapshots вместо резервни копия на ниво файлове, но това може да се преглътне, ако решението е производително и надеждно. 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
