More than 1,200 people have already watched our Ethernet Storage Forum (ESF) Great Storage Debate webcast "File vs. Block vs. Object Storage." If you haven't seen it yet, it's available on demand. This great debate generated many interesting questions. As promised, our experts have answered them all here. Q. What about the encryption technologies on file storage? Do they exist, and how do they affect the performance compared to unencrypted storage? A. Yes, encryption of file data at rest can be done by the storage software, operating system, or the drives themselves (self-encrypting drives). Encryption of file data on the wire can be done by the storage software, OS, or specialized network cards. These methods can usually also be applied to block and object storage. Encryption requires processing power so if it's done by the main CPU it might affect performance. If encryption is offloaded to the HBA, drive, or SmartNIC then it might not affect performance. Q. Regarding block size, I thought that block size settings were also used to tune and optimize file protocol transfer, for example in NFS, am I wrong? A. That is correct, block size refers to the size of data in each I/O and can be applied to block, file and object storage, though it may not be used very often for object storage. NFS and SMB both let you specific block I/O size. Q. What is the main difference between object and file? Is it true that File has a hierarchical structure, while object does not? A. Yes that is one important difference. Another difference is the access method--folder/file/offset for files and key-value for objects.   File storage also often allows access to specific data within a file and in many cases shared writes to the same file, while object storage typically offers only shared reads and most object storage systems do not allow direct updates to existing objects. Q. What is the best way to backup a local Object store system? A. Most object storage systems have built-in data protection using either replication or erasure coding which often replicates the data to one or more remote locations. If you deploy local object storage that does not include any remote replication or erasure coding protection, you should implement some other form of backup or replication, perhaps at the hardware or operating system level. Q. I feel that this discussion conflates object storage with cloud storage features, and presumes certain cloud features (for example security) that are not universally available or really part of Object Storage.   This is a very common problem with discussions of objects -- they typically become descriptions of one vendor's cloud features. A. Cloud storage can be block, file, and/or object, though object storage is perhaps more popular in public and private cloud than it is in non-cloud environments. Security can be required and deployed in both enterprise and cloud storage environments, and for block, file and object storage. It was not the intention of this webinar to conflate cloud and object storage; we leave that to the SNIA Cloud Storage Initiative (CSI). Q. How do open source block, file and object storage products play into the equation? A. Open source software solutions are available for block, file and object storage. As is usually the case with other open-source, these solutions typically make storage (block, file or object) available at a lower acquisition cost than commercial storage software or appliances, but at the cost of higher complexity and higher integration/support effort by the end user. Thus customers who care most about simplicity and minimizing their integration/support work tend to buy commercial appliances or storage software, while large customers who have enough staff to do their own storage integration, testing and support may prefer open-source solutions so they don't have to pay software license fees. Q. How is data [0s and 1s in hard disk] converted to objects or vice versa? A. In the beginning there were electrons, with conductors, insulators, and semi-conductors (we skipped the quantum physics level of explanation). Then there were chip companies, storage companies, and networking companies. Then The Storage Networking Industry Association (SNIA) came along... The short answer is some software (running in the storage server, storage device, or the cloud) organizes the 0s and 1s into objects stored in a file system or object store. The software makes these objects (full of 0s and 1s) available via a key-value systems and/or a RESTful API. You submit data (stream of 1s and 0s) and get a key-value in return. Or you submit a key-value and get the object (stream of 1s and 0s) in return. Q. What is the difference (from an operating system perspective where the file/object resides) between a file in mounted NFS drive and object in, for example Google drive? Isn't object storage (under the hood) just network file system with rest API access? A. Correct--under the hood there are often similarities between file and object storage. Some object storage systems store the underlying data as file and some file storage systems store the underlying data as objects. However, customers and applications usually just care about the access method, performance, and reliability/availability, not the underlying storage method. Q. I've heard that an Achilles' Heel of Object is that if you lose the name/handle, then the object is essentially lost.   If true, are there ways to mitigate this risk? A. If you lose the name/handle or key-value, then you cannot access the object, but most solutions using object storage keep redundant copies of the name/handle to avoid this. In addition, many object storage systems also store metadata about each object and let you search the metadata, so if you lose the name/handle you can regain access to the object by searching the metadata. Q. Why don't you mention concepts like time to first byte for object storage performance? A. Time to first byte is an important performance metric for some applications and that can be true for block, file, and object storage. When using object storage, an application that is streaming out the object (like online video streaming) or processing the object linearly from beginning to end might really care about time to first byte. But an application that needs to work on the entire object might care more about time to load/copy the entire object instead of time to first byte. Q. Could you describe how storage supports data temperatures? A. Data temperatures describe how often data is accessed, where "hot" data is accessed often, "warm" data occasionally, and "cold" data rarely. A storage system can tier data so the hottest data is on the fastest storage while the coldest data is on the least expensive (and presumably slowest) storage. This could mean using block storage for the hot data, file storage for the warm data, and object storage for the cold data, but that is just one option. For example, block storage could be for cold data while file storage is for hot data, or you could have three tiers of file storage. Q. Fibre channel uses SCSI. Does NVMe over Fibre Channel use SCSI too? That would diminish NVMe performance greatly. A. NVMe over Fabrics over Fibre Channel does not use the Fibre Channel Protocol (FCP) and does not use SCSI. It runs the NVMe protocol over a FC-NVMe transport on top of the physical Fibre Channel network.   In fact none of the NVMe over Fabrics options use SCSI. Q. I get confused when some one says block size for block storage, also block size for NFS storage and object storage as well. Does block size means different for different storage type? A. In this case "block size" refers to the size of the data access and it can apply to block, file, or object storage. You can use 4KB "block size" to access file data in 4KB chunks, even though you're accessing it through a folder/file/offset combination instead of a logical block address. Some implementations may limit which block sizes you can use. Object storage tends to use larger block sizes (128KB, 1MB, 4MB, etc.) than block storage, but this is not required. Q. One could argue that file system is not really a good match for big data. Would you agree? A. It depends on the type of big data and the access patterns. Big data that consists of large SQL databases might work better on block storage if low latency is the most important criteria. Big data that consists of very large video or image files might be easiest to manage and protect on object storage. And big data for Hadoop or some machine learning applications might work best on file storage. Q. It is my understanding that the unit for both File Storage & Object storage is File - so what is the key/fundamental difference between the two? A. The unit for file storage is a file (folder/file/offset or directory/file/offset) and the unit for object storage is an object (key-value or object name). They are similar but not identical. For example file storage usually allows shared reads and writes to the same file, while object storage usually allows shared reads but not shared writes to the object. In fact many object storage systems do not allow any writes or updates to the middle of an object--they either allow only appends to the end of the object or don't allow any changes to an object at all once it has been created. Q. Why is key value store more efficient and less costly for PCIe SSD? Can you please expand? A. If the SSD supports key-value storage directly, then the applications or storage servers don't have to perform the key-value translation. They simply submit the key value and then write or read the related data directly from the SSDs. This reduces the cost of the servers and software that would otherwise have to manage the key-value translations, and could also increase object storage performance. (Key-value storage is not inherently more efficient for PCIe SSDs than for other types of SSDs.) Interested in more SNIA ESF Great Storage Debates? Check out:

• Fibre Channel vs. iSCSI
• FCoE vs. iSCSI vs. iSER

If you have an idea for another storage debate, let us know by commenting on this blog. Happy debating!

When it comes to storage, a byte is a byte is a byte, isn't it? One of the enduring truths about simplicity is that scale makes everything hard, and with that comes complexity. And when we're not processing the data, how do we store it and access it? The only way to manage large quantities of data is to make it addressable in larger pieces, above the byte level. For that, we've designed sets of data management protocols that help us do several things: address large lumps of data by some kind of name or handle, organize it for storage on external storage devices with different characteristics, and provide protocols that allow us to programmatically write, find, and read it. On April 17^th, the SNIA Ethernet Storage Forum will host another of its "Great Debates" webcasts. This time, it's "File vs. Block vs. Object Storage." In this live webcast, our experts, Mark Carlson, Alex McDonald and Saqib Jang will compare three types of data organization: file, block and object storage, and the access methods that support them. Each has its own set of use cases, advantages and disadvantages. Each provides data management ranging from simple to sophisticated, and each makes different demands on storage devices and programming technologies. Perhaps you're comfortable with block and file, but are interested in investigating the more recent class of object storage and access. Perhaps you're happy with your understanding of objects, but would really like to understand files a bit better. Or perhaps you want to understand how file, block and object are implemented on the underlying storage systems – and how one can be made to look like the other, depending on how the storage is accessed. Join us as we discuss and debate:

• Storage devices
  • How different types of storage drive different management & access solutions
  • Which use cases tend to favor block, file or object
• Block
  • Where everything is in fixed-size chunks
  • SCSI and SCSI-based protocols, and how FC and iSCSI fit in
• Files
  • When everything is a stream of bytes
  • NFS and SMB
• Objects
  • When everything is a BLOB
  • HTTP, key value and RESTful interfaces
• Altogether...
  • When files, blocks and objects collide, it will rock your world!

I will be moderating this "friendly debate" where there won't be winners or losers, just more information on these three popular data storage technologies. We hope you will register today to come join the debate on April 17^th. And if you missed our first hugely popular "Great Debate" – Fibre Channel vs. iSCSI, it's now available on-demand.

Today's storage world would appear to have been divided into three major and mutually exclusive categories: block, file and object storage. The marketing that shapes much of the user demand would appear to suggest that these are three quite distinct animals, and many systems are sold as exclusively either SAN for block, NAS for file or object. And object is often conflated with cloud, a consumption model that can in reality be block, file or object. A fixed taxonomy that divides the storage world this way is very limiting, and can be confusing; for instance, when we talk about cloud. How should providers and users buy and consume their storage? Are there other classifications that might help in providing storage solutions to meet specific or more general application needs? What about customers who need file access performance beyond what one storage box can provide? Which options support those who want scale-out solution like object storage with file protocol semantics? To clear up the confusion, the SNIA Ethernet Storage Forum is hosting a live Webcast, "Clustered File Systems: No Limits." In this Webcast we will explore clustered storage solutions that not only provide multiple end users access to shared storage over a network, but allow the storage itself to be distributed and managed over multiple discrete storage systems. You'll hear:

• General principles and specific clustered and distributed systems and the facilities they provide built on the underlying storage
• Better known file systems like NFS, IBM Spectrum Scale (GPFS) and Lustre, along with a few of the less well known
• How object based systems like S3 have blurred the lines between them and traditional file based solutions

This Webcast should appeal to those interested in exploring some of the different ways of accessing & managing storage, and how that might affect how storage systems are provisioned and consumed. POSIX and other acronyms may be mentioned, but no rocket science beyond a general understanding of the principles of storage will be assumed. Contains no nuts and is suitable for vegans! As always, our experts will be on hand to answer your questions on the spot. Register now for this October 25^th event. Update: If you missed the live event, it's now available  on-demand. You can also  download the webcast slides.

The team at SNIA-ESF and I were very pleased with how many people attended our live "Block Storage in the Open Source Cloud called OpenStack." If you missed it, please check it out on demand. We had several great questions during the live event. As promised here are answers to all of them. If you have additional questions, please feel free to comment on this blog. Q. How is the support for OpenStack, if we hit a roadblock or need some features? A. The OpenStack community has many avenues for contacting developers for support. The official place to report issues, file bugs or ask for new features is Launchpad. https://launchpad.net/openstack. It is the central place for all of the many OpenStack projects to file bugs or feature requests. This is also the location where every OpenStack project tracks its current release cycle and all of the features, called blueprints. Another good source of information are the public mailing lists. A good place to start for the mailing list is here, https://wiki.openstack.org/wiki/Mailing_Lists. Finally, developers are also on the public Internet Relay Chat channels associated with their projects. The developers are live and interactive, on each of the channels. You can find the information about the IRC system that OpenStack developers use here: https://wiki.openstack.org/wiki/IRC. Q. Why was Python chosen as the programming language? Which version of Python is used as there are incompatibilities between versions? A. The short answer here is that Python is a great language for rapid development and deployment that is mature and has a wide variety of publicly available libraries for doing work. The current released version of OpenStack uses Python 2.7. The OpenStack community is making efforts to ensure that we can eventually migrate to Python 3.x. New libraries that are being developed have to be Python 3.x compatible. Q. Is it possible to replicate the backed up volumes at the OpenStack layer or do you defer to the back end array for data replication? A. Currently, there is no built in support for volume replication in Cinder. The Cinder community is actively working on how to implement volume replication in the next release Liberty, which will ship in the fall of 2015. As with any major new feature in Cinder, the community has to design the new feature core such that it works with the 40+ vendor arrays, in such a way that it's consistent. As the array support grows, the amount of up front design becomes more and more important and difficult at the same time. We have a specification that we are currently working on that will get us closer to implementing replication. Q. Who, or what, creates the FC zones? A. In Cinder, the block storage project, the component that creates and manages Fibre Channel zones is called the Fibre Channel Zone manager. A good document to read up on the zone manager is here: http://www.brocade.com/downloads/documents/at_a_glance/fc-zone-manager-ag.pdf. The official OpenStack documentation on the zone manager is here: http://docs.openstack.org/kilo/config-reference/content/section_fc-zoning.html. The zone manager is automatically called after Cinder Fibre Channel volume driver exports its volume from the array. The zone manager then adds the zones as requested by the driver to make the volume available to the virtual machine. Q. Does the Cinder and Nova attachment process work over VLANs? A. Yes. It's entirely dependent on how the OpenStack admin deploys the Nova and Cinder services. As long as the Nova hosts can see the Cinder services and arrays behind the Cinder volume drivers, then it should just work. Q. Is the FCZM a native component of the Cinder project? Or is it an add-on? A. As I mentioned earlier, the Fibre Channel zone manager is part of the Cinder project. There has been some discussions, as part of the Cinder community, to possibly break out the zone manager into it's own Python library, in which case it would be available to any Python project. Currently, it's built into Cinder itself. Q. Does Cinder involve itself in the I/O path as well or is it only the control path responsible for allocating storage? A. Cinder is almost entirely control plane provisioning mechanism only. There are a few operations where the Cinder services actually does I/O. When a user wants to create an image from a volume, then Cinder attaches the volume to itself, and then copies the bytes from the volume into an image. Cinder also has a backup service that allows a user to backup a volume to an external service. In that case, the Cinder backup service directs copying the bytes into the configured backup storage. When Cinder attaches a volume to a Nova VM, or a bare metal node, Cinder is not involved in any I/O. Cinder's job is to simply ensure that the volume is exported from the back-end array and make it available to Nova to see. After that, it's entirely up to the transport protocol, iSCSI, FC, NFS, etc. to do the I/O for the volume. Q. Is Nova aware of the LUN usage %? A. Nova doesn't track statistics against the volumes that it has attached to its virtual machines. Q. Where do the vendor specific parts of Cinder fit in? Are there vendor specific "volume managers"? A. The vendor specific components of Cinder exist in what are called Cinder volume drivers.     Those drivers are really nothing more than a python module that conforms to a volume driver API that is defined by the Cinder volume manager. You can get an idea of what the features that the drivers can support on the Cinder Support Matrix here: https://wiki.openstack.org/wiki/CinderSupportMatrix Q. If Cinder is only for control plane, which project in OpenStack is for data path? A. There isn't a project in OpenStack that manages the data path for volumes. Q. Is there a volume detachment process as well and when does that come into play? A. My presentation primarily focused around one aspect of the interaction between Nova and Cinder, which was volume attachment. I briefly discussed the volume detachment process, but it is conducted in basically the same way. An end user asks Nova to detach the volume. Nova then removes the volume from the VM, then removes the SCSI device from the compute host itself, and then tells Cinder to terminate the connection from the array to the compute host. Q. If a virtual machine is moved to a different physical machine, how's that handled in Cinder? A. This process in OpenStack is called live migration. Nova does all of the work of moving the VM's data, from one host to another. One facet of that is migrating any Cinder volume that may be attached to the VM. Nova understands which volumes are attached to the VM and knows which one of those volume(s) are Cinder volumes. When the VM is migrated, Nova coordinates with Cinder to ensure that all volumes are attached to the destination host and VM, as well as ensures that the volumes are detached from the originating compute host. Q. Why doesn't Cinder use SNIA SMI-S API to manage/consume SAN, NAS or Switch fabric instead of each storage vendor building Cinder drivers? SMI already covers all scenarios for the Cinder scenarios for FC, iSCSI, SAS etc. A. Cinder itself doesn't really manage the storage array communication itself. It's entirely up to the individual vendor drivers to decide how best to communicate with its storage array. The HP 3PAR volume driver uses REST to communicate with the array, as do several other vendor drivers in Cinder. Other drivers use ssh. There are no strict rules on how a Cinder volume driver can choose to communicate with its back-end. This allows vendors to make the best use of their array interfaces as they see fit. Q. Are there Horizon extensions or extension points for showing what physical resources your storage is coming from? Or is that something a storage vendor would need to implement? A. Horizon doesn't really know much about where storage is coming from other than it's a Cinder volume. Horizon uses the available Cinder APIs to talk to Cinder to do work and fetch information about Cinder's resources. I know of a few vendors that are writing Horizon plugins that add extra capabilities to view more detailed information about their specific array. As of today though, there is no API in Cinder to describe the internals of a volume on the vendor's array.            

On June 3^rd at 10:00 a.m. SNIA-ESF will present its next live Webcast "Block Storage in the Open Source Cloud called OpenStack." Storage is a major component of any cloud computing platform. OpenStack is one of largest and most widely supported Open Source cloud computing platforms that exist in the market today.  The OpenStack block storage service (Cinder) provides persistent block storage resources that OpenStack Nova compute instances can consume. I will be moderating this Webcast, presented by a core member of the OpenStack Cinder team, Walt Boring. Join us, as we'll dive into:

• Relevant components of OpenStack Cinder
• How block storage is managed by OpenStack
• What storage protocols are currently supported
• How it all works together with compute instances

I encourage you to register now to block your calendar. This will be a live and interactive Webcast, please bring your questions. I look forward to "seeing" you on June 3^rd