Distribuera SAS Grid 9.4 på Azure NetApp Files

SAS-analysprogramvaran tillhandahåller en uppsättning tjänster och verktyg för att dra insikter från data och fatta intelligenta beslut. SAS-lösningar tillhandahåller analys, artificiell intelligens, business intelligence, kundintelligens, datahantering samt bedrägeri och säkerhetsinformation.

Om du distribuerar SAS Grid i Azure är Azure NetApp Files ett praktiskt primärt lagringsalternativ. När du använder skalbara tjänster i Azure NetApp Files kan du skala upp eller ned lagringsallokeringarna när som helst utan avbrott i tjänsterna. Du kan också justera lagringstjänstnivån till prestandakraven dynamiskt.

SAS erbjuder dessa primära plattformar, som Microsoft har verifierat:

• SAS Grid 9.4
• SAS Viya

SAS Grid 9.4 har verifierats i Linux.

Den här artikeln innehåller allmän information för att köra SAS Grid 9.4 på Azure med hjälp av Azure NetApp Files för SASDATA-lagring. Det ger också vägledning om lagringsalternativ för SASWORK. Dessa riktlinjer baseras på antagandet att du är värd för din egen SAS-lösning i Azure i din egen klientorganisation. SAS tillhandahåller inte värdtjänster för SAS Grid i Azure.

Arkitektur

Ladda ned en PowerPoint-fil med alla diagram i den här artikeln.

Dataflöde

Beräkningsnivån använder SASDATA-volymer (och eventuellt SASWORK) för att dela data över rutnätet. SASDATA är en NFS-ansluten volym på Azure NetApp Files.

• En beräkningsnod läser indata från SASDATA och skriver resultat tillbaka till SASDATA.
• En efterföljande del av analysjobbet kan köras av en annan nod på beräkningsnivån. Den använder samma procedur för att hämta och lagra den information som den behöver bearbeta.

Potentiella användningsfall

En skalbar SAS Grid-distribution som använder Azure NetApp Files gäller för dessa användningsfall:

• Ekonomisk analys
• Upptäckt av bedrägerier
• Spårning och skydd av utrotningshotade arter
• Vetenskap och medicin
• Analys och AI

Krav för lagringsprestanda

För SAS 9.4-distributioner (SAS Grid eller SAS Analytics Pro) i Azure är Azure NetApp Files ett praktiskt primärt lagringsalternativ för SAS Grid-kluster med begränsad storlek. SAS rekommenderar 100 MiB/s-dataflöde per fysisk kärna. Med tanke på den rekommendationen är SAS Grid-kluster som använder en Azure NetApp Files-volym för SASDATA (beständiga SAS-datafiler) skalbara till 32 till 48 fysiska kärnor på två eller flera virtuella Azure-datorer. SAS-klusterstorlekar baseras på arkitekturbegränsningen för ett enda SASDATA-namnområde per SAS-kluster och den tillgängliga enskilda Azure NetApp Files-volymbandbredden. Vägledningen för kärnantalet kommer att ses över när Azure-infrastrukturen (beräkning, nätverk och lagringsbandbredd per filsystem) ökar över tid.

Volymtyper för Azure NetApp Files

Azure NetApp Files erbjuder två olika typer av volymer för nätverksanslutna lagringsarbetsbelastningar (NAS).

Vanliga volymer tillhandahåller:

• Upp till 4 500 MiB/s läsningar.
• Upp till 1 500 MiB/s skrivningar.
• 460 000 in- och utdataåtgärder per sekund (IOPS).
• Upp till 100 TiB av total kapacitet.
• En minsta storlek på 100 GiB.

Stora volymer, som nådde allmän tillgänglighet i maj 2024, tillhandahåller:

• Upp till 10 000 GiB/s dataflöde.
• Upp till 800 000 IOPS.
• 1 000 TiB av total kapacitet.
• En minsta kapacitet på 50 TiB.

Mer information finns i Krav och överväganden för stora volymer.

Regelbundna volymprestandaförväntningar för Azure NetApp Files

En enda vanlig Azure NetApp Files-volym kan hantera upp till cirka 4 500 MiB/s läsningar och 1 500 MiB/s skrivningar. Med tanke på en Azure-instanstyp med tillräcklig utgående bandbredd kan en enskild virtuell dator (VM) använda all skrivbandbredd för en enda vanlig Azure NetApp Files-volym. Det är dock bara den största enskilda virtuella datorn som är tillgänglig i Azure som kan använda all läsbandbredd för en enskild volym. Om du vill ha mer bandbredd för arbetsbelastningen bör du överväga att använda en stor Volym i Azure NetApp Files.

SASDATA, den största delade arbetsbelastningen för SAS 9.4, har ett läs-/skrivförhållande på 80:20. De viktiga talen per volym för en arbetsbelastning på 80:20 med 64 KiB läsning/skrivning är:

• 2 400 MiB/s läsdataflöde och 600 MiB/s skrivdataflöde som körs samtidigt. Det kombinerade dataflödet är cirka 3 000 MiB/s.

Mer information finns i Prestandamått för Azure NetApp Files för Linux.

Stora volymprestanda för SAS Grid

En enda stor Azure NetApp Files-volym kan hantera upp till 10 GiB/s totalt dataflöde, vilket innebär att prestandapotentialen för SAS Grid kan vara mycket större när du hanterar större skalor.

I följande tabell visas prestandaresultat för arbetsbelastningar som använder SAS Grid på en stor Volym i Azure NetApp Files med olika vm-exempelstorlekar. Exempellistan innehåller antal instanser, trådar per instans och nconnect värden som använder Red Hat Enterprise Linux (RHEL) 8.4.

VM-instans	Antal instanser	Trådar per instans	nconnect värde	Läs MiB/s per tråd	Skriv MiB/s per tråd	Totalt antal lästa MiB/s	Totalt antal skrivnings-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

Kapacitetsrekommendationer

Prestandakalkylatorn för Azure NetApp Files kan ge vägledning för storlek på SASDATA-volymer.

Det är viktigt att välja en lämplig tjänstnivå eftersom:

• Volymbandbredd baseras på volymkapacitet.
• Kapacitetskostnaden baseras på tjänstnivån.
• Valet av tjänstnivå baseras på kapacitets- och bandbreddsbehov.

I kalkylatorn väljer du avancerat, väljer en region och anger följande värden.

• Volymstorlek: Önskad kapacitet
• Dataflöde: Önskat dataflöde med tanke på 100 MiB/s per kärna
• Läsprocent: 80 %
• IOPS: 0
• I/O-storlek: 64KiB sekventiell

Utdata längst ned på skärmen ger rekommenderade kapacitetskrav på varje tjänstnivå och kostnaden per månad, baserat på priset för den valda regionen:

• Dataflöde. Volymens bandbredd, baserat på arbetsbelastningsmixen. För en sekventiell läsarbetsbelastning på 80 % 64 KiB är 3 096 MiB/s det förväntade maxvärdet.
• IOPS. Antalet IOPS som volymen tillhandahåller vid det angivna dataflödet.
• Volymstorlek. Mängden kapacitet som behövs av volymen på de angivna tjänstnivåerna för att uppnå det dataflöde som krävs. Volymkapaciteten (rapporteras i gibs) kan vara lika med eller mindre än kapacitetspoolens storlek. Den här rekommendationen baseras på antagandet att du använder automatiska QoS-kapacitetspooltyper. Om du vill optimera kapacitet kontra dataflödesdistribution mellan volymer i en kapacitetspool ytterligare bör du överväga manuella typer av QoS-kapacitetspooler.
• Kapacitetspoolens storlek. Poolstorleken. En volym kapacitet är huggen från en kapacitetspool. Kapacitetspooler är storleksanpassade i steg om 1 TiB.
• Kapacitetspoolkostnad (USD/månad). Kostnaden per månad för kapacitetspoolen på angiven storlek och servicenivå.
• Visa tillbaka volym (USD/månad). Kostnaden per månad för kapaciteten för volymen i den angivna kapaciteten. Avgifterna baseras på de allokerade kapacitetspoolstorlekarna. Volymen visar tillbaka anger volymmängden.

Kontrollera kostnaderna efter behov med hjälp av volymformning i Azure NetApp Files. Det finns två dynamiska alternativ som påverkar prestanda och kostnader:

• Ändra storlek på en volym- och kapacitetspool dynamiskt
• Ändra tjänstnivå för en volym dynamiskt

Läs mer om kostnadsmodellen för Azure NetApp Files.

Dataskydd

Azure NetApp Files använder ögonblicksbilder för att skydda dina data. Ögonblicksbilder ger utrymmeseffektiva, kraschkonsekventa, nästan omedelbara bilder av dina Azure NetApp Files-volymer. Du kan skapa ögonblicksbilder manuellt när som helst eller schemalägga dem med hjälp av en ögonblicksbildprincip på volymen.

Använd en princip för ögonblicksbilder för att lägga till automatiserat dataskydd i dina volymer. Du kan snabbt återställa ögonblicksbilder på plats med hjälp av återställning av ögonblicksbilder. Eller så kan du återställa en ögonblicksbild till en ny volym för snabb dataåterställning. Du kan också använda återställning till nya volymfunktioner för att tillhandahålla test-/utvecklingsmiljöer med aktuella data.

För extra nivåer av dataskydd kan du använda dataskyddslösningar som använder säkerhetskopiering av Azure NetApp Files eller programvara för partnersäkerhetskopiering.

Komponenter

• Azure Virtual Machines: SAS Grid kräver hög bandbredd för minne, lagring och I/O, i ett lämpligt förhållande med antalet kärnor. Azure erbjuder fördefinierade storlekar för virtuella datorer (VM) med lägre vCPU-antal som kan bidra till att balansera antalet kärnor som krävs med mängden minne, lagring och I/O-bandbredd.

  Mer information finns i Begränsad vCPU-kompatibel VM-storlek. Det är viktigt att du noggrant förstår vilka beräkningsresurser som är tillgängliga för varje instans. För att köra SAS Grid i Azure med Azure NetApp Files rekommenderar vi följande instanstyper:

  • Standard_E64-16ds_v4 eller Standard_E64-16ds_v5
  • Standard_E64-32ds_v4 eller Standard_E64-32ds_v5

  Se till att granska metodtipsen för att använda SAS i Azure, inklusive uppdateringarna i kommentarerna.

• Azure NetApp Files: Du kan lagra SASDATA på en Azure NetApp Files-volym som delas över beräkningsklustret.

  Du kan också använda Azure NetApp Files NFS-volymer för SASWORK.

  Azure NetApp Files är tillgängligt på tre prestandatjänstnivåer:

  • Standard
  • Premium
  • Ultra

  Volymprestanda definieras främst av tjänstnivån. Volymens storlek är också en faktor, eftersom det erhållna dataflödet bestäms av tjänstnivån och volymens storlek.

Lagringsalternativ för SASDATA

Eftersom Azure NetApp Files kan ge åtkomst med högt dataflöde och låg svarstid till lagring är det ett genomförbart och snabbare alternativ till Premium Disk. Nätverksansluten lagring begränsas inte på vm-nivå som med hanterade diskar, så du får högre dataflöde till lagringen.

Om du vill beräkna den nivå som krävs för din SASDATA-kapacitet använder du Prestandakalkylatorn för Azure NetApp Files. (Välj avancerat.)

Eftersom Azure NetApp Files NFS-volymer delas är de en bra kandidat för att vara värd för SASDATA, när de används med rätt storlek på VM-instanstyper och RHEL-distribution, som beskrivs senare i den här artikeln.

Lagringsalternativ för SASWORK

I följande tabell visas de vanligaste lagringsalternativen för att distribuera SASWORK i Azure. Beroende på dina krav på storlek (kapacitet) och hastighet (bandbredd) har du tre alternativ: tillfällig lagring, hanterad disk och Azure NetApp Files.

	Tillfällig lagring	Hanterad disk	Azure NetApp Files
Storlek	Litet	Stort	Extra stor
Hastighet	Extra stor	Litet	Medium

Ta hänsyn till dessa överväganden när du väljer ett alternativ:

• Tillfällig lagring (eller tillfällig lagring) ger den högsta bandbredden, men den är endast tillgänglig i mindre storlekar. (Storleken beror på vm-SKU:n.) Beroende på tillgängliga och nödvändiga kapaciteter kan det här alternativet vara bäst.
• Om den nödvändiga SASWORK-kapaciteten överskrider den tillfälliga lagringsstorleken för den virtuella dator-SKU som du har valt kan du överväga att använda en Hanterad Azure-disk som värd för SASWORK. Tänk dock på att dataflödet till en hanterad disk begränsas av den virtuella datorarkitekturen avsiktligt och att det varierar beroende på vm-SKU:n. Därför är det här lagringsalternativet endast genomförbart för miljöer som har lägre SASWORK-prestandakrav.
• För de högsta SASWORK-kapacitetskraven och ett genomsnittligt prestandakrav utöver vad Azure-hanterade diskar kan tillhandahålla kan du överväga Azure NetApp Files för SASWORK. Den ger en stor storlek tillsammans med snabbt dataflöde.

När du använder föregående tabell, för att avgöra om dina behov är små, stora, medelstora eller extra stora, tar du hänsyn till distributionens skala, antalet virtuella datorer och kärnor samt de associerade kapacitets- och prestandakraven. Du måste göra dessa utvärderingar för varje distribution.

Alternativen i tabellen motsvarar distributioner som beskrivs i de arkitekturer som följer. I alla scenarier finns SASDATA på en Azure NetApp Files NFS-volym och delas mellan beräkningsnoderna. För vissa RHEL-distributioner rekommenderar vi att du använder NFS nconnect-alternativet för att skapa flera nätverksflöden till volymen. Mer information finns i avsnittet NFS-monteringsalternativ i den här artikeln.

Tillfällig lagringsarkitektur

För mindre SASWORK-kapacitetskrav är tillfällig lagring för virtuella Azure-datorer en snabb och kostnadseffektiv lösning. I den här arkitekturen är varje virtuell dator på beräkningsnivån utrustad med viss tillfällig lagring. Information om hur du fastställer de tillfälliga lagringsstorlekarna för de virtuella datorer som du använder finns i dokumentationen om virtuella Azure-datorer.

Dataflöde

• En beräkningsnod läser indata från SASDATA och skriver resultat tillbaka till SASDATA.
• En efterföljande del av analysjobbet kan köras av en annan nod på beräkningsnivån. Den använder samma procedur för att hämta och lagra den information som den behöver bearbeta.
• SASWORK för temporärt arbete delas inte. Den lagras i tillfällig lagring på varje beräkningsnod.

Arkitektur för hanterade diskar

Om dina kapacitetskrav för SASWORK överskrider de kapaciteter som är tillgängliga i tillfällig lagring är Azure-hanterade diskar ett bra alternativ. Hanterade diskar är tillgängliga i olika storlekar och prestandanivåer. Mer information finns i Skalbarhets- och prestandamål för virtuella datordiskar.

Dataflöde

• En beräkningsnod läser indata från SASDATA och skriver resultat tillbaka till SASDATA.
• En efterföljande del av analysjobbet kan köras av en annan nod på beräkningsnivån. Den använder samma procedur för att hämta och lagra den information som den behöver bearbeta.
• SASWORK för temporärt arbete delas inte. Den lagras på hanterade diskar som är anslutna till varje beräkningsnod.

Azure NetApp Files-arkitektur

Överväg att använda Azure NetApp Files för högre SASWORK-kapacitet eller medelhöga prestandakrav. Azure NetApp Files tillhandahåller volymkapaciteter på upp till 100 TiB med en vanlig volym och 1 PiB med en stor volym. Varje nod på beräkningsnivån ska ha en egen SASWORK-volym. Volymerna ska inte delas.

Dataflöde

• En beräkningsnod läser indata från SASDATA och skriver resultat tillbaka till SASDATA.
• En efterföljande del av analysjobbet kan köras av en annan nod på beräkningsnivån. Den använder samma procedur för att hämta och lagra den information som den behöver bearbeta.
• SASWORK för temporärt arbete delas inte. Den lagras på enskilda Azure NetApp Files-volymer som är anslutna till varje beräkningsnod.

Skalnings- och konfigurationsrekommendationer

• För bästa och mest konsekventa svarstid för datatrafik mellan instanserna i SAS-klustret kontrollerar du att alla virtuella datorer har skapats i samma närhetsplaceringsgrupp.
• Läs avsnittet Allmän justeringsvägledning i Metodtips för att använda SAS i Azure.
• Aktivera accelererat nätverk för optimal nätverksbandbredd.

RHEL-distributioner och NFS-inställningar

RHEL-distributioner

RHEL är den rekommenderade distributionen för att köra SAS 9 på Linux. Varje kernel som stöds av Red Hat har sina egna begränsningar för NFS-bandbredd.

Information om hur du kör SAS på Azure finns i Metodtips för att använda SAS i Azure.

Azure Standard_E64-16ds_v4 och Standard_E64-32ds_v4 virtuella datorer, eller deras v5-motsvarigheter, rekommenderas för SAS. Med dessa rekommendationer i åt beräkningen innehåller det här avsnittet några riktlinjer för att använda SAS med Azure NetApp Files.

• Om du använder RHEL 7 är Standard_E64-16ds_v4 eller Standard_E64-16ds_v5 det bästa valet, baserat på målet 100 MiB/s per fysisk kärna för SASDATA.

  • Standard_E64-16ds_v4: 90–100 MiB/s per kärna
  • Standard_E64-32ds_v4: 45-50 MiB/s per kärna

• Om du använder RHEL 8.2 är antingen Standard_E64-16ds_v4 eller Standard_E64-32ds_v4, eller deras v5-motsvarigheter, möjliga alternativ. Standard_E64-16ds_v4 är att föredra med tanke på målet 100 MiB/s per kärna för SASDATA.

  • Standard_E64-16ds_v4: 150-160 MiB/s per kärna
  • Standard_E64-32ds_v4: 75-80 MiB/s per kärna

• Om du använder RHEL 8.3 är både Standard_E64-16ds_v4 och Standard_E64-32ds_v4, eller deras v5-motsvarigheter, helt acceptabla med tanke på dataflödesmålet per kärna:

  • Validering anger 3 200 MiB/s läsningar.
  • Dessa resultat uppnås med NFS-monteringsalternativet nconnect .

Testningen visar att en enda RHEL 7-instans inte uppnår mer än ungefär 750–800 MiB/s av läsdataflöde mot en enda Azure NetApp Files-lagringsslutpunkt (d.v.s. mot ett nätverksuttag). 1 500 MiB/s skrivningar kan uppnås mot samma slutpunkt om du använder monteringsalternativen 64 KiB rsize och wsize NFS. Vissa bevis tyder på att det tidigare antecknade genomflödestaket är en artefakt av 3.10-kärnan. Mer information finns i RHEL CVE-2019-11477.

Testningen visar att en enda RHEL 8.2-instans, med dess 4.18-kernel, är fri från de begränsningar som anges i 3.10-kerneln. Så 1 200-1 300 MiB/s lästrafik kan uppnås om du använder ett 64-KiB rsize - och wsize NFS-monteringsalternativ. För stora sekventiella skrivningar kan du förvänta dig samma 1 500 MiB/s med uppnåeligt dataflöde som du skulle få på RHEL 7.

Med en enda RHEL 8.3-instans med alternativet nconnect mount (som är nytt i RHEL 8.3-distributionen) kan cirka 3 200 MiB/s läsdataflöde uppnås från en enda Azure NetApp Files-volym. Förvänta dig inte mer än 1 500 MiB/s skrivningar till en enskild Azure NetApp Files-volym, även när du tillämpar nconnect.

Kernel tunables

Posterna i facktabellen

NFSv3 har ingen mekanism för att förhandla om samtidighet mellan klienten och servern. Klienten och servern definierar var och en sina gränser utan att vara medvetna om den andra. För bästa prestanda bör du rada upp det maximala antalet posterna för facktabeller på klientsidan sunrpc med det som stöds utan pushback på servern. När en klient överbelastar servernätverksstackens förmåga att bearbeta en arbetsbelastning svarar servern genom att minska fönsterstorleken för anslutningen, vilket inte är idealiskt för prestanda.

Som standard definierar moderna Linux-kernels poststorleken sunrpc.max_tcp_slot_table_entries per anslutningsplatstabell sunrpc för att stödja 65 536 utestående åtgärder. Dessa posterna i facktabellen definierar gränserna för samtidighet. Värden som är så höga är onödiga eftersom Azure NetApp Files som standard är 128 utestående åtgärder.

Vi rekommenderar att du justerar klienten till samma nummer:

• Kernel tunables (via /etc/sysctl.conf)
  • sunrpc.tcp_max_slot_table_entries=128

Filsystem cache tunables

Du måste också förstå följande faktorer när det gäller cachelagring av filsystem:

• Tömning av en smutsig buffert lämnar data i ett rent tillstånd, vilket kan användas för framtida läsningar tills minnestrycket leder till borttagning.
• Det finns tre utlösare för en asynkron tömningsåtgärd:
  • Tidsbaserad: När en buffert når den ålder som definierats av vm.dirty_expire_centisecs eller vm.dirty_writeback_centisecs tunable, måste den markeras för rengöring (dvs. tömning eller skrivning till lagring).
  • Minnestryck: Mer information finns i vm.dirty_ratio | vm.dirty_bytes.
  • Stäng: När ett filhandtag stängs rensas alla smutsiga buffertar asynkront till lagring.

Dessa faktorer styrs av fyra tunables. Du kan justera varje tunable dynamiskt och beständigt med hjälp tuned av eller sysctl i filen /etc/sysctl.conf . Om du justerar dessa variabler förbättras prestandan för SAS Grid:

• Kernel tunables (via anpassad finjusterad profil)
  • include = throughput-performance
  • vm.dirty_bytes = 31457280
  • vm.dirty_expire_centisecs = 100
  • vm.dirty_writeback_centisecs = 300

Alternativ för NFS-montering

Vi rekommenderar följande NFS-monteringsalternativ för delade NFS-filsystem som används för permanenta SASDATA-filer :

RHEL 7 och 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

Vi rekommenderar följande monteringsalternativ för SASWORK-volymer , där respektive volymer endast används för SASWORK och inte delas mellan noder:

RHEL 7 och 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

Mer information om fördelarna och kostnaden för monteringsalternativet nocto finns i Timers för nära-till-öppna-konsekvens och cacheattribut.

Du bör också granska Azure NetApp Files: Ett delat filsystem som ska användas med SAS Grid i MS Azure, inklusive alla uppdateringar i kommentarerna.

Läsinställningar för NFS

Vi rekommenderar att du anger 15 360 KiB för alla RHEL-distributioner till 15 360 KiB. Mer information finns i How to persistently set read-ahead for NFS mounts .How to persistently set read-ahead for NFS mounts .how to persistently set read-ahead for NFS mounts.

Alternativ

Lagringslösningen i föregående arkitekturer är mycket tillgänglig, enligt vad som anges i serviceavtalet för Azure NetApp Files. För extra skydd och tillgänglighet kan du replikera lagringsvolymerna till en annan Azure-region med hjälp av Replikering mellan regioner i Azure NetApp Files.

Det finns två viktiga fördelar med att replikera volymerna via lagringslösningen:

• Det finns ingen ytterligare belastning på de virtuella programdatorerna.
• Den här lösningen eliminerar behovet av att köra virtuella datorer i målregionen under normal drift.

Lagringsinnehållet replikeras utan användning av beräkningsinfrastrukturresurser och målregionen behöver inte köra SAS-programvaran. De virtuella måldatorerna behöver inte köras för att stödja det här scenariot.

Följande arkitektur visar hur lagringsinnehållet i Azure NetApp Files replikeras till en andra region, där lagringen fylls med en replik av produktionsdata. Om det sker en redundansväxling ansluts den sekundära regionen och de virtuella datorerna startas så att produktionen kan återupptas i den andra regionen. Du måste omdirigera trafik till den andra regionen genom att konfigurera om lastbalanserare som inte visas i diagrammet.

Det typiska RPO för den här lösningen är mindre än 20 minuter när intervallet för replikering mellan regioner är inställt på 10 minuter.

Dataflöde

• En beräkningsnod läser indata från SASDATA och skriver resultat tillbaka till SASDATA.
• En efterföljande del av analysjobbet kan köras av en annan nod på beräkningsnivån. Den använder samma procedur för att hämta och lagra den information som den behöver bearbeta.
• SASWORK för temporärt arbete delas inte. Den lagras på enskilda Azure NetApp Files-volymer som är anslutna till varje beräkningsnod.
• Azure NetApp Files replikering mellan regioner replikerar asynkront SASDATA-volymen, inklusive alla ögonblicksbilder, till en DR-region för att underlätta redundansväxling om det uppstår en regional katastrof.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare.

Azure NetApp Files tillhandahåller ett serviceavtal för standard 99,99 % tillgänglighet för alla nivåer och alla regioner som stöds. Azure NetApp Files har också stöd för etablering av volymer i tillgänglighetszoner som du väljer och HA-distributioner mellan zoner.

För förbättrade serviceavtal för RPO/RTO ingår integrerat dataskydd med ögonblicksbilder och säkerhetskopiering i tjänsten. Replikering mellan regioner ger samma fördelar i Azure-regioner.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

Azure NetApp Files ger en säkerhetsnivå eftersom volymer etableras och datatrafiken stannar kvar i dina virtuella nätverk. Det finns ingen offentligt adresserbar slutpunkt. Alla data krypteras i vila hela tiden. Du kan också kryptera data under överföring.

Azure Policy kan hjälpa dig att framtvinga organisationsstandarder och utvärdera efterlevnad i stor skala. Azure NetApp Files stöder Azure Policy via anpassade och inbyggda principdefinitioner.

Prestandaeffektivitet

Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.

Prestanda

Beroende på dina krav för dataflöde och kapacitet bör du tänka på följande:

• Prestandaöverväganden för Azure NetApp Files.
• Den nödvändiga Azure NetApp Files-kapaciteten och tjänstnivåerna för SASDATA.
• Vägledningen i den här artikeln för att välja en lagringstyp för SASWORK.

Skalbarhet

Du kan enkelt skala beräkningsprestanda genom att lägga till virtuella datorer i skalningsuppsättningarna som kör sas-lösningens tre nivåer.

Du kan dynamiskt skala lagring av Azure NetApp Files-volymer. Om du använder automatisk QoS skalas prestanda samtidigt. Om du vill ha mer detaljerad kontroll över varje volym kan du också styra prestanda för varje volym separat med hjälp av manuell QoS för dina kapacitetspooler.

Azure NetApp Files-volymer är tillgängliga på tre prestandanivåer: Ultra, Premium och Standard. Välj den nivå som bäst passar dina prestandakrav, med hänsyn till att tillgänglig prestandabandbredd skalar med storleken på en volym. Du kan ändra tjänstnivån för en volym när som helst. Mer information om Azure NetApp Files-kostnadsmodellen finns i dessa prisexempel.

Du kan använda Prestandakalkylatorn för Azure NetApp Files för att komma igång.

Kostnadsoptimering

Kostnadsoptimering handlar om att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

Kostnadsmodell

Att förstå kostnadsmodellen för Azure NetApp Files kan hjälpa dig att hantera dina utgifter.

Azure NetApp Files-fakturering baseras på etablerad lagringskapacitet som du allokerar genom att skapa kapacitetspooler. Kapacitetspooler debiteras varje månad baserat på en angiven kostnad per allokerad GiB per timme.

Om storlekskraven för din kapacitetspool varierar (till exempel på grund av variabel kapacitet eller prestandabehov) bör du överväga att dynamiskt ändra storlek på dina volymer och kapacitetspooler för att balansera kostnader med dina kapacitets- och prestandabehov.

Om storlekskraven för din kapacitetspool är desamma, men prestandakraven varierar, bör du överväga att dynamiskt ändra tjänstnivån för en volym. Du kan etablera och avetablera kapacitetspooler av olika typer under hela månaden, ge just-in-time-prestanda och minska kostnaderna under perioder då du inte behöver höga prestanda.

Prissättning

Baserat på dina kapacitets- och prestandakrav bestämmer du vilken Azure NetApp Files-tjänstnivå du behöver (Standard, Premium eller Ultra). Använd sedan Priskalkylatorn för Azure för att utvärdera kostnaderna för dessa komponenter:

• SAS på Azure-komponenter
• Azure NetApp Files
• Hanterad disk (valfritt)
• Virtuellt nätverk

Driftsäkerhet

Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Översikt över grundpelare för driftskvalitet.

SAS Grid i Azure ger flexibilitet och snabb distribution. Här är några fördelar:

• Uppfylla föränderliga affärskrav med dynamisk arbetsbelastningsutjämning
• Skapa en SAS-datormiljö med hög tillgänglighet
• Få snabbare resultat från din befintliga IT-infrastruktur
• Öka beräkningsresurserna stegvis och kostnadseffektivt
• Hantera alla dina analytiska arbetsbelastningar
• Övergå enkelt från en silobaserad server eller miljö med flera datorer till en SAS-rutnätsmiljö

Distribuera det här scenariot

Det är bäst att distribuera arbetsbelastningarna med hjälp av en IaC-process (infrastruktur som kod). SAS-arbetsbelastningar kan vara känsliga för felkonfigurationer som ofta sker i manuella distributioner och minskar produktiviteten.

Om du vill börja med att utforma din SAS Grid på Azure-lösning kan du läsa SAS om Azure Architecture och Automatisera SAS-distribution i Azure med hjälp av GitHub Actions.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

• Geert van Teylingen | Grupp produktansvarig
• Arnt de Gier | Teknisk marknadsföringstekniker

Övriga medarbetare:

• Mick Alberts | Teknisk författare

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

• Webbseminarier för snabbstart om hur du kommer igång med Azure
• Azure NetApp Files: Ett delat filsystem som ska användas med SAS Grid i Azure
• Prestandakalkylator för Azure NetApp Files
• Dokumentation om Azure NetApp Files
• Utbildning: Introduktion till Azure NetApp Files
• Krav och överväganden för stora volymer

Relaterade resurser

• SAS på Azure, storleksrekommendationer för virtuella datorer
• SAS på Azure, Azure NetApp Files
• Överväganden för SAS på Azure, nätverk och VM-placering
• SAS på Azure, säkerhetsöverväganden