vania-janet/multiturn-rag-retrieval-data huggingface dataset:
$ oc extract secret/elasticsearch --to=. --keys=admin-ca -n openshift-logging
8. The other fields, including the other certificate and key fields, can be left blank.



5. Click Create.
6. After the route is created, note the hostname for the route. You can find the hostname at following path: Networking → Routes → Elasticsearch. The hostname is in this format: Hostelasticsearch-openshift-logging.workaround-logging-caf539b8d718205a334907f986dcee2a-0000.us-south.containers.appdomain.cloud.







 Retrieving the bearer token for Elasticsearch 

When forwarding logs to the Elasticsearch cluster, the Fluentd client authenticates to the Elasticsearch service by using a bearer token. You can retrieve the bearer token for the Elasticsearch Operator with the following commands:

$ oc project openshift-operators-redhat
$ oc sa get-token elasticsearch-operator

Save the bearer token to use in the next section.





 Installing Fluentd on a virtual server instance 

You can install Fluentd on a virtual server instance. For more information about installing on different operating systems, see the [instructions for installing Fluentd](https://docs.fluentd.org/installation). For Linux, use the td-agent.

Log forwarding to the Red Hat OpenShift on IBM Cloud cluster is done by the [Elasticsearch Fluentd plug-in](https://docs.fluentd.org/output/elasticsearch). The Elasticsearch plug-in is installed as part of the td-agent installation and does not require any additional installation steps. Log forwarding is configured in the td-agent.conf file.

The following example is a td-agent.conf file that forwards logs to an Elasticsearch server. You must make the appropriate changes where noted with <variables>.

<system>
  log_level debug
</system>

<source>
  @type tail
Run the following tests to verify that the NFS cluster functions.



 Test1 - Testing the NFS export 

Use the following information to test the NFS export.

Run all the commands on an NFS client node outside the HA NFS cluster.

Verify the NFS exports.

showmount -e ${NFS_ip}

The showmount command displays information about file systems that are exported by an NFS Server (NFS v3). Verify that the output lists all the exported directories.

Create a temporary directory on the NFS client node. Then, mount the NFS file system and create the directory structure that is required for the SAP installation.

In the first example, only /usr/sap/trans and /sapmnt/${SID} are NFS mounted on the SAP application server instance.

Prepare the mount points that are used for the SAP installation.

mkdir -p /sapmnt/${SID} /usr/sap/trans

Change the attributes of the mount points.

chattr +i /sapmnt/${SID} /usr/sap/trans

Mount the NFS shares.

mount -t nfs -o vers=4,minorversion=1,sec=sys ${NFS_vh}:/saptrans /usr/sap/trans

mount -t nfs -o vers=4,minorversion=1,sec=sys ${NFS_vh}:/sap${SID} /sapmnt/${SID}

Change the ownership and the permissions.

chown ${sid}adm:sapsys /usr/sap/trans

chmod g+w /usr/sap/trans

chown -R ${sid}adm:sapsys /sapmnt/${SID}

Unmount the file systems.

umount /usr/sap/trans

umount /sapmnt/${SID}

Add the new file systems to /etc/fstab.

cat >> /etc/fstab << EOT
Download terraform from [https://www.terraform.io/downloads.html](https://www.terraform.io/downloads.html).
2. Uncompress the downloaded archive.
3. Move the terraform.exe binary to your PATH.
4. Verify the installation with:

terraform version



To manage IBM Cloud resources with Terraform, you also need to install the IBM Cloud Provider. Starting with Terraform 0.13, the provider can be automatically downloaded from Terraform plugin registry. Follow the instructions in the [provider documentation](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-setup_cliinstall-provider-v13) to configure the required_providers property in your Terraform templates.





 jq 



1. Download jq from [https://stedolan.github.io/jq/](https://stedolan.github.io/jq/).
2. Rename jq-win64.exe to jq.exe.
3. Move jq.exe binary to your PATH.
4. Verify the installation with:

jq --version







 Git 



1. Download and install git from [https://github.com/git-for-windows/git/releases/latest](https://github.com/git-for-windows/git/releases/latest).
2. Verify the installation with:

git --version



Proceed to the configuration [common to all operating systems](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-tutorialsgetting-started-common).







 Apple macOS 

The following sections assume you are running macOS High Sierra or later under a user with Administrator privileges.
Download and install git from [https://github.com/git-for-windows/git/releases/latest](https://github.com/git-for-windows/git/releases/latest).
2. Verify the installation with:

git --version



Proceed to the configuration [common to all operating systems](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-tutorialsgetting-started-common).







 Apple macOS 

The following sections assume you are running macOS High Sierra or later under a user with Administrator privileges. Once you're done with the specific sections, proceed to the configuration [common to all operating systems](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-tutorialsgetting-started-common).



 IBM Cloud CLI 



1. Download and install the IBM Cloud CLI from [https://github.com/IBM-Cloud/ibm-cloud-cli-release/releases/latest](https://github.com/IBM-Cloud/ibm-cloud-cli-release/releases/latest).
2. Verify the installation with:

ibmcloud version







 Docker 



1. Docker Desktop on Mac is one option to run container images on macOS. Make sure to review the terms of the [license agreement](https://docs.docker.com/subscription/docker-desktop-license-agreement) before proceeding with the installation. Other options include [Podman](https://podman.io/get-started).
2. If you don't have one, sign up for a free account at [https://hub.docker.com/signup](https://hub.docker.com/signup).
3.
(https://cloud.ibm.com/docs/satellite?topic=satellite-location-sizingtypes-changes-sizing-increase).

4 vCPU, 16 GB RAM

16 vCPU, 64 GB RAM



Sizing guidance for the Satellite location control plane

 Number of control plane hosts Max clusters in location Example of max worker nodes in location Max cluster size 

 6 hosts Up to 5 clusters 20 workers across 5 clusters, or 80 workers across 2 clusters 60 workers per cluster 
 9 hosts Up to 8 clusters 40 workers across 8 clusters, or 140 workers across 3 clusters 60 workers per cluster 
 12 hosts Up to 11 clusters 60 workers across 11 clusters, or 200 workers across 4 clusters 60 workers per cluster 







 Location size for Red Hat CoreOS (RHCOS) enabled location 

The following tables show sizing guidance for the number of hosts that the Satellite location control plane requires to run the master components for various combinations of clusters and worker nodes in a Red Hat CoreOS enabled location. These sizings are for reference only. Your sizing requirements can increase depending on the amount of workload running in a cluster. For more information, see [What types of changes can increase my location sizing requirements?](https://cloud.ibm.com/docs/satellite?topic=satellite-location-sizingtypes-changes-sizing-increase).

4 vCPU, 16 GB RAM

16 vCPU, 64 GB RAM



Sizing guidance for the Satellite location control plane

 Number of control plane hosts Max clusters in location Example of max worker nodes in location Max cluster size 

 6 hosts Up to 3 clusters 20 workers across 3 clusters, or 80 workers across 2 clusters 60 workers per cluster 
 9 hosts Up to 5 clusters 40 workers across 5 clusters, or 140 workers across 3 clusters 60 workers per cluster 
 12 hosts Up to 8 clusters 60 workers across 8 clusters, or 200 workers across 4 clusters 60 workers per cluster 







 Location size for testing 

The following table shows sizing guidance for the number of hosts that the Satellite location control plane requires to run a Satellite location demonstration. This configuration is not intended for production use.

For a non-RHCOS enabled location, your hosts must have at least 4 vCPU and 16 GB RAM.
It depends on how you set up the app. See [Planning highly available deployments](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_deployhighly_available_apps) and [Planning highly available persistent storage](https://cloud.ibm.com/docs/openshift?topic=openshift-storage-plan).







 Multiple public clusters connected with a global load balancer 

To protect your app from a master failure or for classic clusters that must reside in one of the supported [single zone locations](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zoneszones-sz), you can create multiple clusters in different zones within a region and connect them with a global load balancer.

To connect multiple clusters with a global load balancer, the clusters must be set up with public network connectivity.

Zoom

![High availability for multiple clusters.](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/ha-multiple-cluster-zones.svg)

Figure 1. High availability for multiple clusters

To balance your workload across multiple clusters, you must set up a global load balancer and add the public IP addresses of your router services or load balancer services to your domain. By adding these IP addresses, you can route incoming traffic between your clusters. For the global load balancer to detect if one of your clusters is unavailable, consider adding a ping-based health check to every IP address. When you set up this check, your DNS provider regularly pings the IP addresses that you added to your domain. If one IP address becomes unavailable, then traffic is not sent to this IP address anymore. However, Red Hat OpenShift does not automatically restart pods from the unavailable cluster on worker nodes in available clusters.
* [Accessing Red Hat OpenShift clusters on Satellite](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_cluster_sat)



* [Accessing clusters through the cluster service URL](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_cluster_sat_se)
* [Accessing clusters from within the IBM Cloud private network](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_cluster_sat_link)
* [Accessing clusters from the public network](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clustersat_public_access)



* [Accessing VPC clusters through the Virtual Private Endpoint Gateway](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clustervpc_vpe)
* [Accessing clusters from automation tools by using an API key](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_automation)



* [Using an API key to log in to clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_api_key)
* [Using a service ID to log in to clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clusteraccess_service_id)





[Accessing the cluster master with admission controllers and webhooks](https://cloud.ibm.com/docs/openshift?topic=openshift-access_webhooksaccess_webhooks)



* [Can I create my own admission controllers?](https://cloud.ibm.com/docs/openshift?topic=openshift-access_webhooksaccess_webhooks_create_controllers)
public-crbmnj1b1d09lpvv3oof0g-alb1 true enabled public 169.XX.XXX.XX dal10 ingress:1.1.2_2507_iks 2234945 2.0



* If a public ALB is listed and is assigned an IP address (classic clusters) or hostname (VPC clusters), continue to the next step.
* If a public ALB is listed and but is not assigned an IP address (classic clusters) or hostname (VPC clusters), try to disable and re-enable the ALBs.



* Classic clusters:

ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>

ibmcloud ks ingress alb enable classic --alb <ALB_ID> -c <cluster_name_or_ID>
* VPC clusters:

ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>

ibmcloud ks ingress alb enable vpc-gen2 --alb <ALB_ID> -c <cluster_name_or_ID>



* If no ALBs are created after several minutes, [review ways to get help](https://cloud.ibm.com/docs/containers?topic=containers-get-help).



4. Check whether the LoadBalancer service that exposes the ALB exists and is assigned the same IP address (classic clusters) or hostname (VPC clusters) as the public ALB.



* If a LoadBalancer service is listed and is assigned an IP address (classic clusters) or hostname (VPC clusters), continue to the next step.
* If no LoadBalancer services are created after several minutes, [review ways to get help](https://cloud.ibm.com/docs/containers?topic=containers-get-help).



kubectl get svc -n kube-system | grep LoadBalancer

Example output
Classic clusters that are set up in a single zone data center can't be converted to a multizone cluster. To convert a single zone cluster to a multizone cluster, see [Adding worker nodes by adding a zone to a worker pool](https://cloud.ibm.com/docs/containers?topic=containers-add_workersadd_zone).





 Do my apps automatically spread across zones? 

It depends on how you set up the app. See [Planning highly available deployments](https://cloud.ibm.com/docs/containers?topic=containers-plan_deployhighly_available_apps) and [Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage-plan).







 Multiple public clusters connected with a global load balancer 

To protect your app from a master failure or for classic clusters that must reside in one of the supported [single zone locations](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-sz), you can create multiple clusters in different zones within a region and connect them with a global load balancer.

To connect multiple clusters with a global load balancer, the clusters must be set up with public network connectivity.

Zoom

![High availability for multiple clusters.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/ha-multiple-cluster-zones.svg)

Figure 1. High availability for multiple clusters

To balance your workload across multiple clusters, you must set up a global load balancer and add the public IP addresses of your ALBs or load balancer services to your domain. By adding these IP addresses, you can route incoming traffic between your clusters. For the global load balancer to detect if one of your clusters is unavailable, consider adding a ping-based health check to every IP address. When you set up this check, your DNS provider regularly pings the IP addresses that you added to your domain.
Adding, viewing, and deleting clusters for VMware Regulated Workloads 

You can add your own clusters to VMware® Regulated Workloads instances to expand the compute and storage capacity. Within a cluster, you can manage VMware vSphere® ESXi™ servers for better resource allocation and high availability. When no longer needed, delete the added clusters from your instances.

The procedures to add, view, and delete clusters for VMware Regulated Workloads instances are similar to the ones for VMware vCenter Server® instances. For more information, see the following topics:



*  [Adding clusters to vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_addingclusters)
*  [Viewing clusters in vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_viewingclusters)
*  [Deleting clusters from vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_deletingclusters)





  Related links 



*  [Viewing and deleting VMware Regulated Workloads](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vrw-view-delete-instance)
*  [Expanding and contracting capacity for VMware Regulated Workloads](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vrw-addingremovingservers)
Setting up disaster recovery with Portworx 

You can configure disaster recovery for your data that you store in your Kubernetes clusters by using Portworx. When one of your clusters becomes unavailable, Portworx automatically fails over to another cluster so that you can still access your data.

Disaster recovery with Portworx requires at least two Kubernetes clusters where Portworx is installed and configured for disaster recovery. One of the two clusters is considered the active cluster where your data is primarily stored. All data is then replicated to the standby cluster. If your active cluster becomes unavailable, Portworx automatically fails over to the standby cluster and makes the standby cluster the new active cluster so that data can continue to be accessed.

If you installed Portworx in one of your clusters without the Portworx disaster recovery plan, you must re-install Portworx with the disaster recovery plan so that you can include this cluster in your disaster recovery configuration.

Depending on your cluster setup, Portworx offers the following two disaster recovery configurations:



* [Metro DR](https://docs.portworx.com/portworx-install-with-kubernetes/disaster-recovery/1-metro-dr-nodes-are-in-the-metro-area-network-man): Your Kubernetes clusters are in the same metro location, such as both clusters are deployed in one or multiple zones of the us-south region. All clusters are configured to use the same Portworx cluster and share the same Portworx key-value store. Data is automatically replicated between the clusters because the Portworx storage layer is shared. RPO (Recovery Point Objective) and RTO (Recovery Time Objective) for this configuration is less than 60 seconds.
* [Asynchronous DR](https://docs.portworx.com/portworx-install-with-kubernetes/disaster-recovery/2-asynchronous-dr-nodes-are-across-different-regions-datacenters): Your Kubernetes clusters are deployed in different regions, such as us-south and us-east.
For more information, see [Platform and service roles for Red Hat OpenShift clusters](https://cloud.ibm.com/docs/satellite?topic=satellite-iamiam-roles-clusters).
: If you have access to a Satellite location or configuration, you can view the clusters that are attached to the location or configuration. However, you might not be able to access the clusters if you do not have the appropriate roles to those clusters. For example, if you have the appropriate access to a Satellite configuration, you might be able to list all the Kubernetes resources that run in registered clusters through the Satellite Config API. However, without an access policy to the individual clusters, you cannot log in to the individual clusters and use Red Hat OpenShift APIs to list Kubernetes resources. For more information, see the following topics.



* [Reference documentation](https://cloud.ibm.com/docs/openshift?topic=openshift-access_reference) for user access permissions including [platform](https://cloud.ibm.com/docs/openshift?topic=openshift-access_reference) and [service](https://cloud.ibm.com/docs/openshift?topic=openshift-access_reference) roles.
* [Assigning access to clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-users), such as setting up the API key for underlying infrastructure permissions and granting users access with IBM Cloud IAM.
* [Accessing clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster) on the public or private service endpoints, or by using an IBM Cloud IAM API key such as for automation purposes.



Other managed services
: To use Satellite with other [managed services](https://cloud.ibm.com/docs/satellite?topic=satellite-managed-services), you must set up service to service access through IAM, with Satellite as your target service and the managed service as the source service.



 Platform and service roles for Red Hat OpenShift clusters
To balance your workload across multiple clusters, you must set up a global load balancer and add the public IP addresses of your ALBs or load balancer services to your domain. By adding these IP addresses, you can route incoming traffic between your clusters. For the global load balancer to detect if one of your clusters is unavailable, consider adding a ping-based health check to every IP address. When you set up this check, your DNS provider regularly pings the IP addresses that you added to your domain. If one IP address becomes unavailable, then traffic is not sent to this IP address anymore. However, Kubernetes does not automatically restart pods from the unavailable cluster on worker nodes in available clusters. If you want Kubernetes to automatically restart pods in available clusters, consider setting up a [multizone cluster](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersmz-clusters).



 Why do I need 3 clusters in three zones? 

Similar to using [3 zones in multizone clusters](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersmz-clusters), you can provide more availability to your app by setting up three clusters across zones. You can also reduce costs by purchasing smaller machines to handle your workload.





 What if I want to set up multiple clusters across regions? 

You can set up multiple clusters in different regions of one geolocation (such as US South and US East) or across geolocations (such as US South and EU Central). Both setups offer the same level of availability for your app, but also add complexity when it comes to data sharing and data replication. For most cases, staying within the same geolocation is sufficient. But if you have users across the world, it might be better to set up a cluster where your users are so that your users don't experience long waiting times when they send a request to your app.





 What options do I have to load balance workloads across multiple clusters?
The required IOPS varies with the number of clusters in the location, and the activity of the masters for those clusters. For more information, see [How many clusters can I run before I need to add capacity to the control plane?](https://cloud.ibm.com/docs/satellite?topic=satellite-location-sizingcontrol-plane-how-many-clusters).

Additional storage for hosts assigned to services (like clusters)
: Depending on the services that you want to use, you might need to add more storage before attaching hosts to your location. For service-specific storage requirements, refer to the service documentation. Note that if you plan to deploy additional services or operators to the clusters in your location, you must account for cluster storage plus any additional deployments that you want to use in your clusters. For example, OpenShift Data Foundation.



* [Satellite-enabled services](https://cloud.ibm.com/docs/satellite?topic=satellite-managed-services)
* [Satellite storage overview](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-template-ov)
(https://cloud.ibm.com/docs/openshift?topic=openshift-cs_loadbalancer_failscs_loadbalancer_fails)

[Classic clusters: Why can't I deploy a load balancer?](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_subnet_limit_lbcs_subnet_limit_lb)

[Classic clusters: Why does the master status have an ingress IP address for NLB error?](https://cloud.ibm.com/docs/openshift?topic=openshift-rhoks_ts_openvpn_subnetrhoks_ts_openvpn_subnet)



* [Verifying that your cluster has available subnets](https://cloud.ibm.com/docs/openshift?topic=openshift-rhoks_ts_openvpn_subnetverify_subnets)
* [Verifying that the load balancer setup completed successfully](https://cloud.ibm.com/docs/openshift?topic=openshift-rhoks_ts_openvpn_subnetverify_nlb)



[Classic clusters: Why does source IP preservation fail when using tainted nodes?](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_source_ip_fails_lbcs_source_ip_fails_lb)

[VPC clusters: Why do I see VPC load balancer health status failures?](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc_lb_healthcheckvpc_lb_healthcheck)

[VPC clusters: Why can't my app connect via load balancer?](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc_ts_lbvpc_ts_lb)

[VPC clusters: Why does a Kubernetes LoadBalancer service fail with no IPs?]