tc 명령을 이용한 트래픽 제어 실험에 관한 결과입니다.
스크립트는 아래와 같습니다.
############################################################################################
#!/bin/sh
EDEV="eth0"
# create root node
/sbin/tc qdisc add dev $EDEV root handle 1: htb default 11
# create LINK class
/sbin/tc class add dev $EDEV parent 1: classid 1:1 htb rate 20Mbit ceil 20Mbit
/sbin/tc class add dev $EDEV parent 1:1 classid 1:10 htb rate 15Mbit ceil 15Mbit
# create our REST class for unutilized bandwidth
/sbin/tc class add dev $EDEV parent 1:1 classid 1:11 htb rate 5Mbit ceil 5Mbit
/sbin/tc qdisc add dev $EDEV parent 1:10 handle 10: sfq perturb 10
/sbin/tc qdisc add dev $EDEV parent 1:11 handle 11: sfq perturb 10
/sbin/tc filter add dev $EDEV protocol ip parent 1:0 prio 1 u32 match ip src 0.0.0.0/0 flowid 1:10
############################################################################################
위 스크립트로 테스트가 진행되었습니다.
전체 제어된 트래픽은 20Mbps로 제한을 두도록 설정했고,
class id 11일 경우 우선 순위로 지정해서 out traffic을 5Mbps로 제한을 걸었으며, class id 10은 15Mbps
로 제한을 걸었습니다.
ceil 옵션은 대역 sharing 처리를 못하도록 하는 옵션입니다. 즉 5Mbps 를 넘어서지 못하도록 일부러 묶어뒀습니다.
위 스크립트 실행이후 mrtg 그래프는 20Mbps 를 훨씬 초과 하였으며, 실제 tc 테스트 결과를 보면 아래와 같습니다.
qdisc htb 1: r2q 10 default 11 direct_packets_stat 4
Sent 140811537021 bytes 35430427 pkt (dropped 1662573, overlimits 31954288 requeues 1)
rate 0bit 0pps backlog 0b 112p requeues 1
qdisc sfq 10: parent 1:10 limit 126p quantum 1514b perturb 10sec
Sent 140811414799 bytes 35430362 pkt (dropped 1662573, overlimits 0 requeues 1)
rate 0bit 0pps backlog 523870b 112p requeues 1
qdisc sfq 11: parent 1:11 limit 126p quantum 1514b perturb 10sec
Sent 42292 bytes 26 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
### eth0: traffic classes
class htb 1:11 parent 1:1 leaf 11: prio 0 rate 5000Kbit ceil 5000Kbit burst 2225b cburst 2225b
Sent 113814 bytes 61 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 37 borrowed: 0 giants: 32
tokens: 3496 ctokens: 3496
class htb 1:1 root rate 20000Kbit ceil 20000Kbit burst 4Kb cburst 4Kb
Sent 141819096186 bytes 35430291 pkt (dropped 0, overlimits 0 requeues 0)
rate 37282Kbit 1089pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 37274474
tokens: -802 ctokens: -802
class htb 1:10 parent 1:1 leaf 10: prio 0 rate 15000Kbit ceil 15000Kbit burst 3474b cburst 3474b
Sent 140811422563 bytes 35430366 pkt (dropped 1662573, overlimits 0 requeues 0)
rate 36690Kbit 1090pps backlog 0b 113p requeues 0
lended: 35430254 borrowed: 0 giants: 37274442
tokens: -2586 ctokens: -2586
### eth0: filtering rules
filter parent 1: protocol ip pref 1 u32
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 37092945 success 37092945)
match 00000000/00000000 at 12 (success 37092945 )
전체 out traffic 합이 20Mbps 으로 제어 테스트를 하였습니다만, 실제 out traffic이 훨씬 많이 나오는 서버 경우는 tc htb bandwidth 제어가 확실하게 되지 않으며, 제어된 부분을 무시하고 나갑니다.
하지만, 제어된 bandwidth 어느정도 효과가 있으려면, 실제 out traffic 최대 bandwidth와 제어된 tc bandwidth 값이 유사할때는 효과가 있어보입니다.
제가 내린 결론은 tc 를 이용한 대역폭 제어는 그렇게 좋은 효과가 없다는 것으로 결론 내렸습니다.
제가 옵션을 모르는 것이 있거나, 저 명령 옵션이나 기반 기술을 제대로 이해를 못해서 그럴수도 있습니다.
정확하게 저 기술로 대역 제어를 해보신분이 계시면, 좀 알려주시면 고맙겠습니다. :)