Storage

There are at least as many storage solution than different hypervisors :-).

Storage can be on the cloud (Azure blob storage, ADLS, S3) or local and we hope to support it in the very near future, thanks to Terraform cloud infrastructure control.

When speaking about local installation or low level, physical disks are aggregated using the notion of physical volume groups. These PVS are usually choosen depending on the capabilities of the drives: do they handle hot plug, are they redundant, efficient ?

Logical volumes

These volume groups can then be split into several logical volume groups these LVMs are usually in place to seggregate the kind of data which is saved:

  • Is it business critical, like the photo of your 18 years old son when he was born.

  • Or is it to store data which you do not really care, like your more-than-a-year-old system logs.

Thinpools

These logical volume groups can be auto extending, meaning that at first they only have the minimal size, then extends by themselves as long as you add data on them.

A thinpool is made of two logical volumes: a fixed one to store the pool metadata (main thinpool configuration) and an other one for the effective pool.

NFS

Network file systems are mounted harddisks through network.
These filesystem are protected by kerberos, particularly with the help of the ansible-volume role.

However sometimes, the kerberos tickets expires.

Here’s a recipe to renew all tickets on each hosts. On the datastore host

sudo kdestroy
sudo kinit admin
sudo ipa-rmkeytab -p nfs/nfs.example.com -k /etc/krb5.keytab
sudo ipa-getkeytab -p nfs/nfs.example.com -k /etc/krb5.keytab
sudo ipa-rmkeytab -p host/nfs.example.com -k /etc/krb5.keytab
sudo ipa-getkeytab -p host/nfs.example.com -k /etc/krb5.keytab

On the client host

sudo kdestroy
sudo kinit admin
sudo ipa-rmkeytab -p host/client.example.com -k /etc/krb5.keytab
sudo ipa-getkeytab -p host/client.example.com -k /etc/krb5.keytab