преобразование наследования узла к hiera
Я предполагаю, что Вы ожидаете, что самое большое усиление из dedup прибудет из части ОС образов виртуальной машины. В этом случае, если бы Ваши VMs не являются клонами друг друга, то я сказал бы, что 128 кибибайт являются слишком большим блоком для оптимального dedup. Если бы Ваше узкое место является сетевой и более эффективной дедупликацией, было бы полезно, я пошел бы путем вниз. Если бы Вы дедуплицируете образы дисков, то оптимальный размер был бы минимальной единицей уровня ОС VM выделения. В Linux это - блок 4 КБ (по умолчанию) в ext3 и ext4 файловых системах. С большими размерами блока обращают внимание на разделение, можно было сместить идентичные системы наполовину dedup-размер-блока из-за различных разметок виртуального диска.
Трудно дать лучший ответ с довольно неопределенным вопросом.
Вы можете сделать это на стороне клиента, используя пользовательский факт вместо параметра puppet.conf . Однако я бы сказал, что делайте это на стороне сервера, в данных Hiera. Уловка, которую я использую для чего-то похожего, заключается в следующем:
Задайте что-нибудь в данных Hiera на уровне
clientcertдля каждого сервера. В вашем случае:realm: "pre-prod"Захватите эту переменную в глобальную область видимости через Hiera в
site.pp, перед вашимhiera_include:$ realm = hiera (realm) hiera_include (классы)Переменная была получена из файла
clientcert.yamlи теперь будет использоваться в поисках, которые происходят из вашегоhiera_include, извлеченного изpre-prod.yamlна основе конфигурации"% {realm}"в вашей иерархии.