iGroup Management

[#1]

Generally when installing SnapManager for SQL/Exchange, I just let all igroup management be done automatically out of SnapDrive. Are there any downsides to handling it this way? (as the upside is that using SD for this makes things very simple)

[#2]

Hi Andrew,

Here is some info which is not directly relating to SD but rather to how to use LUNs in a cluster. My understanding (I could be wrong) is that if a LUN is presented from

a controller that is in a cluster the LUN IDs across the CLUSTER need to be unique to ensure a healthy failover. So if you have a LUN with ID 100 on controller A

you should not have a LUN with ID 100 on controller B (partner in cluster) is it can potentially confuse the host accessing this LUN.

Not knowing how SD does this I cant really say if its good enough or not. But something to be aware of in the event I am right. I hope the experts can clarify this.

Cheers,

Eric

[#3]

Ah....very good point. If I understand correctly, "LUN ID uniqueness" is specifically required when using FC connectivity and Single System Image on the NetApp side (as that causes both cluster members to present out the same WWPN to the FC fabric)....no needed with iSCSI given the two cluster members have unique IP #'s.

My understanding is that SnapDrive does take care of this...but I'm not sure how to confirm that...so confirmation would be great.

[#4]

I think I know the answer to this one but am not sure so will just post this place marker so that I can see

what other people say.  Maybe learn the correct answer...

Bren

[#5]

Come on Bren, dont be shy. Give it away mate. 

Eric

[#6 · Accepted solution]

There aren't really any downsides to letting SnapDrive do it automatically.

The ability to do manual igroup management was added for people that want to be able to specify particular igroup names, etc... .

The unique LUN IDs is not really a SnapDrive "issue" but  storage system topic.  On an active/active (or clustered) storage system, the LUNs IDs do have to be unique since the LUNs are available across the ports on both controllers with the same WWNodeName across controllers.  When mapping LUNs the storage system checks if the number (the N in LUN) is already used for that igroup and only allows unused numbers. 

Cheers,

Rick

[#7]

Eric & Brendon -- we are having trouble with the expert replies showing up.  We are working on the fix as I write.

Terri

[#8]

The replies above regarding LUN IDs are good points.  But focusing from a pure iGroup perspective Rick is correct, I can't really think of any down sides to letting SnapDrive control this automatically unless you really need to manually control the iGroup names in your environment.

[#9]

Here are the direct links to responses -- still working out the post issues....

From Rick Joos  - http://communities.netapp.com/message/16749#16749

There aren't really any downsides to letting SnapDrive do it  automatically.

The ability to do manual igroup management was added for people that want to  be able to specify particular igroup names, etc... .

The unique LUN IDs is not really a SnapDrive "issue" but  storage system  topic.  On an active/active (or clustered) storage system, the LUNs IDs do have  to be unique since the LUNs are available across the ports on both controllers  with the same WWNodeName across controllers.  When mapping LUNs the storage  system checks if the number (the N in LUN) is already used for that igroup and  only allows unused numbers.

Cheers,

Rick

From Brad Garvey -  - http://communities.netapp.com/message/16793#16793

The replies above regarding LUN IDs are good points.  But focusing from a  pure iGroup perspective Rick is correct, I can't really think of any down sides  to letting SnapDrive control this automatically unless you really need to  manually control the iGroup names in your environment.

[#10]

Thanks Brad! Still testing (and fixing) the posting issue.