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 |  |
 |
| Standard-Dateifreigaben (GPv2), GRS/GZRS | |
|
| Premium-Dateifreigaben (FileStorage), LRS/ZRS | |
|
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
|
|
10.340 MiB/s |
Durchsatz (eingehend und ausgehend) für ZRS
|
|
10.340 MiB/s |
| Durchsatz (eingehend und ausgehend) für Kombinationen aus Redundanz und Region, die in der vorherigen Zeile nicht aufgeführt sind |
|
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 |
|
| 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:
- Bei der ersten einmaligen Bereitstellung: Informationen zum Optimieren der Leistung bei der ersten Bereitstellung finden Sie unter Onboarding bei der Azure-Dateisynchronisierung.
- 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.