OpenShift Virtualization Mimari Önerileri serimize kaldığımız yerden devam ediyoruz. Önceki yazılarda, platformun yalnızca bir sanallaştırma çözümü olmadığını; altyapıdan ağa, depolamadan operasyonel modellere kadar bütüncül bir mimari yaklaşım sunduğunu detaylı şekilde ele aldık. İlk yazıda dönüşümün arkasındaki motivasyonu ve mimari yaklaşımın temelini oluştururken, ikinci yazıda altyapı bağımlılıklarını ve platformun sağlıklı çalışması için kritik olan servisleri değerlendirdik. Üçüncü yazıda ise ağ mimarisine derinlemesine bakarak, bağlantının ötesinde performans, izolasyon ve sürdürülebilirlik açısından doğru tasarım kararlarının ne kadar belirleyici olduğunu konuştuk. Artık elimizde doğru tasarlanmış, modern, esnek ve güçlü bir platform var. Ancak gerçek dünyada bir platformun değeri, yalnızca “çalışıyor” olmasıyla değil; hata anında nasıl davrandığı, kendini ne kadar hızlı toparlayabildiği ve ne kadar güvenli yönetilebildiği ile ölçülür.
Sanallaştırma dünyasında yıllardır alışık olduğumuz High Availability (HA) kavramı, Kubernetes-native bir platformda çok yönlü bir bakış açısıyla ele alınır. yalnızca bir VM’in yeniden başlatılması değil; failure detection, fencing ve remediation gibi mekanizmaların birlikte çalıştığı, daha dağıtık ve daha otomatik bir model söz konusudur.
High Availability (HA), bir node üzerinde oluşan bir hatanın tespit edilmesi ve bu node üzerinde çalışan sanal makinelerin başka bir node üzerinde yeniden başlatılabilmesi yeteneğini ifade eder. Ancak burada kritik bir ayrım yapmak gerekir. HA yalnızca “VM yeniden başlatma” mekanizması değildir. Veri merkezi seviyesinde dayanıklılık (resiliency), yani güç kaybı, network switch arızası gibi tüm cluster’ı etkileyebilecek dış faktörler, farklı bir tasarım alanıdır ve topology awareness kapsamında değerlendirilir. Bu nedenle HA’i doğru konumlandırmak önemlidir. HA, cluster içindeki node seviyesindeki hatalara karşı verilen otomatik bir tepkidir. OpenShift Virtualization’da bir node’un devre dışı kalması durumunda VM’lerin yeniden ayağa kaldırılması, tek adımlı bir işlem değildir. Bu süreç üç temel fazdan oluşur:
Failure Detection (Hata Tespiti)
İlk adım, bir node’un gerçekten “down” olduğunun doğru şekilde tespit edilmesidir. Kubernetes dünyasında bu genellikle node heartbeat mekanizması üzerinden yapılır. Her node düzenli olarak control plane’e “ben ayaktayım” sinyali gönderir. Bu sinyal kesildiğinde node önce NotReady durumuna düşer. Ancak burada önemli bir nokta vardır: Bir node’un geçici bir network problemi yaşaması ile gerçekten tamamen erişilemez olması aynı şey değildir. Eğer sistem bu ayrımı doğru yapamazsa, gereksiz VM restart’ları olabilir (false positive), aynı VM iki farklı node’da çalışabilir (split-brain riski).Bu yüzden failure detection aşaması, HA sürecinin en kritik ve en hassas kısmıdır.
Fencing (İzolasyon / Kesme)
Failure detection sonrası en kritik adım fencing’dir. Fencing’in amacı, arızalı olduğu düşünülen node’un gerçekten artık sistemle hiçbir şekilde etkileşime giremeyeceğini garanti altına almaktır. Yani, node tamamen kapatılır (power off), network (ağ) erişimi kesilir, storage erişimi engellenir.
Bu neden bu kadar önemli? Çünkü eğer fencing yapılmadan VM başka bir node’da yeniden başlatılırsa ve eski node aslında hala çalışıyorsa, aynı VM iki yerde birden çalışır, aynı diske iki farklı yerden yazılır, veri tutarsızlığı ve corruption oluşur.
Bu senaryoya “split-brain” denir ve karşılaşabileceğimiz en kritik risklerden biridir. Bu nedenle, fencing yapılmadan remediation (yeniden başlatma) asla güvenli değildir. Önemli bir nokta da şu,
OpenShift/Kubernetes bu mekanizmayı otomatik olarak sizin yerinize seçmez. Administrator’ün, IPMI, Redfish, Cloud provider API’leri ya da benzeri bir mekanizma ile fencing yöntemini açıkça tanımlaması gerekir. Bu, HA’in çalışması için minimum gereksinimlerden biridir.
Remediation (İyileştirme / Yeniden Başlatma)
Son aşama remediation’dır. Bu aşamada sistem artık şunlardan emindir: node gerçekten down, node izole edildi (fencing tamamlandı). Artık VM’ler güvenli bir şekilde başka bir node üzerinde yeniden başlatılabilir. Kubernetes tarafında bu süreç: VM’in bağlı olduğu node’un unavailable olarak işaretlenmesi, VM workload’un başka bir uygun node’a schedule edilmesi, disklerin yeniden attach edilmesi, VM’in yeniden boot edilmesi adımlarını içerir. Burada dikkat edilmesi gereken önemli bir gerçek var: Bu bir restart sürecidir, yani klasik anlamda “live migration” değildir. Dolayısıyla, VM kısa süreli kesinti yaşar, uygulama seviyesinde tolerans gerekebilir.
Özetle OpenShift Virtualization’da HA, tek bir özellik değildir. Birbirine bağlı üç kritik mekanizmanın birlikte çalışmasıdır:
Failure detection -> problemi doğru tespit eder
Fencing -> sistemi güvenli hale getirir
Remediation -> servisi yeniden ayağa kaldırır
Bu üçlüden herhangi biri eksik veya yanlış yapılandırılmışsa, HA ya çalışmaz ya da daha büyük problemlere yol açabilir. En kritik nokta, HA’in, varsayılan olarak “tam çalışır” şekilde gelmememsidir.
Özellikle fencing mekanizmasının doğru şekilde tasarlanması ve konfigüre edilmesi, mimarinin güvenilirliği açısından belirleyicidir.
Şimdi her bir başlığı daha detaylı ele alalım.
Failure Detection (Hata Tespiti)
HA sürecinin ilk adımı, bir node’un gerçekten problem yaşayıp yaşamadığını anlamaktır.
Yani sistem önce şu soruya cevap arar: “Bu node gerçekten çöktü mü, yoksa sadece geçici bir problem mi yaşıyor?” OpenShift/Kubernetes tarafında bu süreç control plane tarafından yürütülür. Her node üzerinde çalışan kubelet, belirli aralıklarla control plane’e durum bilgisini gönderir. Bunu şöyle düşünebiliriz: Her node düzenli olarak “Ben buradayım, sağlıklıyım” diye sinyal gönderir (heartbeat). Eğer bu sinyaller gelmemeye başlarsa, node önce NotReady durumuna düşer ve daha ciddi durumlarda Unknown olarak işaretlenir. Bu noktada önemli bir detay var. Bu durum hemen VM’lerin taşınacağı anlamına gelmez. Sistem sadece şunu der: “Bu node sağlıklı görünmüyor, bir sorun olabilir.” Yani failure detection, aksiyon almak değil, problemi fark etmektir.
OpenShift node hatasını nasıl anlar? OpenShift’te bu tespiti yapmak için birden fazla mekanizma birlikte çalışır. Bu da sistemi daha güvenilir hale getirir.
*Heartbeat (Durum Güncellemeleri)
En temel mekanizma budur. Node üzerindeki kubelet, belirli aralıklarla control plane’e durumunu bildirir. Bu güncellemeler kesilirse node şüpheli hale gelir. Basitçe, “Node konuşmayı bırakırsa, bir şeyler ters gidiyor demektir.”
*Node Health Checks
Bu mekanizma biraz daha akıllıdır. Sadece “node cevap veriyor mu?” diye bakmaz, aynı zamanda şunları da kontrol eder:
Node NotReady mi?
Bellek dolmuş mu? (memory pressure)
Disk dolmuş mu? (disk pressure)
Yani node hala ayakta olabilir ama üzerinde workload çalıştırmak artık güvenli olmayabilir. Bu da sistemin daha erken aksiyon almasını sağlar.
*Machine Health Checks
Bu biraz daha “altyapı seviyesinde” çalışan bir kontrol mekanizmasıdır. Burada artık sadece Kubernetes değil, fiziksel veya sanal sunucunun kendisi izlenir. Machine Health Check, Node’un çalıştığı makineyi izler ve gerekirse makineyi yeniden başlatabilir veya yeniden oluşturabilir. Ancak bunun çalışması için, Machine API kullanılması gerekir, node’ların bu API üzerinden yönetiliyor olması gerekir. Yani bu mekanizma daha çok “infra otomasyonu” tarafıdır.
En kritik nokta, failure detection aşamasında sistem sadece şunu yapar: “Bu node’da bir problem var” der fakat VM’leri hemen taşımaz, node’u kapatmaz ve herhangi bir riskli aksiyon almaz Bunun sebebi çok önemlidir. Eğer sistem yanlış alarm verirse (false positive), gereksiz restart’lar olur ve servis kesintisi yaşanır. Daha kötüsü, node aslında çalışıyorken “down” sanılabilir. Bu yüzden failure detection temkinli çalışır.
Fencing
Failure detection aşamasında sistem, bir node’un sağlıksız olabileceğini anlar. Ama bu bilgi tek başına yeterli değildir. Çünkü bir node control plane’e cevap vermiyor olsa bile, o node gerçekten tamamen durmuş olmayabilir. Yani şöyle bir durum mümkün olabilir:
Node, cluster ile iletişimini kaybetmiştir,
Control plane bu node’u NotReady veya Unknown olarak görür,
Ama node’un kendisi aslında hala açıktır,
Ve üzerinde çalışan sanal makineler de hala çalışıyor olabilir.
İşte burada fencing devreye girer. Fencing’in amacı, problemli node’u sistemden güvenli şekilde izole etmektir. Başka bir ifadeyle fencing, cluster’ın şundan emin olmasını sağlar: “Bu node artık VM çalıştıramaz, artık disklere erişemez ve artık sisteme zarar veremez.” Bu neden bu kadar önemlidir?
Çünkü cluster, aynı VM’i başka bir node üzerinde yeniden başlatmak istediğinde, eski node üzerinde o VM hala çalışıyorsa iki ayrı VM örneği aynı diski aynı anda kullanmaya çalışabilir. Bu da veri bozulmasına, dosya sistemi tutarsızlıklarına ve ciddi servis problemlerine yol açabilir. Bunu basit bir örnekle şöyle düşünebiliriz, aynı Word dosyasını iki kişinin aynı anda birbirinden habersiz biçimde düzenlediğini hayal edelim. Bir süre sonra hangi kopyanın doğru olduğu karışır. VM disklerinde ise bu durum çok daha yıkıcıdır. Çünkü burada yalnızca içerik çakışması değil, doğrudan disk bozulması yaşanabilir. Bu yüzden fencing, HA mekanizmasının en kritik güvenlik adımıdır. Fencing tamamlanmadan remediation güvenli değildir. OpenShift’te fencing nasıl yapılır? OpenShift’te fencing için farklı yöntemler vardır. Hangi yöntemin kullanılacağı; donanıma, node’ların nasıl yönetildiğine ve cluster’ın hangi altyapı modeliyle kurulduğuna bağlıdır.
*Self Node Remediation
Bu yöntem, node’un kendi kendini sistemden çıkarması mantığıyla çalışır. Özellikle şu durumlarda önerilir:
Sunucuda erişilebilir bir donanım yönetim arayüzü yoksa,
Yani BMC, iLO, iDRAC gibi out-of-band yönetim mekanizmaları bulunmuyorsa,
Ya da bu arayüzler cluster tarafından erişilemiyorsa.
Bu modelde node, belirli koşullar oluştuğunda kendisinin sağlıksız olduğunu anlayıp kendini yeniden başlatabilir veya kendini sistemden çıkartacak bir davranış gösterebilir. Yani burada mantık şudur: “Ben artık sağlıklı değilim; o halde kendimi devreden çıkarayım ki cluster güvenli şekilde devam edebilsin.” Bu yöntem bazı ortamlarda çok kullanışlıdır çünkü ekstra donanım entegrasyonu gerektirmez. Ancak yine de, mümkünse fiziksel güç kapatma gibi daha kesin yöntemler genellikle daha güçlü kabul edilir.
*Fence Agents Remediation
Bu yöntem genellikle en güvenilir ve en çok önerilen yöntemdir. Burada cluster, problemli node’u kapatmak için sunucunun donanım yönetim arayüzünü kullanır. Örneğin: BMC, iLO, iDRAC, Redfish benzeri yönetim arabirimleri. Bu arayüzler üzerinden sunucuya doğrudan “power off” komutu gönderilebilir. Bu yaklaşımın en büyük avantajı şudur: Cluster, problemli node’un gerçekten kapandığını dışarıdan doğrulayabilir. Yani node’un kendi insiyatifine bırakmadan, fiziksel seviyede müdahale eder. Bu yüzden bu yöntem mevcutsa genellikle tercih edilen yöntem budur. Çünkü en net güvenceyi sağlar: “Bu node artık kapalı; artık VM çalıştırması mümkün değil.”
*Machine Deletion Remediation
Bu yöntem daha çok Machine API kullanılan ortamlarda karşımıza çıkar. Burada yaklaşım şudur: Problemli node sistemden silinir, ardından yerine yeni bir node oluşturulur. Yani sadece mevcut node’u kapatmak değil, onu cluster’dan tamamen çıkarmak ve yerine sağlıklı bir makine getirmek hedeflenir. Bu model özellikle altyapının otomasyonla yönetildiği ortamlarda güçlüdür.
Ancak çalışabilmesi için genellikle şu koşullar gerekir:
Cluster node’ları Machine API ile yönetiliyor olmalı,
Bare metal cloud provider kullanılmalı,
Kurulum modeli buna uygun olmalı.
Bu yüzden her ortamda kullanılmaz; daha çok tam otomasyonlu altyapılarda anlamlıdır. Fencing neden bu kadar kritik? Buradaki en önemli kavramlardan biri split-brain riskidir. Split-brain, sistemin aynı VM’in iki farklı kopyasının çalıştığını düşünmeden devam etmesi durumudur. Örneğin:Eski node aslında hala VM’i çalıştırıyor, Cluster bunu bilmiyor ve aynı VM’i yeni bir node’da tekrar başlatıyor. Sonuç, iki VM örneği aynı anda aktif, ikisi de aynı storage’a erişmeye çalışıyor ve veri bozulması kaçınılmaz hale geliyor. İşte fencing bu riski ortadan kaldırmak için vardır. Yani fencing yalnızca bir node’u kapatmak değildir, veri bütünlüğünü korumak için yapılan zorunlu izolasyon işlemidir.
Remediation
Fencing tamamlandıktan sonra sistem artık güvenli bir noktaya gelir. Çünkü cluster şundan emindir:
Eski node artık VM çalıştırmıyor,
Aynı VM’in ikinci bir kopyası yok,
Workload güvenli şekilde yeniden başlatılabilir.
İşte bundan sonra remediation aşaması başlar. Remediation, problem yaşayan node üzerindeki workload’un başka bir sağlıklı node üzerinde yeniden ayağa kaldırılması sürecidir. OpenShift Virtualization’da bu işlem fencing sonrasında otomatik olarak gerçekleşir. Bu aşamada sistem, arızalı node üzerinde çalışan sanal makinelere ait VMI (VirtualMachineInstance) nesnelerini siler.
Burada çok önemli bir ayrım var: OpenShift, VM’i silmez. Sadece o anda çalışan örneği, yani VMI’yi siler. Bu farkı iyi anlamak gerekir:
VM (VirtualMachine) = Sanal makinenin tanımıdır.
Kaç CPU?
Ne kadar RAM?
Hangi disk?
Hangi ağ?
Nasıl çalışacak?
VMI (VirtualMachineInstance) = O VM’in şu anda çalışan canlı örneğidir
Yani remediation sırasında olan şey şudur: “Bu VM artık çalışmıyor sayılmalı; o halde yeni bir node üzerinde yeniden başlatılmalı.” Başka bir deyişle, OpenShift VM’in kimliğini ve tanımını korur, sadece çalışmakta olan instance’ı yeniden oluşturur.
Remediation süreci pratikte nasıl işler?
Genel akış şu şekildedir:
Node’un problemli olduğu tespit edilir,
Fencing ile node sistemden izole edilir,
Cluster, bu node üzerindeki VMI nesnelerini kaldırır,
Scheduler, VM’i çalıştırmak için uygun başka bir node belirler,
VM yeni node üzerinde yeniden başlatılır.
Bu noktada diskler, network bağlantıları ve ilgili kaynaklar yeni node ile yeniden ilişkilendirilir. Burada dikkat edilmesi gereken önemli bir nokta var: Bu süreç live migration değildir. Yani VM kesintisiz biçimde taşınmaz. Bu bir restart sürecidir. Dolayısıyla kısa süreli bir servis kesintisi oluşur. HA burada “kesintisiz çalışma” değil, “arıza sonrası otomatik toparlanma” sağlar.
Özet olarak, fencing ve remediation birlikte çalışır, ama aynı şey değildir. Fencing,
Problemli node’un artık VM çalıştıramayacağını ve disklere erişemeyeceğini garanti altına alır.
Remediation, bu garanti sağlandıktan sonra, VM’i başka bir sağlıklı node üzerinde yeniden başlatır.
Bu yüzden süreç sırası çok önemlidir: Önce fencing, sonra remediation. Eğer remediation fencing’den önce yapılırsa veri bozulması riski doğar. Eğer fencing doğru tasarlanmazsa HA güvenilir olmaz. Eğer remediation düzgün çalışmazsa servis toparlanamaz. Yani HA’in gerçekten işe yaraması için bu iki mekanizmanın birlikte ve doğru sırayla çalışması gerekir.
Sarav Asiye Yiğit * 24 Mart 2026
Kaynakça:
https://access.redhat.com/sites/default/files/attachments/openshift_virtualization_architecture_guide_v1.0.0.pdf
https://docs.redhat.com/en/documentation/workload_availability_for_red_hat_openshift/26.2/html-single/remediation_fencing_and_maintenance/index