3Siebel Infrastructure Planning
Siebel Infrastructure Planning
This chapter explains how to plan the infrastructure of your Siebel CRM deployment. It includes the following topics:
Process of Infrastructure Planning
The tasks in this process help you to determine the Siebel CRM infrastructure requirements for a production environment. Along with a production environment, you must also plan for a development environment and a test environment.
Use the following tasks to plan your Siebel CRM deployment infrastructure:
Determining How Siebel CRM Applications Are Used
This task is a step in Process of Infrastructure Planning.
This infrastructure planning task identifies what tasks users perform when using Siebel CRM applications. Examples are completing a customer order, adding a contact, and creating a quote. Later in the planning process, you map these tasks to specific Siebel applications and functions.
To determine how Siebel CRM applications are used
Identify user types.
For each business location, identify user types. Organize this list by the functional areas that participate in key business processes. Include application developers and integrators, system administrators, and application administrators in your list of user types.
For example, assume that you have a call center in Denver. One of your key business processes is order creation. Two of the functional areas that participate in this business process are call center agents and product line administrators. These are two user types.
Identify tasks by user type.
For each user type, identify all of the tasks that the users perform using Siebel applications. Start with each key business process and map its steps to tasks. Doing this step helps you to verify that your business processes are being correctly automated.
Identify background tasks.
If your business operation includes background tasks, then list these as well. Background tasks are those that the Siebel CRM components perform, rather than users. These include batch processing of business data and automated workflow processes.
Estimate transaction volumes.
For each user task, estimate average and maximum daily transaction volumes. For example, in your Denver call center there are 25 call center agents. Transaction records indicate that each agent completes an average of 12 customer orders per day and a maximum of 20 per day. The following is an example of how you would list transaction volumes for the Denver call center.
User Type Number Task Average Volume Per Day Maximum Volume per Day Call Center Agents
25
1. Inbound customer order
300
500
Defining Data Flows and Integration Requirements
This task is a step in Process of Infrastructure Planning.
This infrastructure planning task identifies how data flows to and from the Siebel CRM deployment. An example of a key data flow would be customer contact updates that originate at several call centers and flow to the master customer contact database at a headquarters location.
This task identifies where the master copy of data records resides. It also identifies the data interchange requirements for applications.
To identify data flows and transaction volumes
Identify business data.
List the types of business data that flow through the system components of Siebel CRM. Examples of business data are orders, customer contacts, product line information, and quotes.
Identify business data sources.
For each type of business data, list the user types or business activities that can originate or update the business data. Group user types or business activities by business location.
Analyze the data requirements of legacy applications.
Identify all of the existing applications that send or receive data from the Siebel CRM deployment. Determine data volumes and group them by location.
Identify data formats and transformations.
For each legacy application that sends or receives data from the Siebel application, identify the required data formats. Specify in detail all of the data transformation requirements.
Map the data flows.
Create a model that shows all of the major business data flows. Include all of the data sources, repositories, and key business applications.
The following figure shows an example of a model of a data flow. The example shows a call center running the Siebel Communications application. The company maintains an ERP database and a phone number database separately from the Siebel database, which contains customer information.
Siebel Communications sends XML messages containing customer orders to the order fulfillment application, and receives order fulfillment status through an inbound HTTP adapter. Siebel Communications also queries the phone number database for available phone numbers in real time. The phone number database then receives assigned phone numbers from the Siebel database using Siebel EIM.
Determining Database Requirements
This task is a step in Process of Infrastructure Planning.
This infrastructure planning task identifies database requirements for the Siebel CRM deployment.
You would have already identified the types of data that are stored in the Siebel database. This task maps that data to key database characteristics. Doing this task helps you to estimate database size requirements and expected growth. Begin by defining general requirements:
What types of records are stored? What specific fields does each record contain?
What is the volume of each record? How many records of each type are processed each hour? Each day? Each year? Group this information by business location.
Determine how record volumes map to specific Siebel tables. For help with mapping records to Siebel tables, contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.
How much space do database indexes occupy? Typically, indexes require as much space as the data. For example, 50 GB of data requires about 50 GB of indexes.
What is the expected annual growth rate of the database by record type and location?
Include the following information in your analysis of records:
Number of addresses that are assigned to each customer account
Number of employees that are assigned to each account
Number of contacts that are assigned to each account
Number of attachments that are assigned to a record
Number of activities that are associated with each account
Whether opportunities, quotes, or orders are stored
Whether product data is stored
Whether Siebel Remote is used
Whether Siebel Mobile applications are used
Include the temporary table space, log files, and space required for loading data.
Mapping Business Requirements to Siebel Server Components
This task is a step in Process of Infrastructure Planning.
This infrastructure planning task identifies the Siebel Server components needed to meet your business requirements.
Begin by listing the Siebel applications that users run. For each application, identify the associated Application Object Manager. List all language-specific Application Object Managers that you need.
Many Application Object Managers require additional server components such as Workflow Manager. Users typically do not interact with these second-tier components directly. The role of these components is to support the function of Application Object Managers and of the Siebel Server.
All of the second-tier component requirements must be correctly identified in your planning and review phases. Work closely with your implementation team to identify these components.
After you have identified all of the required server components, group them by business location. Then, for each location, determine the anticipated workload volumes for all of the components. Consider both average and peak workloads. This information is key for deciding how to distribute Application Object Managers and other components across Siebel Servers.
Defining High Availability Policies
This task is a step in Process of Infrastructure Planning.
This infrastructure planning task defines business policies regarding availability of servers.
See also High Availability Deployment Planning .
Siebel Servers
For each business location, assess the impact of losing each server component. Consider the possibility of the component failing, rather than the hosting platform itself. Individual server components that are important to normal application function must be identified in your planning and review phases. Work closely with your implementation team to identify all of the components that could represent single points of failure.
After you complete this analysis, define high availability policies for all of the applications and services. Decide how long your business can tolerate not having access to key applications. Also, decide how long your business can tolerate degraded performance.
For example, a company decides that Siebel Call Center must run 24 hours a day, seven days a week, and that the maximum acceptable downtime is 30 minutes. The company also decides that the maximum time it can accept degraded performance is one hour.
Finally, at each business location, list all of the server components to which each policy applies. This analysis forms the basis for implementing a high availability strategy as part of hardware planning.
Database Platform and Data Integrity
The server platform that hosts the Siebel database is crucial to Siebel CRM deployment operations. For this reason, it is important to define high availability and data integrity policies specifically for the database server. The following policies are recommended:
Cluster database servers to protect against platform hardware failures.
Use redundant disk arrays (RAIDs) for disk storage. RAID 1+0 is recommended because it provides maximum performance, and there is no data loss if a disk fails. Do not implement RAID 0 arrays. RAID 0 offers good performance but does not protect data adequately in the event of a disk failure.
Enable transaction logging.
Observe the following recommendations for storing database files:
Store data and indexes on separate disk subsystems.
Store active log files and archived log files on separate disk subsystems.
Store the database and database control files on separate disk subsystems.
To allow for good OLTP performance, set up four rollback segments (if you choose to use them) for each 20 to 40 users. For Initial extents or Next extents, set up rollback extents sized to 100 KB. If you use Siebel EIM, then also create several additional, large rollback segments to support Siebel EIM loads.
Siebel Gateway
The Siebel Gateway maintains the Siebel Gateway registry to store the configuration information for all of the Siebel Servers in all of the Siebel Enterprise Servers managed by the Siebel Gateway. Loss of the Siebel Gateway due to a disk failure could bring your Siebel CRM deployment to a halt while you restore the Siebel Gateway, unless you take measures to provide high availability for the Siebel Gateway.
As of Siebel CRM 18.5 Update, Siebel CRM supports an optional native clustering feature for Siebel Gateway to provide high availability benefits to Siebel CRM customers. This feature works at the software level and is the preferred and recommended approach for clustering the Siebel Gateway. To use this feature, you install Siebel Gateway on multiple nodes and configure clustering using Siebel Management Console. Clustering is supported for both the Siebel Gateway service (application container) and the Siebel Gateway registry (Apache ZooKeeper). If an individual node goes down within the Siebel Gateway cluster, then the Siebel Application Interface or Siebel Server client connection switches to another available node. After any Siebel Gateway cluster node goes down, when it is restarted, the node will again participate in the cluster. For more information, see the Siebel Installation Guide for the operating system you are using.
Optionally, you can install a RAID or some other type of redundant disk configuration on your Siebel Gateway.
Siebel Mobile Web Client Users
A Siebel Server temporarily stores transaction files that move to and from users of the Siebel Remote client, generally called Siebel Mobile Web Clients. The loss of these files results in the need to re-extract the database for all of the affected mobile users. (Siebel Remote supports synchronization of data between Siebel Mobile Web Clients and the Siebel database, over an Internet connection.)
It is strongly recommended that you install a RAID or some other type of redundant disk configuration on Siebel Servers that run Siebel Remote.
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.
This topic includes the following information:
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
This topic is part of Mapping Siebel CRM Deployment Elements to Platforms.
Perform the following steps to determine your server platform requirements, for topology planning:
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 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.
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.
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.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?
Use average and peak workload information to determine how many instances of Siebel Application Interface are needed.
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:
Verify that all of the 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 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.
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
This topic is part of Mapping Siebel CRM Deployment Elements to Platforms.
Consider the following guidelines for topology planning:
A single Siebel Gateway or Siebel Gateway cluster can manage a single Siebel Enterprise Server.
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.
The following table describes possible deployment schemes for Siebel CRM applications.
| Deployment Scheme | Recommended? |
|---|---|
A single Siebel Gateway with multiple Siebel Enterprise Servers configured on a single computer or UNIX hardware partition. Each Siebel Enterprise Server has its table owner and Siebel database. |
No. |
Running multiple Siebel Gateways on a single UNIX hardware partition or on a single unpartitioned computer. |
No. |
Installing and configuring Siebel Gateway on multiple nodes to provide clustering services. |
Yes. For more information, see Defining High Availability Policies. See also the Siebel Installation Guide for the operating system you are using. |
Multiple Siebel Enterprise Servers sharing a DBMS table owner (schema). |
Might 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. |
A single Siebel Enterprise Server hosting multiple Siebel Servers within a single hardware partition. |
No. |
A Siebel Enterprise Server hosting multiple Siebel Servers, with each Siebel Server on its own computer, operating system instance, or UNIX hardware partition (multiple partitions on each UNIX server computer). |
Yes. This scheme is the most common way to deploy Siebel CRM applications. |
Installing the Siebel Gateway, each Siebel Server, and the Siebel database all on different operating systems. |
Yes. This scheme is supported. However, it is strongly recommended 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 that you need only runs on another operating system. For information about supported operating systems for Siebel CRM deployments, see the Certifications tab on My Oracle Support. |
Recommendations for Collocating Server Components
This topic is part of Mapping Siebel CRM Deployment Elements to Platforms.
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.
Determining Network Requirements
This task is a step in Process of Infrastructure Planning.
The purpose of this infrastructure planning task is to identify the network requirements needed to support the Siebel CRM deployment.
To determine network requirements
Use the information about average and peak workloads to verify that there is sufficient network bandwidth to handle network traffic to and from, as well as within, the Siebel CRM deployment.
Determine whether to use data encryption. If so, then define data encryption policies. Then add data encryption protocols to the deployment plans that you outlined using Mapping Siebel CRM Deployment Elements to Platforms.
Define firewall requirements. If you are creating a network DMZ, then also define the requirements for proxy servers and other items that you install in the DMZ.
Include network address translation (NAT) and HTTPS requirements.
Analyze interactions and dependencies between networking components.
For example, assume that you use HTTP with TLS (Transport Layer Security) between browsers and instances of Siebel Application Interface.
Select port numbers for all of the network components that listen on TCP ports.
This includes Siebel Application Interface, Siebel Servers, and server clusters. For a full description of Siebel Server components that require a port number assignment, see Siebel System Administration Guide. See also the Siebel Installation Guide for the operating system you are using.
The default TCP port number for Siebel Application Interface-to-Siebel Server traffic is 3320. This is the port number of the Siebel Connection Broker (SCBroker); however, you can configure the port number. You cannot assign the Siebel Gateway and Siebel Servers port numbers higher than 32767.
Also, verify that firewalls are configured to communicate with the correct TCP ports.
Consider any other factors that might affect networking connectivity.
Defining a Test and Transition Plan for the Siebel CRM Deployment
This task is a step in Process of Infrastructure Planning.
It is important that you define a test plan to verify that the proposed deployment infrastructure functions correctly and is sized correctly. Equally important is defining a plan that transitions the Siebel CRM deployment to production.
Observe the following recommendations for testing the Siebel CRM deployment and transitioning it to production:
Separate production environment. Keep the development and test environments physically separate from the production environment. Do not conduct development and test activities on the production Siebel database or, if possible, on the production database server.
Server stress testing. Test Siebel Enterprise Server performance under average and peak workloads.
Oracle’s Application Expert Services finds that performance problems at customer sites are frequently caused by the following:
Servers were tested at much less than average or peak workloads. This prevents configuration and tuning problems from being uncovered.
Siebel Server components and other Siebel product modules are either incorrectly distributed across servers or are not configured correctly.
Failover and resiliency testing. Define a test plan that evaluates the effect of server component failures. Work closely with your implementation team to identify all of the components that could represent single points of failure, as noted in Defining High Availability Policies.
Define a server cluster test plan that evaluates failover behaviors. Run the test plan under average and peak workloads. It is particularly important to verify that failover performance under peak workloads is acceptable.
Database server testing. Define a test plan that evaluates the following:
OLTP performance. Consider OLTP performance under average and peak workloads.
Database server platform failover. Typically the database server is clustered.
Recovery from database corruption. The database vendor usually provides recovery mechanisms.
Batch processing support. Verify that the database server correctly handles batch jobs from servers as well as synchronization requests from Siebel Remote components.
Siebel Web Client users. Verify that batch jobs do not degrade transaction processing performance and are completed in a reasonable time.