On 6/15/2018 9:52 AM, Andreas Ladanyi wrote: > ok. so the process of change CellSrvDB on db servers and bos restart AND > updating (copying) new CellServDB to clients has to be done in a very > short time to minimize timeout symptoms for users, because db servers > has to be in sync and ubik coordinator has to be elected and the afs > clients with new CellServDB with the new db server (lowest ip) asks the > new db server (ubik coordinator) first.
The ubik clients do not rank servers based upon IP address. What they
do is:
1. compute the length of the ordered server list
A B C D
2. then generate a random number from 0..<length - 1>
3. use that number as an index into the list to decide which is first
4. and reorder the list as if it were a circular queue. So if the
random number selected was 2, then the list would become
C D A B
The only time the coordinator must be contacted is for a write
transaction. All read transactions are processed by the first server
contacted.
My conclusion is that there is something about your cell configuration
that results in a write transaction for each token requested. For example:
1. cell name: example.com
2. One of the following is true:
a. realm name: AD.EXAMPLE.COM
b. CellServDB's zeroth ubik server host domain:
subnet.example.com
3. auto-registration of foreign PTS IDs enabled:
a. pam_afs_session configuration doesn't disable it
b. aklog executed without -noprdb
If the "realm of cell" guessing algorithm decides that the current login
is likely to be a foreign cell login, then an attempt to allocate a PTS
ID for the authentication name will be performed. This request is a
write transaction and the ubik client will attempt to contact every ubik
server in order until the coordinator is determined.
Jeffrey Altman
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
