Baukastenmodus

von Martin Loschwitz

Die Virtualisierungsplattform Proxmox gilt als Geheimtipp für Umgebungen, die VMware-frei bleiben sollen. Doch wer sich dazu entschließt, damit ein Virtualisierungssetup zu realisieren, sieht sich vielen Fragen gegenüber: Welche Hardware braucht es? Wie sieht es mit dem Thema Storage aus? Und wie baut der Admin das physische Netz so, dass es später die nötige Skalierbarkeit bietet? Der folgende Artikel begleitet Sie angefangen bei der Planung bis hin zur Inbetriebnahme von Proxmox mit vielen praktischen Tipps.

Kaum ein Admin kann sich eine IT noch ohne Virtualisierung vorstellen. Der Trend hin zu virtuellen Workloads nahm schon vor 20 Jahren Fahrt auf und erhielt in letzter Zeit durch Cloud Computing und Container-basierte Anwendungen neuen Auftrieb. Das betrifft mittlerweile nicht nur die virtuellen Systeme selbst, sondern auch umgebende Technik wie das Netz oder den Speicher: Software-defined Storage und Software-defined Networking haben sich im Fahrwasser der Cloud ebenfalls einen festen Platz in der IT der Gegenwart erarbeitet.

Es muss allerdings längst nicht in jedem Fall eine Cloudlösung sein, um dem Admin beim Abwickeln seiner Workloads das Leben zu erleichtern. Vor ein paar Jahren galt OpenStack als eine Art Allzweckwaffe bei der Umsetzung virtueller Setups. Erst lange nach Beginn großer Migrationsprojekte merkte manches Unternehmen, dass OpenStack viel zu komplex für den eigenen Workload ist und dass einfache, gemanagte Virtualisierung vollkommen ausreichend gewesen wäre. Werkzeuge dafür gibt es zuhauf: Platzhirsch VMware dürfte jedem ein Begriff sein. Red Hat mischt im Spiel ebenfalls mit und vertreibt ein kommerzielles Produkt auf Basis von oVirt. Ein weiterer Proband ist das besagte Proxmox, das eine gleichnamige Firma aus Wien vertreibt.

Keine Wege verbauen

Rudi Carrell hat einmal ganz treffend festgestellt, dass Künstler Witze auf der Bühne nur dann aus dem Ärmel schütteln können, wenn sie sie vorher dort hineingesteckt haben. Ganz ähnlich ist die Situation bei der Planung einer Virtualisierungsplattform: Nur solche Technologie lässt sich später benutzen oder installieren, die der Admin im Vorfeld nicht durch eine bewusste Design-Entscheidung verunmöglicht hat.

Proxmox kommt mit einer riesigen Menge Features daher. Aus Sicht des Admins lässt sich kaum sinnvoll vorhersagen, welche davon zu einem späteren Zeitpunkt möglicherweise einmal zum Einsatz kommen sollen und welche nicht. Die oberste Prämisse bei der Planung entsprechender Setups ist deshalb, so wenige Design-Entscheidungen wie möglich zu treffen, die spätere Änderungen der Plattform vielleicht unmöglich machen. Es wäre beispielsweise alles andere als hilfreich, von vornherein nur eine Storage-Option etwa in Form vom Network Attached Storage (NAS) vorzusehen und skalierbare Lösungen wie Ceph auszuschließen. Denn im Gespann mit Ceph kommt auch dessen S3-kompatible Schnittstelle, die sich in modernen Umgebungen für das Ablegen generischer Dateien über ein standardisiertes Protokoll gut nutzen lässt.

Das Rückgrat jeder funktionalen Virtualisierungsplattform ist ihre Hardware. Leistung, die auf der Hardware-Ebene nicht vorhanden ist, lässt sich auf der Software-Ebene nicht abrufen. Der Kauf der richtigen Hardware ist deshalb ein kritischer Faktor für den Erfolg des Setups am Anfang sowie über seine gesamte Lebensdauer hinweg. Und der Faktor Hardware umfasst mehrere Dimensionen: Neben den Rechnern für den Betrieb der virtuellen Maschinen steht die Netzwerkinfrastruktur im Fokus.

Und weil virtuelle Umgebungen ebenfalls persistenten Speicher brauchen, kommt diesem auch eine Schlüsselrolle zu. Die beiden letztgenannten Faktoren sind de facto fast wichtiger als die Frage nach der Compute-Hardware. Denn die lässt sich bei Bedarf recht unkompliziert ersetzen. Storage- und Netzwerkinfrastruktur hingegen nicht – und schon gar nicht im laufenden Betrieb.

Viel Durchsatz beim Netz

Im Grunde das einfachste Thema ist bei der Hardware das Thema Netzwerk. Kleinere Infrastrukturen unterscheiden sich von Clouds ja gerade dadurch, dass sie von vornherein nicht nahtlos in die Breite skalieren sollen. Wollen Sie in Proxmox später HA-Funktionen für seine virtuellen Instanzen nutzen, also automatischen Failover, setzt das die Nutzung des Cluster-Features in Proxmox voraus. Das kann technologiebedingt aber nicht mehr als 32 Knoten verwalten – für einen solchen Cluster ist bei 32 Knoten also Schluss.

Unter der Annahme, dass Compute-Server viel Strom fressen und der Strom pro Rack begrenzt ist, lassen sich von diesen Geräten üblicherweise 16 Server pro Rack unterbringen. Ein Setup beansprucht im RZ also nicht mehr als zwei Racks. Und deren Netzwerkanbindungen können Sie mit Standardhardware und einer klassischen Verkabelung mit MLAG sinnvoll abbilden. Die Hardware welches Netzwerkherstellers dann zum Einsatz kommen soll, obliegt letztlich dem persönlichen Geschmack des Unternehmens. Alle Standardzulieferer haben passende Geräte im Programm.

Achten sollten Sie allerdings auf hohe Bandbreiten. Moderne Computing-Server verfügen nicht selten über 128 physische CPU-Kerne, die per Hyperthreading zu 256 Threads mutieren. Rechnen Sie darauf noch die übliche Überprovisionierung um den Faktor 4, ergeben sich pro Server 1024 nutzbare vCPUs. Mit 10 GBit/s ist es da kaum getan, denn jeder virtuellen CPU stünden dann nur noch 10 MBit/s zur Verfügung. Das muss kein Problem sein, kann aber eines werden. 25-GBit/s-Switches sind heute problemlos zu bekommen, und 400-GBit/s-Geräte tauchen langsam in den

Lineups der Hersteller auf. Wer plant, seine Virtualisierungsumgebung über mehrere Jahre zu betreiben, investiert also lieber mehr Geld am Anfang und macht seine Umgebung dadurch zukunftssicherer.

Storage klassisch

Eine der wichtigsten Fragen begegnet Ihnen im Kontext des Themas Storage. Hier ist ganz banal die Frage gemeint, ob Sie Ihren Storage klassisch implementieren wollen, also in Form eines Network Attached Storage (NAS) oder eines Storage Area Networks (SAN), oder ob eine moderne Speicherlösung wie Ceph zum Einsatz kommen soll. Das hat freilich auch etwas mit der Frage zu tun, wie viel Geld Sie ausgeben wollen und wie sehr Sie den benötigten Plattenplatz perspektivisch ansteigen sehen.

Können Sie mit einiger Gewissheit den benötigten Speicherplatz prognostizieren, spricht nichts gegen den klassischen Ansatz eines NAS oder SAN. Selbst diese bringen heute zum Teil die Möglichkeit mit, im weiteren Verlauf zusätzliche Shelves mit Festplatten anzuschließen, sodass sich die Kapazität der Lösung erhöht. Die Herausforderung bei diesen Geräten ist eher der typische Vendor-Lock-in: Wer sich einmal den Storage eines Herstellers ins Rack hängt, muss Ersatzteile und Teile zur Erweiterung des Arrays vom Anbieter kaufen. Und für Erweiterungsbauteile verrechnen die Hersteller bis heute zum Teil fürstliche Beträge.

Hinzu kommt, dass die Anbindung möglicherweise den Aufbau einer zusätzlichen Netzwerkinfrastruktur bedingt. Soll der Zugriff auf den Speicher etwa über FibreChannel geschehen, benötigen alle Compute-Hosts entsprechende HBAs und die passende Verkabelung.

Alternative Ceph

Die Alternative zu klassischen Speicherumgebungen ist SDS, also Software-defined Storage auf Basis von Ceph. Proxmox beherrscht den Umgang damit mittlerweile hervorragend, bindet Vol-umes aus einem Ceph-Cluster nahtlos ein und nutzt sie als Backing Device für virtuelle Maschinen. Ein Ceph-Cluster läuft in aller Regel auf Hardware von der Stange und lässt sich zu einem späteren Zeitpunkt mit beliebigen Servern – auch anderer Anbieter – erweitern.

Ceph beherrscht jedoch aktuell ausschließlich TCP/IP als Zugriffsprotokoll, die bei FibreChannel nötige Parallelverkabelung für eine zweite Netzwerktechnologie entfällt also. Wollen Sie jedoch sicher sein, dass Sie in Ihrem Storage hohe Bandbreiten zur Verfügung haben, müssen Sie das ebenso bei der Planung der Netzwerkinfrastruktur beachten. Ceph beherrscht die Auftrennung von Traffic zwischen den Storage-Knoten (private network) und dem Storage und seinen Clients (public network). Dies erhöht aber die Anzahl notwendiger NICs in den Servern und führt zu mehr Kabeln im Rack.

Entscheiden Sie sich für Ceph, sind drei Server das Minimum. Eine Kombination aus Festplatten und MON-Servern, die in Ceph das Quorum sowie die Cluster-Funktionalität überwachen, hat sich bewährt. Allzu groß sollte die Menge des angebotenen Bruttospeichers pro Knoten nicht sein. Zwölf 14-TByte-Platten pro System klingen verlockend, führen jedoch dazu, dass der Cluster ordentlich Resynchronisierungs-Traffic abwickeln muss, falls mal einer der Knoten ausfällt.

Genau das ist auch der Grund, warum hyperkonvergente Installationen eine eher bescheidene Idee sind – denn auf diesen reißt der Resynchronisierungs-Traffic zusammen mit der anfallenden Last auf den CPUs gerne mal die Performance in den Abgrund. Wer Ceph wie von Red Hat empfohlen auf eigenen Servern betreibt, sollte darauf achten, dass er einen physischen Kern pro Festplatte pro Server sowie 1 GByte RAM pro angebotenem TByte Speicherplatz beschafft. Auf RAID-Controller sollte der Admin zudem verzichten: Ceph verwaltet Redundanz über seine Festplatten selbst.

Ob NAS, SAN oder SDS sich finanziell eher lohnt, lässt sich pauschal nicht beantworten. In jedem Fall sollten Sie Angebote für die Hard- und Software von verschiedenen Anbietern einholen und bei der Analyse der erwarteten Kosten alle aufgezählten Faktoren einfließen lassen. Eventuell spielt auch das Training eine Rolle: Wer bereits eine auf Dell-EMC oder NetApp geschulte Truppe hat, wird sich mit eben diesen Geräten leichter tun als mit Ceph. Grundsätzlich aber gilt: Aktuelle NAS- oder SAN-Appliances werden den Workload in einem Proxmox-Cluster ohne Mühe handhaben.

Vollgas beim Compute-Knoten

Haben Sie sich erfolgreich mit den Themen Netzwerk und Storage befasst, steht die Frage an, welche Compute-Knoten anzuschaffen sind. Hier ist der vorgegebene Rahmen nahezu beliebig groß und es gilt: Je mehr, desto besser. Ein paar Empfehlungen aus unserer Erfahrung lassen sich allerdings formulieren:

Zunächst tun Sie gut daran abzuschätzen, ob der Workload in Ihrer Proxmox-Umgebung eher CPU- oder RAM-lastig sein wird oder ob ein guter Mix aus beiden Arten gefragt ist. Die vCPU-Ratio zu RAM liegt in den gängigen Berechnungen bei 1:2 oder 1:4, auf eine vCPU kommen 2 oder 4 GByte RAM. Je mehr vCPUs pro Höheneinheit zur Verfügung stehen, desto potenter ist das System insgesamt. Proportional kleiner ist entsprechend die Wahrscheinlichkeit, dass Sie zu einem späteren Zeitpunkt Compute-Knoten durch mächtigere Server austauschen müssen.

Bei den CPUs hat AMD aktuell deshalb die Nase klar vorn. Die aktuellen Xeons von Intel haben den Epyc-CPUs bei den meisten Workloads wenig bis gar nichts entgegenzusetzen, zumal die CPUs von AMD auch noch mit mehr Kernen daherkommen. Ausgehend davon lassen sich die Spezifikationen für die benötigten Compute-Knoten bestimmen. Kaufen Sie entsprechend viele Geräte auf einmal, gewähren die großen Hersteller üblicherweise großzügige Rabatte.

Infrastruktur vorbereiten

Sind alle benötigten Hardwarekomponenten geliefert und verbaut, kann es fast losgehen. Fast, weil noch auf ein paar Infrastrukturkomponenten hingewiesen sein soll. Dieser Artikel geht davon aus, dass im RZ sowohl NTP-Server als auch DNS-Server (für autoritatives DNS sowie für Reverse DNS) zur Verfügung stehen. Beide Dienste werden im Proxmox-Kontext an verschiedenen Stellen benötigt, sodass sie zuverlässig ihre Arbeit verrichten müssen. Ist diese Anforderung erfüllt, geht es mit der Installation von Proxmox selbst los.

Wie Sie dabei vorgehen, hängt auch vom Gesamtaufbau ab. Soll als Storage Ceph zum Einsatz kommen, ergibt es Sinn, eben dieses gleich am Anfang des Deployments zu berücksichtigen. Proxmox VE kommt in einem schlanken ISO-Image vom Hersteller daher [1]. Üblicherweise schreiben Sie dies per "dd" auf einen USB-Stick und starten auf dem Zielsystem dann von diesem USB-Riegel. Proxmox basiert auf Debian GNU/Linux, nutzt jedoch einen modifizierten Installationsassistenten. Der gibt sich in Summe mit sehr wenigen Details zur Konfiguration zufrieden (Bild 1), sodass das erste Proxmox-System bald gestartet ist.

Automatisierte Installation

Wer sich mehreren Racks mit den beschriebenen 32 Servern gegenübersieht, findet die Idee vielleicht nicht ganz so prickelnd, diese händisch zu installieren. Es existieren mehrere Möglichkeiten, um sich das Leben in Sachen Automation der Proxmox-Installation zumindest zu erleichtern. Eine Option besteht darin, ein von Stefan Heitmüller entwickeltes Skript zu nutzen, um aus dem Proxmox-ISO-Abbild den Kernel sowie dessen Initrd zu extrahieren. Das Skript findet sich unter [2] samt einer Anleitung, wie es zu benutzen ist.

Haben Sie den Kernel und die Initrd-Datei extrahiert, kopieren Sie diese in Ihr pxeboot-Verzeichnis, hinterlegen in der Konfiguration des Bootloaders die entsprechenden Einträge, kopieren den Kernel sowie die Ramdisk an die richtige Stelle auf dem pxeboot-Server und können das Proxmox-Setup automatisiert starten. Die komplette Anleitung dazu findet sich samt Beispielen für den erwähnten Bootloader auf der GitHub-Seite von Stefan Heitmüller.

Die Anleitung setzt allerdings voraus, dass es bereits einen Bootstrap-Knoten für PXE-Starts gibt. Ein Server, auf dem DHCP, NTP sowie TFTP oder HTTP samt pxeboot eingerichtet sind, sollte also bereits existieren – oder zumindest sollte er im Laufe des Vorgangs entstehen. Diese Variante kommt im Gegensatz zum USB-Stick mit dem großen Vorteil daher, dass sich alle 32 potenziellen Systeme zur selben Zeit installieren lassen. Die Installation selbst ist allerdings noch immer händisch durchzuführen.

Noch eleganter und vollständig automatisch lässt sich die Proxmox-Installation mittels eines kleinen Tricks gestalten. Denn letztlich fungiert Proxmox VE 6.2 als Aufsatz für Debian GNU/Linux 10 alias Buster. Weil Proxmox ganz hervorragende Arbeit leistet und sämtliche eigenen Modifikationen in Form von Debian-Paketen ausliefert, lassen diese sich auch auf ein ganz normal installiertes Debian-Buster-System anwenden. Der Weg zur vollautomatischen Proxmox-VE-Installation führt im ersten Schritt deshalb über eine ganz normale, automatische Debian-Installation mittels Preseeding. In der Debian-Dokumentation ist ausführlich erläutert, wie Preseeding arbeitet und wie es sich nutzen lässt [3].

Wieder benötigen Sie bei dieser Variante einen bestehenden Preseeding-Host mit DHCP, PXE und HTTP. Über den ersten beschriebenen Weg hinaus brauchen Sie zudem Preseeding-Dateien für Ihre Server, die Informationen zur genutzten Sprache des Systems, zum Festplattenlayout, zu dessen Netzwerkkonfiguration und zu den Paketen enthalten, die das fertige System später haben soll. Bereits in der Preseeding-Konfiguration bestimmen Sie auch zusätzliche Verzeichnisse für Pakete, die der Debian-Installer nutzen soll. Das Proxmox-Wiki enthält eine Anleitung, die beschreibt, wie aus einem Buster-Host ein echter Proxmox-Knoten entsteht [4]. Sorgen Sie in Ihrem Preseeding-Skript dafür, dass diese Anforderungen erfüllt sind, lässt Proxmox VE sich auf diese Weise automatisiert ausrollen.

Netzwerkeinrichtung abschließen

Ganz gleich ob automatisiert oder manuell installiert: Nach dem ersten Start eines frisch installierten Proxmox-Systems loggen Sie sich im Normalfall zunächst auf dessen Management-GUI ein. Das Passwort dafür ist das des Nutzers "root", das der Admin während der Installation angegeben hat. Das Webinterface lauscht auf der IP-Adresse des Hosts auf Port 8006.

Während der Installation nutzt Proxmox die erste Netzwerkkarte, die es findet und die eine DHCP-Anfrage beantwortet. Moderne Server werden in der Regel jedoch mehrere Netzwerkports haben. Das geht mit dem Wunsch einher, diese etwa für Bonding zusammenzuschalten. Sie erledigen das pro Host über das jeweilige Management-Interface. Dazu wählen Sie links in der Leiste "Server View" das jeweilige System aus und klicken dann in der Mitte auf "System / Network". Hier lassen sich die Netzwerkschnittstellen exakt so festlegen, wie Sie es für Ihren Einsatzzweck benötigen.

Cluster initialisieren

Bevor sich ein Ceph-Cluster oder irgendeine Form der Virtualisierung in Proxmox VE einrichten lässt, konfigurieren Sie zunächst den Cluster für Proxmox selbst. Dazu wählen Sie auf einem beliebigen Knoten oben links bei "Server View" den Eintrag "Datacenter" und danach rechts den Eintrag "Cluster" aus. Im Anschluss erfolgt ein Klick auf "Create Cluster". Auf allen anderen Systemen verfahren Sie identisch, klicken oben jedoch nicht auf "Create Cluster", sondern auf "Join Cluster".

Bei der Initialisierung des ersten Clusters gibt Proxmox VE einen Codeblock aus, den Sie auf den anderen Systemen während des "Join Cluster"-Vorgangs eingeben müssen. Stück für Stück erweitern Sie auf diese Weise die Umgebung, bis schließlich alle Knoten Bestandteil des Clusters sind. Nun ist es übrigens auch eine gute Idee, die eigenen Proxmox-Subskriptionen zu aktivieren.

Dazu wählen Sie links jeweils den Server aus und klicken dann in der Mitte auf "Subscription". Oben erscheint dann der Button "Update Subscription Key". Ist der Schlüssel für die Subskription eingetragen, kann das System sich mit Updates von Proxmox versorgen und bekommt das komplette Feature-Set. Eine Übersicht über Proxmox-Subskriptionen findet sich unter [5], die billigste Variante schlägt mit 85 Euro pro CPU-Socket pro Jahr zu Buche.

Ceph als Storage einrichten

Soll Ceph zum Einsatz kommen, setzen Sie es nun auf. Dazu wählen Sie auf einem beliebigen Cluster-Knoten im Web-Frontend links die Knoten aus, die Ceph bekommen sollen, und klicken dann rechts auf "Ceph". Es erscheint der Button "Install Ceph-nautilus", auf den Sie ebenfalls klicken. Der Installationsassistent führt Sie nun durch den Vorgang der Ceph-Installation.

Der besteht aus mehreren Schritten: Im ersten initialisieren Sie den Ceph-Cluster durch die Installation eines ersten MONs. In der "Ceph"-Ansicht des Systems erscheint danach ein Baum unterhalb des Eintrags für Ceph, der den Punkt "MONS" enthält. Oben klicken Sie auf "Add MON" und wählen dann einen weiteren Ceph-Knoten aus. Das Spiel geht so lange, bis alle zukünftigen MON-Hosts einen laufenden MON-Prozess haben und diese alle zum selben Cluster gehören. Danach wiederholen Sie den Vorgang für jede einzelne Festplatte, die in Ceph zum OSD werden soll. Dazu bestimmen Sie zunächst links den Server, klicken dann in der Mitte auf "Ceph / OSDs" und nutzen oben den Button "Add OSD". Das führt, so wie Proxmox es implementiert hat, zwar zum nervösen Klickfinger, wenn viele Platten OSDs werden sollen, funktioniert letztlich aber gut (Bild 3).

Praktisch: Proxmox konfiguriert Ceph gleich als Storage für virtuelle Maschinen in sich selbst. Wer eine VM anlegt, hat Ceph als Option für deren Backend-Speicher also ab Werk vorgegeben. Wenn der Ceph-Cluster einmal steht, lässt er sich in Proxmox also auch unmittelbar nutzen.

Die erste VM in Betrieb nehmen

Haben Sie sich bis hierhin durch das Set-up von Hard- wie Software gekämpft, ist der Mühe Lohn die erste eigene virtuelle Instanz. Dazu klicken Sie oben rechts in Proxmox auf "Create VM", woraufhin sich ein weiterer Assistent öffnet. Hier legen Sie Schritt für Schritt die Parameter der neuen VM fest, etwa von welchem Image Sie sie installieren wollen und welchen Speicher die VM nutzen soll.

Kommt Ceph oder ein redundantes NAS/ SAN zum Einsatz, ist die Redundanz des Speichers für die virtuelle Instanz automatisch gegeben. Entsprechend richtet Proxmox die VM gleich hochverfügbar ein, sodass Proxmox die virtuelle Maschine auch auf einem anderen System automatisch neu startet, wenn der Server abstürzt, auf dem sie ursprünglich lief.

Freilich bietet Proxmox noch eine Vielzahl von Stellschrauben, um sein eigenes Verhalten in mannigfaltiger Art und Weise zu beeinflussen. Sie alle zu beschreiben, würde den Rahmen dieses Artikels bei weitem sprengen. Der vorgestellte Grundaufbau eignet sich als Fundament für den Admin aber ganz hervorragend, um sich – nicht zuletzt anhand der Doku von Proxmox – voranzuhangeln.

Fazit

Proxmox ist ein hervorragendes Werkzeug, wenn es darum geht, kleinere und mittelgroße Virtualisierungsumgebungen zu schaffen. Die Werkzeuge der Cloud, die auch im Proxmox-Kontext Sinn ergeben, integriert das Werkzeug gut und sinnvoll. Das Paradebeispiel hierfür ist Ceph. Andere Features, die etwa von OpenStack bekannt sind, fehlen bewusst, sodass der Admin es bei Proxmox mit deutlich geringerer Komplexität zu tun hat. Zweifelsohne ist Proxmox im Kontext klassischer Virtualisierungssetups ein echter Konkurrent für VMware, gerade weil Funktionen wie redundanter Speicher und Hochverfügbarkeit für virtuelle Instanzen ab Werk einfach funktionieren.

Für eine vielseitige Virtualisierungsumgebung muss aber nicht nur die Software stimmen. Wichtig ist, dass Sie schon in der Vorbereitungsphase Ihre grundlegenden Bedürfnisse definieren. Diese beziehen Sie im Anschluss ein, wenn es um die Planung der Hardware sowie die Skizzierung der benötigten Infrastruktur geht. Dabei stellt sich als hilfreich heraus, Design-Entscheidungen nur dann zu treffen, wenn sie zu einem bestimmten Zeitpunkt unbedingt nötig sind – denn so lassen Sie sich Alternativen offen, die Sie später nutzen können.

Mit Proxmox zur eigenen Virtualisierungsumgebung

Baukastenmodus

Keine Wege verbauen

Keine Wege verbauen

Viel Durchsatz beim Netz

Storage klassisch

Alternative Ceph

Vollgas beim Compute-Knoten

Infrastruktur vorbereiten

Automatisierte Installation

Netzwerkeinrichtung abschließen

Cluster initialisieren

Ceph als Storage einrichten

Die erste VM in Betrieb nehmen

Fazit