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 A Series On The Same Topic

  1. Network ZEN: Do Not Tell Me About Yesterday, Tell Me About Tomorrow (9th June 2013)
  2. Network ZEN: The Same Problem can Seem Different (25th July 2011)
  3. Network ZEN - Frames or Packet (11th February 2011)
  4. Network Zen - The Flow may only be seen when it is not present. (7th February 2011)
  5. Network Zen - Standardisation and Failure (18th November 2010)
  6. Network Zen - Standardisation (17th November 2010)
  7. Network ZEN - Storage traffic isn't so Important (20th October 2010)
  8. Network ZEN: A Switch (20th April 2010)
  9. Network ZEN: OSPF or EIGRP (25th March 2010)
  10. Network ZEN: Management or Monitoring (20th January 2010)
  11. Network ZEN: Stackable or Chassis Switches (3rd August 2009)
  • 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. :)