суббота, 26 февраля 2011 г.

thin vmdk shrik. Как уменьшить размер тонкого (thin) диска


Мне захотелось проверить и резюмировать то, как же можно схлопнуть тонкий диск.

Сначала резюме:
После стандартных действий по обнулению выделенных, а затем освобожденных блоков, следует выполнить миграцию "схопываемого" диска с выполнением одного из следующих условий:
  • миграция должна происходить между хранилищами на разных системах хранения.
    SAN -> NAS
    SAN -> локальные диски
    один SAN сторадж -> другой SAN сторадж;
  • миграция должна происходить пусть внутри одной системы хранения, но у VMFS хранилищ должны быть блоки разного размера;
  • миграция может происходить внутри одной СХД, между хранилищами с одинаковыми блоками - но с изменением кое-какой глубинной настройки. Только для ESXi.
А теперь подробности.
С недавно полученных гонораров за книгу я прикупил аж двухтеррабайтный диск в свою тестовую лабораторию, и ставши куда менее ограниченным в дисковом пространстве, решил поиграться со "схопыванием" тонкого диска, о нюансах которого был большой пост недавеча - thin shrink, VMFS blocksize.

Организация теста
Я создал 3 LUN на iSCSI СХД,
на двух из них VMFS с блоком = 8 МБ,
и на одном с блоком = 4 МБ.
Плюс к тому, добавил локальный диск с блоком размером 8 МБ на один из хостов.
И еще создал NFS-хранилище.

Развернул из шаблона виртуальную машину, с тонким диском, на хранилище с блоком в 8МБ. Диск тонкий, данных мало (рис.1).
Рис.1. тестовая ВМ, занимает мало места на хранилище с блоком 8 МБ
Следующий шаг - имитация разрастания тонкого диска и повода к схлопыванию. Копирую на диск ВМ данные объемом около 3 Гб, затем удаляю их (рис.2).

Рис.2. Добавление данных на диск ВМ, затем удаление


Очевидно, тонкий диск увеличивается, и не уменьшается(рис.3).
Рис.3. Тонкий диск увеличился
 Загружаем sdelete, применяем его внутри этой ВМ:
C:\>sdelete -c c:\

SDelete - Secure Delete v1.51
Copyright (C) 1999-2005 Mark Russinovich
Sysinternals - www.sysinternals.com

SDelete is set for 1 pass.
Free space cleaned on c:\


C:\>

И теперь необходимо выполнить Storage vMotion (ну или миграцию выключенной ВМ) для того, чтобы диск ВМ уменьшился.

Тестирование
Сама суть моего тестирования - проверить, а куда и откуда нужно мигрировать ВМ для того, чтобы SVmotion схлопнул ее тонкий диск.

Сейчас ВМ использует хранилище с iSCSI SAN, блок 8 МБ.
Тесты я планирую такие
1) Между LUN одной схд, один размер блока. SAN 8 MB -> SAN 8 MB
2) Между LUN одной схд, разный размер блока. SAN 8 MB -> SAN 4 MB
3) Между LUN схд и локальным хранилищем, один размер блока. SAN 8 MB -> local 8 MB
4) Между LUN схд и NFS-хранилищем. SAN 8 MB -> NFS
5)  Между LUN одной схд, один размер блока. SAN 8 MB -> SAN 8 MB, но попробовать через глубинную опцию принудительно использовать старый механизм копирования, схопывающий тонкие диски.

Для того чтобы слегка упростить себе задачу - я клонировал на исходном хранилище подготовленную к "схлопыванию" ВМ.

Итак, поехали.
1) миграция - внутри СХД, блоки на хранилищах одного размера. Схлопывания не произошло (рис.4).
Рис.4. Тест 1

2) миграция внутри СХД, блоки на хранилищах разного размера. Тонкий диск схлопнулся (рис.5).
Рис.5. Тест 2

3) миграция между СХД (между СХД и локальным диском), блок одного размера. Диск схлопнулся (рис. 6).
Рис.6. Тест 3


4) миграция с VMFS хранилища на NFS хранилище. Схлопывание произошло(рис.7).
Рис.7. Тест 4


5) Наконец, повторяем первый тест, но сначала зайдем на ESXi по ssh и выполним следующие команды:
~ # vsish
/> set /config/VMFS3/intOpts/EnableDataMovement 0

Эта настройка предписывает использовать только старый механизм перемещения данных - который решает нашу задачу.

Теперь запускаем миграцию между хранилищами внутри одной СХД, с одинаковым размером блока. Схлопывание произошло(!) (рис. 8).
Рис.8. Тест 5
Потом только стоит не забыть вернуть в ssh и восстановить значение ранее измененной настройки:


~ # vsish
/> set /config/VMFS3/intOpts/EnableDataMovement 1



Комментарии

Обратите внимание на связанный момент:
во всех случаях, кроме первого, использовался менее производительный механизм для миграции данных. Напомню картинку из исходных постов:

Вот если задействуется механизм, показанный красной линией, старый - он схлопывает тонкие диски.
А два более новых механизма - не схлопывают, зато работают быстрее.
Вот интересная страница коммьюнити VMware - Blocksize matters!
А там таблица:
Миграция между LUN одного стораджа, с задействованием нового и старого механизмов.
Разница в 4-5 раз. И это даже без VAAI.

Мораль - для скорости лучше, чтобы использовались новые механизмы.
Для "схлопывание" тонких дисков - обязательно нужно старый.

А для того, чтобы обычно использовались новые механизмы -  
блоки VMFS на всех наших хранилищах должны быть одного размера.
 И лучше, чтобы этот размер был бы 8 мегабайт - причин не делать так нет, а такой размер блока применим всегда.

28 комментариев:

  1. но на Linux не работает, использую CentOS 5.5, один сторедж, различные блоки

    ОтветитьУдалить
  2. http://www.yellow-bricks.com/2011/02/24/storage-vmotion-performance-difference/
    >>please note, that VAAI is not used

    ОтветитьУдалить
  3. Спасибо за vaai

    про Linux, признаться, не в курсе до конца. Мне казалось что для него должно примерно так же работать.. надо будет поразбираться

    ОтветитьУдалить
  4. Миша я что-то не понял
    "миграция между СХД (между СХД и локальным диском), блок одного размера. Диск схлопнулся"

    выходит что при копировании с SAN LUN на Local LUN , используется стары датамовер ?, так как размер блока одинаковой и диск схлопнылся, или я что-то не понял ?

    ОтветитьУдалить
  5. судя по тому, что я читал - при миграции между хранилищами на разных системах (в частности, между SAN и локальным диском, или между одним SAN и другим SAN) - да, используется старый способ.

    ОтветитьУдалить
  6. Михаил, а при создании ovf диски не схлопываются? Проверить пока нет возможности (

    ОтветитьУдалить
  7. я уверен что да - но через ovf это не то что будет простой - а будет потеряна куча времени, пока туда сюда выгрузишь загрузишь.

    для оффлайн схлопывания лучше подключить к ВМ новйы тонкий диск, загрузиться с лайв сд и при помощи ghost\acronis\т.п. перелить образ.

    ОтветитьУдалить
  8. Про простой понятно. У нас как раз про это вопрос не стоит. У нас стендэлоне фриварные хосты. А овф-тулсами мы клонируем системы.
    Кстати, не совсем по теме вопрос к Вам, как гуру - дозволяется ли использовать один лицензионный ключ к куче фриварных ESXi хостов?

    ЗЫ: спасибо, большое человеческое за книгу и за сайт!

    ОтветитьУдалить
  9. признаться, не вчитывался в лицензионное соглашение бесплатной лицензии - так что юридически верно ответить затруднюсь.

    спасибо :-)

    ОтветитьУдалить
  10. а хитрой консольной команды нет, чтобы данные не таскать ?

    ОтветитьУдалить
  11. Михаил, ещё есть засада с sdelete - похоже, что в случае thin-диска она вызывает рост файлов vmdk до показанного размера (provisioned size) и можно попасть на кончину места на LUN.

    ОтветитьУдалить
  12. Михаил, у нас есть, факт. И довольно неприятный т.к. чуть не тормознули боевые машины на кластере vSphere (место могло кончиться).

    ОтветитьУдалить
  13. странно.

    попробую поизучать вопрос.

    ОтветитьУдалить
  14. Делал через sdelete -c D: , перед этим вирт. диск НЕ дефрагментировал (т.к. думаю что смысла в этом нет).

    ОтветитьУдалить
  15. дефрагментация скорее всего бессмыслена для thick дисков, и строго противопоказана thin дискам.

    ОтветитьУдалить
  16. Сегодня проверил результат sdelete на 2 дисках. Место распухло, факт. Перегнал на другое хранилище с размером блока 8 МБ (на исходном - 4 МБ), диски "подсохли"...

    ОтветитьУдалить
  17. На VMFS5 установка /config/VMFS3/intOpts/EnableDataMovement не оказывает никакого влияния. Аналогичной настройки для VMFS5 нет (или я не нашел).

    ОтветитьУдалить
  18. А в как это проделать в Windows 2008R2, как я понимаю sdelete там не работает?

    ОтветитьУдалить
  19. Есть еще один неприятный факт, парни, при использовании чуднОй утилиты sdelete с ключем "-с" - после применения команды "sdelete -с " при использовании Veeam Backup&Replication 6.0 в качестве бакапа, время бекапирования увеличивается в 4 раза! Помогает команда "sdelete -z " , но при этом provisioned space thin-диска становится максимальным.

    ОтветитьУдалить
  20. размер тонкого диска, как мне казалось, становится максимальным с обоими ключами, нет?

    вы пробовали в четверке или пятерке?

    ОтветитьУдалить
  21. Подскажите, как сделать так, чтобы уменьшился и provisioned size? У меня был thick-диск на 20 ГБ. Я по незнанию увеличил его до 200 ГБ, а назад - не вышло. Потом с помощью миграции с хоста на СХД и обратно удалось "схлопнуть диск" до 19 ГБ. Но как теперь вернуть thick-диск с provisioned size, равным 20 ГБ, а не 200?

    ОтветитьУдалить
  22. 1) правльный путь - создать диск размером 20, затем взять ghost\acronis\что-то еще и перелить образ с большого на маленький.

    2) нормальный путь - взять vmware converter, перенести им эту вм на тот же сервер - но по ходу дела он предлоижт уменьшить диск.

    3) неправильный путь - уменьшить внутри партицию (если она была увеличена), затем отредактировать файл-заголовок vmdk на меньший размер.

    ОтветитьУдалить
  23. С Acronis'ом я пробовал - как ни крутил, не удалось запустить винду на склонированном диске.
    Спасибо за варианты. Сейчас пробую конвертером: не получается перенести виртуалку "саму в себя". Если выбираю в качестве Destination другое имя, то не могу найти, где можно уменьшить диск. Можно подробнее, пожалуйста?

    ОтветитьУдалить
  24. нет под рукой чтобы проверить, но вроде на шаге options пункт data to copy

    ОтветитьУдалить
  25. Спасибо, нашёл. Всё получилось =)

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.