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

Как работает планировщик процессора ESXi. Презентация с VMUG 2013.

Как заставить ESXi5 видеть диск как SSD datastore

В vSphere 5 представлена новая функция Host Cache, которая позволяет выгрузить своп файл виртуальной машины на выделенный SSD диск для повышения производительности. Для этого на диске, который SATP (Storage Adapter Type Plugin) опознала как твердотельный, создать VMFS раздел, добавить и настроить данное VMFS хранилище для хранения кэша.

Во время тестирования vSphere 5 тестировал самые разнообразные функции, включая Host Caching, но у меня не было доступа к системе с SSD диском во время обновления и создания новых скриптов. После небольшого расследования я узнал, что стандартное правило SATP не опознаёт определённый твердотельный диск, и что можно создать новое правило, содержащее мета информацию о данном конкретном устройстве.

В данном примере я заставлю ESXi 5 думать, что локальный диск mpx.vmhba1:C0:T2:L0 является SSD диском.

Необходимо иметь доступ к esxcli, без разницы через локальную оболочку ESXi, vMA или PowerCLI.

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

Для начала необходимо создать новое SATP правило, в котором будет указан диск, и enable_ssd как опция параметра option.

esxcli storage nmp satp rule add --satp VMW_SATP_LOCAL --device mpx.vmhba1:C0:T2:L0 --option=enable_ssd

Проверить правильность создания можно с помощью листинга всех правил

esxcli storage nmp satp rule list | grep enable_ssd

VMW_SATP_LOCAL       mpx.vmhba1:C0:T2:L0  enable_ssd                  user

Теперь необходимо перерегистрировать диск в системе, чтобы применить к нему новое правило.

esxcli storage core claiming reclaim -d mpx.vmhba1:C0:T2:L0

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

esxcli storage core device list --device=mpx.vmhba1:C0:T2:L0

mpx.vmhba1:C0:T2:L0
   Display Name: Local VMware Disk (mpx.vmhba1:C0:T2:L0)
   Has Settable Display Name: false
   Size: 5120
   Device Type: Direct-Access
   Multipath Plugin: NMP
   Devfs Path: /vmfs/devices/disks/mpx.vmhba1:C0:T2:L0
   Vendor: VMware
   Model: Virtual disk
   Revision: 1.0
   SCSI Level: 2
   Is Pseudo: false
   Status: on
   Is RDM Capable: false
   Is Local: true
   Is Removable: false
   Is SSD: true
   Is Offline: false
   Is Perennially Reserved: false
   Thin Provisioning Status: unknown
   Attached Filters:
   VAAI Status: unsupported
   Other UIDs: vml.0000000000766d686261313a323a30

Теперь параметр Is SSD имеет значение true.

Вы можете обновить Storage view в vSphere Client или через командную строку командой vim-cmd hostsvc/storage/refresh.

Теперь в vSphere Client в разделе Host Cache Configuration появится новый твердотельный диск, который необходимо добавить для использования Host Cache.

Официально это, конечно же, не поддерживается.


Оригинал: http://www.virtuallyghetto.com/

Резервирование всей памяти Виртуальной машины (all locked)

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

Настройки резервирования памяти статичны, то есть если пользователь изменит объём памяти у ВМ, то настройки резервирования останутся предыдущими. Если же необходимо, чтобы объём зарезервированной памяти всегда равнялся объёму сконфигурированной памяти - в интерфейсе, как классическом, так и вэб, есть опция Reserve all guest memory (all locked).

Это опция напрямую связана с настройками объёма памяти виртуальной машины - при увеличении объёма выделенной ОЗУ увеличиться и резерв, при уменьшении, соответственно, уменьшится.

Эта опция очень полезна когда vSphere Client используется как инструмент управления инфраструктурой, так как настройка выделения объёма памяти и опции резервирования находятся в разных вкладках. В результате, при изменении выделенного объёма ОЗУ администратор может забыть изменить настройки резервирования.

В вэб клиенте представлен обновлённый дизайн, и настройки выделения и резервирования памяти теперь представлены на одном экране, что сводит возможные ошибки к минимуму.

Оригинал: http://frankdenneman.nl/