NFS v4.1-volymer på Azure NetApp Files för SAP HANA

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

Att tänka på

När du Azure NetApp Files för SAP Netweaver och SAP HANA bör du vara medveten om följande viktiga överväganden:

• 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 är monterade, måste finnas i samma Azure-Virtual Network eller i peer-ade virtuella nätverk i samma region
• Det är viktigt att de virtuella datorerna distribueras nära Azure NetApp-lagringen för korta svarstider.
• Det valda virtuella nätverket måste ha ett undernät som delegerats till Azure NetApp Files
• Kontrollera att svarstiden från databasservern till ANF-volymen mäts och understiger 1 millisekund
• Dataflödet för en Azure NetApp-volym är en funktion för volymkvoten och tjänstnivån, vilket dokumenteras i Servicenivå för Azure NetApp Files. När du storleksiserar HANA Azure NetApp-volymerna kontrollerar du att det resulterande dataflödet uppfyller HANA-systemkraven. Du kan också överväga att använda en manuell QoS-kapacitetspool där volymkapacitet och dataflöde kan konfigureras och skalas oberoende av varandra (SAP HANA exempel finns i det här dokumentet
• Försök att "konsolidera" volymer för att få bättre prestanda på 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 (skrivskyddade&skrivskyddade, skrivskyddade osv.).
• Azure NetApp Files är inte zonmedveten ännu. För Azure NetApp Files inte distribueras 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.

Storleksändring för HANA-databas på Azure NetApp Files

Dataflödet för en Azure NetApp-volym är en funktion för volymstorlek och tjänstnivå, enligt vad som dokumenteras i Tjänstnivåer för Azure NetApp Files.

Det är viktigt att förstå är prestandarelationens storlek och att det finns fysiska gränser för en lagringsslutpunkt för tjänsten. Varje lagringsslutpunkt matas in dynamiskt i Azure NetApp Files delegerade undernätet när volymen skapas och får en IP-adress. Azure NetApp Files kan dela en lagringsslutpunkt, beroende på tillgänglig kapacitet och distributionslogik

Tabellen nedan visar att det kan vara bra att skapa en stor "Standard"-volym för att lagra säkerhetskopior och att det inte är meningsfullt att skapa en "Ultra"-volym som är större än 12 TB eftersom den maximala fysiska bandbreddskapaciteten för en enskild volym skulle överskridas.

Det maximala skrivdataflödet för en volym och en linux-session är mellan 1,2 och 1,4 GB/s. Om du behöver mer dataflöde för /hana/data kan du använda SAP HANA-datavolympartitionering för att stripa I/O-aktiviteten vid inläsning av data eller HANA-sparapunkter över flera HANA-datafiler som finns på flera NFS-resurser. För att förbättra läsgenomflödet kan du använda monteringsalternativet NFS nconnect. Mer information om hur du Azure NetApp Files Linux-prestanda och nconnect finns i Metodtips för Linux NFS-monteringsalternativ för Azure NetApp Files. Mer information om striping av HANA-datavolymer finns i följande artiklar:

• Hana-administratörsguiden
• Blogg om SAP HANA – partitionering av datavolymer
• SAP-anteckning #2400005
• SAP-anteckning #2700123

^1:skriv- eller enskild sessionsläsningsflödesgränser (om NFS-monteringsalternativet nconnect inte används)

Det är viktigt att förstå att data skrivs till samma SSD:er i lagringsbackend. Prestandakvoten från kapacitetspoolen skapades för att kunna hantera miljön. De Storage KPI:erna är lika för alla HANA-databasstorlekar. I nästan alla fall återspeglar det här antagandet inte verkligheten och kundens förväntan. Storleken på HANA-system innebär inte nödvändigtvis att ett litet system kräver lågt lagringsgenomflöde – och ett stort system kräver högt lagringsgenomflöde. Men generellt kan vi förvänta oss högre dataflödeskrav för större HANA-databasinstanser. Till följd av SAP:s storleksregler för den underliggande maskinvaran ger större HANA-instanser också fler PROCESSORresurser och högre parallellitet i uppgifter som att läsa in data efter en omstart av instanser. Därför bör volymstorlekarna användas för kundens förväntningar och krav. Och inte bara drivs av rena kapacitetskrav.

När du utformar infrastrukturen för SAP i Azure bör du vara medveten om vissa krav på minsta lagringsgenomflöde (för produktionssystem) av SAP, vilket innebär minsta dataflödesegenskaper för:

Eftersom alla tre KPI:er krävs måste /hana/data-volymen ha en storlek mot den större kapaciteten för att uppfylla minimikraven för läsning. När du använder manuella QoS-kapacitetspooler kan volymernas storlek och dataflöde definieras oberoende av varandra. Eftersom både kapacitet och dataflöde tas från samma kapacitetspool måste poolens servicenivå och storlek vara tillräckligt stora för att leverera den totala prestandan (se exemplet här)

För HANA-system som inte kräver hög bandbredd kan ANF-volymens dataflöde sänkas antingen med en mindre volymstorlek eller, vid manuell QoS, justera dataflödet direkt. Och om ett HANA-system kräver mer dataflöde kan volymen anpassas genom att kapaciteten ändras online. Inga KPI:er har definierats för säkerhetskopieringsvolymer. Dataflödet för säkerhetskopieringsvolymen är dock viktigt för en miljö med bra prestanda. Log – och Datavolymprestanda måste utformas enligt kundens förväntningar.

För att uppfylla minimikraven för SAP-dataflöde för data och logg, och enligt riktlinjerna för /hana/shared, skulle de rekommenderade storlekarna se ut så här:

För alla volymer rekommenderas NFS v4.1 starkt

Storleken på säkerhetskopieringsvolymerna är uppskattningar. Exakta krav måste definieras baserat på arbetsbelastnings- och åtgärdsprocesser. För säkerhetskopieringar kan du konsolidera många volymer för olika SAP HANA instanser till en (eller två) större volymer, som kan ha en lägre servicenivå för ANF.

Därför kan du överväga att distribuera liknande dataflöde för ANF-volymerna som anges för Ultra-disklagring redan. Överväg även storlekarna för de storlekar som anges för volymerna för de olika VM-SKU:erna, som du redan gjort i Ultra-disktabellerna.

Dokumentation om hur du distribuerar en SAP HANA-utskalningskonfiguration med väntelägesnod med NFS v4.1-volymer som finns i ANF publiceras i SAP HANA-utskalning med väntelägesnodpå virtuella Azure-datorer med Azure NetApp Files på SUSE Linux Enterprise Server .

Tillgänglighet

UPPDATERINGAR och uppgraderingar av ANF-system 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 byggs. En kapacitetspool är bara en konstruktion som tillhandahåller en kapacitets- och prestandabudget och faktureringsenhet baserat på servicenivån för kapacitetspoolen. 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 lagringsslutpunkten för att ge dataåtkomst till volymen. Om du skapar flera volymer distribueras alla volymer i den underliggande bare metal-vagnpark som är kopplad till den här lagringsslutpunkten. ANF har en logik som automatiskt distribuerar kundens arbetsbelastningar 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 distributionslogiken.

Loggvolym och loggsäkerhetskopieringsvolym

"loggvolymen" (/hana/log) används för att skriva online-redo-loggen. Därför finns det öppna filer på den här volymen och det är ingen mening att ögonblicksbilder av volymen. Onlinereup-loggfiler arkiveras eller säkerhetskopieras till loggsäkerhetskopieringsvolymen när onlinereuploggfilen är full eller en säkerhetskopia av en redo-logg körs. För att tillhandahålla rimliga prestanda för säkerhetskopiering kräver loggsäkerhetskopieringsvolymen ett bra dataflöde. För att optimera lagringskostnaderna kan det vara klokt att konsolidera loggsäkerhetskopieringsvolymen för flera HANA-instanser. Så att flera HANA-instanser använder samma volym och skriver sina säkerhetskopior till olika kataloger. Med en sådan konsolidering kan du få mer dataflöde med eftersom du behöver göra volymen lite större.

Samma gäller för den volym som du använder skriv fullständiga HANA-databassäkerhetskopior till.
 

Backup

Förutom att strömma säkerhetskopior och Azure Back service säkerhetskopiering av SAP HANA-databaser enligt beskrivningen i artikeln Säkerhetskopieringsguide för SAP HANA på Azure Virtual Machinesöppnar Azure NetApp Files möjligheten att utföra lagringsbaserade säkerhetskopieringar av ögonblicksbilder.

SAP HANA stöder:

• Storage stöd för säkerhetskopiering av ögonblicksbilder för ett enskilt containersystem med SAP HANA 1.0 SPS7 och senare
• Storage för multidatabascontainer (MDC) HANA-miljöer med en enda klientorganisation med SAP HANA 2.0 SPS1 och senare
• Storage stöd för säkerhetskopiering av ögonblicksbilder för Multi Database Container (MDC) HANA-miljöer med flera klienter med SAP HANA 2.0 SPS4 och senare

Att skapa lagringsbaserade säkerhetskopior av ögonblicksbilder är en enkel procedur i fyra steg:

1. Skapa en HANA-databasögonblicksbild – en aktivitet som du eller verktyg behöver utföra
2. SAP HANA skriver data till datafilerna för att skapa ett konsekvent tillstånd på lagringen – HANA utför det här steget när en HANA-ögonblicksbild skapas
3. Skapa en ögonblicksbild på /hana/datavolymen på lagringen – ett steg som du eller verktyg behöver utföra. Du behöver inte utföra en ögonblicksbild på /hana/log-volymen
4. Ta bort HANA-databasens (interna) ögonblicksbild och återuppta normal drift – ett steg som du eller verktyg behöver utföra

BACKUP DATA FOR FULL SYSTEM CREATE SNAPSHOT COMMENT 'SNAPSHOT-2019-03-18:11:00';

az netappfiles snapshot create -g mygroup --account-name myaccname --pool-name mypoolname --volume-name myvolname --name mysnapname 

BACKUP DATA FOR FULL SYSTEM CLOSE SNAPSHOT BACKUP_ID 47110815 SUCCESSFUL SNAPSHOT-2020-08-18:11:00';

Den här proceduren för säkerhetskopiering av ögonblicksbilder kan hanteras på olika sätt med hjälp av olika verktyg. Ett exempel är Python-skriptet "ntaphana_azure.py" som är tillgängligt på GitHub Det här är exempelkod som tillhandahålls https://github.com/netapp/ntaphana "i drift" utan underhåll eller support.

Tillgängliga lösningar för lagringsögonblicksbildbaserad program konsekvent säkerhetskopiering:

• Verktyget Microsoft Azure Application Consistent Snapshot (AzAcSnap) är ett kommandoradsverktyg som möjliggör dataskydd för databaser från tredje part genom att hantera all orkestrering som krävs för att föra in dem i ett konsekvent programtillstånd innan du tar en ögonblicksbild av lagringen. Därefter får de drifttillståndet igen. AzAcSnap har stöd för ögonblicksbildsbaserade säkerhetskopieringar för både stora HANA-instanser Azure NetApp Files. Mer information finns Azure Application verktyget För konsekvent ögonblicksbild
• För användare av Commvault Backup-produkter är ett annat alternativ Commvault IntelliSnap V.11.21 och senare. Den här eller senare versionen av Commvault Azure NetApp Files stöd för ögonblicksbilder. Mer information finns i artikeln Commvault IntelliSnap 11.21.

Säkerhetskopiera ögonblicksbilden med Azure Blob Storage

Säkerhetskopiering till Azure Blob Storage är en kostnadseffektiv och snabb metod för att spara SÄKERHETSKOPIOR av ANF-baserade HANA-databaslagringsögonblicksbilder. AzCopy-verktyget är att föredra för att spara ögonblicksbilderna till Azure Blob Storage. Ladda ned den senaste versionen av det här verktyget och installera den, till exempel i bin-katalogen där Python-skriptet GitHub är installerat. Ladda ned det senaste AzCopy-verktyget:

root # wget -O azcopy_v10.tar.gz https://aka.ms/downloadazcopy-v10-linux && tar -xf azcopy_v10.tar.gz --strip-components=1
Saving to: ‘azcopy_v10.tar.gz’

Den mest avancerade funktionen är alternativet SYNKRONISERA. Om du använder alternativet SYNC behåller azcopy källan och målkatalogen synkroniserade. Det är viktigt att parametern --delete-destination används. Utan den här parametern tar azcopy inte bort filer på målplatsen och utrymmesanvändningen på målsidan skulle växa. Skapa en blockblobcontainer i ditt Azure Storage-konto. Skapa sedan SAS-nyckeln för blobcontainern och synkronisera mappen med ögonblicksbilder till Azure Blob-containern.

Om till exempel en daglig ögonblicksbild ska synkroniseras till Azure-blobcontainern för att skydda data. Och endast att en ögonblicksbild ska behållas kan kommandot nedan användas.

root # > azcopy sync '/hana/data/SID/mnt00001/.snapshot' 'https://azacsnaptmytestblob01.blob.core.windows.net/abc?sv=2021-02-02&ss=bfqt&srt=sco&sp=rwdlacup&se=2021-02-04T08:25:26Z&st=2021-02-04T00:25:26Z&spr=https&sig=abcdefghijklmnopqrstuvwxyz' --recursive=true --delete-destination=true

Nästa steg

Läs artikeln:

• SAP HANA hög tillgänglighet för virtuella Azure-datorer