Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
Solved! See The Solution
1 ACCEPTED SOLUTION
migration has accepted the solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
11 REPLIES 11
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Come on Bren, dont be shy. Give it away mate.
Eric
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Eric & Brendon -- we are having trouble with the expert replies showing up. We are working on the fix as I write.
Terri
Thanks so much!
Terri Peluso
Senior Community Program Manager
Terri Peluso
Senior Community Program Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Thanks so much!
Terri Peluso
Senior Community Program Manager
Terri Peluso
Senior Community Program Manager
migration has accepted the solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Brad! Still testing (and fixing) the posting issue.
Thanks so much!
Terri Peluso
Senior Community Program Manager
Terri Peluso
Senior Community Program Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Andrew,
If you are satisfied with the responses please mark as 'Answered'. If not, just let us know and we can work on getting more info. Thanks!
Thanks so much!
Terri Peluso
Senior Community Program Manager
Terri Peluso
Senior Community Program Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So...I'm horrifically slow but just awarded points.
