vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Your PVC, PV, and storage instance are automatically removed.
: For storage that was [statically provisioned](https://cloud.ibm.com/docs/openshift?topic=openshift-kube_conceptsstatic_provisioning), or storage that you provisioned with a storage class that sets reclaimPolicy: Retain, you must manually remove the PVC, PV, and the storage instance to avoid further charges.

How does the billing stop after I delete my storage?
: Depending on what storage components you delete and when, the billing cycle might not stop immediately. If you delete the PVC and PV, but not the storage instance in your IBM Cloud account, that instance still exists and you are charged for it.

If you delete the PVC, PV, and the storage instance, the billing cycle stops depending on the billingType that you chose when you provisioned your storage and how you chose to delete the storage.



* When you manually cancel the persistent storage instance from the IBM Cloud console or the ibmcloud sl CLI, billing stops as follows:



* Hourly storage: Billing stops immediately. After your storage is canceled, you might still see your storage instance in the console for up to 72 hours.
* Monthly storage: You can choose between immediate cancellation or cancellation on the anniversary date. In both cases, you are billed until the end of the current billing cycle, and billing stops for the next billing cycle. After your storage is canceled, you might still see your storage instance in the console or the CLI for up to 72 hours.



* Immediate cancellation: Choose this option to immediately remove your storage. Neither you nor your users can use the storage anymore or recover the data.



* Anniversary date: Choose this option to cancel your storage on the next anniversary date. Your storage instances remain active until the next anniversary date and you can continue to use them until this date, such as to give your team time to make backups of your data.



* When you dynamically provisioned the storage with a storage class that sets reclaimPolicy: Delete and you choose to remove the PVC, the PV and the storage instance are immediately removed. For hourly billed storage, billing stops immediately.
In addition, a console message with more details is displayed and you are notified by email. The message displays the expected capacity for all services that do not meet the requirements.

To install the service, you must increase the capacity in your cluster either by adding more VMware ESXi™ servers or by freeing up RAM, CPU, or disk space. After that, you can add the service or services again. To remove the existing service that is in a Capacity Validation Failed state, click the Delete icon ![Delete icon](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/icons/delete.svg) next to it.

The following table provides the resource requirements for the services for which a capacity check is completed.



Table 2. Resources required for the services that the system checks for capacity requirements

 Service name Resource requirements 

 Caveonix RiskForesight CPU - 8 CPUs <br>RAM - 32 GB <br>Storage - 100 GB 
 F5 BIG-IP<br><br>[1] CPU - 4, 8, or 16 CPUs, depending on license and bandwidth chosen <br>RAM - 8, 16, or 32 GB, depending on license and bandwidth chosen 
 FortiGate Virtual Appliance CPU - 2, 4, 8, 16, or 32 CPUs, depending on deployment size chosen <br>RAM - 4, 6, or 12 GB, depending on deployment size chosen 
 Entrust CloudControl CPU - 4 CPUs <br>RAM - 16 GB <br>Storage - 186 GB VMDK 
 Juniper vSRX You must have enough available capacity to accommodate two VMs with the following requirements, on different hosts: <br>CPU - 6 CPUs <br>RAM - 16 GB <br>Storage - 18 GB <br>If you install Juniper vSRX on clusters with 25 Gb uplink speed, the following capacity requirements apply. <br>CPU - 10 CPUs <br>RAM - 16 GB <br>Storage - 18 GB 
 Red Hat OpenShift If you install Red Hat OpenShift with vSAN™ storage, the following capacity requirements apply.
(https://cloud.ibm.com/docs-content/v1/content/04e9937a86546143babfc65ea21fdd4ea2d12d13/FileStorage//images/bfcircle3.svg) After a Snapshot copy is created, the active file system and Snapshot copy point to the same disk blocks. The Snapshot copy doesn't use extra disk space. 
 ![The space that is used when something changes after a snapshot copy was taken.](https://cloud.ibm.com/docs-content/v1/content/04e9937a86546143babfc65ea21fdd4ea2d12d13/FileStorage//images/bfcircle2.svg) After myfile.txt is deleted from the active file system, the Snapshot copy still includes the file, and references its disk blocks. Thus deleting active file system data doesn't always free up disk space. 



For more information about snapshot space usage, see [Managing Snapshots](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-managingSnapshots).
[Actions icon](https://cloud.ibm.com/docs-content/v1/content/04e9937a86546143babfc65ea21fdd4ea2d12d13/icons/action-menu-icon.svg) for the volume to be canceled, and select Delete File Storage for Classic.
4. Confirm if want to delete the volume immediately or on the anniversary date of when the volume was provisioned.

If you select the option to cancel the volume on its anniversary date, you can void the cancellation request before its anniversary date.
5. Click Continue or Close.
6. Click the acknowledgment checkbox, and click Confirm.



When the volume is canceled, the request is followed by a 24-hour reclaim wait period. You can still see the volume in the console during those 24 hours. Billing for the volume stops immediately. When the reclaim-period expires, the data is destroyed and the volume is removed from the console, too. For more information, see the [FAQs](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-file-storage-faqs).

Active replicas and dependent duplicates can block reclamation of the Storage volume. Make sure that the volume is no longer mounted, host authorizations are revoked, replication is canceled, and no dependent duplicates exist before you attempt to delete the original volume.





 Deleting a storage volume from the SLCLI 

To delete a storage volume, you can use the following command.

 slcli file volume-cancel --help
Usage: slcli file volume-cancel [OPTIONS] VOLUME_ID

Options:
--reason TEXT An optional reason for cancellation.
--immediate Cancels the file storage volume immediately instead of on the
billing anniversary.
-h, --help Show this message and exit.

When the volume is canceled, the request is followed by a 24-hour reclaim wait period. You can still see the volume in the console during those 24 hours. Billing for the volume stops immediately.
Autoscaling configurations based on memory usage are currently not available.

Disk - Disk autoscaling can scale when either disk usage reaches a certain threshold, Disk I/O utilization reach a certain threshold, or both. (The "or" in the UI operates as an inclusive or, |, v.) The amount of IOPS available to your deployment increases with disk size at a ratio of 10 IOPS for each GB.

The resource numbers refer to each database node in a deployment. For example, there are three members in a RabbitMQ cluster and if the deployment is scaled with 10 GB of disk and 1 GB of RAM, that means each member gets 10 GB of disk and 1 GB of RAM. The total resources added to your deployment is 30 GB of disk and 3 GB of RAM.



 Autoscaling Considerations 



* Scaling your deployment up might cause your RabbitMQ to restart. If your scaled deployment needs to be moved to a host with more capacity, then the databases are restarted as part of the move.
* Disk cannot be scaled down.
* A few scaling operations can be more long running than others. Drastically increasing RAM or Disk can take longer than smaller increases to account for provisioning more underlying hardware resources.
* Autoscaling operations are logged in [IBM Cloud® Activity Tracker](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=cloud-databases-activity-tracker).
* Limits



* can't set anything to scale in an interval less than 60 seconds.
* Maximum Disk = 4 TB per member
* Maximum RAM = 112 GB per member



* Autoscaling does not scale down deployments where disk or memory usage has shrunk. The RAM provisioned to your deployment remains for your future needs, or until you scale down your deployment manually. The disk provisioned to your deployment remains because disk cannot be scaled down.
* If you need to add resources to your deployment occasionally or rarely, you can [manually scale](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=messages-for-rabbitmq-resources-scaling) your deployment.







 Configuring Autoscaling in the UI
* UI
* CLI
* Terraform







 Managing Snapshots 

Snapshots are a feature of IBM Cloud® Block Storage for Classic. A snapshot represents a volume's contents at a particular point in time. With snapshots, you can protect your data with no performance impact and minimal consumption of space. Learn more about how to manage snapshots by reading the following instructions.



 Adding a Snapshot schedule in the UI 

You decide how often and when you want to create a point in time reference of your storage volume with Snapshot schedules. You can have a maximum of 50 snapshots per storage volume. Schedules are managed through the Storage > File Storage for Classic tab of the [IBM Cloud® console](https://cloud.ibm.com/login).

Before you can set up your initial schedule, you must first purchase snapshot space if you didn't purchase it during the initial provisioning of the storage volume.

Snapshots schedules can be set up for hourly, daily, and weekly intervals, each with a distinct retention cycle. The maximum limit of snapshots is 50 per storage volume, which can be a mix of hourly, daily, and weekly schedules, and manual snapshots.



1. Click your storage volume, click Actions![Actions icon](https://cloud.ibm.com/docs-content/v1/content/04e9937a86546143babfc65ea21fdd4ea2d12d13/icons/action-menu-icon.svg), and click Schedule Snapshot.
2. In the New Schedule Snapshot window, you can select from three different snapshot frequencies. Use any combination of the three to create a comprehensive snapshot schedule.



* Hourly



* Specify the minute each hour that a snapshot is to be taken. The default is the current minute.
* Specify the number of hourly snapshots to be retained before the oldest is discarded.



* Daily



* Specify the hour and minute that a snapshot is to be taken. The default is the current hour and minute.
* Select the number of hourly snapshots to be retained before the oldest is discarded.



* Weekly
* If ephemeral storage is set to 1 GB and memory is set to 4 GB, and you want to reduce the memory to 2 GB, this operation is valid because the ephemeral storage is less than or equal to the memory.



For more information about memory or CPU limitations, see [Limits and quotas for Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-limits).



 Supported combinations 

See the following table for valid combinations of vCPU and memory.



Table 1. Valid vCPU and memory combinations

 CPU-intensive Balanced Memory-intensive 

 0.125 vCPU <br>0.25 GB 0.125 vCPU <br>0.5 GB 0.125 vCPU <br>1 GB 
 0.25 vCPU <br>0.5 GB 0.25 vCPU <br>1 GB 0.25 vCPU <br>2 GB 
 0.5 vCPU <br>1 GB 0.5 vCPU <br>2 GB 0.5 vCPU <br>4 GB 
 1 vCPU <br>2 GB (default) <br>1 vCPU <br>4 GB 1 vCPU <br>8 GB 
 2 vCPU <br>4 GB 2 vCPU <br>8 GB 2 vCPU <br>16 GB 
 4 vCPU <br>8 GB 4 vCPU <br>16 GB 4 vCPU <br>32 GB 
 6 vCPU <br>12 GB 6 vCPU <br>24 GB 6 vCPU <br>48 GB 
 8 vCPU <br>16 GB 8 vCPU <br>32 GB 
 10 vCPU <br>20 GB 10 vCPU <br>40 GB 
 12 vCPU <br>24 GB 12 vCPU <br>48 GB 



Your existing apps and jobs might be using other memory and CPU combinations, and those will remain unaffected. However, these other combinations are not valid and only the valid combinations are supported. Therefore, any new apps or jobs as well as any changes to existing apps or jobs must comply with the list of valid choices.





 Units of measurement
For questions about billing and to find the steps for how to use the IBM Cloud console to modify your storage, see [Expanding Block Storage capacity](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-expandingcapacityexpandingcapacity) and [Adjusting IOPS](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-adjustingIOPS). Updates that you make from the console are not reflected in the persistent volume (PV). To add this information to the PV, run oc patch pv <pv_name> and manually update the size and IOPS in the Labels and Annotation section of your PV.



1. List the PVCs in your cluster and note the name of the associated PV from the VOLUME column.

oc get pvc

Example output

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
myvol Bound pvc-01ac123a-123b-12c3-abcd-0a1234cb12d3 20Gi RWO ibmc-block-bronze 147d
2. If you want to change the IOPS and the size for your block storage, edit the IOPS in the metadata.labels.IOPS section of your PV first. You can increase or decrease the IOPS value. Make sure that you enter an IOPS that is supported for the storage type that you have. For example, if you have endurance block storage with 4 IOPS, you can change the IOPS to either 2 or 10. For more supported IOPS values, see [Deciding on your block storage configuration](https://cloud.ibm.com/docs/openshift?topic=openshift-block_storageblock_predefined_storageclass).

oc edit pv <pv_name>

To change the IOPS from the CLI, you must also change the size of your block storage. If you want to change only the IOPS, but not the size, you must [request the IOPS change from the console](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-adjustingIOPS).
3.
The maxmemory is set to 80% of a data node's available memory, so your node doesn't run out of system resources.

You can scale the amount of memory to accommodate more data, and you can configure the maxmemory setting to tune memory usage. The [Redis documentation](https://redis.io/topics/memory-optimizationmemory-allocation) has some good information on memory behavior and tuning maxmemory.

You can also configure your deployment to use [Redis as a cache](https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-redis-cache), allowing Redis to evict data out of memory once the memory limit is reached.





 Disk IOPS 

The number of Input-Output Operations per second (IOPS) is limited by the type of storage volume. Storage volumes for Databases for Redis deployments are provisioned on [Block Storage Endurance Volumes in the 10 IOPS per GB tier](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-orderingthroughConsoleorderingthroughConsoleEndurance). By default, a deployment starts with persistence enabled. It's possible for very busy databases to exceed the IOPS for the disk size, and increasing disk can alleviate a performance bottleneck.
For example, Bucket.
3. Optional: Add additional target attributes to further qualify the resources that you want to target.

For example, to target all of your Cloud Object Storage buckets in the US South location, you would make the following selections: Attribute: Location, Value: string_equals, and enter us_south for Value.
4. Click Add to rule.



5. Configure your properties.

To add additional properties to your rule, repeat this step. You can select up to 5 different conditions and 16 properties to create your rule.



1. Select a Condition.



* And: When you select And as your condition, all the property configurations that you add to your rule must evaluate to true in order for the rule to be compliant.
* Or: When you select Or as your condition, only part of your rule must evaluate to true for it to be compliant.



2. Define the rule by specifying a Property, Operator, and Value.

To see all the properties that are available for the service that you selected, you can click Available Properties in the Definition step.
3. Click Add to rule.



6. Click Next.
7. Review your selections and click Create.







 Next steps 

Now that you created a rule, add it to a library by associating it with a specification. Then, start monitoring by attaching it to a scope.
The quotas can be specified in MB, GB, or TB. These are hard quotas.
3. Select what you would like to occur when the quotas are reached.

Discard logs when the Daily Usage Quota is reached until midnight UTC
: If selected, when the daily quota is reached within a 24-hour period at UTC, logs will no longer be saved.

Discard logs when the Monthly Usage Quota is reached until the next billing cycle
: If selected, when the monthly quota is reached before the end of the billing cycle, logs will no longer be saved.

If logs are not being saved they will still be available for live tail and alerting.

Verify all conditions and exclusion rules when selecting these options. Selecting these options will result in logs being discarded and not saved for searching, archiving, or streaming.
4. Click Apply to save your changes.







 Configuring usage quota exclusion rules 

If you want to take action prior to daily or monthly quota being reached, you can set up exclusion rules that operate as soft quotas.

These exclusion rules will allow you to discard specific non-critial logs before reaching the hard quota threshold.

For example, if the daily usage quote is 2 GB and your set an exclusion rule for 50%, IBM Cloud Activity Tracker will apply the configured exclusion rule and no longer retain logs from the sources, apps, hosts, or queries specified in the rule.

You can specify up to 5 daily exclusion rules and 5 monthly exclusion rules.



 Daily exclusion rules 

To specify a daily exclusion rule, do the following from the Usage Quotas dialog:

Verify that each exclusion rule that you add behaves as expected. Improper configured exclusion rules can result in storing data not intended for storage.



1. In the Triggered Exclusion Rules section click Add daily rule.
2. Drag the slider to the percentage of the daily usage quota when you want the rule triggered. For example, 50%. If you try to set a percentage where an exclusion rule exists, you will be warned that the existing rule will be replaced.
3. Select the source of the logs you want to exclude.
4. Select the apps you want to exclude.
5.
Autoscaling configurations based on memory usage are currently not available.

Disk - Disk autoscaling can scale when either disk usage reaches a certain threshold, Disk I/O utilization reach a certain threshold, or both. (The "or" in the UI operates as an inclusive or, |, v.) The amount of IOPS available to your deployment increases with disk size at a ratio of 10 IOPS for each GB.

The resource numbers refer to each database node in a deployment. For example, there are three members in an Elasticsearch cluster and if the deployment is scaled with 10 GB of disk and 1 GB of RAM, that means each member gets 10 GB of disk and 1 GB of RAM. The total resources added to your deployment is 30 GB of disk and 3 GB of RAM.



 AutoScaling Considerations 



* Scaling your deployment up might cause your Elasticsearch to restart. If your scaled deployment needs to be moved to a host with more capacity, then the databases are restarted as part of the move.
* Disk cannot be scaled down.
* A few scaling operations can be more long running than others. Drastically increasing RAM or Disk can take longer than smaller increases to account for provisioning more underlying hardware resources.
* Autoscaling operations are logged in [IBM Cloud® Activity Tracker](https://cloud.ibm.com/docs/databases-for-elasticsearch?topic=cloud-databases-activity-tracker).
* Limits



* can't set anything to scale in an interval less than 60 seconds.
* Maximum Disk = 4 TB per member
* Maximum RAM = 112 GB per member



* Autoscaling does not scale down deployments where disk or memory usage has shrunk. The RAM provisioned to your deployment remains for your future needs, or until you scale down your deployment manually. The disk provisioned to your deployment remains because disk cannot be scaled down.
* If you need to add resources to your deployment occasionally or rarely, you can [manually scale](https://cloud.ibm.com/docs/databases-for-elasticsearch?topic=databases-for-elasticsearch-resources-scaling) your deployment.
* Elasticsearch is designed to balance work load across a cluster and can benefit from being horizontally scaled.
4. Select the host quantity.



* For NFS only storage, select a minimum of 2.
* For vSAN™ storage, select a minimum of 6.



5. For vSAN, optionally select the Enable vSAN de-duplication & compression checkbox to save storage space.
6. Select the sizings for one or more IOPS/GB performance tiers for attached NFS storage.



7. Review the add-on service option to deploy the Veeam® Backup and Replication service. Toggle the service off if you do not want to include it in your order.
8. On the Summary pane, review the instance settings and the estimated price.
9. To place the order, ensure that the account to be charged is correct, review and accept the terms, and then click Create.







 Related links 



* [VMware as a Service overview](https://cloud.ibm.com/docs/vmware-service?topic=vmware-service-vmware-aas-overview)
* [Viewing VMware as a Service instances](https://cloud.ibm.com/docs/vmware-service?topic=vmware-service-tenant-viewing)
* [Visualizing your site with IBM Cloud® Monitoring](https://cloud.ibm.com/docs/vmware-service?topic=vmware-service-single-tenant-monitoring)
* [Deleting VMware as a Service instances](https://cloud.ibm.com/docs/vmware-service?topic=vmware-service-tenant-deleting)
Follow the prompts and choose whether to delete cluster resources, which include containers, pods, bound services, persistent storage, and secrets.



* Persistent storage: If you [dynamically provisioned](https://cloud.ibm.com/docs/containers?topic=containers-kube_conceptsdynamic_provisioning) storage with a storage class that sets reclaimPolicy: Delete, your persistent volume claim (PVC), persistent volume (PV), and the storage instance are automatically deleted when you delete the cluster. However, depending on when you delete the cluster, you might still see your storage instance in the IBM Cloud console for up to 72 hours or until the new billing cycle begins. VPC Block Storage is not removed automatically, even if you used a Delete storage class.

For storage that was [statically provisioned](https://cloud.ibm.com/docs/containers?topic=containers-kube_conceptsstatic_provisioning), VPC Block Storage, or storage that you provisioned with a storage class that sets reclaimPolicy: Retain, the PVC and the PV are removed when you delete the cluster, but your storage instance and your data remain. You are still charged for your storage instance.

To manually remove the storage and find frequently asked questions about storage removal, review the documentation for each storage type in the links in the Before you begin section.





Next steps:



* After it is no longer listed in the available clusters list when you run the ibmcloud ks cluster ls command, you can reuse the name of a removed cluster.
* Classic clusters only: If you kept the subnets, you can [reuse them in a new cluster](https://cloud.ibm.com/docs/containers?topic=containers-subnetssubnets_custom) or manually delete them later from your IBM Cloud infrastructure portfolio.
* VPC clusters only: If you have infrastructure resources that you no longer want to use, such as the VPC or subnets, remove these resources in the VPC portal.
* If you kept the persistent storage, you can delete your storage later through the IBM Cloud console for the corresponding storage service.
"id": "d8b26921-1409-4c2f-9b46-39b5b6e0b945",
"name": "my-volume-data-5iops"
}
}







 Next steps 

Create more volumes and manage existing ones. See the following information.



* [Creating Block Storage for VPC volumes](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-block-storage)
* [Managing Block Storage for VPC volumes](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-block-storage)