vSphere Security

Давно собирался написать этот пост, но что-то руки не доходили. Вот, взял себя за шкирку и пишу :)
Правда, по хорошему его надо писать слегка по другому - не только в теории (как я это делаю сейчас), но и практики добавить - но время, время... Напишу как есть, а будет время попрактикуюсь и еще напишу.

Итак - вСфера и безопасность. Благодаря хозяйке virtualizationsecuritygroup.ru я узнал, что

• существует довольно много решений, содержащих в своем описании "VMware vSphere" и "Security" одновременно.
• они в чем-то сильно похожи, но и нюансов хватает.
• ну и узнал немного подробностей про некоторые из них.

Введение

Для начала частично процитирую один из своих старых постов.

Есть вот такая картинка:

Семейство продуктов vShield

Это - продукты и функции VMware vSphere, имеющие отношение к безопасности.

Интерфейс vShield Manager, управлялки ко всему остальному

Во-первых - есть продукт vShield Zones. Это - межсетевой экран, позволяющий контролировать обмен трафиком, притом даже тем трафиком, что остается внутри ESX(i), когда им обмениваются две ВМ на одном вКоммутаторе. Еще он хорош тем, что правила создаются и контролируются в одном месте (появляется отдельная страница прямо в интерфейсе vSphere Client, см. картинку) - не требуется отдельно конфигурить правила в каждой гостевой ОС, если использовать внутри-гостевые межсетевые экраны.

Его плюс - он доступен нахаляву тем, у кого куплена vSphere Advanced и более высокие лицензии.
Его минус - это только брандмауэр.

Впрочем, его можно прокачать до vShield App. Этот апгрейд весьма заметно расширяет функционал - теперь контроль трафика возможен не только по правилам отслеживающим Source IP address, Destination IP address, Source Port, Destination port, protocol, но и по многим другим параметрам, а так же добавляются многие организационно полезные вещи. Список тут.

Подробнее про эти продукты можно на русском прочесть тут - Различия VMware vShield Zones и vShield App 4.1 update 1.

vShield Endpoint

Однако по прежнему это межсетевой экран.

И вот тут на сцену выходит vShield Endpoint.

Это - платная дырка в гостя. Благодаря этому интерфейсу, специально обученная виртуальная машина может:

• перехватывать и контролировать трафик прочих ВМ на этом сервере
• получать доступ к ОЗУ и к диску прочих виртуальных машин

Благодаря этому в упомянутой "специально обученной ВМ" могут работать антивирус\антималваре - и защищать ВМ на этом ESX(i). (Предполагается, что такая ВМ разворачивается на каждом ESX(i), это же относится к vShield Zones).

Кроме антивируса, по такой схеме заработают системы обнаружения и предотвращения вторжений, IDS\IPS, межсетевые экраны.

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

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

И вот про этих партнеров я, преимущественно, и хочу немного рассказать.

Продукты третьих фирм


Дисклаймер:
Приведенная здесь информация может изобиловать неточностями и неуказанными нюансами. Автор не является специалистом ни в области безопасности, ни в каком-либо из описываемых продуктов. Информация предоставляется в общеобразовательных целях, целевой аудиторией являются владельцы vSphere, которым область сторонних продуктов обеспечения безопасности vSphere незнакома.

Cisco

Дает нам свой виртуальный коммутатор - Nexus 1000V. Определенный функционал безопасности в нем можно найти.

Еще - Virtual Security Gateway. Это Virtual Appliance, с функциями, я так понимаю, контроля трафика. Устанавливается в дополнение к Nexus 1000V.

Презентация:

Cisco VSG_Конкурс продуктов портала VirtualizationSecurityGroup.Ru  

View more presentations from VirtSGR

McAfee

Продукт McAfee Move(Management for Optimized Virtual Environments).

Вариантов два - или мы берем просто антивирусы, и их расставляем в ВМ - тогда центральная консоль управления дает возможность ограничить одновременные запуски сканирование на хост\LUN, для предотвращения шторма .

Или добавляем его на каждый хост Virtual Appliance (я не совсем разобрался, это подготовленный именно Appliance, или просто дистрибутив который сам устанавливаешь в самостоятельнуо подготовленную ВМ).
Затем в каждого гостя ставим "тонокого" агента. Такой агент, вроде как, умеет данные для антивирусного сканирования отправлять на Appliance - т.е. на каждую ВМ нагрузка меньше, и антивирус-шторма можно не так опасаться.

Однако - VMware Endpoint API не используется, связь между агентами в ВМ и выделенной ВМ со сканером просто по IP.
Тем не менее, обещают на порядок меньший объем памяти и нагрузку на процессор для каждой ВМ с таким "тонким" агентом.


Презентация:

McAfee MOVE_Конкурс продуктов портала VirtualizationSecurityGroup.Ru

View more presentations from VirtSGR

Symantec

Symantec Endpoint Protection.

Сегодняшняя версия не интегрируется с API от VMware. В каждую ВМ устанавливаем привычного агента, с функцией антивируса. Под виртуализацию заявлена кое-какая оптимизация - исключение из сканирования файлов из мастер-образов, автоматическое обнаружение клиентов-ВМ и назначение им политик, которые могут отличаться от политик для физических клиентов. Обещают защиту от антивирус-штормов. Позволяют одинаковый файл проверять один раз на хост, не для каждой ВМ где он был найден.

Про функционал кроме антивируса я не понял. Функции брандмауэра и IPS упоминаются, но понятной инфы я не нашел.

Презентация (на редкость невычитанная, я даже удивился низкому качеству вроде бы публичного источника информации. Смысл, к сожалению, без спикера тоже не очень легко уловить):

Symantec Endpoint Protection_Конкурс продуктов портала VirtualizationSecurityGroup.Ru

View more presentations from VirtSGR

Trend Micro

Trend Micro Deep Security.

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

Если на каждый сервер добавить Virtual Appliance Deep Security, а в ВМ активировать vShield Endpoint (сегодня это требует установки маленького компонента в каждую ВМ, потом обещают реализовать эти вещи прямо в VMware tools), то на всех этих ВМ мы получим функции:

• антивируса
• межсетевого экрана
• IDS\IPS

Самым прямым конкурентом для Trend Micro выглядят антивирусные вендоры Symantec и McAfee. Я присутствовал на презентации Trend Micro, но отсутствовал на презентациях Symantec и McAfee, поэтому информации для сравнения у меня мало.

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

Опять же дисклаймер - я понятия не имею, насколько качественно и полно реализован функционал того же антивируса или там IPS. А вот с точки зрения работы именно в контексте vSphere Deep Security мне понравился .

Что еще обратило на себя внимание с презентации по этому продукту:

• в конце года обещают версию 8 под vSphere 5
• управление Deep Security через веб-интерфейс (интеграции с vCenter нет)
• если внутри ВМ есть агент, а на сервере - Appliance, то антивирус делается последним. а все остальное - агентом. Сегодня агент не умеет антивирус, зато умеет контроль событий (с файлами, папками, реестром) в госте - чего не умеет VA.
• чтобы использовать Deep Security в варианте с VA, потребуется купить его самого, и еще лицензии на VMware Endpoint (впрочем этот пункт по идее должен быть одинаков для всех продуктов, которые использую эти API)

Презентация (очень информативная, рекомендую к ознакомлению):

Deep Security_Конкурс продуктов портала VirtualizationSecurityGroup.Ru

View more presentations from VirtSGR

Кстати, только для продукта Trend Micro нашел русскоязычную инструкцию по развертыванию стенда - Тестовая лаборатория. Как установить Trend Micro Deep Security?

HP

HP Tipping Point. Это vController, Virtual Appliance, предлагающий функции IDS\IPS. Притом, сама логика контроля трафика в этом VA не реализована - он лишь перехватывает трафик ВМ и переправляет его на физический IPS от HP.

Управлялкой к этим VA является продукт VMC, это OEM от Reflex.

Презентация:

TippingPoint Virtual Controller +Virtual Firewall_Конкурс продуктов портала VirtualizationSecurityGroup.Ru

View more presentations from VirtSGR

IBM

IBM Virtual server protection for VMware.

Virtual  Appliance, работает через API от VMware.

Предоставляет все основные функции:

• Брандмауэр
• IPS (с виртуальным патчингом)
• Защита от руткитов 

Антивируса нет, по крайней мере в текущей версии.

Презентация:

Proventia Virtual Server Protection for VMware_Конкурс VirtualizationSecurityGroup.Ru

View more presentations from VirtSGR

Код Безопасности

vGate.
Продукт с немного другой спецификой, чем упомянутые ранее. vGate встает "в разрез" между администраторами и vCenter, и позволяет более правильно закрутить гайки прав и возможностей. Кроме того, позволяет обеспечить контроль целостности конфигурации ВМ, их доверенную загрузку. Обеспечивает контроль целостности и доверенную загрузку хостов. Регистрирует события информационной безопасности.

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

Презентация:

vGate R2_Конкурс продуктов портала VirtualizationSecurityGroup.Ru

View more presentations from VirtSGR

ЗАО "ОКБ САПР"

Аккорд-В. Программно-аппаратный комплекс, реализует контроль целостности и доверенную загрузку копонентов vSphere и ВМ, разграничение доступа.

Презентация:

Аккорд-В_Конкурс продуктов портала VirtualizationSecurityGroup.Ru_продукт представлен вне Конкурса

View more presentations from VirtSGR

Выводы

Если интересует антивирус - присмотритесь к Deep Security, при прочих равных, этот продукт вроде как по максимуму использует все то, что VMware позволяет использовать для оптимизации процесса.

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

Продукты от vGate и  ЗАО "ОКБ САПР" реализуют специфические задачи - думать не надо, есть задачи - надо использовать :-)

Кроме того, у некоторых продуктов есть сертификация перед российскими регуляторами, что делает их весьма интересными в контексте соответствия инфраструктуры 152-ФЗ и т.п.

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

vCenter + Oracle 11 g r2

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

Небольшой опыт решения проблем с vCenter на Oracle 11 g r2

http://alexsavva.blogspot.com/2011/06/vcenter-and-oracle-db.html
Надеюсь, это сможет кому нибудь помочь.

Первая рекоменлация - цитата из документа. Просто это не performance optimization, а must have - иначе уже от 20 виртуалок все начинает тормозить и oracle.exe постоянно кушает 100% от одного CPU.
Второй пункт - через полгода перестал стартовать vCenter service, причем в логах тишина по этому поводу. Видимо не обрабатывается ситуация когда password expired. Эта проблема специфична именно для 11 версии Oracle - там измениласть default policy. Пришлось править руками и в VCREP и в VUMREP.
Надеюсь что в следующих выпусках vCenter эти действия добавят в инсталляционный скрипт.

thx Alexey V. Savva

boot storm. TPS vs. hardware MMU

В комментариях к посту про page sharing - TPS vs. Large Pages in real life

- подсказали пару интересных ссылок.

Итак, суть вот в чем:
TPS позволяет нам сэкономить память, сэкономить заметно, особенно при отключении Large Pages.

После выключения Large Pages  потребляется на треть ОЗУ меньше 

Нагрузка на процессор вроде как растет, но если у вас (как у большинства) процессоры нагружены на 40 и менее процентов, то пофиг до небольшого роста.

Однако возникает опасения бут-шторма.
Так вот, по ссылкам из комментариев приводят данные тестирования ситуации бут-шторма.


Large Pages, Zero Pages, TPS and Boot-Storm in vSphere 4.x
Large Pages, Zero Pages, TPS and Boot-Storm Part II


Вводная:

Сервер с 32 ГБ памяти. Притом серверов два - старый и новый, с поддержкой аппаратной виртуализации памяти и без.
Типовая ВМ - Windows 2003 (а потом Windows 2008) с 4 ГБ памяти.

Что происходит при старте - Windows записывает нолик в каждую доступную страницу памяти, вроде как чтобы определить сколько памяти ей доступно.

Одновременно включалось 12 таких ВМ.

Вот он boot storm - гости одновременно хотят 48 гигабайт памяти, из 32 имеющихся.

Что происходит на сервере постарее, без аппаратной поддержки виртуализации памяти:

Как видно, как только произошел overcomitment а TPS не смог помочь его избежать - начали применяться механизмы вытеснения гостя из оперативной памяти (balloon\memory compression\vmkernel swap). Конкретно тут, почему-то, использовался своп гипервизора, а не balloon.

UPD. swap вырос аж до 3 мегабайт, видимо в самом начале, когда balloon-драйвер еще не загрузился. Потом не снижается с этих 3 мегабайт так как не было запросов к этой памяти.

Однако - и это узкое место данного теста - большая часть памяти занята не значимыми данными, а только нулями (на это указывает параметр acvtive memory). И раздутый swap оказывал влияние только(или в большей степени) на ненужные гостю страницы с нулями, т.е. провалов в производительности не было. Это-то хорошо, но непонятно как относится к реальной жизни.

Как видно из графика, ситуация стабилизировалась в течении 5-10 минут с момента старта.
А в течении 20 минут потребление памяти опустилось ниже 10 ГБ - за счет работы  TPS.

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

Тут все просто офигенно - все свопы по нулям, память выделенная(consumed) и_не_поднималась(!) выше отметки в 10 ГБ.

Довольно важный вывод - на процессорах с аппаратным MMU ESX(i) не выделяет реальную память под нолики, просто "засчитывая" их гостю.

Это очень здорово, потому что если при бут-шторме не все гости будут потреблять сразу всю свою память, то даже без влияния TPS оперативка не будет тратиться впустую на обнуленные страницы.

TPS vs. Large Pages in real life

Помните пост Transparent Page Sharing?

Напомню суть: от механизма дедупликации памяти, Transparent Memory Page Sharing можно ожидать больше эффективности, если отключить использование Large Pages, больших страниц памяти.

Тут со мной поделились парой графиков по результатам экспериментов:

Рисунок 1. Первый кластер 

Рисунок 1-а. График загрузки процессоров кластера 1

Обратите внимание на момент, показанный первой стрелкой. Это перед выключением Large Pages, вечер пятницы. До этого порядка 190-200 ГБ ОЗУ было выделено (Granted) для ВМ, и порядка 190 было потреблено(Consumed) на серверах. Затем часть ВМ, видимо обслуживалась, выключалась, перезагружалась, и ESX(i) стал выделять им меньше памяти. А вот затем (двойная стрелка) аппетиты ВМ вернулись на прежний уровень, а вот выделение памяти опустилось с примерно 190 ГБ до примерно 143 ГБ.

Чуть ли не 50 ГБ, 25%, экономии для одного кластера.

Рисунок 2. Второй кластер. 

Здесь объем занятой памяти снизился с примерно 230 ГБ до примерно 160 ГБ.
Экономия 70 ГБ, порядка 30%.

Рисунок 2-а. Нагрузка на процессоры кластера 2

Рисунок 3. Третий кластер. 

Еще порядка трети экономии.

Рисунок 3-а. Нагрузка на процессоры кластера 3.

 (тут, правда, не очень понятен пик на 167%, но вряд ли это TPS)

Я не знаю точных размеров инфраструктуры, но это больше сотни ВМ. Из примерно 500 ГБ памяти мы освободили порядка 150 ГБ. Сто пятьдесят гигабайт оперативки. На халяву :-)

P.S. У нас же тут не маркетинговые сказки, так? Поэтому стоит обсудить вторую сторону медали. Потенциальных проблем по факту таких манипуляция я вижу две:

1) Снижение производительности из за неиспользования больших страниц.

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

Буду рад, если кто подскажет ссылку или поделится опытом.

2) Самый, наверное, веский аргумент тех, кому по долгу службы требуется указывать на недостатки продуктов-конкурентов – ненадежность сэкономленного. Есть вероятность, что ВНЕЗАПНО!!111 значительная доля одинаковой памяти поменяется у многих ВМ, и Consumed memory резко скакнет. И имеющейся физически памяти на всех не хватит.

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

А вот если на этой вСфере работают и менее критичные ВМ, и если такая ситуация наступит, то заранее розданные shares позволят производственным ВМ пережить такой всплеск «недедуплицируемости» памяти с минимальным падением комфорта, ну а через какое-то время все устаканится и неважные ВМ вернуться из своих свопов.

Ну а стоят ли эти минусы экономии трети* памяти вашей вСферы – решать вам.

*Здесь «треть» означает «больше или меньше 30%»**. 

**Данные приведены по результатам многочисленных тестирований в количестве одной штуки***. 

***Автор не несет ответственности за негативные результаты, полученные при использовании приведенной здесь информации.
За позитивные результаты – несет, пишите спасибо в камментах к посту. 

;-) 

big thx Сергею Щадных за информацию.

VAAI

есть такая штука - VAAI, vSphere API for Array Integration. Ее поддержка на стороне СХД позволит ускорить выполнение некоторых операций и сократить накладные расходы на дисковую подсистему за счет сокращения числа блокировок LUN'ов для изменения метаданных.

Есть мнение - Using VAAI to Maintain Control? - , что эти API всего лишь часть стандарта SCSI, и другим вендорам не составит труда реализовать подобное в своих гипервизорах.

Scripted Removal Of Non-present Hardware After A P2V

Те, кому приходилось использовать VMware Converter для переноса физических серверов в ВМ знают, что в перенесенной таким образом ВМ остается много теперь ненужного.

Это разного рода софт\драйверы физического сервера, и само оборудование физического сервера, упоминание о котором остается в гостевой ОС.


Я недавно в очередной раз писал о существовании удобной утилиты для серверов HP - HP Proliant Support Pack Cleaner, умеющей подчищать софт этого вендора.

А поводом к этому посту стал пост Scripted Removal Of Non-present Hardware After A P2V.

Автор предлагает скачать скрипт, который упростит удаление упоминаний о ненужном уже оборудовании при переносе любого физического сервера (для Windows).

На свой страх и риск. Делаем снапшот перед попыткой применить эту штуку.

зачем нужен каталог .dvsData для распределенных виртуальных коммутаторов

Если кто пользуется распределенными виртуальными коммутаторами VMware, то вы скорее всего обращали внимание на каталоги .dvsData, появляющиеся на хранилищах.

Я тут узнал зачем они нужны - vDS config location and HA. Или оно же по русски - vDS конфиг файлы и VMware HA.

Virtual Storage Applience - Starwind

Коллеги, новый частично тематический русскоязычный блог - Секреты работы StarWind, автор Константин Введенский.

И интересная новость с его блога - Отрелизился StarWind VSA.

Transparent Page Sharing

Просто вау - Transparent Page Sharing в ESX 4.1 — по следам прошлогодней статьи.

Я задавался примерно теми же вопросами (напр. Transparent memory page sharing, vdi, large pages), но автор поста по ссылке вроде как нашел ответы.


Очень, очень рекомендуется к прочтению.

P.S. TPS это лишь одна из нескольких технологий ESX(i) для работы с памятью. Вспомнить об остальных можно тут - Memory management.

P.P.S. блог автора (предположительно), англоязычный - http://vmnomad.blogspot.com/

deinoscloud, vsphere miltipathing

Углядел тут нового для себя западного блогера - deinoscloud.wordpress.com.

Для памятки пара интересных постов.

• Все про Multipathing для vSphere - VMware PSA, MPP, NMP, PSP, MRU, … And Tutti Quanti!.

Например, интересная инфа про именование модулей сторадж-стека:

Или инфа про то, что вроде как для ев хьюлет рекомендует настраивать для round-robin балансировки смену пути через каждую 1 команду, не через 1000 как по умолчанию.

• еще вот про multipathing - EMC PowerPath/VE, Get It For FREE!.

В частности, мне понравилось следующее разъяснение по поводу multipathing:
"В составе ESX(i) есть поддержка многопутевости в смысле работы с СХД, доступной по нескольким путям, и обработки отказа пути. Но нет поддержки балансировки нагрузки, т.е. работы сразу по нескольким путям с неким алгоритмом балансировки."

• Хорошо написано про ALUA - Aloha ALUA.

HA admission control

Последние несколько недель у меня происходило довольно много дискуссий по поводу вроде бы довольно банального VMware HA. Дело в том, что в какой-то момент я задумался над некоторыми его настройками, и нашел их менее очевидными, чем это мне казалось. И вот по этому поводу и хотелось бы немного вбросить.

Часть первая, введение

Итак, коллеги, начнем с банальностей.

Чем мы платим за высокую доступность, которую дает нам VMware HA?

Правильный ответ – ресурсами. Вернее, заначкой ресурсов на случай сбоя.

Эту заначку ресурсов мы учитываем

1. При планировании инфраструктуры.
   
2. При эксплуатации инфраструктуры.
   

В первом пункте это выглядит примерно так:

«Ага, нам надо будет запустить 40 ВМ по 2 ГБ ОЗУ каждая, всего 80 ГБ. Накинем еще

• Запас на пиковые нагрузки;
  
• Запас на рост на будущее;
  
• Запас на случай отказа одного из серверов;
  
• Запас на неправильные расчеты исходных ресурсов ВМ.
  

И получим (к примеру) 120 ГБ, которые и раскидаем по трем предлагаемым серверам, очевидно по 40 ГБ в каждом».



А во втором случае это выглядит примерно так:

«Ага, если нагрузка на мои сервера превысит 65%, то при отказе одного (двух\трех\...) серверов ресурсов остальных уже не хватит для всех виртуальных машин. Поимею-ка я это в виду…»

Часть вторая, контроль заначки ресурсов

Теперь, внимание, вопрос – а каким образом мы можем поиметь в виду недопустимость нагрузки на каждый из серверов выше порогового значения? Вариантов, в общем-то, два:

1. Или сам администратор заявляет «Я не включу ни одной дополнительной виртуальной машины, пока не будет приобретен еще сервер-другой в мою вСферу». Или, как вариант, «Давайте купим еще сервер, иначе через месяц новые ВМ негде будет включать без опасения что ресурсов не хватит в случае отказа сервера».
   
2. или при попытке администратора включить еще одну ВМ появится сообщение об ошибке вида как на рис. 1
   

Рисунок 1. Сообщение о невозможности включить ВМ из за настроенного Admission Control

Вольный перевод:
«VMware HA запрещает тебе, холоп, включать эту ВМ, ибо претендует она на мою заначку ресурсов на случай сбоя».


И какой вариант контроля выберете вы?


Давайте их обсудим.

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

Или в ситуации, когда администратор vSphere не обладает достаточными возможностями по продавливанию бюджета на очередной сервер.

Случай номер два, в принципе, выглядит неплохим. Мы поручаем работу по контролю нагрузки на инфраструктуру кластеру HA, и теперь система непрерывно следит «А можем ли мы себе позволить еще одну ВМ?». Однако, и вот моя самая главная претензия, способы оценки «можем\не можем» далеки от идеала, и именно этот тонкий момент мне хотелось бы проговорить.

Часть третья, настройки Admission Control

У кластера HA есть соответствующая настройка - Admission Control (рис.2).

Рисунок 2. Настройка контроля заначки ресурсов

В положении «Disable: Power on VMs…» HA не будет сам контролировать заначку. Как раз такая настройка нам подойдет, если мы этот контроль будем осуществлять сами.

А настройка «Enable: Do not power on VMs…» как раз и приведет к автоматическому контролю «заначки ресурсов», что может вызвать за собой сообщение с рис.1.

А три варианта настройки с рис.2 – это способы оценки заначки. Давайте про них поговорим.

Specify a failover host – сервер-запаска

Рисунок 3. Указание сервера-запаски

Самый простой вариант. Мы сами выбираем тот один сервер, на котором HA не позволит работать ни одной виртуальной машине. Даже DRS или мы сами не сможем мигрировать на него ВМ или включить. Но сам сервер работать будет все время, пустым. А остальные сервера HA не будет контролировать никак (рис. 4).


 

Рисунок 4. Пример статистики по нагрузке на сервера кластера

Мне этот вариант настройки нравится по следующим причинам:

• Он простой и понятный. Вот сервер – запаска, вот – все остальные сервера, на которые контроль не распространяется.
  
• Он дает хорошую гарантию достаточности ресурсов. Если допустить, что сервера у нас типовой конфигурации, то при отказе одного у нас есть 100% ресурсов такого же сервера – неплохая гарантия что после сбоя виртуалкам будет где подняться.
  

Однако минусы тоже есть:

• В маленьком кластере выделить целый один сервер может быть слишком много.
  
• В большом кластере резервирование только одного сервера может быть слишком мало.
  

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

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

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

Percentage of cluster resources reserved as failover spare capacity – процент ресурсов

Второй вариант настройки резервирования ресурсов кластера на случай отказа – резерв указанного процента ресурсов на каждом сервере (рис. 5).

Рисунок 5. Резерв процента ресурсов

Проблем две.


Первая, не очень острая - а сколько процентов надо указать?


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

Наводящая картинка – как вы думаете, рис. 6 это чудеса фотошопа или реально возможная ситуация?

Рисунок 6. Статус резервирования для кластера и фактическая нагрузка на сервера кластера

Раскрою что здесь изображено - HA считает что ему надо резервировать 25% ресурсов, а реально у него еще свободно от резервов 97%. 
А на нижней части рисунка отображена реальная нагрузка на оба сервера кластера в 100%.


Так как - это возможно?


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

Для правильного понимания ситуации давайте немного отвлечемся.

Взгляните – вот информация по параметрам виртуальных машин (рис. 7).

Рисунок 7. Четыре разных параметра ОЗУ виртуальных машин

Здесь мы видим, что у виртуальной машины vCenter:

• 3 гигабайта памяти – максимум;
  
• 0.5 гигайбата – резерв;
  
• 1.9 гигабайта гипервизор реально тратит на нее;
  
• 7% от 3 гигабайт она активно использует.
  

Внимание, вопрос – какой из этих показателей контролируется HA Admission Control?

Правы те, кто ответил Reservation.

Т.е. резервирование 25% ресурсов каждого сервера означает, что на каждом сервере сумма резервов включенных виртуальных машин должна быть меньше-равна 75% ресурсов сервера.

А максимальное или реальное потребление ресурсов виртуальными машинами НЕ_УЧИТЫВАЕТСЯ_НИКАК.

Допустим:

• У типового сервера 64 гигабайта оперативной памяти;
  
• 4 ГБ занял гипервизор, 60 ГБ (для ровного счета) доступно виртуальным машинам;
  
• Для HA мы указали зарезервировать 25% ресурсов – т.е. 15 ГБ памяти он зарезервировал;
  
• Типовая виртуальная машина имеет 4 ГБ памяти как максимум, 0.1 ГБ как резерв, сколько-то потребляет де-факто.

Сколько типовых ВМ нам дадут запустить на этом типовом сервере с 25% резерва под HA?

Правильный ответ: До задницы много.Порядка 450 если учитывать только резервирования памяти.

Это означает, что

без указания адекватного reservation для каждой (или большей части) ВМ этот тип резервирования – фикция.

По той простой причине, что нам не очень радостно от того, что HA нам позволяет включить сотую ВМ, хотя уже на тридцатой сервер стал нагружен на 100%.

Кстати говоря, а какой должна быть настройка reservation?

Я вижу два основных варианта – или reservation = 100% от выданного ВМ объема памяти, или reservation равен среднему объему активно используемой памяти (рис. 8).

Рисунок 8. Активно потребляемая память

Именно на уровне каждой ВМ, не только пулов ресурсов или vApp!

Host failures cluster tolerates – по слотам

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

Рисунок 9. Резервирование "По слотам"

Далее, HA формирует размер «слота». «Слот» это всего лишь количество мегагерц и мегабайт. 

Формируется слот или автоматически – по наибольшему reservation среди всех ВМ в кластере, или (что правильнее) указывается вручную через Advanced settings.

Так или иначе размер слота выбран, теперь считаем статистику нашего кластера (рис. 10).

Рисунок 10. Статистика по слотам в кластере

Мы видим, что:

• Один слот это 50 МГц и 100 МБ;
  
• В кластере у нас 82 слота;
  
• 14 слотов занято;
  
• 9 слотов можно занять еще (9 а не 27 по той причине что серверы различны по конфигурации, а расчет идет по наихудшему сценарию – отказу самого мощного сервера).

(Эти подсчеты никак не связаны с параметрами виртуальных машин из предыдущих примеров).

Одна виртуальная машина может занять один, а может несколько слотов (как на рисунке 10 – включено всего 2 ВМ, однако занято 14 слотов). 

Внимание, вопрос – от чего это зависит?

Внимание, не самый радостный ответ – снова от reservation виртуальной машины.

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

Небольшая иллюстрация на рис. 11:

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

Этим чудесным хенд-мейд комиксом я хочу проиллюстрировать тот факт, что нам будет мало радости от того, что очередная виртуальная машина включиться (так как слот под нее есть), но работать будет плохо (так как достаточно ресурсов для нее нет) – рис. 12 или, что то же самое – рис. 6.

Рисунок 12. Иллюстрация оторванности подсчета слотов от реальных аппетитов ВМ

Некоторые факты и соображения

В инфраструктурах покрупнее кластеру HA впору опасаться не только отказа сервера, но и отказа группы серверов – из-за отказа шасси блейд-серверов.

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

Рисунок 13. Разбивка кластеров HA по шасси

В каждом шасси не более четырех серверов, потому что HA гарантированно переживает отказ максимум четырех серверов.


И теперь нас интересует настройка резервирования ресурсов для каждого кластера независимо. К сожалению, если отказ шасси влечет за собой отказ более одного сервера кластера, то простого способа гарантировать достаточность ресурсов для ВМ после сбоя нет. Ну или я не вижу :-)

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

Подведение итогов

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

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

Варианты резервирования «процент ресурсов кластера» и «по слотам» мне видятся неприменимыми без указания адекватного reservation для каждой важной ВМ.

Обратите внимание - по данным опроса в прошлом посте 169 из 184 (на момент написания) ответивших не используют reservation для широкого круга ВМ - т.е. если у этих 92% ответивших  настроен первый или второй вариант Admission Control - это бессмысленно.

А стоит ли заморачиваться с reservation для работы этих вариантов Admission control – это отдельный вопрос, и не факт что ответ будет «да».

Еще одним вариантом как можно поступить является следующий:

1. Как-то адекватно настроить admissions control – самое применимое это выбрать сервер-запаску или вообще отключить этот контроль.
   
2. Создать набор пулов ресурсов, и распихать туда виртуальные машины в соответствии с их важностью для нас. В соответствие с важностью указать shares(и, может быть, reservation) на уровне пулов.
   
3. Теперь мы получим гарантию, что нашим важным виртуальным машинам хватит ресурсов, пусть даже путем вытеснения неважных ВМ с процессоров и в своп если после срабатывания HA ресурсов на всех не хватает.
   

ИМХО, этот вариант лидер по соотношению сложности\эффективности.

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

Список MAC адресов на dvSwitch

Вот тут - How to query for MACs on internal vSwitch on ESXi - делятся набором команда и готовым скриптом, который поможет получить данные по MAC адресам с распределенного виртуального коммутатора.

HP Proliant Support Pack Cleaner

VMware Converter - очень эффективное средство миграции физических серверов в виртуальные машины.

Однако после миграции физического сервера в ВМ имеет смысл удалить программное обеспечение, которое неактуально после смены железа.

Для серверов HP есть специальная программа - HP Proliant Support Pack Cleaner.

starwind

Я как-то неотреагировал, а недавно компания Starwind объявила о честной бесплатности своего программного iSCSI target под Windows - StarWind Software Inc. Presents Free Version of iSCSI SAN Solution.

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

Несколько лет назад я начинал работать с виртуальной инфраструктурой VMware,  и находился в поисках способа организовать разделяемое хранилище для своей тестовой среды. Опробовав несколько вариантов программных iSCSI и NFS стораджей, я ими остался неудовлетворен - по тем или иным причинам.

С какими-то реализациями ESX не захотел работать. С какими-то не захотел работать я :-), особенно это касалось вариантов под Linux.

И тогда я узнал о существовании Starwind software (тогда еще rocket division). Специально поднял свою переписку - в марте 2007 года я написал им письмо с запросом NFR лицензии для демо-стендов, и Anton Kolomyeytsev любезно мне ее предоставил.

С тех пор я наподнимал десятки стендов, некоторые из которых просуществовали по нескольку месяцев, а один - уже почти два  года.

Вот это скриншот Windows 7, в которой установлен продукт от starwind. На этой же Windows 7 установлен VMware Workstation, в виртуальных машинах которой крутятся ESX, ESXi и vCenter, для которых Starwind iSCSI target и предоставляет разделяемое хранилище.

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

Все это время я ни разу не испытал проблем с продуктом Starwind - ребята, спасибо!

С первых использованных мною версий продукт значительно развился, обзавелся функционалом высокой доступности, дедупликации и др., рекомендую глянуть первоисточник - StarWind Free Edition Overview.


P.S.
Довольно интересен и, местами, даже холиворен вопрос про использовании программных СХД (тем более под винду!!!111) в производственной среде - тут я опытом поделиться не могу, поэтому промолчу. Но, к слову сказать, небезинтересная дискуссия развернулась вот на форуме VMware - Starwind Free.

Snapshot это плохо

Перевод интересного поста - Влияние снапшотов на производительность - 1.
Цитата:

Мы уже получили очень важную информацию: для начала, один лишь факт наличия снапшота означает двукратный рост операций read. Более того, если ВМ записивает блок, который еще не был записан в снапшот, происходит две операции записи - сначала нужно обновить таблицу "где найти конкретный блок" (снапшот или базовый диск). И это очень сильно влияет на производительность!

Если вы еще не верите, что для производственных ВМ снапшоты это зло, см. интересную подборку "всё всё всё про снапшоты" - Snapshots: Подборка интересных постов и статей.

Inventory Snapshot

На сайте экспериментальных продуктов VMware новое поступление - InventorySnapshot.

Обещают, что эта штука сохранит объекты иерархии vCenter, т.е. папки для хостов и ВМ, кластеры, какой хост в каком кластере, пулы ресурсов, vApp, роли и назначение ролей, custom fields.

А затем запустит PowerShell скрипт, который восстановит эту иерархию объектов в указанном (предполагается новом или другом) vCenter.

Видео с иллюстрацией работы:

VMware vSphere 4.1 Storage Performance: Measuring FCoE, FC, iSCSI, and NFS

VMware и NetApp зарелизили интересный документ - VMware vSphere 4.1 Storage Performance: Measuring FCoE, FC, iSCSI, and NFS.

Взяли кучу железа, кучу ВМ, кучу нагрузки с них на диски и померяли IOps, нагрузку на процессор и latency для разных протоколов (FC 4 Gbit, iSCSI 1\10 Gbit, NFS 1\10 Gbit, FCOE 10 Gbit).

Вывод - разницы нет что использовать :-)

The HA and DRS Audit Script

Не так давно вышла книга "HA and DRS deepdive". Я ее купил, прочел, и, в целом, могу рекомендовать для тех, кому хочется понимать устройство этих кластеров. Как альтернативу придти ко мне на курсы пообщаться на эту тему ;-)

PowerCLI-гуру  Alan Renouf  "...прочел первые 50 страниц, возбудился, и, с разрешения авторов, накидал скрипт, проверяющий кластер на соответствие рекомендациям".

Выглядит эта штука шикаарно - после запуска скрипта в консоли PowerCLI можно наблюдать красочную форму для ввода параметров доступа к vCenter:

После себя остается не менее красочный html файл с выжимкой текущих настроек кластеров HA\DRS, и статистики по ним:

Посмотреть этот отчет по моему кластеру можно вот тут.

Видео как это все используется:

HA and DRS Audit Script from Alan Renouf on Vimeo.

Однако я пока глубокого смысла в этих данных не углядел.
Впрочем, кому-то может и пригодится, и, самое главное, стоит ждать доработки этого скрипта - так что страницу с ним стоит проверять - The HA and DRS Audit Script.

HA Slot sizes

Помнится мне, как-то на форуме VMware было довольно бурное обсуждение касаемо подсчета слотов для кластера HA.

Для интересующихся темой может быть интересной информация отсюда - HA Slot sizes – how do we get those numbers from vCenter?

VMware vSphere 4.1 Networking Performance

Помните не очень давно камрад Umlyaut рассказывал о достижении скоростей порядка 16 Gbps между двумя ВМ на одном ESX(i) - vSphere network test - vmxnet3, Jumbo Frames

А теперь сама VMware рассказывает о достижении аж 27 Gbps - VMware vSphere 4.1 Networking Performance.

Правда, не при любых условиях и не для любой ОС:

Одна из идей документа - если есть приложение, которое генерит трафик в нереальных объемах, то можно воткнуть в ESX(i) до 4х контроллеров 10 Гбит Ethernet, выпустить через них ВМ с этим приложением, и при совпадении некоторых условий она получит канал с пропускной способностью до 36 Гбит\с, что близко к рассчетным значениям для современного железа.

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