Amazon EC2 VPC: экземпляр NAT загружает отбрасывание быстродействия
У меня есть ряд серверов в Amazon EC2 в VPC. В этом VPC у меня есть частная подсеть и общедоступная подсеть. В общедоступной подсети я настроил машину NAT на t2.micro экземпляре, который в основном запускает этот скрипт NAT на запуске, вводя правила в iptables. Загрузка файлов из Интернета от машины в частной подсети хорошо работает.
Однако я сравнил скорость загрузки файла на внешнем широкополосном FTP-сервере непосредственно от моей машины NAT до скорости загрузки от машины в моей частной подсети (через ту же машину NAT). Была действительно значительная разница: вокруг 10MB/s от машины NAT по сравнению с 1MB/s при загрузке с машины в частной подсети.
На машине NAT нет никакого использования ЦП, таким образом, это не может быть узким местом. При попытке того же теста более крупными машинами (m3.medium с "умеренной производительностью сети" и m3.xlarge с "высокой производительностью сети"), я также не мог получить скорости загрузки, больше, чем 2.5MB/s.
Действительно ли это - общая проблема 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
Вывод: OP не врет.
================================================= =============================
Теория: разные версии ядра приводят к разным результатам.
Эксперимент: Настройте 3 NAT-бокса, каждый с магнитным SSD, m3.medium (без разрывов) и выделенной арендой. Запустите тест скорости.
Процедура: См. Последний эксперимент. Кроме того, настройте таблицу маршрутизации для каждого блока NAT. Использовал таблицу маршрутизации «черная дыра», чтобы доказать, что изменения распространяются при замене таблиц маршрутизации.
- Использование NAT.
curl google.comработает.- Переключиться на черную дыру.
- Подождите, пока
] curl google.comсбой на клиенте. - Переключиться на новый NAT.
curl google.comработает.
Вот мои 3 поля nat: 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 Выделенный сервер NAT m3.medium.
Другого трафика в этой среде нет.
SG в среднем Скорость загрузки: 292,19 sg от среднего Скорость загрузки: 259,21
Мой тест был: для ((n = 0; n <10; n ++)); сделать speedtest-cli --simple; сделано