NetScaler ServiceGroup DOWN: Nereden Başlamalı?

İlgili yazılar

NetScaler HA: Sync ≠ Command Propagation

1 hafta önce

NetScaler Persistence: SOURCEIP mi, COOKIEINSERT mi?

2 hafta önce

NetScaler SNIP Nedir? Backend Trafiğinde Neden Kritiktir?

3 hafta önce

NetScaler üzerinde bir ServiceGroup member’ın DOWN görünmesi, backend uygulama sunucusunun mutlaka kapalı olduğu anlamına gelmez.

Sorun; monitor, SNIP, routing, ARP veya firewall katmanında da olabilir.

Benim temel troubleshooting zincirim:

ServiceGroup → Member → Monitor → SNIP → Route → ARP → Firewall → Backend → Return Path

1. ServiceGroup ve Member Durumu

İlk kontrol:

show servicegroup SG_WEB -includemembers

Bu komut ServiceGroup özellikleriyle birlikte member’ları görmenizi sağlar. NetScaler GUI tarafında da DOWN member seçilip Monitor Details üzerinden durumun nedeni incelenebilir.

Burada özellikle:

Member State → Monitor → Probe Failure → Backend IP/Port

kontrol edilmelidir.

2. Monitor Gerçekten Neyi Kontrol Ediyor?

Sadece TCP monitor kullanıyorsanız:

TCP 443 OPEN → UP

sonucu alabilirsiniz.

Ancak uygulama gerçekte:

HTTP 503

döndürüyor olabilir.

Bu nedenle web uygulamalarında yalnızca port kontrolü yerine uygulamanın gerçek durumunu ölçen HTTP/HTTPS monitor kullanmak daha anlamlıdır.

Örneğin:

GET /health
→ 200 OK

NetScaler monitor’ları ServiceGroup’a bağlanarak member’ları periyodik olarak probe eder ve durumlarını buna göre günceller.

3. SNIP Doğru mu?

Sonraki kritik nokta backend iletişiminde kullanılan source IP’dir.

Kontrol:

show ns ip

NetScaler standart backend bağlantılarında ve birçok monitor probe’unda SNIP (Subnet IP) kullanır.

Bu nedenle:

SNIP doğru subnet’te mi? → Backend SNIP’e cevap verebiliyor mu? → Firewall SNIP’i izinli görüyor mu?

soruları kontrol edilmelidir.

Not: Bazı özel monitor türleri NSIP kullanabilir. Bu nedenle kullanılan monitor tipinin source-IP davranışı ayrıca doğrulanmalıdır.

4. Route ve ARP

Kontrol:

show route
show arp

Backend ağına doğru route bulunmalıdır.

Backend doğrudan bağlıysa backend’in MAC adresi; router üzerinden erişiliyorsa ilgili next-hop/gateway MAC adresi ARP tablosunda çözümlenmiş olmalıdır.

NetScaler troubleshooting dokümantasyonunda da show route ve show arp temel network kontrolleri arasında yer alır.

5. Firewall ve Return Path

Route doğru olsa bile backend firewall veya ara ACL şu trafiği engelliyor olabilir:

SNIP → Backend-IP:443

Aynı şekilde backend cevabı farklı gateway üzerinden dönüyorsa monitor response NetScaler’a ulaşmayabilir.

Bu nedenle yalnızca forward path değil:

NetScaler → Backend → NetScaler

dönüş yolu da doğrulanmalıdır.

Kritik Nokta

Service DOWN ≠ Server DOWN

Problemi şu katmanlarda aramak gerekir:

Monitor → SNIP → Route/ARP → Firewall → Backend → Return Path

Özellikle VIP çalışıyor ancak ServiceGroup member’ları DOWN görünüyorsa ilk hedef backend’i suçlamak değil, NetScaler’ın monitor probe’unu hangi source IP’den gönderdiğini ve cevabın geri dönüp dönmediğini doğrulamak olmalıdır.

İyi troubleshooting, sadece DOWN durumunu görmek değil, neden DOWN olduğunu katman katman izole etmektir.