Redis Sentinel'ın Temel Mimarisi
Redis Sentinel, Redis için yüksek kullanılabilirlik (high availability) çözümü sağlayan dağıtılmış bir sistemdir. Temel işlevi, bir birincil (master) Redis sunucusu ile bir veya daha fazla ikincil (replica) sunucudan oluşan bir kümenin sürekli izlenmesi, otomatik failover yönetimi ve konfigürasyon sağlayıcılığıdır. Sentinel'in kendisi, kendi aralarında iletişim kuran ve çoğunluk oluşturan birden fazla Sentinel işleminden (genellikle tek sayıda) oluşan bir kararlı ve hataya dayanıklı bir katmandır.
Her Sentinel işlemi, ilgili olduğu birincil sunucuyu, onun ikincillerini ve diğer Sentinel'leri izler. Bu izleme, periyodik PING, INFO ve PUBLISH komutları aracılığıyla gerçekleştirilir. Sentinel, bir birincil sunucunun erişilemez hale geldiğini tespit ettiğinde, süreç objektif ve subjektif kesinti olarak iki aşamalıdır. Diğer Sentinel'lerle konsensüs sağladıktan sonra otomatik failover başlatılır.
Sentinel mimarisinin en kritik yönlerinden biri, çoğunluk (quorum) kavramıdır. Failover gibi önemli kararlar, tek bir Sentinel tarafından değil, çoğunluğun oybirliği ile alınır. Bu, yanlış pozitif tespitlerden kaynaklanan gereksiz failover'ları önlemek ve sistemin dayanıklılığını artırmak için hayati önem taşır. Sentinel kümesinin boyutu genellikle 3 veya 5 gibi tek sayıda seçilerek çoğunluk kararının net bir şekilde alınması sağlanır.
| Bileşen | Rol | Failover'daki Etkisi |
|---|---|---|
| Birincil Sunucu (Master) | Yazma işlemlerini kabul eder, veriyi ikincillere replike eder. | Başarısız olduğunda failover hedefidir. |
| İkincil Sunucu (Replica) | Birincilden veriyi çoğaltır, okuma işlemlerini yük dağılımı için kullanılabilir. | Birincil seçimi için potansiyel adaydır. |
| Sentinel İşlemleri | Küme izleme, hata tespiti, lider seçimi ve konfigürasyon yayını. | Failover sürecini başlatır, yönetir ve sonlandırır. |
Sentinel, bulduğu en uygun ikincil sunucuyu yeni birincil olarak seçer. Seçim kriterleri arasında replikasyon gecikmesinin düşüklüğü, öncelik değeri ve işlem kimliği (run ID) gibi faktörler bulunur. Bu algoritmik yaklaşım, insan müdahalesini en aza indirgeyerek hizmet kesintisi süresini minimize eder. Ayrıca Sentinel, yeni konfigürasyonu istemcilere otomatik olarak yayınlayarak, istemcilerin yeni birincil sunucuya yönlendirilmesini sağlar.
Sentinel ve Replikasyon
Sentinel'in failover mekanizması, Redis'in asenkron replikasyon özelliğinin üzerine inşa edilmiştir. Başarısız bir birincil sunucudan sonra, seçilen yeni birincil, en güncel veri setine sahip olan ikincil olmalıdır. Sentinel, repl-offset değerlerini sürekli olarak karşılaştırarak hangi ikincilin en çok ilerlemiş olduğunu belirler. Bu durum, asenkron replikasyonun doğasında bulunan veri kaybı riskini yönetmek için kritik bir adımdır.
Failover sonrasında, eski birincil sunucu (eğer tekrar çevrimiçi olursa) yeni bir ikincil olarak kümeye yeniden katılır. Sentinel bu yeniden yapılandırmayı otomatik olarak yönetir ve eski birincili, yeni birinclin bir replikası olacak şekilde yapılandırır. Bu süreç, "eski efendi" (old master) sorununu çözer ve sistemin kendini iyileştirmesine olanak tanır. Bu noktada, replikasyon bağlantısının doğru kurulması ve veri tutarlılığının sağlanması Sentinel'in gözetimi altındadır.
| Replikasyon Özelliği | Sentinel ile Entegrasyonu | Failover Sürecindeki Önemi |
|---|---|---|
| Asenkron Replikasyon | Sentinel, replikasyon gecikmesini izler ve uygun yeni master'ı seçer. | En az veri kaybı için en güncel replikayı seçmeyi sağlar. |
| Çoklu İkincil (Replica) Desteği | Birden fazla failover adayı sağlar, yedekliliği artırır. | Master seçiminde esneklik ve güvenilirlik kazandırır. |
| READONLY Komutu | Sentinel, yeni master seçimi sonrası diğer replikalara READONLY komutunu göndermez, yapılandırma dosyasını günceller. | Küme durumunun tutarlı şekilde güncellenmesini sağlar. |
Sentinel, replikasyon topolojisindeki değişiklikleri yalnızca yönetmekle kalmaz, aynı zamanda bu değişiklikleri izleyen istemcilere de bildirir. İstemciler, Sentinel'lere abone olarak (SUBSCRIBE komutu ile) "switch-master" olay mesajını dinleyebilirler. Bu mesaj, birincil sunucunun IP ve port bilgisinin değiştiğini bildirir, böylece istemci bağlantılarını dinamik olarak güncelleyebilir. Bu mekanizma, uygulama katmanında herhangi bir statik yapılandırma değişikliği gerektirmeden sürekli hizmet sağlar.
Replikasyon gecikmesinin yüksek olması veya ağ bölünmeleri (network partition), Sentinel'in karar alma sürecini doğrudan etkiler. Sentinel, bu tür durumlarda, çoğunluk oluşturamadığı sürece failover başlatmaz, bu da split-brain senaryolarını engellemeye yönelik koruyucu bir tasarımdır. Ancak, bu durum aynı zamanda, birincil sunucunun gerçekten başarısız olduğu ancak Sentinel çoğunluğunun buna ikna olmadığı durumlarda hizmet kesintisi riskini de beraberinde getirir.
Failover Sürecinin Adımları
Redis Sentinel failover süreci, basit bir anahtar değişiminden ziyade, birden fazla aşamadan oluşan ve çoğunluk konsensüsü gerektiren karmaşık bir dağıtık algoritmadır. Süreç, bir Sentinel'in objektif kesinti (SDOWN - Subjectively Down) durumunu ilan etmesiyle başlar. Bu, tek bir Sentinel'in belirli bir süre (is-master-down-after-milliseconds yapılandırması) boyunca birincil veya ikincil sunucudan yanıt alamaması durumudur. Ancak bu, failover için yeterli değildir.
İkinci ve daha kritik aşama, objektif kesinti (ODOWN - Objectively Down) durumunun oluşmasıdır. Başlangıçtaki Sentinel, diğer Sentinel'lere, ilgili birincil sunucunun SDOWN durumunda olduğunu bildirir. Eğer yapılandırılmış quorum sayısı kadar Sentinel, belirli bir süre içinde aynı fikre varırsa, ODOWN durumu ilan edilir. Bu, failover için resmi bir tetikleyicidir ve sistem, çoğunluğun birincil sunucunun erişilemez olduğu konusunda hemfikir olduğunu garanti eder.
ODOWN ilanından sonra, Sentinel'ler arasında bir lider seçim süreci (Raft algoritması benzeri) başlatılır. Bu süreçte, ODOWN'ı tespit eden ilk Sentinel, diğerlerinden failover için yetki (leadership) ister. Yeterli çoğunluktan onay alan Sentinel, failover lideri olarak seçilir ve süreci yönetme sorumluluğunu üstlenir. Bu liderlik mekanizması, aynı anda birden fazla failover girişimini önleyerek sistemin kararlılığını korur.
Failover lideri Sentinel, mevcut ikincil sunucular arasından yeni bir birincil adayı seçer. Seçim algoritması, sunucunun bağlantısının kesilme süresini, öncelik (priority) değerini, replikasyon ofsetini ve benzersiz işlem kimliği (run ID) gibi faktörleri değerlendirir. En düşük öncelik değerine sahip, en yüksek replikasyon ofsetine sahip ve bağlantısı en kısa süre önce kopmuş olan ikincil tercih edilir. Bu, mümkün olan en az veri kaybı ile en kararlı sunucunun yükseltilmesini hedefler.
Yeni birincil belirlendikten sonra, Sentinel lideri bu sunucuya SLAVEOF NO ONE komutunu göndererek onu bağımsız bir birincil haline getirir. Ardından, kısa bir bekleme süresinden sonra (promotion delay), diğer tüm çalışan ikincil sunuculara, yeni birincili replike etmeleri için SLAVEOF komutunu gönderir. Bu adım, replikasyon topolojisinin yeniden kurulmasını sağlar. Son olarak, eski birincil (eğer geri dönerse) yeni bir ikincil olarak yapılandırılır.
Failover'ın son ve istemciler için en görünür aşaması, konfigürasyon yayınıdır. Lider Sentinel, başarılı failover'ı, yeni birincilin IP ve port bilgisiyle birlikte diğer tüm Sentinel'lere bildirir. Ayrıca, __sentinel__:hello kanalına bir "switch-master" olayı yayınlar. Bu kanala abone olan istemciler (Sentinel istemci kitaplıkları aracılığıyla), bağlantılarını anında yeni birincil sunucuya yönlendirerek uygulama katmanında kesintisiz hizmet sağlarlar.
Yapılandırma ve Örnek Senaryolar
Redis Sentinel'in doğru çalışması, yapılandırma dosyalarının (sentinel.conf) titizlikle ayarlanmasına bağlıdır. Minimum bir yapılandırma, izlenecek birincili tanımlayan `sentinel monitor
Kritik parametrelerden biri `sentinel down-after-milliseconds
Sentinel, çoklu veri merkezi (multi-DC) senaryolarında dikkatli bir şekilde konumlandırılmalıdır. İdeal olarak, Sentinel işlemleri, izledikleri Redis sunucularıyla aynı veri merkezinde (availability zone) çalıştırılmalıdır. Aksi takdirde, iki veri merkezi arasındaki bir ağ bölünmesi (split-brain) durumunda, Sentinel'ler birincil sunucuyu kesintide ilan edip, kendi lokallerindeki bir ikincili yeni birincil yaparak veri çatallanmasına (data fork) neden olabilirler. Bu riski azaltmak için, çoğunluk oluştracak şekilde Sentinel'ler birincil veri merkezinde yoğunlaştırılabilir veya `sentinel parallel-syncs` gibi parametrelerle replikasyon yükü kontrol edilir.
| Senaryo | Yapılandırma Odak Noktası | Beklenen Sentinel Davranışı |
|---|---|---|
| Planlı Bakım (Birincil Yeniden Başlatma) | `sentinel failover-timeout`'un yeterince yüksek olması. | Eski birincil geri geldiğinde, yeni birincilin ikincili olarak yeniden katılır. Gereksiz ikinci bir failover tetiklenmez. |
| Ağ Gecikmesi veya Paket Kaybı | `down-after-milliseconds` değerinin ağ koşullarına göre optimize edilmesi. | Geçici ağ sorunlarında SDOWN'a girer ancak quorum sağlanamadığı için ODOWN ve failover gerçekleşmez. |
| Çoğunluk Kaybı (Majority Loss) | Sentinel sayısı (örn. 3) ve dağılımı. | Kalan Sentinel'ler çoğunluk kuramadığı için hiçbir failover başlatılamaz. Küme yazmaya kapanır (read-only), veri bütünlüğü korunur. |
| İkincil Sunucu Arızaları | `sentinel parallel-syncs` ile yeni master'a eşzamanlı bağlanacak replica sayısı. | Failover başarılı olur, sağlıklı kalan ikinciller yeni birinciyle senkronize olur. Arızalı ikinciller SDOWN olarak işaretlenir. |
Sentinel'in güvenlik yapılandırması da akademik bir inceleme gerektirir. `sentinel auth-pass` direktifi kullanılarak, Sentinel'in Redis sunucularına kimlik doğrulaması yapması sağlanabilir. Daha da önemlisi, Sentinel'ler arasındaki iletişimin güvenliği, şifrelenmemiş TCP bağlantıları üzerinden gerçekleştiği için ayrı bir değerlendirme konusudur. Üretim ortamlarında, Sentinel trafiğinin VPN tünelleri veya özel ağlar içinde izole edilmesi, yetkisiz erişim veya kötü niyetli müdahaleleri önlemek adına esastır. Ayrıca, her Sentinel düğümünün sistem saatlerinin (NTP ile) senkronize olması, timeout tabanlı karar alma mekanizmalarının doğruluğu için kritiktir.
Senaryo bazlı testler, Sentinel konfigürasyonunun geçerliliğini kanıtlamanın en güvenilir yoludur. `DEBUG SLEEP`, `CLUSTER FAILOVER` gibi komutlar veya ağ arayüzlerini kapatma simülasyonları kullanılarak, failover süresinin (RTO - Recovery Time Objective) ve olası veri kaybı penceresinin (RPO - Recovery Point Objective) ölçülmesi gerekir. Bu testler, `sentinel.conf` dosyasındaki timeout değerlerinin, belirlenen servis seviyesi hedeflerine (SLA) uygun olarak ayarlandığından ve doğrulandığından emin olmayı sağlar.
Gelişmiş bir kullanım senaryosu, farklı uygulama hizmetleri için birden fazla bağımsız Redis birincil kümesinin (shard) aynı Sentinel kümesi tarafından yönetilmesidir. Her bir master-group için ayrı yapılandırma blokları tanımlanarak, Sentinel kaynakları verimli bir şekilde konsolide edilebilir. Ancak, bu durumda, tek bir Sentinel hatasının veya aşırı yüklenmesinin birden fazla hizmeti aynı anda etkileme potansiyeli dikkatle değerlendirilmelidir. Kaynak izolasyonu gerektiren kritik iş yükleri için ayrı Sentinel kümeleri önerilir.
Bulut ortamlarındaki dinamik IP adresleri, Sentinel konfigürasyonunda bir zorluk teşkil eder. Sentinel, başlangıç konfigürasyonunda belirtilen IP'leri, INFO komutu aracılığıyla Redis sunucularından aldığı gerçek IP'lerle sürekli olarak günceller. Ancak, bu mekanizmanın güvenilir çalışması için sunucuların belirli bir stable hostname veya servis bulma (service discovery) mekanizmasına sahip olması tercih edilir. Aksi takdirde, geçici ağ sorunları sonrasında yanlış IP eşleştirmeleri ortaya çıkabilir ve küme durumu bozulabilir.
Avantajlar ve Sınırlamalar
Redis Sentinel'in birincil avantajı, otomatik failover sağlayarak hizmet sürekliliğini artırmasıdır. Bu, sistem yöneticisi müdahalesi gerektirmeden, saniyeler mertebesinde (tipik olarak 10-30 saniye içinde) yeni bir birincil sunucunun devreye alınmasını mümkün kılar. İnsan hatası olasılığını ortadan kaldırarak ve kesinti süresini (downtime) minimize ederek, özellikle 7/24 hizmet veren kritik uygulamalar için operasyonel yükü önemli ölçüde azaltır. Ayrıca, merkezi bir konfigürasyon sağlayıcısı olarak hareket ederek, istemcilerin dinamik olarak güncellenmesini sağlar.
Bir diğer önemli avantaj, çoklu ikincil (replica) desteğinin getirdiği okuma ölçeklendirmesi ile failover adaylığının bir arada sunulmasıdır. Uygulamalar, yük dağılımı için ikincil sunucuları kullanabilirken, aynı sunucular otomatik kurtarma için hazır bekler. Sentinel'in dağıtık ve çoğunluk temelli mimarisi, tek nokta arızası (SPOF) riskini büyük ölçüde ortadan kaldırır. Tek bir veya hatta azınlıkta kalan Sentinel'lerin arızalanması, kümenin izleme ve failover yeteneğini durdurmaz.
Ancak, Sentinel'in belirgin sınırlamaları mevcuttur. En kritik sınırlama, tek bir yazma noktası (single point of write) modelini sürdürmesidir. Failover sadece yazma yetkisini başka bir düğüme devreder, ancak yazma iş yükünü birden fazla düğüme dağıtmaz (sharding). Bu, tek bir birincilin kapasitsini aşan yazma yoğun iş yükleri için Sentinel'in yetersiz kalması anlamına gelir. Bu durumda, veriyi birden fazla birincil gruba bölen Redis Cluster çözümü daha uygundur.
Sentinel, çapraz bölge (cross-region) yüksek kullanılabilirlik için ideal bir çözüm değildir. Asenkron replikasyon ve çoğunluk karar alma mekanizması, coğrafi olarak dağıtılmış düğümlerde ağ gecikmeleri ve bölünmeler nedeniyle sorunlu hale gelir. Uzak bir veri merkezindeki bir ikincilin yeni birincil seçilmesi, uygulama için kabul edilemez gecikmelere yol açabilir. Ayrıca, ağ bölünmelerinde "bölünmüş beyin" riski, düşük gecikmeli yerel ağlara kıyasla çok daha yüksektir.
Veri kaybı riski, asenkron replikasyon kullanan her sistemde olduğu gibi Sentinel için de geçerlidir. Failover anında, henüz eski birincilden yeni birincile replike edilmemiş veriler kaybolabilir. Replikasyon gecikmesi (replication lag) ne kadar yüksekse, potansiyel veri kaybı penceresi de o kadar büyük olur. Sentinel, veri tutarlılığını garanti etmekten ziyade kullanılabilirliği (availability) önceliklendiren CAP teoremindeki "AP" (Availability, Partition Tolerance) sistemine daha yakındır. Bu, belirli iş senaryoları için dikkatle değerlendirilmelidir.
Konfigürasyon ve operasyonel karmaşıklık, bir diğer pratik sınırlamadır. Doğru çalışması için quorum, timeout'lar ve ağ topolojisi gibi parametrelerin dikkatli bir şekilde ayarlanması gerekir. Yetersiz sayıda Sentinel veya yanlış dağıtılmış quorum, kümenin "failover yapamaz" bir duruma düşmesine neden olabilir. Ayrıca, Sentinel'i izleyen ve yöneten bir süreç olmadığından, Sentinel işlemlerinin kendilerinin de izlenmesi ve bir arıza durumunda yeniden başlatılması için ek operasyonel prosedürler gereklidir.
Son olarak, Sentinel'in ölçeklendirme sınırları vardır. Çok fazla sayıda ikincil sunucu (örneğin, 50+), failover sırasında lider Sentinel'den gelen yoğun `SLAVEOF` komutu trafiğine neden olabilir ve `parallel-syncs` parametresi ile kısıtlansa bile, tüm kümenin senkronizasyon süresini uzatabilir. Benzer şekilde, aynı Sentinel kümesinin izlediği birincil grup (shard) sayısı arttıkça, her bir Sentinel'in işlem yükü ve ağ tüketimi artar, bu da karar alma sürelerini yavaşlatabilir.