Storage Betriebskonzept

[Snowi]

@Snowi Bist du noch im Urlaub

Ne, immer vergessen

Im großen und ganzen wurde hier alles erwähnt, aber 2 Sachen vermisse ich hier:
Wartungs- und Releaseplan der Soft- und Hardware
Optional:
Grobe Doku über jede Anwendung, die Zeug auf dem Storage liegen hat, also auch ggf. Storage bezogene Konfiguration der Anwendung der Kollegen (Die aber von diesen Kollegen kommt)
Das ist bei uns auf vielen Appliances ein "großes" Problem. Da liegen Altlasten rum von irgendwelchen Anwendungen, die werden dann irgendwann abgeschaltet, und niemand weiß mehr, wie wichtig deren Zeug noch ist, oder ob man das einfach wegwerfen kann.
Ein Kollege macht es jetzt so: Bei allem, was länger als 3 Monate kaputt ist / nicht mehr angefasst wird, fragt er nach. Kriegt er nach 2 Wochen keine Antwort, wird es temporär deaktiviert. Meldet sich in 3 Monaten keiner, wird es gelöscht (Sind keine Daten, sondern Konfigurationen auf Appliances die genutzt werden).
Bei Storage ist das natürlich nicht so leicht möglich (Also das löschen von Dateien). Aber im Zweifel den Zugriff sperren, und ggf. bei der Revision fragen, wie die das sehen. Schrecklich, wenn die Leute irgendwelche Dienste von anderen nutzen, dann irgendwann ihr Zeug abbauen / ersetzen, aber niemandem sagen, dass das Zeug weg kann.

 

[douggy]

Grobe Doku über jede Anwendung, die Zeug auf dem Storage liegen hat,

Ja, kann z.B. in einer Excel oder Datenbank erfolgen. Oder auch via Skript vom Managementserver aus (und dann vllt. noch wöchentliche Email mit Auslastung und Co.)

Die "Grobe Doku" gehört aber nicht ins Storage-Betriebskonzept. Es kann auf sie verwiesen werden. Schließlich gibt es hier Änderungen..

also auch ggf. Storage bezogene Konfiguration der Anwendung der Kollegen (Die aber von diesen Kollegen kommt)

Da gibt es von mir(!) ein klares Nein.

Es sollten (jetzt schon) Standardvorgaben, anhand der Best Practises der Storage-Hersteller, existieren, an die sich Clients/Server/Applikationen halten müssen. Diese Vorgaben können im Storage-Betriebskonzept dokumentiert werden.

Meint Applikation "Wurstbude", der auf Shared Storage zugreift, andere Parameter zu konfigurieren, haben diese das bei sich zu dokumentieren und haben im Wartungs- oder Fehlerfall auch ein höheres Risiko.

Gibt es abgestimmt für einen Projekt/Kunden/Applikation (vllt. auch auf dedizierter Hardware) andere Parameter, ist das im Betriebskonzept für dieses Projekt/Kunde/Applikation zu dokumentieren. In solchen gibt es meist eh Abschnitte für Storage.

Meine bescheidene Meinung. Einwände sind willkommen.

 

[Snowi]

Meine bescheidene Meinung. Einwände sind willkommen.

Du hast völlig Recht mit der Meinung, erspart einem aber meiner Erfahrung nach später viel Arbeit, weil genau die, die dann irgendwas anderes konfigurieren, das sehr oft nicht dokumentieren, und man dann später mit denen zusammen eine Lösung finden soll.
Ist also eigentlich korrekt was du sagst, aber aus Eigennutz würde ich es trotzdem selbst dokumentieren.

 

[douggy]

@Snowi

Kommt dann auf die Anzahl der Sonderlocken an.

Ich wollte gerade eh noch umformulieren, weil man (oder ich) gerne vergisst, dass Storage überall anders gelebt wird.

 

[Skysnake]

Storage ist auch immer sehr speziell....

Gibt immer wieder Leute mit sehr spezieller Nutzung. Einzelne Files mit Dutzenden TB an Daten. Dann wieder andere mit Dutzenden von Millionen files....

Gerade Chemiker und OpenFoam Nutzer sind da immer wieder so Spezialisten, die dir auch mal nen Filesystem crashen lassen....

Btw @sun-man Lustre und bgfs sind parallele verteilte Dateisysteme. Wobei GPFS heute eigentlich Spectrum Scale heißt, nennt aber kaum einer (von den alten Hasen) so

Guckst du hier:
https://de.m.wikipedia.org/wiki/IBM_General_Parallel_File_System
https://de.m.wikipedia.org/wiki/Lustre_(Dateisystem)

Sind die beiden bekanntesten Filesysteme im HPC Bereich.

Gibt aber auch andere die vor allem als Flash only aufkommen. VAST, Panasas usw usf