Freigeben über

Verstehen und Optimieren der Leistung von Azure-Dateifreigaben

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 können, und es wird beschrieben, wie Sie die Leistung von Azure-Dateifreigaben für Ihre Workload optimieren können.

Gilt für:

Verwaltungsmodell Abrechnungsmodell Medienebene Redundanz KMU NFS (falls abgekürzt von Network File System gemeint)
Microsoft.Storage Bereitgestellt v2 HDD (Standard) Lokal (LRS) Ja Nein
Microsoft.Storage Bereitgestellt v2 HDD (Standard) Zone (ZRS) Ja Nein
Microsoft.Storage Bereitgestellt v2 HDD (Standard) Geo (GRS) Ja Nein
Microsoft.Storage Bereitgestellt v2 HDD (Standard) GeoZone (GZRS) Ja Nein
Microsoft.Storage Bereitgestellt v1 SSD (Premium) Lokal (LRS) Ja Ja
Microsoft.Storage Bereitgestellt v1 SSD (Premium) Zone (ZRS) Ja Ja
Microsoft.Storage Nutzungsbasierte Bezahlung HDD (Standard) Lokal (LRS) Ja Nein
Microsoft.Storage Nutzungsbasierte Bezahlung HDD (Standard) Zone (ZRS) Ja Nein
Microsoft.Storage Nutzungsbasierte Bezahlung HDD (Standard) Geo (GRS) Ja Nein
Microsoft.Storage Nutzungsbasierte Bezahlung HDD (Standard) GeoZone (GZRS) Ja Nein

Glossar

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. Der Begriff "IO" ist austauschbar mit den Begriffen "Operation" und "Transaction" in der Azure Files-Dokumentation.

  • 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 E/A-Größe = 10 GiB/s, während 10.000 IOPS * 4 KiB E/A-Größe = 38 MiB/s ergeben.

  • 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 der Dateifreigabe auf Speicherkontoebene aus, und nachdem Sie ein Speicherkonto in einer bestimmten Medienebene erstellt haben, können Sie nicht zur anderen wechseln, ohne manuell zu einer neuen Dateifreigabe zu migrieren.

Bei der Auswahl zwischen SSD- und HDD-Dateifreigaben ist es wichtig, die Anforderungen des erwarteten Verwendungsmusters zu verstehen, das Sie für die Ausführung auf Azure Files planen. Wenn Sie große Mengen an IOPS, schnelle Datenübertragungsgeschwindigkeiten oder geringe Latenz benötigen, sollten Sie SSD-Dateifreigaben auswählen.

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.

Nutzungsmusteranforderungen SSD HDD
Schreiblatenz (im einstelligen Millisekundenbereich) Ja Ja
Leselatenz (im einstelligen Millisekundenbereich) Ja Nein

SSD-Dateifreigaben bieten ein Bereitstellungsmodell, das folgendes Leistungsprofil basierend auf der Freigabegröße garantiert. Weitere Informationen finden Sie unter bereitgestelltes V1-Modell.

Prüfliste für die Leistung

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 häufig von Endbenutzern gesehen oder genutzt werden, eignen sich besser für SSD-Dateifreigaben, da diese eine Latenz von nur wenigen Millisekunden für Lese- und Schreibvorgänge ermöglichen können (2 ms für kleine 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 Dateifreigaben.

  • Dauer und Häufigkeit der Arbeitsauslastung: Kurze (Minuten) und seltene (stündliche) Workloads sind weniger wahrscheinlich, die oberen Leistungsgrenzwerte von HDD-Dateifreigaben im Vergleich zu lang ausgeführten, häufig auftretenden Workloads zu erreichen. Bei SSD-Dateifreigaben ist die Dauer des Workloads hilfreich, um das passende Leistungsprofil basierend auf dem bereitgestellten Speicher, den IOPS und dem Durchsatz zu bestimmen. Ein häufiger Fehler besteht darin, Leistungstests nur für einige Minuten auszuführen, was häufig 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 Leistung der SMB Azure-Dateifreigabe.

  • API-Vorgangsverteilung: Umfangreiche Metadaten-Workloads, z. B. Workloads, die Lesevorgänge in einer großen Anzahl von Dateien ausführen, eignen sich besser für SSD-Dateifreigaben. Weitere Informationen finden Sie unter Hohe Workload für Metadaten oder Namespaces.

Latenz

Wenn Sie über Latenz nachdenken, ist es wichtig, zunächst zu verstehen, wie Latenz mit Azure Files bestimmt wird. Die häufigsten Messwerte sind die Latenzmetriken im Zusammenhang mit End-to-End-Latenz und Dienstlatenz. Die Verwendung dieser Transaktionsmetriken kann dabei helfen, clientseitige Latenz und/oder Netzwerkprobleme zu identifizieren, indem bestimmt wird, wie viel Zeit Ihr Anwendungsdatenverkehr für die Übertragung zum und vom Client aufwendet.

  • 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 benötigt wird, damit eine Transaktion ausschließlich innerhalb von Azure Files hin und zurück gesendet wird. Dies schließt keine Client- oder Netzwerklatenz ein.

    Abbildung: Vergleich von Clientlatenz und Dienstlatenz für Azure Files.

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 die Dienstlatenz z. B. eine niedrige Latenz und der End-to-End-Wert eine sehr hohe Latenz für Anforderungen angibt, deutet dies darauf hin, dass die gesamte Zeit für die Übertragung zum und vom Client und nicht für den Azure Files-Dienst aufgewendet wird.

Darüber hinaus, wie das Diagramm zeigt, je weiter Sie vom Dienst entfernt sind, desto langsamer ist die Latenzerfahrung und desto schwieriger ist es, Leistungsskalierungsgrenzwerte mit jedem Clouddienst zu erreichen. Dies gilt insbesondere, wenn lokal auf Azure Files zugegriffen wird. Optionen wie ExpressRoute sind zwar ideal für lokale Umgebungen geeignet, erreichen aber nicht die Leistung einer Anwendung (Compute und Speicher), die ausschließlich in derselben Azure-Region ausgeführt wird.

Tipp

Die Verwendung einer VM in Azure zum Testen der Leistung zwischen der lokalen Umgebung und Azure ist eine effektive und praktische Möglichkeit, um eine Baseline für die Netzwerkfunktionen der Verbindung mit Azure zu ermitteln. Untergeordnete oder falsch weitergeleitete ExpressRoute-Schaltkreise oder VPN-Gateways können Workloads, die auf Azure Files ausgeführt werden, erheblich verlangsamen.

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) entwickelt haben, wird nun auch eine größere Warteschlangentiefe unterstützt. 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 großen Stil konzipiert ist, empfiehlt es sich, Workloads mit großer Warteschlangentiefe zu erstellen und zu testen.

Eine große Warteschlangentiefe kann auf verschiedene Arten in Kombination mit Clients, Dateien und Threads erreicht werden. Um die Warteschlangentiefe für Ihre Workload zu bestimmen, multiplizieren Sie die Anzahl der Clients mit der Anzahl der Dateien sowie mit der Anzahl der Threads (Clients * Dateien * Threads = Warteschlangentiefe).

Die folgende Tabelle veranschaulicht die verschiedenen Kombinationen, die Sie verwenden können, um eine größere Warteschlangentiefe zu erreichen. Auch wenn Sie die optimale Warteschlangentiefe von 64 überschreiten können, wird dies nicht empfohlen. Wenn Sie so vorgehen, erreichen Sie keine weiteren Leistungssteigerungen, und Sie riskieren, die Latenz aufgrund von TCP-Sättigung zu erhöhen.

Klienten Dateien Fäden Warteschlangenlänge
1 1 1 1
1 1 2 2
1 2 2 4
2 2 2 8
2 2 4 16
2 4 4 32
1 8 8 64
4 4 2 64

Tipp

Um Leistungsobergrenzen zu erreichen, stellen Sie sicher, dass Ihr Workload- oder Benchmarktest mehrere Threads mit mehreren Dateien verwendet.

Einzelthread- im Vergleich zu Multithreadanwendungen

Azure Files eignet sich am besten für Multithreadanwendungen. Die einfachste Möglichkeit, die Leistungsauswirkungen zu verstehen, die Multithreading auf eine Workload besitzt, besteht darin, das Szenario anhand von E/A zu durchlaufen. Im folgenden Beispiel wird eine Workload verwendet, die 10.000 kleine Dateien so schnell wie möglich in eine 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.

E/A-Vorgang Erstellen 4 KiB-Schreibvorgang 4 KiB-Schreibvorgang 4 KiB-Schreibvorgang 4 KiB-Schreibvorgang Schließen Gesamt
Thread 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

In diesem Beispiel würde es ungefähr 14 ms dauern, eine einzelne 16-KiB-Datei aus den sechs Vorgängen zu erstellen. Wenn eine Einzelthreadanwendung 10.000 Dateien auf eine Azure-Dateifreigabe verschieben möchte, entspricht dies 140.000 ms (14 ms * 10.000) oder 140 Sekunden, da die einzelnen Dateien sequentiell nacheinander verschoben werden. Denken Sie daran, dass die Zeit für die Verarbeitung der einzelnen Anforderungen in erster Linie davon abhängt, wie nahe die Compute- und Speicherressourcen beieinander liegen, wie im vorherigen Abschnitt erläutert.

Durch die Verwendung von acht Threads anstatt eines Threads kann die oben genannte Workload von 140.000 ms (140 Sekunden) auf 17.500 ms (17,5 Sekunden) reduziert werden. Wie die nachstehende Tabelle zeigt, können Sie die gleiche Datenmenge in 87,5 % weniger Zeit verschieben, wenn Sie acht Dateien parallel verschieben, anstatt eine Datei nach der anderen.

E/A-Vorgang Erstellen 4 KiB-Schreibvorgang 4 KiB-Schreibvorgang 4 KiB-Schreibvorgang 4 KiB-Schreibvorgang Schließen Gesamt
Thread 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 2 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 3 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 4 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 5 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 6 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 7 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 8 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Siehe auch