Ist ein VPS Upgrade möglich ohne die Node neu installieren müssen?

Moin,

soweit ich weiß wird bei einem Upgrade nur die Leistung erhöht. Also die mehr Ressourcen werden dir zugewiesen. Deswegen ist auch ein Neustart der Maschine nötig und das alle Snapshots entfernt werden.

Das heißt du musst hier nichts neu installieren, nur ggf. deine Config anpassen.

Ich hab gerade in der Doku noch mal gesucht, so sehr Hilfreich ist sie hier jetzt aber gerade auch nicht

https://helpcenter.netcup.com/de/wiki/general/tarif-upgrade

Das Dateisystem wird nicht angetastet. Existierende Partitionen musst du ggf. selber vergrößern.

Zitat von dalu

Was heisst eigentlich iv?

iv steht für international version

Sollte beim VPS keinen Einfluss haben. Er wird nicht in ein anderes RZ verschoben, sondern bleibt wo dein Server gerade ist.

Das tut mir sehr leid zu hören. Bei meinem letzten Upgrade musste ich nur die Partition vergrößern, ansonsten hat das wunderbar ohne Probleme geklappt.

Kannst du vielleicht "VPS kommt nicht hoch" spezifizieren? Wo genau scheitert das booten? Startet dein VPS noch im Rettungssystem? https://helpcenter.netcup.com/de/wiki/server/rettungs-system/

Schau auch mal, ob sich in der /etc/fstab UUIDs befinden, sich sich durch die Anpassung/Upgrades geändert haben. Sowas könnte nämlich auch der Fall sein. Das kann dann wie von alxhu schon erwähnt leicht über das Rettungssystem wieder korrigiert werden.

Zitat von dalu

Kubernetes ist reinste Nervenaufreibung und Geldverschwendung.

Amen

Talos ist zwar ganz nett von der Idee, aber vermutlich auf einem Remote VPS nur bedingt geeignet. Gerade wenn du kein SSH hast und das Remote Management komplett über https über das Internet machen musst, kann man sich da manchmal auch selbst ein Bein stellen. Ich habe ja auch Kubernetes Cluster. Auch bei Netcup. Aber an Talos würde ich da nicht unbedingt denken, gerade weil du da bei Problemen recht schnell aufgeschmissen bist ohne lokale Debugging Tools.

Boote doch wirklich mal in das Rettungssystem und versuche die Disk zu mounten. Wenn da dann alles ok ist, dann liegt es zumindest schon mal nicht am Upgrade. Vielleicht sind ja wirklich einige UUIDs anders oder die Disk Reihenfolge. Klar gibt es auch immer noch eine Restwahrscheinlichkeit, dass das Upgrade an sich etwas kaputt gemacht hat, aber die Wahrscheinlich dafür ist dann doch eher gering. Um die Problemsuche etwas einzugrenzen solltest du wirklich mal schauen, ob es an der VM liegt oder an deinem Talos selbst.

Auch der Support wird dich erst einmal nur auf das Rettungssystem verweisen. Das musst du also so oder so machen.

Ich betreibe auch ein 9 Nodes Talos Cluster bei Netcup mit ARM VPS. Hab da auch schon ein VPS Upgrade gemacht und das ging wunderbar. Das war aber mit einer Älteren Talos version irgendwann letztes Jahr, wenn ich mich richtig erinnere.

Wäre auf jeden fall cool wenn du deine Erkenntnisse hier weiter schreibst.

Ich habe auf der Maindisk vda eine Partition für Ceph Bluestore und ein 50 GB LBS für Ephemeral/System

machine:
  [...]
  install:
    bootloader: true
    image: factory.talos.dev/metal-installer/ce4c980550dd2ab1b17bbf2b08801c7eb59418eafe8f279833297925d67c7515:v1.11.2
    wipe: true
    diskSelector:
      size: ">= 128GB"
---
apiVersion: v1alpha1
kind: VolumeConfig
name: EPHEMERAL
provisioning:
  diskSelector:
    match: disk.size < 128u * GB
  grow: true
  minSize: 16GB
  maxSize: 128GB
---
apiVersion: v1alpha1
kind: RawVolumeConfig
name: storage
provisioning:
  diskSelector:
    match: disk.size > 128u * GB
  grow: true
  minSize: 128GB

EDIT: ich habe irgendwann angefangen mit diskselector nach Größe zu arbeiten, weil ich einige Nodes hatte wo auf einmal das LBS device vda war (warum auch immer).

Zitat von dalu

Das Problem ist halt, BIOS meint vda ist boot disk und findet keinen boot sector o.ä. weil, wie bei dir ceph bluestore.

Und vdb hat das Talos system.

Shit ja da bin ich auch schon rein gelaufen. Deswegen hab ich diesen "Hack", dass ich als install drive vda (also immer die größere) nehme und dann das Ephemeral auf das LBS packe.

talosctl -n 192.168.32.10 get discoveredvolumes
NODE            NAMESPACE   TYPE               ID      VERSION   TYPE        SIZE     DISCOVERED   LABEL       PARTITIONLABEL
192.168.32.10   runtime     DiscoveredVolume   loop1   1         disk        672 kB   squashfs
192.168.32.10   runtime     DiscoveredVolume   loop2   1         disk        66 MB    squashfs
192.168.32.10   runtime     DiscoveredVolume   rbd0    1         disk        11 GB    ext4
192.168.32.10   runtime     DiscoveredVolume   sr0     1         disk        1.1 GB
192.168.32.10   runtime     DiscoveredVolume   vda     1         disk        1.1 TB   gpt
192.168.32.10   runtime     DiscoveredVolume   vda1    1         partition   2.2 GB   vfat         EFI         EFI
192.168.32.10   runtime     DiscoveredVolume   vda2    1         partition   1.0 MB   talosmeta                META
192.168.32.10   runtime     DiscoveredVolume   vda3    1         partition   105 MB   xfs          STATE       STATE
192.168.32.10   runtime     DiscoveredVolume   vda4    1         partition   1.1 TB   bluestore                r-storage
192.168.32.10   runtime     DiscoveredVolume   vdb     1         disk        54 GB    gpt
192.168.32.10   runtime     DiscoveredVolume   vdb1    1         partition   54 GB    xfs          EPHEMERAL   EPHEMERAL

Hilft dir jetzt natürlich nicht viel. Ich schaue mal gleich ob ich noch im Kopf habe wie ich damals das gefixt hab (muss dafür aber mal kurz eine node drainen, zum testen), dass zumindest das System wieder bootet. Gab beim UEFI von den ARM kisten zumindest eine Möglichkeit interaktiv explizit von der vdb zu booten.

EDIT:

TalosBootNetcupARM64UEFI-2.gif

EDIT2:

wahrscheinlich wurdest du aufgrund des Updates auf ein anderes Host System umgezogen. Nach meinen Verständnis verschwinden dann die EFI einstellungen die z.B. talos gemacht hat. Danach ist der Default wieder das auf der "Ersten" Block device nach einer EFI partition mit bootx64.efi/bootxaarch.efi gesucht wird.

Moderatoren würde mir wünschen wenn man die BootOrder der Block devices im SCP wählen könnte. Das würde sowas deutlich reboot safer machen und man bräuchte keine Hacks (die erst kürzlich mit Talos 1.11 möglich sind) brauchen, wenn man vda als Bluetstore für ein CEPH nutzen möchte.

I know mega special anwendungscase den nicht jeder hat. Wäre aber trotzdem mega toll

Zitat von dalu

Ich ändere die Kernel parameter und boote die ISO.

Ready Healthy

Aber was bringts wenn die ISO nach 48 Stunden gelöscht wird und das ganze in memory ist..

Nach eigener Erfahrung wird ein ISO-Abbild dann nicht gelöscht, wenn es gerade in Verwendung ist.

Zitat von dalu

Ok ich hatte UEFI nicht aktiv.

Das Upgrade war gefühlt instant.

Habe UEFI nun an, und dank deiner coolen animierten Anleitung das 2. device ausgewählt, aber wenn ich enter drücke flackert es kurz und wenn ich raus gehe und continue passiert nichts. Es ist noch immer das standard device eingestellt, wahrscheinlich weil das System nicht per UEFI installiert wurde.

Seit Talos 1.11 installiert er nur noch den Bootloader der benötigt wird und nicht mehr beides. D.h. du müsstest damit es mit UEFI klappt mindestens einmal ein: talosctl -n <ip> upgrade machen über den boot mit der ISO. Hab das aber bisher selber noch nicht gemacht ein BIOS zu UEFI konvertieren mit Talos. BIOS geht ja gar nicht mit den ARM64 kisten.