Обзор Citrix XenServer vSwitch Controller

Одним из нововведений, появившихся в Citrix XenServer 5.6 SP1, стал vSwitch Controller - специализированный управляющий виртуальный сервер (Virtual Appliance), расширающий функционал виртуальных коммутаторов XenServer.

После установки vSwitch Controller у администратора появляется возможность анализировать сетевой трафик с помощью RSPAN, собирать статистику (Netflow), настраивать списки контроля доступа (ACL - Access Control List), ограничивать исходящий трафик ВМ и настраивать частные виртуальные сети между несколькими хостами XenServer (Cross-Server Private Network).

Citrix XenServer 6.0 не принес никаких изменений в функционал vSwitch Controller за исключением добавления дополнительного режима применения ACL для виртуальных коммутаторов (Fail-Open) на случай выхода из строя управляющего сервера.

Рассмотрим подробнее возможности контроллера.

Возможности vSwitch Controller
vSwitch Controller доступен в редакции Citrix XenServer Advanced и выше. Процедура установки управляющего сервера крайне проста - достаточно загрузить образ ВМ в формате .xva с сайта Citrix, импортировать его, используя XenCenter, запустить и выполнить первоначальную настройку, задав сетевые настройки и пароль администратора.

Управление контроллером осуществляется через Web-интерфейс (из CLI виртуальной оснастки доступны всего несколько команд, задающих сетевые настройки и позволяющие выключить или перезагрузить ВМ).

Для управления серверами XenServer требуется добавить их в пул ресурсов (Resource Pool), один контроллер может управлять несколькими пулами, но у каждого пула может быть только один управляющий контроллер.

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

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

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

Для детального анализа сетевого трафика предназначен RSPAN, который позволяет дублировать весь траффик, проходящий через определенную виртуальную сеть, виртуальную машину или виртуальный сетевой адаптер, и помечать его определенным VLAN ID. Создав отдельную виртуальную сеть с аналогичным VLAN ID, вы сможете анализировать его с помощью ВМ с программой для мониторинга, например: Microsoft Network Monitor или Wireshark.

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

Правила можно задавать на нескольких уровнях: глобальном, уровне пула ресурсов, виртуальной сети, виртуальной машины, виртуального сетевого адаптера. Кроме того, почти на всех уровнях можно задавать два типа правил - стандартные (Default) и обязательные (Mandatory). Обязательные правила всегда имеют приоритет над стандартными. При обработке пакета происходит сверка со списком правил, пока не будет найдено подходящее правило, после чего пакет принимается или отбрасывается. Порядок проверки правил следующий:

1. Обязательные правила на глобальном уровне.
2. Обязательные правила на уровне пула ресурсов.
3. Обязательные правила на уровне виртуальной сети.
4. Обязательные правила на уровне виртуальной машины.
5. Правила на уровне виртуального адаптера.
6. Стандартные правила на уровне виртуальной машины.
7. Стандартные правила на уровне виртуально сети.
8. Стандартные правила на уровне пула ресурсов.
9. Стандартные правила на глобальном уровне.

При использовании списков контроля доступа следует учитывать один важный момент. В случае недоступности контроллера (например при его выключении), все ACL перестают применяться, и ВМ могут беспрепятственно отправлять и получать пакеты. Такой режим носит название fail-open и в XenServer 6.0 используется по умолчанию. Альтернательный режим fail-safe, доступный еще в XenServer 5.6 SP1, обеспечивает большую безопасность и позволяет сохранить ACL для существующих ВМ при недоступности контроллера, однако имеет ряд побочных эффектов. Например, при смене IP адреса у ВМ, все входящие и исходящие пакеты начинают блокироваться, тоже самое происходит при создании и добавлении новых ВМ в пул или подключении виртуальных адаптеров к существующим ВМ, или миграции ВМ с помощью XenMotion между хостами. Наконец, если хост XenServer перезагрузится и контроллер все еще будет недоступен, все закешированные ACL будут удалены, и весь трафик ВМ будет запрещен. Так что будьте крайне осторожны с данным режимом.

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

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

Частные сети создаются из консоли XenCenter.

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

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

Заключение
Как видите, vSwitch Controller предоставляет администраторам серверов виртуализации достаточно интересные возможности по мониторингу и контролю сетевого трафика, сравнимые с возможностями, доступными в решениях конкурента - VMware vNetwork Distributed Switches и VMware vShield App, и категорически рекомендуется к развертыванию при наличии соответствующих лицензий на Citrix XenServer. Однако, следует помнить, что vSwitch Controller не имеет встроенных механизмов обеспечения отказоустойчивости, поэтому повышать доступность ВМ придется сторонними средствами.

Hitachi Data Protection Suite и VMware vSphere 5

Есть такой продукт для резервного копирования - Hitachi Data Protection Suite (он же CommVault Simpana), который помимо всего прочего умеет бекапить виртуальные машины VMware vSphere. Оказывается, что при работе с VMware vSphere 5.0 у него есть определенные проблемы.

Во-первых, если вы используете хранилище с VMFS 5, то резервное копирование ВМ в режиме SAN будет завершаться с ошибкой: "Error opening virtual machine disk".

В качестве временного решения можно переключиться в режим NBD или NBD SSL (бекап по сети).

Чтобы исправить данную проблему вам потребуется установить на сервер с media агентом обновленную версию VMware vSphere 5.0 Virtual Disk Development Kit (загрузить можно с сайта VMware).

Во-вторых, при попытке восстановления отдельных файлов ВМ или всей ВМ целиком, задача также завершается с ошибкой, что недоступна сеть или сетевая служба. В журнале событий по этому поводу можно найти сообщение: "Either the application has not called WSAStartup, or WSAStartup failed.". Что интересно, проблема возникает только на Windows Server 2008 (x86 или x64), и единственный известный мне способ ее решения - установить CommVault на Windows Server 2008 R2.

VMware VCP 5

На прошлой неделе у меня появилось немного свободного времени, поэтому я решил обновиться до VCP 5. Благо, как и в случае апгрейда VCP 3 -> VCP 4, все, что требуется нынешним обладателям статуса - это успеть до февраля сдать экзамен VCP-510.

Экзамен все также сдается в тестовых центрах VUE (я сдавал в Москве, в УЦ Softline) и стоит 175$ за попытку сдачи. Экзамен включает в себя 85 вопросов, на которые отводится 90 минут (+30 минут для тех, у кого английский не родной язык, а также +15 минут на предварительный опрос).

Экзамен достаточно сильно отличается от VCP-410. Во-первых, он стал сложнее. Если в предыдущем экзамене мне попалось достаточно много вопросов на максимумы и на командную строку, то в новом их было от силы штук 5 (возможно мне так повезло).

Во-вторых, поменялся подход - теперь в вопросах частенько описывают некую ситуацию или показывают картинку и спрашивают "что следует делать?". Т.е. текста, который требуется прочитать и понять стало больше. В итоге первый прогон мне удалось завершить за 1.5 часа, так что дополнительное время оказались как нельзя кстати.

В-третьих, в отличии от VCP-410 мне не встретилось ни одного вопроса по VMware vShield, VMware vCenter Orchestrator или VMware SRM, но было много вопросов по новым технологиям и продуктам, появившимся в vSphere 5. Многие вопросы строятся на знании отличий 4-й версии от 5-ки.

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

При подготовке я пользовался документацией с сайта и VMware VCP510 Exam Blueprint. В качестве тестовых вопросов я использовал VCP on vSphere 5 Mock Exam и VCP5 Practice Exams, но оба оказались довольно далеки от вопросов в реальном экзамене.

Итоговый результат: 400 из 500 возможных, с чем себя и поздравляю.

P.S. интересно, как скоро VMware обновит VCAP до 5-ой версии? :-)

VMware vSphere Storage APIs for Storage Awareness для СХД HP

Одним из нововведений, появившихся в vSphere 5.0, стал vSphere Storage APIs for Storage Awareness (VASA), позволяющий администратору упростить процедуру выбора хранилища для размещения виртуальных машин. Если раньше администратор мог полагаться только на свою хорошую память, либо на политику именования хранилищ, что, как правило, могло приводило к названиям вроде "01_HP_P2000G3_iSCSI_RAID5_SAS_NOREPL_LUN0", то теперь стало возможным видеть и другие параметры хранилища (т.н. Storage Capabilities, например: интерфейс подключения СХД, уровень RAID массива, поддержка репликации, физическое расположение, поддержка "тонких" томов и т.п.) прямо из интерфейса vSphere Client.

Все параметры хранилища разделяются на два типа: системные (system), определяемые производителем системы хранения, и пользовательские (user-defined), задающиеся администратором виртуальной инфраструктуры. Для каждого хранилища может быть предопределено несколько системных параметров и только один пользовательский параметр.

Для отображения параметров хранилища требуется зарегистрировать провайдера (Storage Provider) соответствующего производителя СХД. Так, например, для СХД производства HP (HP Storageworks P2000, P4000, EVA, XP) служба провайдера входит в состав HP Insight Control Storage Module for vCenter версии 6.3 и выше, который доступен для загрузки с сайта HP.

Инсталляция HP Insight Control Storage Module довольно проста и не требует никаких специфичных навыков. После установки вам потребуется выполнить базовые настройки интеграции в Insight Control for vCenter Setup Wizard и добавить ваши СХД с помощью Storage Administrator Portal.

Далее с помощью клиента VMware vSphere зарегистрируйте HP Insight Control Storage Module в окне Storage Providers.

Вам потребуется указать URL к серверу в формате "HTTPS://<ИМЯ_СЕРВЕРА>:<ПОРТ>/vasa_provider_ws/vasaService" (порт по умолчанию: 3518), на котором установлен HP Insight Control Storage Module, а также учетные данные для подключения.

После завершения настройки в свойствах каждого хранилища появятся соответствующие ему системные параметры.

Кроме того, вы сможете создавать профили хранилищ, используя соответствующие системные параметры.

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

Аналогично при переносе виртуальной машины с одного хранилища на другое.

Загрузка VMware ESXi по iSCSI

Одним из нововведений, появившихся в VMware ESXi 4.1, стала возможность загрузки с iSCSI хранилищ с помощью сетевых адаптеров, поддерживающих iBFT (iSCSI Boot Firmware Table) и VMware Software iSCSI Initiator.

Однако, будьте внимательны если планируете использовать подобный вариант загрузки в VMware ESXi 5.0.

Так, например, с серверами HP Proliant BL460c G6 с интегрированными адаптерами NC532i (они же Broadcom NetXtrem II BCM57711E) такой вариант может не заработать. Причина заключается в том, что в новой версии ESXi, в качестве типа разметки диска используется GPT, а не MBR. Существующая версия загрузчика iSCSI Boot (v4.2.10) не поддерживает GPT диски, выводя при загрузке сообщение: [iBoot-04]: Bootable partition is not found.

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

Переполнение базы VMware vCenter из-за vSphere Management Assistant

Недавно мы столкнулись с проблемой черезмерного роста базы VMware vCenter Server.

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

По коду ошибки удалось определить и устранить проблему, однако, после перезагрузки никаких журналов событий на сервере ESXi не сохранилось. Было решено вести централизованный сбор журналов с помощью vSphere Management Assistant. Сказано - сделано, несколько команд в консоли (решили заодно собирать журналы с сервера vCenter), проверка, что журналы в vMA обновляются, и о проблеме забыли. Пока через несколько дней внезапно не отключился vCenter Server.

Журнал приложений в Windows показал, что база vCenter заняла максимально возможные 10 Гб (в качестве СУБД мы используем Microsoft SQL Server 2008 R2 Express Edition), что, собственно, и послужило причиной остановки vCenter.

С помощью сценария мы быстро определили размер всех таблиц в базе.

SET NOCOUNT ON

DBCC UPDATEUSAGE(0)

-- DB size.
EXEC sp_spaceused

-- Table row counts and sizes.
CREATE TABLE #t
(
[name] NVARCHAR(128),
[rows] CHAR(11),
reserved VARCHAR(18),
data VARCHAR(18),
index_size VARCHAR(18),
unused VARCHAR(18)
)

INSERT #t EXEC sp_msForEachTable 'EXEC sp_spaceused ''?'''

SELECT *
FROM #t

-- # of rows.
SELECT SUM(CAST([rows] AS int)) AS [rows]
FROM #t

DROP TABLE #t

Самыми большими оказали таблицы VPX_EVENT и VPX_EVENT_ARG - вместе с индексами они занимали более 9.5 Гб. С кем не бывает - подумали мы, хотя и усомнились, т.к. наша тестовая лаборатория не такая большая, чтобы в журналах сохранялось так много событий.

Для очистки таблиц мы использовали сценарий с сайта VMware:

TRUNCATE table VPX_EVENT_ARG
DELETE FROM VPX_EVENT 

Если вы планируете последовать нашему примеру - приготовьтесь к тому, что выполнение сценария потребует много времени и приведет к существенному увеличению размера журналов базы (в конце статьи приведен альтернативный сценарий). Поскольку в качестве Recovery Model установлен режим Simple, то после завершения операции мы сделали Shrink Database, и база уменьшилась до 350 Мб.

Однако, через некоторое время после включения служб vCenter база снова стала расти гигантскими темпами. Для определения причины проблемы заглянули vCenter Server log и обнаружили огромное количество записей о подключении vSphere Management Assistant к серверу vCenter.

Для проверки мы выключили на время виртуальную машину с vMA, и база перестала расти. Поскольку сам vMA был установлен достаточно давно, то стало понятно, что проблема возникла из-за недавних манипуляций с vilogger. Отключение сбора журналов с сервера vCenter позволило решить проблему.

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

P.S. в VMware vSphere Management Assistant 5.0 этой проблемы нет, т.к. из него убрали vilogger.

VCAP-DCA +1

Наконец-то, я сумел поставить долгожданную точку в изучении VMware vSphere 4 и закрепить полученные знания сдачей сертификационного экзамена VMware Certified Advanced Professional vSphere4 Datacenter Administration. Итоговый результат составил 325 баллов из 500 возможных, что меньше, чем хотелось бы, но больше, чем требуется для успешной сдачи.

Как должно быть многим из вас известно, данный экзамен представляет собой одну большую лабораторную работу, состоящую из порядка 40 вопросов/заданий (мне попалось 35). Никаких вопросов по теории, никаких вариантов ответов на выбор, все требуется делать вживую на небольшой инфраструктуре, включающей два сервера ESX/ESXi, сервер управления vCenter и десяток виртуальных машин. Одно неосторожное движение во вкладке Networking и лабораторная работа может внезапно окончиться плачевно, о чем, собственно, экзаменационная система настойчиво предупреждает в самом начале.

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

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

Самое важное на экзамене - правильно спланировать свое время. Это при сдаче обычных тестов четыре часа кажутся прорвой времени, в лабораторной каждая минута на счету. Я послушался совета зарубежных коллег и не стал долго разбираться с проблемными вопросами, коих оказалось штук 8, а старался побыстрее дойти до последнего. Кроме того, помог тот факт, что задания практически не связаны друг с другом, и некоторые вещи можно делать параллельно, пока система что-нибудь установит или настроит. Единственным заданием, которое я просто не смог пропустить из-за принципа, было написание скрипта. В итоге оставшихся тридцати минут до конца хватило, чтобы добить еще 2-3 отложенных вопроса.

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

В целом, вся тестовая система работала достаточно стабильно и быстро, однако, попалось несколько вещей, которые откровенно не понравились. Во-первых, весьма скромного размера удаленный рабочий стол (1024x768). Работать было не очень комфортно после привычных больших мониторов на работе и дома. Во-вторых, постоянно приходилось переключаться между окном с рабочим столом и окном с заданиями. Особенно это надоедало в заданиях, где требовалось задать конкретные настройки в системе, названия компонентов и т.п. В-третьих, вместо стандартной панели задач присутствовало маленькое окно с ярлыками, запускающими основные приложение (клиент vSphere, клиент RDP, Putty и Adobe Reader), и надписью с просьбой ничего не закрывать. Я не стал нарочно проверять, что будет, если, все-таки, проигнорировать это сообщение, однако пару раз ловил себя на мысли, что хочется закрыть лишние окна. И, да, для тех, кто не в курсе о hotkey на переключение между окнами (Alt + Tab), выучите - пригодится. :-)

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

Настольными книгами для меня стали задачник VCAP-DCA Exam Blueprint Guide и решебник VCAP-DCA Study Guide, содержащие детально описание тем, с которыми придется столкнуться на экзамене.