Configuring the IBM DS8000 for Transparent Cloud Tiering
This chapter describes how to configure the IBM DS8000 to support Transparent Cloud Tiering (TCT).
In the first part, we explain how to set up the network connection. Then, we describe how to set up the cloud connection, providing examples for most supported cloud target types.
Finally, we show how to set up the DS8000 Hardware Management Console (HMC) as cloud proxy for Data Facility Storage Management Subsystem (DFSMS).
This chapter includes the following topics:
6.1 Configuring the IBM DS8000 for TCT
To access the cloud services, your DS8000 hardware must be configured to communicate with the cloud by using TCPIP connections. This configuration includes defining the following components:
Ethernet port configuration
Cloud storage configuration
Prepare a DS8000 user ID for the cloud proxy functions (for all cloud target types except Swift).
6.1.1 Ethernet configuration
Assuming that you connected the DS8000 to your network according to 4.1, “Ethernet connections on DS8000” on page 38, you can now configure the Ethernet ports that you are using for TCT. You must configure the Ethernet ports enable network connectivity. Use the lsnetworkport command from the DS Command-line Interface (DSCLI) to display any current Ethernet configuration. Example 6-1 shows the output of the lsnetworkport command where no network ports are configured yet.
Example 6-1 Output from lsnetworkport command with unconfigured network ports
dscli> lsnetworkport
ID IP Address Subnet Mask Gateway Primary DNS Secondary DNS State
============================================================================
I9831 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Offline
I9832 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Offline
I9833 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Offline
I9834 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Offline
I98A3 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Offline
I98A4 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Offline
I9B31 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Offline
I9B32 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Offline
I9B33 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Offline
I9B34 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Offline
I9BA3 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Offline
I9BA4 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Offline
Example 6-1 lists 12 network ports. The four port IDs that are marked red belong to the 1 Gbps Ethernet ports that are always available in the DS8000 internal servers. The eight port IDs marked blue belong to the TCT network adapter features that can be ordered and installed separately. The port IDs on these adapters are counted from top to bottom. For more information about DS8000 network connectivity for TCT, see 4.1, “Ethernet connections on DS8000” on page 38.
Use the setnetworkport command to define the network settings for each port you want to use, as shown in Example 6-2.
Example 6-2 Configuring DS8000 network ports for TCT
dscli> setnetworkport -ipaddr 9.155.112.15 -subnet 255.255.240.0 -gateway 9.155.112.1 -primary 9.0.138.50 -secondary 9.0.136.50 I9B32
CMUC00250I setnetworkport: You configured network port I9B32 successfully.
dscli> setnetworkport -ipaddr 9.155.112.16 -subnet 255.255.240.0 -gateway 9.155.112.1 -primary 9.0.138.50 -secondary 9.0.136.50 I9832
CMUC00250I setnetworkport: You configured network port I9832 successfully.
You must specify at least the -ipaddr and -subnet parameters, defining the IP address and the subnet mask for a port. If you need routing to access the cloud storage target from the DS8000 TCT network connections, you can specify a gateway by using the -gateway parameter. If you need name server resolution to access the object storage endpoint, you can specify up to two DNS servers by using the -primary and -secondary parameter.
 
Note: The -gateway, -primary, and -secondary parameters set the default gateway and DSN servers for all TCT network connections of a DS8000 internal server. You can have only one gateway and one set of DNS servers. Therefore, routing into different networks is not possible. All cloud targets must either be accessible through the local subnet or a single gateway.
It is possible to route each internal server’s connection through different subnets if each server can access all cloud targets.
After the configuration is complete, use the lsnetworkport command again to confirm that your network configuration is correct. Example 6-3 shows a sample network configuration with four configured ports.
Example 6-3 Verifying the network configuration
dscli> lsnetworkport
ID IP Address Subnet Mask Gateway Primary DNS Secondary DNS State
================================================================================
I9831 0.0.0.0 0.0.0.0 9.155.112.1 9.0.138.50 9.0.136.50 Offline
I9832 9.155.112.16 255.255.240.0 9.155.112.1 9.0.138.50 9.0.136.50 Online
I9833 192.168.100.51 255.255.255.0 9.155.112.1 9.0.138.50 9.0.136.50 Online
I9834 0.0.0.0 0.0.0.0 9.155.112.1 9.0.138.50 9.0.136.50 Offline
I98A3 0.0.0.0 0.0.0.0 9.155.112.1 9.0.138.50 9.0.136.50 Offline
I98A4 0.0.0.0 0.0.0.0 9.155.112.1 9.0.138.50 9.0.136.50 Offline
I9B31 0.0.0.0 0.0.0.0 9.155.112.1 9.0.138.50 9.0.136.50 Offline
I9B32 9.155.112.15 255.255.240.0 9.155.112.1 9.0.138.50 9.0.136.50 Online
I9B33 192.168.100.52 255.255.255.0 9.155.112.1 9.0.138.50 9.0.136.50 Online
I9B34 0.0.0.0 0.0.0.0 9.155.112.1 9.0.138.50 9.0.136.50 Offline
I9BA3 0.0.0.0 0.0.0.0 9.155.112.1 9.0.138.50 9.0.136.50 Offline
I9BA4 0.0.0.0 0.0.0.0 9.155.112.1 9.0.138.50 9.0.136.50 Offline
The ports marked blue are configured for routing. The defined gateway is in their network segment. They can be used, for example, to connect to a public cloud endpoint.
The ports marked red are in a private network. They are not able to reach the gateway. They can be used to connect, for example, to an on-premises object storage or a TS7700 Grid that is in the same private network segment.
 
Note: Network ports cannot be created or deleted. The only way to unconfigure a port is to clear the configured IP address by setting it to “0.0.0.0”.
With the Ethernet configuration complete, you can proceed to the cloud configuration process.
 
Note: You can have up to six Ethernet ports available in each DS8000 internal server. It is a best practice to use only ports of the same type, for example only the 10 Gbps ports, to avoid performance imbalance. For more information about networking requirements, see Chapter 5, “Connectivity and network setup for Transparent Cloud Tiering” on page 45.
6.1.2 Cloud configuration
In this step, you configure the DS8000 for access to the cloud storage. DS8000 cloud connections are managed by using DSCLI commands. There is no DS8000 GUI equivalent available.
 
Important: Since Release 9.2, the DS8900F supports up to eight independent cloud connections. Since this release, the way these connections are managed has changed:
If you define only one connection, everything works as before. All commands (create or delete connection) have an immediate effect.
As soon as you define more than one connection, any modification to the cloud connections requires an extra activation step. This step is disruptive to ongoing TCT operations. It removes and re-creates all defined cloud connections. Active TCT data transfers are terminated and must be restarted by the application that initiated them.
For more information and examples, see 6.3, “Managing multiple cloud connections” on page 60.
Use the mkcloudserver command to define a cloud object storage to your DS8000 system. Generally you provide the cloud target type, endpoint information, and cloud credentials with the command. However, the usage differs for the different cloud target types.
The following parameters are available for the mkcloudserver command:
-type (required): The cloud object storage target type. TCT supports the following types of Object Storage protocols and authentication mechanisms:
 – swift: Unencrypted (HTTP) communication to Swift cloud object storage.
 – swift-keystone: Secure Sockets Layer (SSL)/Transport Layer Security (TLS) secured authentication to a Swift keystone service to access Swift cloud object storage.
 – ibmcos: IBM Cloud Object Storage either on premises or in the IBM Cloud.
 – aws-s3: Amazon Simple Storage Service cloud object storage that uses the S3 API.
 – ts7700: IBM Virtual Tape Server TS7700 as cloud object storage.
-endpoint (required for all cloud target types except ts7700): The Uniform Resource Identifier (URI) to access the cloud object storage. For the swift-keystone type, it is the URI of the keystone authentication service.
 
-tenant (required for the swift and swift-keystone types, not used for all others): Specify the Tenant name that is provided by cloud storage administrator.
-username (required for all cloud target types, not allowed for TS7700): A user identifier for the cloud object storage account. For Amazon S3 type object storage solution, use the access key that is provided by the cloud administrator.
-pw (required for all cloud target types, not allowed for TS7700): A user credential for the cloud object storage account. For Amazon S3 type object storage solution, use the secret access key that is provided by the cloud administrator.
-nossl (optional): Allow insecure authentication with the object storage target. This parameter cannot be specified together with -rootcaloc, -intermcaloc, or -syscaloc.
 
Note: TCT secure data transfer with TS7700 is supported for DS8900F R 9.1 and later. For prior releases, the -nossl option is required for TS7700 as object storage target.
-rootcaloc, intermcaloc, syscaloc (required for swift-keystone and all Amazon S3 type targets if IP security is used. Optional for the TS7700 target type): Use these parameters to provide certificates to the DS8000 for secure authentication with the object storage. Specify the location of the certificate (Privacy-Enhanced Mail (PEM)) file that you want to import into the DS8000 system with each parameter. If you use self-signed certificates, only the SysCA option is required. If you use a CA, the root CA and intermediate CA can be provided. These parameters cannot be used if -nossl is specified.
 
Note: If you use TCT secure data transfer with TS7700, you must provide certificates only if you changed the TS7700 secure data transfer certificate. The DS8900F knows and accepts the factory-provided certificates of the TS7700.
 
-loc (optional and valid only for aws-s3 and ibmcos type targets):
 – ibmcos: Specify the name of your vault template on the IBM Cloud Object Storage service.
 – aws-s3: Specify the AWS Region as defined by the endpoint of the Amazon S3 service.
-keygrp (required if DS8000 TCT encryption is used, not valid for TS7700): Specify the key group that you defined for TCT encryption (for more information, see 3.6, “DS8900F multi-cloud support” on page 30).
-primary7700IPs (required and valid only for TS7700): Specify IP addresses of the primary TS7700 that you use as TCT cloud storage. You can specify up to four IP addresses (only IPv4 is supported). Separate them with a comma.
-secondary7700IPs (optional and valid only for TS7700): Specify IP addresses of the secondary TS7700 that you use as TCT cloud storage. You can specify up to four IP addresses (only IPv4 is supported). Separate them with a comma.
 
cloud_name (required): Specify a name for your cloud connection. Use the same name as in your DFSMS cloud definition (for more information, see 7.4, “Creating a DFSMS cloud network connection by using ISMF” on page 70). This parameter is a positional one. Place it at the end of the command without a keyword.
When you run the mkcloudserver command, the ability of the DS8000 and the object store to communicate is verified. Running the command also verifies that the data path is accessible and encryption certificates are valid. We provide examples for most supported cloud target types in the following sections.
 
Note: Anybody with access to the cloud credentials you use to connect a DS8000 to cloud storage has full access to all objects TCT stores in the cloud, including the capability to update, move, or delete data. Make sure that you treat these credentials with the appropriate care.
Connecting to on-premises IBM Cloud Object Storage
In this section, we explain how to connect your DS8000 to an on-premises IBM Cloud Object Storage System. Before connecting the DS8000, you must prepare the IBM Cloud Object Storage. For more information about this topic, see Configuring transparent cloud tiering.
During the configuration, you create an IBM Cloud Object Storage user and a Vault Provisioning Profile. To set up the DS8000 cloud connection, you need the Access Key and the Secret Access Key for this user and the provisioning code for the profile.
In Example 6-4, we show the command to configure the DS8000 cloud connection for the simple case without SSL and encryption.
Example 6-4 DS8000 cloud connection to IBM Cloud Object Storage without SSL and encryption
dscli> mkcloudserver -type ibmcos -username zbg...DId -pw jMn...AcA -nossl -endpoint http://9.155.115.167 -loc ztct IBMCOS
 
CMUC00560W mkcloudserver: Use of the -nossl flag allows user credentials such as username and password to be transmitted on the network insecurely. Are
you sure that you want to continue? [y/n]: y
 
CMUC00505I mkcloudserver: The entered Cloud server IBMCOS was created successfully on node 0.
CMUC00505I mkcloudserver: The entered Cloud server IBMCOS was created successfully on node 1.
We used the following command options:
type: The cloud storage target type ibmcos
endpoint: The IP address of one of the IBM Cloud Object Storage accessor nodes
username: The Access Key for the IBM Cloud Object Storage user
pw: The Secret Access Key for the IBM Cloud Object Storage user
nossl: Connect without authorization security
loc: The provisioning code for the IBM Cloud Object Storage Vault Provisioning Profile
The last parameter is a required positional parameter without keyword. Specify the name of your DS8000 cloud connection here.
 
Note: In our example, we specified the IP address of one accessor node of the IBM Cloud Object Storage, which is a single point of failure. For a production configuration, you would either provide the IP address of a load balancer that has access to several accessor nodes, or the virtual address of an accessor node pool.
In Example 6-5, we show another IBM Cloud Object Storage connection, this time with SSL and encryption support.
Example 6-5 DS8000 cloud connection to IBM Cloud Object Storage with SSL and encryption
dscli> mkcloudserver -type ibmcos -username zbg...DId -pw jM...AcA -endpoint http://9.155.115.167 -syscaloc ibmcos_sle_certificates.pem -loc ztct -keygrp 2 ibmcos
 
CMUC00505I mkcloudserver: The entered cloud ibmcos was created successfully on node 0.
CMUC00505I mkcloudserver: The entered cloud ibmcos was created successfully on node 1.
The meaning of the parameters for type, username, password, endpoint, and cloud connection name are the same as in Example 6-4 on page 54. We still provide a URL starting with http: for the endpoint, although we specified that SSL is being used. The systems will switch to https communication automatically after successful SSL negotiation.
We use the following extra parameters:
syscaloc: Specifies the file containing the IBM Cloud Object Storage System certificate. You can download it from the IBM Cloud Object Storage Manager.
keygrp: Specify the key group used for TCT encryption.
 
Note: Before you can use TCT encryption, you must configure your IBM Security Key Lifecycle Manager servers and DS8000 encryption settings (key server and key group) according to IBM DS8000 Encryption for Data at Rest, Transparent Cloud Tiering, and Endpoint Security (DS8000 Release 9.2), REDP-4500.
Connecting to the IBM Cloud Object Storage service in the public IBM Cloud
In this example, we connect the DS8000 to the IBM Cloud Object Storage service in the public IBM Cloud.
After you signed up to the IBM Cloud and defined the IBM Cloud Object Storage instance, you can create credentials for your service. The credentials are provided in JSON format like that shown in Example 6-6.
Example 6-6 Credential that is provided by IBM Cloud for IBM Cloud Object Storage
{
"apikey": "LB1Iki88rfqXJSy1oXFlAn8i0WLu_lzigjn0xTpAYG73",
"cos_hmac_keys": {
"access_key_id": "f9ae19f116de4a37a9e9f0e7d80348e3",
"secret_access_key": "97f858f693dfcbf4236b16b1c6f512295fcb99d034b138ad"
},
"endpoints": "https://control.cloud-object-storage.cloud.ibm.com/v2/endpoints",
"iam_apikey_description": "Auto-generated for key f9ae19f1-16de-4a37-a9e9-f0e7d80348e3",
...
Use the access_key_id and secret_access_key as username and password in the mkcloudserver command.
The endpoints definition does not directly provide an endpoint. It refers to a web page with all endpoints for the IBM Cloud Object Storage services. We show a section of this page in Figure 6-1.
Figure 6-1 IBM Cloud Object Storage service endpoints
Find the endpoint that matches the regional settings of the IBM Cloud Object Storage service you defined and use it for the endpoint parameter of the mkcloudserver command, as shown in Example 6-7.
Example 6-7 DS8000 cloud connection to the public IBM Cloud without SSL and encryption
dscli> mkcloudserver -type ibmcos -username 648...630 -pw f7b...e6f -nossl -endpoint http://s3.eu-de.cloud-object-storage.appdomain.cloud pubcos
CMUC00560W mkcloudserver: Use of the -nossl flag allows user credentials such as username and password to be transmitted on the network insecurely. Are you sure that you want to continue? [y/n]: y
CMUC00505I mkcloudserver: The entered cloud pubcos was created successfully on node 0.
CMUC00505I mkcloudserver: The entered cloud pubcos was created successfully on node 1.
 
Note: If you want to use SSL for secure authentication with the IBM cloud, you can download the endpoint security certificate (for example, by using the openssl command). Then, provide the certificate file in the syscaloc parameter of the mkcloudserver command.
Connecting to minio compatible object storage
In Example 6-8 on page 56, we show a command that creates a connection to our own on-premises IBM Cloud Object Storage based on the open source project minio (minio.io).
Example 6-8 DS8000 cloud connection to a minio S3 target without security and encryption
mkcloudserver -type s3 -username Y0B...8SX -pw 7Sv...Iex -nossl -endpoint http://9.155.49.146:9000 minioz
CMUC00560W mkcloudserver: Use of the -nossl flag allows user credentials such as username and password to be transmitted on the network insecurely. Are you sure that
you want to continue? [y/n]: y
CMUC00505I mkcloudserver: The entered cloud minioz was created successfully on node 0.
CMUC00505I mkcloudserver: The entered cloud minioz was created successfully on node 1.
The parameters that we must specify follow the same rules as in “Connecting to on-premises IBM Cloud Object Storage” on page 54, except for the -loc parameter. The S3 cloud target type does not support a location specification.
Connecting to a TS7700 Virtualization Engine
Before you can connect a DS8000 to a TS7700 Virtualization Engine (VE), the VE must be prepared:
A license for the DS8000 Object Store feature (Feature Code (FC) 5283) is required.
For TCT secure data transfer with TS7700, the TS7700 Secure Data Transfer feature
(FC 5281) is also required.
The client activates the feature.
An IBM service representative configures the TS7700:
 – Configures the system to handle object data and creates an object partition.
 – Defines the DS8000 systems that can store objects on this machine, by providing the IP addresses and serial numbers.
The client can now set the size of the Object Partition as needed.
If the TS7700 is a stand-alone system, there is an extra step to connect the TS7700 grid links to the network.
 
Additional information: For more information, see IBM TS7700 Series DS8000 Object Store User's Guide Version 2.0, REDP-5583. This publication is not updated yet to cover the changes that were introduced with TS7700 release 5.22 and FC 5283.
The connection to a TS7700 Virtualization Engine is different from the other cloud types because we need no cloud credentials. The DS8000 systems that are allowed to access the TS7700 as cloud storage are defined in the TS7700 by their IP addresses and serial numbers.
In Example 6-10 on page 58, we show the DSCLI command to connect a DS8000 to a single TS7700.
Example 6-9 DS8000 cloud connection to an IBM TS7700 Virtualization Engine
dscli> mkcloudserver -type TS7700 -primary7700IPs 192.168.100.1,192.168.100.2 TS7700
CMUC00505I mkcloudserver: The entered cloud TS7700 was created successfully on node 0.
CMUC00505I mkcloudserver: The entered cloud TS7700 was created successfully on node 1.
The following parameters are required:
type: Specify the cloud target type, TS7700.
primaryTS7700IPs: A comma-separated list of IP addresses of the Grid links of the TS7700 that you want to use for TCT data transfer.
The last parameter again is a required positional parameter without keyword. Specify the name of your DS8000 cloud connection here.
 
Note: With DS8900F R 9.1 and later, TCT supports compression with TS7700 as object storage. Compression is enabled or disabled in z/OS. You enable TCT compression in z/OS, as described in 7.5, “Enabling TCT compression with a TS7700” on page 77. You do not need to configure anything in the DS8900F or TS7700 to use TCT compression.
TCT secure data transfer with TS7700 is supported for DS8900F R 9.1 and later. For prior releases, the -nossl option is required, as shown in Example 6-10.
Example 6-10 DS8000 cloud connection to an IBM TS7700 Virtualization Engine without secure data transfer
dscli> mkcloudserver -type TS7700 -primary7700IPs 192.168.100.1,192.168.100.2 -nossl TS7700
CMUC00560W mkcloudserver: Use of the -nossl flag allows user credentials such as username and password to be transmitted on the network insecurely. Are you sure that you want to continue? [Y/N]: y
CMUC00505I mkcloudserver: The entered cloud TS7700 was created successfully on node 0.
CMUC00505I mkcloudserver: The entered cloud TS7700 was created successfully on node 1.
You can optionally specify a second TS7700 by using the secondary7700IPs parameter.
Connecting two TS7700 machines provides redundancy and improves performance. Object data transfers are balanced across the defined TS7700 systems.
With the new feature DS8000 Object Store Grid Policy Management (FC 5283), object replication is handled by the TS7700 engine and defined through TS7700 Object Policies and selected through different DS8000 and DFSMS cloud connections.
 
Note: You can specify up to four IP addresses for each TS7700. Only one link is used at a time. The others are for redundancy. Only IPv4 is supported.
Connecting to on-premises Swift cloud object storage
Example 6-11 shows a sample mkcloudserver command to configure a Swift Keystone authenticated cloud object storage as cloud server.
Example 6-11 Configuring a Swift cloud server
dscli> mkcloudserver -type swift-keystone -tenant tenant -username username
-pw password -endpoint http://9.155.117.45:5000/v2.0/ -rootcaloc
/home/ssl_cacert.pem -intermcaloc /home/user/ssl_cacert.pem -syscaloc
/home/user/ssl_cert.pem ibmcloud
For the swift and swift-keystone cloud target types, the cloud credentials are provided according to the following list:
tenant: The Tenant name that you were given (or specified yourself) when you signed up for the Swift cloud service. The tenant is sometimes also referred to as a Project.
username: User that can access to objects of your tenant (or Project).
pw: The password for this user.
rootcaloc, intermcaloc, or syscaloc: For the swift-keystone type that uses SSL/TLS to encrypt the authentication path, certificates are required to maintain a chain of trust between the DS8000 and the object store. If you use self-signed certificates, only the SysCA option is required. If you use a CA, the root CA and intermediate CA can be provided in the mkcloudserver command. These items point to a PEM file type that you can import into the DS8000 system.
The last parameter again is a required positional parameter without keyword. Specify the name of your DS8000 cloud connection here.
6.2 Maintaining the cloud server configuration
The following sections show how to list, update, or remove a cloud server configuration.
6.2.1 Listing a cloud server configuration
You can also list the cloud configuration on your hardware. Use the lscloudserver command to list cloud information. Sensitive information, such as user ID and password, is not displayed in the output. Example 6-12 displays a sample output from the lscloudserver command.
Example 6-12 Listing cloud information
dscli> lscloudserver
Date/Time: November 30, 2017 2:24:31 PM MST IBM DSCLI Version: 7.8.31.118 DS: -
name node type tenant endpoint
ibmcloud 0 swift-keystone test https://ibmcloud.ibm.com:5000/v2.0/
ibmcloud 1 swift-keystone test https://ibmcloud.ibm.com:5000/v2.0/
You can use the lscloudserver -l command to display more detail about the cloud connection. Example 6-13 shows the output for a connection to a TS7700 with secure data transfer enabled (nossl = false).
Example 6-13 Listing detailed cloud information
dscli> lscloudserver -l
name node type tenant user endpoint IP address Location nossl keygrp
=========================================================================================
TS7700 0 TS7700 - - - 192.168.100.1,192.168.100.2 - false -
TS7700 1 TS7700 - - - 192.168.100.1,192.168.100.2 - false -
6.2.2 Updating or removing a cloud server configuration
If you need to update any cloud settings, the existing configuration must first be deleted. Then, the new configuration can be defined. Use the rmcloudserver command to remove the existing cloud configuration. When the command is issued, a prompt message displays requesting a confirmation if the cloud server configuration is to be removed. If you want to continue with the removal, enter y, as shown in the Example 6-14.
Example 6-14 Removing a cloud server configuration
dscli> rmcloudserver ibmcloud
Are you sure you want to delete cloud server ibmCloud? [y/n]:y
The cloud server ibmcloud successfully deleted.
After deleting the old configuration, you can add a configuration by using the mkcloudserver command.
6.3 Managing multiple cloud connections
Since Release 9.2, a DS8900F supports up to eight independent cloud connections. Since this release, the way these connections are managed changed:
If you define only one connection, everything works as before. All commands (create or delete connection) have an immediate effect.
Starting with the second connection, any modification to the cloud connections requires an extra activation step.
If you define only one cloud target, or with the first definition, the mkcloudserver command becomes effective immediately. The command verifies the ability of the DS8000 and the object store to communicate and perform all necessary object storage operations, and whether the encryption certificates are valid. A connection removal in a single cloud setup also is effective immediately.
Starting with the second cloud connection definition, the mkcloudserver command accepts the configuration parameters and creates the internal configuration structures. Validation and activation of the connection happen only after you issue the activation command. Removing a cloud connection in a multi-cloud configuration also requires the activation step. To activate a modification, use the managecloudserver command with the -action applypndgconfig.
 
Note: If you remove all connections except the last one from a multi-cloud configuration, the configuration turns into a single-cloud configuration.
Example 6-15 on page 61 shows the commands that add and activate a second cloud connection to an existing one.
Example 6-15 Defining and activating a second cloud definition
dscli> mkcloudserver -type TS7700 -primary7700IPs 192.168.100.1,192.168.100.2 TS7700
CMUC00602W mkcloudserver: The cloud TS7700 was successfully created on node 0. To activate the cloud, run managecloudserver -action applypndgconfig command.
CMUC00602W mkcloudserver: The cloud TS7700 was successfully created on node 1. To activate the cloud, run managecloudserver -action applypndgconfig command.
 
dscli> lscloudserver
name node type  endpoint IP address Location keygrp State
=====================================================================================================
ibmcos 0 ibmcos http://9.155.115.167 - ztct - Active
ibmcos 1 ibmcos http://9.155.115.167 - ztct - Active
ts7700 0 TS7700 - 192.168.100.1,192.168.100.2 - - Activation Pending
ts7700 1 TS7700 - 192.168.100.1,192.168.100.2 - - Activation Pending
 
dscli> managecloudserver -action applypndgconfig
CMUC00607W managecloudserver: This is a disruptive operation that affects all the cloud configurations. Are you sure you want to apply pending configuration changes? [Y/N]: y
CMUC00601I managecloudserver: The cloud ts7700 was successfully updated to Active state on node 0.
CMUC00601I managecloudserver: The cloud ts7700 was successfully updated to Active state on node 1.
CMUC00601I managecloudserver: The cloud ibmcos was successfully updated to Active state on node 0.
CMUC00601I managecloudserver: The cloud ibmcos was successfully updated to Active state on node 1.
The first command (mkcloudserver) defines the cloud connection, but it does not activate the connection yet. (The message at command completion indicates this status.) With the second command (lscloudserver), we show how the DS8000 displays the intermediate state of the cloud connections. Finally, with the third command (managecloudserver), we activate the newly defined connection. You can add more than one cloud connection and activate them all with a single managecloudserver command.
 
Note: A managecloudserver -aplypndconfig command is disruptive to ongoing TCT operations. It removes and re-creates all defined cloud connections. Active TCT data transfers are terminated.
If you remove or modify one or more cloud connections in a multi-cloud configuration, the activation step with the managecloudserver command also is required.
 
Note: A major use case for multiple DS8000 cloud connections is the selection of TS7700 object policies. Using the TS7700 user interface, you can define policies for stored objects that specify where in the TS7700 grid objects are stored and how they are replicated.
To call such a policy, you must define a DS8000 cloud connection to the TS7700 grid and name it like the policy that you want to use. If you have more than one object policy, you define a DS8000 cloud connection for each of them.
6.4 Preparing the DS8000 as cloud proxy
With the TCT feature, the DS8000 acts a cloud proxy for the mainframe. This capability enables support for Amazon S3, IBM Cloud Object Storage, and TS7700 cloud interfaces for TCT. This way, z/OS and DFSMS do not have to connect to the cloud object storage directly, but use the DS8000 to relay the cloud requests. We describe required preparations for this function in the following sections.
6.4.1 Configuring the DS8000 for the REST API proxy function
This section describes the following topics:
Creating a proxy user
You need a DS8000 user ID that is used by DFSMS to authenticate on the DS8000 system by using the Representational State Transfer (REST) API interface. The REST API proxy service is automatically enabled when the DS8000 Code level is upgraded to R8.3 or later. No other tasks are required to enable the communication other than configuring the network and the user ID that is used by DFSMS. Example 6-16 shows how to create a local user ID in the DS8000 by using DSCLI.
Example 6-16 Creating a DS8000 user ID for DFSMShsm to connect
dscli> mkuser -pw REDxxxx -group monitor itsouser
 
Date/Time: December 13, 2017 8:56:41 AM MST IBM DSCLI Version: 7.8.31.118 DS: -
 
CMUC00133I mkuser: User itsouser successfully created.
When a user ID is created on the DS8000, the initial password that is used in the mkuser command is temporary and expired. You must change to the final password that will later be used by DFSMS, by logging on as that user and issuing a chuser command. Alternatively, this can also be done by your DS8000 security administrator. You can also use the DS8000 GUI to create the needed user ID and change the password.
After the user ID is created and the password is changed, you will be able to connect the DFSMS to the DS8000 by using the steps described in Chapter 7, “Configuring Data Facility Storage Management Subsystem for Transparent Cloud Tiering” on page 65.
 
Attention: The user ID that is created for the DFSMS to connect to the DS8000 follows the security rules that are defined in the Authentication Policy of the DS8000. Therefore, depending on your policy rules, this password can expire after a certain number of days. To avoid connectivity issues with TCT, change the password of this user ID both in the DS8000 and the DFSMShsm before the expiration date, or modify the expiration date policy to never expire.
Optionally, you can use LDAP to create the user ID that will be used by DFSMShsm to connect to the DS8000 REST API Proxy interface. The step-by-step instructions to configure LDAP on the DS8000 system can be found in LDAP Authentication for IBM DS8000 Systems: Updated for DS8000 Release 9.1, REDP-5460.
Exporting the security certificate
Section 4.6.3, “Certificates (if using SSL/TLS)” on page 44 describes how to secure the communication between the DS8000 system, DFSMS, and the cloud service provider. You can use encryption-based security with certificates that are exchanged during the authentication process, which can be External CA (signed by a third-party CA) or self-signed certificates.
Also, if you use Amazon S3 or IBM Cloud Object Storage cloud types, DS8000 uses a REST API Proxy interface to communicate with DFSMS. To do so, DFSMS connects to the DS8000 by using its HTTPS interface, so the certificate used by the DS8000 must be added to the IBM Resource Access Control Facility (RACF) for the DFSMShsm authentication to be successful.
By default, each DS8000 has factory-created communication certificates that are installed. They can be used to secure the communication between DFSMS and the DS8000 cloud proxy function.
To transfer the communication certificate to your z/OS host, first download it to your local workstation, for example, by using the openssl tool, as shown in Example 6-17. Any other tool that can download, extract, and dump certificates to PEM files can also be used.
Example 6-17 Downloading the DS8000 HMC self-signed certificate by using openssl
openssl x509 -in <(openssl s_client -connect <DS8000-HMC-IP>:8452 -prexit 2>/dev/null) -text -out certificate.pem
The procedure to upload the certificate from your workstation to the z/OS host is demonstrated in 7.2.1, “Uploading the certificate files to the z/OS host” on page 66.
If you must replace the DS8000 certificates, for example, because your organization requires the use of certificates that are signed by a designated CA, see Appendix C, “Replacing communication certificates in the IBM DS8900F” on page 145.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset