У нас есть новый Synology RS3412RPxs, который предлагает цели iSCSI для трех устройств Windows 2008 R2 и NFS для одного модуля OpenBSD 5.0.
Вход в RS3412 с помощью ssh и чтение / запись небольших файлов и файлов размером 6 ГБ с использованием dd и различных размеров блоков показывают отличную производительность дискового ввода-вывода.
Используя dd или iometer на клиентах iSCSI / NFS, мы достигаем скорости до 20 Мбит / с (это не опечатка. Двадцать Мбит / с). Мы как бы надеялись лучше использовать несколько гигабитных сетевых карт в Synology.
Я проверил коммутатор, и для конфигурации порта сетевой карты установлено значение гигабит, а не автосогласование. Мы пробовали с Jumboframes и без, без разницы. Я проверил с помощью ping, что MTU в настоящее время составляет 9000. Было развернуто два обновления прошивки.
Я собираюсь попробовать прямую связь между целью iSCSI и инициатором, чтобы исключить проблемы с переключателем, но каковы другие варианты?
Если я разорву wirehark / tcpdump, что мне искать?
Как кажется, это общая тема здесь, еще раз взгляните на настройки управления потоком на переключателе (-ах). Если у коммутатора (-ов) есть статистика счетчиков Ethernet, посмотрите на них и проверьте, есть ли большое количество кадров Ethernet PAUSE. Если да, то это, вероятно, ваша проблема. В общем, отключение QOS на переключателе (-ах) решает эту проблему.
Подобные потоки подсказывают мне, что различные методы управления потоком TCP работают неправильно. Я видел некоторые проблемы с ядрами Linux, связанными с версиями Windows после Vista, и вы получаете такую производительность. Как правило, они довольно хорошо отображаются в Wireshark, если вы посмотрите.
Абсолютно худшая возможность заключается в том, что отложенное подтверждение TCP полностью сломано, и вы увидите схему трафика, которая выглядит так:
packet
packet
[ack]
packet
packet
[ack]
Я решил эту проблему, применив обновления драйверов сетевой карты к серверам Windows. Интеллектуальные сетевые адаптеры, которые поставляются с некоторыми (Broadcom) серверами, иногда могут выходить из строя интересным образом, и это один из них.
Обычный образец трафика - это большое количество пакетов, за которыми следует пакет Ack.
Еще нужно обратить внимание на длительные задержки. Подозрительные значения: 0,2 секунды и 1,0 секунды. Это говорит о том, что одна сторона не получает того, чего ожидает, и ожидает истечения тайм-аута, прежде чем ответить. Объедините вышеупомянутый шаблон плохого пакета с задержкой 200 мс для ACK, и вы получите колоссальную пропускную способность 1 МБ / с.
Это легко заметить плохие модели трафика.
Я не работал с такими устройствами NAS, поэтому не знаю, насколько они настраиваются, чтобы исправить все, что было найдено.