Пока все обсуждают то, что из Citrix ушли ключевые люди, а 12 июля VMware объявит о своей платформе VMware vSphere 5, мы расскажем о другом.
Хорошая новость для тех, кому необходимы средства для защиты инфраструктуры виртуализации VMware vSphere. Как многие знают, есть такое семейство продуктов VMware vShield, среди которых есть средства для обеспечения безопасности виртуальных машин, хост-серверов ESX / ESXi и периметра датацентра.
Теперь суть новой промо-акции. Любой пользователь VMware, приобретающий продукт VMware vSphere до 15 сентября 2011 года, получает бесплатно 50 лицензий на VMware vShield Data Security. Кстати, не очень понятно пока, какие именно компоненты vShield включены в промо-пакет, ведь как такого продукта VMware vShield Data Security еще нет, он выйдет несколько позже. При этом по данному промо, к пакету идет бесплатно поддержка и подписка на обновления на 1 год (SnS).
Исключение из акции составляют пакеты ПО VMware vSphere Essentials и VMware vSphere Essentials Plus, которые как всегда в пролете.
Список парт-номеров и названия продуктов, участвующих в акции, приведен здесь. Так что не забывайте задать вопрос своему поставщику VMware про данную акцию.
Продолжаем вам рассказывать о средстве vGate от компании Код Безопасности, которое необходимо для двух важных с точки зрения информационной безопасности вещей: защиты компонентов VMware vSphere от несанкционированного доступа (НСД) и автоматической настройки среды VMware vSphere (хосты ESX и виртуальные машины) в соответствии со стандартами и регламентами по обеспечению безопасности виртуальных инфраструктур.
На фоне грядущей ответственности за неисполнения норм ФЗ 152 продукт vGate R2 будет вам очень полезен, тем более, что он имеет сертификат ФСТЭК. Согласно сертификату ФСТЭК России №2308, программное средство защиты информации разработки компании «Код Безопасности» vGate R2 предназначено для защиты от несанкционированного доступа к информации, не содержащей сведения, составляющие государственную тайну, и может применяться в автоматизированных системах уровня защищенности до класса 1Г включительно и в информационных системах персональных данных (ИСПДн) до класса К1 включительно.
А сегодня - еще одна важная новость. В данное время продукт vGate R2 с поддержкой ESXi передан во ФСТЭК России для прохождения инспекционного контроля. Поступление сертифицированного продукта в продажу ожидается в августе 2011 года (т.е. ближе к релизу vSphere 5).
"При разработке новой версии vGate R2 мы постарались учесть все пожелания наших заказчиков. Теперь vGate R2 поддерживает ESXi-сервера, а также содержит новые встроенные наборы шаблонов для АС по требованиям ФСТЭК и для ИСПДН по требованиям СТО БР ИББС. Реализованные в новой версии vGate R2 функции значительно облегчат приведение виртуальных инфраструктур в соответствие законодательству, обеспечат непрерывность в соблюдении политик безопасности и позволят сократить затраты на обеспечение ИБ. На этом мы не останавливаемся и продолжаем дальше развивать vGate с учетом пожеланий наших заказчиков. Сегодня любой желающий может внести свой вклад в развитие vGate, предложив идею относительно развития функционала продукта на нашем сайте", - отметила Мария Сидорова, заместитель руководителя направления "Защита виртуальных инфраструктур" компании «Код Безопасности».
Свой вклад в развитие продукта vGate R2 можно внести, оставив комментарий вот в этой форме на сайте Кода Безопасности.
Скачать пробную версию vGate R2 можно по этой ссылке (вам выдадут лицензию на 60 или 90 дней). В ближайшее время мы подробно рассмотрим механизм защиты информации в виртуальной инфраструктуре VMware vSphere от несанкционированного доступа, а также расскажем о процессе установки vGate R2.
Мы уже писали об утилите VDI Sizing Tool от отчественного разработчика Василия. Она позволяет сымитировать нагрузку на виртуальные ПК предприятия (VMware View или Citrix XenDesktop) с помощью специальных агентов и измерить производительность решения (старт приложений, создание RDP-сессии и т.д.).
Недавно вышла версия VDI Sizing Tool 0.2. В новой версии утилиты появилась поддержка VMware View Client для протоколов RDP и PCoIP. А
на сайте автора появилась статья про сравнение потребления ресурсов
протоколами PCoIP и RDP:
В документе детально описана концепция Dynamic Memory, технологии, появившейся в Microsoft Windows Server 2008 R2 SP1, рассмотрены варианты ее применения и настройки, а также даны лучшие практики по ее использованию в производственной среде. Документ весьма понятный и очень нужный для администраторов Hyper-V.
Второе - несколько интересных документов от Veeam Software, выпускающей продукт номер один Veeam Backup and Replication 5 для создания систем резервного копирования VMware vSphere. Документы написаны известными блоггерами, давно пишущими о виртуализации на базе VMware.
VMware Recovery: 77x Faster! - интересный документ о практическом применении новейших технологий в продукте Veeam Backup: мгновенное восстановление ВМ из резервных копий, верификация резервных копий в автоматических лабораториях и восстановление отдельных объектов приложений. Все с интересными картинками.
Третье - очередной документ "Project Virtual Reality Check Phase IV" от Login Consultants. Вы их уже знаете по заметкам у нас тут и тут. Коллеги сравнивают производительность различных продуктов и технологий в сфере виртуализации и выкладывают результаты в открытый доступ. На этот раз сравнивались продукты для виртуализации приложений в инфраструктуре VDI: Citrix Application Streaming (XenApp), Microsoft App-V и VMware ThinApp.
Интересно, что VMware ThinApp бьет почти все остальные варианты:
Случилось так, что один из билдов новой операционной системы Windows 8 утек в сеть (build 7989). Блоггер Robert McLaws, заведующий веб-ресурсом windows-now.com, нашел в новой ОС несколько возможностей, относящихся к виртуализации на базе Hyper-V, вероятно, версии 3.0.
Вот что нашел Роберт:
Хранилища
Виртуальный HBA-адаптер для виртуальных машин - Virtual Fibre Channel Adapter (хотя на картинке не он, а просто новые настройки сети для виртуальных машин).
Пулы ресурсов для систем хранения (картинка), которые позволяют кобинировать различные категории хранилищ в целях лучшей управляемости.
Новый формат виртуальных дисков VHDX, который поддерживает диски до 16 ТБ, а также имеет возможности защиты от сбоя питания (картинка). Данный формат может быть использован, только начиная с Windows 8.
Улучшения вычислительных ресурсов (Memory/Processor)
Поддержка более 4 ядер (картинка, я не очень понял что имеется в виду).
Новые настройки NUMA-узлов (картинка - Memory per Node, Cores per Node, Nodes per Processor Socket).
Улучшения сетевого взаимодействия (Networking Enhancements)
Поддержка аппаратного ускорения для сетевых адаптеров (картинка - техники Virtual Machine Queue и IPsec Offload).
Управление пропускной способностью адаптеров (картинка - минимум, максимум).
DHCP Guard - запрет на получение адресов неавторизованным виртуальным машинам.
Router Guard - отклоняет сообщения Advertisement и Redirection для неавторизованных ВМ, которые хотят притвориться роутерами.
Monitor Port - возможность перенаправления трафика виртуальной машины (входящего и исходящего) на другой порт в целях мониторинга ИБ.
StarWind Enterprise iSCSI Target в виде VSA позволит вам создать хранилища для виртуальных машин VMware vSphere или Microsoft Hyper-V в виде виртуальных серверов хранения (в ВМ), которые развертываются из уже готовой машины StarWind VSA. Для платформ ESX / ESXi и Hyper-V компания StarWind выпустила отдельные версии. Сам виртуальный модуль построен на базе Gentoo Linux и не требует отдельной лицензии Windows.
Отличительная особенность от аналогичных продуктов, поставляемых в виде виртуальных модулей (например, Openfiler) - это то, что с помощью этих модулей можно создать хранилища с высокой доступностью, которые в случае выхода из строя одного из узлов (т.е. ВМ или хост-сервера) мгновенно переключается на работу с синхронизированным резервным хранилищем.
О решении для создания хранилищ StarWind Enterprise iSCSI в виртуальных машинах мы уже писали тут. Его можно использовать для филиалов и небольших компаний, где нет возможности закупить дорогостоящие системы хранения данных, и даже нет денег на покупку отдельных серверов хранения.
Установка продукта StarWind VSA очень проста - вы импортируете виртуальный диск на хранилище VMware ESX или ESXi (понятное дело, что это может быть как локальный том VMFS, так и общее хранилище NFS/VMFS), создаете новую виртуальную машину, к которой подцепляете этот диск vmdk, а также еще один виртуальный диск для хранения данных виртуальных машин, которые будут защищены с помощью высокой доступности.
Конфигурацию машины StarWind VSA рекомендуется сделать такой (пока нет точной информации по этому поводу):
Guest OS - other Linux 64 bit
RAM - 1 GB
2 vNIC
можно поставить paravirtualized SCIS-контроллер для диска с данными
После загрузки этой машины, на стартовом скрине можно будет увидеть IP-адрес, полученный по DHCP, а дальше ее можно подцепить с помощью StarWind Management Console, где уже настраиваются сетевые и прочие параметры:
Процесс установки для платформы Hyper-V в принципе аналогичен. Понятное дело, когда выйдет релизная версия StarWind VSA, она будет поставляться в виде виртуального модуля OVF, чтобы машину можно было сразу импортировать на ESX.
Насчет логина и пароля к Linux-консоли StarWind VSA. Это vsa и starwind, соответственно. Для добавления VSA к консоли управления логин и пароль остались теми же: root и starwind.
Скачать StarWind VSA сейчас можно бесплатно и без регистрации с пробной лицензией на 120 дней по этой ссылке.
Как знают администраторы систем хранения данных, у различных компонентов SAN-сети есть такой параметр как глубина очереди (Queue Depth). Он есть у HBA-адаптера сервера (на котором, например, работает VMware ESX / ESXi) и у порта Storage Processor'а системы хранения (SP). Глубина очереди определяет сколько операций ввода-вывода (IO) может быть одновременно обработано на устройстве.
Как мы уже писали, если до SP со стороны сервера ESX / ESXi используется один активный путь, то глубина очереди целевого порта массива (T) должна удовлетворять следующему соотношению:
T >= Q*L,
где Q - это глубина очереди на HBA-адаптере, а L - число LUN, обслуживаемых SP системы хранения. Если у нас несколько активных путей к одному SP правую часть неравенства надо еще домножить на P - число путей.
Соответственно, в виртуальной инфраструктуре VMware vSphere у нас несколько хостов имеют доступ к одному LUN через его SP и получается следующее соотношение:
T>= ESX1 (Q*L*P) + ESX2 (Q*L*P)+ и т.д.
Queue Depth на серверах
По умолчанию, для хостов VMware ESX / ESXi значение Queue Depth равно 32, как его изменить, читайте у нас тут и вот тут. Теперь внимание: этот параметр имеет значение только когда у вас только одна виртуальная машина на хост-сервере использует конкретный LUN. Если его используют уже 2 машины, то он игнорируется, а в действие вступает следующая расширенная настройка (Advanced Setting - как его задавать описано тут):
Disk.SchedNumReqOutstanding (DSNRO)
Этот параметр также по умолчанию равен 32. Он глобально определяет, сколько операций ввода-вывода (IOs) может максимально выдать одна виртуальная машина на LUN одновременно. В то же время, он задает это максимальное значение в IOs для всех виртуальных машин на этот LUN. То есть, если задано значение 32, то все машины могут одновременно выжать 32 IOs, это подтверждается в статье Jason Boche, где 3 машины генерируют по 32 одновременных IO к одному LUN, а реально к LUN идут все те же 32, а не 3*32:
Здесь видно, что активно выполняется 30 команд (максимально 32) для параметра DQLEN, а остальные 67 остаются в очереди. То есть параметр определяет максимальную планку в IO как для одной машины на LUN, так и для всех машин на LUN.
Важно, чтобы параметры Queue Depth и DSNRO были установлены в одно и то же значение. Это рекомендация VMware. Так что, если вздумаете изменить один из них - не забудьте и про второй. И помните, что параметр DSNRO для хоста - глобальный, а значит будет применяться ко всем LUN, подключенным к хосту.
Target Port Queue Depth на массивах
Для дискового массива (а точнее, SP) очередь - это то, куда он сладывает SCSI-команды в то время, пока обрабатывается и выполняется пачка предыдущих. Нормальный midrange-массив имеет глубину очереди 2048 и более. Если массив получает в очередь команд IO больше значения Target Port Queue Depth, то он назад выдает команду QFULL, которая означает, что очередь заполнена и хост-серверу нужно с этим что-то делать. VMware ESX / ESXi реагирует на это следующим образом - он уменьшает очередь на LUN и периодически (каждые 2 секунды) проверяет, не исчезло ли QFULL, и если исчезло, то начинает постепенно увеличивать глубину очереди для этого LUN (это может занять до одной минуты). Это и есть причины тормозов, которые часто возникают у пользователей VMware ESX / ESXi.
Как управлять очередью и адаптивный алгоритм VMware
Теперь становится понятным, почему мы сразу не выставляем параметр Disk.SchedNumReqOutstanding на хостах VMware ESX / ESXi в максимальное значение - мы можем вызвать QFULL на SP массива. С другой стороны, уменьшать его тоже нехорошо - мы ограничим количество операций IO с хоста на LUN.
Поэтому здесь нужен гибкий подход и он есть у VMware (adaptive queue depth algorithm). Работает он таким образом: мы его активируем с помощью параметров Disk.QFullSampleSize и Disk.QFullThreshold в Advanced Settings. Они влияют вот на что:
QFullSampleSize - если число число ответов QFULL (оно же BUSY) превысит его, то ESX / ESXi наполовину обрежет глубину очереди (LUN queue depth)
QFullThreshold - если число ответов о том, что QFULL или BUSY больше нет, превысит его, то ESX / ESXi будет постепенно увеличивать LUN queue depth на 1 (вроде бы, каждые 2 секунды).
Но сколько бы не уменьшалось DQLEN - ниже заданного нами значения DSNRO оно не упадет. Это защищает нас от неожиданного провала в производительности. Кстати, эти параметры тоже глобальные - так что если один (например, тормозящий) массив с хоста будет подвергаться такому адаптивному эффекту со стороны ESX / ESXi, то и для другого (например, производительного) тоже будут выполняться такие фокусы.
Теперь, что дополнительно можно почитать на эту тему:
То есть мораль всей басни такова - дефолтные зачения DSNRO и Queue Depth подходят для большинства случаев. Но иногда имеет смысл изменить их. Но в этом случае надо учитывать параметры системы хранения данных, структуру SAN, количество LUN и другие параметры, влияющие на производительность ввода-вывода.
Как вы знаете, есть такой хороший продукт vGate 2, который производится нашим спонсором - компанией "Код Безопасности" (об основных его возможностях можно почитать в нашей статье). Нужен он для двух важных с точки зрения информационной безопасности вещей: защиты компонентов VMware vSphere от несанкционированного доступа (НСД) и автоматической настройки среды VMware vSphere (хосты ESX и виртуальные машины) в соответствии со стандартами и регламентами по обеспечению безопасности виртуальных инфраструктур (это экономит деньги, которые вы должны были бы потратить на консультантов, обучение своих специалистов и ручную настройку виртуальной среды).
Кстати, важная новость. Вышел vGate 2 с полной поддержкой VMware ESXi 4.1 (об этом мы писали тут, но продукт был еще в бете). Скачать vGate 2 для VMware ESXi можно тут.
Но сегодня мы поговорим о том, как было бы неплохо организовать безопасную инфраструктуру доступа системных администраторов VMware vSphere к различным компонентам среды виртуализации. Это нужно для того, чтобы понимать как правильно наладить контроль за серверами ESX / ESXi и виртуальными машинами со стороны vGate, а также разграничить доступ к этим объектам в рамках зон ответственности администраторов vSphere.
Логичной выглядит следующая схема построения локальной сети в контексте доступа к компонентам виртуальной инфраструктуры:
Немного опишем ее:
Выделяем на уровне домена безопасности отдельно сеть администрирования инфраструктуры vSphere. Она содержит серверы ESX / ESXi, сервер vCenter, а также сервер авторизации vGate. Сам сервер авторизации имеет два сетевых адаптера - одним он смотрит в сети администрирования vSphere, а другим во внешнюю сеть предприятия, где находятся рабочие станции администраторов. Таким образом из последней сети в сеть управления можно попасть исключительно через сервер авторизации vGate (компоненты vGate выделены зеленым). На рабочих местах администраторов vSphere и администратора ИБ также установлены клиентские компоненты vGate.
В отдельную подсеть нужно выделить сеть репликации ВМ (та, что для vMotion и Fault Tolerance).
В отдельную подсеть выделяем сеть для IP-хранилищ (NFS/iSCSI).
Ну и, само собой, сеть виртуальных машин тоже должна быть отдельной. Разделение сетей на хостах ESX / ESXi лучше делать на базе тегирования на уровне виртуального коммутатора (см. виды тэгирования).
Если взглянуть на разделение сетей со стороны сетевых адаптеров хост-сервера ESX сервера авторизации vGate, мы получим такую картину:
После конфигурирования локальной сети обязательно следует настроить маршрутизацию между подсетями, а также убедиться в наличии доступа с рабочих мест администраторов vSphere к элементам управления виртуальной инфраструктурой (vCenter и хост-серверы).
Вот основные варианты настройки маршрутизации (АВИ - это администратор виртуальной инфраструктуры):
Как вы знаете, скоро должен состояться VMworld 2011, где, скорее всего, будет объявлено о выходе VMware vSphere 5, серверной платформы виртуализации. Возможно, параллельно с этим компания VMware выпустит и новую версию продукта для виртуализации настольных ПК предприятия VMware View 5.
На сегодняшний день уже известны некоторые подробности о новых возможностях VMware View 5:
VMware View 5 будет включать в себя улучшенную версию протокола PCoIP (напомним, что во View 4.6 уже появились некоторые улучшения). На данный момент производительность протокола PCoIP существенно уступает аналогичному Citrix HDX/ICA, на базе которого построено конкурирующее решение Citrix XenDesktop. Улучшения PCoIP в VMware View 5 должны позволить VMware немного приблизиться к позициям Citrix в сфере виртуализации настольных ПК.
VMware View 5 будет иметь некий аналог технологии Citrix IntelliCache, которая появилась в платформе Citrix XenServer 5.6 SP2 (со стороны брокера соединений у Citrix его поддержка включена в XenDesktop 5 SP1). У Citrix эта технология позволяет снижать стоимость обслуживания инфраструктуры виртуальных ПК и повышать их производительность за счет использования комбинации общего и локального хранилища (с кэшированием) для виртуальных машин. VMware View 5 также получит что-то подобное.
Наконец-то VMware View 5 получит возможности Virtual Profiles - профили пользователей виртуальных ПК на базе программного продукта от компании RPO Software, приобретенного VMware. Эта возможность позволяет "отвязать" профиль пользователя от операционной системы Windows и повысить портируемость пользовательских окружений (ранее планировалось, что эти возможности войдут в состав View 4.5 или 4.6). Однако сообщается, что эта функция, скорее всего, будет включена несколько позже (но в этом году), и ее возможности будут весьма сильно урезаны по сравнению с тем, что планировалось сделать вначале.
Также о предложениях пользователей по функционалу VMware View 5 можно почитать вот в этой ветке на VMware Communities.
Мы уже писали о веб-клиенте для VMware View от компании Ericom, который построен на базе HTML5. Теперь вот вышла версия Ericom AccessNow for VMware View 1.0. Примечательной особенностью данного ПО является то, что оно позволяет получить доступ к виртуальному ПК предприятия, где развернута инфраструктура VMware View, через любой HTML5-браузер, без необходимости установки каких-либо дополнительных компонентов. Можно также будет использовать и Chromebooks ("Хромбуки" - устройства с Google Chrome OS).
То есть рабочий стол виртуального ПК можно открывать прямо во вкладке Chrome:
Основные возможности Ericom AccessNow for VMware View 1.0:
Не требует Java, Flash, Silverlight или других компонентов.
Поддерживает процессоры Intel x86, ARM и другие.
Может действовать как Gateway, предоставляя доступ к компьютерам в сети предприятия за счет публикации только одного IP.
Передача данных по SSL.
Используются техники WebSockets, AJAX, JSON и другие из HTML5.
Веб-клиент соединяется с сервером Ericom, используя Ajax и WebSockets (когда это возможно) через SSL и пробрасывает клавиатуру и мышь.
С точки зрения протокола доступа, этот клиент от Ericom использует собственный Ericom HTML Display Protocol (HDP), который несколько отличается от RDP и PCoIP (первый работает поверх WebSockets, а от последнего пришлось отказаться в силу его закрытости и невозможности реализации через HTML5).
Скачать пробную версию Ericom AccessNow for VMware View 1.0 можно по этой ссылке.
А сегодня мы расскажем вам еще об одной бесплатной утилите StarWind под названием RAM Disk Emulator (Virtual RAM Drive). Это средство для создания RAM-дисков, то есть виртуальных дисков, выглядящих как локальные в системе, но созданные на основе участка оперативной памяти. Само собой, такие диски на порядок быстрее обычных.
Так как при выключении компьютера такие диски пропадают, то их удобно использовать, например, при работе с расшифрованными копиями зашифрованных файлов (после выключения диск очистится).
RAM Disk Emulator прост в использовании. Устанавливаете, создаете новый диск с заданным объемом (максимум 1024 МБ для одного диска, дисков может быть несколько) и все. Можно поставить настройки форматирования RAM-диска и параметры его монтирования в ОС.
И напоследок. Костян, мой добрый товарищ из StarWind, завел блог о технических вопросах, касающихся StarWind Enterprise. Заходим: http://constantinv.posterous.com.
Компания VMC, золотой партнер компании Veeam Software, ведущего поставщика решений для управления инфраструктурой VMware vSphere, объявляет о запуске промо-программы, которая позволит пользователям Veeam Backup and Replication осуществить обновление своего продукта до издания Enterprise по минимальной цене - со скидкой 40%.
40% скидка от прайс-листа на обновление продукта Veeam Backup & Replication Standard до версии Enterprise (различия изданий)
40% скидка от прайс-листа на обновление продукта Veeam Backup & Replication Standard до пакета продуктов Veeam Management Suite Plus (включает Veeam Backup Enterprise, а также Veeam Reporter и Veeam Monitor)
Внимание: акция действует только для клиентов Veeam, которые приобрели продукт до 1 марта 2011 года.
При внесении различных параметров в конфигурационные файлы виртуальной машины на VMware ESX могут возникнуть различные ошибки. При этом виртуальная машина может до некоторого времени работать корректно.
Есть способ проверить vmx-файл на предмет наличия в нем ошибок (опечаток, например, в путях к рабочим директориям и т.п.). Для этого есть команда:
/usr/bin/vmware-configcheck <путь к vmx-файлу>
Она проверяет его на соответствие правилам оформления, приведенным в файле /etc/vmware/configrules.
В случае успешной проверки результат будет таким:
А в случае неуспешной - будет выведен результат FAIL и описание ошибки конфигурации.
В первой части статьи о файлах журнала VMware ESX (логах) мы описали их размещение и назначение. Но поскольку готовящаяся к выходу платформа VMware vSphere 5 будет построена только на базе платформы VMware ESXi (см. нашу серию статей), то сегодня мы поговорим о том, где находятся логи ESXi и как их можно посмотреть.
Если открыть консоль ESXi через консоль Tech Support Mode или по SSH мы можем увидеть следующую структуру основных логов:
/var/log/vmware/hostd.log – это лог службы хоста VMware ESXi (host daemon - служба, управляющая хостом)
/var/log/vmware/vpx/vpxa.log – лог агента vCenter (который управляет через агент хоста). Этого лога не будет если ESXi работает не под управлением vCenter.
/var/log/messages – Syslog Log (это комбинация логов vmkernel и hostd)
/var/log/sysboot.log - System boot log (лог загрузчика хоста)
/var/log/vmware/aam/vmware_<hostname>-xxx.log - Automatic Availability Manager (AAM) logs (лог агента VMware HA). Этого лога не будет если ESXi работает не под управлением vCenter.
NB: Обратите внимание, что при установке VMware ESXi по умолчанию логи хранятся в разделе Scratch Partition, который находится в памяти в виде RAM-диска. После перезагрузки хоста - они будут удалены, если вы не настроили этот раздел для хранения, в том числе, логов.
Теперь как эти логи на ESXi можно посмотреть. Есть аж 5 способов.
1. Через DCUI (Direct Console User Interface).
В главном меню System Customization, куда вы попадаете по кнопке F2 на самом сервере, выберите пункт "View System Logs":
Также в DCUI можно по комбинации клавиш Alt+F12 увидеть лог vmkernel.
Также вы можете зайти в консоль и перейти в папку с логами (/var/logs):
2. Через веб-браузер.
Просто наберите в адресной строке https://<esxi ip address>/host, после чего введите имя пользователя и пароль root.
3. Использование Syslog-сервера для VMware ESXi.
Вы можете настроить Syslog-сервер для ваших хостов ESXi в целях организации удаленного логирования. Для этих целей вполне можно использовать бесплатный продукт vSphere Management Assistant (vMA). Подробно это описано тут:
Кстати, по умолчанию сообщения логов vpxa и hostd (/var/log/vmware/vpx/vpxa.log и /var/log/vmware/hostd.log) дублируются в /var/log/messages. Если вы хотите это отключить (чтобы там было меньше флуда), используйте вот эту заметку.
Оказывается, на сайте Microsoft есть калькулятор для сравнения цен на приобретение решений VMware vSphere и Microsoft Hyper-V (с другими компонентами System Center). Там есть три сценария внедрения виртуализации в организации: базовая консолидация, виртуализация для среднего и малого бизнеса (СМБ), а также виртуализация для Enterprise-сектора.
Если мы выберем виртуализацию для СМБ, то увидим такую картинку:
Красненьким выделено то, насколько по расчетам Microsoft дороже обходится решение от компании VMware. Интересная штука: Microsoft до сих пор не знает, что в VMware Essentials Plus горячая миграция vMotion входит (в этом можно убедиться тут). Во-вторых, цена на vSphere Essentials Plus указана неправильно, сейчас он стоит $3 844,50 (в калькуляторе же $3 495,00). Из чего мы делаем вывод, что Microsoft просто пофигу на свой калькулятор.
Кстати, раз уж мы порекламировали Microsoft, приведем ссылку на еще один калькулятор - уже от VMware, где, наоборот, приложение от Microsoft вызывает большие затраты (тоже туфтовый калькулятор):
Продолжаем вас знакомить с решением vGate 2 от компании Security Code, которая является нашим спонсором (вот тут описано решение, а вот тут - специальный раздел о продукте). Вкратце: vGate 2 позволяет защиту объектов VMware vSphere от несанкционированного доступа, а самое главное - позволяет автоматически настроить среду VMware vSphere (хосты ESX и виртуальные машины) в соответствии со стандартами и регламентами по обеспечению безопасности виртуальных инфраструктур (это экономит деньги). Кстати, недавно вышла версия vGate 2.3 с поддержкой VMware ESXi.
Сегодня мы поговорим о мониторинге и аудите событий информационной безопасности, происходящих в виртуальной инфраструктуре VMware vSphere. Надо сказать, что для тех компаний, которые заботятся о безопасности своих виртуальных серверов, анализировать стандартные логи, которые дает ESX и vCenter весьма муторно:
На хостах ESX структура логов (откуда мы и можем выделить события ИБ) такова:
/var/log/messages – Syslog Log (это комбинация логов vmkernel и hostd)
Вручную разгребать и анализировать всю эту пачку весьма трудозатратно, поэтому vGate 2 дает вам возможность сделать это удобно из центральной консоли в едином Журнале событий. Но vGate 2 - это не обработчик логов на хостах VMware ESX / ESXi. За счет собственных агентов на хост-серверах он сам регистрирует все события, относящие к информационной безопасности инфраструктуры виртуализации. Это именно те события, аудит которых позволяет своевременно обнаружить и пресечь попытки несанкционированного доступа.
События безопасности регистрируются на всех серверах ESX, на которых установлены компоненты защиты vGate (агенты), а затем пересылаются на сервер авторизации для централизованного хранения. Регистрируются как события несанкционированного доступа к объектам vSphere, так и правомочные события.
Если открыть одно события из списка, мы увидим нечто подобное (доступно полное детальное описание - кто сделал, что, когда и с какого хоста):
События имеют следующие характеристики:
vGate 2 отслеживает те события, которые могут тем или иным образом повлиять на безопасность виртуальной инфраструктуры. Как примеры таких событий можно привести следующее:
Также, помимо основных событий, vGate 2 регистрирует еще и события, связанные с нарушением контроля целостности (КЦ) в различных компонентах виртуальной инфраструктуры:
На серверах ESX (папка /opt/vgate)
На сервере авторизации (каталог установки vGate)
На рабочей станции администратора VMware vSphere
На рабочей станции администратора безопасности инфраструктуры vSphere
Кстати, на компьютерах внешнего периметра сети администрирования (то есть рабочих станциях с vSphere Client), на которых установлен агент аутентификации, сообщения хранятся локально в журнале при
ложений Windows (Application Event Log). Для их просмотра (локально или удаленно) можно использовать Windows Event Viewer.
В этом документе вы найдете полное описание событий ИБ на хостах VMware ESX / ESXi, которые регистрирует vGate 2.
В заключение скажем, что vGate 2 имеет возможность интеграции с SIEM-системами, если таковые имеются на вашем предприятии. vGate позволяет настроить ведение журнала событий и поддерживает протокол SNMP, что позволит при необходимости перенаправить события из журнала событий vGate на удаленный сервер.
На сайте VMware Communities появилась в открытом доступе для всех желающих бета-версия продукта VMware Converter Standalone 5.0, предназначенного для миграции физических серверов в среду VMware vSphere, перевода виртуальных машин на эту платформу с решений других производителей (Hyper-V), а также для миграции между платформами VMware (Workstation, Server, Fusion). Слово Standalone в названии продукта означает, что он не интегрирован с консолью vSphere Client при подключении к vCenter и имеет свой собственный интерфейс управления. Напомним, что продукт абсолютно бесплатен.
Напомним также, что последняя мажорная версия VMware Converter вышла аж в 2009 году (см. нашу заметку тут, а также про версию 4.3 - тут). Поэтому данное обновление - весьма долгожданное.
Новые возможности VMware Converter 5.0:
Сохранение LVM-конфигурации томов исходной Linux-машины при ее миграции.
Улучшенный механизм синхронизации, включая запланированный запуск задачи, а также выполнение нескольких задач синхронизации в одной задаче миграции.
Оптимизация выравнивания дисков и разделов + возможность изменения размера кластера ФС.
Передаваемые данные при миграции между исходным сервером и сервером назначения - шифруются.
Поддержка миграции Red Hat Enterprise Linux 6.x (32-bit and 64-bit). Прекращена поддержка Ubuntu 5.x-7.x.
Скачать бету VMware Converter Standalone 5.0 можно по этой ссылке. Документация доступна тут.
Суть диалога блоггеров такова: Брайан рассматривает позицию VMware о собирании денег с пользователей на базе лицензирования виртуальных машин весьма скептически. Это, во-первых, весьма неудобно (сложно понять, какие машины надо лицензировать, сколько их вообще и т.п.), а, во-вторых, это становится более накладно + не толкает пользователей на оптимизацию датацентра в части увеличения коэффициента консолидации (а, как следствие, и уменьшения количества оборудования).
Так вот, Скотт ему отвечает, что переход на лицензирование по ВМ - вполне логичен. Ибо производительность процессоров на серверах растет как на дрожжах (напомним, что VMware vSphere лицензируется в настоящее время по количеству физических процессоров).
То есть, в данный момент у VMware как бы наблюдается недополученная прибыль, поскольку цена на продукты почти не меняется (хотя мы знаем, что это не так), а мощности серверных платформ растут. А недополученную прибыль как-то надо возвращать, в том числе за счет введения новых программ лицензирования.
Интересно, кстати, будут ли новые версии vSphere проходить по таким программам? Если да, то это приведет к такой путанице, что даже не все сотрудники VMware будут в курсе, как именно лицензируется продукт при определенных условиях (сейчас это иногда бывает и с Microsoft). Будут даже мудрые консультанты по лицензированию VMware.
Но расстраивает тут два момента - первый, что компания вводит все эти вещи в одностороннем порядке, без обсуждения среди пользователей и без объяснения причин, а второй - реально, товарищи, вмваре дорогая, очень дорогая. И безо всяких там изменений. А видно, что изменения эти будут только в сторону удорожания.
Как оказалось, на нашем сайте нет хорошего руководства по назначению и использованию RDM-дисков (Raw Device Mapping) с платформой VMware vSphere. Постараемся заполнить этот пробел.
Давайте начнем с того, что для виртуальных машин на серверах VMware ESX есть всего 3 типа дисков с точки зрения виртуализации подсистемы хранения:
VMDK-диски
Это самые часто используемые диски VMware vSphere. Они создаются на хранилищах VMFS или NFS и позволяют использовать все возможности работы VMware с виртуальными машинами в части распределенных служб. К ним относятся распределенная блокировка файлов (distributed file locking), снапшоты дисков, vMotion - и много чего еще. О типах виртуальных дисков у нас есть отдельная статья. Обычные vmdk-диски - это самый высокий уровень виртуализации, т.е. все SCSI-команды виртуальной машины при обращении к нему проходят через компонент VMkernel, который уже процессит их внутрь файла vmdk. За пределы этого файла виртуальная машина ничего не видит. То есть виртуальной машине дается кусочек тома VMFS или NFS в виде файла vmdk, операции по работе с которым полностью контролируются гипервизором - это и есть максимальная виртуализация устройства. Из этого, кстати, следует, что поскольку есть слой виртуализации, в определенных условиях такие диски могут работать медленнее RDM-дисков, но есть также и условия при которых такие диски могут работать быстрее. Более подробно об этом можно прочитать здесь. На этих дисках в статье мы останавливаться не будем.
RDM-диски в режиме виртуальной совместимости (virtual RDM).
Это промежуточный тип диска с точки зрения виртуализации хранения. В случае создания такого диска на хранилище VMFS (NFS - не поддерживается) создается mapping-файл (он тоже с расширением *-rdmp.vmdk), через который происходит маппирование виртуальной машине физического дискового устройства LUN. Устройство это маппируется особым образом - основные служебные операции по работе с ним (например, команда Open и другие служебные SCSI-команды) проходят через через слой виртуализации в гипервизоре, а команды по работе с данными (Read и Write) процессятся напрямую к устройству, минуя слой виртуализации.
Что означает, что передаются напрямую только команды Read / Write в виртуальный RDM? Это означает, что устройство представляется виртуальной машине как обычный SCSI-диск, с которым нельзя работать иначе как с устройством хранения (как можно иначе - дальше). Зато сохраняется большинство возможностей VMware vSphere по функциональности - например, снапшоты. Ниже мы также посмотрим, где можно использовать такой тип дисков.
RDM-диски в режиме физической совместимости (Physical RDM). Это наименее виртуализованный тип дисков. Для таких дисков хост-сервер ESX также создает mapping-файл, но вот iSCSI-команды процессятся к устройству LUN напрямую, минуя слой виртуализации хранилища в гипервизоре (за исключением одной команды LUN Report).
Что дает такой механизм доступа к устройству? Он позволяет использовать iSCSI-устройство не просто как диск, но и передавать к нему различные iSCSI-команды, которые предоставлют больше возможностей по работе с устройством (например, управление SAN-устройствами изнутри виртуальной машины или снятие снапшота на уровне хранилища). Ниже мы тоже рассмотрим подобные примеры.
Общее у всех этих продуктов - то, что они лицензируются не на базе процессоров (как vSphere), а на базе виртуальных машин. Эта особенность, с одной стороны, как бы ближе к облачной концепции - типа нам не важно где и как работают виртуальные машины, а важно сколько сервисов мы используем, соответственно, за них и платим.
Но с другой стороны, с этим возникают специфические проблемы, на которые обратили внимание в блоге компании VKernel. Суть проблем такова:
Когда организация использует модель лицензирования по физическим процессорам, ее основная цель - достичь максимальной консолидации виртуальных машин на хосте, поскольку она платит за инфраструктурные составляющие (стойки, питание, охлаждение, площади), а также за весьма недешевые лицензии на продукты для виртуализации. А вот когда лицензируются виртуальные машины - увеличение коэффициента консолидации не сказывается на стоимости лицензий, а значит нет и соответствующей мотивации у администраторов и менеджеров датацентра.
Когда используется лицензирование по числу виртуальных машин - это очень сложно учитывать. Виртуальные машины постоянно создаются, удаляются, развертываются в тестовых целях и забываются. Учитывать число лицензий в таких окружениях очень сложно и затратно.
Также автор обратил внимание на проблему, изложенную на одной из веток комьюнити, где у человека возникли проблемы с применением продукта CapacityIQ - он пытался строить отчеты о емкостях инфраструктуры не для всех виртуальных машин (поскольку некоторые не должны влиять на ее будущее состояние). Но оказалось в продукте нет такой возможности - он собирает информацию со всего окружения vCenter и нам рекомендуют лицензировать виртуальных машин столько, сколько нам реально нужно в анализе. Однако это очень неформализованное правило, которое нельзя отразить в EULA.
То есть, в данном случае совсем непонятно, какие виртуальные машины нам надо лицензировать (если она работает раз в году - надо?). Подобные проблемы в будущем будут возникать и в других продуктах (просто вышеозначенные - пока весьма не распространены). А это плохо, вот.
Компания VMware сделала очередной документ по сравнению своей платформы виртуализации VMware vSphere 4.1 с ближайшими конкурентами Microsoft Hyper-V R2 SP1 и Citrix XenServer 5.6 FP2 (то есть, с самыми последними релизными версиями вышеозначенных продуктов на сегодняшний день).
Мы представляем его адаптированную версию (кликабельно):
Надо сказать, что при всей необъективности подобных сравнений, они все же несут некоторую пользу. С помощью таких табличек удобно устраивать дискуссию со сторонниками и противниками тех или иных продуктов и технологий виртуализации. Они позволяют держать ключевые пункты в голове и на столе.
Кстати, обратите внимание, что появились новые пункты про облачные вычисления и IaaS. С Citrix OpenCloud, про который мы недавно писали, еще ничего не ясно.
Как вы знаете, мы сотрудничаем с компанией "Код Безопасности", которая, в частности, занимается выпуском продукта vGate 2, который автоматизирует настройку виртуальной среды в соответствии с регламентами предприятия, а также руководящими документами и стандартами в этой сфере (см. тут). Кроме того, он позволяет организовать инфраструктуру полномочного доступа к компонента виртуальной инфраструктуры VMware vSphere и защитить ее от несанкционированного доступа (см. тут).
Недавно стала доступна для скачивания бета-версия продукта vGate 2.3, который полностью поддерживает платформу VMware ESXi 4.1. А это очень важно, поскольку vSphere 5 будет построена только на базе ESXi, а ESX уйдет в прошлое (см. нашу серию статей тут). Само собой, к выходу vSphere 5 продукт vGate будет готов обеспечивать безопасность этой платформы.
Итак, прежде всего, ссылка на скачивание vGate 2.3 с поддержкой ESXi: http://www.securitycode.ru/products/demo/. В поле "Выберите продукт" выбираем "Бета-версия vGate 2 (с поддержкой ESXi)".
Для поддержки ESXi была проделана большая работа - представьте сколько всего нужно было переделать, чтобы доработать агента для хост-серверов и договориться с VMware о его сертификации для ESXi. Под "все" подразумевается настройка конфигурации хост-серверов ESXi для соответствия политикам безопасности VMware Security Hardening и другим.
Важно! Для серверов виртуализации VMware ESXi пока поддерживаются только следующие политики:
Запрет клонирования виртуальных машин;
Запрет создания снимков виртуальных машин;
Список запрещенных устройств;
Доверенная загрузка виртуальных машин;
Запрет подключения USB-носителей к ESX-серверу;
Очистка памяти виртуальных машин;
Запрет доступа к консоли виртуальной машины;
Запрет доступа к файлам виртуальных машин;
Затирание остаточных данных на СХД при удалении ВМ;
Запрет смешивания разных типов сетевого трафика.
Кстати, если у вас есть инфраструктура VMware View 4.5 - то vGate 2.3 ее поддерживает (в документации описано, что нужно сделать).
В продукте появилось еще несколько интересных возможностей:
Поддержка стандартного Distributed vSwitch (dvSwitch)
Новые политики безопасности:
Запрет Download файлов ВМ с привязкой к меткам
Запрет трафика vMotion (FT) и трафика vSphere Client
Затирание остаточных данных на СХД при удалении ВМ
Запрет доступа к консоли ВМ с привязкой к меткам
Соответствие стандарту PCI-DSS
Обновлен установщик продукта, улучшено управление генерацией событий
Сервер авторизации полностью поддерживается в ВМ
Шаблоны настроек политик АС по ФСТЭК, ИСПДн по ФСТЭК, ИСПДн по СТО БР ИББС
На прошедшей конференции Citrix Synergy было сделано несколько важных заявлений (тут, тут, тут и тут). Одно из них - Citrix Project Olympus, представляющий собой платформу для IaaS (Infrastructure as a Service) облаков, т.е. для компаний, которые планируют создавать у себя облачную инфраструктуру для предоставления виртуальных машин своим пользователям на основе публичной аренды (public cloud) или для внутренних нужд (internal cloud).
Напомним, что у VMware для этих нужд есть продукт vCloud Director (внутренние облака) и vCloud Express (публичные облака провайдеров).
Что же это за штука такая Citrix Project Olympus? Во-первых, это IaaS-платформа, основанная на открытой архитектуре OpenStack (это, кстати, совместный проект хостинг-провайдера RackSpace и NASA). Проект OpenStack - это открытый продукт, сообщество которого поддерживается экосистемой из более чем 60 партнеров, среди которых Citrix, Dell, Cisco, Canonical, Intel и AMD.
На базе OpenStack компания Citrix и будет предлагать свое IaaS-решение, которое будет включать в себя оптимизированный для облаков гипервизор Citrix XenServer, а также инфраструктурные компоненты NetScaler Cloud Gateway (виртуальный или физический модуль входа пользователей в ЦОД со своих клиентских устройств, обеспечивающий авторизацию для виртуальных машин и приложений) и NetScaler Cloud Bridge (штука для связи внутреннего ЦОД с публичным облаком на базе Olympus).
При этом решение от Citrix (как и XenDesktop) будет поддерживать работу с различными платформами виртуализации: XenServer, Hyper-V и vSphere.
Сейчас Citrix организует пилотное тестирование своей платформы совместно с Dell и RackSpace (в качестве серверной платформы используется Dell PowerEdge, а на базе Rackspace будет организовано развертывание, обучение и техподдержка). Записаться на тестирования для вашей большой компании можно здесь.
Ну и подробнее, если эта фигня вас заинтересовала, читаем в пресс-релизе.
В продолжение темы "Как сбросить пароль root на VMware ESX". У Dave Mishchenko есть отличная инструкция о том, как сбросить пароль пользователя root на хосте VMware ESXi в том случае, если вы его потеряли, забыли или съели. Работает эта инструкция и для VMware ESXi 4.1 (а также 4.0 и даже 3.5). Переведем ее вкратце.
1. Допустим хост VMware ESXi у вас сейчас работает и вы можете выполнять на нем команды локально или по SSH. Тогда имеет смысл выполнить команду:
cat /etc/shadow
Видим картинку с хэшем пароля рута:
Хэш пароля - это то, что написано после root : до следующего двоеточия (само двоеточие не включается). Хэш этот нужно записать на случай, если его понадобится восстановить назад.
2. Дальше нужен какой-нибудь Linux live CD. Предлагается использовать Slax Linux Live CD.
Далее просматриваем смонтированные разделы сервера ESXi командами:
fdisk -l (смотрим подходящие FAT16 разделы, где у нас размещен загрузчик)
ls -l /mnt/sda5/ (основной, при загрузке монтируется как /bootbank)
ls -l /mnt/sda6/ (резервный, при загрузке монтируется как /altbootbank)
В случае чистой установки ESXi, картина будет такова:
Нас интересует файл state.tgz - там все, что нам нужно. Если у вас ESXi Embedded то нужен файл local.tgz (который в первом случае находится внутри state.tgz).
Распаковываем сначала state.tgz, а потом local.tgz командами gzip и tar во временную директорию. Далее заходим в ней в папку /etc и открываем в ней файл shadow командой:
vi shadow
У вас откроется что-то вроде того:
Теперь посмотрите на картинку ниже, мы удаляем хэш пароля из этого файла:
То есть убираем все то, что между двумя двоеточиями. Выходим из файла, сохранившись.
Теперь все это упаковываем назад, для чего во временной папке (туда надо подняться из /etc) выполняем такую команду (апдейтим архив изменившейся папкой):
tar -czvf local.tgz etc
Если вы используете ESXi Embedded - кладете файл local.tgz на место, откуда брали. Если обычный ESXi - снова апдейтим архив:
tar -czvf state.tgz local.tgz
И также копируем туда, где он лежит:
Перезагружаем сервер и уже загружаемся в VMware ESXi. Видим такую картинку:
Это значит - все получилось. Теперь можем заходить в консоль под пользователем root с пустым паролем. Вот такой незамысловатый способ сброса пароля на хосте VMware ESXi.
Вы уже все знаете про продукт StarWind Enterprise iSCSI (но еще не все купили), который позволяет создавать отказоустойчивые хранилища для виртуальных машин VMware vSphere и Microsoft Hyper-V (у нас есть, кстати, специальный раздел о StarWind). Недавно мы писали о том, что вышла бесплатная версия StarWind Free.
А сегодня еще одна приятная новость для задумавшихся о покупке продукта - теперь StarWind Enterprise полностью сертифицирован со стороны VMware в качестве системы хранения по программе VMware Certified Partner. Вы можете обнаружить его в HCL-листе:
Из пресс-релиза:
StarWind iSCSI SAN software has successfully passed all the laboratory tests and has met all the interoperability criteria required by VMware.
This certification assures our customers that StarWind solution is officially compatible with VMware virtualization products and guarantees full VMware technical support for any VMware infrastructure built using StarWind iSCSI SAN.
Так что теперь можете смело показывать руководству, что iSCSI-хранилища StarWind Enterprise - это сертифицированное VMware решение.
Начните хотя бы с бесплатной версии - это не потребует от вас ничего кроме обычного Windows-сервера, который даже может быть виртуальным. Кстати, скоро выйдет версия StarWind Enterprise 5.7, где будет еще больше возможностей.
Те, кто увлекается разработкой сценариев на PowerShell на фреймоврке PowerCLI, наверное помнят про бесплатную раздачу постеров на блоге VMware. Тогда не все успели забрать свой постер.
Сейчас они пишут, что раздача закончена. Но не беда - вы без проблем можете забрать свой постер по PowerCLI по этой ссылке. А вот еще версия для распечатки на листах А4.
На проходящей сейчас конференции Citrix Synergy, было сделано несколько интересных анонсов компанией Citrix. В частности, среди них две важные новости - выпуск технического превью клиентского гипервизора Citrix XenClient 2.0 и выпуск его релизной версии Citrix XenClient XT 1.0 (будет доступна в июне). О том, что такое Citrix XenClient вы можете прочитать в наших заметках тут, тут и тут.
Expanded Hardware Compatibility – поддержка в три раза большего количества ПК и ноутбуков для установки продукта. Кроме того, добавлена поддержка второго поколения процессоров Intel Core vPro. Напомним, что список совместимости с Citrix XenClient (HCL) находится здесь.
Expanded Graphics Support – расширенная поддержка графики Intel HD Graphics на процессорах Intel Core 2nd Generation, а также поддержка дискретных графических технологий от AMD, включая видеоадаптеры FirePro и Radeon.
Новая версия компонента Synchronizer – обновление компонента, отвечающего за синхронизацию виртуальных ПК пользователя с VDI-инфраструктурой датацентра. Теперь возможности синхронизации станут шире, что позволит наиболее быстро синхронизировать ПК, приложения и данные.
Simplified User Experience – за счет комбинации с новой версией Citrix Receiver, XenClient 2 получать большую производительность и качество отображения своих виртуальных ПК.
Скачать Citrix XenClient 2.0 technical preview можно по этой ссылке.
Extreme Desktop Isolation - улучшения в плане безопасности, касающиеся изоляции виртуальных ПК и их сетей на одном клиентском устройстве, что позволяет создавать защищенные окружения (например, для домашней и рабочей виртуальных машин на одном ноутбуке).
Extreme Security - опять-таки, улучшения безопасности, связанные с возможностями платформы Intel Core vPro. Это включает в себя технологию доверенной загрузки на базе Intel Trusted Execution Technology (TXT), где проверяется конфигурация XenClient при каждой загрузке.
Как вы знаете, есть такая компания VKernel, которая занимается производством средств для управления виртуальной инфраструктурой (о ней мы пишем тут). Недавно в продуктовой линейке компании появилось два продукта для платформы Microsoft Hyper-V: VKernel Capacity Analyzer и VKernel Chargeback.
Это средство для анализа инфраструктуры Hyper-V на предмет наличия узких мест в плане производительности, которое также позволяет осуществлять планирование развития инфраструктуры в аппаратной части (то есть, прогнозирование роста необходимых вычислительных мощностей).
А эта штука позволяет вам учитывать затраты на содержание инфраструктуры виртуализации Hyper-V и стоимость выделения новых ресурсов под развертываемые сервисы. Актуально, в основном, для крупных компаний.
Скачать пробные версии этих утилит VKernel можно по этой ссылке.
На конференции Citrix Synergy компания Citrix объявила о приобретении Kaviza (напомним, что в прошлом году Citrix сделала стратегические инвестиции в Kaviza). Это вендор, который выпускает решение VDI-in-a-box. Это такой виртуальный модуль (Virtual Appliance), который позволяет упростить процедуру внедрения VDI в небольших компаниях.
Kaviza VDI-in-a-box не требует брокеров соединений, серверов управления и балансировщиков нагрузки - все умещается в одном виртуальном модуле. Получаем вот такую картинку "до и после":
При этом решение VDI-in-a-box не требует общего хранилища для виртуальных ПК - можно использовать локальные диски серверов. Это и быстрее (локальные диски vs общее хранилище), и не требует дополнительных инвестиций в создание инфраструктуры СХД.
В продукте даже есть некий High Availability Grid Engine, который обеспечивает отказоустойчивость для виртуальных ПК на хост-серверах.
Кстати, ранее в качестве платформы поддерживались VMware vSphere, Citrix XenServer и Microsoft Hyper-V. Теперь же непонятно, оставит ли Citrix поддержку VMware, хотя логичных причин прекращать ее нет.
Также отметим, что Kaviza имеет в своем составе поддержку Linked Clones для виртуальных ПК, а в качестве протокола доступа с клиентских устройств использует RDP либо Citrix HDX.
В целом, VDI-in-a-box - штука весьма интересная и SMB-пользователи должны повнимательнее к ней присмотреться. Тем более, что под крылом Citrix продукт, будем надеяться, станет лучше.
Реселлеры смогут начать поставки VDI-in-a-box по каналам Citrix уже с 1 июля этого года. Скачать пробную версию ПО Kaviza можно по этой ссылке.
RSS
