VM-1 on host-1 <[cable]> network router <[cable]> host-2 with VM-2
올바르게 이해했다면 VM-1의 애플리케이션에서 VM-2의 동일한 애플리케이션으로 파일을 전송하는 경우 데이터는 다음과 같은 과정을 거치게 됩니다.
- VM-1 애플리케이션 파일을 메모리 버퍼로 읽습니다.
- 프로그래밍 언어 관련 호출
- 운영 체제 수준 호출
- seccomp/apparmor 로직
- 파일 시스템 권한 논리
- 운영 체제 파일 처리 및 버퍼
- 네트워크 소켓 버퍼로 전송된 VM-1 애플리케이션 데이터
- 운영 체제 호출
- seccomp/apparmor 로직
- VM-1 운영 체제 네트워크 스택
- 라우팅 테이블
- 방화벽 논리
- 호스트-1 하이퍼바이저 가상 네트워크 스택
- 가상 스위치
- 라우팅 테이블
- 호스트-1 운영 체제 네트워크 스택
- 라우팅 테이블
- 방화벽 논리
- 호스트-1 물리적 네트워크 카드 버퍼
- 네트워크 라우터
- 미러링된 항목의 거의 동일한 스택이 호스트-2의 VM-2에 대해 여기에 있습니다.
파일이 크다고 가정하면 이미 열려 있고 전송 중인 파일에 대해 seccomp/apparmor, 라우팅 및 방화벽과 관련된 단계가 캐시/생략됩니다.
그러나 1-2 tcp 패킷에 들어갈 만큼 작은 메시지가 있는 가상 머신 간의 빈번한 통신의 경우 문제가 발생합니다.
모든 호출 및 논리 처리에는 수백 개의 CPU 틱이 필요하며 설명된 오버스택은 CPU에 상당한 부하를 가하고 대기 시간에 중요한 역할을 합니다.
- 에 따라Docker 다중 호스트 네트워크 성능 테스트 [2016년 8월]성능이 최소 -13%입니다.
- ~ 안에VMware vSphere® 5의 네트워크 I/O 지연 시간"유휴 시스템에서 VM당 왕복 대기 시간 오버헤드가 약 15~20마이크로초라는 것을 발견했습니다. 이 수치는 vSphere의 리소스 경합이 증가함에 따라 증가하며 이는 예상되는 것입니다. 시스템이 오버 커밋되지 않는 한 지터는 매우 낮았습니다. .
- 또한 Meltdown 및 Spectre Intel 수정으로 인해 성능이 더욱 저하될 수 있습니다.
질문
- VM 간에 미리 열린 통신 소켓이 설명된 목록의 모든 단계를 생략합니까?
- 하다SDN어떻게든 이러한 문제를 완화할 수 있습니까? 아니면 패킷에 더 많은 오버레이와 추가 헤더를 추가합니까?
- VM-1과 VM-2 간의 통신을 위해 설명된 프로세스가 정말로 필요합니까, 아니면 특별한 Linux "보안 수준이 낮고 성능이 높으며 위험에 따라 사용" 빌드가 있습니까?
- 꼭 리눅스만 사용해야 합니까? 도커를 지원하는 더 빠른 *BSD 유사 시스템이 있습니까?
- 결과적으로 동일한 호스트에 마이크로 서비스가 포함된 더 많은 VM을 수용하기 위해 병목 현상을 완화하는 모범 사례는 무엇입니까?
- 다음과 같은 솔루션을 수행하십시오.프로젝트 칼리코도움이 필요합니까 아니면 더 낮은 수준에 관한 것입니까?
답변1
VM 간에 미리 열린 통신 소켓이 설명된 목록의 모든 단계를 생략합니까?
VM/컨테이너 사이에 미리 열린 소켓은 TCP 핸드셰이크 오버헤드로 인해 트릭을 수행합니다. TLS가 있는 경우에는 더욱 그렇습니다.
핸드셰이크 오버헤드는 무시할 수 있을 정도로 작은 것으로 받아들여지지만, 빈번한 통신에 대해 말하면 중요한 역할을 하기 시작합니다.
메시형 컨테이너 네트워크의 경우 M x N 열린 연결의 경계 상태를 갖는 것은 그다지 현명하지 않습니다. 자체 컨테이너 통신 통계를 기반으로 하는 TTL을 사용하는 간단한 연결 유지 솔루션이 더 좋습니다.
TCP 연결을 유지하는 스레드가 너무 많으면 또 다른 오버헤드가 발생하므로 epoll을 사용해야 합니다.
SDN은 이러한 문제를 어떻게든 완화합니까, 아니면 패킷에 더 많은 오버레이와 추가 헤더를 추가합니까?
더 많은 오버레이를 추가하고 많은 오버레이가 공급업체에 의해 잠겨 있지만 적어도 하나는 있습니다.배관 SDNDocker 환경에 대한 관련 솔루션은 아래에 설명되어 있습니다.
VM-1과 VM-2 간의 통신을 위해 설명된 프로세스가 정말로 필요합니까, 아니면 특별한 Linux "보안 수준이 낮고 성능이 높으며 위험에 따라 사용" 빌드가 있습니까?
충분히 신뢰할 수 있는 커뮤니티와 업데이트 지원을 갖춘 "특별한" Linux 빌드를 찾지 못했지만 느린 Linux TCP 스택 문제는 새로운 것이 아니며 커널 우회를 위한 많은 옵션이 있습니다.Cloudflare는 그렇게 합니다.
에서내가 찾은 기사, 느린 Linux TCP 스택은 잘 알려져 있으며 Linux 서버를 드롭인하여 승리할 수 있는 옵션은 없습니다. 매번 이런 식으로 문제를 해결하려면 Torvald의 자식을 미세 조정해야 합니다.
꼭 리눅스만 사용해야 합니까? 도커를 지원하는 더 빠른 *BSD 유사 시스템이 있습니까?
Windows, MacOS 또는 *BSD와 유사한 시스템이 커널 우회가 적용된 느린 TCP 스택을 사용하여 최신 Linux보다 네트워킹이 더 나은 증거를 찾지 못했습니다.
결과적으로 동일한 호스트에 마이크로 서비스가 포함된 더 많은 VM을 수용하기 위해 병목 현상을 완화하는 모범 사례는 무엇입니까?
따라서 게스트 Linux와 호스트 Linux라는 두 가지 병목 현상이 있습니다.
호스트 Linux의 경우 컨테이너 호스팅에만 사용되는 것이 아닌 경우 설명된 다양한 옵션을 갖춘 커널 우회 전략이 있습니다.Cloudflare 블로그그리고"우리는 왜 Linux 커널의 TCP 스택을 사용합니까?" 기사자신만의 애플리케이션 중심 TCP 스택을 작성하는 것입니다.
게스트 리눅스의 경우맥블란레이어 3을 우회하고 자체 MAC 주소를 사용하여 도커 컨테이너를 NIC에 직접 연결하는 데 사용될 수 있습니다. 그것은브릿지보다 훨씬 낫네요, 이는 게스트 및 호스트 Linux 네트워크 병목 현상을 많이 완화하기 때문입니다. 하지만 라우터 MAC 주소 테이블을 또 다른 수백 또는 수천 개의 레코드로 폭발시킬 준비가 되어 있는지 확인하십시오. 대부분 네트워크를 분할해야 할 가능성이 높습니다.
또한 다음과 같이가상 스위칭 기술 및 Linux 브리지 프레젠테이션Macvlan보다 훨씬 더 나은 SR-IOV 옵션이 있습니다. 그것은Mellanox 이더넷 어댑터용 docker 1.9+에서 사용 가능플러그인으로, 모드로 포함됨배관 SDN, 헌신했다Clear Containers의 SRIOV 플러그인- 애플리케이션 중심 솔루션 발굴을 시작하기에 충분합니다.
Project Calico와 같은 솔루션이 도움이 됩니까, 아니면 더 낮은 수준에 관한 것입니까?
이는 완전히 다른 수준이며 SRIOV 및 Macvlan과 비교할 때 큰 영향을 미치지 않지만 선택하는 바이패스 솔루션 외에 오버헤드가 거의 없이 네트워크 관리를 단순화하는 데 도움이 됩니다.
그리고 그렇습니다...
예상치 못한 일이 발생할 수 있으므로 Docker를 면밀히 모니터링하세요. 예를 들어 Macvlan을 켤 이유가 없는 modprobe nf_nat및 를 사용하면 추가 CPU 틱 소비가 발생합니다.xt_conntrack