MLAG tasarımları çoğu zaman “yüksek erişilebilirlik tamam” rahatlığı üretir. Fakat sahada en yorucu vakalardan biri, link down olmadan yaşanan sessiz paket kaybıdır. Port’lar up görünür, LACP normaldir, CPU sakindir; buna rağmen uygulama gecikmesi artar ve bazı akışlar bozulur.
Bu sınıf problemi çözmek için konfigürasyon okumak yetmez. Failover sırasında hangi sinyal neyi anlatıyor, hangi noktada veri kaybı oluşuyor, hangi aksiyon gerçekten güvenli sorularını birlikte cevaplamak gerekir.
1) Sessiz paket kaybı neden tehlikeli?
Çünkü klasik alarm seti çoğu zaman çalmaz:
- Interface up
- BGP/OSPF komşulukları ayakta
- LACP bundle halen formed
Ama gerçek kullanıcı etkisi oluşur:
- Uzun yaşayan TCP oturumları reset yer
- Retransmit artar
- Sadece belirli rack veya node grupları etkilenir
Bu yüzden MLAG sorunlarında “down değilse ağ değildir” yaklaşımı çok pahalıdır.
2) Nerede kırılır?
En sık gördüğüm nedenler:
- Peer-link üzerinde asimetrik yük veya buffer baskısı
- Hash davranışı nedeniyle belirli flow’ların aynı problemli üyeye düşmesi
- STP/ARP/MAC state senkronizasyonunda gecikme
- Yazılım güncellemesi sonrası vendor bug veya half-state
Failover anında bu problemler birkaç saniye sürse bile, üst katmanda kuyruklama ve retry fırtınası yaratabilir.
3) İzleme: hangi sinyaller gerçekten işe yarar?
Ben şu beşliyi birlikte izlemeyi tercih ediyorum:
- Peer-link throughput ve drop sayısı
- Member port başına queue/drop istatistikleri
- ARP/MAC move olayları
- Uygulama tarafında TCP retransmit ve connection reset oranı
- Failover anında sentetik probe kaybı
Bu sinyaller, “kablo koptu mu?” sorusundan çok daha değerlidir. Çünkü sessiz kayıp çoğu zaman tek bir sayaçta patlamaz; birkaç küçük sinyal bir araya geldiğinde görünür olur.
4) Test: failover’u gerçekten prova ediyor musunuz?
MLAG tasarımında güven ancak kontrollü testle oluşur. Önerdiğim tatbikat:
- Sentetik north-south ve east-west akış başlat
- Bir uplink’i kontrollü kes
- Peer-switch rol geçişini tetikle
- Ölçüm: kayıp, jitter, yeniden yakınsama süresi
Burada başarı ölçütü “trafik sonunda geri geldi” değildir. Asıl ölçüt:
- Kaç paket kayboldu?
- Hangi flow etkilendi?
- Üst katmanda retry dalgası oldu mu?
5) Runbook: incident anında nasıl ilerlerim?
- Kapsamı belirle
- Tüm servis mi etkilendi, belirli node/rack mi?
- Sinyali ayır
- Interface down yoksa queue/drop ve retransmit tarafına git
- Yol doğrulama
- Hangi flow hangi member üzerinden gidiyor?
- Geçici mitigasyon
- Problemli member’ı bundle dışına al
- Gerekirse belirli uplink’i drain et
- Kalıcı aksiyon
- Hash/policy revizyonu
- Yazılım sürümü/vendor advisory kontrolü
Bu sırayı bozup “önce reboot atalım” dediğiniz anda en değerli kanıtı yok edersiniz.
6) Tasarım kararları: blast radius nasıl küçülür?
- Her bundle için üyeleri gerçekten farklı failure domain’lere dağıt
- Peer-link kapasitesini yalnızca steady-state ile boyutlama
- Top-of-rack tatbikatını değişiklik sürecine bağla
- Uygulama ekipleriyle timeout ve retry bütçesini hizala
MLAG kararı tek başına ağ kararı değildir. Eğer üst katman istemcileri çok agresif retry yapıyorsa, birkaç saniyelik kayıp bile servis çapında büyür.
Sonuç
MLAG failover sorunlarında asıl maliyet, sinyalin zayıf olmasıdır. “Her şey up ama kullanıcı şikâyet ediyor” tipi olaylarda doğrulama katmanını genişletir, sentetik testleri düzenli yapar ve peer-link davranışını gerçek yük altında ölçerseniz sessiz paket kaybını görünür hale getirirsiniz. Ağ güvenilirliği, sadece redundant link sayısıyla değil; arıza anındaki gözlemlenebilirlikle ölçülür.