Plataformas de Computação em Nuvem Privada:
Contextualização e Introdução
Este documento visa apresentar o conceito de ambientes de computação em
nuvem, no contexto de nuvem privada, e fornecer uma introdução à plata-
forma de orquestração de nuvem OpenStack.
Data de atualização: 7 de outubro de 2024
Revision: add05a341f4bbc51fecf1d5c8a9992591400771a
Conteúdo
1 Introdução 9
2 Plataformas de Nuvem Privada 10
2.1 Funcionalidades básicas . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 OpenStack 13
3.1 Missão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 O caminho OpenInfra . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Guia de princípios . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.1 Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Comparação com outras plataformas de nuvem . . . . . . . . . . 24
3.6 Configurações básicas para deploy . . . . . . . . . . . . . . . . . . . 26
3.7 Conceitos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 Processo de build e deploy 30
4.1 Kolla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Kolla-ansible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5 Serviços mais utilizados 36
5.1 Keystone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.1 Comandos do Keystone . . . . . . . . . . . . . . . . . . . . . 40
5.1.1.1 Domínios . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1.1.2 Projetos . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.1.3 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.1.4 Usuários . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.1.5 Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.1.6 Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Horizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2
5.3 Nova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3.1 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3.2 Fluxo de execução . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.3 Virtualizadores . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.4 Neutron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4.1 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.5 Cinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.5.1 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.5.2 Fluxo de execução . . . . . . . . . . . . . . . . . . . . . . . . 64
5.6 Glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.6.1 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.6.2 Fluxo de execução . . . . . . . . . . . . . . . . . . . . . . . . 66
5.7 Ceilometer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.7.1 Glossário de termos . . . . . . . . . . . . . . . . . . . . . . . 67
5.7.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.7.3 Pollsters dinâmicos . . . . . . . . . . . . . . . . . . . . . . . . 72
5.8 Gnocchi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.8.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.8.2 Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.8.3 Archive policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.9 CloudKitty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.9.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.10 Mistral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.10.1 Linguagem de fluxo de trabalho . . . . . . . . . . . . . . . . 84
5.10.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.11 Magnum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.11.1 Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.11.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3
5.12 Octavia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.12.1 Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.12.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.12.3 Principais funcionalidades . . . . . . . . . . . . . . . . . . . 94
5.13 Barbican . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.13.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.14 Aodh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.15 Heat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.15.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.15.2 Estrutura dos templates . . . . . . . . . . . . . . . . . . . . . 99
5.16 Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.17 OpenStack CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6 Componentes dependentes 106
6.1 RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.1.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.1.2 Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.2 Redis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.3 Memcached . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.3.1 Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.3.2 Comparação com o Redis . . . . . . . . . . . . . . . . . . . . 112
6.4 Etcd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.4.1 Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.5 InfluxDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.6 Kibana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.7 Grafana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.7.1 Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.7.2 Grafana vs Kibana . . . . . . . . . . . . . . . . . . . . . . . . 119
6.8 OpenSearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.8.1 Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4
Lista de Figuras
1 Computação em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Arquitetura lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Arquitetura conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 Arquitetura de rede do OpenStack . . . . . . . . . . . . . . . . . . . 22
5 Arquitetura de provedores do Keystone . . . . . . . . . . . . . . . 38
6 Fluxo de uso do Keystone . . . . . . . . . . . . . . . . . . . . . . . . 40
7 Listando os domínios . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8 Criação de um domínio . . . . . . . . . . . . . . . . . . . . . . . . . 41
9 Dashboard do Horizon . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10 Aba de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11 Aba de computação . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
12 Aba de volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
13 Aba de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
14 Aba de orquestração . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
15 Aba de administração . . . . . . . . . . . . . . . . . . . . . . . . . . 53
16 Aba de identidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
17 Arquitetura Nova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
18 Obtido de link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
19 Componentes do Neutron . . . . . . . . . . . . . . . . . . . . . . . . 61
20 Arquitetura do Cinder . . . . . . . . . . . . . . . . . . . . . . . . . . 64
21 Arquitetura do Glance . . . . . . . . . . . . . . . . . . . . . . . . . . 66
22 Arquitetura geral do Ceilometer . . . . . . . . . . . . . . . . . . . . 70
23 Processamento dos dados executado pelo Ceilometer notifica-
tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
24 Processamento dos dados executado pelo Ceilometer central . 71
25 Processamento dos dados executado pelo Ceilometer compute 71
26 Arquitetura geral do Gnocchi . . . . . . . . . . . . . . . . . . . . . . 75
6
27 Fluxo de execução do CloudKitty . . . . . . . . . . . . . . . . . . . . 81
28 Direct workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
29 Reverse workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
30 Arquitetura do Mistral . . . . . . . . . . . . . . . . . . . . . . . . . . 88
31 Clusters do Magnum . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
32 Arquitetura do Magnum . . . . . . . . . . . . . . . . . . . . . . . . . 91
33 Overview da arquitetura geral do Magnum . . . . . . . . . . . . . . 91
34 Arquitetura do Octavia . . . . . . . . . . . . . . . . . . . . . . . . . . 93
35 Funcionamento exemplificado do Octavia . . . . . . . . . . . . . . 94
36 Arquitetura do Barbican . . . . . . . . . . . . . . . . . . . . . . . . . 96
37 Arquitetura do Aodh . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
38 Uso do Heat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
39 Arquitetura do Heat . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
40 Arquitetura do Placement . . . . . . . . . . . . . . . . . . . . . . . . 102
41 Workflow do uso do Nova com o Placement . . . . . . . . . . . . . 103
42 Arquitetura do RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . 108
43 Dados suportados pelo Redis . . . . . . . . . . . . . . . . . . . . . . 110
7
Lista de Tabelas
1 Tabela comparativa de serviços – AWS vs. OpenStack vs. Apache
CloudStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2 Serviços disponíves para o Kolla . . . . . . . . . . . . . . . . . . . . 32
3 Comparação entre Redis e Memcached . . . . . . . . . . . . . . . . 112
8
1. Introdução
Durante os últimos anos, o uso da computação em nuvem (privada, pública
e/ou híbrida) teve um grande crescimento, intensificando as oportunidades no
mercado de serviços digitais. Para atender a demanda, a infraestrutura ne-
cessária para criar e manter esse tipo de ambiente aumenta constantemente,
impactando diretamente nos custos de gerenciamento e operação.
Ambientes de computação em nuvem são complexos e heterogêneos, pos-
suindo variáveis dinâmicas e inúmeros componentes que devem ser interliga-
dos e gerenciados. Para uma eficiente gestão de tais ambientes, é necessária a
adoção de ferramentas capazes de orquestrar a infraestrutura, auxiliando na
implantação, manutenção e gerência de serviços e sistemas de nuvem.
As plataformas Apache CloudStack e OpenStack são as principais alternati-
vas open source para criação de ambientes de nuvem privada, se destacando
pela robustez, maturidade dos projetos e amplitude de tecnologias e funciona-
lidades suportadas. Tais características se traduzem em centenas de compa-
nhias que adotam alguma dessas plataformas ao redor do mundo.
A SC Clouds vem ao encontro dessa necessidade, fornecendo consultoria,
suporte e desenvolvimento continuados aos provedores de infraestrutura de
nuvem e às empresas que possuem a tecnologia de nuvem como seu pilar base
para criação e fornecimento de serviços. Em modo de parceria com os clien-
tes é realizado o planejamento e execução de ambientes de computação em
nuvem que fornecem infraestrutura como serviço. Nossos profissionais pos-
suem domínio pleno das plataformas Apache CloudStack e OpenStack, sendo
responsáveis por diversas funcionalidades novas e correções de bugs dos pro-
jetos.
9
2. Plataformas de Nuvem Privada
Plataformas de orquestração de nuvem, como o Apache CloudStack e Open-
Stack, são utilizadas para prover nuvem privada, pública ou híbrida em empre-
sas e instituições ao redor do mundo. Elas são capazes de conectar diferentes
sistemas computacionais (armazenamento, rede e virtualizadores), criando a
abstração do modelo de infraestrutura como serviço para usuários e adminis-
tradores de sistema.
Tanto o OpenStack quanto o Cloudstack são softwares de orquestração de
ambientes de nuvem de código aberto e de uso gratuito. Ambos têm como ob-
jetivo o gerenciamento de recursos computacionais, trabalhando com o con-
ceito de virtualização para fornecimento de recursos sob demanda, focando
em prover recursos de infraestrutura como serviço.
Figura 1: Computação em Nuvem
2.1. Funcionalidades básicas
De acordo com a NIST
1
, a definição de computação em nuvem é: “Computa-
ção em nuvem é um modelo que permite o acesso geral, conveniente e sob de-
1
National Institute of Standards and Technology.
10
manda de recursos computacionais compartilhados e configuráveis, tais como,
redes, servidores, armazenamento, aplicações e serviços, que podem ser rapi-
damente provisionados e entregues ao usuário com um esforço mínimo de
gerenciamento ou de interação com o provedor de serviço”[1].
Tanto o CloudStack quanto o OpenStack oferecem funcionalidades básicas
e necessárias para o provisionamento de serviços de computação em nuvem.
Algumas das funcionalidades providas são:
• Serviços de computação
– Provisionamento de VMs e gerenciamento de seus recursos (redes,
memória, CPU, discos...);
– Gestão de imagens com as quais as VMs serão criadas;
– Suporte a múltiplos hypervisors tais como KVM, XenServer e Vmware.
• Serviços de rede
– Gestão e configuração de redes compartilhadas e dedicadas;
– Criação de VLANS e VXLANS (Overlay Networks);
– Definição de políticas de acesso e roteamentos;
– Gestão de DNS, QoS, Load Balancers e Firewalls.
• Serviços de Armazenamento
– Gestão de discos;
– Armazenamento baseado em objetos e blocos;
– Backups;
– Suporte a SDS (Software Defined Storage), e.g. Ceph/RBD.
• Serviços de monitoramento de recursos
– Monitoramento de eventos;
11
– Apresentação dos recursos disponíveis e utilizados;
– Precificação e cobrança (billing).
• APIs REST abertas, padronizadas e documentadas, para gerenciamento
de todos os serviços, automação e integração com outras ferramentas;
• Serviço de autenticação com integração nativa com LDAP;
• Suporte a sistemas federados SAML e OpenID Connect;
• Containers como serviço.
12
3. OpenStack
O projeto OpenStack consiste em um conjunto de componentes de software
que provêm serviços comuns para infraestrutura de nuvem. O OpenStack foi
desenvolvido a partir da cooperação entre a Anso Labs (contratada pela NASA),
que desenvolveu o projeto Nova para gerenciar o uso de recursos computacio-
nais de forma eficiente, com a Rackspace, que havia desenvolvido uma solução
para gerenciar o armazenamento de arquivos chamada Swift. A partir da união
dessas duas empresas, o projeto foi oficialmente anunciado no dia 21 de julho
de 2010. Em 2012, a Rackspace criou uma fundação independente, a Open-
Stack Foundation, a qual recebeu o controle do projeto. Em 2020, a OpenStack
Foundation alterou seu nome para Open Infrastructure Foundation, de modo
a refletir melhor seu posicionamento, onde a mesma foca-se em infraestrutura
de nuvem e não somente na plataforma OpenStack.
3.1. Missão
A missão do OpenStack é “produzir uma plataforma onipresente de com-
putação em nuvem de código aberto que seja fácil de usar, simples de imple-
mentar, interoperável entre implantações, funcione bem em todas as escalas
e atenda às necessidades de usuários e operadores de nuvens públicas e pri-
vadas”.
3.2. O caminho OpenInfra
O caminho OpenInfra é baseado em quatro políticas open:
• Open Source:
Comprometimento em criar projetos verdadeiramente open source, os
quais são usáveis e escaláveis. Projetos verdadeiramente open source não
possuem recursos ou desempenho limitados. A licença utilizada é a Apa-
che License, versão 2.0.
13
• Open Design:
A cada ciclo de desenvolvimento, a comunidade realiza eventos presen-
ciais para reunir requisitos e escrever especificações para o próximo lan-
çamento. Esses eventos, abertos a qualquer pessoa, incluem usuários,
desenvolvedores e projetos upstream. São reunidos requisitos, definidas
prioridades e desenvolvido o design técnico para orientar o desenvolvi-
mento para o próximo ciclo de desenvolvimento. A comunidade controla
o processo de design.
• Open Development:
O desenvolvimento é aberto. O código-fonte é aberto durante todo o pro-
cesso de desenvolvimento. Os reviews de código são abertos. Os road-
maps são abertos. Com isso, a participação no processo de desenvolvi-
mento se torna mais simples, o que permite aos usuários de seguirem o
processo de desenvolvimento.
• Open Community:
A comunidade é aberta, sendo um dos objetivos mantê-la saúdavel, tanto
para usuários quanto para desenvolvedores. A maioria das decisões é
tomada usando o conceito de consenso lazy
2
. Todos os processos são
documentados, abertos e transparentes. A governança técnica do projeto
é fornecida pela própria comunidade, com os contribuidores elegendo os
líderes da equipe e os membros do comitê técnico. Todas as reuniões
do projeto são realizadas em canais públicos e gravadas. A comunicação
técnica adicional é feita por meio de listas de e-mail públicas e arquivada.
3.2.1. Guia de princípios
Além dos quatro opens, existe um conjunto de princípios orientadores que
são usados para informar e moldar decisões:
2
Trata-se de uma política de tomada de decisão que pressupõe consentimento geral se
nenhuma resposta for publicada dentro de um período de tempo definido.
14
• OpenStack único:
OpenStack é uma comunidade com uma missão comum, produzindo uma
estrutura de componentes colaborativos. A organização é dividida em re-
positórios e equipes de código-fonte separados, permitindo que os co-
laboradores se concentrem em suas áreas de interesse e especialização,
mas isso não faz do OpenStack uma coleção solta de projetos desconec-
tados.
• OpenStack produz, primariamente, software:
É esperado que as pessoas utilizem o software produzido pela comuni-
dade, em vez de implementações alternativas da API.
• OpenStack é feito para os usuários:
O OpenStack foi desenvolvido para ser implantado e usado. Por isso, an-
tes de qualquer decisão, deve-se levar em consideração as necessidades
de futuros usuários assim como dos usuários atuais.
• A contribuição é a moeda do OpenStack:
A contribuição é o mecanismo de mudança e como a confiança é cons-
truída entre os membros da comunidade. Embora exista liderança eleita,
essa liderança não é a única responsável pela mudança. Toda a comu-
nidade OpenStack tem autonomia para identificar problemas e, sempre
que possível, reunir equipes para resolvê-los.
• Revisão por pares são valorizadas:
A revisão por pares é uma parte fundamental da cultura. A revisão por
pares ajuda a construir confiança entre os membros da equipe e dá a
oportunidade de ensinar uns aos outros sobre diferentes partes do soft-
ware, sistema de CI e processos. Sem a boa vontade dos colaboradores e
revisores, não existiria comunidade.
Os comentários da revisão devem ser construtivos para que o processo
15
de revisão cumpra o seu propósito. O foco deve estar sempre na melho-
ria incremental do sistema como um todo, em vez de garantir que cada
mudança individual seja perfeita.
• Um contribuidor, um voto:
Contribuidores com muitas participações não tem mais voz do que quem
tem menos participações.
• Democracia representativa:
Todas as decisões são tomadas ou delegadas por pessoas que foram elei-
tas democraticamente.
• Os líderes do OpenStack existem para servir a comunidade
• Mudanças na liderança são boas:
É importante para a saúde do OpenStack a longo prazo que seus líderes
eleitos democraticamente mudem ao longo do tempo para permanece-
rem representativos do corpo de contribuidores. Os líderes, especifica-
mente, devem considerar deixar o seu papel quando não conseguirem
mais concentrar-se totalmente nele, e garantir sempre um bom caminho
de transição com os seus sucessores.
• Comunicação aberta, clara e amigável é valorizada:
A comunicação clara melhora a capacidade de colaborar para resolver
desafios técnicos de forma mais eficaz.
• OpenStack primeiro, time do Projeto em segundo, Empresa em terceiro:
Espera-se que os líderes do OpenStack coloquem as necessidades do Open-
Stack em primeiro lugar na sua tomada de decisão, antes das necessida-
des de qualquer equipe de projeto individual. Espera-se também que eles
coloquem as necessidades de sua equipe de projeto antes das necessida-
des da organização para a qual trabalham, se houver. Em caso de confli-
16
tos de interesse, devem estar prontos para deixar essas necessidades de
lado e tomar a melhor decisão para o OpenStack como um todo.
• Capacitando as empresas em condições de concorrência equitativas:
Desde o início, a OpenStack tem se esforçado para apoiar empresas que
criam produtos no OpenStack ou com ele e ajudá-las a ter sucesso. No
entanto, o OpenStack não deve capacitar uma empresa em detrimento
de outra. Embora as necessidades das empresas constituintes sejam es-
senciais, elas devem ser equilibradas entre si, para que as decisões do
OpenStack não sejam tomadas involuntariamente por pessoas não elei-
tas, a portas fechadas.
• Deve-se sempre ser seguido o caminho OpenStack:
Ninguém está acima das regras. Se partes do OpenStack existirem fora
das regras, todos sofrerão. Embora possa ser tentador contornar o pro-
cesso por conveniência, fazê-lo não é escalável do ponto de vista da co-
munidade. Grandes alterações de código projetadas fora dos processos
da comunidade e decisões tomadas fora da governança do OpenStack
são rejeitadas.
• Participação voluntária:
A liderança do OpenStack não deveria precisar se encontrar na posição de
fazer cumprir as regras porque a participação na comunidade OpenStack
é uma escolha feita pelos seus participantes em primeiro lugar. Caso o
participante não concorde com o caminho OpenStack, o mesmo deve bus-
car outra comunidade.
3.3. Arquitetura
A arquitetura do OpenStack tem por características:
• É composta por diversos componentes independentes, chamados de ser-
viços.
17
• A maior parte dos serviços são feitos em Python, o que permite um de-
senvolvimento mais rápido dos mesmos.
• Todos os serviços se autenticam através de um serviço de identidade co-
mum a todos.
• Todos os serviços definem APIs REST, sendo que é através de tais APIs que
ocorre a comunicação entre diferentes serviços e entre usuários finais e
serviços.
• Cada serviço pode ser composto, internamente, por diferentes compo-
nentes. Os componentes de um serviço comunicam-se entre si através
de uma fila de mensagem. O uso de tal fila provê várias vantagens, como
enfileiramente de requisições, baixo acoplamento e distribuição de carga
entre os consumidores.
Os usuários podem acessar o OpenStack por meio de uma interface web
disponibilizada pelo Horizon, por meio de clientes de linha de comando (CLI) e
através de chamadas diretamente para as APIs REST.
As Figuras 2 e 3 representam a arquitetura lógica e conceitual do OpenStack,
respectivamente:
18
Figura 3: Arquitetura conceitual
Obtido de link
Além disso, os serviços do OpenStack podem ser classificados, de forma
genérica, em:
• Controle:
Consiste nos serviços de gerência de todos os componentes do Open-
Stack, tais como a fila de mensagem e Keystone.
• Rede:
Consiste nos serviços dos componentes do Neutron, como os agentes
DHCP, L3 e Open vSwitch. Provê rede para todas as VMs que estão no
OpenStack.
20
• Computação:
Consiste nos serviços de criação e gerência de VMs.
• Armazenamento:
Consiste nos serviços que provêm armazenamento, seja de blocos e ob-
jetos, para o resto dos componentes do OpenStack.
3.3.1. Rede
A arquitetura de rede de um ambiente OpenStack pode variar de acordo
com o tamanho do ambiente, assim como o objetivo do mesmo. Entretanto,
uma arquitetura de rede mínima consiste em:
• Pública: rede que conecta todos os componentes do OpenStack, além de
ser acessível para usuários finais.
• Guest: rede que conecta as VMs do ambiente entre si.
Apesar de essa ser a arquitetura mínina para ambientes OpenStack, a ar-
quitetura recomendada, vide Figura ??, consiste em:
• Gerência: conecta todos os serviços internos do OpenStack.
• Guest: conecta todas as VMs do ambiente entre si.
• Armazenamento: conecta os serviços que provêm armazenamento para
as VMs.
• Pública: conecta os serviços do OpenStack para acesso pelos usuários
finais.
21
Figura 4: Arquitetura de rede do OpenStack
fig:network
3.4. Serviços
Devido ao fato de o OpenStack ser um sistema modularizado, é possível
criar uma nuvem através de diversas configurações. Dito isso, os principais
componentes de uma nuvem OpenStack estão apresentados na tabela abaixo:
• Nova:
Gerencia a alocação e liberação de máquinas virtuais de acordo com a
demanda. Uma de suas caracteristicas principais é facilitar ao máximo a
introdução de novas funcionalidades, permitindo uma alta escalabilidade,
tolerância à falhas e compatibilidade com APIs de outros sistemas
– Objetivo: Computação;
– Serviço core;
– Depende do Keystone, Glance, Cinder (opcional) e Neutron.
• Glance:
Responsável por criar imagens de todas as máquinas virtuais e armazená-
las em disco, assim como definições de metadados
22
– Objetivo: Serviço de imagem;
– Serviço core;
– Depende do Keystone
• Horizon:
Através de uma interface web, o módulo oferece acesso aos os serviços
do OpenStack, sendo possível instalar plugins para poder acessar serviços
que não são acessíveis nativamente pelo Horizon.
– Objetivo: Gerenciamento;
– Depende do Keystone
• Keystone:
Responsável por autenticar e autorizar todos usuários, dando a cada um
deles os privilégios adequados. Este gerenciamento é realizado através
de uma base de dados MySQL
– Objetivo: Identidade;
– Serviço core;
– Não possui dependências.
• Neutron:
Responsável por gerenciar interfaces de rede de modo escalável e voltado
à APIs.
– Objetivo: Rede;
– Serviço core;
– Depende do Keystone e do Nova.
23
• Cinder:
Abstrai o conceito de volume de VMs, permitindo a migração de volu-
mes, o compartilhamento dos mesmos entre diferentes projetos, backups
e snapshots, além da acoplagem de volumes em VMs.
– Objetivo: Armazenamento de Blocos;
– Serviço core;
– Depende do Keystone.
• Ceilometer:
Torna possível monitorar o funcionamento de todo o sistema.
– Objetivo: Telemetria;
– Depende do Keystone.
• Ironic:
Serve como uma API de hypervisor bare metal e um conjunto de plugins
que interagem com os hypervisor bare metal. Por padrão, usa PXE e IPMI
para provisionar e ligar/desligar máquinas, mas também oferece suporte
a plugins específicos de fornecedores que podem implementar funciona-
lidades adicionais.
– Objetivo: Serviço Bare Metal;
– Depende do Keystone.
Uma lista completa dos serviços do OpenStack podem ser encontrados no
Apêndice A.
3.5. Comparação com outras plataformas de nuvem
A Tabela 3.5 apresenta uma comparação entre os principais serviços ofere-
cidos pela AWS e com Apache CloudStack e OpenStack.
24
Tabela 1: Tabela comparativa de serviços – AWS vs. OpenStack vs. Apache CloudStack
Funcionalidades AWS OpenStack Apache CloudStack
Portal robusto para
gerenciamento dos recursos
Customização do portal
Estrutura de reseller
Virtualização (VMs)
Gestão de templates
CaaS
DBaaS
FaaS
Armazenamento em bloco
Object store
VPN, LB e
firewall
VPC
DNS
Integração com
appliances
Self-service
Contabilização de
consumo de recurso
Auditagem
APIs REST
padrão de mercado
Suporte a LDAP
Suporte a identidade
federada
Escalonamento de máquinas
virtuais em execução
Balanceamento de
carga com base
em contexto
Algoritmos dinâmicos
de alocação de recursos
Criação de pipelines
25
Ambos Apache CloudStack e OpenStack possibilitam a estruturação de ofer-
tas de serviços semelhantes às fornecidos por uma nuvem pública como a AWS,
desde as mais básicas até as mais avançadas.
Devido seu contexto histórico, o Apache CloudStack é uma ferramenta mais
pronta para o mercado, no sentido de possibilitar a gestão da nuvem de ma-
neira flexível e descomplidada, e possibilitando a customização da mesma com
a identidade da organização. Ela foca também na experiência do usuário, pro-
visionando um painel descomplicado para a gestão dos recursos e funcionali-
dades como o escalonamento de máquinas virtuais em execução. Demandas
mais avançadas, como DBaaS, FaaS e object store, ainda não são possíveis aten-
der com essa plataforma, contudo, são passíveis de adoção.
O OpenStack, por outro lado, é uma plataforma que oferece funcionalida-
des mais avançadas e específicas, atendendo casos de uso e operações mais
complexas. O foco da ferramenta não é a experiência do usuário, contudo,
é possível utilizar portais de terceiros para gerenciar a plataforma e oferecer
uma melhor experiência ao usuário.
3.6. Configurações básicas para deploy
Para criar um deploy mínimo do OpenStack, é necessário apenas uma má-
quina, na qual os componentes do OpenStack serão instalados. A recomenda-
ção de configuração de hardware para tal é:
Componente Mínimo Recomendado
CPU 4 cores 2.4 GHz 24 cores 2.67 GHz
RAM 8 GB 24 GB ou mais
Armazenamento 2 x 500 GB 4 x 500 GB
Os serviços mínimos para realizar o deploy do OpenStack são:
• Keystone;
• Nova;
26
• Glance;
• Neutron
Com esses componentes, será possível realizar o deploy de VMs, embora,
com tais componentes, funcionalidades mais avançadas, como gerenciamento
de volumes das VMs, não é possível.
A SC Clouds recomenda a seguinte configuração de serviços no deploy do
OpenStack, de forma a ter as funcionalidades básicas esperadas de uma nu-
vem:
• Keystone;
• Nova;
• Neutron;
• Cinder;
• Horizon;
• Glance
E, caso seja desejável as funcionalidades de bilhetagem e métricas do am-
biente:
• Ceilometer;
• Cloudkitty;
• Gnocchi
3.7. Conceitos básicos
Os recursos da infraestrutura de nuvem são organizados em projetos. Pro-
jetos são, geralmente, criados por administradores da nuvem, sendo que tais
administradores tem a responsabilidade de alocar cotas para os projetos. Os
recursos gerenciados por quotas de um projeto incluem:
27
• Número de vCPUs;
• Quantidade de RAM (em MB);
• Número de volumes;
• Uso do storage em GB (volume_storage);
• Número de snapshots de volumes;
• Número de backups;
• Uso de storage em GB pelos backups (backup_gigabytes);
• Número de routers;
• Número de redes;
• Número de floating IPs;
• Número de regras de firewall;
• Número de grupos de regras de firewall.
O usuário não consegue utilizar mais recursos do que a cota definida para o
projeto do qual faz parte. No projeto, é possível definir vários recursos, sendo
alguns dos mesmos:
• Flavours: se tratam das configurações possíveis para o hardware de uma
VM. Cada flavour possui um conjunto pré-definido de RAM, vCPUs e outros
recursos de hardware. É possível alterar o flavour de uma VM, de forma a
incrementar ou decrementar os recursos da mesma. Flavours são, geral-
mente, criados apenas por administradores. Flavours apenas podem ser
alterados com a VM parada
3
.
3
Via Horizon e API, é possível realizar a alteração de flavour com a VM rodando, porém a
mesma será automaticamente parada pelo OpenStack, sem notificar o usuário disso.
28
• Imagens: consistem nas imagens que servem de base para as VMs, po-
dendo ser ISOs ou imagens com o SO já previamente instalado e configu-
rado. As imagens podem ter sua visibilidade como pública (acessível para
todos os projetos), privadas (acessível apenas para o projeto que é dono
de tal imagem), compartilhada entre alguns projetos.
• Instâncias: são as VMs.
• Security Groups: contém uma coleção de regras de firewall para controlar
o acesso de/para as VMs.
• Security Group Rules: associado com um security group, contém as defini-
ções de regras de firewall de tal grupo.
29
4. Processo de build e deploy
Existem diferentes formas de realizar o build e deploy do OpenStack, sendo
algumas das principais:
• Build manual: nessa opção, o próprio operador gera os serviços necessá-
rios ao preparar para implantação o código-fonte dos mesmos. Alterna-
tiva não escalável.
• Kolla: nessa opção são geradas imagens de contêineres sobre os serviços
do OpenStack, as quais são utilizadas posteriormente para criar o ambi-
ente de nuvem OpenStack.
• Kolla-ansible: Ansible que utiliza os contêineres gerados pelo Kolla para
criar a nuvem OpenStack de forma automatizada. Permite escalar o de-
ploy da mesma de forma mais intuitiva.
• Juju: solução proprietária da Canonical, permite criar uma nuvem Open-
Stack com poucos passos e de forma simples.
4.1. Kolla
Devido a sua facilidade de uso em comparação com as outras opções, in-
cluindo a escalabilidade da solução, além de ser uma alternativa open source, a
SC Clouds opta por utilizar o Kolla no deploy de um ambiente de nuvem Open-
Stack.
O projeto Kolla é utilizado para criar imagens de contêineres dos serviços
do OpenStack. O mesmo necessita de um motor de contêiner para poder criar
as imagens. As opções disponíveis são:
• Docker
• Podman
Para utilizar o Kolla, é necessário realizar a instalação dos seguintes pacotes
via pip:
30
pip install kolla
pip install podman|docker # dependendo de qual será utilizado
Uma vez que o Kolla esteja instalado, é possível gerar as imagens com o
comando:
kolla-build
Para gerar as imagens baseadas em determinada distro, o comando é:
kolla-build -b <distro>
Sendo as opções disponíveis:
• centos;
• debian e
• ubuntu.
Ao não especificar nenhum serviço para geração das imagens, o comporta-
mento padrão é o de gerar todas elas. A Tabela 4.1 exibe os serviços disponí-
veis.
31
Tabela 2: Serviços disponíves para o Kolla
aodh barbican bifrost
blazar ceilometer cinder
cloudkitty collectd cron
cyborg designate dnsmasq
etcd fluentd freezer
glance gnocchi grafana
hacluster hacluster-pcs haproxy
heat horizon influxdb
ironic iscsid keepalived
keystone kolla-toolbox kuryr
magnum manila mariadb
masakari memcached mistral
multipathd murano neutron
neutron-mlnx-agent nova nova-spicehtml5proxy
octavia opensearch openvswitch
ovn ovsdpdk placement
prometheus rabbitmq redis
sahara senlin skyline
solum swift tacker
telegraf tgtd trove
vitrage watcher zun
Para especificar a criação de uma imagem de um serviço, o comando é:
kolla-build <service> <another-service>
Através do arquivo kolla-build.conf é possível especificar a localização de
onde será obtido o código-fonte para a geração das imagens. Com isso, é pos-
sível especificar um repositório remoto ou local como base para as imagens:
[keystone-base]
type = git
location = https://opendev.org/openstack/keystone
reference = stable/mitaka
[heat-base]
type = local
location = /home/kolla/src/heat
Finalmente, para enviar as imagens criadas para um registry específico (do
Docker ou do Podman), o comando é:
kolla-build [image|image] --registry <ip>:<port> --push
32
4.2. Kolla-ansible
O Kolla-ansible é um projeto Ansible que pode ser utilizado para realizar o
deploy de uma nuvem OpenStack, utilizando imagens de contêiner para tal. O
mesmo permite automatizar o processo de deploy, ao passo que possui flexi-
bilidade suficiente para permitir ao operador definir quais serviços farão parte
da nuvem. Além disso, o mesmo permite realizar o deploy em apenas um host
ou em múltiplos hosts.
Para poder utilizá-lo, os passos necessários são
4
:
1. Instalar os pacotes necessários:
apt install git python3-dev libffi-dev gcc libss l-dev python3-venv python3-docker
2. Criar e ativar o virtual environment do Python:
python3 -m venv /path/to/venv
source /path/to/venv/bin/activate
3. Instalar as dependências necessárias, via pip:
pip install 'ansible-core>=2.14,<2.16' kolla-ansible
4. Criar o diretório /etc/kolla e dar permissões de acesso para o usuário cor-
rente:
mkdir -p /etc/kolla
chown $USER:$USER /etc/kolla
5. Copie os arquivos de configurações globais e de senhas gerados ao ins-
talar o kolla-ansible:
cp -r /path/to/venv/share/kolla-ansible/etc_examples/kolla/* /etc/kolla
6. Dependendo se o deploy será realizado em um único host ou em vários,
copie o arquivo all-in-one ou o multinode para o diretório atual. Nesse
documento, será utilizado o deploy em um único host:
cp /path/to/venv/share/kolla-ansible/ansible/inventory/all-in-one .
cp /path/to/venv/share/kolla-ansible/ansible/inventory/multinode .
4
Aqui será utilizado para demonstração o sistema operacional Ubuntu. A sintaxe dos co-
mandos pode variar, de acordo com a distribuição utilizada.
33
7. Instale as dependências do Ansible Galaxy:
kolla-ansible install-deps
8. Preencha manualmente as senhas contidas no arquivo /etc/kolla/passwor
ds.yml que serão usadas pelos serviços do OpenStack ou utilize o seguinte
comando para gerar tais senhas de forma aleatória:
kolla-genpwd
9. Edite o arquivo /etc/kolla/globals. yml. Tal arquivo contém as configura-
ções centrais que serão utilizadas durante o deploy do OpenStack. Aqui,
as principais configurações a se ter em mente são:
• kolla _base_distro: qual será a distribuição que será utilizada como
base durante o deploy. Os valores possíveis são:
– centos;
– debian;
– rocky e
– ubuntu.
• network_interface: interface padrão que será utilizada pelos serviços
do OpenStack.
• neutron_e xte rna l_inte rfa ce: interface que será utilizada pelo Neu-
tron para prover acesso externo. É necessário que tal interface não
possua nenhum IP associado a mesma.
• kolla_internal_vi p_ ad dr es s: IP não utilizado por mais ninguém e que
está no range de IPs da interface definida em network_interface. Tal
IP será utilizado como flutuante para garantir a alta disponibilidade.
Caso seja realiza um deploy sem o uso de HAProxy ou Keepalived, o
valor de tal IP deve ser o mesmo existente na interface definida em
network_interface.
• enable_<nome_do_componente>: definem quais componentes e ser-
viços serão habilitados.
34
10. Utilize o Kolla para realizar o download de todas as dependências neces-
sárias, como Docker, para os hosts:
kolla-ansible -i ./all-in-one bootstrap-servers
11. Realize checagens para garantir que os hosts estão corretamente configu-
rados:
kolla-ansible -i ./all-in-one prechecks
12. Realize o deploy do OpenStack
kolla-ansible -i ./all-in-one deploy
13. Realize as últimas alterações após finalizar o deploy:
kolla-ansible post-deploy
Esse comando irá gerar o arquivo /e tc/kolla/admin-openrc.sh, que con-
terá as variáveis de ambiente necessárias para acessar o OpenStack.
14. Instale o cliente de linha de comando do OpenStack, para interagir com o
mesmo:
pip install python-openstackclient
Opcional Execute o script init-runonce para gerar exemplos de imagens, redes, en-
tre outros:
/path/to/venv/share/kolla-ansible/init-runonce
Com isso, o deploy do OpenStack estará finalizado. Alguns comandos extras
que o Kolla-ansible oferta são:
• Destruir a nuvem OpenStack:
kolla-ansible -i all-in-one destroy
• Atualizar a nuvem OpenStack:
kolla-ansible -i all-in-one upgrade
• Parar todos os contêineres:
kolla-ansible -i all-in-one stop
35
5. Serviços mais utilizados
A arquitetura modular do OpenStack se evidencia pela existência dos seus
componentes. Para cada projeto pode-se escolher a implantação de uma com-
binação de componentes. A escolha de componentes pode ter um impacto
significativo sobre a concepção global do projeto.
Embora existam certos componentes que estão sempre presentes, como
por exemplo o Compute (Nova) e o Serviço de Imagem (Glance), existem outros
serviços que não são necessários. A presente seção se destina a apresentar
os componentes mais utilizados no OpenStack, os quais serão abordados nas
subseções seguintes, sendo eles:
• Keystone;
• Horizon;
• Nova;
• Neutron;
• Cinder;
• Glance;
• Ceilometer;
• Gnocchi;
• CloudKitty;
• Mistral;
• Magnum;
• Octavia;
• Barbican;
36
• Aodh;
• Heat;
• Placement e
• OpenStack CLI.
5.1. Keystone
Keystone implementa os processos de autenticação e autorização dos usuá-
rios do ambiente da nuvem OpenStack. A gestão de acessos entre os demais
componentes é feita com o uso de tokens. Deste modo, o Keystone é um serviço
essencial para todo o ecossistema de componentes OpenStack.
Consiste em um conjunto de componentes, chamados geralmente de pro-
vedores, representados na Figura 5, que são responsáveis pela autenticação e
autorização de usuários e demais serviços na nuvem OpenStack. Cada compo-
nente implementa um conceito da arquitetura do Keystone:
• Identidade:
Fornece validação de credenciais de autenticação e dados sobre usuários
e grupos. Pode armazenar os dados dos usuários em um banco de dados
relacional, ou pode se conectar com um LDAP para obter esses dados.
• Resource:
Fornece dados sobre projetos e domínios. Como o serviço de Identidade,
estes dados podem ser gerenciados diretamente pelo serviço, através de
um banco de dados relacional local, ou serem obtidos de outro serviço de
backend, como o LDAP.
• Assignment:
Fornece dados sobre roles, incluindo qual role é utilizada por entidades
que são geridas pelos serviços de Identidade e de Resource.
37
• Token:
Para acessar os serviços do OpenStack, o usuário, seja outro serviço ou
um usuário final, deve se autenticar com o serviço de Identidade. Uma vez
que o usuário é autenticado, um token é gerado, o qual permite o acesso
do usuário a outros serviços. Tal token é válido durante um período de
tempo configurável.
• Catalog:
Mantém o registro de todos os serviços do OpenStack e seus respectivos
endpoints. É utilizado para que tanto usuários quanto serviços do Open-
Stack descubram os serviços que estão executando na nuvem OpenStack.
Figura 5: Arquitetura de provedores do Keystone
Além disso, existem os seguintes conceitos que são utilizados no Keystone:
• Domínio:
Conjunto de mais alto nível para organização dos projetos, usuários e gru-
pos.
38
• Projetos
5
:
Conjunto de grupos e usuários. Pode representar um cliente, conta ou
organização.
• Grupos:
Conjunto de usuários contidos dentro de um domínio.
• Usuário:
Representa uma pessoa, sistema ou serviço, que possui um conjunto de
credências, como nome de usuário e senha ou nome de usuário e chave
de API, e que utiliza o OpenStack. Um usuário deve ser membro de ao
menos um projeto, e pode ser membro de múltiplos projetos. Além disso,
o mesmo pertence ao menos a um domínio, embora possa ter acesso à
outros.
• Roles:
Conjunto de permissões que determinado usuário possui e que o habili-
tam a realizar certas operações. As roles são controladas pelo sistema de
políticas, e são definidas no arquivo policy.json, localizada em /etc/keysto
ne/policy.json, o qual é configurável e independente em cada componen-
te/serviço.
A Figura 6 representa o fluxo de uso do Keystone.
5
Antigamente chamados de tenants.
39
Figura 6: Fluxo de uso do Keystone
Obtido de link
5.1.1. Comandos do Keystone
A presente seção irá apresentar alguns comandos aceitos pelo Keystone,
partindo que o OpenStack client esteja instalado e as credências de acesso se-
jam as corretas para executar esses tipos de operação.
5.1.1.1. Domínios
• Listar domínios:
A sintaxe de listagem de domínios é:
openstack domain list
40
Figura 7: Listando os domínios
• Criar domínios:
Em uma nuvem OpenStack que possuem como clientes distintas organi-
zações, sendo tais organizações grandes e complexas, ter domínios sepa-
rados para cada organização pode ser benéfico. Por padrão, o OpenStack
possui um domínio padrão chamado Default.
A sintaxe de criação de um domínio é:
openstack domain create --description <description> <name>
O parâmetro desc ription é opcional, mas altamente recomendável. O
nome do domínio é único no ambiente.
Figura 8: Criação de um domínio
• Excluir domínios:
Um domíno apenas pode ser removido caso não existam usuários associ-
ados ao mesmo. Portanto, os passos a serem executados consistem em:
1. Listar usuários no domínio a ser removido:
openstack user list --domain <name>
Caso exista algum usuário associado ao domínio, será necessário re-
mover o mesmo antes da exclusão do domínio.
41
2. Desabilitar o domínio:
openstack domain set --disable <name>
3. Remover o domínio:
openstack domain delete <name>
5.1.1.2. Projetos
• Listar projetos:
openstack project list
• Criar projeto:
openstack project create --domain <domain> --description <description> <name>
O parâmetro domain é opcional. Caso omitido, o projeto será criado no
domínio Default. O parâmetro description também é opcional, mas alta-
mente recomendado. O nome do projeto precisa ser único no domínio.
• Remover projeto:
Os projetos podem ser removidos mesmo se existirem usuários e recur-
sos (volumes, VMs) associados ao mesmo. É recomendado que sejam
removidos os usuários e outros recursos contidos no projeto antes de
removê-lo, uma vez que existe o risco de usuários e recursos ficarem or-
fãos.
Caso um projeto seja removido sem serem removidos os recursos aloca-
dos dentro do mesmo, tais recursos não serão limpos automaticamente,
necessitando que o operador os busque e limpe manualmente. Além
disso, um projeto removido é completamente removido do banco de da-
dos, o que torna muito difícil rastrear quais recursos orfãos pertencem a
tal projeto removido.
openstack project delete --domain <domain> <project-id|project-name>
42
5.1.1.3. Roles
• Listar roles:
openstack role list --domain <domain-name>
• Criar role:
openstack role create --domain <domain_name> --project <project-name|project-id> <role_name>
• Listar roles associadas à um domínio:
openstack role list --domain <domain-name>
• Remover role:
openstack role delete --domain <domain> <role-name|role-id>
5.1.1.4. Usuários
• Listar usuários:
openstack user list [--domain <domain>] [--group <group> | --project <project>]
• Criar usuário:
Para criar um usuário, é necessário que tal usuário pertença à um domínio
ou projeto, além de precisar que o mesmo tenha uma role. Os passos
necessários são:
1. Criar usuário:
openstack user create [--domain <domain>] [--project <project>] --password <password> <
username>
2. Associar role ao usuário:
openstack role add [--domain <domain>] [--project <project>] --user <username> <role>
3. Listar usuários e suas roles:
openstack role assignment list
• Remover usuário:
openstack role delete [--domain <domain>] <role>
43
5.1.1.5. Grupos
• Listar grupos:
openstack group list [--domain <domain>] [--user <user>]
• Criar grupo:
Para criar um grupo, os passos necessários são:
1. Criar um novo grupo:
openstack group create [--domain <domain>] [--description <description>] <group-name>
2. Adicionar role ao grupo:
openstack role add --group <group> [--domain <d omain>] <role>
3. Adicionar usuários ao grupo:
openstack group add user --group-domain <domain> --user-domain <domain> <group> <username>
4. Verificar se o usuário pertence ao grupo:
openstack group contains user <group> <username>
Opcional Remover usuário do grupo:
openstack group remove user <group> <username>
• Remover grupo:
openstack group delete [--domain <domain>] <group-name>
5.1.1.6. Endpoints
Para listar todos os endpoints registrados no Keystone, o comando necessário
é:
openstack catalog list
44
Figura 9: Dashboard do Horizon
46
Algumas das funcionalidades do Horizon são:
• Interface unificada: o Horizon oferece a possibilidade de gerenciar os
componentes do OpenStack através de um único dashboard. Entretanto,
muitas APIs e funções somente estão disponíveis via CLI ou chamadas
HTTP direto. O Horizon cobre somente fluxos básico do ambiente de nu-
vem.
• Gerenciamento de computação: permite aos usuários provisionar, geren-
ciar e monitorar VMs através do dashboard, incluindo realizar o deploy de
instâncias, anexar volumes, gerenciar security groups, entre outros.
• Gerenciamento de armazenamento: permite aos usuários gerenciar di-
versos recursos de armazenamento, incluindo armazenamento em blo-
cos (volumes), em objetos (Swift) e arquivos.
• Rede: usuários podem criar e gerenciar redes, routers, subredes e security
groups.
• Identidade: por possuir integração com o Keystone, é possível que os ad-
ministradores configurem papeis de usuários, projetos e permissões.
A interface gráfica possui, geralmente, a seguinte composição:
• Aba Project: Representada pela Figura 10, permite visualizar e gerenciar
recursos de determinado projeto. É subdividido nas seguintes abas:
47
Figura 10: Aba de Projeto
– Compute: Permite visualizar e gerenciar os recursos de computação
do projeto. Subdividido nas seguintes abas:
48
Figura 11: Aba de computação
*
Overview: exibe estatísticas do projeto;
*
Instances: exibe e permite o gerenciamento de VMs;
*
Images: exibe e permite o gerenciamento de imagens e snapshots;
*
Key Pairs: exibe e permite o gerenciamento de pares de chaves;
*
Server Groups: exibe e permite o gerenciamento de server groups;
– Volumes: Representada pela Figura 12, permite visualizar e geren-
ciar recursos de armazenamento do projeto.
49
Figura 15: Aba de administração
• Identity: Representada pela Figura 16, permite visualizar e gerenciar pro-
jetos, usuários, grupos e papeis.
Figura 16: Aba de identidade
5.3. Nova
O serviço Nova realiza a gestão de recursos de computação (VMs) escaláveis
sob demanda. Tal serviço foi construído sobre uma arquitetura compartilhada
baseada em mensageria. Os componentes do serviço podem ser executados
53
em hosts distintos, sendo a comunicação entre os mesmos realizada via uma
fila de mensageria acessível para todos os componentes.
Para que o Nova funcione é necessário que outros serviços do OpenStack
estejam presentes, sendo os mesmos:
• Keystone, vide Seção 5.1;
• Glance, vide Seção 5.6;
• Neutron, vide Seção ??;
• Placement, vide Seção 5.16.
Sendo algumas de suas principais características:
• Gerenciamento de VMs: todo o ciclo de vida das VMs é gerenciado pelo
Nova, incluindo a criação, migração, redimensionamento, suspensão/re-
sumo e remoção da VM.
• Escalável: o Nova foi desenvolvido para escalar horizontalmente, supor-
tando escalonamento dinâmico de recursos.
5.3.1. Componentes
Os principais componentes do Nova, representados na Figura 17, são:
• DB
6
: banco de dados SQL para armazenamento de dados. Usado por to-
dos os componentes;
• API: componente que recebe solicitações HTTP, converte comandos e se
comunica com outros componentes através da fila de mensageria ou HTTP;
• Scheduler: decide qual host recebe qual VM em momento de redimensio-
namento ou criação;
6
Normalmente é uma instância compartilhada com outros componentes do OpenStack,
onde cada serviço possui um schema e usuário de acesso isolados.
54
• Compute: gerencia a comunicação entre VMs e o virtualizador;
• Conductor: gerencia solicitações que precisam de coordenação (constru-
ção/redimensionamento), atua como proxy de banco de dados ou lida
com conversões de objetos e implementa operações de longa duração
complexas, garantindo o andamento das mesmas e o tratamento de er-
ros.
• Placement: responsável por rastrear inventários e usos de recursos.
• Fila de mensagem: a comunicação entre os componentes internos do
Nova se dá através de um sistema de mensageria acessível por todos os
componentes
7
. Esse sistema de fila de mensagens é usado para coorde-
nar tarefas, passar informações, entre outros.
• Nós de computação: são servidores físicos ou virtuais onde as VMs ficam.
Cada nó roda um virtualizador que seja suportado pelo Nova.
7
Como RabbitMQ ou ZeroMQ
55
Figura 17: Arquitetura Nova
Obtido de link
5.3.2. Fluxo de execução
O fluxo de execução do Nova, resumidamente, consiste em:
1. Recebimento de requisição:
Usuários ou outros serviços do OpenStack enviam requisições para a API
do Nova, especificando qual é a ação desejada. A API recebe tal requisi-
ção, realiza a autenticação do usuário, validação dos inputs enviados, e
checagens de autorização de tal usuário ou serviço.
2. Agendamento:
56
Caso a operação a ser realizada seja de criação ou migração de VMs, a API
delega tal tarefa para o Scheduler, sendo que o mesmo verifica diversos
detalhes da infraestrutura do projeto, como recursos disponíveis e cotas,
para encontrar um host no qual tal VM possa ser alocada.
3. Alocação de Recursos:
Uma vez que o host tenha sido escolhido, o componente Conductor inte-
rage com tal nó para alocar os recursos necessários para a VM.
4. Gerenciamento da VM:
O componente Compute passa a gerenciar o ciclo de vida da VM, incluindo
o boot inicial, pausa/resumo, e destruição da VM. Ele interage com o vir-
tualizador no nó de computação para realizar isso.
5. Atualização do banco de dados:
Durante todo esse processo, o banco de dados é atualizado para refletir o
que está sendo feito, como o estado dos recursos da nuvem, para garantir
consistência dos recursos e a informação dos detalhes da infraestrutura.
6. Comunicação via fila:
Os componetes internos do Nova conversam entre si através de uma fila
de mensagens durante todo o processo, de forma a coordenar as tarefas.
5.3.3. Virtualizadores
Atualmente, o serviço Nova suporta os seguintes virtualizadores:
• Baremetal;
• KVM;
• LXC;
• VMware via vCenter;
• zVM.
57
5.4. Neutron
Neutron é um projeto OpenStack para fornecer NaaS
8
, permitindo aos usuá-
rios criar, remover e gerenciar redes, subredes, routers e outros recursos de
rede em uma infraestrutura OpenStack.
A arquitetura recomendada, representada pela Figura ??, para utilização do
Neutron exige um nó de controle, um nó de rede, e pelo menos um nó de com-
putação. O nó de controle contém uma interface de rede na rede de gestão
9
e
na rede responsável por receber as requisições da API. O nó de rede contém
uma interface de rede na rede gestão, uma na rede de túneis de instâncias
10
e
um na rede externa. O nó de computação contém uma interface de rede Gue
st e outra na rede de gestão.
8
Network as a Service.
9
Nesse caso, a rede Management.
10
Nesse caso, a rede Guest.
58
Figura 18: Obtido de link
.
fig:net-rec
Essa arquitetura de redes, por mais que não seja obrigatória, é recomen-
dada, uma vez que a mesma melhora a segurança da infraestrutura e facilita
despender o recurso de rede pra onde realmente necessita. Além disso, outra
rede que pode existir é a de storage, caso seja utilizado um SDS
11
.
5.4.1. Componentes
Os componentes internos, apresentado na Figura 19, do Neutron são:
• Neutron Server: componente que recebe solicitações HTTP, converte co-
11
Software Defined Storage.
59
mandos e se comunica com outros componentes através da fila de men-
sageria ou HTTP.
• Neutron Plugin Agents: rodam nos nós de computação e de rede, re-
presentam plugins que interagem com os drivers responsáveis por imple-
mentar tecnologias de rede específicas. A comunicação entre os plugins
é feita via fila de mensagens, e depende de qual tipo de plugin está ins-
talado. Os agentes incluem o agente L3 (para o gerenciamento do layer
3 de rede), agente DHCP, além de outros agentes específicos, como load
balancing, VPN, entre outros.
• Fila de Mensagens: os componentes do Neutron se comunicam entre si
via fila de mensagens, de forma a coordenar tarefas.
• DB: é utilizado um banco de dados relacional para armazenar a topologia
de rede.
60
Figura 19: Componentes do Neutron
Obtido de link
5.4.2. Workflow
O fluxo de execução do Neutron, resumidamente, consiste em:
1. Recebimento da requisição: os usuários ou uma ferramenta de orques-
tração enviam a requisição para o Neutron Server. O mesmo verifica se o
token é válidado no KeyStone para dar procedimento à requisição.
2. Criação da rede: o Neutron Server envia a requisição para o plugin apro-
priado. Tal plugin então aloca os recursos de rede, como VLANs, subredes,
endereços IP, e atualiza o banco de dados sobre a nova configuração de
rede;
61
3. Anexar portas
12
na VM: quando um usuário cria uma instância, o mesmo
especifica o tipo de conectividade que deseja para tal instância. O Neu-
tron então aloca portas para cada instância e associa as mesmas com as
redes e subredes apropriadas. Em seguida, os agentes do Neutron no nó
de computação configuram as interfaces virtuais na instância para que a
mesma se comunique com a rede.
4. Roteamento de rede: o agente L3 do Neutron lida com o roteamento
entre diferentes redes e subredes na nuvem. Ao criar routers e definir
políticas de roteamento, é esse agente que configura as tabelas de rote-
amento e gerencia o tráfego entre as redes.
5. Serviço DHCP: o agente DHCP do Neutron provê às instâncias a atribuição
de endereços IP e parâmetros de rede.
6. Security Groups e Firewall : através da API do Neutron, é possível definir
security groups e regras de firewall para controlar o tráfego de rede da
instância.
5.5. Cinder
Provê um serviço de gestão do armazenamento de blocos. Ele é utilizado
para gerenciar armazenamento persistente para instâncias de máquinas virtu-
ais, ou seja, esse tipo de armazenamento permanece mesmo após a remoção
de uma máquina virtual
13
. Um bloco pode estar montado em uma máquina
por vez, porém com a flexibilidade de ser desmontado e montado em outra.
5.5.1. Componentes
Os elementos que compõem o serviço Cinder, representados na Figura 20,
são:
• DB: banco de dados relacional utilizado por todos os componentes para
armazenar metadados dos volumes, snapshots e backups. Serve como
12
Consiste em uma interface de rede na VM, podendo ser conhecida como VNET, NIC e/ou
outras expressões.
13
Caso o volume não seja destruído com a remoção da VM.
62
ponto central de consulta de configurações e dados, garantindo consis-
tência e confiabilidade.
• Cinder API: componente que recebe solicitações HTTP, converte coman-
dos e se comunica com outros componentes através da fila de mensage-
ria.
• Cinder Scheduler: seleciona e utiliza recursos de armazenamento para
atender as solicitações de criação de volumes. Verifica fatores como dis-
ponibilidade, capacidade e performance para escolher o melhor lugar
para alocar o volume e ter uma melhor utilização possível dos recursos.
• Cinder Volume: gerencia o ciclo de vida dos volumes, incluindo a cria-
ção, remoção, operações de snapshot e clonagem. Interage com os dri-
vers backend de armazenamento para provisionar e gerenciar os volumes,
abstraindo a infraestrutura de armazenamento dos usuários.
• Cinder Backup: provê a funcionalidade de backup e restauração de volu-
mes. Permite aos usuários armazenar os backups em um repositório de
backup específico. Possuí integração com várias soluções de backup.
• Fila de Mensagem: os componentes internos do Cinder se comunicam
entre si através de uma fila de mensagens, a qual é usada para sincronizar
tarefas e sincronizar as mudanças de estado que ocorrem.
63
Figura 20: Arquitetura do Cinder
Obtido de link
5.5.2. Fluxo de execução
O fluxo de execução do Cinder pode ser resumido a:
1. Requisição de operação: o usuário realiza uma requisição para o Cinder
API. A requisição inclui informações da operação a ser realizada, tamanho
de volume, tipo de volume, entre outros. Como todas as requisições, essa
também é validada via Keystone.
2. Uso do Scheduler: uma vez que o Cinder API recebeu e autenticou a
requisição, a mesma é redirecionada ao Cinder Scheduler. O Scheduler
verifica os backends disponíveis com base em certos critérios, como ca-
pacidade, desempenho, entre outros, para selecionar o storage que irá
armazenar o volume.
3. Provisionamento do volume: uma vez que o backend tenha sido esco-
lhido, a API do Cinder irá solicitar ao Cinder Volume que interaja com o
backend escolhido para realizar a criação, junto ao backend, do volume.
4. Anexação do volume: uma vez que o volume seja corretamente criado,
o Cinder Volume o maneja de forma a permitir a anexação do mesmo em
instâncias, se comunicando com o nó de computação onde a instância se
encontra para iniciar o processo de anexação e permitir acesso à nível de
bloco entre a instância e o volume.
64
5. Uso: com o volume corretamente usado na instância, é possível utilizá-lo.
6. Desanexar e destruir: quando o volume não é mais necessário, o mesmo
pode ser desanexado da instância e, posteriormente, removido.
5.6. Glance
O serviço Glance provê armazenamento de imagens de máquinas virtuais.
Permite perquisar, registrar, obter e remover imagens de VMs, assim como
outras formas de discos e imagens de containers. Tais imagens são utilizadas
para criar VMs na nuvem OpenStack.
5.6.1. Componentes
Os componentes que compõem o serviço Glance, vide Figura 21, podem ser
resumidos a:
• Cliente: qualquer aplicação que use o Glance.
• API Rest: componente que recebe solicitações HTTP, converte comandos
e se comunica com outros componentes.
• Glance Domain Controller: middleware que implementa as funções de
autorização, notificações e conexões com o banco de dados.
• DB: banco de dados
• Database Abstraction Layer: API que unifica a comunicação entre o
Glance e o banco de dados.
• Glance Store: organiza as interações entre o Glance e os vários sistemas
de armazenamento suportados.
• Glance Registry: armazena metadados e informações sobre as imagens,
como nomes, IDs, propriedades e localização. Serve de repositório central
sobre os metadados das imagens.
65
Figura 21: Arquitetura do Glance
Obtido de link
5.6.2. Fluxo de execução
O fluxo de execução pode ser resumido a:
1. Busca de imagem: o usuário solicita a API do Glance a lista disponível de
imagens.
2. Registro de imagem: o usuário solicita a API do Glance para registrar uma
imagem. Durante tal processo, o usuário precisa informar alguns meta-
dados da imagem, como nome, descrição, formato do disco, entre outros.
Com essas informações, o Glance API armazena os metadados da imagem
no Glance Registry e a imagem em si no backend configurado no Glance
Store.
3. Obtenção da imagem: uma vez que existam imagens registradas e aces-
síveis ao usuário, a API do Glance retorna uma lista das imagens, com os
metadados da mesma e uma URL ou localização para que o usuário faça
o download da imagem.
66
4. Manipulação de imagem: o usuário pode, via API do Glance, alterar os
metadados da imagem, remover a imagem ou criar snapshots de deter-
minada imagem.
5. Permissões e compartilhamento das imagens: é possível compartilhar
as imagens com outros usuários no ambiente de nuvem OpenStack. Os
usuários podem especificar o acesso e as permissões de terminada ima-
gem, como quem pode a visualizar, realizar o download ou usar tal ima-
gem para iniciar instâncias.
5.7. Ceilometer
Serviço de telemetria do OpenStack, permite a coleta de estatísticas de di-
ferentes componentes do OpenStack. Os dados provenientes desse serviço
podem ser usados para bilhetagem
14
, auditoria, análise e planejamento da ca-
pacidade da nuvem.
É importante ressaltar que o objetivo do Ceilometer é somente de realizar
medições e um pré-processamento dos dados, sendo que tais dados devem ser
processados e analisados por outros componentes para se mostrarem úteis.
Cada um dos sub componentes do Ceilometer são criados com a intenção
de serem escalados horizontalmente, podendo ser acrescentados workers e
nós conforme a necessidade.
5.7.1. Glossário de termos
• Resource: pode ser qualquer recurso lógico ou físico do OpenStack que
está sendo metrificada, como instâncias, volumes, entre outros.
• Meters: representa uma métrica rastreada para um recurso. Tal métrica
consiste na conversão de um recurso específico para um valor legível para
humanos, como a utilização de CPU por instância. Os meters são definidos
14
Aqui é importante ressaltar que o Ceilometer, em si mesmo, não provê nenhuma infor-
mação de bilhetagem. O mesmo apenas coleta os dados, que devem ser posteriormente con-
sumidos por um serviço de bilhetagem.
67
como strings que possuem uma unidade de medida e podem ser catego-
rizados em três tipos:
1. Cumulative: o valor é incrementado com o tempo;
2. Gauge: o valor só é atualizado quando ocorre uma alteração no mesmo
ou no tempo de coleta do mesmo;
3. Delta: após um determinado período de tempo, o valor é atualizado.
• Samples: consiste no dado em sí (meter) junto com metadados, como
unidade de medida, horário da coleta, entre outros.
• Archive policy: define como é realizada a agregação das métricas, e por
quanto tempo as mesmas são armazenadas. É formalmente definida
como o número de pontos durante um intervalo de tempo.
Por exemplo, se uma archive policy define uma política de 10 pontos com
uma granularidade de 1 segundo, os dados são armazenados em até 10
segundos, cada um representando a agregação de 1 segundo. Isso sig-
nifica que são armazenados, no máximo, 10 segundos de dados entre a
métrica mais recente e a mais antiga.
A archive policy também define o método de agregação, sendo os méto-
dos padrões: mean, min, max. sum, std e count.
Aqui é importante detalhar que esse componente é referente ao backend
utilizado, neste caso o Gnocchi, detalhado na Seção 5.8.
• Retention: define quanto tempo os dados coletados serão mantidos.
Esse valor é definido no backend utilizado, neste caso o Gnocchi, deta-
lhado na Seção 5.8.
5.7.2. Arquitetura
A arquitetura do Ceilometer pode ser classificada em três categorias:
68
• Ceilometer compute: executa nos nós de computação e tem como fun-
ção coletar as estatísticas dos recursos ao realizar chamadas diretamente
ao virtualizador.
• Ceilometer central: executa no control plane, responsável por coletar
estatísticas de recursos que são independentes das instâncias e dos nós
de computação.
• Ceilometer notification: rodam no control plane, sendo responsáveis
por consumir mensagens de uma fila de mensageria e as tranformar em
métricas que, em seguida, serão publicadas em outro serviço, seja um
próprio do OpenStack ou externo.
A Figura 22 representa a arquitetura e fluxo geral de execução do Ceilome-
ter, a saber:
• Os demais serviços do OpenStack podem publicar dados na fila de men-
sageria que é consumida pelo componente ceilometer notification;
• Os agentes do componente ceilometer compute realizam requisições
diretamente ao virtualizador, para obter os dados. Após obtenção de tais
dados, os mesmos são publicados na fila de mensageria que é consumida
pelo componente ceilometer notification;
• Os agentes do componente ceilometer central realizam requisições para
APIs, seja de serviços do OpenStack, ou de serviços de terceiros, para ob-
ter os dados. Após obtenção de tais dados, os mesmos são publicados na
fila de mensageria que é consumida pelo componente ceilometer noti-
fication;
• Os agentes do componente ceilometer notification obtém os dados da
fila de mensageria, realizam o pré-processamento dos mesmos, e, por
69
fim, os enviam para um serviço de armazenamento externo ao Ceilome-
ter
15
.
De forma geral, a coleta de dados é realizada periodicamente, onde cada
um dos agentes do Ceilometer
16
obtém os dados brutos, o ceilometer notifi-
cation os normaliza/transforma, e os publica em algum sistema de armazena-
mento externo ao Ceilometer. As Figuras 23, 24 e 25 representam o processa-
mento de dados executado pelo Ceilometer.
Figura 22: Arquitetura geral do Ceilometer
Figura 23: Processamento dos dados executado pelo Ceilometer notification
15
Caso tenha sido configurado para o fazer. Do contrário, os dados processados apenas são
descartados.
16
Ceilomenter compute, Ceilomenter central e Ceilomenter notification.
70
Figura 24: Processamento dos dados executado pelo Ceilometer central
Figura 25: Processamento dos dados executado pelo Ceilometer compute
No processamento do pipeline do ceilometer notification, alguns dos trans-
formers que podem ser aplicados são:
• Accumulator: acumula vários valores e os envia em lote.
• Aggregator: acumula vários em apenas um.
• Arithmetic: inclui funções aritméticas para calcular a porcentagem.
• Rate of change: identifica tendências derivando outro medidor dos da-
dos anteriores.
• Unit conversion: converte o tipo da unidade.
Uma vez que o dado tenha sido manipulado e transformado, o mesmo é
publicado através de uma das opções disponíveis:
• gnocchi: opção recomendada, utiliza a API do Gnocchi para publicar os
samples.
• notifier: publica os samples em uma fila, para que os mesmos sejam con-
sumidos por um sistema externo.
71
• udp: publica samples usando pacotes UDP.
• http: publica samples via uma interface REST.
• file: publica samples para um arquivo com determinado nome e localiza-
ção.
• zaqar: serviço de notificação.
• https: publica samples via HTTPS.
• prometheus: publica samples para o Prometheus.
5.7.3. Pollsters dinâmicos
Uma das funcionalidades principais do Ceilometer é o de configurar de forma
dinâmica a coleta de métricas. Para tal, são utilizados arquivos YAML que es-
pecificam quais APIs devem ser consultadas para obter os dados, assim como
quais dados devem ser obtidos e processados. Tal sistema, devido ao fato de
ser extremamente dinâmico, permite também coletar métricas de serviços fora
do OpenStack, permitindo versatilidade na coleta de métricas.
Para realizar essa coleta, o Ceilometer lê os arquivos YAML que ficam no di-
retório definido pelo parâmetro pollsters_definitions_dirs
17
. Tais arquivos defi-
nem quais APIs serão consultadas, assim como quais dados devem ser obtidos
na resposta de tal API.
Alguns dos parâmetros que podem ser adicionados em tais arquivos são:
• name: parâmetro obrigatório. Especifica o nome do pollster.
• sample_type: parâmetro obrigatório. Especifica o tipo do dado, podendo
ter os valores: gauge, delta ou cumulative.
• unit: parâmetro obrigatório. Especifica a unidade da métrica coletada.
17
O valor padrão é /etc/ceilometer/pollsters.d.
72
• value_attribute: parâmetro obrigatório. Especifica que atributo na res-
posta a chamada a API deve ser processado.
• endpoint_type: parâmetro obrigatório. Especifica qual o tipo de endpoint
que será chamado. Para determinar seu valor, deve-se verificar qual o
serviço OpenStack que está sendo chamada e seu tipo.
• url_path: parâmetro obrigatório. Determina a URL que será consultada
para obter os dados.
• metadata_fields: parâmetro opcional. Lista todos os campos que se de-
seja ter na resposta a chamada a API.
Para uma lista completa de todos os parâmetros possíveis de serem utiliza-
dos, pode-se consultar a documentação oficial. Abaixo segue um exemplo de
arquivo de configuração:
---
- name: "dynamic.network.services.vpn.connection"
sample_type: "gauge"
unit: "ipsec_site_connection"
value_attribute: "status"
endpoint_type: "network"
url_path: "v2.0/vpn/ipsec-site-connections"
metadata_fields:
- "name"
- "vpnservice_id"
- "description"
- "status"
- "peer_address"
5.8. Gnocchi
Gnocchi é um banco de dados de séries temporais, que visa resolver o pro-
blema de armazenar e indexar séries temporais e recursos em larga escala.
O Gnocchi foi projetado para lidar com grandes quantidades de dados arma-
zenados, ao mesmo tempo que tem desempenho, é escalonável e tolerante a
falhas. Ao fazer isso, o objetivo era ter certeza de não criar nenhuma depen-
dência rígida em nenhum sistema de armazenamento complexo.
73
Para o armazenamento de séries temporais, a abordagem utilizada, ao in-
vés de armazenar pontos de dados brutos, ele os agrega antes de armazená-
los. Esse recurso integrado é diferente da maioria dos outros bancos de dados
de série temporal, que geralmente suportam esse mecanismo como uma op-
ção e computam agregação (média, mínimo, etc.) no momento da consulta.
Como o Gnocchi calcula todas as agregações na ingestão, a recuperação dos
dados é extremamente rápida, pois basta ler os resultados pré-computados.
Apesar de o Gnocchi ter iniciado como um possível backend para o Ceilome-
ter, com o tempo, o mesmo se tornou a API padrão para armazenamento dos
dados de telemetria. Apesar de o mesmo não fazer mais parte do OpenStack
oficialmente, o mesmo permanece essencialmente como API para telemetria.
O Gnocchi foi retirado do OpenStack devido ao fato do projeto ter ficado
parado, com pull requests deixados sem nenhum review, CI quebrado, e até
mesmo o domínio da documentação foi abandonado. De forma geral, o projeto
ficou um tempo como fora de manutenção.
Além disso, os desenvolvedores do Gnocchi parecem pouco inclinados a
interagir com a comunidade OpenStack ou a transferir o projeto de volta para
a infraestrutura/governança da OpenInfra, apesar do OpenStack parecer ser o
único consumidor do Gnocchi como projeto.
5.8.1. Arquitetura
A arquitetura do Gnocchi, apresentada na Figura 26, é dividida em dois prin-
cipais componentes:
• gnocchi-api: API, por meio da qual os dados (que são inseridos manual-
mente ou coletados de programas como o Ceilometer) são salvos e atua-
lizados, bem como da qual os dados agregados são recebidos.
• gnocchi-metricd: um daemon que processa dados recebidos recente-
mente e ainda não transformados e os salva em armazenamento definido
74
pelo usuário (Ceph, Redis, OpenStack Swift ou em um sistema de arquivos
local) no formato adequado.
Figura 26: Arquitetura geral do Gnocchi
O Gnocchi utiliza diferentes tipos de armazenamento. Os sistemas de ar-
mazenamento suportados para o incoming storage e persistent storage são:
• Local folder (chamado de file)
18
;
• Ceph
19
;
• OpenStack Swift;
• Amazon S3;
• Redis.
18
Armazenamento padrão.
19
Opção recomendada pela comunidade do Ceph.
75
A equipe da SC Clouds recomenda que, para o incoming storage
20
, seja uti-
lizada uma solução mais leve e rápida, como o Redis
21
, enquanto que, para o
storage permanente, seja utilizada uma solução mais robusta, confiável e esca-
lável, como o Ceph.
Existe também o Index, responsável por armazenar o índice de todos os re-
cursos, políticas de arquivo e métricas, juntamente com suas definições, tipos
e propriedades. O mesmo também é responsável por vincular os recursos às
métricas e aos relacionamentos dos recursos. Consiste em um banco de dados
relacional, sendo as soluções suportadas:
• PostgreSQL
22
;
• MySQL
23
.
5.8.2. Terminologia
• Metric: uma entidade que armazena dados agregados. Consiste em:
– name: como cpu;
– unit: unidade de medida da métrica;
– resource id: o ID do resource associado a tal métrica.
• Measure: consiste em uma tupla de datapoint enviada a API do Gnocchi.
No contexto do OpenStack, é o resultado final do processamento do Cei-
lometer. Quando o Gnocchi recebe uma measure, ele as correlaciona com
resources e metrics.
• Resource: uma entidade que representa alguma coisa na infraestrutura
que será associada com a métrica. Pode ser uma VM, o volume de uma
VM, uma rede, etc.
20
O qual abriga os dados não processados.
21
Ou Ceph, caso o Ceph já esteja em uso como backend para armazenamento persistente.
22
Opção recomendada.
23
A partir da versão 5.6.4
76
5.8.3. Archive policies
O Gnocchi não armazena permanentemente os dados brutos que recebe.
Para reduzir o volume de dados, são armazenados valores em determinados
intervalos de tempo. A duração desse intervalo de tempo é chamada de gra-
nularidade.
Os valores armazenados são agregações como, por exemplo, a média do
uso de CPU de uma VM a cada 10 minutos. Outras agregações são possíveis,
como o uso do valor máximo, mínimo, etc.
O uso de granularidade e métodos de agregação geram o que é chamado
de archive policy. Por exemplo:
$ gnocchi archive-policy show medium
+---------------------+-------------------------------------------+
| Field | Value |
+---------------------+-------------------------------------------+
| aggregation_methods | std, count, min, max, sum, mean |
| back_window | 0 |
| definition | - points: 10080, granularity: 0:01:00, |
| | timespan: 7 days, 0:00:00 |
| | - points: 8760, granularity: 1:00:00, |
| | timespan: 365 days, 0:00:00 |
| name | medium |
+---------------------+-------------------------------------------+
Neste exemplo de archive policy, os dados são armazenados a cada minuto
24
e a cada hora
25
. São mantidos 8760 horas de dados, ou seja, um ano inteiro, e
10080 dados por minuto (uma semana).
A cada intervalo, são armazenados diversas agregações, como o desvio pa-
drão (std), o número de measures durante o intervalo (count), o mínimo, má-
ximo, somatório e média.
De forma resumida, toda vez que o Ceilometer envia samples ao Gnocchi, o
Gnocchi processa tais samples, os associa com uma metric. Cada metric tem um
nome, unidade e é relacionada com uma archive policy e resource. Cada sample
é agregado de acordo com os métodos definidos no archive policy e o resultado
final é armazenado em um storage permanente.
24
Granularidade de 0:01:00.
25
1:00:00.
77
5.9. CloudKitty
Serviço de rating do OpenStack. O projeto almeja ser uma solução genérica
de cobrança
26
para nuvem OpenStack. O processo de rating consiste em atri-
buir um valor monetário, com base em regras lógicas, a uma alocação/uso de
recurso computacional da nuvem OpenStack. Deste modo, o CloudKitty vai até
esse ponto, possibilitando definição de valores a recursos consumidos e APIs
para obter relatórios. Entretanto, o processo de bilhetagem/cobrança consiste
em criar boletos, notas fiscais, e coordenar com gateways de pagamentos, e
essa parte está fora do dominio do OpenStack.
O CloudKitty é altamente modularizado em quatro níveis diferentes:
1. Fontes de entrada de dados (collectors): é possível configurar o CloudKitty
para que o mesmo consulte diferentes fontes de dados para obter medi-
das e metadados sobre métricas, de forma a ter insumos para realizar a
bilhetagem.
2. Políticas de cobrança (rating pipeline): é possível criar regras de bilheta-
gem altamente customizáveis.
3. Armazenamento dos dados processados (sto rage): é possível utilizar di-
ferentes sistemas de armazenamento para armazenar os dados proces-
sados.
4. Dados de relatórios (w riters): é possível especificar diferentes formatos
de arquivos para os relatórios criados pelo CloudKitty.
CloudKitty permite realizar rating baseados em métricas específicas e cus-
tomizáveis. Isso é realizado através de consultas a endpoints específicos para
obter medidas e metadados sobre métricas específicas. Após, são aplicadas
regras de precificação aos dados e, em seguida, os dados precificados são en-
viados a um armazenamento.
26
De modo geral, mas não é um sistema de bilhetagem completo.
78
5.9.1. Arquitetura
A arquitetura do CloudKitty possui dois componentes:
• cloudkitty -api: responsável por criar e ler as regras de bilhetagem, além
de ler os dados já processados.
• clou dkitty-proce ssor: responsável por obter os dados brutos, os proces-
sar de acordo com as regras de bilhetagem e os armazenar em um arma-
zenamento.
Esse componente é dividido nos seguintes processos:
– Orchestrator: coordena o processamento. Responsável por listar os
escopos disponíveis e ativos através do fetcher, obter as medidas dos
escopos através do collector, precificar os dados através dos módu-
los de cobrança, e salvar os dados processados no armazenamento
configurado.
– Fetcher: responsável por obter uma lista de escopos para serem
processados. Um escopo é utilizado para distinguir e isolar os da-
dos. Além disso, permite dividir a carga de trabalho entre diferentes
instâncias do cloudkitty-processor.
– Collector: obtém dados a partir de uma fonte para determinado es-
copo e métrica.
– Rating module(s): responsável por aplicar regras de bilhetagem para
os dados obtidos pelo collector. Tais regras são definidas pelo usuá-
rio. Por padrão, existem dois módulos disponíveis:
*
Hashmap: permite criar regras de bilhetagem baseadas nos me-
tadados das métricas.
*
pyscripts: permite utilizar scripts Python customizáveis para re-
alização da bilhetagem.
79
Uma vez que os dados tenham sido processados, os mesmos são salvos
em um armazenamento, e ficam disponíveis para consulta através do clo
udkitty-api.
Com relação ao fluxo de processamento do CloudKitty, representado pela
Figura 27, o processo começa com a inicialização/criação de workers/processors.
O número de workers/processors é definido através da opção max_workers; se
esta opção não estiver definida, o número utilizado será o número total de nú-
cleos disponíveis no sistema operacional onde o sistema está sendo executado.
Além disso, existe o número de threads utilizadas (opção max_threads), que
por padrão é cpu_count() * 5. Após a criação do worker, existe o seguinte fluxo
de trabalho (há outros detalhes, que não serão mencionados para facilitar a
explicação):
80