Learn About the Infrastructure for Hosting Single-Tenant SaaS Applications
Before You Begin
Architecture
This architecture shows the sample network topology for which the solution provides Terraform code. The sample topology supports four tenants. All the components in the topology are in a single region in an Oracle Cloud Infrastructure tenancy.
The SaaS vendor's management infrastructure and the application resources of each tenant are isolated in separate compartments and virtual cloud networks (VCNs). Network isolation ensures that the applications and data are segregated from the other deployments in the tenancy. Compartments ensure logical isolation of the resources and enable granular access control.
This topology contains the following components:
- Management compartment
The management compartment is a logical container for all the ISV-specific resources necessary for the common infrastructure used to manage the individual tenant application deployments. It contains the following resources:
- ISV VCN
The resources required for the SaaS ISV to access and manage its tenants are attached to the ISV VCN.
- Bastion
The bastion server is a compute instance in a public subnet in the ISV VCN. The traffic between the internet and the bastion server is routed through an internet gateway.
The ISV's administrative users can access all the resources in the tenancy, including the private addresses of the resources in the tenant compartments, through the bastion host. The administrative users of the ISV can also access the private resources in the tenancy by using an IPSec VPN tunnel or an Oracle Cloud Infrastructure FastConnect circuit.
- Management server
The management server is a compute instance in a private subnet. It is attached to a private subnet in the ISV VCN. The management server can communicate with the servers in the tenant compartments through the routing gateways.
You can use the management server to install and run an infrastructure monitoring application, such as Nagios Core.
- ISV VCN
- Peering compartment
For private communication between the resources in the ISV VCN and the tenant resources, a local peering relationship is necessary between the ISV VCN and each tenant VCN. But a VCN can have up to only 10 local peering relationships. To overcome this scaling limitation, the architecture uses routing gateways that can connect to multiple peering VCNs. Each peering VCN can have a local peering relationship with up to 10 tenant VCNs. So you can scale up the topology by adding routing gateways and peering VCNs in the peering compartment.
- Peering subnet
The peering subnet is a part of the ISV VCN. All the routing gateways are attached to this subnet.
- Routing gateways and peering VCNs
Each routing gateway is an Oracle Linux compute instance that routes traffic from the management server to the tenant VCNs, through a peering VCN.
To demonstrate high availability (HA) of the routing gateway, an active-passive pair of compute instances with a floating IP address is used for one of the routing gateways. Pacemaker and Corosync are installed to ensure automatic failover. The second routing gateway is a single (non-HA) instance.
The primary VNIC of each routing gateway instance is attached to the peering subnet in the ISV VCN.
The routing gateway instances use theVM.Standard.2.2
shape, which supports one secondary VNIC. The secondary VNIC of each routing gateway instance is attached to a subnet of a peering VCN. Each peering VCN can be connected to a maximum of 10 tenant VCNs. In the sample topology, each peering VCN is connected to two tenant VCNs.-
By using larger shapes for the routing gateway instances, you can extend the topology to support more peering VCNs. For example, if you use the
VM.Standard.2.4
shape for a routing gateway instance, then you can attach up to three secondary VNICs to the instance and connect the routing gateway to a maximum of three peering VCNs. So the routing gateway can support a maximum of 30 tenant VCNs. Remember that the available network bandwidth of the routing gateway instance is shared by all its VNICs. -
The network bandwidth between each tenant VCN and the ISV VCN depends on the compute shape that you select for the routing gateway. The available network bandwidth is shared across all the VNICs of the gateway instance. For example, if you select the
VM.Standard2.4
shape for the routing gateway instance, then the maximum available bandwidth is 4.1 Gbps, which is shared by the primary VNIC and up to three secondary VNICs. Consider this factor when you decide the shape of the gateway instance and the number of peering VCNs that you want each gateway to serve.
-
- Peering subnet
- Tenant compartments
The resources for each of the four tenants in this topology are in a separate compartment. Each tenant compartment contains a VCN to which all the resources for that tenant are attached. So the resources for each tenant use a unique address space in a network that's isolated from all the other tenants in the topology.
In each tenant compartment, a compute instance is created. You can use this instance to install and run an infrastructure monitoring agent. For example, if you install Nagios Core in the management server in the ISV VCN, then you can install the Nagios agent in the compute instance in each tenant compartment. The agent can monitor the servers in the compartment and send metrics to the Nagios monitoring server.
When you add new application tenants, the necessary resources for the new tenant are provisioned in a new compartment.
Tenants can access their application over the public internet or through a private connection (IPSec VPN or FastConnect). For access from the public internet, each tenant VCN requires an internet gateway. For access using VPN or FastConnect, a DRG is necessary. The architecture diagram doesn't show the internet gateways and the DRGs for the tenant VCNs.
About Required Services and Policies
This solution requires the following services and access-management policies:
Service | Policies Required To... |
---|---|
Oracle Cloud Infrastructure Identity and Access Management | Create and manage compartments. |
Oracle Cloud Infrastructure Networking | Create and manage VCNs, subnets, internet gateways, route tables, security lists, LPGs, and DRGs |
Oracle Cloud Infrastructure Compute | Create and manage compute instances. |
See Learn how to get Oracle Cloud services for Oracle Solutions to get the cloud services you need.