vania-janet/multiturn-rag-retrieval-data huggingface dataset:
BI.S4.H4.6000 IBM Cloud Bare Metal (Local SDD) 92,160 Up to 16 nodes:   15 active nodes (1 parent, 14 worker nodes) and 1 standby node TDI OLAP 1,680 3,360 [OLAP Record](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN//solutions?filters=iaas&id=s:2213) [OLAP Scale-Out Record](https://www.sap.com/dmc/exp/2018-benchmark-directory//bwh?id=bm:44417c84-5010-4fae-9245-18e2cbd971d2) <br><br>[Certification #2020032](https://www.sap.com/dmc/benchmark/2020/Cert20032.pdf) 
 BI.S4.H8.6000 IBM Cloud Bare Metal (Local SDD) 92,160 Up to 16 nodes:  15 active nodes (1 parent, 14 worker nodes) and 1 standby node TDI OLAP 3,360 6,720 [OLTP Record](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN//solutions?filters=iaas&id=s:2305) [OLAP Scale-Out Record](https://www.sap.com/dmc/exp/2018-benchmark-directory//bwh?id=bm:e9958ccc-60c6-480f-82f0-59c00ac5f3ce) <br><br>[Certification #2021014](https://www.sap.com/dmc/benchmark/2021/Cert21014.pdf)
To enforce dual control, this must be at least 2:
> 1
3. Add [crypto unit administrators](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-understand-conceptsadmin-concept).

When prompted, enter the number of administrators that you want to add to the crypto units. The number needs to be equal to or greater than the signature threshold values that you set in the previous step.

The command then lists existing signature key files available on your workstation. You can create administrators by selecting the existing signature key files, or by generating new signature keys. The new signature key files are also saved in the directory that you specify with the CLOUDTKEFILES environment variable on your local workstation.

The following output is an example that is displayed:

ENTER NUMBER OF ADMINISTRATORS TO INSTALL

To initialize and maintain your crypto units, administrators must be installed. Each administrator has an associated signature key. Signature keys are stored in files protected by a password. To use the signature key, you must supply the password.

To enforce dual control, each signature key file needs to be assigned to a different user and only that user needs to know the password.

You can install up to eight administrators in a crypto unit. To set a signature threshold value of 1 and a revocation signature threshold of 1, you must install at least 1 administrator.

Enter the number of administrators you want to install:
> 1

SELECT EXISTING SIGNATURE KEY FILES TO USE

The following signature key files were found on this workstation:

KEYNUM DESCRIPTION SUBJECT KEY IDENTIFIER
1 admin1 665527ed7e97c2a083dab035f40c65...
2 admin2 741a60c0a875cd91195b71f6db3cb5...

Enter the KEYNUM of any existing signature key files you want to use to create administrators. If you don't want to use existing signature key files, press enter without entering any KEYNUM values.

If you want to use a combination of existing and new signature keys, enter the KEYNUM values of the existing signature key files you want to use.
BI.S4.H8.6000 IBM Cloud Bare Metal (Local SDD) 92,160 Up to 16 nodes:  15 active nodes (1 parent, 14 worker nodes) and 1 standby node TDI OLAP 3,360 6,720 [OLTP Record](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN//solutions?filters=iaas&id=s:2305) [OLAP Scale-Out Record](https://www.sap.com/dmc/exp/2018-benchmark-directory//bwh?id=bm:e9958ccc-60c6-480f-82f0-59c00ac5f3ce) <br><br>[Certification #2021014](https://www.sap.com/dmc/benchmark/2021/Cert21014.pdf) 
 BI.S4.H8.12000 IBM Cloud Bare Metal (Local SDD) 184,320 Up to 16 nodes:  15 active nodes (1 parent, 14 worker nodes) and 1 standby node TDI OLAP 3,360 6,720 [OLAP Record](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN//solutions?filters=iaas&id=s:2302) [OLAP Scale-Out Record](https://www.sap.com/dmc/exp/2018-benchmark-directory//bwh?id=bm:f050d27b-f541-4807-9df1-78aae4095661) <br><br>[Certification #2021065](https://www.sap.com/dmc/benchmark/2021/Cert21065.pdf)
If this happens, you can use the ibmcloud tke cryptounit-compare command to see how the crypto units are configured. If current master key registers are not set, you can zeroize the crypto units with the ibmcloud tke cryptounit-zeroize command and rerun the ibmcloud tke auto-init command.

You must not zeroize the crypto units if key storage for the service instance contains data. Otherwise, all data in key storage will be lost and you will be not able to access any keys or data in your service instance.
2. Set the value of two [signature thresholds](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-understand-conceptssignature-thresholds-concept): signature threshold and revocation signature thresholds.

When prompted, enter the number for the signature threshold first and then for the revocation signature threshold. The numbers must be between one and eight. The two threshold numbers can be different. Setting the signature thresholds to a value greater than one is a way to enforce [quorum authentication](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-understand-conceptsquorum-authenticaion-concept) for sensitive operations.

The following output is an example that is displayed:

ENTER SIGNATURE THRESHOLD VALUES

Enter the number of signatures to be required on commands sent to the service instance. This must be a number between 1 and 8. To enforce dual control, this must be at least 2:
> 1

Enter the number of signatures to be required on commands to remove an administrator. This must be a number between 1 and 8. To enforce dual control, this must be at least 2:
> 1
3. Add [crypto unit administrators](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-understand-conceptsadmin-concept).

When prompted, enter the number of administrators that you want to add to the crypto units. The number needs to be equal to or greater than the signature threshold values that you set in the previous step.
Acknowledge and agree to the terms and conditions.
6. Click Create.







 Step 2: Assign access 

If you are working in a larger organization, you might need to start by assigning access to those on your team who will be managing compliance.



1. [Create an access group](https://cloud.ibm.com/docs/account?topic=account-groupscreate_ag) and add your compliance focals.
2. In the Console, go to Manage > Access (IAM) > Access groups and click select the group that you want to assign access to. A new page opens with the details of the group.
3. Click Access > Assign access.
4. Assign the following permissions by selecting a service and reviewing the available roles and actions that are available for each option.





Table. Minimum required permissions

 Service Minimum required permissions 

 Security and Compliance Center Administrator 
 Cloud Object Storage Reader 
 Event Notifications Reader 
 Enterprise Administrator or custom role 



If you are working within an enterprise account and do not want to assign administrator access to your compliance focals, you can create [a custom role](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-assign-roles).





 Step 3: Configure storage 

Before you can start evaluating your resources for compliance, you must configure a Cloud Object Storage bucket where the service can forward your results data for long-term storage. For more information about bucket requirements, see [Storing and processing data in Security and Compliance Center](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-storage).

To connect your Cloud Object Storage bucket, you can use the Security and Compliance Center UI.



1. In the Security and Compliance Center navigation, click Settings.
2. On the Storage tile, click Connect.
3. Ensure that the service-to-service policy between Cloud Object Storage and Security and Compliance Center is configured. If a policy is already in place, this screen is not shown and you can skip to the next step.
4. Select an instance of Cloud Object Storage.
5.
Optional: Select the sequence on the canvas and rename it in Extractor Properties under General.
4. Optional: If needed, repeat steps 1 and 2 to add additional elements to the pattern.





 Sequence pattern example 

To select references to military personnel:



1. Create a dictionary called Military Ranks that includes terms such as Warrant Officer, Sergeant, and Lieutenant.
2. Drag the Person extractor onto the canvas following the Military Ranks dictionary to indicate that the new sequence finds ranks then names. The dark blue line after the Military Ranks extractor indicates placement of the Person extractor in the text pattern.

![Adding a Person extractor to the right side of Military Ranks extractor to create a sequence](https://cloud.ibm.com/docs-content/v1/content/50eddb8fd81f33092880335ff107a78ff5cd0f65/watson-knowledge-studio/images/military_ranks.png)

When you release the mouse button, a sequence object is displayed on the canvas.
3. Click the sequence object on the canvas and, under Extractor Properties, open the General tab. Rename the sequence object as Military Personnel.
4. The final extractor rule is displayed on the canvas.

![The Military Personnel sequence](https://cloud.ibm.com/docs-content/v1/content/50eddb8fd81f33092880335ff107a78ff5cd0f65/watson-knowledge-studio/images/military_personnel.jpg)







 Adding proximity rules 

Proximity rules to specify the maximum number of tokens that might occur between the desired terms. In text, each word or character is generally referred to as a token. The sentence "The CEO announced the earnings last week, missing analyst estimates by 5%." contains 15 tokens: 11 words separated by spaces, 3 special characters, and 1 number.

You might want to locate references to red brick houses, knowing that phrases such as house made of red brick, red house of brick and the brick on the house reflected red might appear in the text you are analyzing.
If you manually built your organization MSP with certificates from an external CA, the connection profile will not include any information in the "certificateAuthorities": section.







 Specifying an endorsement policy 

Every smart contract must have an endorsement policy, that is specified during instantiation. The endorsement policy specifies the set of organizations, the peers, on a channel that can execute the smart contract and independently validate the transaction output. For example, an endorsement policy can specify that a transaction is added to the ledger only if a majority of the members on the channel endorse the transaction. The organization that instantiates the smart contract can select from among the members who have installed the smart contract to become validators, and sets the endorsement policy for all channel members. You can update your endorsement policy by following the steps for [updating your smart contract](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-smart-contracts-v14ibp-console-smart-contracts-upgrade).

When you follow the steps to [instantiate a smart contract](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-smart-contracts-v14ibp-console-smart-contracts-instantiate), you can use the side panel to set a contract's endorsement policy after selecting the channel. Use this panel to specify a simple policy by selecting the peers that need to endorse the transaction from the list of peers that have installed the smart contract on the channel. You can use this method to specify an endorsement policy of all channel members, a majority of them, a single member, or a simple +1 preventing members from self-signing. The default endorsement policy is set to 1 of x, meaning that only a single member of the channel is required to endorse a smart contract transaction.

Click the Advanced button if you want to specify a policy in JSON format. You can use this method to specify more complicated endorsement policies, such as requiring that a certain member of the channel must validate a transaction, along with a majority of other members.
<tuv xml:lang="en"><seg>Adopted at the 81st plenary meeting, on 4 December 2000, on the recommendation of the Committee (A/55/602/Add.2 and Corr.1, para. 94),The draft resolution recommended in the report was sponsored in the Committee by: Bolivia, Cuba, El Salvador, Ghana and Honduras. by a recorded vote of 106 to 1, with 67 abstentions, as follows:</seg></tuv>
<tuv xml:lang="fr"><seg>Adoptée à la 81e séance plénière, le 4 décembre 2000, sur la recommandation de la Commission (A/55/602/Add.2, par. 94)Le projet de résolution recommandé dans le rapport de la Commission avait pour auteurs les pays suivants: Bolivie, Cuba, El Salvador, Ghana et Honduras., par 106 voix contre une, avec 67 abstentions, à la suite d'un vote enregistré, les voix s'étant réparties comme suit:</seg></tuv>
</tu>
. . .
</body>
</tmx>
Show more

The general improvements from parallel corpus customization are less predictable than the mandatory results you get from forced glossary customization. For example, consider the following translation unit from the example parallel corpus (lines 172-175).

<tu>
<tuv xml:lang="en"><seg>55/102. Globalization and its impact on the full enjoyment of all human rights</seg></tuv>
<tuv xml:lang="fr"><seg>55/102. La mondialisation et ses effets sur le plein exercice des droits de l'homme</seg></tuv>
</tu>

If you translate "55/102. Globalization and its impact on the full enjoyment of all human rights" with the base en-fr model, the service responds with the following translation.
* Default - 12
* Restarts database - YES
* Notes - The maximum number of simultaneously running WAL sender processes. The default, and minimum, is 12. One wal_sender per consumer is required. Twenty slots are reserved for internal use by your deployment for High-Availability (HA) purposes. You need to set the value above 20 and it is recommended to add one more wal_sender over the minimum per expected consumer. Using wal2json and not increasing max_wal_senders can impact HA and read-only replicas. If you are not using wal2json, leave this setting at the default.
SC-22 - Architecture and Provisioning for Name / Address Resolution Service 



  Control requirements 

SC-22 - 0
:   The information systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal/external role separation.





  NIST supplemental guidance 

Information systems that provide name and address resolution services include, for example, domain name system (DNS) servers. To eliminate single points of failure and to enhance redundancy, organizations employ at least two authoritative domain name system servers, one configured as the primary server and the other configured as the secondary server. Additionally, organizations typically deploy the servers in two geographically separated network subnetworks (i.e., not located in the same physical facility). For role separation, DNS servers with internal roles only process name and address resolution requests from within organizations (i.e., from internal clients). DNS servers with external roles only process name and address resolution information requests from clients external to organizations (i.e., on external networks including the Internet). Organizations specify clients that can access authoritative DNS servers in particular roles (e.g., by address ranges, explicit lists).
These CAs will also create the definition of each organization, which is encapsulated by a Membership Service Provider (MSP). A TLS CA is automatically deployed together with each organization CA and provides the TLS certificates that are used for communication between nodes. For more information, see [Using your TLS CA](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-identitiesibp-console-identities-tlsca).
* One ordering service:Ordering Service While deployments running on a paid cluster have the option to deploy either a single node ordering service or a crash fault tolerant five node ordering service, free clusters only have the option of running a single node. The crash fault tolerant five node ordering service uses an implementation of the Raft protocol (for more information about Raft, see [The Ordering Service](https://hyperledger-fabric.readthedocs.io/en/release-2.2/orderer/ordering_service.htmlraft) and is the deployment option this tutorial will feature. This ordering service will add peer organizations to its "consortium", which is the list of peer organizations that can create channels. Currently, only one ordering service organization per ordering service is supported, regardless of the number of ordering nodes associated with that organization. This ordering service will add peer organizations to its "consortium", which is the list of peer organizations that can create and join channels. If you want to create a channel that has organizations deployed in different clusters, which is how most production networks will be structured, the ordering service admin will need to import a peer organization that has been deployed in another console into their console. This allows the peer organization to join the channel that is hosted on that ordering service.
* Two peers:Peer Org1 and Peer Org2
The ledger, Ledger x in the illustration above, is maintained by distributed peers. These peers are deployed with [Couch DB](https://hyperledger-fabric.readthedocs.io/en/release-2.2/couchdb_as_state_database.html)) as the state database in a separate container associated with the peer. This database holds the current value of all "state" (as represented by key-value pairs).
[Spreading ordering nodes across countries](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/data_res_4.png)

Figure 6. Org C and Org D create a Channel Y using ordering nodes only located in Germany. All data is stored in the country on Ledger Y.

In Figure 6, the ordering nodes that participate in the Raft ordering service are spread across the two countries. Two ordering nodes are located in the United States, and three ordering nodes are in Germany for a total of five ordering nodes. When Channel X is created, all five ordering nodes are included in the consenter set, which would not meet a data residency requirement as the ledger data is spread across both countries. Channel Y however only includes the three ordering nodes that reside in Germany, which guarantees that all ledger data for this channel stays in country. A minimum of three ordering nodes is recommended because this configuration allows for one node to go down and two nodes to be available to maintain "quorum", the minimum number of nodes that must be available (out of the total number) for the ordering service to process transactions. A more robust configuration would be to include five ordering nodes in Germany for Channel Y, which means that two nodes could go down without losing quorum.

The easiest way to achieve this configuration is to spread the ordering nodes across Kubernetes clusters in different regions, a process that is described in the [Setting up multiregion High Availability (HA) deployments for the ordering service](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-hadr-mr-os) tutorial.





 Considerations around using the IBM Blockchain Platform console 

When you create an IBM Blockchain Platform service instance in IBM Cloud, you need to link the service instance to your Kubernetes cluster on IBM Cloud. No ledger data is ever transmitted to the blockchain service instance that is running in IBM Cloud.

When you use your console to view the channel details, ledger data is visible in your browser.
* IaaS certification based on the same benchmark certification example: 16 scale-out nodes which includes 15 Active nodes (1 Parent + 14 Child nodes) + 1 Standby node; using infrastructure with 6,144 GB DRAM for total memory of 92,160 GB





The following table provides examples of how these benchmarks could be inferred to help the business perform sizing decisions for SAP BW/4HANA:



Table 1. Examples of inferring benchmark results into sizing decisions

 Benchmark data point: <br>(by sequence shown in benchmark reports) Phase 1: Data load (seconds) Phase 2: Query executions per hour Phase 2: Records selected Phase 3: Runtime of complex query phase (seconds) 

 Measurement interpretation: Lower is better Higher is better Higher is better Lower is better 
 Benchmark impacting factors: Impacted by quantity of initial records to load Impacted by number of records selected in Phase 2 Impacted by number of records selected in Phase 2 
 <br><br> * <br><br><br> <br><br> * <br><br><br> <br><br> * <br><br><br> <br><br> * <br><br><br> <br><br> * <br><br><br> 
 Example comparison calculation for infrastructure selections (attempts to account for the impacting factors): Seconds to load 1 billion records might help comparisons of read from storage <br> <br>(for example, divide Phase 1 data load in seconds by initial records) Total records parsed per hour during Query Execution might help comparisons of calculations performed by CPU <br> <br>(for example, multiply query executions per hour by records selected) Total records parsed per minute during complex query might help comparisons of calculations performed by CPU <br> <br>(for example, divide records selected by runtime of complex query seconds, then multiply by 60) 



Additional SAP Notes regarding SAP BW/4HANA and sizing for scale-out:



* [SAP Note 2296290 - New Sizing Report for SAP BW/4HANA](https://launchpad.support.sap.com//notes/2296290)
volume_iops Number to represent the IOPS (Input Output Per Second) configuration for block storage to be used for the NFS storage node (valid only for volume_profile=custom, dependent on volume_capacity. Enter a value in the range 100 - 48,000). For more information, see [Custom IOPS profile](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-profiles&interface=uicustom). No 100 
 volume_profile Name of the block storage volume type to be used for the NFS storage node. For more information, see [Block storage profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-profiles). No general-purpose 
 worker_nodes_per_zone The number of worker nodes per zone in the default worker pool. Minimum is one node, and 1,000 is the maximum for each zone. For more information, see [Planning your worker node setup](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodes). No 1 
 worker_pool_flavor The flavor of the Red Hat OpenShift worker nodes that you want to create and attach to the cluster. For more information, see [Available flavors for VMs](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesvm-table). No bx2.4x16
ux2d-8x224 /hana/shared hana_shared_lv 224 hana_vg vde 1,120 
 /hana/data hana_data_lv 672 
 /hana/log hana_log_lv 224 
 ux2d-16x448 /hana/shared hana_shared_lv 448 hana_vg vde 2,240 
 /hana/data hana_data_lv 1,344 
 /hana/log hana_log_lv 448 
 ux2d-36x1008 /hana/shared n/a n/a vdd 1,008 
 /hana/data hana_data_lv 2,016 hana_data_vg vde 1,008 
 vdf 1,008 
 /hana/log hana_log_lv 576 hana_log_vg vdg 192 
 vdh 192 
 vdi 192 
 ux2d-48x1344 /hana/shared n/a n/a vdd 1,344 
 /hana/data hana_data_lv 2,700 hana_data_vg vde 1,350 
 vdf 1,350 
 /hana/log hana_log_lv 576 hana_log_vg vdg 192 
 vdh 192 
 vdi 192 
 ux2d-72x2016 /hana/shared n/a n/a vdd 2,016 
 /hana/data hana_data_lv 4,096 hana_data_vg vde 1,024 
 vdf 1,024 
 vdg 1,024 
 vdh 1,024 
 /hana/log hana_log_lv 576 hana_log_vg vdi 192 
 vdj 192 
 vdk 192 
 ux2d-100x2800 /hana/shared n/a n/a vdd 2,800 
 /hana/data hana_data_lv 8,400 hana_data_vg vde 2,100 
 vdf 2,100 
 vdg 2,100 
 vdh 2,100