Cloud Connect Core

The Cloud Connect Core is deployed as part of the EDA deployment itself. It lives as an application in EDA and handles the configuration of EDA resources based on the needs of the compute environments, provided through the different plugins.

Installation

Cloud Connect is an application in the EDA app eco-system. It can be easily installed using the App Store UI.

Installation using Kubernetes API

If you prefer installing the Connect Core using the Kubernetes API, you can do so by creating the following Workflow resource: 

apiVersion: core.eda.nokia.com/v1 
kind: Workflow 
metadata: 
  name: connect-nokia 
  namespace: eda-system 
spec: 
  input: 
    app: connect 
    catalog: eda-catalog-builtin-apps 
    operation: install 
    vendor: nokia 
    version: 
      type: semver 
      value: v2.0.0 
  type: app-installer

Resources

Connect is based on a pluggable architecture. The Cloud Connect core installation is a collection of controllers responsible for bridging the hypervisor world with the fabric world. It is the plugin that is responsible for introspecting the cloud environment.

The following Custom Resources are involved:
Table 1. Custom Resources
Custom Resources Description
ConnectPlugin

The logical representation of the plugin, created for each plugin automatically when the plugin starts with valid credentials.

ConnectPluginActionable

An actionable is an action to be taken by the ConnectPlugin. It is used by the Core to tell the plugin to do something (for example: initiate an Audit).
ConnectPluginHeartbeat

The ConnectPlugin will continuously send heartbeats to the Cloud Connect service to report its status and alarms.
ConnectInterface

The logical representation of a hypervisor NIC and/or LAG. The labels on the ConnectInterface are used to label the EDA interface (leaf interface) correctly so that the correct subinterfaces are created.

Plugins

Plugins are a core component of the Event Driven Automation (EDA) Connect environment. In the Connect environment, a plugin represents the component that communicates with the external cloud services. The following plugins are supported by EDA, and are further documented in their respective sections:

Plugins are automatically registered within the Connect service when they are deployed. Each is stored in the database with the following main properties:

Table 2. Plugin properties
Plugin property Description
Name

A unique name based on the plugin type and compute environment it is connected to.
Plugin Type

The type of plugin, for example, VMware or OpenShift.
Heartbeat Interval

The interval, in seconds, between heartbeats that the plugin intends to use.
Supported actions

The different actions a plugin can support. These are actions the Core can request the plugin to do. For example, to trigger an Audit.

Heartbeats

When plugins register with the Connect core service, they can indicate that they support heartbeats. When a plugin supports heartbeats, the plugin is expected to send a heartbeat to the Connect core service at an interval of the configured value (or more frequently). If the Connect core does not receive a heartbeat from the plugin after two intervals, it raises an alarm in EDA to indicate that there could be an issue with the plugin.

Connect interfaces

Connect interfaces are managed by the plugins and represent the network interfaces of a compute node. When a plugin notices a new compute or new network interface on a compute node, it will create a Connect interface in EDA for Connect Core to monitor.

Connect Core uses the information from the Connect interface to determine the matching EDA interface. This is the interface on a leaf managed by EDA to which the interface on the compute is connected to, or potentially multiple interfaces in case of a LAG or Bond.

The plugin will label these Connect interfaces to indicate that Connect Core needs to make sure the matching leaf interfaces have a subinterface created in the corresponding overlay service (bridge domain).

This way, only those subinterfaces that are truly necessary are configured in the fabric. This limits configuration bloat and possible security risks.

Namespace support

The EDA Connect service supports multiple namespaces. Multiple namespaces are supported on the level of the plugin.

A plugin is a namespaced object, meaning that it must be created as part of a specific namespace. That plugin will only have access to the fabrics, services and interfaces of that namespace and cannot use objects from other namespaces.

This also means that a compute cluster can only belong to a single namespace, and cannot span multiple namespaces. This is to be expected as compute clusters belong to a single fabric, and a fabric is part of a single namespace.

Connect UI

The Connect UI can be found as part of the System Administrator section of the EDA UI, and allows for inspection of the different resources owned and managed by Connect. This Connect UI follows the same design as the regular EDA UI, where the left menu for Connect opens and displays the different resources available.

Note:

Do not create new resources manually, as this could interfere with the behavior of the plugins.

Connect integration modes

Integration modes define how plugins create resources in EDA for use by the applications in the compute environments.

Connect supports two integration modes:

  • CMS-managed mode

    Networking concepts of the CMS are used to create new services in EDA.

  • EDA-managed mode

    Network services are created in EDA and the networking concepts in the CMS are linked or associated with these pre-existing services.

Each of these modes can be used by the plugins. For the plugins provided by Nokia, both modes are supported, and you can combine them and switch between them as needed. For instance, you can use one integration mode for one application, while using the other for another application.

CMS-managed integration mode

In the Cloud Management mode, Connect creates an EDA bridge domain for each subnet that is created in the Cloud Management system. In this mode, the changes in the Cloud Management system are transparently reflected into EDA. The administrator of the Cloud Management system does not require any knowledge about how to use EDA.

EDA-managed integration mode

For more advanced use cases, a more complex EVPN Service (or set of services) may be needed. This can include features of these services that are supported by EDA, but not natively by the CMS. Examples are configuring complex routing or QoS policies, or using BGP PE/CE for route advertisement from the application into the network service.

In such cases, Nokia recommends using the EDA-managed integration mode, which instructs Connect to associate the subnets in the CMS with existing bridge domains in EDA, instead of creating new resources in EDA based on the cloud management networking.

In this mode, an administrator (or orchestration engine) with knowledge of EDA first creates the necessary resources in EDA directly. You can create more complex configurations than the cloud management system itself would be able to do. When creating the networking constructs in the Cloud Management system, you provide a set of unique identifiers referring to those pre-created networking constructs. This way, the Connect plugin and Connect service know not to create their own resources, but to use the pre-created items.

Troubleshooting

Missing ConnectPlugin for deployed plugin

If a plugin does not show up in the list of ConnectPlugins, it indicates a connection problem from the plugin toward the EDA Kubernetes cluster.

Verify the following information:

  • Check the plugin logs for error messages.
  • Verify the plugin's configuration, especially the Kubernetes information (location/url, certificates, user certificates and so on).

Application connectivity

An application missing connectivity can have multiple causes. The following are some of the most common causes:

  • Check whether there are any alarms reported in EDA.
  • Check whether there are any TransactionResults in FAILED state.
  • Check whether BridgeDomain and VLAN are up, and VLAN is showing the expected number of UP subinterfaces.
  • Check the ConnectInterface corresponding to the compute node NIC where you expect to see traffic.
    • If no ConnectInterface can be found, check the plugin. It is responsible for creating the ConnectInterface.
      Note: The Connect interface is located in the namespace of the Fabric.
    • If a ConnectInterface can be found, check the status.
      • If the status is blank the connect-interface-controller is not online.
      • If the status is Disconnected it cannot find an EDA interface to label.
  • Check the EDA interface corresponding to the NIC on the SRL that is connected to the relevant compute node.
    • If it is not found: operator has to create the "downlink" interfaces
    • If it is found: check the status
      • If no members with the LLDP info are found, check the LLDP process on the compute node and on the SRL node.