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
6.9 MySQL/MariaDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.9.1 Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7 Conclusão 122
Apêndice A Projetos do OpenStack 124
5
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 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