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