Думаю, большинство читателей в курсе что такое тонкие(thin) диски, их плюсов и минуса. И как с этим минусом бороться.
Вкратце - тонкие диски растут по факту потребления места гостем, но не уменьшаются. Существуют способы, пусть не очень красивые, их "схлопнуть" - основной(раз) и неосновной(два). Суть основного способа в том, что надо обнулить блоки, ранее занятые а потом освобожденные гостем, и затем осуществить Storage vMotion виртуальной машины.
Внезапно, Duncan Epping написал - Blocksize impact?, а Антон Жбанков перевел - Влияние различных размеров блока VMFS, почему первый способ не всегда работает.
Вкратце перескажу и чутка дополню.
Идея в том, что у ESX(i) есть два механизма для переноса данных - старый и новый. Новый более оптимален, но он _НЕ_схлопывает_ тонкий диск по способу раз. Старый механизм переноса - менее оптимален, но тонкие диски схлопывает.
Красивая картинка про различия старого и нового механизмов переноса данных:
Уровни работы трех механизмов копирования данных |
ESX(i) задействует новый механизм всегда, когда может - а не может когда данные переносятся между LUN с разным размером блока VMFS.
Так что при переносе тонкого диска между хранилищами с одним размером блока ESX(i) выберет новый механизм - и перенос будет произведен быстрее, но без схлопывания.
А при переносе между хранилищами с разным размером блока - медленнее, но со схлопыванием.
В комментариях к первоисточнику делятся опытом:
1) ЛУН1 и ЛУН2, оба с блоком = 4 Мб.
2) Создается ВМ с толстым диском = 35 ГБ, внутрь ставится Windows.
3.1) перенос thick диска между LUN с конвертацией его в thin
35 Гб толстый диск до
14.5 ГБ тонкий диск после
3.2) Внутрь тонкого диска дописывается гигабайт данных, затем удаляется. Тонкий диск становится размером 15.5 Гб. Применяется sdelete, обнуляющий все блоки. Тонкий диск вырастает до 100%(!, такой побочный эффект данного промежуточного шага может быть неприятным сюрпризом). Осуществляется SvMotion между LUN, thin -> thin.
35 Гб тонкий диск до
35 Гб тонкий диск после (вот этот факт и является краеугольным)
3.3) Еще одна миграция, с конвертацией тонкого диска в толстый
35 Гб тонкий диск до
35 ГБ толстый диск после
3.4) Обратная миграция, с конвертацией толстый -> тонкий
35 Гб толстый диск до
35 ГБ тонкий диск после (вот опять неприятный момент).
Мораль: если "схлопнуть" тонкий диск надо, то может помочь миграция не просто между хранилищами, а между хранилищами с разным размером блока. А для диска размером больше террабайта, лежащего на хранилище с блоком в 8 Мб, схлопывание таким образом вообще невозможно.
UPD. Надо бы проверить, но возможно схлопывание будет происходить при миграции между стораджами, или, например, между СХД и локальными дисками.
Или, непроверенный способ, в комментариях к первоисточнику упоминается настройка:
есть такая оболочка vsish - только в составе ESXi, вот с ее помощью можно пнуть настройку
и принудительно выключить новый способ переноса данных.
VMFS/EnableDataMovement
1 = yes
0 = no
Description – Whether VMFS should handle data movement requests by leveraging FS3DM
Список доступных через vsish настроек, в том числе скрытых - vSphere ESXi 4.1 - Complete vsish configurations.
Михаил, приветствую!
ОтветитьУдалитьЕсли Вы помните, я вам не очень давно в письме писал про то, что столкнулся с такой проблемой: выполняешь sdelete, делаешь sVmotion - ничего не меняется. Причем действительно, все датасторы у меня с одним размером блока. Получается единственный способ - попробовать применять VMFS/EnableDataMovement.
С уважением, Дмитрий Прокудин
да, и не только вы писали про такое.
ОтветитьУдалитья думаю, что у меня на тестовом стенде получалось по той причине, что я мигрировал между разными стораджами, вернее - со стораджа на локальный диск или обратно. Вроде бы по первоисточнику тоже самый простой механизм в таком случае используется.
если будет возможность - можете попробовать у себя так.