Untersuchen von NFS v4.1-Volumes in Azure NetApp Files

  • 4 Minuten

Azure NetApp Files (ANF) verfügt über native Network File System (NFS)-Freigaben, die für die Volumes /hana/shared, /hana/data und /hana/log verwendet werden können. Zur Nutzung von ANF-basierten NFS-Freigaben für die Volumes /hana/data und /hana/log wird das v4.1 NFS-Protokoll benötigt. Das NFS-Protokoll v3 wird nicht für die Nutzung der Volumes /hana/data und /hana/log unterstützt, wenn die Freigaben auf ANF basieren.

Wichtig

Die Verwendung des NFS v3-Protokolls, das für Azure NetApp Files implementiert wurde, wird für /hana/data und /hana/lognicht unterstützt. Die Verwendung von NFS 4.1 ist für die Volumes /hana/data und /hana/log aus funktionaler Sicht obligatorisch. Während für das Volume /hana/shared das Protokoll NFS v3 oder NFS v4.1 aus funktionaler Sicht verwendet werden kann.

Diagramm mit einer Übersicht über eine hochverfügbare NFS-Freigabe.

Wichtige Hinweise

Wenn Sie Azure NetApp Files für die Hochverfügbarkeitsarchitektur von SAP NetWeaver und SAP HANA in Betracht ziehen, beziehen Sie die folgenden wichtigen Überlegungen mit ein:

  • Die Mindestgröße eines Kapazitätspools beträgt 4 TiB.
  • Die Mindestgröße des Volumes beträgt 100 GiB.
  • Azure NetApp Files und alle VMs, in denen Azure NetApp Files-Volumes eingebunden sind, müssen sich in demselben Azure Virtual Network oder in Peering-VNets in derselben Region befinden.
  • Um eine niedrige Latenz zu erzielen, ist es wichtig, dass die VMs in unmittelbarer Nähe zum Azure NetApp-Speicher bereitgestellt werden.
  • Das ausgewählte virtuelle Netzwerk muss über ein an Azure NetApp Files delegiertes Subnetz verfügen.
  • Stellen Sie sicher, dass die Latenz vom Datenbankserver zum ANF-Volume gemessen wird und unter 1 Millisekunde liegt.
  • Der Durchsatz eines Azure NetApp-Volumes ist eine Funktion des Volumekontingents und der Dienstebene, wie in Dienstebenen für Azure NetApp Files beschrieben. Stellen Sie bei der Größenanpassung der SAP HANA Azure NetApp-Volumes sicher, dass der sich ergebende Durchsatz die SAP HANA-Systemanforderungen erfüllt.
  • Versuchen Sie Volumes zu „konsolidieren“, um eine höhere Leistung auf einem größeren Volume zu erzielen. Beispiel: Verwenden Sie nach Möglichkeit je ein Volume für /sapmnt, /usr/sap/trans ... usw.
  • Azure NetApp Files bietet eine Exportrichtlinie: Sie können die zulässigen Clients oder den Zugriffstyp (Lesen und Schreiben, schreibgeschützt usw.) steuern.
  • Azure NetApp Files wertet derzeit noch keine Zonen aus. Das Azure NetApp Files-Feature wird bisher nicht in allen Verfügbarkeitszonen in einer Azure-Region bereitgestellt. Achten Sie auf mögliche Latenzauswirkungen in einigen Azure-Regionen.
  • Die Benutzer-ID für sidadm und die Gruppen-ID für sapsys auf den VMs müssen mit der Konfiguration in Azure NetApp Files übereinstimmen.

Wichtig

Bei SAP HANA-Workloads ist eine niedrige Latenz sehr wichtig. Arbeiten Sie mit Ihrem Microsoft-Vertreter zusammen, um sicherzustellen, dass die virtuellen Computer und die Azure NetApp Files-Volumes in unmittelbarer Nähe zueinander bereitgestellt werden. Wenn die Benutzer-ID für sidadm und die Gruppen-ID für sapsys auf der VM nicht der Azure NetApp-Konfiguration entsprechen, werden die Berechtigungen für Dateien auf in der VM eingebundenen Azure NetApp-Volumes als niemand angezeigt. Stellen Sie sicher, dass Sie die richtige Benutzer-ID für sidadm und die Gruppen-ID für sapsys angeben, wenn Sie ein neues System in Azure NetApp Files integrieren.

Bereitstellung mit zonaler Nähe

Um zonale Nähe Ihrer NFS-Volumes und VMs herzustellen, können Sie die Anweisungen befolgen, die unter Verwalten der Platzierung von Verfügbarkeitszonenvolumes für Azure NetApp Files beschrieben werden. Bei dieser Methode befinden sich die VMs und NFS-Volumes in derselben Azure-Verfügbarkeitszone. In den meisten Azure-Regionen sollte diese Art der Näherung ausreichen, um weniger als 1 Millisekunden Latenz für die kleineren Wiederholungsprotokollschreibvorgänge für SAP HANA zu erzielen. Diese Methode erfordert keine interaktive Zusammenarbeit mit Microsoft, um VMs in einem bestimmten Rechenzentrum zu platzieren und einzupassen. Daher sind Sie flexibel beim Ändern von VM-Größen und -Produktfamilien innerhalb aller VM-Typen und -Produktfamilien, die in der Verfügbarkeitszone angeboten werden, in der die Bereitstellung erfolgt ist. So können Sie flexibel auf sich ändernde Bedingungen reagieren oder schneller zu kosteneffizienteren VM-Größen oder -Produktfamilien wechseln. Wir empfehlen diese Methode für Nichtproduktionssysteme und Produktionssysteme, die mit Wiederholungsprotokolllatenzen arbeiten können, die näher an 1 Millisekunden liegen. Die Funktion befindet sich derzeit in der Public Preview.

Bereitstellung über Azure NetApp Files-Anwendungsvolumengruppe für SAP HANA (AVG)

Zum Bereitstellen von ANF-Volumes mit Nähe zu Ihrem virtuellen Computer wurde eine neue Funktion namens „Azure NetApp Files-Anwendungsvolumegruppe für SAP HANA (AVG)“ entwickelt. Es gibt eine Reihe von Artikeln, in denen die Funktion dokumentiert wird. Beginnen Sie am besten mit dem Artikel Grundlegendes zu Azure NetApp Files-Anwendungsvolumegruppen für SAP HANA. In diesem Artikel wird verdeutlicht, dass die Verwendung von AVGs auch die Verwendung von Azure-Näherungsplatzierungsgruppen nach sich zieht. Näherungsplatzierungsgruppen werden von der neuen Funktionalität verwendet, um Verknüpfungen mit den zu erstellenden Volumes einzurichten. Um sicherzustellen, dass die virtuellen Computer während der Lebensdauer des SAP HANA-Systems nicht von den ANF-Volumes entfernt werden, empfehlen wir die Verwendung einer Kombination aus Avset/ PPG für jede der Zonen, in denen Sie bereitstellen. Die Reihenfolge der Bereitstellung sieht wie folgt aus:

  • Sie müssen mithilfe des Formulars eine Anheftung des leeren AvSet an ein Compute-HW anfordern, um sicherzustellen, dass die VMs nicht verschoben werden.
  • Zuweisen einer PPG zur Verfügbarkeitsgruppe und Starten eines virtuellen Computers, der dieser Verfügbarkeitsgruppe zugewiesen ist
  • Verwenden der Azure NetApp Files-Anwendungsvolumegruppe für SAP HANA-Funktionen zur Bereitstellung Ihrer SAP HANA-Volumes

Die Konfiguration der Näherungsplatzierungsgruppe für die optimale Verwendung von AVGs sieht wie folgt aus:

Screenshot der A N F-Anwendungsvolumegruppe und der P P G-Architektur.

Das Diagramm zeigt, dass Sie eine Azure-Näherungsplatzierungsgruppe für die DBMS-Schicht verwenden. Dadurch kann sie zusammen mit AVGs verwendet werden. Es empfiehlt sich, nur die virtuellen Computer einzuschließen, die die SAP HANA-Instanzen in der Näherungsplatzierungsgruppe ausführen. Auch wenn nur eine VM mit einer einzigen SAP HANA-Instanz verwendet wird, ist die Näherungsplatzierungsgruppe erforderlich, damit das AVG die nächstgelegene Nähe der ANF-Hardware ermitteln kann. Und um das NFS-Volume auf ANF so nah wie möglich einem oder mehreren VMs zuzuordnen, die die NFS-Volumes verwenden.

Diese Methode generiert die besten Ergebnisse, da sie sich auf geringe Latenz bezieht. Nicht nur, indem die NFS-Volumes und VMs so nah wie möglich platziert werden. Aber auch Überlegungen zum Platzieren der Daten- und Wiederholungsprotokollvolumes auf verschiedenen Controllern im NetApp-Back-End werden berücksichtigt. Der Nachteil besteht jedoch darin, dass Ihre VM-Bereitstellung in ein Rechenzentrum eingepasst ist. Dadurch verlieren Sie Flexibilität beim Ändern von VM-Typen und -Produktfamilien. Daher sollten Sie diese Methode auf die Systeme beschränken, die eine solch geringe Speicherlatenz benötigen. Für alle anderen Systeme sollten Sie die Bereitstellung mit einer herkömmlichen zonalen Bereitstellung der VM und ANF versuchen. In den meisten Fällen reicht dies in Bezug auf niedrige Latenz aus. Dies stellt auch eine einfache Wartung und Verwaltung der VM und ANF sicher.

Verfügbarkeit

Updates und Upgrades von ANF-Systemen werden ohne Beeinträchtigung der Kundenumgebung angewendet. Der definierte SLA ist 99,99 %.

Volumes, IP-Adressen und Kapazitätspools

Bei ANF ist es wichtig zu verstehen, wie die zugrunde liegende Infrastruktur erstellt wird. Ein Kapazitätspool ist nur ein Konstrukt, das basierend auf der Dienstebene des Kapazitätspools ein Kapazitäts- und Leistungsbudget und eine Abrechnungseinheit bereitstellt. Ein Kapazitätspool hat keine physische Beziehung zur zugrunde liegenden Infrastruktur. Wenn Sie ein Volume im den Dienst erstellen, wird ein Speicherendpunkt erstellt. Diesem Speicherendpunkt wird eine einzelne IP-Adresse zugewiesen, um Datenzugriff auf das Volume zu ermöglichen. Wenn Sie mehrere Volumes erstellen, werden alle Volumes auf die zugrunde liegende Bare-Metal-Flotte verteilt, die an diesen Speicherendpunkt gebunden ist. Die ANF verfügt über eine Logik, die Kundenworkloads automatisch verteilt, sobald die Volumes oder/und die Kapazität des konfigurierten Speichers eine interne vordefinierte Stufe erreichen. Sie werden solche Fälle bemerken, da automatisch ein neuer Speicherendpunkt mit einer neuen IP-Adresse erstellt wird, um auf die Volumes zuzugreifen. Der ANF-Dienst bietet keine Kundenkontrolle über diese Verteilungslogik.