De geaggregeerde naamruimte plannen
Met Azure HPC Cache hebben clients toegang tot verschillende opslagsystemen via een virtuele naamruimte die de details van het back-endopslagsysteem verbergt.
Nadat u een opslagdoel hebt toegevoegd, stelt u een of meer clientgerichte naamruimtepaden in voor het opslagdoel. Clientcomputers koppelen dit bestandspad en kunnen bestandsleesaanvragen indienen bij de cache in plaats van het opslagsysteem rechtstreeks te koppelen.
Omdat Azure HPC Cache dit virtuele bestandssysteem beheert, kunt u het opslagdoel wijzigen zonder het clientgerichte pad te wijzigen. U kunt bijvoorbeeld een hardwareopslagsysteem vervangen door cloudopslag zonder dat u procedures aan de clientzijde hoeft te herschrijven.
Voorbeeld van een samengevoegde naamruimte
Plan uw geaggregeerde naamruimte zodat clientcomputers gemakkelijk de informatie kunnen bereiken die ze nodig hebben en zodat beheerders en werkstroomtechnici de paden eenvoudig kunnen onderscheiden.
Denk bijvoorbeeld aan een systeem waarin een Azure HPC Cache-exemplaar wordt gebruikt voor het verwerken van gegevens die zijn opgeslagen in Azure Blob. Voor de analyse zijn sjabloonbestanden vereist die zijn opgeslagen in een on-premises datacenter.
De sjabloongegevens worden opgeslagen in een datacenter en de benodigde informatie voor deze taak wordt opgeslagen in deze submappen:
- /goldline/templates/acme2017/sku798
- /goldline/templates/acme2017/sku980
Het datacenteropslagsysteem maakt deze exports beschikbaar:
- /
- /goldline
- /goldline/templates
De gegevens die moeten worden geanalyseerd, zijn gekopieerd naar een Azure Blob Storage-container met de naam 'sourcecollection' met behulp van de NFS-gegevensimporttechnieken die worden beschreven in Move data to Azure Blob Storage.
Voor eenvoudige toegang via de cache kunt u opslagdoelen maken met deze virtuele naamruimtepaden:
| Back-endopslagsysteem (NFS-bestandspad of blobcontainer) |
Pad naar virtuele naamruimte |
|---|---|
| /goldline/templates/acme2017/sku798 | /templates/sku798 |
| /goldline/templates/acme2017/sku980 | /templates/sku980 |
| sourcecollection | /Bron/ |
Een NFS-opslagdoel kan meerdere virtuele naamruimtepaden hebben, zolang elk verwijst naar een uniek exportpad. (Lezen NFS-naamruimtepaden voor meer informatie over het gebruik van meerdere naamruimtepaden met een NFS-opslagdoel.)
Omdat de NFS-bronpaden submappen van dezelfde export zijn, moet u meerdere naamruimtepaden van hetzelfde opslagdoel definiëren.
| Hostnaam van opslagdoel | NFS-exportpad | Pad naar submap | Pad naar naamruimte |
|---|---|---|---|
| IP-adres of hostnaam | /goldline/templates | acme2017/sku798 | /templates/sku798 |
| IP-adres of hostnaam | /goldline/templates | acme2017/sku980 | /templates/sku980 |
Een clienttoepassing kan de cache koppelen en eenvoudig toegang krijgen tot de paden /sourcevan het samengevoegde naamruimtebestand , /templates/sku798en /templates/sku980.
Een alternatieve benadering is het maken van een virtueel pad zoals /templates die koppelingen naar de bovenliggende map, acme2017en vervolgens de clients naar de afzonderlijke sku798 map en sku980 mappen laten navigeren nadat de cache is gekoppeld. U kunt echter geen naamruimtepad maken dat een submap van een andere naamruimtepad is. Dus als u een pad naar de acme2017 map maakt, kunt u geen naamruimtepaden maken om rechtstreeks toegang te krijgen tot de submappen.
Op de pagina Instellingen voor azure HPC Cache-naamruimte ziet u het clientgerichte bestandssysteem en kunt u paden toevoegen of bewerken. Lees De samengevoegde naamruimte instellen voor meer informatie.
Volgende stappen
Nadat u hebt besloten hoe u uw virtuele bestandssysteem instelt, voert u de volgende stappen uit om het te maken:
- Opslagdoelen maken om uw back-endopslagsystemen toe te voegen aan uw Azure HPC Cache
- Naamruimtepaden toevoegen om de geaggregeerde naamruimte te maken die clientcomputers gebruiken voor toegang tot bestanden