Freigeben über

Verstehen und Optimieren der Leistung von Azure-Dateifreigaben

  • Artikel

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:

Dateifreigabetyp SMB NFS
Standard-Dateifreigaben (GPv2), LRS/ZRS Ja Nein
Standard-Dateifreigaben (GPv2), GRS/GZRS Ja Nein
Premium-Dateifreigaben (FileStorage), LRS/ZRS Ja Ja

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 „E/A“ ist in der Azure Files-Dokumentation austauschbar mit den Begriffen „Vorgang“ und „Transaktion“.

  • 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 sehr kleinen Größen wie 4 KiB bis zu deutlich 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 (Wartezeit) ist ein Synonym für Verzögerung und wird normalerweise 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 Leistungsstufe basierend auf Nutzungsmustern

Azure Files bietet eine Reihe von Speicherebenen, mit denen Sie Kosten senken können, indem Sie Daten mit dem entsprechenden Leistungs- und Preisniveau speichern. Azure Files bietet auf der höchsten Ebene zwei Leistungsstufen: Standard und Premium. Standard-Dateifreigaben werden in einem Speichersystem gehostet, das durch Festplattenlaufwerke (HDD) unterstützt wird, während Premium-Dateifreigaben durch Solid-State-Laufwerke (SSD) unterstützt werden, um eine bessere Leistung zu erzielen. Standard-Dateifreigaben verfügen über mehrere Speicherebenen (transaktionsoptimiert, heiße und kalte Ebene), zwischen denen Sie nahtlos wechseln können, um den Speicher für ruhende Daten zu maximieren und Transaktionspreise zu optimieren. Sie können jedoch nicht zwischen Standard- und Premium-Tarifen wechseln, ohne Ihre Daten physisch zwischen verschiedenen Speicherkonten zu migrieren.

Bei der Wahl zwischen Standard- und Premium-Dateifreigaben ist es wichtig, die Anforderungen des erwarteten Nutzungsmusters zu verstehen, das Sie in Azure Files ausführen möchten. Wenn Sie große IOPS-Mengen, extrem schnelle Datenübertragungsgeschwindigkeiten oder eine sehr niedrige Latenz benötigen, sollten Sie Azure Premium-Dateifreigaben auswählen.

In der folgenden Tabelle werden die erwarteten Leistungsziele für Standard und Premium zusammengefasst. Weitere Informationen finden Sie unter Skalierbarkeits- und Leistungsziele für Azure Files.

Nutzungsmusteranforderungen Standard Premium
Schreiblatenz (im einstelligen Millisekundenbereich) Ja Ja
Leselatenz (im einstelligen Millisekundenbereich) Nein Ja

Premium-Dateifreigaben bieten ein Bereitstellungsmodell, das das folgende Leistungsprofil basierend auf der Freigabegröße garantiert. Weitere Informationen finden Sie unter Bereitgestelltes Modell. Burstguthaben sammeln sich in einem Burstbucket an, wenn Datenverkehr für Ihre Dateifreigabe unterhalb der IOPS-Baseline liegt. Erworbene Guthaben werden später genutzt, um Bursting zu ermöglichen, wenn Vorgänge die IOPS-Baseline überschreiten würden.

Kapazität (GiB) IOPS-Grundwert Burst-IOPS Burstguthaben Durchsatz (Eingang und Ausgang)
100 3.100 Bis zu 10.000 24.840.000 110 MiB/s
500 3\.500 Bis zu 10.000 23.400.000 150 MiB/s
1\.024 4.024 Bis zu 10.000 21.513.600 203 MiB/s
5\.120 8.120 Bis zu 15.360 26.064.000 613 MiB/s
10.240 13.240 Bis zu 30.720 62.928.000 1.125 MiB/s
33.792 36.792 Bis zu 100.000 227.548.800 3.480 MiB/s
51.200 54.200 Bis zu 100.000 164.880.000 5.220 MiB/s
102.400 100.000 Bis zu 100.000 0 10.340 MiB/s

Prüfliste für die Leistung

Unabhängig davon, ob Sie Leistungsanforderungen für eine neue oder eine vorhandene Workload bewerten, hilft Ihnen das Verständnis Ihrer Nutzungsmuster, eine vorhersagbare Leistung zu erzielen. Wenden Sie sich an Ihren Speicheradministrator oder den Anwendungsentwickler, um die folgenden Nutzungsmuster zu ermitteln.

  • Latenzempfindlichkeit: Öffnen Benutzer Dateien oder interagieren mit virtuellen Desktops, die in Azure Files ausgeführt werden? Dies sind Beispiele für Workloads, die empfindlich auf Leselatenz reagieren und auch hohe Sichtbarkeit für Endbenutzer aufweisen. Diese Arten von Workloads eignen sich besser für Azure Premium-Dateifreigaben, die Latenz im Bereich von einer Millisekunde für Lese- und Schreibvorgänge bieten können (< 2 ms bei einer kleinen E/A-Größe).

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

  • Dauer und Häufigkeit von Workloads: Bei kurzen (Minuten) und unregelmäßigen (stündlichen) Workloads ist die Wahrscheinlichkeit geringer, dass die oberen Leistungsgrenzen von Standard-Dateifreigaben erreicht werden, als bei regelmäßig auftretenden Workloads mit langer Ausführungsdauer. Bei Premium-Dateifreigaben ist die Workloaddauer hilfreich, wenn das richtige Leistungsprofil basierend auf der Bereitstellungsgröße bestimmt wird. Je nachdem, wie lange die Workload Bursting ausführen muss und wie lange sie unterhalb den Baseline-IOPS verbleibt, können Sie feststellen, ob Sie genügend Burstingguthaben ansammeln, um Ihre Workload zu Spitzenzeiten konsistent zu bewältigen. Wenn Sie das richtige Gleichgewicht finden, können Sie die Kosten im Vergleich zu einer übermäßigen Bereitstellung der Dateifreigabe senken. 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.

  • Workloadparallelisierung: Bei Workloads, die Parallelvorgänge durchführen, z. B. über mehrere Threads, Prozesse oder Anwendungsinstanzen auf demselben Client, bieten Premium-Dateifreigaben einen eindeutigen Vorteil gegenüber Standarddateifreigaben: SMB Multichannel. Weitere Informationen finden Sie unter Verbessern der Leistung der SMB Azure-Dateifreigabe.

  • API-Vorgangsverteilung: Sind die Workloadmetadaten bei Vorgängen zum Öffnen bzw. Schließen von Dateien umfangreich? Dies ist üblich bei Workloads, die Lesevorgänge für eine große Menge von Dateien ausführen. Weitere Informationen finden Sie unter Hohe Workload für Metadaten oder Namespaces.

Latency

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.

  • Dienstlatenz (SuccessServerLatency) ist die Zeit, die eine Transaktion nur innerhalb des Azure Files-Diensts für den Roundtrip benötigt. 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.

Wie die Abbildung außerdem zeigt, wird die Latenz umso langsamer, je weiter Sie vom Dienst entfernt sind und je schwieriger es ist, die Grenzen der Leistungsskalierung mit einem beliebigen 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. Häufig kann eine Workload durch eine unterdimensionierte oder falsch geroutete ExpressRoute-Verbindung oder ein VPN-Gateway verlangsamt werden.

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.

Clients Dateien Threads 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