In nahezu allen Azure-Kursen wie z. B. im AZ 104 oder auch in meinem Kurs Azure Cloud Architect ist der Speicher-Dienst Azure-Storage thematisiert, da es sich hierbei um einen der wichtigsten Dienste in Azure handelt. Mit Ihnen können Sie Objektspeicher, Dateispeicher, Warteschlangen und Tabellenspeicher in Azure hosten. Ich stelle fest, dass es hier häufig Missverständnisse bzgl. der Access Tiers für Objekt- und Datei-Speicher gibt und dass es z. B. hinsichtlich Performance und Kosten lohnt, näher mit der Speicherarchitektur im Backend zu befassen.
In diesem 2. Teil meiner Azure-Storage-Betrachtung zum Thema Zugriffsebenen und Performance befasse ich mich mit dem Dienst „Azure Files“. Etwaige Grundlagen zu Speicherkonto, der Preisgestaltung im Allgemeinen, sowie zur Performance von Azure Blob (Objektspeicher) habe ich im (Link) ersten Teil erläutert.
Azure Files ist der Dateifreigabe-Dienst in Azure, mit dessen Hilfe Sie gehostete und skalierbare SMB- und oder NFS- (NFS nur i. V. mit einem Storage-Account-Typ „Premium Files“) in der Cloud betreiben können. Sie können sich Azure Files wie ein Cloud-basiertes NAS-System vorstellen, auf dessen Dateifreigaben (Schwerpunkt und Hauptfokus ist SMB/CIFS) Sie von jedem gewünschten SMB-Client (Linux mit „Samba“ geht auch) innerhalb oder außerhalb von Azure mittels privater oder öffentlicher Endpunkte und ein in HTTP/S verpacktes SMB-Protokoll zugreifen können.
Benötigen Sie Cloud-basierte SMB- oder NFS-Freigaben auf Enterprise-Niveau, die über die im Folgenden beschriebenen Leistungsaspekte noch hinaus gehen und sich außerdem an im Bereich Enterprise-Storage etablierten Standards von Net App orientieren, werfen Sie doch einen Blick auf Azure NetApp Files. Der zusammen mit Net App entwickelte Dienst ist u. a. HIPAA- und DSGVO konform zertifiziert und bietet eine Standardverfügbarkeit von 99,99 %, sodass Sie auch Branchenanwendungen sicher zu Azure migrieren und dort betreiben können.
Ein paar Denkanregungen zu Azure Files
Was Azure Files betrifft setze ich auch hier grundlegende Vertrautheit mit dem Dienst voraus. Der Dienst wird außerdem in viele Azure-Trainings behandelt, u. a. im AZ 104, AZ 305 oder in meinem Kurs Azure Cloud Architect, wobei ich bei einem Freigabe-Dienst neben den Performance-Betrachtungen vor allem (und noch eher als bei BLOB) das Thema Authentifizierung und Autorisierung in den Fokus rücken würde.
Setzen Sie Azure Files als Cloud-basiertes NAS ein, wird fast immer eine identitätsbasierende Authentifizierung benötigt, damit der Zugriff nicht nur auf die komplette Dateifreigabe (z. B. mit Hilfe der Speicherkontoschlüssel) gewährt wird. Vielmehr ist es bei Azure Files meist gewünscht, das Zugriffsentscheidung an ein existierendes Konto im lokalen Active Directory oder im Entra ID oder in den Entra ID Domain Services zu binden, um z. B. granulare NTFS-Berechtigungen vergeben zu können, mit der Konsequenz, dass das Speicherkonto irgendeine Art von Computer-Identität im verbundenen Verzeichnisdienst benötigt.
Die hierzu erforderliche Konfiguration in einem der 3 genannten Szenarien ist durchaus komplex, von Microsoft aber gut dokumentiert und wird auch im Azure-Portal verständlich „geführt“. Ich schreibe in Kürze hier noch mal einen Beitrag dazu.
REST API und Azure Files Sync
Noch Mal zurück zur REST-API. Während bei BLOB erwartungsgemäß REST die bevorzugte Zugriffmethode ist, steht bei Azure Files das SMB-Protokoll im Vordergrund. Dabei möchte ich nicht verschweigen, dass es für Azure Files durchaus eine REST API gibt, die von Microsoft auch als „FileREST“-API bezeichnet wird. Um diese zu nutzen, müssen Sie HTTPS-Anforderungen für die FileREST-HTTPS-Endpunkte erstellen, sich also quasi selbst einen REST-Client schreiben. Es gibt allerdings einen weiteren Azure-Dienst, der die FileREST-API direkt unterstützt, die „Azure-Dateisynchronisierung“.
Dieser Dienst erlaubt unter anderem das Zentralisieren aller Dateifreigaben eines Unternehmens in Azure Files, obwohl oder trotzdem am lokalen Standort nicht auf die Flexibilität, Leistung und Kompatibilität eines Windows-basierten Dateiservers verzichtet werden muss. Zusätzlich bietet die Azure-Dateisynchronisierung die Möglichkeit, Windows Server als schnellen Cache für Ihre Azure-Dateifreigabe, also für den Dienst Azure Files zu nutzen. Sie können dann jedes beliebige unter Windows Server verfügbar Protokoll verwenden, um lokal auf Ihre Daten zuzugreifen, z.B. SMB, NFS und FTPS.
Ein weiterer beliebter Usecase für Azure Files Sync ist das Cloud Tiering. Hierbei werden nur Dateien, auf die besonders häufig zugegriffen wird, auf den lokalen Server zwischengespeichert, Dateien, auf die nur selten zugegriffen wird jedoch via FileREST-API in die Cloud, also in Azure Files, ausgelagert.
Zugriffs-Ebenen
Nun aber zu den Zugriffsebenen. Wie schon in Teil 1 erläutert, haben diese hier eine andere Bedeutung, als bei BLOB und lauten „Premium“, „Transaktion optimiert“, „Heiß“ (HOT) und Kühl (COOL).
Wie Sie der Abbildung entnehmen können, benötigen Sie für die Zugriffs-Ebene „Premium“ auch ein „Premium“-Speicherkonto. Hier ist aus Kostenbetrachtung große Vorsicht geboten. Bei der Premium-Ebene bezahlen Sie nämlich stets die „gesamte“ von Microsoft bereitgestellte Kapazität, unabhängig davon, wie viel Sie tatsächlich nutzen, während Sie bei den 3 Standard-Ebenen tatsächlich nur die Nutzung zahlen, also die Summe aller Ordner und Dateien und der Verzeichnishierarchie. Außerdem sind die Kosten für Transaktionen in der Premium-Ebene in der Regel höher als bei den anderen Ebenen. Schauen wir uns die Ebenen nun im Einzelnen an:
UseCase: UseCase User Case: UseCase
Premium
Transaktionsoptimiert
Heiß
Kühl
Azure Files Performance
In Summe erfüllt Azure Files die Leistungsanforderungen für die meisten Anwendungen und Anwendungsfälle Trotzdem sollte Sie verschiedenen Faktoren berücksichtigen, die sich auf die Leistung von Dateifreigaben auswirken, bzw. Sie die Leistung von Azure-Dateifreigaben für Ihre Workloads optimieren. In jedem Fall sollten Sie sich über die wichtigsten Performance-Kenngrößen, bzw. Metriken und deren Beziehung zueinander im Klaren sein. Diese sind:
E/A-Vorgänge pro Sekunde (IOPS) Die „Eingabe-/Ausgabevorgänge pro Sekunde“ (IOPS) messen stets die Anzahl von Dateisystemvorgängen pro Sekunde. Sie können „IO“ aber je nach Use Case auch für „Operation“ und „Transaktion“ einsetzen E/A-Größe Hierbei spielt natürlich die elementare I/O-Größe eine wichtige Rolle. Da es sich bei Azure Storage und „Software-Defined-Storage“ handelt, ist die „Physik“ zwar gewissermaßen wegabstrahiert, trotzdem brauchen Sie eine Kenngröße zum Vergleichen. Daher wird I/O-Größe bei Block- und/oder File-Speicher meist als Blockgröße aufgefasst, bzw. interpretiert, in diesem Fall die Größe der Anforderung, die eine Anwendung zum Ausführen eines einzelnen Eingabe-/Ausgabevorgangs (I/O-Vorgang) für den Speicher nutzt. Dies I/O-Größe kann in Abhängigkeit der Anwendung variieren von sehr klein (z. B.4 KiB) bis sehr groß und geht damit unmittelbar in die Berechnung des erreichbaren Durchsatzes ein. Durchsatz Wie schon im BLOB-Beitrag erläutert, misst der Durchsatz die Anzahl der Bits, die pro Sekunde aus dem Speicher gelesen oder in den Speicher geschrieben werden, z. B. in MiB/s. Der Durchsatz errechnet sich dann durch Multiplikation des IOPS-Wertes mit der I/O-Größe Latenz Dabei dürfen Sie aber die Latenz (Wartezeit) nicht außer Acht lassen. Latenz ist eigentlich immer nur ein anderes Wort für Verzögerung und wird in der Regel in Millisekunden (ms) gemessen. Zu unterschieden sind dabei die Ende-to-Ende-Latenz und die Dienstlatenz. Auch darauf bin ich Teil 1 bereits näher eingegangen. Zur Erinnerung: Die Ende-zu-Ende-Latenz ist die Gesamtdauer, die eine Transaktion für einen vollständigen Roundtrip vom Client über das Netzwerk zum Azure Files-Dienst und zurück zum Client benötigt. Die Dienstlatenz hingegen ist die Zeit, die eine Transaktion innerhalb des Dienstes Azure Files für den Roundtrip verbraucht, „ohne“ Client- oder Netzwerklatenz. Insbesondere zur Latenz findet sich eine sehr aussagekräftige Grafik von Microsoft in der Azure-Files-Dokumentation: Warteschlangenlänge Schließlich spielt bei NAS- immer auch die Warteschlangentiefe eine wichtige Rolle. Hierunter versteht man die Anzahl der ausstehenden E/A-Anforderungen, die eine Speicherressource gleichzeitig verarbeiten kann.
Überlegungen zur SMB-Leistung
Es gibt aber durchaus noch weitere Aspekte, die die Performance von Azure -Storage-Dateifreigaben beeinflussen. Vor allen hängt die Leistung natürlich auch davon ab, wie viele Clients gleichzeitig auf die Dateifreigabe zugreifen. Dabei spielen sowohl die Client-Konfiguration, die Anzahl gleichzeitiger Verbindungen von einem Client im Rahmen von SMB-Multichanneling, sowie die Netzwerkbandbreite eine wichtige Rolle. Letztere hängt auch davon ab, wo sich der Client befindet.
Befindet sich Ihre Client VM in Azure, sollte Sie sich aus Gründen der Performance in derselben Azure-Region befinden, damit sich die Netzwerkwartezeit reduziert. Bei deaktivierter sicherer Übertragung (normalerweise ist sicherere Übertragung standardmäßig aktiviert, was mindestens die SMB-Protokoll-Version 3.0 erfordert) und Verwendung eines öffentlichen Endpunktes, „muss“ sich die Client-VM sogar zwingend in der gleichen Region befinden. Sie können übrigens die SMB-Protokollversion, genauso wie viele andere sicherheitsrelevante Einstellungen in den „Kompatibilitätseinstellungen“ der Dateifreigabe konfigurieren.
In puncto SMB-Protokollversion, NFS, sowie öffentlicher oder privater Endpunkt gäbe es durchaus noch eine ganze Reihe weiterer Aspekte zu erörtern, die z. B. leider auch im AZ 104 nicht thematisiert sind. Das plane ich für einen künftigen Beitrag hier ein, um den thematischen Rahmen nicht zu sprengen.
Machen Sie sich grundsätzlich Gedanken, ob Sie für Ihre Anwendung, bzw. den Zugriff darauf, ein Premium-Speicherkonto mit SSDs benötigen oder ob „Standard“ (z. B. mit „transaktionsoptimiert“) genügt, denn die Leistung von SSD-Freigaben ist stets gebunden an die bereitgestellte Freigabegröße, einschließlich IOPS und Durchsatz.
Die maximale mögliche Leistung eines einzelnen VM-Clients bleibt hingegen an VM-Grenzwerte gebunden., die für jede der rund 650 verschieden VM-Größen spezifisch ist. Die in den meisten Azure-Labs verwendete Standard-D-Serie v3 unterstützt z. B. in der Variante Standard_D32_v3 eine maximale Bandbreite von ca. 16000 MBit/s. Die Leistung der Dateifreigabe hängt aber auch von den Grenzwerten des Netzwerks, den CPUs, dem internen Speicher, der verfügbaren Netzwerkbandbreite, den E/A-Größen und der Parallelität ab.
SMB-Multichanneling
Wichtig ist außerdem, dass Sie nach Möglichkeit die Leistungsvorteile von SMB-Multichanneling verwenden. Das klappt allerdings nur bei Premium-Dateifreigaben, das unterliegenden Speicherkonto also SSDs im Backend nutzt und selbstverständlich auch nur bei Windows-Clients. SMB-Multichanneling ermöglicht es einem SMB-Client, mehrere Netzwerkverbindungen zu einer SMB-Dateifreigabe herzustellen, was die Leistung durch Bandbreitenaggregation und die Nutzung von Receive Side Scaling (RSS) unterstützt. Dabei muss nicht nur das Client-OS SMB-Multichanneling unterstützen, sondern auch dessen Hardware. Diese muss über mehrere Netzwerkschnittstellenkarten (NICs) mit RSS-Support verfügen, um die I/O-Last auf mehrere CPUs zu verteilen.
Auch die Client-Anwendung profitiert von SMB-Multichanneling, wenn sie Multi-Thread-fähig ist, weil sie die Last dann auf mehrere Dateien verteilen kann. Die Leistungsvorteile von SMB Multichanneling erhöhen sich mit der Anzahl von Dateien, auf die die Last verteilt wird. Weitere Details zu den Leistungsvorteilen von SMB-Multichanneling, bzw. zu den Leistungsunterscheiden zwischen Multithreads/mehrere Dateien versus Multithreads /einzelne Datei versus Singlethread/mehrere Dateien oder einzelne Datei finden Sie übrigens im Azure-Files-Handbuch.
