Aufbau einer Hybrid Cloud
Was kostet die Wolke?
Das Cloud Computing verspricht Rechen-Power, ohne lange Server aufsetzen zu müssen. So einfach das auch klingt, sind doch zuvor einige Aspekte gründlich zu planen. Wenn der Anwender nicht nur eine Testplattform installieren, sondern wirklich produktiv damit arbeiten will, sollten folgende Themen Berücksichtigung finden: Welche Workloads lassen sich überhaupt auslagern, wer erhält darauf Zugriff, und wie erfolgt die Abrechnung?
Bei der Frage, welche Systeme ein Unternehmen auslagern kann, kommen aus technischer Sicht zunächst solche in den Sinn, die sich leicht kategorisieren lassen. Wenn zum Beispiel ein Prozess in regelmäßigen Abständen (monatlich, jährlich) auftritt und sonst nicht erforderlich ist, sind die betreffenden Prozesse gute Kandidaten, zum Beispiel eine sehr rechenintensive Kalkulation von Quartalsabschlüssen. Auch permanent gleichartige Prozesse können als Kategorie in Frage kommen. Wenn man die Unternehmens-Website auslagern kann, warum nicht auch einen unkritischen Dienst? Die Einstufung, was als kritisch gilt, sollte allerdings in Zusammenarbeit zwischen dem Prozessverantwortlichen (Process Owner) und dem IT-Bereich erfolgen, da dies nicht immer offensichtlich ist. Häufig lagern Unternehmen zudem Test- und Entwicklungssysteme aus. Denn ständige Bereitschaft verschiedener Betriebssysteme, möglichst auf unterschiedlichen Patch-Leveln und mit diversen Applikationen, nur um damit ab und an zu testen, verursacht schnell allein durch Lizenzen und Hardware hohe Kosten.
Die Art der auszulagernden Applikation oder des Prozesses beeinflusst die benötigte Art der Cloud. Von IaaS über PaaS bis SaaS (Infrastructure, Platform, Software as a Service) lassen sich bei den Cloud-Providern inzwischen alle gewünschten Formen finden. Einen Überblick kann man sich unter anderem mit der Studie der Experton Group [1] verschaffen. Neben großen, internationalen SaaS-Anbietern wie Microsoft, Google und Amazon finden sich inzwischen auch Angebote von eher technologiegeprägten Anbietern wie IBM, Fujitsu und HP. Nur wenige der Anbieter betreiben bislang Rechenzentren in Deutschland. Wer Wert auf den Standort legt, kann sich aber inzwischen auch bei deutschen Anbietern wie T-Systems oder Pironet NDH nach passenden Angeboten umschauen [2].
Abhängig davon, welche Kategorie von Systemen ein Unternehmen auslagern will, sind weitere Überlegungen anzustellen. Liegen auf den ausgelagerten Systemen nicht nur Testdaten, gilt es, diese mit in das Backup-Konzept einzubeziehen. Dabei darf ein Unternehmen neben den Daten die eigentlichen virtuellen Maschinen (VMs) nicht vergessen. Bei den Public Cloud Providern lassen sich diese Services inklusive SLA (Service Level Agreement) einfach mitbuchen.
Der Planer sollte zudem die Frage nicht vergessen, wie man gegebenenfalls von einem Provider zum nächsten umzieht. Häufig kommen gerade dann bessere Angebote auf den Markt, wenn die Umstellung gerade vollzogen ist. Idealerweise bietet der Provider der Wahl dann den Download oder Export der VMs inklusive Daten an. Bietet ein Provider diese Option nicht, sollte der verantwortliche Architekt gut überlegen, ob er überhaupt einen solchen Vertrag abschließen oder lieber den Anbieter von der Auswahl ausnehmen will.
Einfacher ist die Lage, wenn von vornherein der Beschluss steht, auf die Nutzung öffentlich zugänglicher Angebote zu verzichten und die "Wolke" selbst zu betreiben oder beim Hoster der Wahl zu installieren. Dagegen steht, dass der Installations- und Betriebsaufwand für die Inhouse-Cloud im Unternehmen bleibt und ein Teil des Cloud-Vorteils verloren geht. Einen solchen Business Case sollte der Architekt der Geschäftsführung gegenüber gut begründen können.
Ein gewichtiger Grund könnte sein, dass ein Unternehmen betroffene Daten aufgrund von internen Vorschriften, Gesetzen oder Vorgaben des BSI oder BMWI gar nicht aus dem Haus geben darf. Der Datenschutz und die entsprechenden Beauftragten im Unternehmen nehmen bei allen Überlegungen daher eine zu berücksichtigende Position ein. Welche Aspekte zu beachten sind, wenn man den IT-Grundschutz des BSI anwenden möchte, können Interessierte den aktuellen Vorabversionen der Bausteine zur Cloud-Nutzung und Management entnehmen [3].
Zugriffskontrolle
Sollten nach den Vorabüberlegungen und Beschränkungen Dienste übrig bleiben, die man in die Cloud übertragen darf, und sollte der Vorstand den Business Case abgesegnet und die notwendigen Budgets freigegeben haben, dann stehen wieder technische Belange im Vordergrund. Je nach notwendiger Anbindung und Provider gibt es grundsätzlich zwei Möglichkeiten, die Cloud-Systeme zugänglich zu machen: Entweder koppelt ein Unternehmen das virtuelle Netzwerk direkt über die Firewall mit dem internen Netzwerk, oder man stellt VPN-Verbindungen zur Verfügung. Beide Methoden haben ihre Vor- und Nachteile. Auf jeden Fall gilt es auf eine redundante Auslegung zu achten, wenn es sich um unternehmenskritische Applikationen handelt. Eine Subnetzkopplung kann das Management der Verbindungen deutlich vereinfachen. Datenströme lassen sich dann zwischen lokalen ("On-Premise"-) und Cloud-Systemen routen. Bei VPN-Verbindungen muss die IT-Organisation gegebenenfalls jeden Anwender und jedes Gerät separat anbinden.
Dies hat auch Auswirkungen auf die Kontrolle der Zugänge. Der manuelle Aufwand, einzelne Benutzer zu berechtigen, ist deutlich höher, als wenn dies über Regeln und zum Beispiel Active-Directory-Rollen teilautomatisiert geschieht. Auch lässt sich über Tools wie Microsoft System Center bei einer Kopplung ein Self-Service-Portal etablieren, aus dem sich Endanwender nach Bedarf jederzeit selbst mit neuen VMs und Services bedienen können. Führt ein Unternehmen ein Portal ein, muss es aber auch ein entsprechendes Verrechnungsmodell mit bedenken, da alle Services über einen Abrechnungskonto mit dem Provider verrechnet werden. Die Festlegung der Metriken erfolgt im Regelfall in Abstimmung zwischen der IT-Abteilung und den Endanwendern im Unternehmen, da beide Seiten die Inhalte verstehen und intern zuordnen können müssen.
Einen weiteren Vorteil bietet die Anbindung über separierte Verbindungen hinsichtlich der Zugangssicherheit. Fehlgeleitete Datenströme, Man-in-the-Middle-Angriffe oder Eindringversuche in Cloud-Subnetze aus kompromittierten Drittnetzen sind leichter zu erkennen und zuzuordnen, wenn auch nicht unbedingt leichter zu verhindern.
Verrechnung
Die Verrechnung der genutzten Cloud-Ressourcen kann unter Umständen sehr mühsam sein. Fällt für die Nutzung eine monatliche Pauschale an, kann die IT-Abteilung die Gesamtsumme einfach durch die Anzahl der Nutzer teilen und pro Kopf auf die Endverbraucher umlegen. Aber spätestens dann, wenn der erste Endkunde mit wenig Last den Vergleich mit einem Nutzer mit hoher Last anstellt, wird diese Methode Probleme bereiten. Als Alternative kann die IT eine Trennung der Anbindungen vornehmen und für jeden Endverbraucher eine separate Verbindung anlegen. Dies ist aber mit sehr viel höherem Implementierungs- und Betriebsaufwand für die IT-Abteilung verbunden. Auch wenn dies einen gangbaren Weg darstellt, ist es nicht unbedingt zu empfehlen.
Sofern der Cloud-Provider die Option nicht schon selbst in seinem Portal anbietet, besteht die Möglichkeit, mit ein bisschen anfänglichem Mehraufwand Chargeback-Systeme zu nutzen. Da man nicht im RZ eines Cloud-Providers beliebig Installationen durchführen darf, um seine Abrechnung zu sortieren, gibt es am Markt spezialisierte Anbieter, die Abrechnungsdaten nach vorgegebenen Spezifika sortieren und daraus Reports erstellen. Die zusätzlichen Kosten für einen solchen Dienst können sich bei einer ausreichend hohen Auslastung der Cloud rechnen.
Beispielsweise kann eine IT-Organisation eine Citrix-Cloud-Farm im eigenen Rechenzentrum mit Hilfe einer auf Apache Cloudstack basierenden Umgebung zu einer elastischen IaaS-Infrastruktur erweitern. Die Installation erlaubt neben der Bereitstellung von Service-Portalen zur Ausbringung virtueller Maschinen die Möglichkeit, umfassende Verrechnungs- und Reporting Tools einzusetzen. Einige Public Cloud Hoster setzen die Apache Cloudstack Tools ebenfalls ein, da sie unter der Apache-Lizenz verfügbar sind.
Auf diesen Prozess spezialisiert ist Amysta [4]. Der Anbieter stellt gegen Gebühr das Programm Chargeback zur Verfügung, das Dashboards enthält, die der Abnehmer anpassen kann. In der Regel nimmt die IT-Abteilung diese Anpassung vor, die anschließend das konfigurierte Dashboard dem Endbenutzer im Unternehmen bereitstellt. Die Dashboards können für alle Arten der Cloud zum Einsatz kommen, um eine Kostenkontrolle und Verrechnung zu etablieren. Es existieren neben Citrix auch andere Technikpartnerschaften, zum Beispiel mit Amazon Web Services (AWS).
Neben dem Apache Cloudstack gibt es noch weitere Abrechnungsapplikationen, die ein Unternehmen in seiner Private Cloud installieren kann. Je nach vorherrschendem Technologie-Stack kann der IT-Architekt Tools einplanen, die die Ressourcennutzung der Private-Cloud-Systeme überwachen und nach einstellbaren Metriken Reports erstellen. Sowohl VMware Vcenter als auch Microsoft System Center lassen sich entsprechend erweitern. Bei der VMware-Lösung ist in Vcenter der zusätzliche Chargeback Manager im Vcloud Director oder die Vrealize Business Suite zu implementieren [5]. Damit lassen sich Kosten für unterschiedliche Systeme und Komponenten der Installation einstellen und als Reports ausgeben.
Eine ähnliche Anpassung ist bei Microsofts System Center notwendig, um die Ressourcen sauber abrechnen zu können [6]. Der Administrator muss verschiedene Komponenten (SCVMM, SCOM, SM, Orchestrator) bei der Implementierung anpassen und aufeinander abstimmen, um die Verrechnungsprozesse zu implementieren. Ab Version 2012 SP1 beinhaltet der Orchestrator das notwendige Service Provider Framework. Mit diesem und dem ehemals "Katal" genannten Azure Pack kann die IT-Abteilung dann Reports erzeugen. Wenn die Tools laufen, steht der Identifizierung von Opex, Capex sowie direkten und indirekten Kosten nichts mehr im Wege.
Bei der Auswahl der zu überwachenden und abzurechnenden Ressourcen muss man noch die passenden Parameter auswählen. Je nach Art der Prozesse und Systeme können unterschiedliche sinnvoll sein, zum Beispiel eine Abrechnung pro VM und Zeit, pro Datenvolumen und Zeit oder einfach pro verwendeter Datenmenge. Aber auch komplexere Systeme können Anwendung finden, etwa die Anzahl der genutzten Verbindungen oder die Anzahl der Speichertransaktionen.
Der Aufwand für die Implementierung einer Chargeback-Lösung sollte allerdings angemessen sein. Die Flexibilität der Cloud erlaubt es ja, kurzfristig neue Ressourcen zu erstellen und einem Endanwender zuzuweisen. Jedes Mal zusätzlichen Aufwand für die Abrechnung aufzubringen, wäre nicht sehr wirtschaftlich und lohnt sich meist nur unter sehr speziellen Bedingungen. Für einen produktiven Betrieb muss ein Unternehmen die gesamte Architektur eines Cloud-Systems inklusive aller Prozesse, Sicherheitsanforderungen, des Accountings und der Governance sorgfältig planen. Sobald es einen der Aspekte vernachlässigt, kann sich die Cloud schnell als Kostenfaktor statt als nützliche Erweiterung der lokalen IT erweisen.
Lesen Sie mehr zum Thema
