vania-janet/multiturn-rag-retrieval-data huggingface dataset:
hpcs uko managed-key-sync 

Sync a managed key in keystores.

ibmcloud hpcs uko managed-key-sync --id ID --uko-vault UKO-VAULT --if-match IF-MATCH



* Command options

--id (string)
: Required. The UUID of the key. You can use the ibmcloud hpcs uko managed-keys command to retrieve the key UUID.

--uko-vault (string)
: Required. The UUID of the vault where the update is to take place. You can use the ibmcloud hpcs uko vaults command to retrieve the vault UUID.

--if-match (string)
: Required. The precondition of the update, which is the value of the ETag from the header on a GET request. You can use the ibmcloud hpcs uko managed-key command to retrieve the ETag.
* Example

ibmcloud hpcs uko managed-key-sync 
--id=b28bf13d-f49d-4b00-8b8d-457d38ad1e15 
--uko-vault=eb66ebbd-7230-4cde-89bf-17282cda5faa 
--if-match=2022-05-27T10:14:13Z 
--output json
* Output

The command returns the output similar to the following example:

{
"status_in_keystores": [
{
"keystore": {
"id": "b28bf13d-f49d-4b00-8b8d-457d38ad1e15",
"name": "AWS KMS Keystore Name",
"type": "aws_kms",
This ansible execution makes sure that the host for workload services acts as an NFS server and awscli package is installed.





 Setting up NTP proxy and forwarder 



1. Ensure all required ports in the security group in IBM Cloud VPC for workload services that are used by host for private services are open. The needed ports are configured for private services. Required port for NTP forwarder is: 123 (TCP).
2. Log in to the workload services instance. SSH command example:

ssh -A -o ServerAliveInterval=60 -o ServerAliveCountMax=600 -o ProxyCommand="ssh -W %h:%p root@<access_host_floating_ip>" root@<workload_services_host_private_ip>
3. Make sure that the required NTP software is available. On SUSE: zypper update -y; zypper install -y chrony. On RHEL: yum update -y; yum install epel-release; yum install -y chrony.
4. Modify file '/etc/chrony.conf' and add following lines. Replace <pvs_mgmt_cidr> with Power Systems Virtual Server management CIDR block (network segment)

local stratum 10
manual
allow <pvs_mgmt_cidr >
5. Enable and start chrony service: systemctl stop chronyd; systemctl start chronyd; systemctl enable chronyd;.







 Setup NTP proxy or forwarder -- Ansible 

To perform previous steps through ansible automation, download ansible-galaxy collection ibm.power_linux_sap.

ansible-galaxy collection install ibm.power_linux_sap

After the ansible collection is installed, to set up proxy, update the variable file playbook/vars/sample_services_variable_file.yml.

server_config: {
ntp: { enable: true }
}

After the file is updated, run the following ansible-playbook command.
For example, if did not select any advanced options in the console and you want to deploy the ordering nodes with your own value for the ServerTimeout and the statsd address port, you would paste the following JSON into the Configuration JSON box:

{
"General": {
"Keepalive": {
"ServerTimeout": "60s"
}
},
"metrics": {
"statsd": {
"address": "127.0.0.1:9446"
}
}
}





 Modifying ordering node settings after deployment 

After an ordering node is deployed, a subset of the fields can be updated as well. Click the ordering service tile in the console and select the ordering node, then click the Settings icon to open a side panel where you can modify the JSON. The JSON in the Current configuration box contains the current settings for the ordering node. Not all of these values can be overridden after deployment. Again, you don't need to include the entire set of parameters from the Current configurationJSON, only paste the parameters you want to override into the Configuration JSON box.

The following list of parameters can be updated:

{
"General": {
"Keepalive": {
"ServerMinInterval": "60s",
"ServerInterval": "7200s",
"ServerTimeout": "20s"
},
"Authentication": {
"TimeWindow": "15m"
}
},
"Debug": {
"BroadcastTraceDir": null,
"DeliverTraceDir": null
},
"Metrics": {
"Provider": "disabled",
"Statsd": {
"Network": "udp",
"Address": "127.0.0.1:8125",
"WriteInterval": "30s",
"Prefix": null
}
}
}
Show more
"minInterval": "60s",
"client": {
"interval": "60s",
"timeout": "20s"
},
"deliveryClient": {
"interval": "60s",
"timeout": "20s"
}
},
"gossip": {
"useLeaderElection": true,
"orgLeader": false,
"membershipTrackerInterval": "5s",
"maxBlockCountToStore": 100,
"maxPropagationBurstLatency": "10ms",
"maxPropagationBurstSize": 10,
"propagateIterations": 1,
"propagatePeerNum": 3,
"pullInterval": "4s",
"pullPeerNum": 3,
"requestStateInfoInterval": "4s",
"publishStateInfoInterval": "4s",
"stateInfoRetentionInterval": null,
"publishCertPeriod": "10s",
"skipBlockVerification": false,
"dialTimeout": "3s",
"connTimeout": "2s",
"recvBuffSize": 20,
"sendBuffSize": 200,
"digestWaitTime": "1s",
"requestWaitTime": "1500ms",
"responseWaitTime": "2s",
"aliveTimeInterval": "5s",
"aliveExpirationTimeout": "25s",
"reconnectInterval": "25s",
"election": {
"startupGracePeriod": "15s",
"membershipSampleInterval": "1s",
"leaderAliveThreshold": "10s",
"leaderElectionDuration": "5s"
},
For more information about customizing your Tuned profile, see [Node Tuning Operator](https://docs.openshift.com/container-platform/4.7/scalability_and_performance/using-node-tuning-operator.html) docs.

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
name: tuned-node
namespace: openshift-cluster-node-tuning-operator
spec:
profile:
- data: 
[main]
summary=Custom OpenShift node profile for my workloads
include=openshift-control-plane
[sysctl]
kernel.sem="250 1024000 200 32768"
kernel.msgmax="65536"
kernel.shmmni="32768"
name: openshift-node-parms
recommend:
- match:
- label: node-role.kubernetes.io/master
priority: 10
profile: openshift-node-parms
Show more
2. Create the custom tuned-node profile in your cluster.

oc apply -f tuned-node.yaml



The oc debug pods do not have access to retrieve worker node tuned profile settings. To retrieve or verify the updated worker node settings, you must be logged into a pod that has hostIPC: true.





 Modifying worker node kernel settings 

If you have specific performance optimization requirements, you can change the default settings for the Linux kernel sysctl parameters on worker nodes.

Worker nodes are automatically provisioned with optimized kernel performance, but you can change the default settings by applying a custom [Kubernetes DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) with an [init Container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) to your cluster. The daemon set modifies the settings for all existing worker nodes and applies the settings to any new worker nodes that are provisioned in the cluster.
For more information, see [Using dedicated hosts](https://cloud.ibm.com/docs/hpc-spectrum-symphony?topic=hpc-spectrum-symphony-using-dedicated-hosts). Further improvements include an update of the stock images that are used for login and storage nodes to RHEL 8.2 and clean up of entitlement and location input properties. Parallelism is now supported in Schematics destroy operations to help overall performance, and due to a bug fix, you can now avoid the Terraform warning regarding interpolation.







 October 2021 



 18 October 2021 

Introducing IBM Spectrum Symphony for HPC workloads
: You can now use IBM Spectrum Symphony as a workload manager with automated deployment of HPC clusters. The clusters are configured for auto scaling and use the cluster compute node configuration that you select.
To reregister the previous primary as new secondary use the following commands.

On NODE1, run the following command.

sudo -i -u ${sid}adm -- <<EOT
hdbnsutil -sr_register --name=${DC1} --remoteHost=${NODE2} --remoteInstance=00 --replicationMode=sync --operationMode=logreplay
EOT

Verify the system replication status:

sudo -i -u ${sid}adm -- <<EOT
hdbnsutil -sr_state
HDBSettings.sh systemReplicationStatus.py
EOT

After the manual register and resource refreshes, the new secondary instance restarts and shows up in status synced (SOK).

On NODE1, run the following command.

pcs resource refresh SAPHana_${SID}_${INSTNO}

pcs status --full







 Test2 - Testing failure of the node that is running the primary database 

Use the following information to test the failure of the node that is running the primary database.



 Test2 - Description 

Simulate a crash of the node that is running the primary HANA database.





 Test2 - Preparation 

Make sure that Cluster Resource SAPHana_${SID}_${INSTNO} is configured with AUTOMATED_REGISTER=true.

On NODE1, run the following command.

pcs resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true

pcs resource config SAPHana_${SID}_${INSTNO}





 Test2 - Prerequisites 



* A functional two-node RHEL HA Add-On cluster for HANA system replication.
* Both nodes active.
* Cluster is started on NODE1 and NODE2.
* Check SAP HANA System Replication status.



* Primary SAP HANA database is running on NODE2
* Secondary SAP HANA database is running on NODE1
* HANA System Replication is activated and in sync









 Test2 - Test procedure 

Crash primary on NODE2 by sending a shutoff system request.

On NODE2, run the following command.
Scale it down to zero to stop the node.
3. Restore the node from the backup.



First, get the list of deployments:

kubectl get deployments

As before, this produces a list of nodes and their persistent volumes similar to this example:

NA.M.E READY UP-TO-DATE AVAILABLE AGE
ibp-operator 1/1 1 1 48d
orderer1node1 1/1 1 1 20h
orderer2node1 1/1 1 1 22h
orderer3node1 1/1 1 1 22h
orderer4node1 1/1 1 1 22h
orderer5node1 1/1 1 1 22h
ordererorgca 1/1 1 1 48d
peera 1/1 1 1 20h
peerc 1/1 1 1 20h
peerorg1ca 1/1 1 1 48d

Then scale down the node by setting the replicas value to 0.

kubectl patch <component> <componentName> --type merge --patch '{"spec":{"replicas":0}}' -n <namespace>

Where <component> is one of: ibppeer, ibporderer, or ibpca.

In this example, scale down peera:

kubectl patch <ibppeer> peera --type merge --patch '{"spec":{"replicas":0}}' -n n3392fd

Then look at your deployments again to make sure that the peer is scaled down:

kubectl get deployments

You'll receive a response similar to:

NA.M.E READY UP-TO-DATE AVAILABLE AGE
ibp-operator 1/1 1 1 48d
orderer1node1 1/1 1 1 20h
orderer2node1 1/1 1 1 22h
orderer3node1 1/1 1 1 22h
orderer4node1 1/1 1 1 22h
orderer5node1 1/1 1 1 22h
ordererorgca 1/1 1 1 48d
For more information, see the [Databases for EnterpriseDB Roles and Privileges](https://cloud.ibm.com/docs/databases-for-enterprisedb?topic=databases-for-enterprisedb-user-management) page.







 Resyncing a Read-only Replica in the UI 

If you need to resync a read-only replica, click the Resync Read-Only Replica button. Resyncing is a disruptive operation and performing a resync tears down and rebuilds the data in the read-only replica. The read-only replica is not able to perform any other operations or run any queries while a resync is running. Queries are not rerouted to the leader, so any connections to the read-only replica fail until it is finished resyncing.

The amount of time it takes to resync a read-only replica varies, but the process can be long running.





 Resyncing a Read-only Replica in the CLI 

To start a resync through the CLI, use the [cdb read-replica-resync](https://cloud.ibm.com/docs/databases-cli-plugin?topic=databases-cli-plugin-cdb-referenceread-replica-resync) command.

ibmcloud cdb read-replica-resync <deployment name>

The amount of time it takes to resync a read-only replica varies, but the process can be long running.





 Resyncing a Read-only Replica in the API 

To start a resync through the API, send a POST to the [/deployments/{id}/remotes/resync](https://cloud.ibm.com/apidocs/cloud-databases-apiresync-read-only-replica) endpoint.

curl -X POST https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/remotes/resync -H 'Authorization: Bearer <>'





 Promoting a Read-only Replica in the UI 

A read-only replica is able to be promoted to an independent cluster that can accept write operations as well as read operations.
Configuring an active-passive NFS server in a Red Hat High Availability cluster 

Use the following information to configure an active-passive NFS server in a Red Hat High Availability cluster.



 Overview 

The following information describes the configuration of an active-passive NFS server in a RHEL HA Add-On cluster with Red Hat Enterprise Linux 8 by using virtual server instances in [Power Systems Virtual Server](https://www.ibm.com/products/power-virtual-server) as cluster nodes.

The instructions are based on the following Red Hat documentation:



* [Configuring an active-passive NFS server in a Red Hat High Availability cluster](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-active-passive-nfs-server-in-a-cluster-configuring-and-managing-high-availability-clustersdoc-wrapper)
* [How to configure HA-LVM Cluster by using system_id in RHEL 8](https://access.redhat.com/solutions/3796221)



The described setup uses shareable storage volumes that are accessible on both cluster nodes. The file systems for the NFS exports are created on those shareable storage volumes. HA-LVM makes sure that the volume group is active on one node at a time.

In the example setup, one shared volume group nfssharevg contains three logical volumes nfssharelv, sap${SID}lv, and saptranslv. XFS file systems are created on those logical volumes and are mounted on /nfsshare, /nfshare/export/sap${SID}, /nfsshare/export/saptrans.





 Prerequisites 



* A [Red Hat Customer Portal](https://access.redhat.com/) account.
* An [IBM Cloud account](https://cloud.ibm.com/docs/account?topic=account-account-getting-started).
ELM is configured by the IBM Cloud for VMware Solutions automation when a secondary instance is deployed.





 Cross vCenter NSX 

In cross-vCenter NSX, you have a primary NSX Manager and multiple secondary NSX managers. Each of these NSX managers is linked to a separate vCenter Server. On the primary NSX Manager, you can create universal NSX components such as switches and routers that are viewable from the secondary NSX managers.

Cross-vCenter NSX includes the following features:



* The same logical networks are available in the cross-vCenter environment, so it's possible for VMs on any cluster on any vCenter Server system to be connected to the same logical network.
* Firewall rules are managed from one centralized location, and apply to the VM regardless of location or vCenter Server system.
* Centralized management of universal objects, reducing administration effort.
* VMs can be migrated by using vMotion across vCenter Servers without having to reconfigure the VM or change firewall rules.



When cross-vCenter NSX is combined with ELM, you can view and manage any of the NSX managers and all of the universal NSX components from any of the linked vCenter Servers. ELM is not a prerequisite or requirement for cross-vCenter NSX. Without ELM, you can still create cross-vCenter universal transport zones, universal switches, universal routers, and universal firewall rules. However, without ELM in place, you must log in to the individual vCenter Servers to access each NSX Manager instance.

Cross vCenter NSX is not automatically deployed. You must deploy it manually by following the tasks in [Configuring the primary NSX manager](https://docs.vmware.com/en/VMware-NSX-Data-Center-for-vSphere/6.4/com.vmware.nsx.cross-vcenter-install.doc/GUID-0B74FB40-1D90-4A6A-B7CE-B4EF3B923452.html).





 Active Directory, SSO, and DNS in a multisite topology
* Network that is used in production



However, in the simplest scenario there might be one private network for all purposes. It depends on business requirements.



 Additional management systems to enable SAP systems 

Depending on your operating system, SAP workload, and network connectivity, you might need to configure access to many more SAP and non-SAP systems. The following is a list of various management systems that your SAP workloads might require to operate:



* OS packages update server, with the different subscription channels of the OS packages for SAP HANA and SAP NetWeaver.



* For IBM Power Systems Virtual Servers, you can use publicly available AIX SUMA or SUSE update repositories, or use your own AIX NIM or SUSE RMT servers. To avoid a common issue that occurs when you use the AIX NIM service handler, see [Using the NIM service handler](https://cloud.ibm.com/docs/sap?topic=sap-power-vs-aix-nwpower-vs-aix-nw-nim_service_handler).



* Software and patches download server. When the software is downloaded onto the server, you can use various protocols to transfer the files such as SCP or SFTP to transfer the software to the target server for installation.
* Time server (NTP), using NTP on IBM Cloud private backbone, public internet NTP or private NTP host.



* For IBM Power Systems Virtual Servers, see [Configuring the NTP client](https://cloud.ibm.com/docs/sap?topic=sap-power-vs-sles-hanapower-vs-sles-hana-ntp_time_server) (Linux) or [Configuring the NTP client](https://cloud.ibm.com/docs/sap?topic=sap-power-vs-aix-nwpower-vs-aix-nw-ntp_time_server_netweaver) (AIX).



* Gateway (and Proxy) and Firewall hosts
* Bastion/Jump host. Enables secured pass-through to your Cloud resources from public internet or other network access; often this uses tightly secured SSH on a non-default port.
* Jump host that is enabled with VNC or RDP.
! ,
"enabled": true
},
"type": "postgres"
}
"registry": {
"maxenrollments": -1,
"identities":
{
"name": "admin",
"pass": "adminpw",
"type": "admin",
"affiliation": "",
"attrs": {
"hf.Registrar.Roles": "",
"hf.Registrar.DelegateRoles": "",
"hf.Revoker": true,
"hf.IntermediateCA": true,
"hf.GenCRL": true,
"hf.Registrar.Attributes": "",
"hf.AffiliationMgr": true
}
}
}
}
}
}'
Show more
<-- </section "id="section-create-a-high-availability-ca" "> --><-- <section "id="section-deploy-a-node-that-uses-an-hsm" "> --> Deploy a node that uses an HSM IBM Blockchain Platform allows you to deploy CA, peer, or orderer nodes that use an HSM to store their private key. To use an HSM with your blockchain network, you need to first set up an HSM on IBM Cloud or in your own environment. You then need to set up a PKCS 11 proxy that allows your nodes to communicate with your HSM. You can then create a node with the private key that is stored in an HSM partition by providing the HSM endpoint along with the slot key and pin before the node is deployed. For more information, see Configuring a node to use an HSM]] .If you are using the APIs to deploy a node, you need to provide the HSM endpoint to the HSM field of the API call.
For cloud-object-storage.bucket-replication.create events, the following fields provide extra information:



 Field Description 

 requestData.replication.num_sync_remote_buckets The number of target buckets specified in the bucket replication rules. 
 requestData.replication.failed_remote_sync The CRNs of the buckets that failed the replication check. 



When replication is active, operations on objects may generate the following extra information:



 Field Description 

 requestData.replication.replication_throttled Indicates if the replication of the object was delayed on the source due to a throttling mechanism. 
 requestData.replication.destination_bucket_id The CRN of the target bucket. 
 requestData.replication.sync_type The type of sync operation. A content sync indicates that the object data and any metadata was written to the target, a metadata sync indicates that only metadata was written to the target, and a delete sync indicates that only delete markers were written to the target. 
 responseData.replication.source_bucket_id The CRN of the source bucket. 
 responseData.replication.result Values can be success, failure (indicates a server error), user (indicates a user error). 
 responseData.replication.message The HTTP response message (such as OK). 



You can trace an object from when it is written to the source until it is written on the target. Search for the request ID associated with the object write and three events should appear:



* The original PUT.
* The sync request from the source.
* The PUT request on the target.



Any of these three missing indicates a failure.





 Usage and accounting 

All replicas are objects themselves, and [contribute usage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-billing) just like any other data. Successful replication results in billable PUT, GET, and HEAD requests, although any bandwidth consumed in the replication process is not billed.

Replication generates additional metrics for use with IBM Cloud Monitoring:



* ibm_cos_bucket_replication_sync_requests_issued
* ibm_cos_bucket_replication_sync_requests_received







 Interactions 



 Versioning
For more information on how to do this with the APIs, see [Creating a node within a specific zone](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-apisibp-v2-apis-zone).

If multizone-capable storage is configured for your Kubernetes cluster, when a zone failure occurs, the nodes can come up in another zone with their associated storage intact, ensuring high availability of the node. In order to leverage this capability with the IBM Blockchain Platform, you need to configure your cluster to use SDS (Portworx) storage. And when you deploy a peer, select the advanced deployment option labeled Deployment zone selection and then select Across all zones. To learn more about multizone-capable storage, see the Comparison of persistent storage options for multizone clusters on [OpenShift](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_planningpersistent_storage_overview) or [IBM Cloud Kubernetes service](https://cloud.ibm.com/docs/containers?topic=containers-storage_planningpersistent_storage_overview).





 Sizing a peer during creation 

The peer pod has four containers that can be adjusted:



* Peer container: Encapsulates the internal peer processes (such as validating transactions) and the blockchain (in other words, the transaction history) for all of the channels it belongs to. Note that the storage of the peer also includes the smart contracts that are installed on the peer.
* CouchDB container: Where the state databases of the peer are stored. Recall that each channel has a distinct state database.
* Smart contract container: Recall that during a transaction, the relevant smart contract is "invoked" (in other words, run). Note that all smart contracts that you install on the peer will run in a separate container inside your peer pod, which is known as a Docker-in-Docker container.
* Smart contract launcher container: Used to launch a separate pod for each smart contract, eliminating the need for a Docker-in-Docker container in the peer pod.