SQL Azure – Ein Überblick

Cloud Computing ist derzeit in aller Munde. Leider bleibt es für viele interessierte Entwickler ein „wolkiger“ Begriff und wird eher selten mit handfesten Fakten und Beispielen gefüttert. codingfreaks versucht, einen Überblick über die Microsoft-Form des Cloud-Computing (Azure) zu geben. Dabei liegt der Fokus zunächst lediglich auf den Cloud-Datenbanken und weniger auf den ebenfalls angebotenenen Services.

Ende 2009 kam Micrsoft im Rahmen verschiedener Veranstaltungen mit den ersten Details zu seiner neuen Cloud-Plattform Azure auf die Entwicklergemeinde zu. Bekannt waren entsprechende Ambitionen des Konzerns schon weitaus länger, aber ansehen konnte man es sich noch nicht so richtig. Das geht jetzt relativ problemlos, auch wenn nicht alles Gold ist, was glänzt.

Cloud Computing

Worum geht es eigentlich bei den Wolken? Im Grunde ist es mal wieder ganz simpel. Es geht um Verfügbarkeit und Skalierbarkeit von Anwendungen im allgemeinen. Das Problem für das die Cloud eine Lösung verspricht kennt eigentlich jeder ernsthafte Programmierer. Es wird durch Fragen, wie „Was, wenn meine Datenbank-Anwendung irgendwann mal wächst?“ oder „Was, wenn plötzlich 10.000 Nutzer gleichzeitg auf die Webseite zugreifen?“ abgebildet. Dahinter steht i.d.R. die Angst, dass eine selbst entwickelte Infrastruktur nicht mit steigenden Anforderungen skalieren kann.

Ein anderer Aspekt der Cloud ist der, dass Entwicklern oft das Know-How oder die technsichen Möglichkeiten fehlen, Infrastrukturen aufzubauen, die während der Entwicklungs-, Test- und Nutzungsphase einer Anwendung immer gleich funktionieren. Oft nutzen Entwickler, die mit Visual Studio arbeiten z.B. die mitgelieferte SQL Server 2008 Express Edition, um eine Datenbank zu erstellen und zu testen. Was aber, wenn diese Datenbank nun in das Produktiv-System übertragen werden muss? Wird sie immer noch genauso arbeiten? Welchen Einfluss werden veränderte Sicherheitseinstellungen haben? Skaliert die Datenbank mit steigenden Benutzerzugriffen? Muss ich eine Sicherung einrichten?

All dies – so der Plan von Microsoft – soll Azure nun obsolet machen. Kurz gesagt, richtet man eine SQL-Server-Datenbank in der Cloud ein und arbeitet die ganze Zeit auf dieser Instanz. In Wahrheit weiß man eigentlich nie, wo die Inszanz gerade tätsächlich residiert, mit der man arbeitet. Microsoft stellt ein riesiges virtuelles Rechenzentrum zur Verfügung. So ist z.B. das für Europa gedachte dem Vernehmen nach ein Cluster aus mehreren tausend Rechnern in Amsterdam. Es gibt nun bald mehrere solcher Cluster weltweit (in Asien entsteht aktuell das nächste) und alle Cluster sind dann wiederum miteinander verbunden. Diese Netze bieten bereits von Haus aus Techniken, wie Redundanz, Load Balancing usw.

Erstellt man nun eine Datenbank auf diesem System, dann weiß man nicht mehr, ob es auf Server A, B oder C oder auf allen drei gleichzeitig geschieht und das ist aus Sicht des Programmierers auch nicht weiter relevant. Man hat einen Inszanznamen und greift mit Benutzerdaten darauf zu – Fertig.

Microsoft hat hier übrigens nichts Neues erfunden. Unternehmen, wie IBM, Google oder Amazon bietet teilweise schon seit Jahren Cloud-Dienste an. Microsoft hat nun einen weiteren, speziell auf die MS-Produkte hin zugeschnittenen Cloud-Pool erstellt bzw. ist noch dabei.

Die Azure-Plattform

Wie bereits erwähnt, bietet Microsoft nicht nur Datendienste, sondern gliedert die Plattform in zwei wesentliche Bereiche: AppFabric und SQL Azure. AppFabric ist als Hosting-Plattform für alle Arten von Diensten konzipiert. .NET-Kenner denken natürlich sofort an WCF oder Web-Services. Das ist auch das Hauptziel dieses Bereiches, aber auch Java, PHP usw. werden als Ziel-Plattformen beworben. Infrastrukturell wird AppFabric einiges mehr als einfaches Hosting von Services bieten, aber das soll Thema eines anderen Beitrages sein.

SQL Azure Mixed Mode

Die Cloud bedeutet nun beileibe nicht das Ende des SQL Servers in Unternehmen! Microsoft weiß sehr genau, dass nur wenige Unternehmen bereit sein werden, ihre gesamten Datenbestände einem dritten einfach so zur Speicherung zu überlassen. Daher ist es neben dem reinen Betrieb einer Datenbank in der Wolke auch möglich, diese als Fallback oder Erweiterung der eigenen Datenbanken zu nutzen. Man nutzt also nach wie vor die Server und Tools aus dem SQL Server Portfolio und greift nur für bestimmte Funktionen oder im Falle von Überlastungen des eigenen Systems auf Microsoft Azure zurück.

Kosten

Azure ist nicht kostenlos! Das war ehrlich gesagt auch nicht zu erwarten und ist bei dem betriebenen Aufwand auch verständlich. Azure berechnet Kosten anhand der in Anspruch genommenen Leistungen. Dieses Modell ist also gerade für Unternehmen interessant, die, wie oben erwähnt, lediglich einen Fallback-Mechanismus zur Absicherung ihrer Systeme benötigen.

Anhand der hier verfügbaren Preisinformationen kann man erkennen, dass es zur Berechnung der Dienste vier mögliche grundlegende Werte gibt:

  • In Anspruch genommene Rechenzeit
  • Verbrauchter Speicherplatz
  • Durchgeführte Transaktionen
  • Angebotene Verbindungen

Dabei muss man natürlich nach den in Anspruch genommenen Dienstleistungen unterscheiden. Der Compute-Bereich z.B., der einem schiere Rechenkraft auf vielen Systemen gleichzeitig anbieten kann, berechnet sich einfach nach der genutzten Zeit. So kostet hier z.B. eine Stunde 0,12 $.

Die Berechnung erfolgt in drei unterschiedlichen Vertrags-Stufen: Introductory Special, Development Accelerator Core und Develop Accelerator Extented.

Eine kleine Beispielrechnung soll das verdeutlichen:

Benutzt man eine SQL-Azure-Version der Northwind-Datenbank (max 5 MB in Auslieferungszustand) und fragt pro Minute einmal den gesamten Inhalt der Tabelle Customers ab (max. ca. 530 Byte/Aufruf), so entstehen im „Introductory Special“-Tarif bei angenommenen 30 Tagen pro Monat Kosten i.H.v. 0,033 $ für 33.200 nicht im Vertrag abgedeckte Transaktionen. Dieser Wert ist von codingfreaks zumindest errechnet, aber noch nicht wirklich getestet und soll dabei helfen, die Kosten in Relation zu bekannten Daenbank-Größen zu setzen.

Das Preismodell erscheint durchaus fair, auch wenn nicht ganz auszuschließen ist, dass das grundgebührenfreie Paket „Introductory Special“ irgendwann einmal ausläuft.

Bis zum 31.01.2010 ist die Nutzung des Dienstes komplett kostenfrei.

Bei SQL Azure Mitmachen

Was muss man nun tun, um einen Account bei Azure einzurichten. Der Zugriff auf den SQL-Azure bereich läuft über http://sql.azure.com. Microsoft-typisch läuft die Anmeldung über Windows Live. Hat man bereits einen Windows-Live-Account, begürßt einen die Azure-Startseite derzeit mit der Frage nach einem Invitation Code. Diesen kann man sich über einen Link auf der Hinweisseite direkt zusenden lassen. Es steht zu erwarten, dass diese Abfrage bis zur finalen Version abgeschaltet wird.

azure01Nach erfolgreicher Registrierung bei SQL Azure ist man im SQL Azure Bereich eingeloggt (siehe Screenshot rechts).

Im linken Tab-Control kann man gut erkennen, wie Microsoft die Dienste thematisch strukturiert. Da wir uns im Bereich SQL Azure befinden, werden uns neben ein paar Server-Informationen (interessant hier vor allem der DNS-Name des Servers, der auf „database.windows.net“ endet und der angebliche Standort des Systems. Ein schnell selbst durchgeführtes tracing ergab, dass sich offenbar MSN-Server um das Routing der Pakete kümmern. codingfreaks konnte nicht mehr ermitteln, ob unsere Datenbank tatsächlich auf einem amerikanischen System lief, oder ob es sich hier derzeit um eine fixe Beta-Meldung handelt.

Zu Beginn wird immer die obligatorische master-Datenbank aufgeführt. Man kann über Create Database aber weitere hinzufügen.

Eine der ersten wichtigen Einstellungen für die Tests verbirgt sich hinter dem Registerreiter „Firewall Settings“. Standardmäßig ist jedes Azure-Konto komplett abgedichtet. Kann man sich den Luxus einer eigenen festen IP-Adresse leisten, wird zum Test erstmal diese als Regel eingetragen. Die meisten können dies nicht und sollten daher eine Rolle für den IP-Adress-Bereich „0.0.0.0 – 255.255.255.255“ eintragen. Vorsicht: Dies sollte auf keinen Fall mit Produktiv-Systemen gemacht werden!

Auf dem Tab „Databases“ lässt sich nun nach Einrichtung einer ersten Test-Datenbank (siehe Screenshot) relativ einfach ein Testszenrio anstoßen. Ein Klick auf „Connection Strings“ öffnet ein Fenster, aus dem man als .NET-Entwickler den ADO.NET-Connection-String herauskopiert.

Nach einem Wechsel in Visual Studio lässt sich das in Listing 1 einsehbare Testprogramm erstellen. Ich habe dort einen ConnectionStringBuilder verwendet, um die Zuordnung der Verbindungsdaten etwas transparenter zu gestalten. Die ***-Einträge müssen noch durch eigene Werte ersetzt werden.

static void Main(string[] args)
{
    SqlConnectionStringBuilder csbuiThis = new SqlConnectionStringBuilder();
    csbuiThis.DataSource = "tcp:***.database.windows.net";
    csbuiThis.UserID = "***";
    csbuiThis.Password = "***";
    csbuiThis.InitialCatalog = "test";
    csbuiThis.Encrypt = true;
    using (SqlConnection cnnTmp = new SqlConnection(csbuiThis.ToString()))
    {
        try
        {
            cnnTmp.Open();
            Console.WriteLine("Verbunden mit Azure-Datenbank {0} unter {1}!", csbuiThis.InitialCatalog, csbuiThis.DataSource);
            Console.WriteLine("Server-Version: {0}", cnnTmp.ServerVersion);
            Console.WriteLine("Statistiken erlaubt: {0}", cnnTmp.StatisticsEnabled);
            Console.WriteLine("Workstation-ID: {0}", cnnTmp.WorkstationId);
            Console.WriteLine("Paket-Größe: {0}", cnnTmp.PacketSize);
            Console.WriteLine();
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
        }
        finally
        {
            if (cnnTmp.State == System.Data.ConnectionState.Open)
            {
                cnnTmp.Close();
                Console.WriteLine("Verbindung geschlossen!");
            }
        }
    }
    Console.ReadKey();
}

Tools

Die meisten gestandenen SQL-Server-Programmierer wenden nun sofort ein, dass wir zwar eine Datenbank haben, aber keinerlei Struktur. SQL Azure bietet hier keine weiter gehende Unterstützung. Das naheliegendste ist also, sein SQL Management Studio mit den Serverdaten zu füttern und loszulegen. Geht aber nicht einfach so :-).

Hier macht sich der Beta-Status von Azure bemerkbar. Der Zugriff klappt bisher nur mittels des Management Studios von SQL Server 2008 R2, nicht aber mit dem der „alten“ 2008er-Version! In letzterem erntet man eine Exception:

„Invalid object name ’sys.configurations‘. (Microsoft SQL Server, Fehler: 208)“

Wie man im SQL Azure Team Block nachlesen kann, können bei Microsoft CTP-Versionen für das Studio bezogen werden:

Beide Pakete sind nur in Englisch erhätlich und sollten vorsorglich in virtuellen Maschinen getestet werden. Wer nun aber einen gewohnt intuitiven Zugriff auf die Datenbanken erwartet, wird ein wenig enttäuscht. Anders, als das 2008er-Studio kommt zwar keine Fehlermeldung, allerdings bringt ein Klick auf „Neue Tabelle“ schnell Ernüchterung: das Management-Studio erfordert die Eingabe der SQL-Strings zum Erstellen der Objekte. Wem das zu stressig ist, kann die Objekte zunächst lokal erstellen und dann auf Azure hoch-importieren:

  1. Tabelle auf lokaler Datenbank mit dem Management-Studio erstellen.
  2. Rechtsklick auf die Tabelle: „Skript für Tabelle als“ -> „CREATE in“ -> „Neues Abfrage-Editor-Fenster“.
  3. Alles von „CREATE TABLE“ bis GO markieren und kopieren.
  4. Neues Abfrage-Fenster auf der Azure-Verbindung öffnen.
  5. SQL einfügen und Abfrage ausführen.

Uns ist es bisher nicht gelunden, ganze Datenbanken per DTS-Package (also Export-Menupunkt) auf Azure zu schieben. Es scheitert daran, dass er den Server-DNS-String nicht akzeptiert. Die Azure-Datenbank bietet die Import-Option wiederum gar nicht erst an.

Die Tool-Unterstützung ist also bisher vorsichtig ausgedrückt rudimentär und erst die finale Version sowohl von SQL Server 2008 R2 und dessen Tools als auch SQL Azure werden wohl reibungslos zusammen arbeiten.

Resumé

Microsoft hat bereits eine Menge Arbeit in die Azure-Plattform gesteckt. Bislang ist man als Entwickler aber trotzdem noch auf eine Menge Enthusiasmus und Forschergeist angewiesen, um sich für die ersten Tests zu motivieren. Die Idee hinter Azure ist so genial, wie sie einfach ist. Es sollte allerdings bei aller technologie-verliebtheit nicht aus den Augen verloren werden, dass auch mit Azure der Trend zu Informations-Giganten im Internet mehr und mehr verschärft wird (siehe auch heise-online Meldung zum 26C3). Man muss wirklich kein Verschwörungs-Theoretiker sein, um zu verstehen, dass hier Risiken verborgen liegen, die gegen den Nutzen abgewogen werden sollten. Ein Datenbank einfach mal nur so in die Wolke zu legen, weil es eben geht, sollte in den Bereich der verpönten Aktionen aufgenommen werden, denn man schießt mit Kanonen auf Mikroben!

codingfreaks wird die weitere Entwicklung gespannt betrachten und sich in einem der nächsten Artikel um die AppFabric kümmern. Wir wissen allerdings schon jetzt, dass wir bewusst auf einem sehr abstrakten Level bleiben wollen, weil die Technik noch sehr jung ist und das Potential größerer Veränderungen im Gesamtsystem noch relativ hoch ist.

Links

Einstiegsseite Microsoft Azure

Preisinformationen

Microsoft Azure-Team-Blog

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.