Infrastruktur

Ich habe die Gelegenheit auf dem fünften IPv6 Kongress (6.-7. Juni in Frankfurt) über das Thema Java und IPv6 zu sprechen. (Programm). Hier das Abstract des Vortrags:

7.6.2013 14:00 - 14:30 Uhr
Bernd Eckenfels: Java-Anwendungen für IPv6 fit machen

Dass die Java-Plattform IPv6 unterstützt, ist allgemein bekannt – oder es wird vermutet. Aber sind dazu Änderungen an Anwendungen notwendig, die bisher nur für IPv4 getestet wurden? Welche Funktionen der IPv6-Protokollfamilie werden unterstützt? Welche Besonderheiten sind zu beachten, um Dual-Stack-fähige Anwendungen in Java zu erstellen?

Der Vortrag betrachtet die Java-API für Netzwerkkommunikation und untersucht diese auf Relevanz für IPv6. Ein besonderes Augenmerk wird auf die Umsetzung von Dual-Stack-fähigen Geschäftsanwendungen (TCP- und TLS-Protokoll) gelegt. Implementierungsdetails von Java SE 7 (OpenJDK, Oracle und IBM) sind Teil des Vortrags.

Ich werde nicht auf die mobilen Java Profile oder Android eingehen. Und über Java 8 gibt es in dem Bereich keine Neuerungen zu vermelden.

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.

Ich hab ein wenig mit Powershell herumgespielt (weil ich das Script das auch in de.Hackin9.org 08/2011 abgebildet war nicht verstanden habe).

Dabei kam dann folgendes funktionierendes Script heraus, es sortiert mit alle Rechner des AD LDAPs und zeigt diese in einem grafischen Viewer mit Betriebsystemversion und Servicepack Level an:

$ldapSearcher = new-object directoryservices.directorysearcher;
$ldapSearcher.filter = "(objectclass=computer)";
$computers = $ldapSearcher.findall();
$pcs = @();
foreach ($c in $computers) {
  $pc = "" | Select-Object Name,OS,SP,SPN;
  $pc.Name=$c.properties["cn"];
  $pc.OS=$c.properties["operatingsystem"];
  $pc.SP=$c.properties["operatingsystemservicepack"];
  $pc.SPN=$c.properties["serviceprincipalname"];
  $pcs += $pc;
}
$pcs | sort-object OS,SP,Name | Out-GridView;

Ich habe aber keine Ahnung wie man einfacher aus den Dictionary Entries des $c.Properties Member direkte Properties machen kann ohne diese mit einer foreach Schleife und direktem Assignment aufwändig zu kopieren. Ich hoffe ein mitlesender Powershell Guru kann mir das kurz sagen? :)

Update: Max Trinidad (@MaxTrinidad) hat mich auf die Idee mit New-Object gebracht, damit lässt sich das Script etwas vereinfachen und die Attribute in Strings konvertieren:

$ldapSearcher = new-object directoryservices.directorysearcher;
$ldapSearcher.filter = "(objectclass=computer)";
$computers = $ldapSearcher.findall();
[Array] $pcs = $null;
foreach($c in $computers) {    
    $pcs += New-Object PSobject -property @{
        Name = [string]$c.properties["cn"];
        OS = [string]$c.properties["operatingsystem"];
        SP = [string]$c.properties["operatingsystemservicepack"];
        SPN = [string]$c.properties["serviceprincipalname"]; }
}

Und darauf aufbauend (aber ohne String Konvertierung) dann die Lösung mit der Automatischen Übernahme aller Dictionary Einträge aus dem AD Objekt:

$ldapSearcher = New-Object directoryservices.directorysearcher;
$ldapSearcher.filter = "(objectclass=computer)";
$computers = $ldapSearcher.findall();
[Array] $pcs = $null;
$computers | ForEach-Object { $pcs += New-Object PSobject -property $_.Properties; }
$pcs | Out-GridView;

Mir ist gerade zufällig aufgefallen (als ich diesen Bugreport nachgestellt habe) dass Windows 7 IPv4 Address-Einträge die eine führende 0 haben im hosts file ignoriert:

C:\Windows\system32>echo 9.20.187.06 TestHost
  >> %SystemRoot%\system32\Drivers\etc\hosts

C:\Windows\system32>ipconfig /displaydns | find "A-Eintrag"
    AAAA-Eintrag  . . . . : 2001::1
    AAAA-Eintrag  . . . . : fe80::20d:60ff:fe49:47
    AAAA-Eintrag  . . . . : 2001::2
    (Host-)A-Eintrag  . . : 9.20.187.96

C:\Windows\system32>echo 9.20.187.6 TestHost
  >> %SystemRoot%\system32\Drivers\etc\hosts

C:\Windows\system32>ipconfig /displaydns | find "A-Eintrag"
    AAAA-Eintrag  . . . . : 2001::1
    AAAA-Eintrag  . . . . : fe80::20d:60ff:fe49:47
    AAAA-Eintrag  . . . . : 2001::2
    (Host-)A-Eintrag  . . : 9.20.187.96
    (Host-)A-Eintrag  . . : 9.20.187.6

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.

Meiner Erfahrung nach werden im Enterprise Umfeld technische Infrastruktur Entscheidungen oftmals via Policy geregelt. Wenn dann neue Anwendungen installiert werden, so müssen diese sich in die vorhandene Landschaft einfügen - ohne gross eine Risikobewertung durchgeführt zu haben.

Typische Kandidaten für diese Vorgaben sind OS (unkritisch solange Erfahrungen damit vorliegen), Cluster, Netzwerk/Firewalls und Storage.

Gerade beim Storage ist das Vertrauen in ein Enterprise SAN grenzenlos (muss es auch sein, war ja teuer). Performance Engpässe werden nie auf der SAN Seite gesucht und Ausfälle werden nicht erwartet (als SPoF darf das SAN einfach nicht ausfallen).

Dabei gibt es ja auch alternative Ansätze. Lokales Storage (mit Sharding, Replikation), NAS oder auch die Auslagerung gewisser Daten in eine Storage Cloud. Auf jeden Fall sollte man sich überlegen: was passiert wenn mein SAN ausfällt, und wie schnell kann ich es wieder ans Laufen bringen.

In einem Artikel den ich auf Highscalability.com gefunden habe bespricht David Marks die Risiken eines SAN Infrastruktur für Web 2.0 Installationen, bei denen Skalierbarkeit und Verfügbarkeit natürlich oberste Prio haben: Should I get a SAN to scale my site architecture (You Can Change It Later 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)

Der Titel dieses Artikels ist eine Zeile aus den SLES11 Beta3 Release Notes. Dieser Artikel soll aber kein Suse bashing sein, sondern vielmehr will ich etwas Frust über den desolaten Zustand der Xen Unterstützung im Linux Kernel herauslassen.

Dabei ist der Hypervisor (erwartungsgemäß wegen der Simplizität) nicht das Problem, sondern die Paravirtualisierung der Guests und Support von aktuellen Linux Kernels für die Dom0 Host Domain. Sogar Microsoft Hyper-V (Windows 2008 Server) und Sun xVM Server (Solaris) haben bessere Xen-komptible Hosts zu bieten als mit einem aktuellen mainstream Linux Kernel erreichbar ist.

Fedora/Redhat die bisher viele Forward-Port Arbeiten an den Xen Patches in aktuelle Kernels gemacht haben planen ein Fedora 10 Release mit einem Hauptkernel (Linux 2.6.27 / Xen 3.3.0) der sowohl Bare-Metal als auch DomU Installationen unterstützt (durch die Verwendung des paravirt_ops Frameworks). Also ein sogenannter Unified Kernel. Das klingt zwar gut, aber gleichzeitig wird es keinen Kernel geben der als Dom0 (Host) eingesetzt werden kann. Hier verweist das Fedora Projekt auf F8 oder KVM mit dem Xen-in-KVM Emulator Xenner. Dieser setzt aber Hardware Unterstützung voraus.

Bei Debian gibt es einen vergleichbaren Unified Kernel, und recht aktuell (Bug#495895) gibt es jetzt in Debian unstable dank Sebastian Blank wieder einen Dom0 Kernel auf Basis der Suse Patches.

Suse selbst hat aber in der SLES11 Beta (wie man am Titel sehen kann) noch einige Probleme in diesem Bereich. Ich denke auch bei Debian hat das noch niemand wirklich ausgiebig getestet. Bleiben die kommerziellen Xen Server 5 (Citrix) Installationen wenn man einen Bastel-freien Linux basierenden Hypervisor betreiben möchte.

Bei Oracle gibt es die Xen 3.1 basierte OracleVM die aber eine zentrale Management Console empfiehlt und Redhat liebäugelt nach RHEL 5 mit einer eigenen Virtualisierungslösung auf Basis von KVM (verständlich nach dem Kauf von Qumranet).

Ich bin ganz Froh zu sehen dass Suse hier den Dom0 Support wieder nutzbar macht, und Debian ist ganz unerwartet einer der fast-followers.

Beim Virtual PC Guy Blog gibt es Screenshots der Installation und "Gui" des neusten "Betriebsystems" von Microsoft:



Aber Spass beiseite, der Hyper-V Server 2008 ist die kostenlos von Microsoft bereitgestellt Hypervisor Platform auf Basis von Windows Server 2008.

Hyper-V Server wird mit einem minimalen Environment geliefert (genannt Server Core: ohne Explorer GUI oder Startleiste). Es ist auch nicht möglich Anwendungen zu installieren.

Eine vergleichbare Installation kann auch mit einem Windows Server 2008 gemacht werden: Hyper-V sitzt auch dort unter dem Betriebssystem. Allerdings sind in der Server Version Lizenzen für 1 (Standard), 4 (Enterprise) oder unbegrenzt (Datacenter) viele virtualisierte Windows Server 2008 Instanzen enthalten.

Auf einem Hyper-V Server (der nur auf 64bit Hardware (max 4 Sockets, 32GB) mit Hardware Virtualisierung läuft) können diverse (Microsoft) Betriebssysteme betrieben werden. Die Emulation der Legacy Devices ist (im Gegensatz zum MS Virtual Server) nicht optimiert, Guests sollten also Device Treiber in einsetzen die von der Virtualisierung wissen ("erleuchted sind").

Für Linux bietet Microsoft die Linux Integration Components for Hyper-V (Beta) als Paket an, SLES 10 (32bit oder x64) ist damit auf Hyper-V Server zertifiziert (allerdings nur mit einer virtuellen CPU). Dabei werden Xen enabled Kernels eingesetzt.

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