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%
Alles anzeigen
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ß
,was auch kleine Lücken im Monitoring auslöst Da ich prinzipiell natürllich lieber die RZ internen Resolver nutzen wollte, stellte sich mir die Frage ob ich irgendwie "flush" ähnlich wie bei google, opendns etc. machen kann. Im Forum bin ich nur über ( 
