Cloud Computing löst nicht alle Probleme automatisch…

..., im Gegenteil, es schafft zunächst Probleme! Vor allem dann, wenn man selber als Anbieter Cloud Computing Services bereitstellen möchte.

Es ist ein Irrglaube, wenn man denkt, dass der Aufbau einer Private Cloud impliziert, sich anschließend nicht mehr um die Hochverfügbarkeit der eigenen Infrastruktur (physikalische Maschinen, virtuelle Maschinen, Master-Slave-Replikation, Hot-Standby, etc.) kümmern zu müssen. Das macht dann ja schließlich die Cloud alleine.

Achtung!!! Die Cloud bereitet einem (Private) Cloud Betreiber beim Aufbau zunächst mehr Probleme als man denkt.

Eine Cloud funktioniert nicht von alleine. Sie muss entwickelt und mit Intelligenz ausgestattet werden. Das gilt für den Aufbau einer Private Cloud genau so wie für die Nutzung eines Public Cloud Angebots (im Falle von IaaS). Dazu müssen Skripte geschrieben, womöglich Software neu entwickelt werden, die auf der Cloud verteilt läuft. Weiterhin ist es wichtig, die Whitepaper des jeweiligen Anbieter zu lesen, KnowHow(!) aufzubauen und zu verstehen, wie die Cloud arbeitet, um sie für die eigenen Bedürfnisse nutzen zu können. Eine weitere Möglichkeit besteht natürlich darin, sich (zusätzlich) von Profis beraten zu lassen.

Das ist bspw. bei der Nutzung des Public Cloud Angebots der Amazon Web Services auch nicht anders. Wenn eine Instanz A ein Problem hat, dann kann sie plötzlich nicht mehr erreichbar sein, wie jeder normale physikalische Server nun einmal auch. Nun könnte man denken: "Dann nehme ich als Backup für Instanz A halt noch eine Instanz B dazu!" Und dann? Man könnte nun denken, dass die Instanz B automatisch die Aufgaben der Instanz A übernimmt. So einfach ist das aber nicht!

Skripte etc. müssen vorab dafür sorgen, dass die Instanz B die Aufgaben von Instanz A übernehmen soll, wenn diese plötzlich nicht mehr erreichbar ist. Auch die Instanz B muss dafür zunächst vorbereitet werden.

Dazu kann z.B. der eigentliche (wichtige) Inhalt der Instanz A inkl. aller Konfigurationen etc. in ein EBS (Elastic Block Store) und nicht auf dem lokalen Instanzspeicher gespeichert werden. Anschließend muss ein Skript dafür sorgen, dass die Instanz B automatisch mit den Konfigurationen und allen Daten aus dem EBS hochgefahren wird, wenn die Instanz A nicht mehr verfügbar ist.

Die Cloud gibt uns im Bereich Infrastructure as a Service letztendlich nur die Möglichkeit, aus einem quasi unendlich großen Pool von Ressourcen die (unendliche) Anzahl an Ressourcen zu dem Zeitpunkt zu bekommen, wenn wir sie benötigen. Wir erhalten von dem Anbieter somit ein eigenes hochskalierbares virtuelles Rechenzentrum. Das bedeutet aber im Umkehrschluss für den Betreiber einer Cloud (Private, Public), dass er ebenfalls die Menge an physikalischen Ressourcen vorhalten muss, damit die angefragten virtuellen Ressourcen jederzeit bereitgestellt werden können und damit immer ausreichend Ressourcen für die Nutzer zur Verfügung stehen.

Share on: