vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Common use cases are archives, short-term data retention, digital asset preservation, tape replacement, and disaster recovery.
* Cold: This option is used for cold data that is rarely accessed (every 90 days or less), or inactive data. Common use cases are archives, long-term backups, historical data that you keep for compliance, or workloads and apps that are rarely accessed.
* Flex: This option is used for workloads and data that don't follow a specific usage pattern, or that are too huge to determine or predict a usage pattern.



[Check out this blog](https://www.ibm.com/blogs/cloud-archive/interconnect-2017-changing-rules-storage) to learn how the Flex storage class works compared to traditional storage tiers.
3. Decide on the level of resiliency for the data that is stored in your bucket.



* Cross-region: With this option, your data is stored across three regions within a geolocation for highest availability. If you have workloads that are distributed across regions, requests are routed to the nearest regional endpoint. The API endpoint for the geolocation is automatically set by the ibmc Helm plug-in that you installed earlier based on the location that your cluster is in. For example, if your cluster is in US South, then your storage classes are configured to use the US GEO API endpoint for your buckets. For more information, see [Regions and endpoints](https://cloud.ibm.com/docs/cloud-object-storage/basics?topic=cloud-object-storage-endpointsendpoints).
* Regional: With this option, your data is replicated across multiple zones within one region. If you have workloads that are located in the same region, you see lower latency and better performance than in a cross-regional setup. The regional endpoint is automatically set by the ibm Helm plug-in that you installed earlier based on the location that your cluster is in. For example, if your cluster is in US South, then your storage classes were configured to use US South as the regional endpoint for your buckets.
Backing up and restoring storage data 

Depending on the storage solution that you use for your IBM Cloud® Kubernetes Service cluster, you have different options to back up and restore your data.

If you have not provisioned storage, review the [Kubernetes storage basics](https://cloud.ibm.com/docs/containers?topic=containers-storage-plan) to understand your storage options for single zone and multizone clusters.



*  [File Storage for Classic](https://cloud.ibm.com/docs/containers?topic=containers-file_storage)
*  [Block Storage](https://cloud.ibm.com/docs/containers?topic=containers-block_storageblock_backup_restore)
*  [Block Storage for VPC](https://cloud.ibm.com/docs/containers?topic=containers-vpc-blockvpc-block-backup-restore)
*  [Object Storage](https://cloud.ibm.com/docs/containers?topic=containers-storage-cos-understand)
*  [Portworx disaster recovery](https://cloud.ibm.com/docs/containers?topic=containers-storage_portworx_recovery)
Restoring vSphere data 

When VMs are protected in vSphere environment, you can restore [vSphere virtual machines](https://cloud.ibm.com/docs/Backup?topic=Backup-VRARestorerestoreVMs), and [restore files and folders](https://cloud.ibm.com/docs/Backup?topic=Backup-VRARestorerestoreFFVRA) with the vSphere Recovery Agent.



 Restoring vSphere VMs 



1. On the navigation bar, click Computers. A grid lists available computers.
2. Find the vSphere environment with the VM that you want to restore, and expand its view by clicking the row.
3. Click Jobs.
4. Find the backup job with the VM that you want to restore, and click Restore in the job’s Select Action menu.
5. In the Choose what you want to restore dialog box, select virtual machines.
6. Click Continue. The Restore dialog shows the most recent safe-set for the job.



* To restore data from another source, click a source (vault) in the Source Device List.
* To restore from an older safe-set, click Browse safe sets. In the calendar that appears, click the date of safe-sets from which you want to restore.



7. In the Items to Restore panel, select each VM that you want to restore.
8. In the Encryption Password field, type the data encryption password.
9. In the Destination Datastore list, click the VMware datastore for the restored VMs.
10. Select one of the following options for restoring VMs to the VMware datastore that you selected:



* Restore all selected virtual machines to the selected datastore only.
* Restore to the selected datastore only when a virtual machine’s original datastore is not available. If the VM's backup contains multiple VMDKs that resided on multiple VMware datastores, and not all of the datastores are available, the entire VM is restored to the selected VMware datastore.
If you want to restore to the latest available point-in-time use "point_in_time_recovery_time":" ".

ibmcloud resource service-instance-create <SERVICE_INSTANCE_NAME> <service-id> <region> -p '{"point_in_time_recovery_deployment_id":"DEPLOYMENT_ID", "point_in_time_recovery_time":"TIMESTAMP"}'

A pre-formatted command for a specific backup or PITR is available in detailed view of the backup.

Optional parameters are available when restoring through the CLI. Use them if you need to customize resources, or use a Key Protect key for BYOK encryption on the new deployment.

ibmcloud resource service-instance-create <SERVICE_INSTANCE_NAME> <service-id> standard <region> <--service-endpoints SERVICE_ENDPOINTS_TYPE> -p
'{"point_in_time_recovery_deployment_id":"DEPLOYMENT_ID", "point_in_time_recovery_time":"TIMESTAMP","key_protect_key":"KEY_PROTECT_KEY_CRN", "members_disk_allocation_mb":"DESIRED_DISK_IN_MB", "members_memory_allocation_mb":"DESIRED_MEMORY_IN_MB", "members_cpu_allocation_count":"NUMBER_OF_CORES"}'





 In the API 

The Resource Controller supports provisioning of database deployments, and provisioning and restoring are the responsibility of the Resource Controller API. You need to complete [the necessary steps to use the resource controller API](https://cloud.ibm.com/docs/databases-for-mysql?topic=cloud-databases-provisioningprovisioning-through-the-resource-controller-api) before you can use it to restore from a backup.

Once you have all the information, the create request is a POST to the [/resource_instances](https://cloud.ibm.com/apidocs/resource-controllercreate-provision-a-new-resource-instance) endpoint.
For more information, see [Protecting Virtual Private Cloud (VPC) Infrastructure Services with context-based restrictions](https://cloud.ibm.com/docs/vpc?topic=vpc-cbr).

File Storage for VPC is integrated with the Security and Compliance Center to help you manage security and compliance for your organization. For more information, see [Managing security and compliance](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-managingfs-vpc-manage-security).

You can [increase the file share size](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-expand-capacity) from its original capacity in GB increments up to 32,000 GB capacity, depending on your file share profile. You can also [increase or decrease file share IOPS](https://cloud.ibm.com/docs/vpc?topic=vpc-adjusting-share-iops) to meet your performance needs. Adjust IOPS by specifying a different IOPS tier profile or different IOPS value withing a custom IOPS band. Operations to increase the capacity or adjust the IOPS cause no outage or lack of access to the storage. Billing is adjusted automatically. You pay for only the capacity and performance that you need.



 File storage IOPS profiles 

When you create a file share in your availability zone, you use the dp2 profile to specify the total IOPS for the file share based on the share size.

If you have existing files shares that are based on either the IOPS tier profiles or custom IOPS profile; you can update those shares to use the dp2 profile. You can also change back to an earlier profile. However, you cannot use the earlier profiles when you provision a file share.

All profiles are backed by solid-state drives (SSDs).

For more information, see [File Storage for VPC profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles).





 NFS version 

File Storage for VPC requires NFS versions v4.1 or higher.







 Mount targets for file shares
"type": "vpc",
"value": "crn:v1:bluemix:public:is:us-south:a/12ab34cd56ef78ab90cd12ef34ab56cd::vpc:r134-d98a1702-b39a-449a-86d4-ef8dbacf281e"
}
]
}

{
"id": "65810ac762004f22ac19f8f8edf70a34",
"crn": "crn:v1:bluemix:public:context-based-restrictions:global:a/12ab34cd56ef78ab90cd12ef34ab56cd::zone:65810ac762004f22ac19f8f8edf70a34",
"name": "example-zone",
"description": "this is an example of zone",
"account_id": "12ab34cd56ef78ab90cd12ef34ab56cd",
"addresses": [
{
"type": "ipAddress",
"value": "169.23.56.234"
},
{
"type": "ipRange",
"value": "169.23.22.0-169.23.22.255"
},
{
"type": "subnet",
"value": "192.0.2.0/24"
},
{
"type": "vpc",
"value": "crn:v1:bluemix:public:is:us-south:a/12ab34cd56ef78ab90cd12ef34ab56cd::vpc:r134-d98a1702-b39a-449a-86d4-ef8dbacf281e"
}
],
"address_count": 4,
"excluded_count": 0,
* By bypassing the public internet, your traffic takes fewer hops, so there are fewer points of failure where your traffic might get dropped or disrupted.
* Move data to and from your on-premises data centers into the IBM Cloud with uninterrupted, consistent network performance while protecting sensitive, business-critical data.
* Save on data transfer rates to and from servers in every IBM Cloud data center across our private network, avoiding bandwidth fees.







 Routing considerations for IANA-registered IP assignments 

IBM Cloud VPC supports the use of RFC-1918 and Regional Internet Registry (RIR) assigned addresses privately as VPC subnets. The following use cases require additional route configurations to designate the Internet Assigned Numbers Authority (IANA) assigned ranges for use in a VPC when a floating IP or a public gateway is attached to a resource within the VPC.



* Use case 1: VPC is connected to your Enterprise with IBM Cloud Direct Link and requires communication with IANA-assigned networks on that Enterprise.
* Use case 2: VPC is connected to another VPC through IBM Cloud Transit Gateway and requires communication to IANA-assigned networks in the connected VPCs.
* Use case 3: VPC is connected to a classic infrastructure network by using BCR peering to announce IANA-assigned ranges to the classic network.



In these scenarios, each subnet in the VPC must have a routing table attached with routes designating the IANA-assigned ranges as targets for private routing, or all traffic to these publicly routable ranges is forwarded toward the public backbone, and not toward the intended private network destination. This applies to VPC subnets using RFC-1918 "and" IANA assigned prefixes. As with all custom route additions, the routing table must include a route for each Availability Zone (AZ) requiring connectivity.

Options include:



* If the VPC default (egress) routing table is attached to all VPC subnets, create a route for each IANA prefix or aggregate per zone in the VPC default table with the Delegate-VPC action. This defers to the VPC system routing table for forwarding action.
* If you use custom routing tables, create a route for each IANA prefix or aggregate per zone in each custom routing table with the Delegate-VPC action.
Use deployable architectures to deploy your resources 

[Infrastructure as Code (IaC)](https://www.ibm.com/cloud/learn/infrastructure-as-code) automates the provisioning of infrastructure and enables your organization to develop, deploy, and scale cloud applications with greater speed, less risk, and reduced cost. With that in mind, IBM Cloud offers a set of

deployable architecturesthat automate the deployment of different variations of the VPC reference architecture.

See [Overview of VPC landing zone deployable architectures](https://cloud.ibm.com/docs/secure-infrastructure-vpc) to get started.



  Next steps 



*  [Account setup in IBM Cloud](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-account-setup)
VPC address prefixes are no longer restricted to RFC-1918 addresses. You must now configure VPCs that use both non-RFC-1918 addresses and have public connectivity (floating IPs or public gateways) by using a custom route that contains the new Delegate-VPC action. You must specify this action for destination CIDRs that are non-RFC-1918 compliant and also outside of the VPC, such as for destinations that are reachable through Direct Link, Transit Gateway, or VPC classic access. For more information about when to use the Delegate-VPC action, see [Routing considerations for IANA-registered IP assignments](https://cloud.ibm.com/docs/vpc?topic=vpc-interconnectivityrouting-considerations-iana).

The Delegate-VPC action is required if both are true:



* The VPC uses non-RFC-1918 addresses
* The VPC has public connectivity



The Delegate-VPC action is NOT required if:



* The VPC uses only RFC-1918 addresses
* The VPC has no public connectivity



You can create a route for an IBM Cloud service by using the UI, CLI, or API.



 Creating a route in the UI 

To create a route in the UI, follow these steps:



1. Make sure to review [Limitations and guidelines](https://cloud.ibm.com/docs/vpc?topic=vpc-about-custom-routes&interface=uilimitations-custom-routes).
2. From the [IBM Cloud console](https://cloud.ibm.com/login), select the Navigation Menu ![Navigation Menu](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc//images/menu_icon.png), then click VPC Infrastructure > Routing tables in the Network section. The Routing tables for VPC page appear.
3. Select the VPC associated with the routing table you want to view.
[Navigation Menu](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc//images/menu_icon.png), then click VPC Infrastructure > Routing tables in the Network section. The Routing tables for VPC page appear.
3. Select the VPC associated with the routing table you want to view. Then, click the name of the routing table to show its details.
4. Scroll to the Routes section and click Create.
5. In the Create route side panel, enter the following information:



* Zone - Select an availability zone for your route.
* Name - Type a name for the new route.
* Destination CIDR - The destination CIDR of the route (for example, 10.0.0.0/16).
* Priority - Enter a priority from 0 to 4. The default value is 2.
For more information, see [Determining route preference](https://cloud.ibm.com/docs/vpc?topic=vpc-about-custom-routescr-determining-route-preference).
* Action - Values are:



* Delegate - Routes the packet by using the system routing table.
* Delegate-VPC - Delegates to the system's built-in routes, ignoring internet-bound routes. Required if the VPC uses non-RFC-1918 addresses and also has public connectivity. See [Routing considerations for IANA-registered IP assignments](https://cloud.ibm.com/docs/vpc?topic=vpc-interconnectivityrouting-considerations-iana) for details.
* Deliver - Routes the packet to the next hop target. You can add multiple routes with the same address prefix. The virtual router performs equal-cost, multi-path routing (ECMP) by using the different next hop IP addresses.
* Drop - Drops the packet.





Traffic egressing a subnet uses the custom routing table that is associated with the subnet.
VPC address prefixes are no longer restricted to RFC-1918 addresses
: You must now configure VPCs that use both non-RFC-1918 addresses and have public connectivity (floating IPs or public gateways) using a custom route that contains the new Delegate-VPC action. You must specify this action for destination CIDRs that are non-RFC-1918 compliant and also outside of the VPC, such as for destinations that are reachable through Direct Link, Transit Gateway, or VPC classic access. For more information about when to use the Delegate-VPC action, see [Routing considerations for IANA-registered IP assignments](https://cloud.ibm.com/docs/vpc?topic=vpc-interconnectivityrouting-considerations-iana).





 18 February 2021 

UI enhancement
: You can now provision a VPN gateway or load balancer without first creating a VPC. If you don't have an existing VPC you can provision the VPN gateway or load balancer in the default VPC. The new VPN gateway or load balancer is created along with a default VPC that includes a default security group, access control list, and subnet.





 07 February 2021 

Virtual server instance console (Beta)
: You can now access your virtual server by connecting to a VNC or serial console. This feature provides a quick-and-easy way for you to interact with the virtual server without using a Secure Shell. This is a Beta feature that requires special approval. Contact your IBM Sales representative if you are interested in getting access. For more information, see [Accessing virtual server instances by using VNC or serial consoles (Beta)](https://cloud.ibm.com/docs/vpc?topic=vpc-vsi_is_connecting_console)







 January 2021 



 26 January 2021 

New region
: The Osaka region endpoint is now in service at https://jp-osa.iaas.cloud.ibm.com. For more information, see [Creating a VPC in a different region](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-in-a-different-region).
* UI
* CLI
* API







 Creating a route 

You can control the flow of network traffic in your VPC by configuring routes. Use VPC routes to specify the next hop for packets, based on their destination addresses.

Multiple routing tables can exist for each zone in your VPC. For egress traffic, when a packet leaves a subnet, the system evaluates its destination against the routing table in the subnet's zone to determine where to send the packet next. Each VPC has a default routing table that will be attached to every subnet (unless it was explicitly attached to a different one by the user).

A VPC custom route has four main components:



* The destination CIDR
* The next hop where the packet will route (when the action is Deliver)

You can edit the next hop IP address for existing routes.
* The zone
* Action



Any traffic that originates in the specified zone of the VPC and has a destination address within the specified destination CIDR routes to the next hop. If the destination address is within the destination CIDR for multiple VPC routes, the most specific route is used. If the VPC has two or more equally specific routes, the traffic is round-robin that is distributed between each route.

Each route has a destination property, which includes a prefix length (/24 in 10.2.0.0/24). The number of unique prefix lengths that are supported per custom routing table is 14. Multiple routes with the same prefix count as only one unique prefix.

VPC address prefixes are no longer restricted to RFC-1918 addresses. You must now configure VPCs that use both non-RFC-1918 addresses and have public connectivity (floating IPs or public gateways) by using a custom route that contains the new Delegate-VPC action. You must specify this action for destination CIDRs that are non-RFC-1918 compliant and also outside of the VPC, such as for destinations that are reachable through Direct Link, Transit Gateway, or VPC classic access.
See [Routing considerations for IANA-registered IP assignments](https://cloud.ibm.com/docs/vpc?topic=vpc-interconnectivityrouting-considerations-iana) for details.
* Deliver - Routes the packet to the next hop target. You can add multiple routes with the same address prefix. The virtual router performs equal-cost, multi-path routing (ECMP) by using the different next hop IP addresses.
* Drop - Drops the packet.





Traffic egressing a subnet uses the custom routing table that is associated with the subnet. If no matching route is found in a custom routing table, routing continues by using the VPC system routing table. You can avoid this behavior with a custom routing table default route with an action of Drop.



* Type - Select either IP address or VPN connection.
* Next hop (IP address) - Enter the next hop.

You can modify the next hop IP address for existing routes.



6. Click Save to save the new route. The route appears on the Routing table details page.







 Creating a route from the CLI 

Before you begin, make sure to [set up your CLI environment](https://cloud.ibm.com/docs/vpc?topic=vpc-infrastructure-cli-plugin-vpc-reference).

To create a VPC route from the CLI, run the following command:

ibmcloud is vpc-routing-table-route-create VPC ROUTING_TABLE --zone ZONE_NAME --destination DESTINATION_CIDR [--action delegate_vpc | delegate | deliver | drop] [--priority PRIORITY] [--next-hop NEXT_HOP --vpngw VPNGW]] [--name NAME] [--output JSON] [-q, --quiet]

Where:



* VPC is the ID or name of the VPC.
* ROUTING_TABLE is the ID or name of the VPC routing table.
* --zone is the name of the zone.
* --destination is the destination CIDR of the route.
vpcAddressModel := &contextbasedrestrictionsv1.AddressVPC{
Type: core.StringPtr("vpc"),
Value: core.StringPtr(vpcCRN),
}
serviceRefAddressModel := &contextbasedrestrictionsv1.AddressServiceRef{
Type: core.StringPtr("serviceRef"),
Ref: &contextbasedrestrictionsv1.ServiceRefValue{
AccountID: core.StringPtr(accountID),
ServiceName: core.StringPtr("cloud-object-storage"),
},
}
excludedIPAddressModel := &contextbasedrestrictionsv1.AddressIPAddress{
Type: core.StringPtr("ipAddress"),
Value: core.StringPtr("169.23.22.127"),
}

createZoneOptions := contextBasedRestrictionsService.NewCreateZoneOptions()
createZoneOptions.SetName("an example of zone")
createZoneOptions.SetAccountID(accountID)
createZoneOptions.SetDescription("this is an example of zone")
createZoneOptions.SetAddresses([]contextbasedrestrictionsv1.AddressIntf{ipAddressModel, ipRangeAddressModel, subnetAddressModel, vpcAddressModel, serviceRefAddressModel})
createZoneOptions.SetExcluded([]contextbasedrestrictionsv1.AddressIntf{excludedIPAddressModel})

zone, response, err := contextBasedRestrictionsService.CreateZone(createZoneOptions)
if err != nil {
panic(err)
}
b, _ := json.MarshalIndent(zone, "", " ")
fmt.Println(string(b))

// Request models needed by this operation.
It is often a business preference to Bring-your-own Subnet/CIDR/IP address range (BYOIP) to your IBM Cloud account; this is available depending on the Infrastructure selection and environment.



 VPC Infrastructure 

When using VPC Infrastructure, it is possible to define and use your own subnet. See [VPC - Bring your own subnet](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-address-prefixes).

This changes depending on whether [RFC 1918](https://tools.ietf.org/html/rfc1918) IANA reserved IPv4 private network address spaces are in use, because any IP Address within these ranges is considered non-routable. These addresses are not unique on the Internet as they could be used by any private network without any coordination with IANA or an Internet registry, so these addresses are only unique within a private network. These IPv4 private network address spaces are:



* Class A - 10.0.0.0/8
* Class B - 172.16.0.0/12
* Class C - 192.168.0.0/16



If you use a bring-your-own subnet range which is defined under [RFC 1918](https://tools.ietf.org/html/rfc1918) IANA reserved IPv4 private network address spaces, then connectivity to an existing internal network is possible when using any VPC functions (for example, Public Gateway or Floating IPs).

It is not supported to use a bring-your-own subnet range not defined under [RFC 1918](https://tools.ietf.org/html/rfc1918) IANA reserved IPv4 private network address spaces because this would not permit connectivity to an existing internal network when used with a Public Gateway (PGW) and Floating IPs.





 Classic Infrastructure with VMware 

If the existing business operates SAP on VMware, it is possible to use IBM Cloud for VMware along with VMware HCX and IBM Cloud® Direct Link to create a bridged bidirectional network between existing Datacenter with VMware and IBM Cloud for VMware.