Sammanfattning

Slutförd

I den här modulen diskuterade vi viktiga faktorer som ingår i valet av HPC-lagring i Azure. Nu är det dags att kombinera informationen och skapa ett verktyg som du kan använda för att utvärdera de olika Azure-lagringsalternativen.

Nu ska vi skapa en checklista som kapslar in de viktigaste lagringsövervägandena. Du kanske undrar varför en checklista är nödvändig, särskilt om du har övervakat din aktuella lagringsmiljö under lång tid. Målet är att konsolidera information för andra intressenter, inklusive Azure-teammedlemmar och partner som du kanske arbetar med. Checklistan hjälper till att effektivisera beslutsprocessen och minimera eventuella missförstånd kring en viss lagringslösnings funktioner (eller brist på funktioner).

Skapa din checklista baserat på följande lista över överväganden.

Distribution av arbetsbelastningstrafik

Ta hänsyn till de typer av trafik som din HPC-miljö genererar och bearbetar. Det här steget är särskilt viktigt om du planerar att köra flera typer av arbetsbelastningar och planerar att använda lagringen för andra ändamål.

Din HPC-arbetsbelastning kan till exempel läsa sekventiella data från en stor fil (till exempel en medietillgång från ett återgivningsjobb eller en genomisk sekvensfil) från ett stort antal HPC-datorer. Samtidigt kan det finnas ett behov av att använda en databas (till exempel för att arbeta med HPC-schemaläggaren). Trafiktyperna är olika och kan behöva distribueras på olika lagringslösningar.

Lagringslösningar kan vara utformade för att optimera för olika saker. En NAS-filer som skapats från Ubuntu och kör lokala NVMe-diskar skulle vara bra på enströmsaktiviteter, till exempel en enda klient som kopierar data från NAS till den lokala disken. Men den kanske inte skalas för samtidig åtkomst av ett stort antal klienter.

Du kan också behöva en lösning som optimerar för ett stort antal små filer. En traditionell NAS-lösning, till exempel Azure NetApp Files, ger optimala prestanda för sådan trafik. Men du kan också behöva bearbeta och sedan lagra stora filer och minimera kostnaden för att göra det. Azure Blob Storage med nivåindelning ger flexibilitet i dessa fall, men det kanske inte ger bra prestanda för en kopieringsåtgärd med en enda ström.

Registrera följande trafiktyper i din checklista:

  • Enströmstrafik jämfört med trafik med flera dataströmmar
  • Förhållandet mellan lästrafik och skrivtrafik
  • Genomsnittliga filstorlekar och antal
  • Slumpmässiga eller sekventiella åtkomstmönster

Din checklista kan till exempel återspegla:

  • Trafik med flera strömmar.
  • Läs tungt (75% jämfört med 25%).
  • Genomsnittliga filstorlekar mellan 10 GB och 200 GB. Cirka 50 000 filer.
  • Sekventiell tung (80% jämfört med 20%).

Du bör också ta hänsyn till de viktiga arbetsbelastningar som du planerar att köra på arkitekturen. Om det finns fler än en eller två kontrollerar du att kraven inte skiljer sig avsevärt.

Datalokalitet

Nästa kategori handlar om dataplacering. Behöver du lagra data lokalt? Är du orolig för dataändringar när du kör arbetsbelastning på HPC-systemet? Planerar du att dataändringar endast ska ske lokalt, endast i Azure eller på båda platserna?

Här följer några lokala objekt för din checklista:

  • Källdata lokalt, i Azure eller både och?
  • Resultatdata lokalt, i Azure eller både och?
  • Ska HPC-arbetsbelastningar i Azure samordnas med tidslinjer för ändring av källdata?
    • Tidslinjer hjälper till att informera om risken för inaktuella data.
  • Känsliga data/HIPAA-data?
    • Datakänslighet hjälper till att informera den nivå av autentisering och kryptering som krävs.

Lokalitetsmedvetenhet hjälper dig att avgöra om du kan använda kopiering, cachelagring eller synkronisering som din strategi för dataflytt.

Prestandakrav

Dina prestandakrav bör se ut ungefär så här:

  • Enkelströms kapacitet (i GB/s)
  • Bandbredd för flera dataströmmar (i GBps)
  • Förväntat maximalt IOPS
  • Genomsnittlig svarstid (ms)

Varje övervägande påverkar prestanda, så dessa siffror representerar en guide som en viss lösning bör uppnå. Du kan till exempel ha en HPC-arbetsbelastning som utför omfattande skapande och borttagning av filer som en del av arbetsflödet. Dessa åtgärder kan påverka det totala dataflödet.

Åtkomstmetoder

Konto för det protokoll för klientåtkomst som krävs. Som vi har diskuterat finns det olika versioner av NFS (och SMB, Windows-klientprotokollet). Om du planerar att använda NFSv4 bör du vara tydlig med vilka funktioner i protokollet som krävs (till exempel ACL:er).

Här följer några objekt för din checklista:

  • NFS-versioner krävs
    • Om v4, förväntade protokollbeteenden (ACL:er, kryptering)
  • Parallell filsystemlösning

Totalt kapacitetskrav

Lagringskapacitet i Azure är nästa övervägande. Det hjälper till att informera den totala kostnaden för lösningen. Om du planerar att lagra en stor mängd data under en lång tid kanske du vill överväga nivåindelning som en del av lagringslösningen. Lagring i olika nivåer erbjuder lagringsalternativ med lägre kostnad i kombination med lagring med högre kostnad men högre prestanda i en het nivå.

Några objekt för listan:

  • Total kapacitet krävs
  • Total kapacitet för varmt lager som krävs
  • Total kapacitet på varm nivå som krävs
  • Total kapacitet som krävs för kall nivå

En kommentar om kapacitet på kall nivå: Arkivnivåer kombinerar lägre kostnader för att lagra data med högre transaktionskostnader för att hämta data. Dessutom har arkivnivåer långa hämtningstider för data. De bör inte betraktas som en del av dina heta eller varma nivåer.

Autentiserings-/auktoriseringsmetod

Lägg till dina autentiserings-/auktoriseringskrav i checklistan. Att lägga till dem säkerställer åtminstone att du inkluderar lämpliga stödsystem, till exempel en LDAP-server eller Active Directory-miljö, i din arkitektur. Men om du behöver stöd för funktioner som UID/GID-mappning till Active Directory-användare måste du bekräfta att lagringslösningen stöder den funktionen.

För din lista:

  • Lokalt (endast UID/GID på filservern)
  • Katalog (LDAP, Active Directory)
  • UID/GID-mappning till Active Directory-användare?

Ytterligare läsning