News In eigener Sache: Das neue Server-Setup von ComputerBase (2021)

[thanatur]

Für die Anzeige also solche, nicht Klicks darauf.

mach ich trotzdem, je nach Thema mal gerne
bei euch lass ich auch alles an Werbung bei uMatrix zu

 

[Jan]

Die Zugriffe werden am Ende auch berichtet und sind für den Kunden natürlich ein wichtiges Maß fur den Erfolg.

 

[Haldi]

Um nochmal kurz auf das Thema Screenshot Komprimierung zurück zu kommen...
Wir haben hier so ein schönes beispiel 7040x2520 Pixel 5.2MB gross. Gemacht mit Windows+Printscreen.

(Nachdem er Hoch geladen wurde noch 3840x1375 Pixel 1.89MB)
Link zu allen Versionen auf gDrive da 19Mb zu viel sind als Anhang auf CB ~.~

Datei:	Settings:	Grösse:
PNG Original	Win+Print	5.19MB
PNG Irfanview	compression lvl 6	3.99MB
PNG OptiPNG	level 4	3.91MB
PNG PNGquant	default	1.46MB
JPG Irfanview	Q75	0.89MB
JPG2000	Q75	1.19MB
WebP Irfanview	Q75 compression 4	0.45MB
AVIF avif.io	Effort 50 Q75	0.70MB
AVIF convertio.co	default	0.85MB
AVIF aconvert.com	default	0.66MB

Wirklich interessant wären hier natürlich noch die Konvertierungszeit! Da diese ja natürlich auch ressourcen frisst. AVIF is schon cool, aber wenn dadurch der CPU gewaltigt mehr ausgelastet wird....

 

[thanatur]

Die Zugriffe werden am Ende auch berichtet und sind für den Kunden natürlich ein wichtiges Maß fur den Erfolg.

Danke euch für eure Transparenz und Kompetenz (nicht nur auf dieses spezielle Thema bezogen)

macht weiter so!

 

[ComputerJunge]

Danke für den informativen Artikel und Glückwunsch zur geradezu geräuschlosen Migration (insbesondere, dass der Plan funktioniert hat ).

Ein Abonnent.

 

[SerErris]

Hi,

herzlichen Glückwunsch zum Umzug und vor allem daß es so reibungslos geklappt hat.

Ich kann von hier vermelden (Bad Homburg, Telekom, Glas) das die Ladegeschwindigkeit der Seite im Chrome deutlich besser ausfällt. Nicht das das bisher ein Riesenproblem war, aber ist eben schneller :-)

Insbesondere gilt das obige für das Forum. Das ist jetzt echt gut flott im Aufbau.

Liebe Grüße
Ser

 

[ebird]

haha, das musste ich auch mal testen mit unserem Warenwirtschafssystem:
Anhang anzeigen 1153180
in der tat ist die Latenz zu CB kürzer als in unserem eigenen Netzwerk. 😂

Ich finde solche Einblicke in die Technik einer Seite echt toll. Danke dafür. Gerne mehr davon.

Naja. Die Zeiten sind nicht gerade gut. Zeiten um die 20ms würde ich eher als mies bezeichnen.

[Edit]Das bedeutet jedoch nicht, dass die Performance trotzdem sehr gut ist[/Edit]

PING www.computerbase.de(www.computerbase.de (2a00:f48:2000:1::137)) 56 data bytes
64 bytes from www.computerbase.de (2a00:f48:2000:1::137): icmp_seq=1 ttl=54 time=20.7 ms
64 bytes from www.computerbase.de (2a00:f48:2000:1::137): icmp_seq=2 ttl=54 time=20.5 ms

PING [DSL 50 Anschluss] 56(84) bytes of data.
64 bytes from [DSL 50 Anschluss]: icmp_seq=1 ttl=54 time=19.3 ms
64 bytes from [DSL 50 Anschluss]: icmp_seq=2 ttl=54 time=19.2 ms

ping [eigener Server]
PING [eigener Server] 56 data bytes
64 bytes from [eigener Server]: icmp_seq=1 ttl=56 time=2.99 ms
64 bytes from [eigener Server]: icmp_seq=2 ttl=56 time=3.04 ms

ping www.google.de
PING www.google.de(fra16s46-in-x03.1e100.net (2a00:1450:4001:801::2003)) 56 data bytes
64 bytes from fra16s46-in-x03.1e100.net (2a00:1450:4001:801::2003): icmp_seq=1 ttl=116 time=4.04 ms
64 bytes from fra16s46-in-x03.1e100.net (2a00:1450:4001:801::2003): icmp_seq=2 ttl=116 time=3.50 ms

PING cloud.telekom-dienste.de(2a06:ac80:11:1::b97b:58d2 (2a06:ac80:11:1::b97b:58d2)) 56 data bytes
64 bytes from 2a06:ac80:11:1::b97b:58d2 (2a06:ac80:11:1::b97b:58d2): icmp_seq=1 ttl=54 time=4.24 ms
64 bytes from 2a06:ac80:11:1::b97b:58d2 (2a06:ac80:11:1::b97b:58d2): icmp_seq=2 ttl=54 time=4.27 ms

ping hosteurope.de
PING hosteurope.de(2001:1520:101:100:: (2001:1520:101:100:) 56 data bytes
64 bytes from 2001:1520:101:100:: (2001:1520:101:100:: icmp_seq=1 ttl=52 time=6.86 ms
64 bytes from 2001:1520:101:100:: (2001:1520:101:100:: icmp_seq=2 ttl=52 time=6.70 ms

PING www.heise.de(www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85)) 56 data bytes
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=1 ttl=54 time=4.65 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=2 ttl=54 time=4.41 ms

 

[foo_1337]

Ein traceroute würde eher helfen zu sehen, woran es liegt (routing/peering) als ein stumpfer ping

 

[ebird]

Ein traceroute würde eher helfen zu sehen, woran es liegt (routing/peering) als ein stumpfer ping

Kann ich nicht durchführen mit computerbase.de bzw. nur teilweise. Aber das war nur die Antwort auf den Screenshot, dass alles bei 20ms einfach schlecht ist. Liefert natürlich keinerlei Erkenntnisse - wobei ein traceroute ja auch nur Pings sind

Das Problem von CB sind eher die 400 Requests in den ersten 10Sekunden, wobei nur ca. 90 Content ausliefern und die übrigen Tracking, Tracking, Tracking und auch etwas Werbung. Diese werden natürlich nicht an Google geliefert, damit der Page Rank nahe der 100% liegt.

 

[Web-Schecki]

Kann ich nicht durchführen mit computerbase.de bzw. nur teilweise.

Kann trotzdem sein, dass die interessanten Router gerade antworten... 20ms sind auf jeden Fall merkwürdig, denn Google gibt dir scheinbar auch einen Server aus Frankfurt - den du in 4ms erreichst. Unwahrscheinlich, dass die bloße Distanz ein Problem ist.

Das Problem von CB sind eher die 400 Requests in den ersten 10Sekunden, wobei nur ca. 90 Content ausliefern und die übrigen Tracking, Tracking, Tracking und auch etwas Werbung.

Mit ComputerBase Pro sind so um die 20 Requests - DOM ist nach ca. 100ms fertig, der komplette Content in <1s. Kann ich nur empfehlen

 

[foo_1337]

Genau deshalb hatte ich gefragt, heise gibts auch nur in FRA bei Plusline… und nein, traceroute ist kein ping sondern udp Nur Windows benutzt by default ICMP, aber deinem output nach war das nicht windows. Daher probier mal traceroute -I oder tcptraceroute auf port 443. Aber wie @Web-Schecki schon sagt: Nicht das ziel interessiert hier, sondern der Weg

% ping www.computerbase.de
PING www.computerbase.de (212.83.33.137): 56 data bytes
64 bytes from 212.83.33.137: icmp_seq=0 ttl=252 time=1.967 ms
64 bytes from 212.83.33.137: icmp_seq=1 ttl=252 time=1.602 ms
64 bytes from 212.83.33.137: icmp_seq=2 ttl=252 time=1.555 ms
64 bytes from 212.83.33.137: icmp_seq=3 ttl=252 time=1.527 ms
64 bytes from 212.83.33.137: icmp_seq=4 ttl=252 time=1.575 ms
^C
--- www.computerbase.de ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.527/1.645/1.967/0.163 ms

hab ich jetzt gewonnen?

 

[Skysnake]

Große Geräte, bspw. Server, Filer und SAN-Directoren haben meist 4 Netzteile

Und haben dann normal trotzdem nur N+1 Redundanz. Die Anzahl der NTs sagt erst mal nichts aus.

Redundante Netzteile sind durchaus Standard, der Rest der Aussage ist hingegen daher geredet. Wer echte Redundanz will, stellt mehrere Geräte hin, redundante Netzteile sind dagegen nur ein kleiner "Trostpflaster", mit dem sich die Hersteller, oft ohne einen echten Bedarf, ein gutes Zubrot verdienen.

Ist so Pauschal auch nicht richtig. Wenn ein Task schon seit Wochen läuft willst du den nicht wegen nem kaputten NT verlieren.

Dann musst du auch Bedenken, was du machst. Wenn es nur high throughput ist, dann ok, aber wenn ein Task 1000 Server umfasst, dann der Ausfall eines NTs gar nicht so unwahrscheinlich.

Zudem muss in nem RZ auch mal ein Stromkreis für ne Wartung etc angeschaltet werden. Da bist du auch ganz froh, wenn das System einfach weiter läuft, oder halt sie 1000 Systeme.

Wenn du ne gewisse Verfügbarkeit brauchst, muss man halt auch was tun. Und einfach in andere Regionen etc replizieren ist jetzt auch nicht zwingend kosteneffizient. Klar, wenn Kohle keine Rolle spielt kann man viel machen, aber das haben die wenigsten.

Zwei Netzteile sind üblich, das eins ausfällt eher nicht - wir hatten 2 Defekte in den letzten 20 Jahren bei 40+ Servern.

Naja, das sind jetzt nicht viele. Wir haben einige tausend Server in Betrieb. Da fällt schon immer mal wieder eins aus. Gerade im ersten Jahr verabschiedet sich doch öfters mal eins.

Na ja, 2 Server nebeneinander zu stellen ist jetzt auch nicht wirklich eine Redundanz, wenn die am selben Stromkreis hängen und im selben Brandabschnitt liegen.

Das Spiel kann man beliebig weit treiben. Auf so ne Diskussion sollte man sich nicht einlassen. Es kommt immer einer, der noch eins drauf legt. Wir können das Spiel gerne 10 Runden spielen

Weiterhin ext4. Wie ist deine Erfahrung mit ZFS? Nutzt du das nur für sowas wie Bilddateien oder liegen da auch Datenbanken drauf?

ZFS ist bei kleinen Files nicht gerade der King, wenn es um Metadaten geht. Mit NVMe kommt man aber schon weit. Nen HW Raid mit Write Cache ist aber schon noch in manchen Bereichen überlegen. Für euch aber wahrscheinlich irrelevant.

Einen Brand halte ich in einem RZ für äußerst unwahrscheinlich, da reicht in den meisten Fällen auch ein Backup an einen anderen Standort. Allerdings darf man hier von einem ziemlichen Luxus sprechen, die RZs die ich in Frankfurt so gesehen habe, stellen nur zwei Stromkreise pro Schrank bereit.

Zwei Kreise reichen normal ja auch aus. Wenn einer davon noch an der USV hängt, dann ist das auch nicht schlecht.

Und bezüglich Brand. Das kann schneller passieren als man denkt. In den letzten 10 Jahren hatte ich 3 Anfahrten bei nem RZ erlebt. Ging immer alles gut aus, aber nur weil die Brandbekämpfungskonzepte funktioniert haben.

Im Optimalfall fällt dann auch nicht mal nen ganzes Rack aus. Da ist die Befüllung der Gaslöschanlage schnell teuer. Aber hey ohne wäre es echt teuer geworden

Nein. Der Leidensdruck war bislang nicht groß genug, weil wir praktisch nie Hardware-Probleme hatten. Und je komplexer das Setup, desto eher kann diese Komplexität dann auch zu Downtimes führen. Als nächsten Schritt will ich die Bilddateien und Forumanhänge irgendwann in einen Object Store packen. Danach gäbe es dann nur noch die Datenbank als "state".

Ihr habt also 2 Server und nen S3 für offsite Backup. Wie macht ihr denn dann den Wechsel zwischen den Servern?

Kepepalive IP wäre ja durchaus was für euch. Oder drbd könnte ich mir mit nem Quorum System vorstellen.

Aber klar, nen funktionierendes HA System aufbauen ist schwierig und mit corosync und Pacemaker funktioniert es dann am Ende oft genug auch nicht sauber. Da sind RAFT basierte Dinge schon ganz nett, also stabiler.

das tägliche MySQL-Backup nutzen wir Percona Xtrabackup + zstd-Komprimierung + age-Verschlüsselung

Wirklich zstd oder pzstd? Pzstd rockt schon gut.

Das komplette System liegt gespiegelt auf 2 NVMe-Laufwerken. Eingesetzt wird es als VM-Host. Großer Vorteil hier sind die Instant Snapshots von ZFS, d. h. es gibt quasi keine Downtime beim VM-Backup. Aktiviert habe ich auch die Kompression, das spart einiges und erhöht auch nochmal die Geschwindigkeit. Mit der Stabilität bin ich zufrieden, das System läuft jetzt seit einigen Wochen inkl. täglicher Backups einiger großer Windows-VMs.

Ist das schnell genug für euch? Also bezüglich Metadaten. Aber klar die snapshots sind schon geil. Habe ich erst in nem Backup System wi gesetzt. Jeden Tag nen kompletten Stand, den man leicht zurückspielen kann, aber trotzdem nur die Änderungen als neuen Speicherbedarf.

Das bedeutet aber auch bei einem Stromausfall (klar, unwahrscheinlich im Rechenzentrum), wäre keine Datensicherheit gegeben ? Normal setzt man doch nur auf einen extra Contro

Nein, wenn man vernünftige Software nutzt, gibt es kein write hole. Die HW Raidcontroller sind ja auch so performant, weil sie bescheißen und bei nem flush schon zurückkommen, wenn die Daten erst in RAM vom Controller sind und nicht erst wenn sie auf der Platte liegen. Dafür brauchen Sie halt die Batterie, sonst sind die Daten weg...

 

[jonsger]

Danke für den interessanten Artikel und die ebenso spannenden Kommentar.

23M hat ganz interessante Colocation-Preise wie ich finde. Leider nur für Geschäftskunden. Wenn ich seh das euer Server nur 130W braucht, kann man sich da sehr potente HW reinstellen und für wenig Geld betreiben. Abgesehen von den einmaligen Investitionskosten halt

@Steffen Wie findest du die SuperMicros im Vergleich zu den HPE Servern? Ich wäre v.a. interessiert an foldgenden Dingen: Remote Console, Remote Steuerung (Neustart etc), Boot-Dauer, SNMP-Unterstützung, Firmware-Updates.

Wir setzten in der Arbeit quasi ausschließlich auf HPE Proliants und ich bin gelinde gesagt nicht so wirklich begeistert. Ich empfinde sie an allen Ecken und Enden als unnötig aufgeblasen. Sowohl das iLO als auch das BIOS sind nicht so wirklich übersichtlich. Sie booten ziemlich langsam (gefühlte 5 Minuten) und Firmwareupdates sind ein Graus: 1h+ mit nem 10GB ISO-Image.

 

[ebird]

Genau deshalb hatte ich gefragt, heise gibts auch nur in FRA bei Plusline… und nein, traceroute ist kein ping sondern udp Nur Windows benutzt by default ICMP, aber deinem output nach war das nicht windows. Daher probier mal traceroute -I oder tcptraceroute auf port 443.

Ist das nicht etwas Haarspalterei? Beides sind verbindungslose IP Pakete. Die TTL ist da entscheidend und nicht der Payload. Und da geht es nicht darum, was in dem Pong Paket steht oder welches Transportprotokoll es ist. Mit geht es auch nicht darum, dass der computerbase Server oder die Route lahm ist, sondern darum, dass 20ms definitiv nicht schnell ist. Alle Routen sind ungefähr gleich.

Daher probier mal traceroute -I oder tcptraceroute auf port 443.

Man konnte auch schon vorher sehen, dass diese direkt nach Frankfurt gehen. Einige waren bis Frankfurt sogar gleich.

64 bytes from 212.83.33.137: icmp_seq=4 ttl=252 time=1.575 ms
^C
--- www.computerbase.de ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.527/1.645/1.967/0.163 ms
[/code]
hab ich jetzt gewonnen?

Leider habe ich aktuell nichts in Frankfurt. Habe meine letzten bei Hosteurope gekündigt, nachdem die Telekom übernommen hat.

 

[foo_1337]

Ist das nicht etwas Haarspalterei? Beides sind verbindungslose IP Pakete. Die TTL ist da entscheidend und nicht der Payload. Und da geht es nicht darum, was in dem Pong Paket steht oder welches Transportprotokoll es ist.

Der Payload ist egal, das Protokoll nicht. Je nachdem was die Targets / Hops erlauben, nimmt man halt UDP, ICMP oder TCP. Und nur diesen Hinweis wollte ich dir geben weil du sagtest:
"Kann ich nicht durchführen mit computerbase.de bzw. nur teilweise"
Ich wüsste nicht, was das mit Haarspalterei zu tun hat. Das ist wie im 2. Satz geschrieben halt relevant, je nachdem was zugelassen/geblockt wird.

sondern darum, dass 20ms definitiv nicht schnell ist. Alle Routen sind ungefähr gleich.

Und genau deshalb hätte mich die Route interessiert. Was heißt "ungefähr" gleich? Da muss es einen entscheidenden Unterschied geben. Peers/PNI/Whatever überlastet? Das hätte man halt auf dem Traceroute gesehen. So ist es leider ein "20ms ist nicht schnell!" bzw "mies" wie du zuerst sagtest. Mit der Aussage kann aber so keiner was anfangen. AS47447 hat z.B. auch ein paar weniger peers/andere via ipv6. Evtl. liegt es auch daran? Falls du dich umentscheiden solltest und einen traceroute nachliefern magst, wäre es interessant sowohl einen via v4 und einen via v6 zu sehen.
Ggf. hat das CB Team ja auch interesse, das 23M mitzugeben, damit ggf. die Peers verbessert werden.

Man konnte auch schon vorher sehen, dass diese direkt nach Frankfurt gehen. Einige waren bis Frankfurt sogar gleich.

Man konnte als Mitleser hier im Forum anhand deines Beitrags nur eines sehen: Die RTT. Ob das was direkt oder nicht irgendwo hin ging, war und ist nicht ersichtlich.

Ergänzung (1. Dezember 2021)

Habe meine letzten bei Hosteurope gekündigt, nachdem die Telekom übernommen hat.

Die Telekom? Host Europe gehört GoDaddy. Die Telekom hatte das zwar vor, aber es kam nie zustande.

 

[xexex]

Ist so Pauschal auch nicht richtig. Wenn ein Task schon seit Wochen läuft willst du den nicht wegen nem kaputten NT verlieren.

Ich bezog mich hier eher auf die klassischen Fälle im Mittelstand, wo die Hersteller allesamt gerne redundante Netzteile verkaufen, wo aber oft kein wirklicher Nutzen draus entsteht. Es haben sich halt in diesem Sektor einige Eigenheiten eingebürgert, die längst nicht mehr wirklich Sinn ergeben, aber von einigen wie ein Mantra daher geredet werden.

Wir haben schon Kunden gehabt, da wurden bei einem Audit solche Sachen bemängelt, obwohl eine Serverredundanz bestand. Ist halt genauso wie mit Hardware Raidcontrollern, die ja per se gut und Software Raids, die grundsätzlich schlecht sind. Absoluter Blödsinn heutzutage, aber kriege das erst einmal aus den Köpfen der Leute raus.

Das Problem in der IT ist leider, dass man Gegebenheiten wie sie vor 20 Jahren noch üblich waren, gerne auch hoch heute als Standard ansieht. Wie du schon selbst korrekt anmerkst, pauschal sollte man heutzutage nichts als gesetzt sehen, sondern muss die Lösung als ganzes betrachten.

Zwei Kreise reichen normal ja auch aus. Wenn einer davon noch an der USV hängt, dann ist das auch nicht schlecht.

In einem Colocation Schrank halte ich es als viel zu wenig. Unter Umständen hast du dort 42 Netzteile an jedem Stromkreis. Das ist nicht nur eine potentielle Fehlerquelle, falls mal wirklich ein Netzteil kaputt geht, es schränkt auch meist den maximalen Strombedarf ein.

Wenn man in einem RZ nicht mehrere Schränke bucht, würde ich immer mindestens auf 4 Stromkreise bestehen und die Infrastruktur von den Servern trennen. Bei Netzteilen ist es ein wenig wie bei großen Raids, steigt ein Netzteil aus und verursacht einen Kurzschluss, kann es auch andere Netzteile beschädigen.

Ergänzung (1. Dezember 2021)

Wie findest du die SuperMicros im Vergleich zu den HPE Servern? Ich wäre v.a. interessiert an foldgenden Dingen: Remote Console, Remote Steuerung (Neustart etc), Boot-Dauer, SNMP-Unterstützung, Firmware-Updates.

Du kannst es schlecht vergleichen.

Vorteil - Vom Preis gar nicht zu vergleichen, du kannst locker >50% im Vergleich zu einem HP Server sparen, du bekommst echte Plattenrahmen und musst nicht überteuerte Datenträger von HP kaufen und kannst natürlich auch die restlichen Komponenten im freien Handel beziehen. IPMI ist immer ohne jeglichen Aufpreis inklusive Bildschirmumleitung vorhanden, alleine die Option kostet bei den OEMs 300€+.

Abgesehen davon bietet Supermicro x-mal so viele Servervarianten, von All-Flash Storageservern bis 16xGPGPU Rechenmonstern ist alles dabei. HP hat zwar auch viele, im Vergleich aber nur einen Bruchteil und auf zig verschiedene Marken und Serien verteilt.

Nachteil - Wenn du alles von HP zu Projektpreisen beziehst und die Server später nicht mehr aufrüstest, kannst du bei den OEMs sogar günstiger als bei Supermicro landen. UEFI Updates sind bei Supermicro grausam, es wird immer das komplette UEFI auf die Standardeinstellungen zurückgesetzt und auch die Pflege halte ich für relativ kurz.

Sowohl das iLO als auch das BIOS sind nicht so wirklich übersichtlich.

Wenn du das bei HP kritisierst, solltest du mit Supermicro gar nicht erst anfangen, das UEFI ist bei HP vergleichsweise überschaubar.

 

[Skysnake]

In einem Colocation Schrank halte ich es als viel zu wenig. Unter Umständen hast du dort 42 Netzteile an jedem Stromkreis. Das ist nicht nur eine potentielle Fehlerquelle, falls mal wirklich ein Netzteil kaputt geht, es schränkt auch meist den maximalen Strombedarf ein.

Also 22kW dürften normal völlig ausreichend sein für Colocation. Das ist eine 3-Phasen PDU. Davon als zero U zwei Stück und gut ist. Mehr braucht es da nicht wirklich weil mehr bekommst du mit Luft eh nicht effizient gekühlt.

Klar wir haben auch Racks mit bis zu 50kW. Da braucht es dann halt paar mehr PDUs mit redundanter Stromversorgung, aber das ist nicht mehr mit Luft machbar.

@Steffen welche Kernel Parameter tunings verwendest du eigentlich?

 

[ebird]

...

Ließt Du überhaupt oder nimmst einfach nur Absätze und reimst Dir irgendwas daraus zusammen. Vor allem wenn Du schon weiß, dass es an IPv6 liegt. Nicht nur bei 23m sondern auch auf dem computerbase.de Server geht.

 

[GrenSo]

ComputerBase ist am Montagmorgen nicht nur auf neue Server umgezogen, sondern auch zu einem neuen Server-Provider in ein neues Rechenzentrum.

Zur News: In eigener Sache: Das neue Server-Setup von ComputerBase (2021)

Das RZ von 23M ist Luftlinie ca. 400 bis 500m von meiner Arbeit entfernt und wurde auch erst innerhalb der letzten 3 bis 4 Jahre gebaut.

 

[ElisaMüller]

Ihr nutzt S3 als Speicher, habt aber 99% im cache weil S3 teuer ist. Dumme frage, aber wo liegt der cache (ram oder nvme) und wie gross ist er?