vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Load Balancers

Load balancers distribute your traffic across multiple VMs, and you can scale your Virtual Server Instances up or down with minimal or no disruption of your traffic. You can Auto scale your servers as well. In the current architecture there are three load balancers: a public facing Load Balancer for the web servers, and a private load balancer each for both the app and database tiers. Application load balancers are configured in active-active mode. For more information on how ALB’s are configured see [About IBM Cloud Application Load Balancer for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-load-balancers).

Ubuntu Linux® Servers

Ubuntu Linux® servers 20.04 were used in the setup. Some of the commands that are listed might be different based on your operating system and its version.





 Software components 

The following software is used in setting up the infrastructure.



1. An Nginx web server with a public load balancer.
2. Apache Tomcat server with a private load balancer.
3. MySQL server with a Multi-Master[2] replication, and a private load balancer.



A multi master MySQL database is configured and is replicated between the zones. Refer to the diagram for details.
[VMware Aria Operations and VMware Aria Operations for Logs](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vrops_overview) VMware Aria® Operations™ 8.12 and VMware Aria Operations™ for Logs 8.12 
 [Zerto](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-addingzertodr) 9.7u3 







 Procedure to add services to vCenter Server with Hybridity Bundle instances 

To apply a service to your vCenter Server with Hybridity Bundle instance, click the links in the table to review the considerations for the service. Then, check the components that are deployed and follow the instructions in the ordering topics to place your order.



 Service installation results 

When the installation of the service is completed successfully, you are notified by email, and the service is displayed on the Services tab of the instance details with the Installed status.







 Procedure to view services for vCenter Server with Hybridity Bundle instances 



1. From the IBM Cloud for VMware Solutions console, click Resources > vCenter Server from the left navigation pane.
2. In the vCenter Server table, click the instance for which you want to view services.
3. Click the Services tab and click a service to review information about it, such as the service status and other details.
4. Depending on the viewed service, you can access the service console by using the credentials that are provided on the service details page and you can manage the service from here.







 Procedure to delete services for vCenter Server with Hybridity Bundle instances 



1. From the IBM Cloud for VMware Solutions console, click Resources > vCenter Server from the left navigation pane.
2. In the vCenter Server table, click the instance for which you want to delete services.
3. Click the Services tab and locate the service instance that you want to delete and click the Delete icon.
4. In the Delete service window, review the considerations or warnings if there are any. Select I understand and click Delete.





 Results after you delete a service
Hybridity Bundle Indicates if the vCenter Server with Hybridity Bundle is installed. 
 Status The status of the instance.<br><br>The information that is displayed provides an update on the progress of the deployment or the action that is taken on the instance. If there are issues, a message might be displayed to help you investigate and resolve the problem. 







 Procedure to view access information for vCenter Server with Hybridity Bundle instances 

Under Access information, view the access information for the instance-related components. The passwords that are displayed are initial passwords that are generated by the system. If you change them outside of the IBM Cloud for VMware Solutions console, they are not updated on the instance summary page.



Table 4. vCenter Server with Hybridity Bundle access information for instance-related components

 Component Description 

 AD/DNS IPs The IP addresses of the two AD servers. 
 AD/DNS FQDNs The AD/DNS server fully qualified domain names.<br><br>Note: The same administrator password can be used to connect to all the AD/DNS servers by using a remote desktop connection. 
 AD/DNS ADMIN (Remote Desktop) For primary instances, it displays the user name and password to access the AD server through a remote desktop connection.<br><br>For secondary instances, click the View on primary instance link to be directed to the user name and password information on the primary instance.<br><br>Note: After the secondary instance is added to the primary DNS domain and replication occurs, the local administrator password on the primary instance might overwrite the local administrator password on the secondary instance. By clicking the View on primary instance link, you have access to the correct administrator password. 
 NSX Manager IP The IP address of the NSX Manager. 
 NSX Manager FQDN The NSX Manager fully qualified domain name (FQDN). 
 NSX Manager HTTP The user name and password used to access the NSX Manager web console. 
 vCenter IP The IP address of the vCenter Server. 
 vCenter FQDN The vCenter Server fully qualified domain name (FQDN).
To work with Qiskit Runtime serive instances, users must create an API key by going to ([Manage → Access (IAM) → API keys](https://cloud.ibm.com/iam/apikeys)).
3. For further information, users can review [Getting started, Step 2](https://cloud.ibm.com/docs/quantum-computing?topic=quantum-computing-get-startedinstall-packages).







 Example scenario 

In our example, we want to create the following setup:



* We have two projects, ml and finance.



* The ml project needs access to the service instances QR-ml and QR-common.
* The finance project needs access to the service instances QR-finance and QR-common.



* We have three users:



* Fatima needs access to the ml project.
* Ravi needs access to the finance project.
* Amyra needs access to both projects.



* We will use access groups without resource groups.
* Users are defined in an App ID instance and project assignments are also done there.
* Users should be able to delete jobs.



The steps to implement this setup are:



1. The Cloud administrator creates an App ID instance and ensures that it is linked in the Cloud administrator's account. The administrator notes the ID provider URL to share it with users.
2. The Cloud administrator creates three service instances: QR-ml, QR finance, and QR-common.
3. The Cloud administrator creates a custom rule that includes the quantum-computing.job.delete action.
4. The Cloud administrator creates two access groups:



* The ml access group can access QR-ml and QR-common. This access group needs a dynamic rule for the App ID IDP that accepts users whose project attribute contains ml.
* The finance access group can access QR-finance and QR-common. This access group needs a dynamic rule for the App ID IDP that accepts users whose project attribute contains finance.



5. The IDP administrator uses the App ID instance that the Cloud administrator created and defines the three users:
7eb4e35b-4257-56f8-d7da-326d85452591 ubuntu-16.04-amd64 Ubuntu Linux (16.04 LTS Xenial Xerus Minimal Install) 2018-10-30T06:12:06.537+00:00 available public
cfdaf1a0-5350-4350-fcbc-97173b510843 ubuntu-18.04-amd64 Ubuntu Linux (18.04 LTS Bionic Beaver Minimal Install) 2018-10-30T06:12:06.51+00:00 available public
b45450d3-1a17-2226-c518-a8ad0a75f5f8 windows-2012-amd64 Windows Server (2012 Standard Edition) 2018-10-30T06:12:06.678+00:00 available public
81485856-df27-93b8-a838-fa28a29b3b04 windows-2012-r2-amd64 Windows Server (2012 R2 Standard Edition) 2018-10-30T06:12:06.564+00:00 available public
5ccbc579-dc22-0def-46a8-9c2e9b502d37 windows-2016-amd64 Windows Server (2016 Standard Edition) 2018-10-30T06:12:06.59+00:00 available public

IBM has internal mirrors to support the IBM images. The mirrors will contain new versions for the software in the IBM provided images as well as the optional packages associated with the distribution. The mirrors are part of the [service endpoints](https://cloud.ibm.com/docs/vpc?topic=vpc-service-endpoints-for-vpc) available for IBM Cloud VPC. There is no ingress cost for reading the mirrors.

Consider both updating the version lists available to the provisioned instances and upgrading the installed software from these mirrors.





 Initialize and customize cloud instances with cloud-init
Availability group secondary replicas can be configured with one of the following synchronization modes:



* Synchronous - The log is hardened (the transactions are committed to the transaction log) on every secondary replica before the transaction is committed on the primary replica. This guarantees zero data loss, with a potential performance impact on a highly transactional workload if network latency is high. You can have two synchronous-commit replicas per AG. This mode is best suited for instances in the same AZ or MZR.
* Asynchronous - The transaction is considered committed as soon as it is hardened in the transaction log on the primary replica. If there is an issue before the logs are hardened on all of the secondary replicas, data loss is possible, and the recovery point would be the most recently committed transaction that was successful on all of the secondary replicas. This mode is better suited for instances in different MZRs or between an AZ and on-premise.







 Failover modes 

When an availability group fails over, a secondary replica becomes the new primary, and the primary replica, if available, becomes a secondary replica.



* Automatic failover - Automatic failovers provide HA and rely on properly configured listener and WSFC objects for their success. Only a synchronous-commit availability mode replica can be the destination of an automatic failover. You can configure the conditions that prompt an automatic failover on a scale of 1 to 5, where 1 indicates that only a total outage of the SQL Server service on the primary replica would initiate a failover, and 5 indicates any of a number of critical to less-severe SQL Server errors. 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.
Deployment dependencies 

Power Virtual Server with VPC landing zone deployment by using deployable architectures is logically separated into the following steps:



1.  Deploying VPC landing zone infrastructure. This landing zone acts as network security and management landscape for SAP solutions that are logically isolated to another infrastructure deployed as next. There might exist only one VPC landing zone per region in one IBM Cloud account.
2.  Deploying Power Virtual Server with VPC landing zone. This deployed infrastructure hosts SAP solutions that are deployed as next. Provisioned IBM PowerVS workspace is connected to VPC landing zone. There might exist only one IBM PowerVS workspace per IBM PowerVS zone (data center) in one IBM Cloud account. Multiple PowerVS workspaces might be connected to the same VPC landing zone if the private CIDR network ranges of each IBM PowerVS infrastructure do not overlap. Multiple PowerVS workspaces in that case are connected to the same VPC landing zone and to each other.



Each of these steps relies on the previous one. For instance, if you deploy Power Virtual Server with VPC landing zone deployment, you enter IBM Schematics workspace ID of another existing Power Virtual Server with VPC landing zone deployment. The prerequisite dependency is constrained by type. Means, for this deployable architecture not every VPC landing zone is accepted, but only the one created by Power Virtual Server with VPC landing zone deployable architecture.

Certain steps are combined together and provided as one deployment step to simplify provisioning. For instances, this deployable architecture offers a full-stack variation that deploys both VPC landing zone and PowerVS workspace within one step. In addition you might deploy Power Virtual Server with VPC landing zone as an extension, which will create an additional PowerVS workspace and connect it with an existing VPC landing zone.
Click New credential and choose the following options:



1. Enter a credential name of your choice.
2. Choose the Writer role.
3. Under Advanced options:





* Choose Auto Generate for the Service ID.
* Turn on the option to include HMAC credential.





1. Click Add.



Zoom

![Shows creating Cloud Object storage credentials.](https://cloud.ibm.com/docs-content/v1/content/cd4be197c8921ed12923aa899ac93a8ab643c158/AnalyticsEngine/images/create-cos-cred.png)

Figure 1. Create credential window







 What are the Object Storage credentials 

To get the credentials of the Object Storage instance you created to reference from your IBM Analytics Engine serverless instance:



1. Select the credential name you created and copy the credentials to the clipboard.
2. View the credentials that you copied. You will see something like what is shown in the following example:

{
"apikey": "XXXXXXX",
"cos_hmac_keys": {
"access_key_id": "aaaa1111bbbbb222222ccccc3333333ddddd44444",
"secret_access_key": "ZZZZYYYYYXXXXXXWWWWWVVVVVVUUUUU"
},
"endpoints": ...
}

Note:



* Currently, the IBM Analytics Engine serverless plan supports HMAC style credentials only.
* Pick private endpoints for consumption.
* The endpoint to your IBM Cloud Object Storage instance should be the direct endpoint. You can find the direct endpoint to your IBM Cloud Object Storage instance on the IBM Cloud® dashboard by selecting cross regional resiliency, the location, and then clicking on your service instance. You can copy the direct endpoint from the Endpoints page.











 Associate the instance home using REST API
* To provide a direct URL or IP address, specify can-reach=<url> or can-reach=<ip_address>. If the network interface can reach the provided URL or IP address, this option is used. For example, use can-reach=www.exampleurl.com for specifying a URL and can-reach=172.19.0.0 for specifying an IP address.
* To choose an interface with a Regex string, specify interface=<regex_string>; for example, interface=eth..



For more information, see the [ibmcloud oc cluster create satellite](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicli_cluster-create-satellite) command reference.





 Limiting access to your Satellite cluster 

After location and cluster creation

After you create your location and cluster, you can use the [ibmcloud ks cluster master satellite-service-endpoint allowlist add](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicluster-master-sat-allowlist-add) command to add a subnet to a Satellite cluster's service endpoint allowlist. Authorized requests to the cluster master that originate from the subnet are permitted through the Satellite service endpoint. The allowlist must be [enabled](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicluster-master-sat-allowlist-enable) for the restrictions to apply.





 Creating network policies by using Calico host endpoints 

After location and cluster creation

If you create a Satellite cluster at version 4.12 and later, there are Calico Hostendpoint instances that are deployed to the cluster for every worker node’s network interface.

You can use these Hostendpoint instances to define global network policies with the help of the “ibm-cloud.kubernetes.io/interface-name: <network_interface_name>” label that is added to each Hostendpoint instance.
metadata:
name: regcred
namespace: <Your IBM Blockchain Platform namespace>
data: <Your secret data here>
type: kubernetes.io/dockerconfigjson





1. Click Create to finish your setup.







 Step three: Deploy the IBM Blockchain Platform console 

There are four instances available listed under "Provided APIs":

Zoom

![Blockchain instances available in Red Hat Marketplace](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/rhm-operators.png)

Figure 1. Blockchain instances available in Red Hat Marketplace



* IBP CA - (Advanced users) Deploys an instance of an IBM Blockchain Platform CA.
* IBP Console - The IBM Blockchain Platform console UI, or "console", is an award-winning user interface for building your blockchain network.
* IBP Orderer - (Advanced users) Deploys an instance of an IBM Blockchain Platform ordering service.
* IBP Peer - (Advanced users) Deploys an instance of an IBM Blockchain Platform peer.



Which instance should I choose?

All customers need to deploy an instance of the IBP Console to simplify the deployment and management of their blockchain networks. The console itself is free. You are only billed for the blockchain nodes that you create by using the console.

Note that this tutorial only includes instructions for deploying an instance of the IBP Console. Currently, you cannot deploy Certificate Authorities (CAs), peers, and ordering nodes directly, you should use the console to deploy those nodes instead.

Click Create Instance on the IBPConsole tile.

Zoom

!
"resource_instance_url": "/v1/resource_instances/crn%3Av1%3Astaging%3Apublic%3Aibmanalyticsengine%3Aus-south%3Aa%2Fd628eae2cxxxxx229f2xxxx%3A79c757e9-xxxx-xxxx-xxxx-dff7f01xxxx%3A%3A",
"resource_alias_url": null
}
Show more





 Obtaining the service endpoints from the IBM Cloud console 

If you follow the steps in this section to get the service endpoints using the IBM Cloud console, you are directed to the service credentials page for your service instance where you expect to see service endpoints and API key.

To create a service key from the IBM Cloud console:



1. Go to your [resource list](https://cloud.ibm.com/resources), click Services and software and select the provisioned serverless instance.
2. Click Service credentials in the left side bar.
3. Then click New credential to create new service credentials.
4. Enter a name, select a role, and click Add.
5. Copy the credentials to the clipboard.



See the [API documentation](https://cloud.ibm.com/apidocs/ibm-analytics-engine/ibm-analytics-engine-v3) for the operations that are available on the instance management and application management endpoints. For details on the permissions that are required to invoke operations on those endpoints, see [Granting permissions to users](https://cloud.ibm.com/docs/AnalyticsEngine?topic=AnalyticsEngine-grant-permissions-serverless).
Auditing events that are generated in other regions, where there is no route defined, are routed to IBM Cloud Activity Tracker. 
 Location-based events Routes defined for multiple regions with receive_global_events = false Events, that are generated in the regions where routes are defined, are sent to the bucket that is configured per region. Auditing events that are generated in other regions, where there is no route defined, are routed to IBM Cloud Activity Tracker. 
 Global events No route in the account is defined with receive_global_events = true Global events are sent to IBM Cloud Activity Tracker. 
 Global events 1 route in the account is defined with receive_global_events = true Location-based events, that are generated in the region where the route is defined to collect global events, and global events are sent to the bucket that is configured in the route. Events, that are generated in other regions where routes are defined, are sent to the bucket that is configured per region. Auditing events that are generated in other regions, where there is no route defined, are routed to IBM Cloud Activity Tracker. 
 Global events Multiple routes defined with receive_global_events = true This configuration is not supported. 







 CLI prerequisites 

Before you use the the CLI to manage routes, complete the following steps:



1. Identify the endpoint in the region where you plan to configure or manage a route. For more information, see [Endpoints](https://cloud.ibm.com/docs/atracker?topic=atracker-endpointsendpoints_api).
2. [Pre-requisite] [Install the IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli).
3. [Pre-requisite] [Install the IBM Cloud Activity Tracker Event Routing CLI](https://cloud.ibm.com/docs/atracker?topic=atracker-activity-tracking-cliactivity-tracking-cli-prereq).
4. Log in to the region in the IBM Cloud where the instance is running.
* Always On availability groups provide the ability to keep a discrete set of databases highly available across one or more cluster nodes and work at the database level. Availability groups consist of one primary replica and up to a maximum of eight secondary replicas, and use synchronous or asynchronous data replication. In this deployment:



* synchronous replication ios used between the two AZs in the primary MZR.
* asynchronous replication is used between the MZRs.



* Distributed Network Names is a name resource in WSFC and Always On availability groups, used for name resolution of the cluster resources.



A file share witness is not required in this deployment because there are an odd number of nodes and Node Majority quorum mode will be used



 Windows Server Failover Cluster 

Deploying Always On availability groups for HA on Windows requires a Windows Server Failover Cluster (WSFC). Each availability replica of an availability group must reside on a different node of the WSFC. To simplify security configuration for the availability databases, it is recommended that the SQL server instances (the service accounts) run under a domain service account.

Windows Server Failover Cluster (WSFC) is a Windows Server feature and each server that acts as a cluster node must have this feature enabled. WSFC relies on quorum votes to prevent "split-brain" syndrome, and there are a number of quorum modes:



* Node Majority – Active cluster nodes determine the quorum. At least half of the possible votes must be affirmative for the cluster to maintain a healthy state.
* Node and File Share Majority – A remote file share acts as a voting witness for the active nodes involved in a quorum vote. As with Node Majority, at least half of the possible votes must be affirmative for the cluster to maintain a healthy state.
* Node and Disk Majority – A shared disk acts as a voting witness, along with the active nodes involved in a quorum vote.
* Disk Only – A shared disk acts as a witness and quorum is determined by which nodes can access the disk. There is no minimum number of possible votes required.



The Microsoft recommendation for SQL server are as follows:



* Use Node Majority quorum mode when there is an odd number of voting nodes.