Beiträge von andreas.

Zitat von sla

Echtes Blech ist leider keine Alternative

1. Habe ich kein Bock mich um Hardware zu kümmern

2. Gerade beim Anbieter aus Falkenstein schaut man bei einem Ausfall in die Röhre, da auf allen Boards (außer Dell/iDRAC) IPMI deaktiviert und blockiert wird.

Dann doch lieber eine VNC Konsole um reinzuschauen, ohne ewig auf eine Lantronix warten zu müssen (Die meiner Erfahrung nach erst nach den zweiten Anschließen richtig funktioniert).

Alles anzeigen

Zu Anfang habe ich auch so gedacht.

Aber so schlimm ist es gar nicht. Denn ich habe mir seit ca. Mitte 2022 in Frankfurt einen Dedicated Server mit IPMI angemietet, bei dem mir in der Zeit von 2022 bis 2024 Anfang des Jahres 2024 nur eine der vier SAS-SSD´s ausgefallen war. Und Diese wurde mir nach dem Erstellen des Tickets sogar auch an einem Sontag innerhalb von 15 Min. im laufenden Betrieb durch eine nagelneue SAS-SSD ausgetauscht.

Zitat von sla

Sicherlich kann man alles over-engineeren oder Workarounds bauen. Auf Frickelbude hab ich persönlich keinen Bock.

Deswegen hier die "Beschwerde", möglicherweise landet das ja bei netcup in der richtigen Abteilung.

Wäre dann nicht der Dedicated Server AX162-S aus Falkenstein nicht eine echte Alternative für dich? Denn laut deren Beschreibung ist Zitat: "Alle Root-Server haben standardmäßig einen dedizierten 1 GBit-Uplink und damit unlimited Traffic."

Noch deutlicher wird es erst für Gewerbetreibende. Denn wenn man sich mal beide folgende Kostenaufstellungen genauer anschaut, so wird man feststellen, dass der Server aus Falkenstein nur ca. 100 Euro mehr kostet. Und für 100 Euro inkl. MwSt. kann man kein weiteren Mitarbeiter für einen ganzen Monat ohne Pausen einstellen.

Server RS 16000 G11 NUE

Serverkosten inkl. 19% MwSt. = 129,60 Euro

Server Standort inkl. 19% MwSt.: = 19,44 Euro

Preis pro Monat inkl. 19% MwSt.: 149,04 Euro

Server (echtes Blech) in Falkenstein, Typ AX162-S

Preis pro Monat inkl. 19% MwSt.: 248,71 Euro

Zitat von sla

Das ist mein einziger G11, schon komisch sich bei einem neuen Gedanken über Traffic machen zu müssen. Musste ich bisher nie. Soll netcup halt eine "Traffic öffnen"-Option anbieten, von mir aus für nen 10er im Monat für echtes unlimited (Monitored, netcup hat sicherlich kein Bock auf Torrent Seeds oder sowas). Aber das aktuelle Modell ist Quack 🦆

Das Traffic-Problem könnte man auch elegant aushebeln, indem man noch vor der Generation G11 einen kleinen RS 1000 der Generation G9.5 ansetzt und intern dann die Generationen G9.5 und G11 über vLAN 2.5 verbindet. Denn laut der technischen Angaben des vLAN´s ist das Traffic-Volumen für die Zusatzoption vLAN unbegrenzt.

Weiterhin ist laut den technischen Daten NAT ins WAN nicht möglich. Aber wer z.B. mit IP-Tables umgehen kann, kann auch das aushebeln.

Ich habe da mal ein IOPS-Test für einen RS 8000 G11 und einen RS 8000 G9.5 durchgeführt.

Schaut man sich folgende Werte an, so nehmen sich die beiden Generationen in Bezug der IOPS nichts.

Schaut man sich aber das Ergebnis des RS 8000 G9.5 genauer an, so ist das Ergebnis für die IOPS bezogen auf die Schwankungsbreite sehr unruhig und von daher gegenüber der neueren Generation extrem schlecht. Mehr siehe folgende Meßergebnisse:

RS 8000 G11

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.19
Starting 1 process
test: Laying out IO file (1 file / 8192MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=34.3MiB/s,w=34.5MiB/s][r=8784,w=8841 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=2499: Fri Mar  8 21:49:30 2024
read: IOPS=8311, BW=32.5MiB/s (34.0MB/s)(4098MiB/126240msec)
bw (  KiB/s): min=26698, max=36248, per=100.00%, avg=33280.85, stdev=1988.63, samples=251
iops        : min= 6674, max= 9062, avg=8320.09, stdev=497.14, samples=251
write: IOPS=8301, BW=32.4MiB/s (34.0MB/s)(4094MiB/126240msec); 0 zone resets
bw (  KiB/s): min=26267, max=37112, per=100.00%, avg=33240.71, stdev=2153.39, samples=251
iops        : min= 6566, max= 9278, avg=8310.07, stdev=538.37, samples=251
cpu          : usr=3.70%, sys=11.31%, ctx=1396554, majf=0, minf=8
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=32.5MiB/s (34.0MB/s), 32.5MiB/s-32.5MiB/s (34.0MB/s-34.0MB/s), io=4098MiB (4298MB), run=126240-126240msec
WRITE: bw=32.4MiB/s (34.0MB/s), 32.4MiB/s-32.4MiB/s (34.0MB/s-34.0MB/s), io=4094MiB (4292MB), run=126240-126240msec

Disk stats (read/write):
vda: ios=1048769/1047428, merge=0/0, ticks=4081577/3972517, in_queue=8054095, util=100.00%

real    2m31,726s
user    0m6,421s
sys     0m30,422s

Schwankungsbreite der IOPS (read): min=6674, max=9062, avg=8320.09, stdev=497.14, samples=251
Schwankungsbreite der IOPS (write): min=6566, max=9278, avg=8310.07, stdev=538.37, samples=251

RS 8000 G9.5

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.19
Starting 1 process
test: Laying out IO file (1 file / 8192MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=21.8MiB/s,w=22.3MiB/s][r=5575,w=5701 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=14385: Fri Mar  8 21:54:21 2024
read: IOPS=8356, BW=32.6MiB/s (34.2MB/s)(4098MiB/125556msec)
bw (  KiB/s): min=   32, max=95297, per=100.00%, avg=34890.72, stdev=28408.01, samples=239
iops        : min=    8, max=23824, avg=8722.54, stdev=7101.99, samples=239
write: IOPS=8346, BW=32.6MiB/s (34.2MB/s)(4094MiB/125556msec); 0 zone resets
bw (  KiB/s): min=   40, max=97940, per=100.00%, avg=34847.66, stdev=28356.16, samples=239
iops        : min=   10, max=24485, avg=8711.77, stdev=7089.01, samples=239
cpu          : usr=2.39%, sys=12.20%, ctx=682393, majf=1, minf=7
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=32.6MiB/s (34.2MB/s), 32.6MiB/s-32.6MiB/s (34.2MB/s-34.2MB/s), io=4098MiB (4298MB), run=125556-125556msec
WRITE: bw=32.6MiB/s (34.2MB/s), 32.6MiB/s-32.6MiB/s (34.2MB/s-34.2MB/s), io=4094MiB (4292MB), run=125556-125556msec

Disk stats (read/write):
vda: ios=1048707/1047193, merge=0/0, ticks=4038994/4072494, in_queue=8165280, util=99.67%

real    2m39,126s
user    0m5,290s
sys     0m41,094s

Schwankungsbreite der IOPS (read): min=8, max=23824, avg=8722.54, stdev=7101.99, samples=239
Schwankungsbreite der IOPS (write): min=10, max=24485, avg=8711.77, stdev=7089.01, samples=239

Vergleicht man die IOPS-Werte der Generation G11 mit einem Dedicated Server vom Mitbewerber, so sieht man daran auch gut, dass derzeit die Generation G11 wirklich gut sind.

Dedicated Server mit NVMe SSD´s, Software-RAID 1

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.19
Starting 1 process
test: Laying out IO file (1 file / 8192MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=31.9MiB/s,w=32.3MiB/s][r=8155,w=8268 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=6219: Fri Mar  8 22:02:07 2024
read: IOPS=7106, BW=27.8MiB/s (29.1MB/s)(4098MiB/147630msec)
bw (  KiB/s): min=15360, max=32904, per=100.00%, avg=28461.64, stdev=3168.60, samples=294
iops        : min= 3840, max= 8226, avg=7115.37, stdev=792.17, samples=294
write: IOPS=7098, BW=27.7MiB/s (29.1MB/s)(4094MiB/147630msec); 0 zone resets
bw (  KiB/s): min=15312, max=33512, per=100.00%, avg=28426.83, stdev=3273.65, samples=294
iops        : min= 3828, max= 8378, avg=7106.67, stdev=818.43, samples=294
cpu          : usr=5.59%, sys=10.16%, ctx=1020045, majf=1, minf=7
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=27.8MiB/s (29.1MB/s), 27.8MiB/s-27.8MiB/s (29.1MB/s-29.1MB/s), io=4098MiB (4298MB), run=147630-147630msec
WRITE: bw=27.7MiB/s (29.1MB/s), 27.7MiB/s-27.7MiB/s (29.1MB/s-29.1MB/s), io=4094MiB (4292MB), run=147630-147630msec

Disk stats (read/write):
vda: ios=1049681/1047681, merge=0/0, ticks=4774103/4644927, in_queue=9427663, util=100.00%

real    2m56.692s
user    0m10.146s
sys     0m33.332s

Schwankungsbreite der IOPS (read): min=3840, max=8226, avg=7115.37, stdev=792.17, samples=294
Schwankungsbreite der IOPS (write): min=3828, max=8378, avg=7106.67, stdev=818.43, samples=294

Zitat von frank_m

Oh ja, sorry, das hatte ich übersehen.

Nein, da hat du nichts übersehen. Denn ich habe es erst nachträglich ergänzt.

Zitat von frank_m

Wie genau? Wahrscheinlich nicht durch einfaches Einspielen eines Images? Das war eher ein file-basierter Ansatz, oder?

Sihe mein Beitrag #3.

Zitat von KB19

Reden wir hier wirklich vom gleichen Produkt?

Ja wir meinen, wenn die URL unter dem Beitrag #4 richtig ist, das gleiche Produkt, welches nicht die neuere Generation per KVM ist.

Zitat von KB19

Die JiffyBox verwendet nicht KVM sondern Xen. Wenn ich das richtig im Kopf habe, war bei den dortigen Images standardmäßig nicht einmal ein Kernel oder Bootloader enthalten, weil das bei der verwendeten Virtualisierung nicht notwendig war. Einen eigen Kernel konnte man auf Anfrage zwar nutzen, aber das war dann trotzdem eher eine Frickellösung. Weiters sind die "Festplatten" dort eigenständige Devices und haben gar keine Partitionen.

Bei den sogenannten JiffyBoxen basierend auf Xen des Mitbewerbers war es möglich, sich noch vor dem Installationsprozess zwischen einer Container- und einer Voll-Virtualisierungs-Installation zu entscheiden. Denn hatte man seinen Voll-Virtualisierten vServer mit einem Betriebssystem seiner Wahl als Voll-Virtualisierungs-Installation installiert, so verhielt sich der Voll-Virtualisierte vServer wie auch hier die vServer von Netcup.

Vor einem Jahr habe ich für einen Bekannten einen Xen-Container und einen Xen-Voll-Virtualisierten vServer hier zu Netcup erfolgreich umgezogen.

Wie bin ich bei beiden Varianten dabei vorgegangen?

1. Den bisherigen vServer habe ich im Rettungssystem gestartet.
2. Sofern die virtuelle Platte vom Rettungssystem nicht gemountet war, sie noch gemountet.
3. Vom / ab den kompletten Inhalt der virtuellen Platte per TAR in einer TAR-Datei gepackt.
4. Auf dem Zielserver das gleiche OS mit gleicher Versionsnummer installiert.
5. Ein Snapshot vom Zielserver erstellt.
6. Das Rettungssystem des Zielservers gestartet und darin die virtuelle Platte gemountet.
7. Die TAR-Datei ab / auf der gemounteten virtuellen Platte ausgepackt.
8. Danach IP-Adresse bzw. IP-Adressen und MAC-Adresse bzw. MAC-Adressen des Zielserver angepaßt.
9. Den Zielserver in beiden Varianten erfolgreich neu gestartet.
10. Und danach glücklich sein.

Zitat von Borgqueen

Ich vermute die neue Version war noch nicht für alle Apps kompatipel und darum crashte es.

Eventuell ist es ratsamer, nicht immer gleich auf die neueste Version zu aktualisieren.

Ich selber habe erst vor einigen Tagen meine Test-Nextcloud auf die Version 26.0.10 angehoben und die Produktive auf die Version 26.0.4.

Wurde denn Nextcloud unter einem Webhosting-Paket oder auf einem vServer x86 oder ARM installiert?

Zitat von aRaphael

Nicht viel

Einmal das von dir schon genannte:

also RS=dedizierter Thread und VPS nicht. (Bei beiden sind es Threads und keine echten Kerne)

dann noch:

* die Anbindung ( 2,5 Gbit/s vs 1 Gbit/s )

* und "nichttechnisch" die Zufriedenheitsgarantie, die es bei den VPS nicht gibt.

Ansonsten gibt es wohl bei der Implementierung der Virtualisierung kein großen Unterschied.

Alles anzeigen

… und alle eigenen RS sind im Gegensatz zu den VPS aufgrund der höheren Verfügbarkeit auf verschiedene Host verteilt.

Ich benutze keine extremst ausgefeilten Monitoring-Tools, sondern eher den Dienstleister serverguard24.de, der für mich alles nötige zum Monitoren meiner Server zur Verfügung stellt.

So werden bei diesen Dienstleister auch von mehreren Meßpunkten, die weltweit verteilt sind, die Zielserver und auch bei Bedarf dessen Dienste darauf auf Erreichbarkeit geprüft.

Innerhalb meiner Server prüfe ich dann nur noch mit dem Paket sysstat und dem Befehl sar das IO und die CPU-Teilung der einzelnen vCores, die man ja sich auch beim Typ RS mit anderen Kunden teilt.

Wenn du lieber einen eigenen Monitoring-Server vorziehst, dann schau dir auch mal CheckMK genauer an. Denn das ist nicht nur sehr modern, sondern auch sehr mächtig und flexibel. Und erst recht im Zusammenspiel mit Grafana zur Visualisierung der einzelnen Ergebnisse.

Zitat von nan0

Sagt mal ich brauche (aus Gründen) eine Anbieter-Redundanz und bin daher gerade am suchen was es da so gibt.

Hat hier wer Erfahrung mit C0ntab0 Servern?

Damit man dir besser helfen kann, solltest du eventuell mal genauer beschreiben, was du vorhast. Denn Anbieter-Redundanz ist sehr dehnbar und nicht jeder Anbieter kommt für den gleichen Zweck - bezogen auf deren Produkte und dessen Stärken - in Frage.

Zitat von aRaphael

Ein Dedi bei H. wird ausgemustert und soll auf 2-3 Virtualisierte verteilt werden.

Und ich kann mich nicht zwischen den netcup ARM und den ARM-Cloudservern bei H. entscheiden...

An deiner Stelle würde ich noch warten, bis es auch die ARM-Server vom Typ RS gibt. Denn diese werden ja aufgrund der höheren Verfügbarkeit auf verschiedene Hostsysteme verteilt.

Zitat von fvbor

Ist bekannt ob das noch kommen soll?

Also PostgreSQL für Webhosting

Unter Plesk ist die Installation der Datenbank PostgreSQL nur ein Knopfdruck entfernt und in Sekunden erledigt.

Abb1.png

Zitat von frank_m

Gilt das auch für langsamere VLANs? Also würden sich 2x 1 GBit/s dann auch die 1 GBit/s teilen, oder kämen mehrere VLANs in Summe an die maximale Anschlussgeschwindigkeit des Servers heran?

Ich hatte es nur mit 2 x 2,5 Gbit/s vLAN´s mal getestet.

Denn 2 x ein vLAN mit einer maximalen Bandbreite von 1 Gbit/s zu bestellen und Diese danach zu bündeln, damit sie dann nachher an den RS´s nur eine maximale Bandbreite von 2 anstelle von 2,5 Gbit/s erreichen, kam für mich damals nicht in Frage.

Zitat von tab

Welcher Mai-Server gibt diese Antwort, die mir bisher in der Form noch nie begegnet ist?

Wenn du diese Fehlermeldung als Mail erhältst, müßtest du mehr auch über den Header der Mail erfahren können. Denn im Header kann man sehr schön den Verlauf einsehen.

Zitat von christianr

Schade, dass ältere VPS dann keine vNICs mit 2.5Gbit bekommen können. Die Server werden vermutlich auf Hosts liegen die nicht für diese Bandbreiten ausgelegt sind, dennoch schade.

Aber du kannst solche alten vServer-Generationen dennoch über das vLAN 2,5 Gbit/s mit neueren Generationen verbinden. Sie erreichen dann aber leider nur nicht die über das vLAN 2,5 Gbit/s zu erreichende Bandbreite.

Zitat von christianr

Bist du dir aber hierbei wirklich sicher?

Ich selber habe so ein Setup und habe es vor gut zwei Jahren auch schon mal getestet.

Was nicht geht, so meine damaligen Tests, ist zwei vLAN´s mit 2,5 Gbit/s zu bestellen und dann parallel zu nutzen, um damit dann die Bandbreite zu verdoppeln. Denn da teilen sich die beiden vLAN´s tatsächlich die maximale Bandbreite von nur einem vLAN.

Zitat von christianr

Deshalb denke ich, dass die Bandbreite letzlich geteilt wird und für mich das vLAN dementsprechend nur dann Sinn machen würde, wenn ich mit meinen Limits, also z.b. 120TB, nicht zurecht kommen würde. Andernfalls kann ich ja einfach ein eigenes 'vLAN' mittels VPN etc. erstellen und meine inkludierte Bandbreite verwenden.

Wenn über zwei RS´s, >= G9 über die WAN- und über die LAN (vLAN)-Schnittstelle gleichzeitig 2,5 Gbit/s übertragen werden, können bis zu 5 Gbit/s übertragen werden.

Die beiden Schnittstellen, WAN und LAN (vLAN), behindern sich also gegenseitig nicht.

Zitat von christianr

Ist eigentlich bei den vLANs die Bandbreite seperat oder wird einfach von der Server Anbindung genommen?

Sprich wenn der RS mit 2.5Gbit nach extern angebunden ist, hat dann das vLAN seine eigene Bandbreite oder nutzt es die 2.5Gbit des Servers selbst?

Das jeweilige vLAN nutzt die zugewiesene Schnittstellengeschwindigkeit voll aus und wird durch die Schnittstelle des WAN´s nicht ausgebremst.