1 |
On Mon, Aug 19, 2002 at 12:22:38AM +0100, Colin Morey wrote: |
2 |
> Do we have a defined number of minimum connections a server should |
3 |
> allow? or are we basing on an had hoc basis, based upon transit and |
4 |
> availability as well? |
5 |
|
6 |
That is an excellent question, and one I've yet to find a good answer |
7 |
for. It is my opinion that we cannot afford to be too picky when |
8 |
someone offers their services to us, but it also doesn't help to have |
9 |
servers out there that can't perform. Unfortunatly, I've been too busy |
10 |
with life to give this matter much thought. |
11 |
|
12 |
The way I see it, we have three basic requirements for rsync mirrors. |
13 |
|
14 |
1. Enough available bandwidth to serve a substantial amount of data. |
15 |
|
16 |
2. Accurate and timely data. |
17 |
|
18 |
3. Sufficient number of simultaneous logins to allow enough people to |
19 |
actually use the mirror. |
20 |
|
21 |
I would suggest that the mirror have at least a T1 of available |
22 |
bandwidth. It doesn't have to dedicate the entire T1 to rsync |
23 |
mirroring, but if all they have is ISDN, DSL, or cable, then they aren't |
24 |
going to be pleased with rsync using all of their bandwidth. I would |
25 |
suggest a minimum 128kb/s of available bandwidth for rsync bandwidth on |
26 |
a mirror. This number would be better at 256kb/s, but 128kb/s should be |
27 |
usable. |
28 |
|
29 |
Some method needs to be developed for making sure that mirrors are updated |
30 |
in a timely fashion, and have accurate copies of the master. There have |
31 |
been several reports of out-of-date and bad data on mirrors. Right now, |
32 |
we have people updating their mirror every 30 minutes on the 0 and 30. |
33 |
This will quickly become inadequate if we continue to grow our number of |
34 |
mirrors. Keeping an infrastructure like this healthy as it grows will |
35 |
probably be the biggest task this admin team will face. I have lots of |
36 |
ideas on this, but they can wait until we get some basic parameters down |
37 |
for mirrors. Right now, it should be sufficient to develop an automated |
38 |
system that checks for inaccurate and out of sync mirrors. |
39 |
|
40 |
The third item seems to be the big point everyone is interested in, and |
41 |
in my opinion the least of our worries. However, I'm tired of hearing |
42 |
people whine about it so I've given it some thought. This ties into |
43 |
item one since the more people you have using a server, the more |
44 |
bandwidth you need. I think we should have ratios of bandwidth to |
45 |
max concurrent users. Maybe 5 users for every 128kb/s of available |
46 |
bandwidth. Basically, to determine these numbers we need to determine |
47 |
the average user's rsync transfer, and come up with an average sustained |
48 |
data rate for an rsync transfer. |
49 |
|
50 |
Now, these are just my opinions. What do y'all think? |
51 |
|
52 |
Damon/kabau |