LUN/Processor Ownership

Question

I am working on my B2D environment, trying to tune it for performance and have a question regarding LUN ownership with regards to processors and MetaLUNs.

In the B2D whitepaper (EMC CLARiiON Backup Storage Solutions: Backup-to-Disk Guide with NetWorker DiskBackup Operations -- 11-2006) on page 9 under the recommendations for disk-based backups, bullet 4 refers to all LUNs on a RAID Group should be owned by the same processor. The paragraph just before this section explains it slightly more, but is clear as to why.

My question is: When I create my MetaLUNs, they have two components. I expand the LUN which has the ownership that I want for the MetaLUN. However, I can look at the component that was added and if it was owned by the other processor, it still shows that ownership, although it is grayed out.

My instinct leads me to believe that the tasks being performed as a result of being a MetaLUN are performed by the MetaLUNs current owner (presumable the default), and the activities associated with being a component of a MetaLUN are being processed by the owner of the compenent and therefore, I should define ownership of all of my LUNs according to the owner that I want to MetaLUN to have when all is said and done.

Is the component ownership still valid even though it is grayed out and a MetaLUN has been formed?

roamdeep · Answer

Thanks for the whitepaper and the reply, Glenn.

kelleg · Answer

Once a LUN has been added to a metaLUN, it will take on the ownership of the first LUN that you expanded - it happens in the background and you can't control it.

MetaLUNs

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/H1024.1_clariion_metaluns_cncpt_wp_ldv.pdf

Not sure about the bullet 4 - I will check with someone about all the LUNs owned by the same SP.

glen

roamdeep · Answer

Glen,Did you ever hear anything about the LUNs from a RAID Group being owned by the same processor? I am still moving LUNs around and would like to plan accordingly. So far, I have not read that same recommendation in the metaLUN whitepaper you shared, but I have not finsished reading it. Thanks.

roamdeep · Answer

I have the understanding that no matter who owns the component, it is managed by the default owner of the metaLUN -- presumably the owner of the base LUN. I think I read that in the metaLUN doc Glen shared, but will go try to find it again. That's why i asked my question about whether I should line all that up prior to expanding a LUN.

Thanks for the reply.

nandas · Answer

The owner SP of a metaLUN becomes the owner for all component LUNs as well. So if you create a MetaLUN on SPA - all component LUNs are also owned by SPA - if any component LUN was having default ownership to SPB - that LUN will show as Trespassed, unless you modify the default owner of that component LUN to SPA. I assume, Robert was mentioning the same.

So, you may plan accordingly to have MetaLUN components on a single SP - or else system will do it while creating MetaLUN based on the default owner of the meta and you need to modify the ownership of those trespassed LUNs later.

My 2 cents

Sandip

RobertDudley · Answer

Remember that if you add a lun to a meta lun with a different SP owner that lun will show as trespassed. You can change the default owner prior to adding it but once added you cannot change the default owner.

kelleg · Answer

The performance person that I asked is out until a bit later this week.

I can't figure out why this was recommended unless you were using the OLD ATA disks - then you were suppose to put all LUNs in a RG on the same SP.

glen

roamdeep · Answer

Thanks for the replies, Glen, Sandip and RobertDudley.

I am clear on the first question, does the component inherit the Default Owner of the metaLUN even though it is grayed out and may show a different Default Owner. The answer being Yes, it takes on the ownership of the metaLUN even though it may not show the same owner.

The second question, do all LUNs from a RAID Group need to be on the same SP, is still out there. I understand that Glen is waiting for a performance guy to return. I'll look for a reply when he returns. Until then, I will continue looking at the metaLUN whitepaper.

Again, thanks.

Bart

RyanP2 · Answer

In older arrays that have DAE-ATA and DAE2-ATA enclosures, all luns within the ATA Raid Groups in these enclosures should be on the same SP. This is due to the way the drives interface with the buses.

In newer arrays (that have DAE2P and DAE3P enclosures) the ATA drives interface in a different way and there is no need to have all luns in a group on the same SP.

In the guide you mention it has that blanket statement of all luns on the same SP, but it probably is assuming the old style DAEs and ATA drives (as the next section mentions only the use of ATAs for Backups).

-Ryan

RRR · Answer

In the performance workshop I attended about 3 years ago they told me that ATA RGs needed to have all LUN's in the same RG owned by the same SP to try to get a more predictable I/O sequence on the RG since all LUN's are owned by the same SP and prediction is done in each SP.

AFAIK there's no need to have all meta components owned by the same SP.

RyanP2 · Answer

All luns under the Meta will be on the same SP no matter what. Being trespassed or not depends on what SP the entire Meta is on and what default owner each component lun has.

For example, say you have a Meta which has 2 components, and 1 lun was bound on A (which we will call the meta head) and 1 on B. If the Metalun is on SPA, then the second lun is technically trespassed (on SPA but default is SPB).

-Ryan

roamdeep · Answer

The question arises, then, is my CX500 considered an older DAE/SPE? We've had it for 5 years and it was a midrange SPE.

I guess it is safe to say that if I wanted to configure the metaLUN ownership to account for the old DAE recommendations, it would be fine as long as I can still distribute the ownership and prevent the CX500 from being lop-sided.

The configuration I am considering now involves vertically provisioning 2 identical DAEs with 2 RAID3 8+1 RGs and 2 RAID3 4+1 RGs. The LUNS will be distributed over all 4 RGs on the two shelves. With this configuration and the old DAE recommendations, all of my LUNs on those two DAEs would be owned by the same processor. The remaining LUNs, horizonally provisioned, would be on the other processor.

For now, I am almost finished moving everything to RAID3 groups. Once the migrations are complete, I can give it a week or two to establish a baseline.

Thanks for all your time and help.

Bart

RRR · Answer

Clear, but does it show in the list of tresspassed luns ? I think not, since you can't do anything about it.

RRR · Answer

So will meta components always show up as tresspassed if they're not owned by the same SP as the meta head ?I'm asking this because then it would be wise to change ownership before creating the meta.

RyanP2 · Answer

RRR, I'm not sure if it shows or not.

CLARiiON

LUN/Processor Ownership

Was this post helpful?