번역. 원본

10GBASE-T 회선의 성능이 6~7Gbps 정도로 포화 되는 경우가 많다. 이유는 MTU(Maximum Transmission Unit)이다.
MTU는 요컨대 최대 프레임 크기로 이 숫자를 넘는 데이터를 전송하는 경우 프레임이 분할된다.
Ethernet에서는 최대 프레임 크기가 1500로 되어 있으므로, 기본적으로 1500Bytes를 벗어나는 데이터는 여러 프레임으로 분할 되어 전송 된다.

원래 이 MTU가 1500로 설정된 것은 IEEE 802.3, 즉 10BASE-2/5 시대의 이야기이다. 정확히 말하면 IEEE 802.3 에서는 MTU는 64~1518Bytes로 정해져 있다.
다만 이 중 18Bytes는 헤더 영역용이므로 데이터로서의 최대치는 1500가 된다.
그 뒤 IEEE 802.1ad(Provider Bridge)용으로 8Bytes 늘리거나 혹은 IEEE 802.1Q(VLAN)용으로 4Bytes 늘리는 등 세세하게 늘어난 규격은 존재하지만 역시 일반적으로는 1500Bytes로 현재에 이르고 있다. 그래서 이 프레임 사이즈로 속도를 올리면 프레임 수가 매우 늘어나고 이것은 오버 헤드 증가로 이어지는 것이 문제가 된다.

사실 이 MTU 크기의 작음은 광 케이블용 GbE 규격인 1000BASE-SX 등에서 처음에 문제가 됐다.
MTU을 1500Bytes로 했을 때에는 처리량이 400Mbps 수준에서 CPU의 부하율이 100%에 달하게 된다.
이유는 다루어야 할 데이터량이 늘면서 CPU의 프레임 처리가 따라가지 못하기 때문이었다.

MTU 크기 변경과 CPU 성능 향상

해결책은 MTU 사이즈를 더 키우고 처리해야 할 프레임 수를 줄이면 된다. MTU의 사이즈를 9000Bytes로 하면 프레임 사이즈를 6배로 늘리면서 스루풋은 600Mbps 이상이 되고, CPU 부하도 55%까지 줄어든다.

그런데 이것이 큰 문제가 되지 않는 것은 급속한 CPU 성능의 향상 덕분이다. 위의 측정 환경이 CPU 클록이 300MHz, OS가 Solaris 2.5.1, 카드는 SBus기반으로 하고 있으며 CPU에 “UltraSPARC IIi”를 탑재한 Sun의 “Ultra 5/Ultra 10” 정도인데 300MHz의 Ultra 10에서는 “SPECint95”가 12.1으로 되어 있다.
비슷한 결과를 찾아보면 Intel의 Pentium II 300MHz가 대체로 이 정도이다.
거칠게 말하면 현재의 CPU는 당시 10배 정도로 고속이다. 이제 1Gbps의 프레임 처리 정도로 CPU 부하가 100%가 될 수 없다. 또, 고기능 LAN 카드 중에는 TCP 오프 로드(프레임 처리를 포함한 TCP 처리의 일부를 하드웨어 측에서 대신하는) 기능을 갖는 것도 있으며 이를 이용하면 또 CPU의 부하가 줄어든다.

10GBASE-T 환경에서 효과적인 “Jumbo Frame”

다만 10GBASE-T가 된다면 이야기는 또 다르다.
전송 속도가 10배라는 것은 프레임 수도 10배가 된다. 결과적으로 프레임 처리가 따라잡지 못하거나 따라가도 CPU 이용률이 매우 높아지는 문제가 다시 출현하게 됐다.
비싼 서버용 10GBASE-T 칩에서는 TCP 오프 로드를 사용하여 처리 부하를 줄일 수 있지만, ASUS XG-C100C 같은 카드에서는 이것도 어려워진다. 이 때문에 MTU을 1500을 넘는 크기로 설정하는 게 효과적이다.

이 1500을 넘는 MTU는 “Jumbo Frame”로 불린다.
실제로는 이 Jumbo Frame에도 몇가지 호칭이나 분류가 있다. 이를 최초로 제창한 것은 Alteon Networks(2000년에 Nortel Networks에 인수되면서 2009년에는 Radware에 매각되는)에서 요컨대 MTU의 사이즈를 1500 이상으로 설정할 수 있도록 하자 “뿐”이다. 이것은 널리 보급되어 최대로 14000~16000 정도의 값을 설정 가능한 것도 있지만 9000 정도가 일반적이다(이 밖에 필자가 본 것 중에서는 7000 나 4000,2500 등도 있었다). 왜 이렇게 값이 제각각인가 하면 표준 규격이 없기 때문이다.

표준화되지 않은 것은 호환성 문제가 나오기 때문이다. 만약 Ethernet의 프레임에 프레임 사이즈를 저장하는 필드가 있으면 그다지 문제 없었을지 모르지만 실제로는 프레임 사이즈를 저장하는 필드는 없기 때문에 종래의 Ethernet 장치는 프레임을 받아들이면 머리부터 순서대로 읽어서 1500바이트를 넘은 곳에 FCS(Frame Check Sequence: 32bit의 CRC 코드)가 저장되어 있지 않은 경우, 이것은 파손된 프레임으로 간주하고 파기하여 종료한다.
즉 Jumbo Frame에 대응하지 않는 기기에서는 Jumbo Frame을 원래 받지 못하는 것이다.

이 문제는 대처할 방법이 없고, IEEE 802.3에서는 Jumbo Frame은 표준화의 대상이 되지 않았다. 그래서 혼재 환경에서 서버와 10GBASE-T 탑재 클라이언트에 Jumbo Frame을 설정하면 1000BASE-T 탑재 클라이언트로부터 10GBASE-T 서버가 보이지 않는다.

더 정확히 말하면 보이는 경우도 있다. 프레임이 1500Bytes 이하면 통신할 수 있기 때문이다. 예를 들어 Windows의 네트워크 기기 목록에서는 서버가 보이고 어쩌면 인증도 통할지 모른다. 하지만 정작 데이터를 전송하려고 하면 타임 아웃이 발생하고 이어지지 못하다는 느낌이다. 그리고 오류를 일으키면 한동안 안 보인다고 하는 이야기이다.

“Jumbo Frame” 설정의 10GBASE-T와 1000BASE-T의 세그먼트를 분할

다른 속도의 네트워크가 혼재한 환경의 예에는 서버와 클라이언트만 제시하고 있지만 실제로는 라우터나 프린터 등 다양한 기기가 연결되어 있으며 이들의 대부분은 1500까지 MTU에만 대응하고 있다. 혹은 Wi-Fi 등으로 연결되는 기기도 마찬가지다. 이들이 전부 연결 되지 않으면 곤란하다.

그럼 어떻게 할까? 가장 간단한 것은 네트워크를 분할하는 것이다.
아래 그림처럼

통상의 MTU와 Jumbo Frame에서 세그먼트를 분할하면 좋다. 기존 네트워크에는 계속해서 MTU을 1500으로 설정한 1000BASE-T에서 접속하고 이와 별도로 새로 10GBASE-T의 네트워크를 추가하는 형태이다. 이 10GBASE-T 쪽은 MTU를 9000 정도의 값으로 설정한다.

이 경우 서버와 10GBASE-T 탑재 클라이언트는 IP 주소를 2개 가지게 되므로 Windows의 네트워크를 사용하면 이름 해결에 좀 귀찮은 경우가 있다(브라우즈 마스터 호스트가 어디에 둘지에 따라서이지만 무조건 1000BASE-T의 IP주소가 지정되어, 10GBASE-T가 이용되지 않는 것을 생각한다.) 이것은 라우팅 테이블의 설정이나 hosts 파일의 추가 등 여러 기법을 빌리면 해결된다. 거꾸로 말하면 이 언저리가 아직 좀 귀찮다는 것이다.