Google Cloud Virtual Private Clouds (VPCs) are a powerful software-defined network. They are easy to create, scalable, and allow global connectivity across all Google Cloud regions. Although Google projects provide excellent workload isolation, connecting their VPCs together for data sharing can be challenging due to nontransitive routing between peered VPCs. Google's Network Connectivity Center (NCC) was built to address such challenges. Google Cloud NetApp Volumes can now interoperate with NCC for storage pools and volumes of the Flex service level.
What is Network Connectivity Center?
NCC is an orchestration framework that simplifies network connectivity among spoke resources that are connected to a central management resource called a hub. Multiple types of spokes are supported; regular VPCs are the most common. When a hub uses VPC spokes, you can configure connectivity between these VPC networks connected to the hub by exchanging subnet routes between all or some of the VPC networks.
NCC also supports hybrid spokes like virtual private network (VPN) tunnels, Cloud Interconnect VLAN attachments, and router virtual machines (VMs). When a hub uses both VPC spokes and hybrid spokes, any-to-any connectivity is supported across all of the spokes.
For architectural diagrams, see the NCC introduction blog article.
How service-level Flex interoperates with NCC
Google Cloud NetApp Volumes leverages Private Service Access (PSA) to connect the service to a single Virtual Private Cloud specified while creating a storage pool. This connection initiates VPC peering between your VPC and a dedicated tenant project VPC within NetApp Volumes. Consequently, virtual machines within your VPC gain access to volumes provided by NetApp Volumes using the NFS or SMB protocol.
The complexity starts as soon as users want to access the volumes from a third network. Typical scenario in which this happens is hub and spoke network topologies (Figure 1).
Figure 1) Hub and spoke network.
Because the hub and spoke use VPC peering and the spoke connecting to NetApp Volumes also uses VPC peering, the architecture has two consecutive VPC peering hops. In this case, nontransitive routing blocks the hub exchanging traffic with NetApp Volumes (the red icons), causing the following issues:
- VMs in the hub VPC cannot talk to volume A, B, C, or D.
- VMs in spoke1 can talk to volumes A and B, but not C and D.
- VMs in spoke2 can talk to volumes C and D, but not A and B.
- If volume A or B is an SMB volume, it needs to connect to Active Directory domain controllers (DCs). If a DC is in spoke VPC1, everything is fine. If no DC is in spoke1, but is in the hub, spoke2, or on premises, the volume is not created.
Network administrators can work around such issues by replacing VPC peering with alternative ways to connect networks, like using VPNs, router VMs, or interconnects, where transitive routing can be configured.
With Network Connectivity Center, such workarounds are not required. Storage pools of service level Flex can be connected to an NCC hub as VPC producer spokes, creating connectivity to all the other spokes (for example, VPC networks) that are connected to the same hub.
Figure 2 shows a similar topology using NCC.
Figure 2) Star topology with NCC.
The left side of the figure shows the user project (customer VPC) that on-boarded NetApp Volumes. Their VPCs are still connected using PSA. A network administrator added NetApp Volumes as a VPC producer spoke to an NCC hub. The admin also added customer VPC and other VPC spokes to the NCC hub to form a star topology, as shown by the solid black lines. NCC creates direct VPC peerings between all the spokes, as shown by the dotted blue lines. The result:
- Customer VPC can communicate with the NetApp Volumes producer VPC by using PSA peering.
- Spokes VPC1 and VPC2 and the routing VPC can communicate with the NetApp producer VPC through the direct VPC peerings created by NCC.
Data can flow freely.
Billing
NCC offers a lot of additional networking flexibility, but it doesn’t come without cost. There are charges per spoke per hour and for data leaving any spoke. To translate this cost into the world of NetApp Volumes, refer to Figure 2.
- Data flowing between NetApp producer VPC and consumer VPC still uses the PSA connection and is free.
- Data being written from spoke VPC1 to NetApp producer VPC is leaving spoke VPC1, meaning that the traffic charges are billed to the project that owns spoke VPC1. The same logic applies for spoke VPC2.
- Data being read by spoke VPC1 or VPC2 from NetApp Volumes is leaving the NetApp producer VPC. The traffic egress charges are billed to the project that owns the customer VPC.
File shares are for data sharing
Adding NetApp Volumes Flex as a VPC producer spoke to Network Connectivity Center enables easier data sharing between isolated networks in Google Cloud. This addition simplifies a lot of use cases where you want to share the same volumes between otherwise isolated projects or networks. A typical example is a transport share between isolated SAP production, development, and QA projects. Or a central data repository. Or a place to put log files. Or data for machine learning. The uses are manifold.
The integration of NetApp Volumes as VPC producer spoke is now available as a preview for service-level Flex-based volumes. To learn more, contact a NetApp Google Cloud specialist.
