How to Set Up OCI Tenancy for PeopleSoft Cloud Manager – Part II

In the previous blog on setting up tenancy, you learned that a Virtual Cloud Network (VCN) and subnets must be created as a prerequisite for PeopleSoft Cloud Manager Image 6. In Oracle Cloud Infrastructure (OCI), you get the flexibility to configure networking to mimic your on premises environment.  Networking can be configured in many ways for PeopleSoft environments.  You can have separate subnets for demo, development, testing, pre-production and production environments.  You can also group environments into two subnets, one for production and another for non-production environments.  Alternatively, you can create one subnet each for database, middle tier components (Application Server, Process Scheduler, and PIA), PeopleSoft Client, Elasticsearch instances and load balancer.  Another option is to create only three subnets, one for load balancer, the second for database and the third for rest of the instance types.  Subnets can either be public or private.  You can choose to deploy all instances on a private subnet to secure them from the Internet, or put them on a public network where they are accessible from the Internet, or put a few on private and a few on public subnets.  Complete flexibility!

In this blog, let’s take an example of a simple networking architecture. This example network has one VCN with one public subnet and one private subnet.  The public subnet (red dotted line in the illustration below) hosts the Cloud Manager, File Server, middle tier, PeopleSoft (Windows) Clients and Elasticsearch instances.  Database instances are hosted in a private subnet. 

 

First step, create a VCN using OCI web console by selecting Networking, Virtual Cloud Networks. Let’s call it MyVCN

Note. To locate the commands mentioned here, click the Navigation Menu at the top left of the OCI console home page.

You can choose to create the default subnets by selecting the option Create Virtual Cloud Network plus related resources or select Create Virtual Cloud Network only to create your own customized subnets.  Let’s select the latter option for the purpose of this blog. In the example below, a VCN is created with a CIDR 10.0.0.0/16.  You can use a CIDR that mimics your on premises networking too. Read more on VCN and subnet here to familiarize with the concepts and management of networks.

The next important part is creating security lists.  By default every subnet will have a security list.  You can customize the same default security list or create your own.  In the sample network illustrated above, there are two security lists – one for a database subnet and another for the middle tier subnet. The security list for the database subnet can have rules as shown below.  The first rule indicates that the database instance can be accessed over the Internet on port 22 for SSH, and the second rule indicates that all network connections arising from the middle tier subnet (10.0.1.0) must be allowed to connect to all ports on instances running on database subnet.

Now, let’s take a look at the middle tier subnet security list. Here is the summary of the rules:

  • Rule 1 – allow all connections to port 22 (SSH access)
  • Rule 2 – allow all connections to port range 8000 – 8200 (HTTP PIA access)
  • Rule 3 – allow all connections to port range 8443 – 8643 (HTTPS PIA access)
  • Rule 4 – allow all connections between instances within middle tier subnet
  • Rule 5 – allow all connections to port 3389 (RDP to Windows Client)

Also add Egress rules for each subnet as per your requirement.  The example shown below allows connections to all destinations.

Define an internet gateway as shown below.  Also add any route tables if required. More details are available in OCI documentation here.

It is important to ensure that the Cloud Manager and the file server instance has access all subnets on which it will provision environments.  The NFS share in the file server on which DPKs are stored, is mounted on the instances being provisioned and hence all NFS ports must be opened in the security lists. More details about the VCN, subnets and security lists specific to Cloud Manager is available here.

All security rules in this blog are not very restrictive and serve as examples to start with.  It is always recommended to restrict access to subnets by adding more rules that allow only required ports.  To learn more about securing access refer to OCI documentation here.

Next, create subnets for each Availability Domain.  In the example below, there are two subnets created for an Availability Domain evQs US-ASHBURN-AD-1.  One subnet is used for hosting database instances and another to host the remainder of the instances, such as middle tier (running Application Server, PIA server and Process Scheduler), Windows client and Elasticsearch.  Create similar subnets on each of the availability domains.  This way, you’ll have a uniform network layout on each of the availability domains.  Ensure that you select the right security list for each subnet.

With this, the tenancy is ready for you to set up PeopleSoft Cloud Manager.  You have set up a compartment, user, policies, VCN, subnets and security lists.  Learn more about installing Cloud Manager here and how to use it here.

How to Set Up OCI Tenancy for PeopleSoft Cloud Manager – Part II

In the previous blog on setting up tenancy, you learned that a Virtual Cloud Network (VCN) and subnets must be created as a prerequisite for PeopleSoft Cloud Manager Image 6. In Oracle Cloud Infrastructure (OCI), you get the flexibility to configure networking to mimic your on premises environment.  Networking can be configured in many ways for PeopleSoft environments.  You can have separate subnets for demo, development, testing, pre-production and production environments.  You can also group environments into two subnets, one for production and another for non-production environments.  Alternatively, you can create one subnet each for database, middle tier components (Application Server, Process Scheduler, and PIA), PeopleSoft Client, Elasticsearch instances and load balancer.  Another option is to create only three subnets, one for load balancer, the second for database and the third for rest of the instance types.  Subnets can either be public or private.  You can choose to deploy all instances on a private subnet to secure them from the Internet, or put them on a public network where they are accessible from the Internet, or put a few on private and a few on public subnets.  Complete flexibility!

In this blog, let’s take an example of a simple networking architecture. This example network has one VCN with one public subnet and one private subnet.  The public subnet (red dotted line in the illustration below) hosts the Cloud Manager, File Server, middle tier, PeopleSoft (Windows) Clients and Elasticsearch instances.  Database instances are hosted in a private subnet. 

 

First step, create a VCN using OCI web console by selecting Networking, Virtual Cloud Networks. Let’s call it MyVCN

Note. To locate the commands mentioned here, click the Navigation Menu at the top left of the OCI console home page.

You can choose to create the default subnets by selecting the option Create Virtual Cloud Network plus related resources or select Create Virtual Cloud Network only to create your own customized subnets.  Let’s select the latter option for the purpose of this blog. In the example below, a VCN is created with a CIDR 10.0.0.0/16.  You can use a CIDR that mimics your on premises networking too. Read more on VCN and subnet here to familiarize with the concepts and management of networks.

The next important part is creating security lists.  By default every subnet will have a security list.  You can customize the same default security list or create your own.  In the sample network illustrated above, there are two security lists – one for a database subnet and another for the middle tier subnet. The security list for the database subnet can have rules as shown below.  The first rule indicates that the database instance can be accessed over the Internet on port 22 for SSH, and the second rule indicates that all network connections arising from the middle tier subnet (10.0.1.0) must be allowed to connect to all ports on instances running on database subnet.

Now, let’s take a look at the middle tier subnet security list. Here is the summary of the rules:

  • Rule 1 – allow all connections to port 22 (SSH access)
  • Rule 2 – allow all connections to port range 8000 – 8200 (HTTP PIA access)
  • Rule 3 – allow all connections to port range 8443 – 8643 (HTTPS PIA access)
  • Rule 4 – allow all connections between instances within middle tier subnet
  • Rule 5 – allow all connections to port 3389 (RDP to Windows Client)

Also add Egress rules for each subnet as per your requirement.  The example shown below allows connections to all destinations.

Define an internet gateway as shown below.  Also add any route tables if required. More details are available in OCI documentation here.

It is important to ensure that the Cloud Manager and the file server instance has access all subnets on which it will provision environments.  The NFS share in the file server on which DPKs are stored, is mounted on the instances being provisioned and hence all NFS ports must be opened in the security lists. More details about the VCN, subnets and security lists specific to Cloud Manager is available here.

All security rules in this blog are not very restrictive and serve as examples to start with.  It is always recommended to restrict access to subnets by adding more rules that allow only required ports.  To learn more about securing access refer to OCI documentation here.

Next, create subnets for each Availability Domain.  In the example below, there are two subnets created for an Availability Domain evQs US-ASHBURN-AD-1.  One subnet is used for hosting database instances and another to host the remainder of the instances, such as middle tier (running Application Server, PIA server and Process Scheduler), Windows client and Elasticsearch.  Create similar subnets on each of the availability domains.  This way, you’ll have a uniform network layout on each of the availability domains.  Ensure that you select the right security list for each subnet.

With this, the tenancy is ready for you to set up PeopleSoft Cloud Manager.  You have set up a compartment, user, policies, VCN, subnets and security lists.  Learn more about installing Cloud Manager here and how to use it here.