5

Mar

Windows Azure – Storage pt.2 – Blobs, SDS e CDN

Lo schema generale dell’entry point dedicato ai blobs nell’Azure Storage è questo:

image

Ogni subscription di Azure dà diritto a diversi account di storage (il numero è variato negli anni, potrà variare ancora); ogni account di storage ha un entry point, rappresentato da un indirizzo web sul dominio microsoft dedicato (core.windows.net); ogni entry point può avere più containers; ogni container può avere più blobs, i quali possono essere composti da blocchi o pagine.

Le operazioni che si possono fare su un blob sono:

  • PutBlob
  • GetBlob
  • DeleteBlob
  • CopyBlob
  • SnapshotBlob
  • LeaseBlob

Ad ogni blob è poi possibile associare dei metadati, che non sono altro che coppie (nome,valore). Un blob è sempre accessibile tramite il suo nome completo (comprensivo del container). Inoltre all’interno di un container è sempre possibile creare un numero di Directory illimitate in numero e profondità (ovviamente, essendo poi referenziate via URL http, è sensato limitare la profondità a quella attualmente supportata dal protocollo e dai browser).

Nota: di rilevanza fondamentale è il particolare container $root (che non esiste di default ma può essere creato) che è implicitamente il container di tutto ciò che sta in radice all’indirizzo base del nostro endpoint di storage. Creando il container root e caricando una immagine image.jpg, sarà poi possibile ottenerla (previ permessi) all’url: http://accountName.blob.core.windows.net/image.jpg.

Page Blobs e Block Blobs

I blobs “normali”, ovvero quelli che possono essere visti come i più comuni, sono i Block Blob. Essi possono essere creati per blocchi, avere una dimensione complessiva di 200GB ed essere reperiti sequenzialmente. Se invece abbiamo bisogno di un accesso casuale, allora il Page Blobs fa al caso nostro. Con esso possiamo definire delle pagine il cui blob risultante sarà proprio un array di esse. Poi a queste potremo accedere in random read/write. Già si può intuire che con una struttura del genere si può costruire sopra, in via teorica, un qualsiasi sistema di memorizzazione casuale.

Shared Access Signatures

Per la gestione granulare dei permessi sui blobs è possibile definire dei token, tipicamente di due tipi:

  • Ad-Hoc: tipicamente delle firme a scadenza basate sulla data, utili nel caso si debbano fornire risorse usa e getta (single-url) o per l’interazione con Silverlight.
  • Policy Based: si crea una policy a livello di container, utile per creare policy di accesso per gruppi di utenti.

Content Delivery Network

La CDN serve per replicare i contenuti di Azure Blob Storage in giro per il mondo, con l’obiettivo di ridurre la latenza tra un client e il singolo endpoint di Azure. Il meccanismo è quello più tipico della cache, per cui incollo solo un diagramma degli step coinvolti in un probabile flusso.

image

image

image

by Roberto Freato on 3/5/2011
Post archive