Hyper-V Speicherfehler im Cluster, ISCSI Volume
Guten Mittag liebe Administrator Gemeinde,
hoffentlich sitzt Ihr gerade gemütlich Zuhause und genießt das Wochenende. Ich sitze aktuell leider vor einem Server der nicht mehr startet.
Grundinfos:
Hyper-V Cluster im Aufbau (aktuell ohne 2ten Node)
ISCSI Speicher
Fehler:
SQL Server hat eine 4 TB Platte komplett vollgeschrieben.
Schon getan:
Speicher erweitert
Weitere Fehlermeldung:
Siehe Anhang
Ich bitte nun um Hinweise und Tipps (gerne auch IT-Service Firmen melden, gerne bezahlen wir den Einsatz)
Mit freundlichen Grüßen,
mistergemuese
hoffentlich sitzt Ihr gerade gemütlich Zuhause und genießt das Wochenende. Ich sitze aktuell leider vor einem Server der nicht mehr startet.
Grundinfos:
Hyper-V Cluster im Aufbau (aktuell ohne 2ten Node)
ISCSI Speicher
Fehler:
SQL Server hat eine 4 TB Platte komplett vollgeschrieben.
Schon getan:
Speicher erweitert
Weitere Fehlermeldung:
Siehe Anhang
Ich bitte nun um Hinweise und Tipps (gerne auch IT-Service Firmen melden, gerne bezahlen wir den Einsatz)
Mit freundlichen Grüßen,
mistergemuese
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1039998633
Url: https://administrator.de/forum/hyper-v-speicherfehler-im-cluster-iscsi-volume-1039998633.html
Ausgedruckt am: 22.12.2024 um 20:12 Uhr
16 Kommentare
Neuester Kommentar
Moin @mistergemuese,
Das wird eine längere Operation. Hier scheint die Planungsabteilung ganz schön geschlampt zuhaben.
Habt ihr den SQL-Server wirklich auf dem Hyper-V Sever installiert?
Gruß
C.C.
Das wird eine längere Operation. Hier scheint die Planungsabteilung ganz schön geschlampt zuhaben.
Habt ihr den SQL-Server wirklich auf dem Hyper-V Sever installiert?
Gruß
C.C.
Hi,
habt ihr ein Backup vom SQL Server ? Wahrscheinlich nein, da die Logs die Festplatte vollgemacht haben. Und habt ihr differenzierte VHD's genommen. Empfehlung feste VHD's. Ist das ein SQL Cluster ? Wenn nein kannst du, die VM aus dem HyperV Cluster entfernen und dann erstmal versuchen die VHD Probleme zu lösen.
Habt ihr Ein SQL _Backup, Server neu aufsetzten mit festen VHD und Backup wieder einspielen.
Mit freundlichen Grüßen
habt ihr ein Backup vom SQL Server ? Wahrscheinlich nein, da die Logs die Festplatte vollgemacht haben. Und habt ihr differenzierte VHD's genommen. Empfehlung feste VHD's. Ist das ein SQL Cluster ? Wenn nein kannst du, die VM aus dem HyperV Cluster entfernen und dann erstmal versuchen die VHD Probleme zu lösen.
Habt ihr Ein SQL _Backup, Server neu aufsetzten mit festen VHD und Backup wieder einspielen.
Mit freundlichen Grüßen
Ja, jetzt wo du es sagst.
Ich war wohl sehr von c:\... als Teil der Clusterressource geschockt. 😄
Ich war wohl sehr von c:\... als Teil der Clusterressource geschockt. 😄
Moin,
ich schließe mich @Th0mKa an.
Du hast aus meiner Sicht ein Problem mit den VHDX-Dateien dieser VM. Anscheinend sind da Prüfpunkte vorhanden, die nicht zu den Differential-VHDX passen.
Aber um hier eine Lösung vorzuschlagen, bedarf es wesentlich detaillierter Informationen ansonsten bliebe die Hau-drauf-Methode, sofern noch anwendbar:
Datenbankserver (nicht die VM sondern den Dienst) herunterfahren. Alle zur DB gehörenden Dateien aus der VM wegkopieren.
VM runterfahren. Prüfpunkte löschen ggfs. differental-VHDX manuell integrieren.
VM hochfahren und schauen, ob alles klar ist, sonst DB-Kopie zurückspielen.
Gruß
bdmvg
ich schließe mich @Th0mKa an.
Du hast aus meiner Sicht ein Problem mit den VHDX-Dateien dieser VM. Anscheinend sind da Prüfpunkte vorhanden, die nicht zu den Differential-VHDX passen.
Aber um hier eine Lösung vorzuschlagen, bedarf es wesentlich detaillierter Informationen ansonsten bliebe die Hau-drauf-Methode, sofern noch anwendbar:
Datenbankserver (nicht die VM sondern den Dienst) herunterfahren. Alle zur DB gehörenden Dateien aus der VM wegkopieren.
VM runterfahren. Prüfpunkte löschen ggfs. differental-VHDX manuell integrieren.
VM hochfahren und schauen, ob alles klar ist, sonst DB-Kopie zurückspielen.
Gruß
bdmvg
Zitat von @mistergemuese:
Das sieht nur so aus... Die Daten liegen auf einem iSCSI Target.
Zitat von @148656:
Ja, jetzt wo du es sagst.
Ich war wohl sehr von c:\... als Teil der Clusterressource geschockt. 😄
Ja, jetzt wo du es sagst.
Ich war wohl sehr von c:\... als Teil der Clusterressource geschockt. 😄
Das sieht nur so aus... Die Daten liegen auf einem iSCSI Target.
Ist dennoch ein
Aber lass doch Mal alles sehen.
Joar, Montag ist die Hütte immer am Brennen.
Nunja, eine differenzierte Festplatte kann man nicht Vergrößern. Man muss Sie vorher in ein eigenständige VHD überführen. Das einfachste und schnellste. Du spielst das Backup des SQL-Servers in eine neue VM ein.
- Kollegen die sich krank melden.
- Status-Calls mit den Stammkunden, um über Störungen vom Wochenende zu informieren.
- Nachbearbeitung von Störungen. Am WE sitzt meist nur eine Person im Büro und ist für alle Kunden zuständig. Da macht man nur das nötigste. Sprich Dokumentieren, Logs sichern und wieder zum Laufen bringen. Für saubere Fehlersuche bleibt da keine Zeit.
Nunja, eine differenzierte Festplatte kann man nicht Vergrößern. Man muss Sie vorher in ein eigenständige VHD überführen. Das einfachste und schnellste. Du spielst das Backup des SQL-Servers in eine neue VM ein.
Wenn dein SQL-Server wieder läuft. Solltest du dir vllt Gedanken über ein "Redesign" der Festplattenkonfiguration machen.
Zum Beispiel
C:\ -> Systempartition
D:\ -> SQL-Datenbank
E:\ -> Temp-DB
F:\ -> SQL-LOGs
D-F sollten eigenständige LUN sein.
Zum Beispiel
C:\ -> Systempartition
D:\ -> SQL-Datenbank
E:\ -> Temp-DB
F:\ -> SQL-LOGs
D-F sollten eigenständige LUN sein.
Zitat von @mistergemuese:
Hier habe ich mal alles was ich habe zusammengefasst, Fujitsu lässt uns immer noch warten....
Hier habe ich mal alles was ich habe zusammengefasst, Fujitsu lässt uns immer noch warten....
Falls du noch ein paar hundert Euro Budget übrig hast kannst du zusätzlich ein Severity A Ticket bei Microsoft aufmachen, die kennen sich auch mit Hyper-V und MSSQL aus.
/Thomas
Zitat von @mistergemuese:
Hier habe ich mal alles was ich habe zusammengefasst, Fujitsu lässt uns immer noch warten....
Zitat von @148656:
Ist dennoch ein untypischer Aufbau, der von MS als "kannste zwar machen, aber..." Umschrieben wird. Schnellklick-Aufbau
Aber lass doch Mal alles sehen.
Zitat von @mistergemuese:
Das sieht nur so aus... Die Daten liegen auf einem iSCSI Target.
Zitat von @148656:
Ja, jetzt wo du es sagst.
Ich war wohl sehr von c:\... als Teil der Clusterressource geschockt. 😄
Ja, jetzt wo du es sagst.
Ich war wohl sehr von c:\... als Teil der Clusterressource geschockt. 😄
Das sieht nur so aus... Die Daten liegen auf einem iSCSI Target.
Ist dennoch ein
Aber lass doch Mal alles sehen.
Hier habe ich mal alles was ich habe zusammengefasst, Fujitsu lässt uns immer noch warten....
Hast Du Checkpoints bei allen Maschinen laufen?
Wieso?
Die würde ich nur zum Backup erstellen oder aber, wenn ich einen Fail-Back brauche. Aber für den normalen Betrieb würde ich das nicht machen. Dann hängt die Gesundheit Deines aktuellen Datenbestandes an zwei virtuellen Laufwerken, die in "guter" Beziehung zu einander stehen müssen.
Ich empfinde das als sehr riskant.
Mahlzeit,
Da kommt es immer darauf an, was im Auftrag stand. Und was für ein Techniker am werkeln war. Hatte schon öfters das "Glück" gehabt, dass er den ersten Server seines Lebens in meinem Projekt installieren wollte. Da sind Erfahrungswerte eher gering und mehr "Bilderbuchmäßig".
Gruß
Da kommt es immer darauf an, was im Auftrag stand. Und was für ein Techniker am werkeln war. Hatte schon öfters das "Glück" gehabt, dass er den ersten Server seines Lebens in meinem Projekt installieren wollte. Da sind Erfahrungswerte eher gering und mehr "Bilderbuchmäßig".
Gruß
ich muss sagen ich bin sehr enttäuscht über die Qualität so einer großen Firma.
Tröste dich... Ist bei anderen ja auch nicht besser:Reklamation HPE, Beschwerdefall HPE, Was tun wenn die Antworten des HPE Supports hanebüchen werden?