<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/1.5.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Tom&#8217;s got nice SAS</title>
	<link>http://storageadvisors.adaptec.com/2006/04/10/toms-hardware-loves-sas/</link>
	<description>Storage Solutions for Real World IT Professionals</description>
	<pubDate>Mon, 15 Mar 2010 17:56:08 +0000</pubDate>
	<generator>http://wordpress.org/?v=1.5.2</generator>

	<item>
 		<title>Comment on Tom&#8217;s got nice SAS by: Tom</title>
		<link>http://storageadvisors.adaptec.com/2006/04/10/toms-hardware-loves-sas/#comment-28844</link>
		<pubDate>Fri, 26 Jan 2007 19:33:09 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2006/04/10/toms-hardware-loves-sas/#comment-28844</guid>
					<description>Wow!  At first I assumed that it was just using InfiniBand for inter-controller communication, but this is a real InfiniBand connection to the host.  Cool.  Thanks for sharing.

BTW, did you mean to post this in the &lt;a href=&quot;http://storageadvisors.adaptec.com/2005/12/03/infiniband-history/&quot;&gt;InfiniBand thread&lt;/a&gt;?.  No big deal either way.  Like you said, both threads are pretty stale.  But extra points to you for finding it and commenting!  :-)</description>
		<content:encoded><![CDATA[	<p>Wow!  At first I assumed that it was just using InfiniBand for inter-controller communication, but this is a real InfiniBand connection to the host.  Cool.  Thanks for sharing.</p>
	<p>BTW, did you mean to post this in the <a href="http://storageadvisors.adaptec.com/2005/12/03/infiniband-history/">InfiniBand thread</a>?.  No big deal either way.  Like you said, both threads are pretty stale.  But extra points to you for finding it and commenting!  <img src='http://storageadvisors.adaptec.com/wp-images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' />
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Tom&#8217;s got nice SAS by: Trevor</title>
		<link>http://storageadvisors.adaptec.com/2006/04/10/toms-hardware-loves-sas/#comment-28841</link>
		<pubDate>Fri, 26 Jan 2007 18:34:23 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2006/04/10/toms-hardware-loves-sas/#comment-28841</guid>
					<description>This thread is a little stale, but I'll tack on anyway.
Well, it looks like your wish has come true XiraNet now has a device that supports both 10 GB and Infiniband.

http://www.xiranet.com/43.0.html</description>
		<content:encoded><![CDATA[	<p>This thread is a little stale, but I&#8217;ll tack on anyway.<br />
Well, it looks like your wish has come true XiraNet now has a device that supports both 10 GB and Infiniband.</p>
	<p><a href='http://www.xiranet.com/43.0.html' rel='nofollow'>http://www.xiranet.com/43.0.html</a>
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Tom&#8217;s got nice SAS by: Tom</title>
		<link>http://storageadvisors.adaptec.com/2006/04/10/toms-hardware-loves-sas/#comment-460</link>
		<pubDate>Tue, 25 Apr 2006 14:32:14 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2006/04/10/toms-hardware-loves-sas/#comment-460</guid>
					<description>Are you talking about a SAS-to-SAS RAID controller that also has an Ethernet option?  If so, I agree completely.  That's exactly how remote replication should be done.  SAS doesn't have the required cable lengths to even get out of the rack, and FC is just rediculously expensive.  iSCSI, or some other proprietary protocol, is the way to go.  Unfortunately it requires either a TOE or a big improvement in the SAS RAID CPU to get decent performance.  But as x86 prices come down, and the x86 CPUs and chipsets become more integrated, even the cheapest controller will have a a ton of GHz to throw at the problem.

TT</description>
		<content:encoded><![CDATA[	<p>Are you talking about a SAS-to-SAS RAID controller that also has an Ethernet option?  If so, I agree completely.  That&#8217;s exactly how remote replication should be done.  SAS doesn&#8217;t have the required cable lengths to even get out of the rack, and FC is just rediculously expensive.  iSCSI, or some other proprietary protocol, is the way to go.  Unfortunately it requires either a TOE or a big improvement in the SAS RAID CPU to get decent performance.  But as x86 prices come down, and the x86 CPUs and chipsets become more integrated, even the cheapest controller will have a a ton of GHz to throw at the problem.</p>
	<p>TT
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Tom&#8217;s got nice SAS by: Allen</title>
		<link>http://storageadvisors.adaptec.com/2006/04/10/toms-hardware-loves-sas/#comment-435</link>
		<pubDate>Mon, 24 Apr 2006 23:14:09 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2006/04/10/toms-hardware-loves-sas/#comment-435</guid>
					<description>&amp;#62;&amp;#62; a dual-ported JBOD enclosure is probably most interesting
&amp;#62;&amp;#62; behind a dual-controller RAID enclosure

That's the killer app for SAS.  The high throughput/low latency and low cost of U320 with the natural and easy fault tolerance of FC and the flexibility of iSCSI [1].  Whichever tier 1 storage vendor builds it first will make their year early.

It was said this way in another article: &quot;SAS is the SAN people really want.&quot;  I know I do.

[1] iSCSI is here to stay regardless of SAS for two reasons, WAN being only the most obvious.  Less obvious: true block level access for Virtual Machines.  There's no other (good) way to do this with without bending things a lot.  Google this to see what I mean:

iscsi site:vmware.com

Quarter TiB .vhd files are cool in a perverse sort of way, but they are effectively opaque to the rest of the system.  Is there a reason a SAS RAID head/enclosure couldn't also have a few (optional, user installable, thank you) Ethernet ports to leverage the perfectly good RAID engine...?</description>
		<content:encoded><![CDATA[	<p>&gt;&gt; a dual-ported JBOD enclosure is probably most interesting<br />
&gt;&gt; behind a dual-controller RAID enclosure</p>
	<p>That&#8217;s the killer app for SAS.  The high throughput/low latency and low cost of U320 with the natural and easy fault tolerance of FC and the flexibility of iSCSI [1].  Whichever tier 1 storage vendor builds it first will make their year early.</p>
	<p>It was said this way in another article: &#8220;SAS is the SAN people really want.&#8221;  I know I do.</p>
	<p>[1] iSCSI is here to stay regardless of SAS for two reasons, WAN being only the most obvious.  Less obvious: true block level access for Virtual Machines.  There&#8217;s no other (good) way to do this with without bending things a lot.  Google this to see what I mean:</p>
	<p>iscsi site:vmware.com</p>
	<p>Quarter TiB .vhd files are cool in a perverse sort of way, but they are effectively opaque to the rest of the system.  Is there a reason a SAS RAID head/enclosure couldn&#8217;t also have a few (optional, user installable, thank you) Ethernet ports to leverage the perfectly good RAID engine&#8230;?
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Tom&#8217;s got nice SAS by: Tom</title>
		<link>http://storageadvisors.adaptec.com/2006/04/10/toms-hardware-loves-sas/#comment-411</link>
		<pubDate>Mon, 24 Apr 2006 13:24:06 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2006/04/10/toms-hardware-loves-sas/#comment-411</guid>
					<description>Allen,

IMHO, I see three ways to use a JBOD box with redundant IO modules:

(1) Single controller in the host, connected via two redundant cables to the enclosure.  This allows cable failover.

(2) Dual controllers in the host, each connected via a single cable to the enclosure.  This allows controller failover.

(3) Dual servers, each with a controller connected via a single cable (or perhaps dual) to the enclosure.  This allows server failover.

Starting in reverse order, the dual server approach smells like clustering.  And Microsoft is not interested in propogating support of PCI RAID clustering with SAS.  Pity, since the cabling is so much nicer than SCSI.  I made a &lt;a href=&quot;http://storageadvisors.adaptec.com/2005/10/24/is-pci-raid-clustering-finally-dead/&quot;&gt;post&lt;/a&gt; on this topic earlier.

Dual controllers in a server is interesting, but probably overkill.  Controllers don't/shouldn't go bad.  Servers (due to power supplies, fans, etc.) and cables go bad.  So I'm not crazy about this solution.  Plus, it requires an MPIO framework under Windows, and I'm not sure what framework under Linux.

So that leaves us with the first usage, which I think is the most interesting.  Cables do fail and they do fall out.  Or someome yanks the wrong cable.  And it's not hard to support this feature - the RAID controller &quot;just&quot; needs to support detecting the same storage via multiple paths, and then avoid presenting twice the amount of real storage to the host.  If a cable fails, then the controller either &quot;remembers&quot; the other path to the storage, or re-detects the topology and finds the remaining path.

Another cool use of the dual paths is for added performance, i.e., using both paths to actively transfer data.  But this is probably a little over the top since a 4X SAS cable can already support 1.2GB/s and a TON of random IOPs.

Lastly, and I think you referred to this in your comment, a dual-ported JBOD enclosure is probably most interesting behind a dual-controller RAID enclosure, such as a FC-to-SAS or iSCSI-to-SAS enclosure.  (And someday a SAS-to-SAS enclosure for great performance and the lowest cost point.)  In this configuration, each RAID controller would connect to the dual-ported JBOD enclosure for cable and controller redundancy.

This is all great stuff, because I believe that most people with multiple servers go down the expensive FC SAN road because that was their only choice.  SAS makes a lot more sense - especially if you can use cheap &lt;a href=&quot;http://storageadvisors.adaptec.com/2005/12/16/can-sata-breach-the-chasm/&quot;&gt;SATA drives protected by RAID-6&lt;/a&gt;.

Thanks for reading.

TT</description>
		<content:encoded><![CDATA[	<p>Allen,</p>
	<p>IMHO, I see three ways to use a JBOD box with redundant IO modules:</p>
	<p>(1) Single controller in the host, connected via two redundant cables to the enclosure.  This allows cable failover.</p>
	<p>(2) Dual controllers in the host, each connected via a single cable to the enclosure.  This allows controller failover.</p>
	<p>(3) Dual servers, each with a controller connected via a single cable (or perhaps dual) to the enclosure.  This allows server failover.</p>
	<p>Starting in reverse order, the dual server approach smells like clustering.  And Microsoft is not interested in propogating support of PCI RAID clustering with SAS.  Pity, since the cabling is so much nicer than SCSI.  I made a <a href="http://storageadvisors.adaptec.com/2005/10/24/is-pci-raid-clustering-finally-dead/">post</a> on this topic earlier.</p>
	<p>Dual controllers in a server is interesting, but probably overkill.  Controllers don&#8217;t/shouldn&#8217;t go bad.  Servers (due to power supplies, fans, etc.) and cables go bad.  So I&#8217;m not crazy about this solution.  Plus, it requires an MPIO framework under Windows, and I&#8217;m not sure what framework under Linux.</p>
	<p>So that leaves us with the first usage, which I think is the most interesting.  Cables do fail and they do fall out.  Or someome yanks the wrong cable.  And it&#8217;s not hard to support this feature - the RAID controller &#8220;just&#8221; needs to support detecting the same storage via multiple paths, and then avoid presenting twice the amount of real storage to the host.  If a cable fails, then the controller either &#8220;remembers&#8221; the other path to the storage, or re-detects the topology and finds the remaining path.</p>
	<p>Another cool use of the dual paths is for added performance, i.e., using both paths to actively transfer data.  But this is probably a little over the top since a 4X SAS cable can already support 1.2GB/s and a TON of random IOPs.</p>
	<p>Lastly, and I think you referred to this in your comment, a dual-ported JBOD enclosure is probably most interesting behind a dual-controller RAID enclosure, such as a FC-to-SAS or iSCSI-to-SAS enclosure.  (And someday a SAS-to-SAS enclosure for great performance and the lowest cost point.)  In this configuration, each RAID controller would connect to the dual-ported JBOD enclosure for cable and controller redundancy.</p>
	<p>This is all great stuff, because I believe that most people with multiple servers go down the expensive FC SAN road because that was their only choice.  SAS makes a lot more sense - especially if you can use cheap <a href="http://storageadvisors.adaptec.com/2005/12/16/can-sata-breach-the-chasm/">SATA drives protected by RAID-6</a>.</p>
	<p>Thanks for reading.</p>
	<p>TT
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
