HomeLab

[alexhell]

Ja das würde ich auch. Ich dachte nur zum ausprobieren, wenn man nicht viel aufsetzen will.

 

[plang.pl]

Bei mir gibts auch mal wieder was Neues.
Ich hab heute die neue Batterie in meiner USV verbaut.
Dann habe ich die USV umgesteckt, sodass sie nun nicht mehr an der DS, sondern am Proxmox-Host 1 hängt. Dort den USB-Port durchgereicht an eine Windows-Server 2019 VM und dort PowerChute Business Edition installiert. Dann die DS via SNMP an der DS angebunden. Jetzt fehlt nur noch, dass die beiden Proxmox Hosts mit der USV reden und sich bei Stromausfall auch runterfahren.
Der Vorteil: Ich habe jetzt die Weboberfläche zur USV im Netzwerk erreichbar und kann da auch was einstellen. Ich hätte das Ganze gerne noch über meinen Reverse Proxy geleitet. Doch das will der Webserver anscheinend nicht:

Zugriff via IP und Port funktioniert. Ich hab auch schon dazu recherchiert und nur eine "Meldung" gefunden und die ist unbeantwortet: https://community.se.com/t5/APC-UPS...NI-when-running-PowerChute-behind/td-p/438279
Ich hab auch schon manuell die ganzen Config Daten im Programmverzeichnis durchsucht. Doch dazu kann man nix einstellen...

 

[plang.pl]

Heute wollte ich das Konstrukt mit der USV mal weiterspinnen. Dabei ist mir aufgefallen, dass die Daten, die PowerChute in der WebUI anzeigt, nicht stimmen. Dies betrifft unter anderem die Last (0%) und den Batterie-Stand (10%). Ich habe dann recherchiert und herausgefunden, dass die PowerChute Business Edition nicht mit der Back-UPS funktioniert, sondern nur mit höherwertigen Modellen. Dann wollte ich die PowerChute Personal Edition installieren mit dem Ergebnis, dass der Installer den Dienst verweigert, da die Windows-Edition nicht kompatibel ist (Windows Server 2019). Dann auf Windows 11 installiert. Da geht es, allerdings kann die Personal Edition kein SNMP. Also weiter gesucht und "PowerChute Serial Shutdown" gefunden und installiert. Funktioniert auf dem W2K19, allerdings dort ebenfalls ohne SNMP. Dann habe ich diverse 3rd Party Tools getestet, um einen NUT- oder SNMP-Server bereit zu stellen unter Windows. Alles gescheitert. Ich habe dann überlegt, die USV wieder an die DS zu hängen. Dann habe ich allerdings den Nachteil, dass ich die USV selbst nicht managen kann UND ich "nur" 5 Hosts für den Zugriff auf den NUT-Server einrichten kann. Dann bin ich einfach hergegangen und hab den USB-Port der USV zusätzlich zum W2K19 noch an einen Linux-Server durchgereicht. Dort bin ich gerade dabei, irgendwie einen NUT-Server bereit zu stellen für die DS und die anderen Hosts. Auf jeden Fall schon mal positiv: Die PowerChute WebUI ist aus dem Netzwerk erreichbar und der kleine Webserver des USV-Monitorings auf dem Linux-Server. Sobald ich allerdings unter Linux auf die USV zugreife, erscheint im Treiber-Manger unter Windows ein Fehler und PowerChute kann nix mehr machen. Ist mir aber egal. Wenn ich mal was einstellen muss, fahr ich den Dienst auf der Linux Maschine runter, stelle mein Zeug ein und fahre den dann wieder hoch.
Diese Anleitung hat geholfen: https://technotim.live/posts/NUT-server-guide/#nut-ups-server

EDIT: Nach Neustart des Windows-Servers ist beides erreichbar

 

[plang.pl]

Nun einige Zeit später. Ich habe mich immer wieder gewundert, warum mein Server plötzlich offline ist. Der NUT-Server meldete immer wieder "ERROR: Data Stale". Nach meiner Recherche liegt das wohl an der Antwortzeit der USV. Per default schaltet der NUT-Server die Versorgung der Geräte ab, wenn er nach 15 sek keine Antwort von der USV erhält. Ich habe daraufhin sowohl die "Dead Time" auf 45 sek erhöht als auch die USV nur noch dem NUT-Server zugewiesen und nicht mehr dem Windows-Server. Wenn ich jetzt mal via PowerChute auf die USV will, dann ändere ich einfach fix die Zuweisung des Geräts in Proxmox. Ist der sauberere Weg, denn eigentlich geht es technisch nicht, dass ein USB-Gerät an zwei VMs durchgereicht wird.
Aktuell verteilt der NUT-Server die USV im Netz. Davon liest die DS ihre Daten (via Netzwerk-USV-Server). Da muss man Synology schon wieder was ankreiden. In der UI der DS nennt sich das "Synology USV-Server". Da spielt es allerdings keine Rolle, ob der USV-Server auf einer DS läuft, oder nicht. Lediglich die Zugangsdaten für den Server sind nach meiner Recherche in DSM gecodet und nicht änderbar. So muss der USV-Server die USV mit dem Nutzer "upsmon" und dem Passwort "secret" anbieten, sonst loggt sich die DS nicht ein. Ziemlich dumm, aber immerhin hinnehmbar. Die DS kann sich aber auch mit SNMP an einen beliebigen USV-Server verbinden. Da bin ich grad am Testen. Der Linux-Server stellt aktuell zusätzlich zum NUT die Daten auch via SNMP bereit, aber grad kann sich die DS da nicht anmelden. Warum auch immer.
So sieht der Plan aus:
-USV geht auf Batterie
-NUT-Server wartet 5 Minuten, ob der Strom wiederkommt
->wenn nicht, werden via Ansible alle Server vom USV-Server aus über ssh heruntergefahren, außer der NUT-Server selbst
-nach 8 Minuten wird noch ein FSD abgesetzt (Force Shutdown -> benachrichtigt alle Clients, die mit dem USV-Server per SNMP oder NUT verbunden sind darüber, dass sie sich dringend runterfahren sollen)
->nach 10 Minuten wechselt die DS in den sicheren Modus
->nach 15 Minuten fährt der NUT-Server die USV herunter und schaltet sich damit selbst "hart" ab

Da sind natürlich einige Dinge dabei, die "doppelt gemoppelt" sind. Aber das halte ich für wichtig. Denn wenn Ansible aus irgendeinem Grund nicht über ssh auf die Systeme kommt, dann fahren diese sich selbst herunter, wenn sie den Force Shutdown Befehl erhalten. Und wenn selbst das nicht passiert, hat am Ende des Tages wenigstens die DS das Volume ausgehängt, damit zumindest die letzten Backups aller Maschinen sicher sind, bevor diese gekillt werden. Der WinNUT Client auf den Windows-Maschinen ignoriert dieses Shutdown Signal aber, auch wenn man ihm explizit sagt, er möge doch bitte nach diesem Signal sofort herunterfahren. Das ist nach meinen Recherchen ein Bug, der wohl irgendwann mal behoben werden soll. Aber das ist auch zweitrangig. Am Wichtigsten ist mir, dass die Systeme runterfahren, wo Datenbanken laufen und halt die DS, weil letztere auch das einzige System ist, wo ein RAID läuft.
Weiterhin kann man mit dem NUT-Server auch einen Selbsttest der USV nach Zeitplan starten und dann via http Post eine Benachrichtigung an Gotify senden, wenn dieser einen Fehler aufweisen sollte. Das werde ich irgendwann auch noch implementieren.

@alexhell Ich habe nun auch ansible Semaphore aufgesetzt. Es scheint erstmal zu laufen (mit postgres), habe ich aber noch weiter eingerichtet / getestet.

In diesem Sinne, soweit das Wort zum Mittwochabend.

 

[alexhell]

Dann bin ich mal gespannt. Musst mal berichten. Ich konnte es halt aufsetzen und auch einrichten, aber kein Playbook ausführen. Vielleicht sollte ich es mal wieder testen.
Aber wie geschrieben, ich bin gespannt, ob es bei dir läuft.

 

[Wiesel6]

@plang.pl wie machst du das mit deinen ganzen internen Anwendungen. Hast du die alle als Lesezeichen im Browser?
Ich spiele mit dem Gedanken eine interne Auflistung zu erstellen mit Links zu den einzelnen Seiten, z.B. eine simple HTML Seite mit den Links. Aktuell habe ich noch nicht so viel und noch reicht es als Lesezeichen.

 

[alexhell]

Dafür gibt es Dashboards. Ich z.B. nutze Flame. Es gibt aber auch noch Heimdall, Dashy, Homarr und dieverse andere.

Edit: Sehe gerade bei Homarr hat sich sehr viel getan. Vielleicht sollte ich mir das nochmal genauer angucken.

 

[plang.pl]

Aktuell nutze ich dafür Lesezeichen im Browser. Die werden über meinen Firefox-Syncserver synchronisiert auf alle Geräte.
Bezügl. Dashboard bin ich noch dabei, eine Lösung zu finden. Habe aktuell sowohl Homarr als auch Heimdall zum Test im Einsatz. Ich kann aber auch einfach auf meinen nginx Proxy Manager und von dort sehe ich ja alle Reverse Proxies und kann diese per Klick darauf auch aufrufen.

 

[Wiesel6]

Danke euch beiden. Werde ich mir mal anschauen und testen.
Eine Verständnisfrage. Wofür ist das hier genau?
- /var/run/docker.sock:/var/run/docker.sock # optional but required for Docker integration
Was ist unter Docker integration zu verstehen?

 

[Monacum]

Das muss gesetzt werden, wenn der Container zum Beispiel Infos über eine Konfiguration mit dem Docker Daemon austauschen soll. Hier scheint das notwendig zu sein, ein anderes Beispiel wäre bei Portainer.

 

[alexhell]

Von welchem Container ist es denn? Homarr? Der zeigt dir dann Infos über alle laufenden Container.
Wenn man den Docker Daemon mounted, dann kann der Container auch deinen Docker Daemon steuern. Also Container auslesen, starten, stoppen, löschen und auch neue erstellen

 

[Wiesel6]

Danke, verstanden. Dann weiß ich, dass ich diese Optin nicht benötige.

Von welchem Container ist es denn?

Bei Flame und Homarr.

 

[Toby-ch]

Hallo zusammen

Ich habe meine "Test" Installation von Check mk an die wand gefahren in dem ich via Containermanager das Update gestartet habe.
Die Daten werden natürlich außerhalb des Containers abgelegt:


Leider erhalte ich nur noch einen:


Ach ja ein recreat hat nichts gebrach
Gibt es da noch etwas zu machen

 

[alexhell]

Was steht denn in den logs?

 

[Toby-ch]

Was steht denn in den logs?

Warst zu schnell wollte ich noch anfügen:

Update Log im Anhang:

Log des aktuellen starts:

[CODE=rich]### STARTING XINETD

 * Starting internet superserver xinetd

   ...done.
### STARTING SITE
Starting agent-receiver...OK
Starting mkeventd...OK
Starting rrdcached...OK
Starting npcd...OK
Starting nagios...OK
Starting apache...OK
Starting redis...OK
Initializing Crontab...OK
Temporary filesystem already mounted
### STARTING CRON
### CONTAINER STARTED

Was steht denn in den logs?[/CODE]

 

[Toby-ch]

@alexhell
Die Panik war umsonst ich habe jetzt nochmals aktualisiert und der Container war erreichbar.
Einzig was ich gemacht habe die Rechte des Dockers Ordner auf der Synology aktualisiert. aber keinen weiteren neue start.

 

[alexhell]

Dann ist ja alles gut

 

[plang.pl]

Ich hab hier seit einigen Tagen ein komisches Phänomen. Wenn die VMs länger als 1-2 Tage laufen, haben sie dauerhaft eine Auslastung zwischen 50 und 60% (laut Proxmox). Dies betrifft ALLE Linux-VMs, Windows nicht. Wenn ich in die VM selbst kucke (Docker stats, htop), ist die Auslastung nicht höher als 10%. Auch mein Monitoring mit Prometheus + Grafana zeigt eine Auslastung der VM von max. 10%. Es ist definitiv so, dass Proxmox das entweder falsch anzeigt oder aus irgendeinem Grund ein immenser Overhead bei der Virtualisierung entsteht. Es ist auch so, dass wenn eben alle VMs in diesem Zustand sind, das Proxmox jede einzelne mit 50-60% Auslastung anzeigt, wird die Auslastung des Hosts mit 70-80% angezeigt. Das ist in der Tat ein Problem, da dementsprechend auch die Lüfter hochdrehen.
Wenn man die VMs neu startet, ist die Auslastung wieder bei 5-10% für einige Tage. Hier mal in Bildern, was ich meine:
Die Auslastung der VM "Management-Server" (Laufzeit einige Tage):

Die Auslastung der VM "Monitoring-Server" (kürzlich neu gestartet - die Auswirkung sieht man schön am Grafen rechts, sie ging mit dem Neustart deutlich runter):

Und nun die aktuelle Anzeige im Grafana:

Also hier zeigt die Auslastung der VM auch nur 7% beim Management-Server, während Proxmox über 50% anzeigt. In der VM soweit alles ok:
htop:


docker stats:

Auf dem Dingens läuft so wie auf allen Servern quasi alles in Containern und nix ist nativ installiert, so wie auf den anderen Servern auch.
Keine Ahnung, was da los ist. Eventuell versuche ich einfach mal den RAM der VMs hochzuschrauben.
Vielleicht hat irgendjemand noch nen Punkt, wo man ansetzen kann. Recherchiert hab ich schon zuhauf ohne Erfolg

 

[Jim_OS]

Moin,

was die CPU-Last betrifft und je nach verwendeten BS in der VM: Falls Du pve-qemu-kvm=8.1.2-6 laufen haben solltest ist das scheinbar ein bekannter Bug und die Empfehlung lautet ein Downgrade auf pve-qemu-kvm=8.1.2-4 zu machen.

BTW was die RAM-Auslastung betrifft und unabhängig von Deinem CPU-Last-Problem: Das PVE aufgrund des RAM-Caching andere Werte anzeigt als es z.B. eine VM macht wirst Du ja sicherlich wissen. D.h. die Anzeige eines z.B. zwei- oder dreifachen RAM-Verbrauchs bei PVE ist noch kein Grund sich irgendwelche Sorgen zu machen.

VG Jim

 

[alexhell]

Bei mir zeigt Proxmox auch eine Auslastung von 90% vom RAM an.


HTOP zeigt aber gerade mal einen RAM Verbrauch von 2,5GB von 10GB an.


Wenn ich dann aber in Grafana gucke, dann sehe, dass der RAM voll mit Cache + Buffer Daten ist.


Daher wahrscheinlich die unterschiedliche Anzeigen. Proxmox unterscheidet nicht womit der RAM gefüllt ist, während HTOP das wohl beachtet.....