레이어 3 LACP 대상 주소 해싱은 어떻게 정확하고 구체적으로 작동합니까?

1 년 전의 초기 질문 ( 멀티플렉싱 된 1 Gbps 이더넷? )을 기반으로 LACP 링크가있는 새로운 ISP가있는 새로운 랙을 설치했습니다. 인터넷을 통해 1Gbps 이상의 누적으로 수천 대의 클라이언트 컴퓨터를 지원하는 개별 서버 (하나의 응용 프로그램, 하나의 IP)가 있기 때문에 이것이 필요합니다.

이 LACP 아이디어는 10GoE 스위치 및 NIC에 많은 비용을 들이지 않고 1Gbps 장벽을 무너 뜨릴 것으로 예상됩니다. 불행히도 아웃 바운드 트래픽 배포와 관련된 몇 가지 문제가 있습니다. (위의 링크 된 질문에서 Kevin Kuphal의 경고에도 불구하고)

ISP의 라우터는 일종의 Cisco입니다. (MAC 주소에서 추론했습니다.) 내 스위치는 HP ProCurve 2510G-24입니다. 그리고 서버는 Debian Lenny를 실행하는 HP DL 380 G5입니다. 한 서버는 핫 대기입니다. 애플리케이션을 클러스터링 할 수 없습니다. 다음은 IP, MAC 및 인터페이스가있는 모든 관련 네트워크 노드를 포함하는 단순화 된 네트워크 다이어그램입니다.

그것은 모든 세부 사항을 가지고 있지만 내 문제를 다루고 설명하기가 약간 어렵습니다. 간단하게하기 위해 여기에 노드와 물리적 링크로 축소 된 네트워크 다이어그램이 있습니다.

그래서 나는 새 랙에 키트를 설치하고 설치하고 ISP의 케이블을 라우터에서 연결했습니다. 두 서버 모두 내 스위치에 대한 LACP 링크가 있고 스위치에는 ISP 라우터에 대한 LACP 링크가 있습니다. 처음부터 LACP 구성이 올바르지 않다는 것을 깨달았습니다. 테스트 결과 각 서버로의 모든 트래픽이 서버 간 스위치와 스위치 간 라우터간에 하나의 물리적 GoE 링크를 통해 진행되고있는 것으로 나타났습니다.

리눅스 NIC 본딩에 관한 구글 검색과 많은 RTMF 시간으로 수정을 통해 NIC 본딩을 제어 할 수 있음을 발견했습니다. /etc/modules

# /etc/modules: kernel modules to load at boot time.
# mode=4 is for lacp
# xmit_hash_policy=1 means to use layer3+4(TCP/IP src/dst) & not default layer2 
bonding mode=4 miimon=100 max_bonds=2 xmit_hash_policy=1

loop

이로 인해 트래픽이 예상대로 두 NIC를 통해 서버를 떠나게되었습니다. 그러나 트래픽은 여전히 하나의 물리적 링크를 통해 스위치에서 라우터로 이동하고있었습니다 .

두 물리적 링크를 통과하는 트래픽이 필요합니다. 2510G-24의 관리 및 구성 안내서를 읽고 다시 읽은 후 다음을 발견했습니다.

[LACP는] 트렁크 링크를 통해 아웃 바운드 트래픽을 분산시키기 위해 SA / DA (Source-Destination Address Pair)를 사용합니다. SA / DA (소스 주소 / 대상 주소)는 스위치가 소스 / 대상 주소 쌍을 기반으로 트렁크 그룹 내의 링크에 아웃 바운드 트래픽을 분산시킵니다. 즉, 스위치는 동일한 트렁크 링크를 통해 동일한 소스 주소에서 동일한 대상 주소로 트래픽을 보내고 다른 경로를 통해 동일한 소스 주소에서 다른 대상 주소로 트래픽을 보냅니다. 트렁크의 링크.

본딩 된 링크는 하나의 MAC 주소 만 제공하는 것으로 보이므로 스위치에서 하나의 MAC (두 개가 아닌 두 개가 아닌)을 볼 수 있기 때문에 서버-라우터 경로는 항상 스위치 간에서 한 경로를 넘을 것입니다. 각 LACP의 링크에 대해).

알았다. 그러나 이것이 내가 원하는 것입니다 :

더 비싼 HP ProCurve 스위치는 2910al이 해시에서 레벨 3 소스 및 대상 주소를 사용한다는 것입니다. ProCurve 2910al 관리 및 구성 안내서 의 "트렁크 링크를 통한 아웃 바운드 트래픽 분배"섹션에서 :

트렁크를 통한 트래픽의 실제 분포는 소스 주소 및 대상 주소의 비트를 사용한 계산에 따라 다릅니다. IP 주소를 사용할 수있는 경우 계산에는 IP 소스 주소와 IP 대상 주소의 마지막 5 비트가 포함되며 그렇지 않은 경우 MAC 주소가 사용됩니다.

승인. 따라서 원하는 방식으로 작동하려면 소스 주소가 고정되어 있기 때문에 대상 주소가 핵심입니다. 이것은 내 질문으로 이어진다.

레이어 3 LACP 해싱은 어떻게 정확하고 구체적으로 작동합니까?

어떤 목적지 주소가 사용되는지 알아야합니다.

• 클라이언트의 IP , 최종 목적지?
• 또는 다음 물리적 링크 전송 목적지 인 라우터의 IP

아직 교체 스위치를 구입하지 않았습니다. 레이어 3 LACP 대상 주소 해싱이 필요한지 아닌지를 정확하게 이해하도록 도와주세요. 다른 쓸모없는 스위치를 구입하는 것은 옵션이 아닙니다.

찾고있는 것을 일반적으로 "전송 해시 정책"또는 "전송 해시 알고리즘"이라고합니다. 프레임을 전송하는 집합 포트 그룹에서 포트 선택을 제어합니다.

802.3ad 표준에 손을 대는 것은 돈을 쓰려고하지 않기 때문에 어려운 것으로 판명되었습니다. 내가 말했듯이, 나는 당신이 찾고있는 것에 약간의 빛을 비추는 준 공식 출처에서 정보를 얻을 수있었습니다. 당 2007 오타와에서이 프레 젠 테이션, ON, CA IEEE 고속 연구 그룹 회의 802.3ad를 표준은 "프레임 유통"에 대한 특정 알고리즘을 강제하지 않습니다

이 표준은 특정 배포 알고리즘을 요구하지 않습니다. 그러나 모든 배포 알고리즘은 43.2.3에 규정 된 프레임 수집기에 의해 프레임이 수신 될 때 알고리즘이 a) 주어진 대화의 일부인 프레임의 오정렬 또는 b) 프레임의 복제를 유발하지 않아야한다. . 프레임 순서를 유지하기위한 상기 요건은 주어진 대화를 구성하는 모든 프레임이 MAC 클라이언트에 의해 생성 된 순서대로 단일 링크를 통해 전송되도록 보장함으로써 충족된다; 따라서,이 요구 사항은 프레임을 재정렬하기 위해 MAC 프레임에 정보를 추가 (또는 수정)하거나 대응하는 프레임 콜렉터 부분에 대한 버퍼링 또는 처리를 포함하지 않습니다.

따라서 스위치 / NIC 드라이버가 전송 된 프레임을 배포하는 데 사용하는 알고리즘은 해당 프레젠테이션 (아마도 표준에서 인용)에 명시된 요구 사항을 준수해야합니다. 지정된 특정 알고리즘이 없으며 준수 동작 만 정의됩니다.

지정된 알고리즘이 없지만 특정 알고리즘이 작동하는 방식을 파악하기 위해 특정 구현을 살펴볼 수 있습니다. 예를 들어, Linux 커널 "본딩"드라이버에는 기능을 적용하는 802.3ad 호환 전송 해시 정책이 있습니다 (커널 소스의 Documentation \ networking 디렉토리에있는 bond.txt 참조).

Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF) 
    XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>

이로 인해 소스 및 대상 IP 주소와 소스 및 대상 MAC 주소가 모두 포트 선택에 영향을줍니다.

이 유형의 해싱에 사용 된 대상 IP 주소는 프레임에있는 주소입니다. 그것에 대해 잠시 생각하십시오. 서버에서 인터넷으로 떨어진 이더넷 프레임 헤더에있는 라우터의 IP 주소는 이러한 프레임의 어느 곳에도 캡슐화되지 않습니다. 라우터의 MAC 주소 는 이러한 프레임의 헤더에 있지만 라우터의 IP 주소는 없습니다. 프레임의 페이로드에 캡슐화 된 대상 IP 주소는 서버에 요청하는 인터넷 클라이언트의 주소입니다.

다양한 클라이언트 풀이 있다고 가정 할 때 소스 및 대상 IP 주소를 모두 고려하는 전송 해시 정책은 매우 적합합니다. 일반적으로, 이러한 통합 된 인프라를 통해 흐르는 트래픽에서보다 광범위하게 다양한 소스 및 / 또는 대상 IP 주소는 계층 3 기반 전송 해시 정책이 사용될 때보다 효율적인 집계를 초래합니다.

다이어그램은 인터넷에서 서버로 직접 들어오는 요청을 보여 주지만 프록시가 상황에 대해 수행 할 수있는 작업을 지적 할 가치가 있습니다. 클라이언트 요청을 서버에 프록시하는 경우 chris가 답변에서 말한 것처럼 병목 현상이 발생할 수 있습니다. 해당 프록시가 인터넷 클라이언트의 IP 주소 대신 자체 소스 IP 주소에서 요청하는 경우 엄격하게 계층 3 기반 전송 해시 정책에서 가능한 "흐름"이 줄어 듭니다.

전송 해시 정책은 802.3ad 표준의 요구 사항을 유지하는 한 계층 4 정보 (TCP / UDP 포트 번호)도 고려할 수 있습니다. 이러한 알고리즘은 질문에서 참조 할 때 Linux 커널에 있습니다. 해당 알고리즘에 대한 설명서는 조각화로 인해 트래픽이 반드시 동일한 경로를 따라 흐를 수있는 것은 아니며 알고리즘이 엄격하게 802.3ad 호환되지 않는다는 것을 경고합니다.

매우 놀랍게도 며칠 전 테스트에서 xmit_hash_policy = layer3 + 4는 직접 연결된 두 Linux 서버간에 아무런 영향을 미치지 않으며 모든 트래픽은 하나의 포트를 사용합니다. 둘 다 결합 장치를 멤버로하는 1 개의 브리지로 xen을 실행합니다. 가장 중요한 것은 브리지가 문제를 일으킬 수 있다는 것입니다. 단지 ip + port 기반 해싱을 사용한다는 점을 고려하면 전혀 의미가 없습니다.

일부 사람들은 실제로 본드 링크 (예 : ceph 사용자)를 통해 180MB 이상을 푸시 할 수 있으므로 일반적으로 작동합니다. 살펴볼 수있는 것들 :-우리는 오래된 CentOS 5.4를 사용했습니다.-OPs 예제는 두 번째 LACP가 연결을 "해체"한다는 의미입니다.

이 스레드 및 문서 읽기 등이 나에게 보여준 것 :

• 일반적으로 모든 사람은 이것에 대해 많은 것을 알고 있으며, 본딩 방법 또는 IEEE 표준에서 이론을 인용하는 데 능숙하지만 실제 경험은 거의 없습니다.
• RHEL 설명서가 완전하지 않습니다.
• 본딩 문서는 2001 년부터 현재 상태가 아닙니다.
• layer2 + 3 모드는 CentOS에없는 것 같습니다 (modinfo에 표시되지 않으며 테스트에서 활성화되면 모든 트래픽을 삭제했습니다)
• SUSE (BONDING_MODULE_OPTS), 데비안 (-o bondXX) 및 RedHat (BONDING_OPTS) 모두 본드 별 모드 설정을 지정하는 방법이 서로 다릅니다.
• CentOS / RHEL5 커널 모듈은 "SMP 안전"이지만 "SMP 가능"기능이 아닙니다 (페이스 북 고성능 대화 참조). 하나의 CPU 이상으로 확장되지 않으므로 더 높은 CPU 클럭 본딩> 많은 코어

경우 사람이 좋은 고성능 본딩 설정을 종료하거나, 정말 그들이 LACP, 아니 이상한 물건과 대역폭을 사용 ONE 작업 예를 문서화 새로운 작은 하우투를 작성 시간 반 걸렸다 경우 좋지 않을까 무슨 말을하는지 알고 > 하나의 링크

스위치에 실제 L3 대상이 표시되면 해시 할 수 있습니다. 기본적으로 2 개의 링크가있는 경우 링크 1은 홀수 번호 목적지, 링크 2는 짝수 번호 목적지라고 생각하십시오. 그렇게 구성하지 않는 한 다음 홉 IP를 사용한다고 생각하지는 않지만 대상의 MAC 주소를 사용하는 것과 거의 같습니다.

문제는 트래픽에 따라 대상이 항상 단일 서버의 단일 IP 주소이므로 다른 링크를 사용하지 않는다는 것입니다. 대상이 인터넷의 원격 시스템 인 경우 배포가 가능하지만 시스템이 대상 주소 인 웹 서버와 같은 경우 스위치는 항상 사용 가능한 링크 중 하나를 통해 트래픽을 보냅니다.

어딘가에로드 밸런서가있는 경우 "원격"IP가 항상로드 밸런서의 IP 또는 서버이기 때문에 상태가 더 나빠질 수 있습니다. 로드 밸런서와 서버에서 많은 IP 주소를 사용하면 문제를 해결할 수 있지만 이는 해킹입니다.

공급 업체의 지평을 조금 넓힐 수 있습니다. 익스트림 네트워크와 같은 다른 공급 업체는 다음과 같은 것을 해시 할 수 있습니다.

L3_L4 알고리즘 — 레이어 3 및 레이어 4, 소스 및 대상 IP 주소와 소스 및 대상 TCP 및 UDP 포트 번호가 결합되었습니다. SummitStack 및 Summit X250e, X450a, X450e 및 X650 시리즈 스위치에서 사용 가능합니다.

따라서 기본적으로 클라이언트의 소스 포트 (일반적으로 많이 변경됨)가 변경되는 한 트래픽을 고르게 분산시킵니다. 다른 벤더들도 비슷한 기능을 가지고 있다고 확신합니다.

믹스에로드 밸런서가없는 한 소스 및 대상 IP의 해싱만으로도 핫스팟을 피할 수 있습니다.

라우터가 아닌 클라이언트 IP에서 벗어난 것 같습니다. 실제 소스 및 대상 IP는 패킷에서 고정 된 오프셋에 있으며 해싱을 빠르게 수행 할 수 있습니다. 라우터 IP를 해싱하려면 MAC을 기반으로 한 조회가 필요합니다.

방금 여기 다시 돌아 왔으므로 지금까지 배운 것들 : 회색 머리를 피하려면 layer3 + 4 정책을 지원하는 적절한 스위치가 필요하며 Linux에서도 마찬가지입니다.

대부분의 경우 ALB / SLB (mode6)라는 표준 변형 블로 토치가 더 잘 작동 할 수 있습니다. 작동 적으로 그것은 짜증납니다.

나는 종종 두 인접 시스템 사이의 대역폭을 원하기 때문에 가능한 경우 3 + 4를 사용하려고합니다.

또한 OpenVSwitch를 사용해 보았으며 트래픽 흐름을 방해하는 인스턴스가있었습니다.