Alignment

[TOM_M]

Hallo,

wir setzen nun schon eine längere Zeit VMware - VSphere - VCenter ein und heute
hat uns ein "Berater" zugerufen, dass alle unsere VMs falsch angelegt wären und wir
ein erhebliches Performance-Problem hätten!!!!!!

"Falsches Alignment" war sein Schlagwort.

Irgendwie habe ich noch in meinen Gedanken gefunden, dass wir damals
(vor mehr als 4 Jahren) gezeigt bekommen haben, dass wir neue VMs mit dem
Assistenten anlegen sollen - hier wird abgefragt, welches Betriebssystem auf der
VM laufen soll und dadurch "richtig" angelegt wird!

SO, und nun diese Aussage!

Liegt der Berater hier richtig oder isser ein Sprücheklopfer???

Für jeden Tipp dankbar
TOM

[mbreidenbach]

Die unpräzise Kurzfassung ist daß vor Vista meist alles falsch und nach Vista meist alles richtig ist.

Das lisgt daran daß der Datenbereich bei XP/2003 normalerweise bei Sektor 63 losgeht und das führt eben dazu daß Blöcke 'oben' (OS) und 'unten' (Storage) nicht übereinstimmen. Das wiederum führt zu einem teilweise deutlich erhöhten I/O Aufwand.

Das Thema betrifft grundsätzlich alle Storagehersteller; manche reden drüber, andere nicht. Von NetApp gibts umfangreiche Abhandlungen zu dem Thema.

In der Praxis bewegt sich das irgendwo zwischen 'kann man so lassen es ist den Aufwand nicht wert' bis zu 'macht echt schlechte Performance'.

Einfach mal nach 'partition misalignment' googeln und lesen. Hier mal ein VMware Link zu dem Thema:

http://blogs.vmware.com/vsphere/2011/08 ... nment.html

[elgato319]

bzgl. Alignment

[irix]

@TOM,

entweder hab ihr was falsch verstanden oder nach 4 Jahren gibts es du es falsch wieder.

Wenn man im vSphere Client ueber die GUI Datastores anlegt so macht er das Alignment des VMFS richtig. Hat man es frueher auf der CMD gemacht und so war es dann Mis-alignent. Das ist der eine Teil.

Dann erzeugt ja jede GuestOS Installation ein weiteres FS und das kann VMware dann NICHT mehr beeinflussen. Hier muss das OS alles richtig machen oder die Filesystem muessen vorab präpariert werden.

Ja, ab >= VISTA und aktuellen Linux Versionen ist die Chance gross das das OS es selber hinbekommt. Aber wer Image basierte Deployments macht der sollte mal genauer hingucken. Wir hatten schon Faelle wo halt dieses Images Mis-aligned war bzw. dess automatischer Installer hat Mist gebaut hat.

Wie Gross der Impact ist kann man pauschal nicht sagen und es haengt einzig vom Storage und dessen Auslastung ab. Es gibt Systeme (so von EMC) welche mit einer extrem kleinen Blocksize arbeiten und da war der Overhead bei einem Mis-alignment nicht spuerbar. Anders kann es bei 64KB oder Groesser aussehen.

Das mbralign von Netapp kann das im Nachhinein korrigieren und auch auf Nicht NetApp funktioniert es . Allerdings war das zu ESX Zeiten. Wir hatten damals den Quest vOptimizer im Einsatz und haben die VMs konvertiert. Man sollte nur hinterher die vDISK wieder auf einen gerade Wert bringen. Weil das machen alle diese Tools nicht die machen es um einen krummen Wert nur groesser so das sie drinnen die Partition verschieben koennen.

Das Thema Alignment kommt mit dem vFRC wieder hoch weil dieser nur funktioniet wenn alles Aligned ist.

Gruss
Joerg

[mbreidenbach]

mbralign (aus VSC4.2) geht auch auf ESXi und auch ohne NetApp Storage drunter. Ich habs ausprobiert (ESXi 5.1U1 + HP SA P420).

[TOM_M]

@irix
Ja, der Supporter aus der damaligen Zeit hat uns erklärt, wie wir neue VMs anlegen.
Dies ging über die GUI am VCenter und wir haben dies auch anschließend immer so
durchgeführt. Sind somit alle so angelegten VMs korrekt "aligned"??

Was ist mit den P2V VMs - muß bei denen nachgebessert werden?

Und zu Abschluß noch die Frage zum Storage!
Funktioniert das NetApp "mbralign" auch bei anderen StorageSystemen??
(wir haben ein Dell Storage iSCSI am Laufen - EquiLogic wurde damals gerade zugekauft)

Danke für Eure schnelle Hilfe
TOM

[mbreidenbach]

Disk Alignment mit Windows Bordmitteln prüfen:

http://frankdenneman.nl/2009/05/20/wind ... alignment/

Alignmentprobleme können auf mehreren Ebenen auftreten:

Applikation (Ausrichtung der Daten innerhalb der Datei)
Partitionierung der VM (z.B. Partitionsanfang Sektor 63 bei Windows 2003; Sektor 64 wäre besser aber was wirklich richtig ist hängt von der Blockgröße des Storage Systems ab)
VMware Datastore (VMFS via Kommandozeile angelegt)

VMware VMFS Datastores die über vSphere Client angelegt wurden sind richtig 'aligned'.

Auf die anderen möglichen Ursachen von Misalignment hat der vSphere Client keinen Einfluß da er ja die VM nicht partitioniert bzw die Applikation nicht beeinflußt.

Was man jetzt tun sollte:

Prüfen welche VMs betroffen sind
Abschätzen wieviel I/O die so machen und ob das überhaupt einen Unterschied macht (wenn die VM kaum Disk IO macht dann wirkt sich das auch kaum aus; bei einem schwer arbeitendem File- oder Datenbankserver kann das aber ganz anders aussehen)
Falls Aktion erforderlich: Plan zur Korrektur machen. Es steht ja eine Downtime an und irgendwas kann immer schief gehen also sollte mit Backup&Recovery alles in Ordnung sein.

[Dayworker]

Ob und welche deine Gast-OS davon betroffen sind, können wir dir nicht sagen. Notfalls siehst du selbst nach und korrigierst das manuell. Ich hatte dazu letztes Jahr mal schnell das HowTo - Nachträgliches Alignment auf Sektor 2048 verfaßt.


Der IO-Verlust von Unaligned Partition wird aber mehr als die rechnerischen 25 Prozent betragen. Wenn der DS auf einer SSD eingerichtet ist, betrifft der Zugriff dann auch noch mehrere Sektoren mit grösseren Blöcken.

[irix]

@irix
Ja, der Supporter aus der damaligen Zeit hat uns erklärt, wie wir neue VMs anlegen.
Dies ging über die GUI am VCenter und wir haben dies auch anschließend immer so
durchgeführt. Sind somit alle so angelegten VMs korrekt "aligned"??

Nein!

Weil du es noch nicht ganz Ueberblickst. Es sind 2 Ebenen betroffen.

1. Ebene
VMFS. Wenn Datastore ueber GUI erstellt dann alles OK!

2. Ebene
GuestOS. Nicht in vSphere Hand. Es hat nichts damit zutun in vSphere auf den Knopf "Create VM" zu klicken. Der OS Installer muss es richten bzw. die vDISK werden Vor-formatiert. Bei alten Linuxen und da wo wie W2K3 nehmen "mussten" haben wir das dann gemacht.

Was ist mit den P2V VMs - muß bei denen nachgebessert werden?

Ja.

Und zu Abschluß noch die Frage zum Storage!
Funktioniert das NetApp "mbralign" auch bei anderen StorageSystemen??
(wir haben ein Dell Storage iSCSI am Laufen - EquiLogic wurde damals gerade zugekauft)

Danke für Eure schnelle Hilfe
TOM

Ja funktioniert auch bei anderen. Der Kunde mit Netapp hatte auch HP EVA.
Wir haben auch grossflaechig EqualLogic und dort gibts 64KB Blocksize. Wir haben damals den Quest vOptimizer verwendet.

Dann sollte EQL ja ueber 5 Jahre alt sein. Sag bescheid wenn ihr eine neue haben moechtet Gibt aktuell nette Promos wo so 24x300K SAS fuer 10K weggehen bzw. so "Double Capacity" bzw. "Free Upgrade 10GbE". Wer aber auf 10GbE gehen moechte dem Rate ich dringend den November anzuwarten weil sonst muessen Traenen getrocknet werden.

Gruss
Joerg

[TOM_M]

@mbreidenbach

OK,
ich glaube verstanden zu haben dass alle VMs, mit Server 2000 und Server 2003, nicht
richtig "aligned" sind - auch wenn diese dem Assistenen aus der VSphrere GUI erstellt wurden!
Entscheidend ist die Installation, der VM, und diese wird ganz normal von einer Installations-CD
gestartet und somit nur von Microsoft beeinflußt - also ab Sektor 63!!!

Richtig verstanden???

DANKE
TOM
PS: Ihr seid schneller bei schreiben, als ich beim lesen!!!

[Dayworker]

Jein. Du kannst die Win-Partition ja auch über eine WinPE-CD oder ein sonstiges Partitionierungsprogramm angelegt haben. Dir bleibt nichts anderes übrig, als selbst nachzusehen.
Wenn du damals nur die CDs von W2k und W2k3 vorliegen hattest, sind deine Partitionen mit Sicherheit unaligned.

[mbreidenbach]

Bei Windows 2000/2003 gibt es jedenfalls einen 'begründeten Anfangsverdacht' für Misalignment. Man kann die VMs auch so anlegen daß von Anfang an alles 'richtig' ist (z.B. Partitionen anlegen mit diskpart create partition primary align=64 oder sowas). Der sollte dann erstmal überprüft werden. Und dann immer mit der Ruhe... wenn das 4 Jahre misaligned war kommts auf ne Woche mehr oder weniger auch nicht an. Misalignment hat Performanceauswirkungen aber wie groß die sind hängt vom jeweiligen System ab (und den Plattenzugriffsmustern der laufenden Anwendungen).

[Dayworker]

Hattet ihr denn Performanceprobleme und habt den "Berater" darauf angesprochen oder kam das nebenbei raus, als ihr euch über ein vSphere-Upgrade unterhalten habt?

[TOM_M]

@Dayworker

Nein, keine Performanceprobleme - zumindest nicht bewußt!
Da wir dies von Anfang an so hatten, ist das auch nicht aufgefallen ........

Der Berater kommt immer mal wieder bei uns vorbei und will sich wichtig machen - setzt
bei der "technischen Leitung" solche Dinge ab und macht dadurch die Leute nervös!
Ob wir Probleme haben und sein "ich weiß was" auch etwas bringt, kann ich (er aber auch)
nicht sagen aber er ist wieder in aller Munde!!!!!
Der Type hat erkannt, dass unsere Leitung nicht hinter uns steht und er damit
immer wieder "Pluspunkte" sammeln kann.

Danke für Eure Tipps
TOM

[irix]

TOM,
schaut in das SANHQ sofern Unsicherheit herscht.

Innerhalb des Windows ist es ein Einzeiler um herauszubekommen obs Volumes gibt welche misaligend sind. Mein Kunde hatte sich da mal nen Nagios Check gemacht nur um mal zusehen wieveiele VMs betroffen sind. Wobei es gibt neben mbralign noch mbrcheck oder so aehnlich wo er von aussen prueft.

Solche Altlasten schleppen viele herum und jeder der XP/W2k3 hat sollte betroffen sein. Das Thema kocht alle paar Jahre mal hoch und war schon aktuell als das OS noch auf Physik war. Bei hoher Konsolidierungsrate und Einsatz eines SANs kann sich natuerlich da was konzentrieren.

Ich wuerde mich in der Form vorbereiten das du aufzeigen kannst das aktuell genug Performance vorhanden ist und evtl. Verbesserungen die Stoerungen durch Downtime bzw. evtl. Datenverlust das Risiko nicht Wert sind.

Im Zuge der XP/W2k3 Abloesung sollte sich das Problem ja von alleine minimieren

Gruss
Joerg

[TOM_M]

TOM,
schaut in das SANHQ sofern ........

..............
Im Zuge der XP/W2k3 Abloesung sollte sich das Problem ja von alleine minimieren

Gruss
Joerg

SANHQ????

Ja, wir haben schon einige Server durch Server 2008 ersetzt!
Zwischenzeitlich sind es vielleicht noch 5 "AltLasten"
darunter ein XP-Client - bei dem werde ich dies einfach mal prüfen
damit man (ICH) ein Gefühl dafür bekommt.

Danke für Eure Unterstützung
TOM

[Dayworker]

Wenn der "Berater" so der Hecht wäre, hätte er dieses Alignment-Manko bereits früher erkennen müssen. Gerade wenn man einen Kunden auf diese Problematik einschwört und ihm zumindest das Anlegen über den Assistenten nahelegt, sollte man sich regelmäßig von der Umsetzung überzeugen.

Egal. Sieh einfach selbst nach und wenn zumindest der Datastore korrekt angelegt wurde, ist der Rest auch nicht schwer. Ich hatte das Gast-Alignment für die Bebilderung meines HowTo so oft machen müssen, daß ich das danach im Schlaf gemacht habe.

[irix]

TOM,
schaut in das SANHQ sofern ........

..............
Im Zuge der XP/W2k3 Abloesung sollte sich das Problem ja von alleine minimieren

Gruss
Joerg

SANHQ????

Die extrem schicke Monitoring und Alarming Software fuer deine EQL. Viele Graphen und Kurven, IO Estimations sowie Aufzeichnung von Lastfaellen und wiederabspielen.

Ja, wir haben schon einige Server durch Server 2008 ersetzt!
Zwischenzeitlich sind es vielleicht noch 5 "AltLasten"

5? Also einen weniger als 6?
Sofern es sich nicht um HighPerformance SQL/FS Systeme handelt wuerde ich mal sagen so Sturm im Wasserglas
Wieviele passende VMs stehen denn den fuenfen gegenueber?

darunter ein XP-Client - bei dem werde ich dies einfach mal prüfen
damit man (ICH) ein Gefühl dafür bekommt.

Danke für Eure Unterstützung
TOM

Gruss
Joerg

[TOM_M]

5? Also einen weniger als 6?
Sofern es sich nicht um HighPerformance SQL/FS Systeme handelt wuerde ich mal sagen so Sturm im Wasserglas
Wieviele passende VMs stehen denn den fuenfen gegenueber?
Gruss
Joerg

Zwischenzeitlich haben wir ESX-Hosts mit ca. 20 VMs!
Also dann um die 15 2008er Server.

Danke
TOM

PS:Leider ist unser SQL Server immer noch auf Windows2003 zuhause.

[irix]

5? Also einen weniger als 6?
Sofern es sich nicht um HighPerformance SQL/FS Systeme handelt wuerde ich mal sagen so Sturm im Wasserglas
Wieviele passende VMs stehen denn den fuenfen gegenueber?
Gruss
Joerg

Zwischenzeitlich haben wir ESX-Hosts mit ca. 20 VMs!
Also dann um die 15 2008er Server.

Ohne nun die IO Auslastung zu kennen. Aber wenn das Faktor 10-100 waere dann, ja dann muss man sich da einen Kopf drum machen.

Danke
TOM

PS:Leider ist unser SQL Server immer noch auf Windows2003 zuhause.

Der SQL Server hat seine DBs ja nich auf C:, welches ja bei der Installation zwangsweise Automatisch erstellt wird, sonder auf d:, e:, f: jenach dem wo die TempDB, Log und Data Files liegen.
Wer vor 10 Jahren Microsoft Bestpractices gelesen und umgesetzt hat haette nurn die weiteren Laufwerke entsprechend angelegt mit passendem Alignment sowie auch einer NTFS Clustersize von 64KB.

Es kommt immer auf das Volume an wo am meisten IO herscht und nicht ob da alle Volumes aligned sind aber nur rum Ideln.

PS: Du hast eine PM.

Gruss
Joerg

[kastlr]

Hallo zusammen,

wenn dir das wirklich Sorgen macht, dann kannst du das ja relativ schnell ändern.

Disk Partition Alignment Best Practices for SQL Server

Um das umzusetzen könntest du z.B.

• neue virtuelle Disks hinzufügen
• gemäß SQL BP mit NTFS formatieren (aligned + 64KB Blocksize)
• SQL Server Dienste stoppen
• Files von alten unaligned NTFS Volumes auf neue aligned NTFS Volumes kopieren
• Laufwerksbuchstaben der alten Source Volumes auf die neuen Target Volumes übertragen
• den alten Source Volumes keinen Laufwerksbuchstaben geben
• die VM runterfahren
• die alten VMDKs abhängen (optional) und bei den neuen VMDKs die SCSI ID's anpassen (optional)

Das sollte es schon gewesen sein.

Gruß,
Ralf

[TOM_M]

Noch eine Frage zum Thema!

Betrifft dies eigentlich nicht nur Server mit kleinen Dateien??
Angenommen ich habe eine kleine Datei - ein Block groß!
Um diesen virtuellen Block zu lesen, der pysikalische über zwei Blöcke auf dem Storage geht,
muß der Storage zweimal zugreifen.
Lese ich eine Datei mit 100 virtuelle Blöcke, muß der Storage 101 mal zugreifen!
Somit sollte das Problem eigentlich nur bei Servern mit vielen kleinen Dateien auftreten!

Liege ich hier richtig??

DANKE
TOM

[kastlr]

Hallo Tom,

das ist wie bei einer Frage an Radio Eriwan, im Prinzip schon, aber...

Vefügt dein Array über einen Cache, prüft das Array bei jedem Read IO, ob sich die angeforderten Daten schon im Cache befinden.
Beim ersten von deinen 100 IO's ist das wahrscheinlich noch nicht der Fall, also muß das Array die Daten von der/n Platten lesen.
Wird bei einem (Front End) Request Daten angefordert, die im (Back End) auf zwei verschiedenen Blöcken liegen, müssen natürlich zwei (Back End) Read Requests durchgeführt werden.
Danach befinden sich die beiden Blöcke im Cache des Arrays.

Sofern der nächste Request also zeitnah kommt, könnte das Array diese Anfrage wahrscheinlich direkt aus dem Cache beantworten.
Zumindest ein Teil der angefordeten Daten sollten sich im Cache befinden, daher muß das Array auch nur den Teil der Daten aus dem Back End einlesen, der sich noch nicht im Cache befindet.

Ein entscheidender Punkt ist daher die Frage, mit welcher Blocksize dein Array intern arbeitet und welche Blocksize die erzeugten IO's haben.
Üblicherweise haben Arrays nämlich eine Blocksize von 32 oder 64KB.

Somit hängen die Auswirkungen eines "non aligned" Filesystems auch davon ab, wie die verwendete Blocksize ist.

Als Beispiel nehmen wir mal Windows, das verwendet 4 KB.
Bei deinem Array nehmen wir einfach mal 64KB Blocksize an.

Fordert die Windows VM nun Daten an, werden sie vom ESXi Server an das Array weitergegen, also erhält das Array einen Request, 4 KB zu lesen.
Da dein Array aber intern mit 64 KB arbeitet, liest es den/die 64KB Blöcke ein, in dem sich die angeforderten Daten befinden.
Im ungünstigsten Fall muß das Array also 2* 64KB Blöcke lesen, um den 4KB Read Request der Windows VM beantworten zu können.

Sofern bei den folgenden Requests die Daten noch im Cache sind, werden diese auch aus dem Cache beantwortet, eine Backend Aktivität ist nicht erforderlich (Cache Hit).


Bei Write IO's verhält es sich ähnlich, allerdings muß das Array ja auch noch die Parity berechnen.
Passt der Request in eine Back End Block, ändert sich an dem erforderlichen Aufwand zur Berechnung der Parity nichts.
Sobald der Write IO aber zwei Back End Blöcke betrifft, muß auch die Parity zweimal berechnet werden.

Hört sich alles nicht so schlimm an, und ist es auch nicht wirklich, solange du dein Array nicht zu sehr ausgelastet hast.
Ab einer Utilization von 65-75% ändert sich aber das Verhalten von Arrays, wenn die Anforderungen dann weiter steigen.
Bis zu diesem Bereich hat eine Erhöhung der IO Last nur minimale Auswirkungen auf die Response Zeit, verläst du diesen Bereich, haben kleine Änderungen an der Last größerer Auswirkungen auf die Antwortzeiten.

Durch "unaligned" Filesysteme erzeugst du unnötige Last und belegst Resourcen des Arrays, die in dieser Zeit für Front End IO's fehlen.
Messungen einiger Array Hersteller haben ergeben, das ein unaligned Filesystem ca. 10-12% langsamer ist als ein aligned Filesystem.

Gruß,
Ralf

[irix]

Er hat eine Dell EqualLogic welche mit den Standard 64KB arbeitet. Aber das Array ist/sollte nach den Aussagen so 5-6 Jahre alt sein und wenn die Hosts das auch sind dann sind letztere eher der Bottleneck.

Bei Umgebungen welche in wenig in die Jahre gekommen sind bzw. wo nicht mitbekommen wurde was sich so in den Jahren getan hat bleibt es halt auf dem Stand. Ich meine hier nicht technologisch sondern das was der Hersteller nachgeschoben hat an Software wie sein SANHQ und MeM.

Ohne SANHQ kann keine Aussage getroffen werden was die Auslastung angeht und ohne historische Daten kann man auch nichts ueber den Verlauf sagen.

Da es dann auch nur 5 von 20 VMs sind bedeutet das nicht den Untergang des Abendlandes. Allerdings ist da nun Politik im Spiel und das ist immer Unfair.

Gruss
Joerg

[TOM_M]

....
Da es dann auch nur 5 von 20 VMs sind bedeutet das nicht den Untergang des Abendlandes.
......

Das sehe ich auch so!
Das System brummt recht gut und wir arbeiten ja an der Ablösung - beim
SAN ist was ganz neues in der Pipeline!
Und PerformanceProbleme sind bisher nicht aufgefallen, dann kann es so schlimm
nicht sein, dass man nun einen Aufstand macht!!!!

...
Allerdings ist nun Politik im Spiel und das ist immer Unfair.
....

GENAU,
und unsere Heeresleitung läßt sich von sowas beeindrucken - nutzt dies sogar
um uns schlecht aussehen zu lassen!
Wir haben keinen einfachen Stand hier.

Trotzdem DANKE
TOM