Güncelleme!. Yorumlarda okuyuculardan biri denemeyi önerdi (belki de kendisi üzerinde çalışıyordur) bu yüzden bu çözümle ilgili bir bölüm ekledim. ben de yazdım Çünkü süreç diğerlerinden çok farklı.
Dürüst olmak gerekirse pes ettim ve pes ettim (en azından şimdilik). kullanacağım . Neden? Depolama nedeniyle! Kubernetes'in kendisinden çok depolamayla ilgileneceğimi kim düşünebilirdi? kullanırım çünkü ucuz ve performansı iyi ve en başından beri kümeleri şunu kullanarak dağıtıyorum: . Google/Amazon/Microsoft/DigitalOcean vb.'nin yönetilen Kubernetes hizmetlerini denemedim çünkü her şeyi kendim öğrenmek istedim. Ben de tutumluyum.
Yani evet, olası bir Kubernetes yığınını değerlendirirken hangi depolama alanını seçeceğime karar vermek için çok zaman harcadım. Açık kaynaklı çözümleri tercih ediyorum, sadece fiyatı nedeniyle değil, aynı zamanda sınırlamalara sahip ücretsiz sürümleri olduğu için merakımdan birkaç ücretli seçeneğe baktım. Farklı seçenekleri karşılaştırırken son testlerden bazı rakamları not ettim ve bunlar Kubernetes depolama hakkında bilgi sahibi olanların ilgisini çekebilir. Gerçi şimdilik Kubernetes'e şahsen veda ettim. Ayrıca şunu da belirtmek istiyorum Hetzner Cloud birimlerini doğrudan tedarik edebilen, ancak henüz denemedim. Bulut yazılımı tanımlı depolamayı araştırdım çünkü çoğaltmaya ve özellikle düğüm arızaları ve diğer benzer durumlarda kalıcı birimleri herhangi bir düğüme hızlı bir şekilde bağlama yeteneğine ihtiyacım vardı. Bazı çözümler belirli bir zamanda anlık görüntüler ve tesis dışı yedeklemeler sunar; bu da kullanışlıdır.
6-7 depolama çözümünü test ettim:
Söylediğim gibi Listedeki seçeneklerin çoğunu test ettikten sonra başlangıçta OpenEBS'ye karar verdim. OpenEBS'nin kurulumu ve kullanımı çok kolaydır, ancak dürüst olmak gerekirse, yük altında gerçek verilerle test ettikten sonra performansından dolayı hayal kırıklığına uğradım. Bu açık kaynaktır ve geliştiriciler kendi başlarınadır yardıma ihtiyacım olduğunda her zaman çok yardımcı oldu. Ne yazık ki diğer seçeneklerle karşılaştırıldığında performansı çok düşük olduğundan testlerin yeniden yapılması gerekti. OpenEBS'nin şu anda 3 depolama motoru var, ancak cStor için kıyaslama sonuçlarını yayınlıyorum. Henüz Jiva ve LocalPV için numaralarım yok.
Özetle, Jiva biraz daha hızlıdır ve LocalPV genel olarak hızlıdır; doğrudan disk kıyaslamasından daha kötü değildir. LocalPV ile ilgili sorun, birime yalnızca hazırlandığı düğümden erişilebilmesi ve hiçbir çoğaltmanın olmamasıdır. Bir yedeği geri yüklerken bazı sorunlar yaşadım Düğüm adları farklı olduğundan yeni bir kümede. Yedeklemeler hakkında konuşursak, cStor'un Velero-Restic ile dosya düzeyinde yedeklemelerden daha kullanışlı olan anlık görüntülerin belirli bir zamanda site dışına yedeklenmesini sağlayabilirsiniz. yazdığım Bu eklentiyle yedeklemeleri ve geri yüklemeleri yönetmeyi kolaylaştırmak için. Genel olarak OpenEBS'i gerçekten seviyorum ama performansı...
Rook aynı zamanda açık kaynaktır ve farklı arka uçlarla karmaşık depolama yönetimi görevlerini gerçekleştiren bir depolama orkestratörü olmasıyla listedeki diğer seçeneklerden farklıdır; , ve işi büyük ölçüde kolaylaştıran diğerleri. Birkaç ay önce denediğimde EfgeFS ile sorun yaşadım, bu yüzden esas olarak Ceph ile test ettim. Ceph yalnızca blok depolama sunmakla kalmıyor, aynı zamanda S3/Swift ve dağıtılmış dosya sistemiyle uyumlu nesne depolama da sunuyor. Ceph'in sevdiğim yanı, birim verilerini birden fazla diske yayabilme yeteneğidir, böylece birim tek bir diske sığabilecek miktardan daha fazla disk alanı kullanabilir. O konforlu. Bir başka harika özellik de, bir kümeye disk eklediğinizde verileri tüm disklere otomatik olarak yeniden dağıtmasıdır.
Ceph'in anlık görüntüleri var ancak bildiğim kadarıyla bunlar doğrudan Rook/Kubernetes'te kullanılamıyor. Doğru, bu konuya derinlemesine girmedim. Ancak tesis dışı yedekleme yoktur, bu nedenle Velero/Restic ile bir şeyler kullanmanız gerekir, ancak yalnızca dosya düzeyinde yedeklemeler vardır, belirli bir noktaya ait anlık görüntüler yoktur. Rook'ta gerçekten hoşuma giden şey, Ceph ile çalışmanın ne kadar kolay olduğuydu; neredeyse tüm karmaşık şeyleri gizler ve sorun giderme için doğrudan Ceph ile konuşmak için araçlar sunar. Ne yazık ki Ceph hacimlerinin stres testi sırasında sorunlar yaşamaya devam ettim. Bu da Ceph'in kararsız hale gelmesine neden olur. Bunun Ceph'in kendisindeki bir hata mı yoksa Rook'un Ceph'i yönetme biçimindeki bir sorun mu olduğu henüz belli değil. Bellek ayarlarını düzelttim, düzeldi ama sorun tamamen çözülmedi. Aşağıdaki kıyaslamalarda görebileceğiniz gibi Ceph iyi bir performansa sahip. Aynı zamanda iyi bir kontrol paneline sahiptir.
Longhorn'u gerçekten seviyorum. Bana göre bu umut verici bir çözüm. Doğru, geliştiricilerin kendisi (Rancher Labs), bunun çalışma ortamı için henüz uygun olmadığını kabul ediyor ve bu gösteriyor. Açık kaynaktır ve iyi bir performansa sahiptir (her ne kadar henüz optimize edilmemiş olsa da), ancak birimlerin bölmeye bağlanması çok uzun zaman alır ve en kötü durumlarda, özellikle büyük bir yedeklemeyi geri yükledikten sonra 15-16 dakika sürer. iş yükünün yükseltilmesi. Bu anlık görüntülerin anlık görüntüleri ve tesis dışı yedeklemeleri vardır, ancak bunlar yalnızca birimler için geçerlidir, dolayısıyla diğer kaynakları yedeklemek için yine de Velero gibi bir şeye ihtiyacınız olacaktır. Yedeklemeler ve geri yüklemeler çok güvenilirdir ancak aşırı derecede yavaştır. Cidden, inanılmaz derecede yavaş. Longhorn'da orta miktarda veriyle çalışırken CPU kullanımı ve sistem yükü sıklıkla artıyor. Longhorn'u yönetmek için kullanışlı bir kontrol paneli var. Longhorn'u sevdiğimi zaten söylemiştim ama üzerinde biraz çalışılması gerekiyor.
StorageOS listedeki ilk ücretli üründür. 500 GB ile sınırlı yönetilen depolama boyutuna sahip bir geliştirici sürümü var, ancak düğüm sayısında bir sınır olduğunu düşünmüyorum. Satış departmanı bana, yanlış hatırlamıyorsam 125 TB için maliyetin ayda 1 dolardan başladığını söyledi. Temel bir kontrol paneli ve kullanışlı bir CLI var, ancak performansta tuhaf bir şeyler oluyor: bazı kıyaslamalarda oldukça iyi, ancak hacim stres testinde hızı hiç beğenmedim. Genel olarak ne diyeceğimi bilmiyorum. O yüzden pek bir şey anlamadım. Burada tesis dışı yedekleme yoktur ve birimleri yedeklemek için Velero'yu Restic ile birlikte kullanmanız gerekecektir. Garip çünkü ürün ücretli. Ve geliştiriciler Slack üzerinde iletişim kurmaya istekli değildi.
Robin'in varlığını Reddit'te teknik direktörlerinden öğrendim. Onu daha önce hiç duymamıştım. Belki de ücretsiz çözümler aradığım için ama Robin'e para ödeniyor. 10 TB depolama alanına ve üç düğüme sahip oldukça cömert bir ücretsiz sürümü var. Genel olarak ürün oldukça iyi ve güzel özelliklere sahip. Harika bir CLI var, ancak en güzel yanı, birimler ve diğer kaynaklar da dahil olmak üzere tüm uygulamanın (kaynak seçicide buna Helm sürümleri veya "esnek uygulamalar" denir) anlık görüntüsünü alıp yedekleyebilmenizdir, böylece Velero olmadan da yapabilirsiniz. Ve küçük bir ayrıntı olmasaydı her şey harika olurdu: Yeni bir kümedeki bir uygulamayı geri yüklerseniz (veya Robin'de denildiği gibi "içe aktarırsanız") - örneğin, bir felaketten kurtulma durumunda - restorasyon, Elbette çalışır ancak uygulamayı yedeklemeye devam etmek yasaktır. Geliştiricilerin de onayladığı gibi bu sürümde bu mümkün değil. Bu, özellikle diğer avantajlar (örneğin, inanılmaz derecede hızlı yedekleme ve geri yükleme) göz önüne alındığında, en hafif tabirle gariptir. Geliştiriciler bir sonraki sürümde her şeyi düzelteceklerine söz veriyor. Performans genel olarak iyidir, ancak bir tuhaflık fark ettim: Karşılaştırmayı doğrudan ana bilgisayara bağlı bir birim üzerinde çalıştırırsam, okuma hızı aynı birimi bölmenin içinden çalıştırmaktan çok daha hızlı olur. Diğer tüm sonuçlar aynıdır ancak teoride hiçbir fark olmamalıdır. Üzerinde çalışıyor olsalar da, geri yükleme ve yedeklemeyle ilgili sorun beni üzüyordu; sonunda uygun bir çözüm bulduğumu düşünüyordum ve hatta daha fazla alana veya daha fazla sunucuya ihtiyaç duyduğumda bunun için para ödemeye bile hazırdım.
Burada söyleyecek pek bir şeyim yok. Bu ücretli bir üründür, aynı derecede havalı ve pahalıdır. Performans tek kelimeyle muhteşem. Bu şu ana kadarki en iyi gösterge. Slack bana Google'ın GKE Marketplace'inde listelendiği gibi fiyatlandırmanın düğüm başına aylık 205 dolardan başladığını söyledi. Direkt alırsanız daha ucuz olur mu bilmiyorum. Zaten bunu karşılayamam, bu yüzden statik provizyondan memnun olmadığınız sürece geliştirici lisansının (1 TB'ye ve 3 düğüme kadar) Kubernetes'te pratik olarak işe yaramaz olmasından dolayı çok ama çok hayal kırıklığına uğradım. Deneme süresinin sonunda toplu lisansın otomatik olarak geliştirici sürümüne geçeceğini umuyordum ancak bu gerçekleşmedi. Geliştirici lisansı yalnızca doğrudan Docker ile kullanılabilir ve Kubernetes'te yapılandırma oldukça hantal ve sınırlıdır. Tabii ki açık kaynağı tercih ediyorum ama param olsa kesinlikle Portworx’u seçerdim. Şu ana kadar performansı diğer seçeneklerle karşılaştırılamaz.
Bu bölümü yazının yayınlanmasından sonra bir okuyucu Linstor'u denemeyi önerdiğinde ekledim. Denedim ve beğendim! Ama yine de daha derine inmemiz gerekiyor. Artık performansının fena olmadığını söyleyebilirim (Benchmark sonuçlarını aşağıya ekledim). Temel olarak, diskle aynı performansı hiçbir ek yük olmadan doğrudan elde ettim. (Portworx'ün neden doğrudan sürücü karşılaştırmasından daha iyi rakamlara sahip olduğunu sormayın. Hiçbir fikrim yok. Sanırım Magic.) Yani Linstor şu ana kadar çok etkili görünüyor. Kurulumu çok zor değil ancak diğer seçenekler kadar kolay da değil. Öncelikle Linstor'u (çekirdek modülü ve araçlar/hizmetler) kurmam ve LVM'yi Kubernetes dışında doğrudan ana makinede ince provizyon ve anlık görüntü desteği için yapılandırmam ve ardından Kubernetes'teki depolamayı kullanmak için gereken kaynakları oluşturmam gerekiyordu. CentOS'ta çalışmaması hoşuma gitmedi ve Ubuntu kullanmak zorunda kaldım. Elbette korkunç değil, ama biraz sinir bozucu çünkü belgeler (bu arada mükemmel) belirtilen Epel depolarında bulunamayan birkaç paketten bahsediyor. Linstor'un anlık görüntüleri var, ancak tesis dışı yedeklemeler yok, bu yüzden burada da birimleri yedeklemek için Velero'yu Restic ile birlikte kullanmak zorunda kaldım. Dosya düzeyinde yedeklemeler yerine anlık görüntüleri tercih ederim, ancak çözüm performanslı ve güvenilirse bu da tolere edilebilir. Linstor açık kaynaktır ancak ücretli desteği vardır. Eğer doğru anladıysam destek sözleşmeniz olmasa bile kısıtlama olmadan kullanılabilir ancak bunun açıklığa kavuşturulması gerekiyor. Linstor'un Kubernetes için ne kadar test edildiğini bilmiyorum, ancak depolama katmanının kendisi Kubernetes'in dışında ve görünüşe göre çözüm dün ortaya çıkmadı, bu yüzden muhtemelen zaten gerçek koşullarda test edilmiştir. Fikrimi değiştirip Kubernetes'e geri dönmemi sağlayacak bir çözüm var mı? Bilmiyorum. Hâlâ daha derine inip kopyalanmayı incelememiz gerekiyor. Görelim. Ama ilk izlenim iyi. Daha fazla özgürlüğe sahip olmak ve yeni şeyler öğrenmek için kesinlikle Heroku yerine kendi Kubernetes kümelerimi kullanmayı tercih ederim. Linstor'un kurulumu diğerleri kadar kolay olmadığından yakın zamanda bununla ilgili bir yazı yazacağım.
kıyaslamalar
Ne yazık ki karşılaştırmayla ilgili pek fazla not tutmadım çünkü bu konuda yazacağımı düşünmemiştim. Yalnızca temel fio kıyaslamalarından ve yalnızca tek düğümlü kümelerden sonuçlarım var, bu nedenle çoğaltılmış yapılandırmalar için henüz sayılarım yok. Ancak bu sonuçlardan her bir seçenekten ne bekleyeceğiniz konusunda kabaca bir fikir edinebilirsiniz çünkü bunları aynı bulut sunucularında, 4 çekirdekli, 16 GB RAM'le ve test edilen birimler için ek 100 GB diskle karşılaştırdım. Karşılaştırmaları her çözüm için üç kez çalıştırdım ve ortalama sonucu hesapladım, ayrıca her ürün için sunucu ayarlarını sıfırladım. Size genel bir fikir vermek için bunların hepsi tamamen bilim dışıdır. Diğer testlerde, okuma ve yazmayı test etmek için ciltten 38 GB fotoğraf ve video kopyaladım, ancak ne yazık ki sayıları kaydetmedim. Kısacası: Portworkx çok daha hızlıydı.
Hacim karşılaştırması için bu bildirimi kullandım:
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İlk önce uygun depolama sınıfına sahip bir birim oluşturdum ve ardından işi perde arkasında fio ile yürüttüm. Performansı tahmin etmek için 1 GB aldım ve çok fazla beklemedim. Sonuçlar burada:
Her metrik için en iyi değeri yeşille, en kötü değeri ise kırmızıyla vurguladım.
Sonuç
Gördüğünüz gibi çoğu durumda Portworx diğerlerinden daha iyi performans gösterdi. Ama benim için pahalı. Robin'in maliyetinin ne kadar olduğunu bilmiyorum ama harika bir ücretsiz sürümü var, yani ücretli bir ürün istiyorsanız deneyebilirsiniz (umarım geri yükleme ve yedeklemeyle ilgili sorunu yakında çözerler). Üç ücretsiz olan arasında OpenEBS ile en az sorun yaşadım, ancak performansı berbat. Daha fazla sonuç kaydetmemiş olmam üzücü ama umarım sayılar ve yorumlarım size yardımcı olur.
Kaynak: habr.com