Schnattis Server wird gewartet

[drdope]

Grrrrrr, jetzt wurde mein nicht ganz unumfangreicher Beitrag bzgl. der Hausaufgaben gefressen...

Ansonsten:
1) Der Riser war/ist unauffällig, würde ich weiter nehmen
2) Die Hardware-Bilder sind schon bitter, wobei es vergleichsweise doch hinterher immer so harmlos aussieht...
Gefühlt ärgere ich mich am meisten drüber, dass das Teil doch gerade erst angelaufen und frisch bezahlt worden war. Wobei es andererseits vermutlich noch behämmerter gewesen wäre, wenn frisch nach der Jungfernfahrt des Servers mit aufgespieltem OS seitens des BSB der Controller wegknackt...

Das Session-Timeout hat mich auch schon so manchen Beitrag gekostet...


2) War ein undichter Wakü-Anschluß (3€) Artikel... die Kühlflüssigkeit ist direkt auf Karte den Slot getropft...
Muß man unter doof gelaufen verbuchen... das Mainbaord war einen Tag alt; hatte gerade alles umgebaut.
Immerhin ist mir die "Suppe" nicht auf die GPU getropft, weil der PCIe-Anschluß ein paar mm weiter hinten lag...

(3)Besser ein DOA, als später im Betrieb, letzteres erhöht nur den zeitlichen Aufwand.

[Schnatti]

DOA - es gibt auch für alles inzwischen eine Abkürzung.

Der Hausaufgabenfahrplan war in etwa der:

ZUERSCHT:
- muss zusehen, dass der Tagesbetrieb ungefährdet ist, danach kann ich auf Spurensuche gehen
- primär Blick auf den direkt am Server konnektierten Monitor, wie es mit Lebenszeichen aussieht (läuft ESXi?), danach Versuch der Verbindung mit vSphere Client auf den Host um zu schauen, was die beiden VM "sagen", zuletzt:
- Blick auf den Zentralclienten samt seiner virtualisierten Ersatzserver-Funktion: wenn ersterer auch keine Erreichbarkeit vermeldet, muss ich das ganze unter "Ernst" verbuchen und ein größeres Problem, als dass nur das Patch-Kabel aus'm Switch annehmen geflutscht ist
- was diesen Teil dann betrifft rufe ich den BSB an (die haben zumindest auch einen 24h-Bereitschaftsdienst, inwieweit der helfen kann ist natürlich nicht gesagt) und lasse mich in den Notlauf des Ersatzservers führen
- dann hoffe ich, dass der "Rumpfbetrieb" mit dem Ersatzserver besser läuft als zuletzt und die Clienten alle weiterhin arbeiten können
(ein Kollege von mir hat ein ähnliches System, da arbeiten die Clienten bei Serverausfall erstmal autark und benötigen keine dauerhafte LAN-Verbindung zur DB, bringen dann erst später wieder die serverseitige DB auf den neuesten Stand - das klingt schon etwas praktischer als bei mir, muss ich zugeben, die Wahl dazu habe ich aber aktuell nicht)
- wenn alles gut läuft ist zumindest damit der Tagesbetrieb gewährleistet und ich habe inzwischen den Rücken frei, mich um das Hardwarethema zu kümmern

DANACH:
- ich versuche das Hardwareproblem des defekten (?) Servers zu orten
- wenn der Server unter Hardware-Minimalbesetzung schon mal läuft, wäre das ein kleines erstes gutes Zeichen
- analog des aktuellen Problems würde ich dann peu-a-peu die fakultativen Hardwarekomponenten zum System zufügen, um zu schauen, ab wann es kritisch wird
- sollte wie gerade bspw. der RAID-Controller als Störenfried identifiziert werden können, würde ich ein Ersatzteil besorgen; zuvor freilich im Drittserver schauen, ob ich schnellen Ersatz habe (hätte ich aktuell mit dem anderen Controller)
- Neuaufsetzen des Raidsets
- Überspielen des "relativ aktuellen" Images auf den virtuellen Datenträger
- danach müsste ich wieder den BSB fragen, inwieweit mein aktuellstes DB-Backup (USB und/oder NAS) auf den "offline"-Server überspielt werden kann, um erstmal einen noch aktuelleren Stand der Dinge zu reproduzieren
- letzteres bringt zwar auch erstmal keine großen Punkte, da ja währenddessen eh weitergearbeitet wird und sowieso schon wieder neue Daten anfallen, die ich später auch bloß wieder zurückspielen muss, schaden kann es aber imho nicht und auch kein allzu großer Zeitfaktor sein - wenn es denn überhaupt geht, ohne dass der Server im LAN ist (was er ja bis hierhin meinerseits noch nicht wieder ist)
- den daraufhin vorhandenen aktuellst möglichen Server würde ich dann in die alte Umgebung wieder zurückverpflanzen und an's LAN bringen
- was ab hier für Switch-Überraschungen o.ä. auf mich lauern, ist für mich völlig unvorhersehbar, weiß nicht ob ich mich hier in Mutmaßungen verstricken sollte
- mit etwas Glück erreiche ich im Problemfall den System-Admin, der die lokale Infrastruktur aufgebaut hat, und kann mir auch ohne Wartungsvertrag zügig helfen lassen
- ohne etwas Glück muss ich selbst orakeln gehen...

Was hab ich direkt übersehen?

Und wie stellt man eigentlich wieder den aktuellsten Zustand-NACH-Backup wieder her?
Sprich die im günstigsten Fall 24 Stunden Daten, die mir seit dem letzten Backup fehlen, wie rekonstruiert man so etwas?
Mein Warenwirtschaftssystem stimmt doch sonst hinten und vorne nicht...
"Aus der Erinnerung" wieder in die DB speisen oder was ist bei solchen Fällen der Masterplan?

[Schnatti]

Kleines Update noch:

Der neue gebrauchte H200-Controller ist gekommen, so dass ich mich an den Wiederaufbau machen kann.
Nach Anschluss der beiden SSDs in gewohnter Manier gelange ich zu folgendem Stand:



Sieht also gut aus auf den ersten Blick. Nur das "Boot" hinter der Slot0-SSD ist für mich neu, das stand da zuletzt nicht.
Ich bin zugegebenermaßen wieder einmal reichlich verwirrt, weil der Controller direkt die beiden Platten als Raidverbund-SSDs zusortiert und den RAID-Status anerkennt. Obwohl der Controller selbst die beiden Speichermedien zuvor noch nicht gekannt hat...
Das Raidset wird zwar als inaktiv geführt, das allerdings lässt sich ja innerhalb von 5 Sekunden ändern:



Danach bin ich also direkt im aktiven R1-Modus, wobei noch ein "consistency check" läuft, den ich bisher noch nicht in live kenne. Es bleibt dabei: Alles merkwürdig aus meiner Sicht mit diesem RAID-Zeuchs…
Ich nehme aber zur Kenntnis, dass bis hierhin die SSDs nicht defekt scheinen und ein Voranschreiten im Plan voraussichtlich möglich ist.

Noch weiter verwirrt werde ich durch folgende Meldung beim Bootvorgang nach Initialisierung des RAID-Controllers:



Das ist IMHO noch nicht die Meldung, dass das System kein bootfähiges OS findet, sondern die Maschine beschimpft ja irgendeine fehlerhafte Einstellung der Bootreihenfolge/-Präferenzen (?). Aber welche konkret...dass das System zuerst von den physischen Laufwerken booten soll, ist eigentlich eingestellt. Und ein virtuelles RAID-Laufwerk ist doch besser als kein Laufwerk?
Muss ich mir morgen nochmal anschauen, wo hier Wünsche unerfüllt bleiben.

Soviel also erstmal zum Stand der Dinge.
Bei konkreten Hinweisen zu meinen Unklarheiten gerne wieder her damit.

Ansonsten habe ich zufällig folgende Dinge in meinem Büro gefunden:





Bei ersterem ist mir völlig unbekannt, woher es stammt und was ich damit sinnvolles tun kann.
Das Teil ist ein Lancom 1681V-Router, aber welcher Wichtel hat den wann in meinen Schrank gestellt und was will er mir damit sagen?
Das andere sind tatsächlich Backup-CDs vom Hypervisor und dem BSB-gemoddeten Linux, was als Server-OS läuft. Es geschehen Zeichen und Wunder...
Nicht, dass ich glaube, dass das nach 6 Jahren eine wertvolle Backup-Option sein könnte, aber im Falle eines Falles ist es vielleicht ein Anfang. Wer weiß?

[drdope]

Was hab ich direkt übersehen?

Und wie stellt man eigentlich wieder den aktuellsten Zustand-NACH-Backup wieder her?
Sprich die im günstigsten Fall 24 Stunden Daten, die mir seit dem letzten Backup fehlen, wie rekonstruiert man so etwas?

Du mußt vor Inbetriebnahme des Ersatzservers dort das aktuelle DB-Backup einspielen.
Ebenso mußt nach Einsatz des Ersatzservers von diesem ein aktuelles DB-Backup machen und dieses auf
den reparierten Server bzw. Austauschserver wieder zurück spielen.

Mein Warenwirtschaftssystem stimmt doch sonst hinten und vorne nicht...
"Aus der Erinnerung" wieder in die DB speisen oder was ist bei solchen Fällen der Masterplan?

Überleg mal, was wäre, wenn du feststellst, daß dein DB-Backup fehlerhaft ist...
Dann reden wir plötzlich nicht mehr von Stunden, sondern von Tagen/Wochen/Monaten...

Deshalb ist es so wichtig, den Ernstfall mal zu proben...
Wenn der Ausfall nur ein paar Stunden dauert (weil man weiss, was zu tun ist und Ersatz parat steht und dem aktuellen Backup vertraut),
kann man ggf. auch dieses Zeit einfach mit "Pen & Paper" überbrücken...
Fies wird es immer, wenn z.B. zur Tagesmitte was defekt geht und man quasi einen halben Arbeitstag Tag in der DB "verliert".
Im Prinzip muß man für solche Fälle fertig modellierte Geschäftsprozesse bereit halten, damit man nicht akut/im Ernstfall "mit herunter gelassenen Hosen" dar steht.

Ganz bewußt arrogant formuliert -> Eine EDV-Lösung ist ein bissl mehr, als teure Hardware und Software hinzustellen.
Dummerweise merkt man das idR aber erst, wenn man sich selbst mal ein bissl intensiver mit dem Thema beschäftig!
Deshalb ist das, was du machst imho auch eine gute Sache.

Kleines Update noch:

Der neue gebrauchte H200-Controller ist gekommen, so dass ich mich an den Wiederaufbau machen kann.
Nach Anschluss der beiden SSDs in gewohnter Manier gelange ich zu folgendem Stand:

...

Ich bin zugegebenermaßen wieder einmal reichlich verwirrt, weil der Controller direkt die beiden Platten als Raidverbund-SSDs zusortiert und den RAID-Status anerkennt. Obwohl der Controller selbst die beiden Speichermedien zuvor noch nicht gekannt hat...
Das Raidset wird zwar als inaktiv geführt, das allerdings lässt sich ja innerhalb von 5 Sekunden ändern:

...

Ich nehme aber zur Kenntnis, dass bis hierhin die SSDs nicht defekt scheinen und ein Voranschreiten im Plan voraussichtlich möglich ist.

Der Unterschied zu deinen bisherigen Versuchen -> du benutzt identische/baugleiche Controller.
Der kann augenscheinlich auch mit den RAID-Sets seiner "Geschwister" umgehen, sprich interpretiert die Metadaten auf dem Raidset korrekt.
Aus meinen Erfahrungen mit 3Ware/LSI Areca-Controllern (neuere Controller gleicher Serie/der Nachfolgeserie können mit älteren Raidsets umgehen), würde ich vermuten, daß DELL
da auch entsprechende Upgradepfade bereit stellt.

Freut mich, daß es die SSDs nicht geschossen hat!

Noch weiter verwirrt werde ich durch folgende Meldung beim Bootvorgang nach Initialisierung des RAID-Controllers:

...

Das ist IMHO noch nicht die Meldung, dass das System kein bootfähiges OS findet, sondern die Maschine beschimpft ja irgendeine fehlerhafte Einstellung der Bootreihenfolge/-Präferenzen (?). Aber welche konkret...dass das System zuerst von den physischen Laufwerken booten soll, ist eigentlich eingestellt. Und ein virtuelles RAID-Laufwerk ist doch besser als kein Laufwerk?
Muss ich mir morgen nochmal anschauen, wo hier Wünsche unerfüllt bleiben.

Soviel also erstmal zum Stand der Dinge.
Bei konkreten Hinweisen zu meinen Unklarheiten gerne wieder her damit.

Schau mal, was an Bootdevices im Mainboard-Bios hinterlegt sind und ob/wann der Raidcontroller dort als Bootdevice eingetragen ist.
Vermutlich sind da noch Reste aus der vorherigen Konfig drin, die nun fehlen...

Ansonsten habe ich zufällig folgende Dinge in meinem Büro gefunden:

Bei ersterem ist mir völlig unbekannt, woher es stammt und was ich damit sinnvolles tun kann.
Das Teil ist ein Lancom 1681V-Router, aber welcher Wichtel hat den wann in meinen Schrank gestellt und was will er mir damit sagen?
Das andere sind tatsächlich Backup-CDs vom Hypervisor und dem BSB-gemoddeten Linux, was als Server-OS läuft. Es geschehen Zeichen und Wunder...
Nicht, dass ich glaube, dass das nach 6 Jahren eine wertvolle Backup-Option sein könnte, aber im Falle eines Falles ist es vielleicht ein Anfang. Wer weiß?

Der Lancom 1681V ist ein relativ teurer Staubfänger:
--> https://geizhals.de/?phist=576244

Vermute auf den Medien sind die Installer vom ESXi 5.0 (iirc) und Suse Enterprise Linux 11... kannst die CDs/DVDs ja mal testweise booten...
Wenn du z.B. den SEL11 neu aufsetzt, müßtest du nun
--> https://de.wikipedia.org/wiki/SUSE_L...rver#Versionen
alle Updates seit erscheinen (März 2009) ggf. sukzessive (SP1/2/3/4) einspielen und danach den DB-Server installieren, sowie das DB_Backup zurück spielen.
Das updaten könnte je nach Umfang (kenne SEL selbst nicht) und Internetanbindung länger dauern...

Mit einem aktuellen Image spart man sich das ganze gefrikkel!
Da muß du noch nicht mal den ESXi neu aufsetzen/einrichten.


Im Prinzip ist das unterm Strich immer alles eine zeitliche Abwägung, ausgehend von dem Szenario "Server fällt aus".
Wie lange brauchst du, um manuell ein funktionierenden Zustand auf beliebiger Hardware neu aufzubauen?
Wie lange brauchst du, um ein aktuelles Image auf imagekompatibler Hardware wieder zum laufen zu bekommen?

Die praktikabelste Lösung ist (imho) immer die am wenigsten komplexe/fehleranfällige und schnellste.

[Schnatti]

Du mußt vor Inbetriebnahme des Ersatzservers dort das aktuelle DB-Backup einspielen.
Ebenso mußt nach Einsatz des Ersatzservers von diesem ein aktuelles DB-Backup machen und dieses auf
den reparierten Server bzw. Austauschserver wieder zurück spielen.

Das hatte ich so angedeutet und schon auch mit im Gedankengang drin.
Der aktuelle, virtuelle Notlauf im Hintergrund sieht so aus, um mal einen Eindruck zu haben:



Sprich das Sekundärsystem ist per LAN permanent up-to-date, von wenigen Minuten Latenz abgesehen.
In dritter Zeile ist dann die USB-Datensicherung aufgeführt, die ja nächtlich ca. zu dieser Zeit angestoßen wird - was auch immer mit dem "eingespielt" konkret gemeint ist.
In dem Moment wo der Notlauf gestartet wird, wird also IMHO im Prinzip fast nahtlos weitergearbeitet, ohne dass ich die Daten erst transferieren muss.

Und auch nach Instandsetzung des Primärservers wird aktuell über diese Konsole die Kapitänsbinde zurückgegeben und die Daten gleich wieder mit zurückgeschickt ("Notlaufdaten übertragen"). Ein händisches Hin und Her mit USB-Stick/-Platte entfällt da.

Überleg mal, was wäre, wenn du feststellst, daß dein DB-Backup fehlerhaft ist...
Dann reden wir plötzlich nicht mehr von Stunden, sondern von Tagen/Wochen/Monaten...

Deshalb ist es so wichtig, den Ernstfall mal zu proben...

Der BSB wird vermutlich antworten:
"Das geht doch gar nicht, wir lassen doch bei der Datensicherung nach stattgehabtem Transfer die DB-Daten nochmal von einer Software-Routine überprüfen."
Leute wie mich kriegt man damit vermutlich.

...aber du hast Recht: Vertrauen ist gut, …

Ich stelle mir gerade die Gesichter und Reaktionen vor, wenn ich denen eine Mail schreibe, dass ich gerne mal am Tag XY zur Zeit Z ein Ernstfall-Szenario würde proben wollen und sie mich durchleiten sollen, so wie sie es sich vorstellen würden.
Könnte man ja mit dem aktuellen offline-Server tatsächlich durchexerzieren.
Also in Absprache mit dem BSB meine ich, alleine piepele ich da eher nicht rum.

Der Lancom 1681V ist ein relativ teurer Staubfänger:
--> https://geizhals.de/?phist=576244

Ganz kurz mal noch hierzu, das Kapitel ist ja aber ein anderes. Noch kommendes.

1) 700€ - WTF? Es ist mir ehrlich (!) ein Rätsel, wo das Teil herkommt und wer es bezahlt hat.

2) Ich hatte ja schon zuletzt angedeutet, dass ich mittelfristig aus branchenspezifischen Gründen eine 24h-Online-Verfügbarkeit benötige. Sprich: Nach aktuellem Dafürhalten und Argumentieren ist ein Arbeiten für uns nicht mehr möglich, wenn wir keinen permanenten Datenabgleich mit einer bestimmten Online-Plattform ermöglichen können. Wer auch immer so etwas für zwingend notwendig befunden hat und uns jetzt allen in der Branche einem Online-Druck aussetzt, den es so noch nie gab.
Da in dem Zusammenhang die Backup-Option mit einem Surfstick/SIM-Karten-Modul im Falle eines WAN-Versagens die plausibelste schien und die Telekom selbst in diesem Zusammenhang von einem LANCOM-Router als Möglichkeit zur Abhilfe sprach, wäre interessant zu wissen, ob ich die Lösung des Problems quasi schon ungenutzt bei mir herumstehen habe...
Kann man das von mir Erträumte aus der Kurzbeschreibung herauslesen? Ich bin in dieser Hinsicht absolut blind und hatte mit dem Thema noch niemals zu tun.

Diese Woche Dienstag hatte ich passenderweise einen spontanen Telefonausfall des Gewerbe-Anschlusses, der erst nach ca. 24h wieder repariert werden konnte. DSL war allerdings direkt nach Modem-Neustart wieder möglich...viel gefehlt hat aber nicht daran, dass ich mal einen Tag lang "ohne allen Zugriff von und nach außen" dastehe. Das hätte auch wieder super gepasst.

[drdope]

Imho schaut das richtig gut aus...

Die Server-DB synct sich sich selbstständig (im laufenden Betrieb) mit dem vorhanden Backupserver.
Das ist viel, viel, viel mehr, als ich erwartet hätte...

Das DOS-Interface (der VM) mag zwar archaisch wirken, ist aber (imho) einfach und simpel strukturiert.

Mit "eingespielt" meint die Software (imho) -> wenn das Server und Backupserver gleichzeitig die Grätsche machen (Feuer, Wasser, Überspannung, Diebstahl, EMP durch Atombombe, Kollision Erde/Asteroid usw...) könntest du noch (theoretisch) auf das 11:59h alte Offline-Backup zurück greifen...

Das wäre auch mein einziger Kritikpunkt:

Sprich das Sekundärsystem ist per LAN permanent up-to-date, von wenigen Minuten Latenz abgesehen.
In dritter Zeile ist dann die USB-Datensicherung aufgeführt, die ja nächtlich ca. zu dieser Zeit angestoßen wird - was auch immer mit dem "eingespielt" konkret gemeint ist.

Ist das Zufall, daß das letzte Offline Backup 12h weg ist?
Wie oft/häufig repliziert der laufende Server seine Daten auf das potentielle Backupsystem?

[Schnatti]

Das ist in der Tat Zufall., habe das Bild einfach um die Zeit vorhin aufgenommen.

Die Synchronisation läuft relativ zügig, ob sie minutiös erfolgt kann ich aber nicht sagen.
Gefühlt: Mindestens immer, wenn ich den Cursor im VM-Fenster platziere, aktualisiert sich die Zeit-Anzeige.

Tut mir leid, falls die Info darüber meinerseits gar nicht so herübergekommen war.
Ich dachte meine Beschreibungen der hiesigen Infrastruktur mit dem Zentralclienten hätten das an irgendeiner Stelle bereits dargestellt.

[drdope]

Kam nicht rüber... weise dir aber keinerlei "Schuld" dafür zu!

Frage an alle mitlesenden "Admins/User" kleinerer (< 30 PC-Arbeitsplätze) KMU's -> ist daß Standard, daß im LAN ein potentieller Backkup-Server mit läuft?
Imho ist das eine richtig "gute" Lösung, die mir so (in meiner beschränkten Praxis "Hobbyadmin") noch nicht begegnet ist.

[Schnatti]

Die Foto-Lovestory geht diese Woche weiter, eingeschlafen ist hier noch lange nix.

[hi2u]

Ich hoffe immer, wenn du hier nichts schreibst Schnatti, dass alles rund läuft bei dir Freue mich aber auf weitere Ausführungen, auch wenn ich leider nicht helfen kann.

[Schnatti]

Hey, danke für's Daumendrücken, kann man immer gebrauchen.
Beim Arbeitsserver ist tatsächlich nichts vorgefallen, alles ruhig.
Derweil liegen inzwischen daheim der geplante Hauptserver (ehemaliger "alter" Server) und der künftige Teilelieferant in Form des Drittservers zur Sichtung.

Um anzuknüpfen an die letzten Geschehnisse:
Mein letzter Wunsch (amen ) bestand darin, die momentan bestehende Hardware des kommenden Hauptservers nochmal mit den neuesten Firmware-Versionen aller beteiligten Komponenten und mit dem neuesten Mainboard-BIOS zu versorgen. Während des vorangegangenen Versuches per gemountetem USB-Stick mit dem Update-ISO ging mir ja die Hardware flöten, aufgrund eurer Rückmeldungen ja eher dank Freund Zufall und eher nicht durch Einfluss meinerseits...

Im nächsten Versuch war nun, bei vorbekannten Problemen mit Firmware-Update per USB-Device, meinerseits angedacht, das Update per CD zu tätigen. Ein (per SATA verbundenes) optisches Laufwerk hat der Rechner ja ohnehin, also eben einen Rohling verheizen und das Update so ablaufen lassen.
Gesagt, getan, krame ich die seltenst genutzten Rohlinge heraus und will mich gerade mit der Brennsoftware auseinandersetzen, als mir auffällt, dass ich die 2GB der *.iso eher nicht auf die CD bekommen werde...
Nach Besuch im örtlichen dm-Markt brannte ich daraufhin also am 08.09.2018 meine erste DVD.
War bisher noch nie notwendig, ich weiß auch nicht wann ich künftig je die nächste der 24 freien Scheiben benötigen werde...
Egal, hat man das Zeuch also auch noch herumliegen.

Danach dann also Bootvorgang von DVD:



Der Rest ist mir unverständliches Kauderwelsch...
(sorry, aber die schwarz-weiß-Screens kriegt meine Telefonkamera nicht gescheiter/schärfer hin)



...und nach 10 Minuten ist alles vorbei.



Aber: .
Der Reboot erfolgt reibungslos und "BIOS-Version 1.13." zeigt mir, dass tatsächlich etwas erfolgreich stattgefunden zu haben scheint.

Nächster Halt (der Doc hat mich ja quasi dahingehend beflügelt ):

[drdope]

Falls du die CPU noch nicht getauscht hast:
Die Verschraubungen des CPU-Kühlers am besten gleichmäßig und über kreuz lösen/anziehen,
damit nicht einseitig zu viel Kraft auf die CPU wirkt.
Bei Wärmeleitpaste gilt: "Man verwende sie sparsam, ein kleiner Tropfen in der Mitte des CPU-Heatspreaders genügt,
selbiger verteilt sich ausreichend über den Anpressdruck des Kühlers.


Viel erfolg!

[Schnatti]

Na, zumindest 50% deines Ratschlages habe ich vorausgeahnt...

Das Lösen (und später auch erfolgende Anziehen) der Schrauben gab mein Logikgefühl noch her, der Blick darunter offenbarte folgendes:



Schön ist ja was anderes...
...aber wer wusste schon, wie mein Endresultat aussehen würde. Also Klappe halten, weitermachen.

Das Objekt der Begierde hatte ich ein paar Tage vorher bei eBay aus deutscher, scheinbar vertrauenswürdiger Quelle geschossen und preislich gar nicht schlecht damit gelegen:



(das Forum dreht das Bild leider immer wieder ungünstig)
Der Intel Xeon x3480 ist zumindest beim Dell Poweredge R310 im Quadcore-Bereich das Höchste der Gefühle und ich wollte ja gerüstet sein...
Ich bin beileibe niemand, der stets am oberen Limit mitschwimmen muss oder will, aber für die Fragestellung "Wie kann ich am besten dem mir überbrachten Angebot des Softwarebetreibers trotzen?" hielt ich das CPU-Upgrade nach Speichermedien und RAM an dritter Stelle für vertretbar.
60€ brutto mit Rechnung waren im Gesamtkontext und nach Vergleich mit dem gängigen Marktpreis völlig ok. Außerdem hatte drdope mich nicht gerade entmutigt, was den CPU-Tausch angeht und Erfahrungen sind manchmal auch da, um einfach gemacht zu werden - also war der Plan gefasst.

Nach Einlesen in die Empfehlungen flatschte ich guten Mutes folgendes auf die neu in den Sockel gepflanzte CPU:



Mein Mut an das Gelesene (und die, wie ich später vernehmen sollte, zweite Empfehlung vom Doc ) verließ mich jedoch an dieser Stelle, als ich es für unsinnvoll hielt, den Fladen so zu belassen, wie er ist und einfach den Passivkühler darauf zu pfropfen.
Zwar finden sich im WWW durchaus Meinungen, dass über die Wärmeentwicklung eine daraus folgende Spreitung der Kühlpaste zu erwarten sei und man einfach den Kühler wieder repositionieren solle, aber mir erschien das zu...äh...tja...äh....ich weiß nicht, ich hatte einfach kein Vertrauen.
Daher dann doch die oldschool-Variante mithilfe einer ausgedienten Visitenkarte, ich hätte sonst nicht still weitermachen und "daran glauben" können:



Auch hier auf dem Bild wirkt die Masse übertrieben, aber "dick aufgetragen" hatte ich für mein Gefühl nicht.
Seitlich überschüssiges war problemlos abzuziehen gewesen, der Pastenfleck war auch gar nicht so fehldimensioniert gewesen, aber trotz dessen ist vermutlich schon zu viel aufgetragen worden. Ich habe mich dessen aber nie vergewissert, indem ich den Kühler später nochmal abgezogen und einen Blick darunter geworfen hätte.

Den Rest also noch porentief gereinigt, zumindest an diesem Equipment scheitert es in einer Apotheke nie...

[Schnatti]

...und das Resultat war folgendes:



So weit, so gut, mehr war nicht das Ziel.
Die 8GB RAM sind nur temporär, die volle Dröhnung werkelt aktuell auf Arbeit im Übergangsserver und wird bei Rücktausch der Server wieder im hiesigen Arbeitsserver landen.

Es folgt nun als nächstes, und da bewege ich mich wieder innerhalb des Zeitstrahles und nicht in der Retrospektiven, der Gang zurück zur Software.
Die Hardware scheint zu funktionieren, ich bin da angekommen, wo ich es mit den Upgrades hin schaffen wollte, also weiter im Schweinsgalopp.

Bzw. auch nicht, denn irgendwie "flaut" es ja tatsächlich schon ein wenig mit dem Elan, aber das ist vermutlich normal. Das einzige was richtig nervt, ist der Platzmangel daheim mit dem rumliegenden Gedöns, aber solange sich noch nicht beim Insbettgehen die Aluplatine des Servers an mich schmiegt, sondern das ganze eine Etage unter mir vor sich hinlungert, ist der Druck einfach noch nicht groß genug, das Projekt schneller abzuschließen...

Also: Mit nun 2 formatierten SSDs im RAID0-Verbund kann ich mir Gedanken machen um eine für mich essentielle Frage:
ESXi oder Nicht-ESXi?
Fakt ist: Ich brauche was bootbares, also muss ich mich zu irgendetwas entschließen.

[drdope]

Wärmeleitpaste ist von der Begrifflichkeit her irreführend.
Wärmeleitpaste leitet Wärme idR sehr schlecht; sie leitet sie lediglich viel weniger schlecht als Luft.

Ziel der Übung ist also nicht eine Möglichst homogene Schicht aus WLP zwischen CPU-Heatspreader und Kühler zu bekommen,
sondern "nur" dafür zu sorgen, das sich dort keine Luft befindet.
Die WLP soll mikroskopisch kleine Unebenheiten auf HS/Kühler ausgleichen, sonst nichts.
--> https://de.wikipedia.org/wiki/Wärmel...ärmeleitpasten


PS

Daher dann doch die oldschool-Variante mithilfe einer ausgedienten Visitenkarte, ich hätte sonst nicht still weitermachen und "daran glauben" können.

Muß man nicht "glauben", kann man auch einfach mit Objektträgern aus Glas (ggf. hast du auch Laborbedarf zur Hand?) testen.
Einfach mal mit unterschiedlichen Mengen an Paste auf dem Objekträgern experimentieren + Druck + Temperatur.

Also: Mit nun 2 formatierten SSDs im RAID0-Verbund kann ich mir Gedanken machen um eine für mich essentielle Frage:
ESXi oder Nicht-ESXi?
Fakt ist: Ich brauche was bootbares, also muss ich mich zu irgendetwas entschließen.

Du meinst Raid1, oder?


Schwieriges Thema, ich werde die Tage (warte noch auf bestellten RAM) den letzten, von mir betreuten ESXi abschalten.

Das Problem des (kostenlosen) ESXi ist, daß er
a) nur auf zertifizierter Hardware läuft und
b) viele Einschränkungen hat, die sich nur durch (imho sehr teure) Softwareprodukte (vSphere fürs Management und z.B. Veeam für Backups) umgehen lassen.

Zum Beispiel gibt es auf dem ESXi (ohne Erweiterungen), keine wirklich praktikable Lösungen, um Backups der laufenden VMs zu erstellen.
Den Server für ein Full-Backup offline zu nehmen ist imho wenig elegant, weil es händischen Aufwand bedeutet.

Ich hatte ja mal folgendes Beispiel genannt:

Szenario B)

Gebäudereiningung mit ESXi-Server für VM-Server, sechs VM-Office-Clients und einen VM-HBCI-Banking-Client.
Auf allen Systemen läuft Windows.
Als Client-Hardware kommen gebrauchte Thin-Clients zum Einsatz, die sich per RDP mit den VMs verbinden.
Die Backups laufen alle automatisiert/zeitgesteuert per Acronis True Image auf ein der Firma stehendes NAS.
DB-Backup erfolgt nochmals einzeln aus der DB-Software selbst auf das NAS.
Das NAS synct sich per VPN/rsync mit Chefs NAS@Home (symetrische Glasfaseranbindung ist was feines).
Das NAS@Home sichert Chef mit One-Touch-Backup und mehreren externen 2,5' HDDs nach Hanoi-Schema.

Das ganze hat den Haken, daß man beim Ausfall des ESXi-Systems erst mal irgendwo einen neuen ESXi aufsetzen muß.
Danach legt man acht neue VMs an, die man dann einzeln per Acronis Rescue Medium bootet und manuell die (automatisch erstellten) Images zurück spielt.
Die automatisierten Backups sind zwar schon ein guter Schritt, aber elegant geht anders...

Inzwischen steht dort ein QNAP TS-677 (mit demnächst 40GB RAM, Ryzen7 1700, 2x 1TB SSD R1 und 2x 3TB R1 für Daten und Backups; Coldspares vorhanden).
Die vorhandene Datenträger aus dem alten QNAP/NAS wurden in das neue Gerät migriert.
Dabei wurde die Konfiguration des alten Gerätes 1:1 übernommen (kein administrativer Aufwand um den IST-Zustand wieder her zu stellen).
Dank der Virtualisation Station, welche QNAP bereit stellt, kann ich dort die VMs vom ESXi importieren und weiter betreiben.
Die Virtualisation Station bietet auch einfache Möglichkeiten, die laufenden VMs automatisiert/zeitgesteuert zu sichern und mit wenigen Klicks wieder zurück zu spielen.

PS
Das soll jetzt kein Rant gegen den ESXi bzw. Werbung für QNAP sein.
Aber der ESXi ist für eine so überschaubare Anzahl von Arbeitsplätzen als Virtulisierungslösung imho ein bissl mit Kanonen auf Spatzen geschossen.
Ich halte Virtualisierung immer noch für deutlich besser, als die Systeme direkt auf der Hardware laufen zu lassen, aber für KMUs gibt es da inzwischen
bessere/einfachere Lösungen.