28

Mar

Windows Azure – SQL Azure pt.2 – Architettura e API

L’infrastruttura dietro SQL Azure è certamente un esempio maximo dello stato dell’arte di SQL Server in architettura distribuita che mai probabilmente riusciremo a vedere in un contesto alternativo/aziendale. Fondato su una tecnologia che permette HA (High Availability) scalabile, promette di essere un backend DB inaffondabile.

A livello di replica, il grafico sotto mostra molto bene quale possa essere la struttura:

image

Mentre da quest’altro emerge come dal punto di vista dell’applicazione, sembra che nulla cambi. Infatti il load balancer si pone come gateway TDS (Tabular Data Stream) esattamente come qualsiasi altro SQL Server in attesa TCP. Sarà poi il LB ad inoltrare la richiesta a SQL effettivo, gestendo però il ciclo di vita della sessione stabilita. Il backend poi, sarà replicato come sopra.

image

Il servizio SQL Azure viene erogato secondo modalità analoghe a quelle dell’Azure Compute e dell’Azure Storage, infatti:

  • Ogni account può avere un Server
  • Ogni server può avere più database (di dimensione anche diversa)
  • Ogni DB ha propri oggetti tipici (Tabella, Views, SP, etc)

Modello di utilizzo

Utilizzando un gateway TDS, SQL Azure è accessibile esattamente come una qualsiasi altra istanza SQL Server, senza dover cambiare nulla per quanto riguarda la connessione e l’accesso. Le librerie ADO, PHP, ODBC esistenti possono infatti essere utilizzate semplicemente facendo puntare le connessioni al nuovo endpoint pubblico.

Una best practice per l’utilizzo di SQL Azure è quella di criptare la connessione (Encrypt = True) e di NON fidarsi del certificato server (TrustServerCertificate = False), cosa che purtroppo si fa spesso in contesti di intranet per la scarsa qualità dei certificati SSL. Il non fidarsi evita attacchi di tipo man-in-the-middle con certificati non validi.

Il deployment su SQL Azure è effettuabile tramite script T-SQL via interfaccia amministrativa e/o tramite SQL Server Management Studio 2008 R2: alcuni progetti open source stanno nascendo per semplificare la procedura (soprattutto per grossi schemi/dati).

Il Security Model è basato su login e non è possibile per ora impostare trusted connection.

Limiti

Al momento esistono alcuni limiti, sensati data la piattaforma distribuita, che SQL Azure ha in difetto di SQL Server:

  • Mancanza di possibilità di salto tra DB (clausola USE)
  • Mancanza di alcuni Data Types (esempio il Filestream che, per sua natura, è dipendente dall’architettura fisica)
  • Mancanza delle partizioni (o meglio del controllo relativo alle partizioni)
  • Mancanza della ricerca full-text e del CLR

Edizioni e pricing

Le “edizioni” sono fondamentalmente due:

  • Web: da 1 o 5 GB
  • Business: da 10 a 50 GB

I prezzi ovviamente sono molto diversi, non cambia nulla nell’architettura, solo la dimensione. Nota: si può cambiare la dimensione del DB in corso d’opera e questo comporterà l’inizio di una eventuale diversa fatturazione al momento del cambio.

by Roberto Freato on 3/28/2011
Post archive