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!

Storage VMotion 2 Quelldatastores

Moderatoren: irix, Dayworker

Member
Beiträge: 71
Registriert: 21.02.2011, 11:14

Storage VMotion 2 Quelldatastores

Beitragvon ribaadmin » 12.04.2016, 16:06

Hallo,
ich habe vsphere 5.5 im Einsatz mit u.a. einer VM die 2 VMDK hat.
1 kleine VMDK auf Datastore 1 und eine 1,5 TB VMDK auf Datastore 2.
Ich würde gerne Storage VMotion im laufenden Betrieb machen auf Datastore 3.
Geht das ohne Probleme? Hat da jemand Erfahrungswerte?

Danke und Gruß

Profi
Beiträge: 503
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 12.04.2016, 16:13

Ich wüsste nicht was dagegen sprechen sollte. Die VMDKs werden dann zusammen in einem DS gespeichert.

Experte
Beiträge: 1823
Registriert: 04.10.2011, 14:06

Beitragvon JustMe » 12.04.2016, 16:25

...hoechstens die Lizenz, falls die kein Live Storage vMotion beinhalten sollte...

Experte
Beiträge: 1337
Registriert: 25.04.2009, 11:17
Wohnort: Thüringen

Beitragvon Supi » 12.04.2016, 18:09

Und wenn das (ext.) Storage und und die Lizenz noch VAAI unterstützen, geht das auch bei 1,5TB recht schnell.

Profi
Beiträge: 993
Registriert: 31.03.2008, 17:26
Wohnort: Einzugsbereich des FC Schalke 04
Kontaktdaten:

Beitragvon kastlr » 14.04.2016, 11:12

Hallo zusammen,

nur mal so am Rande, VAAI ist dazu gedacht, den Host (und das Netzwerk) von solchen Tätigkeiten zu entlasten.
Aus Sicht des Arrays ändert sich so viel nicht, es muß in jedem Fall 1,5 TB kopieren und das dauert halt seine Zeit.

Daher melden moderne Arrays solche Jobs gerne schon mal als erledigt, obwohl der Copyjob im Hintergrund noch bearbeitet wird.

Deshalb scheinen die Jobs mit VAAI deutlich schneller zu sein als solche ohne VAAI.

Gruß,
Ralf

Experte
Beiträge: 1337
Registriert: 25.04.2009, 11:17
Wohnort: Thüringen

Beitragvon Supi » 14.04.2016, 11:33

@ kastlr,

wusste ich so ncht. Kann aber auch nur von einer MD3220i sprechen. Und zumindest da hatte ich ja direkt über die Verwaltungssoftware die Auslastung "überwacht".
Das sollte dann halbwegs passen.

Profi
Beiträge: 993
Registriert: 31.03.2008, 17:26
Wohnort: Einzugsbereich des FC Schalke 04
Kontaktdaten:

Beitragvon kastlr » 14.04.2016, 12:16

Na ja,

wenn die Daten verschoben werden sollen müssen Sie ja alle gelesen und anschließend aufs neue Ziel geschrieben werden.
Der Unterschied zwischen non VAAI und VAAI complaint arrays liegt an dem Weg, den die Daten dazu nehmen müssen.

Im ersten Fall erzeugt der ESXi Host eine entsprechende Anzahl von Read IO's gegen die Quelle und die erforderliche Anzahl von Write IO's gegen das Zieldevice.
Im zweiten Fall verlassen die IO's das Array zwar nicht, aber trotzdem müssen die Daten ja intern gelesen und anschließend wieder geschrieben werden.

Da moderne Arrays ja genau wissen wo sich die Daten zu jedem Zeitpunkt befinden melden Sie üblicherweise sehr schnell, das dieser Job erfolgreich abgeschlossen ist.
Externe IO Anfragen durch die VM werden dann entweder von der Quelle oder dem Ziel beantwortet, je nach dem, wo sich die angeforderten Daten zum Zeitpunkt der Abfrage befinden.

Somit ist die svMotion aus Sicht der VMware Umgebung ziemlich schnell abgearbeitet, während das Array intern noch gut damit beschäftigt ist.

Man kann das relativ gut testen, indem man versucht, eine running VM mit svMotion zu verschieben.
Wenn man die Meldung im VMware erhält das die VM migriert worden ist startet man unmittelbar im Anschluß eine weitere svMotion Operation mit dieser VM.

Alternativ kann man versuchen, mehrere parallele svMotion Sessions anstarten.
Nach meiner Erfahrung erhält man so ab 4 Sessions auf einmal SCSI Fehlermeldungen im Zusammenhang mit VAAI XCOPY Befehlen.

Gruß,
Ralf


Zurück zu „vSphere 5.5 / ESXi 5.5“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 16 Gäste