Beiträge von peterbo

  • Das längste Thema

    Zitat von nitram

    Das ist aber nen wählbares Feld... Momentan nur mit der CPU aber vlt kommt ja mal was anderes :D

    Bei der Konkurrenz ist vor ein paar Tagen die Cloud mit Zen3 EPYCs (7703) an den Start gegangen. Ob das bei Netcup auch bald kommt? Hat da jemand vielleicht Infos / Gerüchte?

  • Backbone / Routing Q&A

    Hallo Theo,

    vielen Dank für's Kümmern und die Mühe!

    Zitat von [Anexia] Theo V.

    Wir haben jetzt noch mal Kontakt mit "H" aufgenommen und werden unsere PNI-Kapazitäten vorbeugend noch weiter aufbohren, auf 2x100GE über zwei Router verteilt, sodass es zukünftig keine Probleme mehr geben wird, wenn ein Router sowohl bei uns als auch bei "H" Probleme macht.

    Ganz großes Tennis, da bleibt kein Wunsch offen!

    Vielen Dank für die tolle Arbeit. Ich werde berichten, wie sich das in den nächsten Monaten entwickelt, aber ich weiß schon einmal Bescheid, dass das Problem dann sicher nicht auf NC/Anexia-Seite liegt. :)

    Viele Grüße

    Peter

  • Backbone / Routing Q&A

    Zitat von [Anexia] Theo V.

    Hallo peterbo - danke für deine Meldung. Wir haben in den letzten Tagen leider immer wieder Probleme mit "H", Traffic wird uns auf unüblichen Wegen (via N-IX, statt über unseren PNI) zugestellt. Wir laufen dem leider im Moment reaktiv hinterher, vom H-NOC bekommen wir keine Rückmeldung. Wir haben jetzt grade noch mal etwas Traffic Engineering betrieben, kannst du bitte noch mal prüfen, ob das Problem noch besteht?

    Hallo Theo,
    besten Dank für die schnelle Antwort und den klasse Support!


    Derzeit läuft es wieder stabil. Ab dem 27.3 hat sich die Situation insgesamt wieder verbessert; Seit dem 1.1.21 meldet das Monitoring allerdings schon 20 Ausfallperioden des Peerings. Mittlere Länge der nicht-Nutzbarkeit (=Latenz >100ms und Paketloss, gemessen von 20+ H*** Maschinen und 4 Zielen bei Netcup) sind 15 Minuten, mit Spitzen von 45 Minuten. 5 Minuten können wir das kompensieren, danach fangen die Loadbalancer das Rotieren an. Insgesamt verlieren wir da also etwas das Vertrauen in die Stabilität - mit schlechteren Latenzen kommt die Topologie klar, aber Paketloss ist der Killer. Der Support von H* hält sich da leider sehr in Grenzen, hoffe aber sehr, dass dies auf deren Seite auch bald etwas höher priorisiert wird.

    Vielen Dank für Deinen Einsatz!!
    Peter

    Nachtrag mit Antwort des Supports (H):

    >der PNI zu Netcup/Anexia ist an dem ausgefallenen Router.

    >Deswegen ging dieser kurzfristig ueber den N-IX.

    >Heute geht dieser wieder direkt ueber den PNI.

    Allerdings wurde nicht beantwortet, warum dies seit dem 1.1. schon so oft vorkam bzw. ob nur jedesmal der defekte Router wiederbelebt (Abstauben und streicheln?), oder endlich mal getauscht wird/wurde; Oder noch besser: Redundant gemacht wurde.

  • Backbone / Routing Q&A

    Hallo zusammen, ich habe hier, insbesondere in den letzten Tagen, ein kleines Routing / Latenzproblem mit einem anderen Hoster.

    Wir betreiben Infrastruktur bei Netcup und einigen anderen Anbietern, darunter auch dem im gleichen Rechenzentrum mit dem roten "H". Seit Januar und ganz schlimm auch wieder in den letzten Tagen, läuft das Peering sehr instabil. IP4 und IPv6 gleichermaßen. Normalerweise ist die Latenz zwischen 0,5 und 2,5 Millisekunden, zu den Ausfallzeiten steigt die Latenz auf 80-120 Millisekunden und Paketloss setzt ein:

    Route Netcup zu H*****:

    Code
    HOST: ncdb-m                      Loss%   Snt   Last   Avg  Best  Wrst StDev
1.|-- 2a03:4000:4e::2            0.0%  1000    5.9   2.7   0.2  82.5   9.8
2.|-- 2a00:11c0:47:3::32         0.0%  1000    1.9   1.4   0.3  58.6   4.9
3.|-- 2a00:11c0:47:1:47::139     0.1%  1000    0.4   5.5   0.3 111.7  13.5
4.|-- 2a00:11c0:47:1:47::141     7.4%  1000    3.4   7.0   3.3 108.4  10.4
5.|-- decix-gw.h*****.com       0.3%  1000   10.5   6.9   1.1  81.1   8.8
6.|-- core12.nbg1.h*****.com   19.7%  1000   99.3  98.3   4.4 143.3  16.7
7.|-- 2a01:4f8:0:e0c0::a0c2      1.4%  1000  102.3  83.6   1.2 229.2  38.6
8.|-- hxapp          82.9%  1000   49.3  10.2   0.6  49.3  13.8

    Andere Richtung:

    Code
    HOST: hxapp                       Loss%   Snt   Last   Avg  Best  Wrst StDev
1.|-- 172.31.1.1                 0.0%  1000    5.0   5.2   3.2  26.7   1.2
2.|-- 15902.your-cloud.host      0.0%  1000    0.3   0.2   0.1   0.9   0.0
3.|-- static.65.139.12.49.clien  0.0%  1000   13.1  57.2   1.1 795.8 112.7
4.|-- static.88.198.252.165.cli  0.0%  1000    0.9   4.6   0.7 102.6  11.9
5.|-- core12.nbg1.h*****.com    0.0%  1000    2.2   2.3   0.4  31.2   3.9
6.|-- juniper4.dc2.nbg1.h******  0.0%  1000    0.4   0.6   0.3  26.2   1.4
7.|-- xe-65-0-2-900.bbr02.anx84 78.6%  1000   93.3  75.2  22.1 111.8  25.9
8.|-- netcup-gw.bbr02.anx84.nue  1.5%  1000   93.4  95.1  19.7 1560.  53.3
9.|-- ncdb-m               1.6%  1000   97.0  92.5  18.2 1449.  48.8


    Das treibt uns etwas in die Verzweiflung, da unsere Systeme zwar für eine gewisse Zeit mit höheren Pings klar kommen, aber das gepaart mit Paketloss bringt die Datenbank-Replikation zum Erliegen und die Loadbalancer melden reihenweise ausgefallene Backends. Falls es hilft, kann ich gerne auch noch ein paar Zeiten hinzufügen, in denen es besonders schlimm war. Kann hier jemand evtl. mal schauen, was hier schief läuft?

    Besten Dank im Voraus und viele Grüße!

  • Kernel Panic bei Reinstall

    Das Problem mit dem "reinstall" hatte ich nach einer Image-Installation auch schon. Glaube nicht mal, dass dies an der Kernel-Panic lag, sondern es ist ein weiter verbreitetes problem: Siehe https://forum.netcup.de/anwendung/scp-…ie-sein-sollte/

    Nach 10 Stunden verschwand das "reinstall" erst und ich konnte wieder Aktionen im SCP ausführen. Der Support antwortete erst 14 Tage später auf erneute Nachfrage auf das Problem mit dem "reinstall". Ergo: Wenn etwas schnell gehen muss oder dringend ist, hängt man hier in der Luft.

  • (Zu) hohe Read-Latenz bei Netcup Root-Servern?

    Hallo zusammen,

    ich habe einige Netcup (Root)Server und auch Server bei anderen Anbietern. Bei anderen ANbietern sind teilweise dedicated vCores, aber auch shared-Instanzen dabei. Bei den Netcup-Root-Servern habe ich allerdings eine Gemeinsamkeit, die bei keinem der anderen Anbieter so auftritt: Eine (zu?) hohe read-latenz. Die Schreibgeschwindigkeit ist vergleichbar, oder sogar überdurchschnittlich, aber für z.B. MySQL für hohe Lasten und große Datenbanken, die nicht ins RAM passen, ist diese Latenz ein maßgeblicher Faktor.

    Anbei einige Screenshots, erst von zwei verschiedenen Servern bei NC (Datenbanken):

    nc-rl2.JPG

    nc-rl1.JPG


    Und nun zwei Beispiele eines anderen Anbieters (beides Shared vCore Cloud Instanzen):

    h-rl.JPG

    h-rl2.JPG

    Zwei Workloads sind natürlich nie exakt miteinander zu vergleichen. Allerdings würde ich dem Problem schon gern auf den Grund gehen, da dies u.U. die Performance stark verbessern könnte.

    Vielen Dank im Voraus für Eure Ideen!

  • Email Versand pro Domain, Tageslimit. Kleiner Verlag kämpft mit Corona. Sollte Netcup helfen?

    Zitat von Andi22

    Stimmt.https://www.mailjet.de/ ist da besser. Da steht eine französische Firma dahinter.

    Guter Einwand. Technisch sollte das ähnlich sein und gleichzeitig DSGVO konform. In der Datenschutzrichtlinie sollte das trotzdem erwähnt sein. Hier sei dem Themenersteller eRecht24 (oder der Händlerbund) ans Herz gelegt, die u.a. für MailJet die passenden Texte anbieten.

    Persönlich finde ich, dass man Netcup hier keine Schuld geben kann. Der Versand von 100 eMails pro Stunde erfordert einfach besondere Lösungen, die ein Hostingpaket einfach nicht out-of-the-box liefern muss. Wenn man so viele Emails verschickt, muss man wissen, was man tut und auch Geld in die Hand nehmen.

  • Servermigration leider nicht so smooth, wie sie sein sollte

    Zitat von michaeleifel

    urze Frage: Hast du die Generationen gewechselt? Ansonsten bietet sich doch ein Sidegrade an.

    Nicht direkt, beides G9, aber das eine ist der RS Special 3, den es nicht als herkömmliches sidegrade gab.

    Zitat von michaeleifel

    Mir ist bisher auch kein Provider in der Preisregion bekannt der solche Aktionen unterstützt,

    Das können doch die meisten heute im consumer-Bereich. Da tut sich eher der Enterprise-Bereich schwer mit diesen Features. Aber darauf wollte ich gar nicht wirklich hinaus, es ging um angebotene Features, die haken und genau deshalb da sind, um dieses Problem zu lösen. :)

  • Servermigration leider nicht so smooth, wie sie sein sollte

    Grüß Euch zusammen,

    ich dachte, ich mache mal ein Thema auf und beschreibe meine erste Root-Server Migration innerhalb der Netcup-Welt. Vorausgeschickt: ich bin Netcup-Fan, da Preis/Leistung unschlagbar ist und die Server wunderbar schnell und stabil laufen. Ich habe Server (Baremetal & Cloud) bei einigen Hostern, daher beschreibe ich nur meine Erfahrung mit NC.

    Zu einer Einsetzbarkeit in Produktivumgebungen braucht es allerdings etwas mehr als nur eine schnelle und stabile Laufzeitumgebung, nämlich auch, dass die Migrationsvektoren verlässlich, berechenbar und fehlerfrei funktionieren. Damit spreche ich nun auch nicht die Puristen an, die ihre Migration per DD durchführen und zur Partitionierung alle Befehle im Schlaf beherrschen. Dies tun viele hier im Forum, mir geht es aber um die Mechanismen, die genau dafür da sind und funktionieren müssen. Auch möchte ich keine Diskussion entfachen über Failover und Redundanz - ist alles da, darum geht es aber nicht.

    Ziel: RS2000 auf größeren RS migrieren.

    Plan:

    - Produktiven Server herunterfahren

    - Offline Snapshot anfertigen

    - exportieren auf Snapshot FTP

    - Installation des Snapshot auf neuem Server

    - Einbinden der Failover-IP und des Networking Stack

    - Anpassung der Partitionsgrößen (da neuer Server mehr Platz) - hätte ich gern kurz mit dem GParted Image gemacht, da es nachts um 3 einfacher ist

    Schritte und Unwegbarkeiten:

    • Produktivserver ausschalten - keine Probleme
    • Offline Snapshot anfertigen - keine Probleme und überraschend schnell
    • Snapshot Export
      • Erste Überraschung - es wird vermeldet, dass dieser Vorgang länger dauern kann, da nur mit geringer Priorität durchgeführt. Nicht optimal finde ich, denn man möchte ja die neue VM so schnell wie möglich wieder ans Netz bekommen. Auch in einer Situation, die, aus welchen Gründen auch immer, zeitkritisch ist, wäre das nicht optimal. Hier wäre eine Option gut, dass man diesen Vorgang beschleunigen kann (Extrakosten wären in Ordnung). - Dauer ca. 50 Minuten, Image-Größe ca. 145GB.
      • Zweite Überraschung: Während das Image auf den FTP geladen wird, kann man den Host NICHT mehr starten, da "auf diesem gerade eine andere Aktion ausgeführt wird". D.h. die Maschine läuft nicht, während mit niedriger Priorität auf einen FTP hochgeladen wird? - Das macht keinen Sinn, man ist aber gezwungen, das abzuwarten.
    • Image auf neuer Maschine auswählen und installieren - klappt erstmal wunderbar, auch wenn es keine Fortschrittsanzeige gibt. Man muss warten, aber es geht einigermaßen fix.
      • Dritte Überraschung: Nach Beendigung der Image-Installation wird als Aktion noch "reinstall" im SCP angezeigt (dazu gibt es auch schon einige Threads hier im Forum). D.h. keine der im SCP verfügbaren Einstellungen funktioniert, da "gerade eine andere Aktion durchgeführt wird". Ich kann weder eine IP zuordnen/löschen, noch ACPI Befehle senden, kein Image einbinden, nicht einmal das Keyboard-Layout des VNC kann man ändern. Wenn ich für die neue VM nun eine Failover-IP einbinden müsste, wäre ich richtig gekniffen, denn das funktioniert nicht. Der Status "reinstall" hielt noch weitere 10(!!!) Stunden an, d.h. ich musste den Server quasi unfertig wieder ans Netz bringen.
    • Vierte (eigentlich nicht wirklich überraschend, da immer so bei NC, aber trotzdem lästig!) Überraschung - wenn man kurzfristig eine Failover IP benötigt, kann man diese nicht gleich verwenden, sondern muss Stunden lang warten, bis ein Mitarbeiter diese freigibt. Da bildet eigentlich NC auch die Ausnahme, da dies bei vielen anderen schon on-the-fly geht. Das tut vor allem den Admins weh, die vorher nicht perfekt planen und kurzfristig immer mal Sachen brauchen (dazu zähle ich mich leider selbst auch).

    Hier besteht noch einiges an Verbesserungsbedarf, vor allem was das Handling im SCP betrifft. Dies soll durch Stabilität und Schnelligkeit punkten und nicht die Schweißperlen auf die Stirn treiben. gerade die Entscheidung auf virtualisierte Hardware zu setzen geschieht auch aus dem Grund, genau an diesem Punkt flexibel zu sein und keine Stundenlange Migration hinlegen zu müssen, die es eigentlich nicht bräuchte.

    Wie ist Eure Erfahrung / Meinung dazu bzw. wie kam euch dieser Vorgang vor? Besser / Schlechter?

  • Was ist Eure Meinung zu Post Privacy?

    Zitat von aRaphael

    Noch eine weitere meiner egozentrischen Anekdoten: Ich hab auch keinen Facebookaccount :)

    Tja, schon schlimm, wie ich mich um diese "komplexen und /oder sozioökonomische Zusammenhänge" herumdrücke.

    Sollte kein persönlicher Vorwurf sein; Jeder, wie er es gern möchte. Aber es sollte einem auch klar sein, dass man seine persönlichen Vorlieben und Lebensumstände nichts über das große Ganze aussagen und auch in der Diskussion nciht wirklich hilfreich sind. ;)

  • Was ist Eure Meinung zu Post Privacy?

    Zitat von aRaphael

    Ich lebe gut ganz ohne Whatsapp und habe auch nicht vor das jemals zu installieren.

    Wohl leider ein Problem unserer Zeit, dass Menschen große, komplexe und /oder sozioökonomische Zusammenhänge mit einer egozentrischen Anekdote lösen möchten. "Schmeißt Windows und MacOS einfach weg; Braucht kein Mensch! Ich kompiliere mir mein Linux selbst..."