Was ist der orcharhino?

Am Anfang war nur ein Server. Der wurde gehegt und gepflegt. Aber das ist lange her. Heute steuern die Meister der Rechenzentren ihre unzähligen Hosts meist per Automatisierung – beispielsweise mit Foreman und Katello. Diese zwei Open-Source-Tools bilden den Kern des orcharhino, den die ATIX im Bundle mit einigen anderen Komponenten als Rechenzentrums-Rundum-Glücklich-Paket anbietet. Auch Red Hat leitet übrigens seinen Satellite seit Version 6 davon ab.

Der orcharhino übernimmt Installation, Konfigurationsverwaltung und Lifecycle Management Ihrer Server. RHEL und CentOS hat das Duo Foreman/Katello von Anfang an im Programm. Die ATIX-Entwickler haben das ausgebaut, sodass der orcharhino zusätzlich für SuSE Enterprise Linux sowie Debian und Ubuntu sorgt. Mittlerweile steht ein Großteil seiner Funktionen auch für Windows-Hosts zur Verfügung. Unsere Erweiterungen geben wir – ganz im Sinne von Open Source – natürlich zurück an die Community.

Entwicklung und Qualitätssicherung bei ATIX bereiten für alle erwähnten Plattformen passende Installationstemplates vor sowie Client-Software, die die Hosts mit dem orcharhino verbindet. Nutzer unterschiedlicher Plattformen erhalten somit im Endeffekt eine einheitliche Schnittstelle, die die verschiedenen technischen Ansätze gleichwertig anbietet. Aber auch für homogene IT-Landschaften eignet sich der orcharhino als herstellerunabhängige Verwaltungssoftware. Bei Problemen steht Kunden unsere Knowledge Base sowie das Support Team zur Verfügung.

Vorspann und Disclaimer

Drei (fiktive) Unternehmen teilen hier ihre Erfahrungen mit dem orcharhino. Wir skizzieren ihr jeweiliges Einsatzszenario und gehen auf besondere Aspekte in deren Serververwaltung ein. Die Infrastruktur unterscheidet sich in einigen Aspekten, die den Rahmenbedingungen und den persönlichen Vorlieben der Administratoren vor Ort geschuldet sind. Disclaimer: Keines dieser Unternehmen existiert tatsächlich und die Auswahl repräsentiert auch nicht den orcharhino-Nutzerstamm. In der Tat sollen sie lediglich einen Querschnitt der Anwendungsbereiche abbilden. Dennoch wollen wir sie hier kurz vorstellen:

1. Die Finesse Bank

Die Finesse Bank ist relativ jung und im FinTech-Bereich angesiedelt. Sie hat einen kleinen Endkundenbereich und stellt Apps zur Finanzverwaltung bereit, der größere Anteil betrifft die Vermögensverwaltung. Eine stabile Server-Infrastruktur ist eine zentrale Voraussetzung für ihr Geschäftsmodell. Die meisten Server stehen im zentralen Rechenzentrum, kleinere Remote Branches stehen in der Nähe wichtiger Börsen. Als Bank unterliegt sie der Aufsicht durch die BaFin und muss ihre Infrastruktur robust gestalten.

2. Value and Vision

Value and Vision bietet seinen Kunden (primär Ingenieursbüros) zentrale Services an, insbesondere die flexible Bereitstellung von Rechenkapazitäten und Server-Housing sowie -Management. Die weltweit verteilten Kunden haben auch Value and Vision expandieren lassen. Sie betreiben inzwischen mehrere kleinere Rechenzentren, die teilweise sehr streng voneinander separiert sind. Bei Value and Vision ist der Kunde König – deswegen möchte beispielsweise jeder sein eigenes Lieblingsbetriebssystem verwenden. Hosts werden ähnlich wie virtuelle Maschinen in der Regel einmal eingerichtet und für ein Projekt benutzt, bevor die Nutzer sie durch neuere Instanzen ersetzen (lassen).

3. Die Qualitätsuniversität

Die Qualitätsuniversität hat etwa 30.000 Studierende aus allen Fachbereichen. Diesen stehen etliche zentrale Dienste zur Verfügung. Die Naturwissenschaften und die Wirtschaftswissenschaften nutzen zudem einen lokalen Cluster für Simulationen und Modellberechnungen, der zentral bereitgestellt und verwaltet wird. Dank orcharhino hat die Qualitätsuniversität die Infrastrukturverwaltung quasi vollständig konsolidiert und vereinheitlicht.

Use Cases


Im folgenden sind eine Reihe von Use Cases beschrieben um Ihnen eine Vorstellung der Einsatzmöglichkeiten von orcharhino zu geben.

orcharhino als Installationsquelle

Hosts zu deployen gehört neben dem Konfigurationsmanagement und dem Lifecyle Management zu den Kernfunktionen des orcharhino. Er stellt verschiedene Wege bereit, neue Hosts während der Installation mit Informationen zu versorgen und menschliche Interaktionen überflüssig zu machen.

Value and Vision muss auf Kundenanfragen hin häufig neue Hosts, auch in größerer Zahl, bereitstellen. In der Regel handelt es sich dabei um virtuelle Maschinen, einzelne Kunden bevorzugen Bare-Metal-Server. In allen Fällen bereiten die V&V-Mitarbeiter den neuen Host in der Web-Oberfläche des orcharhino vor. Bei virtuellen Maschinen setzen sie beispielsweise deren Leistungsmerkmale (CPU, RAM, Netzwerk, Storage) fest. Natürlich wird auch festgelegt, in welchem Netz sich der Host befinden soll, damit die Kunden darauf Zugriff haben. Weitere Kriterien sind das Betriebssystem oder das verwendete Konfigurationsmanagement samt Rollen/Klassen/States. Value and Vision muss auf Fälle vorbereitet sein, weswegen sie Daten und Clients für fast alle Betriebssysteme vorhalten, die der orcharhino verwalten kann:

  • CentOS 6, 7 und 8
  • CloudLinux 7
  • Debian 9, 10
  • Oracle Linux 7 und 8
  • Red Hat Enterprise Linux (RHEL) 7 und 8
  • SuSE Linux Enterprise Server (SLES) 12 (SP3 und SP4) sowie 15 (inkl. SP1)
  • Ubuntu 16.04 LTS und 18.04 LTS

Linux-Hosts benötigen Kernel und initiale Ramdisk, die sie entweder per PXE-Boot von einem Boot-Image erhalten. Windows-Hosts können von einem speziellen minimalen Image booten. Danach greifen verschiedene Mechanismen, um das Betriebssystem automatisiert zu erstellen. Unter Linux haben sich Kickstart/Anaconda (Red-Hat-Familie), AutoYAST (SUSE) und Preseed (Debian-Familie) etabliert. In allen Fällen fragt ein Programm per HTTP die grundlegende Konfiguration ab. Die orcharhino-Admins haben zuvor Templates geschrieben, die jetzt aus den Konfigurationsparameters die Kickstart-, AutoYAST- oder Preseed-Definition erstellen. Das gerenderte Template enthält dann beispielsweise die Netzwerkkonfiguration des jeweiligen Hosts, Passwort-Hashes, eine grundlegende Paketauswahl und wie das Konfigurationsmanagement vorzubereiten ist.

Virtuelle Maschinen kann der orcharhino direkt starten, indem er die Hypervisor-API anspricht, die meisten Bare-Metal-Server startet der orcharhino per BMC (iLO/IPMI/iDRAC), nachdem ihre Netzwerkinterfaces am Switch ins richtige VLAN gehängt wurden. Alle Hosts (physisch und virtuell) hängen bei Value and Vision in mindestens zwei Netzen: ein produktives und ein Installationsnetz. Zu Beginn spielt lediglich das Installationsnetz eine Rolle. Darin fungieren der orcharhino bzw. seine orcharhino Proxies als DHCP-Server, zudem liefern sie per TFTP alle nötigen Dateien für PXE-Boot aus.

Nach einigen Minuten sind die neuen Hosts grundlegend eingerichtet und booten neu. Im Anschluss nimmt das zentrale Konfigurationsmanagement weitere Schritte vor und installiert noch weitere Software. Einige Kunden wollen beispielsweise größtenteils Web-Server. Eine dafür geschriebene Ansible-Rolle installiert die dafür nötigen Pakete, legt Konfigurationsdateien an und richtet Firewall-Regeln ein. Ab jetzt können die Kunden ihr System verwenden.

Bei der Finesse-Bank läuft der Prozess ähnlich, ist aber überschaubarer, weil nur SuSE Linux Enterprise Server als Betriebssystem vorgesehen ist. Auch gibt es nicht so viele Anwendungsszenarien. Zudem gibt es parallel zur produktiven Umgebung eine Test-Umgebung, in der Anpassungen an der Infrastruktur simuliert werden. Erst wenn dort alles reibungsfrei läuft, übernehmen die Admins die Änderungen in die nächste Stufe.

Die Qualitätsuniversität hingegen muss etwas tiefer in die Trickkiste greifen. Einige Anwendungen setzen dort Windows Server voraus. Auch diese werden vom orcharhino aus installiert und verwaltet. Dafür gibt es einerseits ein Golden Image, das auf den Virtualisierungshosts hinterlegt ist und direkt eingebunden werden kann. Andererseits gibt es auch eine individualisierbare Netzwerkinstallation, die ähnlich wie beim Kickstarting oder Preseeding unter Linux auf Templates setzt.

Lifecycle Management

Eine Kernfunktion des orcharhino ist das Bereitstellen von Software-Repositories – neben dem Konfigurationsmanagement und dem Deployment neuer Hosts. Allerdings ist er mehr als ein einfacher Spiegelserver, denn er kann Repositories auch versionieren. Bei der Finesse-Bank gibt es eine Gruppe von Repositories für das Betriebssystem, die jede Nacht aktualisiert werden. Ähnliches gibt es für Dritt-Anbieter-Software. Gleichzeitig entwickelt die Finesse Bank eigene Software. Auch diese liegt paketiert in Repositories, hier erfolgt der Upload jeweils händisch aus dem Entwicklersystem. Angebundene Systeme erhalten nicht automatisch Zugriff auf die neueste Version der Pakete, sondern eine Version zu einem bestimmten Zeitpunkt.

orcharhino-Admins fassen mehrere Repositories zu Produkten zusammen, zum Produkt SLES 15 SP1 beispielsweise gehören Repositories für das Betriebssystem und Updates. Verschiedene Repositories – nicht notwendigerweise aus nur einem einzelnen Produkt – lassen sich als Content Views zusammenfassen. Damit lässt sich der relevante Inhalt für ein Zielsystem aggregieren, beispielsweise fasst bei der Finesse Bank der Content View SLES15_Puppet die Repositories für SuSE Linux Enterprise Server 15 zusammen mit den Client Tools für den orcharhino und dem Konfigurationsmanagementtool Puppet.

Auf Dateiebene liegen alle Pakete in einem Pool, unter Umständen in mehreren Versionen. Wenn nun die Administratoren eine neue Version eines Content Views erstellen, wird ein neuer Zweig im Verzeichnisbaum erstellt, der Links zu den jeweils aktuellen Paketen enthält – quasi ein Snapshot. Bei der Finesse Bank ist derzeit die jüngste Version von SLES15_Puppet 11.0 und vor wenigen Tagen erstellt worden, Version 10.0 ist bereits ein knappes halbes Jahr alt, inzwischen aber mehrmals aktualisiert worden, um Sicherheitslücken zu beheben (dazu später mehr).

Bei der Finesse Bank durchläuft Software mehrere Entwicklungsstadien, die klassisch dev, test und prod heißen – der Lifecycle Path. Jeder dieser Umgebungen ist genau eine Version zugeordnet. Hosts in test und prod hängen derzeit an Version 10.8 des Content View SLES15_Puppet, in dev kommt Version 11.0 zum Einsatz, da dort einige neue Funktionen verfügbar sind, auf die die Entwickler gerne in ihrer Software zurückgreifen möchten. Ist es so weit, die jüngste Version ans Testing zu übergeben, wird der Versionsstand in der Umgebung test angehoben.

Unternehmen aus dem Finanzsektor haben gewöhnlich hohe Sicherheitsstandards. Um diese zu erfüllen, müssen die IT-Verantwortlichen den Überblick über etwaige Schwachstellen ihrer Systeme behalten. Unter Red Hat haben sich dafür die Errata etabliert – dieses Konzept steht inzwischen auch unter anderen Distributionen zur Verfügung. Dahinter verstecken sich Metainformationen zu veröffentlichten Sicherheitslücken. Neben einem Code zur Identifizierung und einer Beschreibung der Lücke gehört dazu eine List betroffener Pakete und eine Lösung, also in welchen neueren Paketen der Fehler behoben ist. Der orcharhino bezieht Listen mit Errata aus den Hersteller-Repositories. Gleichzeitig hält er Informationen vor, welche Pakete auf welchen Systemen installiert sind. ATIX stellt Kunden Errata auch für CentOS, Debian und Ubuntu zur Verfügung.

Für jeden Host kann man im orcharhino einfach erkennen, ob solche Errata das jeweilige System betreffen und sie direkt einspielen. Die zuvor erwähnte Minor Release des Content View kommt daher, dass Sicherheitsupdates in Paketen liegen, die in SLES15_Puppet 10.0 noch nicht vorhanden sind. In diesem Fall ist es möglich, nur einzelne Pakete zu aktualisieren und Minor Versions eines Content Views zu erzeugen.

Bei der Qualitätsuniversität ist dieser Vorgang insgesamt einfacher, da es keine Eigenentwicklungen gibt, sondern lediglich Upstream-Repositories gepflegt werden. Bei Value and Vision verhält es sich ähnlich, nur haben die Experten dort zusätzlich „Lifecycle Fast Paths“ eingefügt, in denen Minor Releases der Content Views getestet werden, bevor sie auf Kundensystemen landen.

Konfigurationsmanagement

orcharhino vereint mehrere Werkzeuge zur Automatisierung im Rechenzentrum. Eine zentrale Rolle nimmt dabei das Konfigurationsmanagement ein – neben dem Deployment neuer Hosts (siehe ‘orcharhino als Installationsquelle’) und dem versionierten Bereitstellen von Repositories (siehe ‘Lifecycle Management’) kann das als eine seiner Kernaufgaben betrachtet werden. orcharhino-Nutzer können sich beim Konfigurationsmanagement zwischen Ansible, Puppet oder SaltStack entscheiden, die alle integriert sind und sich über das Web-GUI verwenden lassen. Die Finesse Bank setzt dabei komplett auf Puppet. Das Tool hat sich etabliert in Bereichen, in denen Configuration Drifts vermieden werden sollen. Dafür laufen auf den angebundenen Systemen Agents, die in regelmäßigen beim Puppet Master ihre Zielkonfiguration abfragen. Weicht ihr Status davon ab, unternehmen sie alle nötigen Schritte, um den gewünschten Zustand zu erreichen. Beispielsweise könnten Pakete installiert oder deinstalliert werden, Services konfiguriert und gestartet. Puppet korrigiert alle Änderungen, die die Nutzer oder lokale Software vorgenommen haben. Meist – auch bei der Finesse Bank – übernimmt der orcharhino die Rolle des Puppet Master. Damit landen die Berichte der einzelnen Puppet Agents automatisch dort. Für jeden Host lasst sich detailliert nachsehen, welche Änderungen erfolgt sind. Gab es einen Fehler beim Durchlauf, wird der Host in der Übersicht entsprechend markiert.

Value and Vision verwendet Ansible zum Konfigurationsmanagement. Mit Ansible lassen sich besser sequenzielle Abläufe abbilden, zum Vermeiden von Configuration Drifts lässt es sich zwar auch einsetzen, das ist bei Value and Vision allerdings nicht so wichtig, denn nach Übergabe sind die Kunden selbst für ihr Maschinen verantwortlich. Im orcharhino sind dafür mit den Hosts Ansible Rollen verknüpft. Nach dem Installieren werden diese automatisch einmal ausgeführt und installieren beispielsweise bestimmte Pakete, nehmen Konfigurationen vor oder führen bestimmte Befehle aus.

An der Qualitätsuniversität ist das verwaltete System insgesamt heterogener, da früher die Institute für ihre Infrastruktur selbst verantwortlich waren. Der orcharhino bietet ihnen jetzt eine gemeinsame Oberfläche, entsprechend der jeweiligen LDAP-Zugehörigkeit haben die Admins aber nur Zugriff auf ihre eigenen Systeme. Teil dieser Heterogenität ist auch, dass unterschiedliche Konfigurationsmanagement-Tools zu Einsatz kommen. Manche Institute verwenden auch einen Mix. Das orcharhino-Team hat deshalb die Plug-ins für Ansible, Puppet und SaltStack aktiviert. Aus den Reports ergibt sich, dass alle drei zum Einsatz kommen.

Infrastruktur separieren

Die Qualitätsuniversität setzt den orcharhino inzwischen (siehe ‘Wie kommt der orcharhino eigentlich zum Kunden?’) für den gesamten Campus ein. Ursprünglich ein reines Projekt zur Verwaltung zentraler Dienste sind mittlerweile fast alle Institute involviert. Somit hat sich ein Sammelsurium von Tools und Ansätzen in einem Werkzeug konzentriert. Im Zuge dieses Prozesses hat sich gezeigt, dass es den einzelnen beteiligten Einrichtungen (Lehrstühle, Verwaltungseinheiten) wichtig ist, die ursprüngliche Trennung nach Instituten und Lehrstühlen weiterhin abbilden zu können.

Mechanismen, diese Trennung im orcharhino abzubilden sind in erster Linie die sogenannten Organizations und Locations. Als Organisationen beispielweise existieren Uni für die zentralen Dienste und die Lehrstuhlinfrastruktur sowie Verwaltung und Klinikum. Eine Ebene darunter sind die Locations angesiedelt. Die Verwaltung unterscheidet hier nicht weiter, das Klinikum hat sich für eine Untergliederung in Infrastruktur und Lehrbetrieb entschieden. Für die Organisation Uni gibt es Locations mit den Namen der einzelnen Lehrstühle, RZ, Cluster und Media. Alle Objekte im orcharhino erhalten eine Organization und eine Location zugewiesen. Das erlaubt einerseits, Listen zu filtern, und andererseits, Rechte zu vergeben.

Zur Nutzerauthentifizierung hängt der orcharhino am zentralen LDAP-Server der Universität und auch an dem des Klinikum. Meldet sich ein Nutzer am Web-Frontend an, weist das System ihm einer Nutzergruppe zu. Die Zuordnung erfolgt anhand der Gruppenzuordnung im LDAP. Lehrstuhl-Admins beispielsweise sehen nur ihre eigenen Rechner und können auch nur diese verwalten.

Die verwalteten Objekte sind in erster Linie die Hosts, denn damit arbeiten die Administratoren am meisten, aber beispielsweise auch Subnetze lassen sich in ihren Zugriffserlaubnissen einschränken. Somit können die Admins neu angelegte Hosts nur in bestimmten IP-Bereichen registrieren.

Jeder Administrationseinheit steht ein Klasse-C-Netz zur Verfügung. Fast alle Rechner erhalten öffentliche IPs, nur der Rechencluster befindet sich in einem privaten Netz und für bestimmte Server existiert eine separate DMZ. Das Clusternetz ist relativ stark abgeschottet, ähnlich einer DMZ. Lediglich zwei Nodes sind aus dem Universitätsnetz erreichbar und können Verbindungen nach außen aufbauen: ein Login-Knoten für die Nutzer und der orcharhino Proxy. Letzterer ist eine separate Instanz und gehört zur orcharhino-Infrastruktur. Er besitzt keine eigene Web-GUI, sondern dient lediglich als Bindeglied für Netzwerke, auf die der orcharhino keinen direkten Zugriff hat oder spiegelt Repositories, wenn sich das zur Minimierung der genutzten Bandbreite empfiehlt. Er empfängt auch Puppet-Reports und dient als Proxy für Ansible Calls. Auf dem orcharhino Proxy laufen ähnliche Dienste wie auf dem orcharhino, allerdings in einer untergeordneten Rolle. Pulp synchronisiert ausgewählte Repositories vom orcharhino – in diesem Fall Debian – und versorgt die Nodes mit Paketen, er ist DHCP-Server und Nameserver und liefert per PXE und TFTP die nötigen Daten zum Installieren neuer Nodes.

Neben dem Cluster gibt es derzeit 8 Subnetze, die am orcharhino hängen. Dazu gehört ein zentrales Netz, in dem die Serverdienste der Universität liegen (Intranet, Mailserver & Co) und mehrere Institutsnetze, wenn diese eigene zentrale Dienste oder kleine lokale Rechencluster, wie in der Physik oder der Chemie, betreiben.

In allen Netzen läuft ein orcharhino Proxy als Bindeglied zwischen den Hosts und dem orcharhino. Da die Netzwerklast bisher überschaubar ist, verwenden fast alle Hosts den orcharhino direkt als Paketquelle, sie müssen aber ihren jeweiligen orcharhino Proxy als HTTP-Proxy verwenden, denn es gibt keine direkte Route – der orcharhino selbst hängt in einem internen Netz. Arbeitsplatzrechner sind bisher von der zentralen Verwaltung durch den orcharhino ausgenommen, obwohl zumindest für die Linux-Pools darüber nachgedacht wird.

Value and Vision betreibt eine vergleichbare Infrastruktur, hat jedoch vorwiegend private Netze, auf die die Kunden per VPN zugreifen. Für jeden Kunden legen die Administratoren automatisiert eine eigene Organisation an. Hosts authentifizieren sich gegenüber dem orcharhino per SSL-Zertifikaten und sehen somit nur erlaubte Repositories. Einige Kunden hinterlegen selbstentwickelte Software und können somit sichergehen, dass kein etwaiger Mitbewerber darauf einfach Zugriff hat.

Die Finesse-Bank hat ein zentrales Netz in der Hauptfiliale und Subnetze an den Remote-Standorten. Die orcharhino Proxies dort spiegeln die Repositories vom orcharhino. Die Bedienung des orcharhino obliegt vollständig dem Infrastruktur-Team, sodass kein feingranulares Rechtemanagement auf Nutzerebene nötig ist. Dafür sind strengere Richtlinien für das Netzwerk nötig. Das liegt eigentlich außerhalb des Bereichs, den der orcharhino verwaltet. Die Hardware lässt sich jedoch per Ansible steuern, was sich wiederum über den orcharhino verwalten lässt.

Hypervisoren / Untersätze

Value and Vision betreibt weltweit mehrere Rechenzentren. Kunden benötigen typischerweise für bestimmte Projektphasen Rechenkapazität, wollen diese jedoch nicht dauerhaft vorhalten und sie auch nicht verwalten müssen. Meist bestellen sie dann virtuelle Maschinen, die ihnen vorkonfiguriert zur Verfügung gestellt werden. Haben sie ihre Aufgabe erfüllt, kann man sie einfach wieder löschen. Deswegen sind die Rechenzentren primär mit Virtualisierungshosts bestückt. Zu Beginn waren das lediglich VMware-ESXi-Host, in jüngster Zeit gab es da eine Neuerung: einige Rechenzentren stellt Value and Vision um auf Proxmox-Cluster.

Im orcharhino lassen sich als “Compute Resources” die API-Endpoints und Credentials der Virtualisierungshosts eintragen. Dadurch lassen sich über die orcharhino-GUI auf diesen Hosts virtuelle Maschinen erstellen, ein- und ausschalten und gegebenenfalls auch wieder löschen. Für VMware lassen sich zudem Snapshots mit dem orcharhino verwalten.

Legt also ein Mitarbeiter von Value and Vision einen neuen Host an, wählt er neben dem Betriebssystem den Virtualisierungshost und die Spezifikation der virtuellen Maschine. Nach einem Klick auf “Create Host” wird die VM automatisch erzeugt und gebootet. Sie erscheint anschließend als neuer Host in der Liste im Web-Interface – sowohl im orcharhino als auch beim Hypervisor.

Anderen Kunden verwaltet Value and Vision Bare-Metal-Server. Auch diese hängen am orcharhino, der Konfigurationsmanagement und Lifecycle-Management übernimmt. Dank „Intelligent Plattform Management Interface“ können Admins auch für diese Maschinen die Power-Einstellungen über den orcharhino steuern.

Jüngst haben die Admins auch die Plugins für die Cloud-Anbieter Amazon Web Services, Google Cloud Engine und Microsoft Azure installiert. Dadurch stehen auch diese als Compute Resources zur Auswahl und der orcharhino kann Instanzen dort anlegen. Ursprünglich war die Idee, darüber Spitzenlasten dynamisch abfangen zu können. Die ersten Kunden sehen darin jedoch neue Möglichkeiten, ihre virtuellen Maschinen mit anderen Diensten der jeweiligen Anbieter verknüpfen zu können.

Die Finesse-Bank hatte zu Beginn lediglich physische Server im Einsatz, diese aber nach und nach durch virtuelle Maschinen ersetzt. Der Flexibilität erweiterte die Einsatzszenarien und erlaubte eine besser an den Bedarf angepasste Auslastung der Rechenzentren. Dass sich diese zudem so einfach über den orcharhino verwalten lassen, hat physische Hosts quasi komplett verdrängt.

An der Qualitätsuniversität hingegen geht es fast ausschließlich um physische Server – zu groß die Bedenken der Wissenschaftler, dass ihnen CPU-Zyklen an Hypervisoren verloren gehen, die sie eigentlich für Ihre Berechnungen brauchen. Lediglich zentrale Netzwerk-Dienste laufen virtualisiert. Eine Besonderheit hat sich jüngst am Institut für Wirtschaftsinformatik etabliert. Dort gibt eine neue Professorin Kurse zur IT-Infrastruktur. Im ersten Semester ließen sich nicht spontan genügend Ressourcen bereitstellen, um den Kursteilnehmern Schulungsumgebungen zur Verfügung zu stellen. In den Planungen warf jemand aus dem Rechenzentrum ein, doch Cloud-Instanzen zu verwenden und dass der orcharhino dafür bereits vorbereitet sei. Er demonstrierte, wie sich Hosts in der Azure-Cloud anlegen ließen, die nach der Installation per Ansible eingerichtet wurden. Das erste Semester über wurden für die Kurse (Blockkurse) also Azure-Instanzen gestartet und direkt im Anschluss – ebenfalls über den orcharhino – wieder gelöscht. Dieser Weg hat sich bis heute erhalten und Kursinhalt ist inzwischen auch die Infrastrukturverwaltung mit dem orcharhino.

Wie kommt orcharhino zum Kunden

Als in den 70er Jahre die Qualitätsuniversität gegründet wurde, gab es noch keine IT-Infrastruktur an den einzelnen Lehrstühlen, alles wurde zentral über das Rechenzentrum verwaltet. In der Zwischenzeit wurden die Computer allerdings günstiger und Windows- und Linux-Administration einfacher. Wissen und finanzielle Mittel sammelten sich nicht mehr im Rechenzentrum und die IT-Landschaft fragmentierte. Mit dem Aufkommen von Konfigurationsmanagementtools startete ein Diskurs um eine erneute Konsolidierung. Über die Zeit etablierten sich trotz der Bestrebungen, die Infrastruktur zu vereinheitlichen, Insellösungen. Dann begann das Rechenzentrum, den sogenannten Gondor-Cluster aufzubauen und damit zentral HPC-Ressourcen anzubieten. Im Zuge dessen wurden verschiedene Verwaltungs-Tools evaluiert. Die Qualitätsuniversität entschied sich für den orcharhino. Man beauftragte die ATIX mit dem Aufbau einer Proof-of-Concept-Umgebung. Dafür installierte ein ATIX-Consultant einen orcharhino im Qualitätsuniversitäts-RZ samt orcharhino Proxy im Cluster Netz, bereitete diese vor, Debian-Hosts zu provisionieren. Zusätzliche band er einige vorgefertigte Puppet-Module ein, mit denen sich Hosts in das Cluster-Queueingsystem aufnehmen sowie wissenschaftliche Pakete installieren lassen. Diese Aufgaben vor Ort erstreckten sich über eine Woche, während der die RZ-Mitarbeiter immer wieder Gelegenheit hatten, sich einzelne Punkte gleich anzusehen.

Nach der Einrichtungswoche hatte die Qualitätsuniversität ihren ersten orcharhino und konnte anfangen, den Cluster damit komplett aufzubauen. Bereits bald danach begann dessen aktive Testphase. Aus dem PoC wurde schnell ein produktives System und man beschloss, weitere Systeme in den orcharhino aufzunehmen. Zunächst weitere zentrale Server, die ebenfalls auf Debian Linux liefen. Dann wurde schnell klar, dass sich die meisten Insellösungen ohne großen Aufwand ebenfalls integrieren ließen. Größte Hürde dabei waren die verschiedenen Distributionen bzw. sogar Betriebssystem im Einsatz. Hierfür vereinbarte die Qualitätsuniversität mit der ATIX eine Schulung vor Ort, um mehr Mitarbeiter an den orcharhino lassen zu können. Außerdem sollte für die nächsten Monate regelmäßig ein ATIX-Consultant zur Qualitätsuniversität kommen, um dort den Verlauf der Migration zu unterstützen. Zunächst baute man einen zentralen Git-Server, der die Definitionen für die Konfigurationsverwaltungen beherbergt, Paketquellen für die verschiedenen Distributionen wurden synchronisiert und darauf aufbauend Content Views und Activation Keys angelegt. Die zentrale Nutzerverwaltung wurde eingebunden und zuletzt fand man noch eine Verwendung für eine Compute Resource aus der Cloud, da eine neue Professorin für einen Kurs Schulungsinfrastruktur in Azure benutzte.

Die Besuche des ATIX-Consultants wäre zu Beginn natürlich häufiger – zwei Tage alle zwei Wochen – und gingen gegen Ende zurück auf einmal pro Monat, als die RZ-Mitarbeiter vertrauter wurden mit dem System.

Für die grundlegende Installation der Produktivsysteme bei Value and Vision und Finesse Bank holten sich die Unternehmen Unterstützung von ATIX. Beide hatten zuvor jedoch auf eigene Faust Tests mit dem orcharhino durchgeführt. Dafür gibt es eine Testlizenz. Deren Erlös geht übrigens an das Schutzprojekt „Save the rhino“. Nachdem das System für tauglich befunden wurde, bestellte die Finesse Bank jemanden ins Haus, um das Produktivsystem zu installieren. Value and Vision hat keinen wirklich zentralen Sitz, weswegen die Installation über Remote Sessions durchgeführt wurde. Dadurch zog sich der gesamte Prozess etwas länger, war jedoch deutlich flexibler.

This post is also available in: Englisch