Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 473
  • Last Modified:

Same LUN presented to four machines, can't see updates from one machine on the other

A guy at work wanted a temporary shared storage between four SQL servers, two virtual and two physical servers. This is so that he can easily do some work that involves importing and exporting data between the servers.

I created a LUN that I presented to the two physical servers and the hosts in the vmware cluster where the virtual machines are. I then created  a Raw Device Mapping on the VMs to the LUN and set the multiwriter parameter for the SCSI adapter it used to yes or true(something to that extent) so that the vm would no try to lock the RDM disk for itself and allow two VMs to share it.

All works nice, but it seems that when data is copied from one machine to the shared storage, one of the other machines might not see the files actually being in the file system. The disk might show the right data usage, and we can browse to the folder, but one can't see the files that were copied there from first machine.

We have tried to rescan the disks in diskmanager, and to give the group Domain Users, and all the machine accounts involved full access. We have also tried to restart the machine that does not see the files. This has not helped.

The server OS on all four servers is Windows 2012 R2.

Any tips?
0
itnifl
Asked:
itnifl
  • 3
  • 2
  • 2
4 Solutions
 
Cliff GaliherCommented:
This is a limitation of Windows. The only way for multiple windows installations to have simultaneous access to shared storage is to create a CSV, and even then CSVs are only supported for specific workloads.... not SQL. You can't do what you want directly. You will have to attach the logical disk to only a single OS at a time.
0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
You *CANNOT* use LUNs like this with Windows, for concurrent ACCESS, it's not supported, and I'm surprised it works, and the data is not corrupted.

You will have to use Clustered Shared Volumes, and Failover Clustering for this support.

or use NFS or a NAS (CIFSs) windows Share.
0
 
itniflAuthor Commented:
This LUN presentiation is not a production solution, but a temporary workspace for one user as stated in the question. The disk does not host databases, but database backups that he manually takes and then imports on other servers, one at a time. He has taken care to write and read from one server at a time to avoid problems with concurrent writes to the disk.

The SQL service on the server however is a part of a production solution and the service runs with the Local System user account. First thing I did was ask him to use a Windows/SAMBA share instead, but he claimed that it would not work when the SQL service uses the Local System user account since it supposedly is not possible to delegate access permitions for it to the share. I have not verified this or tested it. He can't change the user that runs the windows service, since he then would have to take it down and have downtime.

It is too much effort to set up clustering for that one user to have a temporary private workspace.

I am not sure what is being referred to when mentioning CSV. Could you please provide a link or explanation?
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
see here for Clustered Shared Volumes

http://technet.microsoft.com/en-gb/library/dd759255.aspx
0
 
itniflAuthor Commented:
Thanks, actually I found this too:
http://serverfault.com/questions/135867/how-to-grant-network-access-to-localsystem-account

Looks like SAMBA share should work fine, just give access to the computer accounts.
0
 
Cliff GaliherCommented:
"He has taken care to write and read from one server at a time to avoid problems with concurrent writes to the disk.".

That doesn't matter. Windows does a lot of internal data management in the background. From idle defragging to NTFS caching, there are always small writes happening. And since windows is unaware that the LUN is shared, it has no reason to refresh its NTFS cache (which is why other nodes don't always see written files) NOR does it see a need to recheck before doing a background write that it might perform as part of normal OS maintenance. AKA writes not performed by the "careful" user. It'll happily write a block of data right over top of data written by another node.

Being careful isn't good enough. Just don't do it. Use a supported solution instead. As far as SQL using a local system account, that is configurable. But so are permissions to grant access to local system processes, so that reasoning is flawed. Don't let a SQL admin push you into doing a bad configuration (even non-production) and create more work for you (such as troubleshooting missing files) just because they don't know what they are about or are trying to take shortcuts themselves.
0
 
itniflAuthor Commented:
Yes, you are right. I did recheck this multi access to LUN adventure beforehand and I made him aware of the fact that it didn't look like a good idea. However, I did see some on the internet about people trying this, so I thought I'd let him try at his own risk and see where things went. It wouldn't affect more then the work he was doing anyway. Obviously, it didn't work out too good.

I found this, second solution in the list(we are using 2012R2 and is works fine there too):
http://stackoverflow.com/questions/182750/map-a-network-drive-to-be-used-by-a-service


Use this at your own risk. (I have tested it on XP and Server 2008 x64 R2)

For this hack you will need SysinternalsSuite by Mark Russinovich:

Step one: Open an elevated cmd.exe prompt (Run as administrator)

Step two: Elevate again to root using PSExec.exe: Navigate to the folder containing SysinternalsSuite and execute the following command psexec -i -s cmd.exe you are now inside of a prompt that is nt authority\system and you can prove this by typing whoami. The -i is needed because drive mappings need to interact with the user

Step Three: Create the persistent mapped drive as the SYSTEM account with the following command net use z: \\servername\sharedfolder /persistent:yes

It's that easy!

WARNING: You can only remove this mapping the same way you created it, from the SYSTEM account. If you need to remove it, follow steps 1 and 2 but change the command on step 3 to net use z: /delete.

NOTE: The newly created mapped drive will now appear for ALL users of this system but they will see it displayed as "Disconnected Network Drive (Z:)". Do not let the name fool you. It may claim to be disconnected but it will work for everyone. That's how you can tell this hack is not supported by M$.

So the whole adventure ended with using a SAMBA share and mapping with net use, using 'nt authority\system'.

Thanks for the assistance.
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 3
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now