На сайте VMware Labs обновилась утилита HCIBench до версии 2.1.
Напомним, что о версии HCIBench 2.0 мы писали вот тут, а здесь мы рассматривали использование этой утилиты для замеров производительности кластеров VMware vSAN. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.
Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.
Целью такого тестирования может быть, например, необходимость убедиться, что развернутая инфраструктура обеспечивает достаточную производительность для планируемой на нее нагрузки.
Что нового появилось в HCIBench 2.1:
- Интерфейс переключили на темную тему.
- Переработанная технология подготовки VMDK, которая теперь работает гораздо быстрее за счет использования рандомизации на дедуплицированных хранилищах.
- Добавлена возможность обновления процесса подготовки VMDK.
- Добавлена проверка портов базы данных Graphite в процесс превалидации.
- Пароли vCenter и хостов ESXi затемняются при сохранении
- Добавлена кнопка удаления гостевой ВМ ("Delete Guest VM").
- Пофикшены проблемы с дисплеями для Grafana.
- Пофикшена проблема с пустыми результатами при отработки модели нагрузки FIO (Flexible I/O).
- Множество мелких исправлений ошибок.
Скачать HCIBench 2.1 можно по этой ссылке. Документация пока доступна только для версии 2.0.
Читать далее... - читать дальше и комментировать
|
На сайте проекта VMware Labs появилось очередное обновление - стала доступна новая версия средства USB Network Native Driver for ESXi до версии 1.1. Напомним, что ранее мы писали о нем вот тут. Это нативный драйвер для сетевых адаптеров серверов, которые подключаются через USB-порт.
Такой адаптер можно использовать, когда вам необходимо, например, подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. В каких-то еще случаях подключение такого адаптера может помочь, чтобы получить еще одно сетевое соединение без необходимости перезагружать сервер (и так же просто отключить его).
Новая версия драйвера содержит поддержку девяти новых устройств USB NIC, включая девайсы USB 2.0 RTL8152 & TPLINK. Полный список поддерживаемых устройств теперь таков:
| Vendor | Chipset | VendorID | ProductID |
|---|
| ASIX | AX88179 | 0x0b95 | 0x1790 |
| ASIX | AX88178a | 0x0b95 | 0x178a |
| CISCO LINKSYS | RTL8153 | 0x13b1 | 0x0041 |
| DLINK | AX88179 | 0x2001 | 0x4a00 |
| LENOVO | AX88179 | 0x17ef | 0x304b |
| LENOVO | RTL8153 | 0x17ef | 0x7205 |
| LENOVO | RTL8153 | 0x17ef | 0x3069 |
| LENOVO | RTL8153 | 0x17ef | 0x720a |
| LENOVO | RTL8153 | 0x17ef | 0x3062 |
| NVIDIA | RTL8153 | 0x0955 | 0x09ff |
| REALTEK | RTL8153 | 0x0bda | 0x8153 |
| REALTEK | RTL8152 | 0x0bda | 0x8152 |
| SITECOMEU | AX88179 | 0x0df6 | 0x0072 |
| TP-LINK | RTL8153 | 0x2357 | 0x0601 |
Помимо этого, в драйвер также была добавлена поддержка Jumbo Frames (размером до 4K) для устройств RTL8153 и AX88179.
Для установки драйвера нужно развернуть на ESXi 6.5 или 6.7 один из двух VIB-пакетов для соответствующей версии:
- ESXi670-VMKUSB-NIC-FLING-20124247-offline_bundle-11613968
- ESXi650-VMKUSB-NIC-FLING-20123976-offline_bundle-11613344
Делается это следующей командой:
esxcli software vib install -d /path/to/the/offline/bundle
После установки нужно перезагрузить хост VMware ESXi, после чего устройство USB NIC будет автоматически смонтировано как, например, vusb0.
Скачать USB Network Native Driver for ESXi можно по этой ссылке. Читать далее... - читать дальше и комментировать
|
Очень часто администраторы платформы VMware vSphere задаются следующими вопросами о версиях продукта vCenter: какая разница между обновлением vCenter (он же update) и патчем (patch)? в чем отличие апгрейда (upgrade) и миграции (migration)? почему некоторые версии vCenter нумеруются как-то отдельно? Попробуем дать ответы на эти вопросы ниже, используя материал вот этой статьи в блоге VMware.
Первое, что нужно понять - это нумерация версий vCenter. Она подразумевает 2 компонента - номер версии (например, vCenter 6.7 Update 2a) и номер билда (например, 13643870):
Номер версии имеет также и цифровое обозначение. Если вы зайдете в интерфейс VMware Appliance Management Interface (VAMI), то увидите там номер билда (13643870), а также полный номер версии (6.7.0.31000):
Если же вы зайдете в vSphere Client и перейдете там на вкладку Summary для вашего сервера vCenter (в данном случае vCenter Server Appliance, vCSA), то увидите там версию 6.7.0:
В данном случае в поле Build указан номер билда клиента vSphere Client (13639324), и не стоит его путать с номером билда самого vCenter. Все это как-то более-менее соотносится между собой (VAMI дает более полную информацию о цифровом номере версии).
Теперь, чтобы сложить все это в единую картину и соотнести с датой релиза конкретной версии vCenter, существует статья базы знаний KB 2143838, где есть полезная табличка:
Обратите внимание на последнюю колонку - Client/MOB/vpxd.log. Это версия клиента vSphere Client, и именно она появится в лог-файле vpxd.log, поэтому не стоит удивляться, что она отличается от номера билда vCenter.
Теперь перейдем к апдейтам и патчам. vCenter Server Update - это полноценное обновление платформы, которое может включать в себя новый функционал, исправления ошибок или доработки существующей функциональности. Выходит апдейт довольно редко и имеет свое строковое наименование (например, vCenter 6.7 Update 2a). Для апдейта всегда выпускается документ Release Notes, и его можно скачать через my.vmware.com.
Патч - это постоянно выпускаемое небольшое обновление для vCenter, которое поддерживает уровень безопасности, закрывает критические уязвимости, исправляет фатальные ошибки и т.п. Он может относиться к вспомогательным компонентам vCSA, например, Photon OS, базе данных Postgres DB или фреймворку Java.
Для патча нет выделенного документа Reelase Notes, но информация о нововведениях доступна в VMware vCenter Server Appliance Photon OS Security Patches. Патчи нельзя скачать через my.vmware.com, но они загружаются через VMware Patch Portal. Само собой, патчи включаются в апдейты, выпускаемые на какой-то момент времени. Патчи накатываются в рамках одного цифрового обновления. То есть 6.7 Update 1 не патчится напрямую на 6.7 Update 2b, сначала надо накатить апдейт 6.7 Update 2a, а затем уже пропатчиться на 6.7 Update 2b.
Также на VMware Patch Portal вы можете найти ISO-образы vCenter Server, но их не надо использовать для новых развертываний, они нужны только для восстановления вашего vCenter Server Appliance, если вы используете резервное копирование на уровне файлов.
Теперь перейдем к разнице между апгрейдом и миграцией. Апгрейд - это обновление мажорной версии сервера vCenter одного типа развертывания (например, вы делаете апгрейд vCenter Server Appliance 6.5 на vCenter Server Appliance 6.7). Миграция - это когда вы меняете тип развертывания vCenter, переходя, например, с Windows-платформы на Linux (к примеру, vCenter Server 6.5 for Windows мигрируете на vCenter Server Appliance 6.7).
Если вы обновляете vCSA 6.5 на 6.7, то апгрейд идет как бы ненастоящий - развертывается новый виртуальный модуль vCSA 6.7, и на него переезжают все настройки (FQDN, IP, сертификаты и UUID), а также содержимое базы данных vCSA 6.5.
Также надо упомянуть и back-in-time upgrade - это когда вы хотите обновить, например, vSphere 6.5 Update 2d на vSphere 6.7 Update 1. Прямое обновление тут не поддерживается, так как Update 2d для версии 6.5 вышел позднее, чем Update 1 для версии 6.7. То есть Update 2d содержит код, которого нет в Update 1, а значит это может вызвать потенциальные конфликты.
Поэтому для каждой новой версии vCenter выпускается раздел Upgrade Notes for this Release, где можно найти информацию о возможности апгрейда:
Читать далее... - читать дальше и комментировать
|
На сайте проекта VMware Labs появилось очередное обновление - Workspace ONE UEM SCIM Adapter. С помощью этого средства администратор получает возможности управления пользователями, группами и правами доступа SCIM в инфраструктуре решения Workspace ONE UEM.
Это средство представляет собой middleware, которое транслирует интерфейс System for Cross-Domain Identity Management (SCIM) во фреймворк CRUD REST, который может интерпретировать средство Workspace ONE UEM. Эта возможность позволяет Workspace ONE UEM синхронизировать облачные сервисы идентификации (пользователи/группы/назначения прав) без необходимости дополнительной интеграции LDAP (service to service model). Такими примерами являются решения Azure AD, Okta и Sailpoint.
Примеры развертывания данного средства можно посмотреть в следующих статьях:
Документация по Workspace ONE UEM SCIM Adapter доступна по этой ссылке. Скачать сам адаптер можно вот тут. Читать далее... - читать дальше и комментировать
|
У средства обновления хостов VMware vSphere Update Manager (VUM) есть полезный механизм проверок Pre-Check Remediation Report, который выполняет предварительную проверку условий для обновления хостов ESXi, чтобы этот процесс не прервался уже после его начала. Эти условия очень просты, но иногда позволяют сэкономить массу времени, особенно в большой инфраструктуре VMware vSphere.
Чтобы запустить эти проверки, надо выбрать нужный вам кластер и нажать кнопку Pre-Check Remediation:
После того, как вы запустите предпроверку Update Manager, вы получите отчет с предупреждениями о фактах, мешающих дальнейшим обновлениям:
Отчет Pre-Check Remediation Report для кластера может содержать следующие пункты:
| Номер
| Текущий статус
| Рекомендуемое действие
| Описание | | 1 |
Отключен ли DPM? |
Отключите DPM в кластере | Если на хосте нет виртуальных машин, то механизм DPM может перевести хост в режим standby во время или до обновления. Вследствие этого, DPM может не начать процесс обновления хоста. | | 2 |
Включен ли DRS? |
Включите DRS в кластере | Именно DRS позволяет серверу vCenter смигрировать ВМ на другие хосты ESXi, чтобы обновить целевой хост-сервер. | | 3 |
Отключен ли HA admission control? |
Отключите HA admission control | HA admission control предотвращает миграцию ВМ средствами vMotion, в результате которой не выполняются правила доступности слотов. Перед обновлением этот механизм лучше отключить. | | 4 |
Включен ли EVC в кластере? |
Включите EVC в кластере | EVC позволяет убедиться, что все хосты в кластере презентуют одинаковый набор инструкций CPU виртуальным машинам. Это позволяет гарантировать, что все они могут перемещаться на любой хост кластера средствами vMotion во время эвакуации машин с обновляемого хоста ESXi. | | 5 |
Успешны ли проверки vSAN health check? |
Проверьте страницу vSAN Health Check на наличие проблем | Проверки vSAN Health Check представляют собой набор тестов для хостов ESXi, составляющих кластер vSAN (например, тесты доступности хранилищ во время обновления). Они должны завершиться успешно перед началом процедуры обновления хостов. |
Отчет Pre-Check Remediation Report для виртуальных машин может содержать следующее:
| Номер
| Текущий статус
| Рекомендуемое действие
| Описание | | 1 |
К ВМ привязан привод CD/DVD |
Отключите привод CD/DVD
|
Это редкая, но случающаяся проблема, когда такие приводы используются, например, для монтирования ISO-образов. | | 2 |
К ВМ привязан floppy-драйв |
Отключите привод floppy
|
Очень редко, но бывает. | | 3 |
Для ВМ включена технология FT |
Отключите Fault Tolerance для ВМ
|
Технология Fault Tolerance не позволяет VUM обновлять ВМ. | | 4 |
На ВМ установлен VMware vCenter Server, при этом DRS в кластере отключена |
Включите DRS в кластере и убедитесь, что машина может мигрировать средствами vMotion | vCenter управляет компонентом VUM, поэтому нужно, чтобы он мог переехать на другой хост в процессе обновления ESXi.
| | 5 |
На ВМ установлен VMware vSphere Update Manager, при этом DRS в кластере отключена | Включите DRS в кластере и убедитесь, что машина может мигрировать средствами vMotion |
vCenter управляет процессом обновления, поэтому нужно, чтобы он мог переехать на другой хост в процессе обновления ESXi. |
Читать далее... - читать дальше и комментировать
|
Компания VMware опубликовала уведомление VMSA-2019-0009 для пакета VMware Tools, который содержит уязвимость, позволяющую непривилегированному пользователю читать данные из гостевой ВМ, а также негативно влиять на ее гостевую ОС. Уязвимости подвержены версии VMware Tools ниже 10.3.10.
В качестве примера использования такой уязвимости можно привести Windows-машины, где включены службы Microsoft Remote Desktop Services. Также риску подвержены службы Microsoft SQL Server или IIS, использующие сервисные аккаунты.
Сначала надо вывести все ВМ, имеющие VMware Tools версии ниже 10.3.10 с помощью следующей команды PowerCLI:
Get-VM | Where-Object {$_.Guest.ToolsVersion -lt ‘10.3.10’} | Sort-Object Name | Format-Table
Вот такая команда выдаст все Windows-машины с VMware Tools ниже, чем 10.3.10:
Get-VM | Where-Object {$_.Guest.ToolsVersion -lt ‘10.3.10’ -and $_.Guest.GuestFamily -eq ‘windowsGuest’} | Sort-Object Name | Format-Table
Проверить версию VMware Tools можно и самостоятельно в VMware vSphere Client:
Помните, что VMware 6.7 Update 2a идет с версией VMware Tools 10.3.5. Надо отметить, что гостевые ОС Linux не подвержены уязвимости, поэтому не пугайтесь, что open-vm-tools имеют только версию 10.3.5.
Последнюю же версию пакета тулзов можно скачать по этой ссылке: https://www.vmware.com/go/tools.
Если вы хотите обновить VMware Tools через офлайн-бандл, то скачайте "VMware Tools Offline VIB Bundle", после чего можно использовать vSphere Update Manager (VUM) для развертывания установщиков пакета на хостах ESXi без простоя. После этого машины должны в течение 5 минут схватить новую версию тулзов (таков период обновления информации об актуальной версии пакета). Установленная версия VMware Tools также проверяется и при vMotion, а, кроме того, и при операциях с питанием ВМ (включение/выключение).
В большой инфраструктуре вы можете настроить централизованный репозиторий VMware Tools для использования в качестве источника для многих хостов ESXi.
Обновление VMware Tools можно инициировать через PowerCLI с помощью следующего командлета:
Get-VM | Where-Object {$_.ExtensionData.Guest.ToolsVersionStatus -eq "guestToolsNeedUpgrade" -and $_.PowerState -eq "PoweredOn"} | Get-VMGuest | Where-Object {$_.GuestFamily -eq "windowsGuest" } | Update-Tools -NoReboot -RunAsync
Помните, что при апгрейде VMware Tools вам может потребоваться перезагрузка виртуальных машин и их гостевых ОС. Также вы можете использовать приведенный выше сценарий для нескольких ВМ в одной папке:
Get-VM “TEST-VM-02” | Where-Object…
Get-Folder “Test VMs - Snapshotted" | Get-VM | Where-Object…
Через vSphere Client тулзы также прекрасно обновляются:
Если вы используете опцию "Automatic Upgrade", то машина будет обновлена автоматически (без взаимодействия с гостевой ОС) и, при необходимости, перезагрузится. Также вы можете использовать обновление тулзов без немедленной перезагрузки, применив инструкции, описанные в KB1018377. Надо помнить, что в этом случае до перезагрузки будет работать старая версия VMware Tools, а значит, что до перезагрузки машины уязвимость будет актуальна.
Еще одна опция - настроить обновления тулзов в настройках виртуальной машины:
Иногда администраторы гостевой системы имеют эксклюзивный доступ к ней (например, админы бизнес-критичных баз данных) и контролируют все происходящие в ней события. Для этого надо настроить их взаимодействие с машиной как указано в KB 2007298.
В этом случае они получат нотификацию о новой версии VMware Tools из трея, либо могут проверить наличие обновлений самостоятельно с помощью команд:
VMwareToolboxCmd.exe –v - проверка установленной версии.VMwareToolboxCmd.exe upgrade status - возможность обновления для доступных апгрейдов.VMwareToolboxCmd.exe upgrade start - запуск процедуры апгрейда.
В этом случае запустится графический установщик, но не требующий вмешательства пользователя.
Читать далее... - читать дальше и комментировать
|
Администраторы отказоустойчивых кластеров хранилищ VMware vSAN часто сталкиваются с проблемами производительности, наблюдаемыми в виртуальной среде. Как правило, о таких проблемах администратор узнает двумя путями: либо ему сообщают пользователи, либо он видит алерты, которые генерируются в консоли клиента vSphere Client при превышении определенных пороговых значений.
Так или иначе, администратор должен, прежде всего, выяснить, что проблема низкой производительности приложений проявляет себя именно на уровне гостевой системы. В этом случае VMware предлагает придерживаться следующего рабочего процесса:
Основные моменты траблшутинга по такому воркфлоу рассказаны в документе "Troubleshooting vSAN Performance". Самый очевидный симптом проблем - это задержки (Latency) на уровне гостевой ОС (то есть время, затраченное на выполнение транзакции ввода-вывода), которые приводят к медленной работе приложений.
Задержки измеряются в миллисекундах, и интерпретация их значений зависит от контекста - размер блока ввода-вывода, характер потока (чтение/запись, последовательное/случайное). При этом latency измеряется на некотором сегменте прохождения команд к хранилищу, на каждом из участков которого также возникают свои составляющие задержек. Анализ таких компонентов Storage stack в контексте задержек и поиск узких мест - и есть основная задача администратора, решающего проблемы низкой производительности приложений для пользователей. Многое из этого можно делать с помощью утилиты ESXTOP, о которой мы много писали.
Обратите внимание, что на иллюстрации фреймворка выше, анализ виртуальной инфраструктуры и анализ приложений и их рабочих процессов находится еще до анализа метрик. Это связано с тем, что выбор метрик, на которые стоит обратить внимание в среде VMware vSAN, зависит от характера происходящих проблем.
После того, как администратор выяснил основные признаки проблемы и локализовал ее на уровне приложений, можно приступать к анализу метрик. Алгоритм действий приведен в документе "Troubleshooting vSAN Performance":
Тут рекомендуется делать следующее:
- Шаг 1 - просматриваем метрики в гостевой ОС проблемной ВМ, чтобы убедиться, что проблемы с производительностью хранилища ощущаются на уровне приложений.
- Шаг 2 - просматриваем метрики на уровне кластера vSAN, чтобы в целом понять масштаб проблемы - нет ли других аномалий в кластере. Это позволяет идентифицировать потенциальные "наводки" от других компонентов виртуальной инфраструктуры.
- Шаг 3 - просматриваем метрики на уровне хоста ESXi, чтобы соотнести метрики внутри гостевой ОС и всего хоста в целом с точки зрения latency.
- Шаг 4 - смотрим на хосте метрики дисковой группы, чтобы найти источник повышенной latency.
- Шаг 5 - если не нашли проблему на шаге 4, то смотрим на сеть хоста и метрики VMkernel, чтобы убедиться, что сеть функционирует штатно.
То есть смысл прост - если что-то тормозит в кластере VMware vSAN, то это либо дисковая подсистема, либо сетевая инфраструктура. Ну и главное - правильно идентифицировать хост/хосты ESXi, где находятся компоненты виртуальной машины.
И еще одна важная рекомендация - при траблшутинге старайтесь не менять несколько настроек одновременно, чтобы решить проблему. Во-первых, вы не сможете понять, какая из настроек или их комбинация дала правильный эффект, а, во-вторых, вы не сразу можете обнаружить, что сделанные вами настройки может и помогли машине работать быстрее, но остальные машины этого хоста или кластера значительно просели по производительности. А вернуть все назад может быть не так уж и просто.
Читать далее... - читать дальше и комментировать
|
Недавно мы писали о том, как настроить сетевое соединение между Compute Network и SDDC Management Network в публичном облаке VMware vCloud on AWS (VMConAWS). Сегодня мы расскажем еще об одной полезности, предложенной Вильямом Ламмом - развертывании виртуального модуля VMware vCenter Server Appliance (VCSA) в такой инфраструктуре.
Начать надо с того, что когда вы запустите графический установщик виртуального модуля vCSA в среде VMC, то получите вот такое сообщение об ошибке на этапе указания параметров хоста для развертывания:
User has no administrative privileges
Это интересно тем, что на самом деле установщик vCSA не требует административных привилегий и, по идее, не должен выдавать такого сообщения об ошибке. Поэтому Вильям нашел, все-таки, способ развернуть vCSA в публичном облаке.
Для этого надо сделать следующее:
1. Создать вспомогательную ВМ (например, с Windows 10 на борту), которая будет использовать для развертывания нового экземпляра vCSA с помощью командной строки. Вы можете использовать для этой цели любую ОС, которая поддерживает интерфейс vCSA CLI.
2. Настроить соединение между сетевыми экранами Management (MGW) и Compute (CGW) для этой машины, как мы писали вот тут, чтобы установщик имел доступ к административной сети.
3. Развернуть vCSA через CLI с помощью файла конфигурации развертывания в формате JSON, настроенного под ваше окружение. Вот пример содержимого такого файла, который вы можете взять за основу:
{
"new_vcsa": {
"vc": {
"hostname": "vcenter.sddc-a-b-c-d.vmwarevmc.com",
"username": "cloudadmin@vmc.local",
"password": "FILLMEIN",
"deployment_network": "sddc-cgw-network-1",
"datacenter": [
"SDDC-Datacenter"
],
"datastore": "WorkloadDatastore",
"target": [
"Cluster-1",
"Resources",
"Compute-ResourcePool"
]
},
"appliance": {
"thin_disk_mode": true,
"deployment_option": "tiny",
"name": "VCSA-67u2"
},
"network": {
"ip_family": "ipv4",
"mode": "dhcp"
},
"os": {
"password": "VMware1!",
"time_tools_sync": true,
"ssh_enable": true
},
"sso": {
"password": "VMware1!",
"domain_name": "vsphere.local"
}
},
"ceip": {
"settings": {
"ceip_enabled": false
}
}
}
После этой процедуры вы получите работающий VMware vCenter Server Appliance 6.7 Update 2 в своей инфраструктуре, который сможете использовать как для тестирования его возможностей, так и для полноценного управления виртуальной средой:
Читать далее... - читать дальше и комментировать
|
Не так давно мы писали о функции Site Locality в кластере VMware vSAN и некоторых ситуациях, когда эту функцию полезно отключать. Недавно Дункан Эппинг еще раз вернулся к этой теме и рассказал, что при использовании растянутых кластеров VMware vSAN надо иметь в виду некоторые особенности этого механизма.
При создании растянутого кластера вам предоставляют опции по выбору уровня защиты данных RAID-1 или RAID-5/6 средствами политики FTT (Failures to tolerate), а также позволяют определить, как машина будет защищена с точки зрения репликации ее хранилищ между датацентрами.
Некоторые дисковые объекты машин вы можете исключить из растянутого кластера и не реплицировать их между площадками. Такая настройка в HTML5-клиенте выглядит следующим образом:
В старом интерфейсе vSphere Web Client это настраивается вот тут:
Смысл настройки этих политик для виртуальной машины в том, чтобы вы могли однозначно определить размещение ее дисковых объектов, так как если у нее несколько виртуальных дисков VMDK, то если вы не зададите их локацию явно - может возникнуть такая ситуация, когда диски одной машины размещаются в разных датацентрах! Потому что при развертывании ВМ решение о размещении принимается на уровне дисковых объектов (то есть на уровне виртуальных дисков), которые по каким-то причинам могут разъехаться в разные сайты, если вы выберите первый пункт на первом скриншоте.
Это, конечно же, со всех сторон плохо, особенно с точки зрения производительности.
Если такая машина работает не в растянутом кластере vSAN, то в случае, если произойдет разрыв между площадками - часть дисков в гостевой системе станет недоступна, что неприемлемо для приложений и ОС.
Поэтому всегда убеждайтесь, что машина и ее дисковые объекты всегда находятся на одном сайте, для этого задавайте их локацию явно:
Читать далее... - читать дальше и комментировать
|
Не смогли в этом году присутствовать на VeeamON Forum 2019 в Москве? Присоединяйтесь онлайн!
VeeamON Forum Москва 2019 - крупнейший форум по интеллектуальному управлению данными - состоится 6 июня.
В программе:
- Выступления Дэниэла Фрида, генерального директора и старшего вице-президента в регионе EMEA, и Василия Ваганова, вице-президента по Восточной Европе, России, СНГ и странам Ближнего Востока.
- Представители Hewlett Packard Enterprise, NetApp, Lenovo, PureStorage, Nutanix расскажут об эволюции в управлении данными.
- Технические сессии, включая обзор архитектуры, планирования и установки для Veeam Backup for Microsoft Office 365, тонкости проектирования комплексной платформы Veeam с более 25.000 виртуальных машин, и многое другое.
Полный перечень выступлений. Трансляция сегодня доступна по этой ссылке. Читать далее... - читать дальше и комментировать
|
Другие посты
Архив новостей
|  |
RSS
