Yük dengeleme ve güvenlik katmanında yapılandırma değişikliği kaçınılmazdır. Yeni kurum servisi eklenir, WAAP kuralı güncellenir, sertifika yenilenir, sağlık kontrolü değiştirilir, rate-limit politikası sıkılaştırılır veya saldırı anında yeni engelleme kuralı yazılır. Eğer her değişiklik servis restart gerektiriyorsa, küçük operasyonlar bile kullanıcı oturumu kesintisine dönüşür.
Klasik restart modeli özellikle TCP ve uzun yaşayan bağlantılarda sorun üretir. Aktif kullanıcı oturumu kesilebilir, dosya aktarımı yarıda kalabilir, API istemcisi hata alabilir veya güvenlik duvarı değişikliği yüzünden anlık erişim problemi yaşanabilir. Bu yüzden ekipler gerekli değişiklikleri ertelemeye başlar; güvenlik ve operasyon çevikliği düşer.
WAAP ve güvenlik kural setlerinde bu problem daha kritiktir. Yeni bir saldırı pattern'i görülürken kural güncellemesini bakım penceresine bağlamak kabul edilebilir değildir. Aynı şekilde sertifika yenileme veya kurum servisi havuzu genişletme gibi rutin işler de aktif trafiği gereksiz yere etkilememelidir.
Doğru model, değişiklik türünü ayırmaktır. Kural, sertifika, health check, kurum servisi listesi ve güvenlik profili gibi runtime uygulanabilir değişiklikler soft reload ile devreye alınmalı; yalnızca servis yaratılışını etkileyen VIP, port, namespace, kaynak limiti veya servis tipi değişikliklerinde kontrollü restart yapılmalıdır.
TR7 Kesintisiz Yapılandırma Yenileme bu ayrımı yapar: pool bazlı soft reload, otomatik hard fallback, restart reason görünürlüğü ve paralel operasyon akışıyla yapılandırma değişikliklerini canlı trafik etkisini azaltarak uygular.
TR7, yapılandırma yenilemeyi tek tip restart işlemi olarak değil, değişiklik türüne göre karar veren katmanlı bir operasyon akışı olarak tasarlar.
Her pool kendi yönetim kanalı üzerinden reload alabilir. Bu model, bir pool'daki değişikliğin diğer pool'ları etkilemeden uygulanmasını sağlar.
TR7 önce canlı bağlantıları koruyan soft reload yolunu kullanır. Soft reload başarısız olursa veya değişiklik hard restart gerektiriyorsa sistem kontrollü restart yoluna geçer.
Config diff analizi hangi alanların reload, hangi alanların restart gerektirdiğini belirler. Operatör değişikliğin canlı yenilenebilir mi yoksa restart gerektiren creationConfig değişimi mi olduğunu önceden görebilir.
Load balancing ve log container işlemleri bağımsız ise paralel çalıştırılabilir. Böylece pool düzenleme süresi gereksiz seri beklemelerle uzamaz.
Kesintisiz Yapılandırma Yenileme, pool bazlı reload, değişiklik türü analizi, fallback, bağlantı drain ve paralel operasyonları aynı yönetim akışında birleştirir.
Soft reload, uygun değişikliklerde yeni yapılandırmayı devreye alırken mevcut bağlantıların doğal şekilde tamamlanmasına izin verir. Eski worker drain modunda kalır ve aktif oturumlar bitene kadar görevini sürdürür. Yeni bağlantılar güncel config ile karşılanır. Bu yaklaşım kural ve sertifika değişikliklerini bakım penceresine bağlama ihtiyacını azaltır.
TR7, varsayılan olarak soft reload yolunu tercih eder. Soft reload sırasında hata alınırsa sistem hard restart fallback ile servisi toparlar. Bu model operatöre tek bir güvenli akış sunar: mümkünse kesintisiz yenile, gerekirse kontrollü restart yap. Böylece başarısız reload durumları yarıda kalmış belirsiz konfigürasyona dönüşmez.
Bazı değişiklikler canlı reload ile uygulanamaz çünkü servis yaratılış parametrelerini değiştirir. Servis tipi, CPU limiti, bellek limiti, VIP, port, network namespace, image veya binary sürümü gibi alanlar hard restart gerektirir. Bu durumlarda forceHard davranışıyla restart açık ve bilinçli şekilde uygulanır. Operatör değişikliğin etkisini önceden planlayabilir.
Her config alanı için değişikliğin neden reload veya restart gerektirdiği restartReasons listesinde tutulabilir. Bu görünürlük operasyon ekibinin "bu değişiklik neden restart istiyor?" sorusuna cevap verir. Özellikle change management ve bakım onayı süreçlerinde karar daha net alınır. Değişiklik etkisi kara kutu olmaktan çıkar.
Her pool kendi runtime yapısı ve yönetim kanalıyla ele alınır. Bir pool'da WAAP profili, sertifika veya kurum servisi listesi değişirken başka bir pool aynı şekilde çalışmaya devam eder. Bu izolasyon büyük platformlarda değişiklik riskini daraltır. Operasyon ekibi tüm cihazı değil, yalnızca ilgili servisi yeniler.
Log transport veya log container yapılandırmaları load balancing container'ından ayrı ele alınabilir. Böylece log tarafındaki değişiklikler trafik yönlendirme katmanını gereksiz etkilemez. Aynı şekilde trafik tarafındaki reload, log hattını zorunlu olarak kesmez. Bu ayrım platform operasyonunda daha kontrollü değişiklik sağlar.
Bir değişiklik hem load balancing hem log tarafını etkiliyorsa uygun işlemler paralel yürütülebilir. Seri bekleme azaltılır ve toplam job süresi kısalır. Özellikle büyük konfigürasyonlarda veya birden fazla alt bileşenin etkilendiği güncellemelerde bu önemlidir. Operasyon penceresi daha verimli kullanılır.
Soft reload uygulandığında eski çalışma birimi hemen öldürülmez; mevcut bağlantıların bitmesine izin verilir. Yeni trafik güncel konfigürasyona yönelirken eski trafik doğal kapanış sürecini tamamlar. Bu, uzun yaşayan TCP bağlantıları ve kullanıcı oturumları için kritik önemdedir. Amaç değişiklik anında TCP reset veya ani kopma üretmemektir.
Pool istatistiklerinde belirli hata eşiği aşılırsa otomatik reload tetiklenebilir. Bu davranış geçici runtime sorunlarının manuel müdahale beklemeden toparlanmasına yardımcı olur. Operatör için bu, servis sağlığında otomatik iyileştirme sinyali anlamına gelir. Yine de tekrar eden reload nedenleri izleme ve kök neden analiziyle değerlendirilmelidir.
WAAP profil, whitelist, kural seti ve Lua script güncellemeleri canlı yenilenebilir değişiklikler arasında ele alınabilir. Bu, saldırı anında güvenlik politikasını hızlı güncellemeyi ve uygulama trafiğini kesmeden yeni mantığı devreye almayı sağlar. Kural seti değişimleri tüm platform restart'ına bağlanmaz. Bu yaklaşım güvenlik operasyonunun çevikliğini artırır.
Hot config reload; pool yönetim yolu, komut davranışı, zaman aşımı, retry mantığı ve hangi alanların soft/hard değişiklik sayıldığıyla birlikte işletilir.
Her pool için ayrı yönetim soketi bulunur. Reload komutu ilgili pool'un kendi yönetim kanalına gönderilir. Bu yapı pool bazlı bağımsız yenileme davranışının temelidir.
Soft reload, yönetim kanalına gönderilen reload komutu ile tetiklenir. Komut başarılı olursa yeni config devreye alınır ve mevcut bağlantılar drain davranışıyla korunur. Başarısızlık durumunda smart reload hard restart fallback uygulayabilir.
Pool container isimleri poolId ile ilişkilendirilmiş düzenli bir pattern kullanır. Bu yapı reload, restart, log temizleme ve sağlık kontrol işlemlerinin doğru container üzerinde uygulanmasını sağlar. Operasyon otomasyonu bu deterministik isimlendirmeden yararlanır.
Varsayılan modelde soft reload bir kez denenir. Exception veya reload başarısızlığı görülürse hard restart yoluna geçilir. Bu yaklaşım tekrar tekrar başarısız reload deneyerek operasyon süresini uzatmaz.
Pool düzenleme işi için toplam zaman aşımı 5 dakika seviyesinde tutulabilir. Bu süre log temizleme, reload ve gerekirse restart işlemlerinin tamamını kapsar. Uzayan işler operasyon ekranında belirsiz biçimde açık kalmaz.
Varsayılan waitBefore ve waitAfter değerleri optimize edilerek 0 olarak çalıştırılabilir. Böylece gereksiz sabit beklemeler kaldırılır. Gerçek bekleme, işlemin durumuna ve sistem cevabına göre belirlenir.
Yeni WAAP kural seti veya OWASP tabanlı güncelleme soft reload kapsamına alınabilir. Mevcut kullanıcı oturumları korunurken yeni güvenlik mantığı yeni isteklerde devreye girer. Saldırı anında bakım penceresi beklenmez.
Süresi yaklaşan sertifika güncellendiğinde lbCertificates değişikliği soft reload ile uygulanabilir. Yeni TLS bağlantıları güncel sertifikayı kullanır. Mevcut bağlantılar drain davranışıyla doğal akışında kapanır.
Yeni kurum servisi node'ları lbBackends listesine eklenebilir. Soft reload sonrası yeni bağlantılar genişletilmiş havuzdan yararlanır. Diğer pool'lar ve mevcut bağlantılar etkilenmeden kapasite artırılır.
Yeni DDoS veya rate-limit profili canlı config değişikliği olarak uygulanabilir. Politika kısa sürede yeni isteklere etki eder. Operasyon ekibi saldırıya restart kaynaklı ek kesinti üretmeden cevap verir.
WAAP kuralı, sertifika, kurum servisi havuzu ve rate-limit politikasını aktif oturumları kesmeden uygulayın. Kendi ortamınızda canlı bir kurulumla gezdirelim.