Questo post è parte di una serie su windows azure.
Uno delle feature di Azure più interessanti, facilmente utilizzabili ed integrabili anche nelle applicazioni già in essere è il Windows Azure Storage.
Azure mette a disposizione quattro diverse tipologie di storage:
- Blob: storage di dati binari (file e simili).
- Table: storage di dati non relazionali.
- Queue: storage di messaggi (reliability)
- Windows Azure disk: fondamentalmente è un volume NTFS, utilizzabile a runtime da un “role”. Lo storage effettivo dei dati scritti su un Windows Azure è memorizzato in un page blob, garantendo, in questo modo, che i dati rimangano disponibili anche a seguito di un recycle dell’istanza di un “role”.
La creazione e il setup di uno storage avviene tramite il “management portal” di Azure ed è, alla stregua di tutte le altre operazioni fatte tramite il portale, molto semplice: basta impostare il nome dell’account, la region in cui si sceglie di “deployare” lo storage e abilitare/disabilitare la, cosìdetta, “geo-replication”.
Alcune semplici note nella scelta dei parametri:
- la scelta della “region” va fatta in base alla “prossimità” con le applicazioni che sfrutteranno lo storage. Qualora tali applicazioni fossero dei role (cloud service) sarebbe opportuno/auspicabile/preferibile che siano nello stesso data center per massimizzare le prestazioni (e contenere i costi)
- abilitare la geo-replication è una scelta a costo zero. Abilitarla in un secondo momento, invece, potrebbe impattare economicamente in base alla quantità di dati da replicare nel secondo data center.
La possibilità di abilitare la replica dei dati anche su data center geograficamente distribuiti aumenta a dismisura l’affidabilità del servizio: qualora ci siano “major disaster” nel data center principale, i dati, già replicati nel data center secondario, verranno messi a disposizione della piattaforma aggiornando il DNS e facendolo puntare allo storage sul secondo datacenter, in modo del tutto trasparente alle applicazioni che ne fanno già uso.
Quando la creazione dello storage viene completata (pochi minuti) abbiamo a disposizione blob, table e queue. Gli endpoint attraverso cui possiamo interagire con i tre tipi di storage hanno tutti la stessa semantica:
http://..core.windows.net//
dove:
- ACCOUNTNAME è il nome scelto in fase di creazione dello storage
- SERVICETYPE può essere blob, table o queue a seconda della tipologia di “servizio” con il quale si vuole interagire
- CONTAINER e RESOURCE li vedremo strada facendo 🙂
Ora basta con tutta questa teoria (anche se un po’ di basi credo proprio che non guastino), dal prossimi post entreremo nel dettaglio pratico del come e quando utilizzare il “cloud storage” di Azure.
