В этой статье хочу вкратце рассказать о том, что такое Contrail, в каких формах он доступен и как его поставить себе в лабу. Более конкретно, ставить будем Contrail Cloud 3.2.0.
Основы Contrail
Задача, которую решает Contrail — построение гибких и масштабируемых виртуальных сетей. Виртуальную сеть можно понимать как замену старым-добрым VLAN, в данном случае реализованную примерно как провайдерский L3VPN/EVPN. При этом с точки зрения подключенных клиентов все выглядит так, как будто все их виртуальные машины и физические сервера подключены через обычный коммутатор.
Проще всего описать Contrail как оверлейный SDN. Software-Defined Networking здесь понимается в смысле классического определения ONF — разделение forwarding plane и control plane, плюс централизация control plane в данном случае в Contrail-контроллере.
Слово «оверлейный» указывает на то, что есть на самом деле две сети:
- Физическая «фабрика», от которой требуется «только» обеспечить доступность по IP между подключенными физическими устройствами (серверами, роутерами-шлюзами), и
- Оверлей — сеть, составленная из туннелей, проложенных между серверами и роутерами-шлюзами. Туннели могут быть MPLS over UDP, MPLS over GRE или VXLAN (перечислено в порядке приоритета, установленного по умолчанию; хотя есть некоторые нюансы, в целом конкретный тип используемого туннеля является деталью реализации).
Contrail-контроллер занимается тем, чтобы управлять виртуализированной оверлейной сетью в ЦОДе или провайдерском облаке, и совершенно не лезет в работу фабрики. Отвечая на вопросы «зачем?» и «почему именно?», в качестве сильных сторон Contrail можно отметить:
- Масштабируемость — система построена по тем же принципам, что проверенное временем решение BGP/MPLS VPN.
- Гибкость — изменение конфигурации виртуальной сети не требует изменений в физической сети. Это естественное следствие оверлейности и использования принципа «smart edge — simple core».
- Программируемость — приложения могут управлять сетью как системой через Contrail API.
- NFV (виртуализация сетевых функций) aka service chains (цепочки сервисов) — очень важный аспект, позволяет прогонять трафик через заданные виртуализированные сетевые сервисы (виртуальный фаервол, кэш, и пр.). При этом абсолютно равноправны как VNF от Juniper (vSRX, vMX) так и любые продукты других вендоров.
- Мощная аналитика и визуализация результатов, включая «Underlay Overlay Mapping» — это когда Contrail показывает вам, как трафик между виртуальными сетями идет «на самом деле» по физической сети.
- Open Source — все исходные коды открыты, плюс для взаимодействия частей используются только стандартные протоколы. Сайт проекта — www.opencontrail.org.
- Простая интеграция с существующими MPLS VPNs.
Вот картинка из Contrail Architecture whitepaper, показывающая как система устроена в целом:
На верхнем уровне работает инфраструктурный оркестратор — чаще всего это будет OpenStack (есть варианты интеграции Contrail с vCenter и Kubernetes). В нем сеть настраивается через высокоуровневые команды (Neutron API) — при этом детали реализации остаются заботой SDN-контроллера.
Сам SDN-контроллер состоит из четырех основных типов нодов:
- Конфигурационные ноды — отвечают за предоставление REST API оркестратору и другим приложениям. «Компилирует» инструкции, приходящие «сверху», в конфигурации, применимые в конкретной сети на низком уровне.
- Контрольные ноды — принимают конфигурацию от конфигурационных нодов и программируют vRouter-ы (см. далее) и физические роутеры.
- Аналитика — ноды, собирающие статистику потоков, логи, и прочее.
- База данных (не показана на картинке) — БД Cassandra, в которой хранится конфигурация и собранная аналитикой информация.
На одном физическом (или даже виртуальном) сервере может быть запущено несколько ролей, в лабе можно даже делать контроллер все-в-одном (плюс вычислительные ноды отдельно).
Теперь немного про форвардинг. Весь трафик между виртуальными машинами или контейнерами в системе бегает по туннелям, терминируемым на vRouter, физическом роутере или OVSDB-свиче (этот вариант я тут не рассматриваю). vRouter является софтверной компонентой (модуль ядра Linux по умолчанию, user space если используется DPDK), второй важной частью решения Contrail (первой является собственно контроллер). vRouter-ы устанавливаются и запускаются на вычислительных нодах кластера (Virtualized Server на картинке) — там же, где запускаются машины/контейнеры.
Еще раз, основной задачей vRouter-а является терминирование оверлейного туннеля. vRouter по функциям соответствует PE (provider edge) роутеру в MPLS VPN.
Какой бывает Contrail
Опции использования Contrail у нас следующие (при этом фичи и код везде одни и те же и различаются только опции поддержки):
- OpenContrail — вариант, доступный бесплатно. Установка описана в Quick Start Guide.
- Contrail Networking — коммерческий вариант, поддерживаемый Juniper TAC.
- Contrail Cloud — опять же коммерческий вариант, причем включающий в себя как сам Contrail, так и Canonical/Ubuntu OpenStack — оба поддерживаемые Juniper TAC.
Кроме того, есть вариант с поддержкой OpenContrail от Mirantis.
Я в этой статье пойду по пути наименьшего сопротивления и покажу, как установить Contrail Cloud.
Установка Contrail Cloud
Ставить будем Contrail Cloud 3.2.0 — последнюю версию, на момент написания статьи. Для установки я использовал один ESXi 6.0 сервер с 4-ядерным hyper-threading CPU и 32GB RAM. Этого оказывается достаточно для тестов, даже с запасом (можно еще запустить пару vMX).
Схема виртуальной лаборатории будет выглядеть вот так:
Обратите внимание, что Compute-ноды (как и ноды контроллера) у нас в лабе виртуализированные, то есть виртуалки будут запускаться внутри других виртуалок. Следует пойти в настройки гипервизора и там поставить флажок у опции «Expose hardware assisted virtualization to the guest OS» для каждого Compute-нода. Как видно из testbed.py, первые два у нас собственно для виртуальных машин, и используют KVM, а третий — для контейнеров Docker.
Разворачиваем все 5 виртуалок с параметрами как указано на схеме. При этом для compute-нодов параметры на самом деле определяются тем, сколько и каких машин/контейнеров вы собираетесь запускать, а вот для контроллера параметры указаны близкие к минимально допустимым.
Ставим на все машины минимальную Ubuntu 14.04.4 (ubuntu-14.04.4-server-i386.iso). Строго эту версию, как указано в документации Contrail 3.2.0 — это очень важно! Иначе очень легко можно нарваться на несовместимость пакетов. И именно минимальную, по той же причине. Голый минимум плюс только OpenSSH Server. Почему-то многие люди серьезно не относятся к таким простым инструкциям и потом у них не работает :)
Далее прописываем адреса в /etc/network/interfaces, а в /etc/hosts задаем, чтобы не заморачиваться с DNS,
10.10.10.230 openstack
10.10.10.231 control
10.10.10.233 compute-1
10.10.10.234 compute-2
10.10.10.235 compute-3
Устанавливать Contrail будем с помощью Fabric-скриптов. Этот вариант для лабы наиболее простой, для продакшена есть еще Server Manager (с Puppet под капотом), но это как-нибудь в другой раз. Для Fabric нам понадобится разрешить root login для SSH, например так
echo -e "contrail\ncontrail" | sudo passwd root
sudo sed -i.bak 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config
sudo service ssh restart
Еще желательно включить ntp на всех нодах:
sudo apt-get install ntpДалее, на первом ноде, копируем пакет contrail-install-packages_3.2.0.0-19-ubuntu-14-04mitaka_all.deb в /tmp и устанавливаем его:
dpkg -i /tmp/contrail-install-packages_3.2.0.0-19-ubuntu-14-04mitaka_all.deb Запускаем установочный скрипт:
cd /opt/contrail/contrail_packages
./setup.sh
Теперь важный момент. Нужно создать файл /opt/contrail/utils/fabfile/testbeds/testbed.py, который будет описывать наш кластер. Вот рабочий пример:
from fabric.api import env
# FOR LAB ONLY, DEFAULT IS 250
minimum_diskGB = 10
# MANAGEMENT USERNAME/IP ADDRESSES
host1 = 'root@10.10.10.230'
host2 = 'root@10.10.10.231'
host3 = 'root@10.10.10.233'
host4 = 'root@10.10.10.234'
host5 = 'root@10.10.10.235'
# EXTERNAL ROUTER DEFINITIONS
ext_routers = []
# AUTONOMOUS SYSTEM NUMBER
router_asn = 64512
# HOST FROM WHICH THE FAB COMMANDS ARE TRIGGERED
# TO INSTALL AND PROVISION
host_build = 'root@10.10.10.230'
# ROLE DEFINITIONS
env.roledefs = {
'all': [host1, host2, host3, host4, host5],
'cfgm': [host1],
'openstack': [host1],
'control': [host2],
'compute': [host3, host4, host5],
'collector': [host1],
'webui': [host1],
'database': [host1],
'build': [host_build]
}
# DOCKER
env.hypervisor = {
host5 : 'docker',
}
# NODE HOSTNAMES
env.hostnames = {
'host1': ['openstack'],
'host2': ['control'],
'host3': ['compute-1'],
'host4': ['compute-2'],
'host5': ['compute-3'],
}
# OPENSTACK ADMIN PASSWORD
env.openstack_admin_password = 'contrail'
# NODE PASSWORDS
env.passwords = {
host1: 'contrail',
host2: 'contrail',
host3: 'contrail',
host4: 'contrail',
host5: 'contrail',
host_build: 'contrail',
}
Значение разных разделов, думаю, должно быть понятно без дополнительных пояснений.
Еще всего несколько шагов. Установим пакеты на оставшиеся ноды:
cd /opt/contrail/utils/
fab install_pkg_all:/tmp/contrail-install-packages_3.2.0.0-19-ubuntu-14-04mitaka_all.deb
Поменяем ядро на рекомендуемое:
fab upgrade_kernel_all(версия ядра изменится с 4.2.0-27-generic на 3.13.0-85-generic и ноды перезагрузятся).
Далее перезаходим на первый нод и:
cd /opt/contrail/utils/
fab install_contrail
И, наконец, последний шаг (самый длительный, занимает около часа в моем случае):
fab setup_all
В принципе, все. Но в таком виде при заданных параметрах виртуалок Contrail Cloud подтормаживает. Применим несколько трюков для его ускорения (использовать только для лабы):
echo 'export JAVA_OPTS="-Xms100m -Xmx500m"' > /etc/zookeeper/java.env
sed -i.bak 's/workers = 40/workers = 1/' /etc/nova/nova.conf
sed -i.bak 's/#MAX_HEAP_SIZE="4G"/MAX_HEAP_SIZE="1G"/' /etc/cassandra/cassandra-env.sh
sed -i.bak 's/#HEAP_NEWSIZE="800M"/HEAP_NEWSIZE="500M"/' /etc/cassandra/cassandra-env.sh
(после чего сервера надо перезагрузить; все в сумме дает снижение использования памяти раза в полтора и заметно улучшается отклик на действия вроде запуска виртуалок).
Теперь можно зайти в веб-интерфейс. Openstack Horizon должен быть доступен на 10.10.10.230/horizon, а Contrail Web UI — на 10.10.10.230:8080. С нашими установками логин — admin, пароль — contrail.
Выводы
Надеюсь, что эта статья поможет заинтересованным людям начать разбираться и работать с Contrail 3.2. Полная документация по продукту есть на сайте Juniper. Некоторые примеры того, как дергать Contrail через API, я стараюсь собирать вот здесь.
Всем успехов в работе и хорошего настроения!
Комментарии (13)
pk1
13.02.2017 16:07В случае моей лабы, все крутится на одном сервере, и в роли «IP fabric» выступает просто VMware vSwitch, к которому подключена каждая из машин своим единственным интерфейсом. В реальном ЦОДе фабрика будет состоять из кучи свичей/роутеров вроде Juniper EX/QFX/MX или любого другого вендора. Контрейл работает с оверлеем и ему не важно, из чего состоит фабрика.
vMX и Contrail SDN — перпендикулярны, одно не требует другое. vRouter, упоминаемый в статье — это не vMX, и не похож на него.
Тем не менее MX или vMX роутеры могут использоваться вместе с Contrail — обычно в качестве шлюза, соединяющего физическую сеть (Интернет и пр.) с виртуальной.
Спасибо за хороший вопрос.
vvpoloskin
14.02.2017 01:08Подождите, концепт SDNа обычно состоит в том, что есть некий контроллер (здесь contrail), в который вынесена вся обработка control plane (или я что-то не понимаю?). Вы говорите, что vMX и vRouter перпендикулярны контроллеру. Так чем же в предложенной вами схеме может управлять контроллер? Интересует общий случай, а не конкретно ваша лаба. И может ли контрейл управлять какими-то другими (какими?), не виртуальными, сетевыми железками? Иначе получается, что весь предлагаемый SDN ничто иное, как просто система управления NMS корзинами серверов.
pk1
14.02.2017 01:28Определение SDN — да, совершенно верно, разделение контрол и форвардинг + централизация форвардинга. Здесь все это применимо.
Далее смотрите, Contrail состоит из двух компонент — Contrail Controller (все вместе 4 типа нодов, см. в статье) и Contrail vRouter — это уже не часть контроллера, а forwarding plane компонента (софтверная, запущенная на сервере) — которыми контроллер как раз и командует. См. также картинку.
Когда я сказал что vMX перпендикулярен, имелось в виду что его можно использовать — можно не использовать. Теперь по поводу использовать. Для связи виртуальной сети и физической сети надо иметь роутер — физический (MX) или опять же виртуальный (vMX), вообще годится любой вендор. Этот роутер должен быть настроен примерно как MPLS PE. Ну так вот, в случае Juniper (v)MX, Contrail Controller может таки настраивать эти (v)MX сам — по протоколу NETCONF (это также отмечено на картинке).
Если что-то не ясно, спрашивайте, может завтра яснее получится изложить.pk1
14.02.2017 01:56Перечитал и ужаснулся. Естественно, имелась в виду централизация контрол-плейна, а не форвардинга.
vvpoloskin
14.02.2017 16:19Вот есть абстрактный ЦОД с множеством стоек с блейдами, на которых крутятся множество ВМ. На каждой корзине на одной из ВМ ставится образ vRouter, эта ВМ является маршрутизатором для всех остальных ВМ в этой корзине. Всеми этими vRouterами в каждой корзине управляет один контроллер. Я так все понимаю?
Теперь для ЦОДа для подключения каждой корзины ставится пачка не важно каких коммутаторов (не обязательно qfabric или nexus) и одна PE (упростим). Контроллер может управлять этой же PE. Здесь тоже все верно понял?
А теперь вот вопрос — какой толк от всего этого SDNа, если он не может управлять коммутаторами? И для чего нужен функционал роутера в виде виртуальной машины? Все ВМ все равно по IP терминируются на единственной PE (ну пусть на двух), до каждой ВМ просто тянется влан.pk1
14.02.2017 16:401) Правильно с точностью до того, что vRouter это все-таки не виртуальная машина, а модуль ядра гипервизора — в случае если мы используем KVM-гипервизор, как это обычно предполагается. Правда если делать интеграцию с ESXi, то там vRouter это уже как раз виртуалка и все в точности как вы сказали.
2) Верно. Для разворачивания фабрики предполагается, что должны использоваться другие инструменты. У Джунипера это например OpenClos.
3) Здесь идея в том, что Contrail за счет того что он работает с оверлеем, позволяет вам получить SDN/NFV «прям щас», на любом физическом оборудовании. Никаких вланов через ЦОД больше не тянется, это тоже одно из преимуществ. Собственно одна из задач как раз избавиться от вланов. Как говорится, бродкастный домен = единая точка отказа. Нужна только L3 фабрика. Что если у вас более 4096 клиентов?
Я не понял вопрос насчет роутера в виде виртуальной машины. Это кому как, кому нужно, кому нет. Приложения и задачи разные. Есть концепция NFV (виртуализации сетевых функций), в которой предполагается что все сервисы должны делаться виртуально. Другое дело опять же кому и где это будет актуально. В общем для этого.vvpoloskin
15.02.2017 10:57А если нужно именно L2 между парой ВМ, расположенных на разных корзинах? Здесь без SDNа?
И еще момент — получается весь предлагаемый SDN нужен ТОЛЬКО для виртуальных машин, к реальному физическому оборудованию (серверы, сетевые железки) он практически не относится (за исключением netconf на PE).
P.S. Как говорится, бродкастный домен = единая точка отказа. Нужна только L3 фабрика. Что если у вас более 4096 клиентов? Если грамотно все сделать, не будет в одном не разделенном L2 столько оборудования, которое будет создавать проблемы. Больше 4094 — есть QinQ. Кроме того, мне с трудом представляется схема, когда на один порт PE (хоть 100GE) будет создано больше 4094 статических сабов (не vitrual-template).pk1
15.02.2017 13:05Связность по L2 Contrail обеспечивает, просто в оверлей упаковывается фрейм целиком. Собственно это работает по умолчанию. L3-оверлей он тоже умеет.
Основное применение — да, для облаков где все виртуальное. Есть вариант когда ваши свичи (любой в принципе вендор) терминируют VXLAN и Contrail с ними общается по OVSDB. Тогда и обычные bare-metal сервера можно подключать.
ayurtaykin
13.02.2017 18:11зачем такое поднимать без vMX? оверлейный sdn без гейта — это вещь в себе.
pk1
13.02.2017 18:16Вы имеете в виду в лабе? У меня-то оно есть. Но просто установка vMX это немножко отдельная тема. А играться можно и без шлюза, смотря что хотим тестировать.
Также есть Simple Virtual Gateway — это когда из VRF напрямую дается доступ в сеть фабрики. Как-бы шлюз но без туннелирования. Для лабы годится.
vvpoloskin
Не до конца понятно, IP Fabric (Underlay network) — это что? Обычные Juniper-овские коммутаторы, которые управляются с контроллера? Или какая-то специфичная линейка оборудования? По схеме не вижу, чтобы они как-то были связаны с Contrail. Весь SDN работает только с виртуальными маршрутизаторами vMX?
pk1
см. ответ ниже