Thought Leadership
Klassisches Hosting mit VMware ist immer mit Lizenzkosten verbunden. Und diese können teilweise beachtliche Beträge erreichen. Aber es gibt auch kostengünstigere Alternativen. Eine davon ist die Self-Managed-Cloud-Software OpenStack.
VMware ist seit Jahren die bewährte Software für klassisches Hosting im Enterprise-Umfeld. Allerdings kommen die damit verbundenen Lizenzkosten Kunden teilweise teuer zu stehen. Bei der Suche nach einer preisgünstigeren Alternative ist Adacor auf OpenStack aufmerksam geworden. Das von der Firma Rackspace mitentwickelte und betreute Self-Service-Produkt ist ein Tool zur Umsetzung der „DevOps-Idee“. Als Kombination aus „Software Development“ und „Information Technology Operations“ umfasst der Begriff verschiedene Methoden zur Kollaboration und Kommunikation von Softwareentwicklern und IT-Professionals.
Nach eingehender Prüfung der Technologie von OpenStack wurde mit der Software ein neues Angebot im Bereich Private und Self Managed Cloud geschnürt. Seit dessen Einführung haben wir zahlreiche Erfahrungen in der Umsetzung von OpenStack gesammelt. Wir haben dabei jede Menge gelernt und einige Konsequenzen gezogen.
Komplexität macht Fehlersuche schwer kalkulierbar
Eine große Herausforderung, speziell im Fall von Störungen, ist die große Komplexität von OpenStack. Die Software funktioniert als Bundle aus mehreren Services, die zusammen einen Dienst bereitstellen. Sieben verschiedene Module bilden dabei die Kernkomponenten. Diese müssen komplett installiert und betrieben werden, da sie in ihrer Gesamtheit die Voraussetzung für das Funktionieren der Software bilden. Zwischen den einzelnen Modulen bestehen zahlreiche Abhängigkeiten. So ist die volle Funktionalität nur dann gegeben, wenn jeder Dienst reibungslos läuft. Tritt ein Problem auf, müssen alle Komponenten in die Fehlersuche einbezogen werden. Das kann extrem zeit- und ressourcenaufwändig sein – und ist vorab kaum abschätzbar.
(Eine detaillierte Beschreibung der einzelnen Komponenten aus der Grafik ist hier zu finden Sie hier.)
Erschwerend kommt hinzu, dass man auf die in der Community verfügbare Dokumentation angewiesen ist. Diese ist mit der von großen Cloud-Anbietern wie zum Beispiel Amazon eingesetzten Versionen nicht vergleichbar. Außerdem hinkt sie der Weiterentwicklung durch Rackspace erfahrungsgemäß hinterher. Gleichzeitig gibt es in der Community teilweise Features, die den großen Cloud-Anbietern noch gar nicht zur Verfügung stehen. Sie kaufen in der Regel Hardware und Management inklusive Support bei Rackspace ein. Es versteht sich von selbst, dass ein Unternehmen, das Software entwickelt, im Fall eines Fehlers viel weitreichendere Möglichkeiten hat, diesen zu lokalisieren und zu beheben als das einem unabhängigen Hosting-Dienstleister möglich ist.
Security-Frage für Hosting-Dienstleister nicht zufriedenstellend gelöst
Eine weitere Herausforderung bei der Anwendung von OpenStack ist der Sicherheitsaspekt. Zwar bietet der enthaltene Netzwerk-Stack (Neutron oder Nova) die Möglichkeit, Firewall-Regeln zu erstellen. Allerdings müsste der Kunde selbst diesen Vorgang übernehmen und infolgedessen auch die volle Verantwortung für die Sicherheit tragen. Je nach Unternehmen ist das sicher machbar. Für einen externen Dienstleister ist allerdings kaum abschätzbar, inwiefern ein Unternehmen dazu in der Lage ist. Setzt sich der Kunde nicht ausreichend mit den Security-Themen auseinander oder treten Fehler in der Applikation auf, kann dies zu Sicherheitslücken führen. Hinzu kommt, dass die möglichen Paket-Filterregeln im Netzwerk-Stack auf einer Software-Programmierung basieren, die relativ frisch ist beziehungsweise sich noch in der Entwicklung befindet. Für deren hundertprozentige Sicherheit zu garantieren, ist für einen Hoster nicht möglich – gewohnte Sicherheitsstandards könnten also nicht gewährleistet werden.
Aus diesem Grund haben wir uns in OpenStack-Projekten für eine dedizierte, gemanagte Firewall entschieden. Sie wird jedem System vorgeschaltet und regelt sämtliche Security-Belange entsprechend den unternehmenseigenen Sicherheitsstandards. Der Netzwerklayer-Part von OpenStack ist somit bei dieser Hosting-Art gar nicht notwendig. Das entsprechende Modul muss zwar installiert und betrieben werden, es wird aber nicht genutzt: Sämtliche Security-Regeln werden ausgeschaltet. Bei einem Incident muss das Modul allerdings in die Fehlersuche einbezogen werden. Damit bindet es für den Dienstleister vorab kaum kalkulierbare Ressourcen.
Projekte geben den Ausschlag
Auch die Art der Projekte spielt beim Einsatz von OpenStack eine wichtige Rolle: Die betreffenden Applikationen müssen „DevOps-ready“ sein. Die zentrale Frage lautet dabei: Ist die Applikation so aufgesetzt, dass sie in kürzester Zeit deployt werden kann? Das heißt: Können Komponenten ausgetauscht und durch neu produzierte ersetzt werden? Oder basieren die Applikationen auf Assets, die langfristig gespeichert werden müssen, weil sie an große Datenbanksysteme angeschlossen sind. Diese können in der Regel nicht ad hoc zurückgespielt werden.
Wann ist eine Applikation reif für DevOps?Entscheidend ist die Möglichkeit, ein schnelles Deployment der Applikation auszuführen. Dafür müssen im Wesentlichen zwei Voraussetzungen erfüllt sein: Es kann kurzfristig auf die Applikation verzichtet werden: Es liegt eine horizontale Skalierung vor. In diesem Fall sind mehrere Systeme vorhanden (HA-Funktionalität), sodass ein System in der Lage ist, die Last abzufangen und alle Daten entsprechend auszuliefern, während ein zweites, drittes oder viertes System kurzzeitig neu deployt wird. Die Datenbank enthält fast nur die logischen Verknüpfungen der Assets. Die Daten und Bilder selbst sind im Asset Storage gespeichert. Die Applikation baut den Datensatz zusammen. |
Neben der Art der Datenvorhaltung ist die horizontale Skalierung der Systeme ein entscheidender Faktor für die DevOps-Fähigkeit von Applikationen. Dementsprechend lassen sich Projekte gemäß ihrer Hosting-Anforderungen in zwei grundlegende Arten unterteilen:
- Projekte mit klassischen Hosting-Anforderungen
- Projekte mit DevOps-ausgerichteten Hosting-Anforderungen
Projekte mit klassischen Hosting-Anforderungen
Laufen Webserver, Datenbank und Datenvorhaltung auf einem System, kann nicht einfach auf eine virtuelle Maschine (VM) verzichtet werden. Schließlich wäre der Dienst für eine bestimmte Zeit – gegebenenfalls mehrere Stunden – nicht verfügbar. Eine solche Infrastruktur ist meist in Unternehmen zu finden, die hauptsächlich etablierte Enterprise-Software wie das klassische Microsoft Active Directory oder Exchange sowie Applikationen, die große MySQL-Systeme voraussetzen, einsetzen. In einem solchen Umfeld ist DevOps generell schwer umzusetzen. Dementsprechend hat sich der Einsatz von OpenStack als nicht zielführend erwiesen. Der Versuch, mit einer kleineren Version des Network-Stacks zu arbeiten, führte zu Abstrichen in der Funktionalität und massiven Einschränkungen in der Performance. Unternehmen mit einer solchen Infrastruktur haben eher klassische Hosting-Anforderungen und sind deshalb mit VMware besser bedient.
Projekte mit DevOps-ausgerichteten Hosting-Anforderungen
Unternehmen, die einen Teil ihrer Daten in Datenbanken vorhalten und ihre Web-Applikationen so aufgesetzt haben, dass die gleichen Systeme horizontal skalieren, können von OpenStack profitieren. Defekte Applikationen können ausgetauscht und anschließend neu positioniert und deployed werden. Wichtig ist allerdings, dass im Unternehmen das Know-how und die Ressourcen vorhanden sind, um VMs selbst zu deployen und das System ebenfalls selbst zu managen.
Aber auch hier kann es zu Problemen innerhalb der OpenStack-Applikation kommen. Ist das der Fall, muss der Hosting-Dienstleister gegebenenfalls mit immenser Manpower Komponenten und Abhängigkeiten prüfen, identifizieren, analysieren und die Probleme beheben.
Fazit
Auf der Suche nach einer kostengünstigeren Alternative zu VMware haben wir die Self-Managed-Cloud-Software OpenStack eingesetzt. Die Erfahrungen in verschiedenen Projekten haben leider gezeigt, dass die Software für die von Adacor angebotenen Hosting-Projekte nicht optimal ist. Grund dafür ist die immense Komplexität der Software, die insbesondere das Finden und Beheben von Fehlern extrem schwer kalkulierbar macht. Zum anderen ist der Security-Aspekt für Hosting-Dienstleister nicht zufriedenstellend gelöst: Wird der Security-Stack wie angedacht dem Kunden in seiner vollen Funktionalität zur Verfügung gestellt, würden alle Sicherheitsbelange in die Verantwortung des Kunden übertragen. Das entspricht für die meisten unserer Hosting-Projekte nicht der Realität. Die kurzfristige Lösung ist eine dedizierte Firewall und das Ausschalten aller Security-Regeln in OpenStack. Auf der Basis dieser Erfahrungen mit OpenStack haben wir daher ein Frame-Konzept als Alternative zu OpenStack entwickelt. Es ermöglicht, die DevOps-Idee in Hosting-Projekten umzusetzen und bietet Unternehmen große Flexibilität bei wenig Aufwand.
Alexander Wichmann, ADACOR Hosting GmbH
