need help with LUNS zoning

Thank you Woolmilkproc and Daniel for your advice.

One samll query - Should I say that in max scenario we dont need reboot?

Hi Daniel - Sorry but could you please explain some more about your bottom second point on DM Multipath - I confuse in that?

Any other advice will be highly appreciated!

You don't need a reboot, that's true.

If your zone changes would take away active LUNs from a server you must take care that these LUNs are down on the concerned server - means: applications using the respective filesystems or raw devices shut down, filesystems dismounted (better: deleted) and disks removed from the server's config.

Thanks Woolmilkporc,

Actually I am concerned about your this statement:
"One caveat though: Each zone reconfiguration causes RSCNs ("registered state change notifications") to be sent to all nodes. It might happen that an HBA cannot process these RSCNs fast enough so that there might be a disruption of I/O. Change the zone config only when your SAN is not too busy (or when short I/O disruptons are acceptable)."

I dont want any problem - what do you think is it a major issue?

Or if you could brief me some more about it ?

Each change in the SAN configuration gets propagated to all nodes (HBAs).

This is done by means of RSCNs ("registered state change notifications") which must be accepted, processed and answered by the concerned HBAs.
So if your HBAs (switches and servers) are very busy it might happen that an HBA is not able to process an RSCN fast enough between I/Os, so that I/O might be delayed or even disrupted. Switch and HBA will have to communicate such a disruption to finally repeat the failed I/O(s).

This will obviously take some time, and if your applications are very sensitive in regard to response time you should not perform major SAN config (zone) changes during busy hours.

Hi Daniel - Sorry but could you please explain some more about your bottom second point on DM Multipath - I confuse in that?

Sure. dm-multipath is used in Linux (RHEL) to virtualize many different paths to one LUN as one multipathed device. Since most are firm with IP - networks, I will try an analogy.

Some detail: In Ethernet/IP networks, you may only have one path active at a time. If you connect two ports of the switch with one cable, you packets are traveling endlessly; STP will stop that, you can call dm-multipath an equivalent if you like.
In a SAN, multiple paths are possible and even wanted for performance and redundancy. Remember, storage access is much more delegate then network access. For instance, you connect two ports of your FC switch to your computer. If one port fails, you still have the other port. But: You see your LUN twice. If you access the LUN from both ports, data corruption will occur.

This is where dm-multipath will come in: It distinguishes the devices it sees more than once and aggregates them into a virtual device you will now access (it even blocks the access to the original device). As with STP, it can make fastest (shortest) path decisions while it can also use all paths together for performance (STP would block one path).

By default, if one or all paths failing, dm-multipath would put IO operations to that device in an endless cue until the paths are available again. If you zone a LUN out, you do that on purpose and they never come back.

So, while all of woolmilkporc's statements are true and working well, I still find it more practical to switch off the server if I do zone out LUNs - because it is sometimes faster then unmounting all the devices and stopping (and finding) all services and open files. If you need the system up, then you can achieve the same without switching it off of course.

Thank you both for detailed info on this.