☰

Задержка размещенной сети

tag-icon • tag-icon networking hosting ping dedicated-server latency
Задержка размещенной сети

Фон

У меня есть новый выделенный сервер базы данных, размещенный за выделенным брандмауэром (Cisco ASA 5505 Sec+). План состоит в том, чтобы иметь виртуальный (он же «облачный») веб-сервер или два по ту сторону брандмауэра, подключаясь обратно к внутреннему серверу базы данных.

При настройке сервера я не был впечатлен его сетевой производительностью. Оказалось, что хотя на двух серверах есть GigE - брандмауэр поддерживает только 100 Мбит - так что большинство проблем с производительностью, которые у меня были, можно адекватно объяснить этим.

Проблема

Однако, в рамках устранения неполадок, я запустил серию пингов к брандмауэру с выделенного сервера. Эти пинги вернулись с некоторыми интересными результатами - в частности, распределение 100 пингов было следующим:

57% < 1ms
14% between 1ms and 2ms
12% between 2ms and 3ms
11% between 3ms and 6ms
6% >= 6ms
Min/Avg/Max: 0/1/8 ms

Я бы ожидал, что первый прыжок будет < 1 мс постоянно (и честно говоря, не могу вспомнить ни одной проводной среды, где бы этого не было). Последующие тесты были довольно похожими и проводились в течение некоторого количества дней, так что это, похоже, не единичный случай. Никаких повторных передач или потерянных пакетов не наблюдалось. Пинг через брандмауэр показывает схожую производительность:

58% < 1ms
14% between 1ms and 2ms
8% between 2ms and 2ms
14% between 3ms and 6ms
6% >= 6ms
Min/Avg/Max: 0/2/56 ms

Поиск неисправностей

Хостер проверил сервер, брандмауэр и промежуточные коммутаторы и не обнаружил никаких проблем. Они также указывают, что они «деприоритезируют» трафик ICMP в сети. Они заметили недавнюю неустойчивость портов (вероятно, вызванную, как я полагаю, конфигурацией сервера) и будут «продолжать следить» за ситуацией. Неустойчивость портов недостаточно многочисленна или недостаточно коррелирована по времени, чтобы объяснить время пинга, хотя возможно, что это (еще один) симптом более глубокой проблемы.

У меня нет прямого доступа к ASA, но хостер собрал некоторую статистику в рамках устранения неполадок:

# ping ***** (series of 5-packet pings from firewall to server, edited for brevity)
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/10 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/8/10 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/10 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

# show cpu usage
CPU utilization for 5 seconds = 13%; 1 minute: 11%; 5 minutes: 10%

# show mem
Free memory:       341383104 bytes (64%)
Used memory:       195487808 bytes (36%)
-------------     ----------------
Total memory:      536870912 bytes (100%)

# show int eth0/1
Interface Ethernet0/1 "", is up, line protocol is up
Hardware is 88E6095, BW 100 Mbps, DLY 100 usec
    Full-Duplex(Full-duplex), 100 Mbps(100 Mbps)
    Available but not configured via nameif
    MAC address *****, MTU not set
    IP address unassigned
    5068644 packets input, 5077178693 bytes, 0 no buffer
    Received 4390 broadcasts, 0 runts, 0 giants
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
    0 L2 decode drops
    387883 switch ingress policy drops
    3220647 packets output, 1648213382 bytes, 0 underruns
    0 output errors, 0 collisions, 0 interface resets
    0 babbles, 0 late collisions, 0 deferred
    0 lost carrier, 0 no carrier
    0 input reset drops, 0 output reset drops
    0 rate limit drops
    0 switch egress policy drops

За исключением, казалось бы, высокой загрузки ЦП для брандмауэра с несколькими ACL и, возможно, только сеансом RDP, проходящим через него, я не вижу ничего тревожного в статистике ASA. Он определенно не выглядит перегруженным IMHO.

Вопрос

Учитывая, что мы приближаемся к времени поиска диска, а на брандмауэре или сервере пока нет производственного трафика, я все еще немного обеспокоен. Что вы думаете? Это проблема? Это нормально в среде крупного центра обработки данных?

решение1

Во-первых, вы не говорите, какая у вас конкретная модель ASA, ни режим лицензирования. Пожалуйста, опубликуйте вывод "sh ver" и "sh int Ethernet0/0".

При этом разные модели ASA имеют разные ограничения пропускной способности. Например, ASA5510 имеет максимальный предел пропускной способности (одновременной) 300 Мбит/с. Смотретьhttp://www.cisco.com/en/US/prod/collateral/vpndevc/ps6032/ps6094/ps6120/product_data_sheet0900aecd802930c5.htmlдля полного списка.

Что касается задержки, то все продукты Cisco направляют трафик напрямую к устройству в нижней очереди. Вот почему плохая практика — отправлять эхо ICMP на маршрутизатор или брандмауэр, так как результаты никогда не предсказуемы. У нас есть два ASA5510 (оба с гигабитом) и два коммутатора 3750-X, и все они увеличивают задержку эхо ICMP до 300 мс, когда передают большой объем трафика.

Это не означает, что маршрутизируемый/пересылаемый трафик медленный.

Если вы хотите проверить задержку, то используйте ping между устройствами через ASA. Это единственный надежный способ.

Связанный контент