Virtualisierte RZ-Umgebungen berichten über I/O-Performance-Engpässe

Starnberg, 4. Febr. 2016 – Mögliche Beeinträchtigung bei Unternehmensanwendungen wie SQL oder Oracle durch virtual Machine - shared Storage - Disconnect...

Zum Hintergrund: die Virtualisierung der IT-Infrastruktur kann Applikationsseitig zu Beeinträchtigungen führen, besonders wenn das Storage- und das I/O-sizing nicht skalierbar und sauber auf die Server- und Virtual Machine - Umgebung abgestimmt ist (1). Auch bekannt als Noisy Neighbour- und I/O-Blender-Effekt treten diese Probleme gerne dann auf, wenn auf Grund der hohen VM-Density per Host plus einer Vielzahl an unterschiedlichsten virtualisierten Apps-Workloads diese nicht mehr kontrolliert auf die I/O-Kanäle und den shared Storage (SAN) „gemappt“ werden können. Die Workload-Profile erzeugen nicht vorhersehbare (randomized) non-sequential I/Os, also das Gegenteil von Cache-freundlichen sequentiellen Anfragen. Dieser Umstand tritt in einer eindeutigen Beziehung von Server / Applikation zu VM / Storage LUN so natürlich nicht auf, sollte aber im Rahmen von Verfügbarkeits- und Leistungsanforderungen moderner virtualisierter Anwendungen beachtet werden.

  • Die Leistungsfähigkeit moderner Server-CPUs und eine hohe Virtualisierungsrate im RZ (>70%) korreliert und beschleunigt potentielle Engpässe beim shared Storage I/O. Ältere Controller-Architekturen kommen in Bezug auf die Skalierbarkeit der geforderten Leistung (Cachegröße, Read-Write-Handling, high-latency HDDs, VMDK file locking etc.) schnell an ihre Grenzen, gerade wenn sehr viele VM’s gleichzeitig auf eine LUN zugreifen.

  • Moderne VM-Aware-Storagesysteme setzen hier an und verwalten den Speicher mit einem großen Cache intelligent (QoS) und granular in Bezug auf die direkte Korrelation pro VM zum jeweiligen Speicherort; auch liefern sie (real-time) Performance-Parameter für jede einzelne VM. Somit lassen sich Engpässe und hohe Latenzen pro-aktiv vermeiden und die Gesamt-Systemleistung wesentlich balancierter und vor allem automatisierter bereitstellen (Auto-tuning). Potentiell ein Engpass je nach Einsatzzweck bleibt die Leistungsfähigkeit der zugrunde liegenden Controller-Hardware-Architektur, die deshalb idealerweise als scale-out-System ausgeführt sein sollte.

Eine zweite Möglichkeit besteht darin, die Probleme direkt auf der Host-/Hypervisor-Ebene über Software-basierte Beschleunigung und Caching-Lösungen anzugehen. Aber auch hier stellt ein älteres Dual-Controller-Array eine potentiellen Schwachpunkt in Bezug auf die Skalierbarkeit auf der SAN-Seite dar. Daran würde übrigens auch der Einsatz von SSDs / Tiering innerhalb des Subsystems nur wenig ändern.

Performance Management Tools sind ein weiteres wichtiges pro-aktives Element bei der Verwaltung von leistungsfähigen virtuellen Umgebungen (z.B. VMware vRealize Operations Manager). Eine zusätzliche Herausforderung betrifft das Write-Management von Windows auf dem logischen Disk-Layer, das die Beziehung zwischen der E/A-Leistung und Daten berührt; in Verbindung mit dem I/O-Blender Effekt entstehen damit viele kleine, zufällig verteilte I/Os, die gerade HDD-seitig für Performanceprobleme sorgen können.

Der Einsatz von intelligenten Scale-out Flash-Lösungen kann in diesen Zusammenhängen einen wesentlicher Beschleunigungsfaktor für den (shared-) Storage und dessen Applikationen darstellen.

  • Eine scale-out-Architektur z.B. in Verbindung mit einem hierfür optimierten (Log structured Filesystem O/S (LSFS) verhindert typische I/O-Performance-Limitierungen auf der Controllerseite und skaliert durch intelligentes internes „I/O-Load-balancing“ sowie Caching. Erst die vertiefte logische Integration des Storage mit den Hostsystemen/VMs und Anwendungen erzielt den geforderten Mehrwert (z.B. robustes OpenStack Cinder API oder auch VMware VVOL – Integration etc. in Kombination mit pro-aktiven Performance Management Tools).

  • In Verbindung mit einer Beschleunigungs-Software auf der Hostseite (z.B. im Verbund mit clustered Server-side Storage auf Basis PCIe Flash) kann bei hochgradig virtualisierten Umgebungen mit tausenden VM’s/Anwendungen und hohen Anforderungen an den I/O eine flexibel skalierbare Architektur sowohl für Server (VM-) als auch den shared-Storage aufgebaut werden.

Umfrage zu Virtualisierung und I/O-Performance-Problemen

Die beschriebenen Probleme sind nicht theoretischer Natur, sondern betreffen IT-Infrastruktur-Verantwortliche ganz konkret. Im Laufe des letzten Jahres hat die Firma Condusiv Technologies hierzu 2.654 IT-Experten in einer ersten weltweiten Erhebung zum Thema I/O-Performance befragt. Hier die wichtigsten Erkenntnisse des Research „I/O Performance Survey Results“:

  • 77% aller Befragten berichteten nach dem Einsatz von Virtualisierung über I/O-Performance-Probleme

  • 36% berichten über (Kunden-)Beschwerden auf Grund von verlangsamten Antwortzeiten bei Unternehmensanwendungen wie MS SQL oder Oracle

  • 28% davon sprachen über I/O Engpässe, die es unmöglich machten, die virtualisierte Infrastruktur weiter zu skalieren


Um die I/O-Leistungsprobleme zu adressieren, wurden laut der Umfrage bislang folgende Maßnahmen ergriffen:

  • 51% beschafften ein neues SAN
  • 8% kauften PCIe flash cards
  • 17% setzten auf Server-side SSDs
  • 27% erwarben Storage-side SSDs
  • 16% setzten auf mehr SAS-Laufwerke
  • 6% setzten auf Hyper-konvergente Appliances

Für 2016 sieht laut Report die geplante Beschaffungsstrategie wie folgt aus:

  • 25% wollen ein neues SAN erwerben
  • 8% setzen auf PCIe Flash Cards
  • 16% setzen auf Server-side SSDs
  • 27% setzen auf Storage-side SSDs
  • 10% setzen auf mehr SAS-Drives
  • 8% setzen auf Hyper-konvergente Appliances
  • 35% planen derzeit keine Neuanschaffungen

Abb. 1: Bildquelle Condusiv Technologies, I/O Performance Survey Results, 2015

(1) Quelle: Condusiv Technologies