Tags:
create new tag
, view all tags

Storage Service

Beteiligte Personen

Ausgangslage

  • Wechsel des Storage-Systems von EMC auf IBM
  • Einsatz der SONAS-Technologie mit Usermapping gemäss RFC 2307
  • IBM stellt für die Speicher-Ressourcen-Provisionierung ein Portal bereit
  • Storage-Portal der IBM muss auf sinnvolle Weise ins Admin-Tool eingebunden werden
  • jetziger (Pseudo-) DFS-Service muss abgelöst werden
  • Teile des Storage-Service sollen ein kostenpflichtiger Service (Lenkungsabgaben gem. SL) werden
  • einige Unix-Attribute und Gruppenmitgliedschaften müssen zwischen AD und LDAPS harmonisiert werden
  • viele organisatorische Prozesse müssen festgelegt werden
  • Projekt-Phase 1: Installation SONAS, Storage Portal
  • Projekt-Phase 2: Start Early-Adopter Program

IBM Service Delivery Manager (ISDM)

Das ISDM ist ein Software-Paket, bestehend aus folgenden Produkten:

  • TUAM (Tivoli Usage and Accounting): sammelt die Daten, welche für das Monitoring und die Verrechnung notwendig sind. Besteht aus folgenen Komponenten
    • server
    • reporting
    • client
    • collector
  • TPC (Tivoli Storage Productivity Center): automatisiert die Storage-Infrastruktur
  • TSAM (Tivoli Service Automation Manager): automatisiert die Cloud-Computing Infrastruktur (deployment, monitoring, management)
  • TPM (Tivoli Provisioning Manager): zuständig für das «resource lifecycle management»
  • Tivoli Integrated Portal: Web-Applikation für die Interaktion und das Weiterleiten von Daten zwischen obenstehenden Tivoli-Produkten

Die Tivoli-Produkte gibt es schon länger, das Tivoli Integrated Portal hingegen ist erst noch im Aufbau. Die ETH hat die Möglichkeit, bei der Entwicklung dieses Tools gewisse Dinge mit zu gestalten.

Demonstration der bestehenden Funktionalitäten

User und Gruppen

  • Kunde anlegen (als Cloud Service Provider Administrator)
    • Verwendung von Network Configuration Templates
  • Request erscheint
  • Kontextwechsel (Wechsel auf Sicht des Users)
  • Team anlegen (ETH-Team)
  • User anlegen (ETH-Admin) und als Member vom ETH-Team festlegen
  • als ETH-Admin einloggen
  • User anlegen (ETH-User), ist wieder Admin aber ohne Grant-Option

Projekt

  • Projekt anlegen (Name, Start, Ende)
  • Default-Werte werden als Admin in Form von XML festgelegt
  • Maschinen-Typ, CPU's, Memory, Disk
  • TODO Preise sollten gleich dargestellt werden
  • zusätzliche Software installieren (mit Angabe der Optionen, welche der Paket-Ersteller festlegt)
  • Einbindung von eigenen Tools müsste mit Java programmiert werden
  • Netzwerk-Konfiguration (Netzwerk-Interface MOVED TO... Netzwerk-Segment)
  • Image kann am Ende der Provisionierung gespeichert werden
  • Nützlich für Release-Wechsel

Approving - Prozess

  • ETH-Admin bekommt ein Request-Mail
  • loggt sich ein
  • sieht Details des Requests
  • Request wird angenommen oder abgelehnt (approved, declined)
    • TODO weitere Möglichkeiten wären wünschbar (Status «in Bearbeitung», Modifikation des hängigen Requests)
  • wird ein Request angenommen, wird Maschine im Hintergrund erstellt
  • beim Ablauf der Gültigkeitsdauer werden Admin und Team per Mail informiert
  • TODO organisatorische Abläufe müssen überdacht werden
  • zusätzlicher Server im selben Projekt wird mit derselben Gültigkeitsdauer versehen wie die übrigen Server
  • remove Server: durchläuft ebenfalls einen Approving-Prozess
  • modify Server
    • install (additional) software
    • Reset Server Password (root-Passwort wird neu gesetzt - %Q& wie funktioniert das?)
    • Modify Server Resources (CPU, Memory, Disk), Server wird neu gestartet ( TODO Zeitpunkt sollte ev. festgelegt werden können)
    • Start / Restart / Stop Server
    • TODO Icons sollten überarbeitet werden smile

Monitoring

  • alle Maschinen im Überblick
  • alle Details (CPU, Disk, Network etc.) können eingesehen werden
  • Auslastung, Trends, etc.
  • Monitoring-Agent auf Maschine liefert die Daten
  • TODO Daten wären für Kunden auch interessant
  • Monitoring ist eine eigenständige Applikation
  • Question werden angeforderte (allozierte) oder tatsächlich verwendete Ressourcen verrechnet?
  • bei uns: nur was wirklich gebraucht wird, wird verrechnet
  • Monitor-Tool ist lizenztechnisch bereits im Paket dabei
  • Verrechnung ist komplett unabhängig vom Monitoring

Reporting

  • Rechnungstellung pro Account-Level (Kunde)
  • kann als PDF verschickt werden
  • Reports sind bis jetzt in 3 verschiedenen Ausprägungen geplant:
    • standard Report
    • template based interactive report
    • adhoc Report
  • TODO Graphische Darstellung (roter Balken) ist problematisch

Storage-Portal: Zusammenfassung der Funktionen

  • Storage-Ressource Request
    • erstellen
    • berechtigen
    • verkleinern
    • vergrössern
    • löschen?
  • Storage-Request-Tabelle: Zuweisung eines Ressource-Namens zu
    • Fonds-Nummer
    • Leitzahl
    • Departement
    • Forschungsgruppe
    • Projektname
    • Verantwortlicher (ist bereits vorhanden)
    • zuständige ISG

Rollen und Akteure im Storage-Portal

  • Service Requestor (beantragt Service)
  • Service Creator Provider
  • Consumer Storage Admin
  • Storage Administrator
  • Storage Consumer

IBM-Portal und die Sicht der ETH

User und Gruppen werden im Identity-Management-System der ETH (genannt nethz) erzeugt und verwaltet. Viele Prozesse laufen automatisiert ab; mit dem nethz Admin-Tool können diese Prozesse auch manuell gesteuert werden. Die User und Gruppen werden einerseits ins Active Directory (AD), andererseits in ein Open LDAP (LDAPS) synchronisiert. Ausserdem werden im Active Directory (unabhängig von nethz) zahlreiche Gruppen manuell erzeugt und verwaltet, sehr viele Departemente sind in sog. OUs organisiert.

nethz Admin-Tool und Storage Portal

  • Portal-berechtigte Gruppen müssen erzeugt werden
  • Wiederverwendung von bereits bestehenden Informatik-Support-Gruppen (ISG) sollte angestrebt werden
  • zur Zeit existieren ca. 400 solche ISGs
  • Gruppen sollen in nethz für das Storage-Portal autorisiert werden können
  • Innerhalb einer Gruppe sollten einzelne User mit zusätzlichen Rechten resp. Rollen ausgestattet werden
    • Storage Request
    • Storage Approving
    • Storage Report

Die kleinste Gruppeneinheit, welche Storage beansprucht, ist die Forschungsgruppe oder Working Group (WG). An der ETH gibt es schätzungsweise 400 solcher WGs. Die Finanzierung dieser WGs und deren Ressourcen geschieht über die Institute respektive über die Departemente. Die ISGs werden vom Informatik-Support-Leiter (ISL) eines Departements erstellt. Sie betreuen diese WGs und administrieren deren Storage-Bedürfnisse. Es ist denkbar, dass für jede WG auch mehr als eine ISG zuständig ist:

Working Group (WG) zuständige ISG
Departement_WG_1 ISG_1, ISG_3
Departement_WG_2 ISG_1, ISG_3
Departement_WG_3 ISG_2, ISG_3

Innerhalb einer ISG sind die Mitglieder nicht genau identisch, sie haben verschiedene Rollen inne:

ISG_1 mit ihren Usern und ihren Rollen

User Storage-Request Storage-Approving Storage-Report
anna DONE DONE DONE
berta DONE No No
christina No DONE No

ISG_2 mit ihren Usern und ihren Rollen

User Storage-Request Storage-Approving Storage-Report
anna DONE No No
doris DONE DONE DONE

ISG_3 mit ihren Usern und ihren Rollen

User Storage-Request Storage-Approving Storage-Report
emma No No DONE

Das ergibt folgende Berechtigungen

  • Anna ist für WG_1 und WG_2 voll berechtigt und kann für ISG_3 Storage Requests erstellen
  • Berta kann für WG_1 und WG_2 Storage Requests erstellen
  • Christina darf für WG_1 und WG_2 Storage bewilligen
  • Doris ist für WG_3 voll berechtigt
  • Emma kann für WG_1, WG_2 und WG_3 Reports erstellen

Wird eine weitere WG_4 einer ISG zugeteilt, so bleiben die Rollen der ISG-Mitglieder zwar unverändert, ihr Einflussbereich wird aber entsprechend auf die neue WG_4 erweitert. Mit anderen Worten: Die Rechte der ISG-Mitglieder gelten für alle WGs, die sich im Zuständigkeitsbereich ihrer ISG befinden.

Realisierung der Integration nethz und Storage Portal

Eine Abbildung der eben gezeigten Berechtigungs-Matrix ins Active Directory oder LDAPS ist praktisch unmöglich. In einer relationalen Datenbank aber ist dies relativ einfach und wurde bereits in der nethz-DB realisiert. Ein entsprechendes GUI fehlt zwar noch, sollte aber mit vernünftigem Aufwand realisiert werden können.

In diesem Sinne soll eine direkte Integration von nethz ins Storage Portal angestrebt werden, ohne Umwege über ein Directory. Dazu gibt es mehrere Möglichkeiten:

  • REST-Schnittstelle für Portal benutzen (nethz push)
  • regelmässiger Datenimport per File (Portal pull)
  • regelmässiger Datenimport per nethz-Webservice (Portal pull)

Storage-Service für den User

  • Anforderung ist im Prinzip simpel: es muss einfach funktionieren
  • Doktoranden benötigen typischerweise viel mehr Speicher als Studenten (User-Quota Regelung)
  • Verkleinerung des Speichers ist neu technisch machbar, birgt aber organisatorische Probleme
    • Benutzer hat erhält aufgrund eines Funktionswechsels weniger Speicher als bisher
    • Benutzer erhielt aufgrund eines Antrags eine grössere Quota als die funktionsbezogene Norm
  • MOVED TO... Storage-Kapazität aufgrund der Personenkategorie
  • diese Service-Erweiterungen können in nethz agewickelt werden, da hier keine zusätzlichen Ressourcen benötigt werden.
  • der Prozess muss definiert werden (Phase 1 und Phase 2 der Portal-Lösung)

Accounting

  • Abrechnung für die Storage-Benutzung wird zur Zeit pro rata temporis gemacht
  • Abrechnungsgrundsätze müssen an die Vorgaben anpassbar bleiben (neue definition: Lenkungsabgabe 2012)
  • kleinste Zeiteinheit: 1 Tag
  • kleinste Storage-Einheit: 100 GB (anpassbar)

Verrechnung / Reporting

  • im SAP werden folgende Dinge definiert:
    • Fonds-Nummer quasi Kontonummern, meistens mehrere pro Kostenstelle
    • Kostenstelle, entspricht einer Leitzahl, ist aber streng genommen nicht dasselbe
    • Budget-Verantwortlicher (BV, immer vorhanden)
    • Budget-Stellvertreter, (BVS, in vielen Fällen nicht vorhanden)
    • Fonds-Inhaber, (FI, in vielen Fällen nicht vorhanden)
  • Question woher kriegt man die korrekte Fonds-Nummer?
    • nethz hat bereits eine Schnittstelle zu den (täglich aktualisierten) Fonds-Nummern, deren Kostenstellen, BV, BVS und FI
  • Question wer darf über welchen Fonds wieviel Storage kaufen?
    • Hier wird es nötig sein, einen Autorisierungs-Prozess in den Portal-Service vorzusehen.
    • Die Interfaces zwischen Nethz und Storage Protal sind zu definieren und zu bauen. (Phase 2 des Storage Portals)
  • Fernziel: direkte Abbuchung via SAP
  • Per-Use-Modell wird favorisiert
    • Storage Request
    • Approvement mit Angabe der Kostenstelle
    • Prozesse bei Änderungen an der Organisationsstruktur müssen definiert werden

To Do

nächste Schritte

  • Virtuelle Maschine bereitstellen (Netzwerk, VLAN etc.)
  • TODO für das Portal berechtigte Admins müssen im AD vorhanden sein
    • Service-Berechtigungen von Admins in Form von Gruppenzugehörigkeiten im AD exportieren
  • TODO Storage-Request-Tabelle (Mapping-Tabelle) der Shares muss erstellt und mit zusätzlichen Daten «angereichert» werden
  • TODO zentrale Steuerung der primären Gruppe eines Users und des Attributs homeDirectory (sowie weiterer Unix-Attribute wie loginShell etc.) im Admin-Tool
  • TODO Möglichkeiten prüfen, wie man gewisse Dinge (Gruppen) vom AD nach nethz zurücksynchronisieren kann

Termine

  • nächste Sitzung Dienstag 17. Januar
  • Ende Q2 sollte Portal-Service zur Verfügung stehen

Diverses

Fragen und Antworten

  • Question soll Request bereits im Admin-Tool erstellt werden
    • Dies wird nicht empfohlen, da viele Informationen nur auf den Storage Portal zur Verfügung stehen, und somit vorgelagert zu Entscheidungshilfen, Nachfragen, Verweigerungen etc. im Workflow-Prozess des Storageportals genutzt werden können
    • Die Abhängigkeiten mehrdimensional werden und somit vermehrt zu Supportproblemen führen können
    • Die Supportbarkeit der nethz direkt an die Release Changes der IBM bindet
    • etc.
  • Question könnte Preisgestaltung vereinfacht werden?
    • basierend auf Beschlüssen der SL und ID-GL
  • Question sollten Pakete sollten geschnürt werden, um Verwaltungsaufwand zu minimieren?
    • basierend auf Beschlüssen der SL und ID-GLund in Abstimmung mit Portfolio Management
    • basierend auf der Akzeptanz der Bezüger und in Abstimmung mit Portfolio Management

Glossar

NAS Network Attached Storage. Netzwerk-Speichersystem, welches über schnelle Verbindungen (meist Ethernet l) und via SMB oder NFS Protokolle erschlossen wird. Der primäre Vorteil besteht darin, dass auf File-Ebene die Daten gemeinsam genutzt werden können. Dabei ist bleibt die Integrität der Datzen durch Update Zugriffe gewährleistet.

SAN Storage-Area-Network (Speichernetzwerk). Serversysteme werden via dedizierte Netwerkinfrastrukturen wie FibreChannel an die Speichersysteme angeschlossen.Der Speicher kann auf Block-Ebene gemeinsam genutzt werden. Nur Cluster-Filesysteme könnensicheren Nutzen aus dieser Funktion wiehen.

SONAS Scale Out Network Attached Storage. Hoch skalierbare Storage-Infrastruktur der IBM

DFS Distributed File System (Microsoft). Ermöglicht, im NAS-Umfeld Verzeichnisse zu Verzeichnisstrukturen zusammenzustellen. Die Verzeichnisse können sich auf unterschiedlichen Systemen befinden und erscheinen Benutzern dennoch als geschlossene Struktur.

SMB Server Message Block (teils auch als LAN-Manager- oder NetBIOS-Protokoll bekannt und in Common Internet File System (CIFS) genutzt) ist ein Kommunikationsprotokoll für Datei-, Druck- und andere Serverdienste in IP-Netzwerken. SMB implementiert ein Netzwerkdateisystem ähnlich wie NFS und ist damit vom zugrundeliegenden Dateisystem des Servers größtenteils unabhängig. Dieses Protokoll wird mehrheitlich im MS Windows Umfeld genutzt.

NFS Network File System ist ein Protokoll, das den Zugriff auf Dateien über ein IP Netzwerk ermöglicht. Dieses Protokoll wird Hauptsächlich im Unix-Umfeld genutzt.

*DFS Distributed File Service ermöglicht es, einen strukturierten Directory-Baum für SMB/CIFS Protokolle zu realisieren. Dabei können die einzelnen Unterstrukturen auf unterschiedlichen Geräten Benutzertransparent eingebungen werden.

Dokumente und Links

-- SwenVermeul - 2011-12-05

Topic revision: r13 - 2012-06-25 - vermeul
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback