Kategorien
Analysen

Was Unternehmen aus dem Amazon EC2 Problem in North Virginia lernen sollten!

Am 21. April haben wir es wieder erlebt. Auch eine hochverfügbare Cloud wie die von Amazon ist nicht vor Fehlern geschützt. Natürlich erhalten Kritiker nun wieder die Gelegenheit gegen die Nutzung der Cloud zu argumentieren. Aber um es vorweg zu nehmen, Anbieter wie Hootsuite, Mobypicture, Foursquare und Reddit hätten von dem Ausfall nicht betroffen sein müssen, hätten Sie auf eine ausfallsichere Architektur gesetzt.

Aus diesem Grund ist es nicht nachvollziehbar, dass diese Unternehmen mit dem Finger auf Amazon zeigen und sagen: „Uns trifft keine Schuld, Amazon ist down!“. Es wäre interessant zu wissen, wer zur Rechenschaft gezogen worden wäre, hätten diese Anbieter keinen Public Cloud Service genutzt, sondern betrieben ein eigenes Rechenzentrum. Denn eines ist klar, (solche) Probleme können in jedem Rechenzentrum auftreten und hätten dann bedeutend schwerwiegendere Probleme. Und wenn die Cloud richtig genutzt worden wäre, wären auch die Probleme bei Amazon in der Form nicht sichtbar geworden.

Was ist passiert?

Hintergrund
Die Amazon Cloud besteht aus mehreren Regionen, verteilt über mehrere Kontinente, in denen sich wiederum mehrere sogenannte Availability Zones befinden. Availability Zones sind verschiedene Standorte innerhalb einer Region, die so konstruiert sind, dass sie isoliert betrieben werden und von Fehlern in anderen Availability Zones nicht betroffen sind.

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 Availability Zones ausgeführt werden.

Wie das Konzept genau funktioniert, kann unter Das Konzept hinter den AWS Regionen und Verfügbarkeitszonen nachgelesen werden.

Das Problem
Um 1:41 AM PDT begann das Problem mit Latenzen und Fehlerraten innerhalb der EBS Volumes und Verbindungsproblemen zu den EC2 Instanzen in mehreren Availability Zones der Region US-EAST-1.

Das führte dazu, dass die Webseiten bzw. Webanwendungen, die auf den EC2 Instanzen betrieben werden, nicht mehr erreichbar waren.

Design For Failure

Zunächst muss eines klar sein. Amazon stellt „nur“ virtuelle Ressourcen zum Aufbau einer eigenen virtuellen Infrastruktur bereit. Amazon ist NICHT für die Anwendung und deren Funktionalität zuständig, sondern stellt nur die Infrastruktur bereit, auf der die Anwendungen ausgeführt werden.

„Everything fails, all the time“ Werner Vogels, CTO Amazon.com

Aus diesem Grund rät Amazon: „Design for failure!“ und gibt Tipps, dieses umzusetzen:

  • Avoid single points of failure
  • Assume everything fails, and design backwards
  • Goal: Applications should continue to function even if the underlying physical hardware fails or is removed or replaced.

Und nennt Möglichkeiten für die Realisierung des Designs:

  • Use Elastic IP addresses for consistent and re-mappable routes
  • Use multiple Amazon EC2 Availability Zones (AZs)
  • Create multiple database slaves across AZs
  • Use Amazon Elastic Block Store (EBS) for persistent file systems

Design for failure! Ist im Prinzip nichts Neues. Im Grunde sollte das ebenfalls bei jedem anderen nicht Cloud Anbieter und im eigenen Rechenzentrum beachtet werden. Der Entwickler sollte immer in der Pflicht stehen, seine Anwendung gegen Hardware oder sonstige Ausfälle abzusichern und die Verfügbarkeit sicherzustellen.

Hootsuite und Mobypicture bspw. haben den Fehler gemacht, sich nur auf eine AWS Region zu konzentrieren, anstatt ihren Service über die gesamte Amazon Cloud hinweg zu verteilen. Speziell bei Mobypicture, als einen europäischen Anbieter mit Sitz in Holland, ist genau dies ein wenig verwunderlich. Die deutsche Seite von Foursquare hingegen war bspw. erreichbar und lief stabil, ebenso die von Reddit.

Nicht alles auf eine Karte setzen

Für jedes Unternehmen, das seinen Service über die Cloud anbietet, gilt es daher: „Nutze die gesamte Cloud eines Anbieters und verlasse Dich nicht nur auf einen einzigen Anbieter!“

Durch die Verteilung einer Anwendung über mehrere Regionen und Availability Zones bei einem Anbieter wird die Verfügbarkeit der Anwendung drastisch erhöht. Zudem ist eine MultiVendor Strategie zwingend erforderlich. Außerdem müssen bereits von Beginn an Fallback Szenarien entwickelt werden, um gegen einen plötzlichen Ausfall vorbereitet zu sein.

Es geht also bspw. darum, Systeme aufzubauen, die im Fehlerfall automatisch eine gespiegelte Infrastruktur bei einem anderen Anbieter aufbauen. Besser wäre es, mehrere Anbieter parallel zu nutzen und die Services über mehrere Anbieter hinweg zu verteilen. Dazu gehört z.B.: Instanzen von unterschiedlichen Anbietern parallel produktiv einzusetzen, um damit das Risiko zu streuen.

Denn: Cloud Computing löst nicht alle Probleme automatisch…

Für die Zukunft

Amazon darf auf keinen Fall von einer Schuld freigesprochen werden, dazu werben sie viel zu deutlich mit der eigenen Verfügbarkeit. Dennoch, beim Cloud Computing handelt es sich um bedeutend mehr als nur das Nutzen von ein paar virtuellen Ressourcen und jeder Nutzer der Cloud ist für die Verfügbarkeit seiner Anwendung selber verantwortlich. Dafür stehen ihm ausreichend Mittel und Wege auf Grund der Cloud zur Verfügung!

Kategorien
Analysen

Wo bleibt der Killer PaaS?

Es gibt nunmehr eine Vielzahl von Platform as a Service (PaaS) Angeboten auf dem Markt, die mehr oder weniger jede moderne Programmiersprache unterstützen. Doch eines haben alle gemeinsam. Jedes Angebot setzt auf maximal einem Infrastructure as a Service (IaaS) Angebot auf. Sei es ein Proprietäres oder das eines Drittanbieters. Wie zu erwarten ist derzeit noch die Infrastruktur von AWS die bevorzugte Wahl.

Betrachten wir eine kleine Auswahl von PaaS Angeboten und das darunter eingesetzte IaaS Angebot.

Was also fehlt ist ein unabhängiges gehostetes PaaS Angebot. Eine richtige PaaS Innovation! Eine Art PaaS Broker. SteamCannon geht in diese Richtung. Jedoch ist er 1. kein unabhängiger gehosteter Service (es steht ein AWS AMI zur Verfügung) und 2. wird derzeit nur AWS EC2 unterstützt.

Selbstverständlich muss der Service auch auf einer Plattform betrieben werden, aus diesem Grund mag das Verlangen nach einem unabhängigen gehosteten Service zunächst missverständlich sein. Aber bereits hier muss die Macht der Cloud genutzt werden. Der Killer PaaS darf nicht nur als AMI auf einer Infrastruktur laufen, sondern muss über mehrere Anbieter hinweg verteilt sein. So ist bereits dessen Ausfallsicherheit gewährleistet.

Der Killer

Warum ich diesen Service als Killer PaaS bezeichne ist ganz einfach. Er muss alle IaaS Anbieter und nicht nur einen bestimmten am Markt, sowie alle gängigen Programmiersprachen, unterstützen. Die Funktionalität ist in der Theorie recht simpel. Als Nutzer des Killer PaaS habe ich bereits vorher bei unterschiedlichen IaaS Anbietern wie AWS, Rackspace, GoGrid etc. einen Account registriert. Alternativ bietet mir der Killer PaaS an, dort einen erstellen zu lassen.

Nach belieben werden die Zugangsdaten für den jeweiligen IaaS Anbieter hinterlegt, auf die der Killer PaaS zugreifen kann. Ich kann bereits hier, wenn ich möchte, meinen primäre, sekundären etc. Anbieter festlegen. Mehr habe ich als Nutzer nicht zu tun.

Möchte ich meine Anwendungen in der Cloud betreiben, lade ich den Programmcode auf den Killer PaaS hoch. Dieser kümmert sich nun um den Rest und deployed die Anwendung auf die von mir hinterlegten Infrastrukturen. Das kann er entweder willkürlich vornehmen, da er den Status der jeweiligen Infrastruktur bzgl. Performance etc. kennt, oder er zieht die von mir vorher festgelegten Einstellungen in betracht und verteilt die Anwendung auf den primären Anbieter. Falls dieser zu ausgelastet ist auf den Sekundären usw..

Der Killer PaaS ist so intelligent, dass er die gesamte Anwendung über mehrere Anbieter hinweg verteilt und damit die bestmögliche Performanz und Verfügbarkeit gewährleistet. Habe ich mich als Nutzer jedoch zu Beginn dafür entschieden die Anwendung bei einem primären Anbieter ausführen zu lassen und hat dieser nun Performance- oder anderweitige Probleme, sorgt der Killer PaaS dafür, dass automatisch weitere (oder alle) Ressourcen von einem anderen Anbieter genutzt werden. Mir sind Fälle bekannt, bei denen Anwender bei AWS keine neuen Instanzen in einer AWS Region mehr starten konnten, weil nicht genügend Ressourcen vorhanden waren. Davon darf ich bzw. meine Anwendung jedoch nichts mitbekommen. Wenn meine Anwendung plötzlich einer enormen Belastung, z.B. auf Grund eines Besucherandrangs, ausgesetzt ist und der IaaS Provider ebenfalls einen Ressourcenengpass hat, sorgt der Killer PaaS dafür, dass Ressourcen von einem anderen Anbieter bezogen oder andere Maßnahmen eingeleitet werden.

Mit so einem Killer PaaS können ebenfalls viele Fragen bzgl. SLAs geklärt werden. Die Ausfallsicherheit und Verfügbarkeit der Anwendung wird hier durch den Killer PaaS sichergestellt. Da dieser ebenfalls über mehrere IaaS Anbieter hinweg in der Cloud betrieben wird, ist auch dessen Verfügbarkeit gewährleistet.

Was also benötigt wird ist eine unabhängige Cloud Management Platform wie bspw. enstratus, nur für PaaS.

Kategorien
Services

Big Blues Kampf im Jungle – IBM gegen Amazon

Mit den „Smart Business Clouds“ hat nun auch IBM seine Public Cloud Infrastruktur für Unternehmenskunden vollständig geöffnet und hat angekündigt im Laufe des Jahres ein weiteres Angebot mit einer deutlich höheren Verfügbarkeit zu veröffentlichen.

IBMs „Smart Business Clouds“ (SmartCloud) bestehen aus den eigenen vorkonfigurierten x64-basierten CloudBurst Stacks und werden in einer Vielzahl von Cloud Rechenzentren überall auf der Welt betrieben. IBM unterscheidet seine SmartCloud in den Angeboten Enterprise und Enterprise+, die von den IBM’s Global Technology Services vertrieben werden.

Die bereits verfügbare „SmartCloud Enterprise“ Infrastruktur umfasst ausschließlich x64-basierte Server und bietet ein Service Level Agreement (SLA) mit einer Verfügbarkeit von 99,5%. Weiterhin unterstützt IBM auf seinen virtuellen Maschinen 32-bit und 64-bit Betriebssysteme wie Microsoft Windows 2003 und 2008, Red Hat Enterprise Linux 5.4 und 5.5 und Novell SUSE Linux Enterprise 11

Die „SmartCloud Enterprise+“ Infrastruktur wird in der zweiten Jahreshälfte von 2011 erwartet. Kunden erhalten hier die Möglichkeit, x64 basierte oder Power Server zu kaufen, auf denen sie ihre Anwendungen betreiben können. Hier erhöht IBM zudem seine SLAs auf 99,9% Verfügbarkeit

Im Gegensatz zu seinem Angebot „Smart Business Development and Test on the IBM Cloud“, bei dem IBM als Hypervisor auf eine RedHat/ KVM Kombination setzt, nutzen die „SmartClouds“ den VMware ESXi Hypervisor. Um auch Kunden zu bedienen, die auf andere Hypervisor setzen als den von VMware, wird IBM dazu übergehen müssen, ebenfalls KVM und Microsofts Hyper-V zu unterstützen. Auf den Power Servern in der „SmartCloud Enterprise+“ setzt IBM auf seinen eigenen PowerVM Hypervisor und unterstützt hier die Betriebssysteme AIX Unix, Red Hat Enterprise Linux, sowie den SUSE Linux Enterprise Server.

Die Abrechnung der SmartClouds erfolgt pro VM pro Stunde. Zudem steht ein Softwarekatalog bereit, aus dem sich Kunden IBM spezifische Anwendungen wie Middleware, Groupware und Datenbanken, sowie Anwendungen von Drittanbietern wie die Cloud Management Software von Kaavo oder Plattformen zur Entwicklung von Webanwendungen wie von Aviarc, beziehen können.

Die Preise für die SmartClouds sind ebenfalls öffentlich. Vergleichbar mit Amazons EC2 rechnet IBM auch hier on-Demand ab und bietet seinen Kunden Optionen auf reservierte Kapazitäten. Das „SmartCloud Enterprise+“ Angebot hingegen wird nicht stündlich on-Demand abgerechnet. Hier muss sich der Kunde entweder für eine monatliche Abrechnung oder einen festen Vertrag mit Laufzeit entscheiden. Jedoch stehen ihm hier weitere Managed Services, sowie mehrere Sicherheitsstufen zur Verfügung.

Wie ebenfalls von Amazon EC2 bekannt, kann ein Kunde auch bei den „SmartClouds“ zwischen unterschiedlichen Konfigurationen von virtuellen Maschinen wählen. Je nach Leistungsstufe wird hier von Copper bis Platinum unterschieden.

Für eine 32-bit Konfiguration kann je nach Leistungsstufe zwischen 1 bis 4 virtuellen CPUs mit 1,25 GHz, zwischen 2GB bis 4GB virtuellen RAM und zwischen 60GB und 350GB virtuellen Instanzspeicher gewählt werden. Für einen Red Hat Enterprise Linux Server und einer Copper Konfiguration berechnet IBM 15.4 Dollar(cent) pro Stunde.

Für eine 64-bit Konfiguration kann je nach Leistungsstufe zwischen 2 bis 16 virtuellen CPUs mit 1,25 GHz, zwischen 4GB bis 16GB virtuellen RAM und zwischen 60GB und 2TB virtuellen Instanzspeicher gewählt werden.

Im Vergleich zu Amazon EC2 ist die IBM SmartCloud erheblich teurer, was aber daran liegt, das IBM mit seinem Angebot gezielt nur Unternehmen anspricht. So kostet die kleinste 32-bit Copper Instanz mit einem SUSE Enterprise Linux Server 11.0 0,095 Dollar pro Stunde und eine 64-bit Platinum Instanz mit einem Red Hat Linux Enterprise Server 5.4 und 5.5 1,84 Dollar pro Stunde. (Jeweils für nicht reservierte Kapazitäten.)

Das sich das Angebot an Unternehmen richtet, wird bei der Registrierung deutlich. Hier kann zwischen weiteren „Optional Premium Services“ wie „On-boarding support“ (Remote on-boarding support | Einmalig 3.000 Dollar), „Virtual Private Network service“ (Network isolation of your instances through a virtual private network on the IBM Cloud | Einmalig 1.000 Dollar plus 300 Dollar monatlich) oder weiterem „Support“ unterschieden in „Premium support“ für 5% von der Gesamtnutzungsgebühr pro Monat (aber mindestens 75$ pro Monat) und „Advanced Premium support“ für 10% von der Gesamtnutzungsgebühr pro Monat (aber mindestens 1000$ pro Monat), gewählt werden.

Die SmartCloud Enterprise Infrastruktur befindet sich in unterschiedlichen Cloud Rechenzentren überall auf der Welt. Kunden aus den USA beziehen die Services aus Raleigh in North Carolina und Boulder in Colorado. Kanadische Kunden werden aus Toronto in Ontario bedient. Für Europa, den mittleren Osten und Afrika werden die Services über ein Rechenzentrum aus Ehningen in Deutschland bereitgestellt, sowie für asiatische Kunden über ein Rechenzentrum in Singapur und Tokio.

Fazit

Für Unternehmenskunden sind die IBM „SmartCloud Enterprise Services“ auf Grund ihrer umfangreichen Serviceleistungen ein attraktives wenn auch teures Angebot. Ob IBM damit tatsächlich den Kampf mit Amazon aufnehmen kann und möchte bleibt fraglich. Denn einen entscheidenen und attraktiven Vorteil hat Amazon gegenüber IBM. Die AWS Cloud ist ein echtes Public Cloud Angebot und ist für jedermann zugänglich. So haben auch Entwickler oder „normale Menschen“ mit einer Idee die Möglichkeit die Services von Amazon zu nutzen. IBM hingegen richtet sich gezielt an Unternehmenskunden und hat nicht den Bedarf auf die Wünsche einfacher Benutzer einzugehen.

Aus eigener Sicht betrachtet, muss IBM sich darauf auch nicht einlassen, da die Dienstleistungen seit jeher Unternehmen adressierten. Spannend bleibt, ob und wie Amazon darauf reagiert. Wie bereits oben erwähnt, kann sich Amazon jedoch darauf berufen, die „Cloud für jedermann“ zu sein. Vor allem Startups, Entwickler mit innovativen Ideen und Fachabteilungen die „nur mal etwas ausprobieren wollen“, werden weiterhin auf Grund des unkomplizierten Ressourcenbezugs und der einfachen und kostengünstigen Abrechnung auf die AWS Cloud zurückgreifen.

Kategorien
Events

Die SecTXL ‘11 – "Juristische und Technische Sicherheit für die Cloud!"

Der Hype um das Thema Cloud Computing hat sich mittlerweile auch in Deutschland gelegt und die heiße Phase der Adaption hat begonnen. Damit stehen Unternehmen neben technischen Herausforderungen ebenfalls Fragen bzgl. der Datensicherheit, des Datenschutzes und rechtlicher Themen gegenüber.

Die SecTXL ‘11 nimmt sich am 11.08.2011 in Hamburg genau diesen Themen an und konzentriert sich ganzheitlich mit ihrem Leitsatz „Juristische und Technische Sicherheit für die Cloud!“ auf den Bereich der Cloud Computing Sicherheit. Neben fachlichen Vorträgen von Rechtsanwälten und Experten aus den Bereichen des Datenschutzes und der Datensicherheit werden ebenfalls technische Probleme und deren Lösungen von IT-Architekten vorgestellt. Damit werden Möglichkeiten aufgezeigt, wie sich Unternehmen in Zeiten des Cloud Computing aus dem Blickwinkel der Sicherheit verhalten müssen.

Für eine Festigung und Vertiefung des während der Vorträge vermittelten Wissens finden im Anschluss an die Vortragsreihe eine Auswahl von Workshops statt. In diesen werden die Referenten dann detaillierter auf das von Ihnen vorgestellte Thema eingehen, weitere Ansätze erarbeiten sowie Fragen beantworten.

Mit einem Audience Talk erhalten darüber hinaus drei Teilnehmern die Möglichkeit, vor allen Referenten und den restlichen Teilnehmern einen themenbezogenen Vortrag ihrer Wahl zu halten, in welchem sie ihre Meinung zu einem bestimmten Bereich mitteilen dürfen. Dieser darf natürlich gerne polarisierend sein. Dazu können alle Teilnehmer während der Registrierung oder auch gerne im Nachhinein einen Themenvorschlag einreichen.

Der krönende Abschluß der Veranstaltung sind die SecTXL Awards, bei denen die Referenten für ihre Leistungen ausgezeichnet werden. Dazu stimmen alle Teilnehmer während der Veranstaltung für ihren Favoriten ab.

Mit einem SecTXL Leitfaden Cloud Computing Sicherheit wird zudem im Anschluß der Veranstaltung eine Publikation veröffentlicht, in der alle Referenten ihr Wissen noch einmal zum Besten geben. Diesen werden alle Teilnehmer exklusiv und kostenlos erhalten.

Alle weiteren Informationen und die Anmeldung sind unter http://sectxl.com zu finden.

Kategorien
Analysen

Die "Mobile Cloud" ist der wahre Megatrend

Genau genommen laufen die beiden Megatrends Mobile Computing und Cloud Computing bereits seit mehreren Jahren Hand in Hand nebeneinander her.

Worauf viele Anbieter wie z.B. Apple jahrelang verzichtet haben, hat Google bereits während der Einführung von Android besonderen Wert gelegt und hat damit das enorme Wachstumspotential erkannt. So hat Google z.B. seine Dienste wie Mail, Kalender etc. sowie das App Deployment über den Market Cloud basiert ausgerichtet.

Das erste Android Endgerät (HTC Dream | T-Mobile G1) kam am 22.10.2008 auf den Markt. Zielgruppe waren in erster Linie Privatnutzer, die mit einem Googlekonto ihre E-Mails, Termine, Kontakte etc. synchronisieren wollten. Nach etwas über einem Jahr entwickelte sich das System langsam aber sicher zu einer mobilen Plattform für den Unternehmenseinsatz. Das Update auf Android 1.6 brachte nun auch die lang ersehnte Möglichkeit, das Endgerät via VPN mit einer Gegenstelle zu verbinden. Verbindungen können hierbei über die Protokolle PPTP und L2TP (IPsec PSK bzw. IPsec CRT) hergestellt werden.

Für den Einsatz im Unternehmen stehen Anwendungen für unterschiedliche Bereiche zur Verfügung. Als mobiler Dateimanager ist der Astro File Manager eine gute Alternative. Wie schon auf den Palm Handhelds hat Dataviz ebenfalls für Android eine Version seiner mobilen Office Suite Documents To Go im Portfolio. Über einen kostenlosen Viewer können Word Dokumente, Excel Dateien und Power Point Präsentationen betrachtet werden. Die kostenpflichtige Version gestattet dann auch das Erstellen und Bearbeiten der oben genannten Dateien und zusätzlich das Betrachten von PDF-Dateien. Für Administratoren steht das Programm Server up bereit. Damit können Netzwerke und Webserver mobil überwacht werden und es informiert über unterschiedliche Arten u.a. per SMS oder E-Mail, wenn z.B. ein Server nicht mehr erreichbar ist. Salesforce, Anbieter von Geschäftsanwendungen (u.a. CRM) stellt seine Produkte ebenfalls als mobile Versionen mit dem Namen Salesforce Mobile zur Verfügung. Da diese allerdings über den Webbrowser genutzt werden sind sie daher aber nicht auf Android beschränkt. Für den Abruf von E-Mails bzw. die Synchronisation mit einem Microsoft Exchange Server stehen u.a. Anwendungen wie K-9 Mail, TouchDown oder Aardvark bereit.

Der meiner Ansicht nach größte Vorteil von Android, der auch für den Einsatz im Unternehmen spricht ist die Portabilität. Neben Smartphones funktioniert Android auf den beliebten Netbooks und Tablets. Aber ebenso der Einsatz auf modernen Kassensystemen, MDEs (Mobile Datenerfassung) und jeder Art von Embedded Systems ist vorstellbar.

Optimales Szenario

Das bisher noch einfachste und bzgl. Android mit dem wenigsten Aufwand verbundene Szenario ist der vollständige Einsatz der Google Infrastruktur. Das setzt allerdings voraus, dass von dem Unternehmen bereits Google Apps für die E-Mail Kommunikation und die Verwaltung der Kalender und Kontakte eingesetzt wird. Android ist per se vollständig in die Google Infrastruktur integriert. Somit werden alle Änderungen die z.B. im E-Mail Postfach oder im Kalender stattfinden automatisch mit den Google Servern synchronisiert. Daher sind die Daten eines Benutzers – egal an welchem Arbeitsplatz (Desktop/ Mobil) er sitzt – immer auf dem aktuellen Stand. E-Mails werden über den Push-Mail Dienst automatisch auf das mobile Endgerät zugestellt. Dies ist wohlgemerkt das optimale Szenario und kann so nicht ohne einen Mehraufwand umgesetzt werden, wenn z.B. ein Exchange Server eingesetzt wird.

Ideal für eine Cloud Strategie

Android verfolgt u.a. den Ansatz des Cloud Computing. Das heißt die Daten liegen dabei in einer Serverfarm im Internet und synchronisieren sich in diesem Fall mit dem mobilen Endgerät.
Entscheidet sich ein Unternehmen z.B. für das oben beschriebene Szenario, bei dem die Daten bei Google gespeichert werden, kann hier auf die Bereitstellung und Wartung der mobilen Infrastruktur im eigenen Rechenzentrum verzichtet werden, was einen klaren Kostenvorteil bedeutet. Durch das Speichern der Unternehmensdaten auf den Servern und nicht auf dem mobilen Endgerät sind die Daten geschützt. Das Endgerät kann im Falle eines Diebstahls oder anderen Missgeschicken jederzeit zentral gesperrt bzw. generell zentral administriert werden. Telefongespräche können über das Unternehmensnetzwerk stattfinden. Die Gespräche werden vom mobilen Endgerät gestartet und anschließend vom Unternehmensnetzwerk geroutet (z.B. in das Festnetz) und gesteuert. Der Vorteil besteht in der deutlichen Trennung von privaten und geschäftlichen Gesprächen, der Nutzung einer einzigen Rufnummer und den Zugriff auf die zentrale Kontaktdatenbank des Unternehmens. Neben (mobilen) Telefonkonferenzen über das Unternehmensnetzwerk unabhängig von Ort/ Zeit und beliebig vielen Benutzern besteht die Möglichkeit den aktuellen Status jedes Benutzers abzufragen um so zu sehen ob dieser gerade Verfügbar ist. Weiterhin haben u.a. Außendienstmitarbeiter Zugriff auf sämtliche Daten (z.B. CRM oder ERP) von jedem Ort mittels einer (mobilen) Internetverbindung.

Fazit

Die Mobile Cloud ist kein Zukunftsthema sondern bereits seit längerer Zeit in der Gegenwart angekommen. In ihr verschmelzen die beiden Megatrends Mobile Computing und Cloud Computing zu einem Hypertrend (wenn man diesen so bezeichnen darf) und ermöglichen Unternehmen und Ihren Mitarbeitern somit den Zugriff auf sämtliche Daten von jedem Ort und zu jeder Zeit.

Kategorien
Events

Der Ablauf des CloudOps Summit

Der CloudOps Summit 2010 am 17.03.2011 will den Focus auf den Betrieb und die Architektur von Cloud Computing Infrastrukturen legen und eine Brücke zwischen den bislang oft Marketing-getriebenen Angeboten hin zum Betrieb und den Architekten solcher Lösungen schlagen. Unter dem Motto “Run your Cloud” wollen die Veranstalter besonders das Thema “Betrieb von dynamischen und cloud-basierten Infrastrukturen” in den Vordergrund stellen und die Teilnehmer zu einer intensiven Diskussion einladen.

Nach einer Serie von Lightning Talks von 5 bis 7 Minuten Länge, sollen die Teilnehmer im Rahmen von 4 Workshop-Tracks mit jeweils 2 Vorträgen die Gelegenheit haben, die Themen zu vertiefen. Die Workshop-Tracks sind wie folgt strukturiert:

Track 1 – Management

  • Datenschutz/Datensicherheit
  • Compliance
  • Strategien
  • Nachhaltigkeit

Dieser Track wird den Schwerpunkt auf Themen legen, mit den sich heute die Vorstände und IT-Strategen befassen müssen, um für einen erfolgreichen und nachhaltigen Einsatz von Cloud Computing im Unternehmen vorbereitet zu sein. Auch wird hier Raum für die Diskussion wirtschaftlichen und ökonomischen Aspekte und der damit verbundenen Chancen des Cloud Computing Paradigmas für Unternehmen sein.

Track 2 – Operations

  • Anbieter/Lösungen/Tools
  • Herausforderungen bei der Umsetzung
  • Migration

Im Operationstrack wollen die Veranstalter die Diskussion auf Erfahrungen bei Durchführung von konkreten Cloud Computing Projekten diskutieren und besonders auf Hindernisse, Herausforderungen und Werkzeuge eingehen. Ein weiterer Schwerpunkt wird die Migration existierender Anwendungen sein.

Track 3 – Architecture

  • Best Practices/Methoden
  • Standards/Zertifizierung
  • Open Source

Dieser Track soll Diskussionen um die Standardisierung und ‘Best Practices’ von Cloud Computing Lösungen und Architekturen umfassen und auch auf damit verbundene Themen wie Stacks, Plattformen und Open Source eingehen.

Track 4 – Investors/Startups

  • Elevator Pitches

Im Rahmen der Elevator Pitches wird ausgesuchten Startups die Gelegenheit gegeben sich und Ihre Cloud Computing Lösungen oder Projekte vorzustellen. Die Veranstalter wollen so die Chancen des Cloud Computing aufzeigen und entsprechende Firmen und Produkte präsentieren, die allen auf dem Weg in die Clouds begleiten werden.

Weitere Informationen und die Anmeldung sind auf http://cloudops.cloudcontrolled.com zu finden.

Kategorien
Tutorials

Ubuntu Enterprise Cloud Topologien

Eine Ubuntu Enterprise Cloud kann aus zwei, bzw. bis zu hunderten oder sogar tausenden physikalischen bestehen. Es ist daher wichtig, die möglichen Topologien zu verstehen, die auf Basis der vorhandenen physikalischen Maschinen aufzubauen sind.

1 physikalisches System (Nicht für den produktiven Einsatz empfohlen)

Dies ist die einfachste mögliche Konfiguration. Dabei werden der CLC/Walrus/CC/SC und NC alle gemeinsam auf einer einzigen Maschine betrieben. Diese Konfiguration unterscheidet sich nicht von allen anderen möglichen. Der einzige Unterschied besteht darin, dass der Netzwerkverkehr hierbei nicht durch das lokale Netzwerk übertragen wird.

    1. Maschine A: CLC/Walrus/CC/SC/NC

Beispiel Konfiguration (für ein bestehendes LAN)

Netzwerk Konfiguration:

  • Netzwerk: 192.168.1.0/24
  • DHCP und DNS Server: 192.168.1.2
  • UEC Server: 192.168.1.4
  • /etc/network/interfaces auf dem UEC Server
iface eth0 inet manual

auto br0
iface br0 inet static
    address 192.168.1.4
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    gateway 192.168.1.2
    # dns-* options are implemented by the resolvconf package, if installed
    # these are google's dns servers
    dns-nameservers 8.8.8.8 8.8.4.4
    # this setting could be "local" if you all your local hosts
    #  were named something like a.localdomain b.localdomain c.localdomain etc
    dns-search localdomain
    bridge_ports eth0
    bridge_fd 9
    bridge_hello 2
    bridge_maxage 12
    bridge_stp off
  • /etc/eucalyptus/eucalyptus.conf – wichtige Einträge:
VNET_PUBINTERFACE="br0" # must match the br definition above
VNET_PRIVINTERFACE="br0" # must match the br definition above
VNET_MODE="MANAGED-NOVLAN"
VNET_SUBNET="172.19.0.0" # ips from this range are bound to $VNET_PRIVINTERFACE:priv
VNET_NETMASK="255.255.0.0"
VNET_DNS="192.168.1.2" # what DNS server nodes are given
# v - should be ips on the LAN, not in use anywhere, and excluded from the DHCP server
VNET_PUBLICIPS="192.168.1.100-192.168.1.110"

Sollten das Netzwerk nach der Konfiguration nicht starten helfen die folgenden Befehle beim Korrigieren.

sudo stop eucalyptus CLEAN=1
sudo /etc/init.d/eucalyptus-nc stop
# fix the config file here
sudo start eucalyptus CLEAN=1
sudo /etc/init.d/eucalyptus-nc start

Der Parameter CLEAN sorgt dafür, dass sich das Netzwerk nicht bei jedem Neustart resetet. Es sollte darauf geachtet werden, dass kein System auf die ETH0 Schnittstelle gebunden ist. Um sicherzugehen, dass man mit einer sauberen Konfiguration arbeiten kann, ist ein Neustart des gesamten Systems. Wurde die PRIV Schnittstelle falsch konfiguriert, werden die Nodes ihre DHCP-Antworten von dem LAN-DHCP-Server anstelle des privaten CC-DHCP-Server erhalten.

Mindestens 2 physikalische Systeme

Bei dieser Konfiguration werden alle Verwaltungskomponenten für den Benutzer wie CLC und Walrus, sowie die Verwaltungskomponenten für das Backend wie der CC und SC auf einer gemeinsamen Maschine installiert. Der NC für das Hosting der virtuellen Maschinen erhält eine eigene physikalische Maschine.

    1. Maschine A: CLC/Walrus/CC/SC
    2. Maschine B: NC
    3. (weitere NCs…)

Mindestens 3 physikalische Systeme

Bei dieser Konfiguration werden die Verwaltungskomponenten für den Benutzer wie CLC und Walrus auf eine physikalische Maschine, sowie die Verwaltungskomponenten für das Backend wie der CC und SC auf einer weiteren zweiten Maschine installiert. Der NC für das Hosting der virtuellen Maschinen wird auf eine dritte physikalische Maschine installiert.

    1. Maschine A: CLC/Walrus
    2. Maschine B: CC/SC
    3. Maschine C: NC
    4. (weitere NCs…)

Mindestens 4 physikalische Systeme

Bei dieser Konfiguration erhalten der CLC und Walrus jeweils eine eigene physikalische Maschine. Auf die dritte Maschine werden der CC und SC installiert. Für den NC wird eine vierte physikalische Maschine eingesetzt.

    1. Maschine A: CLC
    2. Maschine B: Walrus
    3. Maschine C: CC/SC
    4. Maschine D: NC
    5. (weitere NCs…)

Mindestens 5 physikalische Systeme

Für diese Konfiguration werden der CLC und der Walrus auf einer gemeinsamen Maschine konfiguriert. Auf eine dritte Maschine werden der CC1 sowie der SC1 installiert. Für den NC1 kommt eine eigene Maschine zum Einsatz. Um die Performance der Cloud zu erhöhen und die Last besser zu verteilen, werden auf einer vierten Maschine ein CC2 und ein SC2 konfiguriert. Auf eine fünfte Maschine wird ein NC2 installiert, der anschließend seine Ressourcen von dem CC2 und SC2 erhält.

    1. Maschine A: CLC/Walrus
    2. Maschine B: CC1/SC1
    3. Maschine C: NC1
    4. Maschine D: CC2/SC2
    5. Maschine E: NC2
    6. (weitere CCs/SCs/NCs…)

Quelle: UECTopologies

Kategorien
Tutorials

Einrichten der openQRM Cloud für das Deployment von physikalischen Windows Systemen auf CentOS 5.5

Dieses Tutorial zeigt Schritt für Schritt, wie eine openQRM Cloud auf CentOS 5.5 so eingerichtet wird, dass damit anschließend physikalische Windows Systeme deployed werden können. Für dieses Tutorial werden dazu zwei physikalische Systeme benötigt.

1. Los geht es mit einer neuen CentOS 5.5 Installation

Während der Installation des Systems nehmen wir eine manuelle Partitionierung vor und erstellen 3 Partitionen:

    1. primary ext3 mounted at / (the rootfs)
    2. primary swap
    3. primary “lvm” (wird zum Speichern des Server-Image benötigt)

An dieser Stelle ist es wichtig zu beachten, ein benutzerspezifisches Partitionsschema zu wählen und eine dedizierte Partition zu erstellen, auf der später die Server-Images gespeichert werden. (/dev/hda3). Bei der Paketauswahl selektieren wird zudem das “Gnome Desktop Environment”. Weitere Software wird nicht benötigt.

Wichtig: SELinux und die Firewall müssen deaktiviert werden!

Wenn die Installation abgeschlossen ist, starten wir das System neu und melden uns an.

Die folgende Konsolenausgabe zeigt die exakte CentOS Version. Alle Konsolenbefehle in diesem Tutorial werden des Weiteren mit „root“ ausgeführt.

[root@cloud ~]# lsb_release -a
LSB Version: :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description: CentOS release 5.5 (Final)
Release: 5.5
Codename: Final
[root@cloud ~]#

2. Vorbereiten des Netzwerks

Nun bearbeiten wir die /etc/sysconfig/network-scripts/ifcfg-eth0 und tragen eine statische, private IP-Adresse ein. (In diesem Beispiel: 192.168.88.6)

[root@cloud network-scripts]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
HWADDR=00:02:b3:a0:d3:12
ONBOOT=yes
DHCP_HOSTNAME=cloud
IPADDR=192.168.88.6
NETMASK=255.255.255.0
GATEWAY=192.168.88.1
TYPE=Ethernet
[root@cloud network-scripts]#

Um die Änderungen zu übernehmen, starten wir das Netzwerk neu.

[root@cloud network-scripts]# /etc/init.d/network restart
Shutting down interface eth0: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0:
[ OK ]
[root@cloud network-scripts]#

Nun hinterlegen wir die statische IP-Adresse (in unserem Fall “192.168.88.6″) und den Hostname (in unserem Fall “cloud”) in der /etc/hosts. Der Hostname darf hierbei nicht in der ersten Zeile zusammen mit 127.0.0.1 stehen!

[root@cloud ~]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
192.168.88.6 cloud
::1 localhost6.localdomain6 localhost6
[root@cloud ~]#

3. Vorbereiten des Speicherplatz für die Server-Images

Nun bereiten wir die dedizierte Partition so vor, dass sie zusammen mit lvm genutzt werden kann. Anschließend erstellen wir eine Logical Volume Group “vol”.

[root@cloud ~]# pvcreate /dev/hda3
Physical volume "/dev/hda3" successfully created
[root@cloud ~]# vgcreate vol /dev/hda3
Volume group "vol" successfully created
[root@cloud ~]# vgs
VG #PV #LV #SN Attr VSize VFree
vol 1 0 0 wz--n- 186.22G 186.22G
[root@cloud ~]#

4. Installation des Enterprise iSCSI Target

Seitdem CentOS das „ietd“ (Enterprise iSCSI Target) nicht mehr als Standard RPM Paket unterstützt, müssen wir dieses nun aus den Sourcen erstellen.

[root@cloud ~]# yum -y install kernel-devel openssl-devel gcc rpm-build
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
.... 
Complete!
[root@cloud ~]#

Wir erstellen ein ietd Verzeichnis und laden und entpacken die letzte iscsi-target-[version].tar.gz Version von http://iscsitarget.sourceforge.net

[root@cloud ~]# mkdir ietd
[root@cloud ~]# cd ietd/
[root@cloud ietd]# wget http://sourceforge.net/projects/iscsitarget/files/iscsitarget/1.4.20.1/iscsitarget-1.4.20.1.tar.gz/
.... 
2002-06-10 20:41:12 (245 KB/s) - `iscsitarget-1.4.20.1.tar.gz' saved [137487/137487]
[root@cloud ietd]# tar -xzf iscsitarget-1.4.20.1.tar.gz
[root@cloud ietd]# cd iscsitarget-1.4.20.1

Kompilieren:

[root@cloud iscsitarget-1.4.20.1]# make
Applying Patch compat-2.6.32.patch
patching file kernel/conn.c
Applying Patch compat-2.6.31.patch
.... 
CC [M] /root/ietd/iscsitarget-1.4.20.1/kernel/seq_list.o
LD [M] /root/ietd/iscsitarget-1.4.20.1/kernel/iscsi_trgt.o
Building modules, stage 2.
MODPOST
CC /root/ietd/iscsitarget-1.4.20.1/kernel/iscsi_trgt.mod.o
LD [M] /root/ietd/iscsitarget-1.4.20.1/kernel/iscsi_trgt.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.18-194.3.1.el5-i686'

Installieren:

[root@cloud iscsitarget-1.4.20.1]# make install
`usr/ietd' -> `/usr/sbin/ietd'
`usr/ietadm' -> `/usr/sbin/ietadm'
`etc/initd/initd.redhat' -> `/etc/init.d/iscsi-target'
install: creating directory `/etc/iet'
`etc/ietd.conf' -> `/etc/iet/ietd.conf'
`etc/initiators.allow' -> `/etc/iet/initiators.allow'
`etc/targets.allow' -> `/etc/iet/targets.allow'
`doc/manpages/ietadm.8' -> `/usr/share/man/man8/ietadm.8'
`doc/manpages/ietd.8' -> `/usr/share/man/man8/ietd.8'
`doc/manpages/ietd.conf.5' -> `/usr/share/man/man5/ietd.conf.5'
install: creating directory `/usr/share/doc/iscsitarget'
`ChangeLog' -> `/usr/share/doc/iscsitarget/ChangeLog'
`COPYING' -> `/usr/share/doc/iscsitarget/COPYING'
`RELEASE_NOTES' -> `/usr/share/doc/iscsitarget/RELEASE_NOTES'
`README' -> `/usr/share/doc/iscsitarget/README'
`README.vmware' -> `/usr/share/doc/iscsitarget/README.vmware'
`README.initiators' -> `/usr/share/doc/iscsitarget/README.initiators'
`kernel/iscsi_trgt.ko' -> `/lib/modules/2.6.18-194.3.1.el5/extra/iscsi/iscsi_trgt.ko'
Running depmod
[root@cloud iscsitarget-1.4.20.1]#

Verlinken den Ablageort der ietd.conf Konfigurationsdatei.

[root@cloud ~]# mv /etc/iet/ietd.conf /etc/iet/ietd.conf.org
[root@cloud ~]# > /etc/ietd.conf
[root@cloud ~]# ln -s /etc/ietd.conf /etc/iet/ietd.conf
[root@cloud ~]#

Und starten das iSCSI-Target:

[root@cloud ~]# /etc/init.d/iscsi-target start
Starting iSCSI Target: [ OK ]
[root@cloud ~]#

5. Vorbereiten der Datenbank

Als Datenbank für den openQRM Server nutzen wir das Package “mysql-server”.

[root@cloud ~]# yum -y install mysql-server
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
.... 
Complete!
[root@cloud ~]#

Nach der Installation starten wir den mysqld service.

[root@cloud ~]# /etc/init.d/mysqld start
Initializing MySQL database: Installing MySQL system tables...
100521 14:44:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
100521 14:44:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
OK
Filling help tables...
100521 14:44:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
100521 14:44:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
OK
To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h cloud password 'new-password'
Alternatively you can run:
/usr/bin/mysql_secure_installation
which will also give you the option of removing the test
databases and anonymous user created by default. This is
strongly recommended for production servers.
See the manual for more instructions.
You can start the MySQL daemon with:
cd /usr ; /usr/bin/mysqld_safe &
You can test the MySQL daemon with mysql-test-run.pl
cd mysql-test ; perl mysql-test-run.pl
Please report any problems with the /usr/bin/mysqlbug script!
The latest information about MySQL is available on the web at
http://www.mysql.com
Support MySQL by buying support/licenses at http://shop.mysql.com
[ OK ]
Starting MySQL: [ OK ]
[root@cloud ~]#

Nun prüfen wir, dass wir uns mit der Datenbank verbinden können.

[root@cloud ~]# mysql
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 2
Server version: 5.0.77 Source distribution
Type 'help;' or 'h' for help. Type 'c' to clear the buffer.
mysql> quit
Bye
[root@cloud ~]#

Und fügen mysqld zu den init Startskripten mittels chkconfig hinzu.

[root@cloud bin]# chkconfig --add mysqld
[root@cloud bin]# chkconfig mysqld on
[root@cloud bin]# chkconfig --list mysqld
mysqld 0:off 1:off 2:on 3:on 4:on 5:on 6:off
[root@cloud bin]#

6. Installation von openQRM

openQRM wird in diesem Tutorial aus den Sourcen erstellt. Diese sind in dem Subversion Repository des openQRM Projects verfügbar. Für die Installation sind hier lediglich ein Subversion Client und “make” notwendig. Diese sollten also installiert werden.

[root@cloud ~]# yum -y install subversion
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
.... 
Complete!
[root@cloud ~]#

Nun müssen die openQRM Sourcen aus dem SVN Repository ausgecheckt werden.

[root@cloud ~]# svn co https://openqrm.svn.sourceforge.net/svnroot/openqrm openqrm
.... 
A openqrm/trunk/src/rpm/README
A openqrm/trunk/src/rpm/openqrm-entire.spec
A openqrm/branches
A openqrm/tags
Checked out revision 1996.
[root@cloud ~]#

Wir wechseln in das src/ Verzeichnis.

[root@cloud ~]# cd openqrm/trunk/src/
[root@cloud src]#

Anschließend führen wir “make” aus. Dafür wird eine funktionsfähige Internetverbindung benötigt. Sollte dieses nicht der Fall sein, können die Sourcen auch von http://sourceforge.net/projects/openqrm/files/openQRM-4.6/source/openqrm-thirdparty-cache.tgz/download heruntergeladen werden. Diese müssen danach in das Home-Verzeichnis entpackt werden.

[root@cloud src]# make
.... 
[root@cloud src]#

Alle Ergebnisse der Kompilierung werden vom openQRM-Build System automatisch gecached. Um sicherzustellen, dass alle Komponenten richtig erstellt wurden, kann “make” einfach erneut ausgeführt werden.

[root@cloud src]# make
Checking requirements for the compilation phase
openqrm-server requires: make, gcc, portmap, rsync, zlib-devel, wget, tar, bzip2, unzip, patch
found make installed
found gcc installed
found portmap installed
found rsync installed
found zlib-devel installed
found wget installed
found tar installed
found bzip2 installed
found unzip installed
found patch installed
openqrm-plugin-aoe-storage requires:
openqrm-plugin-aws requires:
openqrm-plugin-citrix requires:
openqrm-plugin-cloud requires:
openqrm-plugin-collectd requires:
openqrm-plugin-dhcpd requires:
openqrm-plugin-dns requires:
openqrm-plugin-equallogic-storage requires:
openqrm-plugin-highavailability requires:
openqrm-plugin-image-shelf requires:
openqrm-plugin-iscsi-storage requires:
openqrm-plugin-kvm requires:
openqrm-plugin-kvm-storage requires:
openqrm-plugin-linux-vserver requires:
openqrm-plugin-linuxcoe requires:
openqrm-plugin-local-server requires:
openqrm-plugin-local-storage requires:
openqrm-plugin-lvm-storage requires:
openqrm-plugin-nagios2 requires:
openqrm-plugin-nagios3 requires:
openqrm-plugin-netapp-storage requires:
openqrm-plugin-nfs-storage requires:
openqrm-plugin-puppet requires:
openqrm-plugin-sanboot-storage requires:
openqrm-plugin-solx86 requires:
openqrm-plugin-sshterm requires:
openqrm-plugin-tftpd requires:
openqrm-plugin-tmpfs-storage requires:
openqrm-plugin-vbox requires:
openqrm-plugin-vmware-esx requires:
openqrm-plugin-vmware-server requires:
openqrm-plugin-vmware-server2 requires:
openqrm-plugin-windows requires:
openqrm-plugin-xen requires:
openqrm-plugin-xen-storage requires:
openqrm-plugin-zabbix requires:
openqrm-plugin-zfs-storage requires:
Checking for required components to compile openQRM finished successfully
if [ -d ./thirdparty ]; then mkdir -p ../buildtmp; cp -aR ./thirdparty/* ../buildtmp/; fi
-> found component gpxe (undionly.kpxe.0.9.9.tgz) already downloaded
-> found component kvm-nic-bios (kvm-nic-bios-1.1.tgz) already downloaded
-> found component openqrm-client.windows (openQRM-Client-4.6.1-setup.exe) already downloaded
-> found component sshterm-component (openqrm-plugin-sshterm-components-1.0.tgz) already downloaded
Creating the default initrd-template
-> found component busybox (busybox-1.14.2.tar.bz2) already downloaded
-> Found busybox-1.14.2/_install/bin/busybox already in the build-cache
-> Skipping compilation, taking the ready built component from the cache
-> found component pciutils (pciutils-3.1.4.tar.gz) already downloaded
-> Found pciutils-3.1.4/pcimodules already in the build-cache
-> Skipping compilation, taking the ready built component from the cache
-> found component dropbear (dropbear-0.52.tar.gz) already downloaded
-> Found dropbear-0.52/dropbear already in the build-cache
-> Skipping compilation, taking the ready built component from the cache
Adding /sbin/portmap to default initrd-template
Adding /sbin/rpc.statd to default initrd-template
Adding /bin/bash to default initrd-template
Adding /usr/bin/rsync to default initrd-template
Adding /usr/bin/wget to default initrd-template
Adding /sbin/modprobe to default initrd-template
Adding /sbin/depmod to default initrd-template
Adding /sbin/insmod to default initrd-template
Adding /sbin/lsmod to default initrd-template
Adding /sbin/mke2fs to default initrd-template
Adding /sbin/sfdisk to default initrd-template
Adding /sbin/udevd to default initrd-template
Adding /lib/udev/vol_id to default initrd-template
-> found component gpxe (undionly.kpxe.0.9.9.tgz) already downloaded
-> found component kvm-nic-bios (kvm-nic-bios-1.1.tgz) already downloaded
-> found component openqrm-client.windows (openQRM-Client-4.6.1-setup.exe) already downloaded
-> found component sshterm-component (openqrm-plugin-sshterm-components-1.0.tgz) already downloaded
-> found component adodb (adodb498.tgz) already downloaded
-> found component jquery (jquery-1.3.2.tgz) already downloaded
-> found component js-interface (interface_1.2.zip) already downloaded
-> found component openqrm-client.centos.i386 (openqrm-client.4.6.1.centos.i386.tgz) already downloaded
-> found component openqrm-client.centos.x86_64 (openqrm-client.4.6.1.centos.x86_64.tgz) already downloaded
-> found component openqrm-client.debian.i386 (openqrm-client.4.6.1.debian.i386.tgz) already downloaded
-> found component openqrm-client.debian.x86_64 (openqrm-client.4.6.1.debian.x86_64.tgz) already downloaded
-> found component openqrm-client.ubuntu.i386 (openqrm-client.4.6.1.ubuntu.i386.tgz) already downloaded
-> found component openqrm-client.ubuntu.x86_64 (openqrm-client.4.6.1.ubuntu.x86_64.tgz) already downloaded
-> found component openqrm-initrd-template.centos.i386 (openqrm-initrd-template.4.6.1.centos.i386.tgz) already downloaded
-> found component openqrm-initrd-template.centos.x86_64 (openqrm-initrd-template.4.6.1.centos.x86_64.tgz) already download
-> found component openqrm-initrd-template.debian.i386 (openqrm-initrd-template.4.6.1.debian.i386.tgz) already downloaded
-> found component openqrm-initrd-template.debian.x86_64 (openqrm-initrd-template.4.6.1.debian.x86_64.tgz) already download
-> found component openqrm-initrd-template.ubuntu.i386 (openqrm-initrd-template.4.6.1.ubuntu.i386.tgz) already downloaded
-> found component openqrm-initrd-template.ubuntu.x86_64 (openqrm-initrd-template.4.6.1.ubuntu.x86_64.tgz) already download
[root@cloud src]#

Nun führen wir “make install” aus.

[root@cloud src]# make install
include/
include/openqrm-plugin-local-storage-functions
bin/
.... 
Creating the openqrm-client boot-service package
[root@cloud src]#

Am Ende initialisieren und starten wir openQRM mittels “sudo make start”.

[root@cloud src]# make start
Checking the requirements for RedHat based systems ...
openqrm-server requires: httpd, php, php-mysql, php-soap, mysql, syslinux, screen, procmail, openssl
-> found httpd installed
NOTICE: Trying to automatically install php ...
Loaded plugins: fastestmirror
.... 
Checking for required components finished successfully
Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.88.6 for Server
[ OK ]
First startup detected. Running initialization.
Looking for syslinux/pxelinux.0...found: /usr/lib/syslinux/pxelinux.0
Creating custom apache config.../etc/httpd/conf.d/openqrm-httpd.conf
Checking /usr/share/openqrm/etc/openqrm-server.conf for OP[ OK ]B_PROTOCOL=https..Reloading httpd:
Adding password for user openqrm
Initializing dropbear...
Will output 1024 bit rsa secret key to '/usr/share/openqrm/etc/dropbear/dropbear_rsa_host_key'
Generating key, this may take a while...
Public key portion is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgmOa49UMeOPqid06cR96yfRD/SQ98J1REpLKyyJ518iFFQyGKb9j2quZD+8FfKYt6rgFgS6
kGw95qJf6lqYc/rIH5ezcl4bVCn0Zo9pQkTyF496+iAp6AbPOX9KfBivu+5KWc7sfxOiDWGErPhzTGSkvjxwDAu2PkXAvTjUHMhhXxLk= root@cloud
Fingerprint: md5 de:cc:34:cb:2b:e5:b1:3d:50:dd:cc:f0:b5:ca:e9:e5
Adding public key to /root/.ssh/authorized_keys...
Starting the openQRM-server ver. 4.6.
Initialization complete. Please configure your openQRM Server at: http://192.168.88.6/openqrm/
-> User: openqrm -> Password: openqrm
[root@cloud src]#

“make start” führt zusätzlich eine Check-Routine aus, die überprüft, dass alle Abhängigkeiten für die Einwandfreie Nutzung von openQRM vorhanden sind. Ggf. nicht vorhandene Pakete werden automatisch installiert.

Während des ersten Starts wird der openQRM Server initialisiert. Nachdem openQRM vollständig installiert wurde, kann nun die Konfiguration mittels der Weboberfläche vorgenommen werden.

7. Konfiguration von openQRM

Wir melden uns am openQRM Server per http://ip-adresse/openqrm an. Der Benutzer und das Passwort sind jeweils “openqrm”. Nach der Konfiguration sollten diese Daten geändert werden.

Als erstes wählen wir als Netzwerkkarte die Bridge Schnittstelle für das openQRM Management.

Als Datenbank für das openQRM Backend wählen wir “myslq”.

Anschließend konfigurieren wir die Verbindungsinformationen für die Datenbank.

openQRM ist nun vollständig konfiguriert.

Wir werden automatisch zum Datacenter Dashboard weitergeleitet.

8. Erstellen eines Windows Image

Mit dem Plugin-Manager müssen wir als nächstes die folgenden Plugins aktivieren und starten:

  • dhcpd
  • tftpd
  • sanboot-storage
  • windows
  • cloud

Anschließend wechseln wir nach Base >> Components >> Create >> Storage. Dort erstellen wir einen neuen Speicher vom Typ “Sanboot-Storage (iSCSI)” und wählen den openQRM Server als Ressource.

Wir geben dem Storage Server einen Namen und speichern diesen.

Die Liste der verfügbaren Speicher sind nun wie folgt aus.

Wir klicken auf den “Mgmt” Button des neu erstellten “sanboot” Storage Server.

Hier wählen wir die Volume Group “vol”.

Nun erstellen wir ein neues Volume mit dem Namen “windowsxp″. Die Größe muss etwas größer sein als die der lokalen Festplatte des Systems, das verwendet wird, um das Image zu erstellen.

In unserem Tutorial verwenden wir eine 40 GB große lokale Festplatte, um ein Windows System zu installieren und zu einem LUN auf ein iSCSI-Target zu übertragen. Das Volume das wir erstellen hat eine Größe von 41GB und ist damit ein wenig Größer als die eigentliche physikalische Festplatte.

Mittels der Konsole würden wir wie folgt vorgehen:

[root@cloud ~]# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
windowsxp vol -wi-ao 40.04G
[root@cloud ~]# cat /etc/ietd.conf
Target windowsxp:windowsxp
Lun 0 Path=/dev/mapper/vol-windowsxp,Type=fileio
[root@cloud ~]#

Installation von Windows auf der lokalen Festplatte des zweiten Systems

In diesem Tutorial verwenden wir Windows XP Professional und nutzen exakt die GPXE Anweisungen von http://etherboot.org/wiki/sanboot/winxp. Wir nutzen dazu eine frische Windows Installation und nehmen keine Partitionierung der Festplatte vor.

Achtung:

Es wird „Install local + Transfer to iSCSI Lun“ verwendet, da Windows XP es nicht unterstützt, direkt auf einem iSCSI-Target installiert zu werden. Neuere Windows Version wie bspw. Windows 7 können dagegen direkt auf einem iSCSI-Target installiert werden, siehe dazu http://etherboot.org/wiki/sanboot/iscsi_install

Nachdem Windows installiert wurde, fügen wir die “iSCSI Boot” Unterstützung hinzu. Dazu gehen wir auf die Webseite http://etherboot.org/wiki/sanboot/winnt_iscsi und laden dort die für Windows passende „Initiator 2.x boot-buildxxx-arch/lang.exe“ herunter. In unserem Fall i386/X86 EN.

Wir speichern die Datei auf unserem Desktop.

Wir führen die Datei aus und folgen den Anweisungen.

Nun laden wir den Windows SAN Boot Configuration Driver von http://etherboot.org/wiki/sanboot/winnt_sanbootconf herunter.

Die ZIp-Datei beinhaltet den SAN Boot Treiber. Wir entpacken den Inhalt auf unseren Desktop.

Nun starten wir den sanbootconf Installer und folgen den Anweisungen.

Damit ist die Installation abgeschlossen.

Übertragen des Festplatteninhalts mittels nc

Um den Inhalt der lokalen Festplatte des Windows Systems auf das iSCSI LUN auf dem “Sanboot” Storage Server zu übertragen, nutzen wir „nc“ und „dd“. Weitere Informationen hierzu sind unter http://solutions.unixsherpa.com/2009/08/10/remote-mirroring-using-nc-and-dd zu finden.

Nach der Windows Installation starten wir das System neu und konfigurieren den Systemstart im BIOS so, dass das System vom Netzwerk aus (pxe-boot) gestartet werden kann. Anschließend wird das System nun innerhalb von openQRM als neue „idle“ Ressource vom Typ “Physical System” gestartet.

Wenn sich das System im Status „idle“ befindet müssen wir die folgenden Schritte vornehmen, um den Festplatteninhalt des physikalischen Windows Systems auf das iSCSI LUN zu übertragen:

1. Starten eines nc Listener auf dem logischen Windows Volume

[root@cloud ~]# ls /dev/mapper/vol-windowsxp
/dev/mapper/vol-windowsxp
[root@cloud ~]# nc -l 12345 | dd of=/dev/mapper/vol-windowsxp
# this command won't return but listen on port 12345 to submit data
# which it reads bitwise from the network port to /dev/mapper/vol-windowsxp

2. Mittels des “openqrm login” Befehl anmelden
Here the syntax of the “openqrm login” comand:

/usr/share/openqrm/bin/openqrm login -i [ip-address-of-the-idle-resource-withe-the-windows-installed-on-local-disk]
[root@cloud ~]# cd /usr/share/openqrm/bin/
[root@cloud bin]# ./openqrm login -i 192.168.88.251
Login to resource 192.168.88.251 ...
Host '192.168.88.251' key accepted unconditionally.
(fingerprint md5 ff:5f:e7:60:ae:14:74:4a:39:15:8c:a6:62:98:73:0b)
bash-3.2#

Wir müssen hierbei beachten, dass die Shell in diesem Fall über keine PATH Umgebung verfügt. Die Befehle müssen daher unter der Angabe des vollständigen Pfads ausgeführt werden.

Der folgende Befehl dient dazu, die lokale Festplatte der Windows Installation zu identifizieren.

bash-3.2# cat /proc/partitions
major minor #blocks name
8 0 39082680 sda
8 1 39070048 sda1
bash-3.2# /sbin/fdisk -l /dev/sda
Disk /dev/sda: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 4864 39070048+ 7 HPFS/NTFS
bash-3.2#

3. dd und nc gemeinsam nutzen

Um den Festplatteninhalt remote auf das logische Volume zu übertragen, nutzen wir die Kombination von dd und nc.

bash-3.2#
bash-3.2# dd if=/dev/sda | nc 192.168.88.6 12345

Abhängig von der Größe der Festplatte und der Geschwindigkeit des Netzwerks, kann dieser Vorgang ein Weile dauern.

Auf dem openQRM Server kann der Befehl „kill -USR1 [pid-of-dd-process]“ genutzt werden, um zu sehen, wie viele Bytes dd bereits übertragen hat.

..
78165360+0 records in
78165360+0 records out
40020664320 bytes (40 GB) copied, 6322.11 seconds, 6.3 MB/s
[root@cloud ~]#

Nun führen für „sync“ aus, um sicherzustellen, dass alle Bits auf das logische Volume übertragen wurden.

[root@cloud ~]# sync
[root@cloud ~]#

9. Vorbereiten des Windows Image

Wir schalten die Ressource die sich im Zustand „idle“ befindet herunter (die Windows Installation auf der lokalen Festplatte), entfernen die Festplatte und starten sie über das Netzwerk neu.

Es sollte darauf geachtet werden, das die Bootreihenfolge auf „Network Boot only“ steht.

Wenn das System neu gestartet ist und sich im Status „idle“ befindet, erstellen wir erneut in logisches „Image“ in openQRM.

Wir wechseln dazu nach Base >> Components >> Create >> Image und wählen den “Sanboot” Storage Server.

Anschließend geben wir dem Image einen Namen und wählen das “windowsxp″ Volume als das Root-Device.

Die Liste der verfügbaren Images sind nun wie folgt aus.

Nun erstellen wir eine „Appliance“. Dazu wechseln wir zu Base >> Appliance >> Create und wählen die Ressource „idle“.

Wir nennen die „Appliance“ windowsxp, wählen den “default” kernel und das “windowsxp” Image und speichern die Appliance.

Wir starten die „Appliance“.

Das folgende Video auf YouTube zeigt den Systemstart des Windows Systems von dem iSCSI Storage Server.

Das Windows Image ist damit nun deployed und funktionsfähig. Nun müssen wir das Image so konfigurieren, damit es mittels openQRM verwaltet werden kann.

Dazu erstellen wir auf dem Windows Image im ersten Schritt einen Windows Benutzer mit dem Namen „root“.

Als nächstes muss der openQRM Client auf dem Windows Image installiert werden. Dazu öffnen wir einen Web-Browser und melden uns an den openQRM Server an.

Anschließend gehen wir zu Plugins >> Deployment >> Windows >> About

Hier laden wir den Windows openQRM-Client herunter.

Wir starten die openQRM-Client Installationsroutine und folgen den Anweisungen.

Now please run “gpedit.msc” and add the permission to “remote shutdown” to user “root”.

Wichtig: Sollte die Windows Firewall aktiviert sein, muss der TCP Port 22 geöffnet werden.

10. openQRM Cloud Konfiguration

Nun wechseln wir nach Plugins >> Cloud >> Configuration >> Main Config und konfigurieren die folgenden Punkte:

  • cloud_admin_email > eine valide E-Mail Adresse
  • auto_provision → true
  • external_portal_url → (optional) externe URL zu einem Cloud Portal
  • request_physical_systems → false
  • auto_give_ccus → 100
  • show_disk_resize → (optional) true
  • show_private_image → true
  • cloud_currency → (optional) auf US oder Euro setzen
  • cloud_1000_ccus → Wie viele 1000 CCUs wie viel US/Euro entsprechen

Für alle weiteren Konfigurationspunkte können die Standardwerte genommen werden. Speichern nicht vergessen!

Der folgende Screenshot zeigt die Hauptseite zur Konfiguration der Cloud.

Als nächstes müssen die Cloud Produkte mittels des „Cloud-Selector“ konfiguriert werden.

Dazu gehen wir nach Plugins >> Cloud >> Configuration >> Products >> Kernel und erstellen ein neues „Windows“ Kernel Produkt.

Das sieht dann wie im folgenden Screenshot aus.

Nun erstellen wir ein „Memory“ Produkt. Dieses muss den exakt verfügbaren Speicher aufweisen, das auf dem zweiten physikalischen System verfügbar ist. (Das System, welches das Windows Image deployed.) In diesem Tutorial verwenden wir ein System mit 3008 MB physikalischen Arbeitsspeicher. Dieser muss entsprechend angepasst werden.

Das sieht dann wie im folgenden Screenshot aus.

Nun erstellen wir ein “Physical System”.

Das sieht dann wie im folgenden Screenshot aus.

Der nächste Schritt besteht darin, der Cloud mitzuteilen, welche Images den Cloud Benutzern angezeigt werden sollen. Dazu wechseln wir nach Plugins >> Cloud >> Configuration >> Private Images und wählen in den Checkboxen „All“ für das „windowsxp “ Image.

Nun erstellen wir einen oder mehrere Cloud Benutzer. Hierfür gehen wir nach Plugins >> Cloud >> User und fügen einen neuen Benutzer inkl. einer gültigen E-Mail Adresse hinzu. Als Cloud Administrator kann man sich mit jedem beliebigen Cloud Benutzer anmelden, indem man auf den Namen des Cloud Benutzers klickt.

Die Liste der Cloud Benutzer sieht im Anschluss wie folgt aus.

Das openQRM Portal sieht nach einem erfolgreichen Login dann wie folgt aus.

Wir klicken auf den 2ten Tab mit dem Namen „Visual Cloud Designer“.

Der Virtual Cloud Designer zeigt alle verfügbaren Komponenten innerhalb der Cloud an. Mittels Drag and Drop kann nun eine eigene Cloud Appliance konstruiert werden.

Anschließend sollten die Kosten (stündlich, täglich, moantlich) für die Appliance betrachtet werden.

Mit einem einzigen Klick kann die Appliance der Cloud hinzugefügt werden.

Für das Cloud Deployment erstellt openQRM automatisch ein LVM Snapshot für das ursprüngliche Windows Image. Das bedeutet, dass es sich bei der (remote) Festplatte des Windows Image eigentlich um ein LVM Snapshot handelt. Im Storage Manager ist das Cloud Volume daher mit einem „s“ (Snapshot) gekennzeichnet.

Auf der Konsole verwendet man dazu den folgenden Befehl:

[root@cloud ~]# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
2.cloud_1_1_ vol swi-ao 19.53G windowsxp 0.06
windowsxp vol owi-ao 40.04G
[root@cloud ~]#

Lizenzen:
Wichtig! Für das Deployment jedes einzelnen Windows Image ist eine entsprechende und gültige Windows Lizenz erforderlich.

11. Die nächsten Schritte

  • Verwenden von Sanboot-Storage inkl. AOE Deployment
  • Separierung des Storage, Hypvervisors und openQRM auf dedizierte Systeme
  • openQRM Server als Hochverfügbarkeitslösung
  • Hinzufügen weiterer virtualisierter Hosts unterschiedlichen Typs
  • Hinzufügen von physikalischen Systemen
  • Hinzufügen von weiteren Storage Systemen
  • Aktivieren des automatischen Monitorings
  • IP- und Netzwerkmanagement
  • Cloud-Billing
  • Cloud Integration / SOAP WebService

Quelle

  • Howto: Setup openQRM Cloud deploying physical Windows Systems on CentOS 5.5
Kategorien
News

Salesforce.com stellt fünf neue Services für die Erstellung von Cloud 2-Apps vor

Mit Appforce, Siteforce, VMforce, ISVforce und Heroku hat salesforce.com fünf neue Cloud Plattform Services für die Erstellung von Cloud 2-Apps vorgestellt. Force.com 2 beseitigt dabei Hardware- und Softwarekomplexität und ermöglicht Unternehmen und ISVs, Anwendungsentwicklungsprojekte zu beschleunigen.

  • Appforce – Kollaborative Apps für verschiedene Abteilungen
    Appforce hilft Unternehmen leistungsfähige und skalierbare Apps für alle Abteilungen zu erstellen. Nutzer können Formulare anlegen, Reports anpassen, Unternehmensprozesse visuell abbilden und gleichzeitig sicher stellen, dass diese messbar und prüffähig sind. Und sie können über Salesforce Chatter zusammenarbeiten.
  • Siteforce – Pixelgenaue Erstellung von Webseiten ohne Code
    Die Erstellung von Webseiten ist oft langwierig und mühsam und fordert kontinuierlich neue Landing Pages, Produkte und Kampagnen. Zusätzlich stehen Entwickler heute vor der Herausforderung, soziale, mobile und Echtzeit-Funktionen zu integrieren. Siteforce gibt Anwendern die Werkzeuge an die Hand, um einfache Änderungen vornehmen zu können. Web-Entwickler haben die Möglichkeit, schnell leistungsstarke Seiten zu liefern. Siteforce macht es einfach, in Echtzeit Seiten zu entwerfen, Inhalte zu verwalten und vorgefertigte Komponenten wiederzuverwenden.
  • VMforce – Der Weg für Java-Entwickler in die Cloud
    VMforce, die salesforce.com-Partnerschaft mit VMware, ermöglicht es 6 Millionen Java-Entwicklern, ihre bestehende Java-Expertise sowie die Vorteile des Cloud Computings einzusetzen und neue, mobile und soziale Echtzeit-Anwendungen für Unternehmen in der Cloud zu erstellen. Mit VMforce können Entwickler ihre Java-Anwendungen direkt auf Force.com laufen lassen, die beliebten Java-Entwicklungsumgebungen Spring Framework und Eclipse IDE nutzen und offene Standards, wie zum Beispiel JPA für die Entwicklung von Javaanwendungen für Unternehmen verwenden. VMforce ist derzeit für ausgewählte Kunden als Beta-Programm verfügbar.
  • Heroku – Die Ruby Cloud Application-Plattform
    Heroku ist die führende Ruby Platform-as-a-service, die von Beginn an in einer offenen Umgebung erstellt wurde, um die Vorteile der Programmiersprache nutzen zu können. Ruby ist die führende Sprache für die Erstellung einer neuen Generation von Apps. Diese sind sozial, kollaborativ und ermöglichen Echtzeit-Zugang zu Informationen über mobile Endgeräte. Heroku ist heute Grundlage für mehr als 105.000 Apps.
  • ISVforce – Ermöglicht ISVs die Erstellung und Bereitstellung von multi-tenant Cloud-Apps
    ISVforce bietet ISVs umfassende Services für Anwendungsentwicklung, Tests und Bereitstellung, automatische Upgrade-Möglichkeiten, den AppExchange-Marktplatz für Cloud Apps sowie eine Echtzeit-Konsole zur Überwachung der Nutzung durch Kunden. ISVforce legt all diese Services hinter jede ISV App. Führende ISVs wie Blackboard, BMC und CA nutzen ISVforce um Anwendungen zu erstellen und zu liefern.
Kategorien
News

Amazon stellt Cloud DNS Dienst Amazon Route 53 vor

Bei Amazon Route 53 handelt es sich um einen hochverfügbaren und skalierbaren DNS (Domain Name System) Web Service. Route 53 verbindet Nutzeranfragen effektiver mit einer Infrastruktur die sich innerhalb der Amazon Web Services (AWS) befindet, wie bspw. einer Amazon Elastic Compute Cloud (Amazon EC2) Instanz, einem Amazon Elastic Load Balancer oder einem Amazon Simple Storage Service (Amazon S3) Bucket. Route 53 kann darüber hinaus ebenfalls dazu verwendet werden, um Nutzer zu einer Infrastruktur ausserhalb von AWS zu routen.

Route 53 löst DNS Anfragen mit einer geringen Latenz auf, indem ein globales Netzwerk von DNS Servern genutzt wird. Anfragen an eine Domain werden automatisch an den nächstgelegenen DNS Server weitergleitet und damit mit der best möglichen Performanz beantwortet. Route 53 stellt eine Web Service Schnittstelle bereit, über die Public DNS Einträge erstellt und verwaltet werden können und ist vollständig in alle bereits vorhandenen Amazon Web Services integriert. Zum Beispiel kann durch die Nutzung des AWS Identity and Access Management (IAM) in Kombination mit Route 53 bestimmt werden, wer Änderungen an den DNS Einträgen vornehmen kann.

Für die Nutzung von Route 53 müssen, wie bei alle anderen Amazon Web Services, keine langen Vertragslaufzeiten eingegangen oder Mindestumsätze generiert werden. Die Abrechnung erfolgt pro Domain, die mit dem Service verwaltet wird und pro Abfrage, die von Route 53 beantwortet wird.