Transcript
Can Legacy NAS keep pace? When it comes to managing unstructured data, the data center has problems. The legacy network attached storage (NAS) systems that it uses to store this data are no longer keeping pace with the demands of the modern data center. As a result, IT planners are considering object storage as a potential replacement for their aging NAS infrastructures. Our “ NAS vs. Object ” series will perform a detailed examination of these technologies to help IT planners decide which technology is right for their data centers.
[ 1 ]
Table Of Contents Page 3: What is Object Storage? Page 4: The Dollar Per GB Challenge by Curtis Preston Page 5: Data Archive – Long Term Data Efficiency by George Crump Page 7: Beating Bit Rot – Examining Data Durability by Curtis Preston Page 8: Data Archive – Long Term Efficiencies by Curtis Preston Page 9: Performance – Thinly Provisioned NAS by Joseph Ortiz Page 11: Protecting High File Count Systems by Joseph Ortiz Page 14: HA w/o the headaches by Curtis Preston Page 15: Supporting Next Apps by Curtis Preston Page 16: The Rise of the Machines: The Challenge with High File Count Environments by George Crump Page 18: Scaling, There’s More To it Than Just Adding Nodes by George Crump Page 19: Making the Migration by Curtis Preston Page 21: The Verdict: Legacy NAS Falls Short
[ 2 ]
Chapter 1: What Is Object Storage? Most unstructured data is stored in a POSIX (Portable Operating System Interface) file system. It is a means of organizing the way data is written to a storage system. A series of volumes, directories (also known as folders) and subdirectories is organized within the file system data. The data POSIX stores is basic, including information like date created, date changed, hierarchy, and archive status. It is also called data about data, or metadata. Object storage is also a technology that organizes the way data is written to a storage system. In it, data is written into selfcontained entities called objects. For simplicity think of an object as a file. Unlike a POSIX file system, an object storage system gives each object a unique ID, which is managed in a flat index. There are no folders and subfolders. When a user or application needs access to a file, the user or application provides the object storage system with the unique ID. This flat index provides greater scalability, enabling an object storage system to support faster access to a massively higher quantity of objects or files as compared to most POSIX based NAS counterparts. The flat organizational structure also enables object storage to provide a much richer metadata component for the object. Most object storage systems, in addition to date created and date modified information, can store expiration dates, object protection requirements as well as descriptive tagging about the objects they store. Lastly, it is possible to protect objects at the object level. POSIX file systems conversely need to protect data at a volume level. An object storage system, armed with the more granular protection layer, can protect data better on less expensive hardware and more importantly recover quicker. Object Storage: The File Server for The Modern Enterprise There is a tremendous change in unstructured data. It is no longer just user files. It now includes millions, if not billions, of machine generated files and logs. The data center needs to continue
[ 3 ]
to provide users the file sharing capabilities they require, as well as support the unprecedented growth of data generated by machines. Object storage, as we will explain in this series, may very well be the heir apparent to NAS.
[ 4 ]
Chapter 2: The Dollar Per GB Challenge by Curtis Preston, Senior Analyst Spending top dollar to store older fixed content on the typical network attached storage system (NAS) filer is more than just a waste of money — it’s actually spending more to get less. Using an objectbased storage system may be the perfect match for such content. For unstructured data (files) it has a richer feature set and is more scalable while being substantially less expensive. All data goes through some kind of lifecycle. It generally starts out with a very high value that precipitously drops within a few days or weeks. It then has very little value for a long time after which its value may suddenly spike for a variety of reasons. Unfortunately, most people store high value and low value data in the same place — tier one filers. Filers have dozens of very important and very expensive features, and performance way beyond the needs of a file that hasn’t been looked at for three years. These features and performance come at a cost. Filers also have to be backed up — further increasing your cost. Every gigabyte of primary storage is duplicated in your backup system 1020 times. And the manpower to make all these backups happen is also quite expensive. Here’s the worst part. This data explosion coupled with the typical hierarchical file system layout means that finding data if it is ever needed again may be next to impossible. While things can be done in advance to facilitate long term access, such as a solid file system hierarchy and strict naming conventions, chances are the typical person won’t have done any of those things and more than likely won’t be able to find a file when they need it. They will end up recreating the data, which is again a waste of money. In contrast, object storage systems have just the features necessary to facilitate easy storage and retrieval of the objects stored within them. Since most of the data will only be written and rarely read (if ever), they do not have to be as performant as their tier one counterparts. This makes them immediately less expensive to buy than tier one storage. Secondly, an object storage system that has file versioning and replication does not need to be backed up — because it already is. Versioning will handle any deleted or corrupted file problems, and replication will handle anything that happens during some kind of disaster. You specify exactly how many simultaneous node or site failures you want to be able to survive, and how many versions of every file you want to keep — and that’s what happens. You can exclude this data from your backup system, saving significant amounts of money.
[ 5 ]
Finally, since object storage systems store data based on its content and metadata instead of useless things like directory or filename, they are inherently better at finding random objects when you are looking for them months or years later. This saves money by reducing the amount of time it takes to find data when you need it, and even more money by removing the need to recreate the data. Conclusion An object storage system is a much more economical way to store the primary copy of fixed content. It is also an economical way to make sure that data is protected in the case of accidental deletion or damage to a disaster. Finally, it’s an ideal place to store data that you might find yourself looking for years after it was created.
[ 6 ]
Chapter 3: Data Archive – Long Term Data Efficiency by George Crump, Lead Analyst Most of the time when unstructured data is created there is never a need to access it again. But it is still necessary to store it just in case you need it. When the “just in case” scenario occurs, you need to retrieve it quickly and it has to be readable. The problem is that “justincase” may occur at anytime, from a few days after someone creates the data, to a few decades later. The storage system has to be able to store this data efficiently for a long period of time. The need for long term data efficiency is one of the reasons why network attached storage systems are giving way to object storage systems. What is Long Term Data Efficiency? Long term data efficiency means that a storage system has the ability to store a large amount of data, both in terms of capacity and number of items, for decades. But just scaling to meet the long term capacity requirement is not enough. The storage system must also maintain data integrity so that when “justincase” occurs the data is there and is readable. Finally, long term data efficiency means that the storage system can cost effectively store it from both a hardcost perspective and an operational perspective. NAS vs. Object – Which Meets The Long Term Data COST Efficiency Challenge? Except for cost, network attached storage (NAS) systems meet many of the short term problems that unstructured data creates. When it comes to long term data efficiency most NAS systems fall short. Not only are most NAS systems expensive to purchase upfront, they are also expensive to scale or upgrade. While scaleout NAS systems have the ability to spread the cost of scaling more evenly across nodes, it is still expensive. Both legacy NAS approaches require that the system is powered the entire time it is online, which means the cost to power and cool are constant. Object storage is typically software only. The software leverages offtheshelf servers and internal SSD/HDD storage. The impact is dramatically lower costs and greater hardware flexibility. Although most object storage software solutions are scaleout in design, some have the ability to not only power down storage media, they can also power down nodes. This means that the long term power and cooling costs of an object storage system can rival offline media storage like tape.
[ 7 ]
NAS vs. Object – Which Meets The Long Term Data Integrity Challenge? When “justincase” occurs, the data needs to be accessible and readable. The problem is there may be decades of time between accesses of that data. The storage system needs to have the ability to continuously verify that data written today will be the same in 10 or 20 years. While some NAS systems can scan the media for defect, most can not verify specific files. Object storage systems can leverage the unique ID applied to each object. Since that ID is generated from the data, it should always provide the same result. An object storage system can periodically recalculate the ID for an object. If the result is different than the original the system can take corrective action or notify the storage administrator. Conclusion Long term data efficiency means making sure that over the course of decades an organization can costeffectively store data, while at the same time assuring data quality. The softwarefirst nature of object storage keeps upfront and ongoing costs low and the built in data integrity ensures that when you need a file in the future you can read it.
[ 8 ]
Chapter 4: Beating Bit Rot – Examining Data Durability by Curtis Preston, Senior Analyst IT considers data durable if it survives anything that might happen to it because of how the user stores it. Typical data protection systems (e.g. backup, snapshots, replication) protect data from component, media, site, and human failure – or at least they’re supposed to. Object storage, whether from a cloud provider or onsite in the data center, can provide many of those features as well. My colleague Joseph Ortiz compares the data protection techniques of NAS vs. Object storage in chapter 7. What about Bit Rot? What typical data protection systems do not protect against is bit rot . Bit rot is a layman term applied to the concept of magnetic degradation over time. A secret (that hasn’t been kept very well) about magnetic storage is that it all degrades over time. Ones become zeros and vice versa. With any magnetic storage, it is not a matter of if the data will be corrupted – it is when. The degree to which a medium will allow bits to be coerced over time into changing polarity is called its coercivity value, and the formula to determine coercivity is KuV/kT, where V is the volume of the magnetic bit and K is the ambient temperature of that bit in Kelvin. Unfortunately for those wishing to store data for long periods of time, disk has poor values for both. (It has very small magnetic bits and disks are hot all the time.) When those values are plugged into the coercivity formula, the values that emerge suggest that data left on disk will begin to significantly degrade after five years. This means that if you are using disk as your long term storage medium, you must monitor for and repair magnetic degradation. This must be done at a level higher than the device level, because the underlying hardware layer will not detect this magnetic degradation. Object storage software is perfect for monitoring and repairing the effects of magnetic degradation, because such products use a unique identifier for each object that is the result of some type of algorithm (e.g. SHA256) being run against the contents of the object. By rerunning the algorithm against an object and comparing it against its unique identifier, the software makes sure that no bit rot corrupts the file. Caringo’s Swarm does this using proactive period health checks, which allows them to identify and correct any bit rot even before an object is requested. Other vendors check for and repair corruption when they read the file.
[ 9 ]
Another way the software ensures durability is to make sure the object can survive simultaneous node or site failures. This is done by replicating the object to multiple locations. An object that does all of these things would be considered durable even over long periods of time. Conclusion A storage product that is truly durable will be able to overcome any kind of damage that could happen to a file, which goes beyond a component or site failure. It includes protection against bit rot over time – which requires some higher level of intelligence which is provided by object storage vendors. It can also provide protection against accidental or malicious damage to the data as well. When evaluating storage vendors, make sure to look into both sides of the equation.
[ 10 ]
Chapter 5: Data Archive – Long Term Efficiencies by Curtis Preston, Senior Analyst The longer you keep data, the more it makes sense to move it off of primary storage and into a different kind of system. It makes financial sense, as discussed in chapter 2. It also makes sense for efficiency. The problem is most of the inefficiencies come from the typical design of most NAS systems. Have a bunch of unstructured data that needs storing? Buy a filer and put it there. Problem solved, right? Not so fast. An old saying is, “I loved my first filer. I loved my second filer. I hated my fifth filer.” Typical NAS do not scale. Yes, there are some scaleout NAS systems, but even then you have to create some kind of hierarchy to be able to find anything. You need a filer or mount point for each department or workgroup. Then under that mount point that work group is going to create subdirectories to organize their content. Some workgroups are better at this process than others. They create some kind of hierarchy that includes things like projects, timeframes, data types, etc. Others are very bad at it and create subdirectories that make as much sense as obfuscated code*. Whichever of these happens in a given department, time passes and people get replaced. The next person responsible for the organization of the file system might not agree with the previous person’s management system and decide to make a change. Maybe they’re better; maybe they’re worse. The result is that data older than a few months can become nearly impossible to find. The bigger your data needs are, the worse this problem becomes. Although there are some systems that can allow you to search the content of these files (instead of just their file and directory names) most searching systems are completely unable to search the content within the files of a large file hierarchy. You can waste a lot of time trying to find these older files. Worse than that is often the person is unable to find the file in question – and they end up having to recreate the work. Now the person has wasted time looking, wasted time recreating the data, and wasted more space on the already overtaxed primary storage system.
[ 11 ]
Imagine a system where there is no file system hierarchy, and data is stored and accessed according to what’s in the file. It separates the data and the metadata, allowing for much easier search of the data when it’s needed. For example, Caringo Swarm allows customers to search based on the attributes of the file, as well as against custom metadata that they can add. Objects attached to a certain project, product, or process can easily be located via such a search. Conclusion Object storage systems may not be for everyone, but they certainly make sense for those who are creating and storing significant amounts of data that need storage for very long periods of time. The more data you create and store this way, the more object storage makes sense.
[ 12 ]
Chapter 6: Performance – Thinly Provisioned NAS by Joseph Ortiz, Senior Analyst Network Attached Storage (NAS) filers were originally designed to be a central repository that provides fast access to frequently changing files on primary storage. NAS also makes it simple to add more storage capacity over existing Ethernet networks. However, the everrising tide of unstructured data, combined with legal compliance requirements that force organizations to retain much of their data for longer periods of time, have led to storage sprawl. Storage sprawl is forcing organizations to purchase more high performance storage to keep pace with the rising data flood, and continue to provide high performance access for “hot” (active) data sets. An additional problem is that a large percentage of the data most NAS systems store is cold data the organization no longer accesses, but it still consumes valuable primary storage space it needs for active data sets. While newer scaleout NAS systems make it possible to scale local storage into the petabyte range, they do so with certain limitations such as greater complexity and higher costs. What organizations need is a way to scaleout existing and new NAS acquisitions without the additional expense and complexity of traditional scaleout NAS systems. The Object Storage Alternative Object storage addresses the various challenges of NAS limitations by providing much of the same flexibility of deployment and accessibility as traditional NAS and scaleout NAS systems. But at the same time, it uses much less expensive commodity disk to build out large, multiPB storage repositories that can store an almost infinite number of files. Object storage systems also have other advantages such as erasure coding, which is a highly efficient technology that protects data while minimizing the amount of disk storage it needs while also providing faster volume rebuild times. Additionally, object storage systems store data based on its metadata and content rather than by filename and directory location. This makes it easier to find particular objects months or even years later.
[ 13 ]
A Different Approach Given the continuing need for NAS performance in dealing with “hot” data sets, a more cost effective method of scaling out a NAS system would be using a Software Defined Storage (SDS) solution that would allow you to effectively scaleout NAS capacity through thin provisioning of primary storage. It would provide support for the necessary NAS protocols, like NSF and CIFS/SMB, allowing you to couple a NAS system to scalable object storage that functions like an endless, but intelligent and resilient, JBOD (Just a Bunch of Disks) tier built on less expensive commodity hardware. Additionally, it would also provide intelligent, policy driven life cycle management that automatically handles migrating “warm” and “cold” data from primary storage to less expensive tiers. “Warm” means there is a reasonable chance someone would access this data in the near future. “Cold” means data is inactive, no one needs to access now nor probably will again. But, in the event someone needs any of this “warm” or “cold” data, it will be instantly retrievable back to the NAS high performance, primary storage tier. Conclusion With flat IT budgets and the everincreasing amount of unstructured data, as well as the high percentage of cold data consuming expensive primary storage on NAS systems, organizations clearly need a costeffective way to efficiently store and manage all this data. A strong, flexible SDS solution that facilitates the use of thin provisioning and object storage with NAS systems will provide organizations the budgetfriendly means to meet this difficult challenge.
[ 14 ]
Chapter 7: Protecting High File Count Systems by Joseph Ortiz, Senior Analyst The modern data center today is faced with storing, managing and protecting an everincreasing torrent of data, most of which needs to be stored for indefinite periods of time due to various government rules, regulations and laws. File counts have soared from hundreds of thousands past hundreds of millions and now with IoT (Internet of Things) machine generated data from sensors, surveillance cameras, etc., to billions of files and more. Today, organizations are not only struggling with the inability of legacy NAS systems to keep pace with the everincreasing flood of unstructured data, they also must deal with the reality that in spite of what storage vendors may claim, data loss in storage systems is unavoidable. To meet the challenge of storing everincreasing amounts of unstructured data, many organizations have turned to object storage, a technology that has been around for quite a few years that is able to efficiently handle very large quantities of data. And, while data loss may be unavoidable, by selecting the right solutions and applying appropriate parameters, it is possible to minimize significantly both the probability of data loss occurring as well as the size of the data loss. Data Vulnerability Physical devices like hard drives (HDD) and SSDs (Solid State Drives) can and do fail. Hardware failures can be caused by power loss to the disk while it is writing data, Undetectable Bit Errors while data is being written, and/or Unrecoverable Read Errors (URE). Software can malfunction due to power failures during operation or flaws in the program and there is also the human factor, human error or malicious intent. All of these can all result in data corruption or loss.
[ 15 ]
The First Line of Defense Data is most vulnerable when the first instance is created and written to the disk storage system. At this point there is only one copy of the data, which has not been duplicated anywhere else in the system. The data needs to be written to stable storage, such as hard disk or SSD, which does not require power to retain the data once it has been written to the media. But, because hard disks and SSDs can fail or malfunction, the data also needs to be written in a manner that allows it to be restored and used again. The most common method to protect data from corruption or loss is the use of some type of parity based scheme at the disk level, like RAID in legacy filebased systems, or erasure coding (EC) in objectbased storage systems. These methods allow the system to reconstruct data from a failed device. RAID Reaches its Limit For many years, RAID has been the method commonly used to protect data at the disk level in legacy NAS systems, with RAID 5 or 6, being the most common methods used. In a RAID system, data blocks are striped across the drives in the array and a parity checksum of all the block data is computed and written to one or two drives depending on RAID configuration. In the event of a drive failure, the system can rebuild the data from the missing drive on a replacement drive. Unfortunately, as the disk to be rebuilt gets larger in capacity, it takes longer and longer to rebuild the missing drive. With new drives having a capacity 6 to 10 TB, rebuild times can take 24 to 36 hours per TB. In a multiterabyte system, it could take days to rebuild the failed drive. During this time, data is at risk. Should another drive fail during the rebuild, the data on the failed drive is lost. Additionally, the array performance is significantly degraded during the rebuild process. Clearly, RAID has become problematic as a data protection method against hardware failure. Erasure Coding as an Alternative Object storage can handle storing almost unlimited quantities of data efficiently, by using a parity based protection method called EC to protect data at the object level. In EC, data is broken into fragments, which are then expanded and encoded with redundant data pieces. These are then written across a set of different locations or storage media. The advantages of EC are that it is more resilient than RAID 6, and only the corrupt data needs to be recovered, versus an entire volume, so the chance of overlapping failures is significantly reduced. It also consumes less storage, typically only requiring 2040% more capacity. The downside to EC however, is that it can be more CPU intensive which can result in increased latency.
[ 16 ]
Replication Adds Data Redundancy While erasure coding is an effective protection strategy, it is not necessarily suitable for all types of data. The simplest form of protection that insures data redundancy is replication, which can create and maintain additional copies of the original object locally for fast retrieval in the event the original object is somehow lost. An ideal system will apply replication or EC automatically based on the data sets being protected. The Second Line of Defense A common data protection standard for many organizations is to have at least three copies of the data stored in three different locations. One copy is stored offsite and preferably offline, to insure that at least one copy of the data is secure from potential hacking, corruption or tampering. In the past this was accomplished with a strong backup server running enterprise class backup software and writing the data to high performance disk based storage devices and/or large tape libraries. But today’s massive quantities of data make this legacy backup method impractical. First, it would take too long for legacy backup products to “walk” a massive file system with millions to billions of files and directories in order to identify data that needs to be backed up and then actually back up all that data. With the organization needing to access all its data at anytime, the old, traditional “backup windows” of eight to twelve hours or more, are impractical. Second, even enterprise class legacy backup products would “choke” when the file count hit a million or more files. They simply couldn’t handle such large quantities of files. Backup products had to find a different way to handle so many files. But a flexible objectbased SDS (Software Defined Storage) system built using commodity hardware, can provide a cost effective method of storing and protecting massive amounts of data safely across various storage tiers, including cloud storage, while also managing the lifecycle of an organization’s data. Conclusion Properly protecting very high file count systems is a key requirement for all organizations today, especially in light of the everincreasing laws and regulations governing data protection and retention. Legacy NAS and the traditional file system are no longer able to keep pace with such massive quantities of data consisting of millions, or even billions of files. Storing this much data efficiently and reliably requires a new solution. A strong object storage system, with replication and erasure coding, is well suited for the task of storing and protecting such massive quantities of data in an efficient and safe manner.
[ 17 ]
Chapter 8: HA w/o the headaches by Curtis Preston, Senior Analyst Some systems are born with high availability, others have it thrust upon them. This seems to be the case when discussing the High Availability (HA) features of traditional NAS systems vs those of object storage systems. HA refers to the ability of a system to be available for an extended period of time, surviving many of the things that would take lesser systems down. Even the cheapest systems have some type of HA features built into them. They are able to survive the loss of a component or two. For example, if a disk drive, power supply, or controller fails, there are redundancies built in to be able to survive the failure. The true test of an HA’s system mettle, however, is what happens when an entire node or site fails. Will the system continue to serve its purpose and preserve the data? The answer for NAS systems is maybe and, if so, the HA features were thrust upon them. That is, HA is an addon to the original design of a system. NFS and SMB, the protocols designers use to build NAS systems, were both initially designed in 1984. They both think of a NAS server in the same way, it is a computer with a hostname and a single IP address. While we have figured out ways around that, the client still believes it is communicating with a single server. This creates multiple problems, including not being able to scale performance farther than a single node, and not being able to use HA features — without doing some fancy footwork. There are certainly NAS vendors that can scale beyond a single node and there are those that have built HA features into their NAS products as well. It includes multiple nodes that monitor each other through some kind of heartbeat monitor. In an activepassive configuration, the passive node takes over for the active node if it were to fail. In an activeactive configuration, both nodes are sharing a portion of the production load. If one node goes down, the remaining node(s) take(s) over the extra load created by the loss of the one node. But the NAS client has no idea any of this is happening, because it is still talking to the same IP address it was talking to before an issue arose. This is accomplished through some type of mask that hides the true IP address of the actual node delivering the service.
[ 18 ]
This is why some say that NAS systems have HA thrust upon them. It is a bolton feature added decades after the initial design, and is still in many ways a workaround to the fact that NFS and SMB clients think they are talking to a single server. Object storage, on the other hand, is from this century, and has HA features built into it. Customers can specify what level of redundancy their system needs to have, and one part of the system does not have to lie to any other part of the system for things to actually work. An object storage client understands that it is talking to a multinode system and can adjust accordingly if one of the nodes in an object storage system were to become unavailable. And since all data is replicated to multiple locations, any node in any location can satisfy any read request. Conclusion NAS systems play an important role in today’s data centers, but adding HA to the mix requires a lot of additional hardware and software that needs masking from the NAS client. Object storage systems, on the other hand, are built with HA in mind. If HA is the goal, perhaps object storage systems would be a more appropriate tool.
[ 19 ]
Chapter 9: Supporting Next Generation Apps by Curtis Preston, Senior Analyst Today’s apps aren’t your father’s apps. Applications developed today take for granted things that were not even thinkable not that long ago — especially in the storage space. The scale that is needed by modern day applications was never envisioned when traditional shared storage was invented. (NFS and SMB were released in 1984, five years before Tim BernersLee would invent the worldwide web.) It wasn’t that long ago that developers would assume an app would run on a single server and access a single filesystem. Once apps started to run on clusters, most “clusters” were really just activeactive pairs, or even activepassive pairs. Of course, there were a few truly clustered applications that ran on several nodes. However, all of these systems assumed one thing: a filesystem or LUN that could be shared by all nodes, or synchronously replicated storage that mimicked that behavior. Modern day developers assume they can have an infinite number of nodes to run their application. The ubiquity of the public cloud has made this possible; more VMs or containers is only a few API calls away. This is what has allowed companies like Netflix — who runs their entire infrastructure in Amazon EC2 — to scale to the level that they have. The ubiquity of VMs and containers in the cloud is also what has made modern day applications like Hadoop popular. Hadoop is built from the ground up with the understanding that it will run on a cluster of machines, not a single machine. In fact, Hadoop is built to run in the cloud. And yet, the file system built into Hadoop (HDFS) is a nonclustered, nonshareable file system that uses local storage in each node.
[ 20 ]
When Hadoop developers needed to add a “filesystem” that all nodes could access, they chose to use the S3 protocol and not something like NFS or SMB. This is because object storage is built for modern day applications that can run anywhere and read and write from storage that can be anywhere. Where NFS and SMB assumed latencies that were typically only found within a datacenter, object storage protocols don’t assume that at all. In fact, they assume just the opposite. As far as data consistency between multiple locations, the eventual consistency method of object storage distribution works well with readheavy applications like data warehousing. But if eventual consistency is an issue for a given application, developers can easily take that into consideration when writing data. Conclusion Object storage and its associated protocols are a much better match for modern day applications that are written in and for the cloud. The more an application makes use of modern day development and deployment methods, such as the use of public or private cloudbased VMs and containers, the more object storage makes sense for that application.
[ 21 ]
Chapter 10: The Rise of the Machines: The Challenge with High File Count Environments by George Crump, Lead Analyst It is a well known fact that unstructured data is growing. But there is an aspect of its growth that may take unsuspecting IT professionals off guard; the number of individual files storage systems need to store today and the ramifications of a higher file count on the storage infrastructure. Machines – The File Creators The primary reason for the increase in the number of files that a storage system has to store and manage is machines. Machines are the devices and sensors we are integrating into our lives to help us be more productive and healthy. They also allow companies to capture data about their products to help with future product planning. Unlike users, machines work nonstop capturing data. Often each increment of capture results in a new file. Some devices may capture information every second of every day, 365 days per year. While the actual file that a device creates may be significantly smaller than the files that users create, the sheer number of these files often consumes far more capacity than the user data does. The Ingestion Problem Many organizations implementing machines are now asking their storage infrastructures to store millions if not billions of files. These files are sent to the storage system nonstop and although the individual files may be small, the constant ingestion can place a lot of stress on the storage system. Also, different types of devices may need to transmit data to a different type of target. For example, some devices may look for an NFS data store, others a Windows SMB data store and still others may transmit via a RESTful API.
[ 22 ]
The storage system that is the target for these high file count situations needs to be able to handle the ingestion of all this data and it needs to present multiple target types. While NAS systems typically support SMB/CIFS and NFS they are less likely to support object storage. Some object storage systems, however, can support NFS, SMB, Amazon S3 and native object stores. This combined with their scale out nature allows them to receive inputs from thousands of devices at the same time. The Scale Problem As the number of files increases the data that tracks where these files are on disk, the metadata increases with it. A traditional NAS system, because of its more complex hierarchal structure of folder and subfolder, will reach metadata limits long before an object storage system will. This is why most environments with a NAS investment will not allow their NAS systems to exceed more that 40 to 50 percent of capacity. These percentages will be even lower for systems that are storing files from sensors or devices. Object storage systems, thanks to how they streamline the handling of metadata, can run at much higher percentages of capacity. Reducing both the number of systems or nodes required while increasing the capacity efficiency of the system. The NAS Surprise Many data centers don’t see file count as a problem, probably because they do not have sensors to track various components or products. But most organizations will eventually implement these devices, and of course many already have. Initially a traditional NAS may be able to handle the inbound data from these sensors but over time these systems will hit a performance wall caused primarily by file count. The problem is that when that wall is hit it will be difficult and more costly to migrate the data on the NAS to an object storage system. Data centers should consider object storage upfront and avoid the costly migration in the future.
[ 23 ]
Chapter 11: Scaling, There’s More To it Than Just Adding Nodes by George Crump, Lead Analyst Driven by either the demand for more capacity, more performance or both, every storage system at some point has to scale. Broadly there are two types of scaling available: scaleup or scaleout. Scaleup systems scale by adding more capabilities to the initial system. When you reach the limits of that system then you need to purchase a new system and migrate the old data. Scaleout systems expand by adding additional nodes to the original purchase. Each node has additional capacity and delivers greater aggregate performance, no data migration or the need for an additional point of management. For these reasons scaleout storage tends to be the design of choice for data centers with rapidly growing unstructured data to store. The Scaleout Storage Challenges While scaleout storage succinctly addresses the ever growing capacity demands of data centers, it still has challenges. First there is the physical process of just adding a node. There is a physical appliance that needs to be racked and integrated into the existing cluster. The good news is most scaleout NAS systems are fairly adept at finding new physical nodes. This new physical node may be part of a closed system, where you, the customer, must buy hardware from the vendor that supplied them the software. While acceptable for initial setup, over time the lack of flexibility may cause a problem. The organization may be able to get a better price from another vendor or simply may prefer another vendor’s solution. The second challenge is rebalancing data to this new node. When adding a new node to the cluster the data protection feature of the scaleout system will want to leverage its capacity to improve the protection. Doing so requires a lot of data copying to occur, so much so that it may impact performance. It is important that the scaleout storage software manages how quickly the infrastructure absorbs the new nodes without impacting performance.
[ 24 ]
A third concern is how effectively the storage software manages the cluster itself. Scaleout storage systems may scale to 1,000s of nodes. The software needs to effectively manage the internode communication and the management of metadata to avoid performance bottlenecks. Finally, there is, or a at least should be, a concern over power. Many of these systems will store their data for years, if not decades. The problem with the traditional scaleout storage system is that physical node has to have power on 100 percent of the time. For decades. With hard disk drive prices reaching near parity with tape (or at least it is close) enough, data centers will select a disk based system over a tape based one. But tape’s key advantage is power consumption, or lack thereof. Few scaleout storage systems do anything to address that. While a few scaleout storage systems support power managed drives, they still have to power the nodes. IT professionals should look for scaleout storage systems that can power down both drive AND nodes. Conclusion As you can see, there is more to scaleout storage than just adding a node. The storage software, be it object storage or NAS storage, needs to effectively manage the cluster, provide hardware flexibility and provide some mechanism to manage power.
[ 25 ]
Chapter 12: Making the Migration by Curtis Preston, Senior Analyst Using new technology can be hard. Getting to the new technology is often the hardest part, and there are a few keys to making that migration as painless as possible. Painful migrations can create the worst of all situations – a grassroots campaign to roll the project back and revert to the previous system. Rolledback projects are doubly cursed: they have a reputation that they spent a lot of money and accomplished nothing, and trying the same project again will be even harder due to that reputation. The two keys to a successful migration are minimizing how different the new system is and minimizing disruption during the actual transition. The first challenge is minimizing how different the new world will be from the old world. To understand the importance of this, consider the difference between Windows 7 and 8 vs the difference between Windows 7 and 10. Customers installing Windows 8 found themselves in a completely foreign land with the tiled “Metro” interface and no Windows button. The more familiar you were with previous versions of Windows, the harder it was to get used to Windows 8. While some companies did adopt Windows 8, those that did required a significant amount of training. Many cancelled their Windows 8 rollouts altogether. Windows 10, on the other hand, was closer to Windows 7 than Windows 8 from a user experience level. They brought back the Windows button, and the Metro interface no longer took over the entire desktop. This made the transition for users a lot easier. The same needs to be true for users moving from traditional NAS storage to a more objectbased approach. This is relatively easy because many objectbased storage products offer a NAS frontend to their products allowing them to act – from a user perspective – exactly like traditional storage products. Users will never know or care that their files are really stored as objects. In fact, if the object storage system offers federated search, they may actually get more benefit out of the new system than they did from the old – making the one big difference something they can ignore or get tremendous benefit from.
[ 26 ]
The second challenge to work through is easing hiccups during the migration itself. Since it is inevitable that there will be a hiccup or two during the process, one key to managing this is to migrate a little at a time so that any issues only affect a small number of people. Another key is to migrate small groups of users who are friendly to IT and don’t mind giving constructive criticism and not speaking ill of the system to those outside the initial rollout. Using these “power users” as a way to work out the kinks will help reduce the number of hiccups you will have when rolling out to more challenging users who require a little more handholding. Conclusion First do no harm. Make sure that any advancements to your storage systems do not negatively impact those that would use them – their experience should be the same as before the migration. Of course it’s alright to add functionality, like federated search, but minimize the degree of change whenever possible. Also try to mitigate hiccups along the way by migrating small groups of users at a time, allowing you to deal with any technical hiccups or training requirements that do come up.
[ 27 ]
The Verdict: Legacy NAS Falls Short Unstructured data puts stress on a NAS system in several ways: ● First, while many NAS systems can scale large, the cost to achieve that scale is very expensive. ● Second, while they can scale, traditional NAS systems often become complex as they scale. ● Third, they generally use RAID5/6 for data protection. Because of the size of the data set, IT planners want to use larger hard disks like 610TBs, which require longer RAID rebuilds. ● Finally, users don’t sit in one facility any more, data needs to be dispersed across an organization’s locations and into the cloud. As we explained throughout this series object storage responds well to each of these stress points.
[ 28 ]
About Storage Switzerland Storage Switzerland is an analyst firm focused on the storage, virtualization and cloud marketplaces. Our goal is to educate IT Professionals on the various technologies and techniques available to help their applications scale further, perform better and be better protected. The results of this research can be found in the articles, videos, webinars, product analysis and case studies on our website storageswiss.com George Crump, Chief Steward George Crump is President and Founder of Storage Switzerland. With 25 years of experience designing storage solutions for data centers across the US, he has seen the birth of such technologies as RAID, NAS and SAN. Prior to founding Storage Switzerland he was CTO at one the nation’s largest storage integrators where he was in charge of technology testing, integration and product selection. Curtis Preston, Lead Analyst W. Curtis Preston (aka Mr. Backup) is an expert in backup & recovery systems; a space he has been working in since 1993. He has written three books on the subject, Backup & Recovery, Using SANs and NAS, and Unix Backup & Recovery. Mr. Preston is a writer and has spoken at hundreds of seminars and conferences around the world. Preston’s mission is to arm today’s IT managers with truly unbiased information about today’s storage industry and its products. Joseph Ortiz, Lead Analyst Joseph is an Analyst with Storage Switzerland and an IT veteran with over 35 years of experience in the high tech industries. He has held senior technical positions with several OEMs and VARs; providing technical pre and post sales support as well as designing, implementing and supporting backup, recovery and data protection / encryption solutions along with providing Disaster Recovery planning and testing and data loss risk assessment in distributed computing environments on Unix and Windows platforms. Copyright © 2016 Storage Switzerland, inc.—All rights reserved
[ 29 ]
Sponsored by Caringo About Caringo Caringo was founded in 2005 to change the economics of storage by designing software from the ground up to solve the issues associated with data protection, management, organization and search at massive scale. Caringo’s flagship product, Swarm, eliminates the need to migrate data into disparate solutions for longterm preservation, delivery and analysis—radically reducing total cost of ownership. Today, Caringo software is the foundation for simple, bulletproof, limitless storage solutions for the Department of Defense, the Brazilian Federal Court System, City of Austin, Telefónica, British Telecom, Ask.com, Johns Hopkins University and hundreds more worldwide. Visit www.caringo.com to learn more.
[ 30 ]
