Vor gut einer Woche
habe ich mich dazu durchgerungen, meine ersten Gehversuche in der Microsoft Wolke
zu wagen.
Es ging um die Portierung einer mittelgroßen ASP.NET 4.0 (Webforms) App zu Windows
Azure. Der erste Schritt was das Umziehen der Datenbank zu SqlAzure, was sehr unproblematisch
war. Die einzige Änderung, die ich an der Datenbank machen musste, war das Anlegen
von Clustered Indexes auf Zuordnungstabellen. Diese sind notwendig, weil die Datenbank
bei SqlAzure repliziert wird. Mehr dazu hier:
http://blogs.msdn.com/b/sqlazure/archive/2010/05/12/10011257.aspx
Die eigentliche Webseite hatte ich vorerst auf meinem eigenen Server gelassen und
die Datenbank lief in der Cloud. Von dieser Kombination hatte ich mir eine schlechte
Performance erwartet, da für jede Datenbankabfrage ein Round Trip von Berlin nach
Amsterdam notwendig war. Jedoch konnte ich keine zusätzliche Verzögerung messen.
Jetzt hatte ich genug Zeit, um auch die Webseite zu Windows Azure zu bringen. Die
brauchte ich auch. Der einfache Weg, den man in vielen Webcasts sehen kann, lief
wie geschmiert:
- Hinzufügen eines Windows Azure Projects zur Solution
- 2, 3 Settings anpassen
- Publish im Windows Azure Projects klicken
- Kaffee holen weil Windows Azure die VM’s einrichtet und hochfährt, dies dauert ca.
10 Minuten
Schön, die Webseite war online und die Freude war groß. Leider währte dieses Erfolgserlebnis
nur kurz. Genauer gesagt, bis ich den ersten Link auf der Webseite klickte und ich
feststellen musste das das ASP.NET Routing nicht funktionierte.
Jede geroutete URL lieferte ein „404 – File not found“ zurück.
Die Fehlersuche begann im IIS, der auf der VM in Windows Azure lief. In meiner App
konnte kein Fehler sein, da sie schon ein paar Monate fehlerfrei auf meinem eigenen
Server lief. Die Einstellungen im IIS waren alle sauber. Das Rätselraten begann.
Wenn kann man an Wochenende um Rat fragen?
Leider ist die Azure - Community in Deutschland praktisch nicht vorhanden, nur ein
Blogger schlägt sich tapfer und veröffentlicht regelmäßig Artikel rund um Windows
Azure: Sascha Dittmann.
Bei einem Telefonat mit ihm erfuhr ich, dass die Azure VM’s per default nicht mit
Windows Server 2008 R2 laufen, sondern mit Windows Server 2008!
Warum das so ist, kann ich nicht nachvollziehen. Bei der Datenbank setzt Microsoft
schon auf Denali und in der Azure Management App können sogar schon CTP Features
des nächsten SQL Servers genutzt werden.
Es ist möglich, vor der Instanziierung einer VM das OS zu bestimmen und den Windows
Server 2008 R2 auszuwählen:
- ServiceConfiguration.Local.cscfg bzw. in der ServiceConfiguration.Cloud.cscfg öffnen
- Im Tag ServiceConfiguration folgende Attribute ändern/hinzufügen: osFamily="2"
Gesagt – getan, schon lief mein Routing.
Tja, da fehlte wohl irgendein Patch in der Windows Azure - Windows Server 2008 Installation,
der in der R2 Version vorhanden ist.
Hier noch mal eine kurze Zusammenfassung:
Per default bekommt man in Windows Azure nur eine Windows Server 2008 Installation.
Mit dieser kann man das Routing in ASP.NET 4.0 Webforms nicht nutzen, es hagelt
404’er.
Abhilfe schafft die Auswahl des Windows Servers R2.