2 Planning Your Services Gatekeeper Installation
This chapter provides information about planning your Oracle Communications Services Gatekeeper installation.
About Services Gatekeeper Software Components
Services Gatekeeper is built on top of Oracle WebLogic Server and can use all WebLogic Server components. It also embeds Oracle Communications Converged Application Server for connectivity to SIP networks and access to network nodes using the Diameter protocol.
About Services Gatekeeper Components for a Telecom Implementation
Services Gatekeeper provides communication services that telecom operator in-house applications and third-party applications use to access assets in the telecom network. For a list of the supported communication services, see Services Gatekeeper Communication Service Reference Guide. In addition, Services Gatekeeper provides extension points and tooling that you can use to create new communication services.
Each communication service has two components:
-
A service facade that exposes interfaces to be used by applications.
-
A service enabler that consists of a network protocol plug-ins. The plug-ins can be instantiated. Each instance connects to a node in the telecom network using a specific protocol. These instances interact with container services as necessary.
The communication services use container services, which are provided with the installation. Container services include Alarm, Event Data Record (EDR), Call Details Record (CDR), Policy Enforcement, Service Level Agreement (SLA) enforcement, Account, Event channel, and Trace services.
Requests between the network and applications can be intercepted by using service interceptors, which may allow, deny, or manipulate the request as necessary. When called upon to act on a request, service interceptors interact with container services as necessary to determine how to handle the request.
Service facades, service enablers, and service interceptors are deployable units in Services Gatekeeper.
Figure 2-1 illustrates how the Services Gatekeeper service components mediate the flow of requests between applications and the telecom network node.
Figure 2-1 Services Gatekeeper Components
Description of ''Figure 2-1 Services Gatekeeper Components''
Understanding Services Gatekeeper Domains
A domain is the basic administrative unit in Oracle WebLogic Server. It consists of an Administration Server and, usually, one or more managed servers, which may be grouped into clusters, as illustrated in Figure 2-2.
The Administration Server is used to manage the domain and provides access to the WebLogic Server administration tools.
A single WebLogic Server instance can function as both the Administration Server and a managed server, depending on the purpose of the installation. For example, developers creating communication service extensions using the Platform Development Studio might run both the Administration Server and managed servers on a single machine.
Managed servers are often grouped together into clusters that work together to provide scalability and high availability. Clusters improve performance and provide failover should a server instance become unavailable. The servers within a cluster can run on the same machine, or they can reside on different machines. To the client, a cluster appears as a single WebLogic Server instance.
Managed servers, or the clusters to which they are linked, host application components—in this case, the communication services—and resources, which are also deployed and managed as part of the domain.
Each server instance is also assigned to a machine that is a logical representation of actual hardware. The machine representation is used by the Administration Server to start and stop remote servers using the node manager. Multiple server instances can run in a single machine.
For more information about WebLogic Server domains, see "WebLogic Server Domains" in the WebLogic Server documentation.
See "About Configuring Domains" for information on configuring domains.
Understanding Services Gatekeeper Deployment Types
Services Gatekeeper supports the following types of deployments:
-
Single-tier deployments, which are self-contained Services Gatekeeper implementation that runs on a single system. This is what most new customers use to become familiar with Services Gatekeeper. This implementation is suitable for test and development and small-scale production environments. See ”Getting Started with Services Gatekeeper” in Services Gatekeeper Getting Started Guide for details.
-
Tiered deployments, which are suitable for large production environments
-
Non-tiered deployments, which are suitable for test and development and small-scale production environments. There are two types of non-tiered deployments:
-
basic developer
-
basic high availability
-
-
Geographically redundant deployments, which are suitable for large production environments in which provisioning and run-time processing data are replicated between sites
Table 2-1 provides a summary of the different deployment types.
Table 2-1 Summary of Deployments
| Deployment Type | Provides | Characteristics |
|---|---|---|
|
Tiered |
Access and Network clusters |
Targeted for medium and large deployments. Some high-availability aspects. High level of security. High level of scalability. |
|
Non-tiered |
Basic developer configuration |
Targeted to extension and integration developers. No high-availability or redundancy aspects. |
|
Non-tiered |
Basic high-availability |
Targeted for smaller deployments, testing, and development. Introduces support for high availability or redundancy. |
|
Geographic redundancy |
Geographically separated sites with data synchronization |
Each site has the characteristics of a tiered deployment. Adds geographic redundancy aspects that allow for disaster failover in the event of a site failure. Both sites are active; assumes site affinity from an application's point of view. |
About Tiered Deployments
A Services Gatekeeper deployment is normally divided into three tiers: the Access Tier, the Network Tier, and the database tier.
As Figure 2-3 shows, in-house and third-party applications that use Services Gatekeeper interact only with the Access Tier. The Network Tier interacts with the telecommunications network, the Access Tier, and other nodes such as Operation Support Systems (OSS) or Business Support Systems (BSS).
Service facades are deployed in the Access Tier nodes. Service enablers and container services are deployed in the Network Tier nodes.
Figure 2-3 Example of a Tiered Deployment
Description of ''Figure 2-3 Example of a Tiered Deployment''
The tiering physically separates the servers, which enables carrier-grade scaling, security, and high availability.
Services Gatekeeper uses storage services that rely on an underlying database. For security reasons and in order to scale the database tier independently, the database is normally running on separate, dedicated nodes.
Physical Architecture
Each deployment consists of a number of nodes to ensure high availability and to provide redundancy and load balancing. The nodes are separated into a tiered architecture.
Production deployments of Services Gatekeeper are normally tiered into an Access Tier, a Network Tier, and a database tier.
The Access Tier is responsible for:
-
Security
-
SSL (secure sockets layer) termination
-
XML serialization
-
Termination of more latent WAN connections with applications
The Network Tier is responsible for:
-
Network protocol translation
-
Generation of EDRs (event data records), CDRs (charge data records), and alarms
-
Inter-node communications and state management
The database tier is a relational database management system (RDBMS) used to store configuration and provisioning data, as well as data generated as a result of interaction with applications and network nodes. The RDBMS is abstracted by the Storage Service, a container service that provides the nodes with access to a shared cache. The Storage Service is deployed on nodes in the Network Tier.
Figure 2-4 shows an example of the tiered deployment of servers in a Services Gatekeeper installation. A firewall and a load balancer separate the application tier from the servers in the Access Tier. A second firewall regulates the traffic between the servers in the Access Tier and the servers at the Network Tier. All servers in the Network Tier are managed by the Services Gatekeeper Administration Server. The managed servers in the Network Tier can access the telecom network nodes and the database servers.
See ”Deploying Services Gatekeeper in a Demilitarized Zone” in Services Gatekeeper Security Guide for more information on setting up and protecting the Services Gatekeeper physical architecture.
Figure 2-4 Servers in a Tiered Deployment
Description of ''Figure 2-4 Servers in a Tiered Deployment''
As seen in Figure 2-4, the tiers provide a separation at the network level, which allows for:
-
Firewalls to be introduced between the tiers
-
Different networks to be used for the different tiers
The servers are also physically separated within a tier.
Each tier consists of at least one cluster, with at least two server instances (nodes) per cluster, and all server instances run in active mode, independently of each other. The servers in all clusters are, in the context of Oracle WebLogic Server, managed servers. Together the clusters make up a single WebLogic Server administrative domain, controlled through an Administration Server.
Runtime Aspects
Nodes are grouped into one or more clusters in a deployment. With a few exceptions, all the same components are deployed on nodes within a cluster and these components are managed as one unit. There are a set of services where a component, a cluster singleton, is active only on one node within the cluster at any given point. In case of node failure, the singleton service is automatically migrated to another node in the cluster.
Configuration settings for a deployed module can be per node or shared among the components deployed in the a cluster.
The clusters are grouped into a domain, with an Administration Server that normally does not process any traffic. The traffic-processing nodes are called managed servers.
There is normally a one-to-one relationship between managed servers and a physical servers. In some cases, several managed servers can run on the same physical server. If the CPU is powerful and has a lot of memory, performance can benefit from using a smaller heap size for a set of managed servers on a single physical server, rather than using one managed server per physical server. The disadvantage of this setup is mainly loss of redundancy and lower availability if a physical server fails.
Scalability
The Access Tier and the Network Tier scale independently of each other. New servers can be added at runtime, allowing you to scale the deployment horizontally.The main responsibilities of the Access Tier are security, SSL termination, XML serialization and termination of WAN connections from applications. The main responsibilities of the Network Tier are to perform network protocol translation and protocol abstraction. This separation of responsibilities translates into two very different processing models.Processing in the Access Tier is CPU-intensive, mainly concerned with XML to Java translations that have a short life span and generate numerous short-lived objects that trigger frequent garbage collection. The Access Tier does not maintain any state information. This behavior is consistent across communication services.Processing in the Network Tier maintains state information and puts demands on data caching, inter-node communication, and processing logic.The behavior of communication services varies with some of the services supporting relatively long-lived sessions. Call control sessions tend to have a significantly longer session lifetime than more data-centric sessions, such as messaging.Some protocols, for example short message peer-to-peer protocol (SMPP), have more efficient data transfer sizes compared to XML-based protocols, for example multimedia messaging service interface (MM7). This translates into different processing needs.Sizing and configuring individual servers in the Network Tier depend on which communication services are used in the deployment and the estimated utilization ratio between them. Both the physical characteristics of the servers (such as internal memory, network cards and CPU speeds) and settings for the Java Virtual Machine, (such as heap size and other parameters that affect garbage collection) can be optimized for the different use cases.In summary, the processing models determine how you optimize the physical hardware, the Java Virtual Machine, and the operating system. Tiering allows you to tune individual nodes in each tier for the different processing requirements.
Securing the Physical Architecture
Services Gatekeeper provides extensive support for authentication, authorization, and accounting. In addition, the separation of physical tiers allows for network-level security. This helps protect the network from attacks by fraudulent applications that use resources without paying for their usage and attacks designed to take resources out of service.
By using separate IP-network domains, one for the Access Tier and one for the Network Tier, you can apply different levels of network security. Applications are allowed to physically connect only to Access Tier servers, possibly fronted by a firewall, while the Network Tier servers only have access to the network domain where the telecommunication network nodes reside. In addition to this, the Access Tier servers are only allowed to connect to the Network Tier servers, possibly using a firewall between the tiers.
This topology puts the Access Tier servers in a demilitarized zone (DMZ) where out-of-network applications are only allowed access to the Access Tier servers. It also puts the Network Tier servers in a more strictly controlled domain, where the network elements they connect to are well known and the access is controlled by firewalls.
For more information, see ”Deploying Services Gatekeeper in a Demilitarized Zone” in Services Gatekeeper Security Guide.
High Availability
From a high-availability perspective, tiered deployments are better than non-tiered deployments. Processing in the Access Tier is stateless and is characterized by negligible latency while processing in the Network Tier is stateful, involves more processing logic, and higher latency.
In a tiered deployment, the Access Tier adds a high-level load balancing function that is aware of the health of each Network Tier server and quickly removes an out of service server from the list of servers to load balance among. This means that fewer requests are affected if a fault occurs.
The Access Tier guarantees that requests toward the Network Tier are properly load balanced and are not repeatedly sent to Network Tier servers that are out of service. Network tier servers asynchronously update the Access Tier servers when they are back in service.
If a request from an Access Tier server targets a Network Tier server that has failed, the Access Tier server sends the request to another Network Tier server. The Storage Service provides reliable cluster-wide access to all state information kept by the Network Tier. As a result, any Network Tier server can process requests coming from any Access Tier node or network node. If a node fails, cluster singleton services are automatically migrated from the failed node to a healthy node.
High Availability and JavaDB
JavaDB supports one master one slave database. If the master fails, the slave completes the recovery by redoing the log that has not already been processed. The state of the slave after this recovery is close to the state the master had when it crashed. However, some of the last transactions performed on the master may not have been sent to the slave and may therefore not be reflected.
About Non-tiered Deployments
Services Gatekeeper can be deployed in a non-tiered deployment by using one of the following configurations:
-
Multiple node configuration: A non-tiered, multiple node configuration is targeted toward smaller production environments that have less strict scalability and high availability requirements.
-
Single node configuration: A non-tiered single node configuration is targeted toward test and development environments.
Service facades, service enablers, container services, and service interceptors are deployed in all nodes in non-tiered deployments.
Using Non-tiered Deployments in Production Environments
You might use a non-tiered deployment in a production environment when security requirements and scalability requirements are irrelevant or minimal. An example of this is when Services Gatekeeper only serves applications hosted within the operators' domain and there is very restricted access to the IP network where Services Gatekeeper is deployed, and the integrity of the network is ensured by external mechanisms.
Scalability is compromised when you use a co-located access and Network Tier, because the individual servers cannot be optimized according to their diverse processing models.
Figure 2-5 shows a deployment that has a cluster configuration. The Administration Server also processes traffic. The cluster can contain two or more servers.
Figure 2-5 Example of a Dual Server Non-tiered Deployment for Basic High Availability
Description of ''Figure 2-5 Example of a Dual Server Non-tiered Deployment for Basic High Availability''
Using Non-tiered Deployments in Test and Development Environments
When you use Services Gatekeeper for functional testing of extensions and integrations, there is no immediate need for a multi-server configuration. A single-server configuration can be used to simplify management and configuration for the developer or tester.
Although it is possible to run several servers on a single physical machine, the only reason to do so is to run initial high availability tests. System tests should be performed on a deployment with multiple physical servers.
Figure 2-6 Example of a Single Node Non-tiered Deployment for Test and Development
Description of ''Figure 2-6 Example of a Single Node Non-tiered Deployment for Test and Development''
About Geographically Redundant Deployments
Geographically separated deployments are important for high availability. To prevent service failure in the face of catastrophic events such as natural disasters or massive system outages caused by power failures, you can deploy Services Gatekeeper at two geographically distant sites that are designated as site pairs. As Figure 2-7 shows, each site, which is a Services Gatekeeper domain, has another site as its peer. Application and service provider configuration information, including related Service Level Agreements (SLAs) and budget information, is replicated and enforced across sites.
Figure 2-7 Example of a Geographically Redundant Deployment
Description of ''Figure 2-7 Example of a Geographically Redundant Deployment''
Geographically redundant sites are the active-active type, which means that both sites in a pair can be used to process traffic simultaneously. These deployments are connected by communication channels for data synchronization and health monitoring. The data synchronization replicates budget information between the site pairs to enforce SLAs accurately. Applications should have site affinity, but have the ability to fail over to the other site if necessary. Each site is managed and configured independently. Accounts and SLAs are replicated across sites. Typically, one database tier is used per site.
All sites have a geographic site name and each site is configured to have a reference to its peer site using that name. The designated set of information is synchronized between these site peers.
One site is defined as the geomaster, the other as the slave. Checks are run periodically between the site pairs to verify data consistency and an alarm is triggered if mismatches are found, at which point the slave can be forced to synchronize to the geomaster. Any relevant configuration changes made to either site are written synchronously across the site pairs, so that a failure to write to one site causes the write to fail at the other site while triggering an alarm.
If a slave site becomes unavailable for any reason, the geomaster site becomes read-only, either until the slave site is available and has completed all data replication, or until the slave site has been removed from the geomaster site's configuration, terminating geographic redundancy. This behavior applies only to global configuration changes.
For applications, geographic redundancy means that their traffic can continue to flow in the event of a catastrophic failure at an operator site. Applications that normally use only a single site for their traffic can fail over to a peer site while maintaining ongoing SLA enforcement for their accounts. This scenario is particularly relevant for SLA aspects that have longer term impact, such as quotas.
In many respects, the geographic redundancy mechanism is not transparent to applications. There is no single sign-on mechanism across sites, and an application must establish a session with each site it intends to use. In case of site failure, an application must manually fail over to a different site.
While application and service provider budget and configuration information are maintained across sites, state information for ongoing conversations is not maintained. Conversations in this sense are defined in terms of the correlation identifiers that are returned to the applications by Services Gatekeeper or passed into Services Gatekeeper from the applications. Any state associated with a correlation identifier exists on only a single geographic site and is lost if an entire site goes down. Conversational state includes, but is not limited to, call state and registration for network-triggered notifications. This type of state is considered volatile, or transient, and is not replicated at the site level.
As a result, conversations must be conducted and completed at their site of origin. If an application wants to maintain conversational state across sites, for example, to maintain a registration for network-triggered traffic, the application must register with each site individually.
About Configuring Domains
Services Gatekeeper ships with domain configuration templates that you use to configure domains. There is a template for each type of deployment that Services Gatekeeper supports. These templates contain the basic configurations for setting up domains, but you may need to adjust some aspects of the domain during the domain configuration process.
Table 2-2 lists and explains the deployment templates.
Table 2-2 Domain Templates for Deployments
| Domain Template Type | Template Name | Description |
|---|---|---|
|
Basic developer configuration with co-located access and network tiers |
Basic Oracle Communications Services Gatekeeper Domain |
Creates an unified domain containing both the access and network tiers and the administration server all on a single machine. There is no support for high-availability configurations. The server does not belong to a cluster but is tied to the domain. This deployment type is common for non-production development machines where developers need access to Services Gatekeeper for functional testing of extensions and integrations. |
|
Basic high-availability configuration |
OCSG Basic HA configuration |
Creates a basic high-availability, unified domain containing an access tier and network tier, each with two servers, and a database. One of the servers can also serve as the WebLogic administration server. The servers do not belong to a cluster but are tied to the domain. Database replication is not automatically provided and must be configured at the database level. This configuration can be expanded later. This deployment type is common for:
|
|
Access and network tier clusters |
OCSG Domain with Access and Network Clusters |
Creates a basic distributed domain, with a two-instance access tier cluster and a two-instance network tier cluster. A separate server has the role of the WebLogic administration server. This server does not process traffic requests. This configuration can be expanded later. High availability toward the database is not supported automatically. Redundancy toward the database is up to the database deployment. This deployment type is common for production environments and support deployments with a DMZ between the access and network tiers. |
|
Access and network tier clusters with Oracle RAC database |
OCSG Domain with Access and Network Clusters with Oracle RAC Configuration |
Creates a basic distributed domain, with a two-instance access tier cluster and a two-instance network tier cluster. This configuration can be expanded later. It also creates the additional data sources required for use with an Oracle RAC-based installation. This configuration has all the properties of the access and network tier cluster setup and adds high availability and redundancy toward the database. This setup leverages the failover and redundancy characteristics of Oracle Real Application Cluster (Oracle RAC). This deployment type is common for production environments and supports deployments with a DMZ between the access and network tier. |
|
Portal servers |
OCSG Portal Domain |
Creates a domain that contains the Portal server on a single machine. |
System Deployment Planning
All servers in a Services Gatekeeper cluster must be dedicated servers.
You must perform an installation on each machine in your Services Gatekeeper configuration.
Figure 2-8 shows one recommended Services Gatekeeper installation.
Figure 2-8 Recommended Services Gatekeeper Installation
Description of ''Figure 2-8 Recommended Services Gatekeeper Installation''
For more information on more secure installations see the diagrams in ”Deploying Services Gatekeeper in a Demilitarized Zone” in Services Gatekeeper Security Guide.
See "Installing Services Gatekeeper" for detailed installation instructions.
About Setting Up Services Gatekeeper Reporting Support
If you plan to install Services Gatekeeper reporting support, you will need additional servers to host Oracle Business Intelligence.
You install Services Gatekeeper reporting support by using a separate installer. Before you configure the reporting functionality, you must install and configure Oracle Business Intelligence, which prepares and renders the Services Gatekeeper reports.
Oracle Business Intelligence requires a dedicated server and an reports staging database.
Figure 2-9 shows a recommended Services Gatekeeper installation including a dedicated servers for Oracle Business Intelligence.
Figure 2-9 Recommended Services Gatekeeper Installation with Reporting
Description of ''Figure 2-9 Recommended Services Gatekeeper Installation with Reporting''
Note:
A core Services Gatekeeper installation must be configured and running before you can install portal and reporting support.About Deploying Partner Relationship Management Modules
Oracle recommends that you deploy the Partner Relationship Management (PRM) modules in a separate cluster in the domain. The PRM servers should not be co-located with Access Tier servers or Network Tier servers, because PRM processing impacts the performance of processing traffic requests.
There are two views to PRM: the service provider view and the operator view. Each view can be deployed separately. A portal application can benefit from being deployed in two parts: the service provider view deployed in the DMZ and the operator view deployed inside the secure network of the operator, not accessible from the Internet.
About Integrating Services Gatekeeper with Converged Application Server, Service Controller
You can integrate Services Gatekeeper with Oracle Communications Converged Application Server, Service Controller (Converged Application Server) if your implementation requires service orchestration and protocol mediation capabilities.
A Converged Application Server-Service Gatekeeper integration must communicate using SIP traffic, and Services Gatekeeper must then translate the SIP traffic into SS7 format. Consequently, these are the network-facing communication services that can take advantage of the integration:
-
Parlay X 2.1 Audio Call/SIP
-
Parlay X 2.1 Call Notification/SIP
-
Parlay X 2.1 Presence/SIP
-
Parlay X 2.1 Third Party Call/SIP
-
RESTful Third party Call
-
RESTful Call Notification
-
RESTful Audio Call
-
RESTful Presence
For details on these communication services see the Services Gatekeeper Communication Service Reference Guide and the section on RESTful services in Services Gatekeeper Application Developer's Guide.
About Enterprise Manager Compatibility
Services Gatekeeper is compatible with Oracle Enterprise Manager Cloud Control version 12c. For information about Enterprise Manager Cloud Control 12c, see the Enterprise Manager 12c page on the Oracle Technology Network website:
http://www.oracle.com/technetwork/oem/enterprise-manager/overview/index.html
See ”Using Cloud Control Monitoring with Multi-tier Services Gatekeeper” in Services Gatekeeper Administrator's Guide for more information.
About Administering Your Implementation
You administer Services Gatekeeper by editing the underlying MBeans, or running their operations. Services Gatekeeper provides a GUI tool for this purpose, or you can use another Java management tool. For details, see ”Administration Overview” in Services Gatekeeper System Administrator's Guide.
Disk Storage Planning
You can use an ordinary disk system for disk storage. However, for performance and high availability reasons, a RAID system should be used.
Latency and Bandwidth Requirements
To avoid transaction processing issues related to latency or bandwidth restrictions Oracle provides the following guidelines for minimum latency and bandwidth requirements used in production environments.
Latency Requirements
Table 2-3 shows the minimum latency requirements between Services Gatekeeper entities in a production environment.
Bandwidth Requirements
Table 2-4 shows the minimum required bandwidth between Services Gatekeeper entities in a production environment. Bandwidth requirements depend on the traffic type and traffic load present in your environment. These guidelines are for typical deployments of Services Gatekeeper
Database Planning
Production multi-tier systems generally use a database on a system separate from the other Services Gatekeeper components. Production implementation architecture strongly favors deploying a non-JavaDB database in a separate tier for performance and security reasons. However, for a test and development implementation you can deploy the JavaDB on the same system as the other Services Gatekeeper components. Figure 2-11 shows an example of this architecture that is suitable for test, or small production implementations. This architecture offers high-availability and is relatively inexpensive to implement. However, it does sacrifice security, so only use it in a trusted environment, such as for internal company API management.
Installing a multi-tier Services Gatekeeper with a non-JavaDB database usually requires a different strategy. The database should be deployed on a dedicated server. Backup and other data-intensive operations should not increase load on traffic-processing servers. Database administrators should be granted exclusive privileges to log on and perform SQL operations.
Oracle recommends that you use an Oracle database, where the instance is based on the transaction processing template, runs in dedicated server mode, and uses automatic store management.
See "Supported Databases" for a list of the databases you can use.
For more information on secure production implementation, see ”Deploying Services Gatekeeper in a Demilitarized Zone” in Services Gatekeeper Security Guide.