Tutorial: Erstellen einer hochverfügbaren Anwendung mit Blobspeicher
Dieses Tutorial ist der erste Teil einer Serie. In diesem Teil erfahren Sie, wie Sie Hochverfügbarkeit für Ihre Anwendungsdaten in Azure herstellen.
Am Ende des Tutorials verfügen Sie über eine Konsolenanwendung, die ein Blob in ein RA-GZRS-Speicherkonto (geozonenredundanter Speicher mit Lesezugriff) hochlädt und aus diesem abruft.
Georedundanz in Azure Storage repliziert Transaktionen asynchron von einer primären Region in eine sekundäre Region, die Hunderte von Kilometern entfernt ist. Dieser Replikationsprozess garantiert, dass die Daten in der sekundären Region letztendlich konsistent sind. Die Konsolenanwendung ermittelt mithilfe des Musters Trennschalter, mit welchem Endpunkt eine Verbindung hergestellt werden soll, und wechselt automatisch zwischen Endpunkten, wenn Fehler und Wiederherstellungen simuliert werden.
Wenn Sie kein Azure-Abonnement besitzen, können Sie ein kostenloses Konto erstellen, bevor Sie beginnen.
Im ersten Teil der Serie lernen Sie Folgendes:
- Speicherkonto erstellen
- Festlegen der Verbindungszeichenfolge
- Ausführen der Konsolenanwendung
Voraussetzungen
Für dieses Tutorial benötigen Sie Folgendes:
Installieren Sie Visual Studio 2022 mit der Workload Azure-Entwicklung:
Melden Sie sich auf dem Azure-Portal an.
Melden Sie sich beim Azure-Portal an.
Speicherkonto erstellen
Ein Speicherkonto stellt einen eindeutigen Namespace zum Speichern Ihrer Azure Storage-Datenobjekte sowie für den Zugriff auf diese Objekte bereit.
Führen Sie die folgenden Schritte aus, um ein geozonenredundantes Speicherkonto mit Lesezugriff (RA-GZRS) zu erstellen:
Wählen Sie im Azure-Portal die Schaltfläche Ressource erstellen aus.
Wählen Sie auf der Seite Neu die Option Speicherkonto – Blob, Datei, Tabelle, Warteschlange aus.
Füllen Sie das Speicherkontoformular wie in der Abbildung dargestellt mit den folgenden Angaben aus, und klicken Sie auf Erstellen.
Einstellung Beispielwert BESCHREIBUNG Abonnement Mein Abonnement Ausführliche Informationen zu Ihren Abonnements finden Sie unter Abonnements. ResourceGroup myResourceGroup Gültige Ressourcengruppennamen finden Sie unter Naming rules and restrictions (Benennungsregeln und Einschränkungen). Name mystorageaccount Ein eindeutiger Name für Ihr Speicherkonto Location USA, Osten Wählen Sie einen Standort aus. Leistung Standard Die Standardleistung ist eine gute Option für das Beispielszenario. Kontoart StorageV2 Es wird die Verwendung eines Speicherkontos vom Typ „Universell v2“ empfohlen. Weitere Informationen zu den Azure Storage-Kontotypen finden Sie unter Speicherkontoübersicht. Replikation Geozonenredundanter Speicher mit Lesezugriff (RA-GZRS) Die primäre Region ist zonenredundant und wird in einer sekundären Region repliziert. Lesezugriff auf die sekundäre Region ist dabei aktiviert. Zugriffsebene Heiße Ebene Verwenden Sie die heiße Ebene für häufig verwendete Daten. 
Herunterladen des Beispiels
Laden Sie das Beispielprojekt herunter, extrahieren (entpacken) Sie die Datei „storage-dotnet-circuit-breaker-pattern-ha-apps-using-ra-grs.zip“, und navigieren Sie dann zum Ordner v12 mit den Projektdateien.
Sie können auch git verwenden, um das Repository in Ihrer lokalen Entwicklungsumgebung zu klonen. Das Beispielprojekt im Ordner v12 enthält eine Konsolenanwendung.
git clone https://github.com/Azure-Samples/storage-dotnet-circuit-breaker-pattern-ha-apps-using-ra-grs.git
Das Beispiel konfigurieren
Anwendungsanforderungen an Azure Blob Storage müssen autorisiert werden. Die Verwendung der von der Clientbibliothek Azure.Identity bereitgestellten Klasse DefaultAzureCredential ist der empfohlene Ansatz zum Herstellen einer Verbindung mit Azure-Diensten in Ihrem Code. Im .NET v12-Codebeispiel wird dieser Ansatz verwendet. Weitere Informationen finden Sie in der Übersicht über DefaultAzureCredential.
Sie können Anforderungen an Azure Blob Storage auch mithilfe des Kontozugriffsschlüssels autorisieren. Dieser Ansatz sollte jedoch mit Vorsicht verwendet werden, um Zugriffsschlüssel vor der Offenlegung zu schützen.
Ausführen der Konsolenanwendung
Drücken Sie in Visual Studio F5, oder wählen Sie Starten aus, um mit dem Debuggen der Anwendung zu beginnen. Visual Studio stellt automatisch fehlende NuGet-Pakete wieder her, wenn die Paketwiederherstellung konfiguriert ist. Weitere Informationen finden Sie unter Installieren und Neuinstallieren von Paketen mit der Paketwiederherstellung.
Wenn das Konsolenfenster gestartet wird, erhält die App den Status der sekundären Region und gibt diese Informationen in der Konsole aus. Anschließend erstellt die App einen Container im Speicherkonto und lädt ein Blob in den Container hoch. Sobald das Blob hochgeladen wurde, überprüft die App kontinuierlich, ob das Blob in der sekundären Region repliziert wurde. Diese Überprüfung wird fortgesetzt, bis das Blob repliziert oder die maximale Anzahl von Iterationen gemäß der Schleifenbedingungen erreicht wird.
Als Nächstes wechselt die Anwendung in eine Schleife mit der Eingabeaufforderung, das Blob herunterzuladen. Dabei wird zunächst aus dem primären Speicher gelesen. Drücken Sie eine beliebige Taste, um das Blob herunterzuladen. Wenn ein wiederholbarer Fehler beim Lesen aus der primären Region auftritt, wird eine Wiederholung der Leseanforderung für den Endpunkt der sekundären Region ausgeführt. In der Konsolenausgabe wird angezeigt, wenn die Region zur sekundären Region wechselt.
Um die Schleife zu beenden und Ressourcen zu bereinigen, drücken Sie die Taste Esc an der Eingabeaufforderung zum Blobdownload.
Grundlagen des Beispielcodes
Das Beispiel erstellt ein BlobServiceClient-Objekt, das mit Optionen für Wiederholungsversuche und einem Endpunkt der sekundären Region konfiguriert ist. Mit dieser Konfiguration kann die Anwendung automatisch zur sekundären Region wechseln, wenn die Anforderung für den Endpunkt der primären Region fehlschlägt.
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);
Wenn die Eigenschaft GeoRedundantSecondaryUri in BlobClientOptions festgelegt ist, wird bei Wiederholungsversuchen für GET- oder HEAD-Anforderungen zur Verwendung des sekundären Endpunkts gewechselt. Nachfolgende Wiederholungen wechseln zwischen dem primären und sekundären Endpunkt. Wenn der Status der Antwort vom sekundären URI jedoch 404 lautet, verwenden nachfolgende Wiederholungen für die Anforderung nicht mehr den sekundären URI, da dieser Fehlercode angibt, dass die Ressource nicht in der sekundären Region repliziert wurde.
Nächste Schritte
Im ersten Teil dieser Reihe haben Sie erfahren, wie Sie mit RA-GZRS-Speicherkonten Hochverfügbarkeit für eine Anwendung herstellen.
Im zweiten Teil der Reihe erfahren Sie, wie Sie einen Fehler simulieren, durch den Ihre Anwendung auf den sekundären RA-GZRS-Endpunkt ausweichen muss.