Cloud overview
In this chapter, we introduce you to cloud concepts and explain how IBM Transparent Cloud Tiering (TCT) enables cloud integration with IBM DS8000 systems that run IBM z/OS environments. You get a basic understanding of what a cloud is in the context of TCT, through a short description of cloud storage versus cloud computing.
This chapter describes the following topics:
2.1 What defines a cloud in the context of TCT
The cloud is a combination of several different solutions, components, and services. It consists of different layers.
Figure 2-1 provides a comprehensive diagram that shows the different layers and where TCT integrates with the cloud:
•Application Layer: Applications can be hosted and run, and can also take advantage of pre-coded software APIs that you can integrate to create new applications.
•Infrastructure Layer: Entire systems can be hosted. An Infrastructure Layer can be composed of a mix of interconnected cloud and traditional infrastructures.
•The Cloud Layer is composed of three main classes of components:
– Storage Layer
– Network Layer
– Compute Layer
•Within the Storage Layer, we have three Storage types:
– Block Storage
– File Storage
– Object Storage
TCT uses Object Storage architecture for storing data sets. We cover this architecture in more detail in this chapter.
Figure 2-1 TCT in the context of the cloud
2.2 Compute cloud versus a storage cloud
In short, the compute cloud provides the necessary components to run the applications for processing resources, and is where you can deploy and run your chosen software, including operating systems and applications.
The storage cloud holds the data and caters for operations like backing up and archiving data. As mentioned earlier in this chapter, TCT uses Object Storage architecture to store the data it manages in the cloud.
2.3 Types of storage
Before you use storage clouds, you must understand what a gateway is, its function, and how the data is managed between the mainframe and the cloud.
The following types of architectures (see Figure 2-2) can be used for storing data, where each type has its advantages:
•Block and File: This architecture is used on mainframes and other operating systems to store data. It has the advantages of being faster, IOPS-centric, flash-optimized, and allows various approaches.
•Object Storage: This architecture provides larger storage environments, or cool or cold data, which can scale to petabytes of data while being cloud-compatible.
Figure 2-2 Types of storage
Having a storage cloud that uses object storage has several benefits. A storage cloud significantly reduces the complexity of storage systems by simplifying data scaling within a single namespace. Also, the Representational State Transfer (REST) protocol is used for communication between the server and the client. The use of high-density, low-cost commodity hardware turns storage clouds into a scalable, cost-efficient storage option.
The TCT function of IBM DS8000 provides a method to convert the block to Object Storage without more hardware on the LAN.
On storage clouds, the data is managed as objects, unlike other architectures that manage data as a block of storage, as is done on mainframes.
For this reason, the communication between mainframe systems and storage cloud is done by an application responsible for converting cloud storage APIs, such as SOAP or REST, to block-based protocols, such as iSCSI or Fibre Channel, when necessary.
Therefore, the storage cloud can be considered an auxiliary storage option for mainframe systems to be used by applications, such as these:
•DFSMShsm to migrate and recall data sets
•DFSMSdss to store data that is generated by using the DUMP command
2.4 Cloud storage delivery models
Cloud delivery models refer to how a cloud solution is used by an organization, where the data is located, and who operates the cloud solution. There are multiple delivery models that can deliver the capabilities that are needed in a cloud solution.
The cloud delivery models are as follows:
•Public cloud
•Private cloud
•Hybrid cloud
These delivery models can be integrated with traditional IT systems and other clouds. They are divided into two categories:
•On-premises: Consists of a private cloud infrastructure at your organization’s location.
•Off-premises: Consists of a cloud infrastructure that is hosted in a cloud service provider’s location.
Public cloud
A public cloud is a solution in which the cloud infrastructure is available to the general public or a large industry group over the internet. The infrastructure is not owned by the user, but by an organization that provides cloud services. Services can be provided at no cost, as a subscription, or as a pay-as-you-go model.
There is another delivery model option that is known as community cloud, or multi-tenant cloud, which typically consists of a public cloud that is shared among multiple organizations, to lower costs. For ease of understanding, this book treats this delivery model as part of the public cloud category.
Private cloud
A private cloud is a solution in which the infrastructure is provisioned for the exclusive use of a single organization. The organization often acts as a cloud service provider to internal business units that obtain all of the benefits of a cloud without having to provision their own infrastructure. By consolidating and centralizing services into a cloud, the organization benefits from centralized service management and economies of scale.
A private cloud provides an organization with some advantages over a public cloud. The organization gains greater control over the resources that make up the cloud. In addition, private clouds are ideal when the type of work that is being done is not practical for a public cloud because of network latency, security, or regulatory concerns.
A private cloud can be owned, managed, and operated by the organization, a third party, or a combination of the two. The private cloud infrastructure is provisioned on the organization’s premises, but it can also be hosted in a data center that is owned by a third party.
Hybrid cloud
As the name implies, a hybrid cloud is a combination of various cloud types (public, private, and community). Each cloud in the hybrid mix remains a unique entity, but is bound to the mix by technology that enables data and application portability.
The hybrid approach allows a business to use the scalability and cost-effectiveness of a public cloud without making available applications and data beyond the corporate intranet. A well-constructed hybrid cloud can service secure, mission-critical processes, such as receiving customer payments (a private cloud service) and secondary processes, such as employee payroll processing (a public cloud service).
IBM Cloud Object Storage and TCT
IBM Cloud® Object Storage offers all the delivery model options that were described previously. Figure 2-3 provides a summary of each option, with its capabilities.
Figure 2-3 IBM Cloud Object Storage capabilities
The TCT solution provides an integration of the IBM DS8000 storage system when running in z/OS environments with a IBM Cloud Object Storage infrastructure, which can be any of the options that are described above.
For detailed information about the IBM Cloud Object Storage service offering, see Cloud Object Storage as a Service: IBM Cloud Object Storage from Theory to Practice - For developers, IT architects and IT specialists, SG24-8385 or go to the IBM Cloud Object Storage website at this link:
For other IBM Cloud Storage solutions, see IBM Private, Public, and Hybrid Cloud Storage Solutions, REDP-4873 or go to the IBM Cloud website at the link:
2.5 Object storage hierarchy
Data that is written to a cloud by using TCT is stored as objects and organized into a hierarchy. The hierarchy consists of accounts, containers, and objects. An account can feature one or more containers and a container can include zero or more objects.
2.5.1 Storage cloud hierarchy
The storage cloud hierarchy consists of the following entities:
•Account
•Containers
•Objects
Each entity plays a specific role on data store, list, and retrieval by providing a namespace, the space for storage, or the objects. There also are different types of objects, data, and metadata.
A sample cloud hierarchy structure is shown in Figure 2-4. Each storage cloud component is described next.
Figure 2-4 Cloud hierarchy
Account
An account is the top level of the hierarchy and is created by the service provider, but owned by the consumer. Accounts can also be referred to as projects or tenants and provide a namespace for the containers. An account has an owner that is associated with it, and the owner of the account has full access to all the containers and objects within the account.
The following operations can be done from an account:
•List containers
•Create, update, or delete account metadata
•Show account metadata
Containers
Containers (also called buckets or vaults) are similar to folders in Windows or UNIX, and provide a way to organize objects. Depending on your cloud solution, you can, for example, set up container-to-container synchronization, quotas, object versioning, and other policies on a container level. One main limitation is that containers cannot be nested. Therefore, you cannot create a container within another container. Container names can be up to
256 characters.
256 characters.
|
Note: Containers in an object storage context have nothing to do with application containers in a containerized virtualization environment, such as Docker, Kubernetes, or Red Hat OpenShift.
|
Access to objects within a container are protected by using read and write Access Control Lists (ACLs). There is no security mechanism to protect an individual object within a container. After a user is granted access to a container, that user can access all of the objects within that container.
The following operations are supported for containers:
•List objects
•Create container
•Delete container
•Create, update, or delete container metadata
•Show container metadata
Objects
Objects contain the actual user data that is stored in object storage. An object can contain any type of data and be of any size. Object storage by definition doesn’t distinguish between types of data. Object storage creates and uses metadata to reference objects in its uniform data store. Metadata can also be used to specify certain object attributes.
The following operations are supported for objects:
•Read object
•Create or replace object
•Copy object
•Delete object
•Show object metadata
•Create, update, or delete object metadata
The objects can have a defined, individual expiration date. The expiration dates can be set when an object is stored and modified by updating the object metadata. When the expiration date is reached, the object and its metadata are automatically deleted.
However, the expiration does not update information about the z/OS host; therefore, DFSMShsm and DFSMSdss do not use this feature. Instead, DFSMShsm handles the expiration of objects.
User-created backups (backups that are created outside of DFSMShsm to the cloud) must be managed by the user. Therefore, a user must go out to a cloud and manually delete backups that are no longer valid. At the time of writing, this process is not recommended.
|
Note: Older OpenStack Swift implementations can have an object size limit of 5 GB. TCT splits up data sets that are larger. The limitation is transparent to the TCT user. For other object storage types, the restriction does not apply.
|
2.5.2 Metadata
In addition to the objects, metadata is recorded for account, container, and object information. Metadata consists of data that contains information about the stored data. Some metadata information might include data creation and expiration date, size, owner, last access, and other pertinent information.
The difference between data and metadata is shown in Figure 2-5.
Figure 2-5 Data and metadata differences
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.