Learn About Deploying Siebel CRM on Oracle Cloud Infrastructure

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 subinet. The web servers are placed in the public subnet in this image, so the web server instances have 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 bastion host in 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 is the gateway that connects your on-premises network to your cloud network. To enable communication between the DRG and the customer-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 public_private_subnets_jde_old.png follows

Description of the illustration public_private_subnets_jde_old.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.

Architecture for Deploying Siebel CRM in a Single Availability Domain

You can plan the architecture to deploy Siebel CRM Innovation Pack 2016 in a single availability domain while ensuring high availability. The high availability of an application within an availability domain can be achieved by placing application instances in separate fault domains.

Note:

This specific architecture applies to Siebel CRM Innovation Pack 2016 only. Architectures for IP2019, 2020, and 2021 deployments are described elsewhere in this playbook.

Fault domains let you distribute your instances so that they are not on the same physical hardware within a single availability domain. A hardware failure or Oracle Cloud Infrastructure Compute hardware maintenance that affects one fault domain does not affect instances in other fault domains.

The architecture consists of a virtual cloud network (VCN) with the bastion, load balancer, application, and database hosts placed in separate subnets of the VCN in a single availability domain. The bastion host is deployed in a public subnet, and all the other servers are placed in private subnets. Depending on your business requirements, you can place instances in public or private subnets. You can access the instances that are in private subnets over port 22 through the bastion host or the dynamic routing gateway (DRG). To enable communication between the DRG and the customer-premises equipment, use IPSec VPN or Oracle Cloud Infrastructure FastConnect.

Instances in the private subnet require outbound connection to the Internet to download patches as well as to apply operating system and application updates. For this purpose, use a Network Address Translation (NAT) gateway in your VCN. With a NAT gateway, the hosts in private subnet can initiate connections to the Internet and receive responses, but won’t receive inbound connections initiated from the Internet.

Oracle recommends that the database and the applications deployed on Oracle Cloud Infrastructure should have a robust backup of recovery strategy. It is recommended to store backup of databases and application instances in the Oracle Cloud Infrastructure Object Storage. The databases and application instances in private subnets can be backed up to Oracle Cloud Infrastructure Object Storage by using a service gateway. A service gateway provides access to Oracle Cloud Infrastructure Object Storage without traversing the Internet.

The automatic and on-demand database backups to Oracle Cloud Infrastructure Object Storage can be configured using the Oracle Cloud Infrastructure console. This requires connectivity to Oracle Cloud Infrastructure Object Storage using a Swift endpoint. All database backups on Oracle Cloud Infrastructure Object Storage are encrypted with the same master key used for Transparent Data Encryption (TDE) wallet encryption. The automatic database backup service uses weekly incremental backup strategy to backup databases with a 30-day retention policy. It is also possible to perform an on-demand full backup of databases for ad-hoc requirements.

The backup of application can be configured by using the policy-based backup feature of Oracle Cloud Infrastructure Block Volumes. Oracle Cloud Infrastructure Block Volumes provides you with the capability to perform volume backups automatically based on a schedule and retain them based on the selected backup policy. This allows you to adhere to your data compliance and regulatory requirements. There are three predefined backup policies: Bronze, Silver, and Gold. Each backup policy has a predefined backup frequency and retention period.

Description of single_availability_domain_siebel_crm_deployment.png follows

Description of the illustration single_availability_domain_siebel_crm_deployment.png

This architecture supports the following components:

Bastion host: The bastion host is an optional component that you can use as a jump server to access instances in the private subnet. A bastion host is an Oracle Cloud Infrastructure Compute instance that uses Linux or Windows as its operating system. Place the bastion host in a public subnet and assign it a public IP address to access it from the internet.

To provide an additional level of security, you can set up security lists to access the bastion host only from the public IP address of your on-premises network. You can access Oracle Cloud Infrastructure instances in the private subnet through the bastion host. To do this, enable ssh-agent forwarding, which allows you to connect to the bastion host, and then access the next server by forwarding the credentials from your computer. You can also access the instances in the private subnet by using dynamic SSH tunneling. SSH tunneling is a way to access a web application or other listening service. The dynamic tunnel provides a SOCKS proxy on the local port, but the connections originate from the remote host.
Oracle Cloud Infrastructure Load Balancer hosts: The Oracle Cloud Infrastructure Load Balancing instances receive requests from application users, and then load balance the traffic to Siebel web servers. These load balancer instances receive requests from users, and then route the requests to Siebel web servers.

Use Oracle Cloud Infrastructure Load Balancing to distribute traffic to your application instances within a VCN. This service provides a primary and standby instance of the load balancer to ensure that if the primary load balancer goes down, the standby load balancer forwards the requests. The load balancer ensures that requests are routed to the healthy application instances. If there’s a problem with an application instance, then the load balancer removes that instance and starts routing requests to the remaining healthy application instances.

Based on your requirements, you can place load balancers in a public or private subnet.
- For internal endpoints, that aren’t accessible from the internet, use a private load balancer. A private load balancer has a private IP address, and it isn’t accessible from the internet. Both the primary and the standby instances of a load balancer reside in the same private subnet. You can access private load balancers in the VCN or in your data center over the IPSec VPN through a DRG. The private load balancer accepts traffic from your data center, and distributes the traffic to underlying application instances.
- For internet-facing endpoints, use a public load balancer. A public load balancer has a public IP address, and it’s accessible from the internet. You can access the public load balancers from the internet through the internet gateway.
- For accessing internal endpoints and internet-facing endpoints, set up private load balancers and public load balancers. Set up private load balancers to serve the internal traffic, and set up public load balancers to serve the traffic from the internet.
Register the public or private IP address of Oracle Cloud Infrastructure Load Balancing instances in your on-premises domain name server (DNS) for domain resolution of your application endpoint.
Siebel web server: The Siebel web servers receive requests from the Oracle Cloud Infrastructure Load Balancing instances, and then route these requests to the Siebel application subnet. Siebel web servers include the Siebel native load-balancing module. This module provides round-robin load balancing for routing requests to Siebel servers. You can deploy redundant Siebel web servers to provide high availability within an availability domain. All the web server instances are active. Even if one web server becomes unavailable, the other web server continues processing the requests.

The Siebel web server is an Oracle HTTP server with Siebel Web Server Extension (SWSE) deployed on top of it. The Siebel Web Server Extension is a plug-in that identifies the requests for Siebel application data that come from web clients, and then flags these requests for routing to a Siebel server. When the Siebel server sends information back to the web client, the Siebel Web Server Extension helps complete the composition of the web page for forwarding to the client.
Application subnet: The application subnet contains the following instances of Siebel CRM.
- Siebel Server: Each Siebel server functions as an application server. You can deploy redundant instances of the Siebel server to provide high availability. A logical grouping of one or more Siebel servers that connects to a Siebel database is referred to as Siebel Enterprise server.
- Siebel Gateway Name Server: This server serves as the dynamic address registry for Siebel servers and components. Siebel servers query the Siebel Gateway Name Server address registry for information about the availability and address of Siebel servers. The Siebel Gateway Name Server contains the siebns.dat file which you can back up to Oracle Cloud Infrastructure Object Storage.
- Siebel File System: The Siebel file system is a shared file system directory or set of directories. It is used for sharing binaries across the Siebel servers and Siebel Gateway Name Server. It stores document files, Siebel Product Configurator models, web template definitions, and other files that are not suitable for database storage.
You can use Oracle Cloud Infrastructure Object Storage to back up Siebel servers.
Database hosts: For high availability requirements, Oracle recommends that you use one of the following options to set up Siebel CRM database instances:
- Two-node, Oracle Real Application Clusters (Oracle RAC) database systems on a virtual machine or bare metal.
- Oracle Database Exadata Cloud Service instances. This service provides Oracle Database hosted on Oracle Exadata Database Machine in Oracle Cloud.
Place database systems in a separate subnet. A database service on Oracle Cloud Infrastructure can be created only in a public subnet. You can set up redundant database hosts to provide high availability. For Oracle RAC and Oracle Database Exadata Cloud Service database systems, requests that are received from the application subnet are load balanced across the database servers. If one database instance becomes unavailable, the other database instance processes the requests. You can use Oracle Cloud Infrastructure Object Storage to back up the Siebel CRM database by using Oracle Recovery Manager (RMAN).

Use security lists to restrict access to the database servers only from the bastion host, Siebel servers, and on-premises servers. You can set up security lists to ensure that communication occurs only over port 22, through the bastion host, and over port 1521. Also ensure that the database systems can’t be accessed over the internet.

Architecture for Deploying Siebel 19.x, 20.x, 21.x for Resiliency and High Availability

This architecture shows how to deploy Siebel 19.x, 20.x, 21.x for resiliency and high availability.

At a basic level, you can achieve resiliency and redundancy for your Siebel deployment even within a single availability domain (AD).

Description of res-ha-siebel-19-20-21.png follows
Description of the illustration res-ha-siebel-19-20-21.png

System Resilience (1): Fault domains is a grouping of hardware and infrastructure that is distinct from other fault domains in the same Availability Domain (AD). Each AD has three fault domains. By properly leveraging fault domains you can increase the availability of applications running on Oracle Cloud Infrastructure.
Load Balancer Tier (2): We recommend having load balancers in their own tier or subnet to load balance traffic to Siebel web servers. The load balancer receives requests from users and routes them to the application tier.
Active-Active: Siebel AI Server Redundancy in Application Interface Tier (3) Subnet C: This tier contains redundant instances of the Siebel Application Interface (AI) servers to provide high availability. For server redundancy of the AI servers they should be distributed across the fault domains within the AD. All instances are active and receive traffic from the load balancer and middle tier.
Active-Active: Siebel Server Redundancy in Application Interface Tier (4) Subnet B: This tier contains redundant instances of the Siebel Application servers to provide high availability. For server redundancy of the Siebel servers they should be distributed across the fault domains within the AD. All instances are active.
Redundancy in Database Tier (5): This tier contains database system instances, Subnet A. For performance requirements, Oracle recommends that you use two-node Oracle RAC (available only in DBaaS VMs) or Exadata Cloud Service
Backup Strategy – AI tiers and Siebel Application Server tiers: Backup of the AI and application server tiers can done using snapshot of the Virtual Machine (VM). VM can be restored from these snapshots.
Backup Strategy - Database Tier: Use Object Storage to perform backups using RMAN. To back up/patch the database to Object Storage, the DB system's VCN must be configured with either a service gateway or an Internet Gateway (IGW). We recommend using an IGW for backup and patching.

Architecture for Deploying Siebel 19.x, 20.x, 21.x for High Availability in Single Region Across Multiple Availability Domains

This architecture shows how to deploy Siebel 19.x, 20.x, 21.x for high availability in single region across multiple availability domains (ADs).

Customers interested in deploying in our multiple-availability domain regions (Phoenix, Ashburn, London, Frankfurt), have the option of disaster recovery across ADs within a single region.

Description of hasing-reg-multi-ad-siebel-19-20-21.png follows
Description of the illustration hasing-reg-multi-ad-siebel-19-20-21.png

Regional Subnets across ADs (1): Regional subnets span the entire region providing benefits like protection from AD network failure, simplified Siebel service deployment and management. In this architecture bastion hosts, load balancers, and application tier servers in both ADs are in active state.
Load-balancing across ADs (2): Public Load Balancing distributes traffic across the servers across all configured ADs, providing protection from an AD failure.
Active-Active Siebel AI Server components across ADs (3): By clustering supported services across ADs you can get protection from any unforeseen failure in a single AD.
Active-Active Siebel Server components across ADs (4): By clustering supported services across ADs you can get protection from any unforeseen failure in a single AD. GWY and Siebel File System are shown as Active-Passive across ADs.
Database DR across Availability Domains (5): The use of either Data Guard or Active Data Guard is dependent on your use case and database edition. Active Data Guard requires Enterprise Edition – Extreme Performance.

Architecture for Deploying Siebel 19.x, 20.x, 21.x for Disaster Recovery Across Multiple Regions

This architecture shows how to deploy Siebel 19.x, 20.x, 21.x for disaster recovery (DR) across multiple regions.

You can achieve true DR across multiple regions in the unlikely event that one region goes down.

Note:

This reference architecture covers the most robust case with clustering of supported services across ADs within the primary region, but DR can be achieved across regions with single AD. This is important to note as most of our new OCI regions launching will be single AD regions.

Description of dr-multi-reg-19-20-21.png follows
Description of the illustration dr-multi-reg-19-20-21.png

VCN Peering Across Regions: VCNs can connect between regions with in a tenancy or even between tenancies. Connectivity is achieved using Oracle’s internal backbone between regions. If you have two applications running in two different ADs, VCN peering will allow them to communicate internally.
Active-Active components across ADs: Clustering of supported services across ADs provides protection from an AD failure.
Load-balancing across ADs: Public Load Balancing distributes traffic across the Siebel servers across all configured ADs, providing protection from an AD
Distribute Active-Passive Application Server Components Across Regions: If you are using Active-Passive to synchronize application servers across ADs, use rsync.
Regional subnets across ADs: Regional subnets span the entire region, providing resilience against AD network failure, and simplified Siebel service deployment and management.
Database DR across ADs: The use of either Data Guard or Active Data Guard depends on your use case and database edition. Active Data Guard requires Enterprise Edition – Extreme Performance.
Storage synchronization across ADs: Block volume backups between regions can be done using the console, CLI, SDKs, or REST APIs. Copying block volume backups to another region at regular intervals makes it easier for to rebuild applications and data in the destination region if a region-wide disaster occurs in the source region. You can also easily migrate and expand applications to another region. With Object Storage cross region copy, data asynchronously copies objects between buckets in the same region or to buckets in other regions.

About the Security Lists

In Oracle Cloud Infrastructure, firewall rules are configured through security lists. A separate security list is created for each subnet.

Oracle recommends that you create separate subnets for the database, application, load balancer, and bastion hosts to ensure that the appropriate security list is assigned to the instances in each subnet. Use security lists to permit traffic between different tiers and between the bastion host and external hosts. Security lists contain ingress and egress rules to filter traffic at the subnet level. They also contain information about communication ports through which data transfer is permitted. Those ports (or in some cases, the protocols that will need open ports in the security rules) are shown on each security rule line in the architecture diagrams.

Each security list is enforced at the instance level. However, when you configure your security lists at the subnet level, all instances in a particular subnet are subject to the same set of rules. Each subnet can have multiple security lists associated with it, and each list can have multiple rules. The transfer of a data packet is permitted if a rule in any of the lists allows traffic (or if the traffic is part of an existing connection that’s being tracked). In addition to security lists, use iptables to implement another layer of security at the instance level.

For deployments in a public subnet, you can provide an additional level of security by preventing access to the application and database instances from the internet. Use a custom security list to prevent access to the application and database instances from the internet, and permit access to the database and application hosts over port 22 from the bastion host for administration purposes. Don’t enable SSH access to the application and database instances from the internet, but you can permit SSH access to these instances from the subnet that contains the bastion host.

You can access your instances in the private subnet through the bastion server.

Security List for the Bastion Host

The bastion security list allows the bastion host to be accessible from the public Internet over port 22.

To permit SSH traffic from the on-premises network to the bastion host over Internet:

Stateful ingress: Allow TCP traffic from the source CIDR 0.0.0.0/0 and all source ports to the destination port 22 (SSH).

Source Type = CIDR, Source CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

You can also restrict bastion host to be accessible over the Internet on port 22 only from your data center instead of public Internet (0.0.0.0/0). To achieve this, use your edge router IP instead of the source CIDR as 0.0.0.0/0 in the stateful ingress rule.
To permit SSH traffic from the bastion host to Oracle Cloud Infrastructure Compute instances:

Stateful egress: Allow TCP traffic to the destination CIDR 0.0.0.0/0 from all source ports to the destination port 22 (SSH).

Destination Type = CIDR, Destination CIDR = <CIDR block of VCN>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22

Security List for the Oracle Cloud Infrastructure Load Balancing Instances

The architecture contains private load balancers, which are placed in private subnets. If you place the load balancer instances in a public subnet, then you’re permitting traffic from the Internet (0.0.0.0/0) to the load balancer instances.

To permit traffic from the Internet to the load balancer:

Stateful ingress: Allow TCP traffic from source CIDR (Internet) 0.0.0.0/0 and all source ports to the destination port 80 (HTTP) or 443 (HTTPS).

Source Type = CIDR, Source CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = 80 or 443
To permit traffic from the on-premises network to the load balancer:

Stateful ingress: Allow TCP traffic from the on-premises network CIDR block and all source ports to the destination port 80 (HTTP) or 443 (HTTPS)

Source Type = CIDR, Source CIDR = <CIDR block for onpremises network>, IP Protocol = TCP, Source Port Range = All, Destination port range = 80 or 443
To permit traffic from the load balancer tiers to the application servers:

Stateful egress: Allow TCP traffic to the destination CIDR 0.0.0.0/0 from all source ports to all destination ports.

Destination Type = CIDR, Destination CIDR = <CIDR block for application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = All

Security List for Siebel Web Servers

Create the following security lists to permit traffic from the load balancer instances and bastion server to the Siebel web servers. Traffic received from the load balancer instances is forwarded to the Siebel application servers in the application tier.

To permit traffic from the bastion host to the application tier:

Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22
To permit traffic from the load balancer tier to the application tier:

Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of load balancer subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 80 or 443
To permit traffic from the Siebel web servers to the Siebel servers in the application tier:

Stateful egress: Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = All

Security List for the Application Tier

To permit traffic from the bastion host to the application tier:

Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22
To permit traffic from the Siebel servers to the Siebel Gateway Name Server:

Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of Siebel application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 2320
To permit traffic from the Siebel web servers to the Siebel application servers:

Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of Siebel web subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 2321
To permit egress traffic:

Stateful egress: Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = All

Security List for the Database Tier

To permit traffic from the bastion host to the database tier:

Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of bastion subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 22
To permit traffic from the Siebel application servers to the database tier:

Stateful ingress: Source Type = CIDR, Source CIDR = <CIDR block of siebel application subnet>, IP Protocol = TCP, Source Port Range = All, Destination port range = 1521
To permit egress traffic:

Stateful egress: Destination Type = CIDR, Destination CIDR = 0.0.0.0/0, IP Protocol = TCP, Source Port Range = All, Destination port range = All