İnternet Hattı Kapasite Planlama: Uygulama Bazlı Bant Hesabı

Yeni ofis açılırken ya da mevcut hat yetmediğinde ilk soru hep aynıdır: “Kaç kişiyiz, kaç megabit yeter?” Bu soru yanlış yerden başlar, çünkü trafiği kişiler değil uygulamalar üretir. Aşağıdaki yöntem, internet veya WAN hattının kapasitesini uygulama profilinden hesaplar; upload ihtiyacını ayrı değerlendirir, yedekleme trafiğini hesaba katar ve sonucu mevcut ölçüm verisiyle sınar.

Kişi başı bant hesabı neden tutmaz?

“Kişi başı 2 Mbps” gibi bir çarpan üç yerden hata verir. Birincisi, uygulama karışımı ekipten ekibe değişir: CAD dosyalarını bulut depolamaya yükleyen bir tasarım ekibiyle ERP ekranında çalışan bir finans ekibinin trafiği aynı ölçekte bile değildir. İkincisi, kişiden bağımsız trafik vardır; yedekleme, replikasyon, güncelleme, kamera kaydının buluta gönderimi ve izleme sistemleri çalışan sayısıyla ölçeklenmez. Üçüncüsü, çarpan yön bilgisi taşımaz. Oysa birçok ofiste hattı önce yükleme yönü boğar.

Doğru yol, trafiği kaynaklarına ayırmak, her kalem için “eşzamanlı oturum × oturum başına bant genişliği” hesabı yapmak ve iki yön için ayrı toplam çıkarmaktır.

Uygulama profilini çıkarmak

Uygulama profili, lokasyondaki iş akışlarının trafik envanteridir. Her kalem için şunları toplayın:

• Uygulama ve trafik yönü: Video konferans iki yönlüdür, yazılım güncellemesi ağırlıklı indirme, uzak yedekleme ağırlıklı yüklemedir.
• Oturum başına bant genişliği: Üreticinin güncel ağ gereksinimleri dokümanından alınır; çözünürlüğe ve kodek ayarına göre değişir.
• Eşzamanlılık katsayısı: Aynı anda kaç kişinin bu uygulamayı kullandığı. Takvim verisi, lisans kullanım raporları ve mevcut akış verisi iyi kaynaktır; tahminle değil veriyle doldurun.
• Zaman penceresi: Trafik mesaide mi, gece mi oluşuyor? Gece çalışan yedekleme gündüz tepe hesabına doğrudan eklenmez ama kendi penceresinde hattı tamamen doldurabilir.
• Gecikme duyarlılığı: Ses ve video düşük gecikme ister, dosya transferi yalnızca toplam süreye bakar. Bu ayrım QoS ve hat seçimi için girdidir.

Hesabı somutlaştırmak için ses trafiğini ele alalım. G.711 kodeği 64 kbps ses verisi üretir. 20 ms paketleme ile saniyede 50 paket gönderilir; her pakete eklenen 40 baytlık IP/UDP/RTP başlığı 16 kbps ek yük getirir ve IP katmanında görüşme başına, yön başına yaklaşık 80 kbps eder. Ethernet başlıkları eklenince değer yaklaşık 87 kbps’ye çıkar. Başlık yükü küçük değildir. Kodek ve paketleme süresi değişince sonuç da değişir; hesabı kendi ayarlarınızla yapın.

Örnek hesap: ofis, şube ve merkez

Aşağıdaki tablo 60 kişilik bir ofis için kurgulanmış bir örnek hesaptır. Oturum başına değerler varsayımdır; kendi uygulamalarınızın üretici dokümanlarındaki değerlerle ve kendi ölçümlerinizle değiştirin.

Bu toplam, hattın tavana dayanarak taşıyacağı yük olarak okunmamalı. TCP akışları boş kapasiteyi doldurmaya çalışır; hat sürekli tavanda çalışırsa kuyruk gecikmesi büyür ve ilk bozulan şey ses ve video olur. Pratikte hesaplanan tepenin üzerine planlama payı konur ve hat hızı, tepe anında bile boşluk kalacak şekilde seçilir. Bu örnekte 100 Mbps simetrik hat sınırdadır: yükleme tarafı rahat, indirme tarafında tepe anında pay kalmıyor. 200 Mbps sınıfı bir hat hem bugünkü tepeyi hem yakın dönem büyümeyi karşılar.

Merkez hesabında işler değişir, çünkü merkez şubelere sunucu hizmeti verir. Şubeler ERP’ye, dosya sunucusuna veya terminal sunucusuna merkez üzerinden bağlanıyorsa, şubelerin indirme trafiği merkez hattının yükleme trafiğidir. Sahada en sık atlanan kalem budur. Merkez hattını boyutlandırırken tüm şubelerin eşzamanlı ihtiyacını merkezin upload hesabına ekleyin. WAN mimarisi henüz seçilmediyse bu hesap SD-WAN ve MPLS karşılaştırması için de girdi olur.

Upload ihtiyacı: simetrik hat ne zaman şart?

Asimetrik hatlar (indirme hızı yükleme hızından yüksek) ev kullanımına göre tasarlanmıştır; tipik bir ofiste yükleme yönü beklenenden önce dolar. Aşağıdakilerden biri varsa simetrik hattı ciddi olarak değerlendirin:

• Lokasyonda internete veya şubelere hizmet veren sunucular var (web, e-posta, ERP, dosya sunucusu).
• Uzak lokasyona veya buluta yedekleme ve replikasyon yapılıyor.
• Uzaktan çalışanlar VPN ile merkezdeki kaynaklara bağlanıyor.
• Video konferans yoğun; aynı anda çok sayıda katılımcı bu lokasyondan bağlanıyor.
• Kamera görüntüleri veya büyük tasarım dosyaları buluta yükleniyor.

Yükleme yönü dolduğunda yalnızca yükleme yapan uygulama yavaşlamaz. İndirilen TCP akışlarının onay (ACK) paketleri de aynı kuyrukta beklediği için indirme performansı da düşer. Kullanıcı bunu “her şey yavaş” diye anlatır. “İndirme hızı yeterli ama her şey yavaş” şikâyetinde ilk açılacak grafik upload grafiğidir.

Yedekleme ve replikasyon trafiği

Uzak yedekleme kapasite hesabında çoğu zaman en büyük kalemdir ve hesabı basittir: aktarılacak veri, kullanılabilir zaman penceresine bölünür.

Örnek hesap:
Günlük değişen veri (sıkıştırma/tekilleştirme sonrası) : 200 GB
Yedekleme penceresi                                    : 22:00–04:00 = 6 saat
Gerekli ortalama hız = 200 GB × 8 / (6 × 3600 s)
                     = 1.600.000 Mb / 21.600 s
                     ≈ 74 Mbps (protokol ek yükü hariç)

Bu hesap üç şeyi birlikte gösterir. Gece penceresinde hattın yükleme yönünün büyük kısmı yedeklemeye ayrılmalıdır. Pencere taşarsa yedekleme mesai saatine sarkar ve sabah 09:00’daki yavaşlık şikâyetlerinin kaynağı olur. İlk tam yedek (seed) ise günlük değişimin çok üzerinde olduğu için ya fiziksel taşımayla ya da birkaç günlük planlı aktarımla yapılmalıdır. Yedekleme yazılımının bant sınırlama (throttling) özelliğini saat bazlı kurallarla kullanmak, sarkma olduğunda gündüz trafiğini korur. Yedek depolama tarafındaki boyutlandırma için yedek depolama kapasite hesabı rehberi tamamlayıcıdır.

İşletim sistemi ve uygulama güncellemeleri de ani tepeler üretir: yüzlerce cihazın aynı büyük güncellemeyi aynı anda indirmesi hattı dakikalarca doldurur. Yerel önbellek veya dağıtım sunucusu kullanmak ve güncellemeleri kademeli halkalara bölmek, hat yükseltmekten ucuzdur. Önce trafiği düzenleyin. Sonra hattı büyütün.

Mevcut veriyle doğrulama ve büyüme payı

Hesap bir modeldir. Mevcut hat varsa model ölçümle sınanmalıdır. Kullanabileceğiniz kaynaklar:

• Arayüz sayaçları (SNMP): Toplam kullanımı yön bazında verir. Beş dakikalık ortalamalar kısa tepeleri düzleştirir; tepe analizinde daha kısa örnekleme aralığı veya 95. persentil kullanın.
• Akış verisi (NetFlow/IPFIX/sFlow): Trafiğin hangi uygulama, kaynak ve hedeften geldiğini gösterir; profildeki varsayımları sınamanın en iyi yoludur. Seçenekler için NetFlow, sFlow ve IPFIX karşılaştırması yazısına bakabilirsiniz.
• Firewall uygulama raporları: Uygulama tanıma özellikli firewall’lar kategori bazlı kullanım verir; şifreli trafikte sınıflandırma doğruluğu sınırlı kalabilir.

Ölçüm en az birkaç haftayı ve ay sonu kapanışı, yoğun sezon gibi iş döngülerini kapsamalı. Tek haftalık veri yanıltır. Uzun dönemli trend ve raporlama yöntemi ağ kapasite raporlaması yazısında ayrıntılı anlatılıyor.

Büyüme payını sözleşme süresi ve operatörün yükseltme teslim süresiyle birlikte belirleyin. Sözleşme iki yıllıksa ve yükseltme altyapı çalışması gerektiriyorsa, bugünkü tepeyi değil iki yıl sonra beklenen tepeyi esas alın. Planlanan işe alımlar, yeni bulut geçişleri, şube açılışları ve kurumsal ağ altyapısındaki değişiklikler bu öngörünün girdileridir.

Hat yükseltme öncesi kontrol listesi

• Uygulama profili çıkarıldı; her kalem için yön, eşzamanlılık ve zaman penceresi belli.
• İndirme ve yükleme toplamları ayrı ayrı hesaplandı.
• Yedekleme ve replikasyon için gereken hız, pencere süresiyle hesaplandı.
• Merkez lokasyonda şubelere sunulan hizmetler upload hesabına eklendi.
• Model, en az birkaç haftalık akış ve arayüz verisiyle karşılaştırıldı.
• Sorunun kapasite değil gecikme, kayıp veya yapılandırma kaynaklı olmadığı doğrulandı.
• Sözleşme süresince beklenen büyüme ve yükseltme teslim süresi hesaba katıldı.
• Kapasite yetersizse önce trafik zamanlaması, önbellek ve QoS seçenekleri denendi.

Hat boyutlandırması ve operatör seçimi için internet hat yönetimi, mevcut performans sorunlarının teşhisi için network performans analizi hizmetlerimize bakabilirsiniz.

Sık sorulan sorular

Kullanıcı başına kaç Mbps hesaplanmalı?

Tek bir kişi başı değer yanıltır; aynı kişi sayısındaki bir muhasebe ofisiyle bir mühendislik ofisinin ihtiyacı çok farklıdır. Kullanılan uygulamaları ve eşzamanlı kullanım oranını çıkarın, sonra sonucu mevcut hattın akış verisiyle karşılaştırın.

Hat dolu görünmüyor ama kullanıcılar yavaşlıktan şikâyet ediyor, kapasite sorunu olabilir mi?

Olabilir. Beş dakikalık ortalama grafikler kısa süreli tepeleri gizler; anlık doygunluk ses ve video kalitesini bozar. Daha kısa aralıklı örnekleme ve akış verisiyle tepe anlarına bakın. Gecikme, paket kaybı ve DNS gibi kapasite dışı nedenleri de ayrıca kontrol edin.

Simetrik hat her zaman daha mı iyi?

Her zaman gerekmez. Trafik büyük ölçüde indirme yönündeyse asimetrik hat yeterli olabilir. İnternete hizmet veren sunucular, uzak yedekleme, merkeze bağlanan şube ve VPN kullanıcıları ya da yoğun video konferans varsa upload belirleyici olur ve simetrik hat tercih edilir.

Kapasite artırmak yerine QoS yeterli olur mu?

QoS sınırlı kapasiteyi önceliğe göre paylaştırır; yetmeyen bir hatta kritik uygulamaları korur ama kapasite üretmez. Hat düzenli olarak doygunluğa ulaşıyorsa QoS kısa vadeli bir önlemdir; kalıcı çözüm kapasite artırımı veya trafik zamanlamasıdır.