Posts by Mikey

    Also für alle mit Probleme bei Failover v6 ich hab gerade raus gefunden, dass zumindest meine Failover nach einem umhängen auf EGAL welchen Server komplett ins nirgendwo routet. Sobald ich die Failover auf der "alten" Server zurück gebe kommen Pings an. Heißt für mich die Failover macht kein Failover, obwohl alle Server via Ansible eingerichtet wurden und dass Failover mindestens 3 Mal ohne Probleme ging.


    Komischerweise ist die Failover v4 nicht betroffen bei mir. Naja morgen dann Server umziehen, ich tue mir das Debugging von komischen Routing verhalten nicht mehr an.


    Lustiger Fun Fact ist mir beim manuellen Pingen an verschiedene Hosts aufgefallen, kann jeder ja mal schauen. Die Server sind alles RS 1000 G9.5 a1 in Nürnberg (laut CCP) und wurden im Januar bestellt. Command:


    mtr speedtest.novoserve.com -w -c 10

    2 meiner aktuellen 3 produktiven Servern routen via Österreich, obwohl alle in Nürnberg stehen?

    Ja leider bringt mir der Swarm recht wenig, wenn alle Server gleichzeitig kein Netzwerk haben. Außerdem routet meine Failover v6 seit 23:15:44 nicht, heißt mein Cluster ist defacto nicht erreichbar. Kann die Failover umhängen, das ändert jedoch nichts an der Erreichbarkeit. Bin gerade echt unzufrieden.

    Hat sich erledigt.


    Problem ist die Kombination von Firefox und Plesk Optionsseite für Python (alles andere geht nur diese verdammte Python Seite mag er nicht). Ich habe keine Ahnung wieso (sehe auch keine Javascript Errors), aber via Chromium funktioniert es nun. Ich hätte gerne meine 3 verschwendeten Stunden zurück......

    Hallo zusammen,


    ich bin gerade etwas am verzweifeln, da meine django Python Anwendung nicht auf dem Webhosting läuft. Um genauer zu sein, gar nichts läuft.


    Ich bin bereits auf der Suche nach der Ursache auf folgenden Beitrag gestoßen: https://forum.netcup.de/netcup…bhosting-8000/#post156843


    An dem Punkt erst einmal danke für den tollen Beitrag :thumbup: conda und die Abhängigkeiten konnten via SSH/bash auch alle installiert werden. Nun jedoch zu meinem Problem.


    Im CCP hab ich bei meinem Webhosting EiWoMiSau gar keine Python Option, diese sehe ich nur wenn ich ins Plesk Frontend springe. Dort sehe ich auch, dass Python in meinem Produkt vorhanden und aktiviert ist (im Reiter Konto)


    Wenn ich nun auf meine Domain "beispiel.de" gehe und dort auf den Punkt Python gehe sehe ich folgendes:


    pasted-from-clipboard.png


    Wenn ich jetzt auf "Einschalten" klicke kommt folgende Meldung:


    pasted-from-clipboard.png


    Ich verstehe den Sinn der Meldung und hab dann auf "Ausschalten" gedrückt. Gebe in den Einstellungen das Verzeichnis an, wo meine passanger_wsgi.py liegt. Gehe auf "Einschalten" und alle Anpassungen werden verworfen. Sprich ich kann den Pfad, die Datei und die Python Version gar nicht anpassen. Egal in welcher Kombination wird alles was ich dort mache verworfen, sobald ich auf "Einschalten" klicke.


    Ist das normal, oder muss ich dort irgendetwas spezielles beachten. Oder ist einfach auf meinem Host (a2f24) das allgemein ein Problem. Vermutlich wird es nicht ohne der Support gehen aber ich finde das extrem komisch, da ja Plesk die Einstellungen nicht annimmt.


    Ein Hinweis auf die Richtung, in welcher ich noch schauen könnte wäre gut. Eventuell muss ich ja noch irgendwo in der Hosting oder Webserver Einstellungen etwas aktivieren? Die Frage ist nur was?

    Also der Server in VIE hat eine Latenz nach NBG von ca. 9,2 ms und die Performance von meinem alten G8 aus NBG ist nahe an den 1Gbit/s (mehr geht damit halt nicht) mit iperf3 gemessen.

    Habe gerade ein "merkwürdiges" Routing in Richtung Telekom -> Nürnberg:

    Frankfurt -> Wien -> Nürnberg? Latenz ist normal bei ca. 9-12ms damit jetzt bei ca. 30ms


    Komischerweise ist das ganze aus dem in Interxion Madrid "direkt" aus Frankfurt -> Nürnberg (man beachte den "Umweg" über Amsterdam):

    Code
    traceroute to YYY.YYY.YYY.YYY (YYY.YYY.YYY.YYY), 30 hops max, 60 byte packets
    1  10.77.13.1 (10.77.13.1)  1.372 ms 
    2  10.60.44.5 (10.60.44.5)  1.725 ms 
    3  10.50.110.67 (10.50.110.67)  31.419 ms 
    4  ae3-1337.bbr02.anx63.ams.nl.anexia-it.net (80.249.213.102)  32.219 ms 
    5  ae2-0.bbr02.anx84.nue.de.anexia-it.net (144.208.208.213)  53.839 ms 
    6  netcup-gw.bbr02.anx84.nue.de.anexia-it.net (144.208.211.11)  53.453 ms 
    7  YYYYYYYYYYYY (91.204.45.100)  53.775 ms

    Ja ist bei mir auch kaputt alle "Tabs" gehen nur bei Netzwerk kommt ein Fehler. Die normalen IP's scheinen noch zu gehen nur Failover scheint betroffen zu sein.


    Edit: Bei mir genau seit 20:01 Uhr kaputt - noch nicht behoben/gelöst. Hatte aber gestern und vorgestern Probleme, dass die Failover einfach nicht mehr auf einen Server gezeigt hat. Dann musste ich diese einfach neu zuweisen, dass geht jetzt natürlich nicht mehr aufgrund der Fehlermeldung. pasted-from-clipboard.png

    Sorry für den Doppelpost.

    Das Problem ist behoben. An für sich war der Fehler auf meiner Seite, jedoch auch ein "komisches" verhalten von Debian.


    Lösung:


    Es müssen auf dem Server:

    - Die eigentliche IPv6 (Server eigene) als network Interface angelegt werden

    - Die Failover IPv6 (die man sich aussucht z.B. für DNS) angelegt werden

    - UND die IPv6, welche die Failover IPv6 im SCP anzeigt, angelegt werden. (also IPv6 Failover + Link Local vom jeweiligen Server)


    Der letzte Punkt war mein Problem und ich konnte ihn auch nachstellen. Ich habe damals 2019 mit Ansible die Netzwerk Konfiguration erstellt. Dann ging einmal alles und ich habe geschaut, was denn "überflüssiger" Ballast darin ist. Dabei konnte ich (geht immer noch) die oben letzte genannte IPv6 entfernen und das networking restarten, ohne dass es irgendeinen Impact zu Schein hatte. Großer Fehler, denn irgendwo scheint Debian für 1800 Sekunden alle Routen nochmals zu "cachen". Danach funktioniert das ganze via Failover IPv6 einfach nicht mehr.

    Zu den sysctl Einträgen: Habe ich auch bereits getestet, dass war gestern (ja apply und reboot brachten dort auch nichts). Die Einträge sind laut Commands aktiv und werden soweit korrekt genutzt.


    Das mit dem erst Pakete von meinem Server los senden: Müsste das nicht durch die Pings bereits erledigt sein (sofern ich als Absender die Failover IPv6 nutze?), oder muss ich da etwas weiteres beachten?

    Habe gerade via mtr nochmal geschaut, jetzt bekomme ich von der Failover v6 gar keinen Host in Richtung extern mehr angezeigt?!? (Wenn ich eine falsche Absender IPv6 angebe bekomme ich korrekterweise "mtr: Address not available")


    Failover v6 nach netcup.de:

    Code
    Start: 2021-02-27T20:52:57+0100
    HOST: rcluster2 Loss%   Snt   Last   Avg  Best  Wrst StDev

    Servereigene IPv6 nach netcup.de:

    Code
    Start: 2021-02-27T20:56:45+0100
    HOST: rcluster2            Loss%   Snt   Last   Avg  Best  Wrst StDev
      1.|-- 2a03:4000:2b:1000::2  0.0%     1    0.6   0.6   0.6   0.6   0.0
      2.|-- 2a03:4000::e01e       0.0%     1    0.4   0.4   0.4   0.4   0.0


    Wie schon beschrieben die servereigene IPv6 funktioniert genau so wie ich es auch von der Failover IPv6 erwarten würde. Habe auch nochmal via "ip a" und "ip -6 r" geprüft, dort ist nichts auffälliges von meiner Seite aus.

    Sorry für den doppelt Post aber das hier ist mir auch noch aufgefallen, war aber für das Erstellen zu lange:



    Was ich komisch finde, sind die letzen beiden MTRs von extern nach Failover v6 vs. direkte IPv6 man sieht, dass vor meinem Server noch die "2a00:11c0:47:3::21" kommt. Diese IP ist bei der Failover nicht erreichbar?


    Bin gerade etwas ratlos, ob ich hier etwas nicht verstehe, oder ob die FailoverIPv6 einfach nicht sauber auf meinen Server zeigt. Ich weiß auf jeden Fall, dass die Failover IPv6 damals als ich sie initial via Ansible eingerichtet hatte ohne Probleme erreichbar war.



    So nachdem dieses Buch geschrieben ist, hoffe ich auf konstruktives Feedback. Echt nervig, wenn etwas nicht so tut, wie man es gerne hätte....

    Hallo zusammen,


    folgendes Problem besteht seit mindestens einer Woche mit meinem Server Cluster + IPv6 Failover (davor hab ich das ganze ignoriert und nicht im Monitoring gehabt). Bevor ich jetzt ein Support Ticket aufmache frage ich hier einmal nach, ob bei anderen Kunden das gleiche Phänomen auftritt. Ich konnte hier bereits Beiträge lesen, wo aber meistens der Fall anders aussieht.


    Ziel ist es mein Cluster auf lange Sicht IPv4 und IPv6 ready zu machen.


    Zu dem System:


    3x RS2000 G8, alle auf Debian Buster neuste Updates werden regelmäßig eingespielt. Kernel läuft ein 4.19 er. Macht soweit auch keine Probleme.


    Firewall und IP Config ist bis auf das Gateway und die einzelnen IP's bei allen Systemen identisch (via Ansible) eingerichtet und funktioniert auch soweit.


    Was aktuell keine Probleme macht (via DNS oder direkter IP kein Unterschied):


    • Ping 4 von netcup Server <-> netcup Server (via Failover v4 bzw. die servereigene IPv4 geht beides)
    • Ping 6 von netcup Server <-> netcup Server (via Failover v6 bzw. die servereigene IPv6 geht beides)
    • Ping 4 von externem Server <-> netcup Server (via IPv4 und Failover v4 in beide Richtungen kein Problem)
    • Ping 6 von netcup Server zum externem Server (1x von der Failover v6 und einmal von der servereigenen v6 IP)
    • Ping 6 von externem Server zum netcup Server (auf die servereigene IPv6, Failover v6 geht nicht siehe unten)


    Was aktuell Probleme macht, wo ich mir noch nicht zu 100% sicher bin, ob es wirklich in meinem Verantwortungsbereich liegt.


    • Ping 6 von externen Server zum netcup Server (bekomme hier zur Failover v6 ein: "Destination unreachable: Address unreachable")

    Auf den Servern sehe ich bei dem Interface mit der Failover v6 ein "scope global deprecated" anstelle von "scope global" bei der servereigenen IPv6.


    Das komische an dem ganzen ist, dass es so aussieht, als würde die IPv6 auf keinen Server zeigen (Zuordnung im SCP habe ich auch schon gewechselt) bzw, der Router nicht wissen, was damit passieren soll.


    Anbei mal ein paar MTRs von und zum Server. (Man vergleiche die Hops bei v6), da diese leider keine Hostnames haben, gehe ich davon aus, dass das Problem am Routing direkt vor meinem Server hängt.