IBM COS Performans Planlaması yazımın 2. kısmına hoşgeldiniz bu sefer ufak bir yazı olacak diyebilirim. Bu yazı içerisinde network konularına ve genel olarak performans planlamasının ölçütleri hakkında bilgi vermeye çalışacağım.

Öncelikle 1. bölümü okumak isteyenler lütfen BURAYA

IBM COS Network Performansı

IBM COS ile ağ performansını optimize ederken dikkate alınması gereken kilit noktalar, jumbo frameler ve NIC birleştirmedir.

Jumbo Frame

Jumbo frame kullanımının ana avantajı, optimum ağ kullanımı ve daha yüksek verim sağlayan TCP işleme için gerekli CPU kaynak kullanımını azaltmasıdır. Jumbo frameler, standart framelerden daha büyük olduğundan, daha az frame’e ihtiyaç duyulur ve bu nedenle CPU işleme kaynağı kullanımı azalır.

Bununla birlikte, daha büyük bir frame, standart bir 1500 maksimum aktarım birimi (MTU) Ethernet frame’inden yaklaşık 6 – 7 kat daha fazla bir gecikme sağlar. Bu sorun, uygulama yanıt süresini etkileyebilir ve yüksek performanslı bilgi işlem (HPC), multimedya, video akışı, VoIP ve web hizmetleri gibi hassas uygulamalar bu gecikme nedeniyle etkilenebilir.

Jumbo frameler de tasarıma bir karmaşıklık katar ve bu konu kararınızda dikkate alınmalıdır. Örneğin, Accesorler için client kanalında genel interneti kullanıyorsanız, internet üzerinden jumbo frameler geçirmek bir sorun olabilir.
Tepki süresi birincil endişeniz ise (iş hacmi değil), standart MTU’yu kullanın; Aksi takdirde, jumbo framelerin kullanımını düşünebilirsiniz.

Belirli bir kanal için, MTU ayarları tüm sistem ve tüm anlık anahtarlar arasında tutarlı olmalıdır. Bu tutarlılık, performansı etkileyebilecek paket parçalanmasını önler. MTU ayarı, IBM COS’a bağlanan istemciler ve IBM COS’nin istemciye yönelik arabirimleri arasında da tutarlı olmalıdır. Accesor düğümleri ve Slicer düğümleri, bağlı NIC’lerle yapılandırılabilir.

İpucu: IBM COS için varsayılan MTU ayarı 1500’dür ve gerekirse jumbo frameleri (MTU=9000) destekleyecek şekilde değiştirilebilir.

NIC bonding

IBM COS NIC’leri, yük dengeleme (LACP) ve yedeklilik için bağlanabilir. Yük dengeleme kullanılıyorsa, ağ anahtarları COS bağlantı noktalarındaki ayarlarla eşleşecek şekilde doğru şekilde yapılandırılmalıdır.

Toplu bağlantılar arasındaki trafik akışını optimize etmek için çeşitli karma algoritmalar kullanılabilir. Uygun karma algoritma, cihaza gelen trafik ve cihazdan çıkan trafik için farklı olabilir.

IBM COS Performans Ölçümü

IBM, müşterilerin ve üçüncü kişi bütünleştiricilerin, müşteri uygulamasında herhangi bir performans testi çalıştırmadan önce her zaman bir IBM COS sisteminin performansını temel almasını önerir.

IBM COS performansının temel çizgisini oluşturmak için Nesne Oluşturucu (OG) gibi bir yük oluşturucu kullanılabilir.
OG aracı, bir Accesser düğümüne karşı HTTP testi için geleneksel bir istemci olarak kullanılabilen açık kaynaklı bir Java programıdır.

Genel OG deposu GitHub.com’da bulunabilir ve bu web sayfasındaki sürüm yapıları mevcuttur.
OG, bir Windows veya Linux ana bilgisayar işletim sisteminden çalıştırılabilir ve aşağıdaki işlevleri gerçekleştirme yeteneği de dahil olmak üzere çok çeşitli işlevleri destekler:

• Thread sınırlı veya OPS modlarında çalıştırın.
• Tek bir çağrıdan birden çok dosya boyutu aralığını destekleyin.
• PUT, GET, DELETE, LIST, HEAD ve Multipart Upload trafiğinin farklı karışımlarını destekleyin.
• OG, aracın oluşturduğu rastgele kaynak verileri oluşturur.

Tercih edilen uygulama: Herhangi bir performans testi çalıştırmadan önce bir kasayı kısmen doldurmak en iyi uygulama olarak kabul edilir.

• Doldurma, planlanan iş yüküyle eşleşmeli ve sistem performansındaki bir değişikliğe yanıt veren (sabit bir OPS yük oluşturucu yerine) iş parçacığı tabanlı bir yük oluşturucu kullanmalıdır.
• Doldurma, istikrarlı performans elde edilene kadar devam etmelidir.
• IBM COS sistem temeli, planlanan üretim iş yüküyle aynı nesne boyutlarını ve iş akışını kullanmalıdır.

Aşağıdaki yaygın performans testi türleri mevcuttur:

OPS testi Dosya boyutu değiştirilirken eşzamanlılık sabit tutulur. Birincil metrikler, saniyedeki işlemler ve aktarım hızıdır.

Latency testi OPS değiştirilirken dosya boyutu sabit tutulur. Birincil metrik gecikmedir.

Smoke testi Dosya boyutları ve işlem türlerinin bir karışımını içerir. Bir eşzamanlılık veya OPS’de çalıştırılabilir modu.

Concurrency testi Eşzamanlılık değiştirilirken dosya boyutu sabit tutulur. Birincil metrik verimdir; ikincil metrik gecikmedir.

Diğer Konular:
Test sonuçlarının geçerli olduğundan emin olmak için performans testi için kullanılan bir sistemi izlemek de önemlidir.
Aşağıdaki noktaları göz önünde bulundurun:

• Test özellikle bozulmuş bir sistemdeki performansa bakmıyorsa, depolama havuzu her zaman hiçbir Slicestor düğümü kapalı ve çekilmiş veya karantinaya alınmış diskler olmadan tam genişlikte olmalıdır.
• Test çalıştırması sırasında yeniden oluşturma yapılmamalıdır.
• Diskler karantinaya alınırsa, disk arızası gerçekleştirilmeden değiştirilmelidir. göç. Ayrıca, test devam ettirilmeden önce yeniden oluşturma işleminin tamamlanmasına izin verilmelidir.
• Disk yeniden dengelemenin bir faktör olmadığından ve disklerin fazla dolmadığından emin olmak için disk doldurma seviyeleri izlenmelidir.
• Kasa silme işlemi hemen istemciye döner, ancak arka planda çalışması biraz zaman alabilir. Bu nedenle, kasa silme içeren testler, başka bir teste başlamadan önce kasaların silinmesi için yeterli süre tanımalıdır.

Umarım bilgilendirici bir yazı olmuştur. Bir sonraki yazım yine bir kaç bölüm olacak, Güvenlik ve Erişilebilirlik konularının planlanmasına bakalım istiyorum.

Bu arada yazıyı beğendi iseniz, Patreon üstünden bir kahve ısmarlaya bilir veya abone olup yeni yazılarımın ve podcastlerimin gelmesi için bana destek olabilirsiniz.

Become a Patron!