Аналитическая компания Gartner выпустила магический квадрант (Magic Quadrant) за 2017 год, посвященный программному обеспечению для резервного копирования и восстановления ИТ-систем датацентров. Напомним, что о квадранте по серверной виртуализации мы писали вот тут, а здесь - про квадрант об IaaS (Infrastructure-as-a-Service).

Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

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

• Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
• Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
• Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
• Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.

Как и в квадрантах прошедших 4 лет, компания Veeam - единственная в сегменте лидеров производящая специализированное ПО для бэкапа виртуальных сред Veeam Backup and Replication. Остальные - это традиционные поставщики систем резервного копирования, которых Veeam постепенно вытесняет с рынка ПО для бэкапа виртуальных машин.

Кстати, вот так выглядел этот квадрант год назад:

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

Полностью отчет Gartner Magic Quadrant for Data Center Backup and Recovery Software 2017 можно скачать по этой ссылке с сайта Veeam. Кстати, Veeam еще находится в списке Топ-100 облачных компаний 2017 по версии FORBES.

В VMware vSphere есть механизм для создания и анализа кастомных алармов - VMkernel Observations (VOBs). VOB'ы - это системные события, которые можно использовать для пользовательских алармов в целях отладки различных аспектов виртуальной инфраструктуры (сетевого взаимодействия, кластеров vSAN, производительности и т.п.).

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

/usr/lib/vmware/hostd/extensions/hostdiag/locale/en/event.vmsg

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

/var/log/vobd.log

Для того, чтобы создать кастомный аларм на основе VOB, нужно при создании нового аларма выбрать пункт "specific event occuring on this object":

И далее добавить соответствующий идентификатор, например, такой:

esx.problem.vob.vsan.pdl.offline

Событий, для которых можно создать кастомные алармы, очень много. Вот некоторые из них:

Ну а вот так вот будет выглядеть сработавший кастомный аларм в интерфейсе VMware vSphere Web Client:

Аналитическая компания Gartner опубликовала магический квадрант (Magic Quadrant) за 2017 год, посвященный публичным облачным сервисам, предоставляющим ресурсы инфраструктуры как услугу ( IaaS, Infrastructure-as-a-Service). Напомним, что о квадранте по серверной виртуализации мы писали вот тут.

Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

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

• Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
• Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
• Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
• Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.

Для сравнения посмотрим на квадрант по IaaS, опубликованный в августе 2016 года:

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

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

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

Напомним, что для этого теперь есть 2 политики: Primary level of failures to tolerate (PFTT) и Secondary level of failures to tolerate (SFTT). Для растянутого кластера PFTT определяет защиту между площадками, реализуемую по схеме RAID-1. А политика SFTT для растянутого кластера определяет защиту на уровне локального сайта, которая может быть реализована по схеме RAID-1 (на обычных дисках), а также RAID-5 или RAID-6 (для архитектуры All-Flash).

Это, кстати, означает, что при полном отказе одного из сайтов растянутого кластера, виртуальные машины выжившего сайта все еще будут защищены на уровне отдельных хостов или виртуальных дисков. Единственное, что для этого компонент Witness должен быть доступен. Ну и, само собой, при отказах дисков/хостов внутри площадки виртуальные машины также будут защищены в соответствии с политикой SFTT.

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

Традиционно, до введения политик избыточности на уровне каждой из площадок, планирование емкости было простым - надо было просто удвоить исходную емкость одной площадки. В vSAN 6.2 появилась не только защита RIAD-1 (mirroring), но и RIAD-5/6 (erasure coding), что позволяет в рамках растянутых кластеров организовать различные схемы размещения данных. Отметим, что алгоритм erasure coding между площадками пока не реализуем ввиду ограничений на уровне домена отказа (Fault Domain). Поэтому между площадками - только Mirroring.

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

В поле PFTT для растянутых кластеров мы видим 1, а для обычных 0. FTM (Failure Tolerance Mode) - это режим обеспечения отказоустойчивости на уровне каждого из сайтов. Напомним, что для обычных дисков он может быть только Mirroring, а для All-Flash архитектур - Mirroring или Erasure Coding.

SFTT определяет число отказов дисковых объектов внутри площадки, которое сможет перенести каждая из площадок вашего растянутого кластера.

Таким образом, если вы организуете растянутый кластер хранилищ на базе архитектуры All-Flash со средствами защиты Erasure Coding в рамках площадки и Mirroring между площадками, то вам потребуется 266% исходной дисковой емкости виртуальных машин (ее можно скорректировать на экономию от Thin Provisioning).

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

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

Компания VMware выпустила обновление сервера управления виртуальной инфраструктурой - VMware vCenter Server 6.5b. Новых возможностей там три:

• Последние обновления по временным зонам (time zones) при кастомизации гостевых операционных систем Linux и Windows.
• Обновленный пакет Oracle (Sun) JRE package версии 1.8.0_12 с поддержкой турецкой временной зоны.
• Значительно обновленный VMware vSphere Client (бывший HTML5 Client).

Последний пункт как раз и заслуживает внимания. В состав vCenter Server 6.5b вошел vSphere Client версии 6.5 (Build 5178943). Судя по версии билда - это нечто среднее между vSphere Client 3.7 (Build 5168275) и vSphere Client 3.8 (Build 5204615), которые доступны на сайте проекта VMware Labs. То есть, это практически самый свежий клиент.

Тем не менее, у vSphere Client 6.5 на сегодняшний день отсутствует следующая функциональность (подробнее тут):

Скачать VMware vCenter Server 6.5b можно по этой ссылке, а Release Notes доступны тут.

Кроме того были выпущены обновления следующих продуктов:

• VMware Fusion 8.5.5
  • Скачать Fusion 8.5.5 здесь
  • Fusion 8.5.5 release notes здесь
• VMware Workstation 12.5.4 для Linux и Windows
  • Скачать Workstation 12.5.4 здесь
  • Workstation 12.5.4 release notes здесь

Как некоторые знают, в VMware vSphere 6.5 появилась (а точнее вернулась снова) возможность Automatic VMFS UNMAP - возврат дискового пространства виртуальной машины (ее VMDK) на сторону дискового массива средствами VAAI (vStorage API for Array Integration). Если раньше эта возможность требовала выполнения различных команд, то теперь управление этой штукой доступно из GUI, а возврат дисковых блоков происходит автоматически. Работает UNMAP только для "тонких" (Thin Provisioned) LUN, на которых размещаются тома VMFS.

Из GUI vSphere Web Client можно управлять только UNMAP'ом для томов VMFS 6, для пятой версии файловой системы это нужно делать вручную с помощью ESXCLI. Кроме того, механизм UNMAP работает в асинхронном режиме, а иногда хочется почистить хранилища от неиспользуемых блоков прямо сейчас.

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

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

Function Perform-VMFSUnmap {

[CmdletBinding()]

param(

[Parameter(

Mandatory=$true)]

[String[]]$Datastore,

[String]$ESXiHost

)

Set-PowerCLIConfiguration -WebOperationTimeoutSeconds -1 -Scope Session -Confirm:$false

$ESXHost = Get-VMHost $ESXiHost

$DatastoreName = Get-Datastore $Datastore

Write-Host 'Using ESXCLI and connecting to $VMHost' -ForegroundColor Green

$esxcli = Get-EsxCli -VMHost $ESXHost

Write-Host 'Unmapping $Datastore on $VMHost' -ForegroundColor Green

$esxcli.storage.vmfs.unmap($null,$DatastoreName,$null)

}

Ну а вот так надо запускать этот сценарий:

Perform-VMFSUnmap -ESXiHost ESXi65-A.lab.local -Datastore ISOs

Компания Citrix на днях объявила о доступности для загрузки новой версии своей платформы виртуализации Citrix XenServer 7.1. Напомним, что прошлая версия продукта - XenServer 7 - была выпущена в мае прошлого года.

Давайте посмотрим на возможности нового XenServer 7.1:

• Ускорение загрузки виртуальных машин до 25% за счет применения технологии Provisioning Services (PVS) Accelerator. В некоторых случаях это приводит к сокращению передаваемого трафика в сети на величину до 98% и уменьшению нагрузки на CPU до 93%. Эта фича доступна только для пользователей издания Platinum продукта XenApp и для любого издания XenDesktop.
• XenServer перешел на условия поставки Long Term Service Release (LTSR), что предполагает 10-летний цикл сопровождения продукта (5 лет поддержки и еще 5 лет расширенной поддержки). Такие же условия сейчас предлагаются для XenApp и XenDesktop.
• Для всех пользователей продуктов XenApp и XenDesktop платформа XenServer Enterprise доступна бесплатно, вне зависимости от типа лицензии. Это предполагает наличие такой важной фичи, как кэширование в памяти на чтение, что улучшает производительность Machine Creation Services (MCS).
• Специальные преимущества для пользователей решений Nutanix: улучшенные provisioning services, поддержка NVIDIA GRID vGPU, расширенная поддержка XenServer Direct Inspect APIs.
• Интересная штука - live-патчинг хостов XenServer, не требующий их перезагрузки. Такого нет даже у VMware!
• Автоматические обновления хостов XenServer без участия администратора.
• Средство миграции XenServer Conversion Manager теперь позволяет переносить Linux-машины с платформы VMware vSphere на XenServer.
• Полноценные возможности анализа трафика и предотвращения вторжений XenServer Direct Inspect APIs совместно с технологией Bitdefender Hypervisor Introspection. Это также доступно и для XenServer 7.0.

Если у вас есть какое-либо издание Citrix XenDesktop прошлых лет, вы можете использовать и XenServer 7.1 бесплатно! Ну а сравнение изданий XenServer 7.1 можно посмотреть по этой ссылке. Скачать же 90-дневную пробную версию платформы можно вот тут. Документация доступна здесь.

Компания StarWind, производитель лучшего средства для создания отказоустойчивых хранилищ под виртуализацию, приглашает на бесплатный вебинар "Log-Structured File System in StarWind Virtual SAN new build", посвященный файловой системе LSFS и ее новым возможностям в новом релизе Virtual SAN.

Вебинар пройдет 9 февраля в 19-00 по московскому времени.

Напомним, что файловая система LSFS изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины. Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.

Помимо этого, LSFS имеет следующие полезные функции:

• Встроенная поддержка снапшотов и точек восстановления хранилищ (автоматически они делаются каждые 5 минут).
• Поддержка непрерывной дефрагментации (она идет в фоне).
• Дедупликация данных "на лету" (то есть, перед записью на диск).
• Улучшения производительности за счет комбинирования операций записи.
• Поддержка overprovisioning.
• Использование технологии снапшотов и техник отслеживания изменений при синхронизации HA-узлов.

В новом билде StarWind Virtual SAN у LSFS появилось несколько новых экспериментальных возможностей, которые позволят вам получить больше от этой технологии:

• Передача операций по работе с метаданными на SSD (что снижает требования к RAM).
• Оптимизация производительности операций чтения и записи, что сокращает время на них до 4-5 раз.

Регистрируйтесь на вебинар, чтобы узнать больше о LSFS и новом билде StarWind Virtual SAN.

На днях компания VMware выпустила интереснейший технический документ обо всех новых возможностях новой версии своей флагманской платформы виртуализации - "What’s New in VMware vSphere 65".

Напомним, что о новых возможностях VMware vSphere 6.5 мы уже писали вот тут. Также можно посмотреть наши заметки тут, тут и тут. А вот содержание документа:

• VMware vCenter Server
  • Migration
  • Improved Appliance Management
  • VMware vCenter High Availability
  • Backup and Restore
  • vSphere Web Client
  • vSphere Client
• vSphere Host Lifecycle Management Enhancements
  • vSphere Update Manager
    • VMware Tools and Virtual Hardware Upgrades
    • Previous Windows-Based Architecture Still Offered
  • Host Profiles
    • Profile Management Improvements
    • Operational Enhancements
  • Auto Deploy
    • Manageability Improvements
    • Performance and Resiliency Enhancements
  • VMware Tools 10.1 and 10.0.12
    • Signed ISO Images
    • Bifurcation of VMware Tools for Legacy and Current Guests
    • Bundling of Tools for Most Popular Guests Only
    • Guest OS Granularity Increase
    • Detailed Display of VMware Tools Type and Version in vSphere Web Client
    • Improved Detection of Availability of Updated VMware Tools Installers
• vSphere Operations
  • Operations Management
  • Log Monitoring
• Developer and Automation Interfaces
  
  • Program Interfaces
  • vCenter Server Appliance API
  • Virtual Machine API
  • Discover the APIs with the New API Explorer
  • Process Improvements
  • Command-Line Interfaces
  • What’s New in VMware vSphere
  • VMware PowerCLI
    • Core vSphere Module
    • Storage Module
    • VMware Horizon Module
• Security
  • Virtual Machine Encryption
    • Encrypted vMotion
  • Secure Boot Support
    • Virtual Machine Secure Boot
    • ESXi Host Secure Boot
  • Enhanced Logging
  • VM Sandboxing
  • Automation
• vSphere 65 Availability Enhancements
  • Proactive HA
  • VMware vSphere High Availability Orchestrated Restart
  • vSphere HA Admission Control Improvements
  • VMware vSphere Fault Tolerance
  • Resource Management Enhancements
    • Improved vSphere DRS Load Balancing Algorithm
    • vSphere DRS Additional Options
    • Network-Aware vSphere DRS
    • VMware vSphere Storage I/O Control Using
      • Storage Policy Based Management
    • Content Library
  • vSphere Integrated Containers
• vSphere 65 Storage Enhancements
  • Advanced Format Drives and 512e Mode
  • Automated UNMAP
  • LUN Scalability
  • NFS 4.1 Support
  • Software iSCSI Static Routing Support
• vSphere 6.5 Networking Enhancements
• Enhancements for Nested ESXi
• Dedicated Gateways for VMkernel Network Adapter
• SR-IOV Provisioning
• Support for ERSPAN
• Improvements in DATAPATH

Компания VMware недавно выпустила документ "Instant-Clone View Desktops in Horizon 7", который может оказаться полезным многим администраторам решения VMware Horizon View. Напомним, что технология Instant Clone (ранее она называлась VMFork) позволяет почти мгновенно создавать работающие копии виртуальных машин.

Суть этой технологии такова, что "на лету" создается клон виртуальной машины (VMX-файл и процесс в памяти), который начинает использовать ту же память (Shared memory), что и родительская ВМ. При этом дочерняя ВМ в шаренную память писать не может, а для записи собственных данных используется выделенная область.

Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ. При выключении такой виртуальной машины она полностью уничтожается из памяти и стирается с хранилища, что очень удобно для выполнения типизированных задач, приложения для которых доставляются средствами динамической сборки App Volumes (например, для оператора колл-центра).

Также сам workflow мгновенных клонов выглядит проще, чем для связанных клонов View Composer (об этом мы писали вот тут):

Основные разделы документа:

• Instant-Clone Use Cases
• Cloning Technology
  • Full Clones
  • Linked Clones
  • Instant Clones
• How Instant-Clone Desktop Pools Are Created
  • Publishing the Master Image
  • Provisioning Instant-Clone Desktops
  • What Happened to These Linked-Clone Settings?
• Benefits of Using Instant Clones
  • Simple Setup
  • Easy Management of OS and Software Updates
  • Smaller Load on vCenter
  • Simplified Desktop Pool Management
  • Reduced Storage Costs
• Instant-Clone Restrictions

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

Аналитическая компания Gartner выпустила очередной "магический квадрант" об инфраструктуре серверной виртуализации и лидерах в этой сфере - Magic Quadrant for x86 Server Virtualization Infrastructure 2016. О квадрантах прошлых лет мы уже много писали тут и тут. Интересная деталь - если в 2014 году Gartner оценивала, что примерно 70% серверов архитектуры x86 виртуализованы, то сейчас этот показатель достигает 80%.

Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

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

• Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
• Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
• Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
• Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.

В этом году квадрант не сильно отличается от прошлого года:

Как мы видим за последний год ситуация не сильно изменилась, разве что можно отметить то, что Red Hat перешла в разряд визионеров за счет довольно широкого внедрения гипервизора KVM в архитектурах OpenStack со средствами управления OpenStack Glance project (для управления образами серверов и дисками), а также OpenStack Neutron (для управления виртуальной корпоративной сетью виртуальной инфраструктуры).

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

Кстати, интересно, что у компании Huawei, присутствующей в рейтинге, также есть свой FusionSphere hypervisor:

О том, как облачные технологии решают проблемы документооборота и меняют подход к его организации, рассказал Антон Аникин — генеральный директор компании «Андок», известной своими решениями по управлению процессами, документами и поручениями на базе системы электронного документооборота (СЭД) DocsVision.

О компании и уникальности облачных услуг

Компания «Андок» — сертифицированный партнер «ДоксВижн» — предлагает решение собственной разработки в рамках услуги СЭД DocsVision доступной в модели SaaS. Решение прошло тестирование сотрудниками «ДоксВижн» и доступно из каталога вендора. Для максимальной безопасности и надежности данных клиентов виртуальная инфраструктура услуги по аренде DocsVision размещена в облаке «ИТ-ГРАД» (IaaS), на базе ЦОД DataSpace уровня Tier III.

Читать статью далее->>

В крупных компаниях, где виртуальная инфраструктура является основой всего ИТ, иногда используется продукт VMware NSX для виртуализации и агрегации сетей виртуальных (на базе vSphere) и физических сред. Напомним, что с 3 мая этот продукт также стал доступен в трех изданиях, что позволит приобретать его и небольшим компаниям в базовом издании Standard.

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

Вот эти порты, протоколы и коммуникации для компонентов NSX:

• Client PC > NSX Manager 443/TCP (NSX Manager Administrative Interface)
• Client PC > NSX Manager 80/TCP (NSX Manager VIB Access)
• ESXi Host > ESXi Host 6999/UDP (ARP on VLAN LIFs)
• ESXi Host > NSX Controller 1234/TCP (User World Agent Connection)
• ESXi Host > NSX Manager 5671/TCP (AMQP)
• ESXi Host > NSX Manager 8301, 8302/UDP (DVS Sync)
• ESXi Host > vCenter Server 80/TCP (ESXi Host Preparation)
• NSX Controller > NSX Controller 2878, 2888, 3888/TCP (Controller Cluster – State Sync)
• NSX Controller > NSX Controller 30865/TCP (Controller Cluster -State Sync )
• NSX Controller > NSX Controller 7777/TCP (Inter-Controller RPC Port)
• NSX Controller > NTP Time Server 123/TCP (NTP client connection)
• NSX Controller > NTP Time Server 123/UDP (NTP client connection)
• NSX Manager > DNS Server 53/TCP (DNS client connection)
• NSX Manager > DNS Server 53/UDP (DNS client connection)
• NSX Manager > ESXi Host 443/TCP (Management and provisioning connection)
• NSX Manager > ESXi Host 8301, 8302/UDP (DVS Sync)
• NSX Manager > ESXi Host 902/TCP (Management and provisioning connection)
• NSX Manager > NSX Controller 443/TCP (Controller to Manager Communication)
• NSX Manager > NTP Time Server 123/TCP (NTP client connection)
• NSX Manager > NTP Time Server 123/UDP (NTP client connection)
• NSX Manager > Syslog Server 514/TCP (Syslog connection)
• NSX Manager > Syslog Server 514/UDP (Syslog connection)
• NSX Manager > vCenter Server 443/TCP (vSphere Web Access)
• NSX Manager > vCenter Server 902/TCP (vSphere Web Access)
• REST Client > NSX Manager 443/TCP (NSX Manager REST API)
• vCenter Server > ESXi Host 80/TCP (ESXi Host Preparation)
• vCenter Server > NSX Manager 80/TCP (Host Preparation)
• VTEP > VTEP 8472/UDP (Transport network encapsulation between VTEPs.)

Есть пара интересных постов, на базе которых мы попробуем вкратце описать поведение кластера VMware Virtual SAN в случае, если при развертывании виртуальной машины кластер не способен обеспечить требуемые политики хранилищ (Storage Policies).

1. Обычный кластер Virtual SAN.

Если при развертывании новой ВМ в кластере VSAN невозможно обеспечить требуемые политики хранилищ (например, не хватает места для создания зеркалируемых объектов реплик), а именно:

• NumberOfFailuresToTolerate (FTT)
• NumberOfDiskStripesPerObject (SW)
• FlashReadCacheReservation (FRCR)

то виртуальная машина не сможет быть развернута в кластере. Но есть такая настройка Force Provisioning для VM Storage Policy, которая позволяет игнорировать указанные 3 параметра при развертывании новой ВМ в кластере.

Однако надо понимать, что при использовании Force Provisioning происходит не понижение требований кластера к хранилищу виртуальной машины (например, вместо FTT=2 можно было бы проверить FTT=1), а использование следующих параметров:

• NumberOfFailuresToTolerate = 0
• NumberOfDiskStripesPerObject = 1
• FlashReadCacheReservation = 0

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

Но кластер Virtual SAN имеет еще одну специфическую черту - если вы использовали Force Provisioning при недостатке дисковых ресурсов, то когда они освободятся, для хранилища машины будут сделаны реплики дисковых объектов и прочие операции, чтобы она все-таки соответствовала требуемым политикам хранилищ. Администраторам надо иметь эту особенность в виду.

И еще один момент - так как в случае Force Provisioning может храниться только одна копия дисковых объектов, то, например, если при переводе хоста в режим Maintenance Mode случится какой-нибудь сбой с его хранилищем - реально можно потерять эту машину целиком. Делайте бэкап и, по-возможности, не используйте Force Provisioning - старайтесь соблюдать политики хранилищ хотя бы на уровне FTT=1.

2. Растянутый кластер (Stretched Cluster).

В случае растянутого кластера появляется еще один компонент - Witness Appliance, следящий за ситуацией Split Brain, которая может появиться между площадками. Если вырубить этот виртуальный модуль и попытаться включить виртуальную машину или создать новую ВМ, то кластер Virtual SAN (несмотря на то, что он Failed и политика хранилищ не соблюдена) позволит это сделать, правда будет ругаться, что машина не соответствует текущим политикам хранилищ:

В остальном растянутый кластер ведет себя по отношению к Force Provisioning так же, как и обычный.

Среди возможностей решения для создания отказоустойчивых хранилищ VMware Virtual SAN 6.2 мы забыли упомянуть о нововведении в части обработки файлов подкачки - Sparse Swap.

Как вы знаете при создании виртуальной машины в обычной инфраструктуре под нее резервируется файл *.vswp, который равен по размеру объему сконфигурированной оперативной памяти виртуальной машины (либо объему незарезервированной памяти, то есть разнице между сконфигурированной и зарезервированной памятью, если она указана в настройке reservation). Это нужно на случай, когда машине не хватает свободной физической памяти (в ситуации, если уже не спасают техники memory overcommit), и она начинает сбрасывать страницы памяти в своп-файл на диске.

То есть, если вы создали ВМ с оперативной памятью 4 ГБ, то столько же займет и файл подкачки для этой ВМ. А теперь посмотрим на инфраструктуру Virtual SAN: если у вас задан параметр FTT=1, то каждый дисковый объект (в том числе и файл *.vswp) будет задублирован (если у вас mirror-конфигурация).

Теперь посчитаем, сколько места съест своп 100 виртуальных машин, у каждой из которых 4 ГБ оперативной памяти и которые размещены в кластере VMware Virtual SAN с FTT=1 в зеркальной конфигурации:

100 ВМ * 4 ГБ * 2 (FTT равен 1) = 800 ГБ

Да, именно так - почти терабайт только под своп. Кому-то это покажется расточительством, поэтому в Virtual SAN сделали такую штуку, как Sparse Swap. Эта функция позволяет создавать файлы подкачки vswp как тонкие, то есть растущие по мере наполнения данными, диски.

Для того, чтобы включить опцию Sparse Swap, нужно выполнить следующую команду на хосте VMware ESXi:

esxcfg-advcfg -s 1 /VSAN/SwapThickProvisionDisabled

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

Давно мы не публиковали таблицу сравнения изданий VMware vSphere, а ведь в версии vSphere 6.0 много что изменилось, поэтому иногда полезно взглянуть на таблицу ниже. Кроме того, помните, что с 30 июня колонок в таблице станет на одну меньше - издание vSphere Enterprise снимается с продаж.

Возможность / Издание VMware vSphere	Hypervisor 6 (бесплатный ESXi)	vSphere Essentials 6	vSphere Essentials Plus 6	vSphere Standard 6	vSphere Enterprise 6.0 - (снимается с продаж 30 июня 2016 года	vSphere Enterprise Plus 6
Максимальное число процессоров в ВМ (vSMP)	8	128	128	128	128	128
Thin Provisioning
Update Manager
vStorage APIs for Data Protection
vCenter agent for VMware host
Storage APIs
VMsafe
vSphere API
vRealize Operations Foundation		Смотрите KB (2108695)	Смотрите KB (2108695)	Смотрите KB (2108695)	Смотрите KB (2108695)	Смотрите KB (2108695)
vSphere High Availability
vSphere Data Protection
vSphere vMotion			Cross vSwitch	Cross vSwitch	Cross vSwitch	Cross vSwitch
vSphere Storage vMotion
SUSE Linux Enterprise Server for VMware				Снят с производства	Снят с производства	Снят с производства
Shared Smart Card Reader
vShield Zones
Hot Add / Hot-Pluggable virtual HW
vShield Endpoint
vSphere Replication
vSphere Fault Tolerance				2-vCPU	2-vCPU	4-vCPU
vSphere DRS
MPIO / Third-Party Multi-pathing
Remote Virtual Serial Port Concentrator
vSphere Storage APIs for Array Integration
Distributed Power Management (DPM)
vSphere Distributed Switch
vSphere Host Profiles
vSphere Storage I/O Control & Network I/O Control
Direct Path vMotion
vSphere Storage DRS
vSphere vMotion Metro
vSphere Auto Deploy
vSphere View Accelerator
SR-IOV
App HA						Снят с производства
Big Data Extensions
Reliable Memory
Flash Read Cache
Virtual Volumes
Storage Policy-Based Management
NVIDIA GRID vGPU

В конце прошлого года компания Citrix анонсировала скорую доступность новых версий своих платформ для виртуализации и доставки приложений и десктопов - XenApp 7.7 и XenDesktop 7.7. На днях же эти продукты стали доступны для загрузки. О прошлых версиях данных решений мы писали вот тут.

Давайте посмотрим на новые возможности Cirtix XenApp 7.7 и XenDesktop 7.7:

1. Функционал зон (zones).

Эти возможности позволяют оптимизировать типовую инфраструктуру географически распределенных филиалов. Можно использовать одну первичную зону (Primary Zone), на которой есть единая база данных SQL Server (Site Database) и общие компоненты инфраструктуры Citrix, а остальные зоны (Satellite Zones) получают конфигурации из центральной зоны по WAN, но запросы виртуальных ПК к контроллерам исполняются локально.

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

2. Улучшенные настройки баз данных.

Теперь при создании сайта XenDesktop/XenApp можно указать различные места размещения баз данных для объектов Site, Logging и Monitoring. Также компоненты Delivery Controllers можно создавать не только при создании сайта, но и позже. Более подробная информация приведена вот тут.

3. Функции Application limits.

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

4. Улучшенные нотификации об изменении статуса виртуальных машин.

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

• Апдейт виртуальных машин в Machine Catalog с использованием нового мастер-образа.
• Перезагрузка машин в рамках Delivery Group для применения настроек.

Сообщения можно повторять каждые 5 минут за 15 минут до начала выполнения действий.

5. Поддержка API для перемещаемых сессий.

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

6. Поддержка API для развертывания ВМ из шаблонов.

Теперь виртуальные машины из шаблонов на гипервизор можно развертывать автоматизированно, используя PowerShell SDK.

7. Поддержка обновленных программных компонентов.

Теперь при установке Delivery Controller по умолчанию развертывается SQL Server 2012 Express SP2 (SP1 больше не поддерживается), также обновлены 32 и 64-битные версии Microsoft Visual C++ 2013, 2010 SP1 и 2008 SP1. Citrix Studio или VDA для Windows Desktop OS можно развернуть на Windows 10. Citrix Receiver for Mac и Citrix Receiver for Linux теперь доступны только с сайта Citrix.

8. Многочисленные улучшения Citrix Director.

О них вы можете прочитать по этой ссылке.

9. Улучшенный Skype for Business.

Теперь звонки и видео звонки будут намного качественнее и стабильнее за счет обновленного RealTime Optimization Pack.

10. Интеграция с Azure.

Теперь через Machine Creation Services (MCS) можно быстро и просто создать виртуальные машины в облаке Microsoft Azure. Также Citrix Provisioning Services поддерживается онпремизное развертывание виртуальных ПК на основе Windows 10.

11. Запись сессий в VDI-инфраструктуре.

Теперь можно использовать Session Recording for VDI для записи сессии пользователя виртуального ПК (администратор может так записывать обучающее видео для пользователя или, наоборот, попросить его записать возникшую проблему).

Более подробно о фичах нового релиза можно прочитать в этой статье (там же и про объявленные возможности следующей версии Citrix XenApp 7.8 и XenDesktop 7.8).

Не так давно на сайте VMwareArena появилось очередное сравнение VMware vSphere (в издании Enterprise Plus) и Microsoft Hyper-V в Windows Server 2012 R2 Datacenter Edition, которое включает в себя самую актуальную информацию о возможностях обеих платформ.

Мы адаптировали это сравнение в виде таблицы и представляем вашему вниманию ниже:

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

Сегодняшняя статья расскажет вам ещё об одной функции моего PowerShell-модуля для управления виртуальной инфраструктурой VMware - Vi-Module. Первая статья этой серии с описанием самого модуля находится здесь. Функция Convert-VmdkThin2EZThick. Как вы уже поняли из её названия, функция конвертирует все «тонкие» (Thin Provision) виртуальные диски виртуальной машины в диски типа Thick Provision Eager Zeroed.

На проходящей сейчас конференции VMworld 2015 компания VMware представила новую версию своего решения для виртуализации рабочих мест предприятия VMware Horizon 6.2. Основные нововведения коснулись продукта VMware Horizon View 6.2, отвечающего за виртуализацию ПК и создание VDI-инфраструктуры компании. Напомним, что о новых возможностях решения VMware Horizon View 6.1 мы писали вот тут.

Давайте посмотрим, что нового появилось в VMware Horizon View 6.2:

1. Поддержка архитектуры Cloud Pod для опубликованных приложений (RDS).

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

2. Функции HTML Access for Cloud Pod

Теперь на глобальном уровне можно получить доступ к виртуальному ПК одного из подов прямо по ссылке из браузера с поддержкой HTML 5. Для доступа используется протокол Blast.

3. Стали доступны средства балансировки нагрузки RDSH и интеллектуального размещения сессий.

Теперь для определения загрузки хостов и приложений используются счетчики perfmon, а сессии пользователей балансируются между серверами RDSH на основе этих данных. Безусловно, в Horizon View эти функции еще не такие мощные, как в Cirtix XenApp, но видно, что VMware развивается в этом же направлении.

4. Технология Linked Clones для виртуальных машин с сервисами RDS.

Теперь можно использовать View Composer для создания инфраструктуры связанных клонов (Linked Clones) для ферм RDSH. Это позволяет автоматизировать развертывание этих ферм на хост-серверах VMware ESXi, а также централизованно управлять ими, а самое главное - обновлять на уровне мастер-образа.

Эти функции для сервисов RDS пользователи ждали довольно давно.

5. Технология организации доступа Access Point.

Теперь нет необходимости размещать Windows-машину в DMZ, чтобы организовать безопасный доступ пользователей к их виртуальным ПК. В новой версии используется специализированный защищенный модуль на базе виртуального модуля (Virtual Appliance) Linux SLES 11, который можно выставить в DMZ (установка ПО весьма проста).

6. Поддержка однонаправленных трастов.

Теперь наличие двунаправленного траста не обязательно. Это востребовано в крупных инфраструктурах.

7. Поддержка новой версии технологии NVIDIA GRID 2.0.

Более подробно об этом можно прочитать вот тут. Теперь поддерживается новое поколение карт с процессорами Maxwell. Напомним, что ранее это были карточки NVIDIA K1/K2 (архитектура Keppler).

Новые графические карты M60/6 обещают быть в 2 раза более производительными и позволяют разместить до 128 пользователей, требовательных к производительности графической подсистемы, на одном сервере.

Более подробно об этом написано вот тут.

8. Поддержка AMD GPU для режима vDGA.

Мы уже писали, что такое режим vDGA, и почему он производительнее vSGA. Теперь режим vDGA Passthrough полностью поддерживается для карточек AMD. Кстати, эти карточки стоят дешевле, чем у NVIDIA, поэтому можно снизить стоимость такой инфраструктуры в определенных сценариях.

9. Поддержка функции 3D-ускорения для приложений RDS.

Теперь публикуемые через RDSH приложения тоже поддерживают режим аппаратного ускорения vDGA и vGPU (пока только для NVIDIA). Это может оказаться очень полезным и выгодным, в том числе по сравнению с виртуальными ПК.

10. Поддержка vGPU для Linux-десктопов.

Теперь не только Windows-пользователи смогут полноценно использовать функции vGPU от NVIDIA.

11. Перенаправление клиентского диска для VDI и RDSH.

Если раньше это перенаправление работало только для Windows, то теперь можно перенаправить диски Win и Mac клиентов, а также в экспериментальном режиме и для Linux.

12. Поддержка ассоциаций типов файлов для RDSH.

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

13. Поддержка разрешения 4К.

Теперь мониторы с мегаразрешениями (3840x2160) полностью поддерживаются для инфраструктуры виртуальных ПК:

14. Поддержка Windows 10.

Теперь виртуальные ПК поддерживают в качестве гостевой ОС Windows 10, а также последние функции Skype.

Доступность VMware Horizon View 6.2 ожидается в ближайшее время.

Компания StarWind, известная своим продуктом StarWind Virtual SAN для создания программных отказоустойчивых хранилищ, выпустила интересный документ о своей журналируемой файловой системе - "LSFS container technical description".

Напомним, что файловая система LSFS изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины. Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.

Помимо этого, LSFS имеет следующие полезные функции:

• встроенная поддержка снапшотов и точек восстановления хранилищ (автоматически они делаются каждые 5 минут)
• поддержка непрерывной дефрагментации (она идет в фоне)
• дедупликация данных "на лету" (то есть, перед записью на диск)
• улучшения производительности за счет комбинирования операций записи
• поддержка overprovisioning
• использование технологии снапшотов и техник отслеживания изменений при синхронизации HA-узлов

Обо всем этом и многом другом вы можете почитать в документе "LSFS container technical description".

Некоторые из вас знают компанию VMTurbo, занимающуюся производством решений для резервного копирования виртуальных машин. На днях VMTurbo выпустила бесплатный набор стенсилов Visio, которые можно использовать для рисования схем в своем ЦОД:

Стенсилы включают в себя следующие компоненты:

• Host
• Cluster
• Virtual SAN и физическая сеть зранения данных
• Тонкие и обычные хранилища
• Различные типы облаков в датацентре: Public, Private, Hybrid и Virtual Datacenter
• некоторые другие объекты

Также напомним, что у компании Veeam, производителя решения номер 1 для резервного копирования виртуальных сред Veeam Backup and Replication, также есть свои стенсилы для Visio:

Там вы найдете следующие объекты:

• Хосты ESXi и Hyper-V
• Датацентры
• Объекты SCVMM
• Локальные и общие хранилища
• LUN
• Виртуальные машины и их статус (запущена, остановлена)
• Сетевые адаптеры (NIC)
• И многое другое

Этих двух наборов будет вполне достаточно, чтобы набросать простенькую схемку при планировании небольшой инфраструкутры.

Те из вас, кто давно следит за развитием технологий виртуализации, знают, что каждый год компания Gartner публикует "Magic Quadrant for x86 Server Virtualization Infrastructure", отражающий расклад сил в сфере серверной виртуализации.

Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

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

• Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
• Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
• Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
• Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.

В этом году квадрант выглядит так:

Что мы видим? Два явных лидера, VMware и Microsoft, и кучка лузеров, застенчиво сбившихся в тесный кут нишевых игроков. В хвосте уныло плетется Huawei. Кстати, не удивляйтесь новому названию Odin - это теперь так называется сервис-провайдерский бизнес Parallels (с продуктами Virtuozzo, Plesk и другими).

Ну а вот так выглядел квадрант Gartner в сфере серверной виртуализации в 2014 году:

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

Ну и для информации - квадранты прошлых лет (когда еще Citrix подавала надежды):

Таким образом, рынок серверной виртуализации, можно сказать, уже окончательно сформировался и его в чем-то можно сравнить с мобильным рынком: VMware - это Apple рынка виртуализации (дорого, но хорошо сделано), а Microsoft - это Google (дешево, но не понятно, куда тыкать и зачем). Хороша ли такая ситуация?

Интересный документ совместной разработки компаний Citrix и Amazon появился на блоге Citrix - "Citrix XenApp and XenDesktop 7.6 on Amazon Web Services Reference Architecture".

Это даже не совсем документ, а маленькая книга о том, как можно построить инфраструктуру доступа пользователей к виртуальным приложениям и ПК Citrix, размещенных частично или полностью в облаке Amazon EC2, с использованием технологии CloudFormation. Кстати, виртуальные ПК в Citrix XenDesktop можно создавать сразу в облаке с помощью Citrix Studio (технология и процесс подробно описаны тут).

Так вот, первый рассматриваемый в документе сценарий - это гибридная инсталляция, когда большинство сервисов компании работает on-premise (то есть, на собственной площадке), а инфраструктура Amazon используется для масштабирования сервисов, при пиковых нагрузках, а также как резервная инфраструктура в случае сбоя основной площадки. Ключевым компонентом здесь выступает NetScaler CloudBridge Connector, который создает оптимизированный для инфраструктур XenApp и XenDesktop VPN-туннель, а также обслуживает AWS availability zones (независимые зоны облачной инфраструктуры):

Второй вариант развертывания инфраструктуры Citrix XenApp и XenDesktop - это 100%-е использование облачных ресурсов Amazon для компаний, которым не требуется собственная инфраструктура (например, зачем турфирме свои серверы?). Здесь также ключевую роль играет NetScaler CloudBridge Connector, который обслуживает VPN. Все то же самое, но без своего оборудования (но нужен web-фронтэнд и cloud-совместимые приложения):

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

На самом деле, за такими штуками будущее, поэтому очень рекомендую этот документ.

Аналитическая компания Gartner опубликовала свой "Magic Quadrant for Cloud Infrastructure as a Service" за 2015 год. По-сути, этот квадрант отражает реальное состояние дел на рынке облачных решений и IaaS (инфраструктура как услуга, то есть аренда виртуальных машин). Конечно же, учитывались и решения PaaS/SaaS, но они на данный момент больше нишевые платформы (кроме Google) и, все-таки, в плане актуальности для пользователей идут вслед за IaaS.

Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

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

• Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
• Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
• Визионеры (visionaries) — поставщики с положительными оценками только по полноте видения.
• Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.

Собственно, сам квадрант:

Лидеры тут ожидаемы: с Амазоном все и так понятно, а вот Microsoft за последние пару лет приложила весьма серьезные усилия как в технологическом, так и в маркетинговом плане для продвижения своей платформы Azure, поэтому и попала в двойку лидеров.

Из квадранта нишевых игроков вы, наверняка, знаете только платформу Rackspace. Ну и надо отметить движение VMware в сектор визионеров, но ей очевидно мешает то, что платформа VMware vCloud Air - это все же больше Enterprise-продукт с ограниченной (на данный момент) географией датацентров.

Квадранты прошлых лет на эту же тему:

Компания VMware в своем блоге затронула интересную тему - обновление микрокода для процессоров платформ Intel и AMD в гипервизоре VMware ESXi, входящем в состав vSphere. Суть проблемы тут такова - современные процессоры предоставляют возможность обновления своего микрокода при загрузке, что позволяет исправлять сделанные вендором ошибки или устранять проблемные места. Как правило, обновления микрокода идут вместе с апдейтом BIOS, за которые отвечает вендор процессоров (Intel или AMD), а также вендор платформы (HP, Dell и другие).

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

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

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

Есть два способа обновить микрокод процессоров в ESXi - через установку VIB-пакета и через обновление файлов-пакетов микрокода на хранилище ESXi. Если вы заглянете в папку /bootbank, то увидите там такие файлы:

• uc_amd.b00
• uc_intel.b00

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

1. Скачиваем обновления микрокода.

Можно воспользоваться вот этими ссылками:

• Intel microcode download
• AMD microcode download

Для Intel выполните команду:

tar -zxf microcode-*.tgz

После распаковки вы получите файл microcode.dat. Это файл в ASCII-формате, его надо будет преобразовать в бинарный. У AMD в репозитории есть сразу бинарные файлы (3 штуки, все нужные).

2. Делаем бинарный пакет микрокода.

Создаем следующий python-скрипт и называем его intelBlob.py:

#! /usr/bin/python
# Make a raw binary blob from Intel microcode format.
# Requires Python 2.6 or later (including Python 3)
# Usage: intelBlob.py < microcode.dat microcode.bin

import sys

outf = open(sys.argv[1], "wb")

for line in sys.stdin:
if line[0] == '/':
continue
hvals = line.split(',')
for hval in hvals:
if hval == '\n' or hval == '\r\n':
continue
val = int(hval, 16)
for shift in (0, 8, 16, 24):
outf.write(bytearray([(val >> shift) & 0xff]))

Далее создаем бинарники микрокода. Для Intel:

cat intel/*.dat | ./intelBlob.py uc_intel
gzip uc_intel

Для AMD:

cat amd/*.bin > uc_amd
gzip uc_amd

3. Метод замены файлов с апдейтом микрокода.

Тут все просто. Выполним одну из следующих команд для полученных файлов:

• cp uc_intel.gz /bootbank/uc_intel.b00
• cp uc_amd.gz /bootbank/uc_amd.b00

Далее можно переходить к шагу 5.

4. Метод создания VIB-пакета и его установки.

Тут нужно использовать утилиту VIB Author, которую можно поставить на Linux-машину (на данный момент утилита идет в RPM-формате, оптимизирована под SuSE Enterprise Linux 11 SP2, который и предлагается использовать). Скачайте файл cpu-microcode.xml и самостоятельно внесите в него изменения касающиеся версии микрокода.

Затем делаем VIB-пакет с помощью следующей команды:

vibauthor -c -d cpu-microcode.xml \
-p uc_intel.gz,boot,uc_intel,200 \
-p uc_amd.gz,boot,uc_amd,201

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

Далее устанавливаем VIB через esxcli:

esxcli software acceptance set --level=CommunitySupported
esxcli software vib install \
-v file:/vmfs/volumes/datastore1/cpu-microcode-6.0.0-0.test.0.vib

Затем проверьте наличие файлов uc_*.b00, которые вы сделали на шаге 2, в директории /altbootbank.

5. Тестирование.

После перезагрузки хоста ESXi посмотрите в лог /var/log/vmkernel.log на наличие сообщений MicrocodeUpdate. Также можно посмотреть через vish в файлы /hardware/cpu/cpuList/*, в которых где-то в конце будут следующие строчки:

Number of microcode updates:1
Original Revision:0x00000011
Current Revision:0x00000017

Это и означает, что микрокод процессоров у вас обновлен. ESXi обновляет микрокод всех процессоров последовательно. Вы можете проверит это, посмотрев параметр Current Revision.

Также вы можете запретить на хосте любые обновления микрокода, установив опцию microcodeUpdate=FALSE в разделе VMkernel boot. Также по умолчанию запрещено обновление микрокода на более ранние версии (даунгрейд) и на экспериментальные версии. Это можно отключить, используя опцию microcodeUpdateForce=TRUE (однако микрокод большинства процессоров может быть обновлен только при наличии цифровой подписи вендора). Кроме того, чтобы поставить экспериментальный апдейт микрокода, нужно включить опции "debug mode" или "debug interface" в BIOS сервера, после чего полностью перезагрузить его.

Как многие из вас знают, одной из новых возможностей VMware vSphere 6.0 в плане хранилищ стала новая архитектура Virtual Volumes (VVols). VVols - это низкоуровневое хранилище для виртуальных машин, с которым позволены операции на уровне массива по аналогии с теми, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. Тома VVols создаются на дисковом массиве при обращении платформы к новой виртуальной машине (создание, клонирование или снапшот). Для каждой виртуальной машины и ее файлов, которые вы видите в папке с ВМ, создается отдельный VVol.

Между тем, поскольку технология VVol на сегодняшний день находится в первой своей релизной версии, а продуктов у VMware очень много, на сайте VMware появился список продуктов (в пункте 1 выберите Virtual Volumes), с которыми VVols работают, и тех, где поддержка еще не заявляена.

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

Продукты и технологии, которые поддерживают Virtual Volumes (VVols):

Продукты VMware:

• VMware vSphere 6.0.
• VMware vRealize Automation 6.2.
• VMware Horizon 6.1.
• VMware vSphere Replication 6.0
• VMware NSX for vSphere 6.x

Возможности платформы VMware vSphere 6.0:

• Storage Policy Based Management (SPBM)
• Thin Provisioning
• Linked Clones
• Native Snapshots
• View Storage Accelerator also known as Content Based Read Cache (CBRC)
• Storage vMotion
• vSphere Flash Read Cache
• Virtual SAN (VSAN)
• vSphere Auto Deploy
• High Availability (HA)
• vMotion
• xvMotion
• vSphere Software Development Kit (SDK)
• NFS version 3.x

Продукты и технологии, которые НЕ поддерживают Virtual Volumes (VVols):

Продукты VMware:

• VMware vRealize Operations Manager 6.x
• VMware vCloud Air
• VMware Site Recovery Manager 5.x to 6.x
• VMware vSphere Data Protection 5.x to 6.x
• VMware Data Recovery 2.x
• VMware vCloud Director 5.x

Возможности VMware vSphere 6.0:

• Storage I/O Control
• NFS version 4.1
• IPv6
• Storage Distributed Resource Scheduler (SDRS)
• Fault Tolerance (FT) + SMP-FT
• vSphere API for I/O Filtering (VAIO)
• Array-based replication
• Raw Device Mapping (RDM)
• Microsoft Failover Clustering (MSCS)

Отслеживать официальную поддержку VVols со стороны продуктов и технологий VMware можно в специальной KB 2112039. Там же, кстати, находится и полезный FAQ.

Для поиска совместимого с технологией VVols оборудования необходимо использовать VMware Compatibility Guide:

В феврале компания Red Hat сделала два весьма важных анонса. Во-первых, было объявлено о выходе новой версии платформы Red Hat Enterprise Virtualization 3.5 (напомним, что о RHEV версии 3.4 мы писали вот тут).

Список новых возможностей Red Hat Enterprise Virtualization 3.5:

• Поддержка до 4 ТБ памяти хост-сервера, до 4 ТБ памяти виртуальной машины (vRAM) и до 160 vCPU на виртуальную машину.
• Управление жизненным циклом хост-серверов и их развертыванием посредством интеграции с Red Hat Satellite.
• Оптимизация вычислительных мощностей за счет аналитики загрузки в реальном времени и интеграции с oVirt Optimizer. Это позволяет сбалансировать нагрузку на инфраструктуру при вводе в эксплуатацию новых виртуальных машин.
• Расширенная поддержка механизма non-uniform memory access (NUMA) - теперь появились такие фичи, как Host NUMA, Guest Pinning и Virtual NUMA. Все это увеличивает производительность за счет более быстрого доступа к нужным областям памяти.
• Улучшенный механизм Disaster Recovery за счет оптимизаций и поддержки миграции хранилищ между хранилищами (Storage Domains), что позволит партнерам Red Hat сделать ПО для восстановления после сбоев на уровне площадки на базе технологий и интерфейсов Red Hat.
• Лицензия Red Hat Enterprise Linux with Smart Virtualization, которая позволяет развертывать неограниченное количество систем Red Hat Linux.
• Подписка Red Hat Cloud Infrastructure, которая включает в себя следующие компоненты: Red Hat CloudForms, Red Hat Satellite, Red Hat Enterprise Linux OpenStack Platform и Red Hat Enterprise Virtualization.

Кроме того, в RHEV 3.5 появились дополнительные функции для интеграции с инфраструктурой Openstack:

• Интеграция с компонентами OpenStack Image Service (Glance) и OpenStack Networking (Neutron), доступная как технологическое превью, что позволяет администраторам управлять ресурсами хранения и сети из одной точки для всей инфраструктуры.
• Типы инстансов, которые заточены под развертывание виртуальных машин в онпремизной и офпремизной инфраструктуре (облаке).

Более подробно о новых возможностях Red Hat Enterprise Virtualization 3.5 можно почитать здесь.

Во-вторых, на днях была анонсирована платформа Red Hat Enterprise Linux OpenStack Platform 6, которая позволяет построить частное или публичное облако на базе платформы виртуализации Red Hat и открытой архитектуры OpenStack.

Новые возможности Red Hat Enterprise Linux OpenStack Platform 6:

• Поддержка IPv6, как для провайдерской сети, так и для сетей клиентов облака. IPv6 можно использовать как для физических сетей, так и для виртуальных роутеров OpenStack Networking (Neutron) в режимах stateless и stateful.
• Функции Neutron High Availability, которые позволяют настроить агенты Neutron в режиме "active-active" в целях обеспечения высокой доступности.
• Поддержка возможностей технологии Single root I/O virtualization (SR-IOV), а также новый драйвер, который позволяет имплементировать виртуальный коммутатор на стороне сетевой карты сервера, не создавая нагрузку на софт.
• Поддержка Multi-LDAP доменов, которые обслуживаются одним узлом со службами идентификации, что упрощает администрирование.
• Полная поддержка компонента для создания высокопроизводительных кластеров Sahara (ранее было технологическое превью), который позволяет обрабатывать нагрузки с big data.
• Более полная интеграция с блочными устройствами Ceph с новыми возможностями для компонентов OpenStack Compute (Nova) и OpenStack Block Storage (Cinder), включая полную поддержку бездисковых вычислительных узлов и функции почти мгновенного запуска виртуальных машин.
• Новые возможности в стадии технологического превью: bare metal provisioning (развертывание узлов без ПО) и поддержка механизма развертывания и обновлений TripleO.

Более подробно о новых функциях Red Hat Enterprise Linux OpenStack Platform 6 можно почитать на этой странице.

Как вы знаете, вчера компания VMware сняла эмбарго на освещение новых возможностей платформы виртуализации VMware vSphere 6.0, о которых мы писали вот тут (и тут). На блогах, посвященных технологиям виртуализации, появилось много разных статей о новых возможностях продукта, но нас больше всего заинтересовала технология непрерывной доступности VMware Fault Tolerance.

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

Теперь VMware Fault Tolerance в VMware vSphere 6.0 полноценно доступна для виртуальных машин с четырьмя vCPU и 64 ГБ оперативной памяти. И все это поддерживается в производственной среде.

Какие преимущества дает VMware FT в vSphere 6.0:

• Непрерывная доступность и полное сохранение данных ВМ в случае отказа хоста ESXi.
• При отказе не разрывается TCP-соединение.
• Срабатывание Fault Tolerance полностью прозрачно для гостевой системы.
• При сбое хоста происходит переключение на новую первичную ВМ, при этом на другом хосте автоматически поднимается новая резервная ВМ.

Что нового в Fault Tolerance 6.0:

• Теперь технология непрерывной доступности VMware Fault Tolerance поддерживает виртуальные машины с 4 vCPU и объемом памяти до 64 ГБ.
• Fast Check-Pointing - новая технология, предназначенная для поддержания исходного и резервного узла в синхронном состоянии, пришедшая на смену технологии "Record-Replay".
• Поддержка технологии горячей миграции как для Primary, так и для Secondary-узла.
• Возможность резервного копирования виртуальных машин, защищенных с помощью FT, технологией vStorage APIs for Data Protection. То есть, для таких ВМ теперь работет Veeam Backup and Replication.
• FT в vSphere 6.0 поддерживает новые типы дисков, такие как EZT, Thick или Thin Provisioned. Для vSphere 5.5 и более ранних поддерживаются только диски типа Eager Zeroed Thick.
• Возможность создания снапшотов виртуальных машин, защищенных FT.
• Новая версия FT поддерживает отдельные копии файлов ВМ (.vmx и .vmdk) для каждой машины, чтобы защитить машину не только от сбоев хоста, но и от сбоев хранилища, которые могут произойти одновременно со сбоем хоста. Файлы Primary и Secondary VM могут быть на разных виртуальных хранилищах.

Но по-прежнему, для Fault Tolerance остаются следующие ограничения:

• На хост ESXi можно иметь до 4 машин, защищенных технологией FT, при этом всего суммарно может быть защищено до 8 vCPU. Обратите внимание, что эти максимумы применяются суммарно к Primary и Secondary виртуальным машинам, расположенным на этом хосте.
• Обязательно потребуется адаптер 10 Gb. Его можно разделять между различными типами трафика средствами NetIOC.
• Нельзя использовать горячее добавление CPU или памяти для таких машин (Hot Add).
• Если несколько vCPU затронуто технологией FT, то для таких машин не поддерживается Storage vMotion.
• Кроме того, технику SMP-FT не поддерживают такие вещи, как vCloud Director, vSphere Replication, VSAN/vVols и vFlash.

Как и раньше, технология VMware HA полностью поддерживается:

Для наглядности есть вот такая табличка, описывающая отличия от предыдущей версии FT:

Надо понимать, что SMP-FT вызовет падение производительности гостевой ОС, по оценкам VMware - это около 10-30% в зависимости от нагрузки.

Ну и помните, что VMware Fault Tolerance на защитит от сбоя на уровне приложения - если он произойдет в основной ВМ, то будет и в резервной ВМ, поскольку машины синхронизированы на уровне исполнения инструкций в процессорах.