vania-janet/multiturn-rag-retrieval-data huggingface dataset:
High availability and disaster recovery 

IBM is announcing the deprecation of the IBM Watson® Language Translator service for IBM Cloud® in all regions. As of 10 June 2023, the Language Translator tile will be removed from the IBM Cloud Platform for new customers; only existing customers will be able to access the product. As of 10 June 2024, the service will reach its End of Support date. As of 10 December 2024, the service will be withdrawn entirely and will no longer be available to any customers.

IBM Watson® Language Translator is highly available within multiple IBM Cloud locations (for example, Dallas and Washington, DC). However, recovering from potential disasters that affect an entire location requires planning and preparation.

You are responsible for understanding your configuration, customization, and usage of the service. You are also responsible for being ready to re-create an instance of the service in a new location and to restore your data in any location. Fore more information, see [How IBM Cloud ensures high availability and disaster recovery](https://cloud.ibm.com/docs/overview?topic=overview-zero-downtime).



  High availability 

Language Translator supports high availability with no single point of failure. The service achieves high availability automatically and transparently by using the multi-zone region (MZR) feature provided by IBM Cloud.

IBM Cloud enables multiple zones that do not share a single point of failure within a single location. It also provides automatic load balancing across the zones within a region.





  Disaster recovery 

In the event of a catastrophic failure in a region, complete the following steps.



*  Create a new Language Translator service instance.
*  Adjust your application software to use the new service instance URL and credentials.
*  Create new custom models to replace any that you lost. Use the same forced glossaries and parallel corpora that you used to create your previous custom models. See [Customizing your model](https://cloud.ibm.com/docs/language-translator?topic=language-translator-customizingcustomizing) for more information about custom models.



*  To prepare for a quick recovery, store backup copies of your training files whenever you create a model. You can use the name and model_id fields of your custom models along with the filenames of your training files to keep a record of the files that you use for each model.



*  Adjust your application software to use the new custom models.
High availability and disaster recovery for KMIP for VMware 



 High availability within a region 

Within a single region:



* KMIP for VMware and Key Protect are highly available when correctly configured. If any one of the three zones in that region fail entirely, key management continues to be available to your VMware® workloads.
* KMIP for VMware and Hyper Protect Crypto Services (HPCS) are highly available if you deploy two or more crypto units for your HPCS instance. If you do so and any one of the three zones in that region fail entirely, key management continues to be available to your VMware workloads.







 Disaster recovery across regions 

When you are using VMware vSAN® encryption, each site is protected by its own key provider. If you are using vSAN encryption to protect workloads that you replicate between multiple sites, you must create separate KMIP for VMware instances in each site that is connected to separate Key Protect or HPCS instances in those sites. You must connect your VMware vCenter Server® in each site to the local KMIP for VMware instance as its key provider.

When you are using VMware vSphere® encryption, most VMware replication and migration techniques today (for example, cross-vCenter vMotion and vSphere replication) rely on having a common key manager between the two sites. This topology is not supported by KMIP for VMware. Instead, you must create a separate KMIP for VMware instance in each site that is connected to separate Key Protect or HPCS instances in those sites. You must connect your vCenter Server in each site to the local KMIP for VMware instance as its key provider, and then use a replication technology that supports the attachment and replication of decrypted disks.

Veeam Backup and Replication supports this replication technique. To implement this technique, see the [steps that you must take](https://helpcenter.veeam.com/docs/backup/vsphere/encrypted_vms_backup.html?ver=120) as indicated in the Veeam® documentation.

This technique does not support the replication of virtual machines with a vTPM device.





 Related links
Single campus MZRs contain three availability zones in different sections of the same building or within multiple buildings on a campus where the power, cooling, networking, and physical security dependencies overlap but are not identical between any two availability zones. This setup ensures a level of continuous availability and survivability of any one system outage, planned or unplanned.

SLAs are maintained because the infrastructure is set up in a concurrently maintainable fashion so that a single failure does not affect all three zones in the same campus. This setup is ideal for services that support local users as it reduces latency or to support disaster recovery workloads.

Zoom

![This diagram shows a geography that contains a single campus MZR](https://cloud.ibm.com/docs-content/v1/content/adcecdbe4e86955f88aac7f3c1e7ec3ff44992ef/overview/images/single-campus-mzr.svg)

Figure 2. Single campus MZR

The following table lists the single campus MZRs that are available in IBM Cloud and the region, zone, and data center codes for each one.



Table 2. Single campus MZRs

 Location Region Zone Data center 

 Osaka jp-osa jp-osa-1 <br>jp-osa-2 <br>jp-osa-3 OSA21 <br>OSA22 <br>OSA23 



OSA2X (formerly known as OSA02) is the physical data center.







 Data centers 

In addition to selecting a region for your resource, you can select from a list of the IBM Cloud data centers, depending on the type of resource you're working with.

Data centers host the power, cooling, compute, network, and storage resources used for services and apps. They don't provide isolation from multizones in a location.

Data centers are based on a POD architecture where each data center can have more than one POD, depending on the on-demand build out. Each POD consists of racks, servers, networks, and storage, along with backup power generators. Placing application servers across PODs improves the availability.

Zoom

!
And, remote secondary sites far from the primary site might require asynchronous techniques to be evaluated in your design.

For more information, see [How IBM Cloud ensures high availability and disaster recovery](https://cloud.ibm.com/docs/overview?topic=overview-zero-downtime).





 Plan and design for the “worst conditions” 

When designing your resiliency solution, the key is in the word “resiliency". Your solution has to work in the worst possible conditions and provide enough performance, not only to achieve your recovery objectives (RTO and RPO), but to also be able to sustain and run production from an alternative site for a long period. Your design should not only consider a single plan, but many possible alternatives to best adapt and be resilient, for example being able to work in a degraded or impacted ecosystem.

Of course, costs might be prohibitive in this approach. However, you should have a clear view of what the minimal acceptable conditions are, and what other aspects you might eliminate when a solution is cost prohibitive while understanding what the impact would be. In other words, accept residual risks knowing the consequences.

Your design should not be limited to the IT only. Your IT is dependent on several other factors that can be impacted as well. The following is a nonexhaustive list:



* Key personnel availability
* External networks services
* Dependencies on critical providers
* Road conditions (when planning physical transfers of personnel, backup, and more)
* DR resources availability when required









 Planning your application's recovery strategy objectives 

You should define the recovery objectives for your application and the disaster recovery metric thresholds for your application. In the following example, RTO and RPO requirements are homogeneous. This helps in the design and implementation of the application's DR strategy.



Table 1. Example RTO and RPO requirements

 Recovery classes RTO RPO 

 Continuous availability <= 1 hour <= 1 hour 
 Advanced recovery > 1 hour - <= 72 hours <2 hours - <72 hours 
 Standard recovery > 72 Hr Last backup 
 No recovery n/a n/a
To discover the earliest recovery point through the CLI, use the [cdb postgresql earliest-pitr-timestamp](https://cloud.ibm.com/docs/databases-cli-plugin?topic=databases-cli-plugin-cdb-referencepostgresql-earliest-pitr-timestamp) command.

ibmcloud cdb postgresql earliest-pitr-timestamp <deployment name or CRN>

To discover the earliest recovery point through the API, use the [/deployments/{id}/point_in_time_recovery_data](https://cloud.ibm.com/apidocs/cloud-databases-apiget-earliest-point-in-time-recovery-timestamp) endpoint to find the earliest PITR time.

{
"point_in_time_recovery_data": {
"earliest_point_in_time_recovery_time": "2019-09-09T23:16:00Z"
}
}



 Recovery 

Backups are restored to a new deployment. After the new deployment finishes provisioning, your data in the backup file is restored into the new deployment. Backups are also restorable across accounts, but only by using the API and only if the user that is running the restore has access to both the source and destination accounts.

By default the new deployment is auto-sized to the same disk and memory allocation as the source deployment at the time of the backup that you are restoring from. Especially in the case of PITR that might not be the current size of your deployment. If you need to adjust the resources that are allocated to the new deployment, use the optional fields in the UI, CLI, or API to resize the new deployment. Be sure to allocate enough for your data and workload, if the deployment is not given enough resources the restore fails.

While storage and memory are restored to the same as the source deployment, specific instance configurations are not automatically set for the new instance. In this case, rerunning the configuration after a restore might be needed.
AltaVault exposes a CIFS/SMB or Network File System (NFS) mount point on the front end and securely connects to the IBM Cloud Object Storage interface on the back end. You can then mount or point to the mount points and copy data into and or recovering/restoring environments from the cloud securely.



 Deploying AltaVault in a Disaster Recovery Configuration 

Follow these steps to deploy AltaVault as a disaster recovery solution with IBM Cloud Object Storage.



 Before you get started 

Verify that the following prerequisites are met before you proceed:



* Obtain a copy of AltaVault Virtual Appliance and make sure that it is on the utility server. It is a single file with an OVA file extension. Contact your NetApp representative for the appliance, or download a 90-day trial version from the [NetApp AltaVault website ![External link icon](https://cloud.ibm.com/docs-content/v1/content/icons/launch-glyph.svg)](https://mysupport.netapp.com/site/products/all/details/altavault/docsandkb-tab).
* Have an existing on-premises vSphere ESXi 5.5 environment with the minimum CPU, memory, and disk space requirements available for the AltaVault appliance. If you use the trial version, these are the resource requirements: four virtual CPUs (vCPUs), 24 GB of memory, and up to 8 TB of disk space.
* Have two 10 Gbps network interface controllers (NICs) available within the vSphere environment. One NIC is used for data access, and the other is used for data replication to IBM Cloud Object Storage.
* Have two portable private networks that correspond to the two NICs that are defined within the vSphere environment. The replication network cannot be assigned to the same network as the data access network, which can create a routing loop.
* Have IBM Cloud Object Storage credentials. These credentials include an IBM Cloud username, IBM Cloud Object Storage username, and the API key that is associated with the IBM Cloud username.
Queue Manager <br><br> * Backup queue manager configuration daily<br> * Recover required infrastructure<br> * Provision new infrastructure in a backup availability zone, if recovery is not possible<br> * Redeploy queue managers to new availability zone<br> * Restore queue manager configuration from previous backup<br><br><br> <br><br> * [Register for disaster recovery notifications](https://cloud.ibm.com/docs/services/mqcloud?topic=mqcloud-mqoc_dr_notifications)<br> * Reset channel sequence numbers so that channels will successfully communicate<br><br><br> 







 Applications and data 

You are completely responsible for the applications and data that you use with IBM MQ on IBM Cloud . However, IBM provides various tools to help you set up, manage, secure, integrate and optimize your apps as described in the following table.



Table 7. Applications and data
The rows are read from left to right. The resource area of comparing responsibilities is in the first column, with the responsibilities of IBM in the second column and your responsibilities in the third column.

 Resource How IBM helps What you can do 

 Applications <br><br> * Provide default queue manager configuration to allow applications to connect securely<br> * Provide sample applications such as [MQ JMS client](https://developer.ibm.com/messaging/learn-mq/mq-tutorials/develop-mq-jms/)<br> * Generate an API key that is used to access queue managers<br> * Provide application connection configuration in JSON CCDT format<br><br><br> <br><br> * Maintain responsibility for your apps, data, and their complete lifecycle<br> * Configure applications for [high availability](https://cloud.ibm.com/docs/services/mqcloud?topic=mqoc_ha)<br> * Manage open connections to ensure the maximum queue manager limit is not exceeded<br><br><br>
In the subject for your issue, include Request Veeam Self Service Portal for my Organization and include your Organization ID and virtual data center name in your issue description.





 Limitations for Veeam Availability Suite 



* For the Veeam application aware image processing and guest file system indexing options to work for Windows® VMs, the most recent VMware® Tools must be installed on the VMs. Linux® VMs do not support application awareness or guest file system indexing.
* If you are using application aware image processing for MS SQL or Oracle DB backups, the options application aware and Item restore are not supported. The restore operation needs to complete a full VM restore, which requires a downtime window for any consumers of the database.







 Licenses and fees for Veeam Availability Suite 

Veeam usage incurs on-demand charges. For more information, see [VMware Shared pricing](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-shared_pricing).





 Backup data storage and encryption 

For more information about how Veeam Availability Suite stores backups, see [How is your data stored and encrypted in the VMware Shared Veeam Availability Suite service](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-data-security-mng-datadata-security-data-veeamshared).







 Veeam Cloud Connect Replication 

Veeam Cloud Connect Replication provides seamless replication of your workloads from on-premises to IBM Cloud®. Use Veeam Cloud Connect as disaster recovery for failover during on-premises outages or to permanently move workloads directly to IBM Cloud.

For VMware Shared V4.2 and later, VMware Shared virtual data centers provide Veeam Backup and Replication 11 for the Veeam Cloud Connect Replication ready-to-use service. For more information about compatibility requirements between Veeam service providers and tenants, see [Product versions in Veeam Cloud Connect infrastructure](https://helpcenter.veeam.com/archive/backup/110/cloud/cloud_connect_versions.html).
You are responsible for the recovery of the workloads that run IBM Cloud Event Notifications and your application and application data.



Table 5. Responsibilities for disaster recovery

 Task IBM Responsibilities Your Responsibilities 

 Availability <br><br> * Provide high availability capabilities, such as IBM-owned infrastructure in multizone regions, to meet local access, and low latency requirements for each supported region.<br> * Run IBM Cloud Event Notifications deployments with three replicas in the same region for high availability. <br> Continuously monitor IBM Cloud Event Notifications infrastructure to ensure the reliability and availability of the service environment by site reliability engineers. <br> Maintain service availability across [worldwide regions](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-ac-regions-endpoints) so that customers can deploy projects across zones and regions for higher DR tolerance.<br><br><br> <br><br> * Use the list of [available regions](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-ac-regions-endpointsac-regions) to plan for and create new instances of the service to meet performance and availability requirements exceeding the default that is provided by IBM.<br> * Set up more IBM Cloud Event Notifications instances across zones and regions to increase disaster recovery tolerance that exceeds the default that is provided by IBM.<br><br><br>
High availability and disaster recovery 

IBM Cloud® Transit Gateway is highly available within any IBM Cloud location (for example, Dallas or Washington, DC). However, recovering from disasters that affect an entire location requires planning and preparation.

You are responsible for understanding your configuration, customization, and usage of the service. You are also responsible for being ready to re-create an instance of the service in a new location and restore your data in a new location.



 High availability 

IBM Cloud supports high availability with no single point of failure. The service achieves high availability automatically and transparently by means of the multi-zone region ([MZR](https://cloud.ibm.com/docs/overview?topic=overview-locationsmzr-table)) feature provided by IBM Cloud.

When you create a transit gateway instance in a particular region, the system automatically enables multiple zones which do not share a single point of failure.

Transit gateway GRE connections require the gateway owner to configure HA to meet their specific needs. When configuring a GRE connection on a transit gateway, you must specify the availability zone. For a more robust solution, configure multiple connections using different availability zones.

Transit gateway GRE connections require the gateway owner to specifically configure HA for their needs. A GRE connection is a point to point connection, has no built in redundancy, and is a single point of failure. When configuring a GRE connection on a transit gateway, you must specify the availability zone. For a robust HA solution, configure multiple GRE connections using different availability zones.





 Disaster recovery 

In the event of a catastrophic failure impacting an entire region, the transit gateway service management plane, which is global, continues to be available. Transit gateway instances are restored when the failing region recovers. However, in some rare cases, you may need to recreate specific instances of your transit gateways, as well as their connections.

Your disaster recovery plan should include knowing, preserving, and being prepared to restore all data that is maintained on IBM Cloud. This includes data about all deployed transit gateways and their connections.



 Backing up transit gateways for disaster recovery
Understanding high availability and disaster recovery for IBM Cloud Partner Center 

IBM Cloud® provides a service for hosting Partner Center. Partner Center follows the practices that are described in [How IBM Cloud ensures high availability and disaster recovery](https://cloud.ibm.com/docs/overview?topic=overview-zero-downtime).

This service is hosted in the Dallas (us-south), Frankfurt (eu-de), and Sydney (au-syd) regions, which are collectively served by a global endpoint. Partner Center data is stored in a US cross-regional DB2 on Cloud high availability instance. If the service in one region fails, Partner Center is still operational as traffic is routed automatically to the other available regions. When the service in the failed region recovers, it will start receiving traffic again without any action required from users.
Data migration tool <br><br> * You can migrate your data from anywhere to IBM Cloud classic infrastructure or VPC.<br> * The tool uses rsync to copy data from the source to the target machine.<br> * The script is available in this [public GitHub repository](https://github.com/IBM-Cloud/vpc-migration-tools/tree/main/data-migration).<br> * For a detailed step-by-step guide, see [Migrating data from IBM Cloud classic infrastructure to VPC](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-data-migration-classic-to-vpc).<br><br><br> 







 Custom image templates 

By using a custom image template, you can capture a classic bare metal image to replicate its configuration to order more classic bare metal servers with the same configurations, and you can deploy as many as needed.

With this type of classic bare metal to classic bare metal migration in IBM Cloud classic infrastructure, you need to review the following considerations and limitations:



* Only compute resources and secondary volumes are migrated
* Not meant for backup
* Can be used for disaster recovery



Classic bare metal to classic bare metal migration is disruptive to your workloads, so be sure to plan accordingly.

For more information, see [About bare metal custom image templates](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-getting-started-bm-custom-image-templates).