Cloud-Architekturen Multi-Instanz- versus Multi-Tenancy-Systeme

Für manche Szenarien ist eine Cloud mit Multi-Tenancy-Architektur nicht gemacht. Insbesondere bei hohen Sicherheitsanforderungen können andere Ansätze sinnvoller sein, meint der Anbieter ServiceNow.

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

Cohesity GmbH

Schwarz IT KG

ServiceNow

Die ersten Cloud-Dienste der 1990er-Jahre bauten auf Datenbanksystemen auf, die für Flugreservierungen, Kundenservice oder Finanzsysteme entwickelt wurden. Diese Datenbanksysteme wurden für alle Kunden auf zentralen Rechen-, Speicher- und Netzwerksystemen gehostet.

Diese Art von Cloud-Struktur wird als Multi-Tenancy-Architektur bezeichnet und bis heute am häufigsten verwendet. In der Multi-Tenancy-Architektur teilen alle Nutzer dieselbe Software, Hardware sowie Infrastruktur. Zugleich profitiert der Betreiber von einem großen zentralisierten System. Um die Kapazitäten einer Multi-Tenancy-Cloud zu erweitern, werden zusätzliche Hardwarekomponenten benötigt.

Im Gegensatz dazu haben Nutzer der Multi-Instanz-Cloud jeweils eine eigene Basis-Instanz. Die Datenbank-Instanzen sind hier wie einzelne Stockwerke eines Hochhauses angeordnet und können horizontal beliebig skaliert werden – ohne Einsatz von weiteren Komponenten. Auf dieser Infrastruktur basieren Enterprise-Cloud-Systeme.

Mitbewerberdaten in einem System

In Multi-Tenancy-Architekturen befinden sich die Daten aller Nutzer in nur einem einzigen System. Selbst wenn kein Unternehmen die Informationen seiner Mitbewerber einsehen kann, werden die Daten dennoch nur durch eine Softwarelösung voneinander getrennt.

Das kann bei sensiblen Informationen, besonders im Gesundheits-, Finanz- und Behördenbereich weitreichende Folgen haben. Es besteht ein erhöhtes Risiko, dass im Fall eines Sicherheitsverstoßes bei nur einem Nutzer, alle anderen Nutzer ebenfalls geschädigt werden. Da Nutzer einer Multi-Instanz-Cloud eigenen Basis-Instanzen zugeordnet sind, werden ihre Daten nicht nur separat verwaltet.

Upgrades

Da sich Nutzer in Multi-Tenancy-Architekturen eine Datenbank teilen, bekommen sie dieselben Upgrades zur selben Zeit. Wer wenig eigenen Verwaltungsaufwand bevorzugt, ist damit gut bedient.

Für manch ein Unternehmen kann das wiederum problematisch sein, vor allem, wenn unternehmensweit laufende Dienstleistungen mit geschäftskritischen Anwendungen betroffen sind. Außerdem wollen einige Firmen den Zeitpunkt eines Upgrades aus Planungs- sowie Compliance-Gründen selbst bestimmen. In einer Multi-Instanz-Umgebung lassen sich Upgrades in der Basis-Instanz durchführen.

Wartungsarbeiten

Ähnlich verhält es sich mit Wartungsarbeiten in Multi-Tenancy-Architekturen. Da es sich hier um sehr große und komplexe Datenbanken handelt, sind Hard- und Softwarewartungen in regelmäßigen Abständen notwendig. Problematisch wir es dann, wenn die Wartungsarbeiten Nichtverfügbarkeiten mit sich bringen.

Anwendungen auf Abteilungsebene können durchaus Ausfallzeiten tolerieren, zumindest solange sie außerhalb der Arbeitszeiten stattfinden. Bei unternehmenskritischen Prozessen sind allerdings möglichst hohe Verfügbarkeiten unerlässlich.

Disaster Recovery

Multi-Instanz-Architektur gewährleistet Hochverfügbarkeiten von mehr als 99.995%. Kopien aller Kunden-Instanzen werden nahezu in Echtzeit erstellt und befinden sich in einem separaten Rechenzentrum. Dieses Replikat ist aktiv und voll funktionsfähig.

So wird ein Disaster-Recovery-System unnötig, weil die Datenbank und ihre Kopie in verschiedenen, geographisch voneinander getrennten Rechenzentren zeitgleich funktionieren. Der Wechsel zwischen den Rechenzentren kann sehr schnell durchgeführt werden, sodass Wartungsarbeiten der Enterprise-Cloud im Quartal höchstens sechs bzw. weniger als zwei Stunden im Monat beanspruchen.

Die Multi-Instanz-Architektur bietet nicht nur Hochverfügbarkeit, sondern gibt seinen Nutzern die Kontrolle über ihre Cloud. Unternehmen können Upgrades individuell nach ihren Bedürfnissen planen. Aufgrund der Isolierung von Daten anderer Nutzer entstehen zudem keine Compliance-Konflikte.

* Georg Goller ist Area Vice President Deutschland bei ServiceNow.

(ID:43975994)