Deployment Planning Guide > Siebel Infrastructure Planning >

Mapping Siebel Deployment Elements to Platforms

This infrastructure planning step maps the elements of the Siebel deployment to server platforms.


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

Review the following information, developed in previous steps:

This topic is a step in Process of Infrastructure Planning.

To determine server platform requirements

  1. 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. This 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. Customers should contact Siebel Expert Services for information on how to size Siebel Servers. Additional information on calculating the settings for MaxTasks, MaxMTServers and MinMTServers is discussed in detail in the Performance Tuning Guide.

  2. 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:

    • Install the document server on a dedicated server. The document server uses Microsoft Word to create documents. Since Word is a single-threaded process, the document server could block other processes running on the same server.
    • Consider what time of day a component will be used. For example, a typical scenario is to run EIM batch jobs during off-peak hours. This means EIM can be collocated with a server that is busy during peak hours. You can collocate components running off-peak with on-peak components for server consolidation purposes.
    • Collocation architecture decisions are driven by the load placed on each component and the overall size of the deployment. Consider the following scenario. An implementation plan involves having 1,000 connected users with light Assignment Manager usage, light Workflow usage, heavy off-peak EIM batch jobs, and a moderate Communication Server load. The implementation also requires some degree of high-availability and resiliency. One possible architecture solution would be as follows:
      • Clustered Gateway. Collocated Siebel File System, Assignment Manager, Workflow Monitor Agent and Communications Server.
      • Multiple, load-balanced Siebel AOMs. The number of servers required depends on the level of configuration and scripting complexity.
    • Engage Siebel Expert Services to perform an architecture and sizing review early in the implementation process. Once key metrics are known (user count, data volume, transaction volume, interfaces, and so on), you can determine the architecture and size the system.
    • Some components are complex to size (for example, Configurator) and require expertise to determine an appropriate architecture and distribution of components. It is always necessary to have a thorough understanding of the product model design and how the product model will be used.
    • It is common practice in a large implementation (with thousands of users) to dedicate a server (usually a set of servers) to one function. This makes it easier to monitor the performance of each segment of the implementation and makes it easier to scale each subset of the architecture. In a large implementation, AOMs, Workflow, EAI, Assignment Manager and Configurator would all run on dedicated servers. The Siebel Gateway Name Server and the Web servers would also run on dedicated hardware.
    • For larger implementations, consider running Siebel Reports Server (Actuate) on dedicated hardware. Generating reports can cause peaks in usage distribution and cause CPU spikes. If the Siebel Reports Server is isolated from other servers, CPU spikes will not affect the end-user experience.
    • When there are more than a relatively small number of remote users (100 or so), run Siebel Remote on a dedicated server. Planning considerations should include the total number of remote users, the expected data volume transferred between the enterprise database and the remote client, and the quantity of visibility events. Visibility events include adding or removing a position to an account team, adding or removing a user to a position, and so on. When a visibility event occurs, it can cause a great deal of Siebel Remote activity. Once again, it is important to identify those processes with the potential for spikes of resource consumption and spread the load accordingly.
  3. 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 Siebel terms, active-active clustering means 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.

  4. 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?
  5. Use average and peak workload information to determine how many Web servers are needed.
  6. 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:
    1. Verify that all needed server components are enabled and correctly set up on each platform.
    2. Run component and platform failure scenarios. Verify that there are no single points of failure that will cause unacceptable impacts.

      For example, 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.

  7. 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 on a second group of machines, and remote user synchronization 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. This simplifies server administration.

Topology Planning Guidelines

Use 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. This includes multiple Application Object Manager types, each with their own SRF.

Table 5 lists recommended deployment schemes.

Table 5. Deployment Schemes
Deployment Scheme

A single Siebel Gateway Name Server and multiple Siebel Enterprise Servers running on a single machine or UNIX hardware partition. Each Siebel Enterprise Server has its tableowner and database server.

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 UNIX hardware partition or on a single unpartitioned machine.

No. Very difficult to set up. It requires manual workarounds, and requires manually editing registry on Windows platforms.

Multiple Siebel Enterprise Servers sharing a DBMS tableowner.

No. Each Siebel Enterprise Server is required to have its own set of tables.

Multiple Siebel Enterprise Servers, each with their own DBMS tableowner and sharing the same instance of the DBMS executable.

No. If the one Database Server goes down, all of the Siebel Enterprise Servers will go down. Too much dependency on one machine.

A Siebel Enterprise Server hosting multiple Siebel Servers within a single hardware partition.

No. There is no additional scalability, throughput, or performance benefit to this configuration. 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 is the most common way to deploy Siebel version 6.x and later.

A single Siebel Server managing multiple applications. Each Application Object Manager type having its own copy of the SRF.

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 SRFs 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 database all on different operating systems.

Yes. This is supported for Siebel 7.x. 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 System Requirements and Supported Platforms on Siebel SupportWeb.

Deployment Planning Guide