InfiniBand Subnet Manager: OpenSM ve UFM ile Fabric Yönetimi

InfiniBand fabric’inde hiçbir paket, Subnet Manager (SM) olmadan hareket edemez. Switch’leri rack’e taktınız, kabloları çektiniz, adaptörler takılı — ama SM çalışmıyorsa portlar Initializing durumunda kalır ve tek bir MPI mesajı bile geçmez.

Ethernet’te karşılığı olmayan bu bileşen, InfiniBand kurulumlarında en sık yanlış anlaşılan ve en sık yedeksiz bırakılan parçadır.

Subnet Manager tam olarak ne yapar?

SM, fabric’i tarar ve şu işleri yapar:

1. Keşif. Tüm switch’leri, adaptörleri (HCA) ve aralarındaki bağlantıları bulur; fabric’in topoloji haritasını çıkarır.
2. Adresleme. Her porta bir LID (Local Identifier) atar. InfiniBand yönlendirmesi bu LID’ler üzerinden yapılır.
3. Yönlendirme tablosu. Her switch için forwarding tablosunu hesaplar ve switch’lere yazar.
4. Port etkinleştirme. Portları Active durumuna geçirir; veri trafiği ancak bundan sonra başlar.
5. Sürekli izleme. Topoloji değiştiğinde (kablo çıkması, switch arızası, yeni düğüm eklenmesi) yeniden hesaplama yapar.

Yani SM bir izleme aracı değil, fabric’in kontrol düzlemidir.

Yönetilebilir ve yönetilemez switch farkı

Ürün listelerinde aynı port sayısına sahip iki model görürsünüz: QM8700 ve QM8790, ya da QM9700 ve QM9790. Donanım neredeyse aynıdır; fark tam olarak buradadır.

Pratikte yaygın ve doğru yaklaşım: fabric’teki ilk (ve yedeklilik için ikinci) switch’i yönetilebilir seçmek, ölçeklerken eklenen switch’leri yönetilemez almak. SM zaten fabric’te çalışıyorsa her switch’in ayrı bir SM’e ihtiyacı yoktur ve bu, genişletme maliyetini belirgin biçimde düşürür.

Tamamen yönetilemez switch’lerden kurulu bir fabric de mümkündür — o durumda SM, küme içindeki bir sunucuda OpenSM olarak çalıştırılır.

OpenSM: sunucu üzerinde subnet manager

OpenSM, InfiniBand’in açık kaynak subnet manager’ıdır ve MLNX_OFED / DOCA-OFED paketiyle birlikte gelir. Tipik olarak login veya yönetim düğümünde çalıştırılır.

# Kurulu mu, fabric görünüyor mu?
ibstat                  # yerel HCA port durumu
ibnetdiscover | head    # fabric topolojisi
sminfo                  # aktif SM kim?

sminfo çıktısı üretimde ilk bakılacak yerdir: hangi düğümün SM olduğunu ve önceliğini gösterir.

Yedeklilik: tek SM üretim ortamı değildir

En sık gördüğümüz operasyonel hata, tek bir düğümde tek bir OpenSM çalıştırmaktır. O düğüm yeniden başlatıldığında mevcut bağlantılar bir süre ayakta kalır ama topolojide herhangi bir değişiklik olduğunda fabric yönetimsiz kalır.

Doğru kurulum en az iki düğümde SM çalıştırmaktır. InfiniBand bunu doğal olarak destekler: SM’ler kendi aralarında öncelik üzerinden anlaşır, en yüksek öncelikli olan master, diğeri standby olur. Master düştüğünde standby devralır.

# /etc/opensm/opensm.conf — master düğümde
priority 15

# standby düğümde
priority 10

Öncelikleri farklı vermek önemlidir; eşit öncelikte seçim GUID’e göre yapılır ve hangi düğümün master olacağı öngörülemez hâle gelir.

Routing engine seçimi

OpenSM’nin varsayılan yönlendirme algoritması her topoloji için en iyi seçim değildir. Fat-tree kurulumlarında ftree veya updn belirgin fark yaratır:

# fat-tree topolojide
routing_engine ftree

Yanlış routing engine, fiziksel olarak non-blocking bir fabric’te bile bazı bağlantıların tıkanmasına yol açar. Devreye alma sırasında ib_write_bw ile çapraz ölçüm yapıp beklenen bisection bant genişliğine ulaşıldığını doğrulamak gerekir.

Partition (pkey): fabric’i bölmek

Paylaşımlı kümelerde farklı grupların birbirinin trafiğini görmemesi istenebilir. InfiniBand’de bu partition ile yapılır: her partition’ın bir pkey’i vardır ve yalnızca aynı pkey’e sahip portlar haberleşir.

# /etc/opensm/partitions.conf
Default=0x7fff, ipoib, defmember=full : ALL;
arastirma=0x8001, ipoib, defmember=full : 0x0002c90300abcdef, 0x0002c90300abcdf0;

Tipik kullanım: hesaplama trafiği, depolama trafiği ve yönetim trafiğini ayrı partition’lara koymak. Bu, çok kiracılı kurulumlarda hem güvenlik hem de trafik izolasyonu sağlar.

UFM: ölçek büyüdüğünde

OpenSM işini yapar ama bir izleme ve yönetim arayüzü sunmaz. NVIDIA UFM (Unified Fabric Manager) bunun üzerine gelir: merkezi topoloji görünümü, port sayaçları, hata eşiği uyarıları, telemetri ve otomatik olay kaydı.

Kabaca kural: birkaç düğümlük kurulumlarda OpenSM + ibdiagnet yeterlidir. Yüzlerce düğüme çıkıldığında, özellikle paylaşımlı ve SLA’lı ortamlarda, UFM’in sağladığı görünürlük operasyon yükünü belirgin biçimde azaltır.

Teşhis: bir şeyler ters gittiğinde

ibdiagnet                    # fabric geneli sağlık taraması
ibhosts                      # görünen HCA'lar
ibswitches                   # görünen switch'ler
iblinkinfo                   # bağlantı hızları ve durumları
perfquery -a                 # port hata sayaçları

ibdiagnet üretimde ilk çalıştırılacak komuttur; kredi kaybı, sembol hatası ve hız uyuşmazlıklarını tek raporda toplar.

Sık görülen üç bulgu:

Port beklenenden düşük hızda. Kablo veya modül hız uyumsuzluğu ya da kirli/gevşek konektör. iblinkinfo çıktısında beklenen hızla gerçekleşeni karşılaştırın.

Artan sembol hatası. Fiziksel katman sorunu — kablo, modül veya port. Sayaçları sıfırlayıp belirli bir süre sonra tekrar okuyarak hata hızını ölçün; tek seferlik birikmiş sayı yanıltıcıdır.

Fabric’te iki master SM. Genellikle ağ bölünmesinden sonra oluşur. sminfo ile kontrol edin; öncelik ayarlarının tutarlı olduğundan emin olun.

Mevasis fabric devreye alma hizmetleri

Subnet manager kurulumu, yedekli yapılandırma, routing engine seçimi ve partition planı, HPC altyapı kurulumu hizmetimizin kapsamındadır. Devreye alma, ibdiagnet raporu ve çapraz bant genişliği ölçümüyle birlikte teslim edilir.

Yönetilebilir/yönetilemez switch dağılımını planlarken de yardımcı oluyoruz: InfiniBand switch modelleri sayfasına göz atın veya iletişime geçin.

Sıkça Sorulan Sorular

Yönetilemez switch aldım, subnet manager’ı nerede çalıştırmalıyım? Küme içindeki bir sunucuda — genellikle login veya yönetim düğümünde — OpenSM çalıştırabilirsiniz. Üretim ortamında en az iki düğümde farklı önceliklerle kurmanızı öneririz.

İki switch’in ikisi de yönetilebilirse iki SM mi çalışır? Evet ve bu istenen durumdur. Biri master, diğeri standby olur; master düştüğünde standby devralır. Önemli olan önceliklerin farklı ayarlanmasıdır.

SM yeniden başlarsa çalışan işler kopar mı? Kurulu bağlantılar genellikle etkilenmez, çünkü veri düzlemi SM’den bağımsız çalışır. Ancak SM yokken topoloji değişikliği olursa (kablo çıkması gibi) fabric kendini toparlayamaz.

Partition kullanmak performansı düşürür mü? Hayır. pkey kontrolü donanımda yapılır ve ölçülebilir bir gecikme eklemez.