Bu makale, kendiniz için doğru çözümü seçmenize ve Gluster, Ceph ve Vstorage (Virtuozzo) gibi SDS arasındaki farkları anlamanıza yardımcı olmak için yazılmıştır.
Metin, belirli sorunların daha ayrıntılı bir şekilde açıklandığı makalelere bağlantılar kullanır, bu nedenle açıklamalar mümkün olduğu kadar kısa olacaktır, gereksiz tüyolar olmadan kilit noktalar ve isterseniz İnternetten bağımsız olarak edinebileceğiniz giriş bilgileri kullanılacaktır.
Aslında, elbette, gündeme getirilen konular metnin tonlarını gerektiriyor, ancak modern dünyada giderek daha fazla insan okumayı pek sevmiyor))), böylece hızlı bir şekilde okuyabilir ve bir seçim yapabilirsiniz ve eğer bir şey varsa net değil, bağlantıları takip edin veya google'da belirsiz kelimeleri takip edin))) ve bu makale, bu derin konular için, her kararın ana kilit noktalarını gösteren şeffaf bir paket gibidir.
Yapıştırıcı
Sanal ortamlar için açık kaynak tabanlı SDS'ye sahip hiper bütünleşik platform üreticileri tarafından aktif olarak kullanılan ve RedHat web sitesinde depolama bölümünde bulunabilen ve iki SDS seçeneğinden birini seçebileceğiniz Gluster ile başlayalım: Gluster veya Ceph.
Gluster, bir tercüman yığınından oluşur - dosyaları dağıtma vb. gibi tüm işleri gerçekleştiren hizmetler. Brick, bir diske hizmet veren bir hizmettir, Volume ise bu tuğlaları birleştiren bir birimdir (havuz). Daha sonra, DHT (dağıtılmış karma tablo) işlevini kullanarak dosyaları gruplara dağıtma hizmeti gelir. Aşağıdaki bağlantılarda bununla ilgili sorunlar açıklanacağından Sharding hizmetini açıklamaya dahil etmeyeceğiz.
Yazma sırasında dosyanın tamamı Brick'te saklanır ve kopyası aynı anda ikinci sunucudaki Brick'e yazılır. Daha sonra ikinci dosya, farklı sunuculardaki iki tuğladan (veya daha fazlasından) oluşan ikinci gruba yazılacaktır.
Dosyalar yaklaşık olarak aynı boyuttaysa ve birim yalnızca bir gruptan oluşuyorsa, o zaman her şey yolunda demektir, ancak diğer koşullar altında açıklamalardan aşağıdaki sorunlar ortaya çıkacaktır:
- gruplardaki alan dengesiz kullanılıyor, dosyaların boyutuna bağlı ve grupta dosya yazmak için yeterli alan yoksa hata alırsınız, dosya yazılmaz ve başka bir gruba yeniden dağıtılmaz ;
- bir dosya yazarken, GÇ yalnızca bir gruba gider, geri kalanı boştadır;
- bir dosya yazarken tüm birimin GÇ'sini alamazsınız;
- ve genel konsept, bloklara veri dağıtımının olmaması nedeniyle daha az verimli görünüyor; burada tekdüze dağıtım sorununu dengelemek ve çözmek daha kolaydır ve artık tüm dosya bir bloğa girmez.
Resmi açıklamadan ayrıca istemeden de olsa gluster'ın klasik donanımsal RAID'in üzerinde dosya depolama olarak çalıştığını anlıyoruz. Dosyaları bloklar halinde kesmek (Parçalamak) için geliştirme girişimleri olmuştur, ancak bunların tümü, halihazırda mevcut mimari yaklaşıma performans kayıpları getiren bir eklemedir ve ayrıca Fuse gibi performans sınırlamalarına sahip serbestçe dağıtılan bileşenlerin kullanımıdır. Dosyaları bloklara dağıtırken depolamanın performansını ve hata toleransı yeteneklerini sınırlayan meta veri hizmetleri yoktur. “Dağıtılmış Çoğaltılmış” yapılandırmayla daha iyi performans göstergeleri gözlemlenebilir ve optimum yük dağılımına sahip güvenilir bir kopya 6 düzenlemek için düğüm sayısının en az 3 olması gerekir.
Bu bulgular aynı zamanda kullanıcı deneyiminin tanımıyla da ilgilidir. ve karşılaştırıldığında ve ayrıca bu daha üretken ve daha güvenilir konfigürasyonun anlaşılmasına yol açan deneyimin bir açıklaması da bulunmaktadır.
Resim, iki dosya yazarken yük dağılımını gösterir; burada ilk dosyanın kopyaları, birim 0 grubunda birleştirilen ilk üç sunucuya dağıtılır ve ikinci dosyanın üç kopyası, üç birimden oluşan ikinci grup cilt1'e yerleştirilir. sunucular. Her sunucunun bir diski vardır.
Genel sonuç, Gluster'ı kullanabileceğinizdir, ancak sanal ortamların bilgi işlem yükleri için de kaynaklara ihtiyaç duyulan hiper yakınsanmış bir çözümün belirli koşulları altında zorluklar yaratan performans ve hata toleransında sınırlamalar olacağı anlayışıyla.
Ayrıca belirli koşullar altında elde edilebilecek bazı Gluster performans göstergeleri de vardır;
cep
Şimdi yapabildiğim mimari açıklamalardan Ceph'e bakalım. arasında da bir karşılaştırma var Hizmetleri yük altında tüm donanım kaynaklarını gerektirdiğinden Ceph'i ayrı sunuculara dağıtmanın tavsiye edildiğini hemen anlayabilirsiniz.
Mimari Gluster'dan daha karmaşıktır ve meta veri hizmetleri gibi hizmetler vardır, ancak tüm bileşen yığını oldukça karmaşıktır ve onu bir sanallaştırma çözümünde kullanmak için çok esnek değildir. Veriler, daha verimli görünen bloklar halinde depolanır, ancak tüm hizmetlerin (bileşenlerin) hiyerarşisinde, belirli yükler ve acil durum koşulları altında kayıplar ve gecikmeler vardır, örneğin aşağıdakiler
Mimarinin açıklamasından, verilerin depolanacağı konumun seçildiği kalp CRUSH'dur. Sonra PG geliyor - bu anlaşılması en zor soyutlamadır (mantıksal grup). CRUSH'u daha etkili hale getirmek için PG'lere ihtiyaç vardır. PG'nin temel amacı, kaynak tüketimini azaltmak, performansı ve ölçeklenebilirliği artırmak için nesneleri gruplamaktır. Nesneleri bir PG'de birleştirmeden doğrudan, tek tek adreslemek çok pahalı olacaktır. OSD, her disk için bir hizmettir.
Bir küme, farklı amaçlara yönelik ve farklı ayarlara sahip bir veya daha fazla veri havuzuna sahip olabilir. Havuzlar yerleşim gruplarına ayrılmıştır. Yerleşim grupları, istemcilerin eriştiği nesneleri depolar. Mantıksal düzeyin bittiği ve fiziksel düzeyin başladığı yer burasıdır, çünkü her yerleştirme grubuna bir ana disk ve birkaç çoğaltma diski atanır (tam olarak kaç tanesi havuz çoğaltma faktörüne bağlıdır). Başka bir deyişle, mantıksal düzeyde nesne belirli bir yerleştirme grubunda ve fiziksel düzeyde kendisine atanan disklerde depolanır. Bu durumda diskler fiziksel olarak farklı düğümlerde, hatta farklı veri merkezlerinde bulunabilir.
Bu şemada yerleştirme grupları, tüm çözümün esnekliği için gerekli bir seviye gibi görünüyor, ancak aynı zamanda bu zincirdeki ekstra bir halka olarak, bu da istemeden bir üretkenlik kaybına işaret ediyor. Örneğin, veri yazarken sistemin onu bu gruplara bölmesi ve ardından fiziksel düzeyde kopyalar için ana diske ve disklere bölmesi gerekir. Yani, Hash işlevi bir nesneyi ararken ve eklerken çalışır, ancak bir yan etkisi vardır - karmanın yeniden oluşturulmasında (bir diski eklerken veya çıkarırken) çok yüksek maliyetler ve kısıtlamalardır. Başka bir karma sorunu, verilerin değiştirilemeyecek şekilde açıkça çivilenmiş konumudur. Yani, disk bir şekilde artan yük altındaysa, sistemin ona yazmama fırsatı yoktur (başka bir disk seçerek), karma işlevi, ne kadar kötü olursa olsun, verilerin kurala göre yerleştirilmesini zorunlu kılar. Disk öyledir, bu nedenle Ceph, kendi kendini iyileştirme veya depolamayı artırma durumunda PG'yi yeniden oluştururken çok fazla bellek tüketir. Sonuç olarak Ceph'in iyi çalıştığı (yavaş da olsa) ancak yalnızca ölçeklendirme, acil durumlar veya güncelleme olmadığında çalıştığı görülüyor.
Elbette, önbelleğe alma ve önbellek paylaşımı yoluyla performansı artırma seçenekleri vardır, ancak bu iyi bir donanım gerektirir ve yine de kayıplar olacaktır. Ancak genel olarak Ceph, üretkenlik açısından Gluster'dan daha cazip görünüyor. Ayrıca, bu ürünleri kullanırken önemli bir faktörü hesaba katmak gerekir - bu, Linux'a büyük önem veren yüksek düzeyde yeterlilik, deneyim ve profesyonelliktir, çünkü her şeyi doğru bir şekilde dağıtmak, yapılandırmak ve sürdürmek çok önemlidir. Bu da yöneticiye daha fazla sorumluluk ve yük getirmektedir.
Vstorage
Mimari daha da ilginç görünüyor Aynı düğümlerdeki bir hipervizörle birlikte kullanılabilen, aynı , ancak iyi bir performans elde etmek için her şeyi doğru şekilde yapılandırmak çok önemlidir. Yani böyle bir ürünü mimariye uygun önerileri dikkate almadan herhangi bir konfigürasyonda kutudan dağıtmak çok kolay olacak ama üretken olmayacak.
Depolama için kvm-qemu hipervizörünün hizmetlerinin yanında bir arada var olabilecekler ve bunlar, kompakt ve optimal bir bileşen hiyerarşisinin bulunduğu hizmetlerden yalnızca birkaçıdır: FUSE aracılığıyla bağlanan istemci hizmeti (değiştirilmiş, açık kaynak değil), MDS meta veri hizmeti (Meta veri hizmeti), fiziksel düzeyde bir diske eşit olan hizmet Chunk hizmeti veri blokları ve hepsi bu. Hız açısından, elbette, iki kopya ile hataya dayanıklı bir şema kullanmak en uygunudur, ancak SSD sürücülerinde önbelleğe alma ve günlükleri kullanırsanız, o zaman hataya dayanıklı kodlama (kodlamayı silme veya baskın6) uygun şekilde hız aşırtma yapılabilir. hibrit şema veya tüm flaşlarda daha da iyisi. EC'nin (kod silme) bazı dezavantajları vardır: bir veri bloğunu değiştirirken eşlik miktarlarının yeniden hesaplanması gerekir. Bu işlemle ilgili kayıpları atlamak için Ceph, EC'ye gecikmeli olarak yazar ve belirli bir istek sırasında performans sorunları ortaya çıkabilir; örneğin tüm blokların okunması gerektiğinde ve Virtuozzo Storage durumunda, değiştirilen blokların yazılması gerçekleştirilir. Eşlik hesaplama maliyetlerini en aza indiren “log-yapılandırılmış dosya sistemi” yaklaşımını kullanmak. EC ile ve EC olmadan işin hızlandırılmasıyla ilgili seçenekleri yaklaşık olarak tahmin etmek için, – rakamlar, ekipman üreticisinin doğruluk katsayısına bağlı olarak yaklaşık olabilir, ancak hesaplamaların sonucu, konfigürasyonun planlanmasında iyi bir yardımcıdır.
Depolama bileşenlerinin basit bir diyagramı, bu bileşenlerin emilmediği anlamına gelmez. ancak tüm maliyetleri önceden hesaplarsanız hipervizörün yanında işbirliğine güvenebilirsiniz.
Ceph ve Virtuozzo depolama hizmetlerinin donanım kaynaklarının tüketimini karşılaştırmak için bir plan var.
Daha önce Gluster ve Ceph'i eski makaleleri kullanarak, onlardan en önemli satırları kullanarak karşılaştırmak mümkün olsaydı, Virtuozzo ile bu daha zordu. Bu ürün hakkında çok fazla makale yok ve bilgiler yalnızca ilgili belgelerden derlenebilir. veya Vstorage'ı aşağıdaki gibi şirketlerdeki bazı hiper bütünleşik çözümlerde kullanılan depolama alanı olarak düşünürsek Rusça olarak ve Acronis.
Bu mimarinin bir açıklamasıyla yardımcı olmaya çalışacağım, bu yüzden biraz daha fazla metin olacak, ancak belgeleri kendi başınıza anlamanız çok zaman alır ve mevcut belgeler yalnızca tabloyu revize ederek referans olarak kullanılabilir. içeriğin veya anahtar kelimeye göre aramanın yapılması.
Kayıt sürecini yukarıda açıklanan bileşenlerle hibrit bir donanım konfigürasyonunda ele alalım: kayıt, istemcinin onu başlattığı düğüme (FUSE bağlama noktası hizmeti) gitmeye başlar, ancak Meta Veri Hizmeti (MDS) ana bileşeni elbette istemciyi doğrudan istenen yığın hizmetine (depolama hizmeti CS blokları) yönlendirir, yani MDS kayıt sürecine katılmaz, yalnızca hizmeti gerekli yığına yönlendirir. Genel olarak fıçılara su dökülerek kayıt yapılmasına benzetme yapabiliriz. Her varil 256 MB'lık bir veri bloğudur.
Yani, bir disk belirli sayıda bu tür varildir, yani disk hacminin 256 MB'a bölünmesidir. Her kopya bir düğüme dağıtılır, ikincisi neredeyse başka bir düğüme paraleldir, vb. Üç kopyamız varsa ve önbellek için SSD disklerimiz varsa (günlükleri okumak ve yazmak için), yazmanın onayı yazdıktan sonra gerçekleşir. SSD'ye günlük kaydı ve SSD'den paralel sıfırlama, sanki arka plandaymış gibi HDD'de devam edecektir. Üç kopya olması durumunda kayıt, üçüncü düğümün SSD'sinden onay alındıktan sonra gerçekleştirilecektir. Üç SSD'nin yazma hızının toplamı üçe bölünebilir ve bir kopyanın yazma hızını elde edeceğiz gibi görünebilir, ancak kopyalar paralel olarak yazılır ve ağ Gecikme hızı genellikle SSD'ninkinden daha yüksektir, ve aslında yazma performansı ağa bağlı olacaktır. Bu bakımdan gerçek IOPS'yi görebilmek için Vstorage'ın tamamını doğru bir şekilde yüklemeniz gerekir. yani, doğru veri bloğu boyutunu, iş parçacığı sayısını vb. dikkate almanın gerekli olduğu bellek ve önbellek yerine gerçek yükü test etmek.
Yukarıda belirtilen SSD'deki kayıt günlüğü, veri içine girer girmez servis tarafından hemen okunacak ve HDD'ye yazılacak şekilde çalışır. Küme başına birkaç meta veri hizmeti (MDS) vardır ve bunların sayısı, Paxos algoritmasına göre çalışan bir çekirdek tarafından belirlenir. İstemci açısından bakıldığında, FUSE bağlama noktası, kümedeki tüm düğümler tarafından aynı anda görülebilen bir küme depolama klasörüdür, her düğümün bu prensibe göre monte edilmiş bir istemcisi vardır, dolayısıyla bu depolama her düğüm tarafından kullanılabilir.
Yukarıda açıklanan yaklaşımlardan herhangi birinin performansı için, planlama ve dağıtım aşamasında, toplama nedeniyle dengelemenin olacağı ve ağ kanalı bant genişliğinin doğru seçileceği ağın doğru şekilde yapılandırılması çok önemlidir. Toplama açısından doğru karma modunu ve çerçeve boyutlarını seçmek önemlidir. Yukarıda açıklanan SDS'den de çok güçlü bir fark var; bu, Virtuozzo Storage'daki hızlı yol teknolojisiyle sigortalanıyor. Modernize edilmiş sigortaya ek olarak, diğer açık kaynaklı çözümlerden farklı olarak IOPS'yi önemli ölçüde artırır ve yatay veya dikey ölçeklendirmeyle sınırlı kalmanıza izin vermez. Genel olarak yukarıda açıklanan mimarilerle karşılaştırıldığında bu daha güçlü görünüyor, ancak böyle bir zevk için elbette Ceph ve Gluster'ın aksine lisans satın almanız gerekiyor.
Özetlemek gerekirse, üçünün en tepesini öne çıkarabiliriz: Mimarinin performansı ve güvenilirliği açısından Virtuozzo Storage birinci sırada, Ceph ikinci sırada ve Gluster üçüncü sırada yer alıyor.
Virtuozzo Storage'ın seçildiği kriterler: hızlı yol ile bu Fuse yaklaşımı için modernize edilmiş, esnek bir donanım konfigürasyonları seti, daha az kaynak tüketimi ve bilgi işlemle paylaşma yeteneği (bilgi işlem/sanallaştırma), yani kendisinin de parçası olduğu hiper-yakınsak çözüme tamamen uygundur. İkinci sırada ise Bloklar halinde çalışması, senaryoların daha esnek olması ve daha büyük kümeler halinde çalışabilmesi nedeniyle Gluster'a göre daha verimli bir mimari olması nedeniyle Ceph yer alıyor.
VSAN, Space Direct Storage, Vstorage ve Nutanix Storage arasında bir karşılaştırma yazma, Vstorage'ı HPE ve Huawei ekipmanlarında test etme ve Vstorage'ı harici donanım depolama sistemleriyle entegre etme senaryoları yazma planları var; bu nedenle makaleyi beğendiyseniz, Yorumlarınızı ve dileklerinizi dikkate alarak yeni yazılar için motivasyonunuzu artırabilecek geri bildirimler almak güzel.
Kaynak: habr.com