ITBlog

Für unsere OpenStack DevCloud benötigten wir Images für OpenStack die mit cloudbase-init starten. Dazu gibt es bei Cloudbase ein GIT repository das die nötigen (Powershell) Scripte bereitstellt. https://github.com/cloudbase/windows-openstack-imaging-tools Als ich dies jedoch auf einem Windows 2012 R2 Server nach Anleitung ausführen wollte was das resultierende Image nicht startfähig. Es gab Warnungen dass DSIM nicht aktuell genug ist und anscheinend wurden auch die VirtIO Treiber nicht integriert. Hier sind ein paar Schritte mit denen es dann geklappt hat: a) Git4Windows installieren. b) ein Arbeitsverzeichnis anlegen und die Image Tools dorthin auschecken:

    mkdir c:\work
    cd /d c:\work
    git clone https://github.com/cloudbase/windows-openstack-imaging-tools.git

c) Aus einer Windows Server 2016 Installations-ISO das File sources\install.wim (5,6GB) extrahieren und nach c:\work\source\install.wim legen. (Ich habe dies mit einer Volume License ISO als auch dem 180 Tage Eval ISO erfolgreich gemacht) d) Für Windows Server 2016 muss man eine DSIM Version verwenden die neuer ist. Dazu habe ich das Windows ADK für Windows 10, Version 1703 (Hardware Dev Center) auf dem Server installiert. Es gibt zwar auf der Webseite an dass dies nur für Windows 10 ist, jedoch war es in meinem Fall auch für Windows Server 2016 (Rollup CDs) notwendig. e) nach der Installation ist es Wichtig das DSIM Verzeichnis dieses neuen Kits im Pfad vor dem Windows Systemverzeichnis zu haben (da dort eine alte DSIM Version gefunden wird). Man kann `(Get-Command dism.exe).Path` verwenden um zu sehen welches DISM verwendet wird. Ich habe es mir einfach gemacht und in das verwendete Powershell script einfach einen passenden Pfad gesetzt. f) Im Beispielscript werden die RedHat VirtIO Treiber heruntergeladen, ich hatte die URL auf eine neue Version angepasst. g) Das Offline Beispielscript habe ich angepasst dass es alle Verzeichnisse unter c:\work sucht, dass es nur ein 15GB Image anlegt (und weil dieses noch transportiert und gestartet werden muss habe ich es auch als QCow2 angelegt. Hier das komplette script (auszuführen als privelegierter lokaler admin im Unterverzeichnis example): "Windows Server 2016 Images mittels DSIM für OpenStack vorbereiten" vollständig lesen

At $EMPLOYER we are developing and offering (Java based) COTS Enterprise Software to a wide range of customers. And while it looks like customer demand seem to concentrate on the various Linux enterprise distributions as well as Windows Server, there are of course still customers with different strategic platforms for Mission Critical applications. This includes AIX, HP-UX and Solaris which we all officially support. For a specialized ISV it is hard to have test systems for all those platforms combinations and keep up with the latest patches and Java versions. This is especially true if you do not want to maintain a whole datacenter full of test equipment. Luckily most of the system vendors offer some sort of partner program and provide opportunities to test. HP AllianceONE Partner Program Today I want to blog about the HP offering called Cloud Operating Environment (CLOE). As an HP AllianceOne Partner Program member we have access to this offering and can order virtualized HP-UX machines on a self-service portal for the purpose of porting, integrating and troubleshooting customer problems. The standard machines offered are OK for installation and compatibility testing or creating documentation for it. Simulating larger environments and doing load-tests requires different agreements. When ordering a new "Project" you have to give some details about the work you are planning to do (but I had actually never denied any request). Most of the work is related in trying out installer, shell scripts as well as Java dependencies. Remote Shell Access After ordering a Server (for example the medium configuration of HP-UX 11i v3 Data Center OE with 2 CPUs, 4GB RAM and 2 x 36GB HDD). After the server is provisioned (which takes about 12 minutes), you will receive an e-mail with the SSH key for root user. This SSH keyfile can be converted into a PuTTY .ppk file with the use of the PuttyGen Tool. The SSH access is the only open incoming network connection, so you need the SSH port forwarding feature available in PuTTY if you want to access or provide remote services. The login is a bit slow, I discovered, that it helps to put the option UseDNS no in /opt/ssh/etc/sshd_config to speed up the SSH login process. Otherwise you need to increase login timeout limits of some SFTP tools. Installing Open Source Software On the first startup the system is pretty basic, there are only some Open Source goodies installed in /usr/contrib. But it is missing for example a modern shell. We can fix this with the help of the HP-UX Porting and Archive Centre:

# cd /var/tmp
# /usr/bin/ftp hpux.connect.org.uk
Name: ftp
Password: root@ 
ftp> cd /hpux/Sysadmin/depothelper-2.00/ 
ftp> get depothelper-2.00-ia64-11.31.depot.gz
ftp> quit
# /usr/contrib/bin/gunzip depothelper-2.00-ia64-11.31.depot.gz
# /usr/sbin/swinstall -s /var/tmp/depothelper-2.00-ia64-11.31.depot depothelper
... 
# /usr/local/bin/depothelper curl bash
# /usr/local/bin/bash
Bash-4.2$

Using remote X11 If you need to run applications with a graphical user interface, you need a way to display X11 sessions. There are basically two options. The first is, you install locally (on your PC) a X Window server (like Xming) and then set the X11 DISPLAY variable to a port which is forwarded by SSH back to your desktop. This requires no additional software on HP-UX side, but is not very fast. Another problem is, that if you lose the SSH connection all GUI applications on the remote side will be terminated. So the better option is to use a X11 simulating server on the HP side and connect to it. This allows to re-attach the session. Xvnc is a X11 server which can do that. It runs on the HP server talking X11 protocol to the local clients and publishes the frame buffer via VNC protocol. On the PC you only need a VNC client and connect (via a SSH port tunnel) to the remote. Unfortunately HP offers no Xvnc out of the box. But you can buy a version from RealVNC. There is also an older 4.1.2 PARISC binary floating around on the Internet which does not require a commercial license and works fine in the Aeries emulator:

# cd /var/tmp
# export PATH=$PATH:/usr/local/bin
# curl -o vnc-4_1_2-parisc_hpux.depot.gz http://www.grossmatten.ch/share-freeware/Network/VNC/4.1/vnc-4_1_2-parisc_hpux.depot.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1767k  100 1767k    0     0   158k      0  0:00:11  0:00:11 --:--:--  182k
# /usr/contrib/bin/gunzip vnc-4_1_2-parisc_hpux.depot.gz
# /usr/sbin/swinstall -s /var/tmp/vnc-4_1_2-parisc_hpux.depot VNC
...
# vncpasswd
Password: 
Verify:
# vncserver
xauth:  creating new authority file //.Xauthority

New 'aps39-92:1 (root)' desktop is aps39-92:1

Creating default startup script //.vnc/xstartup
Starting applications specified in //.vnc/xstartup
Log file is //.vnc/aps39-92:1.log

After this you need to forward port 5901 in PuTTY to localhost:5901 on remote, and can connect with a VNC Viewer on your Desktop. Expanding Filesystem Capacity The next task is, that the default filesystems are sized too small to install additional software, so you need to get access to the additional capacity. As I am not a HP-UX expert and I could not find a good tutorial on that, here is my attempt to mount the second disk and to increase the /var filesystem with the remaining LVM extends (I did not setup a LVM for the second disk to keep the two devices independent for better snapshotting):

# bdf
Filesystem          kbytes    used   avail %used Mounted on
/dev/vg00/lvol3    1048576  176080  865720   17% /
/dev/vg00/lvol1    1835008  167008 1655064    9% /stand
/dev/vg00/lvol8    4718592  899128 3794848   19% /var
/dev/vg00/lvol7    5472256 3340744 2114872   61% /usr
/dev/vg00/lvol4     524288   21200  499160    4% /tmp
/dev/vg00/lvol6    8708096 5689992 2994560   66% /opt
/dev/vg00/lvol5     106496    5792   99928    5% /home

# for i in /dev/disk/*; do diskowner -AF $i; done | grep -v ioerror
path=/dev/disk/disk4:owner=partition.vxfs
path=/dev/disk/disk4_p1:owner=vxfs
path=/dev/disk/disk4_p2:owner=lvm.vxfs
path=/dev/disk/disk4_p3:owner=vxfs
path=/dev/disk/disk5:owner=vxfs

# vgdisplay -v
…
--- Physical volumes ---
   PV Name                     /dev/disk/disk4_p2
   PV Status                   available
   Total PE                    4495
   Free PE                     1247
   Autoswitch                  On
   Proactive Polling           On

# lvdisplay /dev/vg00/lvol8
--- Logical volumes ---
LV Name                     /dev/vg00/lvol8
…
LV Size (Mbytes)            4608
Current LE                  576
Allocated PE                576
 
# lvextend -l $[576+1247] /dev/vg00/lvol8
Logical volume "/dev/vg00/lvol8" has been successfully extended.
 
# lvdisplay /dev/vg00/lvol8
...
LV Size (Mbytes)            14584
 
# fsadm -b 14584m /var
fsadm: /etc/default/fs is used for determining the file system type
vxfs fsadm: V-3-23585: /dev/vg00/rlvol8 is currently 4718592 sectors - size will be increased
 
# mkfs -F vxfs /dev/disk/disk5
    version 6 layout
    37748736 sectors, 37748736 blocks of size 1024, log size 16384 blocks
    largefiles supported

# mkdir /u01
# echo "/dev/disk/disk5 /u01 vxfs delaylog 0 3" >> /etc/fstab
# mount /u01

# bdf
Filesystem               kbytes      used        avail      %used Mounted on
/dev/vg00/lvol3    1048576    176080     865720   17% /
/dev/vg00/lvol1    1835008    167008   1655064    9% /stand
/dev/vg00/lvol8    14934016  899496 13930104    6% /var
/dev/vg00/lvol7    5472256    3340744 2114872   61% /usr
/dev/vg00/lvol4     524288      21200       499160    4% /tmp
/dev/vg00/lvol6    8708096    5689992 2994560   66% /opt
/dev/vg00/lvol5     106496      5792           99928    5% /home
/dev/disk/disk5    37748736  26333   35364760    0% /u01

The fsadm command to online-resize the filesystem is only available in the Data Center OE, the Base Operating Environment has not the required license option "Online JFS" activated In the next article I will have a look at installing patches and Quality Packs. Update 2012-05-13: How to get Started presentation from HP: http://h20195.www2.hp.com/V2/GetDocument.aspx?docname=c03201145. My Blog article is featured by @HPAllianceOne on Twitter.

Wie ich bereits berichtet hatte kann es für einen Anwender der IaaS Cloud Amazon EC2 Sinn ergeben den Simple Email Service (SES) von Amazon zu verwenden um E-Mails zu versenden. Dabei kann man entweder die Amazon API/Tools verwenden, oder inzwischen auch die Mails per smtps an den Amazon Smarthost liefern. Amazon selbst bietet nur einen SMTP-SSL Server auf Port 465 an. Die meisten MTAs können dieses Protokoll nicht mehr sprechen und ziehen STARTTLS vor, deswegen empfiehlt Amazon in seiner Anleitung die Verwendung von stunnel als zwischengeschaltenen Proxy. Diese Indirektion ist aber unschön, und kann mit einer aktuellen Exim Version vermieden werden. Ab der Version 4.77 unterstützt der SMTP Transport von Exim auch das smtps Protokoll (für ausgehende Verbindungen). Mit folgenden Exim Einstellungen (Auszug) kann also ein EC2 Linux Rechner direkt an den Amazon Dienst die E-Mail ausliefern (wichtig: die Envelop-From und From: Addresse der versendeten Mails müssen in der Liste der verifizierten SES Absender sein. Als Empfänger kommen nur dann beliebige E-Mail Addressen in Frage, wenn man diese Funktion bei Amazon explizit freischalten hat lassen. 1. Alle Mails an dem Amazon Server leiten (dnslookup entfernen):

smarthost:
  driver = manualroute
  domains = ! +local_domains
  transport = remote_smtps
  route_data = email-smtp.us-east-1.amazonaws.com
  no_more

2. Einen neuen SMTP/SSL Transport definieren:

remote_smtps:
  driver = smtp
  protocol = smtps
  #port = 465
  hosts_require_auth = *
  hosts_require_tls = *

3. Zusätzlich einen Authenticator mit dem SES User/Passwort definieren:

client_login:
  driver = plaintext
  public_name = LOGIN
  client_send = : xxxxI6CIH2YIWSNxxxxx : Agcq00AEvA2ZDiQHNrDvTEODE3FWa1rxxxxx

Ich habe das ganze unter Amazon Linux mit Exim 4.77 aus dem AltCent Repository getestet:

wget http://centos.alt.ru/repository/centos/6/i386/exim-4.77-1.el6.i686.rpm
rpm -i exim-4.77-1.el6.i686.rpm

Es bietet sich an Exim so zu konfigurieren, dass nur auf localhost auf dem Submission Port E-Mails angenommen werden:

daemon_smtp_ports = 587
local_interfaces = 127.0.0.1

Dies stellt sicher, dass der Dienst nicht für Spam oder Sicherheitsangriffe ausgenutzt werden kann.

Die Bundesnetzagentur hat ein Eckpunktepapier zum Thema Smart Grids und Markets veröffentlicht. Damit will die Bundesbehörde

durch dieses Papier eine intensivere Diskussion der Thematik anstoßen zu können und die Veränderungen des Energieversorgungssystems weiter voran zu bringen. Dieses Eckpunktepapier soll die Diskussion zu dieser Thematik weiter befördern und besser strukturieren.

Das "Eckpunktepapier der Bundesnetzagentur zu den Aspekten des sich verändernden Energieversorgungssystems" enthält Leitgedanken und Begriffsdefinitionen und ist schon aus diesem Grund sehr lesenswert. Ob die einzelnen Thesen (Abnahme des Gesamtenergieverbrauchs) nun zutreffen wird sich zeigen, von einer Zunahme der Stromabnahme wird aber ausgegangen. Auch bei intelligenteren Verbrauchern (da zunehmend andere Energieformen verdrängt werden, was angesichts der Endlichkeit von fossilen Energieträgern nur logisch ist). Das Paper baut darauf, dass Verbraucher sich über Marktsignale (Preise) steuern lassen. Das wird sich zeigen wie gut das funktioniert... Ein wenig sehr optimistisch dürfte die Annahme der Transaktionskostensenkung bei "kleinteiliger Interaktion" sein (Fehlschläge im Smartmeter Markt wie in den Niederlanden oder Großbritannien deuten ja eher darauf hin, dass es sinnvoll sein kann alternative Lösungswege anzustreben und nicht alles über Informationstechnologie lösen zu wollen. Größtenteils wird der Smartmetermarkt von Anbietern getrieben die sich neue Einnahmequellen versprechen und die Vorteile werden in den meisten Haushalten weder gesehen - noch existieren diese). Das BNetzA Papier sieht dies aber auch (Leitgedanke 4). Was mir persönlich im Papier fehlt ist ein klarere Fokus auf das Thema Datenschutz, Schutz von kritischen Infrastrukturen und Monokultur. Die Notwendigkeit von Datendrehscheiben wird nicht hinterfragt, und eine Vermischung der Messdaten von Prosumenten oder Industrieabnehmern mit den Messstellen in Haushalten führt meiner Meinung nach zu einer Übertechnisierung der Haushalte. Für eine zuverlässige Demand-Site Prognose ist meiner Meinung nach nicht notwendig den Tagesverlauf jedes einzelnen Haushaltes zu betrachten - ganz im Gegenteil das ist eher schädlich. Der Nutzen von mehr Transparenz beim Stromverbrauch eines einzelnen Haushaltes kann auch durch eine rein lokale Informationsanwendung (deutlich besser) gelöst werden. Eine feingranulare Übermittlung von Messwerten erscheint mir nicht zwingend notwendig und vor allem nicht Ökonomisch. In dem Zusammenhang verweise ich auch auf den Artikel in der aktuellen Datenschleuder #95 (Power to the People, Das Stromnetz der Zukunft, Mathias Dalheimer, Seite 35-48) und die Projekte mySmartGrid sowie volkszaehler.org.

Wer ein Smartphone mit sich rumschleppt wird schon auf die Idee gekommen sein einen Web Kalender wie z.B. Google Calendar zu synchronisieren, um immer alle Termine im Blick zu haben. In meinem Fall habe ich einen Google Calendar Account in dem ich einige andere Kalender zusammenfasse, dieser wird dann per CalDAV auf dem iPhone eingebunden. So sehe ich zum Beispiel die Karlsruher IT Termine, die Familientermine und die Termine der Karlsruher Piraten.

Was mir bisher noch gefehlt hat, waren meine Facebook Events, da hier immer auch mal wieder eine Einladung dabei ist, der ich zwar bei Facebook zusage, diese dann aber nicht in einen der Google Calender übernehme. Es gibt hier aber eine einfache Möglichkeit, man kann die Events in Facebook als webcal/ical Feed exportieren. Diese URL kann man dann in Google als neuen Kalender von einer URL importieren.

Das hat aber leider das Problem, dass Google bei einigen Einträgen kein Titel oder Beschreibung anzeigt. Das ist ein bekanntes Problem, und es gibt im Web auch Anleitungen wie man das beheben kann. Bei mir hat das auch geklappt (allerdings musste ich nicht CLASS:CONFIDENTIAL in CLASS:PUBLIC ändern, sondern bei mir waren es CLASS:PRIVATE Einträge die Facebook produziert hat: <?php $ical="http://www.facebook.com/ical/u.php?uid=XXX&key=XXX"; $file=file_get_contents($ical); $replace="CLASS:PUBLIC"; $output=str_replace("CLASS:CONFIDENTIAL",$replace,$file); $output=str_replace("CLASS:PRIVATE",$replace,$output); header("Content-Type: text/Calendar"); // Give the file a name and force download header("Content-Disposition: inline; filename=events.ics"); print_r($output); ?> Diese Lösung setzt allerdings voraus, dass man irgendwo ein PHP Script ablegen kann. Damit muss man jetzt nur die Export-URL von Facebook in dem PHP Script hinterlegen ("webcal:" in "http:" ändern), und in Google die PHP URL als Kalender importieren. Dabei ist zu beachten, dass jeder der das Script kennt und aufrufen kann so an alle Facebook Termine rankommt (auch die privaten).

Wer das mit dem eigenen PHP Script nicht machen will, der kann auch Yahoo! Pipes verwenden. Das ist ein Dienst bei den man eine Verarbeitungspipeline für Feeds zusammenstellen kann. Im Falle von ICS Dateien reicht es bei Yahoo aus diese nur als Source zu definieren, und dann direkt wieder zurückzugeben, denn die Yahoo Quelle für Feeds (die ICS versteht) filtert automatisch die CLASS Attribute ganz raus.

Bei Yahoo Pipes muss man immer etwas tricksen wenn man einzelne Komponenten verbinden möchte (auf den Typ achten), deswegen hat die von mir verwendete Pipe noch den Zwischenschritt mit dem URL-Builder. Die URL selbst ist in einem "Private String" abgelegt, damit niemand der die Sourcen sehen kann an meine Facebook Events herankommt. (Leider lässt sich aber die Pipe trotzdem nicht sinnvoll Sharen, aber ich denke mit dem Screenshot könnt Ihr Euch leicht eine eigene zusammenbauen). Beim Aufruf der Pipe ist es wichtig den Parameter "_render=ical" mitzugeben. Früher gab es hierfür wohl einen Menueintrag bei Yahoo, der scheint aber entfernt worden zu sein. Auch hier gilt, wer die Addresse Eurer Pipe kennt, kann Eure Facebook Terminzusagen lesen.

Amazon EC2 ist ein IaaS Anbieter bei dem man eigene virtuelle Systeme starten kann. Diese Systeme können dann alle Systemfunktionen die eine Anwendung benötigt bereitstellen. Dazu gehört zum Beispiel auch der E-Mail Versand (z.B. root Mails oder eben E-Mails der Anwendung wie z.B. Passwort Reminder oder Notifications). Um sicherzustellen, dass die E-Mails die von einem Amazon EC2 System abgeschickt werden auch ankommen, und nicht in Spam Filter der Provider hängenbleiben sind folgende Punkte zu beachten: a) wenn man einen Mailserver (MTA) verwendet der die Mails versendet so sollte dieser natürlich sicher konfiguriert sein, und kein Relaying von E-Mails zulassen - da sonst der EC2 Server zur Spamschleuder wird (was nicht nur Ärger mit Amazon nach sich zieht). b) Der SMTP Server meldet sich mit einem Rechnername. Dort sollte er nicht den internen Amazon EC2 Namen verwenden der dem Rechner zugewiesen wird, denn dir dort verwendete .internal Domain wird von vielen E-Mail Empfängern als ungültig abgelehnt. c) Die E-Mail Adresse des SMTP Servers (also in dem Fall der virtuelle EC2 Host) sollte in einen gültigen Hostnamen aufgelöst werden, denn sonst springt der Spamschutz der Empfänger an. Dies ist bei Amazon nur sinnvoll machbar wenn man eine Elastic IP verwendet. Dieses Verfahren wird PTR oder auch "reverse DNS" checks genannt. d) Der Envelop-From (im Falle von Cron Mails z. B. root@host) der versendeten E-Mails sollte eine gültige E-Mail Adresse sein. Insbesondere prüfen E-Mail Server beim Empfang, ob die Domain existiert. Hier sollte also auch nicht der .internal Hostname von AWS verwendet werden. e) Die Domain einer Absender E-Mail Adresse sollten nicht nur gültig sein, sondern mit dem SPF Mechanismus (Sender Policy Framework) kann der Betreiber der Domain auch angeben von welchen Rechnern legalerweise Mails mit dem Absender versendet werden. Einige Empfänger benutzen das, um das Spamaufkommen zu reduzieren. In der Regel kommt in der Liste der zugelassenen Server nur die MX Server der Domain vor, und eben nicht beliebige IP-Adressen aus den Amazon AWS Netzen. Es bietet sich auch nicht an das komplette EC2 Netz in die Liste aufzunehmen, da sonst alle Amazon Kunden wiederum E-Mails am SPF Filter vorbei versenden können (das ist zwar weniger ein Problem aber eben unschön). Aus diesen Punkten ergeben sich zwar einige Konfigurationen die man vornehmen kann um von einem EC2 Host direkt an Endempfänger Mails zu versenden. Die Wahrscheinlichkeit dass diese aber häufig als Spam erkannt werden ist groß. Deshalb ist es anzuraten, dass ein Smarthost verwendet wird. (Das hat auch administrative Vorteile wenn die EC2 Hosts Ihre Mails schnell loswerden und man nicht mehrere Mailwarteschlangen überwachen muss). Um kein eigenes Relay betreiben zu müssen bietet es sich z.B. an den Simple E-Mail Service (SES) von Amazon zu verwenden. Dann muss man nur die SES E-Mail Server von Amazon AWS zusätzlich in die SPF Liste der Absenderdomain aufnehmen. Dies ist hier beschrieben: http://docs.amazonwebservices.com/ses/latest/DeveloperGuide/SPF.html. Im Gegensatz zum kompletten IP-Subnetz von Amazon EC2 hat man bei dieser Vorgehensweise den Vorteil, dass Amazon ein hohes Interesse daran hat, dass nur autorisierte Benutzer die Absenderadresse verwenden. (Gleiches gilt übrigens auch für Google App Engine, hier kann man auch Mail Relays in die SPF Liste aufnehmen). Zudem kann man sich danke Amazon IAM ein Benutzername/Passwort erzeugen der außer dem E-Mail Versand keine weiteren Rechte hat. Dieser kann man dann bedenkenlos im EC2 Image hinterlegen - zumindest solange man dieses nicht mit anderen Amazon Anwendern teilt. Sonst bietet es sich eher an diese Credentials beim Start mit anzugeben. Im nächsten Post beschreibe ich, wie man bei einem AMI auf Basis von Amazon Linux diese Varianten realisieren kann.

Mit dem neuen (Beta) Dienst Beanstalk steigt Amazon in das Platform-as-a-Service Geschäft ein. Vergleichbar mit dem Google AppEngine for Java Dienst können Java Entwickler einfach Web Anwendungen in WAR Files verpacken und in die Cloud hochladen. Amazon kümmert sich um die Skalierung aller Komponenten. Man könnte fast annehmen ursprünglich war das WAR Deployment Modell genau so gedacht. Amazon rechnet die unterliegenden Infrastrukturdienste ab. Das ergibt sich aus den Freiheitsgraden die man hat, macht die Rechnung aber komplex - und vor allem für Low-Traffic Anwendungen eventuell nicht gerade preiswert. Die Amazon Beispielrechnung kommt z.B. auf $30/Month. Immerhin können die sehr günstigen EC2 Micro Instanzen ($0.02/h) genutzt werden.

Amazon's Utility Computing Platform EC2 zeichnet sich durch eine einfache Skalierbarkeit aus. Für Anwender die allerdings nicht kurzfristig mehrere hundert Compute Instanzen benötigen war das Pricing nicht so attraktiv. Amazon hat nun Reserved Instances angekündigt. Kann man sich auf eine gleichmäßige Nutzung einer Instanz committen, so sinken die Nutzungspreise erheblich. Ich habe das mal (bei einer Monatsnutzng von 30*24h) hochgerechnet:

Instanz	Stundenpreis	Norm Monat	Monat 1y	Monat 3y
Small	$0,10/$0,05	$72	$48,68	$35,49
XL	$0,80/$0,24	$576	$390	$284

Das Modell scheint bisher noch nicht für die Windows Server verfügbar zu sein. Details unter EC2 Pricing. Was ich bei Amazon immer wieder gut finde ist es wie durch einfache Bezahlmodelle Anreize für ein bestimmtes Userverhalten geschaffen wird, und dies dank der Anzahl der Benutzer skaliert. Z.b. die Möglichkeit IP Addressen zu reservieren, und solange man diese nutzt sind sie kostenlos. So langsam kommt Amazon mit diesem Pricing in die Regionen von normalen V-Servern (mit dem zusätzlichen Benefit dass man jederzeit mehr Ressourcen auf Stundenbasis dazuschalten kann). Ganz konkurenzfähig sind die Server allerdings immer noch nicht - trotz Dollar Kurs.

Schon bisher haben Firmen die Amazon S3 Storage Cloud für die Auslieferung von Bildern und Downloads genutzt. Allerdings hatte S3 im vergleich zu den anderen kommerziellen Content Delivery/Distribution Networks einen Performance Nachteil: wenn man ein CDN in die Web Site einbindet, so erhofft man sich Performance Vorteile insbesondere im Bereich Latenz. Das bedingt Caches die in die Nähe der User repliziert werden. Amazon hat reagiert, mit der Public Beta zu Cloudfront kann man jetzt eine solche automatische Replikation und globales (DNS) load balancing aktivieren. Preise bewegen sich zwischen 17 und 22 USD cent je GB (je nach Abrufort). Dazu kommen noch 1,2-1,3 cent pro 10.000 GET Requests und die normalen S3 Gebühren für Storage und der Replikation des Content zu den Caches. Dieses einfach Preismodell könnte den Anbietern wie Akamai ziemlich nahe gehen - zumindest solange es um statischen Content geht. Die folgenden 14 Standorte bietet Amazon für die Verteilung an: United States (Ashburn, VA; Dallas/Fort Worth, TX; Los Angeles, CA; Miami, FL; Newark, NJ; Palo Alto, CA; Seattle, WA; St. Louis, MO); Europe (Amsterdam; Dublin; Frankfurt; London), Asia (Hong Kong; Tokyo). Bekannte Einschränkungen (laut RightScale blog): kein HTTPS, keine detaillierten Usage Reports, kein Streaming, nur Public S3 Content und kein Fine-Tuning der Caches möglich. Zum Weiterlesen
Werner Vogels' Ankündigung (Amazon CTO).
Jeff Barr's Ankündgung auf dem AWS Blog

Amazon wurde gefeiert als sie SLAs für Ihre Cloud Offerings angeboten haben. Das bezieht sich insbesondere auf die Amazon Web Services Dienste S3 (Storage Cloud), EC2 (Compute Cloud), ECB (Elastic Block Storage) und die Host Lösungen für Queueing (SQS) und Datenbank (SimpleDB). Betrachtet man sich allerdings die SLAs, so muss man sagen diese sind ziemlich nutzlos in einem kommerziellen Umfeld (um traditionalle Bedenken zu zerstreuen): Die neuen EC2 SLA definieren, dass ein Kunde 10% der Gebühren für die letzten 365 Tage zurückerstattet bekommt, wenn die Verfügbarkeit unter 99.5% fällt. Dabei wird die Zurückerstattung nur für zukünftige Gebühren gut geschrieben. Die Zurückerstattung ist auf 10% gedeckelt. Strafen/Schadensersatz werden keine zugestanden. Und zu allem Übel ist die Definition der Verfügbarkeit noch so, dass der Kunde sich selbst darum kümmern muss ausgefallene Instanzen neu zu starten, und nur wenn dies nicht gelingt gilt der Service als ausgefallen. D.h. wenn eine Amazon Instanz alle Stunde ausfällt und der Startup einer neuen Instanz 5mins dauert, so gelten diese 5 Minuten nicht als Ausfall. Bei den S3 SLA werden Gutschriften für erfolglose Requests gezählt. 10% bei unter 99.9% und 25% bei unter 99%. Dabei kann Amazon aber weder Requests zählen die nicht angekommen sind, noch steht Amazon mit Strafen/Schadensersatz für Datenverlust ein. Gleiches gilt für EBS, hier gibt es keine SLA, die typische jährliche Fehlerrate (AFR - Anual Failure Rate) wird mit 0.1% - 0.5% angegeben (Lokale Harddisks haben angeblich 4%). Natürlich wird AWS durch diese SLA unter Druck gesetzt einen guten Service zu erbringen. Von daher haben diese schon einen Effekt. Der Kunde muss darauf aber vertrauen und das Risiko eines Schadens komplett selbst tragen. Eine reduzierte Amazon Rechnung wird Ihn da kaum trösten. Cloud Computing definiert nicht nur die Technologie neu, sondern auch die Ökonomie des Outsourcings: statt ewig Langer Vertragsverhandlungen, umfangreichen SLA Monitorings, Schuldzuweisungen und umfangreiche Konventionalstrafen (die zu Aufschlägen beim Betreiber führen um sein Risiko abzusichern) wird auf ein Kooperatives Vorgehen gesetzt, das von Vertrauen geprägt ist. Deswegen haben es auch die Großen Anbieter in dem Markt einfacher akzeptiert zu werden. Die technischen Vorkehrungen die ein Betreiber trifft werden stärker betrachtet als seine Vertraglichen Zusagen. Zusätzlich ist die Lösung durch den Kunden schon stärker auf Ausfall ausgelegt. (Diesen Artikel nehme ich zum Anlass eine neue Cloud Kategorie hier im Blog einzuführen)

Oracle und Amazon arbeiten zusammen um Oracle Anwendungen im Amazon Grid anzubieten. Es gibt jetzt einige Images die von Oracle kostenlos bereitgestellt werden. Oracle erlaubt sogar den Betrieb von Produktiven lizenzierten Anwendungen im EC2 Grid. Die Konfiguration ist sogar für offiziellen Support zertifiziert. Besonders interessant sind aber auch die Möglichkeiten die vorinstallierten Anwendungen wie Application Express oder Enterprise Manager Grid einfach mal ausprobieren zu können.

• Amazon/Oracle Partner News
• Oracle Cloud Computing Center

Im Gegensatz zum Begriff Grid Computing ist das Thema Cloud computing etwas eindeutiger definiert. Es geht darum IT-Resourcen (Rechner oder Laufzeitumgebungen) aus der Wolke des Internets einzukaufen, also die Anwendungen remote zu betreiben. Die bekanntesten Vertreter dieses Genres sind Amazon's EC2 (Elastic Cloud Computing - eine Serverfarm auf der man Xen Images auf Stundenbasis laufen lassen kann) und Google App Engine (eine Python Web Server umgebung für Web Anwendungen). Beide haben grade aktuell Neuigkeiten zu vermelden: Google App Engine ist nun offen für alle Entwickler (die kostenfreie Einsteigerversion erfordert eine SMS Registrierung, und kann auch mit Google Apps for Domains zusammenarbeiten). In der Public Beta des Amazon Cloud Services werden bald persistente Volumes möglich sein: damit sind dann auch klassische Enterprise Anwendungen einfach zu betreiben und nicht nur Compute Jobs (Video Rendering) oder replizierte Datenbanken. In zwei kommenden Artikel will ich beide Dienste etwas näher vorstellen, und meine Bewertung dazu abgeben wo und wie das Utility Computing funktionieren kann.