Warum die Cloud nicht das Ende des klassischen Unternehmens-Admins ist, wie Amazons Elastic Computing Cloud praktisch funktioniert und welche Linux-Tools beim Auf- und Weiterbau des professionellen Wolkenkuckucksheim helfen, zeigt dieser Artikel.
“Eine Wolke wird nicht gekauft, sondern gebaut.” sagt Songnian Zhou, CEO des Cloud-Dienstleisters Platform Computing [1]. Mit dem leicht schiefen Bild Und damit hat er wahrscheinlich mehr Recht, als seiner Firma lieb sein kann. Für viele Admins ist die Cloud ohnehin nur das Marketing-Buzzword, das mehr und mehr Technologien aufsaugt, die seit gefühlten Jahrzehnten zum Standardrepertoire der IT-Admins gehören. Nicht wirklich viel Neues, meinen sie: Cloud Computing sei definitiv kein technischer, sondern ein Business-Trend.
Hybride Zukunft
Auch wenn sich die Zahlen von IDC [2], Gartner [3] und Accenture [4] unterscheiden, in einem sind sich alle einig: Keiner glaubt mehr an die eine, weltumspannende Cloud, die Analysten raten zur Hybrid-Wolke mit starkem privaten, internen Anteil. Eine Ausnahme könnten Branchenlösungen sein, bei denen sich die Anforderungen ähneln, zum Beispiel in Form einer Health Care Cloud. Forrester Research [5] nennt die Wolke einen “Pool abstrakter, skalierbarer, managebarer Infrastruktur, die für den Enduser Applikationen hostet.” Dem fehle nur noch ein Software-Layer, der die Ressourcen verwaltet und via automatisiertem Provisioning virtuelle Hardware und Systeme hinzufügt, ganz so wie das VMwares Vcloud macht. Ein modernes Cloud-Management sollte deshalb mindestens vier Features bringen:
- Dynamische Ressourcenverwaltung,
- eine Admin-Oberfläche mit Selfservice-Portal für den
Enduser, - eine transparente Softwarebasis,
- Logging, Abrechnung und Auswertung für die
Geschäftsleitung (Auditing, Billing, Reporting).
Schon in wenigen Jahren herrsche vielen Analysten zufolge überall die Elastic IT, die “Elastic Business-responsive Engine”. Die Serverkosten verschieben sich vollständig von der Investition zu Betriebskosten, die Wertschöpfungskette von einer Factory- zur Supply-Chain. In der öffentlichen Wolke kommt ein externer Service Provider wie Amazon ins Spiel und rechnet benutzte Ressourcen ab.
Der Vorteil fürs Unternehmen scheint klar: Es spart Investitionen, niemand braucht sich um die Hardware zu kümmern und ein Serverausfall ist zumindest theoretisch nur das Problem des Dienstleisters. Wer den Marketingexperten glaubt, weiß dann auch, dass CIO (ehemals Chief Information Officer, Leiter der IT) zur Abkürzung für “Career is Over” mutiert. Aber auch hier liegt die Sache nicht ganz so einfach, wie es sich die Strategen aus den Sales Departments das ausmalen. Gerade bei komplexen Angeboten wie Amazons Webservice ist immer noch einiges Know-how gefragt, um die Systeme anzupassen.
Der Amazonas
Die Registrierung für die Amazon Web Services (AWS, [6]) macht einen sicheren, aber umständlichen Eindruck: Wer sich beim Marktführer eine Wolke aufbauen will, muss mehrere Schritte durchlaufen. Am Anfang braucht er einen ganz normalen Account beim Onlinehändler. Der hilft bei der Identifizierung für das Konto bei den AWS.
Ins Webformular gibt der Bewerber seine Kreditkartendaten ein, per E-Mail kommt der Link auf eine Webseite, wo er einen vierstelligen Zahlencode erhält. Diesen gibt er bei dem sogleich erfolgenden Anruf von Amazon ein und bestätigt. Zurück per Mail gibts jetzt den Link zu den Access-Verifiern, die aus drei Teilen bestehen: Einem Account-Namen, einem AWS-Accesskey und einem AWS-Secret- Accesskey.
Elastischer Fuchs
Die trägt der Benutzer in seinem Client ein, zum Beispiel Amazons Firefox-Erweiterung Elasticfox (Abbildung 1, [7]), und schon kann er loslegen Clouds zu bauen. Wer den elastischen Fuchs nicht mag, nutzt die umfangreiche Toolbox der AWS-Funktionen in Amazon Management Console unter [8]. Hier kontrolliert er die laufenden Instanzen, wählt Images für die virtuellen Maschinen aus und koordiniert Schlüssel, Sicherheitsgruppen und Verbindungen.

Abbildung 1: Cloud-Management vom Browser aus mit Elasticfox. Amazons Addon vereint fast alle Funktionen, die auch die Weboberfläche bietet, und startet auf Wunsch ein Gnome-Terminal auf dem Wolkenserver..
Erstellen lassen sich die Instanzen am einfachsten wieder mit der Management Console (Abbildung 2), über die der Anwender auch das passende Keyfile »key.pem« und die Adresse für den SSH-Zugriff auf einen DNS-Namen im Reiche Amazon erhält. Elasticfox startet auf Wunsch gleich ein (Gnome-)Terminalfenster auf der Maschine. Das Listing 1 zeigt den ersten Zugriff auf das minimalistische Fedora-Core-8-LAMP-Image. Den SSH-Key sollte der Admin mit sensiblen Rechten ausstatten, sonst gibts die Fehlermeldung am Anfang des Beispiels.

Abbildung 2: Die Amazon Web Services Management Console ist vollständig und bietet auch Links zum Billing und zu den verwandten Produkten wie Cloud-Front.
| Listing 1: Log-In im Amazonas |
|---|
01 ssh -i mfeilner.pem root@ec2-204-236-222-5.compute-1.amazonaws.com 02 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 03 WARNING: UNPROTECTED PRIVATE KEY FILE! 04 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 05 Permissions 0644 for 'mfeilner.pem' are too open. 06 It is recommended that your private key files are NOT accessible by others. 07 This private key will be ignored. 08 bad permissions: ignore key: mfeilner.pem 09 Permission denied (publickey,gssapi-with-mic). 10 ls -l 11 insgesamt 16708 12 -rw-r--r-- 1 mfeilner mfeilner 1697 2010-03-23 12:20 mfeilner.pem 13 chmod 400 mfeilner.pem 14 ssh -i mfeilner.pem root@ec2-204-236-222-5.compute-1.amazonaws.com 15 16 __| __|_ ) Fedora 8 17 _| ( / 32-bit 18 ___|___|___| 19 20 Welcome to an EC2 Public Image 21 :-) 22 23 Getting Started 24 with EBS Boot 25 26 --[ see /etc/ec2/release-notes ]-- 27 [root@ip-10-212-71-68 ~]# netstat -tan 28 Aktive Internetverbindungen (Server und stehende Verbindungen) 29 Proto Recv-Q Send-Q Local Address Foreign Adress State 30 tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 31 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 32 tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 33 tcp 0 288 10.212.71.68:22 IP:60345 VERBUNDEN 34 [root@ip-10-212-71-68 ~]# df -h 35 Dateisystem Größe Benut Verf Ben% Eingehängt auf 36 /dev/sda1 9,9G 1,3G 8,2G 14% / 37 /dev/sda2 147G 188M 140G 1% /mnt 38 none 851M 0 851M 0% /dev/shm 39 [root@ip-10-212-71-68 ~]# |
Feste IP nötig
AWS-Einsteiger sollten sich zwei Sachen anschauen, bevor sie loslegen: Zum einen braucht die virtuelle Maschine eine statische IP. Die gibt es bei Amazon (kostenpflichtig) unter dem Stichwort Elastic IP, ein Eintrag im Kontextmenü der Instanz oder der IP weist die Adresse zu. Wer über das Leben der virtuellen Instanz(en) hinaus dauerhaften Plattenplatz braucht, muss unbedingt blockbasierten Speicher auf dem Elastic Block Storage (EBS [9] oder dem Simplee Storage Service S3 [10] anmieten, auch das geht bequem vom Browser aus.
Schön Linux-mäßig wird es, wenn der Admin nicht mit den wenigen von Amazon vorgefertigten Systemimages [11] zufrieden ist. Passende Server muss sich hier jeder selbst bauen, dabei helfen die Amazon Image Tools [12]. Sie gibt es als RPM und als ZIP-File, mit ihnen erstellt der Anwender eigene Abbilder und lädt sie in seinen Speicher in der Amazon-Wolke hinauf. Macht er sie dort öffentlich, dann tauchen die Images auch bei anderen Usern in der Liste auf.
Amazons Preisliste ist lang, das Gefüge recht unübersichtlich. Die verschiedenen Dienstleistungen (CPU-Zeit, I/O, Netzwerktraffic, Plattenplatz) kosten auf den ersten Blick lediglich Cents, summieren sich aber schnell zu höheren Beträgen. Die kleinste OS-Instanz schlägt mit 8,5 Dollar-Cent pro Stunde zu Buche, das macht 45 Euro im Monat oder gut 500 Euro im Jahr, benutzte Ressourcen sind da noch nicht dabei.
Administration
Admins brauchen also keine Angst entwickeln: Ihr Job wird sicher nicht entbehrlich. Selbst wer bei reinen IAAS-Providern wie Enomaly [13] mandantenfähige Infrastrukturen einkauft mit Firewall, DNS- und DHCP-Server, kommt um die Konfigurationsarbeit nicht herum. Darüber hinaus scheuen zahlreiche Unternehmen die Problematik, sich im Ernstfall bei unternehmenskritischen Diensten mit externen Dienstleistern herumschlagen zu müssen. Fragen bezüglich SLAs, Sicherheit und Geheimhaltung sowie rund um Garantien für den Zugriff stehen da unbeantwortet im Raum.
Dagegen betrachten der IDC [2] zufolge die meisten Unternehmen das Wolkenkonzept als sinnvoll für Webapplikationen (Abbildung 3). Vielleicht ist das der Grund für die eingeschränkte Vielfalt der Images bei Amazon.
© IDC Enterprisse Panel
Auch für den Notfall oder für kleine und mittlere Unternehmen oder Startups ohne große Invesitionsmöglichkeiten eignen sich die Szenarien nach allgemeiner Einschätzung gut.
Viele Firmen setzen bereits seit Längerem aufs Cloud Bursting, also die Möglichkeit, kurzfristig Ressourcen von Amazon, Google oder Microsoft hinzuzukaufen, um Leistungsspitzen abzufangen, wie das Beispiel der Spinchat AG zeigt [14]. Auch Programmierer nutzen virtuelle Instanzen für ganze Testumgebungen oder Entwicklersysteme.
Hybrider Mischmasch
Die Hybrid Cloud, also die Mischung lokaler Wolkendienste mit externen Angeboten und webbasierten Angeboten ist dementsprechend allgegenwärtig in der IT vieler Firmen. Als Management-Software stehen Tools wie Eucalyptus ([15],[16]) parat. Wem das nicht reicht, der sollte sich Projekte wie Amazons Open-Source-Toolkit Rain [17], die Java-basierte Cloud Application Plattform Makara [18] (ehemals Webappvm) anschauen.
Die Tools helfen, eigene Maschinen (Rain) oder Applikationen (Makara) in die externe Wolke zu bringen und diese nach Bedarf zu skalieren. Makara unterstützt Java, Flex, PHP, JBoss und Tomcat und kann Amazon, Rackspace, Vcloud, VMware, Virtualbox und Xen verwalten. Die Developerversion gibts gratis, Gerüchten zufolge werden weite Teile der Software wohl bald Open-Source.
Einen ähnlichen Ansatz verfolgt das proprietäre Cloudswitch [19]. Als Cloud Broker verschiebt die Software existierende Maschinen jederzeit reversibel in die Amazon-Cloud und verwaltet sie dort laut Hersteller transparent. Neben einer Testversion gibt es auf der Webseite eine kostenpflichtige Enterprise Edition mit erweiterten Features. Sun hatte sich schon 2009 der vielversprechenden Managementsoftware Q-Layer bemächtigt [20], aber auch die Python-Tools Pylabs [21] und Qpackages [22] sind des Admins Aufmerksamkeit wert, weil sie Applikationen betriebssystemunabhängig installieren und administrieren.
Wolkenwanderung
Die Migration in die Cloud gestaltet sich wie jede andere, egal ob eine private, externe oder hybride Wolke im Spiel ist. Als Dienstleister Im Bereich der Infrastuktur (Iaas) kommen die Namen Amazon, Rackspace, VMware (Vcloud), Gogrid, Citrix C3 Cloud Center und Skytabs Virtual Lab infrage. Paas, also Mietplattformen für Business-Anwendungen und Entwickler, gibt’s wie auch Saas-Angebote zum Beispiel bei Salesforce, Google, Microsofts Azure und 3Tera. Accenture macht denn gleich noch eine neue Kategorie für die Business-Prozesse auf, die das Marketing BPO-as-a-Service nennt. Darunter fallen geschäftsrelevante Prozesse wie Billing mit Paypal, transaktionsbasierte Kalkulation mit Equatrax [23] oder Buchhaltung mit Employease [24].
Open Source Cloud Stack

Abbildung 4: Im Lisog Open Source Cloud Stack versammeln sich die Enterprise-Produkte bekannter Open-Source-Hersteller.
© Lisog
Den Linuxer freut es, wenn auch die Granden der IT-Industrie verstanden haben, dass nur Offenheit und Freiheit dauerhaft erfolgreiche Konzepte ermöglichen. Wer sich auf allen Ebenen sicher vor dem Schrecken des Vendor-Lock-ins schützen will, der darf die Bemühungen der Stuttgarter Linux Solutions Group studieren. Im Lisog Open Source Cloud Stack (LOSCS, Abbildung 5, [25]) findet der interessierte Admin zahlreiche freie Software-Projekte, deren Hersteller sich zu einer langfristige Open-Source-Strategie verpflichtet haben.
Analog zur und in Kooperation mit der von Sam Johnston ins Leben gerufenen Open Source Cloud Initiative OSI [26] setzt die Lisog auf eine Vier-Stufen-Strategie hin zur Idealvorstellung einer Free Cloud mit freien APIs, offenen Formaten, ausschließlich Open-Source-Software und offenen Datenstrukturen.
Freiheit und vollständige Interoperabilität sollen da laut Vorstand Thomas Uhl die Kriterien sein, an denen sich die Mitglieder messen lassen müssen, auch wenn die Unternehmen der Kunden stets selbst Herr ihrer Daten bleiben. Der Stack erstreckt sich über alle Ebenen der Wolke, Saas, Paas und Iaas. Alle beteiligten Firmen müssen unternehmenstypische Supportmodelle bieten. Aus den involviertenKomponenten lassen sich bereits einfache Open-Source-Appliances bauen. Darüber hinaus soll das Projekt mit Finanzierungs- und Vertragsmodellen sowie dem Erfahrungsaustausch untereinander Unternehmen helfen, die ein “Going-GNU-Public” (Uhl) vorhaben, und das werden laut Lisog täglich mehr.
Auf dem Vormarsch
Der ungebrochene Trend zu Virtualisierung und neue Technologien für Web-Applikationen (RIA, Ajax, Flash undFlex, Open Laszlo, HTML 5) sorgen dafür, dass immer mehr lokale Anwendungen ins Web wandern. Sam Somashekar von CA [27] nennt vier komplexe Anforderungen, die Admins bei der Umstellung in die Wolke die berücksichtigen müssen:
- Monolithische Applikationen werden dynamisch und modular.
- An die Stelle physikalischer Infrastruktur tritt virtuelle
Hardware. - Die Organisationsform ändert sich: Viele, isolierte
Domänen ersetzen die heute üblichen wenigen
Kontrollbereiche. Das macht globale Entscheidungen bezüglich
Policies und SLAs schwieriger, sie werden in Zukunft eher dezentral
umgesetzt. - Businessmodelle verändern sich: Aus Pay-per-instance wird
Pay-per-use. Investitionen (CAPEX) sinken, Betriebskosten (OBEX)
steigen
Egal, was der IT-Leiter vom Marketing-Gedudel der großen Cloud-Anbieter hält, eines bleibt: Fast alle technischen Features des Cloud Computing sind im Unternehmen schon lange angekommen. Neu ist nur deren Kombination und Management. Angebote wie Amazons EC2 machen zwar vieles einfacher, lösen aber Probleme nicht automatisch. Der Open-Source-Szene hilft das mit dem Cloud Computing wachsende Bewusstsein für freie Software sehr. (mfe)






