Setting up private services access

Cloud Volumes Service uses private services access to create a high-throughput and low-latency data-path connection. You need to perform the following steps once for each project. However, if you are using a shared VPC, you only need to perform these steps on the host project. You can only peer VPCs that use RFC 1918 address ranges as internal addresses.

You need to perform the following steps based on the cloud volume service type (CVS or CVS-Performance) that you deploy for your project. For example, if you deploy a volume that uses the CVS service type, use the commands for the CVS service type to perform the steps. If, later, you deploy a volume that uses the CVS-Performance service type, you need to perform the steps again and use commands for the CVS-Performance service type.

The steps and examples in this section assume that you are deploying a volume of each service type and that you will use a separate VPC for each service type.

If you plan to peer your consumer project with other producer organizations in addition to NetApp, you must use a different IP address allocation for each of those producers. This precaution is necessary because Cloud Volumes Service uses dynamic routes with your consumer project, but Google Cloud does not check whether your dynamic route allocations overlap. Because these routes are not visible to the other participating producers, multiple producers could inadvertently use an allocation from the same range, causing IP collisions and routing issues.

If you plan to use CVS or CVS-Performance volumes from on-premises networks through a VPN or Cloud Interconnect, choose a CIDR range that does not collide with the CIDR ranges used in your on-premises network. Failing to take this precaution can result in IP collisions and routing issues.

1. Create an allocated IP range within your VPC for the Cloud Volumes Service mount points. In the case of a shared VPC, allocate the range from the host project. You must provide an RFC 1918 address block. Ensure that your allocated range is sufficient in size for your present and future growth needs. You cannot modify (that is, expand) an existing range after you establish it and allocate it to a volume.

   The CVS service type sets a /25 CIDR range for each consumer service project. This setup provides sufficient addresses for volumes in a single zone. You need an additional /25 CIDR range for each subsequent zone that you add in a region.

   For example, consider the following CIDR ranges:

   CIDR range	Maximum volumes	Number of supported zones	Example deployment
   /25	100	1	Up to 100 volumes in 1 zone are supported for 1 VPC
   /24	200	Up to 2	Up to 100 volumes per zone, up to 2 zones, for 1 VPC
   /23	400	Up to 4	Up to 100 volumes per zone, up to 4 zones, for 1 VPC

   The following example for the CVS service type assumes that a VPC already exists in the project being used:

   gcloud
       --project=my-cvs-prj compute addresses create netapp-addresses-production-vpc1 \
       --global --purpose=VPC_PEERING --prefix-length=25 --network=production-vpc1 --no-user-output-enabled
   

   The CVS-Performance service type uses a /28 CIDR range per region and consumer service project pair. If you pass a /24 CIDR range, you can deploy up to 16 combinations of a region and consumer service project pair.

   For example, consider the following CIDR ranges:

   CIDR range	Number of region and project pairs supported	Example Region to Project Pairs
   /28	1	Region1:Project1
   /27	2	Region1:Project1 Region2:Project1
   /26	4	Region1:Project1 Region2:Project1 Region3:Project1 Region1:Project2
   /25	8	Region1:Project1 Region2:Project1 Region1:Project2 Region2:Project2 Region1:Project3 Region2:Project3 Region1:Project4 Region2:Project4
   /24	16	Region1:Project1 Region1:Project2 Region1:Project3 Region1:Project4 Region2:Project1 Region2:Project2 Region2:Project3 Region2:Project4 Region3:Project1 Region3:Project2 Region3:Project3 Region3:Project4 Region4:Project1 Region4:Project2 Region4:Project3 Region4:Project4

   The following example for the CVS-Performance service type assumes that a VPC already exists in the project:

   gcloud \
       --project=my-cvs-prj compute addresses create netapp-addresses-production-vpc2 \
       --global \
       --purpose=VPC_PEERING \
       --prefix-length=24 \
       --network=production-vpc2 \
       --no-user-output-enabled
   

2. Create a private service connection to the Cloud Volumes Service endpoint.

   CVS service type example:

   gcloud \
       --project=my-cvs-prj services vpc-peerings connect \
       --service=cloudvolumesgcp-sds-api-network.netapp.com \
       --ranges=netapp-addresses-production-vpc1 \
       --network=production-vpc1
   

   CVS-Performance service type example:

   gcloud \
       --project=my-cvs-prj services vpc-peerings connect \
       --service=cloudvolumesgcp-api-network.netapp.com \
       --ranges=netapp-addresses-production-vpc2 \
       --network=production-vpc2
   

3. Enable custom route propagation:

   CVS service type example:

   gcloud \
       --project=my-cvs-prj compute networks peerings update netapp-sds-nw-customer-peer \
       --network=production-vpc1 \
       --import-custom-routes \
       --export-custom-routes
   

   CVS-Performance service type example:

   gcloud \
       --project=my-cvs-prj compute networks peerings update netapp-cv-nw-customer-peer \
       --network=production-vpc2 \
       --import-custom-routes \
       --export-custom-routes
   

4. Check that the connection is established:

   CVS service type example:

   gcloud \
       --project=my-cvs-prj services vpc-peerings list \
       --network=production-vpc1
   

   CVS-Performance service type example:

   gcloud \
       --project=my-cvs-prj services vpc-peerings list \
       --network=production-vpc2
   

Note: NetApp does not support a multi-consumer VPC architecture currently. This means that a scenario involving multiple consumer VPCs in the same project consuming volumes will not work.

Accessing Cloud Volumes from different regions or external networks

Your project can access a volume of the CVS or CVS-Performance service type from any zone within the region in which a volume is provisioned. Furthermore, if your VPC has enabled global dynamic routing, your project can access a volume from any other Google Cloud regions.

Note: Inter-region traffic adds latency (reduced performance) and cost (inter-region traffic charges).

The routes to CVS or CVS-Performance volumes will only be announced within the VPC. If you want to access the service from an external network, like an on-premises network via VPN or Cloud Interconnect, you need to configure a static route on the on-premises router to the CIDR range that you selected in Step 1 above.

What's next

• Creating and managing NFS volumes
• Creating and managing SMB volumes
• Monitoring cloud volumes
• Creating and managing volume snapshots
• Reverting a volume using a snapshot
• Backing up and restoring a cloud volume
• FAQs about NetApp Cloud Volumes Service for Google Cloud
• Try out other Google Cloud features for yourself. Have a look at our tutorials.