[prev in list] [next in list] [prev in thread] [next in thread] 

List:       thin
Subject:    [THIN] Re: OT: VMWare ESX 3.x Internal / DMZ networks on same physical server
From:       "Joe Shonk" <joe.shonk () gmail ! com>
Date:       2007-02-26 16:38:01
Message-ID: 45e30d08.02ac0cd0.2fa5.1d88 () mx ! google ! com
[Download RAW message or body]

This is a multipart message in MIME format.


Those are some great points.

 

If you truly need the best performance then raw hardware is the way to go.
Of course local disk is going to be better, but at what cost?  Additional
management?  I think the flexibility of a SAN outweighs the performance hit
of using the SAN.   For a normal server,  how much of a hit are we talking
about?  Now, how about for a Citrix server?  If the performance impact is
truly paramount, then why not use RAID 0+1 (or RAID 10) for the local disk
sub-system.  Or better yet, throw in a tigiJet solid state devices.

 

I will agree with you on points 1 and 2.  For number 3, my point for
heat/power consumption go back to your first point.   If you manage the
space properly, you could boot 5-10 servers off of two 146 gig SAN drives.
The savings come in aggregating and virtualizing the disks at the SAN.  The
SAN becomes the VMware of storage so you gain many of the benefits and
efficiencies.  For larger volumes,  management is the key.  Many vendors let
you start out small and grow you luns/volumes as needed.   The normal
paradigm for local disk is to buy as much as you can up front.

 

For point number 4,  the SAS drives performance has been dismal (or should I
say the controllers from HP and IBM).  Even IBM recommends booting from
their SAN.

 

I love this quote and it rings so true and this is one reason I'm not a fan
of EMC:   "If your SAN dies because some bozo screwed up a firmware upgrade
or decided to re-arrange the LUNs, you've just discovered that you've got
all your eggs in one basket"

 

Anyways,  this has been a great discussion.  Thanks Rick and Neil.

 

Thanks,

 

Joe

 

 

 

From: thin-bounce@freelists.org [mailto:thin-bounce@freelists.org] On Behalf
Of Rick Mack
Sent: Friday, February 23, 2007 10:55 PM
To: thin@freelists.org
Subject: [THIN] Re: OT: VMWare ESX 3.x Internal / DMZ networks on same
physical server

 

Hi Joe,

 

I hope this isn't interpeted as a religious discussion because it's not
meant to be. SANs have an important role to play in business and VMWare
rocks. SAN disks give you much better throughput than local hard disks.
Period, no argument. SAN storage is good, my customers use it and I promote
it like crazy, in the right places. 

 

BUT we were talking about boot on SAN and the advisability of using SAN
disks as system disks.

 

The first point to emphasize is that throughput and latency are different.
It's the difference between disk seek time and disk transfer rate, different
units (time vs data/time), different meaning. 

 

I guess I'd like to dispute a couple of the bullet points you made and maybe
concede some stuff as well.

 

(1) If we're talking system disks (Boot off SAN vs local disks), SAN disks
waste less disk space. 

 

(2) SAN volumes typically have a latenct than local disks. There are more
players between the ball and the goal.

 

(3) For large data volumes, SANs use the same hard disks we use as local
disks (unless of course you got a really "good" deal and are using SATA or
parallel IDE disks). Same power draw, same heat production. Since we've got
lots of redundancy built in there are extra power supplies, controllers,
fans, cache electronics etc. There's no way a 72 GB SAN volume could use
less power or produce less heat than a 72 GB local disk. How can it when the
underlying technology is exactly the same and you've got more support
infrastructure. Also let's not forget about those spare drives that are in
the SAN and powered up just in case. 

 

(4) HP and IBM as an example are using 2.5 " SAS disk on-board on blades and
stuck in the front of 1RU systems. They don't take up any extra rack space.
SAN disks are in big cabinets and pizza boxes, generally in their own
rack/cabinet.  

 

SANs have much greater hardware redundancy and that means they ought to be a
lot more reliable than a bunch of disks. This is genarally true, but how
often have you had both disks in a mirrored pair fail? 

 

Admittedly these days if a SAN dies it really doesn't matter if your servers
stay up or not but that's not the point.If your SAN dies because some bozo
screwed up a firmware upgrade or decided to re-arrange the LUNs, you've just
discovered that you've got all your eggs in one basket. If we've used boot
on SAN extensively we've got no domain controller, no terminal servers, no
file server, no exchange, no SQL, nothing. 

 

Even if you've got a fully replicated SAN on your DR site with up-to-date
synchronized data, you can't use the data unless you do a complete failover
to the DR site with all your systems. And if that isn't an option, how long
will it take before you've restored everything once the SAN is reconfigured
and running again? 

 

Don't get me wrong, I don't have a better solution and having everything on
disparate sets of local disks is a total nightmare to support compared to
SAN storage. I'm not biassed against SANs, I just think it's important to
use technology appropriately and as efficiently as possible. SANs give you
tremendous flexibility in data storage, good redundancy etc but as I've
stated above, it comes at a cost. You don't save power or cooling costs, you
don't save space. 

 

Google have shown us that there are other possible architectural models that
don't need SANs. Operating system partitioning has been around for a long
time, and products like Virtuozzo are going to start eroding the the VMWare
market because they're just that much more efficient. PlateSpin let's you do
P2P migrations (not that efficient yet, but just wait) that can be used for
DR redundancy etc. Heck, most of the time we use pitiful active/passive
clustering when you've got stuff around like Polyserve that makes clustering
actually work. 

 

There really is no technology solution that is a 100% fit to all problems.
VMWare isn't the answer to everything, SANs aren't the answer to everything.
We have to stay open-minded and try and use what's available in the best way
possible. 

 

regards,

 

Rick 

I'm going to have to disagree with you and Neil on the one...

The latency issue with FC vs SCSI is negligible depending on what your setup
is.  Sure FC can have higher latency if all your doing is mapping 2 physical
disks (mirrored) to one lun.  That's old school technology.  Modern SANs
aggregate disks into pools that can be carved out.  Much of SANs and SCSI
performance depends on the hardware used to implement.   I've seen 1Gb SAN
push a sustained 97MB/s for reads while a 2 mirrored 10k SAS drives could
only sustain 11MB/s for reads.  Extremes perhaps, but real world results. 

Yes, SANs are more expensive that local disks, but there are other
considerations be made:
  Heat and Cooling costs
  Power Draw
  Space/Real Estate
  Business Continuity and Recoverability
  Blades or Pizza Boxes 

Just like the blades vs Pizza Boxes debate,  each has it's advantage and
disadvantages.  However, there is so much more I can do with a SAN
infrastructure that I can do with Local Storage.

Add VMware and BAM! (borrowed this term from Emeril) the value that can be
added to an organization skyrockets.  It's no mystery why VMWare and
Virtualization has taken off. 

As far a cost effectiveness, that is debatable... When you factor in
Cooling/Power Draw/Business continuity it's hard to argue. Again, it all
depends on what your virtualizing and how important it is to the business. 

If you want a cost effective Virtualization Solution, then I would suggest
looking at Virtuozzo from SWSoft.

Joe

On 2/23/07, Rick Mack < ulrich.mack@gmail.com <mailto:ulrich.mack@gmail.com>
> wrote:

Hi Steve,

 

VMs aside, there are still a couple of significant areas where SAN disks
just don't hack it as a system disk. 

 

The first is latency which can be 4-5 times worse on a SAN "disk" (overhead
of fabric switch and other infrastructure) compared to local disks. I know
that DR etc is a lot easier with SAN disks than local hard disks, but if you
decide to go SAN boot and still want want real performance then you'd better
at least consider using the local hard disks for paging, spooling and user
profiles. 

 

The second issue is price. Even with 72 GB disks where most of the disk
space is wasted, SAN disk space still costs quite a bit more than RAID
mirrored local drives. 

 

I have a suspicion that there will be a time in the near future when people
will start realising that that VMWare isn't nearly as cost effective as
everyone argues. Please don't get me wrong, I love the idea of VMWare and
just wouldn't do without it. It's just that VMWare isn't really about saving
money once we get away from a development environment. 

 

And until we can overcome disk and network i/o bottlenecks, having more CPU
power to play with just isn't all that critical. Of course there are things
like Vista/Longhorn's flash drive read/write caching that even things up a
bit but what we really need is the next generation of hard disks that have
obscenely large on-board caches. That'll let them run at close to the
interface speeds (eg up to 6 Gb per disk on SASI). 

 

regards,

 

Rick

 

On 2/23/07, Steve Greenberg < steveg@thinclient.net
<mailto:steveg@thinclient.net> > wrote:

Nice! This is one of those mind set changes that we periodically have to go
through. I am going through one right now with the idea of booting servers
off the SAN, in the old days this was flaky but I have to update my thinking
and accept that it works and is trustworthy! 

 

Steve Greenberg

Thin Client Computing

34522 N. Scottsdale Rd D8453

Scottsdale, AZ 85262

(602) 432-8649

www.thinclient.net  <http://www.thinclient.net/> 

steveg@thinclient.net  <mailto:steveg@thinclient.net> 

 




-- 
Ulrich Mack
Commander Australia 


[Attachment #3 (text/html)]

<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.q
	{mso-style-name:q;}
span.e
	{mso-style-name:e;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Those are some great points.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>If you truly need the best performance then raw hardware is the
way to go.&nbsp;&nbsp; Of course local disk is going to be better, but at what
cost?&nbsp; Additional management? &nbsp;I think the flexibility of a SAN
outweighs the performance hit of using the SAN.&nbsp;&nbsp; For a normal
server,&nbsp; how much of a hit are we talking about?&nbsp; Now, how about for
a Citrix server?&nbsp; If the performance impact is truly paramount, then why
not use RAID 0+1 (or RAID 10) for the local disk sub-system.&nbsp; Or better
yet, throw in a tigiJet solid state devices.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I will agree with you on points 1 and 2.&nbsp; For number 3, my point
for heat/power consumption go back to your first point.&nbsp; &nbsp;If you
manage the space properly, you could boot 5-10 servers off of two 146 gig SAN
drives.&nbsp; The savings come in aggregating and virtualizing the disks at the
SAN.&nbsp; The SAN becomes the VMware of storage so you gain many of the benefits
and efficiencies.&nbsp; For larger volumes,&nbsp; management is the key.&nbsp;
Many vendors let you start out small and grow you luns/volumes as needed. \
&nbsp;&nbsp;The normal paradigm for local disk is to buy as much as you can up \
front.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>For point number 4,&nbsp; the SAS drives performance has been
dismal (or should I say the controllers from HP and IBM).&nbsp; Even IBM
recommends booting from their SAN.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I love this quote and it rings so true and this is one reason \
I&#8217;m not a fan of EMC:&nbsp;&nbsp; &#8220;</span>If&nbsp;your SAN dies because \
some bozo screwed up a firmware upgrade or decided to re-arrange the LUNs, you've
just discovered that you've got all your eggs in one basket<span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&#8221;<o:p></o:p></span></p>


<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Anyways,&nbsp; this has been a great discussion.&nbsp; Thanks
Rick and Neil.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thanks,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Joe<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span \
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span \
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> thin-bounce@freelists.org \
[mailto:thin-bounce@freelists.org] <b>On Behalf Of </b>Rick Mack<br>
<b>Sent:</b> Friday, February 23, 2007 10:55 PM<br>
<b>To:</b> thin@freelists.org<br>
<b>Subject:</b> [THIN] Re: OT: VMWare ESX 3.x Internal / DMZ networks on same
physical server<o:p></o:p></span></p>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=MsoNormal>Hi Joe,<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<div>

<p class=MsoNormal>I hope this isn't interpeted as a religious discussion
because it's not meant to be. SANs have an important role to play in business
and VMWare rocks. SAN disks give you much better throughput than local hard
disks. Period, no argument. SAN storage is good,&nbsp;my customers use it and I
promote it like crazy, in the right places. <o:p></o:p></p>

</div>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>BUT we were talking about boot on SAN and the advisability
of using SAN disks as system disks.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>The first point to emphasize is that&nbsp;throughput and
latency are different. It's&nbsp;the difference between disk seek time and disk
transfer rate, different units (time vs data/time), different meaning. \
<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>I guess I'd like to&nbsp;dispute a couple of the&nbsp;bullet
points you made and maybe concede some stuff as well.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>(1) If we're talking system disks (Boot off SAN vs local
disks), SAN disks waste less disk space. <o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>(2) SAN&nbsp;volumes typically have a latenct than local
disks. There are more players between the ball and the goal.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>(3)&nbsp;For large data volumes, SANs use the same hard
disks we use as local disks (unless of course you got a really &quot;good&quot;
deal and are using SATA or parallel IDE disks). Same power draw, same heat
production. Since we've got lots of redundancy built in there are extra power
supplies, controllers, fans, cache electronics etc. There's no way a 72 GB
SAN&nbsp;volume&nbsp;could use less power or produce less heat than a 72 GB
local disk. How can it when the underlying technology is exactly the same and
you've got more support infrastructure. Also let's not forget about
those&nbsp;spare drives that are&nbsp;in the SAN&nbsp;and powered up just in
case. <o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>(4) HP and IBM as an example&nbsp;are using 2.5 &quot; SAS
disk on-board on blades and stuck in the front of 1RU systems. They don't take
up any extra rack space. SAN disks are in big cabinets and pizza boxes,
generally in their own rack/cabinet.&nbsp; <o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>SANs have much greater hardware redundancy and that
means&nbsp;they ought to be a lot more reliable than a bunch of disks. This is
genarally true, but how often have you had both disks in a mirrored pair fail? \
<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>Admittedly these days if a SAN dies it really doesn't matter
if your servers stay up or not but that's not the point.If&nbsp;your SAN dies
because some bozo screwed up a firmware upgrade or decided to re-arrange the
LUNs, you've just discovered that you've got all your eggs in one basket. If
we've used boot on SAN extensively we've got no domain controller, no terminal
servers, no file server, no exchange, no SQL, nothing. <o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>Even if you've got a fully replicated SAN on your DR site
with up-to-date synchronized data, you can't use the data unless you do a
complete failover to the DR site with all your systems.&nbsp;And if that isn't
an option, how long will it take before you've restored everything once the SAN
is reconfigured and running again? <o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>Don't get me wrong, I don't have a better solution and
having everything on disparate sets of local disks is a total nightmare to
support compared to SAN storage. I'm not biassed against SANs, I just think
it's important to use technology appropriately and as efficiently as possible.
SANs give you tremendous flexibility in data storage, good redundancy etc but
as I've stated above, it comes at a cost. You don't save power or cooling
costs, you don't save space. <o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<div>

<p class=MsoNormal>Google have shown us that there are other possible
architectural models that don't need SANs. Operating system partitioning has
been around for a long time, and products like Virtuozzo are going to start
eroding the the VMWare market because they're just that much more efficient.
PlateSpin let's you do P2P migrations (not that efficient yet, but just wait)
that can be used for DR redundancy etc.&nbsp;Heck, most of the time we use
pitiful active/passive clustering when you've got stuff around like Polyserve
that makes clustering actually work. <o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

</div>

<div>

<p class=MsoNormal>There really is&nbsp;no technology solution&nbsp;that is a
100% fit to all problems. VMWare isn't the answer to everything, SANs aren't
the answer to everything. We have to stay open-minded and try and use what's
available in the best way possible. <o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>regards,<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>Rick&nbsp;<o:p></o:p></p>

</div>

<div>

<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in \
6.0pt; margin-left:4.8pt;margin-right:0in'>

<div>

<div>

<p style='margin-bottom:12.0pt'>I'm going to have to disagree with you and Neil
on the one...<br>
<br>
The latency issue with FC vs SCSI is negligible depending on what your setup
is.&nbsp; Sure FC can have higher latency if all your doing is mapping 2
physical disks (mirrored) to one lun.&nbsp; That's old school technology.&nbsp;
Modern SANs aggregate disks into pools that can be carved out.&nbsp; Much of
SANs and SCSI performance depends on the hardware used to
implement.&nbsp;&nbsp; I've seen 1Gb SAN push a sustained 97MB/s for reads
while a 2 mirrored 10k SAS drives could only sustain 11MB/s for reads.&nbsp;
Extremes perhaps, but real world results. <br>
<br>
Yes, SANs are more expensive that local disks, but there are other
considerations be made:<br>
&nbsp; Heat and Cooling costs<br>
&nbsp; Power Draw<br>
&nbsp; Space/Real Estate<br>
&nbsp; Business Continuity and Recoverability<br>
&nbsp; Blades or Pizza Boxes <br>
<br>
Just like the blades vs Pizza Boxes debate,&nbsp; each has it's advantage and
disadvantages.&nbsp; However, there is so much more I can do with a SAN
infrastructure that I can do with Local Storage.<br>
<br>
Add VMware and BAM! (borrowed this term from Emeril) the value that can be
added to an organization skyrockets.&nbsp; It's no mystery why VMWare and
Virtualization has taken off. <br>
<br>
As far a cost effectiveness, that is debatable... When you factor in
Cooling/Power Draw/Business continuity it's hard to argue. Again, it all
depends on what your virtualizing and how important it is to the business. <br>
<br>
If you want a cost effective Virtualization Solution, then I would suggest
looking at Virtuozzo from SWSoft.<br>
<br>
Joe<o:p></o:p></p>

<div>

<p>On 2/23/07, <b>Rick Mack</b> &lt;<a href="mailto:ulrich.mack@gmail.com"
target="_blank"> ulrich.mack@gmail.com</a>&gt; wrote:<o:p></o:p></p>

<div>

<div>

<p>Hi Steve,<o:p></o:p></p>

</div>

<div>

<p>&nbsp;<o:p></o:p></p>

</div>

<div>

<p>VMs aside, there are still a couple of&nbsp;significant areas where SAN
disks just don't hack it as a system disk. <o:p></o:p></p>

</div>

<div>

<p>&nbsp;<o:p></o:p></p>

</div>

<div>

<p>The first is latency which&nbsp;can be&nbsp;4-5 times worse on a SAN
&quot;disk&quot; (overhead of fabric switch and other infrastructure) compared
to local disks. I know that DR etc is a lot easier with SAN disks than local
hard disks, but if you decide to go SAN boot and still want&nbsp;want real
performance then you'd better at least consider using the local hard disks for
paging, spooling and user profiles. <o:p></o:p></p>

</div>

<div>

<p>&nbsp;<o:p></o:p></p>

</div>

<div>

<p>The second issue is price. Even with 72 GB disks where most of the disk
space is wasted, SAN disk space still costs quite a bit more than RAID mirrored
local drives. <o:p></o:p></p>

</div>

<div>

<p>&nbsp;<o:p></o:p></p>

</div>

<div>

<p>I have a suspicion that there will be a time in the near future when people
will start realising that that VMWare isn't nearly as cost effective as
everyone argues. Please don't get me wrong, I love the idea of VMWare and just
wouldn't do without it. It's just that VMWare isn't really about saving money once
we get away from a development environment. <o:p></o:p></p>

</div>

<div>

<p>&nbsp;<o:p></o:p></p>

</div>

<div>

<p>And until we can overcome disk and network i/o bottlenecks, having more CPU
power to play with just isn't all that critical. Of course there are things
like Vista/Longhorn's&nbsp;flash drive read/write caching that even things up a
bit but what we really need is the next generation of hard disks that have
obscenely large on-board caches. That'll let them run at close to the interface
speeds (eg up to 6 Gb per disk on SASI). <o:p></o:p></p>

</div>

<div>

<p>&nbsp;<o:p></o:p></p>

</div>

<div>

<p>regards,<o:p></o:p></p>

</div>

<div>

<p>&nbsp;<o:p></o:p></p>

</div>

<div>

<p>Rick<o:p></o:p></p>

</div>

<div>

<div>

<p>&nbsp;<o:p></o:p></p>

</div>

<div>

<p>On 2/23/07, <b>Steve Greenberg</b> &lt;<a href="mailto:steveg@thinclient.net"
target="_blank"> steveg@thinclient.net </a>&gt; wrote:<o:p></o:p></p>

</div>

<div>

<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in \
6.0pt; margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<div>

<div>

<p><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'>Nice!
This is one of those mind set changes that we periodically have to go through.
I am going through one right now with the idea of booting servers off the SAN,
in the old days this was flaky but I have to update my thinking and accept that
it works and is trustworthy! </span><o:p></o:p></p>

<p><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'>&nbsp;</span><o:p></o:p></p>


<div>

<p><span style='font-size:10.0pt;color:navy'>Steve Greenberg</span><o:p></o:p></p>

<p><span style='font-size:10.0pt;color:navy'>Thin Client \
Computing</span><o:p></o:p></p>

<p><span style='font-size:10.0pt;color:navy'>34522 N. Scottsdale Rd \
D8453</span><o:p></o:p></p>

<p><span style='font-size:10.0pt;color:navy'>Scottsdale, AZ \
85262</span><o:p></o:p></p>

<p><span style='font-size:10.0pt;color:navy'>(602) 432-8649</span><o:p></o:p></p>

<p><span style='font-size:10.0pt;color:navy'><a
href="http://www.thinclient.net/" target="_blank">www.thinclient.net \
</a></span><o:p></o:p></p>

<p><span style='font-size:10.0pt;color:navy'><a
href="mailto:steveg@thinclient.net" target="_blank">steveg@thinclient.net \
</a></span><o:p></o:p></p>

</div>

</div>

</div>

</blockquote>

</div>

</div>

</div>

</div>

<p>&nbsp;<o:p></o:p></p>

</div>

</div>

</blockquote>

</div>

<p class=MsoNormal><br>
<br clear=all>
<br>
-- <br>
Ulrich Mack<br>
Commander Australia <o:p></o:p></p>

</div>

</body>

</html>


SBC SITES ONLY GOOGLE SEARCH: http://www.F1U.com 
************************************************
For Archives, RSS, to Unsubscribe, Subscribe or 
set Digest or Vacation mode use the below link:
http://www.freelists.org/list/thin
************************************************

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic