Red Hat OpenShift üzerinde sanal makineler (VM’ler) için felaket kurtarma (DR) stratejileri, beklenmedik kesintilerde iş sürekliliğini sağlamak açısından çok önemlidir. Günümüzde şirketler, kritik uygulamalarını Kubernetes gibi platformlara taşımaktadır. Bu yüzden, bir kesinti olduğunda bu uygulamaların hızlı ve güvenilir şekilde geri yüklenmesi artık temel bir ihtiyaç haline gelmiştir.Bulut tabanlı ortamlarda geçici (ephemeral) ve durum bilgisi tutmayan (stateless) sanal makineler sıkça kullanılsa da, kurumsal dünyada kullanılan sanal makinelerin çoğu hâlâ durum bilgisi tutar (stateful). Durum bilgisi tutan makineler, çalışırken veri kaydederler ve bu veriler kalıcı disklerde (persistent block storage) tutulur. Bu nedenle bu disklerin, makineler yeniden başlatıldığında veya taşındığında tekrar bağlanabilmesi gerekir. Bu yazıda, durum bilgisi tutan (stateful) sanal makinelerin (VM’lerin) özel ihtiyaçlarına odaklanacağız. İlk olarak, küme (cluster) ve depolama mimarisi tercihlerinin; felaket anında devreye alma (failover) süreci, veri çoğaltma (replication) davranışı ve RPO/RTO hedefleri üzerindeki etkilerini inceleyeceğiz. Ardından, Kubernetes tabanlı araçlar, örneğin Red Hat Advanced Cluster Management, Helm, Kustomize ve GitOps pipelines kullanılarak iş yüklerinin nasıl dağıtıldığını ve nasıl geri dönüş işlemlerinin (recovery) yapıldığını ele alacağız. Son olarak, hem blok depolamayı hem de Kubernetes manifest dosyalarını çoğaltabilen gelişmiş depolama platformlarının, kurtarma süreçlerini nasıl sadeleştirdiği ve altyapı ile uygulama seviyesindeki otomasyon arasında nasıl köprü kurduğunu anlatacağız.
Bu detaylara girmeden önce terminolojiyi tekrar gözden geçirmek istiyorum. Bu sayede anlam karmaşasının önüne geçebiliriz diye düşünüyorum.
“felaket (disaster)” bir “lokasyon kaybı (site loss)” durumunu ifade etmektedir. Felaket kurtarma (DR: Disaster Recovery) denildiğinde temel amaç, bir iş hizmetindeki kesintiyi en aza indirmektir. Yani bir lokasyon kullanılamaz hale geldiğinde, hizmeti mümkün olan en hızlı ve verimli şekilde yedek lokasyonda yeniden devreye almak için DR planlarının uygulanması gerekir. Felaket kurtarma planları yalnızca veri merkezi düzeyindeki büyük kayıplar için değil, aynı zamanda uygulama katmanı veya altyapıdaki (örneğin veri tabanı, ağ anahtarı, depolama ünitesi) tekil kritik bileşen hataları için de kullanılabilir. Modern DR çözümleri, yüksek erişilebilirlik (HA), otomatik failover, sürekli veri replikasyonu ve orkestrasyon desteğiyle hizmet sürekliliğini sağlamayı amaçlar. Bu nedenle DR planlarının hem lokasyon bazlı hem de servis bazlı senaryoları kapsayacak şekilde esnek ve önceden test edilmiş olması büyük önem taşır.
“Bileşen (component) hataları”, genellikle tüm sistemi değil, bir uygulama grubunu etkiler. Örneğin; bir veri tabanı sunucusunun, bir yük dengeleyicinin ya da dosya sisteminin çökmesi gibi durumlar sadece belirli servisleri aksatır. Bu durumda, tüm siteyi taşımak yerine yerel yedeklilik (local redundancy) veya uygulamaya özel DR planları devreye alınarak hizmetin sürekliliği sağlanır. Modern sistem mimarilerinde, bu tür durumlara hazırlıklı olmak adına: Uygulama bağımlılıklarının net olarak tanımlanması, Bileşen bazlı felaket senaryolarının test edilmesi, ve hem lokasyonlar arası hem de lokasyon içi “failover” mekanizmalarının önceden yapılandırılması gerekir.
Bu yaklaşım, hem kesintileri minimize eder hem de tüm siteyi devre dışı bırakmadan esnek ve hızlı müdahale olanağı sağlar.
Recovery Point Objective (RPO): Kurtarma Noktası Hedefi, bir felaket ya da sistem arızasından sonra hizmet yeniden devreye alındığında maksimum ne kadar verinin kaybının kabul edilebilir olduğunu (zaman cinsinden) tanımlar. Başka bir ifadeyle, organizasyonun veri kaybına ne kadar tolerans gösterebileceğini belirten eşiği ifade eder. Yani, ne kadar eski veriyle sistemi açabilme iznim olduğunu belirtir. Özetle, RPO, “En son ne zaman yedek aldıysak, o andan itibaren geriye dönük ne kadarlık veri kaybını tolere edebiliriz?” sorusunun yanıtıdır.
RPO, genellikle veri yedekleme ve replikasyon stratejilerinin merkezinde yer alır. Örneğin:
Eğer bir sistemin RPO değeri 4 saat olarak tanımlanmışsa, sistem kurtarıldığında son 4 saate kadar olan veri kaybı kabul edilebilir demektir. Daha kritik sistemlerde bu süre birkaç saniyeye kadar indirilebilir (örneğin finansal işlemler). RPO değeri, iş sürekliliği planlamasında şu açılardan kritiktir: Veri koruma politikalarının oluşturulması (ör. yedekleme sıklığı), replikasyon çözümlerinin (eşzamanlı/asenkron) yapılandırılması, ve risk analizleri sırasında iş birimleriyle kabul edilebilir kayıp seviyelerinin belirlenmesi.
Recovery Time Objective (RTO): Kurtarma Süresi Hedefi, bir hizmetin devre dışı kaldıktan sonra maksimum ne kadar süreyle erişilemez olabileceğini, yani organizasyonun hizmet kesintisine ne kadar süreyle tolerans gösterebileceğini tanımlar. Başka bir ifadeyle, hizmetin kabul edilebilir süre içinde yeniden çalışır duruma getirilmesi gereken zamanı gösterir.
RTO, iş sürekliliği ve felaket kurtarma planlarının performans hedeflerinden biridir. Örneğin:
Eğer bir uygulamanın RTO’su 2 saat olarak belirlenmişse, hizmet kesintisinden sonra en geç 2 saat içinde uygulamanın yeniden erişilebilir olması gerekir. Daha kritik sistemlerde bu süre dakikalar ya da saniyeler düzeyinde olabilir (örneğin hastane bilgi sistemleri, bankacılık altyapısı). RTO değeri, altyapı tasarımı, yedeklilik yapısı, otomasyon seviyesi ve operasyonel hazırlıkla doğrudan ilişkilidir. Yüksek RTO değerleri daha uzun kesintilere tolerans sağlar ancak daha az maliyetli sistemler yeterlidir. Düşük RTO değerleri için ise yüksek yatırım ve güçlü teknik altyapı gerekebilir. Özetle RTO, “Bir hizmet çöktüğünde, onu ne kadar sürede tekrar ayağa kaldırmalıyız?” sorusunun yanıtıdır.
Metro-DR ve Bölgesel DR (Regional-DR) Arasındaki Fark:
Felaket kurtarma (Disaster Recovery: DR) mimarileri genel olarak iki ana kategoriye ayrılır: Metro-DR ve Bölgesel DR (Regional-DR).
Metro-DR: Bu yapı, veri merkezlerinin birbirine coğrafi olarak yakın olduğu ve ağ performansının senkron (eşzamanlı) veri çoğaltmasına izin verdiği durumlar için uygundur.
Senkron çoğaltma sayesinde, birincil ve yedek sistemler aynı anda veri yazar. Bu sayede veri kaybı yaşanmaz ve RPO değeri sıfır olarak hedeflenebilir.
Bölgesel DR (Regional-DR): Veri merkezlerinin birbirinden uzakta olduğu ve senkron çoğaltmanın mümkün olmadığı durumlarda tercih edilir. Bu senaryoda asenkron veri çoğaltması kullanılır. Asenkron replikasyon, doğal olarak bir miktar veri kaybı riskini beraberinde getirir.
Eğer kullandığınız depolama altyapısı senkron veri çoğaltmayı desteklemiyorsa, fiziksel yakınlığa rağmen Metro-DR planınız teknik olarak Bölgesel DR mimarisi gibi değerlendirilmek zorundadır.
Metro-DR, genellikle aynı şehirde ya da kampüs içinde bulunan veri merkezleri arasında uygulanır. Düşük gecikmeli ağ bağlantısı sayesinde veriler aynı anda iki merkeze de yazılır. Bu sayede hem RPO = 0 (veri kaybı yok) hem de çok düşük RTO (hızlı kurtarma) mümkündür.
Regional-DR ise daha çok farklı şehirlerde ya da ülkelerdeki veri merkezlerini kapsar. Fiziksel mesafe arttıkça, ağ gecikmeleri nedeniyle senkron çoğaltma mümkün olmaz ve veri önce birincil merkeze yazılır, sonra yedeğe aktarılır. Bu da veri kaybı riskini beraberinde getirir.
Özetle:
Metro-DR: Yüksek senkronizasyon, sıfır veri kaybı, düşük gecikme.
Regional-DR: Daha esnek coğrafya, bazı veri kayıpları kabul edilir.
Seçim, hem teknik altyapıya hem de işin veri kaybı ve kurtarma süresine olan toleransına bağlıdır.
Restart Storm (Yeniden Başlatma Fırtınası):
“Restart storm”, çok sayıda sanal makinenin (VM) eşzamanlı olarak yeniden başlatılmaya çalışıldığı bir durumdur. Bu işlem öyle büyük bir yük oluşturur ki, altyapıyı yöneten hipervizör ve destekleyici sistemler bu taleple başa çıkamaz hale gelir. Sonuç olarak, ya hiçbir VM yeniden başlatılamaz, ya da yeniden başlatmalar kabul edilemeyecek kadar uzun sürer.
Bu durum, kötü niyetli olmasa da, hizmetin geçici olarak kullanılamaz hale gelmesi anlamına geldiği için, zaman zaman “zararsız bir hizmet engelleme (DoS) saldırısı” gibi de tanımlanabilir.
“Restart storm”, genellikle felaket kurtarma senaryolarında, bakım süreçlerinde veya beklenmedik altyapı kesintilerinden sonra, çok sayıda VM’nin aynı anda ayağa kaldırılmaya çalışılmasıyla oluşur. Ancak altyapı (özellikle hipervizör, ağ ve depolama sistemleri) bu kadar büyük yükü aynı anda taşıyabilecek kapasitede değilse, bu süreç sistem üzerinde baskı yaratır ve performans düşer ya da tamamen kilitlenir. Bu tür durumlar, otomasyon sistemleri yanlış yapılandırıldığında ya da DR senaryoları test edilmeden uygulamaya konduğunda ortaya çıkabilir.
Önlem olarak:
VM’leri kademeli (batch-based) yeniden başlatmak,
Başlatma öncelikleri tanımlamak (start order / dependency mapping),
Ve altyapının bu yükü kaldıracak şekilde ölçeklendirilmiş olması gerekir.
Özetle, “restart storm”, sistemin aynı anda aşırı yüklenmesi nedeniyle felaket kurtarma planlarının etkisiz hale gelmesine yol açabilecek kritik bir risk senaryosudur.
Durum Bilgisi Tutan Yükler (Stateful Workloads) için Felaket Kurtarma (Disaster Recovery) Yaklaşımları
İş sürekliliği ve felaket kurtarma (DR) senaryolarında, sistemin nasıl davranacağı kritik önemdedir. Cloud Native Computing Foundation (CNCF), bu konuyu ele alan bir teknik doküman (Spazzoli, 2024) yayınlamıştır. Bu belgede dört temel DR yaklaşımı açıklanmakta. Aşağıdaki diyagram, bu dört farklı yaklaşımı karşılaştırmalı olarak göstermektedir.
Back up and restore (Yedekleme ve Geri Yükleme)
Senaryo: Sistemin sadece bir yerde (Failure Domain 1) çalıştığı durumda, veri yedeklemeleri güvenli bir uzak lokasyona (Safe Backup Location) gönderilir. Eğer sistem çökerse, yedeklerden manuel olarak geri yükleme yapılır.
Avantajı: Uygulaması en kolay, en düşük maliyetli yöntemdir.
Dezavantajı: Kurtarma süresi çok uzundur (RTO yüksek).Sürekli erişim isteyen kritik sistemler için uygun değildir.
Volume Replication (Disk Bazlı Replikasyon)
Senaryo: Veriler, canlı çalışan bir domain’den (active) pasif olan başka bir domain’e (passive) sürekli olarak volume düzeyinde (yani blok bazlı disk kopyalama) yedeklenir.
Teknik: Persistent Volume (kalıcı disk) seviyesinde yansıtma yapılır. Uygulama yeniden başlatılabilir.
Avantajı: Daha hızlı kurtarma süresi. Otomatik failover senaryolarına uygun.
Dezavantajı: Uygulama mantığında replikasyona özel ek bir yapılandırma gerekebilir.
Transaction Replication (Veri Tabanı Replikasyonu)
Senaryo: Ana (master) veri tabanı canlı çalışırken, veriler transaction (işlem) bazında anlık olarak pasif sunucuya replikedir. Uygulamanın front-end katmanı her iki tarafa da yönlenebilir, ancak veri yalnızca master üzerinde yazılır.
Teknik: Uygulama ve veri tabanı, aktif/pasif olacak şekilde yapılandırılmıştır. Replikasyon uygulamaya özgüdür.
Avantajı: Transaction bazlı kurtarma yapılabilir. Tutarlılık daha yüksektir.
Dezavantajı: Karmaşıklık artar. Uygulama mimarisinde bu yapıyı desteklemek gerekir.
Distributed Stateful Workload / CRDB (Dağıtık Durumsal Yük / Dağıtık Veri Tabanı)
Senaryo: Sistemin birden fazla domain’de aynı anda (Active/Active) çalıştığı, dağıtık veri tabanı mimarisi.
Veri Senkronizasyonu: Veri tabanları kendi arasında aktif olarak “state sync” (durum senkronizasyonu) yapar.
Avantajı: En yüksek süreklilik (high availability). Gerçek zamanlı failover. Gelişmiş esneklik ve yük dengeleme.
Dezavantajı: Mimarisi çok karmaşıktır. Tutarlılık (consistency) problemleri yaşanabilir. Dağıtık veri tabanı yönetimi uzmanlık ister.
Sanal makinelerle çalışan sistemlerde felaket kurtarma stratejisi planlanırken, iki ana yöntem öne çıkar:
Backup & Restore (Yedekleme ve Geri Yükleme):
Bu yöntem, sanal makine disklerinin (VMDK, QCOW2 vb.) düzenli aralıklarla yedeklenmesini ve bir felaket durumunda bu yedeğin geri yüklenerek sistemin tekrar ayağa kaldırılmasını esas alır.
Avantaj: Uygulaması kolay ve maliyeti düşüktür.
Dezavantaj: Kurtarma süresi uzundur, verinin bir kısmı kaybolabilir (RTO ve RPO yüksektir).
Volume Replication (Hacim Bazlı Replikasyon):
Bu yaklaşımda, sanal makinelerin bağlı olduğu diskler (volume’ler) gerçek zamanlı ya da neredeyse gerçek zamanlı olarak başka bir lokasyona replik edilir.
Avantaj: Hem veri kaybı (RPO) hem de kurtarma süresi (RTO) minimuma iner.
Dezavantaj: Teknik karmaşıklık ve altyapı maliyeti daha yüksektir.
Bu bağlamda, volume replication temelli yöntemler daha verimli olduğu için modern altyapılarda tercih sebebidir. Ancak bu yaklaşımın da kendi içinde iki farklı mimari biçimi bulunur.
Tek Yönlü Replikasyon (Unidirectional Replication):
Ana sistemin bulunduğu lokasyondaki veriler, pasif durumdaki uzak bir veri merkezine kopyalanır.
Bu ikinci lokasyon normal şartlarda devre dışıdır, sadece bir felaket durumunda devreye alınır.
Replikasyon bir yönlüdür: aktif → pasif.
Avantajları: Mimari sadedir. Felaket durumunda hızlıca ayağa kalkılabilir.
Dikkat Edilmesi Gerekenler: Pasif sistemde yazılabilirlik ve senkronizasyon yoktur. Veri geri dönüşü (failback) karmaşık olabilir.
Bu diyagram, sanal makinelerin (VM) tek yönlü veri replikasyonu (unidirectional replication) ile felaket kurtarma (Disaster Recovery – DR) kapsamında iki farklı veri merkezine kurulmuş bağımsız OpenShift (OCP) kümeleri üzerinde nasıl taşınabileceğini göstermektedir.
Mimari Bileşenlerin Tanımı:
VM (Sanal Makine): OpenShift üzerinde çalışan sanal makineleri temsil eder.
OCP Cluster (OpenShift Cluster): Her veri merkezinde bağımsız çalışan, 3 master node ve n tane worker node içeren bir OpenShift (OCP) kümesidir. Bu iki OCP cluster birbiriyle bağlantısızdır (cluster-level replikasyon yoktur).
Storage (Depolama): Her OCP cluster, kendi veri merkezindeki lokal depolama sistemiyle bağlıdır.
Depolama sistemleri arasında tek yönlü replikasyon vardır. Yani sadece bir taraftan diğerine veri akışı olur.
Unidirectional Replication: Kaynak veri merkezindeki disk (storage array), hedef veri merkezine tek yönlü (unidirectional) olarak veri replikasyonu yapar. Bu replikasyon genellikle storage vendor’ının (örneğin NetApp, Dell PowerStore, IBM, vs.) sunduğu yeteneklere dayanır.
Human (İnsan Müdahalesi): Bu yapı aktif/pasif olduğu için failover otomatik değildir. Bir kesinti durumunda, insan müdahalesiyle VM migration orkestrasyonu tetiklenir.
Bu mimari, sanal makinelerin (VM) çalıştığı birincil (aktif) veri merkezinden, ikincil (pasif) bir veri merkezine tek yönlü veri replikasyonu (unidirectional replication) kullanılarak felaket kurtarma (DR) sağlanmasını amaçlar. Normal operasyon sırasında, VM’ler birinci veri merkezindeki OpenShift (OCP) kümesi üzerinde çalışır ve kendi kalıcı disklerine (persistent volume) yazma işlemi gerçekleştirir. Bu diskler, storage sisteminin desteklediği tek yönlü replikasyon kabiliyeti sayesinde, ikinci veri merkezindeki storage alanına otomatik olarak kopyalanır. Her iki veri merkezinde de bağımsız OCP kümeleri yer alır; bu kümeler birbirinden tamamen izole olduğu için birbirlerinin durumundan habersizdir. Bu yapı, aktif/pasif bir mimariyi temsil eder.
Bir kesinti yaşandığında (örneğin elektrik arızası, ağ problemi, donanım hatası), insan müdahalesiyle devreye alınan bir orkestrasyon mekanizması yardımıyla, ikinci veri merkezindeki OCP kümesine VM’lerin taşınması sağlanır. Buradaki VM’ler, replike edilmiş volume’ları kullanarak çalışmaya devam eder. Böylece uygulama, minimum kesintiyle operasyonlarını sürdürebilir.
Bu senaryonun sağlıklı çalışabilmesi için bazı teknik ön koşullar mevcuttur. Öncelikle, kullanılan storage altyapısının tek yönlü replikasyonu desteklemesi gerekir. Replikasyon işlemi senkron ya da asenkron şekilde olabilir; genellikle veri merkezleri arasındaki mesafe yüksek olduğunda asenkron tercih edilir. Ayrıca, felaket anında replike edilmiş volume’ların salt-okunur (read-only) değil, yazılabilir (read-write) hâle getirilebilmesi gerekir. DNS, load balancer ve benzeri dış bileşenlerin bu geçişi destekleyecek şekilde yapılandırılmış olması da oldukça önemlidir.
Ancak bu mimaride bazı kısıtlar da bulunmaktadır. Otomasyon eksikliği önemli bir dezavantajdır; failover, DNS güncellemesi, volume mount işlemleri gibi pek çok adım manuel olarak gerçekleştirilmelidir. Ayrıca, veri kaybı riski göz ardı edilmemelidir. Özellikle stateful uygulamalar (örneğin veritabanları, önbellek sistemleri vb.) çalışıyorsa ve replikasyon henüz tamamlanmadan yük devri yapılırsa, RPO (veri kaybı toleransı) açısından sıkıntılar doğabilir. Aynı şekilde RTO (kurtarma süresi) da aktif/aktif ya da çift yönlü replikasyon mimarilerine kıyasla daha yüksektir.
Tüm bunlara rağmen bu yapı, mimari sadeliği, birçok kurumsal storage çözümüyle uyumluluğu ve operasyonel bağımsızlığıyla öne çıkar. Verinin tam zamanlı senkron olması gerekmiyorsa, uygulama tarafında kısa süreli kesintiler kabul edilebiliyorsa ve insan müdahalesiyle yük devri yapılması sorun teşkil etmiyorsa, bu model birçok kurum için yeterli bir felaket kurtarma çözümü sunar. Ancak daha yüksek erişilebilirlik ve otomasyon seviyeleri isteniyorsa, bu yapının bir üst adımı olan çift yönlü replikasyon (bidirectional replication) ya da coğrafi olarak dağıtılmış aktif/aktif OCP kümeleri (geo-distributed active/active clusters) düşünülmelidir.
OpenShift ortamlarında kullanılan hacim (volume) replikasyonu, Kubernetes’in standart CSI (Container Storage Interface) spesifikasyonunda tanımlanmadığı için, bu özellik tamamen depolama üreticilerinin sunduğu özel çözümlere (CRD’lere) bağlıdır. Bu da mimarinin taşınabilirliğini ve vendor bağımsızlığı (vendor-agnostic yapı) sağlamayı zorlaştırır. Bugün piyasada üç farklı olgunluk düzeyinde yaklaşım bulunmaktadır: Bazı üreticiler henüz CSI seviyesinde volume replication desteği sunmazken, bazıları bu özelliği sınırlı şekilde entegre eder; ileri seviye üreticiler ise yalnızca volume’ları değil, ilgili namespace metadata’sını (VM tanımları ve manifestler dahil) da geri yükleyebilecek mekanizmalar sağlar. Bu farklılık nedeniyle, bölgesel bir DR (Disaster Recovery) senaryosu için tek bir standartlaştırılmış kurtarma süreci oluşturmak oldukça karmaşıktır ve gerekli otomasyonun kapsamı doğrudan kullanılan storage üreticisine bağlıdır.
Bu mimarinin farklı arıza senaryoları altında nasıl davrandığını değerlendirmek faydalı olur. Öncelikle, bir OpenShift düğümünde (node) yaşanan bir arıza durumunda, OpenShift Virtualization scheduler devreye girer ve ilgili VM’i aynı cluster’daki uygun başka bir node üzerinde otomatik olarak yeniden başlatır. Bu senaryoda herhangi bir manuel müdahale gerekmemektedir. Ancak, bir storage array’in tamamının arızalanması halinde, o depolamaya bağlı tüm VM’ler çalışamaz hale gelir ve felaket kurtarma süreci başlatılmalıdır. Gerçek bir veri merkezi arızası durumunda (datacenter failure), tüm VM’lerin başka bir bölgede yeniden başlatılması gerekir. Bu senaryo genellikle bir insanın olay yönetim çerçevesi içinde süreci başlatmasıyla ilerler, ancak otomasyon burada önemli bir rol oynar.
Bir felaket kurtarma süreci planlanırken şu kritik noktalar göz önünde bulundurulmalıdır: Aynı uygulamaya ait VM’lerin diskleri tutarlı bir şekilde replikasyona tabi tutulmalı, yani bu volume’lar bir consistency group (tutarlılık grubu) içinde yer almalıdır. Normal çalışma sırasında volume’lar aktif bölgeden pasif bölgeye replikedir. Failover esnasında replikasyon durdurulur, çünkü artık veriler pasif bölgeden çalıştırılacaktır. Failback hazırlığında, bu kez pasif bölgeden aktif bölgeye replikasyon yapılır; ardından yeniden aktif bölgeye geçilirken replikasyon yine durdurulur. Bu geçişlerin başarılı olabilmesi için, VM’lerin hedef veri merkezinde replike edilmiş disklerle yeniden başlatılabilir olması gerekir. Ayrıca, yeniden başlatma işlemlerinin kontrolsüz bir şekilde aynı anda tetiklenmesi (“restart storm”) gibi durumları önlemek adına, VM başlatma işlemlerinin sıralanması ve önceliklendirilmesi gerekir. Örneğin, önce veritabanları, ardından bu veriye bağımlı servislerin başlatılması önerilir.
Maliyet açısından değerlendirildiğinde, OpenShift kümelerinin yapılandırılma biçimi, ortamın “hot site” mi yoksa “warm site” mi olduğunu belirler. Eğer DR sitesinde aktif workload yoksa — yani sadece persistent volume’lar (PV), persistent volume claim’ler (PVC) ve çalışmaya hazır ancak durmuş (powered off) VM’ler bulunuyorsa — bu yapı warm site olarak kabul edilir ve bazı lisans/maliyet avantajları sağlar. Öte yandan, aktif yüklerin de bulunduğu bir senaryoda tüm OpenShift düğümleri lisanslı olmalıdır ve bu durumda yapı hot site olur.
Son olarak, her iki veri merkezinin de kısmen aktif olarak çalıştığı, yüklerin yaklaşık %50 oranında bölündüğü yapılar symmetric active/passive olarak tanımlanır. Bu mimari, sistemin tamamının tek bir noktada çökmesini engellemek açısından pratik ve yüksek erişilebilirlik sağlayan bir yaklaşımdır. Ayrıca, felaket durumunda yeniden toparlanma süresini de azaltır. Bu yapıda, her iki veri merkezi karşılıklı olarak birbirinin yükünü devralabilecek şekilde yapılandırılır. Yukarıda açıklanan mimari, symmetric active/passive modeliyle de uyumludur. Ancak bu durumda, her iki lokasyondaki tüm OpenShift düğümlerinin aktif olarak lisanslı ve kullanılabilir olması gerektiği unutulmamalıdır.
Çift Yönlü (Simetrik) Replikasyon (Bidirectional / Symmetric Replication):
Her iki lokasyon da aktif olabilir (active/active ya da active/standby senaryosu). Veriler karşılıklı olarak replik edilir. Failover ve failback işlemleri otomatiktir ve veri kaybı minimumdur.
Avantajları: Hem RPO hem de RTO en düşük seviyededir. Her iki sistem de yedek görevi gördüğünden, iş sürekliliği yüksek olur.
Zorluklar: Çakışma çözümü (conflict resolution) gerekebilir. Dağıtık kilit yönetimi, tutarlılık politikaları (eventual vs strong consistency) düşünülmelidir. Altyapı ve lisans maliyetleri daha yüksektir.
Symmetric active/passive mimarisi, modern felaket kurtarma (Disaster Recovery – DR) stratejilerinde yüksek erişilebilirlik (High Availability – HA) hedefleyen kurumlar için son derece güçlü bir yaklaşımdır. Bu yapı, yüklerin yalnızca birincil (aktif) veri merkezinde toplanması yerine, iş yüklerinin her iki veri merkezine yaklaşık %50 oranında dağıtılmasını esas alır. Böylece herhangi bir veri merkezi arızasında tüm servislerin aynı anda çökmesi engellenir, kurtarma süresi (RTO) kısalır ve sistem esnekliği artar. Her iki veri merkezi de hem kendi üzerindeki yükleri çalıştırabilecek, hem de diğer merkezin yüklerini devralabilecek kapasitede yapılandırılır. OpenShift Virtualization ortamlarında da başarıyla uygulanabilen bu mimari, iki yönlü ve senkron veri replikasyonu sayesinde iki veri merkezi arasında sürekli veri bütünlüğü sağlar.
Bu yapının temelinde yer alan symmetric replication, verilerin hem DC1 hem de DC2 arasında senkron olarak, çift yönlü biçimde replikasyonunu ifade eder. Böylece her iki merkezdeki volume’lar hem yazılabilir durumdadır hem de anlık olarak birbirine yansıtılır. Ancak bu replikasyon modelinin çalışabilmesi için iki veri merkezi arasında çok düşük gecikmeli (latency < 5ms) bir bağlantı olması gerekir. Bu nedenle bu mimari genellikle aynı şehirdeki veri merkezlerinde uygulanır ve bu yapı “Metro-DR” olarak adlandırılır. Bu tür yapılandırmalarda kullanılan depolama sistemleri genellikle SAN (Storage Area Network) bazlıdır ve her iki merkezdeki storage array’ler arasında senkronizasyon gerçekleştirilir. OpenShift tarafında, bir persistent volume claim (PVC) oluşturulduğunda, bu volume’a çift yönlü bağlantı sağlayan bir multipath LUN atanır. Bu LUN hem DC1 hem DC2 üzerindeki storage sistemlerine erişebilir. Bu erişim yapılandırması, çoğu zaman ALUA (Asymmetric Logical Unit Access) modunda çalışır; bu durumda en yakın storage aktif yol olarak kabul edilir ve I/O trafiği buradan akar. Bazı vendor’lar ise Active/Active erişim sunar ve erişim ağırlıkları (weights) ile kontrol edilir. Fiber Channel bağlantıları simetrik değilse ve her node yalnızca kendi lokal storage’ına erişebiliyorsa, ALUA yapılandırması uygulanamaz.
Bu yapının sağlıklı ve tutarlı çalışabilmesi için, split-brain senaryolarına karşı önlem olarak bağımsız bir witness site kullanılır. Witness site, herhangi bir ağ bölünmesi (network partitioning) veya site kaybı durumunda hangi tarafın aktif kalacağına karar vermek için bir hakem (quorum member) olarak görev yapar. Bu site, yük taşımaz ve büyük kaynaklara ihtiyaç duymaz; ancak fiziksel güvenlik, enerji, soğutma gibi veri merkezi operasyonları açısından diğer veri merkezleriyle benzer kalitede olmalıdır. Ayrıca, OpenShift gibi Kubernetes temelli sistemlerde, etcd veritabanı en az üç adet failure domain gerektirdiği için, bu witness site genellikle OpenShift control plane’in üçüncü node’unu barındıracak şekilde de kullanılır. Bu sayede OpenShift kümeleri, üç farklı zone’a yayılmış tam dayanıklı bir mimariye kavuşur.
Farklı arıza senaryolarında bu yapı çeşitli avantajlar sağlar. Bir node arızasında, OpenShift scheduler devreye girerek ilgili VM’i aynı veri merkezindeki uygun başka bir node’a otomatik olarak yeniden yerleştirir. Storage tarafındaki multipath yapı sayesinde, bir storage array arızalandığında veya bakıma alındığında, VM’ler diğer array üzerinden çalışmaya devam eder. Bu geçiş, kullanıcı tarafında genellikle fark edilmez ve sadece küçük bir I/O gecikmesi yaşanabilir. Ancak bağlantı yapısı simetrik değilse (non-uniform), VM’in, erişim sağlayabilen başka bir node’a migrate edilmesi gerekebilir.
Tüm veri merkezinin kullanılamaz hale gelmesi durumunda ise, bu olay OpenShift tarafından birden fazla node’un aynı anda erişilemez hale gelmesi olarak algılanır. OpenShift scheduler, yeterli kaynak varsa tüm workload’ları sağlıklı veri merkezine yeniden planlar. Replike edilmiş volume’lar zaten mevcut olduğundan, veri kaybı sıfırdır (RPO = 0) ve sistem, node’un offline olduğunun anlaşılması, fencing işlemleri, VM’lerin yeniden başlatılması ve boot sürecinin tamamlanması toplam süresince kurtarılır (RTO). Bu süreç tamamen otomatik çalışabilir; ancak bu her zaman tercih edilmeyebilir. Özellikle büyük yapılarda “restart storm” adı verilen, aynı anda çok sayıda VM’in yeniden başlatılması gibi kontrolsüz durumlar yaşanabileceğinden, VM’lerin hangi sırayla ve ne zaman başlatılacağının kontrol altına alınması önerilir.
Sonuç olarak, symmetric active/passive mimarisi, yüksek erişilebilirlik ve veri bütünlüğünü garanti altına almak isteyen kurumlar için son derece güçlü bir çözümdür. Ancak bu çözümün uygulanabilmesi için altyapının bu karmaşıklığı kaldırabilecek seviyede olması, düşük gecikmeli ağ bağlantılarının kurulması ve kurumsal storage sistemlerinin bu replikasyon biçimini desteklemesi gerekir. Doğru yapılandırıldığında, bu mimari felaket senaryolarında kesintisiz iş sürekliliği sağlar ve manuel müdahaleye gerek kalmadan sistemin kendi kendine toparlanmasına olanak tanır.
Bu güçlü Metro-DR mimarisinin uygulanmasında bazı kritik hususların göz önünde bulundurulması gerekir. Öncelikle, sanal makinelerin (VM) veri merkezleri arasında serbestçe hareket edebilmesi için, bu VM’lerin bağlı olduğu VLAN’ların da metro veri merkezleri arasında “stretched” (genişletilmiş) olması gerekir. Ancak bu durum bazı ortamlarda ağ yönetimi açısından istenmeyebilir veya karmaşıklık yaratabilir. Ayrıca, üçüncü bölge olarak konumlanan witness site’ın yönetim ağı (OpenShift node management network), metro veri merkezlerindeki ağlarla aynı Layer 2 (L2) subnet’te olmayabilir. Bu da bazı senaryolarda erişim planlamasının daha dikkatli yapılmasını gerektirir.
Buna ek olarak, bazı uzman görüşleri bu mimariyi tam anlamıyla bir felaket kurtarma (DR) çözümü olarak görmeyebilir. Bunun nedeni, hem OpenShift kontrol düzleminin (control plane) hem de depolama altyapısının kontrol düzleminin (storage controller plane) mantıksal olarak tekil hata noktaları (Single Point of Failure – SPOF) oluşturmasıdır. Fiziksel seviyede elbette yedeklilik sağlansa da, teoride yapılabilecek tek bir hatalı komut, tüm ortamın silinmesine yol açabilir. Bu nedenle, en kritik iş yükleri için Metro-DR yapıları genellikle daha geleneksel bir bölgesel DR mimarisiyle birlikte zincirleme (daisy-chained) olarak kullanılır.
Bir başka dikkat edilmesi gereken konu, felaket anında OpenShift’in varsayılan davranışıdır. DR senaryosunda OpenShift scheduler, etkilenen veri merkezindeki tüm VM’leri aynı anda sağlıklı veri merkezine yeniden planlayabilir. Bu durum, “restart storm” olarak bilinen ve altyapıyı anlık olarak aşırı yükleyebilecek bir duruma neden olabilir. Kubernetes içinde bu riski azaltmaya yönelik çeşitli mekanizmalar mevcuttur; uygulamaların sırayla ve önceliklendirilerek yeniden başlatılması gibi özellikler bu sorunu hafifletir. Bu tür kontrollerin aktif kullanılması, Metro-DR senaryolarında sürdürülebilirlik açısından kritik önemdedir.
Maliyet açısından bakıldığında, symmetric replication yaklaşımında her iki veri merkezi de tam kapasiteyle yapılandırılmış (fully subscribed) olmalıdır. Çünkü bu yapı, tek bir aktif OpenShift kümesini iki bölgeye yayılmış şekilde çalıştırır. Ayrıca, her iki site de diğerinin %100 yükünü alabilecek kapasitede olmalıdır. Bu, sistemin yüksek erişilebilirliğini garanti altına alırken, kaynak kullanımını da doğal olarak iki katına çıkarır. Bu durum, altyapı maliyetlerini unidirectional replikasyon senaryolarına kıyasla daha yukarı çeker.
Sonuç olarak, unidirectional ve symmetric replication mimarileri arasında yapılacak seçim, kurumun OpenShift Virtualization üzerindeki tüm felaket kurtarma stratejisinin temelini belirler. Her model, operasyonel karmaşıklık, altyapı maliyeti, RPO/RTO taahhütleri ve otomasyon potansiyeli gibi farklı dengeler içerir. İster çift kümeli (dual-cluster) isterse genişletilmiş kümeli (stretched-cluster) bir yapı tercih edilsin, temel mimari tasarım, iş sürekliliği hedefleri ve altyapı kapasitesiyle uyumlu olmalıdır. Bu temel sağlandıktan sonra, felaket kurtarma sürecinin odak noktası altyapıdan orkestrasyona kayar: Varlıkların (VM’lerin) nasıl yerleştirildiği, yeniden başlatıldığı ve kontrol edildiği gibi daha üst seviye süreçler devreye girer. Böylece yalnızca veriyi değil, aynı zamanda operasyonu da kurtaran kapsamlı bir DR stratejisi mümkün olur.
Sarav Asiye Yiğit * 5 Ağustos 2025 Salı
Kaynakça:
https://www.redhat.com/en/blog/disaster-recovery-approaches-red-hat-openshift-virtualization
https://github.com/cncf/tag-storage/blob/master/cloud-native-disaster-recovery-whitepaper/Cloud%20Native%20Disaster%20Recovery%20v2.pdf