vania-janet/multiturn-rag-retrieval-data huggingface dataset:
: A PV is a virtual storage instance that is added as a volume to the cluster. The PV points to a physical storage device in your IBM Cloud infrastructure account and abstracts the API that is used to communicate with the storage device. To mount a PV to an app, you must have a matching PVC. Mounted PVs appear as a folder inside the container's file system.

Physical storage
: A physical storage instance that you can use to persist your data. Examples of physical storage in IBM Cloud include [File Storage for Classic](https://cloud.ibm.com/docs/containers?topic=containers-file_storagefile_storage), [Block Storage](https://cloud.ibm.com/docs/containers?topic=containers-block_storageblock_storage), [Object Storage](https://cloud.ibm.com/docs/containers?topic=containers-storage-cos-understand), and local worker node storage that you can use as SDS storage with [Portworx](https://cloud.ibm.com/docs/containers?topic=containers-storage_portworx_about). IBM Cloud provides high availability for physical storage instances. However, data that is stored on a physical storage instance is not backed up automatically. Depending on the type of storage that you use, different methods exist to set up backup and restore solutions.

For more information about how to create and use PVCs, PVs, and the physical storage device, see the following topics.



* [Dynamic provisioning](https://cloud.ibm.com/docs/containers?topic=containers-kube_conceptsdynamic_provisioning)
* [Static provisioning](https://cloud.ibm.com/docs/containers?topic=containers-kube_conceptsstatic_provisioning)







 Dynamic provisioning 

Use dynamic provisioning if you want to give developers the freedom to provision storage when they need it.

Dynamic provisioning is a feature that is native to Kubernetes and that allows a cluster developer to order storage with a pre-defined type and configuration without knowing all the details about how to provision the physical storage device.
: A PV is a virtual storage instance that is added as a volume to the cluster. The PV points to a physical storage device in your IBM Cloud infrastructure account and abstracts the API that is used to communicate with the storage device. To mount a PV to an app, you must have a matching PVC. Mounted PVs appear as a folder inside the container's file system.

Physical storage
: A physical storage instance that you can use to persist your data. Examples of physical storage in IBM Cloud include [File Storage for Classic](https://cloud.ibm.com/docs/openshift?topic=openshift-file_storagefile_storage), [Block Storage](https://cloud.ibm.com/docs/openshift?topic=openshift-block_storageblock_storage), [Object Storage](https://cloud.ibm.com/docs/openshift?topic=openshift-storage-cos-understand), and local worker node storage that you can use as SDS storage with [Portworx](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_about). IBM Cloud provides high availability for physical storage instances. However, data that is stored on a physical storage instance is not backed up automatically. Depending on the type of storage that you use, different methods exist to set up backup and restore solutions.

For more information about how to create and use PVCs, PVs, and the physical storage device, see the following topics.



* [Dynamic provisioning](https://cloud.ibm.com/docs/openshift?topic=openshift-kube_conceptsdynamic_provisioning)
* [Static provisioning](https://cloud.ibm.com/docs/openshift?topic=openshift-kube_conceptsstatic_provisioning)







 Dynamic provisioning 

Use dynamic provisioning if you want to give developers the freedom to provision storage when they need it.
Using HMAC credentials 

HMAC credentials consist of an Access Key and Secret Key paired for use with S3-compatible tools and libraries that require authentication.



 HMAC credentials defined 

The IBM Cloud® Object Storage API is a REST-based API for reading and writing objects. It uses IBM Cloud® Identity and Access Management for authentication and authorization, and supports a subset of the S3 API for easy migration of applications to IBM Cloud.



 Create HMAC credentials in the console 

Users can create a set of HMAC credentials as part of a [Service Credential](https://cloud.ibm.com/docs/services/cloud-object-storage/iam?topic=cloud-object-storage-service-credentials) by switching the Include HMAC Credential to On during credential creation in the console. Figure 1 shows the option for setting the HMAC parameter by choosing "Advanced options."

Zoom

![include HMAC credential](https://cloud.ibm.com/docs-content/v1/content/63322f2f3a72050206eb05ba7f590fdcb741105c/cloud-object-storage/images/hmac-credential-dialog.jpg)

Figure 1. HMAC setting from advanced options

After the Service Credential is created, the HMAC Key is included in the cos_hmac_keys field. These HMAC keys are then associated with a [Service ID](https://cloud.ibm.com/docs/account?topic=account-serviceidsserviceids) and can be used to access any resources or operations that are allowed by the Service ID's role.

When creating a service credential, it is possible to provide a value of None for the role. This will prevent the creation of unintended or unnecessary IAM access policies. Any access policies for the associated service ID will need to be managed using the IAM console or APIs.





 Create HMAC credentials using the CLI 

You can also use the IBM Cloud® Object Storage CLI to create your credentials.
In this exercise, the first two API keys are created so that the two instances can talk to each other during the replication process. The third API key is for the user to access the IBM Cloudant API, create the _replicator database, and then add the replication document to it.

Follow these steps to generate IAM API keys and API access for IBM Cloudant. You must write down the credentials that are requested in the following steps to continue with the example.

Ensure that you select the specified instance, either the Source or Target.



1. Log in to cloud.ibm.com.
2. From the Resource list, select Services and your Source instance.



1. Click Service credentials and click New credential.
2. Name the new credential replicator-source, and select the Manager role.
3. Click Add, and make note of its apikey, which is under View Credentials in the Actions column.



3. Repeat steps 2 through 2.c. for the Target instance.



1. Create a credential called replicator-target with the Manager role.
2. Make note of its IAM API key, which is under View Credentials in the Actions column.



4. Select the Source instance, and click Service credentials and New credential.



1. Name the new credential apiaccess, and select the Manager role.
2. Make note of the actual IAM API key under View Credentials in the Actions column.



5. Make note of Source and Target instance URLs.



Depending on your workflow, instead of creating a service-level credential (step 4), you can use a personal IAM API key, as detailed in [Creating an API key](https://cloud.ibm.com/docs/account?topic=account-userapikeycreate_user_key).

You can also complete these steps on the command line by using the [IBM Cloud CLI tool chain](https://cloud.ibm.com/docs/cli?topic=cli-getting-started).





 Generating a bearer token to authenticate against the IBM Cloudant API
VMware NSX-T logical routing on VPC 

When designing logical network topologies on IBM Cloud® Virtual Private Cloud hosted in NSX-T™, it is important to decide how to route the traffic of NSX-T segment attached workloads between NSX-T, IBM Cloud VPC, and public internet.

The following diagram presents an overview of the routing between NSX-T Logical Routers and VPC.

Zoom

![VPC routing with NSX-T Logical Routers](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/vpc-ryo-diagrams-nsx-t-vpc-routing.svg)

Figure 1. VPC routing with NSX-T Logical Routers

If your design does not need direct inbound public access, you can customize this architecture. Various customization aspects of the connectivity architecture are discussed in the following topics.



 Routing between Tier-0 and Tier-1 logical routers 

The first architectural decision to be made for your solution, is routing between T1 and T0. You can configure various route advertisements and static routes on a T1 logical router.

In this design, the workloads are connected to NSX-T overlay segments behind T1, and when T1 is connected to its parent T0, it has a default route pointing to the T0. By default, T0 does not detect the segments that are attached to T1, and this is where route advertisement is needed.

If you want to route natively with IBM Cloud VPC subnets and other connected service without using NAT in T1, enable route advertisement of "All Connected Segments & Service Ports" in the specific T1. You must not configure a routing protocol or static routes between T1 and T0 logical routers. After enabling the route advertisement, NSX-T creates routes automatically. With this approach, you have all connected segments on your T1 routed to T0, and then you can decide how to proceed with the public and private traffic in T0.
The backend instance runs a NodeJS and GraphQL API wrapper for IBM Cloud Databases for PostgreSQL and IBM Cloud Object Storage.



4. Copy the public load balancer hostname from the log output and paste the hostname in a browser by prefixing http:// to see the frontend application. As shown in the diagram below, enter the balance, e.g.,10 and click Submit to see the details of the VSIs serving the request.

Zoom

![View application](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution62-vpc-scaling-dedicated/application.png)

View application

To check the provisioned VPC resources, you can either use the [VPC UI](https://cloud.ibm.com/vpc-ext/network/vpcs) or [Cloud Shell](https://cloud.ibm.com/shell) with [ibmcloud is](https://cloud.ibm.com/docs/cli?topic=vpc-infrastructure-cli-plugin-vpc-reference) commands.



In the next section, you will choose a scaling method (static or dynamic) and create scaling policies.







 Step 3: Increase load on your instances to check scaling 

In this section, you will start scaling the instances with the scaling method initially set to static. Then, you move to scaling the instances with dynamic scaling by setting up an instance manager and an instance group manager policy. Based on the target utilization metrics that you define, the instance group can dynamically add or remove instances to achieve your specified instance availability.



 Manual scaling 



1. To check static scaling method, navigate to the Settings tab of your Schematics workspace to see that the step3_is_dynamic variable is set to false.
2. Update the step3_instance_count variable to 2 and Save the setting.
3. Apply the plan to see the additional two instances (one frontend VSI and one backend VSI) provisioned.
Setting up an HPC cluster 



 Objectives 



* Deploy an HPC cluster with your choice of configuration properties







 Architecture overview and NFS file system setup 

The HPC cluster consists of a login node, a storage node where the block storage volume is attached, 1 - 3 LSF management nodes, and a number of LSF worker nodes.



* The login node is served as a jump host and it is the only node that has the public IP address. Other nodes have only private IP addresses and the only way to reach these nodes is through the login node. You can log in to the primary LSF management host and do most of the operations from the LSF management host. By default, lsfadmin is the only user ID created on the cluster. The SSH passwordless setup is configured between the LSF management host and workers. You can reach any other worker node with the lsfadmin user ID from the LSF primary.
* The worker node can be a static resource. In this case, its lifecycle is managed by Schematics. You can request a number of static worker nodes, and these workers remain available in the LSF cluster until a Schematics-destroy action is performed. The LSF resource connector function creates extra workers when there is not enough capacity to run jobs and destroys workers when the demands decrease. The lifecycle of these dynamic workers is managed by the LSF resource connector. Wait until these dynamic resources are returned to the cloud before you destroy the entire VPC cluster through Schematics.
* The storage node is configured as an NFS server and the block storage volume is mounted to /data, which is exported to share with LSF cluster nodes. At the NSF client end, the LSF cluster nodes in this case, the remote directory, /data, is mounted to /mnt/data locally. A soft link, /home/lsfadmin/shared, also points to /mnt/data. You can use /home/lsfadmin/shared as a shared file system for your applications.



The HPC cluster solution provides a base custom image, which includes the LSF installation. You can create your own custom image on top of the base image.
FAQs for IBM Cloud Virtual Router Appliance 

These frequently asked questions can help you when working with the IBM Cloud® Virtual Router Appliance (VRA).



 What is a VRA? 

A IBM Cloud® Virtual Router Appliance (VRA) allows an IBM Cloud® customer to selectively route private and public network traffic through a full-featured enterprise router with firewall, traffic shaping, policy-based routing, VPN, and a host of other features. All VRA features are customer-managed. VRA gives an IBM Cloud customer a degree of control that is normally reserved for on-premises networks.





 What is a gateway appliance? 

With a gateway appliance fixture, you can use the web portal or API to choose network segments (VLANs) to route through a VRA. You can change VLAN selections at any time. The gateway appliance also handles VRA High Availability (HA), configuring a second VRA to take over if the first one fails.





 I sometimes see references to terms like "Vyatta" and "vRouter." How do they relate to VRA? 

Vyatta was open source, PC-based router software that was acquired and transitioned to closed source. Today, "Vyatta" and "Vyatta OS" describe commercial software adaptations that are derived from that closed source project. IBM VRA incorporates elements of Vyatta OS, along with substantial feature and service enhancements available exclusively through IBM Cloud.

"vRouter" was a short-lived rebranding of Vyatta by its then-owner. When seen in documentation, it can be considered synonymous with Vyatta.





 Is Vyatta 5400 still supported? 

IBM no longer supports Vyatta 5400 as of 31 March 2019.





 What improvements does the IBM Cloud® Virtual Router Appliance (Vyatta 5600) have over the Vyatta 5400? 

Vyatta 5600 offers the following enhancements over the Vyatta 5400:



* Faster throughput, at up to 10 Gbps per CPU core
* Over 3X increased throughput per IPsec VPN session (Advanced Encryption Standards)
An NSX-T Tier-1 logical gateway has downlink ports to connect to NSX-T Data Center logical switches and uplink ports to connect to NSX-T Data Center Tier-0 logical gateways. They run in the kernel level of the hypervisor they are configured for, and they are virtual router instances (vrf) of the NSX-T gateway cluster. In this design, one or more T1 logical gateways can be created for the needs of customer chosen topologies.





 Tier 1 to Tier 0 route advertisement 

To provide Layer 3 connectivity between VMs connected to logical switches that are attached to different tier-1 logical gateways, it is necessary to enable tier-1 route advertisement toward tier-0. No need to configure a routing protocol or static routes between tier-1 and tier-0 logical routers. NSX-T creates static routes automatically when you enable route advertisement. For this design, route advertisement is always enabled for any IBM Cloud® for VMware Solutions automation created T1 gateways.







 Preconfigured topologies 

Workload to T1 to T0 gateway – virtual gateway cluster

Zoom

![NSX-T deployed topology virtual T0 Edge Gateway](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/nsx-t-3-ra-diagrams-preconfigured-topology.svg)

Figure 6. NSX-T deployed topology virtual T0 Edge Gateway

Topology 1 is basically the same topology that is deployed with NSX-V DLR and Edge gateways. With NSX-T, no dynamic routing protocol configuration between T1 and T0. RFC-1891 IP address space is used for the workload overlay network and transit overlay network. A customer private and public portable IP space is assigned for customer use. A customer designated IBM Cloud private and public portable IP space is assigned to the T0 for customer use.
: In case you plan to use dynamic rule with IBM Cloud App ID-based federation, make sure to use the correct syntax for the "Identity Provider" setting inside the Dynamic Rule. The section in the link is describing how to build the correct "Identity Provider" identifier.

[Setting up IBM Cloud App ID with your Active Directory Federation Service](https://www.ibm.com/cloud/blog/setting-ibm-cloud-app-id-active-directory-federation-service)
: A description of how to set up an IBM Cloud App ID instance with Microsoft Active Directory. This blog entry is describing the general way how to connect Microsoft Active Directory, but does not make any additional steps to ensure that attributes required by IBM Cloud IAM are correctly mapped. You must make sure to provide the attributes described here to successfully display user data.

[IBM Cloud Account Single Sign-on by using IBM Cloud App ID and Microsoft Azure AD](https://medium.com/@vrvignesh/ibm-cloud-account-single-sign-on-using-ibm-cloud-app-id-and-microsoft-azure-ad-88932a5660a2)
: This blog entry shows the whole process of integrating Microsoft Azure Active Directory with IBM Cloud using IBM Cloud App ID. Check out the documentation to learn more about Identity and Access Management in IBM Cloud.
* Click the Server tab and specify the application ingress subdomain as Origin server address, for example cdn-with-cda-todolist.<ingress-subdomain>.
* Uncheck HTTP port.
* Check HTTPS port and select Wildcard SSL certificate.

With the [Wildcard certificate](https://cloud.ibm.com/docs/CDN?topic=CDN-about-httpswildcard-certificate-support), you will access your app through the Custom CNAME. The Wildcard certificate is the simplest way to deliver web content to your users securely. The Custom CNAME is added to the wildcard certificate maintained on the CDN Edge server and becomes the only way for users to use HTTPS for your CDN (for example, [https://cdnakaivlnqidbg4.cdn.appdomain.cloud](https://cdnakaivlnqidbg4.cdn.appdomain.cloud)){: external}.



2. Accept the Master Service Agreement and click Create.



After you have successfully created the CDN mapping:



* CNAME configuration required may display in the Status column, you can ignore it and check the status again by selecting Get status from the overflow menu. It should change to Running after a few minutes.
* To view your CDN instance, select the CDN instance [in the list](https://cloud.ibm.com/cdn). The Details panel shows both the Hostname and the CNAME for your CDN.
* You application is now accessible through the CNAME only: https://<CNAME>. You may need to wait a few minutes for all configuration to complete and for the CNAME to work.







 Step 3: Enable Dynamic Content Acceleration (DCA) 

At that stage, the static content of the application is cached by the CDN but not the dynamic content.

The Dynamic Content Acceleration (DCA) feature will query a test object in about 10KB size on your origin server to determine the optimal routes for real requests.
[What is an access policy](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/account/images/Access-Policy.svg)

Figure 1. What is an Access Policy

The most commonly used roles are viewer, editor, operator, and administrator platform roles.



* The viewer role provides the least amount of access for viewing instances and resource groups in an account.
* The operator role includes actions such as the ability to view instances and manage aliases, bindings, and credentials.
* The editor role includes actions the same actions of an operator role but also actions for creating, editing, deleting, and binding service instances.
* The administrator role includes everything for working with a service instance and assigning access to others for that service or instance that the policy is for.



While these are the most popular roles for assigning access in the platform, there are a second set of roles to consider called service roles. The actions mapped to these roles are defined by each service. Typically the actions mapped to these roles relate specifically to the ability to work with a service's APIs and UI.

For more information about the roles that can be assigned, see [IAM roles](https://cloud.ibm.com/docs/account?topic=account-userrolesiamusermanrol).





 Reducing time and effort to manage access 

There is a [limit](https://cloud.ibm.com/docs/account?topic=account-known-issuesiam_limits) on the total number of policies that are allowed in an account. You can use a few strategies to ensure that you don't reach the limit and to reduce the amount of time that you spend managing access for the identities in your account (users, service IDs, or trusted profiles):



* Use the principle of least privilege and assign only the access that is necessary. This can help you ensure that the identities in your account are limited to only the actions that you want to allow.
When the instance is stopped, you can either restart it or delete it.
* When I attempt to update my Ubuntu image with apt, I receive an error about the grub menu.lst file. How do I fix it?

Edit the file "/boot/grub/menu.lst" by changing groot=LABEL... into groot=(hd0). Then, run following command, sudo update-grub-legacy-ec2. For more information, see [Error: groot must be grub root device on Ubuntu](https://developer.ibm.com/answers/questions/462237/error-groot-must-be-grub-root-device-on-ubuntu/).
* In what cases is my virtual server migrated to a different host?

In limited cases a virtual server might need to be migrated to a different host. If a migration is required, the virtual server is shut down, migrated, and then restarted. A virtual server might be migrated in the following cases:



* Infrastructure [maintenance](https://cloud.ibm.com/docs/vpc?topic=vpc-about-cloud-maintenance). You might receive an email that's indicating that [maintenance](https://cloud.ibm.com/docs/vpc?topic=vpc-about-cloud-maintenance) is required on a system that is hosting your virtual server. Your virtual server might need to be migrated as part of the infrastructure [maintenance](https://cloud.ibm.com/docs/vpc?topic=vpc-about-cloud-maintenance).
* An unplanned host outage. The following actions apply if an unexpected host failure occurs:



* The virtual servers that were running on the host are stopped when the outage is detected.
* The virtual servers are automatically reassigned and restarted on a different compute host in the same multi-region zone.
* The virtual servers that are restarted use the same boot volume, and the same data volumes as the original virtual server.
* The virtual server that was restarted is assigned the same floating IP, static IP, and dynamic IP addresses on the new node.