Actually a few people here have experience with the first two options. There are some old threads that cover this exact situation.
I have done all three options multiple times on Microsoft SQL 2000 and 2005 clusters running Windows Server 2003.
Depending on the current configuration of the LUN that needs expansion and the growth needs of the database will determine what is the best option for you.
For example, if the current database LUN is 300GB in size and you only need to add 100GB then it would be better to migrate to a 400GB LUN that is the appropriate RAID type and has the appropriate number of spindles for the database.
Or if the current database LUN is 200GB and you want to add another 200GB then create an identical LUN on another RAID group and expand using striping for best overall performance.
Both of these will incur zero downtime for the active node of the cluster. The only gotcha I have seen with expanding the LUNs of a cluster is that it is non disruptive for the node actively hosting the physical disk resource, but the passive node will need to be rebooted to recognize the expanded disk and be able to host the disk resource.
When you increase the size of the LUN, don't you also need to run diskpart to allow Windows to see the increased size?
glen
Yes, but that is a non-disruptive process for Windows. Just make sure there is not a lot of i/o to the LUN at the time as there is a brief one or two second pause of i/o during the expansion.
I make my decision based on a few factors. 1. How quickly do I need to expand the disk? 2. Is there available space on the same raid group, or will I have to use new spindles? 3. Is the server performing ok as of now, or can I use this opportunity to allocate more spindles? 4. How much space do I have available and on what type of spindles?
Unfortunately, I have had to do a couple emergency expansions when a process is running wild. The quickest thing in those scenarios is to do a concatenate MetaLUN using the same raid group or one with a similar IO pattern.
When creating a MetaLUN the first time, I often strip across multipe raid groups, but when I expand a MetaLUN, I almost always end up just doing a concatenate. If you re-stripe, it taxes the system as it restripes all the data across all the spindles. You don't have the restripe penalty if you haven't used the LUN yet. There are definitely reasons why you would want to restripe, but for large LUNS, you're looking at a long time to restripe.
I have only expanded a LUN by using LUN Migration once or twice. It has some interesting performance implications as well. It makes heavy use of the cache on the system to move the data. As a general rule, do not use ASAP as it can slam your array. One other interesting point is that when the LUN migration is running and it reaches the new space on the destination lun it runs an internal consistency check which runs (according to the Clariion Best Practices guide) at 40MB/s on a 4+1 R5. The doc then goes on to explain that you can concatenate a MetaLUN to make the LUN The right size before copying to the destination.
The only time I create a brand new LUN and use a host-based copy is if I need to change the drive offset, cluster size, or if I'm having problems with the volume for some other reason.
Expanding a partition with diskpart is a breeze. Once you select the partition, just type "extend" and you're done.
kelleg
4 Operator
•
4.5K Posts
0
August 25th, 2008 14:00
LUN Migration
http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/H1529.1_emc_virtual_lun_tech_wp_ldv.pdf
and
White Paper: The Influence of Priorities on CLARiiON LUN Management Operations - Applied Technology
http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/H4153-the-influence-of-priorities-on-lun-mgmt-optns-wp.pdf
MetaLUNs
http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/H1024.1_clariion_metaluns_cncpt_wp_ldv.pdf
glen
AranH1
2.2K Posts
1
August 25th, 2008 15:00
I have done all three options multiple times on Microsoft SQL 2000 and 2005 clusters running Windows Server 2003.
Depending on the current configuration of the LUN that needs expansion and the growth needs of the database will determine what is the best option for you.
For example, if the current database LUN is 300GB in size and you only need to add 100GB then it would be better to migrate to a 400GB LUN that is the appropriate RAID type and has the appropriate number of spindles for the database.
Or if the current database LUN is 200GB and you want to add another 200GB then create an identical LUN on another RAID group and expand using striping for best overall performance.
Both of these will incur zero downtime for the active node of the cluster. The only gotcha I have seen with expanding the LUNs of a cluster is that it is non disruptive for the node actively hosting the physical disk resource, but the passive node will need to be rebooted to recognize the expanded disk and be able to host the disk resource.
RRR
4 Operator
•
5.7K Posts
0
August 26th, 2008 02:00
Therefore:
kelleg
4 Operator
•
4.5K Posts
0
August 26th, 2008 07:00
glen
AranH1
2.2K Posts
0
August 26th, 2008 08:00
need to run diskpart to allow Windows to see the
increased size?
glen
Yes, but that is a non-disruptive process for Windows. Just make sure there is not a lot of i/o to the LUN at the time as there is a brief one or two second pause of i/o during the expansion.
shearermd
10 Posts
0
August 26th, 2008 08:00
http://support.microsoft.com/kb/325590
RRR
4 Operator
•
5.7K Posts
0
August 31st, 2008 12:00
shewitt1
45 Posts
0
September 2nd, 2008 08:00
1. How quickly do I need to expand the disk?
2. Is there available space on the same raid group, or will I have to use new spindles?
3. Is the server performing ok as of now, or can I use this opportunity to allocate more spindles?
4. How much space do I have available and on what type of spindles?
Unfortunately, I have had to do a couple emergency expansions when a process is running wild. The quickest thing in those scenarios is to do a concatenate MetaLUN using the same raid group or one with a similar IO pattern.
When creating a MetaLUN the first time, I often strip across multipe raid groups, but when I expand a MetaLUN, I almost always end up just doing a concatenate. If you re-stripe, it taxes the system as it restripes all the data across all the spindles. You don't have the restripe penalty if you haven't used the LUN yet. There are definitely reasons why you would want to restripe, but for large LUNS, you're looking at a long time to restripe.
I have only expanded a LUN by using LUN Migration once or twice. It has some interesting performance implications as well. It makes heavy use of the cache on the system to move the data. As a general rule, do not use ASAP as it can slam your array. One other interesting point is that when the LUN migration is running and it reaches the new space on the destination lun it runs an internal consistency check which runs (according to the Clariion Best Practices guide) at 40MB/s on a 4+1 R5. The doc then goes on to explain that you can concatenate a MetaLUN to make the LUN The right size before copying to the destination.
The only time I create a brand new LUN and use a host-based copy is if I need to change the drive offset, cluster size, or if I'm having problems with the volume for some other reason.
Expanding a partition with diskpart is a breeze. Once you select the partition, just type "extend" and you're done.
Good luck!
RRR
4 Operator
•
5.7K Posts
0
September 17th, 2008 05:00