Learn About Deploying Oracle Siebel CRM on Oracle Cloud Infrastructure
If you want to provision Oracle Siebel CRM 19.x and above on Oracle Cloud Infrastructure or migrate Siebel CRM environments from your data center to Oracle Cloud Infrastructure, you can plan a multihost, secure, high-availability topology for development environments and test environments.
Considerations for Deployment on Oracle Cloud Infrastructure
Oracle recommends creating separate subnets for your instances, such as bastion host, database, application, and load balancer instances to ensure that appropriate security requirements can be implemented across the different subnets.
Private or Public Subnets
You can create instances in a private or a public subnet based on whether you want to permit access to the instances from the internet. Instances that you create in a public subnet are assigned a public IP address and you can access these instances from the Internet. You can’t assign a public IP address to instances created in a private subnet. Therefore you can’t access these instances over the internet.
The following image shows a virtual cloud network (VCN) with public and private subnets. The VCN contains two availability domains, and each availability domain contains a public and private subnet. The web servers are placed in the public subnet in this image, so each web server instance has a public IP address attached to it. You can access these Oracle Cloud instances in the public subnet from the internet by enabling communication through the internet gateway (IGW). You’ll have to update the route table to enable traffic to and from the IGW. To permit traffic to the web servers from the internet, you must create load balancers in the public subnet. To access your instances from the internet, you also need to create a bastion host in the public subnet and access the bastion host from the IGW.
The database servers are placed in the private subnet in this image. You can access Oracle Cloud instances in the private subnet from your data centers by connecting through the dynamic routing gateway (DRG). The DRG connects your on-premise networks to your cloud network. To enable communication between the DRG and the customer on-premises equipment, use IPSec VPN or Oracle Cloud Infrastructure FastConnect. You’ll also have to update the route table to enable traffic to and from the DRG.
Description of the illustration public_private_subnets_jde.png
Scenario 1: Deploy All Instances in Private Subnets
Oracle recommends deploying all instances in private subnets for production environments where there are no internet-facing endpoints. This type of deployment is useful when you want to have a hybrid deployment with the cloud as an extension to your existing data centers.
In this deployment, all the instances including application and database servers are deployed in a private subnet. A public IP address can’t be assigned to instances created in a private subnet, so you can’t access these instances over the internet. To access your application servers from your on-premises environment in this configuration, you can:
-
Configure an IPSec VPN tunnel between your data center and Oracle Cloud Infrastructure DRG before provisioning the application servers.
-
Create a bastion host in this configuration, and then access all the servers in private subnet from the bastion host.
Scenario 2: Deploy Instances in Public and Private Subnets
You can deploy a few instances in a public subnet and a few instances in a private subnet. This type of deployment is useful when the deployment includes internet-facing and non-internet facing endpoints.
In this configuration, some application instances are placed in a public subnet, and others are placed in a private subnet. For example, you may have application instances serving internal users and another set of application instances serving external users. In this scenario, place the application instances that serve internal traffic in a private subnet, and place the application servers that serve external traffic in a public subnet. You can also set up a public load balancer on the internet-facing application instances, instead of placing the application servers that serve external traffic in a public subnet. If you place the bastion host in a public subnet, then the bastion host is assigned a public IP address, and you can access it over the internet. You can access your instances in the private subnet through the bastion server.
Scenario 3: Deploy All Instances in Public Subnets
Oracle recommends this deployment for quick demonstrations or for production-grade deployments with no internal endpoints. This deployment is suitable only if you don’t have your own data center, or you can’t access instances over VPN, and you want to access the infrastructure over the internet.
In this deployment, all the instances including the application and database instances are deployed in public subnets.
Every instance in the public subnet has a public IP address attached to it. Although instances with public IP addresses can be accessed over the internet, you can restrict access by using security lists and security rules. For performing administration tasks, Oracle recommends that you place a bastion host in this configuration. In this scenario, you would not open administration ports to the public internet, but rather open the administration ports only to the bastion host and setup security lists and security rules to ensure that the instance can be accessed only from the bastion host.
Anti-Affinity
While creating multiple instances for high availability in an availability domain on Oracle Cloud Infrastructure, the anti-affinity for instances can be achieved by using fault domains.
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain contains three fault domains. Fault domains let you distribute your instances so that they are not on the same physical hardware within a single availability domain. So, a hardware failure or Oracle Compute hardware maintenance that affects one fault domain does not affect instances in other fault domains. By using fault domains, you can protect your instances against unexpected hardware failures and planned outages.
For high availability of databases, you can create 2-node Oracle Real Application Clusters (Oracle RAC) database systems. The two nodes of Oracle RAC are always created in separate fault domains by default. So, the database nodes are neither on the same physical host nor on the same physical rack. This protects the database instances against the underlying physical host and top of the rack switch failures.