Bu Konu Neden Önemli?
Kurumsal Wi‑Fi tasarımında yalnız kapsama alanı yeterli değildir; eşzamanlı istemci sayısı, uygulama trafiği, airtime, kanal kullanımı ve roaming gereksinimleri kapasiteyi belirler.
Karar Verirken Kontrol Edilecek Noktalar
Kullanıcı ve cihaz yoğunluğunu alan bazında ölçün.
Ses/video gibi gecikmeye duyarlı uygulamaları ayrı değerlendirin.
Kanal tekrar kullanımını ve transmit power seviyelerini planlayın.
Yüksek yoğunluk alanlarını genel ofis profilinden ayırın.
Mimari ve çalışma modeli
AP kapasitesi kapsama ile aynı değildir. Aktif istemci, uygulama trafiği, airtime, kanal rekabeti ve uplink sınırı birlikte değerlendirilir. Alan başına tek sabit AP sayısı bütün bina türlerine uygulanmaz. Metal raf, hareketli araç, üretim ekipmanı ve istemci anteni ölçüm sonucunu değiştirebilir.
- 1Aktif istemci ve uygulama
- 2Kanal/airtime planı
- 3AP ve uplink
- 4Yerinde yoğunluk testi
Tasarım parametreleri
- Airtime bütçesi
- Aktif istemci, uygulama ve PHY hızını birlikte ölçün; bağlı cihaz sayısı trafik yükü değildir.
- RF hücre tasarımı
- Kanal tekrarı, güç ve istemci roamingini sahada değerlendirin; AP eklemek paraziti artırabilir.
- Adres ve yönlendirme
- Subnet, gateway, route ve NAT kapsamını çizimde ayrı gösterin. DNS cevabı ile hedef IP’ye gerçek yolu birlikte doğrulayın.
- Yedek yol
- Yedek bağlantının aynı cihaz, enerji veya operatör arızasını paylaşmadığını kontrol edin. Geçiş süresini uygulama üzerinden ölçün.
- Taşıma kapasitesi
- Port hızı, uplink yoğunluğu, paket kaybı ve kuyrukları birlikte değerlendirin. Tek bir test akışı bütün kapasiteyi temsil etmeyebilir.
- İşletim görünürlüğü
- Arayüz sayaçları, komşuluklar, hata kayıtları ve zaman senkronizasyonunu izleyin. Normal davranış için başlangıç ölçümü tutun.
Hesap ve uygulama örneği
Örnek 60 aktif istemci × 2 Mbit/s net gereksinim 120 Mbit/s uygulama yüküdür; protokol ve airtime maliyeti eklenir. Tek radyo bu yükü mutlaka taşıyacak diye varsaymayın. Gerçek istemcilerle yoğun saat yükü, roaming ve PoE kısıtında radyo davranışını test edin.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Sinyal güçlü ama hız düşük | Co-channel trafik, retry veya düşük hızlı istemci airtime tüketiyor olabilir. | Kanal busy, retry ve uygulama gecikmesini aynı yoğunlukta ölçün. |
| Aynı VLAN çalışıyor, uzak ağ çalışmıyor | Gateway, route, ACL veya dönüş yolu farklı olabilir. | Kaynak ve hedef tarafında adres, route ve politika kayıtlarını karşılaştırın. |
| Küçük istek çalışıyor, büyük aktarım duruyor | MTU, paket kaybı veya hedef depolama beklemesi olası ayrımlardır. | Paket boyutu ve yeniden iletimleri ölçün; ağ sorununu disk beklemesinden ayırın. |
| Yedek bağlantı var ama kesinti uzun | Algılama, yeniden yakınsama, DNS veya oturum yenilenmesi süreyi büyütebilir. | Arıza zamanını ve ilk başarılı uygulama işlemini aynı saatle kaydedin. |
Kabul ve doğrulama kontrolleri
- Kapsama haritasını kapasite, dolaşım ve uygulama testiyle birlikte kabul edin.
- İzin verilen ve engellenen ağ çiftleri için erişim matrisi test edin.
- Tek bağlantı ve tek cihaz arızalarını ayrı uygulayın.
- Yoğun yükte kayıp, gecikme ve kuyruk sayaçlarını kaydedin.
- Değişiklik öncesi yapılandırma ve geri dönüş adımını saklayın.
- Yönetim erişiminin kullanıcı ağından gerektiği gibi ayrıldığını doğrulayın.
İlgili kavramlar
Radyo kapasitesi ve airtime
Kablosuz istemciler radyo ortamını paylaşır; bağlantı hızı kullanılabilir uygulama hızı değildir. Kanal genişliği, parazit, istemci yeteneği, düşük hızlı cihazlar ve yeniden iletim airtime tüketimini değiştirir. Daha fazla access point aynı kanalda daha fazla rekabet oluşturabilir. RSSI ile SNR farklı ölçülerdir; iyi sinyal tek başına düşük parazit veya yüksek kapasite kanıtı değildir. Tasarımı boş bina ölçümüyle bitirmeyin: üretim ekipmanı çalışırken, hedef istemcilerle ve yoğun saatlerde dolaşım ve uygulama gecikmesini test edin.
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
PoE kaynak ve uç cihaz bütçesi
Switchin toplam PoE bütçesi, her portun verebildiği güçten ayrı bir sınırdır. Port sayısı kadar uç cihaz sınıfını, kablo kaybını ve açılış sırasındaki gereksinimi değerlendirin. PSE tarafındaki güç ile PD’ye ulaşan güç aynı sayı olmayabilir. Access point daha düşük güçte açılıp bazı radyolarını kapatabilir; cihazın çalışıyor görünmesi bütün özelliklerin etkin olduğunu kanıtlamaz. PSU arızasında kalan PoE bütçesini ayrıca hesaplayın. Port tüketimi ve güç sınıfını yönetim kayıtlarından doğrulayın.
Kaynak rekabeti
Kaynak rekabeti, birden fazla iş yükünün aynı CPU, bellek, disk veya bağlantıyı paylaşırken birbirini bekletmesidir. Boş görünen toplam kapasite, tek bir sıcak çekirdek veya tek kuyruk üzerindeki darboğazı gizleyebilir. Aynı anda çalışan backup, antivirüs taraması, indeks bakımı ve kullanıcı trafiğini zaman çizelgesinde karşılaştırın. Kaynak eklemeden önce darboğazın yerini doğrulayın. Testte bir işi tek başına ve diğerleriyle birlikte çalıştırarak paylaşılan kaynağın etkisini ayırın; ortalama kullanım kadar yoğun saatlerdeki gecikmeyi de raporlayın.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Birincil teknik dokümantasyon
Bu İçerik Nasıl Hazırlandı?
Doz Teknoloji Teknik Ekibi
İçerik, Doz Teknoloji’nin kurumsal BT hizmet alanlarında kullandığı teknik değerlendirme yaklaşımı temel alınarak hazırlanmıştır.
Teknik kriterler + birincil kaynaklar
Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.
Karar kalitesini artırmak
Amaç, teknik bir terimi yalnız tanımlamak değil; satın alma, tasarım veya işletim kararı verirken hangi kriterlerin birlikte değerlendirilmesi gerektiğini görünür hale getirmektir.
İlgili Hizmet ve Rehberler
Bu Rehberle İlgili Kurumsal Çözümler
Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.
Teknik İhtiyacınızı Birlikte Değerlendirelim
Mevcut altyapınızı, kullanıcı sayınızı veya teknik hedefinizi paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.
Teknik Talep Oluşturun