November 2021 - PowerCampus 01

November 22, 2021November 22, 2021

Virtual Network Interface Controller (vNIC)

vNIC adapter with 2 vNIC backing devices and vNIC failover.

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

November 15, 2021

Shared Ethernet Adapter

SEA with multiple trunking adapters and VLANs

Trotz SR-IOV und vNIC ist Shared Ethernet immer noch die am häufigsten verwendete Virtualisierungslösung, wenn es um die Virtualisierung von Ethernet geht. Dabei implementiert der POWER Hypervisor virtuelle interne IEEE802.1q kompatible Netzwerk-Switches, die im Zusammenspiel mit sogenannten Shared Ethernet Adaptern oder kurz SEA die Anbindung an externe Netzwerke übernehmen. Die Shared Ethernet Adapter werden durch den Virtual-I/O-Server in Software als Layer-2 Bridge implementiert.

Wie in Bild 8.2 gezeigt, kann ein Shared Ethernet Adapter mehrere sogenannte Trunking Adapter besitzen. Der gezeigte SEA hat die 3 Trunking Adapter ent8, ent9 und ent10, welche alle 3 an den virtuellen Switch mit dem Namen ETHMGMT angebunden sind. Alle Trunking Adapter unterstützen im gezeigten Fall VLAN-Tagging. Neben den Port-VLAN-IDs (PVIDs) besitzen die 3 Trunking Adapter noch weitere VLANs über VLAN-Tagging. Neben der Anbindung an den virtuellen Switch über die Trunking Adapter besitzt der SEA noch eine Anbindung an ein externes Netzwerk über den physikalischen Netzwerk-Adapter (ent0). Netzwerk-Pakete von Client-LPARs an externe Systeme werden über einen der Trunking-Adapter zum SEA und dann über den zugehörigen physikalischen Netzwerk-Adapter ins externe Netzwerk weitergeleitet. Netzwerk-Pakete von externen Systemen an Client-LPARs werden vom SEA über den Trunking Adapter mit dem richtigen VLAN an den virtuellen Switch weitergeleitet, welcher die Pakete dann an die Client-LPAR weiterleitet.

Im einfachsten Fall kann ein SEA aus nur einem Trunking Adapter bestehen. Ein SEA kann bis zu 16 Trunking Adaptern besitzen, wobei jeder der Trunking-Adapter neben der Port-VLAN-ID bis zu 20 weitere VLANs besitzen kann.

Welche SEAs es auf einem Virtual-I/O-Server schon gibt, lässt sich mit Hilfe des Kommandos „vios lssea“ (list SEAs) herausfinden:

$ vios lssea ms05-vio1
                                       TIMES   TIMES    TIMES    BRIDGE 
NAME   HA_MODE  PRIORITY  STATE       PRIMARY  BACKUP  FLIPFLOP  MODE
ent33  Sharing  1         PRIMARY_SH  1        1       0         Partial
ent34  Sharing  1         PRIMARY_SH  1        1       0         Partial
$

Zu jedem SEA werden einige grundlegende Informationen angezeigt, wie z.B. der HA-Mode (siehe später), die Priorität des SEA, sowie Informationen wie häufig der SEA schon Primary bzw. Backup war.

8.5.1. SEA ohne VLAN-Tagging

8.5.2. SEA mit VLAN-Tagging

8.5.3. Einige SEA Attribute

8.5.4. Konfigurieren einer IP-Adresse auf dem SEA

8.5.5. Hinzufügen und Wegnehmen von VLANs (nicht HA)

8.5.6. Hinzufügen und Wegnehmen von Trunking Adaptern (nicht HA)

8.5.7. Löschen eines Shared Ethernet Adapters (nicht HA)

8.5.8. HA-SEA mit Failover

8.5.9. Erzeugen von SEAs mit HA Mode (HA-SEA)

8.5.10. HA-Modes auto und standby

8.5.11. Hinzufügen und Wegnehmen von VLANs (HA-SEA)

8.5.12. Hinzufügen und Wegnehmen von Trunking Adaptern (HA-SEA)

8.5.13. Löschen von HA-SEAs

8.5.14. HA-SEA mit Load-Sharing

8.5.15. Erzeugen von SEAs mit Load-Sharing

8.5.16. Hinzufügen und Wegnehmen von VLANs (Load-Sharing)

8.5.17. Hinzufügen und Wegnehmen von Trunking Adaptern (Load-Sharing)

8.5.18. Ändern des HA-Modes zwischen Failover und Load-Sharing

8.5.19. Löschen von SEAs (Load-Sharing)

November 8, 2021

Virtuelle FC-Adapter und NPIV

Physical FC port with Virtual FC and NPIV

Eine Möglichkeit für die Virtualisierung von Storage unter PowerVM ist die Verwendung von virtuellen FC Adaptern. Dabei ist ein virtueller FC-Client Adapter über den POWER Hypervisor mit einem virtuellen FC-Server Adapter auf einem Virtual-I/O-Server verbunden, wie in Bild 7.10 gezeigt. Auf dem Virtual-I/O-Server wird der virtuelle FC-Server Adapter dann mit einem der physikalischen FC-Ports verbunden (Mapping). Jeder der verbundenen virtuellen FC-Server Adapter kann dabei einen eigenen Login in die FC-Fabric durchführen. Jeder virtuelle FC-Server Adapter bekommt dabei eine eigene 24-bit FC-Adresse zugewiesen.

Der Vorteil von Virtual FC besteht darin, das jeder virtuelle FC-Client Adapter einen eigenen N_Port besitzt und damit direkt mit dem Storage in der FC-Fabric kommunizieren kann. Die Storage-LUNs können dem virtuellen FC -Client Adapter direkt zugewiesen. Der Virtual-I/O-Server selbst sieht normalerweise die Storage-LUNs der virtuellen FC Clients nicht. Das macht die Administration deutlicher einfacher als bei virtuellem SCSI, wo jede Storage-LUN auf dem Virtual-I/O-Server auf einen virtuellen SCSI Server Adapter gemappt werden muss (siehe nächstes Kapitel).

Bevor ein virtueller FC Adapter angelegt und gemappt wird, sieht die Situation auf einem Virtual-I/O-Server so wie in Bild 7.11 dargestellt aus. Der physikalische FC-Port ist an eine FC-Fabric angeschlossen und konfiguriert daher einen N_Port. Der physikalische FC-Port loggt sich in die Fabric ein (FLOGI) und bekommt die eindeutige N_Port ID 8c8240 zugewiesen. Danach registriert der FC-Port seine WWPN (hier 10:00:00:10:9b:ab:01:02) beim Simple Name Server (SNS) der Fabric (PLOGI). Danach kann der Virtual-I/O-Server über das Gerät fcs0 mit anderen N_Ports in der Fabric kommunizieren.

N_Port-ID Virtualisierung oder kurz NPIV ist eine Erweiterung des FC-Standards und erlaubt das sich über einen physikalischen FC-Port mehr als ein N_Port in die Fabric einloggen kann. Im Prinzip gab es diese Möglichkeit schon immer, allerdings nur im Zusammenhang mit FC Arbitrated Loop (FC-AL) und Fabrics. Mit NPIV können mehrere Client LPARs einen physikalischen FC-Port gemeinsam verwenden. Jeder Client hat dabei seinen eigenen eindeutigen N_Port.

In Bild 7.12 ist die Situation mit 2 virtuellen FC-Client Adaptern gezeigt. Jeder der Client Adapter hat eine eindeutige WWPN. Diese wird von PowerVM beim Erzeugen des virtuellen FC-Client Adapters zugewiesen (um Live-Partition Mobility unterstützen zu können, werden immer 2 WWPNs zugewiesen, wobei nur eine der beiden WWPNs aktiv ist). Jeder virtuelle FC-Client Adapter benötigt auf einem Virtual-I/O-Server einen Partner Adapter, den virtuellen FC-Server Adapter (oder auch vfchost). Dem virtuellen FC-Server Adapter muß auf dem Virtual-I/O-Server einer der physikalischen FC-Ports zugeordnet werden. Ist die Client-LPAR aktiv, dann loggt sich der virtuelle FC-Server Adapter in die Fabric ein (FDISC) und bekommt eine eindeutige N_Port ID zugewiesen. Im Bild ist das für den blauen Adapter die 8c8268 und für den roten Adapter die 8c8262. Danach registriert der blaue Adapter seine Client-WWPN (hier c0:50:76:07:12:cd:00:16) beim Simple Name Server (SNS) der Fabric (PLOGI). Das gleiche macht der rote Adapter für seine Client-WWPN (hier c0:50:76:07:12:cd:00:09). Damit haben dann beide virtuellen FC-Client Adapter jeweils einen N_Port mit einer eindeutigen 24-bit ID und können damit mit anderen N_Ports in der Fabric kommunizieren.

Die zu Daten werden natürlich zwischen virtuellem FC-Client Adapter und virtuellem FC-Server Adapter nicht vom Hypervisor kopiert, das würde zuviel Performance kosten. Der Hypervisor gibt lediglich die physikalische Speicheradresse weiter, an der die Daten stehen und der physikalische FC-Port verwendet dann DMA (Direct Memory Access) um auf diese Daten dann zuzugreifen.

7.4.1. NPIV-fähige FC-Adapter

7.4.2. Hinzufügen eines virtuellen FC Adapters

7.4.3. Zuordnen eines physikalischen FC-Ports (Mapping)

7.4.4. Hinzufügen von LUNs

7.4.5. Hinzufügen eines virtuellen FC-Adapters mit Mapping

7.4.6. Ändern von Attributen eines virtuellen FC-Adapters

7.4.7. Entfernen eines NPIV-Mappings

7.4.8. Ändern eines NPIV-Mappings

7.4.9. Wegnehmen eines virtuellen FC-Adapters

7.4.10. Verwendung von vorgegebenen WWPNs