Linux TC 클래스 / 필터 번호 매기기


12

저는 현재 ISP 수준의 회사를위한 트래픽 쉐이핑 솔루션을 개발 중이며 흥미로운 (철학적 인) 문제에 직면했습니다.

시스템이 처리해야하는 엔드 포인트 수 (약 20k 정도)를 살펴보면 더 많은 사용자의 트래픽을 정책 / 형성해야 할 때 어떤 일이 발생할지 걱정이되었습니다. 현재 전체 네트워크에 대해 HFSC 쉐이핑 트리 (주로 잘 알려진 HTB와 동일하지만 쿨러 인 tc-hfsc 참조)를 사용하고 있으므로 더 많은 ClassID를 사용해야합니다 (분명히 각 사용자마다 하나 이상). 회로망). 내가 찾은 문제는 TC ClassID가 제한적이라는 것입니다 .16 비트 숫자 이므로이 솔루션으로 최대 64k 사용자를 만들 수 있습니다.

마찬가지로 TC 필터를 효율적으로 관리하려면 (예 : '모든 기능 플러시'를 사용하지 않음) 개별 필터 항목을 삭제하거나 수정할 수 있어야합니다. (LARTC [1]의 해시 테이블과 비슷한 것을 사용하고 있습니다). 다시 말하지만, 이것과 함께 작동하는 유일한 방법은 개별 우선 순위 (tc filter add dev ... prio 1)를 사용하여 모든 필터에 번호를 매기는 것입니다. 이 목적으로 사용될 수있는 다른 매개 변수는 없으며, 유감스럽게도 prio는 16 비트 전용입니다.

내 질문은 다음과 같습니다 : 'tc class'명령에 대한 32 비트 clsid 및 'tc 필터'에 대한 32 비트 우선 순위 (또는 다른 수정 핸들)와 같이 사용 가능한 "식별자 공간"을 확대하는 좋은 방법이 있습니까? 명령?

매우 감사합니다,

-mk

(하지만 이것이 "64k 사용자는 모든 사람에게 충분해야 함"시나리오로 가지 않기를 바랍니다 ...)


이러한 모든 값은 커널 공간에 저장되므로 커널 및 사용자 공간 유틸리티를 다시 컴파일해야합니다. 64 비트 커널을 사용해 보셨습니까? 32 비트로 정의 될 수 있습니다.
허버트 카리오

64 비트 커널은 동일한 크기를 사용합니다. 예를 들어, 필터 번호는 분명히 16 비트 인 상위 (프로토콜) 및 하위 (prio)로 구성된 u32 정수입니다. 클래스 ID는 u16으로 하드 코딩됩니다. 아마도 LKML에 누군가에게 물어볼 것입니다.
엑사

1
필터에 해시를 사용하더라도 많은 필터를 사용하면 많은 IO 문제가 발생합니다 (업스트림 및 다운 스트림). 나는 많은 시간을 보냈고 ksoftirqd와 함께 작동하도록 커널 내부의 큐 구현을 패치해야했습니다. 4 년 전에 LARTC에서 만난 Simon Lodal이라는 사람의 패치를 사용했습니다. 그의 패치 mail-archive.com/lartc@mailman.ds9a.nl/msg16279.html을보십시오 . 항상 최신 버전 (마지막 커널에 대해)을 가지고 있기 때문에 전자 메일을 보내려고 시도 할 수 있습니다.
Pabluez

@Pabluez 대단히 감사합니다. 최대한 활용하려고 노력하겠습니다.
엑사

1
귀하의 요구 사항은 유효하지만 Pabluez가 작성한 것처럼 분명히 많은 커널 변경이 필요합니다. "잘못하고있다"고 말하고 싶지 않지만, 패킷 처리의 하위 부분이 스위치 수준에서 수행되고 정책이 사용자 지정 소프트웨어에서 수행되는 오픈 플로우를 확인하는 것이 좋습니다. 사용자 공간에서 실행 중입니다. 그것이 귀하의 요구 사항에 맞는지 모르겠지만 확실히 조사 할 가치가 있습니다.
AndreasM

답변:


2

64k 사용자에게 업스트림 및 다운 스트림 클래스와 필터를 각각 동일한 인터페이스에 두지 않아야한다고 생각합니다. 가지고있는 각 인터페이스에 대해 처리기를 반복 할 수 있으므로 더 많은 인터페이스를 추가하십시오. 이 작업을하려면 놀라운 작업 / 서버 / NIC가 필요합니다. 서버가 충돌하면 64k 명의 사용자가 오프라인 상태가됩니다 (그리고 그 양의 트래픽으로 인해 쉽게 충돌합니다). 네트워크 카드를 통과하는 각 패킷은 필터로 확인 및 분류되어 대기중인 클래스로 전송됩니다. 이것은 64k 고객이있는 ISP 게이트웨이의 NIC에 많은 작업입니다. 현재 우리가 가지고있는 모든 비디오 스트림 (주로 대기열에 들어가기 어렵습니다)을 주로 사용합니다.


다른 수준에서 서비스 가용성을 보장하고 있지만 걱정 해 주셔서 감사합니다. 실제로 좋은 NIC를 사용하면 10Gbits를 전달할 수있는 Linux 라우터를 갖는 것이 어렵지 않습니다.
엑사

원래 질문에 대해서는 각 사용자마다 5 가지 클래스를 추가하는 것과 같은 것에 더 관심이있어서 스트림과 실시간 트래픽을 개별적으로 처리하는 것과 같이 실제로 좋은 QOS 작업을 수행 할 수는 있지만 현재 상태에서는 거의 생각할 수 없습니다. ~ 20k 엔드 포인트의 현재 사용 사례는 이미 한계를 초과했습니다.
엑사

1
좋아, 10Gbits를 전달하는 데 아무런 문제가 없으며 64k * 2 (ups downs) 필터와 클래스가 많이 있습니다. 그래도 행운을 빌어 : D
Pabluez

0

한 시스템의 모든 트래픽을 처리하는 대신 트래픽 처리를 두 번째 시스템 (세 번째 시스템 사용)으로 분할 할 수 있습니다. 트래픽은 단순히 소스 IP 주소를 기반으로 라우팅 될 수 있습니다. 따라서 IP 범위를 균등하게 나눌 수 있으면 최적의 사용자가 10k 명입니다.

물론 필요한 경우 두 대 이상의 컴퓨터를 사용할 수 있습니다. 나는 이것이 리눅스 커널을 패치하고 다른 해킹을하는 것보다 낫다고 생각합니다. 요컨대, 트래픽 조절은 여러 컴퓨터에 배포됩니다. 중앙 노드는 트래픽을 올바른 처리 노드로 전달합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.