Tag: Technology


Der Amazon EC2 Workflow

Die folgende Graphik verdeutlicht den grundsätzlichen Ablauf zum Verwenden von Amazon EC2.

  • 1. Zunächst wird ein AMI (Amazon Machine Image) von Grund auf neu, oder auf Basis eines bereits vorhandenen AMIs erstellt. Dieser Vorgang ist optional, da Instanzen aus bereits vorhandenen AMIs gestartet werden können, ohne diese vorab zu verändern.
  • 2. Für ein AMI das einen lokalen Instanzspeicher für sein Root Device verwendet, muss der Prozess zum bundlen und registrieren des AMIs erfolgen. Für ein AMI hingegen, dass ein Amazon EBS Volume verwendet, reicht es aus, den create Image Befehl auf einer bereits gestarteten Instanz auszuführen. Amazon EC2 gibt anschließend eine AMI ID zurück, wodurch auf Basis des AMI so viele Instanzen wie gewünscht gestartet werden können.
  • 3. Starten einer oder mehrerer Instanzen eines AMI.
  • 4. Verwalten und verwenden der Instanzen als wären es gewöhnliche Server.

Quelle



UEC: Zusammenstellen von Images für Ubuntu 9.10

Dieser Artikel beschreibt das Vorgehen (Bundling) für das Erstellen und die Registrierung von VM Images mit dem UEC Cloud Controller für Ubuntu 9.10. Dazu benötigen wir ein Image, dass von den Daily Builds heruntergeladen werden kann, verknüpfen alles miteinander und laden es in unsere Ubuntu Cloud.

1. Um den Vorgang von der Kommandozeile aus zu starten nutzen wird die folgenden Befehle. Hierbei wird automatisch ein UEC Image heruntergeladen.

TIMESTAMP=$(date +%Y%m%d%H%M%S)
RELEASE=karmic
ARCH=amd64 # Or this might be i386
[ $ARCH = "amd64" ] && IARCH=x86_64 || IARCH=i386
UEC_IMG=$RELEASE-server-uec-$ARCH
URL=http://uec-images.ubuntu.com/$RELEASE/current/
[ ! -e $UEC_IMG.tar.gz ] && wget $URL/$UEC_IMG.tar.gz # This may take a bit, depending on your connectivity

2. Als nächstes muss alles verpackt, hochgeladen und registriert werden. In dem Package cloud-utils befindet sich das Tool uec-publish-tarball. Mit diesem können die oben genannten Aktionen in einem Schritt durchgeführt werden. Weiterhin ist in den cloud-utils das Tool uec-publish-image vorhanden. Mit diesem kann direkt mit einem ungepackten Image gearbeitet werden.

uec-publish-tarball ${UEC_IMG}.tar.gz "${RELEASE}-${TIMESTAMP}" "${ARCH}"

Diese Schritte sind nur dann notwendig, wenn nicht das Tool uec-publish-tarball verwendet wird!

1. Entpacken des UEC Image Tarball

[ ! -e $UEC_IMG.img ] && tar -S -xzf $UEC_IMG.tar.gz

2. Zusammenstellen des Kernels

BUCKET_KERNEL="k-$TIMESTAMP"
UEC_KERNEL=$UEC_IMG-vmlinuz-virtual
euca-bundle-image -i $UEC_KERNEL -r $IARCH --kernel true
euca-upload-bundle -b $BUCKET_KERNEL -m /tmp/$UEC_KERNEL.manifest.xml
EKI=$(euca-register $BUCKET_KERNEL/$UEC_KERNEL.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $EKI

3. Zusammenstellen der initrd (Wird nur benötigt, wenn keine Ramdisk vorhanden ist)

BUCKET_INITRD="r-$TIMESTAMP"
UEC_INITRD=$UEC_IMG-initrd-virtual
euca-bundle-image -i $UEC_INITRD -r $IARCH --ramdisk true
euca-upload-bundle -b $BUCKET_INITRD -m /tmp/$UEC_INITRD.manifest.xml
ERI=$(euca-register $BUCKET_INITRD/$UEC_INITRD.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $ERI

4. Zusammenstellen des Images

BUCKET_IMAGE="i-$TIMESTAMP"
UEC_IMG=$RELEASE-server-uec-$ARCH
euca-bundle-image -i $UEC_IMG.img -r $IARCH --kernel $EKI ${ERI:+--ramdisk ${ERI}} # This will take a long time (~10m)
euca-upload-bundle -b $BUCKET_IMAGE -m /tmp/$UEC_IMG.img.manifest.xml
EMI=$(euca-register $BUCKET_IMAGE/$UEC_IMG.img.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $EMI

3. Damit ist der Kernel und das Image in unsere Ubuntu Cloud (Eucalyptus) hochgeladen worden und kann nun genutzt werden.

euca-describe-images

Wir sollten einen registrierten Kernel sowie ein Image sehen, die als "available" markiert sind.

Mit dem anschließenden Befehl können wir das überprüfen.

Quelle



Fallbeispiel: Cloud Computing im Unternehmenseinsatz

Um die Möglichkeiten des Cloud Computing im Unternehmenseinsatz darzustellen, wird am Beispiel eines fiktiven Unternehmens, der Spielwaren GmbH, die IT-Infrastruktur analysiert und ein Handlungskonzept für die Migration in die Cloud vorgestellt.

Ausgangssituation

Die Spielwaren GmbH ist ein weltweit agierendes Unternehmen mit vier Standorten in Deutschland, den USA, China und Indien. Das Unternehmen erzielt mit seinen knapp 3.500 Mitarbeitern weltweit einen Umsatz von ca. 1 Milliarde US Dollar pro Jahr. Die IT-Umgebung des Unternehmens wurde in den letzten Jahren weitestgehend nur dann aktualisiert, wenn die Notwendigkeit durch Ausfall eines Servers oder ähnliches bestand. Die Systemumgebung setzt sich wie folgt zusammen.

  • Customer Relationship Management: Microsoft Dynamics CRM
  • Enterprise Resource Planing: Microsoft Navision
  • Verzeichnisdienst/ Domain Controller: Microsoft Active Directory Services
    (ADS)
  • Kommunikationsserver/ E-Mail-Server: Microsoft Exchange 2000
  • Applicationserver: Microsoft Windows 2000 Server
  • Fileserver: Microsoft Windows 2000 Server (für Office Dokumente)
  • Webserver: Microsoft Internet Information Server
  • Betriebssysteme: Windows 2000 Professional
  • Anwendungssoftware: Microsoft Office 2000

Die Kommunikation der Standorte findet über SDSL VPN-Verbindungen statt. Die beschriebene Systemumgebung gilt für jeden Standort. Eine Skizze der IT-Infrastruktur ist in der folgenden Graphik illustriert.

Ausgangssituation der Spielwaren GmbH

Analyse der IT-Umgebung

Eine Analyse der IT-Infrastruktur führte zu folgendem Ergebnis.

  • Microsoft Dynamics CRM: ok
  • Microsoft Navision: veraltet
  • Microsoft Active Directory Services: ok
  • Microsoft Exchange 2000: veraltet, die Maintenance durch Microsoft endet im Juli 2010, Lizenzen können nicht mehr nachbestellt werden.
  • Microsoft Windows 2000 Server: veraltet, die Maintenance durch Microsoft endet im Juli 2010, Lizenzen können nicht mehr nachbestellt werden.
  • Webserver: überdimensioniert, Erweiterungen ohne Konzept, Jahresdurchschnitt ca. 15% Belastung, Hauptzeiten: 80% Zuwachs
  • Windows 2000 Professional: veraltet, die Maintenance durch Microsoft endet im Juli 2010, Lizenzen können nicht mehr nachbestellt werden.
  • Microsoft Office 2000: veraltet, die Maintenance durch Microsoft endet im Juli 2010, Lizenzen können nicht mehr nachbestellt werden.
  • Arbeitsplatzrechner: überwiegend veraltete Systeme, die in den nächsten ein bis zwei Jahren ausgetauscht werden müssen(!)
  • VPN-Verbindungen: instabil(!), der Datenverkehr nimmt durch steigende Synchronisationen zu.

Generell gilt für die vorhandenen Rechenzentren: Die Hardware bei 80% der Server ist am Limit bzw. veraltet und muss dringend augetauscht werden.

Handlungskonzept

Auf Basis der Analyse und der Sondierung des Cloud Computing Marktes erhält die Spielwaren GmbH folgende Handlungsempfehlung.

  • Microsoft Dynamics CRM: Ablösung durch Salesforce.com
  • Microsoft Navision: Ablösung durch Salesforce.com
  • Microsoft Active Directory Services: Migration zu Google Apps mittels Directory Sync, Integration von Salesforce.com in Google Apps Professional mittels Salesforce for Google Apps
  • Microsoft Exchange 2000: Ablösung durch Google Apps Professional (Mail & Kalender)
  • Microsoft Windows 2000 Server: können entfallen, da sämtliche Office Dokumente auf Google Apps abgelegt werden, ggf. können auf GoGrid Fileserver angemietet und über entsprechende APIs mit Salesforce und Google Apps verbunden werden.
  • Webserver: Go Grid Server (Baukastensystem bestehend aus Load Balancer, Datenbankserver, Webserver und Speicherplatz) auf Linux oder Windows Basis
  • Windows 2000 Professional: Kann durch eine Linux Distribution z.B. Ubuntu Linux ausgetauscht werden
  • Microsoft Office 2000: Ablösung durch Google Apps Professional (Text & Tabellen)
  • Arbeitsplatzrechner: Schrittweise Ablösung der Fat-Clients durch Thin-Clients
  • VPN-Verbindungen: Die SDSL Leitungen bleiben vorhanden, die Kommunikation erfolgt vollständig über die Cloud

Die beschriebene Handlungsempfehlung gilt für die gesamte IT-Umgebung der Spielwaren GmbH, wodurch alle Standort betroffen sind. Eine Skizze der möglichen IT-Infrastruktur nach Umsetzung der Handlungsempfehlung ist in der folgenden Graphik illustiert.

Handlungskonzept für die Spielwaren GmbH

Vorteile

Die Migration würde der Spielwaren GmbH folgende Nutzen bringen.

  • Reduzierung der Kosten
    • Lizenzkosten für Software
    • Hardwarekosten (Server, Desktop)
    • Maintenance-Kosten
    • Personalkosten
  • Erhöhung der Datensicherheit
    • Automatisierte Durchführung von Backups durch den Anbietern
  • Optimierung der Zusammenarbeit
    • Standortübergreifende Zusammenarbeit durch Web-Kollaboration
  • Automatisierung der Softwarewartung
    • die Anwendungssoftware ist immer auf dem aktuellen Stand
  • Steigerung der Flexibilität
    • Mitarbeiterverwaltung
    • Hinzufügen neuer Anwendungen
  • Mobilität
    • Mitarbeiter können von überall arbeiten
    • Zugriff auf alle Daten von überall
  • Konzentration auf Kernkompetenzen
    • Erhöhung der Investitionen in das Kerngeschäft

Nachteile

Neben den Nutzen birgt die Migration aber auch einige Gefahren, die aufgezeigt werden müssen.

  • Politische Einflüsse
    • Politische Spionage/ Einschränkungen über die Internetverbindungen (z.B. China)
  • Single point of failure
    • Internetverbindung (kann durch Backupleitungen abgesichert werden)
  • Ausfall eines Anbieters
  • Datensicherheit(!)
    • Alle unternehmenskritischen Informationen befinden sich auf fremden Servern
  • Standorte der Server
    • Ist in der Cloud nicht transparent
  • Abhängigkeit
    • Die Standards der Anbieter müssen eingehalten werden

Kostenbetrachtung

Um den finaziellen Vorteil mit Zahlen zu verdeutlichen, wird die vorgeschlagende Google Apps Professional dem vergleichbaren Microsoft Exchange Server gegenüber gestellt. Die Aufstellung der Kosten ist in der folgenden Graphik nachzuvollziehen.

Vergleich der Kosten von Google Apps Professional mit einer Microsoft Exchange Lösung

Der Vergleich zeigt den deutlichen finanziellen Vorteil durch den Einsatz der Google Apps Professional Lösung. Über einen Zeitraum von drei Jahren liegen die Ersparnisse pro Benutzer bei ca. 62,00 EUR im Vergleich zur Microsoft Exchange Lösung. Das liegt zum einen an den geringeren Lizenzkosten der Google Lösung (Ersparnis: 98.000 EUR), zum anderen an den geringeren Wartungs- (Ersparnis: 53.000 EUR) und Administrationskosten (Erspanis: 68.000 EUR) sowie an den fehlenden Investitionskosten in eine eigene Infrastruktur für die Server (Ersparnis: 20.400 EUR). Werden die gesamten Wartungs-, Administrations und Infrastrukturkosten herausgerechnet (letzte Zeile), liegt der Kostenvorteil der Google Lösung über einen Zeitraum von drei Jahren nur noch bei ca. 8,00 EUR pro Mitarbeiter.

Dieser Vergleich zeigt, wie die Infrastruktur- und Wartungskosten durch den Einsatz von Cloud Computing signifikant gesenkt werden können.

Reflexion

Die Handlungsempfehlungen, die für dieses Beispiel gewählt wurden, sind bewusst ein wenig extrem aber verdeutlichen gleichzeitig, was bereits heute mit dem Cloud Computing für Möglichkeiten bestehen. Ein Unternehmen muss sich gut überlegen, ob es seine Infrastruktur bzw. die unternehmenskritischen Daten in der Form so auslagern möchte. Zu groß ist z.B. das Risiko der Datensicherheit. Werden auf der anderen Seite aber Kunden von Google (Motorola und Procter & Gamble) und Salesforce.com (Dell, Dow Jones und Morgen Stanley) herangezogen, sollte die Attraktivität dieses Outsourcingmodells nicht vernachlässigt werden. Zu so einer Entscheidung gehört auch immer eine subjektive Betrachtung, bei der die Kosten eine immer größer werdene Variable in der Gleichung werden. Aus diesem Grund müssen auch Kompromisse geschlossen werden, wenn Kosten gesenkt werden sollen. Ob die Datensicherheit dabei zweitrangig behandelt werden darf bleibt fraglich.



Scalarium

Scalarium, das Cloud Computing Produkt der Peritor GmbH dient zur Automatisierung der Kommunikation und Konfiguration von Amazon EC2 Cluster.

Eine Beispielkonfiguration für einen Cluster würde z.B. aus einem Load Balancer, drei Rails Applikations-Servern und einem Datenbankserver bestehen. Für den Start dieses Clusters ist anschließend Scalarium verantwortlich, indem es eine Verbindung zur Amazon Compute Cloud (EC2) herstellt und die entsprechenden Instanzen startet. Die Images werden geladen und der Scalarium Agent installiert.

Der Scalarium Agent wird auf jedem Server ausgeführt und ist über eine verschlüsselte Verbindung ständig mit Scalarium in kontakt. Webserver werden dabei automatisch mit Nginx konfiguriert, während Datenbankserver eine MySQL Installation erhalten. Nachdem der Scalarium Agent auf einer Instanz installiert wurde und das System konfiguriert hat, wird die Instanz als online markiert und kann durch den Cluster verwendet werden.

Scalarium bietet die folgenden vier Funktionen, die im Anschluß jeweils kurz vorgestellt werden.

  • Auto Config
  • Auto Healing
  • Auto Scaling
  • One Click Deploy

Auto Config

Mittels der Auto Configuration werden die Server automatisiert konfiguriert, indem die benötigte Software installiert und eingerichtet wird. Werden weitere Instanzen hinzugefügt, konfiguriert Scalarium automatisch die Anwendungen und den gesamten Cluster. Die einzigen Informationen die von Scalarium dazu benötigt werden sind die gewünschten Ubuntu Packages und Rubygems. Anschließend werden alle Pakete und Libraries auf jedem Server installiert und das zu jederzeit.

Weitere Informationen zu Auto Config sind HIER zu finden.

Auto Healing

Mit Auto Healing sorgt Scalarium dafür, dass die vorher festgelegten Services und Hosts des Cluster im Fehlerfall automatisch wiederhergestellt werden. Fällt z.B. ein Server aus, wird dieser durch Scalarium entfernt und in kurzer Zeit durch eine neue Instanz ersetzt, wodurch der gesamte Cluster automatisch neu konfiguriert wird.

Weitere Informationen zu Auto Healing sind HIER zu finden.

Auto-Scaling

Durch das Auto-Scaling können Schwellwerte festgelegt werden die dafür sorgen, dass entweder weitere Instanzen gestartet oder nicht mehr benötigte Instanzen beendet werden. Dazu überwacht Scalarium die CPU- und Arbeitspeicher-Auslastung, sowie die durchschnittliche Belastung jeder Instanz.

Weitere Informationen zu Auto Scaling sind HIER zu finden.

One Click Deploy

Mittels One Click Deploy können Anwendungen über den gesamten Cluster hinweg zu einem Zeitpunkt vollständig automatisiert verteilt, installiert und konfiguriert werden.

Weitere Informationen zu One Click Deploy sind HIER zu finden.

Demo Video

http://www.youtube.com/watch?v=F2UzrYOZNM4

Preise

Quelle



Vorteile durch Desktop-Virtualisierung!

Was ist Desktop-Virtualisierung?

Im Vergleich zu klassischen Desktop-PCs werden virtuelle Desktops als virtuelle Maschinen wie eine zentral verwaltete Ressource betrachtet und im Rechenzentrum bereitgestellt. Das führt dazu, dass die Konfiguration und Verwaltung nicht mehr auf dem physikalischen Endgerät eines Benutzers stattfindet, sondern innerhalb der virtuellen Maschine.

Auf einem zentralen Rechner werden dabei mehrere individuelle Betriebssysteminstanzen für mehrere Benutzer zur Verfügung gestellt, wodurch jeder Benutzer in (s)einer eigenen virtuellen Umgebung arbeitet. Der Benutzer merkt nicht, dass seine Systemumgebung virtualisiert ist, da sich sein Gesamtsystem wie ein gewöhnlicher Desktop-PC verhält.

Es lassen sich drei Typen von virtuellen Desktops klassifizieren:

  • Standard Desktop
    Dabei handelt es sich um einen gewöhnlichen Desktop, der für alle Benutzer gleich aufgebaut und so ausgestattet ist, das Büroaufgaben damit ohne weiteres erledigt werden können.
  • Personalisierter Desktop
    Auf Basis von virtuellen Maschinen werden auf den Servern für jeden Benutzer individuell eingerichtete virtuelle Desktops bereitstellen, die dort zentral gepflegt und verwaltet werden. Die Anwender haben zudem die Möglichkeit selbständig Änderungen vorzunehmen.
  • High-End Desktop
    Wird eine enorme Leistung benötigt, erhält jeder Benutzer auf Basis von Blade PCs seine eigene Instanz im Rechenzentrum. Der Desktop wird dabei auf dem Blade PC ausgeführt, wodurch der Benutzer die vollständigen Ressourcen wie z.B. die Prozessorleistung alleine für sich nutzen kann.

Vorteile und Nutzen der Desktop-Virtualisierung

Durch die Trennung des Desktops von dem physikalischen Endgerät kann die Administration zentral auf einem Server vorgenommen werden, womit der Wartungsaufwand reduziert wird, da die Installation, Konfiguration und Aktualisierung nicht mehr vor Ort vorgenommen werden muss. Speziell im Falle von Migrationen stehen hier enorme Zeitvorteile im Vordergrund. So kann z.B. in kurzer Zeit die Umstellung auf eine neue Betriebssystemversion vorgenommen werden.

Weiterhin können die Kosten für die Client-Hardware gesenkt werden. Aktuelle Windows Betriebssysteme benötigen performante und damit kostspielige Endgeräte. Durch die Virtualisierung des Desktops können entweder ältere Endgeräte oder Thin Clients eingesetzt werden, die zudem stromsparend und wartungsarm sind. Laut einer IDC Kundenbefragung können die Kosten, im Vergleich zu herkömmlichen Desktop PCs (Fat Clients), um ca. 600 Dollar pro Benutzer pro Jahr gesenkt werden.

Ein weiterer zu beachtender Punkt ist die Erhöhung der Sicherheit. Die Daten befinden durch die Desktop-Virtualisierung nicht mehr lokal auf den Endgeräten, sondern werden zentral auf den Unternehmensservern gespeichert. Somit werden die Daten zusätzlich in die zentralen Datensicherungsmechanismen eingegliedert und der Zugriff auf die Daten wird zentral gesteuert. Die Compliance kann ebenfalls unternehmensweit verbessert werden, da die Installation von unerwünschter Software zentral unterbunden werden kann und es kann sichergestellt werden, dass die Daten im Rechenzentrum verbleiben.

In Unternehmen die mit wechselnden Arbeitsplätzen arbeiten, erhalten die Benutzer den Vorteil, immer über ihre eigene tatsächliche Umgebung zu verfügen. Der Nachteil der "Roaming Profiles" besteht darin, dass die Installation & Konfiguration des Betriebssystems und der darauf installierten Software für jeden Benutzer, der an dem Rechner arbeitet, gleich ist. Im Falle der Desktop-Virtualisierung ist ein Benutzer damit (wirklich) nicht mehr an einen bestimmten Arbeitsplatz (Ort) gebunden.

Anforderungen & Herausforderungen der Desktop-Virtualisierung

Desktop-Virtualisierung ist kein Thema, dass kurzfristig umgesetzt werden kann, sondern bedarf einem gut durchdachten und ganzheitlichen Ansatz. Dazu gehören neben der Administration der virtuellen Desktops, ebenso die benutzerspezifische Anpassung und die Gewährleistung der Geschwindigkeit und Performanz. Letzteres ist vor allem kritisch zu betrachten, wenn ein Unternehmen über mehrere Standorte verteilt ist und der Zugriff über eine WAN-Verbindung stattfindet. Die Berücksichtigung der gesamten IT-Infrastruktur ist bei der Einführung und Implementierung von Desktop-Virtualisierung von enormer Wichtigkeit. Wozu eine ganzheitliche Betrachtung und ebenfalls Technologien zur Optimierung und Überwachung der WAN-Verbindungen und Performanz sowie des sicheren Zugriffs gehören.



IBM Smart Business Services

Mit den IBM Smart Business Services bietet IBM standardisierte Services auf Basis der IBM Cloud oder Private-Cloud-Services die von IBM verwaltet werden. Zu dem Leistungsumfang gehören u.a. das Infrastrukturdesign, die Beachtung einer hohen Verfügbarkeit sowie Sicherheitsimplementierungen.

Zwei bereits definierte und veröffentlichte Angebote sind das Development und Test Workload Angebot, dazu gehört die IBM Smart Business Test Cloud und das Desktop Workload Angebot, zu welchem die IBM Smart Business Desktop Cloud gehört.

IBM Smart Business Test Cloud

Bei der IBM Smart Business Test Cloud handelt es sich um eine Privat Cloud die auf die Technologien und Konzepte der IBM Public Cloud basiert. Mit der IBM CloudBurst Hardware wird dazu die Implementierung und das Management der Cloud vorgenommen, um die vorhandene Infrastrukturen mit der IT-Topologie innerhalb der Cloud zu verbinden. IBM verspricht damit Einsparungen bei den Kapital- und Lizenzierungskosten von bis zu 75%, sowie eine Kostenreduzierung der Betriebs- und Personalkosten um bis zu 50%. Weiterhin sollen mit standardisierten und einfach bereitzustellenden Services Softwaremängel reduziert werden, die auf Grund von fehlerhaften Konfigurationen und mangelhafter Modellierung entstehen.

Funktionen und Vorteile der IBM Smart Business Test Cloud

  • Reduzierung von Personalkosten für Konfiguration, Betrieb und Überwachung durch automatisierte Self-Service-Bereitstellung.
  • Risikominderung und Verbesserung der Qualität durch ein vereinfachtes Management
  • Verringerung der Lizenzkosten.
  • Effektiverer Kapitaleinsatz und flexible Skalierung durch Virtualisierung.

IBM Smart Business Desktop Cloud

Mit dem IBM Smart Desktop Cloud können Benutzer mit einem Thin Client oder eines Desktop-PCs mit Java™ und einem Web-Browser eine Verbindung zu einem Betriebssystem (virtuelle Maschine) auf einem zentralen Server herzustellen. Als Betriebssysteme können Windows oder Linux verwendet werden, deren Desktopumgebungen vollständig standardisiert sind und als Image vorliegen.

Funktionen und Vorteile der IBM Smart Business Desktop Cloud

  • Schnelle Skalierung der IT-Infrastruktur.
  • Steigerung des Return-on-Investment (ROI) und Reduzierung des Total Cost of Ownership (TCO, Gesamtbetriebskosten), durch flexibleren Betrieb und Energieeinsparungen.
  • Abrechnung der Betriebskosten nach dem tatsächlichen Bedarf.

Quelle

  • IBM Smart Business Services


IBM Smart Business Systems

Mit den Smart Business Systems stellt IBM integrierte Plattformen für die Servicebereitstellung inkl. Managementfunktionen für Hardware, Speicher, Netze, Virtualisierung und Services bereit, mit denen Lastoptimierte Systeme aufgesetzt werden können.

Zu den aktuellen Angeboten gehören die IBM CloudBurst™ Family (IBM CloudBurst 1.1) und die WebSphere CloudBurst Appliance.

IBM CloudBurst™ Family

Bei der IBM CloudBurst™ handelt es sich um ein IBM Service Management-Paket, mit dem die vorhandene IT-Infrastruktur erweitert werden kann. Dazu zählen Hardware-, Software- und Service-Lösungen für den Einsatz einer Private Cloud.

IBM CloudBurst 1.1

IBM CloudBurst 1.1 bietet auf Basis der IBM BladeCenter®-Plattform bereits vorinstallierte und integrierte Management-Funktionen für die Verwaltung der Hardware, Middleware und vorhandener Applikationen.

Funktionen und Vorteile der IBM CloudBurst 1.1

  • Schnellere Wertschöpfung durch bereits vorinstallierte und vorkonfigurierte Umgebung.
  • Flexibilität auf Basis einer skalierbaren Plattform.
  • Self-Service-Portal zur schnellen Bereitstellung von Cloud-Services.
  • Eine zentrale Schnittstelle zur Verwaltung physischer und virtueller Workloads und Systeme.
  • Verringerung des Ausfalls des Gesamtsystems durch mehrere Redundanzebenen.
  • Steigerung der Energieeffizienz durch die Möglichkeit des aktiven Managements des Stromverbrauchs der BladeCenter.

WebSphere CloudBurst Appliance

Mit der IBM WebSphere CloudBurst Appliance kann auf virtuelle WebSphere-Images zugegriffen werden, um das Erstellen, Implementieren und Management von Anwendungsumgebungen in einer Private Cloud vorzunehmen.

Funktionen und Vorteile der WebSphere CloudBurst Appliance

  • Verringerung der Einrichtung von WebSphere-Umgebungen
  • Vordefinierte Muster und virtuelle Images
  • Überwachung der Nutzung zur Leistungsverrechnung (Abrechnung der tatsächlichen Nutzung) durch Managementberichte

Quelle

  • IBM Smart Business Systems


Was sind Application Service Provider?

Als die indirekten Nachkommen der Service Bureaus gelten die Application Service Provider. Application Service Provider sind Dienstleister, die über eine Datenverbindung Anwendungssoftware wie z.B. ein CRM-System (Customer Relationship Management) anbieten, das von einem Kunden gegen eine Nutzungsgebühr gemietet werden kann - siehe Graphik. Der Vorteil für den Kunden besteht darin, dass er sich nicht mehr um die Administration der Software wie z.B. eine tägliche Datensicherung oder das Einspielen von Updates kümmern muss. Die Software befindet sich innerhalb der Infrastruktur auf den Servern des Application Service Providers, der sich um die gesamte Maintenance, was auch die Betreuung der Endbenutzer beinhalten kann, kümmert. Bekannte Anwendungen, die über einen Application Service Provider gemietet werden können, sind z.B. Office Suites, E-Mail Lösungen, CRM-System oder ERP-Systeme (Enterprise Resource Planning).

In der Anfangszeit der Application Service Provider gab es immer wieder Schwierigkeiten bei der Umsetzung dieses Modells, da die zu der Zeit vorhandene Hardware und die Telekommunikationstechnologie nicht leistungsfähig genug und die Mandantenfähigkeit der Software nicht gegeben war.




Was ist Grid Computing?

Die Charakteristiken von Computercluster sind das Bereitstellen von reiner Rechnerleistung in einem lokalen begrenzten Bereich. Die nächste Herausforderung bestand also darin, die Rechenleistung nicht nur lokal, sondern auch global verfügbar zu machen und neben der Rechenleistung z.B. auch Daten und Applikationen bereitzustellen.

Mitte der 1990er wurde der Begriff des Metacomputing als Möglichkeit zur Erweiterung von Paralleler Datenverarbeitung und Custer Computing eingeführt. Die Idee bestand darin, große Computersysteme über WAN-Leitungen (Wide Area Network) miteinander zu verbinden. Im Jahr 1997 wurden erstmals zwei Supercomputer des High Performance Computing Center Stuttgart (HLRS) und des Pittsburgh Supercomputing Centre (PSC) miteinander verbunden. Trotz der Verfügbarkeit von hohen Bandbreiten innerhalb der nationalen und internationalen Forschungsnetzwerke scheiterte das Experiment auf Grund der Latenz.

Das Metacomputing bezieht sich aber lediglich nur auf Computer (Rechenleistung) im Allgemeinen. Ian Foster und Carl Kesselman stellten im Jahre 1999 ein neues erweitertes Konzept mit dem Namen Grid Computing vor, das neben Computer auch andere Arten von (IT-)Ressourcen wie Software, Datenbanken, Rechenleistung, Speicherplatz oder spezielle Hardware beinhalten und miteiander vernetzen kann. Der Begriff des Grid wird abgeleitet aus dem englischen Wort Electrical Power Grid (Deutsch: Stromnetz), dessen Idee darin besteht, die Ressourcen den Benutzern so zur Verfügung zu stellen, als wenn sie den Strom aus der Steckdose bekommen würden. Dabei verfügt das Grid über standardisierte Schnittstellen, über die der Benutzer seine Anfragen übermitteln kann und ihm die Ressourcen dann automatisiert zugeteilt werden. Die Ressourcen sind dabei über das Internet verteilt und können unterschiedlichen ’virtuellen’ Organisationen angehören. Anhand der Schnittstellen kann der Status der Ressourcen abgefragt und diese direkt angesprochen werden. Ein entscheidender Vorteil liegt darin, dass der geographische Ort an dem sich die Ressource befindet nicht mehr von Bedeutung ist - siehe Graphik. Auf Grund des beliebigen und weltweiten Zugriffs auf Ressourcen über das Internet gilt das Grid als Generalisierung des World Wide Web. Davon abgeleitet steht die Technologie des Grid Computing somit als die Basistechnologie für die Koordination und Verarbeitung organisationsübergreifender Geschäftsprozesse und den gemeinschaftlichen Austausch und die Nutzung von Ressourcen.

Das entscheidende Ziel des Grid Computings bestand also darin, Ressourcen gemeinschaftlich global zu nutzen sowie diese zu koordinieren und darüber hinaus gemeinsam Probleme institutionsübergreifend in dynamischen virtuellen Organisationen zu lösen. Genauer bedeutet dies, dass zu Beginn Formalitäten wie das Abrechnungsschema und die Zugangsrechte geklärt werden und anschließend der Zugriff auf die Ressourcen wie z.B. Rechnerleistung oder Anwendungen für die gemeinschaftliche Nutzung bereitgestellt werden. Der Begriff der virtuellen Organisation beschreibt in diesem Fall eine dynamische Allianz von Organisationen, die ein gemeinsames Interesse während der Nutzung des Grids vertreten.

Arten von Grid Computing

Je nachdem wie die Ressourcen miteinander vernetzt sind und um was für ein Anwendungsszenario es sich handelt, können Grids in unterschiedliche Arten unterteilt werden. Nachfolgend werden fünf unterschiedliche Arten betrachtet.

  • Compute Grids
    Compute Grids werden verwendet um einem Benutzer Rechnerleistung bzw. Rechnerkapazität, die ihm in seiner eigenen Umgebung nicht zur Verfügung stehen, verteilt bereitzustellen. Das Bereitstellen kann hierbei eine derzeit nicht verwendete Ressource - z.B. eine Workstation außerhalb der Geschäftszeiten sein, oder aber auch ein Hochleistungclustersystem.
  • Data Grids
    Data Grids werden eingesetzt um große verteilte Datenmengen gemeinsam zu Nutzen und diese zu verarbeiten. Dabei wird eine sogenannte Data-Federation, eine organisationübergreifende Sicht auf alle Daten, die beispielsweise einem Projekt zugewiesen sind, definiert. Bei so einer Data-Federation handelt es sich um ein dezentral verwaltetes System, bei dem derjenige, der die Daten in dieser Umgebung zur Verfügung stellt auch die uneingeschränkte Kontrolle über diese Daten behält.
  • Application Grids
    Application Grids waren der erste Ansatz um virtuelle Organisationen zu etablieren und damit die organisationsübergreifende gemeinsame Nutzung von Ressourcen voranzutreiben. Die Betreiber der Grids sollten dadurch eine höhere Auslastung und die Benutzer ein besseres Angebot erfahren. Themen, die innerhalb dieses Grids auftreten, sind sichere und schnelle Datenverbindungen, Authentifikationen, Authorisierungen und Single-Sign-On sowie Accounting und Abbrechnungsmöglichkeiten.
  • Resource Grids
    Resource Grids sind die Erweiterung der Application Grids. Diese definieren ein Rollenmodell, in dem eindeutig zwischen einem Grid Benutzer, einem Grid Provider und einem Resource Provider unterschieden wird. Die Hierarchie ist logisch geordnert. Ein Grid Benutzer verwendet die Grid Infrastruktur des Grid Provider um die dort vorhandenen Ressourcen des Resource Providers zu nutzen. Für den Grid Benutzer unterscheidet sich die Funktionalität des Application- und des Resource Grids nicht. Das Konzept der beiden hat aber einen gravierenden Unterschied. Application Grids werden vertikal integriert, was bedeutet dass der Bedarf an Fremdleistungen sehr gering gehalten wird und die Komponenten individuell hinzugefügt werden. Dagegen müssen bei einem Resource Grid alle Schnittstellen definiert und offen gelegt werden, da jeder Ressource Provider über die Spezifikation der Grid Infrastruktur des Grid Providers informiert sein muss um dort ggf. seine Ressourcen anbieten zu können.
  • Service Grids
    Ein Service Grid verbindet das Konzept der Serviceorientierung mit der Technik der Resource Grids. Ein Service wird in diesem Zusammenhang als ein Bündel von mehreren Komponenten betrachtet, von dem jede einzelne Komponente wiederum als Utility von einem anderen Resource Provider zur Verfügung gestellt wird. In dieser Form des Grids existiert eine übergeordnete Form des Grid Providers, der so genannte Grid Service Provider, der im direkten Kontakt mit den Grid Benutzern steht und ihnen einen Komplettservice anbietet. Das bedeutet, dass der Grid Benutzer nicht darüber informiert ist, welcher Resource Provider ihm welche Ressource bereitstellt.


Enomalys – ECP Cloud Service Provider Edition

Mit der Enomaly Service Provider Edition steht eine von Enomaly auch "cloud in a box" genannte Plattform zur Verfügung, mit der Internetcarrier und Hosting Anbieter ihren Kunden Infrastructure as a Service Lösungen anbieten können.

Die Platform verfügt über eine Benutzerschnittstelle sowie eine REST API, mit der die Kunden die Verwaltung ihrer Cloud eigens vornehmen können. Ein weiteres Feature ist die "Theme Engine" mir der das Branding vom Internetcarrier oder Hosting Anbieter auf die jeweiligen Bedürfnisse angepasst werden kann. Weiterhin können mehrere Kunden eines Anbieters parallel auf einer einzigen Plattform verwaltet werden und ein Quota System sorgt für die gerechte Verteilung der Ressourcen. Die Plattform kann darüber hinaus in bereits bestehende Systeme für die Abbrechnung, Ressourcenversorgung und das Monitoring integriert werden.

Nach Angaben von Enomaly wird die Plattform derzeit von 15.000 Unternehmen weltweit eingesetzt.

Funktionen & Umgebung

Die Plattform verfügt u.a. über folgende Funktionen, die im weiteren Verlauf dieses Artikels jeweils kurz vorgestellt werden.

  • Managementkonsole für die Endkunden
  • Fernverwaltung
  • Flexible Hardware-Profile
  • Management für virtuelle Maschinen
  • Nutzungsabbrechnung
  • App Center
  • Virtual Private Cloud (Vlan)
  • Theme Engine
  • Gruppierung von virtuellen Maschinen

Managementkonsole für die Endkunden

Mit der Managementkonsole können Endkunden auf ihre virtuellen Maschinen zugreifen, diese verwalten und bekommen darüber die Fehlermeldungen des Systems angezeigt. Die Anbieter können mittels RSS Feeds die Inhalte entsprechend anpassen und darüber ihre eigenen Inhalte anzeigen.

Fernverwaltung

Mittels einer Remote Desktop Verbindung oder der Kommandozeile kann auf die virtuellen Maschinen zugegriffen werden, auch dann wenn keine Netzwerkverbindung nach Aussen hin besteht.

Flexible Hardware-Profile

Auf Basis von flexiblen Hardware Profilen können virtuelle Maschinen nach ihrer Bereitstellung durch den Endkunden angepasst und skaliert werden. Die Hochverfügbarkeit einer virtuellen Maschine wird dadurch garantiert, indem im Falle eines physikalischen Fehlers die virtuelle Maschine automatisch auf eine andere funktionsfähige Hardware übertragen wird.

Management für virtuelle Maschinen

Endkunden können entweder einzelne virtuelle Maschinen oder ganze Gruppen von virtuellen Maschinen weltweit und von jedem Rechner aus starten, stoppen und neu starten.

Nutzungsabbrechnung

Über die Nutzungsabbrechnung haben Endkunden einen Echtzeit-Überblick über die aktuell genutzen Ressourcen (virtuelle Maschinen, Arbeitsspeicher, CPUs und Speicherplatz) im Verhältnis zu den noch verfügbaren Ressourcen.

App Center

Mit dem App Center können Anbieter ihren Kunden bereits vor-konfigurierte Cloud Anwendungen, wie z.B. Betriebssysteme zur Verfügung stellen. Endkunden können aus den virtuellen Maschinen Images eines Anbieters virtuelle Maschinen erstellen und diese direkt ihrer Cloud hinzufügen, oder eigene virtuelle Maschinen verwenden.

Virtual Private Cloud (Vlan)

Für jeden Endkunden und dessen virtuellen Maschinen steht ein oder mehrere private VLANs zur Verfügung, die durch den Endkunden selber verwaltet werden können.

Theme Engine

Mit der Theme Engine kann jeder Anbieter das Branding, sowie das look & feel enstprechend seiner Bedürfnisse anapssen.

Gruppierung von virtuellen Maschinen

Mittels eines Tagging Systems (tags) können mehrere einzelne virtuelle Maschinen zu einer Gruppe von virtuellen Maschinen organisiert werden.

Quelle



Thin Clients

IT-Abteilungen leben neben einem erhöhten Kostendruck zusätzlich mit den Problemen der Sicherheit und der Aufrechterhaltung des IT-Betriebs.

Der in den letzten Jahren immer mal wieder aktuell gewordene und dann wieder verblasste Ansatz der Thin Client Nutzung kann der IT helfen diese Probleme zu bewältigen, verfügen Thin Clients doch gegenüber den klassischen Desktop PCs über einige Vorteile.

Zunächst sind Thin Clients - wie der Name schon andeutet - sehr einfach und weniger komplex als Desktop PCs. Das liegt zum einen an den geringeren und funktional beschränkten Hardwareressourcen, zum anderen an der eingesetzten Software. Die benötigte Software wird serverseitig betrieben, wodurch ein lokales "vollwertiges" Betriebssystem nicht benötigt wird. Diese beiden Kernpunkte sorgen dafür, das Thin Clients weniger sensibel bzgl. Fehler und Angriffe sind.

Von Desktop PCs wird heutzutage erwartet, dass sie 24/7 funktionsfähig sind. Dabei wird jedoch nicht bedacht, das nicht vorhersehbare Situationen, wie Hackerangriffe, der Ausfall der Hardware oder ganz einfach Benutzer dafür verantwortlich sind, das dem nicht so ist und niemand diese Erwartungen gewährleisten kann.

Speziell die Einflussnahme der Benutzer auf die Systemkonfiguration erhöht auf Thin Clients, durch das Beschränken oder vollständige entziehen der Rechte, die Systemstabilität und schützt den Benutzer und das gesamte Unternehmensnetzwerk vor Angriffen durch Viren, Würmer und jeglicher Form von Malware. Weiterhin wird die Stabilität und der Schutz erhöht, da Thin Clients ihre Anwendungen von einem oder mehreren zentralen Servern beziehen und nicht mehr - wie Desktop PCs - auf lokale Anwendungen und ein vollwertiges lokales Betriebssystem angewiesen sind.

Trotz hinreichender Anordnung speichern Benutzer ihre Daten generell auf der lokalen Festplatte und nicht wie gefordert auf die dafür vorgesehenen Netzlaufwerke, also auf den zentralen Servern. Nicht selten hört man von Fehlern der Festplatte die dazu führen, dass die Arbeit eines Tages in kurzer Zeit hinfällig war und erneut erledigt werden muss. Der Diebstahl der Daten sollte auch hier nicht außer acht gelassen werden. Auf der anderen Seite sind Benutzer in diesem Fall für Backups selber zuständig, was verständlicherweise gerne mal vergessen wird. Da Thin Clients über keine lokalen Daten verfügen, sind damit alle oben genannten Probleme hinfällig. Das Speichern der Daten erfolgt auf zentralen Servern, wo von ihnen jeden Tag automatisiert ein Backup vorgenommen wird. Dazu kommt, dass wenn keine lokalen Daten vorhanden sind, diese auch nicht gestohlen werden können. Zudem reicht es aus, Desktop-Firewall Konzepte serverseitig einzurichten, wodurch der Administrationsaufwand verringert wird.

Der letzte Themenbereiche behandelt die physikalische Sicherheit der Systeme. Werden Desktop PCs gestohlen, ist der Angreifer im schlimmsten Fall im Besitz unternehmenskritischer Daten (Festplattenverschlüsselung hin oder her). Thin Clients hingegen werden erst dann sinnvoll, wenn sie mit einem Server des Unternehmensnetzwerks verbunden sind und haben außerhalb des Unternehmens für den Angreifer keinen Nutzen. Auch der Diebstahl der Daten durch den Anschluss externer Geräte wie USB-Sticks oder USB-Festplatten oder das Übertragen von Viren etc. durch CDs stellt ein nicht zu verkennendes Problem dar. Der Zugriff kann bei Desktop PCs natürlich unterbunden werden. Das physikalische entfernen stellt sich jedoch als ziemlich schwierig und aufwendig dar. Fällt die Entscheidung daher auf Thin Clients, sollte mit den Gedanken gespielt werden sich gegen physikalische vorhandene USB-Ports und CD/DVD Laufwerke zu entscheiden.

All die oben beschriebenen Probleme der Desktop PCs können natürlich durch diverse Softwareangebote behoben werden. Jedoch verursachen diese wiederum Anschaffungs-, Installations- und Wartungskosten. Zudem ist die Verträglichkeit mit vorhandener (spezial)-Software nicht garantiert.

Erweitern wir den Thin Client Gedanken nun um das Thema Cloud Computing ist es durchaus vorstellbar, dass die Infrastruktur für die Terminalserver nun nicht mehr im eigenen Rechenzentrum steht, sondern als Appliance/Image oder einem Terminalserver in einer Cloud z.B. von Amazon, GoGrid oder einem anderen Anbieter gehostet wird. Ein Unternehmen müsste dann lediglich über die Hardwareressourcen (Thin Clients) und eine schnelle Internetverbindung verfügen. Das ist wohlgemerkt natürlich eine sehr abstrakte und ideale Sicht auf das Thema, die noch tiefer durchdrungen werden muss.

Quelle der Graphik

  • NetPoint


Glide OS

Mit eyeOS habe ich vor kurzem bereits einen Cloud Desktop vorgestellt. Heute folgt mit Glide OS nun der Zweite.

Wie bei eyeOS handelt es sich bei Glide OS in der aktuellen Version 4.0 um ein webbasiertes Betriebssystem, dass unabhängig von der Hardware und dem darauf ausgeführten "klassischen" Betriebssystem ausgeführt werden kann und auf das mit einem Standard Webbrowser zugegriffen wird. Der Zugriff kann dabei von einem gewöhnlichen PC (http://desktop.glidesociety.com/default.aspx) oder einem Smartphone (http://www.glidemobile.com/browser_index.aspx) stattfinden.

Zu folgenden Systemen ist Glide OS derzeit kompatibel:

  • Windows
  • Mac OS X
  • Linux
  • Solaris
  • Android
  • BlackBerry
  • iPhone
  • Palm Pre
  • Symbian
  • Windows Mobile

Für Android und Blackberry stehen zusätzlich proprietäre Anwendungen bereit, für iPhone/iPod Touch, sowie Palm und Symbian sollen welche folgen.

Für die Webbrowser Firefox, Internet Explorer und Chrome stehen darüber hinaus spezielle Plugins zur Verfügung.

Die Architektur von Glide OS basiert auf einem Mix aus C++, HTML, JavaScript (AJAX) und Flash Applikationen. Mit dem Glide Sync App können Daten zwischen dem Glide OS Desktop und dem lokalen PC ausgetauscht werden. Dabei werden die Daten zentral auf einem Glide OS Server gespeichert. Neben einem Programm zur Bildbearbeitung sind weitere Apps wie z.B. eine Office Suite (wobei ich eine Textverarbeitung nicht gefunden habe), ein E-Mail Client oder ein Kalender vorhanden. weitere Anwendungen inkl. Screenshots sind weiter unten zu sehen.

Glide OS ist ein zwei Versionen verfügbar. Die kostenlose bietet 30 GB Speicherplatz und kann von bis zu 6 unterschiedlichen Benutzern verwendet werden. Die Premium Variante kostet entweder $4.95 monatlich oder $49.95 pro Jahr. Das beinhaltet dann 250 GB Speicherplatz und 25 unterschiedliche Benutzer.

Screenshots & Anwendungen

Der Anmeldedialog

Der Startbildschirm nach der Anmeldung

Unter "Settings" können benutzerspezifische Einstellungen vorgenommen werden.

Mit "Draw" steht ein rudimentäres Malprogramm ähnlich Microsoft Paint zur Verfügung.

Mit dem "Address Book" können die Kontakte verwaltet werden.

Hinter "Stickies" verbergen sich Notizzettel für den Desktop.

Für die Synchronisation mit dem lokalen PC wird für jedes Betriebssystem eine spezielle Anwendung benötigt.

Mit dem "Calculator" steht auch ein wissenschaftlicher Taschenrechner bereit.

Beim Versuch den Text in der Textverarbeitung "Write" zu vergrößern, wurde meine Eingabe immer wieder gelöscht, daher nur fett!

Ein Blick auf den "Calender".

Die Präsentationsanwendung "Present".

Das Bildbearbeitungsprogramm "Photo Edit".

Mittels "Customize" kann das Aussehen des Desktops angepasst werden.

Quelle



Was ist Cluster Computing?

Handelte es sich bei Supercomputern zu Beginn noch um Systeme mit spezieller Technologie, werden heute in der Regel gängige Servertechnologien eingesetzt. Dabei werden viele einzelne, in der Regel kostengünstige Server zu einem so genannten Servercluster vernetzt, um über die Rechenleistung eines Supercomputers zu verfügen.

Die Grundlagen des Cluster Computing legte Gene Amdahl als Computerarchitekt bei IBM. In seinem 1967 veröffentlichten Paper zum Thema ’Parallel Processing’ stellte er folgende These auf, die auch als Amdahl’s Law bezeichnet wird und als Basis für Multiprozessor sowie Clustercomputer gilt.

Das Gesetz besagt, ’... wie sich der nicht parallelisierbare Anteil eines Programms auf die Gesamtrechenzeit auswirkt ...’. Genauer bedeutet dies, dass die Geschwindigkeitszunahme in erster Linie durch den sequentiellen Anteil des Algorithmus beschränkt wird. Das ist darauf zurückzuführen, dass sich die Ausführungszeit nicht durch Parallelisierung verkleinern lässt.

Die ersten Ideen einen Computercluster aufzubauen stammen aus den Zeiten, in denen auch die ersten Computernetzwerke aufgebaut wurden. Der Grundgedanke zum Aufbau solcher Netzwerke bestand darin, Ressourcen in Form von Computersystemen untereinander zu verbinden und damit einen quasi Computercluster aufzubauen. Durch die Einführung der Paket vermittelnden Netzwerke im Jahre 1962 durch die Firma RAND, wurde auf dieser Grundlage 1969 das ARPANET Projekt gegründet. Dieses gilt als das erste Commodity-Netzwerk auf Basis eines Computercluster, in dem vier unterschiedliche Computercenter miteinander verbunden wurden. Jedes dieser vier Computercenter war für sich selbst wieder ein Computercluster, die aber nur autonom arbeiteten. Aus dem ARPANET wurde später das Internet, weshalb das Internet auch als die ’Mutter’ aller Computercluster gilt, aus dem Grund, das quasi alle Computerressourcen inkl. aller bereits bestehenden Cluster zusammengeschlossen werden können.

Ein Computercluster beschreibt also eine meist große Anzahl von einzelnen miteinander vernetzten Computern, die dazu verwendet werden einzelne Teilaufgaben, die zu einer Gesamtaufgabe gehören, parallel zu verarbeiten. Von außen betrachtet wirkt ein Computercluster wie ein einzelnes System. Die jeweiligen Knoten sind dabei untereinander über ein schnelles Netzwerk verbunden. Durch den Aufbau solcher Serverfarmen wird die Rechenkapazität und Verfügbarkeit deutlich gegenüber eines einzigen Computers erhöht. Vor allem die Ausfallsicherheit eines solchen Computercluster ist ein entscheidender Vorteil gegenüber einem einzelnen Computersystem. Fällt innerhalb eines Clusterverbunds ein einzelnes System aus, hat das keinen direkten Einfluss auf alle anderen beteiligten Systeme innerhalb des Clusters. Es wird damit also eine Redundanz erzielt. Computercluster können am besten für die Verarbeitung von Batch-Jobs eingesetzt werden, bei denen viele parallele Teilberechnungen durchgeführt werden. Handelt es sich bei der Verarbeitung jedoch um Teilaufgaben, die im hohen Maße synchronisiert werden müssen, sind Computercluster dafür nicht geeignet, da der Kommunikationsoverhead zwischen den einzelnen Systemen den Performancegewinn, der durch die parallele Verarbeitung entsteht, wieder relativiert.

Der erste kommerziell zu erwerbende Computercluster (ARCnet) wurde im Jahr 1977 von der Firma Datapoint vorgestellt. Mit dem so genannten VAXCluster für ihr
VAX-System hatte die Firma DEC im Jahr 1983 den ersten richtigen Erfolg im Bereich des kommerziellen Clustercomputing.

Arten von Computer Cluster

Das Ziel des Cluster Computing ist die Bereitstellung einer sehr hohen Rechenleistung bzw. einer besonders ausfallsicheren Rechnerumgebung. Von diesen Zielen ausgehend werden verschiedene Arten von Computercluster und dadurch auch deren Einsatzfeld definiert.

Bei Clustersystemen wird grundsätzlich zwischen homogenen und heterogenen Clustern unterschieden. Homogene Cluster zeichnen sich dadurch aus, dass die jeweiligen Computer, die dem Cluster angehören, alle das gleiche Betriebssystem und die gleiche Hardware einsetzen. Computer, die zu einem heterogenen Cluster gehören, dürfen über unterschiedliche Betriebssysteme und Hardware verfügen.

Heutzutage werden drei Arten von Computercluster unterschieden und eingesetzt:

  • Hochverfügbarkeit Cluster
    Hochverfügbarkeit Cluster werden verwendet die Verfügbarkeit zu steigern und für eine bessere Ausfallsicherheit zu sorgen. Aus diesem Grund darf die gesamte Hardware als auch die Software eines solchen Cluster in keinerWeise über einen Single-Point-of-Failure verfügen, da die Definition und der Zweck diesem widersprechen würde. Im Fehlerfall werden die Dienste von dem defekten Host des Cluster auf einen anderen Host automatisch übertragen. Einsatzgebiete solcher Clustersysteme sind Bereiche, in denen eine Ausfallzeit maximal einige Minuten pro Jahr erlaubt. Eine besondere Art von Hochverfügbarkeit Cluster sind die so genannten ’stretched Cluster’. In diesem Fall werden einzelne Hosts eines Cluster räumlich getrennt in verschiedene weit voneinander entfernte Rechenzentren untergebracht. Kommt es in einem der Rechenzentren zu einem nicht vorhersagbaren Problem, können die Hosts des anderen Rechenzentrums vollständig die Aufgaben übernehmen.
  • Load-Balancing Cluster
    Load-Balancing Cluster werden dazu verwendet eine Lastverteilung auf mehrere Computer zu ermöglichen. Aus der Benutzersicht steht ihm nur eine zentrale Einheit gegenüber, die aber logisch gesehen aus mehreren vernetzten Systeme besteht. Um die Leistung des gesamten Cluster zu erhöhen, werden nicht die einzelnen Hosts für sich aufgerüstet, sondern ein zusätzlicher Host dem Cluster hinzugefügt. Einsatzbereiche sind Umgebungen, in denen die Anforderungen an die Rechenleistung extrem hoch sind.
  • High Performance Computing Cluster
    High Performance Computing Cluster werden überwiegend dazu verwendet Berechnungsverfahren durchzuführen, wobei die Berechnungen auf mehrere Hosts verteilt werden. Hierbei werden zwei unterschiedliche Arten der Aufgabenverteilung unterschieden. Eine Möglichkeit besteht darin, die Aufgaben in unterschiedliche Pakete zu verteilen, die dann parallel auf mehreren Hosts ausgeführt werden. Die andere Variante wäre, die Aufgaben auf die einzelnen Hosts direkt zu verteilen. Einsatzgebiete der High Performance Computing Cluster liegen überwiegend in den wissenschaftlichen Bereichen, aber auch die Serverfarmen für das Rendern von 3D-Computergrafiken und Computeranimationen gehören zu dieser Art von Cluster.



CloudLinux

Mit CloudLinux hat der gleichnamige Hersteller eine Linux-Distribution vorgestellt, die speziell für Webhosting Anbieter und Rechenzentren gedacht ist. Das Betriebssystem basiert auf der proprietären Lightweight Virtual Environments (LVE) Technologie, und beinhaltet eine Apache LVE-Version. Mit dieser Technologie werden die Hardware Ressourcen des gesamten Systems so aufgeteilt, dass sie speziell zu einzelnen gehosteten Webseiten zugewiesen werden können. Damit soll verhindert werden, dass eine einzelne Webseite den kompletten Server beeinträchtigen kann.

In diesem Artikel werden die Hintergründe und Funktionen von CloudLinux beschrieben.

Hintergrund

CloudLinux ist ein auf Linux basierendes Betriebssystem, welches kommerziell unterstützt wird und mit den bekanntesten RPM basierten Linux Distributionen kompatibel ist. Es richtig sich an Shared Hosting Anbieter und Rechenzentren und soll durch eine höhere Effizienz und Stabilität eine rentableren Betrieb bieten.

Vorteile für Shared Hosting Anbieter

  • Erhöhen der Anzahl der Konten pro Server.
  • Reduzierung der Hardware-, Strom-, Raum-und Verwaltungskosten.
  • Schutz des gesamten Server vor der Überlast durch eine einzelne Webseite.
  • Durch eine höhere Sicherheit werden die Ausfallzeiten minimiert und wodurch weniger Verwaltungs- und Supportzeiten benötigt werden.
  • 24/7 Unterstützung

Vorteile für Rechenzentren

  • Kommerzieller Support und ein gewartetes Betriebssystem
  • Spezielle für das Web optimierte Distribution
  • Vollständige Unterstützung mittels Ticketing System
  • Integration in bestehende Monitoringsysteme

Lightweight Virtual Environments (LVE)

Mit der Lightweight Virtual Environments (LVE) Isolationstechnologie erhöht CloudLinux die Server-Dichte und verbessert die Stabilität und Zuverlässigkeit. LVE verspricht ein verbessertes Ressourcenmanagement, indem die Ressourcen die einer Webseite zur Verfügung stehen limitiert werden. Damit kann eine einzelne Webseite nicht den gesamten Server ausbremsen. Weiterhin stehen Methoden zur Verfügung, mit denen die Benutzer identifiziert werden könne, die aktuell die meisten Server Ressourcen nutzen. Die einzelnen Webseiten sind voneinander isoliert, wodurch z.B. ein Hackerangriff die anderen auf dem Server gehosteten Webseiten nicht beeinträchtigt.

Vergleich: Standard OS vs. CloudLinux

Standard OS

  • Mehrere Webseiten pro Server.
  • Jede Webseite benötigt Ressourcen.
  • Eine einzelne Webseite kann den gesamten Server überlasten.
  • Hacker kann durch den Angriff einer Webseite alle auf dem Server vorhandenen Webseiten attackieren bzw. lahmlegen.

CloudLinux

  • Isolation der Ressourcen mittels der LVE Technologie.
  • LVE limitiert den Ressourcenzugriff einer einzelnen Webseite, dadurch werden die anderen Webseiten vor Ressourcenengpässen geschützt.
  • Eine einzelne Webseite kann den Server nicht überlasten.
  • Ein Server kann mehr Webseiten beherbergen.
  • Verbesserung der Server Performance.

Vergleich: Open Source Anbieter vs. CloudLinux

Quelle



Installation einer Private Cloud mit OpenNebula

Dieser Artikel beschreibt das Einrichten einer Private Cloud mit OpenNebula auf Ubuntu. Die Infrastruktur besteht dabei aus drei physikalischen Maschinen. Einem Front-End und zwei Nodes, auf denen die virtuellen Maschinen ausgeführt werden. Auf den Nodes muss zusätzlich eine Bridge konfiguriert werden, damit die virtuellen Maschinen das lokale Netzwerk erreichen können. Für das Einrichten der Brigde siehe den Bereich Bridging.

Installation

Auf dem System für das Front-End installieren wir OpenNebula mit folgendem Befehl:

sudo apt-get install opennebula

Für jeden Node installieren wir den OpenNebula-Node:

sudo apt-get install opennebula-node

Um später die SSH Schlüssel zu kopieren, benötigt der oneadmin (wird von OpenNebula erstellt) ein Passwort. Dazu führen wir auf jeder Maschine folgenden Befehl aus:

sudo passwd oneadmin

Nachfolgend müssen die Namen für node01 und node02 entsprechend der eigenen Installation angepasst werden.

Nun kopieren wir den SSH Schlüssel des oneadmin auf jeden Node und in die Datei authorized_keys des Front-Ends.

sudo scp /var/lib/one/.ssh/id_rsa.pub oneadmin@node01:/var/lib/one/.ssh/authorized_keys
sudo scp /var/lib/one/.ssh/id_rsa.pub oneadmin@node02:/var/lib/one/.ssh/authorized_keys
sudo sh -c "cat /var/lib/one/.ssh/id_rsa.pub >> /var/lib/one/.ssh/authorized_keys"

Der SSH Schlüssel jedes Nodes muss in die Liste der bekannten Hosts unter /etc/ssh/ssh_known_hosts auf dem Front-End hinzugefügt werden. Nun muss die SSH Session beendet werden und der SSH Schlüssel von ~/.ssh/known_hosts nach /etc/ssh/ssh_known_hosts kopiert werden.

sudo sh -c "ssh-keygen -f .ssh/known_hosts -F node01 1>> /etc/ssh/ssh_known_hosts"
sudo sh -c "ssh-keygen -f .ssh/known_hosts -F node02 1>> /etc/ssh/ssh_known_hosts"

Diese Schritte erlauben dem oneadmin SCP ohne ein Passwort oder manuellen Eingriff zu nutzen, um eine Image auf den Nodes bereitzustellen.

Auf dem Front-End muss ein Verzeichnis zum Speichern der Images für die virtuellen Maschinen erstellt und dem oneadmin Zugriff auf das Verzeichnis gegeben werden.

sudo mkdir /var/lib/one/images
sudo chown oneadmin /var/lib/one/images/

Nun kann eine virtuelle Maschine in das Verzeichnis /var/lib/one/images kopiert werden.

Eine virtuelle Maschine auf Basis von Ubuntu kann mit dem vmbuilder erstellt werden, siehe dazu JeOS and vmbuilder.

Konfiguration

Der OpenNebula Cluster kann nun konfiguriert werden. Weiterhin können virtuelle Maschinen dem Cluster hinzugefügt werden.

Auf dem Front-End geben wir dazu folgenden Befehl ein:

onehost create node01 im_kvm vmm_kvm tm_ssh
onehost create node02 im_kvm vmm_kvm tm_ssh

Als nächstes erstellen wir eine Template-Datei mit dem Namen vnet01.template für das virtuelle Netzwerk:

NAME = "LAN"
TYPE = RANGED
BRIDGE = br0
NETWORK_SIZE = C
NETWORK_ADDRESS = 192.168.0.0

Die NETWORK_ADDRESS sollte dem eigenen lokalen Netzwerk entsprechen.

Mit dem onevnet Befehl fügen wir das virtuelle Netzwerk OpenNebula hinzu:

onevnet create vnet01.template

Jetzt erstellen wir eine Template-Datei für eine virtuelle Maschine mit dem Namen vm01.template:

NAME = vm01

CPU = 0.5
MEMORY = 512

OS = [ BOOT = hd ]

DISK = [
source = "/var/lib/one/images/vm01.qcow2",
target = "hda",
readonly = "no" ]

NIC = [ NETWORK="LAN" ]

GRAPHICS = [type="vnc",listen="127.0.0.1",port="-1"]

Mit dem Befehl onevm starten wir die virtuelle Maschine:

onevm submit vm01.template

Mit dem Befehl onevm list können wir weitere Informationen über die gestarteten virtuellen Maschinen abfragen. Mit dem Befehl onevm show vm01 erhalten wir detaillierte Informationen zu einer bestimmten virtuellen Maschine.

Quelle



Eigenschaften einer Cloud Platform

Ich habe bisher einige Cloud Computing Plattformen, darunter openQRM, OpenNebula oder OpenECP vorgestellt und ein paar weitere werden noch folgen. Daher erläutere ich in diesem Artikel die grundsätzlichen Eigenschaften die eine Cloud Plattform (meiner Meinung nach) hat bzw. haben sollte.

1. Zunächst sollten ausreichend virtualisierte Serverressourcen zur Verfügung stehen. Weiterhin müssen, (vor allem dann) wenn sich mehrere Kunden auf einem System befinden, jedem Kunden diese virtualisierten Serverressourcen garantiert werden und die einzelnen virtuellen Instanzen isoliert und damit vollständig von einander getrennt betrieben werden.

2. Zum Bereitstellen von umfangreichen Enterprise-Class-Services wie z.B. hohe Verfügbarkeit, Systemwiederherstellungen nach Datenverlusten, automatische Skalierung während Lastspitzen und Ressourcenoptimierungen muss eine große (unbegrenzte) Menge an virtualisierten Serverressourcen vorhanden sein.

3. Für ein zustandsbehaftetes Lifecycle Management, wozu Snapshots, schnelles Cloning (duplizieren) und eine dynamische Versorgung mit Ressourcen über große Server Infrastrukturen gehören, wird ein virtualisierter Cloud Speicher benötigt.

4. Für die Anpassung der virtuellen Topologie - durch das Hinzufügen weiterer Netzwerkfunktionen für Sicherheit, Routing, Load Balancing, Application Firewalls, Protokol Optimierung, etc. in den OSI Schichten 3 bis 7 - und die Möglichkeit die jeweiligen (Teil)-Netzwerke auf Multi-Kunden Systemen zu isolieren und Ressourcen zu garantieren, werden virtuelle Netzwerk Ressourcen benötigt.

5. Es müssen umfangreiche und offene APIs zur Kontrolle sämtlicher Ressourcen vorhanden sein, damit Cloud Computing Anbieter ihren Kunden die vollständige Kontrolle über deren privaten virtuellen Rechenzentren anbieten können.

6. Die Cloud Plattform muss für allen gängigen Virtualisierungs-Plattformen vollständige Kompatibilität bieten und jede virtuelle Maschine unterstützen, um u.a. einen Vendor Lock-in zu vermeiden. Des Weiteren müssen Funktionen für die Migration von virtuellen Maschinen zwischen unterschiedlichen Virtualisierungs-Technologien (P2V, V2P und V2V) vorhanden sein.

7. Zu guter letzt sollte die Cloud Plattform auf Open Source basieren, um eine größtmögliche Kompatibilität zu allen möglichen Clouds aufzuweisen und um einfach adaptiert und angenommen zu werden.



Enomaly's Elastic Computing Platform

Enomaly’s Elastic Computing Platform (ECP) dient Internet Carriern, Hosting-Providern und deren Kunden dazu, die Stärken von Cloud Computing, wie Flexibilität und Kosteneinsparungen zu nutzen. Mit ECP können vollständige Cloud Computing Plattformen verwaltet und Infrastrukturen on-Demand bereitgestellt werden. Weitere Möglichkeiten bestehen in der dynamischen Versorgung mit Ressourcen und der Skalierung nach Bedarf.

Enomaly's Elastic Computing Platform bietet folgende Funktionen:

Unbegrenzte Skalierbarkeit
Mit der ECP Architektur können große Cloud Plattformen über mehrere Rechenzentren in unterschiedlichen geographischen Regionen hinweg aufgebaut werden.

Eigene Konfigurationsmöglichkeiten für die optimale Anpassung an das Unternehmen
Unternehmen können, unterstützt durch eine Echtzeit-Überwachung, sowie umfangreichen Befehls- und Kontrollmöglichkeiten, ihre Cloud Infrastrukturen bzgl. Lastspitzen entsprechend anpassen.

Sicherheit trotz mehrerer unterschiedlicher Nutzer auf einer Plattform
Auf Basis von sehr fein granular einstellbaren Zugriffskontrollen kann ein Benutzer den Zugriff auf die Cloud Plattform (für Multi-User) so einstellen, dass nur die jeweils eigenen Ressourcen eingesehen und verwaltet werden können. Darüber hinaus kann ein Anbieter eine unbegrenzte Anzahl von VLANs für jeden Kunden erstellen und damit das Netzwerk zwischen mehreren Kunden so aufteilen und die Teilnetzwerke so isolieren, dass jedem Kunden innerhalb der Cloud die Privatsphäre seiner Daten garantiert wird. Ein Quota System schützt die Cloud gegen den Missbrauch.

Automatisierte Versorgung mit Ressourcen
ECP verfügt über eine Regelbasis zur automatischen Versorgung mit Ressourcen und kann damit den optimalen Standort einer virtuellen Anwendung bestimmen. Dazu stellt ECP sicher, dass ein Node einem optimalen physikalischen als auch virtuellen Standort zugeordnet ist. Weiterhin ist ECP in der Lage, ein offline Image einer virtuellen Maschine zu ändern, um den Speicherplatz, die Vernetzung, den Zustand des Clusters, etc. für schnelle Deployments und Off-Site Migrationen vorzunehmen.

Integration in vorhandene Infrastrukturen
ECP verfügt über eine API, mit der Benutzer die Verwaltung ihrer Cloud Infrastruktur automatisieren können, um z.B. externe SLAs oder andere Systeme für die Verwaltung zu integrieren. Darüber hinaus stellt ECP eine Back-Office API bereit, mit der weitere Systeme zur Ressourcenversorgung und Abbrechnung von (anderen) Anbietern integriert und administrative Aufgaben automatisiert werden können.

Integration von ECP im Rechenzentrum

Quelle



Die Xen Cloud Platform

In diesem Artikel stelle ich die Xen Cloud Platform (XCP) vor, die im August 2009 erstmals veröffentlicht wurde. Dabei handelt es sich um eine Initiative, mit der eine vollständige Open Source Lösung auf Basis einer von der Industrie unterstützenden API für Cloud Anbieter zur Verfügung stehen soll. Mit einer XCP Infrastruktur sollen andere Open Source Projekte wie z.B. Eucalyptus, Convirture, OpenNebula, OpenXenCenter, Xen VNC Proxy, und Nimbus in der Lage sein den Xen Hypervisor besser nutzen zu können, in dem die neue API speziell auf das Cloud Computing ausgerichtet ist.

Die Xen Cloud Platform versteht sich als eine Kombination der Eigenschaften der Xen Virtualisierung Platform (Mobilität, Offenheit, Isolation und der Möglichkeit mehrere Instanzen parallelen auszuführen) mit neuen und verbesserten Speicher-, Sicherheits- und Netzwerk- Virtualisierungstechnologien. Damit soll eine Vielzahl von virtuellen Infrastruktur Cloud Services angeboten werden können. Darüber hinaus werden Anforderungen bzgl. der Sicherheit, Verfügbarkeit, Performance und Isolation von Hybrid Clouds erfüllt.

Aktuelle Funktionen

  • Xen 3.4.1
  • Linux 2.6.27 Kernel
  • Windows PV Treiber, Microsoft Zertifiziert
  • XAPI Enterprise-class Management Tool Stack
    • Lebenszyklus einer virtuellen Maschine: Live Snapshots, Checkpoint, Migration
    • Ressourcen Pools: Sichere Neuverteilung (Live), Autokonfiguration, DR
    • Host Konfiguration: Flexibles Speichermanagement, Netzwerkbetrieb, Power Management
    • Verfolgen von Ereignissen: Fortschritt, Benachrichtigung
    • Sichere Kommunikation durch SSL
    • Möglichkeit für Upgrades und Patching
    • Überwachung und Benachrichtung bzgl. der Perfomance in Echtzeit
  • Unterstützung von Single-Root I/O Virtualization
  • Installation des Host per CD-ROM und Netzwerk
  • Vollständige "xe" Kommandozeile und Web Service API
  • Openvswitch
  • Fehlertoleranz (Marathon FT products)
  • VNC Console Proxy und Web Front-End
  • Unabhängiges Front-End

Roadmap für XCP 1.0

  • VSwitch Integration
    Mehrere Nutzer einer Netzwerkinfrastruktur; Übernahme der Firewall- und Routingregeln von migrierten virtuellen Maschinen; Flexible Überwachung des Datenverkehrs von virtuellen Ports
  • Netchannel 2 Integration
    Verbesserung der Skalierbarkeit der Xen Vernetzung auf größeren Systemen; Beschleunigung des Datenverkehrs zwischen virtuellen Maschinen
  • Single-Root I/O Virtualization (SR-IVO) Vernetzung
    Xen unterstützt bereits SR-IVO Netzwerkkarten, allerdings müssen diese noch manuell konfiguriert werden.
  • Starten der Gast Systeme von SR-IOV Host-Bus-Adapters (HBAs)
  • Libvirt bindings
  • Native Unterstützung für das Open Virtualization Format (OVF)
  • DMTF (Distributed Management Task Force) Standards für Virtualisierung und Cloud
  • Intelligente Fehlerbehebung um die Auswirkungen von Hardware-Fehlern zu minimieren
  • Unterstützung von Web-basierten Management mehrere Nutzer für unterschiedliche Anbieter wie z.B. Eucalyptus, Enomaly oder OpenNebula
  • Verbesserung der Skalierbarkeit des Managements für die Verwaltung von mehr als 1.000 Xen-Hosts
  • Zusammenschluss von günstigen lokalen Speicher durch die Integration von DRDB und Parallax
  • Oracle Cluster File System 2 (ocfs2) Integration

Quelle

Xen Cloud Platform