[AusNOG] DCB in non-converged networks

[Peter Tiggerdine]

I am going to buck the trend.

DCB shouldn't be enabled and configured on a whim, however, if this is for
backup, how long before these backups need to be rehydrated/booted in
another DC or moved to a second DC for business availability/continuity
purposes?

As for tuning (jumbo-frames, QoS, Flow Control) the network to the
requirements, this is still best practice (as we would for voice) -
particularly since iSCSI overhead is heavy (in comparison to FCoE).

I agree with the KISS principle, but DCBs aren't the place for that because
of the complexity that they are (the same would be said for MPLS, VXLAN,
etc) it's about business/regulatory requirements that drives a competitive
edge. Think "If you're going to do it, do it properly" is more applicable.

Regards,

Peter Tiggerdine

GPG Fingerprint: 2A3F EA19 F6C2 93C1 411D 5AB2 D5A8 E8A8 0E74 6127


On Thu, Nov 9, 2023 at 12:19 PM Robert Hudson <hudrob at gmail.com> wrote:

> I largely agree with Luke.  Given you're on a dedicated iSCSI network,
> keep it simple.  DCB and other services will only add things that you'll
> later need to troubleshoot and eliminate as the root cause of network
> issues on your iSCSI network when they invariably happen (it's rare that
> I've come across a well and consistently configured iSCSI network, and I've
> been playing in that space since the mid 2000s).  Chances are your
> OS/hypervisor vendor of choice publishes best practices for how to
> configure DCB - but as noted, DCB is specifically there to deal with
> converged networks (where your iSCSI traffic is sharing an ethernet fabric
> with other traffic types), and you don't seem to have that situation.
>
> Jumbo frames help in busy iSCSI networks by increasing throughput - but
> you need to make sure every device from one end of the communications to
> the other fully supports it.  Again, follow vendor advice here.  Getting
> this wrong can cause all sorts of "fun".
>
> Flow control, buffer tuning (large buffers tend to help with iSCSI
> traffic), etc, can all help to eke out a few more small percentage points
> of performance, but again, the further you drift from the KISS principle,
> the more fun you're likely to have troubleshooting later.
>
> Above all - set and document policy in all things, audit against that
> policy both at initial setup and for drift during the lifecycle of the
> environment.
>
> On Thu, 9 Nov 2023 at 12:20, Luke Iggleden <luke at iggleden.com> wrote:
>
>> Hi Andres,
>>
>> Unless you are running other services on the switch it's not useful.
>>
>> Typically these are the only useful changes:
>>
>> Jumbo Frames (YMMV), depends on vendor.
>>
>> Flow Control on (so hosts can issue back off - hopefully without dropping
>> frames)
>>
>> Depending on the switch, buffer tuning.
>>
>> Don't use control plane things, like MLAG, Stacking, STP, etc etc. Flat
>> fabric.
>>
>>
>> Cheers,
>>
>> Luke Iggleden
>>
>>
>> On 9/11/2023 11:14 am, Andres Miedzowicz wrote:
>>
>> Hello everyone,
>>
>>
>>
>> I wanted to get some opinions on the use of DCB and its associated
>> protocols in a storage-only (iSCSI), non-converged network. Any thoughts
>> about the pros and cons of enabling DCB in a scenario where 100% of the
>> traffic on a switch is bi-directional iSCSI storage (virtual machines and
>> backups)?
>>
>>
>>
>> Thanks in advance.
>>
>>
>>
>> Andres
>>
>> _______________________________________________
>> AusNOG mailing listAusNOG at lists.ausnog.nethttps://lists.ausnog.net/mailman/listinfo/ausnog
>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> https://lists.ausnog.net/mailman/listinfo/ausnog
>>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> https://lists.ausnog.net/mailman/listinfo/ausnog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ausnog.net/pipermail/ausnog/attachments/20231109/6300adf2/attachment.htm>