Instalação do Intel Xeon Phi no CentOS 7

Este documento detalha a instalação dos pacotes de software necessários para o funcionamento do Intel Xeon Phi (MPSS 3.6.1) no CentOS Linux release 7.2.1511 (Core) com kernel 3.10.0-327.el7.x86_64. Importante observar que a versão do kernel deve ser compatível. Caso não esteja de acordo com a documentação do MPSS, deve-se instalar os pacotes do kernel adequado. Veja mais em: http://registrationcenter.intel.com/irc_nas/8495/mpss_users_guide.pdf

0. Desabilitar o NetworkManager

Por padrão, o NetworkManager vem habilitado no CentOS. Devemos desabilitá-lo :

# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start

1. Download dos Pacotes

Baixar o arquivo mpss-3.6.1-linux.tar do site https://software.intel.com/en-us/articles/intel-manycore-platform-software-stack-mpss:

# mkdir /root/mic
# cd /root/mic
# wget http://registrationcenter.intel.com/irc_nas/8495/mpss-3.6.1-linux.tar
# tar xvf mpss-3.6.1-linux.tar

2. Instalar os pacotes

Primeiro passo desta fase, verificar que não existe uma versão anterior instalada:

# rpm -qa | grep -e intel-mic -e mpss

Esse comando não deve retornar nenhum valor. Em seguida, devemos instalar os pacotes base:

# cd /root/mic/mpss-3.6.1
# cp ./modules/`uname -r`.rpm
# yum install *.rpm

Caso encontre algum problema de incompabilidade no kernel, por exemplo não encontrar na pasta /root/mic/mpss-3.6.1/modules os pacotes equivalentes a sua versão, faça o seguinte:

# yum install kernel-headers kernel-devel
# cd /root/mic/mpss-3.6.1/src
# rpmbuild –rebuild mpss-modules.src.rpm
# yum install /root/rpmbuild/RPMS/x86_64/
.rpm

Os passos anteriores podem ser feitos a cada atualização do kernel. Mas talvez seja melhor não atualizar os pacotes do kernel.

Por último, carregue o módulo do kernel da mic:

# modprobe mic

Demora alguns segundos. Se nada retornar, então deu tudo certo. Vamos chegar o status da mic:

# micctrl -s
# mic0: ready

Devemos atualizar a memória flash do dispositivo:

# micflash -update -device all
No image path specified – Searching: /usr/share/mpss/flash
mic0: Flash image: /usr/share/mpss/flash/EXT_HP2_C0_0391-02.rom.smc
mic0: Flash update started
mic0: Flash update done
mic0: SMC update started
mic0: SMC update done
mic0: Transitioning to ready state
Please restart host for flash changes to take effect

3. Aplicar as configurações default

Inicializar as configurações default:

# micctrl –initdefaults

Verificar se o serviço mpss pode ser inicializado:

# service mpss start

Habilitar para inicializar junto com o sistema:

# chkconfig mpss on

Verificar se é possível entrar no mic através do SSH (você precisa ter criado a chave do root antes):

# ssh mic0

Executar dois comandos que verificam o status da mic:

# miccheck

# micinfo

4. Adicionar um usuário

Primeiro, adicione o usuário no host:

# adduser usuario

# passwd usuario

Em seguida logue como o usuário e crie uma chave SSH:

\$ ssh-keygen

De volta ao root, adicione o usuário ao mic:

# micctrl –useradd=usuario

Pronto! Agora o usuário pode logar no mic.

Uma pequena comparação entre o Generics do Java e do C#

Meu objetivo neste post é comparar uma característica do Generics do Java e do C# que encontrei quando tentei criar uma classe para representar uma matriz. Queria guardar a matriz em um vetor linear e acessar seus elementos fazendo uma pequena aritmética no número de linhas e colunas. O objetivo era parametrizar a classe para que pudesse criar matrizes para qualquer tipo numérico.

Comecei pelo Java e tentei o seguinte código:

package matrix;

public class Matrix <T extends Number> {

	private int rows;
	private int columns;
	private T[] linearArray;
	
	public int rows() { return rows;}
	public int columns() { return columns;}
	
	public Matrix  (int rows, int cols){
		this.rows = rows;
		this.columns = cols;
		linearArray = new T[rows*columns];
	}
	
	public T get(int i, int j) {
		if (i > rows || j > columns)
			return null;
		int localIndex = i * rows + j;
		return linearArray[localIndex];
	}
	
	public void set(int i, int j, T value) {
		if (i > rows || j > columns)
			return;
		int localIndex = i * rows + j;
		linearArray[localIndex] = value;
	}
}

O problema é que esta linha:

linearArray = new T[rows*columns];

Fornece o seguinte erro:

Cannot create a generic array of T	Matrix.java	/MatrixComponents/src/matrix	line 15	Java Problem

Pela descrição, é um problema do Java. Criei então código semelhante em C#:

using System;

namespace TestandoArraysGenerics
{
	public class Matrix <T>
	{
		T[] elements;
		int rows;
		int columns;

		int Rows {
			get {
				return rows;
			}
			set {
				rows = value;
			}
		}

		int Columns {
			get {
				return columns;
			}
			set {
				columns = value;
			}
		}

		public Matrix (int rows, int columns)
		{
			this.rows = rows;
			this.columns = columns;
			elements = new T[rows * columns];
		}

		public T this[int i, int j] {
			get {
				return elements[i * rows + j];
			}
			set {
				elements[i * rows + j] = value;
			}
		}
	}
}

A linha

elements = new T[rows * columns];

Funciona perfeitamente. Pergunto então, existe uma situação insegura que Java previne e C# permite? Ou é o contrário, C#, mais moderna e recente, decidiu implementar Generics até a raiz da linguagem?

Etiquetado

Compilar MPICH2/MPI.NET Ubuntu

O MPI.NET é uma biblioteca que permite escrever aplicações MPI usando C#. É muito parecida com o MPI para C, mas tem algumas facilidades interessantes, principalmente se você deseja enviar objetivos através de primitivas de comunicação MPI. Nesse tutorial, vamos usar pacotes e código fonte que não fazem parte da instalação oficial do Ubuntu. Na verdade, sugiro que retire qualquer pacote mono ou mpich que tenha instalado no Ubuntu antes de começar. Eu testei na 12.04 LTS e na 14.04 LTS, os passos sãos os mesmos. Vamos instalar tudo no /opt.

1) Instalar o MONO

Seguir as instruções no site abaixo:
http://software.opensuse.org/download/package?project=home:tpokorra:mono&package=monodevelop-opt
Depois executar:
# ln -s /opt/mono/bin/ilasm /opt/mono/bin/ilasm2
# source /opt/mono/env.sh
# ln -s /opt/mono/env.sh /etc/profile.d/mono.sh

2) Instalar o MPICH

Na pasta do código fonte do MPI (usei o mpich2-1.3)
# mkdir /opt/mpich2-1.3
# ./configure –prefix=/opt/mpich2-1.3 –enable-shared –enable-lib-depend
# make
# make install
Colocar o seguinte em /etc/profile.d/mpich.sh:
export PATH=/opt/mpich2-1.3/bin:$PATH
export LD_LIBRARY_PATH=/opt/mpich2-1.3/lib:$LD_LIBRARY_PATH
export LD_RUN_PATH=/opt/mpich2-1.3/bin:$LD_RUN_PATH
export MANPATH=/opt/mpich2-1.3/share/man:$MANPATH
Depois:
# source /etc/profile.d/mpich.sh

3) Instalar o MPI.NET

Na pasta do código do fonte do MPI.NET
# mkdir /opt/mpi.net
# git clone https://github.com/jmp75/MPI.NET.git mpi.net
# cd mpi.net
# LOCAL_DIR=/opt/mpi.net
# sh autogen.sh
# ./configure –prefix=/opt/mpi.net
# make
# make install
# gacutil -i /opt/mpi.net/lib/MPI.dll
# gacutil -i /opt/mpi.net/lib/MPIUtils.dll

4) Compilar código de exemplo

Salve o conteúdo abaixo em um arquivo chamado Hello.cs.

using System;
using System.Collections.Generic;
using MPI;

class Hello{
    static void Main(string[] args){
		IDictionary<int, MPI.Intracommunicator> colors = new Dictionary<int, MPI.Intracommunicator>();

		MPI.Environment mpi = new MPI.Environment(ref args);
		MPI.Intracommunicator worldComm = Communicator.world;
		int min = 8; int max=min; int rank = min;

		rank = worldComm.Rank;
		min = worldComm.Allreduce<int>(rank+1, MPI.Operation<int>.Min);
		max = worldComm.Reduce<int>(rank+1, MPI.Operation<int>.Max, 1);

		colors[rank] = (MPI.Intracommunicator)worldComm.Split(rank+100, rank);

		int rec = 8;
		if (rank == 0) {
			MPI.Request req = worldComm.ImmediateSend<int> (50, rank, 0);
			rec = worldComm.Receive<int> (rank, 0);
			req.Wait();
		}
		Console.WriteLine("Node {0} of {1} - min={2} - max={3} - rec={4}\n", rank, worldComm.Size, min,  max, rec);
		mpi.Dispose();
   }
}

$ export LD_LIBRARY_PATH=/opt/mpi.net/lib
$ gmcs -r:/opt/mpi.net/lib/MPI.dll Hello.cs
$ mpirun -np 2 mono ./Hello.exe

Se executar sem mensagens de erro, então sua configuração está OK!!!

Gerenciando VMs no VirtualBox por Linha de Comando

Introdução

O VirtualBox é uma ferramenta de fácil utilização para criação de máquinas virtuais. O ambiente gráfico é bastante intuitivo, com poucos cliques o usuário é capaz de colocar uma máquina virtual para executar. Entretanto, algumas vezes é mais cômodo utilizar a linha de comando para gerenciar as máquinas virtuais, principalmente se você deseja criar scripts para automatizar suas tarefas.

Iniciar uma máquina virtual pelo terminal

Ao contrário de outras ferramentas que possuem um comando para cada ação, o VirtualBox tem um comando apenas que engloba todas as ações, o VBoxManage. Não adianta tentar memorizar todas as opções, apenas as principais são importantes. Uma maneira fácil de listar as máquinas virtuais disponíveis é com a opção list.

VBoxManage list vms
"AdmLinux2014" {e5d22843-42b3-40f1-b7cb-1013b31feb99}
"GParted" {23213647-b9bf-41cd-a696-d023527de672}
"pfSense" {c078a303-8283-43b9-8f82-19d7524681d6}

Com a comando VBoxManage list vms, conseguimos ver quais as máquinas virtuais disponíveis. Se e somente se a máquina virtual estiver com os Adicionais para Convidados (Guest Additions), você conseguirá tirar proveito total do VBoxManage. Para inicializar uma VM específica, sem subir a interface gráfica, o ideal é usar o comando VBoxHeadless. Ele é muito útil quando você está hospedando um servidor na VM e não precisa da interface gráfica. O comando completo seria:


VBoxHeadless --startvm AdmLinux2014 --vrde off

Com isso, a VM inicializa, mas sem nenhuma tela para interação. Como controlá-la?

Enviando comandos para uma VM

Claro que você pode configurar o SSH e o redirecionamento de portas para logar na VM e executar comandos. Mas novamente, não é uma boa opção para scripts. É possível enviar um comando através do próprio VirtualBox. Por exemplo, o comando abaixo executa ifconfig em uma máquina virtual chamada AdmLinux2014:


VBoxManage --nologo guestcontrol AdmLinux2014 execute --image \\ "/sbin/ifconfig" --username usuario --password senha --wait-stdout

É um comando muito útil para, caso você esteja atribuindo IP através de uma bridge em uma interface do hospedeiro, descobrir qual o endereço a máquina recebeu.

Conclusão

Com essas duas dicas, é fácil criar um script que inicialize um certo conjunto de VMs e execute comandos de configuração em cada uma. Agora é só usar a imaginação 😉

Etiquetado ,

A simple script for probing status from SLURM cluster nodes.

A common problem that appears once in a while in our cluster at CENAPAD-UFC is that not all the processes are terminated on the nodes when the job is aborted. This is a wrong behavior, and we haven’t been able to fix it within SLURM. The solution I found is to constantly check the nodes to see if any of them has load average greater than the number of cores available. If an overloaded node is found, the administrator may log in and check of zombie processes.

If you have a SLURM cluster, the best way to monitor the nodes is installing Ganglia . But if by any chance you can’t install Ganglia, another solution is using pdsh and a little bit of scripting in Python. The only customization needed is changing the value of numberOfCoresPerNode according your cluster configuration. Also, partition must be the name of a partition with all the nodes you want to monitor.

#!/usr/bin/python
# coding=UTF-8
import os
from collections import OrderedDict

numberOfCoresPerNode = 12
partition = "superlong"

# Retrieve the list of available nodes
stream = os.popen("sinfo -p " + partition + " -t ALLOC,IDLE -o %N | tail -1")
nodeStr = stream.readline()

print "Available nodes are: " + nodeStr[:-1]

# Retrieve the load of each node
stream = os.popen("pdsh -w " + nodeStr[:-1] + " cat /proc/loadavg")
output = {}
for line in stream.readlines() :
key = line.split(":")[0]
value = line.split(":")[1].split(" ")[1]
output[key] = value

# Sort the output dictionary according the keys values
orderedOutput = OrderedDict(sorted(output.items(), key=lambda item: int(item[0][6:])))

# Print information about each node.
print "Node load: "
for key in orderedOutput.keys():
if float(orderedOutput[key]) > numberOfCoresPerNode + 4:
print "OVERLOAD>>>" + key + ":" + orderedOutput[key]
else:
print key + ":" + orderedOutput[key]

We consider that a node is overloaded if the load is greater that the number of cores plus 4. That can be changed at the last for loop.

Etiquetado ,

Enviando e-mail na linha de comando do Linux pelo GMail.

Muitas vezes é interessante enviar um e-mail através no BASH no Linux, seja para enviar relatórios ou avisos para o administrador. Entretanto, instalar um servidor SMTP completo apenas para essa função não é o ideal. Por que não utilizar um serviço confiável já existente? Vamos a seguir explicar como utilizar o GMail para envio de mensagens no BASH. Sem muito esforço, é possível adaptar essa solução para outros serviços de e-mail. Essa solução foi testada no Ubuntu 12.04 LTS.

O aplicativo que vamos utilizar é o MSMTP. A instalação dos pacotes necessários pode ser feita com o comando abaixo:

:~$ sudo apt-get install msmtp openssl ca-certificates

Com os pacotes instalados, devemos criar um arquivo de configuração para o MSMTP. Coloque o conteúdo abaixo no arquivo ~/.msmtprc:

account default
host smtp.gmail.com
port 587
from SEUUSUARIO@gmail.com
tls on
tls_starttls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
auth on
user SEUUSUARIO@gmail.com
password SUASENHA
logfile ~/.msmtp

Como esse arquivo contém sua senha, o ideal é impedir que os outros usuários possam lê-lo. Execute o comando abaixo para restringir as permissões:

:~$ chmod u+rw,g-rw,o-r ~/.msmtprc

Agora vamos criar um arquivo de e-mail. O arquivo deve possuir os campos From:, To: e Subject: (remetente, destinatário e assunto). Lembre de casar as informações do e-mail com o que você colocou no arquivo ~/.msmtprc. Veja um exemplo, salvo no arquivo email.txt:

To: larrypage@gmail.com
From: SEUUSUARIO@gmail.com
Subject: Teste de envio de e-mail pelo BASH.

Olá Larry,

Isto é um teste.

[]'s

Agora basta executar o comando abaixo e pronto, um e-mail será enviado:

:~$ msmtp -t < email.txt
Etiquetado , ,

Configuração de Um Ambiente de Testes para o OpenStack – Parte 4 – Compute

Aviso: este tutorial não funciona. Ele foi baseado em um guia que está no site oficial do projeto OpenStack (veja a parte 1). Entretanto, nos próprios comentários da página do tutorial, vários usuários relatam que as máquinas virtuais criadas não conseguem capturar um IP do DHCP. A razão do problema está relacionada com o serviço Quantum, cuja utilização no OpenStack é recente. Caso você deseje ter uma visão geral de virtualização e OpenStack, aconselho a seguir o tutorial mesmo assim. Na hora de aprender, um erro pode valer mais do que mil acertos.

Introdução

Vamos agora para a parte final do tutorial, a máquina Compute. Se você observar na tabela no post parte 1, verá que o nó Compute não foi configurado com uma interface com a Rede Externa (Host NAT). A configuração está correta, porém sem conexão com a Internet, fica difícil instalar os pacotes necessários. E quais são os pacotes? Por mais estranho que possa parece, a máquina Compute, que é virtual, precisará do KVM. Ou seja, uma máquina virtual que hospedará máquinas virtuais. Não posso deixar de lembrar que esta configuração é apenas para testes, o desempenho apresentado não será bom.

Configuração do Ubuntu

Primeiro, vamos aos pacotes. Execute ‘sudo apt-get install ubuntu-cloud-keyring’. Crie o arquivo /etc/apt/sources.list.d/cloud-archive.list com apenas a seguinte linha:

deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/folsom main 

Depois, atualize a distribuição com os comandos ‘sudo apt-get update && sudo apt-get upgrade’. Instale os pacotes com o comando abaixo:

openstack@compute:~$ sudo apt-get install ntp kvm libvirt-bin pm-utils nova-compute-kvm openvswitch-switch quantum-plugin-openvswitch-agent

Com isso todos os pacotes estarão instalado e podemos partir para a configuração individual de cada um. Mas antes vamos terminar que configurar o Ubuntu.

Configuração de Rede

Você deve deixar seu arquivo /etc/network/interfaces parecido com o exemplo abaixo:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
# auto eth0
# iface eth0 inet static
#        address 192.168.122.4
#        netmask 255.255.255.0
#        network 192.168.122.0
#        broadcast 192.168.122.255
#        gateway 192.168.122.1
#        dns-nameservers 192.168.122.1

auto eth1
iface eth1 inet static
        address 192.168.0.4
        netmastk 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
	### static routing ###
	post-up route add -net 192.168.0.0 netmask 255.255.255.0 dev eth1
	pre-down route del -net 192.168.0.0 netmask 255.255.255.0 dev eth1

auto eth2
iface eth2 inet static
        address 10.10.10.3
        netmastk 255.255.255.0
        network 10.10.10.0
        broadcast 10.10.10.255
	### static routing ###
	post-up route add -net 10.10.10.0 netmask 255.255.255.0 dev eth2
	pre-down route del -net 10.10.10.0 netmask 255.255.255.0 dev eth2

A configuração do eth0 é opcional, já que instalamos o pacote. Se você encontrar algum problema, pode deixar essa configuração fora de comentários. Atualize os seguintes campos no arquivo /etc/sysctl.conf:

net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0  

Agora, reinicie a rede com ‘openstack@compute:~$ sudo service networking restart’.

NTP

Coloque apenas a linha ‘server 192.168.0.2’ no arquivo /etc/ntp.conf e reinicie o serviço com ‘sudo service ntp restart’.

KVM

Vamos agora configurar o KVM. Edite o arquivo /etc/libvirt/qemu.conf e adicione o seguinte:

cgroup_device_acl = [
    "/dev/null", "/dev/full", "/dev/zero",
    "/dev/random", "/dev/urandom",
    "/dev/ptmx", "/dev/kvm", "/dev/kqemu",
    "/dev/rtc", "/dev/hpet", "/dev/net/tun"]

É necessário desabilitar a bridge padrão do KVM, para evitar conflitos na rede:

openstack@compute:~$ virsh net-destroy default
openstack@compute:~$ virsh net-undefine default

Temos que habilitar a migração “quente”, configurando as seguintes opções no arquivo /etc/libvirt/libvirtd.conf:

listen_tls = 0
listen_tcp = 1
auth_tcp = "none"

Em seguida, a variável libvirtd_opts deve ser alterada no arquivo /etc/init/libvirt-bin.conf:

env libvirtd_opts="-d -l" 

Temos que alterar a mesma variável no arquivo /etc/default/libvirt-bin para ficar com o mesmo valores. Para finalizar, reiniciamos o KVM/Libvirt:

openstack@compute:~$ sudo service libvirt-bin restart
libvirt-bin stop/waiting
libvirt-bin start/running, process 3110

Nova

Edite o arquivo /etc/nova/api-paste.ini:

admin_tenant_name = service
admin_user = nova
admin_password = openstack

Edite o arquivo /etc/nova/nova-compute.conf:

[DEFAULT]
libvirt_type=qemu
libvirt_ovs_bridge=br-int
libvirt_vif_type=ethernet
libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
libvirt_use_virtio_for_bridges=True

O campo libvirt_type está como qemu porque compute é uma máguina virtual. Fosse uma máquina real, o valor deveria ser kvm. Perceba que os dois primeiros arquivos editados não trazem nenhuma indicação que esta instalação do nova faz parte de uma nuvem. No próximo arquivo iremos adicionar os endereços IPs dos outros serviços da nuvem. Edite o arquivo /etc/nova/nova.conf :

[DEFAULT]

# MySQL Connection #
sql_connection=mysql://nova:openstack@192.168.0.2/nova

# nova-scheduler #
rabbit_host=192.168.0.2
rabbit_password=openstack
scheduler_driver=nova.scheduler.simple.SimpleScheduler

# nova-api #
cc_host=192.168.0.2
auth_strategy=keystone
s3_host=192.168.0.2
ec2_host=192.168.0.2
nova_url=http://192.168.0.2:8774/v1.1/
ec2_url=http://192.168.0.2:8773/services/Cloud
keystone_ec2_url=http://192.168.0.2:5000/v2.0/ec2tokens
api_paste_config=/etc/nova/api-paste.ini
allow_admin_api=true
use_deprecated_auth=false
ec2_private_dns_show_ip=True
dmz_cidr=169.254.169.254/32
ec2_dmz_host=192.168.0.2
metadata_host=192.168.0.2
metadata_listen=0.0.0.0
enabled_apis=metadata

# Networking #
network_api_class=nova.network.quantumv2.api.API
quantum_url=http://192.168.0.2:9696
quantum_auth_strategy=keystone
quantum_admin_tenant_name=service
quantum_admin_username=quantum
quantum_admin_password=openstack
quantum_admin_auth_url=http://192.168.0.2:35357/v2.0
libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
linuxnet_interface_driver=nova.network.linux_net.LinuxOVSInterfaceDriver
firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver

# Compute #
compute_driver=libvirt.LibvirtDriver
connection_type=libvirt

# Cinder #
volume_api_class=nova.volume.cinder.API

# Glance #
glance_api_servers=192.168.0.2:9292
image_service=nova.image.glance.GlanceImageService

# novnc #
novnc_enable=true
novncproxy_base_url=http://192.168.122.2:6080/vnc_auto.html
vncserver_proxyclient_address=192.168.0.4
vncserver_listen=0.0.0.0

# Misc #
logdir=/var/log/nova
state_path=/var/lib/nova
lock_path=/var/lock/nova
root_helper=sudo nova-rootwrap /etc/nova/rootwrap.conf
verbose=true

Quantum

Vamos configurar o Open vSwitch, que nos dará acesso às bridges virtuais, e o próprio Quantum.

Open vSwitch

No caso do Open vSwitch, precisamos iniciar o serviço e adicionar as bridges:

openstack@compute:~$ sudo service openvswitch-switch start
 * Inserting openvswitch module
 * /etc/openvswitch/conf.db does not exist
 * Creating empty database /etc/openvswitch/conf.db
 * Starting ovsdb-server
 * Configuring Open vSwitch system IDs
 * Starting ovs-vswitchd
 * Enabling gre with iptables
openstack@compute:~$ sudo ovs-vsctl add-br br-int

Quantum

Para o Quantum, temos que configurar os dois arquivos com os IPs do Controller.

Edite o arquivo /etc/quantum/quantum.conf:

core_plugin = quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
auth_strategy = keystone
fake_rabbit = False
rabbit_host = 192.168.0.2
rabbit_password = openstack

Edite o arquivo /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini:

sql_connection = mysql://quantum:openstack@192.168.0.2:3306/quantum
tenant_network_type = gre
tunnel_id_ranges = 1:1000
integration_bridge = br-int
tunnel_bridge = br-tun
local_ip = 10.10.10.3
enable_tunneling = True

E vamos iniciar o serviço:

openstack@compute:~$ sudo service quantum-plugin-openvswitch-agent start
quantum-plugin-openvswitch-agent start/running, process 3510

Toques finais

Para finalizar alguns toques finais. Irá facilitar muito nossa vida sincronizar o conteúdo dos arquivos /etc/hosts em cada máquina. Lembre de comentar a linha que atribui o loopback (127.0.0.1) para o hostname da máquina. Os arquivos devem ter as seguintes linhas:

192.168.0.2	controller
192.168.0.3	network
192.168.0.4	compute

Configuração de Um Ambiente de Testes para o OpenStack – Parte 3 – Network

Aviso: este tutorial não funciona. Ele foi baseado em um guia que está no site oficial do projeto OpenStack (veja a parte 1). Entretanto, nos próprios comentários da página do tutorial, vários usuários relatam que as máquinas virtuais criadas não conseguem capturar um IP do DHCP. A razão do problema está relacionada com o serviço Quantum, cuja utilização no OpenStack é recente. Caso você deseje ter uma visão geral de virtualização e OpenStack, aconselho a seguir o tutorial mesmo assim. Na hora de aprender, um erro pode valer mais do que mil acertos.

Introdução

Com a configuração feita no post anterior, podemos partir para configurar o segundo host com os serviços de rede. A princípio, já poderíamos instanciar máquinas apenas com o Controller configurado. Mas a adição do Network torna o cenário, ainda controlado, um pouco mais realista.

Configurações no Ubuntu

Assim como na configuração do Controller, vamos atualizar a sources.list para adicionar o repositório com a versão mais recente do OpenStack.

openstack@network:~$ sudo apt-get install ubuntu-cloud-keyring 

Coloque a linha abaixo no arquivo /etc/apt/sources.list.d/cloud-archive.list:

deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/folsom main 

Em seguida, atualize o sistema:

openstack@network:~$ sudo apt-get update && sudo apt-get dist-upgrade

Vamos configurar a rede. Aqui temos que prestar atenção em detalhe. A interface da rede externa (endereço 192.168.122.3/24) será alterada. Nós vamos criar uma bridge pública. Se você logou na máquina pela interface da rede externa, sai e comece a sessão SSH por outro endereço. O arquivo /etc/network/interfaces deve ficar assim:

# The loopback network interface
auto lo
iface lo inet loopback

# Bridge Pública
auto eth0
iface eth0 inet manual
        up ifconfig $IFACE 0.0.0.0 up
        up ip link set $IFACE promisc on   
        down ifconfig $IFACE down

# Rede de Gerência
auto eth1
iface eth1 inet static
        address 192.168.0.3
        netmastk 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        ### static routing ###
        post-up route add -net 192.168.0.0 netmask 255.255.255.0 dev eth1
        pre-down route del -net 192.168.0.0 netmask 255.255.255.0 dev eth1

# Rede de Dados
auto eth2
iface eth2 inet static
        address 10.10.10.2
        netmastk 255.255.255.0
        network 10.10.10.0
        broadcast 10.10.10.255
        ### static routing ###
        post-up route add -net 10.10.10.0 netmask 255.255.255.0 dev eth2
        pre-down route del -net 10.10.10.0 netmask 255.255.255.0 dev eth2

Antes de reiniciar, instale todos os pacotes necessários. Com a interface pública como bridge, não teremos acesso aos repositórios do Ubuntu no primeiro momento.

openstack@network:~$ sudo apt-get install ntp quantum-plugin-openvswitch-agent quantum-dhcp-agent quantum-l3-agent

Devemos ativar o roteamento de pacotes no kernel. Coloque as opções a seguir no arquivo /etc/sysctl.conf:


Coloque também as mesmas informações do /etc/hosts do Controller no Network. Configura o NTP:

openstack@network:~$ sudo cat /etc/ntp.conf
server 192.168.0.2
openstack@network:~$ sudo service ntp restart
 * Stopping NTP server ntpd                                                                                                           [ OK ] 
 * Starting NTP server ntpd                                                                                                           [ OK ]

Por via das dúvidas, reinicie a máquina.

Serviços de Rede

Vamos agora configurar os serviços de rede.

Open-vSwitch

O Open-vSwitch é uma ferramenta de criação de switchs virtuais. Nós já instalamos o pacote acima, vamos iniciar o daemon:

openstack@network:~$ service openvswitch-switch start

Os comandos abaixo criam uma bridge virtual:

openstack@network:~$ sudo ovs-vsctl add-br br-int
openstack@network:~$ sudo ovs-vsctl add-br br-ex
openstack@network:~$ sudo ovs-vsctl add-port br-ex eth0
openstack@network:~$ sudo ip link set up br-ex 

Com isso, criamos uma bridge interna (br-int) e uma externa (br-ex). Devemos adicionar no /etc/network/interfaces a configuração abaixo para garantir conectividade pela rede externa:

Quantum

Vamos agora integrar o Quantum do network com o controller. Configure as seguintes opções no arquivo /etc/quantum/l3_agent.ini:

auth_url = http://192.168.0.2:35357/v2.0
admin_tenant_name = service
admin_user = quantum
admin_password = openstack
metadata_ip = 192.168.0.2
use_namespaces = False

Configure as seguintes opções no arquivo /etc/quantum/api-paste.ini:

auth_host = 192.168.0.2
admin_tenant_name = service
admin_user = quantum
admin_password = openstack

Configure as seguintes opções no arquivo /etc/quantum/quantum.conf:

core_plugin = quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
auth_strategy = keystone
fake_rabbit = False
rabbit_host = 192.168.0.2
rabbit_password = openstack

Configure as seguintes opções no arquivo /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini:

sql_connection = mysql://quantum:openstack@192.168.0.2:3306/quantum
tenant_network_type = gre
tunnel_id_ranges = 1:1000
enable_tunneling = True
integration_bridge = br-int
tunnel_bridge = br-tun
local_ip = 10.10.10.2

Configure a seguinte opções no arquivo /etc/quantum/dhcp_agent.ini:

use_namespaces = False

Agora, vamos reiniciar todos os serviços:

openstack@network:~$ sudo service quantum-plugin-openvswitch-agent restart
openstack@network:~$ sudo service quantum-dhcp-agent restart
openstack@network:~$ sudo service quantum-l3-agent restart

Redes Virtuais

Criação de Redes Virtuais

Vamos agora configurar o necessário para criação de redes virtuais. O primeiro passo é criar um arquivo com as variáveis de ambiente, para facilitar a execução dos comandos no prompt. O arquivo deve ser nomeado novarc:

export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL="http://192.168.0.2:5000/v2.0/"
export SERVICE_ENDPOINT="http://192.168.0.2:35357/v2.0"
export SERVICE_TOKEN=openstack

Vamos carregar essas variáveis e garantir que as mesmas são carregadas toda vez que entrarmos no sistema com o usuário ‘openstack’.

source novarc
echo "source novarc">>.bashrc

Vamos baixar o script de automação do site oficial do projeto. O script se chamada quantum-networking.sh. Nós temos que alterar os endereços IPs no script. A alteração será feita de acordo com a tabela na Parte 1 desse tutorial. A primeira coisa que temos que notar é que a nossa rede externa não é 7.7.7.0/24, mas sim 192.168.122.0/24. Portanto, altere os seguintes campos no script:

EXT_NET_CIDR="192.168.122.0/24"
EXT_GW_IP="192.168.122.3"
EXT_NET_GATEWAY="192.168.122.1"
POOL_FLOATING_START="192.168.122.130"   
POOL_FLOATING_END="192.168.122.150"     

Também aproveite para corrigir as últimas linhas do script. Elas executam comando que necessitam de privilégios de super-usuário.

sudo ip addr flush dev $EXT_NET_BRIDGE
sudo ip addr add $EXT_GW_IP/$EXT_NET_LEN dev $EXT_NET_BRIDGE
sudo ip link set $EXT_NET_BRIDGE up

Em seguir, execute o script:

openstack@network:~$ ./quantum-networking.sh 
Added interface to router 357a19df-004a-47ef-919b-3a7e4b0c1e53
Created a new subnet:
+------------------+--------------------------------------------------------+
| Field            | Value                                                  |
+------------------+--------------------------------------------------------+
| allocation_pools | {"start": "192.168.122.130", "end": "192.168.122.150"} |
| cidr             | 192.168.122.0/24                                       |
| dns_nameservers  |                                                        |
| enable_dhcp      | False                                                  |
| gateway_ip       | 192.168.122.1                                          |
| host_routes      |                                                        |
| id               | 05f4eb00-c3aa-494f-9b04-08ad8c895749                   |
| ip_version       | 4                                                      |
| name             |                                                        |
| network_id       | 4e7f1f37-b4a8-4111-a1d5-84245fe80500                   |
| tenant_id        | 4630c01242484c2ba63cf6392c78061c                       |
+------------------+--------------------------------------------------------+
Set gateway for router 357a19df-004a-47ef-919b-3a7e4b0c1e53
Configuração Layer3

Vamos configurar as funcionalidades da camada 3. Anote o identificador da rede externa (‘ext_net’) retornado pelo comando ‘quantum net-list’. Coloque no arquivo /etc/quantum/l3_agent.ini o campo ‘gateway_external_network_id = ID’, onde ID é o identificador da rede externa. Anote também o identificador do roteador ‘provider-router” retornado por ‘quantum router-list’ e atualize o campo ‘router_id = ID’ no mesmo arquivo. Para finalizar, reinicie o serviço:

openstack@network:~$ sudo service quantum-l3-agent restart
quantum-l3-agent stop/waiting
quantum-l3-agent start/running, process 32735

Com isso, finalizamos a configuração do nó Network.

Configuração de Um Ambiente de Testes para o OpenStack – Parte 2 – Controller

Aviso: este tutorial não funciona. Ele foi baseado em um guia que está no site oficial do projeto OpenStack (veja a parte 1). Entretanto, nos próprios comentários da página do tutorial, vários usuários relatam que as máquinas virtuais criadas não conseguem capturar um IP do DHCP. A razão do problema está relacionada com o serviço Quantum, cuja utilização no OpenStack é recente. Caso você deseje ter uma visão geral de virtualização e OpenStack, aconselho a seguir o tutorial mesmo assim. Na hora de aprender, um erro pode valer mais do que mil acertos.

Instalação e Configuração do OpenStack

Com as máquinas virtuais configuradas no post anterior, vamos partir para a configuração dos serviços do OpenStack. Em teoria, se você está usando máquinas reais, seria possível começar o tutoria a partir deste ponto.

Controlador

Com as máquinas criadas e configuradas, vamos para o OpenStack. Primeiro passo, vamos logar no Controller e configurar os repositórios do Ubuntu para utilizar a versão mais nova do OpenStack:

openstack@controller:~$ sudo apt-get install ubuntu-cloud-keyring
openstack@controller:~$ cat /etc/apt/sources.list.d/cloud-archive.list
deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/folsom main 
openstack@controller:~$ sudo apt-get update && sudo apt-get upgrade

Em seguida, edite o arquivo /etc/sysctl.conf com as seguintes opções:

net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0  

O arquivo /etc/hosts deve conter os endereços das máquinas da nuvem:

127.0.0.1       localhost
#127.0.1.1      controller
192.168.0.2     controller
192.168.0.3     network
192.168.0.4     compute

NTP

O NTP é um programa que sincroniza o tempo da máquina com um servidor da rede. Precisamos instalá-lo para garantir sincronização entre as máquinas da nuvem:

openstack@controller:~$ sudo apt-get install -y ntp
openstack@controller:~$ sudo cp /etc/ntp.conf /etc/ntp.conf.old
openstack@controller:~$ cat /etc/ntp.conf
server ntp.ubuntu.com iburst
server 127.127.1.0
fudge 127.127.1.0 stratum 10
openstack@controller:~$ sudo service ntp restart
 * Stopping NTP server ntpd                                                                                                                                                                                  
 * Starting NTP server ntpd       

MySQL

Instale o MySQL-Server, colocando a senha do banco como openstack. Configure o banco com os comandos abaixo.

openstack@controller:~$ sudo apt-get install mysql-server python-mysqldb
openstack@controller:~$ sudo sed -i 's/127.0.0.1/0.0.0.0/g' /etc/mysql/my.cnf
openstack@controller:~$ sudo service mysql restart
mysql stop/waiting
mysql start/running, process 4219
openstack@controller:~$ mysql -u root -p <<EOF
CREATE DATABASE nova; 
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' IDENTIFIED BY 'openstack'; 
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'192.168.0.1' IDENTIFIED BY 'openstack'; 
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'192.168.0.2' IDENTIFIED BY 'openstack'; 
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'192.168.0.3' IDENTIFIED BY 'openstack'; 
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'controller' IDENTIFIED BY 'openstack'; 
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'compute' IDENTIFIED BY 'openstack'; 
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'network' IDENTIFIED BY 'openstack'; 
CREATE DATABASE cinder; 
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'localhost' IDENTIFIED BY 'openstack';
CREATE DATABASE glance;
GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' IDENTIFIED BY 'openstack';
CREATE DATABASE keystone;
GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' IDENTIFIED BY 'openstack';
CREATE DATABASE quantum;
GRANT ALL PRIVILEGES ON quantum.* TO 'quantum'@'localhost' IDENTIFIED BY 'openstack';
GRANT ALL PRIVILEGES ON quantum.* TO 'quantum'@'192.168.0.2' IDENTIFIED BY 'openstack';
GRANT ALL PRIVILEGES ON quantum.* TO 'quantum'@'192.168.0.3' IDENTIFIED BY 'openstack';
GRANT ALL PRIVILEGES ON quantum.* TO 'quantum'@'controller' IDENTIFIED BY 'openstack'; 
GRANT ALL PRIVILEGES ON quantum.* TO 'quantum'@'network' IDENTIFIED BY 'openstack'; 
FLUSH PRIVILEGES;
EOF

RabbitMQ

O RabbitMQ é um sistema de mensagens:

openstack@controller:~$ sudo apt-get install rabbitmq-server
openstack@controller:~$ sudo rabbitmqctl change_password guest openstack
Changing password for user "guest" ...
...done.

Keystone

O Keystone é o serviço de identidade do OpenStack. Vamos primeiro configurar o banco de dados do Keystone:

openstack@controller:~$ sudo apt-get install keystone python-keystone python-keystoneclient
openstack@controller:~$ sudo mv /etc/keystone/keystone.conf /etc/keystone/keystone.conf.old
openstack@controller:~$ sudo cat /etc/keystone/keystone.conf
[DEFAULT]
admin_token = openstack
bind_host = 0.0.0.0
public_port = 5000
admin_port = 35357
compute_port = 8774
verbose = True 
debug = True 
log_file = keystone.log
log_dir = /var/log/keystone
log_config = /etc/keystone/logging.conf

[sql]
connection = mysql://keystone:openstack@localhost:3306/keystone
idle_timeout = 200
(resto igual ao arquivo original)
openstack@controller:~$ sudo service keystone restart
keystone stop/waiting
keystone start/running, process 6271
openstack@controller:~$ sudo keystone-manage db_sync

Vamos em seguida criar um arquivo com as variáveis de ambiente necessárias para interagir com o OpenStack:

openstack@controller:~$ cat novarc 
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL="http://localhost:5000/v2.0/"
export SERVICE_ENDPOINT="http://localhost:35357/v2.0"
export SERVICE_TOKEN=openstack
openstack@controller:~$ source novarc 
openstack@controller:~$ echo "source novarc">>.bashrc

O próximo passo é povoar o banco de dados do Keystone. Para isso, vamos fazer uso dos scripts keystone-data.sh e keystone-endpoints.sh . Baixe-os na máquina Controller. No keystone-data.sh, deixe o começo do script da seguinte forma:

ADMIN_PASSWORD="openstack"
SERVICE_PASSWORD="openstack"
SERVICE_TOKEN="openstack"
export SERVICE_ENDPOINT="http://localhost:35357/v2.0"
SERVICE_TENANT_NAME=${SERVICE_TENANT_NAME:-service}

Em seguida, torne o script executável e o invoque:

openstack@controller:~$ chmod +x keystone-data.sh 
openstack@controller:~$ ./keystone-data.sh 

No keystone-endpoints.sh, deixe o começo do script da seguinte forma:

# MySQL definitions
MYSQL_USER=keystone
MYSQL_DATABASE=keystone
MYSQL_HOST=localhost
MYSQL_PASSWORD=openstack
# Keystone definitions
KEYSTONE_REGION=RegionOne
SERVICE_TOKEN=openstack
SERVICE_ENDPOINT="http://localhost:35357/v2.0"
# other definitions
MASTER="192.168.0.2"

Em seguida, torne o script executável e o invoque:

openstack@controller:~$ chmod +x keystone-endpoints.sh 
openstack@controller:~$ ./keystone-endpoints.sh 
+-------------+----------------------------------+
|   Property  |              Value               |
+-------------+----------------------------------+
| description |    OpenStack Compute Service     |
|      id     | 7e658862c9244b0da03b0c7497681b9a |
|     name    |               nova               |
|     type    |             compute              |
+-------------+----------------------------------+
(...)

Com isso, temos o Keystone configurado.

Glance

Glance é o serviço de controle de imagens do OpenStack. Vamos instalar os pacotes:

openstack@controller:~$ sudo apt-get install glance glance-api glance-registry python-glanceclient glance-common

Configure as seguintes opções em ambos os arquivos /etc/glance/glance-api.conf e /etc/glance/glance-registry.conf:

sql_connection = mysql://glance:openstack@localhost/glance
admin_tenant_name = service
admin_user = glance
admin_password = password

Os arquivos possuem outras opções, deixe-as como estão. Apenas para o glance-api.conf, configure estas opções:

notifier_strategy = rabbit
rabbit_password = openstack

Agora é questão de reiniciar os serviços e carregar os dados do Glance no MySQL:

openstack@controller:~$ sudo  service glance-api restart
openstack@controller:~$ sudo  service glance-registry restart
openstack@controller:~$ sudo glance-manage db_sync

Em seguida, baixar uma imagem do Ubuntu pronta para a nuvem e registrá-la no Glance. Observe como o serviço é flexível: você pode informar a URL, não precisa baixar a imagem previamente.

openstack@controller:~$ glance image-create \
> --location http://uec-images.ubuntu.com/releases/12.04/release/ubuntu-12.04-server-cloudimg-amd64-disk1.img \
> --is-public true --disk-format qcow2 --container-format bare --name "Ubuntu"
+------------------+--------------------------------------+
| Property         | Value                                |
+------------------+--------------------------------------+
| checksum         | None                                 |
| container_format | bare                                 |
| created_at       | 2013-04-23T16:43:17                  |
| deleted          | False                                |
| deleted_at       | None                                 |
| disk_format      | qcow2                                |
| id               | 6aa23a63-f2eb-45cc-98bf-7e3d8becc6a4 |
| is_public        | True                                 |
| min_disk         | 0                                    |
| min_ram          | 0                                    |
| name             | Ubuntu                               |
| owner            | None                                 |
| protected        | False                                |
| size             | 251789312                            |
| status           | active                               |
| updated_at       | 2013-04-23T16:43:17                  |
+------------------+--------------------------------------+
openstack@controller:~$ glance image-list
+--------------------------------------+--------+-------------+------------------+-----------+--------+
| ID                                   | Name   | Disk Format | Container Format | Size      | Status |
+--------------------------------------+--------+-------------+------------------+-----------+--------+
| 6aa23a63-f2eb-45cc-98bf-7e3d8becc6a4 | Ubuntu | qcow2       | bare             | 251789312 | active |
+--------------------------------------+--------+-------------+------------------+-----------+--------+

Nova

O Nova é o serviço de computação, que trata da criação das máquinas virtuais. Apesar do controlador cuidar da gerência, também vamos instalar o Nova, para manter a uniformidade na nuvem e facilitar a configuração. Partimos para a instalação de pacotes:

openstack@controller:~$ sudo apt-get install nova-api nova-cert nova-common \
> nova-scheduler python-nova python-novaclient nova-consoleauth novnc \
> nova-novncproxy

O arquivo /etc/nova/api-paste.ini deve ser alterado nos seguintes campos:

admin_tenant_name = service
admin_user = nova
admin_password = password

Os campos abaixo deve ser removidos porque instalaremos o serviço Cinder nas próximas etapas, que trata de gerenciar os volumes, eliminando a necessidade do Nova fazer o mesmo. Comente as linhas abaixo no mesmo arquivo.

============================================================
[composite:osapi_volume]
use = call:nova.api.openstack.urlmap:urlmap_factory
/: osvolumeversions
/v1: openstack_volume_api_v1
============================================================

============================================================
[composite:openstack_volume_api_v1]
use = call:nova.api.auth:pipeline_factory
noauth = faultwrap sizelimit noauth ratelimit osapi_volume_app_v1
keystone = faultwrap sizelimit authtoken keystonecontext ratelimit osapi_volume_app_v1
keystone_nolimit = faultwrap sizelimit authtoken keystonecontext osapi_volume_app_v1
============================================================

============================================================
[app:osapi_volume_app_v1]
paste.app_factory = nova.api.openstack.volume:APIRouter.factory
============================================================

============================================================
[pipeline:osvolumeversions]
pipeline = faultwrap osvolumeversionapp

[app:osvolumeversionapp]
paste.app_factory = nova.api.openstack.volume.versions:Versions.factory
============================================================

Vamos agora editar o arquivo /etc/nova/nova.conf com as seguintes modificações:

[DEFAULT]

# MySQL Connection #
sql_connection=mysql://nova:openstack@192.168.0.2/nova

# nova-scheduler #
rabbit_password=openstack
scheduler_driver=nova.scheduler.simple.SimpleScheduler

# nova-api #
cc_host=192.168.0.2
auth_strategy=keystone
s3_host=192.168.0.2
ec2_host=192.168.0.2
nova_url=http://192.168.0.2:8774/v1.1/
ec2_url=http://192.168.0.2:8773/services/Cloud
keystone_ec2_url=http://192.168.0.2:5000/v2.0/ec2tokens
api_paste_config=/etc/nova/api-paste.ini
allow_admin_api=true
use_deprecated_auth=false
ec2_private_dns_show_ip=True
dmz_cidr=169.254.169.254/32
ec2_dmz_host=192.168.0.2
metadata_host=192.168.0.2
metadata_listen=0.0.0.0
enabled_apis=ec2,osapi_compute,metadata

# Networking #
network_api_class=nova.network.quantumv2.api.API
quantum_url=http://192.168.0.2:9696
quantum_auth_strategy=keystone
quantum_admin_tenant_name=service
quantum_admin_username=quantum
quantum_admin_password=openstack
quantum_admin_auth_url=http://192.168.0.2:35357/v2.0
libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
linuxnet_interface_driver=nova.network.linux_net.LinuxOVSInterfaceDriver
firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver

# Cinder #
volume_api_class=nova.volume.cinder.API

# Glance #
glance_api_servers=192.168.0.2:9292
image_service=nova.image.glance.GlanceImageService

# novnc #
novnc_enable=true
novncproxy_base_url=http://192.168.122.2:6080/vnc_auto.html
vncserver_proxyclient_address=192.168.0.2
vncserver_listen=0.0.0.0

# Misc #
logdir=/var/log/nova
state_path=/var/lib/nova
lock_path=/var/lock/nova
root_helper=sudo nova-rootwrap /etc/nova/rootwrap.conf
verbose=true

O comando abaixo serve para popular o banco de dados ‘nova’ com as tabelas necessárias. É recomendável executá-lo como root, em alguns instalações houve erros quando executado como usuário comum.

root@controller:~# nova-manage db sync
2013-04-25 10:43:28 11425 DEBUG nova.utils [-] backend <module 'nova.db.sqlalchemy.migration' from '/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/migration.pyc'> __get_backend /usr/lib/python2.7/dist-packages/nova/utils.py:506

A mensagem de DEBUG parece ser um problema da versão, mas não impede que o Nova funcione corretamente. Para finalizar, reiniciamos todos os serviços do Nova:

openstack@controller:/etc$ sudo service nova-api restart
openstack@controller:/etc$ sudo service nova-cert restart
openstack@controller:/etc$ sudo service nova-consoleauth restart
openstack@controller:/etc$ sudo service nova-scheduler restart
openstack@controller:/etc$ sudo service nova-novncproxy restart

Com isso, finalizamos o Nova.

Cinder

O Cinder possui uma funcionalidade que já existe no Nova, a gerência de blocos. Porém, essa funcionalidade está sendo separada em novo componente para facilitar a manutenção do Nova. Vamos instalar os pacotes do Cinder:

openstack@controller:~$ sudo apt-get install -y cinder-api cinder-scheduler cinder-volume iscsitarget open-iscsi iscsitarget-dkms python-cinderclient linux-headers-`uname -r`

Em seguida, inicializar os serviços iSCSI:

openstack@controller:~$ sudo sed -i 's/false/true/g' /etc/default/iscsitarget
openstack@controller:~$ sudo modprobe iscsi_trgt
openstack@controller:~$ service iscsitarget start
openstack@controller:~$ sudo service open-iscsi start

Coloque as seguintes opções no /etc/cinder/cinder.conf:

[DEFAULT]
sql_connection = mysql://cinder:openstack@localhost:3306/cinder
rabbit_password = openstack
rootwrap_config = /etc/cinder/rootwrap.conf
api_paste_confg = /etc/cinder/api-paste.ini
iscsi_helper = tgtadm
volume_name_template = volume-%s
volume_group = cinder-volumes
verbose = True
auth_strategy = keystone
state_path = /var/lib/cinder
volumes_dir = /var/lib/cinder/volumes

Altere as seguintes opções no /etc/cinder/api-paste.ini

admin_tenant_name = service
admin_user = cinder
admin_password = openstack

Precisamos utilizar agora o segundo disco da máquina controller. Se você executou a primeira seção deste tutorial sem problemas, deve haver um disco em /dev/sdb ou e /dev/vdb de 5Gb pronto para ser usado. Crie uma partição no dispositivo e depois execute os seguintes comandos:

openstack@controller:~$ sudo pvcreate /dev/sdb1
openstack@controller:~$ sudo vgcreate cinder-volumes /dev/sdb1

Com isso, configuramos um volume LVM para o Cinder. O sistema LVM é interessante pois permite adicionar mais espaço a partições sem a necessidade de reiniciar o servidor. Com isso feito, basta carregar o banco de dados do Cinder e reiniciar os serviços. Novamente, pode ocorrer uma mensagem de DEBUG na sincronização do banco. Ignore-a.

openstack@controller:~$ sudo service cinder-api restart
openstack@controller:~$ sudo service cinder-scheduler restart
openstack@controller:~$ sudo service cinder-volume restart

Com isso, finalizamos o Cinder.

Quantum

O Quantum é o serviço de configuração de redes da nossa nuvem. Vamos instalá-lo:

[soucecode language=”bash”]
openstack@controller:~$ sudo apt-get install quantum-server
[/sourcecode]

Deixe o arquivo /etc/quantum/quantum.conf com as opções da seguinte forma:

core_plugin = quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
auth_strategy = keystone
fake_rabbit = False
rabbit_password = openstack

Deixe o arquivo /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini com as opções da seguinte forma:

sql_connection = mysql://quantum:openstack@localhost:3306/quantum
tenant_network_type = gre
tunnel_id_ranges = 1:1000
enable_tunneling = True

Deixe o arquivo /etc/quantum/api-paste.ini com as opções da seguinte forma:

admin_tenant_name = service
admin_user = quantum
admin_password = openstack

Inicialize o serviço:

openstack@controller:~$ sudo service quantum-server restart

Dashboard

O Dashboard é a interface web do OpenStack. Sua configuração é fácil, basta instalar os pacotes:

openstack@controller:~$ sudo apt-get install apache2 libapache2-mod-wsgi openstack-dashboard memcached python-memcache

Terminamos o Controller! Agora acesse http://192.168.122.2/horizon e entre com o usuário ‘admin’ e a senha ‘openstack’. Se por acaso tiver algum problema, verifique se todos os serviços estão ativados na opção “Serviços” do DashBoard. O Rabbit não está lá, mas você pode ativá-lo com:

openstack@controller:/etc/init$ sudo update-rc.d rabbitmq-server enable
openstack@controller:/etc/init$ sudo service rabbitmq-server start

Configuração de Um Ambiente de Testes para o OpenStack – Parte 1 – Máquinas Virtuais

Aviso: este tutorial não funciona. Ele foi baseado em um guia que está no site oficial do projeto OpenStack (veja a parte 1). Entretanto, nos próprios comentários da página do tutorial, vários usuários relatam que as máquinas virtuais criadas não conseguem capturar um IP do DHCP. A razão do problema está relacionada com o serviço Quantum, cuja utilização no OpenStack é recente. Caso você deseje ter uma visão geral de virtualização e OpenStack, aconselho a seguir o tutorial mesmo assim. Na hora de aprender, um erro pode valer mais do que mil acertos.

Introdução

Vou apresentar aqui uma série de posts sobre a configuração de um ambiente de testes para o OpenStack. O objetivo desses posts é explicar como criar um ambiente de testes para a solução de nuvens IaaS OpenStack. Irei instalar os componentes do OpenStack (controller, network e compute) em três máquinas virtuais diferentes, de acordo com o tutorial encontrado no site do projeto. Para criação das máquinas virtuais, será usado o KVM. Para todos os efeitos, esse tutorial foi desenvolvido para o Ubuntu 12.04 LTS 64 Bits. A primeira parte trata da criação das máquinas virtuais.

Instalação e Configuração das Máquinas Virtuais

Instalação do KVM

O primeiro passo é verificar se seu sistema suporta virtualização por hardware. A maioria dos sistemas lançados depois do Intel Core 2 Duo possui suporte a virtualização. A exceção é o caso dos processadores da linha Atom. Para testar se o seu sistema tem suporte, execute o seguinte comando:

~$ sudo kvm-ok

Se a resposta for

INFO: /dev/kvm exists
KVM acceleration can be used

então seu sistema está configurado com o suporte ao KVM.

Agora vamos instalar os pacotes necessários:

~$ sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils virtinst

E adicione seu usuário ao grupo libvirtd. Depois disso, será necessário sair e logar novamente:

~$ sudo adduser `id -un` libvirtd

Com esses passos, você pode verificar a instalação com o seguinte comando:

~$ virsh -c qemu:///system list
 Id Name                 State
----------------------------------

Mais informações sobre a instalação do KVM na página do Ubuntu sobre o projeto

Criação das Máquinas Virtuais

Iremos criar três máquinas com as seguintes características:

Máquina Controller Network Compute
Discos 2 discos de 5G 1 disco de 5G 1 disco de 5G
Rede Externa (Host NAT) 192.168.122.2/24 192.168.122.3/24 192.168.122.4/24 (veja observação no final)
Rede Gerência 192.168.0.2/24 192.168.0.3/24 192.168.0.4/24
Rede Dados 10.10.10.2/24 10.10.10.3/24

As máquinas terão duas ou três interfaces de rede. O papel de cada rede ficará mais claro no decorrer do tutorial. Para a Rede Externa, a configuração ‘default’ do KVM é suficiente. Precisamos criar mais duas redes no KVM, Gerência e Dados, que não terão acesso a Internet. Servem para comunicação entre as máquinas virtuais. A primeira rede é definida no arquivo gerencia.xml:

<network>
	<name>gerencia</name>
        <bridge name="virbr1" />
        <ip address="192.168.0.1" netmask="255.255.255.0"/>
</network>

A outra rede é definida em um arquivo dados.xml:

<network>
	<name>dados</name>
        <bridge name="virbr2" />
        <ip address="10.10.10.1" netmask="255.255.255.0"/>
</network>

Em seguida, execute os comandos:

~$ virsh net-define dados.xml 
~$ virsh net-define gerencia.xml 
~$ virsh net-autostart dados
~$ virsh net-autostart gerencia
~$ virsh net-start dados
~$ virsh net-start gerencia
~$ virsh net-list
Name                 State      Autostart
-----------------------------------------
dados                active     yes       
default              active     yes       
gerencia             active     yes 

Por segurança, guarde os XMLs em uma pasta chamada networks/ no seu diretório de usuário. Agora, vamos para a criação das máquinas virtuais. Nós vamos criar as máquinas usando a versão 12.04.1 LTS do Ubuntu Server. Usaremos 512Mb de RAM para cada máquina. Novamente, é um ambiente de teste, desempenho não é o objetivo principal. Vamos começar pela Controller. Execute o comando abaixo:

~$ virt-install \
--connect qemu:///system \
--virt-type kvm --name Controller \
--ram 512 \
--disk path=/home/usuario/openstack/disks/controller1.img,size=5 \
--disk path=/home/usuario/openstack/disks/controller2.img,size=5  \
--vnc \
--cdrom /home/usuario/openstack/ubuntu-12.04.1-server-amd64.iso \
--network network=default --network network=gerencia 

O nome da máquina é Controller, usurá 512 megabytes de RAM. Dois discos são criados, cada um com 5 Gigabytes. Essa máquina dará boot pelo CD de instalação do Ubuntu. Duas interfaces de rede serão criadas, uma default (NAT) e outra privada. Agora execute os seguintes comandos para ter acesso à máquina pelo protocolo VNC:

~/openstack$ virsh list --all
 Id Name                 State
----------------------------------
  2 Controller           running
~/openstack$ virsh vncdisplay 2
:0
~/openstack$ vncviewer 127.0.0.1:0

A partir daí podemos instalar a máquina. Crie o usuário ‘openstack’ e a senha ‘openstack’. Não se preocupe, o SSH não é acessível pela Internet, está protegido pelo NAT. Use o mesmo par usuário/senha nas outras máquinas. O importante é lembrar de instalar o OpenSSH Server para termos acesso externo. Após a instalação, a máquina será desligada. Você deve reativá-la:

~$ virsh start Controller
~$ virsh list 
 Id Name                 State
----------------------------------
  3 Controller           running
~$ virsh vncdisplay 3
~$ :0

Observação: caso você esteja montando o ambiente de teste em uma máquina remota, não conseguirá acessar o VNC do KVM. O VNC não é criptografado por padrão, portanto ele só escuta no endereço 127.0.0.1. A saída é usar um túnel SSH da seguinte forma:

~$ ssh -L <porta_local>:<127.0.0.1>:<porta_destino> -N -f <usuario>@<maquina_destino>
~$ vncviewer 127.0.0.1:0

Só como exemplo de configuração de rede, o arquivo /etc/network/interfaces do Controller deve ficar assim:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
        address 192.168.122.2
        netmask 255.255.255.0
        network 192.168.122.0
        broadcast 192.168.122.255
        gateway 192.168.122.1
        dns-nameservers 192.168.122.1

auto eth1
iface eth1 inet static
        address 192.168.0.2
        netmastk 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        ### static routing ###
        post-up route add -net 192.168.0.0 netmask 255.255.255.0 dev eth1
        pre-down route del -net 192.168.0.0 netmask 255.255.255.0 dev eth1

As outras máquinas devem ser configuradas de forma semelhante de acordo com a tabela acima. Não vou mostrar esses passos. Para finalizar, os comandos para criar as outras duas máquinas são:

virt-install \
--connect qemu:///system \
--virt-type kvm \
--name Network \
--ram 512 \
--disk path=/home/usuario/openstack/disks/network.img,size=5G \
--vnc \
--cdrom /home/usuario/openstack/ubuntu-12.04.1-server-amd64.iso \
--network network=default --network network=gerencia  --network network=dados
virt-install \
--connect qemu:///system \
--virt-type kvm \
--name Compute \
--ram 512 \
--disk path=/home/usuario/openstack/disks/compute.img,size=5 \
--vnc \
--cdrom /home/usuario/openstack/ubuntu-12.04.1-server-amd64.iso \
--network network=default --network network=gerencia  --network network=dados     

Observação importante: No comando de criação da máquina Compute, estamos colocando também a rede default, que é a Rede Externa (Host Nat). Pela tabela acima e de acordo com o tutorial que tomamos como base, essa rede não seria necessária. Entretanto, quando formos configurar o nó, vamos precisar da Internet para poder instalar os pacotes. Então vamos proceder como se colocássemos o endereço 192.168.122.4 na máquina Compute, mas depois vamos desativá-lo.