Esercitazione: Creare un'applicazione a disponibilità elevata con l'archiviazione BLOB

Articolo
01/10/2024

Questa è la prima di una serie di esercitazioni. Si apprenderà come applicare la disponibilità elevata ai dati delle applicazioni in Azure.

Dopo aver completato questa esercitazione, si avrà un'applicazione console che carica e recupera un BLOB da un account di archiviazione con ridondanza geografica della zona di accesso in lettura (RA-GZRS).

La ridondanza geografica in Archiviazione di Azure replica le transazioni in modo asincrono da un'area primaria a una secondaria a centinaia di chilometri di distanza. Il processo di replica garantisce che i dati nell'area secondaria abbiano coerenza finale. L'applicazione console usa il criterio interruttore per determinare l'endpoint a cui connettersi, passando automaticamente da un endpoint a un altro quando vengono simulati errori e ripristini.

Se non si ha una sottoscrizione di Azure, creare un account gratuito prima di iniziare.

Nella prima parte della serie si apprenderà come:

Creare un account di archiviazione
Impostare la stringa di connessione
Eseguire l'applicazione console

Prerequisiti

Per completare questa esercitazione:

Installare Visual Studio 2022 con il carico di lavoro Sviluppo di Azure.

Accedere al portale di Azure.

Creare un account di archiviazione

Un account di archiviazione offre uno spazio dei nomi univoco per archiviare gli oggetti dati di Archiviazione di Azure e accedere a tali oggetti.

Seguire questa procedura per creare un account di archiviazione con ridondanza geografica della zona e accesso in lettura (RA-GZRS):

Selezionare il pulsante Crea una risorsa nel portale di Azure.
Selezionare Account di archiviazione - BLOB, file, tabella, coda nella pagina Nuovo.

Compilare il modulo dell'account di archiviazione con le informazioni seguenti, come illustrato nell'immagine seguente e selezionare Crea:

Impostazione	Valore di esempio	Descrizione
Abbonamento	Sottoscrizione personale	Per informazioni dettagliate sulle sottoscrizioni, vedere Sottoscrizioni.
ResourceGroup	myResourceGroup	Per i nomi di gruppi di risorse validi, vedere Regole di denominazione e restrizioni.
Nome	mystorageaccount	Un nome univoco per l'account di archiviazione.
Location	Stati Uniti orientali	Scegliere un paese.
Prestazioni	Standard	Le prestazioni standard sono un'opzione valida per lo scenario di esempio.
Tipo di account	StorageV2	È consigliabile usare un account di archiviazione per utilizzo generico v2. Per altre informazioni sui tipi di account di archiviazione di Azure, vedere Panoramica dell'account di archiviazione.
Replica	Archiviazione con ridondanza geografica della zona e accesso in lettura (RA-GZRS)	L'area primaria è con ridondanza della zona e viene replicata in un'area secondaria, con l'accesso in lettura all'area secondaria abilitato.
Livello di accesso	Accesso frequente	Usare il livello ad accesso frequente per i dati a cui si accede di frequente.

create storage account

Scaricare l'esempio

Scaricare il progetto di esempio, estrarre (decomprimere) il file storage-dotnet-circuit-breaker-pattern-ha-apps-using-ra-grs.zip, quindi passare alla cartella v12 per trovare i file di progetto.

È anche possibile usare Git per clonare il repository nell'ambiente di sviluppo locale. Il progetto di esempio nella cartella v12 contiene un'applicazione console.

git clone https://github.com/Azure-Samples/storage-dotnet-circuit-breaker-pattern-ha-apps-using-ra-grs.git

Configurare l'esempio

Le richieste dell'applicazione all'archiviazione BLOB di Azure devono essere autorizzate. L'uso della DefaultAzureCredential classe fornita dalla Azure.Identity libreria client è l'approccio consigliato per la connessione ai servizi di Azure nel codice. L'esempio di codice .NET v12 usa questo approccio. Per altre informazioni, vedere la panoramica di DefaultAzureCredential.

È anche possibile autorizzare le richieste di Archiviazione BLOB di Azure usando la chiave di accesso dell'account. Tuttavia, questo approccio deve essere usato con cautela per proteggere le chiavi di accesso dall'esposizione.

Eseguire l'applicazione console

In Visual Studio premere F5 o selezionare Avvia per avviare il debug dell'applicazione. Visual Studio ripristina automaticamente i pacchetti NuGet mancanti se è configurato il ripristino del pacchetto. Per altre informazioni, vedere Installazione e reinstallazione dei pacchetti con il ripristino dei pacchetti.

All'avvio della finestra della console, l'app otterrà lo stato dell'area secondaria e scriverà tali informazioni nella console. L'app creerà quindi un contenitore nell'account di archiviazione e caricherà un BLOB nel contenitore. Dopo il caricamento del BLOB, l'app verificherà continuamente se il BLOB è stato replicato nell'area secondaria. Questo controllo continua fino a quando il BLOB non viene replicato oppure si raggiunge il numero massimo di iterazioni definite dalle condizioni del ciclo.

Successivamente, l'applicazione immette un ciclo con un prompt per scaricare il BLOB, inizialmente leggendo dall'archiviazione primaria. Premere un tasto qualsiasi per scaricare il BLOB. Se si verifica un errore di ripetizione della lettura dall'area primaria, viene eseguito un nuovo tentativo della richiesta di lettura sull'endpoint dell'area secondaria. L'output della console verrà visualizzato quando l'area passa a quella secondaria.

Screenshot of Console output for secondary request.

Per uscire dal ciclo e pulire le risorse, premere il Esc tasto al prompt di download del BLOB.

Informazioni sul codice di esempio

L'esempio crea un BlobServiceClient oggetto configurato con le opzioni di ripetizione dei tentativi e un endpoint dell'area secondaria. Questa configurazione consente all'applicazione di passare automaticamente all'area secondaria se la richiesta non riesce nell'endpoint dell'area primaria.

string accountName = "<YOURSTORAGEACCOUNTNAME>";
Uri primaryAccountUri = new Uri($"https://{accountName}.blob.core.windows.net/");
Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Provide the client configuration options for connecting to Azure Blob storage
BlobClientOptions blobClientOptions = new BlobClientOptions()
{
    Retry = {
        // The delay between retry attempts for a fixed approach or the delay
        // on which to base calculations for a backoff-based approach
        Delay = TimeSpan.FromSeconds(2),

        // The maximum number of retry attempts before giving up
        MaxRetries = 5,

        // The approach to use for calculating retry delays
        Mode = RetryMode.Exponential,

        // The maximum permissible delay between retry attempts
        MaxDelay = TimeSpan.FromSeconds(10)
    },

    // Secondary region endpoint
    GeoRedundantSecondaryUri = secondaryAccountUri
};

// Create a BlobServiceClient object using the configuration options above
BlobServiceClient blobServiceClient = new BlobServiceClient(primaryAccountUri, new DefaultAzureCredential(), blobClientOptions);

Quando la GeoRedundantSecondaryUri proprietà è impostata in BlobClientOptions, i tentativi per le richieste GET o HEAD passeranno all'uso dell'endpoint secondario. I tentativi successivi si alternano tra l'endpoint primario e quello secondario. Tuttavia, se lo stato della risposta dall'URI secondario è 404, i tentativi successivi per la richiesta non useranno più l'URI secondario, perché questo codice di errore indica che la risorsa non è stata replicata nell'area secondaria.

Passaggi successivi

Nella prima parte della serie è stato descritto come applicare la disponibilità elevata a un'applicazione con gli account di archiviazione RA-GZRS.

Passare alla seconda parte della serie per informazioni su come simulare un errore e forzare l'applicazione a usare l'endpoint RA-GZRS secondario.

Simulare un errore durante la lettura dall'area primaria

Risorse

Per esempi di codice correlati che usano SDK deprecati, vedere le risorse seguenti:

Condividi tramite