Datacenter Management, zum Beispiel in München Infrastructure as Code mit deklarativen Tools

Rechenzentrums-Management wird immer komplexer. Wer sich da allein auf händisches Vorgehen und jeweils individuelle Prozesse verlässt, gerät ins Schwimmen. Einen Lösungsansatz bietet möglichst weitgehende Automatisierung mit Hilfe deklarativer Tools.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Cisco Systems GmbH

Red Hat GmbH

Red Hat GmbH

Rechenzentren werden immer größer und komplexer. Zudem arbeiten immer mehr On-Premises-Einrichtung eingebunden in ein ganzes Netz von Public Cloud Services. Container und Cloud-Native, CI/CD (Continuous Integration/Continuous Delivery), DevOps und andere neue Verfahren dringen über die Cloud in die Unternehmen ein.

Sie machen vieles, was schon lange auf dem Prüfstand steht, endgültig zum Auslaufmodell: Silo-Architekturen, wochenlange Beantragungsprozeduren, bis eine Ressource endlich bereitsteht, Monate währende Entwicklungsprozesse.

Die IT, so die aktuelle Philosophie, soll imstande sein, sich schnellstmöglich (und das bedeutet eben nicht mehr nach Jahren oder Monaten, sondern am besten sofort) an den sich stetig wandelnden Anforderungen des Kerngeschäfts ausrichten und zudem vorhandene Geschäftsprozesse optimieren oder gleich vollkommen neue, digitale ermöglichen.

Standardisierung und Automatisierung werden zum Muss beim Datacenter-Management

Das macht Druck auf Rechenzentrums-Admins: Standardisierung und Automatisierung lauten die Stichworte der Stunde. Dabei helfen deklarative Management-Tools. Doch was bedeutet das überhaupt?

Lange Zeit bestand IT-Management darin, den einzelnen Infrastrukturkomponenten Schritt für Schritt vorzuschreiben, was sie wie zu tun haben. Man spricht hier von imperativer Programmierung. Mittels Skript- oder klassischer Programmiersprachen wie Python wurden einzelne Schritte in umfangreichen Skripten festgelegt. Die Maschinen – physisch und virtuell – arbeiteten diese Skripte ab, sobald sie entweder durch den Admin oder aber andere Skripten respektive Tools aufgerufen wurden.

Anschließend prüfte der Admin, ob auch alles wie gewünscht funktionierte. War dies nicht der Fall, musste möglicherweise das Skript umgestrickt werden. Klassische Skripte sind meist geräte- oder herstellerspezifisch, daher mussten Admins häufig mehrere Skriptsprachen beherrschen und bei Herstellerwechsel neu erlernen. Weil man für viele Prozesse jeweils eigene Skripte brauchte, entstanden wahre Skriptdschungel. Kurz: Das Ganze bedeutete zu viel Aufwand, um schnell und flexibel auf Anwenderanforderungen reagieren zu können.

Was tun deklarative Tools?

Deklarative Tools für das Datacenter-Management dagegen verfolgen ein anderes Konzept: das der infrastruktur- und herstellerübergreifenden automatisierten Provisionierung und des automatischen Managements. Sie definieren in – verglichen mit imperativen Skript- oder Programmiersprachen - sehr nah an der natürlichen Sprache gehaltener Syntax und Terminologie, wie die Zielinfrastruktur aussehen soll.

Der Rest passiert „unter der Haube“: Die Software greift über die sich rasant verbreitenden offenen Schnittstellen, insbesondere die REST-API, auf die Infrastruktur zu und vergleicht zunächst die jeweils vorhandene Infrastruktur mit dem angestrebten Zustand. Anschließend ´deployed oder konfiguriert sie die Lösungen so um, dass der Wunschzustand erreicht ist.

Deklarative Skripte haben den Vorteil, exakt die gleichen Resultate zu erwirken, wann und wo immer man sie anwendet. Das gilt natürlich nur unter der Voraussetzung, dass die nötigen Geräte, Betriebssysteme und Schnittstellen vorhanden sind. Man kann Deklarationen versionieren und damit auf vorherige Implementierungsstände zurückgreifen. Die einzelnen Änderungen lassen sich transparent verfolgen.

Terraform und Ansible

Dennoch unterscheiden sich IaC-Tools voneinander. Zwei der bekanntesten sind „Terraform“ und „Ansible“. Terraform gehört Hashicorp, Ansible, ein Open-Source-Projekt, wird inzwischen von Red Hat/IBM supportet.

Terraform besitzt keinerlei Abhängigkeiten, kann also auf einem nahezu System installiert werden und zieht sich notwendige Komponenten automatisch nach. Ansible dagegen braucht in der Laufzeitumgebung Python und einige andere Voraussetzungen. Agenten brauchen beide Sprachen nicht. Zumindest für Ansible stehen mittlerweile zahlreiche herstellerspezifische Module bereit, die den konfigurierenden Zugriff auf die entsprechenden Komponenten oder Umgebungen erlauben.

„Daher wird Terraform eher für das Provisioning einer Infrastruktur und vor allem in Cloud-Umgebungen verwendet. Ansible setzen viele Anwender besonders gern für Konfigurationsaufgaben ein“, erklärte Philipp Roth, Solution Sales Specialist Next Generation Datacenter bei Cisco anlässlich eines IaC-Vortrags während der „Cisco Data Center University“.

Welche Vorteile das praktisch hat, berichtete auf der Veranstaltung Thomas Kneifel. Er ist bei it@m, dem für die IT zuständigen Eigenbetrieb der Stadt München, für Themen rund um die Datacenter-Vernetzung in den und zwischen den beiden Rechenzentren zuständig ist.

IT für 35.000 Stadtverwaltungsmitarbeiter

Sein zehnköpfiges Team sorgt dafür, dass die 35.000 Mitarbeiterinnen und Mitarbeiter der Stadtverwaltung sich jederzeit auf intakte Datacenter-Netzwerkressourcen verlassen können. Die Infrastruktur umfasst aktuell 270 virtuelle Hosts und etwa 6.000 virtuelle Maschinen, etwa 300 Subnetze, 24.000 Endpunkte und 800 aktive Access-Interfaces in der „ACI Fabric“.

Die 2013 implementierten „Nexus-7000“-Switches, die Back-to-Back implementiert wurden, waren etwa 2018 veraltet. Also suchten Kneifel und sein Team eine Nachfolgelösung. Am Ende lief es wegen der steigenden Bandbreiten- und Anwendungsanforderungen auf ein komplett neues Netzwerk hinaus.

Weil es eine unentbehrliche Ressource für die Stadtverwaltung ist, waren lange Ausfallzeiten anlässlich der Migration keine Option. Es musste also ein Weg gefunden werden, das riesige Projekt ohne solche Misshelligkeiten zu stemmen.

ACI-Multifabric als Nachfolger für Nexus 7000

Kneifel entwickelte zusammen mit dem langjährigen Umsetzungspartner Computacenter das Konzept einer Cisco-ACI-Multifabric mit Zugangsgeschwindigkeiten bis zu 40 Gigabit pro Sekunde (Gbit/s(. Alle Netzwerkprozesse sollten so weit wie möglich standardisiert und Fehlkonfigurationen durch Automatisierung vermieden werden. Alle Prozesse werden über Policies gesteuert. Feingranulare Templates und Rollen garantieren größtmögliche Flexibilität.

Um eine möglichst reibungslose Migration zu realisieren, wurde das gesamte Projekt mittels Ansible-Playbooks realisiert. So wird das Netz nun auch weiterentwickelt. Kneifel: „Ansible ist besonders dankbar, wenn Mitarbeiter mit wenig Programmiererfahrung es nutzen. Dabei helfen die vielen Templates und Module und die leichte Erlernbarkeit.“

Ab 2018 baute Kneifels Team die geplante neue Infrastruktur zunächst virtuell im „ACI Simulator“ auf. Schon dabei stellte es sich heraus, wie wichtig es ist, von Anfang an eine auch langfristig funktionierende Namenskonvention und weitere Standards zu denken, die dann konsequent eingehalten werden müssen.

Anschließend entwickelte das Team auf einer von Cisco bereitgestellten Testumgebung für nahezu jede denkbare Situation Testfälle. Sie wurden ad hoc in sehr kurzer Zeit über Ansible bereitgestellt und durchlaufen.

Denn anschließend erfolgte ein echter PoC in Ciscos Labs in den USA. Dorthin reiste das Team mit einem kompletten Set an Playbooks für sämtliche denkbaren Situationen. Nach drei Wochen intensiver Laborarbeit war alles für die Migration vorbereitet.

Migration mit nur vier Sekunden Ausfallzeit

Im Frühjahr 2019 wurden drei Drehbücher für die drei vorgesehenen Migrationsschritte erstellt. Ziel war eine maximale Ausfallzeit von sechs Sekunden, um auf die neue Infrastruktur mit 52 Leafs und vier Border Leaf Routern zu migrieren.

Im September erfolgte der erste Migrationsschritt, eine Layer-2-Kopplung zwischen neuer und alter Infrastruktur auf Backbone-Ebene. Anschließend wurden auf einen Schlag alle Gateways in den Rechenzentren migriert.

Schließlich stellte das Team nach und nach die 800 Access Interfaces von der alten Fabric auf ACI um. Am 7. April 2020 gelang die beim letzten Access Interface.Die Migration war damit abgeschlossen – mit nur vier statt sechs Sekunden Ausfallzeit. Seitdem läuft die neue Infrastruktur ohne Zwischenfälle. Änderungsnotwendigkeiten lassen sich dank Ansible risikoarm und schnell umsetzen.

(ID:47473815)