HPC Cluster Mimarisi: Bileşenler ve Tasarım Prensipleri

Yüksek Başarımlı Hesaplama (HPC) cluster’ları, tek bir sunucunun sınırlarını aşan hesaplama iş yüklerini paralel olarak işlemek için tasarlanmış, birden fazla sunucunun birbirine bağlandığı dağıtık bilgisayar sistemleridir. Bu sistemlerde yüzlerce veya binlerce işlemci çekirdeği koordineli biçimde çalışarak mühendislik simülasyonlarından yapay zeka eğitimine kadar geniş bir uygulama yelpazesine hizmet verir.

Bir HPC cluster’ın başarısı, salt hesaplama gücüyle değil; bu gücü çalışır kılan mimari kararlarla belirlenir. Hangi node’un hangi rolü üstlendiğinden depolama katmanının nasıl yapılandırıldığına kadar her tasarım seçimi; sistemin kararlılığını, ölçeklenebilirliğini ve uzun vadeli toplam sahip olma maliyetini (TCO) doğrudan etkiler.

Bu yazıda bir HPC cluster’ının temel bileşenlerini, her bileşenin görev tanımını ve bunları bir araya getiren tasarım prensiplerini ele alıyoruz.

Temel Bileşenler: Roller ve Sorumluluklar

Modern bir HPC cluster’ı işlevsel açıdan beş ana katmana ayrılır: erişim, yönetim, hesaplama, depolama ve ağ. Her katman, diğerleriyle açıkça tanımlanmış arayüzler üzerinden iletişim kurar.

Login Node (Erişim Düğümü)

Login node, kullanıcıların cluster’a bağlandığı tek giriş noktasıdır. SSH bağlantılarını kabul eder, kullanıcıların iş komutları hazırlamasına ve iş kuyruğuna iş göndermesine olanak tanır. Login node üzerinde doğrudan hesaplama yapılmaz; bu düğüm yalnızca iş hazırlığı, dosya transferi ve iş yönetimi için kullanılır.

Boyutlandırma ipucu: Eşzamanlı kullanıcı sayısına göre RAM kapasitesi belirlenmelidir. Tipik kurumsal cluster’larda 10–50 kullanıcı için 64–128 GB RAM yeterlidir; ancak büyük akademik ortamlarda bu gereksinim 256 GB’a çıkabilir.

Yüksek kullanıcı yoğunluğu beklenen ortamlarda iki login node yük dengelemeli (active-active) olarak konuşlandırılabilir.

Management Node (Yönetim Düğümü)

Management node veya baş düğüm (head node), cluster’ın kontrol merkezi konumundadır. Şu hizmetleri barındırır:

• DHCP / PXE: Compute node’larının ağ üzerinden önyüklenmesi
• DNS: Cluster iç ad çözümlemesi
• LDAP / Active Directory: Merkezi kullanıcı ve grup yönetimi
• NTP: Tüm node’larda saat senkronizasyonu
• İzleme servisleri: Prometheus, Grafana, Nagios veya Zabbix
• Provizyon yönetimi: Warewulf, xCAT veya Ansible

Management node’u kaybetmek tüm cluster’ı işlevsiz kılabilir. Bu nedenle kritik servislerin yedekli çalıştırılması — en azından pasif bir yedek node (standby) bulundurulması — önemli bir tasarım gereksinimidir.

Compute Node (Hesaplama Düğümü)

Asıl hesaplama gücünün yoğunlaştığı yerdir. Compute node’lar tipik olarak şunları içerir:

• Çok çekirdekli CPU’lar (örn. AMD EPYC 7003 serisi, Intel Xeon Scalable)
• Yüksek kapasiteli RAM (hesaplama iş yükü başına 4–16 GB/çekirdek)
• Yerel geçici depolama (NVMe SSD, scratch alanı için)
• Yüksek hızlı ağ arayüzü (InfiniBand veya 25/100 GbE)

Compute node’lar işletim sistemi açısından genellikle minimal konfigürasyonla çalışır: yerel disk I/O’sunu azaltmak ve node homojenliğini korumak için diskless (RAM disk) ya da küçük boyutlu OS partition ile önyüklenir.

GPU node’lar: Yapay zeka, derin öğrenme veya GPU hızlandırmalı simülasyon gereksinimleri için ayrı GPU node’ları kümeye dahil edilebilir. Bu node’lar farklı kaynak politikaları gerektirir ve SLURM’da ayrı partition olarak yönetilir.

Storage Node (Depolama Düğümü)

Depolama katmanı; kullanıcı home dizinlerini, proje verilerini ve uygulama ikili dosyalarını barındırır. HPC ortamında standart NFS ile paralel dosya sistemleri arasındaki fark kritiktir:

Küçük cluster’larda (8–32 node) NFS yeterli olabilir; ancak yüzlerce node ölçeğinde veya checkpoint yoğun iş yüklerinde paralel dosya sistemi zorunluluk haline gelir.

Ağ Katmanı

Cluster içi ağ iki farklı trafiği taşır:

1. Yönetim ağı (Ethernet): PXE, SSH, izleme, provizyon trafiği. Genellikle 1 GbE yeterlidir.
2. Hesaplama/veri ağı (Yüksek hızlı): MPI mesajlaşması, paralel dosya sistemi I/O. InfiniBand HDR (200 Gb/s) veya 25/100 GbE tercih edilir.

Bu iki ağı fiziksel ya da mantıksal olarak ayırmak hem güvenlik hem de performans açısından en iyi uygulamadır. Yönetim trafiğinin hesaplama ağını meşgul etmesi ciddi gecikme sorunlarına yol açabilir.

Yazılım Stack: İş Akışının Görünmez Temeli

Donanım ne kadar güçlü olursa olsun, onu etkin kılan yazılım katmanıdır.

İş Yöneticisi: SLURM

SLURM (Simple Linux Utility for Resource Management), HPC dünyasında fiili standart haline gelmiş iş zamanlayıcısıdır. Kaynak talep eden iş tanımları sbatch ile kuyruğa gönderilir; SLURM uygun node’ları tahsis ederek işi başlatır.

Tipik bir SLURM iş betiği:

#!/bin/bash
#SBATCH --job-name=fluent_sim
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=28
#SBATCH --mem=120G
#SBATCH --time=08:00:00
#SBATCH --partition=compute
#SBATCH --output=fluent_%j.out

module load ansys/2024R2
module load mpi/openmpi-4.1

mpirun -np 112 fluent 3d -t112 -g -i input.jou

Bu betik 4 node üzerinde 28’er çekirdek ve 120 GB RAM tahsis eder; toplam 112 çekirdek üzerinde ANSYS Fluent çalıştırır.

Kullanıcı ve Kimlik Yönetimi: OpenLDAP

Tüm node’larda tutarlı kullanıcı hesapları için merkezi dizin servisi şarttır. OpenLDAP veya FreeIPA, UID/GID eşlemelerini ve grup politikalarını tek noktadan yönetmeyi sağlar. Aksi hâlde her yeni kullanıcı için onlarca node’da manuel /etc/passwd girişi gerekir — bu hem hata eğilimli hem de yönetilemez olur.

Modül Sistemi: Environment Modules / Lmod

Farklı kullanıcılar farklı uygulama sürümlerine ihtiyaç duyar. Lmod, module load gcc/12.2 gibi komutlarla ortam değişkenlerini dinamik olarak değiştirerek çakışan yazılım sürümlerini izole eder.

Tasarım Prensipleri

1. Rolleri Net Ayır

Her node grubunun tek bir birincil görevi olmalıdır. Login node üzerinde uzun süreli hesaplama yapmak, diğer kullanıcıların bağlantısını yavaşlatır. Compute node üzerinde kullanıcı oturumu açmak, iş yönetimini ve izlemeyi karmaşıklaştırır.

2. Homojenlik Önceliklidir

Mümkün olduğunca aynı donanım modelini ve aynı işletim sistemi sürümünü kullanın. Heterojen ortamlar provizyon süreçlerini, sorun gidermeyi ve yazılım uyumluluğunu önemli ölçüde zorlaştırır.

3. Kaldıraç Olarak Depolama Katmanı

Hesaplama gücünü artırmak nispeten kolaydır; depolama mimarisini sonradan değiştirmek ise maliyetlidir. Depolama gereksinimlerini baştan fazla tahmin etmek yerine, ölçeklenebilir bir mimari (paralel dosya sistemi, tier yapısı) ile başlamak uzun vadede avantaj sağlar.

4. Yedeklilik Kritik Noktalar için Zorunlu

Tüm sistemi durduracak tek hata noktaları (SPOF) tasarımda en baştan giderilmelidir:

• Management node: en az pasif yedek
• Ağ anahtarı (switch): çekirdek switch’te aktif-aktif veya yedekli uplink
• Depolama: RAID ya da ağ düzeyinde replikasyon

5. Gözlemlenebilirlik İnşa Edin, Sonradan Eklemeyin

Prometheus + Grafana kombinasyonu, node başına CPU/bellek kullanımı, depolama I/O ve ağ bant genişliğini gerçek zamanlı izlemek için en yaygın tercihlerden biridir. İzleme altyapısını kurulum aşamasında devreye almak, kapasite planlamasına ve olası sorun giderimine çok değerli veri sağlar.

Ölçeklendirme: Küçük Başla, Akıllı Büyü

Çoğu HPC cluster’ı başlangıçta küçük bir çekirdek altyapıyla devreye girer; zamanla compute node eklenerek büyür. Bu sürecin sorunsuz işlemesi için:

• Ağ katmanı baştan yeterli port kapasitesine sahip switch’lerle kurulmalıdır.
• IP adres planlaması büyümeye yer bırakmalıdır (örn. /24 yerine /22 subnet).
• Provizyon sistemi yeni node’ları minimum müdahaleyle ekleyebilmelidir.
• Lisans altyapısı (ticari simülasyon yazılımları için) ek node’ları kapsayacak şekilde planlanmalıdır.

Küçük ölçekte yeterli görünen tasarım kararları, sistem büyüdükçe ciddi darboğazlara dönüşebilir. Bu nedenle mimarinin büyüme varsayımları göz önünde bulundurularak tasarlanması gerekir.

Özet: Mimari Kararlar Neden Önemli?

Bir HPC cluster’ında her bileşen belirli bir nedenden dolayı vardır ve aralarındaki ilişki bir bütün oluşturur. Login node kullanıcıyı karşılar, management node sistemin sağlıklı çalışmasını sağlar, compute node’lar işi yürütür, depolama katmanı veriyi taşır, ağ ise bunların tamamını birbirine bağlar. Bu bileşenlerden birinin yetersiz tasarlanması, zincirin en zayıf halkası haline gelir.

Başarılı bir HPC mimarisi; iş yükünü anlayan, büyümeyi öngören, bakımı kolaylaştıran ve kullanıcı deneyimini merkeze alan tasarım kararlarının bütünüdür.

Mevasis olarak HPC cluster mimarisi konusunda size destek olmaktan memnuniyet duyarız. İletişim için formu doldurun.