Yeniləyin!. Şərhlərdə oxuculardan biri cəhd etməyi təklif etdi (bəlkə də onun üzərində işləyir), ona görə də bu həll haqqında bir bölmə əlavə etdim. Mən də yazdım çünki proses qalanlardan çox fərqlidir.
Düzünü desəm, imtina etdim və imtina etdim (ən azı indiyə qədər). istifadə edəcəm . Niyə? Saxlama səbəbindən! Kimin ağlına gələrdi ki, Kubernetesin özündən çox yaddaşla məşğul olacağımı. Mən istifadə edirəm , çünki ucuzdur və performans yaxşıdır və əvvəldən mən klasterləri yerləşdirdim. . Google/Amazon/Microsoft/DigitalOcean və s.-dən idarə olunan Kubernetes xidmətlərini sınamamışam, çünki hər şeyi özüm öyrənmək istəyirdim. Mən də qənaətciləm.
Beləliklə - bəli, Kubernetes-də mümkün yığını nəzərdən keçirərkən hansı yaddaşı seçəcəyimə qərar verməyə çox vaxt sərf etdim. Mən açıq mənbə həllərinə üstünlük verirəm və təkcə qiymətə görə deyil, həm də maraqdan bir neçə ödənişli varianta baxdım, çünki onların məhdudiyyətləri olan pulsuz versiyaları var. Fərqli variantları müqayisə edərkən son meyarlardan bir neçə rəqəmi qeyd etdim və onlar Kubernetesdə yaddaşı öyrənənlər üçün maraqlı ola bilər. Baxmayaraq ki, şəxsən mən indiyə qədər Kuberneteslə vidalaşdım. Mən də qeyd etmək istəyirəm , burada birbaşa Hetzner Cloud həcmlərini təmin edə bilərsiniz, lakin mən hələ bunu sınamamışam. Mən bulud proqram təminatı ilə müəyyən edilmiş yaddaşa baxırdım, çünki mənə replikasiyaya və davamlı həcmləri istənilən qovşaqda tez quraşdırmaq qabiliyyətinə ehtiyacım var idi, xüsusən də node nasazlığı və digər oxşar vəziyyətlər. Bəzi həllər zamanında anlıq görüntülər və saytdan kənar ehtiyat nüsxələri təklif edir ki, bu da əlverişlidir.
6-7 saxlama həllini sınaqdan keçirdim:
Artıq dediyim kimi , siyahıdakı variantların əksəriyyətini sınaqdan keçirərək əvvəlcə OpenEBS-də qərarlaşdım. OpenEBS quraşdırmaq və istifadə etmək çox asandır, amma düzünü desəm, yük altında real məlumatlarla sınaqdan keçirdikdən sonra onun performansı məni məyus etdi. Bu açıq mənbədir və tərtibatçılar özləridir köməyə ehtiyacım olanda həmişə çox kömək edir. Təəssüf ki, digər variantlarla müqayisədə çox zəif performansa malikdir, ona görə də testləri yenidən keçirməli oldum. Hal-hazırda OpenEBS-də 3 yaddaş mühərriki var, lakin mən cStor üçün benchmark nəticələrini dərc edirəm. Hələ Jiva və LocalPV üçün nömrələrim yoxdur.
Bir sözlə, Jiva bir qədər sürətlidir və LocalPV ümumiyyətlə sürətlidir, birbaşa sürücü göstəricisindən daha pis deyil. LocalPV ilə bağlı problem ondadır ki, həcmə yalnız onun təmin edildiyi qovşaqda daxil olmaq olar və heç bir təkrarlama yoxdur. vasitəsilə ehtiyat nüsxəsini bərpa etməkdə bəzi problemlər yaşadım node adları fərqli olduğu üçün yeni klasterdə. Yedəkləmələrdən danışarkən, cStor var , onun köməyi ilə saytdan kənar vaxtda snapshot ehtiyat nüsxələrini edə bilərsiniz, bu, Velero-Restic ilə fayl səviyyəli ehtiyat nüsxələrindən daha rahatdır. yazdım bu plaginlə ehtiyat nüsxələri və bərpaları idarə etməyi asanlaşdırmaq üçün. Ümumiyyətlə, mən OpenEBS-ni çox bəyənirəm, lakin onun performansı...
Rook həm də açıq mənbədir və siyahıdakı digər seçimlərdən fərqlənir ki, o, məsələn, müxtəlif arxa tərəflərlə mürəkkəb yaddaş idarəetmə tapşırıqlarını yerinə yetirən yaddaş orkestratorudur. , və başqaları, bu da işi xeyli asanlaşdırır. Bir neçə ay əvvəl EfgeFS ilə bağlı problemlərim var idi, ona görə də əsasən Ceph ilə sınaqdan keçirdim. Ceph yalnız blok yaddaşı deyil, həm də S3/Swift və paylanmış fayl sistemi ilə uyğun olan obyekt yaddaşını təklif edir. Ceph-də bəyəndiyim şey, həcm məlumatını birdən çox diskə yaymaq qabiliyyətidir ki, həcm bir diskə sığdığından daha çox disk sahəsi istifadə edə bilsin. Rahatdır. Başqa bir gözəl xüsusiyyət odur ki, klasterə disklər əlavə etdiyiniz zaman o, məlumatları avtomatik olaraq bütün disklər arasında yenidən paylayır.
Ceph-in anlıq görüntüləri var, amma bildiyimə görə, onlar birbaşa Rook/Kubernetes-də istifadə edilə bilməz. Etiraf edim ki, mən bunu dərindən araşdırmadım. Ancaq saytdan kənar ehtiyat nüsxələri yoxdur, ona görə də Velero / Restic ilə bir şey istifadə etməlisiniz, lakin yalnız fayl səviyyəli ehtiyat nüsxələri var, zamanında çəkilmiş görüntülər deyil. Rook haqqında həqiqətən bəyəndiyim şey Ceph ilə işləməyin asanlığıdır - o, demək olar ki, bütün mürəkkəb işləri gizlədir və problemlərin həlli üçün birbaşa Ceph ilə danışmaq üçün alətlər təklif edir. Təəssüf ki, Ceph cildlərinin stress testində mən həmişə idim , bu da Cefin qeyri-sabit olmasına səbəb olur. Bunun Cefin özündə bir səhv və ya Rookun Ceph-i necə idarə etməsində problem olduğu hələ aydın deyil. Yaddaş parametrləri ilə məşğul oldum və yaxşılaşdı, lakin problem tamamilə həll edilmədi. Aşağıdakı meyarlarda göründüyü kimi Ceph yaxşı performansa malikdir. O, həmçinin yaxşı tablosuna malikdir.
Mən Longhornu çox sevirəm. Düşünürəm ki, bu, perspektivli bir həlldir. Düzdür, tərtibatçıların özləri (Rancher Labs) onun hələ istehsal mühiti üçün uyğun olmadığını etiraf edirlər və bu onu göstərir. O, açıq mənbədir və layiqli performansa malikdir (hələ onu optimallaşdırmamış olsalar da), lakin həcmləri poda əlavə etmək çox uzun vaxt tələb edir və ən pis hallarda, xüsusən də böyük ehtiyat nüsxəsini bərpa etdikdən sonra 15-16 dəqiqə çəkir. iş yükünün təkmilləşdirilməsi. Onun anlıq görüntüləri və həmin görüntülərin saytdan kənar ehtiyat nüsxələri var, lakin onlar yalnız həcmlərə aiddir, ona görə də qalan resursların ehtiyat nüsxəsini çıxarmaq üçün sizə hələ də Velero kimi bir şey lazımdır. Yedəkləmə və bərpa çox etibarlıdır, lakin ləyaqətsiz dərəcədə yavaşdır. Ciddi, sadəcə qadağanedici dərəcədə yavaş. Longhorn-da orta məlumat miqdarı ilə işləyərkən CPU istifadəsi və sistem yükü tez-tez artır. Longhorn idarə etmək üçün lazımlı bir tablosuna malikdir. Artıq dedim ki, mən Longhorn-u bəyənirəm, amma onun üzərində düzgün işləmək lazımdır.
StorageOS siyahıda ilk ödənişli məhsuldur. Onun 500 GB-lıq məhdud idarə olunan saxlama ölçüsü ilə inkişaf etdirici versiyası var, lakin qovşaqların sayında məhdudiyyət olduğunu düşünmürəm. Satış şöbəsi mənə dedi ki, səhv xatırlamıramsa, 125 TB üçün qiymət ayda 1 dollardan başlayır. Əsas tablosuna və lazımlı CLI var, lakin performansda qəribə bir şey var: bəzi meyarlarda bu olduqca layiqdir, lakin həcmlərin stress testində sürəti heç bəyənmədim. Ümumiyyətlə, nə deyəcəyimi bilmirəm. Ona görə də həqiqətən başa düşmədim. Burada saytdan kənar ehtiyat nüsxələri yoxdur və siz həmçinin həcmlərin ehtiyat nüsxəsini çıxarmaq üçün Velero ilə Restic-dən istifadə etməli olacaqsınız. Qəribədir, çünki məhsul pulludur. Tərtibatçılar Slack-də ünsiyyət qurmağa həvəsli deyildilər.
Reddit-də Robin haqqında onların texniki direktorundan öyrəndim. Mən əvvəllər onun haqqında heç eşitməmişdim. Bəlkə ona görə ki, mən pulsuz həllər axtarırdım və Robin pulludur. Onların 10 TB yaddaş və üç qovşaq ilə olduqca səxavətli pulsuz versiyası var. Ümumiyyətlə, məhsul olduqca layiqli və gözəl xüsusiyyətlərə malikdir. Mükəmməl bir CLI var, lakin ən maraqlısı odur ki, həcmlər və digər resurslar da daxil olmaqla bütün tətbiqin (Helm buraxılışları və ya resurs seçicisində "çevik proqramlar" adlanır) şəklini çəkə və ehtiyat nüsxəsini çıxara bilərsiniz, beləliklə, Velero olmadan edə bilərsiniz. Bir xırda detal olmasaydı, hər şey gözəl olardı: yeni bir klasterdə tətbiqi bərpa etsəniz (və ya Robində deyildiyi kimi "idxal" etsəniz - məsələn, fəlakətin bərpası halında - bərpa, Əlbəttə, işləyir, ancaq tətbiqin ehtiyat nüsxəsini çıxarmağa davam etmək qadağandır. Bu buraxılışda bu, sadəcə olaraq mümkün deyil və tərtibatçılar təsdiqlədilər. Bu, ən azı qəribədir, xüsusən də digər üstünlükləri nəzərə aldıqda (məsələn, inanılmaz sürətli ehtiyat nüsxələri və bərpalar). Tərtibatçılar növbəti buraxılışa qədər hər şeyi düzəltməyə söz verirlər. Performans ümumiyyətlə yaxşıdır, amma qəribə bir şey gördüm: etalon birbaşa hosta qoşulmuş bir həcmdə işlədirsinizsə, oxuma sürəti eyni həcmdə olduğundan çox daha yüksəkdir, lakin pod daxilindən. Bütün digər nəticələr eynidir, lakin nəzəri cəhətdən heç bir fərq olmamalıdır. Bunun üzərində işləsələr də, mən bərpa və ehtiyat nüsxə problemindən məyus oldum - mənə elə gəldi ki, nəhayət, uyğun bir həll tapdım və hətta daha çox yerə və ya daha çox serverə ehtiyacım olanda bunun üçün pul ödəməyə hazır idim.
Burada deyəcək çox sözüm yoxdur. Bu pullu məhsuldur, eyni dərəcədə sərin və bahalıdır. Performans sadəcə heyrətamizdir. Hələlik bu, ən yaxşı göstəricidir. Slack mənə qiymətlərin Google-un GKE Marketplace-də qeyd edildiyi kimi, hər node üçün ayda 205 dollardan başladığını söylədi. Direkt alsanız ucuz olar, bilmirəm. Hər halda, mən bunu ödəyə bilmirəm, buna görə də statik təminatla kifayətlənmədiyiniz halda, inkişaf etdirici lisenziyasının (1TB-a qədər və 3 qovşaq) Kubernetes ilə praktiki olaraq faydasız olması məni çox məyus etdi. Mən ümid edirdim ki, sınaq müddətinin sonunda həcm lisenziyası avtomatik olaraq developer səviyyəsinə enəcək, lakin bu baş vermədi. Tərtibatçı lisenziyası yalnız Docker ilə birbaşa istifadə edilə bilər və Kubernetes-də quraşdırma çox çətin və məhduddur. Təbii ki, açıq mənbəyə üstünlük verirəm, amma pulum olsaydı, mütləq Portworx-u seçərdim. İndiyə qədər onun performansı digər variantlarla müqayisə olunmur.
Bu bölməni yazı dərc edildikdən sonra, bir oxucu Linstor-u sınamağı təklif edəndə əlavə etdim. Mən sınadım və xoşuma gəldi! Ancaq hələ də qazmaq lazımdır. İndi deyə bilərəm ki, performans pis deyil (benchmark nəticələri aşağıda əlavə olunur). Əslində, mən heç bir yük olmadan birbaşa sürücü ilə eyni performansı əldə etdim. (Portworx-un rəqəmlərinin niyə sürücünün etalonundan daha yaxşı olduğunu soruşmayın. Heç bir fikrim yoxdur. Sehrli, deyəsən.) Beləliklə, Linstor indiyə qədər çox təsirli görünür. Onu quraşdırmaq o qədər də çətin deyil, lakin digər variantlar kimi asan deyil. Mən əvvəlcə Linstor (kernel modulu və alətlər/xidmətlər) quraşdırmalı və Kubernetes xaricində, birbaşa hostda nazik təminat və snapshot dəstəyi üçün LVM qurmalı və sonra Kubernetes-dən yaddaşdan istifadə etmək üçün lazım olan resursları yaratmalı idim. Onun CentOS-da işləməməsi və Ubuntu istifadə etməli olması mənim xoşuma gəlmədi. Əlbəttə ki, dəhşətli deyil, amma bir az zəhlətökəndir, çünki sənədlərdə (yeri gəlmişkən, əladır) göstərilən Epel depolarında tapılmayan bir neçə paket qeyd olunur. Linstor'un anlıq görüntüləri var, lakin saytdan kənar ehtiyat nüsxələri yoxdur, buna görə də həcmlərin ehtiyat nüsxəsini çıxarmaq üçün yenidən Velero-dan Restic ilə istifadə etməli oldum. Fayl səviyyəli ehtiyat nüsxələrdən daha çox anlıq görüntülərə üstünlük verərdim, lakin həll yolu həm effektiv, həm də etibarlı olarsa, buna dözmək olar. Linstor açıq mənbədir, lakin pullu dəstək var. Düzgün başa düşdümsə, dəstək müqaviləniz olmasa belə, məhdudiyyətsiz istifadə edilə bilər, lakin bunu aydınlaşdırmaq lazımdır. Linstor-un Kubernetes üçün necə sınaqdan keçirildiyini bilmirəm, lakin saxlama təbəqəsinin özü Kubernetesdən kənardadır və görünür, həll dünən görünmədi, buna görə də çox güman ki, real şəraitdə sınaqdan keçirilib. Burada məni fikrimi dəyişdirib Kubernetesə qayıtmağa məcbur edəcək bir həll varmı? Mən bilmirəm. Biz hələ də daha dərindən qazmalı, təkrarlamanı öyrənməliyik. Görək. Amma ilk təəssürat yaxşıdır. Daha çox sərbəstliyə sahib olmaq və yeni şeylər öyrənmək üçün Heroku əvəzinə öz Kubernetes klasterlərimdən istifadə etməyə üstünlük verərdim. Linstorun quraşdırılması digərləri kimi asan olmadığı üçün tezliklə bu haqda yazı yazacam.
Benchmarks
Təəssüf ki, müqayisənin bir neçə qeydini saxladım, çünki bu barədə yazacağımı düşünmürdüm. Mən yalnız tək qovşaq klasterləri üçün ilkin müqayisə nəticələrim var, ona görə də təkrarlanan konfiqurasiyalar üçün hələ nömrələrim yoxdur. Ancaq bu nəticələrdən hər bir seçimdən nə gözlədiyiniz barədə təxmini bir fikir əldə edə bilərsiniz, çünki mən onları eyni bulud serverlərində, 4 nüvədə, 16 GB RAM, sınaqdan keçirilmiş həcmlər üçün əlavə 100 GB disklə müqayisə etdim. Hər bir həll üçün testləri üç dəfə işlədim və orta nəticəni hesabladım, həmçinin hər bir məhsul üçün server parametrlərini sıfırladım. Bütün bunlar tamamilə qeyri-elmidir, sadəcə olaraq ümumi mənada başa düşəsiniz. Digər testlərdə oxumağı və yazmağı sınamaq üçün həcmdən 38 GB foto və video köçürdüm, amma təəssüf ki, nömrələri saxlamadım. Qısacası: Portworkx daha sürətli idi.
Həcmi müqayisə etmək üçün mən bu manifestdən istifadə etdim:
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Əvvəlcə müvafiq saxlama sinfi ilə bir cild yaratdım və sonra işi pərdə arxasında fio ilə idarə etdim. Performansı qiymətləndirmək və çox gözləməmək üçün 1 GB götürdüm. Nəticələri təqdim edirik:
Hər bir metrik üçün ən yaxşı dəyəri yaşıl, ən pisini isə qırmızı rənglə vurğuladım.
Nəticə
Gördüyünüz kimi, əksər hallarda Portworx digərlərindən daha yaxşı çıxış etdi. Amma mənim üçün bahadır. Robinin nə qədər baha başa gəldiyini bilmirəm, amma əla pulsuz versiya var, ona görə də pullu məhsula ehtiyacınız varsa, onu sınaqdan keçirə bilərsiniz (ümid edirəm ki, tezliklə bərpa və ehtiyat nüsxələri ilə problemi həll edəcəklər). Üç pulsuz olanlardan mən OpenEBS ilə ən az problem yaşadım, lakin onun performansı bərbaddır. Daha çox nəticə saxlamadığım üçün üzr istəyirəm, amma ümid edirəm ki, rəqəmlər və şərhlərim sizə kömək edəcək.
Mənbə: www.habr.com