Storage. Backup. Virtualisierung.
Server-Virtualisierung - Performance · Version 1.10 · © Stor IT Back 2026
Die Performance einer Server-Virtualisierung wird hauptsächlich durch CPU, Arbeitsspeicher, Storage-Latenz, IOPS, Netzwerk und die Konfiguration des Hypervisors bestimmt. Bei vielen VMs entstehen Engpässe häufig nicht durch einen einzelnen Faktor, sondern durch das Zusammenspiel mehrerer Ressourcen.
Schon bei reinen physischen Systemen ohne jegliche Virtualisierung ist
eine Performance-Vorhersage recht schwierig. Es spielen einige Faktoren bei der
Performance-Analyse eine wichtige Rolle, viele sind nur sehr schwer zu erfassen, die meisten ändern sich dynamisch.
Ein einfaches Beispiel:
Eine Datenbank zeigt eine sehr schlechte Performance,
die User beschweren sich über langsame Antwortzeiten, die Applikationen
sind wegen der schlechten Geschwindigkeit nur schwer zu bedienen.
Woran kann dies liegen?
Allgemein am Server, am Netzwerk, am Client oder an der Datenbank oder
Applikation. Die Datenbank und die Applikation
sind erfahrungsgemäß die Ursache der größten Probleme, auch Client und das Netzwerk können die Performance beeinflussen.
Dann haben wir noch den Server, dieser besteht aus CPU, Hauptspeicher und Festplattenspeicher.
Die Dimensionierung von CPU und Hauptspeicher sind bei der Virtualisierung sehr wichtig. Ein Hauptvorteil der Server-Virtualisierung ist ja gerade die bessere Ausnutzung der modernen CPUs. Aber was ist, wenn die CPU jetzt überlastet ist? Die Anwendung wird langsamer als sie sein sollte. Bei einer richtigen Überwachung durch Schwellwert-Alarme in der Virtualisierungsschicht ist dieses Problem leicht zu erkennen. Auch bei der Auslastung des Hauptspeichers bietet die Virtualisierung meist einfache und effektive Überwachungsmöglichkeiten. Gleiches muss dann auch entsprechend in den virtuellen Maschinen überwacht werden. Ist die Dimensionierung von Hauptspeicher- und CPU-Ressource für die VM ausreichend? Oder muss dort angepasst werden?
Jetzt bleibt bei dieser Betrachtung nur noch der Speicherplatz übrig. Auch dort bieten viele Virtualisierungsprodukte umfangreiche Analysewerkzeuge an. So kann z.B. die I/O-Belastung einer Platte gemessen und grafisch ausgewertet werden, ebenso der Durchsatz und die I/O-Wartezeit. Wird dort ein Engpass angezeigt, so wird es aber schwierig dies zu verbessern. Bei fehlendem Hauptspeicher ist es einfach: Aufrüstung des RAMs in der physischen Maschine oder die Verlagerung von virtuellen Maschinen auf eine andere Hardware. Aber was kann bei Performance-Problemen im Storage-Backend geändert werden?
Schauen wir uns die Storage-Möglichkeiten in der virtuellen Welt einmal etwas genauer an. Die VM (virtuelle Maschine) nutzt einen Treiber, um die Daten an den virtuellen Hardware-Adapter der Virtualisierung weiterzuleiten. Dieser virtuelle Hardware-Adapter leitet es dann an das Filesystem der Virtualisierung (bei VMware ist es das VMFS oder vSAN, bei Proxmox z.B. ZFS oder Ceph, bei Hyper-V zum Beispiel NTFS) weiter. Vom Filesystem (oder einem virtuellen Blockdevice) geht es dann über den Treiber zum physischen Speicheradapter weiter. Dieser ist entweder über das Speichernetzwerk an das RAID-System angeschlossen (Shared Storage) oder lokal an einem RAID-Controller. Auch beim Speichernetzwerk (zum Beispiel Fibre Channel oder iSCSI) gibt es noch Optimierungsmöglichkeiten. Im externen RAID-System ist ein Cache vorhanden und über einen RAID-Level geht es auf die Platten. Je nach RAID-Level und Möglichkeiten des RAID-Controllers sind unterschiedliche Stripe-Sizes möglich. Und bei den Festplatten ist auch noch eine große Auswahl (SAS-Platten oder SATA, oder SSDs) vorhanden, mit unterschiedlichen Vor- und Nachteilen. In dieser Kette sind viele Faktoren vorhanden, die zum größten Teil auch noch untereinander abhängig sind.
Nachfolgend finden Sie zwei Beispiele für das Performance-Tuning im Storage-Bereich. Dies gilt nicht nur für die Virtualisierung, auch bei großen und performanten Anwendungen auf einem physischen Server kann ein Tuning einiges an Verbesserungen bringen.
Ceph ist ein verteiltes Storage-System, das bei Proxmox VE häufig als Shared Storage für virtuelle Maschinen und Container eingesetzt wird. Die Daten werden dabei auf mehrere Storage-Geräte und Nodes verteilt. Dadurch lassen sich Hochverfügbarkeit, Skalierbarkeit und Storage-Performance in einem gemeinsamen System realisieren.
Die Performance eines Ceph-Clusters hängt jedoch nicht von einer einzelnen Komponente ab. Entscheidend ist das Zusammenspiel von OSDs, Datenträgern, CPU, Arbeitsspeicher, Netzwerk, Anzahl der Nodes, Replikation und dem jeweiligen Workload. Besonders bei schnellen SSD- und NVMe-Systemen kann sich der Engpass vom Storage sehr schnell in Richtung Netzwerk oder CPU verschieben.
Die eigentliche Speicherung der Daten übernehmen bei Ceph die OSDs (Object Storage Daemons). Ein OSD verwaltet normalerweise einen physischen Datenträger. Proxmox VE empfiehlt grundsätzlich einen OSD pro physischem Storage-Gerät.
Mehr OSDs ermöglichen Ceph, I/O-Operationen auf mehr Datenträger zu verteilen und parallel abzuarbeiten. Daraus folgt jedoch nicht automatisch, dass eine Verdoppelung der OSD-Anzahl auch die doppelte Performance liefert. CPU-Leistung, Netzwerkbandbreite, Replikation und der jeweilige Workload können die Skalierung begrenzen.
Proxmox empfiehlt für einen produktiven Ceph-Cluster mindestens drei Nodes und insgesamt mindestens zwölf OSDs, die möglichst gleichmäßig auf die Nodes verteilt werden. Diese Empfehlung ist keine feste Voraussetzung für den technischen Betrieb von Ceph, sondern eine sinnvolle Grundlage für eine ausgewogene Verteilung von Daten, Last und Ausfällen.
Auch eine möglichst gleichmäßige Ausstattung der Nodes ist sinnvoll. Unterschiedlich schnelle oder unterschiedlich große Datenträger können dazu führen, dass einzelne OSDs häufiger ausgelastet sind als andere und damit die Gesamtperformance beeinflussen.
Die Art der verwendeten Datenträger hat erheblichen Einfluss auf die Ceph-Performance. HDDs bieten hohe Kapazitäten zu vergleichsweise niedrigen Kosten, sind bei kleinen zufälligen I/O-Operationen jedoch durch ihre mechanischen Zugriffszeiten begrenzt.
SSDs und insbesondere NVMe-Laufwerke bieten wesentlich mehr IOPS und geringere Latenzen. Für Virtualisierungsumgebungen mit vielen gleichzeitig aktiven VMs sind deshalb SSD- oder NVMe-basierte Ceph-Cluster häufig deutlich leistungsfähiger.
Bei der Auswahl von SSDs sollte jedoch nicht nur auf die maximale Übertragungsrate oder die angegebenen IOPS geachtet werden. Für produktive Ceph-Systeme sind beispielsweise eine ausreichende Schreibhaltbarkeit (Endurance beziehungsweise DWPD), konstante Dauerleistung und Power Loss Protection (PLP) wichtige Eigenschaften. Enterprise-SSDs sind deshalb für schreibintensive Virtualisierungsumgebungen normalerweise besser geeignet als einfache Client-SSDs.
Ceph übernimmt die Verteilung und Redundanz der Daten selbst. Die einzelnen Datenträger sollten deshalb direkt vom Betriebssystem beziehungsweise von Ceph angesprochen werden können.
Ein klassisches Hardware-RAID unterhalb der Ceph-OSDs ist nicht sinnvoll. Es erschwert die Fehlererkennung und kann durch zusätzliche Caching- und RAID-Mechanismen sogar die Performance beeinträchtigen. Für Ceph werden deshalb direkt angebundene Datenträger beziehungsweise ein geeigneter HBA (Host Bus Adapter) verwendet.
Aktuelle Ceph-Installationen verwenden BlueStore als Storage-Backend der OSDs. BlueStore schreibt die Daten direkt auf das Blockdevice und verwaltet zusätzlich interne Metadaten in einer RocksDB-Datenbank.
Bei HDD-basierten OSDs kann es sinnvoll sein, die BlueStore-Datenbank (block.db) auf einer schnelleren SSD oder NVMe unterzubringen. Dadurch können insbesondere Metadatenzugriffe beschleunigt und die Latenz der HDD-basierten OSDs verbessert werden.
Auch das Write-Ahead Log (WAL) kann auf einem schnelleren Gerät liegen.
Wird bereits ein schnelles Gerät für block.db verwendet,
platziert BlueStore das WAL normalerweise ebenfalls dort.
Bei reinen SSD- oder NVMe-OSDs ist eine Trennung von Daten, DB und WAL dagegen nicht automatisch schneller. Ein separates DB- oder WAL-Gerät ist nur dann sinnvoll, wenn dieses tatsächlich schneller als das eigentliche OSD-Gerät ist und das Design zum Workload passt.
Ceph benötigt nicht nur schnelle Datenträger. Jeder OSD-Prozess benötigt CPU-Leistung und Arbeitsspeicher, beispielsweise für BlueStore, Checksummen, Replikation, Netzwerkkommunikation und die Verarbeitung der I/O-Operationen.
Besonders schnelle NVMe-Laufwerke können eine hohe Anzahl von I/O-Operationen erzeugen und dadurch erheblich mehr CPU-Leistung beanspruchen als HDD-basierte OSDs. Bei einem hyperkonvergenten Proxmox-Cluster teilen sich außerdem die virtuellen Maschinen und die Ceph-Dienste CPU und RAM eines Nodes.
Bei der Dimensionierung müssen deshalb immer genügend Ressourcen für Proxmox VE, Ceph und die virtuellen Maschinen vorhanden sein. Eine hohe Zahl schneller OSDs bringt wenig, wenn CPU oder Arbeitsspeicher des Nodes bereits ausgelastet sind.
Ein Ceph-Cluster erzeugt deutlich mehr Netzwerkverkehr als nur die Daten, die eine virtuelle Maschine liest oder schreibt. Zusätzlich müssen beispielsweise Replikation, Recovery, Rebalancing und die Kommunikation zwischen den Ceph-Diensten über das Netzwerk übertragen werden.
Proxmox empfiehlt für Ceph mindestens 10 Gbit/s Ethernet. Bei leistungsfähigen SSD- und insbesondere NVMe-Clustern sollte eher 25 Gbit/s oder schneller vorgesehen werden. Abhängig von Anzahl und Leistung der OSDs können auch 40 oder 100 Gbit/s erforderlich sein, um die vorhandene Storage-Performance tatsächlich nutzen zu können.
Das Ceph-Netzwerk sollte außerdem redundant ausgelegt sein. Gerade mehrere SSDs oder NVMe-Laufwerke in einem Node können gemeinsam wesentlich mehr Daten liefern, als über eine einzelne 10-Gbit/s-Verbindung übertragen werden können.
Besonders wichtig bei Proxmox VE ist die Trennung des Ceph-Traffics von Corosync. Die Cluster-Kommunikation über Corosync benötigt keine hohe Bandbreite, reagiert aber empfindlich auf Paketverluste und erhöhte Latenzen.
Ein stark ausgelastetes Ceph-Netzwerk kann deshalb im ungünstigen Fall nicht nur die Storage-Performance beeinträchtigen, sondern auch die Kommunikation des Proxmox-Clusters stören.
Für leistungsfähige Installationen können beispielsweise getrennte physische Netzwerke verwendet werden:
Ob ein separates Public und Cluster Network erforderlich ist, hängt von der Größe und Performance des Clusters ab. Entscheidend ist, dass ausreichend Bandbreite vorhanden ist und der Storage-Traffic keine latenzkritische Cluster-Kommunikation beeinträchtigt.
Ceph verteilt die Daten nicht nur über mehrere OSDs, sondern erzeugt bei replizierten Pools mehrere Kopien der gespeicherten Objekte. Eine typische Konfiguration verwendet beispielsweise size=3. Damit existieren insgesamt drei Instanzen eines Objektes innerhalb des vom CRUSH-Regelwerk vorgegebenen Failure Domains.
Die Replikation erhöht die Ausfallsicherheit, verursacht aber gleichzeitig zusätzliche Schreiboperationen und zusätzlichen Netzwerkverkehr. Ein Schreibzugriff einer VM erzeugt daher innerhalb des Ceph-Clusters mehr I/O und Netzwerkverkehr als die ursprünglich von der VM geschriebene Datenmenge.
Die Redundanz sollte deshalb nicht zugunsten einer höheren Performance
reduziert werden. Einstellungen wie size und
min_size sind in erster Linie Parameter für
Datensicherheit und Verfügbarkeit und keine Tuning-Parameter.
Neben replizierten Pools unterstützt Ceph auch Erasure Coding (EC). Dadurch kann die benötigte Speicherkapazität für Redundanz gegenüber einer dreifachen Replikation deutlich reduziert werden.
Erasure Coding benötigt jedoch zusätzliche Berechnungen und kann insbesondere bei kleinen zufälligen Schreibzugriffen höhere Anforderungen an CPU, Datenträger und Netzwerk stellen. Für typische VM-Workloads mit Ceph RBD sollten deshalb Kapazität, Performance und verwendete Ceph-Version sorgfältig gegeneinander abgewogen werden.
Für maximale Performance und eine möglichst einfache Konfiguration werden bei Virtualisierungsumgebungen häufig replizierte RBD-Pools eingesetzt. Erasure Coding kann dagegen interessant sein, wenn die nutzbare Speicherkapazität eine besonders wichtige Rolle spielt.
Eine wichtige Besonderheit verteilter Storage-Systeme zeigt sich beim Ausfall oder Austausch eines OSDs beziehungsweise eines ganzen Nodes. Ceph verteilt die betroffenen Daten automatisch auf die verbleibenden beziehungsweise neu hinzugefügten OSDs.
Dieses Recovery und Rebalancing benötigt zusätzliche Storage-, Netzwerk- und CPU-Ressourcen. Die Performance eines Clusters sollte deshalb nicht nur im normalen Betrieb betrachtet werden. Entscheidend ist auch, welche Leistung während eines OSD- oder Node-Ausfalls für die virtuellen Maschinen übrig bleibt.
Große HDDs können hierbei problematisch sein, da nach einem Ausfall sehr große Datenmengen wiederhergestellt werden müssen. SSDs und schnelle Netzwerke verkürzen nicht nur die Recovery-Zeit, sondern reduzieren damit auch den Zeitraum, in dem das Cluster unter zusätzlicher Last arbeitet.
Zur Analyse bietet Ceph verschiedene Werkzeuge und Statistiken.
Mit rados bench lässt sich beispielsweise die Performance eines
RADOS-Pools untersuchen. Dabei können Schreib- und Lesezugriffe mit mehreren
parallelen Operationen getestet werden.
Ein solcher Test misst jedoch nur einen bestimmten Teil der Storage-Kette. Für eine virtuelle Maschine sind zusätzlich der Hypervisor, RBD, der virtuelle Storage-Controller, das Dateisystem und die Anwendung relevant. Deshalb sollte auch die Performance aus Sicht der VM gemessen werden.
Wichtige Werte bei der Analyse eines Ceph-Clusters sind unter anderem:
Ein einzelner Benchmark-Wert ist deshalb nur begrenzt aussagekräftig. Tests sollten mit unterschiedlichen I/O-Größen, Queue Depths sowie Lese-/Schreibverhältnissen durchgeführt werden und möglichst den späteren Workload der virtuellen Maschinen nachbilden.
Für eine gute Ceph-Performance bei Proxmox VE sind vor allem eine ausgewogene Architektur und ausreichend Reserven entscheidend. Schnelle OSDs allein reichen nicht aus, wenn Netzwerk oder CPU zum Flaschenhals werden.
In der Praxis sollten insbesondere folgende Punkte berücksichtigt werden:
Fazit: Die Performance eines Ceph-Clusters ergibt sich aus dem Zusammenspiel aller Komponenten. Mehr OSDs oder zusätzliche Nodes können die Leistung erhöhen, eine lineare Skalierung ist jedoch nicht garantiert. Für einen leistungsfähigen Proxmox-Ceph-Cluster müssen Datenträger, CPU, Arbeitsspeicher und insbesondere das Netzwerk gemeinsam dimensioniert werden.
Bei der Storage-Performance einer Server-Virtualisierung spielen Blockgrößen, I/O-Größen und das Alignment der verschiedenen Storage-Schichten eine wichtige Rolle. Dabei gibt es jedoch nicht die eine Blockgröße, die für alle Ebenen einer virtuellen Umgebung gilt.
Zwischen einer Anwendung in der virtuellen Maschine und dem physischen Storage liegen mehrere Schichten. Jede dieser Schichten kann mit eigenen Block-, Sektor- oder I/O-Größen arbeiten. Dazu gehören beispielsweise:
Diese Größen müssen nicht identisch sein. Eine gute Storage-Performance entsteht nicht dadurch, dass auf allen Ebenen möglichst dieselbe Blockgröße eingestellt wird. Entscheidend ist vielmehr, dass die einzelnen Schichten sinnvoll zusammenarbeiten und keine unnötigen zusätzlichen I/O-Operationen erzeugen.
Unter Alignment versteht man die Ausrichtung von Partitionen, Dateisystemen und Datenstrukturen an geeigneten Grenzen des darunterliegenden Storage-Systems. Beginnt beispielsweise ein Datenblock ungünstig zwischen zwei physischen Storage-Blöcken, kann ein eigentlich kleiner Zugriff mehrere physische I/O-Operationen verursachen.
Das folgende vereinfachte Beispiel zeigt dieses Prinzip. Die Grenzen der verschiedenen Storage-Schichten liegen ungünstig zueinander. Ein einzelner Zugriff innerhalb der virtuellen Maschine kann deshalb mehrere Blöcke der darunterliegenden Storage-Schicht betreffen:
In einer besser ausgerichteten Umgebung liegen die relevanten Grenzen günstiger zueinander. Dadurch können unnötige zusätzliche Zugriffe reduziert werden:
Bei aktuellen Betriebssystemen und Hypervisoren ist ein manuelles Partition-Alignment normalerweise nicht mehr erforderlich. Moderne Windows- und Linux-Systeme richten neu angelegte Partitionen automatisch an geeigneten Grenzen aus. Auch Storage-Werkzeuge unter Linux können Informationen wie logische und physische Blockgröße, Alignment sowie bevorzugte I/O-Größen des Storage-Gerätes berücksichtigen.
Relevant kann das Thema weiterhin bei älteren oder migrierten Systemen sein. Dazu gehören beispielsweise virtuelle Maschinen, deren Partitionen bereits vor vielen Jahren angelegt wurden, alte Images, geklonte Datenträger oder manuell erstellte Partitionen. Auch besondere RAID- und Storage-Konfigurationen können eine Überprüfung des Alignments sinnvoll machen.
Moderne Datenträger und Storage-Systeme arbeiten häufig intern mit 4-KByte-Sektoren. Dabei muss zwischen der logischen Blockgröße, die gegenüber dem Betriebssystem präsentiert wird, und der tatsächlich intern verwendeten physischen Blockgröße unterschieden werden.
Ein Storage kann beispielsweise logische 512-Byte-Sektoren bereitstellen, intern aber mit 4-KByte-Sektoren arbeiten. Solche Laufwerke werden häufig als 512e bezeichnet. Bei 4Kn werden dagegen auch nach außen 4-KByte-Sektoren verwendet. Besonders bei direkten I/O-Zugriffen und älteren Betriebssystemen oder Anwendungen sollte deshalb geprüft werden, welche Sektorgrößen die komplette Storage-Kette tatsächlich verwendet.
Für die Performance ist heute häufig die I/O-Größe des tatsächlichen Workloads wichtiger als eine einzelne Blocksize-Einstellung. Eine Datenbank kann beispielsweise viele kleine zufällige Lese- und Schreiboperationen erzeugen. Backup-, Datei- oder Streaming-Anwendungen arbeiten dagegen häufig mit größeren und eher sequenziellen Zugriffen.
Kleine zufällige I/O-Operationen stellen andere Anforderungen an ein Storage-System als große sequenzielle Transfers. Bei kleinen I/Os sind beispielsweise die Anzahl der möglichen IOPS und die Latenz besonders wichtig. Bei großen sequenziellen Zugriffen wird dagegen häufig die maximale Übertragungsrate zum entscheidenden Faktor.
Auch das RAID-Verfahren beeinflusst die Storage-Performance. RAID-Systeme verteilen Daten in Chunks beziehungsweise Stripes über mehrere Laufwerke. Besonders bei RAID-Leveln mit Parität können kleine Schreibzugriffe zusätzliche Lese- und Schreiboperationen verursachen. Dieser Vorgang wird häufig als Read-Modify-Write bezeichnet.
Eine Änderung der RAID-Chunk- oder Stripe-Größe kann deshalb bei bestimmten Workloads Auswirkungen auf die Performance haben. Eine pauschale Empfehlung wie „größere Blöcke sind schneller“ oder „kleinere Blöcke sind besser für Datenbanken“ ist jedoch nicht sinnvoll. Die optimale Konfiguration hängt von Workload, RAID-Level, Cache, Storage-System und Datenträgern ab.
Bei VMware vSphere, Proxmox VE, Microsoft Hyper-V und anderen modernen Virtualisierungsplattformen sollten Administratoren die Standardwerte nicht ohne konkreten Grund verändern. Vor einem Tuning sollte zunächst analysiert werden, ob überhaupt ein Storage-Engpass vorhanden ist und welche I/O-Muster die virtuellen Maschinen erzeugen.
Für eine Performance-Analyse sind insbesondere folgende Werte interessant:
Erst wenn diese Werte bekannt sind, lässt sich beurteilen, ob Änderungen an Dateisystem, RAID, Storage-Netzwerk oder Storage-System tatsächlich sinnvoll sind. Besonders bei schnellen SSD- und NVMe-Systemen können inzwischen auch Latenz, Parallelität und Queueing wichtiger sein als die klassische Betrachtung einer einzelnen Blockgröße.
Fazit: Bei modernen virtualisierten Umgebungen geht es beim Blocksize-Tuning weniger um das manuelle Verschieben von Partitionsgrenzen, sondern um das Zusammenspiel von Anwendung, Dateisystem, Hypervisor und Storage-System. Die Block- und I/O-Größen sollten deshalb immer im Zusammenhang mit dem realen Workload betrachtet und Änderungen durch Performance-Messungen überprüft werden.
Bei iSCSI werden blockbasierte Storage-Zugriffe über Ethernet und TCP/IP übertragen. Die Performance hängt deshalb nicht nur vom Storage-System selbst, sondern auch vom Netzwerk, vom iSCSI-Initiator, vom Hypervisor und von der Konfiguration der einzelnen Datenpfade ab.
Bevor einzelne Parameter verändert werden, sollte zunächst ermittelt werden, wo sich der tatsächliche Engpass befindet. Eine hohe Storage-Latenz kann beispielsweise durch ein ausgelastetes Storage-System, volle I/O-Warteschlangen, Paketverluste, eine überlastete Netzwerkverbindung oder eine ungünstige Multipathing-Konfiguration verursacht werden.
Da iSCSI auf TCP/IP und Ethernet basiert, hat das Netzwerk einen direkten Einfluss auf die Storage-Performance. Entscheidend sind dabei nicht nur die maximale Bandbreite, sondern insbesondere eine geringe und gleichmäßige Latenz sowie eine möglichst verlustfreie Übertragung.
Für produktive Virtualisierungsumgebungen sollte iSCSI deshalb über ein entsprechend dimensioniertes und redundantes Netzwerk betrieben werden. Abhängig von Anzahl und Leistung der Hosts sowie des Storage-Systems kommen heute beispielsweise 10, 25 oder 100 Gbit/s Ethernet zum Einsatz. Besonders schnelle SSD- und NVMe-Storage-Systeme können bereits mehrere 10-Gbit/s- Verbindungen vollständig auslasten.
iSCSI-Traffic sollte logisch oder physisch vom normalen Client- und Management-Netzwerk getrennt werden. Dies kann beispielsweise über dedizierte Switches, separate Ports oder eigene VLANs erfolgen. Entscheidend ist, dass Storage-Traffic nicht durch andere stark belastete Netzwerkdienste unnötig beeinträchtigt wird.
Ein produktives iSCSI-Netzwerk sollte möglichst mehrere unabhängige Datenpfade zwischen Virtualisierungshost und Storage-System bereitstellen. Dadurch kann bei einem Ausfall einer Netzwerkkarte, eines Switches, eines Storage-Ports oder einer Verbindung weiterhin auf die LUNs zugegriffen werden.
Hierfür wird üblicherweise Multipathing beziehungsweise MPIO verwendet. Neben der Redundanz können mehrere aktive Pfade – abhängig von Hypervisor, Storage-System und Path-Selection-Policy – auch zur Verteilung der I/O-Operationen genutzt werden.
Wichtig ist dabei, die vom Storage-Hersteller empfohlenen Einstellungen für Multipathing und die jeweilige Path-Selection-Policy zu verwenden. Eine Konfiguration, die bei einem Storage-System optimal funktioniert, muss bei einem anderen System nicht die richtige sein.
Bei VMware ist zusätzlich zu beachten, dass das sogenannte iSCSI Port Binding nur für bestimmte Netzwerkdesigns vorgesehen ist. Mehrere VMkernel-Ports im gleichen IP-Subnetz können beispielsweise über Port Binding an den Software-iSCSI-Initiator gebunden werden. Werden dagegen unterschiedliche Storage-Netze oder Subnetze verwendet, gelten andere Konfigurationsregeln. Port Binding sollte deshalb nicht pauschal aktiviert werden.
Eine häufig diskutierte Optimierung bei iSCSI sind Jumbo Frames. Statt der üblichen Ethernet-MTU von 1500 Byte können dabei größere Frames, beispielsweise mit einer MTU von 9000 Byte, übertragen werden. Dadurch sinkt die Anzahl der Frames, die für die Übertragung einer bestimmten Datenmenge verarbeitet werden müssen.
Jumbo Frames können den Protokoll-Overhead reduzieren, sind jedoch keine Voraussetzung für ein schnelles iSCSI-Netzwerk. Ob sich daraus in der Praxis ein messbarer Performance-Vorteil ergibt, hängt unter anderem von Netzwerkadaptern, CPU, Switches, Storage-System und Workload ab.
Entscheidend ist eine konsistente Konfiguration über den gesamten Übertragungspfad. Wenn Jumbo Frames verwendet werden, müssen Virtualisierungshost, virtuelle Switches, physische Netzwerkadapter, Netzwerk-Switches und Storage-System die entsprechende MTU unterstützen und korrekt konfiguriert sein.
Eine unterschiedliche MTU innerhalb des iSCSI-Pfades kann zu Paketverlusten, Fragmentierung, Verbindungsproblemen und deutlich erhöhter Storage-Latenz führen. Deshalb sollte die tatsächlich nutzbare MTU nach der Konfiguration über den kompletten Storage-Pfad getestet werden.
Bei einem Software-iSCSI-Initiator wird ein Teil der Verarbeitung von TCP/IP und iSCSI durch die CPU des Virtualisierungshosts durchgeführt. Moderne Server-Prozessoren und Netzwerkadapter können diese Verarbeitung jedoch normalerweise mit vergleichsweise geringem Aufwand übernehmen. Deshalb ist ein Hardware-iSCSI-HBA heute nicht grundsätzlich erforderlich.
Moderne Netzwerkadapter bieten zudem verschiedene Hardware-Offload-Funktionen, mit denen beispielsweise TCP- oder Netzwerkoperationen von der CPU auf den Netzwerkadapter verlagert werden können. Welche Funktionen tatsächlich genutzt werden und sinnvoll sind, hängt vom Hypervisor, Betriebssystem, Netzwerkadapter sowie dessen Treiber und Firmware ab.
Offload-Funktionen sollten deshalb nicht pauschal aktiviert oder deaktiviert werden. Bei Performance- oder Stabilitätsproblemen sollten zunächst die Empfehlungen des Hypervisor-, NIC- und Storage-Herstellers sowie die Kompatibilität von Treiber und Firmware überprüft werden.
Ein weiterer wichtiger Faktor ist die Anzahl gleichzeitig verarbeitbarer I/O-Operationen. Zwischen Anwendung, virtueller Maschine, Virtualisierungshost, Storage-Adapter und Storage-System existieren mehrere Warteschlangen. Die maximale Anzahl der gleichzeitig ausstehenden I/O-Kommandos wird häufig als Queue Depth bezeichnet.
Ist die Queue Depth zu klein, kann ein leistungsfähiges Storage-System möglicherweise nicht vollständig ausgelastet werden. Zu große Warteschlangen können dagegen dazu führen, dass sehr viele I/O-Operationen aufgestaut werden und die Antwortzeiten deutlich steigen.
Eine Änderung der Queue Depth sollte daher nur vorgenommen werden, wenn Messwerte auf einen entsprechenden Engpass hinweisen und die Änderung vom Storage- beziehungsweise Hypervisor-Hersteller unterstützt wird.
Bei älteren iSCSI-Implementierungen wurden häufig Parameter wie
MaxRecvDataSegmentLength, MaxBurstLength,
InitialR2T oder ImmediateData manuell verändert,
um die Performance zu optimieren.
Bei aktuellen Virtualisierungs- und Storage-Systemen sollten solche Protokollparameter nicht ohne konkrete Herstellerempfehlung geändert werden. Moderne Initiatoren und Targets handeln viele Einstellungen automatisch aus beziehungsweise verwenden für die jeweilige Plattform geeignete Standardwerte.
Ein vermeintliches iSCSI-Performance-Problem sollte deshalb nicht als Erstes durch die Veränderung einzelner Protokollparameter behandelt werden. In der Praxis sind Netzwerk, Storage-Latenz, Multipathing, Queueing oder ein überlastetes Storage-System häufig die wichtigeren Ansatzpunkte.
Vor einem Tuning sollten die einzelnen Komponenten der Storage-Kette systematisch untersucht werden. Wichtige Messwerte sind beispielsweise:
Bei VMware können beispielsweise esxtop sowie die Performance-Daten
von vCenter zur Analyse verwendet werden. Besonders interessant sind dabei
die Storage-Latenzen und Warteschlangen. Bei Linux- beziehungsweise
Proxmox-Systemen stehen unter anderem Werkzeuge wie iostat,
sar und die Statistiken des Linux-Multipathings zur Verfügung.
Die größte Verbesserung lässt sich häufig nicht durch einen einzelnen iSCSI-Parameter erzielen, sondern durch eine saubere Gesamtarchitektur. Ein ausreichend schnelles und redundantes Netzwerk, korrektes Multipathing, aktuelle Treiber und Firmware sowie ein passend dimensioniertes Storage-System bilden die Grundlage für eine gute iSCSI-Performance.
Erst wenn Messungen einen konkreten Engpass zeigen, sollten Einstellungen wie MTU, Queue Depth, Multipathing-Policy oder andere Parameter verändert werden. Nach jeder Änderung sollte erneut gemessen werden, ob sich Latenz, Datendurchsatz oder IOPS tatsächlich verbessert haben.
Fazit: Modernes iSCSI-Tuning bedeutet vor allem messen, analysieren und gezielt optimieren. Pauschale Parameteränderungen ohne Kenntnis des tatsächlichen Engpasses können die Performance verschlechtern und im ungünstigsten Fall sogar die Stabilität der Storage-Anbindung beeinträchtigen.
Werden in einer virtuellen Umgebung Performance-Probleme festgestellt, so ist die Analyse erst
mal recht undurchsichtig. Wo liegt jetzt das eigentliche Problem? Nehmen wir einmal VMware vSphere als
Beispiel. Wenn dort die Antwortzeiten von Anwendungen und Applikationen schlecht sind, dann
gibt es viele Analysemöglichkeiten. Der zentrale Ansatz ist auf jeden Fall der ESXi. Und der
bringt auch einige Möglichkeiten zur Fehlersuche mit. Dies ist einmal die grafische Aufbereitung
der Performancedaten. Hier lassen sich schon viele Probleme erkennen. Ist die CPU-Auslastung
über einen langen Zeitraum recht hoch für den Server, dann kann auf die einzelnen virtuellen Maschinen
geschaut werden, welche zu viel CPU verbraucht. Hier kann man auch recht schnell entscheiden, ob der
CPU-Verbrauch einer VM richtig ist, oder ob schon dort der Fehler vorliegt. Ähnlich kann auch
mit dem RAM verfahren werden. Dort ist die Lösung meist recht einfach, wenn an sich keine
Störung vorliegt, es wird einfach mehr RAM eingebaut, oder eine VM wird verschoben.
Problematischer wird die Fehlersuche meist bei den Datenspeichern. Auch hier bietet VMware viele
grafische Auswertungen an, jedoch sind diese immer zeitlich gemittelt. Kleine Peaks werden meist
nicht erkannt und komplexe Zusammenhänge werden grafisch meist wegen Unübersichtlichkeit nicht erkannt.
Hier hilft das Texttool esxtop direkt auf der Konsole des ESXi. Es ist dem üblichen Linux-Tool top
nachempfunden und zeigt detailliert die Zustände im ESXi an. Neben CPU und RAM werden die Devices und Units
ausgewertet, aber auch die virtuellen Maschinen. Durch eine einstellbare Aktualisierungsrate können auch kleine
Peaks noch erkannt werden.
Beispiel esxtop für Devices:
6:51:15pm up 13 days 1:41, 326 worlds, 3 VMs, 4 vCPUs; CPU load average: 0.11, 0.14, 0.14
| ADAPTR | PATH | NPTH | CMDS/s | READS/s | WRITES/s | MBREAD/s | MBWRTN/s | DAVG/cmd | KAVG/cmd | GAVG/cmd | QAVG/cmd |
| vmhba0 | - | 0 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| vmhba1 | - | 2 | 1.00 | 0.00 | 1.00 | 0.00 | 0.00 | 0.76 | 0.01 | 0.77 | 0.00 |
| vmhba32 | - | 0 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| vmhba33 | - | 0 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| vmhba34 | - | 0 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| vmhba35 | - | 1 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| vmhba36 | - | 1 | 2.81 | 0.00 | 2.81 | 0.00 | 0.01 | 1.53 | 0.01 | 1.54 | 0.00 |
Hier können Basisdaten wie zum Beispiel die Lese- oder Schreiboperationen pro Sekunde oder die Übertragungsrate
getrennt nach Read und Write ermittelt werden. Bei diesen Werten gibt es kein "Gut" oder "Schlecht",
eher ein "sinnvoll" oder ein "nicht nachvollziehbar". Es kommt immer auf die Umgebung an, große Datenbanken
können auch sehr viele Lese- oder Schreiboperationen verursachen, ohne dass es eine Störung ist. Diese Werte
müssen immer von Fall zu Fall abgeglichen werden. Interessant sind mehr die DAVG/cmd und die KAVG/cmd, beide Werte
zeigen die Antwortzeit. Liegt zum Beispiel die DAVG über 25, so wird das meist als kritisch eingestuft. Die KAVG Werte über
3 deuten auf Probleme im Kernel hin, zum Beispiel eine fehlerhafte Failover-Policy oder eine falsche Queue Depth.
Insgesamt muss das System und auch die ganze Umgebung genau analysiert werden, esxtop kann aber als erste Anlaufstelle
zur Ermittlung der Fehlerursache genutzt werden.
Die Performance einer virtuellen Maschine wird durch mehrere Komponenten beeinflusst. Dazu gehören die verfügbaren CPU- und RAM-Ressourcen des Hosts, die Konfiguration der VM, die Storage-Performance, das Netzwerk sowie das Betriebssystem und die Anwendungen innerhalb der VM. Besonders bei vielen gleichzeitig betriebenen VMs können sich Engpässe bei CPU, Arbeitsspeicher, Storage-Latenz oder IOPS auf mehrere Systeme gleichzeitig auswirken.
Die Performance eines Ceph-Clusters hängt unter anderem von Anzahl und Geschwindigkeit der OSDs, deren Verteilung auf die Nodes, der Leistungsfähigkeit der Datenträger sowie CPU, Arbeitsspeicher und Netzwerk ab. Besonders bei SSDs und NVMe-Laufwerken kann das Netzwerk zum begrenzenden Faktor werden. Für produktive Umgebungen sollte die Kommunikation zwischen den Ceph-Nodes deshalb leistungsfähig und redundant ausgelegt werden.
Bei einer virtualisierten Storage-Umgebung treffen unterschiedliche I/O- und Blockgrößen aufeinander, beispielsweise von Anwendung, Dateisystem, virtueller Festplatte, Hypervisor und Storage-System. Diese Größen müssen nicht identisch sein. Wichtig ist, unnötige I/O-Operationen, ungünstige Alignment-Grenzen und zusätzliche Read-Modify-Write-Vorgänge zu vermeiden. Moderne Betriebssysteme und Hypervisoren richten Partitionen normalerweise automatisch korrekt aus.
Für eine gute iSCSI-Performance sind ein schnelles und möglichst redundantes Storage-Netzwerk, geringe Latenzen und eine fehlerfreie Ethernet-Verbindung entscheidend. Zusätzlich können Multipathing, Queue Depth, Netzwerkadapter, Treiber, Switch-Konfiguration und die MTU die Leistung beeinflussen. Änderungen sollten immer anhand von Messwerten vorgenommen werden, da es keine allgemeingültigen iSCSI-Tuning-Parameter für jede Umgebung gibt.
Mit esxtop können auf einem VMware-Host Performance-Werte in Echtzeit untersucht werden. Für die Storage-Analyse sind unter anderem IOPS, Datendurchsatz sowie die Latenzwerte DAVG, KAVG und GAVG interessant. Damit lässt sich eingrenzen, ob Verzögerungen eher vom Storage-System, innerhalb des Hypervisors oder aus der gesamten I/O-Kette entstehen.
Für Virtualisierungsprojekte bieten wir die passenden Storage-Lösungen an, setzen Sie sich mit uns in Verbindung. Natürlich können Sie auch komplette Lösungen von uns bekommen. Egal zu welcher Virtualisierungssoftware, wir finden ein für Sie passendes Storage-System.
