저는 현재 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 사용자는 모든 사람에게 충분해야 함”시나리오로 가지 않기를 바랍니다 …)
답변
64k 사용자에게 업스트림 및 다운 스트림 클래스와 필터를 각각 동일한 인터페이스에 두지 않아야한다고 생각합니다. 가지고있는 각 인터페이스에 대해 처리기를 반복 할 수 있으므로 더 많은 인터페이스를 추가하십시오. 이 작업을하려면 놀라운 작업 / 서버 / NIC가 필요합니다. 서버가 충돌하면 64k 명의 사용자가 오프라인 상태가됩니다 (그리고 그 양의 트래픽으로 인해 쉽게 충돌합니다). 네트워크 카드를 통과하는 각 패킷은 필터로 확인 및 분류되어 대기중인 클래스로 전송됩니다. 이것은 64k 고객이있는 ISP 게이트웨이의 NIC에 많은 작업입니다. 현재 우리가 가지고있는 모든 비디오 스트림 (주로 대기열에 들어가기 어렵습니다)을 주로 사용합니다.
답변
한 시스템의 모든 트래픽을 처리하는 대신 트래픽 처리를 두 번째 시스템 (세 번째 시스템 사용)으로 분할 할 수 있습니다. 트래픽은 단순히 소스 IP 주소를 기반으로 라우팅 될 수 있습니다. 따라서 IP 범위를 균등하게 나눌 수 있으면 최적의 사용자가 10k 명입니다.
물론 필요한 경우 두 대 이상의 컴퓨터를 사용할 수 있습니다. 나는 이것이 리눅스 커널을 패치하고 다른 해킹을하는 것보다 낫다고 생각합니다. 요컨대, 트래픽 조절은 여러 컴퓨터에 배포됩니다. 중앙 노드는 트래픽을 올바른 처리 노드로 전달합니다.