Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 03 Jun 2013 06:39:57 -0400
From:      Michael Powell <nightrecon@hotmail.com>
To:        freebsd-questions@freebsd.org
Subject:   Re: Max top end computer for Freebsd to run on
Message-ID:  <kohrpp$nc4$1@ger.gmane.org>
References:  <51ABAC4D.4040302@a1poweruser.com> <51ABB457.5060205@gmail.com> <CAD4099=yEL+7BSbpUrBA2s69cHB1vEC54W-vZZmdpUzN-2z_qA@mail.gmail.com> <51AC00D9.4030502@hdk5.net>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Al Plant wrote:

> James wrote:
>> Several modest servers applied well will take you further than one b=
ig
>> iron=97and for less cost.
>=20
> James I agree. I have witnessed the benefit of what you say. Putting
> your faith in one big server can be a problem if the box fails,
> especially hardware failure.
>=20
> Keeping a spare server in a rack that can be switched in to service
> quickly can save you if one dies. Time (waiting for parts), most
> failures are hardware if your running FreeBSD. Even most Linux boxes.=

>=20

There are 2 approaches, and applying both together is what I favor. Sca=
le up=20
(vertical) is a horsepower per box kind of thing. Scale out (horizontal=
)=20
adds more of the same kind of box(es) in parallel. The resulting redund=
ancy=20
will keep you up and online.

Sizing matters somewhat. Having excess horsepower that sits unused is e=
xtra=20
money spent on one box that could have been applied to scale out redund=
ancy.=20
If you can size one machine to match your current and projected workloa=
d,=20
then if there are two, or more, of these and one fails the remaining ca=
n=20
shoulder the load while you get the broken one back up.

Where the balance point is struck will depend on workload. Let's say=20=

(hypothetical) one box as a web/database server can handle 1,000=20
connections/users per second within desired latency and response time. =
If a=20
spike in demand suddenly comes that box will slow to a crawl (or even f=
all=20
over) as it tries to keep up, as it is lacking the extra horsepower ove=
rhead=20
that would otherwise be sitting idle if it did. Scaling out (horizontal=
ly)=20
by adding more boxes will distribute this spike across multiple machine=
s and=20
remain within the desired processing response/latency time so together =
they=20
can handle 2,000 when the need is present. Need another 1,000? Add anot=
her=20
box, and so on.

So the trick is to understand your workload. Don't go overboard on just=
 one =20
huge high-power machine which sits mostly idle and takes you offline if=
 it=20
fails. Spend the money on more moderately sized boxen. Me, I like to ha=
ve at=20
least 3 of everything (if I can) such that they are sized so that 2 of =
them=20
together can easily handle the desired load. The third one is for redun=
dancy=20
and the 'what-if' spike in demand.

Another advantage here is you can take one offline for updates, then pu=
t it=20
back online and test it out for problems. If there is no problem then y=
ou=20
can take one of the other two down and update it. This way you can do=20=

updates without your service being offline. But the trick is still to=20=

understand your specific workload first, then spread the money around=20=

accordingly.

-Mike





Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?kohrpp$nc4$1>