When you say clients are you talking about ESX clients? Or do you have 750 physical servers that need to see a single device?

750 physical servers that need to see a single device.

Are you sure about this?

A device can be presented to multiple servers, but it is then the responsibility of the servers to coordinate amongst themselves to work out who has the write access. This is typically done by host clustering software. I'm a little skeptical about a 750 node cluster...

I can understand the concerns behind provisioning such a LUN with write permissions precisely because of what you said, however what about read-only permissions? I don't see how that could be a technical problem nor how it could negatively impact my storage array.

There is certainly nothing from a storage management perspective doing what you are intending to do. The maximum number of masking views is 64K.

Great, thanks. So to conclude, unless I am provisioning such a LUN with write-access, there is no need for concern?

By the way, if I use SCSI3 Reservation, wouldn't it be fine to provision that even with write-access? I mean I could see potential problems even with SCSI3, but I think it can be possible, don't you?

This is still a bad idea. SCSI volumes are not meant to be shared amongst non-clustered hosts. I don't know what OS your hosts will be running, but if one host were to write to the volume, the rest of the hosts would not know about the write and they could very well have stale read cache on the volume. This scenario could cause data corruption on the volume, kernel panics and/or blue screens depending on the OSs. For a shared data-store scenario among non-clustered hosts, an NFS/CIFS share would be more appropriate.

Thank you for the illuminating response. However, what you said about hosts not knowing about the write sparked a red flag for me because what that essentially means is that I can't provision the same LUN to different Storage Groups.

What I concluded from your reply is that hosts from different storage groups can't see the I/O requests to the same LUN which means that if I want to share a LUN I can do so only through a cascaded storage group?

Sorry, that is not the conclusion I meant for you to draw. The functionality of the devices will be identical if you were to use multiple SGs vs a cascaded SG solution. The result for both of those would be unsupported. In order for multiple hosts to read and write from the same SCSI volume, both the OS as well as the filesystem need to be designed for this express purpose. Some examples are Microsoft Cluster and ESXi Cluster.

Standalone hosts reading and writing from the same SCSI volume is simply not supportable and data integrity cannot be guaranteed in this configuration regardless of how you have provisioned the volume from the array. The SCSI protocol itself it not written to "multicast" changes to the hosts. A separate software layer (cluster services) must be employed to add this kind of functionality.