Hitachi Virtual Storage Platform
Installation, Configuration, and
Maintenance
Back-End Architecture
October 2010
Copyright © 2010 Hitachi Data Systems. All rights reserved.
Module Objectives
Upon completion of this module, the learner should be able to:
– Identify the different areas in which Hitachi Data Systems implements virtualization in the enterprise storage
architecture
– Describe back-end storage virtualization, using the correct terms and progression from physical storage at the RAID
group level to the definition of a Logical Device (LDEV)
– Describe the back-end physical architecture of the Virtual Storage Platform (VSP)
– Define and correctly use the terms:
• RAID Group
• Parity Group
• Array Group
• Error Checking and Correction (ECC) Group
• Emulation
• Physical Device (PDEV)
• Virtual Device (VDEV)
• LDEV
• Logical Disk Controller (LDKC)
• Control Unit (CU)
• Hard Disk Unit (HDU)
• A group of four HDU boxes that are used to contain 128 HDDs (B4)
– Describe how eight-drive Parity Groups are constructed in a VSP system
– Describe the SAS back-end architecture and components
2
Storage Virtualization in the Virtual Storage Platform
Logical Unit Numbers
Internal or back- end
Host/server storage
(LDEV addressing)
Virtualization
Virtualization
storage
(LUNs)
Front end Back end
Internal
Thin provisioning
Hitachi Dynamic Provisioning
DP Pool
CHA Port
Host Group Virtualization of External Storage LDKC
(Hitachi Universal Volume Manager)
LUN Address Control Unit
Storage System Serial Number LDEV address
Port LUN
External
3
RAID Groups and PDEVs
• RAID Group Supported RAID configurations
• Parity Group • RAID 1+0 (2D, 2D)
• Array Group (4D, 4D) HDD-1
• ECC Group • RAID 5 (3D, 1P) PDEV
(7D, 1P) also x2 or x4
PDEV
• RAID 6 (6D, 2P) HDD-2
PDEV
HDD-3
HDD-1
Supported HDD Types PDEV
HDD-4
• SAS PDEV
HDD-2 • Flash drives
PDEV refers to the total or
• SATA raw capacity of one HDD. It
can also be used to describe
HDD-3 the total raw capacity of the
entire HDDs in a RAID group
HDD-4 Emulation
Mainframe or Open Systems
A set of HDDs
configured to work
together 3390-3 OPEN-V
4
3390-9
VSP Supports 4-drive and 8-drive RAID Group Structures
Virtual Storage Platform 4-drive and 8-drive RAID Groups
Hitachi has already determined which sets
of HDDs may work together to form
RAID groups. There is no flexibility in the
choice of which HDDs form RAID groups.
Two 4-drive
RAID groups
may be combined
to form an
8-drive group.
4-drive RAID groups For example:
may be either: • RAID 1+0 (4D, 4D)
• RAID 1+0 (2D, 2D)
• RAID 5 (7D, 1P)
• RAID 5 (3D, 1P)
• RAID 6 (6D, 2P)
Four HDDs are always in the same
B4. Eight HDDs are always in two paired
Always within the same DKU. B4s.
Always within the same DKU.
5
Emulation Attribute of a RAID Group
Emulation determines two LDEV attributes:
– Maximum LDEV size
– How the data is stored and accessed
on the LDEV
3390-9
8.514GB
Emulation is a hardware installation attribute. metadata
– Emulation must be set at the time when the
disk drives of the RAID group are installed
in the system by the maintenance engineer.
OPEN-9 (*)
OPEN-V emulation delivers the maximum 7.384GB
storage utilization and the best performance.
LDEV metadata
Not used for
OPEN-V
OPEN-V
48MB to entire VDEV
6 or max 4TB
VDEV Describes the Usable Capacity of the PDEV
RAID 5
VDEV
PDEV
PDEV
PDEV
PDEV
PDEV
PDEV refers to the total or VDEV refers to the usable data
raw capacity of all the capacity of a RAID group or PDEV.
HDDs in a RAID group.
VDEV capacity depends on the
HDD capacity, the RAID structure,
and the emulation.
7
What Is an LDEV and Why Is It Important?
At the LDEV level:
The maintenance
– Operate all the
engineer may be PDEV
microcode enabled
responsible to
Program Products
define the LDEV
VDEV – Perform provisioning
structure of newly
installed RAID – Perform Replication
groups. – Perform Volume
Migration
– Set Data Retention
Storage must be – Define virtualization of
formatted at the external storage
LDEV level before it LDEV
– Build Dynamic
can be used by [Link] Provisioning and
programs or hosts.
Dynamic Tiering Pools
8
VDEV Capacity – LDEVs, Free Space, or a Combination
OPEN-V
VDEV 48MB to entire VDEV
OPEN-V
Either 48MB to entire max 4TB
LDEVs VDEV max 4TB OPEN-V
or
48MB to entire VDEV
free space
or both max 4TB
Free space
9
Control Unit Tables Are Control Information
Control information in the Cache Memory
shared memory area of cache
1. Configuration
2. Cache pointers
3. Control Unit (CU) tables
4. I/O instruction queues
5. Copy product delta bitmap tables
6. Virtual volume Dynamic Mapping
tables (DMT)
7. Parity data
Dual In-line Memory Modules (DIMMs)
on the CPC-0 and CPC-1, only
Customer data area of cache
10
Control Unit Tables in the Control Information Area
On a VSP at GA (v01), it is possible: LDEV ID assignment is required for
– To identify up to 64k LDEVS (65,280) each internal and external (virtual)
– LDKC 00 LDEV and for each Virtual Volume
– CU 00 – FE (255) of Copy on Write Snapshot or
– Each CU maps 256 LDEVs Hitachi Dynamic Provisioning (HDP).
– 255 x 256 = 65,280
Control Unit (CU) tables
LDKC 00
Other
LDEV [Link]
CU 00 CU FE control
xxxxxxxxx xxxxxxxxx
xxxxxxxxx xxxxxxxxx
information
CU FF
Reserved for system use
Not available for LDEVs
11
Parity Group > PDEV > VDEV > LDEV or Free Space
VSP Back-end Architecture Review
• Parity Group
• RAID Group
• Array Group
• ECC Group
PDEV VDEV LDEV
LDKC:CU:LDEV
[Link]
through
[Link]
(1-1)-1
PG(1-1)
12
Parity Group Identifier
In order to know which HDDs are part of the Parity Group, you must also
determine the RAID structure, particularly whether it is a 4-drive or an 8-drive
group.
When you determine the Parity Group identifier and the number of HDDs in
the Parity Group, you can go to the storage system and physically locate all
the HDDs that make up the Parity Group. (The Location Section of the
Maintenance Manual provides the documentation.)
13
VSP Physical Layout Matrixes
14
Virtual Storage Platform — DKC and DKU Layout
15
VSP DKU and HDU Numbering — Front View
VSP
16
VSP DKU and HDU Numbering — Rear View
VSP
17
B4 Layout — Front View
VSP
18
B4 Layout — Rear View
VSP
19
DKU Components and Layout — LFF and SFF
20
HDD and PG Layout when the DKU Holds 3.5 Inch HDDs
B4(2)
or other
B4 (even number)
B4(1)
or other
B4 (odd number)
Spare HDDs
in slots 09 PG 1-1
PG 2-1
21
HDD and PG Layout when the DKU Holds 2.5 Inch HDDs
B4(2)
or other
B4
(even number)
B4(1)
or other
B4 (odd number)
Spare HDDs
in slots 0F
PG 1-1 PG 2-1
22
Back-End Cabling Pattern — Front Rack View
VSP Back-end
23
DKA Basic and Option 1
Standard Model
High-Performance Model
24
DKA Cables Connect to SSWs in First DKU
Standard Model — DKA Option Basic, only
25
DKA to Back-End Cabling — High Performance Model
26
Back-End Comparison of HDS Enterprise Storage Systems
VSP USP V USP VM
3.5” 2.5”
Maximum number of B4s 32 18 4
HDDs per B4 40 64 64 60
Maximum number of 4-drive PG 288 480 270 68
Maximum back-end data loops 16 SAS 64 FC 8 FC
per controller
Maximum HDDs including spares 1280 2048 1152 240
Maximum HDDs per data loop 160 256 48 or 32 60
Diskless configuration supported Yes No Yes
27
Summary
In this module you have learned:
– The meaning of the terms and acronyms that are used to describe the back-end
components and architecture of the VSP storage system
– To correctly describe and use the terms: RAID group, Parity Group, PDEV, VDEV,
and LDEV
– To correctly describe and use the terms: DKU, HDU, HDD, SSW, and B4
– To use the Location Section of the Maintenance Manual to locate specific DKUs,
HDUs, SSWs, and HDDs in a VSP system
– To correctly identify the HDDs that make up any 4-drive or 8-drive Parity Group
– To describe how the controller is connected to the back-end disks in a VSP
– To describe the difference between the Standard Model DKA configuration and the
High Performance Model configuration
28
