Bir veri merkezinin deprem, yangın veya sel nedeniyle devre dışı kalması, aynı tesiste çalışan tüm BT sistemlerini etkileyebilir. Sunucuların yedekli olması, disklerin RAID yapılandırmasıyla korunması veya düzenli yedek alınması bu riski tek başına ortadan kaldırmaz. Çünkü fiziksel bir tesisin tamamına erişilemediğinde, aynı lokasyondaki yedek donanım da kullanılamaz hâle gelebilir.
Bu riski azaltmanın yollarından biri, kritik altyapıyı fiziksel olarak ayrı veri merkezlerine dağıtan coğrafi yedeklilik (geographic redundancy) mimarisidir. Verilerin iki lokasyonda eşzamanlı tutulduğu NetApp MetroCluster gibi çözümler, ana veri merkezinin kaybedilmesi durumunda alternatif lokasyondaki depolama kaynaklarının devreye alınmasını sağlar.
Ancak coğrafi yedeklilik yalnızca verilerin ikinci bir yerde saklanması değildir. Gerçek iş sürekliliği; veri replikasyonu, sunucu ve ağ altyapısı, uygulama bağımlılıkları, kurtarma hedefleri ve düzenli felaket kurtarma testlerinin birlikte planlanmasını gerektirir.
Coğrafi yedeklilik nedir?
Coğrafi yedeklilik, kritik BT sistemlerinin ve verilerin farklı fiziksel lokasyonlarda konumlandırılmasıdır. Birincil veri merkezinde meydana gelen bölgesel veya tesis düzeyindeki bir arızanın diğer lokasyondaki altyapıyı da etkilemesini önlemek amaçlanır.
Standart bir coğrafi yedeklilik mimarisi üç temel bileşenden oluşur:
-
Birincil veri merkezi (Primary Site): İş uygulamalarının ve üretim sistemlerinin normal koşullarda çalıştığı lokasyondur.
-
İkincil veri merkezi (Secondary Site): Verilerin ve gerekli altyapının replikasyon veya kurtarma amacıyla tutulduğu alternatif lokasyondur.
-
Lokasyonlar arası bağlantı: Veri replikasyonu, sistem yönetimi ve gerektiğinde hizmetlerin alternatif lokasyona aktarılması için kullanılan ağ altyapısıdır.
Birincil lokasyonda ciddi bir arıza meydana geldiğinde, kurtarma planına göre ikincil lokasyondaki sistemler devreye alınır. Bu işlem failover olarak adlandırılır. Ana lokasyon yeniden kullanılabilir hâle geldiğinde sistemler senkronize edilerek normal çalışma düzenine döndürülebilir (failback veya switchback).
Burada önemli olan, iki veri merkezinin yalnızca farklı adreslerde bulunması değildir. Elektrik beslemesi, soğutma, telekomünikasyon bağlantıları ve fiziksel afet riskleri açısından da bağımsız olmaları gerekir. Örneğin aynı elektrik altyapısına veya aynı fiber kablo güzergâhına bağımlı iki tesis, ortak bir arıza karşısında birlikte devre dışı kalabilir.
Eşzamanlı ve asenkron veri replikasyonu arasındaki fark
Coğrafi yedeklilikte verilerin ikincil lokasyona nasıl aktarıldığı, kurtarma sırasında oluşabilecek veri kaybını ve sistem performansını doğrudan etkiler.
Eşzamanlı replikasyon (Synchronous Replication): Veri yazma işlemi, her iki lokasyondaki ilgili depolama kopyalarına kalıcı olarak kaydedilmeden tamamlanmış sayılmaz. Uygun yapılandırmalarda bu yöntem, birincil lokasyon kaybedildiğinde son onaylanmış yazmaların diğer lokasyonda bulunmasını sağlayarak depolama katmanında sıfır RPO hedefini destekler.
Bunun karşılığında iki lokasyon arasındaki ağ gecikmesi ve bağlantı kalitesi kritik hâle gelir. Mesafe arttıkça gecikme de artabileceğinden, eşzamanlı replikasyon her coğrafi mesafede veya her iş yükünde uygun değildir.
Asenkron replikasyon (Asynchronous Replication): Veriler birincil lokasyonda kaydedildikten sonra ikincil lokasyona aktarılır. Replikasyon gecikmesi nedeniyle iki kopya arasında kısa süreli fark oluşabilir. Bu yöntem daha uzun mesafelerde kullanılabilir ve üretim sistemlerinin ağ gecikmesine duyarlılığını azaltabilir. Ancak birincil lokasyon aniden kaybedilirse son başarılı replikasyondan sonraki değişiklikler kaybolabilir.
| Özellik | Eşzamanlı replikasyon | Asenkron replikasyon |
|---|---|---|
| Veri aktarımı | Yazma işlemiyle eşzamanlı | Yazma işleminden sonra |
| Veri kaybı riski | Uygun yapılandırmada sıfır RPO hedeflenebilir | Son replikasyondan sonraki değişiklikler kaybolabilir |
| Ağ gecikmesi | Performansı doğrudan etkiler | Üretim işlemlerini daha az etkiler |
| Mesafe | Gecikme sınırları nedeniyle daha kısıtlı | Daha uzak lokasyonlara uygun olabilir |
| Kullanım amacı | Çok düşük veri kaybı toleransı | Daha geniş coğrafi mesafelerde felaket kurtarma |
MetroCluster nedir ve nasıl çalışır?
NetApp MetroCluster, iki ayrı lokasyondaki NetApp depolama sistemleri arasında eşzamanlı veri yansıtma sağlayan bir felaket kurtarma ve yüksek erişilebilirlik mimarisidir. ONTAP tabanlı bu çözüm, yerel depolama yedekliliğini lokasyonlar arası veri korumasıyla birleştirir.
MetroCluster'ın temelinde iki veri merkezindeki depolama sistemlerinin birbirini yedeklemesi bulunur. Cloud4U'nun MetroCluster çözümleri hakkında daha fazla bilgi edinebilir ve coğrafi yedeklilik yaklaşımını inceleyebilirsiniz.Veriler SyncMirror teknolojisi aracılığıyla eşzamanlı olarak yansıtılır. Böylece bir lokasyondaki depolama altyapısının kaybedilmesi durumunda diğer lokasyondaki yansıtılmış veriler kullanılabilir hâle getirilebilir.
Örneğin ana veri merkezinde meydana gelen bir yangın nedeniyle depolama sistemlerine erişilemediğini düşünelim. İkincil lokasyonun çalışır durumda olduğu ve gerekli bağlantı koşullarının sağlandığı bir MetroCluster yapılandırmasında, switchover işlemi gerçekleştirilerek diğer lokasyondaki depolama kaynakları hizmete alınabilir.
MetroCluster mimarisinin öne çıkan özellikleri şunlardır:
-
SyncMirror: Verilerin iki lokasyondaki depolama sistemlerine eşzamanlı olarak yansıtılmasını sağlar.
-
Yerel yüksek erişilebilirlik: Uygun yapılandırmalarda her lokasyondaki depolama düğümleri arasında yedeklilik sunar.
-
Site-level disaster recovery: Bir lokasyonun tamamının kaybedilmesi senaryosunda diğer lokasyondaki verilerin kullanılmasını destekler.
-
Switchover: Ana lokasyon kullanılamadığında ikincil lokasyondaki depolama hizmetlerinin devreye alınmasını sağlar.
-
Switchback: Ana lokasyon yeniden kullanılabilir olduğunda sistemlerin planlı biçimde normal çalışma düzenine dönmesini sağlar.
MetroCluster'ın iki temel dağıtım yaklaşımı bulunur:
MetroCluster FC: Lokasyonlar arasındaki bağlantıda Fibre Channel altyapısından yararlanır. Depolama ve küme trafiği, desteklenen mimariye göre ayrı bağlantılar üzerinden taşınır.
MetroCluster IP: Lokasyonlar arasındaki iletişim için IP tabanlı ağ altyapısını kullanır. Bu mimari, desteklenen yapılandırmalarda Ethernet bağlantıları üzerinden MetroCluster trafiğinin taşınmasını sağlar.
Hangi mimarinin uygun olduğu; ağ altyapısı, gecikme, bant genişliği, mesafe, donanım uyumluluğu ve iş yükü gereksinimlerine bağlıdır.
Önemli bir nokta: MetroCluster, depolama katmanındaki veri korumasını ve kullanılabilirliği ele alır. Uygulamaların otomatik olarak hiçbir kesinti olmadan çalışmaya devam edeceğini garanti etmez. Sunucuların, sanallaştırma platformlarının, veri tabanlarının, DNS'in ve ağ bağlantılarının da kurtarma mimarisine dahil edilmesi gerekir.
Teknik mimari ve desteklenen yapılandırmalar hakkında daha fazla bilgi için NetApp MetroCluster dokümantasyonu incelenebilir.
MetroCluster, yedekleme ve felaket kurtarma arasındaki fark nedir?
MetroCluster, klasik yedekleme sistemlerinin yerine geçen bir çözüm değildir. Bu teknolojiler farklı arıza ve veri kaybı senaryolarını karşılamak üzere tasarlanmıştır.
| Teknoloji | Koruma sağladığı senaryo | Temel sınırlama |
|---|---|---|
| RAID | Disk arızaları | Veri merkezi veya sistemin tamamının kaybına karşı koruma sağlamaz |
| Yerel yüksek erişilebilirlik (HA) | Sunucu veya depolama bileşeni arızaları | Aynı tesisin kaybına karşı tek başına yeterli değildir |
| Yedekleme (Backup) | Veri silinmesi, bozulması ve geçmiş bir sürüme dönme ihtiyacı | Verilerin geri yüklenmesi zaman alabilir |
| Asenkron replikasyon | Uzak lokasyonda veri kopyası bulundurma | Replikasyon gecikmesi nedeniyle veri kaybı yaşanabilir |
| MetroCluster | İki lokasyon arasında eşzamanlı depolama yedekliliği | Uygulama ve diğer altyapı bileşenleri ayrıca korunmalıdır |
Örneğin bir fidye yazılımı saldırısı sonucunda dosyalar şifrelenirse, replikasyon bu değişiklikleri diğer lokasyona da taşıyabilir. Bu nedenle coğrafi yedeklilik, bağımsız ve mümkünse değiştirilemez (immutable) yedeklerle desteklenmelidir.
Güvenilir bir mimaride yedekleme, yüksek erişilebilirlik ve felaket kurtarma birlikte çalışır. Her biri farklı bir riski yönetir.
RPO ve RTO nedir? Felaket kurtarma hedefleri nasıl belirlenir?
Bir felaket kurtarma mimarisinin başarısı, yalnızca kullanılan teknolojiyle değil, işletmenin belirlediği kurtarma hedefleriyle ölçülür. Bu noktada iki temel metrik kullanılır: RPO ve RTO.
RPO (Recovery Point Objective — Kurtarma Noktası Hedefi), bir kesinti durumunda işletmenin kabul edebileceği maksimum veri kaybını zaman cinsinden belirtir.
Örneğin RPO 15 dakika olarak belirlenmişse, işletme bir felaket sonrasında en fazla yaklaşık 15 dakikalık veriyi kaybetmeyi kabul eder. RPO sıfır olduğunda hedef, onaylanmış işlemler açısından veri kaybını önlemektir.
RTO (Recovery Time Objective — Kurtarma Süresi Hedefi), bir hizmetin kesinti başladıktan sonra ne kadar süre içinde yeniden kullanılabilir olması gerektiğini ifade eder.
Örneğin RTO iki saat olan bir uygulamanın, kesinti başlangıcından itibaren iki saat içinde tekrar çalışır hâle getirilmesi hedeflenir.
Bu değerler bütün sistemler için aynı olmak zorunda değildir:
| İş yükü | Örnek RPO hedefi | Örnek RTO hedefi |
|---|---|---|
| Ödeme ve sipariş sistemleri | 0–5 dakika | 15–30 dakika |
| ERP ve üretim uygulamaları | 5–15 dakika | 1–2 saat |
| İç raporlama sistemleri | 1–4 saat | 4–8 saat |
Tablodaki değerler yalnızca örnek planlama hedefleridir; sektör standardı veya belirli bir çözümün garanti ettiği değerler değildir.
RPO ve RTO belirlenirken iş etki analizi (Business Impact Analysis — BIA) yapılmalıdır. İşletme hangi uygulamaların kritik olduğunu, kesintinin finansal ve operasyonel sonuçlarını ve hangi sistemlerin önce kurtarılması gerektiğini belirlemelidir.
MetroCluster, desteklenen yapılandırmalarda depolama katmanı için sıfır RPO hedefini destekleyebilir. Ancak uçtan uca RPO ve RTO değerleri uygulama mimarisine, sunucu kapasitesine, ağ yapılandırmasına ve kurtarma süreçlerine bağlıdır.
Türkiye'de coğrafi yedeklilik mimarisi tasarlarken nelere dikkat edilmeli?
Türkiye'de veri merkezi yedekliliği planlayan işletmelerin bölgesel afet risklerini ve altyapı bağımlılıklarını birlikte değerlendirmesi gerekir. Deprem, sel, yangın ve uzun süreli elektrik veya iletişim kesintileri, tek bir lokasyona bağımlı sistemler için önemli riskler oluşturur.
AFAD'ın Türkiye Afet Risk Azaltma Planı (TARAP), Türkiye genelindeki afet risklerinin azaltılması ve hazırlık çalışmalarının koordinasyonu açısından önemli bir referanstır. İşletmeler de veri merkezi seçiminde ve felaket kurtarma planlarında bulundukları bölgenin risklerini dikkate almalıdır.
Coğrafi yedeklilik tasarımında özellikle şu beş konu önem taşır:
1. Veri merkezlerinin fiziksel ve operasyonel bağımsızlığı
İki tesisin farklı lokasyonlarda bulunması yeterli değildir. Aynı deprem risk bölgesinde, aynı enerji dağıtım altyapısına veya aynı telekomünikasyon güzergâhına bağımlı tesisler ortak arıza riski taşır. İkincil lokasyonun farklı risklere maruz kalacak şekilde seçilmesi gerekir.
2. Ağ gecikmesi ve bant genişliği
Eşzamanlı replikasyon için iki lokasyon arasında düşük gecikmeli, yeterli bant genişliğine sahip ve yedekli bağlantılar gerekir. Bağlantının performansı yalnızca ortalama kullanım üzerinden değil, yoğun yük ve arıza senaryolarında da değerlendirilmelidir.
3. İkincil lokasyonun kapasitesi
Felaket kurtarma merkezinin yalnızca verileri saklaması yeterli değildir. Kritik iş yüklerini çalıştıracak sunucu, depolama, ağ ve lisans kapasitesi de hazır olmalıdır. Aksi durumda veriler korunmuş olsa bile işletme uygulamalarını yeniden başlatamayabilir.
4. KVKK ve veri güvenliği
Kişisel veri içeren sistemlerin yedekleri ve replikaları da veri işleme süreçlerinin bir parçasıdır. Bu nedenle verilerin nerede saklandığı, erişim yetkileri, şifreleme, kayıt tutma ve veri aktarımı gibi konular KVKK kapsamında değerlendirilmelidir. Coğrafi yedeklilik tek başına mevzuata uygunluk sağlamaz.
5. Failover ve geri dönüş süreçleri
Birincil lokasyonun kaybedilmesi durumunda hangi sistemlerin, hangi sırayla ve kimin kararıyla devreye alınacağı önceden tanımlanmalıdır. Ayrıca ana lokasyon yeniden çalışır hâle geldiğinde veri senkronizasyonu ve geri dönüş işlemlerinin nasıl yapılacağı belirlenmelidir.
Felaket kurtarma planı nasıl test edilir?
Bir felaket kurtarma planı, yalnızca dokümante edildiğinde değil, gerçekçi senaryolar altında başarıyla uygulandığında güvenilir kabul edilebilir.
İşletmelerin düzenli olarak gerçekleştirmesi gereken temel testler şunlardır:
-
Replikasyon kontrolü: Birincil ve ikincil lokasyon arasındaki veri senkronizasyonunun sağlıklı çalıştığını doğrulayın.
-
Failover testi: Kontrollü koşullarda ikincil lokasyonun hizmetleri devralabildiğini test edin.
-
Uygulama doğrulaması: Sunucuların açılmasının ötesine geçerek veri tabanlarını, kimlik doğrulamayı, DNS'i ve uygulama işlemlerini kontrol edin.
-
Failback testi: Ana lokasyon yeniden kullanılabilir olduğunda verilerin senkronize edildiğini ve normal çalışma düzenine güvenli biçimde dönülebildiğini doğrulayın.
-
Kapasite testi: İkincil lokasyonun kritik sistemlerin üretim yükünü karşılayabildiğinden emin olun.
-
Operasyonel test: Teknik ekiplerin, yöneticilerin ve ilgili iş birimlerinin görevlerini ve iletişim süreçlerini doğrulayın.
Testlerin sonuçları belgelenmeli, başarısız adımlar için düzeltici faaliyetler tanımlanmalı ve kurtarma planı düzenli olarak güncellenmelidir. Özellikle uygulama, ağ ve veri tabanı mimarisinde yapılan değişikliklerden sonra eski test sonuçlarına güvenmek doğru değildir.
Sonuç
Coğrafi yedeklilik, veri merkezi düzeyindeki afetlerin işletme sistemleri üzerindeki etkisini azaltmak için kullanılan temel altyapı yaklaşımlarından biridir. Ancak iki lokasyonda veri bulundurmak tek başına iş sürekliliği sağlamaz. Replikasyon, bağımsız altyapı, yeterli kurtarma kapasitesi, uygulama bağımlılıkları ve test edilmiş operasyonel süreçler birlikte tasarlanmalıdır.
NetApp MetroCluster gibi teknolojiler, eşzamanlı veri yansıtma ve lokasyon düzeyinde depolama kurtarma ihtiyaçları için güçlü seçenekler sunar. İşletmelerin doğru mimariyi seçerken öncelikle kritik iş yüklerini, RPO ve RTO hedeflerini ve kabul edilebilir kesinti maliyetini belirlemesi gerekir.
Gerçek iş sürekliliği, ana veri merkezinin çalışmadığı durumda bile kritik iş süreçlerini sürdürebilecek bir altyapının önceden tasarlanması ve düzenli olarak test edilmesiyle sağlanır.
