ProHoster > Blogs > Administrācija > Krātuve Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Krātuve Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Krātuve Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Atjaunināt!. Komentāros kāds no lasÄ«tājiem ieteica pamēģināt Linstors (varbÅ«t viņŔ pats pie tā strādā), tāpēc esmu pievienojis sadaļu par Å”o risinājumu. Es arÄ« rakstÄ«ju ierakstu par to, kā to instalēt, jo process ļoti atŔķiras no pārējiem.

Ja godÄ«gi, es padevos un padevos Kubernetes (vismaz pagaidām). es izmantoÅ”u Heroku. Kāpēc? GlabāŔanas dēļ! KurÅ” to bÅ«tu domājis, ka es vairāk lāpÄ«Å”os ar uzglabāŔanu, nevis paÅ”u Kubernetes. ES izmantoju Hecnera mākonisjo tas ir lēts un veiktspēja ir laba, un no paÅ”a sākuma es izvietoju klasterus, izmantojot fermeris. Es neizmēģināju pārvaldÄ«tos Kubernetes pakalpojumus no Google/Amazon/Microsoft/DigitalOcean utt., u.c., jo gribēju visu apgÅ«t pats. Es arÄ« esmu taupÄ«gs.

Tātad, jā, es pavadÄ«ju daudz laika, mēģinot izlemt, kuru krātuvi izvēlēties, izvērtējot iespējamo Kubernetes steku. Es dodu priekÅ”roku atvērtā pirmkoda risinājumiem ne tikai cenas dēļ, bet arÄ« ziņkārÄ«bas dēļ esmu izskatÄ«jis dažas maksas iespējas, jo tām ir bezmaksas versijas ar ierobežojumiem. Esmu pierakstÄ«jis dažus skaitļus no nesenajiem testiem, kad salÄ«dzināju dažādas iespējas, un tie varētu bÅ«t interesanti tiem, kas mācās par Kubernetes krātuvi. Lai gan es personÄ«gi pagaidām esmu atvadÄ«jies no Kubernetes. Es arÄ« gribu pieminēt CSI draiveris, kas var tieÅ”i nodroÅ”ināt Hetzner Cloud apjomus, taču es to vēl neesmu izmēģinājis. Es izpētÄ«ju mākoņa programmatÅ«ras definētu krātuvi, jo man bija nepiecieÅ”ama replikācija un iespēja ātri uzstādÄ«t pastāvÄ«gus sējumus jebkurā mezglā, it Ä«paÅ”i mezgla kļūmju un citu lÄ«dzÄ«gu situāciju gadÄ«jumā. Daži risinājumi piedāvā momentuzņēmumus un dublējumus ārpus vietnes, kas ir ērti.

Es pārbaudÄ«ju 6ā€“7 uzglabāŔanas risinājumus:

OpenEBS

Kā jau teicu iepriekŔējā ierakstāPārbaudÄ«jis lielāko daļu no saraksta opcijām, es sākotnēji izvēlējos OpenEBS. OpenEBS ir ļoti viegli instalējams un lietojams, taču, godÄ«gi sakot, pēc testÄ“Å”anas ar reāliem datiem zem slodzes, biju vÄ«lies par tā veiktspēju. Tas ir atvērts avots, un izstrādātāji ir paÅ”i Slavens kanāls vienmēr ļoti palÄ«dzēja, kad man bija vajadzÄ«ga palÄ«dzÄ«ba. Diemžēl tai ir ļoti vāja veiktspēja salÄ«dzinājumā ar citām opcijām, tāpēc testi bija jāveic atkārtoti. OpenEBS paÅ”laik ir 3 krātuves dzinēji, bet es publicēju cStor etalona rezultātus. Man vēl nav Jiva un LocalPV numuru.

ÄŖsumā, Jiva ir nedaudz ātrāks, un LocalPV parasti ir ātrs, ne sliktāks par diska etalonu tieÅ”i. Vietējā PV problēma ir tāda, ka sējumam var piekļūt tikai tajā mezglā, kurā tas tika sagatavots, un vispār nav replikācijas. Man bija dažas problēmas ar dublējuma atjaunoÅ”anu, izmantojot Buru laiva jaunā klasterÄ«, jo mezglu nosaukumi bija atŔķirÄ«gi. Ja mēs runājam par dublÄ“Å”anu, cStor ir spraudnis Velero, ar kuru jÅ«s varat izveidot momentuzņēmumu dublējumus ārpus vietnes noteiktā brÄ«dÄ«, kas ir ērtāk nekā faila lÄ«meņa dublējumkopijas ar Velero-Restic. ES rakstÄ«ju vairāki skripti, lai atvieglotu dublējumu un atjaunoÅ”anas pārvaldÄ«bu, izmantojot Å”o spraudni. Kopumā man ļoti patÄ«k OpenEBS, bet tā veiktspēja...

krauÄ·is

Rook ir arÄ« atvērtā koda un atŔķiras no pārējām opcijām sarakstā ar to, ka tas ir krātuves orÄ·estrētājs, kas veic sarežģītus krātuves pārvaldÄ«bas uzdevumus ar dažādām aizmugursistēmām, piemēram, Cef, EdgeFS un citi, kas ievērojami vienkārÅ”o darbu. Man bija problēmas ar EfgeFS, kad es to izmēģināju pirms dažiem mēneÅ”iem, tāpēc es testēju galvenokārt ar Ceph. Ceph piedāvā ne tikai bloku krātuvi, bet arÄ« objektu krātuvi, kas ir saderÄ«ga ar S3/Swift un izplatÄ«to failu sistēmu. Tas, kas man patÄ«k Ceph, ir iespēja izplatÄ«t apjoma datus vairākos diskos, lai sējums varētu izmantot vairāk diska vietas, nekā var ievietot vienā diskā. Tas ir ērti. Vēl viena lieliska iezÄ«me ir tā, ka, pievienojot diskus klasterim, tas automātiski pārdala datus visos diskos.

Ceph ir momentuzņēmumi, bet, cik man zināms, tos nevar izmantot tieÅ”i Rook/Kubernetes. Tiesa, es tajā neiedziļinājos. Bet ārpus vietnes nav dublējumu, tāpēc jums bÅ«s kaut kas jāizmanto ar Velero/Restic, taču ir tikai faila lÄ«meņa dublējumkopijas, nevis momentuzņēmumi brÄ«dÄ«. Man ļoti patika Rook tas, cik viegli ir strādāt ar Ceph ā€” tas slēpj gandrÄ«z visas sarežģītās lietas un piedāvā rÄ«kus, lai tieÅ”i sarunātos ar Ceph problēmu novērÅ”anai. Diemžēl Ceph apjomu stresa testa laikā man joprojām radās problēmas ar Ŕī problēma, kas izraisa Ceph nestabilitāti. Pagaidām nav skaidrs, vai tā ir kļūda paŔā Ceph vai problēma tajā, kā Rook pārvalda Ceph. Es pārdomāju atmiņas iestatÄ«jumus, un tas kļuva labāks, taču problēma netika pilnÄ«bā atrisināta. Kā redzams zemāk esoÅ”ajos etalonos, Ceph ir pienācÄ«gs sniegums. Tam ir arÄ« labs informācijas panelis.

Rančers Longhorns

Man ļoti patÄ«k Longhorn. Manuprāt, tas ir daudzsoloÅ”s risinājums. Tiesa, paÅ”i izstrādātāji (Rancher Labs) atzÄ«st, ka tas vēl nav piemērots darba videi, un tas arÄ« liecina. Tas ir atvērtā koda, un tam ir pienācÄ«ga veiktspēja (lai gan viņi to vēl nav optimizējuÅ”i), taču sējumiem ir nepiecieÅ”ams ļoti ilgs laiks, lai izveidotu savienojumu ar podziņu, un sliktākajos gadÄ«jumos tas aizņem 15ā€“16 minÅ«tes, Ä«paÅ”i pēc lielas dublējuma atjaunoÅ”anas vai darba slodzes uzlaboÅ”ana. Tam ir Å”o momentuzņēmumu momentuzņēmumi un dublējumkopijas ārpus vietnes, taču tie attiecas tikai uz sējumiem, tāpēc jums joprojām bÅ«s nepiecieÅ”ams kaut kas lÄ«dzÄ«gs Velero, lai dublētu citus resursus. DublÄ“Å”ana un atjaunoÅ”ana ir ļoti uzticama, taču nepieklājÄ«gi lēna. Nopietni, vienkārÅ”i neticami lēni. Strādājot ar vidēju datu apjomu programmā Longhorn, centrālā procesora lietojums un sistēmas slodze bieži palielinās. Lai pārvaldÄ«tu Longhorn, ir ērts informācijas panelis. Es jau teicu, ka man patÄ«k Longhorn, bet ar to ir jāpiestrādā.

StorageOS

StorageOS ir pirmais maksas produkts sarakstā. Tam ir izstrādātāja versija ar ierobežotu pārvaldÄ«to krātuves lielumu 500 GB, taču es nedomāju, ka mezglu skaits ir ierobežots. PārdoÅ”anas nodaļa man teica, ka izmaksas sākas no 125 USD mēnesÄ« par 1 TB, ja pareizi atceros. Ir pamata informācijas panelis un ērts CLI, taču ar veiktspēju notiek kaut kas dÄ«vains: dažos etalonos tas ir diezgan pieklājÄ«gs, bet skaļuma noslodzes testā ātrums man nepatika. Kopumā es nezinu, ko teikt. Tāpēc es Ä«sti daudz nesapratu. Å eit nav dublējumu ārpus vietnes, un sējumu dublÄ“Å”anai bÅ«s jāizmanto arÄ« Velero ar Restic. DÄ«vaini, jo prece ir apmaksāta. Un izstrādātāji nevēlējās sazināties Slack.

penijs

Es uzzināju par Robinu vietnē Reddit no viņu tehniskā direktora. Es nekad agrāk par viņu nebiju dzirdējis. VarbÅ«t tāpēc, ka meklēju bezmaksas risinājumus, bet Robinam maksā. Viņiem ir diezgan dāsna bezmaksas versija ar 10 TB krātuvi un trim mezgliem. Kopumā produkts ir diezgan pienācÄ«gs un tam ir jaukas Ä«paŔības. Ir lieliska CLI, taču pats forŔākais ir tas, ka varat izveidot momentuzņēmumu un dublēt visu lietojumprogrammu (resursu atlasÄ«tājā to sauc par Helm izlaidumiem vai ā€œflex appsā€), ieskaitot apjomus un citus resursus, lai jÅ«s varētu iztikt bez Velero. Un viss bÅ«tu brÄ«niŔķīgi, ja ne tikai viena sÄ«ka detaļa: ja atjaunotu (vai ā€œimportētuā€, kā to sauc Robinā) lietojumprogrammu jaunā klasterÄ« - piemēram, atkopÅ”anas gadÄ«jumā pēc katastrofas - atjaunoÅ”ana, protams, darbojas, bet turpināt dublēt lietojumprogrammu tas ir aizliegts. Å ajā laidienā tas vienkārÅ”i nav iespējams, kā to apstiprinājuÅ”i izstrādātāji. Tas ir, maigi izsakoties, dÄ«vaini, Ä«paÅ”i ņemot vērā citas priekÅ”rocÄ«bas (piemēram, neticami ātras dublÄ“Å”anas un atjaunoÅ”anas). Izstrādātāji sola visu salabot lÄ«dz nākamajam laidienam. Veiktspēja kopumā ir laba, taču es pamanÄ«ju dÄ«vainÄ«bu: ja es palaižu etalonu tieÅ”i sējumā, kas pievienots resursdatoram, lasÄ«Å”anas ātrums ir daudz ātrāks, nekā palaist to paÅ”u skaļumu no poda. Visi pārējie rezultāti ir identiski, taču teorētiski atŔķirÄ«bai nevajadzētu bÅ«t. Lai gan viņi pie tā strādā, es biju sarÅ«gtināts par problēmu ar atjaunoÅ”anu un dublÄ“Å”anu - es domāju, ka beidzot esmu atradis piemērotu risinājumu, un es pat biju gatavs par to maksāt, kad man vajadzēja vairāk vietas vai vairāk serveru.

Portvorksa

Man te nav daudz ko teikt. Å is ir maksas produkts, vienlÄ«dz forÅ”s un dārgs. Izrāde ir vienkārÅ”i pārsteidzoÅ”a. Tas ir lÄ«dz Å”im labākais rādÄ«tājs. Slack man teica, ka cenas sākas no USD 205 mēnesÄ« par mezglu, kā norādÄ«ts Google GKE Marketplace. Nezinu, vai bÅ«s lētāk, pērkot pa tieÅ”o. Es tik un tā nevaru to atļauties, tāpēc biju ļoti, ļoti vÄ«lies, ka izstrādātāja licence (lÄ«dz 1 TB un 3 mezgliem) ir praktiski bezjēdzÄ«ga ar Kubernetes, ja vien jÅ«s neesat apmierināts ar statisko nodroÅ”inājumu. Es cerēju, ka izmēģinājuma perioda beigās lielapjoma licence automātiski tiks pazemināta uz izstrādātāju, taču tas nenotika. Izstrādātāja licenci var izmantot tikai tieÅ”i ar Docker, un Kubernetes konfigurācija ir ļoti apgrÅ«tinoÅ”a un ierobežota. Protams, es dodu priekÅ”roku atvērtajam pirmkodam, bet, ja man bÅ«tu nauda, ā€‹ā€‹es noteikti izvēlētos Portworx. LÄ«dz Å”im tā veiktspēja vienkārÅ”i nav salÄ«dzināma ar citām iespējām.

Linstors

Å o sadaļu pievienoju pēc ieraksta publicÄ“Å”anas, kad kāds lasÄ«tājs ieteica izmēģināt Linstor. Izmēģināju un man patika! Bet mums joprojām ir jārok dziļāk. Tagad varu teikt, ka sniegums nav slikts (zemāk pievienoju etalona rezultātus). BÅ«tÄ«bā es saņēmu tādu paÅ”u veiktspēju kā disks tieÅ”i, bez papildu izmaksām. (Nejautājiet, kāpēc Portworx ir labāki skaitļi nekā piedziņas etalons tieÅ”i. Man nav ne jausmas. MaÄ£ija, es domāju.) Tātad Linstor pagaidām Ŕķiet ļoti efektÄ«vs. To nav tik grÅ«ti uzstādÄ«t, taču tas nav tik vienkārÅ”i kā citas iespējas. Vispirms man bija jāinstalē Linstor (kodola modulis un rÄ«ki/pakalpojumi) un jākonfigurē LVM plānam nodroÅ”inājumam un momentuzņēmumu atbalstam ārpus Kubernetes, tieÅ”i resursdatorā, un pēc tam jāizveido resursi, kas nepiecieÅ”ami, lai izmantotu krātuvi no Kubernetes. Man nepatika, ka tas nedarbojās uz CentOS, un man bija jāizmanto Ubuntu. Nav, protams, briesmÄ«gi, bet nedaudz kaitinoÅ”i, jo dokumentācijā (kas, starp citu, izcila) ir minētas vairākas paketes, kuras nevar atrast norādÄ«tajās Epel krātuvēs. Linstor ir momentuzņēmumi, bet ne izbraukuma dublējumkopijas, tāpēc Å”eit man atkal bija jāizmanto Velero ar Restic, lai dublētu apjomus. Es dotu priekÅ”roku momentuzņēmumiem, nevis faila lÄ«meņa dublējumkopijām, taču to var pieļaut, ja risinājums ir veiktspējÄ«gs un uzticams. Linstor ir atvērtā koda, taču tam ir arÄ« maksas atbalsts. Ja pareizi saprotu, to var izmantot bez ierobežojumiem, pat ja nav noslēgts atbalsta lÄ«gums, bet tas ir jāprecizē. Nezinu, cik Linstor ir pārbaudÄ«ts Kubernetes, bet pats krātuves slānis atrodas ārpus Kubernetes un acÄ«mredzot risinājums vakar neparādÄ«jās, tāpēc, iespējams, tas jau ir pārbaudÄ«ts reālos apstākļos. Vai Å”eit ir kāds risinājums, kas liks man mainÄ«t domas un atgriezties pie Kubernetes? ES nezinu. Mums joprojām ir jāiedziļinās un jāizpēta replikācija. PaskatÄ«simies. Bet pirmais iespaids labs. Es noteikti gribētu izmantot savus Kubernetes klasterus, nevis Heroku, lai bÅ«tu vairāk brÄ«vÄ«bas un apgÅ«tu jaunas lietas. Tā kā Linstor nav tik viegli uzstādÄ«t kā citus, tad drÄ«zumā par to uzrakstÄ«Å”u ierakstu.

Etaloni

Diemžēl es nesaglabāju daudz piezÄ«mju par salÄ«dzinājumu, jo nedomāju, ka par to rakstÄ«Å”u. Man ir rezultāti tikai no pamata fio etaloniem un tikai viena mezgla klasteriem, tāpēc man vēl nav skaitļu replicētām konfigurācijām. Bet no Å”iem rezultātiem var iegÅ«t aptuvenu priekÅ”statu par to, ko sagaidÄ«t no katras opcijas, jo es tos salÄ«dzināju tajos paÅ”os mākoņserveros, 4 kodoli, 16 GB RAM, ar papildu 100 GB disku pārbaudÄ«tajiem sējumiem. Es trÄ«s reizes izpildÄ«ju etalonus katram risinājumam un aprēķināju vidējo rezultātu, kā arÄ« atiestatÄ«ju servera iestatÄ«jumus katram produktam. Tas viss ir pilnÄ«gi nezinātniski, lai sniegtu jums vispārēju priekÅ”statu. Citos testos es nokopēju 38 GB fotoattēlu un videoklipu no sējuma, lai pārbaudÄ«tu lasÄ«Å”anu un rakstÄ«Å”anu, bet diemžēl es nesaglabāju skaitļus. ÄŖsāk sakot: Portworkx bija daudz ātrāks.

Apjoma etalonam izmantoju Ŕo manifestu:

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

Vispirms es izveidoju sējumu ar atbilstoÅ”u uzglabāŔanas klasi un pēc tam veicu darbu ar fio aizkulisēm. Es paņēmu 1 GB, lai novērtētu veiktspēju un negaidÄ«tu pārāk ilgi. LÅ«k, rezultāti:

Krātuve Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Es esmu iezīmējis katra rādītāja labāko vērtību zaļā krāsā un sliktāko sarkanā krāsā.

Secinājums

Kā redzat, vairumā gadÄ«jumu Portworx darbojās labāk nekā citi. Bet man tas ir dārgi. Es nezinu, cik maksā Robin, bet viņiem ir lieliska bezmaksas versija, tāpēc, ja vēlaties maksas produktu, varat to izmēģināt (cerams, ka viņi drÄ«z atrisinās problēmu ar atjaunoÅ”anu un dublÄ“Å”anu). No trim bezmaksas man vismazāk bija problēmas ar OpenEBS, taču tā veiktspēja ir nenormāla. Žēl, ka nesaglabāju vairāk rezultātu, bet ceru, ka skaitļi un mani komentāri jums palÄ«dzēs.

Avots: www.habr.com

Pievieno komentāru