Storage Betriebskonzept

Raknar

Ensign
Registriert
Apr. 2006
Beiträge
174
Hallo zusammen,

tl;dr: Bin ich auf dem richtigen Weg mit meinem Betriebskonzept? Gibt es Quellen zur Orientierung?

Ich habe die Aufgabe bekommen, ein Betriebskonzept für unsere Storage-Systeme (netapp, Synology, Eigenbau) zu erstellen. Weil so viele Admins das Unternehmen verlassen haben, ist das jetzt meine Aufgabe. Ich komme aus der Ecke Backup, VMware, AD. Ich habe ähnliches für mein bisheriges Tätigkeitsfeld angefertigt und habe folgende Punkte kopiert:

1 Systembeschreibung

1.1 Hauptzielsetzung und Funktionen im Überblick.

1.2 Verantwortlichkeiten (operativ)

1.3 Ansprechpartner/Support/Hersteller

1.4 Kompaktübersicht / wichtige Parameter zum Betrieb des Systems.

1.5 Abhängigkeiten zu anderen Systemen/Servern.

2 Technische Beschreibung.

2.1 Architekturschaubild.

2.2 Plattformen.

2.3 Systemkomponenten Interne Schnittstellen und Datenflüsse.

2.3.1 Server

2.3.2 Dienste.

2.3.3 DNS Konfiguration.

2.3.4 AD Konfiguration.

2.3.5 Mail

2.3.6 SIEM/Monitoring.

2.3.7 Portübersicht

2.3.8 Datenbanken.

2.3.9 Schnittstellen.

2.3.10 Datenflüsse und Firewall

2.4 Jobsteuerung.

3 Installation und Konfiguration.

3.1 Installations- und Konfigurationspfade in der Produktivumgebung.

3.1.1 Server

3.2 Installations- und Konfigurationspfade in der Testumgebung.

3.2.1 Cloning der Applikation/Daten in Testsystem..

4 Verfügbarkeit

4.1 Betriebszeiten/Wartungsfenster

4.2 SLAs.

5 System-/Anwendungsbetrieb.

5.1 Rollen und Aufgaben.

5.2 Gruppen und Berechtigungskonzept

5.3 Regelmäßige Wartungsaufgaben.

5.4 Überwachung und Reporting.

5.4.1 Logging.

5.4.2 Monitoring.

5.5 Startup- /Shutdownroutine.

5.6 Datensicherung.

5.7 Wiederherstellung.

5.8 Archivierung.

5.9 Systemspezifische Tätigkeiten.

5.10 Wichtige Informationen für den Betrieb des Systems.

6 Störungsmanagement

6.1 Alarmierung und Eskalation.

6.2 Fehlerbehebung (inkl. Test)

6.3 Restart und Wiederanlauf

6.4 Verweis auf Notfallpläne.

Online habe ich nicht wirklich etwas gefunden. Sicherlich, weil mir die passenden Begriffe noch fehlen.
Daher hoffe ich, dass ihr mir weiterhelfen könnt.

Vielen Dank im Voraus!

 
Kurz um das zu verstehen:
Eure Firma kündigt admins / diese gehen von sich aus, gibt dir Aufgaben fuer die du keine Qualifikation hast, beziehungsweise, die du dir ohne externe Hilfe nicht zutraust.
Darum wird die Aufgabe jetzt an ein Forum externalisiert. (free support fuer kommerzielle wird hier ohnehin nicht gern gesehen, aber meh)
Ist kündigen und einen anderen Arbeitgeber suchen eine Option?

Die Punkte in deiner Liste sind soweit alle fuer Storage relevant. Einige doppeln sich dem Sinn nach. Zu jedem Davon kann man 1-2 Seiten schreiben und sich lange Gedanken machen.

bei 4. koenntest du noch was zu geoverteilung / Multi-Site und entsprechend active-active / active/passive betrieb schreiben.
Vielleicht noch block vs object storage.

Aber ey. Ohne irgendwelche Rahmenbedingungen zu kennen kann dir niemand sagen welche hardware, software und konzepte sinnvoll sind.

Raknar schrieb:
Online habe ich nicht wirklich etwas gefunden
wonach hast du bisher gesucht?

Mir kommen zu den meisten deiner Punkte sofort gedanken mit ganz vielen Optionen. Ich tippe davon jetzt nichts weil das alles immer an dem punkt scheitert: Welche Anforderungen
Verfügbarkeit?
Was soll darauf schreiben?
-> Latenzen?
-> bandbreite?
-> IOPS?
Welche Anforderungen gibt es an Backups?
Welche Anwendungen sollen darauf schreiben?
Welche Gesetzlichen Rahmenbedingungen gibts bei euch?
was steht bei euch in den Vertraegen?
Welche Monitoring und welche Konzepte zur Log Verwaltung gibt es bei euch?
Welche Protokolle um den Storage einzubinden?
und. so. weiter....

nur vielleicht als genereller hinweis:
Raknar schrieb:
3.2 Installations- und Konfigurationspfade in der Testumgebung.
von anfang an config management. versioniert.
Die Bedienung ansible+git kann man wenn man ein bisschen Computer kann an einem Nachmittag erlernen.
Details halt auf dem weg nachschlagen.
Manuelles gefummel hat im Unternehmensumfeld nix zu suchen
 
  • Gefällt mir
Reaktionen: noxiD, PHuV und BFF
Bei uns im Unternehmen gibt es Vorlagen mit den entsprechenden Vorgaben.
Aber prinzipiell sieht das schon sehr umfangreich aus.
 
  • Gefällt mir
Reaktionen: Snowi und madmax2010
Haben den deine Vorgänger keinerlei Dokumente dir hinterlassen?
 
  • Gefällt mir
Reaktionen: Snowi und madmax2010
madmax2010 schrieb:
Darum wird die Aufgabe jetzt an ein Forum externalisiert.

Dass Leute gehen und man zusätzliche Aufgaben bekommt, kann passieren.
Externalisiert ist deswegen noch nichts. (Arbeit machen)

Hier tummeln sich wahrscheinlich einige Experten oder sonstiges Fachpersonal, denen ähnliches passiert sein könnte.

Vielleicht kann jemand was dazu beitragen.
Wenn nicht hier fragen, wo dann?
 
  • Gefällt mir
Reaktionen: maxik und quaaaak
Raknar schrieb:
Weil so viele Admins das Unternehmen verlassen haben
Wen so ein Exodus eines ganzen Teams statt findet, dann hat das meist seine Gründe. Ernst gemeinter Rat weil ich auch mal in so einer Situation war und es nicht habe kommen sehen: Fang parallel an deinen Lebenslauf zu aktualisieren und mal die Fühler ausstrecken.

Gerade wenn du jetzt so etwas schreiben sollst, kann man das auch unter dem Aspekt sehen: Dann hat die Firma etwas in der Hand für einen potentiellen externen IT-Dienstleister, der den Betrieb/Administration übernehmen soll.

Manche der Punkte in deiner Aufzählung sind redundant vorhanden, hier würde ich ggf. aussortieren.
Ebenfalls empfinde ich solche all-umfassenden Dokus selten zielführend. Ich würde diese teilen je nach Zielsetzung. Soll man daraus Infos beziehen oder damit lernen, soll es etwas beschreiben oder soll es Handlungsanweisungen beinhalten? Oder ausführlicher erklärt:
https://www.writethedocs.org/videos...-to-understand-what-they-are-daniele-procida/
Ebenso würde ich die Dokumente pro System trennen. Wenn ihr also wie du schreibst drei Storages habt, dann jeweils drei Stück und nicht alles in einem Monolithen.

@madmax2010 Ich glaube, hier liegt ein Missverständnis vor. Der TE soll dokumentieren, was vorhanden ist und nicht Planung für etwas neues machen, zumindest verstehe ich das so.
madmax2010 schrieb:
von anfang an config management. versioniert.
Ja, sehr guter Vorschlag und full ack aber das wird bei stateful Systemen (Datenbanken) schnell schwierig und schmerzhaft weil Rollbacks nicht immer so einfach möglich sind und bei Storage wird es nochmal schwieriger weil gefühlt alle anderen Systeme und Services auf Verfügbarkeit angewiesen sind und jetzt als Realitätsabgleich: Die meisten kommerziellen Storagesysteme sind proprietärer Rotz, zumindest die Management-Systeme davon und nicht für alle gibt es Ansible Module oder eine gut dokumentierte API.
 
  • Gefällt mir
Reaktionen: Skysnake und madmax2010
Bei uns gibt es für so etwas auch Vorlagen, also eventuell mal schauen? Scheint sich ja jemand zumindest ein paar Gedanken gemacht zu haben.
Wenn nein, eventuell mal ein anderes Konzept anschauen als Orientierung. Ich hab das ganze vor kurzem auch durch gemacht, waren am Ende insgesamt ca. 40 Seiten schätze ich.
 
Hallo,

erstmal vielen Dank für die Antworten!
@madmax2010 Die Admins sind halt von sich aus gegangen, zur Konkurrenz bzw. Umzug. Und das alles innerhalb weniger Monate. Eine ähnliche Situation gab es vor meiner Zeit in einem anderen Bereich, was jemand genutzt hat, um sich weiterzuentwickeln. So möchte ich das auch für mich :)

@Snowi Vorlagen habe ich nicht gefunden. Deswegen habe ich meine aus meinem Bereich genommen. Ich habe ein eBook "Praxishandbuch IT-Dokumentation", indem aber nur beispielhaft Hardware dokumentiert wird, sodass ich da wenig ableiten kann. Ist dein Konzept mit meinem Bereich verwandt? Wenn ja, dann würde mich das Inhaltsverzeichnis interessieren ;)

@snaxilian Ich werde es nach Systemen trennen. Pro Hersteller haben wir mehrere Geräte (ca. 20 x netapp)
 
Raknar schrieb:
Ist dein Konzept mit meinem Bereich verwandt? Wenn ja, dann würde mich das Inhaltsverzeichnis interessieren ;)
Leider nicht direkt, aber da gibt es bestimmt Überschneidungen. Melde mich am Montag damit, hab heute meinen letzten Urlaubstag ;)
 
  • Gefällt mir
Reaktionen: Raknar
Ich vermisse in der Gliederung nichts Essentielles.
Viel Erfolg bei der inhaltlichen Ausgestaltung.
 
  • Gefällt mir
Reaktionen: Raknar
Ich vermisse da noch Daten zu Quotas, Schutzbedürftigkeit der Daten, Umgang mit defekten Datenträgern, Spare Parts, HA Konfiguration, Firmware Stände, Netzwerk Abschottung, Infiniband, also MOFED Version usw, auditing, Security also SUID Bits rootsquash usw.

Batterien für Raidcontroller, USV Standzeiten usw usf, Power Verkabelung, Testmethoden für Redundanz, Filesystemchecks, Tiering, in die count

Das sind so die Sachen die mir spontan einfallen.

Storage ist echt nen riesen Feld. Du solltest wirklich was über deren Einsatzzweck usw kundtun. Je nachdem ist der storage auch nur scratch
 
  • Gefällt mir
Reaktionen: Raknar
Ich vermisse in der Liste unterschiedliche Speicherklassen (IOPS (pro GB), Durchsatz sowie Antwortzeiten).
Der Rest richtet sich sowieso nach eurem Unternehmensstandard für Servicedokumente und ist durchaus abhängig davon, was bestimmte Standards fordern (ISO 270001 etc.) sollte also für alle eure Dokumentationen derselbe Standard sein.
 
Skysnake schrieb:
Ich vermisse da noch Daten zu Quotas, Schutzbedürftigkeit der Daten, Umgang mit defekten Datenträgern, Spare Parts, HA Konfiguration, Firmware Stände, Netzwerk Abschottung, Infiniband, also MOFED Version usw, auditing, Security also SUID Bits rootsquash usw.

Batterien für Raidcontroller, USV Standzeiten usw usf, Power Verkabelung, Testmethoden für Redundanz, Filesystemchecks, Tiering, in die count

Das sind so die Sachen die mir spontan einfallen.

Storage ist echt nen riesen Feld. Du solltest wirklich was über deren Einsatzzweck usw kundtun. Je nachdem ist der storage auch nur scratch
Also ich kennen im SAN/Storage kaum einen der das alles in einer Abteilung hat. Ich kenne mich ein wenig bei Banken aus FFM aus und bei meinem Hauptkunden haben wir ~45PB reinen Blockstorage und div. Objekts hinter ein paar Tausend FC Ports.
Zumindest aus BS Sicht betrachten wir keinerlei Endgeräte (Quotas usw) und ziehen uns durchaus auf den Support des Herstellers zurück. Aber u.U. sollte man auch betrachten welchen Umfang die Firma hat.
Aber Du hast Recht, Storage ist mit allem drumherum ein ziemlich großes Feld.

NetApp :freak:, Synology, Eigenbau....da würde ich mir unter den beiden letzten gerne mal etwas vorstellen.
 
Naja, wir machen große Lustre und GPFS Systeme. Da hast du dann halt Filesysteme mit 10PB++ Netto. Also als einzelnes Filesystem auf dem dann durchaus ein paar hundert Leute hantieren können... da gibt es dann auch User und Gruppenquotas recht häufig.

Aber klar, wir verkaufen das Zeug, aber wenn man Eigenbau hat, muss man sich damit eben beschäftigen. Hat schon seinen Grund warum viele Leute den storage als Appliance einkaufen.
 
Kenne ich nicht. Ist das Software Defined? "Viele" wollen sich halt nicht damit beschäftigen, Fire&Forgett und je nach Größe ist das doch auch OK. Kunde 2 hat da viel mit "reinem und puren" Storage :D, was für eine seltsame Firma ^^.
 
@Skysnake
Vielen Dank für die Tipps. Einsatzzwecke: von teilweise Archiv (ältere, nur drehende Platten) bis Datenbank-Applikationen (=>All Flash) inkl. ERP. Es sind halt verschiedene Geräte, die allerdings durch Funktionalitäten wie Metro-Cluster, SVM-Peering und SnapMirror miteinander aus Redundanzgründen verbunden sind, ohne abhängig zu sein.

@sun-man
Der Storage von Netapp ist für alle wichtigen Produktivsysteme (ERP, DMS, etc.). Die Geräte von Synology gehören zu den Backupzielen und zu temporärer Dateiablage. Der Eigenbau besteht aus Servern unter Support, mit vSAN, Trunas, CIFS. Aber auch (noch) reine Oracle-Server.
OT: was hast du gegen Netapp? Ich hatte vorher viel mit Dell (Unity, Powerstore, Vxrail, VMax) zu tun. Ich halte NetApp für ähnlich gut/ausgereift, mit ein paar besseren Lösungen, vor allem bei Live-Kompression von Produktiv-Daten.

@Snowi Bist du noch im Urlaub :)
 
Ach so. Ja mei. Jeder hat so seine Erfahrungen, hier hat nichts davon gezündet. Ist aber ne Weile her, seitdem sind sie raus. Ich denke wenn ich jetzt IBM, HDS, Huawei oder auch irgendein Systemhaus wie Computa.... schreibe könnten solche Smileys auch kommen :D
 
Ich mag meine NetApp-Büchsen, sei es HA, FMC oder IP :)

Aber das ist ja nicht unbedingt das Thema hier.

Wie gesagt, ich würde in das Betriebskonzept alles beschreiben, was in der eigenen Verantwortung liegt. Was nicht in der eigenen Veranwortung liegt, da sollten die Anforderungen rein (wenn z.B. LAN, Strom etc. andere Teams machen und alles standardisiert ist).
Wenn der douggy beim TE in's Team kommen würde, müsste er mit dem Betriebskonzept ohne große Nachfragen arbeiten können.
Meine Meinung.
 
  • Gefällt mir
Reaktionen: Skysnake
Zurück
Oben