Multi-Cloud-Konnektivität als Herausforderung für Admins Mehrere Clouds richtig überwachen

Anbieter zum Thema

netfiles GmbH

Hyland Software Germany GmbH

Cloudgermany.de GmbH

Die Cloud-Nutzung hat unbestritten viele Vorteile. Weniger Komplexität der IT ist einer davon. Doch wenn Unternehmen mehr als eine Cloud nutzen oder sogar mehrgleisig mit hybriden Multi-Cloud-Umgebungen unterwegs sind, ist es schnell vorbei mit der Einfachheit.

Die Adaption von Cloud-Technologien hatte in Deutschland aus mehreren Gründen einen schwierigen Start und verläuft deutlich schleppender als beispielsweise in den USA oder in China. Mit dem Beginn der Pandemie und den damit einhergehenden Maßnahmen, das Arbeiten von zu Hause zu ermöglichen, ist jedoch auch hier ein Wachstum zu verzeichnen. Pläne zur digitalen Transformation, die auf Jahre angelegt waren, konnten nun innerhalb von wenigen Monaten realisiert werden.

Obwohl auch das Wissen der Technikexperten wächst und gedeiht, kommen aber Fragen auf, wie man das Service-Level bei einer Cloud-Umgebung überwachen kann. Genauer genommen: Multi-Cloud ist das Problem, weil viele IT-Admins mit diesem speziellen Thema noch nicht voll vertraut sind.

Es gibt verschiedene und durchaus berechtigte Gründe, warum eine Organisation mehrere Cloud-Anbieter anstatt „nur“ einen nutzt. In manchen Fällen ist der Hintergedanke, die Verfügbarkeit einer Anwendung zu erhöhen. Mehr als nur einen Cloud-Anbieter zu nutzen, erlaubt Designs im Aktiv/Passiv- oder Aktiv/Aktiv-Betrieb. Multi-Cloud High Availability ist die einzige echte Form eines Aktiv/Aktiv-Designs und kann genutzt werden, um Ausfällen bei einem einzigen Provider vorzubeugen, oder aber mit einer spezifischen Region, oder eines Domain Name System (DNS). In einem Aktiv/Passiv-Design agiert der zweite Cloud-Anbieter als Failover für Disaster Recovery (DR), und zwar nicht nur bei Problemen beim Anbieter, sondern auch bei temporären Angriffen wie DDoS (Distributed Denial of Service).

In den meisten Fällen jedoch ist der Denkansatz der, dass beide – oder gar mehrere – Anbieter anhand des aktuellen Bedarfs im Unternehmen gleichzeitig eingesetzt werden können oder man einen Prozess zwischen ihnen aufteilen kann. Ein geläufiges Modell ist die Unterscheidung nach Produktiv- und Development/Test-Umgebung. Dadurch kann man versehentliche Veränderungen am Produktivbetrieb vermeiden, die schnell in hauseigenen Sabotageakten enden könnten.

Ebenso kann die Aufteilung helfen, Kosten zu senken. So könnte zum Beispiel eine komplette Entwicklungsumgebung samt aller Server in der Cloud automatisch nach Dienstschluss heruntergefahren werden. Eine klare Trennung der Plattformen nach Projekten kann auch bei der Abrechnung helfen. Wenn beispielsweise ein spezifisches Budget für ein Projekt oder eine interne Dienstleistung zugewiesen wurde, dann behält man leichter den Überblick über die Kosten, wenn sämtliche Kosten von Anbieter A auch dem Budget von Projekt A zugewiesen werden können.

Da Multi-Cloud in nahezu allen Fällen auch gleichzeitig hybrid bedeutet, ist es wichtig, dass die IT-Abteilung vergleichende Daten der Cloud-Anbieter sowie der involvierten On-Premises-Objekte nutzen kann, um den Überblick zu bewahren. Dies geht beispielsweise mit Cloud-Monitoring-Lösungen von SolarWinds.

Wie man sich Überblick verschafft

Um mit AWS zu kommunizieren werden die Metriken aus CloudWatch bezogen, bei Azure aus PowerShell; eine funktionierende Verbindung in die Wolke ist ohnehin gesetzt. Bei AWS muss vorab ein Konto für die Überwachung erstellt werden. Notwendige Berechtigungen sowie Richtlinien werden angehangen, und schließlich ein Schlüssel signiert und ausgetauscht. Man kann auch notwendige Berechtigungen per JSON in den IAM-Bereich der AWS Management Console anhängen. Danach werden die IAM-Richtlinien editiert und an das Konto gebunden. Die Richtlinien sind im Detail hier erklärt.

Schließlich wird ein Access Key generiert, der zur Authentifizierung dient. Die Keys können an gleicher Stelle auch deaktiviert werden, und davon sollte im Sinne der IT-Sicherheit auch regelmäßig Gebrauch gemacht werden. Ähnlich läuft es bei Azure: Ein Konto wird benötigt, und dieses nutzt die Azure AD App zur Authentifizierung. Das Konto erwartet die Subscription, Tenant und Client ID sowie den geheimen Anwendungs-Schlüssel. Alles kann unter „Subscriptions“ im Azure-Portal gefunden werden.

Der Ordner „Access Control“ erlaubt das Ändern bzw. Zuweisen von Berechtigungen. Für die Überwachung allein reicht „Reader“, aber sollten auch Aktionen für Automation (wie Start/Stopp/Reboot) gewünscht sein, muss die „Contributor“-Rolle ausgewählt werden.

Beim Thema Automation ist zu beachten, dass jedes Monitoring-System Performance-Indikatoren sowie Events nutzt, um Situationen zu identifizieren, die dann eine Alarm-Bedingung wären. Das Anwenden von Veränderungen innerhalb der Cloud-Plattform oder dem Betriebssystem individueller VMs wäre dann eine Alarm-Aktion oder Auslöse-Aktion.

Welche Daten sollten gesammelt werden?

Kurze Antwort: Eine ganze Menge. Aber tatsächlich ist das etwas komplizierter.

Ganz generell sammelt eine API Informationen über die unterliegende Infrastruktur der Cloud-Provider, soweit das Konto es zulässt. Das geht über Netzwerk-Informationen wie IP, DNS und Verbindungen, Informationen über Storage inklusive angehängter Volumen, eher spezifischen Informationen wie Platzierungsgruppen und Verfügbarkeit-Zonen, aber auch weniger spezifischen Daten wie die allgemeine Ressourcen Auslastung, und ein paar Sicherheitsinformationen.

Azure ist durch PowerShell etwas zugänglicher, daher ist es einfach, sogar komplexe Metriken auszulesen wie zum Beispiel Site-to-Site-Verbindungstunnel oder Abonnement-Informationen. Um darüber hinaus Informationen vom Betriebssystem oder den Anwendungen zu bekommen, ist in den meisten Fällen ein push-fähiger Agent auf der VM/Instanz erforderlich. Je nach Bedarf können weitere Daten ausgelesen werden, zum Beispiel über Amazon Route 53 beziehungsweise Azure DNS Zone und die entsprechenden Einträge. Ebenso wichtig sind V-Netze und deren Gateways, sowie Storage-Informationen.

Aber was ist jetzt mit den Verbindungen?

Häufig wird beim Monitoring vergessen, die tatsächlichen Verbindungen zwischen Objekten zu kontrollieren. In einer traditionellen On-Premises-Umgebung ist das einfach, bei Verbindungen von einem Cloud-Anbieter zum anderen schon etwas komplexer.

Ein gewöhnliches und simples Szenario könnte eine Anwendung in AWS sein, vielleicht ein Share Point Server, aber die Datenbank ist in Azure bereitgestellt, weil die SQL-Lizenzierung mit entsprechendem Vertrag attraktiver ist. Zuerst wird die Abhängigkeit der beiden Anwendungen erstellt beziehungsweise im besten Fall automatisch erkannt. Und dynamische Karten helfen beim Identifizieren von Problemen durch die visuelle Komponente.

Bildergalerie

Bildergalerie mit 16 Bildern

Damit ist es kein großes Problem, Maschinen und Anwendungen unabhängig von Standort oder Einsatzart im Griff zu behalten, aber die Kommunikation muss auch sichergestellt sein. Hier kommen Werkzeuge zur Analyse des Datenpfades ins Spiel. Altgediente Tools wie Trace Route sind leider nicht mehr zeitgemäß, da die falschen Protokolle überprüft werden. Die meisten Anwendungen nutzen TCP, also wird auch eine TCP basierende Hop-by-Hop-Analyse benötigt, um die einzelnen Knoten auf dem Pfad zwischen der Anwendung und der Datenbank zu sehen.

Das Datenbank-Beispiel würde also die Strecke über TCP 1433 überwachen und alle involvierten Knoten anzeigen. Hier ist es besonders sinnvoll, wenn über die IP-Adressen der Knoten gleich zusätzliche Informationen gesammelt werden, so kann man verschiedene iOS über die AS-Nummern zusammenfassen und gleich die Inhaber-Informationen mitliefern, um mögliche Probleme auch dem Internet Service Provider zuordnen zu können.

Wenn nun eine Änderung beim Routing bei AWS, Azure, oder vielleicht dem ISP eintritt, wird das System es anzeigen. Da wir hier von SDN sprechen, kann man naturgemäß viele Veränderungen erwarten, aber die sind nur interessant, wenn ein Schwellwert erreicht und dadurch ein Warnverhalten ausgelöst wird. Solche Technologien erlauben das Nachverfolgen der Verbindung auch retrospektiv, und ermöglichen damit zum Beispiel das schnelle Überprüfen von langsamen oder problematischen Verbindungen in der letzten Nacht und von Cloud zu Cloud.

* Der Autor Sascha Giese ist Head Geek bei SolarWinds.

Cloud-Know-how im IT-Team gezielt aufbauen

Plötzlich Cloud-Admin! – Vom (Un)Mut zur Wissenlücke

(ID:47036222)