«

I’ve long wondered what problem virtualization was really supposed to solve.
It was supposed to reduce the proliferation of physical servers, and thereby
cut back on power consumption, rack space, infrastructure costs and all
that.

Only it turns out that’s not happening, instead by lowering the cost of
providing extra servers, it has simply encouraged explosive growth in
numbers of them.

In other words, virtualization was only ever a band-aid, a solution to the
wrong problem.

<http://computerworld.co.nz/news.nsf/security/burning-question-how-can-vm-sprawl-be-prevented>

On Tue, 26 Oct 2010 23:41:48 +1300, EMB wrote:

>> Only it turns out that’s not happening, instead by lowering the cost of
>> providing extra servers, it has simply encouraged explosive growth in
>> numbers of them.
>
> It has encouraged people like my bosses to issue an edict that "all
> servers will be virtualised regardless of performance requirements", and
> then jam 93 servers across 32 CPU cores. Nothing runs well, most of it
> hardly runs at all, but it's virtual so it must be good.

By any chance does your boss have pointy hair?


--
"Filtering the Internet is like trying to boil the ocean"

On Wed, 27 Oct 2010 18:12:10 +1300, EMB wrote:

> On 27/10/2010 9:41 a.m., Sweetpea wrote:
>> On Tue, 26 Oct 2010 23:41:48 +1300, EMB wrote:
>>
>>>> Only it turns out that’s not happening, instead by lowering the cost
>>>> of providing extra servers, it has simply encouraged explosive growth
>>>> in numbers of them.
>>>
>>> It has encouraged people like my bosses to issue an edict that "all
>>> servers will be virtualised regardless of performance requirements",
>>> and then jam 93 servers across 32 CPU cores. Nothing runs well, most
>>> of it hardly runs at all, but it's virtual so it must be good.
>>
>> By any chance does your boss have pointy hair?
>
> Very, very, pointy. I'm quietly getting my revenge though - this
> evening I'm going to dump a moderately busy SQL server onto an already
> struggling ESX host and tomorrow when the user complaints hit the
> helldesk I'll offer a loud "told you so", some raucous laughter and
> probably do a little dance appropriate to my heritage.

LOL!

Presumably you've already mentioned this as a "risk" of doing the change
when you got that work approved?


--
"Filtering the Internet is like trying to boil the ocean"

On Thu, 28 Oct 2010 07:17:32 +1300, EMB wrote:

>> Presumably you've already mentioned this as a "risk" of doing the
>> change when you got that work approved?
>>
> It is better than that - the change is at the request of the PHB, and he
> is the one who drove it through the change management committee despite
> my protests. Not my issue when blame is apportioned and questions are
> asked

Nice!


> The first call about slow performance hit the helldesk at 6:47 which is
> likely to become my issue. I can see myself moving a SQL server onto a
> physical box again ASAP - what a pity that I'm busy for a week or so.

LOL!

But what if they log a high priority incident about it?

You'll be turning back on the physical server and syncing the database on
the physical server with the one on the virtual server.


--
"Filtering the Internet is like trying to boil the ocean"

In message <ia6b9c$nol$>, EMB wrote:

> It has encouraged people like my bosses to issue an edict that "all
> servers will be virtualised regardless of performance requirements", and
> then jam 93 servers across 32 CPU cores.

But then, why did you have 93 servers in the first place? It’s always the
Windows servers, isn’t it? Compare:

* Why would you need 93 Windows servers? To run 93 different applications.
* Why would you need 93 Linux servers? To get 93 times the computing power
that a single server can give you.

On Fri, 29 Oct 2010 07:55:39 +1300, EMB wrote:

>>> The first call about slow performance hit the helldesk at 6:47 which
>>> is likely to become my issue. I can see myself moving a SQL server
>>> onto a physical box again ASAP - what a pity that I'm busy for a week
>>> or so.
>>
>> LOL!
>>
>> But what if they log a high priority incident about it?
>
> Despite a high priority incident being logged I managed to convince the
> change management people that it would be a bad idea to do anything
> about moving it off the ESX before we purchase new hardware for its
> reincarnation. That gives me a week or so before I deal with it.
>
>> You'll be turning back on the physical server and syncing the database
>> on the physical server with the one on the virtual server.
>
> I held the PHB to his edict that hardware that isn't under a support
> contract cannot be brought into production, so I can't re-use the old
> server.

Nice touch - NAFfing a high priority incident (caused by management
policy) because of management policy.

Presumably they'll be revising their policies - or do you think they'll
say buy more hardware for the ESX farm?


--
"Filtering the Internet is like trying to boil the ocean"

On Fri, 29 Oct 2010 23:02:51 +1300, EMB wrote:

>> * Why would you need 93 Windows servers? To run 93 different
>> applications. * Why would you need 93 Linux servers? To get 93 times
>> the computing power that a single server can give you.
>
> To get the segregation of data, risk and downtime that is afforded by
> separate servers?

Agreed. There are good practical reasons to keep applications and
databases on separate servers.

And it is also a good risk mitigation to have business applications/
databases (especially key mission critical ones where non-availability
would have a medium to high business impact) hosted on their own
infrastructure.

To that end from a risk management perspective it makes no sense to have
everything virtualised and hosted on one ESX farm with one SAN (virtual
or otherwise). Doing that gives everything at least two more single
points of failure.

Best practise would have 2 ESX farms physically located in different
parts of the country, with 2 physical SANs (I'll not comment on how the
SAN's or the ESX farms themselves should be configured as I really
wouldn't know), with one used as DR for the other (perhaps having half of
prod on one and half of UAT & DR on the other) with either transactional
or log-shipping sync between prod & DR depending on how important the
data is.

I imagine that you'd agree with the above, but it is predicated on having
a fairly fat pipe between them. You've probably already suggested this
when you started down the virtualisation path, but gave you suggested
this to your PHB using risk management/business impact corporate-speak
language?


Words to work into any proposal you want accepted:
Fast, reliable, cheap, efficient.

Words to work into any proposal you want rejected:
Slow, unreliable, expensive, courageous.


--
"Filtering the Internet is like trying to boil the ocean"

In message <iae64a$ncl$>, EMB wrote:

> To get the segregation of data, risk and downtime that is afforded by
> separate servers?

You get that with one primary server and one backup server. How did you end
up with 93?

On Sat, 30 Oct 2010 10:02:06 +1300, Lawrence D'Oliveiro wrote:

>> To get the segregation of data, risk and downtime that is afforded by
>> separate servers?
>
> You get that with one primary server and one backup server. How did you
> end up with 93?

Perhaps he is looking after machines hosting more than 93 applications or
databases?


--
"Filtering the Internet is like trying to boil the ocean"

On 29/10/10 23:02, EMB wrote:
> On 28/10/2010 12:41 p.m., Lawrence D'Oliveiro wrote:
>> In message<ia6b9c$nol$>, EMB wrote:
>>
>>> It has encouraged people like my bosses to issue an edict that "all
>>> servers will be virtualised regardless of performance requirements", and
>>> then jam 93 servers across 32 CPU cores.
>>
>> But then, why did you have 93 servers in the first place? It’s always the
>> Windows servers, isn’t it? Compare:
>
> The 93 are a mix of Windows, Linux and BSD.
>>
>> * Why would you need 93 Windows servers? To run 93 different
>> applications.
>> * Why would you need 93 Linux servers? To get 93 times the computing
>> power
>> that a single server can give you.
>
> To get the segregation of data, risk and downtime that is afforded by
> separate servers?
>
And segregation of applications - you wouldn't want a JBoss and a Tomcat
to run on the same machines. You wouldn't want to mix database and
application server. You wouldn't want the web server or web service to
be on the same machine (and probably not the same network segment) as
the database and application servers. You wouldn't want to have an
upgrade for application A to affect application B. There are many
reasons for having multiple servers running multiple applications,
Windows and Linux. Even before virtualization it was not common to have
'applications' using a shared machine.

Cheers,

Cliff

--

The ends justifies the means - Niccolò di Bernardo dei Machiavelli.

The end excuses any evil - Sophocles