No subject
Fri Mar 12 14:08:07 EST 2010
Channel
<http://www.vmware.com/files/pdf/vsphere_perf_exchange-storage-protocols
.pdf> =20
=20
"All three tested protocols [FC, iSCSI and NFS] have shown to be able
to support 16,000 Exchange users in both the Heavy and Double Heavy
workloads. These workloads stressed a 16-core HP DL 580 server to
approximately 60 percent CPU utilization and pushed an average of over
5,000 IOPS to the attached NetApp storage array. This throughput was
maintained while the average latency stayed under 220 milliseconds and
95th percentile latency remained under one second. Fibre Channel
provided the best performance with the lowest CPU utilization. NFS and
iSCSI performance was comparable with slightly longer latencies, and
slightly higher CPU utilization."
=20
According to the white paper from VMware, the performance differential
is marginal. This paper was based on NetApp. Is there any reason to
believe that other vendors offering similar products would not have
similar results?
=20
=20
Bobby
=20
From: discuss-bounces at itdiscuss.org
[mailto:discuss-bounces at itdiscuss.org] On Behalf Of Bobby Stewart
Sent: Friday, May 21, 2010 11:04 AM
To: IT Discussion Forum
Subject: [itdiscuss] Off to the Races - To LUN or not to LUN...
=20
As we proceed in our virtualization quest we are trying to cover all the
basses. For me, this has been a thought provoking process as I entertain
the various technologies available. This is my second post on this topic
to seek the advice of the community as we go.
=20
Most, if not all, current SAN solutions for the SMB market provide iSCSI
capabilities for accessing the SAN at a block level. This will require
that a device accessing the SAN will access a LUN set up on the SAN for
the data therein (stored VMs, actual data stores, etc.).
=20
Many newer SAN offerings provide alternate methods of accessing data on
the SAN other than iSCSI. These typically appear as file based access
principally via CIFS and NFS thus making the SAN a combo SAN/NAS.
Virtualization purists will decry this tactic suggesting that to do so
will impact performance. My own thoughts, unfounded thought they may be,
are along these lines:=20
a) virtualization infrastructures access files located on storage
media that are the basis of the virtualized servers (VMs)
b) in a traditional iSCSI based system a host OS must be created to
provide that file infrastructure
c) a VM host accessing these files on a system that already
provides the file infrastructure will have a resulting reduction in
resource usage
=20
It would seem, then, that a virtual system utilizing a high performance
file based architecture hosted by the storage device is something to be
desired in a virtualization environment. A possible down side would be
that the storage device would be required to provide the resources for
that architecture and could suffer a resulting performance hit on the
iSCSI side. Much would depend on the robustness of the device's
computing platform and its networking capabilities which would determine
its ability to provide both block and file architectures simultaneously
without performance suffering for either or both.
=20
A secondary benefit will be that portions of the storage infrastructure
could also be provisioned for direct, file based access for end users
thus reducing the need to set up virtualized file servers. Obviously,
safeguards will be required so that sufficient bandwidth is retained for
server virtualization and that proper access security is provided.
=20
So, to paraphrase Shakespeare, "To LUN or not to LUN - that is the
question." What do you say? What are the risks of using a storage device
that would provide both file and block based storage architectures for
use in a virtualized environment?
=20
Please try to provide thoughtful, fact based responses where possible.
Opinions are just that, opinions, and I have many of them that are not
worth much.
=20
Bobby Stewart
Network Analyst
Brentwood Baptist Church
Brentwood, TN
www.brentwoodbaptist.com
+1 (615) 324-6149 office
+1 (615) 830-0012 cell
=20
------_=_NextPart_001_01CAF90E.8F13D3E1
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(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:11.0pt;
font-family:"Calibri","sans-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.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:601376688;
mso-list-type:hybrid;
mso-list-template-ids:-820493566 67698711 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-number-format:alpha-lower;
mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Chris Green at Solerant gave me the following =
considerations:<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>“If you want to do =
DFS or similar Windows technologies your file server will need to be =
Windows and not a NAS.”<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>Yes, we are using DFS. =
This is important.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>“NFS is not block =
level. While it is the highest performance network file system it is not =
VMFS and therefore does not benefit from much of the technology in =
vSphere.”<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>Though most virtualizers =
here are VMware aficionados, I am not yet persuaded. My initial =
investigation into the pricing of the Microsoft management technologies =
shows a considerable savings over the VMware offerings even with their =
newly available academic pricing for charities. I still have some =
detailed feature comparisons ahead. I will start a new thread inviting =
those of you with specific experience with the current versions of both =
offerings to send up your comments.<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>Great stuff! Thanks =
Chris. Keep those cards and letters coming!<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'>Bobby<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><div><div =
style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
discuss-bounces at itdiscuss.org [mailto:discuss-bounces at itdiscuss.org] =
<b>On Behalf Of </b>Bobby Stewart<br><b>Sent:</b> Friday, May 21, 2010 =
12:31 PM<br><b>To:</b> IT Discussion Forum<br><b>Subject:</b> Re: =
[itdiscuss] Off to the Races - To LUN or not to =
LUN...<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Also see the paper: <a =
href=3D"http://www.vmware.com/files/pdf/perf_vsphere_storage_protocols.pd=
f">Comparison of Storage Protocol Performance in VMware vSphere™ =
4</a> <o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>“All four storage =
protocols for shared storage on ESX [FC, Hardware iSCSI, Software iSCSI =
and NFS] are shown to be capable of achieving throughput levels that are =
only limited by the capabilities of the storage array and the connection =
between it and the ESX server. ESX shows excellent scalability by =
maintaining these performance levels in cases of heavy consolidation. =
For CPU cost, Fibre Channel and Hardware iSCSI are more efficient than =
Software iSCSI and NFS. However, when CPU resources are not a =
bottleneck, Software iSCSI and NFS can also be part of a =
high-performance solution.”<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>My question is to the =
conceivable benefits of using NFS/CIFS for some storage device functions =
and iSCSI for others from the same device vs. the performance overall. =
To me, it’s beginning to look like it wouldn’t be a =
significant issue for performance. The aspect of not needing to license =
and setup a virtual machine for file service and potentially other =
functions is in the plus column of the cost/benefit =
analysis.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><div><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'>Bobby<o:p></o:p></span></p></div><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><div><div =
style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
discuss-bounces at itdiscuss.org [mailto:discuss-bounces at itdiscuss.org] =
<b>On Behalf Of </b>Bobby Stewart<br><b>Sent:</b> Friday, May 21, 2010 =
11:48 AM<br><b>To:</b> IT Discussion Forum<br><b>Subject:</b> Re: =
[itdiscuss] Off to the Races - To LUN or not to =
LUN...<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Here’s some real data: =
<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>From <a =
href=3D"http://www.vmware.com/files/pdf/vsphere_perf_exchange-storage-pro=
tocols.pdf">VMware vSphere™ 4: Exchange Server® on NFS, iSCSI, =
and Fibre Channel</a> <o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>“All three tested =
protocols [FC, iSCSI and NFS] have shown to be able to support =
16,000 Exchange users in both the Heavy and Double Heavy workloads. =
These workloads stressed a 16-core HP DL 580 server to approximately 60 =
percent CPU utilization and pushed an average of over 5,000 IOPS to the =
attached NetApp storage array. This throughput was maintained while the =
average latency stayed under 220 milliseconds and 95th percentile =
latency remained under one second. Fibre Channel provided the best =
performance with the lowest CPU utilization. NFS and iSCSI performance =
was comparable with slightly longer latencies, and slightly higher CPU =
utilization.”<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>According to the white =
paper from VMware, the performance differential is marginal. This paper =
was based on NetApp. Is there any reason to believe that other vendors =
offering similar products would not have similar =
results?<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><div><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'>Bobby<o:p></o:p></span></p></div><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p> </o:p></span></p><div><div =
style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
discuss-bounces at itdiscuss.org [mailto:discuss-bounces at itdiscuss.org] =
<b>On Behalf Of </b>Bobby Stewart<br><b>Sent:</b> Friday, May 21, 2010 =
11:04 AM<br><b>To:</b> IT Discussion Forum<br><b>Subject:</b> =
[itdiscuss] Off to the Races - To LUN or not to =
LUN...<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>As we =
proceed in our virtualization quest we are trying to cover all the =
basses. For me, this has been a thought provoking process as I entertain =
the various technologies available. This is my second post on this topic =
to seek the advice of the community as we go.<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Most, if not =
all, current SAN solutions for the SMB market provide iSCSI capabilities =
for accessing the SAN at a block level. This will require that a device =
accessing the SAN will access a LUN set up on the SAN for the data =
therein (stored VMs, actual data stores, etc.).<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Many newer =
SAN offerings provide alternate methods of accessing data on the SAN =
other than iSCSI. These typically appear as file based access =
principally via CIFS and NFS thus making the SAN a combo SAN/NAS. =
Virtualization purists will decry this tactic suggesting that to do so =
will impact performance. My own thoughts, unfounded thought they may be, =
are along these lines: <o:p></o:p></p><p class=3DMsoListParagraph =
style=3D'text-indent:-.25in;mso-list:l0 level1 lfo2'><![if =
!supportLists]><span style=3D'mso-list:Ignore'>a)<span =
style=3D'font:7.0pt "Times New Roman"'> =
</span></span><![endif]>virtualization infrastructures access files =
located on storage media that are the basis of the virtualized servers =
(VMs)<o:p></o:p></p><p class=3DMsoListParagraph =
style=3D'text-indent:-.25in;mso-list:l0 level1 lfo2'><![if =
!supportLists]><span style=3D'mso-list:Ignore'>b)<span =
style=3D'font:7.0pt "Times New Roman"'> =
</span></span><![endif]>in a traditional iSCSI based system a host OS =
must be created to provide that file infrastructure<o:p></o:p></p><p =
class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo2'><![if !supportLists]><span style=3D'mso-list:Ignore'>c)<span =
style=3D'font:7.0pt "Times New =
Roman"'> </span></span><![endif]>a =
VM host accessing these files on a system that already provides the file =
infrastructure will have a resulting reduction in resource =
usage<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal>It would seem, then, that a virtual system utilizing a =
high performance file based architecture hosted by the storage device is =
something to be desired in a virtualization environment. A possible down =
side would be that the storage device would be required to provide the =
resources for that architecture and could suffer a resulting performance =
hit on the iSCSI side. Much would depend on the robustness of the =
device’s computing platform and its networking capabilities which =
would determine its ability to provide both block and file architectures =
simultaneously without performance suffering for either or =
both.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal>A secondary benefit will be that portions of the =
storage infrastructure could also be provisioned for direct, file based =
access for end users thus reducing the need to set up virtualized file =
servers. Obviously, safeguards will be required so that sufficient =
bandwidth is retained for server virtualization and that proper access =
security is provided.<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>So, to =
paraphrase Shakespeare, “To LUN or not to LUN – that is the =
question.” What do you say? What are the risks of using a storage =
device that would provide both file and block based storage =
architectures for use in a virtualized environment?<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Please try =
to provide thoughtful, fact based responses where possible. Opinions are =
just that, opinions, and I have many of them that are not worth =
much.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p =
class=3DMsoNormal>Bobby Stewart<br>Network Analyst<br>Brentwood Baptist =
Church<br>Brentwood, TN<br><a =
href=3D"http://www.brentwoodbaptist.com">www.brentwoodbaptist.com</a><br>=
+1 (615) 324-6149 office<br>+1 (615) 830-0012 cell<o:p></o:p></p><p =
class=3DMsoNormal><o:p> </o:p></p></div></body></html>
------_=_NextPart_001_01CAF90E.8F13D3E1--
More information about the discuss
mailing list