web viewvendors such as lenovo, cisco, hp, huawei, and fujitsu have been rather promiscuous in...

TOWARD A SIMPLIFIED TWO-TIER ARCHITECTURE FOR DATA STORAGE (ESPECIALLY FILES AND OBJECTS)

BY

JON TOIGO

SUMMARY

It is a given that data storage capacity demand is accelerating – by a lot. The numbers coming out of the analyst houses are mind-bending, in the Zettabyte range, especially in large data centers and industrial cloud operations. But even in small-to-medium-sized companies, capacity demand growth rates are accelerating. Industry analysts peg rates between 40% per year to as high as 300 to 650% per year in heavily virtualized server environments.

It is also a given that the preponderance of the data being stored by organizations today takes the form of files and objects, rather than block output from workloads such as databases. One leading analyst says that the trend line for file/object crossed the trend line for block in 2005 and has kept its high-and-to-the-right trajectory ever since.

Since it is usually up to the end user to name and manage his or her files and objects, we see a lot of inefficiency in file/object storage today. Files and objects are placed on infrastructure in a wasteful manner. According to the Data Management Institute, up to 70% of the capacity of every SSD/HDD deployed today in user computing devices, servers and storage arrays is wasted by storing

Data that must be retained but that is never re-referenced, Orphan data whose owner or server no longer exist at the firm, Contraband data that shouldn’t be retained at all, and Copies of data created either as versions or as disaster backups.

TWO-TIER ARCHITECTURE DRAFT 10/2/2016 1COPYRIGHT © 2016 BY THE DATA MANAGEMENT INSTITUTE LLC. ALL RIGHTS RESERVED.

DMI says that, with a modicum of data management in the form of data hygiene and archive, companies could reclaim over half of the capacity they already own for productive use. Given that storage has a tangible cost – between 33 and 70 cents of every dollar spent annually on IT hardware, depending on the analyst you consult – it might be a good time to rethink how we are hosting and managing data for optimized reference and retention at the lowest possible cost.

This paper seeks to begin such a dialog.

THE SHAPE OF THE STORAGE INFRASTRUCTURE TO COME: “FLAT” VS “TIERED”

Today, there is considerable debate in the industry between advocates of “flat storage infrastructure” and “tiered storage infrastructure.” Since the former is usually defined within the context of the latter, it is useful to begin with a quick description of tiered storage.

Tiering, as the metaphorical name suggests, means having multiple locations or tiers of storage where data can be placed. A traditional tiered storage environment, per Horison Information Strategies, significantly reduces overall storage expense by positioning data on different types of storage based on factors such as

data access frequency, rate of data re-reference, data modification frequency and business context.

Business context refers to rules related to the retention and preservation of certain types of files or objects usually to comply with legal or regulatory retention requirements.

Horison sets forth a nominal schedule for storage tiering. In a given computing infrastructure, per the illustration below, data will be dispersed across four tiers of storage corresponding to

high performance, high cost, memory-based silicon storage (DRAM and Flash Memory), called Tier 0;

high performance, high cost, low capacity hard disk, or Tier 1; lower performance, higher capacity and lower cost hard disk, or Tier 2; and, extremely low cost, extremely high capacity and slower performing mass storage

mediums such as optical disc or tape – Tier 3.

Based on the access frequency and re-reference rate, data is migrated between these tiers of storage thereby achieving the best cost per gigabyte dynamics.


Source: Horison Information Strategies, www.horison.com.

Using the cost ranges provided by Horison and the percentages of data in each tier as a guide, one can see the benefits of storage tiering. Using only disk (tier 1 and 2) to store all data results in an infrastructure cost for a 100 TB repository of approximately $765,000 based on media cost alone. Using all four tiers and judiciously migrating files from the more expensive to the less expensive tiers of infrastructure results in an infrastructure cost of approximately $482,250 for the same capacity.

Tiering has long been the lynchpin of strategies for storage cost-containment, a narrative that has helped to keep interest in tiered storage architecture front of mind for IT planners since the earliest days of mainframe computing. However, it has recently come under fire in some firms because of it is thought to fit less well with workloads from server virtualization and big data analytics hosting.

In a virtual server world, the industry mantra is to promote the “rip and replacement” of legacy storage infrastructure. Instead of “networked” or “shared” storage tiers, hypervisor vendors are recommending a return to locally-attached or internally-mounted storage, storage topologies that are easier for a virtual server administrator to see and manage using hypervisor administration and orchestration tools.

The argument is made that reduced storage administration costs accrue to server virtualization and a return to direct-attached storage. One analyst claims that the cost of 1 RAW TB of storage, excluding facility expense, has fallen by more than 50% to $2009 in 2015, courtesy of the (hyper-) convergence of storage and servers under a server virtualization hypervisor. The same analyst notes that hypervisor-centric storage has improved capacity management per


http://www.horison.com/

administrator. An individual server admin can now manage 344 TB of capacity, up from 132 TB) with hypervisor-controlled storage.

One problem with this back-to-direct-attached-storage strategy is that it creates “silos of storage.” Capacity behind different servers with different hypervisors cannot be shared between those hypervisors and their workloads. With the diversification of hypervisors that is occurring in most data centers today, the proliferation of silos has led to a reduction in overall or infrastructure-wide capacity utilization efficiency of 10% over the past five years, according to the analyst. This should be a concern to cost- and space-savvy planners in the near future -- if it isn’t already.

In addition to reducing overall capacity utilization efficiency, silo-ing also erects practical barriers to the tiering of storage in a distributed virtual server setting. Rather than sharing an infrastructure comprising pools of storage devices organized into tiers, most virtual server environments are moving toward isolated islands of data that lack infrastructure wide resource or data management.

Nowhere is this architectural model taken to the extremes found in big data analytics “farms.” In a big data environment, many servers – each with its own locally-attached storage – are clustered to provide massive scalability. Each server/storage node participates in a broader clustered entity, a “farm,” that can be expanded by adding more server/storage nodes.

Big data advocates prefer, generally, not to move data around the infrastructure if this can be avoided. Moving data is thought to create “friction” – that is, additional work for computing components and I/O latencies that are to be avoided at all possible costs.

These architects argue for a frictionless and “flat” storage environment. They disparage tiering as a source of undesired data movement (between tiers) and they denigrate most forms of data protection based on data copy. Rather than mirroring or replicating data in order to protect it


from loss or damage, flat storage advocates prefer a “shelter in place” approach, usually involving technologies such as erasure coding.

There is no concept of archiving in a flat infrastructure vision. When a storage device becomes filled with data that is not being re-referenced, the recommended best practice is to power the drive down and leave it in a powered-down state until there is another access to the data. This is a questionable strategy, as the failure rates of both Flash and hard disk drives when they are powered down then restarted do not inspire confidence that access to data will be reliably restored. However, the attitude of most flat infrastructure advocates is a general disdain for data copy, especially if the data is thought to lose its immediate value within a few minutes of creation.

So, is storage tiering dead? Is flat storage the future? The answer is, it depends.

LOOK TO THE DATA TO DEFINE INFRASTRUCTURE REQUIREMENTS

The truth is that database and file/object data generally have different storage – and therefore different tiering – requirements. A big data analytics environment may have enormous quantities of new data to store, but re-reference to this data after the initial analysis process is complete (e.g., minutes after data is created and aggregated) may be nil. One big data analytics user recently exclaimed that the useful life of data in his environment was about four minutes. After that brief period of time, the chances that data might be accessed again fell to zero. Still, the user did not want to delete any data, since it might be required for historical analysis at some future date, or to review when troubleshooting an unexpected outcome. Thus, “shelter in place” and drive power down were his preferred methods for data protection and preservation.

In a file/object world, the re-reference rate depends on the workflow and application. While some objects may enjoy protracted and consistent rates of re-reference over a period of time, everyone has seen a presentation by a vendor showing the s-curve of steadily declining file or object access.

As a rule of thumb, most user produced files are not revisited again after 30 days. However, there are often compelling legal and regulatory reasons to retain file or object data for a protracted timeframe. Whether the data is part of the disclosure required by publicly traded firms to the SEC, or clinical test trial data that needs to be maintained for possible review by the FDA, or private patient healthcare data that must be stored in conformance with HIPAA or other regulations, it must be retained…ideally, in a manner that does not accrue significant expense.

The above suggests that, at a minimum, contemporary computing requires at least two “tiers” of storage: one optimized for data capture, the other for data retention.


The capture tier likely consists of the fastest write-optimized storage available. DRAM has data transfer rates of between 2 and 20GB/s, while Flash SSDs are a couple of orders of magnitude slower: transferring data at a rate of between 50 and 200 MB/s.

Interestingly, tape (often and incorrectly viewed as a performance laggard) has a sustained transfer rate of roughly 300 MB/s for LTO 7 or 351 MB/s for enterprise tape technologies such as IBM’s TS1150. Burst transfer rates are even faster. Plus, tape is much less expensive as a storage technology than are either silicon or hard disk storage.

Still, with the potential exception of certain scientific applications, DRAM or Flash memory, rather than tape, tends to be drafted into service in a “capture storage” pool – mainly for convenience, certainly not for cost.

The second – or retention – tier of a simplified two-tier approach to file/object data hosting consists of a high capacity (rather than high performance) storage infrastructure. Such an infrastructure would need to be designed to meet expectations for data re-reference rates and access speeds, which can vary widely but are usually well below the requirements for capture infrastructure.

For example, if a pharmaceutical house is required to store clinical test trial data for as long as its drug is offered in the market – in case the Food and Drug Administration needs to review the data in response to a product complaint or unexpected outcome with a statistically important frequency of occurrence – the platform best suited to the access characteristics (very infrequent access without extremely fast response to requests) might well be a tape repository. Tape is capacious and has the lowest cost of ownership, partly by virtue of being an offline medium and therefore having a very low energy cost profile.

In a different case, such as the archival storage of creative content for a motion picture studio, a tape-based repository with a cache of faster access capacity disk might be the right mix of technology for the retention tier. That way, a requested video file can be streamed from a partial file recorded to disk until the whole file is located, mounted and accessed from the tape system (a process that might take up to two minutes in a very large tape library).

The central point is that a two-tier storage infrastructure – with one tier optimized for real time capture and short term retention, and a second tier optimized for long term retention at the lowest possible cost per GB – might be just the thing for contemporary data storage. The only problem is how best to move data between tiers with minimal hassle for operators and minimal friction for latency sensitive applications and workload.


THREE POTENTIAL METHODS FOR PLACING DATA ON CAPTURE AND/OR RETENTION STORAGE

Implementing a two tier storage strategy should be effortless from the standpoint of application workload. The capture tier, after all, is designed for real time data capture, and all physical movement of data between tier one and tier two (the retention tier) should occur “behind the scenes” – that is, transparently to applications and production servers. There are actually three approaches that might enable smooth and efficient data movement.

CONTEMPORANEOUS WRITE TARGETING (COPY DURING WRITE)

One potential approach to reducing the friction of data movement that makes tiering suspect to “flat infrastructure” advocates is to write initial data to both the capture and the retention storage targets concurrently. Using any of a dozen techniques to perform simultaneous writes to different targets, data is written to both capture and retention storage tiers.

Remediation and recovery of capacity on expensive capture storage could be automated simply using metadata-driven policy. Consulting file or object metadata, once the file or object has reached a threshold re-reference frequency (for example, when 30 days have elapsed without further re-references of the file or object), simply delete the instance of the file or object on the capture storage, freeing up that physical capacity. The file already exists in the retention infrastructure, so there is no need for the friction of copy operations.

ASYNCHRONOUS WRITE TARGETING (COPY AFTER WRITE)

An alternative is to write the data from the capture storage to the retention storage tier in batches, whether per a pre-defined schedule or when triggered by a lifecycle management event. The actual write operation should be handled by a process working outside of the workload of capture storage and it should be cognitive or self-optimizing to avoid throttling capture data operations while migrating capture data to retention.

Today, there are many examples of this technique in the archive space, including the StrongBox appliance. In fact, placing gateway machines, whether physical or virtual, into the production/capture storage environment to buffer capture data prior to writing to the retention tier may provide a means to trickle older capture data into the retention tier whether that tier is established on premise using local disk or tape assets, or in a cloud using the same assets operated by a service provider.

CHANGE BLOCK SNAPSHOTS


Block snapshot technology, replicating change data blocks to a remote target, then reassembling or applying the snapshot data to file or object forms already on the retention storage tier may also have a potential value – especially to capture unanticipated changes to files and objects that have already been designated for replication to retention storage and deletion from capture storage.

Write block interception is widely used for continuous data protection and backup and many technologies exist for applying this methodology to low friction data replication.

Storage systems could be (and have been) designed to deliver multiple tiers of storage that could support such a data tiering strategy but, if current sales data of storage vendors are any indication, the idea of a monolithic storage array hardware platform with expensive value-add tiering/data management software appears to have fallen out of favor. Such “legacy” platforms have fallen into disrepute because of array vendor pricing models and lock-in strategies. They have also been blamed, mostly without merit, for slow virtual machine performance in virtual server environments.

A virtualized pool of storage from which logical tiers could be defined to provide shared capture and retention storage targets is another strategy. IBM’s SAN Volume Controller and DataCore Software’s SANsymphony platform are two examples of technologies that could be used to build an optimized shared infrastructure such as the capture/retention infrastructure described above. However, again, sales data suggests that storage area networks (SANs) have also fallen out of consumer favor – again driven by negative perceptions of vendor SAN products (lock-ins, interoperability problems, etc.) and prevarication by hypervisor vendors in blaming SANs for slow VMs.

What we appear to be seeing currently is an effort to return to internal and direct-attached storage topologies that predated shared and networked storage systems. The narrative around these “converged” and “hyper-converged” infrastructure models is usually somewhat confusing and quite tortured.

Advocates refer to converged and hyper-converged “a return to direct-attached,” as opposed to “network attached,” storage infrastructure. In fact, all storage is direct-attached.

What we have called storage area networks for the past two decades were in fact direct-attached storage topologies with connections between server and storage simply made and broken at high speed by a physical layer switch. Network-attached storage consisted of a thin file server joined to a direct-attached storage array. Bottom line: there never was a network-attached storage model.

Similarly, advocates describe the “new” converged/hyper-converged storage paradigm as “software-defined storage.” While this description may faithfully represent a typical design in


which software functionality that once resided on a storage array controller (usually, a server motherboard) has been moved into a software stack operated in conjunction with or under the aegis of a server hypervisor, it does not establish a meaningful distinction: all storage is “software-defined.”

What converged (and hyper-converged) storage is is a “de-evolution” of storage infrastructure, a return to a prior topology that dates back at least to 1993 and IBM System Managed Storage (SMS) on the mainframe. Building storage in the server chassis or connecting to it to the server using an adjacent tray in a rack and a direct bus extension cable, then operating the storage and applying value add services via a server-side functionality stack, simplifies the management of storage by a server administrator but impairs, in most cases, the sharing of storage capacity across multiple workloads for maximum utilization efficiency.

“Hyper-converged infrastructure appliances” are a case in point. Server vendors are currently working with hypervisor vendors and/or independent software vendors of software-defined storage stacks to create HCI appliances for sale in the market. Vendors such as Lenovo, Cisco, HP, Huawei, and Fujitsu have been rather promiscuous in relationships, partnering with many SDS vendors to deliver many different flavors of HCI at different price points. For the most part, however, almost all HCI appliances are the same.


Primordial HCI appliances are simple pre-configured cobbles of a multicore processor-based server, DRAM, SSD and/or HDD storage, a hypervisor for server virtualization, and an SDS software stack.

Most offer the same general set of value-add services: mostly focused on data protection but with some capacity optimization functionality such as de-duplication, compression, thin provisioning, etc. This definition of the SDS stack functionality follows a model first articulated by VMware, mainly to serve the company’s (and its main shareholder, EMC’s) proprietary interests. Missing from the functionality of virtually all HCI appliances is any provision for automated storage resource management (management of the physical kit) or for policy-driven data management including file/object system support, global namespace management, etc.

SDS, and later HCI, have been sold to consumers using two fundamental pitch points. For one, these “new” storage configurations were supposed to address “storage I/O log jams and latencies” that are blamed by the hypervisor vendor for slow virtual machine performance. In truth, very few instances of slow VM performance can be laid at the feet of storage I/O. Simple tests with any I/O meters show that there are no significant storage queues that would indicate chokepoints or other log jams in the path for processing storage I/O in most virtual machine host systems. What is commonly found is significant processor cycling that suggests I/O problems at the RAW I/O part of the I/O pathway – at the CPU.

This makes sense. Today’s multicore processors are an aggregation of multiple single core (or unicore) processors that have been introduced in a regular tick-tock of development and distribution by Intel for the past 30 years. Unicore chips have a sequential I/O processing function: I/O from application instructions is processed one at a time. In a multicore environment, each logical chip core waits its turn for its I/O to be processed sequentially. The more cores in the chip, the longer the processing of all I/O requires.

DataCore Software recently demonstrated a “workaround” for sequential I/O processing (Adaptive Parallel I/O) that leverages “idle” logical cores in a multicore chip to create a parallel TWO-TIER ARCHITECTURE DRAFT 10/2/2016 10

COPYRIGHT © 2016 BY THE DATA MANAGEMENT INSTITUTE LLC. ALL RIGHTS RESERVED.

I/O processing engine. Benchmark testing by Storage Performance Council recently confirmed the technology’s ability to deliver in excess of 5 million SPC-1 IOPS from a “commodity” (Lenovo) server communicating with commodity storage across a Fibre Channel link. For whatever else the demonstration proved, it confirmed that storage I/O is not and probably never has been a source of latency and log jams in virtual server environments. The problem was always rooted in sequential I/O processing at the CPU.

So, the first argument for abandoning “legacy storage” – including NAS and SAN – for software-defined storage was mostly bogus: doing so would not appreciably improve the performance of virtual machines in most cases. The second reason for moving to converged/hyper-converged was to “break the lock-ins and the complexity of legacy storage.” Hypervisor vendors basically argued that reducing storage to its commodity components and operating those components from the hypervisor was less expensive than buying storage gear with embedded value-add software on each array controller. Moreover, directly attaching storage to the virtual machine host would enable the server admin to manage storage assets without requiring a storage administrator. CAPEX and OPEX nirvana would be realized.

Basically, this second narrative proved to be the more compelling. Consumers felt that they were being overcharged for value-add software on arrays. Data Domain’s original de-duplicating virtual tape library, for example, carried a list price of $410K for a box of Seagate hard drives in a commodity chassis with an aggregated hardware cost of less than $3K. The “value add” according to the vendor was the de-duplication software embedded on the array controller that would deliver a 70-to-1 data reduction ratio, enabling each $100 disk drive to behave like 70 disk drives. (Problem was, nobody ever came near to realizing such a reduction ratio.)

In addition to paying obscene costs for value add functionality, consumers were put off by the complexity of many storage platforms and storage networking switches. IT staffs needed to include high cost storage administrators or firms needed to purchase very expensive vendor-supplied support services. The need for support became more acute when hypervisors were used to consolidate applications and their I/O requirements onto fewer servers, dramatically altering traffic patterns on storage fabrics.

Plus, a lot of the value-add functionality implemented on storage arrays obfuscated the capability to manage storage as a holistic and coherent infrastructure. Lack of infrastructure management also drove perceived complexity, cost, and in some cases downtime.

So, converged/hyper-converged storage, whether justified by its original adoption case or not, has become a fixture of the current IT landscape. In the best case scenario, it will evolve in ways that will deliver greater utility and manageability to IT operators and planners at a lower cost. But that will not happen until we re-envision what software-defined storage is, and wrest control of silo’ed storage from proprietary hypervisor vendors and appliance builders.


RE-ENVISIONING STORAGE INFRASTRUCTURE FOR THE COMING DECADE

For now, the storage infrastructure in most organizations is a mixture of legacy and software-defined storage. Much of the legacy storage is used to support data coming from the complement of high performance workloads (transactional databases) that companies have been reluctant to virtualize for fear of reducing their performance. Other legacy storage is used to store file system data and archival data.

SDS has enjoyed adoption by about 25% of companies responding to market surveys in its first iteration; usually in conjunction with hypervisor-virtualized workloads. Truth be told, for all of the discussion of the presumed high performance benefits of SDS, most HCI appliances are deployed to support data and workloads with fairly low performance requirements. They are often deployed in small office and remote office settings where there is minimal IT support skill because of their pre-integrated, plug-and-play characteristics.

Much more could be done with SDS and hyper-convergence. There is, for example, a case to be made for “personalizing” HCI appliances. One of the first instances of this is StrongBox Data Solutions Virtual StrongBox Appliance. This product is a virtualized version of a hardware appliance intended to serve as an active archiving gateway to disk and tape. It is a good example of a storage kit that is now implemented as software to provide personalization of any HCI appliance as an archival gateway to tape or cloud storage.

StarWind Software has also introduced a personalized appliance: the StarWind Virtual Tape Library. A VTL emulates a tape library using disk drives either to optimize tape writes or to share tape resources more efficiently. Among the first VTLs was a software-based VTL in the mainframe space that could be used to designate any set of storage as a virtual tape library. StarWind Software, in an effort to further differentiate their product from many SDS competitors, created a personality for a VTL that can be dropped into place in an on premise or cloud-based infrastructure in a very agile way, simply by deploying a virtual machine and designating what storage to use.

This kind of basic SDS personalization gets closer to the pure vision of software-defined advocates, but only if the vendors are hypervisor and hardware brand agnostic. It also portends to open a new discussion around SDS/HCI that we could call “atomic units of compute.”

ATOMIC UNITS OF COMPUTE

Imagine that storage could be rolled out incrementally – Lego™ style – to meet the needs of specific workload. One can easily envision a DRAM/Flash-based hyper-converged appliance optimized for in-memory databases or big data analytics workloads, or a highly scalable Flash/disk based appliance to store files or objects from systems of interaction. With the


proper engineering, this kind of infrastructure could radically simplify the provisioning of storage in response to fast changing business needs. In a word, such a building block infrastructure would be agile.

Applying the same concept to a two-tiered storage infrastructure model discussed in this paper, appliances could be configured and optimized for data capture and for data retention. Capture storage appliances could be filled with DRAM and Flash memory to capture data at rated speeds, while retention storage appliances could be filled with Flash, high/low performance hard disks and perhaps provide back-end links to tape technology or cloud services access. Again, agility would be the by-product, but only if silo-ing could be replaced by an effective mechanism for resource sharing.

DataCore Software enables the sharing of legacy, converged and hyper-converged infrastructure by virtualizing all of the mount points of all storage in the infrastructure, pooling the resources, and sharing them as a set of logical volumes. IBM SVC can also pool and share resources, but uses direct connections to APIs on each storage controller to aggregate capacity. Unfortunately, neither solution provides comprehensive hardware resource monitoring or management functionality or any global namespace functionality or other data management-enabling capabilities as part of the basic kit.

Some object storage vendors have sought to implement data management capabilities via a software layer across select storage infrastructure. Caringo Swarm, for example, provides an object storage environment using commodity server and storage clustered for scalability and fault tolerance.

Perhaps one of the most innovative efforts to unite these different approaches is StrongLink from StrongBox Data Solutions. StrongLink positions itself as middleware – software deployed on its own high availability cluster – that sits above the server/storage infrastructure and manages connections between application data (files and objects) and storage infrastructure, whether on premise or in clouds. StrongLink…

inventories all virtual and physical pathways between application server hosts and storage resources,

creates a scalable global namespace for all files, supports all network file systems and network object access standards (de facto and de

jure), and delivers a policy engine and data mover to support the placement of any data from any

application on the best fit storage platform per policy throughout the useful life of data.

Developers are keen to add out-of-the-box policy profiles that support the specialized metadata of different industry verticals as well as connectors for common workflows (video editing, for example). Plus, the entire technology is hardware and protocol agnostic, enabling any vendor’s


gear and file/object access protocols ranging from Amazon S3 to NFS to be included in its infrastructure and data management solution.

A workable StrongLink technology may be what is really needed to unify storage infrastructure, maintain simplified tiering, and ensure that both data and infrastructure are well managed into the future.

HASTY CONCLUSION

By itself, software-defined storage (and converged/hyper-converged infrastructure appliances that are based on SDS) is no panacea for everything that ails storage. Improvements need to be made in the SDS stack to support greater workload and hardware agnosticism so that storage infrastructure can be shared more efficiently.

Moreover, the by now “traditional” or first-generation stack of SDS functionality is already showing its limitations. Going forward, the industry needs to follow the example of DataCore Software, StarWind Software, Caringo, Pivot3, and many others to add value to the SDS stack, to personalize appliances, to enable data tiering in a shared infrastructure model optimized for data management over time.

StrongLink has provided an outline for what is possible. It will be interesting to monitor how the industry and the community of consumers responds.


web viewvendors such as lenovo, cisco, hp, huawei, and fujitsu have been rather promiscuous in...

Documents