Posts by mlohr

    Liebe Netcup-Gemeinde,


    ich bin mir nicht sicher, ob der Thread hier richtig aufgehoben ist, da es mehr um Netzwerk-Administration als Server-Administration geht, da es hier aber leider kein passends Unterforum dafür gibt, probier ichs mal hier.


    Der Grund meiner Frage: Ich beschäftige mich gerade ein bisschen mit Netzwerken, Routing und HA. Bei den Themen stolpert man schnell über Begriffe wie HSRP, VRRP, LACP etc. - mit all denen kann man irgendwie HA-Lösungen zusammenbauen. Allerdings glaube ich, dass ich an einer Stelle noch nicht komplett verstanden habe, wies da läuft. Nehmen wir folgendes an: Es gibt einen "Übergabepunkt", meinen Provider, der hat irgendeine Infrastruktur die ganz bestimmt redundant ausgelegt ist, aus meiner Sicht eine Blackbox. Aus dieser Blackbox kommen nun zwei (bestenfalls Glas)Kabel heraus mit "Internet". Mir wurde außerdem eine IP verraten (10.0.0.1) die Gateway ist. Ggf. gibt es da noch IP-Adressen (10.0.0.2 und 10.0.0.3) die Router physikalisch adressieren. In meinem Modell besitze ich nun zwei Switches an dem jeweils eines der Uplink-Kabel angeschlossen ist.


    LACP: Ist der Uplink mit LACP konfiguriert muss ich das auf meiner Seite auch entsprechend tun - sprich ich benötige Stacked Switches und konfiguriere (Cisco-Sprech?) eine L(ink)ag(gregation)g(group) die über die Glasfaseranschlüsse beider Switches geht. Ist entweder ein Uplink-Kabel oder einer meiner Switches tot läuft noch alles weil LACP erkennt das und leitet Traffic nur noch über das, was noch nicht so tot ist.

    VRRP: Uplink-Seitig ist VRRP konfiguriert, d.h. die beiden Uplink-Glasfaser versuchen sich gegenseitig über Multicast davon zu überzeugen, dass sie leben. Geht der aktive kaputt, bekommt das der passive mit und krallt sich nach einem gewissen Timeout die Gateway-IP (10.0.0.1). Meine Switches bekommen irgendwie mit, dass das passiert und... joa. Ich habs nicht verstanden. Wie muss ich meine Switches konfigurieren (muss ich das überhaupt?), damit die mit VRRP gegenüber klarkommen? Naiv hätte ich jetzt gesagt: Switches mal wieder stacken, Glasfaserports in ein VLAN stecken. Dann müsste ich über einen Switch 10.0.0.2 und über den anderen Switch 10.0.0.3 erreichen, und je nachdem welcher gerade aktiver VRRP-Knoten ist ist auch die 10.0.0.1 zugewiesen. Und ich habe mit dem Setup keine Probleme mit Loops, weil es keinen Loop gibt, weil das Uplink-Ding hintenrum (innerhalb der Blackbox) nicht verbunden ist. Soweit richtig verstanden?


    Über Tips wäre ich sehr dankbar.


    Viele Grüße
    Matthias

    Woher kenne ich das...


    Sollen wir eine Petition starten, dass Netcup zwar weiterhin günstige Preise anbieten soll, aber pro Bestellung pro Tag (oder Woche, oder Monat?) wird die Einrichtungsgebühr teurer?

    Die müssen auf die Master pfSense gerouted werden.

    Genau. Aber es ist eben eine zusätzliche Aktion erforderlich, um die auf einen anderen Server zu bekommen. Und genau das würde ich gerne loswerden, um dafür auf etablierte Methoden zu wechseln.

    Ich hasse diese Sonderangebote :( Ist jetzt nicht so, dass die teuer wären. Aber wenn man langsam in den mehrstelligen Bereich an vServer kommt, ... da kommt dann schon was zusammen. Und verlockend sind die alle. Jedesmal.

    pfSense hat eine Funktion um die Konfiguration auf zwischen zwei Instanzen gleich zu halten. Ich habe das aber noch nicht mit netcup ausprobiert, wie man das nutzen könnte um die Failover IPs umzuschalten.

    Die Funktion an sich würde mit 2 pfSensen klappen. Was nicht klappt, ist die dann zwischen den pfSensen hin und her geschobene IP zu teilen. Das läuft auf Layer2 ab, sprich, solange pfSense1 lebt, antwortet sie auf ARP-Anfragen für diese IP, sobald das Ding tot ist, antwortet pfSense2. Also das, was bei H* geht, bei Netcup (noch?) nicht. Genau deswegen wünsche ich mir das Feature ja ;)

    Den SPoF hast Du in jedem Fall, wenn Du das machst. Dafür gerade gibt es ja die Failover-IPs/Prefices samt API.

    Wenn ich in der Lage wäre, eine IP in ein VLAN zu routen, wäre es ohne SPoF machbar (sofern die Anlieferung der VLANs ebenfalls redundant ausgelegt ist natürlich). Aber dann hängt es nicht mehr an meinen VMs.

    Was hindert Dich daran, Deinen einem Server zugewiesenen Prefix zu unterteilen, und das dann per Routingprotokoll im VLAN zu routen?

    Bei den v4-IPs ist es relativ witzlos, da man zu RS/VPS iaR nur je eine IP oder Zusatz-IP bekommt - und gerade kein Netz.

    Die Failover-IPs lassen sich per API schalten. https://www.netcup-wiki.de/wiki/Netcup_SCP_Webservice (changeIPRouting).

    Weil genau dieser Router erstmal ein Single-Point-of-Failure darstellt. Wie ich "irgendwie" öffentliche IPs in ein VLAN bekomme weiß ich. Mein Ziel wäre, nachher eine Layer2-HA-Lösung zu haben - so wie das z. B. Kubernetes mit MetalLB macht. Oder pfSense mit seinen VirtualIPs.

    Die Failover IPs leitest Du auf einen bestimmten Server über das SCP oder die API. Das hat nichts mit dem vLAN zu tun und funktioniert komplett getrennt davon. Die netcup vLAN haben auch laut Produktbeschreibung keinen WAN Zugang.

    Ja, ich weiß, letzteres ist aber genau was, was ich als Feature Request bitte, irgendwann mal zu implementieren ;) (Nach dem Vorbild von besagtem bekannten Hoster mit dem großen H).

    Ich habe bei netcup HA mit den Failover IPs im Einsatz. Du kannst ohne große Probleme keepalived oder ähnliches nutzen und die Failover IPs umschalten (Rootserver scheinen im Gegensatz zu VPS wesentlich weniger Umschaltvorgänge zu erzeugen).

    Wie genau? keepalived ruft dann die SCP-API auf?

    Quote

    Du kannst auch ne Firewall wie pfSense an die Netzwerkkarte hängen und dann Dein vLAN mit IPs versorgen, die da hin gerouted werden, entweder Failover oder ganz normale. Da bist Du nicht eingeschränkt, ganz im Gegenteil. Im Gegensatz zum anderen Hoster könntest Du dieses Gateway HA aufsetzen, während es dort immer den Single Point Of Failure gibt, auf den Du keinen Zugriff hast.

    Eben genau das ist der Punkt, den ich in Frage stelle. "eine Firewall wie pfSense" würde auf einem vServer laufen, richtig? Fällt dieser aus, wird die IP auch nicht länger irgendwo geroutet sondern ist offline. Ja, ich könnte 2 pfSensen betreiben und dann, wenn eine ausfällt, die IP (per SCP-API?) auf die jeweils gerade nicht ausgefallene VM biegen. Aber dann kann ich mir den pfSense-Zwischenschritt auch sparen und direkt per SCP-API auf den Zielserver biegen, oder?

    Ok, dann... liebes Netcup, Lieber [netcup] Felix , könntet ihr das vllt. als Feature Request irgendwo notieren? :) Das würde es ermöglichen, existierende HA-Lösungen (sowas wie z. B. Kubernetes) bei euch einzusetzen - das geht aktuell leider nicht wirklich gut.

    Moin,


    ein großer und bekannter Anbieter für Dedicated Server bietet, so wie Netcup, an, zusätzliche private VLANs für Server zu konfigurieren. Was dieser Anbieter außerdem anbietet ist, zusätzliche IPs/Subnetze in dieses VLAN zu routen, sodass man auch innerhalb des VLANs öffentliche IP-Adressen haben und dort z. B. ein Kubernetes-Cluster mit MetalLB betreiben kann.


    Soweit ich das richtig sehe, geht das bei Netcup nicht, sondern eine zusätzliche IP ist immer an einen Server gebunden, oder? Ich weiß über die Existenz dieser FailOver-IPs, aber auch die haben immer einen Server-Bezug, den man aber übers SCP umstellen kann. Oder sehe ich das gerade falsch? Bei dem nicht näher genannten Anbieter erfolgt die Zuweisung der IP ausschließlich über die Konfiguration des Betriebssystems (also der Netzwerkkarte einfach die IP geben). Meine (nicht-Failover) zusätzliche IP hier bei Netcup musste ich im SCP konfigurieren, aber wie sieht das bei Failover-IPs aus?


    Viele Grüße

    Matthias

    Der Support kann das CPU Flag kostenpflichtig freischalten. Das kostet pro Kern und war glaube ich immer für ein Jahr.

    Moin,


    wusste gar nicht das das geht. Hast du da ne Quelle/weitere Infos dazu, wie z. B. den genauen Preis?


    Viele Grüße
    Matthias

    Ich liebe diese Community! Sonntag Nachmittag ne Frage stellen und überwältigend viele und hilfreiche Antworten bekommen. Danke, jetzt funktioniert es!

    Moin,


    ich bin mir eigentlich fast sicher, dass das schon mal gefragt wurde, habe aber keinen passenden Thread gefunden - daher sorry, wenn ich da etwas übersehen habe.


    Ist es eigentlich möglich, sich direkt ins SCP einzuloggen? Aktuell gehe ich immer den Umweg über das allgemeine CCP und klicke dort auf SCP Auto Login. Was ist beim SCP mein Benutzername? Die "Passwort vergessen"-Funktion kann ich schon nicht nutzen, weil er für Kundennummer+Mail-Adresse keinen Datensatz findet.


    Viele Grüße
    Matthias

    [...] keinerlei Fehler weil ich mich ja problemlos verbinden kann, gerne kann ich ihn aber zusätzlich anhängen wenn nötig.

    Der Satz erschließt sich mir nicht. Stehen da nun wirklich keine Fehler drin oder gehst du davon aus, dass keine Fehler drin sind, weil du dich verbinden kannst? Das hat leider überhaupt nichts miteinander zu tun, von daher bitte mal die Logs hier reinposten (nachdem die Verbindung aufgebaut wurde und versucht wurde, was zu pingen). OpenVPN hat einen Control- und einen Data-Channel. Verbindungen aufbauen läuft über den Control-Channel, Glückwunsch, der scheint dann zu gehen. Den Data-Channel kann man ganz schnell über eine doofe Wahl der Komprimierung kaputtmachen, ohne, dass da viele aufschlussreiche Fehler gelogged werden. Oder das Routing ist kaputt. Oder es ist was ganz anderes. Jedenfalls: Logs würden massiv helfen den Fehler mehr zu erforschen als zu erraten. Gerne auch mit höherer Verbosität und unter Nutzung eines Paste-Services.

    Meine 50 Cent dazu: Was spricht gegen AXFR? Ich habe bisher bei allen Nameserver-Setups, die ich aufgebaut und/oder betrieben hab AXFR als Austauschprotokoll genutzt (in der Regel lief PowerDNS mit PostgreSQL im Hintergrund). Aber wenn es schon einen definierten Standard für Zonentransfers gibt, warum den Schuh anziehen und selbst was basteln? Weiß auswendig auch gerade nicht, wie z. B. PowerDNS auf eine Read-Only-Datenbank reagieren würde. Und selbst ein Zonentransfer mit etwa 20.000 Records ging bei mir in nullkommanix. Und selbst wenn es mal ein paar Sekunden dauert: Ganz ehrlich, jede TTL ist höher ;)