Mal ne Frage in die Runde: hatte den Rebootfehler schonmal jemand mit Intel CPU? Ist mir heute zum ersten Mal aufgefallen, dass die auch betroffen sind.
Beiträge von voja
-
-
Das fehlen, ist per default ja nicht installiert
Ich habe den qemu-guest-agent in beiden Fällen installiert.
-
Ausschließlich bezogen auf Root-Server Gen9, oder?
Richtig. Um es genauer zu sagen:
Proxmox 6 läuft auf einem RS 8000 G9
Proxmox 7 läuft auf einem RS 1000 G9
Proxmox wurde jeweils per ISO Installer mit ZFS Root Filesystem installiert.
-
vielen Dank für eure zahlreichen Meldungen. Gerne möchten wir diese gesammelt untersuchen, um unsere Produkte weiter verbessern zu können. Bitte kontaktiert uns daher jeweils mit folgenden Daten und einem kurzen Verweis auf diesen Beitrag hier per E-Mail an mail@netcup.de. Wir sammeln die Fälle, um Gemeinsamkeiten finden zu können. Dies erlaubt es uns, den Sachverhalt bestmöglich zu analysieren
Ich habe meine Antwort eingeschickt. Wenn ich noch irgendwie helfen kann, einfach melden. Das Problem nervt echt und ich traue mich aktuell nicht mein Proxmox 6 auf 7 upzudaten.
-
voja: Könntest Du uns/mich bitte auf dem laufenden halten wie es Dir mit der Containerverschiebung auf Proxmox 6 ergangen ist?
Eventuell müsste ich das ebenfalls für meine Container machen
Ich habe den Container vor 2 Tagen auf Proxmox 6 (Kernel 5.4.128-1-pve) verschoben. Die Maschine hat inzwischen eine Uptime von 101 Tagen ohne Probleme.
Die Proxmox 7 VM hat seitdem der Container weg ist dreimal spontan neu gebootet. Die VM ist jetzt ansonsten Idle.
-
Ich habe einen wichtigen Container von Proxmox 7 nach 6 verschoben, in der Hoffnung dass er so stabil läuft.
Ich muss mir dann auch überlegen was ich mache. Evtl. muss ich zurück zu lxd migrieren, oder in der Tat die ganzen Container von Netcup weg migrieren. -
Aber du nutzt jedenfalls das VMX flag + nested KVM, richtig?
Nein, bei mir passiert das ohne VMX Flag mit Proxmox 7, bei Proxmox 6 nicht.
-
Voja wird einfach nur die Benachrichtigung im CCP meinen, das hat nix mit dem Problem zu tun. Eher wie wenn dein linux dich auffordert mal neu zu starten weils ja kernel updates gab und du glaubst damit dein GPU treiber problem zufällig zu lösen.
Genau die Benachrichtigung meine ich. Mal schauen ob die Maschine jetzt wieder innerhalb von einem Tag neustartet...
-
genau darum gings mir. Wenn das mit der aktuellen Proxmox VE 7.1-4 und kernel 5.13.19+ immer noch der Fall sein sollte
Ich habe gestern meinen Node mit Proxmox 7 auf den Kernel 5.13.19-1-pve upgedated. Heute Morgen kam es wieder zu dem Reboot Problem. Das System läuft laut SCP seit über 200 Tagen. Es ist ein KVM Update ausstehend. Ich werde jetzt erstmal die Kiste runterfahren, damit das KVM Update sicher greift und dann nochmal beobachten. Ich habe das Reboot Problem nur auf dem Proxmox 7 Node, der Proxmox 6 Node läuft ohne Probleme.
-
Was ich echt super fand: Abrechnungszeiträume < 1 Jahr und sogar welche mit 3 Monaten. Mit 1 Jahr Vertragslaufzeit kann ich leben, die Abrechnung von 12 Monaten auf einmal will ich aber nicht mitmachen.
Andererseits hätte ich sonst noch mehr geholt. ? -
ich bin irgendwie gerade auf sowas wie ein Henne-Ei Problem gestoßen;
sollte das hier nicht
https://www.internic.net/domain/named.root
unter einer sogenannten 'well-known' IP veröffentlicht werden?
Die root hints sind im recursive resolver hinterlegt / konfiguriert. Die IPs ändern sich ja zum Glück nicht ständig.
-
Vielen Dank michaeleifel für die ausführliche Erklärung! Ich werde mich mal am Wochenende hinsetzen und versuchen das mit meinem Ansible Playbook nachzubauen.
-
Der HAProxy läuft als Pod in Kubernetes, exposed aber per Konfiguration verschiedene Ports. Auf den Nodes / Workern läuft aber auch ein HAProxy der die Kubernetes API von den Master loadbalanced. Deswegen macht das Umschalten der Floating IP auch gar nichts im Cluster selbst sondern dadurch ist "nur" die Verbindung von draußen an die FloatingIP unterbrochen. Das der Ingress aber auch auf allen Nodes auf alle Requests reagiert und sie weiterleitet, kann jede beliebige Node auch bspw per "/etc/hosts" angesprochen werden.
Okay, das verstehe ich jetzt.
Der keepalived läuft aber in dem Fall nicht als pod, oder? Der kann überall laufen, wo der Ingress Endpunkte hat. Die prüft der keepalived. Falls der master nicht mehr healthy ist, würde also einfach der nächste übernehmen, die IP umschalten und dann sind alle Ports direkt wieder erreichbar, nur eben auf dem anderen Node. -
So richtig HA geht meiner Meinung nach mit Netcup nicht, da man nicht schnell genug und automatisiert die ölffentliche IP-Adresse des Clusters (müsste dann eine Failover-IP sein) umswitchen kann - jedenfalls habe ich das bisher nicht geschafft. Sollte jemand dafür eine Lösung haben... gerne her damit.
Ich habe auch ein Setup mit keepalived, das eine IPv4 und IPv6 Failover umschwenkt. Allerdings noch nicht mit Kubernetes zusammen. Manchmal dauert das Umschalten und ich musste für meine Anwendung Optimierungen einbauen, damit es zu keinem Nodeflapping (und damit längeren Downtimes) gibt.
-
Habe 3 Master im Einsatz die über ein CloudVLAN miteinander kommunizieren. Nach außen hin switche ich die FailoverIP, das ist <20 Sekunden eigentlich erledigt. Das passiert automatisch über Keepalived was Checks ausführt. Bspw wenn ich eine Node tainte, dann wird die IP verschoben.
Schneller geht`s beim Loadbalancer auch nicht unbedingt, es sei denn man hat sekündliche Healthchecks. VPS500 sollte reichen, wichtig ist auf jeden Fall ne 2C Maschine.
Zum Verständnis: wo läuft der HA Proxy? Ist das auf dem Kubernetes Node wo etcd bzw. die Controlplane läuft? Oder läuft der innerhalb vom Kubernetes als Pod? Was läuft alles auf dem Master?
-
VPS 500 dürfte als Master reichen, ggf. VPS 100
Nachdem was ich gelesen habe ist der etcd etwas anfällig wenn die Maschine ausgelastet ist. Da hätte ich bei VPS bedenken.
Daher hätte ich etcd+controlplane auf einem Node vorgesehen.
-
Hallo,
mich würde mal interessieren wie ihr einen kleinen HA fähigen Kubernetes Cluster bei Netcup dimensionieren würdet.
Auf dem Cluster sollen ein paar Anwendungen laufen, die jeweils 2-4 GB Speicher belegen.
Kann man etcd plus Controlplane auf einen RS 1000 packen (und davon dann drei Stück wegen HA)? Dazu würden sich dann mindestens drei Workernodes gesellen, dachte an RS 2000-4000.
Oder würdet ihr ein anderes Setup vorschlagen?Viele Grüße
Volker
-
Halt, des kann nicht stimmen, oder ist bei Dir Lok kaputt, nur weil die Strecke unterbrochen ist?
Nein, ich sehe in dem Fall ja nur die kaputte Strecke. ?
-
wenn auf Grund eines Netzwerkproblems die Verbindung zwischen Agent und Monitoring unterbrochen ist?
in dem Fall würd einem das Monitoring System mitteilen,
dass der Server xy nicht erreichbar ist, aber das würd man ohne Agent auch wissen
Failure by Design?
Ohne Netzwerkverbindung wird aber kein Alarm die Maschine verlassen… Ich habe keinen Zugriff auf das Hostsystem um extern ne Box mit SMS Versand etc. anzuschließen. Sind ja auch Rootserver.
Immerhin weiß man, dass etwas auf der Maschine nicht stimmt. Aus der Summe der Meldungen kann man dann schon anfangen den Fehler zu suchen. Sollte der Agent abrauchen kriege ich das gemeldet, sollte das Netz abrauchen dito. Und alle anderen Fehler meldet das Monitoring. -
wenn ma am zum monitorenden System was installieren muss,
um es dann in ein Monitoring "einzuhängen" hat man bereits was falsch gemacht;
Worin besteht da das Problem? Ein Agent kommt lokal an alle Infos, die über das Netzwerk nicht zugänglich wären. Bei Icinga gibt es einen Check der prüft ob alle Agents verbunden sind. Plus man kann getrenntes Monitoring aufsetzen, dass prüft ob das Monitoring ansich läuft.
