Auf größeren Server upgraden - Leider doch nicht so einfach

Zitat von frank_m

Davon hab ich auch nicht gesprochen. Natürlich wird irgendwann der 1. Server Down genommen (oder read-only), dann werden ausstehende Synchronisationen vorgenommen, und dann wird der 2. Server hochgefahren. Dabei bleiben die Daten konsistent, und mit der entsprechenden Vorbereitung ist der Aufwand für diesen Schritt überschaubar, und die Downtime bleibt klein.

dd geht da natürlich nicht. Da muss man schon anders herangehen. Also einen Tod wird man sterben: Den der Bequemlichkeit, oder den der Downtime. Das ist mir auch klar. Mit Block auf Langzeitstabilität bin ich immer gegen "harte" Wechsel des Unterbaus einer Installation, von daher kommt so ein einfaches "dd" für mich eh nicht infrage, und dann ist der Schritt zur zweiten Variante klein.

Warum genau sollte dd da nicht gehen? Sehe nichts, abgesehen von Persönlichen Vorlieben, was dagegen spricht.

Einem ordentlich gepflegtem Linux sollte das nichts anhaben. Zwischen zwei ähnlichen KVM VMs wechseln ändert sich ja dann bei Netcup ja eh nur die Netzwerkconfig für IPv6. Und da wir hier VMs haben, sind ja auch so Sachen wie CPU Wechsel bezüglich Microcode egal, weil den gibt es nur 1x auf dem Hypervisor

Zitat von frostschutz

Denke es wird ziemlich aneinander vorbei geredet.

Beim vorher genannten rsync-Ansatz (und ähnliche Methoden) geht dd nicht. dd kann von sich kein Resume oder Tracking von Änderungen (man kanns basteln, mit LVM Snapshot, Copy-on-Write Overlays, aber... Aufwand).

Beim dd-Ansatz machst du also die gesamte Übertragung in einem Schritt offline und so lange wie das dauert, so lange dauert es dann eben. Wenn dir das lieber bzw. sicherer ist, dann ist das auch vollkommen in Ordnung. Da brauchen wir uns aber auch nicht den Mund fusselig reden zu Downtime und Optimierungsansätzen.

Deine Einwände mit Datenbank-Konsistenz, 2 Instanzen & Co. — das ist klar, diese Probleme hast du bei jeder anderen Anwendung doch auch, nicht nur bei Datenbanken. Aber es ist kein Problem, solange — der Zielserver die ganze Zeit nur im Rescue steht und brav Daten empfängt.

Erst im letzten Schritt geht der Quellserver ins Rescue, stellt die erforderliche Konsistenz her (Übertragung der letzten Änderungen von Rescue zu Rescue), und erst dann startet der Zielserver, mit den übertragenen, konsistenten Daten.

Klappt alles mit rsync ohne Probleme, vorausgesetzt man hat ein Dateisystem mit ordentlichen Timestamps. Und nicht FAT32 mit 2-Sekunden-Taktung. Ohne Timestamps weiß rsync nicht, was nochmal zu kopieren ist und was nicht…

Die Konsistenz spielt erst im letzten Schritt eine Rolle.

Alles anzeigen

Ja, schon klar. Am besten wäre es halt wenn man einfach an sein qcow2 ran käme oder noch einfacher so wie beim roten H auf "Ich möchte meinen Server Rescalen, ich brauche so viel Leistung" klicken könnte.

Gut, verstehe ich, dass letzteres mit Sonderangeboten (egal wie gut oder schlecht kommuniziert) nicht geht. Aber dass man an sein qcow2 nur rankommt wenn man unter 50% Speicher ist, ist halt ein Unding und aus meiner Sicht her unverständlich. Muss ja noch nicht mal ein Snapshot sein, sondern könnte ja auch read only auf dem Images FTP Server liegen, wenn die Kiste ausgeschaltet ist.

Klar, können wir jetzt über wie bekomme ich am schnellsten eine Datenbank von Server A nach B diskutieren, aber das löst ja nicht das eigentliche Problem bzw die Ursache, sondern nur die Symptome.

Und klar mag es eine Leute geben, die lieber neu Installieren weil sie ihren Server nicht konsistent halten - aber dass man das vom Support so genannt bekommt als DIE Lösung ist halt auch irgendwie nur Problem versuchen schön zu reden (ja okay, das ist u.a. auch mit Aufgabe im 1. Level Support) statt ernsthaft versuchen zu lösen.

Hier noch mal ein Zwischenstand der Ideen bezüglich Images und Snapshots die in diesem Thread aufkamen:

• Temporäre Copy on Write Snapshots (also nicht für immer aufheben bis sie vergessen sind, sondern nur für 24h oder so)
• Copy on Write Snapshots bis z.B. runter auf 15% Kapazität erlauben, weil für einen Export oder als Sicherheitsnetz werden sich sicher nicht alle Blöcke geändert
• Zugriff auf qcow2 im ausgeschaltetem Zustand (ggf auch nur Lesend)

Natürlich ist es blöd wenn ein CoW Snapshot gemacht wird und vergessen wird und sich dann quasi alles ändert, dass man dann auf dem Hostsystem dauerhaft viel mehr Speicher braucht als der Kunde gebucht hat, aber das muss mit den oben genannten Punkten ja nicht der Fall sein.

Vielleicht sieht ja jemand von Netcup in diesen Thread und kann sich vorstellen diese Optionen mal durchzurechnen, ob man damit vielleicht das 50% Limit mit abschaffen könnte im Sinne der Kundenfreundlichkeit ohne einen erhöhten Ressourcenverbrauch zu haben.

Selbst wenn aus Vergessen aus 50% Kunden mit Snapshot dann im Worst Case 150% Kunden werden, hat dies ja langfristig einen höheren Speicher Verbrauch als selbst ein 100% Kunde der nur 24h einen Snapshot hat und ihn in der Zeit nutzen oder runterladen muss.

Oder vielleicht sieht ja jemand von Netcup diesen Thread und schaut, dass man die aktuellen Snapshot-Möglichkeiten sowie Upgrade-Möglichkeiten auf der Produktseite transparenter darstellt.

Im Worst Case kauft der Kunde einen Snapshot für 1,50€, nur um dann festzustellen, dass es nur was bis max 50% Verbrauch genützt hätte. Das dürfte sicherlich eher weniger zur Kundenzufriedenheit zuträglich sein.

Zitat von frank_m

Zum einen gibt es ja schon eine lauffähige Installation auf dem neuen Server. Es geht ja nur, den letzten Datenstand abzugleichen.

Welche man neu einrichten müsste. Außerdem halte ich jedenfalls nichts von irgendwelchen mit unbekannten Paramentern vorinstallierten Systemen (habe zum Beispiel bei meiner Bestellung eine alte Debian Version erhalten) die vorinstalliert werden, da installiere ich eh immer nach meinen Anforderungen drüber. Oder kann direkt ins Rettungssystem booten.

Zitat von frank_m

Man schleppt trotzdem den ganzen Ballast mit, von toten Konfigfiles bis zu alten Logs.

Mit Logrotate und co kann man sich seine Logs so einrichten, dass diese ohnehin nur eine gewisse Zeit auf dem Server bleiben. Sollte man auch tun, wenn man nicht endlos irgendwelche IP Adresse von Webseitenbesuchern auf Vorrat speichern will.

Und wie gesagt, tote Konfigfiles gibt es zumindest auf meinen Server schon prinzipbedingt keine. Auf einem nicht deklarativ verwaltetem System wie einem Standard Ubuntu/Debian etc. sieht das natürlich aber anders aus.