Al Plant wrote: > James wrote: >> Several modest servers applied well will take you further than one big >> iron—and for less cost. > > 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. > > 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. >
There are 2 approaches, and applying both together is what I favor. Scale up (vertical) is a horsepower per box kind of thing. Scale out (horizontal) adds more of the same kind of box(es) in parallel. The resulting redundancy will keep you up and online. Sizing matters somewhat. Having excess horsepower that sits unused is extra money spent on one box that could have been applied to scale out redundancy. If you can size one machine to match your current and projected workload, then if there are two, or more, of these and one fails the remaining can shoulder the load while you get the broken one back up. Where the balance point is struck will depend on workload. Let's say (hypothetical) one box as a web/database server can handle 1,000 connections/users per second within desired latency and response time. If a spike in demand suddenly comes that box will slow to a crawl (or even fall over) as it tries to keep up, as it is lacking the extra horsepower overhead that would otherwise be sitting idle if it did. Scaling out (horizontally) by adding more boxes will distribute this spike across multiple machines and remain within the desired processing response/latency time so together they can handle 2,000 when the need is present. Need another 1,000? Add another box, and so on. So the trick is to understand your workload. Don't go overboard on just one huge high-power machine which sits mostly idle and takes you offline if it fails. Spend the money on more moderately sized boxen. Me, I like to have at least 3 of everything (if I can) such that they are sized so that 2 of them together can easily handle the desired load. The third one is for redundancy and the 'what-if' spike in demand. Another advantage here is you can take one offline for updates, then put it back online and test it out for problems. If there is no problem then you can take one of the other two down and update it. This way you can do updates without your service being offline. But the trick is still to understand your specific workload first, then spread the money around accordingly. -Mike _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
