vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The Standard plan bills for every stored capacity ($/GB/month), Outbound bandwidth ($/GB), class A ($/1,000), class B ($/10,000) and retrieval ($/GB) metrics, where applicable.
* One Rate plan is suited for active workloads with large amounts of Outbound bandwidth (or varying Outbound bandwidth) as a percent of their Storage capacity (Outbound bandwidth > 20% of Storage capacity). Typical workloads belong to large enterprises and ISVs which may have sub-accounts with multiple divisions/departments or end-users. The plan offers a predictable TCO with an all-inclusive flat monthly charge ($/GB/month) that includes capacity, and built-in allowances for Outbound bandwidth and Operational requests. The built-in allowances for Outbound bandwidth and Operational requests (Class A, Class B) depend on the monthly stored capacity. There is no data retrieval charge.



* How are the allowance thresholds (for Outbound bandwidth, class A and class B) calculated for the One-Rate plan?

For each of the One-Rate plan pricing regions(North America, Europe, South America,and Asia Pacific), the total aggregated Storage capacity across all instances (within a region) is used to determine the allowance thresholds.



* Outbound bandwidth: No charge if Outbound bandwidth ≤ 100% of Storage capacity in GB, then list prices apply ($0.05/GBfor North America and Europe, $0.08/GB for South America and Asia Pacific). For example, for an account with aggregated monthly Storage capacity of 100 GB in North America, there are no Outbound bandwidth charges up to 100 GB of transferred data within that month.
* Class A: No charge if class A requests ≤ 100 x Storage capacity in GB, then list prices apply ($0.005/1000). For example, for an account with aggregated monthly Storage capacity of 100 GB in North America, there are no Outbound bandwidth charges up to 10,000 class A requests that month in North America.
[Onboarding a virtual server image with Terraform to a private catalog](https://cloud.ibm.com/docs/sell?topic=sell-vsimage-onboard)Onboarding a virtual server image with Terraform to a private catalog

This tutorial walks you through how to onboard a virtual server image with Terraform to a private catalog. By completing this tutorial, you learn how to import the virtual server image from a GitHub repository, configure the deployment and other details, and validate that you can deploy the image to a target IBM Cloud® Virtual Private Cloud (VPC).

Object Storage Virtual Private Cloud (VPC)

+1

Selling on IBM Cloud



* 45 minutes
* 2022-08-02



[Onboarding a virtual server image for Power Systems to a private catalog](https://cloud.ibm.com/docs/sell?topic=sell-vsipower-onboard)Onboarding a virtual server image for Power Systems to a private catalog

This tutorial walks you through how to onboard a public virtual server image for Power Systems Virtual Server to a private catalog. By completing this tutorial, you learn how to import the virtual server image from a GitHub repository, configure the deployment and other details, and validate that you can deploy the image to a target Power Systems Virtual Server instance.

Object Storage Virtual Private Cloud (VPC)

+1

Selling on IBM Cloud



* 45 minutes
* 2022-08-02



[Add a pricing plan for your service](https://cloud.ibm.com/docs/sell?topic=sell-svc-pricing)Add a pricing plan for your service

This tutorial walks you through the steps for adding pricing plans and features for your third-party service. By completing this tutorial, you submit required documentation, add your Export Control Classification Number (ECCN) and United Nations Standard Products and Services Code (UNSPSC), define your pricing plan, and add a list of features for your product.

Selling on IBM Cloud



* 10 minutes
* 2023-06-20
It can be based on the number of days that you want to keep the backups. Or it can be based on the total number of backups that you want to retain before the oldest ones are deleted. Planning for the retention and deletion of your backups can keep the costs down.

Backups require that the volume that you're backing up is attached to a running virtual server instance. Put another way, you can't back up an unattached volume.

A volume is backed up when a [user-provided tag](https://cloud.ibm.com/docs/vpc?topic=vpc-backup-service-aboutbackup-service-about-tags) that is associated with a Block Storage for VPC volume match the tags for target resources in a backup policy. The volume must have at least one of the backup policy’s tags for the target resources. When the scheduled backup is triggered by a backup plan, all volumes with matching tags are backed up. You can [view the status of the backup jobs](https://cloud.ibm.com/docs/vpc?topic=vpc-backup-view-policy-jobs) in the UI, from the CLI, or the API.

If a volume has multiple tags, only one tag needs to match for a backup to trigger. You can add user tags to boot and data volumes at any time, when you [create a virtual server instance](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-block-storage&interface=uicreate-from-vsi) or in an instance template.

When the backup is triggered at the scheduled interval, a backup copy is created of your volume contents. Behind the scenes, the [Snapshot for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-about) service is used to create a point-in-time copy of your data. When the first backup snapshot is taken, the entire contents of the volume are copied and retained in IBM Cloud® Object Storage. Subsequent backups of the same volume capture the changes that occurred since the previous backup.
* UI
* CLI
* API







 File Storage for VPC profiles 

When you provision File Storage for VPC file shares by using the IBM Cloud console, CLI, or API, you specify a file share profile. The profile defines the performance level that you require based on the file share size.

IBM Cloud® File Storage for VPC is available for customers with special approval to preview this service in the Frankfurt, London, Madrid, Dallas, Toronto, Washington, Sao Paulo, Sydney, Osaka, and Tokyo regions. Contact your IBM Sales representative if you are interested in getting access.



 File storage profiles overview 

When you [create a file share](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-create) in your availability zone, you select share size and IOPS performance based on a file storage profile. New file shares are created based on the high performance, [dp2](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles&nterface=uidp2-profile) profile.

Earlier file shares that were created by using either the [IOPS tier](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles&nterface=uifs-tiers) profiles or [custom IOPS](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles&nterface=uifs-custom) profile can continue to operate based on these profiles. You can also update these file shares to use the dp2 profile or switch back to a previous profile. However, you cannot use the previous profiles when you create a new file share.

Table 1 shows the dp2 profile performance levels compared to the earlier profiles. [Table 2](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles&nterface=uidp2-profile) presents the IOPS and capacity ranges for the dp2 profile.
Processors also have a different hourly rate depending on the system that they are on (Dedicated S922 vs Dedicated E980). For information on different processor type functions, see [What's the difference between capped and uncapped shared processor performance?How do they compare to dedicated processor performance?](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-power-iaas-faqsprocessor).

All prices mentioned on this page are illustrative and do not represent the actual amounts used for billing. To calculate the exact pricing, use the [IBM cost estimator](https://cloud.ibm.com/estimator).

The following tables show how different processor types affect the cost per system:



Table 4. S922 processor type pricing

 Number of cores (S922) Hourly rate (Processor type) Monthly cost (730 hours) 

 1 $0.64 (dedicated) $353.028 
 1 $0.28 (uncapped shared) $88.257 
 1 $0.34 (capped shared) $132.422 





Table 5. E980 processor type pricing

 Number of cores (E980) Hourly rate (Processor type) Monthly cost (730 hours) 

 1 $1.91 (dedicated) $1235.671 
 1 $0.64 (uncapped shared) $308.936 
 1 $0.85 (capped shared) $463.404 







 Storage types 

The Power Systems Virtual Server charges based on three different storage types:



* Data volumes: These are the simplest form of volume that you create. You are billed based on the current volume size at the metering time. The following table shows an example of how you are billed based on your volume creation:



Table 7. Calculation of data volume

 Volume size you create You are billed 

 10 GB 10 GB 
 10+5 GB 15 GB 



* Image backing volumes:These volumes are part of a boot image in your cloud-instance boot image catalog. You are billed based on the total volume size(s) contained in the image.
If your backup storage utilization is greater than 60 GB for the month (in this scenario), you are charged an overage of $0.03/month per gigabyte.

By default, Cloud Databases provides a daily backup that is stored for 30 days. These backups, and any on-demand backups you make, all count toward the above allocation.

In the above example, if your database contains 2 GB of data and you have not taken any on-demand backups, then your total backup size is 2 GB x 30 = 60 GB. Your backup costs are nil.

If your database contains 15 GB of data and you have not taken any on-demand backups, then your total backup size is 15 GB x 30 = 450 GB. In this scenario, your backup costs are (450 GB - 60 GB) * 0.03 = $11.7 per month.

Most deployments will not ever go over the allotted credit.





 Dedicated Cores Pricing 

You have the option of selecting the CPU allocation for your deployment. With dedicated cores, your resource group is given a single-tenant host with a guaranteed minimum reserve of cpu shares. Your deployments are then allocated the number of CPUs you specify. The cost of dedicated cores is $40 per core per month, and each member gets the selected number of cores. For example, if you provision a deployment with three dedicated cores per member, that is a total of 9 cores, and billed at $360 per month.

Dedicated cores are an optional feature. The default Shared CPU setting provisions your deployment on hosts with shared compute resources and incurs no additional charge.





 Scaling per Member 

Databases for MySQL deployments have minimum and maximum allocation for disk and RAM as shown. Scaling deployments through the API/CLI provides more granularity and also allows a user to scale a database instance up to 4 TB of disk per member.



Table 1. Per Member Scaling Limits

 Resource Minimum Maximum Scaling Granularity (API/CLI) 

 Disk 10 GB per member 4 TB per member 1024 MB per member 
 RAM 1 GB per member 112 GB per member 128 MB per member 
 CPU (if enabled) 3 CPUs per member 28 CPUs per member 1 CPU per member
Due to the level of CPU oversubscription that is allowed on the hosts for variable compute server instances, CPU performance levels might be less than other public profiles with the same number of cores, while RAM and storage remain consistent. These variable compute profiles are a lower-cost alternative. For example, you can use this function to test a new feature without incurring the higher cost of a full-performance virtual server instance.

The offering is available in the following profiles:



Table 11. Variable compute profiles

 Profile vCPU RAM Storage Type 

 U1.1x2 1 2 GB SAN 
 U1.2x4 2 4 GB SAN 
 U1.4x8 4 8 GB SAN 





 Storage notes 



* SAN primary boot disk (25 or 100 GB) with an extra disk available, up to 2 TB. You can add one extra secondary disk to your variable compute instance.
* Pricing for public virtual servers that use SAN storage includes virtual CPU, memory, and minimum primary boot disk. Extra disk prices depend on the disk size and quantity that you select.



Supported operating systems (such as RHEL, CentOS, Ubuntu, and others), databases that are supported, and software add-ons are also available with this offering.







 Compute 

Compute profiles are best for workloads with intensive CPU demands, such as high web traffic workloads, production batch processing, and front-end web servers.

The offering is available in the following profiles:



Table 12. Compute profiles

 Profile vCPU RAM Storage Type 

 C1.1x1 1 1 GB SAN 
 C1.2x2 2 2 GB SAN 
 C1.4x4 4 4 GB SAN 
 C1.8x8 8 8 GB SAN 
 C1.16x16 16 16 GB SAN 
 C1.32x32 32 32 GB SAN 





 Storage notes 



* SAN primary boot disk (25 or 100 GB) with extra disks available, up to 2 TB each (five total disks allowed).
* Pricing for public virtual servers that use SAN storage includes virtual CPU, memory, and minimum primary boot disk. Extra disk prices depend on the disk size and quantity that you select.
The 10 IOPS/GB performance level is limited to a maximum capacity of 4 TB per file share.
* Individual configuration of file shares

(NSX-V only) If you choose the NFS option, one 2 TB and four IOPS/GB file share for management components are ordered.







 vSAN storage 

The vSAN option offers customized configurations, with various options for disk type, size, and quantity:



* Disk quantity - 2, 4, 6, 8, or 10
* Storage disk - 960 GB SSD, 1.9 TB SSD, 3.8 TB SSD, or 7.68 TB SSD (SSD SED disks are supported for Skylake servers.)

In addition, two cache disks of 960 GB are also ordered per host.

3.8 TB SSD (solid-state disk) drives are supported when they are made generally available in a data center.
* High Performance with Intel Optane - this option provides two extra capacity disk bays for a total of 10 capacity disks. It's available only for vSphere 6 instances.









 Licenses (IBM-provided or BYOL) and fees 



* VMware vSphere Enterprise Plus 7.0 (NSX-T only)
* VMware vCenter Server 7.0
* VMware NSX Service Providers Edition (Base, Advanced, or Enterprise) 6.4
* (For vSAN clusters) VMware vSAN Advanced or Enterprise 7.0
* Support and Services fee (one license per node)









 Technical specifications for vCenter Server expansion nodes 

Each vCenter Server expansion node deploys and incurs charges for the following components in your IBM Cloud account.



 Hardware for expansion nodes 

One bare metal server with the configuration presented in [Technical specifications for vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_vcenterserveroverviewvc_vcenterserveroverview-specs).





 Licenses and fees for expansion nodes 



* One vSphere Enterprise Plus 7.0 (NSX-T only)
* One NSX Service Providers Edition (Base, Advanced, or Enterprise) 6.4
For example, a Detailed Billing tab would look similar to the following:





Zoom

![Detailed invoice](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/detailed-invoice.png)

Figure 2. Kubernetes cluster charges

The pie-chart visible on the Usage tab of the IBM Cloud Dashboard will not align with the invoices since it applies to a different billing period.





 Storage usage 

If you are using IBM Cloud File storage, the costs are assessed monthly, so an estimate of storage costs is not visible until the end of the month. However, the storage that you provisioned throughout the month is listed as line items in the Usage tile under Sales > Orders. Look in the Items column for a description of the storage that was dynamically provisioned when you deployed a peer, CA, or ordering node.







 Optimizing the cost of your nodes 

One of the key benefits of the IBM Blockchain Platform pricing model is the ability to dial back or delete resources when they are not needed.



* Switch your nodes to Minimum Utilization State
CPU on individual nodes can be scaled down to 0.001 CPU to completely minimize charges. Taking these actions renders the node non-functional. When the compute is needed later, you can use the reallocation option in the IBM Blockchain Platform console to scale up to what is required. For more information about how resources can be reallocated, see [Reallocating resources](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-govern-components).
* Delete unused peer and deploy a new one when needed. Because the ledger is stored on the ordering node, when you deploy a new peer and join a channel, the peer receives a copy of the distributed ledger. The drawback to this approach is that you need to generate new certificates and join the peer to the channels again.

It is not recommended to ever delete a CA node because the data on it can never be recovered.
To reduce costs you can capture the virtual machine and delete when it is not needed. The pricing for AIX and IBM i operating system license is not determined by whether you use a custom image or a stock image. To learn more, go to [Deploying a custom image within a Power Systems Virtual Server](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-deploy-custom-image).

The Power Systems Virtual Server also provides Linux® stock images. You may select a Linux stock image provided by IBM or bring your own Red Hat Linux Enterprise (RHEL) and SUSE Linux Enterprise Server (SLES) image OVA format. For a Linux subscription, you may opt to use a [full Linux® subscription](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-set-full-Linux) for Power Systems Virtual Server or obtain the subscription for the Linux operating system directly from the vendor. For more information about how to create an OVA format Linux image, see [deploying a Linux virtual machine](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-linux-deployment).





 Processor types 

You are charged different rates depending on the processor type you choose for your virtual machine (VM). Dedicated processors are priced the highest as they provide the best overall performance. Shared capped processors cost slightly more than shared uncapped processors because of their flexibility in addressing licensing restrictions. The processors are all charged on an hourly prorated basis according to the machine type, processor type, and the number of cores used in a month.

Each processor has a different hourly rate depending on its type (Dedicated vs Uncapped shared). Processors also have a different hourly rate depending on the system that they are on (Dedicated S922 vs Dedicated E980). For information on different processor type functions, see [What's the difference between capped and uncapped shared processor performance?How do they compare to dedicated processor performance?](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-power-iaas-faqsprocessor).
Only new volumes are partitioned, and you can't use the partitioned volume with an older version of the HPCR image. Provisioning with an existing encrypted volume also works. The difference is that the existing volume does not get partitioned, and you can also go back to an older image with this volume.







 The env section 

The env section is also one of the most important sections in a contract. The env section of a contract deals with information that is specific to the cloud environment and is not known to the workload persona. This section is created by the deployer persona.

The subsections for the env section are:



* type: env. This subsection is mandatory.
* [logging](https://cloud.ibm.com/docs/vpc?topic=vpc-about-contract_sehpcr_contract_env_log). This subsection is mandatory.
* [volumes](https://cloud.ibm.com/docs/vpc?topic=vpc-about-contract_sehpcr_contract_env_vol). This subsection must be used only when a data volume is attached.
* [signingKey](https://cloud.ibm.com/docs/vpc?topic=vpc-about-contract_sehpcr_contract_env_signkey). This subsection must be used only when you want to use a contract signature.
* [env](https://cloud.ibm.com/docs/vpc?topic=vpc-about-contract_sehpcr_contract_env_env). This subsection is used to specify values for env variables if they are defined by the workload provider.





 The logging subsection 

The minimum subsection that is required for this section is the logging subsection. For more information, see [Logging for Hyper Protect Virtual Servers for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-logging-for-hyper-protect-virtual-servers-for-vpc).

The following snippet is an example of the logging subsection:
What mechanisms are used to avoid data storage contention? 

Data storage contention is a common issue when multiple instances compete for access to the same Block Storage for VPC volume. Block Storage for VPC uses Rate Limiting at the hypervisor for optimal bandwidth between the hypervisor and Block Storage for VPC service. As a result, latency is guaranteed to be less than 1 millisecond for random reads and under 2 milliseconds for writes for a typical 16-KB block size. Latency outside these metrics might indicate a problem on the client side.





 What happens when a volume is in a degraded health state? 

Volume health state defines whether a volume is performing as expected, given its status. Volume health can be OK, degraded, inapplicable, or faulted, depending on what is happening. For example, a degraded status is displayed when a volume is being restored from a snapshot and the volume is not yet fully restored. For more information about volume health states, see [Block Storage for VPC volume health states](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-vpc-monitoringblock-storage-vpc-health-states).







 Data security and encryption questions 



 How secure is data in a Block Storage for VPC volume? 

All Block Storage for VPC volumes are encrypted at rest with IBM-managed encryption. IBM-managed keys are generated and securely stored in a Block Storage for VPC vault that is backed by Consul and maintained by IBM Cloud® operations.

For more security, you can protect your data by using your own customer root keys (CRKs). You import your root keys to, or create them in, a supported key management service (KMS). Your root keys are safely managed by the supported KMS, either Key Protect (FIPS 140-2 Level 3 compliance) or Hyper Protect Crypto Services. Both KMS solutions offer the highest level of security (FIPS 140-2 Level 4 compliance). Your key material is protected in transit and at rest.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mypvc
labels:
billingType: "monthly"
region: us-south
zone: dal13
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 24Gi
storageClassName: ibmc-file-silver

Example for using the custom storage class.

The following .yaml file creates a claim that is named mypvc of the storage class ibmc-file-retain-custom, billed "hourly", with a gigabyte size of 45Gi and IOPS of "300".

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mypvc
labels:
billingType: "hourly"
region: us-south
zone: dal13
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 45Gi
iops: "300"
storageClassName: ibmc-file-retain-custom
Show more

name
: Enter the name of the PVC.

billingType
: Specify the frequency for which your storage bill is calculated, "monthly" or "hourly". If you don't specify a billing type, the storage is provisioned with an hourly billing type.

region
: Optional: Specify the region where you want to provision your File Storage for Classic. To connect to your storage, create the storage in the same region that your cluster is in. If you specify the region, you must also specify a zone. If you don't specify a region, or the specified region is not found, the storage is created in the same region as your cluster. To get the region for your cluster, run ibmcloud oc cluster get --cluster <cluster_name_or_ID> and look for the region prefix in the Master URL, such as eu-de in https://c2.eu-de.containers.cloud.ibm.com:11111.