[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [RFC] /var versus /srv



Le samedi 29 septembre 2007 à 02:22 +0200, Krzysztof Halasa a écrit :
> Lamont Peterson <lamont gurulabs com> writes:
> 
> > Let's just go to an example.
> >
> > Bob runs IT for a large organization.  The systems that Bob deals with
> > are firmly in the category of "Enterprise-Grade."
> >
> > Bob has 10,000 server to backup.
> 
> So anything non-SOHO means 10,000 servers and perhaps hundreds
> of thousands people. Ok, let it be.

Anything non-SOHO is somewhere where you do automated regular backups
via hardware you don't find in consumer PCs and is expensive enough you
can't just backup everything.

It starts at the cheap DLT auto-changer+amanda level

> > Each of Bob's servers has an average of, say, 30GB of stuff (everything
> > on the disk added up together).
> >
> > Of that average of 30GB/server, only 4GB is not data the server manipulate.
> >  Or in other words, 4GB is OS, libraries, application code, etc. (of
> > course, this number would be significantly higher for Bob's Windows
> > server, but let's keep this scenario simple for now, shall we?).
> 
> IOW, 13.3% of your data is the OS.
> How about a bit larger systems? Like the one I have here with
> ca. 440 GB of data? 1% = the OS. It's still a small machine.

Very often your critical data has not inflated like consumer OSes, so
the trend goes the other way (increasing OS data weight). And you still
have backup space constrains because many systems are connected to the
same backup hardware.

>
[Several questions that show you've got absolutely no understanding of
 real-life enterprise contexts, and that I'll answer in one go]

In real-life systems are not identical. They're supposed to be but
perfection costs money, so they aren't. In case of system failure
reinstalling from scratch is a way to heal a system which has bitrotten
(or a system update that was planified in the next months is just done
with the reinstall)

An enterprise will have streamlined installation of its main OSes, using
kickstart, mirroring or just plain paper procedure so "re-installation
keeps crashing" is not a possibility. And anyway the problem is not you
can save half an hour by restoring an OS backup but sysadmin
availability - you don't pay a sysadmin per system, and you don't pay
24/24 7/7 care for every system.

You're assuming every system connected to an enterprise backup system is
critical and needs to be restored at once. It's not. Entreprises have
big shared backup systems because big shared systems are more reliable
and on the whole cheaper than lots of separate systems, and to achieve
volume everything from critical to no-so-critical is plugged in the same
system. Projects are then billed on data backup volume and frequency.

A "critical" system will have a spare waiting to go live, will pay for
full-system backup, and is on the night sysadmin list for immediate
restoration.

A "not-critical" system will only backup data, will be put back-on-line
when sysadmins have the time, will be lagging on updates, etc. It will
run on old obsolete hardware that can't be replaced identically when it
fails. It's a lot more work to restore than the critical system, but
recurrent costs are lower, and on the whole it's cheaper than the other
one. If the hosting site is destroyed by fire or Al-Qaida plane it can
wait months before restoration, while the other will have its hot spare
on another hosting site go live in minutes

This kind of setup where costs closely mirror system criticity requires
careful planning and sorting of on-disk data (and current /var is such a
mess it's not an option)

-- 
Nicolas Mailhot

Attachment: signature.asc
Description: Ceci est une partie de message numériquement signée


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]