Azure Managed Lustre file system prerequisites

This article explains prerequisites that you must configure before creating an Azure Managed Lustre file system.

• Network prerequisites
• Blob integration prerequisites(optional)

Network prerequisites

Azure Managed Lustre file systems exist in a virtual network subnet. The subnet contains the Lustre Management Service (MGS) and handles all client interactions with the virtual Lustre cluster.

You can't move a file system from one network or subnet to another after you create the file system.

Azure Managed Lustre accepts only IPv4 addresses. IPv6 isn't supported.

Network size requirements

The size of subnet that you need depends on the size of the file system you create. The following table gives a rough estimate of the minimum subnet size for Azure Managed Lustre file systems of different sizes.

Other network size considerations

When you plan your virtual network and subnet, take into account the requirements for any other services you want to locate within the Azure Managed Lustre subnet or virtual network.

If you're using an Azure Kubernetes Service (AKS) cluster with your Azure Managed Lustre file system, you can locate the AKS cluster in the same subnet as the file system. In this case, you must provide enough IP addresses for the AKS nodes and pods in addition to the address space for the Lustre file system. If you use more than one AKS cluster within the virtual network, make sure the virtual network has enough capacity for all resources in all of the clusters. To learn more about network strategies for Azure Managed Lustre and AKS, see AKS subnet access.

If you plan to use another resource to host your compute VMs in the same virtual network, check the requirements for that process before creating the virtual network and subnet for your Azure Managed Lustre system. When planning multiple clusters within the same subnet, it's necessary to use an address space large enough to accommodate the total requirements for all clusters.

Subnet access and permissions

By default, no specific changes need to be made to enable Azure Managed Lustre. If your environment includes restricted network or security policies, the following guidance should be considered:

Known limitations

The following known limitations apply to virtual network settings for Azure Managed Lustre file systems:

• Azure Managed Lustre and Azure NetApp Files resources can't share a subnet. If you use the Azure NetApp Files service, you must create your Azure Managed Lustre file system in a separate subnet. The deployment fails if you try to create an Azure Managed Lustre file system in a subnet that currently contains, or has previously contained, Azure NetApp Files resources.
• If you use the ypbind daemon on your clients to maintain Network Information Services (NIS) binding information, you must ensure that ypbind doesn't reserve port 988. You can either manually adjust the ports that ypbind reserves, or ensure that your system startup infrastructure starts your Lustre client mount before starting ypbind.

Blob integration prerequisites (optional)

If you plan to integrate your Azure Managed Lustre file system with Azure Blob Storage, complete the following prerequisites before you create your file system.

To learn more about blob integration, see Use Azure Blob storage with an Azure Managed Lustre file system.

Azure Managed Lustre works with storage accounts that have hierarchical namespace enabled and storage accounts with a non-hierarchical, or flat, namespace. The following minor differences apply:

• For a storage account with hierarchical namespace enabled, Azure Managed Lustre reads POSIX attributes from the blob header.
• For a storage account that does not have hierarchical namespace enabled, Azure Managed Lustre reads POSIX attributes from the blob metadata. A separate, empty file with the same name as your blob container contents is created to hold the metadata. This file is a sibling to the actual data directory in the Azure Managed Lustre file system.

To integrate Azure Blob Storage with your Azure Managed Lustre file system, you must create or configure the following resources before you create the file system:

• Storage account
• Blob containers

Storage account

You must create a storage account or use an existing one. The storage account must have the following settings:

• Account type - A compatible storage account type. To learn more, see Supported storage account types.
• Access roles - Role assignments that permit the Azure Managed Lustre system to modify data. To learn more, see Required access roles.
• Access keys - The storage account must have the storage account key access setting set to Enabled.

Supported storage account types

The following storage account types can be used with Azure Managed Lustre file systems:

For more information about storage account types, see Types of storage accounts.

Access roles for blob integration

Azure Managed Lustre needs authorization to access your storage account. Use Azure role-based access control (Azure RBAC) to give the file system access to your blob storage.

A storage account owner must add these roles before creating the file system:

• Storage Account Contributor
• Storage Blob Data Contributor

To add the roles for the service principal HPC Cache Resource Provider, follow these steps:

1. Navigate your storage account, and select Access control (IAM) in the left navigation pane.
2. Select Add > Add role assignment to open the Add role assignment page.
3. Assign the role.
4. Add HPC Cache Resource Provider to that role.

   Tip

   If you can't find the HPC Cache Resource Provider, search for storagecache instead. storagecache Resource Provider was the service principal name before general availability of the product.

5. Repeat steps 3 and 4 to add each role.

For detailed steps, see Assign Azure roles using the Azure portal.

Blob containers

You must have two separate blob containers in the same storage account, which are used for the following purposes:

• Data container: A blob container in the storage account that contains the files you want to use in the Azure Managed Lustre file system.
• Logging container: A second container for import/export logs in the storage account. You must store the logs in a different container from the data container.

Private endpoints (optional)

If you're using a private endpoint with your blob setup, in order to ensure Azure Managed Lustre can resolve the SA name, you must enable the private endpoint setting Integrate with private DNS Zone during the creation of a new endpoint.

• Integrate with Private DNS zone: Must be set to Yes.

Next steps

• Create an Azure Managed Lustre file system in the Azure portal