We need multiple servers per node for failover.
I hate to require TCP/IP just for configuration.
Rob
Sam Lang wrote:
On Jun 20, 2007, at 11:38 AM, Murali Vilayannur wrote:
Hi Sam,
Hmm...well if the server config file isn't specified, why can't the
server just get the hostname instead of requiring an alias?
hmm.. For one that may not work if you run multiple servers on the
same machine
since their hostnames would be identical, no?
That's true. The multiple servers per node stuff was added to genconfig
just for debugging. I can't think of any good uses for that in
practice. Are there? If not, we might be able to get away with just
using a -p <port> argument in cases where multiple servers/host is desired.
Yeah I was thinking that if a server config was specified as the
second argument to the pvfs2-server, the server would go ahead and
use those values for endpoint, storage location, logfile, etc.
We could still keep all the old code intact and do this parsing if you
are worried that people's scripts etc would break.
Maybe its not a big deal -- and we make people change their scripts and
config files. That's certainly easier/cleaner.
Definitely still interest. I'm not sure we've come up with an
approach yet. I would argue a first step toward zero conf would be
encoding/decoding the config using the lebf encoding layer. This
would give us a more efficient representation of the config, as well
as make it easier to modify at runtime.
I was thinking of a very simple approach.
All machines run portmapper & support tcp/ip (especially since they
presumably also require NFS)..
I don't know about NFS being required, but requiring tcp/ip is probably ok.
How about if we write a simple RPC stub with a fixed PVFS specific
program number and export a single interface to push the config file
and aliases to all servers?
Servers startup will create a thread that binds to any available port,
registers the port, program number with portmapper and prevents any
further initialization until it gets the config file params.
We write a tool that pushes these to each server by querying the
portmapper for the port.
Pushing such values is implicitly a SIGHUP equivalent. The server
reloads/parses its config files and sets itself up. The RPC thread
continues to listen for updates on the ephemeral port in the meantime
until the server process dies..
This is an interesting idea, and allows us to leverage infrastructure
that's already on most systems.
It seems just as easy though to give each server a master endpoint to
send his host,port,etc. config info there. That avoids a tcp/ip and
portmapper dependency doesn't it? There's a startup issue, but servers
could retry until they succeed.
It also alleviates the need to have an admin tool that queries all the
portmappers on all the hosts for all the server ports, and pushes that
info back to all the servers.
-sam
thanks,
Murali
-sam
> thanks,
> Murali
>
> On 6/19/07, Sam Lang <[EMAIL PROTECTED]> wrote:
>>
>> Hi Murali,
>>
>> Just never got around to commit it. My only complaint is that it
>> doesn't allow the server to optionally take a server config file (for
>> legacy scripts, etc.). I think that might be hard to implement
>> though...
>>
>> -sam
>>
>> On Jun 20, 2007, at 1:19 AM, Murali Vilayannur wrote:
>>
>> > Hey Sam,
>> > Any interest in merging this patch to unify config files while
>> > starting up pvfs2 servers?
>> > I have reworked it against HEAD..
>> > Relevant thread..
>> > http://www.beowulf-underground.org/pipermail/pvfs2-developers/2007-
>> > February/003209.html
>> > thanks,
>> > Murali
>> > <unify-config-files.patch>
>>
>>
>
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
