Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Konstant Daten schreiben - was geht schief
Konstant Daten schreiben - was geht schief
Hallo ihr,
ich habe ein Problem, das mir dauerhaft eine Platte am rödeln ist, obwohl alles im idle läuft. Bevor ich um Hilfe schreie, beschreibe ich meine Situation genauerer.
Also:
Ich habe eine Migration & Erweiterung meines RAID 5 durchgeführt. Nachdem aus 3x1TB schrott-Fesplatten 4x4TB Enterprise Platten wurden ist nun das Problem, das nur eine einzige Platte am rödeln ist und die restlichen halt nur bei einem Aufruf.
Es ist genau die Platte, die ich später zum erweitern des Raid 5 genommen habe. Also 3x4TB und dann diese 4TB dazu.
Um ein defekten Raid Controller (HP SmartArray P420) auszuschließen nenne ich ein Grund:
Sobald sämtliche VM's ausgeschaltet sind, ist ruhe.
Schalte ich auch nur irgendeine der Maschinen wieder ein, geht's wieder munter weiter.
Hat dort einer eine Idee?
Ist Esxi falsch geconft? Kann man daran etwas drehen?
Fakt ist: Egal welche VM ich von 6 vorhandenen starte, sobald eine eingeschaltet wird, geht's los und hört net wieder auf. Das schließt jetzt aus, das die VM selbst das Ärgernis verursacht. Und es ist auch nur eine (!?????) Platte aus dem Raid 5. Die mit dem das Raid 5 erweitert worden ist.
Bitte nennt alles - sei es noch eine so "schräge" Idee.
Gruß & Danke
ich habe ein Problem, das mir dauerhaft eine Platte am rödeln ist, obwohl alles im idle läuft. Bevor ich um Hilfe schreie, beschreibe ich meine Situation genauerer.
Also:
Ich habe eine Migration & Erweiterung meines RAID 5 durchgeführt. Nachdem aus 3x1TB schrott-Fesplatten 4x4TB Enterprise Platten wurden ist nun das Problem, das nur eine einzige Platte am rödeln ist und die restlichen halt nur bei einem Aufruf.
Es ist genau die Platte, die ich später zum erweitern des Raid 5 genommen habe. Also 3x4TB und dann diese 4TB dazu.
Um ein defekten Raid Controller (HP SmartArray P420) auszuschließen nenne ich ein Grund:
Sobald sämtliche VM's ausgeschaltet sind, ist ruhe.
Schalte ich auch nur irgendeine der Maschinen wieder ein, geht's wieder munter weiter.
Hat dort einer eine Idee?
Ist Esxi falsch geconft? Kann man daran etwas drehen?
Fakt ist: Egal welche VM ich von 6 vorhandenen starte, sobald eine eingeschaltet wird, geht's los und hört net wieder auf. Das schließt jetzt aus, das die VM selbst das Ärgernis verursacht. Und es ist auch nur eine (!?????) Platte aus dem Raid 5. Die mit dem das Raid 5 erweitert worden ist.
Bitte nennt alles - sei es noch eine so "schräge" Idee.
Gruß & Danke
Re: Konstant Daten schreiben - was geht schief
Sind das 512e oder 4K-Platten und kann der Controller damit umgehen?
Wie genau hast du den Tausch und die Erweiterung durchgeführt?
Erste Anlaufstelle ist das Eventlog des Controllers - da sollte etwas zu finden sein.
Wie genau hast du den Tausch und die Erweiterung durchgeführt?
Erste Anlaufstelle ist das Eventlog des Controllers - da sollte etwas zu finden sein.
Re: Konstant Daten schreiben - was geht schief
Wie sieht es denn aus, wenn bei ausgeschalteten VMs einfach nur Daten auf den Datastore geschrieben werden?
Wurde nach dem Hinzufuegen der vierten 4TB-Platte zum vorhandenen Array aus 3x 4TB ein "Resync" (in diesem Falle: Neusortieren der Daten- und Redundanz-Bloecke) des vergroesserten Arrays beobachtet? Duerfte nicht unter 1 Tag gedauert haben...
Was sagt HP als Controller-Hersteller dazu?
Wurde nach dem Hinzufuegen der vierten 4TB-Platte zum vorhandenen Array aus 3x 4TB ein "Resync" (in diesem Falle: Neusortieren der Daten- und Redundanz-Bloecke) des vergroesserten Arrays beobachtet? Duerfte nicht unter 1 Tag gedauert haben...
Was sagt HP als Controller-Hersteller dazu?
Re: Konstant Daten schreiben - was geht schief
Wurde vielleicht beim Hinzufügen die schnelle bzw. Hintergrund-Initialisierung gewählt?
Dann ist der Controller einfach noch dabei, die Checksummen und Datenblöcke auf die neue Platte zu verteilen.
(Edit: man sollte sich nicht zu lange Zeit zum Antworten nehmen, sonst schreibt jeman anderes schnelle das gleiche... )
Dann ist der Controller einfach noch dabei, die Checksummen und Datenblöcke auf die neue Platte zu verteilen.
(Edit: man sollte sich nicht zu lange Zeit zum Antworten nehmen, sonst schreibt jeman anderes schnelle das gleiche... )
-
- King of the Hill
- Beiträge: 13568
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Re: Konstant Daten schreiben - was geht schief
Neben dem bereits gesagten zur Schnell-/Hintergrundinitialisierung, stellt sich mir gerade die Frage, wieso man ein ideal performendes Raid5 aus drei Platten ein weniger performantes Verhalten aufzwingt und eine vierte Platte verbaut. Platztechnisch mag das ja ein Zugewinn sein, aber das war es dann auch schon. Je nach Grösse der zu schreibenden Daten lassen sich diese nicht in einem Rutsch auf die 3 Platten plus Parity aufteilen und müssen dann in 2 Anforderungen sowie Parityberechnung weggeschrieben werden.
Re: Konstant Daten schreiben - was geht schief
Hui, bin selten so schnell antworten gewöhnt.
Also, verbaut sind 2x seagate Ironwolf und 2x WD Red -> alles 4TB / 5xxx Upm
Meine vorgehensweise:
Eine 4TB in den noch freien einschub des Microservers Gen8 reingesopft -> neues Array -> alle Daten vom Raid 5 auf diese Kopiert.
Dann Raid 5 raus und 3 neue 4TB rein -> Raid 5 erstellt -> und innerhalb der nächsten 5min das endlose Rückkopieren von der einzelnen Platte gestartet.
Danach dann das 1er Array gelöscht -> Die freie Platte dem bestehenden Raid 5 hinzugefügt -> 1-2 VM's gestartet und dann die Transformation abgewartet.
Ende der Trafo -> Array erweitert -> VMFS erweitert und alle VM's hochgefahren.
Nun nach 2 Tagen meldet der Controller den Abschluss der Paritätserstellung.
Heute - weitere 2,5 Tage nach der Paritätsfinishmeldung - rödelt der Bock aber immer noch - auf einer Platte. Die anderen zucken mal zwischendurch, aber das ist ja normal.
Dann heute noch auf esxi 6.5 geupgraded und nichts neues zu berichten - außer das ich nun sehen kann, was bei den Festplatten vorgeht.
Dabei ist mir etwas aufgefallen: Der Bursche zeigt mir die Latenz an - und ich frage mich, wie er das ermittelt.
Indem er laufend kleine Mistdateien schreibt/liest???
(Siehe Bild)
Was ist mit der Hintergrundinitialisierung genau gemeint?
Soweit ich mich erinnere, hatte ich diese aktiviert, weil ich sonst - so meine ich in der Controller warnung gelesen zu haben - das Array erst mal nicht zur Verfügung steht, sondern erst, wenn das durch ist.
Oder betraf das die Paritätserstellung??? WTF, weiß nicht mehr genau.
Und wie lang kann denn bei der "Auslastung" meiner Platten die Initialisierung dauern? Der ist doch sicher schon seid mehr 3-4 Tagen dabei...
Also, verbaut sind 2x seagate Ironwolf und 2x WD Red -> alles 4TB / 5xxx Upm
Meine vorgehensweise:
Eine 4TB in den noch freien einschub des Microservers Gen8 reingesopft -> neues Array -> alle Daten vom Raid 5 auf diese Kopiert.
Dann Raid 5 raus und 3 neue 4TB rein -> Raid 5 erstellt -> und innerhalb der nächsten 5min das endlose Rückkopieren von der einzelnen Platte gestartet.
Danach dann das 1er Array gelöscht -> Die freie Platte dem bestehenden Raid 5 hinzugefügt -> 1-2 VM's gestartet und dann die Transformation abgewartet.
Ende der Trafo -> Array erweitert -> VMFS erweitert und alle VM's hochgefahren.
Nun nach 2 Tagen meldet der Controller den Abschluss der Paritätserstellung.
Heute - weitere 2,5 Tage nach der Paritätsfinishmeldung - rödelt der Bock aber immer noch - auf einer Platte. Die anderen zucken mal zwischendurch, aber das ist ja normal.
Dann heute noch auf esxi 6.5 geupgraded und nichts neues zu berichten - außer das ich nun sehen kann, was bei den Festplatten vorgeht.
Dabei ist mir etwas aufgefallen: Der Bursche zeigt mir die Latenz an - und ich frage mich, wie er das ermittelt.
Indem er laufend kleine Mistdateien schreibt/liest???
(Siehe Bild)
Was ist mit der Hintergrundinitialisierung genau gemeint?
Soweit ich mich erinnere, hatte ich diese aktiviert, weil ich sonst - so meine ich in der Controller warnung gelesen zu haben - das Array erst mal nicht zur Verfügung steht, sondern erst, wenn das durch ist.
Oder betraf das die Paritätserstellung??? WTF, weiß nicht mehr genau.
Und wie lang kann denn bei der "Auslastung" meiner Platten die Initialisierung dauern? Der ist doch sicher schon seid mehr 3-4 Tagen dabei...
-
- King of the Hill
- Beiträge: 13568
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Re: Konstant Daten schreiben - was geht schief
Ich vermute mal, daß ihn die 4 Platten deutlich länger beschäftigen und auch der Controller damit seine liebe Not hat. Raid5 fühlt sich am wohlsten mit 3, 5 oder 9 Platten an. Die übliche Blocksize dürfte fast unabhängig vom OS wohl 4KB sein und wie willst du die performant auf 3 Datenplatten plus Parity verteilen?
Die Frage ist sowieso, ob man bei den Plattengrössen heutzutage überhaupt noch auf Raid5 setzen sollte...
Die Frage ist sowieso, ob man bei den Plattengrössen heutzutage überhaupt noch auf Raid5 setzen sollte...
Re: Konstant Daten schreiben - was geht schief
Ich halte RAID5 für einen guten Kompromiss in kleineren Betrieben bei nicht zu vielen Platten. Das es "magic numbers" beim RAID5 gibt, ist mir persönlich neu - gibt es da Literatur? Da der Standard-Strip-Size bei RAIDs oft 64 kB ist, muss der Controller sowieso immer X mal 64 kB schreiben - auch wenn man nur 1 Bit ändert.
Nein, die wird bei den normalen Disk-I/O-Vorgängen ermittelt.
Wie du vermutest, dass das RAID schon zur Verfügung steht, wenn die Initialisierung noch läuft.
Und was sagt das Eventlog des Controllers?
Dabei ist mir etwas aufgefallen: Der Bursche zeigt mir die Latenz an - und ich frage mich, wie er das ermittelt.
Indem er laufend kleine Mistdateien schreibt/liest???
Nein, die wird bei den normalen Disk-I/O-Vorgängen ermittelt.
Was ist mit der Hintergrundinitialisierung genau gemeint?
Wie du vermutest, dass das RAID schon zur Verfügung steht, wenn die Initialisierung noch läuft.
Und was sagt das Eventlog des Controllers?
Re: Konstant Daten schreiben - was geht schief
Wo finde ich den Eventlog des Controllers? In der Weboberfläche bei 6.5?
Hab sowas schon bei 6.0 nicht gefunden... Also, weder im Client noch jetzt bei der 6.5 Weboberfläche... Logs ja, aber nichts vom Controller...
Lediglich den Status bekomme ich angezeigt - also ob Platte kaputt ist oder das Raid z.B. in Transit steckt etc...
Um jetzt z.B. herauszufinden ob der fertig mit der Paritätserstellung war, nutze ich das neustarten vom Upgrade ESXI um mal ebend im HP Storage Manager vorbei zu booten... -> In ESXI ist davon nichts zu finden...
Hab sowas schon bei 6.0 nicht gefunden... Also, weder im Client noch jetzt bei der 6.5 Weboberfläche... Logs ja, aber nichts vom Controller...
Lediglich den Status bekomme ich angezeigt - also ob Platte kaputt ist oder das Raid z.B. in Transit steckt etc...
Um jetzt z.B. herauszufinden ob der fertig mit der Paritätserstellung war, nutze ich das neustarten vom Upgrade ESXI um mal ebend im HP Storage Manager vorbei zu booten... -> In ESXI ist davon nichts zu finden...
Re: Konstant Daten schreiben - was geht schief
Das Log des Controllers ist Sache der Management-Software des Herstellers. Wie das bei PERCs ist , kann ich mangels Erfahrung nicht sagen, bei meinen LSIs lese ich das Log mit MegaCLI oder StorCLI aus.
Re: Konstant Daten schreiben - was geht schief
Hat jemand Ahnung, wie man die Firmware des Controllers Updatet? -> HP Smart Array P420
-
- King of the Hill
- Beiträge: 13568
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Re: Konstant Daten schreiben - was geht schief
Auf dieselbe Art wie Dell... Am einfachsten per CD/ISO oder du baust dir mit Rufus einen USB-Stick zusammen, wo du alle notwendigen Tools draufpackst.
Re: Konstant Daten schreiben - was geht schief
Ich wüsste nicht, das Dell ein Smart Array P420 hat...
Aber egal, Prinzip ist dasselbe. Nur HP gibt das nicht kostenlos raus. Was fürn Schwachsinn.
Hat jemand ein link zu dem ISO? oder auch nur zu dem reinen P420 Upgrade link?
Ich hatte gestern von meinem Monitoring für ein Intervall ein Hardwaresensor fault bekommen -> Eine Festplatte war kurzfristig (angeblich) komplett weg.
Das ist der Grund meines Update der Firmware - denn ein Rebuild hat der Controller danach nicht durchgeführt, wäre sie wirklich ausgefallen.
Von daher denke ich, der Controller spackt.
Zur Zeit lasse ich ihn die Stripsize verkleinern, mal sehen wie es sich danach verhält. Und in der Zwischenzeit wäre es cool, ein Firmwareupdate zu finden, was ich nach der Transfo aufspielen könnte...
Aber egal, Prinzip ist dasselbe. Nur HP gibt das nicht kostenlos raus. Was fürn Schwachsinn.
Hat jemand ein link zu dem ISO? oder auch nur zu dem reinen P420 Upgrade link?
Ich hatte gestern von meinem Monitoring für ein Intervall ein Hardwaresensor fault bekommen -> Eine Festplatte war kurzfristig (angeblich) komplett weg.
Das ist der Grund meines Update der Firmware - denn ein Rebuild hat der Controller danach nicht durchgeführt, wäre sie wirklich ausgefallen.
Von daher denke ich, der Controller spackt.
Zur Zeit lasse ich ihn die Stripsize verkleinern, mal sehen wie es sich danach verhält. Und in der Zwischenzeit wäre es cool, ein Firmwareupdate zu finden, was ich nach der Transfo aufspielen könnte...
Re: Konstant Daten schreiben - was geht schief
Also:
Nachdem ich auf 64k Stripsize bin, den Controller und alles weitere auf den aktuellsten Stand geupdatet habe fängt es wieder an
Erst einmal brauchte der Dieter 4 Tage zum ändern der Stripsize. Sonntag um 0.xx Uhr war er damit fertig.
Bis dahin war alles astrein. Dann lief es wunderbar - bis vor einer Stunde
Hat jemand eine Idee, wie man die Controller aktivität auslesen kann?
Der Controller meldet nichts mehr im Status des HP SSA - weder Paritätserstellung noch sonst was. Er ist laut Status im normalen Betrieb. Gleiches meldet ESXi und das HP ILo.
Noch eine Idee: Angenommen eine Platte ist kaputt - und zwar so, das der Raid-Controller schreiben&lesen kann, der Festplattencontroller aber irgendwie selbst nicht klar kommt.
Merkt sowas der Raid Controller?
Weil ich merke sowas ja nicht, selbst wenn der Festplattencontroller Hyroglyphen schreibt anstatt das, was der Raid-Controller will.. oder merkt der das auch?
Nachdem ich auf 64k Stripsize bin, den Controller und alles weitere auf den aktuellsten Stand geupdatet habe fängt es wieder an
Erst einmal brauchte der Dieter 4 Tage zum ändern der Stripsize. Sonntag um 0.xx Uhr war er damit fertig.
Bis dahin war alles astrein. Dann lief es wunderbar - bis vor einer Stunde
Hat jemand eine Idee, wie man die Controller aktivität auslesen kann?
Der Controller meldet nichts mehr im Status des HP SSA - weder Paritätserstellung noch sonst was. Er ist laut Status im normalen Betrieb. Gleiches meldet ESXi und das HP ILo.
Noch eine Idee: Angenommen eine Platte ist kaputt - und zwar so, das der Raid-Controller schreiben&lesen kann, der Festplattencontroller aber irgendwie selbst nicht klar kommt.
Merkt sowas der Raid Controller?
Weil ich merke sowas ja nicht, selbst wenn der Festplattencontroller Hyroglyphen schreibt anstatt das, was der Raid-Controller will.. oder merkt der das auch?
Re: Konstant Daten schreiben - was geht schief
sleepless hat geschrieben:Noch eine Idee: Angenommen eine Platte ist kaputt - und zwar so, das der Raid-Controller schreiben&lesen kann, der Festplattencontroller aber irgendwie selbst nicht klar kommt.
Merkt sowas der Raid Controller?
Das ist ein bisschen in sich widersprüchlich. Wenn die Festplatte nach oben zum RAID-Controller "alles bestens" meldet, dann geht der RAID-Controller natürlich davon aus, dass das stimmt. Wenn der onboard-Controller der Festplatte dann nur Mist baut, kann der RAID-Controller davon nichts wissen. Ich halte das aber für zu stark konstruiert. Wahrscheinlicher ist, dass der RAID-Controller da etwas tut.
Re: Konstant Daten schreiben - was geht schief
Ja, er tut was.
Auffällig ist nun ganz klar: Das passiert nur im Leerlauf!
Sobald der beschäfitgt wird ist vorbei mit der ratterei und er konzentriert sich merklich auf das, was er machen soll.
Nun hat der Controller eine Einstellung: Oberflächenanalyse.
Der start ist nach dem Idle verzögerbar.
Was macht das Teil dabei?
Smart-Status abfragen??
Gibt's vielleicht mal eine ausführliche Doku zu dem P420?
Auffällig ist nun ganz klar: Das passiert nur im Leerlauf!
Sobald der beschäfitgt wird ist vorbei mit der ratterei und er konzentriert sich merklich auf das, was er machen soll.
Nun hat der Controller eine Einstellung: Oberflächenanalyse.
Der start ist nach dem Idle verzögerbar.
Was macht das Teil dabei?
Smart-Status abfragen??
Gibt's vielleicht mal eine ausführliche Doku zu dem P420?
Re: Konstant Daten schreiben - was geht schief
Im Englischen heißt das Data Scrubbing.
Hierbei geht der Controller im Hintergrund die Datenbereiche durch und überprüft, ob die Checksummen noch korrekt sind und somit z.B. defekte Blöcke im Voraus zu erkennen
Hierbei geht der Controller im Hintergrund die Datenbereiche durch und überprüft, ob die Checksummen noch korrekt sind und somit z.B. defekte Blöcke im Voraus zu erkennen
Re: Konstant Daten schreiben - was geht schief
Bei Dell nennt sich das glaube ich Patrol Read.
bei einem Raid 4x4TB kann das wohl dauern. Und wenn der das alle 2 Wochen macht und das selbige einige Tage... Dann kann das schon den Eindruck erwecken, dass das immer läuft.
Läuft der Host denn dauerhaft? Nicht das du den auch noch regelmäßig ausschaltest und das Überprüfen wird dann immer neu gestartet.
bei einem Raid 4x4TB kann das wohl dauern. Und wenn der das alle 2 Wochen macht und das selbige einige Tage... Dann kann das schon den Eindruck erwecken, dass das immer läuft.
Läuft der Host denn dauerhaft? Nicht das du den auch noch regelmäßig ausschaltest und das Überprüfen wird dann immer neu gestartet.
Re: Konstant Daten schreiben - was geht schief
Darf ich mal darauf hinweisen, dass es um die Frage geht, warum der Controller nur auf der dem RAID zuletzt hinzugefügten Platte herumkaut und nicht auf den anderen RAID-Membern.
-
- King of the Hill
- Beiträge: 13568
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Re: Konstant Daten schreiben - was geht schief
Entweder hat die neue Platte einen Knacks weg oder nicht nur für den Controller ist ein Raid5 mit 4 Membern suboptimal.
Wenn es nur rattert, wenn die Platten Leerlauf haben, wurde das entweder so konfiguriert oder ist ein Controller-Standardeinstellung von HPE. Hier mal ein öffentlich einsehbares PDF zum HPE Smart Array P420 Controller. Darin wird allerdings auch nur ESXi5.5 erwähnt. Entweder habe ich ein altes PDF erwischt oder das ist des Rätsels Lösung, obwohl ich das eigentlich nicht glaube.
Wenn es nur rattert, wenn die Platten Leerlauf haben, wurde das entweder so konfiguriert oder ist ein Controller-Standardeinstellung von HPE. Hier mal ein öffentlich einsehbares PDF zum HPE Smart Array P420 Controller. Darin wird allerdings auch nur ESXi5.5 erwähnt. Entweder habe ich ein altes PDF erwischt oder das ist des Rätsels Lösung, obwohl ich das eigentlich nicht glaube.
Re: Konstant Daten schreiben - was geht schief
Google hat mir bisher noch keine sehr gute Doku ausgeschmissen - HP behält sich das wohl eher dem Business gegen viel Geld vor
Es klingt jedenfalls ganz nach sanften gekratze.
Das die Festplatte schrott ist, bezweifle ich doch irgendwie - soviel Infos der Controller dort ausliest (was für mich wirklich bömische Dörfer sind) sollte der wohl mitbekommen, wenn diese Verreckt. Insbesondere mit dieser Oberflächenanalyse.
Zitat HP:
Weiß jemand, wo geschrieben steht, was welche LED zu bedeuten hat? Für den p440 hab ich ne Liste gefunden, sicher geistert doch iwo eine für meinen p420 rum...
Weil auf der Kiste eine grüne LED Kontinuierlich in einem 2Hz Takt blinkt...
Es klingt jedenfalls ganz nach sanften gekratze.
Das die Festplatte schrott ist, bezweifle ich doch irgendwie - soviel Infos der Controller dort ausliest (was für mich wirklich bömische Dörfer sind) sollte der wohl mitbekommen, wenn diese Verreckt. Insbesondere mit dieser Oberflächenanalyse.
Zitat HP:
Die Oberflächenscan-Analyse ist ein automatischer Vorgang, der im Hintergrund abläuft und
gewährleistet, dass Daten im Falle eines Laufwerksausfalls wiederhergestellt werden können. Der
Scanvorgang überprüft physische Laufwerke in fehlertoleranten logischen Laufwerken auf
beschädigte Sektoren. In RAID 5- oder RAID 6 (ADG)-Konfigurationen wird zudem die Einheitlichkeit
von Paritätsdaten überprüft.
Weiß jemand, wo geschrieben steht, was welche LED zu bedeuten hat? Für den p440 hab ich ne Liste gefunden, sicher geistert doch iwo eine für meinen p420 rum...
Weil auf der Kiste eine grüne LED Kontinuierlich in einem 2Hz Takt blinkt...
-
- King of the Hill
- Beiträge: 13568
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Re: Konstant Daten schreiben - was geht schief
Du hast doch einen HP/HPE-Server? Andernfalls könnten deine Probleme auch dadurch kommen. HP/HPE garantiert die einwandfreie Funktion immer nur in freigegebener HW. Auf einem Wald-und-Wiesen-Rechner mit zuvor funktionierendem Controller kann da bereits ein Bios-Update alles zunichte machen. Das kann zwar auch auf HP/HPE-zertifizierter HW passieren, aber dann muß der Hersteller ran und kann sich nicht rausreden.
Schau dir mal alle Platten genauer auch hinsichtlich Jumperung an, nicht das da noch was verquer ist. Das mixen von neuen 4K- und alten bzw auf 512B gejumperten Platten sollte man tunlichst vermeiden und von Schrott habe ich auch nicht gesprochen. Ich hatte selber eine WD-RE-Platte, die ohne ersichtlichen Grund und Vorwarnung nach 23h eingegangen ist, obwohl SMART auch nach dem Ausfall immer noch von einer einwandfreien Platte überzeugt war. SATA kann auch nicht prüfen, ob Daten auf dem Weg zur Platte über RAM, Controller und Kabel verändert wurden, denn sowas wurde erst bei SAS spezifiert.
Bevor du dieses Problem/Verhalten nicht gelöst hast, würde ich auch von weiteren Änderungen der Stripe-Size etc absehen. Ist der Controller ggf überhaupt für ESXi6.5 freigegeben?
Schau dir mal alle Platten genauer auch hinsichtlich Jumperung an, nicht das da noch was verquer ist. Das mixen von neuen 4K- und alten bzw auf 512B gejumperten Platten sollte man tunlichst vermeiden und von Schrott habe ich auch nicht gesprochen. Ich hatte selber eine WD-RE-Platte, die ohne ersichtlichen Grund und Vorwarnung nach 23h eingegangen ist, obwohl SMART auch nach dem Ausfall immer noch von einer einwandfreien Platte überzeugt war. SATA kann auch nicht prüfen, ob Daten auf dem Weg zur Platte über RAM, Controller und Kabel verändert wurden, denn sowas wurde erst bei SAS spezifiert.
Bevor du dieses Problem/Verhalten nicht gelöst hast, würde ich auch von weiteren Änderungen der Stripe-Size etc absehen. Ist der Controller ggf überhaupt für ESXi6.5 freigegeben?
Re: Konstant Daten schreiben - was geht schief
Jup, ein HP Server.
Jetzt musst du mich ein wenig aufklären - soll nicht provokant sein - sondern eher ein lernwilligen User aufschlauen, sodass ich mal weiter nach dem Fehler suchen kann.
Jumpering bei SATA...? Meinst du jetzt die Jumper für die 8 Pins direkt an der Platte? Soweit ich weiß, sind die Dinger für power up beim Booten oder Bus-Geschwindigkeiten etc. - also reine Hardware Geschichten - und eigentlich auch völlig überflüssig.
Was meinst du also mit 4k & 512B gejumpert?
Und zu guter letzt: Wie kommst drauf, das 4 Platten Raid5 suboptimal ist? (Kannst mir auch ein Link zu einem Artikel senden, der das mal näher erläutert)
Jetzt musst du mich ein wenig aufklären - soll nicht provokant sein - sondern eher ein lernwilligen User aufschlauen, sodass ich mal weiter nach dem Fehler suchen kann.
Jumpering bei SATA...? Meinst du jetzt die Jumper für die 8 Pins direkt an der Platte? Soweit ich weiß, sind die Dinger für power up beim Booten oder Bus-Geschwindigkeiten etc. - also reine Hardware Geschichten - und eigentlich auch völlig überflüssig.
Was meinst du also mit 4k & 512B gejumpert?
Und zu guter letzt: Wie kommst drauf, das 4 Platten Raid5 suboptimal ist? (Kannst mir auch ein Link zu einem Artikel senden, der das mal näher erläutert)
-
- King of the Hill
- Beiträge: 13568
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Re: Konstant Daten schreiben - was geht schief
Jumpering ist immer noch ein probates Mittel, Platten an unwilligen Controllern zur Zusammenarbeit zu überreden. Je nach FW-Stand kommen eben nicht alle Controller mit neuen Platten und deren 4KB-Sektorgrösse zurecht.
Bezüglich Raid5, optimaler Config und wie ich das verstehe. Der ESXi6.0 kommt meiner Info nach nicht mit 4K-Platten klar und dem ESXi muß daher das Raidvolume mit 512Byte-Sektorgrösse präsentiert werden. Übliche OS-Anforderungen werden in Grössen von 2KB, 4KB, 8KB usw getätigt. Mit 2 oder 4 Datenplatten wirst du wesentlich häufiger eine Teilung ohne Rest hinbekommen als mit 3 Datenplatten. Nimm mal an, daß 2KB an Daten weggeschrieben werden sollen. Bei 3 Datenplatten und 1 Parity könntest du 3 Blöcke a 512Byte gleich 1536Byte direkt wegschreiben, würdest dann die Parity der 3 Blöcke auf Platte 4 schreiben und den fehlenden 512Byte-Block plus Parity in einem zweiten Schreibvorgang wegschreiben. Der Controller-Cache kann dem zwar entgegen wirken, aber diesen völlig unnötigen Schreibvorgang nicht verhindern. Die Stripesize ist hier in meinen Augen auch kein Ausweg, da diese ja für Schreib- und Lese-IO zutreffend ist. Man will beim Raid5 aber gerade die performancesteigernde Wirkung ausnutzen, daß die Daten möglichst von allen Raidmitgliedern gelesen werden und das limitiert die Stripesize. Ist diese zu groß, kommen die Daten im Extremfall nur von einer Platte und auch der Verschnitt wird grösser, da mehr Nullen geschrieben und somit Blöcke belegt werden. Ist die Stripesize zu klein, werden zwar im Lesefall alle Mitglieder eingebunden, aber im Schreibfall läßt sich die Anforderung nicht optimal aufteilen. Die optimale Stripesize ist daher sowohl vom Controller als auch den verwendeten Daten abhängig und eine kleine Wissenschaft für sich, wenn man das absolute Optimum herausholen will.
Bezüglich Raid5, optimaler Config und wie ich das verstehe. Der ESXi6.0 kommt meiner Info nach nicht mit 4K-Platten klar und dem ESXi muß daher das Raidvolume mit 512Byte-Sektorgrösse präsentiert werden. Übliche OS-Anforderungen werden in Grössen von 2KB, 4KB, 8KB usw getätigt. Mit 2 oder 4 Datenplatten wirst du wesentlich häufiger eine Teilung ohne Rest hinbekommen als mit 3 Datenplatten. Nimm mal an, daß 2KB an Daten weggeschrieben werden sollen. Bei 3 Datenplatten und 1 Parity könntest du 3 Blöcke a 512Byte gleich 1536Byte direkt wegschreiben, würdest dann die Parity der 3 Blöcke auf Platte 4 schreiben und den fehlenden 512Byte-Block plus Parity in einem zweiten Schreibvorgang wegschreiben. Der Controller-Cache kann dem zwar entgegen wirken, aber diesen völlig unnötigen Schreibvorgang nicht verhindern. Die Stripesize ist hier in meinen Augen auch kein Ausweg, da diese ja für Schreib- und Lese-IO zutreffend ist. Man will beim Raid5 aber gerade die performancesteigernde Wirkung ausnutzen, daß die Daten möglichst von allen Raidmitgliedern gelesen werden und das limitiert die Stripesize. Ist diese zu groß, kommen die Daten im Extremfall nur von einer Platte und auch der Verschnitt wird grösser, da mehr Nullen geschrieben und somit Blöcke belegt werden. Ist die Stripesize zu klein, werden zwar im Lesefall alle Mitglieder eingebunden, aber im Schreibfall läßt sich die Anforderung nicht optimal aufteilen. Die optimale Stripesize ist daher sowohl vom Controller als auch den verwendeten Daten abhängig und eine kleine Wissenschaft für sich, wenn man das absolute Optimum herausholen will.
Re: Konstant Daten schreiben - was geht schief
Also, nach langem Forschen habe ich herausgefunden, das es 512e platten sind. Alle 4 Stück.
Also native 4k, die aber 512 simulieren.
ESXI 6.0 erkennt einfach keine 4k. Von daher sind es 512.
Ich habe mittlerweile so alles probiert, was sich nur ausdenken lässt - eine Lösung ist nicht greifbar.
Mittlerweile kratz er definitiv nicht nur auf einer Platte rum, es sind alle queerbeet. Ich denke, das hat er am Anfang auch gemacht, ich habe mich da nur etwas verwirren lassen, das es keine HD Activity LED gibt...
Das geschrieben wird, zeigt auch die Auswertung des Controllers - die Seagate Platten loggen nämlich schön den gesamttraffic mit und errechnen sogar den Workload... und mit 24TB/Monat bei der einen bin ich schon weit, weit, weit, weit aus über die eigentliche Nutzung hinaus geschossen...
Hat jemand eine Idee, ob es unter ESXI 6.5 eine tiefgründigere Analyse der Festplattenauslastung gibt?
Denn ich beschreibe mal den Bootvorgang:
Kiste Power Up -> leichtes Kratzen -> ESXI Boot Menü (dabei leichtes Kratzen weiterhin) -> er läd dann die Komponenten fürs Grundsystem (RUHE!!! Absolute RUHE!!!) -> Das kratzen fängt dann wie dämlich an, sobald vmbf-irgendwas geladen wird...
Bitte wirklich um jeden weiteren Rat.
BTW: Die Oberflächenanalyse ist schon seid einer Woche deaktiviert! Trotzdem keine änderung...
Also native 4k, die aber 512 simulieren.
ESXI 6.0 erkennt einfach keine 4k. Von daher sind es 512.
Ich habe mittlerweile so alles probiert, was sich nur ausdenken lässt - eine Lösung ist nicht greifbar.
Mittlerweile kratz er definitiv nicht nur auf einer Platte rum, es sind alle queerbeet. Ich denke, das hat er am Anfang auch gemacht, ich habe mich da nur etwas verwirren lassen, das es keine HD Activity LED gibt...
Das geschrieben wird, zeigt auch die Auswertung des Controllers - die Seagate Platten loggen nämlich schön den gesamttraffic mit und errechnen sogar den Workload... und mit 24TB/Monat bei der einen bin ich schon weit, weit, weit, weit aus über die eigentliche Nutzung hinaus geschossen...
Hat jemand eine Idee, ob es unter ESXI 6.5 eine tiefgründigere Analyse der Festplattenauslastung gibt?
Denn ich beschreibe mal den Bootvorgang:
Kiste Power Up -> leichtes Kratzen -> ESXI Boot Menü (dabei leichtes Kratzen weiterhin) -> er läd dann die Komponenten fürs Grundsystem (RUHE!!! Absolute RUHE!!!) -> Das kratzen fängt dann wie dämlich an, sobald vmbf-irgendwas geladen wird...
Bitte wirklich um jeden weiteren Rat.
BTW: Die Oberflächenanalyse ist schon seid einer Woche deaktiviert! Trotzdem keine änderung...
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste