Немного истории: продукты VMware, которых больше нет с нами

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

VMware ESX Server

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

VMware ESX Server - первый гипервизор типа 1 для процессоров Intel x86. ESX не был первым серверным гипервизором, и даже не был первым продуктом VMware. Однако в нем впервые были реализованы такие функции, как живая миграция ВМ (vMotion), высокая доступность ВМ (High Availability), автоматическая балансировка (Distributed Resource Scheduler), управление питанием (Distributed Power Management) и многое другое.

Кстати, вы никогда не задавались вопросом, что значить аббревиатура ESX? Так вот, ESX - это Elastic Sky X. Что лишний раз доказывает, что еще в далеком 2002 VMware разрабатывала свои продукты с оглядкой на облачные вычисления...

ESX строился на базе монолитной архитектуры, все драйверы, сеть и подсистема ввода-вывода работали на уровне гипервизора. Однако для управления гиперзовиром на каждом хосте устанавливалась небольшая служебная ВМ - Service Console на базе модифицированного дистрибутива Red Hat Linux. С одной стороны, это накладывало ряд ограничений - служебная ВМ отъедала часть вычислительных ресурсов хоста, ее диски, как и любой другой ВМ требовалось размещать на VMFS хранилище, а каждый хост нуждался, по меньшей мере, в двух IP адресах, один - для VMKernel интерфейса, второй - для Service Console. С другой стороны, Service Console предоставляла возможность установки стороннего ПО (агентов, плагинов), которые расширяли возможности по мониторингу и управлению гипервизором. Наличие Service Console породило распространенное заблуждение, что гипервизор ESX является модифицированным Linux'ом.

Стоит упомянуть, что первые версии ESX устанавливались и управлялись по отдельности, однако, начиная ESX 2.0, для централизованного управления несколькими хостами появился VMware VirtualCenter (ныне хорошо известный под именем vCenter Server). Тогда, собственно, и появился Virtual Infrastructure, который представлял собой набор продуктов для виртуализации, состоящий из гипервизора ESX и ПО управления VirtualCenter. К версии 4.0 Virtual Infrastructure был переименован в vSphere.

В 2008 году появился альтернативный гипервизор - ESXi, который не нуждался в Service Console, был гораздо меньше в размере, но не поддерживал многое из того, что умел ESX (у ESXi отсутствовал WEB интерфейс, встроенный брандмауэр, возможность загрузки по SAN, интеграция с Active Directory и пр.). С каждой новой версией VMware постепенно наращивала функционал ESXi. VMware vSphere 4.1 стал последним релизом, включающим гипервизор ESX. Начиная с 5.0 VMware оставила только ESXi.

VMware GSX Server / Server

Долгие годы VMware GSX Server выпускался параллельно с VMware ESX. Ground Storm X (так расшифровывается аббревиатура GSX) представлял собой гипервизор второго типа и устанавливался поверх серверных ОС Microsoft Windows, RedHat или SUSE Linux. Использование гипервизора тип 2 имело свои плюсы. Во-первых, GSX поддерживал гораздо более широкий перечень оборудования и мог работать даже на десктопном железе в отличие от "капризного" ESX. Во-вторых, VMware GSX был крайне прост в установке и настройке, любой, кто работал с VMware Workstation, был способен управиться и с GSX. В-третьих, GSX имел встроенный NAT и DHCP сервер, что позволяло легко настраивать сеть для ВМ.

Как и старший собрат GSX поддерживал централизованное управление через VirtualCenter.

Позже GSX был переименован в VMware Server, получил при этом возможность запускать 64-битные ВМ, а также выделять ВМ несколько виртуальных процессоров. Вышедший в конце 2008 года VMware Server 2.0 стал бесплатным, обзавелся полноценным веб-интерфейсом и возможностью проброса USB устройств внутрь ВМ, однако потерял поддержку VMware VirtualCenter.

К этому времени гипервизоры ESX и ESXi заняли большую часть рынка серверной виртуализации. Выход бесплатных версий VMware ESXi Free и Microsoft Hyper-V Server стали последним гвоздем в крышку гроба VMware Server. VMware и Microsoft забросили свои гипервизоры для серверных ОС.

VMware vCenter Server Heartbeat

Продукт, предназначенный для обеспечения высокой доступности служб vCenter и смежных сервисов (СУБД, SSO, Update Manager), разрабатывался не самой VMware, а сторонней компанией - Neverfail Group.

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

Хотя какое-то время vCenter Heartbeat и был единственным способом обеспечить защиту vCenter не только от аппаратных, но и от программных сбоев, реализация откровенно хромала. Сложная процедура установки и обслуживания кластера, а также масса багов сделали свое черное дело. В итоге, начиная с vSphere 5.5 U3 / vSphere 6.0 компания VMware отказалась от vCenter Heartbeat и вернулась к более привычному способу кластеризации средствами Microsoft Failover Cluster.

VMware vCenter Protect

Для тех из вас, кто работал с vSphere хотя бы с 4-й версии, должно быть известно, что в то время vCenter Update Manager поддерживал установку обновлений не только для гипервизоров ESX/ESXi, но также гостевых операционных систем и различного ПО. Однако начиная с 5.0 данный функционал был исключен из Update Manager, вместо этого VMware стала предлагать отдельный продукт - VMware vCenter Protect, который был приобретен вместе с компанией Shavlik.

Помимо обновления гостевых ОС, vCenter Protect позволял выполнять инвентаризацию программного и аппаратного обеспечения, запускать различные сценарии по расписанию, выполнять проверку на наличие уязвимостей.

Но, по всей вимости, продажи шли не очень хорошо, кроме того в портфеле VMware был vRealize Configuration Manager, приобретенный в 2010 у EMC, и выполнявший функции патч-менеджмента, инвентаризации и многого другого. Поэтому в 2013 vCenter Protect был продан компании LANDesk.

VMware Virtual Storage Appliance

Virtual Storage Appliance - первая попытка VMware играть на рынке программно-определяемых СХД. VSA предназначался для SMB и позволял создавать общую отказоустойчивую СХД на базе локальных дисков, устанавленных в сервер.

На каждом хосте ESXi развертывался специальный апплайнс VSA. Виртуальные диски VSA размещались на VMFS хранилище, созданном на томах локального RAID контроллера. Половина дискового пространства предназначалась для зеркалирования данных с другого VSA (этакий сетевой аналог RAID 1), расположенного на соседнем хосте, половина оставалась под полезные данные. Затем каждый апплайнс презентовал свое зеркалируемое хранилище по протоколу NFS обратно всем хостам виртуализации. Одна инсталляция поддерживала 2 или 3 хоста виртуализации, при использовании 2 хостов vCenter Server выполнял роль арбитра и должен был разворачиваться на отдельном физическом сервере или хосте ESXi, не входящем в VSA.

Функционал VSA был весьма ограниченным. Так, например, первая версия VSA поддерживала размещение только на VMFS томах с RAID 1 или 10, что приводило к высоким накладным расходам на хранение данных (фактически, полезное пространство составляло менее 1/4 от объема локальных дисков), отсутствовала поддержка VAAI, не было поддержки кэширования или тиринга.

Все это в совокупности с не слишком низкой ценой и невысокой производительностью не позволили VSA вытеснить привычные СХД из SMB сегмента. Поэтому вскоре после выхода первой версии Virtual SAN в 2014, продукт был снят с продаж.

VMware Virsto

Еще одна жертва Virtual SAN, продукт одноименной компании, которую VMware приобрела в 2013 году. Насколько мне известно, после покупки Virsto так и не появился в прайс-листах, а был практически сразу же помножен на ноль.

Перпективная разработка в области программно-определяемых хранилищ данных, Virsto представлял собой виртуальный апплайнс, выполняющий роль виртуализатора СХД, т.е. ресурсы СХД презентовались аплайнсу, а аплайнс, в свою очередь, отдавал дисковое пространство хостам по протоколу NFS. Сердцем Virsto была VirstoFS - специализированная файловая система, позволяющая оптимизировать операции записи и чтения за счет использования механизмов, схожих с теми, что можно видеть в СХД NetApp FAS. Virsto мог аккумулировать случайные операции записи в специальном журнале и затем последовательно записывать данные на СХД, что положительно сказывалось на IOPS и задержках. Кроме того, Virsto поддерживал многоуровневое хранение данных (тиринг) и оптимизировал работу со снапшотами за счет хранения в оперативной памяти метаданных о том, какой блок с данными в каком из снимков находится.

Несмотря на то, что продукт так и не вышел, старания разработчиков не прошли даром - в Virtual SAN 6.0 вместо VMFS-L появился новый формат разметки дисков на базе VirstoFS и поддержка "продвинутых" снапшотов.

VMware Lab Manager

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

По сути Lab Manager являлся менеджером менеджеров, разворачивался поверх существующей инсталляции VMware ESX/ESXi и vCenter и позволял организовывать многопользовательский (многоарендный) доступ к общей виртуальной инфраструктуре, выделять пользователям необходимый набор вычислительных ресурсов, автоматически выдавать IP адреса ВМ из пулов, создавать изолированные сети для ВМ, указывать срок аренды для ВМ.

С ростом популярности темы облачных вычислений VMware переключилась на другой продукт - vCloud Director, постепенно перенеся из Lab Manager все наработанные фишки и закрыв его.

VMware ACE

Закончить обзор я хочу на достаточно редком звере - VMware ACE. Еще до появления VDI в своем классическом виде и широкого распространения BYOD компания VMware предлагала клиентам ПО для централизованного управления виртуальными рабочими станциями, которые могли запускаться на персональных компьютерах пользователей - VMware ACE.

ACE работал в связке с клиентскими гипервизорами VMware Workstation и Player и позволял управлять ВМ на основании заданных политик. С помощью политик администраторы могли ограничить функционал ВМ (например, отключить проброс USB устройств или контролировать доступ в сеть), принудительно шифровать виртуальные диски, разрешать доступ к ВМ только для авторизованных пользователей, настраивать срок жизни ВМ, по истечении которого ВМ переставала запускаться и т.д. ВМ вместе с политиками и гипервизором VMware Player могли быть экспортированы в виде готово пакета Pocket ACE и переданы пользователю любым удобным способом (на CD-диске, flash-накопителе или по сети). При необходимости, администратор мог развернуть в сети сервер ACE Management Server, к которому подключались клиентские гипервизоры и запрашивали актуальные настройки политик для ВМ.

Не смотря на интересный функционал, продукт не получил широкого распространения, и по словам VMware не отвечал всем требованиям тех немногих заказчиков, что его использовали, поэтому в 2011 он был снят с продажи. Спустя несколько лет на смену ACE пришел VMware Horizon FLEX, имеющий собственный механизм доставки ВМ на компьютеры пользователей, а также поддерживающий гипервизор VMware Fusion Pro для ОС Apple MAC OS X.

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

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

Все.

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

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

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. Просто так.

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

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

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

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

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

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

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

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

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

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

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

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

Баг Veeam SureBackup - 'DestinationHostUnreachable'

Постигая азы использования 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

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

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

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

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

Внимание: перед тем, как выполнять рекомендации, приведенные в статье, прочтите данное сообщение. Проброс ленточной библиотеки внутрь виртуальных машин НЕ поддерживается VMware и НЕ является приемлемым решением для организации резервного копирования виртуальной среды. Я настоятельно рекомендую рассмотреть альтернативные варианты решения задачи, например, установить FC HBA адаптер в любой доступный физический сервер и подключить к нему ленточную библиотеку. Это избавит вас от множества проблем, связанных с настройкой проброса библиотеки внутрь ВМ и дальнейшей эксплуатацией данного решения. В особенности, когда вам потребуется что-то восстановить из резервной копии.

Обновление: начиная с vSphere 5.0, VMware перестала поддерживать подключение ленточных приводов (библиотек) к хостам ESXi в том числе по SAS/SCSI интерфейсу (https://www.vmware.com/support/vsphere5/doc/vsphere-esx-vcenter-server-50-release-notes.html): 
Tape drives. VMware does not support tape drives that are connected to ESX/ESXi hosts. For additional information, see Knowledge Base article 1016407.

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

Установка и настройка Citrix XenDesktop 4.0 FP1

Признаться, я всегда обходил стороной продукты компании Citrix, считая их сложными в установке и настройке (чего только стоит процедура получения trial лицензий для XenApp), и поэтому постоянно откладывал знакомство с ними на будущее. Конечно, в ознакомительных целях я пару раз устанавливал XenServer, создавал виртуальные машины, настраивал кластер, но, в общем-то, на этом мои познания в Citrix'е заканчивались.

Но недавно я натолкнулся на статью о развертывании Citrix XenDesktop на одном из зарубежных сайтов vmguru.nl.

Не знаю, что сподвигло меня самостоятельно попробовать установить XenDesktop, но (hint!), свое знакомство с продуктом я начал с прочтения руководства по развертыванию и просмотра видео по установке XenDesktop4 Express Tutorial.wmv, идущее в комплекте с дистрибутивом XenDesktop 4 Feature Pack 1 - Express Edition (загружается с сайта Citrix после прохождения регистрации).

Статья, представленная ниже, по большей части повторяет оригинальное руководство по установке за исключением одного - на момент развертывания у меня не было свободной машины, на которой можно было поставить XenServer, поэтому в качестве среды виртуализации была выбрана VMware vSphere 4 (ESX 4 и vCenter 4.0).

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

• Служба каталога Active Directory - предоставляет централизованное управление учетными записями пользователей и компьютеров, информация о ферме XenDesktop хранится внутри службы каталога.
• Сервер(ы) виртуализации - Citrix XenDesktop позволяет развертывать виртуальные рабочие станции на Citrix XenServer, VMware vSphere (при наличии vCenter) и Microsoft Hyper-V (при наличии MS SCVMM 2008).
• Desktop Delivery Controller - служба, устанавливающаяся на сервер или группу (ферму) серверов, которая выполняет роль менеджера соединений, производит аутентификацию пользователей при подключении, контролирует виртуальные рабочие станции, а также непосредственно взаимодействует с другими компонентами инфраструктуры.
• License Server - сервер лицензирования, отвечающий за выдачу пользователям лицензий на подключение и использование дополнительных функций Citrix XenDesktop.
• Virtual Desktop Agent - агент, который устанавливается внутри виртуальной рабочей станции и позволяет Desktop Delivery Controller управлять этой машиной, а также подключаться к ней удаленно по протоколу ICA, использовать локальные принтеры и usb-устройства.
• Citrix Online Plugin Full/Citrix Receiver и Citrix Online Plugin Web - клиентский компонент, устанавливающийся на компьютер с которого пользователь подключается к виртуальной рабочей станции.

Я намеренно не буду рассматривать некоторые компоненты Citrix XenDesktop, например, Citrix Presentation Server Console - для управления политиками доступа к виртуальным машинам или Web Interface Manager - для обеспечения возможности подключения к виртуальным машинам через Web сайт. Кроме того, XenDesktop самостоятельно не предоставляет средств по автоматизированному созданию виртуальных рабочих станций, эту роль он на пару делит с другим продуктом Citrix - Provisioning Services - вещи достаточно большой и сложной, которой следовало бы посвятить отдельную статью, а то и две.

Установка сервера Citrix
Перед тем, как приступать к установке вам потребуется подготовить вашу инфраструктуру - развернуть сервер виртуализации, контроллер домена и, как минимум, еще один сервер для Desktop Delivery Controller. В качестве ОС поддерживаются Windows Server 2003 (R2) (x86/x64) с Service Pack 2.

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

Скопируйте установочные файлы с CD диска, файла-образа DDC_VDA.iso (находится в архиве XenDesktop_ExpressFP1.zip) или сетевой папки на локальный диск сервера.

Установку лучше всего запускать из-под доменной учетной записи, чтобы в дальнейшем вам не пришлось вручную назначать дополнительных администраторо системы и не было проблем с Active Directory Configuration Wizard.

Запустите установщик. Выберите Install Server Components.

Примите лицензионное соглашение (I accept the license agreement) и нажмите Next.

На странице Select Components оставьте все выбранные компоненты по-умолчанию. При установке первого сервера Citrix Desktop Delivery Controller вам потребуется сервер лицензирования, который может быть размещен на этом же или отдельном сервере. Несколько серверов Citrix Desktop Delivery Controller могут обращаться к одному и тому же серверу лицензирования. Нажмите Next.

На странице Create or Join a Farm укажите имя фермы (Type a name for the farm). При установке дополнительных серверов Citrix Desktop Delivery Controller вы можете объединять несколько серверов в один балансируемый/отказоустойчивый пул, указывая одинаковое имя фермы. Нажмите Next.

На странице Specify Farm Edition укажите подходящую редакцию Citrix XenDesktop. В тестовых целях вы можете установить Citrix XenDesktop Express Edition, которая отличается от Citrix XenDesktop VDI Edition количеством поддерживаемых пользователей (до 10). Различия между редакциями можно посмотреть здесь. Нажмите Next.

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

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

Если компонент IIS не был установлен, то система попросит вас вставить диск с дистрибутивом Windows Server для копирования необходимых файлов.

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

На странице завершения установки (Setup Complete) оставьте Configure an Active Directory OU выбранным и нажмите Finish.

Запустится мастер Active Directory Configuration Wizard. На первой странице нажмите Next.

На странице Configure Farm OU in Active Directory с помощью кнопки Browse укажите путь к OU, где будет размещаться информация о ферме и нажмите Next.

На странице Select Controllers с помощью кнопок Add Local Machine или Add добавьте установленный сервер Citrix Desktop Delivery Controller.

На странице Completing the Active Directory Configuration Wizard нажмите Finish. Система выполнит необходимые настройки. Закройте окно результатов (Close).

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

Для добавления лицензий запустите консоль управления лицензиями Start -> All Programs -> Citrix -> Management Consoles -> License Management Console.

На странице License Management Console выберите Configure License Server.

Выберите Step 2: Copy License file to this license server.

С помощью кнопки Browse укажите путь к файлу лицензий, а затем нажмите Upload.

Подготовка виртуальной рабочей станции
Теперь настала очередь настроить виртуальную рабочую станцию. Citrix XenDekstop 4.0 FP 1 поддерживает следующие 32-х и 64-х разрядные ОС: Windows XP Professional SP3 (Windows XP Professional x64 SP2), Windows Vista SP2, Windows 7.

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

После завершения всех необходимых предварительных шагов запустите установщик с диска DDC_VDA.iso и выберите Install Virtual Desktop Components.

На странице Welcome to the Citrix Desktop Agent Setup Wizard нажмите Next.

На странице End-User License Agreement примите лицензионное соглашение (I accept the terms in the License Agreement). Нажмите Next.

На странице Port Number оставьте порт по-умолчанию (TCP: 8080) и нажмите Next.

На странице Windows Firewall Configuration оставьте Automatically configure Windows Firewall и нажмите Next.

На странице Farm Selection выберите имя фермы, которое было сконфигурировано при установке сервера, и нажмите Next.

На странице Ready to Install нажмите Intall для установки агента.

После завершения установки нажмите Finish. Система предложит перезагрузиться. Нажмите Yes.

Разрешение подключений к VMware vCenter
Если в качестве сервера виртуализации вы используете VMware vSphere, то перед следующим шагом вам потребуется выполнить следующие действия.

Citrix Desktop Delivery Controller для управления vCenter использует протокол HTTP или HTTPS, подключаясь к Web-директории /sdk. По умолчанию, доступ к этой директории разрешен лишь по протоколу HTTPS. Проблема заключается в том, что Citrix Desktop Delivery Controller не поддерживает самоподписанных сертификатов vCenter и не может подключиться к серверу.

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

Если вы планируете подключаться по протоколу HTTPS, выдайте серверу vCenter сертификат от доверенного Центра Сертификации. Подробное об этом в статье.

Если вы планируете подключаться по протоколу HTTP, настройте сервер vCenter. Для этого зайдите на сервер, откройте в текстовом редакторе файл proxy.xml из директории "C:\Documents and Settings\all users\Application Data\vmware\VMware VirtualCenter". Найдите там строчки:
<e id="5">
<_type>vim.ProxyService.LocalServiceSpec</_type>
<accessMode>httpsWithRedirect</accessMode>
<port>8085</port>
<serverNamespace>/sdk</serverNamespace>
</e>
и замените httpsWithRedirect на httpAndHttps как показано на рисунке. После этого перезапустите службу VMware VirtualCenter Server.

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

На сервере Citrix запустите консоль управления виртуальными рабочими станциями Start -> All Programs -> Citrix -> Management Consoles -> Delivery Services Console.

В мастере Configure and run discovery на вкладке Welcome нажмите Next.

На вкладке Select Products or Components нажмите Next.

На вкладке Select Controllers с помощью кнопок Add Local Computer или Add добавьте установленный сервер и нажмите Next.

На вкладке Preview Discovery нажмите Next.

После завершения операции нажмите Finish.

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

Для этого раскройте Citrix Delivery Services Console -> Citrix Resources -> Desktop Delivery Controller -> <ИМЯ_ФЕРМЫ> щелкните правой кнопкой мыши по Desktop Groups и выберите Create desktop group.

Запустится мастер создания группы.

На вкладке Welcome нажмите Next.

На вкладке Assignment Type выберите один из типов назначения рабочих столов пользователям.

• Pooled - При подключении к данной группе, пользователь будет перенаправлен на первую свободную машину в пуле. После отключения, машина будет ожидать подключения к ней этого или любого другого пользователей.
• Assigned:
  
  
  
  • Assign on first use - при первом подключении к любой машине из данной группы, машина закрепляется за данным пользователем и используется при всех последующих подключениях.
  • Pre-assigned - администратор вручную указывает закрепленные за конкретными пользователями машины.

Нажмите Next.

На вкладке Hosting Infrastructure выберите виртуальную инфраструктуру на которой работают виртуальные рабочие станции. Например, VMware vSphere (VMware virtualization). Нажмите Next.

На вкладке Logon Information укажите адрес сервера и учетные данные для подключения. Для VMware vCenter требуется указать адрес в формате http://<ИМЯ_СЕРВЕРА>/sdk или https://<ИМЯ_СЕРВЕРА>/sdk. Нажмите Next.

На вкладке Virtual Desktops с помощью кнопки Add добавьте виртуальные рабочие станции в группу. Обратите внимание, если имя рабочей станции в домене и в виртуальной машины различаются, то система не сможет сопоставить эти имена и это придется сделать вручную с помощью кнопки Edit. Чтобы упростить процесс вы можете заранее создать файл в формате .csv и добавить данные из него с помощью кнопки Import from File.
Нажмите Next.

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

На вкладке Desktop Group Name задайте имя (Display name) и описание (Description), которые будут видеть пользователи при подключении к серверу Citrix. Нажмите Next.

На вкладке Icon можете поменять стандартный ярлык. Нажмите Next.

на странице Publishing Options оставьте все параметры по-умолчанию. Нажмите Finish.

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

Машины готовые к подключению будут иметь статус Idle.

Подключение к виртуальным рабочим станциям
Последний шаг - установка Citrix Online Plugin на клиентской рабочей станции для подключения к серверу Desktop Delivery Conroller и виртуальным рабочим станциям.

На выбор предоставляются два клиента CitrixOnlinePluginFull - для установки полной версии клиента и CitrixOnlinePluginWeb - для установки клиента с подключением через Web, расположенных в папке дистрибутива DDC_VDA.iso:
X:\w2k3\en\Citrix Receiver and Plug-ins\Windows\Online Plug-in
, где X - буква диска.

Дождитесь завершения процесса установки.

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

Введите логин и пароль для входа на сервер.

Щелкните по ярлыку Citrix Receiver левой кнопкой мыши и выберите виртуальную группу к которой хотите подключиться.

Кроме того, вы пожете подключиться к виртуальным рабочим станциям через Web сайт, набрав в строке Web браузера на клиенте адрес в фомате: HTTP://<ИМЯ_СЕРВЕРА>/Citrix/DesktopWeb/

Остальное - на ваше усмотрение.

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