Недавно мы модернизировали удаленный узел с оптоволоконного канала 10/10 Мбит / с до оптоволоконного канала 20/20 Мбит / с (это волокно до подвала, затем VDSL от подвала до офиса, примерно 30 метров). Между этим сайтом и центральным сайтом регулярно располагаются большие (несколько гигабайт) копии файлов, поэтому теория заключалась в том, что увеличение ссылки до 20/20 должно примерно вдвое сократить время передачи.
Для передач для копирования файлов (например, использование robocopyдля копирования файлов в любом направлении или репликация Veeam Backup and Recovery) они ограничены скоростью 10 Мбит / с.
Перед обновлением:
После обновления ( robocopy):
Практически идентичны (не учитывать разницу во времени передачи).
Передача осуществляется через туннель IPSec между Cisco ASA5520 и Mikrotik RB2011UiAS-RM .
Первые мысли:
- QoS - нет. Есть правила QoS, но ни одно из них не должно влиять на этот поток. Я отключил все правила на несколько минут, чтобы проверить, и без изменений
- Программно-определенные ограничения. Большая часть этого трафика приходится на Veeam Backup and Recovery, отправляемый за пределы сайта, но там нет никаких ограничений. Кроме того, я просто сделал стрит
robocopyи увидел точно такую же статистику. - Оборудование не в состоянии. Что ж, опубликованные показатели производительности 5520 - это 225 Мбит / с данных 3DES, а Mikrotik не публикует цифры, но их скорость будет более 10 Мбит / с. При выполнении этих тестов переноса Mikrotik использует процессор примерно на 25% -33%. (Кроме того, передача HTTP через туннель IPSec достигает скорости почти 20 Мбит / с)
- Задержка в сочетании с размером окна TCP? Это задержка между сайтами 15 мс, поэтому даже размер окна 32 КБ в худшем случае
32*0.015составляет максимум 2,1 МБ / с. Кроме того, несколько одновременных передач по-прежнему просто составляют до 10 Мбит / с, что не поддерживает эту теорию - Может быть, источник и пункт назначения оба дерьмо? Что ж, источник может выдавать последовательные операции чтения со скоростью 1,6 ГБ / с, так что это не так. Адресат может выполнять последовательную запись 200 МБ / с, поэтому это не так.
Это очень странная ситуация. Я никогда не видел ничего такого, что проявлялось бы таким образом.
Где еще я могу посмотреть?
При дальнейшем расследовании я уверен, что указал на туннель IPSec как на проблему. Я сделал надуманный пример и провел несколько тестов непосредственно между двумя общедоступными IP-адресами на сайтах, а затем провел точно такой же тест с использованием внутренних IP-адресов, и я смог реплицировать 20 Мбит / с через незашифрованный Интернет и только 10 Мбит / с на IPSec. боковая сторона.
Предыдущая версия имела красную сельдь про HTTP. Забудьте об этом, это был неисправный механизм тестирования.
В соответствии с предложением Xeon и echo'd моего интернет-провайдера, когда я попросил их о поддержке, я установил правило искажения, чтобы сбросить MSS для данных IPSec до 1422 - на основе этого расчета :
1422 + 20 + 4 + 4 + 16 + 0 + 1 + 1 + 12
PAYLOAD IPSEC SPI ESP ESP-AES ESP (Pad) Pad Length Next Header ESP-SHA
Для размещения внутри провайдера 1480 MTU. Но, увы, это не имело никакого эффективного значения.
После сравнения перехватов wireshark сеанс TCP теперь согласовывает MSS 1380 на обоих концах (после нескольких настроек и добавления буфера на случай, если моя математика отстой. Подсказка: вероятно, это так). В любом случае 1380 также является MSS по умолчанию ASA, так что, возможно, он все равно договаривался об этом все время.
Я вижу странные данные в инструменте внутри Mikrotik, который я использую для измерения трафика. Это может быть ничто. Я не замечал этого раньше, поскольку использовал фильтрованный запрос, и я видел это только тогда, когда убрал фильтр.
1394это самый большой MTU, через который мне удалось пройти.
