Как известно, в VMware vSphere 5 появилось несколько полезных нововведений, касающихся сетевого взаимодействия, доступных в распределенном коммутаторе VMware vSphere Distributed Switch (vDS), которые облегчают жизнь сетевым администраторам. В частности, посредством dvSwitch доступны следующие новые возможности, которые описаны в документе "What's New in VMware vSphere 5.0 Networking":

• Поддержка Netflow версии 5 - возможность просмотра трафика между виртуальными машинами (ВМ-ВМ на одном или разных хостах, а также ВМ-физический сервер) посредством сторонних продуктов, поддерживающих Netflow.
• Поддержка зеркалирования портов Switch Port Analyzer (аналог технологии SPAN в коммутаторах Cisco) - возможность дублировать трафик виртуальной машины (а также VMkernel и физических адаптеров) на целевую машину (Port Mirroring), которая может реализовывать функционал системы обнаружения или предотвращения вторжений (IDS/IPS).
• Поддержка открытого стандарта Link Layer Discovery Protocol (LLDP, в реализации 802.1AB) - это механизм обнаружения соседних сетевых устройств и сбора информации о них для решения различных проблем сетевыми администраторами. Ранее поддерживался только протокол CDP (Cisco Discovery Protocol), поддержка которого есть не во всех устройствах.
• Улучшения механизма Network I/O Control - пулы ресурсов для сетевого трафика и поддержка стандарта 802.1q. Опредлеямые пользователем пулы для различных типов трафика позволяют приоритезировать и ограничивать пропускную способность канала для них посредством механизма shares и limits.

Все эти новые возможности мы разберем в следующих заметках, а сегодня сосредоточимся на механизме Netflow и его поддержке в vSphere 5. NetFlow — сетевой протокол, предназначенный для учёта сетевого трафика, разработанный компанией Cisco Systems. Является фактическим промышленным стандартом и поддерживается не только оборудованием Cisco, но и многими другими устройствами.

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

• Сенсор. Собирает статистику по проходящему через него трафику. Обычно это L3-коммутатор или маршрутизатор, хотя можно использовать и отдельно стоящие сенсоры, получающие данные путем зеркалирования порта коммутатора. В нашем случае это распределенный коммутатор vDS.
• Коллектор. Собирает получаемые от сенсора данные и помещает их в хранилище.
• Анализатор. Анализирует собранные коллектором данные и формирует пригодные для чтения человеком отчёты (часто в виде графиков).

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

Синяя линия на картинке показывает настроенный виртуальный коммутатор, который посылает данные Netflow на стороннюю машину (коллектор), которая подключена к хост-серверу VMware ESXi через физический коммутатор. Коллектор уже передает данные анализатору. Netflow может быть включен на уровне отдельной группы портов (dvPortGroup), отдельного порта или аплинка (Uplink).

Для начала настройки Netflow нужно зайти в свойства коммутатора vDS (он должен быть версии 5.0.0 или выше):

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

Включить мониторинг Netflow можно в свойствах группы портов на vDS в разделе Monitoring:

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

Теперь можно использовать один из продуктов для сбора и анализа трафика Netflow, например, Manage Engine Netflow Analyzer. Пример статистики, которую собирает этот продукт по протоколам (в данном случае большинство трафика - http):

Netflow можно использовать для различных целей мониторинга, например, в инфраструктуре VMware View, где присутствуют сотни виртуальных машин, можно сгруппировать трафик по группам и смотреть, сколько трафика выжирается видеосервисами (Youtube, к примеру), так как это может сильно влиять на производительность сети в целом:

Применений Neflow на самом деле уйма, поэтому его поддержка в VMware vSphere 5 может оказаться вам очень полезной.

Раньше блоггеры публиковали диаграммы портов и соединений для VMware vSphere и других продуктов по отдельности, о которых мы писали тут и тут. Для VMware vSphere 5 список портов стал настолько обширен (из-за увеличения количества компонентов), что блоггеры уже перестали рисовать картинки и диаграммы.

Напомним, что последнюю версию схемы портов для VMware vSphere 4.1 можно скачать вот тут:

Теперь же сетевым администраторам и администраторам ИБ нужно запомнить вот эту ссылку на статью: KB 1012382, где приведены порты, используемые не только VMware vSphere 5, но и другими продуктами VMware: View, SRM, Converter и пр. Там в таблице конечно мешанина, но ничего другого пока нет:

Для каждого порта приведены комментарии - зачем он нужен и когда используется. Обратите внимание, что порты для vSphere Client указаны внизу статьи.

Как вы знаете, компания Код Безопасности, выпускающая продукт номер 1 для защиты виртуальных сред vGate R2 (читаем тут и тут), выпускает еще несколько программных и аппаратных решений для защиты физической и виртуальной инфраструктуры (см., например, тут).

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

Надо сказать, что TrustAccess - это один из тех продуктов, которые позволят защитить виртуальную инфраструктуру vSphere, в которой обрабатываются персональные данные, согласно требованиям закона ФЗ 152. То есть его можно и нужно использовать совместно с продуктом vGate.

Чтобы понять как все это делать, приходите на вебинар "Защита виртуальных машин от сетевых угроз с помощью межсетевого экрана TrustAccess", который пройдет 30 ноября в 11:00 по московскому времени:

Многие из вас используют продукт номер 1 для создания отказоустойчивых хранилищ StarWind Enterprise, позволяющий предоставлять общие хранилища для виртуальных машин через iSCSI. Это очень хорошая технология для небольших компаний и филиалов, использующих VMware vSphere, но не могущих себе позволить полноценную систему хранения с дублированными аппаратными компонентами. Напомним, что скоро продукт будет доступен для двухузловой конфигурации Microsoft Hyper-V, а также выйдет версия StarWind 5.8, где обещают еще больше нововведений.

Некоторые пользователи применяют доступ к таргетам iSCSI для StarWind изнутри виртуальных машин (например, можно использовать бесплатное издание StarWind). Однако с VMware vSphere 5 и адаптером vmxnet3 обнаружилась интересная проблема - согласно KB 2006277, драйвер vmxnet3 из комплекта vSphere 5 некорректно работает с большими кадрами Jumbo Frames. Это приводит к деградации производительности и потере сетевого соединения.

Какие есть выходы:

• Использовать драйвер vmxnet3 из комплекта VMware Tools для версии vSphere 4.x (можно загрузить тут)
• Использовать виртуальный сетевой адаптер vmxnet2 (Enhanced) или E1000 из комплекта vSphere 5

Надо отметить, что при соединении серверов ESXi 5 с хранилищами StarWind с настроенными Jumbo Frames полностью поддерживается. Также все работает и в конфигурации с томами RDM для виртуальных машин в режиме физической и виртуальной совместимости.

Компания VMware работает над решением проблемы для адаптера vmxnet3 и Jumbo Frames при работе из гостевой ОС. Спасибо Константину Введенскому за новость.

Мы уже писали о новом продукте VMware vSphere Storage Appliance (VSA), который позволяет создать кластер хранилищ на базе трех серверов (3 хоста ESXi 5 или 2 хоста ESXi 5 + физ. хост vCenter), а также о его некоторых особенностях. Сегодня мы рассмотрим, как работает кластер VMware VSA, и как он реагирует на пропадание сети на хосте (например, поломка адаптеров) для сети синхронизации VSA (то есть та, где идет зеркалирование виртуальных хранилищ).

На проходящей конференции VMworld 2011 в Лас-Вегасе за прошедший день было сделано несколько интересных анонсов. Три из них кажутся наиболее важными.

1. Проект VMware Appblast.

Это новый проект VMware, который позволит открывать виртуализованные с помощью ThinApp приложения в любом веб-браузере, совместимом с HTML 5 и Java. Совместно с VMware Horizon App Manager, технология VMware Appblast позволит организовать доставку приложений упакованных ThinApp на любое устройство пользователя, включая планшеты iPad или коммуникаторы на базе Android.

2. Технология сетевого взаимодействия VXLAN (Virtual eXtensible LAN).

Это уровень абстракции Layer 2 для доступа к виртуальным машинам вне зависимости от их расположения. Технология, разработанная совместно с компанией Cisco, использует технологию инкапсуляции "MAC-in-UDP" для создания схемы взаимодействия виртуальных машин, которые могут перемещаться между разными датацентрами со своими физическими сетями и адресацией. В случае применения VXLAN ничего не нужно будет менять с точки зрения сетевой идентификации ВМ в случае ее перезда, например, в другой датацентр (к примеру, сервис-провайдера).

Более подробно о VXLAN вы можете прочитать здесь.

3. Проект VMware Octopus.

Многие знают, что такое сервис Dropbox. Это облачное хранилище данных, но относительно которого есть сомнения в надежности и безопасности. VMware Octopus - это некий аналог Dropbox, т.е. онлайн-хранилище данных, которое позволит крупным предприятиям организовать облачное хранение данных с необходимым уровнем доступности, надежности и безопасности.

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

Скоро об этом обо всем - подробнее.

Компания VMware в июле 2011 года объявила о доступности новых версий целой линейки своих продуктов для облачных вычислений, среди которых находится самая технологически зрелая на сегодняшний день платформа виртуализации VMware vSphere 5.0.

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

Некоторым из вас должен быть знаком проект pfSense, который представляет собой разработку программного фаервола и роутера на базе дистрибутива FreeBSD. Это средство есть также в виде виртуального модуля (Virtual Appliance), которое можно импортировать в VMware vSphere в качестве уже готовой машины. Также Eric Sloof сделал его в в формате OVA.

Естественно, pfSense - это бесплатно и open source. Для продукта доступно огромное количество модулей, за счет которых можно расширять функционал.

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

Кстати, важная новость. Вышел vGate 2 с полной поддержкой VMware ESXi 4.1 (об этом мы писали тут, но продукт был еще в бете). Скачать vGate 2 для VMware ESXi можно тут.

Но сегодня мы поговорим о том, как было бы неплохо организовать безопасную инфраструктуру доступа системных администраторов VMware vSphere к различным компонентам среды виртуализации. Это нужно для того, чтобы понимать как правильно наладить контроль за серверами ESX / ESXi и виртуальными машинами со стороны vGate, а также разграничить доступ к этим объектам в рамках зон ответственности администраторов vSphere.

Логичной выглядит следующая схема построения локальной сети в контексте доступа к компонентам виртуальной инфраструктуры:

Немного опишем ее:

• Выделяем на уровне домена безопасности отдельно сеть администрирования инфраструктуры vSphere. Она содержит серверы ESX / ESXi, сервер vCenter, а также сервер авторизации vGate. Сам сервер авторизации имеет два сетевых адаптера - одним он смотрит в сети администрирования vSphere, а другим во внешнюю сеть предприятия, где находятся рабочие станции администраторов. Таким образом из последней сети в сеть управления можно попасть исключительно через сервер авторизации vGate (компоненты vGate выделены зеленым). На рабочих местах администраторов vSphere и администратора ИБ также установлены клиентские компоненты vGate.
• В отдельную подсеть нужно выделить сеть репликации ВМ (та, что для vMotion и Fault Tolerance).
• В отдельную подсеть выделяем сеть для IP-хранилищ (NFS/iSCSI).
• Ну и, само собой, сеть виртуальных машин тоже должна быть отдельной. Разделение сетей на хостах ESX / ESXi лучше делать на базе тегирования на уровне виртуального коммутатора (см. виды тэгирования).

Если взглянуть на разделение сетей со стороны сетевых адаптеров хост-сервера ESX сервера авторизации vGate, мы получим такую картину:

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

Вот основные варианты настройки маршрутизации (АВИ - это администратор виртуальной инфраструктуры):

Вот собственно и основные правила.

Как вы знаете, в механизме высокой доступности VMware High Availability (HA) есть такая настройка как Isolation Responce, которая определяет, какое событие следует выполнить хосту VMware ESX / ESXi в случае наступления события изоляции для него в кластере (когда он не получает сигналов доступности - Heartbeats - от других хост-серверов).

• Leave powered on
• Power off
• Shutdown

Сделано это для того, чтобы вы могли выбрать наиболее вероятное событие в вашей инфраструктуре:

• Если наиболее вероятно что хост ESX отвалится от общей сети, но сохранит коммуникацию с системой хранения, то лучше выставить Power off или Shutdown, чтобы он мог погасить виртуальную машину, а остальные хосты перезапустили бы его машину с общего хранилища после очистки локов на томе VMFS или NFS (вот кстати, что происходит при отваливании хранища).
• Если вы думаете, что наиболее вероятно, что выйдет из строя сеть сигналов доступности (например, в ней нет избыточности), а сеть виртуальных машин будет функционировать правильно (там несколько адаптеров) - ставьте Leave powered on.

Но есть еще один момент. Как вам известно, VMware HA тесно интегрирована с технологией VMware Fault Tolerance (непрерывная доступность ВМ, даже в случае выхода физического сервера из строя). Суть интеграции такова - если хост с основной виртуальной машиной выходит из строя, то резервный хост выводит работающую резервную ВМ на себе "из тени" (она становится основной), а VMware HA презапускает копию этой машины на одном из оставшихся хостов, которая становится резервной.

Так вот настройка Isolation Responce не применяется к машинам, защищенным с помощью Fault Tolearance. То есть, если хост VMware ESX с такой машиной становится изолированным, при настройке Power off или Shutdown он такую машину не гасит, а всегда оставляет включенной.

Рекомендация - иметь network redundancy для сети heartbeats. Не должен хост себя чувствовать изолированным, если он весь не сломался.

Несколько дней назад компания Citrix объявила о выходе очередного обновления Feature Pack 1 своей платформы виртуализации XenServer 5.6. Этот релиз имеет множество новых интересных возможностей, наиболее важной из которых является возможность использования виртуального распределенного коммутатора (в том числе и на базе Open vSwitch).

Список новых возможностей Citrix XenServer 5.6 Feature Pack 1:

• Distributed Virtual Switching.  Эта возможность позволяет использовать средства управления распределенным сетевым взаимодействием хост-серверов и виртуальных машин (например, cross-host private networks - аналог PVLAN на dvSwitch в VMware vSphere). Также поддерживается устройство Open vSwitch (OVS) для хостов XenServer hosts, а также компонент Controller для управления несколькими vSwitches (сам Controller есть только в издании Premium). Open vSwitch включает в себя поддержку больших кадров Jumbo Frames, позволяющих добиться наибольшей производительности в сетях хранения на базе iSCSI. При этом Open vSwitch пока не поддерживает агрегацию каналов (Link Aggregation).
• VM Protection & Recovery - использование снятия мнгновенных снимков (снапшотов) и экспорта виртуальных машин по расписанию. Новая версия XenServer включает в себя простую утилиту для бэкапа виртуальных машин и их восстановления (из снапшота). При этом дифференциальные снапшоты не поддерживаются (будет в следующих версиях). В бесплатной версии этой функциональности нет.
• Web Self-Service. Портал самообслуживания для пользователей виртуальных машин на основе привилегий, определенных администратором. Создание машин прямо из портала пока не поддерживается (будет потом).
• Boot from SAN with multi-pathing support.  Возможность загрузки хостов XenServer через HBA-адаптер Fibre channel из сети SAN.
• HA Restart Priority. Возможность настройки политик механизма отказоустойчивости таким образом, чтобы расставить приоритеты по старту виртуальных машин отказавшего хост-сервера (например, для вспомогательных ВМ StorageLink Gateway VM или Distributed vSwitch Controller VM, которые должны запуститься сначала).
• Improved XenDesktop VDI scalability. Улучшения под виртуализацию настольных ПК (VDI) - увеличение коэффициента консолидации виртуальных машин на хост-серверах посредством использования компонентом control domain (Dom0) нескольких процессоров и других улучшений.
• Enhanced XenCenter. Улучшенные средства управления XenCenter, включая полностью конфигурируемый StorageLink, отчетность об использовании ВМ и даже возможности подсчета затрат на виртуальную инфраструктуру (chargeback).
• Improved MPP RDAC multi-pathing - отчетность о статусе пути в конфигурации с несоколькими путями к СХД, а также отчетность и возможность срабатывания оповещений (health reporting and alerting).
• Snapshot improvements. После удаления снапшота - на системе хранения все аккуратно подчищается.
• Enhanced guest OS support - лучше работают: Windows 7 SP1, Windows Server 2008 R2 SP1, RHEL 6.0 (RTM), CentOS 6.0 (RTM), Oracle Enterprise Linux 6.0 (RTM), Debian Squeeze (32 and 64-bit) и SLES 11 SP1.
• Generic RHEL 5.x support. RHEL / CentOS / Oracle Enterprise Linux 5.0- 5.5 support with a generic "RHEL 5" template.
• Драйверы Brocade HBA - а также утилиты командной строки включены в XenServer.
• Provisioning Services Improvements. Есть поддержка Windows volume license (MAK и KMS) при развертывании виртуальных машин.
• XenDesktop platform enhancements. Технология локального кэширования образов виртуальных машин для экономии дискового пространства в инфраструктуре виртуальных ПК (VDI). Будет использоваться в следующей версии Citrix XenDesktop.

Скачать Citrix XenServer 5.6 FP1 (включая бесплатную версию) можно по этой ссылке.

На днях компания Citrix сделала доступным бесплатное средство для мониторинга производительности хост-серверов виртуализации Citrix XenServer Virtual Machine Performance Utility.

Данное ПО поставляется в виде виртуальной машины для развертывания на XenServer, которая позволяет отслеживать производительность сетевого взаимодействия и работу виртуальных машин с хранилищами (storage I/O и network I/O). Через веб-интерфейс можно получить информацию о следующих аспектах производительности:

Disk I/O performance utility - предоставляет следующую информацию: sequential read/writes и random read/writes с различными размерами блоков.

Network I/O performance utility - это модифицированная версия утилиты netperf. Позволяет мониторить пропускную способность сети и задержки.

Скачать Citrix XenServer Virtual Machine Performance Utility можно по этой ссылке.

Компания 5nine, известная своим программным обеспечениям для платформы виртуализации Hyper-V, выпустила вторую версию продукта Virtual Firewall 2.0 for Hyper-V. Этот продукт позволяет организовать виртуальный сетевой экран в инфраструктуре виртуальных машин.

Возможности продукта:

• Controls Network Traffic – используя скрипты PowerShell API или в GUI, администратор может определить различные правила фаервола для различных типов траффика, идущего к сети виртуальных машин серверов Hyper-V, а также в сети между виртуальными машинами, что позволяет организовать защиту от внешних и внутренних угроз.
• Security Heartbeat Service – сервис, позволяющий в реальном времени проверять правила фаервола, и, если происходит подозрительная активность со стороны виртуальной машины, может выключить или приостановить данную ВМ.
• Deployment options – 5nine Virtual Firewall может быть использован совместно с Microsoft System Center Virtual Machine Manager для виртуальных машин, а также для физических серверов перед P2V-миграцией.
• Compliance Audits – возможность проведения аудита (отчеты) на соответствие политикам безопасности траффика в виртуальной инфраструктуре.

Скачать 5nine Virtual Firewall for Hyper-V можно по этой ссылке.

Бывает так, что необходимо регламентировать процедуру тестирования отказоустойчивости сетевых интерфейсов VMware ESX (NIC Teaming). В этом случае проверку Network Failover Maish Saidel-Keesing предлагает проводить так:

1. Отключаем один из физических NICs сервера VMware ESX для которого настроен Failover Order, переводя его в режим "10 Half-Duplex ":

[root@esx1 ~]#esxcfg-nics -s 10 -d half vmnic2

2. Видим, что интерфейс отключился:

3. Перед этим запускаем пинги из виртуальной машины, где наблюдаем их потерю из-за "отказа" сетевого адаптера ESX. Потом соединение должно восстановиться по резервному NIC сервера ESX:

4. Включаем интерфейс, переводя его в режим Auto Negotiate:

[root@esx1 ~]# esxcfg-nics -a vmnic2

Если у вас есть 2 виртуальные машины на платформе VMware vSphere / ESX, но они находятся на разных виртуальных коммутаторах (vSwitch) и в разных сетях, то просто передать между ними (или на них) файлы по сети не получится. Здесь на помощь приходит смекалка:

1. Можно создать ISO-образ с необходимыми файлами и положить его на общее хранилище VMFS. Затем можно монтировать этот ISO-образ к той виртуальной машине, на которую необходимо скопировать файлы.

2. Можно подцепить к виртуальной машине VMDK-диск, на который залить нужные файлы, затем этот vmdk можно будет отцепить от первой виртуальной машины и подцеплять к другим ВМ. Помните, что Hot Add виртуального диска в VMware vSphere есть, а вот Hot Remove - не работает, надо будет останавливать виртуальную машину.

3. Можно создать новую виртуальную машину с двумя виртуальными сетевыми интерфейсами (vNIC), один из которых будет "смотреть" в Network одной виртуальной машины, а другой vNIC, соответственно - в Network другой (по-сути роутер).