Ажурирање!. Во коментарите, еден од читателите предложи да се обиде (можеби тој самиот работи на тоа) па додадов дел за ова решение. И јас напишав , бидејќи процесот е многу различен од останатите.
Да бидам искрен, се откажав и се откажав (барем засега). ќе користам . Зошто? Поради складирање! Кој би помислил дека повеќе ќе се занимавам со складирањето отколку со самиот Кубернет. јас користам бидејќи е ефтин и перформансите се добри и од самиот почеток распоредив кластери користејќи . Не пробав управувани Kubernetes услуги од Google/Amazon/Microsoft/DigitalOcean, итн., итн., бидејќи сакав да научам сè сам. И јас сум штедлив.
Така да, потрошив многу време обидувајќи се да одлучам кое складирање да го изберам кога проценував можен куп на 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. Ги чепкав поставките за меморијата и се подобри, но проблемот не беше целосно решен. Ceph има пристојни перформанси, како што можете да видите во бенчмарковите подолу. Има и добра контролна табла.
Навистина ми се допаѓа Longhorn. Според мене, ова е ветувачко решение. Точно, самите програмери (Rancher Labs) признаваат дека сè уште не е погодно за работната средина, и тоа покажува. Тој е со отворен код и има пристојни перформанси (иако сè уште не го оптимизирале), но волумените трае многу долго за да се поврзат со подлогата, а во најлошите случаи потребни се 15-16 минути, особено по враќање на голема резервна копија или надградба на обемот на работа. Има снимки и резервни копии надвор од локацијата на овие снимки, но тие се однесуваат само на томови, така што сепак ќе ви треба нешто како Velero за да направите резервна копија на други ресурси. Резервните копии и обновувањата се многу сигурни, но непристојно бавни. Сериозно, само неверојатно бавно. Користењето на процесорот и оптоварувањето на системот често се зголемуваат кога работите со средна количина на податоци во Longhorn. Има удобна контролна табла за управување со Longhorn. Веќе реков дека ми се допаѓа Longhorn, но треба малку работа.
StorageOS е првиот платен производ на листата. Има програмерска верзија со ограничена управувана големина на складирање од 500 GB, но мислам дека нема ограничување на бројот на јазли. Одделот за продажба ми кажа дека цената започнува од 125 долари месечно за 1 ТБ, ако добро се сеќавам. Има основна контролна табла и удобен CLI, но нешто чудно се случува со перформансите: во некои одредници е сосема пристојно, но во стрес тестот за јачина на звук воопшто не ми се допадна брзината. Во принцип, не знам што да кажам. Така што навистина не разбрав многу. Овде нема резервни копии надвор од локацијата, а исто така ќе мора да го користите Velero со Restic за да направите резервни томови. Чудно е, бидејќи производот се плаќа. И програмерите не беа желни да комуницираат на Slack.
Дознав за Робин на Редит од нивниот технички директор. Никогаш порано не сум слушнал за него. Можеби затоа што барав бесплатни решенија, но Робин е платен. Тие имаат прилично дарежлива бесплатна верзија со 10 TB простор за складирање и три јазли. Генерално, производот е прилично пристоен и има убави карактеристики. Има одличен CLI, но најкул работа е што можете да снимите и да направите резервна копија на целата апликација (во избирачот на ресурси ова се нарекува Helm releases или „flex apps“), вклучувајќи волумени и други ресурси, за да можете без Velero. И сè би било прекрасно ако не за еден мал детал: ако вратите (или „увезете“, како што се нарекува во Робин) апликација на нов кластер - на пример, во случај на закрепнување од катастрофа - реставрација, се разбира, работи, но продолжете да правите резервна копија на апликацијата што е забрането. Ова едноставно не е можно во ова издание, како што потврдија програмерите. Ова е, благо кажано, чудно, особено ако се земат предвид другите предности (на пример, неверојатно брзите бекап и обновувања). Програмерите ветуваат дека ќе поправат сè до следното издание. Перформансите се генерално добри, но забележав чудност: ако реперот го активирам директно на јачината на звукот прикачен на домаќинот, брзината на читање е многу поголема отколку испуштањето на истата јачина од внатре во подлогата. Сите други резултати се идентични, но теоретски не би требало да има разлика. Иако работат на тоа, јас бев вознемирен поради проблемот со реставрација и резервна копија - мислев дека конечно најдов соодветно решение, па дури бев подготвен да платам за тоа кога ми требаше повеќе простор или повеќе сервери.
Немам многу да кажам овде. Ова е платен производ, подеднакво кул и скап. Изведбата е едноставно неверојатна. Ова е најдобриот показател досега. Slack ми кажа дека цената започнува од 205 долари месечно по јазол, како што е наведено во GKE Marketplace на Google. Не знам дали ќе биде поефтино ако купуваш директно. Во секој случај не можам да си го дозволам тоа, па бев многу, многу разочаран што лиценцата за програмери (до 1 ТБ и 3 јазли) е практично бескорисна со Кубернет, освен ако не сте задоволни со статичко обезбедување. Се надевав дека лиценцата за волумен автоматски ќе се деградира на програмер на крајот од пробниот период, но тоа не се случи. Лиценцата за развивач може да се користи директно само со Docker, а конфигурацијата во Kubernetes е многу гломазна и ограничена. Секако, преферирам отворен код, но да имам пари, дефинитивно би го избрал Portworx. Досега, неговите перформанси едноставно не се споредуваат со другите опции.
Го додадов овој дел по објавувањето на објавата, кога еден читател предложи да го пробате Linstor. Го пробав и ми се допадна! Но, сепак треба да копаме подлабоко. Сега можам да кажам дека перформансите не се лоши (подолу ги додадов бенчмарк резултатите). Во суштина, ги добив истите перформанси како и дискот директно, без никакви трошоци. (Не прашувајте зошто Portworx има подобри бројки од директен репер за погонот. Немам поим. Магија, претпоставувам.) Значи, Линстор досега изгледа многу ефикасен. Не е толку тешко да се инсталира, но не е толку лесно како другите опции. Прво морав да инсталирам Linstor (модул на кернелот и алатки/услуги) и да го конфигурирам LVM за тенко обезбедување и поддршка за снимки надвор од Kubernetes, директно на домаќинот, а потоа да ги создадам ресурсите потребни за користење складирање од Kubernetes. Не ми се допадна што не работи на CentOS и морав да користам Ubuntu. Не е страшно, се разбира, но малку досадно, бидејќи во документацијата (која е одлична, патем) се споменуваат неколку пакети кои не можат да се најдат во наведените складишта на Epel. Linstor има снимки, но не и резервни копии надвор од локацијата, така што повторно морав да користам Velero со Restic за резервна копија на волумени. Би сакал снимки наместо резервни копии на ниво на датотека, но ова може да се толерира ако решението е успешно и сигурно. Linstor е со отворен код, но има платена поддршка. Ако добро разбирам, може да се користи без ограничувања, дури и ако немате договор за поддршка, но ова треба да се разјасни. Не знам колку е тестиран Linstor за Kubernetes, но самиот слој за складирање е надвор од Kubernetes и, очигледно, решението не се појави вчера, па веројатно веќе е тестирано во реални услови. Има ли тука решение кое ќе ме натера да се предомислам и да се вратам во Кубернетес? Не знам. Сè уште треба да копаме подлабоко и да ја проучуваме репликацијата. Ајде да видиме. Но, првиот впечаток е добар. Дефинитивно би сакал да ги користам сопствените кластери Кубернетес наместо Хероку за да имам поголема слобода и да научам нови работи. Бидејќи Linstor не е лесно да се инсталира како другите, наскоро ќе напишам објава за тоа.
Репери
За жал, не чував многу белешки за споредбата бидејќи не мислев дека ќе пишувам за тоа. Имам резултати само од основните фио репери и само за кластери со единечни јазли, така што сè уште немам бројки за реплицирани конфигурации. Но, од овие резултати можете да добиете груба идеја за тоа што да очекувате од секоја опција, бидејќи ги споредив на истите облак сервери, 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Прво создадов том со соодветната класа за складирање, а потоа ја извршив работата со фио зад сцената. Зедов 1 GB за да ги проценам перформансите и да не чекам премногу. Еве ги резултатите:
Ја истакнав најдобрата вредност за секоја метрика со зелена, а најлошата со црвено.
Заклучок
Како што можете да видите, во повеќето случаи Portworx се претстави подобро од другите. Но, за мене тоа е скапо. Не знам колку чини Робин, но имаат одлична бесплатна верзија, па ако сакаш платен производ, можеш да го пробаш (се надеваме дека наскоро ќе го средат проблемот со рестор и бекап). Од трите бесплатни имав најмалку проблеми со OpenEBS, но неговата изведба е бездна. Штета што не зачував повеќе резултати, но се надевам дека бројките и моите коментари ќе ви помогнат.
Извор: www.habr.com