ONTAP is NetApp’s storage operating system, and it is known for an industry-leading feature set. Storage efficiency is one of those features. Deduplication, compression, and compaction reduce the physical capacity required to store your logical data. Compaction fills physical blocks that would otherwise stay only partly used. How much capacity you save depends on the data you write. Two volumes of the same logical size can consume very different amounts of disk.
Google Cloud NetApp Volumes removes that calculation. It charges for logical capacity. You provision the logical size of the data, and that provisioned size is what you are billed for. You do not need to work out the difference between logical and physical capacity, or how that difference changes with the contents of the volume.
A migration from an ONTAP system to NetApp Volumes also includes protocol settings, network addresses, and client cutover. Use Volume migration for that workflow. This post covers capacity sizing only: how large to make each destination volume and the storage pool, and how to size the hot tier when you add auto-tiering.
The same sizing applies to any ONTAP source you administer with the ONTAP CLI. That includes hardware platforms such as FAS and AFF, and software platforms such as Cloud Volumes ONTAP. Storage-efficiency savings on the source do not reduce the logical capacity you provision, or the capacity you are billed for. Size every destination volume from the logical used capacity of its source volume, with enough empty capacity for changes during and after migration.
Size volumes and the pool from logical used
On the source cluster, list logical used for each volume you will migrate:
volume show -fields vserver,volume,logical-used
logical-used is the physical space in use plus the space saved by storage efficiency. Create a volume migration requires the destination volume to hold that logical size. For how ONTAP reports it, see Logical space reporting.
Do not make the destination volume exactly as large as the current logical-used value. Users continue to change data while the baseline and incremental transfers run. If the logical data outgrows the destination, SnapMirror can stall because it cannot transfer the additional changes. A volume with no empty capacity also has no room for normal growth after cutover.
Size each destination volume so that the current logical data occupies no more than 80 percent of it:
destination volume capacity = logical-used ÷ 0.8
Build the capacity list from that output:
- Record the SVM, the volume name, and
logical-used for each source volume. - Convert the displayed size to gibibytes (GiB). ONTAP reports KB, MB, GB, and TB in 1024-based units. A value of
2.50TB is 2560 GiB. - Divide the logical used GiB by
0.8, then round up to the next whole GiB. For example, 2560 ÷ 0.8 = 3200 GiB. The resulting volume has 640 GiB, or 20 percent, empty when the current data arrives. - Repeat the measurement shortly before you create the migration. If
logical-used has increased, recalculate the destination capacity. - Add the provisioned destination volume capacities. The storage pool must be at least that sum; do not sum only the source
logical-used values. The pool therefore contains the headroom allocated to its volumes. The pool must also meet the minimum for its type. See Service levels.
A source FlexGroup needs a large-capacity Flex Unified pool and a large-capacity destination volume. Create a volume migration states that requirement.
Create a Flex Unified pool in default mode at the pool capacity from step 5. LOCATION is the zone for a zonal pool. For a regional pool, LOCATION is the region, and you also set --zone and --replica-zone. Throughput and IOPS are required on Flex Unified and are outside this sizing procedure. See Create a storage pool.
gcloud netapp storage-pools create POOL_NAME \
--project=PROJECT_ID \
--location=LOCATION \
--capacity=POOL_CAPACITY_GIB \
--service-level=Flex \
--type=UNIFIED \
--mode=DEFAULT \
--network=name=NETWORK_NAME \
--total-throughput=THROUGHPUT_MIBPS \
--total-iops=IOPS
Create each destination volume at the capacity from step 3, including the 20 percent empty capacity, then continue with Create a volume migration. When the pool uses auto-tiering, create each volume with the command in the next section.
Add auto-tiering
Auto-tiering keeps active data on a hot tier and moves cold data to a cheaper tier. On Flex Unified you choose the hot-tier size, and you cannot decrease it later. A migration that lands in the hot tier can fill it. With auto-increase left on, a full hot tier grows by 10 percent, up to the pool size, and that growth is permanent. See Manage auto-tiering.
A volume with tamperproof snapshots cannot migrate to a volume that uses auto-tiering.
Record the hot working set on the source
Before cutover, while the workload is still on the source system, record the performance-tier footprint of each volume. In volume show-footprint, bin0 is that footprint. See volume show-footprint.
volume show-footprint -fields vserver,volume,volume-blocks-footprint-bin0
Sum volume-blocks-footprint-bin0 for the volumes that will share the NetApp Volumes pool. Convert the sum to GiB and round up. Keep that number. It is the hot-tier size you apply after the migration. Run this command on the source cluster.
Create the pool with a frozen hot tier
Use the same pool capacity as in the previous section. Set the initial hot tier to 20 percent of that capacity, rounded up to the next whole GiB. The minimum hot tier is 1 TiB (1024 GiB). If 20 percent is below 1024 GiB, use 1024 GiB. The hot tier cannot be larger than the pool. If the logical capacity sum is too small to hold a 1024 GiB hot tier, increase the pool capacity until it can.
Turn hot-tier auto-increase off for the migration. The initial hot tier is a floor: NetApp Volumes cannot shrink it if the bin0 sum is smaller.
gcloud netapp storage-pools create POOL_NAME \
--project=PROJECT_ID \
--location=LOCATION \
--capacity=POOL_CAPACITY_GIB \
--service-level=Flex \
--type=UNIFIED \
--mode=DEFAULT \
--network=name=NETWORK_NAME \
--total-throughput=THROUGHPUT_MIBPS \
--total-iops=IOPS \
--allow-auto-tiering=true \
--hot-tier-size=HOT_TIER_SIZE_GIB \
--enable-hot-tier-auto-resize=false
HOT_TIER_SIZE_GIB is the 20 percent size, or 1024, whichever is larger, and it is still within the pool capacity.
Create each migration with hot-tier bypass
Create each destination volume at the calculated capacity from the first section, including the 20 percent empty capacity. Enable auto-tiering and hot-tier bypass so SnapMirror writes go to the cold tier during the transfer. The example uses the default cooling threshold of 31 days. The allowed range is 2 to 183 days.
gcloud beta netapp volumes create VOLUME_NAME \
--project=PROJECT_ID \
--location=LOCATION \
--storage-pool=POOL_NAME \
--capacity=CAPACITY_GIB \
--protocols=nfsv3 \
--share-name=SHARE_NAME \
--hybrid-replication-parameters=peer-cluster-name=SOURCE_CLUSTER,peer-ip-addresses=IC_LIF_1#IC_LIF_2,peer-svm-name=SOURCE_SVM,peer-volume-name=SOURCE_VOLUME,replication=REPLICATION_NAME \
--tiering-policy=tier-action=ENABLED,cooling-threshold-days=31,enable-hot-tier-bypass-mode=on
Set these capacity and tiering fields from the worksheet:
CAPACITY_GIB is the source volume’s logical used size divided by 0.8 and rounded up to whole GiB.tier-action=ENABLED turns auto-tiering on for the volume.enable-hot-tier-bypass-mode=on sends the SnapMirror transfer to the cold tier.
The other flags identify the project, the pool, the share, and the source ONTAP system. enable-hot-tier-bypass-mode is a gcloud beta flag. Peering, protocol settings, and client cutover stay in Create a volume migration and Manage your volume migrations.
Set the hot tier after the migration
Finish the migration with the procedure in Manage your volume migrations. Then set the hot tier in this order.
- Compare the bin0 sum you recorded on the source with
HOT_TIER_SIZE_GIB. If the bin0 sum is larger, raise the hot tier to that sum. If the bin0 sum is smaller, leave the hot tier at the size you set during creation.
gcloud beta netapp storage-pools update POOL_NAME \
--project=PROJECT_ID \
--location=LOCATION \
--hot-tier-size=BIN0_SUM_GIB
- Disable hot-tier bypass on every migrated volume. Repeat the cooling threshold you set at creation. This example keeps 31 days. New writes then go to the hot tier. Data written during bypass returns to the hot tier on the first random read.
gcloud beta netapp volumes update VOLUME_NAME \
--project=PROJECT_ID \
--location=LOCATION \
--tiering-policy=tier-action=ENABLED,cooling-threshold-days=31,enable-hot-tier-bypass-mode=off
- Enable hot-tier auto-increase. When the hot tier is full, NetApp Volumes increases it by 10 percent, up to the pool capacity.
gcloud beta netapp storage-pools update POOL_NAME \
--project=PROJECT_ID \
--location=LOCATION \
--enable-hot-tier-auto-resize=true
Keep bypass on until the transfer is finished, and keep auto-increase off until the hot tier matches the source working set. After that, the hot tier holds the working set you measured, and auto-increase covers later growth.
