WLAN Controller Seçimi: Yüksek Erişilebilirlik, Tünel Modeli ve RRM

Controller ne yapar?

Kablosuz controller, AP'lerin yapılandırmasını dağıtır, kanal ve güç kararlarını koordine eder, roaming için anahtar bilgilerini paylaştırır ve isteğe bağlı olarak kullanıcı trafiğini merkezde toplar. Fiziksel cihaz, sanal makine veya bulut hizmeti olarak sunulabilir. Seçim yapılırken controller'ın hangi işlevleri üstlendiği ve bu işlevlerin kesinti anında nasıl davrandığı anlaşılmalıdır.

Yüksek erişilebilirlik modeli

Controller arızalandığında ne olur? Aktif/bekleme modelinde ikinci controller durumu devralır; geçiş süresi ve bu sırada kullanıcı oturumlarının korunup korunmadığı modelden modele değişir. Aktif/aktif kümelemede yük paylaşılır. Bazı mimarilerde AP'ler controller olmadan da yerel anahtarlamayla çalışmayı sürdürebilir.

Merkezi tünel mi, yerel anahtarlama mı?

Merkezi tünelde tüm kullanıcı trafiği controller'a taşınır; güvenlik politikası ve misafir ağ izolasyonu tek noktada uygulanır, VLAN yapısı basitleşir. Ancak controller'ın aktarım kapasitesi darboğaz olabilir ve Wi-Fi 6/7 hızlarında bu kapasite dikkatle hesaplanmalıdır. Yerel anahtarlamada trafik AP'nin bağlı olduğu anahtardan doğrudan akar; ölçeklenmesi kolaydır ama politika dağıtık uygulanır.

Birçok kurum karma model kullanır: misafir trafiği merkezde, kurumsal trafik yerelde.

RRM ve roaming derinliği

• Otomatik kanal/güç kararlarının nedenini gösterebilen bir arayüz, sorun gidermede zaman kazandırır.
• 802.11r/k/v desteği ve bunların SSID bazında ayarlanabilmesi gerekir.
• Eski istemciler için 802.11r'nin karma modda çalışabilmesi önemlidir.
• Controller'lar arası roaming (inter-controller) büyük kampüslerde test edilmelidir.

Ölçek ve yaşam döngüsü

Controller'ın veri sayfasındaki AP sayısı sınırı, tüm özellikler açıkken geçerli olmayabilir. Merkezi tünel, derin paket inceleme ve yoğun analitik açıldığında kapasite düşebilir. Büyüme planı ile birlikte gerçek özellik setiyle kapasite doğrulanmalıdır. Ayrıca controller yazılımının destek süresi, AP'lerin destek süresiyle uyumlu olmalıdır; aksi halde AP'ler çalışırken controller platformunun yenilenmesi gerekebilir.

Fiziksel, sanal veya bulut controller

Controller üç biçimde sunulabilir. Fiziksel cihaz, belirli bir kapasite ve arayüz seti sunar; kurulumu basittir ama kapasite artışı donanım değişimi gerektirebilir. Sanal controller, kurumun sanallaştırma altyapısında çalışır; kaynak ayırarak ölçeklenebilir, ancak sanallaştırma platformunun performansı ve yedekliliği kritik hale gelir. Bulut controller ise üretici tarafından işletilir; kurum yalnızca hizmeti kullanır.

Merkezi tünel kullanılacaksa fiziksel controller'ın veri işleme kapasitesi veya sanal controller'ın ağ arayüzü performansı belirleyicidir. Yalnızca yönetim ve kontrol işlevleri kullanılacaksa sanal veya bulut modeller daha esnek olabilir. Seçim, trafiğin nerede akacağı kararıyla birlikte verilmelidir.

Yedeklilik testi nasıl yapılır?

Yüksek erişilebilirlik özelliği kağıt üzerinde bulunabilir ama sahada beklenen davranışı göstermeyebilir. Kabul aşamasında controller arızası canlı olarak simüle edilmelidir: birincil controller kapatılır, AP'lerin ikinciye geçiş süresi, aktif sesli görüşmelerin ve veri oturumlarının korunup korunmadığı ölçülür. Ardından birincil controller geri açılır ve geri dönüş davranışı gözlenir.

• Controller kapatıldığında AP'ler kaç saniyede yedek controller'a geçiyor?
• Aktif sesli görüşmeler kesiliyor mu?
• 802.1X oturumları yeniden doğrulama gerektiriyor mu?
• Birincil controller döndüğünde AP'ler otomatik geri mi dönüyor, bu sırada kesinti oluyor mu?
• Yazılım güncellemesi sırasında hangi AP'ler ne kadar süre hizmet dışı kalıyor?

İşletim ve entegrasyon

Controller, kurumun diğer sistemleriyle birlikte çalışır: kimlik doğrulama sunucuları (RADIUS), ağ erişim kontrolü (NAC), güvenlik duvarları, SIEM ve izleme sistemleri. Seçim sırasında bu entegrasyonların desteklenip desteklenmediği ve hangi protokollerle (syslog, SNMP, API, akış verisi) yapıldığı kontrol edilmelidir.

Ayrıca controller yazılımının sürüm politikası önemlidir. Uzun süreli destekli (LTS) sürümler kararlılık sağlar ama yeni özellikleri geç alır; kısa döngülü sürümler yeni özellikleri hızla getirir ama daha sık güncelleme gerektirir. Kritik ortamlarda, yeni bir sürüm önce test ortamında veya pilot sahada denenmeli, ardından kademeli olarak yaygınlaştırılmalıdır.

Son olarak, controller değişimi bir AP değişiminden daha büyük bir projedir; çünkü tüm yapılandırma, politika ve entegrasyon yeni platforma taşınır. Bu nedenle controller seçimi, AP seçiminden daha uzun vadeli düşünülmelidir.

Karar öncesi son kontrol

Controller kararından önce, büyüme senaryosuyla birlikte bir kapasite tablosu hazırlanmalıdır. Bugünkü AP ve istemci sayısı, beş yıl içinde beklenen artış, merkezi tünel kullanılacak trafik miktarı ve açılacak özellikler (analitik, derin paket inceleme, konum hizmetleri) bu tabloda yer almalıdır. Tablo, aday controller'ın hangi noktada kapasite sınırına ulaşacağını ve ek lisans veya donanımın ne zaman gerekeceğini gösterir.

Ayrıca controller'ın yaşam döngüsü, AP'lerin yaşam döngüsüyle karşılaştırılmalıdır. Controller platformunun destek sonu tarihi, AP'lerin destek sonu tarihinden önce geliyorsa, AP'ler hala kullanılabilir durumdayken controller yenilemesi gerekecektir. Bu durum toplam maliyeti ve proje planlamasını doğrudan etkiler; bu nedenle iki tarih birlikte değerlendirilmelidir.

• Beş yıllık kapasite tablosu hazırlandı mı?
• Controller ve AP destek sonu tarihleri karşılaştırıldı mı?
• Yedeklilik tatbikatı kabul planına eklendi mi?
• Entegrasyonlar (RADIUS, NAC, SIEM) test edildi mi?

Sık sorulan sorular

Controller'sız (controller-less) mimariler ne sunar? Bazı mimarilerde kontrol işlevleri AP'ler arasında dağıtılır veya bulutta yürütülür; fiziksel controller gerekmez. Bu yaklaşım küçük ve orta ölçekli ağlarda kurulum ve maliyet avantajı sağlayabilir. Büyük kampüslerde ise merkezi tünel, ayrıntılı politika ve ölçek ihtiyaçları nedeniyle controller tabanlı mimariler hala yaygındır.

Controller'ı farklı veri merkezlerine dağıtmak gerekir mi? Kritik ortamlarda birincil ve yedek controller'ın farklı fiziksel konumlarda olması, bir veri merkezi kesintisinde hizmetin sürmesini sağlar. Bu durumda iki konum arasındaki bağlantının gecikmesi ve kapasitesi, controller üreticisinin gereksinimlerine uygun olmalıdır.

Controller lisansı AP sayısına mı, özelliklere mi bağlıdır? Bu, üreticiye göre değişir; bazı modellerde AP başına, bazılarında özellik paketlerine göre lisanslama yapılır. Teklif karşılaştırmasında aynı özellik setinin fiyatlandığından emin olunmalıdır. Ayrıca lisansın süreli mi kalıcı mı olduğu, süre dolduğunda hangi özelliklerin kapanacağı ve yedek controller için ayrı lisans gerekip gerekmediği netleştirilmelidir. Yedek controller lisansı çoğu zaman gözden kaçar ve proje sonunda beklenmedik bir maliyet kalemi olarak ortaya çıkar; bu nedenle teklif karşılaştırmasında yedeklilik dahil toplam lisans maliyeti hesaplanmalıdır.