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
Eseguire le GitHub Actions offline
Sfruttare lo stream rendering per le pagine statiche di Blazor 8
Short-circuiting della Pipeline in ASP.NET Core
Disabilitare automaticamente un workflow di GitHub (parte 2)
Utilizzare Model as a Service su Microsoft Azure
.NET Conference Italia 2023
Mascherare l'output di un valore all'interno dei log di un workflow di GitHub
Migliora la resilienza delle applicazioni con .NET e Azure Container Apps
Utilizzare le collection expression in C#
Usare una container image come runner di GitHub Actions
Definire stili a livello di libreria in Angular
Usare le collection expression per inizializzare una lista di oggetti in C#
I più letti di oggi
- Minimal API in ASP.NET Core 8
- Ottimizzazione dei block template in Angular 17
- Gestire la cancellazione di una richiesta in streaming da Blazor
- IronPython in Release Candidate
- se avete il dark mode attivo nel vostro browser, da oggi sui nostri siti troverete un tema #dark specifico. fateci sapere cosa ne pensate!per ora è automatico, in futuro sarà specificabile dal profilo. #aspitalia https://aspit.co/b0e