Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Alignment
-
- King of the Hill
- Beiträge: 13561
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Na dann mußt du alle 3 Partitionen wieder geradebiegen.
Die Frage wäre allerdings, weshalb euer Gast überhaupt noch mehrere Partitionen und nicht gleich mehrere VMDKs hat? Beim P2V hättet ihr nur die Systempartition durch den Converter schleichen sehen müssen und hättet dann die restlichen Partitionen einfach über den Explorer kopiert. Diese Kopie auch im TB-Bereich ist in jedem Fall schneller als der bekanntermaßen lahme Converter.
Die Frage wäre allerdings, weshalb euer Gast überhaupt noch mehrere Partitionen und nicht gleich mehrere VMDKs hat? Beim P2V hättet ihr nur die Systempartition durch den Converter schleichen sehen müssen und hättet dann die restlichen Partitionen einfach über den Explorer kopiert. Diese Kopie auch im TB-Bereich ist in jedem Fall schneller als der bekanntermaßen lahme Converter.
-
- King of the Hill
- Beiträge: 12942
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Ein "wmic partition get BlockSize, StartingOffset, Name, Index" zeigt die Daten und StartingOffset sollte bei Modulus 4 einen Restwert von 0 haben.
Wie man das bei einem SQL Server korrigiert hat doch schon jemand hier im Thread beschrieben. In diesem speziellem Fall ist es ja relativ einfach.
Gruss
Joerg
Wie man das bei einem SQL Server korrigiert hat doch schon jemand hier im Thread beschrieben. In diesem speziellem Fall ist es ja relativ einfach.
Gruss
Joerg
@irix
Schau mal hier:
==================================================
BlockSize Index Name StartingOffset
512 0 Datentr„ger Nr. 0, Partition Nr. 0 32256
512 1 Datentr„ger Nr. 0, Partition Nr. 1 37663557120
==================================================
Deswegen habe ich nochmal gefragt!!
Danke
TOM
Schau mal hier:
==================================================
BlockSize Index Name StartingOffset
512 0 Datentr„ger Nr. 0, Partition Nr. 0 32256
512 1 Datentr„ger Nr. 0, Partition Nr. 1 37663557120
==================================================
Deswegen habe ich nochmal gefragt!!
Danke
TOM
-
- King of the Hill
- Beiträge: 12942
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Ach das waren ja Bytes somit erstmal durch 1024.
Wenn du deinen Wert von 32256 / 512Bytes rechnest bekommst du den Block 63 heraus. Die 32768 waeren 64KB und somit "rund" gewesen. Die meisten OS fangen heute bei 1MB an.
Gruss
Joerg
Code: Alles auswählen
s = "." ' Local Computer
Set obj = GetObject("winmgmts:\\" & s & "\root\CIMV2")
Set Items = obj.ExecQuery("SELECT * FROM Win32_DiskPartition",,48)
For Each Item in Items
Wscript.Echo "Disk: " & Item.DiskIndex & " Partition: " & ItemIndex & " StartingOffset: " & Item.StartingOffset/1024 & "KB"
Next
Wenn du deinen Wert von 32256 / 512Bytes rechnest bekommst du den Block 63 heraus. Die 32768 waeren 64KB und somit "rund" gewesen. Die meisten OS fangen heute bei 1MB an.
Gruss
Joerg
irix hat geschrieben:....
Lass dir mal "Size" und "PrimaryPartition" mitausgeben.
....
OK,
jetzt!!!!!
====================================================
Name Size StartingOffset
Datentr„ger Nr. 0, Partition Nr. 0 37663524864 32256
Datentr„ger Nr. 0, Partition Nr. 1 42327290880 37663557120
====================================================
Danke
TOM
PS: Der Offset der zweiten Partition darf aber auch höher sein oder muß dieser
direkt hiner der ersten Part. beginnen???
-
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo,
diese Aussage kann ich nicht bestätigen und zumindest für den Windows SQL Server hier trifft sie auch nicht zu!
Die erste Partition hat
Daher liegt der Offset der zweiten Partition 37663557120 / 512 = 73561635 wieder auf einem ungeradem Block und ist somit ebenfalls nicht aligned.
Gruß,
Ralf
diese Aussage kann ich nicht bestätigen und zumindest für den Windows SQL Server hier trifft sie auch nicht zu!
Die erste Partition hat
- einen Offset von 32256 Bytes (31,5 KB oder 63 Blöcke)
- eine Size von 37663524864 Bytes (ca. 35 GB)
Daher liegt der Offset der zweiten Partition 37663557120 / 512 = 73561635 wieder auf einem ungeradem Block und ist somit ebenfalls nicht aligned.
Gruß,
Ralf
kastlr hat geschrieben:.....
diese Aussage kann ich nicht bestätigen und zumindest für den Windows SQL Server hier trifft sie auch nicht zu!
.....
VORSICHT: Die Angaben aus meinem Posting mit den Partitionsgrößen war nicht unser
SQL Server - das waren die Daten meines XP-Clients. Diese hatte ich gepostet, da mir
das Verständnis zur Sache fehlte!
Zwischenzeitlich ist das aber abgeklärt.
DANKE dafür
TOM
ACHSO: Seit wann kennt man das "Alignment-Problem bei virtuellen Servern" eigentlich schon??
-
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Tom,
das Alignment Problem gibt es schon viele Jahre,und zwar in der phsikalischen und der virtuellen Welt.
Disk performance may be slower than expected when you use multiple disks in Windows Server 2003, in Windows XP, and in Windows 2000
Solltet Ihr bei der Erstinstallation des SQL Servers seine NTFS Volumes nicht aligned haben, hattet Ihr das "Performance Problem" mit dem SQL Server schon immer.
Verwunderlich ist dann eher, das eure "Heeresleitung" einen externen Berater benötigt, um dieses offensichtlich seit Jahren bestehende Performance Problem überhaupt wahrzunehmen.
Es muß doch eine Flut von User Beschwerden gegeben haben, oder ist das etwa nie jemandem aufgefallen???
Ralf
das Alignment Problem gibt es schon viele Jahre,und zwar in der phsikalischen und der virtuellen Welt.
Disk performance may be slower than expected when you use multiple disks in Windows Server 2003, in Windows XP, and in Windows 2000
Solltet Ihr bei der Erstinstallation des SQL Servers seine NTFS Volumes nicht aligned haben, hattet Ihr das "Performance Problem" mit dem SQL Server schon immer.
Verwunderlich ist dann eher, das eure "Heeresleitung" einen externen Berater benötigt, um dieses offensichtlich seit Jahren bestehende Performance Problem überhaupt wahrzunehmen.
Es muß doch eine Flut von User Beschwerden gegeben haben, oder ist das etwa nie jemandem aufgefallen???
Ralf
Hallo,
könnt Ihr mir nochmal unter die Arme greifen??
Ich habe folgende Partitionstabelle:
==================================================
BlockSize Index Name StartingOffset
512 0 Datentr„ger Nr. 0, Partition Nr. 0 32256
512 1 Datentr„ger Nr. 0, Partition Nr. 1 37663557120
==================================================
Hier möche ich "alignen" und stelle folgende Rechnung
Offset / Blockgröße = eine ganze Zahl (integer)
Warum ist 63 dann falsch??
Schubst mich mal hin!
DANKE
TOM
könnt Ihr mir nochmal unter die Arme greifen??
Ich habe folgende Partitionstabelle:
==================================================
BlockSize Index Name StartingOffset
512 0 Datentr„ger Nr. 0, Partition Nr. 0 32256
512 1 Datentr„ger Nr. 0, Partition Nr. 1 37663557120
==================================================
Hier möche ich "alignen" und stelle folgende Rechnung
Offset / Blockgröße = eine ganze Zahl (integer)
Warum ist 63 dann falsch??
Schubst mich mal hin!
DANKE
TOM
-
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Tom,
du wirst immer eine ganze Zahl erhalten, wenn du den PartitionOffset durch 512 teilst, da 512 der kleinste mögliche Teiler ist.
Wie bereits beschrieben ist die entscheidende Frage, wie das verwendete Array intern organisiert ist.
Disk Partition Alignment (Sector Alignment): Make the Case: Save Hundreds of Thousands of Dollars
Dein Array verwendet intern 64KB Blocksize, also solltest du deine Filesysteme mit einem Offset versehen, welcher durch 64KB teilbar ist.
Da 64KB 128 Blöcken entspricht, müßtest du den unter Starting Offset aufgeführten Wert durch (128 *512) = 65536 teilen.
Wenn du dann als Ergebnis eine ganze Zahl erhältst ist dein Filesystem aligned.
Gruß,
Ralf
du wirst immer eine ganze Zahl erhalten, wenn du den PartitionOffset durch 512 teilst, da 512 der kleinste mögliche Teiler ist.
Wie bereits beschrieben ist die entscheidende Frage, wie das verwendete Array intern organisiert ist.
Disk Partition Alignment (Sector Alignment): Make the Case: Save Hundreds of Thousands of Dollars
Dein Array verwendet intern 64KB Blocksize, also solltest du deine Filesysteme mit einem Offset versehen, welcher durch 64KB teilbar ist.
Da 64KB 128 Blöcken entspricht, müßtest du den unter Starting Offset aufgeführten Wert durch (128 *512) = 65536 teilen.
Wenn du dann als Ergebnis eine ganze Zahl erhältst ist dein Filesystem aligned.
Gruß,
Ralf
Hallo,
ich hatte oben schon mal nachgefragt, seit wann VMware dieses Problem mit dem GastOS bekannt ist
und keine Antwort bekommen. In dem VMware Blog, der hier
http://blogs.vmware.com/vsphere/2011/08 ... nment.html
genannt wurde, steht das Datum August 2012 !
Das Video zu der NetApp VSC, in der das Alignment erklärt wird,
https://www.youtube.com/watch?v=-pCfXO7DQio
ist ein Datum Oktober 2012 zu erkennen.
Hat das VMware vorher nicht gewusst???
Danke
TOM
ich hatte oben schon mal nachgefragt, seit wann VMware dieses Problem mit dem GastOS bekannt ist
und keine Antwort bekommen. In dem VMware Blog, der hier
http://blogs.vmware.com/vsphere/2011/08 ... nment.html
genannt wurde, steht das Datum August 2012 !
Das Video zu der NetApp VSC, in der das Alignment erklärt wird,
https://www.youtube.com/watch?v=-pCfXO7DQio
ist ein Datum Oktober 2012 zu erkennen.
Hat das VMware vorher nicht gewusst???
Danke
TOM
TOM_M hat geschrieben:Hallo,
ich hatte oben schon mal nachgefragt, seit wann VMware dieses Problem bekannt ist
und keine Antwort bekommen. In dem VMware Blog, der hier genannt wurde, steht
das Datum August 2012 !
Das Video zu der NetApp VSC, in der das Alignment erklärt wird, ist ein Datum Oktober 2012
zu erkennen.
Hat das VMware vorher nicht gewusst???
Danke
TOM
Das Problem ist schon lange bekannt und es ist ja auch nicht nur VMware betroffen, ich kenne das Problem schon seit 2008. Eine Antwort hast du auch schon bekommen.
kastlr hat geschrieben:Hallo Tom,
das Alignment Problem gibt es schon viele Jahre,und zwar in der phsikalischen und der virtuellen Welt.
Disk performance may be slower than expected when you use multiple disks in Windows Server 2003, in Windows XP, and in Windows 2000
Solltet Ihr bei der Erstinstallation des SQL Servers seine NTFS Volumes nicht aligned haben, hattet Ihr das "Performance Problem" mit dem SQL Server schon immer.
Verwunderlich ist dann eher, das eure "Heeresleitung" einen externen Berater benötigt, um dieses offensichtlich seit Jahren bestehende Performance Problem überhaupt wahrzunehmen.
Es muß doch eine Flut von User Beschwerden gegeben haben, oder ist das etwa nie jemandem aufgefallen???
Ralf
-
- King of the Hill
- Beiträge: 12942
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
VMware hat kein Problem was man daran erkennt das wenn man die GUI nimmt um ein VMFS zu erstellen sie das Alignment richtig machen. Das seit langer Zeit.
Du hast doch schon so viele Äxte das du ganze Wälder abholzen kannst. Welcher Baum versperrt dir denn noch die Sicht auf den Wald?
Was GuestOS Filesysteme angeht hat VMware nichts mit zutun.
Gruss
Joerg
Du hast doch schon so viele Äxte das du ganze Wälder abholzen kannst. Welcher Baum versperrt dir denn noch die Sicht auf den Wald?
Was GuestOS Filesysteme angeht hat VMware nichts mit zutun.
Gruss
Joerg
irix hat geschrieben:VMware hat kein Problem was man daran erkennt das wenn man die GUI nimmt um ein VMFS zu erstellen sie das Alignment richtig machen. Das seit langer Zeit.
OK, das ist bei uns auch so gemacht worden!
irix hat geschrieben:Du hast doch schon so viele Äxte das du ganze Wälder abholzen kannst. Welcher Baum versperrt dir denn noch die Sicht auf den Wald?
Was GuestOS Filesysteme angeht hat VMware nichts mit zutun.
Auch OK,
aber warum weisen die Beiden LINKs auf 3.+4. Quartal 2012 hin?
Ist dort das Thema erneut "hochgekocht" oder "Zufall"?
Danke
TOM
(der hoffentlich bald den Wald sieht!)
-
- King of the Hill
- Beiträge: 12942
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Ja das Kocht immer mal wieder hoch was daran liegt das auch nach 1971 noch Leute geboren sind.
Das Video ist halt aus dem Jahr 2012 weil Netapp eine neue Version ihrer VSC herausgebracht hat und man unter ESXi ja vieles anders machen muss als mit ESX. Bei letzterem hatte Netapp ein kleines Binary "mbralign" am Start welches in der RedHat basierten Service Konsole lief.
Wenn euer Storage kein VMFS nutzen wuerde, weil ihr anstelle von BLOCK ein Filelevel basiertes haettet welche dann NFS praesentiert waere VMware sogar komplett aussen vor, weil dann das Storage oder dessen Admin sorge tragen muss das sein WAFL, ZFS, EXT3, $whatever aligned ist.
Gruss
Joerg
Das Video ist halt aus dem Jahr 2012 weil Netapp eine neue Version ihrer VSC herausgebracht hat und man unter ESXi ja vieles anders machen muss als mit ESX. Bei letzterem hatte Netapp ein kleines Binary "mbralign" am Start welches in der RedHat basierten Service Konsole lief.
Wenn euer Storage kein VMFS nutzen wuerde, weil ihr anstelle von BLOCK ein Filelevel basiertes haettet welche dann NFS praesentiert waere VMware sogar komplett aussen vor, weil dann das Storage oder dessen Admin sorge tragen muss das sein WAFL, ZFS, EXT3, $whatever aligned ist.
Gruss
Joerg
-
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Peter,
dokumentierst du das denn auch ordentlich?
Denn wenn in der Zukunft mal das Array ausgetauscht wird, müssen die Daten ja migriert werden.
Und dann sind solche "Karteileichen" ein Quell purer Freude.
Man darf hierbei einfach nicht vergessen, das das eigentliche Problem von Microsoft's Ignoranz erzeugt worden ist, sich beim Anlegen von NTFS Filesystemen an allgemein gültige Standards zu halten.
Gruß
Ralf
dokumentierst du das denn auch ordentlich?
Denn wenn in der Zukunft mal das Array ausgetauscht wird, müssen die Daten ja migriert werden.
Und dann sind solche "Karteileichen" ein Quell purer Freude.
Man darf hierbei einfach nicht vergessen, das das eigentliche Problem von Microsoft's Ignoranz erzeugt worden ist, sich beim Anlegen von NTFS Filesystemen an allgemein gültige Standards zu halten.
Gruß
Ralf
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 10 Gäste