Private Cloud mit IaaS aufbauen
Privatsphäre im öffentlichen Raum
Infrastructure as a Service (IaaS) in einer Enterprise Private Cloud ist wegen mangelnder Skalierbarkeit und Flexibilität der Ressourcen ein Widerspruch in sich. Aber gerade in Deutschland gelten Sicherheit und Performance als Killerargumente gegen Public-Cloud-Services. Eine Bestandsaufnahme mit Lösungswegen.Das ideale Rechenzentrum sollte so aussehen: Möglichst wenige Ressourcen dürfen brachliegen, gleichzeitig soll es aber jede noch so außergewöhnliche Lastspitze abfangen. Dass dies mit einem dedizierten Rechenzentrum im eigenen Haus zu erreichen sei, glaubt zurecht niemand. Bedarfsgerechte Bereitstellung von Servern und Storage auf dem Unternehmensgelände wäre so, als wollte man im Eigenheim jedesmal, wenn sich Besuch ankündigt, flugs ein Zimmer mit Bad anbauen und es dann sofort ohne Rückstände einpacken, wenn die Freunde oder Verwandten wieder gegangen sind - ganz zu schweigen von unangekündigtem Besuch oder dem vorübergehenden Auszug eines der Kinder. Immerhin gelingt es mit der Virtualisierung von Ressourcen bereits, aus dem Baubestand das Maximum herauszuholen und sich dadurch dem realen Bedarf anzunähern. Viele Enterprise-Private-Cloud-Konzepte sind allerdings im Grunde im Stadium dieser optimierten Virtualisierung eigener vorhandener physischer Rechenkapazitäten steckengeblieben, wie es zuletzt James Staten von Forrester Research in einer Analyse pointiert formuliert und bemängelt hat (bit.ly/12PBdjo). Die Lösung könne nur darin bestehen, den Begriff Service ins Zentrum von Entwicklung und Betrieb virtueller Rechenzentren zu stellen. Damit sei man konzeptionell bei der Public Cloud angelangt. Dass man diesen naheliegenden Schritt in die Public Cloud insbesondere in Deutschland nicht geht, liegt an zwei Annahmen: Public-Cloud-Infrastruktur sei unsicherer und weniger performant als dedizierte, eigene Ressourcen - zumindest wenn diese eine optimale Architektur aufweisen und perfekt verwaltet sind. Vor diesem Hintergrund falle nicht so sehr ins Gewicht, dass interne Ressourcen notwendigerweise immer dazu neigen, unwirtschaftlich zu sein. Wenn also IaaS aus der Public Cloud beweisen kann, dass sie mindestens genauso sicher und performant ist wie das gewohnte eigene physische oder virtualisierte Rechenzentrum, dann gibt es keinen rationalen Grund mehr für Vorbehalte. Von der betriebswirtschaftlichen Seite aus betrachtet hat dieser Ansatz ohnehin den Vorteil höherer Liquidität für das Unternehmen, da eine als Service bezogene Infrastruktur zum operativen Geschäft (Opex) gehört, während eine eigene im Haus betriebene Server-Infrastruktur kapitalbindend dem Betriebsvermögen (Capex) zuzuordnen ist - auch dann, wenn sie als Private Cloud konzipiert ist. Zudem bietet nur ein Public-Cloud-Service ein echtes verbrauchsabhängiges Bezahlmodell und damit volle Kostentransparenz. Der Schlüssel liegt in Deutschland Server in der Public Cloud sind üblicherweise jeder für sich im Internet sichtbar und daher per se angreifbar. Auch besteht dadurch, dass sich mehrere Benutzer wegen der dynamischen Ressourcenzuweisung physische Instanzen teilen, mindestens theoretisch die Gefahr, dass von diesen Instanzen Daten abgegriffen werden. Zudem liegen derzeit bis zu 90 Prozent der Cloud-Ressourcen in den USA und unterliegen damit dem US-Recht, insbesondere dem Patriot Act. Dieser verpflichtet die Anbieter dazu, den US-Behörden Daten und Informationen seiner Kunden zugänglich zu machen, ohne dass der Eigentümer der Daten davon erfährt. Für Letzteres gilt die einfache Losung: Cloud-Services sollte man nur aus einem europäischen, am besten einem ISO-zertifizierten deutschen Rechenzentrum beziehen. Dazu muss sich der Service-Provider verpflichten. Nur so ist man datenschutzrechtlich auf der sicheren Seite. Die beiden anderen Probleme sind technisch lösbar: Vor die eigentlichen produktiven Server lässt sich ein VPN-Server stellen, der das komplett hinter ihm liegende Netzwerk gegen das Internet abschirmt. Jeder Datenverkehr in das virtuelle Netzwerk läuft dann über einen VPN-Tunnel mit einer SSL/TLS-Verbindung. Als Lösung für das zweite Problem bietet sich an, jedem Kunden dedizierte virtuelle Ressourcen zuzuweisen. Dies stellt sicher, dass "Störfeuer" hinsichtlich Performance und Datenschutz seitens anderer Kunden auf derselben VM ausbleibt. Etliche Anbieter neigen allerdings dazu, Server aus Kostengründen überzuprovisionieren. Hier gilt es, die Zusicherung einzufordern, dass genau dies nicht geschieht. Das größte Sicherheitsrisiko bilden allerdings nicht optimal abgesicherte und gewartete Systeme. Schneller, höher, weiter Das Thema Performance ist multidimensional: Geschwindigkeit, Verfügbarkeit und Ausfallsicherheit. Die Datenübertragungsraten der Verbindungen zwischen Host und Anwender sowie zwischen den einzelnen Netzwerkkomponenten bilden die limitierenden Faktoren. Stand der Technik bei Unternehmensnetzwerken, aber auch bei Private-Cloud-Angeboten scheint immer noch Gigabit Ethernet zu sein. Dies stößt aber an seine Grenzen, insbesondere bei der virtualisierten Anbindung von Storage-Gerätschaft. Als Anleihe aus dem High-Performance Computing kann hier auch Infiniband zum Einsatz kommen. Es bringt von Haus aus eine mindestens viermal so hohe Geschwindigkeit 10 Gigabit Ethernet. Setzt man nun in jede Netzwerkkomponente zwei Infiniband-Netzwerkkarten ein, erhöht sich die Übertragungsgeschwindigkeit auf 80 GBit/s. Dies ermöglicht die vollständige Virtualisierung des Netzwerks. Diese ist geboten, will man maximale Flexibilität unter Einbeziehung aller relevanter Komponenten im Netzwerk erzielen, welche die eines lokal installierten Netzwerks - ob virtualisiert oder nicht - bei Weitem übertrifft. Bisherige virtuelle Rechenzentren halten sowohl die Freiheit der Konfiguration als auch deren Skalierung in einem relativ engen Rahmen. Dies betrifft die Zahl der Cores pro virtuellem Server ebenso wie den zugewiesenen Arbeitsspeicher pro Core. Eine vielversprechende Vorgehensweise ist Software-Defined Networking (SDN). SDN der ersten Generation teilt das Netzwerk, vereinfacht gesagt, in separate Ebenen für Netzwerkdatenanalyse und -steuerung (Control Plane) sowie den Netzwerkdatentransport (Data Plane). Dies ermöglicht es, die Analyse- und Steuerungsebene vollständig zu virtualisieren. Die Steuerungsebene spricht die einzelnen Hardwarekomponenten meist über ein API (Application Programming Interface) an. Die Verlagerung der Steuerung auf die Softwareebene eröffnet umfassende Automatisierungspotenziale, etwa für Konfigurationsänderungen oder Update-Rollouts. Neuere Umsetzungen von SDN dagegen virtualisieren nicht nur die Steuerungsebene, sondern das komplette Netzwerk. Man virtualisiert hier sämtliche klassische Netzwerkhardware wie Firewall, Load Balancer oder Switch, echte Hardware wird nicht mehr benötigt. Die Software kann über integrierte Treiber verschiedenste virtuelle Netzwerkhardware einbinden, konfigurieren und steuern. Traffic kann bei dieser Lösung nicht nur separiert, sondern auch verbunden werden. Im Ergebnis entsteht ein Netzwerk, das sich binnen weniger Minuten exakt auf den realen Bedarf einstellen lässt. Es ist dann sogar möglich, nicht nur horizontal zu skalieren, indem man neue Instanzen hinzufügt (ein sehr komplexes Verfahren, weil dann auch die Software parallelisierbar sein muss und die Performance des Netzwerks nicht linear mit der Anzahl der Instanzen steigt). Vielmehr lassen sich damit die einzelnen Instanzen bis zu einer maximalen Größe ohne Reboot vertikal skalieren. Dieses Live Vertical Scaling (LVS) kann so granular erfolgen, dass man Cores einzeln und RAM-GByte in Einserschritten, aber auch jeweils mehrere auf einmal hinzufügen kann. Derzeit sind maximal 48 Cores pro virtueller Maschine und 256 GByte RAM realistisch, Tendenz steigend. Für den Anwender heißt das auch, dass er sicher sein muss, diese Kapazitäten auf Knopfdruck provisionieren zu können. Diese echte Skalierbarkeit setzt wiederum voraus, dass er dedizierte virtuelle Ressourcen erhält. Verfügbarkeit in der Cloud Es bleiben die Themen Verfügbarkeit und Ausfallsicherheit. Ein wesentlicher Aspekt ist hier die mehrfach redundante Anbindung aller Netzwerkkomponenten. So sollte insbesondere die Datenspeicherung automatisiert stets auf zwei Storage-Geräte parallel und innerhalb der Geräte wiederum redundant erfolgen. Damit liegen die Daten letztlich stets vierfach vor. Für eine solche Auslegung des Netzwerks sind allerdings in einer virtualisierten Umgebung hohe Übertragungsgeschwindigkeiten notwendig, damit eine derartige massiv parallele Verarbeitung der Daten überhaupt möglich wird. Auch hier liefert Infiniband den entscheidenden Vorteil gegenüber Standard-Ethernet. Ein weiteres Problem könnte sein, den eingehenden IPv4-Traffic einer festen virtuellen Server-Instanz zuzuweisen. Fällt diese Instanz aus, ist der Datenstrom ins gesamte virtuelle Netzwerk unterbrochen. Unter Linux lässt sich hier allerdings innerhalb von Linux-HA mittels Unterstützung von Gratuitous ARP (Application Ressource Protocol) die dynamische Zuweisung des Datenverkehrs zu einer beliebigen Instanz im Netzwerk realisieren, was dieses Ausfallrisiko minimiert. Damit bleibt der letzte Rest Unsicherheit bei der Datenübertragung über die WAN-Strecke und bei echten Hardwareausfällen mit harten Resets. Beides aber betrifft dedizierte virtuelle Rechenzentren und Private Clouds genauso - nur dass in vielen Unternehmen sicher gut ausgebildetes Personal in geringerer Zahl zur Verfügung steht als beim Public-Cloud-Anbieter.
Lesen Sie mehr zum Thema
