Bağlam
Sanallaştırma ve düzenli yedeklerle "bir sunucu bozulursa" sorusunu cevaplamıştık. Cevaplayamadığımız soru şuydu: merkez binasının tamamı devre dışı kalırsa ne olur? Yangın, uzun süreli elektrik kesintisi, sel ya da bir fidye yazılımı; sebebi fark etmez. Şubelerdeki saha işlemleri, laboratuvar ve muhasebe merkezdeki sunuculara bağlı. Merkez durursa şubeler durur.
Yönetimle konuştuğumuzda ortaya çıkan hedef netti: operasyonun ana işlevleri birkaç saat içinde, veri kaybı bir iş gününün çok altında olacak şekilde ikinci bir yerden çalışabilmeli.
Hedefleri belirlemek
İlk iş her sistem için iki sayıyı yazmaktı: ne kadar veri kaybını kaldırabiliriz (RPO) ve ne kadar süre kapalı kalabiliriz (RTO). Her şeyi "anında" istemek hem pahalı hem gereksizdi; bu yüzden sistemleri üç sınıfa ayırdım. Aşağıdaki değerler yaklaşımı göstermek için temsilidir.
| Sınıf | Sistemler | RPO | RTO |
|---|---|---|---|
| Kritik | Operasyon otomasyonu, ERP ve veritabanı, kimlik servisleri | dakikalar | birkaç saat |
| Önemli | E-posta, dosya sunucusu, uzak bağlantı relay | saatler | aynı gün |
| Ertelenebilir | Raporlama, test ortamı, günlük arşivi | bir gün | bir iş günü |
Bu tablo bütün tasarımın temeli oldu; hangi sistem için hangi replikasyon yöntemini kullanacağım buradan çıktı.
Felaket kurtarma merkezi
İkinci lokasyon olarak merkezden fiziksel olarak uzak, kendi internet hattı ve kesintisiz gücü olan bir yer seçildi. Oraya daha küçük bir sanallaştırma kümesi ve depolama kuruldu; kapasite, yalnızca kritik ve önemli sınıftaki sistemleri taşıyacak kadar. İki lokasyon arasında ayrı bir site-to-site VPN tüneli var; replikasyon trafiği kullanıcı trafiğinden ayrı tutuluyor ve bant genişliği sınırlı.
Replikasyon katmanları
Tek bir yöntem her ihtiyacı karşılamıyor; dört katman birlikte çalışıyor.
- Sanal makine replikasyonu. Kritik ve önemli sınıftaki makineler sanallaştırma katmanında FKM'ye kopyalanıyor; kritik olanlar daha sık. Karşı tarafta makineler kapalı bekliyor; devralmada açılıyor.
- Veritabanı günlük aktarımı. SQL Server için sanal makine kopyası yeterli değil; işlem günlükleri sık aralıklarla ikincil sunucuya aktarılıp uygulanıyor. Böylece veritabanı kopyası her zaman tutarlı ve kısa bir süre geride.
- Dosya eşitleme. Paylaşımlar ve belge arşivi dosya düzeyinde eşitleniyor; büyük ve seyrek değişen veri için en ucuz yöntem.
- Yedek kopyaları. İmaj yedeklerinin bir kopyası FKM'ye, bir kopyası da ağdan bağımsız bir ortama yazılıyor. Fidye yazılımı senaryosunda replikasyon zararı da taşıyacağı için bu katman en önemlisi; geri dönülebilir noktalar haftalarca saklanıyor.
Devralma senaryoları
Her senaryo için adım adım bir runbook var; kimin ne yapacağı, hangi sırayla, hangi komutla. Üç ana senaryo:
- Tek sistem kaybı. Yalnızca bir sunucu bozulmuşsa FKM'ye geçilmez; yerel yedekten ya da replikadan aynı lokasyonda geri açılır. En sık karşılaşılan durum bu.
- Merkez kaybı. Önce kimlik servisleri ve DNS, sonra veritabanı, ardından otomasyon ve ERP FKM'de açılıyor. DNS kayıtları FKM adreslerine çevriliyor; şubeler aynı sunucu adlarıyla çalışmaya devam ediyor, saha programlarında hiçbir ayar değişmiyor.
- Fidye yazılımı. Replikasyon durdurulur, temiz olduğu bilinen son yedek noktası seçilir, sistemler izole ağda açılıp doğrulanır, sonra kullanıma alınır. Burada hız değil temizlik önceliklidir.
Geri dönüş (failback) de senaryonun parçası: merkez tekrar hazır olduğunda FKM'de oluşan veri ters yönde eşitlenip sistemler planlı bir kesintiyle geri taşınıyor.
Tatbikatlar
Kâğıt üzerindeki planın işe yaramadığını ilk tatbikatta gördük: bir servisin başlangıç sırası yanlıştı ve ERP veritabanı açılmadan ayağa kalkmaya çalışıyordu. O günden beri düzenli tatbikat yapıyoruz; bir kısmı duyurulu, bir kısmı habersiz. Her tatbikat sonunda runbook güncelleniyor ve yönetime süre, veri kaybı ve açık noktaları içeren tek sayfalık bir rapor gidiyor. Son tatbikatlarda devralma, hedeflenen sürenin altında tamamlandı.
Öğrendiklerim
Felaket kurtarmanın teknik kısmı kısa sürede kurulur; zor olan onu canlı tutmaktır. Yeni bir sunucu açıldığında replikasyon listesine eklenmezse plan sessizce eskir. Bu yüzden yeni sunucu açma şablonuna "FKM sınıfı" alanı ekledim; sınıf seçilmeden makine açılmıyor. Bir de şunu öğrendim: tatbikat yapılmamış bir felaket planı, plan değil umuttur.