Categories
News

Anerkennung für salesforce.com

Anerkennung für salesforce.com

Auszeichnungen als Leader im Gartner Magic Quadrant und als eines der 100 am schnellsten wachsenden Unternehmen (Fortune)

München – Gute Nachrichten für salesforce.com: das Unternehmen wurde von Gartner im Führungsquadranten für Sales Force Automation positioniert. Nummer 4 wurde das Unternehmen bei der FORTUNE’s Liste der „100 Fastest-Growing Companies“.

Ein Leader ist für Gartner ein Unternehmen mit einer klaren, den Markt definierenden Vision, wie Technologie den Top Sales Executives helfen kann, ihre Ziele zu erreichen. Leader verfügen über die Produkte und Services, diese Vision umzusetzen, und sie können auf solide Geschäftsergebnisse in Form von Umsatz und Gewinn verweisen. Sie haben signifikante und erfolgreiche Implementierungen bei Kunden in Nordamerika, EMEA und Asia/Pacific in vielen Branchen für mehr als 500 Anwender.

Um sich für die Liste von Fortune zu qualifizieren muss ein Unternehmen einige strenge Kriterien erfüllen und wird dann nach seiner Umsatzwachstumsrate, seinem EPS-Anstieg und seinem auf drei Jahre gesehenen Gesamtumsatz (gemessen bis zum 30. Juni 2010) bewertet.

Categories
Grundlagen Services @de

Das Konzept hinter den AWS Regionen und Verfügbarkeitszonen

Amazon EC2 bietet die Möglichkeit, Instanzen über mehrere Standorte zu verteilen. Dabei sind die Standorte in Verfügbarkeitszonen (Availability Zones) und Regionen aufgeteilt. Die Regionen sind verstreut und befinden sich in getrennten geographischen Gebieten wie den USA und Europa. Verfügbarkeitszonen sind verschiedene Standorte innerhalb einer Region, die so konstruiert sind, dass sie isoliert betrieben werden und von Fehlern in anderen Verfügbarkeitszonen nicht betroffen sind. Dazu bieten sie eine kostengünstige Konnektivität mit einer geringen Netzwerklatenz zu anderen Verfügbarkeitszonen in der gleichen Region.

Durch das Starten von Instanzen in separaten Regionen, können Web Anwendungen so konstruiert werden, dass sich diese geographisch in der Nähe von bestimmten Kunden befinden und rechtlichen oder anderen Anforderungen gerecht werden.

Weiterhin werden Anwendungen vor dem Ausfall eines einzelnen Standorts geschützt, indem Instanzen in separaten Verfügbarkeitszonen ausgeführt werden.

Die folgende Graphik zeigt eine Darstellung der Amazon EC2 Regionen und Verfügbarkeitszonen. Jede Region ist völlig unabhängig. Jede Verfügbarkeitszone ist vollständig isoliert, aber durch Netzwerkverbindungen mit einer geringen Latenz mit anderen Verfügbarkeitszonen verbunden.

Regionen

Amazon EC2 verfügt über mehrere Regionen, wodurch EC2 Instanzen an den Standorten ausgeführt werden können, die den eigenen Anforderungen entsprechen. Um z.B. als nicht europäisches Unternehmen Kunden in Europa Dienstleistungen anzubieten und zudem den dort gesetzlichen Anforderungen gerecht zu werden, können die EC2 Instanzen in einer Verfügbarkeitszone der Region Europa ausgeführt werden.

Jede Amazon EC2 Region ist so konstruiert, dass sie vollständig isoliert von allen anderen Amazon EC2 Regionen betrieben wird. Damit wird die größtmögliche Unabhängigkeit und Stabilität erzielt und macht den Ort einer jeden EC2 Ressource eindeutig.

Um Instanzen zu starten oder mit diesen zu arbeiten, muss zunächst die korrekte URL eines Endpunkts einer Region definiert werden. Soll z.B. eine Instanz in der Region US-East (Standard Region) betrieben werden, wird als Endpunkt URL ec2.us-east-1.amazonaws.com verwendet.

In der folgenden Tabelle sind alle Regionen mit ihren zugehörigen Endpunkten dargestellt.

Region Endpoint
US-East (Northern Virginia) Region ec2.us-east-1.amazonaws.com
US-West (Northern California) Region ec2.us-west-1.amazonaws.com
EU (Ireland) Region ec2.eu-west-1.amazonaws.com
Asia Pacific (Singapore) Region ec2.ap-southeast-1.amazonaws.com

Verfügbarkeitszonen

Fehler können auftreten, die Auswirkungen auf die Verfügbarkeit von Instanzen haben, die sich an dem gleichen Standort befinden. Auch wenn das ziemlich selten vorkommt – wenn alle Amazon EC2 Instanzen an einem einzigen Standort gehostet werden, der von einer Störung betroffen ist, sind diese Instanzen nicht mehr verfügbar.

Sind z.B. Instanzen über drei Verfügbarkeitszonen verteilt und eine dieser Instanzen fällt aus, kann eine Anwendung zu konzipiert werden, dass die Instanzen in den übrigen Verfügbarkeitszonen die Anfragen automatisch entgegennehmen und verarbeiten.

Quelle

Categories
Analysen

Wir brauchen eine transparente Cloud!

Stellen wir uns das folgende Szenario vor:

Wir haben unsere IT Infrastruktur erfolgreich in die Cloud eines Anbieters migriert. Alles bestens, wir sagen uns: “Super, alles funktioniert einwandfrei! Wir senken unsere Kosten. Unsere Infrastruktur ist nun so skalierbar, dass sie unseren Anforderungen immer gerecht wird. Uns stehen immer die aktuellen Software Versionen zur Verfügung und wir können von jedem Ort unabhängig von den lokalen Systemen miteinander kollaborieren.”

Was machen wir aber, falls wir uns nun doch dazu entscheiden wieder in das eigene Rechenzentrum zurückzukehren oder den Cloud Anbieter zu wechseln, weil dieser z.B. günstiger ist? Oder gehen wir noch einen Schritt weiter. Wie können wir unsere gesamten Geschäftsprozesse in der Cloud über mehrere Anbieter hinweg verteilt abbilden? Stellen wir uns vor, dass ein Anbieter den Prozess A verarbeitet, ein weiterer den Prozess B. Ein dritter Anbieter verarbeitet den Prozess C und nutzt dabei die Prozesse A und B. Oder wir verwenden eine Vielzahl voneinander unabhängiger Services von unterschiedlichen Anbietern und integrieren diese zu einem einzigen Service. Wir wir sehen, sind der Komplexität keine Grenzen gesetzt. Ein vermeintlich einfacheres Beispiel: Unsere Daten sind bei dem Anbieter A gespeichert und ein Anbieter B soll diese Daten verarbeiten.

Ist das möglich?

Ein weiterhin sehr kritischer Punkt des Cloud Computing ist das Fehlen von Standards. Jeder Anbieter verwendet unterschiedliche Technologien und kocht innerhalb seiner Infrastruktur seine eigene Suppe. Die meisten Anbieter versuchen in der Regel mittels des gefürchteten Vendor-Lockin ihre Kunden “an sich zu binden”. Denn leider haben es bisher die Wenigsten verstanden, Kunden über guten Service und weitere Dienstleistungen von sich abhängig zu machen.

Aus diesem Grund ist jede Beziehung zwischen einem Anbieter und seinem Kunden anders und eine anbieterübergreifende Zusammenarbeit – die für einen Kunden in vielen Fällen unerlässlich ist – kann nicht stattfinden.

Wir brauchen eine transparente Cloud!

Ein möglicher Ansatz wäre libcloud (http://libcloud.org). Dabei handelt es sich um eine Standard Bibliothek u.a. für Anbieter wie Amazon, Rackspace oder Slicehost, die eine einheitliche API bereitstellt. Sie ist in Python implementiert und kostenlos (Apache License 2.0) zu nutzen, um mit unterschiedlichen Cloud Anbietern zu kommunizieren.

libcloud

Allerdings ist die libcloud Bibliothek nur ein Ansatz. Wir müssen, wenn wir von Cloud Standards reden, uns auf eine noch wesentlich tieferer Ebene begeben. Was ich damit sagen will ist, dass ein Cloud Anbieter sich selber in die Pflicht nehmen muss und seine Schnittstellen so offen und sorgfältig zu dokumentieren, dass ein Wechsel oder eine Integration unterschiedlicher Services, Prozesse etc. zwischen verschiedenen Anbietern ohne weiteres möglich ist.

Ein Kunde muss mit einem guten Gefühl seine Daten, Prozesse etc. zu einem Cloud Anbieter auslagern, weil er sich sicher sein kann über diese frei zu verfügen und einen Wechsel sowie eine Integration sorgenfrei vornehmen zu können.

Categories
Grundlagen Services @de

Das Konzept des Amazon Elastic Block Store

Der Amazon Elastic Block Store (Amazon EBS) ist eine spezielle Speicherart, die speziell für Amazon EC2 Instanzen konstruiert wurde. Mit Amazon EBS können Volumes erstellt werden, die von Amazon EC2 Instanzen wie externe Geräte eingebunden (gemounted) werden können. Amazon EBS Volumes verhalten sich wie unformatierte externe Block-Devices. Sie können durch den Benutzer benamt werden und stellen eine Block-Device-Schnittstelle bereit. EBS Volumes können mit einem Dateisystem ausgestattet oder wie ein gewöhnliches Block-Device genutzt werden.

Ein AWS Account ist auf 100 EBS Volumes oder in der Summe auf eine Volume Gesamtspeichergröße von 20 Terrabyte begrenzt. Dabei beträgt die maximale Größe eines Volumes 1 Terrabyte. Jedes EBS Volume kann jeder EC2 Instanz innerhalb derselben Verfügbarkeitszone hinzugefügt werden.

Mit Amazon EBS können Snapshots (Backups) der EBS Volumes erstellt und auf Amazon S3 gespeichert werden. Diese Snapshots können als Ausgangspunkt für neue EBS Volumes genutzt werden und schützen die Daten langfristig. Weiterhin können Snapshots mit bestimmten Benutzern geteilt oder öffentlich verfügbar gemacht werden.

Amazon EBS Volumes verfügen über folgende Eigenschaften:

  • Speichern ausserhalb der Instanz
  • Persistenz jenseits der Lebensdauer von Instanzen
  • Hohe Verfügbarkeit und Zuverlässigkeit
  • Hinzufügen und Entfernen der Volumes für bereits ausgeführte Instanzen
  • Darstellung als ein eigenes Gerät innerhalb der Instanz

Amazon EBS Snapshots verfügen über folgende Eigenschaften:

  • Erfassung des aktuellen Zustands eines Volumes
  • Datensicherung
  • Instanziierung neuer Volumes, die den exakten Inhalt eines Snapshots beinhalten

Amazon EBS Anwendungsfälle


Fehlertoleranz

Amazon EBS ist so konstruiert, dass jede Instanz zu einem Speichervolumen hinzugefügt werden kann. Fällt eine Instanz auf Grund eines Fehlers aus, löst sich das EBS Volume automatisch mit den intakten Daten von der Instanz. Anschließend kann das Volume zu einer neuen Instanz hinzugefügt werden und der Wiederherstellungprozess beginnen.

Erklärung

  • 1. Eine Amazon EC2 Instanz ist mit einem EBS Volume verbunden. Die Instanz fällt aus, bzw. Probleme treten auf.
  • 2. Zur Wiederherstellung muss das EBS Volume nun von der Instanz gelöst werden. Das kann auch automatisch durch das EBS Volume erfolgen. Anschließend wird eine neue Instanz gestartet und das Volume dieser neuen Instanz hinzugefügt.
  • 3. Für denn Fall das ein Amazon EBS Volume ausfällt, kann eines neues EBS Volume auf Basis des jüngsten Snapshots des Volumes erstellen, dass ausgefallen ist.

Neue Volumes auf Basis von Snapshots erstellen

Amazon EBS Snapshots ermöglichen den schnellen Einsatz neuer Volumes, indem ein bereits vorhandener Snapshot als Ausgangspunkt für diese neuen Volumes dient.

Erklärung

  • 1. Es wird ein Web-Service mit einer großen Datenmenge verwendet.
  • 2. Wenn die Daten fertig sind, kann ein Snapshot des Volumes in Amazon S3 zur langfristigen Datensicherung gespeichert werden.
  • 3. Wenn der Datenverkehr und Ressourcenverbrauch ansteigt, kann aus dem Snapshot ein neues Volume erstellt, eine neue Instanz gestartet und anschließend dieser neuen Instanz das neue Volume hinzugefügt werden.
  • 4. Wenn sich der Datenverkehr wieder verringert, können eine oder mehrere Amazon EC2 Instanzen heruntergefahren und ihre EBS Volumes gelöscht werden.

Datenpersistenz

EBS Volumes existieren unabhängig von den aktuell vorhandenen Instanzen und bleiben solange vorhanden, bis sie explizit gelöscht werden. Das ermöglicht das Speichern von Daten, ohne dass eine Instanz gestartet sein muss.

Erklärung

  • 1. In regelmäßigen Abständen wird eine Instanz zur Batchverarbeitung von großen und wachsenden Datenmengen ausgeführt.
  • 2. Am Ende der Verarbeitung wird die EC2 Instanz beendet. Das EBS Volume wird aber weiterhin ausgeführt.
  • 3. Werden die Daten das nächste Mal verarbeitet, wird eine neue EC2 Instanz gestartet und dem bereits vorhandenen EBS Volume hinzugefügt.

Auf Basis dieses Vorgehens können die Daten nur mit den Ressourcen auf unbestimmte Zeit verarbeitet und gespeichert werden, die auch tatsächlich benötigt werden.

Root Partition

EBS Volumes können als Root Device (Partition) für Linux und Windows Instanzen verwendet werden. Dadurch besteht die Möglichkeit Root Partitionen mit der Größe von bis zu 1 Terrabyte zu nutzen.

Weiterhin kann das EBS Volume (als Root Partition) von einer anderen Instanz gemounted werden, falls eine Instanz ausfällt.

Die Größe der Partition kann während des Startvorgangs mittels Block Device Mapping geändert werden.

Erklärung

  • 1. Ein vorhandenes AMI ist in Amazon EBS gespeichert. Es Änderungen daran vorgenommen und ein neues AMI erstellt.
  • 2. Falls die Größe der Root Partition nicht mehr ausreicht, wird die Instanz gestoppt und mit einem größeren EBS Volume neu gestartet.
  • 3. Falls eine Instanz ausfallen sollte, wird eine neue Instanz gestartet und die Root Partition (EBS Volume) der ausgefallenen Instanz gemounted.

Große Datenmengen

Amazon EBS bietet größere Volumes als Amazon EC2 Instanzen. Jedes EBS Volume kann bis zu einem Terrabyte groß sein.

Quelle

Categories
Literatur

Buch – Cloud Computing: Technologies and Strategies of the Ubiquitous Data Center

Titel: Cloud Computing: Technologies and Strategies of the Ubiquitous Data Center

Autor: Brian J.S. Chee, Curtis Franklin Jr.

Beschreibung:
Modern computing is no longer about devices but is all about providing services, a natural progression that both consumers and enterprises are eager to embrace. As it can deliver those services, efficiently and with quality, at compelling price levels, cloud computing is with us to stay. Ubiquitously and quite definitively, cloud computing is answering the demand for sophisticated, flexible services

Cloud Computing: Technologies and Strategies of the Ubiquitous Data Center looks at cloud computing from an IT manager’s perspective. It answers basic as well as strategic questions from both a business and a technical perspective so that you can confidently engage both IT and financial assets in making your organization techno- savvy, efficient, and competitive.

Any answers about the future of computing are definitely in the clouds

The first section of the book offers up a history of the computing roots that have evolved into cloud computing. It looks at how IT has been traditionally serving needs and how cloud computing improves and expands on these services, so you can strategize about how a cloud might provide solutions to specific IT questions or answer business needs.

Next, the book shows how to begin the process of determining which organizational needs would best be served and improved by cloud computing. Presenting specific cases as examples, the book walks you through issues that your organization might likely encounter. Written clearly and succinctly, it —

  • Introduces you to the concepts behind different types of clouds, including those used for storage, those that improve processor and application delivery, and those that mix any and all of these services
  • Covers typical concerns you will hear with regard to such issues as security, application integration, and structural limitations
  • Looks at the future of clouds, from developments right on the horizon to those still in the planning stage

By the book’s conclusion, you will have a solid basis on which to initiate strategic discussions about deploying clouds in your organization. You will understand how cloud computing can affordably solve real problems. You will know which strategies to use and you will learn of the pitfalls to avoid when taking your data center to the clouds.

Throughout this book are the answers you need to the many questions from the most basic to the more advanced surrounding cloud computing and its place in your enterprise.

  • What exactly is cloud computing?
  • How are clouds different than virtualization?
  • Should my organization use a cloud (or multiple clouds)?
  • Can clouds and virtualization play significant roles in my organization at the same time?

Covering the basics of virtualization and clusters and the more advanced strategic considerations of security and return on investment, this book will be your guide to IT’s present and future in the cloud, a resource that you will continually turn to.

Bestellmöglichkeit: Amazon

Cover:

Categories
Analysen

Sind die Amazon Web Services der Standard der Cloud?

Nach dem Artikel Amazon ist das Mass aller Dinge im Cloud Computing Markt! stellt sich ebenfalls die Frage, ob Amazon mit seinen Amazon Web Services (AWS) auch die Standards in der Cloud setzt.

Die Amazon Web Services sind der aktuelle und unangefochtene Marktführer aus dem Bereich der Infrastruktur as a Service (IaaS) Anbieter und decken soweit alle Segmente und Möglichkeiten des Cloud Computing ab. Durch die langjährige Erfahrung verfügt Amazon über einen signifikanten Vorsprung vor allen anderen Anbietern in diesem Segment. Die Expertise entstand dabei durch den Aufbau einer Privat Cloud, um die Ansprüche an die eigene Infrastruktur (Skalierbarkeit des Webshops, etc.) zu erfüllen, woraus dann die Public Cloud Angebote (Amazon Web Services) entstanden sind.

Zunächst können wir natürlich aus einer Vielzahl von “Standards” auswählen, da jeder Anbieter versucht, seine proprietäre Lösung als Standard am Markt zu positionieren. Daher kann nicht einfach davon ausgegangen werden, das die Amazon Web Services der Standard der Cloud sind. Zudem benötigt ein Standard einen gewissen Zeitraum, um sich als Standard zu etablieren.

Was sind also Anzeichen dafür, dass die Amazon Web Services bereits der Standard bzw. der kommende Standard des Cloud Computing sind?

Ein Blick auf die Angebote der Drittanbieter im Cloud Computing Markt verrät, AWS hat einen hohen Stellenwert. Vor allem Amazons Speicherdienst Amazon S3 ist dabei sehr beliebt. Mit JungleDisk, CloudBerry S3 Explorer, CloudBerry Backup oder Elephant Drive, stehen nur ein Paar Clients bereit, mit denen die Daten vom lokalen PC oder Server in die Amazon Cloud übertragen werden können. Zudem stehen mit S3 Curl, S3cmd oder S3 Sync weitere OpenSource Lösungen bereit, welche die Amazon S3 API zum Speichern von Daten nutzen.

Ein weiteres deutliches Indiz dafür, dass sich die Amazon Web Services als Cloud Computing Standard etablieren werden, ist das Angebot des deutschen Cloud Computing Anbieters ScaleUp Technologies, die mit ihrem eigenen Cloud Storage die Amazon S3 API vollständig adaptiert hat. Weiterhin stehen mit Eucalyptus bzw. der Ubuntu Enterprise Cloud “Klone” der Amazon Elastic Compute Cloud (EC2) zur Verfügung, mit denen eine Private Cloud nach dem Vorbild von EC2 aufgebaut werden kann. Auch hier existiert mit den Euca2ools bereits eine EC2 API Adaption.

Schaut man sich zudem die Liste der AWS Solution Provider an, erkennt man, wie wichtig die Bedeutung von AWS mittlerweile geworden ist.

Nicht alle AWS Angebote haben derzeit das Potential als Standard bezeichnet zu werden. Dazu zähle ich wie bereits oben erwähnt nur die Amazon Simple Storage Service (Amazon S3) sowie die Amazon Elastic Compute Cloud (Amazon EC2), wobei S3 dabei deutlich Populärer ist als EC2.

Wie man anhand der Angebote und Adaptionen erkennt, ist vor allem S3 weit verbreitet und anerkannt und es ist davon auszugehen, dass weitere Drittanbieter auf diesen Zug aufspringen werden. Zudem werden die meisten Anbieter davon absehen, dass Rad neu zu erfinden. Amazon war der erste Anbieter im IaaS Cloud Computing Markt und hatte dadurch ausreichend Zeit, seine proprietären Standards bekannt zu machen. Zudem haben es die restlichen großen Anbieter verpasst schnell nachzuziehen und eigene Angebote zu präsentieren. Sollten sie noch länger warten, wird die Zeit zu Gunsten von Amazon entscheiden.

Amazon S3 ist derzeit der Defacto Standard im Bereich Cloud Storage. Amazon EC2 wird voraussichtlich in Kürze nachziehen und sich etablieren. Wann und ob es die restlichen AWS Angebote ebenfalls zu Defacto Standards schaffen, bleibt abzuwarten.

Categories
Grundlagen Services @de

Das Amazon EC2 Adressierungskonzept

Dieser Artikel beschreibt das Adressierungskonzept von Amazon EC2. Das beinhaltet die Arten von IP-Adressen, die für EC2 Instanzen zur Verfügung stehen.

Alle Amazon EC2 Instanzen erhalten während des Starts zwei IP Adressen zugewiesen. Eine private Adresse (RFC 1918) und eine öffentliche Adresse (public), die mittels Network Address Translation (NAT) direkt aufeinander abgebildet werden. Private Adressen sind nur innerhalb des Amazon EC2 Netzwerks erreichbar. Öffentliche Adressen hingegen sind aus dem Internet erreichbar.

Weiterhin stellt Amazon EC2 einen internen, sowie einen öffentlichen DNS Namen zur Verfügung, der jeweils der privaten bzw. öffentlichen IP-Adresse zugewiesen wird. Der interne DNS Name kann nur innerhalb des Amazon EC2 Netzwerk aufgelöst werden. Der interne DNS Name kann nur innerhalb des Amazon EC2 Netzwerk aufgelöst werden. Der öffentliche DNS Name hingegen löst die öffentliche IP-Adresse außerhalb des Amazon EC2 Netzwerks und die private IP-Adresse innerhalb des EC2 Netzwerks auf.

Private Adressen (RFC 1918)

Alle Amazon EC2-Instanzen erhalten eine private Adresse per DHCP zugewiesen. Die Adressbereiche sind in RFC 1918 definiert und können nur innerhalb des Amazon EC2 Netzwerks gerouted werden. Die privaten IP-Adressen werden für die Kommunikation zwischen den jeweiligen Instanzen verwendet.

Die private Adresse ist mit einer Instanz solange verknüpft, bis diese Instanz wieder beendet wird. Anschließend wird die Adresse wieder an Amazon EC2 zurückgegeben und kann dann erneut an eine andere Instanz vergeben werden.

Es sollte darauf geachtet werden, dass immer die internen Adressen verwendet werden, wenn zwischen Amazon EC2 Instanzen kommuniziert wird. Damit ist sichergestellt, dass der Datenverkehr immer mit der höchsten Bandbreite übertragen wird und die Latenz innerhalb des Amazon EC2 Netzwerks so gering wie möglich ist.

Interner DNS Name

Jede Instanz verfügt über einen internen DNS Namen, der zu der entsprechenden privaten IP-Adresse der Instanz innerhalb des Amazon EC2 Netzwerks aufgelöst wird. Der interne DNS Name wird nicht ausserhalb von Amazon EC2 aufgelöst.

Öffentliche Adressen

Während des Starts wird eine öffentliche Adresse einer EC2 Instanz mittels Network Address Translation (NAT) zugewiesen. Die öffentliche Adresse ist mit einer Instanz solange verknüpft, bis diese Instanz wieder beendet wird oder durch eine Elastic IP-Address ausgetauscht wird.

Kommunizieren Instanzen mit anderen Instanzen über ihre öffentliche IP Adresse entstehen zusätzliche Kosten, basierend auf regionalen oder dem Internet Datenverkehr, je nachdem ob sich die Instanzen in der selben Region befinden.

Öffentlicher DNS Name

Jede Instanz verfügt über einen externen DNS Namen, der zu der entsprechenden öffentlichen IP-Adresse der Instanz ausserhalb des Amazon EC2 Netzwerks und von innerhalb des EC2 Netzwerks aufgelöst wird.

Quelle

Categories
Tutorials @de

OpenNebula: Der Aufbau einer Private Cloud

Was ist eine Private Cloud?

Das Ziel einer Private Cloud besteht nicht darin, der Öffentlichkeit eine Schnittstelle zur Cloud zur Verfügung zu stellen. um damit eigene Kapazitäten über der Internet anzubieten. Es geht vielmehr darum, seinen eigenen lokalen Nutzern eine flexible und agile private Infrastruktur bereitzustellen, in der die genutzten Services virtualisiert innerhalb eines selbst administrierten Bereich ausgeführt werden, um die Belastung effizient aufzuteilen. Die virtuelle Infrastruktur-Schnittstelle von OpenNebula stellt den Administratoren Funktionen für die Virtualisierung, die Netzwerkverwaltung, die Konfiguration von Images und physischen Ressourcen, das Management, sowie dem Monitoring und dem Accounting.

Die Sicht des Benutzers

Mit einer OpenNebula Private Cloud steht Nutzern der Infrastruktur eine elastische Plattform zum schnellen Bereitstellen und Skalieren von Services bereit, um den dynamischen Anforderungen gerecht zu werden. Die virtuelle Infrastruktur-Schnittstelle bietet folgenden Möglichkeiten, um Services auf virtuellen Maschinen zu hosten, bereitzustellen, sowie zu kontrollieren und zu überwachen.

  • Kommandozeile
  • XML-RPC API
  • Libvirt Virtualization API inkl. Management Tools

Die folgenden Beispiele zeigen die Funktionalität, die von der OpenNebula Kommandozeile bereitgestellt wird, um eine Private Cloud zu verwalten.

Zunächst überprüfen wir den Host und den physikalischen Cluster:

$ onehost list
 HID NAME                      RVM   TCPU   FCPU   ACPU    TMEM    FMEM STAT
   0 host01                      0    800    800    800 8194468 7867604   on
   1 host02                      0    800    797    800 8387584 1438720   on

Anschließend kann mittels onevm eine virtuelle Maschine an OpenNebula übertragen werden. Dazu wird als erstes ein Template einer virtuellen Maschine benötigt, aus dem ein Image erstellt wird. Das Image wird in dem Verzeichnis /opt/nebula/images abgelegt.

CPU    = 0.5
MEMORY = 128
OS     = [
  kernel   = "/boot/vmlinuz-2.6.18-4-xen-amd64",
  initrd   = "/boot/initrd.img-2.6.18-4-xen-amd64",
  root     = "sda1" ]
DISK   = [
  source   = "/opt/nebula/images/disk.img",
  target   = "sda1",
  readonly = "no" ]
DISK   = [
  type     = "swap",
  size     = 1024,
  target   = "sdb"]
NIC    = [ NETWORK = "Public VLAN" ]

Nachdem die virtuelle Maschine z.B. bzgl. der CPU und des Arbeitsspeichers auf die eigenen Bedürfnisse angepasst wurde, kann diese übertragen werden.

$ onevm submit myfirstVM.template

Nach dem Übertragen der virtuellen Maschine erhalten wir eine ID, mit welcher die virtuelle Maschine identifiziert werden kann, um diese zu überwachen und zu steuern. Die ID erhalten wir mit dem folgenden Befehl:

$ onevm list
  ID     USER     NAME STAT CPU     MEM        HOSTNAME        TIME
   0 oneadmin    one-0 runn   0   65536          host01  00 0:00:02

Das Feld STAT beschreibt den aktuellen Status der virtuellen Maschine. Befindet sich dieser im Status runn, ist die virtuelle Maschine online und wird ausgeführt. Abhängig davon, wie das Image konfiguriert wurde, haben wir Kenntnis von der IP-Adresse, wodurch wir uns auf der virtuellen Maschine anmelden können.

Um eine Migration durchzuführen, verwenden wir erneut den onevm Befehl. Wenn wir z.B. die virtuelle Maschine (VID=0) nach host02 (HID=1) übertragen wollen, nutzen wir:

$ onevm livemigrate 0 1

Damit wird die virtuelle Maschine von host01 nach host02 übertragen. Der Befehl onevm list sollte eine ähnliche Ausgabe der Folgenden anzeigen:

$ onevm list
  ID     USER     NAME STAT CPU     MEM        HOSTNAME        TIME
   0 oneadmin    one-0 runn   0   65536          host02  00 0:00:06

Wie das System funktioniert

OpenNebula – Eigenschaften

  • Verwaltung virtueller Netzwerke: Virtuelle Netzwerke verbinden die einzelnen virtuellen Maschinen.
  • Erstellen virtueller Maschinen: Die Beschreibung jeder einzelnen virtuellen Maschine wird der Datenbank hinzugefügt.
  • Bereitstellen virtueller Maschinen: Der Scheduler entscheided auf Basis von Richtlinien, wo eine virtuelle Maschine ausgeführt wird.
  • Verwaltung virtueller Maschinen Images: Vor dem Ausführen werden die virtuellen Maschinen Images zu dem Host übertragen und SWAP Disk Images erstellt. Nach dem Ausführen werden die virtuellen Maschinen Images in das Repository zurückkopiert.
  • Verwaltung gestarteter virtueller Maschinen: Virtuelle Maschinen werden gestartet und der aktuelle Status periodisch abgefragt. Zudem können die virtuellen Maschinen heruntergefahren, angehalten, gestopped und migriert werden.

OpenNebula Private Cloud – Die wichtigsten Komponeten

  • Hypervisor: Der Virtualisierungsmanager – auf den Ressourcen des Clusters installiert, die OpenNebula für die Verwaltung der virtuellen Maschinen vorgesehen hat.
  • Virtual Infrastructure Manager: Zentrale Verwaltungseinheit zum Steuern und Überwachen der virtuellen Maschinen und Ressourcen. Unterstützt weiterhin die Verwaltung der virtuellen Netzwerke, das Life-Cycle Management der virtuellen Maschinen, das Management der virtuellen Maschinen Images sowie die Fehlertoleranz.
  • Scheduler: Verwaltung der Richtlinien für die virtuellen Maschinen hinsichtlich der gleichmäßigen Verteilung der Last, Server Konsolidierung, Zugehörigkeit, Reservierung der Kapazitäten und SLAs

Quelle

  • Building a Private Cloud
Categories
News

Forrester Research sieht Salesforce.com als „Leader“ bei Kundenservice-Anwendungen

Studie zeigt Trends für herausragenden Kundenservice:
Echtzeit, mobile Funktionalitäten und Social Computing

München – Die „Service Cloud 2” von salesforce.com nimmt eine marktführende Stellung unter den Kundenservice-Lösungen ein. Das ergibt die im Juli erschienene Studie „The Forrester Wave: CRM Suites Customer Service Solutions, Q3 2010” von Forrester Research. Darin bezeichnet das unabhängige Analystenhaus die Service Cloud 2 als „Leader”. Die Service Cloud 2 führt in der Dimension „Gesamtstrategie“ das Feld der CRM-Anbieter an. Weitere hohe Punktzahlen erreicht die salesforce.com-Lösung hinsichtlich Benutzerfreundlichkeit, Amortisationszeit und Produktstrategie.

Besondere Anerkennung erhält salesforce.com für „schnelles Unternehmenswachstum durch das Anbieten SaaS-basierter CRM-Lösungen“. Ebenfalls positiv hervorgehoben werden der Mehrwert für Call Center-Agenten sowie die Integration des Themas „soziales Internet“. Zudem werden die bedarfsspezifische Anpassbarkeit der Lösung, ihre Sicherheit, ihre Benutzerfreundlichkeit sowie der Einsatz von Web 2.0-Technologien und die Möglichkeit zur mobilen Nutzung betont. Eine hohe Wertung erzielte salesforce.com auch für sein aktuelles Produktangebot, vor allem hinsichtlich Kundenservice, Lösungsarchitektur und -plattform.

Die genannten Stärken decken sich mit aktuellen Trends im Kundenservice. Dazu zählen

  • die zunehmende Bedeutung von Echtzeitmethoden, angetrieben durch soziale Netzwerke,
  • der Einsatz von Wissensmanagement-Tools zur eigenständigen Lösungsfindung durch die Kunden,
  • mobile Funktionalitäten und
  • der Einsatz von Social Computing, um Kundenservice über eine Vielzahl von Kanälen bieten zu können.
Categories
Grundlagen Services @de

Typen von EC2 Instanzen

Amazon EC2 Instanzen sind in drei Gruppen unterteilt. Standard, High-CPU und High-Memory. Standard Instanzen sind so ausgestattet, dass sie allen Anforderungen von gewöhnlichen Anwendungen gerecht werden. High-CPU Instanzen verfügen über verhältnismäßig mehr Prozessoren als Arbeitsspeicher und sind auf rechenintensive Anwendungen ausgelegt. High-Memory Instanzen hingegen verfügen über mehr Arbeitsspeicher und sind für Anwendungen mit einem hohen Datendurchsatz, wie z.B. Datenbanken und Caching, ausgelegt.

Bei der Auswahl einer Instanz kann somit jedem Server seine eigene Instanz zugewiesen werden. Für einen Webserver wird z.B. eine weniger leistungsstarke Instanz benötigt als für einen Datenbankserver.

Verfügbare Instanz-Typen

Die folgende Tabelle beschreibt die verfügbaren EC2 Instanz-Typen.

Typ
CPU
Arbeitsspeicher
Lokaler Speicher
Plattform
I/O
Name
Small 1 EC2 Compute Unit (1 virtual core mit 1 EC2 Compute Unit) 1.7 GB 160 GB instance storage (150 GB plus 10 GB root partition) 32-bit Moderate m1.small
Large 4 EC2 Compute Units (2 virtual cores mit je 2 EC2 Compute Units) 7.5 GB 850 GB instance storage (2 x 420 GB plus 10 GB root partition) 64-bit High m1.large
Extra Large 8 EC2 Compute Units (4 virtual cores mit je 2 EC2 Compute Units) 15 GB 1690 GB instance storage (4 x 420 GB plus 10 GB root partition) 64-bit High m1.xlarge
High-CPU Medium 5 EC2 Compute Units (2 virtual cores mit je 2.5 EC2 Compute Units) 1.7 GB 350 GB instance storage (340 GB plus 10 GB root partition) 32-bit Moderate c1.medium
High-CPU Extra Large 20 EC2 Compute Units (8 virtual cores mit je 2.5 EC2 Compute Units) 7 GB 1690 GB instance storage (4 x 420 GB plus 10 GB root partition) 64-bit High c1.xlarge
High-Memory Extra Large 6.5 EC2 Compute Units (2 virtual cores mit 3.25 EC2 Compute Units) 17.1 GB 420 GB instance storage (1 x 420 GB) 64-bit Moderate m2.xlarge
High-Memory Double Extra Large 13 EC2 Compute Units (4 virtual cores mit je 3.25 EC2 Compute Units) 34.2 GB 850 GB instance storage (1 x 840 GB plus 10 GB root partition) 64-bit High m2.2xlarge
High-Memory Quadruple Extra Large 26 EC2 Compute Units (8 virtual cores mit je 3.25 EC2 Compute Units) 68.4 GB 1690 GB instance storage (2 x 840 GB plus 10 GB root partition) 64-bit High m2.4xlarge
HCluster Compute 33.5 EC2 Compute Units (2 x Intel Xeon X5570, quad-core “Nehalem” architecture) 23 GB 1690 GB instance 64-bit storage (2 x 840 GB plus 10 GB root partition) 64-bit Very high (10 Gbps Ethernet) cc1.4xlarge

Quelle