Mixing HDD sizes on MSA1000

[DrewK]

I'm running out of disk capacity on MSA1000 with all drive bays filled. (14x72GB) I wish to upgrade storage capacity by upgrading one of the two logical arrays with larger capacity drives. This will leave me temporarily operating with Array A being 72GB drives and Array B being 300GB drives. All drives mentioned are U320.

My Question: Is this an acceptable configuration and procedure?

Note: Once the SQL DB is backed-up to the NEW Array B, Array A will then also be upgraded with 300GB drives, then the data restored to the new drives from Array B. End result: All drives on MSA1000 being 300GB.

[Jefferson Humber]

I assume you mean systematically replace each 72Gb HDD with a 300Gb HDD ? Then expand & extend the Array/LUN ?

[DrewK]

Actually I was thinking of physically removing the 72Gb drives of Array B and deleting Array B from the configuration. I'm not experience at this as you may see. Our mission critical DB will be offline during this procedure so I trying to minimize downtime. Am I all wet? Perhaps you could point me to a link that describes your procedure?
Is my proposed way feasible?

[Jefferson Humber]

You can mix HDD sizes in the MSA, this is OK. I would tend to keep them the same size in each array though, but you don't have too... just you may find yourself with unused freespace if you do.

However, you may find you need a F/W update to support the 300Gb models. HP reccomend running the latest version v.4.48

[DrewK]

Jefferson,
I've got the F/W covered. Good to know that I can mix sizes. Now need to know if my procedure is feasible to physically remove the 72Gb drives (7 ea.) of Array B. Plug in 300Gb drives (7 ea.) and configure this as a new, larger Array B. If so, I would carry out my plan. If not, please forward a link to your proposed solution. Thanks!

[Steven Clementi]

Drew:

You can do the whole process with tyour DB online and never have to take down the services.

You can simply swap each drive in the array... one at a time allowing it to rebuild first before swapping the next. This process may take longer to complete, but your DB does not have to be offline for you to complete it.

The rebuild process takes about 15minutes per GB depending upon how much free space you have available, current I/O to the array and the priority settings.

Once all the drives are replaced and rebuilt, you will then have the extra space "available" for creating new logical drives and/or extending existing logical drives.

After the fact, you can use diskpart to extend your data partitions, assuming you are running Windows.

Asside from this, you can surely backup the data (and you better), take teh db offline, rip out all the array B disks and replace with the nw drives, rebuil the array and restore the data. It might be a faster way to get this done, but you would definittely be offline during the process.


Steven

[Jefferson Humber]

I agree with Steven, there are at least two ways to achieve the same result here.

Pulling drives and replacing them one by one, will only work if the LUN isn't a RAID0 (Stripe set) since this has no redundancy for a rebuild.

As with all array re-configuration tasks, make sure you have a known good backup of the data before you start !

Hope this helps,

Jeff

[DrewK]

As it turns out, Array B is RAID0 so the disk-at-a-time method is out, so Iâ ll pursue the rip-out-and-replace method on Array B. Of course this means I need to back-up the data on Array B first. The time it takes me to do this is down time. Iâ ll be doing this maintenance in the wee hours as off-peak as possible. But to minimize down time Iâ m trying to come up with â best caseâ . With the methods available to me (data transferred over the network or to an external drive) Iâ ve estimated about 12 hours. Ouch. What ifâ ¦What if I pull out the 72Gb drives with the data on them and set them gently to the side. If I do the Array B rebuild with the 300Gb drives and all goes bad for some reason, is it reasonable to expect I could put the 72Gb back in and be back where I was originally with Array B? If so then Iâ m home free to try the procedure that would call for very little down time.
If it works, Iâ ll just backup the DB from Array A onto the New, Big Array B.
If it DOESâ T work, Iâ ll just put the original 72Gb drives in and do the 12 hour solution.

This all begs the $64 question:
If I do the Array B rebuild with the larger drives and all goes bad for some reason, is it reasonable to expect I could put the 72Gb back in and be back where I was originally with Array B?

[DrewK]

(without the formatting junk) As it turns out, Array B is RAID0 so the disk-at-a-time method is out, so Iâ ll pursue the rip-out-and-replace method on Array B. Of course this means I need to back-up the data on Array B first. The time it takes me to do this is down time. Iâ ll be doing this maintenance in the wee hours as off-peak as possible. But to minimize down time Iâ m trying to come up with â best caseâ . With the methods available to me (data transferred over the network or to an external drive) Iâ ve estimated about 12 hours. Ouch. What ifâ ¦What if I pull out the 72Gb drives with the data on them and set them gently to the side. If I do the Array B rebuild with the 300Gb drives and all goes bad for some reason, is it reasonable to expect I could put the 72Gb back in and be back where I was originally with Array B? If so then Iâ m home free to try the procedure that would call for very little down time.
If it works, Iâ ll just backup the DB from Array A onto the New, Big Array B.
If it DOESâ T work, Iâ ll just put the original 72Gb drives in and do the 12 hour solution.

This all begs the $64 question:
If I do the Array B rebuild with the larger drives and all goes bad for some reason, is it reasonable to expect I could put the 72Gb back in and be back where I was originally with Array B?

[DrewK]

As it turns out, Array B is RAID0 so the disk-at-a-time method is out, so I'll pursue the rip-out-and-replace method on Array B. Of course this means I need to back-up the data on Array B first. The time it takes me to do this is down time. I'll be doing this maintenance in the wee hours as off-peak as possible. But to minimize down time I'm trying to come up with "best case". With the methods available to me (data transferred over the network or to an external drive) I've estimated about 12 hours. Ouch. What if..What if I pull out the 72Gb drives with the data on them and set them gently to the side. If I do the Array B rebuild with the 300Gb drives and all goes bad for some reason, is it reasonable to expect I could put the 72Gb back in and be back where I was originally with Array B? If so then I'm home free to try the procedure that would call for very little down time.
If it works, I'll just backup the DB from Array A onto the New, Big Array B.
If it DOES'T work, I'll just put the original 72Gb drives in and do the 12 hour solution.

This all begs the $64 question:
If I do the Array B rebuild with the larger drives and all goes bad for some reason, is it reasonable to expect I could put the 72Gb back in and be back where I was originally with Array B?