can I grow a meta device for a windows server

First symconfigure script looks good to me.


Second symconfigure script is good but keep on reading


Third script is good. You can skip "disk_group" option .. see below


The last one is great.


The idea is good overall .. But I think that the space you'll free deleting 32 RAID5 devices will hardly be usable to build 32 unprotected BCV since each raid stripe uses only 1/7th the size of the volume. You'll simply free 32*8 slices (maybe on 32*8 different drives) 1/7th each. With this space you can't build 32 BCV since each BCV volume will require a free space as big as the BCV volume you want to create. If you have freespace somewhere in your box (not only in disk_group 2) use the freespace to build BCVs and delete them when you expanded your meta.

My 2 cents .. deleting RAID5 7+1 devices is the best way to drill holes in your binfile

Either ask EMC to dig into that or use already available freespace to create brand new BCV devices.

Cheers !!

Message was edited by:
Stefano Del Corno

Hi Shawn,

Since I had a bit of time I grabbed the binfile on your DMX, and had a quick look.

The first question I have is where do you intend expanding the meta 91D onto? Are you going to re-use existing volumes (if so, which), or create new devices?

The reason I ask is that 91d is built from disk group 6 as per your output, which are 146GB 15K RPM drives. (You can see this yourself from a "symdisk list" and "symdisk show -v -gaps").

The only spare capacity in the box appears to be in groups 1&2, both of which are 300GB 10K RPM drives. You can probably guess what I'm about to say next - its not recommended for a meta to span different drive types (actually drive speeds).

Your engineer can create a meta like this, but I'm not sure if symconfigure will allow it. I think it probably will as its only a SymmWin "hint" - but I can't be sure about this. You need to be aware of reduced performance in this case.

The next issue is that huge metas tend to wrap around on themselves. Assuming you create new volumes (on the 300GB drives), the largest meta I could create before this happened was 48 members - which would give you approx 816GB. There is enough space to go to the 1TB, but the meta would have 7 pairs of members on the same spindles (ie a 64 member meta, spanned over 50 physical drives). Again, not great for performance.

Ok - now that's out the way. There is enough space in group 2 to create new BCVs without having to delete your RAID5 ones. However, if meta 91d is extended using drives from group 2, then some of the 91d members will share the same spindles as the BCVs. This will really slow down the metavolume expansion (restore phase) as these drives are going to get hammered. In the worse case, you may end up restoring from a BCV to a standard on the same physical spindle. It will work, but it will be very slow.

Even if you delete the R5 BCVs, the expanded meta will still share some physical spindles with the BCVs, so there's not much to gain there.

To address Stefano's comment - deleting the R5 BCVs isn't an issue as you're deleting 32 of them. There's enough space to fit 32 unprotected BCVs and leaves an approx 2.5GB "gap" on each disk. So, he's quite right - there is some wastage. However, at the end of the expansion you could delete the unprotected BCVs, and put back the R5 BCVs.

Anyway, before this gets much longer I think maybe the best thing for performance is to purchase 64 additional 146GB 15K RPM drives (ie 32 mirrored pairs), and expand your meta onto this using a BCV meta on the 300GB drives. The new drives would ensure that the meta doesn't wrap around on itself, and that the BCV volumes don't share the same spindles. You have enough space in group 2 to do this without deleting the R5 BCVs.

Phew!

Best Regards,
Marc

Message was edited by:
MarcT

Marc unfortunatly I can't look at the binfile since I don't know the customer and I don't know the serial of the box .. Maybe you already know him and know things not that obvious in the forum

Generally speaking, deleting RAID5 devices (either 3+1 or 7+1) does not allow to create unprotected or 2-way mir devices since it will leave small holes (1/3rd or 1/7th the size of the logical volume) here and there in your backend ..
If the holes (gaps) are one next to the other on the same drive (i.e. 15D:D04) you can have a single bigger gap (as per our previous discussion). And "merging" 3 or 7 small gaps you have the space to build a single unprotected BCV.

But if you have a big meta made with hypers that are on a small numbe of drives, using hypers one next to the other in the same drive, you are already having a lot of contention in the backend.

If you want to take it offline, you can find me in outlook ..

Cheers !!

Message was edited by:
Stefano Del Corno

Hi Stefano,

I'm not disagreeing - you are quite right! Its very easy to make swiss cheese out of a binfile by deleting RAID5 volumes, especially if they're 7+1!

In this particular case, deleting 32 consecutive RAID5 BCVs does release enough space to create 32 unprotected BCVs of the same size, and leaves a gap of approx 2.5GB on each of the 32 physicals.

Since this BCV is for one use only, it could be deleted at the end and the R5 volumes put back.

Anyway I only looked at the bin very quickly - I would suggest Shawn talk with his local engineers to discuss in more depth in case we've overlooked anything.

Best Regards,
Marc

Message was edited by:
MarcT

Marc .. as I said I can't look at the bin .. but in my experience, consecutive symdevs are spread on different hypers .. Unfortunatly Shawn posted the "symdev show" output only for one device .. maybe looking at the backend distribution for every dev that belong to the meta may give an answer

If the disk group (in the backend) is made of 32 drives, deleting 32 devices will leave enough space for the bcvs as you said .. But again I don't know how the DG are layed out .. Maybe a "symdisk -sid xxx -disk_group 7" may help

Cheers !!

My customer changed his mind a lot of times ... from 2-Way-Mir to RAID .. from RAID to BCV .. from BCV back to RAID and again back to 2-Way-Mir .. I'd like to send you a nice binfile that looks very like a piece of swiss cheese .. Gimme your email addres so I can share this nice binfile

hey Stefano,

actually been pretty busy here with iSCSI deployment and getting ready to dive into Avamar. I am watching interesting discussions about deleting/creating devices etc ..can't contribute a whole lot to those discussions but sure am learning a lot from them

[OT]
Welcome Mr Dynamox !! Where had you been ?? Too busy earning easy points in Clariion area of the forums ??

We missed you .. But now you are back in the "hard core" area of the forum !!

You however are right ... I'll respect their privacy .. I'll share the binfile with emule .. but anonimously
[/OT]

hey ..respect their privacy ..maybe customer does not want their swiss cheese to be seen by anybody else

Hearing all the info in this thread, reminds me just how little I know about what I have been trying to accomplish, and am glad you guys have shown me that. The original idea was to create a BCV device equal to the original meta device that was assigned to a Windows server. Once the meta was grown, the BCV devices were to be put back to their original state. The meta was to be increased from 32 devices, to 60 devices while preserving the application data. Since I was not able to get a full grasp on what I needed to do to achieve this, I ended up creating a new 1Tb device and masked and mapped it to the same server. The data was copied from the old device to the new device and I then just modified the drive letter assignment in Windows, so that the SQL databse would not freak out. My only problem now, is that I've been told that this database will need to be grown again in a few months, to accommodate one more department. So, I would still like to learn the proper way of doing this.

Obviously this wasn't what I wanted, but my experience left me no choice. I really appreciate the help you have all given, this is hands down the best forum I've ever used. One last quick question, I feel like I have a decent grasp on how to work with our DMX (not like you guys of course, but for having no training at all and being thrown at this only 4 months ago and still having to perform all UNIX duties, I think I am holding my own), but I think my biggest problem lies with not understanding the internals of EMC. Is there any PDF or guide you guys would suggest, to get a better understanding of the device layouts and such.

Also, thanks MarkT for editing my post and removing sensitive info, I guess that reiterates just how green I am with this.