Das ist quasi ein ähnlich wie ein Tor Exit / Freifunk Node / VPN Endpoint, richtig?
Dann kann man da ohne größere Einschränkungen vermutlich nicht viel machen. Um entsprechende iptables Rules konfigurieren zu können, müsste man den Server besser kennen.
Das wird netcup vermutlich garnicht gefallen. Es ist in diesem Forum leider nicht erlaubt über Konkurrenz zu schreiben. Vor allem weil netcup auch Groupware Services anbietet.
Ist x.x.x.x hierbei dein Server?
Auch hier der obligatorische Hinweis:
Server die direkt im Internet stehen sind weder gefahrlos noch Testumgebung, sollte man nicht wissen was man tut. Am besten auf eine VM ausweichen um dort zu testen.
Ich überlege derzeit auch was ich mache wenn meine Synology voll wird. Da ich auch einen Homeserver betreibe wird‘s im Endeffekt wohl darauf hinauslaufen, dass ich ein ASUS Server-Bord mit entsprechend vielen SATA Ports und Low-Energy CPU laufe und das alles in ein mächtiges 19“ Gehäuse schmeiße.
Darauf wird dann ein Proxmox mit ZFS laufen.
Oder du baust dir alternativ einen SRV Record dafür.
Da der CEPH Cluster Multitenancyfähig sein soll, muss er zwingend außerhalb des eigentlichen Kubernetes Clusters stehen. Rook.io hab ich mir angesehen, bin derzeit jedoch noch mit der Einrichtung überfordert. Mein k8s Cluster will sich einfach nicht mit dem externen Ceph Cluster verbinden.
Servus, ich versuche derzeit CEPH in einen Kubernetes Cluster zu integrieren und scheitere daran. Kennt ihr zufällig gute Anleitungen / Lektüre die sich damit beschäftigen?
Herausforderung ist, dass der CEPH Cluster Multi-Tenancy fähig sein soll und daher von mehreren Kubernetes Clustern genutzt werden soll.
Problem definitiv behoben. 
Achja, was sagt denn die Uptime im SCP? Nur um mal auszuschließen, dass der Wirt die VM rebootet hat.
Laut Netcup ist er seit über 11 Tage Online, aber bei der Eingabe von:
Ich habe nun nochmal ein Thema im Proxmox Forum eröffnet und wurde dort darauf hingewiesen, dass unter Umständen check_mk verantwortlich sein könnte.
Da ich check_mk für mein Monitoring verwende, habe ich nun ein Update ausgerollt und werde das Verhalten beobachten.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940021
Ist der Host selbst Down oder ist er nur aus Sicht der API down?
Huch? Ich wüsste nicht inwiefern das zur Lösungsfindung beitragen soll. Node wurde ausgeschlossen weil ich Nodejs nicht verwende. Die Probleme die im verlinkten Beitrag erwähnt werden beziehen sich leider auf ganz andere Symptome.
Hat niemand eine Idee?
Mein Problem habe ich leider in den VMs selbst und nicht am Host. Ein cache drop hilft leider nicht wirklich, die Usage vom SLAB bleibt bei mir gleich.
Mein Proxmox Host ist übrigens Bare Metal. Das Problem hab ich auf zwei verschiedenen Servern (1x HP DL360p G8 und 1x Eigenbau).
Bildschirmfoto 2019-12-13 um 09.54.10.png
atop output (siehe slab)
Bildschirmfoto 2019-12-13 um 09.52.45.png
free memory
Bildschirmfoto 2019-12-13 um 09.52.28.png
slabtop sorted by slabs
output aus meinem monitoring (leider erst vor kurzem eingerichtet)
Servus. Ich betreibe nebenbei auf einer dedizierten Maschine Proxmox mit KVM und hab in letzter Zeit seit Debian 10 regelmäßig Probleme mit allen Maschinen.
Ich versuche im Laufe des Tages noch weitere Infos zu liefern, da ich gerade im Zug sitze.
—
Auswirkung
Nach einiger Zeit läuft der RAM + SWAP voll und das System fährt mit 100% CPU Last weiter. Nach kurzem, langem Debuggen habe ich herausgefunden, dass es ein Memory Leak sein muss. Leider jedoch nicht von einer Software sondern direkt im Kernel.
Genauer gesagt ist der SLAB zu der Zeit mehrere GB groß. Ich kann es jedoch nicht auf einzelne Items einwchränken und komme an dem Punkt auch nicht mehr weiter.
—
Bisherige Vermutungen / Findings
Es gab im Linux Kernel wohl mal ein Problem mit den memory cgroups. Diese konnten nicht mehr beendet werden und verblieben lange in diesem Status. Ich konnte ähnliches jedoch nicht für Debian selbst finden, sondern nur für Ubuntu.
https://bugs.launchpad.net/bugs/1792349
Auch gab es mal im Raspbian Probleme mit dem inode_cache.
https://github.com/raspberrypi/linux/issues/2829
Ich habe dann in einem Blog einen möglichen Workarround gefunden, der bei mir jedoch leider nicht greift.
https://darkimmortal.com/debian-10-kernel-slab-memory-leak/
Da ich den Leak leider nicht auf einen einzigen Bereich zurückführen kann, bin ich jetzt ziemlich ratlos. Ballooning ist im Proxmox deaktiviert, ein Upgrade auf den 5er Kernel bringt ebenso nichts.
Ein System ist gerade wieder kurz vorm Crashen. Ich versuche nochmal den Output von slabtop zu erwischen.
Was hat eure Mailkuh so für ein "Moo-Level"? (Ich habe keine Ahnung, wie sich das berechnet.)
Das berechnet sich glaub ich durch den Betrag den du für die SAL bezaht hast.
