CORBA Collector

The CORBA Collector microservice collects Multi-Technology Network Management (MTNM) Common Object Request Broker Architecture (CORBA) events from external Element Management Systems (EMS) and converts them to Unified Assurance events for further processing.

This microservice is part of the Event microservice pipeline. See Understanding the Event Pipeline in Unified Assurance Concepts for conceptual information.

You can enable redundancy for this microservice when you deploy it. See Configuring Microservice Redundancy for general information.

CORBA Collector Prerequisites

Before deploying the microservice, confirm that the following prerequisites are met:

1. A microservice cluster is set up. See Microservice Cluster Setup.

2. The following microservices are installed:

   • Pulsar

   • FCOM Processor

   • Event Sink

3. You know the URI for your CORBA server.

4. You have created a Kubernetes secret containing the EMS username and password by running the following command as the assure1 user:

   a1k create secret generic <release-name>-secret --from-literal=emsUserName=<username> --from-literal=emsPwd='<password>' -n <namespace>
   

   where:

   • <release-name> is the release name you will use for the CORBA collector microservice deployment. This is generally corba-collector.

   • <username> is the EMS username.

   • <password> is the EMS password.

   • <namespace> is the namespace.

5. If your EMS server is SSL-enabled, you have created a Kubernetes secret for it. To create the secret:

   1. Export the SSL certificate bundle from your EMS server.

   2. Run the following command to create a secret for the exported certificate bundle:

      a1k create secret generic <release-name>-ems-secret  --from-file=<filepath>/<CertificateBundleName>.crt -n <namespace>
      

      where:

      • <filepath> is the path to the directory where you stored the EMS certificate bundle. For example, $A1BASEDIR/etc/ssl.

      • <CertificateBundleName> is the name of the certificate bundle. For example, EmsBundle.crt.

      • <namespace> is the namespace where you will deploy the CORBA Collector microservice. Typically this is a1-zoneX-pri, where X is the zone ID, but if you are deploying a redundant microservice to the secondary cluster, this will be a1-zoneX-sec.

Deploying CORBA Collector

To deploy the microservice in a single server environment, run the following commands:

su - assure1
export NAMESPACE=<namespace>
export WEBFQDN=<WebFQDN> 
a1helm install <microservice-release-name> assure1/corba-collector -n $NAMESPACE --set global.imageRegistry=$WEBFQDN --set configData.CORBA_EMS_TLS_CA=<CertificateBundleName>.crt

In a multi-server environment, deploy the CORBA Collector microservice to a specific node by running the following commands:

su - assure1
export NAMESPACE=<namespace>
export WEBFQDN=<WebFQDN>
export NODEFQDN=<NodeFQDN>
a1helm install <microservice-release-name> assure1/corba-collector -n $NAMESPACE --set global.imageRegistry=$WEBFQDN --set nodeSelector."kubernetes\.io/hostname"=$NODEFQDN --set configData.CORBA_EMS_TLS_CA=<CertificateBundleName>.crt

In the commands:

• <namespace> is the namespace where you are deploying the microservice. The default namespace is a1-zone1-pri, but you can change the zone number and, when deploying to a redundant cluster, change pri to sec.

• <WebFQDN> is the fully-qualified domain name of the primary presentation server for the cluster.

• <NodeFQDN> is the FQDN of the cluster node to deploy the microservice to.

• <microservice-release-name> is the name to use for the microservice instance. Oracle recommends using the microservice name (corba-collector) unless you are deploying multiple instances of the microservice to the same cluster.

By default, SSL support is enabled, and there is no default value for the CORBA_EMS_TLS_CA parameter. You must set this parameter. If SSL support is not required, disable it by adding --set configData.CORBA_EMS_TLS_ENABLED=false and omitting the CORBA_EMS_TLS_CA parameter. For example:

a1helm install corba-collector assure1/corba-collector -n $NAMESPACE --set global.imageRegistry=$WEBFQDN --set configData.CORBA_EMS_TLS_ENABLED=false

You can also use the Unified Assurance UI to deploy microservices. See Deploying a Microservice by Using the UI for more information.

Changing CORBA Collector Configuration Parameters

When running the install command, you can optionally change default configuration parameter values by including them in the command with additional --set arguments. You can add as many additional --set arguments as you need.

For example:

• Set a parameter described in Default CORBA Collector Configuration by adding --set configData.<parameter_name>=<parameter_value>. For example, --set configData.LOG_LEVEL=DEBUG.

• Enable redundancy for the microservice by adding --set redundancy.enabled=true.

Default CORBA Collector Configuration

The following table describes the default configuration parameters found in the Helm chart under configData for the microservice.

CORBA Collector Flow

CORBA messages are collected and processed by the CORBA Collector as follows:

1. The CORBA Collector loads connection details from environment variables and connects to the EMS.

2. The EMS sends CORBA events to the CORBA Collector.

3. The CORBA Collector transforms the events from StructuredEvent Java objects to Unified Assurance collection events.

4. The CORBA Collector sends the transformed events to the Pulsar assure1/event/collection topic.

5. The topic sends the event to the FCOM Processor microservice to be normalized and inserted into the Event database.

6. A Unified Assurance user can view and manage the events in the user interface.

CORBA Event Details

The following event types are supported:

• NT_ALARM

• NT_TCA

You can choose either one or both of these by setting the CORBA_NOTIFICATION_TYPES microservice configuration parameter as shown in Default CORBA Collector Configuration.

The CORBA Collector supports any vendor with the TMF MTNM standard of NT_ALARM and NT_TCA. It consumes events that conform to the TMF814 specification, with the following vendor-identified fixes:

• In CosNotification.idl, struct EventType is modified to struct _EventType.

• In FlowDomain.idl, the getFDFrVRFs, getAllVRFs, and getAllStaticRoutings methods are deleted.

To download the entire TMF814 specification, see the TMF814 Multi-Technology Network Management (MTNM) Solution Set– IDL Version IIS R3.5 on the TM Forum website.

Example CORBA Event

The following example shows an incoming CORBA event that would be accepted by the CORBA Collector.

name: notificationId value: 1
name: objectName value:
    name: EMS value:ExampleEMS
    name: ManagedElement value:ExampleElement
name: nativeEMSName value:ExampleEMSName
name: objectType value:OT_MANAGED_ELEMENT
name: emsTime value:20230828124734.0
name: neTime value:20230828124734.0
name: isClearable value:TRUE
name: layerRate value:15
name: perceivedSeverity value:PS_MAJOR
name: nativeProbableCause value:Disconnection
name: probableCause value:EMS
name: probableCauseQualifier value:
name: serviceAffecting value:SA_UNKNOWN
name: affectedTPList value:
name: rcaiIndicator value:FALSE
name: additionalText value:
name: additionalInfo value:
    name: LSNExt_AckStatus value:ALM_UNACKNOWLEDGED
    name: LSNExt_MEName value:ExampleEMSName
    name: LSNExt_ALCV value:Unknown
    name: LSNExt_AlarmUniqueString value: EMS DN=ExampleEMSDN, EMS notifId=Not Relevant, CAM ID=1234567
    name: LSNExt_GroupName value: ExampleGroupName

After processing by the CORBA Collector, the event would look as follows:

{
    "@timestamp": "<timestamp>",
    "_agents": [{
        "@timestamp": "<timestamp>",
        "host": "<hostname>",
        "app": "corba-collector",
        "version": "5.0.0",
        "input": "<EMS Connection url>",
        "output": "persistent://assure1/event/collection",
        "id": "<POD Name>",
        "cluster": "<Cluster Name>",
        "node": "<Node Name>"
    }],
    "_domain": "tmf_mtnm",
    "_type": "corba",
    "corba": {
        "rcaiIndicator": "false",
        "probableCauseQualifier": "",
        "serviceAffecting": "SA_UNKNOWN",
        "additionalText": "",
        "neTime": "20230828124734.0",
        "emsTime": "20230828124734.0",
        "corbaEventType": "VendorName",
        "objectType": "OT_MANAGED_ELEMENT",
        "perceivedSeverity": "PS_MAJOR",
        "probableCause": "EMS",
        "nativeEMSName": "ExampleEMSName",
        "layerRate": "15",
        "nativeProbableCause": "Disconnection",
        "additionalInfo": {
            "LSNExt_GroupName": "ExampleGroupName",
            "LSNExt_MEName": "ExampleEMSName",
            "LSNExt_ALCV": "Unknown",
            "LSNExt_AckStatus": "ALM_UNACKNOWLEDGED",
            "LSNExt_AlarmUniqueString": "EMS DN=ExampleEMSDN, EMS notifId=Not Relevant, CAM ID=1234567"
        },
        "objectName": {
            "ManagedElement": "ExampleElement",
            "EMS": "ExampleEMS"
        },
        "eventTypeName": "NT_ALARM",
        "notificationId": "1",
        "isClearable": "true",
        "affectedTPList": ""
    }
}

The value of corbaEventType is mapped from the CORBA_EMS_VENDOR configuration variable and helps match the rule for event processing in the FCOM processor.

CORBA Foundation Rules

To see the default foundation rules for CORBA, as well as the rules for Ribbon (formerly ECI) and Tejas:

1. Log in to the Unified Assurance UI.

2. From the Configuration Menu, select Rules, then expand the following folders:

   Core Rules (core)/Default read-write branch (default)/processing/event/fcom/_objects/corba

You can customize these rules for your environment and vendors.

See Foundation Rules for general information about foundation rules and Rules in Unified Assurance User's Guide for more information about using the Configuration interface.

Customizing the Default CORBA Foundation Rules and the Vendor Rules

To customize the CORBA foundation rules:

1. In a browser, log in to the Unified Assurance user interface.

2. From the Configuration menu, select Rules.

3. Expand the following folders:

   Core Rules (core)/Default read-write branch (default)/processing/event/fcom/_objects/corba

4. Customize the rules in default/DEFAULT-CORBA.json and the vendor-specific JSON files in the vendor-specific folders.

5. Delete the existing deployment of the FCOM Processor microservice and redeploy it.

Troubleshooting

If you can't connect to the CORBA URI configured in the STREAM_INPUT configuration parameter, do the following:

1. Open the Helm chart for the CORBA Collector microservice.

2. Add the following code to the Helm deployment at the end of the Helm Chart:

   hostAliases:
   - ip: <ip>
     hostnames:
     - <hostname>
   

   where <ip> and <hostname> are the IP and host name for the CORBA URI.

3. Redeploy the CORBA Collector microservice.

About CORBA Collector Redundancy

By default, redundancy is not enabled. You can enable it as described in Deploying CORBA Collector.

Because of limitations related to EMS session management, you can only establish one session for each EMS instance. The following redundancy use cases are supported:

• Failover:

  • The primary pod is evicted due to resource unavailability:

    • Kubernetes tries to respin the pod within milliseconds.

    • If the resources become available, the primary pod is brought back up to continue receiving events.

    • If the resources are not available, the primary pod's status is set to pending and the secondary pod starts receiving the events until the resources can be allocated to the primary again.

  • The primary pod can't reach the network:

    • The primary pod keeps trying to connect to the EMS.

    • If the primary pod is unable to establish a connection after a certain number of retries, it updates a metric which lets the secondary pod know of the connection failure.

    • The secondary pod then establishes the connection with the EMS and continues processing the events until the primary pod network issue is resolved.

  • The primary pod and the secondary pod can't reach each other, also known as the split brain scenario:

    • The primary pod is up and actively receiving events, but the redundancy poller does not receive a response from the primary pod and starts failover.

    • Since the primary pod has already established the session, the secondary pod will not be able to acquire it. It will exhaust the number of retries available before it terminates.

  • The connection between the EMS and the active subscribers is broken, even though there are active sessions:

    • The event listener is not able to receive any events.

    • This is related to active monitoring of pods and of events received by Unified Assurance. In such cases, you should restart the pods manually.

• Fallback to primary:

  • The primary is up and, as part of the initialization, the metrics endpoint is active:

    • The primary tries to establish a session for the EMS instance, but it gets an exception as the secondary already has an active session.

    • The secondary poller verifies and starts the fallback process by releasing all session resources.

    • By the time the primary retries establishing the EMS session for the second time, it will be available to acquire and establish the connection.

In situations where multiple users are available for the primary and secondary pod, you must create secrets of the same name separately in both clusters. Each pod running in the cluster will pick up their respective username and password to establish the connection to the EMS. A split brain scenario with multiple users may result in duplicate records, which is a known issue across all the Unified Assurance microservices.

For general information about redundancy in microservices, see Cross-Data Center Redundancy in Unified Assurance Concepts.