LVM steigt täglich aus - Umstellung auf ext4

[ThomasH]

Moinsens,

ich habe ein großes Problem mit einem Produktivserver und LVM. Ich starte den Rechner täglich per Kaltreset neu, weil das LVM-Laufwerk auf dem die VMs drauf sind aussteigt.
ich habe schon reichlich recherchiert und die gefundenen vermeintlichen Lösungen ausprobiert, die auf unserem Server nicht geholfen haben als da wären:

udev.conf:
event_timeout=600

lvm.conf:
thin_check_options= [ "-q", "--skip-mappings" ]

Beides hat nicht geholfen. Ich will nun das LVM loswerden und die VMs auf einem ext4-Laufwerk ablegen.
Nun sehe ich aber, dass hier mit dem Devicemapper gearbeitet wurde.

Meine Vorgehensweise wäre folgende:
* neues Verzeichnis auf der größten Partition anlegen,
* dort die VMs rein,
* neues Storage in Proxmox anlegen
- dieses als "Disk Image" deklarieren
* LVM als storage entfernen

Server neustarten.

Aber wie bekomme ich die 2 TB frei, die das LVM belegt?

Ehe ich nun was kaputtmache (darin bin ich richtig guuut! ) frage ich die Experten, ob es noch etwas gibt, was ich beachten muss.

Grüsskens,

Thomas_H

 

[Johannes S]

Naja ext4 würde auch auf einem lvm liegen, warum sollte das da anders laufen? Direkt ext4 ohne lvm ist keine unterstützte Konfiguration, ich würde statt solchen Gebastel ja erstmal Ursachenforschung betreiben und gucken, warum genau es denn nicht funktioniert. Hast du Logs Mut einer Fehlermeldung? Kannst du ausschließen, dass es an der Hardware liegt?

 

[ThomasH]

Moinsens und Danke für die Antwort.

Die Hardware sollte ich ausschließen dürfen, denn die ist neu. Allerdings konnte ich das Problem etwas eingrenzen. Beim Backup der virtuellen Maschinen steigt das LVM plötzlich aus mit einem "I/O Error". "Gebackupt" wird allerdings auf einer ext4.
Ich mache gerade aufgrund Deines Hinweises (Logfiles) ein paar tests und hoffe, das Problem eingrenzen zu können.

Die VMs befinden sich auf einer SSD (ebenfalls neu).

Ich überlege schon das gesamte System neu aufzusetzen und in diesem Rahmen auch mal die Festplatten zu überprüfen, dabei dann auf LVM zu verzichten.

Auf einem anderen Produktivserver habe ich das ebenfalls ohne LVM gemacht.

Grüsskens,

Thomas_H

 

[fba]

Hi,

bin da ganz bei Johannes S, konkrete Fehlermeldungen und -zustände sind zu analysieren. Wie äußert sich denn

weil das LVM-Laufwerk auf dem die VMs drauf sind aussteigt.

Gibts bei vgck, pvck <pvid> oder lvs <volumegroup> irgendwelche Fehlermeldungen?

 

[ThoSo]

Die Hardware sollte ich ausschließen dürfen, denn die ist neu. Allerdings konnte ich das Problem etwas eingrenzen. Beim Backup der virtuellen Maschinen steigt das LVM plötzlich aus mit einem "I/O Error". "Gebackupt" wird allerdings auf einer ext4.

Wo entsteht den der I/O Error? Wenn das auf der Platte mit dem LVM Volume auftritt würde ich einen Hardwaredefekt, nur weil der "neu" ist nicht ausschließen.

 

[waltar]

Ja, neue Platten sind mitunter doa (dead on arrival) oder sterben gerne in den 3 Monaten, danach laufen sie meist einen Haufen Jahre.
I/O error läßt schon stark vermuten, daß bald ein Plattenausfall droht, auch wenn sie noch recht neu ist.

 

[ThomasH]

So, dank Euren Hinweisen und der Aufforderung nicht so leicht aufzugeben habe ich einiges geprüft. Alle Tests ohne Befund erspare ich Euch mal. Besonders ThoSo's Frage "Wo entsteht der I/O Error" liess mich nicht los. Er entstand immer, wenn der Server nachts die Backups der virtuellen Maschinen machte.

Er kopierte dann nach Backup, ebenfalls auf dem LVM, welches bereits mit 86% belastet war und für das Backup einer 102GB großen Maschine und einem Vorrat von 3 Backups pro Maschine schlicht zu klein war. Ich habe nun dieses "Backup"-Verzeichnis geleert, es aus Proxmox entfernt und ein neues auf einer 4TB großen ext4-Festplatte angelegt und als storage für Backups deklariert.

Aktuell laufen die Backups und bislang störungsfrei. Es ist also schlicht ein Konfigurationsfehler gewesen.

Warum aber der Vorgang nicht mit einem "disk full" abgebrochen wurde verstehe ich nicht.

 

[sdettmer]

So, dank Euren Hinweisen und der Aufforderung nicht so leicht aufzugeben habe ich einiges geprüft. Alle Tests ohne Befund erspare ich Euch mal. Besonders ThoSo's Frage "Wo entsteht der I/O Error" liess mich nicht los. Er entstand immer, wenn der Server nachts die Backups der virtuellen Maschinen machte.

Und wo kam er her?
Fand sich was in dmesg?

Er kopierte dann nach Backup, ebenfalls auf dem LVM, welches bereits mit 86% belastet war und für das Backup einer 102GB großen Maschine und einem Vorrat von 3 Backups pro Maschine schlicht zu klein war.

Warum aber der Vorgang nicht mit einem "disk full" abgebrochen wurde verstehe ich nicht.

Genau, dann würde ich ein out of disk space erwarten und Folgefehler, aber kein I/O error. Hatte ich in Produktion schon, da kam disk full (leider keine Mail, weil disk full).


> Die Hardware sollte ich ausschließen dürfen, denn die ist neu

mmm also neue Hardware steht bei mir immer im Verdacht. Ich lasse auf neuer Hardware erstmal ein paar Tage (oder mind 24h) Last laufen, Festplatten einmal vollschreiben usw.
Bei Festplatten kommt es z.B. vor, dass bestimmte Bereiche langsam sind. ZFS schützt vor wirklich fast allem, aber hier kann es wenig tun. Kann passieren, dass dann Timeouts entstehen und zu I/O Errors führen (über NFS). Wenn die Platten die errors machen, sollte ZFS die irgendwann rauswerfen (wenn raidz oder mirror), aber das kann dauern. Ich hatte mal einen Server, der lahm war und kein Grund zu erkennen, auch smartctl und alles schick. Ich weiß gar nicht mehr, wie ich drauf gekommen bin (ich glaube, das smartctl -a sah unaufällig, aber anders als bei den anderen aus), aber ich hab dann eine Platte gezogen (und zack war der Server schnell), an nem PC beim Schreibtest große Performanceeinbrüche festgestellt und die Platte halt getauscht. Da war leider da nichts in den Logs zu sehen.
Wenn jetzt mehr Platz frei ist, werden die "kaputten Stellen" der Platte vielleicht nicht benutzt oder so, das Problem also aktuell nur gerade nicht sichtbar.