Große NAS-Cluster für die Storage-Virualisierung
NAS-Gateways im Cluster
Im Bereich der File-Server bildete sich eine neue Gerätegeneration heraus. So genannte SMP-SAN-Filer (mit SMP ist ein symmetrisches Multiprozessorsystem gemeint) oder NAS-Gateways verschaffen LAN-Clients den Zugang zum SAN und verfügen dazu über ein offenes Storage-Backend. Diese Gateways können zudem in einem Multi-Node-Cluster mit n-Wege-Redundanz und sehr geringem Overhead arbeiten. Das heißt, diese Systeme bieten deutlich mehr nutzbare Speicherkapazität als klassische NAS-Lösungen.
Hauptbestandteile eines SMP-SAN-Filers zum Beispiel von Onstor sind das Host-Sub-System (HSS) mit der Hauptprozessoreinheit für den Host sowie das Embedded-Sub-System (ESS) mit folgenden Basismodulen:
Hauptprozessoreinheit fürs File-System,
Channel-Coprozessor fürs LAN,
I/O-Prozessoren fürs SAN sowie
eingebettete Coprozessoren für Applikationen.
Da diese Architektur mit mehreren Prozessoren parallel arbeitet, erreicht sie eine höhere Performance als bisherige File-Server-Varianten. Die Speicherung erfolgt bei einem SAN-Filer ausschließlich im SAN, NAS-Gateways können auch mit SCSI-attached Speichereinheiten arbeiten. Um eine akzeptable Performance zu erreichen, benötigt diese Architektur eine echtzeitfähige Softwareumgebung. Für das HSS sollte eine separate CPU zur Verfügung stehen. Es liefert alle Routinen zur Kontrolle, Überwachung und Administration der Gateways. Aus Sicherheitsgründen ist es nicht möglich, vom HSS aus Zugang zu Anwenderdaten im ESS zu erhalten.
Bei den Geräten von Onstor kommen für das ESS zum Beispiel zwei 64-Bit-Quad-Core-CPUs zum Einsatz. Jedes funktionale Modul repräsentiert ein in sich geschlossenes, echtzeitfähiges 64-Bit-Betriebssystem. So fungiert eines als TCP/IP-Offload-Engine (TOE). Dort laufen neben den TCP/IP-Prozeduren die bidirektionalen Prüfsummenverfahren und Paketüberprüfungen ab. Das nachgeschaltete Multiprotokollmodul enthält die Informationen über CIFS/NFS und die Multiprotokollsemantik (Zugriff von Windows- auf Unix-Dateien und umgekehrt). Hier sind auch die Routinen für Authentifizierungen und File-Locking untergebracht. Zudem verwaltet das Modul den Anwenderdaten-Cache, der wiederholte Zugriffe der Benutzer auf gleiche Daten beschleunigt. Es liefert außerdem die Cache-Hits und reicht Metadaten und Disk-Anforderungen weiter.
Das Memory-Management in der Management-Plane sollte bei solchen Lösungen die Datenbewegung innerhalb des Systems minimieren. Das heißt, die Module übergeben nicht die Daten selbst, sondern lediglich Zeiger auf Memory-Bereiche, die die Daten enthalten (Message Passing). Außerdem sollten die CPUs Hypertransport unterstützen und ein Memory-Sharing zwischen den CPUs erlauben. Systeme, die mit einem Journaled-File-System arbeiten, speichern die Daten nicht "im Transit" zwischen, sondern schreiben sie entweder sicher auf Disk (im File System Journal) oder erhalten keine Bestätigung für den Client. Das File-System schreibt die Metadaten im On-Disk-Format in den Metadaten-Cache. Das beschleunigt wiederholte Zugriffe auf gleiche File-System-Bereiche und Dateien. Der Anwender sollte darauf achten, dass es sich um ein echtes 64-Bit-File-System handelt und dass es für die Ausführung der Routinen eine eigene CPU nutzt. Beim Onstor-System kann die File-System-MPU zum Beispiel bis zu 100 File-Systeme mit jeweils 100 TByte Kapazität verwalten. Es ist für das Metadaten-Layout zuständig sowie für die I-Nodes, Quotas sowie für die Datensicherung per Snapshot oder NDMP (Network Data Management Protocol) und steuert das FC-Multi-Pathing. Auch Disk-to-Disk-Datenreplikationen via FC oder IP ermöglicht das File-System. Dabei ist es entscheidend, dass der für das File-System-Layout benötigte und damit nicht für User-Daten verwendbare Speicherbedarf möglichst gering ausfällt. Onstor gibt an, nur jeweils 1,5 Prozent der insgesamt zur Verfügung stehenden Kapazität dafür zu benötigen. Freie Datenblöcke verwaltet dieses File-System in einer speziell verketteten Liste freier Blockbereiche. Dies ermöglicht eine kontinuierliche Defragmentierung. Auch bei einer Kapazitätsauslastung nahe am Maximum des File-Systems gibt es somit keine negativen Auswirkungen auf die Performance.
Im Cluster-Verbund
Wird das System als NAS-Gateway-Cluster eingesetzt, kann es die Speicherkapazität unterschiedlichster Storage-Systeme und Speicherklassen im SAN nutzen und erlaubt eine Replikation von Daten im SAN (also mit FC-Line-Speed) zwischen unterschiedlichen Speicherklassen. Die Daten eines Journaled-File-System im SAN sind für jeden Node eines NAS-Gateway-Clusters erreichbar. Ein Austausch von Anwenderdaten über das Cluster-Netzwerk (CAN) ist dabei nicht erforderlich. Ein CAN transportiert lediglich Cluster-Status-Informationen, und dafür genügt eine Fast-Ethernet-Anbindung. Lediglich die Latenz sollte fünf Millisekunden nicht überschreiten. Zur Umsetzung eines "Stretched NAS-Clusters" muss die Infrastruktur über den Campus so ausgelegt sein, dass alle Nodes eines Clusters eine einheitliche Sicht auf das FC-Netzwerk und die LUNs haben. Generell kann ein NAS-Gateway-Cluster sehr gut als Ressourcen-Container für virtuelle File-Server dienen. Clients im LAN sehen die virtuellen Server (Vserver) als vollständige NAS-Devices mit eigenständiger Identität, IP-Adresse, Authentifizierung und Storage-Kapazität. Sie werden per VLAN separat angesprochen. Obwohl die Vserver die physischen Ressourcen der Nodes gemeinsam nutzen, bleiben sie dennoch völlig voneinander isoliert. Sie sind unabhängig vom physischen Node und können innerhalb eines Clusters einfach per Drag and Drop von einem auf einen anderen Node migrieren, und dies transparent für die Clients im LAN und ohne dass Daten migriert werden müssten. Auf diese Weise lassen sich File-Services hochverfügbar gestalten. Fällt ein Node aus, übernehmen die im Cluster verbliebenen automatisch die Vserver des ausgefallenen.
Um Peformance-Probleme bei der Speicherung zu verhindern, sollte das Lesen von Daten oder das Schreiben auf Disk möglichst nicht in Echtzeit erfolgen, da dann die Anwendungen auf die Rotation der magnetischer Geräte warten müssten. Der umgekehrte Weg, alle Anwendungsdaten im Memory zu halten, ist jedoch nicht praktikabel. Besser ist es, effektive Caching-Algorithmen einzusetzen.
Performance-Optimierung mit ZFS
Das Open-Source-Tool Solaris Zeta File System (ZFS) von Sun beispielsweise arbeitet hier mit einem ganzheitlichen Ansatz für das Prefetching. Es liest bei sequenziellen Datenübertragungen voraus und erreicht so eine höhere Zugriffsgeschwindigkeit. Die Lösung kann laut Sun sein Leseverhalten im laufenden Betrieb an komplexere Zugriffsschemata anpassen und adressiert dabei nicht nur das File-System, sondern greift den gesamten Storage Stack an, vom Disk-Drive-Management (JBODs) über die Redundanz (RAID) bis hin zu Thin Provisioning von LUNs und File-Systemen. Es arbeitet mit variablen RAID-Stripe-Breiten. Während eines RAID-Recoverys können die Daten priorisiert werden, und es erlaubt flexible Cache-Algorithmen, die zum Beispiel auch schnelle Flash Solid State Drives hierarchisch als Schreib-/Lese-Caches einbinden.
Lesen Sie mehr zum Thema
