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.

¹ 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. ² 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.

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

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

Dateiskalierbarkeitsziele

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

^{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.

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:

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.

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:

Erste einmalige Bereitstellung

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

*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.

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

• Grundlegendes zur Leistung für Azure Files
• Planung für eine Azure Files-Bereitstellung
• Planung für die Bereitstellung einer Azure-Dateisynchronisierung