HPC Performans Göstergeleri (KPI): Cluster'ı Nasıl Ölçersiniz?

Bir HPC cluster’ı kurduğunuzda ya da işlettiğinizde, sorulan ilk sorulardan biri çoğu zaman şu olur: “Bu sistem gerçekten verimli çalışıyor mu?” Bu soruyu yanıtlamak için sezgiye ya da tahmine değil, somut ölçümlere ihtiyaç duyarsınız. HPC dünyasında bu ölçümler Key Performance Indicators (KPI) — yani Temel Performans Göstergeleri — aracılığıyla tanımlanır.

Bu yazıda bir HPC cluster’ının sağlığını ve verimliliğini ölçmek için kullanılan başlıca metrikleri, bunları nasıl toplayacağınızı ve yorumlayacağınızı ele alacağız.

Neden KPI Takibi Önemlidir?

HPC sistemleri, kullanıcıların yüzlerce veya binlerce çekirdeğe erişebildiği karmaşık altyapılardır. Donanım maliyeti yüksektir; enerji tüketimi önemlidir; araştırma ya da üretim süreçleri sisteme doğrudan bağlıdır. Bu ortamda izleme yapmadan yönetim yapmak, kokpit bilgisiz uçmaya benzer.

KPI’lar sayesinde şunları yapabilirsiniz:

• Darboğazları erkenden tespit etmek: Bir iş kuyruğu neden uzuyor? Hangi düğüm yavaş işliyor?
• Kapasite planlaması yapmak: Mevcut donanım yeterli mi, yoksa genişleme zamanı mı geldi?
• SLA’ları karşılamak: Kullanıcılara verilen taahhütler yerine geliyor mu?
• Maliyet-verimlilik dengesini kurmak: Kaynak israfını önlemek ve enerji maliyetlerini düşürmek.

Temel HPC KPI Kategorileri

HPC performans göstergelerini beş ana kategoride inceleyebiliriz:

1. Kaynak Kullanımı (Resource Utilization)

En temel metriklerden biridir. Sistem kaynaklarının ne kadarının etkin biçimde kullanıldığını gösterir.

CPU Kullanım Oranı (CPU Utilization)

Bir compute düğümünün CPU çekirdeklerinin yüzde kaçının hesaplama işine harcandığını ölçer. Sürekli düşük seyreden bir CPU kullanımı, iş yükünün doğru şekilde dağıtılmadığına ya da I/O bekleme sürelerinin yüksek olduğuna işaret edebilir.

Bellek Kullanımı (Memory Utilization)

Ayrılan RAM’in ne kadarının gerçekten kullanıldığını takip eder. Bir iş için 256 GB talep edilip yalnızca 40 GB kullanılıyorsa bu ciddi bir israf göstergesidir.

GPU Kullanımı

GPU hızlandırmalı sistemlerde GPU kullanım oranı ayrı izlenmelidir. NVIDIA sistemlerde nvidia-smi veya DCGM araçları bu veriyi sağlar.

Örnek: Slurm ile Basit Bir Kullanım Raporu

# Son 7 günlük iş istatistikleri (sreport)
sreport cluster utilization start=now-7days end=now -t percent

# Belirli bir iş için kaynak kullanımı
seff <job_id>

seff çıktısı şu şekilde görünür:

Job ID: 1042837
Cluster: mevasis-hpc
Cores per node: 32
CPU Utilized: 12:34:22
CPU Efficiency: 87.43% of 14:22:08 core-walltime
Memory Utilized: 48.21 GB
Memory Efficiency: 75.33% of 64.00 GB

Bu çıktı hem CPU hem bellek verimliliğini tek bakışta gösterir.

2. İş Verimi (Job Throughput)

Throughput, belirli bir zaman diliminde cluster’ın kaç işi tamamladığını ölçer. Tek başına bir anlam ifade etmez; kullanıcı sayısı, iş büyüklüğü ve donanım kapasitesiyle birlikte değerlendirilmelidir.

İzlenmesi gereken alt metrikler:

Yüksek başarısız iş oranı genellikle altyapı sorunlarını (ağ kesintisi, dosya sistemi hataları) ya da kullanıcı hatalarını (yanlış kaynak talebi) işaret eder.

3. Kuyruk Bekleme Süresi (Queue Wait Time)

Bekleme süresi, bir işin kuyruğa gönderilmesinden çalışmaya başlamasına kadar geçen süredir. Bu metrik kullanıcı memnuniyetiyle doğrudan ilişkilidir ve cluster’ın talep-kapasite dengesini yansıtır.

Wait time yükseldiğinde sorulacak sorular:

• Belirli bir kaynağa (örneğin GPU) mı yoğunluk var?
• Yüksek öncelikli (high-priority) işler düşük öncelikli işleri uzun süre bloke mi ediyor?
• Partition dengesi doğru kurgulanmış mı?
• Backfill algoritması çalışıyor mu?

Slurm’de backfill scheduler, büyük bir işi beklerken onu engellemeyen küçük işleri araya sıkıştırarak bekleme sürelerini önemli ölçüde kısaltabilir.

4. Sistem Verimliliği (System Efficiency)

Sistem verimliliği, ayrılan kaynakların ne ölçüde gerçek işe dönüştüğünü gösterir. Kaynak kullanımı ile throughput’u birleştiren bir üst düzey metriktir.

Yaygın verimlilik göstergeleri:

• Core Hours Wasted: Ayrılan ama kullanılmayan çekirdek-saat miktarı.
• Stranded Resources: Bir düğüm üzerinde koşan iş nedeniyle kullanılamayan boş çekirdek ya da bellek.
• Node Utilization Rate: Toplam düğüm sayısının ne kadarının aktif olduğu.

Düşük verimlilik çoğunlukla aşırı kaynak talebi alışkanlığından kaynaklanır. Kullanıcılar güvenlik marjı bırakmak amacıyla gerçekte ihtiyaç duydukları kaynağın iki-üç katını talep edebilir. Bunu engellemek için kullanıcı bazlı eğitim ve otomatik kaynak profili önerileri faydalıdır.

5. Erişilebilirlik ve SLA Uyumluluğu

System Availability (Sistem Erişilebilirliği)

Cluster’ın planlanmamış kesintiler dahil ne kadar süre erişilebilir olduğunu ölçer. Çoğu kurumsal HPC ortamında hedef %99 veya üzeri erişilebilirlik oranıdır.

Erişilebilirlik (%) = (Toplam Süre - Kesinti Süresi) / Toplam Süre × 100

MTBF ve MTTR

• MTBF (Mean Time Between Failures): İki arıza arasındaki ortalama süre. Donanım güvenilirliğinin göstergesidir.
• MTTR (Mean Time To Repair): Arızanın tespit edilmesinden çözüme kavuşmasına kadar geçen ortalama süre. Operasyon ekibinin etkinliğini ölçer.

KPI’ları Toplamak ve Görselleştirmek

Metrikleri elle takip etmek sürdürülebilir değildir. Aşağıdaki araç zinciri, çoğu HPC ortamında yaygın biçimde kullanılır:

Veri Toplama Katmanı

• Prometheus + Slurm Exporter: Slurm kuyruklarından ve düğüm durumlarından metrik toplar.
• Node Exporter: CPU, bellek, disk I/O ve ağ metriklerini düğüm düzeyinde toplar.
• DCGM Exporter: NVIDIA GPU metriklerini Prometheus formatında sunar.

Görselleştirme Katmanı

• Grafana: Toplanan metrikleri dashboard’lara dönüştürür; uyarı (alert) kuralları tanımlanabilir.
• XDMoD (Open XDMoD): HPC’ye özgü raporlama ve verimlilik analizi için açık kaynaklı bir platform.

Alarmlar

Kritik metrikler için eşik tabanlı alarmlar kurmak reaktif değil proaktif yönetim sağlar:

• CPU kullanımı 15 dakika boyunca %10’un altındaysa uyar.
• Bir düğüm 5 dakikadır yanıt vermiyorsa bildir.
• Belirli bir kullanıcının bekleme süresi 4 saati aştıysa ekibi haberdar et.

Sık Yapılan Hatalar

“Utilization yüksek, o zaman her şey yolunda” yanılgısı: Yüksek kullanım her zaman verimlilik anlamına gelmez. Sistem %95 CPU kullanımında çalışıyor olabilir ama işlerin %30’u başarısız oluyorsa tablo parlak değildir.

Tek metriğe odaklanmak: Bekleme süresi, utilization, throughput ve SLA birlikte değerlendirilmeden sağlıklı bir tablo çizmek mümkün değildir.

Geçmiş veriyi silmek: KPI değerleri zamanla anlam kazanır. En az 12 aylık geçmiş veriyi saklamak, kapasite planlaması için kritik önem taşır.

Sonuç: Ölçemediğinizi Yönetemezsiniz

HPC cluster’ları, kurumların en değerli bilişim altyapıları arasındadır. Bu altyapının ne ölçüde verimli çalıştığını bilmek; hem operasyonel kararlar hem de yatırım planlaması için vazgeçilmezdir. Utilization, throughput, wait time, efficiency ve SLA uyumluluğunu düzenli olarak izleyen bir KPI çerçevesi oluşturmak, reaktif sorun gidermenin ötesine geçip proaktif bir yönetim anlayışı benimsemenizi sağlar.

Mevasis olarak HPC cluster izleme, KPI çerçevesi kurulumu ve Grafana/Prometheus/XDMoD entegrasyonu konularında size destek olmaktan memnuniyet duyarız. İletişim için formu doldurun.