Highlighted
Anonymous_User Absent Member.
Absent Member.
1755 views

SAN copy and trustee assignments

We have a EMC CX500 and are about to put a second one in to a DR site. We
plan to use SAN copy to replicate the data to the DR. My question is will
this replicate the trustee assignments? If not, what are people using to
set them the same as the primary site?
Labels (1)
0 Likes
13 Replies
Anonymous_User Absent Member.
Absent Member.

Re: SAN copy and trustee assignments


that's an interesting question and it kind of depends on how you're
doing the cluster.

i should ask the dell/emc guy when i talk to him about the same thing
tomorrow.



--
Cheers!
Richard Beels
~ Network Consultant
~ Sysop, Novell Support Connection
~ MCNE, CNE*, CNA*, CNS*, N*LS


0 Likes
Anonymous_User Absent Member.
Absent Member.

SAN copy and trustee assignments

> We have a EMC CX500 and are about to put a second one in to a DR site. We
> plan to use SAN copy to replicate the data to the DR. My question is will
> this replicate the trustee assignments? If not, what are people using to
> set them the same as the primary site?


Hi,

EMC SANCopy is a block-based copy tool. The actual File system is
irrelevant. It does not matter what type of data is on your SAN, it will be
copied over 2 your new one. This means your file system rights will still
be there. Don't forget File system rights and eDirectory Trustee Ricghts
to the Object are 2 very different things. You should look into EMC
Mirrorview. This will allow you to have a real-time Mirror of your
production-SAN in your DR envirnoment. Mirrorwiew is LUN based, so you
should not have one NSS Pool spread over 2 LUNs. It's possible, but can
lead to problems when you upgrade or migrate to new hardware (Some EMC
boxes allow MetaLUNs). You should think about using SANcopy for DR
purposes. You should also look into Novell's Business Continuity Cluster (BCC).

Hope this helps. Of course I can only suggest that you confirm this
information with your Vender/Hardware manufacturer.

Mike


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SAN copy and trustee assignments

For the best solution, you'll really want MirrorView/Synchronous. This a a
byte-for-byte block-level mirror of the LUNs to the DR site.

Then, at the DR site, you also have some of the members of your cluster. If
the production site is distroyed, the DR site has an exact mirror and the
cluster nodes at the DR site can take over for the failed systems.

best,
Jeff


<alan1033@aol.com> wrote in message
news:dBLMf.9465$yg2.6346@prv-forum2.provo.novell.com...
> We have a EMC CX500 and are about to put a second one in to a DR site. We
> plan to use SAN copy to replicate the data to the DR. My question is will
> this replicate the trustee assignments? If not, what are people using to
> set them the same as the primary site?



0 Likes
Anonymous_User Absent Member.
Absent Member.

SAN copy and trustee assignments

Hi,

Thanks for your responses. I would like to run our current setup/plan by
you to get your comments. I have a 3 node 6.5 cluster for file/print,
running on an EMC CX500. The DR solution is to have another EMC CX500 and
a single 6.5 server (not part of the cluster) at our DR site. Data changes
would be replicated to the DR SAN using SAN copy. If we have to fail over
to DR I planned to redirect users to the single 6.5 server and DR SAN (via
login script) Does this sound a feasible option. The other idea I had was
to extend the 3 node cluster to include the single DR server. At the
moment I do not have the budget to purchase Mirror View. Also I have a 3GB
link to the DR site.

Thanks in advance for your comments

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SAN copy and trustee assignments


you want to have the remote site _in_ the same cluster. that way, all
rights and login scripts an everything is seamless.

sync copy will be better than async. it's a pay forit now or pay for
it later kind of thing, IMO.


--
Cheers!
Richard Beels
~ Network Consultant
~ Sysop, Novell Support Connection
~ MCNE, CNE*, CNA*, CNS*, N*LS


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SAN copy and trustee assignments


well, a stretch cluster is definately better. some say that BCC is
"best" but a> it's a 1.0 product and b> I can't get anyone from Novell
to tell my why it's better than a stretch cluster (other than just
refer me to the camparo page in the BCC docs)...


--
Cheers!
Richard Beels
~ Network Consultant
~ Sysop, Novell Support Connection
~ MCNE, CNE*, CNA*, CNS*, N*LS


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SAN copy and trustee assignments

Jeffrey D Sessler wrote:

> you'll really want MirrorView/Synchronous.


unless you are using Novell's BCC - then you want Mirrorview/Async

--
Joe Moore
Novell Support Forums SysOp
http://just.fdisk-it.com
http://www.caledonia.net/jmdns.html
http://www.caledonia.net/nesadmin.html
http://www.caledonia.net/jmttb.html
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SAN copy and trustee assignments

Hi thanks for your comments, I’m a bit confused.

If I make the remote site server part of the primary site cluster, would
you suggest attaching both the SANs to the cluster? I can’t get my head
round the remote sever attaching to the primary SAN. Or is this the sort
of design you was thinking: A 4 node stretched cluster 3 nodes at the
primary site 1 at the remote. The 3 nodes are attached to the primary SAN
and the 1 remote node attached the BC SAN. I can’t see how I can failover
the user’s mappings from the primary SAN to BC SAN without a login script
change which re-maps to the BC volumes. Am I missing something here?

This goes back to how are the trustee assignments going to work on the BC SAN?



0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SAN copy and trustee assignments


Think of it like a simple, two disk, mirrored set. The OS has no idea that
there are actually two disks there, and either disk can fail but the system
stays up.

With MirrorView, you're creating mirrors of your LUNs between two CX 500's
and the software in the SAN presents only a single LUN back to the host OS.
Either of the two SAN's can fail and the host will still see the single LUN.

If the primary site is destroyed, the cluster node(s) in the DR site will
mount the resources and keep on going.

jeff

<robm1@dsl.pipex.com> wrote in message
news:KipNf.1378$oh5.155@prv-forum2.provo.novell.com...
> Hi thanks for your comments, I'm a bit confused.
>
> If I make the remote site server part of the primary site cluster, would
> you suggest attaching both the SANs to the cluster? I can't get my head
> round the remote sever attaching to the primary SAN. Or is this the sort
> of design you was thinking: A 4 node stretched cluster 3 nodes at the
> primary site 1 at the remote. The 3 nodes are attached to the primary SAN
> and the 1 remote node attached the BC SAN. I can't see how I can
> failover
> the user's mappings from the primary SAN to BC SAN without a login script
> change which re-maps to the BC volumes. Am I missing something here?
>
> This goes back to how are the trustee assignments going to work on the BC
> SAN?
>
>
>



0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SAN copy and trustee assignments


instead of thinking of attaching SANs to a cluster, think of it this
way.

You have a fibre channel "fabric" (which is geek-speak for a fibre
channel network). On that fabric, you have 2 SANs and multiple file
servers (configured in a cluster). The two SANs will mirror each other
- just like duplexed disks in a file server mirror each other.

To the NOS, it sees diskspace not he SAN just like it would see
diskspace in a local drive - the only real difference is that the commo
is via the HBA instead of the SCSI card - it doesn't know where the
disk is.

Two SANs mirroring each other is no different really than having 2 SCSI
cards in a file server, each with an array of disks; except that the
SANs keep themseves in sync. You configure the HBAs (or the SAN) to
present one set of disks to the OS. If one of the SANs dies, the other
takes over - just like regular mirroring or duplexing would. The OS
never knows that one of the SANs died.

Another way to think of it is like RAID5 - the OS doesn't care if one
drive in the array dies, since the array stays up. Mirrored SANs are
like that - if one dies, the fabric routes to the surviving SAN and the
OS is none the wiser...


--
Cheers!
Richard Beels
~ Network Consultant
~ Sysop, Novell Support Connection
~ MCNE, CNE*, CNA*, CNS*, N*LS


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SAN copy and trustee assignments

Thanks for the explanation, that makes it sound much clearer now. 1 other
question, if I was using SAN copy to replicate to the other SAN every
30mins, would it work with this setup or do I have to use mirror view?

Thanks again for your help on this

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SAN copy and trustee assignments

Has to be mirror view to be transparent.

Jeff

<robm1@dsl.pipex.com> wrote in message
news:wW1Pf.4941$oh5.3804@prv-forum2.provo.novell.com...
> Thanks for the explanation, that makes it sound much clearer now. 1 other
> question, if I was using SAN copy to replicate to the other SAN every
> 30mins, would it work with this setup or do I have to use mirror view?
>
> Thanks again for your help on this
>



0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: SAN copy and trustee assignments


mirrorview is required to "fool" netware.

you can run mirrorview in either sync or async mode.


--
Cheers!
Richard Beels
~ Network Consultant
~ Sysop, Novell Support Connection
~ MCNE, CNE*, CNA*, CNS*, N*LS


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.