Достаточно давно мы уже описывали средство централизованного администрирования хост-серверами VMware vSphere - vSphere Management Assistant (vMA). По сути, vMA - это вынесенная "сервисная консоль" за пределы хост-серверов ESXi в отдельный виртуальный модуль (Virtual Appliance), с которого удобно выполнять консольные команды RCLI (например, мониторинга - resxtop), а также хранить и запускать различные скрипты. Сегодня мы расскажем о том, как восстновить (сбросить) пароль на виртуальном модуле vMA.

Итак, загружаем VMware vMA 5, устанавливаем выбор на пункте меню "SUSE Linux Enterprise Server 11 SP1 for VMware" и нажимаем кнопку <e>:

В появившемся далее экране выбираем строчку с "kernel /vmlinuz" и снова нажимаем <e>:

В следующем экране, в строке ввода, вбиваем init=/bin/bash:

После нажатия <Enter>, вы вернетесь в педыдущее окно, где нужно нажать <b> для загрузки vMA. После загрузки вводим команду, которой и устанавливаем новый пароль:

# passwd vi-admin

Пароль установить непросто. Он должен соответствовать следующим политикам:

• Не менее 8 символовEight characters
• Хотя бы один символ в верхнем регистре
• Хотя бы один - в нижнем
• Хотя бы одна цифра
• Хотя бы один спецсимвол (#, $ и т.п.)

Понятно, что такой пароль никому не удобен. Поменять его можно командой:

# sudo passwd vi-admin

vMA будет жаловаться, однако пароль сменит:

С покупкой VMware компании Nicira стало больше разговоров о технологии VXLAN (Virtual eXtensible LAN), которая предоставляет расширенный механизм создания виртуальных сетей VLAN в крупных ИТ-инфраструктурах, объединяющих несколько датацентров компании (о ней мы уже упоминали). Разумеется, она нацелена на виртуализацию, и ее поддержка будет включена в платформу VMware vSphere в недалеком будущем. То есть VXLAN - это замена VLAN для создания прозрачной мобильной сетевой среды для виртуальных машин, имеющих возможность перемещаться между датацентрами.

Суть имеющейся сегодня проблемы заключается в том, что IP-адрес системы определяет две, по-сути разные, сущности: идентификатор системы и указатель на географическое размещение в сети (датацентр, сегмент), кроме того стандартная концепция VLAN позволяет использовать только до 4096 виртуальных сетей для логической изоляции классов систем, что в крупных инфраструктурах иногда оказывается недостаточно (особенно это касается IaaS-инфраструктур сервис-провайдеров, работающих с сотнями организаций, у каждой из которых свои VLAN).

Поэтому компании Cisco и VMware, к которым присоединились Citrix и Red Hat, разработали стандарт VXLAN, позволяющий организовать логические сети L2 поверх уровня L3 с возможностью минимального внесения изменений в существующую инфраструктуру сетевого взаимодействия в организациях. На данный момент черновик стандарта VXLAN в реализации IPv4 отправлен в организацию IETF, вскоре там будет и документ по реализации в IPv6.

Обзорный ролик по технологии VXLAN:

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

• VXLAN Network Identifier (VNI) - 24-битный идентификатор виртуальной сети, а значит их всего может быть более 16 миллионов штук
• MAC-адрес машины

Соответственно, в одной VXLAN-сети не может быть машин с одинаковым MAC-адресом, но в разных VXLAN-сетях они вполне могут существовать (что актуально для виртуальных машин, MAC которых генерируется автоматически и глобально не уникален). Большое количество возможных VXLAN-сетей позволяет виртуальным машинам "путешествовать" между инфраструктурой организации и сторонними сервис-провайдерами без изменения сетевой идентификации, сохранением политик и изоляции внутри виртуальной сети безотносительно ее физического размещения (у себя или у IaaS-провайдера).

Для работы инфраструктуры VXLAN есть следующие компоненты:

• Необходима поддержка режимов Multicast, IGMP и PIM
• Идентификатор VNI внутри IP-пакета, только машины с одинаковым VNI могут взаимодействовать между собой
• Шлюз VXLAN Gateway
• Компонент VXLAN Tunnel End Point (VTEP) на стороне сервера виртуализации
• Виртуальная сеть VXLAN Segment/VXLAN Overlay

С точки зрения IP-пакета VXLAN, в сети IPv4 его размер увеличивается на 50 байт, а в сети IPv6 - на 70 байт. Работает это примерно так:

Допустим у нас есть виртуальная сеть VXLAN с VNI равным 864. Когда виртуальная машина VM1 хочет послать IP-пакет виртуальной машине VM2 происходят следующие вещи:

• VM1 по протоколу ARP посылает пакет с запросом MAC-адреса VM2
• Компонент VTEP1, размещенный на первом сервере VMware ESXi, инкапсулирует этот ARP-пакет в мультикаст-пакет, ассоциированный с виртуальной сетью с VNI 864
• Все остальные VTEP, получающие этот пакет, добавляют ассоциацию VTEP1 и VM1 в свои VXLAN-таблицы
• VTEP2  получает пакет, декапсулирует его и посылает броадкаст на портгруппы виртуальных коммутаторов, которым присвоен VXLAN c VNI 864
• VM2, находящаяся в одной из этих портгрупп, получает ARP-пакет и отвечает своим MAC-адресом
• VTEP2 на втором хосте ESXi формирует юникастовый пакет и отправляет его уже по существующему маршруту
• VTEP1 декапсулирует пакет и передает его виртуальной машине VM1

Теперь обратимся к структуре VXLAN-пакета:

В нем есть следующие заголовки (слева-направо):

Outer MAC Header (Ethernet Header)

Он содержит следующие поля:

• Destination Address - это MAC-адрес VTEP назначения, если этот VTEP является локальным по отношению к ближайшему роутеру, или MAC-адрес самого роутера, если VTEP находится за ним
• VLAN - опциональное поле с тэгом VLAN (не обязательно в VXLAN-реализации)
• Ethertype - тип пакета (для IPv4 установлен в 0×0800

Outer IP Header

• Protocol - содержит значение 0×11, чтобы обозначить, что это UDP-пакет
• Source IP - IP-адрес VTEP источника
• Destination IP - IP-адрес VTEP назначения

UDP Header

• Source Port - устанавливается передающим VTEP
• VXLAN Port - порт VXLAN IANA (еще не определен)
• UDP Checksum - контрольная сумма пакета на уровне VXLAN

VXLAN Header

• VXLAN Flags - различные флаги
• VNI - 24-битное поле с идентификатором VXLAN
• Reserved - набор зарезервированных полей

Итак, VM1 по описанному выше алгоритму узнала MAC-адрес VM2, после чего начинает ей адресно слать пакеты примерно так:

• VM1 посылает IP-пакет к VM2 с адреса 192.168.0.100 на адрес 192.168.0.101
• VTEP1 берет пакет и инкапсулирует его, добавляя следующие заголовки:
• VXLAN header с идентификатором VNI=864
• Стандартный UDP-заголовок с назначенным портом (VXLAN IANA)
• Стандартный IP-заголовок с IP-адресом VTEP назначения и признаком UDP-пакета
• Стандартный MAC-заголовок с MAC-адресом следующего устройства (next hop). В данном случае это роутер с маком 00:10:11:FE:D8:D2, который будет использовать стандартную маршрутизацию пакета по IP-сети до VTEP2.
• Далее VTEP2 получает такой пакет, распаковывает его (он узнает, что это VXLAN, так как это UDP-пакет) и вытаскивает VNI (864). Далее уже очищенный от обертки IP-пакет направляется к VM2, которая находится в портгруппе с VNI 864, перед чем VTEP убеждается, что она может получить пакет
• Виртуальная машина VM2 получает IP-пакет очищенным, как обычный IP-пакет

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

Что еще можно почитать на эту тему (источники данной статьи):

• VXLAN Primer-Part 1
• VXLAN Primer-Part 2: Let’s Get Physical

Многие интересующиеся значимыми событиями, происходящими на рынке виртуализации, уже, наверное, читали о том, что VMware приобрела компанию Nicira за 1,26 миллиарда долларов (из них $1,05 млрд. - кэшем, что весьма много). Сумма этой сделки заставляет обратить на нее внимание и задуматься над тем, как ведущие компании в сфере облачных вычислений видят себе будущее частных облаков.

Для начала небольшой видео-обзор решения Nicira (основной продукт компании - Nicira Network Virtualization Platform ):

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

Основа данной концепции такова: мы берем различное железо и хранилища, которые есть в нашем датацентре, объединяем их в общий пул с помощью платформы виртуализации серверов. Далее эти вычислительные мощности и стораджи мы отделяем от логической ценностной единицы ИТ - приложений - с помощью абстракций - виртуальных машин и виртуальных хранилищ. Общий вычислительный пул датацентра мы разрезаем на логически удобные нам единицы (пулы ресурсов) и дальше предоставляем пользователям виртуальные машины с соответствующим уровнем SLA из абстрактных сущностей, которые построены поверх оборудования и вычислительной архитектуры с определенными характеристиками. Делается это с помощью VMware vCloud Director с его концепцией виртуальных датацентров:

Но, помимо абстракции вычислительных ресурсов, нам нужно еще абстрагировать и сервисы хранения. Для этого сегодня существуют техники профилирования хранилищ (Storage Profiles) и средства автоматической балансировки нагрузки на них (Storage DRS):

Следующий аспект: виртуальные машины существуют на серверах и хранилищах уже на логическом, а не на физическом уровне (независимо от вендоров железа), как сделать так, чтобы в датацентре они были защищены политиками, да и сам периметр датацентра тоже был защищен? Ответ прост - есть семейство продуктов VMware vShield:

Прекрасно. Вроде все? Нет, не все. Невиртуализованной у нас осталась еще одна часть, а именно - сети. VMware предоставляет нам распределенный виртуальный коммутатор (Distributed vSwitch) с базовыми технологиями изоляции и контроля (Private VLAN), есть также продукт от Cisco - Nexus 1000V, который выполняет схожие функции, но обладает более широкими возможностями. Все это делается на уровне абстракции сетевых интерфейсов хост-серверов.

Однако в данном подходе нет самого главного - средств абстракции и виртуализации физического сетевого оборудования (коммутаторов, маршрутизаторов), большим парком которых применительно к виртуальным машинам нужно централизованно управлять в датацентре компании, где есть сотни виртуальных сетей, политик и конфигураций. Все это приводит к тому, что на развертывание новой виртуальной машины уходит 2-3 минуты (на сервере+хранилище), а вот на настройку сетевого взаимодействия, VLAN, безопасности, политик и прочего в забюрократизированных организациях уходит несколько дней.

Вот эту фундаментальную проблему и решает компания Nicira, так недешево доставшаяся VMware:

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

Все это называется программно-определяемые сети (Software-defined networking, SDN) и работает на базе программных решений, разрабатываемых Nicira с далекого 2007 года. Интересно, что основательница VMware, Диана Грин, которую двинули с поста CEO компании, была одним из инвесторов Nicira, о чем мы писали 2 года назад. Диана вышла с неплохим профитом, а Nicira теперь позволит VMware получить законченную концепцию полной виртуализации облачного датацентра. Как нам и обещали, VMware вполне может стать "VMware of Networking". Кстати, теперь при покупке Nicira компания VMware снова двигает своего CEO.

Если тема вам интересна, можно почитать следующие материалы:

• VMware and Nicira – Advancing the Software-Defined Datacenter
• VMware acquires DynamicOps and Nicira, first steps to a heterogeneous hypervisor cloud solution?
• VMware buys Nicira for $1.05 billion (Zdnet)
• What Is Network Virtualization?
• vSwitch is the New Battleground. What Every Datacenter Operator Must Know.

Ну и следующая новость - покупка компанией VMware конторы DynamicOps (продукт Virtual Resource Manager, VRM). Эта контора была выделена из небезызвестного банка Credit Suisse и разрабатывает средства для автоматизации гибридных облаков на базе нескольких гипервизоров (что неизбежно будет в крупных организациях с приходом Hyper-V 3.0), а также средства управления сервисными архитектурами вроде Platform-as-a-Service, Database-as-a-Service и Storage-as-a-Service.

Компания StarWind Software, выпускающая продукт номер 1 StarWind iSCSI SAN для создания хранилищ для виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V, приглашает на вебинар "Introduction to SAN Infrastructures", посвященный созданию отказоустойчивой архитектуры хранения на базе данных платформ и протокола iSCSI, который пройдет завтра, 26 июля.

В рамках вебинара вы узнаете о том, как:

• Настроить зеркало синхронизированных хранилищ с автоматическим восстановлением после отказа без простоя виртуальных машин
• Создать синхронно реплицированную копию данных виртуальных хранилищ на DR-площадке
• Использовать технологии защиты данных CDP/Snapshots
• Экономить дисковое пространство за счет технологии Thin Provisioning

Вебинар пройдет в 22-00 по московскому времени, так что сделайте чаю с печеньками и смотрите.

Классная инфографика, гда наш с вами уютный портальчик тоже есть:

Приходите чаще - кружок будет больше.

По прошествии майской конференции Citrix Synergy, где компания Citrix объвила о покупке конкурирующего клиентского гипервизора NxTop вместе с компанией Virtual Computer, было объявлено о выпуске новой версии Citrix XenClient Enterprise 4.1 (ранее мы уже писали о версии 2.1, вышедшей в конце прошлого года).

Такой скачок версий объясняется тем, что Citrix включила в новый релиз XenClient множество наработок от продукта NxTop, который на момент продажи Citrix достиг версии 4.0.8. Теперь Citrix XenClient 4.1 включает в себя поддержку значительно большего спектра оборудования клиентских ПК и ноутбуков, а также больше интегрирован с виртуальной инфраструктурой Microsoft Hyper-V. Мало того, само решение XenClient в качестве серверного бэкэнда использует только инфраструктуру Hyper-V. Интерфейс нового XenClient был позаимствован из NxTop, поэтому пользователям предыдущих версий решения придется немного попривыкать к новым особенностям клиентского гипервизора.

Решение Citrix XenClient Enterprise 4.1 включено в издания Citrix XenDesktop Enterprise и Platinum, а значит пользователи инфраструктуры виртуальных ПК от Citrix могут сразу же приступить к тестированию решения. Пользователи могут просто переключаться между удаленными и локальными копиями своих виртуальных машин, а также использовать сервис хранения ShareFile от Citrix и технологии доступности приложений и данных Follow-Me-Apps и Follow-Me-Data.

Новые возможности Citrix XenClient Enterprise 4.1:

Поддержка новых устройств (в 9 раз больше, чем раньше)

• XenClient значительно расширил список совместимости железа (hardware compatibility list, HCL)
• Поддержка новых устройств, таких как Ultrabook и систем на базе Intel Core третьего поколения (см. тут)
• Поддержка модемов 3G/4G
• Расширенная поддержка графических устройств nVidia
• Обновленные аудио-драйверы

Расширение функций средств управления

• Переработанный серверный бэкэнд средства управления (XenClient Enterprise Synchroniser), которое может работать на платформах Microsoft Hyper-V, VMware vSphere и Citrix XenServer
• Возможности Enterprise-масштабирования, пришедшие от NxTop, позволяющие гибко управлять тысячами виртуальных ПК на устройствах пользователей
• Улучшенные механизмы политик для виртуальных ПК и ролевой модели доступа с большим уровнем гранулярности
• Улучшенная интеграция с Active Directory

Простота использования

• Улучшенные механизмы управления в гостевой ОС, позволяющие управлять сетями Wi-Fi, настройками окружения и устройствами ввода
• Автоматический апгрейд самого XenClient без вмешательства пользователя
• Окружений типа "Connect" для быстрой загрузки ПК и доступа к интернету со встроенным Google Chrome

Обзор инсталляции Citrix XenClient Enterprise 4.1 и компонента Synchronizer:

Если у вас есть аккаунт MyCitrix, то загрузить продукт Citrix XenClient Enterprise 4.1 вы можете по этой ссылке. Если нет - триал можно скачать по этой ссылке.

В преддверии выхода новой версии платформы Microsoft Hyper-V 3.0 в составе Microsoft Windows Server 2012 мы решили обобщить сведения о новых возможностях этого продукта и более-менее объективно сравнить их с возможностями лидирующей платформы VMware vSphere 5.0. В сравнении учетны различные аспекты функциональности обеих платформ, однако оно ни в коей мере не претендует на свою полноту. Всем известно, что VMware vSphere не просто так номер один на рынке, с другой стороны, Hyper-V стал очень силен. Поэтому что выбирать решать в конечном итоге вам (при этом неплохо проанализировать и стоимость капитальных вложений в лицензии, а также посчитать совокупную стоимость владения обоими решениями).

Собственно, сравнение:

В итоге наш вывод таков - весьма большое количество Enterprise-функциональности присутствует только в издании VMware vSphere Enterprise Plus. В сегменте же среднего и малого бизнеса Microsoft Hyper-V 3.0 вкупе с System Center Virtual Machine Manager 2012 практически ни в чем не уступает остальным изданиям vSphere (а кое-где и превосходит). Поэтому, если вся заявленная функциональность Hyper-V 3.0 работает - то компаниям среднего и малого бизнеса однозначно нужно выбирать эту платформу, потому что это дешевле.

Kenny сделал хорошую запись о списке дефолтных аккаунтов для различных продуктов VMware, а мы сведем это в таблицу для вашего удобства, добавив парочку отсутствующих продуктов:

Вроде всё. Если знаете еще что-то, напишите, пожалуйста, в каменты.

Мы уже писали про средства доверенной загрузки, которые нужно использовать в виртуальной инфраструктуре VMware vSphere 5, чтобы нейтрализовать угрозы, свзанные с доверенной загрузкой, и соответствовать требованиям руководящих документов ФСТЭК. Напомним, что когда дело касается виртуальных машин, организовать их доверенную загрузку можно с помощью сертифицированного средства защиты vGate R2 от компании Код Безопасности, в котором есть множество наборов политик, которые можно применять к различным объектам виртуальной инфраструктуры:

Однако надо помнить, что нужно защищать также и сами хост-серверы ESXi, находящиеся в датацентре компании. Для эффективной защиты сервера виртуализации, помимо vGate R2, необходим электронный замок - ПАК «Соболь» версии 3.0 для реализации следующих защитных механизмов:

• идентификация и аутентификация пользователей на входе в систему (непосредственно при запуске сервера);
• ведение журнала безопасности;
• сигнализация попыток нарушения защиты;
• запрет загрузки с внешних носителей;
• контроль конфигурации (PCI-устройств, ACPI, SMBIOS и оперативной памяти).

На эту тему компания Код Безопасности выпустила специальную брошюру "vGate R2 и ПАК «Соболь» - надежная защита виртуальной инфраструктуры на платформе VMware vSphere 5", где можно почитать об основных проблемах контроля целостности хост-серверов VMware ESXi и виртуальных машин и их доверенной загрузки:

Применение обоих средств защиты информации – ПАК «Соболь» версии 3.0 и vGate R2 – в комплексе позволяет защитить сервер с установленной платформой для виртуализации VMware vSphere 5 и нейтрализовать угрозы непосредственного доступа (угрозы, реализуемые до загрузки ОС, и угрозы, реализуемые после загрузки ОС).

Наличие у продуктов сертификатов ФСТЭК России позволяет использовать vGate R2 и ПАК «Соболь» версии 3.0 для защиты информации, составляющей коммерческую или государственную тайну в автоматизированных системах с классом защищенности до 1Б включительно.

Напомним, что версия vGate R2 с поддержкой vSphere 5 уже поступила в продажу, а бесплатную пробную версию продукта можно скачать тут.

Компания Veeam Software, выпускающая продукт номер 1 Veeam Backup and Replication, в котором есть мастер восстановления объектов для Microsoft Exchange, объявила о начале открытого бета-тестирования бесплатного продукта Veeam Explorer for Exchange.

С помощью Veeam Explorer for Exchange можно открыть файл резервной копии виртуальной машины, в которой установлен почтовый сервер Microsoft Exchange, осуществлять навигацию в нем по объектам (пользователи/почтовые ящики), а также экспортировать письма в формат .pst и сохранять в .msg. Также есть возможность отправить их непосредственно в вложении письмом.

Утилиту можно использовать с любым изданием Veeam Backup and Replication, включая бесплатное издание Veeam Backup Free. Получить приглашение на бету Veeam Explorer for Exchange можно по этой ссылке.

Мы уже касались некоторых аспектов мониторинга производительности с помощью утилиты esxtop, которая есть на сервере VMware ESXi, а также метрик производительности хранилищ (и немного сетевого взаимодействия). Сегодня мы более детально взглянем на метрики производительности процессора (CPU) для контроля нагрузки виртуальных машин.

Если мы запустим утилиту esxtop, то увидим следующие столбцы (интересующее нас выделено красным):

Нас интересует 5 счетчиков, касающиеся процессоров виртуальных машин, с помощью которых мы сможем сделать выводы об их производительности. Рассмотрим их подробнее:

Счетчик %RUN

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

Если значение данного счетчика равно <Число vCPU машины> x 100%, это значит, что в гостевой ОС виртуальной машины процессы загрузили все доступные процессорные ресурсы ее vCPU. То есть необходимо зайти внутрь ВМ и исследовать проблему.

Счетчики %WAIT и %VMWAIT

Счетчик %WAIT отображает процент времени, которое виртуальная машина ждала, пока ядро ESXi (VMkernel) выполняло какие-то операции, перед тем, как она смогла продолжить выполнение операций. Если значение этого счетчика значительно больше значений %RUN, %RDY и %CSTP, это значит, что виртуальная машина дожидается окончания какой-то операции в VMkernel, например, ввода-вывода с хранилищем. В этом случае значение счетчика %SYS, показывающего загрузку системных ресурсов хоста ESXi, будет значительно выше значения %RUN.

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

Не надо пугаться высокого значения %WAIT, так как оно включает в себя счетчик %IDLE, который отображает простой виртуальной машины. А вот значение счетчика %VMWAIT - уже более реальная метрика, так как не включает в себя %IDLE, но включает счетчик %SWPWT (виртуальная машина ждет, пока засвопированные таблицы будут прочитаны с диска; возможная причина - memory overcommitment). Таким образом, нужно обращать внимание на счетчик %VMWAIT. К тому же, счетчик %WAIT представляет собой сумму метрик различных сущностей процесса виртуальной машины:

Счетчик %RDY

Главный счетчик производительности процессора. Означает, что виртуальная машина (гостевая ОС) готова исполнять команды на процессоре (ready to run), но ожидает в очереди, пока процессоры сервера ESXi заняты другой задачей (например, другой ВМ). Является суммой значений %RDY для всех отдельных виртуальных процессоров ВМ (vCPU). Обращать внимание на него надо, когда он превышает пороговое значение 10%.

По сути, есть две причины, по которым данный счетчик может зашкаливать приведенное пороговое значение:

• сильная нагрузка на физические процессоры из-за большого количества виртуальных машин и нагрузок в них (здесь просто надо уменьшать нагрузку)
• большое количество vCPU у конкретной машины. Ведь виртуальные процессоры машин на VMware ESX работают так: если у виртуальной машины 4 vCPU, а на хосте всего 2 физических pCPU, то одна распараллеленная операция (средствами ОС) будет исполняться за в два раза дольший срок. Естественно, 4 и более vCPU для виртуальной машины может привести к существенным задержкам в гостевой ОС и высокому значению CPU Ready. Кроме того, в некоторых случаях нужен co-sheduling нескольких виртуальных vCPU (см. комментарии к статье), когда должны быть свободны столько же pCPU, это, соответственно, тоже вызывает задержки (с каждым vCPU ассоциирован pCPU). В этом случае необходимо смотреть значение счетчика %CSTP

Кроме того, значение счетчика %RDY может быть высоким при установленном значении CPU Limit в настройках виртуальной машины или пула ресурсов (в этом случае посмотрите счетчик %MLMTD, который при значении больше 0, скорее всего, говорит о достижении лимита). Также посмотрите вот этот документ VMware.

Счетчик %CSTP

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

В итоге мы получаем следующую формулу (она верна для одного из World ID одной виртуальной машины)

%WAIT + %RDY + %CSTP + %RUN = 100%

То есть, виртуальная машина либо простаивает и ждет сервер ESXi (%WAIT), либо готова исполнять команды, но процессор занят (%RDY), либо ожидает освобождения нескольких процессоров одновременно (%CSTP), либо, собственно, исполняется (%RUN).

Мы уже много писали о производительности решения номер 1 StarWind iSCSI SAN, которое необходимо для создания отказоустойчивых хранилищ iSCSI для серверов VMware vSphere и Microsoft Hyper-V. Сегодня мы хотим обратить внимание на один интересный документ "StarWind Deduplication vs Nexenta Deduplication Test Report", в котором рассматриваются аспекты производительности хранилищ в сравнении продуктов StarWind iSCSI SAN и NexentaStor Enterprise:

Конфигурация тестовой лаборатории:

Решение StarWind iSCSI SAN побеждает во всех категориях:

Но самое интересное это то, что решение NexentaStor на практике часто не работает (!):

Такие вот бывают продукты :)

На сайте компании Slym Software обнаружилась интересная утилита vSphere Configuration Backup, которая позволяет производить резервное копирование конфигурации серверов VMware ESXi из графического интерфейса:

Напомним, что резервную копию настроек ESXi можно сделать из командной строки. Сама же утилита vSphere Configuration Backup делает не только бэкап конфига ESXi, но и позволяет сделать резервную копию базы данных vCenter. По умолчанию политика хранения бэкапов (Retention Policy) составляет 2 недели.

Основные возможности утилиты:

• Автоматическое резервное копирование нескольких конфигураций серверов VMware ESXi 4 / 5
• Бэкап любых локальных БД Microsoft SQL сервера vCenter
• Управление политиками хранения и удаление устаревших резервных копий
• Резервное копирование одного сервера ESXi в один zip-архив
• В имени архива отражается номер билда каждого из ESXi
• Не требует установки (меньше 2 МБ)
• Шифрует пароли
• Простая настройка с консолью "Configuration Manager.exe"

Скачать бесплатную утилиту vSphere Configuration Backup можно по этой ссылке. Утилита очень простенькая, но для небольших компаний вполне подойдет.

Мы уже не раз писали о различных типах очередей ввода-вывода, присутствующих на различных уровнях в VMware vSphere, в частности, в статье "Глубина очереди (Queue Depth) и адаптивный алгоритм управления очередью в VMware vSphere". Недавно на блогах компании VMware появился хороший пост, упорядочивающий знания об очередях ввода-вывода на различных уровнях виртуальной инфраструктуры.

Если речь идет о виртуальных машинах на сервере VMware ESXi, работающих с дисковым массивом, можно выделить 5 видов очередей:

• GQLEN (Guest Queue) - этот вид очередей включает в себя различные очереди, существующие на уровне гостевой ОС. К нему можно отнести очереди конкретного приложения, очереди драйверов дисковых устройств в гостевой ОС и т.п.
• WQLEN (World Queue/ Per VM Queue) - это очередь, существующая для экземпляра виртуальной машины (с соответствующим World ID), которая ограничивает единовременное число операций ввода-вывода (IOs), передаваемое ей.
• AQLEN (Adapter Queue) - очередь, ограничивающая одновременное количество обрабатываемых на одном HBA-адаптере хоста ESXi команд ввода вывода.
• DQLEN (Device Queue / Per LUN Queue) - это очередь, ограничивающая максимальное количество операций ввода-вывода от хоста ESXi к одному LUN (Datastore).
• SQLEN (Storage Array Queue) - очередь порта дискового массива (Storage Processor, SP)

Эти очереди можно выстроить в иерархию, которая отражает, на каком уровне они вступают в действие:

Очереди GQLEN бывают разные и не относятся к стеку виртуализации VMware ESXi, поэтому мы рассматривать их не будем. Очереди SQLEN мы уже частично касались тут и тут. Если до SP дискового массива со стороны сервера ESX / ESXi используется один активный путь, то глубина очереди целевого порта массива (SQLEN) должна удовлетворять следующему соотношению:

SQLEN>= Q*L

где Q - это глубина очереди на HBA-адаптере, а L - число LUN, обслуживаемых SP системы хранения. Если у нас несколько активных путей к одному SP правую часть неравенства надо еще домножить на P - число путей.

Соответственно, в виртуальной инфраструктуре VMware vSphere у нас несколько хостов имеют доступ к одному LUN через его SP и получается следующее соотношение:

SQLEN>= ESX1 (Q*L*P) + ESX2 (Q*L*P)+ и т.д.

Теперь рассмотрим 3 оставшиеся типа очередей, которые имеют непосредственное отношение к хосту VMware ESXi:

Как мы видим из картинки - очереди на различных уровнях ограничивают число I/O, которые могут быть одновременно обработаны на различных сущностях:

• Длина очереди WQLEN по умолчанию ограничена значением 32, что не позволяет виртуальной машине выполнять более 32-х I/O одновременно.
• Длина очереди AQLEN - ограничена значением 1024, чтобы собирать в себя I/O от всех виртуальных машин хоста.
• Длина очереди DQLEN - ограничена значением 30 или 32, что не позволяет "выедать" одному хосту ESXi с одного хранилища (LUN) более 30-ти или 32-х операций ввода-вывода

Все эти очереди можно посмотреть с помощью esxtop:

Зачем вообще нужны очереди? Очень просто - очередь это естественный способ ограничить использование общего ресурса. То есть одна виртуальная машина не заполонит своими командами ввода-вывода весь HBA-адаптер, а один хост ESXi не съест всю производительность у одного Datastore (LUN), так как ограничен всего 32-мя I/O к нему.

Мы уже писали о функционале Storage I/O Control (SIOC), который позволяет регулировать последний тип очереди, а именно DQLEN, что позволяет корректно распределить нагрузку на СХД между сервисами в виртуальных машинах в соответствии с их параметрами shares (эта функциональность есть только в издании vSphere Enterprise Plus). Механизм Storage IO Control для хостов VMware ESX включается при превышении порога latency для тома VMFS, определяемого пользователем. Однако, стоит помнить, что механизм SIOC действует лишь в пределах максимально определенного значения очереди, то есть по умолчанию не может выйти за пределы 32 IO на LUN от одного хоста.

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

1. Настройка длины очереди WQLEN.

Значение по умолчанию - 32. Его задание описано в статье KB 1268. В Advanced Settings хоста ESXi нужно определить следующий параметр:

Disk.SchedNumReqOutstanding (DSNRO)

Он глобально определяет, сколько операций ввода-вывода (IOs) может максимально выдать одна виртуальная машина на LUN одновременно. В то же время, он задает это максимальное значение в IOs для всех виртуальных машин на этот LUN от хоста ESXi (это глобальная для него настройка). То есть, если задано значение 32, то все машины могут одновременно выжать 32 IOs, это подтверждается в случае, где 3 машины генерируют по 32 одновременных IO к одному LUN, а реально к LUN идут все те же 32, а не 3*32.

2. Настройка длины очереди AQLEN.

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

3. Настройка длины очереди DQLEN.

Настройка этого параметра описана в KB 1267 (мы тоже про это писали) - она зависит от модели и драйвера HBA-адаптера (в KB информация актуальна на июнь 2010 года). Она взаимосвязана с настройкой Disk.SchedNumReqOutstanding и, согласно рекомендациям VMware, должна быть эквивалентна ей. Если эти значения различаются, то когда несколько ВМ используют с хоста ESXi один LUN - актуальной длиной очереди считается минимальное из этих значений.

Для отслеживания текущих значений очередей можно использовать утилиту esxtop, как описано в KB 1027901.

Помните мы писали про баг VMware ESXi 5.0 Updare 1, где была проблема с неработающим авто-стартом виртуальных машин?

В конце прошлой недели были выпущены патчи для ESXi (Patch Release ESXi500-201207001), решающие эту проблему. Скачать их можно с портала патчей VMware, выбрав продукт ESXi версии 5.0.0 и дату - 12 июля:

Эти патчи включают в себя обновления подсистемы безопасности, а также множественные исправления ошибок, в том числе, фикс проблем Auto Start и SvMotion / VDS / HA :

Патчи описаны в KB 2019107.

Кроме этого, было также выпущено обновление сервера управления VMware vCenter Server 5.0 Update 1a:

Среди новых возможностей VMware vCenter:

• Поддержка следующих СУБД Oracle:
• Oracle 11g Enterprise Edition, Standard Edition, Standard ONE Edition Release 2 [11.2.0.3] - 64 bit
• Oracle 11g Enterprise Edition, Standard Edition, Standard ONE Edition Release 2 [11.2.0.3] - 32 bit
• Смена БД vCenter Server Appliance - встроенная база данных DB2 Express теперь заменена на VMware vPostgres
• Несколько исправлений ошибок - их можно найти в секции Resolved Issues

Скачать VMware vCenter Server 5.0 Update 1a можно по этой ссылке.

Процедура обновления:

1. Сделайте резервную копию БД vCenter
2. Деинсталлируйте vCenter hot-patch (если он есть)
3. Установите новую версию, указав существующую БД

Для тех, кто активно использует инфраструктуру виртуальных ПК на базе решения VMware View, на сайте проекта VMware Labs появился интересный скрипт - View Controlled Recompose Script. Как знают пользователи VMware View, при необходимости обновления десктопов можно сделать операцию "Recompose", где, выбрав обновленный снапшот базовой ВМ или другую базовую ВМ, можно перестроить виртуальные машины пользователей пула ПК на работу с новым диском, не затрагивая диск с пользовательскими данными:

В отличие от стандартых средств по рекомпозиции в VMware View Manager, в скрипте View Controlled Recompose производится интеллектуальная процедура: через интерфейс WMI производится определение неиспользуемых виртуальных машин, после чего один из таких десктопов используется как реплика (Replica VM), а далее для неиспользуемых десктопов происходит рекомпозиция на базе этой реплики. Потом для активных десктопов можно сделать Force Logoff и перенаправить пользователей на уже рекомпозированные виртуальные ПК, а для этих активных десктопов, в свою очередь, доделать рекомпозицию.

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

• Pool - пул виртуальных ПК для рекомпозиции
• ParentVM - полный путь к базовому образу
• NewSnapshot - полный путь к снапшоту образа, из которого будет создаваться реплика и делаться рекомпозиция

Скрипт необходимо запускать на сервере VMware View Connection Server, сам же скрипт сделан на PowerCLI / PowerShell. Более подробные инструкции по его использованию приведены по этой ссылке.

Скачать скрипт VMware View Controlled Recompose Script можно по этой ссылке.

Мы уже писали недавно об обновленном сборнике иконок, рисунков и диаграмм для документирования инфраструктуры VMware vSphere, который содержит в себе все необходимое для презентаций и документирования проектов по виртуализации. Напомним:

• VMW_PPT_LIBRARY_Icons-Diagrams_2Q12_2_of_3.pptx (2.6 MB)
• VMW_PPT_LIBRARY_Icons-Diagrams_2Q12_3_of_3.pptx (2.9 MB)
• VMW_PPT_LIBRARY_Icons-Diagrams_2Q12_1_of_3.pptx (17.4 MB)

Недавно один добрый человек перевел это все в формат Microsoft Visio:

• Part 1
• Part 2

Еще один выложил полезные иконки, которых мало, но они могут пригодиться:

И он же сделал интересный плагин для Wordpress, показывающий параметры виртуальной инфраструктуры в блоге. Может тоже кому пригодится:

Что-нибудь еще полезное по этой теме подскажете?

Некоторое время назад мы уже писали о возможности конвертации RDM-томов, работающих в режиме виртуальной и физической совместимости, в формат VMDK. Сегодня мы поговорим об обратном преобразовании: из формата VMDK в формат RDM (physical RDM или virtual RDM).

Для начала опробуйте все описанное ниже на тестовой виртуальной машине, а потом уже приступайте к продуктивной. Перед началом конвертации необходимо остановить ВМ, а также сделать remove виртуального диска из списка устройств виртуальной машины. Определите, какой режим совместимости диска RDM вам необходим (pRDM или vRDM), прочитав нашу статью "Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere".

Создайте новый LUN на дисковом массиве, где будет размещаться RDM-том, и сделайте Rescan на хосте ESXi, чтобы увидеть добавленный девайс в vSphere Client:

Обратите внимание на Runtime Name (в данном случае vmhba37:C0:T1:L0) и на идентификатор в скобках (naa.6000eb....итакдалее) - этот идентификатор нам и нужен. Словить его можно, выполнив следующую команду (подробнее об идентификации дисков тут):

# esxcfg-mpath -L

В результатах вывода по Runtime Name можно узнать идентификатор. Вывод будет примерно таким:

vmhba33:C0:T0:L0 state:active naa.6090a038f0cd6e5165a344460000909b vmhba33 0 0 0 NMP active san iqn.1998-01.com.vmware:bs-tse-i137-35c1bf18 00023d000001,iqn.2001-05.com.equallogic:0-8a0906-516ecdf03-9b9000004644a365-bs-lab-vc40,t,1

Соответственно, второе выделенное жирным - идентификатор, его копируем.

Далее выполняем следующую команду для конвертации диска в Virtual RDM:

# vmkfstools –i <исходный>.vmdk -d rdm:/vmfs/devices/disks/<идентификатор>
/vmfs/volumes/datastore/vmdir/vmname.vmdk

Для Physical RDM:

# vmkfstools –i <исходный>.vmdk -d rdmp:/vmfs/devices/disks/<идентификатор>
/vmfs/volumes/datastore/vmdir/vmname.vmdk

Обратите внимание, что команты отличаются только параметрами rdm (виртуальный) и rdmp (физический).

Здесь:

• <исходный> - это путь к старому VMDK-диску, например, old.vmdk
• <идентификатор> - это то, что мы скопировали
• путь с vmdir - это путь к заголовочному VMDK-файлу для RDM-тома (может быть на любом общем Datastore)

Второй вариант клонирования диска подсказывает нам Иван:

vmkfstools --clonevirtualdisk /vmfs/volumes/Demo-Desktop-01/Exchange1/Exchange1_1.vmdk
/vmfs/volumes/Demo-Desktop-01/Exchange1/Exchange1_1_RDM.vmdk
--diskformat rdmp:/vmfs/devices/disks/naa.60a9800057396d2f685a64346b664549

Далее выберите виртуальную машину в vSphere Client и сделайте Add Disk, где в мастере укажите тип диска RDM и следуйте по шагам мастера для добавления диска. После этого проверьте, что LUN больше не показывается при выборе Add Storage для ESXi в vSphere Client. Запустите виртуальную машину и, если необходимо, в гостевой ОС в оснастке Disk Management сделайте этот диск Online.

Мы постоянно рассказываем вам новости о развитии продукта номер 1 для защиты виртуальных инфраструктур - vGate R2 от компании Код Безопасности. Напомним, что он позволяет разделить полномочия администраторов и производить аудит их действий в виртуальной среде, а также защитить корпоративные облака за счет встроенных средств автоматической настройки безопасной конфигурации хостов, а также механизма защиты от несанкционированного доступа.

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

В соответствиии с разделом "Обучение" на сайте Кода Безопасности, по продукту vGate R2 есть только возможность пройти онлайн-обучение и онлайн тестирование, что нисколько не умаляет его ценность. Основной онлайн-курс - это "Развертывание и администрирование средства защиты информации vGate". Он содержит информацию о назначении продукта, его архитектуре и возможностях. В курсе представлены типовые варианты развертывания и использования системы ИБ для инфраструктуры VMware vSphere.

Курс предназначен:

• Для технических специалистов партнерских организаций Группы компаний «Информзащита», планирующих оказание услуг с использованием продуктов и решений компании ООО «Код Безопасности».
• Специалистов организаций, планирующих построение систем защиты своих компьютерных систем с использованием продуктов и решений компании ООО «Код Безопасности».

План курса:

1. Назначение и архитектура vGate.
2. Установка и развертывание vGate.
3. Разделение ролей и механизмы аутентификации.
4. Управление доступом и политики безопасности.
5. Отчеты.
6. Дополнительные возможности.
7. Контрольное итоговое тестирование.

Напомним, что уже достаточно давно появилась и поступила в продажу версия vGate R2 с поддержкой VMware vSphere 5, а на днях обновился онлайн-курс по продукту. Помимо курса обновился и тест. Получить дополнительную информацию о курсах и тестировании можно по телефону +7 (495) 980-2345, доб. 827 или по электронной почте sdo@securitycode.ru.

По прохождении тестирования вам будет выдан сертификат, подтверждающий компетенцию по продукту vGate R2 и методикам защиты виртуальных сред.

Не так давно компания Microsoft опубликовала окончательную модель лицензирования нового поколения семейства серверных ОС Windows Server 2012, где достаточно существенно поменялись правила лицензирования ОС под виртуализацию.

Напомним, как обстояли дела с лицензированием операционных систем Windows Server 2008 R2:

Как видно из таблицы лицензия на издание Windows Server 2008 R2 Standard давала право на запуск одной хостовой машины и одной виртуальной, издание Enterprise - возможность запуска 4-х экземпляров под одной лицензией плюс хостовая платформа, а издание Datacenter позволяло запускать неограниченное количество экземпляров виртуальных машин в пределах одного лицензированного сервера.

Недавно мы уже упоминали о том, что для продукта Microsoft System Center 2012 Suite уже было убрано издание Enterprise, теперь же пришла очередь Windows Server 2012 лишиться этого издания. Теперь в новой ОС, с точки зрения виртуализации, осталось лишь 2 издания - Standard и Datacenter:

Издания Essentials и Foundation не предполагают каких-либо прав на виртуализацию и предназначены для совсем малых предприятий, поэтому здесь мы их рассматривать не будем, а сфокусируемся на изданиях Standard и Datacenter. Обратите также внимание, что исчезло издание Web Server Edition.

Во-первых, издание Windows Server 2012 Standard ничем не отличается по функциональности от издания Datacenter (Full Windows Server functionality), а поэтому оно подорожало. А именно в издании Windows Server 2012 Standard появилась следующая функциональность, которой не было в Windows Server 2008 R2:

• Windows Server Failover Clustering
• BranchCache Hosted Cache Server
• Active Directory Federated Services
• Additional Active Directory Certificate Services capabilities
• Distributed File Services (support for more than 1 DFS root)
• DFS-R Cross-File Replication

Соответственно, с точки зрения функционала мы имеем, по-сути, одно издание данной ОС. А дифференцируются эти издания следующим образом: Standard позволяет запустить до 2-х виртуальных машин под одной лицензией, а издание Datacenter - неограниченное количество ВМ.

Одна лицензия Windows Server 2012 Standard или Datacenter приобретается на 2 процессора физического хост-сервера. Таким образом, если у вас 4-процессорный сервер, вы можете:

• купить 2 лицензии Windows Server 2012 Standard и запустить 4 виртуальные машины на нем (неважно на платформе Microsoft Hyper-V или VMware vSphere)
• купить 2 лицензии Windows Server 2012 Datacenter и запускать сколько угодно виртуальных машин на нем (Hyper-V или vSphere)

Понятно, что 4 виртуальные машины на четырехпроцессорном сервере никто исполнять не будет, поэтому в случае увеличения количества ВМ на сервере можно пойти двумя путями, в зависимости от экономической целесообразности. Например, вы приобрели 2 лицензии на Windows Server 2012 Standard (1 лицензия = 2 CPU сервера) на четырехпроцессорный сервер, и у вас виртуальных машин стало больше четырех (т.е. больше того, что позволяет лицензия). В этом случае вы можете:

• Докупить еще лицензий на Windows Server 2012 Standard, каждая из которых позволит дополнительно запускать по 2 виртуальные машины на данном сервере
• Если у вас есть действующая подписка Software Assurance, можно сделать Software Assurance Step-Up апгрейд на Datacenter Edition и уже запускать сколько угодно виртуальных машин на этом сервере

Рассмотрим примеры:

1. У вас есть один двухпроцессорный сервер, на котором будет запущено 10 виртуальных машин и вам больше не потребуется увеличивать их количество на этом сервере. Посчитаем стоимость покупки Standard и Datacenter на этот сервер:

• 5 лицензий (каждая на 2 CPU хоста) на Windows Server 2012 Standard дают право исполнять 10 виртуальных машин и стоят 5 х 882 = $4 410
• 1 лицензия (на 2 CPU) на Windows Server 2012 Datacenter дает право исполнять эти 10 виртуальных машин и стоит $4 809

В этом случае лицензии на Windows Server 2012 Standard получается покупать выгоднее.

2. У вас есть один четырехпроцессорный сервер, на котором будет запущено 30 виртуальных машин. Посчитаем стоимость покупки Standard и Datacenter на этот сервер:

• 15 лицензий Standard (на 30 машин) обойдутся в: 15 х 882 = $13 230
• 2 лицензии Datacenter (на 4 CPU) обойдется в: 2 х 4 809 = $9 618

В этом случае уже выгоднее издание Windows Server 2012 Datacenter.

Общее правило для издания Standard таково - сначала вы покрываете требуемыми лицензиями все физические процессоры (сокеты), а далее докупаете лицензии на 2 виртуальные машины. То есть, для 10-процессорного сервера нужно купить минимум 5 лицензий, а для 20 виртуальных машин (неважно сколько физ. процессоров у хоста, если оно меньше 20) - минимум 10 лицензий.

Таким образом, все просто - если маленький коэффициент консолидации ВМ на хосте - нужно покупать Standard, если большой - Datacenter. При этом различия в функциональности нет.

Про даунгрейд с 2012 на 2008 R2 тоже все достаточно понятно. Можно сделать даунгрейд Datacenter на Datacenter, а Standard на Enterprise или Standard, при этом правила лицензирования виртуальных машин остаются от купленного Windows Server 2012:

Правила обмена лицензий Windows Server 2008 R2 на лицензии Windows Server 2012

Правила эти просты:

• каждая лицензия Windows Server 2008 R2 Enterprise (с действующей подпиской Software Assurance) обменивается на 2 лицензии Windows Server 2012 Standard (т.е. всего на 4 ВМ - как и было раньше).
• лицензия Standard 2008 R2 обменивается на Standard 2012 в соотношении 1 к 1.
• лицензия Datacenter 2012 покрывает 2 процессора, а Datacenter 2008 R2 - один процессор, поэтому за две старых 2008 R2 дают одну новую Datacenter 2012.

Более детальная информация представлена в документе "Windows Server 2012 Licensing & Pricing FAQ".

Иногда в целях безопасности необходимо настроить время, по прошествии которого если клиент vSphere Client не используется, требуется прервать сессию работы с VMware vCenter. Как подсказывает нам William Lam, сделать это можно двумя способами:

• Заданием аргумента при запуске исполняемого файла VpxClient.exe (vSphere Client)
• В конфигурационном файле VpxClient.exe.config на рабочей станции, где установлен vSphere Client

В первом случае мы задаем параметр inactivityTimeout в свойствах ярлыка vSphere Client, где устанавливаем время в минутах, после которого при неактивности клиента будет показан диалог о необходимости повторного логина:

Во втором случае нужно найти файл VpxClient.exe.config, который находится в следующих местах в зависимости от версии ОС:

• 32bit - %PROGRAMFILES%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher
• 64bit - %PROGRAMFILES(x86)%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher

Открываем этот XML-файл и прямо перед окончанием секции cmdlineFallback добавляем следующую секцию:

<inactivityTimeout>X</inactivityTimeout>

Если вы задали значение 1, то после неактивности в течение 1 минуты, будет показано следующее сообщение:

Также Вильям указывает на еще 2 интересных параметра, которые могут быть заданы как на уровне аргументов исполняемого файла клиента, так и в VpxClient.exe.config:

• -expAll либо добавление секции <expAll /> - при открытии vSphere Client ваше Inventory хостов и виртуальных машин будет полностью раскрыто
• -noPlugins либо добавление секции <noPlugins /> - при запуске клиента все плагины будут отключены

Наш с вами коллега, Анатолий Вильчинский, проводит в ближайшие дни 2 интересных вебинара по продукту номер 1 для создания отказоустойчивых хранилищ под виртуализацию - StarWind iSCSI SAN.

Первый вебинар, который пройдет 11 июля в 19-00 по Москве, посвящен версии продукта StarWind 5.8 (есть также бета 5.9) для серверов VMware vSphere и называется "Storage Evolution & StarWind v5.8 Solutions ".

Зарегистрироваться.

На следующий день, 12 июля в 22-00 по Москве, вы можете послушать новости о продукте StarWind Native SAN for Hyper-V, который позволяет построить недорогую инфраструктуру отказоустойчивых хранилищ на базе всего лишь двух серверов виртуализации, которые будут одновременно и хост-серверами и хранилищами, что позволит вдвое сократить затраты на оборудование. Итак, регистрируемся на вебинар "StarWind Solutions for Hyper-V Environments".

Зарегистрироваться.

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

Компания Veeam Software известна не только продуктом номер 1 Veeam Backup and Replication для резервного копирования виртуальных машин VMware vSphere и Microsoft Hyper-V, но и бесплатными средствами для управления виртуальной инфраструктурой, например, Veeam Backup Free (бывший FastSCP) или Veeam ONE Free Edition.

Одно из них - Veeam Extended Generic Report Library вышло совсем недавно. Это бесплатная библиотека из четырех отчетов, работающая на движке Microsoft SQL Server Reporting Services под Microsoft System Center Operations Manager 2007 R2 или Microsoft System Center 2012 Operations Manager, которая позволяет анализировать состояние и производительность объектов инфраструктуры – как для физической, так и для виртуальной среды. Библиотека может работать с любыми пакетами управления (MP): для создания подробных отчетов с возможностями, которые недоступны в стандартной библиотеке отчетов Microsoft System Center, достаточно настроить правила и задать нужные параметры отчетов.

Расширенная библиотека отчетов Veeam включает такие отчеты, как:

• Veeam Alert Statistics Report – анализ статистики срабатывания оповещений в двух режимах – по правилам/мониторам и по объектам (пример).
• Veeam Generic Performance Top (Bottom) N Report – визуальное представление объектов инфраструктуры, экземпляров, или и тех и других, для выбранного показателя производительности (пример).
• Veeam Performance Report – визуальное представление значений показателей производительности в диаграммах и таблицах (пример).
• Veeam Performance Details Report – анализ тенденций с помощью подробных данных о производительности (пример).

Скачать бесплатную библиотеку Veeam Extended Generic Report Library можно по этой ссылке.

Мы уже писали о новом механизме высокой доступности VMware High Availability (HA), который появился в VMware vSphere 5 и работает на базе агентов Fault Domain Manager (FDM). Как известно, вместо primary/secondary узлов в новом HA появились роли узлов - Master (один хост кластера, отслеживает сбои и управляет восстановлением) и Slave (все остальные узлы, подчиняющиеся мастеру и выполняющие его указания в случае сбоя, а также участвующие в выборе нового мастера в случае отказа основного).

В нашей статье об HA было описано основное поведение хостов VMware ESXi и кластера HA в случае различных видов сбоев, но Iwan Rahabok сделал для этих процессов прекрасные блок-схемы, по которым понятно, как все происходит.

Если хост ESXi (Slave) не получил хартбита от Master, которые он ожидает каджую секунду, то он может либо принять участие в выборах, либо сам себя назначить мастером в случае изоляции (кликабельно):

Если хост ESXi (Master) получает heartbeat хотя бы от одного из своих Slave'ов, то он не считает себя изолированным, ну а если не получает от всех, то он изолирован и выполняет Isolation Responce в случае, если нет пинга до шлюза. Работающим в разделенном сегменте сети он себя считает, когда он может пинговать шлюз. Проверка живости хостов (Slaves) производится не только по хартбитам, но и по datastore-хартбитам (кликабельно):

Все просто и понятно. Иван молодец.

Если у вас в виртуальной инфраструктуре большой набор хранилищ, хостов VMware ESXi и виртуальных машин, то легко не заметить один интересный момент - бесполезные vswp-файлы для виртуальных машин, размещенные в папке с ВМ. Выглядят они как <что-то там>.vswp.<номер чего-то там>:

Как видно из картинки, файлы эти не маленькие - размер vswp равен объему памяти, сконфигурированной для виртуальной машины (vRAM) без Reservation для RAM (если есть reservation, то размер vswp = vRAM - Reservation). Так вот эти файлы с номерами - это ненужный мусор. Образуются они тогда, когда хост ESXi падает в PSOD с запущенными виртуальными машинами.

Эти файлы, понятно дело, надо удалить. Для этого удобнее всего использовать PowerCLI:

dir vmstores:\ -Recurse -Include *.vswp.* | Select Name,Folderpath

Пример вывода мусорных файлов vswp с путями:

Ну а дальше сами знаете, что с ними делать.

На сайте проекта VMware Labs появилась новая интересная утилита Guest Reclaim, позволяющая уменьшить размер "тонкого" (thin provisioned) диска виртуальной машины из гостевой ОС Windows, истребовав нулевые блоки. Напомним, что когда тонкий диск виртуальной машины растет по мере наполнения данными, а потом вы эти данные в самой гостевой системе удаляете, его размер не уменьшается.

Один из способов уменьшить диск машины в VMware vSphere - это использовать утилиту sdelete для очистки блоко и перемещение виртуальной машины на другое хранилище средствами Storage vMotion. Однако, если вы прочтете нашу статью про datamover'ы при Storage vMotion и вспомните, что VMware vSphere 5 использует унифицированные блоки размером 1 МБ для всех хранилищ, то поймете, что этот способ больше не работает, поскольку в датамувере fs3dm не реализована процедура вычищения блоков целевого виртуального диска.

Есть конечно способ отключить fs3dm и, все-таки, уменьшить виртуальный диск машины на ESXi, однако это не очень удобная процедура. Поэтому сотрудники VMware и сделали удобную консольную утилитку Guest Reclaim, которая позволяет уменьшить диск с файловой системой NTFS.

Поддерживаются следующие гостевые ОС:

• Windows XP
• Windows Vista
• Windows 7
• Windows Server 2003
• Windows Server 2008

Запускать утилиту нужно из гостевой ОС, в которой есть диски, являющиеся тонкими. Чтобы просмотреть список тонких дисков используйте команду:

GuestReclaim.exe -list

Если ничего не найдено - значит первые 16 дисков не являются тонкими или у вас ESXi 5.0 и ниже (читайте дальше). VMware предлагает приступать к уменьшению диска, когда у вас разница между размером VMDK и файлами гостевой ОС хотя бы 1 ГБ, при этом для работы самой утилиты может потребоваться дополнительно 16-100 МБ свободного места. Также перед началом использования утилиты рекомендуется запустить дефрагментацию диска, на которую тоже может потребоваться свободное место (будет расти сам VMDK-файл).

Команда, чтобы уменьшить тонкий VMDK-диск за счет удаления нулевых блоков, выполняемая из гостевой ОС:

guestReclaim.exe --volumefreespace D:\

Еще одно дополнение - утилиту можно использовать и для RDM-дисков.

А теперь главное - утилита работает только в случае, если hypervisor emulation layer представляет гостевой ОС диски как тонкие. В VMware ESXi 5.0, где Virtual Hardware восьмой версии, такой возможности нет, а вот в ESXi 5.1, где уже девятая версия виртуального железа - такая возможность уже есть. Соответственно, использовать утилиту вы можете только, начиная с VMware vSphere 5.1 (бета сейчас уже у всех есть), а пока можно использовать ее только для RDM-дисков.

Из ограничений утилиты Guest Reclaim:

• Не работает со связанными клонами (Linked Clones)
• Не работает с дисками, имеющими снапшоты
• Не работает под Linux

Из дополнительных возможностей:

• Поддержка томов Simple FAT/NTFS
• Поддержка flat partitions и flat disks для истребования пространства
• Работа в виртуальных и физических машинах

FAQ по работе с утилитой доступен по этой ссылке. Скачать утилиту можно тут.

Мы уже писали о том, что в продукте номер 1 - vGate R2, предназначенном для защиты виртуальной инфраструктуры VMware vSphere, имеются, помимо всего прочего, втроенные средства контроля целостности и доверенной загрузки виртуальных машин. Реализуется это средствами одной из политик безопасности для хост-серверов VMware ESXi:

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

Однако надо помнить, что нужно защищать также и сами хост-серверы ESXi, находящиеся в датацентре компании. Для эффективной защиты сервера виртуализации, помимо vGate R2, необходим электронный замок - ПАК «Соболь» версии 3.0 для реализации следующих защитных механизмов:

• идентификация и аутентификация пользователей на входе в систему (непосредственно при запуске сервера);
• ведение журнала безопасности;
• сигнализация попыток нарушения защиты;
• запрет загрузки с внешних носителей;
• контроль конфигурации (PCI-устройств, ACPI, SMBIOS и оперативной памяти).

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

Так как, во-первых, злоумышленник столкнется с необходимостью идентификации/аутентификации до старта операционной системы, при этом реализованный механизм защиты от подбора паролей после трех неудачных попыток заблокирует сервер. Во-вторых, если злоумышленник, имея в распоряжении идентификационные данные, пройдет «первый барьер защиты», то на «втором» его будет ждать блокировка всех внешних устройств (CD-ROM, USB, eSata и т.д.), что исключает возможность загрузки нештатной ОС с любых внешних носителей.

Единственной недоступной возможностью при использовании ПАК «Соболь» версии 3.0 на сервере виртуализации, работающем под управлением VMware vSphere 5, является контроль целостности (КЦ) программной среды до загрузки ОС.

В руководящем документе ФСТЭК России нет разделения на КЦ в операционной системе или до ее старта, поэтому при использовании «тандема» vGate R2 и ПАК «Соболь» версии 3.0 требование 4.1. «Обеспечение целостности программных средств и обрабатываемой информации» будет выполнено средствами vGate R2.

Таким образом, применение обоих средств защиты информации – ПАК «Соболь» версии 3.0 и vGate R2 – в комплексе позволяет защитить сервер с установленной платформой для виртуализации VMware vSphere 5 и нейтрализовать угрозы непосредственного доступа (угрозы, реализуемые до загрузки ОС, и угрозы, реализуемые после загрузки ОС).

Наличие у продуктов сертификатов ФСТЭК России позволяет использовать vGate R2 и ПАК «Соболь» версии 3.0 для защиты информации, составляющей коммерческую или государственную тайну в автоматизированных системах с классом защищенности до 1Б включительно.

Напомним, что версия vGate R2 с поддержкой vSphere 5 уже поступила в продажу, а бесплатную пробную версию продукта можно скачать тут.

Как известно, виртуализация требует дополнительных ресурсов сверх тех, которые потребляет непосредственно виртуальная машина. Это называют накладными расходами на виртуализацию (так называемый virtualization overhead). Оверхэд есть как для процессора (примерно 3-5 процентов на хост-сервере), так и для оперативной памяти.

При этом для оперативной памяти накладные расходы гипервизора зависят от количества виртуальных процессоров (vCPU) и объема оперативной памяти, выделенных виртуальной машине. Мы уже писали о накладных расходах по RAM для виртуальных машин в VMware vSphere 4, где использовались следующие средние значения:

Информация эта взята из vSphere 4.0 Online Library.

В VMware vSphere 5 есть новая возможность, которая называется VMX Swap. При включении виртуальной машины гипервизор ESXi создает для нее vmx-процесс, управляющий различными структурами данных, под которые требуется физическая оперативная память. Ее объем, как было сказано, зависит от конфигурации ВМ - количества vCPU и RAM. Для снижения потребления этой памяти в ESXi 5.0 механизм VMX Swap создает swap-файл для сегментов данных процесса vmx, куда сбрасываются страницы памяти, но только в случае нехватки физической оперативной памяти на хосте.

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

sched.swap.vmxSwapDir

По умолчанию механизм VMX Swap включен и в критических ситуациях позволяет уменьшить overhead типичной виртуальной машины с 50 МБ до 10 МБ. Для виртуализации серверов такие порядки цифр может и не очень важны, зато для виртуализации настольных ПК (например, VMware View), где на одном сервере могут находиться десятки и даже сотни виртуальных машин, эта возможность может оказаться весьма кстати в условиях нехватки вычислительных ресурсов.

Если вы считаете, что ресурсов у вас достаточно и VMX Swap вам не нужен, можно его отключить, добавив значение FALSE в следующу расширенную настройку виртуальной машины:

sched.swap.vmxSwapEnabled

Ну а теперь посмотрим сколько оверхэда по памяти потребляет виртуальная машина уже в VMware vSphere 5 с включенным по умолчанию VMX Swap:

Эта информация уже из vSphere 5 Documentation Center. Как мы видим из таблицы, накладные расходы по памяти с учетом VMX Swap уже значительно меньше (в некоторых случаях до 8-9 раз). Как уверяют коллеги из VMware, в условиях недостатка ресурсов VMX Swap почти не влияет на производительность хост-сервера ESXi, ну а в условиях достатка - не влияет совсем.

На прошедшей конференции Google I/O 2012 было анонсировано много чего интересного: Android 4.1 Jelly Bean, планшет Nexus 7, медиаплеер Nexus Q, приняты предварительные заказы на Project Glass для разработчиков, анонсировано расширение магазина Google Play и прочее.

Но нас с вами интересует, конечно же, не это. Главная для нас новость - это анонс нового публичного IaaS-облака от интернет-гиганта, которое называется Google Compute Engine. На конференции было продемонстрировано приложение по обсчету генома, запущенное в кластере из 1250 виртуальных машин (у каждой 8 ядер) на этой платформе, что, возможно, намекает на направленность Google на сегмент "Big Data", а также научные и исследовательские задачи крупных компаний и университетов.

Google Compute Engine - это новый сервис аренды вычислительных сред в публичном облаке (IaaS) на базе ОС Linux, предоставляющий услуги на базе платы за почасовое потребление ресурсов (вычислительные мощности и хранилища). Поддержки Windows в данных вычислительных средах пока не заявлено. Напомним, что у Google уже есть PaaS-платформа App Engine и сервис облачного хранения Cloud Storage. Сам сервис Compute Engine (CE) доступен для пробного использования только по приглашениям (Limited Preview).

Таким образом, мы получаем трех потенциальных лидеров рынка IaaS-сервисов из публичного облака: старейший Amazon AWS, анонсированный в начале июня Microsoft Windows Azure и Google Compute Engine. Особняком стоит компания VMware, предоставляющая решения VMware vCloud, на базе которых любой сервис-провайдер может построить публичное облако. При этом VMware не скрывает своей направленности исключительно на крупный корпоративный сектор (сейчас существует около 125 сертифицированных публичных облаков vCloud от партеров VMware по программе VSPP в 26 странах, которые предлагают аренду виртуальных машин). Отметим также и решение Citrix Xen Cloud Platform от компании Citrix и сообщества Xen.

Основные особенности Google Compute Engine:

• Вычислительные среды. Доступны в конфигурации 1,2,4 или 8 ядер на Linux-платформе с 3,75 ГБ оперативной памяти на одно ядро.
• Хранилища. Можно хранить данные виртуальных машин в виде непостоянных (Ephemeral), а также постоянных (Persistent) дисков на стороне Google или в сервисе Google Cloud Storage. Для постоянных дисков можно делать снапшоты в целях резервного копирования, а также предоставлять доступ к одному диску со стороны нескольких ВМ. Все данные дисков шифруются.
• Сетевое взаимодействие. Возможность использовать высокопроизводительное сетевое оборудование датацетров Google и самостоятельно конфигурировать сетевые экраны, также использовать внешний IP-адрес. Плюс готовые решения от сторонних вендоров, которые выступают партнерами Google.
• Управление. Виртуальными машинами можно будет управлять через веб-консоль или CLI, также есть API, предоставляющий множество возможностей разработчикам и сторонним производителям.

Google Compute Engine будет интегрирован с партнерскими решениями RightScale, Puppet Labs,OpsCode, Numerate, Cliqr, MapR и другими.

Безусловно, Google вступает на рынок IaaS-решений довольно поздно. Но это только одна сторона медали - на самом деле, более 90% компаний вообще еще не пользовались облачными ресурсами уровня IaaS, поэтому потенциал рынка огромный. Также отметим возможную "нишевость" сервиса от Google, если он будет направлен на высокопроизводительные вычисления по цене существенно меньшей, чем у конкурентов.

Кстати, о цене. Заявленные цены выглядят так:

Значение GCEU (Google Compute Engine Units), которое вы видите в правой колонке - это аналог Amazon EC2 Compute Unit (как написано тут), т.е. где-то эквивалент 1.0-1.2 ГГц на процессорах 2007 Opteron or 2007 Xeon.

Также на сайте thenextweb.com проведено сравнение анонсированных цен на Google Compute Engine и уже объявленных Microsoft на Windows Azure. По расчетам получается, что при где-то одинаковой цене мощностей Google Compute Engine и Windows Azure, сервис от Google дает на 50% больше оперативной памяти для ВМ.

В последнее время стало модным предоставлять виртуальные машины в аренду по модели IaaS. Этим занимается VMware со своей платформой vCloud в корпоративных инфраструктурах, а также Amazon, Microsoft и Google - в публичных облаках. Программы для облачных провайдеров есть также и поставщиков сопутствующих продуктов в сфере виртуализации, например, у Veeam и Кода Безопасности.

Теперь и компания StarWind позволяет провайдерам услуг использовать в датацентрах свои продукты StarWind iSCSI SAN и StarWind Native SAN for Hyper-V (статьи о продуктах тут и тут).

Напомним, что продукты StarWind позволяют создавать отказоустойчивые конфигурации хранилищ на базе iSCSI для виртуальных машин VMware vSphere, Microsoft Hyper-V и Citrix XenServer. При этом не требуется инвестиций в дорогостоящие хранилища Fibre Channel и сетевую инфраструктуру SAN, что делает продукты StarWind наиболее эффективными с точки зрения стоимости владения и единовременных капитальных затрат на создание инфраструктуры датацентра.

Кроме того, StarWind это:

• Динамическое масштабирование хранилищ "на лету"
• Отказоустойчивая конфигурация из двух или трех узлов кластера хранилищ
• Использование существующих серверов и хранилищ данных
• Простое администрирование решения
• Встроенные механизмы дедупликации и резервного копирования виртуальных машин

Тем, кого заинтересовала программа IaaS у компании StarWind, необходимо обратиться по адресу sales@starwindsoftware.com.