I blob di Azure sono un servizio che permettono di memorizzare in modo affidabile e scalabile i nostri file. Sono accessibili attraverso endpoint REST e sono in grado di sostenere molteplici richieste concorrenti. Il loro sistema di persistenza è basato sul file system distribuito di Microsoft che replica all'interno della stessa farm o regione almeno tre copie del file stesso. Quando configuriamo un nuovo account abbiamo però la possibilità di scegliere varie modalità. La predefinita è la geo-redundant, la quale indica di creare più copie dello stesso file, non solo nella stessa regione ma anche in una opposta a quella dove abbiamo scelto di far risiedere i file. Se per esempio abbiamo scelto di sfruttare la farm in West Europe, verrà mantenuta una copia dei file anche in North Europe. Questo per sopravvivere ad eventuali disastri, come calamità naturali, incendi o altro.

Una terza opzione che possiamo abilitare, anche in un secondo momento, è la Read-access geo redundant, la quale permette di accedere, con un secondo endpoint, anche ai file presenti in questa seconda farm. Il vantaggio che otteniamo è quello di aumentare la disponibilità dei nostri file, poiché l'accesso al cosiddetto endpoint primario potrebbe non essere disponibili, per i più vari motivi: problemi nella farm stessa o problemi di rete imputabili all'utente stesso. In questi scenari possiamo, lato client, scegliere di provare ad interrogare l'endpoint primario ed eventualmente, in caso di problemi, di provare ad interrogare il secondario.

Per farlo, dobbiamo prima di tutto abitare l'opzione dello storage.

Fatto questo disponiamo di due endpoint REST:

http://mioStorage.blob.core.windows.net
http://mioStorage-secondary.blob.core.windows.net

Per accederci valgono le stesse chiavi e le stesse firme generate per interrogare il primario. Se stiamo usando l'SDK .NET, possiamo sfruttare le opzioni disponibili su ogni metodo, le quali permettono di accedere al file. Per esempio nel seguente snippet leggiamo un file dicendo di provare sul primario ed eventualmente sul secondario.

var client = account.CreateCloudBlobClient(); 
var container = client.GetContainerReference("mioContainer"); 
var blob = container.GetBlockBlobReference("file.txt"); 

var options = new BlobRequestOptions() 
{ 
  LocationMode = LocationMode.PrimaryThenSecondary, 
};
blob.DownloadToFile(localFileName, FileMode.OpenOrCreate, null, options);

Da sottolineare che l'accesso alla regione secondaria è in sola lettura, perciò le scritture vanno sempre fatte su quella primaria. Inoltre, per una questione di prestazioni, è garantita la consistenza delle informazioni solo sulla regione primaria, dato che la replica sulla regione secondaria avviene in asincrono. Questo vuol dire che potenzialmente sul secondario una risorse appena inserita potrebbe essere non disponibile. Infine, facciamo notare che l'attivazione di questa opzione aumenta i costi dello storage.