Hallo zusammen, mal eine einfache und blöde Frage: Wie teste ich die Speicherriegel im laufenden System? Distro ist Debian, obendrauf OMV. Mir ist klar Memtest86, booten, warten, fertig. Aber, es ist ein großes NAS, im Produktivbetrieb, mit homes und trallala. Es müssen jegliche Standzeiten vermieden und reduziert werden. Daher wäre es praktisch das ganze im laufenden Betrieb zu erledigen - soweit möglich. Die syslog wirft mir jede Menge recoverable und unrecoverable Errors vom ECC-RAM. Mit jeweiliger Adresse. Nur welcher Riegel es ist, sagt er natürlich nicht :) Schon mal Danke für die Ideen.
:
Bearbeitet durch User
Drago S. schrieb: > Aber, es ist ein großes NAS, im Produktivbetrieb, Einen kompletten Satz Riegel bestellen, warten bis die geliefert sind, NAS runterfahren, alle RAM-Riegel austauschen, wieder hochfahren, alte Riegel in die Tonne, glücklich sein. Ist billiger als alles andere.
Experte schrieb: > NAS runterfahren, alle RAM-Riegel austauschen, wieder hochfahren Ja, das wäre Plan B, an einem Samstag Nachmittag.
Beitrag #7169357 wurde vom Autor gelöscht.
Du hast Speicherfehler und benutzt das System weiterhin produktiv? Irre!
Onkel Ted schrieb: > Irre! ...sind die anderen. Sie wurden gewarnt. Ich habe vorsorglich Plan C eingeleitet: heute einen Spiegelserver aufgesetzt, der synced schon fleißig :)
Drago S. schrieb: > Onkel Ted schrieb: > >> Irre! > > ...sind die anderen. Sie wurden gewarnt. > Ich habe vorsorglich Plan C eingeleitet: heute einen Spiegelserver > aufgesetzt, der synced schon fleißig :) Aus dem Backup hoffe ich doch! Du hast einen Server mit Speicherfehler. Dessen Daten sind nicht zu trauen!
Ne, jetzt mal im Ernst: gibt es irgendein Paket oder Script, welches das RAM, Zelle für Zelle locked und dann ausführlich durchcheckt? Zeit spielt ja keine Rolle.
Drago S. schrieb: > Nur welcher Riegel es ist Dann tausche im Zweifel alle, damit es keine zeitlichen Probleme gibt. Kranker RAM kann sehr tückisch sein. Wenn Du z.B. eine Socke mit Loch hast, tritt der sichtbare "Fehler" je nach Fuß verschieden auf. Bei RAM kommen jedoch noch zeitkritische Fehler hinzu, die selbst bei langsamen Tests noch nicht auffallen müssen. Deswegen ist ein einfaches Testprogramm, was nur Zellen mit FF od. 00 füllt noch lange nicht voll aussagefähig. Selbst Memtest86 muß nicht beim 1. Durchlauf schon Fehler zeigen, da es u.a. ein zeitlicher Unterschied ist, ob man Befehle oder nur Daten holt.
Drago S. schrieb: > Ne, jetzt mal im Ernst: gibt es irgendein Paket oder Script, > welches das RAM, Zelle für Zelle locked und dann ausführlich > durchcheckt? Zeit spielt ja keine Rolle. Kommt auf viele Faktoren an. Zum Beispiel ob EFI aktiv ist. https://wiki.ubuntuusers.de/memtest/ https://askubuntu.com/questions/343114/how-to-check-for-errors-in-ram-via-ubuntu Eine Anwendung kann schon lange nicht mehr einfach so gezielt Speicherbereiche prüfen. https://linux-audit.com/linux-aslr-and-kernelrandomize_va_space-setting/ Und so wirst du halt 2/4 Riegeln entfernen müssen, einen memtest durchlaufen lassen und dann entsprechend die Riegel tauschen.
oszi40 schrieb: > Wenn Du z.B. eine Socke mit Loch > hast, tritt der sichtbare "Fehler" je nach Fuß verschieden auf. Hehe das ist lustig aber wahr, muss ich mir merken :) Mal zum Verständnis: Eine Datei wird auf das Share des NAS geschoben. Es landet zunächst im Transfer-Cache, sprich RAM. Dann wird es Häppchenweise an den Diskcontroller geschickt, welcher es auf der Platte verteilt. Stimmt das soweit? Wenn nun eine Zelle des RAM defekt ist, nicht durch ECC korrigiert werden konnte, was passiert dann? Meldet der Sharingdienst ergo Samba/nfs nicht einen Transferfehler an den client? Wonach das Client-OS wiederholt sendet?
Deine Frage ist nicht einfach zu beantworten, da Fehler im RAM stets verschieden Folgen haben können. Deswegen schnell tauschen.
oszi40 schrieb: > Deine Frage ist nicht einfach zu beantworten, da Fehler im RAM stets > verschieden Folgen haben können. Deswegen schnell tauschen. Ja, der RAM ist bestellt. Mehr als drinnen war. Ich versuche morgen einen Lieferanten in der Gegend zu finden, zwecks Abholung. Ansonsten dachte ich, gleich in der früh, die homes und andere Schreib-Shares zu sperren bzw. auf den Spiegel umzuleiten. Ich weiss bis dato noch nicht einmal ob es die Operation vom OS auslösen oder die Share-Transferzugriffe. Die obige Frage war eher gemeint ob ein erkannter und vermurkster Inhalt an den Diskcontroller durchgereicht wird oder nicht. Onkel Ted schrieb: > https://askubuntu.com/questions/343114/how-to-check-for-errors-in-ram-via-ubuntu Vielen Dank, Onkel Ted. Das sieht schon mal gut aus und geht in die Richtung Live-Test. Ich habe es mal hier angeworfen...
1 | mratix@crolat-e6540(rw):~$ sudo memtester 1024 5 |
2 | memtester version 4.3.0 (64-bit) |
3 | Copyright (C) 2001-2012 Charles Cazabon. |
4 | Licensed under the GNU General Public License version 2 (only). |
5 | |
6 | pagesize is 4096 |
7 | pagesizemask is 0xfffffffffffff000 |
8 | want 1024MB (1073741824 bytes) |
9 | got 1024MB (1073741824 bytes), trying mlock ...locked. |
10 | Loop 1/5: |
11 | Stuck Address : ok |
12 | Random Value : ok |
13 | Compare XOR : ok |
14 | Compare SUB : ok |
15 | Compare MUL : ok |
16 | Compare DIV : ok |
17 | Compare OR : ok |
18 | Compare AND : ok |
19 | Sequential Increment: ok |
20 | Solid Bits : ok |
21 | Block Sequential : ok |
22 | Checkerboard : ok |
23 | Bit Spread : ok |
24 | Bit Flip : ok |
25 | Walking Ones : ok |
26 | Walking Zeroes : ok |
27 | 8-bit Writes : ok |
28 | 16-bit Writes : ok |
So habe ich mir das Testergebnis schon vorgestellt! Einfach Daten verschoben, kein zeitlicher Stress und noch kein RND-Test bisher.
Das wichtigste wurde schon genannt. Dein Test ist auch quatsch, oder hast du nur 1 GB RAM? Woher soll das System wissen was richtig und falsch ist? Bitflips können auch wieder gültige Prüfsummen (nicht nur im ECC) haben. Den Daten ist nicht zu trauen, dem System erst recht nicht. Wurde ja schon genannt. Du weißt ja, dass RAM (oder noch mehr) defekt ist, was willst du prüfen?
Der Test ist auf meiner Maschine, nicht auf der betroffenen. Natürlich ist hier alles OK :) Ähm eins sollte man mit dem memtest nicht machen: den gesamten Speicherbereich angeben. Sobald er an entsprechende Bereiche kommt, killt er riegeros die laufenden Apps, Sessions und alles :)
Ihr traut euren Daten nicht, nur weil es auf Interfaces Fehler gibt? Dann guckt euch mal die Spec diverser Interfaces an. Da gibt es dauernd Bitfehler. Ja, auch bei dir. Trotzdem kannst du den Daten trauen, denn da gibt es auf so ziemlich jeder Schicht eine Fehlererkennung und oft auch Fehlerkorrektur. Bei PCIe ist die BER kleiner 10^-12. Bei PCIe Gen4 mit 16GBit/s sind das alle 500s ein Bitfehler. Klingt nach wenig, aber mit vielen Lanes zu GPU, SSD, Ethernet, Thunderbolt ist man da schnell bei mehreren Fehlern/Minute. Und das ist nur ein Interface. In den Geräten geht es noch viel fehlerhafter zur Sache. SSDs mit TLC sind quasi dauernd am korrigieren und aussondern defekter Blöcke. Funktioniert trotzdem, der Benutzer merkt davon nichts. SR schrieb: > Woher soll das System wissen was richtig und falsch ist? Bitflips können > auch wieder gültige Prüfsummen (nicht nur im ECC) haben. Ja, können sie. Ist nur statistisch sehr unwahrscheinlich.
Drago S. schrieb: > Die syslog wirft mir jede Menge recoverable und unrecoverable Errors vom > ECC-RAM. Mit jeweiliger Adresse. Nur welcher Riegel es ist, sagt er > natürlich nicht :) So natürlich nicht ist das nicht. Eigentlich sollte eine Machine Check Exception genau das zeigen. Ist das richtige edac_mce-Modul geladen?
Gustl B. schrieb: > Ihr traut euren Daten nicht, nur weil es auf Interfaces Fehler gibt? Thema verfehlt. Es geht hier um RAM.
Drago S. schrieb: > Die syslog wirft mir jede Menge recoverable und unrecoverable Errors vom > ECC-RAM. Mit jeweiliger Adresse. Nur welcher Riegel es ist, sagt er > natürlich nicht :) Sagt das nicht der Schaltplan? also welche CS-leitung an welchen Riegel geht?! Und irgendwo gibt es eine Zuordnung Adresse CS-Leitung, such mal nach memory map.
Drago S. schrieb: > Aber, es ist ein großes NAS, im Produktivbetrieb, mit homes und > trallala. Es müssen jegliche Standzeiten vermieden und reduziert werden. Warum ist ein System mit solchen Anforderungen nicht hochverfügbar ausgelegt?
Kiffer schrieb: > Warum ist ein System mit solchen Anforderungen nicht hochverfügbar > ausgelegt? Weil es noch keinen Zwischenfall gab. Nun ist genau der richtige Zeitpunkt, es einzukippen. So, ich habe nun das NAS auf den Spiegel umgeleitet. Ich hoffe der DNS macht mit. Irrtümer und andere Fehlläufer landen auf auf RO shares.
oszi40 schrieb: > So habe ich mir das Testergebnis schon vorgestellt! Einfach Daten > verschoben, kein zeitlicher Stress und noch kein RND-Test bisher. Eben, so einen Test kannste dir in den A* schieben. Auch von der Laufdauer her. ECC fehler treten eher selten auf, da sollte der Test schon ne Woche/Monat durch laufen. https://www.heise.de/newsticker/meldung/Hauptspeicherfehler-sehr-viel-haeufiger-als-bisher-angenommen-828883.html
Drago S. schrieb: > Kiffer schrieb: >> Warum ist ein System mit solchen Anforderungen nicht hochverfügbar >> ausgelegt? > Weil es noch keinen Zwischenfall gab. Nun ist genau der richtige > Zeitpunkt, es einzukippen. Bitte verzeih' meine ungefragte Einmischung, aber wenn so etwas auftritt, ist es immer eine Folge von Problemen, die dringend gelöst werden müssen. Aus meinen Erfahrungen kenne ich da vor allem zwei Möglichkeiten, und beide sind übel. Die erste Möglichkeit ist, daß die Admins die Kritikalität des Systems schlichtweg übersehen haben. In solchen Fällen sollte ein derartiger Vorfall (nach Behebung der Fehler, natürlich) Anlaß zu sofortigem Handeln geben. Ein möglicher Ansatz wäre, alle vorhandenen Systeme in einer Liste aufzuführen und dann für jedes System im Wesentlichen die Frage zu klären, wie kritisch die Verfügbarkeit des Systems ist -- zum Beispiel anhand der Frage, wieviele Mitarbeiter zwingend auf die Verfügbarkeit des Systems angewiesen sind und nicht mehr arbeiten können, wenn es ausfallen sollte. Wichtig ist es dabei auch, Abhängigkeiten der Systeme zu berücksichtigen. Diese Betrachtung(en) sollten ordentlich dokumentiert und in regelmäßigen Abständen wiederholt und aktualisiert werden. Die zweite Möglichkeit ist, daß die Kritikalität des Systems von den Admins zwar erkannt und kommuniziert wurde, die Einrichtung entsprechender Gegenmaßnahmen aber vom Management abgeschmettert wurde. Dazu paßt die lapidare Erklärung, daß bisher schließlich noch nichts geschehen sei. Das wäre allerdings ein Ausdruck mangelnden Vertrauens der Managementebene in die Systemadministration. Solch ein Mangel an Vertrauen der Führungsebene in die Mitarbeiter ist ein gravierendes Problem in der Organisation und sollte so schnell und so gründlich wie möglich behoben werden. Beim hier vorliegenden Vorfall bietet sich ein guter Anlaß, dem Management seinen Fehler so lange, so deutlich und so gepflegt unter die Nase zu reiben, bis es anfängt, den Aussagen seiner Admins zu vertrauen. (Dabei können ein paar Stunden Ausfall die Argumente der Admins enorm stärken -- während es andererseits kontraproduktiv sein kann, maximale Anstrengungen zur Behebung des Problems zu betreiben, denn dann ist die Argumentation des Managements beim nächsten Mal nämlich wieder die bekannte: "bisher ist ja nichts Schreckliches passiert"... flöt) Am Ende möchte ich gerne kurz darauf hinweisen, daß ich persönlich mittlerweile von hochverfügbaren Lösungen Abstand nehme, wo es geht, und stattdessen lieber auf COTS-Cluster setze. Im Falle Deiner Dateiserver könnte das beispielsweise mit drei bis fünf billigen Pizzaschachteln und GlusterFS, CEPH oder Ähnlichem gehen. Damit sind einerseits die Hochverfügbarkeit durch Redundanz, sowie gleichzeitig die Verteilung der Last und die Skalierbarkeit durch Sharding sichergestellt. Leider sind solche Lösungen nicht in allen Bereichen möglich. Übrigens wäre bei einem Umstieg auf ein verteiltes System die Investition ins NAS dennoch nicht verloren, das könnte nach der Migration zum Backup oder zur Langzeitarchivierung weitergenutzt werden.
Drago S. schrieb: > Die syslog wirft mir jede Menge recoverable und unrecoverable Errors vom > ECC-RAM. Gratuliere, Du schreibst also fleißig weiter Lottozahlen auf das NAS. Sofort abschalten wäre das einzig sinnvolle. Drago S. schrieb: > Es müssen jegliche Standzeiten vermieden und reduziert werden. Dann kaufe ein neues NAS und hoffe, daß das Backup noch von vor dem Fehler ist.
oszi40 schrieb: > Drago S. schrieb: >> Nur welcher Riegel es ist > > Dann tausche im Zweifel alle, damit es keine zeitlichen Probleme gibt. Nee, im "Zweifel" gleich das gesamte System (motherboard + Riegel) tauschen. Fehler im Memory-System können auch von der Stromversorgung (C-Alterung) oder Kontaktleiste (mehr Impedanz durch Korresion) herrühren, Modultausch würde in diesem Fall nichts ändern. Solche Problemfälle kann man mit Traffic-verringerung mildern, dann muss die Stromversorgung nicht ständig Stromimpulse schicken. Mehr Latencies in das Speicher-Taktschema einfügen kann auch helfen, allerding ist fragwürdig ob das ohne Reboot funktioniert. Schau mal, ob im Log was zur Spannung am Riegel steht, manchmal ist Unterspannung dort die Ursache, die Toleranz ist gerne lediglich 5%.
Ohje, das bläht sich wieder auf... Also, ich bin weder der verantwortliche, noch der Admin. Nur gerade die Urlaubsvertretung seines. Auch seiner einer hat Schwierigkeiten die Ideen in Anforderungen beim IT-Management durchzusetzen. Punkt. Ich bin einfach nur derjenige, der in ein Problem springt und sofort an der Fehlerbehebung bzw. Lösung arbeitet, während alle anderen noch Besprechungstermine vereinbaren. Natürlich könnte ich locker von einem Jahrzent IT-Erfahrungen propagandieren, was ich jedoch gerne unter den Tisch fallen lasse - da ich aus Gründen die IT-Branche verlassen habe und mich anderen Zweigen widme. Soweit zum Standpunkt. Das NAS wurde ebenso wenig vom Admin angeschafft, sondern vom ehemaligen IT-Supporter bzw. Dienstleister. Nun ist der RAM hinüber, da muss ein neuer rein. Habe ich bestellt. Zur vorsorglichen Schadensbegrenzung habe ich einen kurzfristigen Ersatz geschaffen. Backups sind auch vorhanden. Ab kommender Woche darf ich mich wieder meinen Aufgaben widmen. Bitte keine weiteren Prügel. Danke.
:
Bearbeitet durch User
MaWin schrieb: > Gustl B. schrieb: >> Ihr traut euren Daten nicht, nur weil es auf Interfaces Fehler gibt? > > Thema verfehlt. Es geht hier um RAM. Auch RAM hat ein Interface. Mit geringem Signal Swing, hoher Bitrate, oft eher langen Leitungen und bei den DIMMs sogar mit Steckverbinder dazwischen. Da wird Signalintegrität garantiert nie ein Problem sein. Die Speicherbausteine haben daher auch nur aus Spaß so viel Fehlerbehandlung eingebaut genauso wie die CRC bei der Übertragung. Siehe: https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/dram/ddr4/8gb_ddr4_sdram.pdf?rev=74679247a1e24e57b6726071152f1384#G5.3104862 (Zur Fehlervermeidung gibt es dann noch das ganze Training, die Kalibration der Terminierung und (Hard) Post Package Repair.) Es passieren ständig Fehler. Aber schon die unteren Schichten haben Methoden um Fehler zu erkennen und zu korrigieren. Davon bekommt man nichts mit und muss sich auch keine Sorgen machen. Tauscht du deine Netzwerkkarte wenn da mal ein kaputtes Paket reinkommt und neu angefragt werden muss?
Drago S. schrieb: > Ich bin einfach nur derjenige, der in ein Problem springt und sofort an > der Fehlerbehebung bzw. Lösung arbeitet, während alle anderen noch > Besprechungstermine vereinbaren. Natürlich könnte ich locker von einem > Jahrzent IT-Erfahrungen propagandieren, > Nun ist der RAM hinüber, da muss ein neuer rein. Habe ich bestellt. > Zur vorsorglichen Schadensbegrenzung habe ich einen kurzfristigen Ersatz > geschaffen. Backups sind auch vorhanden. Nein, mit der Auslösung einer Bestellung ist kein einziges Problem gelöst. Nein, es nicht klar, das tatsächlich 'nur' der rAM oder ein einzelner Riegel "hinüber" ist. Nein, es nicht sicher ob das Backup konsistent und damit brauchbar ist. Nein, mit einen Spiegel-server begrenzt man den aktuellen Schaden nicht, man dupliziert ihn. Nein, mit "10 Jahren IT-Erfahrung" hat man keine Gewähr bei erstmalig aufgetretenen Problemen ädequat umzugehen, insbesonders nicht als "Urlaubsvertretung".
Wo soft endet beginnt hard schrieb: > ... Also was ist dein Vorschlag zur Lösung des Problems? Er hat nunmal nur das Backup. Das alles stammt nicht von ihm, hat er nicht zu verantworten. Er macht doch in seiner Situation das Richtige. Ist maximale Paranoia angebracht? Was hat das für Konsequenzen? Allen Benutzern sagen, dass ihre Daten Müll sind? Oder gleich vorsorglich alles löschen weil manche Nutzer bestimmt auch diese möglicherweise korrupten Daten weiter nutzen würden?
Gustl B. schrieb: > Wo soft endet beginnt hard schrieb: >> ... > > Also was ist dein Vorschlag zur Lösung des Problems? Steht oben: Traffic minimieren, Timing am RAM entspannen, weitere Fehlerquellen durch analyse aller logs aus-/einschliess, Board und Speicher wechseln. Und bei Hochverfügbarkeitssystem sollte man eigentlich sofort ein Reservesystem aktivieren und das auffällig system schnellsten aus dem Verkehr nehmen - auch wenn das Leistungsverluste bedeuten sollte. > Er hat nunmal nur das Backup. Das alles stammt nicht von ihm, hat er > nicht zu verantworten. Er macht doch in seiner Situation das Richtige. Nja, fürr mich sieht das doch stark nach Cargo-Kult aus: man macht das übliche (die billigste Variante des Austausches) ohne die tatsächliche Ursache und deren Auswirkung konkret bestimmen zu können. > Ist maximale Paranoia angebracht? Was hat das für Konsequenzen? > Allen Benutzern sagen, dass ihre Daten Müll sind? Oder gleich > vorsorglich alles löschen weil manche Nutzer bestimmt auch diese > möglicherweise korrupten Daten weiter nutzen würden? Er hat doch die logs zu welchen Zeitpunkt welche Adressen Probleme zeigen. Daraus kann man zusammen mit der access/modify time aus dem filesystem, mögliche Korrupte Daten auf einzelne Datein eingrenzen und deren "owner" bitten eine Konsistenzcheck laufen zu lassen.
Wo soft endet beginnt hard schrieb: > Und bei Hochverfügbarkeitssystem sollte man eigentlich sofort ...auch etwas Misstrauen haben. Es wäre nicht der erste Fall, wo trotzdem etwas schief geht oder hängt, weil es eine gemeinsame Ursache gab. :-)
oszi40 schrieb: > Wo soft endet beginnt hard schrieb: >> Und bei Hochverfügbarkeitssystem sollte man eigentlich sofort > > ...auch etwas Misstrauen haben. Den Psychologenbegriff "Misstrauen" ersetzend, spricht mensch im Technischen wohl besser vom "kalkulierten Risiko". Und "Mitigation" um dessen Auswirkungen zu mindern. https://en.wikipedia.org/wiki/Mitigation Dazu hat man im Werkzeukasetn "redundante Systeme", "cold/warm/hot standby", ... und diverse Verfahren/Checklisten des Systemengineering um kritische Stellen wie die angesprochenen shared ressources zu finden.
Drago S. schrieb: > Nur welcher Riegel es ist, sagt er > natürlich nicht Ist wenigstens das Fabrikat bekannt und die Aufteilung? (eventuell haben die Hersteller brauchbare Werkzeuge) Man könnte zumindest auch noch schauen, wie weit man mit "SiSoft Sandra Linux" in der Suchmaschine kommt. Fehler im Ram produzieren nicht nur fehlerhafte Datenlandschaften, sondern auch Abstürze. D.h. die Gefahr der Stilllegung ist sowieso recht groß. Es kommt noch schlimmer: Man kann die fehlerhaften Daten aus diesen Gründen nicht mehr nutzen und müsste zusätzlich schauen, welche Backups noch unproblematisch sind. Sowohl dieses, wie auch die Wahrscheinlichkeit des Ausfalls könnte man versuchen, herauszuarbeiten.
Guten morgen zusammen, Natürlich habe ich logfiles, mit den genauen Adressen. Wenn ich sie hier posten würde, wäre das nur unnötiges und zus. Futter. Ich habe mir eben 3 aufgetretene Fehler genauer angeschaut. Dir non-recoverable Errors. Die Datei wurde zu 100% (md5) richtig geschrieben. Auch das zurücklesen gab keine Unterschiede. Ebenso wenig konnte ich weder Gwschwindigkeitseinbußen noch Wiederholungstranfers feststellen. Das wäre ein interresanter Punkt für die weiteren Diskussionen.
:
Bearbeitet durch User
@Drago S. vor Corona, als wir noch an physischen Racks gearbeitet haben, jetzt steckt alles in der Cloud, hatten wir DELL und HP Systeme am Laufen. Bei diesen hast Du immer die Lage der betroffenen RAM-, CPU-, NIC-, NT-, Lüfter-Modue im Log gemeldet bekommen. Deswegen vermute ich, dass bei Dir günstigere HW eingesetzt wird, wenn Dir diese Info's fehlt. Das hat zwar die Probleme nicht verhindert, aber diese wesentlich schneller und gezielter lösen lassen. Die namhaften Hersteller haben/hatten Diagnose-Module in den Systemen verbaut, die bei laufendem Betrieb die Probleme mit entsprechenden Tools gelistet haben (iDRAC, HPSIM, etc.). Entsprechend dieser Meldungen konnte man selber Hand anlegen oder hat den Service gerufen, wenn das Problem gravierender war. Wir waren auch ständig am Kämpfen gute Hardware zu organisieren und den höheren Preis zu rechtfertigen. Das war schon bei den Racks ein Problem. Ein Hersteller wie Rittal hat entsprechende Preise und die konnten sich durchaus mit den Wert des Reckinhalts messen. Soweit mein Kommentar zu dem Problem. Markus
Wo soft endet beginnt hard schrieb: > Dazu hat man im Werkzeukasetn "redundante Systeme", "cold/warm/hot > standby", ... und diverse Verfahren/Checklisten des Systemengineering um > kritische Stellen wie die angesprochenen shared ressources zu finden. Auch ein Cluster hängt manchmal. Dein Werkzeugkasten in allen Ehren. Fakt ist, dass es Millionen PCs gibt, wo Erfahrung gesammelt wurde, die Anzahl von Clustern und hochverfügbaren Systemen jedoch "etwas" geringer ist. Dem zufolge bist Du auf wenige verfügbare Fachleute angewiesen. Das soll aber nicht heißen, dass diese Technik schlechter ist. Man sollte nur frühzeitig wissen, wie man Fehler beheben kann!
Nach ein paar internen Rückfragen bekam ich einige knappe Antworten zu dem warum-wieso-weshalb das Backup vernachlässigt wurde. Ich kürze es mal auf das nötigste: Eine Komplettumstellung der Datenhaltung ist bereits im Gange. Das ganze soll final in die Cloud. Ein lokales, also betrieblich internes Backup soll nicht mehr oder nur noch proforma bestehen. Falls 2) dann nur damit "alle Desaster Möglichkeiten" ausgeschöpft wurden. In Kurzform: Die Götter entbinden sich von allen Verantwortlichkeiten. Für mein Engagement bekomme ich nächste Woche das betroffene NAS (HP Proliant Microserver Gen.?) und noch ein Reserve NAS (QNAP TS-469U) geschenkt und darf es behalten. Mit dem ersten werde ich dem RAM-Chaos (keine Datenfehler trotz RAM-Fehler) auf den Grund gehen. Der dafür neu bestellte Speicher DDR4-ECC wir eingezogen ggf. bekomme ich davon einen 8GB Riegel.
:
Bearbeitet durch User
Also wenn es "unrecoverable errors" im RAM gibt, ist ein sofortiger Absturz der Kiste das beste, was passieren kann. Wenn die Mühle mit dem defekten RAM weiterläuft, kann man sich ab diesem Zeitpunkt nicht mehr sicher sein, daß keine Daten durch gekippte Bits verfälscht wurden. Die Datenintegrität ist ab diesem Punkt im Arsch und lässt sich nur zuverlässig durch ein Backup aus einer "Zeit davor" wiederherstellen. Zur Hardware: Normalerweise zeigen die Kisten den problematischen Speicherriegel an. Manche Server haben LEDs dafür an der Front, andere direkt auf dem Mainboard, bei Blade-Systemen gibts die Info normalerweise über ein Diagnose-Interface. Allerdings ist eine RAM-Bestückung meistens nicht so teuer wie produktive Daten auf dem Server oder die zuverlässige Verfügbarkeit des Servers. Wenn man es richtig machen will: komplette RAM-Bestückung durch einen bekannt intakten Satz austauschen, danach kann man sich Gedanken machen, wie man den problembehafteten Satz testet und das defekte Modul findet. Beim Speichertest kann man auch rabiat sein und ihn z.B. 10% übertakten. Wenn er das sagen wir 24 Stunden fehlerlos übersteht, ist die Wahrscheinlichkeit sehr hoch, daß er unübertaktet sehr zuverlässig funktioniert. Wenn sich Fehler zeigen, ist daß ein Zeichen dafür, daß der Speicher bei 100% Takt auch schon nicht mehr weit von seiner Grenze entfernt ist.
Wo soft endet beginnt hard schrieb: > https://www.heise.de/newsticker/meldung/Hauptspeicherfehler-sehr-viel-haeufiger-als-bisher-angenommen-828883.html Es lohnt sich auch, die Kommentare zu lesen. So als Faustregel könnte man sich merken, Qualität kaufen, ordentlich kühlen, und Tests mit viel größeren Datenaufkommen machen - also den Arbeitsspeicher ordentlich arbeiten lassen. Für das Management würde ich die Challenger-Katastrophe als Argumentoption in Erwägung ziehen. Hier war das Management sogar selbst technisch gesehen hochqualifiziert. Und trotzdem ist gewissermaßen das Feingefühl für Sicherheit verloren gegangen. Wenn es geht, sollte man sich ein Video mit der Katastrophe zusammen mit dem Management anschauen. Wenn ich selber Probleme mit Ram-Bausteinen hatte, dann war das i.d.R. beim Aufrüsten. Entweder war das Mainboard nicht kompatibel, oder eben die Rambausteine waren nicht gut (oft vom Gebrauchtmarkt besorgt, weil es keine aktuellen Speicherriegel für System X mehr zu kaufen gab). Einen ganz ähnlichen Effekt kann man bei Disketten beobachten. Man bekommt zwar noch welche - aber funktionieren wollen die nur mit Glück - falls überhaupt. Ziemlich miese Qualität.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.