Object-based Storage 101

1. Object-based Storage 101 Mike Mesnier January 2003 SNIA

2. Storage Trends/Facts • Storage is moving to the network • Servers connect to consolidated NAS or SAN storage • Storage and networking fabrics are converging • iSCSI, iFCP, RDMA/TCP, … • Storage is becoming more autonomous • Standards for richer interfaces and protocols • More functionality in the storage device • Research focusing on intelligent storage • Self-aware, self-managing, self-configuring

3. Load Balancers Tonight’s Talk DB Servers Web Servers File Servers Fire Walls Evolving Data Center Compute and storage platforms are tailored for specific functions. Switched Fabric Building Blocks Storage Bricks Compute Bricks SAN Storage

4. Storage Utopia  • Imagine a storage brick that is: • Always available and reliable • Self-securing • Self-managed • Infinitely scalable (i.e., stackable) Object-based storage is a step closer…

5. Agenda •  Storage today • Emerging solutions • Object-based storage • SNIA activity

6. HOST HOST HOST Storage App. Storage App Storage App CLIENT CLIENT … Network Network … Direct Attached Storage File System … Storage Area Network Network Attached Storage Architectures Today Local Storage Shared Data Shared Capacity How did these evolve?

7. The Trade-offs • DAS – physically secure and simple • Not scalable • Limited connectivity for capacity sharing • No data sharing • SAN – scalable capacity sharing • Limited (coarse) security through switch • No data sharing • NAS – secure sharing (data or capacity) • Limited scalability

8. The Usage Models • DAS and SAN provide raw block storage • No model for the stored data (e.g., files) • No support for data sharing (e.g., concurrency control) • Storage applications built using DAS or SAN • File systems, databases, video servers, etc. • App. implements a data model (e.g., a file) • May implement direct data sharing (e.g., via clustering) • NAS is an application for indirectly sharing data • Servers export local file systems over the network • Clients share data by sharing files

9. Challenge: Data Sharing • Data centers need to share data. • Backup, HSM • Clustering for scalability (e.g., file server and db) • Sharing data directly on the SAN is difficult. • Concurrency control, lock management, versioning • Distributed security • Sharing data through NAS is easy • But imposes limits in scalability • Single point of failure & bottleneck

10. Agenda • Storage today • Emerging solutions • Object-based storage • SNIA activity

11. Emerging Solutions • Virtualization (NAS & SAN) • Aggregates heterogeneous NAS and SAN devices • Clustering the file system • Mitigates file server bottleneck • Giving clients direct access to storage devices • File servers share block metadata with clients • Eliminates file server bottleneck • Changing the device interface • From blocks to objects

12. OSD TWG FILES Network NAS Clients e.g. Web servers Clients need direct access to remove bottleneck. NAS Virtualization + Clustering SAN Virtualization 1st Generation File Server BLOCKS NAS Islands SAN Islands

13. Block-Based Storage 2nd Generation File Server Clients Must be trusted METADATA Servers DATA Trusted SAN Eth switch MANAGEMENT Difficult to directly share

14. Agenda • Storage today • Problems and partial solutions •  Object-based storage • SNIA activity

15. Object Storage • An object comprises • Application data (e.g., file, record) • Device-managed metadata (e.g., block allocation) • User-accessible attributes (e.g., access times) • Objects have file-like methods for access • Open, close, read, write, get/set attributes • Commands are authorized • Object-based storage devices • Disk drive, appliance, controllers ID x123 Blocks:3,42 Length:512 Objects can be self-describing!

16. CPU Applications System Call Interface CPU File System User Component Applications System Call Interface File System User Component File System Storage Component File System Storage Component Block I/O Manager Block I/O Manager Storage Device Storage Device Object Storage Model Object Interface Block Interface

17. So What’s the Real Value of Objects?

18. The Value of Objects • Better security via capabilities • Each object can have its own security domain • All I/O is authorized by the device • Easier to share data • Files and records can be stored as objects • Low-level metadata managed by device • Opportunities for intelligence • Attribute-based learning for resource allocation • Better caching, pre-fetching and staging of data • Self-configuring storage w/ continuous reorganization • Layout objects to best serve client requests

19. Value #1: Security • Separates policy from enforcement • Storage managers set policy • Storage devices enforce the policy • Prevents unauthorized access • Minimizes interaction with storage manager • Minimizes state kept on device • For better scalability, recovery and cost

20. Security Types • Types of security • Authentication – “you are who you say” • Authorization – “you have permission” • Integrity – “data is not corrupted/modified” • Privacy – “data is not seen” • TWG is considering two scenarios • Channel is trusted • Channel is not trusted OSD handles all but authentication.

21. Preventable Attacks • Snooping or modification of commands and data • Unauthorized access via modified capability • Delay and replay attacks • Guards against these attacks, respectively: • Transport or app-level encryption for privacy • Transport or app-level digests for integrity • Cryptographically secure capability • Nonce (timestamp) attached to each command • Requires loosely synchronized clocks • Only needed when channel is not trusted

22. Value #2: Data Sharing • Less metadata to keep coherent • No block allocation or free block lists • Shorter “lists” to manage • Objects may contain aggregation metadata • Leads to better scalability • Backup and HSM • No need to co-locate w/ application (e.g., file system) • Only backup necessary objects (not entire volume) OSD is really a file system less the naming

23. Access Request DATA SECRET KEY Validate Capability SECRET KEY SECRET KEY 3rd Generation File Server Clients SAN Eth switch Managers MANAGEMENT Intelligent Device Space ManagementBackup/RecoveryQoS via attributesSecurity Object-based Storage Devices

24. Value #3: Intelligence • Objects can have rich attributes • Timestamps, accounting information, QoS parameters, group and user information, client-specific usage patterns • Many opportunities for policy-based management • E.g, attributes may describe backup and QoS policies • Attributes may also provide “information gain” • An object’s actions may be correlated with its attributes • E.g., Any object written within the last 24 hours will be read up at 4 a.m. the following day (i.e., for backup) • Can devices actually learn?? • This is an active research topic • OSD facilitates a further investigation • Big questions: which attributes really matter?

25. Agenda • Storage today • Emerging solutions • Object-based storage •  SNIA activity

26. The SNIA TWG for OSD • Charter and Program of Work: • Requirements for OSD • Transport independent definition of OSD • SCSI Standard for OSD • White papers & industry demonstrations • ~100 members and over 30 organizations • academia, industry, National Laboratories and startups.

27. Work Items in the TWG • Establishing the commands – v1 DONE • Establishing the attributes – v1 DONE • Security architecture – v1 DONE • How should we identify and locate objects? • How to maintain integrity through failures? • Should we support transactional semantics? • Management of hundreds or thousands of OSDs.

28. Basic I/O Space Mgmt Session “hints” Attributes Other cmds OSD Functions • Basic Protocol • Read • Write • Create • Delete • Open • Close • Get • Set • Append • Clear • Security • Authorization • Integrity • Privacy • Attributes • Aid to file systems • Hints to device • QoS and Priorities • Logging & Statistics

29. Summary • A big challenge in the enterprise is data sharing • Must be secure and scalable • Objects complement existing technologies • Add security, low-overhead data sharing and intelligence • Enable the 3rd generation file server • OSD is more active now than ever • SNIA has become the focal point • Will complete v1 SCSI standard 1st half of this year.

30. Call to Action • How must your file system change to support OSD? • How will OSD change your backup story? • See the latest OSD standard at T10 • Understand our plans for other transports • Get involved in the OSD TWG • Architecture • Standards efforts • Industry demonstrations

31. Further References • Academic research • www.pdl.cmu.edu • www.dtc.umn.edu • csl.cse.ucsc.edu/obsd.shtml • Standards work • www.snia.org/osd • www.nsic.org/nasd • www.t10.org/scsi-3.htm (see OSD) • Industry research & development • www.intel.com/labs/storage/osd • Download OSD Reference Code • www.haifa.il.ibm.com/storage.html • www.lustre.org • www.panasas.com

32. Our Leaders • Mike Mesnier, Julian Satran (co-Chairs) • Applications – Erik Riedel • Education – Tom Ruwart • Management – Ken Samarra • Security – Michael Factor Contact us to get involved!