Network ZEN – Storage Traffic Isn’t So Important

The Network Master was considering the elementals of QoS with much joy.

The student approached and asked “Master, why is that that you do not permit the Storage traffic to burst to full speed ? Is it not the most important traffic on the network ?”

The Master looked at the Student woefully.

The Student was sure and burst out: “Is it not true that Storage traffic needs a lot of bandwidth and should get priority to ensure that servers run as fast as possible ?”.

“You must contemplate the oneness of the flow and be aware of the entirety of the requirement. Consider. Do not the disks spin to serve data to the servers to serve data to users ? It is the users that are most important, and the flow of data from users to the servers that generate the meaningful interaction of data. The amount of the user data is small but most important.” the Master said equably.

“Therefore, it is vital to ensure that user data is also protected is it not ?” the Master pointed out.

The Student struggled with this and said “But Master, if the Servers cannot reach their Disks, will they not crash ?”

And the Master smiled and said “This is, of course, true. But there is a big difference between high bandwidth and guaranteed packet delivery. It is not the size of the bandwidth that determines the outcome but the balanced sharing of the flow with all services”.

And the Student laughed, because he was enlightened.

Inspiration – PFC/ETS and storage traffic: the real story – Ivan Pepelnjak – Ioshints.info –
http://blog.ioshints.info/2010/10/pfcets-and-storage-traffic-real-story.html

Other posts in the series

  1. Network ZEN: The Same Problem can Seem Different
  2. Network ZEN - Frames or Packet
  3. Network Zen - The Flow may only be seen when it is not present.
  4. Network Zen - Standardisation and Failure
  5. Network Zen - Standardisation
  6. Network ZEN - Storage traffic isn't so Important (This post)
  7. Network ZEN: A Switch
  8. Network ZEN: OSPF or EIGRP
  9. Network ZEN: Management or Monitoring
  10. Network ZEN: Stackable or Chassis Switches
About Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus

  • http://blog.ioshints.info Ivan Pepelnjak

    Namaste, oh great Master. A humble engineer would never be able to express deep thoughts so succinctly

    You’re fantastic. Already updated my post.

  • John Dias

    As a network engineer told me once, “You know, our network would be great without all this stupid user traffic on it.”

  • http://pl.atyp.us Jeff Darcy

    Unfortunately, exceeding available bandwidth does impact latency, and front-end response times are often affected by back-end (usually storage) latency. One common result of “sticking it to the storage guys” is that you end up with high-priority front-end requests being allowed in and getting queued behind earlier requests which are not able to complete fast enough because of their lower priority, leading to user-experience meltdown. In my experience, a well tuned system will give load-retiring traffic slightly higher priority than load-adding traffic.

    If you meet the Buddha on the road, kill him before he screws up your network.

    • http://etherealmind.com Greg Ferro

      The point is that for a, say 10GbE service that is sharing live data with storage data, that you must bandwidth limit storage to, say 8G, so that the link is not saturated and the slow start nature of TCP is not prevented from achieving full speed.

      If you find Buddha in your program, I hope you are listening.