Ihr Partner zur Netzwerkautomatisierung

Wir bieten unser Fachwissen rund um Architektur und Implementierung, um gemeinsam mit Ihrem Netzwerkbetriebs- und Engineering-Team eine passgenaue Automation-Lösung zu entwickeln und auszurollen.

Netzwerkautomatisierung ist vielschichtig

Die Automatisierung aktueller Netzwerkprodukte und Software-Defined-Networking (SDN) hat große Schnittmengen hinsichtlich Anforderungen und Vorgehensweisen mit Automatisierungsaufgaben anderer IT-Fachdomänen. Dies trifft insbesondere auf erzeugtes Automatisierungsartefakte (die Konfigurationen oder Code zum Erzeugen eben dieser) und deren Verwaltung zu. Der Stand der Technik wird dabei von DevOps, NetOps, (Continuous Integration/Continuous Delivery), SDN (Software Defined Networking) und artverwandten Schlagwörtern umrissen.

Allerdings gibt es in großen Netzwerken in der Regel wichtige Bestands-Hard- und -Software, welche sich am Ende des Produktlebenszyklus befindet, als auch besondere regulatorische Vorgaben nebst hohen Ansprüchen an Sicherheit, sowie Nachvollziehbarkeit beziehungsweise Auditierung.

Ansible Automation Plattform – herstellerübergreifende Netzwerkautomatisierung

Zur Implementierung von Netzwerkautomatisierung nutzt die foundata Red Hat Ansible und dessen Ökosystem. Dabei können die reinen Open Source-Varianten ohne Hersteller-Support zum Einsatz kommen, aus Compliance Sicht ist in Enterprise-Umgebungen jedoch die von Red Hat angebotene Ansible Automation Plattform (AAP) meist die sinnvollere Option, auch wenn die Open Source-Upstream-Komponente funktional nicht eingeschränkt sind.

AAP bietet herstellerunterstütze Versionen von aktuell siebzehn Open Source Komponenten wie AWX (Orchestrator) oder Automation Hub (Galaxy). Hinzu kommen von Red Hat in Partnerschaft zertifizierten Automatisierungs-Collections zahlreicher namhafter Ausrüstern wie Cisco, Juniper und VMware. Diese erleichtern unter anderem auch die Automatisierung von z.B. Legacy Cisco-IOS-Hardware ohne Verlust von Unterstützung durch den Hersteller. So bietet AAP zudem auch Support für Legacy-Geräte und solche mit einer offenen Netzwerkinfrastruktur in virtuellen sowie physischen Umgebungen mit mehreren Herstellern, um das Netzwerk mit einem einzigen Werkzeug zu automatisieren.

Ansible verwendet auch für Netzwerkadministratoren einfach zu lesendes und leicht zu versionierendes YAML als primäre Deklarationssprache und fügt sich in Versionierungs-Workflows ein. Dies erleichtert die Implementierung von GitOps-Ansätzen sowie CI/CD als auch Nachvollziehbarkeit (und damit Compliance im Allgemeinen).

Die dynamischen Inventories (welche man sich wie Scripte zum Abrufen von Informationen mit der Ausgabe von Listen an Ansible vorstellen kann) sparen in der Regel Aufwände, dedizierte Middleware zur Kommunikation zwischen verschiedenen Datenhalden und Bestands-Inventarisierungssystemen (z.B. FNT Command oder NetBox) zu schreiben.

Auch die Möglichkeiten, Ansible-Kernfunktionalität gezielt mit wenigen Python-Kenntnissen erweitern zu können kann für umgebungsspezifische Randfälle nützlich sein, da diese Erweiterungen in der Regel unaufwendig sind und erheblich weniger Entwicklungskapazitäten binden, als Wrapper oder Middleware ohne Ansible-Umgebung entwickeln zu müssen.

Machen Sie den nächsten Schritt, sprechen wir über Ihren Automation-Use-Case

Die Probleme

Traditionell monolithisch und proprietär geprägte Umgebungen

Netzwerktechnologien und Produkte haben sich stets weiterentwickelt, jedoch hat sich die Art des Netzwerk-Managements oftmals nicht im gleichen Maße verbessert. Netzwerke sind traditionell von eher monolithischen, proprietären Plattformen ohne Automatisierungsfunktionen geprägt. Oftmals konzentrieren sich die Netzwerkhersteller mehr auf einzelne Produktfunktionen. Dies spiegelt sich auch im Tooling für Netzwerkadministratoren wieder: Netzwerkhersteller-bezogene Hilfsmittel zur manuellen Verwaltung (auch großer Hardware-Bestände) existieren für gewöhnlich, um mindestens repetitive Aufgaben zu vereinfachen oder Übersichten zu generieren – sie sind in der Regel aber an die jeweiligen Hersteller- und Produktlinien gebunden. Diese Lösungen stellen damit administrative Silos dar und zielen nicht auf eine nachhaltige, allgemeine betriebliche Verbesserung ab. Dies trifft auch auf die direkte Administration moderner SDN-Plattformen zu, die besser in eine übergreifende Automatisierung eingebunden werden könnten.

Direkt sichtbare Auswirkungen dieser Umstände finden sich meist leicht. So ist es beispielsweise die Regel, dass das Zustandekommen und die fachlichen Gründe der aktuellen Konfiguration auf Routern und Firewalls nicht mehr in Gänze nachvollziehbar ist, was insbesondere hinsichtlich Auditierung und des Nachweises einer Deckungsgleichheit eines SOLL- und des IST-Zustands problematisch ist, obwohl in großen Organisationen in der Regel Vorgaben und ausgearbeitete, ausgereifte Prozesse zur Verwaltung von Änderungen, Quellcode, Tests und auch Plattformen zum kontrollierten Ausliefern von Code (hier: Konfiguration) gäbe.

Ohne Automatisierung fehlt der Überblick

Auch operativ stellt der Status Quo, selbst bei vorliegen von automatisierten SDN-Inseln und produktspezifischen Hilfen, eine Herausforderung dar. Ohne eine übergreifende Netzwerkautomatisierung kann es schwer sein, Änderungen kontrolliert und nachvollziehbar über die Gesamtheit der realen und virtuellen Netzwerkhardware aus- oder zurückzurollen, Inventories (Bestände) mit Querverbindungen in Gänze nachzuvollziehen, aus diesen die richtigen Schlüsse oder notwendigen Anwendungsreihenfolgen abzuleiten (Topologiekenntnisse), oder Mindestkonfigurationsstandards über Netzwerkplattformen und -grenzen hinweg aufrechtzuerhalten.

Dies ist auch wegen der weitreichenden Auswirkung von Netzwerkausfällen, -fehlfunktionen, oder Sicherheitsproblemen für produktive Umgebungen problematisch und stellt daher sehr hohe Anforderungen an Netzwerksbetriebspersonal. Hinzu kommen die Anforderungen, die sich aus zunehmender Containerisierung, Cloud-Anwendungen und Software-Defined-Networking im Allgemeinen ergeben. Die Volatilität von Container-Umgebungen bedingt beispielsweise oftmals eine automatisierte Vorgehensweise auch auf Netzwerkebene, da manuelle Freigaben, Inventarisierungen oder Ähnliches bei der Masse an Änderungen unweigerlich an ihre Grenzen stoßen.

Must-haves einer zeitgemäßen Netzwerkautomatisierung

Herstellerübergreifende Automatisierung mit Inventories, Versionierung sowie CI/CD (Continuous Integration/Continuous Delivery) und deren inhärenten kontinuierlichen Verbesserung können Aufwände erheblich reduzieren. Dies gilt insbesondere auch für Reporting, Auditing, Betrieb, Notfall/Wiederanlauf oder dem ITIL-Service-Design und der Service-Transition hin zum Betrieb neuer Plattformen unter einer wohldefinierten Zielkonfiguration und Compliance. Diesen Umständen muss eine moderne Netzwerkautomatisierung Rechnung tragen:

• Übergreifende Nutzbarkeit, unabhängig vom Netzwerkhersteller bzw. -ausrüster:
  • Agentenlosigkeit: Die Installation von Agents sollte keine Bedingung sein, da Agents die möglichen Zielplattformen einschränken, daher Interoperabilitätsprobleme verursachen und je nach Implementierung die Angriffsfläche erhöhen können.
  • Pflegen von Mindestkonfigurationsstandards über einzelne Netzwerkplattformen hinweg
  • Bei Bedarf mit Möglichkeiten zur Ansteuerung von Alt-Hardware mit Abhängigkeiten von Befehlszeilenschnittstellen (CLI).
• Deklaratives Arbeiten: Dabei ist die Nutzung von gängigen DevOps-Standards zur Beschreibung von SOLL-Zuständen zielführend, vorzugsweise über Techniken, die sich auch in netzwerkfremden IT-Anwendungsfällen etablieren konnten:
  • Etabliertes Format (YAML, JSON) oder zumindest einer verbreiteten Domain Specific Language (DSL)
  • Möglichkeit zur Nutzung von wahrscheinlich bereits bestehenden Prozessen und Toolings (z.B. Testframeworks innerhalb einer CI/CD-Pipeline)
  • Leichtere Umsetzung des ITILv4-Service-Wertsystems, welches einen ganzheitlichen und damit auch abteilungsübergreifenden Ansatz verfolgt.
• Ermöglichen von Idempotenz: wiederholbare Ausführungen muss das gleiche Ergebnis auf dem Zielsystem liefern. So kann durch stete Ausführung SOLL- und IST-Zustand gleich gehalten und bei Abweichungen automatische Konvergenz gegen den SOLL-Zustand ohne manuelle Eingriffe erreicht werden.
• Nutzung und Aufbereitung von bestehenden Inventories. Eine Lösung, die es ermöglicht ohne weitere Middleware Bestandssysteme und deren APIs anzusteuern (z.B. durch leichte Einbindung von RESTful APIs) ist von Vorteil. Bestehende Datenquellen sollten genutzt und eingebunden werden können (z.B. das weit verbreitete FNT Command oder NetBox).
• Einfache Abbildung von notwendigen Änderungskontrollen und einfügen in artverwandten Rahmen wie ITILv4-Continual Improvement oder dem ITILv3 Service-Lifecycle
• Bereitstellung einer API, um automatisierte Aufgaben und Prozesse für Umsysteme bereitzustellen:
  • Möglichst RESTful:
    • Unterstützung von API-Layering (um sich in Konzepte, z.B. für höher liegende Orchestratoren, einzufügen)
    • Zustandsloser Betrieb (Stateless)
  • Abstraktion von herstellerspezifischen nachgelagerten REST-APIs (z.B. SDN-Controllern)
  • Einfügen in Enterprise-Sicherheitsumgebungen hinsichtlich Authentifizierung (z.B. LDAP, AD) und Autorisierung (zum Beispiel RBAC (Role Based Access Control) für einzelne Prozesse)