SAN und NAS - Speicher für Exchange

Vielleicht haben Sie immer wieder die unterschiedlichen Aussagen zu Exchange und Festplattenspeichern gelesen und gehört:

  • Exchange läuft nicht mit NAS ?
  • Exchange läuft mit NAS ?
  • SATA/IDE ist schlecht ?
  • Exchange braucht kein RAID ?
  • SCSI-Festplatten sind schneller und besser als SATA/IDE ?
  • Exchange läuft nicht mit SAN ?

Um es kurz zu machen. Es gibt viele Aussagen zu Exchange, die alle ein Körnchen Wahrheit haben nicht unbedingt zu Klärung beitragen. Vielleicht ein paar Worte zu Klärung von meiner Seite:

  • Microsoft Exchange benötigt "Festplatten" zum Ablegen der Informationen
  • Diese Festplatten sollten groß genug sein, alle Daten aufzunehmen
  • Diese Speicher sollten schnell genug sein, um auch Exchange nicht auszubremsen
  • Diese Speicher sollten Ausfallsicher sein, damit beim Defekt einer Festplatte nicht die Daten darunter leiden.
  • Exchange kann die Datenbanken nicht auf "Netzwerklaufwerke" ablegen. Exchange erwartet "lokale Festplatten"
  • ABER
    Exchange 2003 kann mit einem besonderen Feature Pack seine Daten auf einem Windows 2003 NAS-Server ablegen (Stand Mai 2004)
    (Siehe hierzu auch Abschnitt am Ende)

Zwar nutzt Exchange ausgeklügelte Cachestrategien, um die Zugriffe zu optimieren. Und auch die Online Sicherung der Datenbank erlaubt sehr einfach die Wiederherstellung von einem Band. Die Nutzung von Transaktionsprotokollen erlaubt meist sogar die Wiederherstellung bis zum Moment des Defekts. Aber nur weil viele Sicherungsmechanismen in Exchange vorhanden sind, dürfen Sie nicht das Fundament verwässern.

Von der Anwendung zu den Bits

Exchange können Sie genau so betrachten wie jedes Betriebssystem und Anwendungen wie Office. Exchange arbeitet mit Informationen und muss diese auch Speicher. Dazu dienen Festplatten. Aber es ist ein langer weg vom Hauptspeicher zum Sektor auf der Festplatte. Das ganze Sieht etwa so aus:

Sie schreiben einen Brief mit Word und dieser wird gespeichert.

Über einen UNC-Pfad oder ein verbundenes Netzwerklaufwerk schreiben die die Dateien weg.

Die Daten werden über das LAN übertragen. Bei Windows wird dazu meist das Protokoll SMB über NetBIOS over TCP/IP genutzt.

Die Gegenstelle ist der "Server". z.B. Windows 2003 Server oder Samba.

Der schreibt die Datei über sein Dateisystem (NTFS) auf eine logische Festplatte. NTFS macht aus den "Dateien" nun handliche "Blöcke" für die Festplatte.

Diese Blöcke werden zur Festplatte gesendet. z.B.: an lokale Festplatten  über ATA, SATA oder SCSI.

Festplatten müssen aber nicht "im" Server sein, sondern können entfernt stehen. z.B.: mit langen  SCSI-Kabeln oder über Fiber Channel oder andere Weg wie iSCSI über Ethernet. Letztlich unterscheidet sich nur die Physik.

Wichtig ist für sie das Verständnis der drei Schichten:

  • Netzwerklaufwerke
    sind Pfade für die Ablage von Daten. Nur Programme, die auf solche logischen Speicherbereiche zugreifen können, können diese nutzen. Exchange gehört "NICHT" dazu
  • Lokale logische Laufwerke
    Dies sind für das Betriebssystem eigene Festplatte, die es direkt C:, D: etc. ansprechen kann ohne ein Netzwerk zu benötigen. Ein logisches Laufwerk ist meist eine Partition auf einem physikalischen Laufwerk
  • Physikalische Laufwerke
    Dies sind aus Sicht von Windows die eigentlichen "Festplatten", auf denen das Betriebssystem blockweise liest und schreibt der NTFS-Treiber muss dazu die komplette Verwaltung übernehmen und die Daten korrekt anordnen. Windows greift auf diese Festplatten z.B. über so genannte SCSI-Miniport Treiber zu.
    Allerdings muss dies nicht wirklich eine "Festplatte" sein. Oft sind RAID-Controller und andere Systeme dazwischen, die wiederum den Zugriff virtualisieren. Was Windows als eine Festplatte erkennt, kann z.B. ein Verbund aus 3 Festplatten als RAID5 sein.

Blockdevice und Filedevice

Aber gerade der Begriff "Lokale Festplatten" sorgt immer wieder für Verwirrung. Es müsste genauer heißen, dass das Betriebssystem ein "Blockdevice" anbietet. Und das ist im einfachsten Fall eine normale Festplatte am IDE-Bus. Das kann aber auch eine virtuelle Festplatte sein, die einem RAID-Controller bereitgestellt wird. Es ist ebenfalls nicht vorgegeben, dass die Festplatte zwingend im Servergehäuse eingebaut ist. Auch externe Festplatten sind möglich, wobei hier auch keine Aussage getroffen ist, ob hierzu eine SCSI-Kabel, Glasfaser mit Fiber Channel oder sogar ein Netzwerk zur Übertragung genutzt werden. Solange Windows davon überzeugt ist, dass es sich um eine echte Festplatte handelt, die als "Blockdevice" (SCSI-Miniport Treiber) angesprochen werden kann, wird darauf auch Exchange die Daten ablegen können.

SAN und Fiber Channel

Wer von SAN spricht, sieht zuerst große Massenspeicher von EMC, Fujitsu Siemens und anderen Herstellern, die große Datenmengen zentralisiert speichern können, von hohen Kosten für die Infrastruktur und die Hostadapter in den Servern. Die meisten Lösungen hierbei werden mit Fiber Channel und entsprechenden Adaptern aufgebaut, die lange Zeit sehr teuer und exklusiv waren. Diese Strukturen waren aber von Anfang an darauf ausgelegt, eine hoher Verfügbarkeit mit garantierten Übertragungszeiten zu gewährleisten. Dinge, die erst mit der Verbreitung von Switches im Ethernet möglich geworden sind.

Durch die frühe Festlegung auf "Speichernetzwerk" und die Dominanz von SCSI konnten zudem viele Funktionen eines Fiber Channel auf eben dieses Protokoll zugeschnitten werden. So können über einen Fiber Channel Adapter in einem Server mehrere Festplatten aber auch Bandlaufwerke angebunden werden. Das funktioniert sogar parallel, so dass mehrere Systeme sich die gleiche Bandlibrary teilen können. Dinge, die mit klassischen SCSI-Kabeln nicht oder nur sehr teuer möglich sind. Von der Kabellänge ganz zu schweigen.

Das wichtigste dabei ist aber, dass die zentrale Speichereinheit die Konsolidierung von Daten auf einer hochverfügbaren Box erlaubt. Warum sollten Sie zehn Server so konfigurieren, dass auf allen eine "Platzreserve" ist, wenn Sie in sechs Monaten doch in die Verlegenheit kommen, dass ein Server voll ist, während die anderen noch Luft hätten. Beim Einsatz einer zentralen Speichereinheit können Sie hier flexibel Kapazitäten zuweisen. Meist funktioniert das ganze sogar im laufenden Betrieb. Selbst Erweiterungen, Firmwareupdate etc. sind bei solchen Systemen möglich. Hinzu kommt, dass Sie häufig auch die Daten ohne den Server sichern können oder Kopien auf eine räumlich entfernte Box ablegen können (Hochverfügbarkeit). Ein weiterer Aspekt ist, dass auch mehrere Systeme gleichzeitig auf die gleichen Datenbereich zugreifen könnten. Dies ist z.B. für den Einsatz von Microsoft Cluster notwendig.

Aber nirgendwo ist festgelegt, dass all diese Funktionen zwingend über Fiber Channel realisiert werden müssten. Allerdings ist mit Fiber Channel es sehr einfach möglich, die SCSI-Befehle zu übertragen. Aber seit iSCSI können diese Befehle auch in TCP/IP eingepackt werden. Trennen Sie daher ihre Ansichten, wenn Sie über SAN sprechen. Genau genommen sprechen Sie über ein Kommunikationsnetzwerk zur Übertragung der Daten zwischen den Servern und den Speichereinheiten.

Auf der einen Seite stehen die Server, auf der anderen Seite der zentrale Festplattenspeicher und dazwischen vermittelt die Daten ein Speichernetzwerk (SAN). Wichtig dabei ist, dass der Speicherplatz für den Server wie eine lokale Festplatte dargestellt wird. Die zentrale Speichereinheit ist kein Dateiserver, sondern ein Festplattenserver.

NAS, Ethernet und TCP/IP

Nun könnten Sie auch auf den Gedanken kommen, einen der günstigen NAS-Systeme einzusetzen, um preiswert einen Netzwerkspeicher für Exchange zu erhalten. Viele Anbieter preisen ihre NAS-Systeme sogar als einem SAN ebenbürtig an mit sehr viel geringeren Kosten. Dabei müssen Sie aber GENAU hinschauen.

Sowohl NAS als auch andere Massenspeicher benötigen Festplatten, Netzteile, Server, Support etc. Und diese Kosten sind vergleichbar hoch. Günstigere Preise müssen NAS-Systeme durch den Einsatz billigerer Komponenten, weniger Funktionen oder anderer Einschränkungen erreichen. Sehr viele NAS-Systeme verzichten dabei auf schnelle Festplatten oder nutzen kostengünstigere IDE-Systeme. IDE ist nicht generell schlechter als SCSI. Siehe dazu auch IDE oder SCSI.

Aber viele NAS-Systeme sind im Endeffekt auch normale PCs, die mit einer angepassten Windows 2003 NAS-Edition oder Linux Distribution betrieben werden. Dieses Systeme können meist weder Domain Controller sein, noch sonstige Zusatzdienste betreiben. Aber diese NAS-Systeme werden direkt am Netzwerk angeschlossen, bieten "Dateifreigaben" im Netzwerk an und sind sehr einfach zu administrieren. Dabei wird in der Regel nicht nur "NetBIOS/SMB" unterstützt, sondern häufig auch AppleTalk/Ethertalk, NFS und andere Protokolle.

Dies sind aber alle "Dateisharing"-Protokolle, bei denen der Client, der diese Datenbereiche nutzt, keine "Blöcke" schreibt, sondern Dateien. Aus Sicht ihres Arbeitsplatzes aber auch des Exchange Servers sind diese Festplatten "Netzwerklaufwerke". Mit diesen Speichern kann Exchange nicht arbeiten. Auf diesen System läuft ein "Dateiserver", kein "Festplattenserver".

Was ist mit iSCSI ?

(Siehe auch MSXFAQ - iSCSI)

Aber die Grenzen verschwimmen. So ist es möglich, ein Verzeichnis auf einem NAS-System z.B. über NFS auf einem Windows Server zu "mounten" und dabei wie eine lokale Festplatte aussehen zu lassen. Auch gibt es mittlerweile Miniport Treiber für Windows, die eine große Datei auf einem NAS-System ansprechen und für Windows als Festplatte darstellen. In diese Richtung geht auch iSCSI und andere Techniken. In diesem Fall ist der NAS-Server zwar ein "Dateiserver", aber der Treiber auf dem Exchange Server simuliert eine Festplatte.

In Zeiten von Gigabit Ethernet, Adapter Teaming, Port Trunking etc. ist es im Hinblick auf die Transferrate und Antwortzeiten auch möglich, solche  "Blocktransfers" als Ethernetpaket über IP zu übertragen. Sie müssen nur die gleiche Verfügbarkeiten sicherstellen, die bei Fiber Channel "per Design" schon immer vorhanden sind. Aber in diesem Moment betreiben Sie kein NAS mehr, sondern ein SAN, bei dem aber ein "Ethernet" bzw. TCP/IP das Übertragungsmedium ist. Nach einigen proprietären Ansätzen scheint sich iSCSI als Standard hier zu etablieren.

So gibt es von Microsoft einen iSCSI-Initiator für Windows 2003. Weitere Details finden Sie auf MSXFAQ - iSCSI. Aber auch umgekehrt findet eine erweiterte Nutzung statt. So ist es heute problemlos möglich, über klassische SAN-Strukturen mit FiberChannel auch TCP/IP-Netzwerke aufzubauen.

Der einfache Server ist NAS und SAN in einem

Ein einfacher Dateiserver besteht aus den gleichen Komponenten wie ein "großes" SAN. Der Zugriff der Anwender erfolgt über das Netzwerk. Der lokale Serverdienst nimmt die Anfragen entgegen und gibt diese an den NTFS-Treiber weiter. Dieser schreibt die Daten auf die Festplatten.

Auch hier ist ein "kleines" SAN am Werk. Im Server ist ein Festplattenkontroller, der über ein Kabel (50 pol SCSI, 40pol IDE, 4pol, SATA, 68pol uW-SCSI) eine Verbindung zu einem Massenspeicher herstellt.

Es muss nicht immer eine Grosse externe Speicherbox sein, an der viele Server angeschlossen werden, um ein "Speichernetzwerk" zu betreiben.

Der Begriff SAN bedeutet aber, dass über ein eigenes Netzwerk "Blockdaten" zwischen Servern und müssenspeichern ausgetauscht werden können.

Ein SAN-Netzwerk arbeitet im Prinzip wie ein normales Ethernet, nur dass die Daten keine "Dateien" sondern Festplattenblöcke darstellen. SAN sagt erst mal nichts über die Kabel und die Protokolle aus. Insofern ist auch das Protokoll "ATAPI über die IDE-Schnittstelle ein kleines SAN.

Aber natürlich nennen viele Firmen ein SAN erst dann so, wenn mehrere Server und mehrere Datenspeicher zusammengeschaltet werden.

Übrigens ist so ein Server ein "NAS-Server", denn der Zugriff erfolgt über das Netzwerk unter Nutzung von "Dateisharing Protokollen"

Also "Jeder" Windows Server können Sie auch als "NAS-Server" betrachten. Nicht umsonst gibt es auch von Microsoft ein "Windows powered NAS", was ein fast vollständiges Windows Betriebssystem ist. Sie benötigen dazu keine weiteren CALs. Allerdings können Sie dieses nur zusammen mit einem entsprechenden Hardwarekauf bei bestimmten Firmen erwerben. Ein NAS-Server muss daher nicht immer mit Linux oder einen proprietären System ausgestattet sein.

Ist ein NAS auch ein SAN ?

Nun verwischt die Grenze zwischen NAS und SAN immer mehr, da viele Hersteller, die bislang einfache "Dateiserver" an ein Netzwerk angeschlossen haben, diese nun als SAN-Server verkaufen.

Die Argumentation dahinter ist ganz einfach:

Nirgendwo steht geschrieben, dass zwischen dem Serverdienst und der eigentlichen Festplatte immer nur IDE oder SCSI sein muss.

Schon lange gibt es "Fiber Channel". Hierbei werden spezielle Komponenten zusammengesteckt, die optimiert sind für die Übertragung von immer gleich langen Blockbefehlen.

Nun ist es aber heute so, dass viele Systeme mehrere Netzwerkkarten haben und auch zentrale Switches mit Gigabit nicht mehr allzu teuer sind.

Da stellt sich die Frage, warum eine Fiber Channel Karte viel Geld kostet und 1-2 Gigabit überträgt, und die Gigabit Ethernet Karte schon onboard ist und nominell gleich schnell ist. Aus dem Grund gibt es Standards wie "iSCSI", die nichts anderes definieren, als die Übertragung von Blockbefehlen über TCP/IP.

Damit werden kostengünstige Netzwerkkomponenten plötzlich interessant für Speichernetzwerke. Es fehlt nur noch der "Massenspeicher", der iSCSI versteht. Und hier springen viele Hersteller auf, die ihre NAS-System um eine iSCSI-Funktion nachrüsten.

Allerdings müssen Sie im Server nun einen passenden Treiber installieren, der diese Festplatten anspricht. Diese entfernten über TCP/IP und Ethernet angebundenen Festplatten werden dann für ihren Server sichtbar, als wären es lokale Festplatten.  Damit ist dies aber kein NAS mehr, sondern in iSCSI-Server. Und damit kann Exchange wunderbar arbeiten.

Aber es gibt doch noch einige unterschiede: Der Preisunterschied zwischen SAN-Komponenten auf Basis con Fiber Channel und dem Aufbau eines SANs mit iSCSI über normale Netzwerkkomponenten ist nicht ganz ungerechtfertigt.

Es ist nicht damit getan, einfach ein paar Netzwerkkarten und Switche zu verbinden und einen iSCSI Treiber zu laden. Redundante Switche, Adapter Teaming, Quality of Service und die Abschottung von Systemen, die sich nicht sehen dürfen (Zoning bzw. VLAN) sind Dinge, die mit Fiber Channel schon lange bekannt sind. iSCSI muss ich hier erst noch beweisen. Sowohl im Hinblick auf Stabilität, Performance aber auch Sicherheit und Kompatibilität zwischen den Systemen werden hier noch sehr viele Erfahrungen gesammelt. (Man könnte auch sagen: Sehr viele Probleme gefunden und behoben.

Performance im SAN und DAS

Ein wichtiger Aspekt des Massenspeicher ist die Performance. Dabei darf man aber nicht die in den Datenblätter der Festplatten angegebenen "Megabyte/Sekunde"-Transferraten heranziehen, sondern für Exchange gelten auch Faktoren wie Zugriffszeiten, Drehzahl etc. Im gleichen Gegenzug wird oft gesagt, dass ein SAN "schneller" ist als eine lokale Festplatte. Ernüchterung macht sich dann aber erst mal breit, wenn das SAN angeschlossen ist und der "XCOPY" sogar langsamer ist, als auf einer lokalen Festplatte. Auch Tests wie DT oder IOMeter scheinen nicht wirklich den Turbo zu aktivieren. Aber das sollte Sie erst mal nicht erschrecken, weil der Zugriff eines Server nun mal nicht mit einer "single threaded"-Applikation wie XCOPY simuliert werden kann. Da sind Tools wie JetStress schon eher geeignet.

Das soll aber nicht Thema dieses Abschnitts sein, sondern hier möchte ich der Fragestellung nachgehen, warum ein SAN denn dennoch schneller sein soll, als eine lokal angeschlossene Festplatte. Eigentlich gibt es nämlich keinen Grund hierzu, da die Festplatten hier und da vergleichbare technischen Merkmale vorweisen. Auch am Anschluss alleine kann es nicht liegen

  • IDE, Serial ATA, SCSI, Firewire als "Direct Attached Storage" (DAS)

    Die Geschwindigkeit der heute installierten Verbindungen ist allemal höher als der Durchsatz der Festplatten. Dabei ist es fast egal, welche physikalische Anbindung genutzt wird
  • iSCSI oder FC
    Auch die Anbindung per SAN bedeutet ja für den Server, dass er "lokale" Festplatten vorfindet, die aber weiter entfernt stehen können und eine entsprechende Vermittlungsinfrastruktur die Daten überträgt. Hier ist mit 1,2,4 GB/Sek auch meist genug Bandbreite vorhanden.

    Wobei Sie sich immer daran erinnern sollten, dass es nicht das SAN selbst ist, welches Performance bringt, sondern das Disksystem dahinter. Das "SAN" ist eigentlich nur die Verbindung zwischen den Komponenten. Wenn Sie von einem "Netzwerk" sprechen, dann sind damit ja genau genommen auch nur die Switches Hubs, Router,  Kabel und die Netzwerkkarten an den Clients und Servern gemeint, aber nicht die Server selbst.

Vor allem ist es möglich, sich das Disksubsystem mit mehreren anderen Servern zu teilen und das hat durchaus Vorteile, da hier mehr Geld investiert werden kann, was dann gleich allen Servern zugute kommt:

  • Leistungsfähige RAID-Controller
    Besonders leistungsfähige Controller erlauben sehr viel schnellere Berechnungen von Parity etc.
  • Performance durch RAM
    Viel Speicher im Disksubsystem wird dynamisch zwischen allen Systemen gemeinsam genutzt.
  • Performance durch Datenverteilung
    Viele Festplatten erlauben eine Verteilung der Daten auf mehrere Festplatte. Es muss dabei auch gar nicht mehr zutreffen, dass ein Server "seine" Festplatten hat.

Verallgemeintert basiert die schnelle Performance eines SAN auf der Verteilung der Last im Speichersubsystem auf viele Schultern. Damit bekommt ein aktiver Server eine bessere Performance zu Lasten der anderen weniger aktiven Server, die die Leistung gerade nicht abrufen.

Früher hat ein Server "Seine" LUN (Logical unit) gehabt, die meist identisch mit einer Festplatte oder einem RAID-Laufwerk war. Moderne Disksubsysteme (und hier ist es egal, ob die nun per FC oder iSCSI an den Server verbunden sind) nutzen möglichst viele Festplatten, um dem einzelnen Server seine persönliche Festplatte vorzugeben.

So wird die Spitzenlast eines Server auf viele Festplatten verteilt. Natürlich "bremst" dies indirekt auch die anderen Server, die auf den gleichen Festplatten arbeiten. Aber dies kann das Disksubsystem durch RAM (Cache) und QualityOfService auf den Disks sehr fein steuern.

Bei dem Bild teilen sich nun Server1 (Gelb) und Server3 (Blau) einen Teil der Festplatten, so dass IOs natürlich konkurrierend sind. Aber in der Praxis hat sich gezeigt, dass viele Server zwar manchmal eine hohe Last haben (Speziell beim Backup, Restore, Reorganisation etc.) aber in der Regel diese Last nicht von Dauer ist. Dann wäre es ja "zu teuer", für die Spitzenzeiten teure Ressourcen vorzuhalten. Beim privaten Auto mag es tolerierbar sein, dass es die meiste Zeit "stillsteht" und vor sich hin verfällt, aber bei den Servern kann man hier schon optimieren.

In der Abbildung ist natürlich nun nichts von RAIDs oder Backup etc. zu sehen. DA zitiere ich den Spruch eines EMC-Administrators:

"Vergiss alles, was du über RAIDs, Sets etc. bisher gelernt hast. Du bekommt von mir LUNs, die redundant, sicher, verfügbar und schnell sind, auch wenn die physikalische Disks mit anderen Systemen gemeinsam genutzt werden. Was Windows als "Disk" sieht ist dreimal virtualisiert  worden. Disks werden zu Packs zusammengefasst, welches dann zu redundanten Sets verbunden werden, von denen dann die gewünschte Anzahl an 9GB-Stripes zusammengefasst werden. Das ist dann die LUN, die der Server sieht. Die Performance steuere ich per "Quality of Service". Ich schau mir genau an, welche Last deiner Server machen und dann verschiebe ich die Bytes ohne dein Zutun auf die Platten, die angemessen sind.

Das ist auch der Grund, warum z.B. einige SAN-Speicher nur immer ein Vielfaches von einer bestimmten Blo9ckgröße konfigurieren können und die althergebrachten Ansichten über RAID1, RAID5, RAID10 etc. einfach nicht mehr relevant sind. Solche Überlegungen machen natürlich nur dann Sinn, wenn wirklich viele Festplatten zusammen werkeln.

Einen Nachteil darf man aber auch nicht übersehen: Die Konfiguration wird komplexer und ohne entsprechende Schulungen, Übung etc. steigt wieder das Risiko eines Ausfalls, den man doch gerade durch ein SAN reduzieren wollte.

Zusammenfassung

Ethernet oder Fiber Channel

Die Grenzen verschwimmen. Ethernet bedeutet nicht mehr länger nur "Dateisharing" mit NFS, SMB, NCP, Ethertalk, sondern erlaubt den Aufbau moderner, schneller redundanter Netzwerke mit garantierten geswitchten Übertragungswegen. So können auch Blockdaten übertragen werden. Umgekehrt ist auch Fiber Channel nicht länger nur als Speichernetzwerk zwischen einem Server und einer zentralen Festplatte im SAN zu verstehen. Auch über FC können Netzwerke für Dateiaustausch aufgebaut werden.

Beide Infrastrukturen wachsen aufeinander zu, aber kommen aus unterschiedlichen Ecken. FiberChannel war schon immer auf hohe Verfügbarkeit, definierte Bandbreiten etc. ausgelegt und kann mittlerweile auch TCP/IP Pakete übertragen. Durch die Leistungssteigerung und den Einsatz von vollständig geswitchten Netzwerken sind auch im Ethernet Übertragungsqualitäten zu erreichen, die als Speichernetzwerk dienen können.

Dateiserver und Festplattenserver

Unabhängig vom Übertragungsweg gibt es aber immer noch den eigentlichen Massenspeicher im Hintergrund, der die Daten letztlich aufnimmt. Hier zählt neben der reinen Kapazität auch die Performance, die Möglichkeiten eines serverless Backup, Schattenkopien, Management und Verfügbarkeit. Diese Aspekte sind unabhängig zu betrachten.

Diese Server können entweder als "Dateiserver" einfach Dateien zum Zugriff bereit halten oder als "Festplattenserver" einem System eine logische Festplatte präsentieren.

  • NAS bedeutet meist der Einsatz eines Dateiservers
  • SAN wird meist mit Fiber Channel und einem Festplattenserver gleich gesetzt.

Faktisch sind diese Annahmen nur zwei Möglichkeiten einer Matrix:

  • Ein Dateiserver kann mit dem richtigen "Treiber" auch eine logische Festplatte über Ethernet bereitstellen (iSCSI).
  • Ein Festplattenserver kann mit einem Zusatzmodul auch einen Dateiserver anbieten.

Exchange kann jede Festplatte nutzen, solange sie über einen Miniport Treiber unter Windows angesprochen werden kann. Exchange kann aber nicht mit "Netzwerklaufwerken" umgehen.

Exchange und Windows 2003 Storage Server

Microsoft muss natürlich auch etwas gegen die Zunahme der preiswerten NAS-Systeme auf Basis proprietärer Betriebssysteme oder Linux mit Samba unternehmen. Eine Lösung hier zu ist der Windows 2003 Storage Server (frühere Bezeichnung: Windows 2000-powered NAS o.ä.). Allerdings handelt es sich hier weder um ein SAN noch um iSCSI, sondern anscheinend eine vollkommen eigene Lösung, um Exchange Daten auf einem Storage Server zu speichern.

Diese speziellen Versionen können Sie nicht frei im Handel kaufen, sondern erhalten diese nur beim Kauf einer entsprechenden Hardware von ausgewählten Herstellern (DELL, HP und andere). Meist handelt es sich dabei auch nur im normale PCs, die als Rackvariant und unter Verzicht auf viele wichtige Funktionen sehr preisgünstig verkauft werden. Meist haben diese Server weder eine Floppy, noch ein CD/DVD-Laufwerk und meist sind diese nicht einmal nachträglich anschließbar. Die Festplatten sind sehr oft IDE-Geräte mit hoher Kapazität. für die Redundanz muss meist das Windows Betriebssystem besorgen. Datensicherung und andere Zusatzfunktionen sind meist nicht geklärt.

Aber Sie erhalten sehr viel Gigabyte mit Windows als Server und benötigen nicht einmal weitere CAL-Lizenzen !!. Klarer Wettbewerber ist daher Linux mit Samba. Ein solches System würde ich nicht dazu nutzen, um darauf auch noch Exchange Daten zu installieren, zumal es weder ein Domain Controller sein noch Exchange darauf laufen darf. Aber auf der Basis des Windows 2003 Storage Servers ist natürlich ein zentraler Datenspeicher für ihr Netzwerk möglich.

Mit dem Windows Storage Server 2003 Feature Pack ist es auch Exchange 2003 möglich, seine Daten nicht mehr auf den lokalen Festplatten oder SAN-Festplatten abzulagern, sondern auch auf einem Windows Storage Server 2003.

Allerdings kann Exchange NUR die Datenbanken und Transaktionsprotokolle auf diesem Storage Server ablegen. Programme (/BIN), Messages Queues etc. verbleiben auf dem lokalen Server, auf dem die Exchange Dienste ausgeführt werden.

Weitergehende Informationen finden Sie dazu auch auf:

Das Windows Storage Server 2003 Feature Pack fügt Exchange Server 2003 Unterstützung für NAS Geräte hinzu. Das Feature Pack füllt die Lücke zwischen DAS und SANs für Kunden, die ihre Exchange Daten auf Netzwerk-Speicherkomponenten lagern wollen.

Weitere Links