Показаны сообщения с ярлыком vmfs. Показать все сообщения
Показаны сообщения с ярлыком vmfs. Показать все сообщения

суббота, 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 мегабайт - причин не делать так нет, а такой размер блока применим всегда.

среда, 23 февраля 2011 г.

VMFS troubleshooting

Введение
Наш любимый ESX(i) использует файловую систему VMFS, для размещения на ней виртуальных машин.

Все хорошо, кроме одного - для нее не существует обслуживающих утилит. Никаких undelete, unformat и т.п. Мораль - не делать бекапы еще более опасно, чем обычно.

Вот один из примеров проблемы и шаманства с решением - Пропал VMFS раздел - что делать?

Но проблемы бывают разные. Не очень давно по почте ко мне обращались со схожими вопросами сразу несколько человек: ESX выключился (некорректно, обычно по пропаже питания), после включения VMFS на месте, а вот файлы виртуальных машин заблокированы. Притом заблокированы так, что не то что включить - скопировать(!) не дают.

Перебрав все известные мне способы попиннать по колесам, я развел руками и посоветовал обратиться в поддержку.

В одном случае обратились - и проблема быстро была решена, путем внесения правок в структуру файловой системы.
(кстати, для тех кто не имеет привычки обращаться в поддержку - у VMware первая линия стала русскоязычной, а продукты VMware без поддержки не продаются - так что обращаемся резко, решительно в случае странных проблем.)

А во втором случае поддержки не было, и нужда заставила найти выход :-)
По результатам изысканий и успешного выколупования данных со мной поделились ранее мне незнакомой утилитой vmfs-tools из состава лайв сд. Эта утилита позволяет подмонтировать раздел VMFS к другой операционной системе.
Запустив ESX сервер с этого live cd  данные с VMFS тома удалось вытянуть.


Монтирование VMFS из под Linux
Разумеется, мне стало интересно, и я поигрался с этой утилитой.
На локальном диске тестового ESX располагается очень нужная мне виртуальная машина (рис.1).
Рис.1. ВМ на локальном диске ESX

Скачал ISO этого live cd, загрузил с него свой тестовый ESX, и вот что увидел (рис.2):
Рис.2. Свежезагрузившийся Live CD
Так как видеть только командную строку лично мне достаточно грустно - я порадовался :-)
Итак, моя задача - получить доступ к разделу VMFS. Посмотрим информацию по разделам соответствующей утилитой - она единственная в местном трее (рис. 3)
Рис.3. Просмотр информации об имеющихся разделах

Следующий шаг - подмонтировать этот раздел.Создадим каталог - точку монтирования, у меня это будет каталог vmfs в корне (рис. 4).

Рис.4. Раздел vmfs создан (слева), и пуст(справа)
Я не большой любитель командной строки, поэтому воспользовался Midnight Commander.
Но к командной строке обратиться все таки придется - откроем терминал и воспользуемся командой "vmfs":

root@PartedMagic:~# vmfs /dev/sda5 /vmfs

Здесь выполнена данная команда, первым параметром на вход ей передан путь к диску с VMFS (здесь это локальный диск сервера), вторым - точка монтирования (ранее мною созданная папка vmfs в корне диска).
И - вуаля (рис.5).
Рис.5. Данные с тома VMFS доступны из под Linux
Сравните правую часть рис.5 с рис.1.
Монтирование осуществляется в read-only режиме - для вытаскивания данных более чем достаточно.

Недолгое гугление нашло мне еще одну ссылку по использованию этой утилиты - из под Ubuntu - Using linux vmfs-tools package to access virtual machines. Там немного другие названия и использование - то ли разные версии с описываемым live cd, то ли что.

Однако на этом мои опыты не закончились.

Монтирование VMFS из под Windows, в том числе

Я вспомнил, что ранее встречал упоминание о каком-то java-драйвере под vmfs. Года три назад я даже пробовал его в деле - но не заработало. Решил попробовать еще раз.

Я нашел его тут - Open Source VMFS Driver.

Эта штука позволяет получить доступ к разделу VMFS с сервера Windows/Linux/Mac OS, где достаточно установленной Java.

Вооружившись Microsoft iSCSI Initiator, я подключился со своего ноутбука к iSCSI LUN с VMFS. Таким образом, в Дистпетчере Дисков я увидел еще один диск (рис.6).
Рис.6. Диск с VMFS, подмонтированный к Windows XP

Следующий шаг - загрузить непосредственно драйвер (и поставить Java если ее еще нет).
После этих действий проверяем работоспособность утилиты получением хелпа по ней:
C:\Program Files\Java\jre6\bin>;java -jar D:\vmfs_r95\fvmfs.jar
VMFSTools (C) by fluid Operations (v0.9.8.18 r95 / 2010-01-25_15-57-35)
http://www.fluidops.com

Arguments:
  VMFSVolume info
  VMFSVolume dir path
  VMFSVolume dirall path
  VMFSVolume cat path
  VMFSVolume fileinfo path
  VMFSVolume filecopy path [newname position size]
  VMFSVolume filedump path position size
  VMFSVolume showheartbeats
  VMFSVolume webdav [host port]

VMFSVolume can be any mounted VMFS volume, or a volume reachable by SSH/SFTP.
Multiple VMFS extents can be specified using a comma-separated list.
Examples:
  \\sambaserver\luns\bigdisk dir /Linux_VMs
  ssh://root:passwd@linuxhost/mnt/vmfslun fileinfo /disks/SwapDisk-flat.vmdk
  \\.\PhysicalDrive3,\\.\PhysicalDrive4 filecopy /Windows-Template/W2008.vmdk x:\recover\W2008.vmdk

C:\Program Files\Java\jre6\bin>;

Таким образом, надо выполнить команду
java -jar D:\vmfs_r95\fvmfs.jar
передав ей первым параметром путь к диску с vmfs, а вторым - действие.
Я путь ей буду передавать как путь к диску Windows.

Для начала - получим информацию о разделе:

C:\Program Files\Java\jre6\bin>java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive1 info
VMFSTools (C) by fluid Operations (v0.9.8.18 r95 / 2010-01-25_15-57-35)
http://www.fluidops.com

VMFS label         = iSCSI_LUN_1_main
VMFS creation date = Fri Jul 24 23:08:51 MSD 2009
VMFS capacity      = 14.50 GB
VMFS UUID          = 4ba75d25-3be4b8df-c372-000c29e78205
VMFS block size    = 1.00 MB
VMFS version       = 3.33
VMFS # of FD/PB/SB = 30720 / 14600 / 3968
VMFS volume type   =
VMFS volume UUID   = 4ba75d25-28b9a16d-2f81-000c29e78205
VMFS volume size   = 14.50 GB
VMFS volume ver    = 4

C:\Program Files\Java\jre6\bin>

Вот когда это у меня получилось - я обрадовался. Вау, работает! :-)

Затем получим список содержимого:

C:\Program Files\Java\jre6\bin>java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive1 dir /
VMFSTools (C) by fluid Operations (v0.9.8.18 r95 / 2010-01-25_15-57-35)
http://www.fluidops.com

10/20/10 05:19:19           (dir) /.dvsData
07/24/09 23:08:51         163а840 /.fbb.sf
07/24/09 23:08:51      63а143а936 /.fdc.sf
07/24/09 23:08:51      60а817а408 /.pbc.sf
07/24/09 23:08:52     260а374а528 /.sbc.sf
07/24/09 23:08:52       4а194а304 /.vh.sf
02/02/11 19:27:13           (dir) /File_Server_Win2008_1
10/01/10 13:18:34           (dir) /main_win2003_template 

C:\Program Files\Java\jre6\bin>

Все так и есть - если заглянуть из интерфейса vSphere, увидим все то же самое (рис. 7).
Рис.7. Просмотр содержимого раздела VMFS средствами vSphere

Следующий шаг - получение доступа к данным. Не вопрос:
C:\Program Files\Java\jre6\bin>java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive1 filecopy
 /File_Server_Win2008_1/File_Server_Win2008.vmdk
VMFSTools (C) by fluid Operations (v0.9.8.18 r95 / 2010-01-25_15-57-35)
http://www.fluidops.com

Size = 626.00 Bytes
Copied 626 bytes in 0s throughput was 39 KB/s

C:\Program Files\Java\jre6\bin>java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive1 filecopy
 /File_Server_Win2008_1/File_Server_Win2008-flat.vmdk
VMFSTools (C) by fluid Operations (v0.9.8.18 r95 / 2010-01-25_15-57-35)
http://www.fluidops.com

Size = 10.00 GB
Copying file -- bytes left=10663493632 throughput=29393 KB/s ETA=362s
...
тут типа прогресс бар, но я сделал монтаж
...

C:\Program Files\Java\jre6\bin>

Здесь не совсем монтирование раздела - здесь команда выгрузки конкретного файла.
Получаем наши vmdk(рис.8)
Рис.8. Бекап удался
Насчет "бекап удался" я слегка соврал - на середине процесса копирование оборвалось - но я не стал разбираться пока, разовая это проблема или нет.

Напоследок расшарим подмонтированный VMFS:
C:\Program Files\Java\jre6\bin>java -jar D:\vmfs_r95\fvmfs.jar \\.\PhysicalDrive1 webdav
VMFSTools (C) by fluid Operations (v0.9.8.18 r95 / 2010-01-25_15-57-35)
http://www.fluidops.com

*** Serving WebDAV/HTTP at http://localhost:50080/vmfs
log4j:WARN No appenders could be found for logger (org.mortbay.log).
log4j:WARN Please initialize the log4j system properly.

К сожалению, подключить к Windows как сетевой диск мне не удалось, хотя в хелпе написано что можно; а вот браузером зашлось нормально(рис.9,10).
Рис.9. Просмотр содержимого vmfs раздела через браузер, корень раздела

Рис.10. Просмотр содержимого vmfs раздела через браузер, каталог ВМ
В общем, за сегодня я значительно прокачал свои навыки неклассических доступов к разделам VMFS.

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

понедельник, 28 июня 2010 г.

VMFS resignaturing

Из переписки:

Михаил, приветствую!
У меня такая проблема, может посоветуете чего...
Вкратце, что есть:
Два ЦОД, репликация данных посредством СХД
Настроен boot from SAN на обеих площадках.
При переезде с одной площадки на другую, ESX4 грузится, но теряет все виртуалки из инвентори, которые на нем должны быть, как следствие, не поднимется VC, и все остальное. Тома ESX-ы РЦОД видит как snap-xxxxxxx, т.к. изменился LUN ID.
По Вашей книге необходимо проводить действия вручную через VC client. Но это нам не подходит из-за большого кол-ва ESX(40) и виртуальных машин(200).
Подскажите, пожалуйста, как сделать автоматическое поднятие всего ЦОД на РЦОД?
В какую сторону копать?
Что я ответил:
Приветствую.
вообще, решать именно вашу задачу призван продукт VMware site recovery manager.
кроме разного полезного прочего он и описанную проблему решает сам.
правда, он стоит денег.
если без него, то единственное, что приходит на ум — это поразбираться, решается ли данная проблема скриптами.
Кроме скриптов я тут вариантов не вижу.
Решается ли это на скриптах (локальных в Service Console, vSphere CLi или PowerCLI) я просто не помню — не приходилось такую задачу решать.
Почему так: потому что в ESX(i) 4 поменялся механизм работы с такими ЛУНами. Какими “такими” и откуда вообще проблема берется, напомню.
1) Вкратце: когда создается VMFS на каком-то LUN, кроме прочего в метаданные записывается номер этого LUN. Если этот номер меняется, то ESX(i) не дает обратиться к такому LUN.
Почему? Потому что такая ситуация обычна для репликации\снапшотов СХД — мы реплицируем LUN с номером X на LUN с номером Y — и в VMFS на Y прописано, что номер LUN=X. И если на LUN Y начать что-то писать, процесс репликации нарушиться (ну или записать нам не дадут — в любом случае это не дело). Вот ESX(i) обучен не обращаться к LUN’ам с таким расхождением, т.к. это является характерным признаком реплики LUN.
Подробнее про это и другое про VMFS можно посмотреть тут — Устройство VMFS-раздела.
2) Если надо таки дать доступ к такому LUN (например см. вот тут — Траблшутинг ESXi, и без всяких репликаций такая задача может встать), то
В третьей версии VMware Infrustructure надо было сделать так:
1. Закладка «Configuration»
2. Advanced Settings
3. В разделе LVM, изменить LVM.EnableResignature на 1 (по умолчанию 0)
4. В Storage Adapters сделайте "Rescan«
5. Хранилище VMFS должно появится (под другим именем)
6. Установить EnableResignature обратно в 0
7. Вручную зарегистрировать ВМ на хостах.
3) А в четверке уже не так — заходим в мастер добавления хранилища, видим там наш LUN, и

мастер предложит нам добавить этот VMFS без форматирования и удаления данных.
Суть поста вот в чем: мне сообщили, что старый, от тройки, способ все равно продолжает работать, правда, из командной строки:
Приветствую.
Мне помогла такая вещь:
esxcfg-advcfg -s 0 /LVM/DisallowSnapshotLUN

решение работает, резервный ЦОД запустился!!
+ дописать в vmx uuid.action = «keep»
А я, пока искал инфу для этого поста, обнаружил что писал таки про способ сделать это в четверке из CLI:

Вот в комментариях подсказали правильную ссылочку с информацией поподробнее: http:/kb.vmware.com/kb/1011387.

thx Александру Черкашину.

пятница, 29 мая 2009 г.

vmfs recovery

К вопросу трабшутинга VMFS.

Единственное официальное, да и просто единственное средство для восстановления ВМ в случае краха VMFS раздела(имеется в виду логическое повреждение метаданных раздела, разумеется) - так вот, единственное средство восстановления это доступный с выходом Update 3 для ESX 3.5 скрипт VMDK Recovery Tool.

К сожалению, не все так просто:
этот скрипт осуществляет сохранение информации о том, каким vmdk соответствуют какие блоки. Теперь, имея этот бекап, в случае сбоя VMFS можно будет восстановить vmdk файлы наших ВМ. Т.е. предполагается запуск этого скрипта на работающей системе, заранее. Это не единственное ограничение: по моему, до сих пор не поддерживается(не работает?) на ESXi, то же самое для ВМ с RDM, и еще некоторые - см. описание на сайте VMware.

Так вот.
Камрад Leo Raikhman взял в руки напильник и немного довел это средство до ума - Revisiting VMFS 3 Recoverability.

Если установить в SC подготовленный им rpm, то создаться задание в планировщике, которое по расписанию и автоматически(исходный скрипт работает только в интерактивном режиме) будет создавать список блоков для vmdk файлов всех ВМ, работающих на хосте. Кроме того, бекапиться будут и vmx\vmtx файлы(оригинальный скрипт ограничивается лишь vmdk). Таким образом, в случае целевых для этого средства сбоев(например, случайное удаление ВМ), восстановление ВМ в строй займет меньше времени.





воскресенье, 24 мая 2009 г.

vmfs recovery

К вопросу восстановления VMFS.
Камрад jbod оставил интересный комментарий к посту Траблшутинг ESXi:

Также, после нештатного отключения, перестал загружаться ESX3.5iU2.
Под ESX крутилось несколько Windows и FreeBSD серверов. Вот один из FreeBSD серверов и надо было спасти.
Методом, который описан выше, восстановить работу ESX не удалось.
Проверка VMFS утилитой fvmfs.jar (http://code.google.com/p/vmfs/)
показала, что VMFS поврежден.
После недели экспериментов все-же удалось вытащить требуемый образ
FreeBSD сервера, путем поиска в VMFS сигнатуры MBR и попытки
стартовать с этого адреса в виртуальной машине.
..
в двух словах так :
Сделал Live Ubuntu 8.10 USB Persistent 4 Gb флэшку (http://www.pendrivelinux.com/).
Предварительно скопировал раздел (~ 500 Gb) с VMFS на тестовый сервер, так же как раздел.
Загрузился в Ubuntu на тестовом сервере (в принципе это может быть и любой другой компьютер или даже упавший сервер, главное что бы из Ubuntu была возможность читать том/раздел/диск/файл с VMFS).
В Ubuntu установил Qemu. После чего смонтировал раздел с VMFS и искал первые шестнадцать байт (я выбрал столько) Master Boot Record. Вначале я искал вручную c помощью hex редактора, потом надоело )) и я написал поиск на С. При нахождении заданной последовательности, начиная с первого байта, монтировал через losetup. После чего этот loop подсовывал Qemu, как образ VM и запускал ее. После нескольких неудачных попыток, нужный образ сервера был найден. Так же хочу особо отметить что на моем ESX сервере, VM создавались последовательно и оставалось свободное пространство на VMFS, т.е. образ VM располагался линейно.

C учетом того, что принципиальных изменений в VMFS для ESX 4 не произошло, все актуально и для vSphere.