3 개의 Windows 2008 R2 상자에 iSCSI 대상을 제공하고 하나의 OpenBSD 5.0 상자에 NFS를 제공하는 새로운 Synology RS3412RPx가 있습니다.
ssh를 사용하여 RS3412에 로그인하고 dd 및 다양한 블록 크기를 사용하여 작은 파일과 6GB 파일을 모두 읽고 쓰는 것은 디스크 I / O 성능이 뛰어납니다.
iSCSI / NFS 클라이언트에서 dd 또는 iometer를 사용하면 최대 20Mbps에 도달합니다 (오타가 아닙니다. 20Mbps). 우리는 Synology의 여러 Gbit NIC를 더 잘 활용하기를 원했습니다.
스위치와 NIC 포트 구성이 자동 협상이 아닌 기가비트로 설정되어 있는지 확인했습니다. 우리는 점보 프레임을 사용하거나 사용하지 않고 시도했습니다. MTU가 현재 9000임을 ping으로 확인했습니다. 두 가지 펌웨어 업그레이드가 배포되었습니다.
스위치 문제를 배제하기 위해 iSCSI 대상과 이니시에이터를 직접 연결하려고하는데 다른 옵션은 무엇입니까?
wireshark / tcpdump를 분리하면 무엇을 찾아야합니까?
답변
여기서 일반적인 주제 인 것처럼 스위치의 흐름 제어 설정을 다시 살펴보십시오. 스위치에 이더넷 카운터 통계가있는 경우 스위치를보고 많은 수의 이더넷 PAUSE 프레임이 있는지 확인하십시오. 그렇다면 그것은 아마도 당신의 문제 일 것입니다. 일반적으로 스위치에서 QOS를 비활성화하면이 문제가 해결됩니다.
답변
그런 흐름은 다양한 TCP 흐름 제어 방법이 제대로 작동하지 않음을 나타냅니다. 비스타 이후 Windows 버전과 통신하는 Linux 커널에서 일부 문제를 보았으며 이와 같은 처리량을 얻습니다. 일단 살펴보면 Wireshark에 꽤 잘 나타나는 경향이 있습니다.
최악의 가능성은 TCP 지연 ack이 완전히 손상되어 다음과 같은 트래픽 패턴이 표시된다는 것입니다.
packet
packet
[ack]
packet
packet
[ack]
NIC 드라이버 업데이트를 Windows 서버에 적용하여 문제를 해결했습니다. 일부 (브로드 콤) 서버와 함께 제공되는 스마트 NIC는 때때로 흥미로운 방식으로 실패 할 수 있으며 이는 하나입니다.
정상적인 트래픽 패턴은 많은 수의 패킷과 Ack 패킷이 뒤 따릅니다.
찾아야 할 또 다른 것은 긴 지연입니다. 의심스러운 값은 0.2 초와 1.0 초입니다. 이는 한쪽이 예상 한 것을 얻지 못하고 응답하기 전에 시간 초과가 만료되기를 기다리고 있음을 나타냅니다. 위의 잘못된 패킷 패턴을 ACK에 대한 200ms 지연과 결합하면 엄청난 1MB / s의 처리량을 얻을 수 있습니다.
이는 알기 쉬운 나쁜 교통 패턴입니다.
나는 그런 종류의 NAS 장치로 작업하지 않았으므로 발견 된 것을 고치는 것이 얼마나 조정 가능한지 모릅니다.