Siebel Deployment Planning Guide > Siebel Infrastructure Planning >

Mapping Siebel CRM Deployment Elements to Platforms

This task is a step in Process of Infrastructure Planning.

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

Criteria

Mapping Siebel CRM 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

Requirements

Review the following information, developed in previous tasks:

• Database requirements. See Determining Database Requirements.
• Required Siebel Server components. See Mapping Business Requirements to Siebel Server Components.
• High availability policies. See Defining High Availability Policies.

Determining Server Platform Requirements

Perform the following steps to determine your server platform requirements, for topology 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 on each Siebel Server. Deploying Application Object Managers 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 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.

2. Identify which Siebel Server components you can collocate. Distribute these across platforms in a way that evenly distributes workload.

   Recommendations for collocating server components are provided later in this topic.

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 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. For information about high availability options, see Defining High Availability Policies.

4. Identify additional hardware required to comply with security policies. For example, do you have to install additional firewalls or a proxy server? Do you have to install LDAP servers?
5. Use average and peak workload information to determine how many instances of Siebel Application Interface are needed.
6. Create a diagram of the Siebel CRM deployment that shows all of the platforms and the distribution of Siebel Servers. Use the diagram to do the following:
   1. Verify that all of the 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 can cause unacceptable impacts.

      For example, assume that you have one Siebel Application Interface. All of your inbound customer orders must go through it and then to one HTTP inbound adapter. If the Siebel Application Interface or the inbound adapter fails, then 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 run on one group of computers, workflows on a second group of computers, and remote user synchronization on a third group. Give the Application Object Manager servers names starting with APP, the workflow servers names starting with WF, and the Siebel Remote servers names starting with REM.

   The servers in each group are displayed 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 or Siebel Gateway cluster can manage a single Siebel Enterprise Server Siebel Enterprise Servers.
• A Siebel Enterprise Server can belong to one and only one Siebel Gateway.
• 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 can include multiple Application Object Manager types, each with its own Siebel runtime repository.
• The Siebel Servers in a Siebel Enterprise Server can connect to only one Siebel database.

Table 5 describes possible deployment schemes for Siebel CRM applications.

Recommendations for Collocating Server Components

When deciding which server components to collocate, consider the following recommendations:

• You use the Siebel Enterprise Server installer to install all of the server modules for your Siebel CRM applications deployment. However, for various reasons, installing certain modules together as part of the same installation is either prevented or strongly recommended against in the current release. For more information, see the Siebel Installation Guide for the operating system you are using.

  The restrictions or recommendations for collocating modules stem from the use of application containers, which are shared when modules are installed together. If the application container is shut down or restarts, then this affects all modules sharing the application container, severely limiting availability and reliability for these modules. However, you can install modules on the same computer or operating system instance if you install them in different directories.

  • You cannot install Siebel Application Interface with any other module. You install Siebel Application Interface in the DMZ, while you install all the other modules in your intranet. (The DMZ or demilitarized zone is located behind an external firewall but outside of an internal firewall.)
  • You cannot install Siebel Gateway with either Siebel Enterprise Cache or Siebel Constraint Engine.

    Siebel Enterprise Cache and Siebel Constraint Engine are optional modules used in an Oracle Constraint Technology integration for Siebel Product Configurator. This integration is in developer preview status. For more information, see Siebel Product Configurator Server Components.

  • You cannot install Database Configuration Utilities unless you are also installing Siebel Server. (It is not required that you configure and use that particular Siebel Server.)
  • For a production environment, it is strongly recommended not to install any of the following modules together:
    • Siebel Server with Siebel Gateway
    • Siebel Server with Siebel Enterprise Cache
    • Siebel Server with Siebel Constraint Engine
    • Siebel Enterprise Cache with Siebel Constraint Engine

      For more information, see the Siebel Installation Guide for the operating system you are using.

• As you plan your topology, you must also plan for the input that you must provide when you install and configure the Siebel CRM installers, which includes port numbers used by Siebel modules. You must anticipate various installation and configuration requirements. You must have a security and authentication framework in place to be able to install and configure the Siebel software. After your installations are done, you must install the Siebel database and configure various installed Siebel modules. Using Siebel Management Console, you can configure the Siebel Gateway, Siebel Enterprise, Siebel Server, Siebel Application Interface, and other modules. The Siebel Gateway, Siebel Server, and Siebel Application Interface need to be able to communicate with one another in order to configure and operate your installed software.

  For more information, see the Siebel Installation Guide for the operating system you are using and Siebel Security Guide.

• Install the Siebel Document Server on a dedicated server. Siebel Document Server uses Microsoft Word to create documents. Because Word is a single-threaded process, Siebel Document Server could block other processes running on the same server.
• Consider what time of day a component is used. For example, a typical scenario is to run Siebel EIM batch jobs during off-peak hours. Doing this means Siebel 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 this scenario: an implementation plan involves having 1000 connected users with light Assignment Manager usage, light Siebel Workflow usage, heavy off-peak Siebel EIM batch jobs, and a moderate Communications Server load. This implementation also requires some degree of high availability and resiliency. One possible architecture solution would be as follows:
  • Clustered Siebel Gateway. Collocated Siebel File System, Assignment Manager, Workflow Monitor Agent, and Communications Server. You can also configure Siebel Gateway clustering using Siebel Management Console, as noted in Defining High Availability Policies.
  • Multiple, load-balanced Siebel Application Object Managers. The number of servers required depends on the level of configuration and scripting complexity.
• You can choose to engage Oracle's Application 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 of the Siebel CRM deployment. Contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle's Application Expert Services.
• Some components are complex to size (for example, Siebel Product Configurator) and require expertise to determine an appropriate architecture and distribution of components. It is always necessary to have a thorough understanding of your customizable products and how they are 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. Doing 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, Application Object Managers, Workflow, EAI, Assignment Manager and Siebel Product Configurator would all run on dedicated servers. Instances of Siebel Gateway and Siebel Application Interface would also run on dedicated hardware.
• When there are more than a relatively small number of remote users (100 or so), run server components from the Siebel Remote (alias Remote) and Disconnected Mobile Synchronization (alias MobileSync) component groups on a dedicated server. Planning considerations must 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.

  It is important to identify those processes with the potential for spikes of resource consumption and spread the load accordingly.