Unified Lustre Overview

Unified Lustre combines a Lustre 2.17 parallel filesystem with multi-protocol NAS access (NFS, SMB, S3, SFTP) on the same OpenZFS storage pool and active-active HA cluster. Lustre lives on its own dataset for HPC parallel I/O; NFS, SMB, S3, and SFTP serve from other datasets in the same pool. One cluster, one HA mechanism, one set of data services - serving both HPC and traditional file workloads.

What’s Unified

Layer	Shared between Lustre OST and NAS protocols
Bulk storage engine	OpenZFS - same pool, same dataset abstraction (OST and NAS)
Backend	Google Cloud Storage via objbacker.io
HA mechanism	One HeartBeat cluster, floating VIPs, sub-60-second failover
Data services	ZFS snapshots, replication, end-to-end checksums, compression
Infrastructure	Two VMs, one set of NVMe disks, one set of GCS buckets
Management	One `mayacli`, one Web UI, one set of credentials

What differs: clients use different protocols (Lustre vs NFS vs SMB vs S3 vs SFTP), each accessing its own dataset.

Note: the Lustre MDT (metadata target) is a separate ldiskfs filesystem on local NVMe SSD - that is Lustre’s standard MDT format. OSTs and NAS datasets live in the OpenZFS pool on each node.

Key Features

Lustre 2.17 parallel filesystem with standard client kernel modules for high-throughput HPC parallel I/O
Multi-protocol NAS alongside Lustre - NFS v3/v4, SMB 3.1.1 with native Windows ACLs, S3-compatible API, and SFTP - each on its own dataset in the same pool
Active-active HA - one HeartBeat cluster orchestrates Lustre targets and NAS protocols together; sub-60-second failover with zero client evictions
Two-tier architecture - MDT on local NVMe SSD (ldiskfs, Lustre-standard); OSTs and NAS datasets on Google Cloud Storage via OpenZFS
OpenZFS data services - snapshots, replication, end-to-end checksums, and compression apply to both Lustre and NAS datasets
Object-storage economics - bulk data on GCS at standard rates, no per-TB markup
Standard Lustre client - any client supported by Whamcloud for Lustre 2.17 servers, no proprietary drivers

Architecture

Each storage node hosts:

Primary node - MDT on local NVMe SSD, an OST, and NAS server daemons (nfsd, smbd, S3 gateway, sshd)
Secondary node - an OST and NAS server daemons (same set, served via floating VIPs)

Within each node’s OpenZFS pool, datasets serve different protocols:

A Lustre OST dataset, accessed via Lustre client mount
NFS share datasets, accessed via standard NFS mount
SMB share datasets, accessed via SMB mount with native Windows ACLs
S3 bucket datasets, accessed via the S3-compatible API
SFTP datasets, accessed via SSH/SFTP

All datasets share the same pool’s NVMe metadata tier and the same GCS bulk data tier.

The mayacli show lustre command summarizes Lustre filesystem state from any node:

Name      Status      MGS NID                Size      Used      Targets
--------- ----------- ---------------------- --------- --------- -------
zettafs   HEALTHY     10.100.198.21@tcp      23.3T     12.0M     MDT0000,OST0000,OST0001

The MGS NID is a floating VIP - clients use it for both initial mount and failover.

Performance

Validated on a 2-node cluster (c3d-standard-90 pair, 100 Gbps Tier_1 networking) against a 400 GB dataset cold from GCS:

Workload	Throughput
Write (1 MB sequential, 20 jobs, stripe across both OSTs)	7.0 GB/s
Read (buffered, 1 MB sequential, 20 jobs)	9.7 GB/s
Read (O_DIRECT libaio iodepth=32)	9.8 GB/s
MLPerf ResNet-50 sustained I/O (48 H100 @ 90.7% accelerator utilization)	8.3 GB/s

Lustre outperforms NFS on writes (+19%) due to client-side stripe fan-out across both OSTs. Reads match NFS within 6%. MLPerf v2.0 validates 48 H100 GPU accelerators served at 90.7% AU from one cluster.

NAS protocols on the same cluster share the OpenZFS substrate’s performance characteristics. Mixed workloads (Lustre + NFS concurrent) divide bandwidth across protocols.

When to use Unified Lustre

Mixed HPC and traditional file workloads - HPC team needs Lustre parallel I/O; same project also needs NFS shares for results and SMB shares for analysts. One cluster serves both.
AI/ML training pipelines - Lustre dataset feeds training data to GPUs; NFS or SMB for checkpoints and model artifacts; S3 for result publication
HPC clusters with downstream non-HPC consumers - Lustre for compute; NFS for results sharing
Media production - Lustre for render farms (Linux); SMB for artist workstations (Windows); same project, same cluster
Scientific computing - Lustre for primary analysis; NFS or SMB for collaborator access; S3 for archive
Genomics pipelines - Lustre for compute-heavy steps; NFS for downstream tools
Cost consolidation - one HA cluster covers both HPC and traditional file storage; no separate Lustre vs NAS infrastructure

For multi-protocol file/object access without a Lustre filesystem, see MayaNAS Overview. For NVMe-oF block storage, see MayaScale Overview.