Problema de eucalipto

Question

Eu tenho alguns problemas em relação à construção de nuvens privadas de eucalipto. E duas versões deste problema aqui, uma simples e uma longa.

Simples:

Alguém familiarizado com a nuvem privada poderia me desenhar uma imagem para ilustrar o 'IP SCHEME' da nuvem? Estou tendo problemas para decidir onde deveria estar cada componente. Se eu quiser instalar o CLC, o Walrus, o CC, o SC, o NC em diferentes máquinas físicas, qual deve ser a topologia da rede?

Mais informações: Eu tenho 12 máquinas físicas executando a nuvem agora, mas não posso anexar volumes a instâncias. Eu queria saber onde devo colocar controlador de armazenamento, rede pública? sob CLC? sob CC? mesmo nível com CC? Nenhuma imagem, nenhuma explicação encontrada em tudo. E eu tentei tudo o que pude, instâncias estão funcionando, ok para acessá-los, apenas a maldita coisa do volume me incomodou por uma semana inteira.

Versão longa:

1. Configurei o eucalipto com êxito em 4 servidores físicos e ele é ótimo.
2. Os quatro servidores são: CLC, SC, CC, NC
3. O problema é que não tenho muita certeza de onde colocar o SC, já que a topologia da minha nuvem é assim:

Agora que o CC está conectado a dois switches: ENTSWitch e PrivateSwitch. E tem dois IPs: IP público > 10.11.25.115, IP privado > 10.11.20.1. O controlador de nós está conectado somente a switches privados e possui IP privado 10.11.20.2

Isso funciona bem agora, usando o modo gerenciado-novlan, o controlador de nó pode implantar instâncias e obter endereços IP públicos para elas. Tudo é doce.

Aí vem o problema, posso criar volume no controlador de armazenamento. Mas o volume não foi anexado a instâncias.

Perguntando se é porque o controlador de nó está sob uma rede diferente com o controlador de armazenamento.

Tentou resolver o problema fazendo o seguinte:

• talvez eu não deveria conectar o controlador de armazenamento ao ENTSwitch ?. SC alterado de rede pública para rede privada
• B. Tente registrar o controlador de armazenamento novamente, mas falhou. Motivo: a nuvem não pode alcançar a rede privada.
• C. Tente registrar sc no CC, não pode, ele deve estar registrado no CLC
• D. Adicionar rota ao CLC, agora CLC e SC podem se conectar uns aos outros.
• E. Registre-se com sucesso, ainda não é possível anexar volume.
• F: log de erros:

    [root@HeroNodeServer1 images]# cat /var/log/eucalyptus/nc.log | grep Volume
    [Fri Aug 20 16:36:12 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-59C90629 remote=/dev/etherd/e0.1 local=/dev/sdb)
    [Fri Aug 20 16:37:53 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:37:53 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:37:53 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-59C90629 remote=/dev/etherd/e0.1 local=/dev/sdb)
    [Fri Aug 20 16:37:53 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:37:53 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:37:53 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-59C90629 remote=/dev/etherd/e0.1 local=/dev/sda5)
    [Fri Aug 20 16:37:53 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:37:53 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:37:58 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-59C90629 remote=/dev/etherd/e0.1 local=/dev/sda4)
    [Fri Aug 20 16:39:38 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:39:38 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:39:38 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-59C90629 remote=/dev/etherd/e0.1 local=/ev/sdp)
    [Fri Aug 20 16:39:38 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:39:38 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-59C90629 remote=/dev/etherd/e0.1 local=/dev/sdp)
    [Fri Aug 20 16:39:38 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:39:38 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:41:15 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-5A030630 remote=/dev/etherd/e0.2 local=/dev/sdp)
    [Fri Aug 20 16:42:55 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:42:55 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:43:12 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-5A030630 remote=/dev/etherd/e0.2 local=/dev/sdc)
    [Fri Aug 20 16:44:52 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:44:52 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:50:02 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-59C90629 remote=/dev/etherd/e0.1 local=/dev/sdd)
    [Fri Aug 20 16:51:42 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:51:42 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1

Perguntas:

1. Onde devo ligar o SC? rede pública ou rede privada?
2. Se ele deve ser anexado à rede privada, como registrar o SC se o CLC não puder acessar a rede privada
3. Por que duas soluções falharam ao anexar volume à instância?

=============================================== =================

Aqui vem o segundo:

1. No momento, estou tentando fazer mais alguns testes.
2. Desejo expandir a arquitetura física de quatro para a arquitetura física de 16.
3. Não importa quantas máquinas eu queira usar, há uma pergunta que eu tive por um longo tempo sem ser resolvida por toneladas de documentos lidos.
4. A nova arquitetura que projetei é como a seguinte foto
5. Nanovatopologia,assumiqueocontroladordearmazenamentodeveriaestarconectadoàredeprivada
6. Nestemodelo,asinstânciasemexecuçãonocontroladordenódevemterdoisendereçosIPatribuídos,umprivado,um"público"
7. O endereço IP público deve estar na rede como CC, certo?
8. Isso significa que as instâncias podem ser acessadas pela rede em que o CC está localizado.
9. E o CLC deve ter um serviço de gateway em execução para permitir que as instâncias acessem redes externas

Perguntas:

1. Existe algum problema com o design?
2. Se as instâncias só puderem obter "IP público", que está na mesma rede com o Cluster Controller, como os clientes devem acessá-los a partir de redes externas?
3. Significa como os clientes de fora da nuvem acessam instâncias por meio da CLC?
4. O CLC tem o mesmo mecanismo como o CC para atribuir um "IP público" para instâncias para que possa ser acessado?

================================

Isso é tudo que preciso perguntar.

Muito obrigado por ler este post confuso, e qualquer tipo de resposta é muito apreciado!

    

Answer 1

As respostas a seguir assumem que o modo de rede é MANAGED-NOVLAN (isso provavelmente também se aplica ao modo MANAGED).

Seção 1:

-1) A menos que você tenha necessidades específicas para preveni-lo, eu recomendaria o acoplamento do SC com o CC.

-2) No modo Gerenciado, o CC fica entre a rede pública e a rede privada de (um dos) grupos de nuvens. Se o SC estiver na máquina CC, ele poderá se comunicar com as duas redes. Se você decidir ter o SC em um servidor separado na rede privada, você precisará criar uma regra de NAT (com iptables) no CC para ativar as comunicações entre o SC e o CLC através do Firewall do CC. O CLC precisará dessa regra para se comunicar com o SC.

-3) Na solução 1; seu SC não estava conectado ao switch privado (isso é obrigatório). Nas soluções 2; você provavelmente não criou essa regra do iptables no CC e o SC foi então isolado atrás do CC.

Seção 2:

-1) Uma correção: mesclar os switches CTI e switch1, deve ser o mesmo switch que é a conexão com a rede pública. Gostaria também de sugerir (a menos que seja absolutamente necessário) para mesclar o CLC e WC em uma máquina e mesclar os SCs em seus respectivos CCs. Este diagrama ( link ) de uma nuvem UEC pode ajudá-lo .

-2) Quando você cria uma nova instância (euca-run-instance), o Eucalyptus cria uma nova regra de iptable no servidor CC que gerencia o nó no qual a instância está sendo executada. Essa regra permite comunicações através do CC. Esta rota NAT cruza as comunicações entre os IPs públicos e seus IPs privados correspondentes.

-3) Os clientes acessam as instâncias através do CC correspondente. O CLC está lá apenas para gerenciar a nuvem, mas, uma vez que uma instância é iniciada, o CC lida com as comunicações.

-4) Resumindo: Não.

    

Answer 2

Ok, vamos tentar começar a responder a isso

• pergunta SC

O SC precisa sempre ser acessível a partir das instâncias, portanto, ele precisa estar na mesma rede que o controlador de nó, as instâncias não podem ver o armazenamento porque ele mora em uma rede diferente.

• Topologia de rede

É bom ter redes separadas, mas acho que seria melhor basear sua segurança em firewall e controle de tráfego em vez de complicar as coisas, o Eucalyptus gosta quando a rede é simples, comece com uma rede e não divida-o em dois até ter uma boa sensação de segurança. Concentre seus esforços em ter um CLC e CC seguro, pois a segurança nos outros componentes será fornecida pela rede privada e pelos protocolos fornecidos pelo eucalyptus. Além disso, o NC em nenhum caso precisa de IPs externos.

• Design de rede

Esse design parece sólido para mim, todos os endereços públicos serão fornecidos pelo CC para que o CC seja, na verdade, o seu gateway, pense nele como sendo as "zonas de disponibilidade" no Amazon EC2, tendo mais de um CC você está criando suas zonas.

Em resumo, fique de olho no CLC e no CC e no Walrus, certifique-se de conhecer as infeções da segurança e da comunicação neles, o resto dos componentes deve ser bom e viver feliz em redes internas.