Map to cluster volume on Linux (ncp)

[joea at j4computers.com]

This has gotten a bit, umm, silly.
 
1 volume = 1 virtual server. I get that. Fine. But that implies, to me, and some of you seem 
to be saying it works, is that, I can move the volumes (resources), from node to node and still 
see the volumes by referencing the virtual server. Fine, that's what I want. Seems obvious it 
should be so.   But, frankly, I hear some of you saying this is not what to expect.
 
I'd like us all to be on the same page.  Let me lay this out again.

I have a two node cluster. N1 and N2. Two resources, R1 and R2. Two VNCP objects 
VNCP1 and VNCP2. 

To start -
Resource R1 exists on node N1 and is bound to VNCP1. I see it on VNCP1. 
Resource R2 exists on node N2 and is bound to VNCP2. I see it on VNCP2. 

Then-
If I migrate R1 to node N2, the unload script (running on N1) will unbind VNCP1 from R1's IP, 
and stop R1. The load script (running on N2) will bind R1's IP to VNCP1 and start R1. 

The load script says
. . .blah . . .
ncpcon bind --ncpservername=VNCP1  --ipaddress=R1's_ip_address
. . .more blah. . .
 
The unload script says
. . .blah . . . 
ncpcon unbind --ncpservername=VNCP1 --ipaddress=R1's_ip_address 
. . .more blah. . . 

Are we still together on this? Anything wrong there? 

Now, please tell me what I should expect to see in the Virtual Servers.  I would 
expect that VNCP1 should continue to show R1 and the associated volumes, 
allowing for some "brief" period of non connectivity. 

However, that is not what happens. Here. VNCP1 is now "empty" and VNCP2 
(previously created for R2 and bound to it's IP), now shows both R1 and R2.  (I would 
not care, if it continued to show in VNCP1, as well.)

Has anyone done this, successfully, and if so, how? Please, no more examples, analogies, 
"I've always done it on NetWare", etc.,  lest I go over the edge, (hmm.  . .) just concise 
response, in line, to what I have laid out. 

I thank everyone for their tolerance and softspoken-ness.
 
joe a.
 
>>> On 5/18/2009 at 10:13 PM, Peter Van Lone <petervl at gmail.com> wrote: 
> Actually I think that Bill and James are saying the same thing. 
> Resources are "served up" by virtual servers. There really should be a 
> 1 to 1 relationship: 1 volume --> 1 virtual server. 
> 
> Then, from login scripts or in any kind of a client side binding, you 
> always reference the virtual server (using either edirectory syntax 
> like .vservername.ou.ou: or I think you can also use a unc path 
> referencing the virtual server name but I don't remember now and am 
> not sure that would work with linux. 
> 
> In any event, when you reference the vserver name, it can float 
> (migrate) from host to host and the clients don't know or care which 
> physical host it is on. It is best planning practice to plan/arrange 
> for virtual servers to be spread around your cluster nodes/hosts. So 
> if I have a 3 node cluster I generally put one resource/virtual server 
> on each host. If I have more resources, then I create more virtual 
> servers and some hosts "host" more than one. 
> 
> When a physical host has one vserver, then that host's tools can only 
> "see" that one volume/resource. If that host has two, then it can see 
> two. But it really does not matter which host it is on from the 
> perspective of a non-host client because it attaches using the vserver 
> identification which is independant of the physical node. 
> 
> I've not got person experience with OES clustering, but peers do ... 
> and they are quit clear and explicit that clustering in OES works the 
> way it does in Netware. i think you have gotten yourself bundled 
> somewhere along the line, and a detail or definition has become 
> magnified in your mind, out of proportion -- so now all appears 
> distorted to you. 
> 
> p 
> 
> 
> 
> On Mon, May 18, 2009 at 9:00 PM, joea at j4computers.com 
> <joea at j4computers.com> wrote: 
>>> 
>>> This is exactly the way it works. A user mapped to a virtual resource does 
>>> not have to care. All mappings should be done based on virtual cluster 
>>> server eDirectory objects. The local resources will not be visible as 
>>> virtual cluster server eDir objects. The only way those could be 
> incorrectly 
>>> mapped is if you used server mapped volumes as opposed to eDirectory mapped 
>>> volumes. Cluster objects only exists as eDir objects. None of the local 
>>> node resources will show up as eDir cluster resources. 
>>> 
>> 
>> That may be the way you see it working on NetWare, but it does not seem to 
> work that way in Linux OES1. 
>> 
>> It works the way I described it, at least on our gear. 
>> 
>> And the way I interpret Bill's response, it differs from what you describe. 
>> 
>> joe a. 
>> 
>> 
>> 
>> _______________________________________________ 
>> Novell mailing list 
>> Novell at netlab1.oucs.ox.ac.uk 
>> http://netlab1.usu.edu/mailman/listinfo/novell 
>> 
> _______________________________________________ 
> Novell mailing list 
> Novell at netlab1.oucs.ox.ac.uk 
> http://netlab1.usu.edu/mailman/listinfo/novell