This section includes the following topics:

In order to successfully install the Oracle Utilities Network Management System (and underlying environment), you must have a thorough understanding of the following:

In addition, you should have at least a cursory knowledge of the Oracle Utilities Network Management System architecture and applications functionality.

The Oracle Utilities Network Management System Quick Install Guide provides an overview of the Oracle Utilities Network Management System architecture and lists the supported hardware and software configurations. Verify that your system meets system requirements prior to attempting the Oracle Utilities Network Management System installation.

The Oracle RDBMS must be installed and configured before beginning the Oracle Utilities Network Management System. It must be installed on a server that is accessible from the Oracle Utilities Network Management System services applications. Time zone settings for the Oracle RDBMS and Oracle Utilities Network Management System services application must both be UTC. That is, on both the services machine and the database server, the TZ environment variable must be "UTC", and the database TIMEZONE value must be '+00:00'. These database and WebLogic instances should not be shared with any NMS installations running earlier versions of the code that did not yet support the UTC time zone.

Oracle recommends that any new installations should use the AL32UTF8 character set.

Refer to the “Database Configuration” chapter of the Oracle Utilities Network Management System Configuration Guide for more details regarding the installation and configuration of the Oracle RDBMS for use with the Oracle Utilities Network Management System applications.

Add the following to the init.ora of the NMS database:

To avoid restarting a database that is already running, you can do this command to make the change immediately:

The Oracle Utilities Network Management System requires that an installation of the Oracle Database Client software be made available in order to facilitate connections between the NMS services and the database. The installation must be the full installation of the Oracle Database Client software. The Instant Client package will not work, as it does not have all of the required libraries and binaries required by the NMS services.

The Oracle Utilities Network Management System requires the installation of a WebLogic Application Server. This installation should be done before installing the Oracle Utilities Network Management System software. Refer to Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server for instructions.

The Oracle Utilities Network Management System recommends installation of the Oracle Map Builder to simplify the process of creating and managing map, theme, and symbology metadata in the spatial database used to render spatial landbase maps. Oracle Map Builder is part of the Oracle Fusion Middleware MapViewer family of products, which is available for download from the Oracle Technology Network website (www.oracle.com/technetwork/).

The Oracle Utilities Network Management System supports the use of commercial web map servers for Viewer background landbases. It is up to each NMS customer to license with a web map provider for access to a web map service. NMS currently supports the following web map services:

The Oracle Utilities Network Management System and third party software files are compressed in the ZIP format. Most Linux/Unix-based platforms already have the binaries needed to unzip the distribution archives. An unzip utility is also included in the Oracle client under $ORACLE_HOME/bin.

Please refer to the Oracle Utilities Network Management System Security Guide for security overview, recommendations, and guidelines when installing Oracle Utilities Network Management System software.

Oracle Utilities Network Management System now uses OpenSSL to encrypt traffic between SwService (used in CVR and FLISR) and WebLogic server by default. As such, OpenSSL is now required to be installed with the operating system if you will be running SwService. The openssl binary as well as libssl and libcrypto are required.

To make them available, you will need to install the appropriate OS packages on your system:

Isis is the backbone of the Oracle Utilities Network Management System. It is the messaging bus through which all back-end NMS service components communicate.

On any computer using Isis it is important to have an accurate clock, which moves monotonically forward. Many approaches, such as rdate, can cause the clock to jump unpredictably, possibly backwards. This jumping is especially deleterious to Isis timing and timer queues, but can easily be avoided by using the Network Time Protocol (NTP) daemon, which is designed to gracefully synchronize the system clock with any reliable time source.

NTP is available for free on all operating systems and is simple to configure. Even if all of your services and applications run on a single computer, it is important to run NTP there. If you have several computers on the same LAN, you may want to consider running an NTP server (pointing to an external time source) on one of them and pointing all of the other NTP clients on the LAN to it. All NMS servers should be configured to be in the same timezone, and have their time synchronized with ntp, including all WebLogic servers.

Refer to the “Isis Configuration” chapter of the Oracle Utilities Network Management System Configuration Guide for more details regarding the configuration of the Isis message bus for use with the Oracle Utilities Network Management System applications.

Authorization and roles are stored in the database, but the authentication must come from an external source. No matter what the authentication source, each login name must be granted access to the system by using the Configuration Assistant. Active Directory and LDAP are supported authentication sources.

In order to perform well, NMS Services should not (even under load) be forced into any type of significant memory swapping situation where inadequate physical memory forces the operating system to “swap out/in” memory blocks from running processes since this can have a major negative impact on performance.

This section helps NMS implementers estimate how much physical memory and CPU the “significant” or “core” NMS Services might require for a production NMS instance. In this context, “significant” implies NMS Services that can be expected to consume more memory as the size of the model and/or model activity grows. Many NMS Services are essentially gateway processes and do not significantly grow in size regardless of model size and/or activity (for example, DBService processes). Special emphasis is granted to the NMS Services dedicated to advanced distribution management system (ADMS) processing since they can consume significant memory and CPU resources.

For NMS 2.6 and above, the NMS/ADMS Services have been separated into multiple NMS Service (daemon) processes. If a given NMS implementation is not using one or more of the noted services, that should be factored in when considering required memory. Keep in mind these are estimates and every NMS model is different, and can consume different amounts of memory. What you see below are averages.

Each of the NMS/ADMS Services consumes roughly the same amount of memory (2.2K memory per active NMS model component in the network components table). Notes and exceptions listed below:

With each of the above NMS/ADMS Services consuming roughly 2.2K memory per NMS network component this yields the full estimate of 11k per active NMS network component if all noted NMS/ADMS Services are in play. The NMS implementer must take into consideration which NMS/ADMS services are actually in play for a given NMS instance.

For a new NMS implementation you may have no idea how many NMS network components you may end up with. As a general rule of thumb, we can typically estimate roughly 1.5 NMS network components per meter if secondary is not modeled and 3 network components per meter if secondary is modeled.

Other core/significant NMS Services can also consume more memory based on the size of the NMS model, number of concurrent study sessions, and/or other activity. There are other specific factors involved (number of SCADA measurements, for example), but the following are rough memory estimates for the other core NMS Services that tend to grow significantly.

 

Example sizing for 1M meter customer:

 

2Mx1.5=3M network_components (estimated) – used for all other calculations below.

 

Note that NMS Services are typically not the only processes to run on these servers (project specific NMS adapters – for example) and thus an additional 5GB (minimum) should ALSO be allocated for the operating system and any other miscellaneous processes that may need to execute.

For an NMS instance to perform optimally under load also requires adequate CPU for the NMS Service (daemon) processes. If NMS daemon processes are consistently waiting for CPU – the system will not perform optimally. Note that a CPU in the context of this discussion is not a hyper-thread – but a “full” CPU. Note Unix utilities like “top” show hyper-threads, and there are typically two hyper-threads per full CPU. Also, for NMS performance in general, a few (faster) CPUs for the NMS Services tier will significantly outperform many (slower) CPUs as several NMS Services process at least certain parts of requests serially. Some guidance on CPU consumption is provided here.

For a 1M meter NMS model, under storm load, MTService, DDService and JMService will tend to consume roughly 1 full CPU each. The “other” NMS Services will tend to consume roughly 1 additional CPU between them (on average) for a total of 4 full CPUs dedicated to NMS/OMS processing. This assumes the RDBMS and WebLogic components are on separate servers. For larger NMS models beyond 1M meters, for each additional 1M meters, an additional CPU is recommended. The operating system and project specific adapters will often consume at least one or two additional CPUs – for a total of 6 (for example) for a 2M meter NMS model.

For a 1M meter NMS model the PFService and FLMService processes will tend to consume at least 1 CPU each, with FLTService, VVOService consuming at least another CPU between them (3 total CPUs). PFService and FLMService can also be configured to be “more multi-threaded” than most NMS processes and can be configured to consume up to 4 CPUs (each) under certain loads. As the NMS model size increases it may become more necessary to enable this additional parallel processing to ensure more consistent (performant) results to end users. Thus, for each additional 1M meters beyond 1M meters, it is recommended you add an additional CPU for ADMS processing. Thus, for a 2M meter model running all ADMS modules, suggest 4->8 CPUs just for ADMS.

Note EMService will also tend to consume a CPU but it is a non-production process so this load only needs to be accounted for on non-prod (training) environments. However, since they are not production environments, it is not generally necessary to add additional CPU to accommodate EMService – but additional memory may still be required.

For a 2M meter customer model (with all NMS modules), we would end up with at least 4->6 CPUs for NMS/OMS and at least 4 more CPUs for ADMS for a total of at least 10 (full) CPUs – up to 14 CPUs if you want to push NMS/ADMS multi-threading.