HPC Disaster Recovery: İş Sürekliliği Planlaması

Yüksek performanslı hesaplama (HPC) sistemleri; ilaç araştırmaları, iklim modellemesi, yapay zeka eğitimi ve mühendislik simülasyonları gibi kritik iş yüklerini taşır. Bu hesaplamalar saatler, günler hatta haftalar sürebilir. Donanım arızası, güç kesintisi veya yazılım hatası nedeniyle yarım kalan bir iş, yalnızca zaman kaybı değil; araştırma bütçelerinin ve proje takvimlerinin çökmesi anlamına gelir. Bu yüzden HPC ortamlarında Disaster Recovery (Felaket Kurtarma) planı, lüks değil zorunluluktur.

Bu yazıda HPC iş sürekliliği planlamasının temel bileşenlerini — RTO/RPO hedefleri, yedekleme stratejileri, checkpoint/restart mekanizmaları ve failover mimarisi — pratik bir perspektiften ele alacağız.

RTO ve RPO: HPC’de Ne Anlama Gelir?

Genel BT dünyasından aşina olunan iki kavramı HPC bağlamına uyarlamak gerekir:

• RTO (Recovery Time Objective): Bir kesinti sonrası sistemin yeniden işlev kazanması için kabul edilebilir maksimum süre.
• RPO (Recovery Point Objective): Veri kaybının tolere edilebildiği maksimum zaman dilimi; yani “en son kurtarılabilir noktaya” kadar olan süre.

HPC’de bu iki parametre, birbirinden çok farklı ağırlıklar taşıyabilir. Saatlik bir CFD (Hesaplamalı Akışkanlar Dinamiği) simülasyonunda 30 dakikalık bir RPO kabul edilebilirken, bir ilaç moleküler dinamik çalışmasında sıfıra yakın RPO hedeflenmesi gerekebilir. Aşağıdaki tablo tipik HPC senaryoları için örnek değerler sunar:

RTO ve RPO hedeflerini belirlemeden yedekleme veya failover tasarımı yapmaya çalışmak, rotası belirsiz bir gemide dümen tutmak gibidir.

Yedekleme Stratejileri

3-2-1 Kuralını HPC’ye Uygulamak

Klasik 3-2-1 yedekleme kuralı — 3 kopya, 2 farklı ortam, 1 site dışı — HPC’de de geçerliliğini korur; ancak hacim boyutları nedeniyle uygulanması daha titiz planlama gerektirir.

HPC ortamlarında yedeklenmesi gereken üç ana varlık grubu vardır:

1. Sistem durumu ve konfigürasyon: SLURM veya PBS konfigürasyon dosyaları, ağ topolojisi, Lustre veya GPFS dosya sistemi konfigürasyonu, kullanıcı ve proje tanımları.
2. Aktif iş verileri: Hesaplama sırasında üretilen ara çıktılar, log dosyaları ve checkpoint dosyaları.
3. Sonuç verileri ve kaynak kodları: Simülasyon çıktıları, eğitilmiş model ağırlıkları, analiz betikleri.

Artımlı ve Diferansiyel Yedekleme

Petabayt düzeyindeki HPC depolama alanlarında tam (full) yedekleme her gün yapılabilir değildir. Pratikte en yaygın yaklaşım şudur:

• Haftalık tam yedekleme (pazar günü penceresi)
• Günlük artımlı yedekleme (yalnızca değişen bloklar)
• Saatlik checkpoint snapshot’ları (kritik işler için)

rsync tabanlı basit bir artımlı yedekleme betiği:

#!/bin/bash
# HPC artımlı yedekleme betiği
# Çalıştırma: crontab ile her gece 02:00'de

SRC="/scratch/active_jobs/"
DEST="/backup/hpc-incremental/"
LOG="/var/log/hpc-backup/$(date +%Y%m%d).log"
SNAPSHOT_LINK="/backup/hpc-incremental/latest"

rsync -avz \
  --delete \
  --link-dest="${SNAPSHOT_LINK}" \
  --exclude="*.tmp" \
  --exclude="core.*" \
  "${SRC}" \
  "${DEST}/$(date +%Y%m%d_%H%M%S)/" \
  2>&1 | tee "${LOG}"

# En güncel snapshot'a sembolik link güncelle
ln -snf "${DEST}/$(date +%Y%m%d_%H%M%S)" "${SNAPSHOT_LINK}"

echo "Yedekleme tamamlandı: $(date)" >> "${LOG}"

Bu betik --link-dest sayesinde değişmeyen dosyaları hard link olarak referanslar; böylece her snapshot tam kopya gibi görünse de disk kullanımı yalnızca değişen dosyalar kadar artar.

Checkpoint/Restart: HPC’nin En Kritik DR Aracı

Genel BT dünyasında yedekleme denilince genellikle dosya ve veritabanı kopyalaması akla gelir. HPC’de buna ek olarak uygulama düzeyinde checkpoint mekanizması, iş sürekliliğinin bel kemiğini oluşturur.

Checkpoint Nedir?

Checkpoint, bir hesaplama işinin belirli bir anındaki tüm bellek durumunu, işlemci kayıt değerlerini ve dosya tanımlayıcılarını diske yazmaktır. Böylece sistem arızalandığında iş baştan değil, en son checkpoint noktasından yeniden başlatılabilir.

DMTCP ile Şeffaf Checkpoint

DMTCP (Distributed MultiThreaded CheckPointing), MPI uygulamaları dahil pek çok HPC uygulamasını kaynak koduna dokunmadan checkpoint edebilir:

# DMTCP ile MPI işini başlatma
dmtcp_launch --interval 3600 \
  mpirun -np 256 ./my_simulation input.dat

# Kesinti sonrası kurtarma
dmtcp_restart --interval 3600 \
  ckpt_my_simulation_*.dmtcp

--interval 3600 parametresi, her 3600 saniyede (1 saatte) bir otomatik checkpoint alınmasını sağlar. Bu değer RPO hedefinize göre ayarlanmalıdır.

SLURM’da Checkpoint Entegrasyonu

SLURM job scheduler, checkpoint oluşturmayı ve yeniden başlatmayı yerel olarak destekler. İş tanımına aşağıdaki direktifler eklenerek bu özellik etkinleştirilebilir:

#!/bin/bash
#SBATCH --job-name=simülasyon_alpha
#SBATCH --nodes=16
#SBATCH --ntasks-per-node=32
#SBATCH --time=72:00:00
#SBATCH --checkpoint=00:30:00        # Her 30 dakikada checkpoint
#SBATCH --checkpoint-dir=/checkpoint/proj_alpha/

# İş başlangıcında mevcut checkpoint var mı kontrol et
if [ -d "/checkpoint/proj_alpha/${SLURM_JOB_ID}" ]; then
  echo "Checkpoint bulundu, yeniden başlatılıyor..."
  srun ./simulation --restart /checkpoint/proj_alpha/${SLURM_JOB_ID}
else
  echo "Yeni iş başlatılıyor..."
  srun ./simulation --input input.dat
fi

Failover Mimarisi

Aktif-Pasif Yapılandırma

Çoğu kurumsal HPC ortamında tercih edilen temel failover mimarisi aktif-pasif çiftlemedir:

• Birincil küme: Tüm üretim iş yüklerini üstlenir.
• İkincil küme (hot standby): Birincil kümenin konfigürasyonunu ve kritik verilerini senkron veya near-senkron biçimde tutar; arıza anında devreye girer.

Bu yaklaşımda dikkat edilmesi gereken nokta, birincil kümeden ikincile geçişin (failover) otomatik mi yoksa manuel mi tetikleneceğidir. Otomatik failover hız kazandırır; ancak yanlış pozitif (split-brain) senaryolarına yol açabilir. Büyük HPC ortamlarında genellikle “izleme sistemi uyarısı → operatör onayı → otomatik geçiş” şeklinde yarı otomatik bir akış tercih edilir.

Depolama Katmanında Replikasyon

HPC’de depolama arızası, işlemci veya ağ arızasından çok daha yıkıcı sonuçlar doğurabilir. Lustre veya GPFS gibi paralel dosya sistemlerinde replikasyon şu yöntemlerle sağlanabilir:

• Synchronous mirroring: Her yazma işlemi ikincil siteye de yansıtılır. RPO sıfır, ancak gecikme maliyeti var.
• Asynchronous replication: Belirli aralıklarla (dakika veya saatlik) ikincil siteye kopyalama. Daha az gecikme, ancak veri kaybı riski.
• Snapshot tabanlı replikasyon: Periyodik snapshot’lar ikincil siteye transfer edilir. Büyük hacimler için ekonomik ve pratik.

Ağ ve Yönetim Düzleminin Korunması

Hesap sunucuları, iş planlayıcısı (scheduler master), kimlik doğrulama servisleri (LDAP/AD) ve izleme sistemi gibi yönetim bileşenleri de DR planının kapsamına alınmalıdır. Bu bileşenler genellikle küçük footprint kaplar; ancak arızalandıklarında tüm küme erişilemez hale gelir.

DR Planının Test Edilmesi

Yazılı bir DR planı, test edilmediği sürece yalnızca kağıt üzerinde var olan bir güvencedir. HPC ortamlarında önerilen test sıklıkları:

• Yedekleme bütünlüğü doğrulaması: Aylık — yedekten rastgele dosya geri yükleme testi.
• Checkpoint kurtarma testi: Üç ayda bir — gerçek bir iş checkpoint’ten yeniden başlatılır.
• Kısmi failover tatbikatı: Altı ayda bir — tek bir rack veya node grubunun devre dışı bırakılması simüle edilir.
• Tam DR tatbikatı: Yıllık — birincil site erişilemez kabul edilerek ikincil siteye tam geçiş test edilir.

Her tatbikat sonrasında bulgular belgelenmeli ve plan güncellenmelidir. Tatbikat belgesi, hem ekip içi bilgi birikimini hem de olası denetimler için uyumluluk kanıtını oluşturur.

Sonuç ve Özet Kontrol Listesi

Etkili bir HPC DR planı, teknik araçların ötesinde organizasyonel bir olgunluk gerektirir. Teknik ekipler, araştırmacılar ve yönetim arasında RTO/RPO hedefleri üzerinde anlaşılmalı; sorumluluklar netleştirilmeli ve tatbikatlar düzenli aralıklarla tekrarlanmalıdır.

Başlangıç için şu adımları izleyin:

• RTO ve RPO hedeflerini iş paydaşlarıyla birlikte belirleyin
• Kritik veri gruplarını sınıflandırın (konfigürasyon / aktif / sonuç)
• 3-2-1 yedekleme mimarisini uygulayın
• Uzun süren işler için DMTCP veya uygulama düzeyinde checkpoint entegre edin
• SLURM job tanımlarına checkpoint direktiflerini ekleyin
• Depolama replikasyon stratejisini seçin (senkron / asenkron / snapshot)
• Yönetim bileşenlerini (scheduler, LDAP, izleme) DR kapsamına alın
• Yılda en az bir kez tam DR tatbikatı yapın

Mevasis olarak HPC iş sürekliliği ve felaket kurtarma planlaması konusunda size destek olmaktan memnuniyet duyarız. İletişim için formu doldurun.