Lab Umgebungen sind eine tolle Sache. Durch sie können wir neue Produkte oder Lösungsideen auf einer kleinen Plattform testen und auch zu Demonstrationszwcken leisten sie unschätzbare Dienste.
Wie viele meiner bloggenden Kollegen, fasse ich die im Lab gesammelten Erfahrungen zu kurzen oder längeren Blogbeiträgen zusammen und teile sie mit der Community. Auch ich lese regelmäßig Blogs und Tutorials, um mich über neue Produkte und Techniken zu informieren. Es gibt wohl kaum ein Thema im Bereich der Virtualisierung, zu dem nicht irgendwann, irgendwer irgendetwas geschrieben hat. Das ist unschätzbar wertvoll, da man auf diese Weise einen schnellen Einstieg in einen meist komplexen Sachverhalt bekommt.
Beim Lesen meiner (und anderer) Blogbeiträge mag der Eindruck entstehen, dass die jeweils beschriebenen Installationen nach dem simplen skip-skip-finish Prinzip ablaufen. Also Defaultwerte übernehmen, dreimal weiterklicken und fertig ist die Installation. Das darf jedoch nicht darüber hinwegtäuschen, dass eine Installation im Lab meilenweit von einer Installation in einem realen Projekt entfernt ist. Ein Lab ist kein Projekt und ein Blogpost ist kein Projektplan.
Im Lab werden Dinge sehr stark vereinfacht und es gilt das KISS Prinzip (keep it simple and stupid). Viele der verwendeten Methoden entsprechen nicht unbedingt den Empfehlungen des Herstellers, oder verbieten sich geradezu in Produktivumgebungen.
Das bedeutet übersetzt: Wenn ich ein Tutorial meines Lieblings-Bloggers [Name hier einfügen] gelesen habe, befähigt mich das noch lange nicht, das gelernte 1:1 auf ein reales Projekt zu übertragen.
Ich hatte diesbezüglich schon mehrfach Diskussionen in Projekt-Vorgesprächen. Es wurde hinterfragt, warum denn die Planungsphase so viel Zeit in Anspruch nehme. Das Produkt sei doch total einfach zu installieren, wie man es im Blog von [Name hier einfügen] nachlesen könne.
Als Blogger und Lab Benutzer weiss ich, wie diese Beiträge zu bewerten sind. Sie sind als Schnelleinstieg und leicht verständlicher Überblick in eine neue Technik zu verstehen. Mit realen Implememtierungen hat das herzlich wenig zu tun. Dies möchte ich in diesem Beitrag exemplarisch anhand einiger Beispiele herausarbeiten:
keep it simple and stupid
Im Lab bzw. in Blog-Artikeln geht es darum, einen komplexen Sachveralt auf ein verständliches Minimum herunterzubrechen. Dabei werden aus gutem Grund viele Extras und Details außer Acht gelassen.
Passwörter
Ein einheitliches und einfaches Passwort für alle Dienste und Konten. Was im realen Leben ein absolutes no-go ist, praktizieren die meisten von uns in der Lab Umgebung. Warum auch nicht? Ein simples Passwort für alles. Denn wir haben es nicht mit mit einer sicherheitskritischen Anwendung zu tun. Ein Lab enthält keinerlei sensitiven oder in sonstiger Art interessanten Informationen. Würde es kompromittiert werden, so löscht man es komplett und setzt es neu auf.
Ich würde übrigens wetten, dass in den meisten Lab-Umgebungen das Kennwort VMware1! als Standard verwendet wird. 😉
Firewall
Auch in Bezug auf die Zugangsbeschränkung gilt wieder das KISS Prinzip. Wir erlauben im Lab alle Zugriffe von überall. Es geht schließlich um die Machbarkeit und nicht um Sicherheit (es sei denn man testet eine Firewall).
In realen Projekten kann die Firewall zur echten Herausforderung werden. Ein einziger Port zwischen zwei VLANs, der versehentlich nicht freigegeben wurde, kann ganze Deployments in die Knie zwingen. Es folgt dann ein längeres Troubleshooting bis die Quelle letztlich gefunden wurde.
Zertifikate
Im Lab sind sogenannte Self-Signed Zertifikate vollkommen ausreichend. Die Warnung im Browser stören nicht und eine man-in-the-middle Attacke ist nicht zu befürchten.
In der wirklichen Welt sieht dies komplett anders aus. Dort müssen vertrauenswürdige Zertifizierungsstellen (CA) des Unternehmens mit eingebunden werden. Manche CA Lösungen unterstützen keine Certificate Signing Requests (CSR). Generierte Zertifikate müssen dann im jeweils passenden Format exportiert und wieder importiert werden. Ein lustiges Spiel.
Redundanz
Ein singulärer Uplink oder ein einzelner Pfad zur Storage ist für einen Test in der Regel vollkommen ausreichend. Wieder das KISS Prinzip. Wozu Uplink Redundanz, wenn ich ohnehin nur einen Switch zur Verfügung habe?
In Produktivumgebungen ist Redundanz ein absolutes Muss. Es darf keinen Single Point of Failure geben (SPOF). Dafür sind redundante Komponenten in jeder Schicht unabdingbar. Das gilt für Daten, Hardware-Komponenten, Stromversorgung, Kühlung, Multipathing für Datenpfade und Netzverbindungen etc. Diese Anforderung erhöht zwangsläufig die Komplexität eines Systems.
Nachgeschaltet bringt diese Komplexität weitere Herausforderungen mit sich. Im SAN Bereich sind dafür redundate Speichernetzwerke (Fabrics) notwendig. Im LAN müssen Aspekte wie zum Beispiel Spine-Leaf Architektur, Link Aggregate, Spanning Tree Protokoll oder Routing berücksichtigt werden.
AMPRS
Verfügbarkeit oder Uptime hängt eng mit der zuvor besprochenen Redundanz zusammen. Im Lab ist das Thema völlig unbedeutend. Die Anlage wird zum Test hochgefahren und wenn es ein technisches Problem gibt wird sie für unbestimmte Zeit abgeschaltet und repariert.
In Produktivsystemen gilt das RAMPS bzw. AMPRS als Grundlage für das konzeptionelle Design. Das Akronym steht für:
- Availability
- Manageability
- Performance
- Recoverability
- Security
Alle fünf konzeptionellen Planungsaspekte spielen im durchnittlichen Lab keine, oder zumindest eine untergeordnete Rolle.
Not supported
Im Lab habe ich viele Freiheiten. Prinzipiell ist alles erlaubt, was irgendwie funktioniert. Ich kann Hardware-Komponenten verwenden, die nicht auf der VMware HCL stehen. Zum Beispiel eine günstige SSD als vSAN Cache Device. Das ist im Lab unproblematisch, da verminderter Durchsatz, oder kürzere Lebenzeit kein echtes Problem darstellen.
In Produktivumgebungen sind dies kritische Designaspekte. Ich muss mich nicht nur streng an die HCL halten, sondern auch so vorausschauend planen, dass die neue Infrastruktur auch die geforderte Leistung erbringt.
Das Lab als Wegbereiter des Projekts
Auch wenn im Labor Wege stark verkürzt und Anforderungen maximal vereinfacht werden, so ist es dennoch ein wichtiges Hilsmittel für Machbarkeitsstudien (engl. proof of concept, PoC). Potenzielle Stolperfallen können so schon frühzeitig erkannt und Ausweichlösungen gefunden werden.
Auch Blogposts sind eine wertvolle Quelle bei der Problemlösung und helfen uns, aus den Erfahrungen anderer zu lernen.
Ein guter Ansatz ist die Verwendung von Informationen aus Blogs als Basis für eigene PoC im Lab. Mit den daraus gewonnenen Erkenntnissen und Erfahrungen ist man gut vorbereitet auf spezielle Fragestellungen realer Projekte.