Lehrveranstaltung Speichersysteme Sommersemester 2009

Transkript

1 Lehrveranstaltung Speichersysteme Sommersemester 2009 Kapitel 11: Network File Systems Part 1 André Brinkmann

2 Gliederung Network AFached Storage Speichertechnologien hinter NAS Verteilte Dateisysteme NFS AFS

3 Network AFached Storage I Dateiserver bieten Zugriff auf Speichersysteme über verteiltes Dateisystem an NFS, AFS, CIFS Anwendungen auf Client Rechnern greifen über Netzwerk auf Dateisystem des Servers zu SchniFstelle wird für den Client von der BlockschniFstelle auf die DateisystemschniFstelle verschoben Was ist nun NAS? Vorkonfigurierter Dateiserver, der über das Ethernet an das LAN angeschlossen wird Einzelne, über Ethernet und CIFS / NFS zugreifbare Festplatte ist bereits ein NAS

4 Network AFached Storage II A term used to refer to storage elements that connect to a network and provide file access services to computer systems. Abbreviated NAS. A NAS Storage Element consists of an engine, which implements the file services, and one or more devices, on which data is stored. NAS elements may be afached to any type of network. When afached to SANs, NAS elements may be considered to be members of the SAS (SAN afached storage) class of storage elements. A class of systems that provide file services to host computers. A host system that uses network afached storage uses a file system device driver to access data using file access protocols such as NFS or CIFS. NAS systems interpret these commands and perform the internal file and device I/O opera^ons necessary to execute them. Definitionen gemäß SNIA

5 NAS Server NAS Server ist ein vorkonfigurierter Dateiserver, der bereits integrierte FestplaFen über LAN zur Verfügung stellt Client Fast-Ethernet Ethernet GBit/s Ethernet CIFS / NFS Server SCSI Festplatten / RAID NAS-Server

6 NAS Gateway NAS Gateway ermöglicht Zugriff auf externe Speichersysteme über SAN SchniFstelle Client Fast-Ethernet GBit/s Ethernet Ethernet CIFS / NFS Server NAS-Gateway FC/iSCSI SAN

7 Basistechnologie: Verteilte Dateisysteme Bei einem verteilten Dateisystem sind sowohl Clients, als auch Server und Speichersysteme über die Knoten eines Systems verteilt. Im Gegensatz zu lokalen Dateisystemen sind dabei die Daten nicht in einem zentralen Repository gesichert, sondern liegen auf voneinander unabhängigen Speichersystemen. Ausprägungen von verteilten Dateisystemen: Netzwerkdateisysteme bieten die gemeinsame Nutzung von Dateien für verschiedene Benutzer über ein Netzwerk. Beispiele NFS und CIFS Cluster Dateisysteme sind symmetrisches Out of Band Dateisystem. Jeder Knoten kann sowohl Client, als auch Server und Metadaten Server sein. Der Speicher wird über alle Clients verteilt. Beispiele GFS, GPFS Parallele Dateisysteme verfügen über separate Metadaten Server. Vor dem Zugriff eines Clients auf die Speichersysteme müssen sie die zugehörigen Berech^gungen von dem Metadaten Server anfragen. Beispiele Lustre und IBM SAN FS

8 Charakteris^ken verteilter Dateisysteme Verteilte Dateisysteme sollten folgende Charakteris^ken erfüllen: Jeder Benutzer kann von jedem beliebigen Host auf Files zugreifen Access Transparency Mehrere Benutzer können gleichzei^g auf dieselben Files zugreifen Concurrency Transparency Files eines Benutzers können auf verschiedenen Hosts sein Loca^on Transparency und Loca^on Independence Dieselben Files können im System mehrfach repliziert vorliegen Replica^on Transparency Folie basiert auf Vorlesung von Prof. Dr. Langendörfer

9 Charakteris^ken verteilter Dateisysteme Wenn ein File im System verlagert wird, so soll das den Zugriff nicht beeinträch^gen Migra^on Transparency Das Dateisystem muss auch bei Ausfall eines Clients / des Servers oder dem Verlust von Nachrichten korrekt arbeiten Failure Transparency Trotz variierender Lasten am File Server muss der Klient mit genügender Geschwindigkeit arbeiten Performance Transparency Geschwindigkeit sollte lokalem Dateisystem entsprechen Folie basiert auf Vorlesung von Prof. Dr. Langendörfer

10 Zusätzliche wich^ge Anforderungen Das verteilte Dateisystem muss auf einer Vielzahl unterschiedlicher Rechner laufen Hardware and Opera^ng System Heterogeneity Ein verteiltes Dateisystem kann sehr schnell viele tausend Rechnersysteme umfassen. Scalability Folie basiert auf Vorlesung von Prof. Dr. Langendörfer

11 Folie basiert auf Vorlesung Verteilte Systeme von Prof. Dr. Beigl Dateiserver Architektur

12 Server Opera^onen Flat file service Read(FileId, i, n) Data Write(FileId, i, Data) Create() FileId Delete(FileId) GetA5ributes(FileId) A5r SetA5ributes(FileId, A5r) Keine open/close Funk^onen Position des ersten Bytes Funk^onen sind idempotent (Ausnahme: create) Verzeichnis-Dienste Lookup(Dir, Name) FileId AddName(Dir, Name, File) FileId UnName(Dir, Name) GetNames(Dir, Pattern) NameSeq Lookup der Pfadnamen: Pfadnamen, wie /usr/bin/tar werden durch FileId: iterative Eindeutiger Aufrufen von Identifier lookup() für aufgelöst. Datei Jede innerhalb Komponente des Netzwerkes. des Pfades erfordert einen Aufruf, wobei mit der ID des Wurzelverzeichnisses / bekannt sein muss. Folie basiert auf Vorlesung Verteilte Systeme von Prof. Dr. Beigl

13 Dateisystem als Protokoll State Maschine Der Zugriff auf Dateien über ein Dateisystem kann als eine Session von Opera^onen auf Dateien im Rahmen einer Verbindung betrachtet werden. Durch diese Betrachtungsweise wird ein verteiltes Dateisystem als ein spezielles Kommunika^onssystem gesehen, das spezielle Protokolle durchführt zur Zielerreichung: Öffnen einer Datei: Session Auiau Zugriff auf Daten: Datentransfer Änderung von AFributen: Management Opera^onen Schließen einer Datei: Session Abbau Protokolle können sehr gut durch State Machines beschrieben werden, die Übergänge von Zuständen in Abhängigkeit von der Ak^onen durchführen. Protokolle können symmetrisch und unsymmetrisch sein und damit die Verteilung der Statusinforma^on. Folie basiert auf Vorlesung von Prof. Dr. Langendörfer

14 Gedächtnisbehamete und gedächtnislose File Systeme I Wie bei Protokollen müssen in Dateisystemen Statusinforma^onen über den aktuellen Stand geführt werden Statusinforma^onen von Dateisystemen sind beispielsweise: Informa^onen über geöffnete Dateien und deren Clients File Deskriptoren und UFIDs Posi^onszeiger für den aktuellen Zugriff Moun^ng Informa^on Lock Status Session IDs und gegebenenfalls deren Capabili^es Caches oder Puffer Diese Art von Statusinforma^onen kann unterschiedlich zwischen Client Module, Directory Server und File Server aufgeteilt werden Aus Performanzgründen sollten Informa^onen über die UFIDs, die Buffer und die Session Keys beim Client liegen Diese Statusinforma^onen sind nicht wie AFribute zu behandeln, die als Teil des Files gespeichert werden, sondern vielmehr als dynamische Informa^onen während der Session Folie basiert auf Vorlesung von Prof. Dr. Langendörfer

15 Gedächtnisbehamete und gedächtnislose File Systeme II Die Verteilung der Statusinforma^onen beeinflusst wesentlich die Eigenschamen eines verteilten Dateisystems, insbesondere die Performance, Scalability, Availability und Consistency Ein verteiltes Dateisystem wird gedächtnisbehamet genannt, wenn es während einer Anwendungs Session intern Informa^onen über diese Session verwaltet und gedächtnislos, wenn der Client alle Session Informa^onen hält. Tradeoffs: Flexibility Je mehr Informa^onen das Dateisystem hat, desto besser kann es Verwaltungsaufgaben und Op^mierungen durchführen. Simplicity Ein gedächtnisloses Dateisystem kann viel einfacher implemen^ert werden und ist wesentlich sicherer im Umgang mit Clienten und Server Fehlern Folie basiert auf Vorlesung von Prof. Dr. Langendörfer

16 Probleme bei gedächtnislosen File Systemen Wie geht der Dateiserver mit wiederholten Opera^onen von Clienten aufgrund vorheriger Fehler um? Sind alle Zugriffe idempotent? (Normalerweise wird vom Kernel des verteilten Systems Wiederholung ausgeschlossen oder durch Nummerierungen Wiederholungen erkennbar gemacht. Im zweiten Fall muss das Dateisystem die Nummerierung überwachen und ist damit nicht mehr gedächtnislos.) Wie geht das Dateisystem mit File Locking zur Concurrency Kontrolle um? (Dies kann durch einen überlagerten Mechanismus wie Transak^ons Management oder Session Management erreicht werden. Damit wird aber das Problem nur vom File System verschoben und bleibt ein System Implemen^erungsproblem.) Wie werden Session Keys für das Security Management verwaltet? (Session Keys sind üblicherweise auf beiden Seiten der Session zu verwalten. Auch hier kann ein übergeordnetes System das Security Management übernehmen.) Wie wird Cache Konsistenz und die Konsistenz der Replikate erreicht? Alle exis^erenden DFSs haben einen minimalen Anteil an Gedächtnis Folie basiert auf Vorlesung von Prof. Dr. Langendörfer