Transition to NetApp Volumes

Last reviewed 2024-04-25 UTC

You can transition your Cloud Volumes Service CVS-Performance service type project resources to Google Cloud NetApp Volumes with no interruption in service to your clients using the Google Cloud console. Network traffic suspends while the connection switches and volumes can't be managed until the switch completes. The transition service creates new storage pools for your volume and shifts all of the following configuration types to NetApp Volumes:

  • Volumes

  • Volume snapshots

  • Active Directory connections

  • Volume replications

  • Customer-managed encryption key (CMEK)

Some configurations, such as Identity and Access Management permissions, scripts, and Cloud Monitoring, can't transition to NetApp Volumes. Instead, we recommend creating new configurations for NetApp Volumes.

Before you begin

Review the following requirements and considerations before you begin.

Requirements

  • Access to NetApp Volumes: you need access to NetApp Volumes before starting the transition process. To set up access, follow the NetApp Volumes configuration steps from Select or create a Google Cloud project up to Set up Identity and Access Management permissions.

    When setting up Virtual Private Cloud peering, you must use the same Compute Engine address range you used for peering the CVS-Performance service type. If you used multiple ranges for Cloud Volumes Service, you must use all of the same ranges for NetApp Volumes.

    Use the following Google Cloud CLI commands to find the names for the ranges:

    1. Find all Virtual Private Cloud peered to the CVS-Performance service type:

      gcloud --project PROJECT_NAME compute networks list /
--filter="peerings[].name=netapp-cv-nw-customer-peer" /
--format="table(name, peerings.name)"

      Replace the following information:

      • PROJECT_NAME: the name of your project.

    2. For each identified Virtual Private Cloud, list the peering ranges:

      gcloud --project PROJECT_NAME services vpc-peerings list /
--network=vpc /
--service cloudvolumesgcp-api-network.netapp.com /
--format="value(reservedPeeringRanges)"

      Replace the following information:

      • PROJECT_NAME: the name of your project.

      • VPC: enter vpc.

      Make sure to peer all Virtual Private Cloud used for the CVS-Performance service type in case you peered more than one network.

  • Naming resources must follow Google Cloud resource naming format: if required, you must change Cloud Volumes Service resource names to follow the Google Cloud resource naming format. The names must also be unique in order to transition to NetApp Volumes. If a name isn't unique and doesn't follow the resource naming format, NetApp Volumes automatically renames the resource during the transition to a name that follows both requirements. You can rename your resources in Cloud Volumes Service before you transition. Once your resources are in NetApp Volumes, you can't change or rename them.

  • All projects within a Shared VPC must be reviewed before transitioning: if your projects use a Shared VPC, you must review each project, host, and any associated service projects, to identify resource naming issues or any other known issues. After all issues are resolved, use the host project for a final review and to launch the transition of all projects in the Shared VPC. Cloud Volumes Service needs to be enabled with the Service Networking API and the NetApp Volumes API on the host project, even if it has no CVS resources.

Considerations

  • Service type: only the CVS-Performance service type can transfer from Cloud Volumes Service to NetApp Volumes.

  • Change in access to resources during transition: project administrators can't view or change resources during the transition, which takes 15 minutes or longer for complex configurations.

  • No disruption to clients: the network change takes only a few seconds. It appears as a pause in network traffic to clients and servers but falls within file protocol timeout windows, so no error is reported.

    Ongoing client read and write operations aren't impacted, network addresses, your Virtual Private Cloud, and client mount points don't change, and data doesn't move.

  • Customer-encryption key settings transition to NetApp Volumes: Customer-managed encryption key (CMEK) settings transition to NetApp Volumes, but these settings require additional service account changes.

  • Review projects using volume replication: when projects use volume replication, the review checks the resources and replication status of the region you select. You must review the other region in the region pair to check its resources. You must resolve all issues in both regions before you can transition the project. After you resolve the issues, you can start the transition from either region, and the two regions transition together.

  • Multiple regions must be reviewed and transitioned separately: if you use other regions, each region must be reviewed and transitioned separately. This includes host projects in all regions which use a Shared VPC even if they have no Cloud Volumes Service resources.

  • Identity and Access Management roles and permissions: Identity and Access Management permissions for NetApp Volumes have new names, but are largely the same as those of Cloud Volumes Service. You can also use the roles/netappvolumes.admin and roles/netappvolumes.viewer roles to simplify configuration. The basic roles for editor and owner include roles/netappvolumes.admin permissions.

  • Metrics for monitoring and alerting for Cloud Volumes Service and NetApp Volumes: metrics available for monitoring NetApp Volumes are generally the same as Cloud Volumes Service. If you've configured alerts or have created a dashboard for Cloud Volumes Service, you need to recreate these for NetApp Volumes. Your existing Cloud Volumes Service metrics data remains available.

  • Cloud Logging and Cloud Billing is offered for NetApp Volumes: NetApp Volumes offers more detailed Cloud Logging entries, including administrative user identity. Cloud Billing uses new SKUs. Your existing Cloud Volumes Service logging and billing entries remain.

  • NetApp Volumes supports the use of labels: NetApp Volumes resources, such as volumes, support up to 64 labels for reporting and querying purposes. If you have defined a single label for your Cloud Volumes Service volumes, it transitions to NetApp Volumes. Migrated resources list the is_migrated:true label.

  • Custom scripts: Cloud Volumes Service offers a RESTful API to create and manage your volumes. NetApp Volumes offers Google Cloud CLI commands and an API service that you can use similarly to create and manage volumes. There is no conversion between them, but if you need assistance, contact your sales team to learn more about services to help with conversion.

  • Terraform support: a NetApp Volumes Terraform provider is available. After you transition to NetApp Volumes, your Cloud Volumes Service Terraform *.tf and state files are no longer valid. To address this, delete them and import the transitioned NetApp Volumes resources to continue managing them.

  • NetApp Volumes supports the Standard service level: the Standard service level is available with NetApp Volumes, but there are differences in behavior. Replication for Standard service level volumes is limited to only between other Standard service level volumes. Volumes in a Standard service level pool can't be reassigned to a Premium or Extreme service level pool.