Utforska NFS v4.1-volymer på Azure NetApp Files

Slutförd

Azure NetApp Files (ANF) tillhandahåller interna NFS-resurser (Network File System) som kan användas för /hana/shared, /hana/data och /hana/log-volymer . Användning av ANF-baserade NFS-resurser för volymerna /hana/data och /hana/log kräver användning av NFS-protokollet v4.1. NFS-protokollet v3 stöds inte för användning av /hana/data - och /hana/log-volymer när du baserar resurserna på ANF.

Viktigt!

NFS v3-protokollet som implementeras på Azure NetApp Files stöds inte för att användas för /hana/data och /hana/log. Användningen av NFS 4.1 är obligatorisk för /hana/data - och /hana/loggvolymer ur funktionell synvinkel. För den /hana/delade volymen kan NFS v3 eller NFS v4.1-protokollet användas ur funktionell synvinkel.

Viktigt!

Tänk på följande viktiga överväganden när du överväger Azure NetApp Files för SAP Netweaver och SAP HANA:

• Den minsta kapacitetspoolen är 4 TiB.
• Den minsta volymstorleken är 100 GiB.
• Azure NetApp Files och alla virtuella datorer, där Azure NetApp Files-volymer monteras, måste finnas i samma virtuella Azure-nätverk eller i peerkopplade virtuella nätverk i samma region.
• Det är viktigt att de virtuella datorerna distribueras i närheten av Azure NetApp Storage för låg svarstid.
• Det valda virtuella nätverket måste ha ett undernät, delegerat till Azure NetApp Files.
• Kontrollera att svarstiden från databasservern till ANF-volymen mäts och under 1 millisekunder.
• Dataflödet för en Azure NetApp-volym är en funktion av volymkvoten och tjänstnivån, enligt beskrivningen i Tjänstnivå för Azure NetApp Files. När du ändrar storlek på SAP HANA Azure NetApp-volymerna kontrollerar du att det resulterande dataflödet uppfyller SAP HANA-systemkraven.
• Försök att "konsolidera" volymer för att uppnå mer prestanda i en större volym, till exempel använda en volym för /sapmnt, /usr/sap/trans, ... om möjligt.
• Azure NetApp Files erbjuder exportprincip: du kan styra de tillåtna klienterna, åtkomsttypen (läs- och skrivskyddad, skrivskyddad osv.).
• Azure NetApp Files-funktionen är inte zonmedveten ännu. För närvarande distribueras inte Azure NetApp Files-funktionen i alla tillgänglighetszoner i en Azure-region. Tänk på de potentiella fördröjningskonsekvenserna i vissa Azure-regioner.
• Användar-ID för sidadm och grupp-ID för sapsys på de virtuella datorerna måste matcha konfigurationen i Azure NetApp Files.

Viktigt!

Det är viktigt med låg fördröjning för SAP HANA-arbetsbelastningar. Samarbeta med din Microsoft-representant för att säkerställa att de virtuella datorerna och Azure NetApp Files-volymerna distribueras i närheten. Om det finns ett matchningsfel mellan användar-ID för sidadm och grupp-ID för sapsys mellan den virtuella datorn och Azure NetApp-konfigurationen visas behörigheterna för filer på Azure NetApp-volymer, monterade på den virtuella datorn, som ingen. Se till att ange rätt användar-ID för sidadm och grupp-ID för sapsys när du går ombord på ett nytt system till Azure NetApp Files.

Distribution med zonindelad närhet

Om du vill få en zonindelad närhet till dina NFS-volymer och virtuella datorer kan du följa anvisningarna enligt beskrivningen i Hantera volymplacering i tillgänglighetszonen för Azure NetApp Files. Med den här metoden kommer de virtuella datorerna och NFS-volymerna att finnas i samma Azure-tillgänglighetszon. I de flesta Azure-regioner bör den här typen av närhet vara tillräcklig för att uppnå mindre än 1 millisekunders svarstid för de mindre omgjorda loggskrivningarna för SAP HANA. Den här metoden kräver inget interaktivt arbete med Microsoft för att placera och fästa virtuella datorer i ett specifikt datacenter. Därför är du flexibel med ändra VM-storlekar och familjer inom alla typer av virtuella datorer och familjer som erbjuds i tillgänglighetszonen som du distribuerade. Så att du kan reagera flexibelt på föränderliga förhållanden eller gå snabbare till mer kostnadseffektiva VM-storlekar eller familjer. Vi rekommenderar den här metoden för icke-produktionssystem och produktionssystem som kan fungera med redo log latencies som är närmare 1 millisekunder. Funktionen är för närvarande i offentlig förhandsversion.

Distribution via Azure NetApp Files-programvolymgrupp för SAP HANA (AVG)

För att distribuera ANF-volymer med närhet till den virtuella datorn utvecklades en ny funktion som kallas Azure NetApp Files-programvolymgrupp för SAP HANA (AVG). Det finns en serie artiklar som dokumenterar funktionerna. Det bästa är att börja med artikeln Förstå azure NetApp Files-programvolymgruppen för SAP HANA. När du läser artiklarna blir det tydligt att användningen av AVG:er även omfattar användning av Närhetsplaceringsgrupper i Azure. Närhetsplaceringsgrupper används av de nya funktionerna för att kopplas till de volymer som skapas. För att säkerställa att de virtuella datorerna under SAP HANA-systemets livslängd inte kommer att flyttas från ANF-volymerna rekommenderar vi att du använder en kombination av Avset/PPG för var och en av de zoner som du distribuerar till. Distributionsordningen skulle se ut så här:

• Med hjälp av formuläret måste du begära en fästning av den tomma AvSet till en beräknings-HW för att säkerställa att virtuella datorer inte kommer att flyttas
• Tilldela en PPG till tillgänglighetsuppsättningen och starta en virtuell dator som tilldelats den här tillgänglighetsuppsättningen
• Använda Azure NetApp Files-programvolymgruppen för SAP HANA-funktioner för att distribuera dina SAP HANA-volymer

Konfigurationen av närhetsplaceringsgruppen för användning av AVG:er på ett optimalt sätt skulle se ut så här:

Diagrammet visar att du ska använda en azure-närhetsplaceringsgrupp för DBMS-lagret. Så att den kan användas tillsammans med AVG:er. Det är bäst att bara inkludera de virtuella datorer som kör SAP HANA-instanserna i närhetsplaceringsgruppen. Närhetsplaceringsgruppen är nödvändig, även om endast en virtuell dator med en enda SAP HANA-instans används, för att AVG ska kunna identifiera den närmaste närheten till ANF-maskinvaran. Och för att allokera NFS-volymen på ANF så nära en eller flera virtuella datorer som använder NFS-volymerna så nära som möjligt.

Den här metoden genererar de mest optimala resultaten eftersom den relaterar till låg svarstid. Inte bara genom att få NFS-volymerna och de virtuella datorerna så nära varandra som möjligt. Men överväganden för att placera data och göra om loggvolymer mellan olika kontrollanter på NetApp-serverdelen beaktas också. Nackdelen är dock att distributionen av den virtuella datorn är fäst på ett datacenter. Med det förlorar du flexibilitet i föränderliga typer av virtuella datorer och familjer. Därför bör du begränsa den här metoden till de system som absolut kräver så låg lagringsfördröjning. För alla andra system bör du försöka distribuera med en traditionell zonindelad distribution av den virtuella datorn och ANF. I de flesta fall räcker det med låg svarstid. Detta säkerställer också ett enkelt underhåll och administration av den virtuella datorn och ANF.

Tillgänglighet

ANF-systemuppdateringar och uppgraderingar tillämpas utan att påverka kundmiljön. Det definierade serviceavtalet är 99,99 %.

Volymer, IP-adresser och kapacitetspooler

Med ANF är det viktigt att förstå hur den underliggande infrastrukturen skapas. En kapacitetspool är bara en konstruktion som tillhandahåller en kapacitets- och prestandabudget och faktureringsenhet baserat på kapacitetspoolens tjänstnivå. En kapacitetspool har ingen fysisk relation till den underliggande infrastrukturen. När du skapar en volym på tjänsten skapas en lagringsslutpunkt. En enskild IP-adress tilldelas till den här lagringsslutpunkten för att ge dataåtkomst till volymen. Om du skapar flera volymer distribueras alla volymer i den underliggande bare metal-flottan, som är knuten till den här lagringsslutpunkten. ANF har en logik som automatiskt distribuerar kundarbetsbelastningar när volymerna eller/och kapaciteten för den konfigurerade lagringen når en intern fördefinierad nivå. Du kanske märker sådana fall eftersom en ny lagringsslutpunkt, med en ny IP-adress, skapas automatiskt för att få åtkomst till volymerna. ANF-tjänsten ger inte kundkontroll över den här distributionslogik.