| title | description | lang |
|---|---|---|
Data Services |
What data services are available for docker containers and swarm services? |
en-US |
Can I limit the space a volume takes? Currently running out of space is show stopper for applications.
Storidge create volumes from a shared storage pool. Most Storidge volumes are thin provisioned (thick provisioning available also) at specified capacity. If the capacity is not grown, that's the limit the application is allowed to consume. Storidge provides event messages at 70%, 80% and 90% volume capacity used, so operators can take steps to grow capacity using resources from the storage pool.
In addition, Storidge has an auto expansion service. When a pre-defined capacity threshold is crossed, the volume is automatically increased at both the block and file system level. The capacity expansion happens while the application is online, which means there is no disruption to the application. See the guide on auto capacity expansion
What is the impact of data locality on read performance and latency? For instance, after node fails and volume moves to a new node.
After the volume from the failed node is moved, as host I/Os comes in on the new node, locality rebuild is triggered if data is not found locally. Capacity is allocated locally and a copy of data is copied to the node (i.e. data is rebuilt), while a remote copy of the data is deallocated. So the penalty is only on the first read as subsequent reads will read the local copy.
The entire volume does not need to be rebuilt as a containerized application and its volume may eventually be rescheduled to other nodes for various reasons.
For more info, read the Effortless Data Locality blog
Yes, Storidge supports the concept of an interface container for NFS. This puts a stateless NFS container in front of any volume and allows access to the NFS share from anywhere in the cluster or outside the cluster.
Possible use case are 1) easy sharing of data between containerized workloads and apps running in virtual servers on the local subnet, 2) migrating data from outside the Storidge cluster to containerized workloads running in the cluster.
Multi access to a volume across a cluster of nodes requires a shared volume. Storidge allows any volume to be turned into a shared volume through an NFS interface container. This associates a stateless NFS container with the volume which travels with the volume if it is rescheduled to a different node. Since the NFS container is assigned a persistent IP address off a macvlan interface, this means moving the shared volume to a new node is transparent to the service replicas using it, e.g. on a node failure.
On the backend as host I/Os are received by the NFS instance, the I/Os are passed through the file system to the shared volume presented by our block device driver. The replication for the volume happens at the block level and is strictly consistent.
There are three compression methods supported; LZO, ZLIB, and ZSTD. There are speed and compression ratio trade-offs between the three methods:
ZLIB - slower but with higher compression ratio
LZO - faster compression and decompression than zlib, but worse compression ratio. It is designed to be fast
ZSTD - compression is comparable to zlib with higher compression/decompression speeds
The differences will depend on your data set. You can run benchmarks to select the best fit. However LZO should give satisfying results for general use.
Compression has to be specified at volume creation since it is enabled when mounting the filesystem on the volume.
Enabling compression after volume creation entails stopping the service/application, unmounting the filesystem, and remounting with compression enabled. This would be disruptive to the application.