Architecture and Components
This article contains the following topics:
This article contains the following topics:
The architecture lets you quickly develop any required vendor-specific API plug-ins, named device packs, to collect the data directly from a device or from an Element Management System (EMS).
DX NetOpsenables deployment in a standalone or distributed architecture.
In a standalone deployment, the installation is usually performed on the management server being integrated. In a distributed deployment, the application is deployed across multiple servers to meet the high demands of current Communication Service Provider (CSP) environments.
The following diagram describes the general architecture of
DX NetOpsfor CA eHealth in a multiserver installation:
When you install DX NetOps Mediation Manager for Performance Management 2.3.4 or later in distributed systems,install the components of Performance Management and DX NetOps Mediation Manager as follows:
- Data Aggregator, Data Collector, and CA Performance Center in individual systems.
- Cert and Views respectively in the system that has Data Aggregator and CA Performance Center.
- CAPM Presenter and LocalController in every system that has a Data Collector.
- Primary MultiController in a system that has CA Performance Center.
- LocalController with Engine and Delivery Service in another system that has Data Aggregator.Install Primary MultiController and LocalController with Engine and Delivery Service in different systems based on the RAM and CPU sizes of the systems. If there is no sufficient memory, install Primary MultiController and LocalController with Engine and Delivery Service in individual systems.
The following diagram describes the general architecture of multiserver installation of
DX NetOpsfor Performance Management with two Data Collectors:
An extra component, the Generic Executor is not shown in both the diagrams, but is described in this document.
The components of
DX NetOpsinclude the following set of core software entities:
- Web Manager
- Generic Executor
- Delivery Service
The subcomponents of
DX NetOpsinclude the following entities:
- Presenter or CAPM Presenter
You can deploy up to two MultiControllers, primary and secondary, in a cluster. Deploy at least one MultiController per cluster. A MultiController performs the following actions in your cluster environment:
- Monitors heartbeat messages from LocalController components on remote servers.
- Acts as the centralized licensing server for the cluster.
- Stores centralized configuration files for components in the cluster.
Install one LocalController on each physical server in the cluster where a subcomponent (Engine or Presenter) resides. A LocalController performs the following actions:
- Communicates with the subcomponents that are installed on the server.
- Monitors heartbeat messages for subcomponents on the local server and automatically restarts subcomponents if they fail.
- Uses a delivery service to process output from the Engine. This service delivers XML documents in a compressed and encrypted format to a local or remote Presenter.
The Web Manager lets you manage the device pack deployment using its web-based interface. The interface displays the following information:
- Status of the running device packs.
- Status of the LocalControllers on which the device packs are installed.
- Status of the primary and secondary MultiController.
All components in a cluster share a common set of functions for communication and execution. The Generic Executor starts the Engine and Presenter subcomponents and cleans the temporary and log files.
The Generic Executor starts at system startup and listens on a specific TCP port. To start a component like the MultiController, the
DX NetOpsControl Utility, cammCtrl, sends a MultiController XML configuration file to the Generic Executor. When the Generic Executor receives this data, it identifies and starts the MultiController component using the information in the configuration file.
When an Engine finishes its poll cycle, it generates one or more
DX NetOps-standard XML documents in the queue directory. The Delivery Service monitors the queue directory independently and distributes the data to one or more local or remote Presenters. Delivery Service determines the correct Presenter by sending a request to the MultiController through the LocalController and identifies the IP address and TCP port of the Presenter. The Delivery Service does not process the queue until the local or remote Presenter becomes available.
The Engine is the main, threaded polling engine in
DX NetOps. You can deploy the Engine in the active or standby mode. The Engine performs the following actions:
- Gathers information from devices using XML, CSV, Telnet, SSH, and so on. The engine then processes the data to aDX NetOps-standard XML document.
- Deploys theDX NetOps-standard XML document to the queue for processing by the Delivery Service.
The Presenter is required only for
DX NetOpsfor eHealth and one Presenter is required for each device pack. It is a threaded presentation engine that performs the following actions:
- Receives theDX NetOps-standard XML document from the Engine.
- Formats the data to the required output format, such as CSV, XML, SNMP, and DDI.
The CAPM Presenter is required only for
DX NetOpsfor CA Performance Management. The CAPM Presenter must be installed in Data Collector that supports
DX NetOps. Similar to the Presenter, CAPM Presenter receives the
DX NetOps-standard XML document from the Engine. But, CAPM Presenter does not format the data to a required output format.
The number of CAPM Presenter depends on the number of complex device packs.