2 Environment Planning Considerations

This chapter describes considerations for Oracle Communications MetaSolv Solution components and provides tips on how to set up for the most efficient use of the application.

Availability Requirements

Business requirements for availability, scalability, and capacity planning have important impacts on planning. This is especially true for hardware sizing, hardware and software configuration, and software use.

Availability refers to a software system's ability to service users. A system possesses 100 percent availability if it can service a request within a defined period of time for every single user request. In practice, 100 percent availability is difficult to achieve.

Scalability Requirements

Scalability refers to the degree to which a system can maintain acceptable response times, availability, and other performance metrics as the load on the system increases. A system is infinitely scalable if the amount of work the system completes per second increases linearly as the amount of computer resources available increases. Infinite scalability allows MetaSolv Solution to serve an ever-increasing population of users simply by increasing the computer resources available to it.

MetaSolv Solution provides high availability using Oracle WebLogic Server platform. Oracle WebLogic offers service continuity in the event of a single server failure within a cluster by allowing you to configure multiple servers as members of a single distributed server set. If one server instance within the cluster fails, other instances of the same distributed server set provide uninterrupted service.

For information on installing and deploying MetaSolv Solution as a multiserver or server cluster configuration, see MetaSolv Solution Installation Guide. For supplemental information on configuring and using server clusters, see the Oracle Web page at:

http://www.oracle.com/technetwork/middleware/weblogic/overview/index.html

With MetaSolv Solution, you can manage a single network inventory using multiple application servers. The optimal number of servers that can be supported in a multiserver configuration depends on a number of interrelated conditions, including the size of the database, power of the database server machine, and number of database connections required. Conditions vary for each deployment. In a multiserver environment, all MetaSolv Solution servers share a single Oracle (logical) database, with each server interacting with the database concurrently. Oracle's transaction facilities maintain consistency of the data within the inventory as the database receives multiple concurrent updates from different MetaSolv Solution servers.

Hardware Sizing Guidelines

You must know how many application servers to set up and the hardware needed to support your deployment of MetaSolv Solution 6.2.x. A good guideline for capacity planning is for every two CPUs and every 100 MHz of speed, the system can support nine users. For additional information on hardware and software planning, see "Minimum Technical Requirements".

The following sections contain Oracle's recommendations for medium and large hardware configurations, based on 100, 500, and 1000 concurrent users. The N+1 industry practice is used in the configurations.

Hardware and Software Configuration

The following sections contain information on installing MetaSolv Solution components.

Database Considerations

If you have installed a version of MetaSolv Solution that is earlier than 6.0.x, you must upgrade to MSS 6.0.x before installing MSS 6.2.x.

Note:

For MSS 6.2.x, you must install Oracle Database 11gR2.

Database Server Configuration

MetaSolv Solution 6.2.x supports the following database server configurations:

  • Active/passive: In this configuration, an active cluster node performs processing while a second passive node is held in reserve to take over processing if the active node fails. This configuration provides faster failover response than traditional standby methods because the passive node is available immediately to take over processing.

  • Oracle RAC: In conjunction with WebLogic JDBC multi data source failover algorithm, connection requests get routed to the first data source in the list; if the request fails, the request is sent to the next data source in the list, and so forth.

Application Server Considerations

The following section details application server considerations. Considerations include the following: connection pooling, clustering, clients, if your plan includes a background processor, if your plan includes a Citrix server, security, and performance and tuning.

Connection Pooling

Connection pools are a group of ready-to-use connections between an application server and the database dedicated to the application. The connection pool creates the specified number of database connections when the application server starts up. By establishing connections at start-up and keeping them ready for an application to use, the connection pool eliminates the overhead of creating a database connection for each client request. Connections are returned to the connection pool when they are freed from use by the application.

Managing connection pools effectively can increase the efficiency of an application, especially if clustered servers are used. Therefore, as part of your environment planning, you should determine the best configuration for managing the connection pools. One factor is the size of the load (the number of concurrent users). A general rule is to provide a connection for each concurrent user you estimate will use the application, so no user waits for a connection. Another general rule is that the number of application server connection pools should be 30 to 50 percent of the number of potential users.

For assistance in determining how to size and set up connection pooling, see the Oracle WebLogic Server documentation.

Should You Cluster?

Single-server architecture is not recommended for MetaSolv Solution. There is no backup strategy if the server fails, and the result could be a loss of data and operational functionality. In addition, the architecture is not scalable. If your business needs increase, it is difficult to add more client workstations and increase the throughput of the system.

A more efficient way to deploy MetaSolv Solution 6.2.x is to cluster application servers. There are four basic ways to cluster application servers:

  • Oracle proxy server with clustered servers on a single host

    Oracle does not recommend the single proxy solution.

  • Oracle proxy server with clustered servers on multiple hosts

  • External load balancer with clustered servers on a single host

    For an external load balancer solution, failover support depends on the vendor solution. A deployment architecture that clusters all servers on one host is not recommended because hardware failure can cause an outage and nullify the benefits of clustering.

  • External load balancer with clustered servers on multiple hosts (recommended)

    You can use external load balancers and place some application servers on the same host machine and some on different hosts. The configuration of session replication prevents the drawback of the single host approach.

    Figure 2-1 shows a 4-node cluster with eight servers and failover load balancers.

Figure 2-1 Server Cluster with Load Balancing

Description of Figure 2-1 follows
Description of "Figure 2-1 Server Cluster with Load Balancing"

Recommendations for load balancing:

  • If you have more than 250 concurrent users, Oracle recommends using an external load balancer to ensure system performance and response time.

  • If you choose an Oracle proxy solution, Oracle recommends placing the proxy server on a separate machine. The Oracle proxy server in this case becomes a single point of failure.

Client Considerations

Client software includes utilities as well as the core client application. The utilities are not required to run the MetaSolv Solution core application on a workstation. Instead, the utilities allow specific tasks to be completed that are in addition to core responsibilities. You can choose to install these applications on a single workstation where they can be easily accessed, or you can allow any user to install them on the same client machine used for the core application.

If you are not using a Citrix server, which handles processing of many users efficiently, you should consider increasing the processing power of hardware dedicated to the client workstation. The technical requirements listed for the MetaSolv Solution rich client provide minimums. For maximum efficiency, consider your company's needs and increase the processing levels of the hardware requirements if necessary.

The following client software can be loaded on a separate machine from the core application:

  • Location and Routing Gateway

  • NPA Split Utility

  • MetaSolv Solution Utilities

If you choose to run these software applications on a machine separate from a core client workstation, you must install the Oracle client on the machine to allow the applications to communicate with the database server.

If Your Plan Includes a Background Processor

The MetaSolv Solution Background Processor is a separate product that provides functionality similar to a mainframe VMS job queue or a print queue. The Background Processor consists of three applications that can be distributed between a remote server and a system administrator's workstation:

  • Job Master (JMASTER.EXE)

  • Job Worker (JWKR.EXE)

  • Job Manager (JMANAGER.EXE)

The Background Processor also includes a job queue, which is a table in the MetaSolv Solution database. When users send jobs, such as group assignment, to the background, the jobs go into the job queue database table. Job Master checks the queue periodically. When it finds a job, Job Master initiates a Job Worker and gives it the ID of the job to be processed. Job Manager acts as a window on the job queue that lets you manipulate the queue.

Oracle recommends running the background processor on a separate server, but the application can also be run on the client workstation. The number of background tasks handled by the Background Processor should be considered before you set it up in either configuration. If the Background Processor will handle a high volume of tasks, it is more efficient to put it on a separate server. See "Minimum Technical Requirements" for complete information on the Background Processor's technical requirements.

If Your Plan Includes a Citrix Server

Citrix and Windows 2008 with Terminal Services allow you to install MetaSolv Solution in one place and have all the clients access the software. You install the application as you would on a server, but it behaves as if you installed on the client. A Citrix server setup resolves performance issues that you get when you install MetaSolv Solution on a server and have everyone access through a shortcut. Citrix Terminal Services also resolve logistical issues of installing on individual clients.

Microsoft Windows 2008 Server with Terminal Services is an operating system that allows multiple, simultaneous clients access to sessions in a server environment. Each session is a private, protected memory space in which users can run applications.

Citrix is server-based software that extends the reach of Terminal Server by providing:

  • A wider range of clients and protocols

  • Enterprise-scale management tools

  • Integration of local and remote resources with bandwidth independent performance

Configuration

MetaSolv Solution must be in the same domain as the APIs, database, and clients.

Figure 2-2 displays an example of a Citrix and MetaSolv Solution configuration.

Figure 2-2 Citrix / MetaSolv Solution Configuration

Description of Figure 2-2 follows
Description of "Figure 2-2 Citrix / MetaSolv Solution Configuration"

Be sure to use the following Citrix configuration with MetaSolv Solution:

  • Set up a default printer.

  • Set up the WTSUPRN file so any printer the clients can use maps to the HP LaserJet 3 driver.

  • If using gateways, modify the MetaSolv Solution registry entry under APICLIENT so the %SYSTEMROOT% in the path name gets hard coded to the correct drive letter and path.

  • There are references to C:\temp made during the installation and placed in the registry. Although this process works most of the time, it could be an issue in some installations. Contact Oracle Support for more information.

Security

Use the Citrix application execution shell (App) to write execution scripts that:

  • Copy standardized INI files containing default settings to user directories before starting an application. Perform application-related cleanup after the application closes.

  • Keep hackers from modifying execution parameters (for example, working directory or execution directory).

For more information on Citrix security and the App shell, see the Citrix product documentation.

Performance and Tuning

The following information refers to Citrix MetaFrame Presentation Server 3.0:

  • Allow no more than 50 users per box.

  • Allow between 3 and 5 power users (3 power users = 30 regular users; 5 power users = 50 regular users).

  • Put all the servers on one subnet and hard code the server names into Citrix. Do not use the Citrix browser because it has difficulty browsing across networks.

  • Require all users to have mandatory profiles that are hardcoded and unchangeable.

Note:

The performance and tuning information is subject to change for later versions of Citrix. See the Citrix documentation for more information.

User Authentication

Users are authenticated by the database server at logon by default. For other authentication methods, see MetaSolv Solution Installation Guide.

Data Migration

This section is applicable only if you are upgrading from a pre-6.0.x version (for example, MSS 5.2) to 6.2.x. If you are moving to 6.2.x from a pre-6.0.x release, it may be necessary for you to perform a data migration especially if you used the Broadband Network Design module to design and provision ATM/Frame Relay and DSL. The Broadband module is obsolete as of 6.0, and customers who use the Broadband module must migrate using this migration utility or if you need the ability to set up your network elements and associate equipment to them.

Note:

If you have already completed the migration when upgrading to 6.0.x, you do not need to do this migration.

Two tools are available to assist with the migration effort:

  • Pre-Migration Analysis Tool (PMAT): This tool can be run against your pre-6.0 database to determine the amount of data that potentially may need to be converted. This include circuits (bandwidth, virtual, facilities, specials), product catalog, and orders. This tool is located on the Oracle software delivery Web site.

  • Next-Generation Migration Tool: This tool is part of MetaSolv Solution Utilities. This tool automates the process of migrating network elements, migrating network systems, migrating connections, and the circuit conversion to next gen connections and any related order conversion.

There are three main migration steps:

  • Network element migration: This step is optional because you can use MetaSolv Solution 6.2.x without migrating network element data. However, if you complete this migration, you receive enhanced functionality, such as the ability to group multiple pieces of equipment into one logical representation.

  • Network systems creation: Creates network systems network systems for networks designed using the Broadband module and make them available in the template-based Network Design module and associate elements to any network elements. The Network Design module enables you to design and provision ATM/Frame Relay and DSL.

  • Conversion: This step converts bandwidths, virtuals, facilities, and specials to a Next Gen Connection. It also converts Product Catalog and any orders using the old product catalog. In addition, if any design line reconciliation is needed, it can be done as part of this conversion.

Planning Tips

  • Your production application server and database server should be two different physical servers for the following reasons:

    • Two systems on the same machine can lead to performance issues and prevent both from operating at their optimum capacity.

    • If hardware issues are encountered, you must rebuild both the database and the application server before production activity is restored.

    • It is difficult to diagnose performance and network problems when both are on the same machine.

  • All client traffic, with the exception of client utilities, is routed through the application server. Therefore, to ensure continuous availability, Oracle recommends an environment that has a minimum of two production application servers. This configuration enables you to implement failover and load balancing functionality. See "Hardware Sizing Guidelines" for additional details based on users and transactions.

  • For nonproduction environments like training, testing, or development, it is possible to place multiple application servers on one physical server. This will reduce the overall cost of maintaining the MetaSolv Solution environment.

  • Consider the application server environment in your normal production maintenance plan. It should be customized, tuned, backed up, and monitored on a regular basis to ensure optimal performance. Make plans to archive logs and re-evaluate your configuration on an ongoing basis. If you leave the system running without oversight and maintenance, you will not get optimal performance.

  • The MetaSolv Solution client contains some functionality that is subject to network delays when run across a WAN. Where possible, end users should be located near the database and application servers.

  • Oracle systems can operate over a LAN or a WAN. The software initiates a significant amount of network traffic between the database server, the application server, and the Oracle client. In a LAN configuration, 100 MB delivers the best performance. If a WAN implementation is necessary, consider using a Citrix Terminal Server solution to reduce the amount of data being transmitted to and from the client.

  • To reduce latency in a WAN environment, deploy the database server, application server, and Citrix Terminal Server on the same LAN segment. This arrangement is necessary in a WAN configuration.

  • Separate the Oracle database files from the operating system files. Place Oracle program files and Oracle archive log files on different disks.

  • Do not allocate so much memory to the Oracle database and other applications that the operating system has to perform memory/disk swapping or paging. A good rule is to not allocate over half the amount of the machine's available physical memory.

  • Limit the database server to database-only use. If the operating system is being taxed by other resources, the Oracle database runs slowly no matter how well tuned your instance is.

  • For production, run only one instance of the Oracle database per machine. The more instances running on a machine, the harder it is to tune the instance with system resources.