У меня есть набор серверов внутри Amazon EC2 в VPC. Внутри этого VPC у меня есть частная подсеть и общедоступная подсеть. В публичной подсети я установил NAT-машину на экземпляре t2.micro, который в основном запускает этот сценарий NAT при запуске, внедрение правил в iptables. Загрузка файлов из Интернета с компьютера в частной подсети работает нормально.
Однако я сравнил скорость загрузки файла на внешнем FTP-сервере с высокой пропускной способностью непосредственно с моей машины NAT со скоростью загрузки с машины в моей частной подсети (через ту же машину NAT). Была действительно значительная разница: около 10 МБ / с с машины NAT против 1 МБ / с при загрузке с машины внутри частной подсети.
На машине NAT нет загрузки ЦП, поэтому это не может быть узким местом. При проведении того же теста на машинах большего размера (m3.medium с «средней производительностью сети» и m3.xlarge с «высокой производительностью сети») я также не смог получить скорость загрузки выше 2,5 МБ / с.
Это общая проблема NAT, которую можно (и нужно) настраивать? Откуда падение производительности?
Обновить
Проведя небольшое тестирование, я смог бы сузить эту проблему. Когда я использую Ubuntu 12.04 или Amazon Linux NAT с 2013 года, все работает без сбоев, и я получаю полную скорость загрузки даже на самых маленьких инстансах t2.micro. Не имеет значения, использую ли я машины PV или HVM. Проблема, похоже, связана с ядром. Эти старые машины имеют версию ядра 3.4.x, тогда как новые машины Amazon Linux NAT или Ubunut 14.XX имеют версию ядра 3.14.XX. Есть ли способ настроить новые машины?
Наконец-то мы нашли решение. Вы можете исправить скорость загрузки, запустив на машине NAT (как root):
ethtool -K eth0 sg off
Это отключает режим разброса-сбора, который (насколько я понимаю) останавливает разгрузку некоторой сетевой работы на самой сетевой карте. Отключение этой опции приводит к более высокой загрузке ЦП на клиенте, поскольку теперь ЦП должен делать всю работу сам. Однако на машине t2.micro при загрузке образа DVD мы увидели только около 5% использования ЦП.
Обратите внимание, что это не выдержит перезагрузки, поэтому обязательно установите это в rc.local или хотя бы до настройки NAT.
Я также использую блоки NAT в аналогичной настройке на производстве, поэтому очень заинтересован в ваших результатах. У меня не было подобных результатов до производства, но, возможно, это проблема, на которую я раньше не обращал внимания.
Давайте займемся наукой!
================================================== ==========================
Теория: блоки NAT могут загружаться и выгружаться быстрее, чем клиент, использующий NAT.
Эксперимент: сопоставьте эксперимент с вопрошающими. t2.micros с Amazon NAT 2014.09 2 подсети, при этом NAT идет на IGW, а частная подсеть указывает на NAT. (Общая аренда. SSD общего назначения)
Процедура:
# install speedtest
$ sudo yum install python-pip -y --enablerepo=epel; sudo pip install speedtest-cli
# run against the same server
$ speedtest-cli --server 935 --simple
# run it many times
$ for ((n=0;n<10;n++)); do speedtest-cli --simple --server 935; done
Данные:
Nat: Client
Download 727.38 157.99
Upload 250.50 138.91
Вывод: ОП не врет.
================================================== ==========================
Теория: разные версии ядра приводят к разным результатам.
Эксперимент: установите 3 ящика с физическими данными, каждый с магнитным SSD, m3.medium (без разрывов) и выделенной арендой. Проведите тест скорости.
Порядок действий: см. Последний эксперимент. Кроме того, настройте таблицу маршрутизации для каждого блока NAT. Использовал таблицу маршрутизации «черная дыра», чтобы доказать, что изменения распространяются, когда я менял местами таблицы маршрутизации.
curl google.com работает.curl google.com потерпеть неудачу на клиенте.curl google.com работает.Вот мои 3 нац ящика: 2014.09 3.14.20-20.44.amzn1.x86_64 2014.03 3.10.42-52.145.amzn1.x86_64 2013.09 3.4.62-53.42.amzn1.x86_64
Данные:
Все 3 коробки дают очень похожие результаты при запуске speedtest-cli --server 935
09/14 03/14 09/13
355.51, 356.55, 364.04
222.59, 212.45, 252.69
От клиента:
09/14 03/14 09/13
351.18, 364.85, 363.69
186.96, 257.58, 248.04
Вывод: есть ли деградация? Нет. Есть ли разница между версиями ядра? Нет.
================================================== ==========================
Теория: Выделенная аренда или совместная аренда имеет значение.
Эксперимент: 2 ящика NAT. Оба используют NAT 2014.09. Один с общей арендой, другой с выделенной арендой.
Данные: Оба блока имеют одинаковую производительность:
Shared Nat Dedicated Nat
387.67 387.26
296.27 336.89
У них также есть похожие стандартные отклонения:
$ python3
>>> import statistics
>>> shared_download = [388.25, 333.66, 337.44, 334.72, 338.38, 335.52, 333.73, 333.28, 334.43, 335.60]
>>> statistics.stdev(shared_download)
16.858005318937742
>>> dedicated_download = [388.59, 338.68, 333.97, 337.42, 326.77, 346.87, 336.74, 345.52, 362.75, 336.77]
>>> statistics.stdev(dedicated_download)
17.96480002671891
И когда вы запускаете комбинации 2x2:
Shared Client/Sh. NAT Sh. Client/Dedicated Nat Ded. Client/Sh. Nat Ded. Client/Ded. NAT
Upload 290.83 288.17 283.13 340.94
Download 260.01 250.75 248.05 236.06
Вывод: действительно непонятно, какое значение имеет общий или выделенный.
Тест, который, вероятно, стоит повторить, будет тест OP с m3.mediums. Мне удалось скопировать результаты t2.micro, но мой m3.medium, похоже, противоречит результатам OP m3.medium.
Мне было бы интересно увидеть ваши данные о версиях ядра.
Возможно, самая интересная часть - это то, как мне не удалось быстро настроить NAT m3.medium.
Мои тесты показали, что это ухудшило мои загрузки.
m3.large speedtest server m3.medium выделенный NAT-сервер.
Никакого другого трафика в этой среде.
sg в среднем Скорость загрузки: 292,19 sg ниже среднего Скорость загрузки: 259,21
Мой тест был таким: для ((n = 0; n <10; n ++)); сделать speedtest-cli --simple; сделано