ESXi Server Sichern/migrieren mit Spanned Disks

[Scrj256]

Hallo Luxer

Da ich selber nicht mehr weiter weiss, dachte ich ich frag mal hier nach.

Ich muss ein Backup eines Version 5.5 EXI-Server erstellen da das RAID platt gemacht werden sollte. Leider war es unter ESXi nicht möglich grössere Disks als 250Gb zu erstellen. Um grössere Disks zu erstellen konnte man die Disks spannen. Das wurde gemacht, leider lassen sich nun diese Disk nicht mehr sichern bzw. die Disks werden dann einzeln gesichert. Ich habe mit Veeam, Windows Backup und Backup Assist probiert ein Backup zu erstellen, leider ohne Erfolg. Die Disks werden einzeln gesichert (3 mal 200GB) der neue Server kann diese dann aber nicht mehr zusammenführen. Hat einer eine Idee wie ich diese 3 Disks mergen kann oder wie ich ein Backup der Partition machen kann? Laufwerk C:\ kann ich sichern, Laufwerk D (kein Systemlaufwerk) um welches es geht leider nicht.

Jemand ne Idee?

 

[Vogelbecker]

Klar kann ESXi auch größere virtuelle Platten:


Das was du da hast, sieht nach Produktivumgebung aus. Finger weg und wen einkaufen, der weiß was er tut.

 

[konfetti]

Man konnte mit den richtigen Settings auch unter 5.5 und früher Platten größer 250GB einbinden - da war also nur was verkonfiguriert.

Nur so am Rande, das mit dem "Demaskieren" (also Schwarz ausmalen) üben wir nochmal
Wenn auf dem Server also wirklich SAP läuft, würde ich einen Consultant holen, der die Migration auf ein neues System durchführt, das entsprechend konfiguriert ist.
Ein Clone ist da nämlich garnicht so trivial.

Was Du zu lernzwecken natürlich probieren kannst:
Mache einen Clone davon -> !Achtung bei vermutlich statischen IP-Adressen, am besten die Netzwerkverbindung trennen - sonst gibts Ärger im System! -> Dem Clone eine weitere Platte in der gewünschten Größe hinzufügen -> Alle Services in der VM stoppen (SAP, DB-Server, etc...) -> Alle Daten der "verteilten Platte" auf die neue kopieren (idealerweise z.B. mit Robocopy) -> Laufwerksbuchstaben ändern, also die "alte verteilte Platte" zu Y machen, die neue dann zu dem, was die vorher war -> Server einmal durchbooten und dann schauen ob alles sauber hoch kommt - damit lernt man bissl was. - Ob das System dann so funktioniert, wie Du das brauchst weis natürlich keiner.

Wie gesagt, am besten einen Consultant für die Migration und gleich ein neues System aufsetzen, schaut mir hier eh nach nem veralteten OS aus?

 

[Scrj256]

Klar kann ESXi auch größere virtuelle Platten:

Ok

 

[Vogelbecker]

Es gibt hier genug, die sowas für die Füße geworfen bekommen haben und hinterher das geheule groß ist, wenn was in die Hose ging.
Ich kaufe regelmäßig Tätigkeiten von extern ein, wenn ich was nicht kann. Wenn dann was in die Hose geht, dann gibts wen der haftet.

Ja, die hätte ich, aber ich muss mich auch nicht beleidigen lassen.

Viel Spaß mit deiner Testumgebung!

 

[Scrj256]

Ok

 

[MicroCane]

Nochmal ne kurze Zwischenfragen:

Hast du das Veeam Backup and Replication (Ziel ist der ESXi Host) oder den Agent (Software AUF der VM) genutzt?
Mich wundert bei beidem, dass es nicht funktioniert.

 

[konfetti]

@Scrj256 - sorry, aber der Post oben is auch nicht gerade Professionell - "Oberhacker", "Spast" ? - gehts noch?
Das ist hier eine Community, die sich gerne hilft und hier hat jeder unterschiedliche Erfahrung oder Erfahrungen gemacht.

Bei den letzten Anfragen hier, waren das eben eher Leute die irgendwas übernehmen mussten, bei einem Wissenstand von <= 0 zum jeweiligen Thema.

Wenn es eine Testumgebung ist, wäre doch meine Vorgehensweise die praktikabelste?
Andererseits würdest Du doch selber ein Backup von der VM machen und zurückspielen, oder?

Entweder Du hast verschiedene Dinge schon probiert und erzählst uns auch davon, damit auch wir nicht bei Null anfangen müssen, oder Du versumpfst hier ganz schnell ohne Hilfe...

 

[Scrj256]

OK

 

[besterino]

Wer jemanden als „Spast“ bezeichnet, wird ignoriert. So einfach ist das. Das ist auf so vielen Ebenen völlig daneben - Fachkompetenz hin oder her. Und im Job wäre das bei uns übrigens mal mindestens flugs ne Abmahnung wenn nicht ne fristlose, auch völlig wumpe „wie toll“ man fachlich sein mag.

 

[konfetti]

Mit Veeam Backup Replication scheitert es weil Veeam keinen Snapshot erstellen kann. Folgende Fehlermeldung erscheint da:

Datei ist größer als die vom Datenspeicher unterstützte maximale Größe.

Speicher ist genug vorhanden um die ganze VM (800GB) doppelt auf dem Datastore zu kopieren (Snapshot). Hab auch mal den Veeam Support kontaktiert, dieser konnte mir leider nicht weiterhelfen. Deshalb bin ich der Meinung das es an diesen drei zusammengesetzten Disks liegt. Bei allen anderen 20 Server haben wir keine Probleme mit der Sicherung nur bei diesem mit den Spanned Disks haben wir Probleme.

Hast Du noch ein leeres Array? - sprich eines, an dem Du die Settings des Datastores ändern kannst?
Alternativ könnte man noch versuchen ein Upgrade des VMFS zu fahren, sofern das nicht schon auf der ESX-entsprechenden höchsten Version ist.

Sofern noch ein Testhobel vorhanden wäre, könnte man auch die VM auf einen neueren ESXi verschieben und dort das ganze probieren.

- Der Snapshot grenzt hier halt auch an die 256GB Grenze des Datatores - wobei ja eigentlich für jede VMDK ein eigener Snapshot angelegt wird... - kannst Du denn händisch einen Snapshot für die VM anlegen?

 

[fdsonne]

Aber das kann man machen wenn man merkt der User hat keine Ahnung von der Thematik und das konnte man bei meinem ersten Post weis Gott nicht raus lesen. Wenn dann einer kommt uns mir sagt "komm lass ma die Profis ran du hast eh keine Ahnung", obwohl ich seit ich arbeiten kann in dieser Branche bin, geht es dann vielleicht schon mal in den falschen Hals.

Naja, ich sag mal so, das Urteil, ob die Beteiligten hier dir das Wissen, was du meinst zu haben zugestehen oder nicht, musst du diesen schon selbst überlassen.
MMn beißt sich die Frage mit "obwohl ich seit ich arbeiten kann in dieser Branche bin" - keine Ahnung was du in dieser Branche machst, aber die Basics, wie man die VM da vom ESXi runter bekommt sollte man doch wenigstens drauf haben wenn man schon so ein System administrieren soll oder möchte? Und wenn es dort dran schon scheitert (was ja absolut kein Problem ist), warum feuerst du dann solche Sachen wie da oben raus und wunderst dich, dass man dir den Rat gibt, da jemanden dran zu lassen, der weis wie das geht? Genau das war doch der Kritikpunkt - die Frage implizierte einfach, dass du nicht weist wie es geht...

Ich versteh ehrlich gesagt so recht dein Problem nicht. Fahr die VM runter, sicher die drei VMDKs weg und mach das Raid platt... Fertig. Keine Tools notwendig, kein wirklicher Aufwand und das funktioniert zu 100%.
Warum da auf nem 5.5er ESXi offenbar VMFS 3 irgendwas gefahren wird ist mir ebenso rätzelhaft. Vor allem, wieso zur Hölle macht man dann ein spanned Volume im Windows? WER baut sowas?
Sollte die Frage aber dahingehend abzielen, dass du das spanned volume zu einem single/simple Volume zurückbauen willst wäre es schon gut gewesen, das so auch zu formulieren, denn das steht da so absolut nicht. Möglich wäre das wahrscheinlich auch (selbst hab ich das aber nie probiert)

Da du auf Nachfrage ja nun sagtest, es handle sich hier um eine Test-SAP Umgebung, wäre es doch wahrscheinlich kein Problem die VM temporär auszuschalten und die notwendigen Schritte durchzuführen? Du kommst da via SCP ran, wie dem vSphere Client oder über das Host UI als Webinterface.
Der Grund, warum du da max. 256GB VMDKs hast ist eine 1MB Blocksize auf einem VMFS3 formatierten Volume - da hat offenbar wer gepennt oder das aus welchen Gründen auch immer so eingerichtet.
Umformatieren ist nur durch leer machen möglich -> also alles runter kopieren und das Volume als VMFS5 neu anlegen (oder was auch immer du da genau vor hattest)
Wenn du dann soweit bist, dass das VMFS Datastore mehr als 256GB pro VMDK zulässt, dann können wir ggf. auch darüber sprechen wie man den Spaß mit dem spanned volume wegbekommt

 

[Scrj256]

ok

 

[l0n]

Schieb den ganzen Kram doch per vMotion weg, leg auf dem neuen Datastore (hoffentlich VMFS 5!) ne neue VMDK an, migrier die Daten und lös dann diesen Windows Dynamic Disk Schwachfug auf

 

[Scrj256]

Die beiden ESXI Hosts(Testumgebung (Ehemaliger Produktiv-ESXi-Server)) und Produktivumgebung(neuer ESXi) sind zwei Physisch getrennte Server welche kein vMotion installiert haben. Deshalb ist ein VM-move per vMotion leider nicht möglich. Da es sich dabei um einen Testserver handelt soll der Host so oder so von der Produktivumgebung abgetrennt werden.

Ich habe trotzdem schnell geschaut was ich für vMotion benötige, da es sich um einen recht alten Server handelt wird das Hardware-technisch (CPU Kompatibilität, Gleiche Netzwerkkonfiguration, ...) wohl schon eher schwierig zu realisieren. Zudem habe ich keine Lizenz für vMotion was mir das testen leider verunmöglicht.

 

[l0n]

vMotion zwischen verschiedenen Hardware Generationen geht, aber nur per Cold vMotion (VM herunterfahren). Die Lizenzfrage ist nochmal eine andere...


Du könntest versuchen per Altaro VM Backup die VM wegzusichern und per Boot from Backup auf dem neuen Host anzustarten. Daten migrieren musst du wohl aber so oder so auf NTFS Ebene

Tante Edith sagt:

Ich bin n Depp

Cold vMotion geht auch ohne Lizenz
Maschine runterfahren, Migration anstoßen, Happy sein
Sollte ja bei der Testumgebung kein Problem sein oder?

Um Downtime kommst du ja irgendwann sowieso nicht mehr rum...

 

[Scrj256]

Die Downtime ist schnuppe da es sich um ein System handelt welches nur bei Präsentationen genutzt wird.

Habe nun Laufwerk C:\ per Veeam Agent auf den neuen ESXi migriert. Nun ist nur noch diese spanned Partition übrig. Versuche es nun mal mit Altaro VM Backup.

 

[Digi-Quick]

- Windows VM Starten,
- SAP stoppen,
- Datenbankserver (das Backend von SAP) stoppen
- (eventuelle weitere Dienste/Programme, die auf LW Daten geöffnet halten beenden)
Damit sind dann die Daten auf LW E: nur noch "kalte" ungeöffnete und ungesperrte Daten

- Inhalt von LW auf ein beliebiges via SMB erreichbaren Share (oder anderes Ziel) per xcopy oder robocopy sichern (oder auch ein beliebiges anders Backupprogramm, welches auf Dateibasis sichern kann)

Wenn komplex (Veeam Backup Agent o-ä.) nicht geht, muß man halt mal Back to the roots gehen.

 

[Scrj256]

- Windows VM Starten,
- SAP stoppen,
- Datenbankserver (das Backend von SAP) stoppen
- (eventuelle weitere Dienste/Programme, die auf LW Daten geöffnet halten beenden)
Damit sind dann die Daten auf LW E: nur noch "kalte" ungeöffnete und ungesperrte Daten

- Inhalt von LW auf ein beliebiges via SMB erreichbaren Share (oder anderes Ziel) per xcopy oder robocopy sichern (oder auch ein beliebiges anders Backupprogramm, welches auf Dateibasis sichern kann)

Wenn komplex (Veeam Backup Agent o-ä.) nicht geht, muß man halt mal Back to the roots gehen.

Genau so habe ich es jetzt gemacht. Habe das Tool SyncToy von MS genommen um die Files von der Data Partition zu kopieren, funktionierte wunderbar. Laufwerk C:\ konnte ich per Veeam Agent weg sichern und mit dem mounten des Veeam-Restore-Iso in der neuen Umgebung wieder einspielen.

Morgen kommt aus ob das SAP noch funktioniert, mein Vorgesetzter ist aufjedenfall guten Mutes und wird versuchen heute Abend das SAP-System wieder in betrieb zu nehmen.

In diesem Fall kann man wohl sagen das es bis zum heutigen Tag keine andere Möglichkeit gibt ausser "back to the roots" zu gehen um so ein spanned-volume per Filecopy von einem ESXi weg zu sichern und eine neue Disk an zu legen welche man dann sichern kann. Echt mühsam.

 

[p4n0]

Darum macht man sich im Vorfeld Gedanken, bevor man so n komisches Konstrukt zusammenzimmert ^^

 

[besterino]

Ach komm schon. Überall gibt es das Phänomen „historisch gewachsener Infrastruktur“...

 

[p4n0]

Ja das ist mir durchaus bewusst
Keiner will es anfassen, nichts ist Dokumentiert und wenns kaputtgeht zieht man lange und ratlose Gesichter... ^^

 

[besterino]

...aber zum Glück hat das irgendein Vorgänger verbrochen, auf den man mit dem fiesen Finger zeigen kann...

In einem mir bekannten großen RZ haben kürzlich Ratten knapp 50 Glasfaserkabel im Übergaberraum von den Leitungsprovidern zerbissen... soviel zum Thema was so alles passieren kann und man vorher nicht geglaubt hätte...