Siebel Server Installation Guide for Microsoft Windows > Siebel Server Installation Overview > The Siebel Environment >

Siebel Gateway Overview

With Siebel 7, significant changes took place in the role of the Siebel Gateway in Siebel deployments that you must understand in deciding how to deploy your servers (Figure 1 and Figure 2).

The Siebel Gateway is not a physical server, it is a logical entity consisting of a Name Server and, optionally, Connection Broker. In Siebel 7, the Name Server and Connection Broker are now separate software components that can reside on different servers.

The Name Server is the primary service associated with the Siebel Gateway. It can be deployed as a standalone server, or as part of multiple servers, based on your requirements in terms of high availability and your budget constraints.

Also, a single Siebel Gateway can now support multiple Siebel Enterprise Servers.

Name Server Overview

The Name Server provides the persistent storage of Siebel Server configuration information, including:

As this information changes—such as during the installation or configuration of a Siebel Server—it is written to the Name Server.

The Name Server serves as the dynamic registry for Siebel Server and component availability information. At startup, a Siebel Server within the Siebel Enterprise Server notifies the Name Server of its availability and stores its connectivity information—such as network addresses—in the Name Server's non-persistent (volatile) store.

Enterprise components (including the Server Manager) query the Name Server for Siebel Server availability and connectivity information. When a Siebel Server shuts down, this information is cleared from the Name Server. However, users can connect directly to the database without the Name Server being up and running.

In a Windows environment, the Name Server runs as a Windows service. The user installing the Name Server needs permissions to create such services.

Impact of Failure of Name Server

If connection brokering is being used, when the Name Server becomes unavailable, active user connections continue to function. All server components and object managers currently running continue to do so and new connections (login sessions) can still be initiated. However, no new Siebel Server components can be started or added and server administration functions become limited. Without connection brokering, if the Name Server fails, all users, server components, and object managers lose connection. Name Server failure also prevents communication with the Actuate Report Server, and Report functionalities will be unavailable.

Resource Requirements for Name Server

The Name Server requires very few system resources. Follow the hardware recommendations listed in System Requirements and Supported Platforms.

Connection Brokering/Central Dispatch Scheduler Overview

Connection Broker directs client connection requests to the least-laden Siebel Server operating the desired component, which provides greater scalability and higher availability. Connection broker has its own service and uses the Central Dispatch product to distribute Web server connection requests across multiple Siebel Servers. For important information about connection brokering, see Implementing Load-Balancing with Central Dispatch.

NOTE:  Mobile Web client connections are not distributed by Central Dispatch.

Impact of Failure of Central Dispatch Scheduler

If the Central Dispatch Scheduler fails, there is no impact. Existing sessions are maintained and new sessions can still be initiated. If the primary Central Dispatch scheduler fails, and a backup scheduler has been activated, then existing sessions are maintained and new sessions can still be initiated. The time to failover between schedulers is configurable. For more details on how to configure the scheduler, see Implementing Load-Balancing with Central Dispatch.

High-Availability Solution for Central Dispatch Scheduler

Central Dispatch specifies two servers for use as the Scheduler—one acts as a Primary Scheduler, while the other acts as the Secondary Scheduler. The Primary Scheduler always listens on the Virtual IP (VIP) address and distributes traffic unless it at some point becomes "unavailable," at which point the Secondary Scheduler takes over listening on the VIP and distributing traffic.

Resource Requirement for Central Dispatch Scheduler

The Connection Broker/Central Dispatch Scheduler does not generally require much resource even when there is a heavy user load, and routing modules reside in the kernel layer or network driver layer.

To maximize performance and minimize interference from outside factors, it is recommended that you use a dedicated Scheduler for deployments with over 1000 concurrent users. In most cases, a single CPU with 512 MB of RAM should suffice even for deployments with many thousands of concurrent users. A dual processor server and 1 GB of RAM would suffice for future system growth. Running a dual processor server also minimizes the likelihood of any program process that is monopolizing the resources of a CPU.


 Siebel Server Installation Guide for Microsoft Windows 
 Published: 25 June 2003