среда, 29 февраля 2012 г.

Кастомизируем образ ESXi и скриптуем инсталлляцию ESXi от EMC Proven

Канал EMCProvenSolutions радует новым видео.

VMware vSphere 5 - Using Image Builder To Create Custom ISO



Scripted ESXi Installation


Дед vAdmin

Перед Новым годом, как вы помните, я решил побыть Дедом vAdmin'ом и подарить немного подарков вместе с Iomega.

Iomega® ScreenPlay® MX получил Идрис Кубатаев.


Wireless iConnect Station отправилась в Киев к Кириллу Сухоставскому.

Поздравляем!

пятница, 24 февраля 2012 г.

В чем разница между CPU Ready и %RDY?

Самым важным ресурсом для виртуальной машины является ЦПУ. И если администратор сталкивается с падением производительности у какой-либо ВМ, то для тонкого траблшутинга производительности очень удобно пользоваться командной утилитой esxtop, которая все значения показывает в процентном соотношении.

В vSphere Client же, в свою очередь, показывает значения в миллисекундах. И если из документации известно, что значение %RDY не должно превышать 10, то соответствующее значение CPU Ready очень легко посчитать.

Итак, и esxtop и vClient собирают данные в реальном времени, и обновляют их каждые 20 секунд  - 20 000 миллисекунд. Таким образом, если CPU Ready за эти 20 000 мс составил 500 мс, то мы делим 500 на 20 000, и получаем значение %RDY около 3, что является прекрасным показателем. Если же CPU Ready составил 7 500, то деление 7 500 на 20 000 даст около 37.5% RDY, что ужасно для однопроцессорной виртуальной машины.

Здесь важно отметить «для однопроцессорной виртуальной машины», так как значение %RDY является суммой значений для всех ядер ВМ. То есть, если в esxtop у 4-ёх ядерной ВМ значение %RDY 20 – то для каждого отдельного vCPU оно составляет в среднем 5.

vClient же, в отличие от esxtop, позволяет просматривать значение CPU Ready как в целом, так и для каждого отдельного вЦПУ.

Оригинал: Jason Boche

четверг, 23 февраля 2012 г.

IBM выпустила distributed virtual switch для vSphere 5

Буквально на днях компания объявила о выпуске собственного распределённого виртуального свитча для vSphere 5 под названием IBM System Networking Distributed Virtual Switch 5000V конкурирующего с аналогом от Cisco – Nexus 1000V.

IBM DVS 5000 заменяет собой встроенный в vSphere 5 виртуальный распределённый свитч и эмулирует аналог физического свитча от IBM.

Основными преимуществами IBM DVS 5000V являются поддержка большого количества протоколов для управления (Telnet, SSH, SNMP, TACACS+, RADIUS, и локальная командная строка), широкий набор функций (L2-L4 ACL, статическая и динамическая агрегация каналов, PVLAN, QoS и EVB) и возможность отладки с помощью протоколов SPAN, ERSPAN, sFlow, Syslog, а также мониторинг статистики ВМ.

Подробности на официальном сайте IBM.

Работа с multicast трафиком в vSphere 5

 С выходом vSphere 5 VMware также выпустила отличный документ Multicast Performance on vSphere 5.0, рассказывающий об увеличении производительности обработки multicast трафика, но при этом никак не раскрывая техническую сторону вопроса.

Когда виртуальная машина настроена на получение трафика из какой-либо multicast группы она публикует соответствующий MAC адрес через свой сетевой интерфейс, и отправляет пакет на запрашивающий добавление её в группу. Виртуальный свитч (как vSS, так и vDS) никак не изменяя пакет отправляет его на физический свитч, который на основе, и благодаря, настройкам IGMP snooping`а на уровне физического хоста определяет через какой порт отправлять какую multicast группу, а vSwitch, в свою очередь, добавляет этот MAC адрес в свою таблицу переадресации.

Когда виртуальный свитч получает multicast трафик, то он переадресовывает его виртуальным машинам, входящим в эту multicast группу. Переадресация работает, как и в случае с unicast трафиком - на основе MAC адреса получателя. Так как vSwitch отслеживает,какие именно ВМ входят в какие именно multicast группы, то трафик переадресовывается не всем ВМ и всем интерфейсам, а только необходимым.

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

Если виртуальная машина переезжает на другой хост с помощью vMotion, то её настройки переедут вместе с ней. Целевой хост обновит свои таблицы переадресации согласно настройкам интерфейса виртуальной машины. Чтобы избежать возможной потери трафика из-за vMotion, виртуальный свитч целевого хоста отправляет IGMP запрос в ВМ, используя её unicast MAC адрес, чтобы физический свитч сразу получил информацию о новом местоположении ВМ. Это позволяет избежать потери трафика в ожидании следующего IGMP запроса от IGMP маршрутизатора.

Обычно IGMP маршрутизатором является какой-либо роутер в сети, и требуется для работы IGMP snooping на физических свитчах, которые, в свою очередь, используют эту информацию в своих таблицах переадресации IGMP трафика, и без которой не могут обеспечить работу IGMP snooping. Маршрутизатор отправляет запрос на адрес 224.0.0.1, общую multicast группу, а все ВМ в ответ отправляют информацию о том в какие-именно multicast группы они входят. Физический свитч, получая эту информацию, обновляет свои таблицы переадресации, и начинает пересылку трафика.
NIC Teaming физических интерфейсов также поддерживается, но механизм его работы зависит от используемого способа балансировки нагрузки.

Если активны все сетевые интерфейсы, а механизм балансировки нагрузки virtual source port ID или MAC hash based, то IGMP запрос на добавление будет выслан настроенным интерфейсом, и физический свитч обновит свою таблицу переадресации, и будет отсылать multicast трафик через соответствующий порт.

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

В случае использования IP hash, физический свитч видит все физические интерфейсы как один интерфейс, и не сможет отправлять multicast трафик на разные интерфейсы, так как все физические интерфейсы являются членами всех групп. Физический интерфейс, используемый для передачи трафика в vSwitch, будет выбран согласно правилам балансировки нагрузки физического свитча.

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

Оригинал: Kamau Wanguhu