Beiträge von [netcup] Felix P.

    Guten Tag,


    nachdem sich ein zweiter Kunde jetzt mit dem gleichen Problem auf dem gleichen Node gemeldet hat und wir die Probleme an Testsystemen nachstellen konnten, migrieren wir jetzt alle Systeme von den Nodes herunter, die in der gleichen Charge produziert wurden. Ihr zuvor genutzter Node war leider auch aus der selben Produktions-Charge. Hier scheint wirklich ein Fehler an den CPUs oder Mainboard vorzuliegen. Baugleiche Systemen, die auch genau den gleichen Software- und Firmwarestand nutzen jedoch aus einer anderen Charge kommen, haben nicht die hier beschriebenen Probleme.

    Wir haben generell jede Hardware mindestens 24 Stunden in einem internen Stresstest bevor sie zum Einsatz kommt. Leider waren die Fehler hier nicht ersichtlich.

    Wir bedauern, dass wir nicht früher den Fehler erkennen konnten.


    Mit freundlichen Grüßen


    Felix Preuß

    Guten Tag,

    das die Root-Server v6 andere CPUs hatten als die G7 ist Ihnen bekannt? Je nachdem welche Software Sie einsetzen kann diese durchaus CPU-spezifisch kompiliert oder konfiguriert worden sein. Wenn Sie dann einfach das System verschieben, kann das unter Umständen zu einem solchen Verhalten führen. Bei SuSE wird der Grund des Kernelpanics recht gut erklärt: https://www.suse.com/de-de/support/kb/doc/?id=7017652

    Weitere Ursachen kann ein unsauberer Transfer sein.

    Die Ursachen eines unsauberen Transfers können Sie reduzieren, in dem Sie mit einfacheren Methoden als mit rsync transferieren. Bsp. dd oder am besten über ein Imageabbild. Eine weitere Möglichkeit wäre das System neu zu installieren, inklusive der Software und nur die statischen und Nutzer-Daten zu kopieren.

    Mit freundlichen Grüßen

    Felix Preuß

    Guten Tag,


    vielen Dank für Ihr Interesse an unseren Produkten:

    Wenn Sie viel garantierte CPU-Leistung benötigen, ist ein großer Root-Server empfehlenswert. Bei unseren VPS-Angeboten gibt es zwar eine bestimmte Anzahl von Kernen, allerdings keine Garantie das kein anderer vServer auch gerade den gleichen Kern nutzt.


    Mit freundlichen Grüßen


    Felix Preuß

    Guten Morgen,

    die Erfahrung zeigt das langsame VNC-Konsolen in der Regel auf eine Firewall zurückzuführen sind, die den https-Traffic auspackt und analysiert. Das wurde ja bereits oben angedeutet.

    Wenn nur der Windows-Defender als einziger Schutz unter Windows genutzt wird, täte ich auch sicher stellen, dass der Arbeitsplatz nicht bereits infiziert ist. Wird eine vorgeschaltete Hardware-Firewall genutzt, kann auch diese die Funktionalität den VNC-Streams behindern, wenn diese den https-Traffic analysiert.

    Darüber hinaus ist es natürlich wichtig, dass die Internetanbindung zum SCP stabil ist, hier keine Wechsel der IPs stattfinden etc. Auch benötigt der Client ausreichend Hardware.

    Mit freundlichen Grüßen

    Felix Preuß

    Vielen Dank für euer Feedback!

    Ich habe es mir mit der Schließung des Hostblogs nicht einfach gemacht. Dennoch musste ich mir eingestehen, dass die Zeit der damaligen Weblogs vorbei ist.

    Zitat


    Und die versprochenen Bilder vom Aufzug gab es nie zu sehen...

    Das tut mir sehr leid. Das ist irgendwie bei mir untergegangen. Ich verspreche das wir das auf Facebook nachholen werden. Mittlerweile gibt es ja deutlich mehr von unserem Büro in Karlsruhe und Nürnberg zu sehen,

    Viele Grüße

    Felix

    Was sollen wir denn dort schreiben? Folgende vServer haben einen Ausfall:

    v123489217858555

    v123489217858556

    v123489217858557

    v123489217858558

    ?

    vServer sind nicht dauerhaft fest an einen Node gebunden.

    Was möglich wäre, ist eine persönliche Statusübersicht im CCP. Das bedarf allerdings ein wenig Arbeit bei uns.

    LG Felix

    Guten Morgen SCD,


    um die eigentliche Frage zu beantworten: Der Server wird dann in Lauf des Tages am 02.08.2017 gelöscht werden.

    Zur Bezeichnung der Server:

    Wir wollen nicht das die Bezeichnungen der Server mit wenig Aufwand erraten werden können. Jede Bezeichnung ist eindeutig. Ein gekündigter Server wird komplett gelöscht. Einzig die IPv4-Adresse wird nach einer Karenzzeit wieder einem anderen Kunden gegeben.


    Mit freundlichen Grüßen

    Felix Preuß

    Vielen Dank!

    Haben Sie die Konfiguration selbst geschrieben? Warum nutzen Sie IDE als Treiber?

    Weitere VMs gibt es nicht?

    Ist "/var/lib/libvirt/images/debian-9.0.0-amd64-netinst.iso" wirklich lesbar? Ich frage daher da es durchaus zu kompletten Freezes kommen kann, wenn ein Device nicht lesbar ist.

    Mit freundlichen Grüßen


    Felix Preuß

    Zitat

    Ich lese nun immer wieder auf anderen Seiten, dass man evtl im BIOS etwas einstellen kann - da komm ich aber natürlich ja nicht hin.

    Was soll das sein? Wenn ich es richtig lese, haben Sie VMX bereits aktivieren lassen.

    Wenn Sie etliche Distributionen probiert haben, warum starten Sie nicht einmal ins Rettungssystem und prüfen hier die Performance von /dev/shm ? Mögliche Gründe für langsame Schreibraten auf /dev/shm habe ich ja bereits in #37 aufgeführt. Können Sie diese ausschließen?

    Mit freundlichen Grüßen


    Felix Preuß