This is the 3rd blog, (Part 3A) in a series of blogs regarding the ISV Validated Design.
This blog series will contain the following topics
In the last blog entry we reviewed a few different architectures that could help an ISV scale on Oracle Cloud Infrastructure. In this blog entry we will focus on how to implement and setup OCI networking constructs to support the Large Scale design shown below. We will focus on the basics building the networks for the management servers, the virtual routers, the first Customer POD, and two customers (Leaf customer #1, and Leaf customer #2). In a subsequent blog on operational steps I will go into further details on how to add a new POD to an existing set of virtual routers.
To validate this architecture we decided to build the following Virtual Cloud Networks (VCNs), Subnets, and Instances. A picture and table can be found below. In our validation we built a set of linux instances with multiple network cards. We are utilizing a secondary Virtual Network Interface Card (VNIC) attachment to our virtual routers so that each router has access to both networks. In practice you can substitute the Linux instance with an ecosystem partner, or commercial virtual router if your more comfortable with that. The concepts applied in this blog could vary from one vendor to the next, or from one Linux distribution to the next.
Routing is probably the area which is the most complex topic in this design. In summary we have to add routes for networks that aren't locally attached. For example from the ISV's management servers, it should know that to reach Customer #1 that we must traverse the Virtual Router's floating IP address.
In this architecture we traverse the following networks:
1. In the ISV Management and vRouter subnets
2. Virtual routers should have routes for:
3. End Customer Networks must be configured as follows
In this section I show specific examples of the route table entries and security list modifications needed to provide end to end connectivity from the ISV Management servers to the Customer VCNs. Logically there are multiple places in this design that require updating including but not limited to the ISV's VCN network, the Linux virtual routers, the POD networks, and finally the Customer's VCNs as well.
Congratulations, you made it through the basics of building your networks and security lists. Since the Linux hosts are not deployed and configured yet, you can't test end to end connectivity. In our next blog, we will cover the implementation details of how to configure Linux based Virtual Routers.