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 <hud...@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 <l...@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@lists.ausnog.nethttps://lists.ausnog.net/mailman/listinfo/ausnog >> >> _______________________________________________ >> AusNOG mailing list >> AusNOG@lists.ausnog.net >> https://lists.ausnog.net/mailman/listinfo/ausnog >> > _______________________________________________ > AusNOG mailing list > AusNOG@lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog >
_______________________________________________ AusNOG mailing list AusNOG@lists.ausnog.net https://lists.ausnog.net/mailman/listinfo/ausnog
