Sunucu Kümeleme Nedir? Mimari, Türler ve Gerçek Dünya Uygulaması

Sunucu kümeleme, düğümler olarak adlandırılan birden fazla fiziksel veya sanal sunucuyu birbirine bağlayarak tek, birleşik bir sistem olarak çalışmalarını sağlama uygulamasıdır. Bu mimari, iş yükü dağıtımını, otomatik yük devretmeyi ve yatay ölçeklenebilirliği mümkün kılarak bireysel donanım veya yazılım bileşenleri başarısız olduğunda bile uygulamaların kullanılabilir kalmasını sağlar. Doğru yapılandırılmış bir kümede hiçbir düğüm tek bir hata noktası oluşturmaz; bu, kümelenmiş altyapıyı bağımsız sunucu dağıtımlarından ayıran temel ilkedir.

Kesinti süresinin doğrudan gelir kaybına, düzenleyici riske veya veri bozulması tehlikesine yol açtığı her iş yükünde sunucu kümeleme isteğe bağlı değildir — temel mimari gerekliliktir.

Sunucu Kümeleme Mimari Düzeyde Nasıl Çalışır

Özünde bir küme, birbiriyle bağlantılı üç katman üzerine inşa edilmiştir: işlem düğümleri, paylaşılan veya çoğaltılmış depolama ve küme yönetim yazılımı. Bu katmanların birlikte tasarlanması ve ayarlanması gerekir; herhangi birindeki yanlış yapılandırma, diğerlerinin sağlamaya çalıştığı güvenceleri zayıflatır.

Düğümler

Her düğüm, hedef iş yükünü bağımsız olarak çalıştırabilen tam bir sunucudur — fiziksel veya sanal. Düğümler, yalnızca sinyal ve dahili küme trafiği için kullanılan özel bir özel ara bağlantı üzerinden iletişim kurar (genellikle ayrı bir NIC veya bağlı bir çift). Bu ağ, son kullanıcı isteklerine hizmet eden genel ağdan ayrıdır.

Sinyal, kümenin nabzıdır. Düğümler, yapılandırılabilir aralıklarla (genellikle her 1–2 saniyede bir) sinyal alışverişi yapar. Bir düğüm belirli sayıda ardışık sinyali kaçırırsa, küme yöneticisi onu ölü ilan eder ve yük devretmeyi başlatır. Buradaki kritik bir uç durum, bölünmüş beyin senaryosudur: sinyal ağının kendisi başarısız olduğunda, her iki düğüm de diğerinin öldüğünü düşünebilir ve aynı anda paylaşılan kaynakların sahipliğini almaya çalışarak veri bozulmasına neden olabilir. Bölünmüş beyni önlemek için bir çekirdek mekanizması gereklidir — özel bir çekirdek diski, bir tanık sunucu veya bulut tabanlı bir tahkim hizmeti gibi bir karar verici kaynak.

Paylaşılan ve Çoğaltılmış Depolama

Depolama mimarisi, küme türüne göre önemli ölçüde farklılık gösterir:

• Paylaşılan diskli kümeler, tüm düğümlerin aynı anda bağladığı bir SAN (Storage Area Network) veya NAS (Network-Attached Storage) cihazı kullanır. Küme yöneticisi, veriyi bozacak eş zamanlı yazmaları önlemek için SCSI rezervasyonlarını veya dağıtılmış kilit yöneticilerini (DLM) kullanır.
• Paylaşımsız kümeler, verileri düğümler arasında blok veya uygulama düzeyinde çoğaltır (örneğin, Linux için DRBD, SQL Server Always On Availability Groups). Her düğüm kendi yerel depolamasına sahiptir; çoğaltma onları senkronize tutar.
• Hibrit mimariler, birincil veriler için paylaşılan depolama ve coğrafi olarak ayrı bir siteye olağanüstü durum kurtarma için çoğaltmayı birleştirir.

Küme Yönetim Yazılımı

Küme yöneticisi, kaynak düzenlemesinden, sağlık izlemesinden ve otomatik yük devretmeden sorumludur. Yaygın olarak kullanılan çözümler şunlardır:

• Pacemaker + Corosync — Linux’ta fiili standart (RHEL, CentOS, Ubuntu)
• Windows Server Failover Clustering (WSFC) — Windows Server ortamlarına özgü
• Kubernetes — pod zamanlaması, kendi kendini iyileştirme ve sıralı güncellemelerle kapsayıcı tabanlı kümeleme
• VMware vSphere HA / vSAN — sanallaştırılmış iş yükleri için hiper yönetici düzeyinde kümeleme

Her çözüm, kaynakları, kısıtlamaları ve yük devretme politikalarını tanımlamak için farklı temel öğeler sunar. Örneğin Pacemaker’daki bir kaynak, kümenin yönettiği herhangi bir hizmettir — bir IP adresi, bir dosya sistemi bağlama noktası, bir veritabanı arka plan programı — ve kısıtlamalar, bu kaynaklar için sıra ve birlikte yerleşim kurallarını tanımlar.

Sunucu Kümelemenin Temel Faydaları

Yüksek Kullanılabilirlik ve Otomatik Yük Devretme

Çoğu küme dağıtımı için birincil etken yüksek kullanılabilirlik (HA)‘dır. Bir düğüm başarısız olduğunda, küme yöneticisi kaçırılan sinyaller aracılığıyla hatayı algılar, ardından etkilenen kaynakları hayatta kalan bir düğüme taşır — bu işleme yük devretme denir. Modern küme yazılımı bunu çoğu iş yükü için 30 saniyenin altında tamamlayabilir; ancak veritabanı düzeyinde kurtarma (çökme kurtarma, günlük yeniden oynatma) iş yüküne bağlı ek süre ekler.

Kurtarma Süresi Hedefi (RTO) ve Kurtarma Noktası Hedefi (RPO), HA kalitesini tanımlayan iki metriktir:

• RTO — yük devretme sırasında hizmetin ne kadar süre kullanılamaz olduğu
• RPO — çoğaltma tamamlanmadan önce birincil düğüm başarısız olursa ne kadar verinin kaybolabileceği (zaman olarak ölçülür)

Eş zamanlı çoğaltma RPO = 0 elde eder, ancak birincil her yazmayı onaylamak için replikayı beklediğinden yazma gecikmesi oluşturur. Eş zamansız çoğaltma gecikmeyi azaltır ancak sıfır olmayan bir RPO kabul eder. İkisi arasında seçim yapmak, salt teknik değil, bir iş kararıdır.

Yük Dengeleme ve Yatay Ölçeklenebilirlik

Yük dengeleme kümeleri, gelen istekleri round-robin, en az bağlantı, IP hash veya ağırlıklı dağıtım gibi algoritmalar kullanarak düğümler arasında dağıtır. Yük dengeleyicinin kendisi — donanım (F5, Citrix ADC) veya yazılım (HAProxy, NGINX, LVS) olsun — kümenin önünde yer alır ve tek bir hata noktası olmaktan kaçınmak için yedekli olmalıdır.

Bir kümede yatay ölçekleme, bireysel sunucu donanımını yükseltmek (dikey ölçekleme) yerine düğüm eklemek anlamına gelir. Bu ekonomik açıdan önemlidir: emtia donanım düğümleri, yüksek kaliteli monolitik sunuculara kıyasla birim işlem başına daha ucuzdur ve küme, temel donanımı uygulamadan soyutlar.

Hata Toleransı ve Yedeklilik

Hata toleransı, düğüm yedekliliğinin ötesine geçer. Üretim kalitesinde bir küme tasarımı şunları hesaba katar:

• Ayrı PDU’lara ve UPS birimlerine bağlı her düğümde çift güç kaynağı
• Yedekli ağ yolları (ayrı anahtarlara NIC bağlama veya LACP trunking)
• Tek HBA veya kablo arızalarını ortadan kaldıran depolama bağlantısı için Çok Yollu G/Ç (MPIO)
• Site düzeyindeki arızalara karşı koruma için kullanılabilirlik bölgeleri veya veri merkezleri arasında coğrafi dağıtım

Bu katmanlardan herhangi birini görmezden gelmek, küme yazılımının telafi edemeyeceği gizli tek hata noktaları oluşturur.

Basitleştirilmiş Sıralı Bakım

Operasyonel açıdan değeri göz ardı edilen bir fayda sıfır kesinti süreli bakımdır. Bir düğüm zarif bir şekilde tahliye edilebilir — kaynakları eşlere taşınır — yamalanır, yeniden başlatılır ve herhangi bir hizmet kesintisi olmaksızın kümeye geri döndürülür. Buna sanallaştırılmış ortamlarda planlı yük devretme veya canlı geçiş denir. Bu, işletim sistemi yamalama ve donanım değiştirmeyi zamanlanmış bakım pencerelerinden rutin, kesintisiz işlemlere dönüştürür.

Sunucu Kümesi Türleri

Yüksek Kullanılabilirlik Kümeleri

HA kümeleri en yaygın kurumsal dağıtımdır. İki düğümlü aktif-pasif bir HA kümesi, iş yükünü birincil düğümde çalıştırırken ikincil düğüm sürekli senkronize edilerek bekleme modunda kalır. Aktif-aktif bir varyant, iş yükünü tüm düğümlerde aynı anda çalıştırır; bu, verimi artırır ancak uygulamanın eş zamanlı çok düğümlü erişimi desteklemesini gerektirir — tüm veritabanları veya eski uygulamalar bunu desteklemez.

Yük Dengeleme Kümeleri

Bu kümeler doğası gereği aktif-aktiftir. Yük dengeleyici, oturumları bir uygulama sunucuları havuzuna dağıtır. Oturum kalıcılığı (yapışkan oturumlar), durum bilgili uygulamalar için yaygın bir gerekliliktir: yük dengeleyici, belirli bir istemcinin isteklerini oturum boyunca aynı arka uç düğüme yönlendirmelidir. Bu, düğüm kaldırmayı ve yük devretmeyi karmaşıklaştıran örtük bir bağımlılık oluşturur; bu nedenle durumsuz uygulama tasarımı modern mimarilerde güçlü bir şekilde tercih edilir.

Yük Devretme Kümeleri

Yük devretme kümeleri, ham performans yerine kurtarma hızını ve veri bütünlüğünü ön plana çıkarır. SQL Server, Oracle RAC ve SAP HANA dağıtımları için standart mimaridir. Temel mühendislik zorluğu, yük devretme hedefinin hata anında tüm verilerin tutarlı ve güncel bir kopyasına sahip olmasını sağlamaktır — bu nedenle bu ortamlarda eş zamanlı çoğaltma ve çekirdek tasarımı tartışmasızdır.

Depolama Kümeleri

Ceph, GlusterFS ve MinIO gibi dağıtılmış depolama sistemleri, üzerlerindeki işlem kümesinden bağımsız olarak kendi küme katmanlarını oluşturur. Örneğin Ceph, merkezi bir meta veri darboğazı olmaksızın verileri OSD’ler (Nesne Depolama Arka Plan Programları) arasında dağıtmak için bir CRUSH algoritması kullanır. Depolama kümeleri, Kubernetes iş yükleri için kalıcı birim arka ucunu ve HA işlem kümeleri için paylaşılan depolama katmanını sağlar.

İşlem ve HPC Kümeleri

Yüksek performanslı bilişim kümeleri, düğümleri hesaplama işlerine tahsis etmek için iş zamanlayıcıları (SLURM, PBS, LSF) kullanır. Düğümler, paralel bilimsel iş yüklerinin gerektirdiği düşük gecikmeli, yüksek bant genişlikli MPI (Message Passing Interface) iletişimini desteklemek için InfiniBand veya yüksek hızlı Ethernet aracılığıyla birbirine bağlanır. Derin öğrenme eğitimi, moleküler dinamik, hesaplamalı akışkanlar dinamiği gibi GPU hızlandırmalı iş yükleri için NVLink veya NVSwitch ara bağlantılarına sahip GPU Hosting altyapısı ilgili mimaridir.

Gerçek Dünya Uygulama Değerlendirmeleri

Ağ Tasarımı

Küme ağı tek bir ağ değildir. Doğru tasarlanmış bir küme, en az üç ayrı ağ segmentine sahiptir:

1. Genel ağ — istemciye yönelik trafik
2. Özel küme ara bağlantısı — sinyal ve dahili küme iletişimi
3. Depolama ağı — paylaşılan depolama arka ucuna iSCSI, NFS veya Fibre Channel trafiği

Bunları tek bir NIC veya VLAN üzerinde karıştırmak, çekişme yaratır ve depolama G/Ç doygunluğunun sinyal sinyallerini bozduğu, yanlış yük devretmeleri tetiklediği senaryolara yol açar.

Çitleme ve STONITH

STONITH (Shoot The Other Node In The Head — Diğer Düğümü Kafasından Vur), bir kümenin başarısız olduğuna inandığı bir düğümü zorla kapattığı veya sıfırladığı mekanizmadır. Çitleme olmadan, yanıt vermeyen ancak tamamen ölmemiş bir düğüm, küme zaten yük devretme yapmışken paylaşılan depolamaya yazmaya devam edebilir — bu, veri bozulmasına giden garantili bir yoldur. STONITH uygulamaları arasında IPMI/iDRAC tabanlı güç kontrolü, PDU anahtarlama ve hiper yönetici düzeyinde zorla kapatma yer alır. Çalışan bir çitleme yapılandırması olmayan herhangi bir HA kümesi gerçekte HA değildir.

Uygulama Düzeyinde Kümeleme ile Altyapı Düzeyinde Kümeleme

Sıklıkla gözden kaçan kritik bir ayrım: altyapı kümeleme (Pacemaker, WSFC) düğüm düzeyinde yük devretme sağlar, ancak uygulamanın da ani yeniden başlatmalara toleranslı olacak şekilde tasarlanması gerekir. Veritabanları çökme kurtarması gerektirir; uygulama sunucularının arka uçlarla bağlantıları yeniden kurması gerekebilir; önbellekler yük devretmeden sonra soğuk olabilir. Uygulama düzeyinde kümeleme — veritabanı çoğaltma grupları, Elasticsearch kümeleri veya Kafka broker kümeleri gibi — veri tutarlılığını ve kullanılabilirliğini, altındaki altyapıdan bağımsız olarak veri katmanında ele alır. Üretim ortamları genellikle her ikisini de katmanlar: işlem katmanı için altyapı HA ve veri katmanı için uygulama düzeyinde çoğaltma.

Düğümler Arası Gecikme

Eş zamanlı çoğaltma için düğümler arası gecikme, yazma performansını doğrudan etkiler. Eş zamanlı bir taahhüt, istemciye yazmayı onaylamadan önce replikaya bir gidiş-dönüş gerektirir. 1ms düğümler arası gecikmede, teorik maksimum eş zamanlı yazma verimi, yerel diskin ne kadar hızlı olduğundan bağımsız olarak iş parçacığı başına saniyede 1.000 işlemdir. Bu nedenle coğrafi olarak dağıtılmış eş zamanlı kümeler, siteler arasında ~100 km’nin ötesinde pratik değildir ve bölgeler arası olağanüstü durum kurtarma için eş zamansız çoğaltma kullanılır.

Sunucu Kümelemenin Doğru Seçim Olduğu Durumlar

Sunucu kümeleme, kesinti süresinin veya veri kaybının maliyeti kümeleme altyapısının maliyetini aştığında uygundur. Belirli göstergeler:

• Uygulamanın %99,9 veya daha yüksek kullanılabilirlik gerektiren bir SLA’sı var (yılda 8,7 saatten az kesinti süresi)
• İş yükü yamalama, donanım değiştirme veya kapasite değişiklikleri için kesintiye uğratılamaz
• Trafik kalıpları öngörülemeyen veya ani artışlı, esnek yatay ölçekleme gerektiriyor
• Düzenleyici gereklilikler veri yedekliliği ve denetlenebilirlik zorunlu kılıyor (PCI-DSS, HIPAA, SOC 2)
• Uygulama, veri kaybının yasal sonuçları olan finansal işlemleri, tıbbi kayıtları veya gerçek zamanlı iletişimleri işliyor

Bu kriterleri karşılamayan daha küçük iş yükleri için, otomatik yedeklemeler ve izleme ile iyi yapılandırılmış bir VPS Hosting ortamı, maliyetin çok daha küçük bir kısmıyla yeterli esneklik sağlayabilir.

Zorluklar ve Yaygın Hata Modları

Maliyet ve Altyapı Yükü

Minimum uygulanabilir bir HA kümesi, en az iki düğüm, paylaşılan veya çoğaltılmış depolama, yedekli ağ ve küme yönetim yazılımı lisanslaması (uygulanabilir olduğunda) gerektirir. Şirket içi dağıtımlar için bu, genellikle tek sunucu dağıtımına kıyasla 3x ila 5x maliyet çarpanı anlamına gelir. Yönetilen hizmetler kullanan bulut tabanlı kümeleme (AWS RDS Multi-AZ, Azure SQL Managed Instance), bu maliyeti operasyonel gider modeline kaydırır ancak satıcı bağımlılığı getirir.

Yapılandırma Karmaşıklığı ve Operasyonel Uzmanlık

Küme yanlış yapılandırması, kurumsal ortamlarda planlanmamış kesintilerin önde gelen nedenlerinden biridir. Yaygın hatalar şunlardır:

• Çitleme yapılandırılmamış veya test edilmemiş — küme düğüm arızalarından güvenli bir şekilde kurtulamaz
• Çekirdek yanlış yapılandırılmış — bölünmüş beyin senaryoları paylaşılan verileri bozar
• Kaynak bağımlılıkları yanlış tanımlanmış — hizmetler yük devretmeden sonra yanlış sırada başlar, basamaklı arızalara neden olur
• Sinyal ağı üretim trafiğiyle aynı arayüzde — depolama veya trafik artışları yanlış yük devretmeleri tetikler

Süregelen küme yönetimi, hem küme yazılımını hem de koruduğu uygulamaları anlayan mühendisler gerektirir. Bu, genel sistem yönetiminden farklı bir beceri setidir.

Depolama Darboğazları

Paylaşılan depolama, HA kümelerinde yaygın bir performans darboğazıdır. Tüm düğümler, aynı depolama arka ucuna G/Ç bant genişliği için rekabet eder. Kötü tasarlanmış depolama kümeleri, tüm sistem için sınırlayıcı faktör haline gelir. Çözümler arasında depolama katmanlama (sıcak veriler için NVMe, soğuk veriler için dönen disk), düğümlerde okuma önbelleğe alma ve tek depolama denetleyicisini ortadan kaldıran dağıtılmış depolama mimarileri yer alır.

Maksimum G/Ç performansı ve tam donanım kontrolü gerektiren iş yükleri için, yerel NVMe depolama ve donanım RAID’e sahip Dedicated Servers, depolama için optimize edilmiş küme düğümleri oluşturmak için güçlü bir temel sağlar.

Web Hosting Ortamları için Küme Mimarisi

Web’e yönelik kümeler, açıkça ayrıntılandırmaya değer belirli bir mimari kalıba sahiptir:

[Client Requests]
        |
[Load Balancer Layer] (HAProxy / NGINX / cloud LB — active-active pair)
        |
[Application Server Layer] (Node 1, Node 2, Node N — stateless)
        |
[Database Layer] (Primary + Replica — HA cluster with automatic failover)
        |
[Shared Storage / Object Storage] (Ceph, NFS, S3-compatible)

Her katman bağımsız olarak ölçeklenebilir ve yedeklidir. Uygulama sunucuları durumsuztur — oturum durumu, yerel düğümde değil, paylaşılan bir Redis veya Memcached kümesinde depolanır. Bu tasarım, herhangi bir uygulama düğümünün aktif oturumları etkilemeden kaldırılabileceği veya eklenebileceği anlamına gelir.

Web altyapısını ölçekte yöneten ekipler için VPS with cPanel ortamları, DNS yönetimi, SSL sağlama ve çok alan adı yapılandırması gibi küme ile ilgili görevleri basitleştiren yönetilen bir kontrol düzlemi sağlar. Kümeleme yığınları üzerinde ayrıntılı kontrol tercih eden ekipler için VPS Control Panels, farklı operasyonel modellere uygun çeşitli seçenekler sunar.

Kümelenmiş bir web ortamında SSL sonlandırma özel dikkat gerektirir: yük dengeleyici genellikle TLS sonlandırmayı üstlenir, trafiği şifreyi çözerek dahili ağ üzerinden arka uç düğümlere dağıtmadan önce işler. Bu, SSL Certificates‘ın bireysel uygulama düğümlerinde değil, yük dengeleyici katmanında sağlanmasını ve yenilenmesini gerektirir — düğüm yük devretmesinden sonra sertifika hatalarına neden olan yaygın bir yanlış yapılandırma.

Teknik Karar Matrisi

Belirli bir iş yükü için uygun küme mimarisini belirlemek için bu matrisi kullanın:

Pratik Temel Çıkarım Kontrol Listesi

Bir sunucu kümesi dağıtmadan önce aşağıdakilerin her birini doğrulayın:

• Çekirdek yapılandırılmış tek sayıda oy veya özel bir karar verici ile — asla çekirdek tanığı olmadan iki düğümlü küme dağıtmayın
• Çitleme (STONITH) test edilmiş bir ağ kablosunu fiziksel olarak çekerek ve kümenin düğümü doğru şekilde izole ettiğini ve yük devretmeyi tamamladığını onaylayarak
• Sinyal ve üretim ağları ayrı fiziksel arayüzlerde — asla paylaşmayın
• Depolama çok yolu (MPIO) yapılandırılmış paylaşılan depolamaya en az iki bağımsız yolla
• Çoğaltma gecikmesi izleniyor RPO ihlal edilmeden önce tanımlanmış uyarı eşikleriyle
• Yük devretme yük altında test edilmiş — hiç test edilmemiş bir küme küme değil, bir teoridir
• Yük devretmeden sonra uygulama davranışı doğrulanmış — uygulamanın yeni birincile yeniden bağlandığını, eski bağlantıları temizlediğini ve trafiği doğru şekilde sunduğunu onaylayın
• Küme olayları merkezi, harici bir günlük sunucusuna kaydediliyor — tanılamaya çalıştığınız hata sırasında kullanılamayabilecek yerel düğüm depolamasına değil
• SSL sertifikaları yük dengeleyici katmanında sağlanmış, bireysel arka uç düğümlerde değil
• Kapasite planlaması N-1 düğüm kullanılabilirliğini hesaba katıyor — küme, bir düğüm çevrimdışıyken tam üretim yükünü kaldırabilmelidir

Sıkça Sorulan Sorular

Bir sunucu kümesi için gereken minimum düğüm sayısı nedir?

Teknik olarak, aktif-pasif bir HA kümesi için iki düğüm yeterlidir. Ancak iki düğümlü bir küme, bölünmüş beyni önlemek için bir çekirdek tanığı (üçüncü bir karar verici kaynak) gerektirir. Aktif-aktif yük dengeleme kümeleri için, bir düğüm bakım için kaldırıldığında yedekliliği korumak amacıyla pratik minimum üç düğümdür.

Sunucu kümesinde bölünmüş beyin nedir ve neden tehlikelidir?

Bölünmüş beyin, kümenin dahili iletişim ağı başarısız olduğunda ve düğümlerin birbirleriyle iletişimini kaybetmesine neden olduğunda ortaya çıkar. Her düğüm diğerinin başarısız olduğu sonucuna varır ve aynı anda paylaşılan kaynakların sahipliğini almaya çalışır. Her iki düğüm de koordinasyon olmaksızın aynı paylaşılan depolamaya eş zamanlı yazarsa, sonuç veri bozulmasıdır. Çekirdek mekanizmaları ve STONITH çitleme, bölünmüş beyne karşı iki savunmadır.

Sunucu kümeleme, sunucu sanallaştırmadan nasıl farklıdır?

Sanallaştırma, tek bir fiziksel sunucuyu birden fazla izole sanal makineye böler. Kümeleme, birden fazla sunucuyu tek bir sistem olarak hareket edecek şekilde birbirine bağlar. İkisi tamamlayıcıdır: sanallaştırılmış sunucular (VM’ler) sıklıkla küme düğümleri olarak kullanılır ve VMware vSphere gibi hiper yönetici platformları, işletim sistemi veya uygulama düzeyinde değil, VM düzeyinde çalışan kendi HA kümeleme özelliklerini içerir.

Sunucu kümeleme tüm kesinti sürelerini ortadan kaldırabilir mi?

Hayır. Kümeleme, yük devretmeyi otomatikleştirerek planlanmamış kesinti süresini önemli ölçüde azaltır, ancak ortadan kaldırmaz. Yük devretmenin kendisi zaman alır (iş yüküne ve küme yapılandırmasına bağlı olarak saniyeler ila dakikalar). Ayrıca küme yazılımındaki hatalar, eş zamanlı çok düğümlü arızalar ve ağ bölümleme senaryoları, kümelemenin önleyemeyeceği kesintilere neden olabilir. Hedef, mutlak sıfır kesinti süresine ulaşmak değil, tanımlanmış bir kullanılabilirlik SLA’sını karşılamaktır.

HA kümesi ile olağanüstü durum kurtarma (DR) kurulumu arasındaki fark nedir?

Bir HA kümesi, genellikle RPO = 0 ve saniyeler ila dakikalar içinde ölçülen RTO ile aynı site veya kullanılabilirlik bölgesinde otomatik, neredeyse anlık yük devretme sağlar. Bir DR kurulumu, verileri coğrafi olarak ayrı bir siteye çoğaltır ve dakikalar ila saatler içinde ölçülen RTO ve eş zamansız çoğaltma nedeniyle sıfır olmayan RPO ile etkinleştirmek için manuel veya yarı otomatik müdahale gerektirir. Hem yerel esneklik hem de coğrafi yedeklilik gerektiren üretim ortamları, bir site içinde HA kümeleme ve siteler arasında DR çoğaltma dağıtır.