"Yedek sunucumuz var" cümlesi çok farklı şeyler anlatabilir. Bazıları için saniyeler içinde devreye giren bir ikiz sistem, bazıları için raftaki kapalı bir makinedir.
Aradaki fark, kesinti sürenizi belirler. Bu yazı, fiziksel sunucu yedeklilik seviyelerini ve maliyet dengesini anlatıyor.
Üç Seviye
| Tür | Durum | Devreye girme | Maliyet |
|---|---|---|---|
| Soğuk yedek | Kapalı, kurulu değil | Saatler-günler | Düşük |
| Ilık yedek | Açık, kurulu, veri eski | Dakikalar-saatler | Orta |
| Sıcak yedek | Açık, güncel, çalışır | Saniyeler-dakikalar | Yüksek |
Maliyet sütunu yalnızca donanım bedelini göstermez: sıcak yedek, kurulum ve bakım açısından da en yüksek maliyetlidir çünkü iki sistemi sürekli senkron tutmanız gerekir.
Soğuk Yedek
Kullanılmayan bir sunucu hazır bekler. Ana sistem kaybedildiğinde kurulum yapılır, yedek geri yüklenir ve hizmet devam eder.
Uygun olduğu durumlar:
- Kesinti toleransı yüksek sistemler. Bir gün kapalı kalması kabul edilebilir.
- Bütçe kısıtı olan projeler.
- Donanım tedarik süresi uzun olan ortamlar. Yedek parça beklemek yerine hazır makine.
Üçüncü madde çoğu zaman asıl gerekçedir: soğuk yedeğin değeri hızında değil, tedarik süresini ortadan kaldırmasındadır. Yeni bir sunucu siparişi haftalar alabilirken, rafta bekleyen makine hemen kullanılabilir.
Kritik uyarı: soğuk yedek de bakım gerektirir. Yıllarca kapalı bekleyen bir makine, ihtiyaç anında açılmayabilir. Periyodik olarak çalıştırıp test edin.
Ilık Yedek
Sunucu açık, işletim sistemi ve uygulamalar kurulu, ama veri güncel değil — periyodik olarak senkronize edilir.
Devreye alma süreci:
- Son yedek geri yüklenir
- Yapılandırma doğrulanır
- Trafik yönlendirilir
Bu seviyenin kritik parametresi senkronizasyon sıklığıdır: veri saatte bir kopyalanıyorsa, en fazla bir saatlik veri kaybı yaşarsınız.
Ilık yedek, maliyet-fayda dengesi açısından çoğu işletme için en makul seçenektir: sıcak yedeğin karmaşıklığı olmadan, soğuk yedekten çok daha hızlı toparlanma sağlar.
Sıcak Yedek
İki sistem sürekli senkron çalışır. Ana sistem düştüğünde ikincisi devralır — ideal durumda kullanıcı fark etmez bile.
Bu seviye, ciddi bir mimari gerektirir:
- Veri çoğaltma. Veritabanı sürekli senkronize olmalı.
- Dosya senkronizasyonu. Kullanıcı yüklemeleri her iki tarafta olmalı.
- Devralma mekanizması. Arıza tespit edilip trafik yönlendirilmeli.
- Oturum paylaşımı. Kullanıcılar çıkış yapmamalı.
- Sağlık kontrolü. Hangi sistemin sağlıklı olduğu belirlenmeli.
Üçüncü madde en kritik ve en çok sorun çıkaran parçadır: arızayı yanlış tespit eden bir mekanizma, sağlıklı sistemi devre dışı bırakabilir veya her iki sistemin aynı anda aktif olmasına yol açabilir.
Bölünmüş Beyin Sorunu
Sıcak yedek mimarilerinin en tehlikeli senaryosu budur: iki sunucu birbirini göremez ama ikisi de çalışmaktadır.
Sonuç: her iki sistem de kendini aktif sayar ve ikisi de yazma kabul eder. Veriler ikiye bölünür ve birleştirmesi son derece zordur.
Korunma yöntemleri:
- Bağımsız bir hakem. Üçüncü bir nokta, hangi sistemin aktif olacağına karar verir.
- Çoğunluk kuralı. Tek sayıda düğüm kullanılır.
- Zorla kapatma. Devralan sistem, diğerini fiziksel olarak kapatır.
- Ayrı iletişim yolu. Ana ağ dışında ikinci bir kontrol bağlantısı.
Dördüncü madde basit ama etkilidir: iki sunucu arasında ana ağdan bağımsız bir bağlantı kurulursa, ağ sorunu nedeniyle oluşan yanlış arıza tespitleri büyük ölçüde önlenir.
Hangi Seviye Gerekli?
Karar için iki soruyu cevaplayın:
| Soru | Belirlediği |
|---|---|
| Ne kadar kesintiyi göze alabilirsiniz? | Yedeklilik seviyesi |
| Ne kadar veri kaybını göze alabilirsiniz? | Senkronizasyon sıklığı |
Bu iki soruyu somut sayılarla cevaplayın ve kesinti maliyetinizle yedeklilik maliyetini karşılaştırın. Saatlik kesinti maliyetiniz düşükse, sıcak yedeğin karmaşıklığı gereksizdir.
Yaygın bir hata, teknik olarak en gelişmiş çözümü hedeflemektir. Karmaşık bir sıcak yedek mimarisi, yanlış kurulduğunda tek sunucudan daha az güvenilir olabilir — çünkü daha fazla arıza noktası içerir.
Lokasyon Kararı
Yedek sunucu nerede olmalı?
- Aynı kabinde. En hızlı senkronizasyon ama kabin seviyesi sorunlara karşı korumasız.
- Aynı veri merkezinde farklı kabinde. Kabin sorunlarına karşı korur.
- Farklı veri merkezinde. En güçlü koruma ama gecikme artar.
Üçüncü seçenekte önemli bir teknik kısıt vardır: senkron veri çoğaltma, mesafe arttıkça performansı düşürür çünkü her yazma işlemi karşı tarafın onayını bekler.
Bu yüzden uzak lokasyonlarda genellikle asenkron çoğaltma tercih edilir — küçük bir veri kaybı riskiyle performans korunur.
Test Etmek
Bu bölüm, tüm yatırımın işe yarayıp yaramadığını belirler: test edilmemiş bir yedeklilik, yedeklilik değildir.
Test edilmesi gerekenler:
- Planlı devralma. Kontrollü olarak yedeğe geçin.
- Ani arıza simülasyonu. Ana sistemi bilinçli kapatın.
- Geri dönüş. Ana sistem düzeldiğinde nasıl dönülecek?
- Veri tutarlılığı. Devralma sonrası veriler eksiksiz mi?
- Süre ölçümü. Gerçekte ne kadar sürdü?
Üçüncü madde sıkça atlanır ama önemlidir: yedeğe geçmek kadar geri dönmek de planlı olmalıdır. Ana sistem düzeldiğinde veriler yedekte birikmiştir ve geri dönüş, bu verilerin ana sisteme aktarılmasını gerektirir.
Testi yılda en az bir kez, planlı bir bakım penceresinde yapın.
Maliyet Optimizasyonu
Yedek sunucu maliyetini azaltmanın yolları:
- Yedeği daha mütevazı yapılandırın. Geçici olarak düşük performansla çalışmak kabul edilebilir olabilir.
- Yedeği test ortamı olarak kullanın. Boşta beklemesin.
- Yedeklemeleri orada çalıştırın. Ana sistemin yükü azalır.
- Yalnızca kritik bileşenleri yedekleyin. Her şeyi değil.
İkinci madde en yaygın ve en verimli yaklaşımdır: yedek sunucu normal zamanlarda test ortamı olarak kullanılır, acil durumda üretime alınır. Böylece boşta duran bir yatırım olmaktan çıkar.
Ancak dikkat: test ortamı olarak kullanılan bir sunucu, acil durumda temiz bir duruma getirilebilmelidir. Bu geçişi de test edin.
Yedek sunucu için ayrı bir sunucu kiralama sözleşmesi yaparken, ana sunucuyla aynı sağlayıcıda mı farklı sağlayıcıda mı olacağını da değerlendirin — sağlayıcı seviyesindeki bir sorun her ikisini birden etkileyebilir.
Sonuç
"Yedek sunucumuz var" ifadesi, saniyeler içinde devreye giren bir ikiz sistemden raftaki kapalı bir makineye kadar çok farklı şeyler anlatabilir — ve fark, kesinti sürenizi belirler. Seçimi teknik hırsla değil kesinti maliyetinizi yedeklilik maliyetiyle karşılaştırarak yapın; çoğu işletme için ılık yedek en dengeli seçenektir. Sıcak yedek kuruyorsanız bölünmüş beyin senaryosuna karşı önlem alın — yanlış kurulmuş bir sıcak yedek, tek sunucudan daha az güvenilir olabilir. Ve yılda bir kez gerçekten test edin.
Sıkça Sorulan Sorular (SSS)
Hangi yedeklilik seviyesi bana uygun?
İki soruyu somut sayılarla cevaplayın: ne kadar kesintiyi ve ne kadar veri kaybını göze alabilirsiniz? Saatlik kesinti maliyetiniz düşükse sıcak yedeğin karmaşıklığı gereksizdir. Çoğu işletme için ılık yedek en dengeli seçenektir.
Soğuk yedeğin faydası ne?
Hızı değil, tedarik süresini ortadan kaldırması. Yeni bir sunucu siparişi haftalar alabilirken rafta bekleyen makine hemen kullanılabilir. Ancak periyodik olarak çalıştırıp test edin — yıllarca kapalı bekleyen bir makine ihtiyaç anında açılmayabilir.
Bölünmüş beyin sorunu nedir?
İki sunucunun birbirini görememesi ama ikisinin de çalışmaya devam etmesidir. Her ikisi de kendini aktif sayar, ikisi de yazma kabul eder ve veriler ikiye bölünür — birleştirmesi son derece zordur. Ana ağdan bağımsız ikinci bir kontrol bağlantısı, bu riski büyük ölçüde azaltır.
Yedek sunucu boşta mı bekleyecek?
Gerekmez. En yaygın ve verimli yaklaşım, yedek sunucuyu normal zamanlarda test ortamı olarak kullanmak veya yedekleme işlerini orada çalıştırmaktır. Ancak acil durumda temiz duruma getirilebilmesi gerekir — bu geçişi de test edin.
