Architecture and Components

This article contains the following topics:
camm31
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 NetOps
enables 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 NetOps
for CA eHealth in a multiserver installation:
DX NetOps Mediation Manager architecture--XML
CA Mediation Manager architecture--XML
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 NetOps
for Performance Management with two Data Collectors:
DX NetOps MM for PM in 4 Systems
CAMM for PM in 4 Systems
An extra component, the Generic Executor is not shown in both the diagrams, but is described in this document.
The components of
DX NetOps
include the following set of core software entities:
  • MultiController
  • LocalController
  • Web Manager
  • Generic Executor
  • Delivery Service
The subcomponents of
DX NetOps
include the following entities:
  • Engine
  • Presenter or CAPM Presenter
MultiController
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.
LocalController
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.
Web Manager
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.
Generic Executor
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 NetOps
Control 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.
Delivery Service
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.
Engine
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 a
    DX NetOps
    -standard XML document.
  • Deploys the
    DX NetOps
    -standard XML document to the queue for processing by the Delivery Service.
Presenter
The Presenter is required only for
DX NetOps
for eHealth and one Presenter is required for each device pack. It is a threaded presentation engine that performs the following actions:
  • Receives the
    DX NetOps
    -standard XML document from the Engine.
  • Formats the data to the required output format, such as CSV, XML, SNMP, and DDI.
CAPM Presenter
The CAPM Presenter is required only for
DX NetOps
for 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.