ORIGINALLY POSTED 10th Novembeer 2008

22,769 views on developereworks

I thought it was time to get back to some technical content, and with recent blog posts, it clear that there is some confusion over how SVC works. In particular how the actual virtual to physical blocks are mapped, how they can be changed without application disruption, and how you get data into (and if you wanted) out of SVC.

Part 1 : Basic Terminology

I forget that a lot of my readers aren’t as close to SVC as I am and so here are some basic terms that we use and what they mean – these will be used extensively in this series.

Term	Abbreviation	Definition
Managed Disk	mdisk	These are the LUNs that are presented to SVC by a storage controller. Normally these would be what are presented to a host system. In IBM terms, this would be a LUN created on a RAID array. Generally we recommend only one LUN per RAID array, so for each RAID-1, 5, 6, 10 array you create at the controller, you will see one mdisk that corresponds to this. SVC will show each mdisk as belonging to a single controller device (normally).
Managed Disk Group (or Storage Pool 2010 onwards)	mdiskgrp or mdg	This is a pool, or tier of storage devices. A group of mdisks to be precise. This logical entity contains some number of mdisks. The rules are that you add mdisks with the same characteristics to a group. So the same performance characteristics (drive speed, drive type, RAID type etc) and the same redundancy/protection level (RAID type etc).
Extent	n/a	Each mdisk is logically divided into extents. These are the building blocks for SVC. Each Virtual Disk is created as a concatenation of extents from one or more mdisks. The extent size is a property of the mdiskgrp. So all mdisks in a group will use the same extent size. SVC currently support extent sizes ranging from 16MB to 2GB (in powers of 2). The chosen extent size affects the total addressable cluster capacity as there are fixed number of extents supported in a single cluster. 4 Million.
Virtual Disk (or Volume – 2010 onwards)	vdisk	A vdisk is a LUN that is presented to a host system as a unit of usable storage capacity. This is a logical entity, which has a contiguous Logical Block Address (LBA) range, starting from LBA 0 through to LBA X. However, as this is made of up some number of extents, the actual physical mdisk LBAs will be contiguous only within an extent. A vdisk can therefore be provisioned from one or more mdisk in a single mdiskgrp.
Virtualization Mapping Table	n/a	The mapping table contains the details of all the extents in the cluster. It provides the lookup between a vdisk LBA and an mdisk LBA. So LBA W on vdisk X will correspond with LBA Y on mdisk Z.
Node, I/O Group, Cluster	n/a	A node is a single SVC engine. Nodes are deployed in pairs, known as an I/O Group. The write cache data is mirrored between the nodes in an I/O group. The node is itself is the failure domain, think of it as a single controller in a dual controller pair. vdisks are associated with an I/O group, and all I/O send to the vdisk is serviced by either node in the I/O group. Up to 8 nodes, so 4 I/O groups can be added to a single SVC cluster. The cluster is the management entity, the domain name space, and the single point of provisioning.

ADDED COMMENTARY 2019 – Its worth noting that since I wrote this in 2008 we introduced Storwize and FlashSystem. We maintained the node, I/O group and cluster concepts. So a single Storwize control enclosure contains two nodes (canisters) and makes a single I/O group. It is also a cluster, since the nodes are auto clustered when you initialise the system.

In part 2 I’ll be looking at how you import existing data into SVC.