Skalierbarkeits- und Leistungsziele für Azure Files und Azure-Dateisynchronisierung

Azure Files bietet vollständig verwaltete Dateifreigaben in der Cloud, auf die über das SMB-Dateisystemprotokoll (Server Message Block) und über das NFS-Dateisystemprotokoll (Network File System) zugegriffen werden kann. Dieser Artikel behandelt die Skalierbarkeits- und Leistungsziele für Azure-Speicherkonten, Azure Files und Azure-Dateisynchronisierung.

Die hier aufgelisteten Ziele können durch andere Variablen in Ihrer Bereitstellung beeinflusst werden. So können beispielsweise das Verhalten Ihres SMB-Clients und die verfügbare Netzwerkbandbreite Auswirkungen auf die E/A-Leistung für eine Datei haben. Es empfiehlt sich, Ihr Nutzungsmuster zu testen, um zu ermitteln, ob Skalierbarkeit und Leistung von Azure Files Ihren Anforderungen entsprechen.

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

Skalierbarkeitsziele für Azure Files

Azure-Dateifreigaben werden in Speicherkonten bereitgestellt, bei denen es sich um Objekte der obersten Ebene handelt, die einen freigegebenen Speicherpool darstellen. Dieser Speicherpool kann verwendet werden, um mehrere Dateifreigaben bereitzustellen. Es gibt also drei Kategorien zu beachten: Speicherkonten, Azure-Dateifreigaben und einzelne Dateien.

Skalierbarkeitsziele für Speicherkonten

Skalierbarkeitsziele für Speicherkonten gelten auf Speicherkontoebene. Es gibt zwei Haupttypen von Speicherkonten für Azure Files:

  • Speicherkonten vom Typ „Universell Version 2 (GPv2)“ : GPv2-Speicherkonten ermöglichen Ihnen die Bereitstellung von Azure-Dateifreigaben auf Standard- bzw. festplattenbasierter Hardware (HDD-basiert). Neben Azure-Dateifreigaben können in GPv2-Speicherkonten auch andere Speicherressourcen wie Blobcontainer, Warteschlangen oder Tabellen gespeichert werden. Dateifreigaben können auf den transaktionsoptimierten (Standardeinstellung), heißen und kalten Ebenen bereitgestellt werden.

  • FileStorage-Speicherkonten: FileStorage-Speicherkonten ermöglichen Ihnen die Bereitstellung von Azure-Dateifreigaben auf SSD-basierter Hardware (Premium/Solid State Drive). FileStorage-Konten können nur zum Speichern von Azure-Dateifreigaben verwendet werden. In einem FileStorage-Konto können keine anderen Speicherressourcen (Blobcontainer, Warteschlangen, Tabellen usw.) bereitgestellt werden.

attribute GPv2-Speicherkonten (Standard) FileStorage-Speicherkonten (Premium)
Anzahl von Speicherkonten pro Region und Abonnement 2501 2501
Maximale Speicherkontokapazität 5 PiB2 100 TiB (bereitgestellt)
Maximale Anzahl der Dateifreigaben Unbegrenzt Unbegrenzt, die gesamte bereitgestellte Größe aller Freigaben muss kleiner sein als die maximale Speicherkontokapazität.
Rate für maximale Anzahl von gleichzeitigen Anforderungen 20.000 IOPS2 102.400 IOPS
Durchsatz (eingehend und ausgehend) für LRS/GRS
  • Australien (Osten)
  • USA (Mitte)
  • Asien, Osten
  • USA (Ost) 2
  • Japan, Osten
  • Korea, Mitte
  • Nordeuropa
  • USA Süd Mitte
  • Asien, Südosten
  • UK, Süden
  • Europa, Westen
  • USA (Westen)
  • Eingehend: 7.152 MiB/s
  • Ausgehend: 14.305 MiB/s
10.340 MiB/s
Durchsatz (eingehend und ausgehend) für ZRS
  • Australien (Osten)
  • USA (Mitte)
  • East US
  • USA (Ost) 2
  • Japan, Osten
  • Nordeuropa
  • USA Süd Mitte
  • Asien, Südosten
  • UK, Süden
  • Europa, Westen
  • USA, Westen 2
  • Eingehend: 7.152 MiB/s
  • Ausgehend: 14.305 MiB/s
10.340 MiB/s
Durchsatz (eingehend und ausgehend) für Kombinationen aus Redundanz und Region, die in der vorherigen Zeile nicht aufgeführt sind
  • Eingehend: 2.980 MiB/s
  • Ausgehend: 5.960 MiB/s
10.340 MiB/s
Maximale Anzahl von Regeln für virtuelle Netzwerke 200 200
Maximale Anzahl von IP-Adressregeln 200 200
Lesevorgänge für die Verwaltung 800 pro 5 Minuten 800 pro 5 Minuten
Schreibvorgänge für die Verwaltung 10 pro Sekunde/1200 pro Stunde 10 pro Sekunde/1200 pro Stunde
Listenvorgänge für die Verwaltung 100 pro 5 Minuten 100 pro 5 Minuten

1 Mit einer Kontingenterhöhung können Sie bis zu 500 Speicherkonten mit Standardendpunkten pro Region erstellen. Weitere Informationen finden Sie unter Erhöhen von Azure Storage-Kontokontingenten. 2 Speicherkonten vom Typ „Universell, Version 2“ unterstützen auf Anforderung höhere Grenzwerte für Kapazität und Eingang. Wenden Sie sich an den Azure-Support, um eine Erhöhung der Kontogrenzwerte anzufordern.

Skalierbarkeitsziele für Azure-Dateifreigaben

Skalierbarkeitsziele für Azure-Dateifreigaben gelten auf Dateifreigabeebene.

attribute Standard-Dateifreigaben 1 Premium-Dateifreigaben
Mindestgröße einer Dateifreigabe Keine Mindestanforderungen 100 GiB (bereitgestellt)
Einheit für Erhöhung/Verringerung der bereitgestellten Größe Nicht zutreffend 1 GiB
Maximale Größe einer Dateifreigabe ca. 100 TiB ca. 100 TiB
Maximale Anzahl an Dateien in einer Dateifreigabe Keine Begrenzung Keine Begrenzung
Maximale Anforderungsrate (max. IOPS) 20.000
  • Geplante IOPS: 3000 + 1 IOPS pro GiB, bis zu 102.400
  • IOPS-Bursting: Max. (10.000, 3x IOPS pro GiB), bis zu 102.400
Durchsatz (Eingehend + Ausgehend) für eine einzelne Dateifreigabe (MiB/s) Bis zu Speicherkontogrenzwerten 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)
Maximale Anzahl von Freigabemomentaufnahmen 200 Momentaufnahmen 200 Momentaufnahmen
Maximale Objektnamenlänge3 (vollständiger Pfadname einschließlich aller Verzeichnisse, Dateinamen und Backslash-Zeichen) 2\.048 Zeichen 2\.048 Zeichen
Maximale Länge einzelner Pfadnamenkomponenten2 (im Pfad „\A\B\C\D“ stellt jeder Buchstabe ein Verzeichnis oder eine Datei dar, die eine einzelne Komponente ist) 255 Zeichen 255 Zeichen
Grenzwert für feste Links (nur NFS) 178
Maximale Anzahl von SMB Multichannel-Kanälen N/V 4
Maximale Anzahl gespeicherter Zugriffsrichtlinien pro Dateifreigabe 5 5

1 Die Grenzwerte für Standarddateifreigaben gelten für alle drei Dienstebenen, die für Standarddateifreigaben verfügbar sind: transaktionsoptimiert, heiß und kalt.

2 Azure Files erzwingt bestimmte Benennungsregeln für Verzeichnis- und Dateinamen.

Dateiskalierbarkeitsziele

Dateiskalierbarkeitsziele gelten für einzelne Dateien, die in Azure-Dateifreigaben gespeichert sind.

attribute Dateien in Standard-Dateifreigaben Dateien in Premium-Dateifreigaben
Maximale Dateigröße 4 TiB 4 TiB
Rate für maximale Anzahl von gleichzeitigen Anforderungen 1.000IOPS Bis zu 8.0001
Maximaler Eingang für eine Datei 60 MiB/s 200 MiB/s (bis zu 1 GiB/s bei SMB Multichannel) 2
Maximaler Ausgang für eine Datei 60 MiB/s 300 MiB/s (bis zu 1 GiB/s bei SMB Multichannel) 2
Maximale Anzahl gleichzeitiger Handles für Stammverzeichnis3 10.000 Handles 10.000 Handles
Maximale gleichzeitige Handles pro Datei und Verzeichnis3 2\.000 Handles 2\.000 Handles

1 Gilt für E/A für Lese- und Schreibvorgänge (üblicherweise geringere E/A-Größen bis maximal 64 KiB) Metadatenvorgänge (außer Lese-und Schreibvorgängen) können geringer sein. Dies sind weiche Grenzen und Drosselung kann jenseits dieser Grenzen auftreten.

2 Abhängig von Netzwerkgrenzwerten des Computers, verfügbarer Bandbreite, E/A-Größen, Warteschlangenlänge und anderen Faktoren Ausführliche Informationen finden Sie unter SMB Multichannel-Leistung.

3 Azure Files unterstützt 10.000 geöffnete Handles für das Stammverzeichnis und 2.000 geöffnete Handles pro Datei und Verzeichnis innerhalb der Freigabe. Die Anzahl der aktiven Benutzer, die pro Freigabe unterstützt werden, hängt von den Anwendungen ab, die auf die Freigabe zugreifen. Wenn Ihre Anwendungen kein Handle im Stammverzeichnis öffnen, kann Azure Files mehr als 10.000 aktive Benutzer*innen pro Freigabe unterstützen. Wenn Sie aber Azure Files zum Speichern von Datenträgerimages für große virtuelle Desktopworkloads verwenden, sind möglicherweise nicht genügend Handles für das Stammverzeichnis oder pro Datei/Verzeichnis verfügbar. In diesem Fall müssen Sie möglicherweise mehrere Azure-Dateifreigaben verwenden. Weitere Informationen finden Sie unter Azure Files-Größenanpassungsanleitungen für Azure Virtual Desktop.

Anleitung zur Größenanpassung von Azure Files für Azure Virtual Desktop

Ein beliebter Anwendungsfall für Azure Files ist das Speichern von Benutzerprofilcontainern und Datenträgerimages für Azure Virtual Desktop unter Verwendung von FSLogix oder App Attach. In umfangreichen Azure Virtual Desktop-Bereitstellungen sind möglicherweise keine Handles für das Stammverzeichnis oder pro Datei/Verzeichnis vorhanden, wenn Sie eine einzelne Azure-Dateifreigabe verwenden. In diesem Abschnitt wird beschrieben, wie Handles von verschiedenen Typen von Datenträgerimages genutzt werden, und er bietet Anleitungen zur Größenanpassung je nach verwendeter Technologie.

FSLogix

Wenn Sie FSLogix mit Azure Virtual Desktop verwenden, sind Ihre Benutzerprofilcontainer entweder virtuelle Festplatten (VHD) oder Hyper-V Virtual Hard Disk (VHDX)-Dateien, und sie werden in einem Benutzerkontext bereitgestellt, nicht in einem Systemkontext. Jeder Benutzer öffnet ein einzelnes Stammverzeichnis-Handle, das sich auf die Dateifreigabe bezieht. Azure Files kann maximal 10.000 Benutzer unterstützen, vorausgesetzt, Sie haben die Dateifreigabe (\\storageaccount.file.core.windows.net\sharename) + das Profilverzeichnis (%sid%_%username%) + Profilcontainer (profile_%username.vhd(x)).

Wenn Sie den Grenzwert von 10.000 gleichzeitigen Handles für das Stammverzeichnis erreichen oder Benutzer eine schlechte Leistung sehen, versuchen Sie, eine zusätzliche Azure-Dateifreigabe zu verwenden und die Container zwischen den Freigaben zu verteilen.

Warnung

Azure Files kann zwar bis zu 10.000 gleichzeitige Benutzer aus einer einzelnen Dateifreigabe unterstützen, es ist jedoch wichtig, Ihre Arbeitsauslastungen ordnungsgemäß anhand der Größe und des Typs der Dateifreigabe zu testen, die Sie erstellt haben. Ihre Anforderungen können je nach Benutzer, Profilgröße und Workload variieren.

Wenn Sie beispielsweise über 2.400 gleichzeitige Benutzer verfügen, benötigen Sie 2.400 Handles im Stammverzeichnis (eins für jeden Benutzer), was unterhalb des Grenzwerts von 10.000 geöffneten Handles liegt. Für FSLogix-Benutzer ist das Erreichen des Grenzwerts von 2.000 geöffneten Datei- und Verzeichnishandles äußerst unwahrscheinlich. Wenn Sie über einen einzelnen FSLogix-Profilcontainer pro Benutzer verfügen, verwenden Sie nur zwei Datei-/Verzeichnishandles: Einen für das Profilverzeichnis und einen für die Profilcontainerdatei. Wenn Benutzer jeweils über zwei Container verfügen (Profil und ODFC), benötigen Sie ein zusätzliches Handle für die ODFC-Datei.

App Attach mit CimFS

Wenn Sie MSIX App Attach oder App Attach verwenden, um Anwendungen dynamisch anzufügen, können Sie Composite Image File System (CimFS) oder VHD/VHDX-Dateien als Datenträgerimagesverwenden. So oder so sind die Skalierungsgrenzwerte pro VM, die das Image einbindet, und nicht pro Benutzer. Die Anzahl der Benutzer ist beim Berechnen von Skalierungsgrenzwerten irrelevant. Wenn ein virtueller Computer gestartet wird, wird das Datenträgerimage bereitgestellt, auch wenn null Benutzer vorhanden sind.

Wenn Sie App Attach mit CimFS verwenden, verbrauchen die Datenträgerimages nur Handles auf den Datenträgerimagedateien. Sie verwenden keine Handles im Stammverzeichnis oder im Verzeichnis, welches das Datenträgerimage enthält. Da ein CimFS-Image jedoch eine Kombination aus der CIM-Datei und mindestens zwei anderen Dateien ist, benötigen Sie für jede VM, die das Datenträgerimage anhäuft, jeweils ein Handle für drei Dateien im Verzeichnis. Wenn Sie also über 100 VMs verfügen, benötigen Sie 300 Dateihandles.

Möglicherweise sind keine Dateihandles mehr verfügbar, wenn die Anzahl der virtuellen Computer pro App 2.000 überschreitet. Verwenden Sie in diesem Fall eine zusätzliche Azure-Dateifreigabe.

App Attach mit VHD/VHDX

Wenn Sie App Attach mit VHD/VHDX-Dateien verwenden, werden die Dateien in einem Systemkontext bereitgestellt, nicht in einem Benutzerkontext, und sie werden freigegeben und schreibgeschützt. Es kann mehr als ein Handle für die VHDX-Datei von einem Verbindungssystem genutzt werden. Um innerhalb der Skalierungsgrenzen von Azure Files zu bleiben, muss die Anzahl der virtuellen Computer, die mit der Anzahl der Apps multipliziert werden, kleiner als 10.000 sein, und die Anzahl der virtuellen Computer pro App darf 2.000 nicht überschreiten. Die Einschränkung ist also je nachdem, was Sie zuerst erreicht haben.

In diesem Szenario könnten Sie den Grenzwert pro Datei/Verzeichnis mit 2.000 Bereitstellungen einer einzelnen VHD/VHDX erreichen. Oder, wenn die Freigabe mehrere VHD/VHDX-Dateien enthält, könnten Sie zuerst den Stammverzeichnisgrenzwert erreichen. 100 VMs für die Bereitstellung von 100 freigegebenen VHDX-Dateien erreichen beispielsweise den Grenzwert von 10.000 im Stammverzeichnis.

In einem anderen Beispiel benötigen 100 VMs, die auf 20 Apps zugreifen, 2.000 Stammverzeichnishandles (100 x 20 = 2.000), die sich leicht innerhalb des Grenzwerts von 10.000 für Stammverzeichnishandles befinden. Außerdem benötigen Sie ein Dateihandle und ein Verzeichnis-/Ordnerhandle für jeden virtuellen Computer, der das VHD(X)-Image einbindet. In diesem Fall sind es 200 Handles (100 Dateihandles + 100 Verzeichnishandles), die bequem unter dem Grenzwert von 2.000 Handles pro Datei/Verzeichnis liegen.

Wenn Sie die Grenzwerte für maximale gleichzeitige Handles für das Stammverzeichnis oder pro Datei/Verzeichnis erreichen, verwenden Sie eine zusätzliche Azure-Dateifreigabe.

Skalierbarkeitsziele für die Azure-Dateisynchronisierung

Die folgende Tabelle gibt die weichen Ziele (von Microsoft getestete Grenze) und die harten Ziele (erzwungenes Maximum) an:

Resource Ziel Harte Grenze
Speichersynchronisierungsdienste pro Region 100 Speichersynchronisierungsdienste Ja
Speichersynchronisierungsdienste pro Abonnement 15 Speichersynchronisierungsdienste Ja
Synchronisierungsgruppen pro Speichersynchronisierungsdienst 200 Synchronisierungsgruppen Ja
Registrierte Server pro Speichersynchronisierungsdienst 99 Server Ja
Private Endpunkte pro Speichersynchronisierungsdienst 100 private Endpunkte Ja
Cloudendpunkte pro Synchronisierungsgruppe 1 Cloudendpunkt Ja
Serverendpunkte pro Synchronisierungsgruppe 100 Serverendpunkte Ja
Serverendpunkte pro Server 30 Serverendpunkte Ja
Dateisystemobjekte (Verzeichnisse und Dateien) pro Synchronisierungsgruppe 100 Millionen Objekte Nein
Maximale Anzahl von Dateisystemobjekten (Verzeichnisse und Dateien) in einem Verzeichnis (nicht rekursiv) 5 Millionen Objekte Ja
Maximale Sicherheitsbeschreibung des Objekts (Verzeichnisse und Dateien) 64 KiB Ja
Dateigröße 100 GB Nein
Minimale Dateigröße für die Unterteilung einer Datei Basiert auf der Größe des Dateisystemclusters (doppelte Größe des Dateisystemclusters). Wenn die Größe des Dateisystemclusters z. B. 4 KiB beträgt, ist die minimale Dateigröße 8 KiB. Ja

Hinweis

Ein Endpunkt für Azure-Dateisynchronisierung kann auf die Größe einer Azure-Dateifreigabe hochskaliert werden. Wenn die maximale Größe der Azure-Dateifreigabe erreicht ist, kann keine Synchronisierung mehr durchgeführt werden.

Leistungsmetriken der Azure-Dateisynchronisierung

Da der Azure-Dateisynchronisierungs-Agent auf einem Windows Server-Computer ausgeführt wird, der mit den Azure-Dateifreigaben verbunden wird, hängt die effektive Synchronisierungsleistung von einer Reihe von Faktoren in Ihrer Infrastruktur ab: von Windows Server und der zugrunde liegenden Datenträgerkonfiguration, der Netzwerkbandbreite zwischen dem Server und Azure Storage, der Dateigröße, der gesamten Datasetgröße und der Aktivität im Dataset. Da die Azure-Dateisynchronisierung auf Dateiebene ausgeführt wird, sollten die Leistungsmerkmale einer auf der Azure-Dateisynchronisierung basierenden Lösung als Anzahl von Objekten (Dateien und Verzeichnisse) gemessen werden, die pro Sekunde verarbeitet werden.

Bei der Azure-Dateisynchronisierung ist die Leistung in zwei Phasen entscheidend:

  1. Bei der ersten einmaligen Bereitstellung: Informationen zum Optimieren der Leistung bei der ersten Bereitstellung finden Sie unter Onboarding bei der Azure-Dateisynchronisierung.
  2. Laufende Synchronisierung: Nachdem zunächst ein Seeding für die Daten in den Azure-Dateifreigaben ausgeführt wird, synchronisiert die Azure-Dateisynchronisierung fortlaufend mehrere Endpunkte.

Hinweis

Wenn viele Serverendpunkte in derselben Synchronisierungsgruppe gleichzeitig synchronisiert werden, konkurrieren sie um Clouddienstressourcen. Dadurch wird die Uploadleistung beeinträchtigt. In extremen Fällen können einige Synchronisierungssitzungen nicht auf die Ressourcen zugreifen, und es tritt ein Fehler auf. Diese Synchronisierungssitzungen werden jedoch in Kürze fortgesetzt und schließlich erfolgreich abgeschlossen, sobald sich die Überlastung verringert hat.

Interne Testergebnisse

Wenn Sie die Bereitstellung für jede der Phasen (anfängliche einmalige Bereitstellung und laufende Synchronisierung) planen, sehen Sie sich hier die Ergebnisse an, die wir bei den internen Tests auf einem System mit der folgenden Konfiguration beobachtet haben:

Systemkonfiguration Details
CPU 64 virtuelle Kerne mit 64-MiB-L3-Cache
Arbeitsspeicher 128 GB
Datenträger SAS-Datenträger mit RAID 10 mit batteriegepuffertem Cache
Netzwerk 1-GBit/s-Netzwerk
Workload Allgemeiner Dateiserver

Erste einmalige Bereitstellung

Erste einmalige Bereitstellung Details
Anzahl der Objekte 25 Millionen Objekte
Datasetgröße ca. 4,7 TiB
Durchschnittliche Dateigröße ca. 200 KiB (größte Datei: 100 GiB)
Anfängliche Enumeration von Cloudänderungen 80 Objekte pro Sekunde
Uploaddurchsatz 20 Objekte pro Sekunde pro Synchronisierungsgruppe
Durchsatz beim Download von Namespaces 400 Objekte pro Sekunde

Anfängliche Enumeration von Cloudänderungen: Wenn eine neue Synchronisierungsgruppe erstellt wird, ist die anfängliche Enumeration von Cloudänderungen der erste Schritt, der ausgeführt wird. In diesem Prozess listet das System alle Elemente in der Azure-Dateifreigabe auf. Während dieses Vorgangs findet keine Synchronisierungsaktivität statt. Es werden keine Elemente vom Cloudendpunkt auf den Serverendpunkt heruntergeladen und keine Elemente vom Serverendpunkt auf den Cloudendpunkt hochgeladen. Die Synchronisierungsaktivität beginnt erst, wenn die anfängliche Enumeration von Cloudänderungen abgeschlossen ist.

Der Durchsatz liegt bei 80 Objekten pro Sekunde. Sie können die Dauer der anfänglichen Enumeration von Cloudänderungen schätzen, indem sie die Anzahl von Elementen in der Cloudfreigabe bestimmen und die folgende Formel verwenden, um die Zeit (in Tagen) zu berechnen.

Zeitraum (in Tagen) für die anfängliche Cloudenumeration = (Anzahl von Objekten am Cloudendpunkt) / (80 × 60 × 60 × 24)

Erstsynchronisierung von Daten von Windows Server zur Azure-Dateifreigabe: Viele Bereitstellungen einer Azure-Dateisynchronisierung beginnen mit einer leeren Azure-Dateifreigabe, weil alle Daten auf dem Windows-Server gespeichert sind. In diesen Fällen ist die anfängliche Enumeration von Cloudänderungen schnell, und der Großteil der Zeit wird für die Synchronisierung von Änderungen vom Windows-Server in die Azure-Dateifreigabe(n) benötigt.

Obwohl die Synchronisierung Daten in die Azure-Dateifreigabe hochlädt, gibt es auf dem lokalen Dateiserver keine Ausfallzeiten, und Administrator*innen können Netzwerklimits einrichten, um die für das Hochladen von Hintergrunddaten beanspruchte Bandbreite einzuschränken.

Die Erstsynchronisierung wird normalerweise durch die anfängliche Uploadrate von 20 Dateien pro Sekunde pro Synchronisierungsgruppe begrenzt. Mithilfe der folgenden Formel zur Berechnung des Zeitraums in Tagen können Kunden schätzen, wie lange es dauert, bis alle ihre Daten in Azure hochgeladen sind:

Zeitraum (in Tagen) zum Hochladen von Dateien in eine Synchronisierungsgruppe = (Anzahl von Objekten am Serverendpunkt)/(20 × 60 × 60 × 24)

Wenn Sie Ihre Daten in mehrere Serverendpunkte und Synchronisierungsgruppen aufteilen, kann dieser anfängliche Datenupload beschleunigt werden, weil der Upload für mehrere Synchronisierungsgruppen mit einer Rate von jeweils 20 Elementen pro Sekunde parallel durchgeführt werden kann. Zwei Synchronisierungsgruppen würden also mit einer kombinierten Rate von 40 Elementen pro Sekunde ausgeführt. Die Gesamtzeit bis zum Abschluss wäre die geschätzte Zeit für die Synchronisierungsgruppe mit den meisten Dateien, die synchronisiert werden sollen.

Durchsatz beim Download von Namespaces: Wenn einer vorhandenen Synchronisierungsgruppe ein neuer Serverendpunkt hinzugefügt wird, lädt der Azure-Dateisynchronisierungs-Agent keine Dateiinhalte vom Cloudendpunkt herunter. Zuerst synchronisiert er den vollständigen Namespace und löst dann im Hintergrund einen Rückruf aus, um die Dateien herunterzuladen, entweder in ihrer Gesamtheit oder bei aktiviertem Cloudtiering in der Cloudtieringrichtliniengruppe für den Serverendpunkt.

Laufende Synchronisierung

Laufende Synchronisierung Details
Anzahl der synchronisierten Objekte 125.000 Objekte (Änderungsumfang ca. 1 %)
Datasetgröße 50 GiB
Durchschnittliche Dateigröße Ca. 500 KiB
Uploaddurchsatz 20 Objekte pro Sekunde pro Synchronisierungsgruppe
Durchsatz bei vollständigen Downloads* 60 Objekte pro Sekunde

*Wenn Cloudtiering aktiviert ist, werden Sie wahrscheinlich eine bessere Leistung beobachten, da nur ein Teil der Dateidaten heruntergeladen wird. Die Azure-Dateisynchronisierung lädt die Daten zwischengespeicherter Dateien nur dann herunter, wenn sie auf einem der Endpunkte geändert werden. Bei mehrstufigen oder neu erstellten Dateien lädt der Agent nicht die Dateidaten herunter, sondern synchronisiert lediglich den Namespace mit allen Serverendpunkten. Der Agent unterstützt auch teilweise Downloads von mehrstufigen Dateien, wenn Benutzer*innen auf diese zugreifen.

Hinweis

Diese Zahlen sind kein Hinweis auf die Leistung, die bei Ihnen zu erwarten ist. Die tatsächliche Leistung hängt von mehreren Faktoren ab, die am Anfang dieses Abschnitts beschrieben werden.

Als allgemeine Richtlinie für Ihre Bereitstellung sollten Sie einige Dinge berücksichtigen:

  • Der Objektdurchsatz wird ungefähr relativ zur Anzahl der Synchronisierungsgruppen auf dem Server skaliert. Das Aufteilen von Daten in mehrere Synchronisierungsgruppen auf einem Server führt zu einem besseren Durchsatz, der zudem durch den Server und Netzwerk begrenzt wird.
  • Der Objektdurchsatz ist umgekehrt proportional zum Durchsatz in MiB pro Sekunde. Bei kleineren Dateien tritt ein höherer Durchsatz im Hinblick auf die Anzahl der verarbeiteten Objekte pro Sekunde auf, jedoch ein niedrigerer Durchsatz in MiB pro Sekunde. Im Gegensatz dazu werden bei größeren Dateien weniger Objekte pro Sekunde verarbeitet, dafür jedoch ein höherer Durchsatz in MiB pro Sekunde erzielt. Der Durchsatz in MiB pro Sekunde wird durch die Azure Files-Skalierungsziele beschränkt.

Weitere Informationen