Lately I’ve been giving a lot of presentations about storage basics. I actually really enjoy it, because it makes me rethink some of the things that I took for granted, and it helps me understand some of the gaps in my own knowledge when questions arise.
When you think of how we do certain things for storage, such as choosing block-based (e.g., FC, FCoE, iSCSI), file-based (e.g., NFS, SMB), or object (e.g., Ceph, Swift, CDMI) storage platforms and protocols, it’s easy to ignore the why these types of storage affect our Data Center architectures and performance.
It dawned on me that I only knew a relatively small piece of the puzzle (this is never a fun realization to grok the depth of your ignorance!), because while I spoke emphatically of knowing storage end-to-end, I actually had a less-than-stellar understanding of certain bits (pun intended).
After all, if I’m going to explain more about NVMe beyond the basics, I better have a water-tight understanding of the broader storage consequences, right?
So, I went asking (trust me, it’s a lot easier to admit you don’t know everything than to actually go out and rectify the situation). Notably, I went to speak to some of Cisco’s finest, such as Joe Pelissier (Distinguished Engineer and contributor to several networking protocols, including Ethernet, Fibre Channel, and InfiniBand). After he patiently sat me down and white-boarded things out, I managed to visualize a way of understanding the relationships between parts of the whole.
To that end, allow me to work through another Napkins Dialogue on how applications communicate with their storage. The road is longer than just one Dialogue, of course, so I’m breaking it down into parts for easier digestion.
Before I begin, though, allow me to thank Joe one more time for his patience and clear explanation of most of the content that follows. (Also, in case you’re wondering why I chose a familiar-looking avatar as the narrator, it’s because I can’t draw to save my life, and this was much easier)
A pdf version of this dialogue can be found here.