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.
Yazı yayınlandıktan sonra, bir okuyucunun Linstor'u denemeyi önermesi üzerine bu bölümü ekledim. Denedim ve beğendim! Ama biraz daha araştırma yapmam gerekiyor. Şimdilik, performansın oldukça iyi olduğunu söyleyebilirim (aşağıda kıyaslama sonuçlarını ekledim). Aslında, herhangi bir ek yük olmadan, doğrudan disk kıyaslamasıyla aynı performansı elde ettim. (Portworx'ün rakamlarının doğrudan disk kıyaslamasından neden daha iyi olduğunu sormayın. Hiçbir fikrim yok. Sanırım sihir.) Yani, Linstor şu ana kadar çok etkili görünüyor. Kurulumu tam olarak zor değil, ancak diğer seçenekler kadar kolay da değil. İlk olarak, Linstor'u (çekirdek modülü ve araçlar/hizmetler) kurmam ve Kubernetes dışında, doğrudan ana bilgisayarda ince provizyon ve anlık görüntü desteği için LVM'yi kurmam ve ardından Kubernetes'ten depolamayı kullanmak için gereken kaynakları oluşturmam gerekti. Kubernetes'te çalışmadığı için mutlu değildim. CentOS ve kullanmak zorunda kaldı UbuntuElbette büyük bir sorun değil, ama biraz can sıkıcı çünkü dokümantasyon (bu arada mükemmel) belirtilen Epel depolarında bulunmayan birkaç paketten bahsediyor. Linstor'da anlık görüntüler var, ancak uzak yedekleme yok, bu yüzden hacim yedeklemeleri için tekrar Velero'yu Restic ile kullanmak zorunda kaldım. Dosya düzeyinde yedeklemeler yerine anlık görüntüleri tercih ederim, ancak çözüm performanslı ve güvenilir ise bu tolere edilebilir. Linstor açık kaynaklı, ancak ücretli destek var. Doğru anladıysam, destek sözleşmeniz olmasa bile kısıtlama olmadan kullanabilirsiniz, ancak bunu kontrol etmem gerekiyor. Linstor'un Kubernetes için ne kadar test edildiğini bilmiyorum, ancak depolama katmanı Kubernetes'in dışında ve bir süredir var gibi görünüyor, bu yüzden muhtemelen gerçek dünya koşullarında zaten test edilmiştir. Burada fikrimi değiştirip Kubernetes'e geri dönmemi sağlayacak bir çözüm var mı? Bilmiyorum. Replikasyon hakkında biraz daha araştırma yapmam ve bilgi edinmem gerekiyor. Bakalım ne olacak. Ama ilk izlenimim iyi. Daha fazla özgürlük ve yeni şeyler öğrenmek için Heroku yerine kendi Kubernetes kümelerimi kullanmayı kesinlikle tercih ederim. Linstor'un kurulumu diğerleri kadar kolay olmadığı için, yakında 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
