In MSP- und Service-Provider-Umgebungen ist die Verwendung einer separaten Appliance für jeden Kunden kostspielig, schwer zu verwalten und kapazitätstechnisch ineffizient. Aber alle Kunden auf einem einzigen Gerät nur mit einer Namens- oder Ordnertrennung zu betreiben, reicht ebenfalls nicht aus. Wenn Verkehrs-, Log-, Netzwerk-, Ressourcen- und Berechtigungsgrenzen nicht klar getrennt sind, können Tenants einander beeinflussen.
In Umgebungen, die Compliance erfordern, wird diese Trennung noch kritischer. Wenn verschiedene Sicherheitsbereiche wie PCI, Gesundheitsdaten oder Behördenklassifizierung auf derselben physischen Ressource laufen sollen, muss nachweisbar sein, welcher Tenant auf welche Ressourcen, welches Netzwerk und welche Logs zugreifen kann. Eine reine softwareseitige Kennzeichnung reicht in den meisten Szenarien nicht aus, um Vertrauen zu schaffen.
In mandantenfähigen Strukturen erzeugt auch der Ressourcenverbrauch ein Betriebsrisiko. Die Anzahl der Verbindungen, die Verkehrsdichte, das Log-Volumen oder eine fehlerhafte Konfiguration eines Tenants dürfen die Leistung anderer Tenants nicht beeinträchtigen. Daher müssen CPU, Speicher, Festplatte, Netzwerkschnittstelle und Flusslimits auf Tenant-Ebene geplant werden.
Der richtige Ansatz ist, jeden Tenant als separaten Arbeitsbereich zu behandeln und Ressourcen-, Netzwerk-, Log-, Audit- und Verwaltungsberechtigungen nach der Tenant-Grenze zu trennen. Die Tenant-Isolation muss nicht nur auf UI-Ebene, sondern auch auf der Verkehrs- und Ressourcenebene umgesetzt werden.
Die TR7 vTenant-Virtualisierung bietet dieses Modell: Beim Betrieb mehrerer Tenants auf einem einzigen TR7 macht sie Ressourcen-, Netzwerk- und Betriebsgrenzen separat verwaltbar.
Die TR7-vTenant-Architektur wird mit einem Ansatz aus unabhängigem Arbeitsbereich pro Tenant, zugewiesenen Netzwerkressourcen, isoliertem Verkehrskontext und Ressourcenkontingent aufgebaut.
Ein vTenant ist ein unabhängiger Arbeitsbereich mit eigener Verwaltungs- und Verkehrsgrenze innerhalb eines einzigen Geräts. Jeder Tenant kann seine eigenen Services, seinen Netzwerkkontext, seine Logs und seine Ressourceneinstellungen getrennt von anderen Tenants nutzen.
Physische Schnittstellen können mit den Tenants zugewiesenen virtuellen Funktionen oder Slot-Strukturen geteilt werden. So empfängt jeder Tenant den Verkehr über seine eigene Netzwerkoberfläche und vermischt sich nicht mit dem Verkehr anderer Tenants.
Jeder Tenant kann seinen eigenen IP-, Route-, Firewall- und Schnittstellenkontext haben. Dieselben IP-Bereiche können in verschiedenen Tenants ohne Konflikt verwendet werden, und der Verkehr wird nach der Tenant-Grenze ausgewertet.
Für jeden Tenant können Prozessorkerne, Speicher, Festplattenplatz und Verbindungs-/Flusslimits geplant werden. Dieses Modell verringert, dass der Ressourcenverbrauch eines Tenants andere Tenants beeinflusst.
Die vTenant-Virtualisierung trennt die Multi-Tenant-Struktur auf Ressourcen-, Netzwerk-, Identitäts-, Log- und Betriebsebene.
Jeder vTenant wird als separater Arbeitsbereich verwaltet. Die innerhalb eines Tenants definierten vService-, Zertifikats-, Regel-, Netzwerk- und Log-Strukturen bleiben innerhalb ihrer eigenen Grenzen. MSPs und Service Provider können verschiedene Kunden auf demselben TR7 nebeneinander betreiben. Dieses Modell reduziert die Anzahl der physischen Geräte und bewahrt zugleich die Betriebsisolation.
Jeder Tenant kann mit einem separaten Lifecycle-Verhalten verwaltet werden. Ein Tenant kann gestartet, gestoppt, neu gestartet oder mit Autostart-Verhalten konfiguriert werden. Das sorgt dafür, dass während der Wartung an einem Tenant die anderen Tenants nicht beeinträchtigt werden. Betriebsteams können kunden- oder umgebungsbasierte Wartungsfenster durchführen.
TR7 kann den Tenants zuweisbare CPU-Kerne unter Berücksichtigung der für den Host reservierten Kerne planen. Kritischen Tenants können mehr Prozessorressourcen zugewiesen werden, Tenants mit geringer Last können mit begrenzteren Ressourcen betrieben werden. Das verringert, dass intensiver Kundenverkehr die Steuerungsebene anderer Tenants beeinflusst. Die Ressourcenverwaltung wird Teil der Kapazitätsplanung.
Für jeden Tenant können eine separate Arbeitsfestplatte und ein separater Rohdatenbereich reserviert werden. Es kann mit Standardwerten begonnen werden, mit steigendem Bedarf kann pro Tenant geplant werden. Logs, Berichte, Konfiguration und temporäre Daten werden innerhalb der Tenant-Grenze gehalten. Diese Struktur ist für Compliance und betriebliche Datentrennung wichtig.
Aus physischen Netzwerkschnittstellen können den Tenants virtuelle Funktionen zugewiesen werden. Jeder Tenant empfängt und sendet Verkehr über seinen eigenen Schnittstellen-Slot. Dieser Ansatz bietet eine stärkere Verkehrstrennung als softwareseitige Kennzeichnung. Bei Tenants mit hoher Last bleiben Leistung und Isolation gemeinsam erhalten.
Auf den einem Tenant zugewiesenen Schnittstellen können Trust- und Spoof-Kontrolleinstellungen verwaltet werden. Das sorgt dafür, dass der Tenant sein eigenes MAC- und Verkehrsverhalten innerhalb der erwarteten Grenzen nutzt. Besonders in mandantenfähigen Netzwerken werden falsche oder kollidierende Adressverhalten frühzeitig unter Kontrolle gebracht. Die Netzwerksicherheit wird zum natürlichen Teil der Tenant-Grenze.
TR7 kann mit der macprefix- und Slot-Struktur eindeutige MAC-Adressen für Tenant-Schnittstellen erzeugen. Dieses Modell sorgt durch die Kombination von 3-Byte-Präfix und Tenant-/Slot-Information für eine geordnete Adressierung. Wenn auf demselben Gerät zahlreiche Tenants und Schnittstellen definiert sind, sinkt das Konfliktrisiko. Das Netzwerkteam verfolgt die Tenant-Schnittstellen besser lesbar.
TR7 plant Tenant- und Schnittstellenkapazität mit den Bitfeldern für Device, Zone und Interface. Das 6-Bit-Zone-Feld bietet ein Adressierungsmodell für bis zu 64 Tenants, das 5-Bit-Interface-Feld für bis zu 32 Schnittstellen pro Tenant. Diese Struktur ermöglicht eine geordnete Skalierung in großen MSP- und Multi-Environment-Installationen. Das Tenant-Wachstum wird von Anfang an an ein vorhersehbares Kapazitätsmodell gebunden.
Jeder Tenant kann seine eigene IP-, Route-, Firewall- und Schnittstellenansicht haben. Dieselben privaten IP-Bereiche können in verschiedenen Tenants ohne Konflikt verwendet werden. Das verringert das klassische RFC1918-Adresskonfliktproblem in Multi-Customer-Umgebungen. Der Verkehr wird im Tenant-Kontext ausgewertet und vermischt sich nicht mit dem falschen Netzwerkbereich.
Der Log- und Audit-Strom jedes Tenants kann separat behandelt werden. Die Betriebsaufzeichnungen eines Tenants sind für einen anderen Tenant nicht sichtbar. Diese Trennung ist für Kundenvertraulichkeit, Compliance und Vorfalluntersuchungsprozesse von kritischer Bedeutung. Auf der zentralen Verwaltungsebene können berechtigte Benutzer tenant-basierte Berichte erstellen.
Mit kontrolliertem Befehlsversand in den Tenant können Lifecycle-, Gesundheits- und Diagnosevorgänge durchgeführt werden. Das ermöglicht beim tenant-spezifischen Problemstudium oder bei Wartungen den Betrieb, ohne das gesamte Gerät zu beeinflussen. Die Befehlsberechtigungen können mit RBAC und Audit eingeschränkt werden. Support-Teams diagnostizieren im Tenant-Kontext schneller.
Die Central-Management-Seite kann Tenants gesammelt sehen und verwalten. Mit RBAC kann eingeschränkt werden, welchen Tenant Benutzer sehen oder ändern können. In MSP-Szenarien kann eine kundenbasierte Berechtigungstrennung vorgenommen werden. Verwaltungskomfort und Tenant-Vertraulichkeit bleiben im selben Modell erhalten.
Der vTenant-Betrieb wird zusammen mit Standard-Festplattenwerten, CPU-Planung, Bitfeldern, Verwaltungs-IP-Modell, Schnittstellenzuweisung und MAC-Adresserzeugung betrieben.
Für jeden Tenant können eine Standard-Arbeitsfestplatte und ein Rohdatenbereich definiert werden. Mit Startwerten von standardmäßig 20 GB für die Arbeitsfestplatte und 30 GB für den Rohdatenbereich erfolgt eine schnelle Einrichtung; die Kapazität kann je nach Produktionslast erhöht werden. Das Log- und Berichtsvolumen muss bei der Festplattenplanung gesondert berücksichtigt werden.
Von der Gesamtzahl der Kerne wird die für den Host reservierte Reserve abgezogen, um einen den Tenants zuweisbaren Kernpool zu bilden. Kritischen Tenants können mehr Kerne zugewiesen werden. Dieses Modell verbindet die Ressourcenisolation mit der Kapazitätsplanung.
Die Bitfelder für Device, Zone und Interface bilden ein Adressierungsmodell von insgesamt 12 Bit. Das 6-Bit-Zone-Feld bietet eine Kapazität von 64 Tenants, das 5-Bit-Interface-Feld eine Kapazität von 32 Schnittstellen pro Tenant. Diese Werte klären den Skalierungsplan bei großen Installationen.
Für jeden Tenant kann eine lokale IP zu Verwaltungszwecken erzeugt werden. Diese IP kann in Tenant-Lifecycle-, Gesundheits- und internen Verwaltungsabläufen verwendet werden. Der Verwaltungsverkehr muss vom Tenant-Datenverkehr getrennt behandelt werden.
Auf den einem Tenant zugewiesenen Schnittstellen können Informationen wie Slot, VF-Anzahl, MAC-Bereich und MTU gehalten werden. Dieses Modell sorgt für eine geordnete Verteilung der physischen Netzwerkressourcen an die Tenants. Beim Ändern des Slot-Plans muss die Netzwerkauswirkung sorgfältig bewertet werden.
Über ein 3-Byte-macprefix werden durch Hinzufügen von Tenant- und Slot-Information eindeutige MAC-Adressen erzeugt. Diese Struktur verringert Adresskonflikte und erleichtert das Nachverfolgen, zu welchem Tenant eine Schnittstelle gehört. Sie sorgt für Lesbarkeit im Netzwerkbetrieb.
Ein Service Provider kann 30 Kunden als separate vTenants betreiben. Jeder Kunde erhält seinen eigenen Netzwerk-, Log-, Regel- und Ressourcenbereich; der Betrieb wird auf einem einzigen Gerät vereinfacht.
Der Tenant, der Kartendaten verarbeitet, und der Tenant für Unternehmens-Webverkehr können auf demselben TR7 als getrennte Arbeitsbereiche laufen. Die Trennung von Ressourcen, Netzwerk und Audit stärkt den Compliance-Nachweis.
Gesundheitseinrichtungen können Test-, Entwicklungs- und Produktionsverkehr in separaten Tenants halten. Produktions-Patientendaten und Entwicklungsverkehr werden, während sie aus demselben Betriebspanel verwaltet werden, voneinander getrennt.
Behörden können Services unterschiedlicher Sicherheitsstufen in separaten Tenants betreiben. Netzwerk, Logs und Zugriffsberechtigungen werden pro Tenant getrennt, sodass das Risiko eines falschen Zugriffs verringert wird.
Auf demselben TR7 können Test-, Staging- und Produktions-Tenants erstellt werden. Anwendungsänderungen werden vor der Überführung in die Produktion mit ähnlichem ADC-/WAAP-Verhalten validiert.
Eine Tenant-Struktur für MSP-, Banking-, Gesundheits- und Behördenumgebungen mit Ressourcen-, Netzwerk- und Betriebsisolation. Lassen Sie uns eine Live-Demo in Ihrer eigenen Installation durchführen.