In large enviroments you expect the load being balanced among the UCS Master/Backup/Slave servers but your master server is very busy with Samba and OpenLDAP processes while your other server are idling.
In your environment you have several UCS servers as member server installed. Member server do not have a local authentication database and therefore have to forward all authentication requests to a master, backup or slave server. By default, the master server is used for authentication according to the following default values of the UCR variables:
ldap/server/name: master.multi.ucs Several LDAP servers can be operated in a UCS domain. The primary one is specified with this variable. Further servers are specified via 'ldap/server/addition'. ldap/server/addition: backup.multi.ucs Several LDAP servers can be operated in a UCS domain. The primary one is specified with 'ldap/server/name'. Further servers are automatically managed by a Listener module through this variable.
So all member servers simply requested authentication information from the master while the other server did never get any requests.
UCS has ucr variables on member servers configuring the servers to be used for authentication purpose. Tell your member servers manually which server to use. To reduce the load on the master it is recommended to balance between slave (preferred) and backups (as secondary). But this depends on the number of servers in your environment.
root@member:~ # ucr set ldap/server/name=slave.multi.ucs root@member:~ # ucr set ldap/server/addition=backup.multi.ucs
Set your variables on the member servers to archieve some sort of load balancing as shown above.
Note: This affects only authentication, not LDAP synchronization! The synchronization between the servers is considered to be balanced already.