Proof of Concept IBM CLOUD OBJECT

Transcription

1 Proof of Concept IBM CLOUD OBJECT By Randy Frye Systems Engineer ATS Innovation Center, Malvern PA September October 2017

2 INTRODUCTION IBM Cloud Object Storage is part of the IBM family of Storage and Software-Defined Infrastructure. IBM Cloud Object storage allows you to choose flexible deployment options dedicated and private cloud or public and shared cloud, implemented within a region or across. IBM Cloud Object Storage uses a cluster of storages nodes to store pieces of the data across the available nodes. Its architecture dramatically increases the tolerance to node and disk failures. This document will provide a perspective of the use cases, capabilities, and ease of use of IBM Cloud Object Storage, from the point of view of a Storage Administrator familiar with Fibre-Channel-attached storage. This Proof of Concept is specifically focused towards on-premises Private Cloud COS deployments. 01

3 HOW IT WORKS IBM Cloud Object Storage (COS) is deployed as a cluster using three types of nodes: A Manager to configure and manage the COS infrastructure, Accessers to provide storage system endpoints for applications to access to the underlying storage, and Slicestors to provide data storage. The Accessers utilize a mathematical Information Dispersal Algorithm (IDA) to transform a given object to be stored into multiple slices in such a way that the original object can be read/retrieved from only a subset of those slices. Those slices are then stored on the Slicestor nodes. Use Cases IBM Cloud Object Storage is not a replacement for all other types of storage. There are specific uses to which Cloud Object Storage is well-suited, and other uses to which it is not. If your application is highly transactional, requiring high IOPs at consistent low latency such as a typical database or mission-critical or SAP applications COS may not be the best solution. Instead, Block Storage (such as Fiber-Channel attached storage) will likely be required to provide the performance required for such applications. Block storage utilizes structured data, and must be attached to an operating system to be accessed. COS is a great solution for large-scale data (hundreds of TeraByte to hundreds of PetaBytes) that might be required to be accessible simultaneously from multiple sites, where instantaneous high-iops response is not required. COS becomes considerably more costeffective with multiple PetaBytes of capacity and three or more sites (whether regional or geographically disperse). Cloud Object Storage is well-suited to storage requirements for applications such as document/image/video/music repositories, archives, log files, or large data sets that are not in constant application use. 02

4 COS is designed to store unstructured data as objects. COS is designed to store unstructured data as objects, allowing access from any source through API s or http/s URL s. The data is referenced by object names stored in COS metadata, allowing any system with appropriate credentials to locate any given object data for access. This type of unstructured data is becoming more and more prevalent in today s environments, comprising an estimated 80percent of all data. Even many WWW Web pages consist of a combination of Block-Storage based structured data such as pricing, transactions and statistics, File-Storage based data such as web page styles and structures, and Object-Storage based data such as Images. And on typical web pages, the images are usually a majority of the storage capacity used to present the page. To utilize a metaphor, liken a piece of data to parking a car: With Block Storage, when you write your data, it s like driving into a parking garage (storage system), getting your ticket (block allocation and write acknowledgement), picking a space and parking (writing your data in the allocated blocks). When you read your data, you look at your ticket to find the location where your car is (block where data is located), go to that parking space (block on storage system), and pay your ticket fee and drive out (read acknowledgement and data retrieval). With Object Storage, when you write your data, it s like driving up to valet parking (COS Accesser), and getting your valet ticket (data Object ID). The valet then takes care of figuring out where to park your car with no knowledge of that location required by you (COS IDA and writing to Slicestores). When you read your data, you present the valet ticket (data Object ID) to the valet (COS Accesser). The valet (COS Accesser) figures out where your car is parked (where the Object ID is located), and retrieves it for you (data retrieval). The Information Dispersal Algorithm (IDA), which is applied to every written object, creates multiple slices of each object, and puts one slice on each of the Slicestor storage nodes (the number of Slicestors is referred to as the IDA Width ). The flexible configuration of COS also allows for different configurations to suit specific use cases, all within the same COS system. 03

5 The flexible configuration of COS allows for different configurations to suit specific use cases. The configuration of how many slices must be available is very customizable in IBM COS, allowing you to specify a Read Threshold (how many of the total number of Slicestor storage nodes must be accessible in order to still have access to the data), and a Write Threshold (one or more higher than the Read Threshold ), which specifies the minimum number of slices that must be available for data writes to be accepted. The Read Threshold determines the availability or your data, and the Write Threshold presents a trade-off between reliability of new data and accessibility to write new data. Consider an example of an Image repository provider: The COS system is set up across three sites with a IDA width of 30, and a Read Threshold of 21, enabling data read accessibility as long as at least 21 of the 30 Slicestor nodes are available. End-users store their images in this COS storage pool, with certain expectations. There is an expectation that their images will be safe and not susceptible to irretrievable loss. So, one COS storage vault might be set up with a high Write Threshold such as 28 of 30 slices. This will prevent users from writing new images if more than 2 of the Slicestor nodes are unavailable less availability, but in turn will still have the data available even if 7 more Slicestor nodes fail (21 of 30 still available) more reliability. This provides a very high data reliability for any newly written images. Now let s say that the Image repository provider also creates thumbnails of all images for presentation to the users. Those thumbnails are the first thing users see when they re looking through the repositories, so there s an expectation that they are always available. So, a second COS storage vault might be created with a Write Threshold of 22 of 30 slices. New thumbnails can be created and stored even with only 22 Slicestor nodes operational more availability. However, just 2 more Slicestor node failures (only 20 of 30 slices available) would result in loss of all data less reliability. But since these thumbnail images can be recreated from the reliably intact original images, that s acceptable. 04

6 CLOUD OBJECT STORAGE CAPABILITIES AND BENEFITS When considering the storage requirements for a given scenario, there are numerous considerations: Price (both Capital and Operational), Reliability / Availability / Serviceability (RAS), Performance, Scalability, Security, Ease of Management and Use, Retention and Compliance, Switching Infrastructure, and Disaster Recovery. Price and RAS COS is implemented with low-cost NLSAS storage on industry-standard servers or VM s, and utilizes lower-cost and often pre-existing Ethernet switching infrastructure. This makes the Capital costs for COS significantly lower than equivalent capacity in Fiber Channel SAN-attached storage, which requires vendor-designed storage controller hardware and a FC network. 05

7 In addition, the implementation of IBM s COS makes it possible to have a highly redundant storage deployment, spanning multiple sites, without the need for complete multiple copies of the data for availability. The configuration of how many slices must be available is very customizable in IBM COS, but as a simple example, consider a 3-site COS deployment with 12 storage nodes (4 per site), and a Read Threshold of 7 slices. The IDA is applied to a given object, creating 12 slices, and one slice is put on each of the 12 storage nodes. This object can then be retrieved by reading any 7 of the 12 slices. In terms of reliability, you are able to lose an entire site (4 nodes) plus 1 additional node, and still have access to your data. In terms of price, this only costs you, in terms of RAW storage, 171 percent (12/7) of your usable capacity. Compare to a typical Fiber Channel SAN-attached storage, where you would typically have RAID overhead plus the need to have your data exist at a minimum of two sites percent RAID overhead percent site redundancy overhead = 225 percent of your usable capacity. And with considerably less redundancy than COS, as loss of a single RAID array at both sites would result in loss of data access. Since COS s IDA can be configured to provide sufficient redundancy to allow for complete loss of a site, a complete second set of controllers and disk spindles for site Disaster Recovery is not required, as illustrated in above example. COS also performs CRC-32 data integrity checks on slices and entire files to ensure bit-perfect data delivery, and performs always-on continuous error correction. This built-in integrity checking is performed at regular intervals, even on data that is not recently accessed, providing self-repair capability. This self-repair capability also ensures missing slices (due to hardware failure for example) are rebuilt in a timely manner with no operator intervention required. Software upgrades, hardware refreshes, disk/node/site failures can be accommodated without loss of system availability. The self-repairing integrity checking also allows for moves of entire Slicestor storage nodes and Accessers between sites without disruption to data access (as long as sufficient Slicestors are left online to provide the required Read Threshold ). 06

8 COS can provide data access that is compatible with S3, OpenStack Swift, and Simple object API s. COS can provide data access that is compatible with S3, OpenStack Swift, and Simple object API s. Storage vaults can be configured with multiple authentication methods (internal users, Active Directory, OpenLDAP, S3 secret access key, OpenStack Keystone Identity Service, PKI), as well as anonymous read or read/write. And authenticated users can have owner, read/write, or read-only privileges to a given storage vault. In comparison to some of the other object stores like Ceph, IBM COS provides an ease of deployment, a polished interface and removes the headache of massive architectural design considerations and a requirement around resourcing. Ceph provides File, Block and Object over 1 unified namespace. While this might allow for flexibility, it also adds complexity. Looking into Ceph, we found that while it might enable a lower TCO, it is quickly offset by a need for staffing as the product needs to managed and maintained constantly. The number of tunable options can be overwhelming and without a deep understanding of the product it can cause serious unforeseen performance impacts. Ceph may offer many different products rolled up into one, and while this is convenient, planning and designing all of the commodity hardware for each Ceph component requires a deep understanding of the workload that will run on the object store which might be an unknown. Incorrect hardware purchases can lead to huge performance impacts and can be a very costly mishap. Maintaining each and every operating system in the cluster also requires the resources supporting the cluster to have excellent Linux Administration skills. 07

9 All-or-Nothing Transform Encryption is applied to every write before it is sliced and dispersed. Performance COS is not going to be fast, compared to Fiber-channel SAN-attached storage. FC storage will typically use 10k/15k and/or flash drives, as compared to the typical NLSAS drives in COS. And access to COS storage is Ethernet-based, sometimes traversing to remote sites, as compared to fast Fiber-Channel storage, typically attached via a local site SAN. COS does optimize data access by re-ranking response times of Accesser nodes and Slicestor storage nodes dynamically during all reads, enabling redirecting of read requests to optimally performing storage nodes. And writes are optimistically written to all Slicestor nodes in parallel, but are acknowledged as soon a configurable Write Threshold is met any missing slices resulting from an inaccessible Slicestor node are automatically detected and rebuilt once the node is available. Scalability COS allows for easy and generous scalability. Capacity can be added at any time by adding more Slicestor storage nodes, with the capability for thousands of storage nodes per system. Additional capacity can be deployed in existing or new storage pools and vault containers. Access points can be added at any time by adding accessors, providing the capability to increase system throughput and/or to add local system accessibility at additional site locations. Both can be added non-disruptively, and performance of the system has a near linear increase in throughput and HTTP operations as the system grows. And COS s global namespace supports yottabyte-scale (1038) object ID s per storage vault. Security All-or-Nothing Transform Encryption is applied to every write before it is sliced and dispersed. This serves to protect data security in motion (between Accessers and Slicestors), as well as data at rest. Transport Layer Security (TLS) is also supported on client-to-accesser networks to provide end-to-end data-in-motion protection. All COS nodes have NSA hardening guidelines applied, and utilize digital certificates and internal firewalls to protect from rogue device attacks. 08

10 IMPLEMENTATION AND SYSTEM EASE OF USE In the ATS Innovation Center, IBM Cloud Object Storage was deployed on a VMWare infrastructure, using one VM for Management, 2 VM s for Accessors, and 6 VM s for SliceStore storage nodes. A single storage vault containing a single Access Pool, was defined with a Slice Width = 6 and Read Threshold = 4. This makes the effective usable capacity 4/6 of the total SliceStore host s RAW capacity. A local user account was then created with access keys and given ownership permission to the storage vault. Anonymous access was also granted to the vault. This complete setup, utilizing nine pre-cloned Linux VM s, was implemented in just over an hour. Write and read access to Object files within the Storage Vault was tested successfully with ease. The COS Manager Web Interface is very easy to use, presenting a single pane of glass view into the entire COS system. The default screen displays a top-level overall health indicator of the system and underlying physical hardware. Drill-down access to information and configuration of the Manager, Accesser and Slicestor nodes is available, providing easy view of node health, IP address, model, and software version. Similar drill-down information/ configuration access is available for Slicestor drives (including drive health, capacity, and information), Storage Vaults (including vault health, name, raw/usable capacities, IDA width and read/write thresholds, quotas, and encryption), and Storage Pools (including names, pool capacities, and which Storage Vaults are in the Pool). COS Manager also has numerous easily-accessible graphs available to visualize key performance indicators and system health. A real-time event stream provides historical records of the system, including conditions that impact the Manager/Accesser/Slicestor nodes, the Storage Vaults, and the Storage Pools. A real-time incident stream displays a list of current issues that require operator intervention to maintain the health of the COS system. And an audit stream provides a historical record of system configuration changes. COS Manager also can be configured to generate , SNMP traps, and/or syslog forwarding for incident and event alerting. 09

11 Want to Learn More? Consider IBM Cloud Object Storage for applications such as document/image/video/music repositories, archives, log files, or large data sets. At ATS, we have a very diverse Innovation Center where we implement Proof of Concepts and specialize in the implementation and architecture of advanced technology. Please contact us with any questions! THEATSGROUP.COM/COMPANY/CONTACT About the ATS Group Since our founding in 2001, the ATS Group has consulted on thousands of system implementations, upgrades, backups and recoveries. We also support customers by providing managed services, performance analysis and capacity planning. With over 60 industrycertified professionals, we support SMBs, Fortune 500 companies, and government agencies. As experts in IBM, VMware, Oracle and other top vendors, we are experienced in virtualization, storage area networks (SANs), high availability, performance tuning, SDS, enterprise backup and other evolving technologies that operate mission-critical systems on premise, in the cloud, or in a hybrid environment.