Это первая из цикла статей, описывающих более глубокое изучение мной Nicira Network Virtualization Platform (NVP). Как по мне NVP это прекрасный продукт, но о котором доступно очень мало информации: как он работает, как он настраивается и т.д - именно эту проблему я и собираюсь решить данным циклом статей. И начнём с высокоуровнего описания архитектуры.
Перед тем как начать хотелось бы прояснить взаимосвязь между NVP и NSX. Данный цикл будет акцентироваться на NVP - продукте который уже доступен, и используется некоторыми компаниями. Архитектура которую я тут буду описывать также будет применима и к стеку NSX, который VMware анонсировала в марте, так как NSX будет использовать архитектуру NVP, так что изучение NVP сейчас поможет с NSX в будущем.
Начнём с картинки - схема внизу показывает высокоуровневую архитектуру 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 трафик будет обрабатываться каждым гипервизором локально.
Комментариев нет:
Отправить комментарий