[c-nsp] Nexus 5K optimisation for iSCSI traffic

[Matthew Melbourne]

Around 8 heads, each with 4x10G connections, and then 10G connections
to downstream integrated blade centre switches where the hosts reside.
A handful of hosts will have 1G connections (landing on the FEXes)

The heads will be distributed across four 5548P, and the hosts/blade
centres and connected to 2232PP FEXes.

I'd have to dig around to get some expected IO figures for the
storage; it will very likely be a fairly even split between
reads/writes.

Cheers,

Matt

On 5 August 2011 13:56, John Gill <johgill at cisco.com> wrote:
> Matthew,
> When you say a large deployment, can you describe the number of FEXes and
> hosts?
> Which model of FEX?
> What speed are your heads, how many connections?
> What speed are your hosts, how many connections?
> Mostly reading, writing, random?
>
> You can increase the buffer size available per port on the FEXes, but it
> would be good to know if this kind of configuration would be beneficial to
> you.  It would mean acting more in a shared manner - so any one transfer
> will have access to more buffers, but there could be contention of those
> buffers if every other port is also performing in the same manner.
>
> Regards,
> John Gill
> cisco
>
>
> On 8/5/11 7:05 AM, Matthew Melbourne wrote:
>>
>> Hi,
>>
>> We're implementing two pairs of N5Ks (and downstream N2k FEXes) to act
>> as separate iSCSI SAN fabrics, with SAN heads attached directly to
>> N5Ks and host ports (and downstream integrated blade switches)
>> connecting to the FEXes. Does anyone have any real-world experience of
>> using N5Ks for a large iSCSI deployment. I have enabled jumbo frames
>> through a network-qos policy-map as an obvious first-step, but wonder
>> whether anything can be optimised by tuning buffer sizes to
>> accommodate the bursty nature of iSCSI (etc)? This switches will only
>> be switching iSCSI traffic.
>>
>> Cheers,
>>
>> Matt
>>
>



-- 
Matthew Melbourne