Tag: Amazon


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.



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



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



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



Amazon ist das Mass aller Dinge im Cloud Computing Markt!

Amazon ist mit seinen Amazon Web Services (AWS) derzeit der Player im Cloud Computing Markt. Was wir bereits erahnt haben bzw. wussten, haben die Analysten Brian Pitz und Brian Fitzgerald von der UBS nun anhand von Zahlen bestätigt.

Die beiden gehen davon aus, dass AWS im Jahr 2010 etwa einen Umsatz von 500 Millionen US Dollar generieren und diesen im Jahr 2011 auf 750 Millionen US Dollar erhöhen wird. Bis zum Jahr 2014 wird ein Umsatz in der Höhe von 2,54 Milliarden US Dollar erwartet.

Weiterhin wird davon ausgegangen, dass der Gesamtmarkt für AWS-Dienste zwischen 5 Milliarden und 6 Milliarden US Dollar im Jahr 2010 und schließlich bis zu 15 Milliarden und 20 Milliarden US Dollar im Jahr 2014 wachsen wird.

Quelle

  • How Big is Amazon’s Cloud Computing Business?



Der Amazon EC2 Instanzspeicher

Jede Instanz verfügt über eine festen Speicherplatz, auf dem Daten gespeichert werden können. Dieser wird im EC2 Kontext als Instanzspeicher bezeichnet und ist nicht als permanente Speicherlösung gedacht.

Wird eine Instanz neu gestartet, bleiben die Daten auf dem Instanzspeicher bestehen. Wird die Instanz higegen beendet, gestoppt oder ein Fehler tritt auf, dann sind die Daten verloren.

Für den Einsatz einer dauerhaften Speicherlösung empfiehlt Amazon daher Amazon Elastic Block Store.

Sollte Amazon EBS nicht eingesetzt werden, sollten wichtige Daten auf Amazon S3 gesichert werden.

Speicherort

Wo sich der Speicher auf den jeweiligen Instanz Typen befindet, kann der folgenden Tabelle entnommen werden.

Ort
Beschreibung
/dev/sda1 Auf allen Linux/Unix Instanz Typen als root (/) formatiert und gemounted. Auf allen Windows Instanz Typen als C:\ formatiert und gemounted.
/dev/sda2 oder xvdb (Windows) Auf allen m1.small und c1.medium Instanzen als /mnt formatiert und gemounted. Auf allen small Windows Instanzen formatiert und gemounted.
/dev/sda3 Auf allen m1.small und c1.medium Instanzen für Linux/Unix Instanz Typen als /swap formatiert und gemounted. Für Windows Instanzen nicht verfügbar.
/dev/sdb oderr xvdb (Windows) Auf allen m1.large, m1.xlarge, c1.xlarge, m2.xlarge, m2.2xlarge, und m2.4xlarge Instanzen für Linux/Unix Instanz Typen als /mnt formatiert und gemounted. Für alle m1.large, m1.xlarge, c1.xlarge, m2.xlarge, und m2.2xlarge Windows Instanzen formatiert und gemounted.
/dev/sdc oder xvdc (Windows) Verfügbar auf m1.large, m1.xlarge und c1.xlarge Linux/Unix Instanzen. Auf m1.large, m1.xlarge, c1.xlarge und m2.4xlarge Windows Instanzen formatiert und gemounted.
/dev/sdd or xvdd (Windows) Verfügbar auf m1.xlarge und c1.xlarge Linux/UNIX Instanzen. Auf m1.xlarge und c1.xlarge Windows Instanzen formatiert und gemounted.
/dev/sde or xvde (Windows) Verfügbar auf m1.xlarge und c1.xlarge Linux/Unix Instanzen. Auf m1.xlarge und c1.xlarge Windows Instanzen formatiert und gemounted.

Quelle



Amazon Machine Images (AMI)

Eine Amazon EC2 Instanz kann auf Basis eines Amazon Machine Image (AMI) welches sich in Amazon EBS befindet oder eines AMI welches in Amazon S3 gespeichert ist gestartet werden. Dabei verwenden Instanzen, bei denen die AMIs in Amazon EBS gespeichert sind, EBS Volumes als Root Device (von wo gebooted wird). Dagegen nutzen Instanzen, deren AMIs in Amazon S3 abgelegt sind einen Instanzspeicher als das Root Device.

Die folgende Tabelle beschreibt die Unterschiede zwischen AMIs die in Amazon EBS abgelegt sind und AMIs die sich in Amazon S3 (Instanzspeicher) befinden.

Eigenschaften
Amazon EBS
Amazon S3 (Instanzspeicher)
Bootzeit Gewöhnlich weniger als 1 Minute. In der Regel weniger als 5 Minuten.
Größenbeschränkung 1 Terrabyte (TB) 10 Gigabyte (GB)
Speicherort Amazon EBS volume Instanzspeicher
Datenpersistenz Die Daten bleiben vorhanden, wenn die Instanz ausfällt und können gespeichert werden, wenn die Instanz beendet wird. Die Daten bleiben nur für die Lebensdauer der Instanz erhalten.
Erweiterung Der Instanz-Typ, Kernel, die RAM Disk und die Benuterdaten können geändert werden, während die Instanz gestoppt (angehalten) ist. Die Attribute einer Instanz sind für ihre Lebensdauer festgesetzt und können währenddessen nicht geändert werden.
Kosten Instanz Nutzung, Amazon EBS Volume Nutzung und Amazon EBS Snapshot Kosten zum Speichern der AMI. Instanz Nutzung und Amazon S3 Kosten zum Speichern der AMI.
AMI Erstellung / Bundling Verwendet einen einzigen Befehl / Anweisung Erfordert die Installation und die Nutzung der AMI Tools
Stoppen / Anhalten Kann in den Zustand "angehalten" überführt werden, wenn eine Instanz nicht ausgeführt wird, aber in Amazon EBS gespeichert ist. Kann nicht gestoppt werden, Instanzen werden ausgeführt oder nicht.

Öffentliche AMIs können direkt über Amazon oder die Amazon EC2 Community bezogen werden. Öffentliche AMIs dienen als Basis und können dazu benutzt werden, um eigene maßgeschneidert AMIs zu erstellen.

Private AMIs sind AMIs die einem selbst gehören. Auf diese kann daher nur selbst bzw. von Leuten zugegriffen werden, denen man den Zugriff erlaubt hat.

Shared AMIs werden von Entwicklern erstellt und anderen Entwicklern für die Nutzung zur Verfügung gestellt.

Paid AMIs können von Entwicklern oder Unternehmen wie z.B. RedHat gekauft werden. Es existieren ebenfalls AMIs die an spezielle Serviceverträge gekoppelt sind.

Quelle



Der Amazon EC2 Workflow

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

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

Quelle



Amazon EC2 mit Ubuntu Images (erste Schritte)

Dieser Artikel beschreibt die Nutzung der offiziellen Ubuntu Images unter Amazon EC2.

Um die Ubuntu Server Edition unter den Amazon Web Services auszuführen, sind folgende Schritte notwendig.

  • Erstellen eines Amazon Web Services Account
  • Konfigurieren der Keys
  • Installation der Amazon EC2 API Tools
  • Instanziierung der Images
  • Konfiguration der Instanz

Continue reading “Amazon EC2 mit Ubuntu Images (erste Schritte)” »



Das Konzept der Amazon Virtual Private Cloud

Bei der Amazon Virtual Private Cloud (VPC) handelt es sich um eine sichere und lückelose Integrationsmöglichkeit zwischen der bereits vorhandenen IT Infrastruktur eines Unternehmens und der Amazon Cloud und dient zum Aufbau einer Hybrid Cloud. Mit Amazon VPC können Unternehmen ihre existierende Infrastruktur mit speziell isolierten AWS Ressourcen mittel eines Virtual Private Network (VPN) verbinden, um damit die Verwaltungsmögklichkeiten wie die Bereiche Sicherheit, Firewall und Intrusion Dection für die AWS Ressourcen zu erweitern.

Um die Amazon Virtual Private Cloud zu nutzen, muss zunächst der IP-Adressraum für die VPC festgelegt werden. Die IP-Adressen innerhalb dieses Adressraums sind privat und bilden ein Netzwerk das mittels paketbasierten Routing von anderen Netzwerken inkl. dem Internet vollständig isoliert ist.

Als nächstes müssen Subnetze erstellt werden, welche Segmente eines VPC IP-Adressraums sind. Damit können die Amazon EC2 Instanzen innerhalb des VPC separiert und sicher betrieben werden. Existiert mehr als ein Subnetz in einem VPC, werden diese mittels eines logischen Routers sternförmig (Stern-Topologie) miteinander verbunden.

Um sich mit der VPC zu verbinden, wird eine VPN Verbindung benötigt, die als VPN Tunnel zwischen der VPC und dem Rechenzentrum, dem Heimnetzwerk oder jeder anderen Co-Location dient. Dazu muss das eigene bestehende Netzwerk so konfiguriert werden, dass jeglicher VPC Datenverkehr zu dem Gateway geroutet wird, welches das Ende der VPN Verbindung darstellt.

Mit einer aktiven VPN Verbindung können anschließend Amazon EC2 Instanzen in einem VPC subnetz starten. Mit den entsprechenden Sicherheitsrichtlinen ist diese Instanz dann ebenfalls im eigenen Netzwerk sichtbar und kann von dort aus wie eine "lokale" Instanz genutzt werden.

VPC basierter Datenverkehr der für das Internet bestimmt ist, wird zunächst automatisch über das VPN in das eigene Netzwerk gerouted. Dort kann dieser von bereits vorhandenen Sicherheitssystemen, wie Firewalls, Intrusion Detection Systemen untersucht werden, bevor die Daten in das Internet weitergeleitet werden. Das ist dann besonders sinnvoll, wenn spezielle Hardware- und Softwaresysteme eingesetzt werden, um bestimmte Sicherheitsrichtlinien zu erfüllen.

Quelle



Die Amazon S3 Konsole

Mit der Amazon S3 Konsole hat Amazon seine AWS Management Console erweitert. Wie schon von den bisherigen Konsolen, wie z.B. der für EC2 bekannt, handelt es sich um eine Weboberfläche, mit der sämtliche Amazon S3 Ressourcen verwaltet werden können. Dazu gehören das Erstellen neuer Buckets sowie das Hochladen von Objekten.

Um die Amazon S3 Konsole zu nutzen, reicht es aus sich mit seinem AWS Benutzeraccount und dem dazugehörigen Passwort anzumelden. Die Access Key ID und der Secrect Access Key werden nicht benötigt, diese werden automatisch durch AWS im Hintergrund geladen.

Damit integriert die AWS Management Console mit Amazon S3, Amazon EC2, Amazon CloudFront, Amazon Elastic MapReduce und Amazon RDS nun fünf Services an einer zentralen Stelle.

Mit der Amazon S3 Konsole können weiterhin Ordner angelegt, sowie Objekte der Öffentlichkeit zugänglich gemacht werden. Ordner und Objekte die mit S3 Tools von einem Drittanbieter erstellt wurden, können mit der Konsole ebenfalls bearbeitet werden.

Die Amazon S3 Konsole ist unter http://console.aws.amazon.com/s3 zu finden.



Scalarium

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

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

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

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

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

Auto Config

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

Weitere Informationen zu Auto Config sind HIER zu finden.

Auto Healing

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

Weitere Informationen zu Auto Healing sind HIER zu finden.

Auto-Scaling

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

Weitere Informationen zu Auto Scaling sind HIER zu finden.

One Click Deploy

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

Weitere Informationen zu One Click Deploy sind HIER zu finden.

Demo Video

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

Preise

Quelle



CloudCache

Mit CloudCache stellt das Unternehmen Quetzall eine flexible Caching Infrastuktur als Service bereit, in der über eine API beliebige Objekte zwischengespeichert werden können. Entwickler haben damit die Möglichkeit ihre Daten innerhalb eines in-memory Cache abzulegen um damit die Zugriffe auf die Datenbank zu verringern und die Performance zu erhöhen.

CloudCache kann u.a. für das Zwischenspeichern von Anfragen, Sessions oder Templates genutzt werden und funktioniert ebenfalls in Verbindung mit Amazon's Netzwerk Topologie.

Funktionen

  • Latenz: 1.5 ms
  • Multi-Get
  • Statistiken: Hits/Misses/Usage
  • Nutzung von 1 bis 1000 Caches
  • AJAX oder XML Unterstützung
  • Inkrementierungs- und Dekrementierungsmöglichkeiten
  • Konfigurierbare Time-to-Live der Objekte für das automatische Löschen

Dokumentation

CloudCache unterstützt derzeit die Programmiersprachen Ruby, Java, PHP und Python sowie eine Raw REST API. Um den Einstieg zu erleichtern existiert eine separate Dokumentationsseite auf der die ersten Schritte für den Umgang mit CloudCache erklärt werden.

Preise

  • $0.05/MB
  • 10 MB Cache frei bis zum 1.November 2010
  • Keine Vertragslaufzeit
  • Keine Einrichtungsgebühr
  • Abrechnung nach dem tatsächlichen Verbrauch
  • Monatliche Abrechnung

Demo Video

http://vimeo.com/7105046

Quelle

  • CloudCache



Thin Clients

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

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

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

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

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

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

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

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

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

Quelle der Graphik

  • NetPoint


JungleDisk

JungleDisk ist das Cloud Storage Angebot von Rackspace Cloud. Dabei handelt es sich im Prinzip um eine Schicht (Applikation) zwischen dem Benutzer bzw. dem lokalen PC/Server und dem Speicherdienst Amazon S3 oder dem von Rackspace.

Die Daten können bei Amazon S3 dabei wahlweise in den USA oder Europa gespeichert werden, was sich in den Preisen und der Geschwindigkeit (Latenz/ Laufzeiten) wiederspiegelt. Die Preise der jeweiligen Angebote setzen sich aus einer festen Grundgebühr (in USD) plus dem tatsächlich genutzen Speicherplatz auf S3 zusammen. Der genutzte Speicherplatz wird dabei mit den bekannten Gebühren von Amazon S3 verrechnet. In diesem Fall ist daher auch ein Amazon AWS Account erforderlich. Man bezahlt also hier - abgesehen von der Grundgebühr - nur für den Speicherplatz, der auch wirklich genutzt wird.

Die Abbrechnung erfolgt vollständig über Amazon. Man erhält am Anfang des Monats eine Rechnung von Amazon über die Grundgebühr der JungleDisk. Die Rechnung über den genutzen Speicherplatzverbrauch findet über den Amazon AWS Account statt.

JungleDisk stellt als einer der wenigen Anbieter für die drei großen Betriebssysteme Windows, Linux und MAC native Clients zur Verfügung. Weiterhin kann der Zugriff auf die gespeicherten Daten mittels einer Weboberfläche oder des iPhones stattfinden.

Die Datenübertragung und die Daten selber sind mit einer 256 bit AES Verschlüsselung gesichert. Zusätzlich können die Buckets auf Amazon S3 mit einem weiteren Passwort geschützt werden.

JungleDisk ist, wie es auf dem ersten Blick erscheint kein reines Tools für das Backup in der Cloud. Daten können ebenfalls damit über mehrere Rechner synchronisiert werden, was die Kollaboration verbessert.

Im Folgenden werden die vier Angebote der JungleDisk, die sich in die Bereiche Business und Personal unterteilen, vorgestellt.


Business Class

Die Business Class besteht aus der Workgroup Edition und der Server Edition. Dabei ist die Workgroup Edition auf Desktop PCs von kleinen bis mittleren Unternehmen ausgerichtet, mit der Backups erstellt, sowie Daten ausgetauscht und synchronisiert werden können. Die Server Edition dient zum Backup eines Servers und verfügt über Möglichkeiten das System per Fernwartung zu verwalten.

Workgroup Edition

Mit der Workgroup Edition können Daten mittels "Master Accounts" zwischen mehreren Benutzer ausgetauscht und synchronisiert werden. Dabei werden Teamgrößen von 2 - 100 Mitgliedern unterstützt. Die Benutzer können damit auf einfache Weise miteinander zusammenarbeiten und haben Zugriff auf ihre Daten auch dann, wenn Sie gerade nicht mit dem Internet verbunden sind. Wenn eine Internerverbindung wieder vorhanden ist, werden automatische alle Änderungen mit der Cloud synchronisiert. Der Zugriff auf die Daten kann ebenfalls über eine Weboberfläche oder ein iPhone erfolgen. Zudem steht eine protable Version zur Verfügung, die von einem USB-Stick ausgeführt werden kann. Die Daten werden mit einer 256 bit AES Verschlüsselung geschützt.

Preise

  • 4 USD pro Benutzer pro Monat + Gebühren von Amazon S3 (siehe unten)

Server Edition

Die Server Edition richtet sich an Windows und Linux Server. Mit ihr stehen im Prinzip unbegrenzte Speicherkapazitäten für Backups in der Cloud zur Verfügung. Die Abbrechnung erfolgt hier nach dem pay per use Modell, es entstehen also nur Kosten für den tatsächlich genutzten Speicherplatz.

Zur Verwaltung der Backups stehen Tools für Windows, Linux und Mac Clients zur Verfügung, die auch parallel auf unterschiedlichen Maschinen genutzt werden können. Die Daten werden mit einer 256 bit AES Verschlüsselung geschützt. Weitere Funktionen sind erweiterte Kompressionsmechanismen und die Möglichkeit der Deduplication.

Preise

  • 5 USD pro Server pro Monat + Gebühren von Amazon S3 (siehe unten)


Personal

Die Angebote aus dem Bereich Personal setzen sich aus dem Simply Backup und der Desktop Edition zusammen. Bei dem Simply Backup handelt es sich lediglich um die Möglichkeit automatisierter Backups, wobei die Desktop Edition Elemente der Workgroup Edition beinhaltet.

Simply Backup

Mit Simply Backup können die Daten auf einem Rechner zeitgesteuert und automatisiert auf Amazon S3 oder Rackspace gesichert und im Fehlerfall z.B. von der letzten Nacht oder der letzten Woche wiederhergestellt werden. Clients sind für Windows und Mac OS vorhanden. Die Daten werden mit einer 256 bit AES Verschlüsselung geschützt.

Preise

  • 2 USD pro Monat + Gebühren von Amazon S3 (siehe unten)

Desktop Edition

Die Desktop Edition beinhaltet alle Funktionen des Simply Backup und bietet darüber hinaus die Möglichkeit die JungleDisk wie eine lokale Festplatte (als Netzlaufwerk) auf dem Computer einzubinden. Somit kann direkt von und auf diesem Netzlaufwerk gearbeitet werden. Weiterhin können ausgewählte Ordner mit der JungleDisk synchronisiert werden. Damit hat man die Möglichkeit seine Daten über mehrere Rechner hinweg zu synchronisieren, da sich die Daten zentral in der JungleDisk befinden und mit dem lokalen Rechner abgeglichen werden. Somit stehen auf jedem Rechner und an jedem Ort (vorausgesetzt eine Internetverbindung ist vorhanden) immer die aktuellen Daten zur Verfügung. Der Zugriff auf die Daten kann aber auch dann erfolgen, wenn gerade keine Internetverbindung vorhanden ist, da die Daten ebenfalls lokal gespeichert werden. Ist die Internerverbindung wieder vorhanden, werden automatische alle Änderungen mit der Cloud synchronisiert. Der Zugriff auf die Daten kann ebenfalls über eine Weboberfläche oder ein iPhone erfolgen. Es stehen Clients für Windows, Mac OS und Linux zur Verfügung. Die Daten werden mit einer 256 bit AES Verschlüsselung geschützt.

Preise

  • 3 USD pro Monat + Gebühren von Amazon S3 (siehe unten)


Screenshots

Konfigurationsmenü

Auswählen der Dateien für das Backup

Backupvorgang

Activity Monitor

Wiederherstellen von Dateien

Verbindung zu einem Server herstellen


Amazon S3 Gebühren


Quelle



Peecho's Printcloud – Printing as a Service

Mit der Printcloud bietet das Unternehmen Peecho aus den Niederlanden einen Cloud Service, mit der ein einheitlicher Zugang zu allen Druckumgebungen auf der ganzen Welt ermöglicht wird. Es reicht dafür aus, lediglich eine eigene Benutzerschnittstelle zu erstellen. Der Rest wird von der Printcloud auf Basis von pay-per-use und ohne eine erforderliche Menge abgewickelt. Der gesamte Prozess vom Auftragseingang über die Verarbeitung bis hin zur Produktion und dem Versand von personalisierten Produkten wird von der Printcloud übernommen.

Was bietet die Printcloud?

  • Grafik-Design
    Vollständige Unterstützung von Adobe Indesign IDML. Weltweit kann jeder Graphikdesigner für ein Unternehmen, dass die Printcloud nutzt, Produkte entwerfen.
  • Einfache Konnektivität
    Mit Hilfe der REST API kann sich jede Anwendung (z.B. eine Webseite, eine mobile Anwendung, eine Desktop Anwendung oder ein Gadget eines Sozialen Netzwerks) mit der Printcloud verbinden.
  • Software
    Programme stehen für das iPhone und Adobe Flex zur Verfügung.
  • Skalierbarkeit
    Auf Grund von Cloud Computing Technologien können die Kapazitäten in wenigen Minuten erhöht werden, wodurch kein Engpass entsteht.
  • Weltweite Produktion
    Auf Basis von Druckstandards wie JDF und JMT kommuniziert die Printcloud mit einem weltweiten Netzwerk von Druckumgebungen, um das endgültig gedruckte Produkt so nah wie möglich am Ziel der Auslieferung zu produzieren und dadurch die Versandkosten zu minimieren.
  • Faire Abbrechung
    Es müssen keine langfristigen Verträge eingegangen werden was ebenfalls bedeutet, dass Terminierungsentgelte, Vorab-Investitionen oder Einrichtungskosten entstehen. Die Abbrechnung erfolgt vollständig auf einer pay per use Basis. Es wird also tatsächlich nur das bezahlt, was genutzt wird.

Funktionen

  • Produktkatalog
    Es steht ein Produktkatalog für Anwendungen/ Produkte von Kunden bereit, die schnell erstellt werden können.
  • Produktvorlagen
    Schnelle Erstellung von Produktvorlagen durch die Nutzung von Adobe InDesign IDML.
  • Einkaufswagen
    Es können mehrere Produkte in einer Bestellung zusammengefasst werden.
  • Abbrechnung
    Die Rechnungsstellung an die Endkunden kann von der Printcloud ebenfalls übernommen werden.
  • Gutschein-Codes
    Für werden mobile Zahlungen oder Marketing-Kampagnen können Gutschein-Codes erstellt werden.
  • Status-Updates
    Der Status des gesamten Prozessverlaufs kann zu jederzeit mittels einer eigens entwickelten Anwendung oder via der Webseite der Printcloud dem Endkunden angezeigt werden.

  • REST API
    Zur Kommunikation steht eine REST API zur Verfügung.
  • iPhone
    Hilfe bei der Entwicklung einer iPhone Anwendung für eigene Produkte mittels der Printcloud Open Source iPhone Anwendung.
  • Adobe Flex
    Vollständige Unterstützung von Adobe Flex.
  • Skalierbarkeit
    Hohe Skalierbarkeit und Verfügbarkeit durch Cloud Computing Technologien.
  • Weltweite Produktion
    Mit der Printcloud kann jede Druckumgebung auf der ganzen Welt angesprochen werden.

Technik

Die Printcloud Plattform basiert vollständig auf der Architektur der Amazon Web Service.

  • Simple Storage Service
    Alle Daten werden in Amazons Cloudspeicher Simple Storage Service (S3), wodurch eine unbegrenzte Menge an Daten verwaltet und gespeichert werden kann und von überall aus verfügbar ist.
  • Elastic Compute Cloud
    Das Versprechen der Skalierbarkeit realisiert die Printcloud durch den Einsatz von Amazons Elastic Compute Cloud (EC2), mit der je nach Bedarf die Systeme erweitert oder verkleinert werden können und damit saisonale Lastspitzen abgefangen werden können.
  • Simple Queue Service
    Mit dem Amazon Simple Queue Service (SQS) werden die einzelnen Prozesse der Printcloud separiert, wodurch kein neuer Auftrag den gesamten Prozess stören kann.
  • Relational Database Service
    Mit dem Relational Database Service (RDS) steht der Printcloud eine skalierbare Datenbank in der Cloud zur Verfügung.
  • Cloudfront
    Mit Amazon CloudFront werden die benötigten Daten eines Druckauftrags der am nächsten gelegenen Druckumgebung des Auslieferungsorts bereitgestellt.

Für Druckereien

Die Printcloud stellt Anwendungen von Drittanbietern (Händlern) eine REST API für die Kommunikation bereit. Der gesamte Prozess vom Auftragseingang über die Verarbeitung bis hin zur Produktion und dem Versand von personalisierten Produkten wird von der Printcloud für den Händler übernommen.

Aus der Sicht einer Druckerei arbeitet Peecho als eine Art Broker für die eigenen Produkte. Dazu steht ein einziger Einstiegspunkt zur Verfügung, wodurch Peecho's Partner ihren Kunden jegliche Art von Produkt anbieten können. Diese Produkte können in verschiedenen Produktionsstätten auf der ganzen Welt hergestellt werden.

Die Infrastruktur basiert vollständig auf den Amazon Web Services, wobei Technologien wie Elastic Load Balancing und Auto-Scaling genutzt werden, um innerhalb von wenigen Minuten die Skalierung der Systeme vorzunehmen.

Der (Kommunikations)-Prozess zwischen einem Partner und der Printcloud funktioniert wie folgt:

Die Ausgabe der Printcloud für 2D Drucker basiert auf den folgenden Elementen:

  • Job Ticket in JMF (Job Messaging Format) und JDF (Job Definition Format).
  • Produktbeschreibung als Adobe Indesign IDML (InDesign Markup Language).

Die Bestellungen werden dabei nicht direkt zu den Druckereien geschickt, um diese nicht zu überlasten. Vielmehr basiert der gesamte Vorgang auf dem Pull Mechanismus, wodurch die Druckereien die Möglichkeiten haben, die Arbeitslast selber zu bestimmen und können die Aufträge in ihren Produktionsfluss integrieren.

  • Erster Schritt: Ein Jobticket beziehen
    Jeder Job wird einer Druckerei in einer eigenen Amazon SQS Job Ticket Queue abgelegt. Diese können z.B. mittels SOAP abgefragt werden. Das Job Ticket basiert auf einer kleinen XML Datei, in der ein Zeiger auf die Produktionsdatei und die Produkbeschreibung zeigt. Mit der JDF Datei kann die Druckerei entscheiden, wann und wie das Produkt gedruckt werden soll.

    Ist das Ticket von der Druckerei heruntergeladen worden, wird der Status des Tickets auf "Queue" gesetzt, was gleichermaßen bedeutet, dass der Auftrag in Produktion ist.

  • Zweiter Schritt: Das Produkt erhalten
    Jedes Job Ticket zeigt zusätzlich auf einer Produktdatei, die in Amazon S3 gespeichert ist. Auf diesen Service kann mit SOAP oder REST mittels eines Schlüssels oder direkt mit einer URL zugegriffen werden. Abhängig von der Job Beschreibung kann die Druckerei die Produktdatei herunterladen, wenn sie bereit sind zu produzieren.
  • Dritter Schritt: Produzieren, Versenden und auf "versendet" setzen
    Jetzt kann die Druckerei die IDML Datei in ein für sie passendes Format übersetzen, wie z.B. PDF oder PPML. Die Druckerei produziert das Produkt und versendet es an die Empfänger. Anschließend wird der Status des Job Tickets auf "versendet" gesetzt.

    Für die ersten Schritte wird eine Open Source Beispielanwendung bereitgestellt, die Job Tickets und Produkt Dateien aus der Printcloud in einen bestimmten Ordner herunterlädt.

Quelle

  • PRINTCLOUD by Peecho




CloudLinux

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

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

Hintergrund

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

Vorteile für Shared Hosting Anbieter

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

Vorteile für Rechenzentren

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

Lightweight Virtual Environments (LVE)

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

Vergleich: Standard OS vs. CloudLinux

Standard OS

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

CloudLinux

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

Vergleich: Open Source Anbieter vs. CloudLinux

Quelle