If “data is the new oil,” it’s no stretch to say that data is an organization’s second most valuable resource—after its people, of course. As data grows, companies are increasingly employing #softwaredefinedstorage as a means to reduce costs and increase agility for digital business. A primary benefit of software defined storage is that it has built-in data-protection mechanisms. Bolted-on #dataprotection infrastructure is unneeded. These modern storage systems implement data protection in three main ways: RAID, erasure coding and replication. You also must decide the granularity at which you want to protect data. For example, some systems protect it at an object or file level, whereas others split the file or data into manageable chunks and apply the data-protection method on top of it. In short: you have many choices. Which method or combination of methods is right for you? Here’s a primer on the pros and cons of different ways to protect data in the enterprise. Storage Data Protection: RAID RAID is the data-protection technology that everyone loves to hate. It’s a familiar concept and great articles describe it in detail if you need a crash course. I’d like to clarify some basic points for this discussion, though (some implementations differ, but this overview is general): RAID is set on a disk-group level RAID rebuilds an entire disk from a mix of data and parity RAID10 lacks parity, so it’s the most efficient, and it’s simply a replica of the write Other RAID types use a form of parity Let’s talk a bit about parity. It’s actually a simple concept: at a basic level, the parity is the evenness or oddness of a number, so a data stripe of 0101 would have a parity of 0 (since 0+1+0+1 is even), but 1101 would have a parity of 1 (since 1+1+0+1 is odd). So the more parity bits we add, the greater the overhead—but also the greater the data protection. The industry’s generally agreed-on standards are the following: RAID0: 1x write penalty RAID10: 2x write penalty RAID5: 4x write penalty RAID6: 5x write penalty Parity is generally implemented with CRC error correction as well, so it’s more than just resilient against data loss: it can also perform error correction. In-line error correction for every read creates unmanageable overhead, so generally it’s just used as a background housekeeping process. Most storage vendors get around the whole write-penalty issue by sticking a big battery of flash-backed write cache in front, allowing writes to be immediately confirmed before the complicated bit of RAID calculation is done. The biggest problem with RAID is the time it takes to do a rebuild. It’s sloooooowww! RAID calculations are expensive, and we’re limited on how many disks we can target for a rebuild because of RAID group limitations. This situation prevents many storage vendors from using drives of more than about 2TB because a rebuild can take days. RAID is useful when you have a small number of disks. Perhaps you have a RAID card that can offload the overhead, and you want simple hardware-implemented data protection. A great application here is a system OS of a physical machine where you don’t want to lose the data, but maybe you don’t want to boot from a SAN. Thus, you choose RAID10 for the best protection with minimal overhead. Storage Data Protection: Erasure Coding The method I find most helpful in explaining erasure coding is to think of it in human terms. The NATO phonetic alphabet, when delivered in a high-loss environment (say a loud concert or over a high-static radio), enables the receiver to still reconstruct the message. If all you hear is “…TEL, ***, ...LTA, VICT…, ..NDI.., …OLF,” you should be able to reconstruct it as spelling out “hotel, ___, delta, victor, india, golf,” and reconstruct the message as “HEDVIG.” This capability is due to the additional information in the message that allows you to reconstruct that message. This approach is more efficient than just shouting “Hedvig” repeatedly until you confirm receipt (which could also involve a lot of repeated shouting—think of it as TCP over a really bad network). This example is contrived, but it makes the concept easier to understand. Data is typically erasure coded with something like a 10/16 ratio (every 10 bits of data is encoded into 16 bits), which is about a 1.5x hit on raw capacity (1.6 to be precise, but 1.5 is easier to calculate and compare quickly). This ratio provides the ability to lose six parts of the data before it is unrecoverable. All data is generally encoded, meaning the parity is distributed and any remaining data blocks can be used to recover the whole data set. The locality of this data is important: in 10/16 terms, if I have more than 6 bits of the data in the same component, I’m putting my data at risk of loss. Erasure coding is generally implemented with RAIN (redundant array of independent nodes), which means my 16 bits of data are spread across multiple nodes. Since I can lose a maximum of 6 bits, my minimum number of RAIN nodes for node redundancy is 3 (16/3 = 5ish, less than 6). Erasure coding has a write penalty that depends on the encoding ratio. Going back to our 10/16 examples means that for every 10 bits of data, I’m encoding and ultimately writing 16 bits to disk. Additionally, because all the data bits are encoded, there’s also a read penalty. The result of these penalties is that the application experiences a performance dip. Thus, we commonly see erasure coding used in backup and archive systems, as well as object-based storage. They aren’t designed to be high-performance Tier One systems, so the performance overhead is acceptable given the data protection and increased storage efficiency. Also important to note is that most storage systems that use erasure coding take the performance penalty into consideration in their sizing, so the performance overhead may be masked by the platform’s capabilities. Importantly, this approach is resilient to erasure (hence the name)—that is, to missing data. If any part of the data is changed (in an error event), erasure coding may fail to recover it. The crucial difference here is erasure coding versus error correction. Error correction is generally handled by creating a hash/checksum of some part of the original data, or data blocks, written to disk so that when they’re restored, we can confirm they’re valid. A final note on erasure coding: it’s an old technology. The Reed-Solomon codes were invented in the 1960s and thankfully are available in the public domain, so many people implement this approach. Although it’s inefficient for writes, it’s the best proven in data protection. Writing an erasure-coding algorithm is difficult, and you must be sure the chance of checksum collisions (which can mean data corruption) and the robustness of the algorithm for rebuilds are well tested. Owing to the performance overhead of Reed-Solomon and the fact that most modern erasure-coding techniques have been patented, everyone has a unique implementation, although the above concepts generally ring true universally. Erasure coding is typically great for single-site backup, archive and object data. A high-performance system is unnecessary, but you want to be efficient in a single location. Although geographically distributed erasure coding exists, reads and writes must cross the wire, exacerbating the performance impact. Rebuilds take place across an entire RAIN cluster, so they’re also fast despite including a parity rebuild. I’m generalizing, though, as erasure-coding implementations come in many diverse flavors. Storage Data Protection: Replication Replication is a fairly easy concept: every write is broken up into parts (as with erasure coding and RAID) and then each bit of data is copied to two or more locations. (To be clear, I’m considering replication that’s synchronous to the write, not a background process.) The replication factor (RF) may be hard coded or user selectable, depending on vendor implementation. The overhead is simple to calculate: it’s either the number of writes you’re making or the quorum of writes that satisfies a majority. So for an RF of 3, the majority set is 2; for 4 it’s 3; for 5 it’s also 3; and so on. Replication has the ability (much like erasure coding) to be logically replicated and striped across multiple devices and nodes in a RAIN architecture. It therefore makes data protection easy but also takes advantage of data locality. The entire data set can be pulled from a single location or from multiple locations. This feature is less relevant to single-site companies (although still important if you want close data locality in hyperconverged solutions), but it comes into its own with multisite use, where you can have any workload in any location and access (reads and writes) to the local storage nodes. Although replication is generally implemented with a CRC check (or simple checksum), it also comes with a built-in level of error checking that doesn’t need an expensive checksum test. If the replication factor is three or greater, we have a quorum. If one data bit is flipped or corrupted, we have a quorum of other data bits that show the error and can be repaired with a simple new replica. Think of replication as the modern replacement for legacy RAID systems; we’re seeing it across the industry (in various and sometimes bizarre ways!). The main advantages of replication are the following: Little or no impact on writes (owing to clever caching mechanisms) Accelerated reads owing to distributed design Rapid rebuilds Active workloads across multiple sites Stretched clustering Minimal impact on failure events Why Choose Just One? Select Systems With Multiple Data-Protection Methods In today’s digital era, it’s imperative to ensure your organization’s data is protected, no matter which of these three methods you choose. Downtime can cost tens of thousands of dollars per minute in lost revenue, and as enterprises embrace digital transformation and software-defined storage, data protection can’t be an afterthought. Modern storage systems, and especially software-defined storage systems based on distributed architectures, can employ two or even all three of these data-protection methods. This capability allows you to select the method that best applies to the workload or the application whose data you’re protecting. Gone are the days when a one-size-fits-all approach will work. RAID and replication are perfect for primary data sets and production environments; erasure coding and less rigorous replication (e.g., RF = 2) are perfect for secondary data sets and test/development environments. The beauty of software-defined storage is that it’s policy driven. Assess the performance and availability needs of your apps and choose RAID, erasure coding and replication as necessary.
No comments:
Post a Comment