Beiträge von andreas.

    Mich plagt es auch, Support sagt leider sinngemäß „das ist kein Grund die VM auf einen anderen Host zu verschieben“. Muss da erst was brennen? Was ist denn ein guter Grund die VM zu verschieben?

    Wobei das vermutlich auch nur eine temporäre Lösung ist, bis auch der neue Node entsprechend viele VMs hat und sich die IO Performance auch dort wieder verschlechtert. Das klingt ja alles eher nicht nach Hardware Problemen, sondern schlicht nach Überprovisionierung. Ich würde in diesem Fall einfach mal die iowait über einen längeren Zeitraum messen und falls die entsprechend hoch ist, damit zum Support gehen. Gerade wenn es ein RS ist. Bei VPS Servern hat man wohl einfach Pech gehabt. Wobei mich das auch nicht wundert, wenn hier alle den ganzen Tag über Yabs Benchmarks laufen lassen ;)


    Auch aus meiner Sicht wird ein Umzug mittlerweile nicht wirklich helfen. Denn schaut man sich folgendes Ergebnis genauer an, so rieht es eher danach aus, als werden mittlerweile aus Kostengründen die virtuellen Platten der virtuellen Server, egal ob VPS oder RS, auf sogenannte "Block Storage Volumes" ausgelagert. Mehr siehe folgendes Meßergebnis, welches ich auf einen RS 4000 G9.5 erstellt habe:

    Mittlerweile lief der Host wieder 44 Tage stabil durch, mit 7 aktiven Containern. Extra wieder keine Updates eingespielt (keine Sorge, läuft hinter einer Firewall), um das Ergebnis nicht zu verfälschen. Möglicherweise lag das Problem wirklich nur an der 8er Version, welche zu dem Zeitpunkt noch ziemlich neu war.


    Jetzt bin ich eben auf proxmox-ve: 8.0.2 (running kernel: 6.2.16-6-pve) hoch und erwarte weiterhin keine Probleme. Falls doch, dann werde ich mich hier nochmal anmelden. Ansonsten hat sich das ganze wohl erledigt ^^

    Hast du zufälligerweise während der Testphasen auch ein Snapshot vom zu testenden Servers angelegt?


    Denn ich frage deswegen, weil vor einigen Wochen ich eine E-Mail vom Support bekam, in der mir mitgeteilt wurde, dass einer meiner vServer vom Typ RS, auf dem ich auch testweise Proxmox 8 installiert habe, einen Tag später vom derzeitigen auf einen neuen Host umgezogen werden sollte und ich darum gebeten wurde, bitte den dazugehörigen Snapshot dieses Servers noch vorher zu löschen, da ansonsten der Server von denen neu gestartet werden müßte.


    Da ich aber den Snapshot zu diesem Server mit Absicht nicht gelöscht habe, habe ich während des Umzuges dann festgestellt, dass der Server zwar neu gestartet wurde, aber die Uptime im SCP bezüglich dieses umgezogenen Servers sich nicht geändert hatte. Also, die Uptime fing damit auch nicht erneut zu zählen an und das System verhielt sich auch in dem Moment genauso, als würde es mit dem Fehlerbild zum Problem mit Proxmox 7 und höher im Zusammenhang stehen.


    Auch in den Logs konnte ich zu diesem Zeitpunkt von einem sauberen Herunterfahren dieses Server nichts finden.

    Das Mitloggen wurde so gesehen einfach unterbrochen und fing erst wieder an, als der Server im Startprozess war. Dazwischen fehlen die Logmitschnitte.


    Grundsätzlich bekommen alle die bei Netcup angemieteten vServer zu mindestens aus Sicherheitsgründen ein Anfangs-Snapshot.

    ich habe ebenfalls versucht Plesk mit Proxmox auf einem LXC zu installieren.

    Also, ich betreibe Plesk unter einem LXC auf dem Hypervisor Proxmox 7.4 immer noch und bin damit immer noch sehr zufrieden.


    Allerdings treten bei mir Probleme mit /dev/urandom, /dev/null und /dev/random auf, da der Container Unpriviledged ist

    Damit man dir auch helfen kann: Kannst du mal beschreiben, wie sich die von dir beschriebenen Fehler bemerkbar machen? Denn ich habe diese Probleme unter dem OS AlmaLinux 8.X nicht.


    Allerdings möchte ich aus Sicherheitsgründen den Container nicht einfach auf Priviledged stellen – zumal der LXC ja ein Webserver ist und ein gewisses höheres Angriffsrisiko hat.

    Könntest du andreas. denn ggf. mal deine Config posten?

    Für meinen LXC nutze ich nur die von Proxmox erstellte Konfiguration, die ich auch über die GUI mit den Features "fuse=1, keyctl=1 und nesting=1" erstellen hab lassen.

    Auch mit dieser Konfiguration lauft der LXC als unprivilegierter Container.

    (a) ist das laut Einleitung viele, viele, viele Jahre her und (b) sind wir hier doch nicht bei "H" mit Consumer-Technik? 8o

    Da die Ressourcen der virtuellen Server zu mindestens vom Typ VPS bei Netcup nur virtualisiert sind, sieht man als Kunde nicht, ob die Hostsysteme von Netcup nicht in Wirklichkeit auch aus Kostengründen aus Consumer Hardware bestehen und eventuell nicht sogar vom großen Provider mit dem Anfangsbuchstaben H angemietet sind. Denn man kann sich ja auch eigene IP-Adressen von sogenannten LIR´s bestellen und bei seinem Provider seines Vertrauens dort schalten lassen.

    So ein Problem hatte ich mit der Plesk-Version Obsidian 18.0.52 vor einigen Monaten auf meinem RS 8000 G9.5 auch.


    Um das Problem zu analysieren hatte ich dann Plesk auf einen deutlich kleineren Dedicated Server aus der Serverbörse bei einem Mitbewerber in einem LXC installiert und den Traffic dann auch auf Diesen umgestellt.

    Da dieses Setup dann auch noch nach mehreren Wochen ohne Probleme lief, habe ich den LXC mit dessen aktuellem Setup dann noch mal auf den RS 8000 G9.5 installiert, womit dann auch die Probleme wieder anfingen.


    Dann habe ich mir mal beide Systeme genauer angeschaut und habe festgestellt, dass bei dem RS 8000 G9.5 laut dem Linux-Befehl SAR das IOWAIT so zwischen 0,05 bis ca. 10 % lag und auf dem Dedicated Server maximal bei 0,01 % lag.

    Der Server bei Netcup wurde dann auch mal auf einem anderen Hostsystem umgezogen, was dann aber gerade mal ca. eine Woche das Problem beseitigt hatte.


    Um dieses Problem noch weiter zu erforschen, habe ich mir dann bei dem Mitbewerber mit dem großen h einen Claud Server angemietet und auf dem dann den LXC mit dem aktuellen Setup installiert bzw. verschoben und auch den Traffic auf diesen umgestellt.

    Auch dort hatte ich durchgehend nur ein IOWAIT von ca. 0,01 % in der Spitze.


    Nun läuft seit einigen Monaten dieses Setup auf einen Cloud Server beim Mitbewerber mit dem großen h und den Server mit der Produktbezeichnung RS 8000 G9.5 hatte ich dann auch schon vor einigen Monaten gekündigt.


    Von daher würde ich mir an deiner Stelle mal das IOWAIT auf dem Server genauer anschauen. Denn das war bei mir das Problem, das es zu solchen Problemen kam.

    Seit gestern Mittag kann man aus diversen Netzen die Dienste über die Domain netcup.de nicht mehr erreichen.


    Fehler vom Webbrowser Firefox:

    Code
    Gesicherte Verbindung fehlgeschlagen
    
    Beim Verbinden mit www.netcup.de trat ein Fehler auf. PR_END_OF_FILE_ERROR
    
    Fehlercode: PR_END_OF_FILE_ERROR
    
    Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.
    Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren.


    Fehler vom Webbrowser Microsoft Edge:

    Code
    ERROR
    OOPS. SOMETHING WENT WRONG.
    Es ist ein Fehler aufgetreten. Wenn Sie hier einen Inhalt vermissen, wenden Sie sich bitte an unseren Support.
    
    An error has occurred and if you are missing any content here, please contact our support.

    For a VPS server (e.g. VPS 200 G10s) and for a Root server (e.g. RS 1000 G9.5)


    I would like to know how many vCPUs in a given processor (e.g. AMD EPYC 7702)?


    What is the difference between a vCPU from VPS and from Root server in terms of capacity (other than the core allocation guarantees)?

    For more information see here too.

    Man sollte es aber auf dem Host System mittels "lspci" sehen können, zumindest ob da ein Hardware Controller aktiv ist.

    Ja stimmt. An diesen Befehl hatte ich gar nicht mehr gedacht.


    Auf dem VDS ist es auch nur eine virtuelle SSD:

    Code
    lspci | grep 'controller'
    ...
    00:05.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI
    ...

    Wenn du den Disk Treiber bei Netcup auf scsi umstellst, solltest du eigentlich den gleichen Output bekommen wie bei dem Mitbewerber.

    Vielen Dank.

    Soeben habe ich es mir noch mal an einem kleinen RS über das Rettungssystem angeschaut und bekomme auch mit dem virtio-scsi Treiber die Werte angezeigt, die ich auf dem VDS des Mitbewerbers angezeigt bekomme.


    Bei einer echten Disk würde im hdparm Output noch viel mehr auftauchen.

    Und wie sieht es aus, wenn ein Hardware-RAID-Controller zwischen der SSD und dem OS ist?

    VDS mit dedicated Storage wäre wirklich mal was.

    Ob da auch tatsächlich ein Platten- oder SSD-Array durchgereicht wird, kann man z.B. mit dem Befehl hdparm (hdparm -I Laufwerk) abfragen.


    Auf dem Netcup vServer (RS 4000 G9.5) sieht die Ausgabe wie folgt aus:

    Code
    hdparm -I /dev/vda
    /dev/vda:


    Auf dem VDS des Mitbewerbers sieht die Ausgabe wie folgt aus:

    Ich nehme mal an, dass zwischen dem SSD-Array und dem VDS ein RAID-Controller hängt und keine virtuelle SSD.

    Gestern ist mir einer der vServer vom Typ RS 4000 G 9.5 wieder neu gestartet. Diesmal aber nicht mit Proxmox 7 oder 8, sondern mit Debian 12 und der Kernelversion 6.1.0-11-amd64.


    Über die Logs sieht man leider nichts.

    Von daher sieht es für mich als Endanwender eher so aus, als würden die vServer nach ein par Tagen einfach mal vom Host willkürlich neu gestartet werden. Denn ich habe ja mehrere vServer vom gleichen Typ bei Netcup, die sich identisch verhalten.


    Gestern habe ich mal beim Mitbewerber einen der neueren Generationen mit der Bezeichnung VDS bestellt und dort das gleiche Setup wie auf einen vServer bei Netcup installiert und werde jetzt auch da mal beobachten, ob dort die Systeme auch so willkürlich wie bei Netcup neu gestartet wird.


    VDS = Virtual Dedicated Server

    Diese Art von vServer soll sich laut den Providern, die solche vServer als VDS anbieten, ähnlich verhalten wie Dedicated Server.

    Ist bei jemandem der Fehler schon behoben? Bei mir gehts leider noch immer nicht und kann deshalb meine Firewall nicht deployen :/

    Soeben wurde der Fehler bei mir im SCP gelöst.

    Schau mal auch bei dir, ob auch bei dir im SCP das Problem nun gelöst wurde.

    Bin ich der einzige mit dem Fehler, oder hat den noch wer? Wenn ich versuche auf "Netzwerk" im SCP zu klicken, kommt: Entschuldigung, das sollte nicht passieren. Ein Serverfehler ist aufgetreten. Sollte der Fehler wiederholt auftreten, setzen Sie sich bitte mit dem Support in Verbindung. Tritt bei all meinen Servern auf...

    Bei mir für Server in Nürnberg habe ich auch das Problem.


    Gestern habe ich schon ein Ticket dafür aufgegeben. Und eben wurde mir mitgeteilt, dass das Ticket an die technische Abteilung nun weitergeleitet wurde.