Tutoriel : Générer une application hautement disponible avec le stockage Blob
Ce tutoriel est la première partie d’une série d’étapes. Il vous apprend à rendre vos données d’application hautement disponibles dans Azure.
À l’issue de ce tutoriel, vous disposez d’une application console qui charge et récupère un objet blob à partir d’un compte de stockage géoredondant interzone avec accès en lecture (RA-GZRS).
La géo-redondance dans le stockage Azure réplique les transactions de manière asynchrone d’une région primaire vers une région secondaire se trouvant à des centaines de kilomètres. Ce processus de réplication garantit que les données de la région secondaire sont cohérentes. L’application de console utilise le modèle Disjoncteur pour déterminer à quel point de terminaison se connecter, en basculant automatiquement d’un point de terminaison à l’autre au fur et à mesure des simulations d’échecs et de récupérations.
Si vous ne disposez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
Dans ce premier volet, vous apprenez à :
- Créez un compte de stockage.
- Définir la chaîne de connexion
- Exécuter l’application console
Prérequis
Pour suivre ce tutoriel :
Installez Visual Studio 2022 avec la charge de travail Développement Azure.
Connectez-vous au portail Azure.
Connectez-vous au portail Azure.
Créez un compte de stockage.
Un compte de stockage fournit un espace de noms unique pour stocker les objets de données de Stockage Azure et y accéder.
Suivez ces étapes pour créer un compte de stockage géoredondant interzone (RA-GZRS) avec accès en lecture :
Sélectionnez le bouton Créer une ressource dans le portail Azure.
Sélectionnez Compte de stockage - blob, fichier, table, file d’attente sur la page Nouveau.
Remplissez le formulaire de compte de stockage avec les informations suivantes, comme indiqué dans l’image ci-après et sélectionnez Créer :
Paramètre Exemple de valeur Description Abonnement Mon abonnement Pour plus d’informations sur vos abonnements, consultez Abonnements. ResourceGroup myResourceGroup Pour les noms de groupe de ressources valides, consultez Naming conventions (Conventions d’affectation de nom). Nom mystorageaccount Un nom unique pour votre compte de stockage. Lieu USA Est Choisissez un emplacement. Performances Standard Les performances Standard sont une bonne option pour l’exemple de scénario. Type de compte StorageV2 Il est recommandé d’utiliser un compte de stockage v2 à usage général. Pour plus d’informations sur les types de comptes de stockage Azure, consultez Vue d’ensemble des comptes de stockage Azure. Réplication Stockage géo-redondant interzone avec accès en lecture (RA-GRS) La région primaire est redondante dans une zone et est répliquée vers une région secondaire, avec accès en lecture à la région secondaire activée. Niveau d’accès Chaud Utilisez le niveau de stockage chaud pour les données fréquemment consultées. 
Télécharger l’exemple
Téléchargez l’exemple de projet, extrayez (décompressez) le fichier storage-dotnet-circuit-breaker-pattern-ha-apps-using-ra-grs.zip, puis accédez au dossier v12 pour rechercher les fichiers projet.
Vous pouvez également utiliser git pour cloner le référentiel dans votre environnement de développement local. L’exemple de projet dans le dossier v12 contient une application console.
git clone https://github.com/Azure-Samples/storage-dotnet-circuit-breaker-pattern-ha-apps-using-ra-grs.git
Configurer l'exemple
Les demandes d’application adressées au Stockage Blob Azure doivent être autorisées. L’utilisation de la classe DefaultAzureCredential fournie par la bibliothèque cliente Azure.Identity est l’approche recommandée pour la connexion aux services Azure dans votre code. L’exemple de code .NET v12 utilise cette approche. Pour en savoir plus, consultez la Vue d’ensemble de DefaultAzureCredential.
Vous pouvez également autoriser les requêtes à Stockage Blob Azure à l’aide de la clé d’accès au compte. Toutefois, cette approche doit être utilisée avec précaution pour protéger les clés d’accès contre l’exposition.
Exécuter l’application console
Dans Visual Studio, appuyez sur F5 ou sélectionnez Démarrer pour commencer le débogage de l’application. Visual Studio restaure automatiquement les packages NuGet manquants si la restauration de package est configurée. Consultez Installation et réinstallation de packages avec la restauration de package pour en savoir plus.
Lorsque la fenêtre de console démarre, l’application obtient l’état de la région secondaire et écrit ces informations dans la console. Ensuite, l’application crée un conteneur dans le compte de stockage et charge un objet blob dans le conteneur. Une fois l’objet blob chargé, l’application vérifie en permanence si l’objet blob a été répliqué dans la région secondaire. Cette vérification se poursuit jusqu’à ce que l’objet blob soit répliqué, ou que nous atteignions le nombre maximal d’itérations définies par les conditions de boucle.
Ensuite, l’application entre dans une boucle avec une invite pour télécharger l’objet blob, en lisant initialement à partir du stockage principal. Appuyez sur n’importe quelle touche pour télécharger l’objet blob. S’il existe une erreur avec nouvelle tentative possible à partir de la région primaire, une nouvelle tentative de la demande de lecture est effectuée sur le point de terminaison de la région secondaire. La sortie de la console s’affiche lorsque la région bascule vers la région secondaire.
Pour quitter la boucle et nettoyer les ressources, appuyez sur la touche Esc à l’invite de téléchargement de l’objet blob.
Comprendre l’exemple de code
L’exemple crée un objet BlobServiceClient configuré avec des options de nouvelle tentative et un point de terminaison régional secondaire. Cette configuration permet à l’application de basculer automatiquement vers la région secondaire si la requête échoue sur le point de terminaison de la région primaire.
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);
Lorsque la propriété GeoRedundantSecondaryUri est définie dans BlobClientOptions, les nouvelles tentatives pour les requêtes GET ou HEAD basculent pour utiliser le point de terminaison secondaire. Les nouvelles tentatives suivantes alternent entre les points de terminaison principal et secondaire. Toutefois, si l’état de la réponse de l’URI secondaire est 404, les nouvelles tentatives suivantes pour la requête n’utilisent plus l’URI secondaire, car ce code d’erreur indique que la ressource n’a pas été répliquée dans la région secondaire.
Étapes suivantes
Dans la première partie de la série, vous avez appris à rendre une application hautement disponible avec des comptes de stockage RA-GZRS.
Passez à la deuxième partie de la série pour apprendre à simuler un échec et à forcer votre application à utiliser le point de terminaison RA-GZRS secondaire.