IBM System Storage RedBooks

In a recent  posting , we introduced  the upcoming  support  for  VMware Virtual Volumes  (VVOL) with the  IBM XIV Storage System. With the announcement of vSphere 6.0, VMware also officially released support for the vSphere Virtual Volumes (VVOL) architecture

Since March 12 , 2015 , the VVOL and XIV  integration is effectively supported through   IBM Spectrum  Control Base, and based on the VMware API for Storage Awareness (VASA). IBM Spectrum Control Base  is  a follow on  to  the IBM Storage Integration Server. 

IBM Spectrum Control  Base  is a member  of the recently announced  IBM Spectrum Storage family.

You can  see a  practical illustration  and a step  by  step  description  of the VVOL integration  in this  new  IBM Redbooks  publication:

 IBM Spectrum Control Enabling VMware Virtual Volumes with IBM XIV Storage System, REDP-5183.

In this publication, we review the VVOL  concept and  explain the architecture of the solution . implemented  by  IBM Spectrum Control  :

The IBM® XIV® Storage System Gen3 software version 11.5.0 was announced on  July 15th  and will be available on  August 21st, 2014.   This new version brings a myriad of new features that make XIV the storage of choice for Cloud environments.   

Amongst those new features is the support for multi-tenants.

XIV multi-tenancy is based upon the concept of domains, where an XIV Storage System is logically partitioned into one or more independent “containers,” each with its own assigned domain administrator(s). This approach allows for the secure isolation of the logical entities contained within a domain from other domains. A user associated to a single domain has no knowledge of the others domains existing on the system, nor the pools or volumes associated with those domains.

It is important to understand that the implementation of this domain construct within the XIV Storage System occurs at the management level. All physical system resources (disks, CPUs, memory and interfaces) are shared among domains. As such, domain administrators do not have the ability to modify physical system resources.

Domains are created  by a global storage administrator. A global storage administrator is a user with the role of Storage Administrator who is not associated with any domains. By default, the built-in admin user account is a global storage administrator.

Here is a sample illustration of how domains and domain resources can  be created and visualized in  the XIV GUI.

For more information , refer to  the  IBM RedBooks publication (draft) : XIV Storage System Architecture and Implementation, SG24-7659

Can you use SVC with XIV as storage ?

YES, you can !

----- updated with 6TB drives in LUN size table - 20160111 ----

XIV and SVC can be a great combination, we have many customers using this combo.

Why ? flexibility and support for operating systems the XIV does not  support.

• But don't you have to pay twice for licenses  if you want to do mirror data ? NO, its a special XIV license for the SVC which includes all the features that comes with the XIV, but for the SVC instead, neat isn't it ?

Very often I get questions on how to configure the XIV when it is part of a solution using SVC.  The questions typically are,  *How many ports should I use in the XIV?',‘What LUN sizes should we use on the XIV ?’, ‘How many LUNs should we have?’

So here we go, check the tables out below. It's,  in most cases, all you need.

How many ports from the XIV should be used in SVC ‘one big zone’ per fabric ?

Table 1, shows the number  of ports you need to include in the ‘one big zone’ zoning.

Table 1 XIV host ports as capacity grows with different drive capacity

How many LUNs and which size of the LUNs should be configured on the XIV ?

Table 2, has the answer to, depending of the drive size you have in your XIV.

Table 2 XIV volume size and quantity recommendation

‘But what about the qdepths ?’

‘Should I not tune the qdepths, somehow?’

No you should not !

In SVC with XIV solutions you can't tune qdepths, qdepths are tuned by itself when you choose the right amount of LUNs and LUN sizes.

And here is the detailed explanation why, stolen from the IBM Redpaper  just updated  during a residency at the ESCC in IBM Mainz, Germany,  REDP-5063

Queue depth considerations

Ideally, the number of MDisks presented by the XIV to the SVC or Storwize V7000 should be a multiple of the number of XIV host ports, from one to four. Math exists to support this.

Since version 6.3 SVC or Storwize V7000 uses round-robin for each mdisk, so it is not necessary anymore to do a manual load balancing. But it is still necessary to have several mdisks because of the following queue depth limitation of SVC and Storwize V7000.

The XIV can handle a queue depth of 1400 per Fibre Channel host port and a queue depth of 256 per mapped volume per host port:target port:volume tuple. However, the SVC or Storwize V7000 sets the following internal limits:

-    The maximum queue depth per MDisk is 60.

-    The maximum queue depth per target host port on an XIV is 1000.

Based on this knowledge, you can determine an ideal number of XIV volumes to map to the SVC or Storwize V7000 for use as MDisks by using the following algorithm:

Q = ((P x C) / N) / M

The algorithm has the following components:

Q         The calculated queue depth for each MDisk

P         The number of XIV host ports (unique WWPNs) visible to the SVC or Storwize V7000 cluster (should be 4, 8, 10, or 12 depending on the number of modules in the XIV)

N         The number of nodes in the SVC or Storwize V7000 cluster (2, 4, 6, or 8)

M         The number of volumes presented by the XIV to the SVC or Storwize V7000 cluster (detected as MDisks)

C         1000 (this is the maximum SCSI queue depth that an SVC or Storwize V7000 will use for each XIV host port)

If a 2-node SVC or Storwize V7000 cluster is being used with 4 ports on IBM XIV System and 17 MDisks, this yields a queue depth as follows:

Q = ((4 ports*1000)/2 nodes)/17 MDisks = 117.6

Because 117.6 is greater than 60, the SVC or Storwize V7000 uses a queue depth of 60 per MDisk.

If a 4-node SVC or Storwize V7000 cluster is being used with 12 host ports on the IBM XIV System and 50 MDisks, this yields a queue depth as follows:

Q = ((12 ports*1000)/4 nodes)/50 MDisks = 60

Because 60 is the maximum queue depth, the SVC or Storwize V7000 uses a queue depth of 60 per MDisk. A 4-node SVC or Storwize V7000 is a good reference configuration for all other node configurations.

Starting with version 6.4 SVC or Storwize V7000 clusters support MDisks from XIV greater than 2 TB. When using earlier versions of SVC code smaller volume sizes for 2 TB, 3TB, and 4 TB drives are neccessary. The following table is valid for SVC version 6.4 or later.

Tip: If you only provision part of the usable space of the XIV to be allocated to the SVC or Storwize V7000, the calculations no longer work. You should instead size your MDisks to ensure that at least two (and up to four) MDisks are created for each host port on the XIV.

Don’t hurt our feelings read the Redpaper !!   

Happy configuring from the Viking part of the world -- Roger Eriksson

This entry could not have been done without the contributions of  Markus Oscheka , Stephen Solewin and Brian Sherman

We recently  published the IBM® Redguide™ Taming the Data Beast with Tarmin GridBank and the IBM XIV Storage System to coincide with the IBM XIV® Storage System  announcement on October 8.  One of the key concepts (aha moment)  for me while working on this Redguide was the opportunity to scale the data and the management of the data using the grid-based products together. 

This  Redguide publication explains how the Tarmin™ GridBank Data Management Platform™ transforms the way organizations manage, scale, search, and gain value from unstructured data by uniting application, information, and storage tiers into a single, integrated data centric management architecture. There is also a focus on how well IBM XIV® storage systems (infrastructure designed for Big Data Analytics and cloud ready) fit into the GridBank architecture for solving current storage management challenges. Together Tarmin GridBank and IBM XIV can tame the data beast.

Tarmin, Inc. is a global pioneer of Data Defined Storage, a next generation data management platform focused on data accessibility and the value of information as a strategic business enabler. The Tarmin solutions presented in this Redguide address the following storage challenges:

• Data Growth:      Exponential unstructured data growth driving up cost and management overhead
• Data Silos:          Limited access to data between business units, locations and hardware
• Data Risk:           Increasingly stringent regulatory and legal compliance mandates
• Data Protection: Multiple solutions required for disaster prevention, retention and immutability
• Data Discovery: Restricted search capability across massively complex data repositories
• Data Value:         Storage is seen as a cost center versus a strategic business enabler

Figure 1 shows the architecture using  cloud GridBank sites with XIV storage pools and IBM InfoSphere BigInsights. 

Figure 1 GridBank with XIV configuration

Figure 2 illustrates Oil and Gas Exploration and Production configuration use case. The Redguide also shows examples of Financial Services and Education use cases.  I am sure these examples will generate many more ideas and examples of using grid-based solutions to solve current storage challenges.

Figure 2  Example of Oil and Gas Exploration and Production configuration

On June 10th,  we announced   IBM Hyper-Scale.

IBM® Hyper-Scale introduces two major new technologies, both implemented in the IBM XIV® Storage System (Gen3 models):

• The first is IBM Hyper-Scale Manager, a flexible, consolidated multi-system management application that was originally released in October 2012 as “Multi-System Manager”. IBM Hyper-Scale Manager is based on and seamlessly integrated with the XIV GUI and spans multiple XIV systems.
•  
• The second new technology, IBM Hyper-Scale Mobility,  is a powerful function for moving volumes between XIV Gen3 systems  transparently, with no disruption to host applications.

IBM Hyper-Scale helps you easily overcome provisioning scenarios that normally challenge traditional systems. IBM Hyper-Scale can accommodate several critical customer scenarios for data mobility, load balancing, over-provisioning, and storage system repurposing.

The process of migrating volumes consist of just a few steps or stages:

Stage 1: Setup  Create the volume on the destination XIV system and set up the relationships between the two volumes needed for migration.

Stage 2: Migration in progress Data migration can begin; New data is written by the host to the source and migrated (copied) to the destination.  The source volume state goes from initializing to synchronized if the migration is successful. This is known as the Proxy_ready phase.

Stage 3: Proxying  At this point, the administrator can instruct the source storage system to redirect host I/O to the new volume on the destination XIV.  This stage corresponds to the Proxy phase.

In proxy mode, the source (now the proxy) no longer functions as a regular volume, and the source storage system communicates host requests to the destination. In proxy mode, the host can remain connected to the source; the host can be moved after the migrated volume data is on the destination.

Stage 4: Cleanup The final stage of the migration involves connecting the host directly to the new volume. This stage might require zoning changes, and the multi-path device driver must discover the new path to the migrated volume.  Finally, the original paths can be removed and the IBM Hyper-Scale Mobility relationship can be deleted.

For details and step by step illustrations, refer to the  IBM Redpaper 'IBM Hyper-Scale Mobility Overview and Usage", REDP-5007

Thin Provisioning provides a volume size as specified but uses physical storage only when needed. While this sounds like a great way to efficiently use the available storage space, in real life situations this may not always be true. When files are deleted or moved the now unused data is usually still residing on the physical storage. The host system may indicate that the used capacity is now smaller but the physical storage is still in use and remains allocated to that host system.

Space reclamation deals with this situation by providing a way for the host system to indicate that the physical storage assigned to it is no longer in use. space reclamation in operating systems are typically achieved by invoking the Small Computer System Interface (SCSI) WRITE SAME or the SCSI UNMAP command. Which commands are used depends on the operating system involved.

Considerations for using Thin Provisioning with Microsoft Windows 2012 are summarized in the Plan and Deploy Thin Provisioning article published by Microsoft

On February 5,  IBM announced new features and improved performance for the XIV Storage System Gen 3. 
Here is a summary  of the announcement:
 
IBM® XIV® Storage Systems, a powerful, innovative enterprise-class storage from IBM , includes the following features for new model 214:

• Up to 5 times performance increase in iSCSI throughput with new 10Gb Ethernet (GbE) ports
• Up to 4.5 times performance boost for random database-like workloads with SSD read-caching (optional)
• Sequential read performance as high as 13.7 GB/s
• Support for Windows™ Server 2012, including space reclamation
• Drive rebuild times as fast as 26 minutes for a fully utilized 2 TB hard disk drive under heavy load