Now, I can create a replicated volume on multiple servers, but can I
create a non-replicated volume which spans on multiple servers. ( ie.
each server contains the different subtree of the volume )
Thanks.
-----Original Message-----
发件人: Jan Harkes <[EMAIL PROTECTED]>
收件人: [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
日期: 1999年9月12日 7:15
主题: Multiple coda servers
>On Sat, Sep 11, 1999 at 01:54:56PM -0400, [EMAIL PROTECTED] wrote:
>> I do have some other questions:
>>
>> In AFS, every cell is under the /afs. Does coda do the same thing?
>> If I install the server on a nother pc, and build another volume,
>> will both show up under /coda? or do I have to do something on the
>> SCM to make that happen? Can I change which machine is SCM? And if I
>> can, how?
>
>Coda currently has no support for importing other administrative cells
>into it's local namespace. (aka. mounting volumes from some other Coda
>installation into your own tree).
>
>However, it does support multiple servers within one administrative
>cell. And volumes can be replicated across several servers.
>
>To go from a single server Coda setup to a multiple server Coda setup is
>relatively painless if you follow the following steps. Maybe this is
>even documented in the Coda-HOWTO, if it isn't it probably needs to be
>added.
>
>- On the SCM, add to /vice/db/servers the name of the new server, with a
> new unique server-id (in the range 1-126 or 128-254, the reason why is
> one of the few things in the FAQ on the Web).
>
>e.g. /vice/db/servers
> 1 SCM
> 2 NewServer
>
>- Also on the SCM add new volume-server-groups to /vice/db/VSGDB.
> This defines which servers are responsible for storing volume
> replicas. A volume can at most be replicated across 8 servers, it is
> theoretically possible to resize/shrink VSG's, but nobody has
> succesfully done so.
>
> The numbers are interpreted as hexadecimal, and seem to have once been
> used as multicast IP-addresses, that's why they start with E0 == 224
> == multicast ip. Multicast support is present in rpc2, but unlikely to
> work.
>
>e.g. /vice/db/VSGDB
> E0000100 SCM
> E0000101 NewServer
> E0000102 SCM NewServer
>
>- Install your second server, and at the question "Is this the master
> server, aka the SCM machine? (y/n)", answer `n'. And finish the setup
> by giving the hostname of the SCM, and configuring RVM.
>
>- Start the update client on the new server, on a redhat installation
> this is done by:
> /etc/rc.d/init.d/update.init start
>
>- Check whether the files in /vice/db are updated. Otherwise restart the
> updatesrv on the SCM (/etc/rc.d/init.d/update.init stop; ... start).
> When the prot_users.db etc. files have appeared, everything should
> be ready to start the auth2 daemon and the codasrv on the new server.
>
>Creating volumes is still done on the SCM, but you should pass another
>VSG identifier to the createvol_rep script.
>
>e.g.
> createvol_rep replicated E0000102 /vicepa
> # creates a replicated volume on both SCM and NewServer, according
> # to the VSGDB show earlier.
>
>If you want to move the SCM, put the hostname of the new SCM in
>/vice/db/scm, and after this file has propagated, stop updateclnt,
>updatesrv and the auth2 daemon on all machines. Then simply restart all
>updateclnt, updatesrv and the auth2 daemons. Maybe check if /vice/db/scm
>is correct before actually restarting them.
>
>The codasrv itself doesn't care whether it is an SCM or not, the other
>daemons have to know it because of the simple replication technique of
>copying the files in /vice/db from the SCM to the other servers.
>
>Jan
>
>
