Среди предложений облачного провайдера ИТ-ГРАД есть услуга по предоставлению облачной инфраструктуры для Java-разработчиков, реализованной на базе продуктов VMware vFabric. Она включает в себя высокопроизводительный сервер приложений, сервис работы с БД SQL, сервис обмена сообщениями, балансировщики нагрузки и сервис хранения файлов.

Также в составе решения предлагается среда поддержки жизненного цикла разработки приложений – IT-GRAD ALMaaS.

Компания ИТ-ГРАД, также имеет в составе своих предложений специализированное решение для команд разработчиков на базе продуктов семейства Team Foundation Server компании Майкрософт и ресурсов собственного публичного облака.

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

• Team Foundation Server – средство учета требований, выдачи заданий на разработку и тестирование, учет ошибок и контроль версий исходных кодов.
• Среда разработчика – выделенный сервер разработчика, с предустановленным пакетом Visual Studio 2010 (любая редакция на выбор) и Test Manager 2010, предназначенный для удаленной работы разработчиков и тестировщиков, дает возможность отказаться от повышенных требований к персональным компьютерам сотрудников, повысить безопасность работы, унифицировать среду разработчика и сократить время на развертывание рабочих сред для новых сотрудников.

Более подробно о предложении PaaS можно узнать на сайте компании ИТ-ГРАД.

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

Эту статью мы пишем, главным образом, здесь для того, чтобы сказать - уже можно. Виртуальные диски Paravirtual SCSI достаточно стабильно работают в VMware vSphere. В KB 1010398 мы видим матрицу поддержки дисков pvscsi для различных релизов VMware vSphere (обычные и boot-диски):

В VMware vSphere/ESXi 5.1 поддерживается все то, что поддерживалось и в предыдущих версиях платформы.

Что же раньше были за баги с PVSCSI? Смотрим, например, в статье тут, отсылающей нас к KB компании Microsoft. Ошибка существовала для ОС Windows Server 2008 R2 и была критической, а устранена была только в VMware vSphere 5.0 Update 1, о чем есть KB 2004578.

Теперь о том, как поставить диск типа PVSCSI в качестве загрузочного для виртуальной машины на ESXi. Выбираем в vSphere Client контроллер типа VMware Paravirtual :

В настройках виртуальной машины добавляем виртуальный floppy-дисковод и указываем образ дискеты с драйвером PVSCSI, который лежит в папке vmimages->floppies (если там ничего нет, идем сюда):

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

Дальше ставим все как обычно. Если хочется запихнуть драйвер PVSCSI в кастомизированную ISO-шку, то вам сюда. И да, драйвер на образе дискеты от Windows Server 2008 прекрасно работает на Windows Server 2012, который, в свою очередь, работает на VMware vSphere 5.1.

Если вы попробуете импортировать виртуальную машину (или Virtual Appliance), которая была создана для настольных платформ виртуализации (например, VMware Workstation в формате 2gbsparse), в VMware vSphere 5.1 с помощью утилиты vmkfstools, то у вас это не выйдет. Вы получите подобное сообщение:

# vmkfstools -i <VM-name.vmdk> <VM-name-new-disk>.vmdk -d zeroedthick

Ошибка может быть и такой:

И такой:

Все это из-за одного и того же - в VMware vSphere 5.1 убрали автоматическую загрузку модуля multiextent, который и отвечает как раз за конверсию виртуальных дисков с hosted-платформ VMware в формат VMFS. Чтобы загрузить этот модуль нужно выполнить простую команду:

# vmkload_mod multiextent

Ну а чтобы выгрузить:

# vmkload_mod -u multiextent

Делать это можно смело, так как этот модуль отвечает только за работу с Non-VMFS дисками ВМ.

Пришел ньюзлеттер от Citrix, в котором содержалось интересное предложение:

Дай, думаю, посмотрю - что за лицензия такая на 0 ГБ, и сколько она стоит. Тыркаю - и правда: 150 баксов за 0 ГБ:

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

Не так давно мы делали обзор сертификаций VMware, где упоминали о сертификации VMware Certified Advanced Professional (VCAP), которая является переходным звеном от стандартной сертификации профессионалов VCP к "звездам" -  VMware Certified Design Expert (VCDX).

Так вот для тех из вас, кто решил встать на нелегкий путь сертификации VCAP (экзамены действительно сложные), вышло руководство VCAP5-DCA Study Guide, основанное на официальном Blueprint и насчитывающее 349 страниц (!). В нем, как это часто бывает, много ботвы, но и по существу есть немало полезного.

Для администраторов VMware vSphere в руководстве также найдется много интересного. Руководство снабжено картинками, командами CLI и, что самое нужное при подготовке к экзамену VCAP, отсылками к конкретным документам VMware (и их главам) по каждой теме. Штука местами очень классная - рекомендую.

Компания StarWind Software, производящая продукт номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN & NAS, приглашает на бесплатный вебинар "Increase Operational Efficiency with StarWind!", который проводит Анатолий Вильчинский, системный инженер StarWind Software.

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

Вебинар состоится в четверг, 24 января в 19-00 по московскому времени. Регистрируйтесь!

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

Теперь, на основе статьи Франка, мы обобщим и актуализуем информацию по миграциям vMotion и Storage vMotion в разных контекстах - на уровне хранилищ, сети и хост-серверов VMware ESX.

Как и в прошлой статье, здесь будем пользоваться понятием стоимости миграции в единицах (cost) и максимального значения костов в тех же единицах (max cost), которое отображает предельно допустимое значение. Сумма костов операций vMotion и SVMotion не должна превышать max cost для соответствующего объекта (datastore, NIC и хост ESXi).

Теперь взглянем на таблички (в них есть не только vMotion, но и SVMotion):

Хост ESXi

Сеть

Хранилище (Datastore)

Читать эти таблички просто - например, для хоста ESXi стоимость миграции vMotion равна 1, а поскольку max cost равно 8, то всего на хост может быть 8 одновременных миграций в конфигурации по умолчанию. Либо допустимы одновременно: 1 миграция SVMotion (4 очка) и 4 штуки vMotion (по одному очку каждая), т.е. суммировать надо по костам: 4+1+1+1+1=8.

Для хранилища (Datastore) также есть ограничения vMotion, поскольку передаются страницы файла подкачки (если он не шаренный между хостами), а также производится передача владения VMX-файлом и другими файлами ВМ на хранилище. Но поскольку влияние это мало, то стоимость vMotion для хранилища всего 1 при максимальной емкости одновременных операций 128 (а вот SVMotion, требующая значительных ресурсов хранилища, "кушает" 16 единиц). Таким образом 1 операция vMotion съест 1 единицу коста, поэтому в этот момент для хранилища будет доступно только 7 миграций SVMotion, т.е. (128-1) div 16 = 7.

Соответственно, редактирование параметра Config Key для соответствующей операции позволяет изменять количество одновременных операций vMotion/SVMotion. Для редактирования параметра Config Key нужно отредактировать конфигурационный файл vpxd.cfg на сервере VMware vCenter, который находится в папке:

%ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\

Там нужно вписать новое значение в соответствующую секцию. Например, для параметра maxCostPerEsx41Ds:

< config >
< vpxd >
< ResourceManager >
< MaxCostPerEsx41DS > new value < /MaxCostPerEsx41DS >
< /ResourceManager >
< /vpxd >
< /config >

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

Теперь самое интересное - это динамический параметр max cost для сетевых адаптеров. Как видно из таблицы, его действующее значение зависит от типа сетевого адаптера на хосте - 1G или 10G. Но, на самом деле, и не только от типа. Точнее - от скорости соединения для трафика vMotion между хостами ESXi, которую обнаруживает VMkernel. Таким образом:

• Если VMkernel обнаруживает соединение на скорости 1Gbit/s - Maximum Cost выставляется в значение 4 (это верно и для случая соединения 1G<->10G).
• Если VMkernel обнаруживает соединение на скорости 10Gbit/s - Maximum Cost выставляется в значение 8.
• Если VMkernel обнаруживает соединение на скорости ниже 1Gbit/s - Maximum Cost выставляется в значение 2.

Таким образом, для адаптера возможны либо 2, либо 4, либо 8 одновременных миграций vMotion, в зависимости от действующей скорости соединения. Операция Storage vMotion, как видно из таблицы, костов сети не кушает.

Если ограничение для сети жестче (например, 4 миграции vMotion), чем ограничение для хоста (8 миграций vMotion) - то для машин этого хоста действует ограничение сети.

Продолжаем рассказывать об услугах сервис-провайдера ИТ-ГРАД - первой в России компании, предоставляющей в аренду виртуальные машины по модели IaaS. В компании понимают, что пользователям виртуальной инфраструктуры инересны комплексные решения, то есть не только размещение своих виртуальных серверов в облаке, но и получение в аренду виртуальных ПК с необходимым набором приложений - Desktop as a Service (DaaS). Особенно это актуально для небольших компаний, которым непросто делать капитальные вложения в инфраструктуру.

По модели DaaS ИТ-ГРАД предлагает в аренду виртуальные рабочие станции (VDI) - полностью готовое к работе («под ключ») стандартизированное виртуальное рабочее место, которое каждый пользователь имеет возможность дополнительно настраивать под свои задачи, т.е. клиент получает доступ не к отдельной программе, а к необходимому для полноценной работы программному комплексу.

Комплексные решения создания виртуальных рабочих мест, предлагаемых ИТ-ГРАД, базируются на решениях VMware View и Citrix XenDesktop.

В услугу включены ресурсы для размещения виртуальных рабочих станций, базовый набор ПО:

• ОС Windows,
• MS Office,
• антивирусное ПО,
• архиватор.

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

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

Мы уже писали о калькуляторе VMware View VDI Flash Calculator, который недавно обновился до версии 2.9. На сегодняшний день это калькулятор номер 1 для расчета параметров инфраструктуры виртуальных ПК на базе VMware View (с поддержкой vSphere 5.1 и View 5.1).

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

А вот что нового появилось в VMware View VDI Flash Calculator 2.9:

• Увеличено число допустимых ВМ на процессор/ядро сервера до 20
• Добавлена поддержка экономии операций ввода-вывода с дисковой подсистемой за счет механизма Content Based Read Cache (CBRC Base % IOP). Предполагается экономия на уровне 65% (можно регулировать)
• Полная поддержка VMware vSphere / vCenter 5.1
• Добавлен фреймворк для поддержки еще нереализованной функциональности VMware View
• Добавлена валидация в соответствии с VMware compatibility matrix
• Пофикшены баги отображения

Есть также обучающее видео по работе с калькулятором:

VMware View VDI Flash Calculator 2.9 доступен по этой ссылке. Напомним также, что у этого же автора есть XenDesktop VDI Calculator.

Мы уже писали о проекте Project Virtual Reality Check (VRC), который продвигают несколько человек из компаний Login Consultants и PQR. В своих работах по тестированию производительности различных решений ребята используют решение Virtual Session Indexer (VSI), которое они сами же и написали.

В рамках Phase V (они величают свои изыскания "фазами") был опубликован 80-страничный документ "Antivirus impact and best practices on VDI", в котором они сравнивают производительность различных антивирусных решений в инфраструктуре VDI (традиционно рассматривалась платформа VMware View / vSphere).

КДПВ из какого-то исследования (есть в документе):

Поэтому детально сравниваются только 3 антивируса для VDI:

• Microsoft
  Forefront Endpoint Protection 2010 (Now System Center Endpoint Protection 2012)
• McAfee
  - Enterprise 8.8.0
  - MOVE Multiplatform AV 2.x
  - MOVE Agentless AV 2.5
• Symantec
  - Endpoint Protection 12.1

Странно, что обошли стороной компанию Trend Micro с ее весьма популярным, заточенным специально под виртуализацию, решением Deep Security. Ну а нам было бы интересно посмотреть, как ведет себя Касперский в среде VDI. Но чего нет, того нет.

Конечно же, в документе рассмотрены и варианты развертывания, когда антивирусный агент работает за пределами виртуальных машин (за счет механизма VMsafe и EPSEC API):

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

В прошлой статье про средство резервного копирования и восстановления StarWind Hyper-V Backup Plug-in (опция к StarWind Native SAN for Hyper-V) мы обещали рассказать про такие режимы восстановления как:

• Restore in Sandbox - возможность восстановить ВМ без ее влияния на продуктивную работающую копию (восстановление происходит в изолированное виртуальное окружение)
• Restore from archive - возможность восстановить ВМ напрямую из архива (в случае крайней необходимости)

Restore in Sandbox

Этот режим нужен тогда, когда требуется восстановить ВМ в изолированное окружение и что-нибудь проверить, например, что все данные внутри остались целостными и приложения работают (т.е. архив пригоден для восстановления). Для этого нужно выбрать пункт "Restore in Sandbox" для резервной копии:

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

Вот так это выглядит в консоли Hyper-V Manager:

Restore from archive

Этот режим можно использовать только в экстренных случаях, когда виртуальная машина должна быть восстановлена безотлагательно. Для этого нужно выбрать пункт "Launch VM from Archive" из контекстного меню хранимой резервной копии.

После этого будет выдано предупреждение:

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

Поэтому, если есть возможность, следует использовать варианты восстановления "Restore Original VM" или "Restore in Sandbox"

Напомним также, что у StarWind есть плагин для резервного копирования виртуальных машин и на платформе VMware vSphere - VMware Backup Plug-in.

Начиная с версии VMware vSphere 4.0, компания VMware сделала замечательную вещь - все выпускаемые ей в комплекте с платформой виртуализации пакеты VMware Tools обратно совместимы со всеми прошлыми версиями хостов VMware ESXi:

Соответственно, на VMware ESX 4.0 можно использовать VMware Tools от vSphere 5.1, но как сделать это, не обновляя платформу виртуализации? Оказывается есть простой метод, опубликованный на v-front.de и основанный на информации из KB 2004018.

Итак:

1. Скачиваем последние бандлы ESXi c VMware Patch download portal, например, ESXi510-201212001.zip. Открываем архив и переходим в категорию vib20\tools-light:

Там будет один или два файла с расширением .vib. Если их два, то тот, что с меньшим номером билда - это тулзы, содержащие только обновления безопасности, а тот, что с большим - включает и эти обновления, и багофиксы. Берем тот, что с большим номером (609), кликаем на нем 2 раза и проваливаемся дальше в архив, где виден репозиторий VMware Tools:

Эти три папки вы уже когда-то видели на Datastore в ESXi (во время установки тулзов). Создаем папку с именем vmware-tools на локальном хранилище ESX / ESXi и заливаем туда три извлеченные из vib'а папки, чтобы получилось вот так:

Теперь нужно настроить хост ESXi для использования данного репозитория VMware Tools. Для этого идем в Advanced Settings хоста ESXi и настраиваем параметр UserVars.ProductLockerLocation, где прописана версия тулзов в формате:

/locker/packages/<ESXi-Version> (ESXi-Version = 5.1.0, 5.0.0, 4.1.0 or 4.0.0)

В нашем случае она выглядит так:

/locker/packages/5.1.0

Меняем ее на путь к репозиторию: /vmfs/volumes/<имя Datastore>/vmware-tools.

После этого нужно перезагрузить хост, и изменения вступят в силу. Если перезагружать ESXi не хочется, то можно в корне файловой системы пересоздать символьную ссылку /productLocker:

rm /productLocker
ln -s /vmfs/volumes/<имя Datastore>/vmware-tools /productLocker

Можно также вызвать команды, которые вызываются хостом для пересоздания символьных ссылок:

•  /sbin/configLocker - для ESX / ESXi 4.x
• jumpstart --plugin=libconfigure-locker.so - для ESXi 5.x

Теперь остается только выбрать пункт Install/Upgrade VMware Tools в консоли vSphere Client при подключении к консоли ВМ для обновления компонентов пакета.

Многим интересующимся технологиями виртуализации известна компания Stratus Technologies, занимающаяся вопросами непрерывной доступности виртуальных машин (Fault Tolerance). Ранее продукты этой компании были доступны на платформе Citrix XenServer, где позволяли обеспечивать непрерывную доступность программными методами (продукт everRun от купленной компании Marathon):

Теперь у компании появился программно-аппаратный комплекс Stratus ftServer systems with vSphere 5.1, интегрированный с последней версией платформы виртуализации от VMware. Возможности решения из пресс-релиза:

• Обещают аптайм на уровне 99.999%, что соответствует 5.26 минут простоя в год
• Один или два 8-ядерных процессора Intel с поддержкой hyper-threading и архитектуры QuickPath
• Полная поддержка SMP для построения архитектуры непрерывной доступности (vSMP?)
• Встроенные интерфейсы 10Gb Ethernet
• Проактивная система мониторинга, предупреждающая о возможных сбоях
• Система обнаружения проблем в самом сервере и операционной системе, работающая без прерывания обслуживания виртуальных машин
• Минимальный overhead (<5%) на систему виртуализации
• Интеграция с VMware HA

Очевидно, что Stratus суетится накануне выхода программного vSMP Fault Tolerance от самой VMware.

Кстати в пресс-релизе по ftServer говорится о полугодовой гарантии на нулевой даунтайм в $50 000, покрывающей не только серверную часть, но и гипервизор (!). Так что торопитесь - возможно, парочка серверов от Stratus достанется вам совершенно бесплатно (учитывая тот набор багов, который мы видим в vSphere 5.1).

На днях компания VMware провела целых два тестирования (тут и тут), целью которых было сравнение производительности виртуальных дисков VMDK и RDM виртуальных машин на платформе VMware vSphere 5.1. Напомним про предыдущие сравнения VMFS и RDM, где основной моралью был тот факт, что оба этих типа виртуальных дисков практически идентичны по производительности, поэтому их следует использовать только в случаях, когда требуется специфическая функциональность (например, кластеры MSCS и большие диски для RDM):

• ESX 3.0.1
• ESX 3.5

Итак, для первого тестирования использовалась следующая конфигурация:

В качестве нагрузки использовался тест DVD Store для приложения, симулирующего интернет-магазин на платформе mySQL 5.5. Также было задействовано несколько тестовых клиентов для создания реальной нагрузки.

Масштабируемость производительности под нагрузкой (OPM - это orders per minute):

Как видно из результатов, масштабируемость производительности при увеличении числа ВМ почти линейная, а результаты различных типов дисков - идентичны (на самом деле, VMDK показал себя на 1 процент быстрее RDM для 1-й ВМ и чуть медленнее для 4-х ВМ):

Затраты ресурсов CPU на обслуживание операций ввода-вывода также чуть-чуть (на тот же 1%) лучше в пользу VMDK:

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

Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: Two Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: Five QLogic QLE2562
Storage: One Violin Memory 6616 Flash Memory Array
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Configuration: Random, 4KB I/O size with 16 workers

Тут уже измерялась производительность в IOPS для виртуальных машин на платформе VMware vSphere 5.1. При этом варьировался размер блока ввода-вывода (I/O Size) и сравнивались VMDK диски в VMFS5 и RDM-тома (нагрузка - случайное чтение):

Здесь уже на тот же самый 1% выигрывает RDM (для тестов на I/O). В тестах на MB/s ситуация в одном тесте оказалась в пользу VMFS. Масштабируемость тут уже показана не совсем линейная, при этом завал кривой начинается после размера блока в 4 Кб (единственный и по умолчанию в vSphere 5.1).

Второй тест - 60% операций чтения и 40% операций записи:

Такой рост производительности на блоке в 4 Кб объясняется просто - массив, примененный в тестировании, использует размер блока 4 Кб.

Вывод обоих тестов - виртуальные диски VMDK и RDM практически идентичны с точки зрения производительности.

Компания Citrix выпустила обновление своего продукта для создания инфраструктуры виртуальных ПК в небольших компаниях Citrix VDI-in-a-Box 5.2. Напомним, что о предыдущей версии этого продукта (5.1) мы уже писали вот тут (а еще раньше - здесь).

Новые возможности решения Citrix VDI-in-a-Box 5.2:

• Support for new hypervisor versions - теперь VDI-in-a-Box поддерживает гипервизоры Microsoft Hyper-V Server 2012, XenServer 6.1 и vSphere 5.1.
• Citrix Cloud Gateway StoreFront support - пользователи StoreFront могут получать доступ к своим VDI-in-a-Box через Cloud Gateway. StoreFront - это унифицированное хранилище данных и приложений (Win/Web/SaaS), которые могут быть доставлены посредством Citrix на различные устройства.
• Microsoft Lync support - пакет Citrix HDX RealTime Optimization Pack for Microsoft Lync позволяет совершать видеозвонки высокой четкости, используя свои виртуальные ПК.
• Image export - опубликованные образы ПК могут быть экспортированы для использования в Citrix XenDesktop и других продуктах.
• Licensing management through a Citrix license server - для существующих пользователей Citrix, у которых уже есть сервер лицензий от других продуктов компании, теперь есть возможность управления лицензированием VDI-in-Box.
• Multiple data stores - пользовательские объекты vDisk могут находиться на разных хранилищах, что позволяет оптимизировать производительность различных категорий данных и приложений.
• Windows Server 2012 virtual desktops - поддержка виртуальных ПК с гостевой ОС Windows Server 2012 (но только посредством RDP-соединений).
• Automated desktop agent upgrade - после обновления VDI-in-a-Box можно обновить агентов в виртуальных ПК одним кликом.
• Citrix Desktop Lock - возможность залочить физический ПК, когда пользователям не требуется локальный компьютер. В результате обычные рабочие станции превращаются в подобия тонких клиентов.

Скачать Citrix VDI-in-a-Box 5.2 можно по этой ссылке. Документ по миграции с предыдущих версий находится тут.

Рост бизнеса компании ИТ-ГРАД по предоставлению в аренду виртуальных машин на платформе VMware vSphere в столице и, как следствие, рост числа сотрудников повлекли за собой необходимость поиска нового, более просторного помещения. Новый офис находится в бизнес-центр «Золотое кольцо», в минуте ходьбы от ст. м.Кожуховская. Телефон остался прежним: +7 (495) 748-05-77.

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

С приходом Нового года в продукте VMware vCenter, входящем в состав vSphere 5.1, была обнаружена ошибка, следствием которой является отображение за прошедший год статистик производительности (Performance history) только за последние 30 дней (декабрь).

Данная ошибка является следствием недоработок в хранимых процедурах БД vCenter Server, что приводит к удалению (purge) объектов базы данных, касающихся производительности. Исправления ошибки и никакого workaround'а пока нет.

С одной стороны, эти данные не являются критичными и, зачастую, не используются администраторами, однако различные продукты, которые используют исторические данные для анализа и планирования мощностей инфраструктуры виртуализации (Capacity Planning), не смогут уже выполнять свои функции адекватно.

Для получения информации об исправлении ошибки можно подписаться на KB 2042164.

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

Сегодня мы хотим обратить ваше внимание на документ "StarWind iSCSI SAN & NAS: Multipathing", в котором детально и по шагам рассказывается о настройке механизма доступа по нескольким путям (MPIO) при использовании сервера хранилищ StarWind iSCSI SAN. В руководстве рассматривается настройка серверов на базе следующей схемы подключения:

В документе описаны способы настройки серверов как на платформе Windows Server 2008, так и Windows Server 2012.

Известный многим Duncan Epping в своем блоге рассказал об изменениях, которые произошли в механизме обнаружения события изоляции хост-сервера ESXi в VMware vSphere 5.1. Приведем их вкратце.

Как мы уже писали вот тут, кластер VMware HA следующим образом обрабатывает событие изоляции (отсутствие коммуникации с другими серверами кластера):

T+0 сек – обнаружение изоляции хоста (slave)
T+10 сек – хост slave переходит в режим выбора (“election state”)
T+25 сек – хост slave объявляет себя мастером (master)
T+25 сек – хост slave пингует адреса isolation addresses (по умолчанию один)
T+30 сек – хост slave объявляет себя изолированным и инициирует действие, указанное в isolation response

В VMware vSphere 5.1 появилось небольшое изменение, выражающееся в том, что хост ждет еще 30 секунд после объявления себя изолированным до инициации действия isolation response. Это время можно отрегулировать в следующей расширенной настройке кластера:

das.config.fdm.isolationPolicyDelaySec.

Таким образом, теперь последовательность выглядит так:

T+0 сек – обнаружение изоляции хоста (slave)
T+10 сек – хост slave переходит в режим выбора (“election state”)
T+25 сек – хост slave объявляет себя мастером (master)
T+25 сек – хост slave пингует адреса isolation addresses (по умолчанию один)
T+30 сек – хост slave объявляет себя изолированным и
T+60 сек - хост инициирует действие, указанное в isolation response

Наглядно:

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

Зачастую администраторам VMware vSphere требуется снять скриншот консоли виртуальной машины, который появляется вследствие различных ошибок или при установке ОС в ВМ. Делают они это, как правило, нажимая принтскрин в ОС, где установлен vSphere Client. Однако этот способ не очень красивый и не особо универсальный - ниже мы покажем, как правильно делать скриншот консоли ВМ.

Для этой операции мы снова задействуем MOB (Managed Object Browser), о котором мы уже писали тут и тут. Сначала нам надо получить MoRef ID виртуальной машины на определенном хосте VMware ESXi. Вкратце: MoRef ID присваивается виртуальной машине (и другим объектам) сервером vCenter для различных операций с ней, в том числе через MOB (он также используется в vCloud Director и других продуктах). MoRef ID уникален в пределах одного сервера vCenter.

Для получения MoRef ID воспользуйтесь статьей KB 1017126 - в ней все понятно расписано по шагам. Можно также воспользоваться скриптом vSphere MoRef ID Finder, который написал Вильям Лам.

Далее в адресной строке браузера наберите:

https://<IP хоста ESXi>/screen?id=vm-171

где vm-171 - это MoRef ID виртуальной машины. После авторизации пользователя (у которого должна быть привилегия VirtualMachine.Interact.ConsoleInteract) скриншот консоли ВМ будет выведен прямо в браузер.

При получении скриншота ВМ можно использовать еще несколько GET-параметров:

w = ширина получаемой картинки
h = высота получаемой картинки
x0  = координата X левого угла для снятия скриншота региона
y0 = координата Y левого угла для снятия скриншота региона
x1  = координата X правого угла для снятия скриншота региона
y1 = координата Y правого угла для снятия скриншота региона

Примеры отработки MOB для получения скриншотов ВМ с различными параметрами:

https://<IP хоста ESXi>/screen?id=vm-162&h=600&w=800

Скриншот региона:

https://<IP хоста ESXi>/screen?id=vm-162&h=600&w=800&x0=200&y0=75&x1=480&y1=200

Duncan и Frank, известные своими изысканиями в сфере механизмов отказоустойчивости (HA) и балансировки нагрузки (DRS) в виртуальной инфраструктуре VMware vSphere, опубликовали пару интересных материалов, касающихся настройки среды vCloud Director и механизма Storage DRS.

Как вы знаете, в настройках кластера хранилищ (Datastore Cluster) есть галка, которая определяет, будут ли виртуальные диски VMDK машин обязательно находиться на одном хранилище (Datastore) при миграции средствами механизма Storage DRS:

Надо отметить, что галка Keep VMDKs together by default - это не совсем простая для понимания галка. Если ее не поставить, то действовать будет обратное - диски виртуальной машины будут обязательно размещаться на разных хранилищах. Это, по заверениям блоггеров, даст больше гибкости в использовании механизма SDRS в среде vCloud Director при перемещении виртуальных машин между хранилищами, что даст больше преимуществ в динамически балансирующейся среде (особенно для "тонких" дисков). Соответственно, по умолчанию галка Keep VMDKs together by default должна быть выключена.

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

Собственно файлы:

• Capacity_IQ_-_Offline_Demo.zip
• Chargeback_1.5_-_Offline_Demo.zip
• ITBM_7.5_-_Financial_Mgmt_Overview_-_Offline_Demo.zip
• Private_Cloud_Cap-Mgmt-Auto-Remediation_-_Offline_Demo.zip
• Private_Cloud_Health-Change-Compliance_-_Offline_Demo.zip
• Site_Recovery_Manager_5.0_-_Offline_Demo.zip
• SoftwareDefinedDatacenter_-_OfflineDemo.zip
• SRM_4.0_-_Offline_Demo.zip
• SRM_4.0_-_Self-Playing_Demo.zip
• vCD_Infrastructure_Resiliency_-_Offline_Demo.zip
• vCenter_CapacityIQ_1.5_-_Offline_Demo.exe.zip
• vCenter_Config_Manager_for_VI_Admins_-_Offline_Demo.zip
• vCenter_Host_Profiles_-_Offline_Demo.zip
• vCenter_Linked_Mode_-_Offline_Demo.zip
• vCenter_Operations_Manager_5.0_-_Offine_Demo.zip
• vCenter_Operations_Standard_-_Offline_Demo.zip
• vCenter_Operations_Standard_Offline_Demo_v1_0-Mar_2011.zip
• vCenter_Orchestrator_-_Offline_Demo.zip
• vCloud_Director_1.0_-_Offline_Demo.zip
• vCloud_Director_1.5_New_Features.zip
• vCloud_Director_5.1_-_Offline_Demo.zip
• vCloud_Networking_and_Security_Suite_-_Offline_Demo.zip
• vCloud_Request_Manager_Offline_Demo.zip
• vCM_5.4_in_vCenter_for_Server_Admins.zip
• vCM_5.4_OS_Provisioning_-_Offline_Demo.zip
• vCM_for_vSphere_5.4.1_-_Offline_Demo.zip
• vDS_Nexus_-_Offline_Demo.zip
• vFabric_Application_Director_-_Offline_Demo.zip
• vFabric_Gemfire_HTTP_Session_Mgt_-_Offline_Demo.zip
• vFabric_GemFire_L2_Cache_-_Offline_Demo.zip
• vFabric_GemFire_Session_Mgmt_-_Offline_Demo.zip
• vFabric_Hyperic_-_Offline_Demo.zip
• vFabric_tc_Server_-_Offline_Demo.zip
• View5.1_PoolManagement_-_OfflineDemo.zip
• View_5_Persona_Mgt_-_Offline_Demo.zip
• View_5_Pool_Mgt_-_Offline_Demo.zip
• View_Administrator_4.5_-_Offline_Demo.zip
• VMware_Data_Recovery_-_Offline_Demo.zip
• VMware_Fault_Tolerance_(BlackBerry_Server)_-_Offline_Demo.zip
• VMware_Fault_Tolerance_(SAP)_-_Offline_Demo.zip
• VMware_Infrastructure_Navigator_1.1_-_OfflineDemo.zip
• VMware_vCloud_Director_Offline_Demo_v1.0.zip
• vShield_App_with_vCloud_Director_-_Offline_Demo.zip
• vShield_Edge_-_Offline_Demo.zip
• vSphere_5_Storage_Enhancements_-_Offline_Demo.zip
• vSphere_Auto_Deploy_-_Offline_Demo.zip
• vSphere_Distributed_Switch_Features_-_Offline_Demo.zip
• vSphere_Storage_Appliance_5.1_-_OfflineDemo.zip
• vSphere_Web_Client_-_Offline_Demo.zip

Вроде все, больше нет.

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

Соответственно, нужно начинать отучать пользователей ходить через vSphere Client и приучать использовать веб. Проблема в том, что штатного способа сделать это нет. Если у пользователя есть доступ - то и клиент он всегда сможет скачать и использовать.

Поэтому William Lam придумал простой способ борьбы с этим. Надо открыть файл version.txt на сервере vCenter, который находится вот тут:

• Windows: C:\ProgramData\VMware\VMware VirtualCenter\docRoot\client
• VCSA: /etc/vmware-vpx/docRoot/client

Дальше в значение версии клиента (exactVersion) нужно вписать несуществующую версию, например, 9.0.0. После этого, при логине через vSphere Client, пользователям будет предложено скачать версию клиента, которой не существует, что приведет к зацикливанию процесса:

Однако это приведет к желаемому результату - через vSphere Client пользователи не смогут залогиниться.

На сервере VMware ESXi это тоже можно применить, однако там нужно поправить файл clients.xml, размещенный по адресу:

/usr/lib/vmware/hostd/docroot/client 

Так что пора уже переводить своих пользователей на браузер.

Отличный пост про симулятор сервера vCenter написал William Lam. Изложим здесь его вкратце. Когда-то два человека, Zhelong Pan и Kinshuk Govil, написали утилиту vcsim, которая позволяет эмулировать сервер VMware vCenter в котором запущены тысячи виртуальных машин, при этом такие объекты потребляют минимум ресурсов и работают на минимальной конфигурации VMware vCSA (vCenter Server Appliance). Утилита входит в состав vCSA, но отсутствует в обычной инсталляции vCenter.

Помимо собственно построения виртуального Inventory сервера vCenter из виртуальных машин и хост-серверов, утилита vcsim поддерживает простейшие операции с фейковыми объектами, например, Power On ненастоящих машин, а также различные метрики производительности. Кроме того, с помощью этой утилиты можно и добавлять настоящие серверы VMware ESXi и виртуальные машины, создавая гибридную конфигурацию, так как vcsim - это, все же, настоящий vCenter Server.

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

• При изучении vSphere API для исследования функций навигации по иерархии.
• Возможность создать "виртуальное" окружение для тестирования различных скриптов.
• Разработка утилит, отслеживающих производительность
• Разработка плагинов к vSphere Web Client 

Для начала работы с vcsim нужно внести изменения в файл /etc/vmware-vpx/vpxd.cfg, поместив туда следующее между тэгами </vpxd> и </config>:

<simulator>
<enabled>true</enabled>
<cleardb>false</cleardb>
<initinventory>vcsim/model/initInventory.cfg</initInventory>
</simulator>

Кстати, шаблон конфигурации vcsim представлен в файле:

/etc/vmware-vpx/vcsim/model/vcsim.cfg.template

После этого нужно перезапустить сервис vCenter:

service vmware-vpxd restart

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

После рестарта сервиса мы можем увидеть окружение с сотнями хост-серверов и десятью тысячами виртуальных машин, как в веб-клиенте:

\

так и в "толстом" клиенте:

Теперь мы можем менять параметры окружения в файле:

/etc/vmware-vpx/vcsim/model/initInventory.cfg

В нем можно настраивать следующие объекты:

• Datacenter
• Hosts per Datacenter
• VM per Host
• Powered On VM per Host
• Cluster per Datacenter
• Host Per Cluster
• Resource Pool per Cluster
• VM per Resource Pool
• Powered On VM
• vCPU for a VM
• vMEM for a VM

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

service vmware-vpxd stop
vpxd -b
service vmware-vpxd start

Кроме того, vcsim использует следующие конфигурационные файлы:

• vcsim/model/metricMetadata.cfg (симулируемые Performance Metrics - по умолчанию их нет)
• vcsim/model/vcModules.cfg (симулируемые модули vCenter, например, DRS)
• vcsim/model/OperationDelay.cfg (задержки выполнения операций)

Так что теперь можно испытывать эту штуку и экспериментировать в свободное время. Ну и, само собой, все это никак не поддерживается со стороны VMware.

Друзья, коллеги, партнеры, читатели и все-все-все!

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

Коллектив VM Guru желает вам Счастливого Нового года, новых свершений, новых идей и успехов в 2013 году!

Наш спонсор, компания номер 1 в сфере предоставления облачной инфраструктуры VMware vSphere в аренду - ИТ-ГРАД, поздравляет читателей VM Guru с наступающим Новым годом. ИТ-ГРАД искренне желает вам добра и любви, а вашей облачной ИТ-инфраструктуре успешного развития под надежным контролем специалистов компании.

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

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

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

Итак:

• Прогноз от Savvis - в 2013 году облака будут все еще on-premise, т.е. работать в пределах инфраструктуры компании. Выиграют те сервис-провайдеры, которые смогут предоставлять гибридную модель онпремизно-офпремизных услуг. Об этом же говорит и прогноз BlueStripe - крупные компании, само собой, от частного облака в публичное никогда полностью не уйдут - критичные сервисы всегда будут в своем датацентре:

• Прогноз от Veeam Software - гипервизоры VMware и Microsoft будут сосуществовать в инфраструктурах компаний, а также средний и малый бизнес будет использовать возможности виртуализции, которые традиционно считались доступными только Enteprise-сектору.

• Прогноз VMware: 2013-год - это год software-defined storage как продолжения концепции software-defined datacenter. Об этой концепции мы уже писали в наших статьях: "Как VMware продолжает менять подход к ИТ-инфраструктуре: концепция vVOL для хранилищ виртуальных машин vSphere" и "VMware Distributed Storage и концепция vSAN для построения хранилищ VMware vSphere". Ключевая идея этой концепции - абстрагировать ресурсы хранения для виртуальной среды и раздавать их виртуальным машинам на базе политик и SLA, а не на базе томов и дисковых массивов.

• Еще один прогноз от VMware - повсеместное применение межсетевого взаимодействия в самоопеделяемых сетях SDN (software-defined networking). Об этом мы уже писали в статьях "Компания VMware приобрела Nicira за $1 260 000 000 - зачем?","Что такое и как работает технология VXLAN для создания виртуальных сетей нового поколения для виртуальных машин VMware vSphere". Действительно, темой SDN занимается сейчас не только VMware, но и, например, Oracle. Об этом мы писали в статье "Компания Oracle покупает Xsigo Systems - ответ на покупку Nicira компанией VMware".

• В том же прогнозе рассказано про HPC Cloud Computig - высокопроизводительные публичные облака. На эту тему, конечно же, мы вспомним нашу заметку "Еще одно публичное облако IaaS - Google Compute Engine". И дествительно, кому как не Гуглу таким заниматься? Но надо помнить, что на этом рынке есть еще Microsoft (вот тут) и, конечно же, первопроходец облачных сервисов - Amazon (вот тут).

• В том же прогнозе рассказывается про эволюцию виртуальных машин, которые будут приобретать новые свойства. Например, новые технологии работы с хранилищами - "Технология Virtual Flash (vFlash) для SSD-накопителей в VMware vSphere" или использование графических модулей напрямую в ВМ (см. "Платформа VGX от NVIDIA - платы с поддержкой виртуализации GPU для VDI-инфраструктуры").

• В продолжение прогнозов от VMware - про достижение максимального уровня автоматизации частых облаков. Об этом можно почитать в наших статьях "Продукт VMware vCloud Automation Center 5.1 доступен для загрузки - новые возможности" и "VMware объявила о запуске бесплатного продукта vCenter Operations Manager Foundation и изменила комплектность vCO Management Suite 5.6.". Ну это в Пендосии, а у нас, будем надеяться, что хоть кто-то поставит себе для начала vCloud Director. Потому как с восприятием облаков в России дела обстоят совсем плохо:

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

Также еще несколько предсказаний вы можете почитать вот тут. Ну и интереснейшая серия прогнозов на 2013 год вот тут (я выбрал самые интересные):

• CA Technologies Cloud Predictions for 2013: Cloud Computing's Sophomore Year
• SunGard Availability Services Predictions: Why Asset Optimization Will Rule in 2013
• Symantec 2013 Virtualization and Cloud Predictions: Innovation Out of Necessity
• VMTurbo 2013 Predictions: Operational Issues in Virtualized Data Centers and Clouds To Take Center Stage
• Citrix Predictions: Four Predictions That Will Shape Mobility In 2013
• HotLink Predictions: Attack Conflicting Goals in 2013 - Agility, Diversity, IT-as-a-Service, and Cost Containment
• Quest Software: Decrease in Backup Solutions, Increase in Protection of Services - Five 2013 Predictions
• Rackspace: Five Cloud Predictions For 2013
• Veeam 2013 Predictions: Hypervisor Coexistence and Enterprise Capabilities in the SMB
• VMware Predictions for 2013: Expect Even More Change Ahead
• Dell Predictions: 2013 - The Year of Hardware and Management Software "Convergence"
• SaaS Markets Prediction: SaaS App Marketplace Poised for Explosive Growth in 2013
• FalconStor 2013 Predictions: Deduplication Proves All Data Is Not Equal
• Virtual Bridges Predictions: 2013 - The Changing Face of VDI
• CommVault 2013 Predictions: Business IT Forecast - Partly to Mostly Cloudy with an Increasing Chance of Managed Service Providers
• SolarWinds 2013 Predictions: If the Mayans are Wrong, Here's What 2013 will Hold for Virtualization
• Acronis Predictions: 2013 - The Year the Cloud Becomes Invisible
• Stratus Technologies: The Cloud is no Place for Mission-Critical Applications. Not in 2013 or the Foreseeable Future.\
• F5 Networks 2013 Predictions: Cloud Trends Include SDN and Cloud-based Solutions

Некоторые из вас знают, что компания VMware выпускает специализированный фреймворк VDDK (VMware Virtual Disk Development Kit), который позволяет просто обращаться с виртуальными машинами в контексте резервного копирования. Его используют практически все вендоры решений для РК виртуальных машин на платформе vSphere, например, Veeam Backup and Replication и Symantec BackupExec.

Не так давно было заявлено о том, что версия VDDK 5.1 может вызывать проблемы при использовании с VMware vSphere 5.1, что выражается в зависании и прерывании некоторых вызовов к функциям резервного копирования и восстановления (например, функции VixDiskLib_ConnectEx и VixDiskLib_Cleanup). Это описано в статье "Third-party backup software using VDDK 5.1 may encounter backup/restore failures", при этом проблема на сегодняшний день не имеет решения.

Так почему же пользователи продукта Veeam Backup and Replication этого не замечают? Все очень просто. Если прочитать статью "Symantec admits all its VMware backup customers are in danger", то становится понятным, что поскольку тестеры и разработчики Veeam давно работают с фреймворком VDDK (еще со времен VADP), то они уже успели понять, что это временами весьма глючная штука. Поэтому процессы Veeam Backup and Replication постоянно следят за работой служб VDDK, проверяют, не зависли ли они сами или их потоки, а в случае зависания (которое определяется грамотно выставленными таймаутами) - терминируют их безопасно для задачи РК. Мало того, в данный момент Veeam работает совместно с VMware над устранением данной проблемы.

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

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

Первое - это то, с чем должен быть знаком каждый администратор VMware vSphere - решение vCloud Director 5.1, которое является базой для создания частных и гибридных облаков на основе продуктов VMware.

Скачать оффлайн-демо VMware vCloud Director 5.1.

Второе - это распределенный коммутатор Cisco Nexus Distributed Switch. Многие компании применяют распределенный коммутатор от VMware (vDS) и мало знакомы с решением от Cisco, которое предоставляет намного больше возможностей.

Скачать оффлайн-демо VMware Cisco Nexus vDS.

Третье - это компонент VMware vCenter Orchestrator, который представляет собой средство автоматизации операций в виртуальной инфраструктуре. Если у вас больше 3-5 хост-серверов VMware ESXi, вам обязательно нужно потыкать демку:

Скачать оффлайн-демо vCenter Orchestrator.

Функции VMware View Persona Management, о которых мы уже писали. Как они работают? Тыркаем тут:

Скачать оффлайн-демо VMware View Persona Management

VMware vCloud Networking and Security - это новое название продуктов семейства vShield. Просто посмотреть, как это все работает:

Скачать оффлайн-демо VMware vCloud Networking and Security

Этих штук еще есть очень много. Надо? Выкладывать?