Новости Статьи VMware Veeam StarWind vStack Microsoft Nakivo Citrix Symantec События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Все самое нужное о виртуализации и облаках

Более 6300 заметок о VMware, AWS, Azure, Veeam, Kubernetes и других

VM Guru | Ссылка дня: Полный список лабораторных работ VMware Hands-on Labs

Новый документ: VMware NSX for vSphere Network Virtualization Design Guide версия 3.0.


Для тех из вас, кто использует в производственной среде или тестирует решение VMware NSX для виртуализации сетей своего датацентра, компания VMware подготовила полезный документ "VMware NSX for vSphere Network Virtualization Design Guide", который вышел уже аж в третьей редакции.

Документ представляет собой рефернсный дизайн инфраструктуры виртуализации сетей в датацентре и описывает архитектуру решения NSX на физическом и логическом уровнях.

В новой версии документа появилась следующая информация для сетевых архитекторов:

  • сайзинг решения NSX для небольших датацентров
  • лучшие практики маршрутизации
  • микросегментация и архитектура компонента обеспечения безопасности среды Service Composer

Документ содержит ни много ни мало 167 страниц. Скачать его можно по этой ссылке.


Таги: VMware, NSX, vNetwork, Whitepaper

Какая полоса пропускания необходима для "растянутого кластера" (VMware Virtual SAN Stretched Cluster)?


Мы уже писали о том, что "растянутый" кластер VMware HA Stretched Cluster прекрасно работает и поддерживается вместе с отказоустойчивыми хранилищами Virtual SAN. Также мы писали о документе с лучшими практиками по построению таких кластеров, для которых требуется обеспечивать максимальную производительность.

Однако многие задаются вопросом - а как планировать ширину канала между площадками таких растянутых кластеров, чтобы обеспечить необходимую пропускную способность для синхронизации узлов кластера VMware Virtual SAN? В помощь таким пользователям компания VMware выпустила интересный документ "VMware Virtual SAN Stretched Cluster Bandwidth Sizing Guidance", в котором даются конкретные параметры и формулы для расчета необходимой пропускной способности между площадками.

Архитектура растянутого кластера в общем случае выглядит так:

Таким образом, имеет место быть 2 связи - между двумя площадками как узлами кластера, а также между каждой из площадок и компонентом Witness, следящим за состоянием каждой из площадок и предотвращающим сценарии Split Brain.

Для этих соединений рекомендуются следующие параметры:

Как известно, реальный трафик состоит из отношения операций чтения и записи, которое зависит от характера нагрузки. Например, в VDI-среде это отношение составляет примерно 30/70, то есть 30% - это операции чтения (read), а 70% - операции записи (write).

В среде растянутого кластера данные виртуальной машины всегда читаются с локальных узлов VSAN - это называется Read Locality. Ну а для операций записи, само собой, нужна определенная пропускная способность на другую площадку. Она рассчитывается как:

B = Wb * md * mr

где:

  • Wb - полоса записи данных.
  • md - множитель данных, он зависит от потока метаданных кластера VSAN и сервисных операций. VMware рекомендует использовать значение 1,4 для этого параметра.
  • mr - множитель ресинхронизации. Для целей ресинхронизации VMware рекомендует заложить в канал еще 25%, то есть использовать значение этого параметра 1,25.

Например, рабочая нагрузка у вас составляет 10 000 IOPS на запись (10 тысяч операций в секунду). Возьмем типичный размер операции записи в 4 КБ и получим параметр Wb:

Wb = 10 000 * 4KB = 40 MB/s = 320 Mbps

Мегабайты в секунду переводятся в мегабиты умножением на 8. Ну и заметим, что требование канала по записи нужно умножать на 1,4*1,25 = 1,75. То есть канал нужно закладывать почти в 2 раза больше от требований по записи данных.

Теперь считаем требуемую пропускную способность канала между площадками:

B = Wb * md * mr = 320 Mbps * 1,4 * 1,25 = 560 Mbps

Ну а в самом документе вы найдете еще больше интересных расчетов и примеров.


Таги: VMware, Virtual SAN, Stretched Cluster, HA, Performance, vNetwork

Диаграмма портов и соединений VMware vSphere 6.x.


Спустя весьма продолжительное время с момента релиза новой версии платформы vSphere 6.0, компания VMware выпустила обновленную версию статьи базы знаний KB 2131180, в которой приведена схема со всеми портами и соединениями, используемыми в виртуальной инфраструктуре.

Штука это очень полезная и прямо просится на стенку в виде плаката в помещение, где сидят администраторы VMware vSphere. На страницах с 3 по 9 находится таблица со всеми соединениями, где указаны номера портов, протокол, источник и целевой компонент, а также назначение соединения.


Таги: VMware, vSphere, vNetwork, Update, Ports, Diagram

Вышел VMware NSX 6.2 - полная поддержка VMware vSphere 6.0 и другие новые возможности.


Уже где-то год прошел с момента релиза версии 6.1 решения для виртуализации сетей виртуального и физического датацентра VMware NSX. Поэтому VMware давно уже было пора обновить продукт и согласовать его с последними версиями линейки продуктов для серверной и десктопной виртуализации. Как мы все давно ждали, на днях вышла обновленная версия VMware NSX 6.2, где появилась масса нужных новых возможностей.

Приведем здесь основные из них:

1. Поддержка последних версий платформ виртуализации.

VMware NSX 6.2 поддерживает как VMware vSphere 5.5, так и vSphere 6.0. Новые функции в плане сетевого взаимодействия и безопасности между двумя серверами vCenter поддерживаются только для vSphere 6.0.

2. Возможности Cross vCenter Network Virtualization.

В NSX 6.2 поддерживаются окружения, где логические коммутаторы, распределенные логические маршрутизаторы и распределенные сетевые экраны размещены таким образом, что их действие распространяется на объекты с разными vCenter. Официально эта возможность называется Cross-vCenter Network and Security.

Теперь политики фаервола или логических сетевых компонентов могут быть помечены как Universal, что означает, что настройки реплицируются между модулями NSX Manager и будут сохранены при миграции vMotion виртуальной машины на другой хост ESXi, который находится под управлением другого сервера vCenter.

3. Новые универсальные логические объекты сети.

  • Universal Logical Switch (ULS) - возможность создания логических коммутаторов, которые объединяют несколько серверов vCenter. Это позволяет создать L2-домен сетевого взаимодействия для приложения в виртуальной машине, которое может "путешествовать" между датацентрами.
  • Universal Distributed Logical Router (UDLR) - это логический распределенный роутер, осуществляющий маршрутизацию между объектами ULS, описанными выше. Этот маршрутизатор работает также и на базе географического размещения ВМ.
  • Universal IP sets, MAC sets, security groups, services и service groups - все эти объекты поддерживают распределенные структуры с несколькими vCenter.

4. Поддержка VMware vCenter Server 6 с различными топологиями Platform Services Controller (PSC).

Если раньше NSX поддерживала только встроенные сервисы PSC (Platform Services Controller), то теперь поддерживаются различные распределенные топологии (об этом мы писали вот тут). Теперь полностью поддерживаются такие компоненты, как vCenter SSO, license service, lookup service, VMware Certificate Authority и прочее.

5. Поддержка L2 Bridging для Distributed Logical Router.

L2 bridging теперь может принимать участие в распределенной логической маршрутизации. Сеть VXLAN, к которой присоединен экземпляр бриджинга, используется для взаимосоединения Routing instance и Bridge instance.

6. Новый механизм обнаружения IP-адресов для виртуальных машин.

Ранее IP-адреса виртуальных машин обнаруживались по присутствию в них VMware Tools и добавлялись вручную. Теперь есть 2 новых способа добавления адресов: DHCP snooping и ARP snooping (причем присутствие VMware Tools необязательно).

7. Улучшения средств управления и решения проблем.

Тут появились следующие новые фичи:

  • Central CLI - единый интерфейс командной строки для обычных и распределенных функций NSX.
  • Traceflow troubleshooting tool - утилита, которая позволяет понять, возникла проблема в виртуальной или физической сети, за счет слежения за прохождением пакета через виртуальный и физический сетевой стек.
  • Функции Flow monitoring и IPFix теперь можно включать отдельно (раньше можно было только вместе и это создавало много нагрузочного трафика, особенно в больших окружениях).
  • Отчет в реальном времени о состоянии управляющих компонентов NSX: состояние связей между NSX Manager и агентом сетевого экрана, NSX Manager и консолью управления, между хостами ESXi и NSX Controller.

8. Улучшения LB Health Monitoring.

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

9. Поддержка диапазона портов для LB.

Теперь для приложений, которым нужно использовать диапазон портов для LB, есть возможность задать этот диапазон.

10. Прочие улучшения.

  • Возможность сохранять тэг VLAN при коммуникациях VXLAN.
  • Просмотр активного узла в HA-паре.
  • Увеличено максимальное число виртуальных IP-адресов.
  • Поддержка vRealize Orchestrator Plug-in for NSX 1.0.2.
  • Возможность включения/отключения uRPF check для отдельного интерфейса.
  • Улучшения Load balancer health monitoring.
  • Прочие улучшения, полный список которых приведен вот тут.

Скачать VMware NSX 6.2 можно по этой ссылке. Документация по продукту доступна вот тут.

Кроме того, VMware NSX версии 6.2 поддерживает инфраструктуру виртуальных ПК VMware Horizon View версии 6.0.1 и боее поздних (другие продукты вы тоже можете добавить в VMware Product Interoperability Matrix):

Про поддержку VMware Horizon View есть также небольшое видео:


Таги: VMware, NSX, Update, vNetwork, Enterprise

Утилита VLANidentificator - сверьте VLAN у виртуальных машин на VMware vSphere.


На одном из блогов о виртуализации на платформе VMware появилась интересная утилита VLANidentificator, предоставляющая информацию о принадлежности всех ваших виртуальных машин к портгруппам виртуальных коммутаторов и их VLAN ID:

Вы просто вводите стартовый IP-адрес и подсеть для сканирования, а скрипт пробегается по всем хостам VMware ESXi и vCenter, после чего все данные помещаются в сводную таблицу, в которой вы можете проверить, что нужные машины находятся в нужных VLAN, а также посмотреть на каких хостах ESXi они сейчас размещены. Для показа полной информации о машине, в том числе IP-адреса, нужно чтобы в ВМ были установлены VMware Tools.

Утилитка требует PowerShell 3 и более поздней версии и протестирована для работы с VMware vSphere 5.0, поэтому с шестой версией вполне может не работать. Поддерживаются также и распределенные виртуальные коммутаторы VMware Distributed Switch (vDS).

Исполняемый файл VLANidentificator можно скачать по этой ссылке. Ну а исходный код можно скачать вот тут.


Таги: VMware, vSphere, vNetwork, PowerShell, Blogs

Новое видео: VMware vSphere Distributed Switch Concept.


Недавно компания VMware выпустила интересное видео - vSphere Distributed Switch (vDS) Concept, из которого начинающие пользователи платформы виртуализации VMware vSphere могут понять, зачем именно им нужен распределенный виртуальный коммутатор:

Как показано в видео, VMware vDS нужен для следующих вещей:

  • Централизация операций по управлению сетевой конфигурацией хостов VMware ESXi.
  • Мониторинг состояния сетевых компонентов инфраструктуры на различных уровнях и решение проблем (траблшутинг).
  • Резервное копирование и восстановление конфигурации сети в случае сбоев.
  • Возможность приоретизации различных типов трафика (NetIOC).
  • Расширенные возможности для сетевых администраторов.

Это видео неплохо бы показать своему сетевому администратору перед внедрением vDS, если вы его планируете. Кстати, для тех, кто хочет узнать больше о возможностях распределенных коммутаторов от VMware и Cisco, есть отличный документ на русском языке "Сетевые функциональные возможности распределенного виртуального коммутатора VMware vSphere и коммутаторов Cisco Nexus серии 1000V". Из таблички, приведенной в нем, видно, какие новые возможности появляются у коммутатора vDS по сравнению с ESXi Standard vSwitch:


Таги: VMware, vDS, vNetwork, Video, vSphere

Демонстрация взаимодействия IaaS-инфраструктур на базе компонентов VMware Virtual SAN и NSX в рамках OpenStack.


Не так давно мы писали про виртуальный модуль vSphere OpenStack Virtual Appliance (VOVA), позволяющий построить архитектуру OpenStack на базе платформы виртуализации VMware vSphere. Теперь компания VMware решила пойти дальше и продемонстрировать пример того, как можно построить облачную IaaS-инфраструктуру на базе хранилищ Virtual SAN и решения для агрегации и виртуализации сетей VMware NSX, обеспечивая при этом прозрачную коммуникацию между виртуальными машинами (инстансами), исполняемыми на VMware vSphere и гипервизоре KVM.

В данной демонстрации используется Cloud Management Portal в рамках архитектуры OpenStack, позволяющий управлять сетевым взаимодействием multitenant-инфраструктуры. Для демо используется реальная инфраструктура, насчитывающая 200 инстансов, работающих на VMware ESXi и KVM. В качестве бэкэнд-хранилищ выступают датасторы VMware VSAN.

В процессе демонстрации показывают следующие вещи:

  • Создание виртуальных сегментов сетей датацентра (публичная веб-сеть и сеть приложений)
  • Создание виртуального роутера для маршрутизации между виртуальными сетями.
  • Назначение виртуальных сетей инстансам (виртуальным машинам) и демонстрация работоспособности заданных правил сетевого взаимодействия.
  • Приведение инфраструктуры в изначальный вид - удаление инстансов, виртуального роутера и виртуальных сетей.

Интересны следующие особенности показанной архитектуры:

  • Коммуникация между виртуальными машинами на разных гипервизорах и в разных виртуальных сетях идет на уровне L2 через оверлей, при этом модификация существующей физической сети не требуется.
  • Между тенантами (организациями в IaaS-инфраструктуре) существует полная логическая изоляция, то есть можно создавать для них роутеры и виртуальные сети, используя одну физическую подсеть, при этом организации будут надежно разделены.
  • На виртуальном роутере используется NAT на уровне тенанта, который позволяет использовать любую схему IP-адресации, а также плавающие (floating) IP для инстансов внутри тенанта, не нарушая работу инфраструктуры в целом.
  • Возможности безопасности в NSX, реализуемые в рамках OpenStack-архитектуры позволяют управлять и ограничивать входящий и исходящий трафик между виртуальными сетями, а также между инстансами в одной сети.
  • Virtual SAN как бэкэнд-хранилище предоставляет ресурсы для томов Cinder Volumes, которые являются основным контейнером для хранения инстансов.
  • Создание виртуальных сетей, маршрутизации между ними в multitenant IaaS-инфраструктуре показывает как сильно решение NSX упрощает жизнь - за несколько минут были созданы виртуальные сети и настроена маршрутизация между ними для коммуникации инстансов, а потом так же быстро удалили все созданные сущности - и все это без модификации настроек коммутаторов, маршрутизаторов и прочих компонентов физической сети.

Таги: VMware, NSX, OpenStack, SDN, vNetwork, IaaS, Cloud, Cloud Computing

Куда делся сетевой адаптер (vNIC) виртуальной машины на VMware vSphere?


Бывает такое, что пользователь системы жалуется администратору виртуальной инфраструктуры VMware vSphere, что у него пропал сетевой адаптер в виртуальной машине, и она больше недоступна из внешней сети. Администратор смотрит в лог виртуальной машины (vmware-##.log) и видит там вот такое:

Mar 15 03:13:37.463: vmx| Powering off Ethernet1 
Mar 15 03:13:37.463: vmx| Hot removal done.

Это, как вы уже догадались, означает, что кто-то тыкнул на иконку "Safely Remove Hardware" в гостевой ОС и выбрал там сетевой адаптер ВМ:

Либо это было сделано случайно в vSphere Client или Web Client. Поправить это легко - надо отключить функции Hot Add для виртуальной машины.

Для этого:

  • Соединяемся с хостом ESXi/ESX напрямую или через vCenter Server посредством vSphere Client.
  • Выключаем виртуальную машину.
  • Выбираем для нее Edit Settings и переходим на вкладку Options.
  • Выбираем General > Configuration Parameters > Add Row.
  • Добавляем строчку с именем devices.hotplug и значением false.
  • Включаем виртуальную машину.

После этого при попытке удаления устройства работающей виртуальной машины будет выдано такое сообщение

Если же вы не хотите запрещать Hot Add для всех устройств, а хотите просто спрятать возможность удаления сетевой карты из Safely Remove Hardware, то нужно сделать следующее:

  • Запустить редактор реестра как Local System. Для этого можно использовать утилиту psexec Tool.
  • Выполняем psexec -i -s regedit.exe.
  • Идем в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum ищем наш драйвер NIC (в его названии есть VMXNET3, E1000 и т.п.).
  • Установите значение ключа Capabilities на 4 единицы ниже.

Например, вот тут мы видим значение ключа 16:

Устанавливаем его на 4 меньше, то есть в значение 12:

После этого сетевой адаптер исчезнет из безопасного удаления устройств:


Таги: VMware, vSphere, Troubleshooting, ESXi, VMachines, vNetwork

Интеграция кластера хранилищ VMware Virtual SAN и кластера отказоустойчивости VMware HA в составе vSphere.


Как многие знают, с выходом средства для создания отказоустойчивых кластеров хранилищ VMware Virtual SAN, строящихся на базе локальных дисков серверов ESXi, стало известно, что этот механизм интегрирован со средством серверной отказоустойчивости VMware HA.

"Интегрирован" - означает, что любая нештатная ситуация, случившаяся с хостами ESXi должна быть обработана на стороне обоих механизмов, а также решение этой проблемы находится в компетенции поддержки VMware. И правда - ведь отказавший хост ESXi нарушает целостность обоих кластеров, поскольку предоставляет и ресурсы хранилищ, и вычислительные ресурсы.

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

Например, на картинке представлено разделение кластеров VMware HA и Virtual SAN на два частично пересекающихся сегмента:

Это, конечно же, плохо. Поэтому в VMware vSphere 5.5 были сделаны изменения, которые автоматически переносят сеть хартбитов кластера VMware HA в подсеть VMware Virtual SAN. Это позволяет в случае разделения сети иметь два непересекающихся в плане обоих технологий сегмента:

Вот тут и возникает 3 основных вопроса:

  • Какие хранилища нужно использовать в качестве datastore heartbeat?
  • Как адрес в случае изоляции хоста (isolation address) нужно использовать, чтобы надежно отличать изоляцию хоста от разделения сети на сегменты (network partitioning)?
  • Какие действия в случае изоляции хостов ESXi от остальной сети (isolation responses) нужно использовать?

Ну а в статье на блогах VMware даются вот такие ответы:

1. В качестве хранилищ, использующих datastore heartbeat в данной конфигурации, предлагается использовать датасторы, прицепленные к хостам ESXi, не входящим в кластер Virtual SAN. Объясняется это тем, что в случае разделения сети VSAN, механизм VMware HA сможет координировать восстановление виртуальных машин на хостах через эти хранилища.

2. По поводу isolation address есть следующие рекомендации:

  • При совместном использовании Virtual SAN и vSphere HA настройте такой isolation address, который позволит определить рабочее состояние хоста в случае отключения его от сети (сетей) VSAN. Например, можно использовать шлюз VSAN и несколько дополнительных адресов, которые задаются через расширенную настройку das.isolationAddressX (подробнее об этом - тут).
  • Настройте HA так, чтобы не использовать дефолтный шлюз management network (если эта не та же сеть, что и Virtual SAN network). Делается это через настройку das.useDefaultIsolationAddress=false.
  • Ну и общая рекомендация - если вы понимаете, как может быть разделен кластер с точки зрения сети, то найдите такие адреса, которые будут доступны с любого хоста при этом сценарии.

3. Ну и самое главное - действие isolation response, которое необходимо выполнить в случае, когда хост посчитал себя изолированным от других. На эту тему уже много чего писалось, но VMware объединила это вот в такие таблички:

 Тип виртуальной машины Хост имеет доступ к сети VSAN?  Виртуальные машины имеют доступ к своей сети VM Network?  Рекомендация для Isolation Responce  Причина 
Не-VSAN машина (не хранится на хранилищах Virtual SAN) Да Да Leave Powered On ВМ работает нормально - зачем что-то делать?
Не-VSAN машина Да Нет Leave Powered On Подходит для большинства сценариев. Если же доступ машины к сети очень критичен и не критично состояние ее памяти - надо ставить Power Off, чтобы она рестартовала на других хостах (координация восстановления будет через сеть VSAN). Дефолтно же лучше оставить Leave Powered On.
VSAN и не-VSAN машина Нет Да Leave Powered On
или
Power Off
См. таблицу ниже
VSAN и не-VSAN машина Нет Нет Leave Powered On
или
Power Off
См. таблицу ниже

А теперь, собственно, таблица ниже, которая объясняет от чего зависят последние 2 пункта:

Наиболее вероятна ситуация, когда в случае изоляции хоста, все остальные также изолированы? Будут ли хосты иметь доступ к heartbeat datastores, если будут изолированы? Важно ли сохранить память виртуальной машины при сбое? Рекомендованная isolation policy (responce) Причина
Нет Да Да Leave Powered On Важно состояние памяти ВМ. Так как есть доступ к хартбит-хранилищам, то ВМ не стартует на других хостах
Нет Да Нет Power Off Надо выключить ВМ, так как есть вероятность того, что ее вторая копия стартанет в другом сегменте разделенной сети.
Да Нет Да Leave Powered On Нет смысла выключать ВМ, так как хост-мастер операций не сможет инициировать ее восстановление, так как все хосты друг от друга изолированы.

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


Таги: VMware, Virtual SAN, HA, VSAN, FDM, Обучение, vSphere ESXi, vNetwork

Новый документ "What’s New in VMware vSphere 5.5 Networking".


Еще на прошлой неделе компания VMware выпустила познавательный документ "What’s New in VMware vSphere 5.5 Networking", в котором детально описываются нововведения, которые были сделаны в плане сетевого взаимодействия в VMware vSphere 5.5.

Напомним, что новая версия платформы принесла 5 основных нововведений в категории Networking:

  • Улучшения Link Aggregation Control Protocol (LACP) - поддержка большего числа алгоритмов балансировки.
  • Traffic Filtering - функции фильтрации трафика.
  • Quality of Service Tagging - поддержка тэгирования различных типов трафика в соответствии с уровнем обслуживания, заданным для него на уровне VDS.
  • Улучшения SR-IOV - напомним, что поддержка этих функций появилась еще в vSphere 5.1, теперь же процесс настройки этих функций существенно упрощен.
  • Host-Level Packet Capture - появилась встроенная утилита для захвата пакетов на уровне хоста.

Собственно об этом всем подробно рассказывается в небольшом документе на 7 страницах, который содержит следующие разделы:

  • VMware vSphere Distributed Switch Enhancements
    • Link Aggregation Control Protocol
    • Traffic Filtering
    • Quality of Service Tagging
  • Troubleshooting and Performance Enhancements
    • Enhanced Host-Level Packet-Capture Tool
    • 40GB Network Adapter Support
    • Single-Root I/O Virtualization Enhancements

Скачать документ можно по этой ссылке.


Таги: VMware, vSphere, vNetwork, Update, Whitepaper

Как создать резервную копию конфигурации VMware vSphere Distributed Switch и восстановить ее.


Некоторым администраторам VMware vSphere в крупных инфраструктурах иногда приходится сталкиваться с задачей по переносу распределенного виртуального коммутатора VMware vSphere Distributed Switch в другую инфраструктуру (миграция, восстановление после сбоя и т.п.). При этом многие знают, как перенести vCenter и SSO, но не знают как быть с этим коммутатором.

Специально для этого компания VMware сделала обучающее видео по процессу резервного копирования и восстановления конфигурации VMware vSphere Distributed Switch:

Но это еще не все. Для тех, кто хочет пройти эти процессы самостоятельно на практике, VMware сделала пошаговое руководство в формате walkthrough (о них мы уже писали тут и тут) - то есть набора экранов, где нужно самостоятельно кликать на элементы в vSphere Web Client:


Таги: VMware, vSphere, VDS, Backup, vNetwork

Как перезапустить Management Network на VMware ESXi из командной строки.


Многим администраторам виртуальной инфраструктуры VMware vSphere зачастую приходится перезапускать Management Network после различных операций с хостом VMware ESXi (например, чтобы обновить аренду IP-адреса у DHCP-сервера).

Делается это из консоли сервера ESXi (DCUI) в пункте меню "Restart Management Network":

Напомним, что доступ к графическому интерфейсу консоли сервера (DCUI) можно получить и по протоколу SSH, выполнив команду:

# dcui

Однако многие хотели бы рестартовать сеть ESXi консольной командой ESXCLI, которую можно выполнить, например, из vSphere Management Assistant. Для этого нужно просто отключить и включить сетевой интерфейс VMkernel на хосте. Делается это через пространство имен esxcli network.

При этом, поскольку вы подключены к ESXi через этот интерфейс, то нужно, чтобы две команды (отключение и включение) были выполнены обязательно вместе. Делается это добавлением точки с запятой (";") между командами.

Итак, узнаем имя интерфейса командой:

esxcli network ip interface ipv4 get

Далее отключаем и включаем интерфейс vmk0, что соответствует функции Restart Management Network в графическом интерфейсе хоста:

esxcli network ip interface set -e false -i vmk0; esxcli network ip interface set -e true -i vmk0


Таги: VMware, ESXi, vNetwork, Networking, VMachines, Blogs

В VMware vCloud Hybrid Service стали доступны возможности Direct Connect.


Мы уже немало писали об инфраструктуре публичного облака VMware vCloud Hybrid Service, которое позволяет предприятию взять виртуальные машины в аренду в датацентрах VMware и объединить их с ресурсами приватного облака.

На днях компания VMware обяъявила о доступности возможности прямого выделенного доступа (Direct Connect) к инфраструктуре vCHS по отдельным и защищенным каналам. Напомним также, что не так давно VMware еще объявила об открытии нового датацентра в UK и 4-го датацентра в Далласе.

Ранее к виртуальным машинам на vCHS можно было обращаться по IPsec VPN через интернет, теперь же доступно прямое соединение шириной до 10 Gbps, которое есть на данный момент только в штатах (а именно в датацентрах: Santa Clara, CA и Sterling) по договоренности с телекоммуникационными и сервис-провайдерами (например, Savvis).

При таком типе соединения полностью поддерживаются технологии, основанные на VXLAN, для организации единых виртуальных сетей, охватывающих собственный ЦОД и датацентр провайдера.

На данный момент в блоге VMware уже можно посмотреть на реальный кейс использования возможностей Direct Connect для облака vCHS.

Для различных типов аренды облака доступны следующие каналы:

  • Dedicated Cloud: 1 or 10 Gbps port connection
  • Virtual Private Cloud: 1 Gbps port connection

Напомним, что у компании Amazon, с которой конкурирует VMware, в облаке AWS также есть возможности Direct Connect.


Таги: VMware, vCHS, Cloud, Update, Cloud Computing, vNetwork, VXLAN

VMware vSphere Replication Capacity Planning Appliance - расчет необходимого канала под host-based репликацию.


Многие пользователи VMware vSphere применяют репликацию уровня хоста (host-based) для защиты виртуальных машин и их хранилищ. Сама эта технология появилась еще в версии VMware vSphere 5.1 и активно используется в vSphere 5.5. Напомним также, что функции vSphere Replication используются в решении VMware Site Recovery Manager для построения катастрофоустойчивой инфраструктуры небольших компаний.

На днях компания VMware выпустила виртуальный модуль (Virtual Appliance) под названием vSphere Replication Capacity Planning Appliance, который призван помочь при планировании пропускной способности канала сети под репликацию.

Эта бесплатная утилита, доступная на сайте проекта VMware Labs, позволяет смоделировать воздействие vSphere Replication на продуктивную сеть без реальной генерации трафика.

Возможности vSphere Replication Capacity Planning Appliance:

  • Интерфейс командной строки для настройки репликации в режиме "preview mode", без реального потребления хранилища.
  • Веб-страница, представляющая графики по потреблению канала для каждой репликации.
  • Не требует ресурсов сети и хранилищ.

Как начать пользоваться:

  1. Установить виртуальный модуль.
  2. Как только он загрузится, залогиниться по SSH или в консоль с логином/паролем - root/vmware.
  3. Выполнить команду:
    cd /opt/vmware/hbrtraffic/
  4. Выполнить команду для симуляции репликации конкретной ВМ (VM_name):
    ./bin/configureReplication --vc --vcuser Administrator --vcpass --lwd <IP_of_the_Appliance> --vmname <VM_name>

После того, как операция будет выполнена (10-15 минут) получившиеся графики можно посмотреть по адресу:

https://IP_of_the_Appliance:5480/vr-graphs/

Скачать vSphere Replication Capacity Planning Appliance можно по этой ссылке.


Таги: VMware, Labs, Replication, vSphere, ESXi, Storage, vNetwork

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


Не так давно мы уже писали о планируемых новых возможностях VMware vSphere 5.5, однако большинство новых функций были описаны в общих чертах, кроме того, до последнего момента так и не было окончательно известно, что же еще нового появится в vSphere 5.5. На проходящей сейчас конференции VMworld 2013 компания VMware наконец-то объявила о выходе обновленной платформы VMware vSphere 5.5, которая стала еще более мощным средством для построения виртуальных инфраструктур.


Таги: VMware, vSphere, Update, ESXi, vCenter, vNetwork, Storage, VMachines, VMFS

Организация сети в облаке ИТ-ГРАД и сетевая связность с облаком.


Это гостевой пост компании ИТ-ГРАД - ведущего российского сервис-провайдера, предлагающего услуги аренды виртуальных машин. Специально для любителей Cloud Computing мы расскажем о тех сетях, что используются в облаке ИТ-ГРАД – о том, как именно все организовано и как к нашему облаку можно подключиться. Итак: если вы берете виртуальную машину у нас в облаке, то автоматически вам выдается внешняя маршрутизируемая сеть с маской /29. Это значит, что...


Таги: IT-Grad, Cloud, vNetworking

Виртуальные сетевые адаптеры виртуальных машин VMware vSphere (vNIC) - какие бывают и какой выбрать?


Большинству администраторов VMware vSphere известно, что у виртуальной машины могут быть виртуальные сетевые адаптеры различных типов, которые выбираются как в зависимости от гостевой ОС, так и от настроек пользователя, которые можно прописать в vmx-файле конфигурации ВМ.

На эту тему компания VMware выпустила вот такое видео:

Опишем типы сетевых адаптеров (vNIC) для виртуальной машины (ранее мы писали о них тут):

  • Vlance - этот адаптер эмулирует реально существующий старый адаптер AMD 79C970 PCnet32- LANCE NIC, он работает на скорости 10 Mbps, и для него есть драйверы в большинстве 32-битных ОС, за исключением Windows Vista и более поздних версий. Виртуальная машина с таким адаптером может сразу использовать сеть.
  • VMXNET - такой адаптер уже не имеет физического воплощения, то есть он полностью виртуальный. Он оптимизирован с точки зрения производительности ВМ. Поскольку он виртуальный - ОС не может его использовать, пока не установлены драйверы, идущие в комплекте с VMware Tools.
  • Flexible - это по-сути не адаптер, а способ его представления. Он ведет себя как Vlance при загрузке ВМ, но потом превращается (или нет - в зависимости от VMware Tools) в VMXNET.
  • E1000 - это эмулируемая сетевая карта Intel 82545EM Gigabit Ethernet NIC. Драйвер для этого адаптера есть не во всех гостевых операционных системах. Обычно Linux с версиями ядра 2.4.19 или более поздними, Windows XP Professional x64 Edition и позднее, а также Windows Server 2003 (32-bit) и позднее включают в себя драйвер для этого устройства. Производительность его достаточно неплоха. Драйвер адаптера E1000 не поддерживает большие кадры jumbo frames до версии VMware ESXi/ESX 4.1.
  • E1000e - этот адаптер эмулирует более продвинутую модель Intel Gigabit NIC (number 82574) в виртуальном аппаратном обеспечении (virtual hardware) виртуальной машины. Адаптер e1000e доступен только для virtual hardware версии 8 (и старше), начиная с VMware vSphere 5. Это дефолтный адаптер для Windows 8 и более новых гостевых ОС. Для гостевых ОС Linux e1000e не доступен для выбора из интерфейса (e1000, flexible, vmxnet, enhanced vmxnet и vmxnet3 - доступны для Linux).
  • VMXNET 2 (Enhanced) - адаптер VMXNET 2 основан на устройстве VMXNET, но предоставляет несколько функций с улучшенной производительностью, таких как jumbo frames и hardware offloads (например, TCP Segmentation Offloading, TSO). Этот адаптер доступен только для хостов VMware ESX/ESXi 3.5 или выше. Устройство VMXNET 2 поддерживается только для следующих гостевых операционных систем:
    • 32- и 64-битные версии Microsoft Windows 2003 (Enterprise и Datacenter Edition). Можно использовать адаптер VMXNET 2 и на Microsoft Windows 2003, однако нужно прочитать статью в KB 1007195 (http://kb.vmware.com/kb/1007195  ).
    • 32-битная версия Microsoft Windows XP Professional
    • 32- и 64-битные версии Red Hat Enterprise Linux 5.0
    • 32- и 64-битные версии SUSE Linux Enterprise Server 10
    • 64-битные версии Red Hat Enterprise Linux 4.0
    • 64-битные версии Ubuntu Linux

    Кроме того, если такой адаптер недоступен для выбора в Windows 2003, то нужно почитать статью Enabling enhanced vmxnet adapters for Microsoft Windows Server 2003 (1007195).

    В ESX 3.5 Update 4 или более поздних версиях платформы следующие гостевые ОС также поддерживаются для этого адаптера:

    • Microsoft Windows Server 2003, Standard Edition (32-bit)
    • Microsoft Windows Server 2003, Standard Edition (64-bit)
    • Microsoft Windows Server 2003, Web Edition
    • Microsoft Windows Small Business Server 2003

    Jumbo frames также не поддерживаются для гостевых ОС Solaris с адаптером VMXNET 2.

  • VMXNET 3 - это следующее поколение виртуальных сетевых карт, которое теперь паравиртуализовано. То есть часть того, что раньше полностью эмулиировалось, теперь передается напрямую в физическое устройство. Этот адаптер не является надстройкой над VMXNET или VMXNET 2, но включает в себя все доступные для них возможности. Например, к ним относятся: поддержка механизмов нескольких очередей (multiqueue - также известны как Receive Side Scaling в Windows), IPv6 offloads, а также прерывания MSI/MSI-X (подробнее - тут).
    VMXNET 3 поддерживается только для виртуальных машин с виртуальным аппаратным обеспечением уровня 7 или более поздним, при этом только для следующих гостевых систем:
    • 32- и 64-битные версии Microsoft Windows XP и более поздние (включая Windows 7, 2003, 2003 R2, 2008, 2008 R2 и Server 2012)
    • 32- и 64-битные версии Red Hat Enterprise Linux 5.0 и более поздние
    • 32- и 64-битные версии SUSE Linux Enterprise Server 10 и более поздние
    • 32- и 64-битные версии Asianux 3 и более поздние
    • 32- и 64-битные версии Debian 4/Ubuntu и более поздние
    • 32- и 64-битные версии Sun Solaris 10 U4 и более поздние

    Заметки:
    • В ESXi/ESX 4.1 и более ранних версиях jumbo frames не поддерживаются для гостевых ОС Solaris для адаптеров VMXNET 2 и VMXNET 3. Эта возможность поддерживается, начиная с ESXi 5.0 только для адаптеров VMXNET 3. Более подробно можно почитать в статье Enabling Jumbo Frames on the Solaris guest operating system (2012445).
    • Технология Fault Tolerance не поддерживается для ВМ с адаптером VMXNET 3 в vSphere 4.0, но поддерживается в vSphere 4.1 и более поздних версиях.
    • Windows Server 2012 поддерживается для адаптеров e1000, e1000e и VMXNET 3 на платформе ESXi 5.0 Update 1 и более поздни

О производительности устройства VMXNET3 можно почитать в документе "Performance Evaluation of VMXNET3 Virtual Network Device".

Для того, чтобы использовать тот или иной тип виртуального сетевого адаптера для виртуальной машины, необходимо выставить его при добавлении к виртуальной машине при создании или редактировании свойств.

Также vNIC можно добавить с помощью добавления строчек в конфигурационный vmx-файл виртуальной машины:

  • Для адаптера типа Flexible ничего добавлять не требуется.
  • Ethernet[X].virtualDev = "e1000" - для добавления сетевого адаптера E1000.
  • Ethernet[X].virtualDev = "vmxnet" - для добавления адаптера VMXNET 2 (Enhanced).
  • Ethernet[X].virtualDev = "vmxnet3" - для добавления адаптера VMXNET3.

Вместо [X] необходимо подставить номер виртуального сетевого адаптера, начиная с 0.


Таги: VMware, vSphere, vNetwork, VMachines, ESXi, ESX, vNIC

Вышел балансировщик в виде виртуального модуля от Loadbalancer.org.


Те из вас, кто испытывает потребность в балансировке соединений в виртуальной инфраструктуре VMware vSphere, а также функциях безопасности, могут обратить свое внимание на продукт от Loadbalancer.org, поставляемый в виде виртуального модуля (Virtual Appliance).

Основные возможности продукта:

  • Средства высокой доступности компонентов
  • Полнофункциональная балансировка на уровнях 4/7
  • Поддержка виртуальных и физических серверов
  • Веб-консоль управления
  • Функции HTTP Cookie Persistence
  • Функции RDP Cookie Persistence
  • Поддержка SSL Offloading
  • Поддержка 802.1q VLAN
  • Группировка интерфейсов 802.3ad Bonding
  • Широкие возможности анализа пакетов
  • Поддержка IPv6
  • Поддержка SIP с функциями Call-ID Persistence

Виртуальный модуль может работать в трех режимах:

  • Direct Routing (DR) - режим прямой маршрутизации
  • Network Address Translation (NAT) - режим трансляции сетевых адресов
  • Source Network Address Translation (SNAT) - режим трансляции исходного сетевого адреса

Более подробно с продуктом от Loadbalancer.org можно ознакомиться в следующих документах:

Скачать пробную версию балансировщика от Loadbalancer.org можно по этой ссылке.
Таги: VMware, vNetwork, Networking, Virtual Appliance, vSphere

Используемые порты VMware Horizon View 5.2 - диаграмма.


Известный инструктор Simon Long опубликовал в своем блоге диаграмму, показывающую, какие локальные порты и соединения задействуются инфраструктуре виртуальных ПК VMware Horizon View 5.2.

На диаграмме представлен дизайн внутренней инфраструктуры, а вот схема по портам с учетом внешних соединений:


Таги: VMware, View, vNetwork, Blogs, Обучение

vmkping в VMware vSphere - через какой интерфейс VMkernel пойдут пинги?


Недавно мы писали про сетевой траблшутинг хостов VMware ESXi, где упоминали утилиту vmkping, с помощью которой можно пинговать какой-нибудь IP-адрес через  порт VMkernel. Но как быть если у вас 2 таких порта?

Через какой адаптер пойдет пинг?

Для этого случая есть параметр -I, который определяет через какой интерфейс пинговать (в нашем случае vmk1, а не vmk2):

# vmkping -I vmk1 IP-target

Источник, который рекомендует еще вот эту статью про vmkping с Jumbo Frames.


Таги: VMware, vNetwork, ESXi, Troubleshooting

Сетевой траблшутинг хостов VMware ESXi.


В инфраструктуре VMware vSphere для диагностики сетевых неполадок иногда приходится в сервисной консоли серверов VMware ESXi тестировать различные соединения. В этой заметке мы вкратце опишем, как это делается.

Прежде всего, обычный пинг через стандартный Management-интерфейс:

# ping <IP хоста>

Пинг через порт VMkernel (в ESXi это тот же самый интерфейс, а в ESX - другой):

# vmkping 192.168.48.133

PING 192.168.48.133 (192.168.48.133): 56 data bytes
64 bytes from 192.168.48.133: icmp_seq=0 ttl=64 time=0.978 ms
64 bytes from 192.168.48.133: icmp_seq=1 ttl=64 time=1.009 ms

Для проверки соединения сервера VMware ESXi с хостом по какому-нибудь порту используется утилита netcat (nc). Telnet есть только на ESX. Формат использования netcat:

# nc -z <IP хоста> <порт хоста>

Например:

# nc -z 192.168.48.133 80
Connection to 192.168.48.133 80 port [tcp/http] succeeded!

С помощью netcat можно проверять только TCP-соединения, для UDP (флаг -uz) всегда будет статус succeeded (даже если порт заблокирован или закрыт), так как соединения по UDP не устанавливается. Для того, чтобы тестировать UDP-соединения можно воспользоваться утилитой tcpdump-uw.

Команда nc может быть использована для сканирования диапазона портов (будьте осторожны со сканированием, чтобы не навлечь гнев безопасников):

# nc -w 1 -z 192.168.48.133 20-81
Connection to 192.168.48.133 22 port [tcp/ssh] succeeded!
...
Connection to 192.168.48.133 80 port [tcp/http] succeeded!

Опция -w определяет таймаут между соединениями.

Для траблшутинга SSL-соединений может быть использована следующая команда:

# openssl s_client -connect <IP хоста>:<ssl-порт>

В результате, вы увидите нечно подобное:

# openssl s_client -connect 192.168.48.133:443
CONNECTED(00000003)

Вывод может содержать полезную информацию об SSL-сертификатах, что может помочь в дальнейшем при поиске источника проблемы.

Для того, чтобы вывести список TCP/UDP-соединений на хосте, можно воспользоваться командами:

  • На ESX 3.5/4.x – # netstat -tnp
  • На ESXi 4.1 – # esxcli network connection list
  • На ESXi 5.0 – # esxcli network ip connection list

Выводом будет что-то вроде:

# esxcli network connection list
Proto  Recv-Q  Send-Q    Local Address       Foreign Address     State        World ID
  tcp    0       52      192.168.48.136:22   192.168.48.1:55169  ESTABLISHED  0
  tcp    0       0       127.0.0.1:62024     127.0.0.1:5988      TIME_WAIT    0
  tcp    0       0       127.0.0.1:57867     127.0.0.1:5988      TIME_WAIT    0
  tcp    0       0       127.0.0.1:62196     127.0.0.1:5988      TIME_WAIT    0
  tcp    0       0       127.0.0.1:8307      127.0.0.1:52943     ESTABLISHED  5790
  tcp    0       0       127.0.0.1:52943     127.0.0.1:8307      ESTABLISHED  5790
  tcp    0       0       127.0.0.1:80        127.0.0.1:55629     ESTABLISHED  5785
  tcp    0       0       127.0.0.1:55629     127.0.0.1:80        ESTABLISHED  6613
  tcp    0       0       127.0.0.1:8307      127.0.0.1:56319     ESTABLISHED  5785
  tcp    0       0       127.0.0.1:56319     127.0.0.1:8307      ESTABLISHED  5785


Таги: VMware, ESXi, vNetwork, ESX, vSphere, Обучение, CLI

VMware анонсировала платформу виртуализации и защиты сетей - VMware NSX.


Новость уже не свежая, так как стала известной в середине марта, но заслуживающая внимания. Как многие помнят, в середине прошлого года компания VMware приобрела стартап Nicira, выпускающий продукт Network Virtualization Platform (NVP), предназначенный для виртуализации сетей в рамках концепции Software-defined networking (SDN).

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

По-сути, VMware NSX - это решение полученное на основе двух продуктов: купленного Nicira NVP и собственного VMware vCloud Networking and Security (vCNS). Последний предназначен для комплексной защиты виртуального датацентра и построен на базе семейства продуктов VMware vShield.

Платформа VMware NSX включает в себя следующие компоненты:

  • Controller Cluster - это система, состоящая из виртуальных машин, предназначенная для развертывания виртуальных сетей во всем датацентре. Эти машины работают в кластере высокой доступности и готовы принимать управляющие команды от различных средств через API, например, VMware vCloud или OpenStack. Кластер осуществляет управление объектами vSwitches и Gateways, которые реализуют функции виртуальных сетей. Он определяет топологию сети, анализирует поток трафика и принимает решения о конфигурации сетевых компонентов.
  • Hypervisor vSwitches - это виртуальные коммутаторы уровня ядра ESXi с программируемым стеком L2-L4 и конфигурационной базой. Они отвечают за работу с трафиком виртуальных машин, обеспечение туннелей VXLAN и получают команды от Controller Cluster.
  • Gateways - это компоненты, предназначенные для сопряжения виртуальных и физических сетей. Они предоставляют сервисы IP routing, MPLS, NAT, Firewall, VPN, Load Balancing и многое другое.
  • Ecosystem partners - партнеры могут интегрировать собственные виртуальные модули (Virtual Appliances) в инфраструктуру NSX на уровнях L4-L7. Подробнее об этом написано здесь.
  • NSX Manager - это централизованное средство управления виртуальными сетями датацентра (с веб-консолью), которое взаимодействует с Controller Cluster.

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


Таги: VMware, NSX, vCNS, Nicira, vNetwork, Enterprsie

Вышла публичная бета распределенного коммутатора Cisco Nexus 1000V для Microsoft Hyper-V.


Еще далекой осенью 2011-го компания Cisco анонсировала доступность своего распределенного коммутатора Cisco Nexus 1000V для платформы Microsoft Hyper-V в новой ОС Windows Server 2012. И только совсем недавно, в начале марта 2013, бета-версия этого продукта наконец стала доступной для скачивания.

Комплект Cisco Nexus 1000V для Hyper-V состоит из следующих компонентов:

  • Управляющий модуль Nexus 1000V Virtual Supervisor Module (VSM) ISO (n1000vh-dk9.5.2.1.SM1.5.0.1.iso)
  • Компоненты, устанавливаемые на хост-серверах Nexus 1000V Virtual Ethernet Module (VEM) MSI package (Nexus1000V.msi)
  • Пакет VSEM Provider MSI Package (CiscoProviderInstaller.msi)
  • Nexus 1000V Installer App
  • Getting Started Guide
  • Документ с тест-кейсами для коммутатора
  • Документация по продукту

Основные возможности распределенного коммутатора Nexus 1000V для Hyper-V:

  • Работа с сетевым взаимодействием виртуальных машин средствами ОС Cisco NX-OS и технологии IEEE 802.1Q.
  • Технология Cisco vPath для интеллектуального перенаправления трафика виртуальных машин на уровнях L2 и L3, а также обеспечения функций политик.
  • Тесная интеграция с System Center Virtual Machine Manager 2012 SP1.
  • Коммутация на уровне L2 с поддержкой ограничения канала передачи (Transmit side Rate Limiting).
  • Поддержка Private VLANs и управление ими на базе политик.
  • Управление профилями портов напрямую из SCVMM.
  • Анализ трафика, включая механизмы VM Migration Tracking, NetFlow v.9 с поддержкой NDE и Cisco Discovery Protocol v.2.

На данный момент в составе беты решения Nexus 1000V для Hyper-V отсутствует компонент для обеспечения информационной безопасности Virtual Security Gateway (VSG).

Напомним, что Nexus 1000V поддерживает только Hyper-V 3.0 в Windows Server 2012 и полностью интегрирован со средством управления виртуальной инфраструктурой System Center Virtual Machine Manager (SCVMM) 2012 SP1 (другие версии бетой не поддерживаются). Запись вебинара на эту тему можно посмотреть тут, а слайды можно скачать здесь.

Полезные ссылки:


Таги: Cisco, Nexus, Microsoft, Update, vNetwork, Hyper-V

Новый документ - VMware Network Virtualization Design Guide.


Не так давно компания VMware выпустила новый документ "VMware Network Virtualization Design Guide", который полезно будет почитать менеджерам и сетевым администраторам виртуализованного ЦОД на платформе VMware vSphere.

В документе на довольно концептуальном уровне рассматривается сетевая модель виртуального датацентра (virtual datacenter, VDC) в контексте использования следующих продуктов и технологий VMware:

  • VMware vSphere Distributed Switch 5.1 (1)
  • VMware vSphere logical network VXLAN (2)
  • VMware vCloud Networking and Security Edge 5.1 (3)
  • VMware vCloud Networking and Security Manager 5.1 (4)
  • VMware vCloud Director 5.1 (5)
  • VMware vCenter Server 5.1

Кстати, об организации сетей VXLAN в виртуальной инфраструктуре VMware vSphere и о том, для чего они нужны, мы уже писали вот тут.

В рамках концепции VXLAN рассмотрено прохождение пакетов в рамках одной виртуальной сети VXLAN:

А также прохождение пакетов из одной сети VXLAN в другую:

Интересны также комплексные сценарии, например, по организации доступа к виртуальной машине, работающей в рамках растянутого кластера (Stretched Cluster) и переехавшей из одного датацентра в другой посредством vMotion.

В общем - читайте.


Таги: VMware, vNetwork, Whitepaper, vSphere, VXLAN

Shadow vmnics в выводе esxtop на VMware ESXi.


Если заглянуть в секцию Network утилиты esxtop, то там (начиная с ESXi 5.1) можно увидеть объекты Shadow of vmnic1 и т.п.:

На самом деле, эти штуки созданы для обеспечения работы функций VDS Network Health Check, которые появились в VMware vSphere 5.1. Для каждого физического интерфейса создается shadow port, через который посылаются пакеты Health Check, связанные с состоянием этого порта. Эти виртуальные интерфейсы можно мониторить на предмет работоспособности означенной функциональности.

Если эти штуки вам мешают, то можно убрать их, отключив модули хоста ESXi, связанные с хэлсчеком (заодно и в целях безопасности). Для этого нужно выполнить следующую последовательность команд для выгрузки ненужных модулей:

vmkload_mod -u vlanmtucheck
vmkload_mod -u teamcheck
vmkload_mod -u heartbeat
vmkload_mod -u healthchk

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

Кстати, не по теме, но хозяйке на заметку: если вы видите, что в esxtop какой-либо счетчик принимает только значения 0 или 100 - знайте, что это просто означает работает эта штука в данный момент времени или нет. Так, например, происходит с SIOC. Просто нет еще в esxtop булевых метрик.


Таги: VMware, ESXi, vNetwork, Blogs, vSphere, VDS

NEC анонсировала распределенный виртуальный коммутатор для Microsoft Hyper-V.


Мы уже писали о том, что виртуальный коммутатор Cisco Nexus 1000V будет доступен не только для платформ VMware, но и для Hyper-V (также мы упоминали о его доступности для Citrix XenServer). А недавно компания NEC взяла и анонсировала виртуальный коммутатор для Microsoft Hyper-V. При этом было объявлено и о публичной доступности этого решения, которое называется ProgrammableFlow PF1000.

Как это модно сейчас называть, Virtual Switch от NEC реализован в рамках концепции Software Defined Networking (SDN), подразумевающей абстракцию сетевого оборудования датацентра в целях агрегации и централизованного управления сетевыми ресурсами. Виртуальный коммутатор ProgrammableFlow PF1000 позволяет объединить сетевые ресурсы хост-серверов Microsoft Hyper-V на платформе Windows Server 2012 в единой консоли и централизованного управлять ими в рамках виртуального датацентра.

Ключевыми компонентами решения ProgrammableFlow PF1000 являются:

  • Средство централизованного управления ProgrammableFlow Controller (PFC), построенное на базе концепции Open SDN и поддерживающее протоколы OpenStack Folsom и OpenFlow
  • Агенты ProgrammableFlow Switches (PFS) на хост-серверах, представляющие собой виртуальные коммутаторы уровня сервера

ProgrammableFlow Controller реализует виртуальные сети на уровне L2 и L3 с поддержкой механизма Quality of Service (QoS) и IPv6 для инфраструктуры OpenFlow. Кроме того, в решении реализована поддержка REST-based API, что позволяет просто интегрировать продукт со сторонним программным обеспечением.

Более подробно о решениях серии NEC ProgrammableFlow SDN можно узнать по этой ссылке.


Таги: NEC, Microsoft, Hyper-V, vNetwork, vSwitch, SDN

Максимальное количество миграций VMware vMotion и Storage vMotion - хосты, сети и хранилища.


Полгода назад мы писали об особенностях работы технологии VMware Storage vMotion, где касались максимального числа одновременных миграций SVMotion на хранилище VMware vSphere. Там же мы вскользь касались миграций vMotion и упоминали вот эту нашу статью, где рассматривались лимиты одновременных миграций vMotion на серверах и хранилищах.

Теперь, на основе статьи Франка, мы обобщим и актуализуем информацию по миграциям vMotion и Storage vMotion в разных контекстах - на уровне хранилищ, сети и хост-серверов VMware ESX.

Как и в прошлой статье, здесь будем пользоваться понятием стоимости миграции в единицах (cost) и максимального значения костов в тех же единицах (max cost), которое отображает предельно допустимое значение. Сумма костов операций vMotion и SVMotion не должна превышать max cost для соответствующего объекта (datastore, NIC и хост ESXi).

Теперь взглянем на таблички (в них есть не только vMotion, но и SVMotion):

Хост ESXi

Operation Config Key Cost
vMotion Cost costPerVmotionESX41 1
Storage vMotion Cost costPerSVmotionESX41 4
Maximum Cost maxCostPerEsx41Host 8

Сеть

Operation Config Key Cost
vMotion Cost networkCostPerVmotion 1
Storage vMotion Cost networkCostPerSVmotion 0
Maximum Cost maxCostPerNic 2
maxCostPer1GNic 4
maxCostPer10GNic 8

Хранилище (Datastore)

Operation Config Key Cost
vMotion Cost CostPerEsx41Vmotion 1
Storage vMotion Cost CostPerEsx41SVmotion 16
Maximum Cost maxCostPerEsx41Ds 128

Читать эти таблички просто - например, для хоста ESXi стоимость миграции vMotion равна 1, а поскольку max cost равно 8, то всего на хост может быть 8 одновременных миграций в конфигурации по умолчанию. Либо допустимы одновременно: 1 миграция SVMotion (4 очка) и 4 штуки vMotion (по одному очку каждая), т.е. суммировать надо по костам: 4+1+1+1+1=8.

Для хранилища (Datastore) также есть ограничения vMotion, поскольку передаются страницы файла подкачки (если он не шаренный между хостами), а также производится передача владения VMX-файлом и другими файлами ВМ на хранилище. Но поскольку влияние это мало, то стоимость vMotion для хранилища всего 1 при максимальной емкости одновременных операций 128 (а вот SVMotion, требующая значительных ресурсов хранилища, "кушает" 16 единиц). Таким образом 1 операция vMotion съест 1 единицу коста, поэтому в этот момент для хранилища будет доступно только 7 миграций SVMotion, т.е. (128-1) div 16 = 7.

Соответственно, редактирование параметра Config Key для соответствующей операции позволяет изменять количество одновременных операций vMotion/SVMotion. Для редактирования параметра Config Key нужно отредактировать конфигурационный файл vpxd.cfg на сервере VMware vCenter, который находится в папке:

%ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\

Там нужно вписать новое значение в соответствующую секцию. Например, для параметра maxCostPerEsx41Ds:

< config >
< vpxd >
< ResourceManager >
< MaxCostPerEsx41DS > new value < /MaxCostPerEsx41DS >
< /ResourceManager >
< /vpxd >
< /config >

Если соответствующей секции нет, то ее можно просто добавить. Уменьшать максимальные косты точно можно, а увеличение работает не всегда. То есть гарантированно вы сможете только уменьшить число одновременных миграций vMotion или SVMotion, а вот увеличить - не факт. Ограничение можно делать двумя способами - повышением обычных костов или понижением максимальных костов.

Теперь самое интересное - это динамический параметр max cost для сетевых адаптеров. Как видно из таблицы, его действующее значение зависит от типа сетевого адаптера на хосте - 1G или 10G. Но, на самом деле, и не только от типа. Точнее - от скорости соединения для трафика vMotion между хостами ESXi, которую обнаруживает VMkernel. Таким образом:

  • Если VMkernel обнаруживает соединение на скорости 1Gbit/s - Maximum Cost выставляется в значение 4 (это верно и для случая соединения 1G<->10G).
  • Если VMkernel обнаруживает соединение на скорости 10Gbit/s - Maximum Cost выставляется в значение 8.
  • Если VMkernel обнаруживает соединение на скорости ниже 1Gbit/s - Maximum Cost выставляется в значение 2.

Таким образом, для адаптера возможны либо 2, либо 4, либо 8 одновременных миграций vMotion, в зависимости от действующей скорости соединения. Операция Storage vMotion, как видно из таблицы, костов сети не кушает.

Если ограничение для сети жестче (например, 4 миграции vMotion), чем ограничение для хоста (8 миграций vMotion) - то для машин этого хоста действует ограничение сети.


Таги: VMware, vSphere, vMotion, ESXi, Storage vMotion, SVMotion, VMachines, Storage, vNetwork

Бесплатный Cisco Nexus 1000V 2.1 и новые возможности для организации сетевого взаимодействия VMware vSphere.


Недавно компания Cisco анонсировала скорую доступность бета-версии своего виртуального распределенного коммутатора Cisco Nexus 1000V 2.1, который не только получит много новых возможностей, но и будет иметь бесплатное издание - Essential Edition.

Напомним, что на данный момент актуальная версия коммутатора Cisco Nexus 1000V 1.5.2 работает на VMware vSphere 5.1 и с vCloud Director 5.1 и уже имеет поддержку технологии VXLAN:

В октябре этого года компания Cisco планирует добавить следующие возможности в Cisco Nexus 1000V 2.1:

Поддержка TrustSec SXP позволяет сегментировать виртуальный датацентр на несколько зон безопасности, защищенных политиками, по тэгам SGT:

Появится полноценный плагин к vCenter:

Технология vTracker позволит отслеживать различные процессы и события в сети виртуальной инфраструктуры (например, миграции vMotion):

Модули VSM можно разносить по двум датацентрам в конфигурации Active-Passive:

Теперь о различиях платного (Advanced Edition) и бесплатного (Essential Edition) изданий Cisco Nexus 1000V 2.1:

Пользователи Cisco Nexus 1000V с активной подпиской получают версию 2.1 бесплатно, а также компонент VSG (Virtual Security Gateway) в подарок, который больше отдельно не продается (т.е. его нельзя прикрутить к бесплатному изданию):

Виртуальный распределенный коммутатор Cisco Nexus 1000V будет доступен не только для VMware vSphere, но и для платформ Microsoft Hyper-V, Linux Kernel-Based Virtual Machine (KVM), а также Citrix XenServer. Напомним, что в VMware vSphere его можно использовать только совместно с изданием vSphere Enterprise Plus.


Таги: VMware, Cisco, Nexus, Update, Бесплатно, vSphere, Enterprise, vNetwork

Постер о сетевой инфраструктуре VMware vCloud: VSS, VDS и VXLAN.


Во время проходившей в конце августа конференции VMworld 2012 компания VMware выпустила интересный постер - "VMware vCloud Networking Poster".

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

  • vSphere Standard Switch (VSS) - обычный виртуальный коммутатор на хостах ESXi.
  • vSphere Distributed Switch (VDS) - распределенный виртуальный коммутатор, предоставляющий функции централизованного управления сетевой инфраструктурой через vCenter.
  • Virtual Extensible Local Area Network (VXLAN) - новая технология для облачных инфраструктур, пришедшая на смену VLAN, описанная у нас тут.

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

Скачать постер VMware vCloud Networking в формате PDF.


Таги: VMware, vCloud, vNetwork, VDS, vSphere, Cloud

Network Health Check в VMware vSphere 5.1 - проверка корректности VLAN на физических свичах.


Мы уже писали о новых возможностях плафтормы виртуализации VMware vSphere 5.1, а также о принципах лицензирования продукта. Среди новых функций сетевого взаимодействия в vSphere 5.1 появились возможности Network Health Check, обеспечивающие проверку согласованности параметров на виртуальных распределенных коммутаторах VDS и физических коммутаторах, к которым подключены сетевые адаптеры серверов ESXi.

В рамках Network Health Check отслеживается корректность настройки следующих параметров (с интервалом в 1 минуту) для физических и виртуальных коммутаторов:

  • VLAN
  • MTU
  • Network adapter teaming

Делается это средствами Layer 2 Ethernet probing. Сегодня мы расскажем о том, как выглядит на практике Network Health Check при проверке VLAN, основываясь на материалах блогера Rickard Nobel. Для начала в vSphere Web Client для коммутатора VDS 5.1 зайдем на вкладку "Manage" в раздел "Health check":

Здесь мы видим, что функции Health check включены только для параметров VLAN и MTU. Частая проблема администраторов vSphere заключается в том, что настройки VLAN, сделанные в портгруппах на виртуальном коммутаторе VDS, не совпадают с настройками VLAN на портах физических свичей.

Например, для портгруппы VDS настроен VLAN 200, а сетевой администратор, который настраивал VLAN для портов физических коммутаторов, куда ведут аплинки серверов ESXi, пропустил один из портов физического коммутатора при настройке для пропускания фреймов VLAN 200. Вследствие этого, виртуальные машины могут работать хорошо, однако функции vMotion/DRS могут быть частично недоступны для некоторых из хостов.

Собственно, чтобы вовремя обнаружить такую ошибку, мы и включаем Network Health Check:

Теперь хосты ESXi будут слать броадкасты на все свои адаптеры vmnic, привязанные к VDS, и отслеживать, не дропают ли их порты физических коммутаторов. Эти фреймы будут тэгированы всеми VLAN ID, которые назначены для групп портов VDS. В нашем случе - это VLAN 100 и VLAN 200, которые мы видим в списке портгрупп:

Теперь мы видим новую вкладку "Monitor", где можно отслеживать жизнедеятельность VLAN на хостах. Заходим в подраздел "Health":

Здесь мы видим, что для одного хоста с настройками VLAN что-то не так. Смотрим детали:

Здесь мы видим, что для аплинков vmnic2 и vmnic3 не работает VLAN 200. Теперь неплохо бы в настройках VDS включить поддержку LLDP (режим Both или Advertise), чтобы определить порты физического коммутатора, с которыми связана данная проблема для конкретных аплинков, и не бегать в серверную.

Теперь на физическом коммутаторе смотрим порты, куда включены vmnic2 и vmnic3 командой (в данном случае команды для коммутатора HP):

# show lldp info remote

Мы видим порты свича, куда включены проблемные аплинки хоста. Теперь смотрим, для каких портов настроен VLAN 200 командой:

# show vlan 200

Видим, что VLAN 200 пропускается только на порту A13, а порт A14 не пропускает двухсотый VLAN. Исправляем ситуацию, добавляя VLAN 200 для порта A14, командой:

# vlan 200 tag A14

И выводим снова информацию по VLAN 200:

Теперь оба порта на физическом коммутаторе принимают кадры с VLAN ID 200.

Откроем vSphere Web Client for ESXi 5.1 и посмотрим, в каком состоянии теперь находятся аплинки VDS:

Теперь мы видим, что все корректно настроено, и порты физических коммутаторов пропускают нужные VLAN от обозначенных сетевых адаптеров хостов в портгруппах VDS.


Таги: VMware, vSphere, VDS, Troubleshooting, ESXi, vNetwork, Hardware

<<   <    1 | 2 | 3 | 4    >   >>
Интересное:





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

Быстрый переход:
VMware Broadcom Offtopic Microsoft Veeam Cloud StarWind VMachines NAKIVO vStack Gartner Vinchin Nakivo IT-Grad Teradici VeeamON VMworld PowerCLI Citrix VSAN GDPR 5nine Hardware Nutanix vSphere RVTools Enterprise Security Code Cisco vGate SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud DevOps Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs IDC Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V Private AI HCX vSAN VCPP VCF Workstation Labs Backup Explore vDefend Data Protection ONE Tanzu AI Intel Live Recovery VCP V2V Aria NSX DPU Update EUC Avi Community Skyline Host Client GenAI Chargeback Horizon SASE Workspace ONE Networking Ransomware Tools Performance Lifecycle Network AWS API USB SDDC Fusion Whitepaper SD-WAN Mobile VMUG SRM ARM HCI Converter Photon OS Operations VEBA App Volumes Certification VMConAWS Workspace Imager SplinterDB DRS SAN vMotion Open Source iSCSI Partners HA Monterey Kubernetes vForum Learning vRNI UAG Support Log Insight AMD vCSA NSX-T Graphics NVMe HCIBench SureBackup Docs Carbon Black vCloud Обучение Web Client vExpert OpenStack UEM CPU PKS vROPs Stencils Bug VTL Forum Video Update Manager VVols DR Cache Storage DRS Visio Manager Virtual Appliance PowerShell LSFS Client Datacenter Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Encryption Nested XenDesktop VSA vNetwork SSO VMDK Appliance VUM HoL Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP iOS SC VMM VDP PCoIP RHEV vMA Award Licensing Logs Server Demo vCHS Calculator Бесплатно Beta Exchange MAP DaaS Hybrid Monitoring VPLEX UCS GPU SDK Poster VSPP Receiver 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 KB VirtualCenter NFS ThinPrint Director Memory SIOC Troubleshooting Stretched Bugs ESA Android Python Upgrade ML Hub Guardrails CLI Driver Foundation HPC Orchestrator Optimization SVMotion Diagram Ports Plugin Helpdesk VIC VDS Migration Air DPM Flex Mac SSH VAAI Heartbeat MSCS Composer
Полезные постеры:

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

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

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

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

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

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

 

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

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

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

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

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

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

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

Диски RDM (Raw Device Mapping) для виртуальных машин VMware vSphere и серверов ESX.

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

Где скачать последнюю версию VMware Tools для виртуальных машин на VMware ESXi.

Подключение локальных SATA-дисков сервера VMware ESXi в качестве хранилищ RDM для виртуальных машин.

Как перенести виртуальную машину VirtualBox в VMware Workstation и обратно

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

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

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

Интервью:

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

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


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

Последние 100 утилит VMware Labs

Новые возможности VMware vSphere 8.0 Update 1

Новые возможности VMware vSAN 8.0 Update 1

Новые документы от VMware

Новые технологии и продукты на VMware Explore 2022

Анонсы VMware весной 2021 года

Новые технологии и продукты на VMware VMworld 2021

Новые технологии и продукты на VMware VMworld 2020

Новые технологии и продукты на VMware VMworld Europe 2019

Новые технологии и продукты на VMware VMworld US 2019

Новые технологии и продукты на VMware VMworld 2019

Новые технологии и продукты на VMware VMworld 2018

Новые технологии и продукты на VMware VMworld 2017



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