Архив

Публикации с меткой ‘VM’

Ошибка клонирования при разном времени на хостах ESXi

Недавно столкнулся с небольшой проблемой, при клонировании ВМ на другой хост на 99% появляется ошибка:

Failed to clone a VM, error: Invalid configuration for device «0″

Дело в том, что время у гипервизоров, между которыми осуществляется клонирование не должно различаться более чем на 5 минут. Если же время сбито, может появиться подобная ошибка. В этом случае все хосты нужно синхронизировать с одним NTP сервером и клонирование пройдет без каких-либо проблем.

Categories: VMware Tags: , ,

Software iSCSI

Появилось желание выложить на блог пару статей настройки и конфигурации продуктов для построения iSCSI хранилищ на программном уровне. Но предварительно немного расскажу о том, какие продукты более всего мне интересны, и на какие также стоит обратить внимание (конечно список будет весьма субъективный, так как каждый сам выбирает подходящее решение, о некоторых я мог даже и не слышать). Здесь я расскажу лишь о тех продуктах, с которыми имел дело лично, будь то настройка в компаниях, либо тестовое изучение.

Прежде всего, что из себя представляют данные продукты в целом. Есть разные модификации, как платные, так и бесплатные, с различным функционалом (повышенная отказоустойчивость, безопасность с разными уровнями аутентификации и т.д.), но суть сводится к одному: имея несколько гипервизоров со своими локальными дисковыми подсистемами, на основе одного из этих гипервизоров, мы создаем одно общее дисковое пространство (DataStore), которое будет видно всем остальным гипервизорам. Этим, по сути, мы создаем общее СХД для всех гипервизоров, которое будет необходимо для таких технологий, как HA, DRS, vMotion.

Для этого нам нужно одной ВМ, назовем ее iSCSI VM, выдать диск большого объема (такого объема, которого нужно нам общее хранилище) и технологиями программных решений построения софтверных iSCSI создать так называемый iSCSI Target, который мы впоследствии покажем нашим гипервизорам. Далее технологиями vSphere мы создаем датастор, который будет ссылаться на этот диск ВМ, и на котором будут лежать другие ВМ. Выглядеть это будет примерно следующим образом:

Конечно, по картинке ясно, что если ESXi01 упадет, то будут недоступны не только данные iSCSI VM, но и данные всех остальных ВМ, которые лежат на нашем общем датасторе. Некоторые продукты умеют создавать реплицированную копию, примерно так же, как технология Fault Tolerance, тем самым обеспечивая зеркалированную запись данных на несколько гипервизоров, при этом в случае падения одного из них, ЦОД останется функциональным.

Итак, приведу примеры таких продуктов, с которыми лично сталкивался:

  1. StarWind iSCSI – один из наиболее популярных продуктов, довольно простой в управлении и умеющий создавать зеркала, о которых я говорил выше. Существует как в бесплатной версии, так и в платной (в бесплатной довольно порезанный функционал, создавать “зеркала” нельзя). О том, как его устанавливать и настраивать я уже писал на сайте нашей компании. Мне этот продукт очень понравился, есть русская техподдержка, довольно быстро работают специалисты. Установка: ставится как программа на ОС Windows Server. Плюсы: огромное количество фич, легкость в настройки, поддержка русскими специалистами, довольно популярна, поэтому всегда найдется тот, кто может подсказать что-нибудь по этому продукту. Минусы: немалая цена, что неудивительно при таких плюсах, поэтому для местного использования подойдет лишь в виде Free Edition, что довольно урезает ее преимущества (лицензию на Windows Server никто не отменял).
  2. vSphere Storage Appliance – довольно новый продукт, появившийся с выходом пятого поколения VSphere. Примечательно то, что этот продукт является родным продуктом компании VMware, довольно удобен тем, что выпускается как .ova файл, который сам разворачивается в ВМ. Сам функционал будет доступен в виде плагина к VSphere Client, поэтому в других окнах нам сидеть не придется, что очень радует, в этом смысле VMware о нас заботится (vDR, Operations, vShield). Продукт также умеет создавать свои зеркала, и недавно (об этом писал в прошлой статье) стал поддерживать RAID5 и RAID6. Установка: как отдельная ВМ с уже установленной ОС и всеми сервисами. Плюсы: интеграция в VSphere, наличие специального бандла Essentials Plus с лицензией VSA, который сильно снижает стоимость продуктов. Минусы: довольно новый продукт, на практике его пробовало меньшее количество людей, чем Starwind, могут возникнуть вопросы технического характера, которые на форумах останутся без решения.
  3. Openfiler – продукт, выпускающийся в бесплатном варианте с полным набором функций, поддерживающий не только iSCSI Target, но и такие фичи, как FTP, sFTP, NFS, FC, а также умеющий создавать различные типы рейдов на основе дисков .vmdk, подключенных к нему. В ближайшее время я немного постараюсь повысить его популярность и выложу подробное описание продукта с пошаговой установкой и настройкой (разработчики пошли другим путем и начали брать деньги с поддержки, например Admin Guide обойдется вам в 40 евро). Довольно интересный продукт, на нем я поднимал пилотный проект View и Openfiler показал себя довольно достойно. Установка: монтируется как образ к Linux 32-bit OS, ставится на отдельную ВМ. Плюсы: бесплатный продукт с множеством функций, хотя если мы говорим здесь об iSCSI Software, то это не считаем, довольно прост в настройке и управлении, в интерфейс всегда можно попасть из WEB. Минусы: нет поддержки продукта в бесплатном варианте, даже документацию придется покупать, защиту в виде зеркалирования и т.д. придется тоже покупать за деньги.
  4. FreeNAS – этим продуктом довольны многие, наверное, уже пользовались, довольно часто слышал, что его используют в Production и весьма довольны. Как понятно из названия, бесплатный продукт на базе FreeBSD. Один раз настраиваем и спокойно пользуемся, также есть поддержка рейдов и дополнительных опций, правда чтобы настроить все правильно, придется потратить не одну минуту. Разработчики продукта решили, что продукт будет бесплатным, однако совместно с iXsystems выпускают сервера с встроенной СХД на базе FreeNAS, своеобразные software iSCSI стораджи, которые стоят денег, и за которые отвечает компания FreeNAS в плане технического обслуживания. Установка: ставится на отдельную FreeBSD ВМ. Плюсы: бесплатный продукт с множеством фич. Минусы: довольно сложно настраивается, нет поддержки на русском языке.

Также есть продукт Microsoft iSCSI Target, но я никогда им не пользовался, если есть те, кто пользовался и кому есть, с чем сравнивать, можете описать продукт, и я с удовольствием добавлю его в этот пост с пометкой Вашего авторства :)

Диски в Виртуальных Машинах

При создании ВМ, самое большое количество выбора настроек приходится на диски. Если Вы не очень знакомы с этими настройками, вы оставляете все по умолчанию и это правильно. Получаем обычный диск, который нам и нужен. Но эти настройки довольно много значат, если нам нужна специфическая задача. Допустим, нам нужно, чтобы при каждом рестарте ВМ мы получали первоначально созданную конфигурацию. Это нужно, допустим, для тестирования оборудования, или мы из ВМ сделали ThinApp Packager. Тогда дефолтная конфигурация нам не поможет.

Начнем с типов дисков. В новой версии VSphere 5 у нашей ВМ 3 варианта выбора диска:

  1. Thick Lazy
  2. Thick Eager
  3. Thin

Что каждый вариант обозначает:

  1. Lazy диск является толстым и при создании такого диска он будет сразу весь завербован ВМ, то есть другие блоки туда записаны не будут. Но при забронировании блоки не будут очищены от прошлых данных, то есть все данные будут сразу писаться поверх старых. Плюс: моментально создается. Минус: при первом обращении, то есть в первые 2 недели работы, будет понижена производительность;
  2. Eager диски тоже толстые, но в отличие от Lazy, система почистит прошлые блоки и новые данные будут записаны моментально. Плюс: самая быстрая система, только с ней можно использовать технологию Fault Tolerance. Минус: долго создается ВМ (чем больше диск, тем дольше создание);
  3. Thin диски являются тонкими и мы можем выдать им сколько угодно место, все равно физически будет использовать лишь пространство, использованное ВМ на данные момент. Плюс: огромная экономия пространства. Минус: более низкая производительность и надежность, ибо ВМ в каждый момент времени необходимо искать пустые блоки и не факт что она всегда их найдет.

Но эти настройки важный с точки зрения скорости работы, но сам принцип записи и чтения данных остается одинаковым. Но вот за то, какой диск и как данные будут храниться, отвечают другие настройки. Это Independent, Persistent, Non-Persistent. Теперь подробнее о каждом.

По умолчанию у нас следующая картинка:

Это значит, что диск у нас стандартный, все данные попадают на дельта-диск, который создается после создания снимка (snapshot). При откате к прошлому снимку мы получаем диск, который выглядел точь-в-точь, как диск во время делания снимка. Допустим, у нас два диска, системный и пользовательский. Если они оба в таком положении, то по мере создания снапшотов, мы получаем следующую конфигурацию с двумя дельта дисков. Если откатывается назад, то и оба диска откатываются.

Вторая конфигурация, это Independent Persistent disk:

В этом случае данные пишутся сразу на диск, без дельта файла. Нужна такая конфигурация, если у нас есть диск, который всегда должен быть одним и тем же, откатываемся мы назад или нет. В основном это лучше, если у нас есть пользовательский диск, на котором данные должны быть сохранены.

Последний вариант – это Non-Persistent disk:

Такой тип диска нужен как раз в тестовых средах. Данная конфигурация означает, что во время перезагрузки мы получаем диск, каким он был до внесения на него изменений. Дельта файл, на который попадают изменения, удаляется, и мы получаем прошлую конфигурацию. Это удобно, если мы установили тестовое ПО, либо тот же ThinApp, который должен использоваться при незагрязненной системе. Также удобно, если ВМ использует много народу и нужно приводить ее постоянно к прошлому состоянию.

При понимании этих значений, мы никогда не потеряем данные, и у нас будет диск настроен так, как нам нужно.

Categories: VMware Tags: , ,

Диски рабочих столов View

Если мы используем в своей VDI инфраструктуре View Composer и linked clones, то могут возникнуть недопонимания, как диск самой ВМ называется на датасторе (файл .vmdk) и где он находится. Дело в том, что при создании ВМ создание дисков подразделяется на несколько этапов, при это и находиться диски будут в разных местах. Этапы следующие:

  1. При создании самой ВМ с десктопной ОС Windows мы определяем, сколько у нас места будет занимать системный диск;
  2. При создании пула уже в VMware View мы выбираем, сколько у нас будут занимать еще два диска.
1 диск (Persistent Data Disk) — диск с пользовательскими данными, на нем будут находиться все данные пользователя, а также бывшая C:\Documents and Settings\. Программы также теперь нужно будет устанавливать на этот диск, по умолчанию нам предлагается назвать его D:\. В зависимости от того, сколько мы его сделаем, столько места будет у пользователя для его личных данных.
2 диск (System Disposable Disk) — диск с временными файлами и логами, своеобразный своп-файл на уровне ОС. Его объем прямо пропорционален производительности на уровне СХД, но больше 10 Гб его делать просто бессмысленно.

После создания пула при заходе на рабочий стол мы увидим следующие диски:

Для нашего случая я взял диск системы 60 Гб, 0.2 Гб отъелись при форматировании Windows’ом NTFS, пользовательский диск 60000 Мб, а также Temp-диск — 4 Гб. Это то, что мы видим со стороны ОС, но все эти диски являются виртуальными и лежат на датасторе в качестве .vmdk файлов. Раз мы создавали их не вместе, то и лежат они в разных папках ВМ. При созданиие linked clones у нас есть 3 типа ВМ:

  • Родительская ВМ (Master Replica), ее еще называют Золотой Образ — та ВМ, из которой мы создаем пул на основе ее снимка, снэпшота.
  • Реплика (replica) — ВМ системного характера, являющаяся базой для всех ВМ в пуле и держащая системный диск с ОС Windows.
  • Клон (linked clone) — сам виртуальный рабочий стол, на котором будут работать пользователи.
Давайте подробнее остановимся на каждом из этих типов и посмотрим его файлы.

Файла в разных типах ВМ

Начнем с Золотого Образа:

1. Это дельты изменений после совершения снэпшотов, то есть диски, которые создавались при создании снимков;

2. Сам системный диск нашего Золотого Образа.

 Эти диски не играют особой роли при расчете занимаемого места рабочими столами, единственное, максимальный объем системного диска начинает рассчитываться уже отсюда, поэтому при создании системного диска нужно быть предельно аккуратным, пользователи его видят и смогут его забить, если не были ограничены права (точнее не его, а дельту, но от этого меньше места не станет :) )

Теперь перейдем к реплике:

3. Это диск с адресом дельты, то есть некая ссылка на него, обращать особо внимания на него нет смысла, так как он всегда весит 1 Мб;

4. Это как раз и есть наш системный диск, сколько он весит, столько у нас занимает система изначально на всех рабочих столах. Это первое значение, которое нужно будет нам в наших расчетах.

Теперь перейдем к рабочему столу:

5. Overhead диск, особо нагрузки не несет, растет по мере увеличения объема дисков;

6. Диск системы, так как VSphere не может понять, что система находится в другом месте, то создает подобный диск, сам по себе не очень интересен, в нем всегда будет какое-то количество информации;

7. Обычный своп-файл на уровне гипервизора, равен выданному объему оперативной памяти;

8. Первый нужный нам диск. Это Temp-диск который виден в самой ВМ, максимальный объем столько, сколько выдали при создании пула во View. Это второе число, которое будет нам важно;

9. Это и есть дельта, то есть накопившиеся изменения, которые пользователь внес в системный диск. Обычно ее объем равен 10-50 % от максимального. Ее процент означает, сколько процентов использует пользователь данных у ее, остальное берет с системного диска. Запомним это число;

10. Ну и последний, пользовательский диск, это то, сколько мы выдали пользователю при создании пула, и на сколько он его уже забил. Этим диском можно оперировать как в самой VSphere, отсоединяя, присоединяя к другим ВМ, так и в интерфейсе View, что правильнее, там есть своя вкладка для этого — Persistent Disks.

Теперь остается понять, как рассчитывается объем занимаемого места самой ВМ. Рассчитывается он из суммы следующих дисков: 4+8+9+10.

Все же место, занимаемое рабочими столами считается следующим образом:  суммируем все 8+9+10 диски всех десктопов и прибавляем к ним один раз реплику. Сам смысл объединенных клонов в том, чтобы системный диск был посчитан один раз, что дает несомненную экономию для СХД.

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

Categories: View, VMware Tags: , , ,

Новое лицензирование Виртуальных Машин

Немного хочу затронуть аспекты нового лицензирования в версии VSphere 5, а именно нюансы лицензирования “тяжелых” ВМ с большим количеством RAM. Как известно, теперь само ограничение на количество ядер снято, то есть теперь мы на это не обращаем внимания, зато появилось новое ограничение на общее количество сконфигурированной памяти, не путать с памятью в пуле (vRAM)! Общая память в пуле – это сколько всего оперативной памяти на всех серверах с установленными лицензиями VSphere, сконфигурированными через VCenter Server, либо отдельно, на каждом хосте ESXi. А вот сконфигурированная память – это количество выданной оперативной памяти всем запущенным ВМ в пуле vRAM, то есть если у нас лицензиями доступно, скажем, 96 Гб, а на серверах у нас 192 Гб, это не нарушение лицензии, это всего-лишь значит, что мы не можем запустить ВМ более чем на 96 Гб в сумме. Но и это не до конца правильно, такое утверждение справедливо лишь для лицензий Essentials и Essentials Plus. У лицензий Standard, Enterprise и Enterprise Plus нет явных ограничений по запуску ВМ, там расчет идет среднего использования памяти в год, если порог за год превышен, то это уже нарушение лицензии. Допустим, у нас лицензиями разрешено использовать 32 Гб, мы полгода использовали 64 Гб, а полгода вообще не использовали сервера, в среднем у нас за год – 32 Гб, и нарушения лицензии не будет. У Essentials китов такой свободы нет, если мы перейдем порог в 192 Гб, а именно столько разрешено использовать в начальных китах, далее ВМ просто не будут запускаться.

Так вот, вернемся к лицензированию “тяжелых” ВМ. Дело в том, что ВМ в новой версии VSphere мы теперь можем выдавать оперативной памяти вплоть до 1 Тб. Но лицензироваться, отбирать vRAM у пула ВМ будет лишь до 96 Гб, далее все будет бесплатно. Например, у нас лицензиями выдано 256 Гб, у нас 2 ВМ по 128 Гб RAM. По идее, вся лицензированная память закончена, но VMware сделала некий бонус, ограничивая снятие памяти с лицензий до 96 ГБ, тем самым 2 ВМ будут работать как 128 Гб памяти но лицензия будет видеть их, как 96 Гб, то есть в сумме 192 Гб, оставив нам еще 64 Гб. Такой бонус не работает для Essentials и Essentials Plus, там если мы используем ВМ 192 Гб, а это значит что она должна исполняться на одном сервере, всего у нас будет 1 сервер, то и вся лицензия будет использована. Это сделано потому, что уровень консолидации будет 1к1, а значит и виртуализироваться смысла не будет. Привожу ссылку на данные ограничения:
Блог VMware
Есть еще один интересный нюанс, меня как то спросили, а что будет если у нас есть 256 Гб в лицензии, и мы включим ВМ 1 Тб, что будет первее, VSphere поймет, что это всего лишь 96 Гб лицензии и пропустит такую ВМ, или скажет что нам выдано 256 Гб и может нам столько не выдать, например нужно создать ВМ с 100 Гб RAM и потом повысить до нужного нам 1 Тб. Тут все просто и ничего не меняется: как я уже писал выше, мы можем включить ВМ даже, если у нас не будет столько в лицензии (для Std, Ent, Ent+), ограничение считается в среднем за год, поэтому все пропустится, включится и ничего дополнительного делать не надо, может быть это еще одна из причин, почему на редакциях Ess, Ess+ данное правило не работает.

Categories: VMware Tags: , , ,

Запуск ESXi внутри виртуальной машины

Очень популярная в последнее время тема, но запишу себе ее в блог, дабы не забыть параметры. Может быть такое, что у нас в наличии есть один сервер ESXi, но в тестовых целях мы хотим использовать несколько гипервизоров, дабы продемонстрировать возможности vSphere. Для этого нам нужно установить гипервизор ESXi как гостевую ОС на ВМ.
Это можно сделать, но по умолчанию аппаратная виртуализация, необходимая для установки гипервизоров VMware, отключена в 4 версии VSphere, нам придется ставить гипервизор и указывать ОС гостевой ВМ, как, например Other Linux (32bit).
Если у Вас уже VSphere 5, то это существенно упрощает задачу, там все гораздо проще.  Нам достаточно лишь выбрать гостевую ОС, как гипервизор ESXi (в ближайшее время выложу скрин, но Вы и сами можете это сделать, найдя в списке гостевых ОС наш гипервизор). Также, чтобы позволить включать внутри виртуального гипервизора ESXi, достаточно добавить внутрь файла /etc/vmware/config параметр (подсказано Михаилом Михеевым):
vhv.allow = «TRUE»
В VSphere 4 нам приходилось изменять конфиг файла .vmx нашей ВМ. Чтобы включить аппаратную виртуализацию на 4 версии, заходим в Edit Settings ВМ (машина должна быть выключена), далее вкладка Options->General->Configuration Parametrs..
Мы попадаем в меню отладки ВМ, вписываем следующие три строки, если их нет в наличии, если какая-то есть, меняем значение:
guestOS = "vmkernel"
monitor_control.vt32 = "TRUE"
monitor_control.restrict_backdoor = "TRUE"
 Выглядеть это будет следующим образом:
После этого сохраняем изменения и включаем ВМ. Теперь ВМ будет считать, что имеет аппаратную виртуализацию, на самом деле мы просто прокинули ее на программном уровне.
Также можно изменить этот файл, зайдя в Tech Support Mode и командой vi изменить .vmx файл нашей ВМ, данные будут расположены там в столбик, разделенные табуляцией. Также можно воспользовавшись просмотром датастора, скачать файл на ПК и изменить его блокнотом.

Проблемы с удалением старых портгрупп ВМ

Проблема:
Может получиться так, что Вы создадите со временем другую портгруппу ВМ (первоначально она называется VM Network), а старую решите удалить. И может возникнуть так, что vSphere Client будет писать, что старая портгруппа приатачена к Вашим, ВМ, хотя Вы все уже перевели на новую. У Вас один адаптер, он «смотрит» в новую портгруппу, а старая все равно показана, что она у этой ВМ есть. Как же тут быть?
Решение:
Тут все очень просто. Дело в том, что до этого вы создавали снэпшоты (снимки) ВМ, которые были еще со старой группой на адаптерах. Дело в том, что снэпшоты сохраняют все старое виртуальное железо, и пока Вы не удалите их, либо откатитесь к ним и поставите новую портгруппу для всех адаптеров, старая портгруппа не удалится.
В принципе тут нет ничего страшного, проще не обращать внимания и не трогать старую портгруппу, даже если Вы переносите ВМ между хостами с разными портгруппами, максимум что будет, это адаптер ВМ не сразу приатачится к новой портгруппе, что конечно же может быть страшно, если требуется от ВМ бесперебойная работа в сети. В этом случае Вам и нужно создавать одинаковые портгруппы, либо переходить на virtual Distributed Switches :)
Categories: VMware Tags: , , ,