Every THING is Internet of Thing

IBM Edge Application Manager Overview

 
  • Akhilesh Moghe
  • Jan 28, 2022
  • Manages and deploys workloads from a management hub cluster to edge devices and remote instances of OpenShift Container Platform or other Kubernetes-based clusters.
  • IEAM is designed to harness the disciplines of hybrid cloud computing to support remote operations of edge computing facilities.

Architecture Overview

IEAM Overview

  • IAEM deployment includes a Management Hub that runs in an instance of OpenShift Container Platform installed in your data center.
  • The management hub manages of all of your remote edge nodes, be it edge devices and edge clusters.
  • The management hub minimize deployment risks and to manage the service software lifecycle on edge nodes fully autonomously.
  • edge nodes can be installed in remote on-premises locations to make your application workloads local to where your critical business operations physically occur, such as at your factories, warehouses, retail outlets, distribution centers, and more.
  • Software developers develop and publish edge services to the management hub.
  • Administrators define the deployment policies that control where edge services are deployed.

Components of IEAM

  • IBM Cloud Platform Common Services:
    • This is a set of foundational components that are installed automatically as part of the IEAM operator installation.
  • Agbot:
    • Agreement bot (agbot) instances are created centrally and are responsible for deploying workloads and machine learning models to IEAM.
  • Model Management System (MMS):
    • The MMS facilitates the storage, delivery, and security of models, data, and other metadata packages needed by edge services.
    • This enables edge nodes to easily send and receive models and metadata to and from the cloud.
    • This service can be useful for remotely updating the configuration of your Services in the field.
    • Enables you to dynamically push new versions of the models to your small edge machines in the field.
    • The MMS enables you to manage the lifecycle of data files on your edge node, remotely and independently from your code updates.
    • In general the MMS provides facilities for you to securely send any data files to and from your edge nodes.
    • The MMS runs in the IBM Edge Application Manager (IEAM) hub and on edge nodes.
    • The Cloud Sync Service(CSS), delivers models, metadata, or data to specific nodes or groups of nodes within an organization. After the objects are delivered to the edge nodes, an API is available that enables the edge service to obtain the models or data from the Edge Sync Service (ESS).
    • Objects are published in the MMS by service developers, devops administrators, and model authors, which makes them immediately available to edge nodes.
    • <>Integrity & Verification of Models</u>:
      • By default, integrity of the model is ensured by hashing and signing the model, and then uploading the signature and verification key before publishing the model.
      • The MMS uses the signature and key to verify that the uploaded model has not been tampered with.
      • This same procedure is also used when the MMS deploys the model to edge nodes.
    • IEAM also provides a CLI (hzn mms) that enables manipulation of the model objects and their metadata.
    • Several components make up the MMS: CSS, ESS, and objects.
      • CSS:
        • The CSS is deployed in the IEAM management hub when IEAM is installed.
        • The CSS uses the MongoDB database to store objects and maintain the status of each edge node.
      • ESS:
        • The ESS is embedded in the IEAM agent that runs on the edge node.
        • The ESS continually polls the CSS for object updates and stores any objects that are delivered to the node in a local database on the edge node.
        • ESS APIs can be used by services that are deployed on the edge node to access the metadata and data or model objects.
      • Objects (metadata and data):
        • Metadata describes your data models. An object is published to the MMS with metadata and data, or with metadata only.
    • Few MMS Commands:
      • Check the MMS status: hzn mms status
      • Create the MMS Object: hzn mms object new
      • Publish the MMS object: hzn mms object publish -m my_metadata.json -f my_model
      • List the MMS object: hzn mms object list --objectType=model --objectId=my_model
      • Delete the MMS object: hzn mms object delete --type=model --id=my_model
      • Update the MMS object: hzn mms object publish -m my_metadata.json -f my_updated_model
  • Exchange API:
    • The Exchange provides the REST API that holds all the definitions (patterns, policies, services, and so on) used by all the other components in IEAM.
    • It is the Centralized Service in IEAM.
  • Management console:
    • The web UI used by IEAM administrators to view and manage the other components of IEAM.
  • Secure Device Onboard:
    • The SDO component enables technology that is created by Intel to make it simple and secure to configure edge devices and associate them with an edge management hub.
  • Cluster Agent:
    • This is a container image, which is installed as an agent on edge clusters to enable node workload management by IEAM.
  • Device Agent:
    • This component is installed on edge devices to enable node workload management by IEAM.
  • Secrets Manager:
    • The Secrets Manager is the repository for secrets deployed to edge devices, enabling services to securely receive credentials used to authenticate to the cloud services.
    • A secret can be a userid/password, certificate, RSA key, or any other credential that grants access to a protected resource, which an edge application needs in order to perform it’s function. All these Secrets are stored in the Secrets Manager.
    • Administrator can access Secrete Manager using UI or CLI.
    • The Secrets Manager is a pluggable component of IEAM.
    • The details of every IEAM secret are composed of a key and a value. Both are stored as part of the details of the secret, and both can be set to any string value. The type of secret on the key and sensitive information as the value.
    • Currently, HashiCorp Vault is the only supported Secrets Manager.
      • HashiCorp Vault is a secrets management tool specifically designed to control access to sensitive credentials in a low-trust environment.
      • It has 2 versions:
        • Open-source - Self Managed
        • Cloud - Managed Vault - paid
    • Example: Hello Secret World Example

Edge Services

  • An edge service can let you create an associated deployment pattern, and register your edge nodes to run that deployment pattern.

Deployment Policies

  • IBM Edge Application Manager uses policies to determine where and when to autonomously deploy services and machine learning models.
  • Types of Policies:
    • Node Policy
    • Service Policy
    • Deployment Policy
    • Model Policy
  • Policies have mainly 2 attribute sections:
    • Properties
      • Node built-in properties
      • Server built-in properties
    • Constraints
  • There are few Policy Commands also, using which we can apply, revoke, list, update policies.
  • Further Reference: Deployment policy use cases

Deployment Patterns

  • Using a deployment pattern is a straightforward and simple way to deploy a service to your edge node.
  • You specify the top-level service, or multiple top-level services, to be deployed to your edge node and IEAM handles the rest, including the deployment of any dependent services your top-level service might have.
  • After you create and add a service to the IEAM exchange, you need to create a pattern.json file.
  • Further Reading: Using patterns

Developing edge services

Example Edge Services

  • Transform image to edge service
    • Demonstrates deploying an existing docker image as an edge service.
  • Creating your own hello world edge service
    • Demonstrates the basics of developing, testing, publishing, and deploying an edge service.
  • CPU to IBM Event Streams service
    • Demonstrates how to define edge service configuration parameters, specify that your edge service requires other edge services, and send data to a cloud data ingest service.
  • Hello world using model management
    • Demonstrates how to develop an edge service that uses the model management service. The model management service asynchronously provides file updates to edge services on edge nodes, for example to dynamically update a machine learning model each time it evolves.
  • Hello world using secrets
    • Demonstrates how to develop an edge service that uses secrets. Secrets are used to protect sensitive data like login credentials or private keys. Secrets are deployed securely to services running on the edge.
  • Updating an edge service with rollback
    • Demonstrates how to monitor the success of the deployment, and if it fails on any edge node, revert the node back to the previous version of the edge service.

Installation of IEAM Management Hub

Management hub installation flow

Sizing and system requirements

  • IEAM database considerations:
    • Local databases are installed (by default) as OpenShift resources onto your OpenShift cluster.
    • remote databases are databases that you provisioned, which can be on-premises, cloud provider SaaS offerings, and so on.
      • At a minimum, provision Remote databases with the following resources and settings:
      • 2vCPU’s
      • 2 GB of RAM
      • The default storage sizes mentioned in the previous section
      • For the PostgreSQL databases, 100 max_connections (which is typically the default)
  • IEAM local storage requirements:
    • Following are default settings for storage requirements:
    • PostgreSQL Exchange (Stores data for the Exchange, and fluctuates in size depending on usage, but the default storage setting can support up to the advertised limit of edge nodes)
      • 20 GB
    • PostgreSQL AgBot (Stores data for the AgBot, the default storage setting can support up to the advertised limit of edge nodes)
      • 20 GB
    • MongoDB Cloud Sync Service (Stores content for the Model Management Service (MMS)). Depending on the number and size of your models, you might want to modify this default allocation
      • 50 GB
    • Hashicorp Vault persistent volume (Stores secrets used by edge device services)
      • 10 GB (This volume size is not configurable)
    • Secure Device Onboarding persistent volume (Stores device ownership vouchers, device configuration options, and the deployment status of each device)
      • 1 GB (This volume size is not configurable)
  • Worker node sizing:
    • Minimal requirements for the default IEAM configuration:
    • Number of worker nodes = 3
    • vCPUs per worker node = 8
    • Memory per worker node (GB) = 32
    • Local disk storage per worker node (GB) = 100

Installing IEAM

  • Following components are deployed as installation IEAM:
    • IBM Cloud Platform Common Services 3.6.x.
    • IBM Edge Application Manager Management Hub operator.
    • IBM Edge Application Manager exchange API.
    • IBM Edge Application Manager agbot.
    • IBM Edge Application Manager Cloud Sync Service (CSS).
    • IBM Edge Application Manager user interface.
    • IBM Edge Application Manager Secure Device Onboarding (SDO).
    • IBM Edge Application Manager Secrets manager (Vault).
  • Further Installation Details:

Installing IEAM in an air gap environment

Upgrades of IEAM Management Hub

  • Upgrading the IEAM Management Hub is provided from the OCP web console for the cluster.
  • Further Details: Upgrades
  • Upgrading edge nodes:
    • Existing IEAM nodes do not upgrade automatically.
    • In order to upgrade the IBM Edge Application Manager agent on your edge devices and edge clusters, you first need to put the 4.3.0 edge node files into the Cloud Sync Service (CSS).
    • Further Details: Upgrades

Installation of Edge Devices

Installation of Edge Devices

Preparing an edge device

  • All edge devices (edge nodes) require the Horizon agent software to be installed.
  • The Horizon agent also depends upon Docker software.
  • Support:
    • Linux x86_64 devices
    • Ubuntu 20.x (focal), Ubuntu 18.x (bionic), Debian 10 (buster), Debian 9 (stretch)
    • Linux on ARM (32-bit)
      • Raspberry Pi, running Raspbian buster or stretch
    • Linux on ARM (64-bit)
      • NVIDIA Jetson Nano, TX1, or TX2, running Ubuntu 18.x (bionic)
    • MacOS
  • 100 MB random access memory (RAM)
  • 400 MB disk (including docker). Disk increases this amount based on the size of the container images
  • Further Details: Preparing an edge device

Installing and registering edge devices

  • Four different methods are provided to install the agent on and register edge devices, each is useful in different circumstances:
    • Automated agent installation and registration
      • Install and register one edge device with a minimum of steps.
      • First-time users should use this method.
    • Advanced manual agent installation and registration
      • Do each step yourself to install and register one edge device.
      • Use this method if you need to do something out of the ordinary and the script that is used in Method 1 does not have the required flexibility.
      • You can also use this method if you want to understand exactly what is required to set up an edge device.
      • Install Steps in brief:
        • Obtain the agentInstallFiles-<edge-device-type>.tar.gz file and the API Key that is created along with this file.
          • As a post-configuration step for Installing the management hub, a compressed file was created. This file contains the necessary files to install the Horizon agent on your edge device and register it with the helloworld example.
        • Copy this file to the edge device with a USB stick, the secure copy command, or another method.
        • Install Horizon install .deb file: apt update && apt install ./*horizon*.deb
        • Point your edge device horizon agent to your IBM Edge Application Manager cluster by populating /etc/default/horizon with the correct information.
        • Have the horizon agent trust agent-install.crt.
        • Restart the agent to pick up the changes to /etc/default/horizon.
        • Verify that the agent is running and correctly configured.
      • Edge Device Registration Steps in brief:
        • Set your specific information as environment variables: export HZN_EXCHANGE_USER_AUTH=iamapikey:<api-key>
        • View the list of sample edge service deployment patterns: hzn exchange pattern list IBM/
        • Register your edge device with Horizon to run the helloworld deployment pattern: hzn register -p IBM/pattern-ibm.helloworld
          • The node ID is shown in the output of above command in the line that starts with Using node ID.
        • The edge device will make an agreement with one of the Horizon agreement bots. hzn agreement list
        • After the agreement is made, list the docker container edge service that started as a result: sudo docker ps
        • View the helloworld edge service output: sudo hzn service log -f ibm.helloworld
    • Bulk agent installation and registration
      • Install and register many edge devices at one time.
    • SDO agent installation and registration
      • Automatic install with SDO devices.
  • Further Reading: Updating the agent

Installation of Edge Clusters

  • Manage and Deploy workloads from a management hub cluster to remote instances of OpenShift® Container Platform or other Kubernetes-based clusters.
  • IEAM deploys edge services to an edge cluster, via a Kubernetes operator, enabling the same autonomous deployment mechanisms used with edge devices.
  • The full power of Kubernetes as a container management platform is available for edge services that are deployed by IEAM. Installation of Edge Clusters

Preparing an edge cluster

Installing the agent from Edge Clusters

Uninstall the agent from Edge Clusters

References:
Search