The server's incoming block processing uses file locking (fcntl under Unix, msvcrt under Windows) in the local store. Since the program creates and deletes files, rather than just modifying them, trying to lock individual files creates some nasty edge cases. Therefore there is a single lockfile in each of the 65,536 directories of the local store. Locking momentarily blocks writes to 1/65536 of the storage space.
You can run multiple servers on the same local store, using the alt_localstore configuration option. These servers must each have their own home directories, entangled stores, and ports. Since each one is doing one update at a time, there will be very little lock contention. Use a load balancer such as haproxy [ http://www.haproxy.org/ ] to map all the server ports to a single incoming port. This provides more parallelism.
You can have two sites each with multiple servers, and each server at one site has a replication partner at the other site. To the outside world this looks like a two-node replication setup, and either site can have a power failure. Your administration software will have to handle calling ADDLOGIN and RMLOGIN on one node of each pair to create and delete accounts. Account create/delete is replicated within replication pairs, but if multiple servers are serving the same local store, each server or replication pair will need accounts to be created.
You can also subdivide the local store onto multiple storage devices by using symbolic links on the first level of the store. For example, map 00-3F to one device, 40-7F, to a second, 80-BF to a third and C0-FF to a fourth. These devices can be NFS mounts so that the storage is spread across multiple servers. Using some combination of NFS, symbolic links, and load balancers, you can handle any workload while appearing to have only two nodes.