Pyro has limited support for failover scenarios. One of the key design principles is to keep it simple. This means that there is a way of automatically reconnecting a client to a server if the server went down, but not much else. If a server goes down, you'll have to recover from that yourself. Pyro mostly just provides an object oriented network communication abstraction, the machinery to deal with managing your servers (and clients) needs to come from somewhere else.
This also holds for the name server. If it goes down, you're responsible to somehow detect that and recover from it. You can use Pyro without its own name server if you don't need logical names.
The name server can use a persistent store so that it won't lose the data if it goes down. The provided data stores have not been designed for concurrent use by multiple name servers at the same time. You may have to build a more fault tolerant storage backend yourself if you need this (the storageprovider is pluggable).
You may want to focus on a stateless server design if failover (and horizontal scaling) is a primary concern. But this is not something Pyro explicitly provides or enforces.
Perhaps the above is enough for your application? If not, you will have to add further fault tolerance yourself or by use of other tools.
I cannot answer your second question. I don't know what you consider a 'large production system' and I myself don't really know how or on what scale the current users of Pyro make use of the library.