Server corridor with red lighting

Data Center Solutions

Data Center, Cloud & AI

Run workloads on infrastructure aligned with capacity, continuity and security goals.

Overview

Server, storage, network and virtualisation layers are assessed alongside application dependencies. Resource consumption, growth expectations and recovery objectives inform the design. A transition plan integrates new capacity with existing operations.

Select infrastructure from workload requirements

Compute, networking and storage design should follow workload capacity and access requirements. Assess applications, data growth, backup dependencies and administrative boundaries before building a product list. Enterprise AI requirements add GPU resources, data access and model lifecycle considerations. The AI POD drawing below is a specific published Cisco reference architecture, not a mandatory component list for every data centre. Establish design and migration decisions with the organisation’s actual workloads and operations team.

CISCO · Figure 5

Cisco AI POD: frontend and backend fabrics

Select nodes to read their roles; zoom or enter full screen to follow the connections.

Nexus Dashboard ClusterND-DATABackend (E-W)Frontend (N-S)ComputeManagementStorageCisco Cloud ControlUnified operations component in the source, with no physical data-path cable.IntersightCisco UCS management. The source does not draw an additional physical link.ND 1One of three management nodes shown in the Nexus Dashboard cluster.ND 2One of three management nodes shown in the Nexus Dashboard cluster.ND 3One of three management nodes shown in the Nexus Dashboard cluster.ND-DATA 1Nexus Dashboard data-network switch attached to the three ND members in the source.ND-DATA 2Nexus Dashboard data-network switch attached to the three ND members in the source.N9364E-SG2BS1Source AI POD backend-spine node; connections are transcribed only from the source figure.N9364E-SG2BS2Source AI POD backend-spine node; connections are transcribed only from the source figure.N9364E-SG2BL1Source AI POD backend-leaf node; connections are transcribed only from the source figure.N9364E-SG2BL2Source AI POD backend-leaf node; connections are transcribed only from the source figure.N9364D-GX2AFS1Source AI POD frontend-spine node; connections are transcribed only from the source figure.N9364D-GX2AFS2Source AI POD frontend-spine node; connections are transcribed only from the source figure.N9332D-GX2BFL1Source AI POD frontend-leaf node; connections are transcribed only from the source figure.N9332D-GX2BFL2Source AI POD frontend-leaf node; connections are transcribed only from the source figure.N9332D-GX2BFL3Source AI POD frontend-leaf node; connections are transcribed only from the source figure.N9332D-GX2BFL4Source AI POD frontend-leaf node; connections are transcribed only from the source figure.UCS C845A-1First illustrated GPU compute node. Backend 4 × 400GbE and frontend 2 × 200GbE are source labels.UCS C845A-NLast illustrated GPU compute node. The ellipsis represents further compute nodes.UCS-X Mgmt. Cluster3 × OpenShift control planeSource cluster representation of three OpenShift control-plane nodes, connected to the compute frontend-leaf pair.Everpure XFMSource storage fabric module connected to both storage leaves and FlashBlade.Everpure XFMSecond source storage fabric module.FlashBlade //S500Shared storage accessed through two XFMs. Each XFM connection is labeled 4 × 100GbE in the source.…Backend: 4 × 400GbE compute · Frontend: 2 × 200GbE computeMgmt: up to 16 × 100GbE · Storage: 4 × 400GbE XFM / 4 × 100GbE FlashBlade
  • Backend fabric (E-W)
  • Frontend / storage (N-S)
  • ND bağlantıları / ND connections
Explore the diagram

Select a node to read its role. Drag to pan or use the buttons to zoom.

The August 2026 inference reference keeps separate backend and frontend fabrics. First and N compute nodes, management cluster and storage modules follow the illustrated scope; intermediate nodes remain an ellipsis. This is not a universal hardware recipe for all AI POD variants. Backend connectivity is represented at compute-group scope; individual NIC/port assignments are not inferred from the first/N icons.

Controlled transition

Inventory and application dependencies establish the baseline. Architecture, capacity expectations and security rules are clarified with the relevant teams. Pilot scope, acceptance criteria and rollback steps are documented before implementation. Migration waves follow business impact; each wave compares essential access, critical application flows and monitoring evidence.

Handover and operations

Topology, configuration ownership and maintenance procedures belong in the handover. Monitoring and escalation follow the organisation’s operating model. Product and service scope is clarified through discovery; support levels are agreed contractually. Share your requirements with Trustnet to assess practical options for your existing infrastructure.

Technology Partners

All technology partners

Services

  • Consulting and Assessment

    We assess your existing infrastructure and business requirements, recommend suitable technology and support optimization and implementation. Our consultancy covers networks, data centers, unified communications, security and network optimization.

  • Architecture Design

    We plan, implement and commission network, server and security infrastructure. Scope includes data centers, virtualization, storage, backup and disaster recovery, with handover and ongoing management where agreed.

  • Deployment and Integration

    We address network, system and security deployment from site readiness through controlled transition and operational handover.