What's the best practice for setting up igroups and lun mapping for a cluster?
Last night we moved a cluster that uses luns on Netapp (IBM Nseries) to new servers. The old servers used internal boot disk, while the new use san boot.
I had it setup like this (names are different!): Igroup: serverA_boot wwnA1 wwnA2 boot_lun_mapped_in_lunid0 Igroup: serverB_boot wwnB1 wwnB2 boot_lun_mapped_in_lunid0 Igroup: cluster_luns all_the_cluster_luns_mapped_in_lunid0-149
During the cutover, I went to add all 4 wwn's (wwA1,wwnA2,wwnB1,wwnB2) into the cluster igroup. I was swinging the luns from the old server with internal boot to the new san boot servers and got an error. It complained that I couldn't put the new wwn's into the cluster igroup for luns because the boot igroups already had a lun id 0, and the cluster igroup also had a lun id 0. That is, the same wwn can't map to duplicate lun id addresses.
To fix, I simply remapped the cluster lun at id 0 to the next highest value, then I could add the wwn's and all was well.
Question: Is this the best way to create a san boot cluster? Is there a better way?
The next time I create a cluster lun It will be interesting what lun id gets assigned - lun id 0 (and get an error), or the next hightest.
I also thought of just mapping the cluster luns to both boot igroups, but like that a cluster lun igroup is kind of self documenting.
Thanks for any ideas!
Rick
----------------------------------------- The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Hi Rick In short: You're doing it right.
I recommend saving LUN ID 0 as a boot LUN if you think you ever want to boot from SAN.
The reason you can't have two LUN ID 0 on different igroups is because they are on the same target. The host/initiator has no idea about igroups. It's just a bunch of LUNs on a target WWPN.
Share and enjoy!
Peter
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of rrhodes@firstenergycorp.com Sent: Wednesday, January 15, 2014 11:46 AM To: Toasters@teaparty.net Subject: igroup setup for a cluster
What's the best practice for setting up igroups and lun mapping for a cluster?
Last night we moved a cluster that uses luns on Netapp (IBM Nseries) to new servers. The old servers used internal boot disk, while the new use san boot.
I had it setup like this (names are different!): Igroup: serverA_boot wwnA1 wwnA2 boot_lun_mapped_in_lunid0 Igroup: serverB_boot wwnB1 wwnB2 boot_lun_mapped_in_lunid0 Igroup: cluster_luns all_the_cluster_luns_mapped_in_lunid0-149
During the cutover, I went to add all 4 wwn's (wwA1,wwnA2,wwnB1,wwnB2) into the cluster igroup. I was swinging the luns from the old server with internal boot to the new san boot servers and got an error. It complained that I couldn't put the new wwn's into the cluster igroup for luns because the boot igroups already had a lun id 0, and the cluster igroup also had a lun id 0. That is, the same wwn can't map to duplicate lun id addresses.
To fix, I simply remapped the cluster lun at id 0 to the next highest value, then I could add the wwn's and all was well.
Question: Is this the best way to create a san boot cluster? Is there a better way?
The next time I create a cluster lun It will be interesting what lun id gets assigned - lun id 0 (and get an error), or the next hightest.
I also thought of just mapping the cluster luns to both boot igroups, but like that a cluster lun igroup is kind of self documenting.
Thanks for any ideas!
Rick ________________________________
The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
-
Learmonth, Peter -
rrhodes＠firstenergycorp.com