InfiniBand Teknik Rehberi: Fabric Mimarisi, Kurulum ve En İyi Uygulamalar
InfiniBand fabric mimarisi, fat-tree topolojisi, Subnet Manager yapılandırması ve HPC kümelerinde uçtan uca kurulum adımları. HDR200 ve NDR400 karşılaştırması dahil.
Yüksek başarımlı hesaplama (HPC) kümelerinde işlemci gücü ne kadar artarsa artsın, düğümler arası ağ yeterli bantgenişliği ve düşük gecikmeyi sağlamazsa genel sistem verimi çöker. Bu noktada InfiniBand, on yılı aşkın HPC pratiğiyle kanıtlanmış tek gerçek seçenek olarak öne çıkar. Bu rehberde InfiniBand’ın temel bileşenlerini, fabric mimarisini ve üretime hazır bir küme için izlenmesi gereken kurulum adımlarını ele alıyoruz.
Neden InfiniBand?
Standart Ethernet, veri merkezi trafiği için yeterli olsa da MPI tabanlı paralel hesaplamada kritik bir dezavantajı vardır: her paket işletim sistemi yığınından geçmek zorundadır. Bu, mikrosaniye düzeyinde hassas zamanlama gerektiren sıkı senkronizasyon iş yüklerinde kabul edilemez bir ek yük yaratır.
InfiniBand’ın temel farkı RDMA (Remote Direct Memory Access) desteğidir. RDMA ile bir düğüm, karşı tarafın CPU’sunu ve işletim sistemini tamamen atlayarak doğrudan uzak belleğe yazar ya da oradan okur. Sonuç: 1–2 µs uçtan uca gecikme ve port başına 200 Gb/s (HDR) veya 400 Gb/s (NDR) ham bantgenişliği.
Bu avantajlar şu iş yüklerinde belirleyicidir:
- MPI paralel simülasyonlar: Her bariyer senkronizasyonu ağa bağımlıdır; gecikme doğrudan toplam çalışma süresine yansır.
- Dağıtık derin öğrenme eğitimi: All-reduce işlemleri sırasında GPU’lar arası gradient değişimi ağı darboğaza sokar.
- Büyük ölçekli biyoinformatik ve genomik: Dağıtık bellek gerektiren veri setleri düğümler arasında sürekli veri hareketi gerektirir.
Hız Katmanlarını Seçmek: HDR200 mi, NDR400 mü?
| Standart | Port Hızı | Tipik Senaryo |
|---|---|---|
| HDR (High Data Rate) | 200 Gb/s | Kurumsal HPC, üniversite kümeleri |
| NDR (Next Data Rate) | 400 Gb/s | Büyük GPU kümeleri, yapay zeka altyapıları |
| HDR100 | 100 Gb/s | Küçük kümeler, geçiş altyapıları |
| EDR | 100 Gb/s | Miras sistemler |
HDR200, çoğu kurumsal HPC ortamı için doğru başlangıç noktasıdır. Donanım maliyeti NDR400’e göre düşüktür ve mevcut MLNX_OFED sürücü ekosistemiyle olgun bir entegrasyon sunar. NDR400 ise all-to-all iletişim yoğunluğunun yüksek olduğu büyük GPU kümelerinde birim işlem başına maliyet avantajı sağlar; port başına maliyet yüksek olsa da daha az switch katmanıyla aynı ölçeğe ulaşmak mümkündür.
Fabric Mimarisi: Fat-Tree Topolojisi
InfiniBand ağlarında en yaygın topoloji fat-tree’dir. Bu yapıda düğümler leaf switch’lere, leaf switch’ler ise core switch’lere bağlanır. Her seviyede yeterli uplink sağlandığında herhangi iki düğüm arasında tam line-rate iletişim mümkündür.
[Core Switch]
/ | \
[Leaf-1] [Leaf-2] [Leaf-3]
/ | \ / | \ / | \
N1 N2 N3 N4 N5 N6 N7 N8 N9
Fat-tree’nin kritik avantajı yatay ölçeklenebilirliktir: kümeye yeni düğümler eklendiğinde mevcut düğümlerin iletişim performansı düşmez. Oversubscription oranı (uplink sayısı / downlink sayısı) tasarım aşamasında dikkatle hesaplanmalıdır; 1:1 oversubscription tam bisection bandwidth garantisi verir.
Subnet Manager Yapılandırması
Fabric’in çalışabilmesi için bir Subnet Manager (SM) zorunludur. SM, topolojiyi keşfeder, LID (Local Identifier) atamalarını yapar ve yönlendirme tablolarını hesaplar. Küçük ortamlarda OpenSM yazılım çözümü yeterlidir; büyük üretim kümelerinde donanım tabanlı SM veya aktif/yedek OpenSM çifti önerilir.
# OpenSM servisini etkinleştirme
systemctl start opensm
systemctl enable opensm
# Fabric topolojisini keşfetme
ibnetdiscover | head -40
# Tüm port durumlarını listeleme
ibstat
# Düğümler arası bandwidth testi
ib_write_bw -d mlx5_0 -i 1 # sunucu tarafı
ib_write_bw -d mlx5_0 -i 1 <ip> # istemci tarafı
Kurulum Adımları
1. Tasarım ve Kapasite Planlaması
Kuruluma başlamadan önce iş yükü profili çıkarılmalıdır. Kaç düğüm var? İletişim yoğunluğu all-to-all mı, yoksa nearest-neighbor mı? Gelecekte kaç düğüm eklenecek? Bu sorular switch modeli, port sayısı ve kablo türünü (aktif optik kablo veya bakır DAC) belirler. HCA (Host Channel Adapter) seçiminde sunucu PCIe şeridinin bottleneck yaratmamasına dikkat edilmelidir.
2. Fiziksel Kurulum ve Kablolama
Rack yerleşiminde switch’ler merkezi konuma alınmalı, kablo uzunlukları minimize edilmelidir. Her bağlantı etiketlenmeli ve Link/Activity testinden geçirilmelidir. Hatalı kablo veya SFP/QSFP modül, üretim öncesinde bu aşamada tespit edilmelidir.
3. Sürücü ve Yazılım Yapılandırması
MLNX_OFED (Mellanox OpenFabrics Enterprise Distribution) sürücü paketi tüm düğümlere kurulur. RDMA performansı için kernel parametreleri optimize edilir (huge pages, IRQ affinity, CPU governor). MPI kütüphaneleri (OpenMPI, MVAPICH2) InfiniBand desteğiyle derlenir ve yapılandırılır.
4. Kabul Testleri
Üretime geçmeden önce şu testler sistematik biçimde uygulanır:
- Bandwidth testi: Her port teorik maksimuma (HDR için ~190 Gb/s efektif) ulaşmalıdır.
- Gecikme testi:
ib_write_latile uçtan uca gecikme ölçülür; 1–2 µs beklenen değerdir. - All-to-all gecikme: Fabric genelinde gecikme dağılımı homojen olmalıdır; outlier port sorunlu bağlantıya işaret eder.
- MPI benchmark: IMB-MPI1 ve OSU Micro-Benchmarks ile gerçek uygulama koşulları simüle edilir.
- Failover testi: Bir switch veya HCA arızası senaryosunda SM yeniden yönlendirmeyi otomatik yapmalıdır.
Sık Karşılaşılan Sorunlar
Port link-down olayları: Genellikle fiziksel kablo hasarı veya SFP/QSFP modül sorunudur. ibstat ve perfquery çıktılarındaki yüksek symbol error sayacı bu tanıyı doğrular.
Beklenenden düşük bandwidth: PCIe Gen3/Gen4 bant genişliği yetersizliği, yanlış HCA port konfigürasyonu veya oversubscription oranı fazla yüksek olabilir.
SM uyumsuzluğu: Fabrik’te birden fazla aktif SM varsa çakışma yaşanır. sminfo komutuyla hangi SM’nin master olduğu kontrol edilmelidir.
RDMA bağlantı hataları: Güvenlik duvarı veya yanlış yapılandırılmış IPoIB arayüzü nedeniyle oluşabilir; rdma_cm demonou ve IB portlarının doğru subnet’e atandığı doğrulanmalıdır.
İzleme ve Operasyonel Yönetim
Üretim fabric’inde sürekli izleme zorunludur. perfquery tabanlı betikler veya Mellanox NEO ile switch portlarından metrikler toplanır ve Prometheus + Grafana’ya aktarılır. İzlenecek kritik metrikler şunlardır: port link durumu, symbol hata sayacı, yeniden iletim sayacı ve port kullanım oranı.
Proaktif uyarı kurulumu, küçük sorunların büyük kesintiye dönüşmesini önler. Port hata eşiği aşıldığında otomatik bildirim gönderilmeli ve sorunlu bağlantı işaretlenmelidir.
InfiniBand fabric, HPC yatırımlarının geri dönüşünü doğrudan belirler. Doğru topoloji, doğru hız katmanı ve eksiksiz kabul testleri olmadan hesaplama düğümlerinin potansiyeli gerçekleşemez. Mevasis olarak yürüttüğümüz InfiniBand projelerinde her aşamayı belgelenmiş prosedürlerle yürütür, testleri geçemeyen hiçbir sistemi üretime almayız.
InfiniBand altyapısı hakkında daha fazla bilgi almak için InfiniBand çözümlerimizi inceleyebilir ya da iletişim sayfamızdan teknik değerlendirme talebinde bulunabilirsiniz.