Das CoCo-Testlab – eine Spielwiese für unsere Berater

Wir haben bei ComConsult schon immer über Wege und Möglichkeiten verfügt, Technologien zu testen, doch waren es ausschließlich viele kleine bis mittelgroße Insellösungen. Solange sich jemand mit dem jeweiligen Thema auseinandersetzen wollte (oder musste), wurden diese Inseln gehegt und gepflegt. Wenn ein Thema schließlich jedoch beherrscht war oder aus Zeitgründen in den Hintergrund trat, verwaisten auch häufig die Test-Umgebungen. Verlässt ein (oder DER) Mitarbeiter mit Kenntnis über die Umgebung dann das Unternehmen, existiert die Umgebung ungepflegt oder unbekannt weiter. Im schlimmsten Fall laufen Server, die jahrelang nicht aktualisiert wurden und zusätzlich noch Strom fressen.

Den Insellösungen kann man nur mit einer zentral verwalteten und ausreichend groß dimensionierten Umgebung entgegentreten. Das Interessante in diesem Fall: Die Test-Umgebung ist explizit (ebenfalls) dazu da, Dinge auszuprobieren und gegebenenfalls auch mal kaputtzumachen. Daher wollten wir sie von unseren produktiven Systemen trennen. Und geboren war die Idee unseres Testlabors.

Doch damit diese auch ein Erfolg wird, muss man sie richtig planen. Und wie bei jeder Planung sollten die Anforderungen der User die Basis für die Dimensionierung und die Architektur sein.

Die Anforderungen an unser Testlabor

Für die Anforderungen wurden verschiedene Punkte berücksichtigt:

• Die Dimensionierung der schon vorhandenen Insellösungen:
  Egal, wie bescheiden die Benutzer ihre Anforderungen einschätzen: Die Ressourcen sollten auf jeden Fall ausreichen, um alle schon vorhandenen Test-Umgebungen zu übernehmen. Und dann muss natürlich noch Luft nach oben sein.
• Es werden potentielle User gesucht und diese nach ihren Anforderungen und auch Wünschen gefragt:
  Dabei können die Anforderungen sehr unterschiedlich formuliert sein. Von sehr groben Aussagen zu gewünschtem Use Case und der eingesetzten Software bis hin zu genauen Stücklisten der benötigten virtuellen Maschinen war bei uns alles dabei. Hier waren auch ein wenig Recherche und interne Beratung notwendig, um alle User abzuholen.
• Die Anforderungen der verschiedenen zur Verfügung stehenden Lösungen:
  Je nach eingesetzter Gesamtlösung für den Betrieb kann auch hier ein sehr unterschiedlicher Ressourcenbedarf entstehen. Dieser muss natürlich noch zusätzlich zu allen anderen Ressourcen-Anforderungen hinzugerechnet werden.

Die betrieblichen Anforderungen sind ebenfalls nicht zu unterschätzen. Sowohl Hard- als auch Software sollten vernünftig geplant werden:

• Auf Hardware-Seite sind auf jeden Fall ausreichende Redundanzen zu planen. Für das Testlabor gibt es keine 24-Stunden-Bereitschaft und auch keine SLAs. Trotzdem möchte man den Nutzern eine ausreichend verfügbare Umgebung zur Verfügung stellen. Also plant man genügend Redundanzen auf verschiedenen Ebenen ein, z. B. Netzwerk und Storage.
• Auf Software-Ebene wird eine Komplettlösung angestrebt, die aus einer Oberfläche heraus möglichst viele Funktionen einfach zugänglich macht.

Eine weitere Anforderung, gerade in einer Umgebung mit vielen Usern und viel Platz für Fehler: Eine Rollen-basierte Zugriffssteuerung, mit der man Nutzer und deren virtuelle Maschinen voneinander trennen kann. Es muss also mehr als einen User und nur die Berechtigung „jeder User darf alles“ geben.

Auf dieser Basis geht es dann in die weitere Detailplanung. Dabei stellen sich die folgenden Fragen:

• Wie realisieren wir den Storage?
• Wie vernetzen wir die Systeme?
• Ausgehend von den Antworten auf die vorherigen Fragen: Welche Hardware setzen wir ein und wie beschaffen wir sie?

Jede dieser Fragen wird im Folgenden für das Testlabor beantwortet.

Der Storage für die Umgebung

Ein wichtiger Aspekt ist die Datenhaltung für das Testlabor. Die virtuellen Maschinen der Nutzer müssen irgendwo abgelegt werden. Und auch hier benötigt man eine ausreichende Redundanz, damit das Testlabor kleinere und größere Ausfälle verkraften kann, ohne dass Daten verlorengehen.

Dabei hat man mehrere Möglichkeiten. Es läuft grundsätzlich auf eine von zwei Basis-Technologien hinaus:

• Zentralisierter Storage:
  Egal ob Fibre Channel, iSCSI, NFS oder SMB, ein zentraler Storage mit ausreichender Platten- (oder SSD-)Kapazität, auf den alle Systeme des Testlabors zugreifen können, bietet bei der Administration eine einzelne Anlaufstelle und lässt sich kompakt realisieren. Erweiterungen sind durch zusätzliche Medien möglich. Dennoch: Es ist und bleibt ein zusätzliches System, welches Platz braucht und Geld kostet. Möchte man einen Single-Point-of-Failure vermeiden, muss man sogar zwei zentrale Storage-Systeme anschaffen und diese synchronisieren. Das ist elegant und performant, doch sehr kostenintensiv. Sollte natürlich schon ein zentraler Storage vorhanden sein, kann man eventuell einen Teil davon für die Test-Umgebung abzwacken. Jedoch wollten wir das Testlabor physisch vollständig von allen produktiven Systemen trennen. Daher haben wir uns für den zweiten Ansatz entschieden:
• Verteilter Storage:
  In einem verteilten Storage wird der Speicherplatz von allen beteiligten Systemen bereitgestellt. Dazu werden die Server mit zusätzlichen Speichermedien ausgestattet. Diese wiederum werden durch eine Software zu einem großen, gemeinsamen „Topf“ zusammengeschaltet, welcher frei konfigurierbare Redundanzmechanismen bietet. In einem solchen Szenario kann man jeder einzelnen virtuellen Maschine eigene Richtlinien mitgeben. Die Maschine ist eigentlich unwichtig? Dann gibt es keine Redundanz! Der Aufbau der Maschine kostet etliche Stunden Arbeit und man möchte sie auf gar keinen Fall verlieren? Also legt man eine Kopie dieser Maschine auf jedem der beteiligten Systeme ab!

In unserem Fall war die verteilte Storage-Lösung auch stark in das Management-Interface der Virtualisierungslösung integriert. Das macht den Administratoren das Leben wesentlich leichter. Damit war die Entscheidung gefallen.

Das Netzwerk für die Umgebung

Das Netzwerk des Testlabors ist ebenfalls überraschend komplex. Natürlich wäre es möglich, alle Netze und Funktionen über eine Handvoll Gigabit-Anschlüsse zu realisieren. Damit würde man allerdings an verschiedenen Stellen Schwierigkeiten geradezu herbeiführen:

• Teilen sich alle Dienste und virtuelle Maschinen einige wenige Interfaces, können sie sich alle gegenseitig beeinflussen. Das wird einerseits dazu führen, dass die Nutzer sich über die schlechte Performance beschweren, und andererseits die Ursachenforschung bei größeren Störungen deutlich kompliziert gemacht wird. Dass man damit komplett von den Best Practices aller gängigen Lösungen abweicht, macht es auch nicht besser.
• Hinzu kommt die Sicherheit: Trennt man die Netze nicht sauber voneinander, ist auch jenseits von Störungen (in IT-Security-Sprache: Beeinträchtigung des Schutzziels Verfügbarkeit) eine Kompromittierung der Umgebung wahrscheinlicher. Zwar sollte alles geprüft und nur intern oder per VPN nutzbar sein, doch wenn man seine Test-Images (z. B. für Container) aus der falschen Quelle bezieht…

Aus diesem Grund haben wir die Netze, sofern es die Hardware zulässt, voneinander getrennt. Dabei haben wir jedem Server zwei 10 Gigabit-Ethernet- und zwei 1 Gigabit-Ethernet-Ports gegönnt. Aufgrund der hohen Anforderungen bzgl. des Storage-Traffics und der Migration von virtuellen Maschinen von einem Host zum anderen sind diese beiden Netze über die 10-Gigabit-Ports verbunden. Um Seiteneffekte auf den Rest des Testlabor s auszuschließen, ist hierfür ein dedizierter Switch im Einsatz, der im Zweifelsfall zudem noch Anschlüsse für weitere Systeme bietet. Getrennt sind diese Netze auf VLAN-Ebene. Es ist zwar dadurch möglich, dass es bei einer Migration von virtuellen Maschinen zu einer verringerten Performance im Storage-Bereich kommt, allerdings werden Maschinen nur selten verschoben. Hauptsächlich muss man damit im Rahmen der Wartung (s.u.) rechnen. Und dann sind „nur“ die Administratoren betroffen, die sich darüber im Klaren sind und die Wartung entsprechend planen.

Hier kann man sich natürlich fragen, ob die Nutzung eines verteilten Storage eine Auswirkung auf das Netzwerk-Design hat. Die Antwort ist: nicht wirklich!

Wie oben bereits beschrieben: Im Bereich der Bandbreite ändert sich gegenüber einem zentralen Storage nichts. Und ein eigenes – logisch getrenntes – Storage-Netz sollte man sowieso haben.

Management- und VM-Netze sind über die Gigabit-Ports angebunden und ebenfalls auf VLAN-Ebene voneinander getrennt. Der Management-Traffic ist nicht besonders umfangreich, und auch die virtuellen Maschinen kommunizieren – aktuell noch – nicht allzu intensiv untereinander. Sollten sich hier Engpässe abzeichnen, ist eine Erweiterung relativ leicht möglich.

Aktuell kommt innerhalb des Testlabors (noch) kein Software-Defined Networking (SDN) zum Einsatz. Gerade bei der Verwaltung der Netze bleibt damit mehr Arbeit an den Administratoren hängen, doch macht es den Einstieg etwas einfacher. Insbesondere für diejenigen Nutzer, die zusätzlich mit externen Komponenten wie Switches oder sonstigen Appliances kommunizieren müssen, würde sich einiges ändern. Das heißt nicht, dass wir niemals SDN einsetzen werden.

Beschaffung und Aufbau der Hardware

Mit all den gesammelten Informationen war es dann möglich, die Systeme zu dimensionieren. Bezüglich der Hardware stellte sich noch eine weitere Frage: Kaufen wir fertige Server oder bauen wir sie selbst zusammen? In einer Test-Umgebung ist beides denkbar. Fertig-Systeme sorgen dafür, dass die Gesamtumgebung schneller aufgebaut ist und gegebenenfalls defekte Hardware vom Server-Hersteller ersetzt wird.
Systeme Marke Eigenbau bieten nicht annähernd so viel Komfort. Dafür sind sie wesentlich günstiger und können genauer an die eigenen Wünsche angepasst werden. Vorausgesetzt, man hat das nötige Personal, um die Systeme zusammenzuschrauben.

Wir bei der ComConsult haben uns für den Eigenbau entschieden. Es war eine interessante Aufgabe für unsere Azubis, die Server zusammenzubauen, bei der man zudem viel über moderne Server-Systeme lernen konnte.

Mit Lieferung der Hardware und einem einigermaßen gut ausgearbeiteten Plan gelangen Aufbau und initiale Konfiguration relativ problemlos. Natürlich galt auch hier: Kein Plan überlebt den ersten Feindkontakt. Dennoch: Wir haben wieder einiges gelernt. Als dann alles lief, auch die ersten virtuellen Systeme, begann die wichtigste Aufgabe: Der reibungslose und nutzerfreundliche Betrieb.

Eine schematische Darstellung der Systeme und Netze findet sich in Abbildung 1.

Die Umgebung im Alltagsbetrieb

Aus Sicht der User gibt es mit dem Betrieb des neuen Testlabors mehr verwaltungstechnischen Aufwand. Alle Veränderungen ihrer eigenen Testnetze müssen mithilfe von Formularen in einem eigens dafür eingerichteten Microsoft-Team beantragt werden. Dies fängt bereits mit dem Account an, für den die User im entsprechenden Formular nicht nur die EULA (End-User License Agreement) akzeptieren müssen, sondern direkt auch verschiedene Berechtigungen beantragen können. In der EULA selbst sind alle Rechte und Pflichten der User und Administratoren vermerkt, und die EULA klärt außerdem über die möglichen Konsequenzen bei Missachtung auf.

Die erhaltenen Berechtigungen können bei Bedarf über ein weiteres Formular immer noch nachträglich angepasst werden, falls ein User im späteren Verlauf in einem anderen Testnetzwerk mitbasteln soll. Wenn neue virtuelle Maschinen erstellt werden sollen oder bestehende angepasst werden müssen, gibt es hierfür auch die passenden Formulare. In diesen Anträgen können die User des Weiteren neue Netzwerke anfordern. Für die benötigten Ressourcen der verschiedenen virtuellen Maschinen wird eine Tabelle angezeigt, die verschiedene Zusammensetzungen der Ressourcen gemeinsam mit Anwendungsbeispielen aufweist. Im Gegensatz zu früheren Testsystemen ist die Verbindung zum neuen Testlabor über VPN möglich. Zuvor konnte man die eigenen Testnetze ausschließlich im Büro erreichen, da die Netzwerke in den entsprechenden Büroräumen gepatcht wurden. Jetzt können die User, solange sie Internetzugriff besitzen, jederzeit einen VPN-Tunnel in ihre Testnetze aufbauen, wodurch sie deutlich flexibler für die praktische Weiterbildung geworden sind. Alle benötigten Zugangsdaten und Einstellungen erhalten die User bei persönlichen Accounts entweder direkt von den Administratoren oder finden diese in diversen KeePass-Dateien für die Accounts der virtuellen Maschinen.

Für die Administratoren hat sich durch die Einführung des Testlabors auch einiges verändert. Primär gibt es im IT-Labor, dem Raum, in dem alles aufgebaut ist, keinen „wilden Westen“ mehr, da alles über Anträge und das neue Testlabor läuft. Sobald der User einen solchen Antrag abgeschickt hat, wird automatisch in einem weiteren, nur für die Administratoren vorgesehenen Microsoft-Team eine Aufgabe generiert und der hausinterne IT-Support benachrichtigt. Bei neuen Usern wird zunächst der Account auf dem Testlabor erstellt und eine VPN-Verbindung für diesen Nutzer in das Management-Netz zur Verfügung gestellt. Je nach Bedarf werden zu dem Zeitpunkt auch die VPN-Verbindungen für weitere persönliche Testnetzwerke konfiguriert. Jedoch hat nicht jedes Testnetzwerk einen eigenen VPN-Server, sondern diese wurden in verschiedenen Gruppen zusammengeschlossen.

Das Grundgerüst der diversen Berechtigungen auf dem Testlabor ist so aufgebaut, dass jeder User in einer sogenannten Catch-all-Gruppe aufgefangen wird, welche den Zugriff auf alle virtuellen Maschinen usw. verbietet. Durch einzelne Gruppen werden die Nutzungsrechte auf einzelne Ordner freigegeben. In diesen Ordnern sind dann die entsprechenden virtuellen Maschinen hinterlegt. Es sind also zum Beispiel alle virtuellen Maschinen aus dem Competence Center Netze in dem Ordner „Netze“ zu finden, worauf ausschließlich die Gruppe namens „Netze“ Benutzer-Rechte besitzen. Die Benutzer-Rechte beinhalten dabei die Berechtigungen für das Starten und Stoppen der virtuellen Maschinen, sowie die Nutzung der Webkonsole.

Die weiteren Arbeiten der Administratoren für die Nutzer gestalten sich auf technischer Ebene relativ einfach: Das Erstellen von neuen virtuellen Maschinen erfolgt mit wenigen Klicks, und es können sogar ganze Images direkt eingespielt werden. Diese werden zuerst auf die Umgebung hochgeladen und dann in die virtuelle Maschine eingespielt, oder eine virtuelle Maschine wird direkt aus den Images erstellt. Für Standard-VMs existieren sogar bereits vorkonfigurierte Images in der Umgebung, die man bei Bedarf direkt klonen kann. Zum Schluss wird noch ein Snapshot als Clean-Install erzeugt und die Zugangsdaten in der entsprechenden KeePass-Datei und in einer separaten Übersicht dokumentiert, und schon kann der User seine Pläne umsetzen. Das Erzeugen von weiteren Snapshots oder das Wiederherstellen geschieht auf einem kürzeren Dienstweg, und zwar in Form einer kurzen Benachrichtigung im Microsoft-Team Testlabor.

Da es sich bei dem Testlabor um vier Server handelt, ist die Wartung etwas umfangreicher, wodurch es auch zu Ausfällen im gesamten Testlabor-Netzwerk kommen kann. Zu Beginn werden die einzelnen Server nacheinander einzeln in den Wartungsmodus versetzt und die Updates eingespielt. Sobald ein Server aktualisiert ist, wird er wieder in den Verbund aufgenommen, und das Prozedere wird mit dem nächsten Server durchgespielt. Darauf folgt das Updaten der Management-Umgebung, und zum Schluss muss eventuell auch ein Update für den verteilten Storage eingespielt werden. Letzteres ist allerdings nur nötig, wenn es größere Änderungen gibt, sprich ein Upgrade der Umgebung durchgeführt wurde. Das Updaten der Server und der Umgebung ist mit wenigen Klicks geschafft und benötigt lediglich einiges an Zeit für die Installation. Das liegt vor allem daran, dass jeder Server, bevor er aktualisiert wird, alle vorhandenen Daten so an die anderen Systeme verteilt, dass auch während des Updates die Daten redundant auf den anderen Servern vorhanden sind. Ob sich das auch dann beibehalten lässt, wenn die Datenmenge weiter zunimmt, wird sich zeigen. In der Regel nimmt die Wartung inkl. Updates einen halben Tag in Anspruch, wobei man währenddessen ohne Probleme auch andere Aufgaben erledigen kann. In der Theorie ist das Updaten des verteilten Storage sehr einfach gestaltet und kann mit wenigen Klicks bewältigt werden. Tatsächlich durchgeführt wurde es bislang noch nicht. Die Administratoren werden auf jeden Fall benachrichtigt, sobald Updates zur Verfügung stehen. Einmal im Monat, spätestens alle zwei Monate, wird eine Wartung durchgeführt und die User frühzeitig im Team Testlabor benachrichtigt. Selbst wenn keine Updates anstehen, werden während der Wartung zumindest die virtuellen Maschinen einmal heruntergefahren und eventuelle Anpassungen vorgenommen.

Die Dokumentation geschieht auf verschiedenen Ebenen. Für die einzelnen virtuellen Maschinen müssen die User selbst eine Dokumentation erstellen und an einem vorgegebenen Ort ablegen, worauf auch die Administratoren jederzeit zugreifen können. Es gibt diverse Tabellen als Übersicht für das User-Management und die virtuellen Maschinen, die von den Administratoren ausgearbeitet werden. Anhand der Tabelle für das User-Management ist auf einen Blick ersichtlich, welcher User in welcher Gruppe ist bzw. welche Berechtigungen besitzt, sei es für die Umgebung oder für die diversen VPN-Verbindungen. Die Übersicht für die virtuellen Maschinen beinhaltet neben den zugeteilten Ressourcen auch Informationen über die Nutzungsdauer oder wer sie beantragt hat. In regelmäßigen Abständen wird manuell geprüft, ob eine virtuelle Maschine kurz vor Löschung steht. Ansonsten gibt es neben einem Netzplan für den Aufbau des gesamten Testlabor-Netzes noch die automatisch erstellte Dokumentation für jedes abgeschickte Formular und diverse Anleitungen für die User und Administratoren.

Wir können viel dazu schreiben, was wir uns überlegt haben und wie wir die Umgebung betreiben – sie steht und fällt mit der Zufriedenheit der Nutzer. Wie sieht es hier aktuell aus?

Aktueller Status – Nutzerakzeptanz

Derzeit haben wir 20 User, die mit unserem Testlabor arbeiten. Vier Mitarbeiter haben sich für ein kurzes Interview zur Verfügung gestellt. Einer ist Frederik Stückemann, der im Competence Center Funknetze arbeitet und im Testlabor ein Testnetz für Long Range Wide Area Network (LoRaWAN) besitzt, um Gateways und Sensorik testen zu können. Zusätzlich konnten wir auch noch Sara Mohd Shafek befragen, die als studentische Hilfskraft nicht nur im LoRaWAN-Testnetz verschiedene Szenarien testet, sondern auch für das Competence Center IT-Sicherheit den verschiedenen Konfigurationen von Nanolog Streaming Service (NSS), Apache und diversen anderen Applikationen auf den Zahn fühlt. Des Weiteren gelang es uns, Michael Schneiders für ein Feedback-Gespräch zu gewinnen, der dem Competence Center Netze angehört und sich mit der Planung, Implementierung und dem Aufbau von lokalen Netzen und WLANs befasst. Last, but not least hat Dr. Markus Ermes für die Competence Center Cloud- und Datacenter bzw. IT-Security seine Meinung kundgetan. Er war nicht nur von Anfang an bei dem Projekt Testlabor dabei, sondern hat sich primär mit Kubernetes, Netzwerk-Sicherheit, Schwachstellenscannern etc. befasst.

Feedback – Frederik Stückemann

Aktuell laufen zwei virtuelle Maschinen im Testlabor. Eine dieser virtuellen Maschinen ist ein LoRaWAN-Netzwerk- und Application-Server mit der Open-Source-Software Chirpstake. Dieser Server kümmert sich um den Empfang und die Verarbeitung von den Paketen, welche von den LoRaWAN-Sensoren an den Server verschickt werden. Die andere virtuelle Maschine kümmert sich um die Speicherung dieser Pakete in einer Datenbank, welche über die Open-Source-Software Grafana grafisch dargestellt werden.

Die Erfahrungen mit dem Testlabor sind bislang sehr gut. Das System läuft einwandfrei. Da es sich dabei um virtuelle Maschinen handelt, können wir ein wenig damit rumspielen und einige Dinge ausprobieren. Wenn man vorher einen Snapshot gemacht hat, kann man ohne Probleme ein Rollback durchführen, falls man sich die Konfiguration komplett zerschossen hat. Man hat dadurch immer die Möglichkeit, noch mal von vorne anzufangen und ohne größere Konsequenzen etwas zu lernen, auch wenn dies beinhaltet, dass es so nicht funktioniert. Sonst habe ich mit dem System keine Probleme. Die virtuellen Maschinen laufen 24/7 durch, speichern unsere LoRaWAN-Pakete sehr zuverlässig weg, und wir können diese Pakete mit der Virtualisierungssoftware immer gut anzeigen lassen. Die Erstellung einer eigenen virtuellen Test-Umgebung mit den virtuellen Maschinen ist auf jeden Fall tausendmal besser als die Raspberry-Pis, mit denen wir vorher das System in Betrieb hatten.

Feedback – Sara Mohd Shafek

Für den Bereich IT-Sicherheit laufen mehrere virtuelle Maschinen im Testlabor. Die genaue Anzahl verändert sich ständig. Zur Grundausstattung gehört immer ein Domain Name System (DNS), ein Apache-Webserver sowie virtuelle Maschinen für verschiedene Cloud-Konnektoren, ein Security Information and Event Management (SIEM), ein Public Service Edge und Windows-Testclients. Oftmals lassen wir ein Image einspielen, um es auf verschiedenen Konfigurationen zu testen, damit wir anschließend den Kunden besser in dem Bereich beraten können. Bislang läuft alles sehr gut, obwohl ich am Anfang ein wenig Angst vor dem organisatorischen Aufwand hatte. Vorher hatten wir unser eigenes Testlabor, und dort konnte ich einfach nach Belieben eine neue virtuelle Maschine erstellen. Jetzt dauert es zwar zwei bis drei Tage, doch es geht trotzdem sehr schnell und ist sehr gut organisiert. Sollte es dennoch sehr dringend sein, kann ich die Administratorin ohne Probleme kurz benachrichtigen, und sie versucht, die Erstellung einer virtuellen Maschine so schnell wie möglich umzusetzen. Das ist vor allen Dingen dann der Fall, wenn ich bei der Konfiguration der Linux-Maschinen Fehler mache oder die Konfiguration nicht den gewünschten Effekt hat. Gerade in den Fällen würde ich am liebsten die virtuelle Maschine löschen und noch mal bei null anfangen, da manchmal selbst mit einem Neuanfang immer noch einige Konfigurationen oder Files übrigbleiben. Ich kann auch schlecht mehrmals am Tag die Administratorin um eine neue virtuelle Maschine bitten, da diese sich schließlich auch um andere Aufgaben kümmern muss, die nicht das Testlabor betreffen. Das Gute ist, dass ich gezwungenermaßen das Troubleshooting besser lerne. Zudem gefällt es mir, dass das System regelmäßig gewartet wird, ohne dass ich selbst einen Handschlag machen muss und die Ankündigungen frühzeitig rausgeschickt werden. Man kann sich so sehr gut auf die Downtime der Server einstellen und an dem Tag andere Arbeiten erledigen.

Feedback – Michael Schneiders

Im Testlabor nutze ich hauptsächlich EveNG und einen virtualisierten WLAN-Controller. EveNG ist ein System zur Emulation von Netzwerkkomponenten. Ich kann mit dem Tool Switches, Router und Firewalls simulieren und somit Demonetzwerke für unsere Seminare im Bereich Netze erstellen. Diese Demonetzwerke werden dazu genutzt, den Teilnehmern zu zeigen, wie Routing, IPv6 und ähnliche Dinge funktionieren. Ich baue solche Labore auch, um technische Sachverhalte besser verstehen zu können und mich somit stetig weiterzubilden. Mit dem WLAN-Controller teste ich derzeit das 6GHz WiFi. Im Büro habe ich einen physischen Access Point stehen, der mit dem virtuellen WLAN-Controller assoziiert ist. Ich kann darüber im 6 GHz WiFi diverse Tests durchführen und so die neue Technologie besser kennenlernen.

Insgesamt läuft das Testlabor ausgesprochen gut. Es läuft alles sehr stabil, und Systemressourcen sind offenbar in ausreichender Größe vorhanden, sodass es keine Probleme gibt. Das Bereitstellen neuer virtueller Maschinen funktioniert einfach und schnell. Ich finde jedoch, dass die Verbindung in die jeweiligen Netzwerke umständlich ist. Es ist wichtig, dass man zum Beispiel ein VPN nutzen muss, um sich sicher mit dem Testlabor verbinden zu können, doch erfordert dies derzeit die Installation eines separaten Clients auf meinem Rechner und lässt sich nicht mit Windows-Bordmitteln realisieren. Dazu kommt, dass man überall noch weitere Credentials abspeichern muss. Heutzutage ist man mit Single-Sign-on ziemlich verwöhnt, und derzeit muss man sich für die Nutzung der Test-Umgebung die passenden Credentials aus diversen KeePass-Dateien raussuchen. Man könnte vielleicht über die Einführung eines RADIUS-Servers (Remote Authentication Dial-In User Service) nachdenken, den man ebenfalls im Testlabor installieren kann. Darüber hätte man die Möglichkeit, die administrativen Zugriffe auf die Komponenten und das Testlabor zu automatisieren und zu vereinfachen.

Feedback – Markus Ermes

Als Initiator der Umgebung und Co-Autor dieses Artikels möchte auch ich noch Feedback zum Testlabor loswerden. Ich selbst verwende es sowohl für den Know-how-Aufbau als auch für Seminar-Demonstrationen, und zwar in zwei Bereichen: Data Center und IT-Security. Als jemand, der sowohl als Nutzer Zugriff auf das Testlabor hat und auch als Verantwortlicher für die Anträge angegeben ist, ist die Bearbeitungszeit für meine eigenen Anträge natürlich begrenzt.

Ich selbst profitiere ebenfalls sehr stark von der guten Organisation und dem strukturierten Betrieb. Da, wo ich früher auf einzelnen Systemen Bastellösungen realisiert habe und schnell in Ressourcen-Engpässe gelaufen bin, bin ich jetzt wesentlich flexibler. Und die organisatorischen Vorgaben des Testlabors halten mich dazu an, alle Arbeitsschritte und Zugangsdaten zu dokumentieren, sodass im Zweifelsfall auch jemand anderes meine virtuellen Maschinen übernehmen kann.

Was die Leistung angeht, bin ich sehr zufrieden mit dem Testlabor. Es wird interessant zu beobachten, wie es sich entwickelt, wenn zusätzliche Funktionen wie Kubernetes oder Software-Defined Networking hinzukommen.

Beim Zugriff auf das Testlabor muss ich meinem Kollegen Michael Schneiders teilweise recht geben. Die Installation eines eigenen VPN-Clients ist etwas lästig, und ein zentrales User-Management wäre sicher an der einen oder anderen Stelle angenehm. Auf der anderen Seite müssten die Nutzer dann wohl auch mit einem deutlich strengeren User-Management rechnen. Der Komfort würde demnach zunehmen, doch die Flexibilität innerhalb der virtuellen Maschinen wäre mehr eingeschränkt.

Aktueller Status – Zusammenfassung

Zusammenfassend haben wir im Testlabor eine bunte Mischung an verschiedenen virtuellen Maschinen. Von der Simulation von Netzwerkkomponenten über die Verwaltung von Sensorik-Daten bis hin zu NSS und SIEM sowie Verbindungen zu physischen Komponenten wie einem Access Point ist alles dabei. Mit dem Testlabor ist der Kreativität fast keine Grenze gesetzt, und wir können ihr mit Sicherheit noch beibringen, für uns Kaffee zu kochen. Das Feedback von den Usern ist bei so einem Projekt ebenfalls wichtig, damit sich dieses lebende System ständig weiterentwickeln kann. Über die Einführung eines RADIUS-Servers oder eines Active Directory kann man auf jeden Fall nachdenken, und das Erteilen von den Rechten für das Erstellen von Snapshots sowie die Alternative der VPN-Verbindung erscheint auf den ersten Blick auch als sinnvoll. Die Rückmeldung der User ist durchweg positiv, und mit dem Umsetzen einiger Verbesserungsvorschläge wird das Testlabor stetig besser.

Doch auch jenseits des Betriebs ist die Umgebung noch erweiterbar. Und es ist schon einiges geplant…

Aktuell in Arbeit befindliche Erweiterungen

Nach knapp einem Jahr und einem virtuellen-Maschinen-Counter von 73 mit entsprechendem Feedback seitens der User wurde schnell deutlich, an welchen Schrauben noch gezogen werden muss. Bei manchen Projekten war zu Beginn schon klar, dass diese in den nächsten Jahren eingeführt werden würden, primär zum Lernen für unsere Auszubildenden. Andere Dinge kamen mit der Zeit dazu und werden auch zeitkritischer behandelt. Die Rede ist hier tatsächlich von den verfügbaren Ressourcen. Ende letzten Jahres ist uns aufgefallen, dass uns die Aufteilung der Ressourcen bei der Planung nicht optimal gelungen ist. Wir hatten zu dem Zeitpunkt eine Auslastung von jeweils ca. 10-15 % bei der CPU und bei dem Festplattenspeicher, wohingegen der Arbeitsspeicher schon bei 60 % lag. Mit der Ankündigung einer XXL-VM aus unserem Netzwerk-Team, die im Laufe dieses Jahres benötigt wird, wird das Ganze sogar noch zeitkritischer. Der entsprechende neue Arbeitsspeicher ist schon vorhanden, man muss nur noch ein geeignetes Zeitfenster finden, um die Arbeitsspeicher in die Server einzubauen. Wenn der Umbau vollzogen ist, dann besitzt das Testlabor statt 512 GB Arbeitsspeicher sage und schreibe 1280 GB. Damit sollten wir auf jeden Fall noch eine Weile hinkommen, und zur Not können wir diese immer noch erweitern.

Das nächste Projekt ist tatsächlich ein Monitoring-System, welches von unserem Auszubildenden im Zuge seines Abschlussprojektes implementiert wird. Primär soll es da um das Überwachen des jeweiligen Update-Status der virtuellen Maschinen und auch deren Ressourcen-Nutzung gehen. Was dabei am Ende rauskommt, werden wir dann Mitte Mai sehen. Nächstes Jahr erfolgt wahrscheinlich anknüpfend an das Monitoring-System die Einführung eines SIEMs. Wenn das Wachstum des Testlabors so weitergeht wie bisher, wird dies definitiv nötig sein und die jüngere Generation hat die Chance, sich mit dem Thema im kleinen Stil zu befassen, bevor sie auf die Kunden losgelassen wird. Genügend Know-how ist durch die ältere Generation in der Firma vorhanden. Es muss nur noch weitergegeben und umgesetzt werden.

Im Zuge einer IP-Adressen-Umstrukturierung unseres Testnetzes im Allgemeinen wird im Laufe des Jahres auch die Umstellung des VPN-Zugriffes in Angriff genommen. Seitens der User und auch des hausinternen IT-Supports kam der Wunsch auf, die VPN-Verbindung mit Windows-Bordmitteln herzustellen. Die Lösung dafür ist bereits vorhanden. Mit der Umstellung warten wir auf einen anderen Auszubildenden, der sich derzeit mit den verschiedenen Möglichkeiten für DHCP auseinandersetzt. Dazu kommt noch die Einführung eines Software-Defined Network (SDN), wodurch wir das Netzwerk unseres Testlabors besser managen können. Vor einigen Jahren hatten wir bereits Interesse an dem Thema, und jetzt haben wir nicht nur die Möglichkeiten, sondern auch einen Grund, das SDN endlich umzusetzen.

Allerdings ist der Einsatz einer SDN-Lösung nicht ganz einfach. Ja, auf Dauer kann SDN die Arbeit erleichtern, doch gibt es auch Seiteneffekte. Daher möchten wir alle notwendigen Aspekte beleuchten, bevor wir unsere Nutzer damit beglücken. Außerdem hat eine solche Lösung immer auch das Potential, zu größeren Störungen zu führen. Das gilt ganz besonders für die Installation und die ersten Tage bis Wochen, in denen die SDN-Lösung eingesetzt wird. Aus diesem Grund möchten wir uns im Vorfeld möglichst intensiv und gut darauf vorbereiten. Das betrifft insbesondere die folgenden Punkte:

• Wir möchten wissen, was alles bei der Einrichtung schiefgehen kann.
• Wir möchten die Menge der Fehler, die dann auftreten, minimieren.
• Wir möchten die User auf diese Reise mitnehmen, damit sie nicht auf einmal vor einer ganz anderen Netzwerk-Topologie und -Technologie stehen und nicht wissen, wie sie damit umgehen sollen.

Last, but not least ist die Einführung einer Kubernetes-Umgebung in Planung. Wann genau dies umgesetzt wird, steht noch nicht fest. Mit dieser Kubernetes-Umgebung decken wir die zunehmenden Optionen von containerbasierten Applikationen ab und können deren verschiedene Integrationsmöglichkeiten mit diversen anderen Tools ausprobieren. Es wird auf jeden Fall die Aufgaben der Administratoren vereinfachen und neue Möglichkeiten für unsere User schaffen.

Insgesamt haben wir also eine gute Ausgangsbasis, zufriedene Nutzer und Pläne für die Zukunft.

Fazit

Zusammengefasst war das ganze Projekt ein Abenteuer und eine Umstellung nicht nur für die User, sondern auch für die Administratoren. Selbst beim Zusammenbauen konnten alle Beteiligten in einer sicheren Umgebung Fehler machen und aus diesen lernen. Vom Azubi aus dem ersten Lehrjahr bis zum langjährigen Berater war ein breites Spektrum an Kompetenzen in das Projekt involviert, und jeder konnte die ein oder andere Lektion mitnehmen, auch wenn diese beinhaltete, dass Theorie und Praxis voneinander abwichen.

Die Migration bestehender Systeme sorgte für mehr Ordnung in den Räumlichkeiten des IT-Labors, auch wenn man manchmal den Wald vor lauter Bäumen nicht mehr sah. Das ist das Problem von Insellösungen, welches wir durch das neue Testlabor wieder sehr gut im Griff haben. Die Umstellung von do-it-yourself zu den geregelten Prozessen über die IT sorgt für eine dauerhafte Ordnung, welche manchmal immer noch etwas holprig ist. Das Abgewöhnen alter Gewohnheiten benötigt eben Zeit. Die zentrale Ressourcen-Verteilung vergrößert den Spielraum der User und senkt außerdem die Kosten, da nicht für jedes Projekt neue Hardware angeschafft werden muss. Mit den VPN-Zugängen sind alle Beteiligten flexibler in der Weiterbildung, und die Administratoren müssen auch nicht mehr im Büro sein, um ein neues VLAN konfigurieren zu können, Jump-Server sei Dank. Mit den aktuell geplanten und in Arbeit befindlichen Erweiterungen gibt es außerdem ein breites Spektrum an Projekten zum Know-how-Aufbau, und die generationsübergreifende Weitergabe des Wissens ist damit ebenfalls gesichert.

Und das Beste ist: Wir haben jetzt im Testlabor drei leere Serverschränke. Was stellen wir bloß mit so viel Platz an? Richtig, neue Hardware testen, die man in das Testlabor integrieren kann. Die IT entwickelt sich stetig weiter, und dieser Anforderung muss auch unser Testlabor gerecht werden. Die geplanten Erweiterungen werden somit auch nicht die letzten sein, und vielleicht bringen wir ihr doch noch das Kaffeekochen bei. Kaffee ist ja bekannterweise systemkritisch für Informatiker.