Die Cloud-Computing-Plattform CloudStack steht kurz vor ihrer fünften Hauptversion – ganz schön fleißig, schließlich ging sie erst 2010 open source. Wir haben Projektmanagement-Member Giles Sirett gebeten, uns CloudStack mal genauer vorzustellen.

Der Apache CloudStack ist eine bewährte multi-tenancy Infrastruktursteuerung, die die Bereitstellung und Verwaltung von Netzwerk-, Speicher- und Rechenkomponenten kontrolliert. Sie stellt ein HTTP-API zur Verfügung, das es Systemadministratoren erlaubt, ihre Datencenter programmatisch bereitzustellen und zu managen. Dieses API wird dazu verwendet, verschiedene Konfigurationsmanagement-Tools, wie Ansible, Puppet, Chef oderTerraform, in das CloudStack-Infrastrukturmanagement zu integrieren. Dadurch können DevOps-Teams nahtlos Rechen-, Speicher- und Netzwerkressourcen zur Verfügung gestellt und den Applikationen zugewiesen werden.

Die CloudStack-Steuerebene automatisiert die effiziente Aufteilung und das Balancing der Datencenterressourcen. Sie unterteilt die Infrastruktur in Partitionen (z. B. nach Regionen, Zonen, Pods oder Clustern), die Ausfallgründe aufteilen und somit die Applikationsstabilität erhöhen. Wir haben die folgenden Ziele für das Design und die Weiterentwicklung:

• Infrastrukturnormierung: CloudStack bietet viele Abstraktionen, die Infrastrukturkomponenten wie Hypervisors, Netzwerkgeräten, Container-Runtimes und Speichergeräten ein herstellerunabhängiges Interface geben. Sie ermöglichen die einheitliche Verwaltung von Infrastrukturen, die aus verschiedenen Komponententypen zusammengesetzt sind.
• Trennung von Kontrollebene und Datenebene: CloudStack trennt Operationen strickt von Datenübertragungen, die Infrastrukturkomponenten kontrollieren (wie das Erstellen einer virtuellen Maschine, das Vergrößern eines Volumes oder das Aufnehmen eines Screenshots). Das Design garantiert die Lebendigkeit automatisierter Kontrolle, indem hohe Latenzen verhindert werden und große Übertragungen davon abgehalten werden, die Zustellung und Verarbeitung von Managementoperationen mit niedriger Latenz zu beeinträchtigen.
• Operative Einfachheit: CloudStack verschiebt den User-Fokus durch die Betonung der Einfachheit von Deployment und Upgrade von Infrastrukturwartung zu Servicepotenzial. Beispielsweise weist CloudStack I/O-intensiven Operationen, z. B. Netzwerk-Routing oder Secondary Storage Transfer, automatisch neuerstellte virtuelle Maschinen zu, um die Auslastung zu senken.

2008 regte Amazon EC2 cloud.com dazu an, das CloudStack-Projekt als privaten, self-service, Infrastructure-as-a-Service (IaaS)-Dienst für private Firmen ins Leben zu rufen. Im ursprünglichen Konzept sollten virtuellen Maschinen zugewiesene „low churn“-Workloads die primären Rechenleistungen übernehmen. Seit dieser Zeit hat sich der CloudStack weiterentwickelt um Bare-Metal-Server, die Hypervisors und Big-Data-Plattformen, wie Apache Hadoop, Riak und Apache Spark, deployen, bereitstellen und managen zu können. Heutzutage werden containerisierte „high churn“-Workloads durch die Einbettung von Container-Management-Plattformen unterstützt, wie Kubernetes, Docker Swarm, Mesos DC/OS. Diese auf CloudStacks grundliegenden Abstraktionen aufbauenden, zusätzlichen Rechenmodelle verhelfen einem kampferprobten Kontrollmodell zum Durchbruch, das über viele Netzwerktopologien und Speicherinfrastrukturen kommuniziert.

2011 wurde cloud.com von Citrix erworben und 2012 wurden sämtliche Trademarks und der Source Code an die Apache Software Foundation (ASF) übergeben. Diese Schenkung transferierte die Projektverantwortung von einem Anbieter zur Community und bot damit die nötige Transparenz, um die zukünftige Richtung des Projekts festzulegen. Jeder kann sich in der Apache CloudStack Community einbringen. Alle Beiträge erfahren eine gleichwertige Berücksichtigung – basierend auf den enthaltenen Leistungen und nicht der gespendeten Menge Geld. Heutzutage entwickeln hunderte Community-Mitglieder neue Features und unterstützen uns via Slack, IRC oder Mailinglisten mit tausenden Nachrichten pro Monat.

CloudStack findet sich in Service-Angeboten von vielen Cloud-Anbietern wieder, wie Datapipe, BT und Exoscale. Unternehmen und öffentliche Einrichtungen wie die Universität von Sao Paulo verlassen sich ebenfalls auf CloudStack um ihre betriebliche Agilität zu erhöhen und gleichzeitig die IT-Kosten zu senken.

Das Innenleben von Apache CloudStack

Der CloudStack Managementserver (MS) hostet die Steuerebene samt Workload-Management, Bilderindexierung (template / ISO) und virtuellem Netzwerkmanagement. Er orchestriert das Management der darunterliegenden Rechen-, Speicher- und Netzwerkgeräte. Intern stellt der Managementserver eine Reihe grundsätzlicher Abstraktionen und Kontrollservices bereit, die von Plug-ins dafür genutzt werden, sich mit verschiedenen Devices zu verbinden. Die Plug-ins sind als Java-Archives (JARs) gepackt und werden dem Managementserver via Spring zur Laufzeit übergeben. Durch dieses Plug-in-Modell integriert CloudStack eine breite Palette von Hypervisors, Netzwerkgeräten und Speicherplattformen. Zu guter Letzt ist die Kommunikationssteuerebene auf Layer 2 isoliert, um so eine robuste und sichere Mandatenfähigkeit zu schaffen.

Wie in der Grafik dargestellt weist der Managementserver Ressourcen den folgenden Partitionstypen zu, abhängig von ihrem Failure-/Recovery-Modell:

• Region: Ein oder mehrere Rechenzentren in einem geographischen Gebiet.
• Zone: Die Kombination einer Stromquelle und eines Internet-Uplinks innerhalb eines Rechenzentrums. Ein Rechenzentrum kann aus mehreren Zonen bestehen, sofern mehrere Stromquellen und Internet-Uplinks verfügbar sind. Eine Region beinhaltet eine oder mehrere Zonen.
• Pod: Ein oder mehrere Racks, die sich einen ToR-Switch („top-of-rack“) teilen. Eine Zone beinhaltet einen oder mehrere Pods.
• Cluster: Eine Gruppierung von Hosts mit dem gleichen Hypervisor und typischerweise der gleichen Hardware-Konfiguration. Ein Cluster ist zudem der kleinste gemeinsame Nenner für primäre Speicherpools. Ein Pod besteht aus einem oder mehreren Clustern.

Ein Host repräsentiert einen physikalischen Server, der einen Hypervisor oder eine Scale-out-/Big-Data-Plattform betreibt. Mit diesem Partionierungsmodell können Applikationen, die verteilte Operationen supporten, so deployt werden, dass sie gegen Strom- und Internetausfälle, als auch Switch-, Server- und Speicher-Pool-Ausfälle widerstandsfähig sind.

Zur Erhöhung der Kapazität und der operativen Belastbarkeit können mehrere Managementserver für verbesserte Orchestrierung und Geräteüberwachung geclustert werden. Da Infrastrukturoperationen erhebliche Mengen wall time in Anspruch nehmen können (z. B. das Kopieren großer Templates von sekundären auf primäre Speichermedien oder Momentaufnahmen größerer Volumes) lagert der Managementserver diese Operationen als langlebige asynchrone Jobs aus. Falls ein Managementserver während einer oder mehreren dieser längeren Operationen ausfällt, nehmen die anderen Cluster-Mitglieder automatisch Ownership über die Jobs des ausgefallenen Servers an.

Einen typischer Use Case

Die Use-Cases für Apache CloudStack können in zwei Kategorien aufgeteilt werden: Allgemeine Cloud- und Service-Provider sowie Enterprise User. Es gibt viele Cloud Provider, die IaaS mittels CloudStack an ihre Kunden liefern – von großen, global arbeitenden Providern bis zu kleinen ISPs, die ein Cloud-Modell einführen müssen. Als Open-Source-Projekt mit freier Lizenz ist es schwer, alle User zu kennen, aber große, bekannte Cloud Provider wie Datapipe, British Telecom, China Telecom, Interoute und Exoscale verlassen sich auf CloudStack um ihre IaaS-Serviceangebote anzubieten. Eine Liste aller erfassten Benutzer gibt es auf der Projektseite.

Bekannte Cloud Provider nutzen den CloudStack, da er alle Funktionen für multi-tenancy IaaS-Services in einer einzigen, verlässlichen, leicht implementierbaren Plattform bietet, die außerdem leicht zu managen ist. Er benötigt keine monatelange Installation und Integration, da die verschiedenen Komponenten bereits integriert sind. CloudStack hat zudem einen eng definierten Aufgabenbereich: Das orchestrieren zentraler Infrastrukturkomponenten. Daher konzentriert sich die Community darauf, aus CloudStack eine widerstandsfähige, gut verwertbare Infrastruktur-Steuerebene zu machen, in die andere Systeme leicht integriert werden kann. Es ist zudem möglich, CloudStack komplett abzuschalten, ohne dass die Infrastruktur auch nur eine kleinste Unterbrechung erfahren würde.

Die andere Benutzerkategorie definieren wir lose als Enterprise User/Non-Service-Provider. Es handelt sich dabei um Organisationen, die ihre Infrastruktur intern automatisieren und orchestrieren wollen. Die Gründe für dieses Bedürfnis sind in sämtlichen Betrieben verschieden. Manche wollen eine Basis für CI/CD-Umgebungen sein. Manche wollen bestimmte PaaS-Plattformen unterstützen. Manche wollen die Entwicklung von großangelegten Testumgebungen automatisieren. Es gibt einige Fortune-500-Unternehmen, die CloudStack aus diesen Gründen nutzen.

Was ist das Schlüsselmerkmal?

Das Schlüsselmerkmal von CloudStack ist, dass es alle IaaS-Funktionen in einer einzigen, integrierten, verlässlichen Softwareplattform durchführt. Gut orchestrierte Infrastrukturen und gemanagte virtualisierte Netzwerkmodelle sind ausschlaggebende Funktionen, die wir in einfacher Benutzbarkeit und Verlässlichkeit erbringen. Es ist kein Geheimnis, dass CloudStack kontinuierlich mit OpenStack verglichen wird (und die Medien und Analytiker scheinen es immer als eine Art Rennen anzusehen). Wenngleich beide eine ähnliche Funktionszusammenstellung haben, nutzen sie unterschiedliche Architektur- und Betriebsmodelle. Anstatt dass Betreiber 15 verschiedene Kleinkomponenten integrieren und maintainen müssen, nutzt die CloudStack-Steuerebene aus Skalierbarkeits- und Resilienzgründen eine Komponente, die auf multiplen Nodes deployt wird.

Es gibt auch Verbesserungsbedarf

Unsere breite Entwickler-Community kommt ihrer Aufgabe, die Funktionalitätszusammenstellung up-to-date zu halten, wirklich gut nach. Allerdings tun wir uns noch damit schwer, die Aufmerksamkeit vom Markt zu bekommen. Das wiederum bedeutet, dass die Anbieter nur in CloudStack integriert werden wollen, sobald es ihre Nutzer fordern. Wir würden uns freuen, wenn mehr Netzwerk- und Speicheranbieter auf CloudStack zugehen würden, sodass wir ihre spezifischen Funktionalitäten mit einbeziehen können.

Was bringt die Zukunft für CloudStack?

Da sich die Branche auf IaaS fokussiert, ist der Bedarf eines Infrastrukturorchestrators, der einfach funktioniert, überlebenswichtig geworden. Neue Modelle wie Container, PaaS oder FaaS können nicht ohne die Bereitstellung von zentralen Rechen-, Netzwerk und Speicherservices arbeiten. Diese Modelle benötigen zudem eine Kontrollebene die „high churn“-Workloads verarbeiten kann, in denen Ressourcen schnell zur Verfügung gestellt, eingeteilt, verbraucht und verworfen werden. Um sich dementsprechend weiterzuentwickeln und den nötigen Support für diese hoch verdichteten „high churn“-Workloads bieten zu können, wird die Steuerebene weiter disambiguiert und vom Managementserver automatisch mit den verfügbaren Rechenressourcen verbunden.

CloudStack wird ebenfalls im Bereich Infrastruktur-Performance wichtiger werden. Heuristische Analysen von detaillierten, telemetrischen Daten werden es der Steuerebene erlauben, die Ressourcendichte und das proaktive Erkennen und Isolieren von Fehlern zu steigern. Erste Zeichen in diese Richtung haben wir bereits durch die kürzliche Ergänzung des Host-Power-Managements und den anstehenden HA-Service gesehen, der stockende Server neu-starten wird. Unsere Roadmap ist darüber hinaus mit weiteren Punkten vollgepackt, die CloudStack als den defacto unbestrittenen und verlässlichen Infrastruktur-Orchestrator auszeichnen werden, z. B. im Bereich Netzwerk-Service-Verkettung oder für leicht hinzuzufügende, verteilte Scheduler mit breiter Auswahl von Rechentypen (z. B. Container, Batch Job Execution oder NoSQL Datenbanken). Während diese Funktionalitäten also reifen, wird die Aufgabenstellung der CloudStack-Steuerebene, CloudStack zu einer umfangreichen Datacenter-Managementplattform wachsen lassen.

Weiterhin hat es die Community stark auf eine Verbesserung von Release-Rhythmus und Entwicklungsagilität abgesehen. Der Wettbewerbscharakter von Businesses, die CloudStack-benutzen, erfordert schnelle Anpassungen an rasante Kundenwünsche. Alle zwei Monate veröffentlicht die Community ein Feature Release, alle sechs Monate erscheint ein LTS mit der Support-Laufzeit von 20 Monaten. Die größte technische Herausforderung der Community ist derzeit das Testen der unzähligen in Frage kommenden Umgebungskomponenten und Systemkonfigurationen, die von der Userbase eingesetzt werden. Es erfordert enorme Rechenleistungen, dieses Problem vernünftig zu lösen. Zur Bewältigung entwickeln wir derzeit ein verteiltes Testsystem (SETI@Home nicht ganz unähnlich), das es jedem erlaubt zu unseren Systemtests beizutragen, der CloudStack nutzt.