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.
TR7, DC failover kararını sağlık senaryosu, boolean koşul yapısı, flap koruması ve manuel cutover mekanizmasıyla uygular.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
DC failover operasyonu; kontrol periyodu, ardışık eşikler, HC ID yapısı, scenario koşulları, regeneration akışı ve RTO parametreleriyle birlikte planlanır.
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.
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.
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.
Otomatik HC kayıtları `auto|
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.
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; 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.
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 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.
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.
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.
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.
Ö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.
Sağlık senaryosu, DNS yanıtı ve manuel cutover tek karar hattında. Kendi DC yapınızla canlı bir kurulumda gezdirelim.