Provisioned space vmware что это
Что такое VMware и почему важна ее совместимость с SSD-накопителями
Привет, Хабр! Сегодня мы поговорим о виртуальных машинах, программном обеспечении VMware и накопителях Kingston, конечно же. В частности, разберем вопросы на тему “зачем нужна сертификация VMware Ready, какие из SSD-решений получают статус VMware Ready for Storage, и о чем это говорит?”. Начнем с самого банального.
Безусловно, аудитории Хабра знакома компания VMware, которая занимается разработкой программного обеспечения для виртуализации и организации облачных вычислений. Продукты VMware включают в себя средства виртуализации, управления сетью и безопасностью, программное обеспечение для ЦОД и хранения данных.
Первым таким продуктом стала программа VMware Workstation, которая позволяла любому пользователю установить на своем ПК одну или несколько виртуальных машин: то бишь имитацию аппаратной начинки компьютера в лице процессора, видеокарты, накопителей, оптических приводов и т.д. Эдакий компьютер в компьютере.
В рамках серверной среды VMware Workstation вкупе с установленным гипервизором VMware ESX позволяет запускать несколько виртуальных машин на одном физическом сервере, при этом каждая из ВМ может работать со своей операционной системой. Следовательно — на одном сервере могут быть активными сразу несколько разных ОС.
При этом все установленные ВМ совместно используют доступные ресурсы (сетевую карту и оперативную память), но работают независимо друг от друга. Основными продуктами в этом направлении является платформа VMware vSphere, гипервизор VMware ESX и VMware ESXi, VMware Server и vCenter Server. Впрочем, серверная виртуализация — не единственный тип абстрагирования от аппаратной реализации.
Типы виртуализации VMware
Все программы для виртуализации можно разделить на пять типов: серверная виртуализация, виртуализация десктопов, сетевая виртуализация, виртуализация хранилищ и ПО для управления облачными средами. О виртуализации в серверной среде мы уже немного рассказали выше, а вот что подразумевается под остальными типами?
Виртуализация десктопов и облачные среды
Виртуализация десктопов, которую иногда называют инфраструктурой виртуальных десктопов (VDI), — это такой тип виртуализации, при котором ОС настольных ПК работает как виртуальная машина на физическом сервере с другими виртуальными десктопами. Обработка нескольких виртуальных рабочих мест происходит на одном или нескольких физических серверах, обычно – в централизованном ЦОД. Копия ОС и приложений, которые использует каждый конечный пользователь, обычно кэшируется в памяти, как один образ на физическом сервере.
Пакет VMware Horizon позволяет организациям запускать рабочие столы Windows в центре обработки данных или в облачных сервисах на базе VMware Cloud, что устраняет необходимость размещения и управления десктопами с офисного рабочего места, централизует управление пользовательской средой и обеспечивает ее безопасность.
При развертывании данного типа виртуализации используется ПО для выполнения сетевых функций путем отделения виртуальных сетей от базового сетевого оборудования. Как только вы начнете использовать виртуализацию сети, физическая сеть будет использоваться только для пересылки пакетов, поэтому все управление осуществляется с помощью виртуальных или программных коммутаторов. Поставщиками сетевой виртуализации являются внутренние виртуальные коммутаторы гипервизора. Кроме того, сторонние поставщики, такие как Cisco и IBM, разработали виртуальные коммутаторы, которые могут использоваться гипервизорами, такими как ESXi.
Как мы уже отмечали, для каждого типа виртуализации компания VMware предлагает определенный набор софта. Например, если мы говорим о хранении данных, то следует принимать во внимание такие решения, как VMware vSAN и VMware Site Recovery Manager (SRM). VMware vSAN — программная функция хранения, встроенная в гипервизор ESXi и интегрированная с vSphere. Она объединяет дисковое пространство от нескольких хостов ESXi и выделяет его с помощью интеллектуальных политик, таких как ограничения защиты, тонкое выделение ресурсов и кодирование стирания. А еще эта опция интегрируется с функцией vSphere High Availability, обеспечивая повышенную производительность вычислений и самого хранилища.
VMware Site Recovery Manager (SRM) предназначен для управления аварийным восстановлением, что позволяет администраторам создавать планы восстановления, которые автоматически выполняются в случае сбоя, а также автоматически организовывать аварийное переключение и восстановление виртуальных машин. SRM также интегрируется с VMware NSX (инструмент управления сетевыми операциями) для сохранения сетевых политик и политик безопасности на виртуальных машинах, перемещенных на новые физические сервера.
Зачем нужна сертификация VMware Ready
Начнем с того, что сертификация VMware Ready означает высокий уровень одобрения для продуктов, созданных партнерами компании VMware. Нетрудно догадаться, что Kingston Digital входит в их число: в частности, является членом “Партнерского технологического альянса VMware”. Участники этого альянса разрабатывают свои устройства в соответствии со стандартами VMware и предоставляют их техническим специалистам компании, которые проводят различные сертификационные тесты.
По итогам проверок, сервера, компьютеры, устройства хранения и другие устройства, отвечающие сертификационным требованиям, получают заветный логотип VMware Ready. Кроме того, в дальнейшем эти продукты поддерживаются как со стороны компании-партнера, так и со стороны VMware. Подробную информацию о твердотельных накопителях Kingston из линейки, которые прошли сертификацию VMware можно найти и на портале VMware Solution Exchange (VSX). Там же размещаются обновления ПО для пользователей “железа” сертифицированного VMware.
Возвращаясь к “Партнерскому технологическому альянсу VMware”, стоит упомянуть о том, что участие в нем позволяет клиентам быстро находить сертифицированное оборудование партнеров, не занимаясь точечным и индивидуальным подбором компонентов, которые в итоге могут не обеспечить ожидаемую производительность. Не в последнюю очередь это способствует росту продаж накопителей Kingston. Только за первое полугодие 2019 года компании удалось реализовать более 13,3 миллиона твердотельных накопителей (по исследованиям TrendFocus). Если говорить о глобальных поставках, хорошие продажи обеспечили Kingston третье место в списке лидеров по реализации SSD-накопителей после Samsung и Western Digital.
Какие SSD-накопители обладают статусом VMware Ready
Применительно к накопителям Kingston серверного класса, сертификацию VMware Ready for Storage имеют твердотельные SATA-накопители Kingston DC500R и Kingston DC500M, рекомендованные для использования в ЦОД. Как мы уже отметили выше, присвоенный данным SSD-решениям статус говорит о том, что DC500R и DC500M получили полное одобрение от специалистов VMware, успешно пройдя все тесты.
Именно эта сертификация позволяет представителям Kingston Digital говорить о том, что при использовании SSD DC500R и DC500M в среде vSAN и серверах vSphere можно ожидать высокой производительности при выполнении большого количества операций чтения данных и смешанных нагрузках. К слову, для прохождения сертификации серверные накопители настраиваются в соответствии с требованиями от VMware и в итоге обеспечивают высокую пропускную способность, кол-во IPOS, а также минимальную задержку в 99% сценариев.
Как итог: сертифицированные SSD Kingston с чистой совестью можно отнести к классу высокопроизводительных ускорителей для виртуализированных рабочих нагрузок смешанного типа в рамках серверной среды. Также они позволяют облачным службам работать с максимальной эффективностью и предоставляют пользователям очень быстрый доступ к данным. Собственно, от них это и требуется.
Для получения дополнительной информации о продуктах Kingston Technology обращайтесь на официальный сайт компании.
Технологии хранения данных VMware vSphere 6. Часть 1 – Old School
VASA – vSphere API for Storage Awareness / Набор API для отслеживания хранилищ
VASA это набор API, предоставляемый VMware и предназначенный для разработки провайдеров хранилищ (storage providers) для инфраструктуры vSphere. Storage provider-ы это программные компоненты, предоставляемые vSphere или разрабатываемые 3-ей стороной, предназначенные для интеграции (отслеживания) хранилищ (программных и аппаратных СХД) и фильтров ввода-вывода (VAIO) с инфраструктурой vSphere.
Storage provider (VASA-провайдер) нужен для того, чтобы виртуальная инфраструктура:
VASA-провайдеры сторонних разработчиков используются как сервисы отслеживания информации о данном хранилище для vSphere. Такие провайдеры требуют отдельной регистрации и установки соответствующих плагинов.
Встроенные storage provider-ы являются компонентами vSphere и не требуют регистрации. Так, например, провайдер для Virtual SAN автоматически регистрируется при её развертывании.
vSphere посредством storage provider собирает информацию о хранилищах (характеристики, статус, возможности) и сервисах данных (фильтрах VAIO) во всей инфраструктуре, данная информация становится доступной для мониторинга и принятия решений через vSphere Web Client.
Информацию, собираемую VASA-провайдерами, можно разделить на 3 категории:
К одному storage provider-у могут одновременно обращаться несколько серверов vCenter. Один vCenter может одновременно взаимодействовать с множеством storage provider-ов (несколько массивов и фильтров ввода-вывода).
VAAI — vSphere API for Array Integration / Набор API для интеграции массива
API данного типа можно разделить на 2 категории:
Storage Hardware Acceleration (VAAI для Hardware Acceleration)
Данный функционал обеспечивает интеграцию хостов ESXi и совместимых СХД, позволяет перенести выполнение отдельных операций по сопровождению ВМ и хранилища с гипервизора (хоста ESXi) на массив (СХД), благодаря чему увеличивается скорость выполнения данных операций, при этом снижается нагрузка на процессор и память хоста, а также на сеть хранения данных.
Storage Hardware Acceleration поддерживается для блочных (FC, iSCSI) и файловых (NAS) СХД. Для работы технологии необходимо, чтобы блочное устройство поддерживало стандарт T10 SCSI либо имело VAAI-плагин. Если блочный массив поддерживает стандарт T10 SCSI, то VAAI-плагин для поддержки Hardware Acceleration не нужен, все заработает напрямую. Файловые хранилища требуют наличия отдельного VAAI-плагина. Разработка VAAI-плагинов ложится на плечи производителя СХД.
В целом VAAI для Hardware Acceleration позволяют оптимизировать и переложить на массив следующие процессы:
Пояснение
VMFS является кластерной ФС (файловая система) и поддерживает параллельную работу нескольких хостов ESXi (гипервизоров) с одним LUN-ом (который под неё отформатирован). На LUN-е с VMFS может размешаться множество файлов ВМ, а также метаданные. В обычном режиме, пока не вносятся изменения в метаданные, все работает параллельно, множество хостов обращается в VMFS, никто никому не мешает, нет никаких блокировок.
Если Hardware Acceleration (VAAI) не поддерживаются блочным устройством, то для внесения изменений в метаданные на VMFS каким-либо хостом приходится использовать команду SCSI reservation, LUN при этом передается в монопольное использование данному хосту, для остальных хостов на момент внесения изменений в метаданные этот LUN становится недоступен, что может вызвать ощутимую потерю производительности.
Метаданные содержат информацию о самом разделе VMFS и о файлах ВМ. Изменения метаданных происходят в случае: включения/выключения ВМ, создания фалов ВМ (создание ВМ, клонирование, миграция, добавление диска, создание снапшота), удаление файлов (удаление ВМ или дисков ВМ), смена владельца файла ВМ, увеличение раздела VMFS, изменение размера файлов ВМ (если у ВМ «тонкие» диски или используются снапшоты – это происходит постоянно).
Hardware Acceleration для VMFS не отработает и нагрузка ляжет на хост если:
Multipathing Storage APIs — Pluggable Storage Architecture (PSA) / Набор API для мультипафинга
Для управления мультипафингом гипервизор ESXi использует отдельный набор Storage APIs называемый Pluggable Storage Architecture (PSA). PSA – открытый модульный каркас (framework), координирующий одновременную работу множества плагинов мультипафинга (multipathing plug-ins – MPPs). PSA позволяет производителям разрабатывать (интегрировать) собственные технологии мультипафинга (балансировки нагрузки и восстановления после сбоя) для подключения своих СХД к vSphere.
PSA выполняет следующие задачи:
NMP в свою очередь также является расширяемым модулем, управляющим двумя наборами плагинов: Storage Array Type Plug-Ins (SATPs), and Path Selection Plug-Ins (PSPs). SATPs и PSPs могут быть встроенными плагинами VMware или разработками сторонних производителей. При необходимости разработчик СХД может создать собственный MPP для использования в дополнение или вместо NMP.
SATP отвечает за восстановление пути посте сбоя (failover): мониторинг состояния физических путей, информирование об изменении их состояния, переключение со сбойного пути на рабочий. NMP предоставляет SATPs для всех возможных моделей массивов, поддерживаемых vSphere, и осуществляет выбор подходящего SATP.
PSP отвечает за выбор физического пути передачи данных. NMP предлагает 3 встроенных варианта PSP: Most Recently Used, Fixed, Round Robin. Основываясь на выбранном для массива SATP, модуль NMP делает выбор варианта PSP по умолчанию. При этом vSphere Web Client дает возможность выбрать вариант PSP вручную.
Принцип работы вариантов PSP:
Виртуализация vSphere, Hyper-V, Xen и Red Hat
Более 5540 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes
Как конфигурировать SDRS Anti-Affinity правила с PowerCLI – Часть 3
Это Часть 3 в серии о Storage DRS. В предыдущей части мы говорили о том как создавать и удалять SDRS Anti-Affinity правила. Чтобы закрыть тему, нам осталось редактировать/реконфигурировать существующие правила. Логично предположить, что это будет функция Set-SdrsAntiAffinityRule.
Таги: SDRS, PowerCLI, vSphere, VMware, Storage
Как конфигурировать Storage DRS кластеры с PowerCLI – Часть 1.
Несмотря на растущую популярность технологии VMware vSAN, большинство крупных предприятий по-прежнему частично или полностью продолжают работать с общими хранилищами (shared storage). Есть достаточно PowerCLI командлетов для конфигурирования большинства аспектов HA/DRS кластеров, однако для SDRS кластеров выбор не велик.
Таги: VMware, PowerCLI, SDRS, Storage
Почему Storage DRS не поддерживается для VVols в VMware vSphere?
Для ответа на этот вопрос надо рассмотреть, как работает традиционная архитектура хранилищ, которая была до VVols и кластеров Virtual SAN. Обычный дисковый массив или хост можно представить набором носителей двух типов (HDD и Flash), которые дают суммарно некоторую емкость.
Все это вызвано сложной структурой хранилищ, которая «прячет» виртуальную машину от дискового массива, представляя ее в конечном счете как набор дисковых блоков, ничем не отличающихся таковых при подключении физических серверов.
То есть все операции по балансировке данных виртуальных машин (на уровне дисковых объектов VVols) передаются на сторону СХД, которая лучше знает, как правильно распределять данные и обеспечивать необходимый уровень обслуживания на базе политик (Storage Policies), привязанных к ярусам. Это, конечно же, требует некоторой работы со стороны производителей систем хранения, зато избавляет от забот саму VMware, которая универсализовала технологию VVols и средства работы с ней.
Таги: VMware, VVols, Storage, SDRS, vSphere
Duncan и Frank, известные своими изысканиями в сфере механизмов отказоустойчивости (HA) и балансировки нагрузки (DRS) в виртуальной инфраструктуре VMware vSphere, опубликовали пару интересных материалов, касающихся настройки среды vCloud Director и механизма Storage DRS.
Как вы знаете, в настройках кластера хранилищ (Datastore Cluster) есть галка, которая определяет, будут ли виртуальные диски VMDK машин обязательно находиться на одном хранилище (Datastore) при миграции средствами механизма Storage DRS:
Таги: VMware, SDRS, Storage DRS, VMDK, Storage, vSphere
Учет производительности виртуальных хранилищ механизмом Storage DRS в VMware vSphere 5.1.
Не так давно мы писали про то, как работает механизм динамического выравнивания нагрузки на виртуальные хранилища VMware Storage DRS. Напомним, что он работает на базе 2-х параметров хранилищ:
Например, бесполезна (с точки зрения производительности) будет миграция с Datastore1 на Datastore2:
Раньше этот факт не учитывался механизмом SDRS в vSphere 5.0, что приводило к бесполезным миграциям в автоматическом режиме. Теперь ситуация изменилась к лучшему в версии vSphere 5.1.
Делается это следующим образом: SIOC запускает тестовую рабочую нагрузку на случайно выбранном Datastore1, измеряет latency, а потом отдельно от него запускает нагрузку на другом Datastore2 и также смотрит на latency:
Это нужно для установления базового уровня производительности для этих виртуальных хранилищ. Потом SIOC запускает нагрузку одновременно на 2 этих хранилища и смотрит, что происходит с latency:
Если оба этих хранилища физических расположены на одних и тех же дисковых устройствах (как в нашем случае), то измеряемые latency в данном случае возрастут, что говорит о взаимной корреляции данных хранилищ в плане производительности.
Узнав про этот факт, Storage DRS не будет генерировать рекомендации по перемещению виртуальных машин между хранилищами Datastore1 и Datastore2:
Однако эти рекомендации перестанут генерироваться только на базе производительности, на базе заполненности хранилищ такие рекомендации останутся.
Таги: VMware, vSphere, SDRS, Performance, Storage vMotion, SVMotion, ESXi, Storage
Frank Denneman опять написал интересную статью. Оказывается у механизма VMware Storage DRS, который производит балансировку виртуальных машин по хранилищам кластера SDRS, есть механизм задания допустимого уровня over-commitment для хранилища при миграции ВМ на тонких дисках.
Как вы знаете, у тонких VMDK-дисков (Thin Disks) виртуальных машин есть 2 параметра:
Разность этих двух парметров есть значение IdleMB, отражающее объем, на который виртуальный диск еще может вырасти. В расширенных настройках Storage DRS можно задать параметр PercentIdleMBinSpaceDemand, который определяет, сколько процентов от IdleMB механизм SDRS прибавляет к Allocated Space при выдаче и применении рекомендаций по размещению виртуальных машин на хранилищах кластера.
Рассмотрим на примере. Пусть максимальный размер диска VMDK составляет 6 ГБ при Allocated Space в 2 ГБ. Допустим мы задали PercentIdleMBinSpaceDemand = 25%. Тогда мы получим такую картину:
Таким образом, при размещении виртуальной машины на хранилище механизм Storage DRS будет считать, что ВМ занимает не 2 ГБ дискового пространства, а 2+0.25*4 = 3 ГБ. Ну и увидев такую машину на 10 ГБ-хранилище, механизм SDRS, при расчете выравнивания хранилищ по заполненности, будет считать что она занимает 3 ГБ, и свободно осталось лишь 7 ГБ.
Регулируя эту настройку можно добиться различных коэффициентов консолидации тонких VMDK-дисков машин на хранилищах. Ну и очевидно, что значение параметра PercentIdleMBinSpaceDemand равное 100% приведет к тому, что тонкие диски при размещении будут учитываться как их обычные flat-собратья.
Таги: VMware, Storage, SDRS, DRS, vSphere, ESXi, Blogs, VMDK
Работоспособность VMware vSphere Storage DRS (SDRS) с возможностями дисковых массивов, функциональностью vSphere 5 и других продуктов.
Недавно мы уже писали о том, как работает технология балансировки нагрузки на хранилища VMware Storage DRS (там же и про Profile Driven Storage). Сегодня мы посмотрим на то, как эта технология работает совместно с различными фичами дисковых массиов, а также функциями самой VMware vSphere и других продуктов VMware.
Для начала приведем простую таблицу, из которой понятно, что поддерживается, а что нет, совместно с SDRS:
Возможность | Поддерживается или нет | Рекомендации VMware по режиму работы SDRS |
---|---|---|
Снапшоты на уровне массива (array-based snapshots) | Поддерживается | Ручное применение рекомендаций (Manual Mode) |
Дедупликация на уровне массива (array-based deduplication) | Поддерживается | Ручное применение рекомендаций (Manual Mode) |
Использование «тонких» дисков на уровне массива (array-based thin provisioning) | Поддерживается | Ручное применение рекомендаций (Manual Mode) |
Использование функций автоматического ярусного хранения (array-based auto-tiering) | Поддерживается | Ручное применение рекомендаций (Manual Mode), только для распределения по заполненности хранилищ (auto-tiering по распределению нагрузки сам решит, что делать) |
Репликация на уровне массива (array-based replication) | Поддерживается | Ручное применение рекомендаций (Manual Mode) |
Тома RDM (Raw Device Mappings) | Поддерживается | Автоматическое применение рекомендаций (Fully Automated Mode) |
Технология репликации на уровне хоста (VMware vSphere Replication) | Не поддерживается | —— |
Снапшоты виртуальных машин (VMware vSphere Snapshots) | Поддерживается | Автоматическое применение рекомендаций (Fully Automated Mode) |
Использование «тонких» дисков на уровне виртуальных хранилищ (VMware vSphere Thin Provisioning) | Поддерживается | Автоматическое применение рекомендаций (Fully Automated Mode) |
Технология связанных клонов (VMware vSphere Linked Clones) | Не поддерживается | —— |
«Растянутый» кластер (VMware vSphere Storage Metro Cluster) | Поддерживается | Ручное применение рекомендаций (Manual Mode) |
Хосты с версией ПО, младше чем vSphere 5.0 | Не поддерживается | —— |
Использование совместно с продуктом VMware vSphere Site Recovery Manager | Не поддерживается | —— |
Использование совместно с продуктом VMware vCloud Director | Не поддерживается | —— |
Комментарии к таблице:
Таги: VMware, SDRS, Storage DRS, Storage, ESXi, SRM, View, VMDK
Одним из ключевых нововведений VMware vSphere 5, безусловно, стала технология выравнивания нагрузки на хранилища VMware vSphere Storage DRS (SDRS), которая позволяет оптимизировать нагрузку виртуальных машин на дисковые устройства без прерывания работы ВМ средствами технологии Storage vMotion, а также учитывать характеристики хранилищ при их первоначальном размещении.
Основными функциями Storage DRS являются:
Ключевыми понятими Storage DRS и функции Profile Driven Storage являются:
Как и VMware DRS, Storage DRS может работать как в ручном, так и в автоматическом режиме. То есть Storage DRS может генерировать рекомендации и автоматически применять их, а может оставить их применение на усмотрение пользователя, что зависит от настройки Automation Level.
С точки зрения балансировки по вводу-выводу Storage DRS учитывает параметр I/O Latency, то есть round trip-время прохождения SCSI-команд от виртуальных машин к хранилищу. Вторым значимым параметром является заполненность Datastore (Utilized Space):
Параметр I/O Latency, который вы планируете задавать, зависит от типа дисков, которые вы используете в кластере хранилищ, и инфраструктуры хранения в целом. Однако есть некоторые пороговые значения по Latency, на которые можно ориентироваться:
То есть, проще говоря, SDRS может переместить в горячем режиме диск или всю виртуальную машину при наличии большого I/O Latency или высокой степени заполненности хранилища на альтернативный Datastore.
Администратор может просматривать и применять предлагаемые рекомендации Storage DRS из специального окна:
Когда администратор нажмет кнопку «Apply Recommendations» виртуальные машины за счет Storage vMotion поедут на другие хранилища кластера, в соответствии с определенным для нее профилем (об этом ниже).
Аналогичным образом работает и первичное размещение виртуальной машины при ее создании. Администратор определяет Datastore Cluster, в который ее поместить, а Storage DRS сама решает, на какой именно Datastore в кластере ее поместить (основываясь также на их Latency и заполненности).
При этом, при первичном размещении может случиться ситуация, когда машину поместить некуда, но возможно подвигать уже находящиеся на хранилищах машины между ними, что освободит место для новой машины (об этом подробнее тут):
Выбирая Storage Profile, администратор будет всегда уверен, что виртуальная машина попадет на тот Datastore в рамках выбранного кластера хранилищ, который создан поверх дисковых устройств с требуемой производительностью. Профиль хранилищ создается в отельном интерфейсе VM Storage Profiles, где выбираются хранилища, предоставляющие определенный набор характеристик (уровень RAID, тип и т.п.), которые платформа vSphere получает через механизм VASA (VMware vStorage APIs for Storage Awareness):
Ну а дальше при создании ВМ администратор определяет уровень обслуживания и характеристики хранилища (Storage Profile), а также кластер хранилища, датасторы которого удовлетворяют требованиям профиля (они отображаются как Compatible) или не удовлетворяют им (Incompatible). Концепция, я думаю, понятна.
Регулируются профили хранилищ для виртуальной машины в ее настройках, на вкладке «Profiles», где можно их настраивать на уровне отдельных дисков:
На вкладке «Summary» для виртуальной машины вы можете увидеть ее текущий профиль и соответствует ли в данный момент она его требованиям:
Также можно из оснастки управления профилями посмотреть, все ли виртуальные машины находятся на тех хранилищах, профиль которых совпадает с их профилем:
Естественно, у Storage DRS есть и свои ограничения. Основные из них приведены на картинке ниже:
И последнее. Технологии VMware DRS и VMware Storage DRS абсолютно и полностью соместимы, их можно использовать совместно.
Таги: VMware, Storage, DRS, SDRS, vSphere, ESXi, Enterprise, Обучение, SVMotion
Вебинары VMC о виртуализации:
Постер 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: