News Intern: Downtime am Samstag wegen Server-Umzug und -Upgrade

[gruenmuckel]

Da muss der Chef seinem Admin aber nochmal die Rangfolge erklären.

 

[ShiningDragon]

Irrtum!

Du weißt, wie man einem den Tag runiert.

 

[hoschi_tux]

Bisher nicht. Ich hätte sie halt in der Bucht oder im Marktplatz vertickt, aber wenn Du sie gebrauchen kannst, werden wir uns sicherlich einig ((

Bleibt nur zu hoffen, dass sie wie meine auch bei Vollbestückung als PC3200 laufen.

 

[KIDH]

Bleibt nur zu hoffen, dass sie wie meine auch bei Vollbestückung als PC3200 laufen.

Ist das nicht eher von der CPU abhängig (Speichercontroller)?

 

[Allfred]

Alles Gute im Trockendock!
Wenn wir etwas etwas gutes (Spende/Zuwendung) tun dürfen lasst es uns wissen!
Übrigens finde ich die Idee mit entfernten Heatspreader gar nicht so schlecht, schließlich sind wir keine 08/15 Gurkentruppe und müssen das nicht wie alle anderen machen! Ein wenig "Sportsgeist" und Risiko - von meiner Seite 100% Verständnis.

Axo - das Zippy ist noch Top?

 

[Blutschlumpf]

Grund ist ein Umzug aus dem Rechenzentrum in Frankfurt nach Idstein in einen neuen Server-Raum unseres Housers. Natürlich hoffen wir dadurch eine noch bessere Erreichbarkeit der Seite gewährleisten zu können. Prinzipiell war Frankfurt auch nicht schlecht, jedoch kam es immer mal wieder zu kurzfristigen Downtimes, vorwiegend wegen Problemen mit der Stromversorgung. Wir können nur spekulieren, aber vermutlich ist das mit ein Grund, weshalb unser Houser den Standort Frankfurt verlassen und ein eigenes Server-Zentrum aufbauen möchte.

In der Regel gibts 2 gute Gründe so ein RZ umzuziehen:
-billigerer Strom (wobei man hier dann konsequenterweise nach Frankreich oder in den Ostblock zieht wo es den guten Atomstrom zum Spotpreis gibt)
-billigeres Gebäude (In FFM gibts eh an jeder Ecke ein RZ, da kann man auch mal 50km weiter ziehen)

 

[Nero24]

Irrtum!
Die Datenbankdisken werden nicht größer!

Ich weiß, dass die DB-Disken nicht größer werden! Vielleicht zitiere ich hier lieber einfach mal Dich selbst:

...würd ich fast sagen es ist gescheiter einfach die 2 IDE Platten durch 2 SATA mit 0,75 oder 1TB auszutauschen und dort "unwichtigere" Sachen wir emails, logfiles backup usw. hin zu legen. Dann sind wir auf jeden Fall das Diskproblem los. Die Datenbankdisken tauschen wir erst wenns wirklich nicht mehr anders geht.

 

[Crashtest]

Auch von mir aus viel Glück.

Ein Bitte hättsch aber noch - könntet ihr die neue IP des Servers ins Twitter/Reserveding packen - wer braucht schon DNS ?!



Mal sehen, was die Zukunft bringt - ich spar grad für ein MC-System, sodass bald, ca 5 Monae, (m)ein Dual-Shanghai-System überflüssig würde ... 8x2,6GHz mit 16GB DDR2-800 REG ECC (oder mehr) wären doch ein wenig potenter als 2 Egypt-DCs
Man bräuchte ggf ein anderes Board aber naja ...

 

[tomturbo]

Ich weiß, dass die DB-Disken nicht größer werden!

mit emails sind aber nicht die in der VB DB gemeint
Von daher steht für die vb db tatsächlich nicht mehr Platz zur Verfügung.

 

[mj]

Die Nachrichten werden in der MySQL Datenbank gespeichert, so wie alles andere das vBulletin speichert. Da die Datenkbank auf zwei separaten 15.000rpm Disken im RAID 1 Verbund liegt und die nicht ausgetauscht werden steigt auch der für die Datenbank verfügbare Platz logischerweise nicht. Durch die neuen Festplatten werden die Datenbankdisken somit nicht entlastet, da nichts außer der Datenbank darauf liegt und wir daher auch nichts davon abziehen können. Da wir die Datenbank auch nicht auf eine andere Platte legen können denke ich nicht, dass die Anzahl der Nachrichten signifikant erhöht werden kann.

Aber das müssen wir noch mal genau prüfen wenn die Platten drin sind und wir Situation in Ruhe analysiert haben. Ich bin bei den Nachrichten deutlich optimistischer als beim verfügbaren Platz für Anhänge

 

[gruenmuckel]

mit emails sind aber nicht die in der VB DB gemeint
Von daher steht für die vb db tatsächlich nicht mehr Platz zur Verfügung.

Watt für ein Scheiß. Darüber bin ich echt traurig.
Ich bin mit 3,89MB Anhängen im roten Bereich. Lass uns hier mal 500 richtig aktive User haben, dann sind das keine 2 Gigabyte für die User.
Das ist echt Steinzeit, sorry. Bitte nicht als Angriff auffassen, das ist einfach nur eine Bestandsaufnahme.

Klar kann ich damit leben, aber es ist ärgerlich. Ich hab schon informative Bilder (und seien es nur30kb pngs) aus alten Beiträgen löschen müssen um hier mal was hochzuladen. Ja, ganz selten will ich was nur hier hochladen. Das ist ägerlich weil es die alten Beiträge entwertet.

 

[PuckPoltergeist]

Das letzte Upgrade des Servers ist eigentlich ein Downgrade, aber leider ein notwendiges. Wie Planet 3DNow! Kenner wissen, werkeln im Server zwei AMD Opteron 290, also zwei 90 nm E-Stepping Dual-Core K8, die nur kurz im Portfolio von AMD waren. Wir glauben auch zu wissen wieso, denn diese beiden Hitzköpfe sind kaum zu kühlen. Trotz zweier CoolJAG JAC18SC Prozessor-Kühler mit 0,21 °C/W Wärmewiderstand und 65 CFM Durchsatz, sowie zwei Gehäuselüftern mit nicht weniger als 11.000/min (!) können wir die beiden AMD Opteron 290 nicht mit Dauervollast betreiben, ohne über 70°C zu kommen, was natürlich die <a href="http://dc.planet3dnow.de/wiki/index.php?title=Distributed_Computing">Distributed Computing</a> Fraktion im Team sehr ärgert. Wir vermuten, dass bei unseren beiden Exemplaren der Wärmeübergang Die->Heatspreader suboptimal ist, zumal die beiden CPUs - obwohl eigentlich baugleich - sich auch noch um 5 Kelvin unterscheiden. Abstürze hatten wir dabei zwar noch nicht zu vermelden, aber ab 70°C Temperatur häufen sich die Northbridge Error-Log Einträge. Da die CPU-Last derzeit sowieso kein Kriterium ist, werden wir die beiden AMD Opteron 290 gegen zwei 270er tauschen, die uns ebenfalls bei weitem genügen werden, ab sofort dann aber rund um die Uhr mit Dauervollast betrieben werden können.

Werden die Dual-Cores überhaupt von dem Board offiziell unterstützt? Bringe ich da was durcheinander, oder war das nicht die erste Revision des Boards (S2882, oder?), dem Tyan den offiziellen Support verweigerte?

 

[tomturbo]

Watt für ein Scheiß. Darüber bin ich echt traurig.
Ich bin mit 3,89MB Anhängen im roten Bereich. Lass uns hier mal 500 richtig aktive User haben, dann sind das keine 2 Gigabyte für die User.
Das ist echt Steinzeit, sorry. Bitte nicht als Angriff auffassen, das ist einfach nur eine Bestandsaufnahme.

Klar ich kann Dich verstehen, 36GB Disken sind aber leider nicht die Welt.
Aber sie ist unsere und nach der müssen wir uns richten.
Vielleicht fällt uns noch etwas ein womit wir die Situation verbessern können.

lg
__tom

 

[hoschi_tux]

Ist das nicht eher von der CPU abhängig (Speichercontroller)?

Ja schon, nur habe ich das bisher nur mit einer CPU getestet.

 

[PuckPoltergeist]

Klar ich kann Dich verstehen, 36GB Disken sind aber leider nicht die Welt.
Aber sie ist unsere und nach der müssen wir uns richten.
Vielleicht fällt uns noch etwas ein womit wir die Situation verbessern können.

Wechsel auf SATAn? Welchen zwingenden Grund habt ihr noch, auf P-SCSI zu setzen?

 

[mj]

Primär Performance. Für eine Datenbank geht nichts über Festplatten mit 15.000 Umdrehungen.
Zudem wäre die einzige ernsthafte Alternative SAS. SATA-Platten traue ich aus Erfahrung keinen halben Meter weit, für kritische Einsatzgebiete wie die zentrale Datenbank wäre das Suizid.

 

[PuckPoltergeist]

Primär Performance. Für eine Datenbank geht nichts über Festplatten mit 15.000 Umdrehungen.

Naja, für eine DB ist erstmal nix besser als RAM. Ok, zweites Kriterium ist dann die Pladde. Aber werden die Anhänge auch in der DB gespeichert? Sonst könnte man doch da splitten? (Sorry, kenne vBulletin überhaupt nicht)

 

[SPINA]

Dann muss Intel beim nächsten Themenabend um ein paar X25-E fürs Serverlein gebeten werden. Vielleicht sind sie spendabel.

 

[PuckPoltergeist]

Dann muss Intel beim nächsten Themenabend um ein paar X25-E fürs Serverlein gebeten werden. Vielleicht sind sie spendabel.

Oder so. Aber ich weiß nicht, wie die Flash-Teile die massiven Zugriffe des Servers verkraften. Man hat ja nix gewonnen, wenn man im sechs-Monats-Rhythmus die Speicher wechseln muss.

 

[mj]

SSDs haben wir uns schon überlegt. Allerdings ist die I/O-Last auf den Disken so hoch, dass keiner genau weiß wie lange eine SSD durchhalten würde. Schließlich ist die Anzahl der Schreib/Lesezyklen auf Flashspeicher begrenzt und als Beta-Tester wollen wir nicht in die Geschichte eingehen

 

[ShiningDragon]

Ach... einfach ein paar SSD Hersteller anschreiben und eine wohlwollende Berichterstattung androhen, wenn die gespendeten SSD lange und performant laufen.
Die Hersteller protzen doch immer mit angeblich jahrzehntelanger Haltbarkeit, das wäre ihre Chance den Werbequatsch zu beweisen.

 

[PuckPoltergeist]

Ach... einfach ein paar SSD Hersteller anschreiben und eine wohlwollende Berichterstattung androhen, wenn die gespendeten SSD lange und performant laufen.
Die Hersteller protzen doch immer mit angeblich jahrzehntelanger Haltbarkeit, das wäre ihre Chance den Werbequatsch zu beweisen.

Nagelst du dir den Aufwand an die Backe, die Hardware zu pflegen. Zumal dann ein wirklich sensibles Backup-System ran muss. Weil die Teile in dem RAID1 garantiert relativ gleichzeitig ausfallen werden. Für nen Produktivsystem wäre mir das Risiko zu groß.

 

[mj]

Es gibt Dinge die tut man in einem Server. Und es gibt Dinge die tut man in einem Server nicht. Experimente und Basteleien fallen definitiv in letztere Kategorie.

 

[tomturbo]

Naja, für eine DB ist erstmal nix besser als RAM. Ok, zweites Kriterium ist dann die Pladde. Aber werden die Anhänge auch in der DB gespeichert? Sonst könnte man doch da splitten? (Sorry, kenne vBulletin überhaupt nicht)

Bei VB wird alles in der DB gespeichert (Gott sei Dank)
Sonst wäre Master/Slave- und Multinode-Betrieb nicht oder nur schwer möglich.

lg
__tom

 

[SPINA]

Experimente fallen definitiv in letztere Kategorie.

Ich glaube moderne SSDs mit SLC Chips fallen nicht darunter. Viele Datenbankserver setzen inzwischen darauf.

Aber vermutlich wäre es für das Boot 2.3 nicht sonderlich wirtschaftlich. Sie haben ja doch ihren Preis. Sei es nun Intel oder Mtron.