OpenStack и Quantum: начало

 

Из wiki.openstack.org:

Quantum is an OpenStack project to provide “network connectivity as a service” between interface devices (e.g., vNICs) managed by other Openstack services (e.g., nova).

Из описания можно предположить, что в будущем это станет заменой nova network, что не далеко от правды. Ниже я расскажу об установки OpenStack + Quantum и немного о самом Quantum.

Установка OpenStack c помощью скриптов devstack является одной из самых простых и быстрых. В простейшем случае, это выглядит так:

$ git clone https://github.com/openstack-dev/devstack.git$ cd devstack && ./stack.sh

После этого нужно будет лишь ввести свой root-пароль, пароль к MySql серверу и пароли к Openstack’у. При установке Quantum нужно создать и/или отредактировать файл localrc в каталоге с Devstack’ом и добавить туда следующие строчки:

disable_service n-netenable_service q-svcenable_service q-agtenable_service q-dhcpenable_service quantumLIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriverQ_PLUGIN=openvswitch

Разберем эти строчуки подробнее:

 

  • LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver - настраивваем libvirt для корректной работы файрволла с Quantum
  • Q_PLUGIN=openvswitch - указываем, что в качестве плагина (back-end’а) использовать Open vSwitch.
  • disable_service n-net - отключение nova-network, теперь вместо этого компонента будет работать Quantum.
  • enable_service q-svc - включаем Quantum Server. По сути, после скачивания исходников и первоначальной настройки выполнится такая команда: “/opt/stack/quantum/bin/quantum-server –config-file /etc/quantum/quantum.conf –config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini”. На момент написания этого поста есть баг, в котором описано что Quantum plugins должны использовать тот жу конфигурационный файл, что и Quantum. Но пока это не пофикшено.
  • enable_service q-agt - запустить Quantum agent. Т.к. в качестве плагина был выбран Open vSwitch, то и запустится, соответственно, Open vSwitch Plugin:** $ sudo python /opt/stack/quantum/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py –config-file /etc/quantum/quantum.conf –config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini**
  • enable_service q-dhcp - Quantum DHCP Agent, который управляет DHCP сервером внутри нашей виртуальной сети. Запускается он следующей командой:  sudo python /opt/stack/quantum/bin/quantum-dhcp-agent –config-file /etc/quantum/quantum.conf –config-file=/etc/quantum/dhcp_agent.ini.  Из коробки это dnsmasq, но можно написать поддержку любого сервера.

 

После правки localrc можно запускать stack.sh и подождать пока все будет установленно.

Кроме установки самого OpenStack’а, devstack так же создает тестовых пользователей, проектов и сети. Т.к. говорим о Quantum, то о сетях подробнее.

Сам по себе Quantum (так сказать, его core) предоставляет только API для создания и управления сетями. Самим управлением занимаются его плагины (plugins), которые, imho, правильнее было бы назвать бэк-ендами (back-ends). В текущей версии (Folsom) возможна одновременная работа только одного плагина. Т.к. мы установили Open vSwitch, то далее буду описывать работу Quantum с ним.

Основные понятия в Quantum:

 

  • network - изолированный L2 сегмент сети, аналог VLAN;
  • subnet - блок IPv4 или IPv6 адресов и их конфигурация (маршрутизатор, DNS-сервер)
  • port - точка подключения устройств (vNICs) в сеть Quantum.

 

Если смотреть на взаимодействие Quantum Network и OpenStack, то это выглядит так:

У каждого тенанта может быть одна и более сетей. У каждой сети может быть от 1 до n подсетей (конечно, может быть и 0 сетей/подсетей, по смысла в этом нет). Если смотреть на то, как все рабтало без Quantum, то теперьешине subnets это аналоги nova networks. При замуске виртуалки (инстанса), ей нужног передать к какой из сетей тенанта она подключена. Для каждой подсети будет создан отдельный vNIC у инстанса, который будет подключен к какому-либо порту. В нашем случае - это порт в Open vSwitch.

Посмотрим как это работает на практики:

Open vSwitch работает поверх бриджей (bridge), поэтому посмотрим какие “мосты” у нас есть:

**$ sudo ovs-vsctl list-br****br-int**br-tun

Сейчас нас интересует br-int, поэтому посмотрим какие у него есть порты:

$ sudo ovs-vsctl list-ports br-int****

**patch-tun****tap6d98326d-5a****tap6e1a8612-27**tapf842abe0-27

В данной конфигурации, у меня запущено два инстанса, которые подключены к портам tap6e1a8612-27 и tapf842abe0-27. Порт patch-tun служит для “проброса” трафика между виртуальной сетью и физической через TUN-интерфейс. К порту tap6d98326d-5a подключен DHCP-сервер(dnsmasq) для инстансов внутри subnet.

Посмотрим, какие у нас есть сети в Quantum:

$ quantum net-list

 

И подсети:

$ quantum subnet-list

 

Порты:

$ quantum port-list

 

Тут мы видем, что у нашего DHCP-сервера адрес 10.0.1.2, а у инстансов 10.0.1.3 и 10.0.1.4.

 

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

$ nova boot –flavor 1 –image 4032fc9c-4688-4e71-ba2d-5a90e7698230 –nic net-id=3d5a9b8d-40cf-4f7b-a344-3db20f1a4783 test_vm_3

Синтаксис стандартный за исключением того, что я явно передал к какой сети подключать инстанс “–nic net-id=3d5a9b8d-40cf-4f7b-a344-3db20f1a4783”

Убедимся, что инстанс запустился командой “nova list”. И если у него статус ACTIVE, то можно попробовать попинговать или зайти по SSH:

 

Все дело в том, что Quantum организует работу с сетями через network netspace (http://stuff.onse.fi/man?program=ip-netns&section=8), поэтому, алгоритм работы немного усложняется:

смотрим список текущих неймспейсов:

$ ip netns

Выполняем ping/ssh внутри нужного неймспейса:

~$ sudo ip netns exec qdhcp-3d5a9b8d-40cf-4f7b-a344-3db20f1a4783 ssh 10.0.1.4

 

Ссылки по теме:

 

Продолжение следует…

Tags

.net .net-framework .net-framework-3.5 agile ajax ajax-control-toolkit ampq ansible apache asp.net asp.net-mvc automation axum babel bash benchmark blog blog-engine bootstrap buildout c# cache centos chrome ci cinder ckan cli cloud code-review codeplex community config debugger deface dependencies development-environment devices devstack devtime disks django dlr dns docker dockerimage dos easy_install elmah encoding environment-variables error event events everything-as-a-code exception exceptions fabrik firefox flask foreach forms fstab gae gcc gerrit git github go google google-app-engine grep hack hacked hardware headless horizon hound html hugo iaas ienumerable iis internet iptables iron-python ironic iscsi java-script javascript jenkins jquery js jsx k8s kharkivpy kiss kombu kubernetes kvm kyiv lettuce libvirt linux lio loci logging loopback losetup lvm mac-os macos mercurial microsoft microsoft-sync-framework mobile mono ms-office msbuild networking news nginx npm npx offtopic oop open-source open-xml opensource openstack openvswitch os packages paraller-development patterns-practices performance php pika pip plugins pnp podcast popup postgresql profiler project protocols proxy pycamp pycharm pycon pykyiv pylint pypi python python-3 qcow quantum qumy rabbitmq rar react reactjs refactoring rfc rhel search-engine security selenium server shell silverlight socket software-engineering source-control sourcegear-vault sources sql sql-server sql-server-express sqlalchemy ssh static-site sublimetext svg tests tgt tipfy todo tornado typescript uapycon ui uneta unit-tests upgrades usability vim virtualenv visual-studio vitrage vm vue.js vuejs web-development web-server web-service web_root webpack webroot windows windows-live word-press x32 x64 xcode xml xss xvfb интернет-магазин книги

Recent posts

Go 1.18: new features

Всё будет Kubernetes

2022 Relaunch

Everyday Blogging

I don't want this CI


Archives

2022 (3)
2019 (73)
2018 (2)
2017 (3)
2016 (2)
2015 (3)
2014 (5)
2013 (17)
2012 (22)
2011 (36)
2010 (25)
2009 (35)
2008 (32)
2007 (2)