Nicira Virtualization Platrform. Контроллеры NVP

Во второй части цикла о платформе виртуализации сети от VMware я расскажу о контроллерах. Напомню, что они нужны для расчёта сетевой топологии, распространения настроек и создания логических сетей и логики распространения трафика внутри неё. Для этого контроллеры на «южную» сторону, Open vSwitch (OVS) устройства, распространяют необходимую информацию, полученную с «северного» NVP API, чем обеспечивают соответствие между логическими сетями, согласно данным полученным NVP API и транспортной сетью, обеспечиваемой программируемыми виртуальными пограничными устройствами.

Детальнее это выглядит так:

Если в транспортной сети происходит изменение – например, запускается или выключается ВМ, мигрирует на другой хост – контроллер обновляет необходимые правила маршрутизации, и состояние транспортной сети, чтобы состояние подключения ВМ соответствовало подключению ВМ к логическим сетям. К примеру, включается новая виртуальная машина, которая должна быть подключена к определённой логической сети – кластер контроллеров обновляет необходимые правила маршрутизации, чтобы включённая ВМ была подключена к требуемой виртуальной сети.

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

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

Итак, разобравшись с ролью контроллеров перейдём к процессу сборки контроллеров.

В каких случаях трафик vMotion пойдёт по сети управления вместо vMotion

Сценарий 1: Миграция между хостами и без общего хранилища
В версии vSphere 5.1 появилась возможность одновременной миграции ВМ между хостами и датасторами. Если ВМ хранится на локальном или не общем для хостов хранилище, то vMotion использует сеть vMotion для миграции ВМ на целевое хранилище. При мониторинге сетевых интерфейсов VMkernel можно увидеть, что трафик идёт по интерфейсу управления вместо vMotion.

При миграции виртуальной машины vMotion определяет горячие и холодные данные. Активно используемые виртуальные диски и снэпшоты считаются горячими данными, тогда как нижестоящие снэпшоты и базовый диск считаются холодными данными. К примеру, представим, что у нас есть ВМ с пятью снэпшотами. Последний снэпшот считается горячими данными, и пересылается по vMotion сети, а остальные 4 снэпшота и базовый диск – холодными, и передаются по VMkernel NIC (vmk0) с помощью network file copy (NFC).

Причина того, что vMotion используется разные сети в том, что сеть vMotion зарезервирована для миграции данных для которых критична производительность. Если сеть vMotion использовать для копирования холодных данных, то вся ширина пропускания может быть занята передачей некритичных данных, что негативно повлияет на данные, которым производительность критична. Не забывайте, что всё что передается по vMotion сети напрямую влияет на производительность мигрируемой ВМ.

Во время миграции VMkernel зеркалирует все команды ввода-вывода для источника и целевого хоста. Если же процесс vMotion будет перегонять всю иерархию дисков по своей сети, то этим он отберёт канал у процесса зеркалирования запросов, что снизит производительность ВМ.

Если же у ВМ нету снэпшотов, то её диск считается горячими данными, и передаётся по сети vMotion, тогда как все остальные файлы из директории – по VMkernel сети.

Сценарий 2: Сеть управления и vMotion используют одну подсеть
Если управляющая сеть (если быть точным то первый интерфейс VMkernel) и vMotion используют одну и ту же подсеть, то vMotion будет отправлять трафик через первый интерфейс VMkernel даже если вы создадите выделенную сеть vMotion на отдельном стандартном или распределённом свитче с отдельным физическим интерфейсом. В любом случае vMotion будет обращаться к первому интерфейсу VMkernel если обнаружит совпадение подсети.

Отдельно хочу отметить, что на целевом хосте конечным интерфейсом будет интерфейс vMotion.

Я проводил онлайн исследование по результатам которого оказалось, что больше 95% респондентов используют выделенный диапазон IP адресов для vMotion сети. Тем не менее я бы хотел напомнить, что рекомендуется использовать отдельную сеть для vMotion. Сеть управления считается небезопасной сетью, и поэтому не рекомендуется использовать её для vMotion.

В случае если хост использует Multi-NIC vMotion то даже в случае использования одной подсети vMotion учитывает настройки, и использует для передачи трафика VMkernel только с активированной опцией использования для vMotion.

Если в вашем окружении используется один диапазон адресов для обоих типов сети, то я бы рекомендовал создание Multi-NIC vMotion. В случае ограниченного количества физических интерфейсов, вы можете использовать одни и тот же сетевой интерфейс для обоих VMkernel, в таком случае хоть балансировка нагрузки и не будет доступна, но VMkernel будет использовать сеть vMotion по назначению.

Источник: Frank Denneman

Курс EMC Cloud Architect в Москве

Коллеги, EMC планирует провести курс из трека EMC Cloud Architect в Москве в сентябре. И у меня появилась возможность пригласить одного-двух человек на этот курс бесплатно.

Мое впечатление от Virtualized Datacenter - http://blog.vadmin.ru/2011/09/emc-cloud-architect.html

Напишите мне в личку / e-mail - почему вам интересно этот курс посетить, и почему именно вам должно достаться место в классе :)

Nicira Virtualization Platform. Высокоуровневая архитектура

Это первая из цикла статей, описывающих более глубокое изучение мной Nicira Network Virtualization Platform (NVP). Как по мне NVP это прекрасный продукт, но о котором доступно очень мало информации: как он работает, как он настраивается и т.д - именно эту проблему я и собираюсь решить данным циклом статей. И начнём с высокоуровнего описания архитектуры.

Перед тем как начать хотелось бы прояснить взаимосвязь между NVP и NSX. Данный цикл будет акцентироваться на NVP - продукте который уже доступен, и используется некоторыми компаниями. Архитектура которую я тут буду описывать также будет применима и к стеку NSX, который VMware анонсировала в марте, так как NSX будет использовать архитектуру NVP, так что изучение NVP сейчас поможет с NSX в будущем.

Начнём с картинки - схема внизу показывает высокоуровневую архитектуру NVP:

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

• Горизонтально масштабируемый кластер контроллеров - NVP контроллеры обрабатывают расчёты сетевой топологии, предоставляют конфигурацию и распространяют настройки требуемые для создания логических сетей. Для повышения уровня доступности и масштабируемости контроллеры поддерживают возможность горизонтального масштабирования. Контроллеры поддерживают "северный" REST API, который может быть использован системами управления облаком типа OpenStack, CloudStack или же внутренними разработками каждой компании.
• Программируемый виртуальный свитч - для этой роли NVP использует Open vSwitch (OVS) - независимый проект с открытым исходным кодом, разрабатываемый самыми разными игроками рынка. OVS связывается с кластером контроллеров NVP для получения настроек и информации о логических сетях.
• "Южный" протокол коммутации - NVP использует два открытых протокола для связи между контроллерами и OVS. Для передачи настроек используется протокол OVSDB, а логических сетей - OpenFlow. Управляющий трафик протокола OVSDB между OSV и контроллерами зашифрован с помощью SSL.
• Шлюзы: шлюзы являются входом и выходом в\для логических сетей в NVP. Шлюзы могу быть как L2 (свитчинг логических сетей в NVP в физические) так и L3 (маршрутизация между логическими сетями в NVP и физическими сетями). В любом случае шлюзы поддерживают горизонтальное масштабирование для обеспечения отказоустойчивости и повышения масштабируемости L2 и L3 шлюзов, работающих на хосте.
• Протоколы инкапсуляции: для обеспечения полной независимости и изоляции логических сетей от подлежащих физических сетей NVP использует протоколы инкапсуляции для транспортировки трафика логических сетей поверх физических сетей. На данный момент NVP поддерживает Generic Routing Encapsulation (GRE) и Stateless Transport Tunneling (STT), а в будущих версиях этот список будет расширен.
• Ноды обслуживания- для разгрузки BUM трафика (Broadcast, Unknown Unicast, и Multicast) NVP опционально может использовать несколько нод обслуживания. На схеме выше они не отображены. Если не использовать ноды обслуживания BUM трафик будет обрабатываться каждым гипервизором локально.

Оригинал: Scott Lowe

Горизонтальное и вертикальное масштабирование. Взгляд со стороны бизнес приложений.

К концу 2012 года более 50% приложений работающих на х86 платформе виртуализированы. Вместе с тем виртуализировано только 20% бизнес критических приложений .

Это из-за того что ИТ отделы не доверяют платформам виртуализации? Считают ли они платформы виртуализации не достаточно стабильными для поддержки работы критически важных приложений?

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

Тогда если доверие или стабильность не являются проблемой в чём же причина того что ИТ отделы еще не виртуализировали оставшиеся приложения?

vCenter Operations: Подсчёт параметра Health в редакции Foundation

Меня спрашивали, есть ли разница в том, как работает подсчёт параметра Health в vCOps Foundation? В общем, разница есть с другими редакциями есть, и большая.

В более высоких редакциях (Standard/Advance/Enterprise) данный параметр считается на основе трёх под-параметров: Workload, Anomalies, Faults. В Foundation версии же отсутствуют под-параметры Anomalies и Faults (точнее Faults отображается, но не как отдельный параметр, хотя vCOps и отсылает предупреждения по данному параметру). Что же тогда принимается в расчёт при расчётах?

У ВМ AD01-Server параметр Health составляет 71% без каких-либо Faults. В данном случае расчёт следующий: 100-29 (так как память самый нагруженный ресурс) = 71%.

Перейдём к хосту ESX. На хосте я отключил сетевой интерфейс,что привело к увеличению значения Faults до 70. При этом память хоста загружена на 45%. Исходя из прошлых результатов можно ожидать, что значение Health составит 55%, но, как видно на картинке, оно составляет только 30%. Причина кроется в учёте значения Faults.

Как только я исправил ошибку, значение Health выросло до ожидаемых 57%, так как память хоста нагружена на 43%.

Оригинал: http://www.virtualclouds.co.za/

VMware Metro Stretched Cluster: вопросы из зала

Задали мне вопрос, а точнее даже два, насчет механизмов работы растянутых кластеров. Ну и соотв. как их проектировать.
Предварительное условие: растянутый метрокластер поверх EMC VPLEX.

1) Нужно ли 2 vCenter?

Ответ: нет. В метрокластере работает HA, и при падении одного из сайтов vCenter будет перезапущен на оставшемся. Разумеется, vCenter должен находиться на LUN, защищенном VPLEX.

2) Что произойдет с dvSwitch, если упадет vCenter.

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