[Tfug] "Blade" servers

[Bexley Hall]

Hi Yan,

On 7/21/2013 2:25 AM, Yan wrote:
> So this probably isn't what you really want to hear, but this is the way we
> do it here in the lab:
>
> We have a bunch (I think the current number is 16) big, beefy (16 core, 96
> gigs of ram, filled to the brim with SSDs) that are in an Openstack

These are individual *servers*?  Or, blade servers??

> deployment. When we need resources, we spin up some VMs (using something
> like Saltstack, for example) which do some work (usually by using Celery to
> handle task distribution) and then shut back down.

OK, so you're "virtually" doing something akin to my approach
(I add actual power control to the process since "half" of the
computational power is not collocated with the blade server
and I have to ensure the "correct" processors are spun up to
make the "necessary" I/O's available for the task set at hand).

In my case, processors boot differently depending on their
locations, roles, etc.  E.g., one boots of a physical disk;
some PXE boot; others boot specialized kernels from ROM/FLASH;
etc.  I can't allow the power cycling/bootstrapping to become
a visible/perceptible activity (i.e., users would never tolerate
waiting seconds for a node/service to come on-line -- so, most
nodes boot and load their applications in a fraction of a second).

> The physical machines
> themselves always stay on (although, if they're not being utilized, they
> idle).

Are they *capable* of being powered down and you just don't
take advantage of that (extra complexity?  *you* aren't paying
for the electricity?  etc.)  Any idea as to what it costs
to idle a processor vs. having it *do* something useful?
(I suspect it's not a huge difference given all the other
cruft in each box)

> That's probably overkill for what you want, unless you need to automate an
> entire compound of buildings, but there you go.

A modest business (50-100 employees) would easily tax this sort of
a system.  I.e., they are "all" interacting (or, *capable* of
interacting) with the system at any given time.  The "cost" if
automation is pretty small.  The lion's share of the cost lies in
servicing users and distributing multimedia (imagine two or three
video conferences happening in that small business -- because
a video conference is "just as inexpensive" as phoning someone
on their office extension).

> For us, it's really nice.
> Spinning up our own VMs let us ignore the fact that we're actually sharing
> the hardware, and a Celery/RabbitMQ/MongoDB task workflow abstracts away
> much of the distributed processing headaches.

In my case, the entity that is freed of the chore of managing what
runs where is the system, itself.  User's aren't associated with
particular machines.  They just think they are dealing with "The
System".  Just like you don't hesitate to pick up the nearest
telephone extension when you need to place a call to another
office; or, check your mail/WWW from the nearest PC, etc.

> I'm personally not aware of anyone that really powers on and off physical
> servers on demand anymore. It's all cloud, all the time.

I think businesses have historically been much less concerned with
energy consumption.  E.g., PBX's stay lit even when the building
is deserted; most places don't even enforce a policy of requiring
employees to power down their PC's before leaving for the day, etc.

I think businesses have a much higher -- and "narrower" -- peak
consumption period than residences.  E.g., ~10 hours (single
shift) of very high demand followed by ~14 hours of very little
demand.  Contrast this with residences that have a spurt of
demand early in the morning, some demand during the day (while
some residents are "away at work"), significantly increased
demand in the evening (meal prep, entertainment) followed by
virtually no demand "while sleeping".

And, residents tend to *feel* the cost of the energy that is
consumed on their behalf!

(Many businesses pay for electricity using different tariffs...
power used "off hours" is often "free" -- or, comparatively so
when contrasted with "peak" consumption)

But, that doesn't mean one should ignore power requirements in
a system's design if you have a choice!  Especially if the capability
is there (and just isn't *typically* used -- at the present time).

--don