Beiträge von bjo

Und: Tritt es im Rettungssystem auch auf?

Zu den Servern die ihre Anbindung verlieren gab es hier ja auch schon einige Threads.

Zitat von TBT

OMG, Du lebst meinen Traum!

Ansich ist das schon sehr angenehm, vor allem weil man Speicherkisten quasi mal als NAS einbinden kann oder dergleichen. Zugleich möchte man aber auch zuhause nichts kritisches hosten, wenn im NUC nur eine SSD ist und man im Grunde alles wieder aus dem Backup ziehen müsste, wenn diese den Geist aufgibt.

Zitat von aRaphael

Eine defekte Festplatte z.B. fällt denen gar nicht auf.

Das muss man selbst überwachen und beim Ausfall einer Platte muss man sie selbst aus dem RAID nehmen und dem Support Bescheid geben. (Und nicht die falsche Platte angeben ) Der Austausch geht dann aber sehr fix. Ich hatte das (zum Glück) erst einmal und das war innerhalb von Minuten (am Wochenende!) erledigt.

Ich meinte bei der Cloud, nicht bei den Dedis. Dass man das bei den Dedis selbst überwachen muss, ist klar.

Zitat von ThomasChr

Fairerweise muss man sagen dass der normale Support auch bei *etzner zu ähnlichen Zeiten arbeitet wie bei netcup.

Das betrifft auch den Cloud Support.

Hast du ne Sperrung oder deine Cloudmaschine läuft nicht wartest du also auch auf normale Öffnungszeiten.

Das was ihr hier meint ist die Vor-Ort Besetzung im Rechenzentrum die bei Hardware-Problemen mit den dedicated Servern bereit steht!

Vermutlich fällt denen aber eher kaputte Hardware auf im Vergleich zu hier wo ein Hardwaredefekt zu IO-Last führt oder VMs ihre Konnekivität verlieren und "kein Fehler feststellbar ist", es zufälligerweise dann aber wieder funktioniert.

Da scheinen Mitbewerber transparenter zu sein und es gibt selbst bei einem 2min-Ausfall nachträglich eine Mail.

Ich bin jedenfalls wieder nach Falkenstein gezogen, auch aufgrund der Nähe zur Storagebox (als Nextcloud-Space) und da ich Akkoma und Matrix auch daheim als Single-User-Instanz auch auf dem NUC laufen lassen kann, 1 Gbit symmetrisch FTTH mit statischer IP machts möglich.

Zitat von [netcup] Lars S.

Hallo bjo,

danke für dein Feedback.

Ich habe es an das zuständige Team weitergegeben und darum gebeten, das zu prüfen. Das genannte Tool hdparm ist (neben anderen nützlichen Tools für Tests dieser Art, wie z.B. fio) bereits standardmäßig im Rettungssystem enthalten. Ich kann den Wunsch nach neueren und aktuellen Versionen, sowie der Möglichkeit, ohne Umwege Pakete zu installieren, aber natürlich gut nachvollziehen.

Wegen eines Durchsatzproblems wurde ich mal vom Support gebeten, iperf3 vom Rettungssystem auszuführen - das ist jedoch nicht im Rettungssystem vorhanden und ließ sich aus og. Gründen auch nicht nachinstallieren.

Zitat

Oder meinst dasselbe nur als Datei?

Ja. Das Enconding scheint sonst etwas kaputt.

Kannst du den Log mal als Anhang dranhängen?

Zitat von [netcup] Lars S.

• Ausgaben von I/O-Speedtests / anderen geeigneten Nachweisen des Problems, falls leicht erstellbar (z.B. wenn das Problem dauerhaft besteht), idealerweise im Rettungssystem erstellt.

Vielleicht wäre es dafür von Vorteil, wenn ihr das Rettungssystem mal aktualisiert. Momentan basiert es auf Debian oldoldoldoldstable, sodass man keinerlei Tools wie bspw. hdparm nachinstallieren kann.

resolvconf hat ja auch nichts mit systemd-resolve zu tun.

Zitat von andreas.

Auch aus meiner Sicht wird ein Umzug mittlerweile nicht wirklich helfen. Denn schaut man sich folgendes Ergebnis genauer an, so rieht es eher danach aus, als werden mittlerweile aus Kostengründen die virtuellen Platten der virtuellen Server, egal ob VPS oder RS, auf sogenannte "Block Storage Volumes" ausgelagert. Mehr siehe folgendes Meßergebnis, welches ich auf einen RS 4000 G9.5 erstellt habe:

Meinst du damit, der Storage läuft auf irgendwelchen SAN mit entsprechenden Caching welches dann die Grätsche macht?

Zitat von andreas.

Auch aus meiner Sicht wird ein Umzug mittlerweile nicht wirklich helfen. Denn schaut man sich folgendes Ergebnis genauer an, so rieht es eher danach aus, als werden mittlerweile aus Kostengründen die virtuellen Platten der virtuellen Server, egal ob VPS oder RS, auf sogenannte "Block Storage Volumes" ausgelagert. Mehr siehe folgendes Meßergebnis, welches ich auf einen RS 4000 G9.5 erstellt habe:

Habe ich gerade auch mal ausgeführt:

 time fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=8G --readwrite=randrw
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.35
Starting 1 process
test: Laying out IO file (1 file / 8192MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=7819KiB/s,w=7875KiB/s][r=1954,w=1968 IOPS][eta 00m:00s] 
test: (groupid=0, jobs=1): err= 0: pid=2910712: Thu Oct 19 20:53:19 2023
  read: IOPS=8703, BW=34.0MiB/s (35.7MB/s)(4098MiB/120546msec)
   bw (  KiB/s): min=  880, max=112432, per=100.00%, avg=34907.31, stdev=13562.80, samples=240
   iops        : min=  220, max=28108, avg=8726.83, stdev=3390.70, samples=240
  write: IOPS=8693, BW=34.0MiB/s (35.6MB/s)(4094MiB/120546msec); 0 zone resets
   bw (  KiB/s): min=  824, max=109568, per=100.00%, avg=34866.91, stdev=13447.36, samples=240
   iops        : min=  206, max=27392, avg=8716.73, stdev=3361.84, samples=240
  cpu          : usr=4.63%, sys=22.98%, ctx=1069407, majf=2, minf=10
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%, >=64=0.0%
     issued rwts: total=1049199,1047953,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=34.0MiB/s (35.7MB/s), 34.0MiB/s-34.0MiB/s (35.7MB/s-35.7MB/s), io=4098MiB (4298MB), run=120546-120546msec
  WRITE: bw=34.0MiB/s (35.6MB/s), 34.0MiB/s-34.0MiB/s (35.6MB/s-35.6MB/s), io=4094MiB (4292MB), run=120546-120546msec

Disk stats (read/write):
  sda: ios=1050099/1050854, merge=0/44, ticks=6735232/905732, in_queue=7641603, util=99.39%
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test    7.14s user 35.24s system 31% cpu 2:12.46 total

Hatte ich mit einem RS 1000 G9.5 auch, war dann zwischendurch mal woanders, der neue RS 1000 G9.5. OST2023 hat das Problem zum Glück bisher nich.

Es existiert "do-release-upgrade".

Zitat von frank_m

Das kann ich kaum glauben. Netcup nutzt als Default IP immer das zugewiesene Prefix mit der EUI-64 Host-ID des Netzwerk-Interfaces. Im SCP steht ja auch nicht - wie du oben schreibst - die Adresse, sondern nur das Prefix. Die Adressen, die dort auftauchen, hast du selber mal für RDNS eingetragen, damit hat netcup nichts zu tun.

Ja, sollte, wenn alles richtig läuft. Im Moment sind wir ja noch dabei, einzugrenzen, was eigentlich schiefgeht. Und netcup nutzt die ursprüngliche Server-Adresse mit EUI-64 Host-ID ja für einige Dienste, z.B. als Routing-Ziel für zusätzliche Subnetze. Vielleicht geht was im NDP schief oder so, wer weiß?

Der Gateway fe80::1 hat aber ja nix mit den gerouteten Netzen zu tun und würde von der LinkLocal aus gepingt. Und wie sich nun gezeigt hat, hatte es nichts mit seiner Config zu tun.

Zitat von frank_m

Halte ich für völlig ausgeschlossen, denn die Host-ID ist nicht identisch mit der link-lokalen Adresse, sondern endet mit :1. Das ist praktisch ausgeschlossen bei einer EUI-64 Adresse.

Was sagt denn tcpdump?

Letztlich ist das doch vollkommen irrelevant, ob die Host-ID nun in der globalen IPv6 ist oder die ::1 - sofern es im selben /64 ist, sollte es gehen. Kann @mkdr denn fe80::1 pingen?

Der funktioniert doch eh nur zur Hälfte, da er auf Debian oldoldoldoldstable basiert?

Habt ihr nicht Lust, mal anexia.social aufzusetzen, damit auch nicht-X-Nutzer:innen aka Fediverse-Nuter:innen Informationen erhalten können?

Zitat von Ecki

Hallo,

die Version 26 mag zwar aktuell sein, die Stable ist aber noch bei 25.0.5

Da die Installation hier im Webhosting ja immer etwas speziell ist, würde ich dir zu der Stable raten.

Da ist man dann sicherer das es am Hosting liegt und nicht an Nextcloud

Wie kommst du darauf, dass 26 keine Stable ist?

Hatte das Problem mit T-Online neulich auch mal, habe dann extra mit Hugo eine Seite mit Impressum gebaut, Freischaltung erfolgt, Seite wieder entfernt. Aber besonders schön ist, dass deren Hosting-Büchse tld.t-online.de Spam rausschickt, deren Backscatter ich dann abbekam. Aber selbst auf deren Postmaster-Seite meckern, wenn Backscatter produziert wird. Warum können deren Hosting-Kunden überhaupt SMTP sprechen und sind nicht verpflichtet, den Relay-Server ihres Providers zu benutzen?

Deswegen auch die Postfix-Config um

client_checks:80.150.6.143 REJECT Ask postmaster@t-online.de how to send spam from your webhosting!
client_checks:2003:2:2:15:80:150:6:143 REJECT Ask postmaster@t-online.de how to send spam from your webhosting!

erweitert.