bulk of content done

Author: ekpgh

articles/hpc-cache/add-namespace-paths.md

@@ -4,7 +4,7 @@ description: How to create client-facing paths for back-end storage with Azure H
 author: ekpgh
 ms.service: hpc-cache
 ms.topic: how-to
-ms.date: 12/22/2020
+ms.date: 03/10/2021
 ms.author: v-erkel
 ---
 
@@ -128,6 +128,30 @@ The options used for the update command are similar to the "create" command, exc
 
 ---
 
+### ADLS-NFS namespace paths (PREVIEW)
+
+Like a regular blob storage target an ADLS-NFS storage target only has one export, so it can only have one one namespace path.
+
+Follow the instructions below to set or change the path with the Azure portal.
+
+From the Azure portal, load the **Namespace** settings page. You can add, change, or delete namespace paths from this page.
+
+* **Add a new path:** Click the **+ Add** button at the top and fill in information in the edit panel.
+
+  ![Screenshot of the add namespace edit fields with an ADLS-NFS storage target selected. The export and subdirectory paths are set to / and not editable.](media/namespace-add-adls.png)
+
+  * Enter the path clients will use to access this storage target.
+
+  * Select which access policy to use for this path. Learn more about customizing client access in [Use client access policies](access-policies.md).
+
+  * Select the storage target from the drop-down list. If an ADLS-NFS storage target already has a namespace path, it can't be selected.
+
+  * For an ADLS-NFS storage target, the export and subdirectory paths are automatically set to ``/``.
+
+* **Change an existing path:** Click the namespace path. The edit panel opens. You can modify the path and the access policy, but you can't change to a different storage target.
+
+* **Delete a namespace path:** Select the checkbox to the left of the path and click the **Delete** button.
+
 ## Next steps
 
 After creating the aggregated namespace for your storage targets, you can mount clients on the cache. Read these articles to learn more.

articles/hpc-cache/cache-usage-models.md

@@ -4,13 +4,13 @@ description: Describes the different cache usage models and how to choose among
 author: ekpgh
 ms.service: hpc-cache
 ms.topic: how-to
-ms.date: 03/04/2021
+ms.date: 03/08/2021
 ms.author: v-erkel
 ---
 
 # Understand cache usage models
 
-Cache usage models let you customize how your Azure HPC Cache stores files to speed up your workflow. 
+Cache usage models let you customize how your Azure HPC Cache stores files to speed up your workflow.
 
 ## Basic file caching concepts
 
@@ -26,7 +26,7 @@ File caching is how Azure HPC Cache expedites client requests. It uses these bas
 
 * **Write-back delay** - For a cache with write caching turned on, write-back delay is the amount of time the cache waits for additional file changes before moving the file to the back-end storage system.
 
-* **Back-end verification** - The back-end verification setting determines how frequently the cache compares its local copy of a file it fetched for a client with the remote version on the back-end storage system. If the back-end copy is newer than the cached copy, the cache fetches the remote copy and stores it for future requests.
+* **Back-end verification** - The back-end verification setting determines how frequently the cache compares its local copy of a file with the remote version on the back-end storage system. If the back-end copy is newer than the cached copy, the cache fetches the remote copy and stores it for future requests.
 
   The back-end verification setting shows when the cache *automatically* compares its files with source files in remote storage. However, you can force Azure HPC Cache to compare files by performing a directory operation that includes a readdirplus request. Readdirplus is a standard NFS API (also called extended read) that returns directory metadata, which causes the cache to compare and update files.
 
@@ -42,7 +42,7 @@ There are several options:
 
 * **Read heavy, infrequent writes** - Use this option if you want to speed up read access to files that are static or rarely changed.
 
-  This option caches client reads but doesn't cache writes (it passes them through to the back-end storage immediately).
+  This option caches client reads but doesn't cache writes. It passes writes through to the back-end storage immediately.
 
   Files stored in the cache are not automatically compared to the files on the NFS storage volume. (Read the description of back-end verification above to learn how to compare them manually.)
 
@@ -52,15 +52,17 @@ There are several options:
 
   In this usage model, files in the cache are only checked against the files on back-end storage every eight hours. The cached version of the file is assumed to be more current. A modified file in the cache is written to the back-end storage system after it has been in the cache for an hour with no additional changes.
 
-* **Clients write to the NFS target, bypassing the cache** - Choose this option if any clients in your workflow write data directly to the storage system without first writing to the cache, or if you want to optimize data consistency. Files that clients request are cached, but any changes to those files from the client are passed back to the back-end storage system immediately.
+* **Clients write to the NFS target, bypassing the cache** - Choose this option if any clients in your workflow write data directly to the storage system without first writing to the cache, or if you want to optimize data consistency. Files that clients request are cached (reads), but any changes to those files from the client (writes) are not cached. They are passed through directly to the back-end storage system.
 
   With this usage model, the files in the cache are frequently checked against the back-end versions for updates. This verification allows files to be changed outside of the cache while maintaining data consistency.
 
-* **Greater than 15% writes, checking the backing server for changes every 30 seconds** and **Greater than 15% writes, checking the backing server for changes every 60 seconds** - 
+* **Greater than 15% writes, checking the backing server for changes every 30 seconds** and **Greater than 15% writes, checking the backing server for changes every 60 seconds** - These options are designed for workflows where you want to speed up both reads and writes, but there's a chance that another user will write directly to the back-end storage system. For example, if multiple sets of clients are working on the same files from different locations, these usage models might make sense to balance the need for quick file access with low tolerance for stale content from the source.
 
-* **Greater than 15% writes, write back to the server every 30 seconds** (Collaborating cloud workstation) - 
+* **Greater than 15% writes, write back to the server every 30 seconds** (Collaborating cloud workstation) - This option is designed for the scenario where multiple clients are actively modifying the same files, or if some clients access the back-end storage directly instead of mounting the cache.
 
-* **Read heavy, checking the backing server every 3 hours** (Read-only high verification time) - 
+  The frequent back-end writes affect cache performance, so you should consider using the **Greater than 15% writes** usage model if there's a low risk of file conflict - for example, if you know that different clients are working in different areas of the same file set.
+
+* **Read heavy, checking the backing server every 3 hours** (Read-only high verification time) - This option prioritizes fast reads on the client side, but also refreshes cached files from the back-end storage system more quickly than the **Read heavy, infrequent writes** usage model.
 
 This table summarizes the usage model differences:
 
@@ -74,7 +76,8 @@ This table summarizes the usage model differences:
 | Greater than 15% writes, frequent write-back (Collaborating cloud workstation) | Read/write | 30 seconds | 30 seconds |
 | Read heavy, checking the backing server every 3 hours (Read-only high verification time)| Read | 3 hours | None |
 
+If you have questions about the best usage model for your Azure HPC Cache workflow, talk to your Azure representative or open a support request for help.
 
-## Next steps:
+## Next steps
 
-* 
+* [Add storage targets](hpc-cache-add-storage.md) to your Azure HPC Cache

articles/hpc-cache/configuration.md

@@ -71,7 +71,9 @@ Your cache uses the Azure-based time server time.microsoft.com by default. If yo
 - (stuff about how to configure and why not to - from that email thread)
 - (something about a DNS forwarder?)
 
-??? where to document refresh DNS? ??? 
+### Refresh storage target DNS
+
+If your DNS configuration changes, storage targets will become unavailable. Read how to update your custom DNS system IP address in [Edit storage targets](hpc-cache-edit-storage.md#update-ip-address-custom-dns-configurations-only).
 
 
 ## View snapshots for blob storage targets

articles/hpc-cache/hpc-cache-add-storage.md

@@ -36,6 +36,9 @@ A new Blob storage target needs an empty Blob container or a container that is p
 
 The Azure portal **Add storage target** page includes the option to create a new Blob container just before you add it.
 
+> [!NOTE]
+> For NFS-mounted blob storage, use the [ADLS-NFS storage target](#) type.
+
 ### [Portal](#tab/azure-portal)
 
 From the Azure portal, open your cache instance and click **Storage targets** on the left sidebar.
@@ -161,11 +164,11 @@ An NFS storage target has different settings from a Blob storage target. The usa
 
 When you create a storage target that uses NFS to reach its storage system, you need to choose a usage model for that target. This model determines how your data is cached.
 
-Read [Understand usage models](cach-usage-models.md) for more details about all of these settings.
+Read [Understand usage models](cache-usage-models.md) for more details about all of these settings.
 
 The built-in usage models let you choose how to balance fast response with the risk of getting stale data. If you want to optimize speed for reading files, you might not care whether the files in the cache are checked against the back-end files. On the other hand, if you want to make sure your files are always up to date with the remote storage, choose a model that checks frequently.
 
-These are the most frequently used options:
+These three options cover most situations:
 
 * **Read heavy, infrequent writes** - Speeds up read access to files that are static or rarely changed.
 
@@ -183,6 +186,8 @@ These are the most frequently used options:
 
   Files that clients request are cached, but any changes to those files from the client are passed through to the back-end storage system immediately. Files in the cache are frequently checked against the back-end versions for updates. This verification maintains data consistency when files are changed directly on the storage system instead of through the cache.
 
+For details about the other options, read [Understand usage models](cache-usage-models.md).
+
 This table summarizes the differences among all of the usage models:
 
 | Usage model | Caching mode | Back-end verification | Maximum write-back delay |
@@ -296,6 +301,43 @@ Output:
 
 ---
 
+## Add a new ADLS-NFS storage target (PREVIEW)
+
+ADLS-NFS storage targets use Azure Blob containers that support the Network File System (NFS) 3.0 protocol.
+
+> [!NOTE]
+> NFS 3.0 protocol support for Azure Blob storage is in public preview. Availability is restricted, and features might change between now and when the feature becomes generally available. Do not use preview technology in production systems.
+>
+> Read [NFS 3.0 protocol support](../storage/blobs/network-file-system-protocol-support.md) for the latest information.
+
+ADLS-NFS storage targets have some similarities with Blob storage targets and some with NFS storage targets. For example:
+
+* Like a Blob storage target, you need to give Azure HPC Cache permission to [access your storage account](#add-the-access-control-roles-to-your-account).
+* Like an NFS storage target, you need to set a cache [usage model](#choose-a-usage-model).
+* Because NFS-enabled blob containers have an NFS-compatible hierarchical structure, you do not need to use the cache to ingest data, and the containers are readable by other NFS systems. You can pre-load data in an ADLS-NFS container, then add it to an HPC cache as storage target, and then access the data later from outside of an HPC cache. When you use a standard blob container as an HPC cache storage target, the data is written in a proprietary format and can only be accessed from other Azure HPC Cache-compatible products.
+
+Before you can create an ADLS-NFS storage target, you must create an NFS-enabled storage account. Follow the tips in [Prerequisites for Azure HPC Cache](hpc-cache-prerequisites.md#nfs-mounted-blob-adls-nfs-storage-requirements-preview) and the instructions in [Mount Blob storage by using NFS](../storage/blobs/network-file-system-protocol-support-how-to). After your storage account is set up you can create a new container when you create the storage target.
+
+To create an ADLS-NFS storage target, Open the **Add storage target** page in the Azure portal. (Additional methods are in development.)
+
+![Screenshot of add storage target page with ADLS-NFS target defined](media/add-adls-target.png)
+
+Enter this information.
+
+* **Storage target name** - Set a name that identifies this storage target in the Azure HPC Cache.
+* **Target type** - Choose **ADLS-NFS**.
+* **Storage account** - Select the account that you want to use. If your NFS-enabled storage account does not appear in the list, check that it conforms to the prerequisites and that the cache can access it.
+
+  You will need to authorize the cache instance to access the storage account as described in [Add the access roles](#add-the-access-control-roles-to-your-account).
+
+* **Storage container** - Select the NFS-enabled blob container for this target, or click **Create new**.
+
+* **Usage model** - Choose one of the data caching profiles based on your workflow, described in [Choose a usage model](#choose-a-usage-model) above.
+
+When finished, click **OK** to add the storage target.
+
+<!-- **** -->
+
 ## View storage targets
 
 You can use the Azure portal or the Azure CLI to show the storage targets already defined for your cache.

articles/hpc-cache/hpc-cache-edit-storage.md

@@ -4,7 +4,7 @@ description: How to edit Azure HPC Cache storage targets
 author: ekpgh
 ms.service: hpc-cache
 ms.topic: how-to
-ms.date: 09/30/2020
+ms.date: 03/10/2021
 ms.author: v-erkel
 ---
 
@@ -14,14 +14,17 @@ You can remove or modify storage targets with the Azure portal or by using the A
 
 Depending on the type of storage, you can modify these storage target values:
 
-* For Blob storage targets, you can change the namespace path.
+* For Blob storage targets, you can change the namespace path and access policy.
 
 * For NFS storage targets, you can change these values:
 
   * Namespace paths
+  * Access policy
   * The storage export or export subdirectory associated with a namespace path
   * Usage model
 
+* For ADLS-NFS storage targets, you can change the namespace path, access policy, and the usage model.
+
 You can't edit a storage target's name, type, or back-end storage system (Blob container or NFS hostname/IP address). If you need to change these properties, delete the storage target and create a replacement with the new value.
 
 > [!TIP]
@@ -93,7 +96,7 @@ Storage targets in caches with some types of custom DNS settings also have a con
 
 Details are below:
 
-* [Change aggregated namespace values](#change-aggregated-namespace-values) (virtual namespace path, export, and export subdirectory)
+* [Change aggregated namespace values](#change-aggregated-namespace-values) (virtual namespace path, access policy, export, and export subdirectory)
 * [Change the usage model](#change-the-usage-model)
 * [Refresh DNS](#update-ip-address-custom-dns-configurations-only)
 
@@ -110,7 +113,7 @@ Use the **Namespace** page for your Azure HPC Cache to update namespace values.
 ![screenshot of the portal namespace page with the NFS update page open at the right](media/update-namespace-nfs.png)
 
 1. Click the name of the path that you want to change.
-1. Use the edit window to type in new virtual path, export, or subdirectory values.
+1. Use the edit window to type in new virtual path, export, or subdirectory values, or to select a different access policy.
 1. After making changes, click **OK** to update the storage target or **Cancel** to discard changes.
 
 ### [Azure CLI](#tab/azure-cli)
@@ -175,10 +178,33 @@ If the cache is stopped or not in a healthy state, the update will apply after t
 
 ### Update IP address (custom DNS configurations only)
 
-If your cache uses a non-default DNS configuration, it's possible for your storage target's IP address to change because of back-end DNS changes. If your DNS server changes the back-end storage system's IP address, Azure HPC Cache can lose access to the storage system.
+If your cache uses a non-default DNS configuration, it's possible for your NFS storage target's IP address to change because of back-end DNS changes. If your DNS server changes the back-end storage system's IP address, Azure HPC Cache can lose access to the storage system.
+
+Ideally, you should work with the manager of your cache's custom DNS system to plan for any updates, because these changes make storage unavailable.
+
+If you need to update a storage target's DNS-provided IP address, there is a button on the Storage targets list. Click **Refresh DNS** to query the custom DNS server for a new IP address.
+
+![Screenshot of storage target list. For one storage target, the "..." menu in the far right column is open and two options appear: Delete, and Refresh DNS.](media/refresh-dns.png)
+
+If successful, the update should take less than two minutes. You can only refresh one storage target at a time; wait for the previous operation to complete before trying another.
+
+## Update an ADLS-NFS storage target (PREVIEW)
+
+Similar to NFS targets, you can change the namespace path and the usage model for ADLS-NFS storage targets.
+
+### Change an ADLS-NFS namespace path
+
+Use the **Namespace** page for your Azure HPC Cache to update namespace values. This page is described in more detail in the article [Set up the aggregated namespace](add-namespace-paths.md).
+
+![screenshot of the portal namespace page with an ADS-NFS update page open at the right](media/update-namespace-adls.png)
+
+1. Click the name of the path that you want to change.
+1. Use the edit window to type in new virtual path, or update the access policy.
+1. After making changes, click **OK** to update the storage target or **Cancel** to discard changes.
+
+### Change ADLS-NFS usage models
 
-+ description and screensots of DNS refresh
-+ why this is an interpersonal problem and maybe you should look into relationship counseling (clash scenarios things?)
+The configuration for ADLS-NFS usage models is identical to the NFS usage model selection. Read the portal instructions in [Change the usage model](#change-the-usage-model) in the NFS section above. Additional tools for updating ADLS-NFS storage targets are in development.
 
 
 ## Next steps

articles/hpc-cache/hpc-cache-prerequisites.md

@@ -184,7 +184,7 @@ This is a general overview of the steps:
 
 1. Make sure that the features you need are available in the regions where you plan to work.
 
-1. Enable the NFS protocol feature for your subscription. Do this before you create the storage account.
+1. Enable the NFS protocol feature for your subscription. Do this *before* you create the storage account.
 
 1. Create a secure virtual network (VNet) for the storage account. You should use the same virtual network for your NFS-enabled storage account and for your Azure HPC Cache.
 

articles/hpc-cache/media/add-adls-target.png

@@ -10,6 +10,8 @@
   items:
   - name: Plan the aggregated namespace
     href: hpc-cache-namespace.md
+  - name: Understand cache usage models
+    href: cache-usage-models.md
   - name: Security
     items:
     - name: Security baseline