What Are the Differences Among CCE Storage Classes in Terms of Persistent Storage and Multi-node Mounting?
Container storage provides storage for container workloads. It supports multiple storage classes. A pod can use any amount of storage.
Currently, CCE supports local volumes, EVS volumes, SFS volumes, SFS Turbo volumes, and OBS volumes. For details on how to use these volumes, see Overview to Storage Management.
Table 1 lists the differences among these storage classes.
| Storage Class | Persistent Storage | Automatic Migration with Containers | Multi-node Mounting |
|---|---|---|---|
| Local volumes | Supported | Not supported | Not supported |
| EVS volumes | Supported | Supported | Not supported |
| OBS volumes | Supported | Supported | Supported. This type of volumes can be shared among multiple nodes or workloads. |
| SFS volumes | Supported | Supported | Supported. This type of volumes can be shared among multiple nodes or workloads. |
| SFS Turbo volumes | Supported | Supported | Supported. This type of volumes can be shared among multiple nodes or workloads. |
Selecting a Storage Class
You can use the following types of storage volumes when creating a workload. You are advised to store workload data on EVS volumes. If you store workload data on a local volume, the data cannot be restored when a fault occurs on the node.
- Local volumes: Mount the file directory of the host where a container is located to a specified container path (corresponding to HostPath in Kubernetes). Alternatively, you can leave the source path empty (corresponding to EmptyDir in Kubernetes). If the source path is left empty, a temporary directory of the host will be mounted to the mounting point of the container. A specified source path is used when data needs to be persistently stored on the host, while EmptyDir is used when temporary storage is needed. A ConfigMap is a type of resource that stores configuration information required by a workload. Its content is user-defined. A secret is a type of resource that holds sensitive data, such as authentication and key information. Its content is user-defined. For details, see Using Local Disks as Storage Volumes.
- EVS volumes: Mount an EVS volume to a container path. When the container is migrated, the mounted EVS volume is migrated together. This storage class is applicable when data needs to be stored permanently. For details, see Using EVS Disks as Storage Volumes.
- SFS volumes: Create SFS volumes and mount them to a container path. The file system volumes created by the underlying SFS service can also be used. SFS volumes are applicable to persistent storage for frequent read/write in multiple workload scenarios, including media processing, content management, big data analysis, and workload analysis. For details, see Using SFS File Systems as Storage Volumes.
- OBS volumes: Create OBS volumes and mount them to a container path. OBS volumes are applicable to scenarios such as cloud workload, data analysis, content analysis, and hotspot objects. For details, see Using OBS Buckets as Storage Volumes.
- SFS Turbo volumes: Create SFS Turbo volumes and mount them to a container path. SFS Turbo volumes are fast, on-demand, and scalable, which makes them suitable for DevOps, containerized microservices, and enterprise office applications. For details, see Using SFS Turbo File Systems for Storage.
If an EVS volume is used, you must manually configure a backup policy for it. For details, see VBS Backup Management.
Did this article solve your problem?
Thank you for your score！Your feedback would help us improve the website.