Этот вопрос похож на Лучшие практики для серверов Linux с тонким выделением ресурсов (в VMware)
Однако мой вопрос немного отличается.
У нас есть P2Ved довольно много серверов (win / linux), и нам нужно было использовать копию на уровне блоков, поэтому мы использовали Thin Provisioning при миграции, и мы установили эти серверы в производство, предполагая, что использование Thin Provisioning будет соответствовать фактическим данным, используемым серверов, но мы оказались неправы, так как видим рост VMDK, хотя фактическое использование диска в гостевых виртуальных машинах низкое из-за журналов / резервного копирования / того, что не обрабатывает соприкасающиеся блоки, и VMDK может только расти, а не уменьшаться.
Мы не хотим, чтобы это повлияло на нас ночью, когда хранилище данных полностью заполнится.
Мы посмотрели на такие инструменты, как sdelete / punching zero, однако для этого нам нужно удалить все снимки, что невозможно из-за того, что наша система резервного копирования использует CBT. Также это не работает с Linux.
Мы также рассмотрели предложения, в которых мы должны просто V2V и создать новый диск другого размера, однако это слишком много работы, учитывая, что серверы уже работают.
Вместо того, чтобы вносить радикальные изменения в настройку, я рассматривал возможность использования дисковых инструментов Windows / Linux, чтобы изменить сжатие файловых систем / томов внутри ОС до удобного размера, поэтому даже если одна виртуальная машина использует все свое доступное пространство, Хост не закончится пространства хранилища данных.
Примеры номеров: Наше хранилище данных: 1 ТБ. Предоставленное использование виртуальной машины: фактическое использование виртуальной машины 2 ТБ (100 ГБ)
Теперь, если мы используем инструмент DiskMgmt в Windows, чтобы уменьшить базовый том до 200 ГБ, и в Linux LVM, чтобы изменить LV / VG и раздел примерно на 200 ГБ, таким образом виртуальная машина имеет некоторый запас для роста, но не может расти слишком сильно.
Мой вопрос: будет ли эта работа работать, то есть рост vmdk остановится на размере дисковой части ОС, и станет ли это своего рода промежуточным звеном между тонким / толстым предоставлением, или это не сработает, и скажет, что виртуальные машины с тонкой подготовкой VMDK все равно будут расти намного превышает лимит раздела / объема, который мы установили на уровне ОС?
Один побочный вопрос: что произойдет, если хранилище данных заполнится, сможем ли мы по-прежнему использовать веб-клиент Vsphere / etc или ssh для простого перемещения некоторых виртуальных машин в другое хранилище данных, или это будет чистая катастрофа?
Отвечу на вопрос сам.
Сжатие файловой системы решает проблему, т. Е. Использование диска не превышает определенного предела, однако есть некоторые проблемы, когда файловая система сжимается, ОС перемещает все файлы / упорядочивает их в соответствии с картой дисков в начале раздела, и эта операция фактически приводит к тому, что VMDK, подготовленные Think, вырастают до значительного размера, в 2 раза превышающего фактический.
Лично мы закончили V2Ving каждый сервер с избыточным предоставлением до управляемого размера, и это было намного проще / меньше времени, чем сокращение / игра с уровнем FS.