EVA 4400 am Limit und Performanceprobleme in VMware

Vor einigen Monaten hatte ich mit zeitweise gravierenden Performanceproblemen in unserer vSphere 4.1 Umgebung zu kämpfen. Unabhängig vom Host waren kurzzeitig alle Prozesse innerhalb der virtuellen Maschinen in Ihrer Performance deutlich eingeschränkt und selbst simple Aufgaben wie das Aufrufen des Windows Explorers innerhalb einer VM gingen extrem langsam vonstatten. Vom Gefühl her war es in etwa mit einem Rechner zu vergleichen, auf dem im Hintergrund ein manueller Virenscan durchgeführt wird und dessen Festplatte permanent an der I/O Grenze arbeitet.

Mangelnde Prozessorleistung und durch zu wenig physikalischen Arbeitsspeicher bedingtes Swapping konnte ich ausschließen, so dass als Ursache nur ein Engpass im Storagesystem oder ein unbekannter Fehler in Frage kommen konnte. Ein Blick in die Performance Charts der Hosts brachte schließlich starke Schwankungen in der Latenz des Storagesystems ans Licht, die zeitlich exakt mit den beschriebenen Phänomenen übereinstimmten:

Während die Latenz im Normalfall bei etwa 15 Millisekunden liegt, schwankte sie bei Auftritt der Probleme zwischen 20 und 100 Millisekunden. Mit sehr großer Wahrscheinlichkeit lag der Hund also irgendwo im Bereich des Storagesystems begraben.

Das Storagesystem besteht aus einer EVA 4400 mit einer Diskgroup aus (damals) 32x 10k 300GB FC Disks, die über zwei Fabrics mit drei ESXi Hosts und zwei Windows Servern verbunden ist. Um sich während des Auftretens der Probleme ein Bild über die Auslastung der EVA machen zu können, stand als nächster Schritt das Monitoring der EVA mittels EVAperf an.

Sollte EVAperf erstmalig zum Einsatz kommen, muss es auf dem entsprechenden SAN Management Rechner einmalig eingerichtet werden. Sofern noch nicht geschehen, wird zunächst der entsprechende Command View Host zur Liste bekannter Arrays in EVAperf hinzugefügt. Hierfür werden Benutzername und Passwort für Command View benötigt:

C:\Program Files\Hewlett-Packard\EVA Performance Monitor>evaperf.exe fnh sanma admin
password:
Verifying access ...

Host      Username Accessible
--------- -------- ----------
sanma     admin    Yes

Anschließend werden zur leichteren Identifikation einzelner Komponenten während des Monitorings die sogen. „Friendly Names“ (Namen der Vdisks etc.) geladen:

C:\Program Files\Hewlett-Packard\EVA Performance Monitor>evaperf.exe fn
Attempting to load names from host: sanma
ARRAY 6002-4563-56G1-HB01 EVA4400
Fetching Virtual Disk data for 5001-4380-04C5-EC00 EVA4400
Found 10 virtual disks
VDISK : 6005-09B4-000E-2CDF-0000-4000-00BB-0000 VMware\vmfs_lun1_r1:vraid1:3:b_failover
VDISK : 6005-09B4-000E-2CDF-0000-4000-00C9-0000 VMware\vmfs_lun3_r1:vraid1:3:b_failover
[...]

Danach stehen diverse Möglichkeiten zur Verfügung, mit denen die Auslastung des Arrays gemessen werden kann:

evaperf.exe as -cont   # Zeigt Gesamtauslastung des Arrays
evaperf.exe cs -cont   # Zeigt Auslastung der Controller
evaperf.exe vd -cont   # Zeigt Auslastung aller Vdisks/LUNs

Insbesondere hilfreich ist letztere Option. So lässt sich sehr leicht feststellen, welche Vdisk bzw. welcher angeschlossene Host das Array am stärksten fordert. Ein während der Problemphase laufendes Monitoring förderte schließlich folgendes Ergebnis zu Tage:

Wie bereits beschrieben, sind insgesamt drei ESXi Hosts sowie zwei Windows-Server an die EVA angeschlossen. Die im Bild sichtbaren Vdisks im Ordner „DWH“ gehören dabei zu den Windows-Systemen, während es sich bei den restlichen Vdisks um VMFS LUNs für die ESXi Hosts handelt.

Das Ergebnis des Monitorings war eindeutig: Während auf den VMFS LUNs kaum Last vorhanden war, ging auf der LUN eines Windows Systems mit insgesamt 2844 IOPS (50% Read/50% Write, 100% Random, 64KB Blocksize) bei einer Latenz von 18,5ms quasi „der Punk ab“ – und die Latenz der VMware LUNs nach oben. Wie sich später herausstellen sollte, war die EVA damit am Limit ihrer aktuellen Konfiguration.

Woher aber weiß man, wann die EVA am Limit ist? Zunächst benötigt man Referenzwerte, an denen man sich orientieren kann. Fündig wird man im HP StorageWorks 4400 Enterprise Virtual Array performance White paper:

Obiges Bild zeigt die zu erwartende Performance einer EVA 4400 mit 96x 15k 146GB FC Disks bei 100% Random Workloads mit 8KB Blocksize und RAID5. Beim Workload „OLTP“ (60% Read/40% Write) erreicht die EVA in dieser Konfiguration bei einer Latenz von 18,5ms etwa 11000 IOPS.

Bezogen auf unsere Konfiguration (32x 10k Disks) bedeutet das eine maximal mögliche Performance von etwa 3300 IOPS (1/3 von 11000 minus 10% für den Unterschied von 10k zu 15k). Unter Berücksichtigung des in unserem Fall größeren Workloads (64KB statt 8KB) und des höheren Anteils an Schreibzugriffen (50% zu 40%) sind die mittels EVAperf festgestellten 2844 IOPS ein passender Wert – der klar zeigt, dass die EVA sich damit am Limit befindet.

Ebenfalls überprüfen lässt sich die Performance, indem der Workload mit IOmeter nachgebildet und das Ergebnis mit den Werten aus dem Whitepaper und EVAperf verglichen wird. Die Total I/Os in IOmeter entsprechen dabei der Summe aus Read Req/s und Write Reqs/s in EVAperf.

Nach Identifikation des Storagesystems als Flaschenhals musste natürlich noch die Ursache für den großen Workload – auch „Heavy Hitter“ genannt – des Windows Systems herausgefunden werden. Das betreffende Windows System rechnet einen für Data Warehousing eingesetzten SQL Server 2008. Dessen Datenbanken liegen auf der LUN, auf der mittels EVAperf die hohe Auslastung festgestellt wurde.

Dank Windows Server 2008 Resource Monitor war der „Übeltäter“ schnell gefunden. Verantwortlich für die hohe Auslastung waren bestimmte Zugriffe auf die tempdb-Datenbank des SQL Servers, die exakt dem mittels EVAperf gemessenen Workload (50% Read/50% Write) entsprachen:

Die Lösung war dann relativ simpel: Herauslösen der tempdb-Datenbank auf lokale Festplatten des Servers, um den „Heavy Hitter“ Workload von der EVA zu bekommen. Nach Verschieben der tempdb-Datenbank waren die Performanceprobleme in der virtuellen Infrastruktur vollständig verschwunden. Auch die für den SQL Server bzw. das Data Warehousing zuständige Fachabteilung hatte durch die Verschiebung keine Nachteile; Nachrichten über Performanceprobleme haben uns nicht erreicht.

Virtuelle Maschinen sollten also nicht gemeinsam mit Heavy Hittern auf einem SAN gehostet werden. Man muss sich darüber im Klaren sein, dass im Fall der Virtualisierung mitunter dutzende Systeme von entsprechenden Performanceproblemen betroffen sein können und nicht wie früher nur drei oder vier Server. Virtuelle Infrastrukturen sollten demnach möglichst über eigene Speichersysteme verfügen oder zumindest so autark sein (z.B. durch eigene Diskgroups), dass sie nicht durch andere Systeme beeinflusst werden können.

Wer übrigens das EVA Performance Whitepaper aufmerksam liest, wird feststellen, dass die EVA insbesondere bei OLTP Workloads mit RAID1 wesentlich besser performt, als mit RAID5:

Wie im obigen Bild dargestellt, sind bei einer Latenz von 18,5ms mit RAID1 17500 IOPS statt lediglich 11000 IOPS mit RAID5 möglich. Dies hat uns dazu veranlasst, die EVA von 32 auf 36 Festplatten zu erweitern und den zusätzlichen Speicher zur Umwandlung der VMFS LUNs von Vraid5 in Vraid1 zu nutzen.

Für einen Vorher-Nachher-Test eignet sich IOmeter, für das es im Open unofficial storage performance thread bei VMware Communities eine gute Vorlage gibt. Sollte der Link nicht mehr funktionieren, muss lediglich folgender Text als ICF Datei gespeichert und in IOmeter geöffnet werden:


Version 2004.07.30 
'TEST SETUP ==================================================================== 
'Test Description 
IO-Test 
'Run Time 
' hours minutes seconds 
0 5 0 
'Ramp Up Time (s) 
0 
'Default Disk Workers to Spawn 
NUMBER_OF_CPUS 
'Default Network Workers to Spawn 
0 
'Record Results 
ALL 
'Worker Cycling 
' start step step type 
1 5 LINEAR 
'Disk Cycling 
' start step step type 
1 1 LINEAR 
'Queue Depth Cycling 
' start end step step type 
8 128 2 EXPONENTIAL 
'Test Type 
NORMAL 
'END test setup 
'RESULTS DISPLAY =============================================================== 
'Update Frequency,Update Type 
4,WHOLE_TEST 
'Bar chart 1 statistic 
Total I/Os per Second 
'Bar chart 2 statistic 
Total MBs per Second 
'Bar chart 3 statistic 
Average I/O Response Time (ms) 
'Bar chart 4 statistic 
Maximum I/O Response Time (ms) 
'Bar chart 5 statistic 
% CPU Utilization (total) 
'Bar chart 6 statistic 
Total Error Count 
'END results display 
'ACCESS SPECIFICATIONS ========================================================= 
'Access specification name,default assignment 
Max Throughput-100%Read,ALL 
'size,% of size,% reads,% random,delay,burst,align,reply 
32768,100,100,0,0,1,0,0 
'Access specification name,default assignment 
RealLife-60%Rand-65%Read,ALL 
'size,% of size,% reads,% random,delay,burst,align,reply 
8192,100,65,60,0,1,0,0 
'Access specification name,default assignment 
Max Throughput-50%Read,ALL 
'size,% of size,% reads,% random,delay,burst,align,reply 
32768,100,50,0,0,1,0,0 
'Access specification name,default assignment 
Random-8k-70%Read,ALL 
'size,% of size,% reads,% random,delay,burst,align,reply 
8192,100,70,100,0,1,0,0 
'END access specifications 
'MANAGER LIST ================================================================== 
'Manager ID, manager name 
1,PB-W2K3-04 
'Manager network address 
193.27.20.145 
'Worker 
Worker 1 
'Worker type 
DISK 
'Default target settings for worker 
'Number of outstanding IOs,test connection rate,transactions per connection 
64,ENABLED,500 
'Disk maximum size,starting sector 
8000000,0 
'End default target settings for worker 
'Assigned access specs 
'End assigned access specs 
'Target assignments 
'Target 
C: 
'Target type 
DISK 
'End target 
'End target assignments 
'End worker 
'End manager 
'END manager list 
Version 2004.07.30 

Ich habe den Test sowohl mit der alten als auch mit der neuen Konfiguration durchgeführt und denke die Ergebnisse sprechen für sich:

32 HDDs, Vraid5

Test Name Response Time IOPS MB/s
Max Throughput-100%Read 2,67 10.809 337,78
RealLife-60%Rand-65%Read 8,29 3.055 23,87
Max Throughput-50%Read 34,03 1.530 47,81
Random-8k-70%Read 8,64 2.866 22,39

36 HDDs, Vraid1

Test Name Response Time IOPS MB/s
Max Throughput-100%Read 5,09 11.686 365,20
RealLife-60%Rand-65%Read 10,84 4.284 33,47
Max Throughput-50%Read 6,63 5.113 159,78
Random-8k-70%Read 10,41 4.783 37,37

0 Responses to “EVA 4400 am Limit und Performanceprobleme in VMware”



  1. Schreibe einen Kommentar

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s





%d Bloggern gefällt das: