139689
Jul 28, 2022, updated at 13:02:33 (UTC)
1942
15
0
Ablauf Ersetzung Storage (FC)
Hallo zusammen,
wir betreiben bei uns 3 physikalische Server (Lenovo & HP), die via FibreChannel (LC-Anschluss) mit einer Lenovo Storewize V3700 Storage angeschlossen sind.
Die Server sind wie so oft ESXi Server in der aktuellen Version 7 und werden über ein lizenziertes vcenter verwaltet.
Auf der Storage sind 6 LUNs und alles ist eben via FC verbunden
Jeder Server ist kreuzweise angeschlossen an Controller A und B der Storage. Die Anschlüsse sind direkt. Es gibt keine FC Switches dazwischen
Zusätzlich hab ich einen Standalone free ESXi Host, mit dem ich was probieren kann.
Ziel:
Die V3700 durch die neue Storage ersetzen.
Gibt es hier gute Best-Practice Vorgehensweisen für den Austausch?
HA ist in der Umgebung aktiviert, aber kein DRS, das dazwischenpfuschen kann.
Meine Überlegung:
- Neue Storage erstmal fertig einrichten (IPs, LUNs, WWN vordefinieren...). Mit dem Test-ESXi kann man was simulieren.
- 1 Host soweit nur mit unproblematischen VMs betreiben und 1 Controller auf neue Storage umhängen.
- 1 VM mal testweise mit vMotion verschieben. Diese läuft natürlich dann nur auf diesen einem Host
-- Ausreichende Testphase. In der Zeit ist jener ESXi Host natürlich nur einseitig angebunden --
- Weitere VMs verschieben
- Einen zweiten ESXi Host umhängen und weitere VMs verschieben. Ggf. kann man den ersten ESXi Host jetzt schon komplett umhängen
- Finalisieren, bis alle VMs mit vMotion verschoben wurden, alte Storage dann entfernen.
... dieses Reissverschluss-artige Vorgehen hängt daran, wie schnell und sauber es läuft und wie schnell man vorgehen will.
Ist das Vorgehen so in Ordnung oder gibt es bessere Ansätze? Ich nehme an, die Storage zu ersetzen wird in vielen Umgebungen reine Routine sein...
Neue Server sind geplant, aber das wird noch länger dauern.
Ob das Umstecken der FC Anschlüsse so problemlos ist, kann ich nicht beurteilen und der Punkt, wo ich mir am meisten unschlüssig bin.
..ich hoffe, ich habe die Daten verständlich beschrieben. Wenn nicht, würde ich das noch nachträglich ergänzen.
besten Dank!
wir betreiben bei uns 3 physikalische Server (Lenovo & HP), die via FibreChannel (LC-Anschluss) mit einer Lenovo Storewize V3700 Storage angeschlossen sind.
Die Server sind wie so oft ESXi Server in der aktuellen Version 7 und werden über ein lizenziertes vcenter verwaltet.
Auf der Storage sind 6 LUNs und alles ist eben via FC verbunden
Jeder Server ist kreuzweise angeschlossen an Controller A und B der Storage. Die Anschlüsse sind direkt. Es gibt keine FC Switches dazwischen
Zusätzlich hab ich einen Standalone free ESXi Host, mit dem ich was probieren kann.
Ziel:
Die V3700 durch die neue Storage ersetzen.
Gibt es hier gute Best-Practice Vorgehensweisen für den Austausch?
HA ist in der Umgebung aktiviert, aber kein DRS, das dazwischenpfuschen kann.
Meine Überlegung:
- Neue Storage erstmal fertig einrichten (IPs, LUNs, WWN vordefinieren...). Mit dem Test-ESXi kann man was simulieren.
- 1 Host soweit nur mit unproblematischen VMs betreiben und 1 Controller auf neue Storage umhängen.
- 1 VM mal testweise mit vMotion verschieben. Diese läuft natürlich dann nur auf diesen einem Host
-- Ausreichende Testphase. In der Zeit ist jener ESXi Host natürlich nur einseitig angebunden --
- Weitere VMs verschieben
- Einen zweiten ESXi Host umhängen und weitere VMs verschieben. Ggf. kann man den ersten ESXi Host jetzt schon komplett umhängen
- Finalisieren, bis alle VMs mit vMotion verschoben wurden, alte Storage dann entfernen.
... dieses Reissverschluss-artige Vorgehen hängt daran, wie schnell und sauber es läuft und wie schnell man vorgehen will.
Ist das Vorgehen so in Ordnung oder gibt es bessere Ansätze? Ich nehme an, die Storage zu ersetzen wird in vielen Umgebungen reine Routine sein...
Neue Server sind geplant, aber das wird noch länger dauern.
Ob das Umstecken der FC Anschlüsse so problemlos ist, kann ich nicht beurteilen und der Punkt, wo ich mir am meisten unschlüssig bin.
..ich hoffe, ich habe die Daten verständlich beschrieben. Wenn nicht, würde ich das noch nachträglich ergänzen.
besten Dank!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 3473800101
Url: https://administrator.de/contentid/3473800101
Printed on: April 26, 2024 at 10:04 o'clock
15 Comments
Latest comment
Moin,
FC-Switche setzt ihr nicht ein, richtig?
Das würde das erheblich vereinfachen.
Es gibt auch die Möglichkeit, dass die Storwize selbst die Daten rüberholt, Verkabelungsmöglichkeiten vorausgesetzt:
https://www.ibm.com/docs/en/flashsystem-5x00/8.3.x?topic=mdbusc-migratin ...
Sinngemäß:
Im Details kann ich dir das aber nicht genau sagen, da wir das immer (in unserem Dabeisein) vom ext. Dienstleister machen lassen. Die Befehle merke ich mir nicht, weiss aber im groben, was da so passiert...
Ich nehme an, die Storage zu ersetzen wird in vielen Umgebungen reine Routine sein...
Jo, per se kein Problem.FC-Switche setzt ihr nicht ein, richtig?
Das würde das erheblich vereinfachen.
Es gibt auch die Möglichkeit, dass die Storwize selbst die Daten rüberholt, Verkabelungsmöglichkeiten vorausgesetzt:
https://www.ibm.com/docs/en/flashsystem-5x00/8.3.x?topic=mdbusc-migratin ...
Sinngemäß:
- Die Storwize schaufeln die Daten im Hintergrund rüber
- die Hosts werden (transparent) durchgereicht.
- Wenn die Datenmigration durch ist, verkabelst du die Hosts um
Im Details kann ich dir das aber nicht genau sagen, da wir das immer (in unserem Dabeisein) vom ext. Dienstleister machen lassen. Die Befehle merke ich mir nicht, weiss aber im groben, was da so passiert...
1
Servus - Danke für die Antwort!
Nein, keine FC-Switches. Werde ich im Ausgangspost noch ergänzen!
Das rüberkopieren von Storage zu Storage ist so ein Lizenzthema...richtig? Und wenn ich richtig lese, ist das eine Offline-Operation. Aber wann lese ich schon richtig?
Ich meine, ich werde für ein paar Sachen definitiv noch Supporteinheiten anfordern, aber ich möchte zum einen weiter dazulernen und selber machen. Zum anderen eben selber vorbereiten und auch wenn Google mein Freund ist, hat er mir hier nicht soviel weitergeholfen.
Das reine verschieben hab ich schon 2x selbst gemacht, das geht so.
Was ich noch nie gemacht habe ist eben die Storage selbst zu konfigurieren und bei der letzten Migration (andere Firma) hatten wir schon 2 Umgebungen parallel aufgesetzt. Dies ist hier nicht der Fall
Nein, keine FC-Switches. Werde ich im Ausgangspost noch ergänzen!
Das rüberkopieren von Storage zu Storage ist so ein Lizenzthema...richtig? Und wenn ich richtig lese, ist das eine Offline-Operation. Aber wann lese ich schon richtig?
Stop all host I/O operations.
Unmap the logical drives that contain the data from the hosts.Ich meine, ich werde für ein paar Sachen definitiv noch Supporteinheiten anfordern, aber ich möchte zum einen weiter dazulernen und selber machen. Zum anderen eben selber vorbereiten und auch wenn Google mein Freund ist, hat er mir hier nicht soviel weitergeholfen.
Das reine verschieben hab ich schon 2x selbst gemacht, das geht so.
Was ich noch nie gemacht habe ist eben die Storage selbst zu konfigurieren und bei der letzten Migration (andere Firma) hatten wir schon 2 Umgebungen parallel aufgesetzt. Dies ist hier nicht der Fall
Die ESXi und vCenter-Testversionen können Storage-vMotion.
Die OEMs haben dafür eigentlich immer eine Prozedur, IBM/Lenovo natürlich auch. Allerding gibt sich IBM nciht mit Leber, Lunge, Nieren und deine Schwester zufrieden.
Du brauchst also alternativ Geld, wenn die Kreativität nicht reicht.
(Und nicht vergessen: Stolz sein IBM gekauft zu haben)
Die OEMs haben dafür eigentlich immer eine Prozedur, IBM/Lenovo natürlich auch. Allerding gibt sich IBM nciht mit Leber, Lunge, Nieren und deine Schwester zufrieden.
Du brauchst also alternativ Geld, wenn die Kreativität nicht reicht.
(Und nicht vergessen: Stolz sein IBM gekauft zu haben)
Hallo,
wenn ich dich richtig verstehe heißt das, dass IBM dafür - wie ich vermutet habe - extra Geld will, wenn man direkt kopieren möchte.
Mit Stolz hat das nix zutun... eher mit "Beständigkeit" und weil man es hat/kennt. Der Anbieter hat es angeboten und weil er es liefern kann. Ob IBM, Dell oder HP ist mir da eher einerlei...
Dann lieber "Kreativität" und so, wie ich beschrieben habe, denke ich.
wenn ich dich richtig verstehe heißt das, dass IBM dafür - wie ich vermutet habe - extra Geld will, wenn man direkt kopieren möchte.
Mit Stolz hat das nix zutun... eher mit "Beständigkeit" und weil man es hat/kennt. Der Anbieter hat es angeboten und weil er es liefern kann. Ob IBM, Dell oder HP ist mir da eher einerlei...
Dann lieber "Kreativität" und so, wie ich beschrieben habe, denke ich.
Du hast im Prinzip fünf Möglichkeiten:
a) Du hängst Switches rein und bindest beide SANs gleichzeitig an.
b) Du packst in den Host weitere FC Ports und bindest beide SANs an alle Hosts direkt an.
c) Du machst b) mit einem Host der die Daten migriert und steckst dann alle anderen Hosts nach der Migration um.
d) Du überträgst die Daten direkt (Herstellerspezifisch und eventuell teuer).
e) Du speicherst die Daten auf einem Datenträger am Host, hängst den Host an die neue SAN und lädst die Daten wieder auf die SAN.
c) ist meist günstig und problemlos, OS ist ja schon fast egal. Aber es bedeutet Downtime
a) Du hängst Switches rein und bindest beide SANs gleichzeitig an.
b) Du packst in den Host weitere FC Ports und bindest beide SANs an alle Hosts direkt an.
c) Du machst b) mit einem Host der die Daten migriert und steckst dann alle anderen Hosts nach der Migration um.
d) Du überträgst die Daten direkt (Herstellerspezifisch und eventuell teuer).
e) Du speicherst die Daten auf einem Datenträger am Host, hängst den Host an die neue SAN und lädst die Daten wieder auf die SAN.
c) ist meist günstig und problemlos, OS ist ja schon fast egal. Aber es bedeutet Downtime
1
Servus @139689,
hast du einen solchen Umbau denn schonmal gestemmt?
Evt. macht es schon Sinn sich einen ext. Dienstleister dazu zu holen und das ganze mit dem zusammen durchzugehen.
Wenn auf einmal was hängt/bockt wo du nicht mehr weiter kommst wirds im schlimmsten Fall richtig teuer.
Bei uns steht bald der Einzug neuer Server an. In dem Zuge wird auch unser Datacore Konstrukt umgebaut nach vielem hin und her haben wir den Umzug dann als Dienstleistung dazu genommen aber ich habe schon mit dem Techniker vom Systemhaus ausgemacht dass ich den Umzug begleiten werden und die mir dann zeigen und erklären was gemacht wird.
Fand die Regelung so ganz gut. Wir können uns sicher sein dass der Umbau danach auch ohne Probleme funktioniert bzw. im Problemfall das Systemhaus nachbessern muss und ich kann weitere Erfahrungen sammeln.
hast du einen solchen Umbau denn schonmal gestemmt?
Evt. macht es schon Sinn sich einen ext. Dienstleister dazu zu holen und das ganze mit dem zusammen durchzugehen.
Wenn auf einmal was hängt/bockt wo du nicht mehr weiter kommst wirds im schlimmsten Fall richtig teuer.
Bei uns steht bald der Einzug neuer Server an. In dem Zuge wird auch unser Datacore Konstrukt umgebaut nach vielem hin und her haben wir den Umzug dann als Dienstleistung dazu genommen aber ich habe schon mit dem Techniker vom Systemhaus ausgemacht dass ich den Umzug begleiten werden und die mir dann zeigen und erklären was gemacht wird.
Fand die Regelung so ganz gut. Wir können uns sicher sein dass der Umbau danach auch ohne Probleme funktioniert bzw. im Problemfall das Systemhaus nachbessern muss und ich kann weitere Erfahrungen sammeln.
1Zitat von @139689:
Hallo,
wenn ich dich richtig verstehe heißt das, dass IBM dafür - wie ich vermutet habe - extra Geld will, wenn man direkt kopieren möchte.
Mit Stolz hat das nix zutun... eher mit "Beständigkeit" und weil man es hat/kennt. Der Anbieter hat es angeboten und weil er es liefern kann. Ob IBM, Dell oder HP ist mir da eher einerlei...
Dann lieber "Kreativität" und so, wie ich beschrieben habe, denke ich.
Hallo,
wenn ich dich richtig verstehe heißt das, dass IBM dafür - wie ich vermutet habe - extra Geld will, wenn man direkt kopieren möchte.
Mit Stolz hat das nix zutun... eher mit "Beständigkeit" und weil man es hat/kennt. Der Anbieter hat es angeboten und weil er es liefern kann. Ob IBM, Dell oder HP ist mir da eher einerlei...
Dann lieber "Kreativität" und so, wie ich beschrieben habe, denke ich.
Typischerweise kommt jemand für einen Tag mit z. B. einem SVC um die Ecke hängt den ans SAN und kopiert deine LUNs und schaltet dann die alten Pfade ab. oder erklärt die gleich, dass du die SVCs brauchst, weil IBM blabla
Kein großes Ding eigentlich, weil du den ESXI viele Pfade unterjubeln und nehmen kannst im laufenden Betrieb.
Ich würde die Testversion nehmen und Stroage vMotion machen.
1
Moin,
stimmt, das FlashCopy-Gedöhns ist eine zu lizensierende Funktion. Da hatte ich nicht dran gedacht
Das Umkabeln muss dann nur sehr gut vorbereitet werden, wenn das im laufenden Betrift, ohne den Ausfall eines Hosts laufen soll.
Alles ist hier ohne Gewähr und aus dem Kopf zusammengeschrieben. Aktiv hab ich das so noch nie umgesetzt, da unsere Infrastruktur immer einfachere Möglichkeiten bot.
Bei der Gelegenheit: euer SPOF ist derzeit das Storage, richtig?
Was macht ihr, wenn das mal ausfällt?
stimmt, das FlashCopy-Gedöhns ist eine zu lizensierende Funktion. Da hatte ich nicht dran gedacht
Der Anbieter hat es angeboten und weil er es liefern kann.
KEnnt ihr den Anbieter gut? vielleicht kann der euch für 2-3 Tage nen FC-Switch ausleihen. EIner wird - dank Zoning - vermutlich ausreichen.Das Umkabeln muss dann nur sehr gut vorbereitet werden, wenn das im laufenden Betrift, ohne den Ausfall eines Hosts laufen soll.
- V5035 und FC-Switch verbinden
- Host A in den Wartungsmodus versetzen (sodass keine VM drauf läuft)
- Host A an den Switch anbinden
- Zone A mit Host A-Port 1 + V5035 Node A, Port 1 anlegen + V5035 Node B, Port 1 anlegen
- Zone B mit Host A-Port 2 + V5035 Node A, Port 2 anlegen + V5035 Node B, Port 2 anlegen
- V3700 mit den freien Ports an den SAN-Switch anschließen und in die beiden Zonen aufnehmen
- An der V5035 nach neuen Hosts suchen und dort den Host A mit einer neuen LUN anlegen
- Host A sollte nun die neue LUN (und die alten) sehen.
- Jetzt den Wartungsmodus beenden, und die VMs auf Host A migieren
- Ist das erfolgreich erfolgt, die Daten per Storage vMotion aufs neue SAN verschieben
- sind die alten LUNs leer, kannst du Host B in die Wartung versetzen...
- ... und von der V3700 abkabeln und direkt an die V5035 anschließen
- Host B auf der V5035 mit in die LUN-Zuordnung aufnehmen
- am Host B prüfen, welche LUNs noch gefunden werden
- (ggf. alle VMs auf Host B migrieren)
- Host A in die Wartung versetzen, den SAN-Switch "ausbauen" und Host A direkt mit der V5035 verkabeln
- Prüfe, ob Host A noch in der Hostzuordnung an der V5035 zu sehen ist
- wenn jetzt alles passt, kannst du die VMs wieder normal verteilen.
Alles ist hier ohne Gewähr und aus dem Kopf zusammengeschrieben. Aktiv hab ich das so noch nie umgesetzt, da unsere Infrastruktur immer einfachere Möglichkeiten bot.
Bei der Gelegenheit: euer SPOF ist derzeit das Storage, richtig?
Was macht ihr, wenn das mal ausfällt?
1
Ich hab einen Dienstleister und auch einen kleinen Stundenpool. Aber den größten
Teil möchte ich selbst machen. Und nunja... die Recherche dafür ist u.a. hier
Ich wollte mir Rat einholen, ob die Reihenfolge so passt für dieses "Standard-Prozedere"
Vermutlich werd ich mit dem Dienstleister das noch kurz absprechen.
@Njord90
2x in meiner vorherigen Firma mit begleitet.
In beiden Fällen wurde es vorher konfiguriert.
Beim ersten Mal weiß ich nicht mehr, wie es angeschlossen war. Hier hab ich nur das storage vmotion gemacht.
Beim zweiten Mal waren es 2 unterschiedliche vcenter, die via einem iSCSI Storage gekoppelt wurden. Also anderes Szenario
das Storage vMotion usw. dann alles allein gemacht... war kein Problem dabei.
@2423392070
Ich frage den Dienstleister mal, ob sie so einen SVC haben...
@em-pie
Der Dienstleister hat zumindest der Firma die letzten 2 Umgebungen verkauft und ja, wir machen öfter was mit denen.
einen FC-Switch finde ich dauerhaft für uns übertrieben. Ausleihen könnte gehen...
Ebenso wie oben geschrieben - ich kann ja fragen im Zuge der Konfiguration der Storage.
Eigentlich würde ich die auch gern allein durchziehen, leider hab ich da selber nur 2 Mail kurz über die Schulter geschaut und bin mir mit dem Zoning nicht sicher genug.
ESXi verbinden wiederum sollte problemlos gehen...
Danke für die Schilderung in Punkteform!
Du würdest das so also über den Wartungsmodus gehen... das hatte ich mir gedacht, dass ich vermeiden kann.
Leider sind die Server schon recht ausgelastet (>3:1 Ratio ...deshalb kommen ja neue...)
Ja, die Storage ist der SPOF - die neue Storage wird das nicht verbessern, da sie es ja ersetzt.
Der Plan ist, dass die 3 Server durch 2 ersetzt werden und 1 Server davon dann der neue Veeam Server wird, der wiederum dann via der "Replikation" Funktion die VMs auf der alten Storage bereithält.
wir bekommen auch einen neuen Serverraum, wo dann die beiden Server verteilt werden. Aber das zieht sich noch und ich möchte die Storage, die ich jetzt schon habe, einfach vorziehen.
Die Ausfallsicherheit wird erhöht. Einen Flugzeugabsturz, regionalen Blackout über lange Zeit und Alien-Invasion würde es natürlich nicht absichern. Aber das überlebe ich selber ggf. nicht
Verkabelung machen wir selbst (unsere Firma macht Elektroinstallationen...) von daher werden Gerätschaften direkt verbunden.
Da hab ich mir 24 Cat6a Anschlüsse und 16 LWL Anschlüsse (LC, mind. OM4, mind. 2 separate Kabelstränge) gefordert... Die Entfernung ist unter 50m...
Teil möchte ich selbst machen. Und nunja... die Recherche dafür ist u.a. hier
Ich wollte mir Rat einholen, ob die Reihenfolge so passt für dieses "Standard-Prozedere"
Vermutlich werd ich mit dem Dienstleister das noch kurz absprechen.
@Njord90
2x in meiner vorherigen Firma mit begleitet.
In beiden Fällen wurde es vorher konfiguriert.
Beim ersten Mal weiß ich nicht mehr, wie es angeschlossen war. Hier hab ich nur das storage vmotion gemacht.
Beim zweiten Mal waren es 2 unterschiedliche vcenter, die via einem iSCSI Storage gekoppelt wurden. Also anderes Szenario
das Storage vMotion usw. dann alles allein gemacht... war kein Problem dabei.
@2423392070
Ich frage den Dienstleister mal, ob sie so einen SVC haben...
@em-pie
Der Dienstleister hat zumindest der Firma die letzten 2 Umgebungen verkauft und ja, wir machen öfter was mit denen.
einen FC-Switch finde ich dauerhaft für uns übertrieben. Ausleihen könnte gehen...
Ebenso wie oben geschrieben - ich kann ja fragen im Zuge der Konfiguration der Storage.
Eigentlich würde ich die auch gern allein durchziehen, leider hab ich da selber nur 2 Mail kurz über die Schulter geschaut und bin mir mit dem Zoning nicht sicher genug.
ESXi verbinden wiederum sollte problemlos gehen...
Danke für die Schilderung in Punkteform!
Du würdest das so also über den Wartungsmodus gehen... das hatte ich mir gedacht, dass ich vermeiden kann.
Leider sind die Server schon recht ausgelastet (>3:1 Ratio ...deshalb kommen ja neue...)
Ja, die Storage ist der SPOF - die neue Storage wird das nicht verbessern, da sie es ja ersetzt.
Der Plan ist, dass die 3 Server durch 2 ersetzt werden und 1 Server davon dann der neue Veeam Server wird, der wiederum dann via der "Replikation" Funktion die VMs auf der alten Storage bereithält.
wir bekommen auch einen neuen Serverraum, wo dann die beiden Server verteilt werden. Aber das zieht sich noch und ich möchte die Storage, die ich jetzt schon habe, einfach vorziehen.
Die Ausfallsicherheit wird erhöht. Einen Flugzeugabsturz, regionalen Blackout über lange Zeit und Alien-Invasion würde es natürlich nicht absichern. Aber das überlebe ich selber ggf. nicht
Verkabelung machen wir selbst (unsere Firma macht Elektroinstallationen...) von daher werden Gerätschaften direkt verbunden.
Da hab ich mir 24 Cat6a Anschlüsse und 16 LWL Anschlüsse (LC, mind. OM4, mind. 2 separate Kabelstränge) gefordert... Die Entfernung ist unter 50m...
Hallo,
so als Gedanke.
Die Server hängen ja mit 2 FC Verbindung am SAN.
Jeweils eine kappen, dann kannst du auf allen Servern beide SAN parallel verbinden.
Dann die Daten auf das neue SAN ziehen
Als nächstes das alte SAN außer Betrieb nehmen und beim neuen die redundanten Verbindungen herstellen.
so als Gedanke.
Die Server hängen ja mit 2 FC Verbindung am SAN.
Jeweils eine kappen, dann kannst du auf allen Servern beide SAN parallel verbinden.
Dann die Daten auf das neue SAN ziehen
Als nächstes das alte SAN außer Betrieb nehmen und beim neuen die redundanten Verbindungen herstellen.
1
Servus,
Danke, ja. das ist genau das, was ich im Eingangspost geschrieben habe
Aber wenn ich den Rat der anderen richtig verstehe, scheint es eher sehr riskant.
Danke, ja. das ist genau das, was ich im Eingangspost geschrieben habe
Aber wenn ich den Rat der anderen richtig verstehe, scheint es eher sehr riskant.
Zitat von @wiesi200:
Hallo,
so als Gedanke.
Die Server hängen ja mit 2 FC Verbindung am SAN.
Jeweils eine kappen, dann kannst du auf allen Servern beide SAN parallel verbinden.
Dann die Daten auf das neue SAN ziehen
Als nächstes das alte SAN außer Betrieb nehmen und beim neuen die redundanten Verbindungen herstellen.
Hallo,
so als Gedanke.
Die Server hängen ja mit 2 FC Verbindung am SAN.
Jeweils eine kappen, dann kannst du auf allen Servern beide SAN parallel verbinden.
Dann die Daten auf das neue SAN ziehen
Als nächstes das alte SAN außer Betrieb nehmen und beim neuen die redundanten Verbindungen herstellen.
Die Frage ist ja ob die Datenmenge auf dem storage bzw. die Größe der VMs eine direkte Kopie von storage zu storage benötigt oder ob das einfach über den FC Anschluss der esx Hosts laufen kann. Ich habe das vor ein paar Jahren Mal mit Hilfe von veeam gemacht, hier gibt es ja auch Features in die Richtung. Aber ich würde das auch über die FC Anschlüsse der esx Hosts machen wenn die Datenmenge es zulässt. Wenn du es auch selber durchführen willst ist es ja auch nicht schlimm wenn der Migrations Vorgang etwas länger dauert.
Zitat von @139689:
Servus,
Danke, ja. das ist genau das, was ich im Eingangspost geschrieben habe
Aber wenn ich den Rat der anderen richtig verstehe, scheint es eher sehr riskant.
Servus,
Danke, ja. das ist genau das, was ich im Eingangspost geschrieben habe
Aber wenn ich den Rat der anderen richtig verstehe, scheint es eher sehr riskant.
Nein, es ist nicht riskant, wenn die Pfade zum Storage redundant sind und z. B. per Round-Robin sich verteilen.
1
Zitat von @wiesi200:
Hallo,
so als Gedanke.
Die Server hängen ja mit 2 FC Verbindung am SAN.
Jeweils eine kappen, dann kannst du auf allen Servern beide SAN parallel verbinden.
Dann die Daten auf das neue SAN ziehen
Als nächstes das alte SAN außer Betrieb nehmen und beim neuen die redundanten Verbindungen herstellen.
Hallo,
so als Gedanke.
Die Server hängen ja mit 2 FC Verbindung am SAN.
Jeweils eine kappen, dann kannst du auf allen Servern beide SAN parallel verbinden.
Dann die Daten auf das neue SAN ziehen
Als nächstes das alte SAN außer Betrieb nehmen und beim neuen die redundanten Verbindungen herstellen.
Genau das wollte ich auch vorschlagen, so ziehen wir die SAN's immer um.
Ich denke, ich werde das nach reiflicher Überlegung noch aufschieben, bis die neuen Server da sind. Dann lässt sich das besser parallelisieren.
Das reine migrieren könnte ich dann ggf. über einen iSCSI Share machen, den die neue Storage direkt bereitstellt oder ich hoste es mit einer Debian VM, die ich schon aufgesetzt habe. Oder eben einen der Hosts in einem Wartungsfenster als Vermittler.
Auf die Weise kann ich auch alles vorher komplett verkabeln. Und es müssen keine temporären Konfigs und Verbindungen geschaffen werden.
Auch wenn das Vorgehen mit Umstecken sicher klappt, möchte ich mich dafür reservieren können. Irgendwie behagt es mir nicht, wenn dann was anderes daherkommt.
Das reine migrieren könnte ich dann ggf. über einen iSCSI Share machen, den die neue Storage direkt bereitstellt oder ich hoste es mit einer Debian VM, die ich schon aufgesetzt habe. Oder eben einen der Hosts in einem Wartungsfenster als Vermittler.
Auf die Weise kann ich auch alles vorher komplett verkabeln. Und es müssen keine temporären Konfigs und Verbindungen geschaffen werden.
Auch wenn das Vorgehen mit Umstecken sicher klappt, möchte ich mich dafür reservieren können. Irgendwie behagt es mir nicht, wenn dann was anderes daherkommt.