Многим администраторам знакома такая вещь: сначала для теста устанавливается виртуальная машина VMware vCenter Server Appliance в конфигурации tiny (минимальные аппаратные настройки), а потом она приживается, и хочется сделать из нее полноценную производственную среду управления (конфигурацию large). Только вот не хочется ее переустанавливать.

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

Установщик vCSA использует фреймворк Electron, настраивая конфигурацию через JSON, и механизм JSON-Schema для установки и валидации параметров. Поэтому в ISO-образе вы сможете найти конфигурацию сервера vCenter по следующему пути:

\vcsa-ui-installer\win32\resources\app\resources\layout.json

Там как раз и находятся данные о типовых конфигурациях vCSA. Например, так выглядит размер xlarge:

"xlarge": {
        "cpu": 24,
        "memory": 49152,
        "host-count": 2000,
        "vm-count": 35000,
        "disk-swap": "50GB",
        "disk-core": "100GB",
        "disk-log": "25GB",
        "disk-db": "50GB",
        "disk-dblog": "25GB",
        "disk-seat": "500GB",
        "disk-netdump": "10GB",
        "disk-autodeploy": "25GB",
        "disk-imagebuilder": "25GB",
        "disk-updatemgr": "100GB",
        "disk-archive": "200GB",
        "required-disk-space": "1180GB",
        "label": "X-Large vCenter Server with Embedded PSC",
        "description": "This will deploy a X-Large VM configured with 24 vCPUs and 48 GB of memory and requires 1180 GB of disk space will be updated for xlarge later. This option contains vCenter Server with an embedded Platform Services Controller for managing up to 2000 hosts and 35,000 VMs."
    }

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

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

1. Увеличение CPU и памяти (RAM).

• Остановите машину.
• Хорошая идея - вывести ее ESXi-хост из кластера DRS.
• Зайдите на ESXi через Host Client, после чего в настройках ВМ измените конфигурацию CPU и памяти, чтобы выставить ее в соответствии с нужной конфигурацией.

2. Увеличение диска ВМ с сервером vCSA.

• Об увеличении дискового пространства сервера vCSA 6.5 мы писали вот в этой статье. С тех пор ничего особо не изменилось. Некоторую дополнительную информацию вы также можете получить в KB 2145603 на случай если что изменится в процедуре vCSA 6.x.
• Диски нужно настраивать не только по размеру, но и по корректной позиции в виртуальном слоте SCSI.

Примерно так это выглядит для vCenter 6.7 Update 2:

Помните, что иногда имя VMDK может не соответствовать его позиции в слоте SCSI. Например, встречаются случаи, когда VMDK0 смонтирован в слот SCSI(0:4), а VMDK2 - в слот SCSI(0:0). В этом случае реальным загрузочным диском будет VMDK2, а не VMDK0, несмотря на их названия.

Также обратите внимание, что SCSI слот 0:7 не используется - не ошибитесь.

После изменения этих параметров запустите vCenter и убедитесь, что все в порядке.

Как знают почти все администраторы платформы VMware vSphere, для кластеров VMware HA/DRS есть такой режим работы, как Enhanced vMotion Compatibility (EVC). Нужен он для того, чтобы настроить презентацию инструкций процессора (CPU) хостами ESXi так, чтобы они в рамках кластера соответствовали одному базовому уровню (то есть все функции процессоров приводятся к минимальному уровню с набором инструкций, которые гарантированно есть на всех хостах).

Ввели режим EVC еще очень давно, чтобы поддерживать кластеры VMware vSphere, где стоят хосты с процессорами разных поколений. Эта ситуация случается довольно часто, так как клиенты VMware строят, например, кластер из 8 хостов, а потом докупают еще 4 через год-два. Понятно, что процессоры уже получаются другие, что дает mixed-окружение, где по-прежнему надо перемещать машины между хостами средствами vMotion. И если набор презентуемых инструкций CPU будет разный - двигать машины между хостами будет проблематично.

EVC маскирует инструкции CPU, которые есть не на всех хостах, от гостевых ОС виртуальных машин средствами интерфейса CPUID, который можно назвать "API для CPU". В статье VMware KB 1005764 можно почитать о том, как в кластере EVC происходит работа с базовыми уровнями CPU, а также о том, какие режимы для каких процессоров используются.

Надо отметить, что согласно опросам VMware, режим кластера EVC используют более 80% пользователей:

В VMware vSphere 6.7 появились механизмы Cross-Cloud Cold и Hot Migration, которые позволяют переносить нагрузки в онлайн и офлайн режиме между облаками и онпремизной инфраструктурой.

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

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

Обратите внимание, что Per-VM EVC доступна только, начиная с vSphere 6.7 и версии виртуального железа Hardware Version 14. Эта конфигурация сохраняется в vmx-файле (потому и переезжает вместе с машиной) и выглядит следующим образом:

featMask.vm.cpuid.Intel = “Val:1”
featMask.vm.cpuid.FAMILY = “Val:6”
featMask.vm.cpuid.MODEL = “Val:0x4f”
featMask.vm.cpuid.STEPPING = “Val:0”
featMask.vm.cpuid.NUMLEVELS = “Val:0xd”

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

Основная причина, по которой не включают EVC - это боязнь того, что поскольку машины не будут использовать весь набор инструкций CPU (особенно самых последних), то это даст снижение производительности. Поэтому VMware написала целый документ "Impact of Enhanced vMotion Compatibility on Application Performance", где пытается доказать, что это не сильно влияет на производительность. Вот, например, производительность Oracle на выставленных базовых уровнях для разных поколений процессоров (в документе есть еще много интересных графиков):

Чтобы включить EVC на базе виртуальной машины, нужно ее выключить, после чего настроить нужный базовый уровень. Для автоматизации этого процесса лучше использовать PowerCLI, а сама процедура отлично описана в статье "Configuring Per-VM EVC with PowerCLI".

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

Get-VM | Select Name,HardwareVersion,
@{Name='VM_EVC_Mode';Expression={$_.ExtensionData.Runtime.MinRequiredEVCModeKey}},
@{Name='Cluster_Name';Expression={$_.VMHost.Parent}},
@{Name='Cluster_EVC_Mode';Expression={$_.VMHost.Parent.EVCMode}} | ft

Это даст примерно следующий результат (надо помнить, что отчет будет сгенерирован только для VM hardware version 14 и позднее):

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

Понять максимально поддерживаемый режим EVC на хосте можно с помощью команды:

Get-VMHost | Select-Object Name,ProcessorType,MaxEVCMode

В итоге вы получите примерно такой отчет:

В целом тут совет такой - включайте режим Enhanced vMotion Compatibility (EVC) в кластерах и для виртуальных машин VMware vSphere сейчас, чтобы не столкнуться с неожиданными проблемами в будущем.

У средства обновления хостов VMware vSphere Update Manager (VUM) есть полезный механизм проверок Pre-Check Remediation Report, который выполняет предварительную проверку условий для обновления хостов ESXi, чтобы этот процесс не прервался уже после его начала. Эти условия очень просты, но иногда позволяют сэкономить массу времени, особенно в большой инфраструктуре VMware vSphere.

Чтобы запустить эти проверки, надо выбрать нужный вам кластер и нажать кнопку Pre-Check Remediation:

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

Отчет Pre-Check Remediation Report для кластера может содержать следующие пункты:

Отчет Pre-Check Remediation Report для виртуальных машин может содержать следующее:

В августе прошлого года мы сделали статью о новом виде памяти Persistent memory (PMEM) в VMware vSphere, которая находится на уровне между DRAM и Flash SSD с точки зрения производительности:

Надо сказать, что устройства с Persistent Memory (они же, например, девайсы с Intel Optane Memory) уже начинают рассматривать некоторые пользователи для внедрения в своей виртуальной инфраструктуре, поэтому надо помнить об их ограничениях, которые раскрыл Дункан Эппинг.

С точки зрения предоставления памяти PMEM виртуальной машине, на платформе vSphere есть 3 способа:

• vPMEMDisk - vSphere представляет PMEM как обычный диск, подключенный к виртуальной машине через контроллер SCSI. В этом случае ничего не нужно менять для гостевой ОС или приложений. В таком режиме работают любые системы, включая старые ОС и приложения.
• vPMEM - vSphere представляет PMEM как устройство NVDIMM для виртуальной машины. Большинство последних версий операционных систем (например, Windows Server 2016 и CentOS 7.4) поддерживают устройства NVDIMM и могут предоставлять их приложениям как блочные или байт-адресуемые устройства. Приложения могут использовать vPMEM как устройство хранения через тонкий слой файловой системы direct-access (DAX), либо замапить регион с устройства и получать к нему прямой доступ через байтовую адресацию. Такой режим может быть использован старыми или новыми приложениями, но работающими в новых версиях ОС, при этом версия Virtual Hardware должна быть не ниже 14.
• vPMEM-aware - это то же самое, что и vPMEM, но только с дополнительными возможностями приложения понимать, что машина использует такое устройство, и пользоваться его преимуществами.

Если виртуальная машина использует такие устройства, то она имеет очень существенные ограничения, которые на данный момент препятствуют их использованию в производственной среде. Они приведены в документе "vSphere Resource Management Guide" на странице 47 внизу. А именно:

• vSphere HA - полностью не поддерживается для машин с включенными vPMEM устройствами, вне зависимости от режима использования.
• vSphere DRS - полностью не поддерживается для машин с включенными vPMEM устройствами (машины не включаются в рекомендации и не мигрируют через vMotion), вне зависимости от режима использования.
• Миграция vMotion для машин с устройствами vPMEM / vPMEM-aware доступна только на хосты с устройствами PMEM.
• Миграция vMotion машин с устройством vPMEMDISK возможна на хост без устройства PMEM.

Будем надеяться, что эта ситуация в будущем изменится.

Некоторые администраторы VMware vSphere задаются вопросом, а для чего же нужна опция Dedicated failover hosts при настройке механизма Admission Control в кластере VMware HA:

Очень просто - это так называемые Spare Hosts, то есть запасные и всегда свободные хосты ESXi, которые берут на себя нагрузку по размещению виртуальных машин только в случае сбоев других серверов, обрабатываемых механизмом VMware HA.

Эти хосты в обычной жизни будут простаивать, и, если на них не удастся запустить виртуальные машины в случае сбоя, VMware HA все равно перезапустит эти ВМ на других хостах ESXi. Также эти хосты не будут браться в расчет механизмом VMware DRS, то есть он не будет мигрировать туда виртуальные машины, даже на период обслуживания других хостов (Maintenance mode).

Так для чего же такая настройка вообще существует, если выгоднее держать просто больше запаса емкости на хостах кластера HA, но использовать все серверы в нем? Вариантов может быть 2:

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

Оба этих варианта очень маловероятны, поэтому, как правило, настройку Dedicated failover hosts использовать вообще не нужно.

На днях компания VMware анонсировала доступность новой версии своей флагманской платформы виртуализации VMware vSphere 6.7 Update 2. Напомним, что предыдущее обновление VMware vSphere 6.7 Update 1 вышло в августе прошлого года.

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

1. Новое издание VMware vSphere ROBO Enterprise.

Теперь в издании для ROBO-сценариев (Remote or Branch Offices) появились следующие возможности уровня Enterprise:

DRS в режиме обслуживания (Maintenance Mode):

• Доступно только для vSphere ROBO Enterprise.
• Может быть использовано для автоматического перемещения ВМ между хостами (и обратно по окончании процесса). Для этого автоматически создаются правила VM-Host affinity (отслеживается, куда машины уехали перед миграцией, потом запомненные правила применяются - и машины приезжают обратно, где и были изначально).
• Применяются обычные требования vMotion.
• Никакого визуального механизма настройки DRS нет.

Шифрование машин (VM Encryption):

• Шифрование домашней директории и файлов VMDK.
• Требуется инфраструктура KMS.
• Полностью безразлично к гостевой ОС.
• Управляется через GUI или PowerCLI.

2. Обновление архитектуры vCenter Server.

Утилита PSC Converge tool теперь доступна в графическом интерфейсе. Об этом средстве мы писали вот тут, оно позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC.

Она дает следующие возможности:

• Конвертация топологии external PSC в Embedded через GUI.
• Можно выполнить шаги по выводу внешнего PSC из эксплуатации (Decomission).

• Все это доступно в разделе System Configuration тонкого клиента vSphere Client (на базе HTML5).
• Можно посмотреть текущую топологию PSC и vCenter в графическом или табличном виде.
• В следующих релизах будет невозможно развернуть внешний PSC, поэтому с него надо уходить.

3. Улучшения резервного копирования и восстановления vCenter Server.

Здесь появилось 2 главных улучшения:

• Новые протоколы, посредством которых вы можете сделать бэкап vCSA - NFS v3 и SMB.
• Нотификации и алармы на успешное и неуспешное завершение задач РК. Эти алармы можно настроить подобно обычным алармам vSphere (послать email, SNMP trap или выполнить сценарий в случае успеха или неудачи).

4. Новые алармы и категории для vSphere Health.

• Опция acknowledgement (заглушить) для алармов vSphere health (как и для обычных алармов).
• Новые категории теперь включают в себя:
  • Online Availability
  • Compute
  • Network
  • Storage
• Эти новые категории позволяют более органично охватывать проблемы сервера vCenter и упрощать управление им.

5. Улучшения Content Library.

• Функции синхронизации шаблонов VM Template (VMTX).
• Шаблоны виртуальных машин теперь можно синхронизировать в автоматическом режиме, как между приватными облаками с серверами vCenter, так и с публичным облаком VMware Cloud on AWS.

6. Улучшения vSphere Client.

• В vSphere Client появилась возможность "code capture" (о ней мы писали вот тут). Теперь она позволяет вести запись пользовательских действий, которые были сделаны в рамках текущей сессии через vCenter API, и генерация соответствующего скрипта. Далее его можно использовать для автоматизации задач в инфраструктуре vSphere.
• Функции API Explorer (доступны в разделе "Developer Center") - простая утилита по поиску в API, которая позволяет найти основные API-вызовы, включая примеры и возможность их тестирования.

• Улучшения пользовательского интерфейса, включая функции attach, compliance check и remediation (все можно делать на одном экране).
• Теперь можно привязать и сделать remediate для нескольких бейслайнов в рамках одной операции.
• Во время remediation можно отключать removable-девайсы от виртуальных машин, включать Quickboot и пропускать проверки vSAN HealthCheck.

8. Улучшения VMware Tools.

• Для Windows Server 2016 тулзы теперь обновляются через Windows update, а значит, что их обновления включены в общий цикл апдейта системы.
• Версия VMware tools for Linux (в формате .TAR) больше не развивается, начиная с VMware Tools 10.3.10, так как OpenVM Tools доступны через любой package update manager.

9. Фикс Host Profiles.

Теперь при применении профиля хоста к ESXi не удаляется интерфейс VMK0, как это было раньше.

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

• Windows Server 2019 и RHEL 8 теперь полностью поддерживаются в vSphere 6.7 Update 2.
• Можно применять лимиты для Password History и Reuse.
• Теперь логируются дополнительные события SSO.
• Улучшения ESXi certification API.
• Генерация запроса vCenter Server CSR доступна через GUI клиента.
• vSphere 6.7 Update 2 лучше обрабатывает уязвимости CPU за счет нового планировщика.
• Доступна сертификация NIAP.

11. Улучшения производительности.

• Поддержка 40 & 100Gb Ethernet и RDMA
• Новая версия Virtual Hardware 15 (VM Compatibility):
  • До 256 vCPU на виртуальную машину
  • До 6 ТБ RAM на ВМ
  • Поддержка SAP HANA

На момент написания статьи обновление VMware vSphere 6.7 Update 2 было еще недоступно. Мы обновим пост, когда обновление можно будет скачать.

Весной 2018 года Selectel запустил услугу резервного копирования для Облака на базе VMware посредством Veeam® Backup&Replication™ (далее VBR). К реализации проекта мы подошли основательно, спланировали и выполнили следующий перечень работ:

• Изучение документации и лучших практик по продуктам Veeam
• Разработку архитектуры VBR уровня сервис-провайдера
• Развертывание инфраструктуры VBR

Сейчас трудно представить себе сферу деятельности, в которой доступность IT-инфраструктуры стояла бы на последнем месте. С ростом критических для бизнеса сервисов данный вопрос встает все острее, и сегодня мы хотим рассмотреть варианты резервирования инфраструктуры на удаленной DR-площадке IaaS-провайдера и кейсы, в контексте которых они подходят в качестве стратегии business continuity.

Давайте для начала определимся с базовыми понятиями, которыми оперируют IT-специалисты при разработке плана повышения доступности и без которых невозможно принять взвешенное и объективное решение по его реализации. Подготовка подобного плана всегда включает в себя обязательный диалог между IT и бизнесом, от чьих интересов и особенностей мы всегда должны отталкиваться. И первый вопрос в данном диалоге должен звучать так: Какое время простоя сервисов компании в случае отказа информационных систем не окажет ощутимого воздействие на бизнес? Можно сразу ответить: никакое, ведь любая нештатная ситуация, приводящая к прекращению предоставления услуг, неприятна. Но следует понимать, что организация нулевого даунтайма может обойтись бизнесу дороже, чем потенциальные потери, которые может понести компания, выстроив план так, что время восстановления после сбоя займет, к примеру, 4 часа.

Данное понятие называется RTO (recovery time objective) и его суть сводится к определению времени, за которое работоспособность того или иного сервиса должна быть восстановлена. Мы говорим про сервисы, а не про инфраструктуру в целом, потому что у каждого сервиса есть свой cost и RTO должен рассчитываться применительно именно к сервисам, а не к инфраструктуре в целом. Ведь, к примеру, без сервера печати можно прожить чуть дольше, чем без CRM или сайта компании, если он располагается на вашей площадке.

Следующим в данном диалоге будет вопрос о критичности потери наработанной информации. К примеру, в компании резервное копирование данных происходит ежедневно в 6:00 утра. Люди приходят на работу, вносят изменения в базы, получают новую почту, модернизируют приложение… А вечером происходит критический сбой всех наших систем, и все, что у нас есть, – это резервные копии на момент начала рабочего дня. Если изменений немного и они не критичны, то ничего страшного – восстанавливаемся и работаем дальше. Но если это не так и откат до существующей точки восстановления по тем или иным причинам невозможен без существенных потерь для бизнеса?

Подобный вопрос описывается параметром RPO (recovery point objective) – то есть точка состояния критичных данных, к которой допустимо вернуться в случае сбоя. К примеру, для сервера баз данных мы определяем этот параметр равный 1 часу. Это значит, что актуальная резервная копия данных...Читать статью далее->>
Таги: IT-Grad, DR, IaaS, DRaaS

Политики хранилищ 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:

• Storage Policy Based Management
• Populating the VM Storage Policies Interface
• Assign Tags to Datastores
• Storage DRS Integration with Storage Profiles

Как знают многие пользователи решения для создания отказоустойчивых кластеров 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 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 (генерация рекомендаций по размещению виртуальных машин).

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

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

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

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

• PowerShell скрипт для автоматической установки ESXi хостов на серверах IBM/Lenovo
• Как получить расширенную информацию об RDM-дисках с помощью PowerCLI
• Как конвертировать «тонкие» VMDK-диски в Eager Zeroed Thick с помощью VMware PowerCLI
• Как найти хост ESXi с виртуальными машинами VMware vCenter и SQL Server, когда они выключены?
• Команда Connect-VIServer в PowerCLI: глубокое погружение или «куда же я подключен?»
• Как скопировать VMware ВМ Notes в Computer/AD Computer Account description
• Как узнать версию BIOS/Firmware ESXi сервера при помощи PowerCLI
• Как узнать дату и время установки хоста ESXi
• Как сравнить установленные VIB packages между двумя и более хостами ESXi
• Как включить/отключить SSH на всех хостах ESXi в кластере при помощи PowerCLI
• Как задать/изменить NTP-серверы для хостов ESXi с помощью PowerCLI
• Как узнать версию любого объекта VMware? Используйте Get-Version!
• Azure Automation: как включить/выключить ВМ в облаке Microsoft Azure по расписанию
• Автоматизация работы с тегами Azure VM
• Как найти потерянные VHD файлы в облаке Azure IaaS?
• Как просматривать датасторы VMware с помощью PowerCLI
• Как сравнить 2 или более хостов VMware ESXi с помощью PowerCLI
• Как мигрировать VMware VM Templates на другой Datastore с помощью PowerCLI
• PowerShell и putty – лучше вместе
• Как получить информацию о графическом процессоре ESXi с помощью PowerCLI
• Как проверить наличие хотфикса в VMware ВМ с помощью PowerCLI
• Как конфигурировать Storage DRS кластеры с PowerCLI – Часть 1
• Как создавать и удалять SDRS Anti-Affinity правила с PowerCLI – Часть 2
• Как конфигурировать SDRS Anti-Affinity правила с PowerCLI – Часть 3
• Как увеличить VM Guest Partition с помощью PowerCLI
• Сохранять и извлекать учетные данные с помощью PowerCLI
• Как узнать срок годности резервных копий vCSA с помощью PowerCLI?
• Как получить данные CDP протокола с помощью PowerCLI
• Как мониторить задачи Nutanix с PowerShell

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

Недавно мы писали про обновление VMware Tools и Virtual Hardware для виртуальных машин на платформе VMware vSphere через PowerCLI. Эта заметка была опубликована как перевод одной из статей цикла об апгрейде VMware vSphere и ее компонентов на версии 6.7 и выше. Сегодня мы поговорим об обновлении кластерной файловой системы хранения ВМ VMFS-5 на следующую версию - VMFS-6.

Напомним, что VMFS-6 впервые появилась в VMware vSphere 6.5 и с тех пор сильно не изменялась, но если посмотреть на отличия шестой версии от пятой, то они весьма существенные:

Как мы видим, основных отличий четыре:

• Доступ к хостам ESXi 6.0 и более ранних к VMFS-6 уже невозможен.
• В VMFS-6 присутствуют функции Automatic space reclamation (он же Automatic VMFS UNMAP), доступные также через PowerCLI.
• Функции возврата дискового на уровне гостевой ОС ограничены в VMFS-5.
• Нативная поддержка 4K native storage.

Последний пункт как раз и стал причиной того, что произошло изменение в структуре метаданных томов, а значит VMFS-5 нельзя проапгрейдить до VMFS-6. Альтернативой является создание нового датастора VMFS-6, перемещение туда всех виртуальных машин и удаление старого.

Создаем новый VMFS-6:

Перемещаем туда все виртуальные машины тома VMFS-5 через Storage vMotion или Cold migration и удаляем его:

Как стало понятно, для такого "апгрейда" датастора VMFS-5 вам потребуется еще столько же места на другом датасторе или готовом к форматированию под VMFS-6 хранилище, чтобы переместить туда виртуальные машины.

Чтобы посмотреть текущие версии VMFS с помощью PowerCLI, нужно выполнить команду:

Get-Datastore | Select Name, FileSystemVersion | Sort Name

Перед началом процесса апгрейда нужно ознакомиться со статьей KB "Migrating VMFS 5 datastore to VMFS 6 datastore". Для миграции надо использовать командлет Update-VmfsDatastore, который также делает некоторые проверки перед миграцией.

При этом надо учитывать несколько моментов:

• На время миграции нужен датастор VMFS-5 такой же или большей свободной емкости.
• Машины перемещаются средствами Storage vMotion на временное хранилище.
• Командлет убеждается, что на датасторе не осталось ВМ, миграция которых не поддерживается (это машины с поддержкой SRM, VADP, VRM и Clustering).
• Командлет временно отключает механизм Storage DRS при своей работе (и включает по окончании). Если сценарий во время исполнения упадет, то вам придется включать Storage DRS вручную.
• Нужно внимательно изучить использование параметров Resume и Rollback в случае появления ошибок.

Посмотрим, какие последовательные действия делает сценарий:

1. Проверяет наличие ВМ с поддержкой VADP, SMPFT, MSCS/RAC на исходном датасторе.
2. Убеждается, что датастор доступен со всех хостов.
3. Валидирует, что временный датастор имеет достаточно емкости для размещения виртуальных машин.
4. Устанавливает функцию Storage DRS Automation в режим manual.
5. Размонтирует исходный датастор.
6. Удаляет старый датастор и создает на его месте новый датастор VMFS-6.
7. Перемещает ВМ и другие данные со временного датастора на новый.
8. Восстанавливает настройку Storage DRS Automation.

Теперь, собственно, как использовать командлет Update-VmfsDatastore:

Connect-VIServer ds-vcsa-03.cpbu.lab

$Source = Get-Datastore "DS02"

$Temp = Get-Datastore "DS-TEMP"

$Server = (Get-VIServer -Server "ds-vcsa-03.cpbu.lab")
Update-VmfsDatastore -Datastore $Source -TemporaryDatastore $Temp -TargetVmfsVersion "6" -Server $Server

Если у вас что-то пошло не так, вы сможете использовать параметр rollback для отката, а также если возникают ошибки, то после их исправления можно использовать параметр resume.

Больше об использовании командлета Update-VmfsDatastore написано вот тут.

На сайте проекта VMware Labs появился полезный плагин DRS Dump Insight H5 Plugin, который добавляет функции утилиты DRS Dump Insight в HTML5-интерфейс vSphere Client на сервере vCenter Server Appliance (vCSA).

Напомним, что сервис DRS Dump Insight - это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. После этого будет выведена информация об операциях по перемещению виртуальных машин, которые рекомендует выполнить механизм балансировки нагрузки DRS:

Плагин DRS Dump Insight в вашем vCSA позволит ответить на следующие вопросы:

• Где взять список всех рекомендаций DRS?
• Почему DRS выдал конкретную рекомендацию (улучшить баланс по CPU, по памяти и т.п.)?
• Почему DRS не вырабатывает рекомендации по балансировке кластера?
• Как созданное пользователем правило affinity/anti-affinity влияет на балансировку ресурсов в кластере?
• Если применить некоторую политику в кластере, как изменится балансировка ресурсов DRS?

При установке DRS Dump Insight H5 Plugin нужно выполнить следующие действия:

• Проверить версию vCenter Server Appliance - подходит только 6.5 и 6.7.
• Положить пакет с плагином в папку /usr/lib/vmware-vsphere-ui/plugin-packages/ на сервере vCSA.
• Добавить настройку CompressDrmdumpFiles со значением "0" в advanced options кластера.
• Перезапустить службу графического интерфейса vsphere-ui командами:
  • service-control --stop vsphere-ui
  • service-control --start vsphere-ui

После установки на вкладке Monitor для каждого кластера вы увидите раздел "DRS Dump Insight".

Загрузить DRS Dump Insight H5 Plugin можно по этой ссылке (в комбо-боксе выберите версию для своего vCenter).

Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 6.7 Update 1, которая была анонсирована на прошедшей конференции VMworld 2018. Одновременно с этим было объявлено и о скором релизе обновленной версии решения для создания отказоустойчивых хранилищ на базе серверов VMware vSAN 6.7 Update 1.

Напомним, что о прошлой версии VMware vSAN 6.7 мы писали вот тут, а теперь давайте посмотрим, что нового появилось в Update 1 к этой версии:

1. Новый мастер Cluster quickstart.

Новый мастер создания кластера включает в себя следующие процессы:

• Развертывание сервисов, таких как vSphere HA, vSphere DRS и vSAN.
• Добавление хостов (несколько хостов одновременно).
• Тип развертывания vSAN.
• Сетевая конфигурация, включая vSphere Distributed Switching и Enhanced vMotion Compatibility (EVC).
• Конфигурация дисковых групп.
• Сервисы дедупликации, компрессии и шифрования.

Посмотреть в деле этот мастер создания кластера можно вот тут.

2. Обновление драйверов и firmware через Update Manager.

Теперь через vSphere Update Manager (VUM) можно обновить микрокод контроллера ввода-вывода с помощью утилиты обновления драйверов от вендора сервера. Таким образом, обновление драйвера I/O-адаптера можно включить в цикл обновления хоста и не заниматься этим отдельно.

Также VUM будет поддерживать кастомные OEM-образы от производителей серверов, а также офлайн процедуры обновления хостов ESXi.

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

3. Механизмы защиты при выводе хостов из эксплуатации и переводе в режим обслуживания.

Теперь в vSAN 6.7 U1 появились предварительные проверки при переводе хостов в режим обслуживания (Maintenance mode) и выводе из эксплуатации (Decomission). В этом случае с помощью симуляции проверяется, смогут ли все машины хоста успешно переместиться на другие серверы, и только в этом случае запускается реальный процесс.

Это устраняет временные затраты на потенциально неуспешные попытки операций с хост-серверами.

Также были добавлены новые оповещения о том, что идет процесс синхронизации и о том, что в режиме обслуживания нет других серверов в кластере. Кроме этого, была добавлена настройка "object repair timer delay", которая задает интервал времени до начала операций по ребилду кластера vSAN для приведения в соответствие с политиками хранилища.

4. Разные представления vROPs для обычных и растянутых кластеров vSAN.

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

Более подробно об этом можно почитать тут.

5. Улучшенные возможности Capacity reporting.

Отчеты по используемой емкости (Capacity reporting) дают информацию о доступном хранилище, в зависимости от выбранной политики хранилищ (Storage policy):

Также можно посмотреть, сколько хранилища потребуется, если отключить функции дедупликации и компрессии:

Ну и можно посмотреть историю использования пространства в кластере vSAN с учетом изменений в коэффициентах дедупликации и компрессии:

6. Поддержка TRIM/UNMAP.

Это возможности по возвращению неиспользуемого дискового пространства обратно в доступную емкость vSAN. Возможности TRIM/UNMAP позволяют вернуть пространство в кластер для множества гостевых ОС и конфигураций машин.

7. Поддержка режима Mixed MTU для растянутых кластеров.

В vSAN 6.7 появилась возможность выделить трафик Witness на отдельный аплинк серверов, а в Update 1 добавили функцию конфигурации MTU Size для трафика Witness отдельно от MTU Size для межсайтового трафика:

8. Обновленные средства для сайзинга инфраструктуры.

vSAN 6.7 Update 1 предоставляет пользователям улучшенные средства по планированию инфраструктуры и определения ее будущих характеристик. Отчет по окружению и производительности (HCI Assessment):

Планирование узлов ReadyNode для поддержания заданных нагрузок (vSAN Sizer):

9. Улучшенные функции Health Check.

Теперь они охватывают еще и firmware контроллеров хранилищ, интеграция с которыми появилась в этой версии vSAN:

Также с помощью тестов сетевого окружения vSAN можно получить отчет о том, какая пропускная способность доступна в сети. Кроме этого, в Health Check появилась проверка недоступности swap-объектов (см. на картинке выше).

10. Улучшенная диагностика для персонала поддержки VMware GSS.

Напомним, что в vSAN есть встроенные средства диагностики и поддержки vSAN Support Insight, которые получили развитие в этом обновлении. Теперь в vSAN 6.7 Update 1 есть детализированные графики производительности в различных аспектах (особенно полезны в плане сетевого взаимодействия):

Функция Network diagnostic mode предоставляет инженерам VMware GSS данные о состоянии сети, что облегчает работу с обращениями в техподдержку и уменьшает объем собираемых и передаваемых в VMware саппорт-бандлов.

Как ожидается, обновленное решение VMware vSAN 6.7 Update 1 будет доступно одновременно с VMware vSphere 6.7 Update 1 до ноября этого года. Будем держать вас в курсе.

Продолжаем рассказывать о новых продуктах и технологиях, анонсированных на проходящей сейчас в Лас-Вегасе конференции VMworld 2018. Вчера мы писали о новых возможностях VMware vSphere 6.7 Update 1, а сегодня расскажем о нововведениях средства для комплексного управления и мониторинга виртуальной инфраструктуры VMware vRealize Operations 7.0 (vROPs). Напомним, что о прошлой версии vROPs 6.7 мы писали вот тут.

Как и прежде, обновление vROPs сфокусировано на возможностях "self-driving", то есть вы будете определять цель оптимизаций, а движок будет в постоянном режиме генерировать рекомендации по их достижению и выполнять операции по автоматизации (Intelligent Remediation).

Давайте посмотрим на новые возможности vROPs 7.0:

1. Улучшенный пользовательский интерфейс.

Теперь операции и рабочие процессы стали проще, а персонифицированный дэшборд "Quick Start" делает процесс выполнения ежедневных задач более удобным.

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

Еще в версии vROPs 6.7 появились функции автоматизации на базе поставленных целей (operational или business). Теперь же появилась магическая кнопка "Automate", при нажатии на которую vROPs сам определит возможности по оптимизации и начнет исполнять их.

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

3. Расширенные возможности размещения виртуальных машин со стороны DRS на базе бизнес-критериев.

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

Например, вы можете выделить разные хосты для хранения Windows, Linux и BSD машин в целях соблюдения лицензионных особенностей:

4. Улучшенные прогнозы по использованию ресурсов.

В этой категории появилось 2 основных улучшения:

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

5. Планирование емкости - как в собственном облаке, так и в публичном облаке VMware Cloud on AWS.

Новая методика анализа "что если" (what-if analysis), которая реализует 3 основных сценария:

• Планирование объема нагрузки, чтобы выяснить необходимые емкости под новые ВМ.
• Планирование физической инфраструктуры (то есть закупок железа с оценкой капитальных затрат).
• Планирование холодных миграций в облако VMware Cloud on AWS (либо изначального размещения там) с детальной оценкой затрат и необходимых емкостей по ресурсам.

6. Упрощенное создание дэшбордов и их расшаривание.

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

7. Обновление vRealize Operations AWS Management Pack.

Теперь появилось 28 новых дэшбордов, с помощью которых можно управлять рабочими нагрузками в облаке AWS в различных регионах. Также можно получить доступ к инвентори всех сервисов и их состоянию, а также отключить избыточные ресурсы. Кроме этого, можно получить рекомендации по оптимизации инстансов EC2. Со стороны AWS предоставляется поддержка для всех сервисов - EC2, RDS, EBS, LB, Lambda, Redshift и других.

8. Прочие улучшения.

• Функция Workload Right-sizing, которая предотвращает затыки производительности, а также позволяет определить неиспользуемые ресурсы.
• Встроенные функции комплаенса для vSphere по стандартам PCI, HIPAA, DISA, FISMA, ISO и CIS.
• Возможность расширить обычный и облачный датацентр с помощью management packs для компонентов Storage, vRealize Orchestrator, Kubernetes, Federation и других.
• Возможность траблшутинга, мониторинга емкости и производительности vSAN, включая поддержку растянутых кластеров через vRealize Operations plug-in в vCenter.
• Интеграция с решением VMware Wavefront для оперирования на уровне приложений.

Пока о дате релиза VMware vRealize Operations 7.0 ничего не известно - будем держать вас в курсе. Основная страница продукта расположена здесь.

На днях в Лас-Вегасе началась конференция VMworld 2018 - главное в году событие в сфере виртуализации. Компания VMware уже в первый день представила немало анонсов новых продуктов и решений, но одним из главных стало объявление о выпуске обновления серверной платформы виртуализации VMware vSphere 6.7 Update 1.

На картинке выше приведены 5 основных новых возможностей vSphere 6.7 U1, давайте посмотрим на них поближе:

1. Полнофункциональный VMware vSphere Client на базе HTML5.

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

Теперь клиент на HTML5 включает в себя не только все старые рабочие процессы, но и новые возможности, такие как упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM). Теперь нет нескольких рабочих процессов, делающих то же самое (раньше были Basic и Advanced), а также улучшились функции работы с Content Library, появился расширенный поиск, упростилась настройка запланированных задач и появились графики top-N (топы по использованию ресурсов).

2. Утилита 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.

Теперь вам не нужны сложные HA-топологии PSC с балансировщиками на разных площадках, серверы vCSA с внедренными PSC на них можно просто соединить между собой.

Утилита vCenter Server Converge Tool работает из командной строки (команда vcsa-converge-cli) и поставляется в комплекте с установщиком vCSA. Ее можно запускать в ОС Windows, macOS и Linux, а конфигурируется она через файл в формате JSON:

Еще одна задача, которая была решена - vCenter Server с компонентом embedded PSC теперь можно перенаправить на другой домен vSphere SSO (это позволяет более гибко распределять и разделять домены SSO в корпоративной инфраструктуре). Ранее это было сделано только для внешних SSO, а теперь доступно и для vCSA.

3. Новая версия vSAN и улучшения HCI.

В новой версии vSAN появилась функция Cluster Quickstart, которая позволяет инициализировать кластер, добавить в него хосты и накатить идентичную конфигурацию на них. Она включает в себя настройку механизмов HA и DRS, Enhanced vMotion Compatibility (EVC), датасторов vSAN и сетевого взаимодействия, включая Virtual Distributed Switch (VDS).

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

Также появилась интеграция микрокода контроллера ввода-вывода с vSphere Update Manager (VUM), который использует утилиту обновления драйверов от вендора сервера. Таким образом, обновление драйвера I/O-адаптера можно включить в цикл обновления хоста и не заниматься этим отдельно.

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

4. Улучшения Content Library.

Теперь OVA-шаблоны можно импортировать из HTTPS-источника или с локального хранилища. Также содержимое OVA-пакетов можно синхронизировать между несколькими серверами vCSA (сами шаблоны синхронизировать пока нельзя). Content Library обрабатывает сертификаты и файлы манифеста, входящие в OVA-пакеты в соответствии с лучшими практиками безопасности.

Content Library также нативно поддерживает формат шаблонов VMTX и ассоциирует с ними операции, такие как развертывание ВМ напрямую из Content Library.

5. vMotion для карточек NVIDIA Quadro vDWS и поддержка Intel FPGA.

Теперь технология NVIDIA Quadro vDWS (ранее она называлась GRID) для vGPU поддерживается со стороны vSphere 6.7 Update 1. Напомним, что ранее была введена поддержка операций Suspend/Resume для GRID, а теперь появилась и поддержка горячей миграции vMotion для машин с привязкой к карточкам NVIDIA Quadro vDWS. Это позволит обновлять хосты с тяжелыми операциями (например, десктопы с CAD-приложениями) без прерывания работы пользователей.

Также VMware объявила о поддержке карточек Intel Programmable Acceleration Card с технологией Intel Arria 10 GX FPGA. Эта технология позволяет получить прямой доступ к оборудованию с помощью механизма VMware DirectPath I/O через Intel Acceleration Stack для процессоров Intel Xeon CPU с FPGA.

Также в рамках VMworld 2018 было анонсировано новое издание - vSphere Platinum, которое предоставляет расширенные функции обеспечения безопасности для корпоративной инфраструктуры. О нем мы расскажем в следующей статье.

О дате доступности для загрузки обновления VMware vSphere 6.7 Update 1 пока не сообщается.

В последней версии платформы виртуализации VMware vSphere 6.7 появилась новая возможность - поддержка Persistent Memory (PMEM). Это новый вид памяти, который покрывает разрыв между оперативной памятью (RAM) и дисковой памятью (Flash/SSD) с точки зрения быстродействия и энергонезависимости.

PMEM имеет 3 ключевые характеристики:

• Параметры задержки (latency) и пропускной способности (bandwidth) как у памяти DRAM (то есть примерно в 100 быстрее, чем SSD).
• Процессор может использовать стандартные байт-адресуемые инструкции для сохранения данных и их подгрузки.
• Сохранение значений в памяти при перезагрузках и неожиданных падениях устройства хранения.

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

А ее характеристики соотносятся с SSD и DRAM памятью следующим образом:

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

На данный момент vSphere 6.7 поддерживает 2 типа решений PMEM, присутствующих на рынке:

• NVDIMM-N от компаний DELL EMC и HPE - это тип устройств DIMM, которые содержат как DRAM, так и модули NAND-flash на одной планке. Данные передаются между двумя модулями при загрузке, выключении или любом событии, связанном с потерей питания. Эти димы поддерживаются питанием с материнской платы на случай отказа. Сейчас обе компании HPE и DELL EMC поставлют модули 16 GB NVDIMM-N.
• Модули Scalable PMEM от компании HPE (доступно, например, в серверах DL380 Gen10) - они позволяют комбинировать модули HPE SmartMemory DIMM с устройствами хранения NVMe (интерфейс Non-volatile Memory дисков SSD) и батареями, что позволяет создавать логические устройства хранения NVDIMM. Данные передаются между DIMMs и дисками NVMe. Эта технология может быть использована для создания систем с большим объемом памяти PMEM на борту.

При этом накладные затраты на использование виртуализации с устройствами PMEM не превышают 3%. Вот так выглядят примерные численные характеристики производительности памяти NVMe SSD и NVDIMM-N по сравнению с традиционными дисками:

С точки зрения предоставления памяти PMEM виртуальной машине, есть 2 способа в vSphere 6.7:

• vPMEMDisk - vSphere представляет PMEM как обычный диск, подключенный к виртуальной машине через контроллер SCSI. В этом случае ничего не нужно менять для гостевой ОС или приложений. В таком режиме работают любые системы, включая старые ОС и приложения.
• vPMEM - vSphere представляет PMEM как устройство NVDIMM для виртуальной машины. Большинство последних версий операционных систем (например, Windows Server 2016 и CentOS 7.4) поддерживают устройства NVDIMM и могут предоставлять их приложениям как блочные или байт-адресуемые устройства. Приложения могут использовать vPMEM как устройство хранения через тонкий слой файловой системы direct-access (DAX), либо замапить регион с устройства и получать к нему прямой доступ через байтовую адресацию. Такой режим может быть использован старыми или новыми приложениями, но работающими в новых версиях ОС, при этом версия Virtual Hardware должна быть не ниже 14.

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

Если у вас хост VMware ESXi имеет на борту устройства с поддержкой PMEM, вы можете увидеть это в его свойствах в разделе Persistent Memory:

При создании новой виртуальной машины вы сможете выбрать, какое хранилище использовать для нее - стандартное или PMem:

Параметры диска на базе PMEM можно установить в разделе Customize hardware:

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

Если же вы хотите добавить хранилище в режиме vPMEM, то надо указать соответствующий объем использования устройства в разделе New NVDIMM:

Надо отметить, что хранилище PMEM может быть на хосте ESXi только одно и содержит только устройства NVDIMM и виртуальные диски машин (то есть вы не сможете хранить там файлы vmx, log, iso и прочие). Для такого датастора единственное доступное действие - это просмотр статистик (при этом в vSphere Client на базе HTML5 датасторы PMEM вообще не видны). Вывести статистику по устройствам PMEM можно командой:

# esxcli storage filesystem list

Пример результатов вывода:

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

Что касается миграции ВМ с устройством PMEM, то особенности этой миграции зависят от режима использования машиной устройства. Для миграции между хостами ESXi машины с PMEM включается не только vMotion, но и Storage vMotion, а на целевом хосте должно быть достаточно места для создания резервации от мигрируемой машины. При этом машину с хранилищем в режиме vPMEMDisk можно перенести на хост без устройства PMEM, а вот машину с vPMEM - уже нет.

В самом плохом случае при миграции ВМ с хранилищем NVMe SSD ее простой составит всего полсекунды:

Технологии VMware DRS и DPM (Distributed Power Management) полностью поддерживают память PMEM, при этом механизм DRS никогда не смигрирует машину, использующую PMEM на хосте, на сервер без устройства PMEM.

VMware недавно провела тестирование памяти PMEM с помощью различных бенчмарков и описала результаты в документе "Persistent Memory Performance on vSphere 6.7 - Performance Study". Приведем некоторые графики из него:

1. Бенчмарк FIO для latency:

vPMEM-aware - это использование устройства PMEM гостевой ОС, которая умеет работать с модулем PMEM на хосте через прямой доступ к постоянной памяти устройства.

2. Бенчмарк FIO для пропускной способности (Throughput):

3. Бенчмарк HammerDB для Oracle, тестирование числа операций в секунду:

4. Тест Sysbench для базы данных MySQL, тестирование пропускной способности в транзакциях в секунду:

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

Документация на тему использования Persistent Memory в VMware vSphere 6.7 доступна тут и тут.

Компания VMware наконец-то обновила свой главный документ о производительности основной платформы виртуализации - "Performance Best Practices for VMware vSphere 6.7". Несколько ранее мы писали о документе "What’s New in Performance - VMware vSphere 6.7", в котором были рассмотрены основные нововведения последней версии продукта в плане производительности, но там было всего 13 страниц, а в этой книге о производительности - аж 88!

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

• Hardware-assisted virtualization
• Storage hardware considerations
• Network hardware considerations
• Memory page sharing
• Getting the best performance with iSCSI and NFS storage
• Getting the best performance from NVMe drives
• vSphere virtual machine encryption recommendations
• Running storage latency-sensitive workloads
• Network I/O Control (NetIOC)
• DirectPath I/O
• Running network latency-sensitive workloads
• Microsoft Virtualization-Based Security (VBS)
• CPU Hot Add
• 4KB native drives
• Selecting virtual network adapters
• The vSphere HTML5 Client
• vSphere web client configuration
• Pair-wise balancing in DRS-enabled clusters
• VMware vSphere update manager
• VMware vSAN performance

Штука эта, очевидно, обязательна к прочтению администраторам vSphere, которые хотят, чтобы у них в инфраструктуре все работало без сбоев и не тормозило.

Несколько интересных моментов из документа:

• Начиная с версии vSphere 6.7, платформа больше не поддерживает программную виртуализацию CPU (только аппаратную).
• vSphere Flash Read Cache (vFRC) может негативно влиять на производительность vMotion.
• Для VVols массив сам обнуляет блоки перед созданием тома, поэтому нет возможности указать тип диска "eager" или "lazy".
• Если вы используете виртуальный сетевой адаптер старой модели с пониженной пропускной способностью, например, Vlance, который показывает в гостевой ОС 10 Мбит/с - это не значит, что он будет работать на этой скорости. Он будет работать на скорости, максимально поддерживаемой физическим оборудованием и хостом ESXi.

Остальные полезные фишки - в документе.

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

Мы много пишем о технологии Virtual Volumes (VVols) - например, тут, тут и тут. Она позволяет более гибко подходить к хранению объектов виртуальных машин за счет передачи некоторых функций работы с их данными на сторону хранилищ.

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

Для ПО резервного копирования тома виртуальные машины на томах VVols выглядят аналогично таковым на томах VMFS, поэтому ни схема, ни средства резервного копирования в инфраструктуре VVols не изменяются:

Резервное копирование делается через механизм vSphere APIs for Data Protection (VADP), который создает снапшот на хранилище, чтобы после его создания ПО для бэкапа могло забрать диски с данными ВМ. Отличие тут в том, что в этой схеме снапшот ВМ делает программное обеспечение дискового массива, на сторону которого передаются операции по работе со снапшотами и другие функции.

Кстати, интересная штука - стандартно для виртуальной машины в VMware vSphere можно сделать до 32 снапшотов, хотя VMware рекомендует делать их не более 2-3 в одной цепочке, так как большее количество может привести к различного рода проблемам. А вот с аппаратными снапшотами на томах VVols можно сделать 32 снапшота, и это никаких проблем не повлечет.

На массивах с поддержкой VVols есть поддержка операций "consolidate" и "revert" для снапшотов. В среде VVols они работают по-другому: там есть базовый VMDK, который всегда остается таковым, и куда идет запись, а также вместо записи изменений в redo log там есть read-only файлы снапшотов, которые не подцепляются в зависимую цепочку. При откате снапшота с базовым VMDK никаких длительных последовательных операций не производится (в отличие от VMFS), соответственно все это делать можно безопасно (подробнее - тут).

Также важно помнить, что использование Change Block Tracking (CBT) и vMotion для виртуальных машин на томах VVols может привести к порче данных (подробнее об этом тут). Эта проблема уже решена, но ее исправления будут доступны в следующих релизах vSphere 6.0, 6.5 и 6.7, а пока отключайте DRS для кластеров с виртуальными машинами на томах VVols.

На момент написания статьи VVols поддерживается для работы в трех режимах резервного копирования:

• Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
• Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
• Защищенное резервное копирование по Ethernet (NBDSSL) - то же самое, что и NBD backup, только с использованием SSL-шифрования при соединении через TCP/IP.

А вот метод без использования сети Ethernet (SAN-to-SAN backup) по-прежнему не поддерживается. Это происходит потому, что для в традиционной инфраструктуре VMFS есть виртуальный хост backup proxy, который говорит виртуальному модулю резервного копирования, какие блоки нужно читать по сети SAN. В среде VVols через VASA API компонент VASA provider на стороне физического сервера или дискового массива пока не может построить физический SAN-путь от хоста ESXi с томом VVols.

VASA provider нуждается в защите (если он реализован в виде виртуальной машины), так как он содержит в себе структуру томов VVols (и маппинги машин к устройствам), и если этот компонент будет потерян, то вы полностью потеряете управление над хранилищами (запущенные машины при этом еще будут работать).

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

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

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

Для vMotion и SVMotion есть вот такой скрипт от Luc Dekens, который экспортирует миграции за указанное число часов или дней в файл XLS. Запустить его можно такой командой (скрипт точно работает для vSphere 6.5, как пишут здесь):

get-motionhistory -Entity (get-cluster "Cluster 1" | get-vm) -Days 2 | Export-csv -NoTypeInformation -UseCulture E:\VMware\Prod_vMotions.csv

На выходе будет вот такая табличка (обратите внимание, что миграции поделены на пользовательские и системные от DRS/SDRS, а также в поле Type указано, что это - vMotion или SVMotion):

Также ребята из компании Opvisor несколько адаптировали этот скрипт в разрезе миграций хранилищ Storage vMotion для подсчета общего объема миграций и выложили его тут. Работа этого скрипта дает вот такой результат:

Вслед за открытием филиала группа компаний «ИТ-ГРАД» запустила новую облачную площадку в Республике Беларусь. Облачная инфраструктура провайдера разместилась в beCloud – республиканском центре обработки данных, обладающем сертификацией Uptime Institute по уровню надежности Tier III, а также сертификатом PCI DSS. Собственная инфраструктура компании построена с использованием лучших в своем классе решений, не имеет единой точки отказа, что позволяет гарантировать высокий коэффициент доступности услуг.

«Запуск новой облачной платформы дает возможность белорусским заказчикам получить качественный сервис корпоративного уровня. Десятилетний опыт работы, отлаженные бизнес-процессы, надежность используемых решений и технологий – все это позволяет размещать в нашем облаке самые требовательные приложения», – комментирует Сергей Чуканов, директор по развитию «ИТ-ГРАД».

Открывшаяся площадка является первой площадкой «ИТ-ГРАД» в Беларуси и пятой по счету наряду с уже имеющимися в Москве, Санкт-Петербурге, Хельсинки и Алматы. При этом ключевым сервисом является IaaS – инфраструктура как сервис. Параллельно с этим «ИТ-ГРАД» готов предложить белорусским заказчикам дополнительные услуги – облачное резервное копирование, мониторинг, администрирование инфраструктуры, построение гибридного облака, облачную площадку для аварийного восстановления (DRS), хостинг корпоративных учетных систем, корпоративную почту и другие виды сервиса.

Отметим, что в основе облачной инфраструктуры «ИТ-ГРАД» лежит эталонная архитектура FlexPod – совместная разработка NetApp и Cisco, что позволяет объединять сетевое оборудование, серверы и системы хранения данных в единое целое. Такой подход обеспечивает гибкость и масштабируемость инфраструктуры, а использование SSD-дисков гарантирует высокую производительность.

На сайте проекта VMware Labs появилось второе (со времени выхода VMware vSphere 6.7) обновление HTML5-клиента для управления виртуальной инфраструктурой - VMware vSphere Client 3.39. Напомним, что о прошлых версиях этого тонкого клиента мы писали около месяца назад вот тут.

Давайте посмотрим, что нового появилось в VMware vSphere Client 3.39:

• Полностью реализованная функциональность механизма автоматизированного развертывания хостов Auto Deploy (то же самое, что есть сейчас в vSphere Web Client):
• Software Depots
• Deploy Rules
• Deployed Hosts
• Discovered Hosts
• Configure (настройка самого Auto-Deploy)
• Поддержка бандлов скриптов для Auto-Deploy (теперь это есть только в vSphere Client):
• Просмотр бандлов скриптов в списке всех бандлов
• Возможность загрузить бандл скриптов
• Возможность добавить или изменить правила развертывания с бандлами скриптов
• Новое представление виртуальных коммутаторов на хосте, которое включает в себя диаграммы с топологиями для стандартных виртуальных коммутаторов, а также host proxy switches.
• Улучшенная функциональность для виртуальных сервисов vApp и виртуальных машин в их составе: создание, редактирование, удаление, изменение значений.
• Были улучшены vCenter Extensions.
• Доработаны правила механизма Storage DRS для виртуальных машин - создание, редактирование и удаление.

Скачать VMware vSphere Client 3.39 можно по этой ссылке.

Компания VMware на днях выпустила новый документ, раскрывающий основные моменты улучшения производительности VMware vSphere 6.7 по сравнению с прошлой версией - What’s New in Performance - VMware vSphere 6.7.

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

• Увеличение в 2 раза числа операций vCenter в секунду по сравнению с vCenter 6.5.
• vCenter использует в 3 раза меньше памяти для основного процесса vpxd.
• Уменьшение времени на операции, связанных с DRS, до 3 раз (например, запуск виртуальной машины).
• Улучшение производительности Virtualization Based Security.

Здесь повышение производительности в числе транзакций в минуту составило 33% по сравнению с работой VBS в vSphere 6.5:

• Поддержка больших страниц памяти (Large Memory Pages) размером 1 ГБ.

Хост ESXi с размером страницы в 1 ГБ (появилось в vSphere 6.7) работает на 26% лучше, чем хост со страницей в 2 МБ:

• Улучшения драйвера vmxnet3 версии 4 в плане механизмов RSS (улучшение 28-146% в числе полученных пакетов в секунду) и VXLAN/Geneve Offload (до 415% улучшение в пропускной способности канала при некоторых условиях).
• Поддержка новых сервисов Persistent Memory.

С помощью технологии vSphere Persistent Memory пользователи могут применять специальные аппаратные модули от Dell-EMC и HPE (DRAM NVDIMM), которые могут использовать высокопроизводительные системы хранения с большим числом IOPS или предоставлять их возможности гостевым системам как non-volatile memory.

Работает это быстрее, чем SSD (vPMEMDisk - это работа такой памяти как локальное хранилище хоста ESXi, а vPMEM - прямое предоставление хранилища гостевой системе как устройства):

• Скорость создания мгновенных клонов (Instant Clones) виртуальных машин по сравнению со скоростью создания связанных клонов.

Мгновенные клоны создаются почти в три раза быстрее, чем связанные (время в секундах на создание 64 клонов):

Все остальное - в документе "What’s New in Performance - VMware vSphere 6.7".

На сайте проекта VMware Labs появилась очередная утилита DRS Entitlement Viewer, которую давным-давно ожидали пользователи еще с третьей версии ESX Server. Это средство позволяет визуализовать иерархию пулов ресурсов, в которой для каждого пула показаны выделенные ему ресурсы процессора и памяти:

Кроме этого, как вы видите на картинке, также показываются и ресурсы, выделенные всем виртуальным машинам кластера VMware DRS. Эти параметры вычисляются и отображаются на основе фактически потребляемых машинами и пулами ресурсов, а также параметров reservation, limit и shares.

Помимо этого, утилита DRS Entitlement Viewer поддерживает 3 сценария "что если" (What-If):

• Изменение настроек reservation, limit и shares для ВМ и/или пула ресурсов.
• Что если ВМ будет потреблять столько ресурсов, сколько сможет (то есть нагружена на 100%).
• Сочетание обоих предыдущих сценариев.

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

И самое полезное - результат what-if моделирования можно выгрузить в виде консольной команды PowerCLI, которую можно затем применить в реальном окружении VMware vSphere, чтобы получить смоделированную конфигурацию кластера DRS.

Скачать DRS Entitlement Viewer можно по этой ссылке. Работает это как плагин к клиенту vSphere Client на базе технологии HTML5. Для запуска плагина вам потребуется vCenter Server Appliance версии 6.5 или 6.7.

Установить плагин просто:

• Распаковываем архив дистрибутива в папку /usr/lib/vmware-vsphere-ui/plugin-packages/.
• Добавляем следующие расширенные настройки (Advanced Settings) в кластер HA/DRS:
  • CompressDrmdumpFiles = 0
  • DrmdumpResActions = 1
• Перезапускаем службу командами:
  • service-control --stop vsphere-ui
  • service-control --start vsphere-ui

После этого вы увидите раздел "DRS entitlements" на вкладке "Monitor" для каждого кластера.

На днях компания VMware объявила о выпуске обновлений для нескольких своих продуктов. Самое интересное - это выпуск обновленной версии решения vSphere Integrated Containers 1.4, которое позволяет создавать инфраструктуру виртуальных приложений Docker в виртуальных машинах vSphere.

Давайте посмотрим, что нового в VMware VIC 1.4:

• Появилась возможность добавлять объекты VCH в группы DRS VM affinity. Подробнее.
• Теперь нет обязательного требования по включению DRS в кластере, в котором вы хотите использовать VCH. Подробнее.
• Добавлена концепция пространств имен. Теперь администраторы могут разрешать или запрещать некоторые пространства имен при добавлении новых реестров в порталу управления. Подробнее.
• Добавлены реестры уровня проекта в VIC Management Portal, который управляется администраторами отдела DevOps. Подробнее.
• Режим whitelist для реестров, который позволяет искать и развертывать ресурсы из реестров, добавленных как глобальные или уровня проекта в VIC Management Portal. Подробнее.
• Добавлено опциональное представление в виде карточек для страницы внутренних репозиториев, которое позволяет упростить развертывание образов, сохраненных в реестре vSphere Integrated Containers Registry.
• Полная поддержка vSphere 6.7. Подробнее.
• Поддержка инсталляций vSphere для филиалов - VMware vSphere Remote Office Branch Office (ROBO) Advanced. Подробнее.
• Упрощенная процедура апгрейда vSphere Integrated Containers Appliance. Подробнее.
• Улучшения интерфейса и юзабилити на портале vSphere Integrated Containers Management Portal.

Загрузить решение vSphere Integrated Containers 1.4 можно по этой ссылке.

Мы много писали о релизе новой версии платформы виртуализации VMware vSphere 6.7 и ее возможностях, а сегодня хотим рассказать про нововведения функции Instant Clone, о которых написал Дункан Эппинг. Напомним, что функция мгновенного клонирования виртуальной машины (ранее известная как VMFork) позволяет очень быстро сделать работающую копию запущенной ВМ на платформе VMware vSphere.

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

Такая схема использования родительской ВМ в VMware vSphere 6.5 требовала, чтобы родительская машина и ее мгновенные клоны находились на одном сервере ESXi. А значит для этих ВМ не поддерживались такие технологии, как vMotion/HA/Storage vMotion и DRS. Между тем, это очень важно для служб тестирования, отделов DevOps и т.п.

Теперь же в VMware vSphere 6.7 появились следующие улучшения Instant Clone:

• Появился простейший публичный API, который позволяет автоматизировать процесс создания и перемещения мгновенных клонов. Он умеет пока не все, но будет развиваться. GUI для этого пока также нет.
• Интеграция с технологиями vSphere для обеспечения доступности виртуальных машин (HA, DRS, vMotion, Storage / XvMotion и т.п.).
• Поддержка двух рабочих процессов создания мгновенных клонов: первый - это последовательное создание клонов в процессе работы родительской виртуальной машины, второй - отпочковывание клонов от "замороженной" родительской ВМ.
• Использование технологии P-Share для дедупликации страниц памяти средствами технологии Transparent Page Sharing (даже когда она отключена на хосте ESXi).
• Теперь отношение родитель-клон не такое тесно связанное, как раньше.

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

Схематично это выглядит вот так:

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

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

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

1. После создания Instant Clone внутри нужно отключить сетевой интерфейс через свойство VirtualEthernetCard->connectable->migrateConnect, устанавливаемое в значение disconnect. Далее нужно задать настройки сетевой идентификации ВМ.
2. Если не хочется менять параметры сетевой идентификации, новые ВМ можно просто запускать в отдельной портгруппе, без выхода во внешнюю сеть во избежание конфликтов IP и MAC-адресов.
3. Внутри мгновенного клона нужно обновить настройки сетевого интерфейса, чтобы гостевая ОС получила новый MAC-адрес. Это можно автоматизировать через Guest Operations API.
4. Снова присоединить виртуальную сетевую карту к ВМ, чтобы новые настройки были применены и машина свободно работала в сети. Для этого нужно установить значение свойства VirtualEthernetCard->connectable->connected в true.

Вторая схема - это "заморозка" родительской ВМ таким образом, что ее CPU перестает исполнять инструкции (для этого используется функция instantclone.freeze в утилите vmware-rpctool). После этого механизм Instant Clone способен создавать связанные клоны этой подмороженной ВМ.

Это позволяет не плодить дельта-диски родительской ВМ (так как ее состояние не изменяется) и достичь унифицированной конфигурации мгновенных клонов:

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

Поморозка ВМ происходит средствами утилиты vmware-rpctool, которая развертывается в виртуальной машине вместе с VMware Tools.

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

Ну и напоследок обзорное видео от Дункана, посвященное использованию Instant Clones в платформе VMware vSphere 6.7:

Кроме этого, советуем также почитать вот эту статью Вильяма Лама, посвященную мгновенным клонам.

Компания VMware, спустя ровно полтора года с момента релиза vSphere 6.5, анонсировала скорую доступность новой версии платформы - VMware vSphere 6.7.

Этот релиз сфокусирован на четырех основных областях улучшений:

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

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

1. Enhanced vCenter Server Appliance (vCSA) и масштабируемая инфраструктура.

Теперь в vCSA есть несколько новых API, которые выводят управление платформой на качественно другой уровень. Кроме того, теперь vCSA поставляется с интегрированными службами embedded platform services controller (обеспечивающими работу служб Single Sign-On), которые могут работать в режиме enhanced linked mode.

Также существенно была увеличена производительность vCSA:

• В 2 раза выросло число операций vCenter в секунду.
• В 3 раза уменьшилось потребление памяти.
• В 3 раза увеличилось число операций DRS (например, включение виртуальной машины и ее первичное размещение в кластере).

2. Улучшения механизма загрузки/перезагрузки хоста ESXi.

Здесь появилось 2 основных улучшения:

• При накате мажорных обновлений теперь требуется не 2 перезагрузки, а одна (Single Reboot).
• Новый механизм vSphere Quick Boot позволяет перезагрузить гипервизор без рестарта всего хоста ESXi.

3. Доработанный HTML5 vSphere Client.

В новом релизе будет обновленная версия клиента для управления vSphere Client на базе технологии HTML5 (добавлены функции управления vSAN и Update Manager), правда пока не понятно, будет ли это полноценная замена vSphere Web Client, или обе версии пока продолжат существовать совместно.

4. Большие улучшения безопасности.

VMware vSphere 6.7 предоставляет поддержку аппаратного модуля Trusted Platform Module (TPM) 2.0, а также появился виртуальный модуль Virtual TPM 2.0. Все это позволяет защититься от атак с подменой хостов и виртуальных машин, а также предотвратить загрузку неавторизованных компонентов.

Также были сделаны улучшения механизма VM Encryption в части рабочих процессов при использовании шифрования. Теперь при миграции виртуальных машин между различными экземплярами vCenter также можно использовать Encrypted vMotion, что расширяет сферу применения данной технологии до гибридных облачных инфраструктур (защищенная горячая миграция в датацентр сервис-провайдера) или инфраструктур с географически разнесенными датацентрами.

Помимо этого, vSphere 6.7 теперь поддерживает технологию Virtualization Based Security, которая используется в гостевых ОС Microsoft Windows.

5. Улучшения поддержки высокопроизводительных приложений.

Как многие из вас знают, поддержка vGPU от NVIDIA и AMD есть в платформе vSphere уже довольно давно. Используется она сейчас не только для виртуальных ПК, но и для таких задач, как системы искусственного интеллекта, machine learning, big data и прочее. Теперь в vSphere 6.7 поддержка такого рода вариантов использования была расширена.

С помощью технологии vSphere Persistent Memory пользователи могут использовать специальные аппаратные модули от Dell-EMC и HPE, которые могут использовать высокопроизводительные системы хранения с большим числом IOPS или предоставлять их возможности гостевым системам как non-volatile memory. Теперь во многих вариантах использования высокопроизводительные приложения смогут работать быстрее.

6. Бесшовная интеграция с гибридной средой.

Теперь в VMware vSphere 6.7 появился режим работы vCenter Server Hybrid Linked Mode, в котором можно соединить две инфраструктуры - вашу онпремизную с одной версией vSphere и облачную, например, VMware Cloud on AWS с другой версией платформы.

Помимо этого, в vSphere 6.7 появились механизмы Cross-Cloud Cold и Hot Migration, которые позволяют переносить нагрузки в онлайн и офлайн режиме между облаками и онпремизной инфраструктурой.

Когда это происходит, виртуальной машине приходится перемещаться между хостами с разными наборами инструкций процессора. Поэтому в vSphere появилась технология Per-VM EVC (Enhanced vMotion Compatibility), которая позволяет подготовить виртуальную машину к миграции на совершенно другое оборудование.

Также появилась фича поддержки операций cross-vCenter, mixed-version provisioning (таких как vMotion, полное клонирование, холодная миграция), которая позволяет производить эти операции между различными vCenter различных версий (что тоже неизбежно в гибридной среде - вроде связки с vCloud on AWS).

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

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

На днях компания VMware выпустила Configuration Maximums Tool - средство, которое позволяет посмотреть максимумы конфигурации платформ виртуализации, виртуальных машин и других решений VMware в различных категориях. На данный момент поддерживаются версии VMware vSphere 6.0, 6.5 и 6.5 Update 1 (кстати о сравнении максимумов 6.5 и 6.0 мы писали вот тут).

По умолчанию мы видим следующие Configuration Maximums, которые можно сворачивать-разворачивать в пределах категории:

• Virtual Machine Maximums
• ESXi Host Maximums (Compute)
• ESXi Host Maximums (Memory)
• ESXi Host Maximums (Storage)
• ESXi Host Maximums (Networking)
• ESXi Host Maximums (Cluster and Resource Pools)
• ESXi Host Maximums (VMDirectPath)
• vCenter Server Maximums
• vCenter Server Maximums (Storage DRS)
• Platform Services Controller
• vCenter Server Extensions (Update Manager)
• vCenter Server Extensions (vRealize Orchestrator)
• VMware vSphere Flash Read Cache
• VMware vSAN
• Virtual Volumes

Также многим будет интересна фича сравнения максимумов различных версий VMware vSphere:

Сравнить можно 2 или 3 версии платформы, а результат выгрузить в XLS-файл, чтобы использовать его в MS Excel.

VMware Configuration Maximums Tool доступен по этой ссылке: https://configmax.vmware.com/.