Dela via


Prestandaöverväganden för Azure NetApp Files-lagring med låg åtkomst

Datauppsättningar används inte alltid aktivt. Upp till 80% data i en uppsättning kan betraktas som "coola", vilket innebär att de inte används för närvarande eller inte har använts nyligen. När du lagrar data på lagring med höga prestanda, till exempel Azure NetApp Files, slösas de pengar som spenderas på den kapacitet som används i stort sett bort eftersom lågfrekventa data inte kräver lagring med höga prestanda förrän de används igen.

Azure NetApp Files-lagring med låg åtkomst är avsedd att minska kostnaderna för molnlagring i Azure. Det finns prestandaöverväganden i specifika användningsfall som måste beaktas.

Åtkomst till data som har flyttats till lågfrekventa nivåer medför mer svarstid, särskilt för slumpmässig I/O. I värsta fall kan alla data som används vara på lågfrekvent nivå, så varje begäran skulle behöva utföra en hämtning av data. Det är ovanligt att alla data i en aktivt använd datamängd är på lågfrekvent nivå, så det är osannolikt att sådana svarstider observeras.

När standardprincipen för lågfrekvent åtkomsthämtning har valts, hanteras sekventiella I/O-läsningar direkt från lågfrekvent nivå och fylls inte på på den frekventa nivån igen. Slumpmässigt åtkomna data återförs till den heta nivån, vilket ökar prestandan för kommande läsningar. Optimeringar för sekventiella arbetsbelastningar minskar ofta svarstiden för molnhämtning jämfört med slumpmässiga läsningar och förbättrar övergripande prestanda.

I ett nyligen utfört test med Standard Storage med låg åtkomst för Azure NetApp Files erhölls följande resultat.

Anmärkning

Alla publicerade resultat är endast i referenssyfte. Resultaten garanteras inte eftersom prestanda i produktionsarbetsbelastningar kan variera på grund av flera faktorer.

100% sekventiella läsningar på varm/kall nivå (singeljobb)

I följande scenario användes ett enda jobb på en D32_V5 virtuell dator (VM) på en 50-TiB Azure NetApp Files-volym med ultraprestandanivån. Olika blockstorlekar användes för att testa prestanda på varma och kalla nivåer.

Anmärkning

Maxvärdet för Ultra-tjänstnivån är 128 MiB/s per tebibyte allokerad kapacitet. En vanlig Azure NetApp Files-volym kan hantera ett dataflöde på upp till cirka 5 000 MiB/s.

I följande diagram visas prestanda på låg nivå för det här testet med olika ködjup. Det maximala dataflödet för en enskild virtuell dator var cirka 400 MiB/s.

Diagram över lågfrekvent dataflöde i varierande blockstorlekar.

Prestanda på hett nivå var cirka 2,75 gånger bättre och nådde upp till ungefär 1 180 MiB/s.

Diagram över dataflöde på frekvent nivå i varierande blockstorlekar.

Det här diagrammet visar en jämförelse sida vid sida av kall och varm nivåprestanda med en blockstorlek på 256K.

Diagram över dataflöde med varierande

Vad orsakar latens i varma och kalla nivåer?

Svarstiden på den frekventa nivån är en faktor i själva lagringssystemet, där systemresurserna förbrukas när mer I/O skickas till tjänsten än vad som kan hanteras vid en viss tidpunkt. Därför måste operationer köa tills tidigare skickade operationer kan slutföras.

Svarstiden på den kalla nivån ses vanligtvis vid hämtningar från molnet: antingen förfrågningar över nätverket för I/O till objektlagret (sekventiella arbetsbelastningar) eller återhämtning av kalla block till den aktiva nivån (slumpmässiga arbetsbelastningar).

Resultatsammanfattning

  • När en arbetsbelastning är 100% sekventiell minskar den kalla nivåns genomströmning med ungefär 47% jämfört med den varma nivån (3330 MiB/s jämfört med 1742 MiB/s).
  • När en arbetsbelastning är 100% slumpmässig minskar den lågfrekventa nivåns dataflöde med ungefär 88% jämfört med den frekventa nivån (2 479 MiB/s jämfört med 280 MiB/s).
  • Prestandaminskningen för frekvent nivå vid 100% sekventiella (3 330 MiB/s) och 100% slumpmässiga arbetsbelastningar (2 479 MiB/s) var ungefär 25%. Prestandaminskningen för lågfrekvent nivå vid 100% sekventiella (1 742 MiB/s) och 100% slumpmässiga arbetsbelastningar (280 MiB/s) var ungefär 88%.
  • När en arbetsbelastning innehåller en procentandel slumpmässig i/o är det totala dataflödet för lågfrekvent nivå närmare 100% slumpmässigt än 100% sekventiellt.
  • Läsningar från lågfrekvent nivå minskade med cirka 50% när de flyttades från 100% sekventiella till en sekventiell/slumpmässig blandning 80/20.
  • Sekventiell I/O kan dra nytta av en readahead cache i Azure NetApp Files som slumpmässiga I/O inte gör. Den här fördelen med sekventiell I/O bidrar till att minska de övergripande prestandaskillnaderna mellan de frekventa och lågfrekventa nivåerna.

Överväganden och rekommendationer

  • Om din arbetsbelastning ofta ändrar åtkomstmönster på ett oförutsägbart sätt kanske lågfrekvent åtkomst inte är idealisk på grund av prestandaskillnaderna mellan frekventa och lågfrekventa nivåer.
  • Om din arbetsbelastning innehåller någon procentandel av slumpmässig I/O bör prestandaförväntningarna vid åtkomst till data på lågfrekvent nivå justeras i enlighet med detta.
  • Konfigurera fönstret för kall data och inställningarna för återhämtning av kall åtkomst för att matcha dina arbetsbelastningsmönster och minimera mängden kall datahämtning.
  • Prestanda från lågfrekvent åtkomst kan variera beroende på datamängden och systembelastningen där programmet körs. Vi rekommenderar att du utför relevanta tester med din datauppsättning för att förstå och ta hänsyn till prestandavariationer från lågfrekvent åtkomst.

Nästa steg