• Vendas: 1-800-961-2888
  • Suporte: 1-800-961-4454

Pré-requisitos para instalação da nuvem privada Rackspace e conceitos


Este capítulo contém a lista de pré-requisitos para instalação de cluster com as ferramentas Rackspace Private Cloud. A Rackspace recomenda que você leia este capítulo detalhadamente antes de tentar a instalação.

Índice

Requisitos de hardware
Requisitos de servidor Chef
Requisitos de nodo do cluster
Requisitos de software
Requisitos de internet
Requisitos de rede
Rede em livros de receitas da Rackspace Private Cloud
Preparação para a instalação
Considerações sobre o acesso a instâncias em rede Nova
Considerações sobre proxy
Ajustes de configurações de ambiente de proxy em nodos
Teste de configurações de proxy
Alta disponibilidade
Zonas de disponibilidade

Requisitos de hardware

A Rackspace testou a implementação da Rackspace Private Cloud com um dispositivo físico para cada um dos seguintes nodos:

  • Um servidor Chef
  • Um nodo controlador Nova de OpenStack
  • Máquinas físicas adicionais com nodos de computação Nova de OpenStack, conforme necessário

Se você tem requisitos diferentes para seu ambiente, fale com a Rackspace.

Requisitos de servidor Chef

A Rackspace recomenda que o hardware do servidor Chef atenda aos seguintes requisitos:

  • 4 GB RAM
  • 50 GB de espaço em disco
  • CPU de tomada dupla com dual core

Requisitos de nodo do cluster

Cada nodo do cluster terá o chef-client instalado. Os requisitos de hardware variam de acordo com a finalidade do nodo. Todos os dispositivos devem suportar VT-x. Consulte os detalhes de requisitos na tabela a seguir.

Tipo de nodo Requisitos
Controlador Nova
  • 16 GB RAM
  • 144 GB de espaço em disco
  • Tomada dupla CPU com dual core ou soquete único com quad core
Nova Compute
  • 32 GB RAM
  • 144 GB de espaço em disco
  • Tomada dupla CPU com dual core ou soquete único com quad core

O alocação total de CPU está definida em 16:1 VCPUs para núcleos, e a alocação total de memória está definida em 1.5:1. Cada núcleo físico pode suportar até 16 núcleos virtuais; por exemplo, um processador de dois núcleos pode suportar até 32 núcleos virtuais. Se necessitar de mais núcleos virtuais, adicione mais nodos físicos à sua configuração.

Veja uma lista de dispositivos Private Cloud certificados em Dispositivos Private Cloud certificados – Computação.

Requisitos de software

A seguir, uma tabela com os sistemas operacionais em que a Rackspace Private Cloud foi testada.

Sistema operacional Versão testada da Rackspace Private Cloud
Ubuntu 12.04 Todas as versões
Ubuntu 12.10 e superior Nenhum
CentOS 6.3 v4.0.0 e versões mais antigas
CentOS 6.4 v4.1.2 e versões mais recentes
CentOS 6.5 v4.2.2 e versões mais recentes
Red Hat Enterprise Linux 6.0 Nenhum

É possível instalar a Rackspace Private Cloud em sistemas operacionais não testados, mas podem ocorrer problemas inesperados.

Se precisar da Rede OpenStack, a Rackspace recomenda o uso da Rackspace Private Cloud v4.2.2 com CentOS 6.4 ou Ubuntu 12.04 para os nodos controladores e de rede.

Os seguintes núcleos foram testados:

  • linux-image-3.8.0-38-generic
  • linux-image-3.2.0-58-generic 
  • kernel-2.6.32-358.123.2.openstack.el6.x86_64

Requisitos de internet

É necessário acesso à internet para concluir a instalação, por isso certifique-se de que os dispositivos que você usa têm esse acesso para baixar os arquivos de instalação.

Requisitos de rede

Uma rede implementada com livros de receita da Rackspace Private Cloud usa rede Nova por padrão, mas a Rede OpenStack (Neutron, anteriormente conhecida como Quantum) pode ser ativada manualmente. Para a finalidade de conceitos de produtos e demonstrações, a rede Nova será suficiente, mas se você pretende criar um cluster de produção e necessita, por qualquer razão, de redes definidas por software, deve usar a Rede OpenStack, que é concebida como substituta para a rede Nova.

Se deseja usar a Rede OpenStack para sua nuvem privada, você terá de especificá-la no seu ambiente Chef e configurar os nodos de forma adequada. Veja as informações detalhadas em Como configurar a Rede OpenStack sobre conceitos e instruções de Rede OpenStack para a configuração da Rede OpenStack em seu ambiente.

Rede em livros de receitas da Rackspace Private Cloud

Os livros de receitas são criados de acordo com as seguintes premissas:

  • Os endereços IP da infraestrutura são fixos.
  • Terminais de vinculação para os serviços são mais bem descritos pelas redes a que estão conectados.

Os livros de receitas contêm definições de três redes gerais e quais os serviços a que elas se vinculam. Estas redes são definidas por faixa CIDR, e presume-se que qualquer interface de rede com um endereço dentro da faixa CIDR seja incluída nessa rede. Você pode especificar a mesma CIDR para várias redes; por exemplo, as redes Nova e de gerenciamento podem compartilhar uma CIDR.

A seguir, uma tabela de redes e serviços que se vinculam ao endereço IP dentro de cada uma dessas redes gerais.

Rede Serviços
nova
  • keystone-admin-api
  • nova-xvpvnc-proxy
  • nova-novnc-proxy
  • nova-novnc-server
pública
  • graphite-api
  • keystone-service-api
  • glance-api
  • glance-registry
  • nova-api
  • nova-ec2-admin
  • nova-ec2-public
  • nova-volume
  • neutron-api
  • cinder-api
  • ceilometer-api
  • horizon-dash
  • horizon-dash_ssl
gerenciamento
  • graphite-statsd
  • graphite-carbon-line-receiver
  • graphite-carbon-pickle-receiver
  • graphite-carbon-cache-query
  • memcached
  • collectd
  • mysql
  • keystone-internal-api
  • glance-admin-api
  • glance-internal-api
  • nova-internal-api
  • nova-admin-api
  • cinder-internal-api
  • cinder-admin-api
  • cinder-volume
  • ceilometer-internal-api
  • ceilometer-admin-api
  • ceilometer-central

A configuração permite a você ter múltiplas interfaces ou sub-interfaces separadas por VLAN. Você pode criar interfaces com marcação de VLAN, na configuração rede Nova (com pontes Linux) ou em Neutron (com OVS). A implementação de NIC único também é possível. As configuração de múltiplos NICs ou de NIC único estão descritas em Como configurar a Rede OpenStack.

Preparação para a instalação

Você precisa das seguintes informações para a instalação:

  • O endereço da rede Nova em formato CIDR
  • A ponte da rede Nova, como br100 ou eth0. Isso será usado como ponte VM em nodos de computação. O valor padrão geralmente é aceitável. Essa ponte será criada por Nova conforme necessário e não precisa ser configurada manualmente.
  • O endereço da rede pública em formato CIDR. Aqui os serviços de API pública, como a extremidade Keystone pública e o painel, serão executados. Um endereço IP dessa rede deve ser configurado em todos os hosts do cluster de Nova.
  • A interface da rede pública, como eth0 ou eth1. Essa é a interface de rede que está conectada à rede pública (internet/WAN) em nodos de computação. Em uma configuração de rede Nova, os nodos de computação com tráfego de instância NAT a partir dessa interface, a menos que um endereço IP flutuante específico tenha sido atribuído a essa instância.
  • O endereço da rede de gerenciamento em formato CIDR. Essa rede é usada para a comunicação entre os serviços, como monitoramento e syslog. Pode ser o mesmo da sua rede pública Nova, se você não quiser separar o tráfego de serviço.
  • A faixa CIDR da rede VM. É a faixa da qual os endereços IP serão atribuídos a VMs automaticamente. Um endereço a partir desta rede será visível a partir da sua instância em eth0. Essa rede deve ser dedicada a OpenStack e não compartilhada com outros serviços.
  • A interface de rede VM para os nodos de computação (como eth1).
  • O nome do cluster de Nova. Deve ser exclusivo e composto por caracteres alfanuméricos, hífens (-) ou sublinhados (_).
  • O nome da zona de disponibilidade padrão. A Rackspace recomenda usar nova como padrão.
  • Para configurações de rede Nova, uma faixa ou faixas CIDR de exclusão NAT opcional para redes configuradas com um DMZ. Uma lista separada por vírgulas de faixas de rede CIDR que serão excluídas das regras de NAT. Isso permite a comunicação direta de, e para instâncias de outras faixas de rede sem o uso de IPs flutuantes.

Considerações sobre o acesso a instâncias em rede Nova

Em uma configuração de rede Nova, por padrão, as instâncias que você cria no cluster de OpenStack podem ser acessadas publicamente via NAT somente pela atribuição de endereços IP flutuante para elas. Antes de atribuir um endereço IP flutuante a uma instância, você deve ter um pool de endereços para escolher. Sua equipe de segurança de rede deve provisionar um intervalo de endereços e atribuí-lo ao seu ambiente. Esses endereços precisam ser acessíveis ao público. Endereços IP flutuantes não são especificados durante o processo de instalação. Assim que o nodo controlador estiver funcionando, você poderá adicioná-los com o comando nova-manage floating create --ip_range. Consulte "Como gerenciar endereços IP flutuantes".

Você também pode tornar as instâncias acessíveis a outros hosts na rede por padrão ao configurar a nuvem com uma rede DMZ. O intervalo da rede DMZ não pode ser o mesmo da rede Nova. Especificando um DMZ permite que o tráfego de rede sem NAT entre as instâncias de máquinas virtuais e recursos fora da rede Nova fixa. Por exemplo, se a rede Nova fixa é 10.1.0.0/16 e você especificar um DMZ de 172.16.0.1/12, todos os dispositivos ou hosts nessa faixa serão capazes de se comunicar com as instâncias na rede Nova fixa.

Para usar o DMZ, você deve ter pelo menos dois NICs nos servidores de implementação. Um NIC deve ser dedicado às instâncias de VM.


Considerações sobre proxy

Em geral, as instruções de instalação da Rackspace Private Cloud pressupõem que nenhum dos seus nodos esteja atrás de um proxy. Se estiverem atrás de um proxy, reveja esta seção antes de prosseguir com a instalação. A Rackspace ainda não testou um ambiente híbrido em que alguns nodos estejam atrás do proxy e outros não.

Ajustes de configurações de ambiente de proxy em nodos

Você deve tornar as configurações de proxy disponíveis para o sistema operacional inteiro em cada nodo, configurando /etc/environment do seguinte modo:

$ /etc/environment
http_proxy=http://<yourProxyURL>:<port>
        https_proxy=http://<yourProxyURL>:<port>
        ftp_proxy=http://<yourProxyURL>:<port>
no_proxy=<localhost>,<node1>,<node2>                    
                    

Substitua node1 e node2 com os nomes de host de seus nodos.

Em todos os casos, no_proxy é necessário e deve conter uma entrada localhost. Se o localhost estiver faltando, a instalação do servidor Chef Omnibus irá falhar. Ubuntu requer http_proxy e no_proxy como mínimo. CentOS requer http_proxy, https_proxy e no_proxy para pacotes yum e atualizações importantes. No entanto, como os métodos de instalação podem mudar ao longo do tempo, a Rackspace recomenda que você defina tantas variáveis ​​quanto puder.

Os nodos também deve ter sudo configurado para conter as seguintes variáveis de ambiente.

Defaults env_keep += "http_proxy https_proxy ftp_proxy no_proxy"  
                    

Em Ubuntu, isso pode ser colocado em um arquivo em /etc/sudoers.d. Em CentOS, certifique-se de que sua versão carrega arquivos em /etc/sudoers.d antes de adicionar essa variável.

Teste de configurações de proxy

Você pode verificar se as configurações de proxy estão corretas fazendo login e executando env e sudo env. Você deve ver as configurações http_proxy, https_proxy, ftp_proxy e no_proxy ajustadas na saída, conforme o exemplo a seguir.

$ env
TERM=screen-256color
SHELL=/bin/bash
SSH_CLIENT=<ssh-url>
SSH_TTY=/dev/pts/0
LC_ALL=en_US
http_proxy=<yourProxyURL>:<port>
ftp_proxy=<yourProxyURL>:<port>
USER=admin
PATH=/usr/local/sbin
PWD=/home/admin
LANG=en_US.UTF-8
https_proxy=<yourProxyURL>:<port>
SHLVL=1
HOME=/home/admin
no_proxy=localhost,chef-server,client1
LOGNAME=admin
SSH_CONNECTION=<sshConnectionInformation>
LC_CTYPE=en_US.UTF-8
LESSOPEN=| /usr/bin/lesspipe %s
LESSCLOSE=/usr/bin/lesspipe %s %s
_=/usr/bin/env
                
$ sudo env
TERM=screen-256color
LC_ALL=en_US
http_proxy=<yourProxyURL>:<port>
ftp_proxy=<yourProxyURL>:<port>
PATH=/usr/local/sbin
LANG=en_US.UTF-8
https_proxy=<yourProxyURL>:<port>
HOME=/home/admin
no_proxy=localhost,chef-server,client1
LC_CTYPE=en_US.UTF-8
SHELL=/bin/bash
LOGNAME=root
USER=root
USERNAME=root
MAIL=/var/mail/root
SUDO_COMMAND=/usr/bin/env
SUDO_USER=admin
SUDO_UID=1000
SUDO_GID=1000
               

Alta disponibilidade

A Rackspace Private Cloud tem a capacidade de implementar suporte para alta disponibilidade (HA) em todos os componentes de serviços Nova e APIs, Cinder e Keystone, e Glance, além do agendador, RabbitMQ e MySQL. A funcionalidade HA tem tecnologia Keepalived e HAProxy.

A Rackspace Private Cloud utiliza os seguintes métodos para implementar HA no seu cluster.

  • Replicação mestre-mestre de MySQL e failover ativo-passivo: MySQL está instalado nos dois nodos controladores e a replicação mestre-mestre está configurada entre os nodos. O Keepalived administra conexões para os dois nodos, de modo que apenas um nodo recebe solicitações de leitura/gravação a qualquer momento.
  • Faiolver ativo/passivo de RabbitMQ: RabbitMQ está instalado nos dois nodos controladores. O Keepalived administra conexões para os dois nodos, de modo que apenas um nodo permanece ativo a qualquer momento.
  • Load balancing de API: todos os serviços que estão sem estado e podem sofrer load balancing (principalmente, todas as APIs e alguns outros) são instalados em ambos os nodos controladores. O HAProxy é então instalado nos dois nodos, e o Keepalived gerencia conexões para o HAProxy, o que torna o próprio HAProxy um HA. Os terminais de Keystone e todo o acesso a API passa pelo Keepalived.

Zonas de disponibilidade

As zonas de disponibilidade permitem gerenciar e isolar diferentes nodos dentro do ambiente. Por exemplo, você pode querer isolar diferentes conjuntos de nodos de computação para oferecer diversos recursos aos clientes. Se uma zona de disponibilidade passar por tempo de inatividade, outras zonas do cluster não serão afetadas.

Ao criar um cluster de Nova, ele será criado com zona de disponibilidade padrão, e todos os nodos de computação serão atribuídos a essa zona. Você pode criar zonas de disponibilidade adicionais dentro do cluster, conforme necessário.







© 2011-2013 Rackspace US, Inc.

Salvo indicação em contrário, o conteúdo deste site está licenciado sob uma licença não adaptada de Creative Commons Attribution-NonCommercial-NoDerivs 3.0


Ver detalhes da licença e o AVISO LEGAL