Dela via

Använda NFS-monterad bloblagring med Azure HPC Cache

  • Artikel

Du kan använda NFS-monterade blobcontainrar med Azure HPC Cache. Läs mer om NFS 3.0-protokollstöd i Azure Blob Storage på dokumentationswebbplatsen för Blob Storage.

Azure HPC Cache använder NFS-aktiverad bloblagring i sin måltyp för ADLS-NFS-lagring. Dessa lagringsmål liknar vanliga NFS-lagringsmål, men har även viss överlappning med vanliga Azure Blob-mål.

Den här artikeln beskriver strategier och begränsningar som du bör förstå när du använder ADLS-NFS-lagringsmål.

Du bör också läsa NFS-blobdokumentationen, särskilt de här avsnitten som beskriver kompatibla och inkompatibla scenarier, och ge felsökningstips:

Förstå konsekvenskrav

HPC Cache kräver stark konsekvens för ADLS-NFS-lagringsmål. Som standard uppdaterar NFS-aktiverad bloblagring inte strikt filmetadata, vilket hindrar HPC Cache från att jämföra filversioner korrekt.

För att undvika den här skillnaden inaktiverar Azure HPC Cache automatiskt cachelagring av NFS-attribut på alla NFS-aktiverade blobcontainer som används som lagringsmål.

Den här inställningen bevaras under containerns livslängd, även om du tar bort den från cacheminnet.

Förinlästa data med NFS-protokoll

I en NFS-aktiverad blobcontainer kan en fil bara redigeras av samma protokoll som användes när den skapades. Om du använder Azure REST API för att fylla i en container kan du alltså inte använda NFS för att uppdatera dessa filer. Eftersom Azure HPC Cache endast använder NFS kan det inte redigera några filer som har skapats med Azure REST API. (Läs mer om kända problem med BLOB Storage-API:er)

Det är inte ett problem för cacheminnet om containern är tom eller om filerna skapades med hjälp av NFS.

Om filerna i containern har skapats med Azure Blob REST API i stället för NFS är Azure HPC Cache begränsat till dessa åtgärder på de ursprungliga filerna:

  • Visa en lista över filen i en katalog.
  • Läs filen (och håll den i cacheminnet för efterföljande läsningar).
  • Ta bort filen.
  • Töm filen (trunkera den till 0).
  • Spara en kopia av filen. Kopian är markerad som en NFS-skapad fil och kan redigeras med hjälp av NFS.

Azure HPC Cache kan inte redigera innehållet i en fil som skapades med hjälp av REST. Det innebär att cacheminnet inte kan spara en ändrad fil från en klient tillbaka till lagringsmålet.

Det är viktigt att förstå den här begränsningen eftersom den kan orsaka dataintegritetsproblem om du använder användningsmodeller för läs-/skrivcachelagring på filer som inte har skapats med NFS.

Dricks

Läs mer om cachelagring av läsning och skrivning i Förstå cacheanvändningsmodeller.

Scenarier för skrivcachelagring

Dessa cacheanvändningsmodeller omfattar skrivcachelagring:

  • Större än 15 % skrivningar
  • Större än 15 % skrivningar, kontrollerar säkerhetskopieringsservern efter ändringar var 30:e sekund
  • Större än 15 % skrivningar, kontrollerar säkerhetskopieringsservern efter ändringar var 60:e sekund
  • Större än 15 % skrivningar, skriv tillbaka till servern var 30:e sekund

Användningsmodeller för skrivcachelagring ska endast användas på filer som har skapats med NFS.

Om du försöker använda skrivcachelagring på REST-skapade filer kan dina filändringar gå förlorade. Det beror på att cacheminnet inte försöker spara filredigeringar i lagringscontainern omedelbart.

Så här gör du för att cachelagrat skrivningar till REST-skapade filer som utsätter data för risk:

  1. Cacheminnet accepterar redigeringar från klienter och returnerar ett meddelande om lyckade ändringar.

  2. Cacheminnet behåller den ändrade filen i sin lagring och väntar på ytterligare ändringar.

  3. När en tid har passerat försöker cacheminnet spara den ändrade filen i serverdelscontainern. Nu visas ett felmeddelande eftersom det försöker skriva till en REST-skapad fil med NFS.

    Det är för sent att tala om för klientdatorn att dess ändringar inte accepterades och att cacheminnet inte kan uppdatera den ursprungliga filen. Så ändringarna från klienter kommer att gå förlorade.

Läsa cachelagringsscenarier

Scenarier med läscachelagring är lämpliga för filer som skapats med antingen NFS eller Azure Blob REST API.

Dessa användningsmodeller använder endast skrivskyddad cachelagring:

  • Läs tunga, ovanliga skrivningar
  • Klienter skriver till NFS-målet och kringgår cacheminnet
  • Läs tungt och kontrollera säkerhetskopieringsservern var 3:e timme

Du kan använda dessa användningsmodeller med filer som skapats av REST API eller av NFS. NFS-skrivningar som skickas från en klient till serverdelscontainern misslyckas fortfarande, men de misslyckas omedelbart och returnerar ett felmeddelande till klienten.

Ett arbetsflöde för läscachelagring kan fortfarande omfatta filändringar, så länge dessa inte cachelagras. Klienter kan till exempel komma åt filer från containern men skriva tillbaka sina ändringar som en ny fil, eller så kan de spara ändrade filer på en annan plats.

Identifiera begränsningar i Network Lock Manager (NLM)

NFS-aktiverade blobcontainrar stöder inte Network Lock Manager (NLM), som är ett vanligt NFS-protokoll för att skydda filer från konflikter.

Om ditt NFS-arbetsflöde ursprungligen skrevs för maskinvarulagringssystem kan klientprogrammen innehålla NLM-begäranden. Om du vill kringgå den här begränsningen när du flyttar processen till NFS-aktiverad bloblagring kontrollerar du att klienterna inaktiverar NLM när de monterar cacheminnet.

Om du vill inaktivera NLM använder du alternativet -o nolock i klienternas mount kommando. Det här alternativet förhindrar att klienterna begär NLM-lås och får fel som svar. Alternativet nolock implementeras på olika sätt i olika operativsystem. Mer information finns i dokumentationen om klientoperativsystemet (man 5 nfs).

Effektivisera skrivningar till NFS-aktiverade containrar med HPC Cache

Azure HPC Cache kan hjälpa till att förbättra prestanda i en arbetsbelastning som inkluderar att skriva ändringar i ett ADLS-NFS-lagringsmål.

Kommentar

Du måste använda NFS för att fylla i din ADLS-NFS-lagringscontainer om du vill ändra dess filer via Azure HPC Cache.

En av de begränsningar som beskrivs i artikeln NFS-aktiverade blobprestandaöverväganden är att ADLS-NFS-lagring inte är särskilt effektivt för att skriva över befintliga filer. Om du använder Azure HPC Cache med NFS-monterad bloblagring hanterar cacheminnet tillfälliga omskrivningar när klienter ändrar en aktiv fil. Svarstiden för att skriva en fil till serverdelscontainern är dold från klienterna.

Tänk på de begränsningar som beskrivs ovan i Förinlästa data med NFS-protokollet.

Nästa steg