Backing Device Archive - PowerCampus 01

Der große Nachteil von SR-IOV, sowie oben beschrieben, besteht darin, das das Verschieben (LPM) von LPARs mit logischen SR-IOV Ports nicht möglich ist. Nach der Einführung von SR-IOV auf Power Systemen gab es eine Reihe von Vorschlägen für Workarounds. Allerdings bedingen alle diese Workarounds zum Einen eine besondere Konfiguration und zum Anderen eine Reihe von Umkonfigurationen die vor und nach einer LPM-Operation durchzuführen sind. Im praktischen Alltag werden dadurch LPM-Operationen aber unnötig verkompliziert.

Mit der Einführung von vNICs können Client-LPARs SR-IOV Adapter benutzen und trotzdem LPM unterstützen. Wie schon bei VSCSI und VFC wird dazu ein Paar von Adaptern benutzt: auf der Client-LPAR wird der sogenannte vNIC Adapter in einem virtuellen Slot verwendet und auf einem Virtual-I/O-Server wird ein zugehöriger vNIC-Server Adapter verwendet. Der logische SR-IOV Port wird dem Virtual-I/O-Server zugeordnet. Der vNIC-Server Adapter, auch als vNIC-Backing-Device bezeichnet, dient dabei als Proxy für den logischen SR-IOV Port. Das Zusammenspiel der verschiedenen Adapter ist in Bild 7.19 dargestellt.

Um eine gute Performance zu erreichen, werden nur Kontroll-Informationen vom vNIC Adapter der Client-Adapter zum vNIC Server Adapter übertragen, welche von diesem über den zugehörigen logischen SR-IOV Port zum entsprechenden logischen Port (Virtual Function) des SR-IOV Adapters übertragen werden. Die Daten selbst werden zwischen vNIC Client-Adapter und dem logischen Port des SR-IOV Adapters per DMA (Direct Memory Access) mit Hilfe des Hypervisors übertragen. Es findet also insbesondere kein Kopieren der Daten über den Virtual-I/O-Server statt. Der vNIC Adapter auf dem Client ist ein rein virtueller Adapter, daher funktioniert LPM auch problemlos. Der Client besitzt den logischen SR-IOV Port nicht und greift auch nicht selbst über den PCIe Bus (Switch) auf diesen zu.

7.7.1. Erzeugen eines vNIC Adapters

7.7.2. Ändern eines vNIC Adapters

7.7.3. Hinzufügen eines vNIC Backing-Devices

7.7.4. Ändern eines vNIC Backing-Devices

7.7.5. vNIC Failover

7.7.6. Manuelles Aktivieren eines vNIC Backing-Devices

7.7.7. Wegnehmen eines vNIC Backing-Devices

7.7.8. Wegnehmen eines vNIC Adapters

Für die schnelle Bereitstellung von Client-LPARs ist die Verwendung von SAN-LUNs mittels NPIV in vielen Fällen nicht geeignet. Die SAN-LUNs müssen auf den externen Storage Systemen zunächst angelegt werden und anschließend muss das Zoning im SAN angepasst werden, damit die neuen SAN-LUNs auch für die WWPNs der Client-LPAR sichtbar sind. Auch die Verwendung von VSCSI für das Mapping der SAN-LUNs auf die Client-LPARs erfordert einigen Aufwand. Jede SAN-LUN wird dabei per VSCSI einem oder mehreren Client-LPARs zugeordnet, was zu einer großen Anzahl von SAN-LUNs auf den Virtual-I/O-Servern führen kann.

Eine Möglichkeit Storage für Client-LPARs schneller bereit zustellen besteht in der Verwendung von Storage Pools auf den Virtual-I/O-Servern. Nachdem ein Storage Pool einmal angelegt ist, kann Storage für Client-LPARs mit nur einem Kommando zur Verfügung gestellt werden. Auf dem Storage Pool werden dabei sogenannte Backing-Devices erzeugt, die per Virtual SCSI den Client-LPARs zugeordnet werden können. Storage für Client-LPAR kann damit per PowerVM von den Virtual-I/O-Servern zur Verfügung gestellt werden. Damit kann z.B. eine Boot-Platte für eine neue Client-LPAR innerhalb von wenigen Sekunden angelegt und sofort benutzt werden.

PowerVM bietet zwei verschiedene Arten von Storage Pools an: lokale Storage Pools und Shared Storage Pools. Ein lokaler Storage Pool, oder auch einfach Storage Pool, wird immer nur von einem Virtual-I/O-Server zur Verfügung gestellt. Jeder Virtual-I/O-Server kann seine eigenen unabhängigen Storage Pools besitzen. Ein Shared Storage Pool hingegen wird von mehreren Virtual-I/O-Servern, die in einem Cluster zusammengefasst sind, zur Verfügung gestellt werden. Der Zugriff auf den Shared Storage Pool ist von jedem der Virtual-I/O-Server der zum Cluster gehört möglich. Shared Storage Pools werden in diesem Kapitel nicht behandelt.

Es gibt zwei Arten von lokalen Storage Pools: Logical Volume Storage Pools und File Storage Pools. Bei einem Logical Volume Storage Pool wird für die Client-LPARs Storage in Form von Logical Volumes zur Verfügung gestellt, beim File Storage Pool in Form von Dateien.

In Bild 8.13 ist ein Logical Volume Storage Pool dargestellt. Der Storage Pool ist in Form einer Volume Group realisiert und bezieht daher seine Storage Kapazität über die zugehörigen Physical Volumes. Um Storage für Client-LPARs bereit zustellen, werden Logical Volumes in dem Storage Pool erzeugt, im Bild die Logical Volumes bd01, bd02 und bd03. Die Logical Volumes werden dabei als Backing-Devices bezeichnet, da sie letztlich als Speicherort für die Daten der Client-LPARs dienen. Die Zuordnung eines Backing-Devices zu einer Client-LPAR, genauer einem vhost-Adapter welcher eins-zu-eins einem virtuellen SCSI-Adapter einer Client-LPAR zugeordnet ist, erfolgt über ein sogenanntes virtuelles Target Device (vtscsi0, vtscsi1 und vtscsi2 im Bild). Das virtuelle Target Device ist ein Kind-Gerät eines der vhost-Adapter und zeigt über das Attribut aix_tdev auf das entsprechende Backing-Device. Beim Mapping wird das virtuelle Target Device unterhalb des vhost-Adapters erzeugt.

Solange der Storage Pool noch freie Kapazität besitzt, können jederzeit weitere Backing-Devices angelegt und Client-LPARs zugeordnet werden. Die Bereitstellung von Storage für Client-LPAR ist damit sehr flexibel und vor allen Dingen sehr schnell und unterliegt komplett der Kontrolle des PowerVM Administrators.

Neben dem Logical Volume Storage Pool sind auch File Storage Pools unterstützt. In Bild 8.14 ist ein solcher File Storage Pool gezeigt, er ist als Dateisystem implementiert. Das unterliegende Logical Volume liegt in dem Logical Volume Storage Pool mypool. Als Name für das Logical Volume wird der Storage Pool Name verwendet, im Bild filepool. Das Dateisystem wird unterhalb von /var/vio/storagepools/filepool gemountet, wobei die letzte Pfad-Komponente gleich dem Storage Pool Namen ist. Als Backing-Devices werden Dateien verwendet, wobei der Dateiname gleich dem Backing-Device Namen ist. Das Mapping wird weiterhin über virtuelle Target Devices realisiert, im Bild vtscsi3 und vtscsi4. Das Attribut aix_tdev der virtuellen Target Devices zeigt dabei auf die jeweilige Datei im File Storage Pool.