Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4770 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru / Articles / Нагрузочное тестирование Veeam Backup&Replication.

Нагрузочное тестирование Veeam Backup&Replication.

Нагрузочное тестирование Veeam Backup&Replication.

Автор: Selectel
Дата: 20/12/2018

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

  • Изучение документации и лучших практик по продуктам Veeam
  • Разработку архитектуры VBR уровня сервис-провайдера
  • Развертывание инфраструктуры VBR
  • Тестирование решения, определение оптимальных настроек и режимов работы
  • Запуск решения в промышленную (коммерческую) эксплуатацию

Как оказалось – не зря. Услуга стабильно функционирует, клиенты могут бэкапить свои виртуалки, а у нас появилась определенная экспертиза, которой мы хотим поделиться.

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

Здесь вы сможете увидеть:

  • Описание production-инфраструктуры Selectel, использованной для тестирования
  • Особенности работы бэкап-прокси (backup proxy) в различных транспортных режимах
  • Описание программы тестирования и настроек компонентов VBR для её реализации
  • Количественные показатели, их сравнение и выводы

Конфигурация инфраструктуры для проведения тестов

Инфраструктура-источник

В качестве платформы для тестирования производительности VBR выступил один из production-кластеров публичного Облака на базе VMware.

  • Аппаратная конфигурация хостов данного кластера:
  • Процессоры Intel® Xeon® Gold 6140
  • NVMe-накопители Intel® DC P4600 и P3520
  • 4 порта 10GbE на хост

В основе кластера лежат следующие решения:

  • Физическая сеть – Ethernet-фабрика на коммутаторах Brocade VDX, архитектура Leaf-Spine (10GbE порты – подключение хостов, 40GbE аплинки до Spine)
  • Среда виртуализации – VMware vSphere® 6.5
  • Хранение данных ВМ – VMware vSAN™ 6.6 (All-Flash кластер vSAN)
  • Виртуализация сети – VMware NSX® 6.4

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

Вместе с Облаком на базе VMware, Selectel запустил услугу для его бэкапа на платформе VBR. Заказчики получают web-портал самообслуживания, в котором могут выполнять бэкап и восстановление vApp и ВМ из своих VDC (виртуальный дата-центр).

Доступ клиентов к данному порталу (Veeam® Enterprise Manager Self-service portal) осуществляется с теми же правами, что и к vCloud Director® (vCD). Это возможно благодаря интеграции Veeam® Backup Enterprise Manager (EM) и vCD, при этом каждый клиент при подключении к ЕМ ограничен ресурсами своих VDC, чужие ВМ он не увидит.

Клиенту не нужно разворачивать собственный VBR и связанную с ним инфраструктуру бэкапа, что предполагает затраты на вычислительные и сетевые ресурсы, хранилище, лицензии Veeam и MS, администрирование. Это долго, дорого и сложно. Selectel предоставляет основные возможности VBR как услугу BaaS (Backup-as-a-Service): мгновенно, просто, удобно, экономично.

Для предоставления данной услуги в Selectel была развернута провайдерская инфраструктура VBR, охватывающая все кластеры vSphere и VDC клиентов облака VMware, в том числе кластер, в котором проводилось данное тестирование. Таким образом, результаты тестов позволят судить о максимальной скорости, с которой клиенты смогут бэкапить свои ВМ.

Тестовые ВМ

Для тестирования производительности бэкапа в кластере vSphere было развернуто 6 идентичных ВМ в следующей конфигурации:

  • ОС Windows Server 2016, 2 vCPU, 4GB RAM
  • 200GB vDisk

Диск занят почти полностью – 193GB. Кроме файлов ОС, на нем создана папка с дистрибутивами различных ОС и СУБД объёмом 60GB (уникальные данные). На том же диске создано 3 копии данной папки – итого 180GB несистемных данных.

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

В кластере vSphere включен DRS, поэтому тестовые ВМ автоматически оптимально распределяются по хостам VMware ESXi™ для балансировки нагрузки.

Бэкап-прокси

ВМ с бэкап-прокси развернута непосредственно в описанном выше кластере vSphere (инфраструктура-источник, далее – кластер vSphere), это необходимое условие для тестирования в режиме Virtual Appliance.

Конфигурация ВМ:

  • 8 vCPU
  • 8GB RAM
  • 40GB vDisk
  • 10GbE vNIC vmxnet3
  • ОС Windows Server 2016

Параметр «Max concurrent tasks» для бэкап-прокси на уровне VBR выставлен в значение 6. Это значит, что бэкап-прокси сможет одновременно (параллельно) обрабатывать до 6 задач (task) бэкапа. Один task – это бэкап одного виртуального диска ВМ.

Репозиторий бэкапа

В качестве фронтенда хранилища бэкапов выступает физический сервер, выполняющий роль бэкап-репозитория VBR. Конфигурация сервера:

  • CPU Е5-1650v3
  • 32GB RAM
  • 2 порта 10GbE

Бекенд хранилища – кластер CephFS c NVMe-кэшем.

Бэкап-репозиторий и узлы Ceph общаются по сети 10GbE, каждый из них подключен к коммутаторам двумя портами.

Подробное описание конфигурации кластера Ceph выходит за рамки данной статьи. Отметим, что для надежности и отказоустойчивости данные на нем хранятся в трех копиях. Производительность кластера не вызывает нареканий и заложена с запасом, результаты тестов показали, что ни в одном из них хранилище бэкапов не являлось узким местом.

Параметр «Limit maximum concurrent tasks» для бэкап-репозитория на уровне VBR выставлен в значение 6. Это значит, что бэкап-репозиторий сможет одновременно (параллельно) обрабатывать до 6 задач (tasks) бэкапа.

Сеть бэкапа

Физическая сеть описанной выше инфраструктуры ограничена полосой пропускания 10Гбит/с, везде используются коммутаторы и порты 10GbE. Это справедливо не только для сети vSAN, но и для менеджмент-интерфейсов хостов ESXi.

Для размещения бэкап-прокси на уровне VMware NSX создана выделенная подсеть со своим логическим коммутатором. Для её связности с физикой и осуществления маршрутизации развернут NSX-edge, размер X-large.

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

Схема взаимодействия компонент

Бэкап-прокси и тестовые ВМ развернуты внутри одного кластера VMware vSAN. После запуска задания бэкапа (бэкап-джобы) в зависимости от выбранного транспортного режима, особенности которых рассмотрены ниже, бэкап-прокси:

  • Извлекает данные из бэкапируемых ВМ по сети vSAN (HotAdd) или по сети управления (NBD)
  • Передает обработанные данные на бэкап-репозиторий по выделенной для этой цели подсети

Транспортные режимы бэкап-прокси

Бэкап-прокси (Backup proxy) является компонентом инфраструктуры VBR, непосредственно выполняющим обработку задания бэкапа. Он извлекает данные из ВМ, обрабатывает их (сжимает, дедуплицирует, шифрует) и отправляет на репозиторий, где они сохраняются в файлы бэкапа.

Бэкап-прокси позволяет работать в трёх транспортных режимах:

  • Direct storage access
  • Virtual appliance
  • Network

Облако на базе VMware Selectel в качестве хранилища использует vSAN, в такой конфигурации Direct storage access не поддерживается, поэтому данный режим не рассматривается и не был протестирован. Оставшиеся два режима замечательно работают на каждом из наших кластеров vSphere, остановимся на них подробнее.

Режим Virtual appliance (HotAdd)

Virtual appliance – рекомендуемый режим при развертывании бэкап-прокси в виде ВМ. Хосты ESXi, на которых развернуты бэкап-прокси, должны иметь доступ ко всем Datastore кластера vSphere, хранящим бэкапируемые ВМ. Суть режима заключается в том, что прокси монтирует к себе диски бэкапируемых ВМ (VMware SCSI HotAdd) и забирает с них данные как с собственных. Извлечение данных происходит с Datastore по сети хранения.

В нашем случае бэкап-прокси ВМ должна находиться на одном из хостов ESXi кластера vSAN, который мы бэкапим. Извлечение данных происходит по сети vSAN. Таким образом, для работы в режиме Virtual appliance в каждом кластере vSAN должно быть развернуто минимум по одному бэкап-прокси. Развернуть пару бэкап-прокси (например, в менеджмент-кластере) и бэкапить ими все кластеры vSAN не получится.

Плюсы Минусы
Быстрый, как правило, значительно быстрее NBD, особенно в случае полного бэкапа или больших инкрементов. По скорости может уступать только Direct storage access. Операция монтирования дисков (HotAdd) к прокси может занимать до 2 минут на диск. При инкрементном бэкапе небольших порций данных NBD может оказаться быстрее.
Утилизирует сеть хранения. Не грузит менеджмент-интерфейс и гипервизор. Прокси-ВМ потребляет часть ресурсов хоста. Иногда могут быть проблемы с удалением снапшотов.

Режим Network (NBD)

Является самым простым и универсальным режимом, подходит как для физических, так и для виртуальных бэкап-прокси. Извлечение данных, в отличие от предыдущих двух режимов, происходит не по сети хранения. Бэкап-прокси забирает данные ВМ, подключаясь к менеджмент-интерфейсу хостов ESXi, на которых они крутятся.

Такой подход имеет следующие недостатки:

  • Зачастую интерфейсы управления ESXi висят не на самых быстрых аплинках, как правило, это 1GbE
  • Даже если менеджмент-интерфейс будет иметь 10GbE порты, ESXi не отдаст прокси всю полосу целиком — он искусственно её ограничивает и выделяет под бэкапы лишь некоторую часть пропускной способности интерфейса
Плюсы Минусы
Простой и универсальный. Прокси может быть физическим и виртуальным. Как правило, значительно медленнее HotAdd, особенно на больших объёмах бэкапа и малом количестве параллельных задач (tasks).
Быстро стартует, отсутствие задержки на монтирование дисков. Нет проблем со снапшотами. Создает нагрузку (небольшую) на интерфейс управления и гипервизор.

При этом, многие источники утверждают, что NBD очень медленный на 1GbE, но на 10GbE может быть достаточно быстрым. Это мы обязательно проверим.

Программа тестирования

На описанной выше инфраструктуре необходимо выполнить бэкап тестовых ВМ и зафиксировать следующие показатели:

  • Нагрузка на CPU, %
  • Потребление RAM, GB
  • Нагрузка на сеть, Гбит/с
  • Производительность бэкапа, МБ/с
  • Время бэкапа, мм: сс

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

Показатели должны быть зафиксированы для Virtual appliance и Network режимов работы бэкап-прокси. Каждый раз должен выполняться полный бэкап, никаких инкрементов.

Таким образом, необходимо создать 4 задания бэкапа (backup job):

  • Для одной тестовой ВМ
  • Для двух тестовых ВМ
  • Для четырех тестовых ВМ
  • Для шести тестовых ВМ

В рамках тестирования необходимо:

  1. Последовательно прогнать все задания в одном режиме
  2. Удалить созданные бэкапы, чтобы не было инкрементов
  3. Повторить прогоны во втором режиме, каждый раз фиксируя показатели

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

Режим работы бэкап-прокси по умолчанию также выбирается автоматически. Поэтому, в настройках бэкап-прокси перед каждым прогоном вручную выставляем нужный транспортный режим.

Наиболее интересный показатель – средняя скорость или производительность бэкапа. Его можно увидеть в результатах выполнения задания в консоли VBR. Там же будет показано время выполнения бэкапа.

Кроме того, необходимо оценить нагрузку на бэкап-прокси в каждом из тестов. Показатели загруженности процессора, памяти и сети можно отслеживать с помощью инструментов гостевой ОС (Windows 2016) и на уровне VMware.

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

Veeam® рекомендует, чтобы количество параллельных задач не превышало количество процессорных ядер на прокси и репозитории. Рекомендуемый объем ОЗУ на репозитории – по 2ГБ на ядро, итого 12ГБ. Конфигурация инфраструктуры показывает, что все рекомендации соблюдены.

Скорость бэкапа и нагрузка в режиме Virtual Appliance (Hot Add)

Бэкап 1 ВМ

Нагрузка на Backup Proxy:

Показатель Значение
Нагрузка на CPU, % 55-95
Потребление RAM, GB 2-2,2
Нагрузка на сеть, Гбит/с 4,7-6,4

Скорость бэкапа:

Показатель Значение
Производительность бэкапа, МБ/с 709
Время бэкапа, мм: сс 06:35

Бэкап 2 ВМ

Нагрузка на Backup Proxy:

Показатель Значение
Нагрузка на CPU, % 70-100 (полка 100% с резкими короткими падениями до 70%)
Потребление RAM, GB 2,3-2,5
Нагрузка на сеть, Гбит/с 5-7,7

Скорость бэкапа:

Показатель Значение
Производительность бэкапа, МБ/с 816
Время бэкапа, мм: сс 10:03

Бэкап 4 ВМ

Нагрузка на Backup Proxy:

Показатель Значение
Нагрузка на CPU, % 100 (полка 100% с редкими небольшими падениями)
Потребление RAM, GB 3-3,5
Нагрузка на сеть, Гбит/с 5-8,2

Скорость бэкапа:

Показатель Значение
Производительность бэкапа, МБ/с 885
Время бэкапа, мм: сс 17:10

Бэкап 6 ВМ

Нагрузка на Backup Proxy:

Показатель Значение
Нагрузка на CPU, % 100 (полка 100% с редкими небольшими падениями)
Потребление RAM, GB 4-4,2
Нагрузка на сеть, Гбит/с 5-8,2

Скорость бэкапа:

Показатель Значение
Производительность бэкапа, МБ/с 888
Время бэкапа, мм: сс 24:42

Скорость бэкапа и нагрузка в режиме Network (NBD)

Бэкап 1 ВМ

Нагрузка на Backup Proxy:

Показатель Значение
Нагрузка на CPU, % 18-24
Потребление RAM, GB 1,9-2,1
Нагрузка на сеть, Гбит/с 1,2-1,8

Скорость бэкапа:

Показатель Значение
Производительность бэкапа, МБ/с 192
Время бэкапа, мм: сс 18:30

Бэкап 2 ВМ

Нагрузка на Backup Proxy:

Показатель Значение
Нагрузка на CPU, % 25-33
Потребление RAM, GB 2,2-2,4
Нагрузка на сеть, Гбит/с 1,5-2,5

Скорость бэкапа:

Показатель Значение
Производительность бэкапа, МБ/с 269
Время бэкапа, мм: сс 25:50

Бэкап 4 ВМ

Нагрузка на Backup Proxy:

Показатель Значение
Нагрузка на CPU, % 45-55
Потребление RAM, GB 2,8-3,5
Нагрузка на сеть, Гбит/с 2,8-4,5

Скорость бэкапа:

Показатель Значение
Производительность бэкапа, МБ/с 446
Время бэкапа, мм: сс 31:14

Бэкап 6 ВМ

Нагрузка на Backup Proxy:

Показатель Значение
Нагрузка на CPU, % 50-70
Потребление RAM, GB 3,5-4
Нагрузка на сеть, Гбит/с 3,5-5

Скорость бэкапа:

Показатель Значение
Производительность бэкапа, МБ/с 517
Время бэкапа, мм: сс 40:02

Сравнение производительности и нагрузки в режимах Virtual Appliance (HotAdd) и Network Mode (NBD)

Кол-во ВМ Скорость – HotAdd, МБ/с Скорость – NBD, МБ/с HotAdd/NBD
1 709 192 3,69
2 816 269 3,03
4 885 446 1,98
6 888 517 1,72
Кол-во ВМ Загрузка CPU – HotAdd, % Загрузка CPU – NBD, % HotAdd/NBD
1 55-95 18-24 3,06-3,96
2 70-100 25-33 2,8-3,03
4 100 45-55 1,82-2,22
6 100 50-70 1,43-2
Кол-во ВМ Загрузка RAM – HotAdd, GB Загрузка RAM – NBD, GB HotAdd/NBD
1 2-2,2 1,9-2,1 1,05
2 2,3-2,5 2,2-2,4 1,04-1,05
4 3-3,5 2,8-3,5 1-1,07
6 4-4,2 3,5-4 1,14-1,05
Кол-во ВМ Загрузка сети – HotAdd, Гб/с Загрузка сети – NBD, Гб/с HotAdd/NBD
1 4,7-6,4 1,2-1,8 3,56-3,92
2 5-7,7 1,5-2,5 3,08-3,33
4 5-8,2 2,8-4,5 1,79-1,82
6 5-8,2 3,5-5 1,43-1,64

Выводы по результатам тестирования

Показатели производительности бэкапа, полученные в результате тестирования, однозначно подтверждают факт значительного превосходства режима Virtual appliance в скорости по сравнению с режимом Network, особенно на малом количестве параллельных задач.

Напомню, что тесты для обоих режимов запускались в абсолютно идентичных условиях на одной и той же платформе. Пропускная способность сети также была одинаковой – интерфейсы управления, через которые прокси забирает данные в NBD-режиме, выдают 10 Гбит/с, как сеть vSAN для HotAdd-режима, никаких лимитов на полосу пропускания мы не устанавливали.

Очевидно, что ESXi действительно замедляет Veeam® и отдает ему лишь часть полосы в Network режиме, отсюда такие отличия в скорости бэкапа. Однако, с ростом количества потоков – одновременных задач бэкапа – Network режим ощутимо сокращает отставание.

Мы видим, что в режиме Virtual appliance уже на 4-х ВМ бэкап-прокси упирается в процессор, работать быстрее он не может, для 6-ти ВМ скорость бэкапа почти не изменилась. При этом скорость бэкапа 1-2 ВМ в этом режиме отстает незначительно, возможности бэкап-прокси и платформы используются по максимуму даже на малом количестве потоков.

В Network режиме, напротив, наблюдается значительный рост производительности с увеличением количества одновременных задач. При этом нагрузка на процессор бэкап-прокси значительно ниже, чем в HotAdd-режиме, даже на 6-ти потоках она не превышает 70%.

Расход оперативной памяти бэкап-прокси невелик и примерно одинаков в обоих режимах.

Нагрузка на сеть бэкап-прокси коррелирует со скоростью бэкапа, превышая её на ~10-17%. Видимо прокси забирает данные с ВМ-источников несколько быстрее, чем заливает на репозиторий, поскольку их нужно обработать.

Интересно понаблюдать за строкой Load на картинках с результатами выполнения джоб. Она показывает уровень нагрузки на различные элементы инфраструктуры бэкапа: источник, прокси, сеть, репозиторий.

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

В Network режиме узким местом всегда является источник, даже для одного потока. Видно, что остальные элементы инфраструктуры могут выдать больше, но ESXi им не дает.

Резюме

Тестирование подтвердило, что бэкап-прокси в исследованных транспортных режимах на практике ведёт себя именно так, как это предполагает теория.

ПО Veeam® показало себя весьма достойно:

  • В режиме HotAdd эффективно и полностью были утилизированы все возможности инфраструктуры
  • В режиме NBD производительность ожидаемо скромнее, но это не проблема Veeam®, а особенность сетевого стека ESXi

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

На данный момент нас вполне устраивает имеющаяся производительность бэкапа, мы понимаем как правильно её увеличить при появлении такой необходимости.

Статья впервые опубликована на ресурсе habr.com.

Реклама







Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

27/03/2019:   Оптимизация ИТ-инфраструктуры 2019
28/03/2019:  Эффективный ЦОД 2019
24/04/2019:  VMware vForum Online 2019

Быстрый переход:
VMware IT-Grad StarWind Veeam PowerCLI Offtopic Gartner Citrix VSAN 5nine Hardware VeeamON Nutanix vSphere RVTools Enterprise Security Code Cisco vGate Microsoft Cloud SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Teradici Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V Horizon vCloud Labs NSX vRNI vSAN HA Update Manager VCP Backup Tools VVols Workstation Workspace ONE Update UEM App Volumes DR Networking Cache Storage DRS VMworld Workspace vROPs DRS Fusion Lifecycle Visio SRM Log Insight Operations Manager SDDC Virtual Appliance OpenStack Forum PowerShell LSFS Client vCSA Datacenter Intel Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Performance Nested AWS XenDesktop VSA vNetwork SSO Host Client VMDK VTL iSCSI Whitepaper Appliance VUM V2V Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers Converter XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP Video SC VMM Certification VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Monitoring VPLEX UCS SDK Poster VSPP Receiver vMotion VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Helpdesk Troubleshooting VIC Upgrade VDS Bug Migration Director Stencils Memory API Android Graphics Diagram Air CLI Plugin DPM SIOC Flex Mac Open Source SSH VAAI Chargeback Heartbeat MSCS Ports SVMotion Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Сравнение Oracle VirtualBox и VMware Workstation.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Работа с дисками виртуальных машин VMware.

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2019, Александр Самойленко. Правила перепечатки материалов.