Spielen

Für mich aktuell der einzige valide Punkt für Windows ist das Spielen. Hier hat es Microsoft mit DirectX geschafft, ein Alleinstellungsmerkmal so zentral in seinem Betriebssystem zu platzieren, dass auch heute noch ein Gaming neuer Spiele auf anderen Plattformen zum Abenteuer wird, auch dank Kopierschutz. Windows ist quasi das AWS für Gaming.

Der MSI-Rechner hat (nach einem RAM-Upgrade auf 64 GB) doch ausreichend Kapazität, um Spiele zumindest in niedrigen Qualitätsstufen darzustellen. Cyberpunk 2077 lief aber mit niedrigsten Einstellungen bei 1080p trotzdem nicht flüssig genug für meine Bedürfnisse. Rocket-League kann ich aber auch in WQHD mit niedrigen Grafikeinstellungen flüssig spielen. Hier hatte ich zunächst einen anderen Eindruck gewonnen.

Spiele sind direkt beim Starten abgestürzt oder ruckelten im 1-2-fps-Bereich. Vielleicht war es aber auch ein inkompatibler Treiber, denn bei Realbench hatte ich merkwürdige Fehlermeldungen bezüglich fehlendem OpenCL.

Ubuntu

Das erste Linux, das ich auf den internen Festplatten ausprobieren wollte, war Ubuntu. Um eine echte Ausfallsicherheit der beiden Festplatten zu ermöglichen, bin ich dieser Anleitung gefolgt. Das System lief super, ich merkte aber leider einen Nachteil in der Reaktionsschnelligkeit des UIs im Vergleich zu Windows. Für mich war das jedoch in Ordnung, ist Linux doch nicht primär dafür optimiert.

Ein anderer CPU-Governor würde hier vermutlich schon Abhilfe schaffen. Da ich jedoch in dem Rechner keinen ECC-Ram verwenden kann, war mir das Root-Volume auf ZFS am Ende aber ein Dorn im Auge. Wie weiter unten ausgeführt, habe ich mich letztlich auch nicht für eine GUI mit KVM, sondern für einen Hypervisor (Proxmox) als Grundlage meiner Plattform entschieden.

Was nun folgt, ist eine von mir erdachte Architektur, die mehrere Interessen abbilden soll. Beweggründe hierfür liegen in der Wartbarkeit komplexer IT-Systeme. Denn oft habe ich solche Projekte zwar erfolgreich umgesetzt, konnte sie im Nachhinein jedoch weder reproduzieren noch (dadurch) verändern.
• Unabhängigkeit von Hardware
• Keine wiederkehrenden Kosten
• Stromsparend wo möglich
• Ausfallsicher
• Reproduzierbar

Wir steigen wie versprochen ab ins Wunschland. Man muss sich erst vor Augen führen, was man will, bevor man sich an die Lösung macht. Für meine Hobbys und Projekte zumindest ist klar: Keine Public Clouds. Hier mangelt es mir schlichtweg an Grundvertrauen gegenüber Google, Amazon, Microsoft. Dass der vorliegende Rechner hier eine untergeordnete Rolle spielt, sollte spätestens jetzt bewusst geworden sein.

Eine Kernproblematik vieler Firmen ist die Authentifizierung und Autorisierung. Doch beides wird gut und gerne auch verwechselt. Und dann entsteht die Anforderung, dass ein Angestellter eine E-Mail beim Unternehmen braucht.

Der banale, aber irrtümliche Gedankengang hierbei: Wenn man die Accounts kontrolliert, auf die die Zugriffe gewährt werden, kann man den Zugriff einfach zurückziehen. Nur ganz nebenbei wird hier eine neue Identität geschaffen. Hier spielt leider auch Compliance mit rein: Viele Firmen erlauben Kommunikation nur über die jeweilige E-Mail. Aus meiner Sicht sollte der Arbeitnehmer die Identität pflegen, der Arbeitgeber die Autorisierung.

Ich wähle für die Authentifizierung eine andere Route: keybase.io. Hier erstelle ich einen PGP-Key auf meinem Rechner für meine digitale Identität. Diese Identität beurkundige ich durch kryptografische Signaturen gegenüber (aktuell leider nicht beliebigen) Online-Diensten. Sei es GitHub, Twitter, die eigene Bitcoin Adresse, die eigene Website und – für uns am wichtigsten – die eigene E-Mail-Adresse. Dezent erwähnt sei hier auch die Möglichkeit, einen User auf einer selbst gehosteten Mastadon-Instanz (dezentrales Twitter) zu verifizieren.

Als Nächstes erstellt man in Keybase ein Team und sendet Einladungen an beliebige Identitäten. Das können alle obigen Online-Dienste sein. Ich gewähre ihrem Facebook-Nutzer Zugriff auf meine Infrastruktur. Wenn Sie sich auf Keybase registrieren und den Besitztum des Facebook-Nutzers verifizieren können, sind sie an der Teilnahme am Team berechtigt. Wenn es denn sein muss, kann hier auch eine Firmen-E-Mail Verwendung finden. Über den Klick auf einen Link in der empfangenen E-Mail beweist man die Kenntnis eines kryptografischen Geheimnisses, das man ohne Zugriff auf die E-Mail nie haben könnte. Für Facebook veröffentlicht man analog einen öffentlichen Beitrag, der von Keybase regelmäßig überprüft werden kann.

Dann kommt die Rechteverwaltung. Die kann man ebenfalls in Keybase kryptografisch abgesichert bewerkstelligen. Es gibt Gruppen, Untergruppen und Rollen innerhalb der Gruppen. Das erlaubt grundsätzliches Zugriffsmanagement, für komplexe Rechteverwaltung ist es aber vermutlich ungeeignet.

Hier kommt dann Openstack ins Spiel. Der gangbarste Weg für mich aktuell ist die Server-Nodes in Proxmox zu virtualisieren. Dann kann man in MaaS die VMs z. B. bezüglich Netzanbindung, Festplatten-Layout usw. vorkonfigurieren und dann einfach als Hardware für beliebige Infrastruktur-Deployments bereitstellen. Ideal wäre es auch, meine Raspberries als provisionierbare Ressourcen einzubinden. Dazu gibt es mittlerweile auch Anleitungen mit UEFI Boot über einen USB-Stick. In unserem Fall provisionieren wir darauf dann Openstack. Man kann hier jedoch auch direkt Kubernetes deployen, büßt dann aber an Konfigurierbarkeit der Anbindung an Unternehmensnetze ein.

Nun hat man ein Openstack, nach Anpassungen idealerweise mit allen Ressourcen, die man begehrt:
• Virtuelle und dedizierte Maschinen
• Docker + Container Registry
• Elastische IPs
• Loadbalancer auf verschiedenen Layern
• Virtuelle Netzwerke, Gateways, NATs, Sicherheitsrichtlinien, Firewalls
• Identitäten und Rollenverwaltung („IAM“)
• Verschiedene Datenspeicher (SSD, HDD, Tape?), Objektspeicher,
• DNS Server
Die Liste der theoretisch verwendbaren Ressourcen ist endlos. Und wenn sich Hardwarehersteller endlich als Zulieferer dieser abstrakten Ressourcen verstehen und diese in Openstack einfach verwendbar sind, bin zumindest ich glücklich. Dann kann ein Hersteller auch gut und gerne mehrerer dieser APIs mit einem Gerät bedienen. Und wenn es dem Hersteller noch nicht passt, kann er gerne eine Open-Source-Initiative zum Erstellen eines neuen Ressourcentyps und der Implementation davon starten.

Um nun einen Zugriff auf diese Openstack Ressourcen als Nutzer zuzugreifen, müsste hier eine Verbindung von Keybase-Identitäten an Openstack Keystone durchgeführt werden. Die Kombination würde mehrere Vorteile bieten: Wir sprechen über einen verschlüsselten Chat / Teamchat mit einem Keybase Bot (der auch nur die an ihn adressierten Nachrichten lesen kann), der uns dann temporäre Token zur Openstack-Nutzung bereitstellt. Er würde als Mediator die Rolle der Nutzer in der Keybase-Gruppe überprüfen und dann von Keystone temporäre Tokens für Dienste ausstellen. Von Keybase wird sichergestellt, dass die Verifizierung des Facebook-Accounts in diesem Beispiel weiterhin auf beiden Seiten bestand hat. Bei E-Mails besteht hier der Nachteil, dass der Besitz nur einmalig erbracht werden muss und nicht kontinuierlich überprüft werden kann.

Nun kommt Kubernetes darauf. Das ist gar nicht so einfach, wie es erst mal scheinen mag. Denn die gebotene Flexibilität in Kubernetes ist beachtlich. Es lässt sich ja erst mal alles containerisieren.

Für das Deployment gibt es mittlerweile sehr viele Möglichkeiten. Für mich in Betracht kamen folgende Lösungen:
• Kubernetes über Maas zu deployen mit „Juju“
• Kubernetes aus Openstack per „Magnum“
• K3s (Alpine Linux)
• Microk8s (Ubuntu Snaps)
• Nvidia DeepOps (Ansible -> kubespray)

Dieser Beitrag ist bereits älter als 90 Tage. Hier finden Sie die Übersicht neuer Sponsored Articles

.