Verstehen und Optimieren der Leistung von Azure-Dateifreigaben

✔️ Gilt für: Klassische SMB- und NFS-Dateifreigaben, die mit dem Microsoft.Storage-Ressourcenanbieter erstellt wurden

✔️ Gilt für: Dateifreigaben, die mit dem Microsoft.FileShares-Ressourcenanbieter erstellt wurden

Azure Files kann Leistungsanforderungen für die meisten Anwendungen und Anwendungsfälle erfüllen. In diesem Artikel werden die verschiedenen Faktoren erläutert, die sich auf die Leistung von Dateifreigaben auswirken, und es wird beschrieben, wie Sie die Leistung von Azure Files für Ihre Workloads optimieren können.

Glossar zur Speicherleistung

Bevor Sie diesen Artikel lesen, ist es hilfreich, einige wichtige Begriffe im Zusammenhang mit der Speicherleistung zu verstehen:

• E/A-Vorgänge pro Sekunde (IOPS)

  „IOPS“ oder „Eingabe-/Ausgabevorgänge pro Sekunde“ misst die Anzahl von Dateisystemvorgängen pro Sekunde. In der Azure Files Dokumentation ist der Begriff "IO" mit den Begriffen "Operation" und "transaction" austauschbar.

• E/A-Größe

  Die E/A-Größe, manchmal auch als Blockgröße bezeichnet, ist die Größe der Anforderung, die eine Anwendung zum Ausführen eines einzelnen Eingabe-/Ausgabevorgangs (E/A-Vorgang) für den Speicher verwendet. Je nach Anwendung kann die E/A-Größe von kleinen Größen wie 4 KiB bis zu größeren Größen reichen. Die E/A-Größe spielt eine wichtige Rolle für den erreichbaren Durchsatz.

• Durchsatz

  Der Durchsatz misst die Anzahl der Bits, die pro Sekunde aus dem Speicher gelesen oder in den Speicher geschrieben werden, und wird in Mebibytes pro Sekunde (MiB/s) gemessen. Um den Durchsatz zu berechnen, multiplizieren Sie den IOPS-Wert mit der E/A-Größe. Beispiel: 10.000 IOPS × 1 MiB I/O-Größe = 10 GiB/s, während 10.000 IOPS × 4 KiB-E/A-Größe = 38 MiB/s.

• Latenz

  Latenz ist ein Synonym für Verzögerung und wird in Millisekunden (ms) gemessen. Es gibt zwei Arten von Latenz: End-to-End-Latenz und Dienstlatenz. Weitere Informationen finden Sie unter Latenz.

• Warteschlangenlänge

  Warteschlangentiefe ist die Anzahl der ausstehenden E/A-Anforderungen, die eine Speicherressource gleichzeitig verarbeiten kann. Weitere Informationen finden Sie unter Warteschlangentiefe.

Auswählen einer Medienebene basierend auf Verwendungsmustern

Azure Files bietet zwei Speichermedienebenen, mit denen Sie die Leistung und den Preis ausgleichen können: SSD und HDD. Sie wählen die Medienebene für die Dateifreigabe auf Speicherkontoebene aus. Nachdem Sie ein Speicherkonto auf einer bestimmten Medienebene erstellt haben, können Sie nicht zur anderen Medienebene wechseln, ohne manuell zu einer neuen Dateifreigabe zu migrieren.

Wenn Sie zwischen SSD- und HDD-Dateifreigaben wählen, sollten Sie die Anforderungen des erwarteten Verwendungsmusters berücksichtigen, das Sie für Azure Files ausführen möchten. Wenn Sie große Mengen an IOPS, schnelle Datenübertragungsgeschwindigkeiten oder geringe Latenz benötigen, wählen Sie SSD-Dateifreigaben aus.

In der folgenden Tabelle sind die erwarteten Leistungsziele zwischen SSD- und HDD-Dateifreigaben zusammengefasst. Weitere Informationen finden Sie unter Skalierbarkeits- und Leistungsziele für Azure Files.

SSD-Dateifreigaben verwenden ein Provisionierungsmodell, das abhängig von der Größe der Freigabe das folgende Leistungsprofil garantiert. Weitere Informationen finden Sie unter bereitgestelltes V1-Modell.

Bewährte Verfahren für Leistungsoptimierung

Ganz gleich, ob Sie die Leistungsanforderungen für eine neue oder vorhandene Arbeitslast bewerten, indem Sie Ihre Nutzungsmuster verstehen, können Sie eine vorhersehbare Leistung sicherstellen.

• Latenzempfindlichkeit: Workloads, die empfindlich auf Leselatenz reagieren und für Endbenutzer besonders sichtbar sind, eignen sich besser für SSD-Dateifreigaben, die sowohl für Lese- als auch für Schreibvorgänge eine Latenz im einstelligen Millisekundenbereich bieten können (weniger als 2 ms bei kleinen E/A-Größen).

• IOPS- und Durchsatzanforderungen: SSD-Dateifreigaben unterstützen größere IOPS- und Durchsatzgrenzwerte als HDD-Dateifreigaben. Weitere Informationen finden Sie unter Skalierungsziele für die Dateifreigabe.

• Dauer und Häufigkeit von Workloads: Kurze (Minuten) und seltene (stündliche) Workloads stoßen mit geringerer Wahrscheinlichkeit an die oberen Leistungsgrenzen von HDD-Dateifreigaben als lang andauernde, häufig auftretende Workloads. Bei SSD-Dateifreigaben hilft die Workload-Dauer dabei, das richtige Leistungsprofil zu ermitteln, das basierend auf dem bereitgestellten Speicher, IOPS und Durchsatz verwendet werden soll. Ein häufiger Fehler ist das Ausführen von Leistungstests nur für ein paar Minuten, was oft irreführend ist. Um ein realistisches Bild der Leistung zu erhalten, sollten Sie mit einer ausreichend hohen Häufigkeit und Dauer testen.

• Workload-Parallelisierung: Für Workloads, die Vorgänge parallel ausführen, z. B. durch mehrere Threads, Prozesse oder Anwendungsinstanzen auf demselben Client, bieten SSD-Dateifreigaben einen klaren Vorteil gegenüber HDD-Dateifreigaben: SMB Multichannel. Weitere Informationen finden Sie unter Verbessern der SMB-Azure Leistung der Dateifreigabe.

• Verteilung der API-Operationen: Metadatenintensive Workloads, etwa Workloads, die Lesevorgänge für eine große Zahl von Dateien durchführen, sind besser für SSD-Dateifreigaben geeignet. Weitere Informationen finden Sie unter "Metadaten" oder "Namespace heavy workload".

• Zonenplatzierung: Verwenden Sie die Zonenplatzierung, um die spezifische Verfügbarkeitszone auszuwählen, in der sich Ihr Speicherkonto befindet. Mit diesem Feature können Sie Ihre virtuellen Computer in derselben Verfügbarkeitszone wie Ihr Speicher platzieren, wodurch die Latenz um bis zu 30 Prozent reduziert werden kann. Dieses Feature ist derzeit nur für SSD-Speicherkonten verfügbar, die lokal redundanten Speicher (LRS) in unterstützten Regionen verwenden.

Latenz

Wenn Sie sich die Latenz überlegen, verstehen Sie zunächst, wie Azure Files die Latenz bestimmt. Die häufigsten Messwerte sind die Latenzmetriken im Zusammenhang mit End-to-End-Latenz und Dienstlatenz. Mithilfe dieser Transaktionsmetriken können Sie clientseitige Latenz- und Netzwerkprobleme ermitteln, indem Sie zeigen, wie viel Zeit ihr Anwendungsdatenverkehr während der Übertragung auf und vom Client verbringt.

• End-to-End-Latenz (SuccessE2ELatency) ist die Gesamtdauer, die eine Transaktion benötigt, um einen vollständigen Roundtrip vom Client über das Netzwerk zum Azure Files-Dienst und zurück zum Client durchzuführen.

• Die Dienstlatenz (SuccessServerLatency) ist die Zeit, die eine Transaktion für einen Hin- und Rückweg ausschließlich innerhalb von Azure Files benötigt. Diese Messung enthält keine Client- oder Netzwerklatenz.

  

Der Unterschied zwischen SuccessE2ELatency- und SuccessServerLatency-Werten ist die Latenz, die wahrscheinlich durch das Netzwerk und/oder den Client verursacht wird.

Es ist üblich, Clientlatenz mit Dienstlatenz zu verwechseln (in diesem Fall Azure Files-Leistung). Wenn z. B. für die Dienstlatenz eine niedrige Latenz und für die End-to-End-Latenz eine sehr hohe Latenz bei Anforderungen gemeldet wird, entfällt die gesamte Zeit auf die Übertragung zum und vom Client und nicht auf den Azure Files-Dienst.

Darüber hinaus ist, wie das Diagramm veranschaulicht, je weiter Sie vom Dienst entfernt sind, desto langsamer ist die Latenzerfahrung und desto schwieriger ist es, Leistungsskalierungsgrenzwerte mit jedem Clouddienst zu erreichen. Diese Bedingung gilt insbesondere für den Zugriff auf Azure Files von der lokalen Bereitstellung. Optionen wie Azure ExpressRoute eignen sich zwar ideal für lokale Bereitstellungen, stimmen aber trotzdem nicht mit der Leistung einer Anwendung (Compute + Speicher) überein, die ausschließlich in derselben Azure Region ausgeführt wird.

Warteschlangenlänge

Die Warteschlangentiefe ist die Anzahl der ausstehenden E/A-Anforderungen, die eine Speicherressource verarbeiten kann. Da sich die von Speichersystemen verwendeten Datenträger von HDD-Spindeln (IDE, SATA, SAS) zu Solid-State-Geräten (SSD, NVMe) entwickelten, entwickelten sie sich auch zur Unterstützung einer höheren Warteschlangentiefe. Eine Workload, die aus einem einzelnen Client besteht, der seriell mit einer einzelnen Datei innerhalb eines großen Datasets interagiert, ist ein Beispiel für eine geringe Warteschlangentiefe. Im Gegensatz dazu kann eine Workload, die Parallelität mit mehreren Threads und mehreren Dateien unterstützt, problemlos eine große Warteschlangentiefe erzielen. Da Azure Files ein verteilter Dateidienst ist, der tausende von Azure Clusterknoten umfasst und für die Ausführung von Workloads im Maßstab konzipiert ist, erstellen und testen Sie Workloads mit hoher Warteschlangentiefe.

Sie können eine hohe Warteschlangentiefe auf verschiedene Arten erreichen. Um die Warteschlangentiefe für Ihre Workload zu ermitteln, multiplizieren Sie die Anzahl der Clients mit der Anzahl der Dateien mit der Anzahl der Threads (Clients × Dateien × Threads = Warteschlangentiefe).

In der folgenden Tabelle sind die verschiedenen Kombinationen dargestellt, die Sie verwenden können, um eine höhere Warteschlangentiefe zu erzielen. Sie können zwar die optimale Warteschlangentiefe von 64 überschreiten, es wird jedoch nicht empfohlen. Wenn Sie so vorgehen, erreichen Sie keine weiteren Leistungssteigerungen, und Sie riskieren, die Latenz aufgrund von TCP-Sättigung zu erhöhen.

Einzelthread- und Multithreadanwendungen

Azure Files funktioniert am besten mit Multithread-Anwendungen. Die einfachste Möglichkeit, die Auswirkungen von Multithreading auf die Leistung einer Arbeitslast zu verstehen, besteht darin, das Szenario anhand der E/A Schritt für Schritt nachzuvollziehen. Im folgenden Beispiel haben Sie einen Workload, der 10.000 kleine Dateien so schnell wie möglich in eine Azure-Dateifreigabe oder aus einer Azure-Dateifreigabe kopieren muss.

In dieser Tabelle wird die erforderliche Zeit (in Millisekunden) zum Erstellen einer einzelnen 16-KiB-Datei auf einer Azure-Dateifreigabe anhand einer Einzelthreadanwendung aufschlüsselt, die in 4 KiB-Blockgrößen schreibt.

In diesem Beispiel dauert es ungefähr 14 ms, um eine einzelne 16 KiB-Datei aus den sechs Vorgängen zu erstellen. Wenn eine Singlethread-Anwendung 10.000 Dateien in eine Azure-Dateifreigabe verschieben möchte, entspricht dies 140.000 ms (14 ms × 10.000) bzw. 140 Sekunden, weil die Dateien sequenziell, also einzeln nacheinander, verschoben werden. Die Zeit zum Warten jeder Anforderung wird in erster Linie durch die Nähe der Berechnung und des Speichers bestimmt, wie im vorherigen Abschnitt erläutert.

Wenn Sie acht Threads anstelle eines Threads verwenden, können Sie die vorhergehende Arbeitsauslastung von 140.000 ms (140 Sekunden) auf 17.500 ms (17,5 Sekunden) reduzieren. Wie in der folgenden Tabelle dargestellt, können Sie, wenn Sie acht Dateien parallel anstelle einer Datei gleichzeitig verschieben, die gleiche Datenmenge in 87,5% weniger Zeit verschieben.

Weitere Informationen

• Problembehandlung bei Leistungsproblemen mit Azure-Dateifreigaben
• Überwachen von Azure Files
• Planung für eine Azure Files-Bereitstellung
• Grundlegendes zur Abrechnung für Azure Files
• Azure Files – Preise