Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4680 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: PowerCLI Extensions теперь поддерживает PowerCLI 11.0

Облачная инфраструктура VMware vCloud on AWS - сколько это стоит?


Мы много пишем о публичном облаке VMware vCloud on AWS, появившемся в результате совместных усилий Amazon и VMware. Например, недавно рассказывали, что vCloud on AWS будет не только облачным сервисом, но и появится возможность разместить его на собственной площадке (on-premises).

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

Основная страница прайсинга на VMware vCloud on AWS находится вот тут:

https://cloud.vmware.com/vmc-aws/pricing

Здесь мы можем увидеть вот такие цены за хост ESXi с сервисами vSphere/vSAN/NSX в час (на самом деле, это от $7 в час, а цены ниже указаны для новых клиентов в течение 3 первых месяцев):

Если вы подпишете контракт на год, скидка будет 30%, если на 3 года - 50%.

На этой же странице ниже расположен калькулятор стоимости аренды IaaS-инфраструктуры vCloud on AWS, где можно посчитать примерную цену аренды хостов SDDC (2 CPU, 36 ядер, 512 ГБ оперативной памяти, флэш-хранилище NVMe: 3.6 ТБ кэш, плюс 10.7 ТБ сырой емкости для ВМ).

Для четырех хостов ESXi на месяц у меня получилась стоимость 30 тысяч долларов, что как-то слишком дорого:

На данный момент также существует 2 онлайн-сервиса, которые позволяют оценить затраты на IaaS-инфраструктуру VMConAWS с точки зрения стоимости владения за 3 года:

1. Базовый калькулятор стоимости владения: VMware Cloud on AWS and Microsoft Azure: A Hybrid Cloud TCO Comparison.

https://cloud.vmware.com/vmc-aws-tco-pricing/

В левой панели вводите число виртуальных машин (как в облаке, так и на собственной площадке под управлением VMC) и длительность контракта (год, 3 года или по мере использования) и получаете оценку затрат за 3 года в виде совокупной стоимости владения TCO (total cost of ownership), а также стоимость машиночаса. Это все подается еще и в сравнении со стоимостью владения ресурсами публичного облака Microsoft Azure (насчет точности конкурентных расчетов есть определенные сомнения):

2. Расширенный калькулятор стоимости владения: VMware Cloud on AWS Sizer and TCO.

https://vmcsizer.vmware.com/

В этом средстве расчета вы уже задаете профили рабочей нагрузки с их назначением, указываете число виртуальных машин с их параметрами (диск/профиль операций ввода-вывода, память, процессор) и получаете расчет совокупной стоимости владения с детальной разбивкой по статьям затрат, а также детальным описанием планируемой IaaS-инфраструктуры:

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

Кстати, для тех, кому интересно - вот детальный FAQ про сервис VMware vCloud on AWS от Amazon на русском языке: https://aws.amazon.com/ru/vmware/faqs/. Ну а вот подобный FAQ со стороны VMware, но уже на английском: https://cloud.vmware.com/vmc-aws/faq.

Кстати, пользователи продукта VMware vRealize Business for Cloud могут в нем провести обследование своей инфраструктуры для оценки затрат на содержание такой же облачной среды, но на стороне vCloud on AWS:


Таги: VMware, vCloud, AWS, Amazon, Pricing, Cloud

Как устроена цепочка сетевого стека VMware ESXi на уровне виртуального коммутатора - Network IOChain.


Недавно мы писали про то, как работает механизм регулирования полосы канала Network I/O Control (NIOC) в VMware vSphere, который позволяет приоритизировать различные типы трафика на одном сетевом адаптере, а сегодня взглянем на сам механизм прохождения трафика по уровням абстракции виртуального коммутатора изнутри.

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

IOChain обеспечивает связность виртуального коммутатора vSphere Standard Switch (VSS) или vSphere Distributed Switch (VDS) от групп портов на них к портам физических сетевым адаптеров (uplikns) в процессе передачи и обработки пакетов между этими сущностями. Для каждого из виртуальных коммутаторов есть 2 интерфейса IOChain (для входящего и исходящего трафика). Это дает большую гибкость по настройке политик каналов трафика Ingress и Egress.

Примерами таких политик служат поддержка сетей VLAN, механизма группировки NIC teaming и шейпинг трафика (traffic shaping). Работают эти политики на трех уровнях абстракции (в порядке следования от виртуальной машины):

  • Группа портов виртуального коммутатора (port group).

На этом уровне работает фильтрация VLAN, а также политики безопасности, такие как Promiscuous mode, MAC address changes и Forged transmits. Пользователи также могут настроить политики шейпинга исходящего трафика (для VSS) или в обоих направлениях (только для VDS).

  • Обычный или распределенный виртуальный коммутатор (VSS или VDS).

Основная задача этого уровня - направлять пакеты к нужному порту (аплинку), через которые они достигнут адреса назначения. Он оперирует MAC-адресами источника и назначения, а также определяет, отдавать ли трафик локально (в рамках одного или нескольких виртуальных коммутаторов на хосте), либо перенаправлять его к уровню аплинка хоста ESXi.

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

  • Порт (uplink).

Этот уровень отвечает за передачу трафика к драйверу сетевого адаптера. На этом уровне работают функции hardware offloading, облегчающие работу с обработкой пакетов за счет ресурсов сетевой карты. Доступные возможности hardware offloading зависят от конкретной модели карты и ее драйвера. Примерами таких возможностей являются TCP Segment Offload (TSO), Large Receive Offload (LRO) и Checksum Offload (CSO). Также здесь обеспечивается поддержка оверлейных протоколов VXLAN и Geneve, которые используются в решениях NSX-v и NSX-T соответственно (эта поддержка есть во многих современных сетевых картах).

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

Для обычного виртуального коммутатора (VSS) схема прохождения трафика через уровни абстракции IOChain выглядит так:

Если же у вас распределенный виртуальный коммутатор VDS, то вы можете использовать механизм Network I/O Control (NIOC) для резервирования и приоритизации трафика внутри канала аплинков. Также VDS предоставляет множество дополнительных возможностей, таких как LBT (Load Balanced Teaming) и LACP (Link Aggregation Control Protocol).

В случае с VDS схема с IOChain выглядит следующим образом:

 

Обратите внимание, что на этой диаграмме есть дополнительный модуль DVfilter. Это API-фреймворк, который есть в VDS и требуется для работы решения NSX. Когда компоненты NSX устанавливаются в ядро ESXi, они взаимодействуют с трафиком именно через этот модуль.

С помощью команды summarize-dvfilter можно вывести все загруженные агенты DVfilter и фильтры. Вот так это выглядит без установленного решения NSX:

Если вы посмотрите информацию по компонентам NSX, когда он установлен, то увидите модули nxst-switch-security, nsxt-vsip и nsxt-vdrb.

Вообще, весь стек IOChain является модульным, что позволяет добавлять новую функциональность его компонентов на различных уровнях абстракции. Например, компоненты DVfilter разделяются на Fastpaths, Slowpaths и Filters:

  • Fastpaths – фильтры трафика на уровне ядра ESXi.
  • Slowpaths – интеграция со сторонними продуктами для сетевой инфраструктуры.
  • Filters – размещение фильтров в слоты для каждого из подходящих по модели сетевых адаптеров vNIC.

В VMware vSphere 6.7 в стеке IOChain появилось несколько улучшений, таких как поддержка MAC learning и функции IGMP snooping через интерфейс VNI (Virtual Network Interface), которые могут быть использованы в будущем.

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


Таги: VMware, Networking, ESXi, VDS, VSS, VMachines

Как работают политики Storage Policy Based Management (SPBM) для томов Virtual Volumes (VVols) в инфраструктуре VMware vSphere.


Недавно мы писали о политиках хранилищ Storage Policy Based Management (SPBM) на базе тэгов, которые помогают использовать возможности платформы VMware vSphere для назначения виртуальным машинам хранилищ на томах VMFS/NFS с разными характеристиками, который работает на уровне отдельных виртуальных дисков.

Сегодня мы поговорим о политиках SPBM для виртуальных томов VVols на хранилищах, которые предоставляют различные возможности через интерфейс VASA (vSphere APIs for Storage Awareness). Механизм VASA реализуется производителем дисковой системы (storage provider) на программно-аппаратном уровне, при этом дисковый массив полностью отвечает за использование его возможностей, а со стороны vSphere возможно только управление ими средствами механизма SPBM.

Через интерфейс VASA Provider устройство хранения сообщает платформе vSphere, какие сервисы оно предоставляет, а через административный том на хранилище Protocol Endpoint (PE) происходит процессинг операций ESXi с массивом:

К таким возможностям в общем случае относятся:

  • Шифрование
  • Дедупликация данных на массиве
  • Репликация данных внутри массива и на другие массивы
  • Функции уровня обслуживания QoS (ограничения по IOPS и Latency)
  • Выбор яруса хранения / типа дисков (регулирование уровня производительности)

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

Самое приятное в использовании механизма SPBM для хранилищ на основе VVols в том, что вам не требуется заботиться о томах LUN, дисковых группах и настройке их параметров - массив сам распорядится размещением данных по ярусам (Tiers) и датасторам, а также обеспечением уровня их производительности (Service levels).

Например, вот так просто выглядят правила (Rules) для первичного размещения виртуальных машин на массиве EMC Unity при выборе уровня обслуживания и производительности для новой политики SPBM:

 

В массивах может быть также реализован QoS в зависимости от критичности приложения (Mission Critical приложения всегда первыми получат ресурсы ввода-вывода):

Некоторые хранилища, например, HPE Nimble, могут предоставлять сразу большое число сервисов, для каждого из которых можно настроить свои правила:

Хранилище может предоставлять не только правила размещения виртуальных машин и обеспечения их функционирования, но и сервисы репликации, как например у Pure Storage (они позволяют, в том числе, настроить репликацию на уровне отдельных VMDK дисков машин):

Также создание политик SPBM для томов VVols можно посмотреть на видео ниже:

А вот так применяются политики SPBM, включая сервисы репликации:


Таги: VMware, SPBM, Storage, vSAN, VVols

Апгрейд распределенного виртуального коммутатора (vSphere Distributed Switch) при обновлении VMware vSphere.


Когда вы обновляете виртуальную инфраструктуру VMware vSphere, нужно также подумать и об обновлении виртуального коммутатора (vSphere Distributed Switch, VDS), который, в зависимости от версии, предоставляет те или иные возможности.

Если вы хотите обновить VMware vSphere 5.5 на последнуюю версию VMware vSphere 6.7 Update 1, то, как вы уже знаете, прямого апгрейда нет. Вам нужно будет обновиться на одну из версий - vSphere 6.0 или 6.5 - и потом уже накатить апгрейд до версии 6.7.

В этом процессе есть нюанс - если вы обновитесь с 5.5 на 6.x, то вам надо будет обновить и Distributed Switch, до того, как будете проводить апгрейд на версию 6.7. В противном случае процесс обновления до версии 6.7 завершится неудачно.

Обновить распределенный коммутатор очень просто: в vSphere Client нужно зайти в Networking, выбрать там ваш VDS-коммутатор и на вкладке "Summary" кликнуть на ссылку, где написано "Upgrades available":

Чтобы запустить процесс обновления VDS, нужно в меню "Actions" выбрать пункт "Upgrade":

В процессе обновления вам предложат выбрать версию VDS, если кликнуть на иконку <i>, то можно узнать какие фичи предоставляют соответствующие версии:

Обратите внимание, что соответствие версий VDS версиям vSphere следующее:

  • vSphere 6.0 = VDS 6.0
  • vSphere 6.5 = VDS 6.5
  • vSphere 6.7 = VDS 6.6 (да, вот так странно)

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

И еще вам может оказаться полезной информация о потенциальных проблемах при обновлении на VDS 6.6, описанная в KB 52621.


Таги: VMware, vSphere, VDS, Upgrade, Networking

Новое на VMware Labs: Android Device Pre-Verification Suite.


На сайте проекта VMware Labs появилась очередная полезность, на этот раз для пользователей инфраструктуры Workspace ONE. С помощью утилиты Android Device Pre-Verification Suite пользователи и партнеры VMware могут проверить Android-устройство (телефон/планшет/rugged device) на предмет предварительного соответствия условиям device verification program.

Проведение такой предварительной проверки уменьшает время включения устройств в инфраструктуру Workspace One Intelligent Hub (device verification program).

Для работы теста на телефоне должен быть установлен агент Workspace One Intelligent Hub (ранее он назывался Android Agent), который можно поставить из Google Play или с компьютера.

Более подробно об утилите Android Device Pre-Verification Suite можно почитать в документации. Скачать ее можно по этой ссылке.


Таги: VMware, Labs, Workspace ONE, Android, Google, Mobile

Вышел VMware Horizon 7.7 - новые возможности платформы виртуализации настольных ПК предприятия.


Спустя всего 3 с небольшим месяца с момента анонса на конференции VMworld 2018 платформы для создания инфраструктуры виртуальных десктопов VMware Horizon 7.6, компания VMware выпустила обновление этого продукта - Horizon 7.7, включая обновленные клиенты Horizon Client 4.10.

Давайте посмотрим, что нового появилось в различных компонентах этого решения:

Улучшения совместимости и поддержка новых ОС

  • Поддержка Windows Server 2019 для серверов виртуальных десктопов и RDSH.
  • Поддержка последних версий VMware vSphere 6.7 U1 и VMware vSAN 6.7 Update 1.
  • Поддержка облачного решения Horizon 7 on VMware Cloud on AWS (SDDC версии 1.5), включая все его новые возможности.
  • Теперь апгрейды можно запускать через виртуальный модуль Horizon 7 Cloud Connector. Этот appliance используется для интеграции служб Horizon Cloud Service с компонентами Horizon 7 на площадках заказчиков и VMware Cloud on AWS.
  • Пакет VMware Virtualization Pack for Skype for Business теперь может быть использован в окружении IPv6.
  • Клиенты Horizon Clients теперь включают поддержку последних операционных систем, таких как macOS 10.14 (Mojave) и Android 9.1.

Улучшения консоли Management Console

Новая Horizon Console (на базе HTML5) получила несколько улучшений:

  • Теперь можно добавлять пулы Manual и View Composer linked-clone, а также добавлять, отключать, изменять и удалять персистентные диски для связанных клонов.
  • На вкладке Machines можно быстро понять, когда кто-либо, кроме назначенного пользователя, заходил в виртуальную машину. Теперь есть 2 колонки: Connected User и Assigned User (фича также доступна в Horizon Administrator).

  • Старый Horizon Administrator в дэшборде System Health отображает детали о зарегистрированных модулях VMware Unified Access Gateway для версии 3.4 и более поздних:

  • Имя узла Connection Server pod теперь есть в верхней панели, рядом с заголовком:

  • Улучшение Help Desk Tool - администраторы теперь могут завершить процесс приложения для выбранного пользователя. База данных событий записывает это действие, включая такие детали, как дата и время, имя десктопа и название приложения, название пула и имя администратора.

Улучшения масштабируемости

  • Можно использовать один экземпляр vCenter Server для нескольких POD в архитектуре CPA (Cloud Pod Architecture).
  • Максимальное число серверов одной фермы RDSH было увеличено с 200 до 500.
  • Была введена поддержка vMotion для пулов linked-clone и automated, которые содержат также и полные виртуальные машины.
  • Поддержка vMotion была также добавлена для полных клонов с поддержкой vGPU, мгновенных клонов и связанных клонов.

Улучшения безопасности и надежности

  • Новая возможность аудита буфера обмена позволяет агентам Horizon Agent записывать информацию об активностях операций copy и paste между клиентом и агентом в журнал событий на машине агента.
  • Можно добавить устройство Virtual Trusted Platform Module (vTPM) к пулу десктопов instant-clone и удалить vTPM уже после операции по созданию образа.
  • Протокол TLS 1.0 теперь отключен по умолчанию на всех клиентах.

Улучшения User Experience

  • Улучшения протокола Blast Extreme:
    • Теперь можно использовать протокол Blast Extreme для доступа к физическим компьютерам и рабочим станциям.
    • Для Windows-клиентов протокол кодирования видео Blast Extreme HEVC (H.265) позволяет ужимать почти в два раза эффективнее чем раньше (при том же качестве), либо улучшать качество на той же самой полосе, как и H.264. Также добавлена поддержка режима 8K. Это требует окружения NVIDIA GRID с аппаратными кодировщиками NVIDIA и клиентов, железо которых поддерживает декодирование HEVC.
  • Улучшения Windows-клиентов:
    • Если включена возможность client-drive redirection, пользователи могут перетаскивать файлы и папки между клиентской системой и удаленными десктопами или опубликованными приложениями. Например, можно перетащить несколько графических файлов в опубликованное приложение (например, закинуть аттач в почтовый клиент).
    • Новая возможность VMware Virtual Print позволяет пользователю печатать на любом Windows-компьютере (она делает то же самое, что и ThinPrint ранее). Но, помимо этого, VMware Virtual Print поддерживает перенаправление принтеров клиента, а также location-based printing. Настройки сохраняются на уровне пользователей.
  • Улучшение опубликованных приложений и десктопов RDSH:
    • Режим multi-session mode, который позволяет администратору задать правило - можно ли пользователю открывать несколько сессий к одному приложению с различных устройств. Требует Horizon Client 4.10.
    • На Windows-клиентах пользователю можно назначить приложение RDSH для отображения на одном мониторе или на наборе из нескольких экранов.
    • Новая возможность hybrid logon может быть использована с функцией доступа для неавторизованных пользователей. Она позволяет неаутентифицированным пользователям, но с доступом к домену, получить доступ к сетевым ресурсам (файловые шары, принтеры), без ввода данных учетной записи домена. Требует Horizon Client 4.10.

Улучшения работы публичного облака VMware Cloud on AWS (SDDC версии 1.5)

  • Минимально требуемый размер кластера vSphere был уменьшен до 3 узлов. Также поддерживаются "растянутые" кластеры (stretched clusters).
  • Поддержка технологий VMware NSX-T network virtualization и VMware vSAN datastore encryption.
  • Поддержка технологий Horizon 7 издания Enterprise Edition: VMware User Environment Manager, VMware App Volumes и техники VMware Instant Clone.

Улучшения и новые возможности VMware Horizon 7 for Linux

  • Десктопы Linux теперь поддерживаются в инфраструктуре Horizon 7 on VMware Cloud on AWS.
  • Режим Single sign-on (SSO) теперь поддерживается для десктопов SLED/SLES 12.x.
  • Аудиовход теперь поддерживается для десктопов SLED/SLES.
  • Плавающий пул десктопов Instant clone теперь доступен при использовании SLED/SLES .
  • Функция session collaboration доступна при использовании Linux-десктопа. Теперь можно приглашать других пользователей присоединиться к удаленной сессии.
  • Десктопы Instant clone на базе Linux теперь позволяют офлайновое присоединение к домену Active Directory через Samba.

Более подробная информация о VMware Horizon 7.7 приведена по этой ссылке. Также здесь можно почитать документацию о VMware Horizon Clients, а вот тут написано про новые возможности Unified Access Gateway 3.4.

Компоненты VMware Horizon 7.7 доступны для загрузки уже сейчас по этой ссылке.


Таги: VMware, Horizon, Update, VDI, RDSH

Сценарии отказов компонентов дисковой подсистемы кластера VMware vSAN - APD и PDL.


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

Как известно, дублирование дисковых компонентов и объектов в кластере vSAN зависит от политики Failures to tolerate (FTT) и уровня RAID, заданного для политики, которой подчиняется виртуальная машина:

Если для машин хоста задана политика с FTT=1 и RAID-1, то в общем случае, при отказе хоста ESXi, через 60 минут начинается ресинхронизация его дисковых объектов на других хостах, чтобы обеспечить выполнение политики FTT.

В случае сбоя какого-либо из компонентов дисковой подсистемы хранения кластера (от диска до хоста) механизм vSAN делит характер сбоя на 2 состояния: APD (All Paths Down) и PDL (Physical Device Loss). Об этих состояниях мы подробно писали вот тут.

  • APD (All Paths Down) - когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. Это состояние считается временным и также называется "absent". Иными словами, мы не знаем, что случилось с устройством, может быть оно будет доступно в будущем. В этом случае vSAN не начинает сразу восстановление дисковых компонентов и объектов, а ждет 60 минут, чтобы не тратить напрасно ресурсы в случае, если устройство снова станет доступно. Время до начала восстановления можно регулировать настройкой Object Repair Timer, о которой мы детально писали вот тут
  • PDL (Physical Device Loss) - состояние, когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось. Определяется это, в частности, по коду ответа для SCSI-команд, например, вот такому: 5h / ASC=25h / ASCQ=0 (ILLEGAL REQUEST / LOGICAL UNIT NOT SUPPORTED) - то есть такого устройства на массиве больше нет. Этот статус считается постоянным и также называется "degraded". В этом случае кластер vSAN сразу начинает восстановление дисковых объектов, несмотря на значение Object Repair Timer. Примером таких состояний является выход из строя дискового массива или его части, поломка HBA/RAID-контроллера и т.п.

Давайте посмотрим, как именно реагирует кластер vSAN на различные варианты отказов и поломок дисковой подсистемы в кластере:

Сценарий отказа  Поведение vSAN  Воздействие на ВМ и поведение HA
Отказ диска в группе кэширования Дисковая группа помечается как "failed", и все ее компоненты перестраиваются на другой дисковой группе (rebuild). ВМ продолжат работать
Отказ диска с данными (функции Dedupe и Compression включены) Дисковая группа помечается как "failed", и все ее компоненты перестраиваются на другой дисковой группе (rebuild). ВМ продолжат работать
Отказ диска с данными (функции Dedupe и Compression отключены

Диск помечается как "failed", и все его компоненты перестраиваются на другом диске группы (rebuild).

ВМ продолжат работать
Отказ дисковой группы Все компоненты группы перестраиваются на другой дисковой группе (rebuild). ВМ продолжат работать
Отказ контроллера RAID/HBA-карточки

Все дисковые группы под контролем карточки HBA/RAID будут помечены как absent и будут перестроены на других дисковых группах (rebuild).

ВМ продолжат работать
Отказ хоста или изоляция хоста

Компоненты на хосте будут помечены как absent и через 60 минут, если хост не вернется в онлайн, будут признаны устаревшими с последующим удалением (stale) после начал процесса перестроения дисковых объектов этого хоста (rebuild).

ВМ других хостов продолжат работать, ВМ этого хоста будут перезапущены HA на других хостах.

А вот графическая иллюстрация того, что происходит через 60 минут в кластере при отказе хоста ESXi. Обратите внимание, что если хост появится снова онлайн после сбоя и начала ресинхронизации (>60 минут) - его дисковые компоненты будут признаны "stale" и удалены механизмом vSAN, чтобы использовать его дисковое пространство в полном объеме.


Таги: VMware, vSAN, HA, Storage, VMachines

Гиперконвергентная инфраструктура (HCI) конца 2018 года - магический квадрант Gartner.


Недавно компания Gartner выпустила Magic Quadrant for Hyperconverged Infrastructure (HCI) за 2018 год, посвященный средствам создания гиперконвергентной инфраструктуры. Это такая среда, которая позволяет объединить вычислительные ресурсы, системы хранения и сети с помощью технологий виртуализации и собрать все компоненты в единую интегрированную сущность, которая управляется из одной точки.

Напомним, что об этом квадранте мы уже писали в начале года, и с тех пор кое-что изменилось:

Вот как было в январе этого года:

Главным лидером рейтинга, как и прежде, сейчас признана компания Nutainx - производитель продуктов для создания гиперконвергентной среды. Сейчас Nutanix поставляет как чисто программные решения (в виде виртуальных модулей), так и программно-аппаратные комплексы (партнерские решения Lenovo, Dell EMC, Fujitsu и IBM). Помимо этого, Nutanix в рамках раннего доступа запустила и облачный сервис для своих HCI-решений.

Несмотря на то, что VMware - это производитель только программных решений, она попала в сегмент лидеров вполне заслуженно. У VMware в последние годы было выпущено очень много того, что относится к HCI - например, сейчас компания поддерживает более 500 моделей серверов в рамках программы ReadyNode для построения кластеров vSAN.

Также VMware поддерживает инициативу VMware Cloud Foundation (VCF), о которой мы много писали в последнее время. Архитектура VCF включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия, которые желательно развертывать все вместе, но можно какие-то и опустить.

Ну и, конечно же, в последнее время VMware делает очень много усилий по продвижению гибридной среды VMware Cloud on AWS, которая будет доступна не только из облака, но и в частной инфраструктуре предприятий (Amazon Outposts).

Родительская компания VMware - Dell EMC - в этом квадранте занимает высокое место благодаря решениям VxRail и VxRack, в состав которых, кстати, входит продукт для создания кластеров отказоустойчивых хранилищ vSAN.

Обратите внимание, что существенный прогресс наблюдается у Cisco - из сегмента челенджеров она переместилась в лидеры. Прежде всего, это случилось благодаря доработке платформы Cisco HyperFlex, котора интегрирует в себе архитектуру Cisco Unified Computing System (UCS), сочетающую в себе продукты Network Fabric, управляющую облачную консоль Intersight, сторонний гипервизор (например, ESXi), а также платформу для управления хранилищами и данными HX Data Platform (разработанную компанией Springpath, которую Cisco купила в сентябре 2017 года).

О магических квадрантах Gartner

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

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

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

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

Таги: Gartner, HCI, Enterprise, VMware, Cisco, Nutanix, Dell, Hardware

Политики хранилищ SPBM (Storage Policy Based Management) на базе тэгов в кластере VMware vSAN.


Мы уже упоминали о политиках хранилищ SPBM, (Storage Policy Based Management) в кластере VMware vSAN, которые представляют собой очень гибкий механизм для выделения виртуальным машинам хранилищ с разными характеристиками, который работает на уровне отдельных виртуальных дисков.

Политики SPBM разделяются на 3 основных области:

  • Storage Capabilities and Services - это политики, которые работают, когда хранилище vSAN или VVols представлено через интерфейс VASA производителем дисковой подсистемы (storage provider). Через VASA это устройство сообщает, какие сервисы оно предоставляет.
  • Data Services - это политики, настраиваемые на уровне хоста ESXi, они также реализуются на стороне дискового устройства (storage provider). Эти политики не определяют размещение виртуальных машин, но влияют на их возможности, например, использование шифрования или механизма SIOC.
  • Tags - это политики, которые используются хранилищами, которые не предоставляют каких-либо специфических функций, как правило - это обычные тома VMFS и NFS традиционных дисковых массивов без поддержки VASA.

В этой статье мы рассмотрим использование таких объектов, как тэги (Tags) и категории (Categories). Они могут оказаться полезными, когда вы хотите высокоуровнево определить параметры размещения и конфигурации виртуальных машин и их дисков на хранилищах, хостах, кластерах или в других объектах виртуальной инфраструктуры.

Поддержка правил на базе тэгов определяется при создании политики:

С помощью тэгов можно задать ярусы размещения ВМ, конфигурации дисков и их расположение, тип ОС, департамент, к которому принадлежит ВМ, тип дисков SAS/SATA/SSD и многое другое. Вот какие аспекты размещения внутри объектов виртуальной инфраструктуры можно контролировать через категории и тэги:

Например, вы хотите сделать так, чтобы виртуальные машины с гостевой ОС Linux попадали на определенные хранилища. В этом случае надо создать категорию "OS" для объектов Datastore и Datastore Cluster и тэг "Linux", который надо назначить заданным хранилищам. После этого машины с таким тэгом при выборе соответствующей политики SPBM будут попадать на заданные стораджи.

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

В рамках одной политики можно использовать до 128 тэгов - это излишне, но если у вас есть фантазия, то вы можете использовать их все) Например, вы можете использовать категорию Department для отдела, а внутри создать тэги для всех отделов: Financial, HR, Engineering и т.п.

Категории и тэги можно использовать для разных аспектов конфигураций хранилищ. Например, тип ОС или тип дисков, на которых размещены ВМ (Category: Disk Type, Tag: SAS).

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

Весь этот процесс показан на видео ниже:

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

Политики SPBM можно использовать не только отдельно для томов VMFS и NFS, но и для инфраструктуры vSAN и VVols, которые регулируются политиками на уровне хостов (host-based services). Например, можно создать политику, которая позволяет виртуальной машине использовать тома VVols, но только в определенном физическом размещении. Таким образом, с помощью провайдера VASA вы выбираете storage capability как VVols, а с помощью тэгов - физическое размещение ВМ.

Вот как это работает при создании политики:

С помощью PowerCLI вы можете получить информацию о виртуальных машинах или хранилищах, тэгированных определенным тэгом. Вот пример команды для ВМ:

Get-VM -Tag Windows
Name PowerState Num CPUs MemoryGB
---- ------- -------- --------
Windows-VMFS-VM PoweredOff 1 4.000
Win10-3 PoweredOn 2 4.000
jm-ws2016 PoweredOn 2 4.000
Win10-2 PoweredOn 2 4.000

И для хранилища:

Get-Datastore -Tag California
Name FreeSpaceGB CapacityGB
---- --------- ----------
N-VVol-Cali 2,048.000 2,048.000

При использовании механизмов размещения SPBM можно задавать уровень возможности их нарушения (Enforcement). Об этом вы можете прочитать в KB 2142765.

Несколько полезных ресурсов про политики SPBM:


Таги: VMware, SPBM, Storage, VMFS, NFS, VVols, vSAN, VMachines, Blogs

Использование командлета Get-ErrorReport для сбора диагностической информации VMware PowerCLI при ошибках и решения проблем с помощью технической поддержки.


Многие из вас используют фреймворк VMware PowerCLI для автоматизации операций в виртуальной инфраструктуре (см. статьи нашего автора Романа Гельмана). Между тем, не все знают, что PowerCLI - это точно такой же поддерживаемый продукт VMware, как и все остальные, с точки зрения обращений в техническую поддержку. То есть, если вы обнаружили некорректное поведение скрипта PowerCLI и не можете выяснить причину - то имеет смысл открыть Support Ticket.

Но чтобы инженеры VMware получили всю необходимую диагностическую информацию, часто оказывается недостаточно сгенерировать support-бандлы для хоста ESXi или сервера vCenter. Иногда нужно залезть глубже, чтобы получить информацию об API-вызовах, например, с помощью инструментов Fiddler или Wireshare.

Но можно сделать все гораздо проще - есть командлет Get-ErrorReport, который соберет для вас всю необходимую диагностическую информацию об ошибке и добавит ее в zip-пакет для отправки как вложения support-тикета. Давайте вызовем ошибку, к примеру, известную проблему PowerCLI, которая возникает при попытке переместить виртуальную машину с помощью Move-VM в виртуальный сервис vApp:

$appsvr = Get-VM -Name appsvr02
$vapp = Get-VApp -Name DemovApp
Move-VM -VM $appsvr -Destination $vapp

Ошибка будет такой:

Move-VM : 11/14/2018 1:12:31 PM Move-VM         A specified parameter was not correct:
PlacementSpec.relocateSpec.pool

Чтобы получить support бандл для этой ошибки, нужно использовать командлет, у которого есть следующие параметры:

  • Destination - директория назначения результирующего бандла.
  • IncludeServerLogs - нужно ли вытягивать логи с сервера, к которому мы подключены.
  • ProblemDescription - описание проблемы для технической поддержки.
  • ProblemScript - участок скрипта, который вызывает ошибку.

Таким образом, давайте попробуем вызвать командлет Get-ErrorReport:

$errorCode = {
$appsvr = Get-VM -Name appsvr02
$vapp = Get-VApp -Name DemovApp
Move-VM -VM $appsvr -Destination $vapp
}
Get-ErrorReport -ProblemScript $errorCode -Destination .\Documents\ -ProblemDescription "Using Move-VM to place a VM into a vApp"

Результатом работы сценария будет саппорт-бандл PowerCLI, лежащий в заданной папке:

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

  • PowerCLI-Main-Log.svclog
  • Powershell-Debug-Stream.txt
  • Powershell-Error-Stream.txt
  • Powershell-Info-Stream.txt
  • Powershell-Verbose-Stream.txt
  • Powershell-Warning-Stream.txt

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

Кстати, файл с расширением *.svclog можно открыть с помощью инструмента Microsoft Service Stack Trace Viewer. В данном случае мы там увидим, что API-сервис вернул ошибку internal server error с кодом 500:

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


Таги: VMware, PowerCLI, Support

Обновленная книга Upgrading to VMware vSphere 6.7 доступна для скачивания.


В начале года мы рассказывали о книге Upgrading to VMware vSphere 6.5, которая описывала процедуры апгрейда платформы виртуализации на версию 6.5. С тех пор были выпущены обновления vSphere 6.7 и 6.7 Update 1, поэтому документ потерял актуальность.

В связи с этим VMware выпустила обновленную книгу Дэвида Стамена (David Stamen) Upgrading to VMware vSphere 6.7, которая стала доступна для скачивания на днях:

В обновленную версию также включены все нововведения последних версий продуктов Site Recovery Manager и Horizon, которые работают в инфраструктуре vSphere. С точки зрения основной платформы, рассматриваются сценарии апгрейда с vSphere 6.0 и 6.5.

В книге процесс обновления разбит на три фазы:

  • Фаза 1: Pre-upgrade – обозначает фронт работ и требований, которые должны быть выполнены перед началом процедуры апгрейда.
  • Фаза 2: Upgrade – описание шагов процесса обновления и иллюстрация их исполнения.
  • Фаза 3: Post-Upgrade – валидация результата в соответствии с изначально поставленными целями.

Скачать книгу Upgrading to VMware vSphere 6.7 можно по этой ссылке.


Таги: VMware, vSphere, Upgrade, Book

Режим обслуживания хостов кластера VMware vSAN Maintenance Mode - как это работает?


Как знают многие пользователи решения для создания отказоустойчивых кластеров VMware vSAN, в данном продукте есть возможность перевода хоста в режим обслуживания (Enter Maintenance Mode, EMM), который позволяет вывести его на время из эксплуатации с сохранением работоспособности кластера в целом. При этом происходит взаимодействие vSAN и механизма балансировки нагрузки VMware vSphere Distributed Resource Scheduler (DRS), который эвакуирует виртуальные машины с хоста ESXi.

Давайте посмотрим, как работает EMM для кластера vSAN, и какие есть опции для данной процедуры. Чтобы перевести хост ESXi в режим обслуживания, надо нажать на него правой кнопкой в vSphere Client и выбрать пункт Maintenance Mode > Enter Maintenance Mode.

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

  • Full Data Migration – это миграция всех компонентов дисковых объектов на другие хосты кластера.
  • Ensure Accessibility – это миграция только тех компонентов, которые есть в кластере в единственном экземпляре. При этом, для некоторых объектов в этом случае не будет соблюдена политика Failures to tolerate (FTT).
  • No Data Migration – в этом случае никакие компоненты не будут перемещены с хоста, поэтому некоторые ВМ могут оказаться недоступными (если на этом хосте их дисковые компоненты находятся в единственном экземпляре, а уровень RAID недостаточен для предоставления доступа к объекту).

С первым пунктом (Full Data Migration) все ясно - он вызывает долговременную процедуру миграции всех дисковых объектов и не всегда оправдан, когда хост ESXi нужно погасить лишь ненадолго. Но если вы выводите хост ESXi из эксплуатации производственного кластера (либо останавливаете, например, на несколько дней), то нужно выбирать именно Full Data Migration.

Давайте подробнее рассмотрим вариант Ensure Accessibility, который как раз подходит для кратковременного обслуживания хоста и последующего его повторного ввода в эксплуатацию. Если у вас достаточно запаса дисковых ресурсов, и виртуальные диски машин работают в RAID-1, то копии дисковых объектов переводимого в режим обслуживания хоста должны быть на других серверах. На картинке ниже реплика объекта C1 есть на другом хосте, поэтому в режиме Ensure Accessibility никаких миграций данных производиться не будет, кластер продолжит работать в режиме полной производительности:

Если же у вас, например, задана политика кластера FTT=1 на четырех хостах, и компоненты дисковых объектов хранятся в соответствии с политикой RAID-5, то картина будет следующей:

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

Между тем, если vSAN object manager будет наблюдать ситуацию несоответствия политики надежности более чем 60 минут (см. параметр Object repair timer в конце статьи), то он, все-таки, запустит синхронизацию дисковых объектов, чтобы их конфигурация в итоге соответствовала действующим политикам.

Кстати, обратите внимание, что такое поведение кластера vSAN - это одна из причин, почему VMware Update Manager не делает обновление хостов ESXi кластера vSAN в параллельном режиме, а проводит это последовательно. Ведь если бы это происходило параллельно, не факт, что можно было бы выполнить требования опции Ensure Accessibility, а также происходило бы много миграций дисковых компонентов.

Кроме того, перед переходом в режим обслуживания хоста, EMM делает полную симуляцию перемещений данных, которые будут проведены в процессе выключения хоста. Например, у нас есть 3 виртуальные машины: vm01 с политикой RAID-0 (без избыточных копий данных), а также машины vm02 и vm03 в режиме RAID-1 (зеркало).

Обратите внимание на картинку ниже:

Здесь показано, что в соответствии с вариантом No data migration 3 дисковых объекта виртуальной машины vm01 окажутся недоступными, а 30, относящихся к vm02 и vm03, не будут соответствовать действующей политике по обеспечению надежности.

Если мы нажмем на ссылку See detailed report, то увидим подробную картину симуляции EMM:

То есть, vm01 окажется недоступной, а vm02 и vm03 будут Non-compliant, пока хост находится в режиме обслуживания.

Если же вы выберете вариант Ensure Accessibility, то прогноз будет следующим:

440 МБ дисковых объектов, относящихся к vm01 будут перемещены, а 30 объектов не будут соответствовать политике, при этом все ВМ останутся доступными. Также в VMware vSAN 6.7 Update 1 появились новые предупреждения о том, что в кластере есть активные процессы синхронизации, а также переходящие или уже перешедшие в режим обслуживания хосты ESXi.

Ну и напомним о настройке Object Repair Timer, которую мы детально рассматривали вот тут. Она то, как раз, и позволяет вам расширить окно обслуживания хоста ESXi в Maintenance Mode, если вам это требуется для проведения какой-то долгой операции. По умолчанию синхронизация не соответствующих политике дисковых объектов начнется через 60 минут:

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


Таги: VMware, vSAN, HA, ESXi, VMachines, Storage

Как включить vMotion для виртуальных машин с поддержкой vGPU в VMware vSphere 6.7 Update 1.


Как многие из вас знают, в последней версии платформы виртуализации VMware vSphere 6.7 Update 1 компания VMware сделала поддержку горячей миграции vMotion для виртуальных машин, которые имеют на борту технологию vGPU в целях прямого использования ресурсов видеокарт NVIDIA.

Напомним, что ранее была введена поддержка операций Suspend/Resume для GRID, а теперь появилась и поддержка горячей миграции vMotion для машин с привязкой к карточкам NVIDIA Quadro vDWS.

Между тем, по умолчанию эта поддержка для виртуальных машин отключена, и чтобы начать пользоваться этой функцией нужно внести изменения в настройки vCenter. Если вы попробуете сделать vMotion машины с vGPU, то получите вот такую ошибку:

Migration was temporarily disabled due to another migration activity. vGPU hot migration is not enabled.

Вильям Лам написал о том, как включить поддержку vMotion в этой ситуации. Вам надо пойти в Advanced Settings на сервере vCenter и поставить там значение true на настройки vgpu.hotmigrate.enabled:

Эта настройка также рассматривается в документации вот тут. Надо отметить, что вступает в действие она сразу же, и вы можете делать не только vMotion, но и Storage vMotion любой машины (одновременно с vMotion, кстати). Помните, что для успешной работы vMotion на всех хостах ESXi должны быть карточки NVIDIA GRID и установлен соответствующий VIB-пакет.

Также установить эту настройку можно и с помощью командлета PowerCLI:

Get-AdvancedSetting -Entity $global:DefaultVIServer -Name vgpu.hotmigrate.enabled | Set-AdvancedSetting -Value $true -Confirm:$false


Таги: VMware, vSphere, vGPU, NVIDIA, Grid, vMotion

Что такое сервис VMware Site Recovery, и для чего он нужен?


Не все из вас знают, что в начале этого года компания VMware запустила облачный DR-сервис по обеспечению катастрофоустойчивости виртуальной инфраструктуры в облаке - VMware Site Recovery. Это так называемое DRaaS для публичного облака VMware Cloud on AWS (VMC), которое позволяет организовать disaster recovery (DR) инфраструктуру без капитальных затрат на организацию резервной площадки, покупку оборудования и т.п. для бизнес-критичных приложений - можно просто взять ее в аренду и платить по времени использования.

Это Disaster Recovery as-a-Service (DRaaS) решение на базе публичного облака дает следующие преимущества:

  • Возможность быстро развернуть резервное окружение для онпремизной инфраструктуры vSphere в облаке.
  • Функции vSphere Replication, обеспечивающие, в случае массового сбоя в датацентре, потерю данных в объеме всего RPO=5 минут.
  • Единую консоль Site Recovery Manager (SRM), которая позволяет оркестрировать весь процесс восстановления после аварии.

Учитывая возможности решения Site Recovery, можно выделить 4 основных сценария использования данной технологии:

  • Замена существующего DR-решения (оптимизация затрат, перераспределение ресурсов).
  • Дополнение существующего DR-решения (частичное освобождение мощностей удаленной площадки).
  • Обеспечение DR-инфраструктуры для приложений, которые ранее не были защищены.
  • Возможность репликации данных из облака в другой регион AWS или другую онпремизную инфраструктуру.

Сервис Site Recovery работает с любым решением для организации хранилищ, особенно эффективен он будет вкупе с решением vSAN, которое, в свою очередь, может быть построено на различных аппаратных платформах, например, Dell-EMC VxRail.

Перед тем, как развертывать компоненты решения Site Recovery, вы можете пощупать их в реальной обстановке в рамках бесплатной лабораторной работы HOL-1905-01-SDC - VMware Site Recovery Manager - Data Center Migration and Disaster Recovery.

Кстати, на VMworld 2018 компания VMware объявила, что теперь в рамках одного кластера SDDC на площадке можно защищать до 1000 виртуальных машин, что в 2 раза больше, чем раньше:

Кроме того, теперь добавлена возможность (пока в режиме превью) реплицировать несколько онпремизных площадок в одну облачную VMware Cloud on AWS DR.

Узнать больше информации о VMware Site Recovery можно в специальном блоге, а также посмотрев следующие видео:


Таги: VMware, DR, Cloud, SRM, DRaaS

Amazon запустила VMware Cloud on AWS на площадках заказчиков (on-premises) в рамках решения AWS Outposts.


Компания Amazon, в рамках конференции AWS re:Invent 2018, объявила о запуске инициативы AWS Outposts, которая будет предоставлять облачные сервисы AWS на площадке и оборудовании заказчика, в том числе сервисы VMware Cloud on AWS.

По-сути, механизм AWS Outposts позволит вам использовать стандартные сервисы AWS, как будто они работают в облаке, но реально исполнять их на своем оборудовании. Это позволит получить все сервисы AWS SDDC, такие как vSphere, NSX и vSAN в своем датацентре, при этом платить по модели повременного использования ресурсов AWS.

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

Здесь логично напрашивается вопрос - а зачем нужно локально исполнять VMware Cloud on AWS, если можно просто развернуть на своем оборудовании VMware vSphere и остальные компоненты? Использовать VMware Cloud on AWS в таком режиме будет целесообразно, когда у вас есть гибридная среда из локальных и облачных датацентров, а вы хотите получать виртуальные ресурсы от единого поставщика - Amazon, а сервисы по управлению и апдейту всех компонентов SDDC - от VMware.

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

Надо отметить, что AWS Outposts предполагает развертывание как в варианте с VMware Cloud on AWS, так и без него - с нативными службами Amazon и их API.

Сервис AWS Outposts будет доступен для пользователей, начиная со второй половины 2019 года. Изменения можно отслеживать на этой странице.


Таги: VMware, Amazon, AWS, vCloud, Cloud

VMware упраздняет топологию с внешним Platform Services Controller (External PSC) в следующей версии vSphere.


Как знают администраторы больших инфраструктур VMware, для среды управления vSphere есть компонент Platform Services Controller, который может быть внешним (External PSC) и внедренным (Embedded PSC). Недавно мы писали о том, как провести миграцию на внедренный PSC с внешнего PSC с помощью утилиты vCenter Server Converge Tool.

VMware везде рассказывает об этом неспроста - недавно было заявлено, что в следующей версии VMware vSphere внешний сервис PSC будет отсутствовать в принципе. А в данный момент Embedded PSC является рекомендуемым способом развертывания инфраструктуры vCenter (как и виртуальный модуль vCSA).

Возможность создания внешнего PSC появилась в версии vSphere 6.0, а еще в vSphere 5.1 компания VMware предоставила возможность размещать отдельные компоненты, такие как VMware Update Manager (VUM) или vCenter Server Database (VCDB) на отдельных серверах. Это привело к тому, что средства управления виртуальной инфраструктурой можно было развернуть аж на 6 серверах, что рождало проблемы интеграции, обновления и сложности обслуживания.

Когда VMware предложила модель с внешним PSC инфраструктура свелась всего к двум узлам сервисов vCenter. PSC обслуживает инфраструктуру SSO (Single Sign-On), а также службы лицензирования, тэгов и категорий, глобальных прав доступа и кастомных ролей. Помимо этого PSC отвечает за сертификаты данного SSO-домена.

В то время, как службы PSC принесли гибкость развертывания, они же принесли и сложность обслуживания, так как для них нужно было обеспечивать отдельную от vCenter процедуру отказоустойчивости в инфраструктуре распределенных компонентов vCenter Enhanced Linked Mode (ELM).

Еще в vSphere 6.7 и vSphere 6.5 Update 2 была введена поддержка режима ELM для Embedded PSC, поэтому с внедренным PSC уже не требуется обеспечивать отказоустойчивость дополнительных узлов, балансировку нагрузки, а также их обновление. Теперь можно обеспечивать доступность узлов vCenter посредством технологии vCenter High Availability.

Поэтому уже сейчас можете использовать vCenter Server Converge Tool для миграции внешних PSC на Embedded PSC виртуального модуля vCenter Server Appliance. А возможности развернуть внешние PSC в следующих версиях vSphere уже не будет.


Таги: VMware, vSphere, HA, vCenter, PSC, Update, vCSA

Кто залогинен в мои ВМ?


Знаете ли вы, кто залогинен в ваши виртуальные машины? Сколько из этих учётных записей локальные и сколько доменные? Уверены ли вы, что знаете где именно в вашей виртуальной инфраструктуре определённый пользователь залогинен в данный момент? И наконец последний вопрос, хотите ли знать ответы на эти вопросы? Если ваш ответ «Да», эта статья вам будет очень полезна...


Таги: VMware, PowerCLI, VMachines

Увеличение производительности Storage DRS и скорости развертывания ВМ в VMware vSphere 6.7 по сравнению с версией 6.5.


Многие администраторы VMware vSphere весьма консервативны и подолгу не обновляют версию платформы виртуализации, даже когда есть деньги на продление поддержки. Отчасти это верная стратегия - VMware так часто пропускает серьезные баги в мажорных релизах, что многие ждут пока обновление "настоится".

Но долго ждать тоже не стоит, так как можно недополучить преимущества новых версий. Например, всегда от релиза к релизу у платформы vSphere растет производительность в различных аспектах. В частности, давайте посмотрим, как выросла производительность технологии миграции хранилищ Storage DRS в VMware vSphere 6.7 по сравнению с версией 6.5.

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

  • CreateVM
  • CloneVM
  • ReconfigureVM (добавление дополнительного диска)
  • RelocateVM (перемещение на другой датастор)
  • Datastore Enter Maintenance (перевод датастора в режим обслуживания)

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

Для 16 одновременных операций:

Отдельно представлен график для операций Datastore Enter Maintenance:

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


Таги: VMware, Storage DRS, Performance, Storage, ESXi, vSphere, Enterprise

Полезные расширенные настройки (Advanced Options) кластера VMware vSAN 6.7 Update 1.


Как почти все знают, компания VMware в рамках конференции VMworld 2018 анонсировала доступность новой версии решения для создания отказоустойчивых хранилищ VMware vSAN 6.7 Update 1. В обновленном vSAN появилась масса новых возможностей, но сегодня мы расскажем о трех новых расширенных настройках (Advanced Options), про которые написал Cormac Hogan, и которые стали доступны для редактирования в графическом интерфейсе.

Ранее Кормак рассказывал про следующие расширенные настройки кластера vSAN:

  • VSAN.ClomRepairDelay - задержка перед началом ребилда отсутствующих компонентов.
  • VSAN.DomOwnerForceWarmCache - определяет, должны ли операции чтения производится со всех реплик дисковых объектов, либо с определенных сайтов растянутого (stretched) кластера vSAN.
  • VSAN.SwapThickProvisionDisabled - возможность сделать swap-файлы виртуальных машин тонкими, то есть растущими по мере наполнения данными.

Теперь эти три настройки в новой инкарнации можно найти в разделе:

Cluster > Configure > vSAN > Services > Advanced Options

При нажатии на ссылку EDIT можно открыть интерфейс их изменения:

1. Настройка Object Repair Timer.

Как было сказано выше, она определяет задержку, после которой начинается ребилд отсутствующих дисковых объектов в кластере после произошедшего сбоя. По умолчанию она установлена в 60 минут (время, которое нужно VMware Update Manager для обновления хоста ESXi). Также тут нужно достаточное время, чтобы не происходило ненужных срабатываний при временных проблемах в сети. Если вы просто тестируете продукт vSAN, то можете поставить ее, например, в 15 минут, чтобы посмотреть, как начнется процесс ребилда.

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

2. Настройка Site Read Locality.

Эта настройка определяет, будут ли данные растянутого (stretched) кластера читаться из реплик дисковых объектов на уровне одного сайта (домена отказа), либо будут читаться из всех реплик дисковых объектов ВМ. Второй вариант подходит, когда между площадками у вас налажено высокоскоростное соединение (inter-site link), не отличающееся по скорости от внутреннего. Если же это совсем не так, то Read Locality можно отключить.

Также эта настройка работает и для кластеров vSAN состоящих только из двух узлов - и вот тут иногда бывает смысл ее менять, чтобы данные ВМ читались, например, только с одного хоста ESXi.

3. Настройка Thin Swap.

Она определяет, будут ли файлы подкачки виртуальных машин "тонкими", то есть растущими по мере наполнения данными. Тонкие swap-файлы экономят дисковое пространство, но создают совсем маленькую нагрузку по IO при аллоцировании блоков. По умолчанию тонкий своп включен.

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


Таги: VMware, vSAN, Update, Storage, VMachines, DR

Голосуйте за наших - поддержите Романа в голосовании Top vBlog 2018!


Уважаемые читатели! Некоторые из вас знают, что у нас на сайте есть цикл статей от Романа Гельмана, который разрабатывает различные функции своего PowerCLI-модуля Vi-Module. Они позволяют управлять многими аспектами виртуальной инфраструктуры VMware vSphere с помощью механизмов, недоступных в рамках стандартных средств управления.

Недавно Роман подал свой англоязычный блог ps1code.com на голосование по выбору лучшего блога о виртуализации Top vBlog 2018. И мы от лица всей редакции очень просим проголосовать за Романа - ведь его блог этого действительно достоин!

Спасибо вам заранее.

И вот статьи Романа на нашем ресурсе, чтобы вам удобнее было найти нужную функцию:

Голосуйте за Романа и его ps1code.com!


Таги: VMware, Offtopic, PowerCLI, PowerShell, Blogs

Анонсы VMworld Europe 2018, часть 3 - технология VMware vSAN Native Data Protection.


Некоторое время назад мы писали о продуктах и технологиях, анонсированных на конференции VMworld Europe 2018 (часть 1 и часть 2), а сегодня поговорим о еще одной технологии, объявленной в рамках мероприятия - VMware vSAN Native Data Protection. О ней в своей статье рассказал Viktor van den Berg.

Данная технология будет представлять собой репликацию данных виртуальных машин на уровне хранилищ на базе снапшотов (а также будет доступна локально в рамках хранилища) в целях создания резервных копий ВМ. Работать этот механизм будет в соответствии с текущей механикой политик Storage Policy Based Management (SPBM).

Использовать технологию vSAN Native Data Protection можно для трех сценариев:

  • Защита локальных виртуальных машин без использования снапшотов vSphere.
  • Репликация данных машин на стороннее хранилище NFS.
  • Репликация данных машин на другую площадку (другой кластер vSAN) под управлением того же (или другого) сервера vCenter.

Технология vSAN Local Data Protection будет использовать механизм native vSAN snapshots, который почти не оказывает влияние на производительность ВМ (поскольку работает на уровне хранилища). Также будут поддерживаться консистентные с точки зрения приложений снапшоты, которые будут использовать скрипты Microsoft VSS / VMware Tools для "подморозки" приложений.

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

Как мы видим, можно установить частоту создания снапшотов (по сути, требования RPO). Далее идет настройка про то, с какой периодичностью делать application consistent снапшоты. Ну и в конце - число хранимых снапшотов.

Некоторые снапшотоы можно будет хранить в течение долгого периода времени в архивных целях:

Также расписание снапшотирования и откидывания на NFS-хранилище будет представлено в таблице:

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

Также в процессе работы vSAN Native Data Protection можно просматривать информацию о ее состоянии в целом:

И для виртуальных машин:

Также будет несколько интересных моментов:

  • Пока не будет интеграции vSAN Native Data Protection и SRM.
  • В будущем планируется создание резервных копий с помощью снапшотов для групп ВМ (consistency groups), если они, например, располагаются на разных хранилищах.
  • Минимально RPO можно указать как 5 минут.
  • Для обеспечения консистентности бэкапов на уровне приложений можно будет использовать собственные скрипты подготовки и возобновления приложения, а также Microsoft VSS.
  • Технология будет интегрирована со сторонними решениями для резервного копирования и фреймворком VADP.
  • Репликация на удаленное хранилище также будет использовать снапшоты в своей основе.
  • Без application consistent снапшотов (только crash consistent) хранилище будет снапшотиться мгновенно.
  • Будет поддерживаться репликация как между разными кластерами, так и между разными vCenter.
  • В качестве архивного хранилища будет поддерживаться пока только NFS, но потом можно будет использовать и облачный сторадж Amazon S3.
  • Нативные снапшоты будут дедуплицироваться и сжиматься при передаче.

Доступность технологии vSAN Native Data Protection ожидается в первом квартале 2019 года, а пока вы можете запросить доступ к vSAN Beta, где эта технология уже имеется.

Также полистайте вот эту презентацию и посмотрите вот эту запись с сессии VMworld Europe 2018.


Таги: VMware, vSAN, Update, Beta, Snapshots, Backup, Replication

Новая версия средства для генерации и тестирования нагрузки приложений в виртуальных ПК - Login PI Release 3 от Login VSI.


Несколько недель назад компания Login VSI, известная своими бенчмарками для виртуальных сред, выпустила обновленную версию своего средства для генерации и тестирования нагрузки приложений в виртуальных ПК - Login PI Release 3. Напомним, что о прошлой версии этого продукта мы писали вот тут.

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

Давайте посмотрим, что нового появилось в Login PI Release 3:

1. Технология Deep Application Performance Testing.

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

  • Воркфлоу можно создавать с помощью функций автодополнения (intellisense) и подсветки синтаксиса. Их можно редактировать без соединения с бэкендом Login PI, то есть на клиенте без задержек.
  • Более гранулярные действия в рабочих процессах и возможность более детального планирования событий, что позволяет точнее настраивать симулированных пользователей и удобнее оркестрировать их поведение.
  • Расширенная поддержка сторонних приложений (EPIC, Cerner, AllScripts и т.п.), приложений пользователей (Microsoft Office), а также тесно интегрированных сторонних плагинов, рабочих процессов и скриптов.

2. Новая архитектура Login PI Release 3.

Здесь появились следующие улучшения:

  • Теперь поставляется как виртуальный модуль (virtual appliance) и развертывается за несколько минут.
  • За счет использования REST API теперь можно интегрировать Login PI с традиционными решениями для мониторинга, такими как SCOM, или системами управления инцидентами, например, ServiceNow, а также big-data анализаторами (например, Splunk).
  • Login PI R3 поддерживает соединения через RDP, PCoIP, Blast Extreme, Citrix ICA/HDX, NetScaler и любые другие.
  • Повышенная безопасность продукта.

3. Новый интерфейс.

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

  • Новый интерфейс для конфигурации, репортинга и быстрых выводов (quick insights) в плане производительности.
  • Более детальная информация и умная агрегация данных на высокоуровневых дэшбордах для проверки и анализа нескольких серверных ферм в разных локациях, а также для нескольких клиентов (удобно для сервис-провайдеров).

4. Проактивный мониторинг.

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

Скачать пробную версию Login PI Release 3 можно по этой ссылке.

Таги: VMware, VDI, Login PI, Performance, Update

Новое на VMware Labs - vSphere PKS Plugin.


Некоторое время назад мы рассказывали об анонсах конференции VMworld Europe 2018, одним из которых была покупка компании Heptio, предоставляющая решения для управления контейнерами платформы Kubernetes в облаке. Ну а на днях на сайте проекта VMware Labs появился плагин к vSphere Client, который позволяет видеть кластеры и узлы Kubernetes, которые находятся под управлением Pivotal Container Service - vSphere PKS Plugin.

Возможности плагина PKS:

  • Визуализация, настройка и управление кластерами Kubernetes, развернутыми и управлеяемыми с помощью PKS.
  • Средства просмотра нижележащей инфраструктуры для контейнеров, включая виртуальные машины, сетевые ресурсы и объекты хранилищ, которые созданы в кластере Kubernetes, развернутом в окружении VMware vSphere.
  • Единая точка просмотра компонентов кластера Kubernetes, включая узлы и сетевые объекты, такие как роутеры, логические коммутаторы и балансировщики.
  • Простой интерфейс для доступа к кластеру через kubectl и дэшборд.

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

  • PKS v1.2.x
  • NSX-T v2.3
  • vSphere v6.7.x, v6.5 U1, U2

Загрузить vSphere PKS Plugin можно по этой ссылке (там же вы найдете и документацию).


Таги: VMware, vSphere, Docker, PKS, Labs, Kubernetes

3 очень серьезных бага VMware vSphere - обязательно накатите обновления!


Совсем недавно стало известно о трех очень серьезных багах в платформе VMware vSphere, которые затронули, как платформу vSphere 5.x/6.x, так и средство создания отказоустойчивых хранилищ для виртуальных машин VMware vSAN 6.6/6.7.

1. Повреждение данных виртуальных дисков снапшотов формата SEsparse.

Начиная с VMware ESXi 5.5, диски стапшотов виртуальных машин стали создаваться в формате SEsparse. Такой диск создается в ESXi 5.5 если диск машины более 2 ТБ, а начиная с ESXi 6.0 / VMFS6 - он используется для снапшотов всех машин. Так что под угрозой практически все виртуальные машины со снапшотами. А ведь снапшоты используются всеми ВМ, для которых применяется резервное копирование через механизм vSphere API for Data Protection (например, с помощью продукта Veeam Backup and Replication).

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

Баг и возможные способы решения описаны в KB 59216. В vSphere 6.7 Update 1 баг уже пофикшен. Для остального есть следующие апдейты:

Для ESXi 5.5 обновления нет, но вы можете отключить функцию "IO coalescing" для формата дисков SEsparse. Делается это следующей командой:

esxcli system settings advanced set -i 0 -o /COW/COWEnableIOCoalescing

2. Проблема консистентности виртуальных дисков машин на платформе vSAN 6.6.

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

  • vSAN начинает процесс ресинхронизации
  • В этот момент вы расширяете диск VMDK виртуальной машины
  • vSAN снова начинает ресинхронизировать уже расширенный диск виртуальной машины

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

Для устранения бага накатите патчи на vSAN:

Также вы можете временно избежать проблемы, выполнив такую команду на каждом хосте ESXi:

esxcfg-advcfg -s 0 /VSAN/ClomEnableInplaceExpansion

3. Получение доступа root к хосту ESXi из виртуальной машины.

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

Кстати, это было публично показано впервые:

Информация об этой уязвимости опубликована в VMware advisory VMSA-2018-0027. Там же есть и названия необходимых вам патчей (обратите внимание, что багу подвержены также и платформы Workstation / Fusion).


Таги: VMware, vSphere, Bug, Bugs, vSAN, Security, VMachines, Storage, Networking

Документ о тестировании работы баз данных Oracle в All-Flash кластере VMware vSAN 6.7.


Компания VMware выпустила документ, касающийся работы баз данных Oracle Database 12c на платформе VMware vSAN - Oracle Database on VMware vSAN 6.7. Основная тема дока - тестирование числа операций ввода-вывода (IOPS) и latency операций СУБД на хостах в All-Flash конфигурации, когда и ярус кэширования, и ярус хранения реализован на SSD-дисках:

В документе рассматривается 4 ключевых аспекта для реализации тяжелых баз данных:

  • Производительность OLTP-нагрузок в кластере all-flash vSAN.
  • Политики Storage Policy Based Management (SPBM) для управления хранилищами.
  • Построение платформы для бизнес-критичных задач уровня Tier-1.
  • Валидация архитектуры для уменьшения времени развертывания и операционных рисков.

Для тестирования использовались хосты ESXi в следующей конфигурации:

В тестах использовалось два типа рабочих нагрузок (R1 и R15), отличающихся конфигурацией ВМ, а также включенными или выключенными технологиями дедупликации и компрессии на стороне vSAN:

Описание рабочей нагрузки:

Базовые результаты по IOPS и latency для операций чтения и записи:

После результатов тестирования в документе есть секция с рекомендациями по исполнению Oracle на хранилищах vSAN, которые будет полезно почитать администратору БД и vSphere (большая их часть приведена в vSAN Design and Sizing Guide).


Таги: VMware, vSAN, Performance, Oracle, AWS, Cloud, Storage, Flash, SSD, Whitepaper

Задачи машинного обучения в инфраструктуре VMware vSphere на оборудовании NVIDIA GRID (vGPU).


Мы много писали о рещениях NVIDIA GRID / Quadro vDWS  (они используют технологии virtual GPU или vGPU), например здесь, здесь и здесь. Ранее эта технология предполагала только применение vGPU для нагрузок в виртуальных машинах, которые требовательны к графике, поэтому используют ресурсы графического адаптера в разделенном режиме.

Между тем, начиная с недавнего времени (а именно с выпуска архитектуры Pascal GPU), VMware и NVIDIA предлагают использование vGPU для задач машинного обучения (CUDA / Machine Learning / Deep Learning), которые в последнее время становятся все более актуальными, особенно для крупных компаний. С помощью этой технологии виртуальная машина с vGPU на борту может эффективно использовать библиотеки TensorFlow, Keras, Caffe, Theano, Torch и прочие.

Например, можно создать использовать профиль P40-1q vGPU для архитектуры Pascal P40 GPU, что позволит иметь до 24 виртуальных машин на одном физическом адаптере (поскольку на устройстве 24 ГБ видеопамяти).

Зачем же использовать vGPU для ML/DL-задач, ведь при исполнении тяжелой нагрузки (например, тренировка сложной нейронной сети) загружается все устройство? Дело в том, что пользователи не используют на своих машинах 100% времени на исполнение ML/DL-задач. Большинство времени они собирают данные и подготавливают их, а после исполнения задачи интерпретируют результаты и составляют отчеты. Соответственно, лишь часть времени идет большая нагрузка на GPU от одного или нескольких пользователей. В этом случае использование vGPU дает максимальный эффект.

Например, у нас есть 3 виртуальных машины, при этом тяжелая нагрузка у VM1 и VM2 пересекается только 25% времени. Нагрузка VM3 не пересекается с VM1 и VM2 во времени:

Компания VMware проводила тест для такого случая, используя виртуальные машины CentOS с профилями P40-1q vGPU, которые имели 12 vCPU, 60 ГБ памяти и 96 ГБ диска. Там запускались задачи обучения TensorFlow, включая комплексное моделирование для рекуррентной нейронной сети (recurrent neural network, RNN), а также задача распознавания рукописного текста с помощью сверточной нейронной сети (convolution neural network, CNN). Эксперимент проводился на серверах Dell PowerEdge R740 с 18-ядерным процессором Intel Xeon Gold 6140 и карточками NVIDIA Pascal P40 GPU. 

Результаты для первого теста оказались таковы: 


Время обучения из-за наложения окон нагрузки в среднем увеличилось на 16-23%, что в целом приемлемо для пользователей, разделяющих ресурсы на одном сервере. Для второго теста было получено что-то подобное:

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

 

Несмотря на то, что число загруженных ML/DL-нагрузкой виртуальных машин увеличилось до 24, время тренировки нейронной сети увеличилось лишь в 17 раз, то есть даже в случае полного наложения временных окон рабочих нагрузок есть некоторый позитивный эффект:

Интересны также результаты с изменением политики использования vGPU. Некоторые знают, что у планировщика vGPU есть три режима работы:

  • Best Effort (это исполнение задач на вычислительных ядрах по алгоритму round-robin).
  • Equal Share (всем дается одинаковое количество времени GPU - это позволяет избежать влияния тяжелых нагрузок на легкие машины, например).
  • Fixed Share (планировщик дает фиксированное время GPU на основе профиля нагрузки vGPU).

VMware поэкспериментировала с настройками Best Effort и Equal Share для тех же тестов, и вот что получилось:

С точки зрения времени исполнения задач, настройка Best Effort оказалась лучшим выбором, а вот с точки зрения использования GPU - Equal Sharing меньше грузила графический процессор:

Некоторые остальные детали вы можете почитать в оригинальной статье VMware.


Таги: VMware, vSphere, vGPU, NVIDIA, Performance, ML

Как настраивается механизм VMware vSphere 6.5 HA Orchestrated Restart (VM Restart Dependency), и как он связан с Restart Priority.


Мы немного рассказывали о новой функции технологии VMware HA, которая появилась в vSphere 6.5 - Orchestrated Restart (она же VM Restart Dependency). С помощью нее можно сделать так, чтобы виртуальные машины (или группы ВМ) могли запускаться после того, как предварительно будет запущена указанная ВМ или группа.

На практике это работает так. В vSphere Web Client идем на вкладку Configure для выбранного кластера HA и в разделе VM/Host Groups добавляем группу ВМ:

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

Например, мы создали 3 группы (в данном случае, это классическая трехзвенная архитектура - серверы БД, серверы приложений и веб-серверы):

После этого можно задать правила запуска групп виртуальных машин в разделе VM/Host Rules, указав предварительное условие для запуска некоторой группы:

В данном случае мы запускаем серверы приложений только после запуска серверов баз данных. Очевидно, что нужно создать такое же правило для веб-серверов, которые будут запускаться после серверов приложений. Это и создаст требуемые зависимости ВМ для их запуска в случае сбоя одного или нескольких хостов в кластере VMware HA. Это и называется VMware HA Orchestrated Restart.

В то же время, у виртуальных машин в кластере HA есть параметр VM Restart Priority, который определяет приоритет запуска виртуальных машин в случае их восстановления после сбоя:

Этот вопрос затрагивает Дункан в своей заметке о настройке VM dependency restart condition timeout. Оказывается, она задает задержку между стартом виртуальных машин разного приоритета (а не для групп зависимостей, как может показаться из названия) и по умолчанию выставлена в 600 секунд.

Так вот, возвращаясь к Restart Priority и VM Dependency, Вова в комментариях к статье об HA Orchestrated Restart спросил: а что важнее - приоритет или зависимости? Опираясь на слова Дункана ("Restart Dependency is a rule, a hard rule, a must rule, which means there’s no time-out. We wait until all VMs are restarted when you use restart dependency"), можно сказать, что зависимости важнее - сначала будут подняты все машины первичной группы (между которыми будет соблюдаться порядок запуска в рамках приоритета), а потом уже те, которые от них зависят.

Таким образом, ответ на вопрос Вовы ("Допустим ВМ1 имеет приоритет high, но зависит от ВМ2 которая имеет приоритет low. Какая будет последовательность запуска?") - сначала запустится ВМ2.


Таги: VMware, HA, VMachines

Миграция сервера VMware vCenter для Windows на виртуальный модуль vCenter Server Appliance 6.7 Update 1.


Как многие из вас знают, VMware vCenter для Windows версии 6.7 (на данный момент Update 1) - это последний vCenter, который еще доступен как отдельный продукт для Windows-машины. Следующая версия vCenter будет поставляться только как виртуальный модуль vCenter Server Appliance на базе Photon OS от VMware.

Мы уже писали о некоторых аспектах миграции на vCSA с vCenter for Windows, но в этом посте дадим несколько новых деталей по этому процессу. VMware рекомендует выполнить 2 основных шага миграции с vCenter на vCSA:

  • Migration Assistant - консольная утилита, которую нужно выполнить до мастера миграции vCenter. Она выясняет соответствие требованиям к миграции и показывает дальнейшие шаги.
  • Migration Tool - это мастер миграции, который доступен из основного дистрибутива vCenter.

Полный обзор процесса миграции показан в видео ниже:

Обратите внимание, что во время миграции вы можете выбрать опцию импорта исторических данных из старой копии vCenter for Windows в созданную новую копию vCSA (это опциональный процесс во время миграции, и можно сделать импорт уже позднее).

Migration Tool делает импорт всех скопированных данных в развернутый виртуальный модуль vCSA (включая параметры идентификации vCenter, такие как FQDN, IP-адрес, UUID, сертификаты, MoRef IDs и прочее). Также происходит миграция и vSphere Distributed Switch (vDS).

Надо отметить, что в процессе миграции не происходит никаких изменений в исходном vCenter, поэтому откат в случае неудачного обновления прост - останавливаете vCSA и продолжаете использовать vCenter Server for Windows.

Помимо всего этого есть утилита vCenter Server Converge Tool (о ней мы писали тут и тут), которая позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC. Проблема заключалась в том, что ранее администраторы использовали внешний PSC, поскольку он поддерживал Enhanced Linked Mode (ELM). И несмотря на то, что внедренный PSC стал поддерживать ELM еще в vSphere 6.7 и vSphere 6.5 Update 2, многие пользователи еще с предыдущих версий поддерживают комплексную инфраструктуру внешних PSC с репликацией между площадками.

Сейчас все стало проще - утилита vCenter Server Converge Tool устанавливает embedded PSC на vCenter Server Appliance (vCSA), после чего налаживает канал репликации с оставшимися внешними PSC. После того, как эта процедура пройдет на всех площадках, вы сможете отключить внешние PSC, а встроенный механизм vCenter HA сам настроится на работу с внедренными PSC.

Пройтись по шагам различных вариантов миграции vCenter и его PSC (встроенного или внешнего) можно вот в этих обучающих материалах VMware (там вы все это можете прокликать прямо в интерфейсе):

В целом процесс миграции vCenter выглядит так:

Кстати, надо понимать, что процесс миграции vCenter - это одновременно и его апгрейд. То есть вы можете, например, провести миграцию-апгрейд vCenter Server 6.0 на VCSA версии 6.7.

Ну и помните, что весь самый новый функционал есть только в VMware vCSA, который является рекомендуемым вариантом развертывания по умолчанию. Вам уже давно пора перейти на vCSA, если вы все еще пользуетесь vCenter для Windows.


Таги: VMware, vCenter, Migration, vCSA, P2V

Новая уязвимость L1 Terminal Fault в процессорах Intel - как она касается VMware vSphere, и как с ней бороться.


В догонку к найденным и, вроде бы, поборенным уязвимостям Meltdown и Spectre, в процессорах Intel нашли еще одну потенциальную дыру - L1 Terminal Fault Vulnerability, которая затрагивает современные процессоры (2009-2018 годов выпуска) и гипервизор VMware ESXi (а также и все остальные гипервизоры).

Для начала надо сказать, что на днях стали доступны вот такие патчи для платформы виртуализации VMware vSphere, которые настоятельно рекомендуется установить:

VMware vCenter:

VMware ESXi:

Суть уязвимости, описанной в CVE-2018-3646 заключается в том, что виртуальная машина, исполняемая на конкретном ядре, может получить доступ к данным других машин, использующих это ядро, или самого гипервизора через L1 Data Cache, который совместно используется машинами, выполняющими команды на данном ядре.

Для такой уязвимости возможны 2 типа векторов атаки:

  • Sequential-context - вредоносная машина получает доступ к данным другой ВМ, которая исполнялась на этом ядре ранее и получала доступ к кэшу L1.
  • Concurrent-context - вредоносная машина прямо сейчас получает доступ к данным ВМ или гипервизора, которые исполняются планировщиком на этом ядре.

Решение вопроса уровня Sequential-context заключается просто в накатывании патчей, которые не должны приводить к падению производительности (как это было с Meltdown и Spectre). А вот для избавления от риска применения вектора атаки Concurrent-context нужно включить фичу, которая называется ESXi Side-Channel-Aware Scheduler. И вот в этом случае влияние на производительность может уже быть существенным, поэтому нужно либо принять риск Concurrent-context, либо следить за производительностью систем.

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

  • Обновляете сначала серверы vCenter, потом хосты ESXi.
  • Смотрите, есть ли на хостах запас по CPU на случай возникновения проблем с производительностью.
  • Если запас есть - включаете функцию ESXi Side-Channel-Aware Scheduler и наблюдаете за производительностью систем по CPU.

Детальные инструкции по включению ESXi Side-Channel-Aware Scheduler вы найдете здесь. Действовать нужно по следующей схеме:

Ну и в заключение, вот список процессоров, которые подвержены атакам типа L1 Terminal Fault:

Кодовое имя процессора Intel FMS Товарное наименование Intel
Nehalem-EP 0x106a5 Intel Xeon 35xx Series;
Intel Xeon 55xx Series
Lynnfield 0x106e5 Intel Xeon 34xx Lynnfield Series
Clarkdale 0x20652 Intel i3/i5 Clarkdale Series;
Intel Xeon 34xx Clarkdale Series
Arrandale 0x20655 Intel Core i7-620LE Processor
Sandy Bridge DT 0x206a7 Intel Xeon E3-1100 Series;
Intel Xeon E3-1200 Series;
Intel i7-2655-LE Series;  Intel i3-2100 Series
Westmere EP 0x206c2 Intel Xeon 56xx Series;
Intel Xeon 36xx Series
Sandy Bridge EP 0x206d7 Intel Pentium 1400 Series;
Intel Xeon E5-1400 Series;
Intel Xeon E5-1600 Series;
Intel Xeon E5-2400 Series;
Intel Xeon E5-2600 Series;
Intel Xeon E5-4600 Series
Nehalem EX 0x206e6 Intel Xeon 65xx Series;
Intel Xeon 75xx Series
Westmere EX 0x206f2 Intel Xeon E7-8800 Series;
Intel Xeon E7-4800 Series;
Intel Xeon E7-2800 Series
Ivy Bridge DT 0x306a9 Intel i3-3200 Series; Intel i7-3500-LE/UE, Intel i7-3600-QE,
Intel Xeon E3-1200-v2 Series;
Intel Xeon E3-1100-C-v2 Series;
Intel Pentium B925C
Haswell DT 0x306c3 Intel Xeon E3-1200-v3 Series
Ivy Bridge EP 0x306e4 Intel Xeon E5-4600-v2 Series;
Intel Xeon E5-2400-v2 Series;
Intel Xeon E5-2600-v2 Series;
Intel Xeon E5-1400-v2 Series;
Intel Xeon E5-2600-v2 Series
Ivy Bridge EX 0x306e7 Intel Xeon E7-8800/4800/2800-v2 Series
Haswell EP 0x306f2 Intel Xeon E5-2400-v3 Series;
Intel Xeon E5-1400-v3 Series;
Intel Xeon E5-1600-v3 Series;
Intel Xeon E5-2600-v3 Series;
Intel Xeon E5-4600-v3 Series
Haswell EX 0x306f4 Intel Xeon E7-8800/4800-v3 Series
Broadwell H 0x40671 Intel Core i7-5700EQ;
Intel Xeon E3-1200-v4 Series
Avoton 0x406d8 Intel Atom C2300 Series;
Intel Atom C2500 Series;
Intel Atom C2700 Series
Broadwell EP/EX 0x406f1 Intel Xeon E7-8800/4800-v4 Series;
Intel Xeon E5-4600-v4 Series;
Intel Xeon E5-2600-v4 Series;
Intel Xeon E5-1600-v4 Series
Skylake SP 0x50654 Intel Xeon Platinum 8100 (Skylake-SP) Series;
Intel Xeon Gold 6100/5100 (Skylake-SP) Series
Intel Xeon Silver 4100, Bronze 3100 (Skylake-SP) Series
Broadwell DE 0x50662 Intel Xeon D-1500 Series
Broadwell DE 0x50663 Intel Xeon D-1500 Series
Broadwell DE 0x50664 Intel Xeon D-1500 Series
Broadwell NS 0x50665 Intel Xeon D-1500 Series
Skylake H/S 0x506e3 Intel Xeon E3-1500-v5 Series;
Intel Xeon E3-1200-v5 Series
Kaby Lake H/S/X 0x906e9 Intel Xeon E3-1200-v6

Таги: VMware, vSphere, Security, ESXi, Intel, CPU, Update, vCenter

Ссылки для скачивания видео всех сессий VMworld Europe 2018.


Мы уже публиковали ссылки для скачивания всех сессий конференции VMware VMworld 2018, которая прошла этим летом. На прошлой неделе закончилась и европейская часть этой конференции - VMworld Europe 2018, об анонсах которой мы писали тут и тут.

Ну а недавно стали доступны записи почти всех сессий с европейского VMworld (369 из 389), ссылки на которые добрый человек занес в Excel-таблицу:

Скачать сессии в Linux-машинах можете каким удобно способом:

  • WGET:

wget --no-check-certificate --referer https://videos.vmworld.com/global/2018/videoplayer/26950 https://s3.us-east-2.amazonaws.com/vmworld-europe-2018/MGT3918BE.mp4

  • CURL:

curl --referer https://videos.vmworld.com/global/2018/videoplayer/26950 https://s3.us-east-2.amazonaws.com/vmworld-europe-2018/MGT3918BE.mp4 -O MGT3918BE.mp4

  • PowerCLI:

$headers = @{"referer" = "https://videos.vmworld.com/global/2018/videoplayer/26950"}
Invoke-WebRequest -Uri "https://s3.us-east-2.amazonaws.com/vmworld-europe-2018/MGT3918BE.mp4" -Headers $headers -Outfile MGT3918BE.mp4


Таги: VMware, VMworld, Sessions, VMachines, Blogs, Video

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89    >   >>
Реклама







Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

31/01/2019:  Бизнес и ИТ. Вокруг ЦОД (Ростов-на-Дону)
14/02/2019:  Облака 2019: бурный рост в цифровую эпоху
14/03/2019:  Информационная безопасность бизнеса и госструктур

Быстрый переход:
VMware Gartner Citrix VSAN StarWind IT-Grad Veeam 5nine Hardware VeeamON Nutanix vSphere RVTools Enterprise Security Code Offtopic Cisco vGate Microsoft Cloud SDRS Parallels IaaS HP VMFS PowerCLI VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Teradici Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V Horizon Networking vCloud Labs vSAN Cache DR Storage DRS VMworld HA Workspace Tools UEM Backup vROPs DRS Fusion Workstation Lifecycle Visio SRM vRNI Log Insight Operations Manager VVols SDDC Virtual Appliance Update App Volumes OpenStack Forum PowerShell LSFS Client vCSA Datacenter Workspace ONE NSX Intel Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Performance Nested AWS XenDesktop VSA vNetwork SSO Host Client VMDK VTL iSCSI Whitepaper Appliance VUM V2V Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Converter XenApp Snapshots VCP vGPU Auto Deploy SMB RDM Mirage XenClient MP Video SC VMM Certification VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Monitoring VPLEX UCS SDK Poster VSPP Receiver vMotion VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint VDS Bug Upgrade Migration Director Stencils Memory Troubleshooting API Android Graphics Diagram Air CLI Plugin DPM SIOC Flex Mac Open Source SSH VAAI Chargeback Heartbeat MSCS Ports SVMotion Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Сравнение Oracle VirtualBox и VMware Workstation.

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Новые возможности VMware vSphere 5.0 - официально.

Отличия VMware ESXi 4 free (бесплатного), ESXi 4 и ESX 4 в составе VMware vSphere.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2018, Александр Самойленко. Правила перепечатки материалов.