Я предполагаю, что это должно быть довольно элементарно, но я попытался это сделать, и я прочитал документацию докеров. Тем не менее, я до сих пор не могу понять, что именно означает " Тонкий пул " и роль, которую он играет в мире докеров.
Что означает "тонкий пул" в докере?
Ответ 1
Короткий рассказ:
Тонкий пул - это источник хранения, который обеспечивает распределение по требованию для хранения. Он более или менее похож на виртуальную память, которая обеспечивает полное адресное пространство для каждого процесса.
Длинная история:
Жировое обеспечение
Традиционный метод распределения хранилищ называется "жирным" или "толстым" обеспечением.
Например, пользователь утверждает, что использует пространство хранения 10G. Затем предоставление жиров резервирует 10 ГБ физического пространства для этого пользователя, даже если он использует только 1% от него. Никто не может использовать это зарезервированное пространство.
Тонкая подготовка
Тонкое обеспечение обеспечивает механизм распределения ресурсов по требованию, что позволяет пользователю требовать больше места для хранения, чем физически зарезервировано для этого пользователя.
Другими словами, он позволяет перераспределять пространство для хранения. Подумайте о функции over-commit RAM.
Тонкий бассейн
Тонкий пул - это концептуальный термин, который обозначает источник резервной памяти, используемый тонким обеспечением. Тонкая инициализация выделяет виртуальные куски хранилища из тонкого пула, в то время как предоставление жиров выделяет физические блоки хранения из традиционного пула хранения.
Тонкий бассейн в Докере
Docker Engine может быть настроен на использование Device Mapper в качестве драйвера хранилища. Здесь вы занимаетесь тонкой настройкой. Согласно документации Докера:
Хозяева, использующие драйвер хранилища devicemapper, должны использовать режим direct-lvm. Этот режим использует блокирующие устройства для создания тонкого пула.
Необходимо позаботиться о двух разных пространствах тонкого пула: пространство метаданных (в котором хранятся указатели) и пространство данных (в котором хранятся реальные данные). В самом начале все указатели в метаданных указывают на отсутствие реальных кусков в пуле. Никакой кусок в пространстве данных действительно не выделяется до тех пор, пока не поступит запрос на запись. Это ничего нового, если вы знакомы с механизмом виртуальной памяти.
Позвольте взглянуть на вывод информации о 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
Здесь единственное запутанное - Thin Pool Minimum Free Space. Что это значит?
Он указывает, что минимальное свободное пространство в ГБ в тонком пуле требует успешного создания нового устройства. Эта проверка относится как к свободному пространству данных, так и к свободному пространству метаданных.
Создание контейнера (во время docker pull или docker run) терпит неудачу, если свободное пространство в тонком пуле меньше, чем значение в Thin Pool Minimum Free Space. Недостаточное пространство требует либо добавления большего объема хранилища в тонкий пул, либо очистки неиспользуемых изображений.
Ссылки: