HPE EVA Storage
1844929 Members
1541 Online
110233 Solutions
New Discussion

Re: Virtual replicator deployment

 
SOLVED
Go to solution
Martin Stanjer
Advisor

Virtual replicator deployment

We have an MSA1000 (redundant controller and switches using sec.path V4.0). They have four w2k servers that need to access this storage, and the company has 10 separate divisions with different storage requirements. Each division will use only one of the four servers, but as the divisions grow, it may be necessary to connect one or more of the divisions to a different one of these servers to balance server (network) load more efficiently, whilst still accessing the same storage volumes. Thus all servers have to be capable of seeing all drives. We are experimenting with different ways of implementing storage units within the MSA1000, and using Virtual replicator V3.0A to create pools and virtual disks for each division (snapshotting is an important requirement). We intend to prevent users of different servers seeing the wrong data by un-mapping drive letters to certain drives on each server, but an administrator may need to alter this mapping when changing the server used by a particular division.
The problem we have appears to be that with virtual replicator installed on each server, and all storage visible to all four servers, changes made to pools on one servers VR MMC (eg new v.disk or v.disk expansion) are not reflected on the others until they are restarted. This leads to a situation where data could be lost if something like drive expansion is carried out without the same procedure being run on the other servers identically.
Are we trying to use VR in entirely the wrong way, or is there a way of syncronising each servers VR settings? Should we be using some kind of VR management on one server only with the others acting as agents only?

1 REPLY 1
TFatman
New Member
Solution

Re: Virtual replicator deployment

OK - the issue you are encountering is a Windows limitation.
On boot each server is loading its own file system, any changes to the file structure are unique to the server that the changes were made on. So effectively your files are being written to disk but the changes to the file system itself are not propegated to the other servers so they can not see any changes to the data until the volume is dimounted and remounted.
Golden rule - you cannot have more than one Windows server accessing the same file system unless you are either clustering or sharing through Windows files system (ie network share).
You should be using Selective Storage Presentation to restrict access to each volume to one server only.
I would say from your description that a good NAS box (or NAS/SAN fusion) with a well Planned DFS would be more suited to you requirements.