Absent Member.
Absent Member.
2038 views

How to combine separate filesystems for a single drive map?

Is there a way to have separate filesystems combined in mount points to look like a single high-level filesystem for mapping a single drive letter?

We previously split up our shared business groups filesystems because they became very big. This was to reduce the outage if a host server failed and to divide and distribute the work of data back-up clients and anti-virus utilities. A consequence was a complicated set of eDir objects (DirMaps, Aliases, profile log-in scripts, confusion documentation, etc.) to support a user from one business group getting an additional drive mapping to a different business group's shared files. Going to SLES/OES we want to be free to keep the filesystems separate but now have a way of presenting all the business group shares back into a single filesystem. Ideally, everyone gets the same drive mapping to the base of the organization shared folders and access is controlled simply by group memberships (which would be natural for a smaller single filesystem).

Thanks!
Labels (2)
0 Likes
6 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

KentFSmith;2208941 wrote:
Is there a way to have separate filesystems combined in mount points to look like a single high-level filesystem for mapping a single drive letter?

We previously split up our shared business groups filesystems because they became very big. This was to reduce the outage if a host server failed and to divide and distribute the work of data back-up clients and anti-virus utilities. A consequence was a complicated set of eDir objects (DirMaps, Aliases, profile log-in scripts, confusion documentation, etc.) to support a user from one business group getting an additional drive mapping to a different business group's shared files. Going to SLES/OES we want to be free to keep the filesystems separate but now have a way of presenting all the business group shares back into a single filesystem. Ideally, everyone gets the same drive mapping to the base of the organization shared folders and access is controlled simply by group memberships (which would be natural for a smaller single filesystem).

Thanks!


Assuming these are NSS file systems, you can use DFS to join everything together in a combined view from a client/NCP/CIFS perspective, whilst your backups still backup each volume individually.

Example:

We had a login script map an "L" drive to:
\\server\data3

The volume held a directory for each division.

Eventually it became too large to handle (2 TB for backups, etc.)

We then created a bunch of other volumes:
data3a, 3b, etc.

moved/copied/transferred/split the top-level directory to each volume and then used DFS to create junctures to the other volumes.

So the users still see:
L:\DATA3\DIR1
L:\DATA3\DIR2

etc

They don't know that in reality, this data is all over the place (17 diff. servers/volumes)
0 Likes
Absent Member.
Absent Member.

Thank you! That sounds like just what we want to do, and it sounds like enough information to direct us as we look into this. Me happy! -Still would love to hear any other suggestions or experiences.
0 Likes
Cadet 1st Class Cadet 1st Class
Cadet 1st Class

DFS requires that the client be aware of and traverse the various servers, with DFS Junctions being glorified symbolic links that say "Oh, you want folder Foo? Oh Foo is really //OtherServer/OtherVolume/Foo. This works well, but requires that DFS be understood by all the clients involved. It works well in most cases. In the olden days ( last week? ) DFS was supported on only a couple clients, and some Novell services didn't understand it. This has beein improved with newer OES releases. DFS junctions is relatively harmess - you are unlikely to break things.

The alternative is DST, which takes two volumes and creates a merged view, ( an entirely new NCP volume ) which contains the contents of both. This is transparent to the client, which just thinks its an ordinary volume. In this case the DFS server acts like an NCP proxy, cherry picking which file comes from which volume. Its like DFS, but inside out. But it can be an "active principle" which manipulates the underlying volumes. Things like quotas in the merged view, and available space, and so on may be odd looking. But most services and clients can understand the merged volume, and so may be more compatible with whatever you need to do....

The advantage of DST is that it can act like a HFS solution, where you can migrate files based on size, age, etc... to one volume or another. This provides a nice disaster recovery feature, in that you can restore the volumes independantly, putting back frequently used files first but restoring the volume they live on.

If you have many volumes, DFS may be better. If its just 2, perhaps DST would work and offer different benefits. The OES documentation has a section on both ...

-- Bob
0 Likes
Fleet Admiral
Fleet Admiral

Bob-O-Rama;2208993 wrote:
DFS requires that the client be aware of and traverse the various servers, with DFS Junctions being glorified symbolic links that say "Oh, you want folder Foo? Oh Foo is really //OtherServer/OtherVolume/Foo. This works well, but requires that DFS be understood by all the clients involved. It works well in most cases. In the olden days ( last week? ) DFS was supported on only a couple clients, and some Novell services didn't understand it. This has beein improved with newer OES releases. DFS junctions is relatively harmess - you are unlikely to break things.


With DFS client support is the key thing - naturally being a Windows/SMB thing Windows clients support it whereas not all Mac and Linux clients do. For Macs it was only with OS X Lion that DFS support was added, before that you needed a third-party product.

HTH.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Doh, I totally forgot about DST!

Bob's correct that may be better for you

We actually use BOTH Together

So not only do I have DFS all over the place, but then I also use DST on the DFS targets because the users see "more disk space" and promptly fill it up with --er--stuff.

🙂
0 Likes
Absent Member.
Absent Member.

Thank you for sharing your experience!
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.