Ažuriraj!. U komentarima je jedan od čitatelja predložio da probate (možda on sam radi na tome), pa sam dodao dio o tom rješenju. I ja sam pisao jer se proces veoma razlikuje od ostalih.
Da budem iskren, odustao sam i odustao (barem za sada). Ja ću koristiti . Zašto? Zbog skladištenja! Ko bi rekao da ću se više petljati sa skladištem nego sa samim Kubernetesom. ja koristim , jer je jeftin, a performanse su dobre, a od samog početka sam postavljao klastere sa . Nisam probao Kubernetes upravljane usluge od Google/Amazon/Microsoft/DigitalOcean itd., itd., jer sam htio sve sam naučiti. Takođe sam štedljiv.
Dakle - da, proveo sam dosta vremena pokušavajući da odlučim koje skladište da izaberem kada sam razmišljao o mogućem steku na Kubernetesu. Više volim open source rješenja, i to ne samo zbog cijene, već sam pogledao par plaćenih opcija iz radoznalosti, jer imaju besplatne verzije sa ograničenjima. Zabilježio sam nekoliko brojeva iz nedavnih mjerila kada sam upoređivao različite opcije, a one bi mogle biti zanimljive onima koji proučavaju skladištenje u Kubernetesu. Iako sam se lično do sada oprostio od Kubernetesa. Takođe želim da napomenem , u kojem možete direktno obezbijediti Hetzner Cloud volumene, ali to još nisam isprobao. Tražio sam softverski definiranu pohranu u oblaku jer mi je bila potrebna replikacija i mogućnost brzog montiranja trajnih volumena na bilo koji čvor, posebno u slučaju kvarova čvora i drugih sličnih situacija. Neka rješenja nude trenutne snimke i sigurnosne kopije izvan lokacije, što je zgodno.
Testirao sam 6-7 rješenja za pohranu:
Kao što sam već rekao , nakon što sam testirao većinu opcija sa liste, u početku sam se odlučio na OpenEBS. OpenEBS je vrlo jednostavan za instaliranje i korištenje, ali da budem iskren, nakon testiranja sa stvarnim podacima pod opterećenjem, njegove performanse su me razočarale. Ovo je open source, a programeri su sami uvijek od velike pomoći kada mi je potrebna pomoć. Nažalost, ima veoma loše performanse u poređenju sa drugim opcijama, pa sam morao ponovo da izvršim testove. Trenutno OpenEBS ima 3 pogona za skladištenje, ali ja objavljujem benchmark rezultate za cStor. Još nemam brojeve za Jivu i LocalPV.
Ukratko, Jiva je nešto brža, a LocalPV je generalno brz, ništa lošiji od direktnog benčmarka. Problem sa LocalPV-om je taj što se volumenu može pristupiti samo na čvoru na kojem je dodijeljen, a replikacija uopće nema. Imao sam problema sa vraćanjem rezervne kopije putem na novom klasteru jer su imena čvorova bila drugačija. Kad smo kod rezervnih kopija, cStor ima , sa kojim možete napraviti rezervne kopije snimka u trenutku van lokacije, što je praktičnije od pravljenja rezervnih kopija na nivou datoteke sa Velero-Restic-om. napisao sam kako biste olakšali upravljanje sigurnosnom kopijom i vraćanjem pomoću ovog dodatka. Sve u svemu, zaista mi se sviđa OpenEBS, ali njegove performanse...
Rook je također otvorenog koda i razlikuje se od ostalih opcija na listi po tome što je orkestrator pohrane koji obavlja složene zadatke upravljanja pohranom s različitim pozadinama, na primjer , i drugi, što uvelike pojednostavljuje rad. Imao sam problema sa EfgeFS-om kada sam ga isprobao prije nekoliko mjeseci, pa sam testirao uglavnom sa Ceph-om. Ceph nudi ne samo blok memoriju, već i skladištenje objekata kompatibilno sa S3/Swift i distribuiranim sistemom datoteka. Ono što mi se sviđa kod Ceph-a je mogućnost širenja podataka o volumenu na više diskova tako da volumen može koristiti više prostora na disku nego što može stati na jedan disk. To je udobno. Još jedna dobra karakteristika je da kada dodate diskove u klaster, on automatski redistribuira podatke na sve diskove.
Ceph ima snimke, ali koliko ja znam ne mogu se koristiti direktno u Rook/Kubernetes. Doduše, nisam se upuštao u to. Ali nema rezervnih kopija van lokacije, tako da morate koristiti nešto sa Velero / Restic-om, ali postoje samo rezervne kopije na nivou fajla, ne i trenutni snimci. Međutim, ono što mi se zaista sviđa kod Rooka je lakoća rada sa Cephom - on skriva gotovo sve složene stvari i nudi alate za direktan razgovor sa Cephom radi rješavanja problema. Nažalost, na stres testu Ceph volumena, uvijek sam imao , što uzrokuje da Ceph postane nestabilan. Još nije jasno da li je ovo greška u samom Ceph-u ili problem u tome kako Rook upravlja Ceph-om. Petljao sam s postavkama memorije, i bilo je bolje, ali problem nije u potpunosti riješen. Ceph ima dobre performanse kao što se vidi u referentnim vrijednostima ispod. Takođe ima dobru kontrolnu tablu.
Zaista mi se sviđa Longhorn. Mislim da je ovo rješenje koje obećava. Istina, sami programeri (Rancher Labs) priznaju da još nije prikladan za proizvodno okruženje, i to pokazuje. Otvoren je kod i ima pristojne performanse (iako ga još nisu optimizirali), ali volumenima je potrebno jako dugo da se prikače na pod, au najgorim slučajevima potrebno je 15-16 minuta, posebno nakon vraćanja velike rezervne kopije ili nadogradnja radnog opterećenja. Ima snimke i rezervne kopije tih snimaka van lokacije, ali oni se primjenjuju samo na volumene, tako da vam je i dalje potrebno nešto poput Velero-a da napravite sigurnosnu kopiju ostatka resursa. Sigurnosne kopije i vraćanja su vrlo pouzdani, ali nepristojno spori. Ozbiljno, samo nedovoljno sporo. Upotreba CPU-a i opterećenje sistema često rastu kada radite sa prosječnom količinom podataka u Longhornu. Postoji zgodna kontrolna tabla za upravljanje Longhornom. Već sam rekao da mi se Longhorn sviđa, ali na njemu treba dobro poraditi.
StorageOS je prvi plaćeni proizvod na listi. Ima verziju za programere sa ograničenom veličinom upravljanog prostora za skladištenje od 500 GB, ali mislim da nema ograničenja u broju čvorova. Odeljenje prodaje mi je reklo da cena počinje od 125 dolara mesečno za 1 TB, ako se dobro sećam. Postoji osnovna kontrolna tabla i zgodan CLI, ali nešto se čudno dešava sa performansama: u nekim benchmarkovima su sasvim pristojne, ali u stres testu zapremine, brzina mi se uopšte nije dopala. Generalno, ne znam šta da kažem. Tako da nisam baš razumeo. Ovdje nema rezervnih kopija van lokacije i također ćete morati koristiti Velero sa Restic-om za pravljenje rezervnih kopija volumena. Čudno, jer se proizvod plaća. A programeri nisu bili željni komuniciranja u Slacku.
O Robinu sam saznao na Redditu od njihovog tehničkog direktora. Nikada ranije nisam čuo za njega. Možda zato što sam tražio besplatna rješenja, a Robin je plaćen. Imaju prilično izdašnu besplatnu verziju sa 10TB prostora za pohranu i tri čvora. Generalno, proizvod je prilično pristojan i sa lijepim karakteristikama. Postoji odličan CLI, ali najbolja stvar je to što možete napraviti snimku i sigurnosnu kopiju cijele aplikacije (koja se nazivaju Helm izdanja ili "fleksibilne aplikacije" u selektoru resursa), uključujući volumene i druge resurse, tako da možete bez Velera. I sve bi bilo divno da ne postoji jedan mali detalj: ako vratite (ili "uvezete", kako se to u Robinu zove) aplikaciju na novom klasteru - na primjer, u slučaju oporavka od katastrofe - restauracija, naravno, radi, ali je zabranjeno nastaviti sa sigurnosnom kopijom aplikacije. U ovom izdanju to jednostavno nije moguće, a programeri su potvrdili. Ovo je u najmanju ruku čudno, posebno kada se uzmu u obzir druge prednosti (na primjer, nevjerovatno brze sigurnosne kopije i vraćanja). Programeri obećavaju da će sve popraviti do sljedećeg izdanja. Performanse su generalno dobre, ali sam primijetio čudnu stvar: ako pokrenete benchmark direktno na volumenu koji je povezan s hostom, brzina čitanja je mnogo veća nego u istom volumenu, ali iz unutrašnjosti pod-a. Svi ostali rezultati su identični, ali u teoriji ne bi trebalo biti razlike. Iako rade na tome, bio sam frustriran problemom vraćanja i backup-a - činilo mi se da sam konačno pronašao odgovarajuće rješenje, a bio sam čak i spreman da ga platim kada mi treba više prostora ili više servera.
Nemam puno za reći ovdje. Ovo je plaćeni proizvod, podjednako kul i skup. Izvedba je jednostavno neverovatna. Za sada je ovo najbolji pokazatelj. Slack mi je rekao da cijene počinju od 205 USD mjesečno po čvoru, kao što je navedeno na Google-ovom GKE Marketplace-u. Ne znam da li će biti jeftinije ako kupujete direktno. U svakom slučaju, ne mogu si to priuštiti, pa sam bio jako, jako razočaran što je licenca za programere (do 1TB i 3 čvora) praktički beskorisna s Kubernetesom, osim ako niste zadovoljni statičkim obezbjeđivanjem. Nadao sam se da će količinska licenca automatski preći na programer na kraju probnog perioda, ali to se nije dogodilo. Licenca za programere može se koristiti samo direktno sa Dockerom, a podešavanje u Kubernetesu je veoma glomazno i ograničeno. Naravno, više volim open source, ali da imam novca, svakako bih izabrao Portworx. Do sada se njegove performanse jednostavno ne mogu porediti sa drugim opcijama.
Dodao sam ovaj odjeljak nakon što je post objavljen, kada je čitatelj predložio da isprobate Linstor. Probala sam i svidjelo mi se! Ali i dalje morate kopati. Sada mogu reći da performanse nisu loše (benchmark rezultati dodati ispod). U stvari, dobio sam iste performanse kao i za disk direktno, bez ikakvih troškova. (Ne pitajte zašto su Portworx-ovi brojevi direktno bolji od benčmarka pogona. Nemam pojma. Magija, pretpostavljam.) Dakle, Linstor se do sada čini veoma efikasnim. Instalacija nije tako teška, ali nije tako jednostavna kao druge opcije. Prvo sam morao da instaliram Linstor (modul kernela i alate/usluge) i da postavim LVM za tanku proviziju i podršku za brze snimke van Kubernetesa, direktno na hostu, a zatim da kreiram resurse potrebne za korišćenje skladištenja iz Kubernetesa. Nije mi se svidjelo što ne radi na CentOS-u i morao sam koristiti Ubuntu. Nije strašno, naravno, ali pomalo neugodno, jer dokumentacija (koja je, inače, odlična) spominje nekoliko paketa koji se ne mogu naći u navedenim Epel repozitorijumima. Linstor ima snimke, ali nema rezervne kopije van lokacije, tako da sam ovdje opet morao koristiti Velero sa Restic-om za sigurnosnu kopiju volumena. Više bih volio snimke u odnosu na sigurnosne kopije na razini datoteke, ali to se može tolerirati ako je rješenje i učinkovito i pouzdano. Linstor je open source, ali ima plaćenu podršku. Ako sam dobro razumio, može se koristiti bez ograničenja, čak i ako nemate ugovor o podršci, ali to treba pojasniti. Ne znam kako je Linstor testiran za Kubernetes, ali sam sloj za skladištenje je van Kubernetesa i, po svemu sudeći, rešenje se nije pojavilo juče, pa je verovatno već testirano u realnim uslovima. Postoji li ovdje rješenje koje će me natjerati da se predomislim i vratim na Kubernetes? Ne znam. Još uvijek moramo kopati dublje, proučavati replikaciju. da vidimo. Ali prvi utisak je dobar. Definitivno bih radije koristio svoje Kubernetes klastere umjesto Herokua da imam više slobode i naučim nove stvari. Pošto Linstor nije tako jednostavan za instaliranje kao druge, uskoro ću napisati post o njemu.
Benchmarks
Nažalost, malo sam zabilježio poređenje, jer nisam mislio da ću o tome pisati. Imam samo FIO osnovne benchmark rezultate i to samo za klastere sa jednim čvorom, tako da još nemam brojeve za replicirane konfiguracije. Ali iz ovih rezultata možete dobiti grubu ideju šta očekivati od svake opcije, jer sam ih uporedio na istim cloud serverima, 4 jezgra, 16 GB RAM-a, sa dodatnim diskom od 100 GB za testirane volumene. Pokrenuo sam benchmark tri puta za svako rješenje i izračunao prosječan rezultat, plus resetirao postavke servera za svaki proizvod. Sve je ovo potpuno nenaučno, samo da shvatite uopšteno. U drugim testovima sam kopirao 38 GB fotografija i video zapisa sa volumena i za testiranje čitanja i pisanja, ali, nažalost, nisam sačuvao brojeve. Ukratko: Portworkx je bio mnogo brži.
Za mjerilo volumena koristio sam ovaj manifest:
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: 4Prvo sam kreirao volumen s odgovarajućom klasom za pohranu, a zatim pokrenuo posao sa fio iza scene. Uzeo sam 1 GB da procijenim performanse i da ne čekam predugo. Evo rezultata:
Označio sam najbolju vrijednost za svaku metriku zelenom, a najgoru crvenom.
zaključak
Kao što vidite, u većini slučajeva Portworx je imao bolje rezultate od ostalih. Ali za mene je to skupo. Ne znam koliko košta Robin, ali postoji odlična besplatna verzija, pa ako vam treba proizvod koji se plaća, možete ga isprobati (nadam se da će uskoro riješiti problem s restauracijama i backupima). Od tri besplatna, imao sam najmanje problema sa OpenEBS-om, ali njegove performanse su strašne. Žao mi je što nisam sačuvao više rezultata, ali nadam se da će vam brojevi i moji komentari pomoći.
izvor: www.habr.com