vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information about file storage IOPS tier and Custom profiles, see [File storage profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles).
6. Specify the size for the file share. You can later [increase this size](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-expand-capacity). The maximum capacity of the share depends on the file share profile.
7. Encryption at rest. By default, all file shares are encrypted by IBM-managed keys. You can also choose to encrypt your shares with your own keys. If you want to use your own keys, select one of the [key management services](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-aboutkms-for-byok).



Table 3. Values for customer-managed encryption for file shares.

 Field Value 

 Encryption To use customer-managed encryption, select either Key Protect or Hyper Protect Crypto Services. The key management service (KMS) instance includes the root key that is imported to or created in that KMS instance. 
 Encryption service instance If you provisioned multiple KMS instances in your account, select the one that includes the root key that you want to use for customer-managed encryption. 
 Key name Select the root key within the KMS instance that you want to use for encrypting the share. 
 Key ID Shows the key ID that is associated with the data encryption key that you selected. 



8. When all the required information is entered, click Create file share. You return to the File Storage for VPC page, where a message indicates that the file share is provisioning. When the transaction completes, the share status changes to Active.







 Create a mount target in the UI 

You can create several mount targets for an existing file share if the share is to be used by resources in multiple VPCs. You can create one mount target per VPC per file share.



1.
KMIP for VMware design 

KMIP™ for VMware® provides a key management service compatible with VMware vSAN™ encryption and VMware vSphere® encryption, by using [IBM Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-getting-started-tutorial) or [IBM Cloud Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-startedget-started) to provide root key and data key storage. Key Protect and Hyper Protect Crypto Services function as the key management service in this solution.



 Storage encryption options 

KMIP for VMware is compatible with both VMware vSAN encryption and vSphere encryption. Both of these solutions are implemented in the hypervisor layer but provide slightly different functions. Evaluate their functions according to your requirements.



 VMware vSAN encryption 

VMware vSAN encryption is only applicable to vSAN datastores. With this solution, VMware vCenter and your VMware ESXi™ hosts connect to a key management server such as KMIP for VMware to get encryption keys. These keys are used to protect individual disk drives used for your vSAN datastore, including both cache and capacity disks. vSAN encryption is implemented in a way that preserves the benefits of vSAN deduplication and compression, if you choose this option when you order a new instance or add a cluster.

Because vSAN encryption operates at the datastore level, its primary goal is to prevent data exposure if loss of physical disk drives occurs. Also, vSAN encryption is fully compatible with all virtual machine (VM) backup and replication technologies, such as vSphere replication, cross-vCenter vMotion, VMware HCX™, Zerto, and Veeam®.



 VMware vSAN encryption notes 



* For vSphere versions older than 7.0u1a, vSAN encryption cannot encrypt the host to host vSAN replication communications within your cluster. Beginning with vSphere 7.0u1a, you can optionally enable data-in-transit encryption for each vSAN cluster.
Connecting with third-party tools 

You can connect third-party command-line interfaces, applications, and tools to your Db2 on Cloud database.



 Data integration 



 Segment 

You can integrate Segment with a Db2 on Cloud database. Segment is a single platform that collects, stores, and routes your user data to hundreds of tools.

[Segment](https://segment.com/docs/destinations/db2/)







 Data visualization & BI 



 Looker 

You can connect Looker to a Db2 on Cloud database. Looker is a business intelligence app and big data analytics platform with which you can explore, analyze, and share real-time business analytics.

[Connecting Looker](https://docs.looker.com/setup-and-management/connecting-to-db)





 Tableau 

These instructions explain how to connect Tableau to a Db2 on Cloud database and apply to Tableau Desktop , but you can use similar steps for other Tableau tools.



 Prerequisites 

Before attempting to connect to your Db2 on Cloud database, verify that you have the [prerequisites](https://cloud.ibm.com/docs/Db2onCloud/connecting?topic=Db2onCloud-connect_ovprereqs).





 Procedure 



1. In Tableau Desktop, open the window or page in your tool that is used to define a database connection.
2. From the start page, click Connect to data.
3. From the Data Sources list, select the data source or driver to use for your database connection. In the On a server section of the list, select IBM Db2.
4. From the IBM DB2 Connection window, enter the connection information by using the definitions in Table 1.
5. Click Connect to establish the connection. Tableau offers several options for connecting to your data. To make full use of your Db2 on Cloud database, choose the Connect Live option.





Table 1. Fields in Tableau for connection information

 Tableau field Db2 connections information field 

 Step 1: Enter a server name Host name 
 Step 2: Port Port number
* Flavor: The flavor defines the amount of virtual CPU, memory, and disk space that is set up in each worker node and made available to the containers. Available bare metal and virtual machines types vary by the zone in which you deploy the cluster. For more information, see [Planning your worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes).



: 

* Worker nodes per zone: For high availability, at least 3 worker nodes per zone are recommended.



: 

* Encrypt local disk: By default, [worker nodes feature AES 256-bit disk encryption](https://cloud.ibm.com/docs/containers?topic=containers-securityworkernodes). You can choose to turn off disk encryption when you create the cluster.



Master service endpoint
: Service endpoints provide communication to the master. You can choose to configure your cluster with a private, public, or both a public and a private cloud service endpoint. For more information about what setup is required to run internet-facing apps, or to keep your cluster private, see [Planning your cluster network setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_vpc_basicsvpc-pgw).

Ingress secrets management
: [IBM Cloud Secrets Manager](https://cloud.ibm.com/docs/containers?topic=containers-secrets-mgr) centrally manages Ingress subdomain certificates and other secrets in your cluster. You can choose to register a Secrets Manager instance to your cluster during the cluster create process. You can also specify a secret group that you can use to control access to the secrets in your cluster. Both of these options can be configured or changed after you have created the cluster.

Encryption
: Data encryption with a key management service (KMS) encrypts secrets and other sensitive information in your cluster. You can add an existing KMS instance to your cluster during the cluster create process.

Cluster details
On the New block storage volume page, update the fields in the Encryption section. See Table 1 for more information. When your changes are complete, click Attach.





Table 1. Values for specifying customer-managed encryption of volumes

 Field Value 

 Encryption Provider managed is the default encryption mode. To use customer-managed encryption, select a key management service from the drop-down list. The key management service instance must include the customer root key that you want to use for customer-managed encryption. 
 Encryption service instance If you have multiple key management service instances that are provisioned in your account, select the one that includes the customer root key that you want to use for customer-managed encryption. 
 Key name Select the root key within the key management service instance that you want to use for encrypting the volume. 
 Key ID Displays the key ID that is associated with the root key that you selected. 







 Provisioning instances with customer-managed encrypted volumes from the CLI 

To provision instances with customer-managed encryption volumes from the CLI, you need to create JSON files to define your boot and data volumes, and then specify the ibmcloud is instance-create command to reference the JSON files.



 Step 1 - Obtain service instance and root key information 

Obtain the ID of the key management service instance and the CRN of the root key in that instance. The following example is specific to Key Protect, but HPCS is similar.



1. If you need to install the Key Protect CLI plug-in, run the following command:

ibmcloud plugin install key-protect -r 'IBM Cloud'
2. List the Key Protect service instances for your account:

ibmcloud resource service-instances

For example:

Retrieving all instances of all services in resource group Default and all locations
under account MyCompany as myuserid@mycompany.com...
OK
Name Location State Type
Key Protect-17 us-south active service_instance
Key Protect-60 us-south active service_instance
3. Retrieve the instance ID for the Key Protect service instance where your customer root keys are stored. Key Protect-17 is the name of the Key Protect service instance.
* Flavor: The flavor defines the amount of virtual CPU, memory, and disk space that is set up in each worker node and made available to the containers. Available bare metal and virtual machines types vary by the zone in which you deploy the cluster. For more information, see [Planning your worker node setup](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodes).



: 

* Worker nodes per zone: For high availability, at least 3 worker nodes per zone are recommended.



: 

* Encrypt local disk: By default, [worker nodes feature AES 256-bit disk encryption](https://cloud.ibm.com/docs/openshift?topic=openshift-securityworkernodes). You can choose to turn off disk encryption when you create the cluster.



Master service endpoint
: Service endpoints provide communication to the master. You can choose to configure your cluster with a public only or both a public and a private cloud service endpoint. For more information about what setup is required to run internet-facing apps, or to keep your cluster private, see [Planning your cluster network setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_vpc_basicsvpc-pgw). You can not change the cloud service endpoints after you create the cluster.

Ingress secrets management
: [IBM Cloud Secrets Manager](https://cloud.ibm.com/docs/containers?topic=containers-secrets-mgr) centrally manages Ingress subdomain certificates and other secrets in your cluster. You can choose to register a Secrets Manager instance to your cluster during the cluster create process. You can also specify a secret group that you can use to control access to the secrets in your cluster. Both of these options can be configured or changed after you have created the cluster.

Encryption
: Data encryption with a key management service (KMS) encrypts secrets and other sensitive information in your cluster. You can add an existing KMS instance to your cluster during the cluster create process.

Cluster details
Select the right profile for your workload. The profile that you select determines the input/output performance of a file share. The dp2 profile provides the most flexibility. For more information about file storage IOPS tier and Custom profiles, see [File storage profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles).
6. Specify the size for the file share. You can later [increase this size](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-expand-capacity). The maximum capacity of the share depends on the file share profile.
7. Encryption at rest. By default, all file shares are encrypted by IBM-managed keys. You can also choose to encrypt your shares with your own keys. If you want to use your own keys, select one of the [key management services](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-aboutkms-for-byok).



Table 3. Values for customer-managed encryption for file shares.

 Field Value 

 Encryption To use customer-managed encryption, select either Key Protect or Hyper Protect Crypto Services. The key management service (KMS) instance includes the root key that is imported to or created in that KMS instance. 
 Encryption service instance If you provisioned multiple KMS instances in your account, select the one that includes the root key that you want to use for customer-managed encryption. 
 Key name Select the root key within the KMS instance that you want to use for encrypting the share. 
 Key ID Shows the key ID that is associated with the data encryption key that you selected. 



8. When all the required information is entered, click Create file share. You return to the File Storage for VPC page, where a message indicates that the file share is provisioning. When the transaction completes, the share status changes to Active.







 Create a mount target in the UI 

You can create several mount targets for an existing file share if the share is to be used by resources in multiple VPCs.
If you configured your Event Streams instance in a multi-zone region, a regional disaster is unlikely. However, we recommend that customers plan for such circumstances. If due to such an event, a customer's instance is no longer available (and a remote DR instance was not already set up), the customer should consider configuring a new instance in a new region.



Table 4. Responsibilities for disaster recovery

 Task IBM Responsibilities Your Responsibilities 

 Disaster recovery Customer is responsible for maintaining and executing a disaster recovery plan if the service is lost. The plan might include provisioning a new cluster in a new region if a disaster occurs and restoring any configuration or data to that cluster, or, pre-provisioning a cluster in another region and using the Event Streams [Mirroring feature](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-event_streams_responsibilitiesmirroring_responsibilities). 
 Mirroring Customer can use the Event Streams [Mirroring feature](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-event_streams_responsibilitiesmirroring_responsibilities), or choose to manage their own mirroring solution. 
 Message payload data backup The customer is also responsible for the backup of message payload data. Although this data is replicated across multiple Kafka brokers within a cluster, which protects against most failures, this replication does not cover a location-wide failure. 
 Topic name and data backup It is recommended good practice that a customer stores their topic names and configuration data for those topics in the same repository as their application source code. This way the topics can be restored into a new cluster if a disaster occurs. 
 Schema Registry It is recommended good practice that a customer stores their schema in the same repository as their application source code. This way the schema can be restored into a new cluster if a disaster occurs. 







 App orchestration 



Table 5. Responsibilities for app orchestration

 Task IBM Responsibilities Your Responsibilities 

 Integrate with select third-party partnership technologies Event Streams provides integrations with select third-party partnership technologies, such as IBM Cloud Activity Tracker with LogDNA. 
 Provide service binding to other IBM services Event Streams provides the capability for service binding to other IBM services.
[Object Storage architecture](https://cloud.ibm.com/docs-content/v1/content/adcecdbe4e86955f88aac7f3c1e7ec3ff44992ef/overview/images/BCDR-Architecture-Diagram-image10.svg)

Figure 9. An architecture diagram showing a Object Storage architecture

In this scenario, the data is always available in both MZRs through cross-regional buckets. Therefore, the only change that is needed is to update the DNS routing to point to the backup MZR.







 Advanced recovery profile 

The [advanced recovery class](https://cloud.ibm.com/docs/overview?topic=overview-understanding-drplan-objectives) requires that the platform is available in less than an hour in the event of a disaster where the primary MZR becomes unavailable. To achieve this with IBM Cloud Code Engine, it is necessary to have a fully configured instance of the IBM Cloud Code Engine project up and running in hot standby mode in the backup MZR. This includes:

Platform
: All applications deployed with the same version as deployed in primary MZR

Application
: All applications deployed with the same version as deployed in primary MZR
: Dependent services provisioned and necessary data replication strategy in place (bidirectional, read-only replica, backup, and restore, and so on)
: Service credentials and service bindings

When planning for an advanced recovery profile application, more options are available to application owners in terms of whether preprovisioning of resources is required. There is a tradeoff between the cost of maintaining preprovisioned compute, such as IBM Cloud Code Engine or Kubernetes Service, capacity and the risk of it taking longer than the RTO to provision or scale up the capacity needed.

Cloud capacity is not infinite. It is important to consider the possibility of capacity constraints in the backup MZR in the event the entire primary MZR is lost.

Recovery times for databases that use backup and restore depends on the size of the backup. Application owners need to take this into account when determining their RTO requirements.



 Advanced recovery profile application - MongoDB 

Zoom

!
Shared responsibilities for using IBM Cloud products 

In IBM Cloud®, as is the case for other cloud service providers, the responsibilities for managing the lifecycle of, operating, and securing products are shared between IBM® and the customer.

The responsibility of completing the following types of tasks on various products can be exclusive to IBM, the customer, or shared between the two. The tasks for each type of product are grouped in the following categories:



* Incident and operations management: Includes tasks such as monitoring, event management, high availability, problem determination, recovery, and full state backup and recovery.
* Change management: Includes tasks such as deployment, configuration, upgrades, patching, configuration changes, and deletion.
* Identity and access management: Includes tasks such as authentication, authorization, access control policies, and approving, granting, and revoking access.
* Security and regulation compliance: Includes tasks such as security controls implementation and compliance certification.
* Disaster recovery: Includes tasks such as providing dependencies on disaster recovery sites, provision disaster recovery environments, data and configuration backup, replicating data and configuration to the disaster recovery environment, and failover on disaster events.



When you're reviewing the following sections, the tables list resources for each category and who manages them. The following list describes what constitutes each type of resource in IBM Cloud.

Data
: Customer-owned content that includes all data that is managed and controlled by the customer. Examples include information that is stored into volumes, files, and databases hosted on IBM Cloud resources and data processed, stored, and logged by the client applications hosted on IBM Cloud. It doesn't include client metadata, the information that is used by IBM to provide services to the customer and support and operate the client account, services, and resources that are always considered to be shared responsibility between client and IBM.

Applications
: Customer-owned software components, such as executables, web applications, middleware, frameworks, libraries, and other software packages that the client developed or acquired by third parties and deployed in IBM Cloud.

Service instance
: An entity that consists of resources that are reserved for a particular service.

Operating systems
The Client is also responsible for monitoring for EOL announcements and moving off EOL versions before the end of support date that is announced by Cloud Databases also described in the version lifecycle policy. 







 Security and regulation compliance 



Table 3. Responsibilities for security and regulation compliance

 Task IBM Responsibilities Your Responsibilities 

 Encryption Cloud Databases is responsible for the encryption of data on disk, in motion, and in backups. The Client is responsible for choosing and managing appropriate additional security features. If using Key Protect and Bring Your Own Key (BYOK), the client is responsible for managing Key Protect authorizations and keys. 
 Security Cloud Databases is responsible for ensuring the security of data on disk and data in motion within our infrastructure. The Client is responsible for managing IBM Cloud passwords and database passwords, and keeping passwords secure. The Client is also responsible for configuring appropriate network security or isolation (for example, IP allowlists or private endpoints). 
 Compliance Cloud Databases is responsible for ensuring adherence, auditing, and certification of compliances listed at the [IBM Cloud compliance page](https://www.ibm.com/cloud/compliance/industry). The Client is responsible for the storing, processing, and transmission of their data. More information on these specific responsibilities can be found in each of the Cloud Databases offerings' specific Security Compliance documentation. 







 Disaster recovery 



Table 4. Responsibilities for disaster recovery

 Task IBM Responsibilities Your Responsibilities 

 Backups and restore Cloud Databases is responsible for automatic daily backups, as well as monitoring the state of client backups. The Client is responsible for restoration, timeliness, validity of backups, and alerting of failed backups via [IBM Cloud® Activity Tracker](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-activity-tracker.) More information can be found in the [Backup and Restore documentation](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-dashboard-backups).