Hitachi Uspv Architecture And Concepts.pdf 474r

Hitachi Universal Storage Platform V – Architecture and Concepts A White Paper

By Alan Benway (Performance Measurement Group, Technical Operations)

Confidential – Hitachi Data Systems Internal Use Only

June 2009

Notices and Disclaimer Copyright © 2009 Hitachi Data Systems Corporation. All rights reserved. The performance data contained herein was obtained in a controlled isolated environment. Actual results that may be obtained in other operating environments may vary significantly. While Hitachi Data Systems Corporation has reviewed each item for accuracy in a specific situation, there is no guarantee that the same or similar results can be obtained elsewhere. All designs, specifications, statements, information and recommendations (collectively, "designs") in this manual are presented "AS IS," with all faults. Hitachi Data Systems Corporation and its suppliers disclaim all warranties, including without limitation, the warranty of merchantability, fitness for a particular purpose and non-infringement or arising from a course of dealing, usage or trade practice. In no event shall Hitachi Data Systems Corporation or its suppliers be liable for any indirect, special, consequential or incidental damages, including without limitation, lost profit or loss or damage to data arising out of the use or inability to use the designs, even if Hitachi Data Systems Corporation or its suppliers have been advised of the possibility of such damages. Universal Storage Platform® is a ed trademark of Hitachi Data Systems, Inc. in the United States, other countries, or both. Other company, product or service names may be trademarks or service marks of others. This document has been reviewed for accuracy as of the date of initial publication. Hitachi Data Systems Corporation may make improvements and/or changes in product and/or programs at any time without notice. No part of this document may be reproduced or transmitted without written approval from Hitachi Data Systems Corporation.

WARNING: This document can only be used as HDS internal documentation for informational purposes only. This documentation is not meant to be disclosed to customers or discussed without a proper non-disclosure agreement (NDA).

Document Revision Level Revision

Date

Description

1.0

December 2007

Initial Release

1.1

April 2008

Updates

2.0

February 2009

Major revision - concepts additions, updates

2.1

June 2009

Changes to MP Workload Sharing, eLUNs, ePorts, Cache Mode, and Concatenated Array Groups discussions, additional tables

Reference Hitachi Universal Storage Platform V Performance Summary 08212008

Contributors The information included in this document represents the expertise, , and suggestions of a number of skilled practitioners. The author would like to recognize and thank the following reviewers of this document: Gil Rangel, Director of Performance Measurement Group - Technical Operations Dan Hood, Director, Product Management, Enterprise Arrays Larry Korbus, Director, Product Management, HDP, UVM, VPM features Ian Vogelesang, Performance Measurement Group - Technical Operations

Table of Contents Introduction .......................................................................................................................................................................... 7 

Glossary ........................................................................................................................................ 7  Overview of Changes ......................................................................................................................................................... 10 

Software Overview ...................................................................................................................... 10  Hardware Overview .................................................................................................................... 11  Processor Upgrade ................................................................................................................................................ 12  Cache and Shared Memory ................................................................................................................................... 12  Features and PCBs ................................................................................................................................................ 13  Architecture Details............................................................................................................................................................ 14 

Summary of Installable Hardware Features ................................................................................ 15  Logic Box Details ........................................................................................................................ 15  Memory Systems Details ............................................................................................................ 16  Shared Memory (SMA) .......................................................................................................................................... 17  Cache Switches (CSW) and Data Cache (CMA).................................................................................................... 18  Data Cache Operations Overview .......................................................................................................................... 20  Random I/O Cache Operations .............................................................................................................................. 20  Sequential I/O Cache Operations and Sequential Detect ...................................................................................... 22  BED and FED Local RAM ...................................................................................................................................... 23 

Front-End Director Concepts ...................................................................................................... 23  FED FC-8 port, ESCON, and FICON: Summary of Features ................................................................................. 25  FED FC-16 port Feature......................................................................................................................................... 25  I/O Request Limits and Queue Depths (Open Fibre) ............................................................................................. 26  MP Distributed I/O (Open Fibre)............................................................................................................................. 27  External Storage Mode I/O (Open Fibre)................................................................................................................ 27 

Front-End Director Board Details ................................................................................................ 28  Open Fibre 8-Port Feature ..................................................................................................................................... 28  Open Fibre 16-Port Feature ................................................................................................................................... 29  ESCON 8-port Feature ........................................................................................................................................... 30  FICON 8-port Feature ............................................................................................................................................ 30 

Back-end Director Concepts ....................................................................................................... 31  BED Feature Summary .......................................................................................................................................... 31 

Back-End-Director Board Details ................................................................................................ 32  BED Details ............................................................................................................................................................ 32 

Back End RAID level Organization ......................................................................................................................... 32 

Universal Storage Platform V: HDU and BED Associations by Frame ....................................... 33  Disk Details ................................................................................................................................. 35  SATA DISKS .......................................................................................................................................................... 36 

HDU Switched Loop Details ........................................................................................................ 38  Universal Storage Platform V Configuration Overviews ................................................................................................. 39 

Small Configuration (2 FEDs, 2 BEDs) ....................................................................................... 39  Midsize Configuration (4FEDs, 4 BEDs) ..................................................................................... 40  Large Configuration (8 FEDs, 8 BEDs) ....................................................................................... 41  Provisioning – Managing Storage Volumes ..................................................................................................................... 42 

Traditional Host-based Volume Management ............................................................................. 42  Traditional Universal Storage Platform Storage-based Volume Management............................ 43  Dynamic Provisioning Volume Management .............................................................................. 45  Usage Overview ..................................................................................................................................................... 46 

Hitachi Dynamic Provisioning Pools............................................................................................ 46  V-VOL Groups and DP Volumes ................................................................................................ 48  Usage Mechanisms ................................................................................................................................................ 50  DPVOL Features and Restrictions ......................................................................................................................... 51  Pool Page Details ................................................................................................................................................... 51  Pool Expansion ...................................................................................................................................................... 53  Miscellaneous Hitachi Dynamic Provisioning Details ............................................................................................. 53  Hitachi Dynamic Provisioning and Program Products Compatibility....................................................................... 54  Universal Storage Platform V Volume Flexibility Example ..................................................................................... 55  Storage Concepts ............................................................................................................................................................... 56 

Understand Your Customer’s Environment ................................................................................ 56  Disk Types .................................................................................................................................. 56  RAID Levels ................................................................................................................................ 57  Parity Groups and Array Groups ................................................................................................. 59  RAID Chunks and Stripes ........................................................................................................... 59  LUNS (host volumes) .................................................................................................................. 60  Number of LUNs per Parity Group .............................................................................................. 60  Port I/O Request Limits, LUN Queue Depths, and Transfer sizes .............................................. 60  Port I/O Request Limits .......................................................................................................................................... 60 

Port I/O Request Maximum Transfer Size .............................................................................................................. 61  LUN Queue Depth .................................................................................................................................................. 61 

Mixing Data on the Physical Disks .............................................................................................. 62  Workload Characteristics ............................................................................................................ 62  Selecting the Proper Disk Drive Form Factor.............................................................................. 63  Mixing I/O Profiles on the Physical Disks .................................................................................... 63  Front-end Port Performance and Usage Considerations ............................................................ 63  Host Fan-in and Fan-out ........................................................................................................................................ 63  Mixing I/O Profiles on a Port................................................................................................................................... 64  Summary ............................................................................................................................................................................. 64  Appendix 1. Universal Storage Platform V (Frames, HDUs, and Array Groups). ......................................................... 65  Appendix 2. Open Systems RAID Mechanisms ............................................................................................................... 66  Appendix 3. Mainframe 3390x and Open-x RAID Mechanisms ...................................................................................... 68  Appendix 4. BED: Loop Maps with Array Group Names ................................................................................................. 71  Appendix 5. FED: 8-Port Fibre Channel Maps with Processors .................................................................................... 72  Appendix 6. FED: 16-Port Fibre Channel Maps with Processors .................................................................................. 73  Appendix 7. FED: 8-Port FICON Maps with Processors ................................................................................................. 74  Appendix 8. FED: 8-Port ESCON Maps with Processors ............................................................................................... 75  Appendix 9. Veritas™ Volume Manager Example .......................................................................................................... 76  Appendix 10. Pool Details ................................................................................................................................................. 77  Appendix 11. Pool Example .............................................................................................................................................. 78  Appendix 12. Disks - Physical IOPS Details .................................................................................................................... 79  Appendix 13. File Systems and Hitachi Dynamic Provisioning Thin Provisioning ..................................................... 82  Appendix 14. Putting SATA Drive Performance into Perspective ................................................................................. 83  Appendix 15. LDEVs, LUNs, VDEVs and More ................................................................................................................. 87  Internal VDEV ........................................................................................................................................................ 92  External VDEV ....................................................................................................................................................... 92  CoW VDEV ............................................................................................................................................................ 93  Dynamic Provisioning VDEV .................................................................................................................................. 93  Layout of internal VDEVs on the parity group ........................................................................................................ 94  Appendix 16. Concatenated Parity Groups ...................................................................................................................... 98  Advantages of concatenated Parity Groups ......................................................................................................... 100  Disadvantages of concatenated Parity Groups: ................................................................................................... 101  Using LDEVs on concatenated Parity Groups as Dynamic Provisioning pool volumes ....................................... 101  Summary of the characteristics of concatenated Parity Groups (VDEV interleave): ............................................ 102 

Hitachi Universal Storage Platform V – Architecture and Concepts A White Paper By Alan Benway (Performance Measurement Group, Technical Operations)  

Introduction This document covers the architecture and concepts of the Hitachi Universal Storage  Platform V.  The  concepts  and  physical  details  regarding  each  hardware  feature  are  covered  in  the  following  sections.   However, this document is not intended to cover any aspects of program products, databases, customer  specific environments, or new features available by the second general release.  Areas not covered by  this document include:        

TrueCopy/Shadow Image/Universal Replicator – Disaster Recovery Solutions  Host ‐ Logical Volume Management – General guidelines  Hitachi Dynamic Link Manager (HDLM) – General guidelines  Universal Volume Management (UVM) – virtualization of external storage for Data  Lifecycle Management (DLM)  Virtual Partition Management (VPM) – General guidelines for workload management   Oracle – General guidelines for storage configuration  Microsoft Exchange – General guidelines for storage configuration  

  This document is intended to familiarize Hitachi Data Systems’ sales personnel, technical  staff,  customers, and value‐added resellers with the features and concepts of the Universal Storage Platform  V. The s that will benefit from this document are those who already possess an in depth knowledge  of the Hitachi TagmaStore Universal Storage Platform architecture.   

Glossary Throughout  this  paper  the  terminology  used  by  Hitachi  Data  Systems  ‐  not  Hitachi  ‐  will  be  normally  used. As some storage terminology is used differently in Hitachi documentation or by the s in the  field, here are some definitions as used in this paper:  

Array Group – The term used to describe a set of four physical disk drives installed as a group in  the subsystem.  When a set of one or two Array Groups (four or eight disk drives) is formatted  using a RAID level, the resulting formatted entity is called a Parity Group.  Although technically  the term Array Group refers to a group of bare physical drives, and the term Parity Group refers  to  something  that  has  been  formatted  as  a  RAID  level  and  therefore  actually  has  parity  data  (here we consider a RAID‐10 mirror copy as parity data), be aware that this technical distinction  is often lost and you will see the  Parity Group and Array Group used interchangeably.  

RESTRICTED CONFIDENTIAL 

Page 7 



BED  –  Back‐end  Director  feature;  the  pair  of  Disk  Adapter  (DKA)  PCBs  providing  4  pairs  of  backend Fibre Channel loops. Pairs of features (4 PCBs, or 8 pairs of loops) are always installed. 



CHA – Hitachi’s name for the FED. 



CMA  –  Cache  Memory  Adapter  board  (8  1064  MB/sec  ports,  4  banks  of  RAM  using  16  DDR2  DIMM slots) 



Concatenated Parity Group ‐ A configuration where the VDEVs corresponding to a pair of RAID‐ 10  (2D+2D)  or  RAID‐5  (7D+1P)  Parity  Groups,  or  a  quad  of  RAID‐5  (7D+1P)  Parity  Groups,  are  interleaved on a RAID stripe by RAID stripe, round  robin basis on their underlying disk drives.   This has the effect of dispersing I/O activity over twice or four times the number of drives, but it  does not change the number, names, or size of VDEVs, and hence it doesn't make it possible to  assign larger LDEVs.  Note that we often refer to RAID‐10 (4D+4D), but this is actually two RAID‐ 10 (2D+2D) Parity Groups interleaved together.  For a more comprehensive explanation see the  Concatenated Parity Group section in the appendix. 



CSW – Cache Switch board (16 1064MB/sec ports), a 2D version of a Hitachi Supercomputer 3D  crossbar switch with nanosecond latencies (port‐to‐port) 



DKC  – Hitachi’s name for  the  base control frame  (or rack) where the Logic Box and  up to 128  disks are located. 



DKA – Hitachi’s name for the BED. 



DP‐VOL  –  a  Dynamic  Provisioning  (DP)  Volume;  the  Virtual  Volume  from  an  HDP  Pool.  Some  documents refer to this as a V‐VOL. It is a member of a V‐VOL Group. Each DPVOL having a   specified size between 8GB and 4TB. 



Feature – an installable hardware option (such as FED, BED, CSW, CMA, SMA) that includes two  PCBs (one per power domain). Note that two BED features must be installed at a time.  



FED – Front‐end Director feature; the pair of Channel Adapter (CHA) PCBs used to attach hosts  to the storage system, providing Open FC, FICON, or ESCON attachment. 



HDU (Hard Disk Unit) – the 64‐disk container in a frame that has 32 disk slots on the front side  and 32 more on the back. The HDU is further split into left and right halves, each on separate  power domains. There are up to four HDUs per expansion frame, and two in the control frame. 



LDEV (Logical Device) – A logical volume internal to the subsystem that can be used to contain  customer  data.   LDEVs  are  uniquely  identified  within  the  subsystem  using  a  six  hex  digit  identifier in the form LDKC:CU:LDEV.  LDEVs are carved from a VDEV (see VDEV), and thus there  are four types of LDEVs ‐ internal LDEVs, external LDEVs, COW V‐VOLs, and DP‐VOLs.  LDEVs may  be mapped to a host as a LUN, either as a single LDEV, or as a set of up to 36 LDEVs combined in  the  form  of  a  LUSE.   Note:  what  is  called  an  LDEV  in  HDS  enterprise  subsystems  like  the  Universal  Storage  Platform  V  is  called  an  LU  or  LUN  in  HDS  modular  subsystems  like  the  AMS  family, and what is called a LUN in HDS enterprise subsystems is called an H‐LUN in HDS modular  subsystems. 



LUN (Logical Unit Number) – the host‐visible identifier assigned by the  to an LDEV to make  it visible on a host port. An internal LUN has a nominal Queue Depth limit of 32, and an external  (virtualized) LUN has a Queue Depth limit of 2‐128 (Adjustable). 

RESTRICTED CONFIDENTIAL 

Page 8 



eLUN (external LUN) – an external LUN Is one which is located in another storage array that is  attached  via  two  or  more  ePorts  on  a  Universal  Storage  Platform  V  and  accessed  by  the  host  through a Universal Storage Platform V.  



ePort  (external Port) – An external array connects via two or more Universal Storage Platform V  Fibre  Channel  FED  ports  on  the  Universal  Storage  Platform  V  instead  to  a  host.  The  FED  ports  used in this manner are changed from a host target into an initiator port (or external Port) by  use of the Universal Volume Manager Software product. The Universal Storage Platform V will  ‘discover’  any  exported  LUNs  on  each  ePort,  and  these  will  be  configured  as  eLUNs  used  by  hosts attached to the Universal Storage Platform V.  



LUSE (Logical Unit Size Expansion) – A concatenation (“spill‐and‐fill”) of 2 to 36 LDEVs (up to a  60TB limit) that is then presented to a host as a single LUN. A LUSE will normally perform at the  level of just one of these LDEVs.  



MP (microprocessor) – the U used on the FEDs and BEDs. Also called CHP (FED) or DKP( BED) 



Parity Group – a set of one or two Array Groups (a set of 4 or 8 disk drives) formatted as a RAID  level, either as RAID‐10 (often referred to as RAID‐1 in HDS documentation), RAID‐5, or RAID 6.   The  Universal  Storage  Platform  V's  Parity  Group  types  are  RAID‐10  (2D+2D),  RAID‐5  (3D+1P),  RAID‐5 (7D+1P), and RAID‐6 (6D+2P).  Internal LDEVs are carved from the VDEV(s) corresponding  to  the  formatted  space  in  a  Parity  Group,  and  thus  the  maximum  size  of  an  Internal  LDEV  is  determined by the size of the VDEV it is carved from.  The maximum size of an internal VDEV is  approximately 2.99 TB.  If the formatted space in a Parity Group is bigger than 2.99 TB, then as  many maximum‐size VDEVs as possible are assigned, and then the remaining space is assigned  as  the  last,  smaller  VDEV.   Note  that  there  actually  is  no  4+4  Parity  Group  type  ‐  see  Concatenated Parity Group. 



PCB – printed circuit board; an installable board (adapter). There are two PCBs per Feature. 



PDEV (Physical DEVice) – a physical internal disk drive.     SMA  ‐  Shared  Memory  Adapter  board  (64  150MB/sec  ports,  2  banks  of  RAM  using  8  DDR2  DIMM slots, up to 8GB) 

    



SVP – Service Processor (a PC running Windows XP) installed in the control rack    VDEV – The logical container from which LDEVs are carved.  There are four types of VDEVs:    o  Internal VDEV (2.99TB max): maps to the formatted space within a parity group that is  available to store  data.  LDEVs carved from a parity group VDEV are called internal  LDEVs.   o External  storage  VDEV  (2.99TB  max):  maps  to  a  LUN  on  an  external  (virtualized)  subsystem.  LDEVs carved from external VDEVs are called external LDEVs.     o Copy  on  Write  (CoW)  VDEV  (2.99TB  max):  called  a  "V‐VOL  group",  and  LDEVs  carved  from a CoW V‐VOL group are called a CoW V‐VOLs   o Dynamic Provisioning (DP) VDEV (4TB max): called a “V‐VOL group”, and LDEVs carved  from a DP V‐VOL group are called a DP‐VOLs (Dynamic Provisioning Volumes).  V‐VOL Group – the organizational container of either a Dynamic Provisioning VDEV or a Copy on  Write VDEV. With Dynamic Provisioning, it is used to hold one or more DP‐Vols.  

RESTRICTED CONFIDENTIAL 

Page 9 

Overview of Changes Expanding on the proven and superior Hitachi TagmaStore Universal Storage Platform technology, the  Universal  Storage  Platform  V  offers  a  new  level  of  Enterprise  Storage,  capable  of  meeting  the  most  demanding  of  workloads  while  maintaining  great  flexibility.  The  Universal  Storage  Platform  V  offers  much higher performance, higher reliability, and greater flexibility than any competitive offering today.  These are the new features that distinguish the completely revamped Universal Storage Platform V from  the previous Universal Storage Platform models:     

Software  o Hitachi Dynamic Provisioning (HDP) volume management feature.  Hardware  o Enhanced Shared Memory system (up to 24GB and 256 paths @ 150MB/s).  o Faster, newer generation 800MHz NEC RISC processors on FEDs (Channel Adapters)  and BEDs (Disk Adapters).  o FEDs MPs have a MP Workload Sharing function (per PCB)  o BEDs have 4Gbit/s back‐end disk loops.  o Switched FC‐AL Loop interface between BEDs and disks.   o Half‐sized PCBs used now (except for Shared Memory PCBs), allowing for more  flexible FED configuration combinations.   o  for internal 1TB 7200 RPM SATA‐II disks.  o  for Flash Drives. 

 

Software Overview The  Universal  Storage  Platform  V  software  includes  Hitachi  Dynamic  Provisioning,  a  major  new  Open  Systems  volume  management  feature  that  will  allow  storage  managers  and  system  s  to  more efficiently plan and allocate storage to s or applications. This new feature provides two new  capabilities:  thin  provisioning  and  enhanced  volume  performance.  Hitachi  Dynamic  Provisioning  provides for the creation of one or more Hitachi Dynamic Provisioning Pools of physical space (each Pool  assigned multiple LDEVs from multiple Parity Groups of the same disk types and RAID level), and for the  establishment  of  DP  volumes  (DPVOLs,  or  virtual  volumes)  that  are  connected  to  a  single  Hitachi  Dynamic Provisioning Pool.    Thin  provisioning  comes  from  the  creation  of  DPVOLs  of  a  ‐specified  logical  size  without  any  corresponding allocation of physical space. Actual physical space (allocated as 42MB Pool pages) is only  assigned  to  a  DPVOL  from  the  connected  Hitachi  Dynamic  Provisioning  Pool  as  that  DPVOL’s  logical  space is written by the host to over time. A DPVOL does not have any Pool pages assigned to it when it is  first  created.  Technically,  it  never  does  –  the  pages  are  “loaned  out”  from  its  connected  Pool  to  that  DPVOL until the volume is deleted from the Pool. At that point, all of that DPVOL’s assigned pages are  returned to the Pool’s Free Page List. Certain individual pages can be freed or ‘reclaimed’ from a DPVOL  using facilities of the Universal Storage Platform V.  The volume performance feature is an automatic result from the manner in which the individual Hitachi  Dynamic  Provisioning  Pools  are  created.  A  Pool  is  created  using  2‐1024  LDEVs  (Pool  Volumes)  that  provide the physical space, and the Pool allocates 42MB Pool pages on demand to any of the DPVOLs  connected to that Pool. Each individual 42MB Pool page is consecutively laid down on a whole number  of  RAID  stripes  from  one  Pool  Volume.  Other  pages  assigned  over  time  to  that  DPVOL  will  randomly  originate from the next free 42MB Page from one of the other Pool Volumes in that Pool.   RESTRICTED CONFIDENTIAL 

Page 10 

As an example, assume that there are 12 LDEVs from twelve RAID‐10 (2D+2D) Parity Groups assigned to  a Hitachi Dynamic Provisioning Pool. All 48 disks in that Pool will contribute their IOPS and throughput  power to all of the DPVOLs connected to that Pool. If more random read IOPS horsepower was desired  for  that  Pool,  then  it  could  have  been,  for  example,  created  with  16  LDEVs  from  16  RAID‐5  (7D+1P)  Parity Groups, thus providing 128 disks of IOPS power to that Pool.   As  up  to  1024  LDEVs  may  be  assigned  as  Pool  Volumes  to  a  single  Pool,  this  would  provide  a  considerable  amount  of  I/O  power  to  that  Pool’s  DPVOLs.  This  type  of  aggregation  of  disks  was  only  possible previously by the use of often expensive and somewhat complex host‐based volume managers  (such  as  VERITAS  VxVM)  on  each  of  the  attached  servers.  On  the  Universal  Storage  Platform  (and  the  Universal  Storage  Platform  V),  the  only  alternative  would  be  to  build  Striped  Parity  Groups  (“Concatenated” Parity Groups – see Appendix 16) using two or four RAID‐5 (7D+1P) Parity Groups. This  would  provide  either  16  or  32  disks  under  the  volumes  (VDEVs)  created  there.  There  is  also  the  LUSE  option,  but  that  is  merely  a  simple  concatenation  of  2‐36  LDEVs,  a  “spill‐and‐fill”  capacity  (not  performance) configuration.  A common question is “How does the performance of DPVOLs differ from the use of Standard Volumes  when  using  the  same  number  of  disks?”  Consider  this  example.  Say  that  you  are  using  32  disks  in  8  Parity  Groups  as  RAID‐10  (2D+2D)  with  8  LDEVs,  all  used  as  Standard  Volumes  over  4  host  paths.  Compare this to a Hitachi Dynamic Provisioning Pool with those same 8 LDEVs as Pool Volumes, with 8  DPVOLs  configured  against  that  Pool  and  used  over  4  host  paths.  If  the  hosts  are  applying  a  heavy,  uniform,  concurrent  workload  to  all  8  Standard  Volumes,  then  the  server  will  see  about  the  same  aggregate IOPS capacity as would be available from the 8 DPVOLs with the same workload. However, if  the  workloads  per  volume  (Standard  or  DPVOL)  are  not  uniform,  or  see  intermittent  workloads  over  time, the DPVOLs will always deliver a constant and much higher IOPS capacity than will the individual  Standard Volumes. If only four volumes (Standard or DPVOL) were simultaneously active, then the four  Standard Volumes would only have a 16‐disk IOPS capacity while the four DPVOLs would always have  the full 32‐disk IOPS  capacity. Another way to see this is that  the use of  Standard Volumes can easily  lead to hot spots, whereas the use of DPVOLs will mostly avoid them.  

Hardware Overview Figure 1. Frame and HDU Map L2 Frame

L1 Frame

Control Frame

R1 Frame

R2 Frame

HDU-4L

HDU-4R

HDU-4L

HDU-4R

HDU-2L

HDU-2R

HDU-4L

HDU-4R

HDU-4L

HDU-4R

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

HDU-3L

HDU-3R

HDU-3L

HDU-3R

HDU-1L

HDU-1R

HDU-3L

HDU-3R

HDU-3L

HDU-3R

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

HDU-2L

HDU-2R

HDU-2L

HDU-2R

HDU-2L

HDU-2R

HDU-2L

HDU-2R

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

LOGIC BOX

HDU-1L

HDU-1R

HDU-1L

HDU-1R

HDU-1L

HDU-1R

HDU-1L

HDU-1R

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD front

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

16 HDD rear

DKU-L2

DKU-L1

RESTRICTED CONFIDENTIAL 

DKC

DKU-R1

DKU-R2

Page 11 

While there are many physically apparent changes to the Universal Storage Platform V chassis and PCB  cards  from  the  previous  Universal  Storage  Platform  model,  there  are  also  a  number  of  not‐so‐evident  internal configuration changes that an SE must be aware of when laying out a system.   The  Universal  Storage  Platform  V  is  a  collection  of  frames,  HDUs,  PCB  cards  in  a  Logic  Box,  FC‐AL  switches  and  disks  (see  Figure  1).  The  frames  include  the  control  frame  (DKC)  and  the  disk  expansion  frames (DKUs). Disks are added to the 64‐disk HDU containers (up to 18 such HDUs) in sets of four (the  Array Group). Array Groups are installed (following a certain upgrade order) into specific HDU disk slots  on either the left or right half (such as HDU‐1R or HDU‐1L) and front and rear of an HDU box. Sets of  HDUs are controlled by one of the BEDs.  

Processor Upgrade The processor (MP) used on the FEDs (the MPs are also called CHPs) and BEDs (the MPs are also called  DKPs)  has  been  improved  and  its  clock  speed  has  been  doubled.  The  quantities  of  processors  represented in Table 1 are values per PCB by feature. A feature is defined as a pair of PCBs where each  board  is  located  on  a  separate  power  boundary.  As  there  are  twice  as  many  FED/BED  features  in  the  Universal Storage Platform V as compared to the Universal Storage Platform, the overall processor count  for FEDs and BEDs remains the same but the available processing power has been doubled.  Table 1. Universal Storage Platform V Processor Enhancements

   Feature 

MPs per PCB  USP  USP V 

FED‐ESCON 8‐port 

‐ 

FED‐ESCON 16‐port 

2 x 400 MHz 

4 x 400 MHz 

‐ 

FED‐FICON 8‐port 

‐ 

4 x 800 MHz 

FED‐FICON 16‐port 

8 x 400 MHz 

4 x 800 MHz 

FED‐FC 8‐port 

‐ 

4 x 800 MHz 

FED‐FC 16‐port 

4 x 400 MHz 

4 x 800 MHz 

FED‐FC 32‐port 

8 x 400 MHz 

‐ 

BED FC‐AL 8‐port 

‐ 

4 x 800 MHz 

BED FC‐AL 16‐port 

8 x 400 MHz 

‐ 

  Cache and Shared Memory  The Data Cache system carries over the same path speeds (1064MB/s) and counts (up to 64 paths) from  the Universal Storage Platform, with a peak wire‐speed bandwidth of 68GB/s. The Shared Memory (or  Control Memory) system has been significantly upgraded over the Universal Storage Platform, with 256  paths (up from 192) operating at 150MB/s (up from 83MB/s), with a peak bandwidth of 38.4GB/s (up  from 15.9GB/s). On the Universal Storage Platform, the FED PCBs had 8 Shared Memory paths, and the  BEDs had 16. Now all of the PCBs have 16 Shared Memory paths.  Note that the Data Cache system contains only the actual  data blocks. The Shared Memory system  holds all of the metadata about the internal Parity Groups, LDEVs, external LDEVs, and runtime tables  for various software products. There can be up to 512GB of Data Cache and 24GB of Shared Memory.  RESTRICTED CONFIDENTIAL 

Page 12 

Features and PCBs Logic boards (PCBs) are installed in the front and rear slots in the Logic Box in the Control Frame. The  logic board types for the Universal Storage Platform V include the following (as features, each a pair of  PCBs):  

CSW – Cache Switch – 1 to 4 features (2 to 8 PCBs) 



CMA – Cache Memory – 1 to 4 features (2 to 8 PCBs) 



SMA – Shared Memory  ‐ 1 or 2 features (2 to 4 PCBs) 



FED – Front‐end Director (or Channel Adapter) – 1 to 14 features (2 to 28 PCBs) 



BED – Back‐end Director (or Disk Adapter) – 2, 4, 6, or 8 features (4, 8, 12, 16 PCBs) of 4Gb/sec  Fibre Channel loops 

The  Universal  Storage  Platform  V’s  new  half‐sized  PCBs  (now  installed  in  upper  and  lower,  front  and  rear  slots  in  the  Logic  Box,  described  later)  allow  for  a  less  costly,  more  incremental  expansion  of  a  system. Also, the BED slots will also  the use of additional FED PCBs (but 2 BED features must be  installed at a minimum). For example, there could be 1‐4 FED features (2‐8 PCBs) installed in a Universal  Storage Platform, and they could be any mixture of Open Fibre, ESCON, FICON, and iSCSI. However, this  gave you a large number of ports of a single type that you may not need, with a substantial reduction of  other port types that you may need to maximize. With the new half‐sized cards, you can have 1‐8 FED  features (or up to 14 FED features if the number of BED features is reduced to just 2), using any mixture  (per feature) of the interface types as before. Now, as there are half as many ports per board, smaller  numbers of lesser used port types may be installed. Features are still installed as pairs of PCB cards just  as with the Universal Storage Platform.  Table 2. Summary of Limits, Universal Storage Platform to Universal Storage Platform V

Limits 

USP 

USP V 

Data Cache (GB) 

128 

512 

Raw Cache Bandwidth 

68 GB/sec 

68 GB/sec 

Shared Memory (GB) 

12 

24 

Shared Memory Paths (max) 

192 

256 

Raw Shared Memory Bandwidth 

15.9 GB/sec 

38.4 GB/sec 

Fibre Channel Disks 

1152 

1152 

SATA Disks 

‐ 

1152 

Logical Volumes 

16k 

64k 

Max Internal Volume Size 

2TB 

2.99TB 

Max CoW Volume Size 

2TB 

4TB 

Max External Volume Size 

2TB 

4TB 

IO Request Limit per FC FED MP 

2048 

4096 

Nominal Queue Depth per LUN 

16 

32 

HDP Pools 

‐ 

128 

Max Pool Capacity 

‐ 

1.1PB 

Max capacity of all Pools 

‐ 

1.1PB 

LDEVs per Pool 

‐ 

1024 

DP Volumes per Pool 

‐ 

8192 

DP Volume Size Range 

‐ 

46MB ‐ 4TB 

  RESTRICTED CONFIDENTIAL 

Page 13 

Other physical Universal Storage Platform V changes include:  

The associations between some BEDs and HDUs have changed 



The associations between FEDs, BEDs, and the CSWs are different. 



The locations of 50% of the Array Group names have shifted around. 



It takes two BED features (4 PCBs) to  the 8‐disk Parity Groups (just as was the case on  the Lightning models). Hence, BEDs must be installed as pairs of features (4 PCBs). 

 

Architecture Details At  the  core  of  the  Universal  Storage  Platform  V  is  a  fourth  generation,  non‐blocking,  high  speed  switched architecture. The Universal Star Network is a fully fault tolerant, high performance, true non‐ blocking switched architecture. These state‐of‐the‐art Hitachi supercomputer derived crossbar switches  are  described  in  more  detail  below.  There  are  no  specific  models  as  there  were  with  the  Universal  Storage Platform products. There is now a single base model onto which upgrade features are applied to  meet the needs of the customer.   Figure 2. Universal Storage Platform V System Components and Bandwidths Overview USP V Universal Star Network 128 control ports x 150 MB/s (19.2 GB/s)

Shared Memory (base) 8-12GB

Cache Memory (base) 8-128GB

Cache Memory (Opt 1) 8-128GB

128 control ports x 150 MB/s (19.2 GB/s)

Shared Memory (option1) 8-12GB

Cache Memory (Opt 2) 8-128GB

Cache Memory (Opt 3) 8-128GB 64 Cache Paths (68 GB/s)

Crossbar Switches 64 concurrent CACHE Paths @ 1064 MB/s CSW 1 (base) 16 ports

CSW 2 (base) 16 ports

CSW 3 (Opt 1) 16 ports

CSW 4 (Opt 1) 16 ports

CSW 5 (Opt 2) 16 ports

CSW 6 (Opt 2) 16 ports

CSW 7 (Opt 3) 16 ports

CSW 8 (Opt 3) 16 ports

64 concurrent FED/BED paths @ 1064 MB/sec

4 - 32 Cache Paths (34 GB/s)

4 - 32 Cache Paths (34 GB/s)

BED

BED

BED

BED

BED

BED

BED

BED

FED

FED

FED

FED

FED

FED

FED

FED

base

Opt 1

Opt 2

Opt 3

Opt 4

Opt 5

Opt 6

Opt 7

base

Opt 1

Opt 2

Opt 3

Opt 4

Opt 5

Opt 6

Opt 7

8 - 64 4Gbit/s DISK LOOPS

1152 DISKS

8 – 224 4Gbit/s FC HOST PORTS

HOSTS / External Storage

 

 

RESTRICTED CONFIDENTIAL 

Page 14 

For quick reference, Figure 2 above depicts the fully optioned Universal Storage Platform V architecture.  Other Universal Storage Platform V configurations are detailed further down. This architecture includes  64 x 1064MB/sec Data paths ‐ representing 68GB/sec of data bandwidth ‐ and 256 x 150MB/sec Control  paths  ‐  representing  38.4GB/sec  of  metadata  and  control  bandwidth.  When  comparing  the  Universal  Storage Platform V to other vendors’ monolithic cache systems (such as EMC DMX4), the aggregate of  the  Universal  Storage  Platform  V’s  Data  +  Control  bandwidths  must  be  used  for  an  apples‐to‐apples  comparison.  The  throughput  aggregate  for  the  fully  optioned  system  is  a  fully  usable  106.4GB/s.  This  includes  any  overhead  for  block  mirroring  operations  that  occur  in  both  the  Data  Cache  and  Shared  Memory systems (discussed further down).   

Summary of Installable Hardware Features The tables below show overviews of the available features for both the Universal Storage Platform and  the Universal Storage Platform V. Except for the Shared Memory PCBs, all of the other PCBs are now half  sized.  The  lower  two  tables  show  the  trade‐off  between  installed  Universal  Storage  Platform  V  BED  features and available Universal Storage Platform V FED features. If someone needs a large number of  ports  (and  reduced  amounts  of  internal  disks  and  performance)  for  virtualization,  additional  FED  features may be installed in the place of up to 6 BED features.  Table 3. Comparison: Universal Storage Platform and Universal Storage Platform V Features

Features

USP

USP V

FEDs  BEDs  Cache  Shared Memory 

1‐7  1‐4  2  2 

1‐14  2, 4, 6, 8  4  2 

2 

4 

Cache Switches     

FED 16-Port Fibre Channel Kits Installed BED PAIRS Installed

FED #1

FED #2

FED #3

FED #4

FED #5

FED #6

FED #7

FED #8

FED #9

FED #10

FED #11

FED #12

FED #13

FED #14

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

1&2 3&4 5&6 7&8

16 16 16 16

32 32 32 32

48 48 48 48

64 64 64 64

80 80 80 80

96 96 96 96

112 112 112 112

128 128 128 128

144 144 144

160 160 160

176 176

192 192

208

224

 

  FED 8-Port FICON or ESCON Channel Kits Installed BED PAIRS Installed

FED #1

FED #2

FED #3

FED #4

FED #5

FED #6

FED #7

FED #8

FED #9

FED #10

FED #11

FED #12

FED #13

FED #14

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

Total Ports

1&2 3&4 5&6 7&8

8 8 8 8

16 16 16 16

24 24 24 24

32 32 32 32

40 40 40 40

48 48 48 48

56 56 56 56

64 64 64 64

72 72 72

80 80 80

88 88

96 96

104

112

 

 

Logic Box Details The Logic Box chassis (main DKC frame) is where all of the different types of PCBs for the features are  installed in specific slots (see Figure 3). This layout is very different from the previous Universal Storage  Platform model. All of the PCBs are now half sized, and there are upper and lower slots in addition to  RESTRICTED CONFIDENTIAL 

Page 15 

the front and back layout. The associations among BEDs, FEDs and the CSWs (cache switches) are also  different. The factory names of the PCB types and their option numbers are shown as well. Note that  FED upgrade features may consume up to six pairs of unused BED slots.  Figure 3. Logic Box Slots (BED slots 3-8 can be used for FEDs if desired) USP-V Rear (Cluster-2)

2QL Opt 3

2PL Opt 1

2NL Opt 4

2ML Opt 3

1FU Opt 2

1EU Opt 1

1DU Basic

1BU Opt 2

1AU Opt 1

UPPER

2RL Opt 4

LOWER

BED-1

2CH Opt 4

BED-3

BED-2

2SD Opt 1

BED-4

CSW-0

2CD Opt 2

CSW-1

FED-1

2TL Opt 7

FED-3

FED-2

2UL Opt 8

FED-4

2VL Opt 3

CMA-4

2WL Opt 8

SMA-1

2XL Opt 7

CMA-2

CMA-3

2MU Opt 1

SMA-2

2NU Opt 2

CMA-1

2PU Basic

FED-5

2QU Opt 1

FED-7

2RU Opt 2

FED-6

2CG Opt 3

FED-8

2SB Opt 2

CSW-2

2CC Opt 1

CSW-3

2TU Opt 5

BED-6

2UU Opt 6

BED-8

2VU Opt 2

BED-5

2WU Opt 6

BED-7

2XU Opt 5

FED-5

CMA-3

SMA-1

CMA-1

FED-2

FED-1

CSW-0

BED-2

BED-1

1LL Opt 7

1KL Opt 8

1Jl Opt 3

1HL Opt 8

1GL Opt 7

1CF Opt 4

1SC Opt 2

1CB Opt 2

1FL Opt 4

1EL Opt 3

1DL Opt 1

1BL Opt 4

1AL Opt 3

FED-7

CMA-4

SMA-2

CMA-2

FED-4

FED-3

CSW-1

BED-4

BED-3

LOWER

FED-6

1CA Opt 1

FED-8

1SA Opt 1

CSW-2

1CE Opt 3

CSW-3

1GU Opt 5

BED-6

1HU Opt 6

BED-8

1JU Opt 2

BED-5

1KU Opt 6

BED-7

1LU Opt 5

UPPER

USP-V Front (Cluster-1)

Memory Systems Details The  Universal  Storage  Platform  V  memory  subsystems  are  unique  among  all  enterprise  arrays  on  the  market.  All  other  designs  use  a  single  global  cache  space  that  controls  the  operation  of  the  array.  All  accesses for data, control tables, metadata, replication software tables and such all go against the same  common cache system. All of these activities compete with one another over the same internal paths  for cache bandwidth. As such, cache access is a primary choke point on competing designs.   The Universal Storage Platform V has four parallel high performance memory systems that isolate access  to data, metadata, control tables and array software. These include:  

Shared Memory (Control Memory) system for metadata and control tables 



Data cache (data blocks only) 



Local RAM pool on each FED and BED PCB (up to 32 such PCBs in an array) for use by the four  MP  processors  on  each  board  (128  processors  in  a  full  array).  This  RAM  is  used  for  the  workspace for each MP, local data block caching and local LUN management tables.  



NVRAM region for each MP that holds the microcode and optional software packages. 

RESTRICTED CONFIDENTIAL 

Page 16 

Shared Memory (SMA) The  SMA  subsystem  is  critical  to  achieving  the  Universal  Storage  Platform  V’s  very  high  array  performance  as  all  control  and  metadata  information  is  contained  within  this  system.  Access  to  and  management of all data blocks in the Data Cache is managed by the SMA system. The SMA subsystem is  unique among all enterprise arrays on the market. All other designs use a single global cache for all data,  metadata, control tables, and software. These other designs create a serialization of access into cache  for all of these competing operations. The SMA design removes all of the non‐data access to Data Cache,  allowing data blocks to be moved unimpeded at very high rates.  The SMA subsystem is sized according to the array configuration (hardware and software). A Universal  Storage Platform V can have up to 24GB of SMA installed across two features (4 PCBs). A section of each  board is mirrored onto the other board of the feature for redundancy.  The Logic Box chassis has slots for four SMA PCBs. One SMA feature is installed in the base system and  one  more  feature  (2  PCBs)  is  an  upgrade  option.  Due  to  the  way  the  Shared  Memory  subsystem  functions,  the  optional  SMA  feature  should  always  be  installed  in  a  system.  As  described  below,  each  FED and BED PCB has 8 paths into the Shared Memory subsystem. It is important to  know that these  paths are hard wired to specific ports on each SMA PCB. Each FED or BED PCB directs 2 SMA paths to  each  installed  SMA  PCB.  With  all  4  SMA  PCBs,  this  means  that  all  8  SMA  paths  per  FED/BED  PCB  are  connected.  Figure 4. Shared Memory PCB

  Each SMA PCB has 8 DDR2‐333 DIMM slots, organized as two separate banks of RAM (4 slots each). A  single board can  up to 8GB of RAM when using either 1GB or 4GB DIMMs. The pair of boards for  each SMA feature is installed in different power domains in the Logic Box (Cl‐1 and Cluster‐2). Each  PCB  has  64  150MB/s  SMA  (control)  paths.  This  provides  for  9.6GB/s  of  bandwidth  (wire  speed)  per  board.  Each  bank  of  RAM  has  a  peak  bandwidth  of  5.19GB/s,  or  a  concurrent  total  of  10.38GB/s  per  board. Due to the very high speed of the RAM compared to the individual SMA ports, with port buffering  and port interleaving, the RAM allows the 64 SMA paths to operate at full speed.  

RESTRICTED CONFIDENTIAL 

Page 17 

For  each  SMA  feature,  there  is  a  small  region  that  is  mirrored  onto  the  other  board  in  that  pair  for  redundancy. (Note: The region used for Hitachi Dynamic Provisioning control is backed up onto a private  disk region on some Pool Volumes.) The Cluster‐1 SMA boards are associated with the Cache‐A region of  the Data Cache (explained below), while the Cluster‐2 boards are associated with the Cache‐B region.  The  basic  configuration  information  for  the  array  is  located  in  the  lower  memory  address  range  of  Shared Memory. This is also backed up on the NVRAM located on each FED and BED PCB in the system.  The  metadata  and  tables  for  optional software  products  (such  as  Hitachi  Dynamic  Provisioning)  in  the  other  (higher)  memory  address  regions  in  Shared  Memory  are  backed  up  to  the  internal  disk  in  the  Service processor (SVP PC) at array power‐down.      Cache Switches (CSW) and Data Cache (CMA) Each  Universal  Storage  Platform  V  has  up  to  8  Data  Cache  boards  (CMA)  and  8  Cache  Switch  boards  (CSW). The cache switches connect the individual cache boards to the cache ports on each FED and BED  board. The Logic Box chassis has slots for 8 Cache Memory (CMA) and 8 Cache Switch (CSW) PCBs. One  CMA  feature  and  one  CSW  feature  are  installed  in  the  base  system  and  three  more  features  (6  PCBs  each) of each type may be added as upgrades. The eight 1064MB/s cache ports on each CMA board are  attached to half of the ports on the “cache side” of central Cache Switches. The “processor side” ports  on  the  Cache  Switches  are  connected  to  FED  and  BED  cache  ports.  Due  to  the  way  the  Data  Cache  subsystem is interconnected through the Cache Switch system, any CMA port on any FED or BED board  can  address  any  cache  board.  As  described  below,  each  FED  and  BED  PCB  has  2  paths  into  the  Cache  Switch subsystem.  

CSW - Cache Switch Each Cache Switch board (CSW) has 16 bidirectional ports (8 to cache ports, 8 to FED/BED ports), each  port operating at 1064MB/s. These cache switches are very high performance crossbar switches as used  in  high  performance  supercomputers  and  servers.  In  fact,  these  CSW  boards  are  a  2D  scaled  down  version  of  a  3D  switch  used  in  Hitachi  supercomputers.  The  CSW  was  designed  by  the  Hitachi  Supercomputer and Hitachi Networks Divisions. The internal port to port latency of this switch is in the  nanosecond range.  The number of CSW features needed depends purely on the number of CHA/DKA features installed.   Adding more CSW features to an existing configuration only permits more FED/BED features to  be installed   

Adding more CSW features does not affect the performance of existing FED/BED features. 

Each CSW board can sustain 8 1064MB/s transfers between the 8 FED/BED paths and the 8 cache ports  for an aggregate of 8.5GB/s per board. As there may be up to four CSW features installed per system (8  CSW  PCBs),  there  can  be  64  cache‐side  ports  switching  among  64  FED/BED  processor  ports.  This  provides  for  a  total  of  68GB/s  per  array  of  non‐blocking,  data‐only  bandwidth  to  cache  from  the  FED/BED  boards  at  extremely  small  (nanosecond)  latency  rates.  No  other  vendor  has  a  non‐blocking  design (despite some unable claims to the contrary), nor are they able to provide sustained data‐ only bandwidth at anywhere near this rate. This bandwidth is not constrained by the type of I/O (read  versus write) since all cache paths are full speed and bidirectional.   Figure  5  illustrates  a  Universal  Storage  Platform  V  array  with  only  two  CSW  and  two  CMA  features  installed. If all four CSW and CMA features (8 boards each) were installed, then each “cache side” path  RESTRICTED CONFIDENTIAL 

Page 18 

on a CSW PCB would go to one of the eight CSA PCBs. Every CSW has at least one path to every CMA.  Farther  down  in  this  document  are  maps  of  associations  of  FEDs  and  BEDs  to  the  CSWs.  There  is  a  certain relationship from the CSW “processor side” to the FED and BED CMA ports.   Figure 5. Universal Storage Platform V with Two Cache Features and Two Cache Switch Features Installed.

Cache

Cache

Cache

Cache

Cache Side

Cache Side

Cache Side

Cache Side

CSW

CSW

CSW

CSW

Processor Side

Processor Side

Processor Side

Processor Side

 

CMA - Data Cache Each  CMA  cache  board  has  16  DDR2‐400  DIMM  slots,  organized  as  four  banks  of  RAM  (thus  32  independent banks in all four features). Each CMA board can  8‐64GB of RAM using a single size  of  DIMM  across  all  installed  CMA  boards.  The  same  amount  of  RAM  must  be  installed  on  each  CMA  board.  The  pair  of  boards  for  a  CMA  feature  is  installed  in  different  power  domains  in  the  Logic  Box  (Cluster‐1 and Cluster‐2).   Each CMA has 8 1064MB/s bidirectional data paths. This provides for 8.5GB/s of read‐write bandwidth  (wire speed) per board. Each bank of RAM has a peak bandwidth of 6.25GB/s, or 25GB/s per board. Due  to  the  very  high  speed  of  the  RAM  compared  to  the  CMA  ports,  with  port  buffering  and  port  interleaving, the RAM allows all 8 CMA cache paths per board to operate at full speed.  Figure 6. Data Cache Board (one of a feature pair)

 

RESTRICTED CONFIDENTIAL 

Page 19 

Data Cache Operations Overview The Data Cache is organized into two contiguous address ranges named Cache‐A and Cache‐B. The RAM  located  across  the  cluster‐1  CMA  boards  is  a  single  address  range  called  Cache‐A,  while  that  of  the  cluster‐2 boards is called Cache‐B. The address range of Cache‐B immediately follows the end of Cache‐A  (illustrated below). This entire space is addressable as units of 2KB cache blocks.  A data block for an I/O  read request can be placed in either Cache range by the BED MP (or FED MP for external storage I/O  operations). Write operations are simultaneously duplexed into both Cache‐A and Cache‐B by the FED  MP processing the request.  Note that only the individual write blocks are mirrored, not the entire cache  space.  Figure 7. Cache Address Space - Cache-A and Cache-B 

The data cache is logically divided up into logical 256KB cache slots across the entire linear cache space  (the  concatenation  of  Cache‐A  and  Cache‐B).  It  is  a  single  uniform  address  space  rather  than  a  set  of  isolated partitioned spaces where only certain devices are mapped to individual regions on independent  cache boards.   When created, each Universal Storage Platform V LDEV (a partition from a Parity Group) is allocated an  initial  set  of  16  cache  slots  for  Random  I/O  operations.  A  separate  set  of  24  cache  slots  is  allocated  when  a  FED  MP  detects  sequential  I/O  operations  occurring  on  that  LDEV.  The  initial  set  of  16  cache  slots  (per  LDEV)  for  use  for  processing  Random  I/O  requests  can  be  temporarily  expanded  by  one  or  more  additional  sets  of  16  random  I/O  256KB  slots  as  needed  (if  available  from  the  associated  cache  partition’s free space).   Since individual LDEVs can dynamically grow to very large sizes in  of their cache footprint based  on the workloads, the use of Cache Partitioning (using the Virtual Partition Management package) can  be  used  to  fence  off  the  cache  space  usable  by  selected  Parity  Groups  (with  all  of  their  LDEVs)  to  manage their maximum allocated random slot sets.    Random I/O Cache Operations Each  logical  256KB  cache  slot  contains  four  logical  64KB  cache  segments.  For  each  cache  slot,  two  of  these  64KB  segments  are  only  used  for  read  operations,  and  two  are  only  used  for  write  operations  (more about this distinction below).  Furthermore, each of the 64KB segments is further sub‐divided into  four  logical  16KB  sub‐segments.  Each  of  these  is  then  divided  into  eight  physical  2KB  Cache  Blocks.  Therefore, each 256KB cache slot contains 64 2KB cache blocks for random reads and another 64 2KB  blocks for random writes. Any cache block in Cache‐A and Cache‐B can be used to build the logical 16KB  sub‐segments (managed by tables in Shared Memory).     RESTRICTED CONFIDENTIAL 

Page 20 

Initial Random Cache Allocation Per LDEV  256KB Cache Slot  64KB Read Segments  64KB Write Segments  16KB Read Sub‐segments  16KB Write sub‐segments  2KB Read Cache Blocks  2KB Write Cache Blocks 

16  32  32  128  128  512  512 

The table above shows the overall breakdown of elements for a set of 16 random I/O cache slots for one  LDEV. Figures 8‐10 below show the relationship among these elements. Figure 8. Random I/O: Logical Cache Slot and Segments Layout 256KB Cache slot (random) 64KB Read segment 64KB Write Segment

64KB Read segment

64KB Write Segment

 

16KB Sub-seg

 

Figure 9. Random I/O: Logical Segment and Sub-segment Layout 64KB Segment 16KB Sub-seg 16KB Sub-seg

16KB Sub-seg

Figure 10. Random I/O: Logical Sub-segments and Physical Cache Blocks Layout 2KB block

2KB block

2KB block

16KB Sub-Segment 2KB block 2KB block

2KB block

2KB block

2KB block

 

  It is because of these small 2KB cache block allocation units that the Universal Storage Platform V does  so  well  with  very  small  block  sizes  and  random  workloads.  In  general,  random  workloads  are  usually  associated with application block sizes of 2KB to 32KB. Other vendors use a single fixed cache allocation  size  (such  as  32KB  and  64KB  for  EMC  DMX)  for  individual  I/O  operations.  Hence,  a  2KB  host  I/O  will  waste 30KB or 62KB of each EMC DMX cache slot. On the IBM DS8000 series, the cache allocation unit is  4KB, thereby avoiding wasting cache space. But the DS8000 arrays are actually general purpose servers  running the AIX operating system using the local shared RAM on individual “processor books”. On both  EMC and IBM, their global cache contains the operating system space, all storage control and metadata,  all  software,  and  all  data  blocks.  On  the  Universal  Storage  Platform  V,  the  CMA  cache  system  is  only  used for  data blocks.  

Write Operations In the case of host writes, the individual data blocks are mirrored (duplexed) to another CMA board on a  different  power  boundary  (i.e.  Cache‐A  and  Cache‐B).  The  mirroring  is  only  for  the  actual    data  blocks, unlike the static mirroring of 50% of cache to the other 50% of cache as is used by EMC for DMX‐ 3 and DMX‐4.   For example, if a host application writes an 8KB block of data, that 8KB block will be written to two CMA  boards,  using  four  2KB  cache  blocks  from  a  64KB  Write  segment  in  Cache‐A  and  another  set  of  four  cache  blocks  from  Cache‐B.  The  FED  MP  that  owns  the  port  on  which  the  host  request  arrived  is  the  processor that performs this duplexing task. After the write has been processed and destaged to disk,  the  8KB  of  mirrored  blocks  will  be  deleted,  and  the  other  8KB  will  remain  in  cache  (after  being  remapped to a Read sub‐segment – see below) for a possible future read hit on that data.   RESTRICTED CONFIDENTIAL 

Page 21 

Note that a read cache hit on data not yet destaged to disk from a Write Segment is not possible. In fact,  no  host  reads  are  directed  against  Write  Segments.  A  read  request  for  a  block  which  still  has  a  write  pending condition will force a disk destage first, and all pending writes in that same 64KB segment will  be included in this forced destage. Similarly, a write cache hit is not possible at any time if a write hit is  meant as “over‐writing a pending write block”. On the Universal Storage Platform V, all blocks written to  cache must be destaged to disk in the order they arrived. There is no “over‐writing” of dirty blocks not  yet written to disks as is the case with a midrange array. On the Universal Storage Platform V, a write hit  actually means that there is empty space in one of that LDEV’s existing write segments already available  for a new I/O request. A write miss would then mean that no such existing space is available, and either  another  set  of  16  random  I/O  cache  slots  will  be allocated  for  use  by  that  LDEV,  or  (if  cache  slots  are  tight) all of the pending writes in that LDEV’s allocated 64KB Write Segments will be destaged, freeing  up all of its random write space. 

Write Pending Limit There  is  a  write  pending  limit  trigger  of  30%  and  70%  per  cache  partition  (the  base  partition  if  others  have not been created using the Virtual Partition Manager product). When the 30% limit is hit, the array  begins  adjusting  the  internal  priority  of  write  operations  higher  than  those  for  reads.  When  the  70%  limit is hit, the array goes into an urgent level of data destage (writes take precedence over reads) to  disk from those 64KB random segments used for writes. If using VPM and cache partitions (and a global  mode setting of 454=ON for the array), in most cases only the 64KB Write Segments within a partition  see  this  urgent  destage  (the  mode  switch  creates  and  averaging  mechanism  to  prevent  all  partitions  from  being  similarly  affected).  Other  partitions  are  generally  isolated  with  their  own  write  pending  triggers.  In  most  cases  a  70%  write  pending  limit  is an  indication  of  too  few  disks  absorbing  the  write  operations. 

Read versus Write Segments There is an interesting event that happens after a Write Segment is processed by a destage operation.  All cache slots, as well as their Read and Write 64KB segments, sub‐segments, and 2KB cache blocks are  actually dispersed across the entire cache space managed at the 2KB cache block level. These 2KB cache  blocks are dynamically remapped to various cache segments. A Write segment cannot be used for reads.  So how does a fresh write that has been destaged become readable as a cache hit for follow‐on read  requests?   Suppose 8KB of data was written to eight 2KB cache blocks (four in one Write Segment, with four more  in a Write Segment mirror). After the disk destage operation occurs, four of those blocks are marked as  free  (from  the  mirrored  Write  Segment)  and  four  are  remapped  into  a  Read  Segment  (thus  becoming  readable for a cache hit). These four “surrendered” blocks from that Write Segment’s address space are  replaced  by  four  unused  2KB  cache  blocks.  The    data  was  not  copied,  but  the  logical  location  of  those blocks did change. All of this is mapping managed in the cache map in Shared Memory system and  occurs  at  RAM  speeds.  In  fact,  nearly  everything  in  the  Universal  Storage  Platform  V  (internal  LDEVs,  external  LDEVS,  Hitachi  Dynamic  Provisioning  pages,  etc.)  is  a  mapped  entity  with  a  high  degree  of  flexibility on how to manage it.  Sequential I/O Cache Operations and Sequential Detect A  separate  set  of  24  cache  slots  is  allocated  to  an  individual  LDEV  when  a  sequential  I/O  pattern  is  detected against that LDEV on a port owned by a FED MP (known as sequential detect). This set of 24  slots  is  released  when  a  sequential  I/O  pattern  is  no  longer  detected.  This  is  one  reason  a  proper  sequential detect state is important on the Universal Storage Platform V. If sequential I/O is broken up  RESTRICTED CONFIDENTIAL 

Page 22 

across several ports on different FEDs (for example), it will look like random I/O to the several individual  MPs controlling those host ports. As an example, the use of a host‐based Logical Volume Manager that  creates a large RAID‐0 volume by striping across several LDEVs on several different host ports can defeat  the sequential detection mechanism. Sequential detect is managed for each LDEV controlled by an MP  on a FED for the one or two FED ports that it owns.  Unlike  the  cache  slots  assigned  for  random  I/O,  each  256KB  cache  slot  is  used  as  a  single  segment  of  256KB for sequential I/O.  This matches the RAID chunk size of 256KB on the disks. In sequential mode,  an entire 256KB chunk is read from or written to each disk. Sequential prefetch will read several such  chunks  into  cache  slots  without  being  instructed  to  do  so  by  the  controlling  MP  on  the  FED  involved.  Sequential  writes  will  be  performed  as  full‐stripe  writes  to  a  Parity  Group,  thus  minimizing  the  write  penalty  for  RAID  levels  5  and  6.  The  data  in  these  sequential  cache  slots  can  be  reusable  for  a  subsequent cache hit. In general, once the data has been processed, these dynamically allocated cache  slots are released for the next sequential I/O operation against that LDEV or are returned to the cache  pool  once  sequential  detect  is  no  longer  present  (for  some  period  of  time)  for  that  LDEV.  However,  certain  lab  tests  do  show  a  high  cache  hit  rate  where  a  small  number  of  LUNs  under  test  have  high  sequential read ratios and use large block sizes (such as 1MB).  Figure 11. Sequential I/O Read Slot 256KB Cache slot (sequential) 256KB Read segment

 

Figure 12. Sequential I/O Write Slot 256KB Cache slot (sequential) 256KB Write segment

 

BED and FED Local RAM There is a pool of RAM installed on each FED or BED PCB. This RAM is shared by the four MP processors  per PCB. This is where the LUN management tables (such as MP Workload Sharing), sequential detect  histograms  and  limited  local  caching  for  highly  reused  data  blocks  are  located.  There  is  also  NVRAM  associated with each MP for holding the system microcode and optional software packages. Note that  other  designs  locate  both  of  these  systems  in  a  monolithic  global  cache  system  and  every  access  for  these  elements  interferes  with    data  block  movement.  On  the  Universal  Storage  Platform  V  the  degree of memory parallelism removes this burden from the data cache system.   When  new  firmware  is  to  be  flashed  into  the  NVRAM  owned  by  each  MP,  the  new  software  is  first  copied  into  the  local  RAM  (over  the  internal  MP‐to‐SVP  network),  and  then,  one‐by‐one,  each  MP  suspends  its  activities,  copies  the  new  microcode  into  its  NVRAM,  and  then  reboots.  The  next  MP  on  that FED or BED board will then follow the same steps until all four MPs are updated.   

Front-End Director Concepts The  Front‐end  Directors  manage  the  access  and  scheduling  of  I/O  requests  to  and  from  the  attached  servers.  The FEDs contain the host ports that interface with the servers or (when using Open Fibre FEDs)  attach to external storage. There are four types of FED features available:  8‐port Open Fibre, 16‐port  Open Fibre, 8‐port FICON, and 8‐port ESCON. The various types of interface options can be ed  simultaneously by mixing FED features within the Universal Storage Platform V.   RESTRICTED CONFIDENTIAL 

Page 23 

Table 4. Comparison: Universal Storage Platform V FED Features

FED Options 

Features 

Total Ports 

  

USP V 

USP V 

Open Fibre 

0‐14 

0‐224 

or 

  

  

ESCON 

0‐8 

0‐64 

or 

  

  

FICON 

0‐8 

0‐64 

  Refer to the Figure below for the following board components discussion.    The  FED  processors  (CHPs,  more  commonly  called  MPs)  manage  the  host  I/O  requests,  the  Shared  Memory  and  Cache  areas,  and  execute  the  microcode  and  the  optional  software  features such as Dynamic Provisioning, Universal Replicator, Volume Migrator, and TrueCopy.   

The  DX‐4  chips  are  Fibre  Channel  encoder‐decoder  chips  that  manage  the  Fibre  Channel  protocol on the cables to the host ports. 



The Data Adapter (DTA) chip is a special ASIC for communication with the CSWs.  



The Microprocessor Adapter (MPA) is an ASIC for communication with the SMA PCBs.   



All I/O, whether it is Reads or Writes, internal or external storage, must  through the Cache  and Shared Memory systems.  

Figure 13. Example of a Universal Storage Platform V FED Board (16-port Open Fibre Feature) 

MPA

RESTRICTED CONFIDENTIAL 

Page 24 

FED Microcode Updates The Universal Storage Platform V microcode is updated by flashing each MP’s NVRAM in the FED PCBs. A  copy of this microcode is saved in the local RAM on each FED PCB, and each MP on the PCB (four MPs)  will  perform  a  hot  upgrade  in  a  rolling  fashion.  While  host  ports  are  still  live,  each  MP  will  take  itself  offline, flash the new microcode from the local FED RAM, and then reboot itself. It then returns to an  online  state  and  resumes  processing  I/O  requests  and  executing  the  optional  installed  software.  The  typical time for this process is 30 seconds per MP. This happens independently on each FED PCB and in  parallel.  

FED FC-8 port, ESCON, and FICON: Summary of Features Table 5 shows the Universal Storage Platform V options for the 8‐port Fibre Channel, 8‐port FICON, and  8‐port ESCON features. The front‐end port counts, the FED (CHA) PCB names, and the associated CSWs  are also indicated.   Table 5. 8-port FED Features

FC- 8 port, FICON, ESCON Features Pair FED Boards Ports

CSW

Feature 1 

FED‐1 

FED00 

FED08 

8 

0 

Feature 2  Feature 3  Feature 4  Feature 5 

FED‐2  FED‐3  FED‐4  FED‐5 

FED02  FED01  FED03  FED04 

FED0A  FED09  FED0B  FED0C 

16  24  32  40 

0  1  1  2 

Feature 6  Feature 7 

FED‐6  FED‐7 

FED06  FED05 

FED0E  FED0D 

48  56 

2  3 

Feature 8 

FED‐8 

FED07 

FED0F 

64 

3 

FED FC-16 port Feature Table  6  shows  the  Universal  Storage  Platform  V  options  for  the  16‐port  Fibre  Channel  features.  The  front‐end port counts, the FED PCB names, and the associated CSWs are also indicated. This port count  can be increased up to 224 (using up to 14 FED features) if the number of BED features is minimal (two)  in order to allow for more FED features (by taking 12 BED “slots”). This FED expansion would be used for  adding  a  large  amount  of  external  storage  to  the  Universal  Storage  Platform  V,  where  less  than  256  internal disks would be configured.  Table 6. Universal Storage Platform V FED FC-16 Feature

FC- 16 port Feature Pair FED Boards Feature 1  Feature 2  Feature 3  Feature 4  Feature 5  Feature 6 

RESTRICTED CONFIDENTIAL 

FED‐1  FED‐2  FED‐3  FED‐4  FED‐5  FED‐6 

FED00  FED02  FED01  FED03  FED04  FED06 

FED08  FED0A  FED09  FED0B  FED0C  FED0E 

Ports

CSW

16  32  48  64  80  96 

0  0  1  1  2  2 

Page 25 

Feature 7 

FED‐7 

FED05 

FED0D 

112 

3 

Feature 8  Feature 9  Feature 10 

FED‐8 

FED07 

FED0F 

128 

3 

FED‐9  FED‐10 

(BED3)  (BED4) 

     

144  160 

1  1 

Feature 11  Feature 12  Feature 13 

FED‐11  FED‐12  FED‐13 

(BED5)  (BED6)  (BED7) 

        

176  192  208 

2  2  3 

Feature 14 

FED‐14 

(BED8) 

  

224 

3 

I/O Request Limits and Queue Depths (Open Fibre) Every  fibre  channel  path  between  the  host  and  the  storage  array  has  a  specific  maximum  capacity,  known as the Maximum I/O Request Limit. This is the limit to the aggregate number of requests being  directed  against  the  individual  LUNs.  For  the  Universal  Storage  Platform  V,  this  limit  is  4096,  and  is  associated with each FED MP. On the 16‐port feature, where there are two ports managed by each MP,  4096  is  the  aggregate  limit  across  those  two  ports.    [This  is  handled  differently  for  FICON,  where  the  MP’s limit is 480 for Open Exchange messaging.] However, when a port (actually the associated MP) is  placed in external storage mode (becomes an initiator), the port I/O Request Limit drops to 256.  Queue Depth is the maximum number of outstanding I/O requests per LUN (internal or external). This is  separate from the MP’s port I/O Request Limit. Note that there is no concept of Queue Depth for ESCON  or FICON volumes.  On the Universal Storage Platform V, the per‐LUN nominal queue depth is 32 but can be much higher  (up  to  4096)  in  the  absence  of  other  workloads  on  that  MP’s  ports  for  internal  LUNs.  In  the  case  of  external  (Virtualized) LUNs, the queue  depth can be set to 2‐to‐128 in the Universal Volume Manager  GUI as shown below. Increasing the default queue depth value for external LUNs from 8 up to 32 can  often have a very positive effect (especially Response Time) on OLTP‐like workloads. The actual limit will  depend on how many other concurrently active external LUNs there are on that port.  Figure 14. Storage Navigator Screen Showing External Port Queue Depth Control 

  RESTRICTED CONFIDENTIAL 

Page 26 

MP Distributed I/O (Open Fibre) The Open Fibre FEDs (not available on FICON or ESCON FEDs) on the Universal Storage Platform V have a  new feature known as MP Distributed I/O. Some of the work pertaining to an individual I/O on a single  port may be processed by another MP on the same PCB rather than the MP that normally controls that  port.  [See  Appendix  8  for  the  port‐MP  mappings.]  A  heavily  loaded  MP  can  hand  off  some  tasks  pertaining  to  data,  metadata,  software  (SI,  TC,  HUR),  and  Hitachi  Dynamic  Provisioning  Pool istrative tasks to another MP that is less busy.  MPs can be configured to be in one of four  modes: target (host), HUR‐A (Send), HUR‐B (receive), and initiator (external) mode. MPs must be in the  same mode in order to participate in Distributed I/O. For example, two MPs (on the same board) whose  ports are configured in ‘initiator’ (external) mode will work together.  The Distributed I/O feature is limited to the four MPs on an individual PCB board. Some of this technique  was actually begun in the Universal Storage Platform with code levels V08 and higher, but most of it is  unique  to  the  Universal  Storage  Platform  V  with  its  much  higher  powered  MPs  and  faster  Shared  Memory  system.  The  degree  to  which  Distributed  I/O  is  available  is  dependent  on  the  pattern  of  I/O  requests from the host as well as the internal status of work already in the system, back‐end processing  of pending requests, and so forth.  Distributed I/O on an individual MP begins when it reaches a sustained average 50% busy rate, and is  managed  on  a  round‐robin  basis  with  the  other  available  MPs  on  the  same  FED  board,  taking  into   their current busy state.  A table is kept in local memory to assist in this workload dispatching.   An MP that receives an I/O command over a host path and is currently more than 50% busy will look for  another MP on that board to assist with the operation. This offload does not represent load balancing  among  host  ports,  just  a  degree  of  parallel  processing  of  I/O  commands  to  the  back‐end  based  on  available cycles among the MPs on a board. [Note: When two or more MPs on a FED board are operated  in external mode, we have observed that in some cases there is no “minimum” percent busy threshold  required to trigger the Distributed I/O mode.]   If an MP is doing processing for other MPs and then receives its own host I/O command, this workload  could be distributed among the other MPs on the board. As the processors all get busy, the degree of  sharing rapidly drops off. MPs that currently have no host I/O of their own can work up to a 100% busy  rate on Distributed I/O loads. In the presence of host I/O on a port associated with an MP, the sum of  that MP’s host I/O + distributed I/O must be less than 50%. Once host I/O on an MP exceeds the 50%  busy rate, there is no further acceptance of Distributed I/O by that MP.  When  Fibre  Channel  FED  ports  are  configured  for  external  storage,  the  associated  “owning”  MP  no  longer  participates  in  the  host‐facing  Distributed  I/O  mode.  That  MP,  and  the  one  or  two  ports  it  manages, is placed into “initiator mode”. (Note: Every port on an MP is operated in the same mode.) If  two or more MPs on a PCB are used for external attachment, then they will engage the Distributed I/O  function. At least two MPs must be in “external mode” (thus all of their ports) in order to get Distributed  I/O for external loads on a FED board.    External Storage Mode I/O (Open Fibre) When  using  the  Open  Fibre  FEDs,  each  MP  (and  the  one  or  two  ports  it  owns)  on  the  PCB  may  be  configured  as  one  of  four  modes:  a  target  (accepting  host  requests),  an  initiator  (driving  storage  requests),  as  TC/HUR‐A  (Copy  products  send)  or  as  TC/HUR‐B  (Copy  products  receive).  The  initiator  mode is how other storage arrays are attached to FED ports on a Universal Storage Platform V. Front‐ end  ports  from  the  external  (secondary)  array  are  attached  to  some  number  of  Universal  Storage  RESTRICTED CONFIDENTIAL 

Page 27 

Platform V FED ports as if the Universal Storage Platform V was a server. If using the 16‐port feature,  then both ports managed by an MP are placed into this mode. In essence, that FED MP (and the one or  two ports it owns) is operated as though it was a BED MP. LUNs visible on the external array’s ports are  then remapped by the Universal Storage Platform V out to FED ports attached to hosts.   As I/O requests arrive over other host‐attached FED ports on the Universal Storage Platform V for those  LUNs,  the  normal  I/O  operations  within  the  FED  occur.  The  request  is  managed  by  Shared  Memory  tables and the data blocks go into the data cache. But the request is then routed to the FED MP (not a  BED MP) that controls the external paths where that LUN is located. The external array processes the  request as though it were talking to a server instead of the Universal Storage Platform V.  

Cache Mode Settings The external port (and all LUNs present on it) may be assigned with either “Cache Mode =ON or OFF”  when  it  is  configured  in  the  Universal  Storage  Platform  V.  The  “ON”  setting  processes  I/O  and  Cache  behavior identical to internal LDEVs. The “OFF” setting directs the Universal Storage Platform V to wait  for Write I/O completion until the data is accepted by the external device. The “OFF” setting does not  change other cache handling behavior such as reads to the external LUNs; however this change makes a  significant difference when writing to slower external storage that presents a risk for high write pending  cases to develop. The use of “Cache Mode = ON” will report I/O completion to the host for writes once  the blocks are written to Universal Storage Platform V cache. “Cache Mode = ON” should normally not  be used when high write rates are expected. In general, the rule of thumb is to use “Cache Mode = OFF”. 

Other External Mode Effects Recall from above that the Queue Depth for an external LUN can be modified to be between 2 and 128  in  the  Universal  Volume  Manager  GUI  as  shown  above.  Increasing  the  default  value  from  8  up  to  32  (probably  the  best  choice  overall),  64,  or  perhaps  even  128  can  often  have  a  very  positive  effect  (especially  Response  Time)  on  OLTP‐like  workloads.  Along  with  this,  recall  that  the  maximum  I/O  Request Limit for an external port is 256 (not 4096).  When ports on a PCB are configured for use as external attachment, then their “owning” MP is operated  in initiator mode; there will be no Distributed I/O mode until at least one other MP is so configured.   The external port represents itself as a Windows server. Therefore, when configuring the host type on  the ports on the virtualized storage array, then must be set to “Windows mode”. 

Front-End Director Board Details This  section  discusses  the  details  of  the  four  types  of  FED  features  available  on  the  Universal  Storage  Platform V.  Open Fibre 8-Port Feature The 8‐port Open Fibre feature consists of two PCBs, each with four 4Gb/sec Open Fibre ports. Each PCB  has four 800MHz Channel Host Interface Processors (CHP) and two Tachyon‐DX4 dual ported chips. The  Shared  Memory  (MPA)  port  count  is  now  eight  paths  per  PCB  (double  the  Universal  Storage  Platform  PCB).  See Appendix 5 for ports, names, and MP associations. 

RESTRICTED CONFIDENTIAL 

Page 28 

Figure 15. Universal Storage Platform V 8-port Fibre Channel Feature (showing both PCBs)

Open Fibre 16-Port Feature The 16‐port  Open Fibre feature consists of two PCBs, each with eight 4Gb/sec Open Fibre ports. Each  PCB has four 800MHz Channel Host Interface Processors (CHP) and four Tachyon‐DX4 dual ported chips.  There are eight Shared Memory (MPA) paths per PCB (double the Universal Storage Platform PCB). See  Appendix 6 for ports, names, and MP associations.  Figure 16. Universal Storage Platform V 16-port Fibre Channel Feature (showing both PCBs)

MPA

RESTRICTED CONFIDENTIAL 

MPA

Page 29 

ESCON 8-port Feature The 8‐port ESCON feature consists of two PCBs, each with four 17MB/s ESCON Fibre ports.  Each PCB has  two  800MHz  Channel  Host  Interface  Processors  (CHP)  and  one  ESA0  interface.  There  are  two  Cache  paths  and  eight  Shared  Memory  (MPA)  paths  per  PCB.    See  Appendix  7  for  ports,  names,  and  MP  associations.  Figure 17. Universal Storage Platform V 8-port ESCON Feature (both PCBs shown)

ESA0 400MH CHP z

ESA0 400MH CHP z

400MH CHP z

400MH CHP z

DTA DTA

MPA

DTA DTA

MPA

2 X 1064 MB/sec DATA Only

8 X 150 MB/sec Meta-DATA Only

2 X 1064 MB/sec DATA Only

8 X 150 MB/sec Meta-DATA Only

FICON 8-port Feature The 8‐port FICON feature consists of two PCBs, each with four 4Gb/sec FICON ports.  Each PCB has four  800MHz  Channel  Host  Interface  Processors  (CHP)  and  two  HTP  interface  chips.  There  are  two  cache  Switch paths and eight Shared Memory (MPA) paths per PCB.  See Appendix 8 for ports, names, and MP  associations.  Figure 18. Universal Storage Platform V 8-port FICON Feature (both PCBs shown)

MPA

RESTRICTED CONFIDENTIAL 

MPA

Page 30 

Back-end Director Concepts The Back‐end Directors manage access and scheduling of requests to and from the physical disks.  The  BEDs also monitor utilization of the  loops, Parity Groups, processors, and status of the PCBs in a pair.  The Universal Storage Platform V BED feature (2 PCBs) has four pairs of 4Gb/sec loops ing up to  128 disks. Each PCB has four 800MHz DKP processors and four DRR RAID processors.   The  BED  features  control  the  Fibre  Channel  Loops  that  interface  with  the  internal  disks  (but  not  to  virtualized  external  storage).  Every  I/O  operation  to  the  disks  will    through  the  Cache  and  Shared  Memory  subsystems.  Table  7  lists  the  BED  features,  loop  counts  and  disk  capacities  for  the  Universal  Storage  Platform  V  system.  Note  that  BEDs  must  be  installed  as  pairs  of  Options  (four  PCBs)  due  to  provide  8  pairs  of  loops  to    the  8‐disk  Parity  Groups,  these  being  RAID‐5  (7D+1P)  and  RAID‐6  (6D+2P).   Note that, while the first pair of BED features can actually  384 disks (the 128 disks in the Control  Frame are attached to BED1 and BED2 – see Figure 21 below), HDS has limited the field configuration to   256 disks until the second pair of BED features has been installed.   Table 7. Universal Storage Platform V BED Features

BED Feature Count  (2 PCBs) 

Back‐end Loops Available 

Max Disks  Configurable 

1 BED 

‐ 

‐ 

2 BED 

8 

256 (PM limit) 

3 BED 

‐ 

‐ 

4 BED 

16 

640 

5 BED 

‐ 

‐ 

6 BED 

24 

896 

7 BED 

‐ 

‐ 

8 BED 

32 

1152 

 

BED Microcode Updates The Universal Storage Platform V microcode is updated by flashing the MPs in the BED PCBs. A copy of  this  microcode  is  saved  in  the  local  RAM  on  each  BED  PCB,  and  each  MP  on  the  PCB  (four  MPs)  will  perform  a  hot  upgrade  in  a  rolling  fashion.  While  the  disk  loops  are  still  live,  each  MP  will  take  itself  offline, flash the new microcode from the local BED RAM, and then reboot itself. It then returns to an  online  state  and  resumes  processing  I/O  requests  to  the  disks  on  its  loops.  The  typical  time  for  this  process is 30 seconds per MP. This happens independently on each BED PCB and in parallel.  

BED Feature Summary Table  8  shows  the  Universal  Storage  Platform  V  options  for  the  BED  feature.  The  total  back‐end  loop  counts, the names of the BED PCBs, and the associated CSWs are also indicated. 

RESTRICTED CONFIDENTIAL 

Page 31 

Table 8. BED Features

BED Feature Pair

BED Boards

Loop Pairs

CSW Used

Basic 

BED‐1 

BED10 

BED18 

‐ 

0 

  

BED‐2 

BED12 

BED1A 

8 

0 

Feature 2 

BED‐3 

BED11 

BED19 

‐ 

1 

  

BED‐4 

BED13 

BED1B 

16 

1 

Feature 3 

BED‐5 

BED14 

BED1C 

‐ 

2 

  

BED‐6 

BED16 

BED1E 

24 

2 

Feature 4 

BED‐7 

BED15 

BED1D 

‐ 

3 

  

BED‐8 

BED17 

BED1F 

32 

3 

 

Back-End-Director Board Details BED Details Figure 19 is a high level diagram of the pair of PCBs for the Universal Storage Platform V BED feature.   Figure 19. Universal Storage Platform V 8-port BED Feature (both PCBs shown)

  Back End RAID level Organization Figure 20 is a view of the Universal Storage Platform V’s BED‐to‐disk organization.  This is also how the  Lightning  9900V  was  organized.  These  two  BED  features  (4  PCBs)  can    256  disks,  with  the  exception being BED1 and BED2, which also control the 128 disks in the DKC control frame (hence 384  disks overall). It takes two BED options to  all of the Parity Group types due to the smaller 4‐loop  PCBs. While the second loop from the other controller would take over the load from the failed partner  loop, the subsequent failure of that alternate loop would take down all of the RAID‐10 (4D+4D) or RAID‐ 5 (7D+1P) Parity Groups. Because of this, pairs of BEDs (4 PCBs) must always be installed.  RESTRICTED CONFIDENTIAL 

Page 32 

Figure 20. Universal Storage Platform V Back-end Disk Layout. (2 BED features)

 

Universal Storage Platform V: HDU and BED Associations by Frame Figures 21 and 22 illustrate the layouts of the 64‐disk containers (HDU), the Frames, and the associated  BED ownerships of the Universal Storage Platform V. The names of the ranges of Array Groups are also  shown. There are two views presented: a regular frontal view and a view of the back as seen from the  back.  For example, looking at Figure 21, the bottom of Frame DKU‐R1 shows the front of the HDU whose disks  are controlled by the eight 4Gbit loops on BED‐1 (pg3, yellow) and BED‐2 (pg4, orange). The HDU is split  in half by power domains, where the 32‐disks on the left half (16 on the front and 16 on the back of the  Frame) are attached to BED‐2 and the 32 on the right half go to BED‐1. Note the diagonal offsets of the  HDU halves from front to rear of the two associated 16‐disk groups by HDU power domains.  Figure 21. Front View of the Universal Storage Platform V Frames, HDUs, with BED Ownership DKU-L2 (front view) bed8 bed7 16 HDD

16 HDD

pg18 pg17 HDU bed8 bed7 16 HDD

16 HDD

pg18 pg17 HDU bed6 bed5 16 HDD

16 HDD

pg16 pg15 HDU bed6 bed5 16 HDD

16 HDD

pg16 pg15 HDU power power

DKU-L1 (front view) bed8 bed7 16 HDD

16 HDD

pg10 pg9 HDU bed8 bed7 16 HDD

16 HDD

pg10 pg9 HDU bed6 bed5

DKU-R0 (front view) bed2 bed1

DKU-R1 (front view) bed4 bed3

16 HDD

16 HDD

16 HDD

16 HDD

pg2

pg1

pg6

pg5

HDU bed2 bed1

HDU bed4 bed3

16 HDD

16 HDD

16 HDD

16 HDD

pg2

pg1

pg6

pg5

HDU bed-5 bed-1

HDU bed2 bed1

16 HDD

16 HDD

16 HDD

16 HDD

pg8

pg7

bed-6

bed-2

pg4

pg3

HDU bed6 bed5

bed-7

bed-3

HDU bed2 bed1

bed-8

bed-4

power

power

16 HDD

16 HDD

pg8

pg7

HDU power power

RESTRICTED CONFIDENTIAL 

16 HDD

16 HDD

pg4

pg3

HDU power power

DKU-R2 (front view) bed4 bed3 16 HDD

16 HDD

pg14 pg13 HDU bed4 bed3 16 HDD

16 HDD

pg14 pg13 HDU bed2 bed1 16 HDD

16 HDD

pg12 pg11 HDU bed2 bed1 16 HDD

16 HDD

pg12 pg11 HDU power power

Page 33 

Figure 22. Rear View of the Universal Storage Platform V Frames, HDUs, with BED Ownership DKU-R2 (rear facing view) bed4 bed3 16 HDD

16 HDD

pg14 pg13 HDU bed4 bed3 16 HDD

16 HDD

16 HDD

16 HDD

16 HDD

16 HDD

pg6

pg5

pg2

pg1

16 HDD

16 HDD

pg12 pg11 HDU power power

DKU-L1 (rear facing view) bed8 bed7 16 HDD

16 HDD

16 HDD

16 HDD

16 HDD

pg6

pg5

pg2

pg1

16 HDD

16 HDD

16 HDD

HDU bed-1 bed-5

16 HDD

16 HDD

16 HDD

pg4

pg3

bed-2

bed-6

pg8

pg7

HDU bed2 bed1

bed-3

bed-7

HDU bed6 bed5

bed-4

bed-8

power

power

16 HDD

pg4

pg3

HDU power power

16 HDD

16 HDD

16 HDD

pg8

pg7

HDU power power

16 HDD

pg18 pg17 HDU bed8 bed7 16 HDD

pg10 pg9 HDU bed6 bed5

16 HDD

16 HDD

DKU-L2 (rear facing view) bed8 bed7

pg10 pg9 HDU bed8 bed7

HDU bed2 bed1

HDU bed2 bed1

pg12 pg11 HDU bed2 bed1 16 HDD

DKU-R0 (rear facing view) bed2 bed1

HDU bed4 bed3

pg14 pg13 HDU bed2 bed1 16 HDD

DKU-R1 (rear facing view) bed4 bed3

16 HDD

pg18 pg17 HDU bed6 bed5 16 HDD

16 HDD

pg16 pg15 HDU bed6 bed5 16 HDD

16 HDD

pg16 pg15 HDU power power

 

The  yellow  section  contains  sixteen  4‐disk  “Array  Groups”  whose  names  (used  in  Parity  Group  configurations) are 3‐1 through 3‐16 (or pg3 as indicated). The official name  of these 4‐disk groups (2  DISKS on the front, 2 on the back of the HDU) is “Array Group” even though they could be assigned RAID  level  10  (no  “parity  involved).  See  Appendix‐1  for  maps  of  the  Universal  Storage  Platform  V  Frames  showing the names of the Array Groups and where they are located. Take note of how the locations of  the Array Groups have been shifted between the Universal Storage Platform and the Universal Storage  Platform  V  models.  This  can  have  important  considerations  when  configuring  a  system  if  this  is  not  understood.  Figure 23 below shows the details of a single frame, with its four HDUs (showing front and rear elements  as viewed through the front). Figure 24 is a “zoomed in” look at the front of just one HDU and the details  of its switches and disks.  Figure 23. Details of a Frame, with the HDUs and FSWs. USP-V - R2 Frame HDU Top Rear 8 HDD

HDU Top Front 8 HDD

8 HDD

FSW-R2B-U BED-4 8 HDD

FSW-R2B-L

BED-3

BED-4

8 HDD

8 HDD

8 HDD

8 HDD

BED-3

BED-4

8 HDD

8 HDD

8 HDD

8 HDD

BED-1

BED-2

8 HDD

8 HDD

8 HDD

8 HDD

BED-1

BED-2

8 HDD

8 HDD

HDU Upper Middle Rear 8 HDD

8 HDD

FSW-R2A-L

8 HDD

FSW-R23-L

8 HDD

FSW-R22-L

8 HDD

8 HDD BED-1 FSW-R21-L

8 HDD

HDU Lower Front

FSW-R22-U BED-2

BED-3 FSW-R28-L

FSW-R21-U

HDU Lower Rear 8 HDD

8 HDD

HDU Lower Middle Front

FSW-R23-U BED-2

8 HDD

FSW-R28-U

HDU Lower Middle Rear 8 HDD

BED-3 FSW-R29-L

HDU Upper Middle Front

FSW-R2A-U BED-4

8 HDD FSW-R29-U

8 HDD FSW-R20-U BED-1 FSW-R20-L

8 HDD

  RESTRICTED CONFIDENTIAL 

Page 34 

Figure 24. Closer Look at One HDU and Its Two Switches.

HDU Lower Front 8 HDD

8 HDD FSW-R20-U

BED-2 8 HDD

BED-1 FSW-R20-L

8 HDD

Disk Details The Universal Storage Platform V s a mixture (in Array Group upgrade units of four disks) of up  to 1152 Fibre Channel and/or SATA disks, or up to 128 Flash disks (with 8 BED features) in the place of  128 Fibre Channel or SATA disks. Table 9 illustrates the d size (base‐10), the apparent size in  the tools (still base‐10), and the typical usable (after Parity Group formatting) size of each type of disk.  Also shown is the “rule of thumb” average maximum random IOPS rate for each type of disk when using  most of the surface. The number and size of the LDEVs created per Parity Group determine how much of  its disks’ surfaces are in active use.   As  more  of  the  disk  surface  is  allocated  to  LDEVs  for  a  Parity  Group,  the  farther  the  disk  heads  must  seek. This creates higher average seek times. For example (using a 15k RPM disk), when only using the  outer 25% of the surface the average read seek time can be around 1.8ms (providing about 267 IOPS),  whereas the 100% surface average seek time will be about 3.8ms (about 182 IOPS). For a SATA disk at  7200 RPM, these values are about 4.3ms (119 IOPS) and 8.5ms (79 IOPS). All write IOPS rates for all disks  are  about  5%  lower  due  to  the  higher  seek  precision  required.  See  Appendix  14  for  more  details  on  theoretical estimates of disk IOPS rates.  Normally with the use of disks with different interface rates (such as 4Gbit/s and 2Gbit/s), the backend  loop  performance  for  all  disks  will  drop  to  the  2Gbit  rate  on  each  BED  feature  where  these  disks  are  installed. This is not true of the 3Gbit SATA disks due to the 4Gbit/s speed conversion, the SATA to FC‐AL  protocol conversion, and data buffering that takes place within each SATA disk canister’s logic board.  Table 9. Table of Disk Types and Rule-of-Thumb IOPS Rates

Port  Speed 

d  Size (GB) 

1 TB     SATA     7.2k RPM  750 GB SATA     7.2k RPM  450 GB FC         15k RPM  400 GB FC         10k RPM  300 GB FC         15k RPM  146 GB Flash  146 GB FC         15k RPM  72 GB Flash 

3Gb/sec  3Gb/sec  4Gb/sec  4Gb/sec  4Gb/sec  4Gb/sec  4Gb/sec  4Gb/sec 

1000  750  450  400  300  146  146  72 

976  738.62  432  384  288.2  143.76  143.76  71.5 

927.2  701.7  410.4  364.8  273.8  136.6  136.6  67.9 

80  80  180  130  180  5000 ‐ read 1500 ‐ write  180  5000 ‐read 1500 ‐ write 

  72 GB FC         15k RPM 

4Gb/sec 

72 

71.5 

67.9 

180 

HDD Type 

Apparent  Usable Size  Size (GB)  (GB) 

Nominal Random  IOPS 

  RESTRICTED CONFIDENTIAL 

Page 35 

The type and quantity of disks and the RAID levels chosen for the Universal Storage Platform V will vary  according  to  analysis  of  the    workloads,  performance  and  capacity  requirements.  The  following  sections  provide  information  to  be  considered  when  selecting  which  disks  to  install.  The  table  below  illustrates usable capacities by RAID and disk types for various disk capacities.  Table 10. Disk Types and Usable Capacities by RAID Level 256 HDDs

RAID Levels

512 HDDs

1024 HDDs

Array Groups

Usable Space %

Usable Capacity TB

Array Groups

Usable Space %

Usable Capacity TB

Array Groups

Usable Space %

Usable Capacity TB

32 32

87.5% 75%

202.8 173.9

64 64

87.5% 75%

405.7 347.7

128 128

87.5% 75%

811.3 695.4

64 32 64 32 32

75% 87.5% 50% 50% 75%

77.0 89.8 51.3 51.3 77.0

128 64 128 64 64

75% 87.5% 50% 50% 75%

153.9 179.6 102.6 102.6 153.9

256 128 256 128 128

75% 87.5% 50% 50% 75%

307.8 359.1 205.2 205.2 307.8

64 32 64 32 32

75% 87.5% 50% 50% 75%

68.4 79.8 45.6 45.6 68.4

128 64 128 64 64

75% 87.5% 50% 50% 75%

136.8 159.6 91.2 91.2 136.8

256 128 256 128 128

75% 87.5% 50% 50% 75%

273.6 319.2 182.4 182.4 273.6

64 32 64 32 32

75% 87.5% 50% 50% 75%

51.3 59.9 34.2 34.2 51.3

128 64 128 64 64

75% 87.5% 50% 50% 75%

102.7 119.8 68.4 68.4 102.7

256 128 256 128 128

75% 87.5% 50% 50% 75%

205.3 239.6 136.9 136.9 205.3

64 32 64 32 32

75% 87.5% 50% 50% 75%

25.6 29.9 17.1 17.1 25.6

128 64 128 64 64

75% 87.5% 50% 50% 75%

51.2 59.8 34.1 34.1 51.2

256 128 256 128 128

75% 87.5% 50% 50% 75%

102.4 119.5 68.3 68.3 102.4

64 32 64 32

75% 87.5% 50% 50%

12.7 14.9 8.5 8.5

128 64 128 64

75% 87.5% 50% 50%

25.5 29.7 17.0 17.0

256 128 256 128

75% 87.5% 50% 50%

50.9 59.4 34.0 34.0

1TB SATA RAID5 7D+1P RAID6 6D+2P

450GB FC RAID5 3D+1P RAID5 7D+1P RAID10 2D+2D RAID10 4D+4D RAID6 6D+2P

400GB FC RAID5 3D+1P RAID5 7D+1P RAID10 2D+2D RAID10 4D+4D RAID6 6D+2P

300GB FC RAID5 3D+1P RAID5 7D+1P RAID10 2D+2D RAID10 4D+4D RAID6 6D+2P

146GB FC or Flash RAID5 3D+1P RAID5 7D+1P RAID10 2D+2D RAID10 4D+4D RAID6 6D+2P

72GB FC or Flash RAID5 3D+1P RAID5 7D+1P RAID10 2D+2D RAID10 4D+4D

 

SATA DISKS LDEVs that are created from Parity Groups that use SATA disks can be configured as OPEN‐V or 3390‐M  emulation; therefore these SATA LDEVs are currently usable for mainframe volumes.  SATA  disks  are  constructed  with  a  far  lower  level  of  technological  sophistication  as  compared  to  enterprise‐grade Fibre Channel disks. In general, the differences between  the SATA and Fibre Channel  disks include:    the  amount  of  extreme  technology  and  precision  involved  with  the  materials  used  for  Fibre  Channel  disks  (disk  platter  materials  and  magnetic  layer  sandwiching,  head  technology,  and  head fly height control)  

the degree of error detection and correction (Fibre Channel disks are about double that of SATA)  and processing power (Hitachi Fibre Channel disks are dual processor) 



the expected lifespan with the duty cycles experienced in enterprise class storage 



the overall performance available 

  RESTRICTED CONFIDENTIAL 

Page 36 

When making performance estimates for SATA Parity Groups that use RAID‐6 (6D+2P), one may use as a  rule of thumb that reads and writes will be 50% and 75% lower than with similar RAID‐6 (6D+2P) 146GB  15k RPM Parity Groups.  (Subject to change in summer 2009 with microcode changes.)  The  back‐end  disk  loops  on  the  Universal  Storage  Platform  V  are  operated  at  4Gbit/s,  with  all  disks  connected to these loops via switches. All Hitachi SATA drives operate at 3Gbit/s. SATA drives also only  have one interface connection, whereas Fibre Channel disks are dual ported (they may transfer in and  out of cache on both loops at the time, with one actual transfer possible through the read/write head).  The SATA disk canisters fit into the same Disk Chassis slots as do Fibre Channel disks because each SATA  disk  canister  has  a  built‐in  controller  module.  One  side  of  the  controller  presents  two  4Gbit  Fibre  Channel paths (mimicking a standard Fibre Channel disk), while the inner side operates the 3Gbit SATA‐II  protocol.  There  is  buffering  in  this  controller  that  provides  the  speed  level  matching  between  the  different protocol rates. [Note: This buffering keeps the BED loops from slowing down to a rate below  4Gbit as happens with the 2Gbit 300GB 10k Fibre Channel disks.]   The  SATA  canister  interface  also  performs  a  read‐after‐write  check  on  every  block  (whether  data  or  parity/mirror)  written  to  the  disk.  After  a  block  is  written  to  the  disk,  it  is  read  from  the  surface  and  compared  to  the  buffer  in  the  canister  interface.  While  this  reduces  the  write  rate  by  some  amount  depending  on  the  RAID  level,  this  read  from  the  disk  does  guarantee  that  the  data  was  accurately  written.   Table 11. Physical Disk IOPS Consumed by RAID Level and Disk Type

Fibre Channel / Flash 

HDD IOPS  per Host  Read 

HDD IOPS  per Host  Write 

RAID10 

1 

2 

RAID5 

1 

4 

RAID6 

1 

6 

SATA 

 

 

RAID10 

1 

4 

RAID5 

1 

6 

RAID6 

1 

9 

  Table 11 above shows the actual physical disk IOPS required for read or write operations as a function of  disks type and RAID level. Although RAID‐6 does protect against a double disk failure, the write costs are  high (especially for SATA disks with the extra read‐compare after write by the local disk canister logic),  so  this  must  be  considered  when  deg  a  storage  solution.  Note  that  in  the  case  where  full  stripe  writes  occur,  the  write  penalty  across  the  entire  Parity  Group  will  be  much  lower  since  the  old  parity  block(s) are not read.   Other considerations on the use of SATA versus Fibre Channel when using RAID‐6 include:   the no‐load format times are about 18X longer than with Fibre Channel disks   the no‐load corrective copy times are about 4.4X longer than with Fibre Channel disks   the no‐load disk copy time is about 10X longer than with Fibre Channel disks   there should be 1 spare SATA disk for every 16 disks in use      RESTRICTED CONFIDENTIAL 

Page 37 

Hitachi’s recommendation on suitable uses for SATA volumes is to use them for Nearline storage with a  low frequency of access but online availability, such as:  

Email archives, backups, 2nd and 3rd copies 



Historical data with limited access (medical records, etc.) 



Archived documents for regulatory purposes 



Sound or video files 



Tape replacement 

The  decision  to  use  up  valuable  internal  disk  slots  with  SATA  disks  rather  than  the  much  higher  performing  Fibre  Channel  disks  should  be  carefully  considered.  In  many  cases,  the  use  of  SATA  disks  within  virtualized  storage  on  a  midrange  product  might  make  better  sense.  However,  there  will  be  individual  cases  where  the  use  of  some  internal  slots  for  SATA  drives  will  solve  a  specific  customer  business  solution  in  a  straight  forward  manner.  It  is  not  expected  that  a  Universal  Storage  Platform  V  would normally be configured with a high percentage of SATA disks. 

HDU Switched Loop Details On the previous Universal Storage Platform model, all of the disks attached to a BED PCB were on eight  native FC‐AL Loops. A transfer to the last disk on a loop (could be 32 or 48 disks per loop) would have to   through by logic on all of the disks in front of it. The Universal Storage Platform V introduces a  switched loop back‐end, where all of the drives are still on Arbitrated Loops (all Fibre Channel disks use  FC‐AL, not FC‐SW fabrics), but the switch logic byes all targets on that loop except for the one disk  being  addressed.  This  reduces  the  propagation  time  by  some  microseconds  (not  noticeable),  but  the  primary effect of this change is improved fault detection and correction.   Each HDU has four such FSW switches, two on the front side (32 disks) and two more on the back (32  disks). Each pair of switches is either an “upper” or a “lower” switch as seen in Figure 25. Figure 26 is a  “zoomed” view showing just the left half of the switch.  Figure 25. Full View of the Two Switches on the Front or Rear Half of an HDU To Next HDU/ FSW UPPER FSW PCB

C T L F C

First BED Pair F C C T L

FSW (upper) Port By Control Circuit LOOP SWITCH

Port By Control Circuit LOOP SWITCH

Port By Control Circuit LOOP SWITCH

Port By Control Circuit LOOP SWITCH

Port By Control Circuit LOOP SWITCH

Port By Control Circuit LOOP SWITCH

FSW (upper) Port By Control Circuit LOOP SWITCH

Port By Control Circuit LOOP SWITCH

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

HDD

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

SW

LOOP SWITCH Port By Control Circuit FSW (lower)

LOOP SWITCH Port By Control Circuit

LOOP SWITCH Port By Control Circuit

LOOP SWITCH Port By Control Circuit

LOOP SWITCH Port By Control Circuit

LOOP SWITCH Port By Control Circuit

LOOP SWITCH Port By Control Circuit

C T L F C

Second BED Pair F C C T L

LOOP SWITCH Port By Control Circuit FSW (lower)

LOWER FSW PCB

To Next HDU/ FSW

RESTRICTED CONFIDENTIAL 

Page 38 

Figure 26. Closer View of the Left Half of the Upper and Lower Switches on an HDU

Universal Storage Platform V Configuration Overviews The  Universal  Storage  Platform  V  is  not  being  offered  in  specific  models  as  is  the  Universal  Storage  Platform, but as basic model that is a starting point for configurations that meet a variety of customer  requirements. 

 Small Configuration (2 FEDs, 2 BEDs) The  Universal  Storage  Platform  V  depicted  here  is  comprised  of  16  x  1064MB/sec  Data  paths,  representing 17GB/sec of data bandwidth, and 64 x 150MB/sec Control or Metadata paths, representing  9.6GB/sec of control bandwidth.  Figure 27. Universal Storage Platform V, Small Configuration

  RESTRICTED CONFIDENTIAL 

Page 39 

This system is shown with:       

Up to 128 physical disks in the controller frame.  Two Back‐end‐Director features (BED‐1, BED‐2; 4 PCBs), consisting of 16 4Gb/sec Fibre Channel  loops, for a total back‐end bandwidth of 6.4GB/sec.  One  Cache  Card  feature  (CMA‐1;  2  PCBs)  ing  up  64GB  of  cache  with  a  bandwidth  of  17GB/sec.  One Cache Switch feature (CSW‐0; 2 PCBs) with a total internal data bandwidth of 17GB/sec.  One Shared Memory feature (SMA‐1; 2 PCBs) with a total metadata bandwidth of 9.6GB/sec.  Two  Front‐End‐Director  features  (FED‐1,  FED‐2;  4  PCBs)  ing  either  16  –  ESCON,  16  4Gb/sec FICON, 16 4Gb/sec Fibre Channel, or 32 4Gb/sec Fibre Channel ports. 

 

Midsize Configuration (4FEDs, 4 BEDs) The  Universal  Storage  Platform  V  depicted  here  is  comprised  of  32  x  1064MB/sec  Data  paths,  representing  34GB/sec  of  data  bandwidth,  and  128  x  150MB/sec  Control  or  Metadata  paths,  representing 19.2GB/sec of control bandwidth.   Figure 28. Universal Storage Platform V, Enhanced Configuration

     

 

RESTRICTED CONFIDENTIAL 

Page 40 

This system is shown with:       

Up to 640 physical disks, with 256 in the R1 frame, 256 in the R2 expansion frame, and 128 in  the Control Frame.  Four Back‐end‐Director features (BED‐1, BED‐2, BED‐3, BED‐4; 8 PCBs), consisting of 32 4Gb/sec  Fibre Channel loops, for a total back‐end bandwidth of 12.8GB/sec.  Two  Cache  Card  features  (CMA‐1,  CMA‐2;  4  PCBs)  ing  up  128GB  of  cache  with  a  bandwidth of 34GB/sec.  Two  Cache  Switch  features  (CSW‐1,  CSW‐2;  4  PCBs)  with  a  total  internal  data  bandwidth  of  34GB/sec.  One Shared Memory feature (SMA‐1; 2 PCBs) with a total metadata bandwidth of 19.2GB/sec.  Four  Front‐End‐Director  features  (FED‐1,  FED‐2,  FED‐3,  FED‐4;  8  PCBs)  ing  either  32  ESCON, 32 4Gb/sec FICON, 32 4Gb/sec Fibre Channel, or 64 4Gb/sec Fibre Channel ports (more  if fewer BED features are installed). 

Large Configuration (8 FEDs, 8 BEDs) The  Universal  Storage  Platform  V  depicted  here  is  comprised  of  64  x  1064MB/sec  Data  paths,  representing  68GB/sec  of  data  bandwidth,  and  256  x  150MB/sec  Control  or  Metadata  paths,  representing 38.4GB/sec of control bandwidth.  Figure 29. Universal Storage Platform V, Maximum Configuration

    RESTRICTED CONFIDENTIAL 

Page 41 

This system is shown with:       

Up  to  1152  physical  disks,  128  in  the  control  frame,  256  in  each  of  the  R1,  R2,  L1,  and  L2  expansion frames.  Eight Back‐end‐Director features (16 PCBs), consisting of 64 4Gb/sec Fibre Channel loops, for a  total back‐end bandwidth of 25.6GB/sec.  Four Cache Card features (8 PCBs) ing up 256GB of cache with a bandwidth of 68GB/sec.  Four Cache Switch features (8 PCBs) with a total internal data bandwidth of 68GB/sec.  Two Shared Memory features (4 PCBs) with a total metadata bandwidth of 38.4GB/sec.  Eight Front‐End‐Director features (16 PCBs) ing either 64 ESCON, 64 4Gb/sec FICON, 64  4Gb/sec Fibre Channel, or 128 4Gb/sec Fibre Channel ports (up to 224 in 14 features if only 2  BED features are installed). 

 

Provisioning – Managing Storage Volumes This section will begin with a review of the techniques typically used to manage storage volumes. Some  of these methods are host‐based, while others use existing HDS Enterprise storage system capabilities  such as LUSE or Concatenated Parity Groups. The end of this section will examine the overall details of  the new Hitachi Dynamic Provisioning volume management feature and explain how it works.   

Traditional Host-based Volume Management There are two methods typically used to organize storage space on a server today. One method would  be the direct use of physical volumes as devices for use either as raw space or as file systems (local or  clustered). These are fixed‐size volumes with a small number of disks; as such each volume has a certain  inherent physical random IOPS or sequential throughput (MB/s) capacity. A system  must  carefully  manage  the  aggregate  server  workloads  against  these  individual  volumes.  This  is  shown  in  Figure 30. As workloads exceed a volume’s available space or its IOPS capacity, the  contents must  be manually moved onto a larger or faster (more spindles) volume if possible.  Figure 30. Use of Individual Volumes on a Host

  The alternative method to the use of individual volumes is to use a host‐based Logical Volume Manager  (LVM)  when  the  planned  workloads  require  either  more  space  or  IOPS  capacity  than  the  individual  physical  volumes  can  provide.  The  LVM  can  create  a  single  logical  (virtual)  volume  from  two  or  more  independent physical volumes. This is shown in Figure 31.  

RESTRICTED CONFIDENTIAL 

Page 42 

Figure 31. Use of LUNs in Host-managed Logical Volumes.

  When such a logical volume runs out of space or IOPS capacity, one could replace it with one that was  created with even more physical volumes and then copy all of the  data. In some cases it is best to  create  another  logical  volume  and  then  manually  relocate  just  part  of  the  existing  data  in  order  to  redistribute  the  overall  workload  across  two  such  logical  volumes.  These  two  logical  volumes  would  probably be mapped to the server using separate host paths as well. However, this manual intervention  could become a costly and tedious exercise as workloads grow over time or as new ones are added to  the mix. The problem becomes more complex as new servers are added to the scenario. This requires a  careful and accurate ongoing documentation effort of all of these elements and their usage by the team  of system s. 

Traditional Universal Storage Platform Storage-based Volume Management In  order  to  create  volumes  on  a  Hitachi  enterprise  storage  system,  an    will  first  create  Parity Groups, each from one or two of the 4‐disk Array Groups. These Parity Groups could be any mix of  five types of RAID levels, to include: RAID‐10 (2D+2D), RAID‐5 (3D+1P, 7D+1P) and RAID‐6 (6D+2P). The  next  step  would  be  to  create  volumes  (LDEVs)  of  the  desired  size  from  these  individual  Parity  Groups  using  Open‐V  (or  Open‐X,  but  this  isn’t  recommended)  emulation  on  Open  Systems,  and  3390‐X  emulation for a Mainframe. These “Standard” LDEVs will then be individually mapped  to one or more  host ports as a LUN (an LDEV on a Mainframe). This standard method is shown below in Figure 32.  Figure 32. Standard Volumes LUN

LUN

LUN

LUN

LDEV

LDEV

LDEV

LDEV

Array Group Array Group Array Group Array Group Independent Array Groups

 

In  order  to  change  the  size  of  a  volume  (LDEV)  already  in  use,  one  must  first  create  a  new  one  (if  possible) that was larger than the old one, and then move the contents of the current volume onto the  new one. The new volume would then be remapped on the server to take the mount point of the old  one, which is then retired. This could be accomplished either manually or in a more automated fashion  on  the  Universal  Storage  Platform  and  the  Universal  Storage  Platform  V  with  the  use  of  the  optional  Hitachi Tiered Storage Manager software product.  RESTRICTED CONFIDENTIAL 

Page 43 

On the previous Hitachi Lightning product, the volume sizes were fixed, and limited to a small number of  Open‐X choices. If you needed something bigger than the largest emulation size (Open‐L, at 33GB), the  storage  system‐based  solution  was  to  use  the  LUSE  (Logical  Unit  Size  Expansion)  LDEV  concatenation  feature (Figure 33). Note that as LUSE is a concatenation of 2 to 36 LDEVs (up to a 60TB maximum size),  it often operates with just the IOPS power of those disks under a single LDEV (either 4 or 8 disks). On the  other hand, the host‐based RAID0 striped LVM volume will use the power of all of the disks of the logical  volume all of the time.  Figure 33. LUSE Volume

  On a Hitachi Universal Storage Platform product, with its Open‐V emulation, a single LDEV could be as  large  as  the  entire  Parity  Group  (up  to  2.99TB  for  internal  storage  and  4TB  for  external  storage).  However a single Parity Group might not have sufficient IOPS power (disks) to  the IOPS needed  by the workload on a single volume. You could build a concatenated LUSE volume as with the Lightning,  but  the  use  of  the  Universal  Storage  Platform’s  large  volume  facility  known  as  Concatenated  Parity  Groups is preferred. This feature allows you to create a logical volume that is striped across 2 or 4 RAID‐ 5 (7D+1P) Parity Groups.   The  individual  RAID  stripes  from  those  member  Parity  Groups  are  interleaved  rather  than  the  LDEVs  being  concatenated  as  the  name  implies.  Thus,  one  could  have  2x  or  4x  the  amount  of  IOPS  (not  capacity)  available  per  volume  as  compared  to  a  standard  volume.  Note  that  a  host‐based  LVM  uses  block  striping  (usually  64KB)  whereas  a  Concatenated  Parity  Group  uses  RAID‐5  (7D+1P)  stripe  interleaving of 3,584MB. See Appendix 3 for a detailed discussion of RAID levels, stripe sizes (chunks),  and stripe widths. See Appendix 16 for a more detailed discussion of Concatenated Parity Groups.  Figure 34. Concatenated Parity Group Striped Volume

  All  of  these  techniques  can  be  awkward  and  time  consuming  to  configure.  As  such,  there  is  a  lot  of  potential for error in a busy IT shop. Now there is a new and simpler alternative to the older methods.  The  Hitachi  Dynamic  Provisioning  feature  (HDP)  allows  for  new  volume  management  techniques  that  provide a greater degree of freedom of storage management for s. 

RESTRICTED CONFIDENTIAL 

Page 44 

Dynamic Provisioning Volume Management The new Hitachi Dynamic Provisioning feature allows for the creation of one or more Hitachi Dynamic  Provisioning Pools of physical space (multiple LDEVs from multiple Parity Groups of any RAID level) to   the creation of virtual volumes (DPVOLs).  There are three distinct and unique capabilities that  become available to the  with this feature. These are:  Thin provisioning volumes – a feature where physical space is only allocated to a DPVOL as it is  written to over time. The DPVOL may be specified to be any size up to 4TB when created, and  this  will  be  the  size  the  host  sees  when  scanning  the  port  for  this  new  volume.  The  DPVOL  is  allocated physical space in 42MB pages from a Pool as the host writes to this volume.  This can  be a good method to manage lots of small  s while avoiding a dedicated large, fixed  pool of space to each  up front.  High  performance  volumes  –  the  ability  to  create  Pools  with  the  RAID  level  desired  and  the  number of disks needed to  the desired target IOPS rates of all of the DPVOLs connected  to that Pool.  With the use of the Concatenated Parity Group feature, one could create volumes  that spanned either 16 or 32 disks, but they had to be RAID‐5 (7D+1P). Now, a wide variety of  choices exists for establishing the physical space under DPVOLs. One might create a Log Pool of  4 LDEVs taken from four RAID‐10 (2D+2D) Parity Groups (one large LDEV each) and use this Pool  for DPVOLs assigned to database logs or temp space. One might also then create four Database  Pools,  each  with  8  LDEVs  from  eight  RAID‐5  (7D+1P)  Parity  Groups,  and  use  these  for  the  database files that contain  data. The Log Pool was configured to accept high levels of large  block  sequential  write  workloads,  whereas  the  Database  Pools  are  configured  to    high  levels of random small block OLTP workloads.  Management simplification – though related to and embedded within both of the above topics,  this  requires  some  special  mention  as  a  feature  in  and  of  itself.  Because  of  this  new  ability  to  create  large  and/or  high  performance  volumes,  a  considerable  amount  of  often  complicated  host‐based storage management can be avoided. Rather than use a Logical Volume Manager on  each server to organize volume space (using 2 or more LDEVs as previously described), in many  cases one can now rely on just the Hitachi Dynamic Provisioning feature for this function. None  of the servers would require the extra management of using an LVM.  One  example  of  simplification  would  be  the  Log  Pool  example  from  above.  Another  example  would  be  the  ability  to  manage  s  and  space  quite  easily  in  a  Microsoft  Exchange  Server  environment. Since only four Storage Pools are available in Exchange 2003 (i.e. four volumes), it  is  necessary  to  carefully  balance  the    types  (regular  or  Blackberry)  among  these  four  volumes because of their significant workload differences and the IOPS limitations of a Standard  volume  from  a  4‐disk  or  8‐disk  Parity  Group.  In  addition  to  the  use  of  one  Standard  LDEV  of  RAID‐10 for the logs, there could be four DPVOLs created from one or two Pools for these four  Storage Groups. A storage  is now in control of deg the desired physical IOPS  rates available per Storage Group. As such, Exchange s may be added to any Storage Group  in a simple round‐robin method without being concerned with what type of  they may be,  how many IOPS they may consume, and how much space they may need in the future.     

 

RESTRICTED CONFIDENTIAL 

Page 45 

The  Figure  below  is  an  overview  of  a  single  Pool  environment  used  for  discussion  purposes  in  the  following sections. See Appendices 9‐11 for additional detailed views.  Figure 35. An Hitachi Dynamic Provisioning Pool Environment

Usage Overview In order to use Dynamic Provisioning volumes, there are a few extra steps to take when creating them.  One  still  configures  various  Parity  Groups  to  the  desired  RAID  level  (see  D),  and  then  creates  one  or  more  Open‐V  volumes  (LDEVs)  on  each  of  them.  The  first  new  step  in  setting  up  an  Hitachi  Dynamic  Provisioning environment would be to create one or more Hitachi Dynamic Provisioning Pools (see C)  that  are  each  collection  of  selected  LDEVs  (Hitachi  Dynamic  Provisioning  Pool  Volumes).  The  second  step  would  be  to  create  one  or  more  V‐VOL  Groups  (see  B),  which  are  istrative  containers  for  virtual volumes (used as pseudo‐Parity Groups). The third step is to create one or more Hitachi Dynamic  Provisioning  Volumes  (DPVOLs),  each  assigned  to  one  V‐VOL  Group,  and  each  connected  to  a  single  Pool. The DPVOL is then mapped to a host port as a LUN (see A) with a host server emulation mode and  used just like any Standard LDEV. 

Hitachi Dynamic Provisioning Pools Each  Hitachi  Dynamic  Provisioning  Pool  (up  to  128  Pools  per  Universal  Storage  Platform  V  system)  provides  the  physical  space  for  all  of  the  DPVOLs  which  are  connected  to  that  Pool.  Each  Hitachi  Dynamic Provisioning Pool is given a name which is used when connecting newly defined DPVOLs. The  LDEVs assigned to a Pool must be of type OPEN‐V. The size of each LDEV must be at least 8GB, but no  more than 4TB. The size  used for LDEVs should be a multiple of 42MB, as Pool space is allocated and  managed in that size. Once assigned to a Pool, these LDEVs are called Pool Volumes. A Pool’s size must  fall  between  8GB  (1  Pool  Volume,  minimum  size)  and  1.1PB  in  size,  although  the  aggregate  size  of  all  RESTRICTED CONFIDENTIAL 

Page 46 

Pools (and all non‐Hitachi Dynamic Provisioning volumes) on a Universal Storage Platform V must be less  than 1.1PB.   Figure 36. Hitachi Dynamic Provisioning Pool and DPVOL Limits

HDP Limits  Maximum number of Pools  Maximum Pool capacity  Maximum capacity of all Pools     Pool Allocation Warning Thresholds  fixed:   adjustable:     Emulation  RAID Level     Number of LDEVs per Pool 

128  1.1PB  1.1PB        80%  5‐95%     Open‐V  any     2‐1024  2.99TB internal  4TB external  8GB     65,536  8192 

Maximum LDEV size  Minimum LDEV size     Maximum DP Volumes per system  Maximum DP Volumes per Pool  DP Volume size range 

46MB ‐ 4TB 

  The Pool Volume sizes are important in that they control the striping rate in the Free Page List (at the  “Optimize” step in Pool setup). If all Pool Volumes are the same size, and if they come from the same  type of Parity Groups (i.e. 2D+2D or 7D+1P), then the Pool will present an even distribution of I/O across  the AGs in that Pool to all of its connected DPVOLs. The actual size (if uniform for all of the LDEVs) does  not matter except that it will determine how soon the Pool runs out of initial physical space. You must  scale your usage expectations against how big the Pool needs be when it first starts out. Additional Pool  Volumes may be added to a Pool when its space begins to run low (explained in Pool Expansion below),  with an overall limit of 1024 LDEVs per Pool.  You should use the same disk type and RAID level for every Pool Volume within a Pool. Additionally, all  of the LDEVs from a Parity Group should be assigned to the same Pool. It is recommended that there be  32 or more disks per Pool in order to have an adequate disk IOPS pool. This could be four 8‐disk Parity  Groups (such as 4D+4D, with four LDEVs each) or eight 4‐disk Parity Groups (such as RAID‐5 3D+1P).   There are various restrictions on the LDEVs used for Pools. These restrictions include:  

There  can  be  a  maximum  of  1024  Pool  Volumes  assigned  to  a  single  Hitachi  Dynamic  Provisioning Pool. 



Pool Volumes (LDEVs) must come from internal disks or external storage on the same Universal  Storage Platform V (can’t create Pools across systems). 



Pool Volumes must be of the OPEN‐V emulation type.  

RESTRICTED CONFIDENTIAL 

Page 47 



A Pool Volume is an LDEV, but it is a normal LDEV created from (or allocated from) an internal  RAID Group or external storage, so it’s LDKC:CU:LDEV address is assigned before the volume is  defined as an Hitachi Dynamic Provisioning pool volume. 



A LUSE volume cannot be used as a Pool Volume.  



If  used,  all  Parity  Groups  that  are    of  a  Pool  must  be  assigned  to  the  same  cache  partition  (CLPR).  Hence,  all  associated  DPVOLs  will  also  be  assigned  to  the  same  VPM  cache  partition.  However,  the  Parity  Groups  for  other  Pools  may  be  assigned  to  different  cache  partitions. 



Once  an  LDEV  becomes  a  Pool  Volume  (assigned  to  a  given  Pool),  there  are  a  wide  variety  of  restrictions  that  are  invoked  in    of  what  you  can  and  cannot  do  with  it,  particularly  in    of  replication  functions.  However  restrictions  that  apply  to  Pool  Volume  do  not  encom the DPVOLs which have very few extra restrictions over tradition LDEVs. 



You cannot remove a Pool Volume from an Hitachi Dynamic Provisioning Pool without deleting  the  entire  Pool  (first  disconnecting  all  of  its  DPVOLs  volumes)  from  the  Universal  Storage  Platform V system. 



An LDEV may not be uninstalled from the system if it is a Pool Volume.  



Each LDEV must be RAID formatted (scrubbed with zeros) before being assigned to a Pool (you  can’t format a Pool). 

V-VOL Groups and DP Volumes There are both V‐VOL Groups (virtual volume containers) and their DPVOLs (virtual volumes, also known  as  V‐VOLs).  The  DPVOLs  are  seen  as  real volumes  by  the  hosts.  There  may  be  up  to  8,192  DPVOLs  created  per  Pool.  DPVOLs share  the  Universal  Storage  Platform  V  system‐wide  addressability  limit  of  65,536 volumes with external volumes, Shadow Image volumes, Universal Replicator volumes, and Pool  Volumes. The size of each DPVOL may be between 46MB and 4TB in size, depending on the size of its V‐ VOL container.    Once  a  Pool  has  been  created,  one  or  more  V‐VOL  Groups  are  then  configured.  A V‐VOL  Group  is  a  virtual  substitution  for  a  Parity  Group.  When  a  V‐VOL  Group  is  created  and  connected  to  an  Hitachi  Dynamic  Provisioning  Pool  (a  V‐VOL  Group  cannot  span  Pools),  a    selectable  Group  size  between  46MB  and  4TB  is  specified.  The  next  step  is  to  create  one  virtual  DP  volume  within  the V‐VOL  Group container. The DPVOL is then mapped to a host port as a LUN (just like a standard LDEV). The host  will then detect the LUN’s size as the virtual size specified for that V‐VOL Group. Figure 37 shows two DP  volumes, two V‐VOL Group containers, the associated Pool with 1152GB of capacity, and the four Parity  Group LDEVs assigned as Pool Volumes (288GB each) to that Pool.  

RESTRICTED CONFIDENTIAL 

Page 48 

Figure 37. Hitachi Dynamic Provisioning: Association of a DPVOL to Parity Groups

500GB DP-VOL

1000GB DP-VOL

500GB V-VOL Group

1TB V-VOL Group HDP Physical Pool

288GB LDEV Pool Volume

288GB LDEV Pool Volume

288GB LDEV Pool Volume

288GB LDEV Pool Volume

2D+2D RAID Group

2D+2D RAID Group

2D+2D RAID Group

2D+2D RAID Group

 

The physical space assigned as needed from the Pool to a V‐VOL Group container is evenly distributed  across the Pool Volumes by the mechanism of the Pool’s Free Page List. As a server writes to a DPVOL,  and new pages are required, these are assigned to the V‐VOL Group for use by that DPVOL. Note that  this assignment is from the next available page in the Free Page List, not from just anywhere in the Free  Page List. It is random in the sense that you do not know from which Pool Volume the next page for an  individual DPVOL will be mapped.  However, the server sees each DPVOL as having the complete SCSI Logical Block Address (LBA) range of  512  byte  physical  blocks  that  would  match  the  logical  size  that  was  specified  when  that  DPVOL  was  created.  This  is  what  thin  provisioning  is  all  about  –  space  allocated  as  needed.  A  DPVOL  is  assigned  42MB pages of physical space from the Pool over time as the server writes to blocks in that volume.  Once assigned to a V‐VOL Group, a page is mapped into the associated DP volume Page Table. This is a  table  of  pointers  matching  up  the  host’s  virtual  LBA  range  and  physical  512  byte  blocks  with  that  DP  volume’s  assigned  pages.  The  Page  Table  presents  a  contiguous  space  of  virtual  and  assigned  42MB  segments to that volume starting at beginning of that DPVOL’s address space (byte 0). A DPVOL whose  size  is  not  a  whole  number  of  42MB  pages  can  acquire  a  page  that  will  be  only  partially  used  at  the  highest  address  range  for  that  DPVOL.  The  remainder  of  that  page  is  unused  (but  this  is  a  very  small  amount of space).  If  a  DPVOL  was  specified  to  be  a  100GB  volume,  that  would  represent  209,715,200  such  SCSI  blocks  sitting on 2,439 42MB Pool pages. Each assigned Pool page will contain a specific (predetermined) range  of consecutive 86,016 512 byte blocks. As illustrated below, one page in a DPVOL will contain LBA‐0 to  LBA‐86015, and some other page will contain LBA‐86016 to LBA‐172031. Whether a physical page has  been assigned is dependent on whether any LBA within that fixed range has been written to by the host.  For  example,  if  the  server  wrote  8KB  file  system  blocks  to  a  new  DPVOL  at  LBA  locations  0,  86016,  RESTRICTED CONFIDENTIAL 

Page 49 

172032, 258048, and 344064 then that DPVOL would have five new Pool pages assigned.  If the server  next  wrote  to  LBA  locations  16,  86032,  172048,  258064,  and  344080  (or  such)  then  those  same  five  pages would be used.  Figure 38. Illustration of Pool Page to a Volume’s SCSI LBA Range

The number of Pool pages initially assigned to a DPVOL by file system formatting will depend upon the  operating  system,  the  file  system,  and  the  size  of  the  volume.  Once  the  server  formats  a  volume,  the  Pool will have assigned some number of physical pages to it. The amount of the physical space initially  required by this formatting operation is determined by the amount of metadata the file system initially  writes to that volume, along with the distribution (stride) of these blocks of metadata across the entire  volume. Hence, the number of pages initially assigned to volume by the formatting operation will vary.  See Appendix 13 for a table of typical file system usage.  If, for example, a DPVOL is formatted by a file system, and the file system’s block size is 8KB, there will  be 5,376 file  system blocks per page (each 8KB block consuming  16 LBA blocks). The first  time one of  these blocks from a DPVOL virtual page is written to, the following sequence occurs:    The next available free Pool page will be assigned from the Pool’s Free Page List.    That page will be mapped into that DPVOLs Page Table and associated with a certain LBA range.     The new block(s) will be written to that page.   Usage Mechanisms If a host Read is posted to an area of the DPVOL that does not yet have physical space (no blocks have  been written there yet), the Hitachi Dynamic Provisioning Dynamic Mapping Table will direct the read to  a special “Null Page”. New Pool pages to cover that region will not be allocated from the Free Page List  since it was a Read.   If a Write is posted to an area of the DPVOL which does not yet have physical space, the DPVOL requests  a new page and assigns it to that LBA range in the Page Table.   If a Write is posted to an area of the DPVOL which does not yet have physical space, and the Pool has  completely  run  out  of  space,  the  host  will  get  a  “Write  Protect”  error.  During  this  “out  of  space”  condition, all Read operations specifying an LBA region of a DPVOL without an assigned page will now  return an “Illegal Request” error rather than the “Null Page”. These error conditions will be cleared once  additional physical Pool Volume space has been added to that Pool or some DPVOLs are formatted and  disconnected from the Pool, thereby freeing up all of their previously allocated pages. 

RESTRICTED CONFIDENTIAL 

Page 50 

There will normally be several DPVOLs connected to a single Hitachi Dynamic Provisioning Pool. As each  DPVOL begins receiving writes from the servers, the number of assigned Pool pages to that DPVOL will  grow. As this group of DPVOLs consumes Pool Pages over time, the Pool’s Free Space Threshold can be  reached and the storage  will receive an alert telling him to add additional Pool Volumes to  that Pool. The amount of physical space a DPVOL can acquire over time will be limited by the DPVOL size  (up to 4TB) when it was defined. The sum of all the virtual sizes of those DPVOLs connected to a Pool,  rounded up to an integral number of pages, will be the maximum physical Pool size required over time.  

DPVOL Features and Restrictions There are various restrictions regarding DPVOLs. These include:  

A DPVOL may only be connected to one Pool.  



Pages are released from a DPVOL when the association to the Hitachi Dynamic Provisioning Pool  is  deleted.  Since  these  Pages  were  merely  mapped  from  the  Pool  to  the  DPVOL’s  local  Page  Table, these N freed Pages “return” to that Pool’s Free Page List and they will be reassigned to  DPVOLs by the next N requests for Pages. 



Pages comprised of all binary zeros can be freed from a DPVOL. A condition where some pages  are all zero is normal when a traditional volume is migrated as‐is to a DPVOL.  



There can be up to 8,192 DPVOLs assigned to an Hitachi Dynamic Provisioning Pool. 



A DPVOL can range from 46MB to 4TB in size.  



A DPVOL can be increased in capacity (up to 4TB). 



In  of usage, a DPVOL is pretty much like a standard LDEV with a few restrictions.   1. A DPVOL has a normal LDKC:CU:LDEV number but this is in a special type of Parity Group  (the V‐VOL Group).  2. Using the usual HDS tools you can use DRU to protect a DPVOL.  3. ShadowImage pairs, TrueCopy pairs, HUR pairs, or CoW P‐VOLs can be created from  DPVOLs.   4. DPVOL cannot use cache residency.   5. A DPVOL also differs from a normal LDEV in that you can't resize or sub‐divide it using VLVI  or glue them together with LUSE. 

Pool Page Details The physical Pool space is assigned over time as needed to the DPVOLs that are connected to that Pool  through their V‐VOL Group. Space is assigned from the Pool in 42MB allocation units called Pool pages.  All Pool pages are managed by the Hitachi Dynamic Provisioning software in a Dynamic Mapping Table  (DMT) in Shared Memory. All metadata for the Hitachi Dynamic Provisioning Pools and their DPVOLs is  maintained in the DMT, which resides in the 12GB‐14GB address space of Shared Memory. One type of  element in the DMT is a Free Page List that is maintained for each Pool for all of their 42MB pages.   The Pool’s Free Page List is a table of pointers to all of the pages located on its set of Pool Volumes as  well  as  some  status  information.  When  a  DPVOL  needs  a  new  physical  page,  it  is  assigned  the  next  available page from this Free Page List. The structure of the Free Page List consists of a matrix of 42MB  RESTRICTED CONFIDENTIAL 

Page 51 

pages  from  all  of  the  Pool  Volumes  using  intelligent  algorithms  that  take  all  of  the  Pool  factors  into  consideration.  The  Free  Page  List  is  generated  (or  re‐generated)  when  the  Optimize  button  in  Storage  Navigator is selected after adding LDEVs to a Pool (either initially or subsequently). The concept of thin  provisioned capacity involves the Pool page capacity actually assigned to a DPVOL – which grows over  time ‐ and not the static, reported size of the volume from the host’s perspective.  Note:  If  one  does  not  use  the  Optimize  button  when  appropriate,  a  new  Free  Page  List  will  be  dynamically created over time. However, this operation is much faster when done purposefully with the  Optimize button.   Each DPVOL has a Page Table for keeping track of pointers to its assigned Pool pages. This is a list of all  assigned Pool pages and where to find them on the Pool Volumes. Each Page Table is also a lookup table  of assigned physical pages to the server’s virtual address space (the LBA range of all the 512 byte blocks  in that volume). Note that once a Pool page is assigned to a DPVOL, it remains there regardless of the  state of the data written to blocks on that page. If all files that happen to reside on that page is deleted  by the host file system, leaving the page “empty” with a lot of unneeded “ghost” data, it doesn’t matter.  As  described  previously,  each  page  –  once  assigned  to  the  volume  –  becomes  a  piece  of  the  physical  space for a specific LBA range for that volume. Once allocated and containing any non‐binary zero data  then the page assignment is permanent until that DPVOL is deleted.   Note:  When  using  Tiered  Storage  Manager,  once  a  DPVOL  is  moved  from  one  Pool  into  another, the original Pool pages are automatically reformatted and released back to the Pool.  The Optimize button has no effect except after adding new Pool Volumes or deleting DPVOLs.  There are some housekeeping pages from each Pool that are not available for assignment to DPVOLs.  There is a small 84MB system region (2 pages) per Pool for each assigned Pool Volume. There is also a  small 4GB (98 page) region in every Hitachi Dynamic Provisioning Pool that is reserved by the system to  use for a mirror copy of the DMT in Shared Memory. For Universal Storage Platform V release G01, with  the setting of a flag in the SVP, the DMT is copied to the SVP’s internal disk on a system power down  (PS‐OFF).  For  G02,  the  DMT  is  mirrored  to  this  reserved  4GB  region  in  the  first  Hitachi  Dynamic  Provisioning Pool currently defined in the system.  There  is  a  simple  physical  structure  for  Pool  pages.  An  individual  42MB  page  is  laid  down  on  a  whole  number  of  consecutive  RAID  stripes  from  a  single  Pool  Volume.  The  Table  below  illustrates  the  relationship  among  different  RAID  levels,  their  various  RAID  stripe  sizes,  and  the  assignment  of  consecutive stripes to a single page.  Table 12. Number of RAID Stripes per 42MB Pool Page

RAID Type  RAID‐10  RAID‐5  RAID‐5  RAID‐6 

RAID Level  2+2  3+1  7+1  6+2 

Data Disks  2  3  7  6 

RAID Stripe Size  (KB)  1024  1536  3584  3072 

RAID Stripes  per HDP Page  42  28  12  14 

  Take, for example, the case of an Hitachi Dynamic Provisioning Pool that is composed of several RAID‐5  (7D+1P)  Pool  Volumes  (LDEVs).  Each  LDEV  has  a  formatted  RAID  stripe  width  of  3,584KB.  This  comes  from two 256KB consecutive chunks per disk, with (effectively) seven data disks in the stripe (256+256 x  RESTRICTED CONFIDENTIAL 

Page 52 

7). [See Appendix 2 for the various Hitachi RAID level details.] Therefore, twelve such RAID stripes from a  single  RAID‐5  (7D+1P)  LDEV  will  be  used  to  create  a  single  42MB  Pool  Page.  In  the  case  of  a  Pool  consisting  of  RAID‐10  (2D+2D)  Parity  Groups,  each  LDEV  will  provide  42  consecutive  stripes  for  each  42MB Pool page.  Pool Expansion As  Pages  in  the  Pool  are  assigned  to  DPVOLs  over  time  and  the  number  of  free  Pages  drops  below  a  certain threshold of the initial Pool capacity, more LDEVs will have to be added to that Pool. Once new  LDEV(s) are added to the Pool and the Optimize button in Storage Navigator is used, the Free Page List  will once again be optimized. The existing Free Page List will be extended using the new pages available  from  the  additional  Pool  Volumes.  When  new  Pool  Volumes  are  added  to  a  Pool  once  the  remaining  Free Page count is low, the HDS recommendation is to add another set of LDEVs that match the initial  set (same RAID level, same disk RPM). This will ensure that the DPVOL performance remains on par with  what was previously experienced for that Pool.   For example, a Pool that started with six LDEVs will have a certain performance due to the number of  disks and the RAID level used (write penalty). If six RAID‐10 (2D+2D) Parity Groups were used for these  six  LDEVs,  that  Pool  would  have  started  out  with  24  disks  of  IOPS  power.  Each  individual  page  would  have the IOPS power of the underlying LDEV (such as 2D+2D), but on average the set of pages mapped  to a DPVOL would include pages from all Pool Volumes, thus delivering the full 24‐disk IOPS power.   Suppose that the initial set of free pages (from the six‐LDEV Pool) become depleted (below 20% of the  Pool)  and  two  new  LDEVs  are  then  added  to  the  Pool  (each  from  different  RAID‐10  2D+2D  Parity  Groups).  Once  the  last  20%  of  original  Pool  pages  are  assigned  from  a  Pool’s  Free  Page  List,  the  new  pages  will  now  exhibit  the  overall  IOPS  power  of  only  8  disks.  There  will  be  a  noticeable  drop  in  IOPS  rates once available from the 24‐disk Pool as IO to new pages is now hitting an 8 disk Pool.   The following may be a way to describe this concept in a 10 second "techie spot":   A new Pool is created from a set of LDEVs taken from like Parity Groups. The more Parity Groups  in  use,  the  higher  the  IOPS  performance  that  is  available  to  that  Pool.  This  space  is  then  "Optimized", where the Free Pool Page List (using 42MB pages) is created in the Hitachi Dynamic  Provisioning region of Shared Memory. This list is built from 42MB pages across the Pool LDEVs.  These  free  pages  are  then  assigned  on  a  first‐come  first‐serve  basis  as  needed  to  DPVOLs  connected to that Pool.   When new LDEVs are added to the Pool once the space becomes depleted, the same process is  followed.  A  complementary  number  of  LDEVs  from  enough  Parity  Groups  should  be  added  to  maintain the IOPS performance level of the Pool.   Miscellaneous Hitachi Dynamic Provisioning Details  The  configuration  of  Hitachi  Dynamic  Provisioning  Pools  and  DP  Volumes  is  done  via  Storage  Navigator (or HiCommand Device Manager ‐ HDvM). This is also how the physical space usage  per  Pool  is  monitored.  There  are  two  Pool  Free  Space  thresholds:  a    specified  threshold  between  5%‐95%  page  utilization  and  a  fixed  threshold  at  80%  utilization.  Both  of  these  thresholds are used as the triggers for the low Pool space notifications.  

If  more  than  4TB  of  space  is  required  for  a  single  host  volume,  then  multiple  DPVOLs  may  be  used in the ordinary fashion by a logical volume manager on the server to create a single large 

RESTRICTED CONFIDENTIAL 

Page 53 

striped Logical Volume. Note that if these DPVOLs come from different Pools, then the overall  IOPS capacity will increase. If all of the DPVOLs used by a host LVM are from the same Pool, then  only the total usable capacity will increase.  

The use of Hitachi Dynamic Provisioning will cause an increase in the port processor (FED MP)  utilization  for  some  writes.  There  is  very  small  increase  in  utilization  for  individual  reads  or  writes  to  the  DPVOL  area  when  physical  pages  are  already  allocated  from  the  Pool  for  that  address space. When a write to a DPVOL causes a physical Page allocation from the Pool, there  is a brief utilization increase (in microseconds) on the associated FED MP for that operation.  



The association of all of the array elements that must be configured is as follows:   Array Group ‐> Parity Group ‐> LDEVs (assign LDKC:CU:LDEV) ‐> HDP Pool  Volume ‐> V‐Vol  Group ‐> DPVol (assign LDKC:CU:LDEV) ‐> LUN.      This lengthy set of steps is similar to what is required when using a host‐based volume manager  such  as  Veritas  VxVM  and  an  array  that  does  not  offer  Hitachi  Dynamic  Provisioning.  For  instance, if using an EMC DMX‐4, one would have to follow these steps which would have to be  repeated on every server attached to that array:      Disks ‐> Hypervolumes ‐> Metavolumes with a software RAID ‐> LUNs (assign port:address) ‐>  VM Disk  (private region) ‐> VM Disk (public region) ‐> PLEX ‐> Volume (LUN).    

Hitachi Dynamic Provisioning and Program Products Compatibility The two  tables below show the application of Pool LDEVs and  DPVOLs to the various Hitachi Program  Products.      Program Product Compatibility  Cache Residency Manager  Cache Residency Manager for z/OS  Compatible Mirroring for IBM Flash Copy  Compatible PAV for z/OS  Compatible Replication for IBM XRC  Copy‐on‐Write snapshot  P‐VOL  POOL  Data Retention Utility  LUN Manager  LUN Security  Open Volume Management  CVS  LUSE  Performance Manager  Server Priority Manager 

                                                     

Pool‐Vol  n/a  n/a  n/a  n/a  n/a     n/a  n/a  n/a  n/a  n/a     yes  n/a  yes  n/a 

     DP‐Vol     no     n/a     n/a     n/a     n/a           yes     n/a     yes     yes     yes           yes     no     yes     yes 

ShadowImage  ShadowImage for z/OS 

     

n/a  n/a 

     

yes  n/a 

Storage Navigator 

  

yes 

  

yes 

  RESTRICTED CONFIDENTIAL 

Page 54 

   Program Product Compatibility  True Copy  True Copy for z/OS  TrueCopy Async  TrueCopy Async for z/OS  Universal Replicator  P‐VOL  S‐VOL  Journal VOL  Universal Replicator for z/OS  Universal Volume Manager  Virtual LVI  Virtual LVI z/OS  Virtual Partition Manager  Volume Security  Volume Security z/OS  Volume Shredder 

                                                     

Pool‐Vol  n/a  n/a  n/a  n/a     n/a  n/a  n/a  n/a  yes  n/a  n/a  yes  n/a  n/a  n/a 

     DP‐Vol     yes     n/a     no     n/a           yes     yes     n/a     n/a     n/a     yes     n/a     yes     yes     n/a     yes 

Volume Migration  Volume Retention Manager 

     

no  n/a 

     

yes  yes 

Volume Retention Manager z/OS 

  

n/a 

  

n/a 

Universal Storage Platform V Volume Flexibility Example If you have a customer using Exchange Server 2003, they are limited to the use of four “Storage Groups”  (LUNs). A host volume manager cannot be used with Exchange. Due to the way that the underlying Jet  database  operates,  one  must  normally  use  RAID‐10  volumes  to  avoid  the  database  mailbox  insert  response  time  issues  that  a  well  known  characteristic  of  Jet.  Here  are  some  alternative  methods  on  a  Universal Storage Platform V to provide these four Storage Group LUNs to an Exchange server:  STANDARD  VOLUMES:    If  using  RAID‐10  (2D+2D),  this  method  would  provide  16  disks  when  using four standard LDEVs from four Parity Groups.   LUSE  VOLUMES:    If  using  four  LUSE  volumes  –  where  each  of  them  has  four LDEVs  from  four  RAID‐10  (2D+2D)  Parity  Groups  (thus  16  Parity  Groups  overall),  this  would  provide  64  disks  overall. However, you will normally only see the IO power of one LDEV per LUSE volume (4 disks  each, or 16 in parallel) due to the simple concatenation nature of LUSE (fill one LDEV, then start  on the next one).  STRIPED  (CONCATENATED)  PARITY  GROUPS:    If  using  this  configuration  with  four  VDEV  volumes,  where  each  Storage  Group  was  located  on  one  VDEV  created  across  four  RAID‐5  (7D+1P)  Parity  Groups,  there  would  be  128  disks  overall.  However,  due  to  the  write  latency  sensitivity of Jet, one would normally not want to use a RAID‐5 solution. Note that this storage  system  based  interleaved  (not  concatenated)  RAID  stripe  solution  is  not  available  from  other  vendors.  HDP  #1:    If  using  Dynamic  Provisioning  for  the  Exchange  Storage  Groups,  there  could  be  12  LDEVs from 12 RAID‐10 (2D+2D) Parity Groups put into a Pool (or 48 disks in all), and then create  four DPVOLs connected to this Pool. Each DPVOL would be used as an Exchange Storage Group  RESTRICTED CONFIDENTIAL 

Page 55 

over a dedicated 4Gbit host path. This very large "native" IOPS solution is not available from any  other vendor.   HDP #2:  If using Dynamic Provisioning, there could be 32 LDEVs from 32 RAID‐10 (2D+2D) Parity  Groups  put  into  four  Pools  (128  disks  in  all),  with  four  DPVOLs  created  per  Pool.  Each  DPVOL  would  be  used  as  an  Exchange  Storage  Group,  and  four  such  Exchange  Servers  could  be  ed by this configuration. This huge "native" IOPS solution is not available from any other  vendor.  However,  note  that  4  paths  from  each  of  the  four  servers  would  likely  be  needed  to  effectively use this huge reservoir of random IOPS capacity.    

Storage Concepts Understand Your Customer’s Environment Before  recommending  a  storage  design  for  customers,  it  is  important  to  know  how  the  product  will  address  the  customer’s  specific  business  needs.  The  factors  that  must  be  taken  into  consideration  include: Capacity, Performance, Reliability, Features and Cost with respect to the storage infrastructure  component.  The  more  data  you  have, the  easier  it  is  to  architect  a  solution  as  opposed  to  just  selling  another  storage  unit.  The  types  of  storage  configured,  including  the  disk  types,  the  number  of  RAID  Groups and their RAID levels, as well as the number and type of host paths is important to the solution.     

Disk Types Table 13 below lists the  disks types available in the Universal Storage Platform V storage arrays. Note  that  the  table  lists  the  true  sizes  typically  seen  by  a  host  after  formatting.  The  additional  formatting  applied by host‐based Logical Volume Managers and file systems will consume additional space.    Table 13. List of Disk Types and Characteristics, Along with Nominal Rule-of-Thumb IOPS Limits

Port  Speed 

d  Size (GB) 

1 TB     SATA     7.2k RPM  750 GB SATA     7.2k RPM  450 GB FC         15k RPM  400 GB FC         10k RPM  300 GB FC         15k RPM  146 GB Flash  146 GB FC         15k RPM  72 GB Flash 

3Gb/sec  3Gb/sec  4Gb/sec  4Gb/sec  4Gb/sec  4Gb/sec  4Gb/sec  4Gb/sec 

1000  750  450  400  300  146  146  72 

976  738.62  432  384  288.2  143.76  143.76  71.5 

927.2  701.7  410.4  364.8  273.8  136.6  136.6  67.9 

80  80  180  130  180  5000 ‐ read 1500 ‐ write  180  5000 ‐read 1500 ‐ write 

  72 GB FC         15k RPM 

4Gb/sec 

72 

71.5 

67.9 

180 

HDD Type 

Apparent  Usable Size  Size (GB)  (GB) 

Nominal Random  IOPS 

  The  table  above  illustrates  the  d  size  (base‐10),  the  apparent  size  in  the  tools  (still  base‐10),  and the typical usable (after Parity Group formatting) size of each type of disk. Also shown is the “rule of  thumb”  average  maximum  random  8KB  block  IOPS  rate  for  each  type  of  disk  when  using  most  of  the  disk surface.  Also shown are the  nominal rates expected for Flash Drives when used as  of  a  RAID‐5 (7D+1P) group across two BED pairs (four boards, 8 FC‐AL loop pairs).   RESTRICTED CONFIDENTIAL 

Page 56 

Every  disk  has  a  maximum  random  small  block  IOPS  rate  determined  by  seek  times  (head  movement  across  the  disk)  and  rotational  delays  (disk  RPM).  The  number  and  size  of  the  LUNs  created  per  RAID  Group  determine  how  much  of  a  disks’  surface  is  in  active  use.    When  using  the  full  disk  surface,  any  expectations for higher sustained levels of IOPS per disk must be met by sustained cache hit rates on the  storage array (avoiding physical reads from disk). Note that 10‐20% is a typical cache hit rate on Open  Systems servers.  As more of the disk surface is allocated to LUNs for a RAID Group, the farther the disk heads must seek.  This creates higher average seek times. For example (using a 15k RPM disk), when only using the outer  25%  of  the  surface  the  average  read  seek  time  can  be  around  1.8ms  (providing  about  267  IOPS),  whereas the 100% surface average seek time will be about 3.8ms (about 182 IOPS). For a SATA disk at  7200  RPM,  these  values  are  about  4.3ms  (119  IOPS)  for  using  25%  of  the  disk  surface  and  8.5ms  (79  IOPS) when using the full disk surface. All write rates are about 5% lower than the read rates due to the  higher seek precision required. See Appendix 14 for more details on theoretical estimates of disk IOPS  rates.   

RAID Levels The Universal Storage Platform V array currently s RAID levels 5, 6, and 10. RAID‐5 is the most  space efficient of these three RAID levels.   RAID‐5 is a group of disks (RAID Group or Parity Group) with the space of one disk used for the  rotating  parity  chunk  per  RAID  stripe  (row  of  chunks  across  the  set  of  disks).  If  using  a  7D+1P  configuration (7 data disks, 1 parity disk), then you get 87.5% capacity utilization for  data  blocks out of that RAID Group.   RAID‐6 is RAID‐5 with a second parity disk for a second unique parity block. The second parity  block  includes  all  of  the  data  chunks  plus  the  first  parity  chunk  for  that  row.  This  would  be  indicated as a 6D+2P construction (75% capacity utilization) if using 8 disks.   RAID‐10 is a mirroring and striping mechanism. First, individual pairs of disks are placed into a  mirror state. Then two of these pairs are used in a simple RAID‐0 stripe. As there are four disks  in  the  RAID  Group,  this  would  be  represented  as  RAID‐10  (2D+2D)  and  have  50%  capacity  utilization. RAID‐10 is not the same as RAID‐0+1, although sloppy usage by many would lead one  to think this is the case. RAID‐0+1 is a RAID‐0 stripe of N‐disks mirrored to another RAID‐0 stripe  of N‐disks. This would also be shown as 2D+2D for a 4‐disk construction. However, if one disk  fails,  that  RAID‐0  stripe  also  fails,  and  the  mirror  then  fails,  leaving  a    with  a  single  unprotected RAID‐0 group. In the case of real RAID‐10, one disk of each mirror pair would have  to fail before getting into this same unprotected state.  The factors in determining which RAID level to use are cost, reliability, and performance. Table 14 shows  the  major  benefits  and  disadvantage  of  each  RAID  type.    Each  type  provides  its  own  unique  set  of  benefits so a clear understanding of your customer’s requirements is crucial in this decision. 

RESTRICTED CONFIDENTIAL 

Page 57 

Table 14. RAID Levels Comparison.

 

RAID‐10 

RAID‐5

RAID‐6 

Description 

Data Striping and Mirroring 

Data Striping with  distributed parity 

Data Striping with two  distributed parities 

Number of  Disks 

4/8 

4/8 

8 

Benefit 

Highest performance with data  redundancy; higher write IOPS per  Parity Group than with similar RAID‐5. 

The best balance of cost,  reliability, and  performance. 

Balance of cost, with  extreme emphasis on  reliability 

Disadvantages 

Higher cost per number of physical  disks 

Performance penalty for  high percentage of  Random Writes 

Performance penalty for  all writes 

  Another characteristic of RAID is the idea of “write penalty”. Each type of RAID has a different back‐end  physical disk I/O cost, determined by the mechanism of that RAID level. The table below illustrates the  trade‐offs between the various RAID levels for write operations. There are additional physical disk reads  and writes for every application write due to the use of mirrors or XOR parity. Note that SATA disks are  usually deployed with RAID‐6 to protect against a second drive failure within the Parity Group during the  lengthy  disk  rebuild  of  a  failed  drive.  Also  note  that  you  must  deploy  many  more  SATA  disks  than  FC  disks to be able to meet the same level of IOPS performance.  Table 15. RAID Write Penalties

HDD IOPS per Host Read

HDD IOPS per Host Write

RAID10  RAID5  RAID6 

1  1  1 

2  4  6 

RAID10  RAID5 

1  1 

4  6 

RAID6 

1 

9 

FC

SATA

  When using Fibre Channel disks, a write‐ operation is performed internally after each write to the  disk (for data or parity).  This BED‐issued command simply, by algorithmic means, verifies that it wrote  the data where it was told to write the data. This same command is not available for SATA HDDs.  To  protect data, in the case of SATA disks, there are additional physical I/O operations per write in order to  compare what was just written to disk with the data and parity blocks held in cache. With RAID‐6, there  are three such blocks: data, parity1, and parity2.  

RESTRICTED CONFIDENTIAL 

Page 58 

Table 16. Break Down of RAID Level Write Costs (Fibre Channel Disks)

   RAID‐10  RAID‐5  RAID‐6    

IOPS Consumed per host I/O request        1 Data Write, 1 mirrored Data Write  2 reads (1 data, 1 parity), 2 writes (1 data, 1 parity)  3 reads (1 data, 2 parity), 3 writes (1 data, 2 parity)  SATA writes: also read and compare data and parity writes (mirror) 

  

 

Parity Groups and Array Groups On  Hitachi  enterprise  products  the    Parity  Group  and  Array  Group  are  used  when  configuring  storage.  The  Array  Group  is  the  set  of  four  associated  disks,  while  the  Parity  Group  is  the  RAID  level  applied to either 1 or 2 sets of disks. However, in general use in the field, the  Array Group and  Parity Group are often used interchangeably.    

RAID Chunks and Stripes A Parity Group is a logical mechanism that has two basic elements: a virtual block size from each disk (a  chunk) and a row of chunks across the group (the RAID stripe). The chunk size is 256KB on the Universal  Storage Platform V, but two such chunks per disk are used at a time so the effective chunk size is really  512KB. The stripe size is the sum of the chunk sizes across a RAID Group. This only counts the “data”  chunks and not any mirror or parity space. Therefore, on a RAID‐6 group created as 6D+2P (eight disks),  the stripe size would be 3072MB (512KB x 6).    Note that some industry usage replaces chunk with “stripe size”, “stripe depth”, or “interleave factor”,  and stripe size with “stripe width”, “row width” or “row size”.  Note that on all current RAID systems, the chunk is a primarily unit of protection management: either  the  parity  or  mirror  mechanism.  I/O  is  not  performed  on  a  chunk  basis  as  is  commonly  thought.  On  Open Systems, the entire space presented by a LUN is a contiguous span of 512 byte blocks, known as  the  Logical  Block  Address  range  (LBA).  The  host  application  makes  I/O  requests  using  some  native  request  size  (such  as  a  file  system  block  size),  and  this  is  ed  down  to  the  storage  as  a  unique  I/O  request. The request has the starting address (of a 512 byte block) and a length (such as the file system  8KB block size). The storage array will locate that address within that LUN to a particular disk address,  and read or write only that amount of data – not that entire  chunk. Also note that this request could  require two disks to satisfy if 2KB of the block lies on one chunk and 6KB on the next one in the stripe.    Because  of  the  variations  of  file  system  formatting  and  such,  there  is  no  way  to  determine  where  a  particular block may lie on the raw space presented by a volume. A file system will create a variety of  metadata  in  a  quantity  and  distribution  pattern  that  is  related  to  the  size  of  that  volume.  Most  file  systems also typically scatter writes around within the LBA range – an outdated hold‐over from long ago  when file systems wanted to avoid a common problem of the appearance of bad sectors  or tracks on  disks.  What  this  means  is  that  attempts  to  align  application  block  sizes  with  RAID  chunk  sizes  is  a  pointless exercise.   The  one  alignment  issue  that  should  be  noted  is  in  the  case  of  host‐based  Logical  Volume  Managers.  These  also  have  a  native  “stripe  size”  that  is  selectable  when  creating  a  logical  volume  from  several  physical storage LUNs. In this case, the LVM stripe size should be a multiple of the RAID chunk size due  RESTRICTED CONFIDENTIAL 

Page 59 

to  various  interactions  between  the  LVM  and  the  LUNs.  One  such  example  is  the  case  of  large  block  sequential I/O. If the LVM stripe size is equal to the RAID chunk size, then a series of requests will be  issued  to  different  LUNs  for  that  same  I/O,  making  the  request  appear  to  be  several  random  I/O  operations to the storage array. This can defeat the array’s sequential detect mechanisms, and turn off  sequential prefetch, slowing down these types of operations.    

LUNS (host volumes) On a Universal Storage Platform V, when space is carved out of a Parity Group and made into a volume,  it is then known as a Logical Device (LDEV). Once the LDEV is mapped to a host port for use by a server,  it  is  known  as  a  LUN  (Logical  Unit  Number)  and  is  assigned  a  certain  World  Wide  Name  if  using  fibre  channel interfaces on the array. On an iSCSI configuration, the LUN gets a name that is associated with  an NFS mount point. Note that general usage has turned the term of “LU” into “LUN”.   

Number of LUNs per Parity Group When configuring a Universal Storage Platform V, one or more LDEVs may be created per Parity Group,  but  the  goal  should  be  to  clearly  understand  what  percentage  of  that  group’s  overall  capacity  will  contain active data. In the case where multiple hosts attempt to simultaneously use LUNs that share the  same  physical  disks  in  an  attempt  to  fully  utilize  capacity,  seek  and  rotational  latency  may  be  a  performance  limiting  factor.    In  attempting  to  maximize  utilization,  RAID  groups  should  contain  both  active and less frequently used LUNs. This is true of all physical disks regardless of size, RAID level, and  physical characteristics.   It is also true that, if many small LUNs are carved out of a single Parity Group, their simultaneous use will  create maximum seek times on each disk, reducing the maximum sustainable small block random IOPS  rate to the disk’s minimum.  

Port I/O Request Limits, LUN Queue Depths, and Transfer sizes There  are  three  aspects  of  I/O  request  handling  per  storage  path  that  need  to  be  understood.  At  the  port level, there are the mechanisms of an I/O request limit and a maximum transfer size. At the LUN  level, there is the mechanism of the maximum queue depth.   Port I/O Request Limits Each  server  and  storage  array  has  a  particular  port  I/O  request  limit,  this  being  the  number  of  total  outstanding I/O requests that may be issued to a port  (not a LUN) at any  point in  time. This limit will  vary  according  to  the  server’s  Fibre  Channel  HBA  and  its  driver,  as  well  as  the  limit  ed  by  the  target  storage  port.  As  switches  serve  to  aggregate  many  HBAs  to  the  same  storage  system  port,  the  operating limit will be the lower of these two points. In the case of a SAN switch being used to attach  multiple server ports to a single storage port (fan‐in), the limit will most likely be the limit ed by  the storage port.  On the Universal Storage Platform V, the I/O request limit per FED MP (controlling either 1 or 2 ports) is  4096. This means that, at any one time, there can be up to 4096 active host I/O commands queued up  for the various LUNs visible on that MP’s ports.   RESTRICTED CONFIDENTIAL 

Page 60 

Most  environments  don’t  require  that  all  LUNs  be  active  at  the  same  time.  As  I/O  requests  are  application driven, this must be taken into consideration.  Understanding the customer’s requirements  for  performance  will  dictate  how  many  LUNs  should  be  assigned  to  a  single  port.  Environments  that  have  low  I/O  demands  overall  will  allow  a  large  number  of  LUNs  to  be  assigned  per  port  without  routinely exceeding the queue limit for that port.  On the other hand, environments with highly active  devices and multiple I/O request should be designed with fewer LUNs per port, where additional ports  will be required in order to satisfy the I/O demand.     Port I/O Request Maximum Transfer Size There is also a host tunable parameter at the driver level that controls the maximum transfer size of a  single  I/O  operation.  This  is  usually  a  per‐port  setting,  but  it  also  might  be  a  per‐host  setting.  The  defaults for this can range from fairly small (like 32KB) to something midsized (128KB). The maximum is  usually 1MB‐16MB. It is probably a best practice to set this to the largest setting that is ed on the  host. The  maximum transfer size that a Universal Storage Platform V will accept is 1024KB. This value  controls  how  application  I/O  requests  get  processed.  If  one  used  a  large  application  block  size  (say  256KB) and the port/LUN default was just 32KB, then each request would be broken down (fragmented)  into 8 * 32KB requests. This creates additional overhead in managing the application request. The use of  a large maximum transfer size such as 1024KB will often be readily apparent on the performance of the  system.     LUN Queue Depth At the LUN level, there is the mechanism of the maximum queue depth. This is the limit of how many  outstanding I/O requests may be scheduled by a host for each LUN. On a host HBA, the device queue  depth  limit  is  usually  configurable  as  a driver  tunable,  usually  on  a  per‐port  basis  rather  than  a  global  setting. On a storage system, this limit is imposed by the controller and is not configurable. The usable  queue depth per LUN when there are multiple simultaneously active LUNs from the same RAID group  limit will be determined by physical I/O capacity of that group of disks.  On the Universal Storage Platform V, the rule‐of‐thumb for the LUN queue depth limit is 32. The actual  limit can be 4096, but that is far beyond the range that any LUN could accommodate. As the 4096 limit  is actually the MP limit, this will be reduced by the number of LUNs managed by that MP for its port(s).   It is important to note that the effective queue depth limit per LUN is not directly related to the host  I/Os as such, but more to the actual physical disk operations required for that RAID level (see Table 7  above),  and  for  the  alignment  of  the  data  blocks  requested.  If  the  data  being  written  crosses  chunk  boundaries, then the parity read/write operations required will be doubled. Recall that for parity RAID  (RAID‐5 or 6) that the parity chunk is associated with a specific data chunk. Note that the effective RAID  chunk size is either 512KB (Open‐V) for Open Systems or 464KB (3390x) for mainframes. 

RESTRICTED CONFIDENTIAL 

Page 61 

Figure 39. Table of Maximum LUN Queue Depths and Port Limits 

Maximum Queue Depth  QD Per LUN  QD Per External Port LUN  16  8  32  2‐128  32  ‐  2  ‐  Port IO Request Limit for Hosts  Per MP IO Req. Limit  Per Port IO Req. Limit  2048  1024  4096  2048  Port IO Request Limit for External Storage  Per MP IO Req. Limit  Per Port IO Req. Limit  256  128  512  256 

Array Type  USP  USP‐V  AMS FC/SAS Disk  AMS SATA Disk  Array Type  USP  USP‐V  Array Type  USP  USP‐V 

 

Mixing Data on the Physical Disks Physical  placement  of  data  by  Parity  Groups  (not  just  the  LDEVs  from  the  same  Parity  Group)  is  extremely  important  when  the  data  access  patterns  differ.    Mixing  highly  “write  intensive”  data  with  high  “read  intensive”  data  will  cause  both  to  suffer  performance  degradation.    This  performance  degradation  will  be  much  greater  when  using  RAID‐5  or  RAID‐6  due  to  the  increase  in  back‐end  disk  operations required for writes. When using Fibre Channel disks, there are two physical I/Os required for  each random write for RAID‐10, four for RAID‐5, and six for RAID‐6. When using SATA disks and RAID‐6,  there  are  three  additional  physical  I/Os  required  due  to  the  read  verification  after  writing  (data  and  parity/parity).   

Workload Characteristics Most applications, from a disk subsystem point of view, can be categorized into one of seven types of  application profiles (though there are the extreme cases that are not covered here):    Online Transactional Processing – Random Read/Write to data files, with Sequential Read/Write  to Log functions   Decision    Systems  –  Sequential  or  Random  Read,  depending  on  data  access  method,  post ETL   General Purpose File systems – Random Read/Write with potentially some Sequential I/O   Messaging systems – Random Read/Write   Web Server systems – Mixed Random and Sequential with various block sizes.   Content Rich Media Streaming and/or Video Streaming – Sequential Read/Write   High‐performance Computing  – Sequential Read/Write    The  applications  that  do  not  directly  fit  into  one  of  these  seven  categories  will  most  likely  be  a  combination of two or more of these categories.  

RESTRICTED CONFIDENTIAL 

Page 62 

Selecting the Proper Disk Drive Form Factor In  all  cases,  distributing  a  workload  across  a    higher  number  of  small‐capacity,  high‐RPM  drives  will  provide  better  performance  in    of  full  random  access.  Even  better  results  can  be  achieved  by  distributing the workload over a higher number of small LUNs where the LUNs are the only active LUNs  in the Parity Group.  When cached data locality is low, multiple small‐capacity high‐RPM drives should  be used.   One must also take into consideration the case where a system that is only partially populated with 15k  RPM  disks  will  be  able  to  provide  a  much  higher  aggregate  level  of  host  IOPS  if  the  same  budget  is  applied  to  lower  cost  10k  RPM  disks.  If  there  is  a  50%  increase  in  the  cost  of  the  15k  disks,  then  one  could  install  50%  more  disks  of  the  10k  variety.  The  individual  I/O  will  see  some  increase  in  response  time when using 10k disks, but the total amount of IOPS available will be much higher.   

Mixing I/O Profiles on the Physical Disks Mixing large‐block sequential I/O with small‐block random I/O on the same physical disks can result in  poor performance.  This applies to both read and write I/O patterns.  This problem can occur at the LUN  level or RAID Group level.  In the first case, with a single large LUN, files with different I/O profiles will  result in poor performance due to lack of sequential detect for the large block sequential I/O requests.  In  the  second  case,  where  multiple  LUNs  share  a  Parity  Group,  files  having  different  I/O  profiles  will  result  in  sequential  I/O  dominating  the  disk  access  time,  due  to  pre‐fetching,  thereby  creating  high  response times and low IOPS for the small‐block random I/O. The resolution to these two issues is to use  different LUNs and different Array Groups for different data types and I/O profiles.   

Front-end Port Performance and Usage Considerations The flexibility of the front‐end ports is such that several types of connections are possible. A couple of  port usage points are considered:   Port fan‐in and fan‐out   I/O profile mixes on a port  Host Fan-in and Fan-out With a SAN, the ability to share a port or ports among several host nodes is possible, as is configuring a  single  host  node  to  multiple  storage  ports.  Fan‐in  is  one  of  the  great  promises  of  fiber  channel  based  SAN technologies—the sharing of costly storage resources. Several host nodes are fanned into a single  storage port, or a host node has fanned out to several storage ports.   Fan‐in   Host Fan‐in refers to the consolidation of many host nodes into one or just a few storage ports (many‐ to‐one).  Fan‐in  has  the  potential  for  performance  issues  by  creating  a  bottleneck  at  the  front‐end  storage  port.  Having  multiple  hosts  connected  to  the  same  storage  port  does  work  for  environments  that  have  minimal  performance  requirements.  In  deg  this  type  of  solution,  it  is  important  to  understand  the  performance  requirements  of  each  host.  If  each  host  has  either  a  high  IOPS  or  throughput  requirement,  it  is  highly  probable  that  a  single  2‐gigabit  or  4‐gigabit  FC‐AL  port  will  not  satisfy their aggregate performance requirements.   RESTRICTED CONFIDENTIAL 

Page 63 

Fan‐out   Fan  out  allows  a  host  node  to  take  advantage  of  several  storage  ports  (and  possibly  additional  port  processors) from a single host port (one‐to‐many). Fan‐out has a potential performance benefit for small  block random I/O workloads. This allows multiple storage ports (and their queues) to service a smaller  number of host ports. Fan‐out typically does not benefit environments with high throughput (MB/sec)  requirements due the transfer limits of the host bus adapters (HBAs).     Mixing I/O Profiles on a Port Mixing  large‐block  sequential  I/O  with  small‐block  random  I/O  can  result  in  poor  performance.    This  applies to both read and write I/O patterns.  This problem can occur at the LUN level or Parity Group  level.    In  the  first  case,  with  a  single  large  LUN,  files  with  different  I/O  profiles  will  result  in  poor  performance due to lack of sequential detect for the large block sequential I/O requests. In the second  case, where multiple LUNs share a RAID Group, files having different I/O profiles will result in sequential  I/O dominating the disk access time, due to pre‐fetching, thereby creating high response times and low  IOPS  for  the  small‐block  random  I/O.  The  resolution  to  these  two  issues  is  to  use  different  LUNs  and  different Array Groups for different data types and I/O profiles.   

Summary The  Universal  Storage  Platform  V  offers  great  flexibility  and  it  should  perform  superbly  in  any  environment. At the hardware level, it offers considerably more IOPS power than does the equivalent  Universal  Storage  Platform  line  of  products.  Even  though  the  Universal  Storage  Platform  already  delivered  best‐of‐class  Sequential  performance  (about  3x  higher  than  any  competition  with  >9GB/s  Read,  >4GB/s  write),  the  Universal  Storage  Platform  V  significantly  outperforms  the  Universal  Storage  Platform.   It  is  important  for  s  to  understand  the  two  configuration  methods  now  available  with  the  new  Dynamic Provisioning feature. The Hitachi Dynamic Provisioning feature can be used for configuring Thin  Provisioning  and  for  the  creation  of  High  Performance  volumes.  While  only  certain  applications  will  benefit from the Thin Provisioning aspect, most can take advantage of the high performance per volume  feature.  It  is  vital,  however,  that  Hitachi  Data  Systems’  sales  personnel,  technical    staff,  value‐added  resellers,  and  others  who  are  responsible  delivery  of  solutions,  invest  the  time  required  to  design  the  best possible solution to meet each customer’s unique requirements, whether it be capacity, reliability,  performance  or  cost.   To assist  in  delivering  the  highest  quality  solution,  Hitachi  Data  Systems’  Global  Solution Services should be engaged.     

RESTRICTED CONFIDENTIAL 

Page 64 

Appendix 1. Universal Storage Platform V (Frames, HDUs, and Array Groups).   USP-V - L2 Frame (256 HDD) 18-16 12:0F 4 HDD

18-14 12:0D 4 HDD

18-12 12:0B 4 HDD

DKA 8 18-10 18-8 12:09 12:07 4 HDD 4 HDD

18-6 12:05 4 HDD

18-4 12:03 4 HDD

18-2 12:01 4 HDD

H D U

17-16 11:0F 4 HDD

17-14 11:0D 4 HDD

17-12 11:0B 4 HDD

DKA 7 17-10 17-8 11:09 11:07 4 HDD 4 HDD

17-6 11:05 4 HDD

17-4 11:03 4 HDD

17-2 11:01 4 HDD

18-15 12:0E 4 HDD

18-13 12:0C 4 HDD

18-11 12:0A 4 HDD

18-9 12:08 4 HDD

18-7 12:06 4 HDD

18-5 12:04 4 HDD

18-3 12:02 4 HDD

18-1 12:00 4 HDD

H D U

17-15 11:0E 4 HDD

17-13 11:0C 4 HDD

17-11 11:0A 4 HDD

17-9 11:08 4 HDD

17-7 11:06 4 HDD

17-5 11:04 4 HDD

17-3 11:02 4 HDD

17-1 11:00 4 HDD

16-16 10:0F 4 HDD

16-14 10:0D 4 HDD

16-12 10:0B 4 HDD

DKA 6 16-10 16-8 10:09 10:07 4 HDD 4 HDD

16-6 10:05 4 HDD

16-4 10:03 4 HDD

16-2 10:01 4 HDD

H D U

15-16 0F:0F 4 HDD

15-14 0F:0D 4 HDD

15-12 0F:0B 4 HDD

DKA 5 15-10 15-8 0F:09 0F:07 4 HDD 4 HDD

15-6 0F:05 4 HDD

15-4 0F:03 4 HDD

15-2 0F:01 4 HDD

16-15 10:0E 4 HDD

16-13 10:0C 4 HDD

16-11 10:0A 4 HDD

16-9 10:08 4 HDD

16-7 10:06 4 HDD

16-5 10:04 4 HDD

16-3 10:02 4 HDD

16-1 10:00 4 HDD

H D U

15-15 0F:0E 4 HDD

15-13 0F:0C 4 HDD

15-11 0F:0A 4 HDD

15-9 0F:08 4 HDD

15-7 0F:06 4 HDD

15-5 0F:04 4 HDD

15-3 0F:02 4 HDD

15-1 0F:00 4 HDD

10-16 0A:0F 4 HDD

10-14 0A:0D 4 HDD

10-12 0A:0B 4 HDD

DKA 8 10-10 10-8 0A:09 0A:07 4 HDD 4 HDD

10-6 0A:05 4 HDD

10-4 0A:03 4 HDD

10-2 0A:01 4 HDD

H D U

9-16 09:0F 4 HDD

9-14 09:0D 4 HDD

9-12 09:0B 4 HDD

DKA 7 9-10 9-8 09:09 09:07 4 HDD 4 HDD

9-6 09:05 4 HDD

9-4 09:03 4 HDD

9-2 09:01 4 HDD

10-15 0A:0E 4 HDD

10-13 0A:0C 4 HDD

10-11 0A:0A 4 HDD

10-9 0A:08 4 HDD

10-7 0A:06 4 HDD

10-5 0A:04 4 HDD

10-3 0A:02 4 HDD

10-1 0A:00 4 HDD

H D U

9-15 09:0E 4 HDD

9-13 09:0C 4 HDD

9-11 09:0A 4 HDD

9-9 09:08 4 HDD

9-7 09:06 4 HDD

9-5 09:04 4 HDD

9-3 09:02 4 HDD

9-1 09:00 4 HDD

8-16 08:0F 4 HDD

8-14 08:0D 4 HDD

8-12 08:0B 4 HDD

DKA 6 8-10 8-8 08:09 08:07 4 HDD 4 HDD

8-6 08:05 4 HDD

8-4 08:03 4 HDD

8-2 08:01 4 HDD

H D U

7-16 07:0F 4 HDD

7-14 07:0D 4 HDD

7-12 07:0B 4 HDD

DKA 5 7-10 7-8 07:09 07:07 4 HDD 4 HDD

7-6 07:05 4 HDD

7-4 07:03 4 HDD

7-2 07:01 4 HDD

8-15 08:0E 4 HDD

8-13 08:0C 4 HDD

8-11 08:0A 4 HDD

8-9 08:08 4 HDD

8-7 08:06 4 HDD

8-5 08:04 4 HDD

8-3 08:02 4 HDD

8-1 08:00 4 HDD

H D U

7-15 07:0E 4 HDD

7-13 07:0C 4 HDD

7-11 07:0A 4 HDD

7-9 07:08 4 HDD

7-7 07:06 4 HDD

7-5 07:04 4 HDD

7-3 07:02 4 HDD

7-1 07:00 4 HDD

2-16 02:0F

2-14 02:0D

2-12 02:0B

DKA 2 2-10 2-8 02:09 02:07

2-6 02:05

2-4 02:03

2-2 02:01

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

2-15 02:0E

2-13 02:0C

2-11 02:0A

2-9 02:08

2-7 02:06

2-5 02:02

2-3 02:02

2-1 02:00

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

6-16 06:0F

6-14 06:0D

6-12 06:0B

DKA 4 6-10 6-8 06:09 06:07

6-6 06:05

6-4 06:03

6-2 06:01

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

6-15 06:0E

6-13 06:0C

6-11 06:0A

6-9 06:08

6-7 06:06

6-5 06:04

6-3 06:02

6-1 06:00

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

USP-V - L1 Frame (256 HDD)

USP-V - Center Frame (128 HDD) H D U H D U

1-16 01:0F

1-14 01:0D

1-12 01:0B

DKA 1 1-10 1-8 01:09 01:07

1-6 01:05

1-4 01:03

1-2 01:01

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

1-15 01:0E

1-13 01:0C

1-11 01:0A

1-9 01:08

1-7 01:06

1-5 01:04

1-3 01:02

1-1 01:00

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

RAID 600 - R1 Frame (256 HDD)

4-16 04:0F

4-14 04:0D

4-12 04:0B

DKA 2 4-10 4-8 04:09 04:07

4-6 04:05

4-4 04:03

4-2 04:01

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4-15 04:0E

4-13 04:0C

4-11 04:0A

4-9 04:08

4-7 04:06

4-5 04:04

4-3 04:02

4-1 04:00

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

14-16 0E:0F

14-14 0E:0D

14-12 0E:0B

DKA 4 14-10 14-8 0E:09 0E:07

14-6 0E:05

14-4 0E:03

14-2 0E:01

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

14-15 0E:0E

14-13 0E:0C

14-11 0E:0A

14-9 0E:08

14-7 0E:06

14-5 0E:04

14-3 0E:02

14-1 0E:00

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

H D U H D U

H D U H D U

5-16 05:0F

5-14 05:0D

5-12 05:0B

DKA 3 5-10 5-8 05:09 05:07

5-6 05:05

5-4 05:03

5-2 05:01

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

5-15 05:0E

5-13 05:0C

5-11 05:0A

5-9 05:08

5-7 05:06

5-5 05:04

5-3 05:02

5-1 05:00

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

3-16 03:0F

3-14 03:0D

3-12 03:0B

DKA 1 3-10 3-8 03:09 03:07

3-6 03:05

3-4 03:03

3-2 03:01

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

3-15 03:0E

3-13 03:0C

3-11 03:0A

3-9 03:08

3-7 03:06

3-5 03:04

3-3 03:02

3-1 03:00

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

USP-V - R2 Frame (256 HDD)

12-16 0C:0F

12-14 0C:0D

12-12 0C:0B

DKA 2 12-10 12-8 0C:09 0C:07

12-6 0C:05

12-4 0C:03

12-2 0C:01

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

12-15 0C:0E

12-13 0C:0C

12-11 0C:0A

12-9 0C:08

12-7 0C:06

12-5 0C:04

12-3 0C:02

12-1 0C:00

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

RESTRICTED CONFIDENTIAL 

H D U

13-16 0D:0F

13-14 0D:0D

13-12 0D:0B

DKA 3 13-10 13-8 0D:09 0D:07

13-6 0D:05

13-4 0D:03

13-2 0D:01

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

H D U

13-15 0D:0E

13-13 0D:0C

13-11 0D:0A

13-9 0D:08

13-7 0D:06

13-5 0D:04

13-3 0D:02

13-1 0D:00

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

H D U

11-16 0B:0F

11-14 0B:0D

11-12 0B:0B

DKA 1 11-10 11-8 0B:09 0B:07

11-6 0B:05

11-4 0B:03

11-2 0B:01

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

H D U

11-15 0B:0E

11-13 0B:0C

11-11 0B:0A

11-9 0B:08

11-7 0B:06

11-5 0B:04

11-3 0B:02

11-1 0B:00

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

4 HDD

  Page 65 

Appendix 2. Open Systems RAID Mechanisms   This  section  describes  how  the  Open‐V  Open  Systems  Groups  function  on  both  the  Universal  Storage  Platform  and  the  Universal  Storage  Platform  V.  The  track  size  (chunk)  used  for  Open‐V  is  256KB.  The  available  9900  Lightning  style  Open‐X  emulation  is  available,  with  its  track  (chunk)  size  of  48KB.  One  should avoid mixing Open‐X and the standard Open‐V emulations on the same storage system.  When using generic RAID‐5, one would normally calculate the stripe width (row size) by multiplying the  RAID  chunk  size  (or  “stripe  size”)  by  7  (if  7D+1P).  In  the  case  of  Open  Systems  (Open‐V  volumes),  the  Universal Storage Platform V uses a native chunk size of 256KB. Hence you would expect a row size of  1,792KB.  However,  the  Universal  Storage  Platform  V  manages  RAID‐5  somewhat  differently  than  any  other vendor. For both Universal Storage Platform V RAID‐5+ types, there are two adjacent 256KB RAID  chunks taken from the same disk before switching to the next disk in the row, so the effective chunk size  is 512KB. This is illustrated in the two Figures below. Thus, there are twice as many chunks per row as  normal.  So  the  Universal  Storage  Platform  V’s  RAID‐5+  7D+1P  stripe  width  is  actually  3,584KB  (7  x  512KB). The Universal Storage Platform V’s RAID‐5+ (3D+1P) stripe width is actually 1,536KB (3 x 512KB).  Figure 40. RAID-5+ (7D+1P) Layout (3,584KB stripe width). 7D+1P OPEN-V Primary Disk 1

Parity Disk 2

Disk 3

Disk 4

Disk 5

Disk 6

Disk 7

Disk 8

Stripe Set 1

Stripe Set 2

  Figure 41. RAID-5+ (3D+1P) Layout (1,536KB stripe width).

  RESTRICTED CONFIDENTIAL 

Page 66 

When using generic RAID‐10, one would normally calculate the stripe width (row size) by multiplying the  RAID chunk size (or “stripe size”) by 2  (if 2D+2D). In the  case of Open Systems (Open‐V volumes),  the  Universal Storage Platform V uses a native chunk size of 256KB. Hence you would expect a row size of  512KB.   However, the Universal Storage Platform V manages RAID‐10+ in the same manner as RAID‐5+, where  there are two adjacent RAID chunks taken from the same disk before switching to the next disk in the  row. This is illustrated in the next Figure. Thus, there are twice as many chunks per row as normal. So  the Universal Storage Platform V’s RAID‐10+ (2D+2D) is 1,024KB (4 x 512KB).   Figure 42. RAID-10+ (2D+2D) Layout (stripe width 1024KB).

  The  Universal  Storage  Platform  V  manages  RAID‐6+  in  the  same  manner  as  RAID‐5+,  where  there  are  two adjacent RAID chunks taken from the same disk before switching to the next disk in the row. This is  illustrated  in  the  Figure  below.  Thus,  there  are  twice  as  many  chunks  per  row  as  normal.  So  the  Universal Storage Platform V’s RAID‐6 6D+2P stripe width is 3,072KB (6 x 512KB).  Figure 43. RAID-6+ (6D+2P) Layout (stripe width 3,072KB)

6D+2P OPEN-V Primary Disk 1

Parity Disk 2

Disk 3

Disk 4

Disk 5

Disk 6

Disk 7

Disk 8

 

RESTRICTED CONFIDENTIAL 

Page 67 

Appendix 3. Mainframe 3390x and Open-x RAID Mechanisms   This  section  describes  how  the  3390x  (mainframe)  and  Open‐X  (9900V  Lightning  style  Open  Systems  volumes)  Parity  Groups  function  on  both  the  Universal  Storage  Platform  and  the  Universal  Storage  Platform V. The track size (chunk) used for 3390x is 58KB, and the Open‐X track (chunk) size is 48KB. One  should avoid mixing Open‐X and the standard Open‐V on the same storage system.  RAID‐5+  When using generic RAID‐5, one would normally calculate the stripe width (row size) by multiplying the  RAID chunk size (or “stripe size”) by 7 (if 7D+1P). In the case of mainframe emulation (3390‐x volumes),  the Universal Storage Platform V uses a native track size of 58KB. Hence you would expect a row size of  406KB (7 x 58KB). For the Open‐X emulation, the track size is 48KB, with an expected row size of 336KB  (7 x 48KB).   However,  the  Universal  Storage  Platform  V  manages  RAID‐5  somewhat  differently  than  any  other  vendor. For both Universal Storage Platform V RAID‐5+ types, there are eight adjacent tracks taken from  the same disk before switching to the next disk in the row. This is illustrated in the two Figures below.  The Universal Storage Platform V’s RAID‐5+ 7D+1P stripe width for 3390‐X is 3,248KB (7 x 8 x 58KB), and  for Open‐X it is 2,688KB (7 x 8 x 48KB). The Universal Storage Platform V’s RAID‐5+ (3D+1P) stripe width  for 3390‐X is 1,392KB (3 x 8 x 256KB), and for Open‐X it is 1,152KB (3 x 8 x 48KB).  Figure 44. RAID-5+ (7D+1P) Layout, 3390-X and Open-X 7D+1P 3390-x & OPEN-x Primary Disk 1

Parity Disk 2

Disk 3

Disk 4

Disk 5

Disk 6

Disk 7

Disk 8

Stripe Set 1

Stripe Set 2

   

RESTRICTED CONFIDENTIAL 

Page 68 

Figure 45. RAID-5+ (3D+1P) Layout, 3390-X and Open-X

3D+1P 3390-x & OPEN-x Primary Disk 1

Parity Disk 2

Disk 3

Disk 4

Stripe Set 1

Stripe Set 2

    RAID‐10+  When using generic RAID‐10, one would normally calculate the stripe width (row size) by multiplying the  RAID chunk size (or “track size”) by 2 (if 2D+2D). In the case of mainframe emulation (3390‐x volumes),  the Universal Storage Platform V uses a native track size of 58KB. Hence you would expect a row size of  116KB (2 x 58KB). For the Open‐X emulation, the track size is 48KB, with an expected row size of 96KB (2  x 48KB).   However, the Universal Storage Platform V manages RAID‐10+ in the same manner as RAID‐5+, where  there are eight adjacent tracks taken from the same disk before switching to the next disk in the row.  This is illustrated in the two Figures below. So the Universal Storage Platform V’s RAID‐10+ (2D+2D) is  928KB (2 x 8 x 58KB). The Universal Storage Platform V’s RAID‐10+ stripe width for Open‐X is 768KB (2 x  8 x 48KB).   

RESTRICTED CONFIDENTIAL 

Page 69 

Figure 46. RAID-10+ (2D+2D) Layout, 3390-X and Open-X.

  RAID‐6+  The  Universal  Storage  Platform  V  manages  RAID‐6+  in  the  same  manner  as  RAID‐5+  where  there  are  eight  adjacent  tracks  taken  from  the  same  disk  before  switching  to  the  next  disk  in  the  row.  This  is  illustrated in the Figure below. Thus, there are twice as many chunks per row as normal. So, for 3390‐X,  the Universal Storage Platform V’s RAID‐6 6D+2P stripe width is actually 2,784KB (6 x 8 x 58KB), and for  Open‐X it is 2,304KB (6 x 8 x 48KB).  Figure 47. RAID-6+ (6D+2P) Layout, 3390-X and Open-X.

 

RESTRICTED CONFIDENTIAL 

Page 70 

Appendix 4. BED: Loop Maps with Array Group Names USP-V (Front View) Cluster-1 BED-6 BED16 Slot 1KU Loop PGrp 0 8, 16 1 8, 16 2 8, 16 3 8, 16

BED-5 BED14 Slot 1LU Loop PGrp 0 7, 15 1 7, 15 2 7, 15 3 7, 15

BED-2 BED12 Slot 1BU Loop PGrp 0 2, 4, 12 1 2, 4, 12 2 2, 4, 12 3 2, 4, 12

BED-1 BED10 Slot 1AU Loop PGrp 0 1, 3, 11 1 1, 3, 11 2 1, 3, 11 3 1, 3, 11

BED-8 BED17 Slot 1KL Loop PGrp 0 10, 18 1 10, 18 2 10, 18 3 10, 18

BED-7 BED15 Slot 1LL Loop PGrp 0 9, 17 1 9, 17 2 9, 17 3 9, 17

BED-4 BED13 Slot 1BL Loop PGrp 0 6, 14 1 6, 14 2 6, 14 3 6, 14

BED-3 BED11 Slot 1AL Loop PGrp 0 5, 13 1 5, 13 2 5, 13 3 5, 13

USP-V (Rear View) Cluster-2 BED-1 BED18 Slot 2MU Loop PGrp 0 1, 3, 11 1 1, 3, 11 2 1, 3, 11 3 1, 3, 11

BED-2 BED1A Slot 2NU Loop PGrp 0 2, 4, 12 1 2, 4, 12 2 2, 4, 12 3 2, 4, 12

BED-5 BED1C Slot 2XU Loop PGrp 0 7, 15 1 7, 15 2 7, 15 3 7, 15

BED-6 BED1E Slot 2WU Loop PGrp 0 8, 16 1 8, 16 2 8, 16 3 8, 16

BED-3 BED19 Slot 2ML Loop PGrp 0 5, 13 1 5, 13 2 5, 13 3 5, 13

BED-4 BED1B Slot 2NL Loop PGrp 0 6, 14 1 6, 14 2 6, 14 3 6, 14

BED-7 BED1D Slot 2XL Loop PGrp 0 9, 17 1 9, 17 2 9, 17 3 9, 17

BED-8 BED1F Slot 2WL Loop PGrp 0 10, 18 1 10, 18 2 10, 18 3 10, 18

RESTRICTED CONFIDENTIAL 

 

Page 71 

Appendix 5. FED: 8-Port Fibre Channel Maps with Processors USP-V (Front View) OPEN_Fibre 8-port Cluster-1 FED-6 FED06 Slot 1HU Port MP 1N mp1 3N mp2 1P mp3 3P mp4

FED-5 FED04 Slot 1GU Port MP 1J mp1 3J mp2 1K mp3 3K mp4

FED-2 FED02 Slot 1FU Port MP 1E mp1 3E mp2 1F mp3 3F mp4

FED-1 FED00 Slot 1EU Port MP 1A mp1 3A mp2 1B mp3 3B mp4

FED-8 FED07 Slot 1HL Port MP 1Q mp1 3Q mp2 1R mp3 3R mp4

FED-7 FED05 Slot 1GL Port MP 1L mp1 3L mp2 1M mp3 3M mp4

FED-4 FED03 Slot 1FL Port MP 1G mp1 3G mp2 1H mp3 3H mp4

FED-3 FED01 Slot 1EL Port MP 1C mp1 3C mp2 1D mp3 3D mp4

USP-V (Rear View) OPEN_Fibre 8-port Cluster-2 FED-1 FED08 Slot 2QU Port MP 2A mp1 4A mp2 2B mp3 4B mp4

FED-2 FED0A Slot 2RU Port MP 2E mp1 4E mp2 2F mp3 4F mp4

FED-5 FED0C Slot 2TU Port MP 2J mp1 4J mp2 2K mp3 4K mp4

FED-6 FED0E Slot 2UU Port MP 2N mp1 4N mp2 2P mp3 4P mp4

FED-3 FED09 Slot 2QL Port MP 2C mp1 4C mp2 2D mp3 4D mp4

FED-4 FED0B Slot 2RL Port MP 2G mp1 4G mp2 2H mp3 4H mp4

FED-7 FED0D Slot 2TL Port MP 2L mp1 4L mp2 2M mp3 4M mp4

FED-8 FED0F Slot 2UL Port MP 2Q mp1 4Q mp2 2R mp3 4R mp4

RESTRICTED CONFIDENTIAL 

 

Page 72 

Appendix 6. FED: 16-Port Fibre Channel Maps with Processors USP-V (Front View) OPEN_Fibre 16-port Cluster-1 FED-6 FED06 Slot 1HU Port MP 1N mp1 3N mp2 5N mp1 7N mp2 1P mp3 3P mp4 5P mp3 7P mp4

FED-5 FED04 Slot 1GU Port MP 1J mp1 3J mp2 5J mp1 7J mp2 1K mp3 mp4 3K 5K mp3 mp4 7K

FED-2 FED02 Slot 1FU Port MP 1E mp1 3E mp2 5E mp1 7E mp2 1F mp3 3F mp4 5F mp3 7F mp4

FED-1 FED00 Slot 1EU Port MP 1A mp1 3A mp2 5A mp1 7A mp2 1B mp3 3B mp4 5B mp3 7B mp4

FED-8 FED07 Slot 1HL Port MP 1Q mp1 mp2 3Q mp1 5Q mp2 7Q 1R mp3 3R mp4 5R mp3 7R mp4

FED-7 FED05 Slot 1GL Port MP 1L mp1 3L mp2 5L mp1 7L mp2 1M mp3 3M mp4 5M mp3 7M mp4

FED-4 FED03 Slot 1FL Port MP 1G mp1 3G mp2 5G mp1 7G mp2 1H mp3 3H mp4 5H mp3 7H mp4

FED-3 FED01 Slot 1EL Port MP 1C mp1 3C mp2 5C mp1 7C mp2 1D mp3 3D mp4 5D mp3 7D mp4

USP-V (Rear View) OPEN_Fibre 16-port Cluster-2 FED-1 FED08 Slot 2QU Port MP 2A mp1 4A mp2 6A mp1 8A mp2 2B mp3 4B mp4 6B mp3 8B mp4

FED-2 FED0A Slot 2RU Port MP 2E mp1 4E mp2 6E mp1 8E mp2 2F mp3 4F mp4 6F mp3 8F mp4

FED-5 FED0C Slot 2TU Port MP 2J mp1 4J mp2 6J mp1 8J mp2 2K mp3 4K mp4 6K mp3 8K mp4

FED-6 FED0E Slot 2UU Port MP 2N mp1 4N mp2 6N mp1 8N mp2 2P mp3 4P mp4 6P mp3 8P mp4

FED-3 FED09 Slot 2QL Port MP 2C mp1 4C mp2 6C mp1 8C mp2 2D mp3 4D mp4 6D mp3 8D mp4

FED-4 FED0B Slot 2RL Port MP 2G mp1 4G mp2 6G mp1 8G mp2 2H mp3 4H mp4 6H mp3 8H mp4

FED-7 FED0D Slot 2TL Port MP 2L mp1 4L mp2 6L mp1 8L mp2 2M mp3 4M mp4 6M mp3 8M mp4

FED-8 FED0F Slot 2UL Port MP 2Q mp1 mp2 4Q 6Q mp1 8Q mp2 2R mp3 4R mp4 6R mp3 8R mp4

RESTRICTED CONFIDENTIAL 

  Page 73 

Appendix 7. FED: 8-Port FICON Maps with Processors   USP-V (Front View) FICON Cluster-1 FED-6 FED06 Slot 1HU Port MP 1N 1, 2 3N 1, 2 5N 3, 4 7N 3, 4

FED-5 FED04 Slot 1GU Port MP 1J 1, 2 3J 1, 2 5J 3, 4 7J 3, 4

FED-2 FED02 Slot 1FU Port MP 1E 1, 2 3E 1, 2 5E 3, 4 7E 3, 4

FED-1 FED00 Slot 1EU Port MP 1A 1, 2 3A 1, 2 5A 3, 4 7A 3, 4

FED-8 FED07 Slot 1HL Port MP 1, 2 1Q 1, 2 3Q 3, 4 5Q 7Q 3, 4

FED-7 FED05 Slot 1GL Port MP 1L 1, 2 3L 1, 2 5L 3, 4 7L 3, 4

FED-4 FED03 Slot 1FL Port MP 1G 1, 2 3G 1, 2 5G 3, 4 7G 3, 4

FED-3 FED01 Slot 1EL Port MP 1C 1, 2 3C 1, 2 5C 3, 4 7C 3, 4

USP-V (Rear View) FICON Cluster-2 FED-1 FED08 Slot 2QU Port MP 2A 1, 2 4A 1, 2 6A 3, 4 8A 3, 4

FED-2 FED0A Slot 2RU Port MP 2E 1, 2 4E 1, 2 6E 3, 4 8E 3, 4

FED-5 FED0C Slot 2TU Port MP 2J 1, 2 4J 1, 2 6J 3, 4 8J 3, 4

FED-6 FED0E Slot 2UU Port MP 2N 1, 2 4N 1, 2 6N 3, 4 8N 3, 4

FED-3 FED09 Slot 2QL Port MP 2C 1, 2 4C 1, 2 6C 3, 4 8C 3, 4

FED-4 FED0B Slot 2RL Port MP 2G 1, 2 4G 1, 2 6G 3, 4 8G 3, 4

FED-7 FED0D Slot 2TL Port MP 2L 1, 2 4L 1, 2 6L 3, 4 8L 3, 4

FED-8 FED0F Slot 2UL Port MP 2Q 1, 2 1, 2 4Q 3, 4 6Q 8Q 3, 4

 

RESTRICTED CONFIDENTIAL 

Page 74 

Appendix 8. FED: 8-Port ESCON Maps with Processors   USP-V (Front View) ESCON Cluster-1 FED-6 FED06 Slot 1HU Port MP 1N 1, 2 3N 1, 2 5N 1, 2 7N 1, 2

FED-5 FED04 Slot 1GU Port MP 1J 1, 2 3J 1, 2 5J 1, 2 7J 1, 2

FED-2 FED02 Slot 1FU Port MP 1E 1, 2 3E 1, 2 5E 1, 2 7E 1, 2

FED-1 FED00 Slot 1EU Port MP 1A 1, 2 3A 1, 2 5A 1, 2 7A 1, 2

FED-8 FED07 Slot 1HL Port MP 1P 1, 2 3P 1, 2 5P 1, 2 7P 1, 2

FED-7 FED05 Slot 1GL Port MP 1K 1, 2 3K 1, 2 5K 1, 2 7K 1, 2

FED-4 FED03 Slot 1FL Port MP 1F 1, 2 3F 1, 2 5F 1, 2 7F 1, 2

FED-3 FED01 Slot 1EL Port MP 1B 1, 2 3B 1, 2 5B 1, 2 7B 1, 2

USP-V (Rear View) ESCON Cluster-2 FED-1 FED08 Slot 2QU Port MP 2A 1, 2 4A 1, 2 6A 1, 2 8A 1, 2

FED-2 FED0A Slot 2RU Port MP 2E 1, 2 4E 1, 2 6E 1, 2 8E 1, 2

FED-5 FED0C Slot 2TU Port MP 2J 1, 2 4J 1, 2 6J 1, 2 8J 1, 2

FED-6 FED0E Slot 2UU Port MP 2N 1, 2 4N 1, 2 6N 1, 2 8N 1, 2

FED-3 FED09 Slot 2QL Port MP 2B 1, 2 4B 1, 2 6B 1, 2 8B 1, 2

FED-4 FED0B Slot 2RL Port MP 2F 1, 2 4F 1, 2 6F 1, 2 8F 1, 2

FED-7 FED0D Slot 2TL Port MP 2K 1, 2 4K 1, 2 6K 1, 2 8K 1, 2

FED-8 FED0F Slot 2UL Port MP 2P 1, 2 4P 1, 2 6P 1, 2 8P 1, 2

         

RESTRICTED CONFIDENTIAL 

Page 75 

Appendix 9. Veritas™ Volume Manager Example  

This diagram illustrates a typical Veritas host LVM configuration and naming conventions.  SERVERS

STORAGE

Vol 01

Plex #1 data

Volume #1

Plex #2 log

Vol 03

Plex #3

Volume #2

VM10

Veritas VM Disk Pool VM09

VM11

VM12

VM13

Vol 03

Plex #4

VM15

Volume #3

VM14

VM16

LUN

VM08

LUN

LUN

VM07

LUN

LUN

VM06

LUN

LUN

VM05

LUN

LUN

VM04

LUN

LUN

VM03

LUN

LUN

VM02

LUN

LUN

VM01

LUN

The volumes are used for raw space or files systems.

Volume – a set of 1 or more plexes

PLEX- a set of subdisks with either a striping (usually RAID-0) or cancatention association among them.

VM disks (each LUN), with a Private and Public Region. Public Regions are cut into one or more Subdisks which are used as Plex building blocks.

LUNs - from RAID Groups

Page 76 

RESTRICTED CONFIDENTIAL 

 

Appendix 10. Pool Details   This section illustrates the Hitachi Dynamic Provisioning environment with naming conventions. Note  the similarities in concepts to the previous Veritas example. 

 

RESTRICTED CONFIDENTIAL 

Page 77 

Appendix 11. Pool Example This illustrates an example of a Pool and DPVOLs.   

 

RESTRICTED CONFIDENTIAL 

Page 78 

Appendix 12. Disks - Physical IOPS Details   These  are  examples  of  maximum  expected  physical  disk  Read  and  Write  IOPS  rates  for  three  types  of  disks. The “Cylinders” columns show the percentage of surface space in use as disk partitions. As more  disk surface is brought into use, the heads must seek farther inwards, which increases the average seek  times.  Note  that  the  Write  table  shows  reduced  maximum  IOPS  due  to  the  higher  track  centering  precision  required  for  writes.    Please  note  in  the  tables  below  that  the  three  drive  types  use  a  representative  capacity.    For  instance,  almost  all  15K  RPM  HDDs  would  be  very  similar  to  the  300GB  Seagate 15K used in the first entry.  Table 17. Calculated Maximum Disk Read IOPS Rates by Type and Active Surface Usage

Reads at 100% Busy 300GB Seagate Fibre Channel 15k RPM  Disk RPM  Average Read Seek Time  Average Rotational Delay  Average Access Time  Random 8KB IOPS Rate    

Cylinders 25% 

50% 

75% 

100% 

15,000  1.8  2.0  3.8 

15,000  2.5  2.0  4.5 

15,000  2.8  2.0  4.8 

15,000  3.5  2.0  5.5 

267 

225 

208 

182 

  

  

  

  

146GB Hitachi Fibre Channel 10k RPM  Disk RPM  Average Read Seek Time  Average Rotational Delay  Average Access Time  Random 8KB IOPS Rate    

25%  10,000  2.4  3.0  5.4  187    

50%  10,000  3.3  3.0  6.3  159    

75%  10,000  3.8  3.0  6.8  148    

100%  10,000  4.7  3.0  7.7  130    

750GB Seagate SATA 7.2k RPM  Disk RPM  Average Read Seek Time  Average Rotational Delay  Average Access Time 

25%  7,200  4.3  4.2  8.4 

50%  7,200  6.0  4.2  10.1 

75%  7,200  6.8  4.2  11.0 

100%  7,200  8.5  4.2  12.7 

119 

99 

91 

79 

Random 8KB IOPS Rate 

RESTRICTED CONFIDENTIAL 

Page 79 

Table 2. Calculated maximum disk Write IOPS rates by type and active surface usage

Writes at  100% Busy 

Cylinders 

300GB Seagate Fibre Channel 15k RPM  Disk RPM  Average Write Seek Time  Average Rotational Delay  Average Access Time  Random 8KB IOPS Rate     146GB Hitachi Fibre Channel 10k RPM  Disk RPM  Average Write Seek Time  Average Rotational Delay  Average Access Time  Random 8KB IOPS Rate 

25%  15,000  2.0  2.0  4.0  250     25%  10,000  2.6  3.0  5.6  180 

50%  15,000  2.8  2.0  4.8  208     50%  10,000  3.6  3.0  6.6  152 

75%  15,000  3.2  2.0  5.2  192     75%  10,000  4.1  3.0  7.1  141 

100%  15,000  4.0  2.0  6.0  167     100%  10,000  5.1  3.0  8.1  123 

   750GB Seagate SATA 7.2k RPM  Disk RPM  Average Write Seek Time  Average Rotational Delay  Average Access Time 

   25%  7,200  5.0  4.2  9.2 

   50%  7,200  7.0  4.2  11.2 

   75%  7,200  8.0  4.2  12.2 

   100%  7,200  10.0  4.2  14.2 

109 

90 

82 

71 

Random 8KB IOPS Rate 

The  two  tables  below  indicate  what  IOPS  rates  (small  block  random)  might  be  expected  from  RAID  Groups  of  different  types  when  using  15K  RPM  SAS  disks  or  7200  RPM  SATA‐II  disks.  The  disk  IOPS  reference values were taken from Tables 1 and 2 above, from the 50% surface usage columns. The left  side  of  each  table  is  the  expected  maximum  rate  where  the  disks  are  operating  at  100%  busy  (not  recommended). The right side of each table shows a more realistic 30% busy rate. For example, when  using 15K RPM SAS drives with RAID‐5 (7D+1P) at a 30% busy rate, you should plan for about 540 IOPS  for 100% Reads, or 125 IOPS for 100% Writes. Take note these are all cache miss values.  Table 3. Calculated RAID Group IOPS Rates (SAS) by RAID Level and Percent Busy Rates

Total Disk IOPS by RAID Group (100% busy)     15k RPM Disks     Using IOPS =  

  

Total Disk IOPS by RAID Group (30% busy)  15k RPM Disks    

225 

208 

225 

208 

   RAID Type    

IOPS  Available for  Random Read 

IOPS  Available for  Random Write 

   RAID Type    

IOPS  Available for  Random Read 

IOPS  Available for  Random Write 

RAID‐1+0  2+2  4+4  RAID‐5  3+1 

   900  1,800     900 

   416  832     208 

RAID‐10  2+2  4+4  RAID‐5  3+1 

   270  540     270 

   125  250     62 

7+1  RAID‐6 

1,800    

416    

7+1  RAID‐6 

540    

125    

6+2 

1,800 

277 

6+2 

540 

83 

RESTRICTED CONFIDENTIAL 

Using IOPS = 

Page 80 

Table 4. Calculated RAID Group IOPS Rates (SATA-II) by RAID Level and Percent Busy Rates

Total Disk IOPS by RAID Group (100% busy)     7.2k RPM SATA     Using IOPS=  

Total Disk IOPS by RAID Group (30% busy)     7.2k RPM SATA    

99 

90 

99 

90 

   RAID Type     RAID‐1+0  2+2  4+4  RAID‐5  3+1  7+1  RAID‐6 

IOPS  Available for  Random Read     396  792     396  792    

IOPS  Available for  Random Write     90  180     60  120    

   RAID Type     RAID‐1+0  2+2  4+4  RAID‐5  3+1  7+1  RAID‐6 

IOPS  Available for  Random Read     119  238     119  238    

IOPS  Available for  Random Write     27  54     18  36    

6+2 

792 

80 

6+2 

238 

24 

RESTRICTED CONFIDENTIAL 

Using IOPS=  

Page 81 

Appendix 13. File Systems and Hitachi Dynamic Provisioning Thin Provisioning   The table below shows various guidelines for different file systems and their formatting behavior on a  DPVOL. 

     

RESTRICTED CONFIDENTIAL 

Page 82 

Appendix 14. Putting SATA Drive Performance into Perspective   By Ian Vogelesang  The fact that we already worry about “hot spots” (busy parity groups) means that Fibre Channel drives  are already quite busy.  In other words, we generally adjust workloads on Fibre Channel drives to stay  within their IOPS handling capability.  For example, the performance benefit of Dynamic Provisioning is that the I/O activity associated with a  large  number  of  host  DP‐VOLs  can  be  combined  and  distributed  over  many  parity  groups.    This  evens  out the activity over those many parity groups and thus eliminates hot spots.  Thus,  by  eliminating  hot  spots,  Dynamic  Provisioning  lets  you  raise  average  parity  group  utilization  (%  busy)  somewhat.    But  what  does  “raise  parity  group  utilization”  mean?    It  means  “put  more  data  on  each drive”.  If we  combine the data from two separate hosts or two applications together and store them on one  parity group, we are also combining the associated activity (IOPS) together.  Thus if we put twice as much data of the same type on one disk drive, we will also double the activity  (IOPS)  on  the  drive.    Notice  that  there  is  the  concept  of  the  type  of  data  in    of  its  intensity  of  access.    Some  types  of  data  are  infrequently  accessed,  and  others  are  heavily  accessed.    This  is  a  fundamental characteristic of the data, no matter what type of drive the data is used to store the data.   The  activity  is  associated  with  the  data,  and  if  you  have  twice  the  data,  you  will  have  twice  the  associated activity.  We call this intrinsic measure of the activity associated with a given amount of data the Access Density,  and it is measured in IOPS per GB.  For example, if you have 100 IOPS associated with 200GB of data the  access density for that data is 100 IOPS per 200GB of data, or 0.5 IOPS per GB.  Compared to Fibre Channel drives:  ‐ SATA drives have a much lower IOPS capability on a per drive basis.  ‐ SATA drives have a much higher storage capacity on a per drive basis.    Thus  to  figure  out  if  it’s  cost‐effective  to  use  SATA  drives,  you  need  to  figure  out  not  only  how  many  SATA drives it will take to hold the data, but also how many SATA drives it will take to handle the IOPS  that come with the data.  In general we can’t put most “normal” types of data on SATA drives, because SATA drives have a much  lower IOPS limit than that of Fibre Channel drives.  Let’s look at some numbers:  Each I/O operation begins with mechanical positioning, which starts with a seek operation (to move the  access arm into position) followed by latency (waiting for the drive to turn until the starting point of the  target data comes under the head). 

RESTRICTED CONFIDENTIAL 

Page 83 

The average seek time for a disk drive is generally longer than the average latency (1/2 turn), so in the  time it takes to do the mechanical positioning, the drive makes more than one full rotation.  However, a  random I/O typically processes a 4 KB or 8 KB block, which is on the order of one percent of the storage  capacity of one disk drive track.  The capacity of one track varies a lot between drive types and the inner  and outer zones of the drive, but in general the transfer time for a random I/O block is on the order of  less than 1% of the total I/O service time, so random I/O is 99% mechanical positioning.  Nominal “one at a time” IOPS capability of sample drive types:   

1TB SATA drive 

400GB 10,000 RPM Fibre  Channel drive 

300GB 15,000 RPM Fibre  Channel drive 

Average read seek time 

8.5 ms 

4.9 ms 

3.5 ms 

Average latency  This is ½ of a rotation. 

4.2 ms 

3.0 ms 

2.0 ms 

Total mechanical positioning  time (read) 

12.7 ms 

7.9 ms 

5.5 ms 

Read IOPS capability  This is the number of (read)  mechanical positioning  operations (IOPS) that can be  done in one second, “one at  a time”.  

79 IOPS 

127 IOPS 

182 IOPS 

  When we factor in the amount of data that is stored on the drive, we can calculate the base “one at a  time” read access density capability of each type of drive:   

1TB SATA drive 

400GB 10,000 RPM Fibre  Channel drive 

300GB 15,000 RPM Fibre  Channel drive 

Read IOPS capability  Number of (read) mechanical  positioning operations (IOPS)  that can be done in one  second, “one at a time”. 

79 IOPS 

127 IOPS 

182 IOPS 

Storage capacity, GB 

1,000GB 

400GB 

300GB 

.08 IOPS per GB 

.32 IOPS per GB 

.61 IOPS per GB 

Nominal read access density  capability 

 

RESTRICTED CONFIDENTIAL 

Page 84 

Random Read Access Density,  IOPS per GB (one read at a time) 1 0.5 0

1 TB SATA  10K 400

15K 300  

What we can see here is that if we fill each drive with data, 10 K RPM drives are capable of handling data  that is 4x as active as the data we can put on a SATA drive, and 15K RPM drives are capable of handling  data that is 8x as active.  It gets worse.  I/O  operations  are  not  issued  one‐at‐a‐time.    Multiple  I/O  operations  (each  identified  by  a  “tag”)  are  issued  at  once  to  each  disk  drive,  in  order  to  let  the  disk  drive  decide  what  order  to  perform  the  I/O  operations in, so as to minimize the amount of seeking and rotational delay necessary.  This capability to  reduce average mechanical positioning time is called Tagged Command Queuing, or TCQ.  Fibre  Channel  drives  have  substantially  more  microprocessor  horsepower  than  SATA  drives,  and  as  a  result,  they  get  substantially  higher  boosts  in  throughput  through  the  use  of  TCQ.    The  amount  of  throughput boost from TCQ varies by workload, but for the purposes of illustration, it’s reasonable to  show at 25% boost in IOPS capability using TCQ for SATA, and a 50% boost for Fibre Channel.  Now a more realistic comparison for read Access Density capability is shown:  

Random Read Access Density,  IOPS per GB (with Tagged Command Queuing) 1 0.5 0

1 TB SATA  10K 400

15K 300  

Now the Access Density capability of 10 K RPM drives is roughly 5x that of SATA, and 15K RPM drives  roughly 10x that of SATA.  It gets even worse.  The  use  of  SATA  drives  in  subsystem  applications  is  relatively  recent,  and  protecting  the  integrity  of  customer data is paramount.  Therefore, Hitachi subsystems perform a read‐ operation after every  RESTRICTED CONFIDENTIAL 

Page 85 

write with SATA drives.  This adds a “random read” positioning time after every write operation.  Note  that this is not “one extra rotation”, but truly a full random read positioning, as in general multiple I/O  operations are queued in the drive at once, and therefore the read‐ operation goes in the queue  after  the  write  completes,  and  other  I/O  operations  in  general  will  intervene  between  the  write  and  subsequent read . 

Random Write Access Density,  IOPS per GB (with Tagged Command Queuing & SATA  read ) 1 0.5 0

1 TB SATA  10K 400

15K 300  

For random writes, the 10K RPM drive is capable of handling about 10x the access density of the SATA  drive, and the 15K RPM drive about 18x that of the SATA drive.  These numbers are only rough estimates, but what you can clearly see here is that in order to realize the  cost  effectiveness  of  SATA  drives,  that  is,  in  order  to  take  advantage  of  the  storage  capacity  of  SATA  drives, they need to be filled with data.  The only type of data that can fill a SATA drive is data that is  approximately  an  order  of  magnitude  (10  times)  less  active  than  data  that  would  normally  be  put  on  Fibre Channel drives.  Failure  to  understand  this  10x  difference  in  access  density  capability  can  result  in  serious  SATA  drive  deployment problems.  If normal Fibre Channel drive‐type data is placed on SATA drives, the result will  usually be that the SATA drives cannot keep up with the IOPS demand, and subsystem cache will fill up  with  data  waiting  to  be  written  to  the  SATA  drives.    In  order  to  treat  the  symptom  (excessive  “write  pending”), SATA drive workloads can be placed in their own Cache Logical Partition (CLPR).  Even though  this  may  isolate  other  workloads  from  the  problem,  the  SATA  drives  will  still  be  a  bottleneck  constraining the throughput of the application that is using them.  The summary on SATA drives is that if they are used for traditional application data, there are only two  scenarios:  1) Cost was reduced by putting over 100GB of normal data on a 1 TB SATA drive.  Excessive write  pending forces the SATA drives to be isolated in a CLPR.  Cost was reduced, but throughput is  drastically reduced.   2) Less than 100GB of data was placed on each SATA drive.  The extra money (over and above  what it would have cost for Fibre Channel drivers) was spent in order to provide enough SATA  drives to handle the IOPS.  For this price  the result is slower response time and higher  electrical power costs.  Thus only if you have a type of workload that has at most 1/10th the access density of normal workloads  will SATA drives be cost effective.  RESTRICTED CONFIDENTIAL 

Page 86 

Appendix 15. LDEVs, LUNs, VDEVs and More   An  LDEV  is  a  logical  volume  internal  to  the  subsystem,  which  can  hold  host  data.    LDEVs  are   “carved” from a logical container called a VDEV.  In the diagram below, an internal VDEV is shown, which  maps to the formatted space (net of parity) in a Parity Group.  Figure 1. Overview of Logical Devices.

Host

Multi-path software device driver’s LUN

HBA device driver’s LUN

HBA

HBA

Switch

Switch

Physical Port

Physical Port

Logical Port

Logical Port

LU

Physical port Host Storage Domain (HSD)

LU Logical constructs

HDEV

LDEV VDEV

LUSE

Physical disk drives

Parity group

RESTRICTED CONFIDENTIAL 

Page 87 

Figure 2. Alternate Overview of Logical Devices.

Host Group

LUN

HDEV

LUSE

LUSE

LDEV

LDEV

LDEV

LDEV

LDEV

LDEV

COW V-VOL

COW V-VOL

DPVol

DPVol

VDEV (internal)

VDEV (concat. parity group)

VDEV (external)

VDEV (internal)

VDEV (concat. parity group)

VDEV (external)

VDEV (CoW V-Vol Grp)

VDEV (CoW V-Vol Grp)

VDEV (HDP V-Vol Grp)

VDEV (HDP V-Vol Grp)

LUN (external)

Parity Group

LUN (external)

CoW Pool

CoW Pool

HDP Pool

HDP Pool

Parity Group

VDEV (internal) < 2.99TB

LDEV LDEV Parity LDEV Group

VDEV (external) < 4TB

VDEV (CoW V-Vol Grp) 4 TB

LDEV LDEV Parity LDEV Group

LDEV LDEV LDEV LDEV LDEV LDEV

LDEV LDEV LDEV LDEV LDEV LDEV

LDEV LDEV LDEV LDEV LDEV LDEV

LDEV LDEV LDEV LDEV LDEV LDEV

LDEV LDEV LDEV LDEV VDEV LDEV (internal)

LDEV LDEV LDEV LDEV VDEV LDEV (external)

LDEV LDEV LDEV LDEV VDEV LDEV (internal)

LDEV LDEV LDEV LDEV VDEV LDEV (external)

LDEV LDEV LDEV LDEV Parity LDEV Group

LDEV LDEV LDEV LDEV LUN LDEV (external)

LDEV LDEV LDEV LDEV Parity LDEV Group

LDEV LDEV LDEV LDEV LUN LDEV (external)

VDEV (HDP V-Vol Grp) 4 TB

 

  LDEVs are uniquely identified across the subsystem by a six hexadecimal digit identifier usually written  with  a  colon  between  each  pair  of  hex  digits,  for  example  00:00:01.    This  format  is  called  the  LDKC:CU:LDEV  format,  and  thus  the  subfields  with  LDEV  names  are  called  the  LDKC  (Logical  DKC)  number, the CU (Control Unit) number, and the LDEV number (within the CU).  The maximum number of LDEVs that may be created within a Universal Storage Platform V or Universal  Storage Platform VM subsystem is 64K.  The LDKC field, the first 2 hex digits of an LDEV identifier, was  added with the introduction of the Universal Storage Platform V and Universal Storage Platform VM in  order to provide for the ability at a later date to possibly increase the number of LDEVs per subsystem  above 64K.  Note that the term “LDEV” as used with HDS enterprise subsystems (Universal Storage Platform family)  to  describe  an  internal  logical  volume,  such  as  can  be  carved  from  a  parity  group,  is  somewhat  confusingly called an “LU” or a “LUN” for HDS modular subsystems (AMS family).  What is called an LU or  LUN in HDS enterprise subsystems is called an “H‐LUN” in modular subsystems.  Sorry for the confusion.  Note that a LUN, the way that a host “sees” an LDEV, emulates a physical Fibre Channel disk drive.  As  such,  accessing  a  LUN  consists  of  reading  or  writing  disk  sectors  comprised  of  512  bytes.    Thus  the 

RESTRICTED CONFIDENTIAL 

Page 88 

smallest amount of data that a host can read or write is one whole 512‐byte sector.  The size of a LUN or  an LDEV is therefore a multiple of a 512‐byte “block” (sector).  When creating an LDEV, if you specify the size in blocks (512‐byte sectors) you will get an LDEV of that  exact size.  If you specify the size you want using any other unit, such as MB, there will be a rounding  operation  that  will  take  the  size  you  asked  for  and  will  round  up  to  the  next  higher  multiple  of  an  internal allocation unit (logical cylinders of 15 logical tracks).  Suffice it to say that if you want to make  an LDEV of an exact size, specify the size in blocks (sectors).  Note in the diagram above that LDEVs are not directly presented to hosts as a Logical Unit (LU) or LUN,  but  rather  there  is  an  intermediate  construct  called  an  HDEV  (Head  LDEV).    An  HDEV  may  either  map  directly to a single LDEV, or it may be mapped to what is called a LUSE (Logical Unit Size Expansion).  A  LUSE is a combination of from 2 to 36 LDEVS:  Figure 3. Overview of LUSE Devices.

Physical Port

Logical Port

Physical Port Host Storage Domain (HSD)

Logical Port

LU

From 2 to 36 LDEVs may be combined in a “LUSE”

LU

LDEV

VDEV

LUSE

HDEV

LDEV

VDEV

The  only  reason  that  one  should  make  a  LUSE  is  to  create  a  LUN  that  is  larger  than  the  maximum  available LDEV size.  For internal LDEVs, the size of an LDEV is limited by the amount of formatted space  in  one  parity  group,  or  about  2.99  TB,  whichever  is  smaller  (more  on  this  below  when  we  talk  about  VDEVs).  For other types of LDEV, the maximum size is 4 TB.  The maximum size of a LUSE, on the other hand, is 60 TB.  Note: The LDEVs within a LUSE are not interleaved or striped.  LBAs (Logical Block Addresses, or sector  numbers) for the LUSE start at the beginning of the first, or “head” LDEV, and then proceed to the end of  each LDEV before starting on the next one.  Thus when or writing sequentially, the performance will be  limited by the performance of a single LDEV at a time.  RESTRICTED CONFIDENTIAL 

Page 89 

Later on, we will talk about what are confusingly called “concatenated parity groups” which do not give  the  ability  to  make  larger  LDEVs,  but  which  do  interleave  the  RAID  stripes  of  an  LDEV  across  multiple  parity groups.  Figure 4. Overview of LUSE Devices.

Host

Multi-path software device driver’s LUN

HBA device driver’s LUN

HBA

HBA

Switch

Switch

Physical Port

Physical Port

Logical Port

Logical Port

LU

Physical port Host Storage Domain (HSD)

LU Logical constructs

HDEV

LDEV VDEV

LUSE

Physical disk drives

Parity group

Going  back  to  our  original  diagram  for  a  moment,  we  can  see  that  a  single  LDEV  (subsystem  internal  logical volume) may be exposed as multiple different LUNS to hosts.  The diagram above shows a single  host with two paths to an HDEV.  Granting a host access to an HDEV (LDEV or LUSE) is done be creating a Logical Unit (LU) within a Host  Storage Domain.  This mapping from a host to an HDEV is sometimes called a “path”.  A path consists of  three  parts,  the  physical  port  (such  as  port  1A),  the  logical  port,  or  Host  Storage  Domain  within  that  physical port, and then the Logical Unit Number, or LUN within that HSD.  Host Storage Domains may be  identified  by  name,  or  by  relative  number  within  the  physical  port.    Note  that  it  is  possible  to  map  a  particular LDEV as one LU number in one HSD and a different LU number in a different HSD.  From the host’s perspective, the host doesn’t see the two‐level structure of the physical port and HSD  (logical port).  When the HSD is configured, you tell the subsystem which host(s) is to be mapped to each  HSD.  (A host can only be mapped to one HSD on a given port.)  Thus the host “sees” a series of logical  units (LUs) behind the port, where each LU is identified by its LU number.  RESTRICTED CONFIDENTIAL 

Page 90 

The diagram above also illustrates how multiple paths from a host to an HDEV are implemented.  The  key is the use of multipath software in the host, such as Hitachi’s HDLM (Hitachi Dynamic Link Manager).   The multipath software is a device driver which presents a single logical device for applications to use.   But  when  I/Os  are  directed  to  that  logical  device,  the  multipath  software  device  driver  receives  those  I/O operations and re‐issues them to  one or the other of the separate LUNs presented by each HBA’s  device  driver.    The  HBA  device  driver’s  LUNs  are  hidden  from  applications,  and  are  only  used  by  the  multipath driver software.  It is only the multipath software that “knows” that the (hidden) LUNs from  the two HBAs really lead to the same HDEV inside the subsystem.  Correspondingly at the subsystem end, when a host has multipath software running, the subsystem is  not aware of that fact.  The subsystem does not “see” I/O operations coming down separate paths as  being related in any way.  For this reason, the “extended round robin” host multipathing algorithm will  produce better results for sequential I/O for active/active configurations.  Extended round robin issues a  series of I/O operations for given multi‐path LUN over one of the paths before issuing the next series of  operations over the other path.  In this way, the subsystem’s “sequential detection” algorithm which is  not  aware  of  multipathing  will  still  see  sequential  host  I/O  as  sequential  at  the  individual  subsystem  port.  Recall that we said that LDEVs are “carved” from a logical container called a VDEV.  There are four types  of VDEV: internal, external, COW, and Dynamic Provisioning (DP) VDEVs: 

Copy On Write Snapshot

V-VOL Group

Pool ID Pool ID

Pool volume

LDEV VDEV

Dynamic Provisioning X-VOL Group

Pool ID Pool ID

Internal

External Parity group Port

Port

Port

Port

LU

RESTRICTED CONFIDENTIAL 

External subsystem

Page 91 

Internal VDEV The original type was the internal VDEV, which is a logical container that maps to the formatted space  within a parity group, net of parity or mirror copies.  Since LDEVs are carved from VDEVs, the size of the  largest internal LDEV that can be created is one that entirely fills the VDEV that it is carved from.  There is a maximum size for internal VDEVs, which is about 2.999 TB.  If there is more formatted space  than this in the parity group, then as many maximum size VDEVs as will fit are first allocated, then any  remaining space is allocated to one more VDEV.  You can see this if your parity group has more than 3 TB of space in it.  In the following example, we  have a RAID‐5 7+1 parity group consisting of 750 GB drives. 

  The  effective  capacity  of  each  drive  is  not  quite  750  GB,  but  just  as  a  rough  estimation  the  total  formatted capacity of the parity group is ~0.7 TB per drive * 7 drives’ worth of formatted space = ~4.9  TB.  This is bigger than the max internal VDEV size, so you can see above that two VDEVs were created  to represent the formatted space on this parity group.  Here you can see that the parity group name is  1‐1, and the VDEV names on this parity group are “1‐1‐(1)”, and “1‐1‐(2)”.  That’s what those numbers in  parentheses  are  at  the  end  of  a  “parity  group”  name.    They  are  the  number  of  the  VDEV  within  that  parity group.  Note that the LDEVs are within the VDEV, not the parity group.  While we are at it, parity groups have names like 1‐1, 1‐2, 3‐1, and so on.  These names have physical  meaning, as they indicate the BED pair and physical drive location.  Thus the names for internal VDEVs are purely determined by the physical layout of the subsystem. 

External VDEV Each  External  VDEV  maps  to  a  LUN  on  an  external  (virtualized)  subsystem.    Thus  each  LUN  on  the  external subsystem corresponds to the equivalent of a parity group.  It is possible to create an LDEV on  an  External  VDEV  that  is  the  exact  size  in  sectors  of  the  external  LUN.    This  makes  it  handy  to  do  replication or migration.  The  names  for  external  VDEVs  look  like  either  E1‐1  or  1‐1  #.   Both  forms  of the  name  are  equivalent,  thus  E  1‐1  and  1‐1  #  both  refer  to  the  same  external  VDEV.    In  some  places  one  form  of  the  name  is  used, and in other places the other form is used.  Note that there is a separate name space for each of the four types of VDEV, so that even if you have an  internal  parity  group  called  1‐1,  you  can  create  an  external  VDEV  called  E  1‐1,  and  these  are  not  the  same.  The maximum size of an external VDEV is 4 TB.  RESTRICTED CONFIDENTIAL 

Page 92 

CoW VDEV VDEVs for Copy on Write Snapshot (CoW) are usually called “V‐VOL groups”.  Each CoW VDEV (CoW V‐VOL group) is fixed in size at 4 TB.  CoW V‐VOL groups have names that look like V1‐1 or 1‐1 V.  These two forms are equivalent, with one  form being used in some places and the other form the rest of the time.  A CoW V‐VOL group does not map to any storage.  It is purely a logical container from which CoW V‐ VOLs (CoW LDEVs) may be carved.  It is these CoW V‐VOLs each individually that are mapped to CoW  pools.    V‐VOL stands for Virtual VOLume.  This is because physical space is not provided for CoW V‐VOLs when  they  are  created.    Instead,  the  LBA  range  representing  extent  of  the  V‐VOL  is  divided  up  into  42  MB  pages,  where  the  pages  are  tracked  in  a  page  table.    A  physical  location  for  a  42  MB  page  within  the  assigned  CoW  pool  is  only  assigned  when  that  page  in  the  V‐VOL  is  written  to.    Thus  pages  that  have  never been written to have no storage assigned.  This comes in handy as CoW V‐VOLs are point‐in‐time  snapshot  ShadowImage  secondary  volumes,  and  thus  you  only  need  space  for  whatever  data  has  changed on the primary volume.  The underlying space in a CoW pool is provided by pool volumes, which are normal internal or external  LDEVs exclusively assigned for duty as pool volumes.  The space on the pool volume LDEVs is broken into  42  MB  pages,  each  starting  at  a  RAID  stripe  boundary.    Thus  one  page  consists  of  a  series of  multiple  RAID stripes.  Odd  note  on  pool  volumes  ‐  when  an  LDEV  is  assigned  as  CoW  or  Hitachi  Dynamic  Provisioning  pool  volume, the suffix " P" is shown on the name of the parity group that the pool volume LDEV is on.  For example, if a normal LDEV 00:12:34 which is on parity group "1‐1" is assigned as a CoW or Hitachi  Dynamic Provisioning pool volume, from that point on, LDEV 00:12:34 will show as being on parity group  "1‐1 P".  In this case, the "P" is really a marker to indicate special treatment as a pool volume, not that  there is a parity group whose name is "1‐1 P".  You can see this using the SVP configuration printout tool. 

Dynamic Provisioning VDEV DP VDEVs are also called “V‐VOL groups”, although their names are written in the form X1‐1 or 1‐1 X.   Dynamic provisioning is exactly like where a COW secondary V‐VOL has been mounted to a host for host  access, and where the CoW primary is all zeros.  In fact, although any one pool must be either a CoW pool or a DP pool, there is only one name space for  COW/DP pools.  The maximum number of pools within a subsystem is 128.  Dynamic Provisioning V‐VOLs are LDEVs carved from a DP V‐VOL group (DP VDEV).  These DP V‐VOLs are  usually called “DP‐VOLs” for short.  The  mechanism  is  the  same  as  for  CoW.    When  a  host  writes  to  a  42‐MB  page  on  a  DP‐VOL  that  has  never been written to before, a page is allocated from the pool, and from then on whenever the host  reads or writes from that page, the access is directed to the assigned physical page in the pool.  DP VOL groups (VDEVs) are fixed in size at 4 TB.  RESTRICTED CONFIDENTIAL 

Page 93 

When you look at the performance statistics for Dynamic Provisioning, what you see is that the DP‐VOLs  (the virtual volumes) are the ones that the hosts access, so they have front‐end I/O statistics only.  On  the other hand, pool volumes only have back‐end I/O statistics, as they are the ones that to which the  actual back‐end I/O is performed.  The maximum number of LDEVs within a Universal Storage Platform V or a Universal Storage Platform  VM is 64K.  This is also the maximum number of VDEVs in a subsystem, and therefore it is possible (and  it is now required since microcode version 06‐04‐00/00) to place each DP‐VOL by itself at the “top” of its  own V‐VOL group (DP VDEV).    In  general,  since  LDEVs  are  carved  from  VDEVs,  if  there  is  contiguous  unused  space  immediately  following the LDEV within the VDEV it is possible to expand the size of an existing LDEV into that free  space, as shown in the following diagram:   

VDEV

LDEV

LDEV LDEV

Free space

An LDEV may be grown “in place” by extending into immediately following (contiguous) free space within the VDEV

During  this  expansion,  any  existing  data  in  the  LDEV  stays  “in  place”,  and  all  that  happens  is  that  the  LDEV gets more space at the end.  Note that appropriate operating system  is required for the  host to “notice” that the volume got bigger, and adjust the partition table on volume accordingly.  Then  an  existing  partition  may  be  dynamically  expanded,  again  if  the  operating  system  and  file  system   that.  This is the reason why each DP‐VOL is required to be placed within its own VDEV (V‐VOL group).  Since  the maximum number of VDEVs is the same as the maximum number of LDEVs, by putting each DP‐VOL  by itself at the “top” of its own V‐VOL group (VDEV), the DP‐VOL can be dynamically expanded later if  necessary.  Of course now we have the anomaly of a Dynamic Provisioning VDEV being called a V‐VOL group even  though it can only contain one V‐VOL. 

Layout of internal VDEVs on the parity group Recall  that  the  VDEV  is  the  logical  container  from  which  LDEVs  are  carved,  and  that  internal  VDEVs  represent the formatted space within a parity group.  This  abstraction  of  a  VDEV  as  a  logical  container  allows  operations  that  deal  with  LDEVs  to  be  implemented largely independently of the type of VDEV, and thus LDEVs work the same way whether  they are internal, external, CoW V‐VOL, or DP‐VOL. 

RESTRICTED CONFIDENTIAL 

Page 94 

Thus it’s in the internal type of VDEV where the mapping happens to the formatted space within a parity  group.  In  the  next  two  diagrams,  we  see  the  VDEV  layout  on  first  RAID‐1  (2D+2D)  and  then  RAID‐5  (3D+1P)  parity group types. 

Thus the VDEV is mapped to “chunks” on the disk drives.  In the Universal Storage Platform family, the  chunk  size  varies  only  with  the  emulation  type,  and  not  by  the  RAID  level  or  number  of  drives  in  the  parity group.  Note that the chunks are relatively big.  About a hundred 4KB blocks fit within one chunk.    For random I/O, only the data requested by the host is read or written.  If the host reads a 4 KB block,  only 4KB is read from the drive, not an entire chunk.  The time it takes to do a random I/O is composed of over 99% mechanical positioning and less than 1%  data transfer.  This is because a block size in the 4KB to 8KB range represents on the order of only 1% of  a disk drive physical track size, and mechanical positioning (seek + latency) takes on average more than  one full disk drive rotation.  That’s why for random I/O workloads, all we care about is the disk drive seek time and RPM.  The chunk size is chosen so that the amount of time it takes to transfer a whole chunk (the size of the  chunk divided by the read/write head sustained data transfer rate) is of the same order of magnitude as  the mechanical positioning time, that is, seek and latency time.  It’s designed this way because sequential I/O operations read or write an entire chunk at a time.  With  having  such  big  chunks,  very  roughly  one  half  of  the  disk  drive  busy  time  when  reading  or  writing  sequentially is mechanical positioning and one half is data transfer.  RESTRICTED CONFIDENTIAL 

Page 95 

This makes sequential transfer relatively productive.    It also makes the I/O service time to read or write a chunk about twice as long in time as a small‐block  random I/O.  The mechanical positioning is the same for both, but for large block sequential I/O after  the mechanical positioning is complete it takes roughly one disk drive rotation worth of time to transfer  the chunk.  You might ask why not make the chunks even bigger?  If transferring a 512KB chunk represents almost ½  of  the  total  I/O  service  time,  then  why  not  make  the  chunks  1MB?    That  way  you  would  get  a  50%  throughput  increase  for  sequential  I/O,  because  then  almost  2/3  of  the  drive  busy  time  during  a  sequential I/O would be data transfer.    The reason is that if a random read miss occurs while a sequential I/O (pre‐fetch stage or write destage)  is  in  progress,  the  host  has  to  wait.    Sequential  I/O  operations  already  take  about  twice  as  long  as  random  I/Os,  and  if  we  made  the  chunks  even  bigger  the  host  would  have  to  wait  even  longer  if  a  random read miss occurs during a sequential I/O.  Thus there’s a trade‐off as a larger chunk size would  increase sequential throughput at the expense of adversely impacting random read performance.  Note also in the RAID‐1 VDEV chunk layout diagram that the primary chunks (shown colored blue) and  the mirror copy chunks (colored red) are in alternating positions from row to row. This is done because  the mirror copies are normally “write only” as a backup.  All read operations are directed to the primary  copy unless the drive containing the primary copy has failed.  Thus  the  effect  of  the  alternating  primary  and  mirror  chunks  in  the  layout  from  row  to row  in  RAID‐1  tends to balance the number of read operations directed to each drive within the parity group.  Let’s take a look at the chunk layout for a RAID‐5 (3D+1P) VDEV in the Universal Storage Platform family: 

  You might ask “Why does the 2nd row have the chunks numbered in the order 4, 5, 3?  This is confusing.”   The  reason  “why”  is  that,  in  the  Universal  Storage  Platform  family,  sequential  reads  will  read  a  chunk  from each drive in the parity group in parallel.  The layout above enables chunks 1,2,3,4 to be read at  once.    In  other  words,  sequential  reads  do  not  read  one  parity  group  stripe  at  a  time.    However,  for  RESTRICTED CONFIDENTIAL 

Page 96 

sequential writes one stripe at a time (in this case 3 data blocks and one parity block), again performing  one I/O to each drive in the parity group at once.  Note: The HDS AMS or modular family of subsystems uses a different RAID‐5 chunk layout scheme which  is more what you might have expected.  The analogous diagram for 3+1 for a modular subsystem has in  row 2 from left to right chunks 3, 4, parity 3‐5, and chunk 5.  We said that the abstraction of a VDEV as a logical container allows operations that deal with LDEVs to  be implemented largely independently of the type of VDEV.  One small dependency on the type of VDEV  is  that  LDEVs  always  start  on  a  RAID  stripe  boundary.    That  is,  the  first  chunk  of  an  internal  LDEV  is  always the first data chunk of a RAID stripe, or parity group “row”.  This is done to make it easy to calculate the physical location of where a particular LBA is stored.  Each  LDEV has an attribute which is the LBA address of where that LDEV starts on every drive in the parity  group.  Thus you can divide an LDEV LBA by the RAID stripe size (data‐only stripe size, exclusive of parity  or mirror copies), and the quotient gives you the relative stripe offset in chunks on the drive, relative to  where the LDEV starts on each drive, and the remainder tells you where you are within the stripe and  therefore  which  drive  contains  that  LDEV  LBA.    (The  number  of  the  stripe  on  the  drive  also  tells  you  which chunks on that stripe are the data chunks and which are the mirror copy / parity chunk(s).) 

RESTRICTED CONFIDENTIAL 

Page 97 

Appendix 16. Concatenated Parity Groups   The Universal Storage Platform V family has exactly the following 4 base Parity Group types:   RAID‐1 (2D+2D)   RAID‐5 (3D+1P)   RAID‐5 (7D+1P)   RAID‐6 (6D+2P)  Note that there is no “4+4” as a base Parity Group type.  The following conceptual diagram, showing two Parity Groups that are not concatenated, will be used as  the starting point to explain two‐way concatenation: 

Concatenated Parity Groups are derived from the base Parity Group types by interleaving their VDEVs.   The following diagram shows a two‐way concatenation or interleaves: 

RESTRICTED CONFIDENTIAL 

Page 98 

Two-way parity group concatenation (VDEV interleave) NOTE: Concatenation does not create one big VDEV for both parity groups. Each VDEV has its first stripe on the parity group that it is named after. Thereafter, RAID stripes for a given VDEV alternate between the parity groups in the concatenated set.

VDEV 1-1-(1)

...

...

VDEV 3-1-(1)

...

...

Parity group 1-1

...

...

Parity group 3-1

There are two types of two‐way interleaved Parity Groups.  

The two‐way interleave of RAID‐1 (2D+2D) is what we usually call ‘4+4’.  o



Note that there is a VDEV for each Parity Group that is the same size as the VDEV would  have been without concatenation. Thus the biggest LDEV you can make on a 4+4 is the  same size as the biggest LDEV you can make on a 2+2. 

The two‐way interleave of RAID‐5 (7D+1P) doesn’t have a shorthand name, but if you write  2x(7+1) this is clear.  Sometimes people write “14+2” – if they are writing about the Universal  Storage Platform V family you know that a 14+2 could only be 2x(7+1). 

RESTRICTED CONFIDENTIAL 

Page 99 

There is one type of four‐way interleaved Parity Group.  

The four way interleave of RAID‐5 7+1 may be clearly written as 4x(7+1).  If you see someone  write 28+4, this is what they must be talking about. 

Yes, the name is confusing.  You will sometimes see the  “VDEV disperse” or “VDEV interleave”.  These are equivalent to the  official name “concatenated Parity Groups”.  Sometimes people will talk about LDEV striping, and here it  is possible that they are talking about concatenated Parity Groups, because the LDEVs that are carved  from a VDEV that is part of a concatenated Parity Group set are indeed striped across the Parity Groups  that have been concatenated together.  The term “concatenated” is unfortunate, as many native English speakers would assume that this refers  to something more like a LUSE.  A colloquial English expression often used to describe LUSE is “spill and  fill”,  because  in  a  LUSE,  reading  or  writing  sequentially  through  the  LUSE,  one  proceeds  through  each  constituent  LDEV  in  its  entirety  before  moving  to  the  next.    Thus  LUSE  does  not  improve  sequential  throughput. 

Advantages of concatenated Parity Groups  Individual LDEVs are striped across the set of concatenated Parity Groups.  This means that  sequential performance is increased, as a when staging or destaging sequential data, an I/O to  read or write a chunk may be issued to all the drives in the concatenated Parity Group set at the  same time.  

Random I/O operations are effectively dispersed across the set of concatenated Parity Groups.   If small‐block random I/O operations are clustered to within up to a hundred blocks or so, they  will likely go to the single disk drive that contains the chunk (512 KB for Open‐V) that contains  those small blocks.  This is true for any Parity Group type.  However, the advantage of  concatenated Parity Groups is that if random I/O is clustered within tens or hundreds of MB,  these I/Os will be dispersed across the whole set of concatenated Parity Groups.  In the case of a  LUSE volume, random I/O clustered within 10s or 100s of megabytes will likely be concentrated  on a single LDEV that is on a single Parity Group. 

RESTRICTED CONFIDENTIAL 

Page 100 



Concatenated Parity Groups reduce to some degree individual Parity Group “hot spots”.  The  total activity across all the LDEVs on a set of concatenated Parity Groups is distributed more or  less evenly across that set of Parity Groups.  Thus this “averages out” Parity Group utilization  across the concatenated set, and thus reduces average Parity Group busy.  Reduced “Parity  Group busy” yields better overall average response and offers the opportunity to increase  overall throughput.  Note that Dynamic Provisioning offers the benefits of I/O activity dispersal across much  larger numbers of Parity Groups. 

Disadvantages of concatenated Parity Groups:  Since I/O activity is dispersed over a concatenated set of Parity Groups, all LDEVs carved from  VDEVs in the set are sharing the same performance characteristics.  Thus there is less  “performance isolation”.  Normally dispersing activity is a good thing, but it should be pointed  out that any of the LDEVs in the combined set have access to the full bandwidth of the disk  drives in the set, and thus high‐activity LDEVs will make the entire concatenated set of drives  busy, and thus reduce the performance of the other LDEVs sharing those drives.  

Should a disk drive fail, performance could be affected for a larger set of LDEVs. 



Most people expect that when you “concatenate” Parity Groups together, you will be able to  make bigger LDEVs.  As we saw, concatenation does not alter the number or size of the VDEVs  that would otherwise be assigned to the same Parity Groups if they were not concatenated  together.  To fix this problem, if you want the performance characteristics of LDEVs that are  striped across a concatenated set of Parity Groups, but you also want a LUN that is as big as the  combined formatted size of the Parity Groups in the set, then carve a single maximum‐size LDEV  out of each VDEV belonging to a set of concatenated Parity Groups, and LUSE these LDEVs  together to make one LUN. 

Using LDEVs on concatenated Parity Groups as Dynamic Provisioning pool volumes Recall that DP‐VOLs are divided up into 42 MB pages, and that each individual page when it has been  written to is assigned a location in the pool.  42 MB is “fairly big”, in the sense that the biggest RAID stripe is an Open‐V RAID‐5 (7D+1P) stripe which  has 7 data blocks of 512 KB each for a total of 3.5 MB of data.  What we thus see is that each 42 MB DP/CoW page is comprised at the Parity Group level of a series of  RAID stripes.  Each page starts on a RAID stripe boundary.  The 42 MB size of a page was picked so as not  to waste any space in any of the base Parity Group types.  One 42 MB page is comprised of:  

42 stripes of a 2+2, where the stripe size is 2 x 512 KB = 1 MB. 



28 stripes of a 3+1, where the stripe size is 3 x 512 KB = 1.5 MB. 



12 stripes of a 7+1, where the stripe size is 7 x 512 MB = 3.5 MB. 



14 stripes of a 6+2, where the stripe size is 6 x 512 MB = 3 MB. 

We  have  not  specifically  tested  the  performance  of  LDEVs  on  concatenated  Parity  Groups  used  as  DP/CoW  pool  volumes.    However,  there  is  a  theoretical  argument  that  says  this  might  improve  RESTRICTED CONFIDENTIAL 

Page 101 

sequential  performance.    Since  sequential  performance  is  higher  for  normal  LDEVs  on  concatenated  Parity Groups due to the characteristic of reading / writing a chunk to all the drives in the concatenated  set at once, (reading / writing one “round” of interleaved RAID stripes at ones) it would be worth trying  to  see  if  this  also  applies  to  sequential  processing  of  DP/CoW  pages.    This  may  or  may  not  provide  a  benefit  in  the  context  of  DP/CoW  sequential  processing.  This  document  may  be  revised  in  future  to  clarify this point, but for the time being this remains an open question. 

Summary of the characteristics of concatenated Parity Groups (VDEV interleave):  The size of the VDEVs is exactly the same as the size of VDEVs on similar Parity Group types that  are not interleaved.  

No change to the maximum size of an LDEV. 



It is not possible to allocate a single LDEV that consumes all the space in all the Parity Groups  being concatenated (interleaved) together.  Instead, create a maximum‐size LDEV on each VDEV  associated with the set of concatenated Parity Groups and LUSE these LDEVs together. 



The I/O activity of each LDEV carved out of a concatenated Parity Group VDEV maps to the  underlying RAID stripes comprising the VDEV, which means that the I/O activity spreads across  all the drives in the concatenation set. 



Sequential I/O throughput is improved because you can read or write one chunk to each of the  drives in the concatenated set in parallel. 



Random I/O operations benefit from having an LDEV’s I/O operations distributed across a larger  number of disk drives. 



RAID group performance isolation happens at the level of the concatenated set, as all the LDEVS  in all the VDEVs in the concatenation set share the same drives. 



In addition to the base Parity Group types 2+2, 3+1, 7+1, and 6+2, concatenated Parity Groups  yield the types 2x(2+2), which is commonly called 4+4, as well as 2x(7+1) and 4x(7+1). 

     

 

RESTRICTED CONFIDENTIAL 

Page 102 

 

Corporate Headquarters 750 Central Expressway, Santa Clara, California 95050-2627 USA Information: + 1 408 970 1000 www.hds.com / [email protected] Hitachi is a ed trademark of Hitachi, Ltd., and/or its s in the United States and other countries. Hitachi Data Systems is a ed trademark and service mark of Hitachi, Ltd. In the United States and other countries. Microsoft is a ed trademark of Microsoft Corporation. Hitachi Data Systems has achieved Microsoft Competency in Advanced Infrastructure Solutions. All other trademarks, service marks, and company names are properties of their respective owners. Notice: This document is for informational purposes only, and does not set forth any warranty, express or limited, concerning any equipment or service offered or to be offered by Hitachi Data Systems. This document describes some capabilities that are conditioned on a maintenance contract with Hitachi Data Systems being in effect, and that may be configuration-dependent, and features that may not be currently available. your local Hitachi Data Systems sales office for information on feature and product availability. Hitachi Data Systems sells and licenses its products subject to certain and conditions, including limited warranties. To see a copy of these and conditions prior to purchase or license, please go to http://www.hds.com/corporate/legal/index.html or call your local sales representatives to obtain a printed copy. If you purchase or license the product, you are deemed to have accepted the and conditions. © Hitachi Data Systems Corporation 2009. All Rights Reserved WHP-###-## September 2009

RESTRICTED CONFIDENTIAL 

Page 103