De geaggregeerde naamruimte plannen
Azure HPC Cache kunnen clients toegang krijgen tot verschillende opslagsystemen via een virtuele naamruimte die de details van het back-endopslagsysteem verbergt.
Nadat u een opslagdoel hebt toevoegen, stelt u een of meer client gerichte naamruimtepaden in voor het opslagdoel. Clientmachines kunnen dit bestandspad aan dit bestandspad toevoegen en aanvragen voor het lezen van bestanden naar de cache maken in plaats van het opslagsysteem rechtstreeks te mounten.
Omdat Azure HPC Cache dit virtuele bestandssysteem beheert, kunt u het opslagdoel wijzigen zonder het client-gerichte pad te wijzigen. U kunt bijvoorbeeld een hardwareopslagsysteem vervangen door cloudopslag zonder dat u procedures aan de clientzijde hoeft te herschrijven.
Voorbeeld van geaggregeerde naamruimte
Plan uw geaggregeerde naamruimte zodat clientmachines gemakkelijk de informatie kunnen bereiken die ze nodig hebben, zodat beheerders en werkstroomtechnici de paden gemakkelijk kunnen onderscheiden.
Denk bijvoorbeeld aan een systeem waarin een Azure HPC Cache 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 informatie die nodig is voor deze taak wordt opgeslagen in de volgende subdirecties:
- /goldline/templates/acme2017/sku798
- /goldline/templates/acme2017/sku980
Het opslagsysteem van het datacenter maakt de volgende 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 het CLFSLoad-hulpprogramma.
Voor eenvoudige toegang via de cache kunt u opslagdoelen maken met deze virtuele naamruimtepaden:
| Back-endopslagsysteem (NFS-bestandspad of Blob-container) |
Pad naar virtuele naamruimte |
|---|---|
| /goldline/templates/acme2017/sku798 | /templates/sku798 |
| /goldline/templates/acme2017/sku980 | /templates/sku980 |
| sourcecollection | /source/ |
Een NFS-opslagdoel kan meerdere virtuele naamruimtepaden hebben, zolang elke locatie verwijst naar een uniek exportpad. (Lees NFS-naamruimtepaden voor meer informatie over het gebruik van meerdere naamruimtepaden met een NFS-opslagdoel.)
Omdat de NFS-bronpaden subdirecties van dezelfde export zijn, moet u meerdere naamruimtepaden van hetzelfde opslagdoel definiëren.
| Storage hostnaam van doel | NFS-exportpad | Pad naar subdirectory | Naamruimtepad |
|---|---|---|---|
| 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 aan elkaar toevoegen en eenvoudig toegang krijgen tot de geaggregeerde bestandspaden /source /templates/sku798 , en /templates/sku980 .
Een alternatieve methode kan zijn om een virtueel pad te maken zoals dat is koppelingen naar de bovenliggende map, , en vervolgens de clients te laten navigeren naar de afzonderlijke mappen en na het koppelen van /templates acme2017 de sku798 sku980 cache. U kunt echter geen naamruimtepad maken dat een subdirectory van een ander naamruimtepad is. Als u dus een pad naar de map maakt, kunt u niet ook naamruimtepaden maken om rechtstreeks toegang te krijgen tot acme2017 de subdirectory's.
Op Azure HPC Cache pagina Naamruimteinstellingen wordt het client-gerichte bestandssysteem weergegeven en kunt u paden toevoegen of bewerken. Lees Set up the aggregated namespace (De geaggregeerde naamruimte instellen) voor meer informatie.
Volgende stappen
Nadat u hebt besloten hoe u uw virtuele bestandssysteem in kunt stellen, moet u deze stappen volgen om het te maken:
- Opslagdoelen maken om uw back-endopslagsystemen toe te voegen aan uw Azure HPC Cache
- Voeg naamruimtepaden toe om de geaggregeerde naamruimte te maken die clientmachines gebruiken voor toegang tot bestanden