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:
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.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Le novità di Angular: i miglioramenti alla CLI
Load test di ASP.NET Core con k6
Usare Refit e Polly in Blazor per creare client affidabili e fortemente tipizzati
Creare alias per tipi generici e tuple in C#
Utilizzare Tailwind CSS all'interno di React: primi componenti
Utilizzare gli snapshot con Azure File shares
Eseguire una GroupBy per entity in Entity Framework
Utilizzare l'operatore GroupBy come ultima istruzione di una query LINQ in Entity Framework
Elencare le container images installate in un cluster di Kubernetes
Utilizzare un service principal per accedere a Azure Container Registry
Cambiare la chiave di partizionamento di Azure Cosmos DB
Inizializzare i container in Azure Container Apps