Rancher und Longhorn auf netcup Servern aufbauen. Erfahrungen?

  • Liebe netcup-Community,


    wir haben rancher 2.x (https://rancher.com/) mit drei netcup Servern welches auf Kubernetes basiert am laufen.
    Als distributed Block Storage Lösung verwenden wir longhorn (https://longhorn.io).

    Aktuell haben bei den volumes von longhorn immer wieder das Thema, dass sie degraded werden und dann sich das eine replica immer wieder neu aufbauen muss.
    Zusätzlich werden volumes teilweise ohne Grund einfach read-only welches die nutzende Applikation natürlich crashen läst. Probleme dieser Art haben wir täglich.

    Laut der longhorn community könnte das an CPU oder Bandbreite liegen bzw. ein Hardware Problem sein. Jedesmal wenn zum Beispiel die connection verloren geht wird ein snapshot gebaut und das Volume könnte degraded werden.

    Hat da jemand Erfahrungen mit netcup Servern?
    Hat jemand so ein Setup funktionierend ohne Probleme laufen und möchte sich diesbezüglich mit mir austauschen?
    Gibt es da Infos von offizieller netcup Seite? Vielleicht macht netcup irgendwas mit dem Netzwerk oder CPU Scheduling?


    Hier noch die Infos zu den drei verwendeten nodes:


    Würde mich freuen herrauszufinden ob ich da für netcup Server eine Lösung finde.

    thx und lg
    Darian

  • Hi Darian,


    sind es VPS oder RS die ihr verwendet? Könnte es sein, dass euch CPU vom Nachbarn 'geklaut' wird?


    Über welches Protokoll kommunizueren die Nodes (IPv4/6)? Es sind Probleme mit dem inkludierten IPv6 Subnetz von Netcup bekannt, das könnte zumindest random Verbindungsabbrüche erklären.


    Grüße

  • Hi gschwepp,

    danke für deinen Input. Es verspricht spannend zu werden.
    Dass es was CPU mässiges sein könnte, hatte ich auch schon im Sinn.

    Aktuell verwende ich folgende 3 Server:

    RS 4000 SAS G8 xRAM

    RS 4000 SAS G8SE a1 12M

    VPS 3000 G9 12M

    Das bedeutet also, dass ein Server da Probleme machen könnte beim CPU? Oder wie könnte das sein? Hab da leider zu wenig Erfahrung.

    Bezüglich ipv4 oder ipv6 muss ich mir das noch anschauen, ich schätze aber schon dass ipv4 verwendet wird.
    Ich sag dir da noch bescheid.

    Im rancher selbst bekommt ich auch öfter mal wieder die message: "max_user_connections". Ich verwende dafür eine db von meinem normalen netcup Hosting.
    Ich hab kein GUI gefunden um die max_user_connection für die db anzupassen.

    thx und lg
    Darian

  • Hi,

    die RS haben im Gegensatz zu den VPS "dezidierte" Kerne für deine Server. Die stehen dir garantiert zur Verfügung und sollten eig. nicht für andere nutzbar sein.


    Wenn es möglich ist könntest du versuchen den VPS aus dem Cluster zu nehmen und schauen was passiert. Ich habe keine Erfahrung mit rancher oder longhorn, aber es klingt für mich mehr nach einem Verbindungsproblem als nach einem CPU Problem.


    Beste Grüße

  • Ich kenne mich mit der o.g. Software nicht aus, aber manchmal helfen auch Gedankengänge von "Unwissenden".


    Kann es sein das "nur" der VPS Probleme macht und die anderen beiden Nodes dann in Fehler laufen, da eine Node crashed.

    Evtl ist deine Software so CPU lastig dass du dir die ganze CPU Leistung vom Wirt "stealst" und Netcup dich nach X Minuten drosselt oder deine Anwendung terminiert?

    Ich selbst besitze keinen VPS aber lässt sich da irgendwie der CPU steal herausfinden?

  • Hi und danke für eure Infos.
    Ich denke damit kann ich schon was anfangen oder zumindest bringt es mich in eine Richtung die ich verfolgen kann.

    Verbindungsproblem: Ich bin gerade am Abklären ob da ipv4 oder ipv6 benutzt wird.
    CPU Problem: Ich kann heute am Abend mal einen Longhorn node (den VPS Server) entfernen und hoffen.

    Wie sonst könnte ich Verbindungsprobleme erkennen gibt es dafür Tools?
    Wie findet man bei netcup heraus ob ein CPU steal passiert? Ich denke ich werde die Statistiken vom SCP mal besser im Auge behalten.

    thx und lg
    Darian

  • Wie findet man bei netcup heraus ob ein CPU steal passiert? Ich denke ich werde die Statistiken vom SCP mal besser im Auge behalten.

    Wie an anderer Stelle ausgeführt: Besser als die SCP-Statistiken im Auge zu behalten, ist es, mit eigenen Programmen direkt im VServer zu messen.

    Das Dienstprogramm top zeigt das in der dritten Zeile (letzter Wert) live an:

    Code
    1. top - 12:48:06 up 45 days, 4:25, 38 users, load average: 1,35, 1,60, 2,37
    2. Tasks: 793 total, 2 running, 685 sleeping, 1 stopped, 1 zombie
    3. %Cpu(s): 16,5 us, 6,5 sy, 0,0 ni, 75,8 id, 0,1 wa, 0,0 hi, 1,1 si, 0,0 st

    Für eine Überwachung empfiehlt sich natürlich die Installation von munin o. ä. – Beispielausgabe zur Prozessorauslastung findet sich hier.

  • Im rancher selbst bekommt ich auch öfter mal wieder die message: "max_user_connections". Ich verwende dafür eine db von meinem normalen netcup Hosting.


    Ich habe selber Ranger nicht im Einsatz, kann also nur einen weiteren Denkanstoß geben:


    Die DBs aus den normalen Webhosting-Tarifen sollen oftmals nicht die schnellsten sein - zumindest wurde hier schon ein paar Mal davon berichtet. Könnte also die verwendete DB für einen Engpass sorgen? Gab schon Webhosting-Kunden die nur die DB ausgelagert haben auf einen kleinen VPS und dadurch einen guten Performanceschub erhielten.
    Inwieweit das dein Setup beeinflusst, keine Ahnung. :)

  • Hauptproblem bei Netcup war bei mir immer der I/O-Delay der Festplatte. Prüfe hier im Detail mit z.B iostat -x /dev/xyz ob die Platte nicht überlastet ist.

  • Hi, ich habe wieder folgendes heraus gefunden.

    Longhorn läuft mit ipv4. Das bedeutet also die bekannten connection lost mit ipv6 dürften nicht passieren.

    Ich habe top verwendet um die "steal time" genauer zu beobachten. Gerade ist es so, dass der Wert bei allen drei Hosts eher zwischen 0,1 und 1,5 liegt.
    Manchmal hatte ich einen Peak von 10,0 was aber eher die Ausnahme war. Sollte st bei einem RS mit dedizierten CPU nicht immer bei 0,0 sein?

    Bei iostat befande sich der tps auch bei allen drein nodes zwischen 40 und 120 . Ich denke das müsste auch passen.

    Oder sind die Werte nicht passend?
    Ich werde jetzt das Verhalten des Server noch beobachten und ggf. das erwähnte munin installieren.

    Aktuell scheine ich der einzige Rancher/Longhorn Nutzer mit netcup zu sein. :-) Würde mich interessieren was da andere Sagen.

    Auf jedenfall danke für die Infos bis jetzt, die haben mir schon sehr geholfen.

  • Die Steal-Werte sind in Ordnung. Falls der Peak von 10.0 bei einem RS ist, dann allerdings nicht. Sollte maximal 3.0 sein bei einem RS, das OS des Wirtssystems braucht halt auch ein wenig CPU. Bei einem VPS kann der Steal auch mal 50 erreichen.


    Edit: Die Rinderzucht überlasse ich anderen. ;)

  • Ich benutze zumindest Longhorn. Bei mir passiert es auch unregelmäßig, dass einige Volumes degraded werden. Ein Muster konnte ich da noch nicht erkennen.


    Mein Cluster besteht aus 4x "RS 2000 SSDx4 G8" und 1x "BF17 VPS 2500".


    Wie passend: Gerade sind wieder 7 Volumes weggeknallt.8o


    Darian Konntest du noch etwas herausfinden?

  • DerFetzer Hi, okay, das ist schon einmal beruhigend, dass ich da nicht der einzige mit Problemen bin.

    Hast du da noch mehr Erfahrungen bzw. Infos?

    Ich habe ja aktuell noch einen alten rancher laufen. Da gibt es auch immer mehr Probleme die irgendwas mit Verbindungsproblemen zu tun haben.
    Da es beim Longhorn auch in die Richtung gehen könnte, glaube ich schon langsam nicht mehr an ein Softwareproblem. Eventuell macht netcup da irgendwas bei diesen Ports mit Firewall settings oder dergleichen. Keine Ahnung.


    Ich glaube deswegen schon langsam nicht mehr an ein Softwareproblem unserer Seits.

    Wir müssen leider nun langsam schon nach anderen Lösungen mit anderen Hostern suchen.

  • Hallo zusammen,

    welches OS verwendet ihr denn? Nutzt ihr nen VLAN für die Kommunikation zwischen den Nodes oder das Public Interface?


    Ich habe RKE (https://github.com/rancher/rke) im Einssatz (was ja bei Rancher zuerst deplyoed wird) mit Canal als CNI und Backend Host-GW ( https://coreos.com/flannel/docs/latest/backends.html ) Mit VxLAN, was der default ist, hatte ich in der Tat auch leichte Probleme.


    Als Storage nutze ich Ceph und das läuft saustabil.

    Gruß

  • Hallo,


    momentan benutze ich noch RancherOS mit einem selbstgebauten 5.6er Kernel und auch RKE.

    Dabei ist Canal mit dem Default, also VxLAN, konfiguriert.

    Dann über das Cloud-VLAN. Das ist natürlich doppelt gemoppelt, aber als ich das Cluster aufgesetzt habe, war ich noch nicht so schlau wie heute.;)

    Soweit ich weiß, kann man das Plugin bzw. Backend auch nicht mal so einfach ändern.


    michaeleifel Läuft das dann bei dir trotzdem über das Cloud-VLAN? Ich hatte auch mal überlegt, per Wireguard über die Public Interfaces zu kommunizieren, aber dann hat man auch wieder eine zusätzliche Fehlerquelle.

  • Ich nutze aktuell ein aktuelles Debian ohne dem Cloud vLAN.

    Denkt ihr das Cloud vLAN würde was bringen, aktuell ist es so, dass das Free Cloud vLAN bei 100 Mbit langsamer wäre wie die aktuellen 1GBit die wir sowieso schon haben. Deswegen zögere ich da noch das auszuprobieren.

    Meint ihr Cloud vLAN wäre trotzdem sinnvoll? Wenn es wirklich was bringt kann man sich ja noch immer ein schnelleres (bis 2,5 Gbit) besorgen.

  • michaeleifel Läuft das dann bei dir trotzdem über das Cloud-VLAN? Ich hatte auch mal überlegt, per Wireguard über die Public Interfaces zu kommunizieren, aber dann hat man auch wieder eine zusätzliche Fehlerquelle.

    Hab mir extra dafür das (https://www.netcup.de/bestellen/produkt.php?produkt=2298 ) gegönnt da ich noch auf längere Zeit an G8 Server gebunden bin ( hatte kleine Fehlplanung und kurz vor G9 Launch fertig umgebaut...)


    Ich nutze auf allen Systemen ein selbst provisioniertes Debian per preseed bei allen Providern am laufen das danach durch Ansible ergänzt wird. Somit hab ich überall das gleiche System und kann Fehlerquellen schnell eingrenzen. RancherOS hatte ich mal testweise am laufen aber irgendwie komme ich dann doch immer wieder zu Debian zurück, zumal nach der Installation es nur 800 mb an Festplatte nutzt da es minimalistisch gehalten ist. Per Backprots paar aktuelle Pakete wie Kernel.


    Seit dem Wechsel auf Host Gw als Backend hab ich keine Probleme mehr. Wireguard hatte ich auch ne Zeit lang im Einsatz, das hatte allerdings bei nem anderen Provider Startup Zeiten von 30 Sekunden (liegt am eingesetzten Hypervisor des Provider Virt..zo) und deswegen habe ich micht einfachheitshalber für das Cloud VLAN entschieden. Kann mich nicht beschweren, keine wegknallenden Volumes, hier nen kleiner fio test:


    Ich nutze aktuell ein aktuelles Debian ohne dem Cloud vLAN.

    Denkt ihr das Cloud vLAN würde was bringen, aktuell ist es so, dass das Free Cloud vLAN bei 100 Mbit langsamer wäre wie die aktuellen 1GBit die wir sowieso schon haben. Deswegen zögere ich da noch das auszuprobieren.

    Meint ihr Cloud vLAN wäre trotzdem sinnvoll? Wenn es wirklich was bringt kann man sich ja noch immer ein schnelleres (bis 2,5 Gbit) besorgen.

    Ich würde nicht nur die Geschwindigkeit an der Stelle beachten sondern auch wie die Anbindungen sind bzgl Latenz, Routing etc.

    Bspw habe ich bei nem anderen Provider das Problem das wenn ich deren public interface nutze die Kommunikationswege zwischen den Nodes auch nur mit 99% SLA abgedeckt sind. Erst durch deren zusätzliches internes Netzwerk ist sichergestellt dass der kürzeste Weg zwischen den Nodes genommen wird was man auch massiv in der Latenz spürt. Eigentlich würde ich ja erwarten dass wenn das andere Ziel innerhalb vom RZ ist der Traffic nicht 1mal bis Frankfurt und zurück geht, allerdings kenne ich da einen Anbieter wo das tatsächlich der Fall ist, aber da sind auch DNS Resolv Zeiten von 2 Sekunden für die Hotline "normal".


    Zuerst habe ich auch mit dem Free ausprobiert, aber eher halt bezogen auf Latenzen, Stabilität etc. Über das VLAN läuft auch sämtliche Kommunikation meiner Nodes und nach außen auf dem Public sind es dann nur eine handvoll Ports die dort überhaupt "lauschen". Ausprobieren mit dem Free kann ja nicht schaden, nur halt nicht Wunder erwarten bei der Geschwindigkeit.


    Gruß

  • Wie hast du den Wechsel durchgeführt? Die RKE-Doku sagt, dass der Network Provider nicht verändert werden kann und in der Flannel-Doku steht auch, dass man das Backend nicht im Betrieb ändern soll.

    Hab das beim "rke up" gesetzt. Die Doku schreibt den Satz halt rein weil es halt zu einer Unterbrechung kommt wenn bspw von Calico -> Flannel gehst etc oder auch beim Backendtype. Sofern man sich aber etwas "auskennt", lässt sich das nachts in einer geplanten Aktion einfach durchziehen. In der RKE config sieht das bei mir wie folgt dann aus (eth1 ist das cloud vlan, hab net.ifnames=0 in der grub und deswegen die alten Interface Namen.):



    Code
    1. network:
    2. plugin: canal
    3. options:
    4. canal_iface: eth1
    5. canal_flannel_backend_type: host-gw

    Der relevante Eintrag stammt aus der Flannel Doku ( https://github.com/coreos/flan…Documentation/backends.md)


    Im laufenden Betrieb (falls keine andere Möglichkeit sich ergibt) würde ich erst alle Deployments auf 0 setzen so dass nur der Kubernetes Core läuft (api, coredns, nodelocaldns), warten bis Ceph / Longhorn alles synced hat und dann die Änderung vornehmen. Weave hat anscheinend aktuell nen kleinen Bug der sich durch das bearbeiten des Daemonsets beheben lässt: https://github.com/weaveworks/weave/issues/3816


    Gruß