☰

트래픽 조절로 서버 속도를 늦추세요

tag-icon • tag-icon networking tc macvlan
트래픽 조절로 서버 속도를 늦추세요

느린 서버에서 스트리밍되는 애플리케이션의 동작을 연구하고 싶습니다. 네트워크 대기 시간 도입 을 활용하려고 합니다 tc-netem.

더 복잡한 시나리오를 설정하기 전에 느린 서버를 시뮬레이션해야 하는 가상 머신에서 이 작업을 수행하기로 결정했습니다. 가상 머신을 통해 액세스하고 있으므로 ssh가상 이더넷을 만들기로 결정했습니다. 이로 인해 실제 이더넷 장치를 사용하여 관리하려고 계획했지만 대기 시간이 발생했습니다.

먼저 가짜 인터페이스를 만들고 ip link add link eth0 type macvtap여기에 IP 주소를 할당했습니다.

그런 다음 40밀리초의 지연을 추가했습니다 tc qdisc add dev macvtap0 root netem delay 40000. 이로 인해 실제로 처리량이 감소했습니다(~250MiB/초에서 ~6MiB/초로).

이 시점에서 설정을 약간 조정해 보았더니 지연이 장치에만 영향을 미치는 것이 아니라 내가 연결된 장치에도 영향을 미친다는 사실을 깨닫기 시작했습니다 macvtap0. eth0즉, ssh세션이 지연되기 시작했습니다.

netem delay실제 네트워크 카드에 영향을 미치는 것 같습니다 . 내가 가상 머신에서 작업하고 있기 때문인가요? 아니면 다른 황갈색을 사용해야 합니까 macvtap? 아니면 변경 사항을 에 적용했기 때문일까요 root qdisc?

편집하다- 겉으로는 거대해 보이는 트래픽 차별화의 세계에 처음으로 들어갔습니다. 어쩌면 더 좋은 방법이 있을까요? 예를 들어, 선택한 프로세스의 속도를 늦추도록 대기열을 설정할 수 있나요? 나는 실제 목적을 반영하기 위해 이 질문의 이름을 바꾸기로 결정했습니다.

답변1

첫째, 설명: 대기 시간을 늘리는 것은 대역폭을 제한하는 것과 동일하지 않습니다. 고려하다정지궤도 위성 인터넷 링크: 단방향 흐름은 (빛의 속도로 인해) 약 1/4초의 필수 지연이 있으므로 전체 경로가 위성을 통해 전송된다면 왕복은 약 1/2초 정도가 될 것이며 이는설명하다~이 되다506Mbps 도달 가능최신 기술을 사용하면 다음 패킷을 보내기 전에 각 패킷이 승인될 때까지 기다리지 않고 이 1/2초 창에서 대량의 데이터를 전송할 수 있습니다. 물론 대기 시간은 속도에 아무런 영향을 주지 않으며 승인을 기다리거나 재전송을 요구하는 등의 이유로 방해를 받을 수 있습니다.

질문이 제기되고 질문의 목표가 다음과 같기 때문에진짜차이점은 이 정보 외에도 다음 질문에만 답변한다는 것입니다.

일부 qdisc에는 속도 제한 기능이 내장되어 있습니다:HTB,TBF,...대기 시간을 늘리는 대신 대역폭을 제한하기 위한 두 가지 제안은 다음과 같습니다.

  • TC를 사용하여 Linux에서 네트워크 대역폭 제한

    # tc qdisc add dev eth0 root tbf rate 1024kbit latency 50ms burst 1540

    언제나 그렇듯이 수출에는 제한이 있습니다. 접근을 제한하려면,IFB내 답변의 예와 같이 장치가 연결되어 있어야 합니다.netem을 사용하여 브리지 인터페이스에서 패킷 손실 시뮬레이션.

  • 좋아요(그렇게 늙지는 않았어요)wondershaper스크립트(v1.4. Debian과 같은 일부 배포판에서는 더 이상 사용되지 않음)는 놀라운 일을 할 수 있습니다. 스트림 우선 순위를 지정하고 대기 시간을 줄이도록 설계되었지만 속도도 줄일 수 있으며 이미 IFB를 사용하여 출구와 입구를 제한하는 단순화 방법을 사용하고 있습니다.

    # wondershaper -a eth0 -d 1000 -u 100eth0대역폭은 다운로드 1000kbps, 업로드 100kbps로 제한됩니다 .

이제 이 질문에 대해서...

이 질문은 아무 관련이 없습니다macvtap(그 tap부분은 OP 설정에도 사용되지 않습니다)macvlan가상화도 아니고tc-netem. 이는 동일한 IP LAN을 사용하여 여러 인터페이스가 동일한 이더넷 LAN에 배치될 때 라우팅이 작동하는 방식과 관련이 있습니다.

가상 머신에서 OP의 특정 구성 없이는 무슨 일이 일어나고 있는지 알 수 있는 방법이 없기 때문에 몇 가지 네트워크 네임스페이스인 "system"에서 인위적인 예를 재현하겠습니다.동료핑 "시스템"듀얼 카드, 둘 다 "스위치"를 통해 연결됨다리.

두 번째 카드를 추가하기 전의 초기 구성:

ip netns del bridge || :
ip netns del twocards || :
ip netns del peer || :
ip netns add bridge
ip netns add twocards
ip netns add peer
ip -n bridge link add bridge0 type bridge
ip -n twocards link add eth0 type veth peer netns bridge name port1
ip -n peer link add eth0 type veth peer netns bridge name port2
ip -n bridge link set port1 master bridge0
ip -n bridge link set port2 master bridge0
ip -n bridge link set port1 up
ip -n bridge link set port2 up
ip -n bridge link set bridge0 up
ip -n twocards link set eth0 up
ip -n peer link set eth0 up
ip -n twocards address add dev eth0 192.0.2.1/24
ip -n peer address add dev eth0 192.0.2.2/24

지금:

# ip -n twocards route
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.1

유비쿼터스 NetworkManager를 사용하는 일반적인 설치에는 일련의 이더넷 장치가 있습니다. metric 100동일한 작업을 수행해 보겠습니다.

ip -n twocards route add 192.0.2.0/24 dev eth0 src 192.0.2.1 metric 100
ip -n twocards route del 192.0.2.0/24 dev eth0 src 192.0.2.1

측정해보자:

# ip netns exec peer ping -c2 192.0.2.1 
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.116 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.060 ms

--- 192.0.2.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1018ms
rtt min/avg/max/mdev = 0.060/0.088/0.116/0.028 ms

결과는 정상입니다. 두 번째 카드를 추가하고 IP를 추가한 다음 netem 대기열을 추가합니다.

ip -n twocards link add eth1 type veth peer netns bridge name port3
ip -n bridge link set port3 master bridge0
ip -n bridge link set port3 up
ip -n twocards link set eth1 up
ip -n twocards address add dev eth1 192.0.2.3/24
ip netns exec twocards tc qdisc add dev eth1 root netem delay 40000

새로운 경로:

# ip -n twocards route
192.0.2.0/24 dev eth1 proto kernel scope link src 192.0.2.3 
192.0.2.0/24 dev eth0 scope link src 192.0.2.1 metric 100

새로운 동작(상속 가정rp_filter설정되었습니다):

# ip netns exec peer ping -c2 192.0.2.1 
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.

--- 192.0.2.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1021ms

무슨 일이에요? 이제 라우팅 및 ARP 동작이 작동합니다.

# ip -n twocards route get 192.0.2.2 from 192.0.2.1
192.0.2.2 from 192.0.2.1 dev eth1 uid 0 
    cache 
# ip -n twocards -br link
lo               DOWN           00:00:00:00:00:00 <LOOPBACK> 
eth0@if3         UP             96:45:4d:f0:52:35 <BROADCAST,MULTICAST,UP,LOWER_UP> 
eth1@if5         UP             c2:70:b7:40:6c:40 <BROADCAST,MULTICAST,UP,LOWER_UP> 

# ip -n peer neighbour
192.0.2.1 dev eth0 lladdr 96:45:4d:f0:52:35 REACHABLE

라우팅 테이블듀얼 카드지금 사용하겠습니다 eth1,심지어그것에 할당된 주소를 위해 eth0. Linux는 단순히 라우팅 테이블의 기본 동작을 따릅니다. 왜냐하면rp_filter부팅 후 장치 eth0(MAC는 여전히동료은닉처). 설정하지 않으면 rp_filter비대칭 라우팅에 작동합니다. 요청 시 핑 eth0, 응답 시 핑 eth1, (지연 netem) 때까지동료ARP 캐시는 결국 만료된 다음 eth1사용됩니다(평소와 같이 송신만 지연됨).

ARP 캐시를 삭제해 보겠습니다.동료그런 다음 다시 시도해 보세요.

# ip -n peer neighbour flush dev eth0
# ip netns exec peer ping -c2 192.0.2.1 
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=80.2 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=40.1 ms

--- 192.0.2.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 40.141/60.178/80.215/20.037 ms

# ip -n peer neighbour
192.0.2.1 dev eth0 lladdr c2:70:b7:40:6c:40 REACHABLE

첫 번째 ping은 netem에 의해 두 번만 지연됩니다. 한 번은 ARP 요청에 대한 기본 ARP 응답이고, 한 번은 실제 ping 응답입니다.

추가 장치에 대한 경로를 제거해 보겠습니다.듀얼 카드ARP 캐시를 다시 지우십시오.동료:

ip -n twocards route del 192.0.2.0/24 dev eth1
ip -n peer neighbour flush dev eth0

다시 정상적인 결과:

# ip netns exec peer ping -c2 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.108 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.050 ms

--- 192.0.2.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.050/0.079/0.108/0.029 ms

마찬가지로 할당된 IP에 대한 핑이 eth1이제 통과됩니다.듀얼 카드지체 없이 eth0:

# ip netns exec peer ping -c2 192.0.2.3
PING 192.0.2.3 (192.0.2.3) 56(84) bytes of data.
64 bytes from 192.0.2.3: icmp_seq=1 ttl=64 time=0.143 ms
64 bytes from 192.0.2.3: icmp_seq=2 ttl=64 time=0.042 ms

--- 192.0.2.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1024ms
rtt min/avg/max/mdev = 0.042/0.092/0.143/0.051 ms

그렇다면 이에 대해 어떻게 해야 할까요? 동일한 시스템의 동일한 이더넷 LAN에서 두 개의 네트워크 장치를 사용하지 마십시오. 특히 동일한 IP LAN을 사용하는 경우 문제가 발생할 수 있습니다. macvlan또는 일반적으로 장치를 macvtap호스트에서 직접 사용해서는 안 됩니다. 자체 독립 라우팅 스택이 있는 VM이나 컨테이너(다른 네트워크 네임스페이스)로 전달되어야 하므로 일반적인 사용에서는 문제가 되지 않습니다.

어떤 이유로 동일한 LAN에 있는 두 개의 카드를 사용해야 하는 경우(본딩, 팀 구성 등 제외), 이러한 상황을 피하기 위해 다소 복잡한 추가 구성을 수행해야 합니다. SF에 대한 내 답변 보기다중 NIC Linux 시스템의 고스트 핑더 알아보기.

답변2

어떤 문제가 있는지 잘 모르겠으므로 건너뛰겠습니다.

프로세스별 트래픽 형태를 조정하려면 클래스별 대기열 규칙을 사용해야 합니다. HTB나 HSFC가 아마도 최선의 선택일 것입니다. 이를 사용하면 대기열 규칙 트리(netem을 리프 중 하나에 연결할 수 있음)를 만들고 트리 사이에 트래픽을 분산할 수 있습니다 tc filter.

필터링 방법은 iptables 태그를 찾기 때문에 필터링은 매우 유연합니다 fw. 즉, iptables를 사용하여 트래픽을 선택할 수 있습니다. 트래픽을 직접 선택할 수도 있습니다.

하지만 qdisc는 나가는 트래픽에서만 작동한다는 점에 유의하세요. 수신 qdisc를 가질 수 있지만 이는 매우 제한적이며 예상대로 작동하지 않을 수 있습니다.

테스트 목적으로 좋은 옵션은 두 개의 인터페이스가 있는 실제 가상 머신을 생성하고 트래픽이 해당 가상 머신을 통해 라우팅되도록 강제하는 것입니다. 몇 가지 트릭(예: 여러 수준의 NAT)이 필요할 수 있습니다. 그런 다음 가상 머신에서 두 인터페이스 모두에 원하는 qdisc를 연결하여 양방향 트래픽 방향을 제어할 수 있습니다.

관련 정보