Browse Prior Art Database

Method to enable platform independent LUN consolidation using IBM SAN Volume Controller to tackle the problem of limit of maximum numbers of LUNs seen at host

IP.com Disclosure Number: IPCOM000205852D
Publication Date: 2011-Apr-06
Document File: 3 page(s) / 137K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to enable platform independent LUN consolidation using SAN Volume Controller to tackle the problem of limit of maximum numbers of LUNs seen at host

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 48% of the total text.

Page 01 of 3

Method to enable platform independent LUN consolidation using IBM SAN Volume Controller to tackle the problem of limit of maximum numbers of LUNs seen at host

Problem

In large enterprise data center environments, administrators often run into a problem where they hit the maximum limit to the number of LUNs that can be seen by a host. This problem is exacerbated because in a shared storage environment there are multiple paths to the same LUN that causes the LUN limit to be hit faster. Once the limit is hit it becomes impossible to add more Storage in the form of new LUN's.

This can prove be a hurdle for the system administrator to overcome. Host based volume managers cannot solve this problem because they are dependent on the host's ability to see

physical LUN's before they can add more virtual storage for use by applications. It is also not

possible to solve this problem at the disk array level where there is no control over what the host

sees.

The table below gives a sample the maximum LUN limit on some major operating systems:

Operating System Maximum number of LUNs

AIX 6.1 1200 LUNs (with maximum 32

p

aths)

Solaris 32 LUNs per SCSI target Windows 2000/Windows 2003 SP1 255 LUNs per target id Linux 128 or 256
HP-UX 11i v3 16384

Existing Solutions

Various means can be used to solve this problem. Example:

1) Add an alternate host loaded with the same OS (as the original one) such that applications that require more LUNs can be run on the alternate host. However, this implies significant capex to purchase another host and it may not be possible to host the same application on a separate host.

2) All storage can be migrated to an alternate host that is capable of seeing more LUN's than the limit that is being hit. This too is fraught with difficulties because there must be a version of the OS that supports more LUN's. Migrating to an different OS altogether maybe difficult or impossible.

3) Upgrade the OS on the host with a patch that allows more LUN's to be added to it than the maximum limit. This may not be immediately possible where such a patch is unavailable.
4) Grow the size of the existing LUN's seen by the host in order to add more storage capacity. That too may not be good enough a solution because some applications may require new & dedicated LUN's.

1


Page 02 of 3

5) Add additional HBA's to the host might work in some cases. However this means additional HBA slots should be available on the host. In addition, this will require downtime while the HBA is added.

The idea used in this invention is to consolidate multiple independent physical LUNs onto a single large physical LUN and adding an OS dependent partition table to this large LUN such that each original LUN appears like a partition to the host. This allows the system administrator to reduce (consolidate) the no. LUNs attached to the host such that more LUNs can be added to the same host. This invention is implemented using IBM SVC and adding a mechanism to craft

partiti...