Composable Infrastructure: Treat Your Infrastructure as Code … · Evolving Infrastructure Models...

Composable Infrastructure: Treat Your Infrastructure as Code

Evolving Infrastructure Models

• Richard Fichera, VP and principal analyst, Forrester Research

Cisco’s View of Composable Infrastructure

• Jim Leach, Director of Platform Strategy, Cisco

• Todd Brannon, Director of UCS Marketing, Cisco

Roundtable Discussion

• Richard, Jim and Todd

Agenda

Evolving Infrastructure Models Forrester Research

Richard Fichera VP & Principal Analyst

January 21, 2016

4 © 2016 Forrester Research, Inc. Reproduction Prohibited

At the Heart of the Problem: Complexity,

Scale and Shifting Architectural Models

© 2016 Forrester Research, Inc. Reproduction Prohibited 5

You’ve seen this before – this is our world

This is not new – what is new is the number of decimal places.

And it is more than just volume, it is also underlying complexity, forcing

a change in the way we engineer our infrastructure, incorporating new

relationships between data and processing

Growth: Inexorable Simple, Ubiquitous, Painful


Our view: Data growth combined with the desire for infrastructure flexibility are forcing enterprise and midsized companies to rethink their both their data management and their network architectures.

• Storing more data for every business operation,.

• Performance requirements continue to increase

• Storage to compute ratios are highly variable

STORAGE MUST BE FASTER, SMARTER AND EASIER TO PROVISION!

Explosive Growth Is Changing Storage and Processing Requirements

VELOCITY, EFFICIENCY & SCALABILITY ARE KEY CHALLENGES, AND MATCHING STORAGE

TO CPU BECOMES A CHALLENGE


But Architectural Diversity Drives Storage and Processing Requirements

0

2

4

6

8

10CPU

Memory

DiskNetwork -Thru

Network - L

OLTP

MemCache

Search

Analytics

VMInfrastructureLatency and throughput are strongly

linked to network characteristics


The Architectural Dilemma - Cheap or Optimized?

Much of the I&O innovation in the past few years has been focused on trying to

“cheat” this seemingly inviolable rule of operations and infrastructure engineering

Lower TCO Optimal

Budget

pressures

force most

of us here

But

increasingly

we want to

be here


New problems spawned new platforms

Rack systems

Blade Systems

Software-Defined Storage

Density Advanced Abstraction

Storage flexibility

Density & Abstraction

External Array Integration

Composable Systems


The Reality Today is Most Organizations Have a Complex Set of Infrastructure

Portfolio

Management

Value Rack Enterprise rack

Density

Optimized/HPC

Tower

Blade

Hyperscale/semicustom


Configuration Complexity Costs

› Increased complexity in systems management

› Complexity in vendor management – from both sides. Configuration diversity

makes forecasting, inventory management less precise, leading either to

requirements to carry extra inventory, or delays in acquisition and provisioning.

› Pushing the inventory issue off onto a distributor or the vendor provides illusory

savings – they are smart enough to build it into their costs

› Acquisition delays can impact productivity and time to solution – this is a big

loss

› Cost and management issues can force us into sub-optimal configurations


Can we cheat?

The new wave of composable systems gives us the chance to have both highly

efficient and near-optimal systems in our infrastructure

Lower TCO Optimal

Now

You

Can Have

BOTH


Composable Systems – The Future of Enterprise Infrastructure Definition – A composable system allows individual servers to be “composed” from

pools of CPU/memory, disks and shared network connections.

Pooled Disaggregated Elements

Magic

A “composed” server


Essential Characteristics of Composable Systems

Usable Composition Requires More Than Just A Box of Components

› The composed systems must be indistinguishable from a standard physical

server with the same configuration (CPU, memory, disk and network)

› Composition must be independent of and have no effect on other composed

systems in the same management domain

• Systems must be capable of being “decomposed” and resources returned to pools

› Management functions must be accessible via API as well as CLI/GUI

› Subject to physical limitations imposed by packaging, elements must be as location-

independent as possible


Closing Thoughts

Composable Systems Represent the Missing Link in Software-Defined Data Centers

› Previous approaches to the implementation of SDDC have fallen short due to

lack of a flexible physical layer

• At some point the fluidity of the VM layer ran into the inflexibility of the physical server layer

› Composable systems will allow a flexible coupling of the virtual layer with a

more fluid physical layer

› Vendor differentiation will be along several dimensions

• Number and selection of compute nodes and size of shared storage pools

• Network flexibility, configuration and integration

• Integration with higher levels of the SDDC, including OS, application and complete service

images


A Final Thought – Simple and Uniform Building Blocks Do not Mean Mediocre Outcomes

Cisco’s View of Composable Infrastructure

Cisco Composable Infrastructure Journey

Disaggregation

CPU

Memory

Local Storage

Network I/O

CPU

Memory

Local Storage

Network I/O

SAN I/O

CPU

Memory

Local Storage

Network I/O

SAN I/O

CPU

Memory

Local Storage

Network I/O

SAN I/O

Physical, Fixed Ratio

Monolithic

UCS

Composable

Infrastructure

M-Series Nexus

• Composable systems allow flexible coupling of virtual layer with a more fluid physical layer

• Supports VMs, containers and bare metal applications

Composable Makes the Resources Fluid

X86 Architecture

Operating System

CPU NIC Disk SSD Memory

Application

X86 Architecture

Virtualization Layer

CPU NIC Disk SSD Memory

Intelligent Automation Software

Resource Pool

Ap

p

A

Ap

p

A’

Ap

p

B

Ap

p

B’

Bare Metal Virtualization Operating System

Container Engine

Conta

iner

• Cisco innovation treats hardware as code

• Software object model: hardware in not configured manually

• API centricity: a unified system control plane

• Virtual Interface card (VIC): all network and SAN adapters are software defined

UCS Management: “Infrastructure as Code”

UCS Management

Resource Pool

XML API

UCS Management

Resource Pool

• Determine which resources to allocate

• Compose infrastructure in a set that is optimized for the workload

Service Profiles Optimize Resources

Profile A Profile B

A A A B B B

Shared Local Resources

PCIe

Compute Cartridges

UCS M Series

UCS M-Series: Composable Infrastructure

Shared Local Resources

PCIe

Compute Cartridges

UCS M Series

Shared Local Resources Improved utilization of resources

Based on Cisco System Link Technology Enables disaggregated, composable infrastructure

Modular Design Improved subsystem lifecycle management

Lean Componentry Cost and power optimization

UCS M-Series: Composable Infrastructure

UCS Management and M-Series

System Link connects disaggregated resource elements

Create and modify

service profiles

Model abstracts of

required resources

Resources allocated

from ID pool

UCS Management

Fabric Interconnect

provides network

connectivity and

management Storage

Resources

Network

Resources

Compute

Resources

Power &

Cooling

Resources

Supports multiple types of cartridges and different processor generations

• Preserves investment in system

• Simplified management using service profiles

UCS M-Series: Flexibility

For more information about

Composable Infrastructure

Including videos and papers from other analysts

Go to

www.cisco.com/go/composable

Thank You

www.cisco.com/composable

Composable Infrastructure: Treat Your Infrastructure as Code … · Evolving Infrastructure Models...

Documents

Transcript of Composable Infrastructure: Treat Your Infrastructure as Code … · Evolving Infrastructure Models...