This section explains the main functionality of Azure Native Qumulo (ANQ), provides a feature comparison between ANQ and Qumulo on other platforms. In addition, it explains the difference between ANQ Hot and Cold, specifies ANQ's known limitations and compliance posture, gives an overview of deploying the service in Azure, and lists the supported Azure Regions for the service.

What is Azure Native Qumulo?

is a fully managed service that provisions a Qumulo file system and creates a resource (for managing the file system) under your Azure subscription. provides the same multi-protocol support, interfaces, and functionality as Qumulo on premises.

makes it possible to configure file protocols, quotas, replication, and other features regardless of underlying infrastructure or storage and without tracking resource quotas or costs. The service receives the latest updates and features continuously and, if any issues occur, replaces compute and storage resources automatically.

Names and Versions

  • In this guide, we refer to the features and functionality of Qumulo Core as _ ()_ or the service.

  • Following ‘s initial launch, we configured the Qumulo file system in Azure to have significant flexibility and performance improvements. For more information, see Feature Comparison with Qumulo on Other Platforms.

  • Default workloads are called Hot workloads. Workloads that use the Azure Blob Storage Cold Tier are called Cold workloads.

Feature Comparison with Qumulo on Other Platforms

The following table compares the features of with those of Qumulo on other platforms.

Feature Qumulo on AWS as an AMI Qumulo on Premises
Automatic deployment
Automatic infrastructure replacement
Automatic updates
Availability in Cloud Marketplace
Customer support
Integration with Azure Portal
Payment for preprovisioned file system capacity
Payment for used storage space only
Performance scales elastically at any capacity
Performance scales with provisioned capacity
Qumulo Core features
Simple and fast deployment under 15 Minutes

Known Limitations

  • IPv6 Addresses: Currently, Azure Networking features don’t support IPv6 addresses.

  • Initial Authentication over SMB: When you deploy the service initially, all users can use the SMB protocol. However, the admin user can authenticate over all protocols except over SMB.

    To allow the admin user to authenticate over the SMB protocol, change the admin user’s password.

Qumulo Compliance Posture

For information about Qumulo’s third-party attestations, including FIPS 140-2 Level 1, GDPR, HIPAA, and SOC 2 Type II, see Qumulo Trust Center.

Using Cold Workloads

Cold uses Azure Blob Storage Cold Tier and has the same data integrity as Hot, a slightly lower (99% rather than 99.9%) guaranteed availability, and a sustained high performance and read throughput. Cold is designed for workloads in which the majority of the data is written once, read infrequently, and retained for a long time period.

Deploying

This section outlines the process of configuring and deploying .

  1. You specify the following configuration.

  2. When Qumulo creates your instance, it deploys and configures the following Azure resources:

    • Managed Resource Group: This group contains the networking resources that the service deploys.

      When you create your service instance, you can specify an existing resource group or create a new one.

    • Delegated Subnet: The delegated subnet that the service uses to provision endpoints for your virtual network.

      When you create your service instance, you can specify an existing delegated subnet or create a new one..

    • Qumulo Service Resource: The Azure resource that represents one instance of the service.

      You can use this resource to manage and view the service configuration.

    • Marketplace SaaS Resource: The Qumulo Marketplace SaaS resource that you select.

      Azure uses this resource for billing purposes.

Supported Azure Regions

The following table lists the regions that supports. ✱ indicates supported zoneless regions.

Geographical Location Azure Region Hot Cold
US (Arizona) West US 3
US (California) West US ✓✱ ✓✱
US (Illinois) North Central US ✓✱ ✓✱
US (Iowa) Central US
US (Texas) South Central US
US (Virginia) East US
US (Virginia) East US 2
US (Washington) West US 2
Canada (Toronto) Canada Central
Europe (Frankfurt) Germany West Central
Europe (Gävle) Sweden Central
Europe (Ireland) North Europe
Europe (Netherlands) West Europe
Europe (Oslo) Norway East
Europe (Paris) France Central
Europe (Zurich) Switzerland North
UK (London) UK South
Australia (New South Wales) Australia East
Brazil (São Paulo State) Brazil South
India (Pune) Central India
Japan (Tokyo, Saitama) Japan East
Korea (Seoul) Korea Central
UAE (Dubai) UAE North

Usage Billing and Metering for

Once an hour, every deployed Hot and Cold instance reports a metering event to Azure Marketplace.

Billing for Cold Instances

Cold instances:

  • Are billed at a lower rate than Hot instances

  • Include a set amount of used capacity, higher than that of an Hot instance

  • Include a set amount of data that you can retrieve per month

    When you exceed this amount, we charge a per-gigabyte rate for reading data from the instance (regardless of protocol).

  • Have a minimum data retention period of 120 days.

    When you delete data early (before the retention period expires), you incur a short-lived data charge, equal to the remaining duration of the retention period.

Metering Dimensions for Hot and Cold

Both Hot and Cold use the Used Capacity metering dimension. In addition:

  • Metering for Hot instances uses the Used capacity and Used throughput dimensions

  • Metering for Cold instances uses the Data read and Data deleted early dimensions.