vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* The client is responsible for providing in–depth documentation at the time of a failure and responding timely to IBM Support when further clarification is needed.
* Clients are also responsible for following the guidelines set forth in this document to grant consent to proactive support.
* By declining consent or failing to abide by the guidelines provided, the client assumes the responsibility of possible lag in problem resolution, which might be caused by communication delays between the client and support team.
* The client should be prepared to perform more technical troubleshooting that would otherwise be done by IBM Support. IBM will provide appropriate documentation and assistance where necessary.







 Security measures 



* Management of Cloud Service - Client is responsible for managing administration, operation, maintenance, and security of the applications, including underlying middleware.
* Service Integrity and Availability - IBM will forward to the Client all network intrusion notifications detected for this Cloud Service. It is the Client’s responsibility to ascertain the impact of each notification that is reported. Client will be notified of hardware failures. Monitoring and responding to OS or software failures is the responsibility of the Client, engaging IBM support as required.
* Activity Logging - Client is responsible for activity logging of OS/System and Database/Applications, as needed.
* Encryption - Client is responsible for configuring and managing all encryption (for both data at rest and in transit), as needed.
* Business Continuity and Disaster Recovery - Client is responsible for configuring and managing all business continuity and disaster recovery processes, as needed.







 Third-party services 



* Third-Party software or code is included or bundled with some of our IBM offerings. This code is included for your convenience but is not considered part of the IBM program.
* These non–IBM programs are licensed directly by their providers. Client agrees to use the non–IBM programs under the provider’s terms and conditions. These terms are provided in the IBM licensing agreement that accompanies the IBM offering at time of purchase.
* IBM does testing to ensure that the third-party products work with IBM programs and that they function correctly.
* IBM Support will diagnose client's problems by using the knowledge of how IBM offerings work with the Third-Party software.
Recovery Point Objective (RPO) and Recovery Time Objective (RTO) depend on many variables. Therefore, the VMware Regulated Workloads dual region design provides no standard Service Level Agreement (SLA) for RPO or RTO. However, review the following information about RPO and RTO:



* The VMware vSphere clusters in the recovery region are provisioned and are available to run workloads as soon as these workload VMs are started after DR invocation.
* The core management components in the recovery region (vCenter Server and the NSX-T™ Manager cluster) are running, so there is no infrastructure deployment wait time.
* The recovery infrastructure is being monitored and compliant through the management toolset, that is, VMware Aria® Operations™ and Caveonix RiskForesight, so that the recovery infrastructure resources are healthy, compliant, and ready to be used.
* The design describes the availability and recovery of the management components, and the technology that is used to accomplish this design can also be used for the workloads, if required. Alternatively, other products can be used for the workloads as required to meet the client's RTO/RPO application requirements.
* The design does not limit options for DR approaches for the workloads. For example, the client's requirements can define the use of the same or different IP addressing in DR or the use of replication or backup and restore for the recovery of these workloads. Most technologies include the ability to restore to multiple restore points so that the client can roll back to "known good" configuration when malware attacks occur.







 Design overview 

The VMware Regulated Workloads dual region design incorporates a number of design decisions that are justified by design simplicity, maximizing the VMware Regulated Workloads instance deployment automation, and minimizing the restrictions upon DR of the workloads. The recovery of management workloads and customer workloads is considered to be independent and this design focuses on the recovery of these management components. Customer workloads can be recovered by similar methods or by using different tools.

Zoom

!
* The use case for the extra policies
* Information on all efforts taken to follow the [Best practices for organizing resources and assigning access](https://cloud.ibm.com/docs/account?topic=account-account_setuphow_access) to reduce the number of policies on the account
* Account ID
* Note how many extra policies in the account are required
* If you are requesting an increase per subject, note how many extra policies per subject are required
* If you are requesting an increase of policies with access management tags, note how many extra policies with access management tags are required
* An estimate of when you expect or plan to create extra policies



You are notified of the update to your policy limits through the case.
For more information about cross-region disaster recovery, see [High availability and disaster recovery](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-ha-dr).





 Step 3: Add administrators to the selected crypto units 

The command to load a master key must be signed by an administrator that is predefined to the crypto unit. This step predefines an administrator.



1. Select the Administrators tab. This tab displays a list of administrators that are allowed to sign commands to the crypto unit.
2. Click Add administrator.
3. When prompted, insert the EP11 smart card that holds that administrator signature key in smart card reader 1, and enter the PIN on the smart card reader PIN pad.



The public signature key and administrator name are read from the smart card and installed in the crypto unit. When the operation is done, the administrator's name is displayed in the ADMIN NAME field of the selected crypto units.

For security and compliance reasons, the administrator name of the crypto unit might be shown up in logs for auditing purposes.

Repeat this step if you want to add multiple administrators. The number of administrators that are added must be equal to or greater than the larger of the following values:



* The [signature threshold](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-understand-conceptssignature-thresholds-concept) value. The signature threshold controls how many signatures are needed to run most administrative commands.
* The revocation signature threshold value that you intend to set in Step 4. The revocation signature threshold controls how many signatures are needed to remove an administrator.



Do not remove the administrator signature keys from your smart cards. Otherwise, you are not able to perform TKE actions that need to be signed, such as zeroizing crypto units and rotating master keys.

If you want to remove the administrator in a later phase, click Remove Administrator.





 Step 4: Set the signature thresholds to exit imprint mode in the selected crypto units 

When crypto units in service instances are assigned to a user, they begin in a cleared state that is called imprint mode.
A single Tier-1 Gateway is provisioned for the workloads by the automation. You can use this topology and expand it by adding new Tier-1 Gateways.
7. You can add new tenant segments to the existing Tier-1 Gateway (or to the other Tier-1 Gateways provisioned by you). The route advertisements between T1 and T0 Gateways are fully customizable by you and is done by NSX-T. No routing protocol is required or used between T1 and T0 advertisements. You can control which routes are advertised to the Tier-0. You can also use NAT, for example, each Tier-1 Gateway can have one or more IP public addresses for inbound or outbound public traffic to be used for NAT.



You can manually deploy edge nodes on the initial cluster for scalability, if needed. You can also manually deploy new edge clusters to host new Tier-1 Gateways.

Tier-0 Gateways support VRF lite, which can be used if needed to support more complex topologies for isolating routing tables also at Tier-0 level. Refer to VMware documentation for more details on capabilities and limitations.





 Considerations for selecting an overlay network topology 

VMware NSX-T™ provides many ways to build the network topologies, and the default network topology is useful for many use cases. You can typically start with this, and expand it as your needs grow. Once the initial deployment is done, IBM Cloud automation does not use the workload overlay topology and you can change the example topology based on your needs. When changing the configuration, note that the default uplinks provide the basic routed connectivity to IBM Cloud private and public networks. If you change the IP addresses or routing, your overlay workloads might lose connectivity.

IBM Cloud offers a flexible way to build the NSX-T topology to your needs. When designing your own overlay network solution, it is important to know that you might deploy new NSX-T edge nodes and new NSX-T edge clusters manually. Also, consider to use Ansible and Terraform to meet your goals. You can do this by following VMware documentation and design guidelines after the initial deployment.
By default, Red Hat OpenShift on IBM Cloud sets up many components such as the cluster master with replicas, anti-affinity, and other options to increase the high availability (HA) of the service. You can increase the redundancy and failure toleration of your cluster worker nodes, storage, networking, and workloads by configuring them in a highly available architecture. For an overview of the default setup and your options to increase HA, see [High availability for Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-ha).

For the latest HA service level agreement terms, refer to the [IBM Cloud terms of service](https://cloud.ibm.com/docs/overview?topic=overview-slas). Generally, the SLA availability terms require that when you configure your infrastructure resources in an HA architecture, you must distribute them evenly across three different availability zones. For example, to receive full HA coverage under the SLA terms, you must [set up a multizone cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clustersmz-clusters) with a total of at least 6 worker nodes, two worker nodes per zone that are evenly spread across three zones.
* What compliance standards does the service meet?

IBM Cloud is built by following many data, finance, health, insurance, privacy, security, technology, and other international compliance standards. For more information, see [IBM Cloud compliance](https://cloud.ibm.com/docs/overview?topic=overview-compliance).

To view detailed system requirements, you can run a [software product compatibility report for Red Hat OpenShift on IBM Cloud](https://www.ibm.com/software/reports/compatibility/clarity/softwareReqsForProduct.html). Note that compliance depends on the underlying [infrastructure provider](https://cloud.ibm.com/docs/openshift?topic=openshift-infrastructure_providers) for the cluster worker nodes, networking, and storage resources.
...
3. Save and close the configuration file. The changes are applied to your ALBs automatically.
4. Verify that the logs for an ALB now contain buffered content that is written according to the memory size or time interval you set.

kubectl logs -n kube-system <ALB_ID> -c nginx-ingress







 Changing the number or duration of keepalive connections 

Keepalive connections can have a major impact on performance by reducing the CPU and network usage that is needed to open and close connections. To optimize the performance of your ALBs, you can change the maximum number of keepalive connections between the ALB and the client and how long the keepalive connections can last.



1. Edit the ibm-k8s-controller-config ConfigMap.

kubectl edit cm ibm-k8s-controller-config -n kube-system
2. Change the values of keep-alive-requests and keep-alive.



* keep-alive-requests: The number of keepalive client connections that can stay open to the Ingress ALB. The default is 100.
* keep-alive: The timeout, in seconds, during which the keepalive client connection stays open to the Ingress ALB. The default is 75.



apiVersion: v1
data:
keep-alive-requests: 100
keep-alive: 75
kind: ConfigMap
metadata:
name: ibm-k8s-controller-config
...
3. Save and close the configuration file. The changes are applied to your ALBs automatically.
4. Verify that the ConfigMap changes were applied.

kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml







 Changing the number of simultaneous connections or worker processes 

Change the default setting for how many simultaneous connections the NGINX worker processes for one ALB can handle or how many worker processes can occur for one ALB.
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. Refer to [Event Streams](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-plan_choose) to determine what the recommended limits are for your plan and cluster.





 Instance bytes out per second 

The number of bytes consumed per second from an Event Streams instance.



Table 13. Instance bytes out per second metric metadata

 Metadata Description 

 Metric Name ibm_eventstreams_instance_bytes_out_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. Refer to [Event Streams](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-plan_choose) to determine what the recommended limits are for your plan and cluster.





 Missing SNI connections 

Incrementing count of the number of connections rejected due to not supporting the SNI extension to TLS.



Table 14. Missing SNI connections metric metadata

 Metadata Description 

 Metric Name ibm_eventstreams_kafka_missing_sni_host_total 
 Metric Type counter 
 Value Type none 
 Segment By Service instance, Service instance name 



Ideally this should be zero. It indicates clients that are not configured correctly. Clients must use the SNI extension for TLS to connect to the service. If this value is nonzero, ensure that all clients are at correct level and configured correctly for [SNI](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-kafka_using).





 Number of offline partitions
The IBM Blockchain platform gives customers total control over their deployments, certificates, and private keys. The console simplifies and accelerates the process of deploying components into a Kubernetes cluster on IBM Cloud that is managed and controlled by the customer. As a reminder, because the customer owns the storage that is mounted to the containers, IBM does not have access to or control over any of the data that the customer chooses to store in their ledger.





 What ports are used by the IBM Blockchain Platform? 

See the port information in the Security topic that addresses this for the [console](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-securityibp-security-ibp-ports) and the [customer Kubernetes cluster](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-securityibp-security-Kubernetes-ports).





 How can I estimate the IBM Blockchain Platform sizing requirements for my development, test, and production environments? 

After you understand how many CAs, peers, and ordering nodes are required, you can examine the default resource allocations table for your [nodes](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-adv-deploymentibp-console-adv-deployment-allocate-resources) to get an approximate estimate of the CPUs (VPCs) required for your network. If you are purchasing IBM Blockchain Platform on IBM Cloud, you can estimate your cost through this method, but you also have the ability to scale dynamically if more sources are needed.





 How does pricing work on the IBM Blockchain Platform for IBM Cloud? 

IBM Blockchain Platform for IBM Cloud is priced based on the VPCs that you allocate to your blockchain nodes on the IBM Kubernetes Service. For more information, see [Pricing for IBM Blockchain Platform for IBM Cloud](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-saas-pricingibp-saas-pricing).
These keys can be rotated in the IBM Key Protect or Hyper Protect Crypto Services instance that is associated with your KMIP for VMware instance. When these keys are rotated in the IBM Key Protect instance, KMIP for VMware handles the new CRK automatically and no operation is needed in VMware or vCenter Server.
* Level 2 - KMIP for VMware uses your CRK to protect the keys that it generates and distributes to VMware. VMware considers these keys to be key encrypting keys (KEKs). KEK rotation is relatively fast. VMware reaches out to KMIP for a new key, takes the DEKs encrypted by the original key and wraps them in this new key, and then stores the updated encrypted DEKs.



* If you are using vSphere encryption, you can rotate the KEKs by using the Set-VMEncryptionKey PowerShell command.
* If you are using vSAN encryption, you can rotate the KEKs by using the vSAN user interface.



* Level 3 - VMware uses these KEKs to protect the actual keys that it uses to encrypt disk drives and VM disks. You can rotate these keys by using what VMware calls a "deep" rekey. This operation reencrypts all your encrypted data so it might take a long time.



* If you are using vSphere encryption, you can perform a deep rekey by using the Set-VMEncryptionKey PowerShell command.
* If you are using vSAN encryption, you can perform a deep rekey by using the vSAN user interface.











 KMIP for VMware 

VMware vSAN encryption and vSphere encryption are compatible with many key management servers. KMIP for VMware provides an IBM-managed key management service that uses IBM Key Protect or Hyper Protect Crypto Services to give you full control over your keys. Other IBM Cloud services such as Cloud Object Storage also integrate with Key Protect and Hyper Protect Crypto Services, making them your central point of control for key management in the IBM Cloud.



 Keys within keys 

Key management systems commonly use a technique that is known as envelope encryption to wrap or protect keys with other keys.
Four VLANs are created in this step: one for management, one for storage, one for VMs, and one for public access. It is recommended that you create these four VLANs before you order your servers. Ordering the VLANs first makes sure that the servers are placed on the correct VLANs and in the correct data center.

The environment consists of five ESXi hosts (two for the management cluster and three for the capacity cluster) and one virtual server. The private management VLAN consists of a subnet with 16 IP addresses to support it. The primary private VLAN for storage and VM traffic consists of eight addresses since the environment contains a single storage server and VMs use a portable subnet. If a larger subnet range is needed for the management network, adjust the range by calculating the number of ESXi hosts and multiplying by 2. Also, make sure that you specify the data center for which these VLANs are created.

After you log in to IBM Cloud, open a support ticket for the management and virtual machine VLANs by selecting Support > Add Ticket. Complete the fields with the information that is in Table 2:.



Table 2. Support ticket information

 Field Value 

 Subject Private Network Question 
 Title Order VLANs 
 Details Provision three primary private VLANSs and one primary public VLAN. Associate the following addressing scheme for each VLAN: Associate 1x18 (16 addresses) for primary private VLAN. Associate 2x29 (eight addresses) for primary private VLAN. Associate 1x29 (eight addresses) primary public VLAN 
 Why do I need these additional VLANs? To place hosts, storage, and VMs on a different network for a VMware environment. 
 Do I need public and or private VLANs? Private and Public 
 How many VLANs do I need? Private = 3, Public = 1 
 How many IP addresses do I need? 8 - 16 for each VLAN 
 What router do the VLANs need to be behind? It doesn't matter that the VLANs are all in the same pod. 
 Which pod do the VLANs need to be in? They all go in the same pod in .
CA-2 (1) - Independent Assessors 



  Control requirements 

CA-2 (1) - 0
:   The organization employs assessors or assessment teams with [Assignment: organization-defined level of independence] to conduct security control assessments.





  NIST supplemental guidance 

Independent assessors or assessment teams are individuals or groups who conduct impartial assessments of organizational information systems. Impartiality implies that assessors are free from any perceived or actual conflicts of interest with regard to the development, operation, or management of the organizational information systems under assessment or to the determination of security control effectiveness. To achieve impartiality, assessors should not: (i) create a mutual or conflicting interest with the organizations where the assessments are being conducted; (ii) assess their own work; (iii) act as management or employees of the organizations they are serving; or (iv) place themselves in positions of advocacy for the organizations acquiring their services. Independent assessments can be obtained from elements within organizations or can be contracted to public or private sector entities outside of organizations. Authorizing officials determine the required level of independence based on the security categories of information systems and/or the ultimate risk to organizational operations, organizational assets, or individuals. Authorizing officials also determine if the level of assessor independence provides sufficient assurance that the results are sound and can be used to make credible, risk-based decisions. This includes determining whether contracted security assessment services have sufficient independence, for example, when information system owners are not directly involved in contracting processes or cannot unduly influence the impartiality of assessors conducting assessments. In special situations, for example, when organizations that own the information systems are small or organizational structures require that assessments are conducted by individuals that are in the developmental, operational, or management chain of system owners, independence in assessment processes can be achieved by ensuring that assessment results are carefully reviewed and analyzed by independent teams of experts to validate the completeness, accuracy, integrity, and reliability of the results. Organizations recognize that assessments performed for purposes other than direct support to authorization decisions are, when performed by assessors with sufficient independence, more likely to be useable for such decisions, thereby reducing the need to repeat assessments.