Beiträge von [netcup] Felix

    Dieser Beitrag dient dazu eventuell anderen Betroffenen zu zeigen, dass sie nicht die einzigen Kunden von Paypal sind, die Probleme mit IPN haben. Dieses hatte zumindest der Support von Paypal uns gegenüber zunächst behauptet. Recherchen im Internet zeigen jedoch auf, dass es Probleme mit dem Service von Paypal gibt. Dieses musste Paypal uns gegenüber dann auch zugeben.


    Der Zahlungsdienstleister Paypal bietet seine Business-Kunden eine Schnittstelle an, um erfolgte Transaktionen automatisch weiterverarbeiten zu können. Die Schnittstelle trägt die Bezeichnung IPN (Instant Payment Notification). Auch wir nutzen IPN, um die Zahlungseingänge automatisiert verarbeiten zu können.


    Seit ein paar Tagen wurden uns Transaktionen von Paypal nur unvollständig gemeldet. Eine Analyse hat ergeben, dass seit dieser Zeit Paypal Transaktionen zum Teil in einem Format meldet, dass der eigenen Schnittstellen-Dokumentation nicht entspricht. Das Feld "item_number" trägt in einigen Transaktionen die abweichende Bezeichnung "item_number1". Wir haben zu dieser Änderung keine Ankündigung erhalten.


    Bei Stackoverflow wird darüber bereits diskutiert: https://stackoverflow.com/ques…em-number-or-item-number1 

    Auch gibt es hier einen ersten Lösungsvorschlag für das akute Problem.


    Wir haben unsere Software bereits so angepasst, dass kommende Buchungen wieder zuverlässig erkannt werden, auch wenn Paypal sich nicht an die eigene Dokumentation hält. Paypal will uns aktuell noch unterstützen, dass wir die falsch übermittelten Transaktionen erneut gemeldet bekommen. Bei vielen tausend Buchungen je Tag würde es Tage dauern, wenn wir dieses manuell machen müssten. Allerdings vertröstet uns Paypal immer wieder aufs Neue. Das ist besonders ärgerlich, da unsere Kunden davon betroffen sind. Wir hoffen das es bald eine Lösung gibt.


    Sollten Sie sich auch wundern warum Ihre Software Transaktionen von Paypal nur noch unvollständig erkennt, dass oben Geschilderte könnte die Ursache dafür sein.


    Beste Grüße


    Felix Preuß

    Guten Tag,




    vielen Dank für Ihr Verständnis!


    Das bewerben von Optionen ist leider eine schwierige Sache. Jeder unserer Kunden hat unterschiedliche Ansprüche. Daher bewerben wir nur die wesentlichen Dinge groß und deutlich. Details können bei Bedarf eingesehen werden. Unser Vertrieb berät dazu ja auch auf Wunsch gerne.


    Die normale Anbindung teilen sich mehrere vServer. Je vServer sind hier im Schnitt 200 MBit/s möglich. Es ist nicht möglich, die bestehende Anbindung für einen einzelnen vServer zu erhöhen, ohne anderen vServer die Leistung weg zu nehmen. Daher bieten wir die dedizierte Leistung auch nur über dedizierte, reservierte Ressourcen an. Was möglich wäre ist, dass wir die Traffickosten deutlich senken, wenn Sie ein Mindestvolumen abnehmen. Ab einer bestimmten Mindestabnahme sind auch hier 1,50 Euro (inkl. Mwst.) / TB möglich. Wir erhöhen in dem Fall unsere Commitments bei den Zulieferern und können so sehr günstige Volumen-Preise erlangen.


    Unsere Root-Server und VPS sind ohne Optionen ganz klar Massenprodukte. Hier bieten wir das an, was die meisten unserer Kunden erwarten und benötigen. Abweichungen sind mit dazu buchbaren Optionen möglich.


    Mit freundlichen grüßen


    Felix Preuß

    Anzumerken ist auch, dass Traffic nicht gleich Traffic ist. Wir haben enorm hochwertigen Traffic mit direkter Anbindung an die wichtigsten DSL-Netze wie die DTAG, LGI usw... Es gibt z.B. Mitbewerber die für direkten Traffic zur DTAG extra Gebühren verlangen. Wir tun das nicht und sind unter diesem Gesichtspunkt sehr günstig.


    Ich bin mir auch relativ sicher, dass die oben genannten Alternativen keine 1 GBit/s garantierten Durchsatz haben. Hier sind nach meinen Kenntnissen 48 Server, ohne Redundanz, an einen Switch mit 48 Ports angeschlossen. Dieser Switch ist wiederum mit 10 GBit/s an den Core-Switch angeschlossen. Werden die 10 GBit/s auf 48 Server verteilt, kann jeder Server 200 MBit/s nutzen. Das kann jeder unserer vServer auch. Selbst wenn er nur 8 Euro / Monat kostet.


    Unsere Anbindung zeichnet folgendes aus:

    • Mehrfach redundante Anbindung bis zum virtuellen Server.
    • Komplett redundante Netzwerkinfrastruktur, auch bei den TORs.
    • Direkte Anbindung an die wichtigsten DSL-Provider
    • Wenn dedizierte Bandbreite gebucht wird, ist diese auch wirklich bis ans Backbone dediziert.


    Ich würde mich also freuen, wenn Sie keinen einseitigen Vergleich machen. Bitte vergleichen Sie nur wirklich dedizierte Anbindung mit unserem Angebot für zusätzlich 30 Euro (inkl. MwSt.) / Monat.



    Vielen Dank!



    Mit freundlichen Grüßen


    Felix Preuß

    Guten Tag,



    es freut uns zu hören, dass die Stucks jetzt nicht mehr auftreten. Zur Sicherheit haben wir gerade den von Ihnen aktuell genutzt Node mit Testsystemen künstlich ans oberste Limit getrieben. Der Test wird gleich beendet sein.



    Mit freundlichen Grüßen


    Felix Preuß

    Guten Morgen,


    wir haben die letzten Tage viel probiert um das Problem zu reproduzieren. Nachdem wir ein ähnliches Problem auf Nodes mit aktivierten Powersave-Governor nachstellen konnten, hatten wir die Hoffnung die Ursache gefunden zu haben. Für andere betroffene vServer scheint das auch die Ursache gewesen zu sein. Zumindest hat sich seit der Umstellung des Governors kein anderer Kunde mehr diesbezüglich gemeldet und auch auf unseren Testsystemen sind die Probleme nicht mehr aufgetreten. Selbst auf zu 100% gefüllten Nodes auf denen alle Testsysteme massive Last erzeugt haben, konnten wir das zuletzt geäußerte Phänomen nicht nachstellen.


    Es gibt allerdings mehrere mögliche Ursachen die wir jetzt eingrenzen konnten. Weitere Tests nehmen wir hierzu in unserer internen Testumgebung vor. Viel deutet auf ein Zusammenspiel zwischen Wirt-Kernel, Qemu und Gast-Kernel hin. Das wird auch dadurch bestätigt, dass das Problem bei Ihnen bislang nicht mehr aufgetreten ist.


    Sobald wird mehr wissen, werde ich berichten.


    Mit freundlichen Grüßen


    Felix Preuß

    Guten Morgen,



    es gibt ein wichtiges Update:


    Nachdem von der Problematik nur recht leere Nodes betroffen waren, auch die neuen die wir jetzt als Alternative bereitgestellt hatten, haben wir weitere Nachforschungen angestellt. Dabei ist herausgekommen, dass vermutlich ein Power-Save-Modus der neuen Intel (R) CPUs für das Phänomen verantwortlich sein kann. Dieser wurde durch Firmwareupdates vermutlich aktiv und konnte ab da von den Wirtssystemen gesteuert werden. Eventuell ist auch eine Änderung im Debian-Kernel dafür verantwortlich. Zuvor galt das, was wir im BIOS vorgegeben haben, nämlich das der Power-Save-Modus deaktiviert ist. Die CPUs wurden durch diese Änderung zum Teil auf 1,2 GHz herunter getaktet, wenn sie nicht genutzt wurden. Das haben wir jetzt geändert, in dem wir den Gouvernor auf "performance" gesetzt haben.


    Im Lauf des Tages rollen wir diese Änderung vorläufig auf allen neuen Systemen aus.


    Rückmeldungen sind willkommen.



    Mit freundlichen Grüßen


    Felix Preuß

    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 Morgen,


    ich habe Ihren Beitrag mal ins richtige Forum verschoben.


    Im Ticket schreiben Sie, dass sich das Problem durch ein Kernel-Downgrade behoben hat und wir nichts weiter unternehmen sollen. Ist das der aktuelle Stand?



    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ß