Siebel Deployment Planning Guide > Siebel Infrastructure Planning >
Mapping Siebel Deployment Elements to Platforms
This topic is a step in Process of Infrastructure Planning. This infrastructure planning step maps the elements of the Siebel deployment to server platforms. Criteria
Mapping Siebel deployment elements to platforms must meet the following criteria:
- Guarantees adequate performance and scalability under both average and peak workloads
- Meets high-availability and resiliency goals
- Accommodates infrastructure security requirements
Prerequisites
Review the following information, developed in previous steps:
To determine server platform requirements
- Determine the amount of hardware required for Siebel Server components. Consider both average and peak workloads. Also consider background processing workloads.
On two- or four-CPU platforms, customers typically deploy one Application Object Manager (AOM) on each Siebel Server. Deploying AOMs in this manner is a common practice, but not a requirement. Depending on the number of concurrent users, the amount and complexity of customization and the components used, the distribution of components can vary.
For detailed information about calculating the settings for MaxTasks, MaxMTServers, and MinMTServers, see Siebel Performance Tuning Guide.
For additional help with sizing Siebel Servers, contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle's Application Expert Services.
- Identify which Siebel Server components you can collocate. Distribute these across platforms in a way that evenly distributes workload.
When deciding which server components to collocate, observe the following best practices:
- Determine how many additional hardware platforms are needed to comply with high-availability policies.
For clustered servers, define a failover strategy for components (active-active, active-passive).
NOTE: In active-active clustering, a process is only active on one node of the cluster and is not active on the other node; that is, two physical servers are running a different clustered process.
- Identify additional hardware required to comply with security policies. For example, do you need to install additional firewalls or a proxy server? Do you need to install LDAP servers?
- Use average and peak workload information to determine how many Web servers are needed.
- Create a diagram of the Siebel deployment that shows all the platforms and the distribution of Siebel Servers. Use the diagram to do the following:
- Verify that all needed server components are enabled and correctly set up on each platform.
- Run component and platform failure scenarios. Verify that there are no single points of failure that will cause unacceptable impacts.
For example, assume you have one Web server. All your inbound customer orders must go through it and then to one HTTP inbound adapter. If the Web server or the inbound adapter fails, customers cannot place orders.
- Use server naming conventions to identify groups of servers that provide similar functions.
For example, in an enterprise, Application Object Managers (AOMs) run on one group of machines, workflows run on a second group of machines, and remote user synchronization runs on a third group. Give the AOM servers names starting with APP, the workflow servers names starting with WF, and the Siebel Remote servers names starting with REM.
Each group will display together in Server Manager, which simplifies server administration.
NOTE: Additional considerations for server naming are provided in the Siebel Installation Guide for the operating system you are using.
Topology Planning Guidelines
Consider the following guidelines for topology planning:
- A single Siebel Gateway Name Server can manage multiple Siebel Enterprise Servers.
- A Siebel Enterprise Server can belong to one and only one Siebel Gateway Name Server.
- A single Siebel Enterprise Server can manage multiple Siebel Servers.
- A Siebel Server can belong to one and only one Siebel Enterprise Server.
- A Siebel Server can manage multiple instances of a single server component or of multiple server components. Components may include multiple Application Object Manager types, each with its own SRF.
- The Siebel Servers in a Siebel Enterprise Server can connect to only one Siebel Database.
Table 4 describes possible deployment schemes for Siebel Business Applications.
Table 4. Siebel Deployment Schemes
|
|
A single Siebel Gateway Name Server with multiple Siebel Enterprise Servers configured on a single machine or UNIX hardware partition. Each Siebel Enterprise Server has its table owner and Siebel Database. |
No. If the Siebel Gateway Name Server fails, it would adversely affect all the Siebel Enterprise Servers. Failure of one UNIX partition could adversely affect all the Siebel Enterprise Servers. If one Enterprise Server requires an upgrade, all Enterprise Servers are affected. |
Running multiple Siebel Gateway Name Servers on a single unpartitioned machine or on a single UNIX hardware partition. |
No. This scheme is very difficult to set up. It requires manual workarounds. On Windows, it requires manually editing the registry. |
Multiple Siebel Enterprise Servers sharing a DBMS table owner (schema). |
May be suitable for some deployments. There are many possible scenarios for deploying with multiple Enterprise Servers and many issues to consider. For more information, see 477829.1 (Article ID) on My Oracle Support. This document was previously published as Siebel Technical Note 544. |
Multiple Siebel Enterprise Servers, each with their own DBMS table owner and sharing the same instance of the DBMS executable. |
No. If the database server goes down, all of the Siebel Enterprise Servers will go down. Too much dependency on one machine. |
A single Siebel Enterprise Server hosting multiple Siebel Servers within a single hardware partition. |
No. There is no additional scalability, throughput, or performance benefit to this scheme. Managing multiple Siebel Servers within a single hardware partition also requires more Siebel administrator time. |
A Siebel Enterprise Server hosting multiple Siebel Servers, with each Siebel Server on its own machine or UNIX hardware partition (multiple partitions on each UNIX server machine). |
Yes. This scheme is the most common way to deploy Siebel Business Applications. |
A single Siebel Server managing multiple applications, each Application Object Manager type having its own copy of the SRF file. |
Yes. This is a common deployment scheme. It allows you to segment functionality for each process. If multiple SRFs are used for the Object Managers in a Siebel Enterprise Server, the SRF used for common components such as Workflow Process Manager, EAI Object Managers, and so on should have the common objects needed for proper processing. It is critical to have all SRF files in sync. The Siebel Repository in the production DBMS must also be in sync with the SRFs. |
Installing the Siebel Gateway Name Server, each Siebel Server, and the Siebel Database all on different operating systems. |
Yes. This scheme is supported. However, you should try to keep the deployment as simple as possible. In some cases a heterogeneous environment is required. For example, you want to install Siebel Servers running on one operating system, but a third-party product you need only runs on another. For information on supported operating systems for Siebel deployments, see Siebel System Requirements and Supported Platforms on Oracle Technology Network. |
|