Wann sollte man ein SAN in Betracht ziehen?

Jeder scheint sich Hals über Kopf in den Kauf eines SAN stürzen zu wollen, manchmal mit großer Leidenschaft. SANs sind, das muss man zugeben, ziemlich beeindruckend. Sie gehören zu den unterhaltsameren und aufregenderen, großformatigen Hardware-Komponenten, die die meisten IT-Fachleute überhaupt einmal im eigenen Betrieb haben dürfen. Oft ist der Wunsch nach einem eigenen SAN eine Frage des “Mit-den-Nachbarn-mithalten”, denn der Einsatz eines SAN ist gewissermaßen zu einem Statussymbol geworden – eine jener letzten Bastionen der Großunternehmens-IT, die man nur in einem eigens dafür vorgesehenen Serverraum und niemals bei jemandem zu Hause sieht (nun, fast niemals). SANs werden massiv beworben, angepriesen und verkauft als erstaunliche Geräte mit interner Redundanz, die sie unfehlbar mache, mit einer Geschwindigkeit, die jeder Logik trotzt, und vollgepackt mit Funktionen, von denen man nie wusste, dass man sie braucht. Wenn ich mit IT-Profis spreche, die neue Systeme entwerfen, ist einer der häufigsten Entwurfsaspekte, die ich höre: “Nun, wir wissen noch nicht viel über unser endgültiges Design, aber wir wissen, dass wir ein SAN brauchen.”

Im Kontext dieses Artikels verwende ich SAN in seiner gebräuchlichsten Bedeutung, nämlich als “Blockspeichergerät” und nicht zur Bezeichnung des gesamten Speichernetzwerks selbst. Ein Speichernetzwerk kann für ein NAS bestehen, ohne überhaupt ein SAN-Blockspeichergerät zu verwenden. Für diesen Artikel bezieht sich SAN also ausschließlich auf SAN als Gerät, nicht auf SAN als Netzwerk. SAN ist ein unscharfer Begriff, der zu verschiedenen Zeiten Verschiedenes bedeutet und recht verwirrend werden kann. Ein SAN ohne Netzwerk konfiguriert wird zu DAS. DAS, das in ein Netzwerk eingebunden wird, wird zu SAN.

Halten wir einen Moment inne. Das SAN ist Ihr Back-End-Speicher. Der Bedarf danach würde sich in allen Fällen aus anderen Aspekten Ihrer Architektur ergeben. Wenn Sie sich noch nicht für viele andere Teile entschieden haben, können Sie schlicht nicht wissen, dass ein SAN im endgültigen Design benötigt wird oder auch nur nützlich sein wird. Alarmsignale. Überall Alarmsignale. Stellen Sie sich ein römisches Wagenrennen vor, bei dem die Pferde die Streitwagen schieben (wenn Sie verstehen, was ich meine).

Es ist offensichtlich, dass der Drang, ein SAN zu implementieren, so stark ist, dass oft ganze Projekte mit kaum einem anderen Zweck ersonnen werden, als, so scheint es, den Kauf des SAN zu rechtfertigen. Wie bei jedem Projekt lautet die erste Frage, die man stellen muss: “Welchen geschäftlichen Bedarf versuchen wir zu decken?” Und von dort aus arbeitet man weiter, nicht von “Wir wollen ein SAN kaufen, wo können wir es einsetzen?” SANs sind komplex, und mit Komplexität kommt Fragilität. Sehr oft sind SANs mit hohen Kosten verbunden. Doch der beängstigendste Aspekt eines SAN ist der weit verbreitete Mangel an tiefgreifendem Branchenwissen über sie. SANs bergen enorme technische und geschäftliche Risiken, die überwunden werden müssen, um ihren Einsatz zu rechtfertigen. SANs sind zweifellos sehr aufregend und durchaus nützlich, doch das reicht selten aus, um den Wunsch nach einem zu rechtfertigen.

Wir bezeichnen SANs als “den Speicher der letzten Wahl”. Das bedeutet: Bei der Auswahl von Speichertypen hofft man, eine der anderen Alternativen wie lokale Laufwerke, DAS (Direct Attached Storage) oder NAS (Network Attached Storage) statt eines SAN verwenden zu können. Meistens funktionieren andere Optionen wunderbar. Doch es gibt Zeiten, in denen die geschäftlichen Bedürfnisse Anforderungen verlangen, die sich vernünftigerweise nur mit einem SAN erfüllen lassen. Wenn diese auftreten, haben wir keine Wahl und müssen ein SAN einsetzen. Doch im Allgemeinen lässt sich dies zugunsten einfacherer und in der Regel kostengünstigerer oder weniger riskanter Optionen vermeiden.

Ich stelle fest, dass die meisten Menschen, die ein SAN implementieren möchten, dies unter einer Reihe von Missverständnissen tun.

Das erste ist, dass SANs ihrer Natur nach hochzuverlässig seien. Zwar gibt es gewiss viele SAN-Anbieter und bestimmte SAN-Produkte, die erstaunlich zuverlässig sind, doch dasselbe ließe sich über jedes IT-Produkt sagen. High-End-Server in der Preisklasse von High-End-SANs sind ganz genauso zuverlässig wie SANs. Da SANs aus denselben Hardware-Komponenten gefertigt werden wie normale Server, gibt es keine Magie, die sie zuverlässiger macht. Alles, was sich nutzen lässt, um ein SAN zuverlässig zu machen, ist ein Durchsickern von Server-RAS-Technologien (Reliability, Availability and Serviceability). Genau wie SAN können auch NAS und DAS sowie lokale Festplatten unglaublich zuverlässig gemacht werden. SAN bezeichnet lediglich das Gerät, das eingesetzt wird, um Blockspeicher bereitzustellen, statt eine andere Aufgabe zu erfüllen. Ein SAN ist nichts weiter als ein sehr einfacher Server. SANs decken das gesamte Spektrum der Zuverlässigkeit ab, mit mainframe-ähnlicher Zuverlässigkeit am oberen Ende bis hin zu Geräten, die nichts weiter sind als externe Festplatten – die unzuverlässigsten Netzwerkgeräte in Ihrem Netzwerk – am unteren Ende. Statt also Zuverlässigkeit zu bedeuten, bietet SAN tatsächlich einige Sonderfälle der geringsten Zuverlässigkeit, die man sich vorstellen kann. Doch im Grunde teilen alle Server in etwa dieselben Zuverlässigkeitsbedenken. SANs erlangen einen Ruf für Zuverlässigkeit, weil Unternehmen oft extreme Budgets in ihre SANs stecken, die sie nicht in ihre Server investieren, sodass der Vergleich ein relativ hochwertiges SAN einem relativ günstigen Server gegenüberstellt.

Das zweite ist, dass SAN “groß” und NAS “klein” bedeute. Eine solche Verknüpfung gibt es nicht. Sowohl SANs als auch NASs können nahezu jede Größenordnung und Qualität aufweisen. Beide decken die gesamte Bandbreite ab, und aus der gewählten Technologie ergibt sich nicht der geringste Hinweis darauf, ob ein Gerät groß ist oder nicht. Erneut, wie oben, kann SAN technisch betrachtet aufgrund seiner möglichen Einfachheit tatsächlich “kleiner” ausfallen als eine NAS-Lösung, doch ist dies ein Spezialfall und größtenteils nur theoretischer Natur, auch wenn es SAN-Produkte auf dem Markt gibt, die in diese Kategorie fallen – nur findet man sie sehr selten im Einsatz.

Das dritte ist, dass sich SAN und NAS im Inneren des Gehäuses dramatisch unterscheiden. Dies ist gewiss nicht der Fall, da es sich bei der Mehrheit der heutigen SAN- und NAS-Geräte um sogenannten “Unified Storage” handelt, also eine Speicher-Appliance, die gleichzeitig sowohl als SAN als auch als NAS fungiert. Dies verdeutlicht, dass der wesentliche Unterschied zwischen beiden nicht in der Backend-Technologie, der Hardware, der Größe oder der Zuverlässigkeit liegt, sondern dass der entscheidende Unterschied die zur Speicherübertragung verwendeten Protokolle sind. SANs sind Blockspeicher, die rohe Blockgeräte über das Netzwerk mithilfe von Protokollen wie Fibre Channel, iSCSI, SAS, ZSAN, ATA over Ethernet (AoE) oder Fibre Channel over Ethernet (FCoE) bereitstellen. NAS hingegen verwendet ein Netzwerkdateisystem und stellt Dateien über das Netzwerk mithilfe von Protokollen der Anwendungsschicht wie NFS, SMB, AFP, HTTP und FTP bereit, die dann über TCP/IP laufen.

Das vierte ist, dass SANs von Natur aus eine Technologie zur Dateifreigabe seien. Das ist NAS. Ein SAN nimmt lediglich Ihren Blockspeicher (das Festplatten-Subsystem) und macht ihn über ein Netzwerk aus der Ferne verfügbar. Die Natur von Netzwerken legt nahe, dass wir diesen Speicher an mehrere Geräte zugleich anbinden können, und das können wir physisch tatsächlich auch. Genau wie wir früher physisch mehrere Controller an die gegenüberliegenden Enden eines SCSI-Bandkabels anschließen konnten, in dessen Mitte die Festplatten baumelten. Dies wird unter normalen Umständen sämtliche Daten auf den Laufwerken zerstören, da die Controller, die nichts voneinander wissen, gegenseitig ihre Daten überschreiben und damit eine nahezu sofortige Beschädigung verursachen. Es gibt Mechanismen in speziellen Cluster-Dateisystemen und deren Treibern, die dies ermöglichen, doch dies erfordert spezielles Wissen und Verständnis, das weitaus technischer ist, als vielen, die sich SANs anschaffen, bewusst ist, dass sie es für genau das benötigen, was sie oft als den eigentlichen Zweck des SAN ansehen – eine Katastrophe, die so verbreitet ist, dass ich vermutlich fast wöchentlich mit jemandem spreche, der genau dies getan hat. Dass das SAN ausgerechnet jenen Anwendungsfall gefährdet, für dessen Bewältigung es nach Ansicht der meisten konzipiert ist, und dass es nicht nur den nahezu magischen, ersehnten Schutz nicht zu bieten vermag, sondern im Gegenteil selbst die Ursache des Datenverlusts ist, offenbart das Ausmaß an Risiko, das eine missverstanden implementierte Speichertechnologie mit sich bringt.

Das fünfte ist, dass SANs schnell seien. SANs können schnell sein; sie können aber auch entsetzlich langsam sein. Aus dem Einsatz der SAN-Technologie allein ergibt sich kein intrinsischer Geschwindigkeitsschub. Es ist für SANs tatsächlich recht schwierig, die inhärenten Engpässe zu überwinden, die durch das Netzwerk entstehen, auf dem sie aufsetzen. Da einige andere Speicheroptionen wie DAS dieselben Technologien wie SAN verwenden, ihnen aber der Engpass und die Latenz des eigentlichen Netzwerks fehlen, wird ein gleichwertiges DAS auch ein kleines Stück schneller sein als sein SAN-Gegenstück. SANs sind im Allgemeinen ein wenig schneller als ein hardware-identisches NAS-Äquivalent, doch selbst das ist nicht garantiert. SAN und NAS verhalten sich unterschiedlich, und in verschiedenen Anwendungsfällen kann jedes von beiden die bessere Leistung erbringen. SAN würde nur selten auf Grundlage von Leistungsanforderungen als Lösung gewählt werden.

Das sechste ist, dass die mit Speicherentscheidungen verbundenen inhärenten Probleme nicht mehr gälten, wenn es sich um ein SAN handelt. Ein gutes Beispiel ist der Einsatz von RAID 5. Dies würde als schlechte Praxis bei einem Server gelten, doch bei der Arbeit mit einem SAN (das theoretisch weitaus kritischer ist als ein eigenständiger Server) wird eine sorgfältige Planung des Speicher-Subsystems oft im Glauben unterlassen, dass das SAN diese Probleme irgendwie behoben habe oder dass sie nicht gälten. Es trifft zu, dass einige High-End-SANs über ein gewisses Maß an Funktionen zur Risikominderung verfügen, die anderswo unwahrscheinlich zu finden sind, doch sind diese selten und ausschließlich sehr hochwertigen Geräten vorbehalten, bei denen der Einsatz fragiler Designs ohnehin ungewöhnlich wäre. Es ist eine gefährliche, aber sehr verbreitete Praxis, bei der Planung des Speichers für einen physischen Server große Sorgfalt und Umsicht walten zu lassen, doch bei der Verwendung eines SAN dieselbe Planung und Aufsicht oft in der Annahme zu überspringen, das SAN handhabe all dies intern oder es sei schlicht nicht mehr erforderlich.

Nachdem ich nun viele Missverständnisse über SAN ausgeräumt habe, fragt man sich vielleicht, ob SANs überhaupt jemals angemessen sind. Das sind sie natürlich, sie sind bei korrektem Einsatz durchaus wichtig und unglaublich wertvoll. Die stärksten Vorzüge von SANs ergeben sich aus der Konsolidierung und besonderen Arten von gemeinsam genutztem Speicher.

Die Konsolidierung war historisch der Treiber, der Kunden zu SAN-Lösungen brachte. Ein SAN ermöglicht es uns, viele Dateisysteme in einem einzigen Festplatten-Array zusammenzufassen und damit eine weitaus effizientere Nutzung der Speicherressourcen zu erreichen. Da SAN auf Blockebene arbeitet, kann es dies immer dann leisten, wenn auch ein traditionelles, lokales Festplatten-Subsystem eingesetzt werden könnte. Bei vielen Servern und sogar vielen Desktops wird Speicherplatz aufgrund der Notwendigkeiten von Wachstum, Planung und der Granularität der Festplattenkapazität verschwendet. Wenn wir zwanzig Server haben, jeder mit 300-GB-Laufwerks-Arrays, von denen jeder aber nur 80 GB dieser Kapazität nutzt, haben wir eine große Verschwendung. Mit einem SAN könnten wir auf lediglich 1,6 TB zuzüglich eines geringen, für den Overhead nötigen Betrags konsolidieren und weitaus weniger für physische Festplatten ausgeben, als wenn jeder Server seinen eigenen Speicher unterhalten würde.

Sobald wir mit der Konsolidierung von Speicher beginnen, beginnen wir, nach fortgeschrittenen Konsolidierungsmöglichkeiten zu suchen. Nachdem wir viele Server-Dateisysteme auf einem einzigen SAN konsolidiert haben, haben wir die Gelegenheit – sofern unsere SAN-Implementierung dies unterstützt –, diese Daten zu deduplizieren und zu komprimieren, was in vielen Fällen, etwa bei Server-Dateisystemen, zu einer erheblichen Verringerung der Auslastung führen kann. So könnten unsere 1,6 TB aus dem obigen Beispiel tatsächlich am Ende nur 800 GB oder weniger ausmachen. Plötzlich werden unsere Konsolidierungszahlen immer besser.

Um die Konsolidierung effizient zu nutzen, bedarf es einer gewissen Größenordnung, und hier glänzen SANs wirklich – wenn die Größenordnung nicht nur in der Kapazität, sondern, was noch wichtiger ist, in der Anzahl der angebundenen Knoten sehr groß wird. SANs eignen sich am besten für die Speicherkonsolidierung großen Maßstabs. Dies ist ihr Sweet Spot und das, was sie in großen Unternehmen nahezu allgegenwärtig und in kleinen sehr selten macht.

SANs sind außerdem sehr wichtig für bestimmte Arten von Clustering und gemeinsam genutztem Speicher, die den Zugriff auf ein einziges, gemeinsames Dateisystem erfordern. Dies ist tatsächlich ein recht seltener Bedarf außerhalb eines besonderen Umstands – Datenbanken. Die meisten Anwendungen sind zufrieden damit, jede Art von Speicher zu nutzen, der ihnen bereitgestellt wird, doch Datenbanken erfordern oft einen Low-Level-Blockzugriff, um ihre Daten möglichst effektiv korrekt manipulieren zu können. Aus diesem Grund können sie selten, oder selten effektiv, auf NAS oder Dateiservern eingesetzt werden. Die Bereitstellung hochverfügbarer Speicherumgebungen für Datenbank-Cluster ist seit Langem ein zentraler Anwendungsfall von SAN-Speicher.

Über diese beiden primären Anwendungsfälle hinaus, die die überwiegende Mehrheit der SAN-Installationen rechtfertigen, bietet SAN auch ein hohes Maß an Speicherflexibilität, indem es potenziell sehr einfach wird, Speicher in einer großen Umgebung zu verschieben, zu erweitern und zu verändern, ohne sich mit physischen Umzügen oder komplizierter Beschaffung und Bereitstellung befassen zu müssen. Auch dies ist, wie die Konsolidierung, ein Artefakt der großen Größenordnung.

In sehr großen Umgebungen kann der Einsatz eines SAN auch dazu verwendet werden, eine Abgrenzung zwischen den Speicher- und den Systemtechnik-Teams zu schaffen, indem eine Übergabe auf der Netzwerkschicht ermöglicht wird, in der Regel über Fibre Channel oder iSCSI. Diese klare Aufgabentrennung kann entscheidend sein, um eine starke Abgrenzung der Teams in Unternehmen zu ermöglichen, die in hohem Maße getrennte Speicher-, Netzwerk- und Systemteams wünschen. Dies erlaubt es dem Speicherteam, sich ausschließlich auf den Speicher zu konzentrieren, und dem Systemteam, sich ausschließlich auf die Systeme zu konzentrieren, ohne dass Kenntnisse über die Implementierungen des jeweils anderen Teams erforderlich wären.

Lange Zeit boten sich SANs auch als bequemes Mittel zur Verbesserung der Speicherleistung an. Dies ist kein intrinsischer Bestandteil von SAN, sondern ein Auswuchs ihrer verbreiteten Verwendung zur Konsolidierung. Ähnlich wie bei der Virtualisierung, wenn sie zur Konsolidierung eingesetzt wird, haben gemeinsam genutzte SANs den natürlichen Vorteil, die verfügbaren Spindeln besser auszulasten, über zentralisierte Caches und größere Hardware zu verfügen als der gleichwertige, auf viele einzelne Server verteilte Speicher. Wie bei gemeinsam genutzten CPU-Ressourcen hat das SAN, wenn es keine Anfragen von mehreren Clients erhält, die Fähigkeit, seine gesamte Kapazität der Bedienung der Anfragen eines einzelnen Clients zu widmen und damit ein durchschnittliches Leistungserlebnis zu bieten, das potenziell weitaus höher ist, als ein einzelner Server für sich allein erschwinglich erreichen könnte.

Der Einsatz von SAN zur Leistungssteigerung verliert jedoch rasch an Beliebtheit, da SSD-Speicher sehr verbreitet geworden ist. Da SSDs mit unglaublich geringer Latenz und hoher IOPS-Leistung im Preis so weit fallen, dass sie eigenständigen Servern als lokaler Cache hinzugefügt oder möglicherweise sogar als Hauptspeicher eingesetzt werden, wird der Engpass des SAN-Netzwerks zu einem immer größeren Faktor, was es zunehmend erschwert, dass die Konsolidierungsvorteile eines SAN die Leistungsvorteile lokaler SSDs aufwiegen. SSDs sind potenziell sehr disruptiv für den Markt des gemeinsam genutzten Speichers, da sie den Leistungsvorteil zurück zum lokalen Speicher verlagern – nur der jüngste Wechsel im Auf und Ab des Designs von Speicherarchitekturen.

Der wichtigste Aspekt der SAN-Nutzung, den man sich merken sollte, ist, dass ein SAN bei der Speicherplanung kein standardmäßiger Ausgangspunkt sein sollte. Es ist eine von vielen Technologieoptionen und eine, die oft nicht den beabsichtigten Zweck erfüllt oder dies zwar tut, aber zu einem unnötig hohen Preis, sei es in finanzieller oder in komplexitätsbezogener Hinsicht. Beginnen Sie damit, Geschäftsziele und -bedürfnisse zu definieren. Wählen Sie SAN, wenn es diese Bedürfnisse am effektivsten löst, doch bewahren Sie sich einen offenen Blick und berücksichtigen Sie den gesamten Speicherbedarf der Umgebung.