DPS Architecture#

Overview#

The Dynamic Power Software (DPS) is a power management solution designed as a cloud-native Kubernetes service. This document describes the overall architecture, core components, deployment model, and system integrations that make up the DPS ecosystem.

DPS provides centralized power management for datacenter infrastructure through a microservices architecture deployed on Kubernetes. The system manages power policies, monitors consumption, and controls hardware through standardized protocols.

Key Architectural Principles#

  • Cloud-Native Design: Built for Kubernetes deployment with containerized microservices

  • API-First Architecture: All functionality exposed through gRPC APIs with HTTP/REST gateway

  • Protocol Standards: Uses industry-standard Redfish protocol for hardware control

  • Scalable Design: Horizontally scalable components with persistent storage

  • Authentication: LDAP, OIDC, service-specific mTLS, or an external authentication proxy

Core Components#

DPS Server (dps-server)#

The core orchestration engine of the DPS system.

Functionality:

  • gRPC API Server: Primary interface for all DPS operations

  • Topology Management: Manages power distribution network topology

  • Policy Engine: Implements and enforces power policies

  • Resource Group Management: Handles dynamic resource allocation

  • BMC Integration: Communicates with Baseboard Management Controllers via Redfish

Key Responsibilities:

  1. API Management: Serves gRPC API for client interactions

  2. Topology Validation: Ensures power topology constraints are satisfied

  3. Hardware Control: Manages BMC connections and Redfish communications

  4. Policy Enforcement: Applies and monitors power policies across resources

  5. Database Operations: Manages persistent state in PostgreSQL

DPS Control Utility (dpsctl)#

Command-line interface for DPS operations.

Architecture:

  • gRPC Client: Communicates with dps-server via gRPC protocol

  • Command Parser: Processes CLI commands and arguments

  • Output Formatter: Provides human-readable and machine-parseable output

DPS Web UI (dps-ui)#

Web-based user interface for DPS management.

Functionality:

  • Topology Visualization: Interactive topology creation and editing

  • Policy Management: Web-based policy configuration interface

  • Telemetry Dashboard: Real-time power consumption monitoring

  • Import/Export: Topology and configuration management tools

Integration:

  • DPS Server Communication: RESTful API calls to dps-server HTTP gateway

  • Authentication: Integrates with DPS authentication system

Data Storage#

PostgreSQL Database#

Primary persistent storage for DPS state and configuration.

Schema Components:

  • Topologies: Power distribution network definitions

  • Policies: Power management policy configurations

  • Resource Groups: Dynamic resource allocations

  • Entities: Hardware component specifications

Authentication and Authorization#

DPS supports the following authentication setups:

  • LDAP: The server checks directory credentials and issues tokens for API requests.

  • OpenID Connect (OIDC): The identity provider issues tokens, and the server validates them against the configured issuer, audience, and scopes.

  • Mutual TLS (mTLS): Verified client certificates authenticate callers to services with a configured certificate common name allowlist.

  • External Authentication and Authorization: An external proxy runs as a sidecar in the DPS server Pod. It authenticates callers, authorizes requests, and forwards permitted calls to the server. Refer to Configure External Authentication and Authorization for configuration. Built-in server authentication and authorization are disabled in this mode.

Refer to Configure Server Authentication to choose and configure a mode. Configure secure transport and Secrets separately through Prepare a Secure Deployment.

The UI and dpsctl use the login method configured for the authentication mode. The API enforces access through the server or external proxy. Authentication confirms the caller’s identity; authorization determines whether its request is allowed.

Hardware Integration#

BMC Communication#

DPS controls hardware through Baseboard Management Controllers using the Redfish protocol.

Protocol Stack:

DPS Server
    ↓
Redfish API (HTTPS)
    ↓
BMC Controllers
    ↓
Hardware Components

Supported Hardware:

  • Real BMCs: Production server BMCs supporting Redfish

  • BMC Simulators: Development and testing environments

Connection Management:

  • Credential Storage: BMC credentials stored in Kubernetes secrets

  • Connection Pooling: Efficient BMC connection management

  • Health Monitoring: BMC availability and status tracking

  • Error Handling: Robust error recovery and retry logic

BMC Simulation System#

Development and testing infrastructure simulating NVIDIA DGX systems.

Simulated Systems:

  • H100 Systems: NVIDIA H100 GPU-based servers

  • B200 Systems: NVIDIA B200 GPU-based servers

  • B300 Systems: NVIDIA B300 GPU-based servers

  • GB200 Systems: NVIDIA GB200 Grace Blackwell systems

Simulator Features:

  • Redfish Compliance: Partial Redfish API implementation

  • Realistic Behavior: Accurate power consumption modeling

  • Dynamic Response: Real-time power limit changes

  • Monitoring Integration: Prometheus metrics export

Python API Integration#

Python API for programmatic DPS interaction.

API Features:

  • Complete Coverage: All DPS functionality accessible via Python

  • Type Safety: Strongly typed interfaces with validation

  • Async Support: Asynchronous operation support

  • Error Handling: Exception handling

Deployment Architecture#

Kubernetes Deployment Model#

DPS deploys as a collection of Kubernetes services using Helm charts.

Namespace Organization:

dps (namespace)
├── dps-server (deployment + service)
├── dps-ui (deployment + service)
├── postgresql (statefulset + service)
├── openldap (deployment + service)
└── bmc-simulators (deployment + service)

Security Architecture#

Network Security#

Service Isolation:

  • Network Policies: Kubernetes network policies restrict inter-pod communication

  • TLS Encryption: All external communications encrypted with TLS

  • Internal Communication: Secure internal service mesh

Authentication Security#

Use separate identities for operators and services. For automation, use LDAP service accounts, OIDC client credentials, or mTLS configured for the required service. Refer to Service Accounts.

BMC credentials authenticate hardware connections separately from API callers. Store them through the configured credential store, as described in Credentials and Secrets Configuration.

Monitoring & Observability#

Metrics Collection#

Prometheus Integration:

  • Service Monitors: Automatic service discovery for metrics

  • Custom Metrics: DPS-specific power consumption metrics

  • Hardware Metrics: BMC-sourced telemetry data

Logging Architecture#

Structured Logging:

  • JSON Format: Machine-parseable log formats

  • Correlation IDs: Request tracing across components

  • Log Levels: Configurable verbosity levels

Tracing Integration#

Distributed Tracing:

  • Tempo Integration: Request tracing across microservices

  • Span Collection: Detailed operation timing

  • Performance Analysis: Bottleneck identification