Vmware Vim что это такое

Обновлено: 21.11.2024

Интерфейс com.vmware.vim.binding.vim.VirtualDiskManager

Расширяет java.lang.Object

Этого класса нет в метаданных подключаемого модуля. Его использование может работать и может зависеть от настройки устройства vRO.

Атрибуты

Методы

< tr> < tr> < td nowrap>com.vmware.vim.binding.vim.Task
Имя Возвращает
consolidateDisks( com.vmware.vim.binding.vim.VirtualDiskManager$DiskUnit[] , логическое значение ) com.vmware.vim.binding.vim.Task
copyVirtualDisk( String , com.vmware.vim.binding.vim.Datacenter , Строка, com.vmware.vim.binding.vim.Datacenter, com.vmware.vim.binding.vim.VirtualDiskManager$VirtualDiskSpec, логическое значение) com.vmware.vim.binding.vim.Task
createChildDisk(String, com.vmware.vim.binding.vim.Datacenter, String, com.vmware.vim.binding.vim.Datacenter, boolean) com.vmware.vim.binding.vim.Task
createVirtualDisk( String , com.vmware.vim.binding.vim.Datacenter , com.vmware.vim .binding.vim.VirtualDiskManager$VirtualDiskSpec ) com.vmware.vim.binding.vim.Task
defragmentVirtualDisk( String , com.vmware. vim.binding.vim.Datacenter ) com.vmware.vim.binding.vim.Task
deleteVirtualDisk( String , com.vmware.vim.binding.vim.Datacenter ) com.vmware.vim.binding.vim.Task
disableUPIT(String, com.vmware.vim.binding.vim.Datacenter, String, boolean) com.vmware.vim.binding.vim.Task
eagerZeroVirtualDisk( String , com.vmware.vim.binding.vim.Datacenter ) com.vmware.vim.binding.vim.Task
enableUPIT( String , com.vmware.vim.binding.vim.Datacenter ) com.vmware.vim.binding.vim.Task
extendVirtualDisk(String, com.vmware.vim.binding.vim.Datacenter, Number, boolean) com.vmware.vim.binding.vim.Task
importUnmanagedSnapshot( String , com.vmware.vim.binding.vim.Datacenter , String ) void
inflateVirtualDisk ( String , com.vmware.vim.binding.vim.Datacenter ) com.vmware.vim.binding.vim.Task
moveVirtualDisk(Строка, com.vmware.vim.binding.vim.Datacenter, Строка, com.vmware.vim.binding.vim.Datacenter, логическое значение, com.vmware.vim.binding.vim.vm.ProfileSpec[]) com.vmware.vim.binding.vim.Task
optimizeEagerZeroVirtualDisk(String, com.vmware.vim.binding.vim.Datacenter)
queryObjectInfo( String , com.vmware.vim.binding.vim.Datacenter , boolean ) com.vmware.vim.binding.vim.Task
queryObjectTypes() String[]
queryVirtualDiskFragmentation( String , com.vmware.vim.binding.vim.Datacenter ) Number
queryVirtualDiskGeometry( String , com.vmware.vim.binding.vim.Datacenter ) com.vmware.vim.binding.vim.host.DiskDimensions$Chs
queryVirtualDiskInfo (Строка, com.vmware.vim.binding.vim.Datacenter, логическое значение) com.vmware.vim.binding.vim.Task
queryVirtualDiskUuid( String , com.vmware.vim.binding.vim.Datacenter ) String
releaseManagedSnapshot( String , com.vmware.vim.binding.vim.Datacenter ) void
reparentDisks( com.vmware.vim.binding. vim.VirtualDiskManager$ReparentSpec[] ) com.vmware.vim.binding.vim.Task
revertToChildDisk( String , com.vmware.vim .binding.vim.Datacenter , String , com.vmware.vim.binding.vim.Datacenter ) com.vmware.vim.binding.vim.Task
setVirtualDiskUuid( String , com.vmware.vim.binding.vim.Datacenter , String ) void
shrinkVirtualDisk( String , com .vmware.vim.binding.vim.Datacenter, логическое значение) com.vmware.vim.binding.vim.Task
zeroFillVirtualDisk( String , com.vmware.vim.binding.vim.Datacenter ) com.vmware.vim.binding.vim.Task

Вернул

Упоминается в

2022 – Д-р Руурд и Флорес из ITQ. Не хватает плагина? Комментарии? Свяжитесь с доктором Руурдом в Твиттере или блоге

Функции VIM в vCloud NFV формируют три компонента: vCenter Server Appliance, NSX Manager и vCloud Director для поставщиков услуг. vCloud Director — это компонент VIM верхнего уровня. Он использует vCenter Server Appliance и NSX Manager для выполнения функций VIM. vCloud Director, vCenter Server Appliance и NSX Manager расположены в иерархическом порядке, что упрощает разделение ролей и обязанностей в сетях CSP и повышает общую отказоустойчивость системы.

Рис. 1. Иерархия VIM в VMware vCloud NFV

VMware vCloud Director

vCloud Director — это уровень абстракции, работающий поверх других компонентов диспетчера виртуализированной инфраструктуры, vCenter Server и NSX Manager. vCloud Director создает безопасные виртуальные среды с несколькими арендаторами, объединяя ресурсы виртуальной инфраструктуры в виртуальные центры обработки данных и предоставляя их пользователям через веб-порталы и программные интерфейсы в виде полностью автоматизированных сервисов на основе каталогов.

Основным понятием в vCloud Director является арендатор. Арендатор — это логически изолированная конструкция, представляющая клиента, отдел, сетевую функцию или службу, используемая для развертывания рабочих нагрузок VNF. vCloud Director изолирует административные границы от арендаторов NFVI. Таким образом, потребление ресурсов рабочей нагрузки VNF отделено от других рабочих нагрузок VNF, даже если эти VNF могут использовать одни и те же ресурсы.

Объединенные ресурсы, используемые vCloud Director, сгруппированы в два уровня абстракции:

Виртуальные центры обработки данных поставщика. Виртуальный центр обработки данных поставщика (PvDC) объединяет вычислительные ресурсы и ресурсы памяти одного пула ресурсов vCenter Server с ресурсами хранения одного или нескольких хранилищ данных, доступных для этого пула ресурсов. Эта конструкция является самой высокой в ​​иерархии каталога ресурсов vCloud Director.

Организация виртуальных центров обработки данных. Виртуальный центр обработки данных организации (OvDC) предоставляет ресурсы арендатору NFVI и отделен от виртуального центра обработки данных поставщика. OvDC предоставляют среду, в которой можно хранить, развертывать и эксплуатировать виртуальные системы. Они также предоставляют хранилище для виртуальных носителей, таких как образы ISO, шаблоны VNF и шаблоны компонентов VNF.

vCloud Director реализует открытый и общедоступный vCloud API, который обеспечивает совместимость, совместимость и программную расширяемость для поставщиков сетевого оборудования (NEP) и их диспетчеров VNF. Возможности vCloud Director можно расширить для создания адаптеров для внешних систем, включая OSS/BSS.

Сервер VMware vCenter

VMware vCenter Server ® — это интерфейс централизованного управления вычислительными ресурсами и ресурсами хранения в NFVI. Он обеспечивает инвентаризацию выделенных виртуальных и физических ресурсов, управляет информацией, связанной с инвентаризацией, и ведет обзор каталогов виртуальных ресурсов. vCenter Server также собирает данные о производительности, емкости и состоянии своих объектов инвентаризации. vCenter Server предоставляет программные интерфейсы другим компонентам управления для детального контроля, эксплуатации и мониторинга базовой виртуальной инфраструктуры.

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

Диспетчер VMware NSX

NSX Manager — это основной интерфейс плоскости управления для настройки сетевых ресурсов в NFVI. NSX Manager отвечает за развертывание и управление виртуализированными сетевыми компонентами, а также за функции, используемые для поддержки создания сетевых служб с помощью VNF. К таким функциям относятся сетевые сегменты, маршрутизация, брандмауэр, балансировка нагрузки и т. д.

Рабочая группа по управлению и организации Европейского института телекоммуникационных стандартов (ETSI MANO) определяет архитектуру управления и оркестрации виртуализации сетевых функций (NFV-MANO) как состоящую из трех основных функциональных блоков: диспетчер виртуальной инфраструктуры (VIM), диспетчер VNF, и оркестратор NFV.

VIM отвечает за контроль и управление вычислительными ресурсами инфраструктуры NFV (NFVI), хранилищем и сетевыми ресурсами, обычно в пределах домена инфраструктуры одного оператора. VIM — это особая часть инфраструктуры MANO, но она может иметь несколько экземпляров в сети. Есть два основных типа экземпляров. Некоторые управляют несколькими типами ресурсов NFVI или могут быть специализированы для работы с определенным типом.

В ноябре 2014 года рабочая группа NFV-MANO закрылась, и была создана рабочая группа ETSI по интерфейсам и архитектуре NFV (IFA), которая взяла на себя работу над стандартами MANO.

Сопоставление OSM с архитектурой ETSI NFV MANO. Источник: ОСМ

Функции VIM

Блок VIM отвечает за управление виртуализированной инфраструктурой решения на основе NFV, ведение инвентаризации распределения виртуальных ресурсов по физическим ресурсам. Это позволяет координировать выделение, обновление, выпуск и освобождение ресурсов NFVI, а также оптимизировать их использование.

Блок VIM поддерживает управление графами переадресации VNF путем организации виртуальных ссылок, сетей, подсетей и портов. Архитектура VIM также управляет групповыми политиками безопасности для обеспечения контроля доступа.

Блок VIM также управляет репозиторием аппаратных ресурсов NFVI (вычисления, хранилища, сети) и программных ресурсов (гипервизоры), а также определяет возможности и функции ресурса для оптимизации его использования.

Блок VIM также выполняет другие функции, такие как сбор информации о производительности и ошибках с помощью уведомлений, управление образами программного обеспечения (добавление, удаление, обновление, запрос, копирование) по запросу других функциональных блоков NFV-MANO, а также управление каталогами виртуализированные ресурсы, которые можно использовать из NFVI. Южные интерфейсы VIM взаимодействуют с сетевыми контроллерами для выполнения этих функций.

Проект ETSI с открытым исходным кодом MANO добавил функциональность к своему компоненту VIM в ходе своих выпусков. К ним относятся повышенная совместимость между компонентами, использование OpenVIM для его возможностей в оркестровке ресурсов, создание подключаемого модуля, улучшенная обработка ошибок, интеграция нескольких VIM, а также управление сбоями и производительностью сетевых служб.

Важность VIM

VIM имеют решающее значение для реализации бизнес-преимуществ, обеспечиваемых NFV, поскольку они координируют физические ресурсы, необходимые для предоставления сетевых услуг. Это особенно заметно для поставщиков инфраструктуры как услуги (IaaS). Поставщики IaaS должны обеспечить бесперебойную работу своих серверов, сетей и хранилищ с пользовательским оборудованием в месте нахождения клиента. Чтобы обеспечить эту плавность, VIM динамически распределяет ресурсы в зависимости от того, что необходимо. Некоторые считают это морфингом традиционной ОС, но он не работает с одним узлом. Вместо этого он одновременно собирает информацию со многих компьютеров и использует эту информацию для функций управления.

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

Рынок ВИМ

Многие поставщики предлагают VIM. Cisco предлагает продукт VIM, который управляет программным и аппаратным обеспечением NFVI клиента. Продукт способен распределять физические ресурсы, в то время как стандарт ETSI давал VIM только контроль над виртуальными ресурсами. Компания также утверждает, что ее продукт VIM минимизирует площадь поверхности для атак.

Большинство поставщиков основывают свои продукты VIM на технологиях VMware или OpenStack. VMware предлагает vSphere — проприетарный, но хорошо зарекомендовавший себя на рынке VIM. VMware может использовать свой VIM, чтобы помочь клиентам преобразовать существующие ИТ-инфраструктуры в общедоступные или гибридные облака.

Компания VMware тесно сотрудничала с проектом ETSI под названием Open Source MANO (OSM), чтобы «использовать синергию между стандартизацией и подходами с открытым исходным кодом». Стек, над которым работает OSM, соответствует моделям ETSI NFV. Первый выпуск OSM датируется октябрем 2016 года и содержит технический обзор его работы.

А еще есть OpenStack. Некоторые отраслевые пользователи отмечают, что OpenStack предоставляет больше функциональных возможностей, чем простые службы VIM. Но легко понять, почему OpenStack развертывается как VIM: он контролирует пулы вычислительных, хранилищ и сетевых ресурсов, которыми можно управлять через OpenStack API. Многие поставщики создали собственные реализации OpenStack, включая Red Hat, Mirantis, Oracle и VMware.

Исходя из популярности OpenStack и функций, предоставляемых VIM, становится ясно, что роль администратора виртуальной инфраструктуры является важнейшим компонентом архитектуры NFV-MANO. Необходимо осознать повышенную ценность, которую обещают решения на основе NFV.

Рынок NFV быстро развивается, поскольку поставщики технологий и услуг используют части проектов с открытым исходным кодом и добавляют их к своим существующим программным решениям, чтобы обеспечить полный набор функций NFV.

Обновлено Коннором Крэйвеном в апреле 2019 г.

Эта статья представлена ​​в руководстве SDxCentral по NFV 101 . Загрузите сегодня, чтобы продолжить изучение виртуализации сетевых функций.

Вы можете использовать один кластер диспетчера VNFM, подготовленный в VIM VMware/OpenStack, который развертывает решения для нескольких VIM; например, VMware и/или OpenStack.VNF Manager поддерживает как однородные, так и смешанные среды VIM. Например:

Системные требования

Чтобы внедрить VNFM для конфигураций с несколькими VIM, необходимо выполнить стандартные требования , а также следующие требования к подключению системы:

На предыдущей схеме примера конфигурации:

  • VNFM должен подключаться к API каждого VIM.
  • VNFM должен подключаться к сети управления, определенной для каждого VIM. Требуется связь L3 между интерфейсами управления машин. В этом примере используется туннель IPSec между средами Openstack и vSphere, и каждая среда имеет дополнительные виртуальные машины с обеих сторон для обработки конфигурации внешней сети.
  • Из-за ограничения BIG-IQ версии 6.0.1.0.0.813 для развертывания решения схемы BIG-IQ без DHCP требуется подключение L2 между компьютерами VNFM и BIG-IQ.

Требования к развертыванию

При настройке реализации нескольких VIM необходимо указать следующее:

Добавьте и определите новый набор сгруппированных секретов для каждого решения, развернутого для каждого местоположения/центра обработки данных VIM. При именовании каждого нового секрета замените _default определением, которое вы будете использовать для входных данных центра обработки данных для соответствующего решения схемы, развернутого для каждого центра обработки данных. Например, чтобы развернуть план дополнительного решения для нового центра обработки данных, используйте диспетчер VNF, который вы запустили для развертывания своего решения диспетчера лицензий BIG-IQ (Центр обработки данных 1 на предыдущей диаграмме Mixed-VIM ). , сделайте следующее:

Перейдите к панели «Системные ресурсы» -> «Управление хранилищем секретов» и несколько раз нажмите +Создать, чтобы добавить следующий набор секретов, заменив _default значением, соответствующим входному определению центра обработки данных, которое вы определите при развертывании решения для этих конкретных данных. центр.

В следующем примере секретных имен этот набор секретов относится к центру обработки данных, запущенному с помощью OpenStack VIM (Центр обработки данных 2 на предыдущей диаграмме Mixed-VIM):

  • keystone_password_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например keystone_password_datacenter_northwest-region.
  • keystone_tenant_name_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например keystone_tenant_name_datacenter_northwest-region.
  • keystone_url_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например keystone_url_datacenter_northwest-region.
  • keystone_username_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например keystone_username_datacenter_northwest-region.
  • keystone_allow_insecure_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например keystone_allow_insecure_datacenter_northwest-region.
  • keystone_ca_cert_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например keystone_ca_cert_datacenter_northwest-region.

Нажмите колонку "Развертывание", нажмите "Создать развертывание" , назовите развертывание, разверните раскрывающееся меню "Схема" и выберите решение для этого центра обработки данных.

В форме Создать новое развертывание щелкните и найдите файл inputs_[имя решения].yaml, который вы отредактировали для этого решения, прокрутите вниз до ввода центра обработки данных и введите то же обозначение datacenter_northwest-region. который вы предоставили набор секретов на шаге 1.a, а затем нажмите "Развернуть" .

Чтобы добавить дополнительный центр обработки данных в этот кластер VNFM, повторите предыдущие три шага. Например, предположим, что это новое развертывание предназначено для центра обработки данных, использующего vSphere VIM, тогда вы определите следующий набор сгруппированных секретов, заменив _default значением, которое вы будете использовать для входных данных центра обработки данных для этого развернутого решения схемы (< em>ЦОД 3 на предыдущей диаграмме Mixed-VIM):

  • vsphere_host_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например vsphere_host_datacenter_southwest-region.
  • vsphere_datacenter_name_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например, vsphere_datacenter_name_datacenter_southwest-region.
  • vsphere_password_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например, vsphere_password_datacenter_southwest-region.
  • vsphere_username_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например, vsphere_username_datacenter_southwest-region.
  • vsphere_host_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например vsphere_host_datacenter_southwest-region.
  • vsphere_port_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например vsphere_port_datacenter_southwest-region.
  • vsphere_resource_pool_name_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например, vsphere_resource_pool_name_datacenter_southwest-region.
  • vsphere_auto_placement_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например vsphere_auto_placement_datacenter_southwest-region.
  • vsphere_allow_insecure_default — определите новый добавленный секрет, используя обозначение центра обработки данных, например, vsphere_allow_insecure_default_datacenter_southwest-region.
  • vsphere_template_library_name_default — определите вновь добавленный секрет, используя обозначение центра обработки данных, например, vsphere_template_library_name_datacenter_southwest-region.

Когда вы повторяете шаг 1.c для этого развертывания, используйте значение datacenter_southwest-region при определении входных данных центра обработки данных для этой схемы решения.

Для получения дополнительной информации о настройке OpenStack и VMware VIM обратитесь к руководствам по установке.

Читайте также: