Viptela SD-WAN: Was darf es denn sein? Single-, Micro- oder Multi-Tenancy? (1/2)
Mit der Einführung von SD-WAN fragen sich viele Firmen, wie die idealste Struktur für ihre Unternehmung ausschauen könnte. Typischerweise haben international tätige Kunden oder auch Service Provider verschiedene Regionen oder Kunden-Gruppen, die in der Lösung abgebildet werden sollen. Einzelne, isolierte regionale Domains zu bilden, ist sicherlich nicht verkehrt, aber diese müssen ja auch untereinander kommunizieren, ohne dass aufwändige Gateways oder andere Übergänge betrieben werden wollen. Auf der anderen Seite möchte man vermutlich die regionalen Domains auch über regionale Administratoren pflegen lassen, nur schon um die Zeitzonen- oder Sprach-Problematik entschärfen zu können. Viptela SD-WAN bietet hierzu verschiedene Grade betreffend Mandantenfähigkeit an. Was sind die Unterschiede und was ist nun hierzu die beste Lösung ?
SD-WAN und die Mandantenfähigkeit – verschiedene Ansätze
Die Viptela Lösung bietet für diese Herausforderungen verschiedene Konzepte an, so werden z.B. Single- Micro- oder Multi-Tenancy Varianten unterstützt und somit kann sich die Lösung sehr flexibel an die verschiedenen Anforderungen anpassen. Im ersten Teil dieses Blogs schauen wir uns die Single- und Micro-Tenancy Varianten an und im zweiten Teil dann die seit 19.2 vorhandene neue Multi-Tenancy Möglichkeit.
SD-WAN Architektur
Zur Erklärung sei hier nochmals kurz die grundsätzliche Architektur der Viptela SD-WAN Fabric erläutert:
Eine Viptela SD-WAN Fabric basiert auf folgenden Bausteinen:
- Backend-Controller (vManage, vSmart, vBond) für die Control-Plane
- CPEs / Router (cEdge – z.B. ISR 1100 oder ISR 4000 Geräte) für die Data-Plane
In der folgenden Skizze sieht man dies schematisch von oben nach unten; oben ist das Backend, welches die Orchestrierung der Lösung mittels vManage, vSmart und vBond vornimmt und unten die entsprechenden CPEs / Router, die für das Data-Plane und für die verschlüsselte Kommunikation zwischen den Endgeräten verantwortlich sind. Nicht eingezeichnet sind die “vertikal” verlaufenden Control-Plane Verbindungen, die mittels verschlüsselten Tunnels zwischen den CPEs und dem Backend vorhanden sind, um Konfigurations-, Routing- oder Image-Updates, Telemetrie-Daten sowie Policy-Änderungen zu übertragen.
Typischerweise werden aus Redundanz-Gründen immer ein vManage mit entweder Snapshot-Backups oder als Cluster-Verbund sowie mindestens zwei vSmart sowie zwei vBond implementiert. Mit dieser Konstellation skaliert die Lösung bei Bedarf bereits bis zu mehrere tausend CPEs.
Single-Tenancy
Kommen wir nun zu den verschiedenen mandantenfähigen Szenarien wie Single- oder Micro-Tenancy. Die einfachste und normalerweise typische Form der Implementierung ist die Single-Tenancy Variante. Hier wird ein Set von Controllern für einen einzelnen Kunden provisioniert und implementiert. Der Kunde kann mit dieser Variante die volle Skalierung der Viptela-Lösung verwenden, jedoch ist dies immer eine einzige SD-WAN Domain. Dies bedeutet, dass alle Log-Files, die Telemetrie-Daten und alle Konfigurations-Templates immer für die gesamte Lösung Gültigkeit haben.
Grundsätzlich kann man auch sagen -> Single-Tenancy = Ein Kunde
Micro-Tenancy
Eine sehr interessante Umsetzungs-Variante ist die Micro-Tenancy Implementierung, die seit Version 19.1 unterstützt wird. Diese Variante hat den gleichen Aufbau der Controller wie bei Single-Tenancy, geht jedoch in Bezug auf die Mandantenfähigkeit einen Schritt weiter. Die eingesetzte Funktionalität wird auch als “RBAC per VPN” Feature bezeichnet (RBAC = role based access control) und macht sich zunutze, dass die Lösung die Segmentierung des Overlays in Form von VPNs unterstützt. Mit Hilfe dieser VPNs kann der Datentransport analog VLANs im LAN-Campus in einzelne Segmente unterteilt werden, die entweder für eine End-to-End Zonierung oder auch für die Unterteilung in Regionen mit lokalen Admins genutzt werden kann.
Die Architektur der Segmentierung in der Viptela Lösung sieht so aus:
LAN Segmente können mit der Lösung im SD-WAN Overlay getrennt voneinander End-to-End übertragen werden, in diesem Beispiel mit zwei Aussenstellen kann das Subnet A links mit dem Netz C rechts kommunizieren, jedoch A nicht mit D. Das Netz B wiederum kann mit das Netz D, jedoch nicht C kommunizieren, da im Overlay die einzelnen Segmente mittels Label getrennt voneinander transportiert werden. Das Vorgehen ist sehr ähnlich wie bei L3 MPLS-VPNs aufgebaut und vergleichbar.
Dieses Konzept kann weiter ausgebaut werden, indem die einzelnen VPNs im vManage aus Konfiguration und Monitoring-Sicht mit RBAC Ansätzen voneinander getrennt werden und der Zugriff auf einzelne Admins verteilt wird. Damit ist es möglich, ein “shared Head-End” aufzubauen und dieses mit diversen unterschiedlichen VPNs mit den Aussenstellen zu verbinden. Werden diese VPNs nun mittels RBAC an verschiedenen Admins zugewiesen und entsprechend sinnvoll verteilt, hat man eine Micro-Tenancy Implementierungs-Variante. Jeder lokale Admin sieht nur seinen Einflussbereich und kann auch nur dort Änderungen vornehmen und “seine” Umgebung überwachen.
Hier sieht man, wie Micro-Tenancy aufgebaut ist. Das zentrale, geteilte Head-End terminiert alle VPNs aller Regionen, während in den Regionen selber nur einzelne VPNs abgebildet sind. Der lokale “Regionen-Admin” sieht jeweils nur seine Umgebung, auf die er mittels RBAC Steuerung Zugriff erhalten hat. Mit diesem Ansatz kommunizieren alle Regionen mit dem Head-End, jedoch sehen sich die Regionen untereinander nicht.
Dieser Ansatz macht dann Sinn, wenn z.B. ein Service Provider oder grosser Enterprise seinen Kunden/Länder-Domains eine eigene lokale Sicht anbieten möchte, die SD-WAN Lösung jedoch schlank gehalten werden soll – man benötigt nicht für jeden Kunden ein eigenes Head-End. Weiter kann man das Monitoring und Änderungen den lokalen Admins überlassen, diese haben nur Zugriff auf “ihren” Teil der Lösung.
In den folgenden Beispielen wird gezeigt, wie die Micro-Tenancy von vManage umgesetzt wird – via dem fiktiven Kunden “British Airways” der mittels RBAC Steuerung in einzelne Bereiche unterteilt wurde. Der jeweilige Regionen Admin hat nur Zugriff auf seine lokale Umgebung.
Die folgenden Folien zeigen weitere Aspekte der RBAC Steuerung in vManage. Der lokale Admin hat Zugriff auf diverse Parameter in seiner Umgebung, inkl. des Datenaufkommens auf “seinen” Leitungen.
Fazit zu Single – und Micro-Tenancy
Die Single-Tenancy eignet sich als Einstieg in Szenarien, bei denen ein einzelner Kunde eine einzige SD-WAN Domain pflegt und keine weitere Unterteilung benötigt wird.
Das Micro-Tenancy Konzept eignet sich für alle Firmen oder Service-Provider, die verschiedene Kunden, Organisations-Einheiten oder Regionen mit lokalen Admins abbilden möchten. Der Vorteil ist, das jeweils das gleiche Head-End als geteilte Ressource verwendet werden kann, damit können die Kosten für die benötigte Hardware klein gehalten werden. Ein weiterer Vorteil ist, dass die Micro-Tenancy Variante nur eine Konfiguration-Anpassung benötigt, es kann daher bei Bedarf auch von Single- zu Micro-Tenancy umgestellt werden.
Im nächsten Teil schauen wir uns die Variante der Multi-Tenancy an, die mit IOS-XE 17.4 eingeführt wird.
Tags:
1 Kommentare