☰

Latenz des gehosteten Netzwerks

tag-icon • tag-icon networking hosting ping dedicated-server latency
Latenz des gehosteten Netzwerks

Hintergrund

Ich habe einen neuen gehosteten, dedizierten Datenbankserver hinter einer dedizierten Firewall (Cisco ASA 5505 Sec+). Der Plan ist, einen oder zwei virtuelle (auch als „Cloud“ bezeichnete) Webserver auf der anderen Seite der Firewall zu haben, die eine Verbindung zum Backend-DB-Server herstellen.

Beim Einrichten des Servers war ich von seiner Netzwerkleistung nicht beeindruckt. Es stellte sich heraus, dass die Firewall, obwohl die beiden Server GigE haben, nur 100 Mbit/s unterstützt. Die meisten meiner Leistungsprobleme lassen sich damit also ausreichend erklären.

Problem

Im Rahmen der Fehlerbehebung habe ich jedoch eine Reihe von Pings vom dedizierten Server an die Firewall gesendet. Diese Pings lieferten einige interessante Ergebnisse. Die Verteilung der 100 Pings war wie folgt:

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

Ich hätte erwartet, dass der erste Hop konstant unter 1 ms liegt (und kann mich ehrlich gesagt an keine fest verdrahtete Umgebung erinnern, in der das nicht der Fall war). Nachfolgende Tests waren ziemlich ähnlich und dauerten mehrere Tage – es scheint sich also nicht um einen Einzelfall zu handeln. Es wurden keine erneuten Übertragungen oder verlorenen Pakete beobachtet. Ein Ping über die Firewall zeigt eine ähnliche Leistung:

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

Fehlerbehebung

Der Hoster hat den Server, die Firewall und die dazwischenliegenden Switches überprüft und sieht keine Probleme. Er weist auch darauf hin, dass er den ICMP-Verkehr im Netzwerk „herabstuft“. Er hat kürzlich einige Port-Flaps festgestellt (wahrscheinlich, glaube ich, durch die Konfiguration des Servers verursacht) und wird die Situation „weiterhin überwachen“. Die Port-Flaps sind nicht zahlreich genug oder zeitkorreliert genug, um die Ping-Zeiten zu erklären, obwohl es möglich sein könnte, dass es ein (weiteres) Symptom eines zugrunde liegenden Problems ist.

Ich habe keinen direkten Zugriff auf die ASA, aber der Hoster hat im Rahmen der Fehlerbehebung einige Statistiken dazu ausgeführt:

# 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

Abgesehen von einer scheinbar hohen CPU-Auslastung für eine Firewall mit wenigen ACLs und möglicherweise nur einer RDP-Sitzung, die sie durchläuft, sehe ich an den ASA-Statistiken nichts Beunruhigendes. Meiner Meinung nach scheint es auf keinen Fall überlastet zu sein.

Frage

Wenn man bedenkt, dass wir uns den Festplattensuchzeiten nähern und es noch keinen Produktionsverkehr auf der Firewall oder dem Server gibt, bin ich immer noch etwas besorgt. Was meint ihr? Ist das ein Problem? Ist das in einer größeren Rechenzentrumsumgebung normal?

Antwort1

Zunächst einmal sagen Sie weder, welches konkrete ASA-Modell Sie haben, noch den Lizenzmodus. Bitte posten Sie die Ausgabe von „sh ver“ und „sh int Ethernet0/0“.

Allerdings haben verschiedene ASA-Modelle unterschiedliche Durchsatzgrenzen. Beispielsweise hat der ASA5510 eine maximale Durchsatzgrenze (gleichzeitig) von 300 Mbit/s. Siehehttp://www.cisco.com/en/US/prod/collateral/vpndevc/ps6032/ps6094/ps6120/product_data_sheet0900aecd802930c5.htmlfür die vollständige Liste.

Was die Latenz betrifft, leiten alle Cisco-Produkte den Datenverkehr direkt an das Gerät in der unteren Warteschlange weiter. Aus diesem Grund ist es keine gute Praxis, ICMP-Echos an einen Router oder eine Firewall zu senden, da die Ergebnisse nie vorhersehbar sind. Wir haben hier zwei ASA5510 (beide mit Gigabit) und zwei 3750-X-Switches, und bei allen steigt die ICMP-Echo-Latenz auf bis zu 300 ms, wenn sie viel Datenverkehr übertragen.

Dies bedeutet nicht, dass der weitergeleitete Verkehr langsam ist

Wenn Sie die Latenz prüfen möchten, verwenden Sie einen Ping zwischen Geräten über die ASA. Dies ist die einzige zuverlässige Methode.

verwandte Informationen