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, и вся инфраструктура продолжит свою работу.