Sunucu Donanım Yenilemesi Ne Zaman Yapılmalı? Net Rehber

Sunucu donanım yenilemesi, yalnızca “yeni cihaz alalım” kararı değildir. Performans düşüşünü, arıza riskini ve özellikle disk/IO darboğazlarını doğrudan etkiler. Bu rehberde, ne zaman yenileme yapılması gerektiğini sayısal sinyallerle açıklıyorum; ayrıca doğru planlama için kapasite hesaplama, izleme (monitoring) ve geçiş adımlarını netleştiriyorum.

Sunucu yenilemesini tetikleyen 7 somut sinyal

Donanım yenilemesini ertelemek zaman kazandırır; fakat yanlış gecikme, hizmet kesintisi ve veri kaybı riskini artırır. Aşağıdaki sinyallerin birden fazlası aynı anda görülüyorsa “yenileme zamanı” yaklaşmıştır.

1) CPU kullanımında kalıcı doygunluk

Sistemler anlık artışlara izin verir, ancak CPU’nun uzun süre yüksek kalması (özellikle normal trafik altında) donanımın yetişmediğini gösterir. - İzleme hedefi: CPU ortalaması %60-70 bandını uzun süre aşmaya başladıysa ve bu artış “sadece bir gün” değilse değerlendirin. - Daha net karar: CPU %80-90 bandında kalıyorsa ve bekleme (load) artıyorsa yenileme veya ölçekleme (scale up/scale out) gündeme alınır.

2) RAM yetersizliği ve swap (takas) artışı

RAM doluluğu, uygulamaların önbelleğe (cache) erişimini azaltır; Linux’ta swap kullanımı artınca disk I/O daha fazla yüklenir. - İzleme hedefi: Swap kullanımı düzenli olarak artıyor ve birkaç saatten uzun sürüyorsa donanım yenilemesi gerekir. - Belirti: Aynı isteklerde yanıt süreleri giderek uzuyorsa “RAM + uygulama bellek ayarları” birlikte ele alınmalıdır.

3) Disk/IO darboğazı: IOPS tavanı ve yüksek latens

Donanım yenilemesinin en sık gözden kaçan tarafı disk ve IOPS’tur. Özellikle veritabanı (MySQL/MariaDB/PostgreSQL) ve yoğun log üreten sistemlerde. - Net sinyal: Disk I/O latensi artıyor, kuyruk (queue) büyüyor. - Pratik eşik: Uygulama yanıt süresi düşmeyen bir şekilde uzuyorsa ve aynı anda disk latensi yükseliyorsa IOPS kaynağı yetersizdir.

4) “Disk doldu” değil, “disk dolmak üzere” alarmı

Disk dolması genellikle tek bir hata anında fark edilir; ama asıl problem doluma giden yoldur. - İzleme hedefi: Disk kullanımında günlük büyüme trendi sabitse, 4-6 hafta içinde kritik seviyeye girecek görünüm varsa yenileme/planlama yapın. - Net eşik: Uygulama ve loglar için rezerv alan bırakmadan (%80 üstü) ilerlemek risklidir.

5) Arıza ve üretim riski: SSD/HDD yaşlanması

Depolama cihazlarının “yaş” metriği yoksa bile değişim planı yapılmalıdır. Donanım yenileme zamanı genellikle arıza olasılığıyla ilişkilidir. - Net yaklaşım: SSD/HDD sağlık durumunu SMART verileriyle izleyin. - Eğer reallocated (yeniden atanan sektör) ve benzeri uyarılar artıyorsa yenileme zamanı yaklaşır.

6) Ağ kartı/port kapasitesi artık yetmiyor

1 Gbit porttan 10 Gbit porta geçmek bazı senaryolarda dramatik fark yaratır; bazı senaryolarda ise darboğaz yine disk veya uygulama olur. - Net sinyal: Trafik artışıyla birlikte sistem yanıt süreleri de artıyorsa ve ağ kullanımında doygunluk varsa ağ yenilemesi değerlendirilir. - Ancak: Yük testinde (load test) önce CPU/RAM/disk darboğazı çıkıyorsa ağ değişimi etkisiz kalır.

7) Güvenlik ve bakım ömrü: BIOS/iDRAC/firmware güncellemeleri durmuşsa

Donanım yenilemesi yalnız performans değil güvenlik içindir. - Net sinyal: Sunucu firmware/BIOS/iDRAC (veya benzeri yönetim bileşeni) güncellemeleri kesildiyse veya kritik güvenlik yamaları yayımlanmıyorsa donanım yenilemesi gerekir.

Yenileme takvimi: Ortalama olarak doğru yaklaşım

Her ortam için tek tarih yoktur; fakat yönetilebilir bir çerçeve kullanmak planlamayı kolaylaştırır.

Önerilen planlama modeli

• 12-18 ay: Performans düşüşü sinyalleri varsa ve depolama/IO başlıca darboğaz ise “ölçekleme/yenileme” değerlendirmesi.
• 36 ay: Sunucu sınıfına göre bakım ömrünün bitme ihtimali artar; disk ve yönetim bileşenlerinde risk yükselir.
• Sürekli: Firmware, kontrol yazılımları ve işletim sistemi güncellemeleri. Donanım yenilemesi “güncelleme bitince” değil, risk seviyesine göre yapılır.

Not: Virtualized (sanallaştırılmış) altyapılarda bile “fiziksel host” yenilemesi performans ve arıza riski açısından aynı şekilde değerlendirilmeli.

“Yenileyelim mi?” kararını sayısal hale getirme

Kararı kolaylaştıran şey, hangi kaynağın tıkandığını net ölçmektir. Aşağıdaki adımlar, VDS/VPS/dedicated sunucu fark etmeksizin uygulanır.

1) 4 metrikle darboğazı bulun (CPU/RAM/Disk AIOPS/Ağ)

Aşağıdaki tablo, pratik eşleştirmeyi sağlar.

2) Kapasite büyümesini hesaplayın (disk + veri tabanı)

Yalnızca anlık disk kullanımına bakmak hatalıdır. Şu hesap daha net karar verir: - Son 30-60 gün: disk büyüme hızı (GB/gün) - Altyapının veri tutma süresi (retention) - Log birikimi ve yedek (backup) hacmi - Kritik eşikler: log rotasyon planı, yedek saklama süresi

Örnek mantık: Eğer disk 120 gün içinde %80 eşiğini geçecekse ve log/backup trendi aynı kalıyorsa, “yedek alıyorum, bir şey olmaz” varsayımı yerine donanım veya planlama aksiyonu gerekir.

3) Maliyet karşılaştırmasını “kesinti maliyeti” ile yapın

Donanım yenilemenin maliyeti sadece satın alma bedeli değildir. - Planlı geçişin maliyeti: yedekleme, test, taşıma (migration) - Plan dışı arızanın maliyeti: kesinti, müşteri kaybı, veri kurtarma

Net öneri: Eğer arızaya yakın sinyal (disk health düşüşü, firmware end-of-life) varsa, “beklemek” seçeneği çoğu zaman daha pahalı çıkar.

Veritabanı ve depolama için özel yenileme kuralları

Veritabanı (MySQL/PostgreSQL) barındıran sunucularda yenileme kararının ağırlığı disk I/O ve RAM’e kayar.

IOPS ve latensi tek başına inceleyin

• Yalnız IOPS sayısı değil, I/O latency birlikte değerlendirilmelidir.
• Aynı zamanda bağlantı (connections) sayısı ve sorgu süresi uzuyorsa önce “query optimizasyonu” gerekir; aksi halde salt donanım yenilemek kalıcı çözüm olmaz.

RAID düzeneğini “performans + güvenlik” dengesiyle ele alın

RAID seviyeleri performansı etkiler: - Yaz yoğun senaryolarda RAID düzeni yaz performansını değiştirebilir. - Veri güvenliği için RAID gereklidir, fakat “en hızlı RAID” her zaman en doğru değildir.

Bu noktada net süreç: RAID/depoma tasarımını uygulamanın okuma/yazma oranına göre yeniden planlayın; ardından kapasite artışıyla yenilemeyi birlikte ele alın.

Planlama: Yenileme zamanı gelince yapılacak iş listesi

Donanım yenilemesi, taşımayı etkileyen çok sayıda parametre içerir. Aşağıdaki kontrol listesi, geçiş riskini düşürür.

Hedef: sıfıra yakın kesinti ve veri bütünlüğü

• Yedekleme doğrulaması: Yedek alındıktan sonra “restore test” yapılır.
• Zamanlama: Trafiği düşük saatlerde geçiş planlayın.
• Paralel test: Yeni donanım üzerinde staging/clone ortamında performans test edin.

Taşıma (migration) için minimum kontroller

• DNS TTL (Time To Live) planı: Geçişte TTL’yi düşürmek, yönlendirme değişimini hızlandırır.
• Uygulama konfigürasyonu: Çevresel değişkenler (env), bağlantı string’leri, servis portları.
• Log ve izleme: Geçiş sonrası hata oranı ve gecikme metrikleri izlenir.

Yedekleme (backup) stratejisi yenileme kadar önemlidir

• Tek yedek noktasına bağlı kalmayın: Yedek kopyasının saklama süresi ve erişimi test edilmelidir.
• Yedek şifreleme ve erişim yetkileri: Yetkisiz erişim riskini azaltın.

Sunucu yenilemesi mi, ölçekleme mi? Net ayrım

Donanım yenilemesi ile “scale up/scale out” aynı şey değildir.

• Scale up (tek makinede yükseltme): CPU/RAM/disk kapasitesini artırmak.
• Scale out (daha fazla makine): Trafiği bölmek, yük dengeleme kullanmak.

Net karar kuralı: - Tek bir kaynak (örn. disk IOPS) belirgin tıkandıysa scale up genellikle en hızlı çözümdür. - Uygulama yatay ölçeklenebiliyorsa (stateless servisler gibi) scale out daha sürdürülebilir olur.

Sonuç: Aksiyon planı (bugün başlayabileceğiniz şekilde)

Sunucu donanım yenilemesi zamanı, “kaç yıl oldu” yerine hangi kaynağın tıkandığı ve riskin ne seviyede olduğuyla belirlenmelidir. CPU/RAM/swap, disk latensi/IOPS, disk büyüme trendi ve firmware/arıza sinyallerini birlikte değerlendirin. Ardından staging üzerinde performans testi yapın, yedek (backup) ve restore doğrulamasını tamamlayın.

Aksiyona başlamak için önerilen sıra: Önce son 30 gün metriklerini çıkarın (CPU/RAM/swap/disk latensi/disk büyüme) → darboğaz kaynağını belirleyin → yenileme (veya ölçekleme) senaryosunu maliyet + kesinti riskiyle karşılaştırın → geçişi planlı pencerede gerçekleştirin. Bu sıra, gereksiz yenilemeyi azaltır ve performans hedefini kısa sürede tutturur.