Disk Enclosures
cancel
Showing results for 
Search instead for 
Did you mean: 

BC At-Time Split

Lai Nee Shyang_1
Frequent Advisor

BC At-Time Split

Hi there,

Anyone out there familar with XP1024/XP128 "BC At-Time Split". I heard that there's a limit to the number of LUNS that can be group into a single group. Problem I'm facing is that I have 552 LUSE Luns in my BC copy, which had exceeded the XP limit.

Any comments or suggestion that I can resolve this issue.??

Thanks and Good Day.

Lai
If it doesn't work, We'll make it work. If it works, We'll make it work better.
9 REPLIES
Alzhy
Honored Contributor

Re: BC At-Time Split

Consolidate your LUSE to bigger LUNs.. This is the only solution IMHO.
Hakuna Matata.
Lai Nee Shyang_1
Frequent Advisor

Re: BC At-Time Split

Hey Nelson,

Thanks for your kind reply.From what I understand : The number of LUNS for the BC grouping is not the number LUSE LUNS, it is the number of LDEVs (Open-E). In my case, I have 2 Open-E LUNS that make up a LUSE LUNS. And in total, I have 552 LUSE Luns, which total of 1104 LUNS. The limit in the BC group is 1024, which if base on the number of Open-E LUNS, I've exceeded. But if base on LUSE LUNS, then I should be still covered.
Is my understanding correct ? And if so, any way I can resolve this ?

Thanks a million.

Lai
If it doesn't work, We'll make it work. If it works, We'll make it work better.
Sanjay Kumar Suri
Honored Contributor

Re: BC At-Time Split

My understanding is as below:

32 host group per CHIP port. 2048 host groups per array.

256 LUNs per host group, max 512 LUNs per port.

LUSE can only be used to create larger LUNs by combining LDEVs.

However, LUSE can not be used to extend the maximum number of LDEVs supported by the system as given above.

sks
A rigid mind is very sure, but often wrong. A flexible mind is generally unsure, but often right.
Lai Nee Shyang_1
Frequent Advisor

Re: BC At-Time Split

Hi Sunjay,

Thanks for your kind reply. But I don't quite understand it. What's the relationship between the LUN Group size (number of ldevs) with ports, host group etc.?

To share with all, I posted another question to HP labs about why does the XP design allow you to install more than 1024 ldevs on a XP box but essential functions like LUN grouping cannot allow all the luns to be group into a single group.
I'm sure there are many XP users whose database are critical and cannot afford down time for backup operations. How does one achieve 0 downtime full snap shot backup?

Thank you.

Lai
If it doesn't work, We'll make it work. If it works, We'll make it work better.
Sanjay Kumar Suri
Honored Contributor

Re: BC At-Time Split

Hello Lai

Host groups are needed to provide security. When you enable security for a port, only those hosts that are members of the host group for which LUNs have been defined will see the LUNs.

With security disabled there will be only one host group. If you want, you can define another host group.

It is recommended to use host based software such as volume manager instead of LUSE.

I am not clear on your how yout post is related with the statement:

"I'm sure there are many XP users whose database are critical and cannot afford down time for backup operations. How does one achieve 0 downtime full snap shot backup?"

sks

A rigid mind is very sure, but often wrong. A flexible mind is generally unsure, but often right.
Lai Nee Shyang_1
Frequent Advisor

Re: BC At-Time Split

Hi Sanjay,

I believe we are on the wrong frequency. ha ha.

The issue I'm facing is regards to the limitation on BC LUN grouping. In my environment, I've a XP hosting production, another XP at DR site hosting a synchronous CA and BC copy. We use the BC copy for our database backup. Our existing backup procedure is to shutdonw production, do a BC split, start up production, carry out filesystem level backup of the BC copy. We can only afford to do this twice a week as this is very disruptive to the production system. I'm looking for possibilities to split BC copy whithout shuting down my production system. In XP1024, there's this "BC at time split" which can achive lun consistency during split. But the problem is there's this limitation of 1024 Ldev in a single BC Lun group, and I've 1108 Ldevs which has exceeded this limitation.

My question is, why is there such a limitation while the XP allows u to expan to more than 1024 ldevs per CA/BC copy ? And is there anyway to bypass this limitation.

Phew.. that's the issue I'm facing.

Cheers.

Lai
If it doesn't work, We'll make it work. If it works, We'll make it work better.
Sanjay Kumar Suri
Honored Contributor

Re: BC At-Time Split

Hello Lai

Check Page 10 of the following link:

http://www.hp.com/products1/evolution/e3000/download/52430407c.pdf

Will increasing the shared Shared memory overcome the limit you are facing?

sks
A rigid mind is very sure, but often wrong. A flexible mind is generally unsure, but often right.
Lai Nee Shyang_1
Frequent Advisor

Re: BC At-Time Split

Hi Sanjay,

I've read thru page 10 of the document you've mention, quite useful but there's no mention on the limitation of number of LDEVS withing 1 disk array group. Is there any document on disk array group or BC At-a-time split ?

The HP engineer is currently asking HP labs if increasing the share memory will increase the number of LDEVs per group. I'm still waiting for his reply. My wild guess is that, unless this is a limitation cause by share memory, else these two aspect should be independent. You agreed ?


cheers.

Lai
If it doesn't work, We'll make it work. If it works, We'll make it work better.
Sanjay Kumar Suri
Honored Contributor

Re: BC At-Time Split

Hello

Also check the documents:

http://h200006.www2.hp.com/bc/docs/support/SupportManual/lpg60211/lpg60211.pdf
http://h200006.www2.hp.com/bc/docs/support/SupportManual/lpg29285/lpg29285.pdf

I have not understood what do you mean by "disk array group" in the statement "number of LDEVS withing 1 disk array group". I have only heard of terms Marketing array group/Parity group.

Max number of LDEVs in Xp128/Xp1024 = 8192

sks
A rigid mind is very sure, but often wrong. A flexible mind is generally unsure, but often right.