Rancher und Longhorn auf netcup Servern aufbauen. Erfahrungen?

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,

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?

Quote from 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:

top - 12:48:06 up 45 days,  4:25, 38 users,  load average: 1,35, 1,60, 2,37
Tasks: 793 total,   2 running, 685 sleeping,   1 stopped,   1 zombie
%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.

Quote from Darian

Wie findet man bei netcup heraus ob ein CPU steal passiert?

Dies kannst du z.B. über den Befehl top (oder per iostat, vmstat etc.) in Erfahrung bringen. Nach Aufruf siehst du in der dritten Zeile (CPU) steht am Ende der steal (si) Wert in Prozent.

too late...

Quote from Darian

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.

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.

Darian Konntest du noch etwas herausfinden?

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.

Quote from DerFetzer

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:

root@seafile-6578f846fd-j9nqg:/data# fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --numjobs=1 --size=4g --iodepth=1 --runtime=60 --time_based --end_fsync=1
random-write: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=posixaio, iodepth=1
fio-3.12
Starting 1 process
random-write: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [w(1)][100.0%][eta 00m:00s]                          
random-write: (groupid=0, jobs=1): err= 0: pid=181846: Wed Oct 28 16:47:14 2020
  write: IOPS=9738, BW=38.0MiB/s (39.9MB/s)(4096MiB/107673msec); 0 zone resets
    slat (nsec): min=369, max=4548.8k, avg=5910.36, stdev=13077.23
    clat (nsec): min=177, max=232807k, avg=34796.15, stdev=254836.05
     lat (usec): min=9, max=232811, avg=40.71, stdev=255.43
    clat percentiles (usec):
     |  1.00th=[   10],  5.00th=[   14], 10.00th=[   15], 20.00th=[   17],
     | 30.00th=[   19], 40.00th=[   20], 50.00th=[   22], 60.00th=[   24],
     | 70.00th=[   27], 80.00th=[   32], 90.00th=[   44], 95.00th=[   70],
     | 99.00th=[  277], 99.50th=[  537], 99.90th=[ 1336], 99.95th=[ 1844],
     | 99.99th=[ 3949]
   bw (  KiB/s): min=58928, max=128464, per=100.00%, avg=95286.47, stdev=14999.21, samples=88
   iops        : min=14732, max=32116, avg=23821.57, stdev=3749.86, samples=88
  lat (nsec)   : 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
  lat (usec)   : 2=0.01%, 4=0.01%, 10=1.47%, 20=40.52%, 50=49.90%
  lat (usec)   : 100=5.13%, 250=1.84%, 500=0.55%, 750=0.25%, 1000=0.11%
  lat (msec)   : 2=0.14%, 4=0.03%, 10=0.01%, 20=0.01%, 50=0.01%
  lat (msec)   : 250=0.01%
  cpu          : usr=3.98%, sys=13.03%, ctx=1095405, majf=0, minf=59
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,1048577,0,1 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=38.0MiB/s (39.9MB/s), 38.0MiB/s-38.0MiB/s (39.9MB/s-39.9MB/s), io=4096MiB (4295MB), run=107673-107673msec

Disk stats (read/write):
  rbd1: ios=0/95706, merge=0/3241, ticks=0/4193217, in_queue=4193217, util=89.28%

Quote from Darian

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ß

Quote from michaeleifel

Seit dem Wechsel auf Host Gw als Backend hab ich keine Probleme mehr.

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.

Quote from DerFetzer

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.):

network:
  plugin: canal
  options:
    canal_iface: eth1
    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ß