VM Press

Катастрофоустойчивая инфраструктура на базе VMware SRM (Часть I)

2012-01-17T08:00:00.000+04:00

Сегодня я планирую начать серию статей, посвященных продукту VMware vCenter Site Recovery Manager (SRM). VMware SRM является основой для организации катастрофоустойчивых решений и предоставляет возможность автоматизации процедуры восстановления виртуальной инфраструктуры при авариях, повлекших за собой недоступность серверов, систем хранения данных (СХД) или целого сайта, а также позволяет проводить плановую миграцию инфраструктуры на резервный сайт и тестировать корректность работы резервной инфраструктуры.

В этих статьях я хотел бы рассказать об актуальной 5-й версии продукта, а также описать процедуру его установки и настройки и работу в связке с СХД NetApp.

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

Вступление
Сразу же хочется ответить на главный вопрос - зачем защищаться от катастроф? Почему не использовать ~~обычный порошок~~ средства обеспечения отказоустойчивости?

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

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

Проницательный читатель, немного знакомый с SRM, возможно скажет: “ - Зачем мне покупать отдельный продукт, который, по существу, не обеспечивает никакого дополнительного функционала, если я могу практически все то же самое сделать вручную или с помощью скриптов?” - и будет по-своему прав. Однако в критической ситуации, коей, безусловно, является падение виртуальной инфраструктуры и всех сервисов, запущенных в ней, человек имеет свойство паниковать и совершать ошибки. В некоторых случаях цена такой ошибки может многократно превысить стоимость и SRM, резервного ЦОДа и всей виртуальной инфраструктуры.

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

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

Сбои можно классифицировать в зависимости от причины возникновения:

Аппаратные сбои. К ним можно отнести, например, выход из строя каких-либо отдельных компонентов серверов или СХД (дисков, вентиляторов, блоков питания, плат расширения, портов). От таких сбоев защититься можно, устранив единую точку отказа (дублирование по схеме N+N или N+1). Однако следует помнить, что следует дублировать не только внутренние компоненты, про отдельные узлы системы, например, Ethernet и Fibre Channel коммутаторы, серверы или контроллеры СХД также не следует забывать.
Программные сбои, которые могут возникать из-за ошибок в коде или программной несовместимости компонентов. Обычно такие сбои не приводят к прекращению работы всей инфраструктуры, если не брать в расчет масштабных вирусных эпидемий или массовую установку проблемного драйвера или обновления. Защититься от программных сбоев можно, разворачивая поддерживаемые и рекомендованные производителями конфигурации, ставя только проверенное ПО, и тестируя обновления перед их установкой в производственную среду.
Человеческий фактор не ограничивается только злобной уборщицей, попавшей по недосмотру в серверную, или проделками пьяных администраторов. Зачастую обычная невнимательность или банальная некомпетентность сотрудников могут привести к печальным последствиям. Гораздо хуже, если сбой вызван из-за предумышленных действий (саботажа) компетентного сотрудника, имеющего доступ к системе.
Форс-мажоры. Практически непредсказуемы по причине возникновения и степени воздействия. Обычно затрагивают все компоненты инфраструктуры сразу, Среди примеров: пожары, наводнения, ураганы, либо более частые - такие как отключение электроэнергии, поломка системы кондиционирования, люди в черных масках с автоматами...

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

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

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

Во-первых, многие приложения и службы имеют встроенные механизмы защиты данных. Так, например, файловые серверы на базе Windows могут реплицировать файлы и папки, используя протокол DFS, контроллеры домена реплицуруют объекты службы каталога, для баз данных Exchange или SQL можно настроить зеркалирование.

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

Резервное копирование.
Кластеризация СХД.
Репликация данных.

Рассмотрим каждый из них подробнее.

Резервное копирование
Как известно администраторы делятся на тех, кто еще не делает резервные копии, и на тех, кто уже делает.

К плюсам резервного копирования относятся:

Распространённость решений.
Создание копий данных, актуальных на определенный момент времени.
Возможность длительного хранения копий данных (архивирование).
Поддержка различных носителей для хранения копий: магнитные, ленточные, оптические накопители.
Возможность резервировать и восстанавливать только те данные, которые требуются (выборочное резервное копирование/восстановление).
Применение разных политик по частоте резервного копирования и длительности хранения для разного типа данных.

Минусы в полной мере характеризуются двумя терминами: RTO и RPO.

(RTO - Return Time Objective - это время на восстановление системы после сбоя). Перед тем, как данные снова станут доступны для использования, их требуется восстановить из резервной копии.

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

Этот недостаток присущ для большинства систем резервного копирования, хотя существуют и исключения, компания Veeam предоставляет продукт для резервного копирования Veeam Backup & Replication, который позволяет монтировать резервные копии в виде NFS хранилища, и напрямую запускать с них ВМ, а после переносить их на основное хранилище с помощью Storage vMotion.

Второй недостаток систем резервного копирования - RPO (Return Point Objective или точка восстановления) характеризуется временем, прошедшим с момента последнего резервного копирования данных, и также тем объемом данных, которые были изменены, и соответственно, могут быть потеряны из-за сбоя.

Например, если резервная копия базы была сделана в час дня, в два часа дня в базу были внесены изменения, а в три часа на ЦОД упала бомба, то при восстановлении будут получены данные актуальные на час дня и потеряются все изменения сделанные после.

Таким образом, чем чаще наша система выполняет резервное копирование, тем меньше показатель RPO, большинство СРК позволяют создавать резервные копии хоть каждые 15 минут. Проблемы начинаются в тех случаях, когда для особо критичных сервисов этого может быть недостаточно.

Отдельным пунктом можно выделить мгновенные снимки (snapshots), поддерживаемые большинством СХД, которые хотя и не в полной мере являются резервными копиями, но также позволяют сохранить копию данных на определенный момент времени. Мгновенные снимки могут создаваться администратором вручную или по расписанию, а также использоваться для создания полноценных резервных копий или репликации данных.

Кластеризация СХД
Другой метод защиты данных основан на кластеризации СХД. У разных вендоров технологии обеспечивающие кластеризацию могут называться по разному, у кого-то это синхронизация, у кого-то зеркалирование, но идея одна. Несколько узлов СХД объединяются, и представляются для всех потребителей дисковых ресурсов единым логическим хранилищем (как правило, узлов два, но в некоторых решения их может быть и больше). Внутри хранилища обеспечивается избыточность хранения LUN'ов, таким образом, что отказ одного из узлов не приводит к потере доступа к LUN'у с данными для клиента.

В качестве примеров кластерных СХД можно привести:

HP P4000 (Lefthand).
NetApp MetroCluster.
EMC VPLEX Metro.
Falconstor Network Storage Server.
Другие..

При желании можно сделать кластеризованное хранилище из серверов, используя Linux + DRBD + HA + iSCSI Target/NFS Export + пару-другую скриптов.

Даже у VMware есть собственный продукт (vSphere Storage Appliance), позволяющий объединить локальные хранилища серверов виртуализации, однако у него есть ряд серьезных ограничений.

Преимущества кластеризации СХД:

Нулевое время простоя в случае отказа одного из узлов.
Прозрачная работа для клиентов. Не требуют ручного переключения с одного узла на другой.
Возможность организации территориально распределенной СХД (Metro или многосайтового кластера). В этом случае, один из узлов СХД может находиться в одном ЦОДе, второй - в другом ЦОДе расположенном в десятках или даже сотнях километров от первого.

Недостатки кластеризации СХД:

Стоимость. Как правило, такие решения представляют собой отдельные линейки СХД midrange или enterprise уровня, или же требуют покупки дополнительных весьма недешевых лицензий.
Требование наличия высокоскоростных каналов передачи данных между узлами СХД.
В случае распределенной СХД, вероятность возникновения Split Brain.

Что такое Split Brain и почему его следует опасаться? Допустим, у вас есть распределенное двухузловое хранилище, каждый из узлов предоставляет доступ к своему набору LUN'ов. В какой-то момент времени между двумя ЦОДами пропал канал связи. Например экскаватор порвал оптоволокно. В данной ситуации для любого из узлов нет однозначной возможности определить - по какой причине недоступен партнер (т.е. с узлом партнером действительно произошел сбой и оставшемуся узлу следует брать на себя управлением доступом ко всем LUN'ам или же это проблема из-за недоступности канала связи).

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

Бороться с этим можно различными способами: использовать несколько независимых маршрутов, или организовать третий ЦОД с узлом-арбитром, который будет доступен для узлов кластера по независимым каналам связи и позволит определить, какому из узлов СХД должен принадлежать тот или иной LUN.

Еще один негативный момент использование кластеризации заключается в том, что данные защищаются на уровне физического оборудования, но не на логическом. Любые изменения внутри LUN'а мгновенно синхронизируются, если какой-либо файл или виртуальная машина будет удалена, то это мгновенно отразится на всех копиях. Для того, чтобы иметь возможность "отменить" сделанные изменения следует использовать резервное копирование, мгновенные снимки или асинхронную репликацию.

Репликация
Репликация позволяет настроить копирование по заданному расписанию данных с основного хранилища на резервное. При необходимости, администратор может приостановить репликацию и переключить клиентов на резервное хранилище. Репликация между СХД выполняется на блочном уровне и передает только измененные блоки данных, а не все файлы или LUN'ы целиком.

Функционал репликации есть у большинства вендоров СХД, если не брать в расчет Home Office NAS'ы, где репликация выполняется с помощью какого-нибудь rsync, то, например, в СХД entry уровня HP StorageWorks P2000 G3 появилась такая возможность.

Преимущества:

Поддержка большим количеством СХД.
Меньшие требования к каналам передачи данных.
Возможность реплицировать данные одного источника на несколько целевых хранилищ.
Реплики данных могут использоваться для создания резервных копий или тестирования.

Недостатки.

Прежде всего надо понимать, что исходное хранилище и целевое хранилище - это два разных хранилища с точки зрения клиентов (у реплицированного и исходного LUN'а различается идентификатор и серийный номер, у контроллеров, участвующих в репликации разные WWN'ы, IP адреса, IQN имена).
Переключение между хранилищами и презентование реплицированного LUN'а занимает определенное время и обычно выполняется администратором вручную.
Кроме того, для асинхронной репликации возможна потеря части данных (в зависимости от частоты репликации).

Условной можно разделить репликацию на два типа:

Синхронная.
Асинхронная.

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

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

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

В свою очередь асинхронная репликация позволяет копировать данные по расписанию (раз в день, раз в час, раз в 5 минут).
Преимущества:

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

Недостатки:

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

Рассмотренные выше варианты защиты данных не исключают друг-друга и в ряде случаев могут применяться совместно. Если говорить непосредственно о VMware SRM, то весь функционал продукта строится как раз вокруг возможности репликации данных средствами СХД (хотя стоит отметить, что в последней на сегодня 5-й версии появилась возможность организовать репликацию средствами SRM). Но об этом в следующий раз.

Заключение
Не исключено, что придирчивый читатель скажет: "- Как можно было написать столько текста~~, не вставив ни одной картинки,~~ и практически ничего не сказать о VMware SRM?" Честно говоря - сам в шоке. Однако, тема организации катастрофоустойчивого решения является благодатной почвой для моего словоблудия, надеюсь в следующий раз мне удастся порадовать вас большей конкретикой и техническими деталями.

Обзор Citrix XenServer vSwitch Controller

2011-12-12T08:00:00.000+04:00

Одним из нововведений, появившихся в 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-интерфейс (из консоли доступны всего несколько команд, задающих сетевые настройки и позволяющие выключить или перезагрузить ВМ).

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

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

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

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

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

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

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

Обязательные правила на глобальном уровне.
Обязательные правила на уровне пула ресурсов.
Обязательные правила на уровне виртуальной сети.
Обязательные правила на уровне виртуальной машины.
Правила на уровне виртуального адаптера.
Стандартные правила на уровне виртуальной машины.
Стандартные правила на уровне виртуально сети.
Стандартные правила на уровне пула ресурсов.
Стандартные правила на глобальном уровне.

При использовании списков контроля доступа следует учитывать один важный момент. В случае недоступности контроллера (например, при его выключении), все 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

2011-11-06T08:00:00.000+04:00

Есть такой продукт для резервного копирования - 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

2011-09-26T08:00:00.000+04:00

На прошлой неделе у меня появилось немного свободного времени, поэтому я решил обновиться до 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

2011-09-19T08:00:00.000+04:00

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

Все параметры хранилища разделяются на два типа: системные (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

2011-09-01T08:00:00.001+04:00

Одним из нововведений, появившихся в 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

2011-08-29T08:00:00.010+04:00

Недавно мы столкнулись с проблемой черезмерного роста базы 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

2011-08-04T08:00:00.065+04:00

Наконец-то, я сумел поставить долгожданную точку в изучении 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, содержащие детально описание тем, с которыми придется столкнуться на экзамене.

Администратор в Windows 7 и Customization Specification

2011-07-21T08:00:00.001+04:00

По умолчанию, в операционных системах Windows Vista и Windows 7 для большей безопасности встроенная локальная учетная запись администратора отключена (disabled). Кроме того, учетная запись администратора отключается при отработке утилиты sysprep (например, при разворачивании и настройке виртуальной машины из шаблона с помощью Customization Specification).

Чтобы обойти это ограничение, создайте в виртуальной машине Windows 7 в папке "%WINDIR%\Setup\Scripts\" файл setupcomplete.cmd и добавьте в него следующую команду:

net user Administrator /active:yes

Для русской версии, соответственно, будет "Администратор".

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

Загрузка и установка VMware ESXi по сети

2011-07-08T08:00:00.015+04:00

Вариант загрузки и установки ESXi по сети может пригодиться, если вам требуется в короткие сроки развернуть большое количество однотипных серверов, не оснащенных CD приводами (например, блейд-серверы), а также автоматизировать однотипные действия, вроде принятия лицензионного соглашения или установки пароля администратора. При наличии уже развернутого vCenter Server можно воспользоваться VMware PXE Manager for vCenter, однако, если его нет - придется делать все самим.

Процесс загрузки и установки сервера по сети включает в себя следующие этапы:

При запуске сервера, управление передается загрузчику в сетевом адаптере (PXE - Preboot eXecution Environment).
PXE посылает широковещательный запрос DHCP серверам сети с целью получения сетевых настроек.
Помимо IP адреса и маски подсети, DHCP сервер отправляет дополнительные параметры - адрес TFTP сервера и путь к файлу загрузчика, который следует запустить.
Загрузчик (в нашем случае pxelinux) в соответствии с настройками, заданными в конфигурационном файле (default), загружает ядро, также используя протокол TFTP.
Наконец, ядро запускает процесс автоматической установки ESXi с параметрами из kickstart файла, который может располагаться, например, на FTP или HTTP сервере.

В качестве примера рассмотрим процесс подготовки сервера Windows Server 2008 R2 для развертывания с его помощью VMware ESXi 4.1 Update 1.

Подготовка дистрибутива
Загрузите последнюю версию Syslinux с сайта (на момент написания - syslinux-4.04.zip).

Скопируйте содержимое дистрибутива VMware ESXi 4.1 Update 1 в папку на сервере (например, 'C:\FTPRoot'). В эту же папку скопируйте три файла из архива Syslinux: pxelinux.0 (расположен в ".\core\"), mboot.c32 (расположен в ".\com32\mboot\") и menu.c32.(расположен в ".\com32\menu\") Подтвердите замену файлов.

Создайте папку и назовите ее pxelinux.cfg, скопируйте в нее файл isolinux.cfg из дистрибутива ESXi и переименуйте его в default (без расширения).

Настройка сервера
Для загрузки по сети нам понадобятся следующие службы:

TFTP;
DHCP;
DNS;
FTP.

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

В качестве TFTP сервера вы можете использовать встроенную службу Windows Deployment Services. Пример настройки TFTP сервера приведен в данной статье. В качестве альтернативного TFTP сервера можно использовать TFTPD. TFTPD проще в установке, а также может выступать в роли DHCP сервера.

При настройке TFTP сервера в качестве корневой укажите ранее созданную папку, в которую был скопирован дистрибутив ESXi.

Если требуется - установите DHCP сервер. Создайте резервацию для MAC адреса адаптера будущего ESXi сервера, с которого будет осуществляться загрузка по сети. Использование резервации вместо задания параметров на уровне всего диапазона адресов или сервера DHCP является хорошей идеей, дабы ненароком не запустить установку ESXi на других компьютерах, настроенных на загрузку по сети.

Обязательно задайте следующие DHCP опции.

060 PXE Client - в качестве значения укажите: PXE Client.
066 Boot Server Host Name - в качестве значения укажите IP адрес или DNS имя TFTP сервера.
067 Bootfile Name - в качестве значения укажите: pxelinux.0.

В качестве примера по настройке опций DHCP можете ознакомиться с этой статьей.

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

Установите FTP сервер, используя мастер Add Roles Wizard.

Откройте консоль управления IIS и создайте новый FTP сайт.

На вкладке Site Information задайте произвольное имя (FTP site name), а в качестве корневой директории FTP сайта (Physical path) укажите ранее созданную папку с дистрибутивом (например, "C:\FTPRoot"). Нажмите Next.

На вкладке Binding and SSL Settings отключите требование использования SSL при подключении (No SSL). Нажмите Next.

На вкладке Authentication and Authorization Information разрешите анонимным пользователям аутентифицироваться на сайте, включив Authentication | Anonymous, а также загружать файлы Allow access to: Anonymous users и Permissions | Read. Нажмите Finish для завершения мастера и создания сайта.

Редактирование kickstart файла
При редактировании текстовых файлов из Windows обратите внимание на следующие особенности.

В Windows и в ESXi используются разные форматы перевода строк. Из-за этого файл, сохраненный в Windows, в ESXi будет отображаться вот так:

Это может стать причиной разнообразных ошибок при выполнении скриптов из kickstart файла. Для решения данной проблемы вы можете:

Использовать для загрузки kickstart файла протокол FTP.
Использовать сторонний текстовый редактор, который позволяет настраивать формат переносов (например, Notepad++).

В текстовом редакторе создайте файл ks.cfg следующего содержания:

vmaccepteula
rootpw P@ssw0rd
autopart --firstdisk=local
install url ftp://<SERVERNAME>
network --bootproto=dhcp --device=vmnic0 --vlanid=0 --addvmportgroup=0
reboot

где <SERVERNAME> соответствует имени или IP адресу FTP сервера, на котором расположен дистрибутив.

Подробнее о параметрах в файле ks.cfg можно прочитать в руководстве по установке ESXi.

Сохраните файл в корневую папку FTP сервера.

Отредактируйте файл default в папке pxelinux.cfg, добавив в него параметр, указывающий на расположение kickstart файла, например так:

default menu.c32

menu title VMware VMvisor Boot Menu

timeout 80
label ESXi Installer
menu label ^ESXi Installer
kernel mboot.c32
append vmkboot.gz ks=ftp://<SERVERNAME>/ks.cfg --- vmkernel.gz --- sys.vgz --- cim.vgz --- ienviron.vgz --- install.vgz
labelBoot from local disk
menu label ^Boot from local disk
localboot 0x80

Где <SERVERNAME> соответствует IP адресу или DNS имени вашего FTP сервера, на котором располагается kickstart файл.

Обратите внимание, что параметр ks= следует указывать сразу за vmkboot.gz, в противном случае, вы можете получить сообщение об ошибке.

Проверка работы
Для проверки работоспособности решения, достаточно запустить целевой сервер в качестве загрузочного устройства выбрать сетевой адаптер. Если все было сделано правильно, то через некоторое время вы увидите привычное окно установщика ESXi, а буквально через пару минут, и сам установленный ESXi.

VMware vExpert 2011

2011-07-04T08:00:00.001+04:00

Пускай и с небольшим опозданием, но тоже спешу похвалиться получением в этом году статуса VMware vExpert.

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

P.S. Надеюсь и дальше продолжать радовать Вас новыми постами.

Механизм настройки прав в VMware vCenter

2011-06-28T08:00:00.005+04:00

Небольшая заметка о том, каким образом VMware vCenter Server хранит разрешения на управление виртуальной инфраструктурой.

Все разрешения хранятся в виде записей в таблице dbo.VPX_ACCESS в базе Microsoft SQL Server'а.

Всего в таблице пять столбцов:

ID - уникальный идентификатор.
PRINCIPAL - имя учетной записи пользователя или группы для которых назначаются права. Задаются в формате <ИМЯ_ЗАПИСИ> или <ДОМЕН\ИМЯ_ЗАПИСИ>.
ROLE_ID - идентификатор роли, содержащий необходимые права.
ENTITY_ID - идентификатор объекта, на который назначаются разрешения.
FLAG - переключатель хранит информацию о наследовании и типе учетной записи (пользователь, группа). Может принимать одно из четырех значений:

0 - учетная запись - пользователь, права не наследуются (no propagate);
1 - учетная запись - пользователь, права наследуются (propagate);
2 - учетная запись - группа, права не наследуются (no propagate);
3 - учетная запись - группа, права наследуются (propagate).

Для каждой роли при создании задается свой уникальный ROLE_ID. В vCenter все роли подразделяются на два типа: системные (System roles) и пользовательские (User roles).

Системные роли существуют в vCenter изначально и не могут быть изменены или удалены. К системным относятся следующие роли:
Administrator - идентификатор роли (ROLE_ID): -1;
Read Only - идентификатор роли: -2;
No Access - идентификатор роли: -5.

Пользовательские роли могут быть созданы, отредактированы и удалены администратором vCenter. В vCenter после установки также присутствует несколько предустановленных (sample) пользовательских ролей:
Virtual machine power user (sample) - идентификатор роли (ROLE_ID): 4;
Virtual machine user (sample) - идентификатор роли: 5;
Resource pool administrator (sample) - идентификатор роли: 6;
VMware Consolidated Backup user (sample) - идентификатор роли: 7;
Datastore consumer (sample) - идентификатор роли: 8;
Network consumer (sample) - идентификатор роли: 9.

Все пользовательские роли хранятся в каталоге "DC=virtualcenter,DC=vmware,DC=int".
Для определения нужного ROLE_ID достаточно подключиться к каталогу (например, с помощью утилиты ADSIEdit) и в подразделении UserRoles найти требуемую группу.

Наконец, значения ENTITY_ID для всех объектов виртуальной инфраструктуры хранятся в таблице dbo.VPX_ENTITY, поле ID.

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

Выдача SSL сертификата для vShield Manager

2011-05-16T08:00:00.003+04:00

Недавно у меня появилась необходимость заменить самоподписанный сертификат для VMware vShield Manager на заверенный нашим УЦ, однако в процессе выполнения данной операции пришлось столкнуться с небольшой проблемой, о которой и хотелось бы рассказать.

Сама процедура крайне проста, первоначально требуется создать .CSR запрос из интерфейса vShield Manager, заполнив необходимые поля, после чего на его основе выпустить с помощью УЦ сертификат и импортировать его в vShield Manager.

Поскольку все клиенты vSphere Client подключаются к vShield Manager'у по IP-адресу, то при создании запроса в поле Common Name следует указывать IP-адрес. В руководстве vShield Administration Guide дословно написано так:

Enter the name that matches the site name. For example, if the IP address of vShield
Manager management interface is 192.168.1.10, enter 192.168.1.10.

Проблема заключается в том, что при использовании IP-адреса в качестве Common Name, vShield Manager выводит предупреждение "Please enter correct domain name as common name".

Более того - не получится задать hostname (NetBIOS) имя сервера, или DNS имя с доменами первого уровня вроде .local или .internal.

~~Усугубить ситуацию может попытка разобраться в происходящем в 2 часа ночи.~~

Если заглянуть в исходный код страницы, то можно обнаружить следующее. За проверку Common Name отвечает javascripts функция checkDomain(), в которой жестко прописаны, какие домены первого уровня допустимо использовать в имени сервера. Соответственно, написать IP-адрес никак не получится.

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

Откройте страницу запроса сертификата https:///CertificateSummary.do?operation=showCertSummary и замените код функции checkDomain() на:

function checkDomain(nname){
return true;
}

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

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

Еще один момент связан с самой процедурой добавления. Перед тем, как добавлять подписанный сертификат, вам потребуется импортировать корневой и все промежуточные сертификаты УЦ в цепочке, в противном случае вы получите сообщение об ошибке.

После добавления сертификата вам потребуется перезагрузить vShield Manager. Сертификат успешно установлен.

VMware High Availability и проверка изоляции

2011-04-26T08:00:00.006+04:00

Одной из функций высокодоступного кластера VMware является механизм проверки изоляции, который запускается, если сервер в течение некоторого времени (по умолчанию 12 секунд) не получает heartbeat сигналов от других членов кластера.

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

Для определения изоляции узел посылает echo-запрос на специальные IP-адреса (isolation address).

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

По умолчанию в качестве адреса для проверки изоляции используется маршрутизатор по умолчанию.

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

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

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

Для предотвращения этой ситуации следует, во-первых, дублировать сетевое оборудование, во вторых, добавить проверку дополнительных адресов, прописав в Advanced Options настройках HA кластера параметры das.isolationaddress и/или das.isolationaddress{n}.

Первый параметр позволяет задать один дополнительный адрес для проверки изоляции, второй, точнее остальные - до десяти дополнительных адресов (в различных документах описывается, что параметры должны иметь значение das.isolationaddress1, das.isolationaddress2, ... das.isolationaddress10, хотя на практике мне удавалось задать и das.isolationaddress0; номер в названии параметра влияет на очередность при проверке).

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

Также для предотвращения ложного срабатывания можно задать параметр das.failuredetectiontime (по умолчанию используется значение 15000 миллисекунд), влияющий на время, в течение которого узлы будут пытаться отправлять друг-другу heartbeat'ы, до того как начать проверку на изоляцию.

Важно отметить, что использование параметров das.isolationaddress не отменяет маршрутизатор по умолчанию в качестве адреса для проверки изоляции. Чтобы не использовать маршрутизатор для проверки вам потребуется добавить параметр "das.usedefaultisolationaddress = false".

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

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

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

Однако с этим решением связан один важный момент. При добавлении узла в кластер требуется, чтобы все указанные адреса для проверки изоляции были доступны. Если хотя бы один из адресов недоступен, вы получите сообщение об ошибке: "Could not reach isolation address".

Проблема заключается в том, что echo-запрос отправляется с любого "ближайшего" VMKernel интерфейса (например, с интерфейса из той же подсети, где находится адрес для проверки изоляции), а не с того, который настроен для передачи управляющего трафика (Management traffic).

Наглядно эту ситуацию демонстрирует следующая картинка.

В данном примере IP адрес 10.0.0.4 соответствует VMKernel интерфейсу, на котором включен management traffic, а 10.0.1.4 - интерфейсу VMKernel, который используется только для передачи iSCSI трафика (адрес 10.0.0.254 соответствует маршрутизатору по умолчанию, 10.0.1.1 - хранилищу iSCSI). В момент проверки узла на изоляцию наблюдается следующее.

VMKernel пытается отправить echo-запрос на адрес 10.0.1.1 уже не с адреса 10.0.1.4, как делал это при создании кластера, а с 10.0.0.4. И если у вас не настроена маршрутизация между подсетями, то смысл в дополнительном адресе для проверки изоляции теряется.

Один последний момент, который я хотел рассмотреть - обеспечение избыточности для управляющих интерфейсов (Management Network) серверов ESXi. Управляющие интерфейсы используются узлами HA кластера для отправки heartbeat пакетов, согласования изменений в конфигурации и проверки изоляции.

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

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

Подключение дополнительных сетевых адаптеров к управляющему интерфейсу.
Создание дополнительных VMKernel интерфейсов и назначение на них функции передачи управляющего трафика (Management traffic).

С первым вариантом все просто - добавили в vSwitch второй (третий, четвертый...) адаптер и переопределили на уровне VMKernel порядок их использования (рекомендуется настроить один из адаптеров как Active, остальные - Standby).

Данный вариант обеспечит защиту от сбоев оборудования: сгоревшего порта, сетевой карты, коммутатора (если они дублированы) или отключенного кабеля, однако не поможет в случае ошибок в конфигурации VLAN'ов, неправильным назначением сетевых настроек, ARP или IP spoofing'е и т.п.

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

Все.

Опыт проектов виртуализации

2011-04-15T08:00:00.006+04:00

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

1) Выбирайте оборудование и ПО, исходя из ваших потребностей.

Часто можно столкнуться с такими перегибами. Клиент покупает полную корзину блейд-серверов с двумя управляющими модулями, ethernet и FC коммутаторами для отказоустойчивости, но при этом "забывает" купить несколько FC кабелей, или же банально не хватает PDU с какими-нибудь розетками типа IEC320 C19 для подключения всех блоков питания, а после подключения, оказывается, что ИБП не тянут.

Или же клиент берет три четырехсокетных сервера, покупает по 4-ре лицензии vSphere Enterprise Plus и Windows Server Datacenter на каждый сервер, хотя никакой функционал Enterprise Plus использовать не планирует, да и виртуальных машин у него всего ~10 на весь кластер. А иногда, бывает, и по одной ВМ на сервер хочет оставить, чтобы "надежнее" и "производительнее".

2) "У нас мало денег, возможно, мы даже не сможем вам заплатить."

Это противоположная крайность (я о ней писал). У инженеров будет прекрасная возможность научиться работать с консолью Windows Server Core, а также научиться подключаться MMC оснасткой Hyper-V Manager с недоменных компьютеров.

Еще пример: раньше у заказчика были 2 сервера с 6-тью 18 ГБ SCSI жесткими дисками, а теперь стал один с 4-мя ВМ на нескольких 1 ТБ SATA дисках. Все работает и не тормозит... почти.

3) Смотреть HCL нужно до покупки оборудования.

Об этом случае я тоже рассказывал. Клиент купил FC библиотеку, надо бы подключить к серверу резервного копирования. А он, оказывается, в ВМ на VMware.

4) Не все, что работает - поддерживается, не все, что поддерживается - работает.

У заказчика на виртуальном сервере один из разделов зашифрован с помощью Secret Disk. Для работы данного ПО требуется USB ключ защиты Aladdin, который предусмотрительно "проброшен" в ВМ с помощью соответствующей функции (даже галочка для поддержки работы с vMotion стоит). Требуется перенести диски ВМ с одного хранилища на другое без простоя. Нам поможет Storage vMotion. Алле-оп! USB ключ после переноса остается, Secret Disk отваливается из-за его отсутствия.

5) Это не баг, это фича/by design.

Например, совсем недавно столкнулся с особенностями работы блейд-коммутаторов Brocade, которые после собственной перезагрузки не отображают WWN HBA серверов, на которых установлен VMware ESXi. И чтобы это исправить, нужно сами серверы перезагрузить.

6) Середина проекта - отличный способ начать всё сначала.

Проект по внедрению виртуализации на базе Microsoft Hyper-V. Все машины развернуты, AD поднята, Exchange установлен, почтовые ящики смигрированы, файловые папки перетащены. В какой-то момент выясняется, что Failover Cluster просто не отрабатывает (это не камень в огород Microsoft, просто так было). Недолгая переписка с поддержкой результатов не дала, а сроки и так были сорваны. Волевое решение - переход на VMware ESX. Два выходных дня и все виртуальные машины сконвертированы. А дизайн-проект и прочую документацию всегда можно переписать.

7) Нет ничего более постоянного, чем временное.

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

(Вы): -Давай прикрутим этот прекрасный HP Cable Management Arm?
(Он): -Ой, так ломает, тут такая путаница в проводах, давай, я чуть попозже прикручу.
(прошло 2 месяца...)

Поэтому, например, чем дольше идет проект, тем меньше шансов обновить firmware для СХД или для одного из серверов.

8) Бумажка с паролями.

Мало у кого из клиентов инфраструктура подробно документирована. Часто он и сам не знает, что-какой сервер делает, особенно если предыдущий администратор уволился и толком дела никому не передал.

Нередки случаи, когда "базы у нас хранятся вот на этой СХД, но пароля от нее я не помню".

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

9) Приёмо-сдаточные испытания - прекрасный способ еще раз "обработать напильником".

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

10) Законы Мёрфи работают.

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

Купил один клиент MSA 2000i с двумя контроллерами, каждый к своему коммутатору подключен, оба блока питания запитаны от двух разных ИБП. Отдельный диск под hot spare. Сломалась эта MSA. Просто так.

Что хранится в базе VMware Guided Consolidation?

2011-04-12T08:00:00.001+04:00

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

В различных книгах и руководствах по vSphere написано, что Guided Consolidation собирает и хранит большое количество параметров и счетчиков производительности серверов, однако, непосредственно из консоли vSphere Client администраторам доступно не так уж много информации.

Вдобавок, Guided Consolidation не имеет встроенных средств для формирования отчетов в отличии от того же Microsoft Assessment & Planning Toolkit.

Так что же именно собирает и хранит Guided Consolidation?

Для хранения базы Guided Consolidation использует формат Firebird. Сам файл с данными Collector.FDB размещается в папке '%programfiles%\VMware\Infrastructure\Guided Consolidation Server\Data'.

Для препарирования базы вы можете использовать Firebird ISQL Tool, который можно загрузить в составе дистрибутива с сайта разработчиков Firebird. Однако гораздо удобнее использовать для этих целей какой-нибудь сторонний инструментарий вроде RazorSQL.

Для подключения к файлу базы с помощью Firebird ISQL Tool используется следующая команда (перед подключением не забудьте скопировать базу во временную папку):
CONNECT <ПУТЬ_К_БАЗЕ> user "SYSDBA" password "masterkey";

Все данные, собираемые Guided Consolidation, хранятся в нескольких десятках таблиц.

Например, из таблицы PERF_HOUR_SUMMARY видно, что Guided Consolidation каждый час сохраняет в базе максимальное и минимально значение счетчиков загрузки процессора (в %) и свободной памяти (в байтах) для всех обследуемых серверов.

Кроме того, в базе хранятся и другие параметры (модель и частота процессора, объем оперативной памяти, свободное место на дисках и т.д.), которые можно найти в соответствующих таблицах "DESС_" или "INV_".

Остается неясным, насколько все эти данные важны при составлении Guided Consolidation рейтинга оптимальных хостов для размещения конвертированных ВМ. Возможно, что это просто 'хвосты', оставленные от старшего брата - Capacity Planner.

Новая книга по виртуализации

2011-03-31T23:50:00.086+04:00

Вслед за Михаилом Михеевым (автором блога vm4.ru) я решил написать собственную книгу по технологиям виртуализации и облачным вычислениям: "По дороге с облаками: том 1".

Книга рассчитана на начинающих специалистов, однако будет интересна и опытным администраторам и архитекторам заоблачных ЦОДов.

Специально для читателей данного блога я решил опубликовать краткую аннотацию к книге.

Книга содержит высококачественные иллюстрации и детальные схемы компонентов виртуальной инфраструктуры.

Подробно описан весь цикл проектирования инфраструктуры - от первоначальной идеи - до конечного воплощения.

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

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

Наконец, для наглядности, в книге приведены примеры нескольких реальных проектов, которые помогут читателям лучше понять идеологию построения виртуализованных облачных ЦОДов.

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

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

Выход книги намечен на 1 апреля 2012 года.

Видео: Установка и настройка Citrix Access Gateway VPX 5 (часть II)

2011-03-09T08:00:00.004+03:00

Продолжение видео об установке и настройке Citrix Access Gateway.

Часть 2: Настройка Access Gateway:

Части 3 и 4: настройка сертификатов и проверка работы Access Gateway:

Видео: Установка и настройка Citrix Access Gateway VPX 5

2011-02-28T08:00:00.004+03:00

Добрый день, коллеги.

Решил записать новое видео про установку и настройку Citrix Access Gateway VPX 5 в среде VMware vSphere.

Первая часть.

Следите за продолжением...

Автоматизируем проверку резервных копий машин с помощью Veeam SureBackup

2011-02-16T08:00:00.005+03:00

Продолжая знакомиться с Veeam Backup & Replication, я занялся изучением функции SureBackup, позволяющей проводить автоматическое тестирование резервных копий виртуальных машин.

Наш коллега, Владимир Ескин, выложил в своем блоге отличное видео, описывающее процедуру настройки SureBackup в Veeam Backup & Replication. Поэтому, если вы еще не работали с данным продуктом, настоятельно рекомендую посмотреть его.

Каким же образом работает SureBackup?

Veeam Backup & Replication позволяет разворачивать и запускать образы виртуальных машин прямо из резервной копии в изолированной от остальной части инфраструктуры среде - виртуальной лаборатории (Virtual Lab). Каждая виртуальная лаборатория определяется набором изолированных сетей - виртуальных свитчей и групп портов, не имеющих связь с физическими сетями. При создании виртуальной лаборатории администратор выбирает один или несколько узлов ESX, на которых требуется разворачивать виртуальные машины, хранилище для временных файлов и настройки подсетей.

Перечень виртуальных машин, которые требуется протестировать задается на уровне группы приложений (Application Group). В простейшем случае группа может содержать одну единственную проверяемую машину, однако, в большинстве случаев для проверки серверов приложений (например, почтового или web-сервера) должны быть развернуты инфраструктурные службы (например, DNS, служба каталога, СУБД). В группе определяется порядок запуска ВМ и тесты, которые необходимо использовать для проверки каждой из них.

По умолчанию, в Veeam Backup & Replication есть несколько предустановленных тестовых наборов, называемых ролями (Server Roles). При создании группы приложений администратор может назначить для виртуальной машины одну из ролей, определив тем самым, какие тесты будут проводиться. Каждая роль хранится в отдельном файле в формате .xml в папке '%ProgramFiles%\Veeam\Backup and Replication\SbRoles' и может быть изменена по усмотрению администратора.

На выбор доступны следующие методы проверки работы ВМ:

Прием Heartbeat сигнала от агента VMware Tools, установленного в ВМ.
Отправка эхо запроса (Ping) на сетевой адрес виртуальной машины
Запуск сценариев для проверки работы.

И если с Heartbeat все понятно, то два других варианта требуют дополнительных пояснений.

Каким образом серверу Veeam удается пинговать виртуальную машину в изолированной сети?

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

Для избежания конфликта с адресацией (поскольку и в производственной сети и в изолированной используется одинаковый диапазон адресов) используются так называемые маскарадные сети (masquerade network). Для каждой IP адреса узла в изолированной сети ставится в соответствие аналогичный IP адрес в маскарадной сети (например 192.168.1.0/24 -> 192.168.254.0/24). В момент запуска виртуальной лаборатории на сервере Veeam Backup прописывается статический маршрут к маскарадной сети, в котором в качестве маршрутизатора указывается адрес прокси сервера.

Таким образом, когда серверу Veeam требуется получить доступ к тестируемой виртуальной машине, то вместо ее адреса в производственной сети, указывается аналогичный адрес из маскарадной сети (например 192.168.1.36 -> 192.168.254.36). По таблице маршрутизации пакет отправляется на прокси сервер.

Прокси сервер выступает в роли NAT устройства, и подменяет в принятом пакете адрес отправителя на свой собственный адрес в изолированной сети (в данном примере - 192.168.1.1), а также подменяет адрес назначения с маскарадной подсети (192.168.254.0) на адрес производственной подсети (192.168.1.0) и отправляет пакет получателю в изолированной подсети.

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

Наконец, Veeam Backup позволяет запускать сценарии для проверки ВМ. Для всех предустановленных ролей используется один единственный сценарий 'VmConnectionTester.exe' - этакий упрощенный аналог Telnet, принимающий в качестве аргументов IP адрес сервера и порт TCP, по которому следует проверить. Здесь важно сделать небольшое отступление и сказать, что Veeam Backup считает сценарий успешно отработавшим, если он был завершен с кодом возврата 0 и неуспешно - при любом другом.

Администратор может самостоятельно указывать любые произвольные сценарии (поддерживает запуск .exe, .bat, .cmd, .js, .vbs, .wsf). Все сценарии запускаются из-под учетной записи настроенной для запуска служб Veeam Backup & Replication.

В принципе, использование VmConenctionTester позволяют проверить доступность большинства сетевых служб в виртуальной машине. Однако, существуют службы, которые не используют для работы протокол TCP, предназначены для работы в качестве клиентских служб или выполняются локально. Для проверки таких служб может использоваться следующий сценарий (query-service.ps1) на powershell, проверяющий, что служба на удаленном компьютере запущена:

#query-service.ps1
param(
[string] $ip, #IP address of checked server
[string] $service ) #Service name
$result = (get-Service -ComputerName $ip -Name $service -ErrorAction SilentlyContinue)
if($result.status -eq "Running")
{
exit
}
else
{
write-host ("Error 1, Service '" + $service + "' not running or not found.") #if service not found or not running, then echo
$host.SetShouldExit(1)
exit
}

В качестве входных параметров сценарий принимает IP адрес сервера и имя службы.

Если служба не запущена или такой службы не существует, сценарий завершается и передает код ошибки 1 обработчику Veeam Backup.

Для работы сценария требуется соблюдение следующих условий:

Во-первых, требуется разрешить запуск сценариев .ps1 на сервере Veeam Backup. Сделать это можно, выполнив в консоли Powershell команду:
set-executionpolicy remotesigned

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

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

Поскольку Veeam Backup не поддерживает запуск .ps1 сценариев напрямую, можно использовать оболочку в виде batch файла (query-service.bat):

REM query-service.bat
@ECHO OFF
powershell.exe -noninteractive -noprofile -command "& {C:\Temp\query-service.ps1 %1 %2 }"
EXIT /B %errorlevel%

Теперь требуется сохранить оба файла в любую папку на сервере (по умолчанию я использовал 'C:\Temp\') и отредактировать одну из групп приложений, добавить скрипт, указать путь к сценарию query-service.bat в поле Path и указав в качестве аргументов IP адрес (задается переменной %vm_ip%) и имя службы. В данном примере в качестве проверяемой службы выбран DHCP клиент.

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

Если же, по какой-то причине, служба не будет запущена, Veeam Backup также уведомит об этом и автоматически завершит работу виртуальной лаборатории.

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

Баг Veeam SureBackup - 'DestinationHostUnreachable'

2011-02-14T08:00:00.024+03:00

Постигая азы использования Veeam Backup & Replication, я натолкнулся на неприятный баг, связанный с функцией проверки резервных копий - Veeam SureBackup.

Администраторам, работавшим с данным продуктом, должно быть известно, что для SureBackup требуется создать виртуальную лабораторию (Virtual Lab) и настроить одну или несколько изолированных сетей, в которых будут запускаться и тестироваться резервные копии виртуальных машин. Проблема заключается в том, что вы можете встретить ошибку 'DestinationHostUnreachable' при попытке прокси сервера пропинговать IP адрес тестируемой виртуальной машины.

При этом, казалось бы, все должно быть настроено правильно - брандмауэр в виртуально машине не блокирует ICMP трафик, более того, если настроить static mapping адрес для виртуальной машины, то она будет прекрасно пинговаться.

Проблема, как оказалось, заключается в некорректной длине маски, которую по умолчанию задает мастер на этапе настройки vNic для прокси сервера для изолированных сетей. В данном примере, в качестве рабочей подсети используется 192.168.1.0 с маской 255.255.255.0.

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

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

После этого пинг должен заработать.

Проблема актуальна для версии Veeam Backup & Replication 5.0.1.198.

Видео: Резервное копирование виртуальных машин VMware vSphere 4.x с помощью Symantec Backup Exec 2010 R2 (часть III)

2011-01-24T08:00:00.009+03:00

Заключительная часть видеообзора возможностей Symantec Backup Exec 2010 R2 по резервному копированию и восстановлению виртуальных машин VMware vSphere.

Видео: Резервное копирование виртуальных машин VMware vSphere 4.x с помощью Symantec Backup Exec 2010 R2 (часть II)

2011-01-17T08:00:00.002+03:00

Как и обещал, выкладываю продолжение видео по резервному копированию виртуальных машин VMware с помощью Symantec Backup Exec 2010 R2.

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

Всем приятного просмотра.

Видео: Резервное копирование виртуальных машин VMware vSphere 4.x с помощью Symantec Backup Exec 2010 R2

2011-01-14T08:00:00.005+03:00

Уже давно в голове у меня витала идея о создании видео обзоров по тому или иному продукту. Поэтому сегодня Ваш покорный слуга решил представить общему вниманию небольшой ролик, описывающий установку и первоначальную настройку сервера резервного копирования Symantec Backup Exec 2010 R2 применительно к VMware vSphere 4.1. Если, что называется, 'попрет', в ближайшем будущем обещаю выложить продолжение, и, наверняка, не только по Symantec.

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

И, конечно, замечания и пожелания крайне приветствуются.

История о подключении FC Tape Library к VMware ESXi

2010-12-20T08:00:00.001+03:00

Недавно у одного из заказчиков появилась необходимость подключить ленточную библиотеку HP StorageWorks MSL2024 G3 к серверу резервного копирования, расположенному внутри виртуальной машины, работающей под управлением VMware ESXi 4.1.

До этого момента я несколько раз встречал сообщения о возможных проблемах при использовании ленточных библиотек в виртуальной среде, но руководство Fibre Channel SAN Configuration Guide окончательно развеяло мои сомнения:

"ESX/ESXi does not support FC connected tape devices"

Памятуя о том, что "unsupported" далеко не всегда равняется "not working", и учитывая, что библиотека уже была приобретена заказчиком, было принято решение попробовать ее подключить.

Небольшое отступление - не то, чтобы я был ярым противником использования не поддерживаемых решений, но уже не раз убеждался, что соблюдение требований вендоров позволяет избежать большого числа проблем при настройке и дальнейшей эксплуатации системы. Вдобавок, для резервного копирования виртуальной среды гораздо более эффективно использование специализированных решений, вроде VMware Data Recovery или Veeam Backup & Replication, которые не работают с ленточными библиотеками.

Библиотека была смонтирована, подключена к FC свитчу и настроена, в консоли vSphere Client сделан Rescan устройств хранения, после чего было обнаружено одно устройство - стример, автозагрузчик куда-то пропал.

Вкладка Paths немного прояснила ситуацию.

Оба пути, по которым ESXi должен был получить доступ к автозагрузчику, показывались как мертвые (Dead). Проверка коммутации библиотеки b серверов, настроек зон на FC свитче результатов не принесла.

В Интернете удалось найти несколько похожих проблем и определить причину такого поведения. Все дело в некорректной работе ESXi с некоторыми FC устройствами в режиме ALUA (Asymmetric Logical Unit Access). Убедиться в этом можно, открыв журнал событий ESXi (/var/log/messages):

Запуск команды esxcli nmp satp listrules -s VMW_SATP_ALUA позволил получить список всех правил, настроенных на сервере по умолчанию:

В качестве решения проблемы предлагалось удалить лишнее правило, что и было сделано с помощью команды:
esxcli nmp satp deleterule --satp VMW_SATP_ALUA --claim-option tpgs_on

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

Затем оба устройства (стриммер и автозагрузчик) были добавлены в выбранную виртуальную машину. Для этого в свойствах ВМ нужно нажать кнопку Add... и в открывшемся окне в качестве типа устройства выбрать SCSI Device и нужное устройство.

Happy End.

Работаем с XenDesktop 5

2010-12-09T08:00:00.008+03:00

Недавно очередная, на этот раз уже пятая, версия Citrix XenDesktop показала всем свое новое "лицо".

Программисты Citrix'а сжалились над простыми смертными вроде нас с вами и полностью переработали интерфейс продукта, сделав его более удобным и дружелюбным. Эту работу трудно переоценить, вспоминая то множество оснасток, которыми приходилось ранее управлять в XenDesktop 4 и до сих пор приходится - в XenApp.

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

Для рядовых администраторов и сотрудников технической поддержки пригодится Desktop Director, позволяющий наблюдать за инфраструктурой XenDesktop и выполнять базовые операции с рабочими станциями через веб-браузер.

Каким образом эти нововведения затронули процедуру установки и настройки?

В качестве примера рассмотрим самый простой вариант развертывания VDI инфраструктуры, включающий в себя сервер XenDesktop, рабочую станцию и клиентский компьютер, с которого будет осуществляться подключение. В качестве рабочей станции можно использовать выделенный физический компьютер или виртуальную машину, работающую под управлением любого доступного гипервизора (Citrix XenServer, Microsoft Hyper-V или VMware ESX). В данном примере не предполагается выполнять интеграцию XenDesktop с подсистемой виртуализации для автоматизации развертывания и управления виртуальными машинами, поэтому каждую рабочую станцию, добавляемую в XenDesktop придется устанавливать и настраивать отдельно. Пример схемы развертывания приведен на рисунке.

В качестве ОС, устанавливаемой на серверы, рекомендуется использовать Windows Server 2008 R2, а в качестве клиентской ОС - Windows 7.

Перед началом установки требуется выполнить настройку сети на всех компьютерах и ввести их в домен Active Directory.

Для установки XenDesktop вам понадобится дистрибутив, который можно загрузить с сайта Citrix после прохождения регистрации. В моем случае использовалась Evaluation версия, включающая в себя все необходимые компоненты.

Установка и настройка сервера XenDesktop
Распакуйте XD5_Plat_Single.zip и подмонтируйте образ XenDesktop5.iso к серверу. Запустите установщик и выберите Install XenDesktop.

Примите лицензионное соглашения, выбрав I accept terms and conditions и нажмите Next.

На странице выбора компонентов (Select Components to Install) убедитесь, что выбраны все компоненты и нажмите Next.

На странице Firewall Configuration нажмите Next.

На странице Summary нажмите Install.

Дождитесь окончания установки. На странице Installation Successful убедитесь, что Configure XenDesktop after closing выбрано и нажмите Close.

В открывшейся консоли Citrix Desktop Studio выберите выберите вариант Advanced Configuration.

Укажите имя сайта (Site), путь к файлу лицензий (License file location) и редакцию (Edition). Проверьте, что выбран вариант использования сервер баз данных по умолчанию (Use default database). Нажмите Next.

При добавлении первого сервера система сама предложит создать и настроить подключение к базе. Нажмите OK.

На вкладке Host укажите тип хоста (Host type) - None, нажмите Next.

На вкладке Summary нажмите Finish.

Дождитесь, пока система завершит настройку.

Настройка рабочих станций
Установите Citrix XenDesktop Agent на виртуальной машине или рабочей станции, к которой удаленно будет подключаться пользователь. Запустите установщик, нажмите Install Virtual Desktop Agent.

Выберите вариант Advanced Install.

Если для видеокарты используется WDDM драйвер, то при установке на физический компьютер или виртуальную машину VMware ESX, вы получите сообщение с предложением отключить данный драйвер. Согласитесь, нажав Yes, так как если этого не сделать, то драйвер Citrix System Inc. Display Driver не сможет работать (подробнее об проблеме можно прочитать тут).

На странице Select Components to Install снимите Support for XenApp Application Delivery и нажмите Next.

На странице Controller Location в поле Manually enter controller location(s) введите имя сервера, на котором установлены службы XenDesktop. Нажмите Next.

На странице Virtual Desktop Configuration нажмите Next.

На странице Summary нажмите Install.

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

Откройте консоль Citrix Desktop Studio на сервере, щелкните правой кнопкой мыши по Machines и выберите Create Catalog.

В мастере Create Catalog на странице Machine Type выберите Physical и нажмите Next.

На странице Machines & users с помощью кнопки Add Computers... добавьте из Active Directory учетную запись рабочей станции, которую вы настроили ранее.

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

На странице Administrators нажмите Next.

На странице Summary задайте имя создаваемого каталога (Catalog name) и нажмите Finish для завершения настройки.

Теперь требуется назначить пользователям рабочие станции.

Щелкните правой кнопкой мыши по Assigments и выберите Create Desktop Group.

В мастере Create Desktop Group на странице Catalog выберите ранее созданный каталог, в поле Add machines введите количество машин, которое требуется назначить. Нажмите Next.

На странице Users с помощью кнопки Add... добавьте из Active Directory группы или пользователей, которым следует разрешить подключаться к удаленным рабочим станциям, и нажмите Next.

На странице Delegation нажмите Next.

На странице Summary введите имя, которое будут видеть пользователи при подключении (Display name) и имя группы (Desktop Group name) и нажмите Finish.

Проверка работы XenDesktop
На клиентской машине откройте браузер. В адресной строке впишите имя сервера XenDesktop. При первом входе на сайт вам предложат установить плагин Citrix Online Plugin Web.

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

Если вы все сделали правильно, то вам будет доступен удаленный рабочий стол.

Поздравляю с успешной настройкой.

Решение проблемы The View Connection Server connection failed. Network error

2010-11-19T08:00:00.005+03:00

В определенных ситуациях при подключении к серверу VMware View Connection Server, например версии 4.5, с помощью клиента VMware View Client, установленного в Windows Vista/7, вы можете получать ошибку следующего содержания:

The View Connection Server connection failed. Network error. Contact your network administrator.

При этом, если попытаться подключиться к серверу с компьютера, входящего в тот же домен, что и сервер View, или с компьютера с ОС Windows XP, то все работает замечательно.

Просмотр журнала "debug-<date>.txt", который располагается в "%userprofile%\AppData\Local\VMware\VDM\logs", позволяет получить более детальное сообщение об ошибке:

DEBUG [wswc_http] WININET ErrorCode = 12057

Поиск по номеру ошибки в Интернете приводит к статьям, описывающим проблемы со списками отзывов сертификатов (CRL). Проверить это предположение можно, отключив проверку CRL в свойствах настроек Интернет: Start -> Control Panel -> Internet Options -> Advanced -> Check for server certificate revocation.

Так и есть! Теперь клиент нормально подключается.

Но что могло послужить причиной? Посмотрим на сертификат, который используется в VMware View Connection Server.

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

Публикация дополнительных путей, доступных клиентам (например, http:// или file://), и повторная выдача сертификата серверу View позволит решить проблему.

P.S. а проверку CRL на клиенте лучше включить обратно. :-)

Различия VMware vShield Zones и vShield App 4.1 update 1

2010-11-03T08:00:00.032+03:00

Если попытаться коротко описать vShield App, то это ни что иное, как более продвинутая (и более дорогая) версия vShield Zones.

Основное назначение vShield Zones и vShield App заключается в возможности создавать правила, которые фильтруют IPv4 пакеты (IPv6 не фильтруется) от виртуальных машин и к виртуальным машинам, подпадающие под определенные правила (совпадение адреса отправителя, адреса получателя, порта и используемого протокола). Какие функции становятся доступными при переходе на vShield App? Давайте посмотрим.

Лицензия на право использования vShield Zones входит в редакции vSphere Advanced, Enterprise или Enterprise Plus; vShield App лицензируется отдельно по количеству защищаемых виртуальных машин.

Обновление с vShield Zones до vShield App производится путем добавления соответствующей лицензии в vCenter Server и не требует установки дополнительных компонентов.

По сравнению с предыдущими версиями vShield Zones, процедура установки в 4.1 существенно упростилась. Больше не требуется загружать и добавлять в vCenter отдельную виртуальную оснастку (appliance) vShield Zones. Вся процедура установки и настройки выполняется из консоли виртуальной машины vShield Manager, которая содержит в себе необходимые компоненты.

Кроме того, больше нет разделения групп портов и виртуальных коммутаторов на незащищенные (Unprotected), подключенные к физическим сетевым адаптерам, и защищенные (Protected), подключенные к виртуальным машинам. После установки агента vShield Zones на сервер ESX правила фильтрации начинают действовать на все виртуальные машины независимо от их расположения.

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

Пакеты анализируются vShield Zones/App в соответствии с существующей таблицей и при нахождении первого подходящего правила отбрасываются или доходят до получателя. Порядок просмотра правил следующий:

правила для датацентра с высоким приоритетом;
правила для кластера;
правила для группы портов;
правила для датацентра с низким приоритетом;
правила по умолчанию.

Для vShield Zones при редактировании правила администратор может задавать в качестве адреса отправителя и получателя только определенный IP адрес или подсеть.

В vShield App возможности по созданию правил расширены - в качестве источника или назначения трафика можно указывать виртуальные машины, расположенные в определенном датацентре, кластере, группе портов, VLAN'е; либо, наоборот, все виртуальные машины, которые НЕ находятся внутри датацентра, кластера, группы портов.

Администратор также может создавать свои собственные группы безопасности (Security Groups) и включать в них выбранные виртуальные сетевые адаптеры.

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

Средство просмотра графиков и отчетов по типу трафика (VM Flow) было переименовано в Flow Monitoring и перекочевало из vShield Zones в vShield App, что крайне огорчает, т.к. никаких других нововведений замечено не было.

Администратор все также может добавить описание для протоколов (Port Mapping), неизвестных vShield App, для более наглядного их отображения в отчетах и при создании правил.

Наконец, начиная с версии 4.1 Update 1, в vShield App появилась функция SpoofGuard, которая позволяет избежать подмены IP адресов в виртуальных машинах. При включении SpoofGuard
для каждой виртуальной сетевой карты ставится в соответствие один определенный IP адрес (администратор может подтвердить корректность IP адреса вручную или автоматически при первом назначении), в случае изменения IP адреса система заблокирует отправку и прием пакетов на данную сетевую карту до тех пор, пока администратор не подтвердит корректность новых настроек в vShield App.

Настраиваем VMware Auto Deploy

2010-10-29T08:00:00.104+04:00

Признаться, я всегда мечтал, чтобы когда-нибудь во всех современных приложениях появилась большая круглая красная кнопка "Работать", нажав которую, администратор по прошествии определенного времени получал бы полностью настроенную и работоспособную систему. И хотя VMware Auto Deploy пока не обладает такой кнопкой, но, во всяком случае, делает уверенные шаги в нужном направлении.

VMware Auto Deploy представляет из себя виртуальную оснастку (Virtual Appliance), которая будучи развернута вместе с VMware vCenter Server позволяет автоматизировать процесс загрузки и настройки серверов виртуализации ESX по сети с использованием протокола PXE. Использование Auto Deploy позволяет, во-первых, отказаться от локальных носителей для установки ESXi, что может несколько повысить надежность сервера, во-вторых, разворачивать новые серверы виртуализации, ограничиваясь тремя операциями - смонтировать сервер, скоммутировать сервер, включить сервер. :-)

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

Установка Auto Deploy
Распакуйте содержимой в любой доступный для vCenter Server каталог. Подключитесь клиентом VMware vSphere Client к серверу. Запустите мастер импорта виртуальных машин из OVF шаблона, нажав File -> Deploy OVF Template.

На первой странице мастера в поле Deploy from a file or URL укажите путь к .ova файлу из распакованного архива. Нажмите Next.

На странице OVF Template Details нажмите Next.

На странице End User License Agreement прочтите и примите лицензионное соглашение с помощью кнопки Accept и нажите Next.

На странице Name and Location задайте имя (Name) виртуальной машины и укажите ее расположение (ЦОД и папку). Нажите Next.

На странице Host / Cluster укажите сервер виртуализации или кластер, на котором будет зарегистрирована виртуальная машина. Нажмите Next.

На странице Datastore выберите хранилище, на котором будут располагаться файлы виртуальной машины. Нажмите Next.

На странице Disk Format укажите тип виртуального диска. Нажмите Next.

На странице Network Mapping привяжите виртуальный сетевой адаптер к нужному виртуальному коммутатору и группе портов. Нажмите Next.

На странице Ready to Complete нажмите Finish.

Дождитесь, пока файлы скопируются на хранилище и машина будет зарегистрирована в vCenter. Запустите виртуальную машину Auto Deploy.

Настройка Auto Deploy
Откройте консоль виртуальной машины Auto Deploy и дождитесь окончания загрузки ОС. При первом старте будет автоматически запущен мастер настройки, позволяющий задать сетевые параметры ВМ. Если в вашей сети еще не настроен DHCP сервер, можете задать статические настройки.

Затем система предложит задать пароль для административной учетной записи vi-admin. После завершения всех настроек откроется окно приветствия.

Настройка DHCP
Для автоматической выдачи сетевых параметров серверам ESXi вам потребуется развернуть сервер DHCP. Вы можете использовать DHCP сервер, встроенный в виртуальную машину или сторонний сервер DHCP в вашей сети. Для примера рассмотрим конфигурацию DHCP сервера в ОС Windows Server 2008.

Откройте консоль управления DHCP сервером. Если у вас уже настроена область с нужным диапазоном адресов, можете использовать ее, в противном случае создайте новую область.
Раскройте область, щелкните правой кнопкой мыши по Scope Options и выберите Configure Options... На вкладке General укажите в качестве значения для опции 066 Boot Server Host Name имя или IP сервера Auto Deploy.

Для опции 067 Bootfile Name впишите "undionly.kpxe.vmw-hardwired". Сохраните настройки.

Теперь можно попробовать загрузить на сервер виртуализации ESXi по сети. Зайдите на ваш сервер и в качестве предпочитаемого источника загрузки выберите сетевой адаптер. В данном примере в качестве такого сервера я использовал другую виртуальную машину.

Если вы правильно настроили DHCP и Auto Deploy, то сервер виртуализации получит необходимые сетевые настройки и начнет процесс загрузки. После ее завершения вы получите вполне работоспособный сервер ESXi, который можете настроить по собственному желанию.

Использование Host Profiles
Понятно, что в силу особенностей загрузки ESXi по сети, настройки вашего сервера и все изменения, которые вы на нем выполните сохранятся до первого выключения. И хотя сервер, развернутый в производственной среде, может не перезагружаться месяцами, а то и годами, гораздо более практичным будет использование функции Host Profiles, доступной в редакции vSphere Enterprise Plus, которая позволяет применять нужные настройки автоматически при каждой загрузке сервера.

Для создания профиля в Host Profiles вам понадобится эталонный сервер, например тот, который вы только что загрузили по сети. Для начала откройте локальную консоль и задайте пароль для учетной записи root (по умолчанию пароля нет).

Теперь зарегистрируйте сервер виртуализации в vCenter.

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

Откройте окно управления профилями Host -> Host Profiles.

Щелкните кнопкой мыши по кнопке Create Profile.

В мастере создания профиля на первой странице выберите Create Profile from existing host. Нажмите Next.

На странице Specify Reference Host укажите добавленный и настроенный вами сервер. Нажмите Next.

На странице Profile Details задайте имя и описание создаваемого профиля. Нажмите Next.

На странице Ready to complete the profile нажмите Finish.

Настоятельно рекомендуется отредактировать созданный профиль и настроить в нем автоматическое назначение пароля для учетной записи root. Для этого щелкните правой кнопкой мыши по созданному профилю и выберите Edit Profile.

В открывшемся окне раскройте Security configuration -> Administrator password, выберите Configure a fixed administrator password, задайте пароль администратора и нажмите OK для сохранения настроек.

Теперь откройте консоль управления Auto Deploy. В главном меню нажмите комбинацию клавиш Alt + F2, в поле autodeploy login введите имя учетной записи (vi-admin), в поле Password - пароль.

Нам потребуется добавить один или несколько серверов vCenter Server, в которых Auto Deploy будет регистрировать серверы виртуализации при каждой загрузке. Сделать это можно с помощью команды:
vifp addserver <АДРЕС_VCENTER>
, где: <АДРЕС_VCENTER> - DNS имя или IP адрес сервера.

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

Для проверки успешности добавления сервера можете воспользоваться командой:
vifp listservers

Для каждого сервера виртуализации, который хотя бы раз загрузился, используя Auto Deploy создается отдельная запись в базе "/var/lib/deploy/db". Для просмотра записей вы можете воспользоваться командой:
deploy-cmd listhosts

Каждую запись характеризует следующий набор параметров:

Boot MAC - MAC адрес сетевой карты, с которой осуществляется загрузка по PXE.
IP Address - IP адрес, назначенный DHCP сервером.
Asset Tag - идентификатор данного компьютера.
Boot Profile - профиль, используемый для загрузки.
Status - состояние сервера (дата последней загрузки по сети).

Вы можете создать записи для ваших серверов заранее, используя команду:
deploy-cmd addhost --bootmac=<MAC_АДРЕС> --profile=<ПРОФИЛЬ>

При каждой загрузке сервера виртуализации Auto Deploy просматривает базу и, исходя из назначенного серверу профиля, передает ему нужный загрузочный образ ESXi, а также регистрирует сервер в vCenter, применяет Host Profiles и п.р.

Для просмотра списка доступных профилей используйте команду:
deploy-cmd listprofiles

По умолчанию в Auto Deploy присутствует лишь один профиль - default. Для редактирования настроек профиля используется команда deploy-cmd updateprofile:
deploy-cmd updateprofile --name=default --vcenter=<АДРЕС_VCENTER> --hostprofile=<ИМЯ_HOST_PROFILE> --hostfolder=<ПУТЬ_К_ПАПКЕ>
, где: <ПУТЬ_К_ПАПКЕ> - путь, включающий в себя имя датацентра, в котором требуется зарегистрировать сервер виртуализации. При необходимости включения сервер в HA кластер, путь к папке можно указать в формате "/<ИМЯ_ДАТАЦЕНТРА>/<ИМЯ_КЛАСТЕРА>".

Например, следующая команда позволит настроит профиль default так, чтобы Auto Deploy автоматически регистрировал серверы в vCenter и применял к ним ранее созданный Host Profile:

Теперь перезагрузите сервер. Если вы выполнили все настройки правильно, то после загрузки сервер будет автоматически добавлен в vCenter, переведен в режиме обслуживания (Maintenance Mode), для него будут применены настройки из соответствующего профиля, после чего он будет переведен обратно в штатный режим работы.

Дополнительные сведения
Для всех серверов настоятельно рекомендуется создавать резервации в DHCP, это позволит серверу не только получать каждый раз один и тот же IP адрес, но и задавать ряд индивидуальных настроек, в частности - имя сервера (параметр 012 Host Name).

Если вас не устраивает, что в vCenter серверы ESXi регистрируются по IP адресу, а не по DNS имени, то исправить это можно, создав соответствующие PTR записи в reversed lookup зоне на DNS сервере, который обслуживает vCenter.

Наконец, я заметил следующую закономерность. При тестах использовались виртуальные серверы ESXi. Частенько при добавлении такого сервера в кластер, если для него выделено меньше 3 Гб памяти, можно получить следующее сообщение об ошибке: "Cannot complete the configuration of the HA agent on the host. Other HA configuration error".

Заключение
Как вы видите VMware Auto Deploy крайне прост в настройке и работе. Тем не менее, его применение рождает следующие вопросы - кто же будет загружать виртуальные машины с Auto Deploy и vCenter, чтобы те, в свою очередь, загружали серверы виртуализации, почему функционал Host Profiles доступен только в редакции Enterprise Plus, и когда в профилях появится поддержка программного инициатора iSCSI?

Установка приложений в среде VMware View 4.5 + ThinApp 4.6

2010-10-22T08:00:00.001+04:00

Рабочие станции, пускай и виртуальные, предназначены, в первую очередь, для запуска пользовательских приложений. А чтобы запустить приложение, требуется его установить (а иногда и купить). По этой причине сегодня мы рассмотрим различные варианты установки приложений, виртуализованных с помощью VMware ThinApp 4.6, которые можно использовать для виртуальных рабочих станций, а в частности - для VMware View 4.5.

Варианты установки
Установка приложений в мастер-образ. Многие распространенные приложения, не требующие частых обновлений, такие как архиваторы или программы для чтения документов и просмотра изображений могут быть установлены в эталонный образ, который послужит основой для создания виртуальных рабочих станций. Однако не следует увлекаться и записывать в мастер-образ весь возможный набор приложений. Во-первых, пользователь может запутаться от обилия ярлыков на рабочем столе (должно же на нем еще оставаться место, что хранить документы и папки) и запустить что-то ненужное, во-вторых, увеличит занимаемое клонированными образами дисковое пространство, в-третьих, усложнит процедуру администрирования рабочих станций и обновления приложений. Хотя при назначении разрешений на запуск приложений с помощью ThinApp или групповых политик, использовании дифференциальных дисков (Linked Clones) и функции Recompose вы можете достаточно просто решить эти проблемы.

Копирование и установка приложений вручную. Администратор может выполнять установку отдельных приложений, подключаясь к рабочей станции через vSphere Client или RDP. Кроме того существует простая и функциональная утилита psexec, позволяющая запускать программы и выполнять команды на удаленном компьютере без необходимости отвлекать пользователей от работы. Для установки приложений можно воспользоваться командой вроде этой:
psexec \\<имя_компьютера> /u <имя_пользователя> msiexec /i \\<имя_сервера>\<путь_к_установочному_файлу> /qn

Для некоторых приложений вы можете разрешить рядовым пользователям без административных прав самостоятельно производить установку. В этом случае приложение будет установлено в каталог %AppData% пользователя вместо %ProgramFiles% и будет доступно лишь этому пользователю. Такой вариант может является предпочтительным для приложений вроде текстовых редакторов или программ обмена мгновенными сообщениями. Для включения режима индивидуальной установки при упаковке приложения с помощью ThinApp требуется отредактировать параметр MSIDefaultInstallAllUsers в файле Package.ini и установить его значение в 0.

Для этого выполните следующие действия. При создании пакетированного приложения с помощью ThinApp в окне Package Settings выберите Generate MSI Package.

Перед финальной сборкой в окне Ready to Build нажмите Edit Package.ini.

При желании вы можете задать параметр MSIDefaultInstallAllUsers=2 и разрешить как административную установку для всех пользователей, так и индивидуальную установку (в зависимости от прав, которыми обладает учетная запись, от имени которой был запущен установочный файл).

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

Использование средств электронной дистрибуции ПО (например, Microsoft SCCM 2007). Наиболее функциональный вариант из представленных, позволяет полностью автоматизировать процесс установки, а также проводить инвентаризацию ПО, хотя и требует покупки дополнительных лицензий, установки агентов и настройки серверов управления.

Наконец, начиная с версии 4.5 в VMware View есть собственные встроенные механизмы публикации приложений, виртуализованных с помощью ThinApp. Публиковать приложения можно на пул или на отдельные виртуальные рабочие станции.

VMware View предоставляет на выбор два режима установки:

В полном (Full) режиме приложение устанавливается на виртуальную рабочую станцию, создает ярлык на рабочем столе и настраивает ассоциации с нужными типами файлов. Процесс установки выполняется в фоновом режиме и не требует от пользователей каких-либо действий. Запуск приложения выполняется с диска виртуальной рабочей станции.
В потоковом (Streaming) режиме на рабочем столе пользователя создается ярлык, указывающий на исполняемый файл .exe приложения, расположенный на файловом сервере. Запуск приложения выполняется с общей сетевой папки файлового сервера. Такой вариант установки с одной стороны позволит сэкономить место на хранилище, на котором располагаются диски виртуальных рабочих станций, особенно в случае, когда пользователи запускают одинаковый набор приложений, с другой - приведет к увеличению нагрузки на сеть. Также учтите, что в случае отсутствия доступа к файловому серверу, например, при запуске ВМ в Local Mode режиме, приложения не смогут запуститься.

Пример публикации приложений с помощью VMware View
Перед тем, как опубликовать приложение вам потребуется соответствующим образом упаковать его с помощью Setup Capture, входящего в состав VMware ThinApp 4.6. Для режима полной установки достаточно будет создать .msi файл, содержащий нужное приложение.

Для Streaming режима перед сборкой вам потребуется отредактировать файл настроек Package.ini и установить параметр MSIStreaming=1. В этом случае после создания пакета размер .msi файла не превысит нескольких мегабайт и для корректной установки вам потребуется сохранять его вместе с созданным .exe файлом.

После завершения создания пакетов приложений скопируйте их в общую папку на файловом сервере. Убедитесь, что сервер View Connection Server и виртуальные рабочие станции имеют доступ к данной папке. Учтите, что в Streaming режиме доступ к папке будет осуществлять из-под учетной записи пользователя, запускающего приложение. В большинстве случаев стандартных разрешений будет достаточно.

Запустите консоль View Administrator добавьте общую папку файлового сервера в список репозиториев: View Configuration -> ThinApp Configuration кнопка Add Repository.

В поле Display Name введите имя репозитория, в поле Share path введите UNC путь к общей папке, содержащей упакованные приложения (в формате \\<имя_сервера>\<имя_папки>). При желании можете добавить дополнительное описание в поле Description.

Нажмите Save.

Просканируйте и добавьте приложения в список доступных. В консоли View Administrator выберите Inventory -> ThinApps. На вкладке Summary нажмите Scan New ThinApps.

Выберите одно из расположений, добавленных ранее и папку для сканирования, и нажмите Next.

Выберите одно или несколько (с помощью зажатых клавиш CTRL или SHIFT) приложений из списка доступных и нажмите Scan.

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

Добавленные приложения появятся в окне на вкладке Summary.

Для назначения приложений вы можете воспользоваться той же вкладкой Inventory -> ThinApps. Выберите необходимое приложение из списка и нажмите Add Assigment и в контекстном меню выберите область назначения - на пул (Pools...) или на рабочие станции (Desktops...).

В открывшемся окне выберите один из двух доступных типов установки (Installation type): Streaming или Full и с помощью кнопки Add... добавьте один или несколько пулов или рабочих станций на которые требуется назначить приложение. Нажмите OK для сохранения настроек.

Теперь пользователям достаточно будет подключиться к своим рабочим станциям и приложение будет автоматически установлено. Учтите, что при использовании Full режима в зависимости от размера приложения для копирования и установки может потребоваться некоторое время, поэтому ярлык может появится не сразу.

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

Для обновления приложения вам потребуется выполнить следующие шаги:

Удалить назначенное приложение (Remove Assigment) с пула или рабочих станций.
Подождать, пока все пользователи войдут на свои рабочие станции, чтобы устаревшая версия приложения удалилась.
Удалить устаревшее приложение из списка ThinApps.
Скопировать обновленную версию приложения на файловый сервер и добавить его в список ThinApps.
Назначить обновленную версию приложения на пул или рабочую станцию.
Подождать, пока все пользователи войдут на свои рабочие станции, чтобы обновленная версия приложения установилась.

Не слишком просто и быстрый вариант, учитывая, что из-за некоторых пользователей процесс обновления может растянуться на несколько дней. С другой стороны, для Linked Clones машин также может быть выполнен Refresh, который вернет виртуальную машину к исходному состоянию и удалит установленные приложения.

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

Более корректным вариантом является использование встроенного механизма обновления, поддерживаемого в ThinApp - исполняемый файл обновленной версии приложения переименовывается из <имя_приложения>.exe в <имя_приложения>.1 (например, "Adobe Reader.1") и помещается в ту же папку, что и исполняемый файл старого приложения. При следующем запуске приложение автоматически обнаружит наличие обновленной версии и запустит ее. При этом пользователи, работающие с текущей версией приложения, смогут продолжать с ней работать до следующего запуска. При необходимости последующего обновления приложения вы можете просто добавлять новые версии .3 или .4 и удалять устаревшие .1 или .2, по мере того, как пользователи будут прекращать работать с ними.

Для Full режима установки ситуация несколько отличается. Вы можете настроить приложение на автоматическую проверку обновленной версии при каждом запуске, указав при создании пакета в параметре AppSyncURL в файле Package.ini путь к обновленной версии на файловом сервере в формате file://<имя_сервера>/<путь_к_файлу> или http://<имя_сервера>/<путь_к_файлу> (например: "file://Fileserver/Software/Firefox/Firefox.exe").

Но поскольку приложение в Full режиме копируется в подпапку в %ProgramFiles%, то для для выполнения установки у учетной записи должны быть права локального администратора, либо права на запись в указанную папку, что довольно рискованно делать для рядовых пользователей даже на индивидуальных виртуальных рабочих станций.

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

На сегодня всё.

Статья: Сравнение решений компаний Microsoft и VMware в области виртуализации серверной инфраструктуры

2010-09-26T08:00:00.003+04:00

Каждый уважающий себя ресурс по виртуализации хотя бы раз в жизни должен опубликовать сравнение решений Microsoft и VMware. И поскольку VM Press наполнен сам к себе ~~глубоким~~ глубочайшим уважением, то я решил немного подправить свою старую статью, которую делал для знакомых, и представить ее вашему вниманию.

Введение
На сегодняшний день все больше компаний применяют различные решения по виртуализации в своей ИТ инфраструктуре. Так, например, по оценкам аналитического агенства IDC в четвертом квартале 2009 года 18.2% всех поставляемых на рынок серверов использовали те или иные решения по виртуализации. Цифры выглядят не слишком впечатляющими, если не брать в расчет тот факт, что на одном физическом сервере может размещаться, в среднем, от 5-ти до 10 виртуальных машин. Именно за счет столь впечатляющих показателей консолидации вычислительных ресурсов, многие компании рассматривают виртуализацию как основное средство повышения эффективности работы собственной ИТ инфраструктуры.

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

Двумя крупнейшими игроками, предоставляющими решения по виртуализации инфраструктуры, являются компании VMware и Microsoft. Обе компании предлагают различные подходы к организации виртуальной инфраструктуры и предоставляют собственный набор фирменных технологий и решений в области виртуализации.

Ниже будут рассмотрены ключевые особенности организации виртуальной инфраструктуры на базе VMware vSphere 4.1 и Microsoft Hyper-V 2008 R2 и Microsoft System Center Virtual Machine Manager 2008 R2 и описаны преимущества каждого из решений по виртуализации.

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

Компания VMware предоставляет комплексное решение по виртуализации инфраструктуры – VMware vSphere 4.1, которое включает в себя как серверы виртуализации (гипервизоры), так и инструменты управления инфраструктурой.

На выбор доступны два варианта гипервизоров – VMware ESXi или VMware ESX. Основное отличие гипервизоров заключается в наличии у VMware ESX так называемой служебной консоли (Service Console) – специализированной виртуальной машины, отвечающей за управление сервером ESX и позволяющей устанавливать программы-агенты сторонних производителей (средства мониторинга и контроля дисковых массиов, переферийного оборудования, ИБП и т.д.). VMware ESXi, в свою очередь, имеет меньший размер, что позволяет записать его, например, на flash накопитель, позволяя отказаться от размещения жестких дисков внутри сервера, снижая, тем самым, энергопотребление и тепловыделение сервера и повышая его надежность за счет уменьшения количества механических компонентов.
Отличительными особенностями гипервизоров VMware ESX/ESXi являются:

Поддержка большинства современных и унаследованных ОС семейств Windows, Linux или Unix.
Хранение и запуск виртуальных машин с локальных дисков или хранилищ (DAS), сетей хранения данных (SAN), подключающихся по протоколам Fibre Channel, iSCSI, а также сетевых хранилищ (NAS), использующих протокол NFS.
Поддержка кластерной файловой системе VMFS для доступа к виртуальным машинам одновременно с нескольких узлов.
Удаленное управление с помощью клиент VMware vSphere Client, с помощью консоли SSH, набора скриптов (RemoteCLI) или модуля расширения для PowerShell (PowerCLI).
Поддержка технологий управления и экономии оперативной памятью (Memory Overcommitment), позволяющих улучшить показатели консолидации инфраструктуры по сравнению с решениями конкурентов.
Поддержка проброса в отдельные виртуальные машины физических устройств с сервера (VMDirectPath I/O), а также устройств, подключенных по шинам USB (USB device passthrough) или COM.
Возможность настройки последовательности и интервала запуска виртуальных машин при старте или перезагрузке физического сервера.
Поддержка ˈгорячегоˈ добавления виртуальных устройств: процессоров, памяти, дисков, контроллеров и сетевых карт.

Компания Microsoft предоставляет гипервизор Hyper-V R2 в качестве одной из ролей своей ОС Windows Server 2008 R2 (Hyper-V Role), либо отдельного продукта – Hyper-V Server 2008 R2. Среди особенностей Microsoft Hyper-V 2008 R2 следует отметить:

Небольшой размер кода гипервизора.
Поддержку широкого перечня современного аппаратного обеспечения.
Наличие родительской виртуальной машины (Parent Partition) для управления сервером Hyper-V и распределения ресурсов другим виртуальным машинам (Child Partition).
Возможность размещения виртуальных машин на локальных дисках или на СХД, подключаемых по протоколам SCSI, Fibre Channel или iSCSI.
Управление через MMC консоль Hyper-V Manager, или с помощью средств командной строки (Powershell, CMD и т.д.).
Поддержку отказоустойчивых кластеров (Failover Cluster), включих до 16 узлов.
Поддержку переноса виртуальных машин с одного узла кластера на другой – Live Migration.
Интеграцию с доменной инфраструктурой на базе Active Directory.
Наличие встроенных средств резервного копирования и восстановления виртуальных машин с помощью Windows Server Backup.
Совместную интеграцию со службами Microsoft Remote Desktop Services для развертывания инфраструктуры виртуальных рабочих станций (VDI).

Централизованное управление
Для крупной ИТ инфраструктуры, насчитывающей десятки или даже сотни серверов виртуализации, работа с каждым сервером в отдельности может стать весьма утомительным и трудоемким занятием. Для решения этой проблемы VMware и Microsoft предлагают свои решения по централизованному управлению виртуальной инфраструктурой.

VMware vCenter Server позволяет:

Централизованно управлять серверами ESX/ESXi. Несколько серверов vCenter Server могут быть объединены в связанную группу (Linked Groups) для контроля всей виртуальной инфраструктурой из единой консоли.
Создавать виртуальные машины копированием из заранее настроенных шаблонов для упрощения и ускорения развертывания новых серверов.
Выполнять автоматическое обновление виртуальных машин, шаблонов и других компонентов виртуальной инфраструктуры с помощью VMware vCenter Update Manager.
Контролировать и динамически перераспределять вычислительные ресурсы серверов виртуализации (процессоры, память, диски) при помощи пулов ресурсов (Resource Pool).
Настраивать кластеры высокой доступности (High Availability) и управлять кластерами с распределением ресурсов (Distributed Resource Schedule).
Выполнять операции переноса виртуальных машин (vMotion и Storage vMotion).
Мигрировать при помощи VMware vCenter Converter в виртуальную среду существующие физические серверы и виртуальные серверы с других платформ.
Следить за состоянием гипервизоров и виртуальных машин, создавать отчеты по текущей загрузке инфраструктуры и настраивать выполнение задач по расписанию.
Настраивать разрешения на управление виртуальной инфраструктурой для учетных записей пользователей.
Создавать и настраивать распределенные виртуальные коммутаторы (Distributed vSwitches) для централизованного управления виртуальной сетевой инфраструкторой.
Использовать профили узлов (Hosted Profiles) для быстрого изменения настроек серверов ESX и контроля изменений в их конфигурации.
Подключать плагины сторонних производителей для управления виртуальной инфраструктой (системами резервного копирования, средствами конвертирования виртуальных машин, антивирусной защитой, управления СХД и т.д.).
Интегрироваться с VMware View и Citrix XenDesktop для создания инфраструктуры виртуальных рабочих станций (VDI).

Решение Microsoft System Center Virtual Machine Manager 2008 R2 предоставляет следующий функционал:

Единую консоль управление серверами виртуализации Microsoft Hyper-V и Microsoft Virtual Server 2005 и
Поддержку управления серверами VMware ESX/ESXi с помощью vCenter Server.
Поддержку развертывания виртуальных машин из шаблонов.
Использование библиотек (SCVMM Library) для хранения и организации централизованного доступа к ISO образам дистрибутивов, дискам и шаблонам виртуальных машин.
Установку актуальных обновлений для виртуальных маши, используя Offline Virtual Machine Servicing Tool.
Встроенные средства по миграции физических серверов (P2V) и виртуальных серверов (V2V) в инфраструктуру Hyper-V.
Использование портала самообслуживание для управления виртуальными машинами из Web браузера.
Выполнение операции Quick Storage Migration для переноса виртуальных машин между хранилищами.
Интеграцию с Microsoft System Center Operation Manager 2007.
Интеграцию с Citrix XenDesktop для создания инфраструктуры виртуальных рабочих станций (VDI).
Поддержку удаленного управления с помощью коммандлет PowerShell.

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

Так, например, технологии VMware vMotion и Microsoft Live Migration обеспечивают перенос работающих машин с одного физического узла на другой в реальном времени без остановки и простоя служб. Это может быть полезно как при проведении технического обслуживание одного из серверов виртуализации, так и при постепенной замене оборудования или обновлении инфраструктуры виртуализации. Аналогично, при необходимости переноса виртуальной машины с одного диска или хранилища на другое могу быть использованы технологии VMware Storage vMotion или Microsoft Quick Storage Migration.

Для снижения времени незапланированного простоя виртуальной среды применяются решения VMware High Availability и Microsoft Failover Cluster. Все защищаемые виртуальные машины должны располагаться на общем хранилище к которому имеют доступ несколько узлов виртуализации, объединенных в кластер. Сбой или отказ одного из узлов отслеживается остальными участниками кластера, а запущенные на нем виртуальные машины автоматически регистрируются и перезапускаются на оставшихся работоспособных узлах. Использование кластеров высокой доступности позволяет уменьшить время незапланированного простоя серверов до 5-20 минут.

Серверы VMware ESX поддерживают организацию двух типов кластеров: высокодоступные кластеры (HA – High Availability) и кластеров с распределением ресурсов (DRS – Distributed Resource Schedule).

Для первоначальной настройки кластера HA, требуется, чтобы все узлы были зарегистрированы на одном сервере VMware vCenter Server, а также были подключены к общему хранилищу, на котором располагаются виртуальные машины. При отказе одного сервера, работавшие на нем виртуальные машины автоматически перезапускаются на других доступных узлах HA кластера.

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

Одной из разновидностей DRS кластера является кластер распределенного управления питанием (DPM – Distributed Power Management), позволяющий выключать часть серверов ESX при низкой загрузке на серверы, снижая тем самым энергопотребление, и включая их снова, при возникновении потребности виртуальных машин в вычислительных ресурсах.

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

Для защиты виртуальных машин Hyper-V от незапланированного простоя используются отказоустойчивые кластеры (Failover Cluster), построенные на базе служб Microsoft Clustering Services, доступных. Для кластера требуется наличие общего дискового хранилища для размещения виртуальных машин, а также доменной инфраструктуры Active Directory.

Системая мониторинга и управления ресурсами (PRO Tips) в SCVMM 2008 R2, работающая совместно с SCOM 2007 R2, отслеживает разничные параметры виртуальной инфраструктуры: доступные вычислительные ресурсы, загрузку физических и виртуальных машин, наличие ошибок в работе различных компонентов и служб, и на основании полученных данных выдавать рекомендации по оптимальному размещению виртуальных машин на кластерах серверов Hyper-V.

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

VMware Data Recovery (VDR) позволяет осуществлять централизованное резервное копирование виртуальных машин VMware ESX на локальные диски или сетевую папку по расписанию. Преимущество VDR заключается в использовании технологии дедупликации данных, которая позволяет уменьшать размер резервной копии. VDR позволяет восстанавливать как виртуальные машины целиком, так и отдельные папки и файлы.

Microsoft DPM 2010 позволяет выполнять резервное копирование и восстановление виртуальных машин, расположенных на серверах Hyper-V, а также устанавливать агенты внутри виртуальных машин для резервирования данных приложений (баз SQL серверов, почтовых ящиков Exchange и порталов SharePoint).

Лицензирование
Оба вендора предоставляют решения как для малого и среднего бизнесы, так и для крупных компаний.
Для небольших компаний или удаленных филиалов с несколькими серверами, которым не требуется централизованное управление, доступна бесплатная версия VMware ESXi Free.

Компаниям, испытывающим необходимость в централизованном управлении виртуальной инфраструктурой, предлагаются VMware vSphere Essentials и Essentials Plus, в которые входят лицензии на три двухпроцессорных сервера и одна лицензий VMware vSphere Essentials. Дополнительно, в лицензии Essentials Plus доступны средства резервного копирования VMware Data Recovery, организации HA кластера и выполнения переноса vMotion между узлами.

Для средних и крупных компаний доступны различные типы лицензий для серверов ESX (редакции от Standard до Enterprise Plus) и vCenter Server (редакции Foundation или Standard), обеспечивающих требуемый функционал.

При выборе решений от компании Microsoft, возможно использование гипервизора входящего в состав ОС Windows Server 2008 R2 в редакциях Standard, Enterprise или Datacenter, либо поставляемого в виде отдельного бесплатного продукта Microsoft Hyper-V Server 2008 R2.

Для централизованного управления небольшой инфраструктурой Hyper-V могут применяться продукты System Center Essentials 2010 или System Center Virtual Machine Manager 2008 R2 Workgroup Edition (позволяет управлять пятью серверами виртуализации).

Для средних и крупных компаний доступен SCVMM 2008 R2 в качестве отдельного продукта, либо в составе пакетов лицензий System Center Server Management Suite Enterprise (SMSE) и Datacenter (SMSD), включающих в себя, помимо SCVMM, другие продукты линейки System Center (SCCM, SCOM, SCDPM и т.п.) и предоставляющие расширенные права на установку агентов и управление виртуальными машинами, запущенными на лицензированном сервере.

Заключение
Как видите обе компании предлагают функциональные, гибкие и надежные решения по организации и управлению виртуальной средой Вашей компании. Выбор же конкретного продукта зависит от размера организации, и, само-собой, от тех требований, которые бизнес предъявляет к современной ИТ инфраструктуре: функциональность, доступность, экономичность и простота в управлении. Чего и позволяет добиться серверная виртуализация.

Использование функции RemoteApp for Hyper-V для работы с устаревшими приложениями

2010-09-23T08:00:00.039+04:00

С выходом Windows Server 2008 (Terminal Services, ныне Remote Desktop Services) у пользователей появилась возможность подключаться не только к удаленному рабочем столу, но и к отдельным опубликованным приложениям (RemoteApp или т.н. Seamless Mode). Данный режим существенно облегчает работу, позволяя перенести выполнение большинства приложений на терминальный сервер прозрачно для пользователей.

Тем не менее, во многих организациях до сих пор используются различные устаревшие приложения, которые не могут выполняться на ОС Windows Server 2008 и выше, что может препятствовать переходу на новые ОС. Данную проблему можно решить различными способами, например, используя решения сторонних производителей (например, Citrix XenApp) или запуская виртуальную машину на локальной рабочей станции пользователя (Windows XP Mode или MED-V), однако есть и другой вариант.

Для клиентских ОС существует возможность публикации отдельных приложений с организацией удаленного доступа к ним по протоколу RDP (RemoteApp for Hyper-V).

Как и в классическом варианте терминального доступа в режиме RemoteApp for Hyper-V существует хост - виртуальная машина с установленными приложениями, к котором требуется обеспечить удаленный доступ и клиент - устройство, за которым работает пользователь.

Microsoft предоставляет на выбор два сценария публикации:

В Standalone режиме администратор создает .rdp файл, в котором указывает название приложения и имя хоста, к которому планирует подключаться один или несколько пользователь. Для каждого публикуемого приложения должен быть создан отдельный .rdp файл. Кроме того, в силу ограничений клиентских ОС, на хосте может быть активной лишь одна пользовательская сессия, иными словами, только один пользователь сможет получить доступ к опубликованным приложениям на данном хосте. Хотя данный вариант не требует установки дополнительных служб и компонентов, но может быть сложен в управлении и обслуживании при наличии большого количества хостов и публикуемых приложений.
VDI конфигурация предполагает развертывание полноценной инфраструктуры виртуализации рабочих станций на базе сервера виртуализации Hyper-V, Remote Desktop Session Host и Connection Broker из состава Windows Server 2008 R2. Данный вариант обеспечивает единую точку подключения ко всем публикуемым приложениям, отслеживает активные сеансы пользователей, дабы избежать одновременного подключения сразу к нескольким хостам, однако не избавляет администраторов от необходимости создавать .rdp файлы и выполнять настройку виртуальных машин.

В качестве хостовой ОС для публикации приложений поддерживаются следующие ОС:

Windows XP x32 Professional SP3;
Windows Vista x32 SP1 или выше в редакции Enterprise или Ultimate;
Windows 7 x32 в редакции Enterprise или Ultimate.

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

В качестве клиентской ОС с которой выполняются подключения, поддерживается Windows 7 x32 или x64 (однако, в роли клиентов также могут выступать Windows XP и Windows Vista с установленным клиентом RDP Client 7.0).

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

Перед тем, как переходить к самой процедуре настройки хостовой машины, вам потребуется установить актуальную версию клиента RDP (RDP Client 7.0) для соответствующей версии ОС и обновление, включающее функционал RemoteApp for Hyper-V (ссылки приведены выше). После установки обновления на компьютер потребуется его перезагрузить.

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

Откройте редактор реестра (regedit) на хостеовой машине и измените параметр fDisabledAllowList расположенный в HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList, установив его значение в 1.

Запустите клиент RDP, укажите имя хоста, к которому требуется подключиться, и сохраните файл конфигурации (.rdp), нажав Save As.

Откройте созданный файл в текстовом редакторе, найдите строчки и замените их значения на приведенные ниже:
Alternate shell:s:rdpinit.exe

RemoteApplicationMode:i:1

Добавьте в файл следующие строчки:
RemoteApplicationName:s:<ИМЯ_ПРИЛОЖЕНИЯ>

RemoteApplicationProgram:s:<ПУТЬ_К_ФАЙЛУ>

DisableRemoteAppCapsCheck:i:1

Prompt For Credentials on Client:i:1

, где <ИМЯ_ПРИЛОЖЕНИЯ> - описательное имя приложения (например, Notepad);

<ПУТЬ_К_ФАЙЛУ> - полный путь к исполняемому файлу приложения (например, "C:\Windows\System32\Notepad.exe").

Пример модифицированного файла показан на рисунке:

Сохраните файл и перенесите его на клиентский компьютер.

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

Учтите, что если вы планируете использовать один и тот же хост для подключения нескольких пользователей поочередно, то крайне желательно настроить автоматическое завершение сеанса после отключения пользователя. Сделать это можно отредактировав групповые политики хоста (через локальные или доменные групповые политики). Интересующая Set time limit for disconnected sessions настройка находится:
Для Windows XP: Computer Configuration -> Administrative Templates -> Windows Components -> Terminal Services -> Sessions
Для Windows Vista: Computer Configuration -> Administrative Templates -> Windows Components -> Terminal Services -> Terminal Server -> Session Time Limits
Для Windows 7: Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Session Time Limits

Установите значение параметра в Enable и укажите интервал отключения через 1 минуту.

При подготовке статьи использовались следующие материалы:

RemoteApp for Hyper-V (VDI) Deployment.

Работаем с App-V (часть IV)

2010-08-17T08:00:00.268+04:00

Продолжая цикл статей и заметок об App-V, я хотел бы рассказать о возможности публикации и загрузки пакетов приложений с использованием Web-сервера.

Данный вариант доступа может быть полезен для пользователей работающих за пределами локальной сети и не имеющих возможности подключаться к серверам по протоколу RTSP или SMB для загрузки пакетов приложений.

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

С настройкой загрузки файлов по HTTP нет ничего сложного.

Чтобы клиент App-V определил, что загрузка .sft пакета должна осуществляться по протоколу HTTP, вам нужно отредактировать .osd файл. Откройте нужный пакет в программе-упаковщике Sequencer, и на вкладке Deployment в качестве протокола выберите HTTP или HTTPS, а также задайте имя сервера (Hostname) и путь (Path) к web-директории, где будет располагаться .sft файл.

При желании, вы можете вручную отредактировать .osd, прописав в параметре CODEBASE HREF= полный путь к .sft файлу.

Далее вам потребуется установить Web-сервер, на котором будут располагаться пакеты приложений. В качестве примера возьмем IIS 7.0.

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

ASP.Net
ASP
Integrated Authentication

После установки откройте консоль управления IIS, выберите web-сайт и добавьте новую web-директорию, в которой в дальнейшем будут располагать пакеты приложений. Перейдите в созданную директорию в секции IIS, выберите Directory Browsing и включите (Enable) возможность просмотра содержимого папки.

Также вам потребуется задать MIME Types для корректной обработки расширений файлов Web-сервером. Для этого выберите ваш сайт и в секции IIS выберите MIME Types.

С помощью кнопки Add... задайте MIME типы для следующих расширений файлов.

Расширение: .osd, MIME type: application/softricity-osd
Расширение: .sft, MIME type: application/softricity-sft
Расширение: .sprj, MIME type: application/softricity-sprj

После этого скопируйте пакет в соответствующую директорию на Web-сервере. В данном примере пакеты приложений располагаются в отдельных дочерних папках внутри главной директории.

Если вы планируете, чтобы клиенты самостоятельно подключались к Web-серверу и получали список опубликованных пакетов вам предстоит выполнить еще ряд действий.

Для получения информации о доступных пакетах клиенты используют файл-описатель (manifest) в формате .xml.

Данный файл автоматически создается при пакетировании приложения и располагается в той же директории, что и остальные файлы.

Структура файла выглядит следующим образом.

Информация об приложениях находится внутри секции <APPLIST><APP></APP></APPLIST>.

Обратите внимание на переменную %SFT_MIME_SOURCE%, присутствующую в файле-описателе. С ее помощью клиент определяет абсолютный путь к файлу .osd и изображениям ярлыков приложения. Значение переменной можно задать при установке или при помощи групповых политик, а также отредактировав соответствующие ключи реестра:
HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration\IconSourceRoot
HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration\OSDSourceRoot

Использование переменной %SFT_MIME_SOURCE% вместо жесткого прописывания абсолютного пути может быть полезно в случае, когда у вас в компании есть несколько мобильных пользователей, переезжающих с места на место. В этом случае, с помощью групповых политик вы можете задавать путь к ближайшему дистрибутивному серверу для ускорения процедуры загрузки новых опубликованных пакетов. Аналогичным образом вы можете менять ключ HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration\ApplicationSourceRoot для изменения пути к пакету .sft, указанном в .osd файле.

Еще один момент на который стоит обратить внимание - если вы планируете размещать содержимое каждого пакета не в корневой папке, а в отдельной директории (например, "App-V/Adobe9"), вам, все-таки, придется отредактировать файл-описатель .xml, добавив после %SFT_MIME_SOURCE% имя дочерней папки.

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

Вариант с использованием скрипта достаточно подробно описан (например, здесь), кроме того, John Sheehan выложил пример скрипта для создания файла-описателя на C#. Исходный код сценариев с небольшими правками вы можете загрузить отсюда или отсюда.

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

Скрипт ищет файлы с именем _manifest.xml во всех подпапках, копирует из них информацию о приложениях, после чего генерирует файл в формате .xml и отдает его клиенту.

Все, что вам осталось - это настроить клиентов на Web-сервер публикаций. Сделать это можно в процессе установки клиента, как описано в данной статье, либо вручную.

В консоли Application Virtualization Client щелкните правой кнопкой мыши по Publishing Servers и выберите New.

В мастере New Publishing Server укажите тип публикации (Type) и задайте отображаемое имя (Display Name). Нажмите Next.

Укажите имя Web-сервера (Host Name) и путь к скрипту публикации (Path).

Для завершения настроек нажмите Finish.

Если для публикации приложения вы использовали переменную %SFT_MIME_SOURCE% не забудьте изменить соответствующие ключи реестра.

Теперь настало время для тестов.

Нажмите правой кнопкой мыши по созданной записи сервера публикации и нажмите Обновить Сервер (Refresh Server). Если вы правильно указали пути в файле-описателе процесс должен будет отработать без ошибок.

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

Если на каком-то этапе у вас возникли ошибки, можете проверить журнал событий приложений.

Скорее всего, вы некорректно задали путь к .osd или .sft файлу и клиент App-V не может их обнаружить.

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

Вместо анонимной аутентификации на сервере вы можете включить Integrated аутентификацию (для всего сервера, или для отдельных папок), после чего предоставить разрешения на уровне NTFS на соответствующую папку требуемому пользователю или группе (например, "App-V <Имя_приложения> Users"). Для этого в консоли IIS, выбрав нужную директорию с приложением, в секции IIS выберите Authentication. Включите (Enable) тип аутентификации Windows Authentication.

При использовании скрипта publishing.aspx, пользователь, не имея достаточных прав, просто не сможет зайти в данную папку, а значит, в созданном файле-описателе не будет информации об этом приложении. Для отмены возможности входа под анонимным пользователем достаточно удалить права у группы Users на соответствующую папку.

На этом знакомство с публикацией пакетов App-V с помощью HTTP можно считать завершенным.

Средства аудита инфраструктуры

2010-08-10T08:00:00.002+04:00

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

Сбор общей информации об инфраструктуре

Microsoft Assessment & Planning Toolkit (MAPT) - одна из лучших утилит по инвентаризации серверов и рабочих станций в сети. Позволяет использовать различные варианты обнаружения компьютеров, включая поиск в Active Directory, через сетевое окружение, в указанном диапазоне IP адресов, импортирование имен из текстового файла.

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

Для хранения собранных данных используется база SQL сервера (поддерживается SQL Server 2008 Express Edition).

Сильной стороной утилиты является возможность генерации различных отчетов в формате xls (по версиям ОС, сетевой или аппаратной конфигурации, установленным в организации серверам SQL и т.д.).

Active Directory Topology Diagrammer (ADTD) - утилита для построения диаграмм и схем в Visio (поддерживает Vision 2003 / 2007) на основе данных, собранных из AD.

ADTD позволяет строить диаграммы: лесов, доверительных отношений и доменов, существующей иерархии организационных подразделений, почтовых серверов Exchange и коннекторов отправителей, организации сайтов и настройки репликации.

Следующая утилита - Microsoft IT Environment Health Scanner позволяет проверить общее состояние вашей инфраструктуры. Среди проверяемых параметров:

Конфигурация сайтов и подсетей Active Directory.
Состояние репликации Active Directory с использование DFS и FRS.
Разрешение имен с помощью DNS.
Настройка сетевых адаптеров на всех контроллерах домена
Конфигурация серверов DNS и почтовых серверов Microsoft Exchange.
Ошибки в журналах событий, связанных с работой домена

Результат работы программы экспортируется в html файл.

При наличии ошибок или предупреждений в результирующий отчет также будет добавлено краткое описание проблемы и дана ссылка на статью из базы знаний Microsoft. Загрузить Microsoft IT Environment Health Scanner можно отсюда.

Для сбора информации о групповых политиках можно воспользоваться скриптами ListSOMPolicyTree.wsf и GetReportsForAllGPOs.wsf, входящими в состав Group Policy Management Console (GPMC).
ListSOMPolicyTree.wsf выводит структуру организационных подразделений Active Directory с указанием всех примененных к ним групповых политик.

GetReportsForAllGPOs.wsf генерирует отчеты в формате html по всем созданным групповым политикам в указанной папке.

Из сторонних программ неплохо себя зарекомендовала ADScribe от компании LEADUM Software. Как нетрудно догадаться, ADScribe собирает информацию об объектах каталога Active Directory (пользователях, группах, компьютерах, контактах, организационных подразделениях, принтерах), сайтах и групповых политиках и сохраняет их в виде единого справочного chm или html файла. Программа может быть запущена с любого компьютера, входящего в обследуемый домен, при наличии у пользователя соответствующих прав.

К сожалению, ADScribe несовместима с 64-разрядными ОС (проявляется в виде проблемы с регистрацией библиотеки msxml.dll). Для ознакомления доступна полнофункциональная trial версия на 15 дней.

Сбор информации о сервере
В качестве основного средства по сбору информации о конфигурации сервера можно использовать Microsoft Product Support Reports (MPSReports). MPSReports собирает подробную информацию о конфигурации и настройках сервера, включая текущую аппаратную конфигурацию, установленные программы, драйверы, службы, версии библиотек и системных файлов, сетевые настройки, вывод утилит NetDiag, DCDiag, GPResult. Дополнительно в отчет могут быть включены результаты проверки настроек системы обновлений WSUS, служб SQL и Exchange. Вся собранная информация будет упакована в один .cab архив. Для его просмотра лучше всего использовать Microsoft Product Support Reports Viewer (MPS Reports Viewer).

В Windows Server 2008 R2 также есть встроенные инструменты по анализу установленных компонентов сервера на соответствие рекомендациям (Best Practice Analyzer). BPA устанавливается вместе с той или иной ролью и доступен из оснастки Server Manager.

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

#Get-BPAResults.ps1
#v.1.0
Import-Module ServerManager
Import-Module BestPractices

$ResultDir = "C:\Temp\"

foreach ($BPAModel in Get-BpaModel)
{
$BPAinstance = $BPaModel.Id
$FileName = $BPAinstance.Substring($BPAinstance.LastIndexOf("/")+1)
Invoke-BpaModel $BPAinstance
Get-BPAResult $BPAinstance | ConvertTo-Html > ($ResultDir + $FileName + ".html")
}

Результат анализа BPA по каждой роли будет сохранен в отдельном HTML файле в папке "C:\Temp".

Заключение
Как видите существует достаточно много простых и понятных утилит для сбора информации об инфраструктуре. Их использование позволит вам получить точную информацию о текущей конфигурации серверов "из первых рук", без необходимости отрыва администраторов от производства.

Оценка стоимости вариантов лицензирования виртуальной среды на базе Microsoft Hyper-V + SCVMM

2010-07-06T08:00:00.021+04:00

Использование виртуализации существенным образом меняет подход к лицензированию многих программных продуктов. Так, например, лицензии Microsoft Windows Server 2008 R2 Standard Edition и Enterprise Edition привязываются к физическому серверу, однако, последняя позволяет запускать до четырех экземпляров ОС Windows Server в виртуально среде на этом же сервер. Еще интересней дело обстоит с Windows Server 2008 R2 Datacenter Edition, которая привязывается к физическому процессору (сокету) и при условии лицензирования всех процессоров позволяет запустить неограниченное число виртуальных машин на одном физическом сервер.

Схожие правила распространяются на пакеты лицензий System Center Server Management Suite Enterprise (SMSE) и System Center Server Management Suite Datacenter (SMSD), включающих в себя право на использование ПО семейства System Center: System Center Configuration Manager 2007 R2, System Center Data Protection Manager 2010, System Center Operation Manager 2007 R2, System Center Virtual Machine Manager 2008 R2 и д.р. как на физических серверах, так и в виртуальной среде.

Важное дополнение: данные пакеты лицензий можно приобретать лишь для тех серверных ОС, для которых куплена подписка Software Assurance.

Дополнительными преимуществами Software Assurance является возможность перехода на новую версию продукта (в данном случае серверной ОС Windows Server) без необходимости покупки новых лицензий.

Вдобавок, Microsoft предоставляет решения по управлению серверами виртуализации для малого бизнеса: Microsoft System Center Virtual Machine Manager 2008 R2 Workgroup Edition и System Center Essentials 2010.

Чтобы оценить преимущества каждого из вариантов лицензирования продуктов, я сделал небольшую таблицу в Excel.

Для примера была взята абстрактная инфраструктура, которая включает в себя три двухпроцессорных сервера в одинаковой конфигурации. Количество виртуальных машин в инфраструктуре варьируется от 5 до 30. Предполагается, что машины размещаются на всех серверах равномерно.

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

Для сравнения использовались следующие выпуски ОС:

Microsoft Windows Server 2008 R2 Standard Edition.
Microsoft Windows Server 2008 R2 Enterprise Edition.
Microsoft Windows Server 2008 R2 Datacenter Edition.

В расчетах не оценивается функционал, который могут предоставлять старшие редакции ОС. Оценка выполнялись как для случая покупки обычных лицензий, так и совместно с Software Assurance.

Также сравнивалась стоимость SCVMM 2008 R2 в составе:

Microsoft System Center Virtual Machine Manager 2008 R2 Workgroup Edition.
Набора приложений System Center, приобретаемых отдельно (SCCM 2007 R2, SCDPM 2010, SCOM 2007 R2 и SCVMM 2008 R2).
Пакета лицензий SMSE.
Пакета лицензий SMSD.

Предполагается, что в случае покупки приложений System Center лицензируются все серверы, как физические, так и виртуальные, что отражается на количестве лицензий, необходимый для SCCM, SCDPM и SCOM. При этом на все серверы (физические и виртуальные) приобретаются лицензии SCDPM Enterprise ML, хотя в реальной среде это, как правило, не так.

В расчетах не учитывается стоимость дополнительных лицензий, таких как: лицензии SQL Server'а или лицензии клиентского доступа (CAL). Все цены для Windows Server и System Center были взяты с сайта Microsoft.

Вот какие результаты были получены.

Стоимость лицензий Windows Server 2008 Standard Edition растет линейно при росте количества, и в некоторых случаях может быть выгодно лицензировать виртуальные машины именно с помощью редакции Standard, нежели Enterprise. Однако, когда количество виртуальны машин вырастает до 25 и более, стоимость Datancenter становится самой низкой по сравнению с другими редакциями.

Еще более интересные результаты получаются при планировании Failover конфигурации. В этом случае, если ваша инфраструктура насчитывает 17 и более виртуальных машин, выгоднее, опять же, покупать Windows Server 2008 R2 Datacenter Edition.

Для вариантов лицензирования с учетом Software Assurance (как для Failover конфигурации, так и без нее) общий вид графиков не меняется.

Стоимость SCVMM 2008 R2 Workgroup Edition в расчете на 3 сервера виртуализации ожидаемо оказывается самой низкой в независимости от количества виртуальных машин. Что касается пакетов лицензий из отдельных продуктов, SMSE и SMSD, то последний выгоднее покупать при наличии 9 и более виртуальных машин (либо 5 и более при планировании отказоустойчивой конфигурации).

Для собственных расчетов вы можете загрузить таблицу отсюда или отсюда.
Примечание: поскольку расчеты производятся для одного кластера, то максимальное число физических серверов, указанных в таблице не должно превышать 16. Аналогично, при использовании кластера, максимальное число виртуальных машин на одном узле - 64. Все поля, доступные для редактирования выделены полужирным. Красным цветом выделены расчеты для отказоустойчивой конфигурации.

Конструктивная критика и предложения приветствуются.

Добавление виртуальных устройств в VMware Workstation 7

2010-06-29T08:00:00.012+04:00

Как должно быть многим из вас известно, в vSphere 4.0 для виртуальных машин с 7-ой аппаратной ревизией (Hardware version 7) поддерживаются новые виртуальные устройства - сетевой адаптер VMXNET3 и дисковый контроллер Paravirtual SCSI (PVSCSI), которые в ряде случаев обеспечивают большую производительность и меньшую нагрузку на процессор. Оказывается, что в VMware Workstation также есть возможность использовать эти устройства.

Сделать это можно, изменив .vmx файл с конфигурацией виртуальной машины для существующих устройств. Для этого найдите соответствующее устройство и измените параметр virtualDev на требуемый. Для scsi контроллера:
scsi[N].virtualDev = "pvscsi"

Для сетевого контроллера:
ethernet[N].virtualDev = "vmxnet3"
, где [N] - номер устройства.

После этого обновите конфигурацию виртуальной машины, удалив и вновь добавив ее в VMware Workstation.

Примечание: Перед добавлением новых устройств убедитесь, что вы используете 7-ую аппаратную ревизию виртуальной машины, что соответствует режиму совместимости Workstation 6.5-7.0.

Не рекомендуется изменять тип контроллера с которого выполняется загрузка, например с LSI Logic на PVSCSI. Дело в том, что в VMware Tools отсутствует необходимый драйвер, что может приводить к BSOD при загрузке ОС. Драйвер для pvscsi можно установить с виртуальной дискеты (pvscsi-Windows2003.flp, pvscsi-Windows2008.flp или vscsi-WindowsXP.flp), которая, по умолчанию, находится в папке:
%ProgramFiles(x86)%\VMware\VMware Workstation\Resources\