Resource Manager¶
By default, containerized applications run in a sandboxed environment that prevents direct access to an edge device's hardware resources, such as GPUs or I/O interfaces. While this type of isolation minimizes the risk of unwanted effects, it also prevents apps from using these resources to accelerate machine learning applications or communicate with specialized field devices, for example. To solve this problem, Industrial Edge allows controlled access to selected resources via the Resource Manager. The Resource Manager tab described below provides an overview of available resources, including their status, and allows them to be configured.
Introduction¶
Generally speaking, each resource class may include multiple resource instances representing individual CPU cores, network interfaces, GPUs or the like.
Industrial Edge's Resource Manager takes care of the following tasks:
- Assign resource instances to apps at startup depending on their demands.
- Ensure that instances in use are not utilized by other apps in the system.
- Display for each instance its availability as well as health status.
- The "Usage" column indicates whether the resource is shared or exclusive. A resource instance with shared usage can be shared by multiple applications, while a resource instance with exclusive usage can only be used by a single application. Each application specifies whether it wants a shared or exclusive resource.
- Release claimed instances when apps are stopped.
More information can be found in the resource manager documentation for device builders and app developers.
Resource Classes¶
CPU Cores¶
Industrial Edge apps can claim selected CPU cores for exclusive use. Having such isolated CPU cores is typically required by real-time applications to avoid (temporal) interferences with other processes. The screenshot below shows a system with four CPU cores, where one core (core0) is statically reserved for housekeeping tasks. This results in three cores that are currently free and can be occupied by an app exclusively (core1-3).
In addition to the brief description shown in the overview, users can obtain more information by clicking on the
icon in the "Metadata" column of the respective resource.
NOTICE
Displaying metadata requires at least version of IEDK: 1.19.0-1.
Configuration¶
To always leave certain CPU cores—in the following simply referred to as CPUs according to Linux conventions—for general-purpose tasks, they can be excluded from the set of isolatable CPUs.
This is accomplished using the field "System (housekeeping) CPU set" in the configuration section, which takes as input a comma-separated list of integers or ranges, e.g., 0,2-4.
The other two fields are defined by device builders, and their values cannot be changed via the UI:
- The statically configured system (housekeeping) CPU set is merged with the corresponding user-defined value. They are, however, used to run Industrial Edge apps that don't require isolation.
- The statically configured to-ignore CPUs are not touched by Industrial Edge altogether.
NOTICE
Changing the configuration requires a system reboot, as the CPU isolation services depend on these values.
Network Interfaces¶
Similar to CPU core isolation, network interfaces can be claimed by applications for exclusive use. This way, applications can implement real-time capable network stacks like Profinet or get access to a PTP clock associated with a network interface.
As with CPU cores, users can view more detailed information about a network interface by clicking the
icon in the "Metadata" column.
NOTICE
Displaying metadata requires at least version of IEDK: 1.19.0-1.
Configuration¶
| Number | Description |
|---|---|
| ① | Add network interfaces |
| ② | Add annotation |
| ③ | Delete annotation |
| ④ | Delete network interface |
The user interface allows isolatable interfaces to be added with control ①, isolatable interfaces to be removed with control ④, annotations be added with control ②, and annotations be removed with control ③.
The Isolatable networks section specifies a set of network interfaces that can be claimed exclusively by Industrial Edge apps.
Each isolatable network interface is identified by the network interface name as assigned by the host system.
The network interface names on the host system are also listed in the network settings user interface and can be used as a reference.
In order to map network interfaces to applications, a labeling mechanism is used. Applications claim network interfaces based on labels stated in their application manifests. The edge operator is responsible for annotating the isolatable interfaces with labels. Whenever an application starts and is claiming an isolated interface, it will obtain one of the interfaces labeled correspondingly.
Each interface can be annotated with multiple labels, since each network interface can be connected to multiple different networks. In order to direct the application traffic to the correct network depending on which applications obtains the interface, a vlan tag can be specified per label. If no vlan tag is specified or a vlan id 0, then no vlan tagging of the outgoing packets is taking place on that interface. Also, multiple interfaces can be annotated with the same label, since multiple interfaces can potentially be connected to the same network. An application claiming an isolated network based on such a label will obtain any one of the interfaces labeled accordingly.
In order to persist configuration changes, the operator has to submit them. Any submitted configuration changes are picked up by the plugin right away and do not require a reboot. Edge operators are allowed to remove network interfaces from the list of isolatable interfaces, even while interfaces are claimed by apps. The plugin will then still report the interface in the user interface albeit as unhealthy. This unhealthy state indidcates that the interface can no longer be isolated even after release. The unhealthy interface will disappear from the list of resources at the latest on reboot. For a clean workflow, we recommend to stop applications before removing their corresponding resources from the configuration. If the interface is not claimed and removed by the operator from the configuration, it will disappear right away from the user interface. The plugin also allows non-existent network interface names to be added to the list of isolatable interfaces, for example, to allow network cards to be temporarily removed without having to change the configuration before or afterwards.
NOTICE
When operators apply configuration changes to network interfaces which are currently isolated like deleting the interface or changing its annotations, a warning dialog will be displayed when clicking the submit button.
NOTICE
Operators should add network interfaces and annotations before installing an application using isolated networks. Otherwise, the installation will fail.
Graphics Processing Units (GPUs)¶
Industrial Edge's GPU plugin enables apps to make use of GPUs available in the Edge Device. The screenshot below shows a system with one Nvidia GPU, which is not occupied by an app. At present, there are no configuration options for GPUs.
Shared Memory¶
Industrial Edge's Shared Memory plugin allows Industrial Edge apps to manage shared memory resources. The plugin mainly enumerates shared memory resources and communicates allocated shared memory resources to the applications.
| Number | Description |
|---|---|
| ① | Add shared memory |
| ② | Add label |
| ③ | Delete label |
| ④ | Delete shared memory |
The shared_memories field specifies an array of shared memory resources that can be claimed by Industrial Edge applications. Each shared memory resource has a field name denoting the shared memory name, a field size_in_mb in MB denoting the size of the shared memory filesystem in megabytes, an optional labels field listing labels associated with the shared memory and an acl field for access control. The labels identify applications that can use the shared memory. The label is obtained from the created shared memory resource. Additionally, applications must include this label if they want to access the shared memory resources.
The access control list field (acl) is an array of entries for whitelisting which applications can request which permissions. Each entry of the acl array has three fields: application_id, the optional field containing the Industrial Edge application id string, service_name an optional string to restrict the acl entry to a certain service name within the given application and permissions a mandatory array of permission strings for which access should be granted.
The field application_id can be omitted or left blank, in which case the acl entry will apply to all applications. The currently supported permission strings are ro and rw for read-only and read-write access.
NOTICE
The rw permission string implies ro permission: Any application which is allowed rw per acl entry, can also claim ro access in the config section in resource claims. So it enough to use permissions: ["rw"] instead of permissions: ["rw", "ro"].
A typical acl configuration to allow read-write access to the application with id zBnbv3HeXi3GDK3LS28hTSSHYyIA1Cm4 and grant read-only access to all other applications looks like
name: shm1
labels: ["shm1label"]
size_in_mb: 5
acl:
- { application_id: "zBnbv3HeXi3GDK3LS28hTSSHYyIA1Cm4", permissions: ["rw"] }
- { permissions: ["ro"] }
NOTICE
If there is no acl field this means that there is no access control, while acl: [] means no access is allowed.
# access-control disabled: all apps can access the 'shm1' resource
name: shm1
labels: ["shm1label"]
size_in_mb: 5
# access-control enabled: but no app can access the 'shm1' resource
name: shm1
labels: ["shm1label"]
size_in_mb: 5
acl: []
GPIO Chips¶
Industrial Edge apps can access General Purpose I/O (GPIO) chips present in the Edge Device using the GPIO plugin.
In addition to the brief description shown in the overview, users can obtain more information by clicking on the
icon in the "Metadata" column of the respective resource. The metadata includes line offsets and labels, which can be useful information when configuring applications.
NOTICE
Displaying metadata requires at least version of IEDK: 1.19.0-1.
Configuration¶
In order to map GPIO chips to applications, a labeling mechanism is used. Applications claim GPIO chips based on labels stated in their application manifests. The edge operator is responsible for annotating the GPIO resources in the Edge device with labels. Changes to the resource labels take effect immediately upon submitting the form; no reboot is required.
Whenever an application starts and is claiming a GPIO chip, it will obtain one of the resources labeled accordingly. It is possible to change or remove resources labels while the corresponding GPIO chip is occupied; this has no effect on the running apps.
NOTICE
Operators should add GPIO resource labels before installing an application using the corresponding GPIO chip. Otherwise, the installation will fail.