Bereitstellen von SAS Grid 9.4 unter Azure NetApp Files

Die SAS-Analysesoftware bietet eine Sammlung von Diensten und Tools, mit denen Erkenntnissen aus Daten gewonnen und intelligente Entscheidungen getroffen werden können. SAS-Lösungen bieten Analysen, künstliche Intelligenz, Business Intelligence, Kundeninformationen, Datenverwaltung und Informationen für Betrugserkennung und Sicherheit.

Wenn Sie SAS Grid in Azure bereitstellen, ist Azure NetApp Files eine geeignete primäre Speicheroption. Durch die Verwendung der skalierbaren Dienste von Azure NetApp Files können Sie die Speicherzuordnungen jederzeit und ohne Unterbrechung der Dienste hoch- oder herunterskalieren. Außerdem kann die Speicherdienstebene dynamisch an die Leistungsanforderungen angepasst werden.

SAS stellt diese primären Plattformen zur Verfügung, die von Microsoft validiert wurden:

• SAS Grid 9.4
• SAS Viya

SAS Grid 9.4 wurde unter Linux überprüft.

Dieser Artikel enthält allgemeine Informationen zum Ausführen von SAS Grid 9.4 in Azure mit Azure NetApp Files als SASDATA-Speicher. Außerdem finden Sie hier einen Leitfaden zu Speicheroptionen für SASWORK. Diese Richtlinien basieren auf der Annahme, dass Sie Ihre eigene SAS-Lösung in Azure in Ihrem eigenen Mandanten hosten. SAS bietet kein Hosting für SAS Grid in Azure.

Aufbau

PowerPoint-Datei mit allen Diagrammen aus diesem Artikel herunterladen

Datenfluss

Die Computeebene verwendet SASDATA-Volumes (und optional SASWORK) zur gemeinsamen Nutzung von Daten im gesamten Raster. SASDATA ist ein mit NFS verbundenes Volume in Azure NetApp Files.

• Ein Serverknoten liest Eingabedaten aus SASDATA und schreibt Ergebnisse in SASDATA zurück.
• Eine nachfolgende Komponente des Analyseauftrags kann von einem anderen Knoten auf der Computeebene ausgeführt werden. Sie verwendet das gleiche Verfahren, um die zu verarbeitenden Informationen abzurufen und zu speichern.

Mögliche Anwendungsfälle

Eine skalierbare SAS Grid-Bereitstellung mit Azure NetApp Files eignet sich für folgende Anwendungsfälle:

• Finanzanalyse
• Betrugserkennung
• Verfolgung und Schutz gefährdeter Arten
• Wissenschaft und Medizin
• Analysen und KI

Anforderungen für Speicherleistung

Bei SAS 9.4-Bereitstellungen (SAS Grid oder SAS Analytics Pro) in Azure ist Azure NetApp Files eine geeignete primäre Speicheroption für SAS Grid-Cluster mit begrenzter Größe. SAS empfiehlt einen Durchsatz von 100 MiB/s pro physischem Kern. Angesichts dieser Empfehlung sind SAS Grid-Cluster, die ein Azure NetApp Files-Volume für SASDATA (persistente SAS-Datendateien) verwenden, auf 32 bis 48 physische Kerne auf zwei oder mehr virtuellen Azure-Computern skalierbar. SAS-Clustergrößen basieren auf der architekturbedingten Einschränkung eines einzelnen SASDATA-Namespace pro SAS-Cluster und der verfügbaren Bandbreite eines einzelnen Azure NetApp Files-Volumes. Der Leitfaden zur Kernanzahl wird ggf. angepasst, wenn sich die Azure-Infrastruktur (Compute, Netzwerk und Speicherbandbreite pro Dateisystem) im Laufe der Zeit vergrößert.

Azure NetApp Files-Volume-Typen

Azure NetApp Files bietet für NAS-Workloads (Network Attached Storage) zwei verschiedene Volumentypen.

Reguläre Volumes bieten Folgendes:

• Bis zu 4.500 MiB/s für Lesevorgänge.
• Bis zu 1.500 MiB/s für Schreibvorgänge.
• 460.000 Ein-/Ausgabevorgänge pro Sekunde (IOPS).
• Eine Gesamtkapazität von bis zu 100 TiB.
• Eine Mindestgröße von 100 GiB.

Große Volumes, die im Mai 2024 die allgemeine Verfügbarkeit erreicht haben, bieten Folgendes:

• Bis zu 10.000 GiB/s Durchsatz.
• Bis zu 800.000 IOPS.
• Eine Gesamtkapazität von bis 1.000 TiB.
• Eine Mindestkapazität von 50 TiB.

Weitere Informationen finden Sie unter Anforderungen und Überlegungen für große Volumes (Vorschau).

Zu erwartende Leistung des regulären Azure NetApp Files-Volumes

Ein einzelnes reguläres Azure NetApp Files-Volume kann bis zu 4.500 MiB/s (Lesen) bzw. bis zu 1.500 MiB/s (Schreiben) bewältigen. Bei einem Azure-Instanztyp mit ausreichender Bandbreite in ausgehender Richtung kann ein einzelner virtueller Computer (VM) die gesamte Schreibbandbreite eines einzelnen regulären Azure NetApp Files-Volumes beanspruchen. Allerdings kann nur der größte einzelne virtuelle Computer, der in Azure verfügbar ist, die gesamte Lesebandbreite eines einzelnen Volumes beanspruchen. Wenn Sie mehr Bandbreite für die Workload wünschen, sollten Sie ein großes Azure NetApp Files-Volume verwenden.

SASDATA, die gemeinsame Hauptworkload von SAS 9.4, hat ein Lese-/Schreibverhältnis von 80:20. Im Anschluss finden Sie die relevanten Werte pro Volume für eine 80:20-Workload mit 64 KiB Lese-/Schreibvorgängen:

• 2.400 MiB/s Lesedurchsatz und 600 MiB/s Schreibdurchsatz, die gleichzeitig ausgeführt werden. Der kombinierte Durchsatz liegt bei etwa 3.000 MiB/s.

Weitere Informationen finden Sie unter Azure NetApp Files-Leistungsbenchmarks für Linux.

Leistung großer Volumes für SAS Grid

Ein einzelnes großes Azure NetApp Files-Volume kann bis zu 10 GiB/s des Gesamtdurchsatzes verarbeiten. Das bedeutet, dass das Leistungspotential für SAS Grid viel größer sein kann, wenn Sie größere Skalierungen vornehmen.

In der folgenden Tabelle sind Leistungsergebnisse für Workloads aufgeführt, die SAS Grid in einem großen Azure NetApp Files-Volume mit verschiedenen Beispiel-VM-Größen verwenden. Die Liste mit Beispielen enthält Instanzenanzahlen, Threads pro Instanz und nconnect-Werte, die Red Hat Enterprise Linux (RHEL) 8.4 verwenden.

VM-Instanz	Anzahl von Instanzen	Threads pro Instanz	Wert vom Typ nconnect	Lesewert pro Thread MiB/s	Schreibwert pro Thread MiB/s	Lese-Gesamtwert MiB/s	Schreib-Gesamtwert MiB/s
E32s_v5	1	16	8	465	113	7\.440	1.808
E32s_v5	2	16	8	411	113	13.152	3.616
E32s_v5	3	16	8	223	113	10.704	5.424
E32s_v5	6	16	8	117	107	11.232	10.272
E104id_v5	1	52	8	161	47	8.372	2.444
E104id_v5	1	52	16	192	50	9.984	2.600

Kapazitätsempfehlungen

Der Azure NetApp Files-Leistungsrechner kann bei der Dimensionierung von SASDATA-Volumes hilfreich sein.

Die Wahl einer geeigneten Dienstebene ist aus folgenden Gründen wichtig:

• Die Volumebandbreite basiert auf der Volumekapazität.
• Die Kapazitätskosten basieren auf der Dienstebene.
• Die von Ihnen gewählte Dienstebene basiert auf der Abwägung zwischen Kapazitäts- und Bandbreitenbedarf.

Wählen Sie im Rechner die Option advanced aus. Wählen Sie anschließend eine Region aus, und geben Sie die folgenden Werte ein:

• Volumegröße: Gewünschte Kapazität
• Durchsatz: Gewünschter Durchsatz bei 100 MiB/s pro Kern
• Prozentualer Leseanteil: 80 Prozent
• IOPS: 0
• E/A-Größe: 64 KiB sequenziell

Die Ausgabe am unteren Bildschirmrand enthält empfohlene Kapazitätsanforderungen auf den einzelnen Dienstebenen sowie die Kosten pro Monat (basierend auf dem Preis für die ausgewählte Region):

• Durchsatz. Die Bandbreite des Volumes, basierend auf der Workloadmischung. Bei einer 80-prozentigen sequenziellen Leseworkload mit 64 KiB sind 3.096 MiB/s das erwartete Maximum.
• IOPS: Die Anzahl von IOPS, die das Volume beim angegebenen Durchsatz bietet.
• Volumegröße: Die Kapazitätsmenge, die das Volume auf den angegebenen Dienstebenen benötigt, um den erforderlichen Durchsatz zu erreichen. Die Volumekapazität (in GiB) kann der Kapazitätspoolgröße entsprechen oder geringer sein. Diese Empfehlung basiert auf der Annahme, dass Sie Kapazitätspooltypen mit automatischer QoS verwenden. Zur weiteren Optimierung der Kapazitäts- bzw. Durchsatzverteilung auf die Volumes innerhalb eines Kapazitätspools können ggf. Kapazitätspooltypen mit manueller QoS verwendet werden.
• Kapazitätspoolgröße: Die Poolgröße. Die Kapazität eines Volumes basiert auf einem Kapazitätspool. Kapazitätspools werden in 1-TiB-Schritten dimensioniert.
• Kapazitätspoolkosten (USD/Monat): Die monatlichen Kosten des Kapazitätspools mit der angegebenen Größe und Dienstebene.
• Volume-Showback (USD/Monat): Die monatlichen Kapazitätskosten für das Volume bei der angegebenen Kapazität. Die Gebühren basieren auf den zugeordneten Kapazitätspoolgrößen. Volume-Showback gibt den Volumebetrag an.

Die Kosten können nach Bedarf mithilfe der Volumegestaltung in Azure NetApp Files gesteuert werden. Zur Beeinflussung von Leistung und Kosten stehen zwei dynamische Optionen zur Verfügung:

• Dynamisches Ändern der Größe eines Volumes und Kapazitätspools
• Dynamisches Ändern der Dienstebene eines Volumes

Weitere Informationen zum Kostenmodell von Azure NetApp Files finden Sie hier.

Datenschutz

Azure NetApp Files verwendet Momentaufnahmen, um Ihre Daten zu schützen. Momentaufnahmen bieten platzsparende, absturzkonsistente und nahezu unmittelbar verfügbare Images Ihrer Azure NetApp Files-Volumes. Momentaufnahmen können jederzeit manuell erstellt oder mithilfe einer Momentaufnahmerichtlinie für das Volume geplant werden.

Verwenden Sie eine Momentaufnahmerichtlinie, um Ihre Volumes mit automatisiertem Datenschutz zu versehen. Momentaufnahmen können mithilfe der Momentaufnahmewiederherstellung schnell am gleichen Ort wiederhergestellt werden. Alternativ können Sie eine Momentaufnahme auf einem neuen Volume wiederherstellen, um Daten schnell wiederherzustellen. Die Funktion für die Wiederherstellung auf einem neuen Volume kann auch verwendet werden, um Test-/Entwicklungsumgebungen mit aktuellen Daten bereitzustellen.

Zur weiteren Verbesserung des Datenschutzes können Datenschutzlösungen genutzt werden, die die Azure NetApp Files-Sicherung oder die Sicherungssoftware eines Partners verwenden.

Komponenten

• Azure Virtual Machines: SAS Grid benötigt eine hohe Arbeitsspeicher-, Speicher- und E/A-Bandbreite in einem angemessenen Verhältnis zur Anzahl von Kernen. Azure bietet vordefinierte VM-Größen mit weniger vCPUs, die ein ausgewogenes Verhältnis zwischen erforderlichen Kernen und der Arbeitsspeicher-, Speicher- und E/A-Bandbreite ermöglichen.

  Weitere Informationen finden Sie unter Eingeschränkte vCPU-fähige VM-Größen. Es ist wichtig, genau zu verstehen, welche Computeressourcen für jede Instanz verfügbar sind. Für die Ausführung von SAS Grid in Azure mit Azure NetApp Files werden folgende Instanztypen empfohlen:

  • „Standard_E64-16ds_v4“ oder „Standard_E64-16ds_v5“
  • „Standard_E64-32ds_v4“ oder „Standard_E64-32ds_v5“

  Machen Sie sich unbedingt mit den bewährten Methoden für die Verwendung von SAS in Azure sowie mit den Aktualisierungen in den Kommentaren vertraut.

• Azure NetApp Files: Sie können SASDATA auf einem Azure NetApp Files-Volume speichern, das im gesamten Computecluster genutzt wird.

  Optional können auch Azure NetApp Files-NFS-Volumes für SASWORK verwendet werden.

  Für Azure NetApp Files stehen drei leistungsbezogene Dienstebenen zur Verfügung:

  • Standard
  • Premium
  • Ultra

  Ihre Volumeleistung hängt in erster Linie von der Dienstebene ab. Die Größe Ihres Volumes ist ebenfalls ein Faktor, da der mögliche Durchsatz durch die Dienstebene und die Größe des Volumes bestimmt wird.

Speicheroptionen für SASDATA

Da Azure NetApp Files Speicherzugriff mit hohem Durchsatz und geringer Wartezeit bieten kann, ist Azure NetApp Files eine geeignete (und schnellere) Alternative zu Premium-Datenträgern. Network Attached Storage (NAS) wird nicht wie bei verwalteten Datenträgern auf VM-Ebene gedrosselt, sodass Sie von einem höheren Speicherdurchsatz profitieren.

Verwenden Sie den Azure NetApp Files-Leistungsrechner, um die erforderliche Ebene für Ihre SASDATA-Kapazität zu schätzen. (Wählen Sie advanced aus.)

Da es sich bei NFS-Volumes von Azure NetApp Files um gemeinsam genutzte Volumes handelt, eignen sie sich gut zum Hosten von SASDATA – vorausgesetzt, sie werden mit ordnungsgemäß dimensionierten VM-Instanztypen und mit der RHEL-Distribution verwendet, wie weiter unten in diesem Artikel erläutert.

Speicheroptionen für SASWORK

Die folgende Tabelle enthält die gängigsten Speicheroptionen für die Bereitstellung von SASWORK in Azure. Je nach Größe (Kapazität) und Geschwindigkeit (Bandbreite) stehen drei Optionen zur Auswahl: temporärer Speicher, verwalteter Datenträger und Azure NetApp Files.

	Temporärer Speicher	Managed Disk	Azure NetApp Files
Size	Klein	Groß	Sehr groß
Geschwindigkeit	Sehr groß	Klein	Medium

Bei der Wahl einer Option muss Folgendes berücksichtigt werden:

• Temporärer Speicher (oder flüchtiger Speicher) bietet die höchste Bandbreite, ist aber nur in kleineren Größen verfügbar. (Die Größe hängt von der VM-SKU ab.) Je nach verfügbarer und erforderlicher Kapazität ist diese Option ggf. am besten geeignet.
• Wenn die erforderliche SASWORK-Kapazität die Größe des temporären Speichers der ausgewählten VM-SKU übersteigt, empfiehlt sich die Verwendung eines verwalteten Azure-Datenträgers zum Hosten von SASWORK. Beachten Sie jedoch, dass der Durchsatz für einen verwalteten Datenträger entwurfsbedingt durch die VM-Architektur begrenzt ist und je nach VM-SKU variiert. Daher ist diese Speicheroption nur für Umgebungen mit niedrigeren SASWORK-Leistungsanforderungen geeignet.
• Für besonders hohe SASWORK-Kapazitätsanforderungen und eine durchschnittliche Leistungsanforderung, die über das hinausgeht, was verwaltete Azure-Datenträger bieten können, sollte Azure NetApp Files für SASWORK verwendet werden. Diese Option zeichnet sich durch ihre Größe und ihren schnellen Durchsatz aus.

Berücksichtigen Sie den Umfang der Bereitstellung, die Anzahl von VMs und Kernen sowie die zugehörigen Kapazitäts- und Leistungsanforderungen, wenn Sie anhand der obigen Tabelle entscheiden, ob Ihre Anforderungen klein, groß, mittel oder sehr groß sind. Diese Bewertungen sind bei jeder Bereitstellung erforderlich.

Die Optionen in der Tabelle entsprechen Bereitstellungen, die in den nachfolgenden Architekturen beschrieben werden. In allen Szenarien wird SASDATA auf einem NFS-Volume von Azure NetApp Files gehostet und von allen Computeknoten gemeinsam genutzt. Bei einigen RHEL-Distributionen empfiehlt sich die Verwendung der NFS-Option nconnect, um mehrere Netzwerkdatenflüsse zum Volume zu erstellen. Weitere Informationen finden Sie im Abschnitt NFS-Einbindungsoptionen dieses Artikels.

Architektur mit temporärem Speicher

Für kleinere SASWORK-Kapazitätsanforderungen ist temporärer Azure-VM-Speicher eine schnelle und kostengünstige Lösung. In dieser Architektur ist jeder virtuelle Computer auf der Computeebene mit temporärem Speicher ausgestattet. Informationen zum Ermitteln der Größen des temporären Speichers für die von Ihnen verwendeten virtuellen Computer finden Sie in der Dokumentation zu virtuellen Computern in Azure.

Datenfluss

• Ein Serverknoten liest Eingabedaten aus SASDATA und schreibt Ergebnisse in SASDATA zurück.
• Eine nachfolgende Komponente des Analyseauftrags kann von einem anderen Knoten auf der Computeebene ausgeführt werden. Sie verwendet das gleiche Verfahren, um die zu verarbeitenden Informationen abzurufen und zu speichern.
• Das temporäre Arbeitsverzeichnis SASWORK wird nicht gemeinsam genutzt. Es wird auf jedem Computeknoten im temporären Speicher gespeichert.

Architektur mit verwalteten Datenträgern

Wenn Ihre Kapazitätsanforderungen für SASWORK die im temporären Speicher verfügbaren Kapazitäten übersteigen, sind verwaltete Azure-Datenträger eine gute Alternative. Verwaltete Datenträger sind in verschiedenen Größen und Leistungsstufen verfügbar. Weitere Informationen finden Sie unter Skalierbarkeits- und Leistungsziele für VM-Datenträger.

Datenfluss

• Ein Serverknoten liest Eingabedaten aus SASDATA und schreibt Ergebnisse in SASDATA zurück.
• Eine nachfolgende Komponente des Analyseauftrags kann von einem anderen Knoten auf der Computeebene ausgeführt werden. Sie verwendet das gleiche Verfahren, um die zu verarbeitenden Informationen abzurufen und zu speichern.
• Das temporäre Arbeitsverzeichnis SASWORK wird nicht gemeinsam genutzt. Es wird auf einem verwalteten Datenträger gespeichert, der mit dem jeweiligen Computeknoten verbunden ist.

Architektur mit Azure NetApp Files

Bei höheren SASWORK-Kapazitätsanforderungen oder mittleren Leistungsanforderungen sollte Azure NetApp Files verwendet werden. Azure NetApp Files bietet Volumenkapazitäten bis zu 100 TiB mit einem regulären Volume und 1 PiB mit einem großen Volume. Jeder Knoten auf der Computeebene muss über ein eigenes SASWORK-Volume verfügen. Die Volumes dürfen nicht gemeinsam genutzt werden.

Datenfluss

• Ein Serverknoten liest Eingabedaten aus SASDATA und schreibt Ergebnisse in SASDATA zurück.
• Eine nachfolgende Komponente des Analyseauftrags kann von einem anderen Knoten auf der Computeebene ausgeführt werden. Sie verwendet das gleiche Verfahren, um die zu verarbeitenden Informationen abzurufen und zu speichern.
• Das temporäre Arbeitsverzeichnis SASWORK wird nicht gemeinsam genutzt. Es wird auf einzelnen Azure NetApp Files-Volumes gespeichert, die jeweils mit den einzelnen Computeknoten verbunden sind.

Skalierungs- und Konfigurationsempfehlungen

• Achten Sie darauf, dass alle virtuellen Computer in der gleichen Näherungsplatzierungsgruppe erstellt werden, um eine bestmögliche und konsistente Wartezeit für Datenverkehr zwischen den Instanzen im SAS-Cluster zu erzielen.
• Lesen Sie den allgemeinen Optimierungsleitfaden aus den bewährten Methoden für die Verwendung von SAS in Azure.
• Aktivieren Sie den beschleunigten Netzwerkbetrieb, um eine optimale Netzwerkbandbreite zu erzielen.

RHEL-Distributionen und NFS-Einstellungen

RHEL-Distributionen

RHEL ist die empfohlene Distribution zum Ausführen von SAS 9 unter Linux. Für jeden von Red Hat unterstützten Kernel gelten eigene NFS-Bandbreiteneinschränkungen.

Einzelheiten zum Ausführen von SAS in Azure finden Sie in den bewährten Methoden für die Verwendung von SAS in Azure.

Für SAS werden virtuelle Computer vom Typ „Azure Standard_E64-16ds_v4“ oder „Standard_E64-32ds_v4“ bzw. deren v5-Pendants empfohlen. Dieser Abschnitt enthält einige Richtlinien für die Verwendung von SAS mit Azure NetApp Files – unter Berücksichtigung der obigen Empfehlungen.

• Bei Verwendung von RHEL 7 ist „Standard_E64-16ds_v4“ oder „Standard_E64-16ds_v5“ die beste Wahl, basierend auf dem Zielwert von 100 MiB/s pro physischem Kern für SASDATA.

  • Standard_E64-16ds_v4: 90–100 MiB/s pro Kern
  • Standard_E64-32ds_v4: 45–50 MiB/s pro Kern

• Bei Verwendung von RHEL 8.2 sind „Standard_E64-16ds_v4“ und „Standard_E64-32ds_v4“ bzw. deren v5-Pendants mögliche Optionen. „Standard_E64-16ds_v4“ wird angesichts des Zielwerts von 100 MiB/s pro Kern für SASDATA bevorzugt.

  • Standard_E64-16ds_v4: 150–160 MiB/s pro Kern
  • Standard_E64-32ds_v4: 75–80 MiB/s pro Kern

• Bei Verwendung von RHEL 8.3 sind sowohl „Standard_E64-16ds_v4“ als auch „Standard_E64-32ds_v4“ sowie die entsprechenden v5-Pendants vollständig akzeptabel, angesichts des Durchsatzziels pro Kern:

  • 3.200 MiB/s für Lesevorgänge laut Prüfung.
  • Diese Ergebnisse werden mit der NFS-Einbindungsoption nconnect erzielt.

Tests zeigen, dass eine einzelne RHEL 7-Instanz für einen einzelnen Azure NetApp Files-Speicherendpunkt (Netzwerksocket) einen maximalen Lesedurchsatz von etwa 750 bis 800 MiB/s erreicht. Bei Schreibvorgängen sind 1.500 MiB/s für den gleichen Endpunkt erreichbar, wenn Sie rsize mit 64 KiB und die NFS-Bereitstellungsoption wsize verwenden. Es gibt Hinweise darauf, dass die zuvor erwähnte Obergrenze beim Lesedurchsatz ein Artefakt des Kernels 3.10 ist. Weitere Informationen finden Sie unter RHEL CVE-2019-11477.

Tests zeigen, dass eine einzelne RHEL 8.2-Instanz mit dem zugehörigen Kernel 4.18 frei von den Einschränkungen ist, die im Kernel 3.10 vermerkt sind. So ist Lesedatenverkehr mit 1.200–1.300 MiB/s erreichbar, wenn Sie rsize mit 64 KiB und die NFS-Bereitstellungsoption wsize verwenden. Bei umfangreichen sequenziellen Schreibvorgängen können Sie den gleichen Durchsatz von 1.500 MiB/s erwarten, den Sie auch mit RHEL 7 erzielen würden.

Bei einer einzelnen RHEL 8.3-Instanz mit der Bereitstellungsoption „nconnect“ (neu in der RHEL 8.3-Distribution) ist von einem einzelnen Azure NetApp Files-Volume aus ein Lesedurchsatz von etwa 3.200 MiB/s erreichbar. Bei Schreibvorgängen auf ein einzelnes Azure NetApp Files-Volume sind auch bei Anwendung von nconnect nicht mit mehr als 1.500 MiB/s zu rechnen.

Abstimmbare Kernel-Werte

Slottabelleneinträge

NFSv3 bietet keinen Mechanismus zum Aushandeln von Parallelität zwischen Client und Server. Client und Server definieren ihre Grenzen jeweils unabhängig voneinander. Um die beste Leistung zu erzielen, sollten Sie die maximale Anzahl der clientseitigen Einträge in der Slottabelle sunrpc mit derjenigen in Einklang bringen, die ohne Pushback auf den Server unterstützt wird. Wenn ein Client die Workloadverarbeitung des Servernetzwerkstapels überlastet, reagiert der Server mit einer Verkleinerung des Fensters für die Verbindung, was für die Leistung nicht ideal ist.

Bei modernen Linux-Kerneln ist die Eintragsgröße sunrpc.max_tcp_slot_table_entries der Slottabelle sunrpc pro Verbindung standardmäßig so festgelegt, dass 65.536 ausstehende Vorgänge unterstützt werden. Diese Slottabelleneinträge bestimmen die Grenzwerte für Parallelität. So hohe Werte sind unnötig, da Azure NetApp Files standardmäßig auf 128 ausstehende Vorgänge festgelegt ist.

Es empfiehlt sich, den Client auf den gleichen Wert zu optimieren:

• Abstimmbare Kernel-Werte (über /etc/sysctl.conf)
  • sunrpc.tcp_max_slot_table_entries=128

Abstimmbare Dateisystemcache-Werte

Sie müssen auch mit diesen Faktoren von abstimmbaren Dateisystemcache-Werten vertraut sein:

• Beim Leeren eines geänderten Puffers bleiben die Daten in einem fehlerfreien Zustand für zukünftige Lesevorgänge verwendbar, bis hohe Arbeitsspeicherauslastung zur Entfernung führt.
• Es gibt drei Trigger für einen asynchronen Leerungsvorgang:
  • Zeitbasiert: Wenn ein Puffer das durch den abstimmbaren Wert vm.dirty_expire_centisecs oder vm.dirty_writeback_centisecs definierte Alter erreicht, muss er für die Bereinigung (d. h. Leeren oder Schreiben in den Speicher) gekennzeichnet werden.
  • Hohe Arbeitsspeicherauslastung: Ausführliche Informationen finden Sie unter vm.dirty_ratio | vm.dirty_bytes.
  • Schließen: Wenn ein Dateihandle geschlossen wird, werden alle geänderten Puffer asynchron in den Speicher geleert.

Diese Faktoren werden von vier abstimmbaren Werten gesteuert. Die einzelnen abstimmbaren Werte können dynamisch und dauerhaft mithilfe von tuned oder sysctl in der Datei /etc/sysctl.conf optimiert werden. Die Abstimmung dieser Variablen verbessert die Leistung für SAS Grid:

• Abstimmbare Kernel-Werte (über benutzerdefiniertes angepasstes Profil)
  • include = throughput-performance
  • vm.dirty_bytes = 31457280
  • vm.dirty_expire_centisecs = 100
  • vm.dirty_writeback_centisecs = 300

NFS-Einbindungsoptionen

Für gemeinsam genutzte NFS-Dateisysteme, die für dauerhafte SASDATA-Dateien verwendet werden, werden folgende NFS-Einbindungsoptionen empfohlen:

RHEL 7 und 8.2

bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev

RHEL 8.3

bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev,nconnect=8

Für SASWORK-Volumes werden folgende Bereitstellungsoptionen empfohlen. Hierbei werden die entsprechenden Volumes ausschließlich für SASWORK verwendet und nicht gemeinsam von mehreren Knoten genutzt:

RHEL 7 und 8.2

bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev,nocto

RHEL 8.3

bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev,nocto,nconnect=8

Weitere Informationen zu den Vorteilen und Kosten der Bereitstellungsoption nocto finden Sie unter Close-to-Open-Konsistenz und Cacheattributtimer.

Lesen Sie außerdem die Informationen unter Azure NetApp Files: Dateifreigabesystem für SAS Grid in Microsoft Azure, einschließlich aller Aktualisierungen in den Kommentaren.

Einstellungen für NFS-Read-Ahead

Es empfiehlt sich, den abstimmbaren Wert für NFS-Read-Ahead für alle RHEL-Distributionen auf 15.360 KiB festzulegen. Weitere Informationen finden Sie unter Dauerhaftes Festlegen von Read-Ahead für NFS-Bereitstellungen.

Alternativen

Die Speicherlösung in den vorherigen Architekturen ist hochverfügbar, wie in der Vereinbarung zum Servicelevel für Azure NetApp Files angegeben. Um den Schutz und die Verfügbarkeit noch weiter zu verbessern, können Sie die Speichervolumes mithilfe der regionsübergreifenden Replikation von Azure NetApp Files in einer anderen Azure-Region replizieren.

Die Replikation der Volumes über die Speicherlösung hat zwei wichtige Vorteile:

• Die virtuellen Anwendungscomputer werden nicht zusätzlich belastet.
• Dank dieser Lösung müssen während des Normalbetriebs keine virtuellen Computer in der Zielregion ausgeführt werden.

Die Speicherinhalte werden ohne Nutzung von Computeinfrastrukturressourcen repliziert, und die SAS-Software muss in der Zielregion nicht ausgeführt werden. Die virtuellen Zielcomputer müssen nicht ausgeführt werden, um dieses Szenario zu unterstützen.

Die folgende Architektur zeigt, wie der Speicherinhalt in Azure NetApp Files in einer zweiten Region repliziert wird. Dort wird der Speicher mit einem Replikat der Produktionsdaten aufgefüllt. Bei einem Failover wird die sekundäre Region online geschaltet, und die virtuellen Computer werden gestartet, damit die Produktion in der zweiten Region fortgesetzt werden kann. Sie müssen den Datenverkehr an die zweite Region umleiten. Hierzu müssen Lastenausgleichsmodule neu konfiguriert werden (nicht im Diagramm dargestellt).

Die typische RPO für diese Lösung beträgt weniger als 20 Minuten, wenn das Aktualisierungsintervall für die regionsübergreifende Replikation auf zehn Minuten festgelegt ist.

Datenfluss

• Ein Serverknoten liest Eingabedaten aus SASDATA und schreibt Ergebnisse in SASDATA zurück.
• Eine nachfolgende Komponente des Analyseauftrags kann von einem anderen Knoten auf der Computeebene ausgeführt werden. Sie verwendet das gleiche Verfahren, um die zu verarbeitenden Informationen abzurufen und zu speichern.
• Das temporäre Arbeitsverzeichnis SASWORK wird nicht gemeinsam genutzt. Es wird auf einzelnen Azure NetApp Files-Volumes gespeichert, die jeweils mit den einzelnen Computeknoten verbunden sind.
• Die regionsübergreifende Replikation von Azure NetApp Files repliziert das SASDATA-Volume einschließlich aller Momentaufnahmen asynchron in einer Notfallwiederherstellungsregion, um ein Failover bei einem regionalen Notfall zu erleichtern.

Überlegungen

Diese Überlegungen setzen die Säulen des Azure Well-Architected Framework um, das aus einer Reihe von Leitprinzipien besteht, die zur Verbesserung der Qualität einer Workload verwendet werden können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

Azure NetApp Files bietet eine standardmäßige SLA mit 99,99 % Verfügbarkeit für alle Ebenen und alle unterstützten Regionen. Azure NetApp Files unterstützt auch die Bereitstellung von Volumes in von Ihnen ausgewählten Verfügbarkeitszonen sowie zonenübergreifende Hochverfügbarkeitsbereitstellungen.

Für verbesserte RPO- bzw. RTO-SLAs ist der integrierte Datenschutz mit Momentaufnahmen und Sicherungen im Dienst enthalten. Die regionsübergreifende Replikation bietet die gleichen Vorteile für alle Azure-Regionen.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und vor dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Azure NetApp Files bietet ein gewisses Maß an Sicherheit, da Volumes innerhalb Ihrer virtuellen Netzwerke bereitgestellt werden und der Datenverkehr Ihre virtuellen Netzwerke nicht verlässt. Es gibt keinen öffentlich adressierbaren Endpunkt. Daten im Ruhezustand sind durchgehend verschlüsselt. Optional können Daten auch während der Übertragung verschlüsselt werden.

Azure Policy unterstützt Sie bei der Erzwingung von Organisationsstandards sowie bei der Bewertung der Compliance im großen Stil. Azure NetApp Files unterstützt Azure Policy über benutzerdefinierte und integrierte Richtliniendefinitionen.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

Leistung

Behalten Sie abhängig von Ihren Durchsatz- und Kapazitätsanforderungen Folgendes im Hinterkopf:

• Die Überlegungen zur Leistung für Azure NetApp Files
• Die Anforderungen hinsichtlich Azure NetApp Files Kapazität und Dienstebene für SASDATA
• Den Leitfaden in diesem Artikel zum Auswählen eines Speichertyps für SASWORK

Skalierbarkeit

Sie können die Computeleistung mühelos skalieren, indem Sie den Skalierungsgruppen, die die drei Ebenen der SAS-Lösung ausführen, virtuelle Computer hinzufügen.

Der Speicher von Azure NetApp Files-Volumes kann dynamisch skaliert werden. Bei Verwendung von automatischer QoS wird gleichzeitig die Leistung skaliert. Für eine präzisere Steuerung der einzelnen Volumes können Sie die Leistung jedes Volumes auch separat steuern, indem Sie manuelle QoS für Ihre Kapazitätspools verwenden.

Azure NetApp Files-Volumes sind in drei Leistungsstufen verfügbar: Ultra, Premium und Standard. Wählen Sie die Stufe aus, die Ihren Leistungsanforderungen am besten entspricht, und berücksichtigen Sie dabei, dass die verfügbare Leistungsbandbreite zusammen mit der Größe eines Volumes skaliert wird. Sie können die Dienstebene eines Volumes jederzeit ändern. Weitere Informationen zum Kostenmodell von Azure NetApp Files finden Sie in diesen Preisbeispielen.

Für den Einstieg kann der Azure NetApp Files-Leistungsrechner verwendet werden.

Kostenoptimierung

Bei der Kostenoptimierung geht es darum, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Kostenmodell

Das Verständnis des Kostenmodells für Azure NetApp Files hilft Ihnen bei der Verwaltung Ihrer Ausgaben.

Die Abrechnung von Azure NetApp Files basiert auf der bereitgestellten Speicherkapazität, die durch Erstellen von Kapazitätspools zugeordnet wird. Kapazitätspools werden monatlich auf Grundlage der festgelegten Kosten pro zugeordnetem GiB pro Stunde abgerechnet.

Wenn die Größenanforderungen Ihres Kapazitätspools schwanken (z. B. aufgrund variabler Kapazitäts- oder Leistungsanforderungen), sollten Sie eine dynamische Größenänderung Ihrer Volumes und Kapazitätspools in Betracht ziehen, um die Kosten mit Ihren Kapazitäts- und Leistungsanforderungen ins Gleichgewicht zu bringen.

Wenn Ihre Anforderungen an die Größe des Kapazitätspools gleich bleiben, aber die Anforderungen an die Leistung schwanken, sollten Sie erwägen, den Servicelevel eines Volumes dynamisch zu ändern. Sie können im Laufe des Monats Kapazitätspools unterschiedlicher Arten bereitstellen bzw. deren Bereitstellung aufheben, um Just-In-Time-Leistung bereitzustellen und die Kosten in Zeiträumen, in denen keine Hochleistung erforderlich ist, zu senken.

Preise

Entscheiden Sie basierend auf Ihren Kapazitäts- und Leistungsanforderungen, welche Azure NetApp Files-Dienstebene (Standard, Premium oder Ultra) Sie benötigen. Verwenden Sie dann den Azure-Preisrechner, um die Kosten für diese Komponenten auszuwerten:

• Komponenten von SAS in Azure
• Azure NetApp Files
• Verwalteter Datenträger (optional)
• Virtuelles Netzwerk

Optimaler Betrieb

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.

SAS Grid in Azure bietet Flexibilität und eine schnelle Bereitstellung. Im Anschluss sind einige Vorteile aufgeführt:

• Erfüllung sich ändernder Geschäftsanforderungen mit dynamischem Workloadausgleich
• Erstellung einer hochverfügbaren SAS-Computingumgebung
• Schnellere Ergebnisse aus Ihrer bereits vorhandenen IT-Infrastruktur
• Inkrementeller und kostengünstiger Ausbau von Computerressourcen
• Verwaltung aller Analyseworkloads
• Einfacher Übergang von einer isolierten Serverumgebung oder einer Umgebung mit mehreren PCs zu einer SAS Grid-Umgebung

Bereitstellen dieses Szenarios

Es empfiehlt sich, die Workloads mithilfe eines IaC-Prozesses (Infrastructure-as-Code) bereitzustellen. SAS-Workloads können anfällig für Fehlkonfigurationen sein. Diese treten vor allem bei manuellen Bereitstellungen auf und verringern die Produktivität deutlich.

Informationen zum Entwerfen Ihrer Lösung für SAS Grid in Azure finden Sie unter Architektur von SAS in Azure sowie unter Automatisieren der SAS-Bereitstellung in Azure mithilfe von GitHub Actions.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• Geert van Teylingen | Group Product Manager
• Arnt de Gier | Technical Marketing Engineer

Andere Mitwirkende:

• Mick Alberts | Technical Writer

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• Schnellstart-Webinar zu den ersten Schritten in Azure
• Azure NetApp Files: Dateifreigabesystem für SAS Grid in Azure
• Azure NetApp Files Performance Calculator (Azure NetApp Files-Leistungsrechner)
• Azure NetApp Files-Dokumentation
• Training: Einführung in Azure NetApp Files
• Anforderungen und Überlegungen für große Volumes

Zugehörige Ressourcen

• SAS in Azure: Größenempfehlungen für VMs
• SAS in Azure: Azure NetApp Files
• SAS in Azure: Überlegungen zum Netzwerk und zur VM-Platzierung
• SAS in Azure: Sicherheitsüberlegungen