Understand the Oracle Siebel CRM Architecture on Oracle Cloud Infrastructure

You can plan the architecture to deploy Oracle Siebel CRM across multiple availability domains to ensure high availability. High availability of an application within an availability domain can be achieved by placing application instances in separate fault domains.

Architecture for Deploying Siebel 19.x and above for High Availability in Single Region Across Multiple Availability Domains

This architecture shows how to deploy Siebel 19.x and above 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 the illustration hasing-reg-multi-ad-siebel-19-20-21.png

ha-sing-reg-multi-ad-siebel-19-20-21.zip

• 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 and above for Disaster Recovery Across Multiple Regions

This architecture shows how to deploy Siebel 19.x and above 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 the illustration dr-multi-reg-19-20-21.png

dr-multi-reg-19-20-21.zip

• 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 Network Security Groups

In Oracle Cloud Infrastructure, firewall rules are configured through network security groups. A separate network security group is created for each tier.

Use security lists to permit traffic between different tiers and between the bastion host and external hosts. Security rules contain ingress and egress rules to filter traffic at the tier 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 network security group line in the architecture diagrams.

Each network security group is enforced at the VNIC level. 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 network security group, 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 network security group 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