DC failover manuel DNS değişikliğiyle yönetiliyorsa, RTO insan hızına bağlıdır.
Geleneksel primary/backup DNS yaklaşımında veri merkezi arızası tespit edilir, operasyon ekibi alarm alır, zone kaydı değiştirilir, servis reload edilir ve istemcilerin yeni DNS yanıtını alması beklenir. Bu süreç teknik olarak basit görünür; ancak gerçek incident anında karar, erişim, onay ve uygulama gecikmeleri RTO'yu uzatır.
Birçok kurumda sağlık kontrolü ile DNS sistemi ayrı çalışır. Monitoring aracı DC'nin erişilemediğini görür, fakat DNS hâlâ aynı IP'leri yanıtlamaya devam eder. Aradaki köprü çoğu zaman script, manuel runbook veya ayrı otomasyon katmanıdır. Bu kopukluk, failover anında en zayıf halka haline gelir.
Failback tarafı da en az failover kadar risklidir. DC kısa süreli gelip giderse DNS yanıtı sürekli değişebilir; istemciler farklı DC'lere savrulur, state senkronizasyonu oturmadan trafik geri dönebilir. Bu nedenle yalnızca "down olunca çıkar, up olunca ekle" mantığı yeterli değildir.
Doğru yaklaşım, DC sağlığını boolean scenario mantığıyla değerlendirmek, ardışık başarı/başarısızlık eşikleriyle flap riskini azaltmak ve DNS yanıtını bu kararın doğal çıktısı haline getirmektir. Planlı bakım için manuel cutover, tüm DC'ler sağlıksız olduğunda fail-safe yanıt ve DR koşulları aynı modelde bulunmalıdır.
TR7 DC Yedekleme bu modeli sunar: DC sağlık senaryosu değiştiğinde DNS yanıtını otomatik yeniler ve failover sürecini DNS TTL'i ile operatör tarafından belirlenen sağlık parametrelerine bağlar.
Yaklaşımımız
TR7, DC failover kararını sağlık senaryosu, boolean koşul yapısı, flap koruması ve manuel cutover mekanizmasıyla uygular.
Sağlık senaryosu DNS yanıtını doğrudan etkiler
Her DC için tanımlanan health check state'i değiştiğinde bağlı scenario yeniden değerlendirilir. Scenario sonucu değişirse ilgili DNS kayıtları yeniden üretilir ve sağlıksız DC yanıt dışına alınır.
Boolean koşullar karmaşık DC sağlık kararlarını modelleyebilir
Koşul grupları AND mantığıyla, gruplar arası birleşim OR mantığıyla kurulabilir. Her health check için negatif koşul da tanımlanabilir; böylece "bu kontrol sağlıksızsa aktif et" gibi ters senaryolar desteklenir.
Stuck-state koruması failback dalgalanmasını azaltır
DC geçiş durumundayken eski değerlendirme sonucu korunabilir. Bu davranış, kısa süreli up/down dalgalanmalarının DNS yanıtını sürekli değiştirmesini engellemeye yardımcı olur.
Maintenance mode planlı bakım için manuel cutover sağlar
Operatör planlı bakımda ilgili DC'yi maintenance mode ile pasifleştirebilir. Bu durumda DC sağlıklı görünse bile DNS yanıtından çıkarılabilir ve trafik diğer DC'ye yönlendirilebilir.
Yetenekler
DC Yedekleme, birden fazla veri merkezi arasında sağlık durumuna göre DNS yanıtını otomatik yöneten GTM failover katmanıdır.
N-DC priority chain primary, secondary ve tertiary akışları destekler
TR7, DC kayıtlarını array sırasına göre öncelik zinciri halinde değerlendirebilir. Primary DC sağlıksız olduğunda secondary, o da sağlıksız olduğunda tertiary gibi daha uzun failover zincirleri kurulabilir. Kod modeli teorik olarak sabit iki endpoint ile sınırlı değildir. Bu yapı finans, kamu ve büyük ölçekli SaaS ortamlarında çok aşamalı süreklilik tasarımını kolaylaştırır.
Veritabanını trafikle birlikte taşıyan tek GSLB
Bir veri merkezi sağlık senaryosunda başarısız olduğunda TR7 yalnızca DNS'i oradan çevirmez — tetikleyici aksiyon, veritabanı devrini aynı olayın parçası olarak yürütür. Oracle Data Guard geçişi, trafiği yönlendiren sağlık kararının kendisiyle başlar; böylece felaket kurtarma, köprü toplantısında kimin önce hareket edeceğini konuşan iki ekip yerine tek bir otomatik hareket olur.
Route Health Injection — devir ağa duyurulur, yalnızca içeride karar verilmiş olmaz
Kontrollerinden geçemeyen saha servis prefix'ini duyurmayı bırakır, ayakta kalan saha duyurmaya devam eder: karar üst yönlendiricilere saniyeler içinde bir yönlendirme güncellemesi olarak ulaşır. Trafiğin gerçekten taşınması bu demektir — yalnızca taşınmış işaretlenmesi değil. Adresi sadece sağlıklı saha duyurduğu için iki sahanın aynı anda adrese sahip çıktığı bir aralık oluşmaz, bir DNS kaydının ömrü dolarken kara delik yaşanmaz. BFD tespiti saniyenin epey altına indirir.
Her DC için beş otomatik sağlık kontrol tipi kullanılabilir
TR7, DC seviyesinde wanAccess, lanAccess, access, internet ve maintenanceMode gibi sağlık sinyallerini değerlendirebilir. WAN erişimi, LAN erişimi, genel access durumu, internet erişimi ve manuel bakım durumu ayrı ayrı modellenir. Bu sayede DC yalnızca tek ping sonucu ile değil, farklı erişim boyutlarıyla değerlendirilir. DNS yanıtı daha gerçekçi DC sağlığına göre şekillenir.
Ardışık başarı ve başarısızlık eşikleri flap riskini azaltır
requiredSuccess ve requiredFailure değerleri DC'nin up veya down kabul edilmesi için kaç ardışık sonuç gerektiğini belirler. Bu model geçici paket kaybı, kısa ağ kesintisi veya anlık servis yavaşlamasında DNS'in gereksiz değişmesini engeller. Operatör kritik servislerde daha hassas, dalgalı hatlarda daha toleranslı eşikler kullanabilir. RTO, bu eşikler ve kontrol periyoduyla birlikte planlanır.
backupBehavior modları pasif DC davranışını kontrol eder
noResponse modu pasif DC'nin normal durumda yanıt vermemesini sağlar. onlyNew modu, uzun süre kapalı kalmış veya güncel olmayan DC'nin eski veriyle yanıt vermesini engellemek için kullanılabilir. Bu davranış, failover sırasında yalnızca ayakta olan değil, doğru durumda olan DC'nin yanıt üretmesini sağlar. Stale data riski olan yapılarda önemli bir koruma katmanıdır.
DR modu felaket kurtarma kayıtlarını koşullu devreye alır
Per-record DR modu ile belirli kayıtlar yalnızca DR koşulu oluştuğunda aktif edilebilir. drCond scenario veya drIfNoRecords bayrağı, primary ve secondary hedefler boşaldığında DR kaydını devreye almayı sağlar. Bu model, uzak felaket merkezi IP'lerinin normal trafik almasını engellerken kritik durumda hazır beklemesini sağlar. DR stratejisi DNS seviyesinde kontrollü hale gelir.
FailSafe yanıt tüm DC'ler sağlıksız olduğunda son seçenek sunar
Hiçbir DC sağlıklı değilse fallbackRecords dizisinden yanıt üretilebilir. Bu kayıtlar bakım sayfası, statik acil durum endpoint'i veya farklı kurtarma servisi olabilir. FailSafe davranışı, DNS'in tamamen boş dönmesi yerine kontrollü son yanıt üretmesini sağlar. Operatör bu kayıtları kurumun kriz planına göre belirleyebilir.
State persistence restart sonrası değerlendirme sürekliliğini korur
TR7, lokal health check ve scenario state bilgilerini dosya seviyesinde saklayabilir. Restart veya servis yeniden başlatma sonrasında önceki state geri yüklenerek değerlendirme sıfırdan başlamaz. Bu yaklaşım failover kararının geçici restart sırasında gereksiz dalgalanmasını azaltır. Özellikle GTM servisinin yeniden başlatıldığı bakım işlemlerinde tutarlılık sağlar.
DC erişimi WAN ve LAN hedefleriyle çok yönlü doğrulanır
Her DC için wanAccess ve lanAccess listeleri tanımlanabilir. Birden fazla erişim hedefiyle DC'nin dış ve iç ulaşılabilirliği daha doğru anlaşılır. Tek bir hedefin geçici sorunu tüm DC'yi yanlış down göstermeyebilir. Bu yapı veri merkezi sağlığını daha kapsamlı modellemeye yardımcı olur.
Manual cutover planlı bakımda kontrollü trafik aktarımı sağlar
maintenanceMode aktif edildiğinde ilgili DC bilinçli olarak pasifleştirilebilir. Bu, patch, bakım, taşıma veya kontrollü DR testi sırasında kullanışlıdır. Operatör DC sağlıklı olsa bile DNS yanıtından çıkararak trafiği diğer DC'ye alabilir. Bakım tamamlandığında mod kapatılarak normal değerlendirme akışına dönülür.
Status enumeration DC arızasını daha anlaşılır sınıflandırır
DC durumu ok, noInternet, noAccess, noWan ve noLan gibi sonuçlarla ifade edilebilir. Bu sınıflandırma yalnızca "down" demek yerine hangi erişim boyutunun sorunlu olduğunu gösterir. Operasyon ekipleri internet çıkışı, WAN erişimi veya LAN erişimi problemini daha hızlı ayırt eder. Failover kararının nedeni daha okunur hale gelir.
DNS config regeneration health state değişiminde otomatik tetiklenir
Health check state'i değiştiğinde ilgili scenario hemen yeniden değerlendirilebilir. Scenario'ya bağlı kayıtlar dynamic config regeneration akışına alınır ve DNS yanıtı güncellenir. Bu davranış manuel zone düzenleme veya harici script ihtiyacını azaltır. Değişiklikler kısa debounce ile gruplanarak gereksiz tekrar üretim engellenir.
HA cluster içinde master DNS yazımı tek noktadan yapılır
HA cluster senaryosunda DNS config yazımı master rolü üzerinden kontrol edilir. Master düğüm düşerse yedek düğüm belirli güvenlik süreci sonunda rolü devralabilir. Bu model iki düğümün aynı anda farklı DNS config üretmesini engellemeye yardımcı olur. GTM davranışı cluster state'iyle uyumlu çalışır.
Operasyonel derinlik
DC failover operasyonu; kontrol periyodu, ardışık eşikler, HC ID yapısı, scenario koşulları, regeneration akışı ve RTO parametreleriyle birlikte planlanır.
DC checker interval
accessPeriod DC sağlık kontrollerinin hangi aralıkla çalışacağını belirler. Bu değer saniye veya dakika bazında ayarlanabilir. Daha kısa periyot daha hızlı algılama, daha uzun periyot daha sakin ve düşük gürültülü değerlendirme sağlar.
Required success/failure
requiredSuccess ardışık kaç başarıdan sonra DC'nin up kabul edileceğini belirler. requiredFailure ardışık kaç başarısızlıktan sonra DC'nin down kabul edileceğini belirler. Bu iki değer failover hızı ile flap koruması arasındaki dengeyi kurar.
DC access tipi
wanAccess ve lanAccess listeleri DC erişim hedeflerini tanımlar. DC'nin yalnızca dış dünyadan değil, iç ağdan da erişilebilir olup olmadığı değerlendirilebilir. Bu ayrım özellikle inter-DC ve hybrid routing senaryolarında önemlidir.
HC ID formatı
Otomatik HC kayıtları `auto|
Scenario condition yapısı
Koşullar grup içinde AND, gruplar arasında OR mantığıyla birleşebilir. Bu yapı basit primary down kontrolünden karmaşık DC sağlık senaryolarına kadar farklı karar modellerini destekler. Operatör yalnızca tek check sonucuna mahkûm kalmaz.
Failover decision akışı
HC state değiştiğinde scenario yeniden değerlendirilir, bağlı kayıtlar belirlenir ve dynamic config regeneration tetiklenir. Bu akış kısa debounce ile çalışarak peş peşe gelen değişiklikleri tek üretim turunda birleştirebilir. DNS yanıtı health state'e göre yeniden render edilir.
RTO parametre bağımlılığı
RTO; accessPeriod, requiredFailure, regeneration debounce süresi ve DNS TTL davranışına bağlıdır. Bu nedenle tek sabit süre iddiası yerine servis ihtiyacına göre ayarlanabilir failover penceresi planlanmalıdır. Kritik servislerde daha kısa TTL ve daha sık kontrol tercih edilebilir.
Hangi senaryolarda kullanılır
Aktif pasif klasik DC çifti
DC1 primary, DC2 pasif yedek olarak tanımlanır. DC1 internet veya erişim senaryosu başarısız olduğunda DC1 kayıtları DNS yanıtından çıkarılır ve DC2 yanıt vermeye başlar.
Finans kurumunda üç DC priority chain
Finans kurumları DC1 → DC2 → DC3 sıralı failover zinciri kurabilir. Her seviye kendi health scenario'su ile değerlendirilir ve sağlıksız DC otomatik olarak yanıt dışına alınır.
Planlı bakımda manuel cutover
Bakım saatinde DC1 maintenance mode'a alınır ve trafik DC2'ye yönlendirilir. Bakım tamamlandığında maintenance mode kapatılır ve normal sağlık değerlendirme akışı devam eder.
Uzak felaket merkezi DR aktivasyonu
Primary ve secondary DC sağlıksız olduğunda DR mode kayıtları devreye girebilir. Bu senaryoda uzak felaket merkezi normalde pasif kalır, yalnızca belirlenen koşullar oluştuğunda DNS yanıtına eklenir.
Stale data korumalı secondary DC kullanımı
Uzun süre kapalı kalan DC yeniden açıldığında eski veriyle yanıt vermesi istenmeyebilir. onlyNew davranışıyla güncel olmayan DC pasif kalır ve yanlış kayıt yayınlama riski azaltılır.
Geofence ve failover hibrit yönlendirme
Önce ülke veya bölge bazlı en yakın DC seçilir, ardından seçilen DC sağlıksızsa yedek DC devreye alınır. Bu model performans yönlendirmesi ile süreklilik kararını aynı GTM yapısında birleştirir.
Sık sorulanlar
DC failover kararı ne zaman ve nasıl tetiklenir?
Flap koruması nasıl çalışır?
RTO ne kadar olur?
DR modu normal failover'dan nasıl ayrışır?
GTM servisi yeniden başlatılırsa failover state kaybolur mu?
Planlı bakımda DC nasıl pasifleştirilir?
DC failover'ı DNS TTL hızına taşıyın
Sağlık senaryosu, DNS yanıtı ve manuel cutover tek karar hattında. Kendi DC yapınızla canlı bir kurulumda gezdirelim.