Falk Dübbert ...

Neu-Bestückung Testrack

| Keine Kommentare

Bislang habe ich mir beim Testen mit alten Notebooks und einem N54L beholfen. Sowas stößt natürlich schnell an seine Grenzen, wenn es darum geht eine ganze Serverlandschaft oder kompliziertere Setups und Prozesse zu testen. Das Testrack bzw. dessen Neubau steht schon länger auf der ToDo. Der Schrank hat 24Höheneinheiten und ist 86cm tief. 

Meiner alten Doktrin, möglichst wenige Sorten zu haben, sind alle Server HPE DL360 Generation 8 (Allerdings sind 3 Stück -p mit SFF und 2 Stück -e mit LFF), die ich trotz der Nachteile mit normalen U-DIMMs bestücke. Die Hosts haben, abweichend von einem produktiven Aufbau, lokalen Storage und nur Gigabit-Ethernet. 

Die Virtualisierung wird zunächst mit einer VSphere passieren, aber ich werde eine Möglichkeit einbauen, ein oder zwei Hosts auf Openstack umzuschalten oder nested Openstack-Hosts als VM laufen zu lassen. 

testrack

Folgende Dinge will ich mit dem Rack testen / lernen / ausprobieren: 

  • Defensive Computing
    Normalerweise ist ein Testrack nicht der Ort für defensives Computing, aber ich möchte das Testrack so betreiben, dass ich die Praktiken von dort jederzeit auf die produktiven Fragestellungen meiner Kunden abbilden kann. 
    Ich profitiere viel von meiner Erfahrung als Admin, Retter, Macher, Techniker und von meinem Ingenieur-Studium und kann meist gut einschätzen welchen Kompromiss man bei der Gestaltung von IT-Strukturen eingehen kann. Aber mittlerweile bin ich mir sehr sicher, dass man in der IT nicht mehr "pfuschen" kann. Der Haufen "Technical Debt", den man mit Pfusch ansammelt, hat die unangenehme Eigenschaft, dann zu brechen, wenn man es am allerwenigsten gebrauchen kann. IT-Abteilungen und ihre Budgets werden immer kleiner und Applikations-lastiger - damit wird man sich mit Blech, Storage oder Backup und Restore nicht befassen müssen wollen und sie dürfen einfach keine Probleme machen.
  • High-Efficiency Computing
    Das ist, wenn man Footprint-Minimalisierung im positiven Sinn auf die Spitze treibt. Also so arbeitet, wie man in den Achtzigern Computerspiele gemacht hat. Ich sehe, genau wie Tim O'Reilly den baldigen Peak Digital voraus. Alles wird komplexer, bis es einfacher wird. Aktuell haben wir enorm komplexe IT-Umgebungen. Durch die Clouds sind tausende Systeme beteiligt. Bislang ist es so, dass diese Komplexität nur selten bis zum Endkunden durchdringt, aber genau, wie wir bei der Mobilität über CO2 und Stickoxide nachdenken, wird man den Footprint von allem in der IT in den Griff bekommen müssen. 
  • Docker-Automation, Service-Bereitstellung mit Docker unter VMware
    Ich will mehr mit Automation im High-Level-Bereich testen. Meiner Ansicht nach, wird eine interne IT in Zukunft eher wie ein Hoster sein und die Anwendungsentwickler je nach Schutz-Bedarf, Last oder Lebensdauer des Services entscheiden, ob dieser On-Premise oder in einer Cloud gestemmt wird. Dabei ist dann entscheidend, dass diese Entscheidung nicht von einer fehlenden Schnittstelle eingeschränkt wird. 
  • Patching und Updates durch Erzeugen der VMs von gepatchten Templates und schnellen Deployment der Services. 
    Ich bin großer Anhänger von disposable IT. Wenn man das Vernichten seiner gesamten Struktur zum Teil des Prozesses macht, hat man zwangsläufig auch alle Prozesse im Blick. Wenn man zum Beispiel die Betriebssysteme neu erzeugt und anschließend automatisiert die Services darauf wiederherstellt, fällt die Pflicht zum Systembackup.  
  • Orchestrator-Skripte am Ticket-System
  • 360°-Monitoring inkl. Failover-Automation (ist mehr was zum Vorführen) 

Das Hauptproblem wird sein, dass, wenn das Rack fertig ist, es auf dem Dachboden zu heiß für dessen Betrieb ist. 

Keine Kommentare

    Kommentarfunktion für diesen Artikel geschlossen.