Virtual Private Network
Just like a project is needed for creating any GCP resource, you need a VPC (Virtual Private Network) before you can create any other resource for our SAP setup. Network is not only the first technical resource you should focus on after creating a new project, it’s also the one that you will have most trouble to change later on.
TIP: What might sound surprising, network throughput scales for each Virtual Machine scale with it’s CPUs. Each vCPU has a 2 Gbps egress cap for peak performance, up to a theoretical maximum of 16 Gbps
If you’re serious about entering Google Cloud Platform, you should follow the best practices for creating network resources as explained in this guide. You should identify all the decision makers and decide together with them about the scale, security, reliability, availability, cost considerations etc. Based on those, you should make informed technical decisions for the initial layout that can be later adjusted to meet your growing demands. But let’s keep stay the basics for the needs of this article.
TIP: Bear in mind that some network-related decisions cannot be changed at a later point in time without recreating dependent resources. Be sure to make it right at the beginning!
VPC is a logical concept that utilizes a tiny part of Google’s global fiber network underneath. Because VPCs are global, you will probably need just one of them for the basic setup of a single SAP system, even if you decide to go multi-continent (for cold/warm DR scenario for example). I would encourage you to delete a default VPC network at the very beginning and create a custom one. In case of multiple SAP systems, you might want to go with more projects and – because of this – more networks (each project needs at least one VPC). But let’s focus on a single one for the scope of this article.
TIP: if you’re operating in an environment with regulated data and need to follow standards like HIPAA or PCI-DSS, you should consider putting your sensitive resources in separate VPC networks for isolation.
What’s surprising for those that come from physical network area, you have way more freedom with GCP with respect to networking. First of all, VPCs have no address space at all – it’s all just a logical representation of a small piece of GCP global network that you’ll utilize. This concept is known as software-defined networking (SDN) and is utilized across GCP Networking area.
Subnetworks
If you follow my advice to get rid of default VPC and create a custom one, you’ll have no subnetworks at the beginning. In contrary to VPCs, subnetworks are not global; instead, they are regional resources, limited to the scope of a set of zones that form each region. Although you might just get away with one subnetwork in one region only, I would encourage you to create at least three of them, all in the same region (it’s choice depends on many factors, for example distance from end users, restrictions of data location, VM types available etc). Due to security reasons, you might want to logically separate HANA, ABAP and “all the rest”, meaning: mostly management instances, Bastion Hosts etc. That’s a good practice that should be followed from the very beginning.
Address spaces come into play with subnetworks: you need to assign a specific CIDR range for each subnet, but again – you’re free to choose the address space freely, without limitations that physical networks imply. What’s interesting, you may have a single subnet with a CIDR range that can be used to provision VMs in different zones (= different data centers). With adequate planning, you’ll have a distributed SAP system with physically separated application servers in different zones, all utilizing the same subnet and – thus – CIDR range. Simple and effective!
TIP: you should think about IP address ranges from day 1 in Google Cloud Platform. It’s very flexible and you’re basically free to choose whatever ranges you’d like (without many constraints that physical networks have), but if you end up with an address range overlapping with those on site, you’ll have to resolve it before connecting both networks.
Once subnets with CIDR ranges are ready, you can think about specific IP addresses that you’ll use when creating Virtual Machines. Each of them needs at least one address, which is called an internal IP. It has to fit into subnet CIDR range, but apart from that, there are no other constraints. For ABAP and HANA hosts that will be enough, but VMs in management network (from example: Bastion Host) will also need an external IP so that they can be accessed from the Internet.
TIP: Don’t be surprised that you will not see external IP from OS level. It’s transparently mapped to an internal IP of a VM.
TIP: Both internal and external IPs are ephemeral by default, but you can easily reserve static IPs for them. I would recommend to do this for external IPs used inside management subnet. For ABAP and HANA machines, you can utilize ephemeral internal IPs (at least for basic scenarios) as the hosts will communicate by names anyways.
If you need additional internal IPs to be attached to a VM (to use it exclusively for backups for example), you can utilize so-called secondary CIDR ranges, which are out of this articles’ scope.
TIP: Keep in mind that GCP will reserve 2 first and 2 last addresses for administrative purposes (Default Gateway, broadcasting etc) from each CIDR range that you assign for a subnet. Take it into account when defining ranges for your needs. If needed, you will be able to extend the subnet range later on (provided that it will not cause addresses to overlap).
Routes
Network Routes are the next element of the puzzle. Default rules are maintained by Google and there is nothing to modify here in a classic SAP scenario. Google ensures that all VMs in a single VPC can communicate between each other using internal IPs (using instance routing tables and a virtual router in each VPC) and that is exactly what you typically need. If a packet needs to be sent outside of a VPC, there is a default route to the Internet that will be used in such a case.
Firewall Rules
Sole existence of network routes does not mean that you will be have the connectivity needed. Firewall Rules are the next important element that needs to be set up accordingly. They basically protect your instances from unapproved connections and define connectivity rules that are allowed. The scope of each Firewall Rule is whole VPC network, but it can be limited (by tags or CIDR ranges) to specific subnets or VMs.
TIP: usage of Firewall Rules is explained here. Usually, ingress rules are enough for SAP setup.
TIP: As IP addresses are ephemeral by default, it’s definitely not a good idea to assign Firewall Rules to single IP addresses as you might loose connectivity when some IPs get renewed by DHCP. Instead, define Firewall Rules using network tags or CIDR ranges of whole subnets.
With a fresh custom network, you need to create all Firewall Rules by yourself, otherwise you will not be able to access any of your new VMs. As for the management subnetwork, it will probably need some communication to and from the outside world. After all, you will need to access the internal resources somehow, SAP Router needs to contact SAP etc. More closed approach would be suitable for HANA and ABAP subnetworks though.
TIP: When you’ve established connection between VPC and on-premise networks, you might choose to access hosts in management network (Bastion Host etc) from on-premise only. In such a scenario, you theoretically don’t need VMs with external IPs at all.
It’s a good practice to restrict access to HANA machines by allowing communication from specific ports and ABAP hosts only (as in the screenshot above). The same it true about ABAP hosts: it’s usually enough to allow communication to selected ports from a machine (or a CIDR range) where your SAP Logon is installed. There needs to be communication between SAP application servers of course, plus you might want to allow traffic from other integrated systems, some of which may be located on-premise.
ABAP ports like 36<instance_number> and 39<instance_number> are examples of ports that should be opened for VMs tagged as ‘abap’, to allow ingress (= incoming) connectivity from locations, where the system will be reached.
NAT
Finally, as with most of environments, you’ll probably like to patch your SAP servers from time to time. Google takes care of everything below operating system, but starting from that, it’s your responsibility. The issue here is the fact that your SAP servers have no public IP addresses, so they can’t fetch OS patches just like that. To deal with that, you can utilize so called NAT (Network Address Translation) servers. Google allows you to designate one of the servers (most probably from maintenance subnetwork, you may choose one that’s already used for other purposes, for example SAP Router or Bastion Host) to act as a NAT Gateway. Then you need to reroute the traffic like described in this example. Alternatively, you might just go with managed Cloud NAT solution, but bear in mind there are some additional costs involved (per hour + egress costs).
Controlling access to VPC Networks
IAM is the keyword in this area. In short, Identify and Access Management is a way of identifying who can do what on which resource.
IAM is a topic for a different article, but it’s worth mentioning there are some network-specific IAM roles that should be granted to groups or individuals managing networking resources.
TIP: If you’re only planning to do a simple SAP installation for sandboxing puproses, you can skip most of IAM concepts: as a project creator, you have all the required privileges for managing GCP resources within the projects you create.
Advanced Networking Concepts
If you’ve implemented all of the network resources mentioned above, you should be ready with a basic networking setup needed for SAP. This is where advanced, optional networking concepts come into play. Depending on your needs, you will choose different methods of joining VPC with your corporate network. For starters, Cloud VPN is probably the best option to start with. It can be later extended by a chosen Interconnect method. No matter what you choose, you will end up with a local visibility (based on private IP addresses) between Google’s and your own network.
TIP: Don’t forget about securing Interconnect connections as the traffic is unencrypted in this option.
TIP: When choosing Interconnect option, you need to be mindful about the physical location of your on-premise network infrastructure, throughput you require and responsibility of each party (Google or your ISP) for the service SLA.
To confuse you just a little bit more, there is a functionality called VPC Network Peering, which is a totally different concept than direct or carrier peering shown on the picture above (these ones dealt with a topic of merging on-premise and VPC networks). Network Peering on the other hand comes into play when you already have two different Google VPC Networks (with the same or in different projects) and you would like them to see each other using internal IPs. It’s often used when you separate different applications (eg. different SAP systems or SAP and third-party systems) that need to communicate with each other. In such a case, you can peer those networks together, allowing for a safe, internal (within Google’s global network) communication.
TIP: All subnets, IP ranges and internal forwarding rules are accessible between peered VPC networks, but each of them maintains it’s own distributed firewall.
If you’re really serious about it, you may incorporate a concept of a shared VPC, which is a way to centralize management of networking resources inside GCP by giving all the control to a single project and – usually – single team able to manage it. In such a scenario, there is one host project for all the networking purposes and a bunch of service projects (for different SAP systems / landscapes), utilizing those those network components. This is a more advanced method of provisioning network resources that should be considered when dealing with multiple SAP and organizations that practice a “separation of duties” concept in networking area.
I hope you enjoyed today’s topic. Networking in GCP is much simpler to understand than with physical setup, yet it’s a really powerful concept that let’s you make a distributed / highly available SAP layout and plan for Disaster Recovery scenarios with ease!
If you’re new here, do not forget to subscribe to my newsletter!