Because object storage systems differ substantially from more traditional block and file storage systems, it is critical for potential buyers to understand the technology and its benefits and pitfalls.
This article outlines the key criteria you need to consider and the questions you need to ask object storage vendors before investing in this technology.
Object storage platform options
As is the case for many infrastructure elements today, you can choose to buy pure software or pure hardware (in the form of an appliance). There are other options available for object storage, too.
If you choose a software-based object storage system, you will need hardware on which to run that system. Depending on the vendor, there may be different options. If you are a do-it-yourselfer, you can buy the software from the object storage vendor, buy your own hardware and then deploy the storage system yourself. If you go this route, make sure you understand these two key points:
- You may have two points of support, and you may need to deal with the software vendor and the hardware vendor separately. Make sure your staff is comfortable with advanced troubleshooting so they know which vendor to call and when.
- Check the software vendor's hardware compatibility list. If you buy your own hardware, make sure that the vendor's software will work with it.
You may decide that you would prefer an all-encompassing system that includes hardware and software. There are several ways you can accomplish this. First, your storage vendor may sell ready-to-run appliances. Simply buy one of those and all of your support -- hardware and software -- can come from that vendor.
Other object storage vendors take a meet in the channel approach. The storage software vendor does not actually provide the hardware, but they have agreements with various hardware providers that value-added resellers (VARs) then carry out. This prevents the software vendor from having to support hardware, but still makes it possible for a customer to get a fully working appliance that is supported by the VAR.
If you choose a software model, you then have to understand how the vendor licenses its software. Some license by the number of nodes you want to run and some license based on the amount of capacity you intend to use.
For capacity licensing, you need to ensure that you understand how the vendor defines capacity. Is the object storage vendor licensing based on raw storage consumption or is it using a post-deduplication capacity figure? Each object storage vendor is different, and the various licensing models have a tremendous impact on cost.
You may also have the option to buy cloud licenses to integrate your on-premises object storage infrastructure with cloud-based storage. Typically, these will be capacity-based licenses, but that is not always the case. Make sure you fully understand all of the licensing options the object storage vendors make available.
Typically, object storage systems will support Amazon Simple Storage Service (S3) and Swift storage access methods. Amazon S3 has been around the longest and is almost a must-have in terms of access method options. Swift has been propagated by OpenStack and is a common need, particularly for organizations that have adopted or are considering adopting OpenStack.
There's also the Cloud Data Management Interface (CDMI) access method. Created by the member companies that comprise the Storage Networking Industry Association, CDMI is an additional REST-based native access protocol for object storage systems.
For pure object storage needs, a native object storage access method is sufficient. If you need or want storage for more traditional items -- perhaps you want to use your object storage as a file server -- you need more traditional protocol support.
To this end, a number of object storage systems include Network File System (NFS) and Server Message Block (SMB)/Common Internet File System (CIFS) functionality. NFS and SMB/CIFS are sometimes natively implemented in the product. Other times, they are bolted on via gateways, which are basically servers that front end the storage and make these access methods available. It is important to understand which option your vendor has selected. Supporting a stand-alone, front-end physical or virtual appliance for SMB or NFS protocol support does add complexity to the equation and may require more staff time and knowledge.
On the security front, ask the object storage vendors if they provide encryption at rest and encryption in transit in their object storage systems.
Encryption at rest is exactly what it sounds like. When data is simply residing in storage, is it encrypted? Data in transit (also referred to as in flight) is another story. Unencrypted data is easy to intercept as it traverses a network. Ask the object storage vendors on your short list how they provide for both of these needs.
Also, find out how strong the vendor's encryption processes are. Are they using the most secure current standards available? Is there a backdoor available? A backdoor refers to a master key of sorts. Most object storage vendors do not have encryption backdoors in their systems.
Data protection and availability
You want your storage system to remain running and your data to stay safe when a hardware failure occurs. Object storage vendors offer several options.
For example, from a pure availability standpoint, some vendors continue to use RAID. Because of concerns with RAID 5, most today use some kind of double-parity scheme, such as RAID 6. But RAID 6 has a lot of capacity overhead. Requiring at least four drives, RAID 6 uses the equivalent of two disks worth of capacity for parity overhead. RAID 6 also imposes significant write performance penalties due to its need to store multiple parity bits. But RAID is a stalwart; it has been around a long time and is well-understood.
Erasure coding and replication have become popular data protection options for object storage. Replication works by storing multiple copies of data at various places in the storage cluster, but it has associated capacity and performance penalties. Erasure coding works by breaking data into small chunks and distributing those chunks around the cluster. Data can be recovered using a subset of these chunks. Recovery is much faster than when using RAID, especially for large drives. However, erasure coding is a complex, computationally intense process, and it may have performance overhead that is too great for some applications.
Perhaps the most important question you should ask vendors is "Will this product support my workload?" Different storage systems have different capabilities. Some support just disks and some support flash. There are all kinds of combinations. For example, if you are planning to deploy object storage for a workload that demands massive IOPS, you probably do not want the system that does not support flash.
Likewise, some object storage systems are not good for traditional database applications, and many are not suitable for supporting virtual machine environments. You need to have a good understanding of the workloads you intend to operate and make sure that the vendors you are talking with can support those use cases. Also, make sure you talk to reference customers about their experiences with specific workloads on the vendor's product.
It may seem strange to ask how small a system can go, but for smaller organizations, it is important to understand the entry point. If you need just a few terabytes, you do not want to buy dozens.
On the other end of the spectrum, many large companies have high-capacity needs and must continue to grow that capacity. Ask object storage vendors what their minimums and maximums are so that you can size a platform according to your needs. Because object storage is considered a high-capacity type of storage, many systems do not offer lower capacity models.
Once you have identified what features and functionality object storage systems offer and matched those to your criteria, it is time to compare the specific offerings to see which one will best fit your organization's needs.
How object storage tackles traditional storage limitations