Zero Downtime für VMs

Discussion in 'Proxmox VE (Deutsch)' started by shibumi, Jan 29, 2019.

  1. shibumi

    shibumi Member

    Joined:
    Apr 6, 2018
    Messages:
    36
    Likes Received:
    0
    Hallo,
    Folgendes Szenario ich habe einen dicken Proxmox Cluster mit 25 Knoten. Auf einer dieser Knoten läuft eine VM, für welche ich eine Downtime von 0 erreichen möchte. Also ähnlich wie VMotion bei VMWare. Ziel ist es, dass ich die VM live migrieren kann ohne Downtime wenn ich beispielsweise einen Clusterknoten runterfahre für Kernel Updates. Ich habe gesehen, dass es den ha-manager gibt. Ich habe allerdings den ha-manager bisher so verstanden, dass dieser nur ein VM Abbild hochfährt wenn ein Knoten ausfällt. Ich hätte demnach also immer noch eine Downtime der VM und den damit verbundenen Verlust von Daten im RAM. Mein Ziel ist allerdings eine Migration der VM auf einen neuen Knoten im Falle eines Ausfalls eines Knotens ohne nennenswerten RAM Verlust.

    Ich weiß, dass es Hoster gibt die dies durch Lösungen wie Ceph und Openstack erreichen und dadurch eine "Zero Downtime" von unter 500 nanosekunden erreichen. Wie ist da der Stand bei Proxmox und brauche ich dafür ZFS oder Ceph? Aktuell habe ich den Cluster nur mit Ext4 installiert.
     
  2. tom

    tom Proxmox Staff Member
    Staff Member

    Joined:
    Aug 29, 2006
    Messages:
    13,408
    Likes Received:
    384
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. shibumi

    shibumi Member

    Joined:
    Apr 6, 2018
    Messages:
    36
    Likes Received:
    0
    Ja, aber geschieht diese Live Migration auch automatisch (beispielsweise wenn ein Cluster Knoten rebooted/heruntergefahren wird oder in einen anderen Fehlerzustand läuft)?? Oder muss ich jedesmal manuell die VM erst live migrieren und dann den Knoten abschalten?

    Meine Vorgehensweise die ich mir vorstellte war:

    "Ich reboote Knoten XY" -> Alle VMs auf dem Knoten XY werden live migriert auf einen anderen Knoten

    Was ich bisher verstanden hab:

    "Ich muss mich durch alle VMs durchklicken diese Live-Migrieren auf einen neuen Knoten. Dann auf Rebooten klicken" und dann alles wieder zurück
     
  4. t.lamprecht

    t.lamprecht Proxmox Staff Member
    Staff Member

    Joined:
    Jul 28, 2015
    Messages:
    1,087
    Likes Received:
    132
    Es gibt ein bulk migrate wo mit filtern auch nur die laufenden VMs alle auf einmal mit einem click wegmigrieren kann.

    Ein "maintenance" Modus gibts es noch nicht ist aber angeplant.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    3,514
    Likes Received:
    315
    AFAIK gibt es ähnliche Ansätze in QEMU wie z.B. Colo (https://wiki.qemu.org/Features/COLO), aber in PVE ist das aktuell nicht möglich.
     
  6. wolfgang

    wolfgang Proxmox Staff Member
    Staff Member

    Joined:
    Oct 1, 2014
    Messages:
    4,454
    Likes Received:
    285
    COLO ist so weit ich weiß noch nicht stable.
    Zumindest ist in den release notes noch nichts vermerkt und es kommen immer wieder große patches.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. fireon

    fireon Well-Known Member
    Proxmox Subscriber

    Joined:
    Oct 25, 2010
    Messages:
    2,903
    Likes Received:
    164
    Ja glaube schon das dies ein großes Anliegen sämtlicher größeren Clusterbetreiber ist. Das bei einem Reboot default alle VM's wo anders hin migriert werden. Und erst mit nem Flag (Freeze) werden die VM's mit der Node mit neu gestartet. Uns hier würde es zumindest so sehr gefallen ;):D
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  8. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    3,514
    Likes Received:
    315
    +1
     
  9. thoe

    thoe Member

    Joined:
    Feb 1, 2018
    Messages:
    48
    Likes Received:
    3
    Ja..ein... ;)

    Wenn bei uns bei Reboot eines Nodes seine VMs ganz doof auf einen anderen NOde verschoben werden, dürfte dieser unter der Last einknicken.
    Es müsste also eine Art Loadbalancing zwischen den verbleibenden NOdes geben. Auch, oder besonders bei einem Nodeausfall.
    Oder gibt's das bereits?
    Das kann ich leider nicht testen....dann kommen die User mit Mistkabeln und brennenden Fackeln in mein Büro. :D
     
  10. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    3,514
    Likes Received:
    315
    Das Erste was wir in unserem PVE Cluster aufgebaut haben war ein Test-PVE-Cluster mit dem wir genau solche Szenarien ausprobiert haben :p
     
  11. thoe

    thoe Member

    Joined:
    Feb 1, 2018
    Messages:
    48
    Likes Received:
    3
    Das hatte ich auch. Aber nur funktionell.
    Die Last konnte ich nicht realistisch nachbilden.
     
  12. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    3,514
    Likes Received:
    315
    Gut, das ist etwas schwerer. Generische Last erzeugt man prima mit Benchmark-Tools, so hat man Speicher, CPU und Disk "Verkehr". In dem Fall erzeugt man einige VMs, sodass der Server schon gut unter Dampf steht und fängt dann an zu testen, in dem man Maschinen resettet, Netzwerkkarten zieht usw.
     
  13. thoe

    thoe Member

    Joined:
    Feb 1, 2018
    Messages:
    48
    Likes Received:
    3
    Das bleibt alles nur Theorie. Und rechnen kann ich allein.
    Wenn ich auf einen Node VMs zu den bisherigen dazuschiebe und denn mehr RAM beanspruche als der Node vergeben kann passieren seltsame Dinge. Auf dem Testcluster wurden dann VMs abgeschaltet.

    Hier mel meine Erfahrungen mit Benchmarks:
    Glaub mir, kein Test spiegelt die Realität dar.
    In meiner letzten Firma haben wir 3PARs von HP zum kotzen gebracht. Dort haben dort wir den größten 3PAR-Cluster in Europa mit Live-Daten von über 60.000 Kunden.
    Der HPE-3PAR-Support ging bei uns mit schüttelnden Häuptern ein und aus. Wir konnten keine neue Firmware/UPdates einspielen weil die Grundlast zu hoch war und HPE die Datensicherheit nicht mehr gerantieren konnte. LUNs liefen voll, RAM am Anschlag, Snapshots wurden nicht mehr weggeräumt usw usw.... Das alles obwohl HPE alles "gebenched" hatte.

    Im Grunde wollte ich nur darauf hinweisen, dass VMs nicht einfach wenn ein Node stirbt hirnlos verschoben werden dürfen.
    Zu einer Zero-Downtime gehört da einfach mehr. Zum Beispiel Load-Balancing und Priorisierung.

    Aber jetzt erstmal allen einen schönen Sonntag...na gut bei uns regnets gerade. :(
    Thomas
     
  14. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    3,514
    Likes Received:
    315
    Gut, du hast Ahnung. Ist oft schwer einzuschätzen, wenn Leute hier was posten.

    Klar. Wahrscheinlich ist das einer der Gründe, dass solch eine Logik aktuell in PVE noch nicht eingebaut ist, da sie eben non-trivial ist.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice