- Network Block Device
-
Ein Network Block Device (engl. für Netzwerk-Blockgerät, abgekürzt NBD) ist eine Art virtuelle Festplatte, auf die ein Rechner via Internetprotokoll zugreifen kann. Das NBD wird von einem NBD-Server bereitgestellt. Er bietet hierfür eigene Festplatte, Festplattenpartition oder eine Datei als NBD bestimmten anderen Rechnern (Clients) an. Ein anderer Rechner (oder auch der gleiche) kann sich über eine TCP-Verbindung mit dem NBD-Server verbinden und anschließend das NBD wie eine eigene lokale Festplatte benutzen.
Derzeit existiert nur für Linux eine vollständige NBD-Implementierung. Linux spricht sämtliche Massenspeicher als sogenannte Blockgeräte an. Wenn ein Linux-Rechner ein Network Block Device nutzen soll, muss NBD support in der Linux-Kernel-Konfiguration aktiviert sein, bzw. das Kernelmodul nbd.ko geladen sein. Ein Userspace-Hilfsprogramm namens nbd-client stellt nun die TCP-Verbindung zum NBD-Server her, gibt die bestehende Verbindung an den Kernel weiter und beendet sich dann. Dies hat den Vorteil, dass der Kernel sich nicht mit dem Verbindungsaufbau (und einer eventuellen Authentisierung usw.) befassen muss.
Der NBD-Server ist betriebssystemunabhängig. Er kann also auch auf einem Nicht-Linux-System laufen, da keine Linux-spezifischen Funktionen benötigt werden. Es existiert ein Programm namens nbd-server, das nichts weiter tut, als eine gegebene Datei (oder Partition etc.) an einem angegebenen TCP-Port bereitzustellen.
Prinzipiell ist es möglich, über NBD einen festplattenlosen Rechner zu betreiben, der als einzigen Massenspeicher ein NBD besitzt. Da jedoch zum Aufbau der Verbindung noch ein externes Programm (nbd-client) benötigt wird, ist dies nur mit Konzepten wie der init-ramdisk zu realisieren, einem virtuellen Dateisystem, welches im RAM gehalten wird und im Kernel selbst gespeichert ist, sodass es nach dem Booten zur Verfügung steht.
Da die Originalversion von NBD einige Schwächen hat (z.B. die Begrenzung auf 4 Gigabyte pro NBD), gibt es verschiedene Erweiterungen, die teilweise als "enhanced NBD" bezeichnet werden. Diese sind jedoch inkompatibel zum Original-NBD.
Inhaltsverzeichnis
NBD-Protokoll (seit Version 2.6)
Das Protokoll ist ein Binärprotokoll. Sämtliche Mehrbytewerte werden dabei in Network Byte Order gesendet.
Zuerst kommt eine Initialisierungsphase, bei der Daten zwischen dem NBD-Server und dem NBD-Clientprogramm ausgetauscht werden. Dieses Protokoll ist unabhängig vom NBD-Treiber im Linux-Kernel und kann bei verschiedenen NBD-Implementierungen variieren.
Sobald ein Client sich zum NBD-Server verbunden hat, sendet der Server folgende Datenstruktur:
-
NBD Initialization packet (Server→Client)[1] Offset Datentyp Name Beschreibung 0 char[8] INIT_PASSWD Identifizerungsstring {'N', 'B', 'D', 'M', 'A', 'G', 'I', 'C'}
8 uint64_t cliserv_magic Magic Number 0x00420281861253 16 uint64_t export_size Größe des exportierten Blockdevices (in Byte) 24 uint32_t flags Flags: Bit 0: Es sind Flags vorhanden; Bit 1: Gerät ist read-only 28 char[124] reserved Reserviert (Derzeit gefüllt mit Nullbytes)
Akzeptiert der Client den Identifizierungsstring oder die Magic Number nicht, schließt er die Verbindung. Andernfalls gilt die Verbindung als erfolgreich aufgebaut. Der NBD-Client leitet die Informationen über die Größe des Blockdevices, eventuelle Flags und den geöffneten Socket über spezielle Systemaufrufe an den Kernel weiter und beendet sich. Der Kernel übernimmt dann die weitere Kommunikation über diesen Socket.
Der Kernel auf Clientseite stellt nun Lese- und Schreibanfragen (Requests) an den Server. Diese haben folgenden Paketaufbau:
-
NBD Request (Client→Server)[2] Offset Datentyp Name Beschreibung 0 uint32_t magic Magic Number 0x25609513 4 uint32_t type 0: Lesezugriff; 1: Schreibzugriff; 2: kontrolliertes Verbindungsende 8 char[8] handle 8 Bytes, die im Reply identisch mitgeschickt werden, um dieses einem Request zuordnen zu können 16 uint64_t from Offset (in Bytes), ab dem gelesen/geschrieben werden soll 24 uint32_t len Länge des Datenblocks
Bei Schreibzugriffen folgen unmittelbar darauf die zu schreibenden Daten. Der Server beantwortet jeden Request mit einer Antwort (Reply). Diese hat folgenden Aufbau:
-
NBD Reply (Server→Client)[2] Offset Datentyp Name Beschreibung 0 uint32_t magic Magic Number 0x67446698 4 uint32_t error 0=OK (kein Fehler aufgetreten) 8 char[8] handle Kopie des Handles im zugehörigen Request
Bei Antworten auf Lese-Requests folgen unmittelbar darauf die angeforderten Daten.
Siehe auch
- Loop device: Die gleiche Idee mit einem lokalen Gerät
- Network File System: Agiert auf einer anderen Ebene, hat dafür aber auch einen weitaus größeren Bekanntheitsgrad
Einzelnachweise
Weblinks
- http://nbd.sf.net NBD Homepage
Kategorien:- Rechnerarchitektur
- Rechnernetze
-
Wikimedia Foundation.