Scale-Out Storage Use Cases

656 views

Published on

The Scale-Out Storage Master Usage Model extends the “ODCA Compute Infrastructure as a Service (CIaaS) Master Usage Model” and specifies the common usage patterns and requirements for CIaaS storage, which have typically used a scale-out approach.

Essentially, a scale-out storage system is designed so that adding more capacity or increasing performance is relatively easy, efficient, and non-disruptive. Enterprises that contend with steadily increasing data demands can adopt a “just-in-time” supply-chain approach—useful in scenarios where it is difficult to predict upcoming storage needs. In addition, scale-out architecture helps to prevent scenarios in which large enterprise systems encounter growth barriers that cause expensive re-architecting and/or rebuilding when an existing system is outgrown.

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
656
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
21
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Speak on how to use the usage model document. We might spend 5-10 mins on this slide.
  • The two most common high-level business drivers from the provider perspective for scale-out storage include:• • Scale-Out Network-Attached Storage.4 Network “drives”—dedicated or shared—that can efficiently grow (or shrink) without encounteringarchitecturally disruptive growth barriers. Some common usages for such storage include typical read/write network “shares,” WORM5 archiving/compliance, databases, and backup/data recovery.• • Scale-Out Direct-Attached Storage.6 Like network-attached storage, the requirement is to be able to efficiently grow (or shrink) withoutencountering architecturally disruptive growth barriers. Some common usages for such storage include in-memory databases, single orclustered file systems, and caches.
  • The following scale-out architectures and patterns are commonly found, and scale-out designs should consider and support each:• • SAN array fronting multiple network-attached storage heads• • Shared-disk clustered file system• • Shared-nothing cluster• • Cross-node RAID• • Erasure coding• • Mirroring• • Low-latency, high-IOPS• • Hybrid; that is, any combination of one or more of the above© 2013 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED. 7Open Data Center Alliance: Scale-Out Storage Rev. 1.0Management The following aspects need to be considered when designing scale-out storage systems:• • Absence of fixed or static control nodes• • Software aspects of scale-out• • Hardware aspects of scale-out• • Capacity scale-out• • Performance scale-out• • I/O scale-out• • Rapid, simple, dynamic/automated, and non-disruptive• • Unified namespace and volume• • Abstracted, dynamic virtual storage “pools”• • Control and interconnect plane aspects of scale-out• • Data plane aspects of scale-out• • Integration with CIaaS/virtualization• • Sustaining engineering• • API and programmability• • Synergies with SDN and software-defined storage7
  • Talk about success and failure for each scenario. We can explain the 4 of these verbally.
  • The following scale-out architectures and patterns are commonly found, and scale-out designs should consider and support each:• • SAN array fronting multiple network-attached storage heads• • Shared-disk clustered file system• • Shared-nothing cluster• • Cross-node RAID• • Erasure coding• • Mirroring• • Low-latency, high-IOPS• • Hybrid; that is, any combination of one or more of the above© 2013 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED. 7Open Data Center Alliance: Scale-Out Storage Rev. 1.0Management The following aspects need to be considered when designing scale-out storage systems:• • Absence of fixed or static control nodes• • Software aspects of scale-out• • Hardware aspects of scale-out• • Capacity scale-out• • Performance scale-out• • I/O scale-out• • Rapid, simple, dynamic/automated, and non-disruptive• • Unified namespace and volume• • Abstracted, dynamic virtual storage “pools”• • Control and interconnect plane aspects of scale-out• • Data plane aspects of scale-out• • Integration with CIaaS/virtualization• • Sustaining engineering• • API and programmability• • Synergies with SDN and software-defined storage7
  • Scale-Out Storage Use Cases

    1. 1. SCALE-OUT STORAGE MASTER USAGE MODEL David Casper Jason Davidson CTO North America Moogsoft Director of Technical Alliances EMC
    2. 2. LE G AL D IS CLAIME R © 2014 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED. This “ Open Data Center AllianceSM Master Usage Model: Scale-Out Storage Rev. 1.0” document is proprietary to the Open Data Center Alliance (the “ Alliance”) and/or its successors and assigns. NOTICE TO USERS WHO ARE NOT OPEN DATA CENTER ALLIANCE PARTICIPANTS: Non-Alliance Participants are only granted the right to review, and make reference to or cite this document. Any such references or citations to this document must give the Alliance full attribution and must acknowledge the Alliance’s copyright in this document. The proper copyright notice is as follows: “ © 2013 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED.” Such users are not permitted to revise, alter, modify, make any derivatives of, or otherwise amend this document in any way without the prior express written permission of the Alliance. NOTICE TO USERS WHO ARE OPEN DATA CENTER ALLIANCE PARTICIPANTS: Use of this document by Alliance Participants is subject to the Alliance’s bylaws and its other policies and procedures. NOTICE TO USERS GENERALLY: Users of this document should not reference any initial or recommended methodology, metric, requirements, criteria, or other content that may be contained in this document or in any other document distributed by the Alliance (“ Initial Models”) in any way that implies the user and/or its products or services are in compliance with, or have undergone any testing or certification to demonstrate compliance with, any of these Initial Models. The contents of this document are intended for informational purposes only. Any proposals, recommendations or other content contained in this document, including, without limitation, the scope or content of any methodology, metric, requirements, or other criteria disclosed in this document (collectively, “ Criteria”), does not constitute an endorsement or recommendation by Alliance of such Criteria and does not mean that the Alliance will in the future develop any certification or compliance or testing programs to verify any future implementation or compliance with any of the Criteria. LEGAL DISCLAIMER: THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS PROVIDED ON AN “ AS IS” BASIS. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE ALLIANCE (ALONG WITH THE CONTRIBUTORS TO THIS DOCUMENT) HEREBY DISCLAIM ALL REPRESENTATIONS, WARRANTIES AND/OR COVENANTS, EITHER EXPRESS OR IMPLIED, STATUTORY OR AT COMMON LAW, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, VALIDITY, AND/ OR NONINFRINGEMENT. THE INFORMATION CONTAINED IN THIS DOCUMENT IS FOR INFORMATIONAL PURPOSES ONLY AND THE ALLIANCE MAKES NO REPRESENTATIONS, WARRANTIES AND/OR COVENANTS AS TO THE RESULTS THAT MAY BE OBTAINED FROM THE USE OF, OR RELIANCE ON, ANY INFORMATION SET FORTH IN THIS DOCUMENT, OR AS TO THE ACCURACY OR RELIABILITY OF SUCH INFORMATION. EXCEPT AS OTHERWISE EXPRESSLY SET FORTH HEREIN, NOTHING CONTAINED IN THIS DOCUMENT SHALL BE DEEMED AS GRANTING YOU ANY KIND OF LICENSE IN THE DOCUMENT, OR ANY OF ITS CONTENTS, EITHER EXPRESSLY OR IMPLIEDLY, OR TO ANY INTELLECTUAL PROPERTY OWNED OR CONTROLLED BY THE ALLIANCE, INCLUDING, WITHOUT LIMITATION, ANY TRADEMARKS OF THE ALLIANCE. TRADEMARKS: OPEN CENTER DATA ALLIANCESM, ODCASM, and the OPEN DATA CENTER ALLIANCE logo® are trade names, trademarks, and/or service marks (collectively “ Marks”) owned by Open Data Center Alliance, Inc. and all rights are reserved therein. Unauthorized use is strictly prohibited. This document does not grant any user of this document any rights to use any of the ODCA’s Marks. All other service marks, trademarks and trade names reference herein are those of their respective owners. 2
    3. 3. SCALE-OUT STORAGE MASTER USAGE MODEL V 1.0 Contributors: David Casper, Moogsoft Jason Davidson, EMC Karl Kohlmoos, HDS Freeman Ratnam, Intel IT Jeff Sedayao, Intel IT Aaron Sullivan, Rackspace Terry Yoshii, Intel IT http://www.opendatacenteralliance.org/docs/Scale_Out_Storage_Master_Usage_Model_Rev1.0.pdf
    4. 4. CUS TO MER S F O CUS O N S LAS Scale-Out Storage = Just-In Time Approach  Growth Becoming Less Predictable  Price Appears Linear  Perception of Infinite Resources  Increases of Capacity or Performance  Relatively Easy  Efficient  Non-Disruptive On-demand Capacity at SLA Performance 4 4
    5. 5. SCALE-OUT STORAGE CHARACTERISTICS  Growth Can Be Capacity and/or Performance  Implemented as Object, Block, or File Based  Unified Name Space – Appears As One Repository  Core Values Scale With Solution  Data Retention  Data Protection  Backup  Failover  Elimination of SPoFs Simple, Efficient, & Non-Disruptive 5
    6. 6. S CALE -UP VS S CALE -O UT More Drives & CPUs vs. More Nodes 6
    7. 7. USAGE SCENARIOS ① Request more on-demand cloud storage. ② Increase the capacity of the network-attached storage system for a network “mount-point.” ③ Increase the performance of the direct-attached storage system for an in-memory database. ④ Scale out the storage environment, both performance and capacity, for intensive workloads such as Apache Hadoop. 7
    8. 8. S ER VICE LEVELS 8
    9. 9. CO MMO N PATTER NS Different SLAs for Different Usages 9
    10. 10. QUESTIONS TO ASK WHEN PURCHASING  Is the solution open?   Does it work on multiple virtual and nonvirtual infrastructure platforms?   Is it standards based?  Is the solution able to keep time in sync across nodes while adding, removing, or replacing nodes for scale out/in?  Is the solution able to auto-recover from  adding or removing nodes?  Will the system auto-sense when a node has been added, removed, or replaced and automatically recover the data integrity and does this trigger a rebalance or other intensive operation that will impact performance?   Is the solution able to dynamically detect new storage resources and add them with minimal disruption to the available resource  pool?  Does the software storage presentation layer for all storage products sufficiently abstract storage clients from growth and shrinkage in the underlying storage resources? Is the solution able to dynamically scale capacity, performance, and I/O? Does the solution provide single-plane-ofglass management framework for storage systems deployed across a variety of physical storage topologies including multiple vendor environments, at single or multiple locations? Does the solution enable separate data into different tiers based on service-level agreement and performance (IOPS) requirements? The solution should enable data movement between tiers seamlessly to adjust for dynamic performance requirements and technology refreshes? Does the solution enable an online view of used and available storage capacity specific to each tenant? Does the solution provide integrated storage platform for block and file access? The entire infrastructure should be managed by a common management interface. 10
    11. 11. IN F O R MATIO N AN D AS S E TS Streamlined Requirements Accelerate Adoption Standardized Response Checklists Accelerate TTM Shared Practices Drive Scale Available to Members at: www.opendatacenteralliance.org URL for Public content: www.opendatacenteralliance.org 11

    ×