OpenStack Networking » History » Version 13
Version 12 (Raphael Cóbe, 26 Jun 2013 14:00) → Version 13/41 (Raphael Cóbe, 26 Jun 2013 14:01)
h1. OpenStack Networking - Netron
h2. Netron Standard Architecture
* cloud controller host (Cloud Controller Node): quantum-server, nova-api, nova-scheduler, keystone, RabbitMQ, MySQL.
* network gateway host (Network Node): quantum-metadata-agent, quantum-dhcp-agent, quantum-l3-agent, quantum-*-plugin-agent
* conjunto de hypervisors para rodar VMs. Compute node: nova-compute, quantum-*-plugin-agent
> cloud controller host e network gateway host podem ser combinados em uma máquina, porém é recomendado que exista um network gateway host separado para evitar restrições de CPU entre os encaminhamentos realizados pelo quantum-l3-agent e outros serviços OS.
* DataNetwork: comunicação de dados dentro da implementação de nuvem.
* Management Network: comunicações entre componentes OS.
* External Network: oferece acesso à internet à implementação OS.
* API Network: expõe todas as APIs do OS, incluindo a Netron API para os tenants. Pode ser a própria rede externa utilizando o recurso de subredes para separação.
h2. Neutron Server
quantum-server: processo principal do Netron. Expõe Netron API e encaminha as requisições de usuário para o plugin.
h2. Agentes
Agentes enviam mensagens para o Quantum-Server via RPC (rabbitmq ou qpid) ou Netron API padrão (REST).
* plugin agent (quantum-*-agent): roda em cada hypervisor para realizar configuração local do vswitch. Dependente do plugin escolhido.
* dhcp agent (quantum-dhcp-agent). serviço de DHCP para redes dos tentents. Usado quando as VMs devem receber IP de forma automatizada. Endereços via DHCP. Requer no mínimo dnsmasq 2.59. Configurado especificamente para o plugin utilizado.
* L3 agent (quantum-l3-agent). Encaminhamento L3/NAT para oferecer acessos as redes externas. Roteador que conecta as redes L2. Fica no Network Node. Usa: Linux IP Stack e IP tables.
** Deve-se garantir que existam rotas entre o serviço de metadata do host e cada rede privada.
** Nós que rodem quantum-l3-agent não devem ter endereços IP especificados manualmente para a NIC conectada a rede externa e sim uma faixa de IPs que poderá ser usada para roteamento.
<pre>
$ sudo ovs-vsctrl add-br br-ext
$ sudo ovs-vsctrl add-port br-ext eth1
</pre>
* não é possível executar ping para IPs fixos. Ao invés disso, usar: router network namespace (qrouter-<UUID>)
<pre> $ ip netns exec qrouter-<UUID> ping <fixed ip> </pre>
h2. Netron API
Serviço de redes virtual. Define conexões e endereços para os outros serviços.
* Network: segmento L2 isolado (análogo a uma VLAN).
* Subnet: bloco de endereços de IP (V4 ou V6) e estados de configuração associados.
* Port: ponto para conexção de dispositivos.
<pre>
network <-- port
| |
-------------- subnet
</pre>
> fixed_ips é atributo do port
> port.fixed_ips = {<IP1>:<subnet1>, <IP2>:<subnet2>, ...}
h2. Netron Plugins
Projeto original assume um modelo muito básico para realizar isolamento através de Linux VLANs e tabelas IP. Netron introduz o conceito de plugin, que é a
implementação de requisições lógicas de API em forma de um back-end acoplável. Padrão: Open vSwitch e Linux Bridge. Plugin deve estar em cada nó que usa
pacotes de dados.
Os plugins devem processar chamadas de API e gerenciar vSwitches.
OpenVSwitch: open vswitch, quantum-plugin-openvswitch-agent
$ sudo ovs-vsctrl add-br br-int
* br-int: integration bridge, nome padrão e fixo.
h2. Netron Standard Architecture
* cloud controller host (Cloud Controller Node): quantum-server, nova-api, nova-scheduler, keystone, RabbitMQ, MySQL.
* network gateway host (Network Node): quantum-metadata-agent, quantum-dhcp-agent, quantum-l3-agent, quantum-*-plugin-agent
* conjunto de hypervisors para rodar VMs. Compute node: nova-compute, quantum-*-plugin-agent
> cloud controller host e network gateway host podem ser combinados em uma máquina, porém é recomendado que exista um network gateway host separado para evitar restrições de CPU entre os encaminhamentos realizados pelo quantum-l3-agent e outros serviços OS.
* DataNetwork: comunicação de dados dentro da implementação de nuvem.
* Management Network: comunicações entre componentes OS.
* External Network: oferece acesso à internet à implementação OS.
* API Network: expõe todas as APIs do OS, incluindo a Netron API para os tenants. Pode ser a própria rede externa utilizando o recurso de subredes para separação.
h2. Netron Command Line Application
Requer: python-pyparsing, python-cliff, python-quantumclient
h2. OSC (OS Compute)
Interagem com Netron através da API. Comunica com Netron API para connectar cada vNIC da VM em uma rede em particular.
h2. Neutron Client
agent-*
dhcp-agent-*
ext-* (extensões)
floatingip-*
l3-agent-*
lb-* (loading balance)
lb-pool-*
lb-healthmonitor-*
lb-member-*
lb-vip-*
net-*
queue-*
router-*
security-*
subnet-*
quota-*
security-group-*
h2. Exemplos - Netron API
$ quantum net-create net1
$ quantum net-create net2 --provider:network_type local
$ quantum net-create --tenant-id=<id> net1
$ quantum subnet-create net1 192.168.0.2/22 --name subnet1
$ quantum port-create net1 --fixed-ip ip_addr=192.168.2.40
$ quantum port-create net1
$ quantum port-list --fixed-ips
$ quantum port-list --tenant-id=<tenant id>
$ quantum port-list --device-id=<vm id>
* as redes já devem estar criadas para serem adicionadas na instanciação das VMs
$ nova boot --image=<img id> --flavor=<fl id> --nic net_id=<net id> <vm name>
* para ip fixo (port deve ser criado antes da instanciação)
$ nova boot --image=<img id> --flavor=<fl id> --nic port_id=<net id> <vm name>
h2. Físico -> Virtual
1) eth0 (VM)
2) TAP VNET0 (hypervisor network interface card, VIF, vNIC)
3) LINUX BRIDGE qbrXXX (hub, multi NIC, virtual ou físico)
4) veth pair {qcbXXX, qvoXXX} (entra de um lado e sai do outro)
5) open switch bridge br-int (virtual switch, integration bridge,todos as VM estão conectadas a ele)
6) veth pair (int-br-eth1, phy-br-eth1)
7) physical network interface card eth1
h2. Ryu
$ sudo pip install ryu
$ sudo apt-get install quantum-plugin-ryu-agent openvswitch-switch python-openvswitch openvswitch-datapath-dkms
* ovs_ryu_plugin.ini e quantum.conf devem ser copiados em cada nó que tenha agente ryu
h2. Not to do
* Proxies ainda não implementados então não se deve executar:
** nova-manage
** nova para administrar recursos de rede
h2. Netron Standard Architecture
* cloud controller host (Cloud Controller Node): quantum-server, nova-api, nova-scheduler, keystone, RabbitMQ, MySQL.
* network gateway host (Network Node): quantum-metadata-agent, quantum-dhcp-agent, quantum-l3-agent, quantum-*-plugin-agent
* conjunto de hypervisors para rodar VMs. Compute node: nova-compute, quantum-*-plugin-agent
> cloud controller host e network gateway host podem ser combinados em uma máquina, porém é recomendado que exista um network gateway host separado para evitar restrições de CPU entre os encaminhamentos realizados pelo quantum-l3-agent e outros serviços OS.
* DataNetwork: comunicação de dados dentro da implementação de nuvem.
* Management Network: comunicações entre componentes OS.
* External Network: oferece acesso à internet à implementação OS.
* API Network: expõe todas as APIs do OS, incluindo a Netron API para os tenants. Pode ser a própria rede externa utilizando o recurso de subredes para separação.
h2. Neutron Server
quantum-server: processo principal do Netron. Expõe Netron API e encaminha as requisições de usuário para o plugin.
h2. Agentes
Agentes enviam mensagens para o Quantum-Server via RPC (rabbitmq ou qpid) ou Netron API padrão (REST).
* plugin agent (quantum-*-agent): roda em cada hypervisor para realizar configuração local do vswitch. Dependente do plugin escolhido.
* dhcp agent (quantum-dhcp-agent). serviço de DHCP para redes dos tentents. Usado quando as VMs devem receber IP de forma automatizada. Endereços via DHCP. Requer no mínimo dnsmasq 2.59. Configurado especificamente para o plugin utilizado.
* L3 agent (quantum-l3-agent). Encaminhamento L3/NAT para oferecer acessos as redes externas. Roteador que conecta as redes L2. Fica no Network Node. Usa: Linux IP Stack e IP tables.
** Deve-se garantir que existam rotas entre o serviço de metadata do host e cada rede privada.
** Nós que rodem quantum-l3-agent não devem ter endereços IP especificados manualmente para a NIC conectada a rede externa e sim uma faixa de IPs que poderá ser usada para roteamento.
<pre>
$ sudo ovs-vsctrl add-br br-ext
$ sudo ovs-vsctrl add-port br-ext eth1
</pre>
* não é possível executar ping para IPs fixos. Ao invés disso, usar: router network namespace (qrouter-<UUID>)
<pre> $ ip netns exec qrouter-<UUID> ping <fixed ip> </pre>
h2. Netron API
Serviço de redes virtual. Define conexões e endereços para os outros serviços.
* Network: segmento L2 isolado (análogo a uma VLAN).
* Subnet: bloco de endereços de IP (V4 ou V6) e estados de configuração associados.
* Port: ponto para conexção de dispositivos.
<pre>
network <-- port
| |
-------------- subnet
</pre>
> fixed_ips é atributo do port
> port.fixed_ips = {<IP1>:<subnet1>, <IP2>:<subnet2>, ...}
h2. Netron Plugins
Projeto original assume um modelo muito básico para realizar isolamento através de Linux VLANs e tabelas IP. Netron introduz o conceito de plugin, que é a
implementação de requisições lógicas de API em forma de um back-end acoplável. Padrão: Open vSwitch e Linux Bridge. Plugin deve estar em cada nó que usa
pacotes de dados.
Os plugins devem processar chamadas de API e gerenciar vSwitches.
OpenVSwitch: open vswitch, quantum-plugin-openvswitch-agent
$ sudo ovs-vsctrl add-br br-int
* br-int: integration bridge, nome padrão e fixo.
h2. Netron Standard Architecture
* cloud controller host (Cloud Controller Node): quantum-server, nova-api, nova-scheduler, keystone, RabbitMQ, MySQL.
* network gateway host (Network Node): quantum-metadata-agent, quantum-dhcp-agent, quantum-l3-agent, quantum-*-plugin-agent
* conjunto de hypervisors para rodar VMs. Compute node: nova-compute, quantum-*-plugin-agent
> cloud controller host e network gateway host podem ser combinados em uma máquina, porém é recomendado que exista um network gateway host separado para evitar restrições de CPU entre os encaminhamentos realizados pelo quantum-l3-agent e outros serviços OS.
* DataNetwork: comunicação de dados dentro da implementação de nuvem.
* Management Network: comunicações entre componentes OS.
* External Network: oferece acesso à internet à implementação OS.
* API Network: expõe todas as APIs do OS, incluindo a Netron API para os tenants. Pode ser a própria rede externa utilizando o recurso de subredes para separação.
h2. Netron Command Line Application
Requer: python-pyparsing, python-cliff, python-quantumclient
h2. OSC (OS Compute)
Interagem com Netron através da API. Comunica com Netron API para connectar cada vNIC da VM em uma rede em particular.
h2. Neutron Client
agent-*
dhcp-agent-*
ext-* (extensões)
floatingip-*
l3-agent-*
lb-* (loading balance)
lb-pool-*
lb-healthmonitor-*
lb-member-*
lb-vip-*
net-*
queue-*
router-*
security-*
subnet-*
quota-*
security-group-*
h2. Exemplos - Netron API
$ quantum net-create net1
$ quantum net-create net2 --provider:network_type local
$ quantum net-create --tenant-id=<id> net1
$ quantum subnet-create net1 192.168.0.2/22 --name subnet1
$ quantum port-create net1 --fixed-ip ip_addr=192.168.2.40
$ quantum port-create net1
$ quantum port-list --fixed-ips
$ quantum port-list --tenant-id=<tenant id>
$ quantum port-list --device-id=<vm id>
* as redes já devem estar criadas para serem adicionadas na instanciação das VMs
$ nova boot --image=<img id> --flavor=<fl id> --nic net_id=<net id> <vm name>
* para ip fixo (port deve ser criado antes da instanciação)
$ nova boot --image=<img id> --flavor=<fl id> --nic port_id=<net id> <vm name>
h2. Físico -> Virtual
1) eth0 (VM)
2) TAP VNET0 (hypervisor network interface card, VIF, vNIC)
3) LINUX BRIDGE qbrXXX (hub, multi NIC, virtual ou físico)
4) veth pair {qcbXXX, qvoXXX} (entra de um lado e sai do outro)
5) open switch bridge br-int (virtual switch, integration bridge,todos as VM estão conectadas a ele)
6) veth pair (int-br-eth1, phy-br-eth1)
7) physical network interface card eth1
h2. Ryu
$ sudo pip install ryu
$ sudo apt-get install quantum-plugin-ryu-agent openvswitch-switch python-openvswitch openvswitch-datapath-dkms
* ovs_ryu_plugin.ini e quantum.conf devem ser copiados em cada nó que tenha agente ryu
h2. Not to do
* Proxies ainda não implementados então não se deve executar:
** nova-manage
** nova para administrar recursos de rede