Ağ Kapasite Raporlaması: Uplink Kullanımı, 95. Persentil ve Trend

İzleme sistemi her porttan yüzlerce grafik üretir, ama “uplink’i ne zaman büyütmeliyiz?” sorusuna cevap veren bir rapor çoğu kurumda yoktur. Grafik var, karar yok. Aşağıda mevcut LAN izleme verisinden anlamlı bir kapasite raporu çıkarmanın yolunu anlatıyoruz: ortalama ile tepe değer yanılgısı, 95. persentil hesabı, örnekleme aralığının sınırları, discard ve hata sayaçlarının yorumu, oversubscription takibi, trend projeksiyonu ve aylık rapor şablonu.

Kapasite raporu hangi soruya cevap vermeli?

Raporun değeri, verdirdiği karara bağlıdır. Hedef grafik koleksiyonu değil, şu sorulara kısa ve kanıtlı cevap veren bir belgedir:

• Hangi uplink’ler ve sunucu portları iş saatlerinde kullanıcı deneyimini etkileyecek düzeyde dolu?
• Doluluk gerçek bir tıkanmaya (paket düşmesi) dönüşüyor mu, yoksa yalnızca yüksek kullanım mı?
• Mevcut büyüme hızıyla hangi bağlantı ne zaman eşiğe ulaşacak?
• Satın alma ve kurulum süresi düşünüldüğünde hangi yatırım kararı bu çeyrekte verilmeli?

Kapsam mevcut LAN ve veri merkezi portlarıdır. Yeni bir internet veya WAN hattının uygulama bazlı boyutlandırılması farklı bir hesap ister; bunun için internet hattı kapasite planlama yazısına bakabilirsiniz.

Kullanım nasıl hesaplanır: sayaçlar ve formül

Port kullanımı, SNMP ile okunan bayt sayaçlarının iki örnek arasındaki farkından hesaplanır. RFC 2863 (IF-MIB) iki sayaç ailesi tanımlar: 32 bit ifInOctets/ifOutOctets ve 64 bit ifHCInOctets/ifHCOutOctets. Hız için ifHighSpeed (Mbps cinsinden) kullanılır.

kullanım (%) = (Δ ifHCInOctets × 8 × 100) / (Δt [s] × ifHighSpeed × 1.000.000)

# Linux’ta tek bir sayacı okumak (SNMPv3 ile)
snmpget -v3 -l authPriv -u izleme -a SHA -A '<auth-parola>' -x AES -X '<priv-parola>' \
  10.10.99.2 IF-MIB::ifHCInOctets.10101 IF-MIB::ifHighSpeed.10101

32 bit sayaçlar yüksek hızda çok çabuk başa döner. Üst sınır olan 4.294.967.296 bayt yaklaşık 34,4 gigabit eder; 1 Gbps hat hızında sayaç yaklaşık 34 saniyede, 10 Gbps’te yaklaşık 3,4 saniyede taşar. 5 dakikalık sorgulamada 32 bit sayaçla hesaplanan değer anlamsızdır. Sahada “10G uplink hep boş görünüyor” şikâyetinin arkasından sıklıkla bu çıkar. 64 bit sayaçlar SNMPv1’de okunamaz; v2c veya v3 gerekir. Güvenli SNMP yapılandırması için SNMPv3 yapılandırma rehberine bakın.

Ortalama, tepe ve 95. persentil: örnek hesap

Günlük veya aylık ortalama kapasite kararında neredeyse her zaman yanıltır; boş saatler ortalamayı aşağı çeker. Örnek hesap: 10 Gbps’lik bir uplink iş saatlerinde 8 saat boyunca 6 Gbps, kalan 16 saatte 0,5 Gbps taşısın. Günlük ortalama (8 × 6 + 16 × 0,5) / 24 = 56 / 24 ≈ 2,33 Gbps olur. Rapor “ortalama yaklaşık 2,3 Gbps” derse sorun yok gibi görünür. Oysa kullanıcılar günün üçte birinde 6 Gbps taşıyan bir bağlantıyla çalışır.

Tek bir maksimum değer ters yönde yanıltır: gece yedeklemesi veya yazılım dağıtımı sırasındaki anlık tepe, kalıcı ihtiyacı temsil etmez. 95. persentil iki uç arasında dengeli bir ölçüdür; dönem içindeki örneklerin yüzde 95’inin altında kaldığı değeri verir.

Örnek hesap: 30 günlük bir ayda 5 dakikalık örneklemeyle 30 × 288 = 8.640 örnek oluşur. Bunların yüzde 5’i 432 örnektir. Tüm örnekler büyükten küçüğe sıralanır, en yüksek 432 örnek atılır ve kalan en yüksek değer (433. sıradaki) 95. persentil olarak raporlanır. Atılan 432 örnek, 5 dakikalık aralıkla toplam 36 saate karşılık gelir. Bağlantı ay içinde toplam 36 saatten fazla bu değerin üzerinde çalışmışsa bu persentile yansır.

Örnekleme aralığı ve mikro patlamaların görünmezliği

5 dakikalık örnekleme o 5 dakikanın ortalamasını verir. Örnek hesap: 1 Gbps bir portta 5 dakikalık ortalama yüzde 30 görünüyorsa, bu 300 saniyede yaklaşık 90 gigabit veri demektir. Bu veri 300 saniyeye eşit yayılmış olabilir; 90 saniye boyunca hat hızında akıp kalan sürede sıfır da olabilir. İkinci durumda kullanıcılar 90 saniye dolu bir hat yaşar, grafik yüzde 30 gösterir.

Daha kısa ölçekte, milisaniye düzeyindeki mikro patlamalar (microburst) hiçbir SNMP örneklemesinde görünmez. Birden çok 10 Gbps sunucunun aynı anda tek bir 10 Gbps porta veri göndermesi switch tamponunu milisaniyeler içinde doldurup paket düşürebilir. SNMP tarafındaki tek iz discard sayacıdır. Örnekleme aralığını kritik uplink’lerde 1 dakikaya düşürmek dakika düzeyindeki tepeleri görünür kılar, mikro patlamayı göstermez; bunun için üreticinin tampon ve kuyruk istatistikleri veya akış/telemetri verisi gerekir. Grafik her şeyi göstermez.

Discard, error ve kuyruk sayaçlarını okumak

Kullanım oranı tek başına tıkanıklığı kanıtlamaz. Yüzde 90 dolu bir port paket düşürmüyorsa kullanıcı deneyimi bozulmayabilir; yüzde 40 ortalamalı bir port ise mikro patlamalar yüzünden düşürüyor olabilir. Bu nedenle kapasite raporu kullanım verisini her zaman şu sayaçlarla birlikte sunar:

Hata sayaçları kapasite değil, fiziksel katman sorunudur. Artan ifInErrors görülen port büyütülmez; kablosu veya optiği kontrol edilir. Sahada sık gördüğümüz hata, CRC artan bir uplink’e çözüm olarak ikinci bir bağlantı eklenmesidir; kirli bir fiber konnektörü temizlemek yeterliyken. Cisco cihazlarda aynı bilgi show interfaces çıktısındaki “Total output drops” ve show interfaces counters errors ile görülür. Sayaçlar mutlak değer olarak değil, dönem içindeki artış hızı olarak raporlanır; clear counters komutunun izleme sistemindeki hesabı bozabileceğini de unutmayın.

Uplink oversubscription oranının izlenmesi

Oversubscription oranı, kurumsal ağ altyapısında erişim portlarının toplam kapasitesinin uplink kapasitesine oranıdır. Örnek hesap: 48 adet 1 Gbps erişim portu ve 2 × 10 Gbps uplink’i olan bir switch’te oran 48 / 20 = 2,4:1’dir. Oran tek başına iyi veya kötü değildir; kullanıcı trafiğinin çoğu aynı anda tepe yapmadığı için erişim katmanında belirli bir oversubscription normaldir. Kararı oranın kendisi değil, uplink’in gerçek 95. persentili ve discard sayaçları verir.

Uplink’ler port-channel ise toplamın yanında her üye bağlantı ayrı izlenir. LACP yük dağıtımı akış bazlı hash kullandığı için trafik üyelere eşit dağılmayabilir; toplam yüzde 45 görünürken üyelerden biri dolu olabilir. Toplam grafik bunu gizler. Hash yöntemi seçimi için LACP ve EtherChannel yapılandırması yazısına bakabilirsiniz. Uplink’i hangi akışların doldurduğunu görmek için NetFlow, sFlow ve IPFIX verisi kullanılır; büyütme kararından önce trafiğin bir kısmının yanlış yoldan aktığı ya da planlanmamış bir yedekleme işinden geldiği ortaya çıkabilir.

Eşik belirleme ve trend projeksiyonu

“Yüzde 70’i geçince büyüt” gibi sabit kurallar her bağlantıya uymaz. Eşik bağlantı bazında şu girdilerle belirlenir: taşınan trafiğin gecikme hassasiyeti (ses ve video mu, yedekleme mi), discard sayaçlarının hangi kullanım düzeyinde artmaya başladığı, yedekli yapıda bir bağlantı düştüğünde kalan bağlantının tüm yükü taşıyıp taşıyamayacağı ve satın alma–kurulum süresi. Son iki madde sık atlanır. 2 × 10 Gbps’lik yedekli bir uplink’te her bağlantı 6 Gbps taşıyorsa, biri düştüğünde 12 Gbps’lik yük tek 10 Gbps’e sığmaz. Yedeklilik o anda kaybolur.

Trend için aylık 95. persentil değerleri en az 6–12 ay tutulur ve basit doğrusal eğilim çıkarılır. Örnek hesap: bir çekirdek uplink’in iş saati 95. persentili bu ay 4,2 Gbps, son 12 ayın ortalama artışı ayda 0,15 Gbps ve bu bağlantı için belirlenen eşik 7 Gbps olsun. Eşiğe kalan süre (7 − 4,2) / 0,15 ≈ 18,7 aydır. Satın alma ve kurulum 4 ay sürüyorsa karar en geç yaklaşık 14 ay içinde verilmelidir. Doğrusal projeksiyon, yeni bir lokasyonun taşınması veya bir uygulamanın buluta göçü gibi sıçramaları yakalamaz; bu tür planlı değişiklikler rapora ayrı satır olarak eklenir.

Aylık kapasite raporu şablonu

Rapor iki katmanlıdır: yönetim için bir özet sayfa, teknik ekip için ayrıntılı tablo. Ayrıntılı tabloda izlenen her kritik bağlantı tek satırdır:

Özet sayfada yalnızca “aksiyon gerekli” ve “izlemede” durumundaki bağlantılar, önerilen adım ve karar tarihi yer alır. Raporu üretecek izleme platformu persentil hesabını ve uzun süreli veri saklamayı desteklemelidir. Bazı sistemler eski veriyi seyrelterek (ortalama alarak) saklar; geçmiş tepeler böylece silinir. Platform seçerken bu ölçütü Zabbix, LibreNMS ve PRTG karşılaştırması ile birlikte değerlendirin.

Kapasite raporlamasını düzenli bakım döngüsüne bağlamak için ağ bakım, izleme ve periyodik kontrol hizmetimiz; discard ve mikro patlama kaynaklı performans sorunlarının teşhisi için network performans analizi ve sorun giderme hizmetimiz ilgili sayfalardır.

Sık sorulan sorular

95. persentil neden ortalamadan daha iyi bir kapasite ölçüsüdür?

Ortalama, boş saatler yüzünden yoğun dönemleri gizler; tek bir maksimum değer ise geçici tepelerden etkilenir. 95. persentil, dönemdeki örneklerin yüzde 95’inin altında kaldığı değeri verir; kısa süreli tepeleri dışarıda bırakırken kalıcı yoğunluğu yansıtır.

Grafikte kullanım düşük ama kullanıcılar yavaşlık yaşıyor, neden olabilir?

5 dakikalık ortalama, dakika ve milisaniye düzeyindeki tepeleri gizler. Aynı porttaki ifOutDiscards sayacı artıyorsa mikro patlamalar nedeniyle paket düşüyor olabilir. Port-channel üyelerinden birinin dengesiz yük yüzünden dolu olması da aynı belirtiyi verir.

SNMP ile kapasite ölçümünde 64 bit sayaç neden şart?

32 bit bayt sayacı 1 Gbps hızda yaklaşık 34 saniyede, 10 Gbps hızda yaklaşık 3,4 saniyede başa döner. Dakikalar süren sorgulama aralıklarında hesaplanan değer anlamsız olur. 64 bit ifHCInOctets ve ifHCOutOctets sayaçları bu sorunu ortadan kaldırır.

Uplink büyütme eşiği kaç yüzde olmalı?

Herkes için geçerli tek bir değer yoktur. Eşik; taşınan trafiğin gecikme hassasiyeti, discard sayaçlarının hangi kullanım düzeyinde artmaya başladığı, yedekli bağlantılardan biri düştüğünde kalan kapasite ve satın alma süresine bakılarak bağlantı bazında belirlenir.