Archive for the 'Storage' Category

HP EVA 4400 Fehler: 0x041F0032 Eva NVRAM Uptime invalid

Letzten Monat waren wir mit dem Problem konfrontiert, dass ein Controller unserer EVA 4400 (XCS 10.000) sekündlich folgende Fehlermeldung protokollierte:

Der Fehler selbst war zwar unkritisch und hatte I/O-technisch keinerlei Auswirkungen, führte aufgrund der schieren Menge an Meldungen aber dazu, dass relevante Informationen aus dem Log förmlich verdrängt wurden.

Darüberhinaus zog die Problematik eine permanent hohe CPU-Auslastung der SAN Management Appliance durch die Postgres Datenbank von WEBES nach sich. WEBES bzw. der dazugehörige System Event Analyzer analysiert die Meldungen und löst entsprechende Aktionen aus (z.B. automatische Eröffnung eines Case bei HP).

Dem Support von HP war der Fehler bis dato nicht bekannt und man riet zunächst zu folgender Vorgehensweise:

    From the description, have You tried a Full Power restart of the affected Controller ?
    Graceful Shutdown Reseat and start ?
    If not try that first

Ein Restart des Controllers ließ sich nicht mehr durchführen – nach dem Ausführen der Aktion in Command View verblieb der Controller im Operational State „Unknown“:

Ein Reseat des Controllers erweckte ihn schließlich wieder zum Leben, brachte aber einen „Soft Diagnostic Failure“ ans Licht. Erst nach einem nochmaligen Reboot (der dann funktionierte) fuhr der Controller fehlerfrei hoch. Exakt dasselbe Phänomen hatten wir mit demselben Controller auch schon beim Upgrade auf XCS 10.000.

Der ursprüngliche Fehler war zwar zunächst verschwunden, trat jedoch einen Tag später wieder auf. HP gab daraufhin grünes Licht zum Austausch des Controllers. Zumindest wollte man dies versuchen, bevor man einen Tausch der eigentlich unter Verdacht stehenden RiserCard des Controller Enclosures durchführt – für den das gesamte System hätte heruntergefahren werden müssen.

Der Tausch des Controllers ist im Dokument HP StorageWorks Controller Enclosure 4Gb Array Controller Replacement Instructions verständlich beschrieben und beschränkt sich im Prinzip auf folgende Schritte:

  1. I/O für den zu tauschenden Controller in Command View anhalten
  2. Kabel beschriften und entfernen
  3. Controller entfernen
  4. Controller öffnen, Speichermodule entnehmen und in neuen Controller einbauen
  5. neuen Controller halb einsetzen, verkabeln und danach einrasten

Sollte der Austauschcontroller mit einer älteren Software kommen, wird die neuere Version vom vorhandenen Controller übernommen. In unserem Fall hat der Vorgang ca. 30 Minuten gedauert und am Ende war zur Beseitigung aller Fehlermeldungen in Command View ein Neustart des Command View Dienstes erforderlich.

Seit dem Tausch des Controllers ist der Fehler mit der falschen NVRAM Uptime nicht mehr aufgetreten.

Advertisements

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