vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You use the Bastion server CLI to run the Terraform scripts that are located in the [GitHub repository](https://github.com/IBM-Cloud/sap-bw4hana/tree/main/cli).

To run the scripts to deploy the SAP BW/4HANA release on dedicated SAP HANA 2.0 BOX VSI, you need to:



* The input.auto.tfvars file to customize the resources for your solution.



* Enter the floating IP and subnet information from the Bastion server.
* By default, the VSI is configured with:



* Red Hat Enterprise Linux® 7.x for SAP Applications (amd64),
* Two SSH keys that are configured to access as root user on SSH,
* Five storage volumes.



You can change the default settings to match your solution.
* You can change the default SAP system configuration settings to match your solution.
* You also specify the location where you downloaded the SAP kits.





The IBM Cloud Provider plug-in for Terraform on IBM Cloud uses these configuration files to provision a VPC in your IBM Cloud account.





 SAP Kits 

For each IBM Cloud region, IBM allocates temporary storage on a dedicated Jump host. It is your responsibility to download the necessary SAP and DB kits to your Deployment (Bastion) Server. All file archives are decompressed by Ansible during the automatic deploying process. For more information, see the readme file.





 Support - Schematics and Terraform 

There are no warranties of any kind, and there is no service or technical support available for these materials from IBM®. As a recommended practice, review carefully any materials that you download from this site before using them on a live system.

Though the materials provided herein are not supported by the IBM Service organization, your comments are welcomed by the developers, who reserve the right to revise, re-adapt or remove the materials at any time. To report a problem, or provide suggestions or comments, open a GitHub issue.





 Support - Catalog Tile 

The catalog tile offering is IBM Cloud supported.
This is for information to help you monitor trends in your usage. See [Choosing your plan](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-plan_choose) to determine what the recommended limits are for your plan and cluster.





 Connected clients software name and version 

The number of connected clients with a particular client software name and version.



Table 10. Connected clients software name and version metric metadata

 Metadata Description 

 Metric Name ibm_eventstreams_instance_connected_clients_software_name_and_version 
 Metric Type gauge 
 Value Type number 
 Segment By Client software name, Client software version 



This is for information to help you monitor the software name and version data of the active clients that are connected to the Event Streams instance.

Client software name and version are available for the Kafka client (Java version 2.4 or later, and other implementations that support software name and version) as described in [KIP-8855](https://issues.apache.org/jira/browse/KAFKA-8855). If the client software name and version are not available, these are set as unknown.





 Inactive consumer groups 

The number of inactive consumer groups in an Event Streams instance.



Table 11. Inactive consumer groups metric metadata

 Metadata Description 

 Metric Name ibm_eventstreams_instance_inactive_consumergroups 
 Metric Type gauge 
 Value Type none 
 Segment By Service instance, Service instance name 



This is for information only and is not an issue. Spikes indicate that a set of consumer groups stopped sending messages.





 Instance bytes in per second 

The number of bytes produced per second to an Event Streams instance.



Table 12. Instance bytes in per second metric metadata

 Metadata Description 

 Metric Name ibm_eventstreams_instance_bytes_in_per_second 
 Metric Type gauge 
 Value Type byte 
 Segment By Service instance, Service instance name 



This is for information to help you monitor trends in your usage of how many incoming or outgoing MB/s your clients are transferring to and from your cluster.
(https://cloud.ibm.com/docs-content/v1/content/a6478671e8f845a84102d9cf49bf28ee7f4f3227/security-compliance/images/kc-profile.svg)

Figure 2. Understanding profiles in the new architecture

Specification
: A statement that defines the specific security and privacy requirements that a control must meet. For example, Check whether App ID Cloud Directory users aren't able to update their own accounts.

Assessment
: The actual evaluation of a configuration for compliance with applicable standards. An assessment can be either automated or manual depending on the control. Currently, the only available type of assessment is an IBM Cloud rule.

Rule
: A set of conditional statements that are used to determine whether a resource configuration is in compliance. To evaluate a rule, you must associate it with a profile through an assessment.

Parameter
: The specific configuration property that is evaluated. Each parameter is assigned a value by default that can be customized when an attachment is created. For example, if a control evaluates which region that a resource exits in, you can specify the region that you want to check for by defining the parameter.

Scope
: The group of resources that you want to evaluate. In the new API-based architecture, a scope can be an Enterprise, Account group, Account, or Resource group.

Attachment
: The connection between a profile and scope that defines the way that Security and Compliance Center conducts an evaluation. An attachment is formed by selecting the grouping of resources that you want to evaluate and a profile. Then, you specify the parameters that you want to evaluate for. Attachments are evaluated once per day or can be initiated as needed.

Report
: The information that is returned by an evaluation is known as a report. For a breakdown of the information in the report, see [Understanding results](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-results).





 Understanding the user flow 

Now that you have an understanding of the various entities that exist within Security and Compliance Center, how do they work together?
A characteristic or trait of an entity that describes the entity; for example, the telephone number of an employee is one of the employee attributes.





 authentication (AuthN) 

The process of validating the identity of a user or server.





 AuthN 

See [authentication](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2014567).





 authorization (AuthZ) 

In computer security, the right granted to a user to communicate with or make use of a computer system.





 AuthZ 

See [authorization](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2014653).





 availability zone 

A location within a region that IBM Cloud Kubernetes Service runs in.







 B 



 bare metal server 

A dedicated, fully-customizable physical server that can be used for virtualization or web hosting.





 base image 

An image that has no parent image. See also [image](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2024928), [parent image](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx8439210).





 beta product 

A product that IBM makes available solely for evaluation and testing purposes. There are no warranties, SLAs or support provided and beta products are not intended for production use.





 bias detection 

The process of calculating fairness to metrics to detect when AI models are delivering unfair outcomes based on certain attributes.





 billing option 

The method by which a client is billed for cloud service usage. Examples include paying in advance, such as with subscriptions, and payment in arrears, as in Pay-As-You-Go accounts.





 billing unit 

The highest level billing entity within an enterprise. Each account or account group is linked to a billing unit, which manages all associated contracts, invoices, orders, and payments. A billing unit can contain one or more credit pools.
Not for the BGP session. We must assign our /30 from IPv4, and we need the same in return from you.
* Does IBM do IPV6 on the private network?

No. IPv6 is public only.
* Does Direct Link support any type of Quality of Service (QoS)?

We are unable to support any QoS guarantees. QoS requires MPLS mapping between each of our service suppliers and IBM Cloud. Cloud service providers generally cannot support QoS because it must reach from end-to-end and involve every device in between. No workaround is currently available by "tunneling" or any other method.
* Does Direct Link support Jumbo frames?

Jumbo frames (up to 9214 bytes) are supported on Direct Link Dedicated.
* How easy is it to upgrade the bandwidth of my Direct Link Dedicated connection, for example 1 - 5 GB?

Typically, IBM installs speeds of 1 GB and lower on 1 GB optics. For speeds of 2-10 GB, IBM installs 10 GB optics. As a result, an upgrade of 1-5 GB would require new optics to be assigned or inserted. It would be a service affecting event. If you anticipate that type of growth, it's possible to request 10 GB optical fibers to be installed at the beginning of your Direct Link deployment, or to order 2 GB initially so that the 10 GB optics are in place.
* Is ECMP the way to go for redundant Direct Link connections? What alternatives exist?

ECMP isn’t for redundant connections, but for balancing the load over the two links. With ECMP, both connections must terminate to the same IBM Cloud cross-connect router (XCR), which makes it a single point of failure. In other words, ECMP can be provisioned only as two sessions on the same IBM Cloud XCR.

ECMP is a feature of BGP. If you are looking for redundancy, you should get two Direct Link connections, one going into each XCR. If you want to use ECMP and have redundancy, you need two Direct Link connections on each XCR so that you can have 2 ECMP sessions running simultaneously.
Assigning access to resources by using access groups 

Get up and running quickly with IBM Cloud Identity and Access Management (IAM) by setting up access groups for quick access assignments, inviting users to your account, and managing their access.

This tutorial is for IAM-enabled resources. For classic infrastructure that doesn't support creating IAM policies for managing access, you can review the [classic infrastructure permissions](https://cloud.ibm.com/docs/account?topic=account-mngclassicinfra) documentation.



 Before you begin 

If you are new to using IAM, check out the following documentation to learn more about the features, concepts, and components of the access management system:



* [What is IBM Cloud Identity and Access Management?](https://cloud.ibm.com/docs/account?topic=account-iamoverview) provides a quick overview of what IAM is in IBM Cloud, the available features, and links to available CLI and API docs.
* [IAM access](https://cloud.ibm.com/docs/account?topic=account-userroles) gives a more in-depth review of how access management works by using access policies.







 Step 1: Create access groups 

To streamline the process of assigning access to users in your account, you can create an access group. Access groups are a way to organize users and service IDs so that you can easily assign access by adding one or more policies for the entire group. Then, you can add or remove users and service IDs as needed instead of assigning individual access to each user.

A unique name is required to differentiate access groups in the account.



 Set up your groups 

To create an access group, complete the following steps:



1. In the IBM Cloud console, click Manage > Access (IAM), and select Access Groups.
2. Click Create.
3. Enter a unique name to identify your access group and an optional description.
4. Click Create.



Next, continue to set up your group by adding users or service IDs:



1. Select the name of the group that you want to update.
2. Click Add users.
For information about downloading, installing, and configuring the HCMT tool, see [SAP Note 2493172 - SAP HANA Hardware and Cloud Measurement Tools](https://launchpad.support.sap.com//notes/2493172).





 SAP HANA overheads impact on available memory 

Every SAP HANA database server reserves a small allocation of memory for the operating system and other services required to operate.

SAP provide a rule of thumb for these overheads:



* Reserved for OS = 10% of the first 64GB + 3% of all remaining memory
* Reserved for SAP HANA services and caches = 50GB



The example below demonstrates the net capacity for SAP HANA when using 4TB Memory (DRAM) after the memory reservation overheads have been taken into consideration:



Table 1. Example of SAP HANA net capacity

 Physical Memory 4096 GB DRAM 

 Reserved for OS 127 GB 
 Available for SAP HANA 3969 GB 
 Reserved for SAP HANA services and caches 50 GB 
 Net capacity available for SAP HANA data + temporary disk space 3919 GB 



This is shown in more detail on [SAP Note 2296290 - New Sizing Report for SAP BW/4HANA](https://launchpad.support.sap.com//notes/2296290) under attachment SAPBW4HANA_Sizing_V2.6.4.pdf







 SAP HANA High Availability and Disaster Recovery (HA/DR) 

The first requirement for SAP HANA High Availability (HA) and Disaster Recovery (DR), is to use the correct Operating System (OS) add-ons for SAP High Availability. Be sure to discuss OS for SAP HA details with IBM Cloud Support before your deployment.

The OS supported and deployed by IBM Cloud for running SAP HANA with HA/DR are:



* Red Hat Enterprise Linux (RHEL)
* SUSE Enterprise Linux Server (SLES)



The IBM Cloud environment does not support any preconfigured high availability (HA) scenarios. It does, however, let you implement HA solutions for SAP HANA through Red Hat Enterprise Linux HA extensions, in a similar manner to existing deployments using Traditional On-Premises data centers.
Managing access overview 

Access to IBM Cloud Satellite® service instances for users in your account is controlled by IBM Cloud Identity and Access Management (IAM). Every user that accesses the Satellite service in your account must be assigned an access policy with an IAM role defined. The policy determines what actions a user can perform within the context of the service or instance that you select. The allowable actions are customized and defined by the IBM Cloud service as operations that are allowed to be performed on the service. The actions are then mapped to IAM user roles.

The name for the IBM Cloud Satellite service in IAM is



* IBM Cloud Satellite in the UI
* satellite in the API and CLI



Keep in mind that you need permissions to IBM Cloud services if you use the services with Satellite. For example, to create and manage clusters in your Satellite location, you must have the [appropriate permissions to Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-access_reference) in IAM (Kubernetes Service in the UI, containers-kubernetes in the API and CLI).



 Locations and hosts 

Review details about the Satellite location IAM resource type, which includes actions for locations and hosts.

If you scope an access policy to the location resource type, the users must target the regional endpoint to interact with the location. For more information, see the [troubleshooting topic](https://cloud.ibm.com/docs/satellite?topic=satellite-ts-location-missing-location).

Name of the resource type
: UI: Location
: API or CLI: location

Type of role that you can assign for the resource in IAM
: Platform access Viewer, Operator, Editor, and Administrator roles
: Custom service access role to create clusters, Satellite Cluster Creator

What you can scope an access policy for the resource to
: Account
: Resource group
: Particular instances of the resource

Description
: [Locations](https://cloud.ibm.com/docs/satellite?topic=satellite-locations) are places that you use to extend IBM Cloud by attaching your own host compute machines to the location.
Run the following command to check your working directory's Terraform modules for updates from the catalog and update the source attribute to the latest version. The README.md is also updated.

ibmcloud catalog utility update-module-references





 ibmcloud catalog offering unpublish account 

Run the following command to unpublish a product from your account. After the product is unpublished, users in your account cannot create an instance of the product.

ibmcloud catalog offering unpublish account [--catalog CATALOG]



 Command options 

--catalog CATALOG
: The catalog name or ID.

--offering OFFERING
: The product name or ID.







 ibmcloud catalog offering unpublish allowlist 

Run the following command to remove account IDs from the product's allowlist. Accounts that are removed from the allowlist cannot create an instance of the product.

ibmcloud catalog offering unpublish allowlist [--catalog CATALOG][--account-ids ACCOUNT-IDS]



 Command options 

--catalog CATALOG
: The catalog name or ID.

--offering OFFERING
: The product name or ID.

--account-ids ACCOUNT-IDS
: The account IDs.







 ibmcloud catalog offering unpublish enterprise 

Run the following command to unpublish a product from an enterprise. After the product is unpublished, the enterprise cannot create an instance of the product.

ibmcloud catalog offering unpublish enterprise [--catalog CATALOG]



 Command options 

--catalog CATALOG
: The catalog name or ID.

--offering OFFERING
: The product name or ID.







 ibmcloud catalog offering publish public 

Run the following command to publish your private offering to the IBM Cloud catalog for all users to see and use. To get to this step in the publication process, you must first publish the offering to your account and to all IBMers to complete the testing process. After your testing is complete, you can run this command.

This option requires approval. As soon as your approval is complete, your tile is available for all IBM Cloud customers.

ibmcloud catalog offering publish public [--catalog CATALOG]
If the ASCS service fails in a two-node cluster, it restarts on the node where ERS is running. The lock entries for the SAP application are protected when they rebuild from the copy of the lock table that's available in the ERS. When the failed cluster node reactivates, the ERS instance moves to the other node (anti-collocation) to protect the lock table copy.

It is recommended that you install the SAP database instance and other SAP application server instances on virtual server instances outside the two-node cluster for ASCS and ERS. For more information, see [Configuring SAP HANA Scale-Up System Replication in a RHEL HA Add-On cluster](https://cloud.ibm.com/docs/sap?topic=sap-ha-rhel-hana-sr).



 Overview 

The following information outlines the configuration of ASCS and ERS in a RHEL HA Add-On cluster with Red Hat Enterprise Linux 8.4 (RHEL) by using [IBM Power Systems Virtual Server](https://www.ibm.com/products/power-virtual-server) instances as cluster nodes.

For more information, see the following Red Hat knowledge base articles:



* [Configuring SAP S/4HANA ASCS/ERS with Standalone Enqueue Server 2 (ENSA2) in Pacemaker](https://access.redhat.com/articles/3974941)
* [Support Policies for RHEL High Availability Clusters - Management of SAP S/4HANA in a cluster](https://access.redhat.com/articles/4016901)







 Prerequisites 



* A [Red Hat Customer Portal](https://access.redhat.com/) account.
* An [IBM Cloud®](https://cloud.ibm.com/docs/account?topic=account-account-getting-started) account{: external}.
* A valid RHEL for SAP Applications or RHEL for SAP Solutions subscription is required to enable the repositories that you need to install SAP HANA and the resource agents for HA configurations.
* Virtual server instances need to fulfill the hardware and resource requirements for the SAP instances in scope.
See [Migrating Vyatta 5400](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-migration-overview) to get started.





 As a customer who owns a Vyatta 5400, what do I need to do by March 31, 2019? 

Customers who have a Vyatta 5400 should migrate to either VRA (Vyatta 5600), Juniper vSRX, or Fortigate Security Appliance (FSA) 10G. The VRA (Vyatta 5600) is still fully supported. There is no current or projected end of support date for the VRA from either IBM Cloud or AT&T. See [Migrating Vyatta 5400](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-migration-overview) to get started.

VRAs and vSRXs are customer managed devices.





 Is support available from IBM for migrating from the Vyatta 5400 to either the VRA, vSRX, or FSA 10G? 

The Vyatta 5400 to VRA (5600) Configuration Conversion Service is still available:



* For existing customers, IBM Cloud is providing a no-cost offering to assist with re-factoring your existing Vyatta 5400 configuration into IBM Cloud® Virtual Router Appliance (VRA), Juniper vSRX, or Fortigate Security Appliance (FSA) 10G formats. To submit a request for the Configuration Conversion service, send an email to nwom@us.ibm.com with the subject: Request for Configuration Conversion to aaaaaaaa: IBM Cloud Account ID xxxxxx..

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.
apiVersion <br><br> * For clusters that run Kubernetes 1.8 or later, use rbac.authorization.k8s.io/v1.<br> * For earlier versions, use apiVersion: rbac.authorization.k8s.io/v1beta1.<br><br><br> 
 metadata.namespace <br><br> * For kind RoleBinding: Specify the Kubernetes namespace to which access is granted.<br> * For kind ClusterRoleBinding: Don't use the namespace field.<br><br><br> 
 metadata.name Name the role binding or cluster role binding. 
 subjects.kind Specify the kind as one of the following:<br><br><br><br> * User: Bind the RBAC role or cluster role to an individual user in your account.<br> * Group: Bind the RBAC role or cluster role to an [IBM Cloud IAM access group](https://cloud.ibm.com/docs/account?topic=account-groupsgroups) in your account.<br> * ServiceAccount: Bind the RBAC role or cluster role to a service account in a namespace in your cluster.<br><br><br> 
 subjects.name <br><br> * For User: Append the individual user's email address to IAM as follows: IAMuser@email.com.<br> * For Group: Specify the name of the [IBM Cloud IAM access group](https://cloud.ibm.com/docs/account?topic=account-groupsgroups) in your account.<br> * For ServiceAccount: Specify the service account name.<br><br><br> 
 subjects.apiGroup <br><br> * For User or Group: Use rbac.authorization.k8s.io.<br> * For ServiceAccount: Don't include this field.<br><br><br> 
 subjects.namespace For ServiceAccount only: Specify the name of the Kubernetes namespace that the service account is deployed to.