db servers separate hardware

[Patty OReilly]

Thanks everyone for your input. My thoughts are that we need at least 3 db
servers for Ubik to work right otherwise we may find ourselves in a
situation with only read ability and no updates. Also, if availability and
speed is a requirement, we should separate the services. In the end,
management will decide and we will have to live with it. I don't think
money is an issue. They are just bent on reducing the number of servers
in the datacenter ;) .


On Wed, 13 Jun 2001, Paul Blackburn wrote:

> Date: Wed, 13 Jun 2001 20:59:55 +0100
> From: Paul Blackburn <mpb@hursley.ibm.com>
> To: info-afs@transarc.com
> Subject: Re: db servers separate hardware
> 
> Patty,
> 
> In my experience, the issues to consider are:
> 
> a) Do we want to provide users with optimum service from the db servers?
>     If yes, then it makes good practical sense to run pure database servers
> 
>     running nothing else that may degradate performance.
>     All surplus processing removed leaves more compute cycles for db
> service.
> 
> b) Do we want to provide optimum availibilty/reliability for the cell?
>     If yes, then splitting out the function is a good thing (tm).
> 
>     We don't want to carry all our eggs in one basket.
>     We do want to use machines of appropriate size and capacity
>      for their function. For fileservers: plenty of disk space and high
> speed
>      network connectivity ideally located "close" to users (on the
> network).
>      For database servers: just enough disk and RAM.
> 
> c) Do we want to provide minimum downtime from system upgrades
>     and system maintenance?
>     If yes, then we should not consolidate onto fewer servers rather
>     we should ensure we have enough spare capacity to have perhaps
>     a "hot standby" db server and fileserver. This allows for a
>     "rolling upgrade": taking one server out for upgrade without
>     breaking the service.
> 
> d) There is the general "KISS" principal or Keep It Simple Stupid! ;-)
>     The more complexity we load on a machine the greater the probably
>     of problems. When you upgrade package "a" does that have
>     a knock-on effect on package "b"? Will you need to reboot
>     to apply a kernel fix for package "z".
> 
> e) To improve performance and distribute load it is better to have
>     more servers not less.
> 
> f) If a server crashes, what is the impact on users?
>    Consider the case of a cell with 3 db servers and 4 fileservers.
>    If one of the three db servers crashes the cell continues
>    to run with minimum degradation: all files continue to be served.
>    Clearly this is not the case if db and fileserver function is on one
> machine.
> 
> However, I guess the bottom line is cost. How many servers can you afford?
> What kind of AFS service are your users expecting?
> 
> I hope this helps.
> --
> cheers
> paul                       http://acm.org/~mpb
> 
> Patty OReilly wrote:
> 
> > Management wants to consolidate services where possible at our site. We
> > have always adhered to the recommended practice of keeping our Database
> > servers running vlserver, kaserver, ptserver and buserver on separate
> > machines from our Fileservers. Now they want us to consolidate these
> > services and run all AFS server processes on our Fileservers.
> >
> > Does anyone have any information pro or con that could help us decide
> > whether consolidation of Fileservers and DBservers would be successful?
> >
> > --patty
>