vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The IBM Cloud Framework for Financial Services only requires you to meet the RPO, RTO, and MTD goals that you define (see previous best practice). However, to be best in class, you should strive to be highly available.

Purpose & value: Consumers will be relying on your service for critical operations and have the potential to be deeply impacted by any downtime. To avoid downtime, you should implement redundancy to eliminate single points of failure. It is strongly recommended that you deploy your application to:



* Multiple availability zones within any multizone region you're using. This enables you to ensure if one data center in a region goes down, that your application can continue to function.
* Multiple multizone regions with failover between them. If something catastrophic happens that impacts an entire region, you can failover to another so consumers can still use your service.



In addition, it is recommended that you:



* Implement a solution for autoscaling your deployment before capacity is exceeded.
* Follow best practices for HA as defined by the specific managed services that you use. For example, Direct Link, Hyper Protect Crypto Services, etc.



Implementation guidance:



* [VPC reference architecture](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-high-availability)
* [Satellite reference architecture](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-satellite-architecture-high-availability)



Most Relevant Controls:



Table 13. Related controls for high-availability

 Family Control 

 Contingency Planning (CP) [CP-2 Contingency Plan](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-cp-2) <br>[CP-7 Alternate Processing Site](https://cloud.ibm.com/docs/framework-financial-services-controls?topic=framework-financial-services-controls-cp-7)
The failover might be implemented within the application logic itself, or by using a load balancer, or by using some other means.

A simple test of whether a failover is required would be to use the main database endpoint as a "heartbeat". For example, a simple GET request that is sent to the main database endpoint normally returns [details about the database](https://cloud.ibm.com/apidocs/cloudantgetdatabaseinformation). If no response is received, it might indicate that a failover is necessary.





 Other configurations 

You might consider other hybrid approaches for your configuration.

For example, in a "Write-Primary, Read-Replica" configuration, all writes go to one database, but the read load is distributed among the replicas.







 Step 7. Next steps 



* Consider monitoring the [replications](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-advanced-replicationadvanced-replication) between the databases. Use the data to determine whether your configuration might be optimized further.
* Consider how your design documents and indexes are deployed and updated. You might find it more efficient to automate these tasks.







 Failing over between IBM Cloudant regions 

Typically, the process of managing a failover between regions or datacenters is handled higher up within your application stack, for example by configuring application server failover changes, or by balancing the load.

IBM Cloudant doesn't provide a facility for you to manage explicitly any failover or reroute requests between regions. This constraint is partly for technical reasons, and partly because the conditions under when it might happen tend to be application-specific. For example, you might want to force a failover in response to a custom performance metric.

However, if you decide that you need the ability to manage failover, consider the following possible options:



* Put your own [HTTP proxy in front of IBM Cloudant](https://github.com/greenmangaming/cloudant-nginx). Configure your application to talk to the proxy rather than the IBM Cloudant instance.
For more information, see [Creating and managing resource groups](https://cloud.ibm.com/docs/account?topic=account-rgs).
* Under Tags (Optional), add tags to organize your resources. If your tags are billing related, consider writing tags as key: value pairs to help group-related tags, such as costctr:124. For more information about tags, see [Working with tags](https://cloud.ibm.com/docs/account?topic=account-tag).
* Under Access management tags (Optional), add tags to resources to help organize access control relationships in the project:analysis format. For more information, see [Controlling access to resources by using tags](https://cloud.ibm.com/docs/account?topic=account-access-tags-tutorial).
* Under Number of crypto units, select the number of

crypto unitsthat meets your performance needs. At least two crypto units are to be enabled for high availability. These crypto units are distributed among different supported availability zones in the selected region.
* Under Number of cross-region failover crypto units, select whether to enable failover crypto units that are used for an automatic restoration in case of a regional disaster.

If you enable failover crypto units, set the number of failover crypto units equal to or less than the number of operational crypto units. However, to meet high availability, you need to specify at least two failover crypto units. Each failover crypto unit [is also charged](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-faq-pricing). Failover crypto units are now available in Dallas (us-south) and Washington DC (us-east), so if you create your instance in other regions such as Frankfurt (eu-de), this option is automatically disabled.

After you provision the service instance, you can still [enable or add failover crypto units](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-enable-add-failover).
[Set up the PKCS #11 configuration file](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-set-up-pkcs-apistep3-setup-configuration-file).

Added: Enabling cross-region recovery with failover crypto units
: Failover crypto units back up the operational crypto units and keystores in another region. When a regional disaster occurs, you can use failover crypto units instead to reduce the downtime and data loss. Failover crypto units [charge extra fees](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-faq-pricing) and this option is now available only in regions of us-south and us-east. For more information, see [Enabling or adding failover crypto units](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-enable-add-failover) and [Cross-region disaster recovery](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-ha-drcross-region-disaster-recovery).

Added: Hyper Protect Crypto Services expands into the London region
: You can now create Hyper Protect Crypto Services instances in the London (eu-gb) region where the infrastructure is based on IBM Cloud Virtual Private Cloud (VPC). For more information, see [Regions and locations](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-regions).





 30 April 2021 

Added: Rotating your master key by using smart cards and the Management Utilities
* Applications behind a load balancer that uses an internal routable IP can require routing changes if they cannot be moved together or it is not desirable to do so. For example, involving too many applications in one swing can be perceived too much of a risk.
* VMware admins, network admins (including customers and WAN vendors), and application owners need to be involved, even if there's no planned impact on a particular system or network equipment.







 Related links 



* [Glossary of HCX components and terms](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcxclient-components)
* [Preparing the installation environment](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcxclient-planning-prep-install)
* [HCX Client deployment](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcxclient-vcs-client-deployment)
* [HCX on-premises Service Mesh](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcxclient-vcs-mesh-deployment)
* [HCX troubleshooting](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-hcxclient-troubleshooting)
Find the row for the identity this orderer used and click the dot dot dot
3. On the enroll wizard select the TLS CA in the CA drop down (its important to select the TLS CA)
4. Type the enroll secret that was used earlier when creating the orderer
5. Follow any other directions in the enroll wizard and click submit
6. If you browse back to the nodes page and select the Orderer Cluster tile the TLS identity error should be gone









 Step four: Create a channel 

In this tutorial, we will presume that users will not be attempting to edit any of the advanced options available when creating a channel. For information about editing advanced options both before and after a channel has been created, as well as more information about standard options, see [Advanced channel deployment and management](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-governibp-console-govern). Note that to use the new 2.x lifecycle, you might need to use the advanced Capabilities option to increase the application capability to 2_0. For more information, check out [Capabilities](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-governibp-console-govern-capabilities).

Although the members of a network are usually related business entities that want to transact with each other, there might be instances when subsets of the members want to transact without the knowledge of the others. This is possible by creating a channel on which these transactions will take place. Channels replicate the structure of a blockchain network in that they contain members, peers, an ordering service, a ledger, policies, and smart contracts. But by restricting the membership, and even the knowledge of the channel, to particular subsets of the network membership, channels ensure that network members can leverage the overall structure of the network while maintaining privacy, where needed.

To join a peer from Org1 to a channel, Org1 must first be added to the consortium. After which, it can create a channel and join a peer to it.
For example, you might want to force a failover in response to a custom performance metric.

However, if you decide that you need the ability to manage failover, consider the following possible options:



* Put your own [HTTP proxy in front of IBM Cloudant](https://github.com/greenmangaming/cloudant-nginx). Configure your application to talk to the proxy rather than the IBM Cloudant instance. This configuration means that the task of changing the IBM Cloudant instances that are used by applications can be handled through a modification to the proxy configuration rather than a modification to the application settings. Many proxies can balance the load, based on user-defined health checks.
* Use a global load balancer such as [IBM Cloud® Internet Services](https://cloud.ibm.com/docs/cis?topic=cis-global-load-balancer-glb-conceptsglobal-load-balancer-glb-concepts) to route to IBM Cloudant. This option requires a CNAME definition that routes to different IBM Cloudant accounts, based on a health check or latency rule.







 Recovering from failover 

If a single IBM Cloudant instance is unreachable, avoid redirecting traffic back to it as soon as it becomes reachable again. The reason is that some time is required for intensive tasks such as synchronizing the database state from any peers, and ensuring that indexes are up to date.

It's helpful to have a mechanism for monitoring these tasks to help decide when a database is in a suitable state to service your production traffic.

As a guide, a typical list of checks to apply include:



* [Replications](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-configuring-ibm-cloudant-for-cross-region-disaster-recoveryreplications)
* [Indexes](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-configuring-ibm-cloudant-for-cross-region-disaster-recoveryindexes)
After Vyatta failover, traffic through Netscaler VPX goes down
: When VRRP failover occurs on the Vyatta, the new VRRP primary sends GARP. As a specification, when NetScaler VPX receives GARP, it sends an ARP request to validate rather than updating the ARP table by using GARP. Manually clearing the ARP for the specific IP address on the Netscaler VPX is a temporary workaround.
: This issue was fixed in version 2012m.

Out of memory (OOM) due to SNMP memory leak
: Crashing and outages can result from OOM issues due to memory leaks with SNMP.
: This issue was fixed in version 2012m.

GRE tunnel interface on a secondary Vyatta in u/u status
: As of version 2012, the GRE tunnel status will perpetually be up for both State and Link statuses on a secondary Vyatta. If the local IP of a GRE tunnel is on an active interface, it will allow the transmission (TX) and reception (RX) of packets on that tunnel (tun) interface. If the local-ip of a GRE tunnel is on an inactive interface, such as the VRRP interface of the secondary Vyatta, then the Vyatta will not allow the transmission and reception of packets on that tunnel interface (and will keep that interface up).
: Before updating to 2012, if you have an active/passive BGP over a High Availability GRE setup, ensure that you confirm your GRE interfaces have local-ip set to a VRRP virtual address instead of the main address configured on the dp0bond0 or dp0bond1 interfaces. You should also validate that your routing does not rely on the tunnel (tun) interface changing status to A/D or u/u on failover, as that will no longer occur. In those instances, IBM may recommend setting up a path monitoring policy for the remote GRE endpoint. This utilizes a ping health check to validate the path over the tunnel before adding a route to that tunnel's routing table.
Are you getting an error due to an invalid token when you make an API request? 

The API request fails if the token that you use does not have permissions to work with the Activity Tracking service.

  What’s happening 

Your request fails with an error message that indicates that you are not authorized.

  Why it’s happening 

When you are not authorize to complete a task, you get an error in your response:

{"trace":"53b41915-749c-4af2-b61f-22194d3b56ea","errors":[     !   {"code":"invalid_token","message":"You are not authorize to complete this task. Check you have IAM permissions to work with Activity Tracking in the account.","recovery":"After you check you have permissions, run 'ibmcloud login' to log in to IBM Cloud. Then, run ibmcloud iam oauth-tokens to retrieve your access tokens. Use the IAM token for the Authorization header in your request."}
  How to fix it To resolve the problem, complete the following steps:<-- <ol> -->1.  Check you have IAM permissions to work with Activity Tracking in the account.2.  Get a valid access token. Learn more about retrieving IAM access tokens]]   !  !  !  !
VRVDR-48372 Major Source NAT is using PPPoE Server (default GW) IP and not local PPPoE interface IP 
 VRVDR-48366 Major Some RFC 7951 data test are wrong causing build breakage 1% of the time 
 VRVDR-48338 Critical IDT servo fails to reliably negotiate an higher packets rates with GM 
 VRVDR-48332 Major TACACS+ AAA plugin should restart on DBus failures 
 VRVDR-48327 Blocker HW forwarding failure due to incorrect L2 Rewrite info 
 VRVDR-48273 Major Show sfp info in show interface dataplane <intf> physical on Flexware 
 VRVDR-48243 Blocker SIAD Boundary Clock not staying locked to GM when using ECMP paths 
 VRVDR-48224 Major "show cgnat session" with complex filter missing entry 
 VRVDR-48222 Major Isolate configd and opd from plugin panics 
 VRVDR-48201 Blocker Mellanox 100G: Needs improvement for performance of 128, 256 Byte pkts; 64Byte pkt has better performance 
 VRVDR-48169 Critical Mellanox 100G: improve traffic throughput performance 
 VRVDR-48167 Critical 'show tech-support' hangs 'WARNING: terminal is not fully functional' 
 VRVDR-48157 Critical Center LED status for S/M/L is not working as expected 
 VRVDR-48124 Critical Azure: System does not provision ssh key pair 
 VRVDR-48113 Major OSPF not on vtun interface 
 VRVDR-48108 Minor Debug level messages for VRRP seen in journal 
 VRVDR-48102 Critical Fails to operate when the number of interfaces with PTP enabled is scaled up 
 VRVDR-48098 Critical BroadPTP fails to re-mark SIGNALING messages with appropriate DSCP 
 VRVDR-48093 Blocker Missing SFP 'Measured values' on FTLF1518P1BTL optics 
 VRVDR-48077 Critical Update BIOS strings for the Flexware XSmall platform
Refer to [Correcting connectivity errors](https://cloud.ibm.com/docs/vsrx?topic=vsrx-correcting-readiness-errors) for information on how to resolve SSH connectivity check errors.





 Error 1021 

An error occurred in the connectivity check. Contact [IBM Support](https://cloud.ibm.com/docs/vsrx?topic=gateway-appliance-getting-help).





 Error 1022 

The gateway readiness precheck failed with an unexpected exception. Try again or contact [IBM Support](https://cloud.ibm.com/docs/vsrx?topic=gateway-appliance-getting-help).





 Error 1023 

The gateway readiness precheck failed the DNS accessibility check on the Ubuntu host. Confirm there is network access to the private 10.0.0.0/8 subnet from the host.





 Error 1024 

The gateway readiness precheck failed with an unexpected exception. Try again or contact [IBM Support](https://cloud.ibm.com/docs/vsrx?topic=gateway-appliance-getting-help).





 Error 1025 

The IPMI interface is disabled for the Gateway host. Check IPMI status and enable the interface if is disabled. Try again or contact [IBM Support](https://cloud.ibm.com/docs/vsrx?topic=gateway-appliance-getting-help).





 Error 1026 

The Ubuntu host is unable to write to the attached storage as it is read only. Reboot the host and try again or contact [IBM Support](https://cloud.ibm.com/docs/vsrx?topic=gateway-appliance-getting-help).





 Error 1101 

An error occurred during the readiness check. Try again or contact [IBM Support](https://cloud.ibm.com/docs/vsrx?topic=gateway-appliance-getting-help).





 Error 1102 

The host experienced a precheck setup failure.
Be sure to insert your application choice in place of aaaaaaaa (IBM Cloud® Virtual Router Appliance, Juniper vSRX, or Fortigate Security Appliance (FSA) 10G), and your specific account number in place of xxxxxx in your subject line.
* Wanclouds, our partner in this conversion configuration process, has completed several hundred successful migration engagements. They transform your existing Vyatta 5400 to create similar functionality on the Vyatta 5600 Platform. They provide their services in two tiers:

Zoom

![Tiers](https://cloud.ibm.com/docs-content/v1/content/01ccb31b85637ed5f03008c920c9596354caaf98/virtual-router-appliance/images/tiers.png)

Service tiers



See [Migrating Vyatta 5400](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-migration-overview) to get started.





 Are there any additional paid migration services available from IBM Business Partners for migrating off the Vyatta 5400? 

We have several business partners who provide paid support for Vyatta 5400 migrations. For more information, see the [End of Support Announcement](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-vyatta-5400-end-of-support-announcement).





 Is there a Vyatta 5400 Offering Management support contact in IBM where I can ask questions related to my Vyatta 5400 migration? 

Contact IBM Vyatta 5400 and VRA Network Offering Management with questions at nwom@us.ibm.com. You can also contact them using slack with the IBM Watson Cloud Platform workspace: vyatta-migration





 What additional resources are available to help me with this migration? 

Review the following IBM Cloud® Virtual Router Appliance documentation resources for more information:
* Your domain ID and instance CRN
* The time and timezone of the 503 error occurrence
* The output of www.example.com/cdn-cgi/trace from the browser where the 503 error was observed (replace www.example.com with your actual domain and host name)











 Error 520: web server returns an unknown error 

Error 520 occurs when the origin server returns an empty, unknown, or unexpected response to CIS.



 Error 520 resolution 

A quick workaround while further investigating 520 errors is to either disable proxying the DNS record in CIS or temporarily pause CIS.

Check your origin web server error logs for crashes and look for these common causes:



* Origin web server application crashes
* CIS IPs not allowed at your origin
* Headers exceeding 32 KB (typically due to too many cookies)
* An empty response from the origin web server that lacks an HTTP status code or response body
* Missing response headers or origin web server not returning proper HTTP error responses



520 errors are prevalent with certain PHP applications that crash the origin web server.

If 520 errors continue to occur, provide the following information to Support:



* Full URL(s) of the resource requested when the error occurred
* Cloudflare cf-ray from the 520 error message
* Output from http://www.example.com/cdn-cgi/trace (replace www.example.com with your hostname and domain where the 520 error occurred)
* Two HAR files:



* one with CIS enabled on your website
* one with CIS temporarily disabled











 Error 521: web server is down 

Error 521 occurs when the origin web server refuses connections from the cloud edge. Security solutions at your origin may block legitimate connections from certain CIS IP addresses.

The two most common causes of 521 errors are:



* Offline origin web server application
* Blocked CIS requests





 Error 521 resolution 

Check your origin web server error logs to eliminate these common causes:



* Ensure your origin web server is responsive
* Review origin web server error logs to identify web server application crashes or outages.
* Confirm CIS IP addresses are not blocked or rate limited
* Allow all CIS IP ranges in your origin web server's firewall or other security software
Why is my connection unstable? 

If you notice that your connection is going up and down occasionally, it might be due to a rekey timing issue.

  What’s happening 

My connection is not stable and keeps going down.

  Why it’s happening 

A rekey timing conflict might exist.

  How to fix it 

Follow the steps to resolve any timing issues:



1.  Make sure that NAT-Traversal is enabled on the peer, if it is a configurable option.
2.  If you are using IKEv2, try different lifetimes so that the side with the shorter lifetime always initiates the rekeying process.
3.  Try disabling and reenabling the connection.