Svazky NFS v4.1 ve službě Azure NetApp Files pro SAP HANA

  • Článek
  • 12 min ke čtení

Azure NetApp Files poskytuje nativní sdílené složky systému souborů NFS, které se dají použít pro svazky /Hana/Shared, /Hana/data a /Hana/log . Použití sdílených složek systému souborů NFS založených na ANF pro svazky /Hana/data a /Hana/log vyžaduje použití protokolu NFS v 4.1. Protokol NFS verze 3 není podporován pro použití /Hana/data a /Hana/log svazků při založení sdílených složek na ANF.

Důležité

Protokol NFS v3 implementovaný v Azure NetApp Files není podporován pro použití pro /Hana/data a /Hana/log. Použití NFS 4,1 je povinné pro svazky /Hana/data a /Hana/log z funkčního bodu zobrazení. Vzhledem k tomu, že je možné použít pro svazek /Hana/Shared systém souborů NFS v3 nebo NFS verze 4.1, ze funkčního hlediska.

Důležité informace

Při zvažování Azure NetApp Files SAP NetWeaver a SAP HANA si pamatujte na následující důležité informace:

  • Minimální fond kapacit je 4 TiB
  • Minimální velikost svazku je 100 GiB
  • Azure NetApp Files a všech virtuálních počítačů, ve kterých jsou připojené Azure NetApp Files svazky, musí být ve stejné oblasti Azure Virtual Network nebo v partnerských virtuálních sítích .
  • Je důležité mít virtuální počítače nasazené v těsné blízkosti úložiště Azure NetApp pro nízkou latenci.
  • Vybraná virtuální síť musí mít podsíť, delegovanou na Azure NetApp Files
  • Ujistěte se, že latence z databázového serveru na ANF svazek je měřená a menší než 1 milisekunda.
  • Propustnost svazku Azure NetApp je funkcí kvóty svazku a úrovně služeb, jak je uvedeno v části úroveň služby pro Azure NetApp Files. Při změně velikosti svazků NetApp HANA Azure se ujistěte, že výsledná propustnost splňuje požadavky na systém HANA. Zvažte také použití ručního fondu kapacity QoS , ve kterém můžete nakonfigurovat kapacitu a propustnost svazku, nezávisle (SAP HANA v tomto dokumentu konkrétní příklady.
  • Zkuste "konsolidovat" svazky a dosáhnout tak vyššího výkonu většího objemu, například pro/sapmnt,/usr/SAP/trans,... Pokud je to možné
  • Azure NetApp Files nabízí zásady exportu: můžete řídit povolené klienty, typ přístupu (čtení&zápisu, jen pro čtení atd.).
  • Azure NetApp Files funkce zatím nereaguje na zóny. Aktuálně Azure NetApp Files funkce není nasazená ve všech zónách dostupnosti v oblasti Azure. Mějte na paměti, že v některých oblastech Azure máte vliv na potenciální latenci.
  • ID uživatele pro ADM s identifikátorem SIDa ID skupiny pro sapsys virtuální počítače musí odpovídat konfiguraci v Azure NetApp Files.

Důležité

U úloh SAP HANA je klíčová nízká latence. Spolupracujte se zástupcem Microsoftu a zajistěte, aby se virtuální počítače a Azure NetApp Files svazky nasadily v těsné blízkosti.

Důležité

Pokud dojde k neshodě mezi ID uživatele pro ADM aID skupiny sapsys mezi virtuálním počítačem a konfigurací služby Azure NetApp, zobrazí se oprávnění k souborům na svazcích Azure NetApp připojených k virtuálnímu počítači nobody . Nezapomeňte zadat správné ID uživatele pro ADM s identifikátorem SIDa ID skupiny pro sapsys , když se při připojování nového systému do Azure NetApp Files nový systém .

Určení velikosti databáze HANA v Azure NetApp Files

Propustnost svazku Azure NetApp je funkcí velikosti svazku a úrovně služby, jak je uvedeno v části úrovně služeb pro Azure NetApp Files.

Důležité je pochopit, že se jedná o poměr výkonu a že existují fyzická omezení pro koncový bod služby úložiště. Každý koncový bod úložiště se dynamicky Vloží do Azure NetApp Files delegované podsítě při vytváření svazku a získání IP adresy. Azure NetApp Files svazky můžou – v závislosti na dostupné kapacitě a logice nasazení – sdílení koncového bodu úložiště

Následující tabulka ukazuje, že by mohlo být vhodné vytvořit velký "standardní" svazek pro ukládání záloh a že nemá smysl vytvořit "extrémně" svazek větší než 12 TB, protože by se překročila maximální kapacita fyzické šířky pásma jednoho svazku.

Maximální propustnost zápisu svazku a jedna relace pro Linux je mezi 1,2 a 1,4 GB/s. Pokud požadujete větší propustnost pro/Hana/data, můžete pomocí SAP HANA rozdělit datové svazky rozdělit aktivitu vstupu/výstupu během opětovného načtení dat nebo HANA úložných bodů napříč více datovými soubory HANA, které se nacházejí ve více sdílených složkách systému souborů NFS. Pro zvýšení propustnosti čtení lze použít možnost připojení NFS nconnect Mount. Další podrobnosti o Azure NetApp Files výkonu a nconnect pro Linux najdete v tématu osvědčené postupy pro Azure NetApp Files systému Linux NFS pro. Další podrobnosti o prokládaných datových svazcích HANA najdete v těchto článcích:

Velikost Propustnost Standard Premium propustnosti Propustnost Ultra
1 TB 16 MB/s 64 MB/s 128 MB/s
2 TB 32 MB/s 128 MB/s 256 MB/s
4 TB 64 MB/s 256 MB/s 512 MB/s
10 TB 160 MB/s 640 MB/s 1 280 MB/s
15 TB 240 MB/s 960 MB/s 1 400 MB/s1
20 TB 320 MB/s 1 280 MB/s 1 400 MB/s1
40 TB 640 MB/s 1 400 MB/s1 1 400 MB/s1

1: omezení propustnosti čtení nebo jedné relace (v případě použití možnosti připojení NFS nconnect se nepoužívá)

Je důležité pochopit, že data se zapisují do stejného SSD do back-endu úložiště. Kvóta výkonu z fondu kapacit byla vytvořena, aby bylo možné spravovat prostředí. klíčové ukazatele výkonu Storage jsou pro všechny velikosti databází HANA stejné. V téměř všech případech tento předpoklad neodráží realitu a očekává se, že zákazník. Velikost systémů HANA nemusí nutně znamenat, že malý systém vyžaduje nízkou propustnost úložiště – a velký systém vyžaduje vysokou propustnost úložiště. Obecně ale můžeme očekávat vyšší propustnost pro větší databázové instance HANA. V důsledku pravidel pro změny velikosti SAP pro základní hardware tyto větší instance HANA také poskytují více prostředků procesoru a vyšší paralelismus v rámci úloh, jako je načítání dat po restartování instancí. V důsledku toho by měly být velikosti svazků přijaty na očekávání a požadavky zákazníků. A neřídí se jenom čistě požadavky na kapacitu.

Při návrhu infrastruktury pro SAP v Azure byste měli znát minimální požadavky na propustnost úložiště (pro systémy výroby) pomocí SAP, který se přeloží na minimální propustnost:

Typ svazku a vstupně-výstupní typ Minimální klíčový ukazatel výkonu, který vyžádané SAP úroveň služby Premium Ultra – úroveň služby
Zápis svazku protokolu 250 MB/s 4 TB 2 TB
Zápis datového svazku 250 MB/s 4 TB 2 TB
Čtení objemu dat 400 MB/s 6,3 TB 3,2 TB

Vzhledem k tomu, že jsou všechny tři KPI vyžadované, musí být velikost svazku /hana/data velikosti směrem k větší kapacitě, aby byly splněny minimální požadavky na čtení. Při použití ručních fondů kapacity QoS je možné nezávisle definovat velikost a propustnost svazků. Vzhledem k tomu, že kapacita i propustnost se odebraly ze stejného fondu kapacity, musí být úroveň a velikost služby fondu dostatečně velké, aby bylo možné zajistit celkový výkon (viz příklad tady).

U systémů HANA, které nevyžadují velkou šířku pásma, je možné propustnost svazku ANF snížit buď menší velikostí svazku, nebo v případě ruční technologie QoS přímou úpravou propustnosti. A v případě, že systém HANA vyžaduje větší propustnost, svazek by se mohl přizpůsobit tak, že by se kapacita přizpůsobil velikosti online. Pro zálohované svazky nejsou definované žádné KPI. Propustnost zálohovacího svazku je však nezbytná pro dobře výkonná prostředí. Protokol – a Výkon objemu dat musí být navrženy podle očekávání zákazníků.

Důležité

Očekává se, že propustnost bez ohledu na kapacitu, kterou nasadíte na jeden svazek SYSTÉMU SOUBORŮ NFS, bude v rámci jedné relace 1,2–1,4 GB/s využína příjemcem. Souvisí to se základní architekturou nabídky ANF a souvisejícími limity linuxových relací týkajících se systému souborů NFS. Čísla výkonu a propustnosti, jak je zdokumentované v článku Výsledky testu srovnávacího testu výkonnosti pro Azure NetApp Files se prováděly na jednom sdíleném svazku NFS s několika klientskými virtuálními počítači a v důsledku toho s několika relacemi. Tento scénář se liší od scénáře, který měříme v SAP. Měříme propustnost z jednoho virtuálního počítače oproti svazku NFS. Hostované v ANF.

Aby byly splněny minimální požadavky sap na propustnost pro data a protokol, a v souladu s pokyny pro /hana/shared by doporučené velikosti vypadaly jako:

Svazek Velikost
Premium Storage vrstvy		 Velikost
Úroveň Storage Ultra		 Podporovaný protokol NFS
/hana/log/ 4 TiB 2 TiB v4.1
/hana/data 6.3 TiB 3.2 TiB v4.1
/hana/sdílené škálování na více instancí Min(1 TB, 1 x RAM) Min(1 TB, 1 x RAM) v3 nebo v4.1
/hana/sdílené škálování na více instancí 1× paměť RAM pracovního uzlu
na čtyři pracovní uzly		 1× paměť RAM pracovního uzlu
na čtyři pracovní uzly		 v3 nebo v4.1
/hana/logbackup 3 x RAM 3 x RAM v3 nebo v4.1
/hana/zálohování 2 x RAM 2 x RAM v3 nebo v4.1

U všech svazků se důrazně doporučuje systém souborů NFS verze 4.1.

Velikostí záložních svazků jsou odhady. Přesné požadavky je potřeba definovat na základě procesů úloh a operací. Pro zálohy můžete konsolidovat mnoho svazků pro různé SAP HANA instancí do jednoho (nebo dvou) větších svazků, které by mohly mít nižší úroveň služby ANF.

Poznámka

Doporučení Azure NetApp Files velikostí uvedená v tomto dokumentu jsou zaměřená na minimální požadavky, které SAP vyjadřuje vůči poskytovatelům infrastruktury. V reálných zákaznických nasazeních a scénářích úloh to nemusí stačit. Tato doporučení můžete použít jako výchozí bod a přizpůsobit se na základě požadavků konkrétní úlohy.

Proto byste mohli zvážit nasazení podobné propustnosti pro svazky ANF, jak je uvedeno pro diskové úložiště úrovně Ultra již. Zvažte také velikosti pro velikosti uvedené pro svazky pro různé skladové jednotky virtuálních počítačů jako v tabulkách disků Úrovně Ultra.

Tip

Můžete dynamicky měnit Azure NetApp Files svazků bez potřeby svazků, zastavit virtuální počítače nebo zastavit unmount SAP HANA. To umožňuje flexibilitu, aby aplikace splňovala očekávané i nepředvídatelné požadavky na propustnost.

Dokumentace k nasazení konfigurace škálování na více systémů SAP HANA s pohotovostním uzlem pomocí svazků NFS v4.1 hostovaných v AN SAP HANA F se publikuje ve škálování na více systémů s pohotovostním uzlem na virtuálních počítači Azure s Azure NetApp Files na SUSE Linux Enterprise Serveru.

Dostupnost

Aktualizace a upgrady systému ANF se aplikují, aniž by to ovlivnilo prostředí zákazníka. Definovaná smlouva SLA je 99,99 %.

Svazky, IP adresy a fondy kapacity

V případě ANF je důležité pochopit, jak je vytvořena základní infrastruktura. Fond kapacity je pouze konstrukce, která poskytuje rozpočet kapacity a výkonu a jednotku fakturace na základě úrovně služby fondu kapacity. Fond kapacity nemá žádný fyzický vztah k základní infrastruktuře. Když ve službě vytvoříte svazek, vytvoří se koncový bod úložiště. K tomuto koncovému bodu úložiště se přiřadí jedna IP adresa, která poskytuje přístup k datům svazku. Pokud vytvoříte několik svazků, všechny svazky se distribuují napříč základní holou vozovou parku, která je svázaná s tímto koncovým bodem úložiště. ANF má logiku, která automaticky distribuuje úlohy zákazníků, jakmile objemy nebo/a kapacita nakonfigurovaného úložiště dosáhne interní předdefinované úrovně. Takové případy si můžete všimnout, protože se pro přístup ke svazkům automaticky vytvoří nový koncový bod úložiště s novou IP adresou. Služba ANF neposkytuje zákazníkovi kontrolu nad touto distribuční logikou.

Svazek protokolu a svazek zálohování protokolů

K zápisu online protokolu znovu se používá "svazek protokolu" (/hana/log). Proto se na tomto svazku nacházejí otevřené soubory, které nemají smysl tento svazek pořizovat. Soubory protokolů znovu online se archivují nebo zálohují na záložní svazek protokolů, jakmile je online soubor protokolu znovu zaplněn nebo se provede zálohování protokolu znovu. Pro zajištění přiměřeného výkonu zálohování vyžaduje svazek zálohování protokolů dobrou propustnost. Pokud chcete optimalizovat náklady na úložiště, může být smysl konsolidovat svazek zálohování protokolů několika instancí HANA. Aby několik instancí HANA bylo používat stejný svazek a zapisovat zálohy do různých adresářů. Díky této konsolidaci můžete získat větší propustnost, protože potřebujete, aby byl svazek o něco větší.

Totéž platí pro svazek, na který používáte úplné zálohy databáze HANA.
 

Backup

Kromě zálohování streamování a zálohování databází SAP HANA službou Azure Back Service, jak je popsáno v článku Průvodce zálohováním pro SAP HANA v Azure Virtual Machinesotevírá Azure NetApp Files možnost zálohování snímků na základě úložiště.

SAP HANA podporuje:

  • Storage zálohování snímků na základě snímků pro jeden kontejnerový systém s SAP HANA 1.0 SPS7 a novějšími
  • Storage zálohování snímků na základě snímků pro prostředí HANA s více databázovými kontejnery (MDC) s jedním tenantem s SAP HANA 2.0 SPS1 a vyšším
  • Storage zálohování snímků na základě snímků pro prostředí HANA s více kontejnery databáze (MDC) s více tenanty s SAP HANA 2.0 SPS4 a novějšími

Vytváření záloh snímků založených na úložišti je jednoduchý čtyřkrokový postup.

  1. Vytvoření snímku interní databáze HANA – aktivita, kterou nebo nástroje potřebujete provést
  2. SAP HANA zapisuje data do datových souborů, aby se v úložišti vytvořil konzistentní stav – HANA tento krok provádí v důsledku vytvoření snímku HANA.
  3. Vytvořte snímek na svazku /hana/data v úložišti – krok, který nebo nástroje potřebujete provést. Na svazku /hana/log není potřeba provádět snímek.
  4. Odstranění snímku databáze HANA (interní) a obnovení normálního provozu – krok, který musíte provést vy nebo nástroje

Upozornění

Chybějící poslední krok nebo neúspěšný provedení posledního kroku má závažný vliv na SAP HANA paměti a může vést k zastavení SAP HANA

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

Zálohování snímků ANF pro SAP HANA

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

Zálohování snímků ANF pro SAP HANA část 2

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

Tento postup zálohování snímků je možné spravovat různými způsoby pomocí různých nástrojů. Jedním z příkladů je skript Pythonu ntaphana_azure.py, který je k dispozici na GitHub Jedná se o ukázkový kód poskytnutý tak, jak je, bez jakékoli údržby https://github.com/netapp/ntaphana nebo podpory.

Upozornění

Snímek sám o sobě není chráněnou zálohou, protože se nachází ve stejném fyzickém úložišti jako svazek, který jste právě po pořízení snímku pořizování. Je nutné chránit alespoň jeden snímek za den do jiného umístění. Můžete to udělat ve stejném prostředí, ve vzdálené oblasti Azure nebo ve službě Azure Blob Storage.

Dostupná řešení pro zálohování konzistentní vzhledem k aplikacím na základě snímků úložiště:

  • Nástroj Microsoft Azure Application Consistent Snapshot (AzAcSnap) je nástroj příkazového řádku, který umožňuje ochranu dat pro databáze třetích stran tím, že před pořízením snímku úložiště zprovozní všechny potřebné orchestrace do stavu konzistentního vzhledem k aplikacím. AzAcSnap podporuje zálohování na základě snímků pro velkou instanci HANA a také Azure NetApp Files. Další podrobnosti najdete v tématu Co je nástroj Azure Application Consistent Snapshot.
  • Pro uživatele zálohovacího produktů Commvault je další možností Commvault IntelliSnap V.11.21 a novější. Tato nebo novější verze služby Commvault nabízí Azure NetApp Files snímků. Další informace najdete v článku Commvault IntelliSnap 11.21.

Zálohování snímku pomocí služby Azure Blob Storage

Zálohování do úložiště objektů blob v Azure je nákladově efektivní a rychlá metoda pro ukládání záloh snímků úložiště databáze HANA založené na ANF. Pokud chcete uložit snímky do úložiště objektů blob v Azure, je upřednostňovaný nástroj AzCopy. Stáhněte si nejnovější verzi tohoto nástroje a nainstalujte ji například do adresáře bin, kde je nainstalovaný skript pythonu z GitHub. Stáhněte si nejnovější nástroj AzCopy:

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’

Nejpokročilejší funkcí je možnost SYNC. Pokud použijete možnost SYNC, nástroj azcopy udržuje zdrojový a cílový adresář synchronizované. Použití parametru --delete-destination je důležité. Bez tohoto parametru nástroj azcopy neodstraňovat soubory v cílové lokalitě a na cílové straně by se zvětšuje využití místa. Ve svém účtu úložiště Azure vytvořte kontejner objektů blob bloku. Pak vytvořte klíč SAS pro kontejner objektů blob a synchronizujte složku snapshot s kontejnerem objektů blob Azure.

Pokud by se například denní snímek měl synchronizovat s kontejnerem objektů blob Azure, aby se chránila data. A pouze jeden snímek by se měl uchovávat, můžete použít následující příkaz.

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

Další kroky

Přečtěte si článek: