Copy-less Data Distribution

Go into the Universal Volume Manager and have USP-V(M)-Local discover USP-V(M)-Remote’s LUNs. This should happen fairly quickly and painlessly. Configure these LUNs as LDEVs and address them in one of the Logical Control Units in order to give them a controller address. The assigned addresses in a LCU can be done automatically or manually. You can now configure these LUNs as eLUNs (external LUNs) and map them to a FC port. In this case, map them to the same port that the Linux server is connected to that you set up in Step A. For this description, I have “Cache Disabled” since these are USP-VM and the local caches are very fast as it is.

Step C2, repeat device discovery from USP-V(M)-Remote.

Now do the same thing from USP-V(M)-Remote. Go into the Universal Volume Manager and have USP-V(M)-Remote discover USP-V(M)-Local’s LUNs.

Step D1, map the new eLUNs to the Linux server on USP-V(M)-Local.

Go into LUN Manager on USP-V(M)-Local and map the new eLUNs from USP-V(M)-Remote to the same port as the initial physical LUN (internal LUNs) from Step A. These LUNs will be noted with a “#” symbol appended to them.

Step D2, map the new eLUNs to the Linux server on USP-V(M)-Remote.

Go into LUN Manager on UPS-V(M)-Remote and map the new eLUN from USP-V(M)-Local to the same port as the initial physical LUN (internal LUNs) from Step A.

OK, so by this time, you should have 4 physical LUNs (internal LUNs) on each USP-VM for a total of 8 LUNs. There should also be 4 virtualized LUNs on each USP-VM. So each Linux server should “see” eight LUNs, assuming a multipath setup to these LUNs is present. Now you should be able to write data to USP-V(M)-Local physical LUNs and have the remote Linux server on USP-V(M)-Remote access this data via its virtual LUNs. I like to call this the reflection of the local LUNs at the remote location. Another set of terminology we are playing with are ghost LUNs or “Casper LUNs” because they’re so friendly.

A scenario for using this configuration goes as follows;

• 1. A research department in a remote research facility writes to a file system on the local USP-VM LUNs. This is a large data set that needs to be processed at one of the corporation’s datacenters where an HPC Cluster resides which is 50 miles away.
• 2. A. This local file system can then be unmounted from the research facility ad mounted by the research facility,
• 2. B. OR the remote site can mount the ghost LUNs as read-only.
• 3. The HPC Cluster then reads the data set in a batch job and processes the data over the course of a few days.
• 4. The resulting data set is actually written to the physical LUNs on the USP-VM as a normal read/write mounted file system.
• 5. The remote research facility can read the ghost LUNs on the local USP-VM by either
• 6. A. unmounting the remote USP-VM file system and mounting the local USP-VM file system
• 6. B. OR, mounting the local USP-VM file system read-only.

Obviously, the read-only mounting or unmounting and unmounting of a file system is a bit of scripting that needs to be added to the batch jobs, but this whole scenario is accomplished without copying data over the MAN distance SAN. Data is moved over the MAN-SAN, but a resident copy, even temporary isn’t performed.

Some of the next steps in this capability will include adding other software features into the mix to solve a greater range of use cases or by fanning out the access of a physical LUN to multiple USP-VMs in a core/edges model for data distribution. Stay tuned as I will continue to post updates as I experiment and test these use cases and the various configurations. Also, if you can think of a use case that includes the basic connections described in this article or with the addition of a USP-V storage software package to solve a use case or a genuine customer problem, please let me know. I will try to validate it and put it in a future post and give you the credit for suggesting it.

Page 2 of 2 | Previous page