SAN und NAS (c) Till Hänisch 2003, BA Heidenheim
SAN SAN : Storage Area Network A SAN is two or more devices communicating via a serial SCSI protocol, such as Fibre Channel or iscsi [Preston02] Fibre channel, weil: ein Kanal (Kabel) mit 2Gb/sec schon schnell ist und mehrere gebündelt werden können, wenn das nicht reicht 16 Millionen Geräte in einem SAN jeder Computer auf jedes Gerät zugreifen kann Entfernungen kein Problem sind (10 Kilometer, mit Bridging - etwa über ATM - auch praktisch beliebig weit, etwa für Datensicherung (Latenzen!))
lokales Backup aus [Preston02] Jeder Server hat ein eigenes Bandlaufwerk, Probleme: Große Datenmengen passen evtl. nicht auf ein Band (Library ist teuer) manueller Bandwechsel Kapazität der Bandlaufwerke (und Bänder) wird meist nicht ausgenützt
zentrales Backup Zentraler Backup-Server mit Library und Backup-SW Client-SW für versch. Plattformen kann voll automatisiert laufen Daten werden über LAN übertragen (Bandbreite --> dauert lang, etwa bei großen Datenbanken) aus [Preston02]
verteiltes Backup aus [Preston02] Große Server erhalten eigene Tape-Libraries Steuerung durch zentralen Backup-Server der auch alle kleineren Clients sichert --> Entlastung des LANs, aber: --> mehrere (teure) Libraries nötig, die nur teilw. ausgelastet werden
SAN Backup aus [Preston02] LAN-free-backup (1) Client-free-backup (2) (Preston, sonst auch Server-free-backup) Server-free-backup (3) Zugriffssteuerung über SCSI-reserve/release oder herstellerspezifisch
Beispiel, nach [Preston02] 3 Server, je 1,5 TB Daten, LTO Tapes a 9000$, Kapazität je 400 GB Annahme bei SAN-Lösung: 4 Tapes für wechselndes Voll-Backup, 1 Tape gemeinsam für inkrementelles Backup normales SCSI SAN Menge Preis Menge Preis Tape drives 12 108.000$ 5 45.000$ HBAs 3 3.000$ 3 6.000$ Switch - - 1 8.000$ Router - - 1 6.000$ Server SW gleich gleich Library gleich gleich Gesamt 111.000$ 66.000$
aus [Preston02] Netzwerktechniken
Fibre channel geringe Latenz QoS, virtual circuits variable Blocklänge Hot pluggable devices FC4: mapping höherer Protokolle FC2: entspricht OSI-Layer 2 FC1: PHY, Darstellung von frames FC0: PMD, Übertragungsmedium versch. Porttypen: N, F, L,EG Adressen: WWN, World Wide Name 64 Bit entspricht MAC-Adresse aus [Preston02]
Topologien aus [Preston02] Fibre Channel unterstützt mehrere Netzwerktopologien, Point-to-point verbindet zwei Teilnehmer z.b. Server an device, N-Ports Beispiel: Apple XServer-RAID, 2,5 TB, 15.000 EUR
Fabric devices werden über switches (F- Ports) verbunden, Vorteil: Kein shared medium, volle Bandbreite für jeden Port. Switch verteilt Adressen (24 Bit --> 16 Millionen Geräte, native address identifier S_ID) Switches können miteinander verbunden werden, E-Ports aus [Preston02]
arbitrated loop aus [Preston02] Switches sind teuer, billige Lösung: arbitrated loop, NL-Ports. Knoten handeln Adressen aus (arbitrated loop physical address, AL_PA, 8 Bit). Komplexe Arbitrierung, faire Verteilung des Zugriffs, Priorisierung durch AL_PA. Kombination mit fabric möglich.
arbitrated loop II aus [Preston02] Loop durch direkte Verbindung ist aufwendig, fehleranfällig, nur bei wenigen Geräten sinnvoll. Bei größeren Netzen Kopplung durch Hub
Komponenten HBA: Host Bus Adapter, FC-SCSI-Karte Kabel: Kupfer oder Glasfaser Switch: untersch. Intelligenz, Zones,... Hub: managed Hubs können defekte/nicht angeschlossene Geräte überbrücken, unmanaged Hubs nicht Router: verbindet auf OSI-Ebene 3, hier SCSI Umwandlung FC auf parallel SCSI zwischen HBA und switch, load balancing, failover Disk subsysteme RAID, JBOD ggf. mit Intelligenz, mirrors, server free copy, monitoring, multipath/failover, off-site-replication usw. Software!
Zoning Im SAN kann jeder Server auf jedes device zugreifen, sol er aber gar nicht (dürfen), Sicherheit! Aufteilung in einzelne Gruppen (Zonen) analog VLANs Hard zones: Gruppierung über Portnummer Soft zones: Gruppierung über WWN Alternative/Ergänzung: LUN-Masking beide aus [Preston02]
aus [Preston02] SAN
iscsi SCSI über TCP/IP, Ethernet verbreitete/billige Standardkomponenten spez. GBit-Ethernet-Karten, die TCP/IP Protokoll abwickeln (Entlastung der Server CPU, TOE: TCP offload engine) Anwendungen: klassisches SAN SAN-Kopplung über Internet diskless Server aus Troppens, IP-basierte Speichernetze, ix 10/2003, Heise
NAS Network attached storage, NAS is a computer (or device) dedicated to sharing files via NFS, CIFS..., [Preston02] Kann (im Prinzip) auch nicht mehr, als ein Windows/Unix Fileserver, aber: weniger aufwendig (mehr oder weniger automatische Konfiguration) schneller (spezielle Betriebssysteme/Treiber, ggf. spezielle Hardware) sicherer (keine unnötigen Dienste,...) einfacher (Administration über spezielle tools) beide Protokolle gleichzeitig (nur ein Server statt zweien)
aus [Preston02] SAN vs. NAS
warum fileserver langsam sind Daten müssen bei jedem Zugriff etliche Schichten durchlaufen, verbrauchen jedesmal CPU-Zeit. aus [Preston02] Dateisysteme ursprünglich nicht für Netzwerkzugriff konzipiert --> Probleme bei Performance --> Hacks bei Netzwerprotokollen nötig, z.b. ls -l unter Unix erfordert (zur Bestimmung der Dateigröße) disk-zugriff auf jede Datei, Folge: dir mit 1000 Dateien braucht 1001Zugriffe übers Netz! (Neuere NFS Versionen haben readdir system call)
multi host access mehrere Rechner greifen auf die gleichen (!) Daten zu kann SAN nicht, dort: mehrere Rechner auf die gleichen devices, aber auf unterschiedliche Daten was passiert, wenn gleichzeitg geändert wird? locking: Wer schreiben will, sperrt (im Filesystem) Client-side caching wird schwierig ältere Protokollversionen liessen deshalb kein caching zu --> Performance in aktuellen Versionen sind effiziente Mechanismen implementiert
was ist eine Datei? NFS und CIFS haben unterschiedliches Rechtemodell Unix: UID/GID + Access-Maske Windows: SID + ACEs Abbildung Unix-->Windows einfach, andere Richtung unmöglich Folge: Backup muß über CIFS erfolgen NTFS Datei kann mehrere streams haben gibt s unter Unix nicht
NAS hat schlechtere Performance als SAN, aber: Braucht man die (unbedingt)? NAS erlaubt gleichzeitigen Zugriff mehrerer Benutzer auf die gleichen Daten NAS ist einfacher (Protokolle, Betriebssysteme, Netzwerktechnik sind bekannt, weniger Komponenten, ein Hersteller, keine Kompatibilitätsprobleme...) NAS ist billiger Backup kann schwierig sein (abgespeckte Betriebssysteme, manche bieten allerdings snapshots, Backups nur auf Dateiebene, bei vielen kleinen Dateien schlechte Performance kein Standard für Management-SW
SAN SANs bieten raw devices (Datenbanken, Geschwindigkeit beim Backup) SANs sind flexibel (Topologien, Dateisysteme,...) SANs sind schnell Backup ist (mit geeigneter SW) einfach, performant (snapshots, remote copies) Produkte verschiedener Hersteller sind nicht (immer) kompatibel SANs sind komplex SANs sind teuer (Stückzahlen sind klein, ändert sich vielleicht mit iscsi)
SAN oder NAS? Hängt vom Einzelfall ab Performanceanforderungen Applikationen Kombination bietet Vorteile beider NAS frontend, SAN backend NAS gateway
Wir stehen selbst enttäuscht und sehn betroffen: Der Vorhang zu und alle Fragen offen."