2013-11-07 08:05 AM
All you have to do is map the lun to server B for access - but you DO have to worry about consistency. If server A fails, it has left the data on the lun inconsistent. Depending on the application, this may be easily recoverable - fsck and log replay, for example - but it is possible there could be some corruption. But this would be the same as if server A panics and reboots, then starts up again - the data will be at the same inconsistent state on server A.
To truly avoid corruption, you need a clustered app - Oracle RAC, for example.
2013-11-07 09:15 AM
Thanks very much Bill I realize that there is a potential for corruption as a result of the crash, but I was told there would be a signature issue if I simply mapped the LUN to server B and that could corrupt the LUN. I was skeptical about this comment and wanted to get confirmation that I wouldn't have a problem at the worst possible moment.
2013-11-07 09:31 AM
I'm not aware of any lun signature from the NetApp side. I know there's a lun serial #, and that can cause confusion. I'm having trouble remembering the details, but either Windows or Exchange complained when the serial # changed after I snapmirrored the luns - but that was re-presenting a different lun to the same host (and was easily fixable by modifying the serial #). If you've only got the one lun, you shouldn't have to worry about that. What application is this? There is the possibility that the app could write some sort of signature that could cause issues, though I don't see how that would corrupt the data. Seems it would only prevent the server B side from using the lun.
As always, I recommend a test....
2013-11-07 12:49 PM
The LUN is just a filestore there's no application other that the OS(Solaris) involved. I agree that a test is in order. Thx for all your help.