Delen via

NFS-gekoppelde blobopslag gebruiken met Azure HPC Cache

  • Artikel

U kunt NFS-gekoppelde blobcontainers gebruiken met Azure HPC Cache. Lees meer over de ondersteuning van het NFS 3.0-protocol in Azure Blob Storage op de documentatiesite voor Blob Storage.

Azure HPC Cache maakt gebruik van blobopslag met NFS-functionaliteit in het ADLS-NFS-opslagdoeltype. Deze opslagdoelen zijn vergelijkbaar met reguliere NFS-opslagdoelen, maar hebben ook enige overlapping met reguliere Azure Blob-doelen.

In dit artikel worden strategieën en beperkingen uitgelegd die u moet begrijpen wanneer u ADLS-NFS-opslagdoelen gebruikt.

Lees ook de NFS-blobdocumentatie, met name in deze secties waarin compatibele en niet-compatibele scenario's worden beschreven, en geef tips voor het oplossen van problemen:

Consistentievereisten begrijpen

HPC Cache vereist sterke consistentie voor ADLS-NFS-opslagdoelen. Blob-opslag met NFS-functionaliteit werkt standaard geen bestandsmetagegevens bij, waardoor HPC Cache bestandsversies niet nauwkeurig kan vergelijken.

Om dit verschil te omzeilen, schakelt Azure HPC Cache automatisch caching van NFS-kenmerken uit op een NFS-blobcontainer die wordt gebruikt als opslagdoel.

Deze instelling blijft behouden voor de levensduur van de container, zelfs als u deze uit de cache verwijdert.

Gegevens vooraf laden met NFS-protocol

In een blobcontainer met NFS-functionaliteit kan een bestand alleen worden bewerkt door hetzelfde protocol dat is gebruikt toen het werd gemaakt. Als u de Azure REST API gebruikt om een container te vullen, kunt u NFS dus niet gebruiken om deze bestanden bij te werken. Omdat Azure HPC Cache alleen gebruikmaakt van NFS, kunnen er geen bestanden worden bewerkt die zijn gemaakt met de Azure REST API. (Meer informatie over bekende problemen met Blob Storage-API's)

Het is geen probleem voor de cache als uw container leeg is of als de bestanden zijn gemaakt met behulp van NFS.

Als de bestanden in uw container zijn gemaakt met de Azure Blob REST API in plaats van NFS, is Azure HPC Cache beperkt tot deze acties op de oorspronkelijke bestanden:

  • Vermeld het bestand in een map.
  • Lees het bestand (en bewaar het in de cache voor volgende leesbewerkingen).
  • Verwijder het bestand.
  • Maak het bestand leeg (kap het af op 0).
  • Sla een kopie van het bestand op. De kopie is gemarkeerd als een door NFS gemaakt bestand en kan worden bewerkt met NFS.

Azure HPC Cache kan de inhoud van een bestand dat is gemaakt met REST niet bewerken. Dit betekent dat de cache een gewijzigd bestand niet kan opslaan van een client naar het opslagdoel.

Het is belangrijk om deze beperking te begrijpen, omdat dit problemen met gegevensintegriteit kan veroorzaken als u gebruiksmodellen voor lees-/schrijfcaching gebruikt voor bestanden die niet zijn gemaakt met NFS.

Fooi

Meer informatie over het lezen en schrijven van caching in De cachegebruiksmodellen begrijpen.

Scenario's voor het schrijven van caching

Deze cachegebruiksmodellen omvatten schrijfcaching:

  • Meer dan 15% schrijfbewerkingen
  • Meer dan 15% schrijfbewerkingen, waarbij u de back-upserver elke 30 seconden controleert op wijzigingen
  • Meer dan 15% schrijfbewerkingen, waarbij u de back-upserver elke 60 seconden controleert op wijzigingen
  • Schrijfbewerkingen van meer dan 15% en schrijf elke 30 seconden terug naar de server

Gebruiksmodellen voor schrijfcaching mogen alleen worden gebruikt voor bestanden die zijn gemaakt met NFS.

Als u schrijfcaching probeert te gebruiken voor door REST gemaakte bestanden, kunnen de bestandswijzigingen verloren gaan. Dit komt doordat de cache niet probeert bestandsbewerkingen onmiddellijk op te slaan in de opslagcontainer.

Hier ziet u hoe het in de cache opslaan van schrijfbewerkingen naar DOOR REST gemaakte bestanden gegevens in gevaar brengt:

  1. De cache accepteert bewerkingen van clients en retourneert een geslaagd bericht bij elke wijziging.

  2. De cache bewaart het gewijzigde bestand in de opslag en wacht op aanvullende wijzigingen.

  3. Nadat enige tijd is verstreken, probeert de cache het gewijzigde bestand op te slaan in de back-endcontainer. Op dit moment krijgt het een foutbericht omdat het probeert te schrijven naar een REST-bestand met NFS.

    Het is te laat om de clientcomputer te vertellen dat de wijzigingen niet zijn geaccepteerd en dat de cache geen manier heeft om het oorspronkelijke bestand bij te werken. De wijzigingen van clients gaan dus verloren.

Cachescenario's lezen

Leescachingscenario's zijn geschikt voor bestanden die zijn gemaakt met NFS of Azure Blob REST API.

Deze gebruiksmodellen gebruiken alleen leescache:

  • Zware, onregelmatige schrijfbewerkingen lezen
  • Clients schrijven naar het NFS-doel, waarbij de cache wordt overgeslagen
  • Lees zwaar, controleer de backingserver elke 3 uur

U kunt deze gebruiksmodellen gebruiken met bestanden die zijn gemaakt door REST API of door NFS. NFS-schrijfbewerkingen die van een client naar de back-endcontainer worden verzonden, mislukken nog steeds, maar mislukken onmiddellijk en retourneren een foutbericht aan de client.

Een werkstroom voor leescache kan nog steeds bestandswijzigingen omvatten, zolang deze niet in de cache zijn opgeslagen. Clients kunnen bijvoorbeeld toegang krijgen tot bestanden uit de container, maar hun wijzigingen terugschrijven als een nieuw bestand, of ze kunnen gewijzigde bestanden opslaan op een andere locatie.

Beperkingen van Network Lock Manager (NLM) herkennen

Blobcontainers met NFS bieden geen ondersteuning voor Network Lock Manager (NLM), een veelgebruikt NFS-protocol om bestanden te beschermen tegen conflicten.

Als uw NFS-werkstroom oorspronkelijk is geschreven voor hardwareopslagsystemen, kunnen uw clienttoepassingen NLM-aanvragen bevatten. Als u deze beperking wilt omzeilen bij het verplaatsen van uw proces naar NFS-blobopslag, moet u ervoor zorgen dat uw clients NLM uitschakelen wanneer ze de cache koppelen.

Als u NLM wilt uitschakelen, gebruikt u de optie -o nolock in de opdracht van mount uw clients. Met deze optie voorkomt u dat clients NLM-vergrendelingen aanvragen en fouten ontvangen in reactie. De nolock optie wordt anders geïmplementeerd in verschillende besturingssystemen. Raadpleeg de documentatie van het clientbesturingssysteem (man 5 nfs) voor meer informatie.

Schrijfbewerkingen stroomlijnen naar containers met NFS-functionaliteit met HPC Cache

Azure HPC Cache kan helpen bij het verbeteren van de prestaties in een workload met schrijfwijzigingen in een ADLS-NFS-opslagdoel.

Notitie

U moet NFS gebruiken om uw ADLS-NFS-opslagcontainer te vullen als u de bestanden wilt wijzigen via Azure HPC Cache.

Een van de beperkingen die worden beschreven in het artikel met betrekking tot blobprestaties met NFS-functionaliteit is dat ADLS-NFS-opslag niet erg efficiënt is bij het overschrijven van bestaande bestanden. Als u Azure HPC Cache gebruikt met NFS-gekoppelde blobopslag, verwerkt de cache onregelmatige herschrijfbewerkingen als clients een actief bestand wijzigen. De latentie van het schrijven van een bestand naar de back-endcontainer is verborgen voor de clients.

Houd rekening met de hierboven beschreven beperkingen in gegevens vooraf laden met het NFS-protocol.

Volgende stappen