Service Subnets on Google Cloud VMware Engine - What you need to know
With Google Cloud VMware Engine, NSX network segments are the standard and recommended method to create new networks for your workloads. These NSX segments add many helpful features such as distributed firewall rules, advanced routing, NAT, and DHCP that are invaluable to meet modern applications’ needs. However, there are certain situations where a traditional VLAN network is desired for the purposes of managing service traffic. So many are asking, what are service subnets, and why would an administrator use them?
What are Service Subnets?
Google introduced Service Subnets to Google Cloud VMware Engine a few months ago by non-disruptively adding them to all new and existing private clouds. As a matter of fact, unless you frequently visited the subnets screen in the Google Cloud VMware Engine console, you likely would have never noticed them being added quietly in the background.
Figure 1: Service Subnets listed in the private cloud’s subnets screen
For each private cloud, there are five service subnets labeled “service-1” through “service-5”, each with its own designated subnet ID. These subnet IDs are just another name for VLAN IDs that can be used to create service networks from within the vSphere client. In essence, service networks are just like any of the other management networks such as vMotion, vSAN, NSX Edge, and HCX uplink networks (as shown above).
Figure 2: Editing a service subnet to provide name and network CIDR
From the subnets screen, an administrator can edit any of the service subnets to provide optional user-defined subnet names and CIDR blocks for routing purposes. Once the service subnet editing is complete, the creation workflow will automatically assign a gateway address if necessary.
From there, it can then be added through the vSphere client just like any other VLAN-backed network as a new distributed port group. (See Figure 3)
Figure 3: Adding the new service subnet as a distributed port group through the vSphere client.
Why would an administrator use service subnets?
From the release notes, Google says, “Service subnets are used for appliance or service deployment scenarios, such as storage, backup, Site Recovery Manager (SRM), disaster recovery (DR), media streaming, and providing high scale linear throughput and packet processing for private clouds at any scale.”
Practically speaking, this means that they are intended to be used for scalability purposes, in other words, for certain edge-case scenarios where an NSX overlay network may not be the best fit. A prime example of when to use a service subnet is for vSphere Replication when using VMware Site Recovery Manager. The SRM best practices recommend using a VLAN-backed network instead of an NSX segment. By attaching the vSphere replication appliance vNICs into the service subnet, not only does it meet the recommendation of isolating the replication traffic, but it also avoids the unnecessary overhead associated with encapsulation and de-encapsulation of the replication packet payload.
When using service subnets there are a couple of things that administrators should keep in mind. First, NSX network segments should be used for most all networking use cases within Google Cloud VMware Engine. Secondly, service subnets reside outside of NSX control, so virtual machines cannot take advantage of NSX services such as distributed firewall rules, DHCP, NAT, etc.
To learn how to create a service subnet-backed network, check out this video:
Conclusion
Service Subnets are an excellent tool in your toolbox to ensure you have powerful networking flexibility, so we hope you found this information helpful in explaining why and when service subnets should be used. For more information and demo videos regarding Google Cloud VMware Engine networking and configuration, check out VMware Cloud Tech Zone.