Configuração de rede básica de múltiplos nós do Openstack / PackStack

1

Antecedentes

Depois de ter instalado o OpenStack com PackStack, ficamos com um problema com a rede. Queríamos uma rede super simples com uma sub-rede onde todas as máquinas virtuais residissem, pois isso parecia a solução mais simples. Temos que começar com três nós que estão rodando nova.

O arquivo de resposta que usamos é o seguinte: arquivo de resposta (pastebin)

Nossa configuração

Três nós com o CentOS 6.5, onde os nós estão conectados a dois switches.

  • eth0: public
  • eth1: rede interna, ip 10.0.20.0/24 onde node1 (10.0.20.1), node2 (10.0.20.2) ...
  • As portas do switch não são marcadas com vlan ou entroncadas (infelizmente).
  • Queremos que as instâncias possam se comunicar, mas também acessem a Internet.

Regras do grupo de segurança

Ingress IPv4    TCP 1 - 65535   0.0.0.0/0 (CIDR)
Ingress IPv4    TCP 22 (SSH)    0.0.0.0/0 (CIDR)
Ingress IPv6    Any -       default
Ingress IPv4    TCP 22 (SSH)    10.0.20.0/24 (CIDR)
Ingress IPv4    TCP 53 (DNS)    0.0.0.0/0 (CIDR)
Egress  IPv4    Any -       0.0.0.0/0 (CIDR)
Ingress IPv4    ICMP    -       0.0.0.0/0 (CIDR)
Egress  IPv6    Any -       ::/0 (CIDR)
Ingress IPv4    Any -       default

Neutron

(neutron) agent-list
+--------------------------------------+--------------------+------------------------
| id                                   | agent_type         | host  | alive | admin_state_up
+--------------------------------------+--------------------+------------------------
| 09add8dd-0328-4c63-8a79-5c61322a8314 | L3 agent           | host3 | :-)   | True
| 0d0748a9-4289-4a5d-b1d9-d06a764a8d25 | Open vSwitch agent | host2 | :-)   | True
| 258c92fe-8e3a-4760-864e-281a47523e85 | Open vSwitch agent | host1 | :-)   | True
| 2e886dc1-af93-4f4f-b66c-61177a6c9dba | L3 agent           | host1 | :-)   | True
| 50f37a33-2bfc-43f2-9d2f-4f42564d234d | Open vSwitch agent | host3 | :-)   | True
| 535bf0a3-06aa-4072-ae5a-1b1ba1d377ab | L3 agent           | host2 | :-)   | True
| 9b17ef73-a602-4b5d-a4e9-e97445e594b4 | DHCP agent         | host1 | :-)   | True

ovs-vsctl

Host1

ovs-vsctl show

43da814e-223c-4f66-ba2d-c3c9de91e1f8
    Bridge br-ex
        Port br-ex
            Interface br-ex
                type: internal
    Bridge br-int
        Port br-int
            Interface br-int
                type: internal
        Port "tap3e0d3121-32"
            tag: 4
            Interface "tap3e0d3121-32"
                type: internal
        Port "tap4a397755-29"
            tag: 4
            Interface "tap4a397755-29"
    ovs_version: "1.11.0"
Host2
afa75816-6a40-4f0c-842f-236a3a94cd63
    Bridge br-int
        Port br-int
            Interface br-int
                type: internal
        Port "tap46f55af8-73"
            tag: 1
            Interface "tap46f55af8-73"
    Bridge br-ex
        Port br-ex
            Interface br-ex
                type: internal
    ovs_version: "1.11.0"

Fora do problema

As instâncias não podem se comunicar entre si e não podem acessar a Internet. Francamente, não temos certeza de quais são os requisitos para isso ao usar uma configuração nova de vários nós quando a rede "interna" entre os nós estiver usando apenas um link. Eu acho que o problema é um problema de roteamento, uma vez que não somos capazes de conectar entre as instâncias em nós diferentes, mas depois de ter lido muita documentação, não tenho certeza de como prosaed. Se eu tcpdump a interface br-int eu posso ver os pedidos ARP, mas nada mais. Isto é, se eu tentar fazer ping de uma instância no respectivo host.

A questão

Portanto, a pergunta é: como podemos nos dedicar a encontrar a solução para esse problema de rede de vários nós, e sobre o que precisamos pensar? Poderia ser o roteamento ou uma configuração incorreta com o host ou openstack? (Rodando o CentOS).

Qualquer feedback é altamente recomendado, já que estamos presos neste ponto por algumas semanas. Desculpe pelo longo post, mas espero que a informação necessária esteja aqui. Se não; não seja tímido:)

Atualizar

Consegui consertar a rede interna entre os nós, para que as instâncias possam se comunicar entre os nós físicos.

- Changed the /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:
[database]
connection = mysql://neutron:[email protected]:3306/ovs_neutron

[OVS]
tennant_network_type = gre
tunnel_id_ranges = 1:1000
integration_brige = br-int
tunnel_bridge = br-tun
local_ip = 10.0.20.1
enable_tunneling = True

- Restarted the service on controller
cd /etc/init.d/; for i in $( ls neutron-* ); do sudo service $i restart; done )
service openvswitch restart

Isso foi feito em todos os nós e criou os túneis GRE. Embora o fluxo não funcionasse, eu precisava usar ovs-ofctl add-flow br-tun action=normal .

O problema atual que tenho agora é poder rotear a sub-rede interna para a internet, para que todas as instâncias obtenham acesso à Internet. Preciso de ips flutuantes para poder conectar-me à internet? Não há nenhum patch entre br-int e br-ex ou os roteadores, então isso é necessário para poder direcionar o tráfego para a internet?

Posso adicionar uma rota padrão com ip netns exec ... ip adicionar gw padrão via (ip de br-ex) ou preciso adicionar novas interfaces?

    
por larhauga 04.03.2014 / 19:47

2 respostas

0

Como atualizado anteriormente, consegui colocar a rede em funcionamento usando o tunelamento GRE em vez da nova rede. O networking da Nova parece ser uma solução ok se você tiver uma interface de rede física extra, mas quando você não faz isso, não funciona tão bem.

A configuração do GRE foi feita com o seguinte:     - Alterou o /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:

[database]
connection = mysql://neutron:[email protected]:3306/ovs_neutron

[OVS]
tennant_network_type = gre
tunnel_id_ranges = 1:1000
integration_brige = br-int
tunnel_bridge = br-tun
local_ip = "internal ip"
enable_tunneling = True

- Restarted the service on controller
cd /etc/init.d/; for i in $( ls neutron-* ); do sudo service $i restart; done )
service openvswitch restart

Isso foi copiado em cada nó de cálculo. Entretanto, a parte importante ao usar túneis GRE é que, quando você cria uma nova rede, é necessário especificar o ID de segmentação. Se você tentar criar a rede via horizonte, não funcionará.

keystone tenant-list
admin=$(keystone tenant-list | grep admin | awk -F' |' '{ print $2 }')
neutron net-create --tenant-id $admin network --provider:network_type gre --provider:segmentation_id 3
neutron subnet-create --tenant-id $admin network 192.168.0.0/24 --getaway 192.168.0.1

Você também pode adicionar uma rede externa com os seguintes comandos:

neutron net-create ext
neutron net-list
neutron subnet-create extnet --allocation-pool start=10.0.0.10,end=10.0.0.100 --gateway=10.0.0.1 --enable_dhcp=False 10.0.0.0/24

Em seguida, podemos criar um novo roteador e conectar a rede a esse roteador externo. Isso é apenas uma das muitas soluções.

intsubnet=$(neutron subnet-list | grep 192.168.0.0/24| awk -F' |' '{ print $2 }')
extnet=$(neutron net-list | grep ext | awk -F' |' '{ print $2 }')

neutron router-create ext-to-int --tenant-id $admin
router=$(neutron router-list | grep ext-to-int | awk -F' |' '{ print $2 }')

neutron router-interface-add $router $intsubnet
neutron router-gateway-set $router $extnet

No começo, eu tinha um rendimento muito baixo das instâncias. Isso foi resolvido quando eu distribuí o novo MTU (1454) com DCHP (crie um arquivo de configuração dhcp em / etc / neutron / e adicione dhcp-option-force=26,1454 ao arquivo. Atualize dnsmasq_config_file em /etc/neutron/dhcp_agent.ini

Isso funcionou para mim e foi tudo o que foi necessário.

    
por 06.04.2014 / 13:38
0

Sente-se e assista this .

Ele percorre a configuração de um cluster simples de vários nós e achei muito claro. O último bit sobre a configuração do NAT não se aplica, porque ele está executando seu cluster no Virtualbox.

Há uma apresentação de slides associada vinculada à descrição do vídeo.

    
por 06.03.2014 / 12:57