extra Wettrennen Storage In der IT ändere sich ständig SAN wie ausgereift sind die aktuellen Übertragungstechniken?

Transkript

1 sponsored by: Ein Verlagsbeihefter der Heise Zeitschriften Verlag GmbH & Co. KG extra Storage SAN wie ausgereift sind die aktuellen Übertragungstechniken? Speichernetze und Ethernet eine ambivalente Beziehung Wettrennen Was taugt Fibre Channel fürs SAN? Nie am Ziel Vorschau Networking Virtual Private Networks Veranstaltungen 30. August 2. September 2010, San Francisco VMworld Oktober 2010, Kopenhagen VMworld Oktober 2010, Frankfurt am Main Storage Networking World Oktober 2010, Frankfurt am Main Virtualization World Oktober 2010, Frankfurt am Main Datacenter Technologies Seite I Seite VII Seite VIII ix extra Storage zum Nachschlagen: Storage Wettrennen Speichernetze und Ethernet eine ambivalente Beziehung Ist iscsi wirklich billiger als Fibre Channel? Und sind FC-SANs wirklich zuverlässiger als iscsi oder andere Ethernet-SAN-Varianten? Bevor man sich in Details und unsinnigen Konfrontationen verliert, die nicht immer auf gesichertem Wissen beruhen, lohnt es sich, ein paar Prinzipien von Speichernetzwerken und ihrer Geschichte in Erinnerung zu rufen. In der IT ändere sich ständig alles, heißt es. Immerzu kämen neue Sachen auf den Markt, da könne man kaum noch mitkommen, angesichts der permanenten Entwicklungen. Das klingt zwar einleuchtend, ist es aber nicht. Die Entwicklungen in der IT sind eigentlich Glieder einer langen Kette von Verbesserungen en détail, da und dort. Ein gutes Beispiel dafür ist das Storage Area Network (SAN). Die Idee, ein nur den Speicheraufgaben gewidmetes Netz vom LAN oder WAN abzutrennen, hatte etwas Bestechendes, da bestehende Mängel mit einem Schlag aus der Welt geschafft waren. So gut wie alle großen Unternehmen haben seit Ende der 90er-Jahre ein oder mehrere SANs auf Basis von Fibre Channel (FC) implementiert, und Experten, Analysten sowie die Fachpresse waren des Lobes voll. Da und dort drehten die Entwickler im Laufe der Jahre an ein paar Stellschräubchen, aber das Prinzip blieb überschaubar und letztlich unverändert. FC-SANs gelten inzwischen als ausgereift und im Vergleich zum klassischen LAN als einfach, weil mit weniger Transportdiensten und Konfigurationsoptionen ausgestattet. Dies hält die Zahl der möglichen Fehlerquellen gering. Das SAN- Management selbst besteht hauptsächlich aus der Verwaltung des Netzes, der FC-Switches und der über sie erreichbaren Speichereinheiten. Keine Frage des Geldes Dass FC-SANs relativ viel Geld kosten, hat die großen Anwender und Early Adopters wenig gestört. Sie konnten zudem in die notwendige Ausbildung ihrer SAN-Fachleute investieren: Die eigentliche Schwierigkeit bei einer FC-Implementierung liegt gewöhnlich in der geringen Erfahrung der Serverund Netzwerkadministratoren mit dem Thema Datenspeicher. Und das, obwohl ein großer Teil der Investitionen der IT gerade in diesen Bereich fließt. Immer wieder kann man feststellen, dass auf der Serverseite die I/O-Last der Festplatten keine Beachtung findet und keine historischen Aufzeichnungen I

2 über den Verlauf der Last vorhanden sind. [1] Noch heute, mehr als zehn Jahre nach der Geburt von FC- SANs, erhält man auf die Frage nach Nachteilen dieser Technik meistens nur eine Antwort: Zu teuer. Manchmal folgen noch Komplexität und Ausbildungsaufwand. Bei der Frage nach der technischen Reife und Stabilität von Fibre Channel verweisen die meisten auf den Vergleich mit den Fähigkeiten von Ethernet. Schaut man zurück, bot Ethernet damals nur einen Durchsatz von 10 MBit/s, 100 MBit/s oder 1 GBit/s, eingesetzt hauptsächlich in der Open-Systems-Welt, bei lokalen Desktop-Anbindungen an zentrale Server und im Internet. Zunächst waren nur relativ wenige Mitarbeiter in solche Netze einbezogen. Was man beim bloßen Transport von Informationen von A nach B zunächst noch an geringer Geschwindigkeit und verzögertem Ankommen am Zielpunkt hinnehmen konnte, stellte sich als wesentlicher Mangel für den Transport von Speicherdaten dar [2]. Flow-Control-Mechanismen und garantierter Durchsatz waren unbekannt, Latenz und Protokoll-Overhead zu groß. Genau hier hat Fibre Channel seine Vorzüge. Es handelt sich immer noch um eine Netzanbindung, aber sie ist in einen eigenen Protokoll-Stack eingebaut, mit dem Resultat eines wesentlich geringeren Overheads. Er verfügt über eingebaute Flow Control, sequenzielle Datenübertragung und kann Bandbreiten garantieren ob Punkt zu Punkt, in einem Maschennetz oder einer Arbitrated Loop. Ohne Zögern Der wohl wichtigste Unterschied zwischen dem Ethernet- und dem Fibre-Channel-Protokoll liegt in der Latenz: In FC-SANs sind Verzögerungen oder Wiederholungen aufgrund von Paketverlusten nicht tolerierbar, da sie Datenblöcke und SCSI- Befehle unmittelbar zwischen Serverbetriebssystem und Speichergerät transportieren. Peter Coleman, langjähriger Storage-Experte und ehemaliger SNIA-Mitarbeiter jetzt bei Compellent im Trainingsbereich tätig, spricht in diesem Zusammenhang von der Erblast des SCSI-Protokolls, das besonders empfindlich auf Verzögerungen reagiert. Sein eigener Bus beschränkte die Kabel aufgrund der Laufzeitunterschiede der parallel geschickten Bits zu Beginn auf sechs respektive drei Meter. Man war allgemein begeistert, als es schließlich Aktuelle SAN-Techniken jenseits von Ethernet und Fibre Channel SAS Serial Attached SCSI: Serieller SCSI-Nachfolger für interne und externe Massenspeichergeräte sowie für Backplanes. Für die externe Anbindung benötigt ein Server HBAs. Obwohl ursprünglich wie SCSI eine DAS-Architektur (Direct Attached Storage), lassen sich mit SAS-Switches inzwischen Speichernetze realisieren, die allerdings nur für Entfernungen von ein paar Metern taugen. Replikation und Disaster Recovery sind deshalb nur in be - schränktem Umfang möglich. Dennoch zählen manche SAS zu den SAN-Techniken. IB Infiniband:ˇAufgrund seiner hohen Geschwindigkeit und geringen Latenz wird dieses Protokoll bisher meistens im Server- und High-Performance-Computing-Bereich (HPC) eingesetzt. Durch den vergleichsweise geringen Preis ist es gerade für die HPC- Domänen Wissenschaft und Forschung sowie für den öffentlichen Sektor geeignet. Sein direkter Speicherzugriff (RDMA) macht es auch für den Banken- und Healthcare-Sektor interessant. Im Speicherbereich hat es bisher kaum Fuß fassen können, obwohl die meisten Infiniband-Hersteller von Fibre- Channel-Anbietern gekauft wurden. Momentan krankt Infiniband an der mangelnden Glasfaser-Implementierung. SCSI-Kabel mit 12 oder 25 Meter Länge gab in heutigen Unternehmensumgebungen schon lange nicht mehr vorstellbar. Das SCSI-Erbe hatte Konsequenzen für das Netzwerkkonzept einer Shared-Bus-Infrastruktur, wie man sie zunächst für FC-SANs vorsah: Wenn eine Kommunikation zwischen zwei Geräten hergestellt war, verfügen sie über die ganze Bandbreite mit garantierter Latenz. Genau dies braucht man, um eine eigene Netzwerkarchitektur für Speicherdaten aufzubauen: Man benötigt eine Kommunikationsinfrastruktur, die sobald zustande gekommen durch keine andere Verbindung gestört wird. Fibre Channel war hierfür die adäquate Lösung: Es bot eine sichere Verbindung und geringe Latenz auch bei größerer Distanz. Brocade gilt als der eigent - liche Vertreter eines FC-SAN, der mit seinem OEM-Modell schließlich für dessen Durchsetzung am Markt sorgte. Allerdings traf dies erst für die zweite Phase der SANs zu, da es Brocade um die Durchsetzung einer Fabric ging also einer Switched Architecture. Zunächst stand erst einmal die SAN-Variante Arbitrated Loop im Vordergrund. Hier waren vor allem zwei Hersteller involviert: Vixel (später von Emulex übernommen) und Gadzoox (später von Broadcom übernommen). Der Normierungs-Ausschuss T10, der sich mit SCSI beschäftigte, und anschließend der T11-Ausschuss kümmerten sich um eine Verbesserung der parallelen Architektur, indem man versuchte, SCSI-Kommandos von der physischen Transportschicht zu trennen und so zu einer seriellen Architektur zu gelangen. Neben Vixel und Gadzoox engagierten sich hier IBM, Emulex, QLogic und JNI. Weichenstellung für die Zukunft Als Brocade und andere zu ihrer Markteroberung ansetzten, wollten die Unternehmen Switch-orientierte Storage- Architekturen einsetzen, weil man mit den Verbindungen bei Ethernet schmerzvolle Erfahrungen gemacht hatte: vom kollisionsbeladenen Bus über ebensolche Hubs zu Switches. Switched Ethernet war der Weg in die Zukunft, und jeder wollte ihn gehen. Als Brocade, Ancor oder QLogic anfingen, über Switched Fabrics zu sprechen, stießen sie schnell auf Zustimmung, weil das Unabhängigkeit von den Internet-Protokollen versprach. Gadzoox und Vixel vertraten dagegen den Standpunkt, dass Arbitrated Loop noch immer der bessere Weg sei, und niemand würde mehr als 126 Geräte in einem Speichernetz verbinden wollen. Ein Protokoll-Kreuzzug begann. Vor diesem Hintergrund setzte sich schließlich Brocade durch. Gadzoox verlor immer mehr seiner OEM-Beziehungen mit Compaq, Data General oder DEC, und Brocade eroberte nach und nach mit seinem OEM-Modell, dem Verzicht auf einen eigenen Vertrieb, den Markt für Switched Fabric auf Basis des FC-Protokolls. Als Gadzoox dann doch mit einem Fabric-Switch herauskam, war es zu spät. Der Marktanteil war von ursprünglich 80 auf 10 Pro- II ix extra 8/2010

3 Überzeugen Sie sich vom SC846 Storage-Server mit NexentaStor TM Zertifizierung EINZIGARTIG UNIFIED STORAGE KOMPLETTSYSTEM Basierend auf Open Solaris und ZFS Selbstheilendes Storagesystem Einfaches Management über intuitive Weboberfläche Unübertroffene Datenintegrität und -konsistenz aufgrund des transaktionsbasierten Zugriffs Perfekte Integration von SSD Technologie Nahtlose Einbindung in VMware, XenServer und Hyper-V Umgebungen Energiesparend dank Efficientline Technologie SC846 STORAGE-SERVER + NEXENTASTOR TM AB EUR 4.095,- Server individuell konfi gurieren: JETZT NEU! Flächendeckendes Händler- und Servicenetz in der Schweiz: EU: +49 (0) AT: +43 (0) CH: +41 (0) Made in Germany! Verkauf erfolgt ausschließlich an Gewerbetreibende, Firmen, Freiberufler (Ärzte, Rechtsanwälte etc.), staatliche Institutionen und Behörden. Druckfehler, Irrtümer und Änderungen in Preis und Ausstattung vorbehalten. Unsere Versandkosten richten sich nach Gewicht und Versandart. Genaue Preisangaben finden Sie unter: Thomas-Krenn.AG, Speltenbach-Steinäcker 1, D Freyung

4 zent zurückgegangen, und die Vorherrschaft lag nun bei Brocade und QLogic. Gadzoox wurde schließlich von Broadcom übernommen, weil man dort an Teilen der Technik für die eigene HBA-Produktion interessiert war, während Vixel an Emulex ging. Eine weitere Dynamik kam in den Markt, als Cisco begann, sich für FC-Switches zu interessieren. Die große Masse der Anwender hielt sich anfangs auch deswegen zurück, weil vor zehn bis zwölf Jahren viele Begriffe und revolutionäre Techniken herumschwirrten es war die Zeit, als sich die Dotcom- Blase so richtig aufblies. FDDI sollte das Internet ersetzen, und ATM und Token Ring sollten die Netzwelt auf eine neue qualitative Stufe heben. Keine der drei Techniken hat sich durchgesetzt, aber ein gewisser fader Nachgeschmack und eine Distanz gegenüber Neuem sind geblieben. Erst als sich anerkannte Player wie EMC, HP oder IBM auf die Seite von FC schlugen und langfristige OEM-Verträge mit Brocade abschlossen, erfuhren Fabric-Architekturen oder SANs eine Art offizielle Anerkennung. Wartung und Service durch mindestens einen der großen Anbieter, wie in diesen Fällen angeboten, gehören zu den oft unterschätzten, weichen Entscheidungskrite - rium jenseits von Preisen oder technischer Attraktivität. Im Schatten des Riesen Die Stunde der FC-SANs kam nicht zuletzt wegen der veränderten Anforderungen an Speicherdaten und Netzwerk, ausgelöst durch Business-kritische Applikationen. War es zum Beispiel zu Beginn der 90er-Jahre noch akzeptabel, wenn bei einer Publikumsbank ein Ausfall der IT drei Tage nicht überschritt, so Coleman, erfordern heute elektronischer Aktienhandel oder Internet-Banking eine wesentlich höhere Verfügbarkeit: Mehr als drei Stunden würden die Geschäftsbasis gefährden. Daten müssen in einer globalisierten Wirtschaft nicht nur on-site repliziert zugänglich meist in Form von Backup- Tapes, die aufwendig gesucht, gefunden und zurückgespielt werden müssen, sondern in mindestens zwei Rechenzentren parallel abgelegt sein, damit man sie im Notfall schnell von B nach A oder umgekehrt replizieren kann. Und diese Anforderungen VOR- UND NACHTEILE DER ÜBERTRAGUNGSTECHNIKEN IM SAN Protokoll Pro Contra FC ˇdeterministisch; unter Volllast vorhersehbares Verhalten ˇgarantierte In-order Delivery ohne Verluste, d.ˇh. kurze Latenz und schlanker Transportlayer ˇhohes Ansehen bzgl. Stabilität ˇhoher Preis, teurer Support; deutlich geringere Stückzahlen als Ethernet ˇmehr zusätzliche Admin-Kompetenzen (verglichen mit iscsi) benötigt iscsi FCoE Infiniband ˇniedrigster Preis ˇwenig Zusatzkompetenz neben LAN-Administration notwendig ˇKomponenten schon vorhanden ˇverringert die Anzahl und Vielfalt an Netzwerkadaptern pro Server erhält bewährte FC-Paradigmen ˇnutzt verbessertes Ethernet ohne Packet Drop etc. ˇpseudodeterministisch ˇniedrigstmögliche Latenz bei hoher Bandbreite (bis 96 Gbps) ˇelementar für Clouds und Grids mit großen Netzen ˇAntwortverhalten unter Volllast ist schwer vohersagbar, IP und Ethernet sind undeterministisch ˇgenießt Geht doch -Ansehen bei Midrange- und Teillast-Servern, dadurch überzogene Erwartungen ˇQoS- und Cut-through-Switching- Weiterentwicklungen in Ethernet sind inkompatibel und wenig erprobt ˇvorerst hoher Preis ˇeine Vermengung von LAN-Backbone und SAN-Backbone ist nicht stabilitätsfördernd ˇConverged Ethernet Ethernet: Zusatzkompetenzen benötigt ˇkomplexe Kompatibilitätsmatrix ˇgeringes Ansehen außerhalb von Uni versitäten (nur in embedded Form akzeptiert, Vielfaltsproblem) erhöhten den Druck auf Latenzzeiten im Netz, nicht nur lokal, sondern auch bei Wide Area Networks (WANs). Mit FC-SANs war zumindest für den Speicherbereich eine neue Stufe der Zuverlässigkeit erreicht. Doch damit sind die Netzwerktechniken noch nicht am Ende. Eher unbemerkt angesichts der schönen neuen Welt der FC- SANs hat sich eine Parallelwelt entwickelt, in der sich zunächst in einigen Nischen angesiedelt eine Alternative zum etablierten Fibre Channel entwickelte. Das muss nicht einmal, von den bereits erwähnten Anschaffungskosten abgesehen, etwas mit einem inhärenten Mangel des Fibre Channel zu tun haben. Jedes IT-System oder jede IT-Technik weist im Laufe der Zeit irgendeinen Flaschenhals oder eine Beschränkung auf oder kollidiert mit neueren Entwicklungen wie derzeit Fibre Channel mit der Server-Virtualisierung. Man kann iscsi als Versuch ansehen, das vorhandene Wissen über LANs auf die Konstruktion und das Management von alternativen Speichernetzen zu übertragen und damit administrative Anstrengungen zu reduzieren. Statt getrennter Netze einst als Fortschritt gepriesen sollte das vorhandene TCP/IP-Netz nun wieder gemeinsam genutzt werden: Neben und zusammen mit der Kommunikation zwischen Desktops und Servern per Ethernet soll die Übertragung von Daten zwischen den Servern und den Speichersystemen ablaufen. Doch ganz so einfach ließ sich das nicht umsetzen: Die Erfahrung zeigt aber ein anderes Bild: iscsi setzt ein gut administriertes TCP/IP-Netz voraus. In der Regel fordert der Server administrator mindestens zwei unabhängige Datenpfade zwischen Speichersystem und Servern, die nicht mit denen zwischen Clients und Servern kollidieren dürfen. [1] Anfängerfehler mit Folgen Des Öfteren haben Administratoren versucht, das vorhandene Firmen-LAN für ein iscsi-speichernetz samt Failover-Funktionen zu nutzen. Solche Versuche endeten im Desaster. Wichtig wäre es, nicht ein fach loszuexperimentieren, sondern dem Schichtenmodell zu folgen und zunächst eine unabhängige IP-Infrastruktur aufzubauen also (wieder) ein eigenes Speichernetz aufzuziehen: statt auf FC- nun auf Ethernet-Basis. Dies dient dem iscsi- Dienst und dem Speichermanagement einschließlich redundanter Kanäle und Multipathing. Der Installa tionsaufwand besteht IV ix extra 8/2010

5 in solch einer Infrastruktur zweifach: in der Bereitstellung der IP-Infrastruktur und der Implementierung der Speichereinheiten. Zudem benötigt man mindestens 1 GBit/s schnelle Managed Switches mit Funktionen wie Jumbo Frames. iscsi eignet sich für wenig dynamische Netze und für solche mit wenigen Speichereinheiten, also eher für mittel - ständische Unternehmen. Es umgeht zwar die Investition in teures Fibre-Channel-Equipment, zieht allerdings einen höheren Aufwand bei der Konfiguration der TCP/IP-iSCSI-Netze nach sich, besonders wenn ein zweites, unabhängiges Ethernet-Speichernetz aufgebaut wird. Ein FC-Switch in kleineren Umgebungen lässt sich dagegen komfortabel wie eine Mehrfachsteckdose betreiben. Noch vor einigen Jahren bedeutete das eine Reihe von Pluspunkten für FC, mit denen Ethernet nicht mithalten konnte. iscsi hatte zunächst eine Menge von Beschränkungen, vor allem beim Overhead. Doch einige Entwickler konzentrierten sich auf den Protokoll-Stack, und 2004 kam es zu ersten Standardisierungen auf der Softwareseite. Viele Anwender nahmen iscsi jedoch noch immer als Infrastrukturvariante mit eigenen Netzwerkausgaben wahr, ohne auf die Protokollebene zu achten. Auch dies kann als anfängliche Hürde im Durchsetzungsprozess von iscsi gesehen werden. Mit dem Fortschreiten der x86-prozessoren-technik änderte sich die Verarbeitungszeit der in iscsi notwendigen Softwarebefehle: Sie lasteten die CPUs nicht mehr zu fast 80 Prozent aus wie noch in den Tagen von Pentium III oder IV, sondern vielleicht nur noch zu 20 Prozent wie heute bei Prozessoren mit 4 oder 8 Kernen. Software-Implementierungen des iscsi-protokolls gewannen dadurch eine gewisse Attraktivität. Hinzu kommt die Verbreitung von 1-GBit- und 10-GBit- Ethernet, wobei sich weitere Geschwindigkeitszunahmen bis zu 40 oder 100 GBit/s abzeichnen, deren Durchsetzung aber noch einige Zeit dauern wird. Leicht und schnell muss es sein Insofern ist klammheimlich eine Alterna - tive entstanden, deren Implementierung jedoch nicht automatisch günstiger ausfallen muss das hängt auch davon ab, ob ein iscsi-speichernetz wirklich komplett neu aufgebaut werden muss. Eine weitere Neuerung etwa in der gleichen Zeit fand mit Infiniband statt: ein leistungsfähiges Transportprotokoll, das zudem Remote DMA (Direct Memory Access) beherrscht. Da die Hersteller aber noch immer zögern, statt der schweren, unflexiblen Kupferkabel (CX4) Glasfaser zu verwenden, hat Infiniband sich in die Nische des High Performance Computing zurückgezogen. Für diesen Anwendungsbereich existieren aber auch High Performance Storage Cluster, deren Knoten über Infiniband kommunizieren. Allgemein ausgedrückt: Serielle Architekturen mit hohen Takten setzen sich in allen Bereichen durch und beschleunigen den Datentransport. Je schneller man die Daten aus den Geräten heraus ins Netz transportiert, desto wahrscheinlicher werden auch die Bottlenecks dorthin verlagert und vom Netzwerk in die Sto rage- Systeme. Betrachtet man die Speicher- Arrays genauer, findet man auch dort einschneidende Veränderungen: Platten mit höheren Umdrehungsgeschwindigkeiten von 10ˇ000 und 15ˇ000 U/min bis hin zu SSDs (Solid State Drives), die bis zu dreimal höheren Durchsatz liefern als mechanische Festplatten. Damit die einzelnen, in den letzten Jahren performanter gewordenen Komponenten in den Server- und Speichersystemen ihre volle Leistung bringen können, brauchen sie ein FC-Netz mit 8ˇGBit/s oder mehr. Parallele Performance iscsi lebt von der Idee, SCSI-Befehle nicht über ein separates FC-SAN zu schicken, sondern sie in TCP/IP-Pakete zu kapseln und in dieser Form über die bestehende Ethernet-Infrastruktur des Unternehmens zu schicken. FC als Zwischenträger entfällt in diesem Szenario. Doch die FC-Alternative kämpft prinzipiell mit einigen Schwierigkeiten: Dabei darf man nicht vergessen, dass sich serielle SCSI-Varianten, ob übers Netz oder direkt angeschlossen, an der letzten parallelen SCSI-Version messen lassen müssen: Deren 320 MByte/s entsprechen einem Nettodurchsatz ohne Overhead der darunterliegenden Protokolle von 3,2 GBit/s über serielle Leitungen (mit 8B/10B-Codierung). [2] Doch dürfte iscsi von dem derzeitigen Übergang zu 10-GBit-Ethernet und dem prognostizierten zu 40 GBit/s profitieren. Übersehen darf man auch nicht, dass TCP/IP in Anlehnung an das ARPAnet des ix extra 8/2010

6 Pentagon für die Nachrichtenübertragung über große Strecken mit vielen Routern geplant war. Auch Umwege waren explizit vorgesehen. Dies schlägt sich bis heute in der verpflichtenden Bestätigung jedes einzelnen Daten pakets nieder mit der Folge einer systembedingten Grundlatenz und eines großen Overheads. SCSI selbst, das als Anwendungsschicht oberhalb des FC implementiert ist, schickt oder holt auf Basis von Befehlen Daten zu oder von Hosts und Speichergeräten. Das Ein- und Auspacken der SCSI-Daten in TCP/IP- und Ethernet-Pakete erfordert Rechenarbeit, geht also zu Lasten der CPU-Leistung. Die anfangs propagierten iscsi-hardware- Initiatoren, die die Packarbeit ANBIETER VON ETHERNET-STORAGE an spezialisierte Chips auf HBAs delegieren, konnten sich nicht durchsetzen: Sie waren unzureichend ausgerüstet und konnten leistungsmäßig nicht mit den von Cisco und Microsoft propagierten Software - lösungen mithalten. Zudem nahmen die Serverhersteller eine Integration dieser Software in ihre Betriebssysteme vor. Für CPU-Entlastung sorgen heute eher TCP/IP-Offload-Engines. Zu den weiteren Einwänden, die gegen ein Ethernet-gestütztes SAN erhoben werden, gehören Verweise auf die Hacker- Anfälligkeit der LAN-Protokolle, die unterschiedlichen Qualitätsanforderungen zwischen dem Client/Server-Verkehr und dem Host-Storage-Verkehr sowie die Überprüfung der Kostenvorteile, die ein iscsi-netz bieten soll. iscsi-platzhirsch Dell ist insofern in einer guten Position, als das Unternehmen mit dem Gestus auftreten kann, für alle Kundenanforderungen etwas anbieten zu können: Wem iscsi nicht passt, dem kann man die ganze FC-SAN-Lösungspalette des Partners EMC, die Dell inzwischen sogar unter eigenem Brand vermarktet, zur Verfügung stellen. Natürlich fährt Dell besser, wenn es die eigenen iscsi-produkte mit einer selbst definierten Marge verkaufen kann, als wenn es diese mit dem OEM-Partner teilen muss. Zudem engagiert sich Dell stark im Bereich der Server-Virtualisierung. Beispielsweise Hersteller Produkt Website 3PAR SAN Advanced UniByte iscsi-san, NAS Brocade Switches, Ethernet-Komponenten (Foundry) Cisco Server, Switches, FCoE-Komponenten Compellent SAN CPI Storage, HBAs, Netzkomponenten Dell Server, Storage, iscsi EMC Storage, iscsi, NAS Emulex HBAs, Switches, FCoE-Komponenten Enhance Technology SAN, Netzkomponenten EUROstor Storage, iscsi, NAS Fujitsu Server, Storage, IP-SAN HDS Storage, iscsi, NAS Hewlett-Packard Server, Storage, NAS, Netzkomponenten IBM Server, Storage, iscsi Infortrend Storage, iscsi Juniper Netzkomponenten LSI Storage NetApp Unified Storage, NAS Netgear Netzkomponenten N-Tec iscsi-san, NAS, Netzkomponenten Oracle/Sun Server, Storage Overland Storage NAS (Snap Server) overlandstorage.com QLogic HBAs, Switches, FCoE-Komponenten Quantum Storage RaidSonic Storage, NAS starline Storage, iscsi, NAS Thomas Krenn Server, Storage, Netzkomponenten TIM AG iscsi-san, NAS transtec Storage, NAS, Netzkomponenten Diese Übersicht erhebt keinen Anspruch auf Vollständigkeit. enthält die neue Firmware-Version 5.0 der EqualLogic-iSCSI- Systeme, die ab Sommer 2010 ausgeliefert und allen bestehenden Dell/EqualLogic-Kunden kostenlos zur Verfügung gestellt wird, außer neuen Funktionen für automatisches Tiering mit SSD-Speichermedien sowie Funktionen für Thin Clones spezielle Anpassungen an VMware ( VM aware sto - rage ), die Dell zukünftig auch auf Citrix und Microsoft ausdehnen will. Fazit Inzwischen haben sich die Fraktionen von Fibre Channel und iscsi auf eine Art Arbeitsteilung geeinigt iscsi in mehr mittelständischen Umgebungen ohne allzu hohe Verfügbarkeitsanforderungen, und FC für große Unternehmen mit geschäftskritischen Anwendungen wie Oracle-Datenbanken oder Customer Relationship Management (CRM). FCoE steckt noch immer mitten in den Standardisierungsprozessen, und von einem Druck der Kunden, die unbedingt diese neueste Variante eines Converged Network haben wollen, ist weit und breit nichts zu sehen. Bis jetzt ein klassischer Fall von herstellergetriebener Paperware [3]. (sun) Hartmut Wiehr ist freier Journalist. Literatur [1]ˇMario Vosschmidt, Hartmut Wiehr; SAN; Gut eingebunden; Speichernetze und ihre Verwaltungsinstrumente; ixˇ8/2008, S.ˇ122 [2]ˇHartmut Wiehr; Storage; Wenn das Gute so nahe liegt; Speichernetze im LAN; ixˇ8/2009, S.ˇI [3]ˇJoe Skorupa; Myth: A Single FCoE Data Center Network = Fewer Ports, Less Complexity and Lower Costs; Gartner, März 2010 VI ix extra 8/2010

7 Nie am Ziel Was taugt Fibre Channel fürs SAN? Rechenzentren setzen meist Fibre Channel als Protokollstandard zur Kommunikation zwischen Servern und Storage-Farmen ein. Weiterentwicklungen und neue Standards wie Fibre Channel over Ethernet bieten eine gute Gelegenheit, einen Blick auf die Entwicklung von Fibre Channel zu werfen. Um die Eignung von Fibre Channel bewerten zu können, bedarf es zunächst eines kurzen Blicks auf das ursprüngliche SCSI-Protokoll. Entwickelt wurde das Small Computer Systems Interface zur Übertragung der Daten innerhalb eines Systems, genauer zwischen der Zentraleinheit und dem peripheren Massenspeicher, etwa zwischen Mo - therboard und Festplatte. SCSI hat sich zunächst im Bereich der Unix-Betriebssysteme etabliert. Mit Microsofts Einstieg in die Serverwelt folgten Implementierungen für die Windows- Betriebssysteme. Die angeschlossenen Geräte und HBAs bildeten immer eine abgeschlossene Umgebung. Somit war es geradezu verführerisch für Hersteller, die eine oder andere Abweichung vom Standard beziehungsweise eine eigene Interpretation des Standards zu implementieren. Dass man eine Festplatte anfänglich zwar mit einem Betriebssystem verwenden konnte, nicht jedoch mit einem anderen, sollte angeblich für Stabilität sorgen, sicherte aber auch den Marktanteil gegenüber Konkurrenten. Der Grund für ein solches Plattenverhalten liegt in speziellen Protokollfunktionen für Informationen und Statusabfragen im SCSI- Protokoll. Als Folge davon verlangen einige Storage-Systeme noch heute für das Bereitstellen von Volumes die Angabe des Betriebssystems. Wollte man also einen allgemeingültigen Standard schaffen, wurde man gleich mit mehreren Herausforderungen konfrontiert. Sie betrafen unter anderem Durchsatz, Restriktionen der Leitungslänge, redundante Anbindungen und das Zusammenspiel mehrerer Initiatoren und mehrerer Geräte/Ziele in einer Umgebung. Ausgangspunkt dafür waren die physischen Übertragungsmöglichkeiten. Um die bisherige Verzahnung von physischem Interface und Protokoll zu entzerren und die Entwicklung zu beschleunigen, führte man entsprechend dem OSI-Modell ein Schichten-Modell ein. Jede Schicht ist dabei separat mit sämtlichen Varia - tionen definiert. Darin ersetzt Fibre Channel nur die Physical und Signalling Layer des SCSI-Protokolls, während SCSI noch immer den Upper Layer bildet. Verwöhntes SCSI Die Unabhängigkeit der einzelnen Layer bei Fibre Channel ermöglicht auch heute noch ein einfaches Upgrade, etwa auf der physischen Schicht FC-0: Durch Austausch der SFP- Transceiver (Small Form-Factor Pluggable Interfaces) und Glasfasern kann man sehr einfach von Multimode auf Singlemode wechseln und damit die mögliche Entfernung von wenigen Hundert Metern auf bis zu über 100 km erhöhen. Für solch extreme Entfernungen ist dann die Bereitstellung von speziellen Buffern vorausgesetzt. In Bezug auf eine zuverlässige Übertragung sind die höheren Ebenen des SCSI-Protokolls ausgesprochen verwöhnt. Auf einem SCSI-Bus gab es kaum Bitfehler entweder der Bus funktionierte oder man tauschte die Komponenten: Abschlusswiderstand, Kabel, Platten, HBAs. Es konnte auch keine Rahmenüberholungen geben es gab ja nur einen Weg vom Master zu den Slaves. Und das wichtigste: Jeder Slave hatte nur einen Master. Somit war das SCSI-Protokoll auf Effizienz getrimmt: schnelle Verschiebung von gespeicherten Blöcken, maschinennah und in State Machines implementiert. Fehlerbehandlung und Reaktionen auf Bitfehler sollten die Ausnahme bleiben. Eine Bitfehlerrate von ist im Standard verankert das entspricht aber immerhin einem Fehler etwa alle 17 Minuten bei einer Übertragungsgeschwindigkeit von 1ˇGBit/s. Die Retransmission Timeouts sind im SCSI-Protokoll mit bis zu 60 Sekunden implementiert. Wer will schon jede Viertelstunde einen Freeze in seiner Applikation von bis zu einer Minute haben? Daher gilt als Best-Prac - tice-empfehlung eine Bitfehlerrate von weniger als und somit etwa alle 11,6 Tage. Die Hürde der Bitfehlerrate haben die Entwickler genommen, und ein höherer Durchsatz, mehrere Initiatoren sowie redundante Anbindungen eröffnen der Open-Systems-Welt nun weitere Möglichkeiten, etwa ein einfacheres Clustering von Servern, Spiegelung von Daten oder Verteilung über Gebäudegrenzen hinweg. Die ursprüngliche Fibre Channel Arbitrated Loop hat schon viele bis dahin gültige Einschränkungen überwunden. Ein Vergleich mit FDDI (Fiber Distributed Data Interface) lässt erahnen, dass Fibre Channel den Lichtwellenleiter-Metro- Ring nicht nur bei den Funktionen beerbt hat, sondern wohl einige FDDI-Entwickler direkt beteiligt waren. Mit der Konsequenz, dass FC mit seiner Zuverlässigkeit nicht nur SCSI transportieren kann, sondern darüber hinaus weitere Upper- Layer-Protokolle definiert. Beispielhaft sei hier das Virtual Interface erwähnt, welches etwa zur Steuerung von Waffensystemen in der Luftfahrtindustrie eingesetzt wird. Höher, schneller, weiter Der Trend zu immer mehr Speichersystemen und Servern in einem Speichernetz hat dann zur Entwicklung der Switched Fabric Topology geführt. Dabei schielten die Entwickler durchaus auf die Erfolge des Ethernet, doch galt weiter die Her - ausforderung, dass keine Frames in der Fabric verloren gehen sollen. Nimmt man diese Topologie mit ihren Besonderheiten ernst, trifft eigentlich das häufig genutzte Synonym SAN, also Storage Area Network, nicht zu. Eine FC-Fabric entspricht eher einem verteilten Punkt-zu-Punkt-System und nicht einem Netz im klassischen Sinne. Die Übertragung von Rahmen durch eine Fabric, frei von Frame-Verlusten, ohne Frame-Überholungen, gleichberechtigt für alle Teilnehmer mit Transferzeiten im Mikrosekunden-Bereich, stellt bis heute die Herausforderung dar, die SCSI mit auf den Weg gibt. Eine Hürde, die auch FCoE zu nehmen hat, wenn es erfolgreich sein will. Darüber hinaus gibt es bei FC sinnvolle Features, die die gegenwärtige Aktualisierung des Standards nicht überleben werden. Von den Class of Services, die maßgeblich das ix extra 8/2010 VII

8 Buffer Management in der Fabric beschreiben, wird der Class of Service 1 demnächst entfallen. Dabei garantiert gerade dieser Class of Service eine bestimmte Bandbreite End-to- End. Aber die Implementierung hat sich als zu aufwendig her - ausgestellt. Einzig der von Broadcom 2003 aufgekaufte Hersteller Gadzoox Networks hatte sie in die Praxis umgesetzt. Seither haben sich die Anforderung an das Design moderner FC-Fabrics geändert. Bei der Entwicklung von FC hat wohl kaum jemand an Fabrics mit Entfernungen von über 100 km, mit über 1000 Ports und mehreren 10ˇ000 Zonen gedacht. Außerdem sollen noch alte Server mit 1 GBit/s schnellen Ports über 16 GBit/s schnelle ISLs (Inter-Switch-Links), wie sie für dieses Jahr angekündigt sind, auf Storage-Systeme mit 8ˇGBit/s zugreifen können. Ungeklärt ist auch, ob man wirklich alle neuen Features und Geschwindigkeiten braucht. Aus der Sicht des Trouble - shooting für FC-SAN-Umgebungen stellt sich hier die Frage, ob nicht zunächst ein anderer Typ von Evolution vonstatten gehen muss. Dabei muss man sich Folgendes klar machen: In den Anfängen des Ethernets hat sich kaum jemand um die Protokolle selbst gekümmert wenn das Netzwerk mal wieder Schuld war, wurden erst mal die Abschlusswiderstände getauscht, die Verkabelung geprüft, einzelne Stationen vom Netz getrennt, um auszuprobieren, ob es dann wieder funktioniert. Doch nach und nach waren die Administratoren diese umständlichen Prozeduren leid und wollten wissen, was tatsächlich in ihrem Netz passiert. Praktische Folge: Kabeltester, Protokoll-Analysatoren und Monitoring-Systeme gehören heute zur Standardausstattung der Netzwerkabteilungen viele Unternehmen veranschlagen in ihrem Budget sogar etwa zehn Prozent explizit für solche Zwecke. Trial and Error Das Kommunikationsaufkommen zwischen Unternehmensstandorten sowie Firmen und ihren mobilen Mitarbeitern wächst rasant und damit auch die Notwendigkeit sicherer Datenverbindungen. Virtual Private Networks (VPN) ermöglichen den sicheren Zugriff aus dem Internet auf das Firmennetz oder die Verbindung von Firmenstand - orten über öffentliche IP-Netze. Mit IPSec-, SSL- oder MPLS- VPNs stehen dafür unterschiedliche Varianten beziehungsweise Techniken mit jeweils spezifischen Stärken zur Verfügung. Im SAN dagegen herrschen noch immer Trial und Error, wie in reinen SCSI-Zeiten. Doch dies ist in den komplexen SAN- Umgebungen von heute nicht mehr zeitgemäß. Kaum ein Applikationsverantwortlicher kann die I/O-Last im SAN auch nur annähernd benennen, geschweige denn voraussagen. Der SAN-Administrator ist auf seine Erfahrung und auf seine hellseherischen Fähigkeiten angewiesen. Viele Probleme werden mit überdimensioniertem Durchsatz und teurem Over-Provisioning erschlagen. Andersherum sorgt die Server-Virtualisierung durch ihre Konsolidierung für neue Engpässe. Die Tatsache, dass ein physischer Host in einer virtualisierten Umgebung die Ressourcen für ein ganzes Bündel von Servern und ihren Anwendungen zur Verfügung stellen muss, erschwert Vorhersagen zur I/O-Last immens. Bei einer Umstellung auf virtuelle Server greifen dann auch die Erfahrungen der SAN-Administratoren nicht mehr. Die Undurchsichtigkeit im SAN könnte dazu führen, dass mancher iscsi dann doch für die bessere Wahl hält. Doch im LAN hört das Management bei der TCP-Ebene auf, oberhalb der TCP-Ebene sind allenfalls noch die Firewall-Administratoren aktiv. Den Block-I/O auf das LAN zu verschieben, behebt nun mal nicht die mangelnde Transparenz im SAN. Zwar existieren Protokoll-Analyser In ix extra 09/2010 Networking Virtual Private Networks VPNs spielen aber nicht nur im Unternehmenseinsatz eine Rolle auch für den privaten Nutzer werden sie immer interessanter, und etliche Heimrouter verfügen mittlerweile über entsprechende Funktionen. Häufig wird die VPN- Funk - tion direkt in Router oder Firewalls integriert. Aber auch Hardware-Speziallösungen sogenannte Appliances und reine Softwarelösungen finden sich am Markt. Der Anwender hat somit die Möglichkeit eigener Installation (Customer-managed), kann jedoch auch VPN- DIE WEITEREN IX EXTRAS: für FC-Netze, doch sind sie kostspielig und in SAN-Etats nicht vorgesehen. Integrierte Analysefunktionen auf Serverseite, in der Fabric und auf den Storage-Systemen liegen noch weit hinter dem zurück, was in den IP-Wolken zum Standard gehört. Wie soll ein erfolgreicher Umstieg auf FCoE funktionieren, wenn nicht einmal die bisherigen FC-Implementierungen bis in die Details verstanden werden, und SAN-Administratoren nicht wissen, was in ihren Fabrics passiert? An diesem Punkt sind die Hersteller von SAN-Equipment gefordert, mehr Funktionen zur Überwachung und Analyse über standardisierte Schnittstellen zur Verfügung zu stellen. (hw/sun) Jan Bartels ist Geschäftsführer der Men@Net GmbH. Dienste vom Service-Provider (Provider-provisioned) in Anspruch nehmen. ix extra 09/2010 erklärt die Grundlagen, erläutert die Unterschiede der möglichen Sicherheitstechniken und gibt einen Überblick über verfügbare Hardware- und Softwarelösungen sowie über VPN-Serviceange - bote. Marktübersichten von Anbietern von VPN-Hard- und -Software sowie von VPN-Services runden das ix extra ab. Erscheinungstermin: 19. August 2010 Ausgabe Thema Erscheinungstermin 10/10 Embedded Systems SE für Automotive Computing /10 IT-Security Virenscanner gegen Malware-Trends /10 Storage Storage as a Service Archivierung, Dokumentenmanagement und mehr VIII ix extra 8/2010