Коллеги из Veeam поделились интересной новостью. Во-первых, и это очевидно, что глобальная конференция VeeamON 2020 не будет проводиться в Америке физически, а пройдет онлайн, как и все остальные подобные события. И, во-вторых, что самое приятное - она будет полностью бесплатна для всех.
Дата проведения: 17-18 июня 2020 года. Регистрация по этой ссылке.
Ежегодная конференция VeeamON - одно из крупнейших мероприятий ИТ-отрасли. На VeeamON соберутся ведущие ИТ-эксперты и альянс-партнеры Veeam, такие как VMware, NetApp, Hewlett Packard Enterprise и многие другие.
В рамках двухдневного онлайн-мероприятия компания Veeam расскажет о новой стратегии компании (напомним, она была продана фонду Insight Partners в этом году за 5 миллиардов долларов), покажет все свои самые новые продукты в сфере защиты данных и обеспечения виртуальных датацентров, а также раскроет множество технических деталей, интересных администраторам платформ виртуализации VMware vSphere и Microsoft Hyper-V.
Список главных спикеров конференции:
William H. Largent - CEO and Chairman of the Board, Veeam Software
Danny Allan - CTO and Senior Vice President, Product Strategy, Veeam Software
Jim Kruger - Chief Marketing Officer, Veeam Software
Anton Gostev - Senior Vice President, Product Management, Veeam Software
Специальный гость - Tripp Crosby,
Entertainer & Comedian.
Ну а для тех, кому хочется послушать о самых актуальных новостях Veeam этого года на русском языке, пройдет также бесплатная онлайн-конференция VeeamON Tour 2020.
Дата проведения: 25 июня 2020 года.
Программа конференции:
11:00 Вступительное слово. Василий Ваганов, Вице-президент, Северная и Восточная Европа, Ближний Восток, Россия и СНГ
11:05 Veeam в 2020: Новости и прогнозы. Владимир Клявин, Региональный Директор, Россия и СНГ, Veeam Software
11:25 Пленарная сессия — Технологии. Виталий Савченко, руководитель группы системных инженеров Veeam по России, СНГ, Грузии, Украине и Монголии, Veeam Software
11:45 Технические сессии:
Лучшие практики и рекомендации для успешной работы с Veeam Agents - Сергей Пискунов, технический консультант Veeam Software
Реализация Veeam NAS Backup в версии 10 - Виталий Савченко, руководитель группы системных инженеров Veeam по России, СНГ, Грузии, Украине и Монголии, Veeam Software
12:05 Перерыв
12:20 Технические сессии:
Практические рекомендации по защите данных от программ вымогателей - Павел Косарев, технический консультант Veeam Software
Все об интеграции с СХД и новые возможности Veeam v10 - Роман Прытков, технический консультант Veeam Software
12:40 Технические сессии:
Рекомендации по планированию инфраструктуры Veeam Backup & Replication v10 - Евгений Зосимов, технический консультант Veeam Software
Как вы знаете, обновлением виртуальной инфраструктуры в VMware vSphere 7 вместо Update Manager теперь занимается комплексное средство vSphere Lifecycle Manager (vLCM). vLCM можно использовать для применения установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений.
Одной из возможностей этого средства является функция проверок на совместимость (Compatibility Checks). Они нужны, например, в случаях, когда вы настроили интеграцию Hardware Support Manager (HSM) для серверов Dell или HP и хотите проверить оборудование развертываемого сервера на совместимость с ESXi. Это так называемые Hardware Compatibility Checks.
Во время проверок можно использовать кастомный образ ESXi с дополнениями Firmware и Drivers Addon для проверки образов от поддерживаемых вендоров на совместимость с имеющимся у вас оборудованием и установленной версией микрокода. Вот так в vLCM выглядит проверка соответствия для образов ESXi:
На этом скриншоте видно, что текущий уровень компонентов хоста ESXi не соответствует желаемым параметрам в плане версий Firmware аппаратных компонентов. В этом случае есть опция Remediate (кнопка вверху слева), которая позволяет привести хосты ESXi в соответствие, обновив микрокод аппаратных компонентов средствами Hardware Support Manager - и все это прямо из клиента vSphere Client, без сторонних консолей.
vLCM предоставляет также функции автоматической проверки (HCL Automatic Checks), с помощью которых можно автоматически и систематически искать несоответствия уровня firmware на хостах ESXi и сверять их с актуальной онлайн-базой VMware Compatibility Guide (VCG, он же Hardware Compatibility Guide - HCL).
Если вы зайдете в раздел Cluster > Updates, то увидите результат работы автоматического тестирования на совместимость с необходимыми деталями. Пока это доступно только для контроллеров хранилищ vSAN (storage controllers), что является критически важной точкой виртуальной инфраструктуры с точки зрения обновлений (стабильность, производительность).
На скриншоте ниже показаны результаты проверки совместимости в кластере для адаптера Dell HBA330. В данном случае видно, что на всех хостах установлена одинаковая и последняя версия firmware, что и является правильной конфигурацией:
По ссылке "View in HCL" вы сможете увидеть, что данный адаптер с данной версией микрокода действительно поддерживается со стороны VMware vSphere и vSAN.
Если вы на своем Mac решили установить VMware ESXi 7 в виртуальной машине на флешке, то с настройками по умолчанию этого сделать не получится - USB-устройство не обнаружится установщиком и не будет видно в разделе настроек USB & Bluetooth виртуальной машины.
Eric Sloof написал, что перед развертыванием ESXi, чтобы установщик увидел USB-диск, нужно перевести USB Compatibility в режим совместимости с USB 3.0:
После этого можно будет выбрать ваш USB-диск для установки ESXi 7.0:
Как вы все знаете, недавно компания VMware сделала доступной для загрузки платформу VMware vSphere 7, где службы управляющего сервера vCenter доступны уже только в формате виртуального модуля vCenter Server Appliance (vCSA).
Блоггер Ozan Orcunus написал интересную заметку о том, как можно отключить автозагрузку некоторых сервисов в vCenter 7. Не секрет, что с каждой новой версией vCenter становится все более и более прожорливым в отношении системных ресурсов. Например, для 10 хостов ESXi и 100 виртуальных машин теперь уже требуется сделать vCSA с двумя vCPU и 12 ГБ оперативной памяти, что слишком много для тестовых окружений, например, на ноутбуке.
Поэтому чтобы vCSA работал немного побыстрее в тестовых средах (и только там, в продакшене этого делать не рекомендуется) можно отключить некоторые его службы при загрузке. В KB 2109881 написано, как останавливать и запускать службы vCenter с помощью команды service-control, но нигде официально не написано о том, как отключать их при старте vCenter.
А делается это следующим образом:
1. Логинимся по SSH на сервер vCSA и переходим в каталог /etc/vmware/vmware-vmon/svcCfgfiles/.
2. Большинство сервисов vCenter - это не стандартные сервисы systemd, а службы спрятанные за за сервисом VMware Service Lifecycle Manager (vmware-vmon). Наберите "systemctl status vmware-vmon" и посмотрите на результат:
Конфигурация сервисов спрятана в JSON-файлах - в директориях, которые можно увидеть в выводе команды. Например, чтобы отключить службу Content Library, нужно открыть файл конфигурации командой:
vi vdcs.json
И выставить в нем параметр StartupType как DISABLED.
3. После внесения всех необходимых изменений нужно перезагрузить vCSA для применения настроек автозапуска.
4. После этого идем в раздел Services и видим, что автозапуск некоторых служб vCenter отключен:
В начале апреля компания VMware обновила свой основной фреймворк для управления виртуальной инфраструктурой с помощью командных сценариев PowerShell до версии PowerCLI 12.0. Напомним, что прошлая версия PowerCLI 11.5 вышла осенью прошлого года.
Давайте посмотрим, что нового появилось в двенадцатой версии фреймворка:
Добавлены командлеты для управления хостовой сетью ESXi
Еще в vSphere 6.0 появилась поддержка сетевых стеков хостов ESXi. Она позволяет назначить различные шлюзы для адаптеров VMkernel в целях маршрутизации трафика. Через PowerCLI можно использовать ESXCLI или API для управления этой функциональностью с помощью командлетов Get-VMHostNetworkStack и Set-VMHostNetworkStack. Новый параметр называется "NetworkStack", он был добавлен в командлет New-VMHostNetworkAdapter:
Добавлены командлеты для управления решением HCX
Появились новые командлеты для управления пространствами имен
Командлеты для управления службами Trusted Host Services
Командлеты для управления диском гостевой ОС виртуальных машин (VM Guest Disk management)
Теперь раздел гостевой ОС можно замапить на VMDK-диск (пока только для Windows-систем). Для этого потребуется vSphere 7 и VMware Tools не ниже 11-й версии. Эту возможность можно использовать с помощью командлета Get-VMGuestDisk:
Новые командлеты для управления VMware Cloud on AWS
Новые командлеты для vSAN:
Get-VsanFileServiceDomain
New-VsanFileServiceDomain
Set-VsanFileServiceDomain
Remove-VsanFileServiceDomain
New-VsanFileServiceIpConfig
Get-VsanFileShare
New-VsanFileShare
Set-VsanFileShare
Remove-VsanFileShare
New-VsanFileShareNetworkPermission
Add-VsanFileServiceOvf
Get-VsanFileServiceOvfInfo
Новый модуль для управления службами VMware Cloud Services
Добавлена поддержка vSphere 7.0
Добавлена поддержка vRealize Operations 8.0
Обновлена поддержка модулей License и vROps, а также командлета Open-VMConsoleWindow для использования на различных платформах
Поддержка Move-VM для сетей opaque networks
Добавлена поддержка последних обновлений PowerShell 7.0:
Скачать VMware PowerCLI 12.0 можно по этой ссылке. Полезные ресурсы:
Многие из вас знакомы с решением VMware App Volumes, которое предназначено для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам. Те из вас, кто его используют, время от времени, наверняка, сталкиваются с проблемой недостатка места на пользовательских томах Writable Volumes, которые забиваются неизвестно чем:
Напомним, что Writable Volumes - это персонализированные тома, которые принадлежат пользователям. Они хранят настройки приложений, лицензионную информацию, файлы конфигураций приложений и сами приложения, которые пользователь установил самостоятельно. Один такой диск может быть назначен только одному десктопу, но его можно перемещать между десктопами. Соответственно, такие тома могут легко заполняться, и пользователи начинают жаловаться.
Aresh Sarkari написал полезный скрипт, который выявляет заполненные тома Writable Volumes в инфраструктуре App Volumes (меньше 3 ГБ свободного места), формирует CSV-файл с данными о них и посылает его по электронной почте администратору:
####################################################################
# Get List of Writable Volumes from AppVolumes Manager for free space less than 3 GB out of 30 GB
# Author - Aresh Sarkari (@askaresh)
# Version - V2.0
####################################################################
# Run at the start of each script to import the credentials
$Credentials = IMPORT-CLIXML "C:\Scripts\Secure-Creds\SCred_avmgr.xml"
$RESTAPIUser = $Credentials.UserName
$RESTAPIPassword = $Credentials.GetNetworkCredential().Password
$body = @{
username = “$RESTAPIUser"
password = “$RESTAPIPassword”
}
Invoke-RestMethod -SessionVariable DaLogin -Method Post -Uri "https://avolmanager.askaresh.com/cv_api/sessions” -Body $body
$output = Invoke-RestMethod -WebSession $DaLogin -Method Get -Uri "https://avolmanager.askaresh.com/cv_api/writables" -ContentType "application/json"
$output.datastores.writable_volumes | Select-Object owner_name, owner_upn,total_mb, free_mb, percent_available, status | Where-Object {$_.free_mb -lt 3072} | Export-Csv -NoTypeInformation -Append D:\Aresh\Writableslt3gb.$(Get-Date -Format "yyyyMMddHHmm").csv
#send an email (provided the smtp server is reachable from where ever you are running this script)
$emailfrom = 'writablevolumes@askaresh.com'
$emailto = 'email1@askaresh.com', 'email2@askaresh.com' #Enter your SMTP Details
$emailsub = 'Wrtiable Volumes Size (free_mb) less than 3 GB out of 30 GB - 24 Hours'
$emailbody = 'Attached CSV File from App Volumes Manager. The attachment included the API response for all the Writable Volumes less than 3 GB of free space'
$emailattach = "D:\Aresh\Writableslt3gb.$(Get-Date -Format "yyyyMMddHHmm").csv"
$emailsmtp = 'smtp.askaresh.com'
Send-MailMessage -From $emailfrom -To $emailto -Subject $emailsub -Body $emailbody -Attachments $emailattach -Priority High -DeliveryNotificationOption OnFailure -SmtpServer $emailsmtp
Последняя версия сценария PowerCLI для поиска заполненных томов доступна в репозитории на GitHub. Там же, кстати, есть сценарий для поиска Writable Volumes со статусом Disabled или Orphaned.
Не так давно мы писали о новых возможностях платформы для создания отказоустойчивых хранилищ виртуальных машин в инфраструктуре виртуализации VMware vSAN 7.0. Компания VMware недавно сделала доступными для загрузки все компоненты обновленной виртуальной инфраструктуры, но новые возможности получили далеко не все пользователи - их набор зависит от имеющейся лицензии.
Давайте посмотрим, какие возможности есть в каждом из четырех доступных изданий VMware vSAN 7.0:
Standard (гибридные хранилища HDD+SSD)
Advanced (All-Flash хранилища)
Enterprise (возможности для предприятий)
Enterprise Plus (гиперконвергентная инфраструктура)
Возможности vSAN 7
Политики хранилищ Storage Policy Based Management (SPBM)
Не так давно компания VMware выпустила обновление пакетов продуктов vRealize Suite и vClud Suite, в состав которых входит средство VMware vRealize Orchestrator 8.1. Напомним, что это средство предназначено для автоматизации рабочих процессов в виртуальной инфраструктуре за счет скриптования и оркестрации последовательности рутинных операций при управлении виртуальной средой.
Давайте посмотрим, что нового появилось в vRO 8.1:
Древовидное представление иерархических папок. Функция, которая была в более ранних версиях и потом пропала из vRO, теперь вернулась и позволяет пользователям удобно организовывать и просматривать объекты в виде дерева.
Элементы Run и Debug для рабочих процессов. Пользователи могут выполнить действия запуска и отладки без необходимости их добавления в рабочий процесс.
Схема Debug workflow - теперь можно добавлять точки останова к определенным элементам в схемах для рабочих процессов.
Возможность пуша набора изменений в бранчи Git. При работе с версиями контента в репозитории Git, vRO позволяет пользователям выбрать, настроить и запушить изменения в разные бранчи. Для данной функции нужна лицензия vRealize Automation.
Несколько языков для скриптов: PowerShell, Node.js, Python. vRealize Orchestrator 8.1 добавляет поддержку PowerCLI 11/Powershell 6.2, Node.js 12, and Python 3.7. Для этого также нужна лицензия vRealize Automation.
Поддержка сервиса Syslog - можно настроить интеграцию со службами логирования для одного или нескольких удаленных серверов syslog.
Графическое сравнение версий схем рабочих процессов - теперь эта возможность позволяет наглядно определить, какие изменения были внесены в следующую версию workflow.
Апдейт API плагинов для поддержки vSphere 6.7.
Скачать VMware vRealize Orchestrator 8.1 можно по этой ссылке. Release Notes доступны тут.
На днях на сайте проекта VMware Labs появилась полезная администраторам vSphere штука - утилита vSphere Replication Capacity Planning, позволяющая определить реальное потребление трафика репликации виртуальными машинами и размер передаваемой дельты данных. Это позволяет планировать сетевую инфраструктуру и принимать решения о выделении канала еще до того, как вы включите репликацию для всех своих виртуальных машин.
Утилита Replication Capacity Planning показывает графики, касающиеся объема передачи сетевого трафика LWD (lightweight delta - изменения с момента последней репликации) во времени, а также метрики по размеру дельты в различных временных масштабах - часы, дни, недели и месяцы.
Также в результате работы этого средства для виртуальной машины будет показано, какой объем вычислительных ресурсов и хранилища под реплики вам потребуется на целевой площадке (без учета актуальной политики хранилищ там):
Решение vSphere Replication Capacity Planning развертывается как виртуальный модуль (Virtual Appliance), для его работы потребуется VMware ESXi 6.0 или более поздней версии. Скачать его можно по этой ссылке. Документация доступна здесь.
На сайте проекта VMware Labs появился необычный контент - Bask Iyer, занимающий должность CIO and Chief Digital Transformation Officer, в специальном проекте "Tech For Good" рассказывает о четырех ключевых сферах Cloud, Mobile, IoT и AI в формате виртуальной реальности. Данный экспириенс посвящен практической пользе данных технологических сфер - продуктивность фермерства, устройство городов, диагностика заболеваний и т.п.
Работает это для очков Oculus Quest и Go:
Приложение доступно через сервис SideQuest, который вы можете настроить согласно этой инструкции. После настройки SideQuest вы можете установить приложение по этой ссылке или найти его по строчке "Tech for Good" внутри сервиса SideQuest.
Также вы можете скачать APK-файл со страницы приложения (кнопка Download слева) и загрузить его через ADB Tool, использовав инструкции по этой ссылке.
На что только у людей не находится времени в эпоху карантина)
В условиях распространения коронавируса и стрессующих мировых экономик производители ПО и крупные сервис-провайдеры делают много интересных вещей, поддерживающих бизнесы поменьше. Например, Microsoft сделала бесплатными приватные репозитории GitHub, ну а VMware представила новый сервис RemoteHelp.
Пользователи решения VMware Workspace ONE знают, что у VMware есть программа поддержки сотрудников своих клиентов под названием Workspace ONE Assist. Она позволяет сотрудникам поддержки VMware работать напрямую с пользователями данного продукта для решения возникающих проблем. Это существенно ускоряет время разрешения инцидентов и в целом повышает уровень лояльности клиентов.
Сейчас VMware решила расширить поддержку клиентов за счет сервиса RemoteHelp на базе ONE Assist, который теперь будет помогать решать следующие задачи мобильных пользователей на платформах Android и iOS:
RemoteHelp позволяет сотруднику поддержки VMware просматривать консоль устройства или получить контроль над ней в целях решения проблемы в реальном времени, ассистируя действиям пользователя. Если потребуется перезагрузка - сотрудник поддержки автоматически пересоединится с консолью после ее завершения.
RemoteHelp обеспечивает приватность коммуникации и сохранение личного пространства пользователя. Работа с поддержкой происходит только при запущенном приложении VMware RemoteHelp, в котором пользователь вводит одноразовый пароль для удаленной сессии. Во время работы с приложением пользователь видит информацию о том, что его экран доступен для просмотра и управления сотруднику поддержки.
RemoteHelp - это решение на баз веб-инструментов, которое можно интегрировать с текущей CRM-системой, провайдером идентификации, шлюзом SMS, сквозной аутентификации (SSO) и другими решениями для создания полного цикла обслуживания пользователей в плане решения проблем. Например, сотрудник VMware может послать пользователю на телефон смс со ссылкой на приложение RemoteHelp.
Ну и рекомендуем вам посмотреть видео о том, как работает новый сервис RemoteHelp для устройств Android:
При развертывании новой версии платформы VMware vSphere 7 в виртуальной машине (вложенные/nested ESXi) на серверах со старыми процессорами вы можете столкнуться с тем, что ваш CPU не поддерживается со стороны платформы:
В этом случае вы все равно можете установить гипервизор ESXi седьмой версии. Для этого вам надо открыть настройки виртуальной машины:
В разделе CPUID Mask нажать ссылку Advanced и далее вбить в регистре eax для Level 1 следующие значения:
Для процессоров Intel CPU: 0000:0000:0000:0011:0000:0110:1100:0011
Для процессоров AMD CPU: 0000:0000:0110:0000:0000:1111:0001:0000
После этого включайте ВМ, где будет установлен ESXi 7, и проходите до конца установки:
После этого ваш ESXi 7 спокойно загрузится. Затем нужно откатить маскирование функций CPU к исходной чистой конфигурации, удалив значение регистра eax:
Обратите внимание, что такая конфигурация не поддерживается в производственной среде! Поэтому используйте такие виртуальные ESXi 7 только для тестирования и других некритичных задач.
На днях компания VMware выпустила большое обновление свой платформы для сетевой виртуализации датацентров NSX-T 3.0. Напомним, что это решение предназначено для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров и контейнеров приложений Kubernetes/Docker. О версии NSX-T 2.5, выпущенной в рамках VMworld 2019, мы писали вот тут.
Давайте посмотрим, что нового в обновленном NSX-T 3:
1. Улучшения работы в облачной среде.
Здесь можно отметить следующие нововведения:
NSX Federation - с помощью нового компонента NSX Global Manager можно централизованно управлять распределенной виртуальной сетью в нескольких локациях, поддерживая их в синхронизированном виде с точки зрения конфигурации, политик безопасности и операционного управления. При миграции рабочих нагрузок между датацентрами их политики сохраняются и контролируются из единой точки.
Поддержка AWS GovCloud и Azure Government - эта возможность позволяет обслуживать облака на базе AWS и VMware для госструктур США с соблюдением всей необходимой регуляторики.
Улучшенная поддержка нескольких клиентов в облаке за счет VRF Lite и Layer 3 BGP EVPN. Средства VRF Lite позволяют упростить управление сетевой средой каждого клиента за счет поддержания для него отдельной таблицы маршрутизации, а Layer 3 EVPN бесшовно соединяет сети телеком-провайдеров с оверлейными сетями.
Dynamic Network Service Chaining - службы NSX service insertion теперь поддерживают механизм dynamic service chaining для трафика ВМ, контейнеров и физических серверов.
2. Улучшения безопасности.
Механизм Service-defined Firewall был значительно улучшен и теперь доступны следующие новые возможности:
NSX Distributed IDS/IPS – это расширенный механизм обнаружения вторжений для трафика east-west в мультиоблачных окружениях на уровне 7 модели OSI. Этот механизм использует знания о природе систем и характере обмена трафиком между ними, что позволяет создавать виртуальные защищенные сетевые зоны без необходимости физической изоляции зон друг от друга.
Улучшения L7 Edge Firewall – сетевой экран Layer 7 Edge Firewall приобрел функции анализа URL в рамках механизма URL Classification and Reputation.
DFW для Windows 2016 – теперь распределенный фаервол (DFW), помимо поддержки Linux, поддерживает и физические серверы Windows 2016.
Правила на базе времени и мастер настройки микросегментации - теперь правила фаервола можно привязать ко временным окнам, определенным администратором. Также новый мастер настройки упрощает конфигурацию микросегментации на базе сетей VLAN.
3. Сетевое взаимодействие для виртуальных машин и контейнеризованных приложений.
NSX-T полностью поддерживает инфраструктуру среды контейнеризованных приложений vSphere with Kubernetes. В единой среде контейнеров и виртуальных машин поддерживается маршрутизация, сетевое экранирование, балансировка нагрузки, NAT, IPAM и другие сетевые сервисы.
Вот как это работает в деталях:
Возможность изоляции пространств имен vSphere Namespaces - теперь в NSX-T есть логика для автоматической реализации логических сегментов с маршрутизацией и сетевым экраном, а также сервисами IPAM для изоляции пространств имен в кластере vSphere Supervisor Cluster. Все рабочие нагрузки, созданные в пространстве имен, автоматически наследуют политики безопасности этого неймспейса.
Интеграция с Cluster API в VMware Tanzu Kubernetes Grid Service –
решение NSX-T интегрируется с данными службами, позволяя разработчикам развертывать кластеры Tanzu Kubernetes Grid. Там можно создавать логические сегменты, шлюз Tier-1 Gateway, балансировщики нагрузки и прочие вещи, необходимые для этих кластеров.
Поддержка модулей Terraform Provider и Ansible - теперь поддерживаются расширенные рабочие процессы различных топологий для функций логического сегментирования, шлюза, а также сетевого оверлея и сегментов VLAN.
Упрощенная интеграция с решением vRealize Network Insight 5.2 - это позволяет организовать end-to-end видимость сетевых потоков, а также проводить более эффективный траблшутинг из дэшборда vRealize Network Insight. Также улучшены функции обнаружения приложений на платформах VMware.
Улучшения OpenStack Neutron - плагин Neutron к NSX-T был существенно доработан. Это привело к улучшению механизма управления для нескольких NSX-T endpoints. Также оператор может теперь настраивать дополнительные параметры IPv6 (DHCPv6, IPv6 LB и NAT64).
Полный список нововведений VMware NSX-T 3.0 приведен в Release Notes. Скачать это решение по этой ссылке.
Не все в курсе, но одной из новых возможностей обновленной платформы виртуализации VMware vSphere 7 стала поддержка протокола точной синхронизации времени PTP (Precision Time Protocol) для хост-серверов ESXi и виртуальных машин.
С давних пор для синхронизации времени в виртуальных машинах VMware vSphere использует протокол NTP, который обеспечивает точность синхронизации на уровне миллисекунд. Для большинства систем этого вполне достаточно, но есть и класс систем, где нужна точность на уровне микросекунд при обработке последовательности событий - например, для финансовых приложений, торгующих на бирже, где важен порядок ордеров в стакане.
Abhijeet Deshmukh написал про PTP в vSphere интересную статью, основные моменты которой мы приведем ниже.
Протокол NTP обладает следующими особенностями:
Имеет точность на уровне единиц миллисекунд.
Реализуется полностью программно, как для таймстемпинга приема сигналов точного времени, так и для таймстемпинга пользовательского уровня для передачи событий.
Широко распространен и является индустриальным стандартом синхронизации времени.
Работает несколько десятилетий, дешев, прост и надежен.
Клиенты NTP включены во все компьютеры, серверы и роутеры, а также множество программных продуктов.
Может синхронизировать время от самых разных источников - атомные часы, GPS-ресиверы, а также разные серверы, разбросанные по интернету.
Клиент-серверная архитектура, позволяющая использовать несколько серверов для синхронизации.
Возможности коррекции и отказоустойчивости - клиент может забирать время с нескольких серверов и исключать из них тот, который находится географически далеко и отвечает с задержкой сигнала.
NTP - это юникаст-протокол, который не требует особых правил маршрутизации. Пакеты получает только источник и отправитель.
Для виртуальных машин у NTP есть следующие особенности:
Сервер ESXi имеет встроенную поддержку NTP на уровне стандарта, а также имеет необходимые компоненты для его поддержки в kernel API.
NTP работает на порту 123.
NTP бесшовно работает для клиентов-виртуальных машин, где ОС поддерживают эту интеграцию.
Как правило проблем с NTP не возникает для гостевых ОС, за исключением некоторых ситуаций, когда, например, вы делаете Suspend виртуальной машины.
Виртуализация добавляет дополнительные уровни абстракции (например, vNIC), которые потенциально могут повлиять на часы гостевой ОС и переменные синхронизации.
Давайте теперь посмотрим на особенности протокола PTP (IEEE 1588):
PTP работает на уровне точности в микросекундах, для чего используется механизм Hardware time stamping (это специальные сетевые адаптеры с поддержкой PTP).
PTP, определенный стандартом IEEE 1588-2008, работает за счет обмена сообщениями мастер-часов и слейв-часов.
Вот так это выглядит:
Времена отправки и получения событий Sync и Delay_Request сохраняются как 4 таймстемпа T1-T4.
Сообщения Follow_Up и Delay_Response используются для передачи записанных таймстемпов от мастер-часов к слейв, чтобы осуществить коррекцию времени.
По окончании передачи слейв-часы имеют все 4 таймстемпа. Это позволяет посчитать смещение от мастера и скорректировать слейв-часы по формуле: Offset = (T2 + T3 – T1 – T4) /2
PTP в основном используется для обслуживания финансовых транзакций, передачи на уровне телефонных вышек, подводных систем позиционирования и прочих систем реального времени, где требуется высокая точность времени.
PTP поддерживает отказоустойчивость. Если мастер-часы отказывают, то другой мастер принимает на себя его функции, так как находится в постоянном ожидании. Это реализовано средствами алгоритма Best Master Clock (BMC).
PTP работает как мультикаст, а значит генерирует дополнительный трафик и требует специальные правила для его перенаправления между сегментами сети.
Использует 2 UDP-порта - 319 и 320.
В виртуальной машине для поддержки PTP есть специальное устройство precision clock для получения системного времени хоста.
В рамках одной сети через PTP все ее виртуальные машины получают точное время.
В итоге можно сделать следующие выводы об использовании протоколов NTP и PTP в виртуальной инфраструктуре:
Если у вас нет специальных задач под PTP, то старого доброго NTP вполне достаточно. Он надежный и отказоустойчивый.
Для PTP нужно специальное оборудование, появляется мультикастовый трафик, и требуется изменение сетевых настроек, что вызывает необходимость в дополнительных затратах по настройке инфраструктуры. Очевидно, что развертывать его нужно только в случае появления у приложений в виртуальных машинах требования к точности времени на уровне микросекунд.
Как все уже знают, VMware vSphere 7 вышла, доступна для скачивания и уже обкатывается многими администраторами виртуальных инфраструктур. Для тех, кто еще не знает, поддерживает ли текущее оборудование новый гипервизор ESXi 7, Florian Grehl сделал специальный сценарий PowerCLI, который позволяет вывести эту информацию для серверов кластера:
Сценарий доступен в репозитории на GitHub. Скрипт автоматически загружает функцию HCL-Check (из GitHub), а также JSON-файл для VMware HCL. В переменной $scope можно установить серверы, которые будут проверены (по умолчанию проверяется все окружение vCenter).
Надо понимать, что если ваш хост не поддерживается для VMware ESXi 7, то имеет смысл проверить его еще раз на всякий случай в реальном VMware HCL.
Если вы получаете вот такое сообщение об ошибке:
.\check_esxi_70_support.ps1 : File .\check_esxi_70_support.ps1 cannot be loaded. The file is not digitally signed. You cannot run this script on the current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.
Значит нужно в свойствах скрипта разблокировать его:
Как все уже знают, недавно компания VMware выпустила обновление своей флагманской платформы VMware vSphere 7. Одновременно с этим были выпущены новые версии и других продуктов серверной и десктопной линеек.
Сегодня мы поговорим об особенностях управления сертификатами в обновленной инфраструктуре vSphere 7. Во-первых, сертификаты Solution User Certificates были заменены на VMCA Certificates (Intermediate CA), что сильно упростило управление инфраструктурой сертификатов для виртуальной среды:
Второй полезный момент - это интерфейс REST API для обработки сертификатов vCenter Server как часть общей стратегии по управлению всеми аспектами vSphere через API:
Также в vCenter Server и ESXi было сделано много улучшений, чтобы снизить число необходимых сертификатов для случаев, когда вы управляете ими вручную, либо автоматически с помощью центра сертификации VMware Certificate Authority (VMCA), который является частью vCenter.
VMCA - это полностью автономный и самодостаточный компонент для управления сертификатами для защищенной шифрованием виртуальной среды, исключая собственно сами сервисы и приложения в виртуальных машинах (для этого уже нужна инфраструктура PKI, в этом отличие VMCA от обычного CA).
В инфраструктуре vSphere 7 есть 4 способа управления сертификатами:
Fully Managed Mode - в этом случае на vCenter есть VMCA с новым корневым сертификатом. Этот режим используется для управления сертификатами внутри кластеров (защита коммуникации между хостами ESXi, а также между ESXi и vCenter). Для этого используются так называемые Machine Certificates. Сертификат VMCA root CA certificate можно загрузить с главной веб-страницы vCenter и импортировать его на свой компьютер для настройки траста. Также можно перегенерировать корневой VMCA-сертификат на базе собственной информации вместо дефолтной (вроде "VMware Engineering" и т.п.).
Hybrid Mode - если у вас слишком много пользователей, которые управляют элементами инфраструктуры vSphere, может оказаться непрактичным заставлять всех их импортировать корневые сертификаты на свои машины. Вместо этого вы можете заменить сертификат, который использует vSphere Client, чтобы браузеры принимали его по умолчанию. Однако администраторы vSphere могут по-прежнему хотеть импортировать корневой сертификат VMCA в целях настройки траста с хостами ESXi, чьи управляющие интерфейсы могут иметь сертификаты, подписанные со стороны VMCA. Как правило, команда администраторов не такая большая, поэтому для этого не требуется много усилий.
Надо понимать, что ни в режиме Fully Managed Mode, ни в Hybrid Mode не используются самоподписанные сертификаты. Все эти сертификаты подписаны со стороны VMCA как центра сертификации. Доверяя VMCA, мы безоговорочно доверяем и серверу VMware vCenter, что надо учитывать при планировании защиты виртуальной инфраструктуры.
Subordinate CA Mode - в этом режиме VMCA может оперировать как подчиненный центр сертификации, подчиняясь корпоративному CA. В этом режиме vCenter продолжает выполнять функции по автоматизации управления сертификатами как в режиме Fully Managed Mode, за исключением того, что они генерируются на стороне корпоративного центра сертификации. В этом случае надо уделять внимание процессу передачи сертификатов со стороны корпоративного CA на vCenter, так как в это время может произойти их подмена со стороны злоумышленника. Поэтому даже крупные организации, как правило, используют режим Hybrid Mode.
Full Custom Mode - в этом случае VMCA не используется для управления сертификатами, а администратор в ручном режиме занимается их генерацией и импортом. Это весьма экзотический сценарий, так как в этом случае придется управлять десятками и даже сотнями сертификатов, в зависимости от размера инфраструктуры. Это рождает большую вероятность человеческой ошибки. Возможно, этот вариант применим для каких-то особо секретных инфраструктур, где доверие людям больше, чем доверие ИТ-системам.
VMware в своей статье про сертификаты для vSphere 7 однозначно рекомендует использовать режим Hybrid Mode, если к нему в вашей инфраструктуре нет каких-либо противопоказаний или ограничений.
Разместить рекламу у нас очень просто! Нажмите сюда, чтобы посмотреть список всех наших рекламодателей за 13 лет. Многие из них работают с нами уже более 10 лет. Форматы сотрудничества могут быть разные - от размещения рекламного баннера до полноценного стратегического партнерства с размещением статей, конкурсов и анонсами мероприятий.
На сайте проекта VMware Labs вышло несколько небольших обновлений утилит для виртуальной инфраструктуры vSphere. Первое обновление - это новая версия USB Network Native Driver for ESXi 1.5. Напомним, что это набор драйверов для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. О прошлой версии драйверов мы писали вот тут.
Сейчас в версии 1.5 поддерживаются следующие устройства:
Основная новая возможность - поддержка VMware vSphere 7. Будьте внимательны - для vSphere 7 сделан отдельный дистрибутив. Есть также и отдельные пакеты для vSphere 6.7 и 6.5.
Скачать USB Network Native Driver for ESXi можно по этой ссылке.
Второе небольшое обновление - это новая версия утилиты vSphere Software Asset Management Tool 1.1. С помощью vSAM можно собрать подробную информацию об инсталляции VMware vSphere на вашей площадке, касающуюся лицензий - весь инвентарь и доступные лицензии.
Из новых возможностей - новая таблица Host Inventory Table в генерируемом отчете software asset management, а также косметические исправления текстов. О первой версии утилиты мы писали вот тут.
Скачать vSphere Software Asset Management Tool можно по этой ссылке.
На сайте проекта VMware Labs очередное обновление - вышел апдейт VMware OS Optimization Tool
b1150. Напомним, что это средство предназначено для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач. О прошлой версии этой утилиты b1140 мы писали вот тут.
Давайте посмотрим, что нового есть в апрельском апдейте OS Optimization Tool:
Появилась поддержка Windows 10 version 2004 (добавлено во встроенный шаблон Windows 10 1809 – XXXX-Server 2019).
Добавлено множество оптимизаций для Windows 10 и Windows Server.
Новые настройки для приложений:
Office 2013/2016/2019:
Отключить стартовый экран
Отключить анимации
Отключить аппаратное ускорение
Internet Explorer 11 и браузер Edge:
Возможность добавить пустую домашнюю страницу
Не показывать мастер первого запуска
Отключить аппаратное ускорение
Adobe Reader 11 и DC
Отключить аппаратное ускорение
Множество дополнительных мелких оптимизаций
Несколько новых оптимизаций для служб Windows и запланированных задач, уменьшающих время инициализации ОС и увеличивающих производительность.
Несколько кнопок было переименовано и реорганизовано, чтобы лучше отражать суть того, что они делают.
Улучшения структуры файла ответов Sysprep.
Новые настройки для задач во время операции Generalize.
Автоматизация использования утилиты SDelete для обнуления блоков на диске (полезно при клонировании диска).
Создание локальных групповых политик для компьютера и пользователя, которые можно посмотреть с помощью утилит RSOP и GPEdit.
Поддержка командной строки для шага Generalize.
Finalize можно запускать без указания шаблона.
Удалены устаревшие шаблоны для Horizon Cloud и App Volumes.
Мы много писали о том, что нового появилось в обновленной платформе виртуализации VMware vSphere 7, которая недавно стала доступной для загрузки. Сегодня мы поговорим о том, чего больше нет в vSphere, ведь многие администраторы привыкли использовать некоторые средства, поэтому, возможно, подождут с апгрейдом. Об этих запланированных изменениях мы писали еще в 2017 году.
1. Больше нет vSphere Web Client на базе Flash
Об этом говорили давно, долго задерживали снятие с производства тяжеловесного vSphere Web Client, но все откладывали из-за несоответствия функциональности клиенту нового поколения vSphere Client на базе технологии HTML5. Теперь в vSphere 7 этот переход окончательно завершен, и старого Web Client больше нет.
Клиент на HTML5 включает в себя не только все старые рабочие процессы Web Client, но и давно получил новые возможности, такие как, например, упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM).
2. Больше нет внешнего PSC (Platform Services Controller)
Как мы уже рассказывали, Embedded PSC - это теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается. Встроенный PSC имеет все необходимые сервисы для управления доменом vSphere SSO (подробнее описано в KB 60229).
С помощью утилиты Converge Tool, которая появилась в vSphere 6.7 Update 1, можно смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC, используя командный интерфейс vCenter Server CLI или графический клиент vSphere Client:
3. Больше нет VMware vCenter for Windows
Как мы уже писали, vSphere 6.7 - это была последняя версия платформы, где для vCenter еще была версия под Windows. Теперь остался только виртуальный модуль vCenter Server Appliance (vCSA) на базе Photon OS. Многие привыкли к сервисам vCenter на базе Windows, теперь придется отвыкать.
VMware рекомендует выполнить 2 основных шага для миграции с vCenter на vCSA:
Migration Assistant - консольная утилита, которую нужно выполнить до мастера миграции vCenter. Она выясняет соответствие требованиям к миграции и показывает дальнейшие шаги.
Migration Tool - это мастер миграции, который доступен из основного дистрибутива vCenter.
4. Больше нет Update Manager Plugin
На протяжении долгого времени это был плагин для vSphere Web Client. Теперь вместо продукта VMware Update Manager (VUM) в vSphere 7 есть более широкое по функциональности решение VMware Lifecycle Manager.
Ранее администраторы vSphere использовали Update Manager (VUM) для обновлений платформы и драйверов, а утилиты от производителей серверов для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.
5. Больше нет VNC-сервера в ESXi
Ранее в ESXi был встроенный VNC-сервер, который был убран в последней версии VMware vSphere 7. Раньше можно было соединиться с консолью виртуальной машины с помощью VNC-клиента, добавив в конфигурацию параметр RemoteDisplay.vnc.enable.
Теперь такой возможности больше нет (ей пользовались администраторы систем, не использующих средства VMware). Для соединения с консолью виртуальной машины используйте vSphere Client, хостовый клиент ESXi Host Client или средство VMware Remote Console.
6. Мелочи, которых или уже больше нет или их не рекомендуется использовать (не будет потом)
В эту категорию попали:
VMware vSphere 7.0 и протокол TLS Protocol (TLS 1.0 и 1.1 отключены по умолчанию).
Нет поддержки резервного копирования на уровне образов (Image-Based Backup) для сервера vCenter.
Интерфейс VMKlinux API уже давно безнадежно устарел, вместо него используется архитектура нативных драйверов под vSphere, начиная еще с ESXi 5.5. vmkLinux - это такая прослойка между VMkernel и Linux-драйверами, которая позволяла транслировать команды от ядра (так как VMkernel - это НЕ Linux) к драйверам и обратно. Но теперь нативных партнерских драйверов устройств для ESXi накопилось достаточно, и старая архитектура Linux-драйверов ушла в прошлое.
Депрекация поддержки 32-bit Userworld. Ранее партнерам VMware была доступна возможность делать 32-битные драйверы, плагины и другие компоненты в VIB-пакетах. Теперь, начиная со следующих версий vSphere, такой возможности больше не будет.
Почти убрана поддержка Integrated Windows Authentication. В этой версии IWA еще работает, но в следующей версии уже не будет. Подробнее в KB 78506.
Депрекация аутентификации DCUI Smart Card Authentication. Пользователям со смарт-картами рекомендовано использовать vCenter, PowerCLI или API-вызовы, ну либо логин и пароль по-старинке.
Депрекация Core Partition Profile для функциональности Host Profiles. Вместо разделов Coredump Partitions пользователям нужно использовать файлы Coredump Files.
Вчера компания VMware объявила о доступности для загрузки (General Availability) своей флагманской платформы виртуализации VMware vSphere 7. Скачать ее можно по этой ссылке.
Объявление о доступности продукта было сделано во время почти часовой онлайн-сессии:
Одновременно стали доступны для скачивания и следующие решения:
Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7, а также функциональности нового механизма динамического распределения нагрузки VMware DRS 2.0. Среди новых возможностей DRS мы упоминали про функции Assignable Hardware, которые позволяют назначить профили устройств PCIe с поддержкой Dynamic DirectPath I/O или NVIDIA vGPU для первоначального размещения виртуальных машин в кластере.
Сегодня мы поговорим об этой технологии в целом. Ранее виртуальные машины, использовавшие технологии DirectPath I/O или vGPU, привязывались к физическому адресу устройства, который включал в себя адрес расположения устройства на конкретной шине PCIe конкретного хоста ESXi. Это делало невозможным использование такой ВМ на других серверах кластера, что, конечно же, делало невозможным и работу технологий HA и DRS, которые являются критически важными в современных датацентрах.
Теперь же технология Assignable Hardware вводит новый уровень абстракции, который включает в себя профиль с возможностями устройств, требующихся для виртуальной машины. Таких профилей два - для технологии Dynamic DirectPath I/O и для NVIDIA vGPU:
Таким образом, технология Assignable Hardware позволяет отделить виртуальную машину от конкретного устройства и дать ей возможность быть запущенной на другом хосте ESXi с таким же устройством (или даже другим, но поддерживающим определенный набор функций).
Теперь при настройке виртуальной машины у вас есть выбор одного из следующих вариантов для устройства PCIe:
DirectPath I/O (legacy-режим, без интеграции с HA и DRS)
Dynamic DirectPath I/O
NVIDIA vGPU
После того, как вы выберете нужный профиль оборудования, механизм DRS сможет разместить машину на хосте ESXi с поддержкой нужных функций для ВМ.
На скриншоте выше, во второй опции Select Hardware, также есть лейбл "GPGPU example" - это возможность задать определенным устройствам метки таким образом, чтобы при выборе размещения ВМ использовались только устройства хостов с данными метками (при этом модели устройств могут отличаться, например, NVIDIA T4 GPU и RTX6000 GPU). Либо можно выбрать вариант использования только идентичных устройств.
Назначить метку можно во время конфигурации PCIe-устройств. В гифке ниже показано, как это делается:
При использовании NVIDIA vGPU для виртуальной машины выделяется только часть устройства. Поддержка горячей миграции vMotion для машин, использующих vGPU, уже была анонсирована в VMware vSphere 6.7 Update 1. Теперь эта поддержка была расширена, в том числе для DRS, который теперь учитывает профили vGPU.
Ну и в видео ниже вы можете увидеть обзор технологии Assignable Hardware:
Как вы знаете, все офлайн-мероприятия этой весны отменены, набирает популярность формат онлайн-конференций. VMware в этом смысле уже давно не новичок - она регулярно проводит подобные конференции, где виртуально собираются тысячи людей со всего мира.
13 мая в этом году пройдет VMware vFORUM 2020 Online, где в течение половины дня сотрудники VMware будут рассказывать о самых последних продуктах и технологиях компании. Интересно, что форум пройдет в удобное вечернее время: с 19-00 мск до часа ночи.
Основные темы:
Multi-Cloud - управление гибридными инфраструктурами.
Modern Applications - все о контейнеризованных приложениях и кластерах Kubernetes в виртуальной среде.
Virtual Cloud Networking - соединение виртуальных машин и приложений в распределенной инфраструктуре датацентров.
Digital Workspace - управление мобильными средами, используемыми на разных платформах.
Intrinsic Security - обеспечение безопасности сетей, рабочих станций, виртуальных машин и облаков в целом.
Вот так выглядит план мероприятия, включающего в себя 38 технических сессий с более чем 130 экспертами:
Также в рамках форума будет 10 лабораторных работ (Hands-On Labs) по продуктам vSphere, vSAN, VMware Cloud on AWS, Carbon Black и Workspace ONE.
Недавно мы рассказывали о новых возможностях платформы VMware vSphere 7 и прочих обновлениях продуктовой линейки VMware, анонсированных одновременно с флагманским продуктом. Напомним эти статьи:
Сегодня мы расскажем еще об одном важном апдейте - новой версии набора решений для гибридной инфраструктуры VMware Cloud Foundation 4. О прошлой версии этого пакета VCF 3.9.1 мы писали вот тут. Как вы помните, он представляет собой комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.
Четвертая версия VCF включает в себя все самые последние компоненты, статьи с описанием которых мы привели выше:
Как мы видим, в стеке VCF появился принципиально новый компонент - VMware Tanzu Kubernetes Grid. Об инфраструктуре поддержки контейнеров в новой версии платформы vSphere мы уже писали тут и тут. В новой архитектуре VCF администраторы могут развертывать и обслуживать приложения в кластерах Kubernetes с помощью Kubernetes tools и restful API.
В то же время, технология vSphere with Kubernetes (она же Project Pacific) будет обеспечивать следующую функциональность:
Службы vSphere Pod Service на базе Kubernetes позволят исполнять узлы напрямую в гипервизоре ESXi. Когда администратор развертывает контейнеры через службы vSphere Pod Service, они получают тот же уровень безопасности, изоляции и гарантии производительности, что и виртуальные машины.
Службы Registry Service позволяют разработчикам хранить и обслуживать образы Docker и OCI на платформе Harbor.
Службы Network Service позволяют разработчикам управлять компонентами Virtual Routers, Load Balancers и Firewall Rules.
Службы Storage Service позволяют разработчикам управлять постоянными (persistent) дисками для использования с контейнерами, кластерами Kubernetes и виртуальными машинами.
Все это позволяет получить все преимущества гибридной инфраструктуры (ВМ+контейнеры), о которых интересно рассказано здесь.
В остальном, VCF 4 приобретает все самые новые возможности, которые дают уже перечисленные новые релизы продуктов vSphere, vSAN, NSX-T и прочие.
Отдельно надо отметить очень плотную интеграцию vSphere Lifecycle Manager (vLCM) с платформой vSphere 7. vLCM дополняет возможности по управлению жизненным циклом компонентов инфраструктуры виртуализации, которые уже есть в SDDC Manager, но на более глубоком уровне - а именно на уровне управления firmware для узлов vSAN ReadyNodes (например, обновления микрокода адаптеров HBA).
Как и все прочие обновления линейки vSphere, апдейт VCF 4.0 ожидается уже в апреле. За обновлениями можно следить на этой странице.
Примеров, когда крупная компания смотрит в сторону облачных решений – довольно много. Этому есть объяснение – технологии не стоят на месте и сегодня клиентам доступны различные инструменты, используя которые можно объективно экономить на ИТ-секторе. Но дело не только в этом. Зачастую облачная площадка провайдера становится спасательным кругом, в буквальном смысле спасая не только инфраструктуру организации, но и ее репутацию.
В этом на личном опыте убедилась компания «Русхимсеть» (крупнейший российский поставщик химического сырья), которая с переходом в облако, смогла избежать катастрофы в виде остановки важнейших ИТ-систем.
Без цифровизации никуда
ЗАО «РУСХИМСЕТЬ» — первый национальный универсальный химический дистрибьютор в России и странах СНГ, специализирующийся на поставках химического сырья и материалов нетранзитными нормами. Компания основана в 2000 году и на протяжении всего времени уделяет особое внимание развитию системы продаж в регионах. Сегодня ЗАО «Русхимсеть» насчитывает 15 офисов по всей России, четыре зарубежных дочерних компании и 28 логистических центра.
Поскольку дистрибьютор представлен от Минска до Красноярска, территориальная разнесенность наложила определенные требования к организации ИТ-инфраструктуры – она должна работать как единый механизм, а сервисы быть доступны сотрудникам в любой момент. В силу специфики бизнеса и необходимости оперативного управления огромными потоками номенклатуры, уйти от цифровизации и обойтись без использования современных ИТ-систем было невозможно. Поэтому сегодня инфраструктура компании представляет собой сложную архитектурную составляющую с множеством завязанных друг на друге сервисов, которые изо дня в день помогают решать различные задачи.
От разрозненных офисов к публичному облаку
Организация ИТ-инфраструктуры – довольно важный и значимый шаг в жизни любой компании. Необходимость внедрения ИТ-систем зачастую продиктована требованиями времени, ведь сегодня сложно конкурировать на рынке, если бизнес не готов к новым вызовам. Понимая тот факт, что цифровизация – неизбежный процесс, компании начинают задумываться о том, как построить собственную ИТ-инфраструктуру с наименьшими затратами. Зачастую в ход пускается экономия на оборудовании и используемых технологиях. Такой подход чреват последствиями, однако, масштаб катастрофы, которая может произойти в дальнейшем, на начальном этапе может быть совершенно неочевидным.
Так, в 2015 году перед ЗАО «РУСХИМСЕТЬ» стояла задача построить собственное приватное облако с использованием технологий виртуализации VMware и избавиться от разрозненности офисов, которые изначально работали по старинке на аналоговой связи без единых серверов и слабым документооборотом. Поставленную задачу удалось решить – компания развернула собственную виртуальную инфраструктуру и работала в таком формате пару последующих лет.
«В 2017 году мы поняли, что вкладываться в модернизацию приватного облака не имеет смысла и нужно переходить к провайдеру. Компания столкнулась с проблемой морального и физического устаревания оборудования, что неоднократно приводило к сбоям в работе отдельных систем, простоям и потерям для бизнеса. Нам хотелось больше стабильности, надежности и возможности масштабирования, чтобы в случае, когда в компании открывались новые позиции – можно было быстро добавлять ресурсы и также быстро высвобождать, если в их использовании больше не было необходимости. Убедившись на личном примере сколько урона наносит выход из строя даже одного хоста из собственной облачной инфраструктуры, мы стали всерьез задумываться о переходе в публичное облако».
Дмитрий Гончаров,
Главный системный администратор «Русхимсеть»
Как все уже знают, в скором времени компания VMware сделает доступной для загрузки обновленную платформу виртуализации VMware vSphere 7. О новых возможностях этого решения мы уже писали, а также рассказывали об отдельных улучшениях подробнее (например, о новом DRS).
Сегодня мы поговорим о службах Identity Federation, появившихся в VMware vSphere 7.
В современном мире в корпоративной инфраструктуре все чаще отходят от устаревшей аутентификации по паролям и переходят к практикам двухфакторной (2FA) или многофакторной (MFA) аутентификации. Процесс идентификации пользователей всегда основан на 3 ключевых вещах: что-то вы знаете (пароль), что-то у вас есть (телефон) или кем-то вы являетесь (отпечаток пальца).
Службы Identity Federation позволяют объединить инфраструктуру vCenter Server с другими Identity Providers, такими как Active Directory Federation Services (ADFS), в целях унификации процесса двух- или многофакторной авторизации. Иными словами, пользователи, логинящиеся через 2FA в свой десктоп или в облачный сервис, будут использовать ту же самую процедуру и для операций с vCenter Server.
Будучи подключенным к одному из провайдеров аутентификации (например, ADFS), клиент vSphere Client при логине будет перенаправлять на форму логина данного провайдера. После авторизации на стороне провайдера будет произведено обратное перенаправление с использованием защищенного токена, через который пользователь уже будет работать со службами vCenter.
С точки зрения пользовательского опыта это напоминает, например, логин на веб-сайт с помощью Google или Facebook. Для обмена информацией используются протоколы OAUTH2 и OIDC.
Если вы включите Identity Federation, вы сможете пользоваться традиционными службами Active Directory, Integrated Windows Authentication и LDAP/LDAPS для аутентификации в vCenter Server. Однако надо понимать, что все эти методы аутентификации не затрагивают vSphere Single Sign-on (SSO), который, по-прежнему, используется для внесения административных настроек в саму платформу vSphere.
Более подробно об этом механизме рассказывает Bob Plankers в видео ниже:
Некоторое время назад мы писали о новых возможностях платформы виртуализации VMware vSphere 7, среди которых мы вкратце рассказывали о нововведениях механизма динамического распределения нагрузки на хосты VMware DRS. Давайте взглянем сегодня на эти новшества несколько подробнее.
Механизм DRS был полностью переписан, так как его основы закладывались достаточно давно. Раньше DRS был сфокусирован на выравнивании нагрузки на уровне всего кластера хостов ESXi в целом, то есть бралась в расчет загрузка аппаратных ресурсов каждого из серверов ESXi, на основании которой рассчитывались рекомендации по миграциям vMotion виртуальных машин:
При этом раньше DRS запускался каждые 5 минут. Теперь же этот механизм запускается каждую минуту, а для генерации рекомендаций используется механизм VM DRS Score (он же VM Hapiness). Это композитная метрика, которая формируется из 10-15 главных метрик машин. Основные метрики из этого числа - Host CPU Cache Cost, VM CPU Ready Time, VM Memory Swapped и Workload Burstiness. Расчеты по памяти теперь основываются на Granted Memory вместо стандартного отклонения по кластеру.
Мы уже рассказывали, что в настоящее время пользователи стараются не допускать переподписку по памяти для виртуальных машин на хостах (Memory Overcommit), поэтому вместо "Active Memory" DRS 2.0 использует параметр "Granted Memory".
VM Happiness - это основной KPI, которым руководствуется DRS 2.0 при проведении миграций (то есть главная цель всей цепочки миграций - это улучшить этот показатель). Также эту оценку можно увидеть и в интерфейсе:
Как видно из картинки, DRS Score квантуется на 5 уровней, к каждому из которых относится определенное количество ВМ в кластере. Соответственно, цель механизма балансировки нагрузки - это увеличить Cluster DRS Score как агрегированный показатель на уровне всего кластера VMware HA / DRS.
Кстати, на DRS Score влияют не только метрики, касающиеся производительности. Например, на него могут влиять и метрики по заполненности хранилищ, привязанных к хостам ESXi в кластере.
Надо понимать, что новый DRS позволяет не только выровнять нагрузку, но и защитить отдельные хосты ESXi от внезапных всплесков нагрузки, которые могут привести виртуальные машины к проседанию по производительности. Поэтому главная цель - это держать на высоком уровне Cluster DRS Score и не иметь виртуальных машин с низким VM Hapiness (0-20%):
Таким образом, фокус DRS смещается с уровня хостов ESXi на уровень рабочих нагрузок в виртуальных машинах, что гораздо ближе к требованиям реального мира с точки зрения уровня обслуживания пользователей.
Если вы нажмете на опцию View all VMs в представлении summary DRS view, то сможете получить детальную информацию о DRS Score каждой из виртуальных машин, а также другие важные метрики:
Ну и, конечно же, на улучшение общего DRS Score повлияет увеличения числа хостов ESXi в кластере и разгрузка его ресурсов.
Кстати, ниже приведен небольшой обзор работы в интерфейсе нового DRS:
Еще одной важной возможностью нового DRS является функция Assignable Hardware. Многие виртуальные машины требуют некоторые аппаратные возможности для поддержания определенного уровня производительности, например, устройств PCIe с поддержкой Dynamic DirectPath I/O или NVIDIA vGPU. В этом случае теперь DRS позволяет назначить профили с поддержкой данных функций для первоначального размещения виртуальных машин в кластере.
В видео ниже описано более подробно, как это работает:
Ну и надо отметить, что теперь появился механизм Scaleable Shares, который позволяет лучше выделять Shares в пуле ресурсов с точки зрения их балансировки. Если раньше высокий назначенный уровень Shares пула не гарантировал, что виртуальные машины этого пула получат больший объем ресурсов на практике, то теперь это может использоваться именно для честного распределения нагрузки между пулами.
Этот механизм будет очень важным для таких решений, как vSphere with Kubernetes и vSphere Pod Service, чтобы определенный ярус нагрузок мог получать необходимый уровень ресурсов. Более подробно об этом рассказано в видео ниже:
На сайте проекта VMware Labs появилось очередное обновление - виртуальный модуль Ubuntu OVA for Horizon версии 1.2. С помощью этого модуля VDI-администраторы могут быстро развернуть инфраструктуру виртуальных ПК на Linux-платформе, получив уже все необходимые настройки и оптимизации в рамках OVA-пакета. Напомним, что о версии 1.1 этого средства мы писали вот тут.
Вот что нового появилось в образе Ubuntu OVA for Horizon версии 1.2:
Поддержка минимально Horizon 7.11 / Horizon Client 5.3 и более поздних версий
Поддержка минимально vSphere 6.7 и более поздних версий
Обновленный базовый образ шаблона OVA на Ubuntu 18.04.4 LTS
Недавно мы рассказывали о новых возможностях анонсированной платформы виртуализации VMware vSphere 7. В составе этого решения идет новая версия управляющего сервера VMware vCenter 7, особенности апгрейда на который мы сегодня рассмотрим.
Основные нюансы этого процесса суммаризованы в видео ниже:
Давайте посмотрим на это немного подробнее:
1. Особенности развертывания
Как мы уже рассказывали, Embedded PSC - это теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается. Встроенный PSC имеет все необходимые сервисы для управления доменом vSphere SSO (подробнее описано в KB 60229).
Напомним также, что теперь у вас нет установщика vCenter Server for Windows. Как мы уже писали, vSphere 6.7 - это была последняя версия платформы, где для vCenter еще была версия под Windows. Теперь это только виртуальный модуль vCenter Server Appliance (vCSA) на базе Photon OS.
Ранее мы писали, что с помощью утилиты Converge Tool, которая появилась в vSphere 6.7 Update 1, можно смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC, используя командный интерфейс vCenter Server CLI или графический клиент vSphere Client:
Также установщик vCenter 7 производит апгрейд vCenter и перенос всех сервисов на Embedded PSC в рамках единой задачи, поэтому результат апгрейда будет сразу законченным. Установщик нового vCenter 7 не имеет опции по развертыванию внешнего PSC:
2. Процесс миграции
Если вы проходите путь миграции с vCenter Server for Windows на vCenter Server Appliance (VCSA), то схема будет точно такой же - в итоге вы получите vCenter 7 на vCSA в встроенным PSC:
После того, как внешний PSC будет сконвертирован, он останется в консоли, и его удаление (decomission) - последующая задача администратора vSphere. Сделать это можно с помощью команды CMSSO-UTIL или из графического интерфейса клиента (в разделе System Configuration):
3. Пути апгрейда
Тут все просто. Апгрейд поддерживается согласно вот этой табличке:
Как видно из таблицы, апгрейд поддерживается, начиная с версии vSphere 6.5, но многие администраторы при обновлении виртуальной инфраструктуры предпочитают развертывать сервисы vCenter заново, чтобы не тащить за собой историю возможных багов, которые могут проявиться при апгрейде.
Кластер отказоустойчивых хранилищ VMware vSAN состоит из нескольких хостов ESXi, на локальных хранилищах которых создаются дисковые группы, где размещаются данные виртуальных машин. В процессе создания, перемещения и удаления дисковых объектов ВМ распределение емкости на дисках может изменяться, иногда довольно существенно.
Все это приводит к дисбалансу кластера по дисковой емкости, что создает разную нагрузку на устройства, а это не очень хорошо:
В случае возникновения подобного дисбаланса в кластере VMware vSAN, в консоли vSphere Client на вкладке Monitor, в разделе vSAN Health появляется нотификация vSAN Disk Balance (выполняется эта проверка каждые 30 минут по умолчанию):
Чтобы устранить подобные ситуации, в кластере VMware vSAN есть механизм автоматической балансировки - Automatic Rebalance, который относится к дисковым объектам кластера vSAN, которые распределяются по дисковым группам разных хостов. Если данная настройка включена, то кластер vSAN автоматически наблюдает за балансом распределения дисковых объектов по хостам ESXi и выравнивает нагрузку на дисковые устройства.
По умолчанию пороговое значение составляет 30% (параметр Average Load Varinace - среднее значение разницы между минимальной и максимальной используемой емкостью на дисках в процентах). Это означает, что когда разница нагрузки между двумя дисковыми устройствами достигнет этого значения - начнется автоматическая перебалансировка и перемещение дисковых объектов. Она будет продолжаться, пока это значение не снизится до 15% или меньшей величины.
Также перебалансировка сама запустится, когда диск заполнен на более чем 80%. Надо помнить, что операция эта создает нагрузку на дисковые хранилища, поэтому надо учитывать, что у вас должен быть некоторый запас по производительности, чтобы автоматическая балансировка не съела полезные ресурсы.
В случае если у вас включена настройка Automatic Rebalance, кластер vSAN будет стараться поддерживать этот хэлсчек всегда зеленым. Если же отключена - то в случае возникновения дисбаланса загорится алерт, и администратору нужно будет вручную запустить задачу Rebalance Disks.
Эта опция называется ручной проактивной балансировкой кластера, она становится доступной когда разница в использовании дисковой емкости двух или более дисков начинает превышать 30%:
Если вы запускаете такую балансировку вручную, то продлится она по умолчанию 24 часа и затем сама остановится.
Надо понимать, что операция ребалансировки - это совершенно другая операция, нежели vSAN Resync. Она служит только целям сохранения равномерной нагрузки в кластере с точки зрения дисков.
Также есть возможность контроля операций ребалансировки с помощью интерфейса Ruby vSphere Console (RVC). Для этого вам нужно сменить пространство имен (namespace) на computers и выполнить следующую команду для кластера, чтобы посмотреть информацию о текущем балансе:
vsan.proactive_rebalance_info <номер кластера vSAN или символ "." для текущего пути консоли RVC>
Результат выполнения команды будет, например, таким:
/localhost/Test-DC/computers/Test-CL> vsan.proactive_rebalance_info .
2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-3.labs.org ...
2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-1.labs.org ...
2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-2.labs.org ...
2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-3.labs.org (may take a moment) ...
2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-2.labs.org (may take a moment) ...
2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-1.labs.org (may take a moment) ...
2019-08-16 19:31:10 +0000: Done fetching vSAN disk infos
Proactive rebalance start: 2019-08-16 19:30:47 UTC
Proactive rebalance stop: 2019-08-17 19:30:54 UTC
Max usage difference triggering rebalancing: 30.00%
Average disk usage: 56.00%
Maximum disk usage: 63.00% (17.00% above minimum disk usage)
Imbalance index: 10.00%
No disk detected to be rebalanced
В этом случае ребалансировка не требуется. Если же вы, все-таки, хотите ее запустить, то делается это следующей командой:
vsan.proactive_rebalance -s <номер кластера vSAN или символ "." для текущего пути консоли RVC>
Ну и вы можете изменить время, в течение которого будет идти ручная ребалансировка. Для этого задайте значение в секундах следующей командой (в данном примере - это 7 дней):
RSS
