(Illustration by Gaich Muramatsu)
On Mon, Mar 19, 2001 at 05:41:16PM +0100, Emmanuel Varagnat wrote: > > I've got some questions about > - How did the Coda client choose the server to speak with, > and is there a sort of load balancing mechanism, or the (or > every) client is/are always talking the same server, as soon > is always reachable ? In venus.conf there is a list of 'rootservers', these servers are queried for what volume is the root-volume of a cell. These are also the servers that are used for all volume replication and location information requests. Once a client knows on which server-group a volume is hosted, it connects to all servers in the group. Effectively all requests are sent to every replica of the volume, however, bulk data transfers (i.e. file/directory fetch) are only sent back from the strongest host, where strongest is the host for which the bandwidth estimate was the highest at the end of the previous operation. Coda's replication strategy is a modified write-all/read-any. Because we still allow writes to succeed when not all servers in a replication group are available, we need to validate the version vector with all available servers to detect possible server-server conflicts. However, once we know there is no conflict, the actual data can be pulled from any of the available servers. > - I'm not to have well understand the way Coda share data. > Within a cell, every server share the same data. So there > is no way to extend the total amount of data available > by adding a new server ? The only way is to add a disk > or a partition in each server of the cell ? No, within a Coda cell there are many "replicated volumes". These volumes are replicated across a "volume storage group (VSG)". The VSG is a group of servers as defined in the VSGDB during volume creation which are all responsible for holding the data of a "volume replica". Or in other words a replicated volume is a logical thing that actually consists of one or more volume replicas which are stored on servers. Which servers actually hold the volume replicas is defined by the volume storage group at the time a volume is created. There are still some places in the code where the VSG is accessed later on, so at the moment it isn't too smart to modify an existing VSG definition once any volumes are created for it. So a cell could have 6 servers that are members of several VSGs, E000100 server1 server2 server3 # VSG for triply replicated volumes E000101 server4 server5 # VSG for doubly replicated volumes E000102 server6 # VSG for singly replicated volumes E000200 server1 server4 server6 # another triply replicated VSG Now any volumes created as "createvol_rep volume E000100" are stored on server1, server2, server3, etc. Adding a partition is no real problem, the VSG's stay the same, newly created volumes just need to be given the correct partition identifier (default is /vicepa, now it will possibly be /vicepb). Adding a new server implies creating new VSGs that incorporate this server. E000300 server7 # VSG for just the new server E000301 server6 server7 # VSG for volumes replicated # across servers #6 and #7 etc. JanReceived on 2001-03-19 14:59:28