11

HDS TECHNOLOGY DEMONSTRATION

Steve Sonnenberg

May 12, 2014

© Hitachi Data Systems Corporation 2014. All Rights Reserved.

2

INTRODUCTION

Hitachi Data Systems (HDS) is a wholly owned subsidiary of Hitachi global

HDS develops solutions using Hitachi hardware (storage and servers) and resells this equipment outside of Japan

Together we collaborate on OpenStack and other projects‒ Hitachi storage drivers covering all storage offerings

‒ Research and collaboration on other OpenStack issues of global concern

3

HITACHI AND OPENSTACK: ENABLING OUR PLATFORMS

Cinder | FC & FCOE SwiftCinder | iSCSI & NFSCinder | iSCSI

NOVA | KVM

Compute

Storage

Compatible with Icehouse, Support from Havana

4

INTRODUCTION

‒ A way to add a compute node to an OpenStack cluster in a couple of minutes‒ Normally a server needs to be PXE-booted, load a bare OS or

puppet agent, copy the OS, reboot and then perform configuration (e.g. to become a hypervisor)

‒ Elapsed time 5-30min

‒ Demonstration consisted of:‒ Maintaining a set of ‘compute-host’ templates in Cinder

volumes

‒ Represent multiple flavors of hypervisors, etc.

‒ Doing a high-speed volume clone and dynamically setting the iSCSI boot volume

‒ The configuration was part of the template.

‒ OpenStack will register a new compute server when presented with a new IP addresses

‒ Elapsed time < 2min

5

PREPARATION FOR PROVISIONING

5

Hitachi Storage

Server Manager （Ｎｏｖａ）

ＯｐｅｎＳｔａｃｋ

Virtual Server Physical Server

Boot Disk

Storage （Ｃｉｎｄｅｒ）

Hitachi Storage Plugin

・・・

Management Portal

・・・

ＶＭ ＶＭ

・・・

ＶＭ ＶＭ

Hypervisor

・・・

Hypervisor

１

２

Create boot image forVirtual or Physical Server

Create BootTemplate

Boot Disk forVirtual Server

Boot Disk forPhysical Server

Templates

6

PREPARE TO BOOT NEW SERVER

6

Hitachi Storage

Server Manager （Ｎｏｖａ）

ＯｐｅｎＳｔａｃｋ

Virtual Server Physical Server

Boot Disk

Storage （Ｃｉｎｄｅｒ）

Hitachi Storage Plugin

・・・Hyper

Management Portal

・・・

ＶＭ ＶＭ

・・・

ＶＭ ＶＭ

Hypervisor

・・・

Hypervisor

1

3

2

Attach disk asBoot volume

Create Boot disk using HTI Snapshot

Clone boot volume for new server (snapshot-create)

Boot Disk forVirtual Server

7

LAUNCH NEW SERVER; NOW ACTIVE HYPER

7

Hitachi Storage

Server Manager （Ｎｏｖａ）

ＯｐｅｎＳｔａｃｋ

Virtual Server Physical Server

Boot Disk

Storage （Ｃｉｎｄｅｒ）

Hitachi Storage Plugin

・・・Hyper

Management Portal

・・・

ＶＭ ＶＭ

Register Service

・・・

ＶＭ ＶＭ

Hypervisor

・・・

Hypervisor

１

2

Launch new Server (IPMI)

Boot Disk forVirtual Server

Boot Disk forPhysical Server

8

THIS YEAR’S CHALLENGE

Leverage the Hitachi LPAR (logical partitioning) capabilities of its server line‒ Launch instances directly into LPARs

9

IMPORTANCE OF VIRTUALIZATION

OpenStack features support for a wide range of hypervisors‒ Using the Nova ‘BareMetal’ driver and future Ironic support,

OpenStack also supports bare-metal provisioning

‒ Why use bare metal? (just when virtualization was going to save the world)

HDS high-end and mid-range blade servers support a unique type of hardware provisioning known as LPAR (logical partitioning)‒ It provides most of the benefits of bare metal without the

cost

10

Physical Server

Generates Virtual Devices

LPAR VS. HYPERVISOR VIRTUALIZATION

Logical partitioning (LPAR)

‒ Logically dividing compute resources

‒ Similar to mainframe‒ Devices are directly accessible

from guest OSs for better isolation‒ Implemented in firmware for

security and performance‒ Memory is never shared

Virtual machine (VM)

‒ Emulation generates virtual devices

‒ Independent from server hardware constraints

‒ Apps and drivers may need to be written to address virtual devices

LPAR LPAR

Physical Server

Physical CPU

Physical Memory

Physical I/O

Divides Server Hardware

Phys. CPU

Phys. Memory

Phys. I/O

Virtual

CPU

VirtualMemory

VirtualI/O

VM VM

11

HIGH EFFICIENCY

Hitachi LPAR feature logically divides physical compute resources

‒ Resources can be dedicated to a partition for performance or shared for dynamic load balancing

Up to 30 LPARs per blade

Benefits

‒ Near-native performance

‒ Securely isolate partitions for sensitive multi-tenant environments

‒ Optimize efficient use of compute resources

‒ Respond dynamically to changing workloads (in shared mode)

HITACHI LPAR LOGICAL PARTITIONING

© Hitachi Data Systems Corporation 2014. All Rights Reserved.

12

HITACHI DEMO PORTAL

PORTAL SERVER EXTENDS HORIZON FOR OPENSTACK MANAGEMENT

13

LAUNCHING AN INSTANCE INTO AN LPAR (HORIZON)

FLAVOR IS USED TO SELECT AN LPAR

14

RUNNING LPARS

An instance running in an LPAR can be managed like a VM

15

ON THE BLADE SERVER…

LPARs are defined prior to usage

16

SOME FUNCTIONS AREN’T FULLY INTEGRATED

17

LPAR DELETION

18

UNDERLYING TECHNOLOGY

The majority of the launch time is normally spent in copying the image from glance to ephemeral storage‒ Also impacts the footprint of compute servers by requiring

local storage

Using LPARs, a daughter card (mezzanine) provides shared fibre-channel or CNA functions which can be shared (or dedicated) to LPARs

To address the significant delay in copying an image into storage for execution…

Mezzanine Card

19

INTRODUCING HITACHI ENTERPRISE STORAGE

ENTERPRISE

STORAGE

CAPABILITIES

Hitachi provides some of world’sBest storage solutions.

20

KEY TECHNOLOGIES

• Extreme Performance/Reliability

• Storage Virtualization

• Dynamic Storage Pools

• Intelligent Storage Tiering

• Data Protection (local/remote)

• Data Migration

21

REDUCING LAUNCH TIME

Bootable images are maintained as volumes

‘BareMetal’ driver creates a high-speed clone using HTI (Hitachi thin image) and lets the LPAR do a FC boot‒ HTI uses controller-based copy-after-write technology (time

to prepare the images is in seconds)

22

STARTUP TIME

Hitachi servers don’t have quick boot option‒ (if it has memory, it needs to be tested)

Fortunately, LPARs have minimal POST requirements

ENTERPRISE SERVERS HAVE CONSIDERABLE POST DELAYS

23

THE RESULT…

Very fast machine startup time

High isolation between instances

Ability to match VM density / server

Stronger guarantees for performance / latency

Better utilization of constant server improvements

2424

THANK YOU