Мы уже некоторое время назад писали про различные особенности томов VMFS, где вскользь касалисьпроблемы блокировок в этой кластерной файловой системе. Как известно, в платформе VMware vSphere 5 реализована файловая система VMFS 5, которая от версии к версии приобретает новые возможности.
При этом в VMFS есть несколько видов блокировок, которые мы рассмотрим ниже. Блокировки на томах VMFS можно условно разделить на 2 типа:
Блокировки файлов виртуальных машин
Блокировки тома
Блокировки файлов виртуальных машин
Эти блокировки необходимы для того, чтобы файлами виртуальной машины мог в эксклюзивном режиме пользоваться только один хост VMware ESXi, который их исполняет, а остальные хосты могли запускать их только тогда, когда этот хост вышел из строя. Назвается этот механизм Distributed Lock Handling.
Блокировки важны, во-первых, чтобы одну виртуальную машину нельзя было запустить одновременно с двух хостов, а, во-вторых, для их обработки механизмом VMware HA при отказе хоста. Для этого на томе VMFS существует так называемый Heartbeat-регион, который хранит в себе информацию о полученных хостами блокировок для файлов виртуальных машин.
Обработка лока на файлы ВМ происходит следующим образом:
Хосты VMware ESXi монтируют к себе том VMFS.
Хосты помещают свои ID в специальный heartbeat-регион на томе VMFS.
ESXi-хост А создает VMFS lock в heartbeat-регионе тома для виртуального диска VMDK, о чем делается соответствующая запись для соответствующего ID ESXi.
Временная метка лока (timestamp) обновляется этим хостом каждые 3 секунды.
Если какой-нибудь другой хост ESXi хочет обратиться к VMDK-диску, он проверяет наличие блокировки для него в heartbeat-регионе. Если в течение 15 секунд (~5 проверок) ESXi-хост А не обновил timestamp - хосты считают, что хост А более недоступен и блокировка считается неактуальной. Если же блокировка еще актуальна - другие хосты снимать ее не будут.
Если произошел сбой ESXi-хоста А, механизм VMware HA решает, какой хост будет восстанавливать данную виртуальную машину, и выбирает хост Б.
Далее все остальные хосты ESXi виртуальной инфраструктуры ждут, пока хост Б снимет старую и поставит свою новую блокировку, а также накатит журнал VMFS.
Данный тип блокировок почти не влияет на производительность хранилища, так как происходят они в нормально функционирующей виртуальной среде достаточно редко. Однако сам процесс создания блокировки на файл виртуальной машины вызывает второй тип блокировки - лок тома VMFS.
Блокировки на уровне тома VMFS
Этот тип блокировок необходим для того, чтобы хост-серверы ESXi имели возможность вносить изменения в метаданные тома VMFS, обновление которых наступает в следующих случаях:
Создание, расширение (например, "тонкий" диск) или блокировка файла виртуальной машины
Изменение атрибутов файла на томе VMFS
Включение и выключение виртуальной машины
Создание, расширение или удаление тома VMFS
Создание шаблона виртуальной машины
Развертывание ВМ из шаблона
Миграция виртуальной машины средствами vMotion
Для реализации блокировок на уровне тома есть также 2 механизма:
Механизм SCSI reservations - когда хост блокирует LUN, резервируя его для себя целиком, для создания себе эксклюзивной возможности внесения изменений в метаданные тома.
Механизм "Hardware Assisted Locking", который блокирует только определенные блоки на устройстве (на уровне секторов устройства).
Наглядно механизм блокировок средствами SCSI reservations можно представить так:
Эта картинка может ввести в заблуждение представленной последовательностью операций. На самом деле, все происходит не совсем так. Том, залоченный ESXi-хостом А, оказывается недоступным другим хостам только на период создания SCSI reservation. После того, как этот reservation создан и лок получен, происходит обновление метаданных тома (более длительная операция по сравнению с самим резервированием) - но в это время SCSI reservation уже очищен, так как лок хостом А уже получен. Поэтому в процессе самого обновления метаданных хостом А все остальные хосты продолжают операции ввода-вывода, не связанные с блокировками.
Надо сказать, что компания VMware с выпуском каждой новой версии платформы vSphere вносит улучшения в механизм блокировки, о чем мы уже писали тут. Например, функция Optimistic Locking, появившаяся еще для ESX 3.5, позволяет собирать блокировки в пачки, максимально откладывая их применение, а потом создавать один SCSI reservation для целого набора локов, чтобы внести измененения в метаданные тома VMFS.
С появлением версии файловой системы VMFS 3.46 в vSphere 4.1 появилась поддержка функций VAAI, реализуемых производителями дисковых массивов, так называемый Hardware Assisted Locking. В частности, один из алгоритмов VAAI, отвечающий за блокировки, называется VAAI ATS (Atomic Test & Set). Он заменяет собой традиционный механизм SCSI reservations, позволяя блокировать только те блоки метаданных на уровне секторов устройства, изменение которых в эксклюзивном режиме требуется хостом. Действует он для всех перечисленных выше операций (лок на файлы ВМ, vMotion и т.п.).
Если дисковый массив поддерживает ATS, то традиционная последовательность SCSI-комманд RESERVE, READ, WRITE, RELEASE заменяется на SCSI-запрос read-modify-write для нужных блокировке блоков области метаданных, что не вызывает "замораживания" LUN для остальных хостов. Но одновременно метаданные тома VMFS, естественно, может обновлять только один хост. Все это лучшим образом влияет на производительность операций ввода-вывода и уменьшает количество конфликтов SCSI reservations, возникающих в традиционной модели.
По умолчанию VMFS 5 использует модель блокировок ATS для устройств, которые поддерживают этот механизм VAAI. Но бывает такое, что по какой-либо причине, устройство перестало поддерживать VAAI (например, вы откатили обновление прошивки). В этом случае обработку блокировок средствами ATS для устройства нужно отменить. Делается это с помощью утилиты vmkfstools:
vmkfstools --configATSOnly 0 device
где device - это пусть к устройству VMFS вроде следующего:
Как вы знаете, в VMware vSphere 5 есть возможность динамической миграции хранилищ виртуальных машин - Storage vMotion. Эта возможность позволяет не только без простоя перенести виртуальные машины между хранилищами и их LUN, но и изменять формат результирующего виртуального диска (thin или thick).
В этой заметке мы рассмотрим один из интересных аспектов миграции Storage vMotion - перенесение томов RDM (Raw Device Mapping) виртуальных машин, работающих в режиме виртуальной и физической совместимости (physical and virtual RDMs).
Также перенос хранилища виртуальной машины мы можем сделать не только в "горячем" режиме, но и в "холодном" с помощью функции Cold Migration (для выключенной ВМ). В этом случае мы также можем выбрать формат виртуального диска результирующей ВМ. Давайте посмотрим как эти условия влияют на перенос RDM томов во всех случаях.
Перенос включенных ВМ с физическим RDM (pRDM) средствами Storage vMotion:
Если вы пытаетесь изменить формат результирующего диска - Storage vMotion будет сделать нельзя.
Если вы не пытаетесь изменить формат - будет перемещен маппинг-файл pRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос включенных ВМ с виртуальным RDM (vRDM) средствами Storage vMotion:
Если вы изменяете формат результирующего диска (в advanced view) - том vRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл vRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос выключенных ВМ с физическим RDM (pRDM) средствами Cold Migration:
Если вы изменяете формат результирующего диска (в advanced view) - том pRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл pRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Перенос выключенных ВМ с виртуальным RDM (vRDM) средствами Cold Migration:
Если вы изменяете формат результирующего диска (в advanced view) - том vRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
Если вы не изменяете формат - будет перемещен маппинг-файл vRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.
Таким образом, у нас получается 3 ситуации, когда исходный RDM-том конвертируется в VMDK-диск на целевом томе, при этом в мастере миграции вас никто об этом не предупреждает.
Также есть еще один аспект при миграции таких томов. Если исходный RDM-том находился в режиме Independent Persistent (а pRDM обязательно в этом режиме находится), то, как следует из свойств этого диска, он не участвует в создании снапшотов ВМ.
После миграции, если он будет сконвертирован в vmdk-файл, то он также останется в этом режиме:
А это значит софт для резервного копирования виртуальных машин не будет бэкапить такой диск, поскольку он не участвует в создании снапшота. Учитывайте этот момент.
Как вы знаете, в VMware vSphere 5 версия файловой системы VMFS была продвинута до 5. Это дает множество преимуществ по сравнению с VMFS 3, в частности, возможность создания хранилищ виртуальных машин (Datastore) размером до 64 ТБ без необходимости создания экстентов.
Это стало возможным благодаря использованию GPT-разделов (GUID Partition Table) вместо MBR-разделов (Master Boot Record). При этом, существует ошибочное мнение, что для томов VMFS 3, обновляемых на VMFS 5, ограничения старой версии в 2 ТБ на файловую систему Datastore остаются. Это не так - VMFS 5.0 при обновлении на нее с третьей версии действительно сохраняет формат MBR, однако после расширения тома более 2 ТБ происходит автоматическая конвертация MBR в GPT-диск.
То есть, происходит это так. У нас есть том VMFS 3, мы нажимаем ссылку "Upgrade to VMFS 5":
После прохождения мастера обновления, видим что тип тома - VMFS 5:
Однако здесь также видно, что том VMFS (теперь уже 5-й версии) остался размеров в 2 ТБ, несмотря на то, что LUN может быть более 2 ТБ. Кроме того, том остался MBR-форматированным, а размеры блоков VMFS 3 для него остались неизменными (см. KB 1003565). Надо отметить, что вновь создаваемые тома VMFS 5 всегда создаются с унифицированным размером блока - 1 МБ.
Чтобы расширить том VMFS, вызываем мастер "Increase Datastore Capacity":
Расширяем том, например до 3 ТБ:
Обратите внимание, что VMFS 5 не дает нам увеличения размера файла (vmdk) по сравнению с предыдущей версией - максимум по прежнему 2 ТБ, просто теперь том может быть размером до 64 ТБ без экстентов.
Запустим fdisk, посмотрим свойства расширенного тома и увидим, что он теперь GPT-том:
Далее операции с таким диском производятся с помощью утилиты partedUtil, но это уже другая история.
Компания VMware в июле 2011 года объявила о доступности новых версий целой линейки своих продуктов для облачных вычислений, среди которых находится самая технологически зрелая на сегодняшний день платформа виртуализации VMware vSphere 5.0.
Мы уже рассказывали об основном наборе новых возможностей VMware vSphere 5.0 неофициально, но сейчас ограничения на распространение информации сняты, и мы можем вполне официально рассказать о том, что нового для пользователей дает vSphere 5.
Мы уже писали о некоторых расширенных настройках дисковой подсистемы серверов VMware ESX / ESXi, которые позволяют управлять доступом виртуальных машин к хранилищам VMFS. Сегодня постараемся описать еще несколько параметров:
Опишем еще несколько параметров Advanced Settings для категории Disk:
Disk.MaxLUN - это число (по умолчанию 256, т.е. ID от 0 до 255), опеделяющее максимальное количество томов, доступных серверу VMware ESX / ESXi.
Disk.MaskLUNs = "vmhba1:0:32-35;vmhba2:0:1,5,7-9" - это параметр, определяющий маскирование томов VMFS в SAN. В данном примере от хоста ESX / ESXi скрываются LUN с ID от 32 до 35 для HBA-адаптера vmhba1, а также LUN с ID 1,5,7,8,9 для адаптера vmhba2. Разделитель для адаптеров - точка с запятой.
Disk.SupportSparseLUN - эта настройка включена по умолчанию (значение 1), по желанию ее можно выставить в 0. Значение 1 означает, что на ESX / ESXi включена поддержка номеров LUN, идущих непоследовательно (например, 0,6 и 23). Если у вас все LUN идут по порядку, то можно отключить эту функцию, выставив значение 0. В этом случае будет тратиться немного меньше времени на сканирование всех LUN.
Disk.DiskMaxIOSize - с помощью этого параметра можно задать максимальный размер операции ввода-вывода (IO request). По умолчанию, сервер VMware ESX / ESXi поддерживает объем IO-запроса размером до 32767 KB, запросы большего объема разбиваются на части. Для некоторых хранилищ (это надо смотреть в документации) такой размер IO-запроса, генерируемый некоторыми приложениями может оказаться слишком большим и привести к снижению производительности. Поэтому можно уменьшить этот параметр, в зависимости от модели дискового массива. Более подробно описано в KB 1003469.
Disk.SchedQControlVMSwitches - по умолчанию, этот параметр равен 6. Он означает вот что. Когда у нас несколько виртуальных машин отдают свои IO к LUN, у нас вступает в игру параметр Disk.SchedNumReqOutstanding (а не глубина очереди адаптера), который определяет границу для виртуальных машин по одновременной отдаче команд ввода-вывода. Если эта граница превышена - наступает постановка команд в очередь. Но VMkernel должен перед этим обнаружить, что LUN использует несколько ВМ. Так вот Disk.SchedQControlVMSwitches определяет сколько раз должен VMkernel это обнаружить. А понимает он это только тогда, когда следующее IO приходит не от той машины, которая дала предыдущий IO. Надо понимать, что это значение может быть достигнуто не очень скоро, когда у нас есть одна высоконагруженная ВМ A на одном LUN, и там же есть низконагруженная по IO машина (B). И это хорошо, поскольку в таких окружениях не должно быть урезания по вводу-выводу для высоконагруженной ВМ.
Disk.SchedQuantum - по умолчанию, этот параметр равен 8. Он определяет число высокоприоритетных последовательных команд, которые идут к дисковому устройству. Последовательными командами считаются те, которые идут к расположенным рядом секторам диска. Что такое расположенные рядом сектора диска? Это те, которые (по умолчанию) находятся друг от друга на расстоянии не более 2000 секторов. Такие команды выполняются до 10 раз быстрее, чем с далекими секторами.
Disk.SectorMaxDiff - это и есть параметр, определяющий, что такое "близкие" секторы для предыдущего параметра. По умолчанию, он равен 2000.
Disk.SchedQControlSeqReqs - этот параметр (по умолчанию, 128) определяет число последовательных IO без переключений (т.е. последовательность команд только от одной ВМ), после которых счетчик Disk.SchedQControlVMSwitches будет сброшен в 0, а машина сможет использовать опять всю очередь адаптера. Этот параметр нужен для того, чтобы после всплеска нагрузки на ВМ B в первом примере, когда этот всплеск прекратится, ВМ A снова смогла получить в свое распоряжение всю очередь адаптера и дальше работать в интенсивном режиме без входа в игру параметра Disk.SchedNumReqOutstanding, который распределяет IO на LUN.
Воткнули? Нет? Тогда еще раз перечитывайте статью Duncan'а. А еще один блоггер, Andy Grant, нарисовал замечательную картинку (кликабельно):
Как оказалось, на нашем сайте нет хорошего руководства по назначению и использованию RDM-дисков (Raw Device Mapping) с платформой VMware vSphere. Постараемся заполнить этот пробел.
Давайте начнем с того, что для виртуальных машин на серверах VMware ESX есть всего 3 типа дисков с точки зрения виртуализации подсистемы хранения:
VMDK-диски
Это самые часто используемые диски VMware vSphere. Они создаются на хранилищах VMFS или NFS и позволяют использовать все возможности работы VMware с виртуальными машинами в части распределенных служб. К ним относятся распределенная блокировка файлов (distributed file locking), снапшоты дисков, vMotion - и много чего еще. О типах виртуальных дисков у нас есть отдельная статья. Обычные vmdk-диски - это самый высокий уровень виртуализации, т.е. все SCSI-команды виртуальной машины при обращении к нему проходят через компонент VMkernel, который уже процессит их внутрь файла vmdk. За пределы этого файла виртуальная машина ничего не видит. То есть виртуальной машине дается кусочек тома VMFS или NFS в виде файла vmdk, операции по работе с которым полностью контролируются гипервизором - это и есть максимальная виртуализация устройства. Из этого, кстати, следует, что поскольку есть слой виртуализации, в определенных условиях такие диски могут работать медленнее RDM-дисков, но есть также и условия при которых такие диски могут работать быстрее. Более подробно об этом можно прочитать здесь. На этих дисках в статье мы останавливаться не будем.
RDM-диски в режиме виртуальной совместимости (virtual RDM).
Это промежуточный тип диска с точки зрения виртуализации хранения. В случае создания такого диска на хранилище VMFS (NFS - не поддерживается) создается mapping-файл (он тоже с расширением *-rdmp.vmdk), через который происходит маппирование виртуальной машине физического дискового устройства LUN. Устройство это маппируется особым образом - основные служебные операции по работе с ним (например, команда Open и другие служебные SCSI-команды) проходят через через слой виртуализации в гипервизоре, а команды по работе с данными (Read и Write) процессятся напрямую к устройству, минуя слой виртуализации.
Что означает, что передаются напрямую только команды Read / Write в виртуальный RDM? Это означает, что устройство представляется виртуальной машине как обычный SCSI-диск, с которым нельзя работать иначе как с устройством хранения (как можно иначе - дальше). Зато сохраняется большинство возможностей VMware vSphere по функциональности - например, снапшоты. Ниже мы также посмотрим, где можно использовать такой тип дисков.
RDM-диски в режиме физической совместимости (Physical RDM). Это наименее виртуализованный тип дисков. Для таких дисков хост-сервер ESX также создает mapping-файл, но вот iSCSI-команды процессятся к устройству LUN напрямую, минуя слой виртуализации хранилища в гипервизоре (за исключением одной команды LUN Report).
Что дает такой механизм доступа к устройству? Он позволяет использовать iSCSI-устройство не просто как диск, но и передавать к нему различные iSCSI-команды, которые предоставлют больше возможностей по работе с устройством (например, управление SAN-устройствами изнутри виртуальной машины или снятие снапшота на уровне хранилища). Ниже мы тоже рассмотрим подобные примеры.
О решении StarWind Enterprise iSCSI для создания отказоустойчивых хранилищ VMware vSphere и Microsoft Hyper-V мы уже писали немало (для этого есть специальный раздел на нашем сайте) и будем писать еще, пока все кому оно нужно его не купят. А нужно оно очень многим, так как позволяет создать отказоустойчивый кластер хранения на базе существующей инфраструктуры Ethernet при минимальных инвестициях (не надо покупать FC-хранилища, устройства коммутации SAN и прочее).
Сегодня мы поговорим о типе диска Snapshot and CDP Device в StarWind Enterprise iSCSI. Во-первых, вам нужно прочитать первую часть статьи, где описаны основные режимы работы дисков со снапшотами, которые поддерживает продукт.
Диски типа Snapshot and CDP Device можно создать, когда вы выбираете опцию создания виртуального образа Advanced Virtual, а затем Snapshot and CDP Device:
CDP - это Continuous Data Protection, т.е. непрерывная защита данных ваших виртуальных машин. В этом режиме поддерживаются мгновенные снимки хранилища (snapshots), которые защитят вас от утраты каких-либо важных данных по вине пользователя - вы всегда сможете откатиться к снимку, созданному в определенный момент времени.
Какие опции мы имеем (кстати, обратите внимание, что StarWind можно использовать и для Citrix XenServer, где он находится в официальном HCL):
Во-первых, у нас есть три режима работы диска Snapshot and CDP Device...(нажимаем читать дальше и комментировать)
Как вы знаете, у компании VMware есть проприетарная система VMFS (официально называемая "VMware Virtual Machine File System"), которая представляет собой распределенную кластерную файловую систему с возможностью одновременного доступа со стороны нескольких хост-серверов VMware ESX / ESXi. VMFS имеет версии, которые можно увидеть в свойствах Datastore в vSphere Client:
VMFS версии 3 впервые появилась в VMware ESX 3.0 (тогда же она перешла от плоской структуры к структуре директорий). Теперь же версии VMFS соответствуют следующим версиям хостов их создавшим:
ESX 3.0 - VMFS 3.21
ESX 3.5 - VMFS 3.31 (новая возможность: optimistic locking - сбор локов в пачки, что повышает производительность при SCSI-резервациях)
ESX 4.0 - VMFS 3.33 (новая возможность: optimistic IO - увеличение эффективности канала ввода-вывода при работе с метаданными тома)
Казалось бы нужно обновлять виртуальные хранилища, чтобы они поддерживали все новые возможности новых версий VMware vSphere. А хранилище VMFS никак обновить нельзя - его можно только создать заново более новой версией, предварительно освободив. Но ничего этого делать не нужно.
Все нововведения по работе с хранилищами делаются со стороны драйвера VMFS на хост-сервере VMware ESX / ESXi, а на самом томе VMFS только ставится маркер версии драйвера его отформатировавшего (например, в datamover'е). Хотя, говорят, в самой структуре тома говорят тоже происходят незначительные изменения. Но все это значит, что на Datastore, созданном из ESX 3.0 (VMFS 3.21), вы можете использовать все функции ESX 4.1 (VMFS 3.46) по работе с хранилищами, например, Thin Provisioning или VMFS Volume Grow (хотя вот про последнее есть иные мнения).
Сегодня мы поговорим о механизме дедупликации данных в StarWind Enterprise iSCSI. Эта функциональность появилась, начиная с версии 5.6. Она позволяет создавать образы виртуальных дисков для хранилищ iSCSI, которые будут содержать только уникальные данные записываемых на них файлов (vmdk, vhd и прочее). Дедупликация работает "на лету", поэтому на хранилище попадают только уникальные блоки:
Объем, занимаемого этим хранилищем, будет расти по мере заполнения его уникальными данными файлов на нем хранящихся. Это позволяет значительно экономить на необходимых дисковых емкостях и понижает совокупную стоимость решения по построению инфраструктуры хранения данных виртуальных машин (c iSCSI она и так весьма небольшая).
Для создания дедуплицированного хранилища нужно выбрать тип диска Advanced Virtual (см типы дисков StarWind) и выбрать его подтип - Deduplicated disk device:
Обратите внимание - сейчас эта возможность экспериментальная (версия StarWind Enterprise 5.6). В следующих релизах она уже будет полностью поддерживаться. Поэтому ее пока используйте только для тестовых или некритичных систем.
Далее создаем новое устройство для виртуального диска, которое определяет максимальный объем хранилища (в нашем случае 5 ГБ):
Далее видим настройки, которые пока нельзя менять. Они определяют размер кэша для записи на данное виртуальное устройство, размер файла метаданных для виртуального диска и объем памяти, требующийся для работы с устройством.
Но реально на хранилище он занимает пока только вот столько:
Добавляем хранилище в vSphere Client:
Видим емкость в 5 ГБ:
Теперь создаем виртуальную машину на этом хранилище с диском в 2 ГБ (этот vmdk-диск указываем как thick, а не thin - то есть он создается сразу файлом в 2 ГБ):
И видим, что общее пространство, занимаемое диском StarWind Enterprise изменилось незначительно (в данном случае я уже был в середине установки Windows 2003 Server в этой виртуальной машине):
То есть в данном случае не просто Thin Provisioning, а полноценная дедупликация данных на лету средствами StarWind Enterprise.
Скачать замечательный продукт StarWind Enterprise iSCSI можно по этой ссылке, а покупают его по этой ссылке.
Вы все уже вполне себе знаете, что есть на свете замечательный продукт StarWind Enterprise 5.6, который позволяет создавать отказоустойчивое хранилище для виртуальных машин VMware vSphere / Microsoft Hyper-V на базе технологии iSCSI, что не требует больших вложений и отлично подходит для небольших компаний и филиалов, где дорого и нецелесообразно покупать громоздкие Fibre Channel массивы (да и, вообще, FC вымирает потихоньку, особенно с приходом 10G Ethernet). О StarWind у нас есть специальный раздел, а также рекомендую почитать тут, тут и тут.
Сегодня мы поговорим о том, какие еще возможности существуют в StarWind Enterprise при работе с дисками (см. предыдущую статью). Во-первых, при создании образа виртуального диска можно задать опцию шифрования данных, которая позволит вам повысить безопасность инфраструктуры хранения виртуальных машин:
Во-вторых, в StarWind iSCSI Target есть возможность расширить уже существующее хранилище. Для этого нужно просто нажать правой кнопкой на файл образа виртуального диска и выбрать пункт "Extend Image Size":
Расширим наше хранилище с 10 до 15 ГБ:
Данная операция не повреждает хранилище с виртуальными машинами. После расширения образа виртуального диска с хранилищем VMFS, в VMware vSphere вам нужно будет сделать расширение тома. Выбираем Properties для нашего Datastore:
И нажимаем кнопку Increase:
Выбираем наш том:
И расширяем его:
Хранилище VMFS расширено на 5 ГБ:
Вот так легко и непринужденно можно оперировать с томами StarWind Enterprise iSCSI. Скачать продукт можно по этой ссылке. Нормальные ребята покупают его тут.
Если вы используете пулы типа Linked Clone (на основе базового образа) в решении для виртуализации ПК VMware View 4.5, то знаете, что есть такая операция "Rebalance", которая перераспределяет виртуальные ПК пула по хранилищам VMFS / NFS. Но многие удивятся, как работает эта функция. Например, у вас есть несколько хранилищ различной емкости, и вы делаете Rebalance десктопов.
Получаете вот такую картину:
Слева - то, что вы ожидаете увидеть в результате балансировки, а справа - то, что получается на самом деле. В чем причина?
Все дело в том, что VMware View 4.5 использует для перемещения машин на хранилище параметр "weighted available space". У какого из хранилищ он больше - туда виртуальные машины и переезжают. Что это за параметр:
datastore_capacity - это общая емкость хранилища VMFS / NFS.
virtual_usage - это максимально возможный объем, занимаемый виртуальными машинами на хранилище, который формируется из размера виртуальных дисков машин (номинального, а не реального) + размер памяти (для Suspend).
overcommit_factor - это настройка для Storage Overcommit, которую вы задавали для Datastore, когда выбирали, какие из них следует использовать для пулов Linked Clone. Там были такие значения:
None - хранилище не является overcommitted.
Default - это коэффициент 4 от размера хранилища
Moderate - это коэффициент 7 от размера хранилища
Aggressive - это коэффициент 15 от размера хранилища.
Если вы забыли, где это выставляли, то это вот тут:
Теперь переходим к примеру и формуле. Есть у нас вот такая картинка (см. настройки overcommitment):
Теперь вот вам задачка - что будет в результате Rebalance виртуальных ПК?
По-сути, правило таково: если у вас все хранилища с одинаковым уровнем Storage Overcommitment и одинакового размера, то виртуальные машины будут перемещены на другие хранилища, если там больше свободного места, чем свободного места на текущем хранилище. Ну а если разного размера и одинакового уровня Overcommitment - то ожидайте того, что машины останутся на больших хранилищах. Так-то вот.
И да, никогда не далейте Storage VMotion для виртуальных машин VMware View 4.5 вручную - это не поддерживается со стороны VMware.
Компания Veeam Software, ведущий поставщик средств для управления виртуальной инфраструктурой VMware vSphere, объявила о выпуске средства для резервного копирования виртуальных машин на серверах VMware ESX / ESXi - Veeam Backup and Replication 5.
Это действительно новый и революционный продукт, выводящий на новый уровень технологии резервного копирования виртуальных машин. Теперь оно стало еще более эффективным, а, с точки зрения механизмов восстановления данных и надежности, на сегодняшний день Veeam Backup and Replication 5 - абсолютный лидер в сегменте продуктов для резервного копирования VMware vSphere.
Мы уже писали об основных нововведениях Veeam Backup and Replication 5 с технологиями vPower, SureBackup, U-AIR и другими в следующих статьях:
Теперь обо всех новых функциях и возможностях Veeam Backup and Replication 5 расскажем по порядку:
1. Технология Veeam vPower в Veeam Backup and Replication 5.
Используя множество техник, компания Veeam в своем продукте для резервного копирования виртуальных машин сделала возможность запуска их напрямую из резервных копий, которые хранятся в дедуплицированном виде на backup-хранилище. Это создает множество возможностей для тестирования резервных копий на работоспособность (SureBackup), мгновенного восстановления в производственную среду (InstantRestore) и даже управления виртуальными тестовыми лабораториями на базе продуктивных окружений (то есть, можно запустить продуктив напрямую из бэкапа для каких-нибудь тестов). Таким образом, Veeam vPower - это фундаментальная технология для множества улучшений в Veeam Backup and Replication 5.
2. Техника Instant VM Recovery (InstantRestore) в Veeam Backup and Replication 5.
InstantRestore позволяет мгновенно (без копирования каких-либо данных) восстановить резервную копию системы, запустив ее напрямую из резервной копии, которая хранится в сжатом и дедуплицированном виде. Далее виртуальная машина потихоньку переносит свое хранилище в продуктивную среду за счет технологии Storage VMotion. Если по лицензии VMware vSphere у вас нет техники Storage vMotion, то можно использовать репликацию виртуальной машины в производственное окружение - ведь репликация в Veeam Backup and Replication 5 бесплатна! Все это влияет самым лучшим образом на политики RTO (Recovery Time Objective) сервиса в виртуальной машине, позволяя восстановить его сразу после отказа.
3. Техника U-AIR (Universal Application-Item Recovery) в Veeam Backup and Replication 5.
U-AIR позволяет восстанавливать объекты приложений виртуальных машин напрямую из образа резервной копии. То есть, из бэкапа можно достать и восстановить на целевой сервер объект Active Directory, письмо Exchange или любой другой объект приложения. Кроме того, есть возможность самостоятельного восстановления данных пользователем из приложений с веб-фронтендом. Заметьте - не надо никаких агентов для восстановления отдельных объектов.
4. Техника SureBackup в Veeam Backup and Replication 5.
Veeam SureBackup позволяет убедиться в том, что резервные копии сделаны правильно и они полностью готовы к восстановлению и работе в случае аварии или потери данных. Делается это автоматизированным способом за счет создания виртуальной тестовой лаборатории, где виртуальные машины запускаются напрямую из бэкапов, не мешая основной производственной среде. Далее администратор вручную или автоматически (по заданию) верифицирует целостность хранимых копий, в том числе с помощью специальных скриптов, которые проверяют работоспособность не только ОС, но и приложений. Об отработавшей задаче проверки целостности резервных копий системному администратору приходит отчет по почте.
5. Виртуальная лаборатория по запросу (On-Demand Sandbox) в Veeam Backup and Replication 5.
С помощью техник мгновенного запуска резервных копий администратор может запустить набор приложений в виртуальных машинах, являющихся копией производственной среды, и проводить там какие угодно тесты. Для тестовой лаборатории задается хост ESX / ESXi, где это будет происходить, Datastore, Proxy Appliance для доступа Veeam Backup к тестовой лаборатории с виртуальными машинами в изолированной сети и настройки этой самой сети. После того, как виртуальная лаборатория создана, появится новый виртуальный коммутатор vSwitch, пул ресурсов и хранилище для тестирования.
6. Мгновенное восстановление файлов (Instant File Level Recovery) для любой гостевой ОС в Veeam Backup and Replication 5.
Veeam Backup всегда умел восстанавливать отдельные файлы из бэкапов гостевых систем виртуальных машин. Windows, Linux, FreeBSD и многое другое поддерживается для восстановления (при этом есть удобный навигатор по файловой системе). Теперь также появляется еще одна интересная возможность - монтирование диска резервной копии к виртуальной машине, куда требуется восстановить нужные файлы. Это очень удобно, а восстановление занимает считанные секунды.
7. Быстрый поиск объектов (Instant Indexing) в Veeam Backup and Replication 5.
Функция Instant Indexing - это быстрая индексация данных содержимого резервных копий виртуальных машин, что позволяет быстро искать в бэкапах любые файлы и мгновенно вытаскивать их в продуктивную среду. Также есть удобный браузер по файловым системам в Veeam Enterprise Manager.
8. Основные дополнительные улучшения в Veeam Backup and Replication 5.
Customizable block size. Теперь можно настраивать размер блока для хранилища назначения резервной копии или реплики. Большой размер блока уменьшает затраты вычислительных ресурсов на бэкап и повышает производительность, в то время как меньший размер блока увеличивает степень дедупликации и позволяет уменьшить передаваемый трафик (что особенно актуально для WAN-соединений) при инкрементальном резервном копировании.
Monthly schedules. Теперь можно настроить планировщик по месяцам для задач резервного копирования напрямую из GUI, который предоставляет больше опций нежели стандартный планировщик Windows.
Continuous job schedule. Новая возможность создания задач по расписанию для соответствия сценариям near-CDP protection.
Unsupported disks are now automatically skipped. Неподдерживаемые диски для резервного копирования теперь автоматически пропускаются (раньше надо было исключать их из задачи вручную).
9. Улучшения процесса создания резервных копий в Veeam Backup and Replication 5.
Incremental backup mode. Традиционный режим инкрементального резервного копирования теперь тоже есть для поддержки сценариев резервного копирования disk-to-disk-to-tape (D2D2T), удаленных сайтов и на хранилища, которые дедуплицируются своими средствами. Синтетический режим резервного копирования (обратные инкременты) также остался. Кроме того, можно восстанавливать систему даже тогда, когда отрабатывает задача по резервному копированию.
Previous full backup chain transformation. Возможность преобразовать цепочки предыдущих полных бэкапов (Full Backups) в цепочку с одним полным бэкапом и несколькими обратными инкрементами для экономии дискового пространства на целевом хранилище.
VM level retention in full backup files. Теперь в файле полной резервной копии просто заменяются блоки данных в соответствии с настроенной политикой хранения полных резервных копий. То есть, нет необходимости делать полный бэкап, полностью удаляя предыдущий из VBK-файла.
Delete individual VMs from full backup file. Теперь можно удалить любую виртуальную машину из резервной копии с VBK-файлом. Блоки помечаются как свободные, и на их место записываются дальнейшие данные бэкапов без роста размера файла.
Enhanced backup properties. Расширенные настройки в опциях для задачи резервного копирования.
10. Улучшения процесса репликации в Veeam Backup and Replication 5.
Thin disk support on replica. Теперь у реплики также может быть растущий по мере наполнения данными (thin) диск. Это улучшает производительность репликации.
On-the-fly disk transformation. Также можно на лету при репликации преобразовывать "толстые" (thick) диски исходной машины в тонкие (thin) диски реплики. Экономия на дисковом хранилище реплик.
Replica properties. Появились новые свойства реплики, такие как объем данных переданный с после запуска задачи репликации (функция, о которой запрашивали многие пользователи).
11. Интеграция с приложениями в Veeam Backup and Replication 5.
Network connection-less operation. Теперь нет необходимости прямого соединения виртуальной машины, где работает Veeam VSS Agent, и бэкап-сервера. Это позволяет соблюсти политики безопасности в виртуальной инфраструктуре без потери функциональности по обеспечению целостности данных за счет служб VSS.
Granular application-aware processing. Теперь можно более структурированно задавать настройки выполнения различных задач (например, запуск службы VSS) для отдельных виртуальных машин или других объектов виртуальной инфраструктуры VMware vSphere.
Better transaction logs handling. Теперь лог транзакций приложения резервируемой системы очищается только после успешного бэкапа, вместо того, чтобы делать это после снятия снапшота при создании резервной копии. Это позволяет сохранить лог транзакций и откатиться на нужную точку в Microsoft SQL Server, даже если задача резервного копирования по какой-либо причине упадет после снятия снапшота виртуальной машины.
Option to disable transaction logs pruning. Можно также полностью отключить очистку лога транзакций.
Transaction logs pruning for Microsoft SQL. Очистка лога транзакций для Microsoft SQL Server была введена на случай, если этот сервер резервируется только средствами Veeam Backup и требуется, чтобы логи транзакций не разрастались.
12. Улучшения процесса восстановления в Veeam Backup and Replication 5.
VM search. В мастер восстановления добавлена возможность поиска файлов, чтобы быстро найти файлы, которые требуется восстановить из резервной копии виртуальной машины.
Restore reason. Можно указать причину восстановления файла - удобно для администраторов, отслеживающих эти события.
Restore audit. Теперь в логе восстановления видно, кто и какие файлы восстанавливал, а также по какой причине.
Service-based restores. Теперь задача восстановления файлов управляется службой Windows, поэтому даже если пользователь вышел из системы - задача продолжится.
Original VM location prefill. Мастер восстановления теперь предлагает по умолчанию куда восстанавливать виртуальную машину, чтобы пользователь не ошибся.
Per-disk datastore selection. Для виртуальной машины с несколькими виртуальными дисками можно указать разные хранилища (datastores) для каждого диска.
Better guest file permission handling. Теперь для задачи восстановления файлов добавляется привилегия для доступа к томам, на которые у пользователя нет разрешений. Делается это только для движка Veeam Backup и не нарушает политик безопасности.
Removed VMware Player requirement. Виртуальный модуль File level restore helper appliance теперь запускается напрямую на хосте VMware ESX / ESXi. Теперь не надо использовать VMware Player на сервере Veeam Backup.
Preserve Linux permissions. Теперь можно сохранить права доступа в Linux при восстановлении отдельных файлов.
Permissions and ownership display. Браузер по файловой системе теперь показывает разрешения и владельца файлов.
ZFS support. Восстановление файлов с томов ZFS теперь поддерживается.
13. Улучшения при работе с задачами в Veeam Backup and Replication 5.
Datastore based jobs. Теперь можно создавать задачи, добавляя Datastore как объект для резервирования. Все машины на этом хранилище будут добавлены в задачу.
Granular disk exclusions. Вместо того, чтобы настраивать исключения для дисков на базе задач, можно настраивать исключения на уровне виртуальных машин или других объектов виртуальной инфраструктуры VMware vSphere. Например, в каком-то пуле вы хотите исключить бэкап диска D виртуальных машин.
Per-job email notification. Для каждой задачи отдельно можно настроить нотификацию по e-mail (для разных пользователей).
Windows Event Log events.Veeam Backup теперь пишет о своих действиях в журнал Windows event log (в стиле vCenter).
Simple delegation. Механизм доступа на базе ролей в Veeam Backup был добавлен для разграничения действий пользователей. Например, Restore Operator может выполнять любой тип восстановления, однако не может работать с задачами резервного копирования.
Source datastore monitoring. Как вы знаете, снапшоты требуют дополнительное пространство на хранилище при создании и слиянии. Теперь мониторинг исходного хранилища позволяет убедиться в том, что не возникнет ситуации переполнения, когда из-за нее виртуальные машины завершат работу. По умолчанию, предупреждение высвечивается в случае, если остается менее 10 ГБ свободного пространства. Если остается менее 2 ГБ - задача резервного копирования будет пропущена.
Session history improvements. Старые сессии восстановления теперь удаляются на базе политики хранения, что актуально для пользователей старых версий Veeam Backup, у которых много чего накопилось с более ранних версий.
14. Улучшения в центральной консоли Enterprise Manager в Veeam Backup and Replication 5.
Centralized license management. Теперь удобно отслеживать использующиеся лицензии на Veeam Backup на нескольких серверах из центральной консоли Veeam Enterprise Manager.
Dashboard statistic improvements. Теперь информация о занимаемом пространстве резервными копиями более детальна.
15. Улучшения в процессе установки Veeam Backup and Replication 5.
Database name selection. Теперь можно привязать несколько бэкап-серверов Veeam Backup к одной базе Microsoft SQL. Disabling automount. Теперь автомонтирование новых томо автоматически отключается на сервере Veeam Backup при установке, чтобы предотвратить переподписку VMFS-томов со стороны Microsoft Windows. Теперь этого не надо бояться забыть сделать вручную. CPU verification. Теперь проверяется, достаточно ли мощности CPU для установки Veeam Backup. При этом требования к CPU сохранились от предыдущей версии.
Безусловно, Veeam Backup and Replication 5 - лучший продукт для резервного копирования виртуальных машин в инфраструктуре VMware vSphere. Скачать его можно по этой ссылке.
Купить Veeam Backup and Replication 5 можно уже сегодня. Для этого используйте форму заказа у Золотого партнера Veeam Software на территории России - компании VMC.
Таги: Veeam, Backup, Update, vSphere, Storage, VMFS, ESX, SAN
Уже многим из вас известен такой замечательный продукт для создания хранилищ под виртуализацию, как StarWind Enterprise HA. С помощью StarWind можно создать инфраструктуру хранения виртуальных машин VMware vSphere или Microsoft Hyper-V на базе технологии iSCSI без больших инвестиций. Сегодня я хочу вам рассказать о технологии использования кэширования в StarWind Enterprise, которая позволяет существенно увеличить производительность операций чтения и записи данных на тома VMFS в среде VMware vSphere. Таги: StarWind, Enterprise, Storage, iSCSI, VMFS, VMware, ESX, SAN, Microsoft, Hyper-V
На многим известном сайте sanbarrow.com обнаружился интереснейший справочник по дискам VMDK, которые используются в платформах виртуализации VMware vSphere, Workstation, Server и других.
Кстати, интересный вопрос поднимается в самом конце страницы. Как восстанавливать данные с поврежденных vmfs-томов и дисков vmdk? Автор полагает, что только компания Ontrack сертифицирована VMware для оказания подобных услуг. Но говорит также, что они очень дороги (я это подтверждаю - сами туда обращались).
Между тем, где-то раз в три месяца люди обращаются к нам с подобной проблемой...
Таги: VMware, VMDK, Storage, VMFS, vSphere, ESX, Workstation, Server
Как многие помнят, еще в VMware vSphere 4.0 появилась возможность расширения тома VMFS, для тех случаев когда почему-то простанство на LUN осталось (или его расширили), а для виртуальных машин уже места нет.
Интересное применение этой возможности - в виртуальных лабораториях. То есть, например, консультант взял VMware Workstation 7 и поставил в виртуальной машине VMware ESX 4.x. В качестве Dastastore используется локальный диск виртуального ESX, туда же ставится какая-нибудь виртуальная машина, но ей, как всегда, не хватает места.
Расширяем виртуальный диск виртуальной машины на Workstation, где установлен виртуальный ESX:
Например, с 20 до 30 ГБ:
Далее загружаем виртуальный ESX, соединяемся с ним из vSphere Client и переходим в категорию Storage на вкладке Configuration. Там выбираем Datastore и нажимаем Properties:
Там нажимаем кнопку Increase:
Возникает мастер Increase Datastore Capacity, где можно расширить том:
На вкладке Extents добавился новый экстент, а размер тома стал под 30 ГБ. То, что мне было нужно.
На сервере VMware ESX из состава vSphere, если запустить утилиту esxtop и перейти в категорию дисковой подсистемы (кнопка "d"), можно увидеть счетчик CMDS/s.
Что он значит? CMDS/s (Total commands per second) - это общее число SCSI - команд, передаваемых к системе хранения, включая операции ввода-вывода вывода виртуальных машин, а также сервисные команды (например, SCSI reservations). Если говорить о параметре IOPS (Input/Output Operations Per Second) - то это общее число операций ввода-вывода, представляющее сумму:
IOPS = Number of Read commands(READS/s) + Number of Write commands(WRITES/s)
Таким образом, число IOPS должно быть близко к CMDS/s, за исключением случаев, когда сервер VMware ESX активно работает с метаданными тома VMFS (например, создает и удаляет снапшоты).
Компания VKernel продолжает выпуск бесплатных программных продуктов для виртуализации VMware vSphere. На этот раз это утилита VKernel StorageView, которая позволяет найти "узкие" места в инфраструктуре хранения виртуальных машин. Это обычное десктоп-приложение весом в 6 МБ, которое может быть установлено на рабочей станции администратора и позволяет найти соединения хостов ESX с наибольшими задержками (latency) к томам VMFS или NFS.
Возможности VKernel StorageView:
Топ 5 путей хост / datastore с наибольшей latency
Список виртуальных машин, которые используют эти пути
Скорость обмена трафиком хранения для каждой ВМ в этих путях
Сводная статистика по остальным парам хост / datastore, не вошедшим в топ 5
Очень много вопросов поступает относительно того, для чего нужны снапшоты виртуальных машин (snapshots) на серверах VMware ESX. По-сути снапшоты - это зло, но иногда они оказываются полезны в очень ограниченных условиях (например, для проверки корректности работы обновления приложения или патча операционной системы). То есть эта та точка сохранения состояния виртуальной машины, к которой можно будет вернуться через небольшой промежуток времени. Ни в коем случае нельзя рассматривать снапшоты как альтернативу резервному копированию основных производственных систем, в силу множества проблем.
Одной из них является неочевидное поведение снапшотов при их удалении (применении к основному диску ВМ). В этом случае вам может понадобиться значительный объем свободного дискового пространства на томе VMFS, особенно когда у вас есть несколько снапшотов. Например, у вас есть виртуальная машина с 3-мя снапшотами следующих размеров:
Вы нажимаете кнопку Delete All в Snapshot Manager в vSphere Client, после чего происходит такая ситуация: Snapshot 3 "склеивается" со Snapshot 2, но при этом сам Snapshot 3 остается на томе VMFS:
При этом занятое дисковое пространство увеличивается на величину Snapshot 3 и составляет 90 ГБ. Далее, то, что получилось в Snapshot 2 (50 ГБ) склеивается со Snapshot 1 (10 ГБ), при этом Snapshot 2 и Snapshot 3 остаются. То есть дисковое пространство, занимаемое файлами виртуальных дисков и снапшотов на томе VMFS увеличивается до 140 ГБ:
Только после всего этого, результирующий Snaphot 1 (60 ГБ - сумма всех снапшотов) применяется к основному файлу виртуального диска VMDK. При этом сам виртуальный диск flat в размере не меняется, поскольку он фиксирован (изменяется только содержимое блоков). И только затем все снапшоты удаляются (все 140 ГБ).
Таким образом, на хранилище VMFS нам понадобится 80 ГБ дополнительного свободного пространства, если мы хотим, чтобы операция прошла успешно (зато потом освободится 60 ГБ от снапшотов).
У пользователей VMware vSphere / ESX иногда возникает ситуация, когда необходимо заглянуть на том VMFS и его содержимое с Windows-машины системного администратора (такое, например, может быть, когда у вас сломался единственный сервер VMware ESX, а содержимое тома VMFS надо скопировать). Кроме того, очень полезным бывает получить доступ к файловой системе диска VMDK, чтобы извлечь из него необходимую информацию, не запуская его в составе виртуальной машины.
Open Source VMFS Driver
В первом случае для просмотра содержимого и копирования данных с тома VMFS версии 3.x (VMware vSphere 4.0 сейчас работает на версии 3.33) нам понадобится Open Source-утилита VMFS Driver от компании Fluid Operations. Она выпускается в виде пакета для Windows или Linux операционной системы (работает на Java) и позволяет монтировать в режиме read only активно работающие тома VMFS, с которых запущены виртуальные машины. По-сути, это не драйвер, а обычное приложение, позволяющее просматривать и копировать содержимое томов VMFS на рабочую станцию администратора. Важно знать, что эта разработка официально не поддерживается со стороны VMware, кроме того у разработчиков для написания утилиты не было спецификаций VMFS. Кстати, сейчас уже поддерживаются thin-диски.
Чтобы начать использовать VMFS Driver наберите в командной строке (у вас должна быть установлена Java):
java -jar fvmfs.jar
VMware Disk Mount
Во втором случае для просмотра содержимого VMDK-диска вам понадобится пакет разработчика Virtual Disk Development Kit, в состав которого входит утилита VMware Disk Mount (vmware-mount.exe или vmware-mount.pl). Эта программа позволяет смонтировать виртуальный диск VMDK в ОС Windows или Linux и просматривать его содержимое как обычного диска, подключенного к компьютеру. Обратите внимание, что последняя версия Virtual Disk Development Kit выпущена 21 мая 2009 года (в тот же день, что и VMware vSphere), а это значит, что поддерживается не только формат виртуальных дисков VMware Workstation, но и VMware ESX 3.x / 4.x (в том числе виртуальные машины vSphere). Пользоваться данной CLI-утилитой очень просто, кроме того, несколько лет назад к ней писали различные GUI-надстройки, которые, вероятно, и сегодня можно использовать.
Пользоваться VMware Disk Mount очень просто - открываете cmd и выполняете команду (где e: - буква монтируемого диска):
На Techtarget появилась хорошая статья Eric'а Siebert'а о безопасности виртуальных машин на сервере виртуализации VMware ESX. Статья достаточно длинная, поэтому постараюсь привести краткое содержание с пояснениями.
Чтобы украсть виртуальную машину с VMware ESX вместе со всеми ее данными и приложениями нужно сделать 3 вещи:
1. Сделать Snapshot виртуальной машины, что переведет ее основной виртуальный диск vmdk в режим только чтения.
2. Загрузить диск vmdk с общего или локального хранилища на машину злоумышленника с помощью FastSCP или WinSCP (можно использовать встроенный в vSphere Client Datastore Browser).
3. Импортировать виртуальную машину на VMware Workstation (для запуска и доступа к данным и приложениям), либо смонтировать диск ВМ в операционную систему Windows или Linux с помощью утилиты vmware-mount из комплекта VMware's Virtual Disk Development Kit (VDDK).
Комментарии:
1. Поскольку основной vmx-файл виртуальной машины будет ссылаться не только на основной vmdk, но и на файл снапшота (отличия от исходного состояния ВМ), нужно будет этот vmx подправить. Кроме того, после того, как файлы vmdk и vmx будут скопированы злоумышленником, он удаляет снапшот - для администратора будто бы ничего и не было.
2. Чтобы запустить импортированную виртуальную машину потребуется пароль администратора гостевой ОС. Как известно, есть утилиты для подбора пароля администратора под Windows Server.
3. Чтобы смонтировать виртуальный диск vmdk и получить доступ ко всем данным - никакого пароля не нужно (если не было шифрования средствами гостевой ОС). Представьте, что вы украли обычный физический диск и воткнули его в компьютер.
4. Файлы vmdk не шифруются в VMware vSphere, но судя по тому, что возможность шифрования в VMware Workstation 7 появилась, в скором времени ее можно ожидать и для VMware vSphere / ESX.
Как не допустить кражи виртуальной машины со своего сервера VMware ESX:
1. Разграничивайте доступ к VMware vCenter, а также к томам VMFS, где хранятся виртуальные машины (в том числе на уровне SAN).
Интересный калькулятор дискового пространства LUN под том VMFS для виртуальных машин появился на vsphere-land.com.
В целом, достаточно адекватный. Надо помнить, что хранилище виртуальных машин надо расчитывать исходя из общего объема виртуальных дисков VMDK, места под снапшоты, vswp файлы и suspend-файлы vmss. При этом нужно 70% тома VMFS держать свободным на случай использования снапшотов и дисков типа thin (возможность VMware Thin Provisioning). При этом не рекомендуется держать на одном LUN больше 10-15 виртуальных машин. И, конечно же, помните о правиле - только 1 LUN для 1 тома VMFS (не используйте экстенты!).
Стала доступна интересная техническая презентация по технологиям VMware vStorage в продукте VMware vSphere от одной из VMware User Group (Mid-Missouri VMUG in August 2009 ).
Многим известно, что диски виртуальной машины на VMware ESX / vSphere можно сделать тонкими (thin - то есть растущими по мере наполнения их данными) с помощью операции динамического перемещения между хранилищами Storage VMotion (SVMotion). Однако, многие из вас удивятся, что когда вы преобразуете толстые (thick) виртуальные диски машины в thin-диски, их размер будет значительно больше объема данных в гостевой ОС машины на ESX.
Все очень просто - Windows при удалении файла не чистит файловую систему физически, а лишь удаляет ссылки на файлы и папки. Поэтому при преобразовании дисков в thin, VMware ESX убирает только нулевые блоки, но данные блоки считает занятыми, хотя фактически пространство диска свободно. Чтобы минимизировать занимаемое виртуальной машиной на томе VMFS пространство, в настройках VMware Tools есть такая вкладка Shrink, откуда можно "вычистить" нулевые блоки и соответственно сделать thin-диск меньше после конверсии:
Одно из преимуществ VMware vSphere - наличие распределенной кластерной файловой системы VMFS, которая оптимизирована для работы в кластере VMware HA / DRS с большими файлами виртуальных дисков VMDK. Для того чтобы обеспечивать работу кластеров, файловая система VMFS имеет механизм обработки распределенной блокировки файлов хостами VMware ESX (Distributed Lock Handling). Это очень важный механизм для корректной работы механизма обеспечения отказоустойчивости VMware HA.
Виртуальные машины на платформе VMware vSphere размещаются на хранилищах Fibre Channel, iSCSI, NAS/NFS или локальных дисках серверов ESX. Диски виртуальных машин могут располагаться на томах в файловой системе VMFS (Virtual Machine File System), NFS (Network File System) или на томах RDM (Raw Device Mapping). При этом на томах VMFS и NFS виртуальные диски машин хранятся в формате vmdk, а на томах RDM виртуальная машина хранит свои данные напрямую на LUN. Сегодня мы поговорим о том, в каких форматах могут быть виртуальные диски машин в VMware vSphere, к которым обращаются серверы VMware ESX 4... Таги: VMware, ESX, VMFS, vSphere, vmdk, Storage, iSCSI, FC, RDM
Немного новостей от наших технологических партнеров, компании Veeam Software. Антон Гостев, Product Manager в Veeam Software, открыл блог vNotion.com. Там Антон будет рассказывать о продуктах компании Veeam (преимущественно Veeam Backup, насколько я понимаю) и, само собой, о платформе VMware vSphere, под которую Veeam делает свои продукты.
Интересная запись - Slow disk read speed on ESX4, в ней Антон описывает интересную особенность VMware ESX 4 из состава vSphere - медленное чтение (падение скорости в 3 раза!) при использовании агента резервного копирования в сервисной консоли. Антон провел тест при различных условиях и обнаружил, что виртуальная машина на ESX читает свои данные с VMFS быстро, а вот Service Console сильно тормозит! При этом такого не было в VMware ESX 3.5...
Многие из вас уже, должно быть, начинают думать о начале проекта по виртуализации серверов на базе платформы VMware vSphere, которая стала вполне доступной для сектора SMB (издания VMware vSphere Essentials). Кроме того, пакеты VMware vSphere Acceleration Kits со скидками для приобретающих впервые - никто не отменял (скидки 20-30% при покупке лицензий на 3-4 сервера). Но сегодня не о ценах, а о том, как правильно спланировать виртуальную инфраструктуру VMware vSphere с учетом появившихся новых технологий и возможностей VMware.
Итак, если начать планировать по этапам, вот так выглядят составляющие инфраструктуры при проектировании решения VMware vSphere 4... Таги: VMware, vSphere, ESX, Fault Tolerance, vNetwork, DRS, Backup, ESXi, VMFS, vCenter, PowerShell
Одна из замечательных технологий, которая стала доступна из GUI в VMware vSphere, Storage VMotion позволяет перемещать хранилище виртуальной машины (ее виртуальные диски) на другой том VMFS / LUN без остановки работы служб и приложений.
На диаграмме ниже показано, какие именно фазы проходят в ESX / ESXi при перемещении виртуальной машины между хранилищами.
RSS
