Ажурирање!. Во коментарите, еден од читателите предложи да се обиде (можеби тој самиот работи на тоа) па додадов дел за ова решение. И јас напишав , бидејќи процесот е многу различен од останатите.
Да бидам искрен, се откажав и се откажав (барем засега). ќе користам . Зошто? Поради складирање! Кој би помислил дека повеќе ќе се занимавам со складирањето отколку со самиот Кубернет. јас користам бидејќи е ефтин и перформансите се добри и од самиот почеток распоредив кластери користејќи . Не пробав управувани 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 изгледа многу ефикасен досега. Неговото поставување не е баш тешко, но не е ни толку лесно како другите опции. Прво, морав да инсталирам Linstor (модул на јадрото и алатки/услуги) и да поставам LVM за тенка провизија и поддршка за снимки надвор од Kubernetes, директно на хостот, а потоа да ги создадам потребните ресурси за користење на складирањето од Kubernetes. Не бев задоволен што не работеше на CentOS и мораше да користи UbuntuСекако, не е голема работа, но е малку досадно бидејќи документацијата (која е одлична, патем) споменува неколку пакети кои не се достапни во наведените репозиториуми на Epel. Linstor има снимки, но нема резервни копии надвор од локацијата, па затоа морав повторно да го користам Velero со Restic за резервни копии на волумени. Би претпочитал снимки од снимки пред резервни копии на ниво на датотека, но тоа е подносливо ако решението е перформативно и сигурно. Linstor е со отворен код, но има платена поддршка. Ако добро разбирам, можете да го користите без ограничувања дури и ако немате договор за поддршка, но би морал да го проверам тоа. Не знам колку е тестиран Linstor за Kubernetes, но самиот слој за складирање е надвор од Kubernetes и изгледа како да постои веќе некое време, па веројатно веќе е тестиран во услови на реалниот свет. Дали има решение овде што би ме натерало да се предомислам и да се вратам на Kubernetes? Не знам. Треба малку повеќе да истражувам и да научам за репликација. Ќе видиме. Но, првиот впечаток е добар. Дефинитивно би претпочитал да ги користам моите сопствени кластери на Кубернетес наместо Хероку за поголема слобода и да учам нови работи. Бидејќи Линстор не е толку лесен за инсталирање како другите, наскоро ќе напишам пост за тоа.
Репери
За жал, не чував многу белешки за споредбата бидејќи не мислев дека ќе пишувам за тоа. Имам резултати само од основните фио репери и само за кластери со единечни јазли, така што сè уште немам бројки за реплицирани конфигурации. Но, од овие резултати можете да добиете груба идеја за тоа што да очекувате од секоја опција, бидејќи ги споредив на истите облак сервери, 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
