Storage Tiers

Configure NVMe, SSD, and HDD storage tiers in NxtSight Block Storage. Map hardware device classes to volume types and set the default tier for your deployment.

Overview

Storage tiering exposes different hardware performance classes as distinct volume types, allowing users to select the appropriate tier for each workload. NxtSight Block Storage supports NVMe, SSD, and HDD tiers within a single distributed storage cluster by mapping CRUSH device classes to dedicated pools and volume types. Configure one volume type per hardware tier and set a default to ensure users without a specific preference land on the most appropriate tier.

Administrator Access Required — This operation requires the admin role. Contact your NxtSight administrator if you do not have sufficient permissions.

Prerequisites

• Distributed storage cluster with at least one device class configured (e.g., nvme, ssd, hdd)
• Pools created for each device class in the storage cluster
• Storage backends registered in Block Storage (one per pool)
• Volume types created for each tier via the Volume Types & QoS guide

---

Tier Performance Reference

Tier	Hardware	IOPS (4K Random)	Throughput	Recommended For
NVMe	PCIe NVMe SSDs	100,000 – 1,000,000	3 – 14 GB/s	Transactional databases, low-latency caches
SSD	SATA/SAS SSDs	10,000 – 100,000	500 MB/s – 2 GB/s	Web application data, instance boot disks
Standard (HDD)	7.2K/10K RPM	150 – 500	100 – 300 MB/s	Archival, bulk storage, infrequent access

---

Configure Tier Mappings

nxtDeploy

1. Open Storage Tiers in nxtDeploy

   Log in to nxtDeploy and navigate to Configuration → Storage → Storage Tiers. nxtDeploy displays the detected hardware device classes from the storage cluster.

2. Configure tier mappings

   For each detected hardware tier, specify:

   Field	Description
   Storage Pool Name	The pool in the distributed storage cluster (e.g., volumes-nvme)
   Volume Type Name	The volume type to expose to users (e.g., nvme)
   QoS Spec	Optional QoS policy to attach to this tier

   Click Save Tier Configuration.

3. Set the default volume type

   In the Default Volume Type field, select the tier to use when users create volumes without specifying a type.

   NxtSight recommends setting ssd as the default for most deployments — you can explicitly request nvme or standard when needed.

   Click Apply.

   Tier mappings saved and default type configured.

CLI

1. Authenticate

   Source your credentials file to authenticate with the NxtSight platform:

   Load credentials

   source openrc.sh
   

   Your administrator provides the RC (credentials) file for your project. See CLI Setup for configuration details.

2. List backend pools and device classes

   List backend pools with capabilities

   openstack volume backend pool list --long
   

   Review volume_backend_name, free_capacity_gb, and total_capacity_gb for each pool to understand available capacity per tier.

3. Create volume types for each tier

   Create NVMe volume type

   openstack volume type create \
     --description "NVMe SSD — high-performance, low-latency" \
     nvme
   openstack volume type set --property volume_backend_name=nvme-backend nvme
   

   Create SSD volume type

   openstack volume type create \
     --description "SSD — balanced performance and cost" \
     ssd
   openstack volume type set --property volume_backend_name=ssd-backend ssd
   

   Create HDD volume type

   openstack volume type create \
     --description "Standard HDD — archival and bulk storage" \
     standard
   openstack volume type set --property volume_backend_name=hdd-backend standard
   
4. Set the default volume type

   Set default volume type

   openstack volume type set --default ssd
   
5. Verify tier configuration

   List all volume types with properties

   openstack volume type list --long
   

   Confirm each type shows the correct volume_backend_name and that one type is marked as default.

   All storage tiers configured and visible to users.

---

Single-Tier Deployments

If your cluster has only one hardware class (e.g., all SSD), configure a single volume type pointing to the existing pool. There is no need to create additional pools or types.

In a single-tier cluster, NxtSight recommends still naming the type explicitly (e.g., ssd) rather than using a generic name — this makes future tier additions easier without requiring users to update their volume creation workflows.

---

Adding a New Tier to an Existing Deployment

When adding new hardware (e.g., NVMe drives to an existing SSD cluster):

1. Add hardware and create a new pool

   Add the new OSDs to the distributed storage cluster with the appropriate device class. Create a dedicated pool using a CRUSH rule that targets only the new device class.

2. Configure a new backend in nxtDeploy

   Add a new backend entry in nxtDeploy pointing to the new pool. Deploy the configuration to register the new backend with the volume service.

3. Create a new volume type

   Create the new tier volume type

   openstack volume type create \
     --description "NVMe PCIe — ultra-low latency" \
     nvme
   openstack volume type set --property volume_backend_name=nvme-pool nvme
   
4. Verify availability

   Test the new tier

   openstack volume create --size 1 --type nvme test-nvme
   openstack volume show test-nvme -c status
   openstack volume delete test-nvme
   

   New tier operational and accessible to users.

---

Automated Storage Tiering

NxtSight-Developed — This capability is developed by NxtSight and ships with nxtVirt / Nxt Cloud Suite.

The NxtSight Resource Optimizer can automatically move volumes between NVMe, SSD, and HDD pools based on observed IOPS activity — eliminating manual tier management for dynamic workloads.

Parameter	Description
Promotion threshold	Sustained high IOPS triggers migration to a faster tier (e.g., HDD to SSD, SSD to NVMe)
Demotion threshold	Sustained low IOPS combined with volume age triggers migration to a cheaper tier
Max retypes per cycle	Limits the number of volume migrations per optimization cycle to prevent thundering-herd effects on the storage cluster

All thresholds are configurable per deployment. The Resource Optimizer evaluates volumes periodically, generates a migration plan, and executes volume retypes through the Block Storage API without downtime to attached instances.

Start with conservative thresholds and monitor the Resource Optimizer audit logs before tightening promotion or demotion criteria. Aggressive thresholds can cause volumes to bounce between tiers repeatedly.

---

Next Steps

Volume Types & QoS

Configure QoS policies to enforce per-tier IOPS and throughput limits

Migration

Move volumes between tiers to rebalance capacity or meet new requirements

Storage Backends

Configure backend drivers for each storage tier

Volume Types (User)

User guide for selecting the right storage tier for a workload