Aruba Controller Cluster ISOLATED Node: Analiz ve Recovery Adımları

01 / PROBLEM

Problem

ArubaOS 8 tabanlı bir controller cluster'da üyelerden biri ISOLATED durumuna düştüğünde yalnızca ilgili controller değil, AP ve istemci yedekliliği de etkilenebilir.

Örnek sağlıklı durum:

Controller-A  → CONNECTED (Leader)
Controller-B  → CONNECTED (Member)

Problemli bir durumda ise aşağıdakine benzer bir görünüm oluşabilir:

Controller-A  → CONNECTED
Controller-B  → ISOLATED

veya peer iletişimi kurulamadığında node kendi lokal görünümünde:

ISOLATED (Leader)

olarak da görülebilir.

Buradaki önemli nokta şudur:

ISOLATED bir node'u düzeltmeye çalışırken ilk adım reboot etmek değil, node'un neden cluster peer'lerinden ayrıldığını belirlemektir.

02 / CLUSTER MIMARISI KISACA NASIL ÇALIŞIR?

Cluster Mimarisi Kısaca Nasıl Çalışır?

ArubaOS 8 mimarisinde Mobility Conductor merkezi yönetim ve konfigürasyon katmanıdır. AP'leri sonlandıran Managed Device controller'lar ise cluster üyelerini oluşturur.

Basitleştirilmiş görünüm:

              Mobility Conductor
                     |
          +----------+----------+
          |                     |
          v                     v
    Controller-A           Controller-B
        Leader                Member
          |                     |
          +-------- Cluster ----+
                    |
                 AP / Client

Cluster içindeki node'lardan biri leader rolünü üstlenirken diğer sağlıklı üyeler Member olarak görünür.

03 / ISOLATED NE ANLAMA GELIR?

ISOLATED Ne Anlama Gelir?

ISOLATED, ilgili controller'ın cluster'ın geri kalanıyla beklenen üyelik ve peer iletişimini sürdüremediğini gösteren önemli bir durumdur.

Bu durum tek başına kesin root cause'u söylemez.

Olası inceleme alanları:

Cluster Membership
       ↓
Peer Communication
       ↓
Secure Cluster Communication / Heartbeat
       ↓
Management & Config Sync
       ↓
Node / Cluster State

Örneğin peer tarafında aşağıdaki gibi ara durumlar görülebilir:

DISCONNECTED
SECURE-TUNNEL-NEGOTIATING
ISOLATED

Bu nedenle yalnızca ISOLATED kelimesine bakmak yerine iki controller'ın da cluster görünümü karşılaştırılmalıdır.

04 / 1. ÖNCE CLUSTER MEMBERSHIP'I KONTROL ET

1. Önce Cluster Membership'i Kontrol Et

İlk kontrol için en değerli komutlardan biri:

show lc-cluster group-membership

Bu çıktı üzerinden özellikle şu alanlara bakılır:

• Self node durumu
• Peer node durumu
• Leader / Member rolü
• Peer bağlantı durumu
• Heartbeat bilgileri mevcutsa son cevap süresi
• Cluster profilinin etkin olup olmadığı

Sağlıklı örnek mantığı:

self  <CONTROLLER_A>  CONNECTED (Leader)
peer  <CONTROLLER_B>  CONNECTED (Member)

Problemli örnek mantığı:

self  <CONTROLLER_A>  ISOLATED (Leader)
peer  <CONTROLLER_B>  DISCONNECTED

veya:

peer  <CONTROLLER_B>  SECURE-TUNNEL-NEGOTIATING

05 / 2. CONFIG ID VE CONFIGURATION STATE'I KONTROL ET

2. Config ID ve Configuration State'i Kontrol Et

Cluster problemi yaşanırken controller'ların yönetim katmanından doğru konfigürasyonu alıp almadığı da kontrol edilmelidir.

Mobility Conductor üzerinde:

show switches

çıktısı önemli bir referanstır.

Özellikle şu sütunlara bakılır:

Status
Configuration State
Config Sync Time
Config ID

Sağlıklı bir managed device için beklenen mantık:

Status              → up
Configuration State → UPDATE SUCCESSFUL
Config ID            → beklenen güncel değer

Sadece Config ID'ye bakmak yerine Configuration State ile birlikte değerlendirmek daha doğru olur.

Örnek kontrol:

Bu tabloda config sync sağlıklı olduğu halde cluster state bozuksa inceleme alanı peer/cluster iletişimine doğru daralır.

06 / 3. PEER COMMUNICATION KONTROLÜ

3. Peer Communication Kontrolü

Cluster üyeleri birbirini sağlıklı şekilde göremiyorsa önce altyapı iletişimi doğrulanmalıdır.

Kontrol sırası:

Controller-A
    |
    |  IP Reachability
    v
Controller-B
    |
    +-- Routing
    +-- VLAN / L2-L3 Path
    +-- ACL / Firewall
    +-- MTU
    +-- Cluster secure communication

Burada amaç yalnızca ping çalışıyor sonucuna ulaşmak değildir.

ICMP erişimi olması:

Ping → SUCCESS

cluster'ın kullandığı tüm iletişim mekanizmalarının da sağlıklı olduğu anlamına gelmez.

show lc-cluster group-membership çıktısında peer'in sürekli:

SECURE-TUNNEL-NEGOTIATING

gibi bir durumda kalması, temel IP erişiminin ötesinde cluster peer iletişiminin ayrıca incelenmesi gerektiğini gösterir.

07 / 4. CONFIG / DATABASE SYNC TARAFINI AYRI DEĞERLENDIR

4. Config / Database Sync Tarafını Ayrı Değerlendir

Cluster üyeliği ile yönetim konfigürasyon senkronizasyonu birbirine bağlı görünse de troubleshooting sırasında ayrı ayrı doğrulanmalıdır.

Basit yaklaşım:

Mobility Conductor
       |
       +-- Controller-A config güncel mi?
       |
       +-- Controller-B config güncel mi?
       |
       v
Cluster üyeleri birbirleriyle sağlıklı mı?

Eğer show switches tarafında:

• Config ID beklenenden farklıysa,
• Configuration State başarılı değilse,
• Managed Device yönetim katmanıyla sağlıklı senkronize değilse,

önce bu problem çözülmelidir.

Config senkronizasyonu sağlıklı olduğu halde node hala ISOLATED ise odak peer communication ve cluster state tarafına kaydırılır.

08 / 5. LEADER / MEMBER DURUMUNU İKI TARAFTAN KARŞILAŞTIR

5. Leader / Member Durumunu İki Taraftan Karşılaştır

Sorunlu cluster'larda yalnızca tek controller'dan çıktı almak yanıltıcı olabilir.

Her iki node üzerinde de:

show lc-cluster group-membership

çalıştırılarak görünüm karşılaştırılmalıdır.

Örneğin:

Controller-A'nın görünümü:
A → ISOLATED (Leader)
B → DISCONNECTED

Controller-B'nin görünümü:
A → DISCONNECTED
B → ISOLATED (Leader)

Bu yapı, iki node'un da birbirini cluster peer'i olarak sağlıklı şekilde göremediğini düşündürür.

Buna karşılık sağlıklı cluster'da ortak görünüm tutarlıdır:

Controller-A → CONNECTED (Leader)
Controller-B → CONNECTED (Member)

09 / 6. RECOVERY'YE HEMEN BAŞLAMADAN ÖNCE

6. Recovery'ye Hemen Başlamadan Önce

Recovery işlemlerinden önce şu sorular cevaplanmalıdır:

• Peer IP erişimi var mı?
• Cluster membership profili doğru mu?
• İki node aynı beklenen yazılım seviyesinde mi?
• Mobility Conductor ile managed device bağlantısı sağlıklı mı?
• Config State UPDATE SUCCESSFUL mı?
• Config ID'ler beklenen seviyede mi?
• Peer durumu DISCONNECTED mı, yoksa negotiation aşamasında mı?
• Yakın zamanda cluster/uplink/VLAN/ACL değişikliği yapıldı mı?

Bu kontroller yapılmadan doğrudan node'u silmek, yeniden eklemek veya reboot etmek root cause'un görünmez hale gelmesine neden olabilir.

10 / RECOVERY YAKLAŞIMI

Recovery Yaklaşımı

Recovery işlemini en az müdahaleden en fazla müdahaleye doğru ilerletmek daha güvenlidir.

Aşama 1 — Altyapı Problemini Düzelt

Eğer problem:

• routing,
• VLAN,
• ACL,
• management connectivity,
• peer reachability

kaynaklıysa öncelikle bu katman düzeltilmelidir.

Ardından cluster'ın kendini yeniden toparlayıp toparlamadığı gözlemlenir.

Aşama 2 — Config Sync'i Doğrula

Mobility Conductor tarafında node tekrar:

UPDATE SUCCESSFUL

durumuna gelmeli ve güncel config'i almalıdır.

Aşama 3 — Cluster Membership'i Tekrar Kontrol Et

show lc-cluster group-membership

çıktısı yeniden alınır.

Beklenen sonuç:

CONNECTED (Leader)
CONNECTED (Member)

Aşama 4 — Kontrollü Yeniden Başlatma

Peer communication ve config sync sağlıklı görünmesine rağmen node cluster'a geri dönemiyorsa, bakım penceresi ve servis etkisi değerlendirilerek kontrollü restart/reboot düşünülebilir.

Bu adım ilk troubleshooting adımı olmamalıdır.

Aşama 5 — İleri Recovery

Cluster üyeliğinin yeniden oluşturulması, managed device'ın yeniden eşleştirilmesi veya Disaster Recovery gibi daha ileri işlemler sürüm ve topolojiye göre önemli servis etkileri yaratabilir.

11 / ÖNERILEN TROUBLESHOOTING AKIŞI

Önerilen Troubleshooting Akışı

ISOLATED Node
      |
      v
show lc-cluster group-membership
      |
      +-- Peer CONNECTED? ------ Yes ------+
      |                                    |
      No                                   v
      |                              Config Sync
      v                                    |
Peer Communication                         v
      |                               show switches
      v                                    |
Routing / VLAN / ACL                       v
      |                              UPDATE SUCCESSFUL?
      v                                    |
Secure Cluster State                       v
      |                              Cluster Re-check
      +-------------------------+----------+
                                |
                                v
                         Recovery gerekiyorsa
                         kontrollü müdahale

12 / DOĞRULAMA

Doğrulama

Recovery sonrasında yalnızca node'un up olması yeterli kabul edilmemelidir.

Aşağıdaki kontroller birlikte yapılmalıdır:

13 / KONTROL LISTESI

Kontrol Listesi

Sorun tekrarlandığında aşağıdaki kısa liste kullanılabilir:

[ ] show lc-cluster group-membership
[ ] Her iki node'un cluster görünümünü karşılaştır
[ ] show switches
[ ] Config ID kontrol et
[ ] Configuration State kontrol et
[ ] Peer IP erişimini doğrula
[ ] Routing / VLAN / ACL yolunu kontrol et
[ ] Secure tunnel / heartbeat durumunu incele
[ ] Son yapılan değişiklikleri kontrol et
[ ] Recovery öncesi config yedeği al
[ ] Recovery sonrası AP ve client durumunu doğrula

14 / ROOT CAUSE NASIL YAZILMALI?

Root Cause Nasıl Yazılmalı?

ISOLATED tek başına bir root cause değildir; bir durum belirtisidir.

Gerçek root cause ancak inceleme sonunda örneğin:

Peer connectivity problemi
Management/config sync problemi
Cluster secure communication problemi
Yanlış veya eksik cluster configuration
Yazılım kaynaklı doğrulanmış sorun

gibi teknik bir neden kesin olarak doğrulandığında yazılmalıdır.

15 / SONUÇ

Sonuç

Aruba controller cluster'da ISOLATED node gördüğümüzde en önemli yaklaşım, controller'ı hemen yeniden başlatmak yerine problemi katmanlara ayırmaktır.

En sağlıklı sıra:

Cluster Membership
        ↓
Config State / Config ID
        ↓
Peer Communication
        ↓
Cluster State
        ↓
Recovery
        ↓
AP / Client Verification

Bu yaklaşım root cause'u korur, gereksiz servis kesintilerini azaltır ve aynı problemin tekrar yaşanması durumunda daha hızlı teşhis yapılmasını sağlar.