Yukarıda listelenen tüm kıyaslama ölçütleri için test ortamında aşağıdaki Tablo 2'de açıklanan istemciler mevcuttu. Test için mevcut bilgi işlem düğümü sayısı yalnızca 16 olduğundan daha yüksek sayıda iş parçacığı gerektiğinde bu iş parçacıkları, bilgi işlem düğümlerine eşit olarak dağıtılmıştır (ör. 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. Bazı kıyaslama ölçütleri yüksek 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ı etkilemesi önlenirken 1024'e kadar maksimum değer kullanılmıştır (her test için belirtilmiştir).

Tablo 2 İstemci test ortamı

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 iş parçacığından 1024 iş parçacığına kadar ikinin katları şeklinde artışlarla değişiklik göstermiştir.

GPFS sayfa havuzu 16 GiB olarak ayarlanarak ve bu boyutun iki katından daha büyük dosyalar kullanılarak sunuculardaki önbelleğe alma etkileri en aza indirilmiştir. GPFS için bu belirlenebilecek ayarın, yüklü ve boş RAM miktarına bakılmaksızın 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ımlar için blok boyutu 1 MiB'ydi. GPFS'nin 8 MiB bloklarla biçimlendirildiğini ve bu nedenle optimum performans için kıyaslamada bu değerin kullanıldığını göz önünde bulundurmak önemlidir. 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.

Kıyaslamayı gerçekleştirmek için aşağıdaki komut kullanılmıştır. Burada $Threads, kullanılan iş parçacığı sayısını (ikinin kuvvetleriyle artarak 1 ila 1024) içeren değişken ve threadlist, her bir iş parçacığını farklı bir düğüme tahsis eden dosyadır. Bunları 16 bilgi işlem düğümüne homojen şekilde dağıtmak için çevrimsel sıralı kullanılmıştır.

İstemcilerden gelebilecek olası veri önbelleğe alma etkilerinden kaçınmak için dosyaların toplam veri boyutu, kullanılan istemcilerdeki toplam RAM miktarının iki katı olmuştur. Diğer bir deyişle, her istemci 128 GiB RAM'e sahip olduğundan, 16 veya daha fazla sayıda iş parçacığı için dosya boyutu 4096 GiB olup iş parçacığı sayısına bölünerek elde edilmiştir (aşağıdaki $Size değişkeni, bu değeri yönetmek için kullanılmıştır). 16'dan az iş parçacığı olan durumlarda (bu, her iş parçacığının farklı bir istemcide çalıştığı anlamına gelir), dosya boyutu istemci başına bellek miktarının iki katı veya 256 GiB olarak sabitlenmiştir.

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

Şekil 2 N'den N'ye Sıralı Performans

Sonuçlardan, yazma performansının kullanılan iş parçacığı sayısıyla arttığını ve ardından yazma işlemleri için yaklaşık 64 iş parçacığı ve okuma işlemleri için 128 iş parçacığı ile bir platoya ulaştığını gözlemleyebiliriz. Ardından okuma performansı da iş parçacığı sayısıyla birlikte hızla artar ve ardından IOzone'un izin verdiği maksimum iş parçacığı sayısına ulaşılana kadar sabit kalır ve bu nedenle büyük dosya sıralı performansı 1024 eş zamanlı istemci için bile sabittir. Yazma performansı 1024 iş parçacığında yaklaşık %10 düşer. Ancak, istemci kümesinin çekirdek sayısı bu sayıdan az olduğundan, performans düşüşünün döner ortamda gözlemlenmeyen değiştirme ve benzeri ek yüklerden mi kaynaklandığı (NVMe gecikme süresi döner ortama kıyasla çok düşük olduğundan) yoksa RAID 10 veri senkronizasyonunun bir darboğaz haline gelmesinden mi kaynaklandığı belirsizdir. Bu noktayı açıklığa kavuşturmak için daha fazla istemci gerekir. 64 iş parçacığında okuma işlemlerinde bir anormallik gözlemlenmiştir; burada performans, önceki veri noktalarında gözlemlenen oranda ölçeklenmemiştir ve ardından bir sonraki veri noktasında, sürdürülebilir performansa çok yakın bir değere geçmiştir. Bu tür bir anormalliğin nedenini bulmak için daha fazla test gerekir ancak bu blogun kapsamı dışındadır.

Okuma işlemleri için maksimum okuma performansı, NVMe aygıtlarının teorik performansının (~102 GB/sn.) veya EDR bağlantılarının performansının altındaydı ve bu durum, bir bağlantının çoğunlukla NVMe over fabric trafiği (4x EDR BW ~96 GB/sn.) için kullanıldığı varsayıldığında bile geçerliydi.
Ancak donanım yapılandırması her CPU soketinin altındaki NVMe aygıtları ve IB HCA'lar açısından dengeli olmadığı için bu bir sürpriz değildir. CPU2'de tüm NVMe aygıtları ve ikinci CX6 adaptörleri bulunurken, bir CX6 adaptörü CPU1'in altındadır. İlk HCA'yı kullanan her türlü depolama trafiği, NVMe aygıtlarına erişmek için UPI'leri kullanmalıdır. Ayrıca CPU1'de kullanılan herhangi bir çekirdek, CPU2'ye atanan aygıtlara veya belleğe erişmelidir, bu nedenle veri yerelliği zarar görür ve UPI bağlantıları kullanılır. Bu, NVMe aygıtlarının maksimum performansına veya CX6 HCA'ların hat hızına kıyasla maksimum performanstaki düşüşü açıklayabilir. Bu sınırlamayı düzeltmenin alternatifi, dengeli bir donanım yapılandırmasına sahip olmaktır. Bu, dört x16 yuvalı bir R740 kullanarak yoğunluğu yarıya indirmek ve NVMe aygıtlarını iki CPU'ya eşit olarak dağıtmak için iki x16 PCIe genişletici kullanmak ve her CPU'nun altında bir CX6 HCA'ya sahip olmak anlamına gelir.

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. 1024 veya daha fazla iş parçacığı için yeterli çekirdek olmadığından yapılan testler, bir iş parçacığından 512 iş parçacığına kadar değişiklik göstermiştir. Bu kıyaslama testlerinde optimum performans için 8 MiB bloklar kullanılmıştır. Önceki performans testi bölümünde bunun neden önemli olduğuna dair daha eksiksiz bir açıklama bulunmaktadır.

GPFS sayfa havuzu 16 GiB olarak ayarlanarak verileri önbelleğe alma etkileri en aza indirilmiştir ve toplam dosya boyutu, kullanılan istemcilerdeki toplam RAM miktarının iki katı olmuştur. Diğer bir deyişle, her istemci 128 GiB RAM'e sahip olduğundan, 16 veya daha fazla sayıda iş parçacığı için dosya boyutu 4096 GiB'dir ve bu toplamın eşit miktarı iş parçacığı sayısına bölünmüştür (aşağıdaki $Size değişkeni bu değeri yönetmek için kullanılmıştır). 16'dan az iş parçacığı olan durumlarda (bu, her iş parçacığının farklı bir istemcide çalıştığı anlamına gelir), dosya boyutu istemci başına kullanılan bellek miktarının iki katı ile iş parçacığı sayısının çarpımı kadar olmuştur veya başka bir deyişle, her iş parçacığından 256 GiB kullanması istenmiştir.

Yazma ve okuma işlemlerinde kıyaslamayı gerçekleştirmek için aşağıdaki komutlar kullanılmıştır. Burada $Threads, kullanılan iş parçacığı sayısını (ikinin kuvvetleriyle artarak 1 ila 1024) 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 çevrimsel sıralı kullanılmıştı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 $ G

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 $ G

Şekil 3 N'den 1'e Sıralı Performans

Sonuçlardan, tüm iş parçacıkları aynı dosyaya eriştiğinden, kilitleme mekanizmalarına yönelik dolaylı ihtiyaçtan bağımsız olarak okuma ve yazma performansının yüksek olduğunu gözlemleyebiliriz. Performans, kullanılan iş parçacığı sayısıyla birlikte yine çok hızlı şekilde artmakta ve ardından bu testte kullanılan maksimum iş parçacığı sayısına kadar okuma ve yazma işlemleri için oldukça istikrarlı bir platoya ulaşmaktadır. Maksimum okuma performansının 512 iş parçacığında 51,6 GB/sn. olduğuna ancak performanstaki platoya yaklaşık 64 iş parçacığında ulaşıldığına dikkat edin. Benzer şekilde, 16 iş parçacığında 34,5 GB/sn. maksimum yazma performansına ulaşıldığına ve kullanılan maksimum iş parçacığı sayısına kadar gözlemlenebilen bir platoya ulaşıldığına dikkat edin.

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

Rastgele N istemciden N dosyaya 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 ikinin katları şeklinde artışlarla değişiklik göstermiştir.

1024 iş parçacığı için yeterli istemci çekirdeği olmadığından, gerçekleştirilen testler tek iş parçacığından 512 iş parçacığına kadar değişiklik göstermiştir. Her iş parçacığı farklı bir dosya kullanıyordu ve iş parçacıkları, istemci düğümlerine round robin (çevrimsel sıralı) olarak atanmıştı. Bu kıyaslama testlerinde küçük blok trafiğini simüle etmek için 4 KiB boyutunda bloklar ve 16'lık bir kuyruk derinliği kullanılmıştır. Büyük boyutlu çözümden ve kapasite genişletmesinden elde edilen sonuçlar karşılaştırılmıştır.

GPFS sayfa havuzu 16 GiB olarak ayarlanarak verileri önbelleğe alma etkileri yine en aza indirilmiştir ve istemcilerden gelebilecek olası veri önbelleğe alma etkilerinden kaçınmak için dosyaların toplam veri boyutu, kullanılan istemcilerdeki toplam RAM miktarının iki katı olmuştur. Diğer bir deyişle, her istemci 128 GiB RAM'e sahip olduğundan, 16 veya daha fazla sayıda iş parçacığı için dosya boyutu 4096 GiB olup iş parçacığı sayısına bölünerek elde edilmiştir (aşağıdaki $Size değişkeni, bu değeri yönetmek için kullanılmıştır). 16'dan az iş parçacığı olan durumlarda (bu, her iş parçacığının farklı bir istemcide çalıştığı anlamına gelir), dosya boyutu istemci başına bellek miktarının iki katı veya 256 GiB olarak sabitlenmiştir.

iozone -i0 -I -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./nvme_threadlist                                     <= Dosyaları sırayla oluşturun
iozone -i2 -I -c -O -w -r 4k -s $ G -t $Threads -+n -+m ./nvme_threadlist                                      <= Rastgele okumalar ve yazmalar gerçekleştirin.

Şekil 4 N'den N'ye Rastgele Performans

Sonuçlardan, yazma performansının 6 bin IOps gibi yüksek bir değerden başladığını ve 1024 iş parçacığına kadar istikrarlı bir şekilde yükseldiğini; bu noktada daha fazla iş parçacığı kullanılabilseydi 5 milyon IOPS'nin üzerinde bir platoya ulaşıyor gibi göründüğünü gözlemleyebiliriz. Öte yandan okuma performansı 5 bin IOPS ile başlar ve performansı kullanılan iş parçacığı sayısı ile istikrarlı şekilde artırır (her veri noktası için iş parçacığı sayısının iki katına çıkarıldığını unutmayın) ve 1024 iş parçacığında maksimum 7,3 milyon IOPS performansına ulaşır ve bir platoya ulaşma belirtisi göstermez. Daha fazla iş parçacığı kullanmak, kaynak tükenmesinden ve görünür performansı düşürebilecek aşırı değiştirme işlemlerinden kaçınmak için 16 bilgi işlem düğümünden fazlasını gerektirecektir. NVMe düğümleri ise aslında performansı koruyabilir.

MDtest ile 4 KiB dosya kullanarak 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. Kıyaslama yalnızca dosyalar için kullanılmıştır (dizin meta verileri hariç), çözümün işleyebileceği oluşturma, istatistik, okuma ve kaldırma sayıları elde edilmiştir ve sonuçlar Büyük boyutlu çözümle karşılaştırılmıştır.

Bu çalışmada test edilen büyük yapılandırma iki ME4024 içerecek şekilde tasarlanmış olmasına rağmen isteğe bağlı Yüksek Talepli Meta Veri Modülü tek ME4024 ile kullanılmıştır. Bu meta veri modülünün kullanılmasının nedeni, şu anda bu NVMe düğümlerinin yalnızca veriler için Depolama hedefleri olarak kullanılmasıdır. Bununla birlikte, düğümler veri ve meta verileri depolamak için veya aşırı meta veri talepleri gerektirdiğinde, yüksek talepli meta veri modülüne daha hızlı bir flash alternatifi olarak da kullanılabilir. Bu yapılandırmalar bu çalışmanın bir parçası olarak test edilmemiştir.

HPC PixStor Depolama çözümü için DellEMC Ready Çözümünün önceki kıyaslamalarında aynı Yüksek Talepli Meta Verileri modülü kullanıldığından, meta veri sonuçları önceki blog sonuçlarına kıyasla çok benzer olacaktır. Bu nedenle boş dosyalar ile çalışma yapılmamış, bunun yerine 4 KiB dosya kullanılmıştır. 4KiB dosya, meta veri bilgileriyle birlikte bir düğüme sığamayacağından, her dosya için verileri depolamak üzere NVMe düğümleri kullanılır. Bu nedenle, MDtest okumalar ve meta veri işlemlerinin geri kalanı için küçük dosyaların performansı hakkında kabaca bir fikir verebilir.

Kıyaslamayı gerçekleştirmek için aşağıdaki komut kullanılmıştır. $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 çevrimsel sıralı kullanılmıştır. 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 -w 4K -e 4K

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 dosyada (2^21 = 2097152), dizin başına dosya sayısının 1024'te sabit tutulmasına karar verilmiştir ve Tablo 3'te gösterildiği üzere iş parçacığı sayısı değiştikçe dizin sayısı da değişmiştir.

Tablo 3 MDtest Dosyaların dizinlere dağılımı

Şekil 5 Meta Veri Performansı – 4 KiB Dosya

İlk olarak, seçilen ölçeğin 10 tabanlı logaritmik olduğuna dikkat edin. Böylece birkaç büyüklük düzeyinde farkları olan işlemlerin karşılaştırılması mümkün olacaktır. Aksi takdirde bazı işlemler doğrusal bir ölçekte 0'a yakın düz bir çizgi gibi görünecektir. İş parçacığı sayısı 2'nin kuvvetlerinde arttığı için 2 tabanlı bir logaritma grafiği daha uygun olabilirdi. Ancak grafik çok benzer görünecekti ve insanlar 10'un kuvvetlerine dayalı sayıları daha iyi işleme ve hatırlama eğilimindedir.

Sistem, daha önce bildirildiği gibi İstatistik işlemlerinin neredeyse 6,9 milyon işlem/sn. ile 64 iş parçacığında en yüksek değere ulaşmasıyla çok iyi sonuçlar almaktadır ve ardından daha yüksek iş parçacığı sayılarında azalarak bir platoya ulaşmaktadır. Oluşturma işlemleri 512 iş parçacığında maksimum 113 bin işlem/sn.ye ulaşır; bu nedenle daha fazla istemci düğümü (ve çekirdek) kullanılırsa artmaya devam etmesi beklenir. Okuma ve Kaldırma işlemleri, 128 iş parçacığında maksimum değerine ulaşarak Okuma işlemleri için neredeyse 705 bin işlem/sn. ve kaldırma işlemleri için 370 bin işlem/sn. ile zirveye ve ardından platolara ulaşmıştır. İstatistik işlemleri daha fazla değişkenliğe sahiptir. Ancak en yüksek değerlerine ulaştıklarında performans, İstatistik için 3,2 milyon işlem/sn.nin altına düşmez. Oluşturma ve Kaldırma işlemleri bir platoya ulaştığında daha istikrarlıdır ve Kaldırma için 265 bin işlem/sn.nin, Oluşturma için 113 bin işlem/sn.nin üzerinde kalır. Son olarak, okuma işlemleri 265 bin işlem/sn.nin üzerinde performansla bir platoya ulaşır.

Sonuç ve Gelecekteki Çalışmalar

NVMe düğümleri; iyi yoğunluk, çok yüksek rastgele erişim performansı ve çok yüksek sıralı performans ile çok yüksek performanslı bir katman sağlamak için HPC depolama çözümüne önemli bir ektir. Ayrıca daha fazla NVMe düğüm modülü eklendikçe çözüm, kapasite ve performans açısından doğrusal olarak ölçeklenir. NVMe düğümlerinin performansı Tablo 4'te özetlenmiştir. Performansın istikrarlı olması beklenmektedir ve bu değerler farklı sayıda NVMe düğümünün performansını tahmin etmek için kullanılabilir.
Ancak her NVMe düğümü çiftinin Tablo 4'te gösterilen her sayının yarısını sağlayacağını unutmayın.
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 özellikleri, gelişmiş izleme ve yönetim sağlar. Ayrıca isteğe bağlı ağ geçitlerinin eklenmesi NFS, SMB ve benzerleri gibi her yerde bulunan standart protokoller aracılığıyla gerektiği kadar çok istemciye dosya paylaşımına izin verir.

Tablo 4: 2 Çift NVMe düğümü için En Yüksek ve Sürdürülebilir Performans

NVMe düğümleri yalnızca veriler için kullanıldığından, gelecekteki olası çalışmalar arasında bunları veri ve meta veriler için kullanmak ve RAID denetleyicilerinin arkasındaki SAS3 SSD'lere kıyasla NVMe aygıtlarının daha yüksek bant genişliği ve daha düşük gecikme süresi sayesinde daha iyi meta veri performansı sunan bağımsız bir flash tabanlı katman oluşturmak yer alabilir. Alternatif olarak, bir müşterinin aşırı yüksek meta veri talepleri varsa ve yüksek talepli meta veri modülünün sağlayabileceğinden daha yoğun bir çözüme ihtiyaç duyuyorsa dağıtılmış RAID 10 aygıtlarının bazıları veya tamamı, ME4024'lerdeki RAID 1 aygıtlarının şu anda kullanıldığı şekilde meta veriler için kullanılabilir.
Yakında yayınlanacak başka bir blog yazısında, PixStor çözümünü NFS veya SMB protokollerini kullanarak diğer ağlara bağlamaya ve performansı ölçeklendirmeye olanak tanıyan PixStor Ağ Geçidi düğümleri tanıtılacaktır. Ayrıca çözüm çok yakında HDR100'e güncelleştirilecektir ve bu çalışma hakkında başka bir blog yazısı yayınlanması beklenmektedir.