Год назад мы писали об обновлении утилиты RVTools 3.9.2, в котором появилась поддержка VMware vSphere 6.5. В конце февраля вышло обновление этого средства - RVTools 3.10, где появилась масса новых возможностей. Напомним, что RVTools - это утилита, которая помогает администраторам при выполнении рутинных операций с виртуальной инфраструктурой в различных аспектах.
Давайте посмотрим, что нового в RVTools 3.10:
RVTools теперь сделана на Visual Studio 2017.
Фреймворк .Net обновлен до версии 4.6.1
Новые колонки на вкладке vInfo: настройка latency-sensitivity для ВМ, параметры Change Block Tracking (CBT) и значение disk.EnableUUID.
Новые колонки на вкладке vDisk: SCSI label, unit number и sharedBus.
Новые колонки на вкладке vHost: назначенные лицензии, ATS heartbeat, значения ATS locking (0 = disabled, 1 = enabled), короткое имя для Host Power Policy, текущая политика CPU Power Management, поддержка CPU power hardware.
При экспорте в xlsx добавляется версия RVTools и дата/время в выходной файл.
Все колонки экспортированного xlsx имеют фильтр.
Новые строчки в csv-файле теперь заменены на пробелы.
Если утилита работает из командной строки и возникают проблемы с логином - больше не появляется окошко ввода кредов, вместо этого утилита завершается с кодом -1.
Добавлен пример сценария PowerShell, который позволяет объединять экспортированные xlsx-файлы.
Добавлен пример сценария PowerShell, который позволяет экспортировать несколько серверов vCenter в один xlsx.
Вкладка vDatastore: для датасторов NFS колонка с адресом заполняется полным путем к папке вместе с хостом.
Новые колонки вкладки vDatastore: имя Datastore Cluster, общая емкость кластера и свободные ресурсы хранилищ.
Верхняя граница хэлсчека (health check) виртуальных машин увеличена до 9999.
Вкладка vHealth: новая колонка "message type", которую можно использовать как фильтр в Excel.
Вкладка vHealth: файлы hbrdisk.RDID теперь не определяются как зомби-файлы.
Вкладка vHealth: при высокой заполненности хранилища показывается также свободная емкость в мегабайтах.
Все вкладки: обновление и автообновление учитывают порядок пользовательской сортировки.
Параметры командной строки export2xls обновились на export2xlsx (старые также работают).
Пакет Log4net обновлен до версии 2.0.8, Waffle.AD - до версии 1.8.3, NPOI - до версии 2.3.0.
Ошибка соединения для TLSv1.0 и TLSv1.1 отключена и только для TLSv1.2 включена за счет использования .Net Framework 4.6.1.
Дефолтная директория теперь поменялась на C:\Program Files (x86)\RobWare\RVTools и не содержит номера версии.
Скачать RVTools 3.9.2 для VMware vSphere 6.5 можно по этой ссылке. Документация доступна тут.
В блоге VCDX133 появился интересный и полезный список основных ключевых моментов в различных аспектах проектирования инфраструктуры VMware vSphere. Он будет полезен архитекторам и системным инженерам, которые планируют внедрение большой инфраструктуры виртуализации и хотят учесть все основные функции платформы, а также избежать проблем в будущем при масштабировании архитектуры.
Кстати, этот список можно использовать как высокоуровневый опросник перед началом фазы проектирования, чтобы выяснить ключевые потребности заказчика и далее превратить это все в техническое задание на базе полученных требований.
Приведем данный список ниже:
Бизнес-задачи и проблемы
Какие основные задачи стоят при внедрении?
Какие проблемы заказчика предполагается решить?
Варианты использования платформы
Какие варианты использования инфраструктуры VMware предполагает сам заказчик?
Требования/Ограничения/Допущения
Каковы основные требования, какие ограничения учесть, о какие допущениях и неочевидных моментах нужно проинформировать заказчика.
Риски
Какие риски внедрения решения (например, простои при миграции) и каковы способы их минимизации? Есть ли специфические задачи, тесты и процедуры, которым нужно следовать в таком случае.
A. Управление виртуальным датацентром
Решения в области логической архитектуры
Общий объем объединяемых в пул ресурсов (вычислительные мощности, сети и хранилища).
Какие сервисы будет предоставлять инфраструктура.
Необходимый уровень доступности для систем управления платформой виртуализации.
Интеграция со сторонними решениями: IT Service Management, Infrastructure Management systems, Enterprise services (DNS, LDAP, NTP, PKI, Syslog, SNMP Traps), сбор данных агентами систем различных вендоров.
Необходимы ли расширенные операции, не предоставляемые из коробки?
Механизмы защиты рабочих нагрузок гипервизора (vMotion, HA и другое).
Механизмы балансировки нагрузки на гипервизор (DRS).
Решения в области физической инфраструктуры
Гипервизор: версии ESXi.
Нужен ли отдельный кластер управления?
Серверы vCenter в режиме Standalone или Linked-Mode?
Версия vCenter Server и тип установки (под Windows или в виде виртуального модуля).
База данных vCenter Server - встроенная или внешняя?
Механизмы защиты vCenter Server.
Дизайн инфраструктуры Platform Services Controller (PSC). Будет ли один домен SSO?
Нужна ли инфраструктура шифрования (PKI)? Какие требования к SSL?
Какие компоненты vSphere будут использоваться?
Нужна ли функциональность Host profiles?
Вопросы управления обновлениями ESXi, версиями VM Hardware и версиями VMware Tools.
Интеграция с антивирусами и решениями vShield/NSX.
Нужен ли пакет vRealize Suite для расширенных операций и управления частным облаком?
Нужен ли продукт vRealize Orchestrator для управления рабочими процессами операций? Нужен ли PowerCLI для сценариев автоматизации?
Нужно ли интегрировать виртуальную инфраструктуру с другими средствами управления (Enterprise Management)?
Automated vendor support mechanisms? How will VMware Skyline be used?
Нужно ли организовывать интеграцию с системами Service Desk или Change Management?
Каковы требования к механизмам vSphere HA и vSphere DRS?
Если будет использоваться HCI (Hyper-Converged Infrastructure), то какие решения будут использоваться для управления, и как это будет совместимо с vSphere?
Вопросы интеграции со службами DNS и NTP.
Ролевая модель доступа (Role Based Access Control) и интеграция с LDAP.
Какой интерфейс vCenter Server будет использоваться для администрирования и ежедневных операций (vSphere Client / Web Client).
Модель лицензирования vCenter.
Вопросы лицензирования стороннего ПО в виртуальных машинах (на хост, на виртуальный процессор vCPU и т.п.).
B. Вычислительные ресурсы
Решения в области логической архитектуры
Традиционная архитектура, технология Server-Side Flash Cache Acceleration, конвергентная или гиперконвергентная инфраструктура (связано с хранилищами).
Минимальное число хостов в кластере.
Тип сайзинга хостов в кластерах: вертикальный (Scale Up) или горизонтальный (Scale Out)?
Гомогенные или гетерогенные узлы?
Число физических процессоров на хост.
Резервирование уровня хостов в рамках доменов отказа (Failure Domains).
Необходимая емкость по CPU.
Необходимая емкость по RAM.
Решения в области физической инфраструктуры
Вендор серверов.
Тип процессоров серверов.
Фичи CPU: VT-x, Hyper-threading, Turbo Boost, включена ли NUMA?
Конфигурация серверного оборудования.
Число сокетов CPU на узел.
Модель процессора, частота и число ядер.
Нужен ли GPU?
Физическое размещение хостов.
Тип размещения: Single Rack или Multi-Rack с шарингом ресурсов?
Требования к доступности кластеров.
Нужно ли обеспечить согласованность доступности хостов с доступностью хранилищ.
Будущее расширение вычислительных ресурсов.
C. Хранилища
Решения в области логической архитектуры
Традиционные хранилища, технология Server-Side Flash Cache Acceleration, конвергентная или гиперконвергентная инфраструктура (связано с вычислительными ресурсами).
Блочные или IP-хранилища?
Средства автоматизированного управления хранилищами.
Допустимо ли использование RDM?
Метод загрузки хоста ESXi - с локального диска (DAS), LUN или PXE.
Толстые или тонкие диски для виртуальных машин?
Необходимые ресурсы хранения.
Репликация хранилищ.
Решения в области физической инфраструктуры
Вендор систем хранения.
Расчет используемой емкости хранилищ с учетом пулов хранения, затрат на репликацию и бэкап. Каковы численные требования к емкости и производительности хранилищ?
Число дисков SSD и HDD в каждой из систем хранения.
Использование дедупликации, сжатия данных, технологии Erasure Coding и Storage APIs. Нужно ли держать процент хранилищ всегда свободным?
Какой активный Working Set (рабочий объем данных) необходим?
Трешхолды для автоматизированного ярусного хранения данных (разнесения по ярусам).
Использование шифрованных дисков и сервер KMS.
Сеть хранения данных и ее организация.
Механизм загрузки хстов ESXi.
Технологии VM DirectPath I/O и SR-IOV.
Число датасторов на кластер.
Будут ли использоваться DRS и SIOC?
Будут ли применяться VMDK shares на уровне виртуальных дисков?
Будет ли использоваться технология VAAI?
Использование VASA и профилей хранилищ (storage profiles).
Будут ли использоваться синхронные или асинхронные DR-решения?
Планирование расширения хранилищ.
D. Сетевая инфраструктура
Решения в области логической архитектуры
Технология Legacy 3-Tier Switch, Collapsed Core или Clos-type Leaf/Spine?
Кластеризованные физические или отдельные коммутаторы EoR/ToR?
Растянутые логические VLAN или на уровне стойки?
Трафик будет функционально разделяться на уровне виртуальных коммутаторов или отдельных VLAN?
В конце января компания VMware выпустила существенное обновление своего клиента на базе технологии HTML5 для управления виртуальной инфраструктурой VMware vSphere. На днях вышел еще один апдейт - VMware vSphere Client 3.34, в котором также появилось немало всего нового.
Давайте посмотрим на последние фичи vSphere Client версии 3.34:
Визуализация топологии виртуальных коммутаторов (см. на скриншоте выше).
Возможность пакетного создания виртуальных адаптеров VMkernel на распределенной группе портов vDS.
Действие по привязке лицензи (Assign License) на вкладке License Assets.
Сообщение об устаревающих лицензиях vCenter.
Изменение настроек виртуальных сервисов vApp.
Включение и изменение настроек vApp для его виртуальных машин.
Перемещение сетей (networks) и распределенных коммутаторов в новые папки типа network в инвентори.
Пакетная привязка физических сетевых адаптеров к аплинкам в мастере "Add and Manage Hosts" на распределенном коммутаторе.
Пакетная привязка портов VMkernel к порт-группам "Add and Manage Hosts" на распределенном коммутаторе.
Отображение дополнительной информации, такой как состояние питания и информации Quiesce/memory для снапшотов виртуальных машин.
Загрузить VMware vSphere Client 3.34 можно по этой ссылке.
Блогер David Pasek опубликовал интересный пост, касающийся ограничения виртуальных машин и их виртуальных дисков по числу операций ввода-вывода. Смысл его в том, что автор, являющийся ярым сторонником обеспечения QoS на уровне виртуальных дисков, настоятельно рекомендует применять ограничения IOPS limit к виртуальным дискам машин, которые потенциально могут выесть много полосы ввода-вывода.
Сейчас ограничивать виртуальные машины по IOPS можно как на уровне виртуальных дисков на томах VMFS/RDM/NFS, так и на уровне томов VVols. Многие системы хранения оперирует понятием логического тома LUN, на котором размещается один том VMFS. Как правило, LUN - это логический том, что значит, что несколько LUN могут размещаться на одной физической группе дисков:
Таким образом, виртуальные машины, потребляющие много IOPS от хранилища (он называет их "noisy neighbor") могут существенно замедлить работу других производственных систем.
Поэтому для таких машин требуется создавать ограничения IOPS limit, которые можно задать для виртуального диска в опциях машин, либо привязать к VMDK диску политику с ограничениями по IOPS.
Например, в vSphere Web Client создаем новую VM Storage Policy с ограничениями IOPS limit for object:
А далее привязываем эту политику к диску VMDK в настройках ВМ:
Тут же в настройках можно задать значение в поле Limit-IOPs, если не выбирать политику.
Именно ограничение по IOPS делает поведение инфраструктуры хранения для виртуальных машин предсказуемым и управляемым. Ограничения по вводу-выводу позволят обеспечить минимально приемлемый уровень обслуживания для виртуальных машин, которым требуются ресурсы хранилища, с гарантией того, что остальные системы не съедят все доступные IOPS.
Ну и в заключение несколько аспектов данного рода ограничений:
Команды ввода-вывода (IO) нормализуются к блоку 32 КБ, то есть команда в 128 КБ будет преобразована в 4 IO.
IOPS limit не влияет на операции SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.
IOPS limit применяется только ко вводу-выводу гостевой ОС и не затрагивает операции с самим диском VMDK и его swap-файлами.
Если у машины несколько лимитов по IOPS для дисков на одном датасторе, то эти лимиты складывают и применяются для всей ВМ на этом датасторе в целом. Если же диски находятся на разных хранилищах, то тут уже действуют правила для каждого из групп дисков.
Например, если у каждой из 4 дисков машины на одном датасторе стоит лимит 100 IOPS, то для всей машины будет совокупный лимит 400. То есть, если три VMDK едят по 10 IOPS каждый, то четвертый диск сможет съесть максимум 370 IOPS.
А вот для NFS-хранилищ все работает несколько иначе - если у каждого из 4 дисков на одном датасторе стоит лимит 100 IOPS, то сколько бы ни потребляли остальные диски, для каждого из дисков будет применен максимальный лимит 100.
Полная информация об ограничении ввода-вывода для виртуальных машин приведена в KB 1038241.
На днях компания VMware начала тестировать новую версию своего фреймворка для управления виртуальной инфраструктурой и выпустила VMware PowerCLI Beta.
Как вы помните, в конце 2016 года VMware на сайте проекта VMware Labs опубликовала утилиту PowerCLI Core, которая позволяет пользователям применять те же самые командлеты PowerCLI на системах Linux, Mac и Docker, которые ранее были доступны только для Windows.
В новой бета-версии PowerCLI эта утилита будет не нужна, так как теперь PowerCLI будет работать на всех платформах в рамках единого пакета, а из состава продукта для платформ Linux и MacOS уйдет слово "Core". На данный момент эта бета была протестирована на следующих платформах:
Windows
CentOS 7 (тестирование еще в процессе)
Ubuntu 16.04
MacOS 10.12
В этой бета-версии на все платформы были портированы следующие модули:
VMware.VimAutomation.Sdk
VMware.VimAutomation.Common
VMware.VimAutomation.Core
VMware.VimAutomation.Vds
VMware.VimAutomation.Cis.Core
VMware.VimAutomation.Nsxt
VMware.VimAutomation.Vmc
VMware.VimAutomation.Storage
VMware.VimAutomation.StorageUtil
Для MacOS и Linux вы увидите только перечисленные модули, остальные пока не доступны. Устанавливать их нужно так:
Более подробную информацию о VMware PowerCLI Beta можно получить вот тут. Ну и вам надо знать, что бета работает только на PowerShell Core v6.0.1 (на версии 6.0.0 работать не будет).
У некоторых администраторов VMware vSphere время от времени возникает проблема с горячей миграцией vMotion виртуальных машин, например, когда они выводят хост в режим обслуживания (Maintenance Mode). vMotion зависает на 21%, и на vCenter Server появляется ошибка наподобие такой:
Failed waiting for data. Error 195887137. Timeout. vMotion migration failed to send buffer to remote host. vMotion migration failed writing stream completion.
Еще одно сообщение об ошибке в этом случае выглядит вот так:
The vMotion failed bacause the destination host did not receive data from the source host on the vMotion network. Failed to initialize migration at source. Error 195887109.
На панели задач мы видим вот такую картину:
Если посмотреть на лог-файлы, то там не обнаруживается никаких проблем. Но подобного рода ошибки, если внимательно поискать их в VMware KB, указывают на разные сконфигурированные значения MTU пакета в виртуальной инфраструктуре и на портах физических коммутаторов. Например, на vSphere Distributed Switch для порта VMkernel, через который идет миграция vMotion, размер MTU у вас выставлен в 9000 (для поддержки Jumbo Frames), а вот на на порту свича - 1500.
Поэтому всегда проверяйте, чтобы размер MTU был одинаковым на всех компонентах физической и виртуальной инфраструктуры - vDS и портах коммутатора. Более подробно о настройке Jumbo frames написано в KB 1038827.
Многие из вас хотя бы раз задумывались о том, сколько виртуальных машин должно в среднем приходиться на один хост, а кроме того, в частности, сколько виртуальных процессоров (vCPU) могут исполняться на физических процессорах (pCPU) хост-сервера VMware ESXi.
На этот счет системные архитекторы часто дают следующие рекомендации (в соответствии с критичностью нагрузок в кластере):
Это общие рекомендации и, конечно же, не железные правила - отталкиваться нужно от имеющегося оборудования и характера нагрузок в виртуальных машинах.
Для того, чтобы регулировать это соотношение со стороны кластера балансировки нагрузки VMware DRS есть 2 специальные расширенные настройки:
MaxVcpusPerClusterPct - регулирует соотношение vCPU/pCPU на уровне всего кластера, не привязываясь к конкретным хостам ESXi (то есть сумма vCPU всех машин делится на сумму pCPU всех хостов).
MaxVCPUsPerCore - регулирует соотношение vCPU/pCPU на уровне каждого из хостов ESXi, то есть ни на одном из них это соотношение не может быть превышено.
Указываются эти расширенные настройки в разделе Configuration Parameters в vSphere Web Client при настройке DRS-кластера:
Но самое интересное - это то, что в vSpher Web Client эта настройка есть в GUI и регулирует параметр MaxVcpusPerClusterPct на уровне всего кластера (можно задать процент от 0 до 500, но разумно задавать значения от 100 до 500, если задать 500 - число vCPU может быть больше pCPU в пять раз):
А вот в vSphere Client - эта настройка уже MaxVCPUsPerCore, то есть задание CPU Overcommitment на уровне каждого из хостов ESXi, о чем и написано в интерфейсе:
Кстати, выставить эту настройку можно в диапазоне от 0 до 32.
Таги: VMware, DRS, Blogs, Web Client, Client, vSphere
Пару недель назад мы писали о новых возможностях последних версий HTML5-клиента для управления виртуальной инфраструктурой VMware vSphere Client 3.31-3.32, а на днях компания VMware выпустила очередное обновление vSphere Client 3.33, где появилось немало новых возможностей (а не как обычно).
Давайте посмотрим, что нового в этом обновлении:
Поддержка устройств PCI и Shared PCI для виртуальных машин.
Мастер создания нового виртуального сервиса (vApp).
Мастер клонирования vApp.
Перемещение vApp в между хостами и кластерами.
Возможность копирования customization specification виртуальной машины на другой сервер vCenter с возможностью изменения имени и описания спецификации.
Действие Synchronize Licenses (ранее оно называлось Import License Keys Data).
Детали об имеющихся ассетах и лицензиях.
Возможность изменять VM Advanced configurations в настройках виртуальной машины (пункт Edit Settings).
Изменение ярлыков для операций с состоянием ВМ (Power Operations) в разделе VMware tools в опциях Edit Settings для виртуальной машины.
Изменение максимального количества сессий VMRC для виртуальной машины в настройках (Edit Settings).
В целом, не так уж и мало для очередного обновления. Скачать VMware vSphere Client 3.33 можно по этой ссылке.
Как вы знаете, механизм динамической балансировки нагрузки VMware DRS используется для того, чтобы в условиях неравномерной нагрузки на хост-серверы VMware ESXi выравнивать ее за счет дачи рекомендаций по миграции виртуальных машин средствами vMotion на другие хосты, либо автоматического выполнения этих рекомендаций.
Давайте посмотрим как Distributed Resource Scheduler работает с оперативной памятью. В кластере DRS есть такая настройка "Memory Metric for Load Balancing", которая отключена по умолчанию, и если почитать к ней описание, то становится понятно, что DRS по умолчанию руководствуется параметром Active memory для балансировки.
У машины есть три основных параметра памяти, учитываемых DRS - это Active, Consumed и Configured Memory:
Configured - это память, указанная в настройках виртуальной машины, то есть ее максимальное значение.
Consumed - это память, которая использовалась виртуальной машиной с момента ее загрузки (а вы знаете, что при загрузке операционная система обращается к большему объему памяти, чем затем ее использует).
Active - это активные страницы памяти (RAM), которые сейчас используются гостевой ОС.
На картинке ниже показан пример - у машины 16 ГБ памяти, при этом при загрузке она наинициализировала страниц памяти на 12 ГБ, а активно использует только 5734 МБ.
Для того чтобы подчитывать используемую память, планировщик DRS подсчитывает working set из страниц Active Memory и прибавляет к нему 25% от разницы между Consumed и Active (это называется Idle Consumed Memory) на незапланированные резкие изменения нагрузки - и это число использует в своих вычислениях балансировки кластера:
В данном случае будет использоваться значение 5734+0,25*(12288-5734) = 7372,5 МБ (на картинке 7373 МБ). Кстати, это еще не все - к машине с памятью в 16 ГБ прибавляются накладные расходы (Overhead) в размере 90 МБ, поэтому DRS в своих вычислениях будет использовать значение 7373+90 = 7463 МБ.
Если же включить настройку DRS-кластера, упомянутую выше, то DRS в своих вычислениях будет использовать Consumed Memory и также прибавлять Memory Overhead:
В обновлении vSphere 6.5 update 1d клиент позволяет вам просматривать как метрику Active Memory, так и Consumed Memory.
Вот так выглядит картинка для сбалансированного кластера DRS (рекомендаций и ошибок нет):
Кстати, если вы посмотрите на Active Memory сбалансированного кластера, то там вполне может быть дисбаланс:
В этом нет ничего страшного, так как машины используют менее 20% active memory от памяти хоста, всем памяти хватает, и DRS решает, что балансировать машины в таком случае - это только тратить ресурсы CPU и сети на vMotion.
Переключимся теперь на Consumed memory:
Тут мы видим большой дисбаланс и разница между хостами более 20% от значений Consumed memory на них. Поэтому если мы включим настройку "Memory Metric for Load Balancing", то кластер DRS начнет работу по миграции виртуальных машин между хост-серверами. Итогом будет вот такая картина:
Вывод тут вот какой. Если у вас кластер работает без оверкомита (non-overcommitted) и есть большой запас по RAM на хостах, то, возможно, вам и следует поставить настройку "Memory Metric for Load Balancing", чтобы DRS балансировал хосты по consumed memory, а сами рекомендации по миграциям, например, можно применять в ручном режиме, чтобы контролировать ситуацию.
На днях мы писали о том, что компания VMware выпустила обновления VMware vCenter и ESXi, закрывающие потенциальную угрозу безопасности Spectre (она же Hypervisor-Assisted Guest Mitigation - CVE-2017-5715), которая недавно была обнаружена в процессорах Intel. Для закрытия уязвимости нужно обновить не только серверы ESXi и vCenter, но и микрокод (BIOS/Firmware) серверов (более подробная информация также приведена в KB 52085).
На днях наш читатель Сергей прислал ссылку на скрипт от Вильяма Лама, который позволяет провести проверку компонентов виртуальной инфраструктуры VMware vSphere на данную уязвимость. Этот PowerCLI-скрипт содержит две функции:
Verify-ESXiMicrocodePatchAndVM
Verify-ESXiMicrocodePatch
Первая функция позволяет проверить хосты ESXi и виртуальные машины и сгенерировать отчет в разрезе виртуальных машин. Если в колонке Affected стоит значение False - значит обновления и микрокода сервера, и хоста ESXi были применены, а сами ВМ и хост-сервер не подвержены уязвимости Spectre.
Вторая функция проверяет только, что на хостах ESXi накачено обновление как микрокода, так и самого гипервизора ESXi, который видит обновленные CPU features.
Функция Verify-ESXiMicrocodePatchAndVM может быть запущена тремя способами:
Без параметров - проверяется все окружение VMware vSphere и все виртуальные машины в нем.
С параметром - ClusterName - проверяется конкретный кластер и всего его хосты и ВМ.
С параметром - VMName - проверяется только конкретная ВМ и ее хост, соответственно.
У функции Verify-ESXiMicrocodePatch также есть три способа вызова:
Без параметров - проверяются все хост-сервера в инфраструктуре vCenter.
С параметром - ClusterName - проверяется конкретный кластер и всего его хосты.
С параметром - VMHostName - проверяется конкретный хост-сервер ESXi.
Те из вас, кто следят за ИТ-новостями, наверняка слышали о последних уязвимостях, обнаруженных в процессорах Intel. Одной из таких уязвимостей стала Spectre - она потенциально позволяет локальным приложениям (локальному атакующему, при запуске специальной программы) получить доступ к содержимому виртуальной памяти текущего приложения или других программ.
Для серверов VMware ESXi надо пойти на VMware Patch Portal и загрузить оттуда обновление ESXi650-201801401-BG / ESXi650-201801402-BG. (номер билда 7526125). Подробная информация об обновлении приведена в KB 2151099.
Также данное исправление доступно и для настольных платформ виртуализации VMware:
VMware Workstation 14.1.1 Pro for Linux - Загрузить
VMware Workstation 14.1.1 Pro for Windows - Загрузить
VMware Fusion 10.1.1 (для Intel-based Macs) - Загрузить
Гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего услуги аренды виртуальных машин.
Blockchain — это принципиально новая технология, которая в последнее время приковывает к себе все больше внимания. Специалисты из таких отраслей, как финансы, экономика, медицина, логистика, IoT, активно работают над исследовательскими и экспериментальными проектами с использованием блокчейн, поскольку эта технология заточена не только на криптовалюты.
Blockchain на vSphere или BoV — это инструмент для развертывания Hyperledger Fabric v1.0 на платформе vSphere, или, другими словами, проект VMware, который помогает администраторам развернуть блокчейн-платформу для разработчиков на базе гипервизора ESXi. Используя всего несколько команд, можно с легкостью запустить кластер на vSphere, а блокчейн-разработчикам сосредоточиться на реализации бизнес-логики.
Отметим, что Hyperledger Fabric — это не компания, не криптовалюта, а проект с открытым исходным кодом, организованный сообществом Linux Foundation, который был создан для продвижения блокчейн-технологии. Это нечто, похожее на хаб для открытой разработки отраслевых блокчейнов. Hyperledger Fabric дает широкие возможности, позволяя разработчикам сконцентрироваться на запуске блокчейн-проекта с собственной бизнес-логикой.
Взгляд изнутри
Суть утилиты Blockchain on vSphere заключается в возможности развернуть несколько узлов кластера Hyperledger Fabric, так называемых Pods, причем максимально просто. При этом в Blockchain-сервисе используются три учетные записи:
Cloud Admin,
Blockchain Admin,
Blockchain Developer.
Каждая из них имеет соответствующие полномочия на разных уровнях системы: Cloud Admin может мониторить и работать с инфраструктурой на базе vSphere, Blockchain Admin — управлять платформой blockchain (Hyperledger Fabric), а разработчик Blockchain фокусируется на разработке приложений с использованием платформы blockchain.
Градация полномочий на разных уровнях системы
Hyperledger Fabric — это распределенная система, реализованная с использованием контейнеров. Она может быть развернута на платформе, которая поддерживает контейнерный стандарт OCI. При этом для управления контейнерами Fabric используется система Kubernetes. В основе рассматриваемого примера для Fabric v1.0 лежит следующая архитектура:
Используются пространства имен для поддержки различных организаций Fabric.
Используется настраиваемое количество одноранговых узлов в организации.
Организуется изоляция через Persistent Volume.
Архитектура решения
Инструкция по развертыванию
Для реализации блокчейн-проекта с использованием Hyperledger Fabric необходимо выполнить ряд предварительных требований, включающих наличие: Читать статью далее->>
В декабре прошлого года мы писали о том, что компания VMware выпустила обновление ESXi 6.5 Update 1 Patch 2, а также вскользь упомянули апдейт сервера управления - VMware vCenter 6.5 Update 1d. А вчера в нашей заметке про обновленный vSphere Client наш читатель обратил внимание на статью в блоге VMware, где рассказано о некоторых новых фичах vSphere Client, версия 3.21 которого была включена в состав vCenter 6.5 Update 1d.
Давайте посмотрим, что за фичи есть в HTML5-клиенте, который поставляется с vCenter 6.5 Update 1d, по сравнению с его прошлой версией, включенной в vCenter.
1. Улучшенный вид интерфейса Clarity.
Благодаря новому подходу VMware за счет фреймворка Clarity интерфейс клиента стал более эстетичным и удобным в использовании. Давайте взглянем, например, на возможность переключения между Active и Consumed Memory в vSphere Client:
2. Настройка vSphere Proactive HA.
Ранее это можно было делать только через Web Client, теперь это выглядит удобно и красиво:
3. Появилась настройка Content Library.
Важная фича - добавление уже существующей библиотеки с контентом (например, с другого сервера vCenter):
4. Настройка Network IO Control (NIOC) на VDS.
Теперь это возможно через vSphere Client (вместе с настройкой LAGs и LACP) для vSphere Distributed Switch (VDS), включая изменение параметров шлюза на адаптерах VMkernel:
5. Настройка политик хранения (Storage Policies).
Ранее это было доступно только через Web Client (например, нельзя было создать новую политику в HTML5-клиенте), но теперь можно делать все операции в удобном рабочем процессе для vSphere Client, который, кстати, был упрощен.
6. Управление VIB-пакетами.
Очень удобный раздел, чтобы узнать, какие дополнения в виде VIB-пакетов установлены на хосте ESXi. Доступно по адресу Host –> Configure –> System –> Packages:
7. Управление настройками ВМ и шаблонами.
Теперь в VM Settings можно настраивать все параметры виртуальных машин, включая добавление новых виртуальных устройств, таких как NVMe, SCSI, USB Controller и Host-based USB Adapter. Кроме того, появилась возможность работы с шаблонами (VM Templates).
8. Настройка VM Guest Customization Specifications.
При развертывании ВМ из шаблонов с помощью HTML5-клиента теперь можно использовать спецификацию созданную с помощью встроенного мастера, либо указать уже существующий файл спецификации.
Скачать текущую версию VMware vSphere Client можно по этой ссылке. VMware vCenter 6.5 Update 1d доступен тут.
Компания VMware в первые дни нового года выпустила очередное обновление своего HTML5-клиента для управления виртуальной инфраструктурой - VMware vSphere Client 3.32.
Напомним, что ранее мы писали о возможностях клиента 3.30 и ниже, поэтому приведем новые возможности версий vSphere Client 3.31 и 3.32, где, в основном, из нового - это управление объектами vApp:
Операции включить/выключить/перезагрузить/приостановить для виртуальных сервисов (vApp) - это показано на рисунке выше.
Переименование/удаление сервиса vApp.
Экспорт объекта vApp в шаблон виртуального модуля OVF.
Отоносящиеся к объектам vApp вкладки VM, datatastore и networking.
Действие Add Permission для шаблонов ВМ (templates).
Выбранные счетчики производительности в разделе Performance Charts сохраняются для данного пользователя в локальном хранилище его браузера. Это позволяет не настраивать их заново при открытии новой сессии клиента.
Исправлены некоторые ошибки.
Скачать VMware vSphere Client можно по этой ссылке.
«Код безопасности» анонсировал выход продукта vGate 4.0. Решение для защиты виртуальных инфраструктур будет востребовано компаниями, применяющими виртуальные платформы VMware vSphere или Microsoft Hyper-V последних версий. Продукт позволяет настроить инфраструктуру согласно различным требованиям с помощью наборов политик, разграничить права доступа администраторов, а также обеспечить защиту от несанкционированного доступа к виртуализованным ресурсам.
Недавно компания Microsoft выпустила интересное сравнение стоимости владения онпремизной инфраструктурой VMware vSphere с облачной IaaS-инфраструктурой Microsoft Azure. Оформлено это сравнение в виде калькулятора совокупной стоимости владения (Total Cost of Ownership, TCO) - Azure TCO Calculator.
Результаты расчетов на Azure TCO Calculator показывают экономию на Azure в размере до 84% относительно аналогичной онпремизной инфраструктуры VMware (на отрезке в 3 года). Сотрудники VMware смотреть на такое спокойно не смогли и разразились гневным постом, где написали о том, что вот буквально недавно закончили Whitepaper, где многие опрошенные ИТ-компании говорят о том, что онпремизная инфраструктура обходится иногда дешевле облачной, а 65% говорит, что если и дешевле, то не более, чем на 10% (некоторые выводы суммаризованы вот тут).
Сотрудники VMware сетуют на следующие недочеты в подходе Microsoft к анализу TCO:
Microsoft почему-то считает необходимым покупку лицензий vSphere каждый год при расчете 3-летней TCO.
При расчете используется 500 ВМ с конфигурацией 2 vCPU / 4 ГБ, для которых требуется аж 1 984 ядра и 33 ТБ RAM. Это в 4 раза больше по CPU и в 16 раз больше по памяти чем требуется, считают в VMware.
Для расчета Azure Pay-As-You-Go модели используются инстансы B-series, которые Microsoft рекомендует для небольших нагрузок (типа разработки/тестирования).
Для расчета облачной нагрузки используется дефолтная цифра 40% в качестве времени работы серверов в течение месяца. Это неприменимо к продакшен серверам - они должны быть включены круглосуточно.
Для расчета TCO VMware используются лицензии vSphere Enterprise Plus, которые существенно функциональнее текущих сервисов Azure. А вот функции Premium storage и Operations Management Suite в облаке будут стоить дополнительных денег (и тогда уже можно сравнивать с Enterprise Plus).
По расчетам Microsoft, онпремизные серверы, хранилища и сети потребляют 20% от своей стоимости в год на обслуживание. VMware считает это дороговато.
Microsoft не учитывает остаточную стоимость серверов и оборудования по прошествии трех лет расчета. Что надо бы учесть по мнению VMware.
На основе тезисов, приведенных выше, компания VMware добавила в сравнительную таблицу колонку "Calculator with corrections", которая отражает реальное по мнению VMware положение дел:
В качестве исходных данных здесь предполагается инфраструктура из 500 ВМ с конфигурацией 2 vCPU / 4 ГБ. Если считать, что для одной ВМ нужно 2 vCPU на одно физическое ядро, то понадобится всего 8 двухпроцессорных хостов (по 32 ядра на процессор в каждом). С точки зрения памяти, VMware считает, что будет достаточно 8 ТБ на 500 машин, что достаточно разумно (16 ГБ на машину с учетом техник оптимизации памяти - это в целом ок).
Согласитесь, что VMware считает деньги в данном случае совсем по-другому и очевидно, что с лукавством Microsoft в своем калькуляторе немного перегнула палку.
Компания VMware после очень долгого перерыва выпустила новую версию своего главного продукта для перенесения физических серверов в виртуальную среду - VMware vCenter Converter Standalone 6.2. Напомним, что прошлая версия этого средства вышла почти два года назад (мы писали о vCenter Converter Standalone 6.1 вот тут) - и никто не переживал по этому поводу.
Давайте посмотрим, что нового VMware добавила в Converter за прошедшие почти 2 года:
Поддержка целевых хостов VMware vSphere 6.5 Update 1.
Поддержка новых ОС физических серверов - Windows Server 2016 и Ubuntu 16.
Новая конфигурация для миграции Linux-серверов. Теперь можно указать путь ко временным файлам vmware-sysinfo, которые будут распакованы и запущены.
Новая опция, позволяющая изменить дефолтный тип диска целевой виртуальной машины с thick ("толстого") на thin ("тонкий"). Для этого нужно отредактировать файл converter-worker.xml.
Не так уж и много, да? Похоже, конвертером особо никто не занимался... Таким образом, список поддерживаемых конвертеров операционных систем выглядит так:
Windows Vista SP2 до Windows 10
Windows Server 2008 SP2 до Windows Server 2016
CentOS 6.x and 7.0
Red Hat Enterprise Linux 4.x up to 7.x
SUSE Linux Enterprise Server 10.x and 11.x
Ubuntu 12.04 LTS, 14.04 LTS, and 16.04 LTS
Офлайн конверсия машин с Microsoft Hyper-V может быть проведена для следующих ОС:
Windows Server 2008 R2 (64-bit)
Windows Server 2012 (64-bit)
Windows Server 2012 R2 (64-bit)
Windows 10 (64-bit)
Windows Server 2016 (64-bit)
Более подробно о новой версии VMware vCenter Converter Standalone 6.2 написано в Release Notes, скачать продукт можно по этой ссылке.
Часто администраторы виртуальной инфраструктуры VMware vSphere испытывают необходимость увеличить размер виртуального диска VMDK, который защищен технологией репликации VMware vSphere Replication. Если попытаться увеличить диск из vSphere Client, то вы получите вот такую ошибку:
vSphere Replication does not support changing the length of a replicated disk
Поэтому для увеличения реплицируемого VMDK-диска нужно сделать следующее:
Переименуйте папку с виртуальной машиной и виртуальным диском на резервном сайте. Это нужно для того, чтобы при отключении репликации папка с ВМ на резервной площадке не удалилась.
Запомните настройки репликации ВМ (RPO, датастор назначения и т.п.).
Отключите репликацию виртуальной машины.
Увеличьте размер виртуального диска на основной площадке из GUI vSphere Web Client через Edit Settings.
Теперь увеличьте размер виртуального диска на резервной площадке с помощью утилиты vmkfstools. Для этого выполните команду:
vmkfstools –X 50G virtual_machine.vmdk
Далее на резервном сайте переименуйте папку с ВМ обратно к исходному имени.
Настройте репликацию ВМ заново, выбрав пункт Specify datastore folder и указав папку с ВМ, которую будете реплицировать. Появится сообщение:
A file with the name ‘[<datastore>] <folder>/<filename> already exists. Press Yes to use file as an initial copy.
Нажимайте Yes и репликация должна завестись.
Если вы не увеличите размер виртуального диска на резервной площадке, то получите вот такое сообщение об ошибке:
The capacity of the seed disk does not match the capacity of the replication source disk. Create a new seed copy or verify that you selected the correct seed to use for this replication
Поэтому не пропускайте этот шаг. Также о процедуре написано в KB 2052883.
А где же такие службы, как vmware-vpostgres, vpxd и прочие? Все просто - их запускает служба vmon. Это новый watchdog-сервис, который управляет службами vCSA в vSphere 6.5 и унифицирует доступ к ним через API.
Чтобы увидеть, в каком порядке она запускает прочие сервисы, выполним команды vmon-cli для остановки и запуска служб vmon на сервере vCSA:
/usr/lib/vmware-vmon/vmon-cli --batchstop ALL
/usr/lib/vmware-vmon/vmon-cli --batchstart ALL
Вывод будет примерно таким:
root@vc01 [ /var/log/vmware/vmon ]# grep "Executing op START on service" vmon-sys
17-12-12T09:44:23.639142+00:00 notice vmon Executing op START on service eam...
17-12-12T09:44:23.643113+00:00 notice vmon Executing op START on service cis-license...
17-12-12T09:44:23.643619+00:00 notice vmon Executing op START on service rhttpproxy...
17-12-12T09:44:23.644161+00:00 notice vmon Executing op START on service vmonapi...
17-12-12T09:44:23.644704+00:00 notice vmon Executing op START on service statsmonitor...
17-12-12T09:44:23.645413+00:00 notice vmon Executing op START on service applmgmt...
17-12-12T09:44:26.076456+00:00 notice vmon Executing op START on service sca...
17-12-12T09:44:26.139508+00:00 notice vmon Executing op START on service vsphere-client...
17-12-12T09:44:26.199049+00:00 notice vmon Executing op START on service cm...
17-12-12T09:44:26.199579+00:00 notice vmon Executing op START on service vsphere-ui...
17-12-12T09:44:26.200095+00:00 notice vmon Executing op START on service vmware-vpostgres...
17-12-12T09:45:33.427357+00:00 notice vmon Executing op START on service vpxd-svcs...
17-12-12T09:45:33.431203+00:00 notice vmon Executing op START on service vapi-endpoint...
17-12-12T09:46:54.874107+00:00 notice vmon Executing op START on service vpxd...
17-12-12T09:47:28.148275+00:00 notice vmon Executing op START on service sps...
17-12-12T09:47:28.169502+00:00 notice vmon Executing op START on service content-library...
17-12-12T09:47:28.176130+00:00 notice vmon Executing op START on service vsm...
17-12-12T09:47:28.195833+00:00 notice vmon Executing op START on service updatemgr...
17-12-12T09:47:28.206981+00:00 notice vmon Executing op START on service pschealth...
17-12-12T09:47:28.220975+00:00 notice vmon Executing op START on service vsan-health...
Как мы видим, службы запускаются в следующем порядке:
Известный своими скриптами блоггер Luc Dekens (LucD) опубликовал интересный сценарий PowerCLI для виртуальной инфраструктуры VMware vSphere, который позволяет вычистить права доступа на объекты, для которых уже существуют права на уровне родительских объектов.
Например, у вас есть такая картина:
Соответственно, нам нужно почистить пермиссии в папке Test1131 для пользователя Local\test, чтобы разрешения остались только на уровне родительского объекта Test1 (там, как мы видим, установлена опция применения разрешений вниз к дочерним объектам).
Собственно, сам скрипт:
<#
.SYNOPSIS
Find and remove redundant permissions on vSphere objects
.DESCRIPTION
The function will recursively scan the permissions on the
inventory objects passed via the Entity parameter.
Redundant permissions will be removed.
.NOTES
Author: Luc Dekens
.PARAMETER Entity
One or more vSphere inventory objects from where the scan
shall start
.EXAMPLE
PS> Optimize-Permission -Entity Folder1 -WhatIf
.EXAMPLE
PS> Optimize-Permission -Entity Folder?
.EXAMPLE
PS> Get-Folder -Name Folder* | Optimize-Permission
#>
[cmdletbinding(SupportsShouldProcess=$true)]
param(
[parameter(ValueFromPipeline)]
[PSObject[]]$Entity
)
Begin{
function Optimize-iVIPermission{
[cmdletbinding(SupportsShouldProcess=$true)]
param(
[parameter(ValueFromPipeline)]
[VMware.Vim.ManagedObjectReference]$Entity,
[VMware.Vim.Permission[]]$Permission = $null
)
Process{
$entityObj = Get-View -Id $Entity
$removePermission = @()
$newParentPermission = @()
if($Permission){
foreach($currentPermission in $entityObj.Permission){
foreach($parentPermission in $Permission){
if($parentPermission.Principal -eq $currentPermission.Principal -and
$parentPermission.RoleId -eq $currentPermission.RoleId){
$removePermission += $currentPermission
break
}
else{
$newParentPermission += $currentPermission
}
}
}
}
else{
$newParentPermission += $entityObj.Permission
}
if($removePermission){
if($pscmdlet.ShouldProcess("$($entityObj.Name)", "Cleaning up permissions")){
$removePermission | %{
$authMgr.RemoveEntityPermission($Entity,$_.Principal,$_.Group)
}
}
}
$Permission += $newParentPermission
if($entityObj.ChildEntity){
$entityObj.ChildEntity | Optimize-iVIPermission -Permission $Permission
}
}
}
}
Process{
foreach($entry in $Entity){
if($entry -is [System.String]){
$entry = Get-Inventory -Name $entry
}
Optimize-iVIPermission -Entity $entry.ExtensionData.MoRef
}
}
}
Скрипт работает так, что пробегается по дереву объектов, обнаруживает избыточные разрешения и удаляет их. У скрипта есть удобный параметр WhatIf, который выводит операции по очистке разрешений, которые как бы применяются к дочерним объектам, но на самом деле не применяет их:
Optimize-VIPermission -Entity Test1 -WhatIf
Результатом будет список объектов, где разрешения будут очищены, в данном случае, если посмотреть на пример выше, это будет папка Test1131:
Можно запустить скрипт и на 2 папки сразу:
Optimize-VIPermission -Entity Test1,Test2 -WhatIf
Результат будет таким (в папке Test22 также есть дублирующиеся разрешения):
Также можно использовать и конструкции с масками, например:
Теперь неплохо было бы, если бы кто-то написал GUI к этой штуке, а также добавил туда функции поиска и удаления произвольных разрешений в выбранных объектах.
Как знают администраторы VMware vSphere, с выходом каждой новой версии платформы увеличиваются и максимумы для ее компонентов. Многие из этих максимумов трудно достижимы на практике, поскольку еще нет серверов такой возможности (например, для запуска такого количества машин в производственной среде), но некоторые аспекты требуют того, чтобы лимиты параметров были увеличены (например, число vNIC на одну машину иногда для тестирования нужно больше).
Давайте взглянем на эволюцию максимумов VMware vSphere в таблицах ниже, где отображены параметры версии 5.5, 6.0 и 6.5:
Максимумы виртуальных машин
Параметры виртуальных машин
ESXi 5.5
ESXi 6.0
ESXi 6.5
vCPU на ВМ
64
128
128
RAM на ВМ
1 ТБ
4 ТБ
6 ТБ
Размер виртуального диска на ВМ
62 ТБ
62 ТБ
62 ТБ
Виртуальных сетевых адаптеров на ВМ (vNIC)
10
10
10
Виртуальных адаптеров SCSI на ВМ
4
4
4
Таргетов для виртуальных адаптеров SCSI на ВМ
60
60
60
Виртуальных адаптеров NVMe на ВМ
-
-
4
Таргетов для виртуальных адаптеров NVMe на ВМ
-
-
60
Видеопамяти на ВМ
512 МБ
512 МБ
2 ГБ
Максимумы вычислительных мощностей VMware ESXi
Вычислительные мощности
ESXi 5.5
ESXi 6.0
ESXi 6.5
Логических CPU на хост
320
480
576
Epkjd NUMA на хост
16
16
16
Виртуальных машин на хост
512
1024
1024
Виртуальных процессоров (vCPU) на хост
4096
4096
4096
Виртуальных процессоров (vCPU) на ядро
32
32
32
Оперативной памяти (RAM) на хост
4 ТБ
12 ТБ
12 ТБ
Максимумы хранилищ VMware ESXi
Параметры хранилищ ESXi
ESXi 5.5
ESXi 6.0
ESXi 6.5
Виртуальных дисков на хост
2048
2048
2048
Логических томов LUN на хост
256
256
512
Адаптеров iSCSI NIC на хост
8
8
8
Число путей к хранилищам на один хост
1024
1024
2048
Число путей к одному LUN (software+hardware iSCSI) на хост
8
8
8
Таргетов программного iSCSI на хост
256
256
256
NAS: монтирований NFS-томов на хост
256
256
256
Fibre Channel (FC): число адаптеров HBA любого типа на хост
8
8
8
Программных адаптеров FCoE на хост
4
4
4
Размер тома VMFS
64 TB
64 TB
64 TB
Томов на хост
256
256
512
Хостов ESXi на один том
64
64
64
Включенных виртуальных машин на один том VMFS
2048
2048
2048
Одновременных операций vMotion на один том VMFS
128
128
128
Максимумы сетевого взаимодействия VMware ESXi
Параметры сетевого взаимодействия ESXi
ESXi 5.5
ESXi 6.0
ESXi 6.5
Портов 1 Gb Ethernet (Intel) - igb - на хост
16
16
16 (igbn)
Портов 1Gb Ethernet (Broadcom) - tg3 - на хост
32
32
32 (ntg3)
Портов 1Gb Ethernet (Broadcom) - bnx2 - на хост
16
16
16
10Gb Ethernet (Intel) - ixgbe - на хост
8
16
16
Портоы 10Gb Ethernet (Broadcom) - bnx2x - на хост
8
8
8
Комбинация портов 10Gb и 1Gb на хосте
До восьми портов 10Gb и до четырех портов 1Gb
До шестнадцати 10 Gb и до четырех 1 Gb ports
До шестнадцати 10 Gb и до четырех 1 Gb ports
Портов 40GB Ethernet Ports (Mellanox) - mlx4_en - на хост
4
4
4 (nmlx4_en)
Число виртуальных устройств SR-IOV на хост
64
1024
1024
Число физических сетевых адаптеров SR-IOV 10G на хост
8
8
8
Портовых групп VSS на хост
1000
1000
1000
Распределенных виртуальных коммутаторов на хост
16
16
16
Всего портов виртуальных коммутаторов на хост (неважно VDS или VSS)
4096
4096
4096
Максимально активных портов на хост (VDS и VSS)
1016
1016
1016
Число виртуальных портов на одном виртуальном коммутаторе (VSS)
4088
4088
4088
Групп портов на стандартный виртуальный коммутатор
С начала ноября мы не писали про тонкий клиент на базе HTML5 для управления виртуальной инфраструктурой - VMware vSphere Client (тогда он был версии 3.27). На днях компания VMware выпустила его версию 3.30, поэтому давайте рассмотрим новые возможности, которые появились в последних трех версиях клиента - VMware vSphere Client 3.28-3.30.
Итак, что нового:
Просмотр имеющихся лицензий (Host/Cluster/функции Solutions) - пока работает в режиме Read-Only.
Доступны детали лицензированных продуктов и их фичей.
Детали лицензий сервера vCenter и хостов ESXi (Host License) - доступно в разделе Configure > Licensing.
Проверки состояния vSphere Distributed Switch (vDS health checks).
Настройка фильтрации трафика и правил его маркировки на уровне распределенных порт-групп.
Экспорт и импорт распределенных виртуальных коммутаторов (vDS) и распределенных порт-групп.
Настройка политик распределенных порт-групп внутри мастера создания новой порт-группы.
Настройка CPU Identification Mask в разделе Advanced.
Выбор паравиртуализованного сетевого адаптера PVRDMA для сети виртуальных машин.
Скачать последнюю версию VMware vSphere Client 3.30 можно по этой ссылке.
Cormac Hogan написал занимательный пост о об использовании дискового пространства в кластере VMware vSAN. Всех интересует - умеет ли vSAN возвращать дисковое пространство хранилищу при удалении файлов в гостевой ОС виртуальной машины? Ответ - пока нет, но над этим работают.
Cormac провел вот какой эксперимент: взял виртуальную машину в кластере vSAN с гостевой ОС Windows Server 2012 R2, у которой было 386.7 ГБ занятого места (сама ВМ была развернута на тонких дисках):
Затем он скопировал туда данные на 800 МБ, после чего увидел, что занятое место увеличилось до 388.37 ГБ, то есть выросло на 1,6 ГБ. Это логично, так как vSAN работал в режиме RAID-1 (зеркалированные VMDK-диски):
Далее он удалил только что скопированные файлы и убедился, что занятое дисковое пространство осталось тем же самым (то есть, в vSAN нет поддержки UNMAP/TRIM изнутри гостевой системы):
Между тем, он снова скопировал те же 800 МБ и к радости администраторов заметил, что дисковое пространство увеличилось лишь на 20 МБ (в совокупности на 40 МБ с учетом RAID-1).
То есть занятые после прошлого копирования блоки были использованы повторно:
Такая штука есть у Windows Server, но у Linux в файловой системе ext4 такой трюк не прокатит - все равно при повторном копировании блоки разместятся в другом месте, и пространство будет использовано повторно. Но это особенность файловой системы ext4, об этом подробно написано тут и тут. Для ФС ext3 и XFS это не актуально, там блоки тоже будут переиспользоваться.
Ну и помните, что описанное применимо только для удаления файлов изнутри гостевой ОС, если же вы удалите на хранилище vSAN виртуальную машину или другой объект - пространство сразу же вернется в общий пул хранения.
Мы часто пишем о встроенной утилите на хосте ESXi - esxtop, которая позволяет отслеживать все основные аспекты производительности хост-серверов и виртуальных машин (процессор, память, диски и сеть). Напомним, что наши последние посты о esxtop расположены тут, тут, тут, тут, тут и тут.
А недавно вышло весьма полезное образовательное видео "Using esxtop to Troubleshoot Performance Problems", в котором показано на практическом примере, как именно использовать esxtop для решения проблем производительности (хотя голос и весьма уныл):
Ну и напомним, что у esxtop есть графический интерфейс - это утилита VisualEsxtop.
Довольно давно мы ужерассказывали о механизме применения политик для хранилищ при развертывании виртуальных машин - VMware vSphere Storage Policy Based Management (SPBM). А недавно Кормак Хоган опубликовал интересную заметку, касающуюся возможности выбора политик SPBM конкретным пользователем во время развертывания новой виртуальной машины.
Прежде всего, в vSphere нет механизма назначения прав доступа пользователей на конкретную политику SPBM - все пользователи видят все политики. Но сам механизм разграничения прав существует - его можно реализовать на уровне прав доступа к хранилищам.
Например, пользователю ben мы даем доступ Read-only к хранилищу VVols1, то есть создавать виртуальные машины он на нем не может:
А на хранилище VVols2 делаем его администратором:
В итоге, при развертываниии виртуальной машины пользователь ben видит оба хранилища - VVols1 и VVols2 и все доступные политики хранилищ (комбобокс VM storage policy):
Однако, обратите внимание, что при выборе хранилища VVols1 в разделе Compatibility написано о том, что пользователь не имеет достаточных привилегий, чтобы создать машину на этом датасторе.
You do not hold the privilege to allocate space on the selected datastore
Между тем, кнопка Next активна. Но если нажать ее, мастер все равно дальше не пустит:
Вверху мы увидим:
Specify a valid location
Ну а если выбрать VVols2, то все проверки пройдут успешно, и пользователь сможет там создать виртуальную машину:
Бывает, что попытке развернуть виртуальную машину из шаблона (Template) вы получаете сообщение об ошибке "Customization of the guest operating system is not supported in this configuration":
Как правило, это происходит из-за того, что в машине не установлены VMware Tools. Просто сконвертируйте шаблон в ВМ, потом включите ее и установите тулзы, после чего конвертируйте машину опять в Template.
Также такая ситуация бывает, когда vCenter не поддерживает гостевую ОС виртуальной машины для кастомизации, либо когда развертывание происходит на NFS-хранилище, для которого не включена опция "no root squash".
Прежде всего, KMS - это сервисы шифрования не только для виртуальных машин, но и любых других объектов ИТ-инфраструктуры. Поэтому KMS уже может быть в вашей организации, при этом он может не быть прикрученным к VMware vSphere. Вы можете использовать любой KMS-сервер, но VMware сертифицировала лишь следующие системы из списка (см. вот этот документ VMware):
Если же у вас другой KMS-провайдер, не расстраивайтесь - он, скорее всего, будет работать, если поддерживает протокол управления ключами KMIP 1.1.
Начать надо с вопросов доступности KMS-сервера. Как вы понимаете, это самый важный сервер в вашей инфраструктуре, важнее DNS или контроллера домена. Если у вас недоступен DNS, все тоже не работает, как и в случае с KMS, но если оказались недоступными данные хранилища KMS - это катастрофа для организации. И нет абсолютно никакого пути восстановить их. Совершенно никакого. Обо всем этом рассказывает видео ниже:
Таким образом, KMS становится бизнес-критичной точкой не только инфраструктуры, но и бизнеса в целом. И вопросы бэкапа и его доступности - это вопросы номер 1. Давайте посмотрим на несколько базовых понятий KMS:
KMIP (Key Management Interoperability Protocol) - это стандарт, по которому клиент KMIP может общаться с серверами KMS. Каждый год он проходит серьезную проверку на конференции RSA.
DEK (Data Encryption Key). Это ключ, который хост ESXi генерирует, когда требуется зашифровать виртуальную машину. Этот ключ используется также и для расшифровывания данных ВМ, он записан в VMX/VM Advanced settings в зашифрованном виде.
KEK (Key Encryption Key). Это ключ, которым зашифрован DEK. KEK key ID также находится в VMX/VM Advanced settings.
Key Manager Cluster/Alias - это коллекция адресов FQDN/IP всех реплицируемых между собой серверов KMS. Она также хранится вместе с зашифрованной машиной в VMX/VM Advanced settings, чтобы после ее включения можно было обратиться к нужному кластеру KMS, получить KEK для cервера vCenter, который разлочит ВМ.
VM и vSAN encryption - это, на самом деле, с точки зрения реализации механизма шифрования одно и то же. То есть, для обоих типов шифрования используются одни и те же библиотеки, конфигурации и интерфейсы.
Когда мы говорим о кластере KMS - это всего лишь KMS-серверы, реплицирующие между собой хранилища ключей. Они не обеспечивают доступность друг друга, как, например, это делает VMware HA. Например, есть серверы KMS-A, KMS-B и KMS-C, в хранилищах которых при добавлении ключа новой ВМ он появляется мгновенно.
Если KMS-A недоступен как сервер, то сервер vCenter запрашивает ключи у хоста KMS-B. Если же KMS-A недоступен как сервис (то есть сервер работает, а служба KMS не отвечает), то vCenter ждет 60 секунд восстановления работоспособности сервиса и только потом переключается на KMS-B. Это поведение изменить нельзя.
Лучшие практики по использованию KMS таковы:
По возможности нужно делегировать обязанности по поддержке инфраструктуры KMS отдельной команде (Security Team) или человеку.
Не класть KMS-серверы в виртуальной машине в тот же кластер (например, vSAN), который также зашифрован. Иначе коробочка закроется (выключится кластер), а ключ от нее останется внутри нее же. То есть, необходимо держать хотя бы один из KMS-серверов за пределами такого домена отказа.
Предыдущий пункт относится и к серверам vCenter и PSC. Чтобы они могли расшифровать другие сервера, они должны быть доступны в случае сбоя.
Теперь надо сказать о катастрофоустойчивости серверов KMS. Типичный кластер в рамках одной площадки выглядит так:
Но если на этой площадке будет авария, которая затронет все 3 сервера - бизнесу может настать конец. Поэтому в идеале надо использовать конфигурацию с двумя площадками:
Понятное дело, что у малого и среднего бизнеса резервных площадок, как правило, нет. В этом случае помочь может публичное облако Amazon AWS или Microsoft Azure. Чтобы поддерживать там одну резервную машину, много денег не нужно.
Ну и если вы используете конфигурацию с несколькими площадками, то обязательно нужно учитывать в конфигурации порядок обращения к серверам KMS в рамках площадки. Если на первой площадке находятся сервера KMS-A, KMS-B и KMS-C, а на второй - KMS-D, KMS-E и KMS-F, то в первом случае порядок должен быть A,B,C,D,E,F, а во втором - D,E,F,A,B,C.
Если на второй площадке вы будете использовать конфигурацию аналогичную первой, сервер vCenter может ходить по серверам другой площадки, которая может быть недоступна, а только обойдя все ее серверы, начнет использовать локальные KMS.
Мы много пишем о технологии Virtual Volumes (VVols), которая сравнительно недавно появилась в платформе виртуализации VMware vSphere. Совсем недавно мы писали о том, что будет в следующих версиях VVols, а сегодня давайте посмотрим на текущее положение дел.
Eric Siebert написал интересный пост о том, сколько компаний использует VVols сейчас в производственно среде. На данный момент VVols применяется примерно у 2% клиентов VMware, что весьма и весьма мало. Связано это, в первую очередь, с ограничениями технологии и небольшим количеством партнеров ее поддерживающих.
Между тем, подвижки в этом направлении уже есть. Вот какие факторы будут способствовать развитию VVols в ближайшем будущем (Эрик считает, что более половины всех пользователей vSphere будут применять эту технологию):
Все больше клиентов переходят с vSphere 5.5 на vSphere 6.x, где VVols полностью поддерживаются.
Рано или поздно каждый администратор приходит к тому, что ему необходимо каким-то образом сохранить, а потом и извлечь учётные данные. Причём это должно быть быстро, эффективно, удобно и самое главное безопасно. Ни один из известных мне способов не отвечал всем этим требованиям одновременно. Я стал искать и нашел свой способ, которым и хочу поделиться с вами. Это PowerCLI! Удивлены? Порой самое простое решение лежит на поверхности.
Наш читатель Стас обратил внимание на то, что в начале ноября компания VMware выпустила значительное обновление для шестой версии платформы виртуализации VMware vSphere 6.0. Были опубликованы апдейты и патчи для ESXi 6.0 - ESXi600-201711001.
В составе гипервизора и прочих компонентов были обновлены следующие пакеты ESXi 6.0:
Обновления коснулись новых возможностей, подсистемы безопасности и исправлений наиболее серьезных ошибок. Чтобы скачать апдейт, нужно пойти на VMware Patch Portal, выбрать ESXi 6.0 и ввести там номер билда (6921384).
Правильно устанавливать обновление нужно следующими командами (если, конечно, на хосте есть интернет):
RSS
