SAN im Griff
Noch vor einigen Jahren schien es schier unmöglich, Speichernetzhardware unterschiedlicher Hersteller zusammen zu verwalten. Inzwischen ist es dem Standard SMI-S gelungen, innerhalb weniger Jahre den Markt der Storage-Management-Applikationen grundlegend zu verändern und Tore für die Zukunft zu öffnen.
- Thorsten Schäfer
- Alexander Wolf-Reber
Zu dem Zeitpunkt, als sich Fibre-Channel-basierte Speichernetze bereits bewährt und etabliert hatten, war die Frage einer gemeinsamen Managementschnittstelle noch immer ungelöst. Die Administration eines komplexen heterogenen Speichernetzes war typischerweise von einer Vielzahl unterschiedlicher Managementapplikationen begleitet und mit hohem Aufwand verbunden.
Durch die Storage Management Initiative Specification (SMI-S) hat sich seitdem einiges geändert: Die Hersteller arbeiten enger zusammen und tauschen ihre - vom Standard geforderten - Schnittstellen aus. Wichtiger noch: Inzwischen erhalten die in der SMI-S vorgesehenen Kommunikationsschnittstellen, die Provider, in der Produktentwicklung einiger Hersteller Vorrang vor den proprietären APIs.
Der Eigner des SMI-S, die Storage Network Industry Association (SNIA), ist ein Zusammenschluss von etwas mehr als 60 Firmen, die im Umfeld von Speichernetzen tätig sind. Ursprünglich hatten die Firmen die SNIA gegründet, um die Popularität von Speichernetzen zu steigern und ihnen zum Durchbruch bei den Kundeninstallationen zu verhelfen. Inzwischen sind Speichernetze allgemein akzeptiert.
2002 rückte die Standardisierung des Speichermanagements in den Mittelpunkt der SNIA-Aktivitäten. Es begann die Arbeit an einem Standard, der zuerst den Namen Bluefin trug und später SMI-S [1]. Die fachliche Arbeit der SNIA wird hauptsächlich in den USA geleistet. In Europa und Japan beschränken sich die SNIA-Dependancen auf das Marketing. Für öffentliche Demonstrationen nutzt die SNIA die regelmäßig stattfindenden Tagungen der Storage Networking World (SNW) in USA, Europa, Japan und Australien. So wurde im Herbst 2002 in Orlando/Florida bereits der erste Vorläufer eines durch SMI-S verwalteten SAN vorgestellt: das CIM-SAN-1.
Standards nutzen und schaffen
SMI-S baut auf bereits existierenden Standards auf. Den wohl größten Teil beschreibt die Spezifikation Web-based Enterprise Management (WBEM) der Distributed Management Task Force (DMTF). Mit WBEM hatte die DMTF Mitte der 90er-Jahre einen webbasierten Ansatz zur Verwaltung der unternehmensweiten IT entwickelt - ein Standard, der genau zum Ansinnen der SNIA passte.
WBEM beschreibt sämtliche funktionalen Aspekte, das heißt Operationen auf dem Objektmodell des Speichergeräts respektive einzelner Instanzen. WBEM selbst nutzt drei weitere Basistechniken: das Common Information Model (CIM) zur Modellierung der zu verwaltenden Speichergeräte, XML zur Beschreibung der Operationen auf dem Objektmodell und HTTP zum Transport der XML-Nachrichten.
Der wichtigste Standard hierbei ist CIM, das die einheitliche Modellierung der Speichergeräte ermöglicht. Theoretisch ließen sich Transport und das Encoding der Managementoperationen jederzeit durch andere Beschreibungssprachen sowie Protokolle realisieren. Beispielsweise diskutieren DMTF und SNIA zurzeit die Verwendung von Webservices.
Die Hauptleistung der SNIA liegt in der Erweiterung von CIM um speichernetzspezifische Aspekte und der Integration des Service Location Protocol (SLP), das zur automatisierten Erkennung von durch WBEM verwalteter Geräte dient [2]. Es sieht neben den abfragenden User Agents und den die Dienste publizierenden Service Agents optional einen zentralen Directory Agent vor. Der im SMI-S Directory Server genannte Agent registriert die SMI-S-Agenten zentral. Jeder SMI-S-Agent ist zwar selbst in der Lage, seinen angebotenen Service zu publizieren, trotzdem ist es gerade bei komplexen Netzkonfigurationen oft notwendig, solche Directory Server zu platzieren. Man denke hierbei nur an die Verteilung der SMI-S-Agenten über mehrere Subnetze. Directory Server bieten zudem die Möglichkeit der manuellen Registrierung.
Ein ebenfalls in den Standard aufgenommener Lock-Manager soll im SMI-S-System für Transaktionssicherheit sorgen. Diese Funktion ist jedoch zurzeit noch optional und wenn, dann nur rudimentär implementiert.
Den vollständigen Artikel finden Sie in der aktuellen Printausgabe der iX. (sun)