AI Data Platform on Cisco UCS with NVIDIA AI and VAST Data Design and Deployment Guide

 

 

 

 

 

In partnership with:

Executive Summary

Organizations are looking for practical ways to use enterprise data with generative AI, document retrieval, and video analytics. Moving these applications from proof of concept to production requires more than GPU capacity. Compute, networking, data services, container orchestration, model serving, and application workflows must operate together as a reliable platform.

This Cisco Validated Design presents an implementation of an AI Data Platform built with Cisco UCS compute, Cisco Nexus networking, VAST data services, NVIDIA accelerated computing, and Red Hat OpenShift. The solution brings these technologies together in a tested architecture that customers can use for deploying data-intensive AI applications.

Cisco provides the compute and network foundation for the solution. VAST provides the shared data platform for file, object, database, vector, and event-driven services. NVIDIA provides GPU acceleration, inference software, optimized models, and video-search components. Red Hat OpenShift provides a consistent environment for deploying and operating the VAST and NVIDIA services. Each layer has a defined role while remaining independently scalable and serviceable.

The design was validated with document and video AI workloads. Document RAG demonstrates how enterprise content can be ingested, indexed, retrieved, and used to generate source grounded responses. Video Search and Summarization demonstrates two complementary approaches: a VAST-native workflow and NVIDIA VSS 3.2.1 Search. Together, these workloads confirm that the infrastructure, data services, GPU services, and application interfaces can operate as one platform.

This document provides the architecture, design considerations, deployment sequence, and functional validation needed to reproduce the solution. It establishes a baseline that can be extended with additional data sources, models, applications, storage capacity, and GPU resources as customer requirements evolve

Solution Overview

This chapter contains the following:

●     Introduction

●     Audience

●     Purpose of this document

●     Solution Summary

Introduction

Enterprise AI is moving from isolated model experiments to data-intensive services that continuously ingest, govern, enrich, search, and serve information. These services require an infrastructure foundation that combines accelerated computing, high-performance data access, and predictable operations without creating a separate data silo for every workload.

The Cisco AI Data Platform (AIDP) combines Cisco compute and networking, Cisco UCS C845A GPU server, VAST AI OS deployed on Cisco UCS C225 M8N (EBox), NVIDIA accelerated AI software, and Red Hat OpenShift. GPU services operate close to a unified data layer so the same platform can support data preparation, retrieval, inference, and multimodal analytics while maintaining clear operational boundaries.

Audience

This document is intended for enterprise and solution architects, AI and data-platform owners, compute and network administrators, OpenShift and GPU administrators, Cisco, VAST, and NVIDIA partner engineers, professional services teams, and technical decision makers evaluating or deploying an integrated AI data platform.

Purpose of this document

This Cisco Validated Design describes the architecture, deployment, operation, and functional validation of the Cisco AIDP. It explains how Cisco UCS C845A M8 accelerated compute, Cisco EBox based on Cisco UCS C225 M8, Cisco Nexus 9332D-GX2B networking, Red Hat OpenShift, NVIDIA AI software, and VAST AI OS are integrated into a repeatable platform for Document RAG and VSS.

Solution Summary

This solution combines Cisco compute and networking, VAST data services, NVIDIA accelerated computing, and Red Hat OpenShift in a single design. The platform supports enterprise AI applications that need direct access to large volumes of document, video, object, and vector data.

The solution consists of the following major stacks:

●     Cisco infrastructure: A 12-node VAST cluster based on Cisco UCS C225 M8 servers provides the data platform. A separate OpenShift environment runs on Cisco UCS C225 M8 servers and is extended with a Cisco UCS C845A GPU worker equipped with eight NVIDIA RTX PRO 6000 Blackwell GPUs. Redundant Cisco Nexus 9332D-GX2B switch pairs connect the storage, OpenShift, GPU, and external networks.

●     VAST data platform: VAST provides file and object storage, VAST DataBase, DataEngine, and InsightEngine. These services maintain source data, metadata, vector embeddings, and processing results on a common platform. DataEngine supports event-driven processing, while InsightEngine provides services for ingestion, retrieval, and application workflows.

●     NVIDIA accelerated computing: NVIDIA GPUs, the NVIDIA GPU Operator, NVIDIA NIM services, optimized models, and NVIDIA Blueprint components provide local inference for embedding, reranking, language generation, video understanding, and semantic search.

●     Red Hat OpenShift: OpenShift provides the common application environment for VAST services, NVIDIA inference services, operators, and AI workloads. It manages workload placement, networking, persistent storage, application services, and lifecycle operations.

The design validates three workloads on this shared foundation: Document RAG, NVIDIA VSS 3.2.1 Search and VAST native Video Search and Summarization.

These workloads demonstrate document retrieval, video understanding, vector search, and grounded response generation without requiring a separate infrastructure platform for each application.

The architecture is designed to expand as requirements grow. Additional GPU nodes, storage capacity, inference services, data pipelines, and NVIDIA Blueprints can be introduced while retaining the same Cisco, VAST, and OpenShift foundation.

Solution Design

This chapter contains the following:

●     Cisco AI Data Platform Design

●     VAST DataEngine Design

●     NVIDIA Blueprint Design

●     Solution Components

●     Physical Topology

●     Network Connectivity Design

This chapter elaborates on the Cisco AI Data Platform (AIDP) design that integrates Cisco compute and networking, Red Hat OpenShift, VAST data services, and NVIDIA accelerated AI software.

The key Design Components are as follows:

●     Cisco UCS C845A and Cisco C225M8 servers, provide the OpenShift and GPU compute foundation

●     Cisco Nexus 9332D-GX2B switches provide resilient high-speed fabrics

●     Cisco EBox cluster provides the VAST data platform

●     NVIDIA GPUs and software provide local inference acceleration.

Cisco AI Data Platform Design

The AI Data Platform (AIDP) design is built on the following:

●     12x Cisco UCS C225 M8-based VAST EBox nodes

●     1x Cisco UCS C845A M8 GPU server

●     3x Cisco UCS C225 M8 OpenShift nodes

●     4x Cisco Nexus 9332D-GX2B switches arranged as two redundant pairs:

◦     The VAST storage pair connects the EBox nodes and carries their internal and client data paths

◦     The AI/OpenShift pair connects the GPU server, the OpenShift CPU nodes, enterprise uplinks, and application ingress.

◦     Redundant inter-pair links provide the approved paths between application compute and VAST data services

Red Hat OpenShift provides namespace isolation, scheduling, Operators, service discovery, Routes, persistent storage consumption, and application lifecycle management.

VAST DataEngine uses OpenShift as an external execution environment for event-driven functions and pipelines.

NVIDIA NIM and VSS services execute on the Cisco UCS C845A GPU worker and expose model APIs to InsightEngine, VAST-native video processing, and NVIDIA VSS Search.

Design Objectives

●     Remove single-link dependencies. Production data-plane endpoints are dual-attached to an A/B Nexus pair so that one link or switch failure does not isolate a healthy service.

●     Separate traffic by function. VAST internal traffic, VAST client traffic, OpenShift machine and application traffic, enterprise access, and out-of-band management use distinct logical roles.

●     Process governed data in place. DataEngine reacts to storage events and invokes containerized functions without requiring every source object to be copied into a separate processing platform.

●     Use one application platform. OpenShift provides a consistent control plane for CPU applications, DataEngine functions, NVIDIA NIM services, and both VSS application lanes.

●     Preserve workload independence. Document RAG, VAST-native VSS, and NVIDIA VSS Search use separate namespaces and data boundaries even when they consume shared infrastructure services.

●     Pin software and images. Operators, Helm charts, application images, model images, and runtime profiles use explicit versions or immutable digests; floating latest tags are excluded.

●     Scale by subsystem. Storage capacity, CPU services, GPU inference capacity, and fabric bandwidth can be expanded independently when workload measurements require it.

●     Keep management independent. Cisco IMC, Nexus management, and VAST management remain reachable through an OOB plane during a data-fabric or OpenShift outage.

Table 1.          Target Architecture and Validated Reference Boundary

VAST DataEngine Design

VAST DataEngine is the event-driven compute and orchestration layer that connects governed data with containerized processing. It organizes triggers, Event Broker topics, functions, function deployments, and pipelines as managed resources. In this design, DataEngine is registered with the external OpenShift cluster so that stateless functions execute as OpenShift and Knative workloads while retaining direct access to VAST data services.

The architecture avoids copying every new object into an unrelated processing platform. A VAST storage event can initiate a pipeline that reads the original object, transforms or segments it, calls one or more NVIDIA model APIs, and writes structured results, derived objects, or embeddings to VAST S3 and VAST DataBase.

Table 2.          DataEngine Resource Model

Control and Execution Flow

The following lists the control and execution flow:

1.  Object or schedule event. A document, video, or other object is created or updated in an approved VAST view, or a configured schedule becomes due.

2.  Trigger evaluation. DataEngine evaluates the selected view, event type, path, tag, prefix, suffix, or schedule condition.

3.  Durable publication. The trigger publishes a structured event to the configured Event Broker topic.

4.  Pipeline resolution. DataEngine resolves the deployed pipeline revision and the function deployment that consumes the event.

5.  OpenShift execution. The integration creates or scales the corresponding Knative service in a namespace already approved in the compute-cluster mapping.

6.  Pinned image pull. The workload pulls its explicit image version or digest from the registered enterprise container registry.

7.  Data and model processing. The function reads the source object from VAST and can invoke a local NVIDIA NIM for embedding, reranking, reasoning, or generation.

8.  Governed output. The function writes derived objects, metadata, execution status, or vectors back to VAST S3 or VAST DataBase.

9.  Operational evidence. Operators verify the VAST resource state, pipeline status, OpenShift service and revision state, logs, metrics, and traces.

DataEngine Design Requirements

The following are the design requirements for DataEngine:

●     Approve namespaces explicitly. Register the OpenShift cluster and add only the namespaces in which DataEngine managed functions are allowed to run.

●     Reconcile registry access. Associate the enterprise registry and its pull credentials with the compute cluster and approved namespace through the VAST-supported workflow.

●     Use immutable function artifacts. Retain the image version or digest, dependency lock, function configuration, and rollback revision for every deployment.

●     Schedule CPU and GPU work deliberately. Place CPU-only functions on the CPU service tier and expose GPU model APIs through stable Services instead of embedding node addresses.

●     Separate applications. Use distinct namespaces, broker topics, storage views, and VASTDB schemas or tables for independently managed workflows.

●     Protect credentials and certificates. Use trusted certificate chains and Kubernetes Secrets; do not publish bearer tokens, passwords, keys, or TLS-verification bypasses in CVD procedures.

NVIDIA Blueprint Design

NVIDIA Blueprints combine reference application services, models, NVIDIA NIM microservices, deployment artifacts, and workflow guidance. It does not replace the compute, network, storage, or container platform.

●     Cisco provides the infrastructure foundation

●     VAST provides governed data and event services

●     and NVIDIA provides GPU-accelerated model and application components

NVIDIA NIM services are managed independently from the applications that consume them. This separation allows an application to be upgraded or rolled back without rebuilding the model container, provided that the API contract, model name, precision profile, and capacity remain compatible.

Table 3.          Blueprint-Aligned Application Profiles

GPU Service Profile

The validated coexistence profile allocates one whole GPU to each service listed below and does not use MIG or time slicing. This is an as-tested allocation, not a universal sizing rule. Production sizing must consider concurrency, latency, precision, model cache size, workload overlap, and the required failure domain.

Table 4.          GPU Service Profile Details

Solution Components

The component inventory distinguishes the CVD target from site-selected deployment services. Customers can add CPU workers, GPU workers, storage capacity, registry capacity, or management services without changing the logical responsibilities of the platform.

Table 5.          Hardware Components

Table 6.          Platform and Application Components

Validated Software Revision Profile

The following values describe the validated reference profile. A production release table must be reconciled against current Cisco, Red Hat, VAST, and NVIDIA support matrices before publication or upgrade.

Table 7.          Validated Reference Profile Values

Physical Topology

The topology uses two redundant Nexus pairs.

The VAST storage pair connects all twelve EBox nodes and keeps VAST internal traffic within the storage domain.

The AI/OpenShift pair connects the C845A GPU server, the three C225 OpenShift nodes, application ingress, and enterprise uplinks.

The inter-pair connection is Po100/vPC100. Storage A Ethernet1/24–25 connects to AI/GPU A Ethernet1/24–25, and Storage B Ethernet1/24–25 connects to AI/GPU B Ethernet1/24–25. Each side contributes two 400-Gb members. Only the service VLANs approved in the final site port map are carried across this boundary.

Figure 8 combines validated fabric connections with the repeatable CVD target for the C845A X710 host attachment. Before a customer deployment, reconcile device names, ports, VLANs, link speeds, and failure-state capacity with the approved site port map and supported bill of materials.

Table 8.          Topology Domains

Table 9.          Physical Connectivity Matrix

Table 10.       Availability Model

Network Connectivity Design

The network design separates control, client, storage, and internal traffic while preserving redundant physical paths. VLAN and subnet numbers are customer selected. The existing deployment solution fixes the logical role, traffic boundary, availability expectation, and validation method rather than prescribing one site's addressing plan.

Frontend (North-South) Fabric

The AI/OpenShift pair is the common attachment point for the OpenShift nodes, the Cisco UCS C845A GPU server, application ingress, and capacity-sized enterprise uplinks. The Cisco UCS C845A uses two separate network paths: X710 bond0/br-ex connects through Po102/vPC102 on Ethernet1/33 for the OpenShift host network on VLAN 1082, with VLAN 3057 used only when provisioning requires it; ConnectX-7 bond1 connects through Po101/vPC101 on Ethernet1/1 for VAST client and RoCE traffic on VLAN 3056. VLANs 1080 and 1081 remain VAST management and service networks and are not assigned to the C845A host links.

●     Dual-home every production endpoint. Distribute host connections across both switches and validate the selected LACP, bond, and vPC behavior together.

●     VLAN trunks. Carry only the logical networks required by each endpoint and keep VAST internal VLANs away from OpenShift, GPU, client, and upstream ports.

●     Publish stable service names. Resolve OpenShift API, ingress, registry, VAST management, and VAST service VIPs through enterprise or delegated DNS.

●     Place routing deliberately. Default gateways, inter-VLAN routing, firewall policy, and controlled egress follow the site Layer 3 design and are documented per traffic role.

●     Size for simultaneous demand. Account for object access, persistent-volume traffic, container and model pulls, application APIs, user traffic, and failure-state utilization.

VAST Storage and Internal Connectivity

The VAST storage pair connects both the client-facing and internal interfaces of the EBox nodes in the reference orientation. Client-facing services include S3, file, CSI, VASTDB, Query Engine, and application VIPs. Internal interfaces carry EBox to EBox cluster communication. These roles remain logically separate even when they share the same physical switch pair.

●     Protect the internal domain. VAST internal networks are confined to EBox interfaces and the storage pair and are not routed to general OpenShift workloads or enterprise clients.

●     Expose only service networks. OpenShift and GPU workloads reach approved VAST client or service VIPs through the inter-pair path, not through an internal EBox subnet.

●     Validate return paths. When one VAST node owns interfaces or VIPs in multiple subnets, test symmetric routing from every client network and apply only the VAST-supported correction for the installed release.

Inter-Pair and Northbound Connectivity

Po100/vPC100 provides the inter-pair path with two 400-Gb members per switch: Storage A Ethernet1/24–25 connects to AI/GPU A Ethernet1/24–25, and Storage B uses the same numbered ports to AI/GPU B. Captured validation evidence confirms the physical membership and active port channel; allowed-VLAN captures were taken at different stages, so the published configuration must use the approved site port map, prune all other VLANs, and be revalidated after the final change.

●     Define the boundary. State whether each inter-pair path is Layer 2, Layer 3, or an explicitly controlled combination, and list the permitted VLANs or routes.

●     Use diverse northbound paths. Terminate uplinks from both AI/OpenShift switches on independent upstream paths whenever the enterprise topology supports it.

Out-of-Band Management Network

This section describes the out-of-band management network.

The OOB plane remains operational independently of both high-speed fabrics. It connects Cisco IMC on every UCS server, mgmt0 on each Nexus switch, and the controlled VAST management interfaces. A bastion or administration VM and enterprise AAA, DNS, NTP, PKI, logging, monitoring, firmware, and configuration-backup services are attached according to site policy.

●     Restrict administrative access. Permit only approved management stations, automation systems, and protocols; do not carry application, storage, model, or user data on OOB.

●     Provide independent recovery. Cisco IMC console and power control remain reachable when OpenShift or either data fabric is unavailable.

●     Protect credentials. Use enterprise identity, unique management addresses, protected credentials, trusted certificates, and auditable access paths.

Logical Network Roles

Table 11 lists the logical network roles and traffic boundaries.

Table 11.       Logical network roles and traffic boundaries

MTU and QoS

The high-speed storage and RDMA-capable paths use jumbo frames. The validated reference uses MTU 9000 on hosts and MTU 9216 on the Nexus data interfaces to accommodate Ethernet overhead. Management and general-purpose networks can retain the site-standard MTU when jumbo frames are unnecessary.

●     Validate the complete path. Configure sufficient MTU on host bonds, switch interfaces, port-channels, VLAN interfaces, and intermediate links, then test with non-fragmenting traffic.

●     Limit lossless treatment. Apply PFC only to the approved RDMA traffic class and leave general application and management traffic outside the lossless queue.

●     Reconcile QoS values. The reference uses CoS 3, DSCP 26, PFC on queue 3, and ECN; confirm these values against the current Cisco, VAST, and NVIDIA guidance before publication.

●     Measure under load. Review pause behavior, ECN marking, queue occupancy, drops, interface errors, throughput, and failure-state utilization.

●     RDMA scope: The current single-node NIM services do not require inter-node GPU RDMA for model-parallel communication. The fabric remains RDMA-capable for storage and future scale-out workloads

Table 12.       Application Traffic Matrix

Subsystem Design Summary

This section summarizes the subsystem design, listing all products utilized.

Cisco UCS C845A GPU Compute

The Cisco UCS C845A joins OpenShift as a dedicated GPU worker for local NVIDIA model and VSS services. X710 bond0/br-ex uses Po102/vPC102 on Ethernet1/33 for VLAN 1082 and optional provisioning VLAN 3057. ConnectX-7 bond1 uses Po101/vPC101 on Ethernet1/1 for VAST client and RoCE traffic on VLAN 3056. Cisco IMC remains on the independent OOB network.

Treat one node as one failure domain. The reference demonstrates workload coexistence, not GPU-node high availability. Continued inference after a node failure requires a second sized GPU node and replicated services.

Avoid relying on GPU numbering. The Kubernetes device plugin allocates GPU resources but does not inherently guarantee a preferred physical GPU identifier

Cisco UCS C225 M8 OpenShift Nodes

Three Cisco UCS C225 M8 servers form the resilient OpenShift control plane and CPU-service tier. They host Operators, CPU-based application frontends and backends, DataEngine functions that do not request GPUs, registry and telemetry services according to the selected deployment, and VAST CSI components. A production design can add dedicated CPU workers when resource isolation or scale requires them.

State the scheduling model. Document whether control-plane nodes remain schedulable or dedicated workers are added, and size CPU, memory, ephemeral storage, and pod density accordingly.

Use policy-based placement. Use labels, affinities, taints, and tolerations rather than permanent cordoning as the steady-state workload-placement method.

Cisco Nexus Fabrics

Four Nexus switches form two A/B vPC pairs. The storage pair connects EBox nodes and retains internal traffic; Po100/vPC100 joins like-sided pairs through Ethernet1/24–25. The AI/OpenShift pair connects CPU nodes, enterprise uplinks, and the C845A through separate X710/Po102 host and ConnectX-7/Po101 data paths. The final design records vPCs, VLAN pruning, MTU/QoS, routing, telemetry, AAA, NTP, and configuration backup.

VAST Data Services

The EBox cluster provides S3-compatible object storage, file and persistent-volume access, VAST DataBase, Query Engine, vector search, Event Broker, DataEngine, and InsightEngine. Client-facing services use stable VIPs and delegated DNS names. Internal cluster traffic stays within the storage domain. VIP ownership, gateway behavior, DNS, and failover are validated together from every approved client network.

Red Hat OpenShift and External Services

OpenShift provides the common application platform with separate namespaces for platform services, model services, Document RAG, VAST-native VSS, and NVIDIA VSS Search. The deployment also depends on enterprise DNS, NTP, PKI, identity, image registry, logging, monitoring, backup, and configuration-management services. These dependencies are available before application deployment begins and do not rely on embedded credentials, certificate-verification bypasses, or unmanaged image tags.

Scaling Model

Scale VAST through the supported appliance model. Add data capacity and performance only through the VAST-supported expansion method and revalidate the fabric port and bandwidth plan.

Scale CPU independently. Add C225 workers when DataEngine functions, application services, or platform services exceed the compact three-node capacity.

Scale GPU independently. Add C845A workers when model concurrency, latency, model size, or node-level availability requires additional GPUs.

Scale fabrics from measurements. Increase inter-pair or northbound capacity when measured steady-state and failure-state utilization approach the approved threshold.

Repeat acceptance testing. After every scale or coordinated upgrade, rerun hardware, network, storage, model API, ingestion, retrieval, and end-to-end application validation.

Solution Deployment

This chapter contains the following:

●     Deployment Overview

●     Deploy Cisco Nexus Switches

●     Deploy VAST Cluster

●     Deploy Red Hat OpenShift

●     Deploy VAST CSI Plugin

●     Install and Configure VAST CSI

●     Deploy Cisco UCS C845A

●     Deploy Cisco UCS C845A M8 as an OpenShift GPU Worker

●     Create Server Policies

●     Create the UCS Server Profile Template

●     Derive and Deploy the UCS Server Profile

●     Validation

●     Deploy Cisco UCS C845A M8 as an OpenShift GPU Worker

●     Deploy VAST DataEngine

●     Deploy VAST InsightEngine

This chapter describes how to deploy the shared Cisco AI Data Platform (AIDP) foundation.

Deployment Overview

Deployment begins with the physical infrastructure and the two Cisco Nexus switch pairs. The VAST storage pair connects the 12-node Cisco EBox cluster. The AI/OpenShift pair connects the three Cisco UCS C225 M8 OpenShift nodes, the Cisco UCS C845A GPU server, the northbound network, and the VAST storage fabric. Before configuration begins, confirm the supported hardware and software versions, addressing, VLANs, routing, MTU, QoS, DNS, NTP, and support responsibilities.

Deploy and verify the VAST cluster using the procedure for the approved release and verify the existing OpenShift cluster before adding the Cisco UCS C845A as a GPU worker. Install the VAST CSI driver and NVIDIA GPU Operator, then prepare Zarf and Zot and deploy DataEngine and InsightEngine. Verify and record each step before continuing to the workload chapters.

Deployment Principles

The deployment principles are as follows:

●     Use one approved compatibility baseline across Cisco hardware and NX-OS, Red Hat OpenShift, VAST software, NVIDIA GPU software, and the selected application releases.

●     Treat hostnames, IP addresses, VLAN identifiers, vPC identifiers, port maps, certificates, and registry endpoints as site inputs rather than fixed CVD values.

●     Store passwords, API keys, tokens, and private certificates in the approved credential system.

Figure 11 illustrate the Workflow and elaborates on the Cisco AIDP platform deployment process.

Table 13.       Deployment stages and verification criteria

Deploy Cisco Nexus Switches

The reference design uses four Cisco Nexus 9332D-GX2B switches arranged as two independent virtual PortChannel (vPC) pairs. The VAST storage pair connects the 12-node Cisco EBox cluster. On each storage switch, Ethernet1/1/1 through Ethernet1/8/2 are external or northbound ports, while Ethernet1/9/1 through Ethernet1/16/2 are internal storage ports. The AI/OpenShift pair directly connects three Cisco C225 M8 OpenShift nodes and one Cisco C845A GPU node and also provides the enterprise uplinks.

Po100/vPC100 connects the two switch pairs: Storage A Ethernet1/24–25 connects to AI/GPU A Ethernet1/24–25, and Storage B Ethernet1/24–25 connects to AI/GPU B Ethernet1/24–25. Each side contributes two 400-Gb members. Captured evidence used NX-OS 10.4(3) on the storage pair and 10.5(4) on the AI/OpenShift pair; confirm and apply one mutually supported target baseline before production deployment.

Validated Port and VLAN Layout

The following tables list the validated ports and roles.

Table 14.       Storage-switch port roles

Table 15.       Validated VLAN roles

Table 16.       Reference interconnects and C845A attachment

Required Deployment Inputs

Table 17 lists the required deployment inputs.

Table 17.       Cisco Nexus implementation inputs

Procedure 1.    Configure the switch pairs

Step 1.          Establish out-of-band management and the system baseline.

Rack and cable both switch pairs according to the approved port map. Configure the management VRF, device identity, administrator access, SSH, AAA/RBAC, DNS, NTP, logging, and monitoring. Enable only the NX-OS features required by the design and verify that each switch can be operated independently through the OOB network.

Step 2.          Form the vPC domains.

Build the peer-keepalive and peer-link for each switch pair, then configure the vPC domain parameters and role preference. Confirm the peer adjacency and consistency state before any production vPC is attached. The storage and AI/OpenShift switch pairs remain separate vPC domains.

Step 3.          Create VLANs, VRFs, trunks, and routed boundaries.

Create only the approved network segments and prune every trunk to the required VLAN set. VLAN 1080 provides VAST management and VLAN 1081 provides approved VAST in-band service connectivity; neither is assigned to a C845A host bond. The C845A X710 host path uses VLAN 1082 and optional provisioning VLAN 3057, while its ConnectX-7 data path uses VLAN 3056. Place gateways in the approved routing domain and validate symmetric routing between OpenShift, VAST management, and VAST client-service endpoints.

Step 4.          Attach Cisco EBox, OpenShift, GPU, inter-fabric, and northbound links.

Configure Po100/vPC100 with Ethernet1/24–25 on the A-to-A and B-to-B inter-pair links. Attach the C845A X710 bond0/br-ex through Po102/vPC102 on Ethernet1/33 for VLAN 1082 and optional provisioning VLAN 3057. Attach ConnectX-7 bond1 through Po101/vPC101 on Ethernet1/1 for VLAN 3056. Apply the approved speed, MTU, VLAN pruning, and RoCE policy to each path, and verify that a single member or peer-switch failure does not isolate a required service.

Step 5.          Align MTU and RoCE policy end-to-end.

Use a switch-interface MTU of 9216 with endpoint MTU 9000 where the validated data path requires jumbo frames. Apply PFC, ECN, and lossless queueing only to the approved RoCE traffic class and only after verifying compatible marking and congestion behavior on every hop. All other traffic remains best effort unless a service requirement states otherwise.

Step 6.          Verify and save the configuration.

Verify control-plane health, physical links, vPC consistency, port-channel membership, trunk pruning, routing, MTU, errors, and QoS counters. Perform the approved failure tests, save the configuration, create an external backup, and store a sanitized evidence package before platform installation begins.

Reference Configuration Repository

The repository keeps the switch content deliberately small. One values file supplies the site inputs, one template covers each switch-pair role, and a local renderer produces four configurations for review. The renderer does not connect to a switch.

Verify the Nexus Fabrics

Table 18 lists the verification commands and pass criteria.

Table 18.       Cisco Nexus verification commands and pass criteria

Validated Output

The following shortened output came from the validation environment. It records NX-OS 10.4(3) on the storage pair and 10.5(4) on the AI/OpenShift pair.

Validated Output from VAST Storage Switch A

 

Validated Output from AI/OpenShift Switch

The AI/OpenShift pair reports the same healthy vPC states in domain 20, and the captured output validates the ConnectX-7 bond1 path on Po101/vPC101, Ethernet1/1, and VLAN 3056. The separate X710 bond0/br-ex mapping on Po102/vPC102, Ethernet1/33, VLAN 1082 (plus provisioning VLAN 3057 only when required).

Verify and Complete the Nexus Deployment

●     Both vPC pairs are reachable through the independent OOB management plane, have synchronized time and centralized logging, and show the documented endpoint, peer-link, inter-fabric, and northbound port channels as operational.

●     VLAN, routing, MTU, and RoCE settings match the approved design. Redundant-link and peer-switch tests complete without loss of the required VAST or OpenShift service path.

●     Save and back up the configurations, retain sanitized verification results, and record how any approved exception will be resolved.

Deploy VAST Cluster

The reference design uses a VAST Data cluster deployed as a Cisco EBox solution on twelve Cisco UCS C225 M8N servers. Detailed cluster build, node imaging, VAST software installation, activation, and initial system configuration are outside the scope of this CVD. Perform those tasks using the documentation for the approved VAST release and VAST support services.

Figure 13 illustrates VAST Cluster deployed on Cisco EBox.

Cisco EBox Cluster

This section defines the handoff into and out of the VAST deployment. Begin only after power, out-of-band access, cabling, both Cisco Nexus fabrics, VLANs, routing, MTU, and the approved RoCE policy have been verified. Do not continue to VAST CSI, DataEngine, or InsightEngine until the post-install checks shown below pass.

Deployment Prerequisites

The following are the deployment prerequisites:

●     Approve the Cisco EBox bill of materials, firmware baseline, VAST software release, licenses, and support coverage.

●     Verify the management, external or client, and internal storage networks, including DNS, NTP, certificates, routing, MTU, and the required RoCE policy.

●     Confirm the rack, power, cabling, administrator access, change window, recovery plan, and operational owners. Keep credentials outside this document.

Post-deployment Verification

Table 19.       VAST cluster post-deployment checks

Deploy Red Hat OpenShift

This section verifies an existing Red Hat OpenShift cluster before it is integrated with the Cisco AI Data Platform (AIDP). Complete OpenShift installation is outside the scope of this deployment. The checks confirm cluster identity, software level, node and operator health, networking, DNS, ingress, storage visibility, and the client tools required by the following deployment sections.

Run the commands from an OpenShift client VM with an authenticated cluster-administrator context. The commands in this section are read-only. Resource creation, node scheduling changes, MachineConfig changes, and storage tests require their own approved change procedure.

OpenShift Architecture as Deployed

The validated reference cluster uses three Cisco UCS C225 M8 nodes for the OpenShift control plane and CPU application services, together with one Cisco UCS C845A GPU worker. OVN-Kubernetes provides the cluster and service networks. The AI and OpenShift Nexus pair carry node, API, ingress, and VAST integration traffic, while VAST CSI and application interfaces connect workloads to VAST data services.

Verification Inputs and Boundaries

Table 20 lists the OpenShift verification inputs.

Table 20.       OpenShift verification inputs

Verify Cluster Identity and Software

Confirm that the client is connected to the intended cluster before collecting evidence.

Commands

Representative Validated Output

Pass when the identity, API endpoint, and context identify the intended cluster; client and server versions are compatible and ClusterVersion reports Available=True and Progressing=False. Investigate a Failing condition or unexpected update before continuing.

Verify Nodes and Workload Placement

List the nodes with the labels that control workload placement. The reference cluster uses the three Cisco UCS C225 M8 control-plane nodes for CPU workloads and a Cisco UCS C845A worker for GPU workloads. Site designs may use dedicated workers instead; preserve the same validation principle.

Commands

Representative Validated Output

Pass when every expected node is Ready, placement labels match the design, no unexpected node is cordoned or tainted, MachineConfigPools are not degraded, and any update in progress is understood. The non-running pod query should return no unexplained workload failure.

Verify ClusterOperators and Platform Health

Review all ClusterOperators, then retain a concise subset with the evidence package.

Commands

Representative Validated Output

Pass when all ClusterOperators report Available=True, Progressing=False, and Degraded=False, and the API readiness endpoint reports success. An operator can be healthy while a node pool is still updating, so review both operator and MachineConfigPool states.

Verify Network, DNS, and Ingress

Confirm the cluster network design and the services that VAST and NVIDIA components depend on. Use normal certificate validation; do not use an insecure TLS option to make a failed test appear successful.

Commands

Representative Validated Output

Table 21.       OpenShift network service pass criteria

Verify Storage and Client Prerequisites

At this point, record the existing storage integration without changing it. VAST CSI installation and the functional PVC test are detailed in the Deploy VAST CSI Plugin section. If VAST CSI has not yet been installed, its absence does not fail this OpenShift baseline.

Commands

Representative Integration State in the Validated Reference Deployment

The validated cluster already contained the VAST CSI Operator and StorageClass. This output records integration visibility only; it does not replace the CSI deployment and read-write/expansion validation in the following section. Do not display Kubernetes Secret data as evidence.

Validated Baseline

Table 22 lists the validated OpenShift reference baseline.

Table 22.       Validated OpenShift reference baseline

OpenShift Acceptance and Handoff

Table 23 lists the OpenShift acceptance checklist.

Table 23.       OpenShift acceptance checklist

After this checklist is accepted, continue with the Cisco UCS C845A integration, Deploy VAST CSI Plugin, Install GPU Operator, Deploy VAST DataEngine, and Deploy VAST InsightEngine sections. Repeat the same read-only verification after an OpenShift upgrade or a material network or MachineConfig change.

Deploy VAST CSI Plugin

VAST CSI integrates an existing Red Hat OpenShift cluster with VAST storage. The certified Operator deploys and maintains the CSI controller and node plug-ins, while the VastStorage resource provides the VAST storage policy used to create the StorageClass. This section covers the NFS deployment path, operational verification, and a complete PVC lifecycle test.

Before using this procedure, confirm the supported VAST CSI, OpenShift, and VAST software combination for the target release.

VAST CSI Architecture and Workflow

Dynamic provisioning uses two separate network paths. The CSI controller calls the VAST Management System (VMS) API over trusted HTTPS to create or update the VAST view and quota. The CSI node plug-in then mounts the resulting NFS export through a VAST frontend VIP. Both paths are required: storage-network reachability alone does not permit the controller to provision a volume.

Table 24.       Table 3-11. VAST CSI deployment prerequisites

Deployment Sequence

Complete the following actions in order. Verify each result before moving to the next action because the StorageClass depends on both the CSI driver and a valid VAST storage definition.

1.     Confirm the OpenShift context and network paths.

2.     Prepare the VAST service inputs.

3.     Install the certified VAST CSI Operator.

4.     Create VastCSIDriver.

5.     Create the credential Secret.

6.     Create VastStorage.

7.     Verify the CSI components.

8.     Validate the PVC lifecycle.

Install and Configure VAST CSI

This section details the process to install and configure VAST CSI.

Install the Operator

In the OpenShift console, open OperatorHub, select the certified VAST CSI Operator, and install the supported release into the vast-csi namespace. Use manual InstallPlan approval when the deployment change process requires a review of the exact CSV and operand versions. The validated reference used VAST CSI Operator 2.6.8; this is a reference result rather than a universal version requirement.

Create VastCSIDriver

Table 25 lists the validated NFS driver settings.

Table 25.       Validated NFS driver settings

VastCSIDriver deploys and configures the controller Deployment and node DaemonSet. It does not create the StorageClass. That relationship is provided by VastStorage.

Create the Secret and VastStorage

Create the VAST credential Secret through the approved secret-management process, then select that Secret in VastStorage. The Secret supplies the endpoint, username, password, and tenant keys required by the Operator; verify the key names without displaying their values.

Table 26.       VastStorage design inputs

Verify the Installation

Commands

Validated Output

Pass when the CSV reports Succeeded; the Operator and controller are available; the node DaemonSet is Ready on every eligible node; each CSINode registers csi.vastdata.com; the custom resources are reconciled; and the StorageClass settings match the approved design. The controller and node plug-ins must both use the NFS plug-in mode.

Validate the PVC Lifecycle

The sample validates one scheduled node.

Create the Test Claim and Pod

Save the following manifest as vast-csi-rwx-test.yaml, replace the namespace and approved image digest, review the file, and then apply it with oc apply -f vast-csi-rwx-test.yaml.

Run the Lifecycle Checks

Before cleanup, confirm in VMS that the test claim created the expected view and quota. After cleanup, confirm that the view, quota, and backing path follow the selected reclaim and trash policy. Run only the Delete or Retain PV check that matches the StorageClass.

Table 27.       VAST CSI lifecycle acceptance criteria

Deploy Cisco UCS C845A

This section explains how to configure a Cisco UCS C845A M8 as a standalone, Intersight-managed GPU worker for Red Hat OpenShift. It describes Cisco IMC management, the Intersight target claim, firmware, the M.2 RAID 1 boot volume, reusable server policies, and server-profile deployment. RHCOS installation, OpenShift worker admission, host networking, and GPU software are detailed in section Deploy Cisco UCS C845A M8 as an OpenShift GPU Worker.

Before you begin

Confirm the following inputs before changing the server:

●     An Intersight account, organization, resource group, and administrator role approved to claim standalone UCS servers and manage server profiles.

●     A management-network address plan CIMC IP address, prefix, default gateway, DNS, and NTP; outbound Device Connector reachability or an approved proxy.

●     Two supported, identical M.2 SATA drives for the RAID 1 boot volume; both drives must be approved for initialization and contain no required data.

Configuration workflow:

1.     Configure BMC         

2.     Claim target

3.     Verify inventory

4.     Update firmware

5.     Create M.2 Boot RAID 1

6.     Build policies

7.     Deploy profile

8.     Validate and hand off

Procedure 1.    Configure the Cisco BMC management network

Step 1.          Connect a USB keyboard and a display to the server local console. The Cisco UCS C845A uses the platform-supported local video connection, such as Mini DisplayPort, described in the installation guide

Step 2.          Power on the server. During POST, press F6 to enter the Setup Utility.

Step 3.          Navigate to Server Mgmt > BMC Network Configuration.

Step 4.          For the dedicated CIMC management port, dedicated NIC Mode, , and enter the approved IPv4 address, prefix, default gateway, and DNS settings.

Step 5.          Press F10 to save the changes and reboot the server.

Step 6.          From an administrator workstation with routed access to the management network, open https://<bmc-management-address> and sign in with the site-managed administrator credential.

Step 7.          Open Administration > Device Connector. Verify that the connector can reach Cisco Intersight; configure the approved proxy if direct outbound connectivity is unavailable.

Procedure 2.    Claim the Cisco UCS C845A in Cisco Intersight

Claim the Cisco UCS C845A as a Cisco UCS Server (Standalone) target. This is Intersight Standalone Mode (ISM).

Step 1.          In Cisco IMC, open Device Connector, enable Allow Control, and record the Device ID and one-time Claim Code. Do not publish or reuse the claim code.

Step 2.          In Cisco Intersight, select System > Targets > Claim a New Target > Cisco UCS Server (Standalone). Enter the Device ID and Claim Code, then assign only the organization and resource group defined by the deployment design.

Step 3.          After the claim completes, select Operate > Servers and confirm that the model is Cisco UCS C845A M8, the target is reachable.

Step 4.          Review the hardware inventory for the expected CPUs, memory, eight GPUs, Intel OCP NIC, NVIDIA ConnectX-7 adapters, and two M.2 boot drives before continuing.

Procedure 3.    Update Cisco UCS C845A firmware

Step 1.          Identify the Cisco UCS C845A M8 firmware. At the time of writing this install guide the validated firmware Version was 2.0(2.260101)

Step 2.          In Cisco Intersight, select Operate > Servers and select the target C845A.

Step 3.          Open the Actions menu and select Upgrade Firmware.

Step 4.          Select Cisco UCS C845A M8 and the release approved in the software matrix.

Step 5.          Review the summary, confirm the target server and bundle, and start the upgrade.

Step 6.          Monitor the Intersight request until it reports Success. Dense GPU server POST and component activation can take several minutes; use request state rather than a fixed timeout.

Step 7.          After the reboot, verify the installed bundle, server health, Device Connector state, inventory, and absence of unresolved firmware alarms.

Step 8.          If this guide is used to create the M.2 RAID 1 volume through Cisco BMC, use Cisco BMC 2.0.2.260062 or later, where that MSTOR-RAID workflow is available

Create Server Policies

Cisco Intersight policies provide repeatable settings for standalone Cisco UCS C845A servers.

Use the following policy grouping:

●     Compute policies:

◦     BIOS — model-specific C845A policy using platform defaults unless a setting is explicitly validated.

◦     Power — Power Restore set to Always On and Processor Package Power Limit set to Maximum after facility power and cooling review.

●     Management policies:

◦     IPMI over LAN — enable only for an approved integration; restrict access to the management network and use an encryption key where supported.

◦     Serial over LAN — enable only if the operations team uses serial-console access.

◦     Local User — use a unique site-managed credential and the organization password policy.

◦     Virtual KVM — enable when remote console access is required. Direct BMC or standard vKVM access requires network reachability; tunneled vKVM is a separate enabled and licensed path.

Procedure 1.    Create BIOS Policy

Table 28 lists the Cisco UCS C845A policy baseline.

Table 28.       Cisco UCS C845A server-policy baseline

Step 1.          In Cisco Intersight, select Configure > Policies and click Create Policy.

Step 2.          Select UCS Server > BIOS and click Start.

Step 3.          Select the UCS Server BIOS policy type.

Step 4.          Enter an approved policy name, select Model Specific, and select UCS C845A.

Step 5.          Use a model-specific policy for Cisco UCS C845A.

Step 6.          Click Next, review the platform-default tokens, change only settings explicitly required by the validated design, and click Create.

Procedure 2.    Create Power Policy

Step 1.          In Cisco Intersight, select Configure > Policies and click Create Policy.

Step 2.          Select UCS Server > Power and click Start.

Step 3.          Enter an approved policy name and click Next.

Step 4.          Select UCS Server Standalone (C8XX). Set Power Restore to Always On and Processor Package Power Limit (PPL) to Maximum after confirming the facility power and cooling design.

Step 5.          Review the policy and click Create.

Procedure 3.    Create IPMI over LAN policy (optional)

Step 1.          Go to the Cisco Intersight Dashboard and click Configure > Policies. Click Create Policy.

Step 2.          Select UCS Server > IPMI over LAN and click Start.

Step 3.          Add a name to the Policy and click Next.

Step 4.          For UCS Server Standalone (C8XX), enable IPMI over LAN.

Step 5.          Click Create.

Procedure 4.    Create local user policy

Step 1.          Go to the Cisco Intersight Dashboard and click Configure > Policies. Click Create Policy.

Step 2.          Select UCS Server > Local User and click Start.

Step 3.          Add a name to the Policy and click Next.

Step 4.          For UCS Server (Standalone), configure the policy as follows:

◦     Keep strong-password enforcement enabled.

◦     Set password history and expiry according to the organization password policy.

Step 5.          Click Create.

Procedure 5.    Create Serial over LAN policy (optional)

Step 1.          Go to the Cisco Intersight Dashboard and click Configure > Policies. Click Create Policy.

Step 2.          Select UCS Server > Serial Over LAN and click Start.

Step 3.          Add a name to the Policy and click Next.

Step 4.          For UCS Server Standalone (C8XX), enable Serial over LAN . Use a baud rate of 115200.

Step 5.          Click Create.

Procedure 6.    Create Virtual KVM policy (optional)

Step 1.          Go to the Cisco Intersight Dashboard and click Configure > Policies. Click Create Policy.

Step 2.          Select UCS Server > Virtual KVM and click Start.

Step 3.          Add a name to the Policy and click Next.

Step 4.          For UCS Server Standalone (C8XX), enable Virtual KVM when remote console access is required.

Step 5.          Click Create.

Procedure 7.    Create the M.2 RAID 1 boot volume in Cisco BMC

This procedure creates the boot virtual drive on the Cisco Boot Optimized M.2 RAID controller. It does not by itself configure the UEFI boot order. Complete boot-order and OS-install-target verification separately.

Step 1.          Log into Cisco IMC with the administrator credential.

Step 2.          Select Storage > MSTOR-RAID. Open Actions and select Create Virtual Drive.

Step 3.          Select MSTOR-RAID as the controller and click Next.

Step 4.          Select From Unused Physical Drives.

Step 5.          Confirm that both expected M.2 drives are present, select RAID 1, and click Next.

Step 6.          Enter the virtual-drive name and set Stripe Size to 64 KB. Keep the remaining validated controller defaults.

Step 7.          Review the summary, confirm RAID 1 and the expected capacity, and click Finish.

Step 8.          After creation completes, verify that the virtual drive reports Optimal, both physical drives are healthy, capacity is correct.

Create the UCS Server Profile Template

A server profile template applies the validated UCS C845A policies consistently. Derive one server profile per UCS C845A and deploy it before the node joins OpenShift. For profile concepts and current UI behavior, see [CISCO-09] and [CISCO-10].

Table 29.       Policies and preparation required for the server profile template

Procedure 1.    Create UCS Server Profile Template

Step 1.          Select Configure > Templates > UCS Server Profile Templates and click Create UCS Server Profile Template.

Step 2.          Enter an approved template name, set Target Platform to UCS Server (Standalone), set Server Family to UCS C845A, and click Next.

Step 3.          Under Compute Configuration, select the validated policies:

-      BIOS policy

-      Power policy

Step 4.          Click Next.

Step 5.          From the Management Configuration section, select the previously created policies as detailed below:

-      IPMI Over LAN Policy

-      Local User Policy

-      Serial Over LAN Policy

-      Virtual KVM Policy

Step 6.          Storage Configuration and Network Configuration are not supported for the C845A standalone C845A Intersight workflow.

Step 7.          Review the summary. Resolve every error and understand each warning before saving the template.

Derive and Deploy the UCS Server Profile

Derive one profile from the validated template and assign it to the intended C845A. Complete this activity before the server is admitted as an OpenShift worker whenever possible.

Procedure 1.    Derive, deploy, and validate the server profile

Step 1.          Confirm that the target C845A is reachable and healthy, with no unexplained Critical alarms, active conflicting requests, or existing profile that would be overwritten.

Step 2.          Select Configure > Templates > UCS Server Profile Templates. Open the validated template Actions menu and select Derive Profiles.

Step 3.          Select the intended C845A, enter a profile-name prefix that follows the naming standard, and click Next.

Step 4.          Review the derived profile, policy assignments, organization, and target server. Resolve all errors and understand all warnings before selecting Derive..

Step 5.          From the navigation pane, go to Profiles > UCS Server Profiles. Ensure Profiles are attached to UCS C845A server nodes and are in Not Deployed state. Click ellipses and select Deploy

Step 6.          If activation requires a reboot, proceed only during the approved maintenance window. For a server already joined to OpenShift, follow the approved cordon and drain procedure before activation.

Step 7.          Monitor the request until validation, deployment, and activation complete successfully.

Step 8.          In Operate > Servers and Configure > Profiles, verify Profile Status OK, Template Sync OK, server health Healthy, no unresolved alarms, and no configuration drift.

Validation

Verify the following before moving to the OpenShift configuration:

●     Cisco Intersight target is reachable and healthy, and the claimed model is Cisco UCS C845A M8.

●     Firmware matches the approved software matrix and all related Intersight requests report Success.

●     The M.2 virtual drive is RAID 1, reports Optimal, and is available as the intended UEFI boot target.

●     The derived server profile is deployed and activated, Profile Status is OK, Template Sync is OK, and no unexplained alarms or drift remain.

●     The expected GPU, Intel OCP NIC, ConnectX-7, CPU, memory, and boot-drive inventory is present.

Deploy Cisco UCS C845A M8 as an OpenShift GPU Worker

The Cisco UCS C845A is deployed as a dedicated Red Hat OpenShift worker node for GPU-accelerated workloads; it does not host control-plane services. The NVIDIA GPU Operator makes the installed GPUs available to the OpenShift scheduler so that NVIDIA NIM, Document RAG, and Video Search and Summarization pods can run on the node.

The Cisco UCS C845A M8 uses two independent network paths:

●     The Intel OCP ports provide the OpenShift host connection through bond0, and br-ex. Port 1 connects to Nexus A Ethernet1/33 and Port 2 connects to Nexus B Ethernet1/33. The switch links form Po102/vPC102. Native VLAN 1082 carries the OpenShift machine network; VLAN 3057 is used only when the approved provisioning workflow requires it.

●     The ConnectX-7 ports form bond1 for VAST client and RoCE traffic. Port 1 connects to Nexus A Ethernet1/1 and Port 2 connects to Nexus B Ethernet1/1. The switch links form Po101/vPC101 and carry native VLAN 3056 with Priority Flow Control and the approved RoCE policy. Configure MTU 9000 on bond1; the Nexus member and port-channel interfaces use MTU 9216.

Connecting one port from each interface pair to each Nexus switch provides network-path redundancy.

Figure 18 shows the physical and logical connectivity between the Cisco UCS C845A GPU worker and the two Cisco Nexus 9332D-GX2B switches in the AI/OpenShift fabric.

Complete the following procedures to add a Cisco UCS C845A M8 server to an existing OpenShift cluster.

Procedure 1.    Identify the Intel OCP and ConnectX-7 interface MAC addresses

Step 1.          In Cisco Intersight, Navigate to Servers > C845 Server > Inventory > Network Adapters. Record the permanent MAC addresses for the Intel OCP and ConnectX-7 interfaces.

Step 2.          Confirm each interface-to-MAC mapping against the server inventory and the screenshots before using it in DHCP or NMState configuration.

Procedure 2.    Install Red Hat CoreOS on the new Cisco UCS C845A M8 worker

Step 1.          For each Cisco UCS C845A M8 server, in Cisco Intersight select the server, then select Inventory > Network Adapters. Select the adapter used for the OpenShift host network, typically OCP_NIC, then select Interfaces. Record the DCE Interface 0 MAC address and use it to create the required DHCP reservation.

Step 2.          Connect to the Red Hat Hybrid Cloud Console here: https://console.redhat.com/openshift/overview and log in with your Red Hat credentials. On the left, select Cluster List. Under Cluster List, click your cluster to open it.

Step 3.          Select the Add Hosts tab. Click Add hosts.

Step 4.          The two Intel OCP ports form an 802.3ad bond. DHCP runs directly on untagged bond0, which Po102/vPC102 maps to native VLAN 1082. Use VLAN 3057 only if the approved provisioning workflow requires it. Select Static IP, bridges, and bonds and click Next.

Step 5.          For Configure via, select YAML view and click Start from scratch. Enter the NMState YAML that creates bond0 from the two Intel OCP interfaces. The example uses DHCP directly on bond0 for native VLAN 1082:

Step 6.          Below the YAML editor, enter the permanent MAC address and interface name for both Intel OCP ports. Use Add another MAC to interface name mapping for the second port. To add another Cisco UCS C845A M8 worker, select Add another host configuration and complete the mapping for that host. When all hosts are listed, click Next.

Step 7.          For Provisioning type, select Minimal image file. Select the SSH public key used for the existing cluster, then click Generate Discovery ISO.

Step 8.          Click Download Discovery ISO and save the file to the administrative workstation, then click Close.

Step 9.          For each Cisco UCS C845A M8 server, launch vKVM from Cisco Intersight. From the Virtual Media menu, select Map image. Upload the generated Discovery ISO and wait for the mapping to complete.

Step 10.       From the Boot Device menu, select CD. From the Host Power menu, select Power cycle, then click Confirm. The server restarts from the Discovery ISO.

Step 11.       If the server does not boot automatically from the Discovery ISO, map the ISO manually through vKVM Virtual Media and repeat the boot-device selection, as shown below.

Step 12.       After the server boots from the Discovery ISO, return to the Red Hat Hybrid Cloud Console. Wait for the new worker to report Ready, expand the host entry, and verify that the intended M.2 boot disk is selected.

Step 13.       Click Install ready hosts. The installation of CoreOS will take several minutes.

Step 14.       After the server boots into CoreOS, open vKVM and use the Virtual Media menu to select Eject image.

Step 15.       In the OpenShift console, select Compute > Nodes. After the host restarts, review the new worker's approval prompts. Approve the discovered host and pending certificate-signing requests only after confirming the node identity and MAC mappings.

Procedure 3.    Create and associate the BareMetalHost (BMH)

Step 16.       From an OpenShift administrative host with the intended kubeconfig, create the following manifest for the new worker. This example uses worker-1:

Step 17.       Validate the manifest, then apply it during the approved change window:

Step 18.       To associate the BareMetalHost with its Machine, select Compute > Machines and record the name of the newly added Machine in the Provisioning phase.

Step 19.       Select Compute > Bare Metal Hosts and open the YAML for an existing, correctly associated BMH. Copy its complete consumerRef structure for use as a format reference; do not reuse the existing Machine name.

Step 20.       Open the new worker BMH YAML. Under spec, add consumerRef next to externallyProvisioned and set consumerRef.name to the new Machine name recorded in the previous step. Verify indentation, then save.

Step 21.       Select Compute > Machines and confirm that the new Machine enters the Provisioned phase.

Step 22.       Open the new Machine YAML and copy its complete spec.providerID value.

Step 23.       Select Compute > Nodes and open the new node's YAML. Under spec, add the copied providerID with two-space indentation, verify that it references the intended Machine, then click Save.

Step 24.       Select Compute > Bare Metal Hosts and confirm that the new BMH is linked to the intended node.

Step 25.       Select Compute > Machines and confirm that the new Machine reports Provisioned as node and links to the same node.

Procedure 4.    Configure the ConnectX-7 VAST and RoCE data path

Step 1.          From an OpenShift administrative host, connect to the new worker and identify the two ConnectX-7 interface names. Confirm each interface by permanent MAC address before creating bond1.

Step 2.          Create bond1 on native VLAN 3056 by using a NodeNetworkConfigurationPolicy (NNCP):

Step 3.          Apply the placement label used by the NNCP to the intended C845A GPU worker only:

Step 4.          Validate the NNCP, then apply it during the approved change window:

Step 5.          In the OpenShift console, select Networking > NodeNetworkConfigurationPolicy. Confirm that the policy and its node enactment complete successfully before continuing.

Step 6.          On the C845A worker, run ip -br a and cat /proc/net/bonding/bond1. Confirm that bond1 is up and both members are collecting and distributing.

Step 7.          Ensure that the DHCP scope for VLAN 3056 has an available address for the C845A VAST/RoCE data path.

Step 8.          Verify the bond1 address and routes. The OpenShift default route and DNS must remain on br-ex; bond1 must not install a competing default route.

Procedure 5.    Install the Node Feature Discovery Operator

Step 1.          In the OpenShift console, select Ecosystem > Software Catalog. Search for and select Node Feature Discovery Operator.

Step 2.          Click Install. Click Install again to deploy the operator.

Step 3.          When the operator is installed, click View Operator.

Step 4.          Select the NodeFeatureDiscovery tab, then create the instance with the approved defaults.

Step 5.          Open the nfd-instance YAML and locate sources.pci.deviceClassWhitelist. Ensure that the validated list includes 02 and 0207 so NFD publishes the required PCI network-device labels for the ConnectX-7 adapters. Save the object and verify the resulting node labels.

Procedure 6.    Deploy the NVIDIA Network Operator

Step 1.          In the OpenShift console, select Ecosystem > Software Catalog. Search for and select NVIDIA Network Operator.

Step 2.          Click Install. Click Install again to deploy the operator.

Step 3.          After installation completes, click View Operator and open the NicClusterPolicy tab.

Step 4.          Select YAML view and make the following validated changes.

Step 5.          Remove the NIC firmware-upgrade PVC block only when it is not used by the validated operator configuration, as shown below.

Step 6.          Under resourceName: "rdma_shared_device_a", replace vendors: ["15b3"] with ifNames: ["bond1"].

Step 7.          Remove the unused ibKubernetes block, if present:

Step 8.          Under spec.ofedDriver, add:

 

Step 9.          Create or save the policy. Continue only after NicClusterPolicy reports Ready and the required Network Operator operands are healthy.

Procedure 7.    Configure kernel arguments for the Cisco UCS C845A

Step 1.          From an OpenShift administrative host with the intended kubeconfig, create the following MachineConfig manifest:

Step 2.          Validate the MachineConfig, then apply it in the approved maintenance window. Applying or removing a MachineConfig can restart affected nodes:

Step 3.          Wait until the MachineConfigPool selected by this MachineConfig reports UPDATED=True, UPDATING=False, and DEGRADED=False. The example manifest targets the standard worker pool.

Step 4.          Log in to each affected Cisco UCS C845A worker and verify the active kernel arguments.

Step 5.          Confirm that the NicClusterPolicy created in the previous procedure remains Ready after the node restarts.

Procedure 8.    Deploy the NVIDIA GPU Operator

Step 1.          In the OpenShift console, select Ecosystem > Software Catalog. Search for and select NVIDIA GPU Operator.

Step 2.          Click Install. Click Install again to deploy the operator.

Step 3.          After installation completes, click View Operator, open the ClusterPolicy tab, and select Create ClusterPolicy.

Step 4.          Create the ClusterPolicy with the settings approved for the validated platform. Keep GDS disabled during base GPU validation. Do not continue while the policy reports Error or ReconcileFailed; the screenshot below illustrates a state that requires correction.

Step 5.          Wait until ClusterPolicy reports Ready and every required GPU Operator operand is healthy.

Step 6.          Select Installed Operators > NVIDIA GPU Operator > ClusterPolicy and confirm that gpu-cluster-policy reports Ready.

Step 7.          Open a running pod whose name begins with nvidia-driver-daemonset-, select Terminal, and run nvidia-smi. Confirm that all eight NVIDIA RTX PRO 6000 Blackwell GPUs are visible and that the node advertises eight allocatable nvidia.com/gpu resources.

Procedure 9.    Enable NVIDIA GPUDirect Storage (GDS)

Step 1.          Select Ecosystem > Installed Operators > NVIDIA GPU Operator, open the ClusterPolicy tab, and select Form view. Edit the GDS section with the version approved for the validated software matrix, then click Save.

Step 2.          Wait until the GDS operands report Ready, confirm that the nvidia-fs module is loaded, and run the approved GDS functional test before declaring the feature operational.

Deploy VAST DataEngine

VAST DataEngine connects a VAST tenant to an OpenShift compute cluster so file, object, tag, schedule, and API events can invoke serverless functions and pipelines. The validated design uses a VAST Event Broker, Knative, a local Zot registry, the VAST-supplied Zarf runtime, and VAST CSI storage.

Table 30.       Validated DataEngine Deployment Profile

Runtime Architecture

VAST AI OS owns tenant identity, policy, the Event Broker, triggers, pipelines, and data services. OpenShift runs the VAST operator, Knative control plane, telemetry collectors, and function pods. Zot provides the pinned images that DataEngine workloads pull at deployment time.

Table 31.       Validated Component Roles

The component model is described in Overview of VAST DataEngine

Procedure 1.    Prepare OpenShift and Deploy Zot

Step 1.          Verify the target cluster and release files.

Step 2.          Confirm the OpenShift identity and API, the VAST CSI StorageClass, the installer-host inotify limits, and the VAST-supplied Zarf binary and packages before installing anything:

Step 3.          Deploy the local Zot registry.

The validated topology uses Zot chart 0.1.113 (app 2.1.16), one registry pod, a 50-GiB RWO PVC on vastdata-filesystem, a NodePort service, and an edge-terminated OpenShift Route. The repository helper encodes these settings; review its printed plan, then apply it. The registry password is entered through a hidden prompt.

Procedure 2.    Install the DataEngine package

Step 1.          Initialize the VAST-supplied Zarf runtime.

For a new installation, run the release-matched Zarf 0.60.0 binary and initialization archive supplied with VAST DataEngine 5.4. Record the package checksums with the deployment evidence.

Step 2.          Label the execution namespaces and deploy DataEngine.

Use only the VAST 5.4 mutation label shown below. Deploy the release-matched package with the VAST-supplied Zarf binary.

Table 32.       Validated OpenShift Results

Procedure 3.    Assign the VAST Event Broker and topics

Step 1.          Select the event foundation.

Open DataEngine enablement for de-tenant. Select de-broker1, de-topic1, and de-deadlettertopic1, and add the approved Event Broker CA certificate.

Step 2.          For more information, see the complete tenant workflow here: Enabling DataEngine on a VAST Cluster Tenant

Procedure 4.    Link the OpenShift Cluster

Step 1.          Register aa10-ocp by mutual TLS.

Enter aa10-ocp and https://api.aa10-ocp.aa10.rtp04.local:6443, then load the cluster CA, client certificate, and private key in their matching fields.

Procedure 5.    Select DataEngine namespaces

Step 1.          Approve the execution namespaces.

Move vast-dataengine, knative-serving, and knative-eventing to Selected Properties. Add application namespaces only when DataEngine functions or pipelines will run there.

Procedure 6.    Link the container registry

Step 1.          Associate local-zot with aa10-ocp.

Select aa10-ocp, set the registry name to local-zot and the base URL to https://zot.apps.aa10-ocp.aa10.rtp04.local, select User credentials, enter admin, and enter the registry password.

Procedure 7.    Confirm DataEngine enablement

Step 1.          Finish the wizard.

Save the configuration and confirm that the tenant dashboard reports DataEngine Enabled. Reopen the compute-cluster and registry records to confirm the selected namespaces and registry association were retained.

Verify DataEngine

Verify the registry, Zarf agent, namespace labels, DataEngine releases, and Knative services. Then use the release-matched DataEngine client to confirm that functions, triggers, and pipelines are visible and Ready.

Table 33.       DataEngine Acceptance Criteria

Table 34.       Quick Troubleshooting

Deploy VAST InsightEngine

VAST InsightEngine adds document ingestion, vector retrieval, and application APIs to the shared AIDP platform. The deployment uses the existing VAST DataEngine foundation, VAST S3, VAST Database, VAST Event Broker, OpenShift, Knative, and a dedicated PostgreSQL instance.

Table 35.       Validated InsightEngine Deployment Profile

Runtime Architecture

The backend and PostgreSQL run as OpenShift workloads. The InsightEngine operator creates the VAST custom resources and the DataEngine ingestion path. Knative starts the ingestion service when events arrive from the VAST Event Broker.

Table 36.       Validated Data and Event Path

The DataEngine execution model is described here: Overview of VAST DataEngine

Procedure 1.    Confirm the VAST Event Foundation

Step 1.          Confirm the Event Broker and topics.

Open the tenant DataEngine configuration and select the existing broker de-broker1. Keep the default and dead-letter topics already used by DataEngine. Add the tenant CA certificate when it is not already present.

For the complete tenant enablement sequence, see Enabling DataEngine on a VAST Cluster Tenant

Procedure 2.    Link the OpenShift cluster

Step 1.          Register aa10-ocp.

Use the OpenShift API URL https://api.aa10-ocp.aa10.rtp04.local:6443 and load the cluster CA, client certificate, and private key through the VAST UI. Save the cluster as aa10-ocp.

Step 2.          Confirm the target before deployment:

Procedure 3.    Add the InsightEngine namespace and registry mapping

Step 1.          Select vast-insight-engine.

Create the OpenShift namespace, edit the aa10-ocp DataEngine compute cluster, add vast-insight-engine to Selected Properties, and keep every existing namespace selection.

Step 2.          Update local-zot.

Open the existing local-zot registry record, keep zot.apps.aa10-ocp.aa10.rtp04.local, associate aa10-ocp and vast-insight-engine, and select Save. Store the registry password only in the registry record and Kubernetes pull Secret; it is not printed in this guide.

When the registry CA must be added to OpenShift, see: OpenShift image configuration resources

Procedure 4.    Confirm DataEngine Readiness

Step 1.          Finish tenant enablement.

Save the DataEngine configuration and confirm that the tenant dashboard shows DataEngine Enabled before installing InsightEngine.

Required inputs:

●     VAST InsightEngine 5.4.3 delivery archive and runbook

●     A working VAST CSI StorageClass and an existing Event Broker

●     Separate VAST PROTOCOLS and Query Engine VIP services

●     Runtime, PostgreSQL, and image-pull Secrets in vast-insight-engine

●     Reachable embedding endpoint; reranker and LLM endpoints when the workload uses them

Procedure 5.    Install InsightEngine

Use the release-matched 5.4.3 charts and images. Install PostgreSQL first, the namespace-scoped operator second, and the backend last. The CVD wrapper renders the manifests for review before it writes to OpenShift.

Step 1.          Prepare and verify the release.

Populate release-inputs.env with the delivery paths and site values, then run the read-only preflight and image import.

Step 2.          Create the namespace and install the three releases.

Apply the namespace step, render the deployment once for review, and apply the same rendered inputs.

Table 37.       Install order

Procedure 6.    Verify the DataEngine Execution Path

Step 1.          Confirm the trigger and subscriber.

The operator creates the pipeline resources and DataEngine creates the Knative service and trigger. The trigger must reference the current broker and send events to the cisco-ingest-docs service.

Procedure 7.    Verify the installation

Step 1.          Run the verification wrapper, then compare the live releases, controllers, pods, PVCs, VAST resources, and Knative objects with the expected names below:

Procedure 8.    Functional acceptance

Step 1.          Run the Document RAG acceptance procedure with a new private collection and a new marker. Pass requires completed ingestion, a retrieved source chunk, reranking when enabled, and a grounded LLM answer containing the marker:

Table 38.       Quick Troubleshooting

AI Data Platform Workloads

This chapter contains the following:

●     Deploy NVIDIA VSS 3.2.1 Search

●     Deploy VAST-native VSS

●     Deploy Document RAG

After the shared Cisco AI Data Platform foundation is deployed, customers can enable three validated AI workloads on the same Cisco UCS, NVIDIA GPU, Red Hat OpenShift, and VAST data foundation. Each workload uses the common infrastructure, networking, storage, and model services described in the preceding chapters.

The sections in this chapter provide the architecture, deployment procedure, functional validation, and rollback guidance for each workload.

Deploy NVIDIA VSS 3.2.1 Search

NVIDIA Video Search and Summarization (VSS) 3.2.1 adds native video upload, GPU-accelerated indexing, semantic and object search, optional visual verification, playback, and grounded answer generation to the Cisco AI Data Platform. The validated deployment runs on the Cisco UCS C845A GPU worker, uses VAST CSI persistent volumes, and is exposed through OpenShift Routes.

The deployment is pinned to the NVIDIA VSS v3.2.1 repository and follows the NVIDIA Search workflow . VAST CSI provides persistent storage; Kafka, Logstash, and Elasticsearch remain the NVIDIA-native event and retrieval plane.

Validated Deployment Profile

Table 39 lists the validated NVIDIA VSS deployment profile.

Table 39.       Validated NVIDIA VSS Deployment Profile

Video Analysis and Indexing

VIOS registers the source once and feeds two parallel GPU paths. RTVI-Embed creates action vectors; RTVI-CV detects and tracks visible objects and creates attribute vectors. Kafka carries both result streams, Logstash shapes the records, and Elasticsearch stores the searchable indices.

Table 40.       Analysis Services and GPU Requests

Search and Answer Generation

Direct Search embeds the user query and retrieves timestamped video clips. Vision Agent can combine embedding, attribute, and fusion search; when enabled, Cosmos3 reviews candidate clips before Nemotron 3.5 Lightning produces the final answer.

For NVIDIA component behavior and current limits, use the release-pinned VSS 3.2.1 documentation

Prepare the Deployment

Table 41 lists the required platform inputs.

Table 41.       Required Platform Inputs

Use the deployment files in configs/cvd/workloads/nvidia-vss-3.2.1-search/. The wrapper verifies the OpenShift target, source lock, chart, storage, Route names, and model settings before it renders or applies the release.

Procedure 1.    Deploy the Search Profile

Step 1.          Create the namespace and runtime objects.

Apply the reviewed namespace and service-account bindings, then create ngc-docker-reg-secret and ngc-api-key-secret. The secret object names and types are visible; password and API-key values are not printed.

Step 2.          Run the initial profile.

Initial mode creates the core services and lets the one-time RT-CV downloader populate its RWO model claim while the RT-CV StatefulSet remains at zero replicas.

Step 3.          Move to steady state.

After the downloader Job completes, steady mode disables the downloader and starts RT-CV against the populated claim.

Step 4.          Enable Critic when required.

Critic mode adds the Cosmos3 NIM cache and service and reserves one additional GPU. The main Search workflow remains available when Critic is disabled.

Procedure 2.    Verify the Deployed Distribution

Step 1.          Run the verification wrapper after each deployment mode, then compare the live Helm release, pods, services, Routes, PVCs, and optional NIM resources with the validated summary below:

Table 42.       Validated Container Distribution

Verify GPU Library Injection

Pass: the running RT-CV process maps the GPU Operator-injected libraries from /usr/lib64, and the pod remains Ready without new restarts

Procedure 1.    Verify the Distribution from the VSS UI

Step 1.          Open Video Management.

Browse to https://nvidia-vss-321-search.apps.aa10-ocp.aa10.rtp04.local and select Video Management. The page must load the VIOS stream inventory and show Upload Video. The deployed profile also displays Add RTSP, but RTSP ingestion is not part of this validated procedure.

The validated screen shows 29 registered MP4 streams, including nv-warehouse-4cams-preview-90s. Add RTSP is visible because it is included in the NVIDIA profile, but no end-to-end RTSP source was validated. The packaged UI footer displays 3.2-dev; use the Helm chart and running image tags—not the footer—to verify the deployed 3.2.1 profile.

Procedure 2.    Run UI Functional Acceptance

Step 1.          Upload one new MP4.

Choose Upload Video and use a unique filename without spaces. Wait until the video appears in Video Management. Registration proves the VIOS/VST path; search acceptance begins only after both indexing branches finish.

Step 2.          Run Direct Search.

Open Search, keep Source Type set to Video, and enter a clearly visible action such as worker handling boxes in a warehouse aisle. Confirm timestamped clips, open one result, and verify playback.

Step 3.          Run Vision Agent.

Open the chat control, use video_file as the media source, and ask an evidence-bounded question. Run once with Critic disabled and once with Critic enabled when the optional Cosmos3 service is deployed.

Table 43.       Functional Acceptance

Table 44.       Troubleshooting and Rollback

Rollback

Rollback to a recorded steady or critic revision, retain the RT-CV model PVC and StatefulSet claims, reapply the reviewed Routes when required, and repeat the UI upload-to-answer acceptance test.

For VIOS source registration and playback details, see NVIDIA Video IO and Storage Microservices

Deploy VAST-native VSS

VAST-native Video Search and Summarization (VSS) combines a browser application with an event-driven VAST DataEngine pipeline. Source and segment media remain in VAST S3; human-readable clip descriptions and 2048-dimensional vectors are stored in VAST Database (VASTDB); local NVIDIA NIM services provide clip reasoning, text embedding, and grounded answer generation.

The implementation uses VAST Event Broker, two S3 triggers, four DataEngine functions, VASTDB semantic search, and the VAST VSS UI. It is independent of the NVIDIA VSS 3.2.1 Search deployment and does not require Elasticsearch, RTVI-CV, RTVI-Embed, Behavior Analytics, or Cosmos3 Critic. The validated source revision is 8b34c2c919edcec6b7bd51cf9ff09722d3dda879.

Video Analysis and Indexing

The pipeline creates five-second MP4 clips, calls Cosmos Reason2 for a visible-activity description, converts that text to a 2048-dimensional vector with Nemotron Embed, and writes the clip metadata, access fields, description, and vector to VASTDB.

Table 45.       Video Analysis and Indexing Stage and Validated Implementation

Search and Answer Generation

The application embeds the user question, searches VASTDB with access and metadata filters, returns timestamped clips for playback, and can pass the retrieved descriptions to Nemotron 3.5 Lightning for a grounded answer.

Table 46.       Services, Roles, and GPU Requests

Validated Deployment Profile

The VAST resources, application, DataEngine graph, and NVIDIA models are separated by namespace. The application and Knative functions request CPU resources only; they reuse the three Ready NIMService pods shown below.

Table 47.       Deployed Items and Validated Value

Procedure 1.    Prepare and Deploy the Workload

Use configs/cvd/workloads/vast-native-vss/. Populate release-inputs.env with the target namespace, pinned source, immutable image references, VAST object names, and model endpoints. Passwords, API keys, pull credentials, and private certificates are entered through the approved Secret workflow and are not stored in Git.

Step 1.          Run preflight.

Confirm the OpenShift context, VAST release, DataEngine cluster, Event Broker, Zot registry, storage views, and the three Ready NIM services.

Step 2.          Prepare and publish.

Prepare pinned source revision 8b34c2c, build the reviewed frontend, backend, stream, batch-sync, and function images, then publish immutable tags or digests to Zot.

Step 3.          Authorize the namespace.

Create vast-vss, add it to the DataEngine compute cluster, save the assignment, reopen and save the existing Zot registry assignment, and create the namespace-local pull and runtime Secrets.

Step 4.          Render and apply.

Render the VAST resources, Helm values, pipeline graph, and receipt. Review the rendered output before applying the approved receipt.

Register and Verify the DataEngine Graph

Register the four functions and two Element triggers with the release-matched DataEngine client, then deploy the application and pipeline. The wrapper previews the object names, broker, topic, buckets, image tag, and graph before any apply.

Table 48.       DataEngine Object and Validated Definition

Pass when current resources remain Ready and any Warning event whose timestamp advances during the run is understood and resolved. Historical Kafka dispatcher or ConsumerBinding warnings are not accepted or rejected solely from their event type; correlate them with the new upload and function logs.

Run UI Functional Acceptance

Browse to https://vast-vss.apps.aa10-ocp.aa10.rtp04.local and sign in with an authorized VAST identity. Use a licensed MP4 with a unique filename and camera ID. Upload completion proves S3 landing; search acceptance begins after the expected five-second rows have been written to VASTDB.

Table 49.       Action and Pass Criteria

Table 50.       Troubleshooting and Rollback

Rollback

Application rollback retains source and segment objects, VASTDB rows, views, the Event Broker topic, DataEngine objects, NIM caches, PVCs, and registry images. Data or model rollback is a separate change.

 

Deploy Document RAG

Document Retrieval-Augmented Generation (RAG) is the final validated AIDP workload in this CVD. VAST InsightEngine 5.4.3 manages collections, identity, ingestion, retrieval, and grounded conversations; VAST S3 stores source documents; DataEngine and Knative execute event-driven ingestion; VAST Database (VASTDB) stores searchable passages and vectors; three local NVIDIA NIM services provide embedding, reranking, and answer generation.

Complete the Deploy VAST InsightEngine section before this workload. The accepted path covers TXT, Markdown, and text-based PDF files. Scanned-document OCR, handwriting recognition, and complex chart extraction are outside the validated scope.

Retrieve and Rerank Governed Context

A question is embedded with the same model and vector width used during ingestion. Insight Engine searches VASTDB within the selected collection and the user's access boundary, then sends only authorized candidate passages to the local reranker.

Table 51.       Control and Validated Implementation

Generate a Grounded Answer

Insight Engine builds a grounded prompt from the ranked, authorized passages. The local Nemotron 3.5 Lightning service generates the answer, and Insight Engine returns both the answer and the source chunks used as evidence.

Table 52.       Service, Purpose, and GPU Requests

Model references: Nemotron 3.5 Lightning, Nemotron Embed 1B v2, and RerankQA 1B v2

Procedure 1.    Configure and Verify the Workload

The InsightEngine platform remains managed through configs/cvd/insightengine. Use the workload companion under configs/cvd/workloads/document-rag for the read-only preflight, local-model smoke test, functional acceptance, embedding reliability, and application rollback. The companion reuses the reviewed platform inputs and does not duplicate credentials or Helm values.

Step 1.          Confirm the foundation.

Verify the intended OpenShift context, InsightEngine 5.4.3 delivery, DataEngine, Knative, VAST CSI, VAST resources, and all three local NIM services.

Step 2.          Review model settings.

Set the local Service endpoints, the exact model identifiers, reranking enabled, and embedding dimensions 2048 in the reviewed backend and ingestion values.

Step 3.          Prepare workload inputs.

Copy the workload example input file, reference the existing private InsightEngine input file, and replace every required non-secret value.

Step 4.          Verify current state.

Run the workload preflight and confirm the backend, PostgreSQL, pipeline, current Knative revision, PVCs, VAST resources, locked validators, and NIM services are Ready.

Run Functional Acceptance

Run acceptance from the Document RAG companion directory on the OpenShift administration client. The wrapper verifies the pinned validator checksums, streams the reviewed validators into the existing backend pod, uses the mounted runtime credential without printing it, creates new private synthetic collections, and retains the created documents and conversations as evidence.

Table 53.       Functional Acceptance and Recorded Result

Table 54.       Troubleshooting

Appendix

This appendix contains the following:

●     Appendix A - References

●     Appendix B – Solution Repository

●     Appendix C – Bill of Materials

Appendix A - References

This appendix lists the primary vendor references and validated implementation sources used by this CVD. Detailed product and troubleshooting links remain with the applicable deployment procedure.

Cisco

Table 55.       Cisco Public References

VAST Data

Table 56.       VAST Data Public References

NVIDIA

Table 57.       NVIDIA Public References

Project Zot

Table 58.       Project Zot Public References

Red Hat OpenShift

Table 59.       Red Hat OpenShift Public References

Appendix B – Solution Repository

This solution repository contains customer deployment guides, non-secret example inputs, scripts, and validation procedures for the CVD. Use repository release v1.0.0 with this CVD. Retain completed site inputs, rendered manifests, credentials, and sanitized validation results in the site’s approved location outside the repository.

Maintain the Repository

For each CVD revision, repository maintainers should prepare changes on a short-lived branch, run repository validation, and submit the branch for review through a pull request. After review and merge to main, publish the approved commit as release tag v1.0.0. Deployment teams use that tag rather than a development branch.

Use a Published Repository Release

Clone the published repository, switch to release v1.0.0, and read the root and documentation indexes before selecting a platform or workload companion.

Table 60.       Repository Information

 

Appendix C – Bill of Materials

Table 61 lists the Bill of Materials for this CVD.

Table 61.       Bill of Materials

About the author

Anil Dhiman, Technical Leader, Cisco Systems, Inc.

Anil has more than 24 years of experience in data center architecture, Cisco UCS solutions, and performance engineering for large-scale enterprise applications. For over 15 years, he has authored Cisco Validated Designs covering a range of enterprise data center technologies. His current work focuses on hyperconverged infrastructure, data protection, software-defined storage, AI Data Platforms, and generative AI solutions using Cisco compute, networking, and infrastructure-management technologies.

Acknowledgements

For their support and contribution to the design, validation, and creation of this Cisco Validated Design, the author would like to thank:

●     John George, Technical Marketing Engineer, Cisco Systems, Inc.

●     Archana Sharma, Principal Technical Marketing Engineer, Cisco Systems, Inc.

●     Chris O’Brien, Senior Director, Technical Marketing, Cisco Systems, Inc.

●     Jawwad Memon, Director, Product Management, Cisco Systems, Inc.

●     Umar Ali, Sr Product Manager, Cisco Systems, Inc.

●     Daniel Glogowski, Senior Product Manager, NVIDIA

●     Joslyn Shakur, Global GTM Leader, Strategic Partnerships at NVIDIA

●     Andy Pernsteiner, Field CTO, VAST Data

●     Rob Girard, Principal Technical Marketing Engineer, VAST Data

●     Jeremy Palumbo, Field CTO, VAST Data

●     Yoni Shelach, Software Engineer, VAST Data

●     Simon Golan, Data Solutions Team Lead, VAST Data

●     Sarathy Krishna, Customer Success, VAST Data

●     Bryan Schramm, Global Field CTO, VAST Data

CVD Program

ALL DESIGNS, SPECIFICATIONS, STATEMENTS, INFORMATION, AND RECOMMENDATIONS (COLLECTIVELY, "DESIGNS") IN THIS MANUAL ARE PRESENTED "AS IS," WITH ALL FAULTS. CISCO AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THE DESIGNS, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

THE DESIGNS ARE SUBJECT TO CHANGE WITHOUT NOTICE. USERS ARE SOLELY RESPONSIBLE FOR THEIR APPLICATION OF THE DESIGNS. THE DESIGNS DO NOT CONSTITUTE THE TECHNICAL OR OTHER PROFESSIONAL ADVICE OF CISCO, ITS SUPPLIERS OR PARTNERS. USERS SHOULD CONSULT THEIR OWN TECHNICAL ADVISORS BEFORE IMPLEMENTING THE DESIGNS. RESULTS MAY VARY DEPENDING ON FACTORS NOT TESTED BY CISCO.

CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unified Computing System (Cisco UCS), Cisco UCS B-Series Blade Servers, Cisco UCS C-Series Rack Servers, Cisco UCS S-Series Storage Servers, Cisco UCS X-Series, Cisco UCS Manager, Cisco UCS Management Software, Cisco Unified Fabric, Cisco Application Centric Infrastructure, Cisco Nexus 9000 Series, Cisco Nexus 7000 Series. Cisco Prime Data Center Network Manager, Cisco NX-OS Software, Cisco MDS Series, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study,  LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trade-marks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries. (LDW_P4)

All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0809R)