Yetenek

Sağlık Kontrolleri Senaryoları

DNS yanıtını statik kayıt olmaktan çıkarın; veri merkezi, uygulama ve servis sağlığına göre dinamik karar verdirin.

TR7 Sağlık Kontrolleri Senaryoları, GTM kararlarını yalnızca "veri merkezi açık mı kapalı mı?" seviyesinde bırakmaz. HTTP, HTTPS, Oracle ve diğer sağlık kontrollerinden gelen sonuçları, veri merkezi bazlı otomatik kontrollerle ve boolean senaryolarla birleştirerek DNS yanıtına gerçek servis sağlığını yansıtır. Her veri merkezi için WAN erişimi, LAN erişimi, genel erişim, internet durumu ve bakım modu gibi otomatik kontroller kullanılabilir. Bunlara kullanıcı tanımlı HTTP/HTTPS içerik kontrolleri, JSONata doğrulamaları, Oracle bağlantı senaryoları ve ADC tarafındaki sağlık sonuçları eklenebilir. Senaryo motoru AND/OR kombinasyonlarını ve negatif koşulları destekler. Örneğin bir kayıt yalnızca veri merkezi erişilebilir, uygulama sağlıklı, veritabanı cevap veriyor ve bakım modu kapalıysa DNS yanıtına alınabilir. Değişiklik olduğunda yalnızca etkilenen kayıtların yeniden üretilmesi hedeflenir. Sonuç: TR7'de sağlık kontrolü sadece izleme verisi değildir; DNS'in hangi IP'yi döneceğini belirleyen canlı karar katmanıdır.

5
Her veri merkezi için otomatik sağlık kontrolü (WAN, LAN, erişim, internet, bakım modu)
11
Sağlık kontrolü tipi — TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS, Oracle
3
Varsayılan ardışık başarı/başarısızlık eşiği — flap koruması

Veri merkezi ayakta görünebilir; ama uygulama, veritabanı veya erişim yolu çalışmıyor olabilir.

GTM tarafında en yaygın hata, veri merkezi sağlığını tek bir up/down işaretiyle yönetmektir. Oysa gerçek hayatta veri merkezi erişilebilir olabilir ama uygulama kapanmış olabilir; uygulama cevap verebilir ama veritabanı çalışmıyor olabilir; WAN hattı açıkken LAN tarafında erişim kopmuş olabilir. Tek bayraklı sağlık modeli bu farkları yakalayamaz.

Birçok kurumda sağlık kontrolü ile DNS yanıtı arasındaki bağ manuel veya parçalıdır. İzleme sistemi alarm üretir, operasyon ekibi script çalıştırır, DNS kaydı elle değiştirilir ya da ayrı bir otomasyon devreye girer. Bu zincir hem geç tepki verir hem de kritik anlarda insan hatasına açıktır.

Karmaşık senaryolar daha da zordur. "DC1 internet erişimi var ve bakımda değilse aktif olsun; değilse DC2 uygulama sağlığı veya DC3 erişimi sağlamsa yedek kayıt dönsün" gibi koşullar çoğu zaman YAML, script ve manuel bağımlılıklarla yönetilir. Bu da GTM kararını anlaşılması zor bir operasyon labirentine çevirir.

Flap davranışı da gerçek bir risktir. Bir sağlık kontrolü anlık olarak başarısız olduğunda DNS'in hemen değişmesi, kullanıcı trafiğini gereksiz yere başka bölgeye taşıyabilir. Aynı şekilde kısa süreli başarı da problem tam çözülmeden trafiği geri alabilir. Bu yüzden ardışık başarı/başarısızlık eşiği ve durum koruma mantığı gerekir.

TR7'nin sağlık kontrolü senaryoları, veri merkezi, uygulama, veritabanı, bakım modu ve özel kontrolleri tek boolean karar katmanında birleştirerek DNS yanıtını gerçek servis sağlığına bağlar.

Yaklaşımımız

TR7, GTM sağlık kararını otomatik veri merkezi kontrolleri, manuel sağlık kontrolleri ve senaryo mantığıyla birlikte değerlendirir.

Otomatik ve manuel sağlık kontrolleri aynı senaryoda birleşir

Veri merkezi bazlı otomatik kontroller, kullanıcı tanımlı HTTP/HTTPS/Oracle kontrolleri ve ADC sağlık sonuçları aynı karar yapısında kullanılabilir. Bu yapı, altyapı ve uygulama sağlığını tek GTM kararına bağlar.

Boolean koşullar karmaşık kararları sadeleştirir

Senaryolar AND ve OR gruplarıyla oluşturulur. Bir sağlık kontrolü kimliği `!` ile ters çevrilerek bakım modu gibi negatif koşullar da kararın parçası yapılabilir.

Sağlık durumu değişince yalnız ilgili kayıtlar etkilenir

Sağlık kontrolü, senaryo ve DNS kaydı ilişkileri harita yapılarıyla takip edilir. Bir sağlık durumu değiştiğinde yalnızca etkilenen senaryolar ve kayıtlar yeniden değerlendirilir.

İçerik doğrulama uygulama seviyesini kontrol eder

HTTP ve HTTPS sağlık kontrolleri yalnızca portun açık olup olmadığını değil, status code ve içerik beklentisini de denetleyebilir. JSONata veya basit içerik kontrolüyle uygulamanın gerçekten sağlıklı cevap verdiği doğrulanır.

Yetenekler

TR7 Sağlık Kontrolleri Senaryoları, basit erişim kontrolünden çok katmanlı uygulama ve veri merkezi kararlarına kadar farklı GTM ihtiyaçlarını kapsar.

HTTP ve HTTPS sağlık kontrolleri status code ve içerik doğrular

TR7, HTTP ve HTTPS kontrollerinde method, URI, body, header, beklenen status code, sertifika doğrulama ve timeout gibi parametreleri destekler. Bu sayede kontrol yalnızca bağlantı kurulup kurulmadığını ölçmez. Uygulamanın doğru endpoint'ten doğru cevap verdiği de denetlenir. GTM kararı gerçek uygulama davranışına daha yakın hâle gelir.

JSONata içerik kontrolü API yanıtlarını anlamlı şekilde doğrular

JSON dönen sağlık endpoint'lerinde JSONata ifadesiyle belirli alanlar kontrol edilebilir. Örneğin `status = "ok"` veya benzeri bir ifade, uygulamanın yalnızca cevap verdiğini değil, beklenen sağlık durumunu döndürdüğünü gösterir. Response içeriği uygun formatta ayrıştırılır ve ifade bu yapı üzerinde değerlendirilir. Bu özellik JSON API tabanlı modern uygulamalar için daha güvenilir sağlık ölçümü sağlar.

Basit içerik kontrolü hızlı string eşleşmesi sağlar

Daha sade senaryolarda response body üzerinde belirli bir metnin bulunup bulunmadığı kontrol edilebilir. Bu yaklaşım, JSONata gibi ifade gerektirmeyen basit uygulama sağlık kontrolleri için yeterlidir. Operasyon ekibi, uygulama yanıtında beklenen bir kelimeyi veya sabit durumu doğrulayarak DNS kararını buna bağlayabilir. Böylece hızlı ve anlaşılır kontroller oluşturulur.

Oracle sağlık kontrolleri veritabanı seviyesini senaryoya ekler

Oracle kontrolü, bağlantı kurma, bekleme ve komut çalıştırma adımlarından oluşan senaryolarla yapılandırılabilir. Beklenen satır sayısı veya beklenen metin üzerinden sonuç değerlendirilebilir. Bu sayede DNS yanıtı yalnızca uygulama katmanına değil, veritabanı erişilebilirliğine de bağlanabilir. Kritik iş uygulamalarında "uygulama açık ama veri tabanı çalışmıyor" kör noktası azaltılır.

Her veri merkezi için beş otomatik sağlık kontrolü bulunur

TR7, veri merkezi bazında `wanAccess`, `lanAccess`, `access`, `internet` ve `maintenanceMode` kontrollerini kullanabilir. Bu kontroller, veri merkezinin farklı erişim ve operasyon durumlarını ayrı ayrı temsil eder. Bakım modu gibi durumlar pozitif sağlık işareti gibi değil, senaryoda negatif koşul olarak değerlendirilebilir. Böylece DNS kararı daha operasyonel gerçekliğe uygun verilir.

Boolean senaryolar AND, OR ve negatif koşulları destekler

Senaryolar condition group yapısıyla oluşturulur; grup içindeki koşullar AND mantığıyla, gruplar arası bağ ise OR veya AND ile değerlendirilebilir. Sağlık kontrolü kimliğinin sonuna `!` eklenerek koşulun tersi kullanılabilir. Örneğin `dcAccess AND NOT maintenanceMode` gibi yapı kurulabilir. Bu sayede script yazmadan karmaşık GTM kararları tasarlanabilir.

Ardışık başarı ve başarısızlık eşikleri flap riskini azaltır

Sağlık kontrollerinde `requiredSuccess` ve `requiredFailure` değerleri kullanılabilir. Varsayılan yaklaşım, durum değişimi için ardışık başarı veya başarısızlık sayısını dikkate alır. Bu yapı anlık paket kaybı, kısa süreli gecikme veya geçici servis dalgalanmasının DNS yanıtını hemen değiştirmesini engeller. GTM davranışı daha stabil hâle gelir.

Yerel sağlık durumu kalıcılığı restart sonrası süreklilik sağlar

Sağlık kontrollerinin durumları yerel dosyada saklanabilir ve sistem yeniden başladığında geri yüklenebilir. Bu sayede her restart sonrası tüm sağlık durumlarının sıfırdan ve kör şekilde öğrenilmesi gerekmez. Özellikle çok sayıda senaryo ve kayıt bulunan GTM ortamlarında bu süreklilik önemlidir. Operasyon ekipleri yeniden başlatma sonrası daha öngörülebilir davranış elde eder.

On bir sağlık kontrolü tipi GTM ve ADC koordinasyonunda kullanılabilir

TR7 ekosisteminde TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS ve Oracle sağlık kontrolleri kullanılabilir. GTM ve ADC sağlık sonuçlarının koordinasyonu, DNS kararını servis katmanındaki gerçek durumla ilişkilendirmeyi sağlar. Bu geniş tip desteği, yalnızca web uygulamaları için değil, çok protokollü kurumsal servisler için de sağlık modeli kurmayı mümkün kılar. Script benzeri TCP send-receive senaryoları da özel kontrol ihtiyaçlarında kullanılabilir.

Operasyonel derinlik

Sağlık kontrolü senaryolarının güvenilir çalışması için kimlik formatı, durum kalıcılığı, tetikleme sırası, master node kontrolü ve değişiklik yayılımı net yönetilir.

01

Sağlık kontrolü tipleri

Senaryo motoru static, dcCheck, http, https ve oracle gibi sağlık kontrolü tiplerini değerlendirebilir. Daha geniş GTM ve ADC sağlık kontrol ailesiyle birlikte çok protokollü servis durumları karar yapısına taşınır. Bu yapı, tek tip HTTP kontrolüne sıkışmayan servis mimarileri için önemlidir.

02

Otomatik kimlik formatı

Veri merkezi bazlı otomatik sağlık kontrolleri `auto||` formatıyla tanımlanır. Örneğin bir veri merkezinin internet durumu ayrı bir otomatik kontrol kimliğiyle temsil edilir. Bu standart format, senaryo ve kayıt ilişkilerinin daha düzenli izlenmesini sağlar.

03

Manuel sağlık kimlikleri

Kullanıcı tanımlı sağlık kontrolleri benzersiz kimliklerle oluşturulur. Bu kimlikler senaryo koşullarında doğrudan kullanılabilir. Böylece aynı HTTP, HTTPS veya Oracle kontrolü birden fazla GTM senaryosunda tekrar değerlendirilebilir.

04

Tetikleme akışı

Sağlık durumu değiştiğinde önce ilgili sağlık kontrolü durumu güncellenir. Ardından bağlı senaryolar yeniden değerlendirilir ve gerekirse dinamik konfigürasyon yeniden üretilir. Bu akış, değişikliğin DNS yanıtına kontrollü şekilde yansımasını sağlar.

05

Varsayılan senaryo durumları

`ALWAYS` ve `NEVER` gibi built-in senaryolar sabit karar üretmek için kullanılabilir. `ALWAYS` durumunda kayıt her zaman uygun kabul edilirken, `NEVER` durumunda devre dışı davranış elde edilir. Bu yapı test, geçici kapatma veya koşulsuz yönlendirme senaryolarında pratiklik sağlar.

06

Master node kontrolü

Tetikleyici aksiyonlar yalnızca GTM master node üzerinde çalıştırılır. Bu davranış, küme yapısında aynı aksiyonun birden fazla node tarafından tekrar tekrar çalıştırılmasını engeller. DR tetikleme, webhook veya bildirim gibi aksiyonlarda bu kontrol operasyonel güvenlik sağlar.

Hangi senaryolarda kullanılır

WAN ve LAN erişimine göre DNS kararı

Çok lokasyonlu kurumlar, veri merkezinin yalnızca tek bir erişim yönüne göre ayakta kabul edilmesini istemeyebilir. TR7, `wanAccess OR lanAccess` gibi senaryolarla farklı erişim yollarını aynı DNS kararında birleştirir.

Uygulama ve veritabanı birlikte sağlıklıysa yanıt ver

Kritik iş uygulamalarında veri merkezi erişimi tek başına yeterli değildir. TR7, `dcAccess AND appHC AND dbHC` benzeri senaryolarla uygulama ve Oracle veritabanı sağlığı birlikte olumluysa ilgili IP'yi DNS yanıtına alır.

Bakım modu açıkken trafiği dışarıda tut

Operasyon ekibi bakım sırasında veri merkezi teknik olarak erişilebilir olsa bile trafik almak istemeyebilir. TR7, `dcAccess AND NOT maintenanceMode` senaryosuyla bakımda olan lokasyonu DNS yanıtından çıkarabilir.

JSON API sağlığına göre GTM yönlendirmesi

Modern uygulamalar sağlık durumunu JSON endpoint üzerinden yayınlayabilir. TR7, HTTPS sağlık kontrolü ve JSONata ifadesiyle `status = "ok"` gibi kontroller yaparak DNS yanıtını gerçek uygulama sağlığına bağlar.

Sık sorulanlar

Sağlık kontrolü senaryosu ile basit up/down kontrolü arasındaki fark nedir?
Basit up/down kontrolü yalnızca veri merkezinin teknik olarak erişilebilir olup olmadığını bildirir. Sağlık kontrolü senaryosu ise HTTP/HTTPS içerik doğrulaması, JSONata ifadesi, Oracle bağlantı kontrolü ve veri merkezi bazlı otomatik kontrolleri AND/OR mantığıyla birleştirir. Sonuçta DNS yanıtı yalnızca altyapı erişilebilirliğine değil, gerçek servis sağlığına göre verilir.
Bakım modunu DNS kararına nasıl yansıtabilirim?
TR7'de her veri merkezi için `maintenanceMode` adında bir otomatik kontrol bulunur. Senaryo koşuluna bu kontrolü negatif olarak ekleyerek (`!` suffix) bakımda olan veri merkezini DNS yanıtından çıkarabilirsiniz. Teknik erişilebilirlik değişmeden trafik yönetimi operasyonel gerçekliğe göre yapılır.
Flap davranışını önlemek için ne yapılabilir?
TR7, sağlık kontrollerinde `requiredSuccess` ve `requiredFailure` parametrelerini destekler. Varsayılan eşik değeri 3 ardışık başarı veya başarısızlıktır. Bu yapı anlık paket kaybı veya geçici servis dalgalanmasının DNS yanıtını hemen değiştirmesini engeller ve GTM davranışını daha stabil hâle getirir.
Oracle veritabanı sağlığını GTM kararına nasıl bağlayabilirim?
Oracle sağlık kontrolü, bağlantı kurma, bekleme ve SQL komutu çalıştırma adımlarından oluşan bir senaryo dizisiyle yapılandırılır. Beklenen satır sayısı veya beklenen metin üzerinden sonuç değerlendirilir. Bu kontrol GTM senaryosuna dahil edilerek DNS yanıtı veritabanı erişilebilirliğiyle de ilişkilendirilebilir.
Aynı sağlık kontrolü birden fazla DNS kaydı için kullanılabilir mi?
Evet. Kullanıcı tanımlı sağlık kontrolleri benzersiz kimliklerle oluşturulur ve birden fazla GTM senaryosunda referans alınabilir. Senaryo ve kayıt ilişkileri harita yapılarıyla takip edildiğinden, bir sağlık durumu değiştiğinde yalnızca etkilenen senaryolar ve kayıtlar yeniden değerlendirilir; diğer kayıtlar gereksiz yere yeniden üretilmez.
GTM yeniden başlatılırsa sağlık kontrolü durumları sıfırlanır mı?
Hayır. Sağlık kontrolü durumları yerel dosyada saklanır ve sistem yeniden başladığında geri yüklenir. Bu sayede her restart sonrası tüm durumların sıfırdan öğrenilmesi gerekmez. Çok sayıda senaryo ve kayıt bulunan büyük GTM ortamlarında bu süreklilik operasyonel öngörülebilirliği artırır.

DNS kararınızı gerçek servis sağlığına bağlayın

HTTP, HTTPS, Oracle ve veri merkezi kontrollerini boolean senaryolarla birleştirin. Kendi ortamınızda canlı bir kurulumda gezdirelim.