Интересно, что продукты VMware vSphere и VMware vSAN имеют разные списки совместимости оборудования (HCL - Hardware Compatibility Lists). Ronald de Jong в своем блоге описал ситуацию, когда у него драйвер SCSI-контроллера подошел для vSphere, но не подошел для vSAN.
После установки обновления драйвера для VMware vSphere через VMware Lifecycle Manager он получил вот такие ворнинги для vSAN в vSphere Client:
Драйвер smartpqi (70.4000.0.100-4vmw.701.0.0.17325551) уже подходит для vSphere, но еще не провалидирован для решения vSAN. В этом можно убедиться в списке совместимости для vSAN по этой ссылке, где есть только старый драйвер (3vmw):
Таким образом, нужно провести даунгрейд драйвера, чтобы он подходил и для vSphere, и для vSAN. Сначала идем на Patch Portal и находим там нужное обновление в виде VIB-пакета:
Вот этот драйвер:
После загрузки в консоли ESXi запускаем установщик VIB-пакета командой:
Некоторое время назад мы писали об улучшении технологии горячей миграции vMotion (тут и тут) в последней версии VMware vSphere 7 Update 1. Сегодня мы вкратце расскажем о вариантах переноса рабочих нагрузок в кластер хранилищ VMware vSAN на базе вот этой заметки.
Первое, что вы должны решить - это в каком рабочем процессе вы будете мигрировать виртуальные машины с помощью vMotion: за один шаг (хранилище+сервер) или за два (сначала сервер, потом хранилище).
1. Миграция в два шага (Two-Step Migrations)
При выборе миграции виртуальной машины у нас есть опция изменения либо сервера ESXi машины, либо ее хранилища, либо и того, и другого:
Change compute resource only - это первый шаг миграции для случая, когда не-vSAN хранилище может быть презентовано существующему кластеру vSAN. Также это может быть востребовано в рамках топологии VMware vSAN HCI Mesh, где хранилище монтируется удаленному кластеру vSAN.
Change storage only - это второй шаг миграции, когда машина на хосте ESXi уже находится в кластере vSAN, и мы выполняем перенос ее VMDK уже на собственные хранилища кластера.
Надо сказать, что миграция машин в два шага имеет бОльшую гранулярность, что позволит вам получить промежуточный результат и зафиксировать результат в середине (например, смигрированная на другой хост, но не хранилище машина), что может сэкономить время при повторной попытке миграции в случае каких-то проблем.
2. Миграция в один шаг
Этот способ миграции реализуется, когда вы выбираете опцию Change both compute resource and storage или Cross vCenter Server export. Надо понимать, что процесс этот весьма затратный, и выбирать этот вариант можно, когда у вас есть большой запас по ресурсам и времени для вычислительных ресурсов и ресурсов хранилищ. Ну или когда вы не можете расшарить хранилище между двумя разными кластерами vSphere / vSAN.
Удобство это способа еще и в том, что если у вас есть много времени на миграцию, то можно просто поставить vMotion для нужных нагрузок, и все будет постепенно переезжать без участия администратора.
Также для переноса нагрузок между разными инфраструктурами есть опция Cross vCenter Server export. В обновлении VMware vSphere 7 Update 1c главным нововведением стала интеграция функций миграции Advanced Cross vCenter Server vMotion Capability (ранее это был виртуальный модуль Cross vCenter Workload Migration Utility) в интерфейс vSphere Client. Оно же называется XVM.
Эта функциональность используется для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). При этом не требуется настроенного механизма Enhanced Linked Mode (ELM) или Hybrid Linked Mode (HLM) для серверов vCenter в разных датацентрах.
Если вы решили сделать пакетную миграцию виртуальных машин в vSphere Client, то нужно для кластера или пула ресурсов перейти на вкладку VMs и с шифтом выбрать группу ВМ для миграции, после чего из контекстного меню выбрать Migrate...:
Надо сказать, что машины одной группы можно мигрировать только в одинаковом состоянии (Powered on или Powered off), поэтому удобно отсортировать их по колонке State.
Ну и в заключение - картинка об улучшении технологии vMotion с момента ее появления в 2003 году:
На сайте проекта VMware Labs обновились четыре полезные утилиты, про которые мы уже не раз писали. Давайте посмотрим, что именно в них появилось нового:
1. VMware OS Optimization Tool билд b2001
Про прошлый апдейт этой утилиты мы писали вот тут. Напомним, что это средство предназначено для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач.
Что появилось нового:
Все записи оптимизаций снова добавили в шаблон main user template, теперь можно их тюнинговать вручную.
Исправлены два параметра аппаратных оптимизаций и ускорения, которые ранее настраивались в одной опции.
Во время фазы Optimize оптимизации экспортируются в файл json (%ProgramData%\VMware\OSOT\OptimizedTemplateData.json).
Во время фазы Analyze, если дефолтный файл json существует (то есть образ уже оптимизирован), то он импортируется и используется при выборе оптимизаций с прошлым выбором параметров. Также если выбор дефолтных состояний обязателен, то перед каждым запуском утилиты нужно удалять этот файл.
Файл OptimizedTemplateData.json можно использовать в командной строке с параметром -applyoptimization.
Улучшена работа с параметрами для служб Hyper-V, которые требуются для облачного сервиса Azure.
Скачать VMware OS Optimization Tool можно по этой ссылке.
2. vSphere Software Asset Management Tool версии 1.3
Напомним, что Software Asset Management Tool предназначен для сбора подробной информации об инсталляции VMware vSphere на вашей площадке, касающуюся лицензирования - инвентаря и доступности лицензий.
О прошлой версии этой утилиты мы писали вот тут, а вот что появилось нового в версии 1.3:
Отображение продуктов семейства Tanzu в генерируемых отчетах
Несколько исправлений ошибок
Скачать Software Asset Management Tool 1.3 можно по этой ссылке.
3. DRS Dump Insight версии 2.0
Напомним, что о прошлой версии Dump Insight 1.1 мы писали здесь. Это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS.
Давайте посмотрим, что появилось нового:
Добавлена поддержка дампов vSphere 7.0 и 7.0 Update 1
Доступен выбор нескольких отдельных дампов для анализа из общего списка
Об этой утилите мы писали вот тут. Она позволяет показывать различную информацию об оконечных устройствах на рабочих станциях (Certificate Management, Application Deployment, Profile Management).
Что появилось нового:
Обновлена иконка приложения
Появился мониторинг компонентов VMware Horizon Client, VMware Digital Experience Telemetry и VMware Hub Health services
Скачать Workspace ONE Discovery 1.1 можно по этой ссылке.
Компания VMware обновила свое руководство для быстрого старта с инфраструктурой виртуализации настольных ПК и приложений - Quick-Start Tutorial for VMware Horizon 8. Это один из самых популярных материалов на VMware TechZone на сегодняшний день, он позволяет начинающим администраторам VMware vSphere и Horizon развернуть тестовую VDI-среду в своей компании за пару часов.
VMware проделала значительную работу по оптимизации руководства, и теперь его объем сокращен с 222 страниц (для Horizon 7) до 63 страниц (Horizon 8). Все это позволяет быстро начать развертывание решения, а уже потом постигать детали.
То, что вы будете делать, в рамках прочтения руководства и развертывания продукта, будет выглядеть так:
Основные фазы будут следующего содержания:
Install - начнете с установки Horizon Connection Server, который управляет сессиями пользователей для десктопов и приложений на базе веб-консоли Horizon Administrative Console.
Prep - с использованием vSphere Client вы создадите образы Windows-десктопов, а также сервера RDSH для виртуализованных приложений. Кроме того, вы поставите Horizon Agent в гостевые ОС.
Configure - создадите пул виртуальных ПК и ферму серверов с виртуализованными приложениями, а также назначите для них права доступа.
Output - из iOS, Android, Chromebook, Windows, macOS или Linux подключитесь к виртуальным ПК, загрузив соответствующую версию Horizon Client или зайдя через браузер (HTML Access web client).
После выполнения всех описанных задач вы получите готовую инфраструктуру Horizon с несколькими опубликованными приложениями (на базе сервисов Microsoft Remote Desktop Session Host, RDSH), а также пул виртуальных десктопов на базе Windows 10.
Руководство Quick-Start Tutorial for VMware Horizon 8 доступно по этой ссылке.
Недавно компания VMware полностью переработала портал документации для разработчиков. Там произошел редизайн интерфейса, была улучшена категоризация, а также юзабилити в целом. При этом ранее документация по PowerCLI существовала отдельно от этого портала.
Теперь домашняя страница VMware PowerCLI полностью интегрирована в портал документации, а также получила много новых фич. Давайте на них взглянем:
1. Компоновка домашней страницы
Теперь с нее вы можете перейти на:
Сообщество разработчиков
Пример репозитория на GitHub
Фиче-реквесты
Блог PowerCLI
Release notes
Сhangelog
Руководство пользователя
То есть это теперь простая и удобная, но функциональная стартовая страница.
2. Организация командлетов по продуктам
Ранее все командлеты были организованы по модулям, что было неудобно для пользователей. Теперь стало намного удобнее, потому что можно проваливаться в каталог командлетов по продуктам:
3. Глобальный поиск
Неважно, какой раздел вы смотрите сейчас, вы всегда сможете воспользоваться функцией глобального поиска:
4. Вкладка структуры данных
Разделы помощи ориентированы на объекты PowerCLI. Теперь на отдельной вкладке Data Structure
можно увидеть, как эти объекты обрабатываются со стороны командлетов.
5. Категории
В рамках разделов по продуктам можно искать командлеты по понятным категориям из меню слева:
6. Страница CMDLET Reference
Эта страница позволяет понять как устроен командлет, и как он используется. Работает подсветка кода, и приведены простые примеры использования, которые вы можете скачать и уже самостоятельно изменять для получения наглядного результата. Вот пример такой страницы для командлета Connect-VIServer.
Если вы хотели бы узнать, какие продукты есть у VMware, кроме тех, что у всех на слуху (вроде vSphere, vSAN и Horizon), то мы можем порекомендовать отличный документ - "VMware Product Guide". Там на ста страницах говорится обо всех продуктах, актуальных на декабрь 2020 года. Основная цель этого документа - рассказать об условиях использования и лицензирования, но из общей таблицы вы узнаете, что вообще есть в портфолио у VMware:
Ну а для тех, кто хочет увидеть весь список сразу со всеми ссылками на продукты, vCendra опубликовала вот такой интересный слайд от Ezzeldin Hussein, на котором можно увидеть все доступное на сегодня портфолио решений (кликабельно):
Скачать слайд в формате PPTX можно по этой ссылке.
Не все администраторы VMware vSphere и vSAN знают, что в версии vSAN 6.7 Update 3 появилась утилита vsantop, которая по аналогии с esxtop, используемой для получения метрик с хостов ESXi, позволяет получать метрики с устройств и хранилищ vSAN.
Запускается утилита просто: vsantop
По умолчанию она отображает метрики для сущности host-domclient. Чтобы выбрать нужную вам сущность - устройства, хост или кластер, нужно нажать большую клавишу <E> с шифтом:
После того, как вы выберете нужную сущность, будут отображаться метрики для нее с дефолтными колонками в данной категории. Чтобы выбрать колонки, нужно нажать клавишу <f>:
Для отображения можно выбрать только 10 полей, если хотите добавить какое-то поле, то какое-то из текущих придется убрать.
Также esxtop может работать в пакетном режиме с заданным интервалом и записывать метрики в CSV-файл:
vsantop -b -d [delay] -n [iterations] > [file location & name]
usage: vsantop [-h] [-v] [-b] [-d delay] [-n iterations]
-h prints this help menu.
-v prints version.
-b enables batch mode.
-d sets the delay between updates in seconds.
-n runs vsantop for only n iterations. Use "-n infinity" to run forever.
Например, вот такая команда запустит сбор метрик с 10-секундным интервалом, всего будет 20 таких итераций, а результаты будут записаны в файл CSV:
VMware выпустила 2 новых экзамена VMware Certified Advanced Professional (VCAP)
На днях компания VMware объявила о релизе обновленных версий экзаменов VMware Certified Advanced Professional (VCAP). Первый - Advanced Design VMware vSphere 7.x (3V0-21.21) - подтверждает знание кандидатами принципов разработки концептуальной архитектуры VMware vSphere 7.x с учетом требований заказчика, возможность определения функциональных и нефункциональных требований для создания логического дизайна инфраструктуры, а также создания физической архитектуры с учетом всего этого.
Экзамен содержит 60 вопросов и заданий, 300 очков проходной балл и 150 минут на сдачу. Описание экзамена (Blueprint) находится вот тут.
Второй выпущенный экзамен - это Advanced Deploy VMware vSphere 7.x (3V0-22.21). Он проверяет знания по планированию и развертыванию решения vSphere 7.x, включая задачи по администрированию, оптимизации и траблшутингу. Тут уже больше про Day-2 Operations.
Многие администраторы решения для создания отказоустойчивых хранилищ VMware vSAN иногда задумываются, чем отличаются политики хранилищ виртуальных машин (Storage Policies) для растянутых кластеров в плане Disaster Tolerance.
Дункан Эппинг написал об этом полезную заметку. Если вы не хотите, чтобы ваша виртуальная машина участвовала в растянутом кластере, то вам следует выбрать один из двух вариантов для настройки Site Disaster Tolerance: хранить все данные на основном сайте или все на резервном:
None – Keep data on preferred (stretched cluster)
None – Keep data on non-preferred (stretched cluster)
Между тем, в интерфейсе есть несколько схожих вариантов:
Например, есть еще два, казалось бы, подходящих:
None – Stretched Cluster
None – Standard Cluster
Но оба этих варианта политик хранилищ для растянутых кластеров не подходят. В первом случае (None – Stretched Cluster) виртуальная машина будет обрабатываться на уровне дисковых объектов, и vSAN будет решать, куда их поместить в растянутом кластере. Вполне может получиться такая ситуация, что один VMDK находится на одной площадке, а второй - на другой. При этом сама машина же может исполняться только на одном ESXi:
Такая ситуация очевидно очень плоха с точки зрения производительности.
Во втором же случае (None – Standard Cluster), если ваша машина настроена с точки зрения хранилищ на RAID-1 и FTT=1, то в растянутом кластере это превращается в SFTT=0 (Stretched FTT), что означает, что данные с одной площадки будут зеркалироваться на другую, но на уровне одной площадки будет храниться только одна копия данных дисковых объектов, что плохо с точки зрения надежности и отказоустойчивости.
Поэтому в растянутых кластерах для машин, которым не нужна "растянутость", используйте настройки Keep data on preferred или Keep data on non-preferred.
Решение для виртуализации сетей VMware NSX-T, в отличие от его vSphere-версии NSX-V, не имеет графического интерфейса для настройки отсылки логов на серверы Syslog.
Graham Smith написал краткую заметку о настройке Syslog для решения VMware NSX-T, включая NSX-T Manager, узлы Edge Nodes и серверы ESXi.
Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware Log Insight. Сначала заходим по SSH на NSX-T Manager и выполняем там следующую команду, указав IP-адрес сервера Log Insight:
MulNSXT01> set logging-server 192.168.10.8 proto udp level info
WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.
На узлах Edge Nodes
также нужно выполнить такую же команду, зайдя по SSH:
DCA-MulNSXT-ESG01> set logging-server 192.168.10.8 proto udp level info
WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.
На серверах ESXi процесс выглядит несколько иначе. Нужно выполнить вот такую последовательность команд:
[root@DCA-MulComp01:~] esxcli network firewall ruleset set -r syslog -e true
[root@DCA-MulComp01:~] esxcli system syslog config set --loghost=udp://192.168.10.8:514
[root@DCA-MulComp01:~] esxcli system syslog reload
[root@DCA-MulComp01:~] esxcli system syslog mark -s "This is a test message"
Первая команда разрешает в фаерволе трафик Syslog, вторая - настраивает сервер адрес сервера, третья - подхватывает настройки, ну а четвертая - отсылает тестовое сообщение, чтобы можно было проверить работоспособность механизма Syslog со стороны Log Insight.
Там это тестовое сообщение можно увидеть в разделе Events:
Чтобы проверить логирование на стороне фаервола, можно создать простое правило с тестовым тэгом:
Далее в Log Insight можно увидеть это событие, поискав по этому тегу:
Чтобы проверить конфигурацию Syslog на стороне сервера ESXi, нужно выполнить следующую команду:
[root@DCA-MulComp01:~] esxcli system syslog config get
Check Certificate Revocation: false
Default Network Retry Timeout: 180
Dropped Log File Rotation Size: 100
Dropped Log File Rotations: 10
Enforce SSLCertificates: true
Local Log Output: /scratch/log
Local Log Output Is Configured: false
Local Log Output Is Persistent: true
Local Logging Default Rotation Size: 1024
Local Logging Default Rotations: 8
Log To Unique Subdirectory: false
Message Queue Drop Mark: 90
Remote Host: udp://192.168.10.8:514
Strict X509Compliance: false
На стороне NSX-T Manager и на узлах Edge Nodes конфигурацию Syslog можно проверить такой командой:
DCA-MulNSXT-ESG01> get logging-servers
Mon Dec 28 2020 UTC 17:37:16.600
192.168.10.8:514 proto udp level info
Если вы когда-нибудь изучали вопрос, почему дискета в 1.44 МБ дает на самом деле 1.38 МБ дискового пространства, то знаете, что это происходит потому, что мегабайт производителей дискет равен 1024х1000 байт. Поэтому дискета на «1,44 Мб» на самом деле имеет ёмкость в 1,44х1024х1000 байт = 1440 Кб или 1.38 Мб (где 1 Мб = 1024х1024 байт). Подробнее об этом вы можете прочитать вот тут.
"Неправильные" килобайты и мегабайты используют префиксы системы СИ (кило, мега, гига), что сложилось исторически, но неверно по сути. "Правильные" (бинарные) килобайты, мегабайты и гигабайты называются кибибайтами, мебибайтами и гибибайтами, соответственно - эти префиксы определены стандартом IEC. При написании они выглядят как KiB, MiB, GiB, TiB и т.д.
Из-за путаницы (или сознательного преуменьшения) производителей систем хранения данных и операционных систем на сегодняшний день иногда трудно понять, какой объем дискового пространства доступен в байтах и не является ли 1 ТБ емкости на самом деле 931 гигабайтом. Например, Microsoft по-прежнему использует систему СИ для отображения мегабайтов/гигабайтов.
VMware приступила к прояснению этого вопроса, начав со своей облачной инфраструктуры VMware Cloud on AWS. Теперь для отображения доступной емкости в консоли используется бинарная нотация IEC:
В данном случае емкость равно 20.74 тебибайта, что в байтах равняется:
Это не изменяли в vCenter, чтобы не вводить пользователей в заблуждение - ведь гостевые ОС отображают данные о емкости в системе СИ. Но имейте в виду, что из-за этого вы можете видеть разные емкости внутри и снаружи ОС при отображении общего и свободного пространства.
Еще в 2015 году мы писали о документе "VMware NSX for vSphere Network Virtualization Design Guide", в котором был рассмотрен референсный дизайн инфраструктуры виртуализации сетей в виртуальном датацентре и описывалась архитектура решения NSX на физическом и логическом уровнях. Тогда этот документ занимал 160 страниц.
С тех пор много всего поменялось (решение NSX разделилось на NSX-T и NSX-V), функциональность продуктов для виртуализации сетей существенно расширилась, поэтому выпущенный недавно компанией VMware новый документ "VMware NSX-T Reference Design Guide" теперь занимает 300 страниц! Доступен он абсолютно бесплатно и, по-сути, представляет собой книгу о продукте NSX-T:
Основные корневые разделы документа:
NSX-T Architecture Components
NSX-T Logical Switching
NSX-T Logical Routing
NSX-T Security
NSX-T Load Balancer
NSX-T Design Considerations
NSX-T Performance & Optimization
Если вы администратор решения VMware NSX на большом предприятии, то это самая лучшая книга, чтобы почитать на новогодние праздники:)
Скачать VMware NSX-T Reference Design Guide можно по этой ссылке.
Первый момент - это то, что вам не потребуется Storage Replication Adapter (SRA), чтобы использовать репликацию на уровне дискового массива. Тома VVols изначально поддерживают управление хранилищами и их репликацией за счет механизма Storage Policy-Based Management (SPBM). Когда вы настраиваете репликацию VVols, она устанавливается не на уровне LUN, а на уровне виртуальных машин.
Все это упрощает управление репликацией виртуальных машин (нет необходимости настройки и обслуживания SRA), а также повышает гранулярность управления за счет оперирования на уровне отдельных виртуальных машин, а не всего LUN в рамках настройки SRM Protection Groups:
Второй важный момент - это то, что поскольку репликация VVols происходит на уровне виртуальных машин и их хранилищ, то ввиду меньшей гранулярности ВМ можно параллельно реплицировать на разные хранилища в соответствии с политиками SPBM, но при этом с разной периодичностью в зависимости от места назначения и их Protection Groups:
В традиционной инфраструктуре хранилищ, когда вы делаете тест восстановления хранилищ в SRM, то он должен выполняться для целой Protection Group, что рождает определенные сложности и условия при подготовке к тестированию. Для томов VVols все происходит гораздо проще, с учетом разной частоты репликации для виртуальных машин и большей гранулярности тестирования. Также это дает возможности простого восстановления отдельной ВМ в случае сбоя.
Между тем есть некоторые ограничения использования томов VVols и SRM:
SRM не поддерживает защиту виртуальных машин, которые имеют нереплицируемые виртуальные диски.
SRM не поддерживает защиту виртуальных машин с разными дисками на базе VVols, которые имеют разные политики хранилищ с точки зрения репликации и разные replication groups.
vVols не поддерживают восстановление шаблонов виртуальных машин (templates).
VVols поддерживает применение разных политик SPBM к дискам виртуальной машины, но чтобы эта ВМ поддерживалась со стороны SRM, нужно, чтобы все ее диски были настроены на базе одной политики:
Тома vVols 2 с поддержкой репликации уже поддерживаются на стороне хранилищ Dell EMC (PowerMax), HPE и Pure Storage. Также в ближайшем будущем ожидается существенное расширение этого списка.
Более подробную информацию вы можете получить по следующим ссылкам:
Многие администраторы платформы для сетевой защиты приложений в контейнерах, виртуальных машин и невиртуализованных нагрузок VMware NSX-T часто сталкиваются с проблемами, связанными с политиками устаревания паролей (password expiration policies), которые заставляют менять пароль локальных аккаунтов к консоли системы:
По умолчанию администратор должен менять пароль каждые 90 дней. Чтобы узнать о текущей политике паролей и сроке действия текущего пароля, надо выполнить следующую команду:
> get user admin password-expiration
Wed Dec 23 2020 UTC 16:38:51.380
Password expires 90 days after last change. Current password will expire in 90 days.
Чтобы изменить число дней, по прошествии которого пароль устаревает, надо выполнить эту команду:
> set user admin password-expiration 10
Ну и чтобы вовсе отключить устаревание пароля, надо выполнить следующее:
> clear user admin password-expiration
После этого нужно проверить, что политика отключена:
> get user admin password-expiration
Wed Dec 23 2020 UTC 16:44:56.671
Password expiration not configured for this user
Многие администраторы виртуальной инфраструктуры VMware vSphere при планировании апгрейда не выясняют важных моментов, касающихся совместимости продуктов и так называемых upgrade paths, то есть поддерживаемых производителем рабочих процессов обновления платформы. В этой статье мы расскажем о том, что нужно выяснить перед апгрейдом...
Большинство администраторов, которым требуется управление виртуальной инфраструктурой VMware vSphere с помощью сценариев используют интерфейс VMware PowerCLI, который является оберткой движка PowerShell. Это требует наличие отдельного хоста, с которого идет исполнение сценариев, а также часто требуются такие сервисы, как vRealize Orchestrator и vRealize Automation.
Поэтому, начиная с VMware vSphere 6.7, появился новый Open Source интерфейс для управления виртуальной средой - Script Runtime Service (SRS). Он представляет собой Kubernetes-приложение для управления инстансами PowerCLI и вызова командлетов через REST API.
Интерфейс SRS позволит интегрировать управление исполнением сценариев PowerCLI в vSphere Client для виртуальных машин и приложений.
SRS создает отдельное пространство имен в кластере Kubernetes, которое позволяет PowerCLI работать как Kubernetes pod. Этот легковесный PowerCLI pod реализуется как образ контейнера, который имеет все модули PowerCLI и требует только необходимые управляющие компоненты, трансформирующие ввод и вывод для сценариев, а также управляющие исполнением запрошенного сценария.
Первоначальная инсталляция SRS запускает задачу Kubernetes, которая регистрирует SRS в сервисах провайдера идентификации vSphere SSO. Единожды аутентифицированные клиенты SRS API автоматически включаются в список доверенных на серверах vCenter.
Надо отметить, что сейчас SRS находится еще в ранней стадии разработки и не работает с vSphere with Tanzu (поэтому не развертывайте его со службами Supervisor Cluster).
Попробовать работу с движком SRS можно двумя путями:
1. Устанавливаете SRS в кластере Kubernetes на любую из машин (инструкции здесь)
2. Устанавливаете SRS на специальным образом подготовленную виртуальную машину на базе Photon OS (инструкции тут).
Начать экспериментировать с SRS API можно, перейдя по ссылке:
https://{SRS-IP}/swagger/index.html
SRS использует механизм vCenter Server SSO для идентификации и аутентификации. У любого пользователя с доступом через SSO есть возможность настроить PowerCLI-соединения к серверам vCenter Servers. Как начать это делать описано вот тут.
SRS работает с vSphere 6.7 и более поздними версиями. Сообщить о проблемах вы можете вот тут, а также присодинившись к VMware Code и каналу в Slack.
Вчера мы писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1c, где главным нововведением стала интеграция функций миграции Advanced Cross vCenter Server vMotion Capability (ранее это был виртуальный модуль Cross vCenter Workload Migration Utility) в интерфейс vSphere Client. Оно же называется XVM.
Эта функциональность используется для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). При этом не требуется настроенного механизма Enhanced Linked Mode (ELM) или Hybrid Linked Mode (HLM) для серверов vCenter в разных датацентрах.
Один из главных сценариев такой миграции - это горячий перенос виртуальной машины из онпремизной инфраструктуры VMware vSphere в облачную среду VMC on AWS.
Для подобного рода миграций vMotion теперь есть 2 рабочих процесса: миграция ВМ на другой vCenter, а также импорт с целевого vCenter виртуальной машины источника:
Для функциональности XVM поддерживается и режим пакетной миграции, для которого вы можете указать несколько виртуальных машин, выбрать пункт Migrate и начать их одновременный перенос (пункт Cross vCenter Server export):
При миграции можно выбрать новый vCenter или один из уже сохраненных, что очень удобно при миграции групп ВМ в несколько заходов. К сожалению, Saved vCenters сохраняются только в рамках одной пользовательской сессии:
Дальше мастер будет похож на аналогичный в обычном vMotion, где будут выполняться стандартные предпроверки:
Как и при обычном vMotion, вы можете сменить хранилище виртуальной машины, а также ее сеть, чтобы она соответствовала инфраструктуре назначения. Затем начнется стандартная задача миграции:
На целевом vCenter тоже будет отображаться задача по приему vMotion от источника:
На целевом vCenter можно также самостоятельно инициировать прием миграции, выбрав пункт Import VMs из контекстного меню кластера:
Чтобы провести такую миграцию, также надо подключить исходный vCenter:
При успешном подключении вы сможете выбрать виртуальные машины, которые требуется перенести в другой датацентр:
Таким образом, эта функциональность может быть использована для следующих случаев:
Миграция онпремизных ВМ в облачный датацентр VMC on AWS без необходимости настройки Hybrid Linked Mode (HLM)
Переход на новую версию платформы vSphere путем переноса рабочих нагрузок со старых серверов
Миграция ВМ в рамках обновления инфраструктуры VMware Cloud Foundation (VCF)
Консолидация датацентров или перераспределение их содержимого
Вывод из эксплуатации старого оборудования со старыми версиями vSphere
Глобальная перебалансировка виртуальных машин между окружениями VCF
Миграция инфраструктуры на одно из публичных облаков VMware Cloud
На днях компания VMware выпустила обновление VMware vSphere 7 Update 1c, в котором появилось довольно много всего нового для минорного апдейта.
Давайте посмотрим, что именно:
Статистики по физическим сетевым адаптерам - добавилось 5 новых параметров (dropRx, dropTx, errorsRx, RxCRCErrors и errorsTx), которые позволяют вам обнаружить сетевые ошибки и предпринять действия по исправлению ситуации.
Параллельное обновление хостов в кластерах, которые находятся под управлением vSphere Lifecycle Manager. Теперь хосты ESXi под управлением vLCM можно одновременно перевести в режим обслуживания и начать их обновление.
Advanced Cross vCenter vMotion - это функциональность виртуального модуля Cross vCenter Workload Migration Utility, который был предназначен для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). Теперь эта штука интегрирована в vSphere Client, где удобно работать с миграциями ВМ между датацентрами (поддерживается и пакетная миграция нескольких ВМ):
Можно подключать сторонние плагины для управления сервисами на платформе vSAN Data Persistence из vSphere Client таким же способом, как вы управляете сервером vCenter.
Улучшения vSAN DOM scrubber (проверка блоков, к которым давно не было обращений).
Улучшения Supervisor Cluster:
Изоляция пространств имен (Supervisor Namespace Isolation) за счет выделенного маршрутизатора T1 Router (кластеры в сети NSX-T используют для этого новую топологию).
Поддержка NSX-T 3.1 для Supervisor Clusters
Удалена поддержка Supervisor Cluster версий 1.16.x.
Улучшения служб Tanzu Kubernetes Grid for vSphere:
Поддержка HTTP/HTTPS Proxy – вновь созданные кластеры Tanzu Kubernetes могут использовать глобальные прокси HTTP/HTTPS для исходящего трафика, а также скачивать образы контейнеров из интернет-репозиториев.
Вновь созданные кластеры Tanzu Kubernetes из коробки интегрированы со службой vSphere Registry Service. Также с этой службой будут интегрированы кластеры, обновленные до новой версии.
Кластеры Tanzu Kubernetes теперь могут монтировать дополнительные тома к виртуальным машинам, что позволяет увеличивать дисковую емкость узлов. Это дает возможность пользователям развертывать большие образы контейнеров, которые больше дефолтного размера в 16 ГБ.
Скачать VMware vSphere 7 Update 1c можно по этой ссылке. Release Notes доступны тут.
Не так давно мы писали о технологии vSphere Clustering Service (vCLS), которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Делается это за счет того, что на хостах есть агентские виртуальные машины служб vCLS.
Дункан Эппинг описал ситуацию, когда эти виртуальные машины просто не включаются с ошибкой в консоли vSphere Cleint:
Insufficient resources
Если посмотреть в детали сообщения об ошибке, то там будет примерно следующее:
The target host does not support the virtual machine's current hardware requirements.
Также может быть показано следующее сообщение:
Feature 'MWAIT' was absent, but must be present.
Выходов из этой ситуации может быть два - так как они могут быть обусловлены разными причинами. Причем первый вариант - это официально поддерживаемый со стороны VMware путь устранения проблемы для кластера в целом, а второй - "народный способ" для отдельных ВМ.
Вариант 1:
Для устранения ошибки про Feature 'MWAIT' нужно убедиться, что опция Monitor/MWAIT включена в BIOS (Enabled). vCLS включает EVC на базе виртуальных машин для каждой ВМ. Если же это не помогло или вы не можете это сделать, то нужно использовать метод, описанный ниже.
Вариант 2:
Апгрейдим ВМ в плане "Compatibility" до последней версии виртуального железа “VM version 14” (меню апгрейда есть по правой кнопке в vSphere Client).
Выбираем нужную ВМ, переходим на вкладку Configure и идем в VMware EVC.
Нажимаем "Edit" и выбираем “Yes” для подтверждения изменения настроек
На днях компания VMware выпустила обновление своего пакета vRealize Operations Management Pack for Kubernetes 1.5.1, которое позволяет отслеживать состояние контейнерных сред Kubernetes из консоли Operations. Напомним, что ранее оно называлось Management Pack for Container Monitoring.
Надо отметить, что vRealize Operations с помощью данного пакета может обеспечивать мониторинг как сред Tanzu Kubernetes в публичном или онпремизном облаке, так и инфраструктуры OpenStack с развернутыми кластерами Kubernetes.
Давайте посмотрим, что появилось нового в MP for Kubernetes 1.5.1:
1. Поддержка vRealize Operations Advanced
Теперь пользователи издания Advanced также могут использовать пакет управления, ранее эта возможность была доступна только владельцам лицензий Enterprise. Для vRealize Operations Cloud поддержка также сохранилась.
2. Улучшенный сбор метрик средствами Prometheus
Многие пользователи сред Kubernetes используют Prometheus для сбора метрик в кластерах. Теперь vRealize Operations за счет MP может запрашивать метрики с сервера Prometheus, а данные об инфраструктуре получать напрямую через Kubelet API.
Такая интеграция по-прежнему позволит вам использовать механизмы интеллектуального анализа данных, в том числе Troubleshooting Workbench и Metric Correlation.
Prometheus хранит данные в отличном от vRealize Operations формате. Чтобы преобразовать и получить данные для метрик Prometheus можно использовать следующих экспортеров (exporters):
Если ваша команда разработки дорабатывает какие-то метрики в экспортерах, то они автоматически становятся доступны в vRealize Operations.
vRealize Operations также собирает метки (labels) с серверов Prometheus. Они могут включать важные данные, такие как IP-адреса узлов, имена приложений или процессов, номера версий или даже, например, какие метрики используются для конкретного ядра CPU:
Для игнорирования ненужных метрик (например, GUID) можно использовать фильтры:
3. Мониторинг приложений в Kubernetes
Теперь интеграция vRealize Operations и Prometheus позволяет более глубоко взглянуть на уровень приложений:
В данном примере показано приложение Redis, для которого используется экспортер Telegraf. Для него vRealize Operations может видеть такие метрики как: число клиентов, как много времени CPU требуется на выполнение вызовов, информацию о памяти и application backlogs.
4. Поддержка новых Tanzu Mission Control API
Теперь vRealize Operations и MP могут не только автоматически мониторить облачные среды Tanzu Mission Control на платформе AWS, но и полностью поддерживают обновленный API. Также недавно было анонсировано, что Tanzu Mission Control будет поддерживать Tanzu Kubernetes Grid on vSphere 7, и вскоре эта поддержка будет добавлена и в Management Pack.
Скачать VMware vRealize Operations Management Pack for Kubernetes 1.5.1 можно по этой ссылке. Документация находится здесь.
Вот список продуктов и их версий, которые затронет отсутствие поддержки Flash со стороны браузеров:
Продукт
На что нужно обновляться
vSphere 6.7 GA или старее
6.7 Update 3 или новее
Horizon 7.8 или старее
7.10 или новее
vCloud Director 10 или старее
10.1 или новее
NSX for vSphere 6.4.7 или старее
6.4.8 или новее
Site Recovery Manager 6.5 или старее
8.1 или новее
vSAN 6.5 или старее
6.7 Update 3 или новее
vRealize Orchestrator 7.5 или старее
7.6 или новее
vRealize Automation 7.6 или старее
8.0 или новее
vRealize Operations 6.5 или старее
6.6 или новее
В июне этого года, в связи с большим числом заявок от крупных компаний, было решено сделать Workaround для Flash Player. Чтобы включить его для отдельных URL, нужно внести изменения в файл mms.cfg, где следует добавить следующие строчки:
На сайте проекта VMware Labs появилось обновление утилиты VMware Event Broker Appliance (VEBA) v0.5. Напомним, что это решение, которое позволяет пользователям создавать сценарии автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That". О версии VEBA 0.3, вышедшей весной этого года, мы писали вот тут.
Давайте посмотрим, что нового появилось в продукте, начиная с версии 0.3 и вплоть до вышедшей на днях версии 0.5:
Новый интерфейс VEBA Direct Console UI (DCUI)
Новые примеры функций Incident Management
Новый пример функции на Golang
Возможность развертывания VEBA в существующем кластере Kubernetes (см. тут)
Обновление базовой ОС на последний релиз Photon OS 3.0 Rev2
Сетевой провайдер (CNI) контейнеров Weave заменен на Antrea
Поддержка кастомизации Docker bridge network (default: 172.17.0.1/16) через свойство OVF-шаблона
Возможность мониторинга виртуального модуля VEBA через vRealize Operations (см. тут)
Какое-то время назад мы писали о полезном документе "Product Lifecycle Matrix", в котором приведены основные моменты касающиеся жизненного цикла продуктов VMware: дата доступности продукта для загрузки, окончание поддержки, завершение технического сопровождения и дата снятия с продаж.
Наш читатель Ser указал на интересный ресурс - это онлайн-тул Product Lifecycle Matrix, который выводит актуальную информацию из указанного документа в возможностью сортировки и фильтрации по нужным колонкам:
Удобно, что в таблице можно не только искать нужный продукт (кстати, не ищите vSphere, потому что там продукты разделяются на ESXi и vCenter), но и экспортировать полученный табличный вид в PDF или CSV, а также вывести его на печать.
Красным отмечены даты у продуктов, для которых поддержка или техническое сопровождение заканчивается в ближайшие 6 месяцев, а фиолетовым - те, у которых поддержка уже закончилась. Обратите внимание, что также есть отдельная вкладка для неподдерживаемых и устаревших продуктов.
Компания VMware запустила новый ресурс core.vmware.com, посвященный технической информации для администраторов инфраструктуры VMware vSphere, решений vSAN, Horizon, vRealize и других платформ.
На новый портал переехал контент с ресурсов Storage Hub и vSphere Central, который был актуализован и теперь будет регулярно пополняться технической информацией в виде документов и видео.
Документов будет много, но основной упор будет делаться на продукты vSphere, vSAN и Cloud Foundation.
Кстати, раз уж речь зашла о документации, расскажем, что VMware потихоньку начинает добавлять техническую документацию по продуктам на русском языке на сайт VMware Docs (мы писали об этом тут). Смотрите, например, что уже есть по vRealize Automation:
В прошлом году мы писали о полезной утилите VMware Configuration Maximums Tool, которая позволяет выводить максимальные конфигурации для различных продуктов VMware. Эта очень полезная штука для администраторов vSphere умеет не только выводить список всех максимумов, но и сравнивать их для разных версий одного продукта.
Для этого нужно выбрать пункт меню "Compare Limits" и указать сравниваемые версии продуктов:
Штука эта очень удобная, но у нее есть большой недостаток - она выводит все конфигурации максимумов (для NSX-T, например, их 274 штуки, поэтому сложно отследить, что именно изменилось).
Поэтому Dale Coghlan написал интересный PowerCLI-модуль VMware.CfgMax, который решает эту проблему - в режиме командной строки можно узнать об изменениях максимумов, а также сделать еще несколько полезных вещей.
После установки модуля можно вывести список доступных продуктов, которые есть на configmax.vmware.com:
Для конкретного продукта можно вывести список его версий/релизов:
Также для конкретной версии можно вывести список категорий максимумов:
С помощью командлета можно вывести все максимумы для конкретного продукта и определенной его версии:
Можно вывести все конфигурации в рамках заданной категории:
Ну и, наконец, с помощью командлета Compare-CfgMaxLimits можно сравнить максимумы конфигураций для разных версий одного продукта:
Как вы видите, тут есть поле CompareStatus, которое и говорит нам, новая ли эта настройка (New), измененная по сравнению с прошлым релизом (Modified), нетронутая (пусто) или удаленная (Deleted) в новой версии.
С помощью параметра New можно, например, вывести все новые настройки:
Параметр Modified выведет только отличающиеся максимумы конфигураций:
Ну а параметр Deleted выведет устаревшие настройки:
Ну и все вместе, без неизмененных значений:
Очень удобная штука, все это также можно экспортировать в формат CSV и сравнивать в Excel. Для этого можно использовать следующую команду:
PS > $product = Get-CfgMaxProduct -Name 'NSX-T Data Center'
PS > $releaseA = $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.0.0'
PS > $releaseB = $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.1.0'
PS > Compare-CfgMaxLimits -Product $product -Release $releaseA -CompareRelease $releaseB | Export-Csv -Path compare-status.csv -NoTypeInformation
Скачать данный PowerCLI сценарий с примерами вы можете по этой ссылке.
На днях компания VMware рассказала об основных моментах новой модели лицензирования, которая появилась в продуктовой линейке VMware Horizon. Главным нововведением стал переход на подписочную модель на продукты, чтобы соответствовать тенденции по переходу пользователей на удаленный режим работы в связи с пандемией.
Переход на новую subscription-based схему начался уже сейчас и завершится к 6 мая 2021 года, когда обычные лицензии Horizon перестанут существовать.
По заверениям VMware это даст пользователям следующие преимущества:
Единую среду для управления лицензиями онпремизных инсталляций и облачных пользовательских сред - все это будет делаться через Horizon Control Plane.
Облачные сервисы могут применяться к онпремизным десктопам, расширяя их функциональность. Если же пользователям нужны только онпремизные инфраструктуры - то и там можно будет использовать десктопы на базе подписки.
Администраторы смогут разворачивать новые десктопы в облаке без капитальных затрат, а также создавать их в целях HA/DR. Это позволит гибко подходить к вопросу отказо- и катастрофоустойчивости, добавляя или удаляя резервные системы по мере надобности.
Возможность перехода между тарифами. Теперь пользователи смогут использовать гибкую систему ценообразования и апгрейдов, чтобы постепенно стремиться к получению оптимальной конфигурации.
Инструменты для получения единой среды EUC (End User Computing) для всех пользователей на любых устройствах с помощью облачного решения Workspace ONE, интегрированного с VMware Horizon.
В ближайшее время ожидаем документ с подробным описанием новой схемы лицензирования VMware Horizon на базе подписки.
Компания VMware на днях выпустила обновление продукта Cloud Director Availability 4.1, предназначенного для создания резервной инфраструктуры в одном из публичных облаков сервис-провайдеров на основе VMware vCloud Director (так называемая услуга Disaster-Recovery-as-a-Service, DRaaS).
Нововведения сфокусированы в трех основных областях - улучшенная совместимость с другими компонентами, новые возможности в плане контроля инфраструктуры и новые функции для архитектур на базе одной или нескольких площадок:
Давайте посмотрим на основные новые возможности Cloud Director Availability 4.1:
1. Новые e-mail оповещения для клиентов
Основные улучшения в этой области рассмотрены в видео выше. Вместо того чтобы логиниться в интерфейс, пользователи могут получать оповещения по почте, имея при этом высокую степень кастомизации для них со стороны провайдера:
Провайдер может контролировать, к каким событиям может иметь доступ клиент.
2. Поддержка шифрования Cloud-to-Cloud
Теперь возможности шифрования виртуальных дисков машин поддерживаются и в распределенных сценариях, когда нужно переместить зашифрованную на базе политик виртуальную машину между площадками с включенным шифрованием, где используется один KMS-сервер.
3. Поддержка аутентификации на нескольких площадках с использованием собственного провайдера
Теперь клиенты могут использовать единую аутентификацию с использованием собственного провайдера identity provider (SSO/LDAP/SAML), что позволяет не вводить логин-пароль при соединении с разными площадками.
4. Упрощенный мастер начальной конфигурации
Здесь было сделано множество улучшений в плане упрощения процесса первой настройки решения - например, можно сохранить логин-пароль для соединения с различными виртуальными модулями, которые участвуют в конфигурации.
5. Улучшенные нотификации для провайдеров
Теперь нотификации вынесены в отдельный раздел, могут рассылаться по электронной почте, а провайдер может управлять нотификациями клиентов.
6. Разделение операций Migrations и Protections
Теперь управление для Migrations и Protections полностью разделено и доступно на базе независимых контролов:
7. Резервное копирование и восстановление виртуальных модулей Cloud Director Availability 4.1
Теперь Virtual Appliances, входящие в состав Cloud Director Availability 4.1, можно бэкапить, а также восстанавливать с случае сбоев производственных систем. Важно, что восстановление, как и бэкап, делается в несколько кликов.
Если у вас версия Cloud Director Availability 4.0 то до 4.1 можно обновиться сразу, а вот с версии 3.5 придется обновляться через 4.0. Более подробная информация о продукте приведена здесь.
Недавно компания VMware залила на GitHub актуальную версию графики для составления схем и диаграмм в Microsoft Visio и OmniGraffle - VMware Stencils. Иконки и графика доступны еще и в формате Microsoft PowerPoint, а также в векторном формате SVG.
Напомним, что в прошлый раз о стенсилах VMware Stencils мы писали год назад вот тут, а в то время не было версии для OmniGraffl под Mac OS.
На днях на сайте проекта VMware Labs появилось очередное интересное обновление - новая версия гипервизора VMware ESXi Arm Edition 1.2 для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства).
Напомним, что о версии ESXi Arm Edition 1.1 мы писали вот тут, а здесь также рассказывали об установке этого гипервизора на платформу Raspberry Pi.
Давайте посмотрим, что нового в VMware ESXi Arm Edition 1.2:
Если у хоста нет датасторов, то datastore browsing отключен
Пофикшен отсутствующий параметр context_id для вызовов CPU_ON
Исправлена проблема с контроллером GICv2 (теперь SGI всегда включены и работают как устройства GIC-500)
Поддержка гостевых ОС на базе big-endian
Убраны требования/ограничения на initrd для ВМ без UEFI
В целом, все это технические фиксы - но обновить вашу тестовую лабу не помешает. Новая версия ESXi Arm встает только как свежая установка, обновление прошлых версий не поддерживается. Можно сохранить прошлые тома VMFS, выбрав опцию "Preserve VMFS", но машины надо будет перерегистрировать заново.
Скачать ESXi Arm Edition 1.2 можно по этой ссылке.
RSS
