© Pavel Ilyukhin, 123RF

Das Geschäft mit gehosteten Cloudservern wollen nicht mehr nur die überseeischen IT-Platzhirsche Amazon oder Rackspace machen, auch deutsche Anbieter wie 1und1, Strato oder die Deutsche Telekom sind dabei, auch kleinere Firmen entwickeln Angebote. Eines hat sich das Linux-Magazin angesehen.

Das Linux-Magazin wählte Kamp DHP [1] für einen Test aus. DHP steht für Dynamic Hardware Pool und ist ein Angebot des mittelständischen Rechenzentrumbetreibers Kamp Netzwerkdienste GmbH, das sich wohl unter Cloudhosting oder in die Sparten PaaS und SaaS einordnen lässt. Es basiert im Wesentlichen auf Containern und richtet sich an kleinere oder mittlere Unternehmen.

Denen beschert es virtuelle Umgebungen mit wählbarer Hardware-Ausstattung, naturgemäß immer mit Betriebssystem, teils auch mit anderer Software vorinstalliert, darunter etwa Datenbanken, Entwicklungswerkzeuge oder Content-Management-Systeme.

Viel Software

Als Betriebssysteme stehen Windows 2008 und 2012 R2 sowie diverse Linux-Derivate zur Auswahl: Centos 7, Debian 8.1, Ubuntu 16.04, außerdem Free BSD 10.1. Auffällig ist, dass kein Enterprise-Linux darunter ist und Suse ganz fehlt. Wer auf eine solche Distribution angewiesen ist, etwa weil er eine Applikation betreiben will, die nur für SLES oder RHEL zertifiziert ist, bleibt außen vor. Selber installieren kann er ein Betriebssystem prinzipiell nicht. Kamp führt an, man wolle Ärger wegen möglicherweise illegaler Windows-Lizenzen vermeiden, mindestens ebenso richtig dürfte aber sein, dass der Containeransatz technisch gar keine freie OS-Wahl zulässt.

Die Auswahl an vorinstallierter Software ist recht groß, es stehen mehr als 100 Templates bereit. In der Sparte Content Management sind neben anderen etwa Joomla, Drupal, Magento, EZ Publish, Mediawiki, Moodle, Plone, Typo3 und WordPress dabei. An CRM-Systemen werden unter anderem Sugar CRM und V-Tiger angeboten.

Als Datenbanken sind etwa Couch DB, Mongo DB, MySQL und PostgreSQL verfügbar. Weiter finden sich so bekannte Anwendungen wie OTRS und Bugzilla sowie Entwicklungswerkzeuge wie Django, PHP, Node.js oder die Google App Engine. An Infrastruktursoftware sind ein LAMP-Stack, LDAP und VPN, ein Windows-Domaincontroller sowie etliche Web- und Applikationsserver vertreten.

Klar ist aber trotzdem, dass dies angesichts der existierenden Softwarevielfalt nur eine kleine Auswahl sein kann. Wer spezielle Wünsche hat, kann sie prinzipiell auf einer nur mit einem Betriebssystem ausgestatteten Umgebung einrichten. Das Installieren klappt sogar von einem importierten ISO-Image aus, nur booten kann man von dem – wie gesagt – prinzipiell nicht.

Ein Seiteneffekt dieser Einschränkung ist, dass es so auch unmöglich ist, bei der Erstinstallation über den OS-Installer verschlüsselte Partitionen anzulegen. Allerdings kann der Anwender später weitere virtuelle Festplatten hinzufügen, die sich partitionieren, formatieren und auch verschlüsseln lassen. Dafür sind aber etwas Know-how und Handarbeit nötig.

Die virtuelle Hardware lässt sich in drei Klassen buchen (Tabelle 1). Die Kontingente der jeweiligen Stufe kann der Kunde auch noch in bestimmten Schritten um CPU-Cores, RAM und Storage aufstocken. Für eine Erweiterung um Rechenkerne oder Hauptspeicher muss die virtuelle Umgebung heruntergefahren werden, Festplatten lassen sich auch im laufenden Betrieb hinzufügen.

Cloud-typisches Pay-per-Use im strengen Sinne – wodurch sich das Angebot auch von einem virtualisierten Rootserver unterscheiden würde – ist dennoch nur fragmentarisch möglich. Schließlich zahlt der Mieter eine Pauschale für eine gewisse Ausbaustufe, auch wenn er ihre Ressourcen nicht ausschöpft, und die kleinste zeitliche Abrechnungseinheit ist ein Tag. Bei konkurrierenden Angeboten sind teils stundengenaue Tarife üblich, die jeden Core und jedes GByte RAM oder Traffic einzeln berechnen.

Manchmal kann der Anwender dort auch inaktive Instanzen einfrieren und zu einem deutlich geringeren Stundenpreis parken. Bei Kamp DHP ist eine solche Option nicht verfügbar, auch das Gegenteil gibt es nicht, also eine Autoscaling-Option, die einem Engpass automatisch mit Aufstocken der knappen Ressource begegnen würde. Dafür sind die Preise vergleichsweise attraktiv.

Gar nicht skalierbar ist allerdings die Netzwerkanbindung. Jede virtuelle Umgebung enthält genau ein Netzwerkinterface, das eine öffentliche IP-Adresse via DHCP zugewiesen bekommt. Soll ein Teil des Traffic zwischen mehreren virtuellen Umgebungen privat sein, wie das üblicherweise in einer Clusterkonfiguration oder in einem Serververbund der Fall wäre, lässt sich das hier nur mit einer entsprechenden Konfiguration der Firewall bewerkstelligen. Die hat der Kunde selbst in der Hand. Eine physische Trennung der Datenströme – sei es aus Sicherheits-, sei es aus Performance-Gründen – ist aber nicht möglich. Was die Performance betrifft, verweist Kamp auf die hohe Bandbreite seiner Virtualisierungshosts, aber die steht ja keinem Container exklusiv zur Verfügung.

Der Kunde hat auch keinen Einfluss darauf, auf welchem physischen Host oder in welchem IP-Subnetz die von ihm gebuchten Container landen, und kann sie nicht auf einen anderen Host migrieren, wie das beispielsweise für ein Hochverfügbarkeitskonzept wünschenswert wäre. Kamp unterstreicht allerdings, dass DHP seine Einstiegsversion sei und das Unternehmen mit Virtual Core auch eine Offerte für höhere Ansprüche im Angebot habe.

Bedienung

Das Anlegen einer virtuellen Maschine und die Auswahl eines Template bewerkstelligt der Anwender mit wenigen sehr einfachen Schritten in einer Weboberfläche (Abbildung 1). Von dort aus startet er die Container mit einem Klick und hält sie an. Er kann Snapshots erzeugen, und es sind Monitore und Statistiken des Ressourcenverbrauchs einblendbar (Abbildung 2).

Abbildung 1: Neue virtuelle Umgebungen lassen sich mit wenigen Klicks erzeugen.

Beide Features müssen jedoch mit kleineren Einschränkungen leben: Die automatischen Snapshots erzeugt das System in der Regel aus der laufenden Umgebung, ergo werden unter Umständen geöffnete Files gesichert, was zu Problemen beim Recovery führen kann. Namentlich betrifft das etwa Datenbanken, die der Anwender besser extra mit einem Dump vor dem Snapshot schützen sollte. Und was das Monitoring betrifft, gibt es zwar eine Übersicht des momentanen Ressourcenverbrauchs, aber keinen Mechanismus, der die Verfügbarkeit der von außen erreichbaren Dienste überwacht.

Abbildung 2: Wie viel der angemieteten Ressourcen wurde bereits eingesetzt? Das Web-GUI hat eine grafische Antwort.

Für die weitere Konfiguration nach der Ersteinrichtung wird Administrator-Know-how gebraucht, denn spezielle Wizards oder andere Hilfen gibt es nicht. Stattdessen erreicht der Anwender aus dem Webinterface heraus eine virtuelle Konsole. Zusätzlich ist der SSH-Zugang von einem beliebigen Terminal aus möglich. Der installierte SSH-Server ist übrigens nicht empfänglich für die Heartbleed-Attacke und andere gängige Vulnerabilities, einzig die selbst signierten Zertifikate beanstandet eine Sicherheitsüberprüfung wie [2].

Kamp DHP ordnet sich ganz den nicht immer konsistenten Vorgaben der vom Anwender gewählten Distribution unter. So ist bei Ubuntu per Default der Root-Account für Logins gesperrt. Ubuntu zählt dafür eine ganze Reihe angeblicher Vorteile auf: Der Extraschritt via »sudo« zwinge zum nochmaligen Nachdenken, der Installer habe weniger zu erfragen, es gibt ein extra Log und feiner abgestimmte Berechtigungen und so weiter.

Allerdings fällt das Kartenhaus in dem Moment in sich zusammen, indem der Anwender den Root-Account mit einem einzigen Kommando wieder aktiviert und damit alle Freiheiten zurückerhält, inklusive jener, gefährliche Schwachstellen einzurichten.

Dem hätte der Cloudanbieter wenigstens in gewissem Umfang vorbeugen können, beispielsweise indem er erzwungen hätte, dass Root ein vernünftiges Passwort erhalten muss. Bei dem im Zuge der Installation angelegten unprivilegierten Default-User kommt man ja auch nicht darum herum.

Auch eine zusätzliche Sicherung der Anwendungs-Logins via »htaccess« wäre denkbar. Letzten Endes ließe sich trotz der Ubuntu-Vorgabe dann auch ein Root-Login von Anfang an ermöglichen, wie das bei den Templates mit vorinstallierter Software, die teils unter Debian laufen, ja auch Standard ist.

Auf der sicheren Seite

Eine Art Backup des Containers in Form eines Snapshots läuft automatisch. Zusätzlich kann der Anwender jederzeit manuell einen Snapshot anfertigen. Eine komplette Rücksicherung auf einen anderen Speicherbereich muss er aber via Support-Ticket beantragen – und das ist extra kostenpflichtig. Einzelne Files kann der Anwender nicht selber wieder restaurieren. Alternativ oder zusätzlich lassen sich die virtuellen Rechner duplizieren und exportieren.

Beim Duplizieren entsteht eine identische Kopie, die der Admin anschließend unter einer neuen IP-Adresse starten kann. Das Exportieren erzeugt ein VMDK-Image der virtuellen Maschine, das sich herunterladen lässt. So gelingt etwa auch die Migration zu einem anderen Anbieter. Eine Funktion zum Importieren von VMDK-Images in Kamp DHP gibt es nicht.

Performance

Welche Performance ist von einem virtuellen Server in der Kamp-Cloud zu erwarten? Das Linux-Magazin hat einige Benchmarks gestartet, um diese Frage zu beantworten. Alle Benchmarks liefen lokal, die Ergebnisse enthalten also keine Einflüsse des Netzwerks. Um sie besser einordnen zu können, starteten die Tester die gleichen Benchmarks noch auf zwei Vergleichsrechnern.

Das war zum einen ein gewöhnlicher Laptop – in diesem Fall ein Lenovo Thinkpad mit Dualcore-Pentium-CPU B940, getaktet mit 2 GHz. Der Laptop, der unter Ubuntu 14.04 lief, verfügte über 4 GByte RAM und eine Seagate-600-Pro-SSD mit 400 GByte. Zum anderen diente ein Dell Power Edge T110 dem Vergleich, ausgestattet mit zwei Intel-Core-i3-530-CPUs (knapp 3 GHz), 16 GByte RAM und einer Festplatte Samsung Spinpoint HD103SI. Dieser Server lief unter SLES 12 SP1. Der virtuelle Server war eine Debian-8-Maschine mit vorinstalliertem MySQL, ausgestattet mit 4 GByte RAM und vier virtuellen CPUs.

Zunächst ließen die Tester die Probanden in der Disziplin Rechenleistung antreten und ermittelten mit Hilfe von Sysbench 0.4.12 die Laufzeit für eine Berechnung der Primzahlen bis zur Obergrenze 20000 (Abbildung 3).

Abbildung 3: Hier ist der kürzere Balken besser, er steht für die Ausführungszeit.

Danach benutzten sie den OLTP-Test von Sysbench, den sie mit einer schrittweise steigenden Zahl paralleler Threads konfigurierten. Hier schlägt sich das DHP-System besonders gut. Es skaliert zunächst exponentiell, bevor es an den Sättigungspunkt gelangt (Abbildung 4). Der Dell-Server kann sich in dieser Disziplin mit seiner Festplatte nicht gegen die SSD-bestückte Konkurrenz durchsetzen.

Abbildung 4: Eine steigende Anzahl Threads erhöht die Last. Bis zu einem bestimmten Punkt kann die Performance Schritt halten.

Etwas anders sieht die Lage aber aus, wenn – wie schon bei der Read-only-Variante desselben Benchmark – die Rechenleistung stärker im Vordergrund steht: Dann spielen die vier Kerne der Core-i3-CPU des Dell im Verbund mit dem größeren RAM ihre Stärke aus und katapultieren ihren Rechner auf einen Spitzenplatz.

In einer Cloud ist es nun besonders einfach, eine solche Beobachtung für die Optimierung zu nutzen und eine Ressource wie die Anzahl der Rechenkerne stufenweise auszubauen. Dabei muss viel nicht zwangsläufig viel helfen. Die Tester des Linux-Magazins haben den OLTP-Test im Read-only-Modus noch einmal mit zehn Threads bei 4 GByte RAM und steigender Anzahl CPUs laufen lassen (Abbildung 5). Man sieht, dass mehr als sechs CPUs in diesem Fall keinen nennenswerten Performancezuwachs mehr bringen.

Abbildung 5: Die letzten sechs hinzugefügten CPUs tragen kaum mehr etwas zur Performance bei.

Fazit

Kamp DHP ist ein leistungsfähiges Angebot zu einem fairen Preis. Die Auswahl an Betriebssystemen ist ausreichend, wenn auch nicht umfassend, die Palette vorinstallierter Software ist breit. Die angebotenen Managementfunktionen sind einfach und intuitiv bedienbar. Bei wachsenden Ansprüchen kann die Lösung skalieren. Doch zahlt man auch nicht genutzte Ressourcen. Dafür lässt sich das Setup in relativ kleinen Schritten erweitern.

Die installierte Software ist aktuell, gängige Sicherheitsvorkehrungen hat der Anbieter getroffen. Mit eigenen Firewallregeln darf der Anwender den Zugriff weiter einschränken. Wer Ressourcen in eine Cloud auslagern will und dabei keine zu speziellen Anforderungen zu erfüllen hat, der sollte Kamp DHP in seine Auswahlentscheidung einbeziehen.