Que signifie "Thin Pool" dans docker?
Je suppose que cela devrait être assez élémentaire, mais j'ai essayé de le rechercher sur Google et j'ai lu le documentation de docker . Cependant, je ne comprends toujours pas ce que signifie exactement " Thin Pool " et le rôle qu'il joue dans le monde des dockers.
Histoire courte:
Un thin pool est une source de stockage fournissant une allocation à la demande d'espace de stockage. C'est plus ou moins similaire à la mémoire virtuelle, qui fournit un espace d'adressage complet à chaque processus.
Longue histoire:
Fat Provisioning
La méthode d'allocation de stockage traditionnelle s'appelle le provisionnement "gros" ou "épais".
Par exemple, un utilisateur prétend utiliser un espace de stockage 10G. Le provisionnement en graisses réserve alors à cet utilisateur un espace de stockage physique 10G, même s'il n'en utilise que 1%. Personne d'autre ne peut utiliser cet espace réservé.
Approvisionnement mince
Thin Provisioning fournit un mécanisme d'allocation de stockage à la demande, qui permet à un utilisateur de réclamer plus d'espace de stockage que ce qui a été physiquement réservé pour cet utilisateur.
En d'autres termes, cela permet une surallocation d'espace de stockage. Pensez à la fonctionnalité de surengagement de la RAM.
Piscine mince
Thin Pool est un terme conceptuel qui désigne la source de stockage secondaire utilisée par le provisionnement fin. Le Thin Provisioning alloue des morceaux de stockage virtuels à partir d'un pool dynamique, tandis que le Fat Provisioning alloue des blocs de stockage physiques à partir du pool de stockage traditionnel.
Thin Pool à Docker
Le moteur Docker peut être configuré pour utiliser Device Mapper comme pilote de stockage. C'est ici que vous traitez avec le provisionnement fin. Selon la documentation de Docker:
Les hôtes de production utilisant le pilote de stockage devicemapper doivent utiliser le mode direct-lvm. Ce mode utilise des périphériques en mode bloc pour créer le pool dynamique.
Il faut prendre en charge deux espaces différents de thin pool: l’espace Métadonnées (qui stocke les pointeurs) et l’espace Données (qui stocke les données réelles). Au tout début, tous les pointeurs de l'espace des métadonnées ne pointent pas vers de véritables morceaux dans le pool. Aucune partie de l'espace de données n'est réellement allouée jusqu'à l'arrivée d'une demande d'écriture. Ce n'est pas nouveau si vous connaissez le mécanisme de la mémoire virtuelle.
Regardons le résultat de docker info:
Data Space Used: 11.8 MB
Data Space Total: 107.4 GB
Data Space Available: 7.44 GB
Metadata Space Used: 581.6 kB
Metadata Space Total: 2.147 GB
Metadata Space Available: 2.147 GB
Thin Pool Minimum Free Space: 10.74 GB
Ici, le seul qui prête à confusion est le Thin Pool Minimum Free Space. Qu'est ce que cela signifie?
Il spécifie le minimum d'espace libre en Go dans un thin pool requis pour la création d'un nouveau périphérique. Cette vérification s'applique à la fois à l'espace de données libre et à l'espace de métadonnées libre.
Création de conteneur (pendant docker pull ou docker run) échoue si l’espace disponible dans le thin pool est inférieur à la valeur dans Thin Pool Minimum Free Space. L'espace insuffisant nécessite soit l'ajout de davantage de stockage dans le pool dynamique, soit le nettoyage des images inutilisées.
Liens: