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
Figura 27: Fluxo de execução do CloudKitty
1. Carregar os escopos para processar:
Por padrão, os escopos processados pelo CloudKitty são project_ids. No
entanto, isso pode ser alterado para qualquer outro ID exclusivo que re-
presente um recurso ou grupo de recursos onde as métricas são encon-
tradas. Os escopos podem ser carregados do Gnocchi, Prometheus ou
Keystone. Por padrão, o CloudKitty usa o Keystone como fetcher, mas isso
força o usuário do CloudKitty no Keystone a ter uma função (permissão)
para os projetos dos quais se quer avaliar/monitorar/coletar dados. Ao
utilizar o fetcher Gnocchi, é possível gerenciar/classificar dados de outras
fontes de dados, e não apenas do OpenStack.
81
2. Para cada escopo encontrado com o fetcher, o CloudKitty executará a co-
leta e classificação de dados. A distribuição do trabalho é feita entre todos
os workers disponíveis (se houver mais de um). Workers diferentes nunca
processarão o mesmo escopo e período duas vezes.
3. Validar se o escopo deve ser processado verificando seu estado. Se estiver
desativado, não é gerado um marcador de data/hora para processar.
4. Se o escopo puder ser processado, é gerado o próximo momento a ser
processado. Caso seja um escopo que o CloudKitty já possui em seu
banco de dados, é verificado se existe um novo timestamp disponível para
processamento, e é gerado um timestamp com base na opção “período”
do CloudKitty, que por padrão é 1 hora (3600 segundos). Caso seja um es-
copo que o CloudKitty ainda não possui no banco de dados, o CloudKitty
iniciará seu processamento a partir da primeira hora do primeiro dia do
mês atual em que o processamento estiver ocorrendo. O CloudKitty está
sempre 2 * period atrasado durante o processamento. Isso significa que,
por padrão, sempre haverá 2 horas de atraso no processamento.
4.A se o escopo tiver um marcador de data/hora que precise de proces-
samento, o CloudKitty moverá para a coleção. O CloudKitty pode co-
letar dados do Gnocchi como métricas ou do Prometheus. A coleta
de dados seguirá o arquivo de configuração metrics.yml do Cloud-
Kitty, onde são descritos os atributos (groupby), juntamente com o
nome da métrica que deve ser coletada. O CloudKitty tentará cole-
tar todas as métricas definidas para todos os escopos que precisa
processar. Ainda não há como vincular métricas a escopos.
4.B se o escopo não tiver um próximo marcador de data/hora, o worker
tentará processar/avaliar o próximo da lista.
5. Após a coleta, o CloudKitty executará o processo de precificação sobre
os dados coletados. As regras de precficação podem manipular os valo-
82
res coletados e usar atributos para atribuir preços diferentes para uso de
recursos.
6. Os dados avaliados/processados são mantidos no backend de armazena-
mento. O backend de armazenamento V1 está obsoleto e não deve ser
usado. Possui apenas uma implementação, que é o MySQL. O V2 atual é
o método padrão suportado e oferece suporte a InfluxDB, OpenSearch e
ElasticSearch.
7. Depois que os dados são persistidos no InfluxDB, o CloudKitty atualiza os
dados em seu banco de dados MySQL.
8. Após atualizar o status
27
do escopo, o CloudKitty passa a gerar o próximo
marcador de data/hora para os escopos e prossegue em seu processa-
mento, até que não haja próximo prazo a ser processado para o escopo
determinado.
5.10. Mistral
Serviço que permite automatizar processos de fluxo de trabalho. Particular-
mente pode ser usado para solucionar tarefas administrativas que envolvam
gerenciar clusters de softwares, ou quaisquer outras tarefas que utilizam vários
componentes e demoram muito para serem concluídas. Além disso, o Mistral
também pode ser utilizado como um componente central para realizar o deploy
de softwares distribuídos em larga escala.
O Mistral permite que os usuários descrevam processos como um conjunto
de tarefas e etapas, e, após receber tal definição de fluxo de trabalho, o Mistral
ficará responsável por gerenciar o estado do processo, respeitar a ordem cor-
reta de execução, lidar com o paralelismo, sincronismo e alta disponibilidade.
O Mistral também permite alta flexibilidade no agendamento de tarefas.
Há de se mencionar que existe uma discussão, detalhada neste link para
remover o Mistral do OpenInfra. Assim, a equipe da SC Clouds recomenda
27
Último marcador de processamento.
83
ponderação ao utilizá-lo em um ambiente OpenStack produtivo, uma vez que
tal serviço pode ser removido futuramente.
5.10.1. Linguagem de fluxo de trabalho
O Mistral utiliza as linguagens YAQL e Jinja2 para descrever um fluxo de
trabalho. Possui como entidades principais:
• Workflows: entidade principal de um fluxo de trabalho do Mistral. Repre-
senta um processo que pode ser descrito de várias formas, e que é útil
ao usuário caso seja automatizado. Cada workflow é composto por tasks
(tarefas), sendo que um workflow está atrelado a pelo menos uma task.
Essas tarefas descrevem quais são os passos que devem ser executados
durante o fluxo de trabalho.
Um workflow pode ser de dois tipos possíveis, apresentados nas Figuras
28 e 29, sendo que tais tipos determinam qual será a lógica a ser execu-
tada durante o processo:
1. direct: é o tipo padrão, no qual as tasks são dependentes entre si, só
sendo executadas caso a anterior finalize com certo resultado. Dessa
forma, esse tipo apresenta a noção de transação entre as tasks.
84
Figura 28: Direct workflow
Obtido de link
2. reverse: nesse tipo é especificado uma task como alvo da operação,
e então o Mistral procura recursivamente quais são as demais tasks
que precisam ser executadas antes para “alcançar” a task alvo. Tasks
que não tem relação direta com a task alvo são ignoradas.
Figura 29: Reverse workflow
Obtido de link
Os atributos mais comuns a existirem em um workflow são:
Opcional type: o tipo do workflow. Pode ser direct ou reverse.
85
Opcional description: texto da descrição do workflow.
Opcional input: uma lista de nomes dos parâmetros de entrada requeridos.
Opcional output: qualquer estrutura de dados contendo expressões YAQL/-
Jinja2 que irão armazenar a saída do workflow.
Opcional output-on-error: qualquer estrutura de dados contendo expressões
YAQL/Jinja2 que irão armazenar a saída do workflow em caso de erro.
Opcional task-defaults: representa ações a serem tomadas durante o work-
flow caso alguma condição de alguma task seja atingida. As condi-
ções possíveis são:
direct workflow on-error: lista de tasks a serem executadas caso a anterior te-
nha finalizado com erro.
direct workflow on-success: lista de tasks a serem executadas caso a anterior
tenha finalizado com sucesso.
direct workflow on-complete: lista de tasks a serem executadas independente
de como a anterior foi concluída.
reverse workflow requires: lista de tasks que a presente depende.
Obrigatório tasks: dicionário contendo as tasks do workflow.
• Actions: consiste em uma instrução particular associada à uma task, que
será executada quando a task rodar.
• Tasks: define um passo computacional específico no workflow. Cada task
pode receber parâmetros opcionais de input e produzir um output. Além
disso, uma task pode ser associada a uma action ou a um workflow. Os
atributos mais comuns a existirem em tasks são:
– name: nome da task, não podendo ser igual a noop, fail, succeed ou
pause. Possuí tamanho máximo de 255 caracteres.
Opcional description: texto contendo a descrição da task.
86
– action: nome da action associada a esse task.
Opcional input: valores de input para a task.
Exemplo de sintaxe:
---
version: '2.0'
create_vm <workflow>:
description: Simple workflow example
input:
- vm_name
- image_ref
- flavor_ref
output:
vm_id: "{{ _.vm_id }}"
vm_status: <% $.vm_status %>
tasks:
create_server <task>:
action <action>: nova.servers_create name=<% $.vm_name %> image=<% $.image_ref %> flavor=<% $.
flavor_ref %>
publish:
vm_id: <% task().result.id %>
on-success:
- wait_for_instance
wait_for_instance <task>:
action <action>: nova.servers_find id={{ _.vm_id }} status='ACTIVE'
retry:
delay: 5
count: 15
publish:
vm_status: "{{ task().result.status }}"
5.10.2. Arquitetura
O Mistral possui, representada na Figura 30, os seguintes componentes:
• mistral-api: API REST que permite manipular e monitorar fluxos de tra-
balho.
• mistral-engine: obtém um fluxo de trabalho a ser executado através de
uma fila. Em seguida, o mesmo fica responsável por controlar e monitorar
a execução de tal fluxo de trabalho. Além disso, ele computa quais tasks
estão aptas a serem executadas, e as coloca na fila de tasks.
• mistral-executor: obtém tarefas da fila de tarefas e executa as ações das
mesmas. Em seguida, envia o resultado de volta para o mistral-engine.
87
• mistral-event-engine: responsável por ouvir notificações de eventos re-
cebidos do mistral-executor e acionar fluxos de trabalho definidos pelo
usuário.
Além disso, outros componentes utilizados pelo Mistral, embora não façam
parte do mesmo:
• Fila de fluxos de trabalho: uma fila de mensageria que contém os fluxos
de trabalho a serem executados.
• Fila de tarefas: uma fila de mensageria que contém as tarefas que preci-
sam ser executads.
• Banco de dados: um banco de dados relacional onde são armazenados
as definições de fluxo de trabalho, o estado da execução dos mesmos,
entre outros.
Figura 30: Arquitetura do Mistral
88
5.11. Magnum
O serviço Magnum provê Conteiner-as-a-Service, permitindo aos usuários
criar e gerenciar clusters de containers usando um mecanismo de orquestra-
ção de contêineres como o Docker Swarm e Kubernetes.
Ele provê uma abstração para realizar o deploy de grupos de contâineres em
uma infraestrutura OpenStack. Utiliza diversos outros serviços do OpenStack
para atingir esse fim, como o Nova, o Neutron e o Cinder/Glance.
5.11.1. Terminologia
• COE: acrônimo para Container Orchestration Engine, que permite o geren-
ciamento de contâineres. São exemplos de COE o Kubernetes e o Docker
Swarm.
• Cluster/Bay: conjunto de máquinas virtuais que hospedam os contâine-
res. Tais VMs são compostas por instâncias Nova, redes do Neutron, se-
curity groups e outros recursos combinados utilizando uma stack do Heat.
Aqui é onde o COE é executado. Pode ter seus recursos escalados, seja
os aumentando ou diminuindo, ao adicionar ou remover VMs do mesmo.
A Figura 31 representa um exemplo de clusters no Magnum.i
• ClusterModel/BayModel: template usado para criar clusters. Contém in-
formações que são comuns para todas as VMs de um cluster.
• Cliente nativo: o cliente que é distribuido junto do COE. Por exemplo, o
docker ou o kubectl. Não é um cliente do OpenStack. Utiliza TLS para se
comunicar com o COE.
89
Figura 31: Clusters do Magnum
5.11.2. Arquitetura
O Magnum é composto de dois componentes, vide Figuras 32 e 33.
• magnum_api: permite aos usuários interagir com o serviço do Magnum.
Os usuários podem criar, remover, escalar e gerenciar os clusters via API.
Uma vez que a API tenha recebido as requisições dos clientes, a mesma
as envia ao magnum_conductor via fila de mensageria.
• magnum_conductor: recebe as requisições dos usuários através de uma
fila, as valida e coordena a execução das mesmas, incluindo o agenda-
mento de tarefas e a interação com outros serviços do OpenStack. Inte-
rage com o banco de dados para armazenar e recuperar as informações
dos clusters, seus estados, assim como informações sobre os usuários.
Também monitora a saúde, estado e performance dos clusters, garan-
tindo disponibilidade e escalabilidade.
90
Figura 32: Arquitetura do Magnum
Obtido de link
Figura 33: Overview da arquitetura geral do Magnum
5.12. Octavia
Serviço de load balancing do OpenStack
28
. Para entregar o serviço de balan-
ceamento de carga, são usadas máquinas virtuais, contêineres ou servidores
bare metal, que são criados/ativados sob demanda, sem a necessidade de que
o operador realize o deploy ou configure o serviço de balanceamento de carga.
28
LBaaS, Load Balancing-as-a-Service.
91
5.12.1. Terminologia
• Load balancing: técnica que permite distribuir o tráfego de rede para
multiplos servidores, de forma a otimizar performance, permitir escala-
bilidade e alta disponibilidade. Através do correto gerenciamento das re-
quisições, é possível prevenir sobrecarga de servidores, reduzir o tempo
de resposta, e melhorar, de forma geral, a perfomance da aplicação.
• VIP: Virtual IP, representa o endereço IP associado à um load balancer.
• Amphora: pode representar uma VM, contêiner, hardware dedicado ou
dispositivo que irá performar como um load balancer.
5.12.2. Arquitetura
A arquitetura do Octavia, representada na Figura 35, é composta pelos se-
guintes componentes:
• octavia-api: expõe uma API Rest que permite aos usuários interagirem
com o Octavia. Recebe as requisições dos usuários, performa uma sani-
tização básica, e a envia, via fila de mensageria, para o octavia-worker.
• octavia-worker: responsável por executar a requisição enviada pelo usuá-
rio.
• octavia-housekeeping: gerencia a rotação dos certificados utilizados pe-
los amphora e remove registros expirados do banco de dados.
• octavia-health-manager: monitora o estado e a saúde de cada amphora,
garantindo que os mesmos estão executando corretamente. Além disso,
esse componente é responsável por lidar com eventos de falha nos amphora.
92
Figura 34: Arquitetura do Octavia
Por padrão, são criados dois load balancers, sendo um dos mesmos o pri-
mário e o segundo o backup, vide Figura 35. De tempos em tempos, o octavia-
health-manager checa a saúde desses dois load balancers e performa opera-
ções necessárias para garantir a disponibilidade do serviço, seja elegendo o
backup a primário, seja realizando o deploy de outro load balancer.
93
Figura 35: Funcionamento exemplificado do Octavia
5.12.3. Principais funcionalidades
• Algoritmos de balanceamento de carga: o Octavia suporta diversos al-
goritmos de balanceamento de carga, como o round-robin, source IP affi-
nity, least connections, entre outros. Com isso, os operadores podem de-
finir com mais precisão a forma que o tráfego terá, assim como otimizar
recursos.
• Checagem de saúde e failover automático: Octavia monitora continu-
amente a integridade dos servidores backend realizando verificações de
integridade. No caso de falha do servidor, o Octavia pode redirecionar au-
tomaticamente o tráfego para servidores íntegros, garantindo a entrega
ininterrupta do serviço e minimizando o tempo de inatividade.
• Terminação SSL/TLS: é possível utilizar terminação SSL/TLS, permitindo
94
a comunicação segura entre os clientes e os servidores. Ele alivia o pro-
cesso de criptografia e descriptografia dos servidores, reduzindo a carga
de processamento e melhorando o desempenho geral.
5.13. Barbican
Serviço de gerenciamento de secrets do OpenStack. Provê armazenamento
seguro, provisionamento e gerenciamento de dados sensíveis/secretos. Esses
dados incluem chaves simétricas e/ou assimétricas, certificados e dados biná-
rios.
5.13.1. Arquitetura
A arquitetura do Barbican, representada na Figura 36, é dividida nos com-
ponentes:
• barbican-worker: lê requisições da fila de mensageria e as processa.
• barbican-keystone-listener: escuta eventos da fila de mensageria do
Keystone. Usado para gerenciar a representação de projetos Keystone
no banco de dados Barbican quando os projetos são excluídos.
• barbican-api: provê uma API Rest para que os usuários possam interagir
com o serviço do Barbican. Envia requisições para uma fila, para que as
mesmas sejam processadas.
95
Figura 36: Arquitetura do Barbican
Obtido de link
5.14. Aodh
Serviço de alarme e notificação do OpenStack. Responsável por ativar alar-
mes baseados em regras customizáveis. Sua arquitetura é dividida em quatro
componentes, vide Figura 37:
• aodh-api: expõe uma API Rest que permite aos usuários acessarem/ma-
nipulares as informações sobre os alarmes.
• aodh-evaluator: responsável por disparar os alarmes quando certas es-
tatísticas cruzarem um limite específico durante determinado período de
tempo. Por exemplo, o uso total de RAM de uma VM variar em 500 MB
num intervalo de uma hora, um alarme é disparado.
96
• aodh-listener: responsável por disparar alarmes quando determinado
evento ocorre. Por exemplo, uma VM com 10 TB ou mais de RAM foi cri-
ada.
• aodh-notifier: responsável por disparar alarmes quando determinado
recurso atinge um limite. Por exemplo, caso o uso total de RAM da nuvem
chegue em 2TB, um alarme é disparado.
Figura 37: Arquitetura do Aodh
5.15. Heat
Serviço de orquestração de aplicações do OpenStack. Visa prover gerenci-
amento de aplicações e infraestruturas de nuvens OpenStack, através de uma
forma declarativa (em YAML), chamada de HOT
29
templates. O Heat realiza o
parse desses templates para, então, realizar chamadas a APIs de outros serviços
do OpenStack.
29
Heat Orchestration Template.
97
Tais templates permitem a criação da maioria dos tipos de recursos do Open-
Stack (como instâncias, IPs flutuantes, volumes, security groups e usuários), as-
sim como o uso de funcionalidades mais avançadas, como alta disponibilidade
e escalonamento automático de instâncias. Além disso, tais templates permi-
tem especificar a relação entre os recursos, por exemplo, o volume X está co-
nectado com a instância Y. Isso possibilita ao Heat chamar as APIs do Open-
Stack para criar sua infra-estrutura na ordem correta para lançar a aplicação
com sucesso.
Por fim, o Heat gerencia o ciclo de vida inteiro da aplicação. Quando hou-
ver necessidade de realizar mudanças na infra-estrutura, basta simplesmente
modificar o template e usá-lo para atualizar o ambiente. O fluxo de uso Heat é
apresentado na Figura 38. O Heat então se responsabiliza de realizar todas as
mudanças necessárias.
Figura 38: Uso do Heat
Obtido de link
5.15.1. Arquitetura
A arquitetura do Heat, apresentada na Figura 39, é dividida em:
98
• heat-api: expõe uma API Rest para que os usuários interajam com o sis-
tema Heat.
• heat-api-cfn: expõe uma API estilo a do AWS Query API, que é compativel
com o AWS CloudFormation.
• heat-engine: responsável por realizar a execução das requisições de or-
questração.
Figura 39: Arquitetura do Heat
5.15.2. Estrutura dos templates
Um template possuí quatro elementos chave:
Opcional Uma sessão de parâmetros, nomeada Parameters, que permite especifi-
car inputs de usuário.
Opcional Uma sessão de mapeamentos (Mappings), que permite a pesquisa de cha-
ve/valor de constantes predefinidas.
1. Uma sessão de recursos (Resources), que descreve os recursos e relacio-
namentos que definem a aplicação, configuração e infraestrutura.
Opcional Uma sessão de output, que descreve os valores de output que serão re-
tornados ao usuário.
99
Todos os recursos tem uma interface padrão composta de:
• Um número de propriedades opcionais ou obrigatórias que especificam
entradas que afetam como o recurso é configurado.
• Vários atributos de saída que podem ser referenciados em outras partes
do modelo.
Um recurso pode referenciar outros recursos, o que causa dependências
implícitas que serão criadas pelo modelo interno do Heat. Tais dependências
são usadas para ordenar o controle de execução das operações. Dependências
explicítas também podem ser usadas.
Por fim, existem funções disponíveis que permitem uma manipulação limi-
tada dos dados de um template. Abaixo segue um exemplo de template que cria
uma instância Nova e adiciona um volume do Cinder. O usuário pode especifi-
car a imagem usada no boot e o nome da chave SSH para instalar na instância.
Por fim, o IP da instância é retornado ao usuário ao final do processo:
heat_template_version: 2015-04-30
description: Simple template to deploy a single compute instance
parameters:
ssh_key_name:
Type: String
Description: ssh keypair name
image_name:
Type: String
Description: The image to boot
resources:
my_server:
Type: OS::Nova::Server
properties:
flavor: m1.small
key_name: {"Ref": "ssh_key"}
block_device_mapping:
device_name: vda
volume_id: {"Ref": "my_vol"}
my_vol:
Type: OS::Cinder::Volume
properties:
size: 20
image: {"Ref": "image_name"}
outputs:
server_ip:
Description: The server IP
Value: {"Fn::GetAtt":["my_server","first_address"]
100
Sendo um possível esqueleto de template:
heat_template_version:
description:
parameters:
param1:
type:
label:
description:
default:
param2:
...
resources:
resource_name:
type: OS::*::*
properties:
prop1: { get_param: param1}
prop2: { get_param: param2}
...
outputs:
output1:
description:
value: { get_attr: resource_name,attr] }
Além disso, um dos recursos de um template pode ser outro template, o
que permite ter estruturas alinhadas, onde cada template realiza uma função
específica. Dessa forma, evita-se a criação de templates muito longos, além de
permitir a reusabilidade de templates.
5.16. Placement
Serviço do OpenStack que provê uma API HTTP para realizar o rastreamento
de inventários e usos de recursos da nuvem para ajudar outros serviços a ge-
renciar e alocar efetivamente seus recursos.
A Figura 40 representa a arquitetura simplificada desse serviço, onde o ser-
viço Nova do OpenStack publica dados no Placemente, assim como demais
clientes, representados pela figura de usuário, podem checar o inventário do
Placement. A Figura 41 representa o fluxo de uso desse serviço.
Apesar de o Placement ser uma solução genérica para a nuvem OpenStack,
o único serviço que, de fato o uso, é o Nova
30
, sendo que a equipe de desen-
volvimento do Cinder informou que não existem benefícios, para o Cinder, em
30
Desde a versão 14.0.0 Newton.
101
usar o Placement, vide discussão oficial.
Figura 40: Arquitetura do Placement
Por exemplo, um provedor de recursos pode ser um nó de computação, um
armazenamento compartilhado, entre outros. Tal serviço, então, publica dados
para o Placement, que os utiliza para atualizar o inventário. Os tipos dos recur-
sos consumidos são monitorados como classes. O serviço provê um conjunto
de classes padrões (como VCPU) e permite a criação de tipos customizados.
Por padrão o serviço do Nova tenta reportar seu inventário e uso assim que
uma API do Placement estiver disponível, e utiliza tal API para descobrir qual a
melhor escolha para alocar instâncias.
102
Figura 41: Workflow do uso do Nova com o Placement
Obtido de link
5.17. OpenStack CLI
O OpenStack client consiste em um conjunto de ferramentas de linha de co-
mando, as quais permitem acessar os serviços do OpenStack. Tais ferramentas
podem ser instaladas através do pip.
Atualmente, existe o projeto python-openstackclient que agrega comandos
para as APIs dos serviços de computação, identidade, imagem, rede, armaze-
namento de objetos e armazenamento em blocos.
Para a instalação de tal ferramenta, o comando necessário é:
pip install python-openstackclient
Entretanto, é importante ressaltar que essa ferramenta não abrange todos
os serviços do OpenStack, além de certos comandos de certos serviços não es-
tarem presentes nessa ferramenta. Com isso, será necessário instalar clientes
de projetos específicos. Para tal, o comando necessário é:
pip install python-<PROJETO>client
103
Onde o placeholder <PROJETO> deve ser alterado para o nome do serviço
do OpenStack do qual se deseja instalar o cliente. Os projetos possíveis são:
• barbican: serviço de gerenciamento de chaves;
• ceilometer: API de telemetria;
• cinder: API para armazenamento de blocos e extensões;
• cloudkitty: API para o serviço de bilhetagem;
• designate: API para o serviço de DNS;
• fuel: API para o serviço de deploy;
• glance: API Para o serviço de imagem;
• gnocchi: API v3 de telemetria;
• heat: API de orquestração;
• magnum: API de serviço de gerenciamento de infraestrutura de contêi-
neres;
• manila: API para sistemas de arquivos compartilhados;
• mistral: API do serviço de workflow;
• monasca: API de monitoramento;
• murano: API de catálogi de aplicação;
• neutron: API de rede;
• nova: API de computação e extensões;
• sahara: API de processamento de dados;
• senlin: API de serviço de agrupamentos;
104
• swift: API de armazenamento de objetos;
• trove: API de serviço de banco de dados;
105
6. Componentes dependentes
Além dos serviços do OpenStack, existem outros componentes, que não
fazem parte do projeto OpenStack
31
, mas que são utilizados pelos serviços do
OpenStack, sendo necessários para o funcionamento da nuvem.
A presente sessão irá abordar tais componentes dependentes, à saber:
• RabbitMQ;
• Redis;
• Memcached;
• Etcd;
• InfluxDB;
• Kibana;
• Grafana;
• OpenSearch e
• MySQL/MariaDB.
6.1. RabbitMQ
O OpenStack usa uma fila de mensagens para coordenar operações e infor-
mações de status entre os serviços, e seus agentes. O serviço de fila de men-
sagens normalmente é executado no control plane, e compartilhado entre os
serviços. O OpenStack suporta vários serviços de fila de mensagens, incluindo
RabbitMQ, Qpid e ZeroMQ, sendo o RabbitMQ o serviçoutilizado por padrão.
Tais serviços de fila são frameworks AMQP
32
, que proveem filas de mensa-
gens com comunicação peer-to-peer.
31
Não são projetos criados e mantidos pela comunidade.
32
Acrônimo para Advanced Message Queuing Protocol.
106
OpenStack não oferece suporte à confiança no nível da mensagem, como
mensagens assinadas. Dessa forma, o operador deve ser responsável por ga-
rantir a segurança das mensagens.
6.1.1. Arquitetura
A arquitetura do RabbitMQ, apresentada na Figura 42, é composta por:
• Produtor: responsável por gerar e enviar as mensagens para a fila.
• Consumidor: acessa e se increve em uma das filas, para obter as mensa-
gens que estão na mesma. Uma mensagem obtida por um consumidor é
retirada da fila.
• Exchange: os produtores não publicam as mensagens diretamente para
as filas. Ao invés disso, elas são enviadas para o exchange. Estes, por
sua vez, redirecionam as mensagens para suas respectivas filas, através
de bindings e chaves de roteamento. Bindings são o que conectam uma
fila à um exchange, sendo os tipos possíveis de exchange:
– Direct: roteia mensagens para filas com base na chave de rotea-
mento de mensagens. A mensagem será entregue diretamente na
fila que corresponde à chave de roteamento.
– Fanout: roteia mensagens para todas as filas que tem acesso.
– Topic: roteia mensagens para filas que dão match em um padrão
específico, que consistem em uma lista de palavras separadas por
pontos.
– Headers: roteia mensagens para as filas de acordo com as informa-
ções no cabeçalho de cada mensagem.
• Fila: estrutura de dados ordenados que é utilizada para armazenar as
mensagens. Implementada como um buffer que mantém a mensagem
até que a mesma seja consumida.
107
Figura 42: Arquitetura do RabbitMQ
Obtido de link
6.1.2. Instalação
Para realizar a instalação do RabbitMQ, os passos necessários são:
1. Instalar os pacotes do RabbitMQ:
apt-get install rabbitmq-server
2. Adicionar o usuário openstack:
rabbitmqctl add_user openstack <password>
Creating user "openstack" ...
...done.
3. Alterar as configurações do usuário criado:
rabbitmqctl set_permissions openstack ".*" ".*" ".*"
Setting permissions for user "openstack" in vhos t "/" ...
...done.
4. Em seguida, será necessário configurar os serviços do OpenStack para
utilizarem a fila. Isso geralmente é realizado na propriedade transport_ur
l presente no arquivo de configuração do serviço em questão. O formato
de tal propriedade é:
transport://user:pass@host1:port[,hostN:portN]/virtual_host
Sendo um exemplo:
108
[oslo_messaging_notifications]
transport_url = rabbit://username:password@kafkahostname:9092
6.2. Redis
O Redis é um armazenamento de dados em memória, que é comumente
utilizado como banco de dados e cache. O Redis possui replicação nativa e
suporta diferentes níveis de persistência em disco. Além disso, ele oferece su-
porte a tipos de dados complexos (por exemplo, listas, conjuntos, JSON, entre
outros), com operações atômicas definidas nesses tipos de dados.
Conhecido por sua velocidade e versatilidade, tem por características prin-
cipais:
• Armazenamento em memória: o Redis armazena dados em memória
33
,
o que torna as operações de leitura e escrita mais rápidas, sendo ideal
para aplicações em que a latência de acesso aos dados é importante.
• Suporte a estruturas de dados: o Redis suporta diversas estruturas de
dados diferentes, vide Figura 43, como strings, hashes, listas, conjuntos,
bitmaps e índices geoespaciais.
33
Embora possa realizar também o armazenamento em disco.
109
Figura 43: Dados suportados pelo Redis
Obtido de link
No OpenStack, o Redis é um componente opcional, que é utilizado para
diversos própositos, de acordo com o serviço do OpenStack que o utiliza, po-
dendo o mesmo ser utilizado como cache, lock distribuído, armazenamento de
sessão, entre outros. Porém, de forma geral, o mesmo é utilizado visando au-
mento de performance e escalabilidade.
Alguns dos serviços que utilizam o Redis são:
• Nova: utiliza o Redis como cache de dados frequentemente acessados.
• Glance: utiliza o Redis como cache para as informações de metadados de
imagens.
• Cinder: utiliza o Redis como mecanismo de lock distribuído, para garantir
operações atômicas durante o manejo de volumes.
• Horizon: utiliza o Redis para armazenamento de sessões.
6.3. Memcached
O Memcached é um armazenamento de dados em memória, assim como
o Redis, vide Seção 6.2. Entretanto, o Memcached é muito mais leve e sim-
ples, ideal para operações que não envolvam estruturas de dados complexas.
110
Além disso, o Memcached não replica os dados. O cliente é que tem que lidar
com a replicação, caso ele deseje, entre todas as instâncias do Memcached do
ambiente.
Tem como características:
• Cache distribuída: o Memcached pode operar de forma distribuída, o
que significa que pode abranger vários servidores para acomodar gran-
des quantidades de dados armazenados em cache. Porém, é importante
ressaltar que o Memcached não replica dados, sendo obrigação do cliente
implementar e lidar com tal replicação.
• Armazenamento chave-valor: os dados são armazenados em um for-
mato de chave-valor, onde um dado está associado à uma chave única,
o que torna a busca de tal dado muito fácil, uma vez que se tenha a chave
do mesmo.
• Protocolo: o Memcached usa um protocolo simples de texto.
• Descarte e expiração: o Memcached faz uso da política de descarte do
menos usado recentemente para alocar memória para novos dados
34
.
Além disso, é possível especificar uma data de expiração para o dado, de
forma que o Memcached o descarte assim que tal período for atingido.
• Armazenamento: ao contrário do Redis, que oferece a opção de armaze-
namento em disco, o Memcached apenas trabalha com armazenamento
em memória.
Ao contrário do Redis, o Memcached não suporta estruturas de dados com-
plexas. No OpenStack, o Memcached é utilizado para incrementar a perfor-
mance, escalabilidade e responsibilidade de vários serviços, ao manter em ca-
che dados frequentemente acessados, o que reduz o acesso a dados em disco.
34
Quando não existe mais memória disponível.
111
Entretanto, é importante mencionar que o Memcached é apenas utilizado para
armazenar dados simples. Dados complexos, como bitmaps, devem ser arma-
zenados no Redis.
6.3.1. Instalação
Para realizar a instalação do Memcached, os passos necessários são:
1. Instalar os pacotes:
# apt install memcached python3-memcache
2. Editar o arquivo /etc/memcached.conf para que o Memcached escute to-
das as requisições vindas de determinada faixa de IP:
# Alterar a linha que contém -l 127.0.0.1 para
-l <ip>
3. Reiniciar o serviço:
service memcached restart
6.3.2. Comparação com o Redis
A Tabela 3 apresenta a comparação entre o Memcached e o Redis:
Tabela 3: Comparação entre Redis e Memcached
Memcached Redis
Latência a baixo de milisegundos Sim Sim
Facilidade para uso por parte dos desenvolvedores Sim Sim
Particionamento de dados Sim Sim
Suporte à múltiplas linguagens de programação Sim Sim
Estruturas de dados avançadas Não Sim
Arquitetura com multithread Sim Não
Snapshots Não Sim
Replicação Não Sim
Transações Não Sim
Publicação/subscrição Não Sim
Suporte a scripts Lua Não Sim
Suporte geoespacial Não Sim
Obtido de link
112
Tanto o Redis quanto o Memcached oferecem suporte a tempos de resposta
inferiores a um milissegundo. Ao armazenar os dados na memória, eles podem
realizar a leitura dos dados com mais rapidez quando comparados com bancos
de dados que armazenam os dados em disco.
Ambos possuem uma sintaxe fácil de usar e requerem uma quantidade mí-
nima de código para a integração com a aplicação. Além disso, os dois permi-
tem que você distribua os dados entre diversos nós. Isso permite aumentar a
escala horizontalmente para lidar melhor com mais dados quando a demanda
crescer.
O Redis e o Memcached tem muitos clientes de código aberto disponíveis
para os desenvolvedores. As linguagens com suporte incluem Java, Python,
PHP, C, C++, C#, JavaScript, Node.js, Ruby, Go e muitas outras.
Além de strings, o Redis oferece suporte para listas, conjuntos, conjuntos
classificados, hashes, matrizes de bits e HyperLogLogs. As aplicações podem
usar essas estruturas de dados mais avançadas para oferecer suporte a uma
variedade de casos de uso. Entretanto, o Memcached apenas suporta estrutu-
ras de dados simples.
Como o Memcached tem uma arquitetura com vários segmentos, ele pode
usar diversos núcleos de processamento. Isso significa que você pode lidar
com mais operações ao aumentar a escala verticalmente para a capacidade de
computação. Enquanto o Redis não dá suporte a essa funcionalidade.
Entretanto, com o Redis, é possível manter os dados em disco com um
snapshot para um ponto no tempo que pode ser usado para arquivamento
ou recuperação. Além disso, o Redis permite que você crie diversas réplicas de
um nó primário. Isso permite escalar leituras de banco de dados e ter clusters
altamente disponíveis.
O Redis também oferece suporte para transações que permitem executar
um grupo de comandos como uma operação isolada e atômica, assim como
oferece suporte a sistemas de mensagens publicação/subscrição com corres-
113
pondência de padrões, que pode ser usado para salas de chat de alta perfor-
mance, fluxos de comentários em tempo real, feeds de mídias sociais e inter-
comunicação de servidores.
O Redis permite a execução de scripts transacionais em Lua. Tais scripts po-
dem ajudar a impulsionar a performance e simplificar a aplicação, quando cor-
retamente escritos. Por fim, o Redis tem comandos com propósitos específicos
para se trabalhar com dados geoespaciais em grande escala. É possível execu-
tar operações, como descobrir a distância entre dois elementos (por exemplo,
pessoas ou lugares) e localizar todos os elementos em uma determinada dis-
tância de um ponto.
De forma geral, o Redis é recomendado para operações mais complexas,
enquanto que o Memcached é recomendado para operações mais simples. En-
tretanto, a escolha de um ou outro deve levar em conta, além da complexidade
das operações, os recursos (financeiros, de hardware e humanos) disponíveis
para o projeto.
6.4. Etcd
Etcd é um armazenamento de chave-valor distribuído de código aberto que
é frequentemente usado para configuração compartilhada e descoberta de
serviços em sistemas distribuídos.
Tem por características:
• Consistência distribuída: o Etcd foi projetado para fornecer garantias
de consistência em um ambiente distribuído. Ele usa o algoritmo de con-
senso Raft para garantir que todos os nós do cluster concordem com o
estado atual do sistema.
• API simples: o Etcd provê uma API HTTP, o que permite seu uso em várias
linguagens de programação.
• Suporte a watch: o Etcd suporta operações de watch, permitindo que
os aplicativos assinem alterações em chaves específicas. Isso o torna útil
114
para implementar coordenação distribuída e arquiteturas orientadas a
eventos.
• Segurança: o Etcd suporta autenticação e encriptação.
• Alta disponibilidade: o Etcd é projetado para ser altamente disponível e
resistente a falhas de nós.
No OpenStack, o Etcd é comumente usado para gerenciamento de configu-
ração distribuída e coordenação entre diferentes componentes. Ajuda a man-
ter a consistência entre vários nós em um ambiente distribuído, o que é crucial
para que serviços como Nova, Neutron e outros funcionem perfeitamente jun-
tos.
De forma geral, o papel do Etcd em uma nuvem OpenStack é o de garantir
o bom funcionamento e a confiabilidade das implantações do OpenStack, for-
necendo um armazenamento de dados consistente e distribuído para fins de
configuração e coordenação.
6.4.1. Instalação
Para instalar o Etcd, os passos necessários são:
1. Instalar o pacote:
apt install etcd
2. Editar o arquivo /etc/default/etcd:
ETCD_NAME="controller"
ETCD_DATA_DIR="/var/lib/etcd"
ETCD_INITIAL_CLUSTER_STATE="new"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster-01"
ETCD_INITIAL_CLUSTER="controller=http://10.0.0.11:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.0.11:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://10.0.0.11:2379"
ETCD_LISTEN_PEER_URLS="http://0.0.0.0:2380"
ETCD_LISTEN_CLIENT_URLS="http://10.0.0.11:2379"
3. Habilitar e reiniciar o serviço:
systemctl enable etcd
systemctl restart etcd
115
6.5. InfluxDB
O InfluxDB é um banco de dados de séries temporais desenvolvido pela
InfluxData. Ele é otimizado para armazenar, consultar e visualizar grandes vo-
lumes de dados temporais. Os dados das séries são pontos indexados em or-
dem temporal, tornando-os ideais para armazenar métricas, eventos e outros
dados que mudam ao longo do tempo. O InfluxDB é amplamente utilizado em
monitoramento de infraestrutura, análise de IoT (Internet das Coisas), análise
de logs e outras aplicações que envolvem dados temporais.
Tem por características:
• Séries temporais: o InfluxDB é otimizado para lidar com séries tempo-
rais.
• Escalabilidade: escalável horizontalmente, sendo possível adicionar mais
nós para lidar com uma carga maior.
• Linguagem InfluxQL: o InfluxDB possuí uma linguagem para query pró-
pria, chamada InfluxQL, que é semelhante a linguagem SQL, mas otimi-
zada para séries temporais.
• Processamento de dados e visualização: o InfluxDB integra com várias
ferramentas de processamento e visualização de dados, por exemplo, o
Grafana.
No OpenStack, o InfluxDB pode ser usado em conjunto com outras ferra-
mentas de monitoramento e coleta de dados. Apesar disso, seu principal uso
consiste no mesmo atuando como backend do CloudKitty, onde o mesmo ar-
mazena dados de medição e faturamento gerados pelo CloudKitty.
Para configurar o CloudKitty para que o mesmo utilize o InfluxDB como bac-
kend, o processo consiste em editar o arquivo de configuração do CloudKitty,
localizado em /etc/cloudkitty-api/cloudkitty.conf, para que o mesmo possua as
seguintes sessões:
116
[storage]
backend = influxdb
version = 2
[storage_influxdb]
database = cloudkitty
host = <ip>
port = <porta>
use_ssl = False
6.6. Kibana
O Kibana é uma ferramenta de visualização de dados que faz parte do Elastic
Stack
35
. Tal ferramenta permite que os usuários explorem, analisem e visua-
lizem dados em tempo real de maneira intuitiva e interativa. Com o Kibana,
é possível criar painéis personalizados, gráficos e tabelas para obter insights
valiosos a partir das visualizações dos dados coletados.
Tem por características:
• Painéis interativos: é possível criar painéis interativos que exibem visu-
almente os dados de forma clara e compreensível. Os painéis podem ser
personalizados de acordo com as necessidades do usuário, permitindo a
inclusão de gráficos, tabelas, mapas e outros elementos visuais.
• Exploração de dados: através de recursos como filtros, consultas e agre-
gações, os usuários podem aprofundar a análise dos dados e obter in-
sights sobre os dados.
• Visualização geoespacial: é possível visualizar dados geoespaciais em
mapas interativos. Isso permite que os usuários identifiquem padrões
geográficos, analisem a distribuição dos dados e tomem decisões basea-
das em informações geográficas.
• Alertas e notificações: é possível configurar alertas e notificações com
base em condições específicas dos dados.
35
Suíte de produtos desenvolvida pela Elastic.
117
• Fonte de dados: suporta uma ampla variedade de fontes de dados, in-
cluindo bancos de dados relacionais, bancos de dados NoSQL, arquivos
CSV, logs de servidor, entre outros.
No OpenStack, é possível utilizar o Kibana para analizar os logs e métricas
geradas pelos serviços do OpenStack. Antigamente, era possível realizar o de-
ploy do Kibana em conjunto com o OpenStack ao utilizar o kolla-ansible. Entre-
tanto, uma vez que a Elastic, empresa dona do Kibana, fechou o código-fonte
do mesmo, tal funcionalidade foi removida. Dessa forma, é necessário instalar
e configurar o ElasticSearch e o Kibana manualmente em um ambiente Open-
Stack.
6.7. Grafana
O Grafana é uma ferramenta open source para visualizar e analisar métricas
por meio de gráficos. Ele tem suporte para diversos tipos de bancos de dados
e pode ser instalado em qualquer sistema operacional.
Para facilitar a visualização dos gráficos, é possível criar dashboards dinâ-
micos. Além disso, a ferramenta permite configurar alertas com base nas mé-
tricas, que são analisadas de forma contínua para notificar o usuário sempre
que preciso, de acordo com as regras definidas por ele. É bastante utilizado
por sistemas de monitoramento para gerar gráficos real-time.
6.7.1. Instalação
Para instalar o Grafana no OpenStack, considerando que a instalação foi
realizada via kolla-ansible, os passos necessários são:
1. Editar o arquivo /etc/koll a / g lo b a ls . y m l, alterando/adicionando as seguin-
tes configurações:
enable_grafana: "yes"
# Caso se deseje utilizar o Prometheus como fonte de dadoss
enable_prometheus: "yes"
2. Fazer o deploy ou reconfigurar o deploy já realizado.
118
Após isso, deve-se acessar o dashboard web do Grafana e configurar os pai-
néis de acordo com o desejado.
6.7.2. Grafana vs Kibana
Apesar de ambas as soluções parecerem oferecer o mesmo, o Kibana é
usado principalmente para analisar e monitorar logs. O Grafana, por sua vez,
é uma ferramenta para análise visual de métricas do ambiente.
6.8. OpenSearch
O OpenSearch é um projeto de código aberto, que consiste em uma suíte de
busca e análise usada por desenvolvedores para ingestão, proteção, pesquisa,
agregação, visualização e análise de dados para uma série de casos de uso, tais
como análise de logs, pesquisa de aplicações, pesquisa empresarial e muito
mais.
Quando a empresa Elastic resolveu alterar as licenças do ElasticSearch e do
Kibana, o OpenSearch surgiu como um fork. O OpenSearch consiste em três
principais componentes:
• OpenSearch: derivado do ElasticSearch 7.10.2, componente principal do
OpenSearch, consiste em um mecanismo de pesquisa que fornece recur-
sos distribuídos de pesquisa e análise. Ele oferece suporte a recursos
como pesquisa de texto, agregações e processamento distribuído de da-
dos.
• OpenSearch Dashboards: derivado do Kibana 7.10.2, ferramenta de vi-
sualização de dados que permite aos usuários criar dashboards interati-
vos para análise de dados e monitoramento.
• Data Prepper: coletor de dados que roda do lado servidor. Capaz de
filtrar, enriquecer, transformar, normalizar e agregar dados para análise
e visualização. É a ferramenta usada pelo OpenSearch para a ingestão de
dados.
119
Além disso, os usuários podem extender as funcionalidades do OpenSearch
através de plugins.
Pode ser utilizado em conjunto com o OpenStack, para prover análise e vi-
sualização, tanto de métricas quanto de logs.
6.8.1. Instalação
Para a instalação do OpenSearch no OpenStack, quando utilizado o kolla-
ansible, os passos necessários são:
• Alterar o arquivo /etc/kolla/globals.yml, alterando/adicionando as seguin-
tes configurações:
enable_central_logging: "yes"
enable_opensearch: "yes"
• Fazer o deploy ou reconfigurar o deploy já realizado.
Em seguida, deve-se acessar o dashboard web do OpenSearch, e começar a
configurar os painéis de acordo com o desejado.
6.9. MySQL/MariaDB
Tanto MySQL quanto MariaDB são bancos de dados relacionais, sendo o
MariaDB um fork do MySQL. A maior parte dos serviços do OpenStack utilizam
um banco de dados SQL para armazenar informações. É possível, em uma
infraestrutura OpenStack, possuir apenas uma instância de banco de dados, a
qual é acessível para todos os serviços do OpenStack.
Entretanto, cada serviço terá um usuário de acesso único, assim como um
schema único, de forma que diferentes serviços do OpenStack não tenham
acesso à informações de outros serviços.
6.9.1. Instalação
Para instalar um banco de dados SQL que será utilizado pelos serviços do
OpenStack, os passos manuais necessários são:
1. Instalar os pacotes:
120
apt install mariadb-server python3-pymysql
2. Crie e edite o arquivo /etc/mysql/mar iadb.conf. d/99 -opens tack. cnf com
as seguintes informações:
• Crie uma sessão nomeada [ mysqld], e adicione a configuração bind
-address como o IP no qual se deseja ouvir as conexões. Esse IP deve
ser acessível por todos os serviços do OpenStack que irão utilizar o
banco de dados:
[mysqld]
bind-address = <ip>
default-storage-engine = innodb
innodb_file_per_table = on
max_connections = 4096
collation-server = utf8_general_ci
character-set-server = utf8
3. Reinicie o serviço:
service mysql restart
4. Configure as credências de acesso ao banco de dados com o seguinte
script:
mysql_secure_installation
Ao realizar o deploy via kolla-ansible, esse processo é simplificado, bas-
tando alterar o arquivo /etc/kolla/globals.yml e realizar/reconfigurar o deploy:
enable_mariadb: "yes"
121
7. Conclusão
Esse documento abordou, de forma geral, os principais conceitos de uma
nuvem OpenStack e componentes auxiliares. Ambos são extensos e comple-
xos, portanto não é possível abordá-los em sua totalidade, contudo, caso haja
dúvidas ou sugestões de melhorias na documentação, um issue pode ser criado
no GitLab.
122
Apêndices
123
Apêndice A. Projetos do OpenStack
Nome Objetivo
Adjutant Automação de processos operacionais
Barbican Serviço de gerenciamento de chaves
Blazar Serviço de reserva de recursos
Cinder Serviço de armazenamento de blocos
CloudKitty Serviço de precificação
Cyborg Gerenciamento do ciclo de vida do Accelerator
Designate Serviço de DNS
Ec2-Api API de compatibilidade do EC2 API com o OpenStack
Freezer Serviço de backup, restauração e recuperação de desastres
Glance Serviço de imagens
Heat Serviço de orquestração
Horizon Dashboard web
Ironic Serviço de Bare Metal
Keystone Serviço de identidade
Kolla Deploy do OpenStack usando containers
Kuryr Serve de ponte entre o OpenStack e rede de contêineres
Magnum Serviço de gerenciamento de infraestrutura de contêineres
Manila Serviço de sistemas de arquivos compartilhados
Masakari Serviço de HA
Mistral Serviço de fluxo de trabalho
Monasca Monitoramento
Murano Serviço de catálogo de aplicativos
Neutron Serviço de redes
Nova Serviço de computação
Octavia Serviço de load balancer
OpenStack Charms Juju Charms para realizar o deploy do OpenStack
124
Nome Objetivo
OpenStack-Chef Livros de receitas do Chef para gerenciamento de ciclo de vida
OpenStack-ansible Ansible para deploy do OpenStack
Openstacksdk SDKs python e CLI para usuários finais
Oslo Bibliotecas comuns
Puppet OpenStack Módulos do Puppet para realizar o deploy
Quality Assurance Ferramentas para garantir a estabilidade e qualidade do
OpenStack
Rally Serviço de benchmarking
Release Management Coordenação dos lançamentos do OpenStack
Requirements Gerenciamento de dependências comuns
Sahara Serviço de processamento de dados
Senlin Serviço de clusters
Skyline Dashboard
Solum Serviço de automação do ciclo de vida de desenvolvimento de
software
Storlets Computação dentro do serviço de armazenamento de objetos
Sunbeam Ferramentas operacionais e de implantação para OpenStack
Swift Serviço de armazenamento de objetos
Tacker Serviço de orquestração NFV
Telemetry Serviço de telemetria
Tripleo Serviço de deploy
Trove Serviço de banco de dados
Venus Serviço de gerencimento de logs
Vitrage Serviço de análise de causas raíz
Watcher Serviço de otimização de infraestrutura
Zagar Serviço de mensagem
Zun Serviço de containêres
125
Referências
[1] H Cloud. The nist definition of cloud computing. National Institute of Science
and Technology, Special Publication, 800(2011):145, 2011.
126
