Serverless Management Infrastructure for Heterogeneous Devices

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing system management platforms face complexity in supporting multiple generations of heterogeneous infrastructure due to varying API standards and implementation differences across hardware and firmware versions, leading to restricted device support and increased complexity.

Innovation Solution

A serverless system management solution using container images that map specific management operations to device and firmware versions, with a FaaS catalog and registry external to the management platform, allowing for onboarded management without external connectivity, utilizing an onboarding API to manage devices by retrieving manifests and pushing container images to a local registry.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If system management platforms support multiple generations of heterogeneous infrastructure with varying API standards, then device compatibility is improved, but platform complexity increases

Engineering Contradiction:
Improvedevice compatibilityVSAvoidplatform complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The platform is segmented into independent components: a core management platform and separate protocol adapter modules. Each adapter handles a specific protocol (Redfish, IPMI, SNMP, WS-Man), allowing the platform to support multiple protocols without increasing core complexity. The adapters are loaded dynamically based on device requirements.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Protocol adapter modules serve as intermediaries between the core management platform and devices using different protocols. These adapters translate device-specific protocols into a standardized internal format, allowing the core platform to remain simple while supporting heterogeneous infrastructure through the intermediary layer.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Device complexity

If system management platforms restrict supported devices to specific protocols or vendors, then platform complexity is reduced, but device support capability deteriorates

Engineering Contradiction:
Improveplatform complexityVSAvoiddevice support capability
Core Design Contradiction:
Device complexityVSAdaptability or versatility

Solution Approach 1:

The core management platform is designed with universal functionality to manage diverse devices through a standardized interface. Protocol adapter modules provide multi-functionality by supporting multiple protocols (Redfish, IPMI, SNMP, WS-Man), allowing a single platform to universally manage devices from different vendors and generations without increasing core complexity.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The platform dynamically loads and activates protocol adapter modules based on the specific device being managed. This dynamic adaptation allows the platform to maintain low complexity for each individual device while providing broad support capability across device types through on-demand protocol adaptation.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS20240264878A1Distributed deployment of serverless systems management infrastructure
Publication Date: 2024.08.08 DELL PROD LP
  • US20240264878A1 patent drawing
  • US20240264878A1 patent drawing
  • US20240264878A1 patent drawing

AI summary

A FaaS-based systems management method for implementing an onboarded management platform retrieves a manifest from a new or updated target device. The manifest indicates supported management operations and mapping coordinates for container images for performing management operations on the targeted device. Any unrecognized mappings in the manifest are added to a local FaaS mapping store and the target device is requested to push its container images to a local container registry. Communications with the target device may comply with an onboarding API that supports calls for retrieving the manifest and requesting the target device to push its container images to the local registry. An access credential token provided to the target device and included with the container images pushed to the local registry may enable the local registry to authenticate the container images. Verification that the local registry includes a container image for each mapping in the manifest may occur.