İş sürekliliği; bir cihaz arızalandığında, bağlantı kesildiğinde veya bakım gerektiğinde kritik işlerin devam edebilmesi için altyapıyı, uygulamaları ve çalışma düzenini birlikte tasarlamaktır. High Availability (HA) ve yedeklilik, bileşen arızalarının hizmete etkisini azaltır. Disaster Recovery (DR), ana ortamın kullanılamadığı daha büyük olaylarda hizmetleri alternatif ortamda yeniden çalıştırmayı sağlar.
Bir sunucu dursa da işletmeniz çalışmaya devam etsin.
Sipariş almak, üretimi takip etmek, otel misafirini karşılamak veya sevkiyatı tamamlamak için birden fazla sistem birlikte çalışır. Sunucular açık olsa bile tek bir ağ cihazı, kimlik doğrulama servisi ya da internet bağlantısı bu akışı durdurabilir. İş sürekliliği çalışmasına bu nedenle cihaz listesinden önce işletmenizin durmaması gereken süreçlerinden başlıyoruz.
Her süreç için uygulama, veritabanı, depolama, ağ, enerji ve dış hizmet bağımlılıklarını çıkarıyoruz. Hangi arızanın hangi işi durduracağını, alternatif yolun nasıl devreye gireceğini ve kalan altyapının yükü taşıyıp taşıyamayacağını değerlendiriyoruz. Hedef; arıza anında çözüm aramak zorunda kalmadan, önceden tasarlanmış ve denenmiş bir çalışma düzenine sahip olmanız.
Devamlılığı sağlayan altı altyapı katmanı
Sunucu ve sanallaştırma
Cluster, uygun HA politikaları ve arıza sonrasında yeterli kaynak rezervi. Kritik sanal makinelerin aynı fiziksel arızadan birlikte etkilenmesini azaltan yerleşim kuralları.
Ağ ve bağlantı
Yedekli switch ve Firewall yapıları, alternatif internet ve lokasyon bağlantıları. Cihazın yanında kablo güzergâhı, operatör ve enerji bağımlılıklarının da değerlendirilmesi.
Depolama ve veri yolları
Disk korumasının ötesinde denetleyici, bağlantı ve depolama erişim yollarının incelenmesi. Ortama uygun Multipathing ve replikasyon tasarımı. Multipathing ile depolamaya birden fazla erişim yolu sağlanması.
Uygulama ve veritabanı
Uygulamanın desteklediği Load Balancing, Clustering ve veritabanı Failover modelleri. Oturumlar, dosyalar, zamanlanmış işler ve entegrasyonların birlikte ele alınması.
Enerji ve fiziksel ortam
UPS, uygun alternatif enerji beslemesi, soğutma ve çevresel izleme. İki güç kaynağının aynı elektrik hattına bağlı olması gibi ortak arıza noktalarının belirlenmesi.
Monitoring ve operasyon
Hizmet sağlığı, kapasite ve erişimin takibi; bakımın aşamalı yürütülmesi. Arıza, otomatik Failover ve insan müdahalesi için açık görev dağılımı.
HA, yedekleme ve Disaster Recovery nerede devreye girer?
Bu üç yapı farklı olaylara cevap verir. High Availability (HA), belirli bileşen arızalarında hizmetin başka bir kaynak üzerinden sürmesini hedefler. Yedekleme geçmişteki bir veri noktasına dönme imkânı sağlar. Disaster Recovery (DR), ana ortam kullanılamadığında uygulamaları, veriyi ve erişimi alternatif bir çalışma ortamında bir araya getirir.
| Olay | Devreye giren yapı | Doğrulanacak sonuç |
|---|---|---|
| Fiziksel sunucu arızası | HA ve yeterli yedek kapasite | Kritik iş yükünün diğer sunucuda çalışması ve kullanıcı erişimi |
| Hatalı veri silme veya bozulma | Uygun saklama ve geri yükleme | Doğru veri noktasına dönüş ve kayıtların tutarlılığı |
| Lokasyonun kullanılamaması | Alternatif ortam ve DR planı | Bağımlılıklarıyla birlikte uygulamanın çalıştırılması |
| Planlı bakım | Aşamalı bakım ve iş yükü devri | Kalan kapasiteyle kabul edilebilir hizmet seviyesinin sürmesi |
Tablonun tamamı için yana kaydırabilirsiniz.
Örneğin bir virtualization cluster’ın arızalanan sunucudaki sanal makineyi diğer sunucuda yeniden başlatması, uygulamanın hiç kesilmediği anlamına gelmez. Yeniden başlatma ve uygulamanın toparlanması zaman alabilir. Daha düşük kesinti toleransı olan işlerde uygulama veya veritabanı seviyesinde ek bir tasarım gerekir. Yedek depolamanın varlığı da bu gereksinimi tek başına karşılamaz.
İki cihazın gerçekten yedekli çalışması için
Ortak arıza noktalarını ayırmak gerekir. İki sunucu aynı tek depolamaya, iki internet hattı aynı bina girişine veya iki Firewall aynı enerji hattına bağımlıysa görünürdeki yedekliliğin koruma kapsamı sınırlı kalabilir. Failure Domain (aynı arızadan etkilenebilecek bileşenler); cihaz, kabinet, elektrik hattı, bina ve lokasyon seviyesinde ayrı ayrı değerlendirilir.
Failover kararının güvenli olması gerekir. Cluster node’ları birbirini göremediğinde iki tarafın da aynı veriye yazmaya çalışması, Split Brain durumuna ve veri bütünlüğü sorunlarına yol açabilir. Quorum, witness ve fencing gibi mekanizmalar kullanılan platformun mimarisine göre tasarlanır. Microsoft’un quorum witness dokümantasyonu, witness bileşeninin yerleşiminin de bu tasarımın bir parçası olduğunu gösterir.
Kalan sistemin kapasitesi yetmelidir. Üç sunuculu bir yapıda bir sunucu kaybedildiğinde kritik işlerin iki sunucuda çalışması bekleniyorsa RAM, işlemci ve depolama performansı bu koşulda ölçülmelidir. Replikasyon ve yeniden eşitlemenin oluşturduğu ek yük de hesaba katılır. Normal günde çalışan bir mimarinin arıza gününde de aynı işi yapabilmesi gerekir.
- Kullanıcı ve şubelerAlternatif erişim yolları
- Ağ ve güvenlikYedekli geçiş ve kontrollü erişim
- Uygulama katmanıHealth Check ve Failover
- Veri katmanıTutarlılık, replikasyon ve koruma
Bütün katmanlarda: bağımsız Failure Domain’ler, kapasite rezervi, izleme ve test. Ayrı koruma hattında: güvenli yedekler ve alternatif kurtarma ortamı.
İş ihtiyacını ölçülebilir hedefe dönüştürüyoruz.
Herkese aynı süreyi veya aynı mimariyi önermek yerine iş etkisi analiziyle öncelikleri belirliyoruz. Bir üretim takip sistemiyle aylık arşiv raporunun kesinti toleransı aynı olmayabilir. Sistem başına hedef koyarken, işin en yavaş toparlanan bağımlılığı da dikkate alınır.
- Erişilebilirlik hedefi: Hangi hizmet, hangi saatlerde ve hangi ölçüm noktasından çalışır kabul edilecek?
- RTO: Bir kesintiden sonra hizmetin tekrar kullanılabilir olması için hedeflenen süre.
- RPO: Kurtarmada geri dönülen veri noktasının olaydan ne kadar geride olabileceği.
- Değişiklik ve bakım hedefi: Hangi işlemler iş yükü devredilerek yapılabilir, hangileri kontrollü kesinti gerektirir?
Bu hedefler tasarım girdisidir; ancak kurulum, test ve işletim kapsamıyla birlikte doğrulandığında bir hizmet taahhüdüne dönüşebilir. NIST’in süreklilik ve kurtarma planlama rehberi de iş etkisi, önceliklendirme, test ve plan bakımını birlikte ele alır.
Kurduğumuz yapının çalıştığını nasıl doğrularız?
Testin amacı yalnız bir sunucunun yeniden açıldığını görmek değildir. Yetkili iş birimi, uygun test senaryosuyla siparişe ulaşabildiğini, üretim kaydını işleyebildiğini veya sevkiyatı tamamlayabildiğini doğrular. Planlanan testler kapsam ve bakım koşullarına göre uygulanır; işletmenizin üretim güvenliğini etkileyen işlemler ilgili ekiplerle koordine edilir.
| Test senaryosu | Ölçüm | Kabul ölçütü |
|---|---|---|
| Bir sunucunun kaybı | Arıza tespiti, Failover ve uygulamanın hazır olma süresi | Kritik işlemin hedeflenen sürede yapılabilmesi |
| Bir bağlantının kesilmesi | Alternatif yol, oturum ve DNS davranışı | Kullanıcının gereken hizmete erişmesi |
| Planlı bakım | Kalan kapasite ve uygulama yanıt süresi | Bakım sırasında kararlaştırılan hizmet seviyesinin korunması |
| Alternatif ortamda çalışma | Veri noktası, erişim ve iş birimi kabulü | RTO/RPO ve iş senaryosu hedeflerinin doğrulanması |
Tablonun tamamı için yana kaydırabilirsiniz.
Çalışmanın sonunda bağımlılık haritası, tekil arıza noktaları, hedef mimari, aşamalı uygulama planı ve test sonuçları ortaya çıkar. Altyapı değiştikçe bu belgeler de güncellenir. Böylece iş sürekliliği yalnız kurulum sırasında konuşulan bir proje olmaktan çıkar; günlük işletimin ve planlı bakımın parçası olur.
Sık sorulan sorular
İş sürekliliği yalnız yedekleme hizmeti mi?
Hayır. Öncelikle kritik işlerin arıza veya bakım sırasında devamını sağlayacak altyapı ve operasyon düzeni tasarlanır. Yedekleme, yanlış veri veya kayıp durumunda geri dönüş için bu yapının bir parçasıdır.
HA (High Availability) sıfır kesinti anlamına mı gelir?
Her mimaride değil. Bir sanal makinenin başka sunucuda yeniden başlatılması kısa bir kesinti yaratabilir. Uygulama seviyesindeki devamlılık ihtiyacı, veri tutarlılığı ve kabul edilen geçiş süresi ayrıca tasarlanır.
Mevcut sunucularımızla yedekli yapı kurulabilir mi?
Donanım, platform desteği, ağ ve depolama yapısı değerlendirilerek karar verilir. Yalnız sunucu sayısı değil, arıza sonrası kullanılabilir kapasite ve ortak bağımlılıklar da önemlidir.
İş sürekliliği için her şeyi buluta taşımamız gerekir mi?
Gerekmez. Şirket içinde, veri merkezinde veya birlikte çalışan bir yapıda tasarlanabilir. Yerleşim kararı uygulama bağımlılıkları ve iş hedeflerine göre verilir.
LivePatch ve Live Migration bu yapıya nasıl katkı sağlar?
Desteklenen güncellemeler için LivePatch, uygun iş yüklerinde Live Migration planlı bakımın etkisini azaltabilir. Her güncelleme veya arıza için kesintisiz çalışma sağlamaz; ürünün kapsamı ve uygulamanın davranışı doğrulanır.