[7] in Kerberos
Kerberos Servers
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:12:30 1987
From spm@ATHENA.MIT.EDU Fri Jun 13 15:58:31 1986
To: saltzer, ostlund, kelley, jis, bcn
Cc: spm
Subject: Kerberos servers
Date: Fri, 13 Jun 86 15:57:02 -0500
From: Steve Miller <spm@ATHENA.MIT.EDU>
Some of us have been discussing alternate means of providing
a highly available Kerberos service, and I believe that this issue
needs to be pondered for a while.
The most direct approach is to put a kerberos server in each cluster,
thus insulating each cluster from gateway and backbone problems.
The drawback with this solution is that it requires a lot of servers
(and $$), each of which ought to be more secure physically than we
currently can provide, and each of which needs to be updated and
managed.
In terms of the workload on Kerberos, I estimate that with 2000 workstations,
except for brief periods of bursty load (26-100 empties into the adjoining
terminal room), three or four uvax2 class servers will provide sufficient
service. Each should be able to handle 3-5 requests/second, with a typical
request asking for 3 tickets. Once routine logging for debugging is turned
off, the limiting factor is software encryption time.
We will have much more than 4 clusters.
I would propose, as a long term alternative, that instead of spending
the equipment money on a Kerberos server per cluster, we install only
3 or 4 Kerberos servers, judiciously located, and that the extra equipment
budget go towards providing a more redundant network, e.g. two
gateways per cluster. This would provide higher availability for all
services, not just Kerberos.
Of course, just providing the gateways is not adequate if the backbone is
not highly reliable, but I suspect sooner or later the backbone will for
many reasons have to become highly reliable.
In the interim, Pete and John are considering the one per cluster approach,
since it is in the realm of what they can do, and do quickly.
