На прошлой неделе компания VMware объявила о запуске нужного сервиса по восстановлению инфраструктуры Disaster Recovery для облачной инфраструктуры vCloud Hybrid Service (vCHS). Напомним, что совсем недавно сервисы vCHS подешевели и стали доступны в Европе.

Анонсированное DR-решение доступно как услуга (RaaS, Recovery-as-a-Servie) для конечных заказчиков, которые могут делать бэкап своего частного облака в инфраструктуру vCHS. При этом для заказа услуги (она доступна на 1,12,24 или 36 месяцев) не требуется быть клиентом vCHS и иметь там свою виртуальную инфраструктуру.

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

Новые возможности Disaster Recovery в облаке vCloud Hybrid Service:

• Self-Service disaster recovery Protection - возможность защитить до 500 виртуальных машин с помощью технологии vSphere Replication самостоятельно, прямо из консоли vCenter Server.
• Custom Recovery Point Objectives - возможность настройки политик репликации, которые дают RPO от 15 минут до 24-х часов, в зависимости от характеристик канала связи, объема реплицируемых данных и прочих факторов.
• Industry-Standard Recovery Time Objectives - время восстановления сервиса после сбоя (RTO) гарантировано на уровне 4-х часов (или менее), что подразумевает полное включение резервных копий всех машин на стороне vCHS.
• Automated Failover Testing, Planned Migrations and Recovery - встроенные возможности (преднастроенные workflows), позволяющие проводить тестирование аварийного восстановления, live-восстановление продуктивной ВМ в среду vCHS, а также проводить запланированные миграции в облако VMware.
• Elastic Cloud Compute and Storage - возможность гибкого изменения требуемых под DR-инфраструктуру ресурсов, что позволяет, например, быстро построить среду под аварийное восстановление инфраструктуры на стороне vCHS в самое ближайшее время.
• Offline Data Seeding - возможность первичной передачи большого объема данных через офлайн-механизм vCloud Connector Offline Data Transfer.
• Private Leased Line Networks - использование выделенных провайдерских сетей (Direct Connect) для возможности аварийного восстановления.
• Flexible Failover Testing - возможность использования различных преконфигуренных сценариев аварийного восстановления.

Для использования сервисов DR в vCHS вам потребуется:

• VMware vSphere 5.1 или выше
• VMware vCenter 5.1 или выше
• Механизм VMware vSphere Replication 5.6
• Подписка VMware vCloud Hybrid Service – Disaster Recovery
• Развернутый виртуальный датацентр (DR-VDC) в инфраструктуре vCloud Hybrid Service
• Достаточное по скорости соединение через интернет с облаком vCHS

Сначала DR vCHS можно купить как Core Service базовой мощности:

А потом уже можно расширять его аддонами (минимальная гранулярность подписки - месяц, что удобно):

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

Компания Microsoft на днях выпустила превью-версию клиента Remote Desktop для Windows Phone, который доступен для скачивания в Windows Phone Store. Клиент предназначен для ОС Windows Phone 8.1. Превью-версия бесплатна и занимает всего 1 МБ.

Основные возможности Microsoft Remote Desktop Preview for Windows Phone:

• Поддержка высокопроизводительных протоколов RDP и RemoteFX.
• Поддержка мультитач и жестов Windows gestures.
• Безопасное соединение с использованием технологии Network Level Authentication (NLA).
• Централизованное управление всеми удаленными соединениями через Connection center.
• Передача высококачественного видео и аудиопотока с улучшенными техниками компрессии и эффективного использования канала. Поддерживаются режимы HD720P (720x1280), WVGA (480x800) и WXGA (768x1280).

Напомним также, что в марте этого года Microsoft обновила свои клиенты и для конкурирующих платформ:

• 15 марта обновился Microsoft Remote Desktop for iOS до версии 8.0.5
• 16 марта обновился Microsoft Remote Desktop for Android также до версии 8.0.5

Пару недель назад мы писали об уязвимости OpenSSL HeartBleed, которая коснулась виртуальной инфраструктуры VMware vSphere, а также других продуктов компании VMware. Напомним, что эта уязвимость позволяла злоумышленнику получить доступ к памяти сервера, где могут храниться логины/пароли и другая информация пользователей.

На прошлой неделе компания VMware выпустила фиксы для этого бага в виде обновлений VMware vSphere 5.5 Update 1a и VMware vSphere 5.5c, подробнее о которых написано в специальной статье KB 2076665.

Но тут, как часто бывает, вышла оказия. Нашелся еще один баг в VMware vSphere 5.5 Update 1 - оказывается, если для этого билда использовать NFS-хранилища, то они периодически отваливаются, то есть переходят в состояние APD (All paths down). Это касается и VSA-хранилищ. В логах при этом наблюдается что-то вроде такого:

2014-04-01T14:35:08.074Z: [APDCorrelator] 9413898746us: [vob.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:35:08.075Z: [APDCorrelator] 9414268686us: [esx.problem.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:36:55.274Z: No correlator for vob.vmfs.nfs.server.disconnect
2014-04-01T14:36:55.274Z: [vmfsCorrelator] 9521467867us: [esx.problem.vmfs.nfs.server.disconnect] 192.168.1.1/NFS-DS1 12345678-abcdefg0-0000-000000000000 NFS-DS1
2014-04-01T14:37:28.081Z: [APDCorrelator] 9553899639us: [vob.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.
2014-04-01T14:37:28.081Z: [APDCorrelator] 9554275221us: [esx.problem.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.

Решения для этой проблемы пока нет, поэтому рекомендуется просто откатиться на VMware vSphere 5.5 (без Update 1), если вы используете NFS-хранилища или модуль VSA.

Так вот, поэтому vSphere 5.5 Update 1 и просто vSphere 5.5 надо обновлять разными патчами для устранения уязвимости OpenSSL HeartBleed (чтобы на 5.5 не накатилась проблема с APD):

VMware ESXi 5.5, Patch Release ESXi550-201404001
Это патч только для фикса хостов ESXi 5.5 Update 1

VMware ESXi 5.5, Patch Release ESXi550-201404020
А этот патч для фикса хостов разных версий 5.5 за исключением ESXi 5.5 Update 1, а именно:
ESXi 5.5.0 hosts
ESXi 5.5.0 hosts patched with ESXi550-201312101-SG bulletin
ESXi 5.5.0 hosts patched with ESXi550-201312401-BG bulletin
ESXi 5.5.0 hosts patched with ESXi550-201403101-SG bulletin
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131201001s-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131201001s-no-tools image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131204001-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131204001-no-tools image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20140301001s-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20140301001s-no-tools image profile

Для серверов vCenter есть также соответствующие патчи:

• VMware vCenter Server 5.5 U1a
• VCVA 5.5 U1a
• VMware vCenter Server 5.5c
• VCVA 5.5c

VMware рекомендует сначала обновить серверы vCenter, а потом уже обновлять хосты ESXi. Сама процедура обновления описана в KB 2076692.

После обновления, на хостах ESXi надо перегенерить сертификаты и сменить пароли root. Делается это так:

cd /etc/vmware/ssl
/sbin/generate-certificates
chmod +t rui.crt
chmod +t rui.key
passwd root

Ну и надо отметить, что для всех остальных продуктов VMware также вышли фиксы уязвимости OpenSSL HeartBleed. Информация о них доступна по этой ссылке: http://www.vmware.com/security/advisories/VMSA-2014-0004.html.

Еще в начале апреля компания Microsoft выпустила превью решения Azure Automation, которое предоставляет движок оркестрации для платформы Windows Azure. Говоря русским языком, это решение для автоматизации создания, мониторинга и развертывания облачных ресурсов на платформе Microsoft Azure c возможностью задания рабочего процесса, как это следует делать, с помощью сценариев.

Если у вас есть премиум-подписка на Azure вы можете активировать фичу в разделе Preview Features:

Работает этот движок аналогично механизму Service Management Automation (SMA), предоставляемому пакетом Windows Azure Pack.

Возможности функций Azure Automation:

• Импорт или создание собственных модулей PowerShell (а также на C#) для возможности интеграции Azure и сторонних систем.
• Использование гибких модулей Windows PowerShell Runbooks для ускорения процесса автоматизации.
• Создание и распределение ресурсов с помощью ручных или автоматизированных задач.

В сферу действия Automation включены следующие объекты:

• Веб-сайты (управление)
• Облачные службы (управление)
• Виртуальные машины (управление поддержка WinRM)
• Хранилище (управление)
• SQL Server (управление и поддержка SQL)

Во время Preview за Azure Automation плата не взымается, дата выхода финальной версии решения пока неизвестна. Потом цены будут примерно такими:

Основной ресурс Microsoft, посвященный механизму Azure Automation находится по этой ссылке.

Пошаговое описание использования функций Automation приведено в хорошей статье "Step-by-Step: Getting Started with NEW Microsoft Azure Automation preview feature".

В прошлых статьях мы писали про новые возможности VMware Horizon 6 - комплекта продуктов для управления физическими и виртуальными ПК предприятия, а также про лицензирование и издания этого решения. Как многие заметили, в состав изданий VMware Horizon 6 Advanced и Enterprise входит обновленная версия продукта для управления образами виртуальных ПК VMware Mirage 5.0 (о самом продукт мы уже писали вот тут).

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

В новой версии Mirage 5.0 большой акцент бы сделан на поддержку последней версии Microsoft Windows 8.1 - которая в скором времени будет одной из основных клиентских ОС предприятий. Если раньше для Windows 8.1 поддерживалось только резервное копирование, то теперь заявлена полноценная поддержка этой ОС.

Итак, что нового в VMware Mirage 5.0:

• Windows 8.1 Migration Support – Теперь устройства с Windows 7 на борту можно перенести на платформу Windows 8.1. Перед каждой миграцией снимается снапшот системы, поэтому если что-то пойдет не так, всегда можно откатиться к исходному состоянию. Даунтайм при миграции обычно составляет 30-60 минут. С помощью Mirage миграции можно проводить масштабно - сотнями компьютеров в день.

• Windows 8.1 Image Management Support – теперь можно разбивать ОС на уровень системы и приложений и управлять этими слоями при развертывании и обслуживании клиентских устройств, а также накатывании обновлений. При обновлении слоя приложений можно указывать, какие приложения стоит сохранить у пользователя, а какие - удалить.

• Windows 8 and 8.1 Disaster Recovery – техники автоматического бэкапа и полного восстановления системы после сбоя Windows 8.1 были добавлены еще в Mirage 4.4, но теперь также появились опции по быстрому восстановлению, а также самостоятельному восстановлению пользователем. Кроме того, доступна возможность рестора образа на другое устройство целиком, либо только данных пользователя.

• Mirage Gateway Enhancements – компонент Mirage Gateway также появился еще в Mirage 4.4. Этот компонент позволяет не применять внешний VPN при соединении с инфраструктурой Mirage предприятия из сети интернет. В Mirage 5.0 была улучшена производительность этого решения и его масштабируемость, кроме того теперь этот компонент требует меньше ресурсов.

В отличие от доступности пакета VMware Horizon 6, которая ожидается во второй половине 2014 года, решение VMware Mirage 5.0 может оказаться доступным значительно раньше - уже в ближайшее время. Больше информации можно найти в комьюнити, посвященном Mirage.

Компания Softline, наш хороший партнер и спонсор, проводит 22 апреля в 11:00 по московскому времени интересный вебинар "Программа аренды VSPP – преимущества участия", посвященный партнерской программе по предоставлению конечным заказчикам виртуальных машин в аренду.

Участие в мероприятии бесплатное!

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

Программа

• Краткая информация о компании Softline и ее достижениях в облачных технологиях
• Арендные программы – почему их выбирают
• Что такое VMware Service Provider Program (VSPP)
• Кому нужна данная программа? – Как работает VSPP
• Детали. Особенности. Требования.
• История успеха

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

Принцип программы VSPP состоит в том, что партнеры Softline получают право оказывать услуги на базе ПО VMware своим заказчикам без капитальных вложений и первоначальных взносов.

ЗАРЕГИСТРИРОВАТЬСЯ

Еще на прошлой неделе компания VMware выпустила познавательный документ "What’s New in VMware vSphere 5.5 Networking", в котором детально описываются нововведения, которые были сделаны в плане сетевого взаимодействия в VMware vSphere 5.5.

Напомним, что новая версия платформы принесла 5 основных нововведений в категории Networking:

• Улучшения Link Aggregation Control Protocol (LACP) - поддержка большего числа алгоритмов балансировки.
• Traffic Filtering - функции фильтрации трафика.
• Quality of Service Tagging - поддержка тэгирования различных типов трафика в соответствии с уровнем обслуживания, заданным для него на уровне VDS.
• Улучшения SR-IOV - напомним, что поддержка этих функций появилась еще в vSphere 5.1, теперь же процесс настройки этих функций существенно упрощен.
• Host-Level Packet Capture - появилась встроенная утилита для захвата пакетов на уровне хоста.

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

• VMware vSphere Distributed Switch Enhancements
  • Link Aggregation Control Protocol
  • Traffic Filtering
  • Quality of Service Tagging
• Troubleshooting and Performance Enhancements
  • Enhanced Host-Level Packet-Capture Tool
  • 40GB Network Adapter Support
  • Single-Root I/O Virtualization Enhancements

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

Еще в октябре 2012 года компания Microsoft выпустила первую версию своей утилиты Virtual Machine Converter для преобразования виртуальных машин VMware в формат виртуальных дисков VHD на платформе Hyper-V. С тех пор прошло много времени, формат виртуальных дисков Microsoft обновился до VHDX, а платформа виртуализации Hyper-V обновилась до третьей версии.

Поэтому неделю назад Microsoft выпустила Virtual Machine Converter 2.0 (MVMC).

Новые возможности Virtual Machine Converter 2.0:

• Конверсия виртуальных дисков VMware в формат VHD с возможностью последующей загрузки на платформу Windows Azure.
• Нативная поддержка Windows PowerShell, что позволяет разрабатывать различные сценарии по автоматизации задач миграции на платформу Microsoft. На интерфейс PowerShell в MVMC 2.0 был заменен старый интерфейс командной строки MVMC 1.0.
• Поддержка конверсии виртуальных машин Linux с платформы VMware на хосты Hyper-V.
  
• Поддержка виртуальных машин, которые находятся в статусе "офлайн".
• Поддержка нового формата дисков VHDX при конверсии и миграции ВМ на платформы Windows Server 2012 R2 и Windows Server 2012 под управлением Hyper-V.
• Поддержка миграции ВМ на платформах VMware vSphere 5.5, VMware vSphere 5.1 и VMware vSphere 4.1 в среду Hyper-V.
• Поддержка гостевых ОС Windows Server 2012 R2, Windows Server 2012 и Windows 8, которые можно указывать как исходные при конверсии.

Механика работы утилиты Virtual Machine Converter проста - на платформе vSphere делается снапшот виртуальной машины, далее у нее удаляются VMware Tools, потом она выключается, ее диски преобразовываются и копируются на платформу Hyper-V, после чего происходит откат исходной виртуальной машины к начальному состоянию, которое было до снятия снапшота.

При конверсии офлайновой машины VMware Tools не удаляются, вместо этого отключаются сервисы и драйверы, связанные с VMware. Для гостевых ОС Linux удаления VMware Tools не происходит вовсе, поэтому делать это нужно вручную до конверсии.

Скачать Microsoft Virtual Machine Converter 2.0 вместе с документацией можно по этой ссылке.

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

Итак, в новой редакции линейки продуктов для управления ПК предприятия будет 3 издания:

• VMware Horizon View Standard - это традиционное решение для виртуализации настольных ПК предприятия VMware View, к которому добавляем решение для виртуализации ПК VMware ThinApp и составляющие платформы виртуализации - VMware vSphere и vCenter.
• VMware Horizon Advanced - это уже полноценное управление физической и виртуальной инфраструктурой ПК предприятия. Здесь добавляется средство по федерации приложений и рабочих сред Unified Workspace, возможности кластеров хранилищ Virtual SAN, а также средства управления образами физических ПК VMware Mirage.
• VMware Horizon Enterprise - ко всем прочим преимуществам добавляется еще решение VMware vCenter Operations for View 6, обеспечивающее автоматизацию управления и мониторинга инфраструктуры виртуальных ПК (мы писали об этом тут), кроме того в состав включается плагин для оркестрации операций (автоматизации с помощью сценариев) - vCO Plugin for VMware Horizon 6.

Также на картинке мы видим американские цены на лицензии. В России эти цены, само собой, будут существенно выше. Обратите внимание, что VMware View лицензируется только на одновременные подключения пользователей, а вот издания Horizon Advanced и Horizon Enterprise уже можно покупать и как именованные лицензии, что серьезно дешевле.

Так что если все пользователи у вас работают одновременно, лучше купить лицензию на Horizon Advanced - вы получите больше продуктов по цене обычного VMware View.

Кроме всего прочего появляется интересный момент в лицензии VMware vSphere Desktop - теперь она "отделилась" от решения VMware Horizon и доступна не только в его составе, но и отдельно по цене $50 (американская цена) за одновременное подключение пользователя. Ее можно использовать для случаев, когда пользователи используют виртуальные серверные системы (терминальные серверы) или виртуальные ПК для доступа к своим приложениям, при этом не покупают VMware Horizon.

Вкратце это все. Больше информации будет доступно ближе к релизу VMware Horizon 6, который состоится во второй половине этого года.

Как знают все те, кто интересуется решением для создания отказоустойчивых хранилищ StarWind iSCSI SAN, совсем недавно вышла обновленная версия StarWind V8 RC, а скоро будет доступен и финальный ее релиз.

Всем тем, кто ездит на ИТ-мероприятия в Америке, мы рекомендуем посетить стенды StarWind на ближайших конференциях:

С 12 по 15 мая команда StarWind будет на мероприятии Microsoft TechEd 2014 в Хьюстоне, Техас. Номер стенда - #746.

А с 13 по 17 июля StarWind будет представлять свое решение StarWind SAN V8 на всемирной партнерской конференции Microsoft:

Приходите - будет интересно!

Интересную штуку случайно обнаружил на Youtube - ролики Евгения Пономаренко, посвященные работе решения VMware Horizon View 5.3 в различных аспектах. Несмотря на то, что ролики сняты на iPhone 4S, там можно увидеть много чего интересного, например, про производительность VDI-инфраструктуры.

Итак:

VMware Horizon View 5.3 Part 02: Windows 8.1 and Ipad

VMware Horizon View 5.3 Part 03: Windows Server 2008 R2

VMware Horizon View 5.3 Part 04: HTML Access and Skype

VMware Horizon View 5.3 Part 05(Final): Simulation of work with poor WAN

Многие администраторы в курсе, что обновление до Windows 8.1, которое вышло в конце прошлого года, было рекомендовано к установке всем пользователям Windows 8. Однако оно не было обязательным. Теперь же с выходом Windows 8.1 Update 1 сделать это фактически заставят.

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

Во-первых, перед обновлением до Windows 8.1 надо удалить агента VMware View Agent, далее обновить гостевую ОС, а уже после этого поставить агента заново. Но лучше всего - развернуть для пользователя уже новую операционку с Windows 8.1. Это все в рамках стратегии, что всегда лучше ставить заново, чем обновлять (если это, конечно, не очень запарно).

Во-вторых, VMware Horizon View 5.3.1 не поддерживает функции VMware View Persona Management для Windows 8.1. Поэтому когда будете устанавливать VMware View Agent и увидите там отмеченную галку, не обольщайтесь - эти функции работать не будут (не установятся).

Об остальных проблемках с Windows 8.1 и VMware View можно почитать вот тут. Ничего фатального на самом деле.

На днях ИТ-сообщество переполошилось из-за очень неприятного факта - уязвимости OpenSSL HeartBleed, которая была обнаружена в версии защищенного протокола OpenSSL 1.0.1 и 1.0.2-beta. Уязвимость получилась из-за того, что отсутствует необходимая проверка границ в одной из процедур расширения Heartbeat (RFC6520) для протокола TLS/DTLS.

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

Как пишет Хабр, 1 января 2012 года, Robin Seggelmann отправил, а steve проверил commit, который добавлял HeartBeat в OpenSSL. Именно этот коммит и привнес уязвимость, которую назвали Heartbleed. То есть, пару лет любой желающий мог вылавливать данные из памяти где-то 2/3 всех защищенных серверов мира. Эта версия OpenSSL используется в веб-серверах Nginx и Apache, в почтовых серверах, IM-системах, VPN, а также еще очень-очень много где. Сертификаты скомпрометированы, логины/пароли, возможно, утекли к посторонним людям. Кошмар, бардак, ядерная война.

Например, уязвимость есть вот в этих Linux-дистрибутивах:

• Debian Wheezy (стабильная), OpenSSL 1.0.1e-2+deb7u4)
• Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11)
• CentOS 6.5, OpenSSL 1.0.1e-15)
• Fedora 18, OpenSSL 1.0.1e-4
• OpenBSD 5.3 (OpenSSL 1.0.1c) и 5.4 (OpenSSL 1.0.1c)
• FreeBSD 8.4 (OpenSSL 1.0.1e) и 9.1 (OpenSSL 1.0.1c)
• NetBSD 5.0.2 (OpenSSL 1.0.1e)
• OpenSUSE 12.2 (OpenSSL 1.0.1c)

Ну и, конечно же, серверы VMware ESXi 5.5 (build 1331820) и ESXi 5.5 Update 1 (build 1623387) также имеют эту уязвимость. Проверить это просто - выполняем команду:

# vmware -vl

VMware ESXi 5.5.0 build-1331820
VMware ESXi 5.5.0 GA

# openssl version -a

OpenSSL 1.0.1e 11 Feb 2013
built on: Tue Feb 26 16:34:26 PST 2013

Видим, что здесь версия 1.0.1e, которая подвержена уязвимости.

А вот для пользователей VMware ESXi 5.1 бонус - уязвимости тут нет, так как используется другой бранч OpenSSL (0.9.8y):

# vmware -vl

VMware ESXi 5.1.0 build-1612806
VMware ESXi 5.1.0 Update 2

# openssl version -a

OpenSSL 0.9.8y 5 Feb 2013
built on: Wed Mar 20 20:44:08 PDT 2013

Есть даже вот такая табличка с VMware Communities, где показано, какие компоненты и каких версий подвержены уязвимости (выделенные цветом - подвержены):

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

Подробное описание уязвимости можно прочитать на специальном сайте: http://heartbleed.com/.

Проверить свой публичный сайт на наличие уязвимой версии протокола можно вот тут: http://filippo.io/Heartbleed/.

Компания ИТ-ГРАД проводит деловой ужин в Санкт-Петербурге, посвященный обновлению линеек систем хранения данных NetApp.

Недавно была анонсировала серия NetApp FAS8000, которая приходит на смену FAS3200 и FAS6200 и отличается 2х более высокой производительностью, 3х больше Flash и прочее. Об этом и пойдет речь в первой части мероприятия.

Во второй половине мероприятия речь пойдет про обновленную линейку NetApp E-series. Блочные СХД начального и корпоративного уровня отличаются превосходным соотношением цены и производительности. Узнайте подробнее.

Программа мероприятия: 

• NetApp FAS8000 как единственная в отрасли унифицированная горизонтально масштабируемая архитектура.
• Примеры использования: простые SAN, резервное копирование на диски, видеонаблюдение, СМИ и развлечения.
• Проблема, с которой сталкиваются заказчики при организации видеонаблюдения.

Дата проведения:  10 апреля 2014 года в 19:00, г. Санкт-Петербург.

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

Многие администраторы VMware vSphere знают, что еще в версии Veeam Backup and Replication 6.5 появилось средство Veeam Explorer for SAN, которое поддерживает гранулярное (то есть до уровня отдельных объектов гостевой ОС) восстановление виртуальных машин напрямую из снапшотов, сделанных устройствами хранения. До настоящего времени это решение поддерживало только хранилища HP StoreVirtual VSA и HP LeftHand (а также была добавлена поддержка StoreServ, т.е. 3PAR). Эта технология изначально была разработана Veeam совместно с HP и поддерживала все функции Veeam: Instant VM Recovery, Instant File-Level Recovery и Explorer for Exchange item recovery.

Теперь же, совсем недавно, компания Veeam Software объявила о партнерстве с NetApp - одним из лидеров в области производства систем хранения данных. Теперь Veeam Backup & Replication 8, который будет следующим мажорным релизом ведущего продукта для резервного копирования и репликации ВМ, сможет восстанавливать виртуальные машины напрямую из снапшотов NetApp:

Это уже вторая фича, заявленная к выпуску в восьмой версии Veeam B&R, первой, напомним, было средство восстановления объектов каталога Active Directory из резервных копий виртуальных машин - Veeam Explorer for Active Directory.

Основные возможности Veeam Explorer for SAN при работе с массивами NetApp:

• Fast backups: возможность резервного копирования виртуальных машин из снапшотов хранилищ, сделанных самим NetApp, что работает до 20 раз быстрее.
• Quick recovery: возможность восстановления машин или их отдельных объектов (документы Exchange, файлы гостевых ОС и т.п.) из объектов хранилищ, сделанных средствами технологий NetApp Snapshot, SnapMirror и SnapVault.
• Improved protection: возможность создания снапшотов или удаленных резервных копий инфраструктуры средствами хранилищ NetApp (например, на DR-площадке).

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

Интеграция Veeam Backup & Replication 8 и массивов NetApp ожидается во второй половине 2014 года. Пока же можно посмотреть вебинар "How Veeam and NetApp deliver Advanced Data  Protection for the Modern Data Center", который пройдет 17 апреля.

Более подробно об интеграции Veeam и NetApp можно почитать на этой странице.

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

Напомним, что продукты StarWind iSCSI SAN and NAS и StarWind Native SAN for Hyper-V предназначены для создания отказоустойчивых хранилищ виртуальных машин для платформ VMware и Hyper-V в частных облаках предприятий. Хранилища, построенные на базе технологии StarWind iSCSI, не требуют дополнительных инвестиций в инфраструктуру сети хранения, работают на базе проверенного протокола iSCSI и имеют функции отказоустойчивости на базе двух или трехузловых кластеров.

Упомянутые продукты StarWind попали в шортлист премии Datacentre Solutions Awards в категории Datacentre ICT Storage Software of the Year.

Голосуйте за StarWind!

Голосуйте скорее - прием голосов закончится 1 мая.

Ну а совсем скоро состоится релиз StarWind iSCSI SAN v8, где будет поистине много новых возможностей!

Оказывается у компании VMware есть такой ресурс whychooseview.com, где она не только рекламирует свое решение для виртуализации настольных ПК предприятия VMware View, но и достаточно активно крошит батоны на конкурирующее решение - Citrix XenDesktop.

Делает она это в виде табличек:

В виде разделов с соответствующими документами:

А также в виде видеороликов на своем Youtube-канале:

Кстати, последние два, все-таки, стоит посмотреть тем кто выбирает VDI-решение, хоть это и реклама в пользу VMware:

С одной стороны, это, конечно, хорошо, так как позволяет вам убедить руководство или всякие там комиссии в том, что вы сделали правильный выбор, заказав VMware View вместо Citrix XenDesktop. А с другой стороны, напрашивается вопрос - а не слишком ли неэтичную кампанию ведет VMware, так открыто глумясь над конкурентом в различных медиа-ипостасях? Или это просто обычный комплекс неполноценности, которым Microsoft страдает в своих табличках о сравнении Hyper-V и vSphere?

Интересную особенность тут обнаружил один из читателей Дукана Эппинга: оказывается в VMware vSphere 5.5 Update 1 при перезапуске/выключении хоста VMware ESXi через консоль DCUI рестарта его виртуальных машин посредством механизма VMware HA не происходит.

Ну то есть, если выключение ESXi делать по клавише <F12> в консоли сервера:

Действительно, в этом случае в логе FDM можно увидеть вот такую запись:

2014-04-04T11:41:54.882Z [688C2B70 info 'Invt' opID=SWI-24c018b] [VmStateChange::SavePowerChange] 
vm /vmfs/volumes/4ece24c4-3f1ca80e-9cd8-984be1047b14/New Virtual Machine/New Virtual Machine.vmx 
curPwrState=unknown curPowerOnCount=0 newPwrState=powered off clnPwrOff=true hostReporting=host-113

Это означает, что VMware vSphere считает, что виртуальные машины были выключены корректно (администратором/хостом), а значит их перезапуск механизмом VMware HA не требуется (параметр clnPwrOff=true).

Совсем другая картина, если мы делаем ребут или выключение VMware ESXi из VMware vSphere Client или vSphere Web Client:

В этом случае в логе FDM мы обнаружим что-то вроде такого:

2014-04-04T12:12:06.515Z [68040B70 info 'Invt' opID=SWI-1aad525b] [VmStateChange::SavePowerChange] 
vm /vmfs/volumes/4ece24c4-3f1ca80e-9cd8-984be1047b14/New Virtual Machine/New Virtual Machine.vmx 
curPwrState=unknown curPowerOnCount=0 newPwrState=powered on clnPwrOff=false hostReporting=host-113

Здесь уже мы видим, что clnPwrOff=false, а значит vSphere полагает, что что-то пошло не так и VMware HA перезапустит виртуальные машины "отказавшего" хоста.

Это поведение актуально для VMware vSphere 5.5 Update 1, но пользователи в комментариях к статье Дункана отмечают, что подобное поведение наблюдается и для vSphere 5.0. Поэтому будет не лишним знать об этом всем тем, кто после настройки отказоустойчивого кластера VMware HA тестирует его работоспособность путем перезагрузки хостов ESXi.

Совсем недавно мы писали про то, что компания StarWind Software выпустила предрелизную версию своего решения для создания отказоустойчивых кластеров хранилищ - StarWind SAN V8 Release Candidate. Там будет огромное количество новых возможностей, которые позволят вывести инфраструктуру виртуальных хранилищ на базе локальных дисков серверов на еще более высокий уровень.

Многих пользователей продукта интересует вопрос, а что будет если оба узла StarWind SAN окажутся недоступны в результате аварии или массового сбоя?

Ответ прост - вам достаточно восстановить и запустить один из узлов, после чего выбрать на нем в Management Console нужное устройство и в его контекстном меню выбрать пункт "Mark As Synchronized":

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

Если второй узел потерян навсегда - нужно просто развернуть новую ноду и настроить синхронизацию на нее.

Недавно компания VMware начала серию статей про совместимость ее решения для организации кластеров хранилищ Virtual SAN с различными продуктами (например, с vCloud Automation Center и решением для резервного копирования vSphere Data Protection). Но многих пользователей интересует юзкейс использования VSAN для катастрофоустойчивой инфраструктуры, управляемой VMware Site Recovery Manager. А именно, с точки зрения экономии, наиболее интересным вариантом является создание резервной инфраструктуры на базе хранилищ локальных дисков серверов VMware ESXi, бэкэнд которых обеспечивается кластером хранилищ VSAN:

Такая схема полностью поддерживается со стороны VMware, как для решения vSphere Replication, обеспечивающего репликацию виртуальных машин на резервный сайт и его VSAN-хранилища, так и для vCenter Site Recovery Manager, обеспечивающего оркестрацию процесса.

Естественно, на данный момент поддерживается совместимость SRM+VSAN только на базе технологии асинхронной репликации vSphere Replication, поэтому такой сценарий не подойдет тем, кто хочет обеспечить RPO=0 для сервисов виртуальных машин в случае массового сбоя или катастрофы на основной площадке. Но для сценариев с RPO=15 минут такая схема вполне подойдет.

Зато такая схема не требует больших вложений в резервную инфраструктуру - не нужно покупать дорогостоящие FC-хранилища, SAN-коммутаторы и прочее. Для организации такой схемы резервирования можно использовать как только механизм vSphere Replication (но тогда потребуются регулярные ручные операции + ручное сопровождение в случае сбоя), так и автоматизировать процесс с помощью vCenter SRM.

При этом SRM может обеспечить следующие возможности:

• Автоматизированный Failover и Failback (нужно только нажать кнопку).
• Управление процессом восстановления из консоли vCenter.
• Возможность запланированной миграции сервисов на резервную площадку (при этом основную площадку можно сделать резервной).
• Несколько точек для восстановления в случае порчи данных (например, надо откатиться на день назад).
• Возможность протестировать процесс восстановления, не затрагивая продакшен-среду.

На тему всего этого компания VMware сделала отличное поясняющее видео, в котором показан процесс переезда с традиционной SAN-инфраструктуры на новую площадку, где хранилища построены на базе технологии VMware Virtual SAN:

Не все администраторы VMware vSphere знают о том, что в версии vSphere 5.5, компания VMware сделала специальную настройку для виртуальных машин - Latency Sensitivity. Она позволяет снизить издержки на виртуализацию для виртуальной машины в случае, когда требуется ее производительность близкая к нативной (то есть почти без потерь на нужды слоя виртуализации).

Найти ее можно в vSphere Web Client, если выбрать нужную ВМ, перейти на вкладку Manage, далее выбрать Settings->VM Options и в разделе Advanced Settings перейти на опцию Latency Sensitivity:

Там можно выбрать значения Low, High, Medium и Normal, однако значения Medium и Normal в vSphere 5.5 являются экспериментальными, поэтому пока можно использовать только Low (по умолчанию) и High (режим высокой производительности для чувствительных нагрузок).

Детально о том, что конкретно делает этот режим, можно почитать в документе "Deploying Extremely Latency-Sensitive Applications in VMware vSphere 5.5", мы же здесь приведем основные моменты.

Итак, если вы ставите Latency Sensivity для виртуальной машины в значение High, происходит следующее:

Виртуальная машина получает эксклюзивный доступ к физическим ресурсам хоста

• Планировщик CPU хоста ESXi определяет возможность того, может ли быть предоставлен эксклюзивный доступ виртуального процессора vCPU к физическому процессору (ядру) сервера pCPU, учитывая реальное состояние процессора (нагруженность, over-commit и прочее). При возможности происходит резервирование pCPU для виртуального процессора на 100%. В этом случае никакие другие vCPU и трэды не могут быть исполнены на этом pCPU (включая VMkernel I/O threads).
• Возможность latency-sensitivity требует от пользователя установки резервирования памяти (Memory Reservation), чтобы выделенная виртуальной машине память не была ненароком отдана другой машине средствами Memory Ballooning. Это позволит дать гарантию, что машина всегда будет иметь в своем распоряжении четко выделенный сегмент физической оперативной памяти хоста ESXi, даже в случае недостатка ресурсов на хосте.

Обход слоя виртуализации

• Как только машина получила эксклюзивный доступ к pCPU, ее виртуальный процессор может напрямую взаимодействовать с его ресурсами в обход планировщика VMkernel. Это ликвидирует затраты на переключение между VMkernel и монитором виртуальных машин (VMM), однако переключения между исполнением кода гостевой ОС и VMM по-прежнему остаются (но это делается очень быстро за счет технологий аппаратной виртуализации, которые есть сейчас в любом процессоре).

Тюнинг механизмов виртуализации на хосте

• Когда в качестве виртуального сетевого адаптера (VMNIC) виртуальной машины используется устройство VMXNET3, то функция Interrupt coalescing и поддержка LRO отключаются, чтобы уменьшить время отклика и джиттер. Если виртуальной машине не нужны такие функции, как vMotion, NetIOC и Fault tolerance, то можно и нужно использовать механизмы проброса сетевого устройства напрямую в виртуальную машину (pass-through) через механизм Single-root I/O virtualization (SR-IOV). Поддержка этого механизма появилась еще в VMware vSphere 5.1, но была существенно доработана в версии 5.5.

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

Чуть больше, чем через два месяца после релиза платформы виртуализации Red Hat Enterprise Virtualization (RHEV) 3.3, компания Red Hat выпустила бета-версию RHEV 3.4, где появилось значительное количество новых возможностей.

А именно, вот что нового нам обещают в RHEV 3.4:

• Более плотная интеграция с инфраструктурой OpenStack:
  • Улучшения безопасности и масштабируемости для сетей, развернутых с помощью Neutron.
  • Поддержка технологии Open vSwitch (расширяемый виртуальный коммутатор) и возможностей SDN-сетей.
• Улучшения enterprise-функций сетевого взаимодействия:
  • Единая точка конфигурации сетевых настроек множества хостов в указанной сети.
• Улучшения enterprise-функций хранилищ:
  • Смешанные домены хранилищ (mixed storage domains) - возможность одновременного использования дисковых устройств из хранилищ  iSCSI, FCP, NFS, Posix и Gluster для организации хранения виртуальных машин.
  • Возможность указания дисков, которые будут участвовать в создании снапшотов, а также тех, которые не будут. Кроме того, улучшен механизм восстановления ВМ из резервной копии - теперь есть возможность указать снапшот состояния, в которое хочется откатиться.
• Улучшения средств управления на всех уровнях:
  • Улучшения планировщика виртуальных машин.
  • Группы Affinity/Anti-Affinity (правила существования виртуальных машин на хостах - размещать машины вместе или раздельно).
  • Возможность горячего добавления процессора в ВМ (Hot Plug CPU). Тут нужна поддержка со стороны ОС.
  • Сервис настройки SNMP для поддержки сторонних систем мониторинга.
  • Сохранение настроек облачной инсталляции RHEV для возможности ее восстановления при сбое или для целей тиражирования в других облаках.

Решение RHEV 3.4 Beta доступно уже сегодня для всех пользователей Red Hat Enterprise Virtualization. Скачать решение RHEV можно на этой странице.

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

Интересно, что из 580 виэкспертов прошлого года в этом году подтвердили свое звание 514 человек. То есть, VMware как бы затягивает.

Ну и снова приятно, что можно сказать про себя "vExpert 2009-2014". Шесть лет уже, мда...

P.S. Кстати, пользуясь случаем, хочу тут заявить, что обещанная сумочка vExpert, которая доезжала в самые захолустные места земного шара, ко мне в центр Питера так и не приехала(.

Как вы знаете, у компании VMware есть несколько сертификаций технических специалистов (например, VCP и VCAP), но самой почетной из них является VMware Certified Design Expert (VCDX), которая подразумевает не только сдачу нескольких непростых экзаменов, но и защиту своего проекта на "панели экспертов", то есть перед такими же сертифицированными VCDX, одним из которых в случае успеха может стать соискатель.

Однако в последнее время сертифицированных экспертов VCDX стало становиться угрожающе много, и данное звание стало терять популярность, поэтому VMware решила предпринять некоторые шаги по ее возвращению. Первым из таких шагов стала организация так называемой "Spiritual panel" вместо надоевшей многим "Expert panel", в ходе которой проверяются не только знания, получаемые зубрежкой документации, но и, например, умение рассказать о своем проекте в течение 15 секунд после выхода из фазы быстрого сна или способности кандидата по расслаблению духа и тел панелистов. Кроме этого, решающим навыком при сдаче финального экзамена будет возможность подтвердить свою физическую готовность к выездам в датацентры заказчика путем выполнения нормативов, примерно соответствующих нормам ГТО IV.

Специально для этих целей компания VMware решила арендовать 15 СПА-салонов и 10 спортзалов, расположенных в непосредственной близости от Moscone Center в Сан-Франциско, где пройдет конференция VMworld 2014, и на которой состоится первая защита званий VCDX по новым правилам программы.

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

Некоторое время назад мы неоднократно писали о замечательном продукте VMware vCenter Log Insight, который предназначен для автоматизированного управления файлами журналов (логами), сбора данных, их анализа и поиска (вот тут интересно про поиск). Попросту говоря, это мощный поиск по логам и их визуализатор, который используется для поиска причин проблем в виртуальной инфраструктуре (root cause analysis).

Так вот на днях вышла бета мажорной версии этого решения - VMware vCenter Log Insight 2.0 Beta.

Давайте взглянем на новые возможности VMware vCenter Log Insight 2.0:

• Улучшенная масштабируемость и производительность в кластерах
  • Улучшения скорости обмена до 5-10 раз при работе в режиме Cluster mode
  • Единая точка интерфейса для работы со всеми массивами данных
• Проактивная аналитика
  • Обучаемая система типов событий и распознавания схем данных с интеллектуальной группировкой
  • "Умные поля" в отчетах
• Улучшенные дэшборды
  • Простое добавление фильтров на лету
  • Возможность взаимодействия между разными виджетами одного дэшборда
• Поддержка RESTful API при работе с логами
• Улучшенные механизмы мониторинга собственного состояния
• Агент для сбора логов Windows
  • Перенаправляет Windows event logs
  • Мониторит изменения файлов журнала
  • Функции централизованной отчетности и управления логами

Начать знакомиться с vCenter Log Insight 2.0 можно в VMware vCenter Log Insight Getting Started Guide. Кроме того, 1 апреля пройдет специализированный вебинар по продукту.

Ну а скачать VMware vCenter Log Insight 2.0 Beta можно по этой ссылке.

Компания ИТ-ГРАД, расположенная в ИТ-ГРАД, регулярно проводит мероприятия (семинары и демонстрации), посвященные облачным инфраструктурам, оборудованию NetApp. Все это проходит на базе Центра компетенции ИТ-ГРАД.

Мероприятия нацелены на общение и дают возможность делиться накопленным опытом. Поэтому специалисты ИТ-ГРАД будут рады видеть вас не только в своем Центре компетенции, но и на форумах, конференциях, круглых столах и других мероприятиях, которые проводят их коллеги и СМИ.

FlexPod со всех сторон

Узнайте, почему совместное решение Cisco/NetApp = FlexPod является самым быстрорастущим по занимаемым объемам рынка во всем мире. Получите ответы на вопросы: Каковы технологические преимущества системы хранения данных NetApp перед конкурентами? Чем сервера Cisco UCS отличается от традиционных блейд-серверов? Чем полезны и как использовать Cisco Validated Design (CVD)? Storage Efficiency, как снизить стоимость хранения данных Как решаются вопросы поддержки и конвергентные решения? ЗАРЕГИСТРИРОВАТЬСЯ

Критерии выбора СХД под виртуализацию

На мероприятии мы расскажем про основные критерии, которые стоит учитывать при выборе СХД для построения виртуальной инфраструктуры. В качестве практического дополнения наш инженер расскажет об опыте эксплуатации СХД NetApp в работе публичного облака ИТ-ГРАД.   Дедупликация данных как средство экономии дискового пространства; Частое использование снапшотов без снижения производительности; Возможность интеграции с гипервизором и средствами управления. ЗАРЕГИСТРИРОВАТЬСЯ

Миграция в облако: пошаговый сценарий  

В рамках данного семинара мы расскажем о нюансах переноса сервисов в публичное облако:     Какие сервисы стоит в первую очередь переносить в облака? Что необходимо предусмотреть для того, чтобы мигрировать? Как обосновать руководству полезность и необходимость облаков? Способы сокращения возможного простоя при миграции. ЗАРЕГИСТРИРОВАТЬСЯ

Использование публичных облаков в ритейле

На данном семинаре мы расскажем о наших заказчиках из сферы ритейла, какие сервисы они перенесли к нам, какую модель оказания услуг выбрали и почему. Приведем примеры и цитаты конкретных заказчиков.Дополнительно будут освещены следующие нюансы:    Мифы и практические реалии многолетнего опыта работы с облаками; Централизация сервисов как способ экономии ИТ-бюджета; Масштабируемость как средство снижения издержек при открытии новых точек продаж; Ресурсы по запросу как средство обеспечения пиков сезонных продаж; Наличие SLA как залог спокойствия; Резервирование инфраструктуры в облаке. ЗАРЕГИСТРИРОВАТЬСЯ

Как знают все те, кто интересуется решением для создания отказоустойчивых хранилищ StarWind iSCSI SAN, совсем недавно вышла обновленная версия StarWind V8 RC, которая пришла на смену StarWind V8 Beta 3.

Совсем скоро появится релизная восьмая версия продукта, в которой будет масса нововведений, в том числе обновленное средство для деплоя ПО StarWind на серверы VMware ESXi - StarWind VSA Builder.

При установке этот компонент называется VSAN Deployment Tools:

Для начала процесса развертывания ПО StarWind нужно нажать на иконку Deploy VSAN в Management Console:

Указываем параметры сервера VMware ESXi:

Указываем путь к ISO-образу с установкой Windows Server или скачиваем его:

Далее указываем исошник к инсталляции StarWind или также скачиваем:

После чего указываем хранилище хоста VMware ESXi, где будет размещена виртуальная машина:

Далее указываем параметры виртуального диска StarWind - то есть, непосредственного хранилища виртуальных машин на диске полученной машины:

Ну и после всего этого начнется развертывание виртуальной машины с ПО StarWind внутри:

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

Скачать StarWind iSCSI SAN V8 Release Candidate можно по этой ссылке.

Некоторые администраторы (которые, например, используют контроллер домена как единую точку руления инфрастуктурой) были удивлены, что с выходом VMware vSphere 5.5 толстый C#-клиент vSphere Client отказывается устанавливаться на контроллере Active Directory. При попытке такой установки будет показана ошибка:

vSphere Client requires Windows XP SP2 or later. 
vSphere Client cannot be installed on a Domain Controller.

Все это от того, что у Microsoft есть стандарт о том, что на контроллере домена не должно быть установлено никакого дополнительного ПО, не относящегося к функциям AD. И VMware вынуждена ему подчиняться. Хотя это и не логично - не всем нужна отдельная машина в небольшой инфраструктуре чисто под управление VMware vSphere.

Ограничение обходится просто. Запускаем установщик клиента с параметром обхода проверок:

VMware-viclient.exe /v "SKIP_OS_CHECKS=1"

Второй вариант - использовать на контроллере домена виртуализованный с помощью ThinApp толстый клиент (ThinApped vSphere Client), о котором мы уже писали тут.

Но его придется создать самостоятельно - актуальная версия поддерживаемой сейчас платформы - vSphere 5.0. Хотя есть кастомные версии и для 5.1.

Осенью прошлого года мы писали про то, что компания Amazon (лидер рынка в сфере облачных IaaS-решений), анонсировала сервис WorkSpaces, который позволяет арендовать виртуальные машины, выглядящие и работающие как персональные ПК. На днях же Amazon выпустила окончательную версию WorkSpaces, которая, однако, пока доступна только в США и только в регионах US East (Северная Вирджиния) и US West (Орегон). Понятное дело, что если эксперимент окажется успешным, то Amazon будет предоставлять эту услугу компаниям по всему миру.

Напомним, что так как компания Microsoft по-прежнему на уровне лицензии запрещает предоставление в аренду виртуальных ПК с клиентскими гостевыми ОС, то в WorkSpaces выдают пользователям Windows Server 2008, кастомизированный под Windows 7 (для каждого десктопа - отдельная лицензия). То есть дают так называемый "Windows 7 experience".

Начать работу с WorkSpaces можно прямо из  AWS Management Console:

А вот так выглядит консолька WorkSpaces после соединения пользователя со своим виртуальным ПК в инфраструктуре Amazon:

В среде WorkSpaces компания Amazon предлагает на выбор один из четырех стандартных бандлов:

• Standard - 1 vCPU, 3.75 ГБ памяти, 50 ГБ постоянного хранилища для пользователя из облака S3.
• Standard Plus - 1 vCPU, 3.75 ГБ памяти, 50 ГБ постоянного хранилища для пользователя и дополнительные приложения (Microsoft Office и антивирус Trend Micro).
• Performance - 2 vCPU, 7,5 ГБ памяти, 100 ГБ постоянного хранилища для пользователя.
• Performance - 2 vCPU, 7,5 ГБ памяти, 100 ГБ постоянного хранилища для пользователя и те же дополнительные приложения.

Во всех бандлах есть множество утилит и приложений, среди которых Adobe Reader, Adobe Flash, Firefox, Internet Explorer 9 и 7-Zip.

С точки зрения протокола доступа пользователя к своему ПК, Amazon применяет разработки компании Teradici (а именно, их протокол PCoIP), которая, как известно, сотрудничает еще и с VMware (для организации доступа в инфраструктуре VMware View), которая является прямым конкурентом Amazon. Напомним также, что совсем недавно компания VMware объявила о доступности собственного сервиса по аренде виртуальных ПК - VMware Horizon DaaS Platform (от приобретенной компании Desktone) - который также построен по схеме с ОС Windows Server.

Для получения виртуального ПК потребуется аккаунт на AWS, PC или Mac с клиентом WorkSpaces, и подключение к интернету по портам (TCP на 443 и TCP+UDP на 4172). Также можно использовать мобильную версию клиента WorkSpaces для iPad, Kindle Fire HDX и Android.

Кроме того, одновременно с релизом WorkSpaces, Amazon выпустила и WorkSpaces Sync Client, который автоматически создает резервные копии документов пользователя в облако Amazon S3.

Для комфортной работы пользователя с виртуальным ПК Amazon рекомендует иметь соединение с latency не более 100 ms, но и на 200-300 ms будут неплохие результаты (более - уже не пойдет).

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

Аутентификация пользователей может проходить как через Active Directory организации (растягивание сети через VPN), так и через Cloud Directory.

Документация по Amazon WorkSpaces доступна по этой ссылке. Ждем возможности использовать у нас тут - интересная штука.

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

Специально для этого компания VMware сделала обучающее видео по процессу резервного копирования и восстановления конфигурации VMware vSphere Distributed Switch:

Но это еще не все. Для тех, кто хочет пройти эти процессы самостоятельно на практике, VMware сделала пошаговое руководство в формате walkthrough (о них мы уже писали тут и тут) - то есть набора экранов, где нужно самостоятельно кликать на элементы в vSphere Web Client: