[MLB-WIRELESS] Server Virtualisation - (was RE: possible vpn and public ip address allocation option)

[mw at freenet.net.au]

Good evening! :-)

> A number of comments about this:

And some responses...

> 1) For what you want to do, nobody should need root access. If they do,
> then you're doing something wrong. There is no reason why someone who is
> working on a wiki needs root level access to the operating system. Again,

I'm not talking about application administration at a user level, I'm
talking about it from a development level.  Take a radius server for
example.  This is something that needs to be set up and installed on a raw
system from scratch.  How can that be done without shell access?  OK, shell
access is not root access - that's a matter of semantics I guess.

The thing is, if I want to build a radius server under debian (becau se
that's what I am most familiar with) then the last thing I want to happen is
for someone else to run a package installer that breaks all my setup work.
And I don't want to do something to the system that will break someone elses
work.

The obvious advantage of a VM is that it is safely partitioned into discreet
functional units.  And we can get many discrete servers onto a single 1RU
server when hosting/colo space is tight.

> 2) I'd be more concerned at the moment with fixing things like spammers
who
> have automated the process of creating accounts and spamming the wiki such
> as: http://www.melbournewireless.org.au/wiki/?diff=Apple This is much more
> of an issue than having VMs everywhere and trying to reinvent the wheel.

Sure - that needs to be done as well.  But who are *we* to determine what
members are going to do?  Is it not better to see a show of hands as to who
has an interest in developing additional features?  Sure, state a problem
and ask for volunteers, but that's only half the solution to getting some
real progress in the online services for MW.

> 3) You seem to overlook the overhead in VMs. Unless you throw serious
> hardware at it the performance penalty is more than acceptable for doing
> all but toying. Neither the current server nor the newer one being built
> supports hardware virtualisation so there is a rather large performance
> drop in CPU cache speeds between tasks etc etc. You basically lose ~10-20%
> CPU performance even if using hardware virtualisation. From what I have
> seen this gets even worse when multiple VMs are very busy.

Hey, that's what you are saying.  From my experience, it usually works in
reverse.  I rarely see a physical server using even more than 10 or 20
percent of the available resources.  It makes sense to get the most workload
out of what you have available, and if I can consolidate 5 servers onto one
hardware, then it's a no-brainer from my perspective.  Not only do I save
money on hardware, but I also save HEAPS of cash on power - it's amazing how
much electricity one server full of disk spindles and fans uses up!

Furthermore, if you are paying for rack space, then there is further
opportunity for serious savings there too.

And what do you call 'busy'?  According to the current web stats, the
February daily average was a bit over 16000 hits (which is the busiest of
the last 12 months) which equates for one hit, on average, every 11 seconds.
That's hardly 'busy' and I doubt if that would put an average CPU at more
than 5% load at any time throughput the day, even with a database query
behind every single request. 

And if this mailing list also running on that system, then even in times of
the <ahem> 'massive' post numbers we've seen recently, that would hardly be
enough to spike the CPU over 10% in total - if we are absolutely fortunate!
;-D

> 4) Nobody working on a user space project (snmp, wiki etc etc) should need
> root access. I know I mentioned this twice, but its such an important
thing
> I thought I would mention it twice.

Heheheh - neither here nor there.  If all resource components were
virtualised on independent VMs, we could:

a.  assign a sysadmin for each and every function: db, web (even a web
server for each app - wiki, 'locfinder', etc), mail, radius, dns, snmp
monitor, etc etc
b.  make VM images available for individual developers to happily hack away
at - learn the ropes, and make real contributions.
c.  save real $$ on colo and power and hardware

Cheers!

Mike.