Skip to content

Cisco UCS Compute

Scope

This file covers Cisco Unified Computing System (UCS) architecture including UCS B-Series blade servers (B200, B480) in UCS 5108 chassis, UCS C-Series rack servers (C220, C240, C480), UCS X-Series modular system (X9508 chassis with X210c and X410c compute nodes), UCS fabric interconnects (FI 6400/6500 series) for unified network and storage connectivity, Intersight cloud management platform (SaaS and Connected Virtual Appliance), service profiles and server templates for stateless computing, firmware management and policy-driven configuration, UCS Manager (UCSM) for on-premises domain management, and HyperFlex hyperconverged infrastructure.

Checklist

  • [Critical] Is the UCS fabric interconnect design defined -- FI pair (always deployed in pairs for redundancy) with appropriate model (6454 for 10/25GbE, 6536 for 100GbE) sized for server count, uplink bandwidth to LAN/SAN, and port capacity including growth -- with fabric failover configured for all vNICs and vHBAs?
  • [Critical] Is the management platform decided -- Intersight (SaaS for cloud-managed operations, recommended for new deployments) vs Intersight Connected Virtual Appliance (on-premises for air-gapped or data-sovereignty environments) vs legacy UCSM (on-premises, being deprecated in favor of Intersight) -- with Intersight licensing tier (Essentials, Advantage, Premier) appropriate for required features?
  • [Critical] Are service profiles (UCSM) or server profiles (Intersight) designed with proper separation of concerns -- identity (UUID, MAC, WWNN/WWPN pools), network (vNIC placement, VLAN policies, QoS), storage (vHBA configuration, SAN boot policy, local disk policy), and boot policy (SAN boot, local boot, iSCSI boot, PXE) -- enabling stateless compute where a server identity can be migrated to any compatible hardware?
  • [Critical] Is the server pool and template strategy defined -- service profile templates (updating template) that propagate changes to all associated servers, with appropriate pool sizes for UUID, MAC, WWNN, and WWPN to avoid address exhaustion, and pool ranges that do not conflict with other UCS domains?
  • [Critical] Is the firmware management strategy defined -- Intersight HCL (Hardware Compatibility List) validation for driver/firmware combinations, firmware policy to control upgrade schedules, and host firmware packages that bundle BIOS, CIMC, adapter, and disk controller firmware into a tested set, with maintenance windows and reboot impact documented?
  • [Recommended] Is the network design for fabric interconnects planned -- LAN uplink port-channels to campus/DC switches (minimum 2 uplinks per FI), SAN uplink port-channels to each SAN fabric (FC 32G or 64G), unified ports configured correctly for FC vs Ethernet, and disjoint layer 2 design (FI-A to SAN-A/network-A, FI-B to SAN-B/network-B) to prevent spanning tree interaction?
  • [Recommended] Is the UCS platform selected appropriately -- X-Series (newest, Intersight-managed only, modular I/O with IFM replacing FEX, supports GPU and accelerator modules) vs B-Series blades (mature, UCSM or Intersight, proven in enterprise but approaching end-of-life for new chassis orders) vs C-Series rack-mount (standalone or FI-attached, for workloads needing more PCIe slots, local storage, or GPU capacity)?
  • [Recommended] Are BIOS policies configured for workload optimization -- high-performance profile for databases and latency-sensitive workloads (disable C-states, enable Turbo Boost, set performance power mode), virtualization profile for hypervisors (enable VT-x/VT-d, hardware-assisted virtualization), and energy-efficient profile for non-critical workloads?
  • [Recommended] Is the local storage policy defined -- disk group policy for RAID configuration (RAID 1 for OS, RAID 5/6 for data), storage profile for M.2 boot optimized (dual M.2 in RAID 1 for hypervisor boot), and NVMe drive policies for high-performance storage workloads?
  • [Recommended] Is the Intersight integration planned for hybrid cloud operations -- Intersight Kubernetes Service (IKS) for container workloads, Intersight Cloud Orchestrator (ICO) for workflow automation, Intersight Workload Optimizer (IWO) for resource right-sizing, and Intersight integration with Terraform for infrastructure-as-code provisioning?
  • [Optional] Is HyperFlex evaluated for hyperconverged use cases -- HyperFlex Edge for remote/branch (2-4 node clusters), HyperFlex Standard for data center (minimum 3 converged + optional compute-only nodes), with awareness that HyperFlex is positioned differently since the Nutanix/Cisco partnership and may have limited future investment?
  • [Optional] Are power and cooling requirements calculated for UCS chassis -- 5108 chassis (4-8 blades, 4 PSU, ~5-8kW loaded), X9508 chassis (8 compute nodes, 6 PSU, ~8-12kW loaded), with redundant power (grid or N+1 PSU) and cooling capacity validated with facilities?
  • [Optional] Is Intersight Assist deployed for integrating third-party endpoints (VMware vCenter, NetApp, Pure Storage, Hitachi) into Intersight for unified infrastructure visibility and cross-domain orchestration?

Why This Matters

Cisco UCS introduced the concept of stateless computing with service profiles, which decouples server identity from hardware and enables rapid provisioning, hardware replacement without reconfiguration, and consistent policy enforcement across large server fleets. However, this abstraction adds complexity -- identity pool exhaustion, template propagation failures, and firmware incompatibilities are the most common UCS operational issues. The transition from UCSM to Intersight is the most significant UCS architectural shift in a decade: Intersight provides cloud-based management with AI-driven insights but introduces a cloud dependency that conflicts with some organizations' operational models. The fabric interconnect is simultaneously the greatest strength and the most critical failure point in UCS -- it provides unified LAN/SAN connectivity through a single management domain, but a misconfigured FI upgrade, incorrect unified port assignment, or spanning tree interaction can take down every server in the domain. Firmware management is deceptively complex because UCS servers have multiple firmware components (CIMC, BIOS, adapter, storage controller, disk) that must be compatible with each other, the hypervisor/OS, and the FI firmware -- Cisco's HCL is the authoritative source but keeping all components aligned requires disciplined policy management.

Common Decisions (ADR Triggers)

  • Intersight SaaS vs Connected Virtual Appliance vs UCSM -- Intersight SaaS is Cisco's strategic direction, provides AI/ML-driven insights and cloud operations, but requires internet connectivity to Cisco cloud. Connected Virtual Appliance (CVA) provides Intersight features on-premises for air-gapped or regulated environments but requires local infrastructure and lacks some SaaS-only features. UCSM is legacy, fully on-premises, and well-understood but receives only maintenance updates. Choose Intersight SaaS for standard enterprise; CVA for government/regulated; UCSM only for existing domains where migration is not yet planned.
  • X-Series vs B-Series vs C-Series -- X-Series is the newest platform with modular I/O (IFM), Intersight-only management, and future GPU/accelerator support. B-Series blades are mature and proven but the 5108 chassis is approaching end-of-new-sale. C-Series rack servers provide maximum flexibility (more PCIe slots, local storage options, GPU support) and can operate standalone or FI-attached. Choose X-Series for greenfield UCS; C-Series for GPU-heavy or high-local-storage workloads; B-Series only to expand existing chassis installations.
  • SAN boot vs local boot vs iSCSI boot -- SAN boot (FC) provides true stateless compute where hardware replacement requires zero OS reinstallation, but requires FC SAN infrastructure and adds complexity. Local boot (M.2 RAID 1 or local disk) is simpler and eliminates SAN dependency but ties the OS to specific hardware. iSCSI boot is a middle ground using IP network for boot but introduces IP storage dependencies. Choose SAN boot for stateless compute with FC SAN; local M.2 boot for hypervisors in environments without FC; iSCSI boot when FC is not available but stateless benefits are needed.
  • Updating vs initial service profile templates -- Updating templates propagate all changes to associated service profiles automatically, enforcing consistency but potentially causing unplanned reboots if firmware or BIOS changes are included. Initial templates create a profile from the template but do not propagate subsequent template changes. Choose updating templates for consistency with strict change control; initial templates when individual server deviation is acceptable.
  • Standalone C-Series vs FI-attached C-Series -- Standalone C-Series servers are managed individually (CIMC/Intersight) with standard network connectivity. FI-attached C-Series connects to fabric interconnects for unified management, service profiles, and centralized network/storage policy. Choose FI-attached when UCS domain management benefits justify the FI infrastructure cost; standalone for small deployments or edge locations without FIs.

See Also

  • general/compute.md -- general compute architecture patterns
  • providers/cisco/switching.md -- Cisco switching and fabric interconnect uplink design
  • providers/vmware/infrastructure.md -- VMware on UCS deployment considerations
  • providers/nutanix/infrastructure.md -- Nutanix on UCS C-Series deployment