![OpenNebula(KVM) + OpenvSwitch, 높은 대역폭 사용 시 높은 CPU 부하](https://rvso.com/image/697403/OpenNebula(KVM)%20%2B%20OpenvSwitch%2C%20%EB%86%92%EC%9D%80%20%EB%8C%80%EC%97%AD%ED%8F%AD%20%EC%82%AC%EC%9A%A9%20%EC%8B%9C%20%EB%86%92%EC%9D%80%20CPU%20%EB%B6%80%ED%95%98.png)
우리는 가상 인터페이스를 연결하기 위해 OpenvSwitch 2.5를 사용하고 완벽하게 작동하는 2개의 Gbit 포트를 LACP 트렁킹하여 Ubuntu 16.04에서 OpenNebula 5.0.2 환경을 실행하고 있습니다.
그러나 VM과 해당 호스트 간에 iperf3 대역폭 테스트를 실행하면 htop은 해당 VM을 실행하는 qemu에 대해 100% CPU 로드를 표시하고 iperf3는 실행 중인 높은 대역폭을 요구하는 다른 VM이 없음에도 불구하고 100~200Mbps만 얻습니다. 두 VM 호스트 사이의 iperf3은 거의 1Gbps를 달성하고 CPU 로드는 없습니다.
2.0.2를 사용 중이었을 때는 이것이 OpenvSwitch 문제라고 믿었지만 지금은 일부 가상 네트워킹 최적화가 누락된 것 같습니다...
답변1
가상 브리지를 통과해야 하는 모든 것은 꽤 큰 타격을 입을 것입니다. 이는 ovs와 Linux 브리징에도 해당됩니다. 둘 다 무차별 모드에서 패킷 검사를 수행하여 사물이 어디로 가야 하는지 결정해야 하기 때문입니다(기본적으로 레이어 2 스위치).
10Gib 이더넷과 같은 고성능 시나리오에서는 호스트 OS가 레이어 2에서 전환되도록 하는 대신 srv-io 장치 통과를 수행하는 것이 현명한 경우가 있습니다. 이는 이 한 게스트만 전달된 이더넷을 사용할 수 있다는 단점이 있습니다. 카드. PCI 패스스루는 네트워크 카드에서 매우 잘 작동하며 KVM/libvirt는 이 점에서 탁월합니다.
Macvtap은 또한 오버헤드가 거의 없고 srv-io PCI 패스스루를 사용하지 않고도 트래픽을 게스트 VM에 직접 전달할 수 있습니다(따라서 하드웨어를 단일 VM에 전용으로 지정할 필요가 없습니다). Macvtap은 호스트-게스트 통신 또는 심지어 동일한 하이퍼바이저 내 게스트-게스트 통신을 제공할 수 없다는 점에서 제한됩니다(가상 스위치를 통해 각 게스트마다 다른 MAC 주소를 사용하는 대신 호스트의 동일한 MAC 주소를 사용하기 때문). ). 이 문제를 해결하는 한 가지 방법은 스위치 수준에서 "헤어핀 설정"을 수행하여(스위치가 지원하는 경우) 장치가 단일 포트 및 단일 MAC 주소에서 일종의 루프백을 통해 자체 통신할 수 있도록 하는 것입니다.
위에서 언급한 방법 중 하나를 사용할 때 호스트와 게스트 상호 통신의 경우 고성능 통신에 사용되지 않는 네트워크에 대해서만 추가 브리지 네트워크를 제공하는 것이 일반적입니다. 이는 실제로 VM에서 10Gib 이상의 이더넷을 사용할 때 매우 일반적인 구성입니다.
답변2
성공적으로(NIC 등을 교환하지 않고도 쉽게) 적용할 수 있었던 대규모 최적화 중 하나는 설명된 대로 VM 템플릿의 모든 NIC 또는 각 NIC에 대해 기본적으로 virtio 모델을 사용하는 것이었습니다.여기:
NIC_DEFAULT = [
MODEL = "virtio" ]
이미 인스턴스화된 VM의 경우 종료하고 모든 NIC를 분리한 후 "virtio" 모델을 사용하여 다시 연결합니다.
첫 번째 테스트에서는 호스트와 게스트 간 iperf3 대역폭을 5.6Gbps로 늘렸고 테스트 중에 호스트 CPU 로드를 qemu 스레드당 ~ 50-60%로 줄였습니다(Gbit 연결 호스트에서 iperf3 클라이언트를 실행하는 경우 < 5% @ 거의 1Gbps).
추가 최적화에 대해 알고 계시다면 자유롭게 추가해 주세요!