HPC Operasyonel Yönetim: Günlük Görevler ve En İyi Uygulamalar

Yüksek Başarımlı Hesaplama (HPC) kümeleri, araştırma kurumlarının ve mühendislik şirketlerinin en kritik altyapı bileşenlerinden birini oluşturur. Bu sistemlerin kesintisiz ve verimli çalışması, yalnızca güçlü donanım seçimiyle değil; titiz bir operasyonel yönetim anlayışıyla mümkün olur. Bu yazıda, bir HPC sistem yöneticisinin günlük rutinlerini, yaygın sorunları ve bu sorunlara karşı geliştirilen en iyi uygulamaları ele alıyoruz.

Günlük Operasyon Rutinleri

Sabah Kontrol Listesi

Her iş gününün başında sistem yöneticisi birkaç temel soruyu yanıtlamalıdır: Gece boyunca beklenmedik bir olay yaşandı mı? Tüm node’lar sağlıklı mı? Kuyrukta takılı kalan iş var mı?

Bu soruları otomatik hale getirmek için sabah kontrol scriptleri büyük kolaylık sağlar. Aşağıdaki örnek, Slurm tabanlı bir kümede node durumlarını özetleyen basit bir Bash scriptidir:

#!/bin/bash
# hpc_morning_check.sh — Günlük sabah sağlık özeti

echo "=== HPC Sabah Raporu: $(date) ==="
echo ""

echo "--- Node Durumları ---"
sinfo -o "%N %T %C" | sort -k2

echo ""
echo "--- Drain/Down Node'lar ---"
sinfo -t drain,down -o "%N %T %R" 2>/dev/null || echo "Sorunlu node yok."

echo ""
echo "--- Kuyruk Özeti ---"
squeue --format="%.10i %.9P %.8j %.8u %.8T %.10M %.6D" | head -20

echo ""
echo "--- Dosya Sistemi Kullanımı ---"
df -h /home /scratch /work 2>/dev/null | column -t

echo ""
echo "--- Yüksek CPU Kullanan İşlemler (Login Node) ---"
ps aux --sort=-%cpu | head -6

Bu tür scriptler cron ile her sabah saat 07:00’de çalıştırılarak yöneticiye e-posta olarak gönderilebilir. Sorunların iş saati başlamadan tespit edilmesi, kullanıcı etkisini önemli ölçüde azaltır.

Node Sağlık Kontrolü

Node sağlığı, HPC operasyonunun temel taşıdır. Bir hesaplama düğümünün yavaşlaması ya da tamamen çevrimdışı kalması, o node üzerinde çalışan onlarca işi etkileyebilir.

Pratik olarak izlenmesi gereken başlıca metrikler şunlardır:

Çok sayıda node’u tek tek izlemek yerine, Nagios, Zabbix veya Prometheus gibi merkezi izleme araçları tercih edilmelidir. Özellikle Prometheus + Grafana kombinasyonu, HPC ortamlarında görsel ve anlık takip için yaygın biçimde kullanılmaktadır.

Kuyruk Yönetimi

Slurm ile Etkili Kaynak Yönetimi

İş kuyruğu yönetimi, HPC operasyonunun en karmaşık boyutlarından biridir. Yanlış yapılandırılmış partition’lar, dengesiz kaynak tahsisi ya da aşırı rezervasyon; hem sistem verimliliğini düşürür hem de kullanıcı memnuniyetini azaltır.

Sağlıklı bir kuyruk yönetimi için şu noktalara dikkat edilmelidir:

Partition tasarımı: Kısa süreli test işleri ile uzun süreli üretim işlerini ayrı partition’lara ayırmak, öncelik çakışmalarını önler. Örneğin debug partition’ına maksimum 1 saat ve 2 node sınırı koymak, sistemin test işleriyle tıkanmasını engeller.

QOS (Quality of Service) politikaları: Kullanıcı başına maksimum çalışan iş sayısı, maksimum CPU çekirdeği ve maksimum bellek kotaları QOS ile tanımlanabilir. Bu, tek bir kullanıcının tüm kaynakları ele geçirmesini önler.

Backfill algoritması: Slurm’un varsayılan backfill scheduler’ı, büyük işlerin önünde bekleyen küçük işleri boşlukları doldurarak çalıştırır. Bu özellik aktifse küme kullanım oranı belirgin biçimde artar.

Takılı Kalan İşler

Kuyrukta uzun süre PENDING durumunda kalan işler en sık karşılaşılan sorunlardan biridir. squeue -j <job_id> --start komutu, Slurm’un tahmini başlangıç zamanını gösterir. scontrol show job <job_id> çıktısındaki Reason alanı ise işin neden beklemede olduğunu açıkça belirtir:

• Resources: Yeterli kaynak henüz boş değil.
• Priority: Daha yüksek öncelikli işler sırada bekliyor.
• QOSMaxCpuPerUserLimit: Kullanıcı kota sınırına ulaşmış.
• NodeDown: İstenen node çevrimdışı.

Yöneticinin bu durumları düzenli aralıklarla gözden geçirmesi ve kullanıcıları bilgilendirmesi iletişim açısından kritiktir.

Kullanıcı Desteği ve İletişim

Etkili Yardım Masası Süreçleri

HPC kullanıcıları genellikle araştırmacı veya mühendislerdir; sistem yönetimi konusunda uzman olmayabilirler. Bu nedenle kullanıcı desteği, HPC operasyonunun ayrılmaz bir parçasıdır.

Sık karşılaşılan kullanıcı sorunları şöyle sıralanabilir:

1. İş sonlanmıyor veya çok yavaş: Çoğunlukla bellek yetersizliği, I/O darboğazı ya da yazılım kilitleri söz konusudur. sstat ve sacct komutları geçmiş iş istatistiklerini gösterir.

2. Modül bulunamıyor: module avail ve module spider komutları kullanıcıya tanıtılmalıdır. Ortam modülleri (Lmod veya Environment Modules) ile yazılım yönetimi standartlaştırılmalıdır.

3. Dosya kotası aşımı: /home dizini genellikle küçük tutulur, büyük veri /scratch veya /work üzerinde saklanmalıdır. quota -s komutu kullanıcının mevcut kotasını gösterir.

4. MPI iletişim hataları: Özellikle Infiniband ağında yaşanan bağlantı sorunları, node bazında hata analizi gerektirir.

Kullanıcı taleplerini ticket sistemi (OTRS, JIRA Service Desk, Request Tracker vb.) üzerinden yönetmek, sorunların izlenmesini ve raporlanmasını kolaylaştırır. Her hafta kapanan ve açılan ticket sayısını raporlamak, operasyon kalitesini ölçmek için iyi bir göstergedir.

Bakım Penceresi Yönetimi

Planlı bakımlar, kullanıcıları önceden bilgilendirilerek yapılmalıdır. İyi bir bakım penceresi yönetimi şu adımları içerir:

• Bakımdan en az 1 hafta önce e-posta duyurusu yapılması
• Bakım süresince kümeye iş gönderilmesini engellemek için Slurm rezervasyonu oluşturulması (scontrol create reservation)
• Bakım öncesi tüm çalışan işlerin tamamlanmasına ya da güvenli şekilde sonlandırılmasına izin verilmesi
• Bakım sonrası sistem sağlık testlerinin (IMB-MPI1, HPL, ior gibi benchmark araçlarıyla) yapılması
• Sonuçların kullanıcılara raporlanması

Depolama ve Veri Yönetimi

Scratch Alanı Temizliği

Yüksek kapasiteli /scratch dosya sistemleri, kullanılmayan verilerle hızla dolabilir. Otomatik temizlik politikaları bu sorunu yönetmeyi kolaylaştırır. Örneğin 30 günden eski erişilmemiş dosyaları listeleyen bir komut:

find /scratch -atime +30 -type f -printf "%u\t%s\t%p\n" | sort | head -50

Bu tür politikalar uygulanmadan önce kullanıcılar mutlaka bilgilendirilmeli ve silme işlemi öncesinde uyarı e-postası gönderilmelidir. Bazı kurumlar kademeli uyarı sistemi kullanır: 30 gün uyarı, 45 gün son uyarı, 60 günde silme.

Yedekleme Stratejisi

HPC ortamlarında /home dizini genellikle yedeklenir; /scratch ise tasarım gereği yedeksiz tutulur. Bu ayrımın kullanıcılara açıkça anlatılması gerekir. Kritik hesaplama çıktılarının kullanıcı tarafından kalıcı depolama alanına taşınması sorumluluğu, açık politikalarla belgelenmelidir.

Performans İzleme ve Kapasite Planlaması

Sistem yöneticisi yalnızca anlık sorunlarla değil, uzun vadeli kapasite ihtiyaçlarıyla da ilgilenir. Aylık raporlarda şu metriklerin izlenmesi önerilir:

• Küme kullanım oranı (utilization): Toplam mevcut CPU-saat içinde kullanılan oran. %75-85 aralığı hem kullanıcılar için makul bekleme süresi hem de kurum için verimli kaynak kullanımı anlamına gelir.
• İş başarı/başarısızlık oranı: Yüksek başarısızlık oranı, yazılım, veri veya yapılandırma sorunlarına işaret edebilir.
• Ortalama kuyruk bekleme süresi: Sürekli artan bekleme süreleri, kapasite genişletme ihtiyacının habercisidir.
• Depolama büyüme hızı: Planlama döngüsü için kritik bir girdidir.

Bu metriklerin düzenli olarak yönetime raporlanması, hem altyapı bütçesinin doğru planlanmasını hem de araştırmacıların gereksinimlerinin zamanında karşılanmasını sağlar.

HPC operasyonel yönetimi, teknik bilgi ile sistematik süreç yönetimini bir arada gerektiren dinamik bir disiplindir. Node sağlığından kuyruk politikalarına, kullanıcı desteğinden kapasite planlamasına kadar her katman, sistemin bütünsel verimliliğini doğrudan etkiler. Bu süreçleri doğru araçlar ve iyi tanımlanmış prosedürlerle desteklemek, hem sistem sürekliliğini hem de kullanıcı memnuniyetini önemli ölçüde artırır.

Mevasis olarak HPC operasyonel yönetimi konusunda size destek olmaktan memnuniyet duyarız. İletişim için formu doldurun.