차례

벤치 마크 #

2018년 XNUMX월자 최신 벤치마크에서는 iptables 대신 nftables를 데이터 경로로 사용할 때 성능이 크게 향상되었음을 보여줍니다.

HTTP 로드 스트레스 도구를 실행하는 클라이언트 2개, 로드 밸런서 1개, 백엔드 3개(약 210바이트의 응답을 제공하는 HTTP 터미네이터 포함)로 구성된 테스트베드 환경에서 다음 벤치마크를 얻습니다. 초당 HTTP 흐름:

iptables DNAT 256.864,07 RPS/cpu iptables SNAT 262.088,94 RPS/cpu nftables DNAT 560.976,44 RPS/cpu nftables SNAT 608.941,57 RPS/cpu nftables DSR 7.302.517,31 RPS/cpu

위의 수치는 코어를 추가하는 확장성이 거의 선형이므로 물리적 CPU당 기준으로 표시됩니다. 본 벤치마크는 3개의 백엔드로만 수행되었지만, 백엔드를 추가하면 iptables 성능이 크게 저하됩니다., 이는 보다 순차적인 규칙을 의미하기 때문입니다.

해당 벤치마크는 리트폴린을 비활성화한 상태에서 수행되었지만(Spectre/Meltdown 완화 없음), 일단 활성화되면 iptables 및 nftables 사례 모두에 대해 conntrack이 활성화된 NAT 사례에서 감지된 성능 저하가 첫 번째 사례에서 훨씬 더 나쁩니다.

iptables: 40.77% CPU 페널티 nftables: 17.27% CPU 페널티

성능 키 #

리트폴린 페널티는 nftables보다 iptables에서 훨씬 더 많은 간접 호출을 사용하기 때문에 설명됩니다. 그러나 아래에서 설명할 몇 가지 추가 성능 키도 있습니다.

규칙 최적화 #

주요 성능 핵심은 규칙 최적화입니다. ipset을 사용하면 순차 규칙 처리가 줄어들어 성능이 향상된다는 것은 iptables에서 이미 알려져 있습니다.

nftlb에서는 다른 용도로 확장하여 사용할 수도 있지만 기본적으로 세트 및 맵 사용을 지원하는 표현 언어를 사용하여 가상 서비스별로 기본 규칙을 설정합니다. 아래에서 생성된 규칙을 참조하세요. 01개의 백엔드가 있는 vs2이라는 가상 TCP 서비스:

테이블 IP nftlb { map tcp-services { 유형 ipv4_addr . inet_service : 평결
        요소 = { 192.168.0.100 . http : vs01로 이동 }
    } 체인 사전 라우팅 { 유형 nat 후크 사전 라우팅 우선순위 0; 정책 동의;
        IP 아빠. tcp dport vmap @tcp-서비스
    } 체인 포스트라우팅 { 유형 nat Hook 포스트라우팅 우선순위 100; 정책 동의; }

    chain vs01 { dnat to jhash ip saddr mod 2 map { 0 : 192.168.1.10, 1 : 192.168.1.11 } }
}

새 백엔드를 추가해야 하면 새 규칙을 포함하지 않고 나머지 가상 서비스에 영향을 주지 않고 가상 서비스에 연결된 체인을 다시 생성하기만 하면 됩니다.

    체인 vs01 {
        dnat에서 jhash ip saddr mod 3 map { 0 : 192.168.1.10, 1 : 192.168.1.11, 2 : 192.168.1.12 }
    }

그러다가 새로운 가상 서비스가 생기면 vs02 생성해야 하는 경우 규칙 세트는 새 규칙을 추가하거나 다른 가상 서비스에 영향을 주지 않고 아래와 같이 됩니다.

테이블 IP nftlb { map tcp-services { 유형 ipv4_addr . inet_service : 평결 요소 = { 192.168.0.100 . http : vs01로 이동,
                     192.168.0.102 . https : vs02로 이동 } } 체인 사전 라우팅 { type nat Hook 사전 라우팅 우선 순위 0; 정책 동의; IP 아빠. tcp dport vmap @tcp-services } chain postrouting { type nat Hook postrouting Priority 100; 정책 동의; } chain vs01 { dnat to jhash ip saddr mod 3 map { 0 : 192.168.1.10, 1 : 192.168.1.11, 2 : 192.168.1.12 } }

    chain vs02 { dnat to jhash ip saddr mod 2 map { 0 : 192.168.2.10, 1 : 192.168.2.11 } }
}

초기 후크 #

nftables는 초기 사용을 허용합니다 인그레스 후크 이는 DSR 시나리오 중에 nftlb에서 사용됩니다.

또한 이 초기 후크는 패킷 삭제 시 성능을 향상시키는 필터링 목적으로 사용될 수 있습니다. 이는 초당 패킷 수로 표시되는 iptables 및 nftables 사례의 가장 초기 단계와 함께 아래에 표시됩니다.

iptables 사전 라우팅 원시 드롭: 38.949.054,35 PPS/코어 nftables 수신 드롭: 45.743.628,64 PPS/코어

가속 기술 #

nftables는 이미 패킷 맹글링에 사용할 수 있는 빠른 경로와 경량 기술을 지원하므로 최적화할 여지가 더 많습니다. 그 예는 다음과 같습니다.

흐름표. 전체 느린 경로를 통과하지 않고 이미 설정된 연결을 수신 단계에 위임하기 위한 Conntrack 빠른 경로입니다. 여기에 대한 자세한 정보.

무상태 NAT. 일부 부하 분산 사례의 경우 연결 추적 없이 수신 단계에서 상태 비저장 NAT를 수행하여 NAT 시나리오에 적용되는 모든 성능을 얻을 수 있습니다.

nftlb 벤치마크 및 성능 키