Lustre on Azure

Deploy a Lustre 2.17 filesystem into your own Azure subscription: an active-active HA pair, one MDT and two OSTs, with each OST on an OpenZFS pool backed by Azure Blob Storage. Any standard Lustre client mounts it.

Azure Marketplace

Lustre is joining the MayaNAS cluster solutions offer on the Azure Marketplace. Until that plan is available, deploy the Community Edition from GitHub as described here. It is the same filesystem and the same HA design.

Before you start

• Terraform 1.0 or later, git, and the Azure CLI signed in (az login)
• An SSH key
• A resource group and region to deploy into
• Quota for two VMs of the size you choose (see Performance tiers)

Deploy

git clone https://github.com/zettalane-systems/open-lustre-cloud.git
cd open-lustre-cloud
./deploy-lustre.sh --cloud azure -g my-resource-group -l westus -n lustre \
    -k ~/.ssh/id_rsa

The script writes the Terraform variables, applies the storage module, waits for the cluster to come up and prints the mount command, for example:

sudo mount -t lustre <MGS_NID>:/zettafs /mnt/lustre

That deploys storage only. Add --deploy-client to also build a test client, install the Lustre client and verify the mount end to end.

What gets deployed

2 storage nodes	an active-active HA pair with floating VIPs and sub-60 s failover, each serving one OST from its own OpenZFS pool
MGS + MDT	on a dedicated disk (ldiskfs)
Azure Blob Storage	the pools’ data devices. You pay for what you store.
1 client	optional, with --deploy-client

Everything lands in your subscription and your VNet. There is no call-home and no vendor-run infrastructure.

Mount from your own client

Any Linux host that can reach the MGS VIP can mount the filesystem. Install the client with the helper in the repo, which prefers a prebuilt kernel module over a DKMS build:

sudo bash install-lustre-client.sh
sudo mkdir -p /mnt/lustre
sudo mount -t lustre <MGS_NID>:/zettafs /mnt/lustre
lfs df -h /mnt/lustre

Packages are also available from Whamcloud if you prefer to install by hand.

Client placement on Azure

The client must be in the same VNet, and its subnet must have the storage route table (mayanas-route-table) associated. The VIPs sit inside the VNet but outside every subnet CIDR, so without that association they are unreachable. The deploy associates the route table with the storage subnet only: a client there works as is, and a client in another subnet needs the association added. A client that cannot reach the VIP hangs on mount rather than failing cleanly.

Performance tiers

--tier sets the machine size and bucket count. The client gets the same size as the storage nodes, because Lustre bandwidth is network-bound at both ends.

Tier	Azure VM	Buckets per node
basic	Standard_D8s_v5	2
standard (default)	Standard_D16s_v5	4
performance	Standard_D32s_v5	8
ultra	Standard_D64s_v5	12

-m and --client-machine-type override the sizes individually.

Tear down

./deploy-lustre.sh --cloud azure -g my-resource-group -l westus -n lustre --destroy

Pass the same -n you deployed with. This removes every resource the deployment created, including the storage containers and their contents. Deployment state lives in the terraform/ directory of your clone, so keep it until the cluster is destroyed.

Pricing

The Community Edition is free: no subscription, no per-TB charge and nothing metered. You pay Azure for the VMs, managed disks, Blob Storage and network traffic the deployment uses. -s, --spot lowers the compute cost for evaluation, but an eviction fails the pair over mid-run, so do not measure throughput on spot VMs.

See the open-lustre-cloud README for the full option list and Kubernetes clients.