Wie Sie die CPU-Auslastung in SDN-Umgebungen überwachen
Das Monitoring der CPU-Last in einem Software-defined Network ist notwendig, damit genug Kapazitäten bereitstehen. Das gilt insbesondere, wenn Workloads um Ressourcen konkurrieren.
Der große Vorteil von Software-defined Networking (SDN) liegt darin, dass für zentrale Netzwerkfunktionen keine spezielle, kundenspezifische Hardware mehr erforderlich ist. Vielmehr bildet SDN die Funktionalität in Software ab, die auf normaler x86- und Commodity-Netzwerkhardware läuft.
Dieser Vorteil von Software-defined Networking ist gleichzeitig aber auch ein Nachteil. Außerdem werden viele dieser Netzwerkfunktionen in Ihren Rechenzentren – und sogar in einigen Zweigstellen – in der gleichen Compute-Infrastruktur ausgeführt wie der Rest Ihrer Workloads. Infolgedessen kann SDN mit anderen Aufgaben im Data Center um begrenzte CPU-Ressourcen konkurrieren.
SDN liefert zwei gute Gründe, die CPU-Auslastung zu überwachen. Erstens um sicherzustellen, dass Ihnen die benötigte Netzwerkkapazität zur Verfügung steht. Zweitens um sicherzustellen, dass die erforderliche Compute-Kapazität bereitsteht, wenn alle anderen Workloads berücksichtigt werden, die die Infrastruktur gemeinsam nutzen.
Was sollten Sie überwachen?
In einem Software-defined Network gilt es, drei große Klassen von Komponenten zu überwachen:
Virtuelle Geräte und Controller laufen für gewöhnlich innerhalb des Data Centers, meistens in Hypervisor-Umgebungen wie VMware, Kernel-based Virtual Machine (KVM), Microsoft Hyper-V, Citrix oder Oracle. Einige Geräte werden auf Branch-Office-Hardware basieren – insbesondere, wenn WAN-Virtualisierung und Software-defined WAN (SD-WAN) weiter an Boden gewinnen. Das geschieht entweder in Form von Customer Premises Equipment (CPE), das explizit mit dem WAN verbunden ist, oder auf einem Branch-Host-Server, auf dem traditionellere Workloads laufen, etwa ein File-Server. IT-Teams sollten an allen genannten Orten die Ressourcennutzung überwachen.
Das Monitoring sollte ebenfalls mehrere CPU-bezogene Metriken umfassen. Der erste Blick gilt natürlich der Auslastung. IT-Teams müssen feststellen, wie viel Zeit die CPU für Workloads aufwendet. Zweitens sollten Sie die Latenz überwachen, also wie lange Prozesse auf CPU-Ressourcen warten. Beim Troubleshooting kann die IT sich viele andere Metriken im Detail ansehen, aber diese sollten Sie besonders im Auge behalten.
Wie sollten Sie die CPU-Last überwachen?
Wenn IT-Teams kommerzielle Softwarepakete für aktuelle Switch-Geräte einsetzen, bieten die Management-Tools für die Plattform üblicherweise die Möglichkeit, die Ressourcennutzung zu überwachen. Die IT kann diese Möglichkeit nutzen, um Daten und Alarmmeldungen zu kontrollieren oder sie an einen Manager of Managers (MoM) im Network Operations Center (NOC) zu senden.
Wenn IT-Teams Open-Source-Software oder eine Plattform ohne integriertes Monitoring ausrollen, können sie in der Regel die Switches wie jedes andere Linux-Gerät behandeln und sie wie einen VM-Host überwachen.
Alles übrige fällt meist ebenfalls in die breitgefasste Kategorie eines VM-Hosts. Die IT-Abteilung kann diese Hosts auf mehrere Arten überwachen, indem sie zum Beispiel:
die eigenen Monitoring Tools der Virtualisierungsplattform nutzt, etwa von VMware, Microsoft oder Citrix;
eine allgemeine Management-Suite, beispielsweise von IBM, CA Technologies, BMC Software, ManageEngine oder SolarWinds verwendet; und
Monitoring Tools aus dem Open-Source-Bereich einsetzt, wie Nagios oder Zabbix.
Was Sie tun können, wenn die CPU-Auslastung im roten Bereich liegt
Die entscheidenden Aspekte beim Monitoring der CPU-Last sind die Baseline-Auslastung und alles andere, was die Ressourcen benötigt. Die durchschnittliche Baseline-Last sollte 75 Prozent oder weniger betragen, so dass sich auch einige Spitzen berücksichtigen lassen. Die Latenzen hingegen sollten bei 5 Prozent liegen, das heißt, Jobs müssen nicht auf CPU-Zyklen warten. Eine dauerhafte Auslastung über 90 Prozent sollte Alarme auslösen, genau wie Latenzen von mehr als circa 10 Prozent.
SDN kann durchaus mit anderen Aufgaben im Data Center um begrenzte CPU-Ressourcen konkurrieren.
IT-Teams sollten immer eine tiefergehende Analyse des vorliegenden Performance-Problems durchführen, um sicherzustellen, dass CPU-Probleme keine anderen Ursachen überlagern. Das können zum Beispiel Fehler im DRAM sein oder übermäßig lange I/O-Wartezeiten. Oft genug allerdings steckt das Problem tatsächlich in der CPU oder steht in Zusammenhang mit der Konkurrenz um CPU-Ressourcen.
In einer physischen Switch-Umgebung kann das Überschreiten von Schwellenwerten auf physische Probleme mit dem Switch hindeuten. Falls der Switch etwa überhitzt und seine Leistungsfähigkeit nachlässt, sollte die IT-Abteilung die Temperaturmetriken überprüfen. Ebenso ist denkbar, dass das Gerät mit zu vielen Aufgaben beschäftigt ist oder Schwierigkeiten hat, die Traffic-Menge zu bewältigen. Trifft dies zu, sollte die IT-Abteilung kontrollieren, ob der Switch etwas macht, das nicht erforderlich ist. Falls die Umgebung mittlerweile einfach zu groß für den Switch geworden ist, kann das IT-team ihn entweder austauschen oder den Traffic so gestalten, dass die Last geringer wird.
In einer VM-Host-Umgebung gelten alle beschriebenen Szenarien weiterhin – einen überhitzten Switch ausgenommen –, wobei die Auslastung mit zu vielen Aufgaben auch bedeuten kann, dass Ressourcen mit nicht netzwerkbasierten Workloads geteilt werden.
In einer solchen Umgebung können IT-Teams versuchen, Workloads zu separieren, um Ressourcen für den Netzwerk-Controller oder ein Data-Plane-Gerät zur Verfügung zu stellen. Eine weitere Gegenmaßnahme besteht darin, Host-Server mit Netzwerk-Offload-Karten auszustatten. Dadurch lässt sich die allgemeine CPU-Zeit drastisch reduzieren, die eine Netzwerkanwendung benötigt. IT-Teams könnten aber auch CPU-Ressourcen nachrüsten, um die Arbeit auf mehr Kerne zu verteilen.
