Skip to main content
Cloud Volumes ONTAP
All cloud providers
  • Amazon Web Services
  • Google Cloud
  • Microsoft Azure
  • All cloud providers

Default configuration for Cloud Volumes ONTAP

Contributors netapp-manini netapp-bcammett netapp-driley netapp-rlithman
PDFs

Understanding how Cloud Volumes ONTAP is configured by default can help you set up and administer your systems, especially if you are familiar with ONTAP because the default setup for Cloud Volumes ONTAP is different than ONTAP.

Default setup

  • BlueXP creates one data-serving storage VM when it deploys Cloud Volumes ONTAP. Some configurations support additional storage VMs. Learn more about managing storage VMs.

    Starting with the BlueXP 3.9.5 release, logical space reporting is enabled on the initial storage VM. When space is reported logically, ONTAP reports the volume space such that all the physical space saved by the storage efficiency features are also reported as used. For information about inline storage efficiency features, refer to the knowledge base article KB: What Inline Storage Efficiency features are supported with CVO?

  • BlueXP automatically installs the following ONTAP feature licenses on Cloud Volumes ONTAP:

    • CIFS

    • FlexCache

    • FlexClone

    • iSCSI

    • Multi-tenant Encryption Key Management (MTEKM), starting with Cloud Volumes ONTAP 9.12.1 GA

    • NetApp Volume Encryption (only for bring your own license (BYOL) or registered pay-as-you-go (PAYGO) systems)

    • NFS

    • ONTAP S3

      Starting with Cloud Volumes ONTAP 9.11.0 in AWS

      Starting with Cloud Volumes ONTAP 9.9.1 in Azure

    • SnapMirror

    • SnapRestore

    • SnapVault

  • Several network interfaces are created by default:

    • A cluster management LIF

    • An intercluster LIF

    • An SVM management LIF on HA systems in Azure

    • An SVM management LIF on HA systems in Google Cloud

    • An SVM management LIF on single node systems in AWS

    • A node management LIF

      In Google Cloud, this LIF is combined with the intercluster LIF.

    • An iSCSI data LIF

    • A CIFS and NFS data LIF

      Note LIF failover is disabled by default for Cloud Volumes ONTAP due to cloud provider requirements. Migrating a LIF to a different port breaks the external mapping between IP addresses and network interfaces on the instance, making the LIF inaccessible.

  • Cloud Volumes ONTAP sends configuration backups to the Connector using HTTP.

    The backups are accessible from http://ipaddress/occm/offboxconfig/ where ipaddress is the IP address of the Connector host.

    You can use the backups for reconfiguring your Cloud Volumes ONTAP system. For more information about configuration backups, refer to ONTAP documentation.

  • BlueXP sets a few volume attributes differently than other management tools (ONTAP System Manager or the ONTAP CLI, for example).

    The following table lists the volume attributes that BlueXP sets differently from the defaults:

    Attribute Value set by BlueXP

    Autosize mode

    grow

    Maximum autosize

    1,000 percent

    Note The BlueXP Organization or Account admin can modify this value from the Settings page.

    Security style

    NTFS for CIFS volumes
    UNIX for NFS volumes

    Space guarantee style

    none

    UNIX permissions (NFS only)

    777

    For information about these attributes, refer to ONTAP volume create man page.

Internal disks for system data

In addition to the storage for user data, BlueXP also purchases cloud storage for system data.

AWS

  • Three disks per node for boot, root, and core data:

    • 47 GiB io1 disk for boot data

    • 140 GiB gp3 disk for root data

    • 540 GiB gp2 disk for core data

  • For HA pairs:

    • Two st1 EBS volumes for the mediator instance, one of approximately 8 GiB as root disk, and one of 4 GiB as data disk

    • One 140 GiB gp3 disk in each node to contain a copy of the root data of the other node

      Note In some zones, the available EBS disk type can only be gp2.

  • One EBS snapshot for each boot disk and root disk

    Note Snapshots are created automatically upon reboot.

  • When you enable data encryption in AWS using the Key Management Service (KMS), the boot and root disks for Cloud Volumes ONTAP are encrypted, as well. This includes the boot disk for the mediator instance in an HA pair. The disks are encrypted using the CMK that you select when you create the working environment.

Tip In AWS, NVRAM is on the boot disk.

Azure (single node)

  • Three Premium SSD disks:

    • One 10 GiB disk for boot data

    • One 140 GiB disk for root data

    • One 512 GiB disk for NVRAM

      If the virtual machine that you chose for Cloud Volumes ONTAP supports Ultra SSDs, then the system uses a 32 GiB Ultra SSD for NVRAM, rather than a Premium SSD.

  • One 1024 GiB Standard HDD disk for saving cores

  • One Azure snapshot for each boot disk and root disk

  • Every disk by default in Azure is encrypted at rest.

    If the virtual machine that you chose for Cloud Volumes ONTAP supports Premium SSD v2 Managed Disk as data disks, the system uses a 32 GiB Premium SSD v2 Managed Disk for NVRAM, and another one as the root disk.

Azure (HA pair)

HA pairs with page blob

  • Two 10 GiB Premium SSD disks for the boot volume (one per node)

  • Two 140 GiB Premium Storage page blobs for the root volume (one per node)

  • Two 1024 GiB Standard HDD disks for saving cores (one per node)

  • Two 512 GiB Premium SSD disks for NVRAM (one per node)

  • One Azure snapshot for each boot disk and root disk

    Note Snapshots are created automatically upon reboot.

  • Every disk by default in Azure is encrypted at rest.

HA pairs with shared managed disks in multiple availability zones

  • Two 10 GiB Premium SSD disks for the boot volume (one per node)

  • Two 512 GiB Premium SSD disks for the root volume (one per node)

  • Two 1024 GiB Standard HDD disks for saving cores (one per node)

  • Two 512 GiB Premium SSD disks for NVRAM (one per node)

  • One Azure snapshot for each boot disk and root disk

    Note Snapshots are created automatically upon reboot.

  • Every disk by default in Azure is encrypted at rest.

HA pairs with shared managed disks in single availability zones

  • Two 10 GiB Premium SSD disks for the boot volume (one per node)

  • Two 512 GiB Premium SSD Shared Managed disks for the root volume (one per node)

  • Two 1024 GiB Standard HDD disks for saving cores (one per node)

  • Two 512 GiB Premium SSD Managed disks for NVRAM (one per node)

If your virtual machine supports Premium SSD v2 Managed Disks as data disks, it uses 32 GiB Premium SSD v2 Managed Disks for NVRAM and 512 GiB Premium SSD v2 Shared Managed disks for the root volume.

You can deploy HA pairs in a single single availability zone and use Premium SSD v2 Managed Disks when the following conditions are fulfilled:

Google Cloud (single node)

  • One 10 GiB SSD persistent disk for boot data

  • One 64 GiB SSD persistent disk for root data

  • One 500 GiB SSD persistent disk for NVRAM

  • One 315 GiB Standard persistent disk for saving cores

  • Snapshots for boot and root data

    Note Snapshots are created automatically upon reboot.

  • Boot and root disks are encrypted by default.

Google Cloud (HA pair)

  • Two 10 GiB SSD persistent disks for boot data

  • Four 64 GiB SSD persistent disk for root data

  • Two 500 GiB SSD persistent disk for NVRAM

  • Two 315 GiB Standard persistent disk for saving cores

  • One 10 GiB Standard persistent disk for mediator data

  • One 10 GiB Standard persistent disk for mediator boot data

  • Snapshots for boot and root data

    Note Snapshots are created automatically upon reboot.

  • Boot and root disks are encrypted by default.

Where the disks reside

BlueXP lays out the storage as follows:

  • Boot data resides on a disk attached to the instance or virtual machine.

    This disk, which contains the boot image, is not available to Cloud Volumes ONTAP.

  • Root data, which contains the system configuration and logs, resides in aggr0.

  • The storage virtual machine (SVM) root volume resides in aggr1.

  • Data volumes also reside in aggr1.