VMware Bitfusion und Tanzu – Teil 3: Bitfusion aus Kubernetes Pods und TKGS nutzen

Dies ist ein mehrteiliger Artikel rund um das Produkt VMware Bitfusion. Ich werde eine Einführung in die Technik geben, wie man einen Bitfusion Server einrichtet und wie man dessen Dienste aus Kubernetes Pods nutzen kann.

Wir haben in den Teilen 1 und 2 gesehen, was Bitfusion ist und wie man einen Bitfusion Server Cluster aufsetzt. Der herausfordernde Teil ist, diesen Bitfusion Cluster aus Kubernetes Pods nutzbar zu machen.

Damit Container auf Bitfusion GPU-Ressourcen zugreifen können, müssen ein paar Rahmenbedingugen erfüllt sein.

Ich setze in dieser Anleitung voraus, dass wir einen konfigurierten vSphere-Tanzu Cluster zur Verfügung haben, sowie einen Namespace, einen User, eine Storage-Class und die Kubernetes CLI Tools. Das Netzwerk kann entweder mit NSX-T oder mit Distributed-vSwitches und einem Loadbalancer wie zum Beispiel dem AVI-Loadbalancer organisiert sein.

Im beschriebenen PoC wurde aus Gründen der Einfachheit Tanzu on vSphere ohne NSX-T verwendet. Zum Einsatz kam der AVI-Loadbalancer, der jetzt offiziell NSX-Advanced-Loadbalancer genannt wird.

Außerdem benötigen wir ein Linux System mit Zugriff auf Github oder einen Mirror für die Vorbereitung des Clusters.

Der Ablauf ist folgender:

  • TKGS Cluster erzeugen
  • Bitfusion Baremetal Token laden und K8s Secret erzeugen
  • Git Projekt laden und Makefile anpassen
  • Device-Plugin auf TKGS-Cluster bereitstellen
  • Pod Deployment
„VMware Bitfusion und Tanzu – Teil 3: Bitfusion aus Kubernetes Pods und TKGS nutzen“ weiterlesen

VMware Bitfusion und Tanzu – Teil 2: Bitfusion Server Setup

Dies ist ein mehrteiliger Artikel rund um das Produkt VMware Bitfusion. Ich werde eine Einführung in die Technik geben, wie man einen Bitfusion Server einrichtet und wie man dessen Dienste aus Kubernetes Pods nutzen kann.

Bitfusion Server Setup Vorbereitungen

Ein Bitfusion Server Cluster muss folgende Anforderungen erfüllen:

  • vSphere 7 oder neuer
  • 10 GBit LAN Minimum für das Bitfusion Netzwerk für kleinere Anwendungen. Hohe Bandbreite und geringe Latenz sind elementar wichtig. Empfohlen werden 40 Gbit oder gar 100 Gbit.
  • Nvidia GPU mit CUDA Funktionalität und DirectPath I/O Unterstützung:
    • Pascal P40
    • Tesla V100
    • T4 Tensor
    • A100 Tensor
  • mindestens 3 Bitfusion Server pro Cluster für Hochverfügbarkeit

Diese Setup Anleitung setzt voraus, daß die Grafikkarten in den ESXi 7+ Servern bereitgestellt wurden und die Hosts einem Cluster in vCenter beigetreten sind.

„VMware Bitfusion und Tanzu – Teil 2: Bitfusion Server Setup“ weiterlesen

VMware Bitfusion und Tanzu – Teil 1: Eine Einführung in Bitfusion

Dies wird ein mehrteiliger Artikel rund um das Produkt VMware Bitfusion. Ich werde eine Einführung in die Technik geben, wie man einen Bitfusion Server einrichtet und wie man dessen Dienste aus Kubernetes Pods nutzen kann.

Was ist Bitfusion?

Im August 2019 übernahm VMware BitFusion, einen führenden Anbieter im Bereich der GPU-Virtualisierung. Bitfusion bietet eine Softwareplattform, die bestimmte physische Ressourcen von den Compute-Servern entkoppelt. Es ist nicht für Grafikdarstellung oder Rendering konzipiert, sondern sondern vielmehr für Machine-Learning (ML) und Künstliche Intelligenz (AI). Bitfusion Systeme (Client und Server) laufen Stand heute nur auf ausgewählten Linux Systemen und unterstützen ML-Anwendungen wie beispielsweise TensorFlow.

Warum sind GPU für ML/AI Anwendungen so wichtig?

Prozessoren (Central Processing Unit / CPU) in aktuellen Systemen sind darauf optimiert, serielle Tasks in möglichst kurzer Zeit abzuarbeiten und dabei schnell zwischen Tasks zu wechseln. GPU (Graphics Processor Unit) dagegen können sehr viele Rechenoperation parallel bearbeiten. Im Namen der GPU steckt die ursprüngliche Anwendung. Die CPU sollte durch GPU bei der Grafikdarstellung entlastet werden, indem sämtliche Render- und Polygonberechnungen auf die GPU ausgelagert wurden. Mitte der 90er Jahre konnten einige 3D-Spiele noch wahlweise mit CPU oder GPU die Darstellung rendern. Schon damals ein Unterschied wie Tag und Nacht. GPU konnten die notwendigen Polygonberechnungen viel schneller und flüssiger berechnen.

Eine schöne Gegenüberstellung von GPU- und CPU-Architektur bescheibt Niels Hagoort in seinem Blogpost „Exploring the GPU Architecture„.

Aufgrund ihrer Architektur sind GPU jedoch nicht nur für Grafikanwendung ideal, sondern für alle Anwendungen, bei denen sehr viele arithmetische Operationen parallel ausgeführt werden müssen. Dazu gehören Blockchain, ML, AI und jede Art von Datenanalyse (Numbercrunching).

„VMware Bitfusion und Tanzu – Teil 1: Eine Einführung in Bitfusion“ weiterlesen

NSX-T Edge Ports am N-VDS blockiert

In meinem Homelab hatte ich vor einigen Wochen Tanzu mit NSX-T aktiviert. Nach einigen Hürden in der Planungsphase funktionierte die Konfiguration und auch das Nord-Süd Routing funktionierte tadellos. Die Edge-Nodes peerten über BGP mit dem physischen Router und machten die Routen in neue Segmente dort bekannt, so dass sie ohne weitere Konfiguratiom im Router sofort verfügbar waren.

Eine Besonderheit, die mein Lab von einer Produktivumgebung unterscheidet, ist dass es nicht 24/7 durchläuft. D.h. nach getaner Arbeit wird der gesamte Cluster herunter gefahren und die Anlage abgeschaltet. Schließlich verursacht ein Cluster im Leerlauf viel Lärm und verbraucht unnötig Energie.

Kürzlich startete ich das Lab neu und musste feststellen, daß aus den NSX Segmenten kein Kontakt zum Router oder DNS Server möglich war. Ein Fall fürs Troubleshooting.

Zunächst prüfte ich die Geneve-Tunnel zwischen den Transport-Nodes. Hier war alles in Ordnung und jeder Transport-Node konnte mit jedem anderen kommunizieren. Die Ursache wurde schnell in den Edge-Nodes lokalisiert. Ein Reboot der Edges oder ein vMotion auf einen anderen Host brachten keine Verbesserung.

Die Edges waren nicht komplett offline. Über das Management-Network waren sie administrierbar. Traceroute funktionierte über T1 und T0 Servicerouter bis zum Fastpath Interface fp-eth0. Ab dort wurde kein Paket weitergeleitet.

Das Interface fp-eth0 ist mit der verteilten Portgruppe Edge-Trunk auf vSwitch VDS-NSX verbunden. Ein Kontrollblick im vSphere-Client zeigte schnell, dass die Uplink Ports der Edges blockiert waren. Nicht im Status „down“, sondern geblockt.

Einen Kunden würde ich an dieser Stelle fragen, was er verändert habe. Ich bin mir aber sehr sicher, keine Veränderung am System oder der Konfiguration gemacht zu haben. Ja, das sagen sie alle 😉

„NSX-T Edge Ports am N-VDS blockiert“ weiterlesen