About File Storage for VPC

Overview

File Storage for VPC provides file shares within the VPC Infrastructure. You can create file shares at the zonal level, for example us-south-1. File shares are identified by name and associated with a resource group in your IBM Cloud customer account.

You create a file share in a zone and create the mount targets for the share per VPC. You can control how the file share is accessed by specifying the access mode: VPC-wide access or targeted access for specific instances within a zone.

You can set up replication between the source file share and a replica file share. So if an outage at the primary site was to occur, you can fail over to the replica file share.

Data on a file share is encrypted at rest with IBM-managed encryption by default. For added security, you can use your own root keys to protect your file shares with customer-managed keys. When you specify the security group access mode and attach a virtual network interface to the file share mount target, you can enable encryption of data in transit. For more information, see File share encryption.

You can apply user tags and access management tags to your file shares. Add tags when you create a share or update an existing share with the UI, CLI, API, or Terraform. For more information, see Tags for file shares.

You can enable context-based restrictions (CBR) for all file share operations. These restrictions work with traditional IAM policies, which are based on identity, to provide an extra layer of protection. Unlike IAM policies, context-based restrictions don't assign access. Context-based restrictions check that an access request comes from an allowed context that you configure, such as creating a file share. For more information, see Protecting Virtual Private Cloud (VPC) Infrastructure Services with context-based restrictions.

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.

You can increase the file share size 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 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.

Encryption at rest

By default, file shares are encrypted at rest with IBM-managed encryption.

You can bring your own customer root key (CRK) to the cloud for customer-managed encryption or you can have a key management service (KMS) generate a key for you. You can select the root key when you create an encrypted file share. For more information, see Customer-managed encryption.

After you specified an encryption type for a file share, you can't change it.

Mount targets for file shares

Mounting is a process by which a server's operating system makes files and directories on a storage device available for users to access through the server's file system. To mount a file share on a virtual server instance or to use it in a Kubernetes cluster, you need the NFS mount path. To create an NFS mount path, you need to create a mount target.

A mount target for a file share is a network endpoint. When you create a mount target, an NFS mount path is created for the file share. You use the mount path to attach the file share to virtual server instances or Kubernetes clusters in the same region. Depending on the access mode you choose, you can restrict access to a share to a specific instance in the VPC or allow all the virtual server instances to mount the share.

If you want to connect a file share to instances that are running in different VPCs in a zone, you can create multiple mount targets, one mount target for each VPC.

After the mount target is created, you can SSH into the virtual server instance and attach the file share.

Granular authorization

When you set the access control mode of a file share to use security groups, and create a mount target with a virtual network interface, the VPC Infrastructure creates a file share gateway that provides a 1:1:1 granular authorization for the share.

The security groups that are associated with the mount target act as a virtual firewall that controls the traffic between the mount target and the Compute host.

You can select a specific security group or use the VPC's default security group. By modifying the rules of the security groups in your VPC, you can restrict access to the file share from one or more specific virtual server instances or bare metal server.

To enable traffic between a virtual server instance and a mount target, you must configure the following rules in the security groups:

• The security groups that you attach to a mount target must allow inbound access for the TCP protocol on the NFS port from all virtual server instances on which you want to mount the file share.
• Each virtual server instance that you want the file share to be mounted on must have a security group that allows outbound access to the mount target on the NFS port.

You can configure your security group in a more dynamic way by allowing all traffic between members of the security group. Then, attach this security group to the network interface of the virtual server instance and the virtual network interface of the mount target. For more information, see Allow traffic between members of a security group.

It is also recommended that UDP ports 500 and 4500 are allowed. UDP port 500 is intended for Internet Key Exchange (IKE) to manage encryption keys, and UDP port 4500 is for IPsec NAT-Traversal (NAT-T). A VPN gateway for VPC accepts VPN packets with UDP Encapsulation of IPsec ESP Packets only.

When you create the mount target, you can specify a subnet and reserved IP address for the virtual network interface, or have the service pick an IP address for you in the specified subnet. The mount target must have a VPC private IP address, and the IP address must be in a subnet that is in the same zone as the share. The IP address that is assigned to the mount target cannot be changed later.

When you create the mount target with a virtual network interface, its IP address is determined in either of the following ways:

• By subnet - You specify the subnet and allow the system to choose an IP address from the reserved IP addresses within that subnet. A network interface is created with the selected IP address, and then that network interface is attached to the file share mount target.

• By subnet and IP address - You specify the IP address in the subnet. Then, the network interface is created and attached to the mount target.

When the mount target is attached and the share is mounted, the virtual network interface performs security group policy check to ensure that only authorized virtual server instances can communicate with the share.

For greater security, enable encryption in transit for your file share mount targets.

Encryption in transit

You can establish an encrypted mount connection between the authorized virtual server instance and the storage system by using IPsec. For file shares based on the dp2 profile, mount targets that are created with a virtual network interface can support the encryption in transit. The mount targets can be for a source or replica share.

If you want to connect a file share to instances that are running in different VPCs in a zone, you can create multiple mount targets. You can create one mount target for each VPC.

If you choose to use Encryption-in-transit, you need to balance your requirements between performance and enhanced security. Encrypting data in transit can have some performance impact due to the processing that is needed to encrypt and decrypt the data at the endpoints. The impact depends on the workload characteristics. Workloads that perform synchronous writes or bypass VSI caching, such as databases, might have a substantial performance impact when EIT is enabled. To determine EIT’s performance impact, benchmark your workload with and without EIT.

Even without EIT, the data is moving through a secure data center network. For more information about network security, see Security in your VPC and Protecting Virtual Private Cloud (VPC) Infrastructure Services with context-based restrictions.

File Storage for VPC is considered to be a Financial Services Validated service only when encryption-in-transit is enabled. For more information, see what is a Financial Services Validated service.

Encryption in transit is not supported for Bare Metal Servers for VPC or virtual server instances that are running on Red Hat Enterprise Linux CoreOS.

IAM roles for creating and managing shares, accessor bindings, and mount targets

File Storage for VPC requires IAM permissions for role-based access control. Depending on your assigned role, you can create and manage file shares. For more information, see IAM roles and actions for File Storage for VPC.

For more information, see the best practices for assigning access. For the complete IAM process, which includes inviting users to your account and assigning Cloud IAM access, see the IAM getting started tutorial.

Sharing file share data between accounts and services

Customers who manage multiple accounts sometimes find that some of their accounts need to access and work with the same data. Administrators with the correct authorizations can share an NFS file system across accounts, so the data that their applications depend on is available across the different systems within the company. Customer can also share their File Storage for VPC shares with the IBM watsonX service.

Cross-account service-to-service authorization is used to establish trust between share owner and accessor accounts. After the authorization is set in place, the share owner account can see the IDs of the accounts that can mount the shared file share and the accessor account can see the shared NFS shares in their resources list along with the share's owner information. The accessor account can't edit the properties of the origin share. Nor can they delete the origin share, but they can mount them in their own VPCs.

For more information about sharing and mounting a file share from another IBM Cloud® account or VPC, see Sharing and mounting a file share from another account.

Sharing a file share with other accounts or services is not supported for file shares with VPC-wide access mode.

File share replication and failover

You can create read-only replicas of your file shares in another zone within your VPC, or another zone in a different region if you have multiple VPCs in the same geography. The replica is updated regularly based on the replication schedule that you specify. You can schedule to replicate your data as often as every 15 minutes. Using replication is a good way to recover from incidents at the primary site when data becomes inaccessible or applications fail. Failover to the replica share makes it the new, writeable primary share. For more information, see About file share replication.

For cross-region replication, you must configure service to service authorizations before you create your replica file share.

Supplemental IDs and Groups for file shares

When a process runs on Unix and Linux, the operating system identifies a user with a user ID (UID) and a group with a group ID (GID). These IDs determine which system resources a user or group can access. For example, if the file storage user ID is 12345 and its group ID is 6789, then the mount on the host node and in the container must have those same IDs. The container’s main process must match one or both of those IDs to access the file share.

With the API, you can set these attributes for controlling access to your file shares when you create a file share. The API provides an initial owner property where you can set the UID and GID values. Wherever you mount the file share, the root folder where you mount it uses that UID or GID owner. For more information, see Add supplemental IDs when you create a file share.

Tags for file shares

File Storage for VPC is enabled for Global Searching and Tagging (GhoST). You can create and apply user tags and access management tags to file shares to better control and organize your file storage resources across the VPC. User tags can be added in the console, from the CLI, or with the API. To apply access management tags to file shares, you must use the GhoST API.

File Storage data eradication

When you delete a file share, that data immediately becomes inaccessible. All pointers to the data on the physical disk are removed. If you later create a file share in the same or another account, a new set of pointers is assigned. The account can't access any data that was on the physical storage because those pointers are deleted. When new data is written to the disk, any inaccessible data from the deleted file storage is overwritten.

IBM guarantees that data deleted cannot be accessed and that deleted data is eventually overwritten and eradicated. When you delete a file share, those blocks must be overwritten before that file storage is made available again, either to you or to another customer.

Further, when IBM decommissions a physical drive, the drive is destroyed before their disposal. Decommissioned physical drives are unusable and any data on them is inaccessible.

Managing security and compliance

File Storage for VPC is integrated with the Security and Compliance Center to help you manage security and compliance for your organization. You can set up goals that check whether file shares are encrypted by using customer-managed keys. By using the Security and Compliance Center to validate the file service configurations in your account against a profile, you can identify potential issues as they arise.

For more information, see Getting started with Security and Compliance Center. For more information about creating security and compliance goals, see Defining rules in the Security and Compliance documentation.

Activity tracking events

You can use IBM Cloud® Activity Tracker Event Routing to configure how to route auditing events. Auditing events are critical data for security operations and a key element for meeting compliance requirements. Such events are triggered when you create, modify, or delete a file share. Activity tracker events are also triggered when you establish and use file share replication. For more information, see Activity tracking events for IBM Cloud VPC.

Logging for file share service

After you provision IBM® Log Analysis to add log management capabilities to your IBM Cloud® architecture, you can enable platform logs to view and analyze logs of the File Storage for VPC service. For more information, see Logging for VPC.

Monitoring share-related metrics in the console

IBM Cloud® Monitoring is a third-party cloud-native, and container-intelligence management system that you can include as part of your IBM Cloud architecture. IBM Cloud Monitoring is operated by Sysdig in partnership with IBM. You can access File share dashboards in the IBM Cloud console and view metrics such as current read and write throughput, and maximum throughput. For more information, see Monitoring metrics for File Storage for VPC.

Limitations in this release

The following limitations apply to this release of File Storage for VPC.

• Previous profiles are not supported when you provision a new file share, which is based on the dp2 profile. However, earlier version file shares can continue to use existing profiles.
• Restricting file share access to specific virtual server instances and data encryption in transit is available only for shares that are based on the dp2 profile.
• Windows operating systems are not supported.
• The minimum capacity is 10 GB per file share.
• The maximum capacity is 32,000 GB per file share.
• No data retention policy exists for deleted file shares. You cannot undelete a file share after you delete it.
• Up to 256 hosts per zone per VPC can be concurrently connected to a single file share.
• You can create up to 300 file shares within your VPC.
• Up to 100 accessor share bindings can be created when you share your file share with another account or external service.
• A file share cannot be deleted by using a DELETE /shares/<id> API request, if an existing mount target is associated with that file share or if replica operations are in progress.
• Only Bare Metal Servers for VPC that are provisioned after 31 August 2023 support File Storage for VPC.
• Encryption in transit is not supported between File Storage for VPC for VPC and Bare Metal Servers for VPC.
• A file share cannot be split from its replica by using a DELETE /shares/<id>/source API request, if the lifecycle_state of the file share is updating or if replica operations are in progress.
• Cross-regional replication is supported within the same geography when both source and replica shares belong to the same account. Cross-geography replication is not supported.

Next steps

• Plan your file shares and mount targets.
• IAM Roles and Actions.
• Create a file share and mount targets.
• Mount your file share. Mounting is a process by which a server's operating system makes files and directories on the storage device available for users to access through the server's file system. For more information, see the following topics:
  • IBM Cloud File Share Mount Helper utility
  • Mounting file shares on Red Hat Linux.
  • Mounting file shares in CentOS.
  • Mounting file shares on Ubuntu.
  • Mounting file shares on z/OS
• Manage your file shares and data.
  • Viewing file shares and mount targets. You can retrieve information about your files shares and mount targets in the console, from the CLI, with the API, or Terraform.
  • Manage your file shares. You can rename a file share. You can increase its capacity and modify its IOPS. You can add mount targets to a file share. You can rename or delete a mount target. You can delete a file share when you no longer need it.
  • Create a file share with replication. With the replication feature, you can keep a read-only copy of your file share in another zone. The replica share is updated from the source share on a schedule that you specify. Replication provides a way to recover from an incident at the primary site, when data becomes inaccessible or an application fails. Replication can also be used for geographical expansion.
  • Sharing and mounting a file share from another account.