Archive for the 'HP StorageWorks' Category



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
Advertisements

Nur noch ein LUN Managing Controller auf einer EVA 4400?

Auch wenn die Vdisks bzw. LUNs einer EVA 4400 über beide Controller erreichbar sind, so können I/O Requests tatsächlich immer nur von einem – dem LUN Managing Controller – ausgeführt werden:

    When creating a virtual disk, one controller is selected to manage the virtual disk. Only this managing controller can issue I/Os to a virtual disk in response to a host read or write request. If a read I/O request arrives on the non-managing controller, the read request must be transferred to the managing controller for servicing. The managing controller issues the I/O request, caches the read data, and mirrors that data to the cache on the non-managing controller, which then transfers the read data to the host. Because this type of transaction, called a proxy read, requires additional overhead, it provides less than optimal performance. (There is little impact on a write request because all writes are mirrored in both controllers’ caches for fault protection.) [1]

Bei mehreren Vdisks möchte man diese also nach Möglichkeit gleichmäßig über beide Controller verteilen. Festgelegt wird das mittels der Einstellung „Preferred path/mode“ in den Eigenschaften der Vdisk in Command View. Path-A-Failover setzt den Managing Controller der Vdisk auf Controller 1, Path-B-Failover auf Controller 2.

Dabei gibt es noch eine Besonderheit zu beachten: Implicit LUN Transition. Wird der Großteil der Read Requests über den Non-Manging Controller empfangen, wird die Vdisk entsprechend verschoben:

    With implicit LUN transition, when the array detects that a majority of read requests for a virtual disk are proxy reads, the array transitions management of the virtual disk to the non-managing controller. This improves performance because the controller receiving most of the read requests becomes the managing controller, reducing proxy read overhead for subsequent I/Os. [1]

Je nach Konfiguration des angeschlossenen Hosts kann sich der Managing Controller einer Vdisk also nachträglich ändern.

Obwohl unsere Vdisks mittels der „Preferred path/mode“ Option auf beide Controller aufgeteilt sind, hatten wir seit einigen Wochen das Problem, dass nur noch Controller 1 als Managing Controller verwendet werden konnte. Kurz nach dem manuellen Festlegen von Controller 2 wurde die Konfiguration zwar übernommen, innerhalb von wenigen Sekunden aber wieder zurück auf Controller 1 geändert.

An der Implicit LUN Transition konnte das nicht liegen. Erstens wechselt diese den Controller nicht schon nach wenigen Sekunden und zweitens trat das Problem auch dann auf, wenn auf einem Host z.B. nur ein fester Pfad zu Controller 2 konfiguriert war.

Verursacht wird das Problem durch einen Firmwarefehler, der zu einem falschen Status der Cache Batterien führen kann. Der betroffene Controller verliert in diesem Fall alle LUN Ownerships und überträgt diese an den anderen Controller. Ersichtlich wird dies durch entsprechende Meldungen im Controller Event Log:

Neben einer sehr großen Anzahl an „An HSV300 controller has changed Battery Cache policy“ Ereignissen hat zumindest in unserem Fall (XCS 09522000) zusätzlich die linke Status LED von Batterie 1 (Controller 2) grün geblinkt (Maintenance in progress).

Beheben lässt sich das Verhalten durch einen Reboot des betroffenen Controllers. Verhindert wird es durch das Firmwareupdate auf XCS 0953400, in dessen Release Notes das Problem auch aufgeführt ist:

    Added a verification step to ensure that an accurate cache battery state is returned for HSV300 controllers to avoid falsely triggered cache policy changes.

Nach dem ersten Reboot von Controller 2 mittels WOCP blieb dieser beim Starten übrigens hängen und ließ sich erst nach einem Reseat (kurz rausziehen und wieder einstecken) wieder booten. Man sollte dabei also besser vor Ort sein.

Ich bin gespannt, ob und nach welcher Zeit das Problem wieder auftritt. Ansonsten ist das Update auf XCS 0953400 natürlich schon geplant.

[1] HP StorageWorks 4400 Enterprise Virtual Array user guide