Zeit bis zur Wirkung
Dieser Blog ist eine Fortsetzung von „Was ist eine gute Steuerebene zum Betreiben einer großen Anzahl von Kubernetes-Clustern?“ . Im vorherigen Blog wurde Volterras einzigartiger Fleet Operations-Ansatz zur Verwaltung einer Flotte von Infrastruktursites und applications beschrieben. In diesem speziellen Blog wird eine zentrale Herausforderung im Zusammenhang mit Konfigurationsdrift beschrieben, mit der ein Betriebsteam konfrontiert wird, wenn es Konfigurationsänderungen über eine große Anzahl von Clustern oder Sites hinweg vornimmt. Ich nenne diese Herausforderung „Zeit bis zur Wirkung“.
Was ist die Zeit bis zur Wirkung?
Es lässt sich einfach so beschreiben: Wie lange dauert es, bis die Absicht einer Operation wirksam wird? Beispiele hierfür sind:
- Wie lange dauert es, bis die Konfiguration meiner Sicherheitsrichtlinie auf allen meinen Websites wirksam wird?
- Wie lange dauert es, bis die neueste Version meiner Application auf allen Websites verfügbar ist?
- Wie lange dauert es, das Betriebssystem oder die Infrastruktursoftware auf allen meinen weltweit verteilten Standorten zu aktualisieren?
Warum ist es wichtig?
Diese Frage lässt sich anhand einiger Kundenbeispiele aus der Praxis beantworten:
- Meltdown und Spectre – Nach Bekanntwerden der Meltdown-/Spectre-Nachrichten beschäftigte sich jeder CISO vor allem damit, wie er das Betriebssystem seiner gesamten Infrastruktur schnell patchen könnte. Dem Betriebsteam wurde stündlich gemessen, wann sein Vorhaben (z. B. ein Upgrade der Betriebssystemversion) in Kraft treten würde.
- Sie haben doch sicher von der Flotte von Verkaufsautomaten gehört, die einen Denial-of-Service-Angriff auf eine Universität verursacht hat, oder? Hier ist die Kurzfassung für den Fall, dass Sie den Angriff nicht verfolgt haben: Hacker haben eine Zero-Day-Sicherheitslücke ausgenutzt und Malware installiert, die sich mit anderen Verkaufsautomaten verband und eine Flotte von Verkaufs-Bots erstellte. Anschließend wurden enorme Datenmengen gesendet und ein Denial-of-Service-Angriff auf die Universität verursacht. Als die Universität den Angriff entdeckte, musste sie für jeden Verkaufsautomaten einzeln Netzwerkrichtlinienregeln konfigurieren, um den Zugriff auf den Befehls- und Kontrollserver zu verhindern. Es war ihnen äußerst wichtig, dass ihre Absicht (d. h. der Zugriff auf eine bestimmte Website zu sperren) sofort an allen Verkaufsautomaten wirksam wurde, um die Blutung zu stoppen.
Die Zeit bis zum Wirksamwerden ist für mehrere Kategorien wichtig, beispielsweise für Infrastruktursoftware, Application , Netzwerkrichtlinien und Sicherheitsrichtlinien.
Was ist die Herausforderung?
Die Herausforderung wird am deutlichsten, wenn das Einsatzteam Folgendes bewältigen muss:
- Eine große Anzahl von Websites
- Weltweit verteilte Standorte
- Heterogene Umgebungen, d. h. Standorte in privaten, öffentlichen, Telko-Clouds und Edge-Geräten
- Inkonsistente Konnektivität für Sites
Ein hervorragendes Beispiel für ein solches Betriebsteam ist ein Automobilhersteller, der für die Aktualisierung der Software und die Verwaltung der Konnektivität seiner Autos (nachfolgend „Kundenstandorte“ genannt) verantwortlich ist. Die typische Bereitstellung würde ein privates Rechenzentrum umfassen, von dem aus das Betriebsteam seine Fahrzeuge global (oder regional, je nach Organisationsstruktur) steuert.
Um die Herausforderung zu verstehen, schauen wir uns die Lösungen an, die dem Betriebsteam zur Verfügung stehen. Die meisten Lösungen bieten Verwaltungssoftware, die im privates Rechenzentrum des Kunden gehostet wird, um die große Anzahl verteilter Standorte zentral zu verwalten. Wenn der Automobilhersteller eine Richtlinie konfiguriert, die auf alle Autos angewendet werden muss, lädt die zentrale Verwaltungssoftware im Wesentlichen für jedes Auto einzeln ein Konfigurationsskript herunter. Das Konfigurationsskript könnte ein Ansible-Playbook oder ein Helm-Diagramm sein, das auf jeder Site eine Reihe von Konfigurationsbefehlen ausführt. Dies kann wie im folgenden Diagramm dargestellt visualisiert werden.
Das Problem besteht darin, dass die Zeit bis zum Wirkungseintritt direkt proportional zur Anzahl der Standorte ist. Anbieter zentralisierter Verwaltungssoftware argumentieren, dass dies das Beste sei, was erreicht werden könne, solange alle Vorgänge remote und automatisiert durchgeführt werden könnten.
Volterra ist anderer Meinung und wir können es in diesem Blog beweisen. Wir haben eine verteilte Kontrollebene mit einem hierarchischen, skalierbaren Architekturansatz erstellt, der eine minimale Wirkungszeit gewährleisten soll.
Volterra-Architektur für minimale Wirkungszeit
Die grundlegenden Bausteine zum Erreichen einer minimalen Wirkungszeit sind:
- Hierarchische baumbasierte Architektur
- Speziell entwickelte verteilte Kontrollebene
Als Nächstes wird ein allgemeiner Architekturüberblick angezeigt.
Der hierarchische Architekturansatz von Volterra besteht darin, einen Knotenbaum zur Konfigurationsverteilung zu erstellen. Jeder Knoten führt einen Store-and-Forward-Vorgang aus, d. h., er speichert die Konfiguration lokal und leitet sie dann an seine untergeordneten Knoten weiter. Dies lässt sich am besten anhand eines Beispiels beschreiben. Wenn ein Benutzer auf der Volterra-Konsole ein Objekt wie beispielsweise eine Netzwerkrichtlinie konfiguriert, verteilt die Steuerungs- und Verwaltungsebene die Konfiguration an unmittelbar untergeordnete Objekte, die Regional Edges (RE). Jede RE speichert die Konfiguration lokal und leitet sie an ihre untergeordneten Elemente weiter. Die untergeordneten REs sind Kundensites, die mit diesem RE verbunden sind.
Eine hierarchische, baumbasierte Architektur gewährleistet eine minimale Wirkungszeit. Die Zeit bis zum Eintritt der Wirkung wird durch die Anzahl der Ebenen im Baum und die Anzahl der untergeordneten Knoten pro Knoten begrenzt. Die maximale Anzahl von Ebenen im Baum beträgt drei (Controller → RE → Kundenstandort). Die Anzahl der untergeordneten Knoten pro Knoten ist direkt proportional zur Anzahl der mit RE verbundenen Sites. Auf dem RE wird eine Serviceinstanz erstellt, die die Konfiguration für eine Reihe von Sites handhabt. Die Scale-Out-Steuerungsebene von Volterra erstellt bei Bedarf neue Serviceinstanzen, wenn die Anzahl der mit dem RE verbundenen Sites zunimmt.
Versuchsaufbau
Die Messung der Wirkungszeit wurde an einer großen Anzahl von Kundenstandorten durchgeführt, die mit zwei regionalen Rändern in New York (NY8-NYC) und Paris (PA4-PAR) verbunden waren. Die Kundenstandorte waren weltweit verteilt auf Santa Clara (Kalifornien), Houston (Texas), Madrid (Spanien), Prag (Tschechische Republik), London (Großbritannien) usw. Darüber hinaus umfassten die Kundenstandorte heterogene Umgebungen wie AWS, virtuelle Maschinen (ESXi), Edge Gateways einschließlich Intel NUCs und Fitlet2.
Das Kundenportal und die globale Kontrollebene von Volterra liefen in Azure (Washington-IAD). Die Kunden-Sites wurden auf mehrere Namespaces und Mandanten verteilt, um eine reale Betriebsumgebung darzustellen.
Fehlerbedingungen wurden durch das Beenden von Serviceinstanzen auf dem RE und die Verwendung von Konnektivitätsverbindungen schlechter Qualität zwischen RE und Kundenstandorten simuliert. Abbildung 3 zeigt eine Momentaufnahme eines Segments der gesamten Flotte in einem einzigen Namespace.
Testmethodik
Prüfprotokolle mit Zeitstempeln werden im Volterra-System erfasst, wenn Objekte auf der Volterra-Konsole konfiguriert werden und die Konfiguration auf jeder Kundensite angewendet wird. Die Laufzeit wurde als Zeitdifferenz zwischen der Konfiguration auf dem Portal und der Application der Konfiguration beim Kunden gemessen. Als Nächstes wird der Vorgang Schritt für Schritt detailliert beschrieben.
- Konfigurieren Sie Objekte im Kundenportal.
- Messen Sie die Startzeit als Objekterstellungszeit im Kundenportal (im Folgenden als „Volterra Global Controller“ bezeichnet). Siehe beispielsweise Abbildung 4.
- Messen Sie die Endzeit als Zeitpunkt der Objekterstellung auf der Kundenseite. Siehe beispielsweise Abbildung 5.
Beachten Sie, dass es sich bei den angezeigten Screenshots um Beispiele handelt und sie sich nicht auf dieselbe Messungsiteration beziehen.
Startzeit der Konfiguration
Endzeit der Konfiguration
Testergebnisse
Die Prüfergebnisse der Laufzeiten sind in den Abbildungen 6 und 7 dargestellt. Die Grafik in Abbildung 6 zeigt, dass die meisten Messproben eine Ausbreitungszeit zwischen 0 und 400 ms hatten. Dies bedeutet, dass alle Kundensites zwischen 0 und 400 ms mit einer neuen Konfiguration aktualisiert werden. Wie bereits erwähnt, wurden Fehlerbedingungen simuliert, indem die Dienste auf der RE neu gestartet und Verbindungsfehler/-verzögerungen auf der Kundenseite eingeführt wurden. Die Konfigurationsausbreitungszeit ist unter diesen Fehlerbedingungen länger und lag bei diesen spezifischen Tests je nach Fehlertyp zwischen 600 ms und 9 Sekunden. Beispielsweise verlängert ein Verbindungsfehler zwischen RE und Kundenstandorten die Zeit, die die Konfiguration benötigt, um den Kundenstandort zu erreichen. Der Vorteil der verteilten Steuerungsebene von Volterra besteht jedoch darin, dass sie dem Paradigma einer letztendlich konsistenten Konfiguration folgt, d. h. sie versucht immer wieder sicherzustellen, dass die Konfiguration auf allen Kundenseiten der vom Kunden definierten Absicht entspricht.
Die Grafik in Abbildung 7 zeigt, dass in 85 % der Fälle alle Kundensites innerhalb von 322 Millisekunden mit einer neuen Konfiguration aktualisiert werden. In einer Situation, in der Fehlerbedingungen auftreten, kann es an einigen Kundenstandorten zu einer Ausbreitungszeit von ca. 3–9 Sekunden kommen.
Haftungsausschluss: Diese Messungen hängen eng mit der Topologie, dem Maßstab, der Bereitstellungsumgebung und den simulierten Fehlersituationen zusammen. Wir haben nicht alle möglichen Fehlersituationen oder andere Umgebungen gemessen. Daher können wir keine Aussagen zur Ausbreitungsverzögerung in anderen Situationen oder Umgebungen machen, die nicht getestet wurden. Wenn beispielsweise ein Kubernetes-Clusterfehler auftritt, müsste das System auf die Fehlererkennung warten, einen Neustart durchführen und die Konfiguration wiederholen, was zu einer längeren Ausbreitungsverzögerung führt.