vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The default is 3, which prompts an automatic failure in the case of an outage or unresponsive primary replica, but also for some critical server conditions. These “flexible failover policy” conditions are detailed at [Configure a flexible automatic failover policy for an Always On availability group](https://docs.microsoft.com/sql/database-engine/availability-groups/windows/flexible-automatic-failover-policy-availability-groupFClevel).
* Planned failover - A planned failover can occur only if there is no possibility for data loss. Specifically, this means the failover occurs without using the FORCE parameter to acknowledge warnings in code or in the SSMS dialog boxes. It is only possible to have a planned failover to a secondary replica in synchronouscommit availability mode. You can move an asynchronous-commit availability mode replica to synchronous, wait for the SYNCHRONIZED state, and then issue a planned failover without data loss. Planned failovers should always be initiated via SSMS, T-SQL, or PowerShell.
* Forced failover - A manually-initiated, forced failover should only be initiated in response to adverse cluster conditions such as the loss of the primary node. Initiate from SSMS wizards, T-SQL commands, or PowerShell and only from Windows Server Failover Cluster Manager as a last resort.
* Force failover if WSFC quorum is down - You will not be able to force a failover for availability groups based on a WSFC if the WSFC has no quorum. You will first have to force quorum in the Configuration Manager by “rigging” the vote and modifying node weights. You should consider this step only in emergencies, such as when a disaster has disrupted a majority of cluster nodes. This can be accomplished this with a PowerShell script, to force an online node to assume the primary role without a majority of votes.



Failovers are not caused by database issues such as a database becoming suspect due to a loss of a data file or corruption of a transaction log.





 Other types of availability groups 

The following availability groups are not used in this deployment pattern, but may be of interest to solutioners wanting to adapt or extend this deployment pattern:
GPU device plug-in and installer 13fdc0d eb3a259 Updated images for [CVE-2019-3462](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3462) and [CVE-2019-6486](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6486). 
 IBM Cloud Provider v1.12.4-118 v1.13.2-62 Updated to support the Kubernetes 1.13.2 release. Additionally, calicoctl version is updated to 3.4.0. Fixed unnecessary configuration updates to version 2.0 network load balancers on worker node status changes. 
 IBM Cloud File Storage for Classic plug-in 338 342 The File Storage for Classic plug-in is updated as follows:<br><br><br><br> * Supports dynamic provisioning with [volume topology-aware scheduling](https://cloud.ibm.com/docs/containers?topic=containers-file_storagefile-topology).<br> * Ignores persistent volume claim (PVC) delete errors if the storage is already deleted.<br> * Adds a failure message annotation to failed PVCs.<br> * Optimizes the storage provisioner controller's leader election and resync period settings, and increases the provisioning timeout from 30 minutes to 1 hour.<<br> * Checks user permissions before starting the provisioning.<br> * Adds a CriticalAddonsOnly toleration to the ibm-file-plugin and ibm-storage-watcher deployments in the kube-system namespace.<br><br><br> 
 Key Management Service provider 111 122 Added retry logic to avoid temporary failures when Kubernetes secrets are managed by IBM Key Protect for IBM Cloud. 
 Kubernetes v1.12.4 v1.13.2 See the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.13.2).
oc adm taint node <node_name> dedicated:NoSchedule- dedicated:NoExecute-







 Deploying the Sysdig agent on edge worker nodes 

To allow the Sysdig agent pods to be deployed to your edge worker nodes, run the following kubectl patch command to update the sysdig-agent DaemonSet. This command applies the NoExecute toleration to the DaemonSet to ensure that the agent pods don't get evicted from the node.

kubectl patch ds sysdig-agent -n ibm-observe --type merge --type='json' -p='[{"op": "add", "path": "/spec/template/spec/tolerations/-", "value": {"operator": Exists, "effect": NoExecute}}]'

If you used pod labels such as dedicated=edge, you can also apply this label to any pods that you want to allow on your edge nodes.
You can also use your console to generate a signing certificate and private key and convert the keys into PEM format. You can then set a user context by passing your keys directly to the SDKs' [Fabric Client class](https://hyperledger.github.io/fabric-sdk-node/release-2.2/Client.html) using the following code:

fabric_client.createUser({
username: 'admin',
mspid: 'org1',
cryptoContent: {
privateKeyPEM: fs.readFileSync(path.join(__dirname,'./privateKey.pem')),
signedCertPEM: fs.readFileSync(path.join(__dirname,'./certificate.pem'))
}});

If you are using low-level SDK APIs to connect to your network, there are additional steps that you can take to manage the performance and availability of your application.





 Highly available applications 

As a high availability best practice, it is strongly recommended that you deploy a minimum of two peers per organization for failover. You need to adapt your applications for high availability as well by downloading a [connection profile](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-organizationsibp-console-organizations-connx-profile) and [enabling service discovery](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-appibp-console-app-sd-cfg). Install smart contracts on both peers and join the peers to your channels.





 Using indexes with CouchDB 

If you use CouchDB as your state database, you can perform JSON data queries from your smart contract against the channel's state data. It is strongly recommended that you create indexes for your JSON queries and use them in your smart contract. Indexes allow your applications to retrieve data efficiently when your network adds additional blocks of transactions and entries in the world state.
mb4c.32x384.6x3.8tb.ssd 384GB 10000Mbps 32 Physical UBUNTU_18_64, UBUNTU_20_64 (default) 2000GB HDD 1920GB SSD 
 mb4c.32x768.3.8tb.ssd 768GB 10000Mbps 32 Physical UBUNTU_18_64, UBUNTU_20_64 (default) 2000GB HDD 960GB SSD 
 mb4c.48x1536 1536GB 10000Mbps 48 Physical UBUNTU_18_64, UBUNTU_20_64 (default) 2000GB HDD 960GB SSD 
 me4c.4x32 32GB 10000Mbps 4 Physical UBUNTU_18_64, UBUNTU_20_64 (default) 2000GB HDD 2000GB HDD 
 me4c.4x32.1.9tb.ssd 32GB 10000Mbps 4 Physical UBUNTU_18_64, UBUNTU_20_64 (default) 2000GB HDD 960GB SSD 
 mg4c.32x384.2xp100 384GB 10000Mbps 32 Physical UBUNTU_18_64, UBUNTU_20_64 (default) 2000GB HDD 960GB SSD 
 mg4c.48x384.2xv100 384GB 10000Mbps 48 Physical UBUNTU_18_64, UBUNTU_20_64 (default) 2000GB HDD 960GB SSD 
 u3c.2x4 4GB 1000Mbps 2 Virtual UBUNTU_18_64, UBUNTU_20_64 (default) 25GB SSD 100GB SSD 







 par 



Table 9. Worker node flavors for Paris.

 Name Memory Network speed Cores Type OS Primary storage Secondary storage 

 b3c.16x64 64GB 1000Mbps 16 Virtual UBUNTU_18_64, UBUNTU_20_64 (default) 25GB SSD 100GB SSD
print("List of databases:")
for row in rows:
print(" ",row[0])
Show more

This final example uses the information from your connection string and the Node driver [node-postgres](https://node-postgres.com/) to connect to your database.

const pg = require("pg");
const fs = require("fs");

let connectionString = "postgres://<username>:<password>@<host>:<port>/<database>?sslmode=verify-full";
let caCert = fs.readFileSync('/path/to/cert');

// set up a client with your Databases for EnterpriseDB connection string
let client = new pg.Client({ connectionString: connectionString,
// set up the TLS options
ssl: {
ca: caCert,
rejectUnauthorized: true
}
});

client.connect(function(err) {
if (err) {
console.log(err);
process.exit(1);
} else {
// query for the names of the databases
client.query(
"SELECT datname FROM pg_database;",
function(err, result) {
if (err) {
console.log(err);
}
// return the names of the databases
console.log(result.rows);
client.end();
}
);
}
});
Show more





 Driver TLS and self-signed certificate support 

All connections to IBM Cloud® Databases for EnterpriseDB are TLS 1.2 enabled, so the driver you use to connect needs to be able to support encryption. Your deployment also comes with a self-signed certificate so the driver can verify the server upon connection.



 Using the self-signed certificate 



1. Copy the certificate information from the Endpoints pane or the Base64 field of the connection information.
2.
* Additional application instance (AAS) on node 2



It's recommended that you run both the ASCS instance and the ERS instance in a switchover cluster infrastructure.





 IBM Cloud File Storage for VPC for SAP HA architecture 

[IBM Cloud File Storage for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-vpc-about) technology is used to make the SAP directories available to the SAP system. The technologies of choice are NFS, shared disks, and cluster file system. If you have decided to use a highly available (HA) solution for your SAP system, make sure that you properly address the HA requirements of the SAP file systems in your SAP environment.

Zoom

![Figure 4. Fire shares for VPC](https://cloud.ibm.com/docs-content/v1/content/f89cc64b006ca59b35404693959c83d5747fee3e/sap/images/sap-terraform-ha-file-shares.png)

Figure 4. File shares for VPC



* File shares that are mounted as NFS permanent file systems on both cluster nodes for SAP apps HA:



* /usr/sap/<SAPSID>/SYS
* /sapmnt<SAPSID>
* /usr/sap/trans



* Cluster-managed file systems for SAP Apps HA: ASCS si ERS



* /usr/sap/<SAPSID>/ASCS00
* /usr/sap/<SAPSID>/ERS01



* Permanent NFS mount on SAP Apps HA node 1 PAS instance:



* /usr/sap/<SAPSID>/Dxx



* Permanent NFS mount on SAP Apps HA node 2 dialog instance:



* /usr/sap/<SAPSID>/Dyy







 Prerequisites 

You need to install the hardware (hosts, disks, and network) and decide how to distribute the database, SAP instances, and, if required, the Network File System (NFS) server over the cluster nodes.





 Context
VMware NSX-T logical routers on VPC deployments 

As defined earlier, a single NSX-T™ gateway cluster with two virtual edge nodes is used in this architecture. It is required to create a Tier-0 (T0) logical router or a Tier-1 (T1) router to provide stateful services such as NAT or load balancer.

When you deploy a VMware NSX Edge™, you can consider it as an empty container. The edge nodes do not change until you create logical routers. The NSX Edge Node provides the compute capacity that is backing the T0 and T1 logical routers. Each logical router contains a services router (SR) and a distributed router (DR). A DR is essentially a router with logical interfaces that are connected to multiple subnets (NSX-T segments). It runs as a kernel module and is distributed in ESXi hypervisors across all transport nodes, including edge nodes.

A services router is instantiated on a gateway cluster as a virtual routing and forwarding (VRF) when a service that cannot be distributed is enabled, such as:



* Physical infrastructure connectivity
* NAT
* DHCP server
* VPN
* Gateway Firewall



In this architecture, the single gateway cluster hosts both T0 and T1s as shown in the following diagram. You can deploy multiple gateway clusters to scale the solution up, if needed.

Zoom

![VPC gateway cluster](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/vpc-ryo-diagrams-nsx-t-edges.svg)

Figure 1. VPC gateway cluster

For more information about NSX-T Designs, see [NSX-T Reference Design Guide 3-0](https://nsx.techzone.vmware.com/resource/nsx-t-reference-design-guide-3-0).



 Tier-0 logical router
Create a NodePort service with port values that are in the port range specified in the LoadBalancer you created earlier.

apiVersion: v1
kind: Service
metadata:
name: echo-server-node-port
spec:
ports:
- port: 80
protocol: TCP The protocol of the port range
nodePort: 30003 Node port in the port range
targetPort: 8080
selector:
app: echo-server
type: NodePort
4. Create the NodePort service.

oc apply -f nodeport.yaml
5. To access a port that is in the range provided by NLB.

curl https://<public ip assigned to NLB>:30003



* 30003 = Is a node port in the range that responds to request
* Other ports in the range do not respond unless additional node port services are created.









 Setting up a private VPC NLB 

Expose your app to private network traffic by setting up a Kubernetes LoadBalancer service in each zone of your cluster. When you create the Kubernetes LoadBalancer service, a private Network Load Balancer for VPC (VPC NLB) that routes requests to your app is automatically created for you in your VPC outside of your cluster.

Before you begin



* Ensure that you have the [Writer or Manager IBM Cloud IAM service access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms) for the namespace in which you deploy the Kubernetes LoadBalancer service for the VPC NLB.
* Connect to your VPC private network, such as through a [VPC VPN connection](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-vpnaas).
* [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
* To view VPC NLBs, install the infrastructure-service plug-in. The prefix for running commands is ibmcloud is.
Active Directory serves to authenticate accesses to manage the VMware® instance only and not to house users of the workloads in the deployed instances. The forest root domain name of the Active Directory server equals to the Domain Name Services (DNS) domain name that you specify during initial deployment.

Domain name services (DNS) in this design support cloud management and infrastructure components only. The DNS zone files are also replicated on the Active Directory servers.





 Veeam management backup 

Veeam is used to continuously back up the management stack for protection against disasters and rapid restoration to known good states. Veeam is also available for use in the workload cluster to provide back up and disaster recovery services for the SaaS consumer workloads.





 vCenter 

The vCenter Server with an embedded PSC is installed on a portable subnet on the private VLAN that is associated with management VMs. Its default gateway is set to the IP address assigned on the perimeter gateway.

One vCenter Server is deployed to manage the management cluster, the gateway cluster, and the SaaS consumer workload clusters.





 NSX-T 

NSX-T™ provides a highly secure and flexible software-defined network to support the application requirements. NSX-T controllers are hosted in the management cluster.

NSX-T is configured with three controllers, which provide a highly available and redundant configuration. Additionally a virtual IP (VIP) address is used to access the cluster to provide fault tolerance and high availability to NSX Manager nodes. Each controller manager is assigned a VLAN–backed IP address from the private portable address block that is designated for management components.

Hosting the NSX-T controllers in the management cluster ensures that network and security changes are not possible by anyone other than the designated administrators.





 VMware Aria Operations Manager 

The VMware Aria Operations analytics cluster contains the nodes that analyze and store data from the monitored components in this deployment.

The analytics cluster consists of the following components:



* Primary node – The primary node is the initial node in a VMware Aria Operations cluster. In a large environment, this node manages all the other nodes.
* Primary node replica – This node enables high availability of the primary node.
OS: Linux 5.15.18-200.fc35.x86_64 amd64

 oc version
Client Version: 4.9.21

 zip
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.

 unzip
UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. Send

 git --version
git version 2.27.0

 curl
curl 7.61.1 (x86_64-redhat-linux-gnu) libcurl/7.61.1 OpenSSL/1.1.1k zlib/1.2.11 brotli/1.0.6 libidn2/2.2.0 libpsl/0.20.2 (+libidn2/2.2.0) libssh/0.9.4/openssl/zlib nghttp2/1.33.0

 wget
GNU Wget 1.19.5 built on linux-gnu.

 openssl version
OpenSSL 1.1.1k FIPS 25 Mar 2021

 make
GNU Make 4.2.1

 docker
Client:
Version: 20.10.12
API version: 1.41
Go version: go1.16.12
Git commit: e91ed57
Built: Mon Dec 13 11:40:57 2021
OS/Arch: linux/amd64
Context: default

 dc --version
dc (GNU bc 1.07.1) 1.4.1

 ed --version
GNU ed 1.14.2
Show more





 Version 3.5 

To view the contents of version 3.5, from the running image, type default_versions.sh. The 3.x branch provides images with the current tool versions. The current Java™ version is Java™ 11. Node.js no longer uses nvm to manage different node.js versions.
If you replace multiple worker nodes at the same time, they are deleted and replaced concurrently, not one by one. Make sure that you have enough capacity in your cluster to reschedule your workloads before you replace worker nodes. 







 Networking 

Keep in mind that the [service](https://cloud.ibm.com/docs/containers?topic=containers-limitationstech_limits) limitations also apply.



VPC cluster networking limitations

 Category Description 

 App URL length DNS resolution is managed by the cluster's [virtual private endpoint (VPE)](https://cloud.ibm.com/docs/containers?topic=containers-vpc-subnetsvpc_basics_vpe), which can resolve URLs up to 130 characters. If you expose apps in your cluster with URLs, such as the Ingress subdomain, ensure that the URLs are 130 characters or fewer. 
 Istio managed add-on See [Istio add-on limitations](https://cloud.ibm.com/docs/containers?topic=containers-istio-aboutistio_limitations). 
 Network speeds [VPC profile network speeds](https://cloud.ibm.com/docs/vpc?topic=vpc-profiles) refer to the speeds of the worker node interfaces. The maximum speed available to your worker nodes is 25Gbps. Because IP in IP encapsulation is required for traffic between pods that are on different subnets, data transfer speeds between pods on different subnets might be slower, about half the compute profile network speed. Overall network speeds for apps that you deploy to your cluster depend on the worker node size and application's architecture. 
 NodePort You can access an app through a NodePort only if you are connected to your private VPC network, such as through a VPN connection. To access an app from the internet, you must use a VPC load balancer or Ingress service instead. 
 Pod network VPC access control lists (ACLs) filter incoming and outgoing traffic for your cluster at the subnet level, and security groups filter incoming and outgoing traffic for your cluster at the worker nodes level.
mb4c.32x384.6x3.8tb.ssd 384GB 10000Mbps 32 Physical UBUNTU_18_64, UBUNTU_20_64 (default) 2000GB HDD 1920GB SSD 
 mb4c.32x768.3.8tb.ssd 768GB 10000Mbps 32 Physical UBUNTU_18_64, UBUNTU_20_64 (default) 2000GB HDD 960GB SSD 
 mb4c.48x1536 1536GB 10000Mbps 48 Physical UBUNTU_18_64, UBUNTU_20_64 (default) 2000GB HDD 960GB SSD 
 me4c.4x32 32GB 10000Mbps 4 Physical UBUNTU_18_64, UBUNTU_20_64 (default) 2000GB HDD 2000GB HDD 
 me4c.4x32.1.9tb.ssd 32GB 10000Mbps 4 Physical UBUNTU_18_64, UBUNTU_20_64 (default) 2000GB HDD 960GB SSD 
 mg4c.32x384.2xp100 384GB 10000Mbps 32 Physical UBUNTU_18_64, UBUNTU_20_64 (default) 2000GB HDD 960GB SSD 
 mg4c.48x384.2xv100 384GB 10000Mbps 48 Physical UBUNTU_18_64, UBUNTU_20_64 (default) 2000GB HDD 960GB SSD 
 u3c.2x4 4GB 1000Mbps 2 Virtual UBUNTU_18_64, UBUNTU_20_64 (default) 25GB SSD 100GB SSD 







 lon 



Table 5. Worker node flavors for London.

 Name Memory Network speed Cores Type OS Primary storage Secondary storage 

 b3c.16x64 64GB 1000Mbps 16 Virtual UBUNTU_18_64, UBUNTU_20_64 (default) 25GB SSD 100GB SSD
If your app workload requires other IBM Cloud services, your worker nodes can automatically, securely communicate with IBM Cloud services that support private cloud service endpoints over the private VPC network.





 External communication to apps that run on worker nodes 

After you test your app, you can expose it to the internet by creating a public Kubernetes LoadBalancer service or using the default public Ingress application load balancers (ALBs). The VPC load balancer that is automatically created in your VPC outside of your cluster when you use one of these services routes traffic to your app. You can improve the security of your cluster and control public network traffic to your apps by replacing the kube-<vpc-id> security group, which is automatically applied to the VPC ALB, with a security group that you create and manage. When applied to ALBs, security groups control which inbound traffic is permitted to your cluster through the ALB.

Ready to get started with a cluster for this scenario? After you plan your [high availability](https://cloud.ibm.com/docs/containers?topic=containers-ha_clusters) and [worker node](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes) setups, see [Creating VPC clusters](https://cloud.ibm.com/docs/containers?topic=containers-clusters).







 Scenario: Run internet-facing app workloads in a VPC cluster with limited public egress 

In this scenario, you run workloads in a VPC cluster that are accessible to requests from the Internet. Public access is controlled so that end users can access your apps while unwanted public requests to your apps are denied. However, you might need to also provide limited public egress from your worker nodes to a public endpoint, and want to ensure that this public egress is controlled and isolated in your cluster. For example, you might need your app pods to access an IBM Cloud service that does not support private cloud service endpoints, and must be accessed over the public network.

Zoom

![Network setup for a cluster that allows limited, secure public access.]
Before you begin, note the public IP address for each worker node in the cluster.

ibmcloud oc worker ls --cluster <cluster_name_or_ID>



 Allow worker nodes to communicate with cluster master 

To allow worker nodes to communicate with the cluster master over the public cloud service endpoint, allow outgoing network traffic from the source <each_worker_node_publicIP> to the destination TCP/UDP port range 30000-32767 and port 443, and the following IP addresses and network groups. Additionally, if you plan to use Ingress or routes to expose apps in your cluster, allow incoming network traffic through these ports to your worker node IP addresses as well so that the Red Hat OpenShift control plane can check the health of your routers.

This table is moving. For the latest IP lists and continued updates, see the public network isolation folder in the IBM/kube-samples[repo](https://github.com/IBM-Cloud/kube-samples/tree/master/calico-policies/public-network-isolation). You can Watch pull requests in the repo for updates.



* TCP/UDP port range 30000-32767, port 443 FROM <each_worker_node_publicIP> TO <public_IPs>
* Replace <public_IPs> with the public IP addresses of the region that your cluster is located.





Table 1. IP addresses to open for outgoing traffic

 Region Public IP address