HPC PixStor Depolaması için Dell EMC Ready Çözümü (İngilizce)

Makale, HPC ve AI Innovation Lab bünyesinden Mario Gallegos tarafından Ekim 2019'da yazılmıştır

İçindekiler

1. Giriş
   1. Çözüm Mimarisi
   2. Çözüm Bileşenleri
2. Performans Karakterizasyonu
   1. Sıralı IOzone Performansı N dosyaya N istemci
   2. Sıralı IOR Performansı N istemciden 1 dosyaya
   3. Rastgele küçük bloklar IOzone Performansı N istemciden N dosyaya
   4. Boş dosyaları kullanarak MDtest ile meta veri performansı
   5. MDtest ile 4 KiB dosya kullanarak meta veri performansı
   6. 3K dosyalarla MDtest kullanarak Meta Veri Performansı
3. Gelişmiş Analizler
4. Sonuç ve Gelecekteki Çalışmalar

Giriş

Çözüm Mimarisi

Çözüm Bileşenleri

Performans Karakterizasyonu

•     IOzone N'den N'ye sıralı
•     IOR N'den 1'e sıralı
•     IOzone rastgele
•     MDtest
  
  Yukarıda listelenen tüm kıyaslamalar için, test yatağı aşağıdaki Tablo 2'de açıklandığı gibi istemcilere sahipti. Test için kullanılabilen hesaplama düğümü sayısı 16 olduğundan, daha fazla sayıda iş parçacığı gerektiğinde, bu iş parçacıkları hesaplama düğümlerine eşit olarak dağıtılmıştır (yani 32 iş parçacığı = düğüm başına 2 iş parçacığı, 64 iş parçacığı = düğüm başına 4 iş parçacığı, 128 iş parçacığı = düğüm başına 8 iş parçacığı, 256 iş parçacığı = düğüm başına 16 iş parçacığı, 512 iş parçacığı = düğüm başına 32 iş parçacığı, 1024 iş parçacığı = düğüm başına 64 iş parçacığı). Buradaki amaç, sınırlı sayıda bilgi işlem düğümüyle daha fazla sayıda eş zamanlı istemciyi simüle etmekti. Karşılaştırmalar çok sayıda iş parçacığını desteklediğinden, aşırı bağlam değiştirme ve diğer ilgili yan etkilerin performans sonuçlarını etkilemesinden kaçınılırken, 1024'e kadar maksimum değer kullanıldı (her test için belirtilmiştir).
  
  Tablo 2 İstemci test yatağı

  İstemci düğüm sayısı	16
  İstemci düğüm	C6320
  İstemci düğüm başına işlemci	2 x Intel(R) Xeon(R) Gold E5-2697v4 18 Çekirdek (2,30 GHz)
  İstemci düğümü başına bellek	12 x 16 GiB 2400 MT/sn RDIMM
  BIOS	2.8.0
  İşletim Sistemi Çekirdeği	3.10.0-957.10.1
  GPFS sürümü	5.0.3

   

  ---

  Sıralı IOzone Performansı N dosyaya N istemci

  Sıralı N istemciden N dosyaya performans, IOzone sürüm 3.487 ile ölçülmüştür. Gerçekleştirilen testler, tek bir iş parçacığından 1024 iş parçacığına kadar değişiklik gösterdi. 
  GPFS sayfa havuzu 16 GiB olarak ayarlanarak ve bu boyutun iki katından daha büyük dosyalar kullanılarak önbelleğe alma etkileri en aza indirilmiştir. Ayarlanabilir GPFS için, yüklü ve boş RAM miktarından bağımsız olarak verileri önbelleğe almak için kullanılan maksimum bellek miktarını ayarladığını unutmamak önemlidir. Ayrıca, önceki Dell EMC HPC çözümlerinde büyük sıralı aktarımlarda blok boyutunun 1 MiB olmasına karşın GPFS'nin 8 MiB'lik bloklarla biçimlendirilmiş olması ve bu nedenle bu değerin optimum performans için karşılaştırmada kullanılmasıdır. Bu çok büyük görünebilir ve çok fazla alanın boşa gitmesine yol açabilir. Ancak GPFS bu durumu önlemek için alt blok tahsisi kullanır. Mevcut yapılandırmada, her blok, her biri 32 KiB'lik 256 alt bloğa bölünmüştür. 
  Yazma ve okuma ölçütünü yürütmek için aşağıdaki komutlar kullanıldı; burada İş Parçacıkları, kullanılan iş parçacığı sayısına sahip değişkendi (ikinin katları olarak 1'den 1024'e kadar artırıldı) ve iş parçacığı, her iş parçacığını farklı bir düğüme tahsis eden dosyaydı ve bunları 16 hesaplama düğümüne homojen bir şekilde yaymak için çevrimsel sıralı olarak kullanıldı.

  ./iozone -i0 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist
  ./iozone -i1 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist

  
  Şekil 2:  N'den N'ye sıralı performans
  
  
  Sonuçlardan performansın kullanılan istemci sayısıyla çok hızlı arttığını ve ardından IOzone'un izin verdiği maksimum iş parçacığı sayısına ulaşılana kadar kararlı bir platoya ulaştığını ve bu nedenle büyük dosya sıralı performansının 1024 eşzamanlı istemci için bile kararlı olduğunu gözlemleyebiliriz. Maksimum okuma performansının 32 iş parçacığında 23 GB/sn olduğuna ve büyük olasılıkla performans sorununun InfiniBand EDR arabirimi olduğuna ve ME4 dizilerinin hala bazı ekstra performansa sahip olduğuna dikkat edin. Benzer şekilde, 16.7'lik maksimum yazma performansına 16 iş parçacığında biraz erken ulaşıldığına ve ME4 dizilerinin özelliklerine kıyasla görünüşte düşük olduğuna dikkat edin.
  Burada, GPFS'nin tercih ettiği çalışma modunun dağınık olduğunu ve çözümün onu kullanacak şekilde biçimlendirildiğini hatırlamak önemlidir. Bu modda, bloklar en baştan sözde rastgele bir şekilde tahsis edilir ve verileri her HDD'nin tüm yüzeyine yayar. Bu yöntemin dezavantajı, başlangıçtaki maksimum performansın daha düşük olması olsa da dosya sisteminde ne kadar alan kullanıldığına bakılmaksızın bu performans büyük oranda sabit tutulur. Bu durum, başlangıçta disk devri başına daha fazla veri (sektör) tutabilen ve bu nedenle HDD'lerin sağlayabileceği en yüksek performansa sahip olan dış izleri kullanan diğer paralel dosya sistemleriyle çelişir. Ancak sistem daha fazla alan kullandıkça devir başına daha az veri içeren iç izler kullanılır ve sonuç olarak performans düşer. 
  
   

  ---

  Sıralı IOR Performansı N istemciden 1 dosyaya

  Sıralı N istemciden tek bir paylaşılan dosyaya performans, 16 bilgi işlem düğümü üzerinde kıyaslamayı çalıştırmak için OpenMPI v4.0.1 tarafından desteklenen IOR sürüm 3.3.0 ile ölçülmüştür. Gerçekleştirilen testler, tek iş parçacığından 1024 iş parçacığına kadar değişiyordu.
  GPFS sayfa havuzu 16 GiB olarak ayarlanarak ve bu boyutun iki katından daha büyük dosyalar kullanılarak önbelleğe alma etkileri en aza indirilmiştir. Bu kıyaslama testlerinde optimum performans için 8 MiB bloklar kullanılmıştır. Önceki performans testi bölümünde bu konular için daha eksiksiz bir açıklama vardır. 
  Yazma ve okuma işlemleri için kıyaslamayı yürütmek üzere aşağıdaki komutlar kullanılmıştır; burada İş Parçacıkları, kullanılan iş parçacığı sayısına sahip değişkendir (ikinin katları olarak 1'den 1024'e kadar artırılmıştır) ve my_hosts.$Threads, her iş parçacığını farklı bir düğüme ayıran karşılık gelen dosyadır ve bunları 16 hesaplama düğümüne homojen bir şekilde yaymak için çevrimsel sıralı kullanılır.

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b 128G 

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b 128G

  
  
  Şekil 3: N ila 1 Sıralı Performans
  
  Sonuçlardan performansın kullanılan istemci sayısıyla birlikte çok hızlı bir şekilde tekrar yükseldiğini ve ardından bu testte kullanılan maksimum iş parçacığı sayısına kadar okumalar için yarı kararlı ve yazmalar için çok kararlı bir platoya ulaştığını gözlemleyebiliriz. Bu nedenle, büyük tek paylaşılan dosya sıralı performansı, 1024 eşzamanlı istemci için bile sabittir. Maksimum okuma performansının 16 iş parçacığında 23,7 GB/sn olduğuna ve büyük olasılıkla performans sorununun InfiniBand EDR arabirimi olduğuna ve ME4 dizilerinin hala bazı ekstra performansa sahip olduğuna dikkat edin. Ayrıca, okuma performansı bu değerden yaklaşık 20,5 GB/sn'de platoya ulaşana kadar düştü ve 128 iş parçacığında 18,5 GB/sn'ye anlık bir düşüş yaşadı. Benzer şekilde, maksimum yazma performansı olan 16,5'e 16 iş parçacığında ulaşıldığına ve ME4 dizilerinin özelliklerine kıyasla görünüşte düşük olduğuna dikkat edin.
   

  ---

  Rastgele küçük bloklar IOzone Performansı N istemciden N dosyaya

  N dosyaya rastgele N istemcinin performansı IOzone sürüm 3.487 ile ölçülmüştür. Gerçekleştirilen testler, tek iş parçacığından 1024 iş parçacığına kadar değişiyordu. Bu kıyaslama testleri, küçük blok trafiğini taklit etmek için 4 KiB blokları kullandı.
  GPFS sayfa havuzu ayarlanabilir olarak 16 GiB ye ayarlanarak ve dosyalar bu boyutun iki katı kullanılarak önbelleğe alma etkileri en aza indirildi. İlk performans testi bölümünde bunun GPFS üzerinde neden etkili olduğu hakkında daha kapsamlı bir açıklama mevcuttur. 
  Aşağıdaki komut, karşılaştırmayı hem yazma hem de okuma işlemleri için rastgele GÇ modunda yürütmek için kullanıldı, burada İş Parçacıkları kullanılan iş parçacığı sayısına sahip değişkendi (ikinin katları olarak 1'den 1024'e kadar artırıldı) ve iş parçacığı listesi, her iş parçacığını 16 hesaplama düğümüne homojen bir şekilde yaymak için çevrimsel sıralı kullanarak her bir iş parçacığını farklı bir düğüme ayıran dosyaydı.

  ./iozone -i2 -c -O -w -r 4K -s 32G -t $Threads -+n -+m ./threadlist

  
  Şekil 4:  N'den N'ye Rastgele Performans
  
  Sonuçlardan yazma performansının neredeyse 8,2 bin IOPS gibi yüksek bir değerde başladığını ve 128 iş parçacığına kadar istikrarlı bir şekilde yükseldiğini ve burada bir platoya ulaştığını ve maksimum 16,2K IOPS değerine yakın kaldığını gözlemleyebiliriz. Öte yandan okuma performansı 200 IOPS'nin üzerinde çok küçük bir performansla başlar ve kullanılan istemci sayısıyla performansı neredeyse doğrusal olarak artırır (her veri noktası için iş parçacığı sayısının iki katına çıktığını unutmayın) ve maksimuma ulaşma belirtisi olmadan 512 iş parçacığında maksimum 20,4K IOPS performansına ulaşır. Ancak, her biri iki CPU'ya sahip olan ve her CPU'nun 18 çekirdeğe sahip olduğu mevcut 16 bilgi işlem düğümünde daha fazla iş parçacığı kullanmak, performansı önemli ölçüde sınırlayan bağlam anahtarlamasına (16 x 2 x 18 = 576 çekirdek) neden olmadan maksimum IOzone iş parçacığı sayısını (1024) çalıştırmak için yeterli çekirdek olmaması sınırlamasına sahiptir. Daha fazla bilgi işlem düğümüyle gelecekte yapılacak bir test, IOzone ile 1024 iş parçacığı ile hangi rastgele okuma performansının elde edilebileceğini kontrol edebilir veya IOR, 1024'ten fazla iş parçacığı içeren davranışı araştırmak için kullanılabilir.
  
   

  ---

  Boş dosyaları kullanarak MDtest ile meta veri performansı

  Meta veri performansı, 16 bilgi işlem düğümü üzerinde kıyaslamayı çalıştırmak için OpenMPI v4.0.1 tarafından desteklenen MDtest sürüm 3.3.0 ile ölçülmüştür. Yapılan testler tek iş parçacığından 512 iş parçacığına kadar farklılık göstermiştir. Karşılaştırma testi yalnızca dosyalar için kullanıldı (dizin meta verisi yok), çözümün işleyebileceği oluşturma, istatistik, okuma ve kaldırma sayısını alıyor.
  Çözümü diğer Dell EMC HPC depolama çözümleriyle karşılaştırmalı olarak doğru bir şekilde değerlendirmek için isteğe bağlı Yüksek Talep Meta Veri Modülü kullanıldı ancak tek bir ME4024 dizisiyle, bu çalışmada test edilen büyük yapılandırma ve test edilen modelde bile iki ME4024 olduğu belirlendi. 
  Bu Yüksek Talepli Meta Veri Modülü dört adede kadar ME4024 dizisini destekleyebilir ve başka bir meta veri modülü eklemeden önce ME4024 dizilerinin sayısının 4'e çıkarılması önerilir. Ek ME4024 dizilerinin, Stat işlemleri (ve boş dosyalar için Okumalar) dışında, her ek diziyle birlikte Meta Veri performansını doğrusal olarak artırması beklenir, çünkü sayılar çok yüksektir, çünkü bir noktada CPU'lar bir darboğaz haline gelir ve performans doğrusal olarak artmaya devam etmez.
  Kıyaslamayı gerçekleştirmek için aşağıdaki komut kullanıldı. Threads, kullanılan iş parçacığı sayısını (ikinin kuvvetleriyle artarak 1 ila 512) içeren değişken ve my_hosts.$Threads her iş parçacığını farklı bir düğüme tahsis eden dosyadır. Bunları 16 bilgi işlem düğümüne homojen şekilde yaymak için round robin (çevrimsel sıralı) kullanıldı. Rastgele G/Ç kıyaslamasına benzer şekilde maksimum iş parçacığı sayısı 512 ile sınırlandırıldı çünkü 1024 iş parçacığı için yeterli çekirdek yoktu. Ayrıca bağlam değiştirme, sonuçları etkileyerek çözümün gerçek performansından daha düşük bir sayı bildirecektir.

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F

  
  Performans sonuçları toplam IOP sayısından, dizin başına dosya sayısından ve iş parçacığı sayısından etkilenebileceğinden, toplam dosya sayısının 2 MiB dosyasına (2^21 = 2097152), dizin başına dosya sayısının 1024'te sabitlenmesine ve Tablo 3'te gösterildiği gibi iş parçacığı sayısı değiştikçe dizin sayısının değişmesine karar verildi.
  
  Tablo 3:  MDdizinlerdeki dosyaların test dağıtımı

  İş Parçacığı sayısı	İş parçacığı başına dizin sayısı	Toplam dosya sayısı
  1	2048	2.097.152
  2	1024	2.097.152
  4	512	2.097.152
  8	256	2.097.152
  16	128	2.097.152
  32	64	2.097.152
  64	32	2.097.152
  128	16	2.097.152
  256	8	2.097.152
  512	4	2.097.152
  1024	2	2.097.152

  
  
  
  
  Şekil 5: Meta Veri Performansı - Boş Dosyalar
  
  İlk olarak, seçilen ölçeğin 10 tabanlı logaritmik olduğuna dikkat edin, bu da birkaç büyüklük sırasına göre farklılıkları olan işlemlerin karşılaştırılmasına izin verir; Aksi takdirde, bazı işlemler normal bir grafikte 0'a yakın düz bir çizgi gibi görünecektir. İş parçacığı sayısı 2'nin katlarında artırıldığından, 2 tabanlı bir günlük grafiği daha uygun olabilir, ancak grafik oldukça benzer görünecektir ve insanlar 10'un kuvvetlerine dayalı olarak daha iyi sayıları işleme ve hatırlama eğilimindedir.
  
  
  Sistem, sırasıyla 11,2 milyon işlem/sn ve 4,8 milyon işlem/sn ile 64 iş parçacığında en yüksek değerine ulaşan İstatistik ve Okuma işlemleriyle çok iyi sonuçlar elde ediyor. Kaldırma işlemleri 16 iş parçacığında maksimum 169,4K işlem/sn'ye ulaştı ve Oluşturma işlemleri 194,2K işlem/sn ile 512 iş parçacığında zirveye ulaştı. İstatistik ve Okuma işlemleri daha fazla değişkenliğe sahiptir. Ancak en yüksek değerlerine ulaştıklarında performans, İstatistik için 3 milyon işlem/sn ve Okumalar için 2 milyon işlem/sn'nin altına düşmez. Oluşturma ve Kaldırma, bir platoya ulaştıklarında ve Kaldırma için 140K işlem/sn'nin ve Oluşturma için 120K işlem/sn'nin üzerinde kaldıklarında daha kararlıdır.
   

  ---

  MDtest ile 4 KiB dosya kullanarak meta veri performansı

  Bu test bir öncekiyle neredeyse aynıdır ancak boş dosyalar yerine 4 KiB boyutunda küçük dosyalar kullanılmıştır. 
  Kıyaslamayı gerçekleştirmek için aşağıdaki komut kullanıldı. Threads, kullanılan iş parçacığı sayısını (ikinin kuvvetleriyle artarak 1 ila 512) içeren değişken ve my_hosts.$Threads her iş parçacığını farklı bir düğüme tahsis eden dosyadır. Bunları 16 bilgi işlem düğümüne homojen şekilde yaymak için round robin (çevrimsel sıralı) kullanıldı.

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K

  
  Şekil 6:  Meta Veri Performansı - Küçük dosyalar (4K)
  
  Sistem, Stat ve Removal işlemleri için çok iyi sonuçlar alıyor ve sırasıyla 7,7 M op/s ve 1 M op/s ile 128 iş parçacığında en yüksek değerlerine ulaşıyor. Kaldırma işlemleri maksimum 37,3 bin işlem/sn'ye ulaşırken, Oluşturma işlemleri her ikisi de 512 iş parçacığında 55,5 bin işlem/sn ile zirveye ulaştı. İstatistik ve Kaldırma işlemleri daha fazla değişkenliğe sahiptir, ancak en yüksek değerlerine ulaştıklarında performans, İstatistikler için 4 milyon işlem/sn'nin ve Kaldırma için 200 bin işlem/sn'nin altına düşmez. Oluşturma ve Okuma daha az değişkenliğe sahiptir ve iş parçacığı sayısı arttıkça artmaya devam eder.
  Bu sayılar tek bir ME4024 içeren bir meta veri modülü için olduğundan, her ek ME4024 dizisi için performans artacaktır, ancak her işlem için yalnızca doğrusal bir artış olduğunu varsayamayız. Tüm dosya bu tür bir dosya için inode içine sığmadığı sürece ME4084'lerdeki veri hedefleri 4 K dosyaları depolamak için kullanılacak ve performansı bir dereceye kadar sınırlayacaktır. Inode boyutu 4 KiB olduğundan ve meta veri depolaması gerektiğinden, yalnızca 3 KiB civarındaki dosyaları alabilecek ve bundan büyük herhangi bir dosya veri hedeflerini kullanacaktır.
   

  ---

  3K dosyalarla MDtest kullanarak Meta Veri Performansı

  Bu test, 3KiB'lik küçük dosyaların kullanılması dışında, öncekilerle neredeyse tamamen aynıdır. Temel fark, bu dosyaların inode'un içine tamamen sığmasıdır. Bu nedenle, depolama düğümleri ve ME4084'leri kullanılmaz; depolama için yalnızca SSD ortamı ve daha az ağ erişimi kullanarak genel hızı artırır. 
  Kıyaslamayı gerçekleştirmek için aşağıdaki komut kullanıldı. Threads, kullanılan iş parçacığı sayısını (ikinin kuvvetleriyle artarak 1 ila 512) içeren değişken ve my_hosts.$Threads her iş parçacığını farklı bir düğüme tahsis eden dosyadır. Bunları 16 bilgi işlem düğümüne homojen şekilde yaymak için round robin (çevrimsel sıralı) kullanıldı.

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 3K -e 3K

   

  
  Şekil 7: Meta Veri Performansı - Küçük dosyalar (3K)
  
  Sistem, sırasıyla 8,29 milyon işlem/sn ve 5,06 milyon işlem/sn ile 256 iş parçacığında en yüksek değerine ulaşan İstatistik ve Okuma işlemleri için çok iyi sonuçlar alır. Kaldırma işlemleri 128 iş parçacığında maksimum 609 bin işlem/sn'ye ulaştı ve oluşturma işlemleri 512 iş parçacığında 78 bin işlem/sn ile zirveye ulaştı. Stat ve Read işlemleri, Oluşturma ve Kaldırma'dan daha fazla değişkenliğe sahiptir. Çıkarma, iki yüksek iş parçacığı noktası için performansta küçük bir düşüşe neden olur, bu da 128 iş parçacığından sonra devam eden performansın 400K op/s'nin biraz üzerinde olacağını düşündürür. Oluşturur 512 iş parçacığına kadar artmaya devam etti, ancak bir platoya ulaşıyor gibi görünüyor, bu nedenle maksimum performans hala 100K op/s'nin altında olabilir.
  Bunun gibi küçük dosyalar tamamen SSD tabanlı meta veri modülünde depolandığından, üstün küçük dosya performansı gerektiren uygulamalar, küçük dosyaların performansını artırmak için bir veya daha fazla isteğe bağlı yüksek talep meta verisi modülü kullanabilir. Ancak, inode'a uyan dosyalar mevcut standartlara göre küçüktür. Ayrıca meta verisi hedefleri, SSD'leri nispeten küçük (maksimum boyut 19,2 TB) olan RAID1'leri kullandığından, depolama düğümleriyle karşılaştırıldığında kapasite sınırlı olacaktır. Bu nedenle, gereksiz arızalara ve diğer sorunlara neden olabilecek Meta Veri hedeflerini doldurmaktan kaçınmak için dikkatli olunmalıdır.
   

  ---

  Gelişmiş Analizler

  PixStor'un yetenekleri arasında, gelişmiş analitik yoluyla dosya sistemini izlemek, yönetimi büyük ölçüde basitleştirmek, sorunları veya olası sorunları proaktif veya reaktif olarak bulmaya yardımcı olmak için gerekli olabilir. Ardından, bu yeteneklerden bazılarını kısaca gözden geçireceğiz.
  Şekil 8'de dosya sistemi kapasitesine dayalı yararlı bilgiler gösterilmektedir. Sol tarafta, kullanılan dosya sistemi toplam alanı ve kullanılan dosya sistemi kapasitesine göre ilk on kullanıcı. Sağ tarafta, pareto grafiklerine benzer bir biçimde (kümülatif toplamlar için satırlar olmadan) her ikisi de kullanılan kapasiteye dayalı olarak uzun yıllar boyunca kullanılan kapasitenin yer aldığı geçmiş görünümü, ardından kullanılan ilk on dosya türü ve ilk on dosya kümesi yer alır. Bu bilgilerle, kullanıcıların dosya sisteminden paylarına düşenden daha fazlasını elde ettiklerini, kapasitenin gelecekteki büyümesine ilişkin kararlara yardımcı olmak için kapasite kullanım eğilimlerini, alanın çoğunu hangi dosyaların kullandığını veya hangi projelerin kapasitenin çoğunu aldığını bulmak kolay olabilir.
  
  
  Şekil 8:  PixStor Analytics - Kapasite görünümü
  
  Şekil 9, sorunları bulmak için çok kullanışlı iki yol içeren bir dosya sayısı görünümü sağlar. Ekranın ilk yarısında, tümü dosya sayısına bağlı olarak, bir pasta grafikte ilk on kullanıcı ve ilk on dosya türü ve ilk on dosya kümesi (projeleri düşünün) pareto grafiklerine benzer bir biçimde (kümülatif toplamlar için çizgiler olmadan) bulunur. Bu bilgiler bazı önemli soruları yanıtlamak için kullanılabilir. Örneğin, çok fazla dosya oluşturarak dosya sistemini tekeline alan kullanıcılar, meta veri kabusu yaratan dosya türü veya kaynakların çoğunu hangi projeler kullanıyor.
  Alt yarı, farklı dosya boyutları için 5 kategori kullanan dosya boyutları için dosya sayısını (sıklığı) içeren bir histograma sahiptir. Bu, dosya sistemi genelinde kullanılan dosya boyutları hakkında bir fikir edinmek için kullanılabilir ve dosya türleriyle koordineli olarak sıkıştırmanın yararlı olup olmayacağına karar vermek için kullanılabilir.
  
  
  Şekil 9:  PixStor Analytics - Dosya sayısı görünümü

  
  
   

  ---

  Sonuç ve Gelecekteki Çalışmalar

  Mevcut çözüm, Tablo 4'te görülebileceği gibi, kullanılan alandan bağımsız olarak (sistem dağınık modda biçimlendirildiğinden) kararlı olması beklenen oldukça iyi bir performans sunabildi. Ayrıca daha fazla depolama düğümü modülü eklendikçe çözüm kapasite ve performans açısından doğrusal olarak ölçeklenir ve isteğe bağlı yüksek talepli meta veri modülünden de benzer bir performans artışı beklenebilir. Bu çözüm, HPC müşterilerine birçok İlk 500 HPC kümesi tarafından kullanılan çok güvenilir bir paralel dosya sistemi sağlar. Buna ek olarak, olağanüstü arama yetenekleri, gelişmiş izleme ve yönetim sağlar ve isteğe bağlı ağ geçitleri eklemek, NFS, SMB ve diğerleri gibi her yerde bulunan standart protokoller aracılığıyla gerektiği kadar istemciye dosya paylaşımına izin verir.
  
  Tablo 4  En Yüksek ve Sürdürülebilir Performans
  
   

  	En Yüksek Performans		Sürdürülebilir Performans
  	Yazma	Read (Okuma)	Yazma	Read (Okuma)
  Büyük Sıralı N istemciden N dosyaya	16,7 GB/sn	23 GB/sn	16,5 GB/sn	20,5 GB/sn
  Büyük Sıralı N istemciden tek bir paylaşılan dosyaya	16,5 GB/sn	23,8 GB/sn	16,2 GB/sn	20,5 GB/sn
  Rastgele Küçük bloklar N istemciden N dosyaya	15.8KIOps	20.4KIOps	15.7KIOps	20.4KIOps
  Meta Veri Oluşturma boş dosyalar	169.400 IOps		127,2K IOps
  Meta Veri İstatistik boş dosyalar	11,2 Milyon IOps		3,3 Milyon IOps
  Meta Veri Okuma boş dosyalar	4,8 Milyon IOps		2,4 Milyon IOps
  Meta Veri Kaldırma boş dosyalar	194,2K IOps		144,8K IOps
  Meta Veri Oluşturma 4 KiB dosyalar	55,4K IOps		55,4K IOps
  Meta Veri İstatistik 4 KiB dosyalar	6,4 Milyon IOps		4M IOps
  Meta Veri Okuma 4 KiB dosyalar	37,3K IOps		37,3K IOps
  Meta Veri Kaldırma 4 KiB dosyalar	1 Milyon IOps		219,5K IOps

  
  
  Çözümün Cascade Lake CPU'lar ve daha hızlı RAM ile piyasaya sürülmesi planlandığından sistem, nihai yapılandırmaya sahip olduğunda bazı performans kontrolleri yapılacaktır. Veri hedefleri söz konusu olduğunda meta veri performansının nasıl ölçeklendiğini daha iyi belgelendirmek için isteğe bağlı Yüksek Talepli Meta Veri Modülünün en az 2x ME4024 ve 4 KiB dosyalarla test edilmesi gerekmektedir. Buna ek olarak, ağ geçidi düğümlerinin performansı ölçülecek ve kontrollerden elde edilen ilgili sonuçlarla birlikte yeni bir blog yazısında veya teknik raporda rapor edilecektir. Son olarak, daha fazla özellik sağlamak için daha fazla çözüm bileşeninin test edilmesi ve piyasaya sürülmesi planlanmaktadır.

  ---