Skip navigation
2011

Чтобы не потерять и не забыть. Серия статей по установке своих SSL сертификатов:

Image3_thumb.png

Статья под названием: "VNXe 3300 performance follow up (EFDs and RR settings)", опубликованная в блоге henriwithani.wordpress.com, является очередным доказательством того, что "IO Operation Limit=1" может на определенных нагрузках дать куда более большую производительность, чем "IO Operation Limit=1000 (1000 - это, как раз, и есть значение, установленное по умолчанию)". Вот, что сам автор пишет в заключении своей статьи:

Changing the default RR policy setting from the default 1000 io to 1 io really makes a difference on VNXe. On random workload there is not much difference between these two settings. But with sequential workload the difference is significant. Sequental write IOps and throughput is more than double with certain block sizes when using the 1 io setting.

Примечание: Прежде, чем что-то менять в своей среде, нужно обязательно все протестировать. Потому что нельзя на все 100% быть уверенным, что "IO Operation Limit=1", конкретно в вашем случае, даст более высокую производительность. Тестировать и, еще раз, тестировать. И только после этого пускать в продакшен.

Автор блога vmguru.nl опубликовал весьма интересный документ: "HYPERVISOR COMPARISON". Как вы уже, наверное, могли догадаться, в данном документе приведено сравнение различных версий enterprise гипервизоров, а именно:


  • VMware vSphere 4
  • VMware vSphere 5
  • Microsoft Hyper-V Server 2008 R2
  • Microsoft Hyper-V Server 2008 R2 SP1
  • Citrix XenServer 5.6
  • Citrix XenServer 6


В общем, документ, как уже было сказано ранее, получился очень интересным и познавательным. К ознакомлению однозначно рекомендую.

В этом посте я хотел остановиться на том, что уже сделано, а, точнее, на том, что уже написано мною про VMware HA. Итак. Из небезызвестной нам книги "vSphere 5 Clustering Technical Deepdive" переведено-законспектировано 4 главы. Вот они:



Кроме выше приведенных статей, я написал (перевел) еще некоторое количество статей на тему, как работает и как взаимодействует HA с другими компонентами VMware vSphere, которые можно легко найти, отфильтровав посты по тегу: HA или Cluster-HA. Надеюсь, что эти статьи пригодятся вам в нашей совсем не легкой, но очень интересной работе.

pdficon_large.gif

Очередная полезная шпаргалка (текст, выделенный СЕРЫМ ЦВЕТОМ - это то, в чем автор немного сомневается, поэтому, имейте это в виду) от блогера Forbes Guthrie. Для вашего удобства существует PDF версия этой шпаргалки, которую вы можете получить, пройдя вот по этой ссылке, либо кликнув по соответствующей pdf-иконке.

Данная статья является очень кратким конспектом соответствующ(их/ей) глав(ы) книги:

" vSphere 5 Clustering Technical Deepdive (Authors: Duncan Epping, Frank Denneman) ".


Купить eBook (Kindle) версию книги (~12$) вы можете на сайте Амазона (amazon.com)

VMware vSphere High Availability будет пытаться перезапустить защищенные виртуальные машины только тогда, когда произойдет одно из следующих событий:


  • Хост вышел из строя
  • Хост изолирован
  • Ошибка в гостевой ОС


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


Restart Priority and Order

В VMware vSphere 5, HA будет перезапускать виртуальные машины в следующем порядке:


  • Агентские (Agent) виртуальные машины
  • FT (Fault Tolerance) secondary виртуальные машины
  • Виртуальные машины с высоким приоритетом (high) перезапуска
  • Виртуальные машины со средним (medium) приоритетом перезапуска
  • Виртуальные машины с низким (low) приоритетом перезапуска


Как мы видим, VMware HA в первую очередь будет пытаться перезапустить агентские виртуальные машины (хорошим примером здесь будет "vShield Endpoint"). Затем - FT secondary ВМ, ну, а дальше, как доктор прописал - виртуальные машины c "high", "medium" и "low" приоритетами. В случае, если по каким-либо причинам агентскую ВМ не удается запустить, повторный её запуск будет произведен чуть позже. Ну, а в это время, VMware HA будет выполнять перезапуск других ВМ. То есть, в случае, если не получается запустить агентскую ВМ, HA не застопорится на этом, а будет и дальше продолжать перезапускать другие ожидающие перезапуска ВМ.


Restart Retries

Когда VMware HA нужно перезапустить виртуальную машину, то не факт, что с первого раза ВМ нормально запустится. Поэтому VMware HA будет пытаться после первого неудачного запуска перезапустить виртуальную машину еще четыре раза:


  • T0 – Initial Restart
  • T2m – Restart retry 1
  • T6m – Restart retry 2
  • T14m – Restart retry 3
  • T30m – Restart retry 4


А теперь представьте себе ситуацию, когда мастер-хост, допустим, в третий раз выполняющий перезапуск ВМ, выходит из строя. Что тогда? Тут все предельно просто. Когда новый мастер будет выбран, он начнет перезапуск виртуальной машины с T0. Т.е., предыдущая последовательность перезапуска этой ВМ сбрасывается.


Когда дело доходит до перезапуска виртуальных машин, VMware HA не будет выдавать больше 32 одновременных "power-on" задач на хост. Например, если в HA кластере есть только два хоста, и если второй хост, на котором запущено 33 ВМ с одним и тем же приоритетом, выходит из строя, то HA на первый хост выдаст только 32 одновременных "power-on" задачи. А вот 33-я ВМ сможет запуститься только после того, как хотя бы одна из предыдущих 32 задач успешно выполнится или завершится с ошибкой.


Если нужно перезапустить 32 виртуальные машины с низким приоритетом и одну ВМ с высоким приоритетом, то HA, как и положено, сначала отдаст команду хосту на запуск ВМ с высоким приоритетом, но при этом, как это уже было написано чуть выше, HA не будет ждать, пока ВМ с высоким приоритетом запустится, и отдаст еще 31 команду на запуск других ВМ с более низким приоритетом. То есть, теоретически возможно, что в случае неудачного запуска ВМ с высоким приоритетом, виртуальные машины с более низким приоритетом могут запуститься раньше, чем ВМ с более высоким приоритетом.


Вот теперь, когда мы рассмотрели порядок, приоритет и количество попыток перезапуска ВМ, самое время рассмотреть различные сценарии, такие как выход из строя мастера, слейва или изоляция хоста.


The Failure of a Slave

Когда slave-хост выходит из строя, то сценарий будет следующим:


  • T0 – Slave-хост выходит из строя
  • T3s – Мастер начинает мониторинг "datastore heartbeats" в течение 15 секунд

  • T10s – Хост помечается как "недоступный (unreachable)", и мастер начинает через management network пинговать вышедший из строя хост

Этот непрерывный пинг будет генерироваться на протяжении 5 секунд.

  • T15s – Если "heartbeat" датасторы не были сконфигурированы, то хост ESXi объявляется "мертвым" (dead), и начинается процесс перезапуска виртуальных машин

  • T18s – Если "heartbeat" датасторы БЫЛИ сконфигурированы, то хост ESXi объявляется "мертвым" (dead), и начинается процесс перезапуска виртуальных машин


Для лучшего понимания, вот вам диаграмма:

slave-failure.jpg

Теперь давайте рассмотрим сценарий, при котором мастер-хост выходит из строя.


The Failure of a Master

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


  • T0 – Мастер вышел из строя
  • T10s – Инициируется процесс выбора мастера
  • T25s – Мастер выбран и считывает файл "protectedlist"
  • T35s – Новый мастер инициирует процесс перезапуска всех на данный момент не запущенных виртуальных машин, находящихся в файле "protectedlist" (то есть, защищенных VMware HA).


Диаграмма для лучшего понимания:

master-failure.jpg

Как вы можете видеть, отказ мастер-хоста влечет за собой более длительный простой в работе виртуальных машин, чем отказ слейв хоста. Но это и логично. Ведь мастер, это ж не слейв :0).


Isolation Response and Detection

Isolation Response

Про "Isolation Response" у меня уже есть ранее написанная статья: "VMware vSphere 5 HA - Isolation Response". Здесь же я опишу только то, чего нет в моей статье. Итак. Когда действие "Isolation Response" срабатывает, хост удаляет из файла "poweron" выключенные виртуальные машины. Мастер узнает о том, что виртуальные машины исчезли (были выключены) и инициирует процесс перезапуска этих ВМ.


Кроме того, когда все же срабатывает действие, заданное в "Isolation Response", то для каждой виртуальной машины будет создан соответствующий файл в каталоге "poweredoff". По наличию этого файла мастер будет знать, что виртуальная машина была выключена именно в результате срабатывания действия "Isolation Response".


Isolation of a Slave

  • T0 – Происходит изоляция хоста (слейва)
  • T10s – Slave переходит в состояние выборов
  • T25s – Slave избирает себя, как мастер
  • T25s – Slave пингует "isolation addresses"
  • T30s – Slave объявляет себя изолированным и выполняет действие "Isolation Response"


После завершения этой последовательности мастер, через "poweron" файл, узнает, что slave был изолирован, и далее мастер будет действовать, основываясь на информации, предоставляемой слейвом.


Isolation of a Master

  • T0 – Происходит изоляция хоста (master)
  • T0 – Master пингует "isolation addresses"
  • T5s – Master объявляет себя изолированным и выполняет действие "Isolation Response"


Additional Checks

Для того, чтобы уменьшить количество ложных срабатываний, вы можете, с помощью параметра "das.isolationaddress", добавить несколько, а, конкретнее, до 10 проверочных адресов изоляции (isolation addresses), которые хост будет пинговать.

isol-address.jpg

С этим разобрались, теперь переходим к самому интересному - к перезапуску ВМ.


Restarting Virtual Machines

Ну вот, мы и добрались до самого главного, до того, как же происходит перезапуск виртуальных машин. Итак. Давайте предположим, что вышел из строя slave-хост. Когда мастер понимает, что слейв разделен или изолирован, он определяет, какие виртуальные машины работают на нем, считывая "poweron"-файл. Если slave-хост не изолирован и не разделен, и при этом происходит сбой, то мастер будет использовать свои ранее закэшированные данные о виртуальных машинах, запущенных на этом хосте до сбоя.


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


И вот, после всех этих действий, VMware HA имеет список виртуальных машин, нуждающихся в перезапуске. Осталось только определиться, где разместить виртуальные машины, в смысле, в каком порядке и на каком именно хосте, перезапустить ту или иную ВМ. Для этого VMware HA берет во внимание следующее:


  • Резервирование по CPU и memory, в том числе и memory overhead для этой ВМ
  • Количество незарезервированной мощности на хосте, входящем в кластер
  • Приоритет перезапуска относительно других нуждающихся в перезапуске ВМ
  • VM-to-Host список или еще по-другому, матрицу совместимости
  • Количество dvPorts, необходимых для ВМ и доступных на хосте-кандидате
  • Максимальное количество vCPU и ВМ, которые могут работать на этом хосте
  • Restart latency


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


Если место для размещения ВМ найдено, мастер пошлет на каждый целевой хост определенный набор виртуальных машин, которые необходимо перезапустить, но, заметьте, что не больше 32-х перезапускаемых ВМ на каждый хост. Если виртуальная машина успешно запускается на хосте, то хост сообщит мастеру об этом, и мастер удалит эту ВМ из списка: "restart list".


Если HA не может найти хост для размещения ВМ, то мастер помещает эту ВМ с список "pending placement list". И после этого HA вернется к этой виртуальной машине только тогда, когда произойдет одно из следующих событий:


  • vCenter предоставит новый VM-to-Host список совместимости (матрицу)
  • Хост сообщит о том, что незарезервированная мощность увеличилась
  • Хост присоединился или переподсоединился к кластеру

Например, когда хост выводится из режима обслуживания или добавляется в кластер

  • Обнаружен новый сбой, при котором пострадали виртуальные машины
  • Произошел какой-либо сбой во время сбоя виртуальной машины (англ. вариант см. ниже)

A failure occurred when failing over a virtual machine


Мастер постоянно отчитывается перед vCenter о виртуальных машинах, которые не удается нигде разместить. И, если для кластера включен DRS, то данная информация будет использована при балансировке нагрузки с целью обеспечить необходимое количество ресурсов для ожидающих перезапуска виртуальных машин.


Split-Brain Scenario

Начиная с версии 4.0 Update 2, если ESXi обнаруживает, что блокировка на VMDK файл была потеряна, то HA автоматически выключит эту виртуальную машину. Это, как раз, и помогает избежать сценария, когда существует две включенные ВМ, то есть того самого пресловутого "Split-Brain" сценария.

Понимать, что такое ALUA и с чем его "едят", безусловно, очень важно. Ниже представлено описание ALUA, взятое из блога blog.aboutnetapp.ru:

ALUA, или Asymmetric Logical Unit Access это протокол внутри спецификаций SCSI-2 и SCSI-3, позволяющий правильно организовывать доступ к данным, доступным по различным путям с различными характеристиками доступа. Для его использования, понимать ALUA должны все участники, как система хранения, так и OS хоста.

Администраторам, которые слышать не слышали об ALUA, я думаю подборка интересных статей и постов, сделанная мною на эту тему, будет очень даже кстати:

alua1.PNG


blog.aboutnetapp.ru


deinoscloud.wordpress.com


vm.pro-it.kz


kb.vmware.com


virtualgeek.typepad.com


yellow-bricks.com

В блоге: "edwinfriesen.nl" увидел я статью, в которой приводятся даты окончания поддержки того или иного продукта. И, среди всего прочего, есть вот такая табличка:

eom-eof.jpg

Источник: Storage IO Control and Storage vMotion?


Вопрос: "Может ли Storage IO Control как-то повлиять на процесс Storage vMotion?" Ответом на этот вопрос будет - "Да, может". Например, если процесс Storage vMotion дисков виртуальной машины на хосте ESXi загрузит хранилище настолько, что latency превысит пороговое значение, то SIOC, в этом случае, ограничит процесс Storage vMotion тем количеством ресурсов, сколько отведено виртуальной машине, чьи диски перемещаются.


Хочу отметить, что SIOC начнет урезать Storage vMotion в том случае, когда задержка будет выше порогового значения. И еще, если массив поддерживает VAAI, то Storage vMotion пройдет красиво и гладко, при этом не создавая никакой нагрузки на storage-сеть.


Из комментариев к статье Дункана следует, что если массив, поддерживающий VAAI, будет самостоятельно перемещать диски виртуальных машин, и при этом этот процесс очень сильно загрузит массив, то SIOC здесь ничем не поможет (это мой вывод после прочтения статьи и комментариев к ней, возможно, я ошибаюсь).

Источник: Using the vSphere Syslog Collector and want to change rotation/sizing?


Возможно, во время эксплуатации: "vSphere Syslog Collector", вам понадобится изменить значение некоторых параметров, которые были заданы еще на этапе установки. Например, вы захотите увеличить максимальный размер лог-файлов или количество архивных лог-файлов. Помочь вам в этом может конфигурационный файл vmconfig-syslog.xml:


  • Windows 2003 –> C:\Users\All Users\VMware\VMware Syslog Collector\vmconfig-syslog.xml
  • Windows 2008 –> C:\ProgramData\VMware\VMware Syslog Collector\vmconfig-syslog.xml


Открыв файл vmconfig-syslog.xml, вы сможете изменить все нужные вам настройки:

<defaultValues>
<port>514</port>
<protocol>TCP,UDP</protocol>
<maxSize>2</maxSize>
<rotate>8</rotate>
<sslPort>1514</sslPort>
</defaultValues>

Думаю, большинству будут интересны только два параметра: <maxSize> и <rotate>.

У кого есть лишние 30-40 минут - посмотрите это видео, сделанное Kendrick Coleman. Может, чего интересного увидите, тем более, что видео хорошего качества, только вот длинное чересчур. Но, как у нас говорится, дарёному коню в зубы не смотртят:0). Открываем бутылочку, а, может, и две холодненького пива и глядим:


Источник: Best Practice: How to correctly remove a LUN from an ESX host


Для того, чтобы правильно удалить с хоста VMware ESXi 5.0, ранее презентованный ему LUN, вам необходимо будет выполнить следующие действия:

Дополнительную информацию вы можете получить, обратившись к этим статьям: 1 и 2.

  1. Unregister all objects from the datastore including VMs and Templates
  2. Ensure that no 3rd party tools are accessing the datastore
  3. Ensure that no vSphere features, such as Storage I/O Control or SDRS, are using the device
  4. Detach the device from the ESX host; this will also initiate an unmount operation
  5. Physically unpresent the LUN from the ESX host using the appropriate array tools
  6. Rescan the SAN

Статья в VMware KB: "Unpresenting a LUN in ESXi 5.x" также будет очень полезной.

В блоге "VMware vSphere Blog" появилось весьма подробное и с большим количеством скриншотов руководство: "How to configure ESXi to boot via Software iSCSI?" про то, как настроить загрузку хоста ESXi по iSCSI, используя для этого софтварный iSCSI, вшитый в сетевую карточку (NIC). К ознакомлению рекомендую.

Если вы обновляете хосты VMware ESX(i) 4.1 до ESXi 5.0 с использованием Update Manager, то есть вероятность того, что вам пригодится следующее руководство: How to Add a 3rd Party driver to a baseline in Update Manager, в котором шаг за шагом показано то, как добавить в baseline драйвер стороннего производителя.

Vladan SEGET в своем блоге опубликовал занимательный обзор инструмента "PHD Virtual Monitor", предназначенного для мониторинга виртуальной инфраструктуры и её окружения. Вот, что он пишет в начале своей статьи по поводу этого инструмента:

PHD Virtual Monitor 10.0.1 – a new update of the product from PHD Virtual. This product is compatible not only with VMware vSphere, but also with Citrix XenServer. The product can monitor not only the physical hypervisors and their respective VMs, but also the surrounding physical infrastructure (servers, switches, routers…). The application monitoring is also possible where you can get deep look at your applications (running inside of VMs or on physical servers) requires the agent deployment in each VM or physical server.


Supported hypervisor’s versions:  VMware vSphere 4.x, 5.0, Citrix XenServer 5.5 and 5.6, 6.0

То есть, "PHD Virtual Monitor" позволяет мониторить виртуальную инфраструктуру, построенную не только на базе VMware vSphere, но и на базе Citrix XenServer. Для тех, кому интересна данная тема, я думаю, обзор, опубликованный Vladan SEGET, придется очень даже кстати.

red-hat.JPG

Несколько дней назад компания Red Hat публично анонсировала бета-версию своей собственной платформы для виртуализации, а если конкретнее, то это "Red Hat Enterprise Virtualization (RHEV) 3.0 public beta".


Для получения дополнительной информации обратитесь к первоисточнику этой новости, либо к официальному анонсу от компании Red Hat.


Там же, в первоисточнике, вы найдете небольшую, но вполне себе полезную сравнительную таблицу: "RHEV 3.0 vs vSphere 5.0".

Очередная полезная шпаргалка (текст, выделенный серым цветом - это то, в чем автор немного сомневается, поэтому имейте это в виду) от FORBES GUTHRIE (PDF версия):

VM-section-alpha-1-277x300.pngVM-section-alpha-2-277x300.png

Давным-давно в какой-то из статей встречал я упоминание про то, какие нагрузочные профили в IOmeter нужно использовать, чтобы, например, воспроизвести нагрузку, создаваемую сервером баз данных. И вот совсем недавно попалась мне на глаза одна из таких статей: "Storage System Performance Analysis with Iometer", в которой имеется вот такая вот табличка:

 

ApplicationBlock SizeRandomnessRead/write Ratio
Exchange 20034K80%60% read (40% write)
Exchange 20078K80%55% read (45% write)
SQL Server16K, 64K100%66% read (34% write)


Я думаю, какие-либо комментарии к таблице излишни. Поэтому идем дальше. Помимо таблицы в статье есть некоторое количество полезных и важных рекомендаций. Вот они:


  • Значение параметра "# of Outstanding I/Os" установите равным 16 или больше (не нужно данное значение выставлять больше 32, так как это ни к чему не приведет, потому что по умолчанию размер очереди в ESXi равен 32). Если оставить значение равное 1, то нагрузка, генерируемая на массив, будет относительно низкой.


  • Для тестирования СХД в программе IOmeter на вкладке "Disk Targets" лучше всего выбрать неформатированный диск (unformatted disk), если, конечно, он есть, что позволит дать более объективную оценку производительности СХД.

Неформатированные диски для большей наглядности помечаются голубым цветом.

iometer_1.JPG

  • Убедитесь в том, что значение "maximum disk size" на вкладке "Disk Targets" установлено в значении больше, чем доступно оперативной памяти (RAM) на сервере. Например, если при тестировании отформатированного диска вы установили значение "maximum disk size" в 200,000 секторов (или 100 MB), и при этом у вас на сервере имеется 1GB RAM, то большинство операций ввода-вывода будет перехвачено и закешировано гостевой ОС, хостом, либо самой СХД. Для того, чтобы избежать кэширования, установите "maximum disk size" в значении, как минимум, в 4 раза превосходящем объем доступной памяти в самом крупном кэше вашей инфраструктуры.


  • Проводите тестирование на самом незагруженном сервере. Если сервер очень загружен, то результаты тестов будут искажены. Рекомендуется проводить тестирование на сервере, который загружен не более, чем на 30%.


Соблюдение всех этих рекомендаций поможет вам получить наиболее объективные показатели производительности вашей системы хранения данных.

Все мы уже, наверное, знаем, что вышел vCloud Director 1.5, и что стал доступен соответствующий Virtual Appliance. Теперь не нужно заморачиваться с установкой Red Hat и Oracle. Но данный пост не об этом, а о том, что с выходом vCloud Director 1.5 стало возможным в качестве сервера базы данных использовать SQL Server 2008 (для vCD 1.0 в качестве БД можно было использовать только Oracle), что, несомненно, очень приятная новость.


Так вот. В сети уже есть соответствующее руководство про то, как правильно настроить SQL 2008 для работы с vCD 1.5: Installing vCloud Director 1.5 With SQL Server 2008. Ну и, конечно, не нужно забывать про официальный документ: VMware vCloud Director 1.5 Evaluation Guide, в котором есть также немного информации про настройку vCD + SQL 2008.

Источник:Mandatory DRS Rules and HA


Duncan Epping в посте, размещенном в блоге yellow-bricks.com, дал ответ на вопрос, касающийся того, учитывает ли VMware vSphere HA правила "DRS Affinity" или нет. Изначально вопрос звучал примерно так: "Учитывает ли vSphere 5 HA правила VM-Host Affinity?". Итак, начнем с того, что существует два типа VM-Host Affinity правил:


  1. Preferential Rules
  2. Mandatory Rules


Отличие между этими правилами в том, что правила "Mandatory" vSphere HA будет обязательно соблюдать, даже если это приведет к простою виртуальных машин. А вот правила "Preferential" носят просто рекомендательный характер, если эти правила можно соблюсти, то хорошо, если нет, то ничего страшного. vSphere 5 HA определяет то, где можно запустить виртуальную машину в соответствии с правилами DRS, ориентируясь на "VM-to-Host" матрицу совместимости, которая фактически содержится в служебном файле "compatlist".

Такая матрица совместимости существует для каждой HA защищенной ВМ.

Файл "compatlist" ведется и обновляется непосредственно самим vSphere HA:

compatlist.jpg

Источник: New SQL 2012 Licensing and Its Impact On Virtualization


Для специалистов, которые на предприятии занимаются вопросами лицензирования, думаю, будет интересно прочитать пост, приведенный выше, как источник. В модели лицензирования будущего SQL сервера от Microsoft много, что изменилось. Microsoft понимает, что в будущем большинство SQL серверов будут перенесены в виртуальную среду. Попросту говоря, будут виртуализированы. Поэтому новая схема лицензирования разработана с оглядкой на виртуализацию.

Другие интересные моменты вы можете прочитать в статье-первоисточнике.

В этом посте я хочу остановиться только на одном, как мне показалось, наиболее интересным для нас, специалистов по виртуализации, моменте:

Software Assurance also gives you the right to full virtual machine mobility. In other words, the rights to use vMotion/DRS in vSphere to move your SQL workloads more than once per 90 days. You still need the appropriate Windows license to allow that mobility, but again this is another reason why Software Assurance is becoming mandatory.

То есть, если у вас нет "Software Assurance", то вы не вправе перемещать свой виртуальный SQL Server с одного хоста на другой чаще, чем один раз в три месяца (90 дней). Но если же у вас есть "Software Assurance", то это дает полную свободу для перемещения виртуального SQL сервера с одного хоста на другой. Остальное читайте в первоисточнике.

docs-storage.jpg


Появился интересный документ, касающийся вопроса выявления узких мест в подсистеме хранения виртуальной инфраструктуры, построенной на основе VMware vSphere.


Автором этого документа является небезызвестный многим нам блогер (www.vsphere-land.com) и VMware vExpert - Eric Siebert.


Для меня данный документ интересен тем, что в нем приводится хорошее описание счетчиков: "GAVG/cmd, KAVG/cmd, DAVG/cmd, QAVG/cmd" и их пороговых значений.


Для удобства я прикрепил PDF-файл этого документа к данному посту. К ознакомлению документ рекомендую.

Источник: vSphere 5 HA – Isolation Response which one to pick?


Тему Isolation Response так или иначе я освещал в предыдущих своих статьях, которые являются очень кратким конспектом (со свободным переводом с англ.) соответствующей главы, достаточно известной в узких кругах, книги "vSphere 5 Clustering Technical Deepdive":

Купить eBook (Kindle) версию книги (~12$) вы можете на сайте Амазона (amazon.com)


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


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


Для Isolation Response вы можете выбрать следующее:


  • Leave powered on – Это вариант по умолчанию. Подходит для большинства организаций. В случае изоляции хост не будет ничего делать со своими виртуальными машинами. Если же хост изолирован полностью, в том числе и от storage network (сеть хранения), то HA поймет, что хост полностью изолирован и отключит виртуальные машины сразу же после того, как появится storage network, и на файлах VMDK будут стоят блокировки, которые говорят нам о том, что виртуальная машина была уже перезапущена на другом рабочем хосте ESXi. Хочу обратить внимание на то, что когда хост полностью изолирован, он не потушит свои ВМ до тех пор, пока не получит доступ к хранилищу и не убедится в том, что на файлах VMDK виртуальной машины присутствуют блокировки.


  • Shut down – В данном случае виртуальная машина будет выключена нормальным способом. Если вдруг по каким-то причинам нормально выключить ВМ не удается, то, по истечению 5 минут, ВМ будет грубым способом выключена (Power off).


  • Power off – Жесткое выключение ВМ. Это самый наихудший вариант для ваших ВМ. И совсем не факт, что после такого выключения вашей виртуальной машине удастся на новом хосте без ошибок загрузиться. Особенно, если речь идет о сервере баз данных. Поэтому очень хорошо подумайте перед тем, как выбрать данный вариант.


На этом пока что все. Продолжение ждите в следующих статьях на тему: "VMware vSphere 5 HA".

Источник: Partitioned Cluster with HA vSphere 5, who owns what?


В блоге yellow-bricks.com имеется статья, приведенная как источник, которая немного проливает свет на то, как ведет себя HA, когда произошёл частичный сбой в management network, и кластер vSphere HA перешел в состояние: "Partitioned" (разделенный). Т.е., когда существует, по крайней мере, две management-сети, недоступные друг для друга.


Вот что Duncan Epping пишет по этому поводу. В нормальной ситуации, когда кластер vSphere HA становится разделенным, первый избранный мастер завладеет всеми виртуальными машинами, установив для этого соответствующую блокировку на файл "protectedlist". В это время остальные мастер-хосты будут периодически пытаться завладеть файлом "protectedlist", и в случае, когда по какой-либо причине выйдет из строя мастер-хост, который на данный момент владеет файлом "protectedlist", какой-то один из оставшихся мастер-хостов возьмет управление на себя.

protectedlist.jpg

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

14.png


Появился очередной интересный документ, касающийся вопроса мониторинга производительности виртуальной инфраструктуры, построенной на основе VMware vSphere.


Автором этого документа является небезызвестный многим нам блогер (www.vsphere-land.com) и VMware vExpert - Eric Siebert.


Лично для меня данный документ интересен тем, что в нем приводится описание наиболее часто используемых перфоманс-счетчиков.


Для удобства я прикрепил PDF-файл этого документа к данному посту. К ознакомлению документ рекомендую.

Источник: Getting network card driver version in ESXi 5.0


В VMware ESXi 5.0 определить версию драйвера сетевой карты можно различными способами. В частности, для этого можно воспользоваться утилитой ethtool, входящей в состав ESXi:

# ethtool -i vmnic0
driver: bnx2
version: 2.0.15g.v50.11-5vmw
firmware-version: bc 3.5.12 ipms 1.6.0
bus-info: 0000:03:00.0

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

# esxcli system module get -m bnx2

Результат выполнения команды будет примерно следующим:

esxcli-driver-info.jpg

В скором времени VMware обещает добавить в esxcli весь необходимый функционал, который на данный момент реализован в различных других утилитах: vmware-cmd, vmkfstools и т.д. Поэтому начинайте потихоньку осваивать esxcli. Эти знания лишними уж точно не будут.

Углядел интересное пошаговое руководство того, как создать (собрать) свой Virtual Appliances, основанный на ОС Ubuntu. Кто с этим никогда не сталкивался, но очень хочет, это руководство может стать хорошей отправной точкой. Хотя руководство написано на английском языке, у тех, кто знаком с процессом установки Ubuntu Server, проблем с пониманием возникнуть не должно. Рекомендую.

Источник: Change ESXi 5.0 hostname with esxcli


Тем из нас, кто часто заглядывает по ssh на хост ESXi 5.0, могут пригодиться следующие команды по смене имени хоста (полного, короткого и домена):

# esxcli system hostname set --domain=deshifrator.lab
# esxcli system hostname set --host=VRT-01
# esxcli system hostname set --fqdn=VRT-01.deshifrator.lab
 
# esxcli system hostname get
   Domain Name: deshifrator.lab
   Fully Qualified Domain Name: VRT-01.deshifrator.lab
   Host Name: VRT-01

В окне терминала это выглядит следующим образом:

esxcli-hostname.jpg

Источник: vSphere5 Storage vMotion does not rename virtual machine files on completing migration


Большинство из нас, так или иначе, использовали Storage vMotion для ПОЛНОГО переименования виртуальной машины. Для тех, кто не в курсе, немного поясню. Дело в том, что когда вы в vSphere Client'е переименовали ВМ, файлы, связанные с этой ВМ, (в частности, vmx, vmdk файлы) останутся не переименованными. И самым простым способом для полного переименования ВМ было сделать Storage vMotion для этой виртуальной машины. В результате чего ВМ на новом своем хранилище становилась полностью переименованной.


Но, к сожалению, в vSphere 5.0 на данный момент при выполнении операции Storage vMotion, переименование ВМ не происходит. В VMware об этой проблеме знают и обещают в следующем обновлении все поправить. Ждемс.

Источник: The Dell Management Plug-in for VMware vCenter Server – Enabling a Single-Pane-of-Glass Management Interface


Для предприятий, которые используют виртуализацию на базе VMware vSphere на серверах DELL, может пригодиться плагин, который компания DELL выпустила для vCenter, с помощью которого вы сможете управлять своим серверным парком буквально из одного окна.

Минус этого плагина в том, что он совсем не бесплатный.

Думаю, описывать плагин бессмысленно, потому что есть хорошее видео, из которого понятно, что, зачем и почему:

Deshifrator Hot Shot

ThinPrint V-Layer Basic

Posted by Deshifrator Nov 15, 2011

ThinPrint V-Layer Basic - программное обеспечение, призванное значительно упростить системному администратору процесс сопровождения и администрирования принтеров на предприятии. Все знают, насколько геморройно бывает подключить принтер к серверной винде, особенно, если он не сетевой, и при этом нормальных драйверов к нему нет. А еще хуже, если на предприятии по каким-либо причинам используются различные модели принтеров разных производителей. Вот это тогда конкретная головная боль для администратора.


Решили мы в своей организации в демо-режиме протестировать данный программный продукт:


thinprint.png

Вот, что про него написано на официальном сайте производителя:

Cамым распространенным сценарием печати в классических сетях является печать с настольного ПК на сетевой принтер с использованием серверов печати. Для маппинг принтера необходимо наличие драйверов принтеров на настольном ПК.


Технология ThinPrint V-Layer Basic освобождает настольные ПК от драйверов принтеров и сокращает тем самым затраты на их управление. С данной технологией их администрирование осуществляется исключительно на сервере печати.


Одним нажатием клавиши мышки сервер печати преобразуется в V-Layer – сервер, при этом управление драйверами принтера сократится до минимума.

Нам была интересна печать не с рабочих ПК, а с шести терминальных Win2008R2 серверов. Итак, первым делом был поднят принт-сервер, на который затем по сети были подключены различные принтера.

К сожалению, не все принтера у нас на предприятии сетевые. Есть достаточно много HP принтеров, которые подключены напрямую по USB к компьютерам пользователей. Так как пользователи у нас работают на Ubuntu 10.04, то расшарить принтер по порту 9100 не составило особого труда. Таким образом, принтер, который изначально не сетевой по средствам ПК пользователя, превращается в сетевой. Главное, чтобы пробрасываемый принтер поддерживал JetDirect.

Затем на этот принт-сервер был установлен "V-Layer Basic" (размер установочного пакета примерно 16 мегабайт, что меня немного удивило) c демо-лицензией.

Установка "V-Layer Basic" прошла буквально в пару кликов мыши.

После завершения процесса установки остается только зайти в консоль "V-Layer Basic" и для каждого доступного принтера активировать функцию "V-Layer":

v-layer.PNG

И вот теперь, находясь на терминальном сервере, вы можете зайти на принт-сервер и двойным щелчком мыши установить любой из доступных принтеров:

printers.PNG

Теперь давайте разберемся в том, как же все-таки "V-Layer Basic" облегчил нам жизнь. Давайте представим, что на принт-сервере мы установили все необходимые драйвера, подцепили все нужные принтера и расшарили их, но при этом не установили "V-Layer Basic". Тогда, когда вы из-под терминального сервера зайдете на принт-сервер и попытаетесь установить принтер, то на терминальный сервер будут установлены соответствующие под этот принтер драйвера. Это хорошо, когда в винде эти драйвера встроены, и у вас на предприятии используется только один тип принтеров. А если принтеров много? И при этом разных производителей? Тогда вам придется перед тем как подключить очередной принтер, на сервере установить соответствующие драйвера под этот принтер. А если у вас таких серверов ни 10 и не 20? Вам придется на каждый сервер установить нужные драйвера. Это просто ужас!

К сожалению, не редки случаи, когда драйвера различных принтеров, в следствии какой-либо критичной программной ошибки, вещают спулер печати, и Windows на этом зависает, либо начинает очень сильно тормозить. Это особенно трагично для тех пользователей, которые работают удаленно в терминальном режиме. Поэтому держать кучу драйверов на терминальном сервере потенциально очень опасно. Если на принт-сервер установить "V-Layer Basic", то на терминальном (и не только) сервере не нужно будет никаких дополнительных драйверов, кроме одного: "TP Output Gateway" (о нем я расскажу немного ниже). В этом случае если и зависнет спулер печати, то он зависнет только на принт-сервере, и это никак не отразится на терминальных пользователях.


Внедряя "V-Layer Basic", мы потенциально защищаем себя от, скажем так, достаточно нередких фатальных ошибок, возникающих в недрах подсистемы печати.

Теперь представьте еще один случай. Например, у вас есть принтер, на который есть драйвера только под 2003 винду, а терминальные сервера у вас под Windows 2008 R2. Как в этом случае быть?


Чтобы избежать всех этих проблем, нам и нужен "V-Layer Basic". Установленный на принт-сервере "V-Layer Basic" позволяет все принтера, подключенные к серверу, расшарить под одним единым универсальным драйвером "TP Output Gateway". Когда вы для принтера в консоли "V-Layer Basic" включаете функцию "V-Layer", происходит подмена оригинального принтера универсальным. И расшаривается именно универсальный принтер, а к имени оригинального принтера добавляется "_n_" и к нему автоматически закрывается доступ. Таким образом, конечные пользователи видят, зайдя по сети на принт-сервер, только универсальные принтера под своими ранее определенными именами. Соответственно, теперь нет никакой нужды устанавливать драйвера принтеров на все терминальные сервера. Принтер подключается всего за пару секунд двумя нажатиями мыши. Что, несомненно, очень удобно.

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

После месяца тестирования нареканий к работе "V-Layer Basic" нет. Свои функции он выполняет.

Попросили меня настроить сервер под один весьма интересный проект. Сервер физически мне еще не отдали, поэтому все делал на своем тестовом серваке, чтобы к тому моменту, когда мне передадут нормальный сервер, у меня уже все было проверено и оттестировано. Как уже выше говорилось, в моем распоряжении есть один сервер и больше ничего. Ни управляемого свича, ни какого-либо аппаратного шлюза - только один сервер.


Задача передо мной поставлена, как потом оказалось, весьма не простая: имеется определенное количество различных клиентов, которые желают приобрести некоторое количество виртуальных машин. Кто-то хочет приобрести виртуальный сервер, чтобы проще было его администрировать, а кто-то хочет виртуальную машину использовать как обычный офисный ПК, к которому можно получить удаленный доступ по RDP из любого места, где имеется интернет. Вот под это и нужно настроить мне сервер.


На первый взгляд задача достаточно простая. Установил VMware ESXi с бесплатной лицензией (на платную лицензию денег нет, так как это только стартап), создал нужное количество ВМ, сделал доступ к ним по RDP и, в принципе, все. Радуйся, пока все работает. Но у меня ситуация несколько иная. В первую очередь нужно обеспечить должный уровень безопасности. Для этого мне нужно было решить две проблемы:


  1. Как безопасно и удобно для клиента организовать удаленный VPN доступ до сервера ESXi?
  2. Каким образом изолировать виртуальные машины различных клиентов?

Небольшое пояснение ко второй проблеме.

Задача состоит в том, чтобы виртуальные машины разных клиентов на одном VMware ESXi сервере ни коим образом между собой не взаимодействовали. Ну, например, представьте себе ситуацию, когда одна виртуальная машина подверглась взлому, или на ней завелся вирус, и если все виртуальные машины в одной сети, то представьте себе, какими могут быть плачевные последствия. А теперь на минуточку остановитесь и подумайте, как бы вы поступили в данном случае, когда у вас есть только один сервер, и вам нужно сделать так, чтобы всем было хорошо ;)?

По поводу VPN доступа я не особо парился. Есть готовый VPN-сервер "OpenVPN Access Server", который мне очень нравится, его-то я и буду использовать.

Про настройку "OpenVPN Access Server" вы можете прочитать здесь.

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


Итак. Прежде чем я приведу схему сети, хочу рассказать про то, какую сеть и сетевую маску для виртуальных машин я выбрал. Исходя из того, что у одного клиента, в нашем случае, скорее всего не будет больше шести (6) виртуальных машин, я решил использовать /29 (255.255.255.248) маску подсети. Это мне позволит в сети 192.168.1.0 спокойно уместить 30 клиентов. Если этого станет мало - задействую сеть 192.168.2.0, ну, и так далее.


С помощью IP калькулятора я получил всю необходимую для себя информацию:

ipcal1.PNG

Теперь самое интересное. Схема сети:

Небольшое пояснение к схеме:


  • vmnic0 - когда я нахожусь рядом с хостом, через этот интерфейс я им управляю.
  • vmnic1 - к данному сетевому интерфейсу подключен интернет-провайдер.


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

Схему более высокого качества вы можете скачать в конце этой статьи.

vswitch-full.PNG

Как вы можете видеть на схеме, для каждого клиента на стандартном свиче 1 (vSwitch1) я создаю отдельную портгруппу со своим VLAN ID. Тем самым я добиваюсь того, что ВМ разных клиентов между собой без шлюза взаимодействовать никак не смогут.

Из документа: "VMware vSphere 4.1 Configuration Maximums":

cmax.png

512 портгрупп на один vSwitch меня вполне устраивает. Кстати говоря, в vSphere 5 это значение уменьшили ровно в два раза. Зачем, не понятно. Да, кстати, в качестве гипервизора я использую VMware ESXi 4.1 (с бесплатной лицензией).

Как я уже выше говорил, свои эксперименты я провожу на своем тестовом сервере, который работает под управлением VMware ESXi 5.0. Поэтому имейте в виду, что на скриншотах вы, возможно, увидите то, чего нет в vSphere 4.1. Но я думаю, что это не смертельно, поэтому просто примите к сведению.

Изолировать-то мы изолировали, но ВМ должны иметь выход в интернет, да и клиенты как-то должны добраться до своих виртуальных машин. Как видно, без шлюза здесь никак не обойтись.


Но как это организовать?


Эту проблему я решил достаточно просто. На все том же стандартном vSwitch1 я создал еще одну дополнительную портгруппу "GATEWAY-NET" c VLAN ID 4095. Здесь я не буду останавливаться на описании того, что это за VLAN ID 4095 и зачем он нужен. Для нас сейчас главное то, что в этой группе фактически собраны все ранее созданные VLAN'ы клиентов. А это означает только одно: если мы поместим в эту портруппу один из сетевых интерфейсов шлюза и на шлюзе правильно настроим vlan интерфейсы и маршрутизацию, то мы получим желаемый результат.


В качестве шлюзов у меня выступают виртуальные машины с ОС FreeBSD на борту. Вот скриншот того, как настроены vlan интерфейсы на шлюзе "Gateway-Private":

rc-conf-vlan.png

Вывод команды ifconfig:

Gateway.PNG

После того, как "Gateway-Private" настроен, проверяем работу сети на ВМ "Client-001-VM1":

Client-001-VM1.jpg

Как мы видим, от виртуальной машины "Client-001-VM1" пинги до шлюза "ходят". Очень Хорошо. Теперь давайте протестируем сеть на ВМ другого (второго) клиента. Для этого открываем консоль виртуальной машины "Client-002-VM1" и начинаем тестировать сеть:

Client-002-VM1.jpg

А теперь снова посмотрите скриншот приведенный выше, но на этот раз более внимательно. Обратите внимание на вывод команды tracert. Видите, что виртуальная машина второго клиента "Client-002-VM1" обменивается информацией с виртуальной машиной первого клиента через ШЛЮЗ, установленный по умолчанию? То есть мы можем на шлюзе настроить соответствующим образом фаервол и рулить трафиком как нам нужно. Захотели - открыли доступ, захотели - закрыли. В общем, схема работает. Но это еще не все. Ведь пока машины не получили доступ в интернет.


Для того, чтобы выпустить виртуальные машины в интернет, был поднят дополнительный шлюз на FreeBSD: "Gateway-Public", на который шлюз "Gateway-Private" и пересылает все запросы от ВМ, адресованные в интернет.


Ну, а теперь попробую еще раз пояснить то, как вся эта кухня работает. Допустим, первый клиент захотел получить RDP доступ до своих ВМ. Что он делает? Он запускает web-браузер, вводит там наше доменное имя, и в ответ в браузере появляется приглашение от OpenVPN сервера на ввод логина и пароля. После успешной аутентификации клиент запускает нужный RDP ярлычок, где уже прописан IP адрес нужной ВМ, и, тем самым, клиент получает доступ к своим машинам. Чтобы клиент получил доступ только к своим ВМ, на фаерволе "Gateway-Private" соответствующим образом настраиваются правила для каждого клиента.


Теперь давайте рассмотрим тот нередкий случай, когда администратору нужно получить доступ к ВМ "vSphere-Client". Системный/виртуальный администратор так же, как и любой другой клиент, должен установить защищенное соединение с OpenVPN сервером и, далее, просто соединиться с нужной виртуальной машиной, используя для этого RDP. Вся логика по разграничению доступа лежит на "Gateway-Private". Именно он ответственен за то, кому и куда можно "ходить".


В заключение, хочу написать о том, как заносится в систему новый клиент. Итак. Допустим, у нас появился четвертый клиент, который заказал одну ВМ. Что я делаю:


  • Создаю на vSwitch1 портгруппу "CLIENT-004-NET" с VLAN ID 4.
  • Создаю новую ВМ с сетевым интерфейсом, входящим в эту портгруппу.
  • На шлюзе "Gateway-Private" создаю новый сетевой интерфейс "vlan4".

Данный сетевой интерфейс можно создать заранее. Если клиентов у вас много, то можно быстренько накатать простенький скрипт.

  • Затем на этом же шлюзе "Gateway-Private" настраиваю соответствующим образом фаервол.

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

  • Ну и, в последнюю очередь, на OpenVPN сервере я создаю нового пользователя. Вот и все.


Новый, четвертый клиент в систему занесен. Ура, товарищи! Осталось только рассказать клиенту, как всем этим хозяйством пользоваться. Благо, это не занимает много времени. На этом у меня все. Надеюсь, что кому-нибудь эта статья окажется полезной и нужной.

Источник: Power Consumption Graphing and Control in vSphere 4.1


Для тех, кто интересуется темой более экономного расходования электроэнергии на серверах, работающих под управлением VMware vSphere, то в блоге www.petri.co.il как раз есть отличная статья, посвященная теме управления питанием в vSphere 4.1 . В этой статье, помимо настройки "Power Management", также рассматривается вопрос о том, как можно осуществлять мониторинг мощности, потребляемой хостом. В статье достаточно много различных скриншотов, поэтому не должно возникнуть каких-либо трудностей с пониманием материала.

vSphere-performance-chart-.png

Источник: Persistent vs. Non-persistent Virtual Desktops


Рекомендую прочитать полную версию статьи, приведенной как источник. Здесь же я приведу только плюсы и минусы от использования Persistent и Non-Persistent Virtual Desktops:


  • Persistent Desktop Pros and Cons:

What’s the benefit of a persistent desktop? What you do from session to session sticks with you. What’s the downside to persistent desktops? Persistent desktops could potentially become an administrative nightmare. The amount of disk space needed to maintain this setting will grow and datacenter storage doesn’t come cheap. Patching and upgrades are now necessary for each persistent image and this can eat up tons of man hours, which usually occur after hours.

  • Non-Persistent Desktop Pros and Cons:

What’s the benefit of non-persistent desktops? Patches and upgrades are more easily applied to a single image in a resource pool of virtual desktops which cuts the man hours required for management. The downside would be having to sync roaming profile changes between multiple sessions. The time it takes to log on will gradually increase with the amount of changes that are applied and updated to each profile.

Deshifrator Hot Shot

vApp startup order and HA?

Posted by Deshifrator Nov 12, 2011

Duncan Epping опубликовал в блоге "VMware vSphere Blog" небольшой пост, в котором ответил на недавно заданный ему вопрос: "Учитывает ли VMware HA порядок запуска виртуальных машин, который выставлен для контейнера vApp?". Duncan ответил весьма коротко: "Нет, не учитывает". И посоветовал выставлять приоритет запуска виртуальных машин непосредственно в настройках кластера. Так что, имейте это в виду.

openvpn.jpg

Возвращаясь к теме OpenVPN сервера, хочу привести статьи, которые помогут вам лучше понять, как пользоваться этим продуктом:



Это лишь часть документации. Полный список документов вы можете получить на официальном сайте продукта в разделе HOW-TO. Так же не забывайте про ранее написанную мною статью на тему настройки "OpenVPN Access Server", ну, и про познавательные видеоролики, представленные все на том же оф. сайте проекта.

Источник: Unable to remove an inaccessible NFS datastore with Storage I/O control enabled


Чтобы удалить неактивное NFS хранилище, для которого включен SIOC, вам нужно подключиться по SSH к хосту ESXi, и в терминале выполнить ряд действий. Первым делом получаем список NFS хранилищ на хосте VMware ESXi:

# esxcli storage nfs list

Результат выполнения команды:

nfs-list1.PNG

После этого удаляем NFS том, выполняя для этого следующую команду:

# esxcli storage nfs remove -v vol_nfs-2

Вот и все. Неактивный NFS датастор должен был удалиться.

Источник: VMware View VDI Flash Calculator v2.5 Released


Обновился View VDI Calculator. Список того, что было сделано в новой 2.5 версии:


  • Added higher degree of control over read/write ratios
  • Added segmentation between number of sockets and cores per socket
  • Added storage overhead support for swap on host
  • Fixed video swap issue with earlier versions of vCenter and ESXi
  • Complete overhaul of the IO calculation
    • Calculation of IO per disk type (replica, clones and persistent)
    • Calculation of IO for of simultaneous boot VMs


Рекомендую к ознакомлению статью: "A Review of VMware View 5.0 Limits and Maximums", которая, возможно, пригодится вам при выполнении расчетов.

Источник: PowerPath VE Versus Round Robin on VMAX – Round 3 (TKO)


Появился очередной тест производительности "PowerPath VE vs Round Robin (RR)" от автора блога www.virtualinsanity.com. Кто не знаком с результатами предыдущих тестов, рекомендую с ними ознакомиться: Тест 1, Тест 2.

Статьи на эту же тему, но только в русскоязычных блогах, вы можете прочитать здесь: Multipathing Часть 1, Multipathing Часть 2 и Параметр IOOperation Limit.

На этот раз автор подошел к этому тесту более обстоятельно. Было задействовано 3 хоста ESXi 5.0, на которых было создано по три (3) Win2008R2 виртуальные машины. В каждой виртуальной машине был запущен IOMeter со своим профилем нагрузки. Вот сводная табличка, где показано, какой профиль IOmeter и на какой ВМ использовался:

testvmsetup.png

Затем было проведено три теста. Первый тест, "Round Robin IOPS=1", дал нам 20,673 IOps. При этом среднее время задержки на чтении (read latency) составляет 7.69 ms, а среднее время задержки на запись (write latency) - 7.5 ms.


Тест "Round Robin IOPS=1000" дал просто ужасные показатели производительности. Общее количество операций ввода-вывода в секунду по сравнению с "Round Robin IOPS=1" меньше на 9000 IOps, а задержка на запись и чтение увеличилась, в среднем, на 40 процентов. Поскольку основная часть профилей IOmeter - это последовательный доступ, то такая большая разница между результатами двух тестов имеет место быть. Ну, а теперь, вернемся к результатам тестов.


Тест с использованием на хостах "PowerPath VE" показывает, что общее количество IOps по сравнению с тестом "Round Robin IOPS=1" увеличилось на 6% и, при этом, на 15% уменьшилось время задержки на чтение (read latency).


Сводная таблица по результатам всех тестов:

results.png

Использовать PowerPath VE или нет - дело каждого. Но автор этого теста для своей VMware среды предпочел использовать PowerPath VE.

Автор блога vTexan.com опубликовал очередную статью касательно VMware View 5 (предыдущие статьи этого автора на тему настройки VMware View вы можете найти здесь). Статья под названием: "Setting up the View 5 Event Database" повествует нам о том, как правильно создать и настроить в админ-панели базу данных для событий (Event Database), генерируемых VMware View 5.

На стареньком сервере Dell PowerEdge 1950 решил я поставить ESXi 5. В этом сервере только два жестких диска, поэтому я собрал зеркало и, затем, накатил гипервизор. ESXi встал без каких-либо проблем. После первоначальной настройки я запустил vSphere Client и соединился напрямую с этим сервером. После удачного соединения полез я в настройки хранилищ. И что-то дернуло меня переименовать одно единственное хранилище datastore1 на что-то более внятное и логичное. Но вместо того, чтобы взять и просто переименовать, я взял и удалил его.


По всей видимости, эта привычка у меня осталась еще от VMware ESXi 4.x, когда нужно было заново пересоздавать датасторы с другим, нужным размером блока, чтобы иметь возможность создавать vHDD размером до 2 Tb. Ну, так вот. Удалить-то я удалил, а вот создать заново не получилось. Выдает вот такую ошибку:

error1.jpg

для наглядности вот полное окно с ошибкой:

error2.jpg

В это время в лог-файле /var/log/hostd.log появляются вот такие записи:

error5.JPG

Подсоединившись к хосту ESXi через SSH и набрав команду:

# df -h

я убедился, что датастора VMFS-5 на этом диске нет:

df.jpg

Тыкание в GUI ни к чему не привело. На том же диске, где до недавнего времени находился удаленный VMFS-5 том, заново его создать не получается. Судя по сообщению об ошибке:

Host cannot perform a partition table conversion

в vSphere 5, если ты удалил том VMFS-5 с диска, на котором располагаются и другие системные разделы ESXi 5, то заново создать датастор на том же диске у вас не получится. Вот так вот.


Кстати говоря, про такое поведение есть статья в VMware KB, на которую я наткнулся уже после написания этого текста. Так вот, в данной статье в качестве решения этой проблемы (когда вам очень сильно нужно локальное хранилище) рекомендуют просто переустановить ESXi на сервере.

Источник: Video - vShield 5 Install and Deploy


Новое видео, сделанное Eric Sloof (vShield 5 Install and Deploy) на тему развертывания продуктов из семейства "vShield 5" в виртуальной инфраструктуре, и статья (vSphere Security), опубликованная в блоге Михаила Михеева (www.vm4.ru), помогут вам более глубоко разобраться в том, как можно защитить виртуальную инфраструктуру от внешних и внутренних угроз.

Для получения более глубоких знаний в области защиты виртуальной инфраструктуры, построенной на базе VMware vSphere, очень рекомендую заглядывать на русскоязычный сайт: http://www.virtualizationsecuritygroup.ru (Virtualization Security Group Russia).


Там вы уж наверняка найдете какие-нибудь интересные материалы на данную тематику.

Источник: Non-Persistent Disks with VMs?


Если вы в своей тестовой или производственной (что очень не рекомендуется) среде используете nonpersistent-диски, то знайте, что Storage vMotion для данных дисков вы сделать не сможете.

Почему НЕ НУЖНО использовать nonpersistent-диски вы можете прочитать здесь.

Источник: Support for Storage DRS in an HA enabled cluster?


В документе "vSphere 5.0 Availability Guide" есть вот такой параграф:

vSphere HA and Storage vMotion Interoperability


In clusters where Storage vMotion is used extensively or where Storage DRS is enabled, VMware recommends that you do not deploy vSphere HA. vSphere HA might respond to a host failure by restarting a virtual machine on a host with an ESXi version different from the one on which the virtual machine was running before the failure. A problem can occur if, at the time of failure, the virtual machine was involved in a Storage vMotion action on an ESXi 5.0 host, and vSphere HA restarts the virtual machine on a host with a version prior to ESXi 5.0. While the virtual machine might power on, any subsequent attempts at snapshot operations could corrupt the vdisk state and leave the virtual machine unusable.

Я не буду переводить этот параграф, так как это уже сделано в статье, опубликованной в блоге www.vmgu.ru. В своём же посте я хочу лишь сказать о том, что прежде, чем что-либо делать со своей виртуальной инфраструктурой, прочитайте соответствующие документы по наилучшим практикам (best practices). Ну, а данный случай, учит нас тому, что не нужно сразу же начинать использовать различные новые возможности до тех пор, пока все компоненты вашей виртуальной инфраструктуры не будут полностью обновлены.

vSphere HA 5 и Storage DRS полностью совместимы и могут использоваться совместно.

Источник: This host have no mangement network redundancy – how to disable this message


Если в своей домашней лаборатории вы не можете обеспечить избыточность management network, и вам порядком поднадоело предупреждение в vCentre вида:

warn.jpg

то вы можете его подавить, добавив в "Advanced Options" кластера HA следующий параметр:

das.ignoreRedundantNetWarning = true

После внесения изменений переконфигурируйте vSphere HA кластер.

Источник: Video - Troubleshooting vCenter 5 start-up problems


Eric Sloof подготовил и опубликовал в своём блоге хорошее видео, на котором наглядно показано, какие действия нужно предпринять, если у вас не стартует служба вЦентра. Видео к просмотру обязательно! Возможно, как и я, узнаете для себя что-то новое.

Изначально тему про возобновление "VMTN Subscription" поднял Mike Laverick. Данную идею уже поддержало много именитых блогеров:



VMTN подписка позволяет за небольшую сумму получить полноценные лицензии к ряду продуктов VMware на целый год. Лично я, чтобы не мучиться с 60-ти дневной лицензией, приобрел бы такую подписку. Ведь это очень удобно для домашней лаборатории, которую не нужно будет каждые 60 дней заново переставлять.


В общем, я обеими руками за возобновление "VMTN Subscription".

В поддержку этой идеи вы можете оставить своё сообщение вот на этом форуме, просто написав +1. Голос каждого очень важен!

Коллеги, не проходите мимо! Оставьте свой +1. Поддержите инициативу.

Источник: Monitor ESX 4.x to ESXi 5.0 migration process


Если вам, сугубо с академической точки зрения, интересно, что же происходит во время миграции с ESX 4.x на VMware ESXi 5.0, то вам нужно нажать сочетание клавиш "Alt-F1" (во время процесса миграции) для того, чтобы получить доступ к консоли сервера. И, уже находясь непосредственно в консоли, вы можете мониторить процесс миграции (monitor migration process) путем просмотра в каталоге "/var/log" соответствующих лог-файлов. Для получения дополнительной информации, обратитесь к первоисточнику.

Источник: Straighten up with a new UBER tool : Presenting UBERAlign


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



Выровнять диски виртуальной машины - достаточно непростое занятие. Например, это можно сделать с помощью различных платных инструментов, таких как "vOptimizer Pro". До недавнего времени не было хорошего бесплатного и простого в использовании инструмента, призванного помочь виртуальным администраторам выровнять (alignment) диски своих виртуальных машин, которые работают под управлением следующих операционных систем: Windows (2000, XP, 2003, 2008 (NTFS)) или Linux (EXT2/EXT3/EXT4).

Диски операционных систем Windows 2008 и Windows 7 не нуждаются в выравнивании. Однако, если вы просто обновили ОС Windows 2003 до Windows 2008, то выравнивание дисков все равно нужно будет сделать.

И вот Nicholas Weaver презентовал нам UBERAlign:

UBERAlign.jpg

UBERAlign состоит из двух компонентов:


  • Console - это центральная консоль, из-под которой вы непосредственно будете выравнивать диски ваших виртуальных машин.

  • vAligner - представляет собой Virtual Appliance, который, в общем-то, и занимается основной работой по выравниванию дисков виртуальных машин.


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


Лично мне, судя по видеороликам, UBERAlign кажется весьма неплохим инструментом, который следует взять на вооружение.

Источник: Double-Diagram: vCloud Director Management Pod in the Public & Private Clouds!


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

DoubleDiagr1.gif

DoubleDiagr2.gif

Источник: Triad VMUG vSphere Security Presentation


Jason Nash опубликовал в своем блоге (www.jasonnash.com) презентацию, посвященную вопросу повышения безопасности виртуальной инфраструктуры, построенной на основе VMware vSphere. Может, кому пригодится. Как-никак 69 слайдов полезной информации.

presa1.jpg

Источник: VMware ESXi 5.0 Patch ESXi500-201111401-BG


Если на хосте ESXi 5.0 для подключения хранилищ у вас используется программный iSCSI адаптер, то вы, наверное, уже столкнулись с проблемой, когда хост VMware ESXi 5.0 очень долго стартует после перезагрузки. Подробности читайте здесь:


  1. Долго грузится VMware ESXi при подключенных iSCSI-хранилищах?
  2. ESXi 5.x boot delays when configured for Software iSCSI


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

This patch updates the esx-baseVIB to resolve an issue where an ESXi 5.0 host might take a long time to boot if a software iSCSI adapter is enabled on the host and a large number of iSCSI targets are present. When the ESXi host boots, it tries to discover the iSCSI targets. If the iSCSI targets are not reachable, the retry logic used for discovering iSCSI targets causes delay and increases the time taken for the ESXi host to boot.

Важные примечания к этому обновлению см. в разделе "Resolution" соответствующей статьи в KB.

resolution.jpg

Данная статья является очень кратким конспектом соответствующ(их/ей) глав(ы) книги:

" vSphere 5 Clustering Technical Deepdive (Authors: Duncan Epping, Frank Denneman) ".


Купить eBook (Kindle) версию книги (~12$) вы можете на сайте Амазона (amazon.com)

Это заключительная часть статьи: "vSphere 5: High Availability - Основные Понятия"

Напомню, что первую часть этой статьи вы можете прочитать, пройдя по этой ссылке.

Heartbeating

На данный момент существуют только два способа обмена "heartbeat" сигналами в HA кластере. Первый способ - через сеть управления (management network), ну и второй - с использованием хранилищ. Немного ниже мы достаточно кратко рассмотрим эти два способа обмена "heartbeat" сигналами в VMware HA кластере.


Network Heartbeating

Этот механизм является самым простым для определения того, "жив" ли хост или нет. Мастер и slave-хосты каждую секунду обмениваются (master <-> slave) между собой "heartbeat" сигналами. И, в зависимости от того, получен ли "heartbeat" сигнал, предпринимается то или иное действие на хосте VMware ESXi.


Datastore Heartbeating

Это новый механизм, появившийся в VMware vSphere 5.0. Данный механизм позволяет исключить ситуацию, когда сеть управления на хосте недоступна, и из-за этого виртуальные машины, которые могут вполне себе нормально работать, будут перезапущены.

Механизм "Datastore Heartbeating" используется только тогда, когда хост не доступен через сеть управления (management network).

Итак. Допустим, произошла изоляция хоста. Как мастер узнает о том, что хост изолирован? Да все достаточно просто. Мастер будет проверять "poweron"-файл на хранилище, который slave-агент должен обновить, занеся в его первую строку значение "1".

Для получения дополнительной информации о "poweron"-файле вы можете обратиться к ранее опубликованной первой части этой статьи.

После того, как мастер поймет, что хост изолирован, его дальнейшие действия будут зависеть от значения параметра "isolation response", заданного при настройке кластера HA. Если в "isolation response" указано "Leave powered on", то slave-хост и мастер ничего предпринимать не будут. Виртуальные машины так и будут продолжать работать на изолированном хосте. Если в "isolation response" указано "Power off" или "Shut down", то изолированный хост потушит свои ВМ, а мастер, после того как убедится в том, что виртуальные машины выключены (проверив "poweron"-файл), инициирует процесс перезапуска ВМ на других хостах кластера HA.


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

host-<number>-hb

d-hb.jpg

который хост должен держать постоянно открытым. На самом деле, хосту необязательно держать постоянно открытым именно этот файл. Если хостом будет открыт любой другой файл, то мастер поймет, что хост жив. Дело все в том, что для отслеживания того, что хост жив, используются стандартные механизмы ФС VMFS. В частности, используется так называемый "heartbeat region", который постоянно обновляется, пока у хоста есть хотя бы один открытый файл на томе VMFS.

Если файл "host-<number>-hb" находится на NFS хранилище, то хост должен его обновлять каждые пять секунд. Иначе мастер поймет, что хост вышел из строя.

По умолчанию HA в качестве "heartbeat datastores" выбирает только 2 хранилища. Если вы считаете, что этого мало, вы можете увеличить это значение при помощи этого параметра: "das.heartbeatDsPerHost".


Isolated versus Partitioned

Если хост изолирован, то он:


  • не получает "heartbeat" сигналы от мастера
  • не получает любой трафик по выбору мастера (election traffic)
  • не пингует проверочный IP адрес (isolation address)


Если хост разделен (partitioned), то он:


  • не получает "heartbeat" сигналы от мастера
  • получает трафик по выбору мастера

На какое-то время в разделенной сети будет выбран новый мастер, и vCenter'у будет об этом сообщено.

scheme.PNG

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


Может случиться так, что мастер в разделенной сети может взять под свою ответственность виртуальные машины, расположенные на хостах ESXi в другой разделенной сети. В этом нет ничего страшного. Если с ВМ в другой разделенной сети что-нибудь случится, мастер об этом будет уведомлен через "datastore communication" механизм. В случае, если хост (на котором работает защищенная мастером ВМ) в разделенной сети выйдет из строя, то мастер сразу же узнает об этом через "datastore heartbeat" механизм.

Если в кластере HA, например, случилось что-то со slave-хостом, то оставшиеся узлы кластера не перезапустят у себя виртуальные машины до тех пор, пока мастер не убедится в том, что хост вышел из строя или стал изолированным, и сработало действие, заданное в "isolation response".


Существует еще один очень интересный момент. Будучи изолированным, хост, перед тем, как что-либо делать со своими виртуальными машинами, проверит наличие блокировки на файле "protectedlist". Если хост увидит, что блокировки на этом файле нет, то, вне зависимости от того, что за действие установлено в "isolation response", с виртуальными машинами не будет ничего сделано. То есть они будут продолжать работать. Зачем это сделано? Дело в том, что если нет блокировки на файле "protectedlist", то это означает, что на данный момент мастер-хоста не существует, а это, в свою очередь, означает что некому будет перезапустить виртуальные машины.


Virtual Machine Protection

  • Защита виртуальной машины:

vm-protect.jpg

  • Снятие защиты с виртуальной машины:

vm-unprotect.jpg

Источник: Methods of upgrading to ESXi 5.0


Увидел достаточно полезную статью в VMware KB, в которой расписано, какими способами можно воспользоваться для осуществления перехода на VMware ESXi 5.0. Также в этой статье есть несколько видеороликов,



которые могут помочь вам при обновлении до ESXi 5.0. Кроме того, в статье содержится много другой полезной и нужной информации, например, там есть небольшая сводная таблица по поддерживаемым методам обновления до ESXi 5.0:


Upgrade methodsUpgrade from ESX/ESXi 4.x to ESXi 5.x
vSphere Update ManagerYes
Interactive upgrade from CD, DVD, or USB driveYes
Scripted upgradeYes
vSphere Auto DeployNo
esxcliNo


Если вы только подумываете о переходе на пятую версию VMware vSphere, то данный документ: "Methods of upgrading to ESXi 5.0" придется вам как нельзя кстати.

Источник: All host failed, how does HA respond?


Итак. Давайте рассмотрим сценарий, когда все хосты в HA кластере выключились из-за отсутствия электричества:


  1. Прекращение подачи электроэнергии. Все хосты выключились.
  2. Электричество появляется, и хосты начинают включаться.
  3. Начинается процесс выбора мастера. По окончании процесса будет выбран новый мастер.
  4. Мастер считывает файл "protectedlist".
  5. Мастер инициирует перезапуск виртуальных машин, которые находятся под защитой HA и, на данный момент, еще не запущены.


Стоить отметить одну вещь: если виртуальная машина была выключена нормально, например, системный администратор потушил её через vCenter, то для неё не будет инициирован процесс перезапуска. А вот если виртуальная машина завершила свою работу, когда хост был изолирован или в случае выхода из строя хоста, то VMware HA для этой ВМ, конечно же, инициирует процесс перезапуска.

Deshifrator Hot Shot

VMware ESXi Firewall

Posted by Deshifrator Nov 1, 2011

Совсем крохотный пост-напоминание. Я думаю, вполне пригодится для тех, кто только начинает разбираться с межсетевым экраном, появившимся в VMware vSphere 5.0. До выхода 5-ой вСферы, межсетевой экран (firewall) был только в гипервизоре VMware ESX, и методы взаимодействия с ним были немного другие, чем есть сейчас в ESXi 5.0.


Автор блога www.virtu-al.net опубликовал весьма интересный пост, в котором приводит список командлетов для работы с распределенным свичем (Distributed Switch) в VMware vSphere.

Чтобы командлеты заработали, должны выполняться следующие требования:


  • Windows required XP or Windows Server 2003 or 2008 is required  (Windows 7 and Vista are not supported currently)
  • VMware PowerCLI 4.1.1 or later is needed

    Также в этом посте показаны примеры использования этих командлетов (для новичков самое то):

    vds.jpg