Operação da nuvem Apache CloudStack
Este documento apresenta o conceito de ambientes de computação em nu-
vem, no contexto de nuvem privada, e uma introdução à plataforma de or-
questração de nuvem Apache CloudStack, com foco no processo de operação
da mesma.
Data de atualização: 7 de outubro de 2024
Revision: 774b16a47611371568767a362e7f712a9012450f
Conteúdo
1 Introdução 20
1.1 Plataformas de nuvem privada . . . . . . . . . . . . . . . . . . . . . 21
1.1.1 Funcionalidades básicas . . . . . . . . . . . . . . . . . . . . . 21
1.2 História do Apache CloudStack . . . . . . . . . . . . . . . . . . . . . 23
2 Conceitos básicos do Apache CloudStack 24
2.1 Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Compute Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Organização lógica do Apache CloudStack . . . . . . . . . . . . . . 26
2.5 Componentes do Apache CloudStack . . . . . . . . . . . . . . . . . 27
3 Funcionalidades do Apache CloudStack 29
3.1 Dashboard inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Configurações da VM . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 Configurações gerais . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.2 Configurações diversas para uso interno . . . . . . . . . . . 31
3.2.3 Configurações de VM específicas para KVM . . . . . . . . . 31
3.2.4 Configurações de VM específicas para VMWare . . . . . . . 32
3.2.5 Configurações específicas para uso interno do XenServer . 32
3.2.6 Configurações específicas para Mac OSX - Guest . . . . . . 32
3.2.7 Configurações globais para VMs . . . . . . . . . . . . . . . . 32
3.2.7.1 Restrição de acesso ao usuário . . . . . . . . . . . 32
3.2.7.2 Metadados de configurações extras . . . . . . . . 33
3.2.7.3 Retenção de estatísticas das VMs . . . . . . . . . . 34
3.3 Gerência de volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.1 Migração de volume com VM parada (migração a frio) . . . 36
3.3.2 Migração de volume com VM rodando (migração a quente) 37
3.3.3 Migração de volume via CLI . . . . . . . . . . . . . . . . . . . 38
2
3.3.4 Importação de volume para outra zona ou conta . . . . . . 41
3.4 Virtual router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.1 Parada do virtual router . . . . . . . . . . . . . . . . . . . . . 43
3.4.2 Reinicialização do virtual router . . . . . . . . . . . . . . . . . 44
3.4.3 Destruição de virtual router . . . . . . . . . . . . . . . . . . . 45
3.4.4 Definição de offering padrão do virtual router . . . . . . . . 45
3.5 IPs públicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5.1 IP público reservado para system VMs . . . . . . . . . . . . . 47
3.6 Suporte a IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6.1 Redes isoladas e tiers de VPCs . . . . . . . . . . . . . . . . . 47
3.6.2 Redes shared . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.7 Host, storage e network tags . . . . . . . . . . . . . . . . . . . . . . . 55
3.7.1 Host tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.7.2 Storage tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.7.3 Network tags . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.7.4 Tags flexíveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.8 Gerenciamento do deploy de instâncias com base em seus siste-
mas operacionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.8.1 Preference OS dos hosts . . . . . . . . . . . . . . . . . . . . . 64
3.8.2 Flexible guest OS . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.9 Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.9.1 Configurações de snapshots . . . . . . . . . . . . . . . . . . . 67
3.10 Auditoria de eventos e alertas . . . . . . . . . . . . . . . . . . . . . 67
3.10.1 E-mails de alertas . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.10.2 Busca e filtro de alertas . . . . . . . . . . . . . . . . . . . . . 69
3.10.3 Remoção ou arquivamento de alertas . . . . . . . . . . . . . 69
3.10.4 Automatização da remoção de eventos e alertas . . . . . . 70
3.11 Service offerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.11.1 Compute offerings . . . . . . . . . . . . . . . . . . . . . . . . . 70
3
3.12 Network offerings - throttling . . . . . . . . . . . . . . . . . . . . . . . 71
3.12.1 System offerings . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.12.1.1 Criação de system offering . . . . . . . . . . . . . . 73
3.12.1.2 Edição de system offering . . . . . . . . . . . . . . . 75
3.12.1.3 Exclusão de system offering . . . . . . . . . . . . . . 76
3.12.1.4 Alteração da system offering de uma system VM . . 77
3.12.2 Backup offerings . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.12.2.1 Habilitação de backup offering . . . . . . . . . . . . 78
3.12.2.2 Importação de backup offering . . . . . . . . . . . . 79
3.12.2.3 Exclusão de backup offering . . . . . . . . . . . . . 81
3.12.2.4 Utilização de backup offering . . . . . . . . . . . . . 81
3.12.3 Limitação de IOPS e BPS nas ofertas de discos . . . . . . . . 84
3.13 Gerência de storages no Apache CloudStack . . . . . . . . . . . . . 88
3.13.1 Primary storage . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.13.1.1 Adição de primary storage . . . . . . . . . . . . . . . 90
3.13.1.2 Desabilitação de primary storage . . . . . . . . . . 93
3.13.1.3 Modo manutenção do primary storage . . . . . . . 94
3.13.1.4 Comportamento após reinicialização do host . . . 94
3.13.1.5 Uso de local storage . . . . . . . . . . . . . . . . . . 95
3.13.2 Secondary storage . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.13.2.1 Adição de secondary storage . . . . . . . . . . . . . 102
3.13.2.2 Migração de dados entre secondary storages . . . 102
3.13.2.3 Modo read-only do secondary storage . . . . . . . . 103
3.13.2.4 Modo read-write do secondary storage . . . . . . . 104
3.13.2.5 Deleção de secondary storage . . . . . . . . . . . . 105
3.14 Alocação de recursos para o armazenamento secundário . . . . . 105
4 Configurações do Apache CloudStack 110
4.1 Escopos de configuração . . . . . . . . . . . . . . . . . . . . . . . . 110
4.2 Configurações globais que regem o uso do primary storage . . . . 111
4
4.3 Configurações para limitação de recursos . . . . . . . . . . . . . . 113
4.4 Configurações que regem o uso de Kubernetes . . . . . . . . . . . 113
4.4.1 Habilitação de integração com Kubernetes . . . . . . . . . . 113
4.4.2 Criação de clusters Kubernetes . . . . . . . . . . . . . . . . . 114
5 Customização da UI 115
5.1 Alteração de logo e outros elementos . . . . . . . . . . . . . . . . . 115
5.2 Alteração de logo ao redimensionar a página . . . . . . . . . . . . 117
5.3 Gerência de temas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.3.1 Criação de tema . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.3.2 Listagem de temas . . . . . . . . . . . . . . . . . . . . . . . . 120
5.3.3 Atualização do tema . . . . . . . . . . . . . . . . . . . . . . . 122
5.3.3.1 Campo css . . . . . . . . . . . . . . . . . . . . . . . 123
5.3.3.2 Configuração JSON . . . . . . . . . . . . . . . . . . . 124
5.3.4 Remoção de tema . . . . . . . . . . . . . . . . . . . . . . . . 125
5.3.5 Exemplos de personalizações comuns da UI . . . . . . . . . 125
5.3.5.1 Criação do tema com arquivo de estilização externo125
5.3.5.2 Observações sobre conflitos entre estilos . . . . . 126
5.3.5.3 Adição de fontes . . . . . . . . . . . . . . . . . . . . 126
5.3.5.4 Uso de variáveis CSS . . . . . . . . . . . . . . . . . . 126
5.3.5.5 Página de login . . . . . . . . . . . . . . . . . . . . . 127
5.3.5.6 Estilização do header . . . . . . . . . . . . . . . . . 128
5.3.5.7 Estilização da sidebar . . . . . . . . . . . . . . . . . 129
5.3.5.8 Estilização dos cards e dos gráficos do dashboard 131
5.3.5.9 Estilização dos links e listagens . . . . . . . . . . . 133
5.4 Redirecionamento para links externos . . . . . . . . . . . . . . . . 134
6 Contabilização do consumo de recursos 137
6.1 Usage Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.1.1 Configuração do Usage Server . . . . . . . . . . . . . . . . . 137
5
6.1.2 Usage type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.2 Quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.2.1 Configuração do Quota . . . . . . . . . . . . . . . . . . . . . 142
6.2.2 Gerência de tarifas . . . . . . . . . . . . . . . . . . . . . . . . 143
6.2.2.1 Criação de tarifas . . . . . . . . . . . . . . . . . . . 144
6.2.2.2 Detalhes das tarifas . . . . . . . . . . . . . . . . . . 146
6.2.2.3 Edição de tarifas . . . . . . . . . . . . . . . . . . . . 146
6.2.2.4 Remoção de tarifas . . . . . . . . . . . . . . . . . . 147
6.2.3 Regras de ativação . . . . . . . . . . . . . . . . . . . . . . . . 147
6.2.3.1 Presets padrões para todos os tipos de recursos . 149
6.2.3.2 Presets para o tipo RUNNING_VM . . . . . . . . . . 150
6.2.3.3 Presets para o tipo ALLOCATED_VM . . . . . . . . . 151
6.2.3.4 Presets para o tipo VOLUME . . . . . . . . . . . . . 151
6.2.3.5 Presets para os tipos TEMPLATE e ISO . . . . . . . . 152
6.2.3.6 Presets para o tipo SNAPSHOT . . . . . . . . . . . . 152
6.2.3.7 Presets para os tipos NETWORK_OFFERING . . . . 153
6.2.3.8 Presets para o tipo VM_SNAPSHOT . . . . . . . . . 153
6.2.3.9 Presets para o tipo BACKUP . . . . . . . . . . . . . . 153
6.2.3.10 Presets para o tipo NETWORK USAGE . . . . . . . . 154
6.2.3.11 Presets para o tipo BACKUP OBJECT . . . . . . . . . 154
6.2.3.12 Verificação das presets via API . . . . . . . . . . . . 154
6.2.3.13 Presets para os demais tipos de recurso . . . . . . 154
6.2.3.14 Exemplos de expressões . . . . . . . . . . . . . . . 155
6.2.4 Gerência de créditos . . . . . . . . . . . . . . . . . . . . . . . 158
6.2.4.1 Adição/remoção de créditos . . . . . . . . . . . . . 159
6.2.5 Contas ativas . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.2.6 Gerência de templates de e-mail do Quota . . . . . . . . . . 161
6.2.6.1 Observações sobre o uso do plugin Quota . . . . . 162
6
7 Operação 164
7.1 Depuração de problemas e processo de troubleshooting . . . . . . 164
7.1.1 Depuração através dos logs . . . . . . . . . . . . . . . . . . . 164
7.1.2 Depuração através da interface web . . . . . . . . . . . . . . 164
7.1.3 Depuração de problemas de rede . . . . . . . . . . . . . . . 165
7.1.4 Path dos arquivos de log . . . . . . . . . . . . . . . . . . . . . 165
7.1.5 Incremento de nível dos logs nos Management Servers e
KVM Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.1.6 Processo de troubleshooting . . . . . . . . . . . . . . . . . . . 169
7.2 Failover de hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
7.3 Gerenciamento dos serviços do Apache CloudStack . . . . . . . . 177
7.3.1 Gerenciamento do cloudstack-management . . . . . . . . . 177
7.3.2 Gerenciamento do cloudstack-agent para hypervisor KVM . 179
7.3.3 Gerenciamento do cloudstack-usage . . . . . . . . . . . . . 180
7.4 System VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
7.4.1 Console Proxy Virtual Machine . . . . . . . . . . . . . . . . . . 182
7.4.2 Secondary Storage Virtual Machine . . . . . . . . . . . . . . . 182
7.4.3 Virtual Router . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
7.4.3.1 Virtual Router health checks . . . . . . . . . . . . . . 183
7.4.4 Acesso às system VMs . . . . . . . . . . . . . . . . . . . . . . 187
7.4.5 Randomização de senha das system VMs . . . . . . . . . . . 187
7.4.6 URL para consumo da CPVM e SSVM . . . . . . . . . . . . . 188
7.5 Habilitação do aumento de recursos computacionais das VMs . . 189
7.6 Overprovisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
7.7 Atualização do Apache CloudStack . . . . . . . . . . . . . . . . . . . 192
7.7.1 Atualização entre major versions . . . . . . . . . . . . . . . . 192
7.7.2 Atualização dentro da mesma major version . . . . . . . . . 194
7.8 Atualização do certificado SSL no ambiente (nginx e ACS) . . . . . 194
7.8.1 Extração dos certificados intermediários e root . . . . . . . 195
7
7.8.2 Conversão de chave para PKCS#8: . . . . . . . . . . . . . . . 195
7.8.3 Adição de certificado no nginx . . . . . . . . . . . . . . . . . 195
7.8.4 Adição de certificado no Apache CloudStack . . . . . . . . . 195
7.9 Pares de chaves SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
8 Virtualizador KVM 203
8.1 Instalação do KVM e CloudStack Agent . . . . . . . . . . . . . . . . 204
8.2 Configuração do KVM e Cloudstack Agent . . . . . . . . . . . . . . 205
8.3 Operação do KVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
8.4 Topologia de CPU no KVM . . . . . . . . . . . . . . . . . . . . . . . . 208
8.5 Controle da CPU no KVM . . . . . . . . . . . . . . . . . . . . . . . . 209
9 Virtualizador VMWare 213
9.1 Criação de datastores . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
9.2 Instalação dos hosts ESXi . . . . . . . . . . . . . . . . . . . . . . . . . 214
9.2.1 Instalação padrão dos hosts ESXi . . . . . . . . . . . . . . . . 214
9.2.2 Configurações básicas dos hosts ESXi . . . . . . . . . . . . . 218
9.2.3 Configurações avançadas dos hosts ESXi . . . . . . . . . . . 223
9.2.3.1 Adição de novos IPs . . . . . . . . . . . . . . . . . . 224
9.2.3.2 Adição de novos datastores . . . . . . . . . . . . . . 226
9.2.3.3 Adição de chave de licença . . . . . . . . . . . . . . 228
9.3 Instalação do vCenter . . . . . . . . . . . . . . . . . . . . . . . . . . 229
9.3.1 Adição de chave de lincença . . . . . . . . . . . . . . . . . . 239
9.3.2 Adição de múltiplos hosts ESXi . . . . . . . . . . . . . . . . . 241
9.3.3 Remoção da interface gráfica do Linux . . . . . . . . . . . . 245
9.4 Adição de cluster VMWare no Apache CloudStack . . . . . . . . . . 246
9.5 Problemas na adição de cluster VMWare . . . . . . . . . . . . . . . 251
9.6 Importação de VMs do VMWare para o Apache CloudStack . . . . 254
9.6.1 Importação de VMs via UI . . . . . . . . . . . . . . . . . . . . 254
9.6.2 Importação de VMs via API . . . . . . . . . . . . . . . . . . . 257
8
10 Conclusão 259
Apêndice A Terminologia 261
9
Lista de Figuras
1 Computação em nuvem . . . . . . . . . . . . . . . . . . . . . . . . . 21
2 Exemplo de arquitetura do Apache CloudStack com tolerância à
falhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 Organização lógica do Apache CloudStack . . . . . . . . . . . . . . 27
4 Dashboard inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5 Aba de configurações da VM . . . . . . . . . . . . . . . . . . . . . . 30
6 Configurações globais . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7 Exemplo de retorno da query com o tamanho total da tabela vm
_stats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8 Migrando volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9 Confirmar a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10 Migrando a VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
11 Configurar a migração . . . . . . . . . . . . . . . . . . . . . . . . . . 38
12 Indo até a aba de virtual routers . . . . . . . . . . . . . . . . . . . . 42
13 Verificando se o VR foi corretamente criado . . . . . . . . . . . . . 42
14 Navegando até os virtual routers . . . . . . . . . . . . . . . . . . . . 43
15 Parando o virtual router . . . . . . . . . . . . . . . . . . . . . . . . . 43
16 Confirmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
17 Confirmando que o virtual router parou . . . . . . . . . . . . . . . . 44
18 Reiniciando o virtual router . . . . . . . . . . . . . . . . . . . . . . . 44
19 Destruindo o virtual router . . . . . . . . . . . . . . . . . . . . . . . . 45
20 Confirmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
21 Confirmando a remoção do virtual router . . . . . . . . . . . . . . . 45
22 Fluxo para definir offering padrão do virtual router . . . . . . . . . 46
23 Iniciando a adição do intervalo IPv6 para a rede pública . . . . . . 48
24 Adicionando um intervalo IPv6 para a rede pública . . . . . . . . . 48
25 Um prefixo /52 permite 4096 subredes IPv6 com bloco /64 . . . . 48
10
26 Iniciando a adição do intervalo IPv6 para a rede guest . . . . . . . 49
27 Adicionando um intervalo de IPv6 para a rede guest . . . . . . . . 49
28 Criando oferta para VPCs com suporte a IPv6 . . . . . . . . . . . . 50
29 Criando oferta para tier de VPCs com suporte a IPv6 . . . . . . . . 50
30 Validação da autoconfiguração do IPv6 da VM (via SLAAC) . . . . . 51
31 Apresentação na UI das rotas que deverão ser adicionadas no
roteador de borda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
32 Apresentação via API das rotas que deverão ser adicionadas no
roteador de borda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
33 Criando oferta para rede isolada com suporte a IPv6 . . . . . . . . 52
34 Validação da autoconfiguração do IPv6 da VM (via SLAAC) . . . . . 52
35 Apresentação na UI das rotas que deverão ser adicionadas no
roteador de borda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
36 Apresentação via API das rotas que deverão ser adicionadas no
roteador de borda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
37 Criação de uma rede shared com os dados do IPv4 . . . . . . . . . 54
38 Criação de uma rede shared com os dados do IPv6 . . . . . . . . . 54
39 Campos para atualizar storage tags e host tags de uma compute
offering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
40 Acessando a edição do host . . . . . . . . . . . . . . . . . . . . . . . 62
41 Criando a tag flexível no host . . . . . . . . . . . . . . . . . . . . . . 62
42 Acessando a edição do primary storage . . . . . . . . . . . . . . . . 63
43 Criando a tag flexível no primary storage . . . . . . . . . . . . . . . 63
44 Acesso ao host a ser configurado . . . . . . . . . . . . . . . . . . . . 65
45 Acesso ao formulário de edição do host . . . . . . . . . . . . . . . . 65
46 Configuração da preference OS do host . . . . . . . . . . . . . . . . 65
47 Configuração da regra de guest OS do host . . . . . . . . . . . . . . 66
48 Acessando os alertas . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
49 Arquivando ou deletando um alerta . . . . . . . . . . . . . . . . . . 69
11
50 System offering padrões . . . . . . . . . . . . . . . . . . . . . . . . . 73
51 Iniciando a criação de uma nova system offering . . . . . . . . . . . 73
52 Criando a nova system offering - 1 - continua . . . . . . . . . . . . . 74
53 Criando a nova system offering - 2 . . . . . . . . . . . . . . . . . . . 74
54 Iniciando a edição da system offering . . . . . . . . . . . . . . . . . . 75
55 Editando a system offering . . . . . . . . . . . . . . . . . . . . . . . . 75
56 Alterando a ordem da system offering . . . . . . . . . . . . . . . . . 76
57 Iniciando a exclusão da system offering . . . . . . . . . . . . . . . . 76
58 Excluindo a system offering . . . . . . . . . . . . . . . . . . . . . . . 76
59 Aba de backup offering . . . . . . . . . . . . . . . . . . . . . . . . . . 79
60 Iniciando a importação de uma nova backup offering . . . . . . . . 80
61 Importando a nova backup offering . . . . . . . . . . . . . . . . . . 80
62 Iniciando a exclusão da backup offering . . . . . . . . . . . . . . . . 81
63 Excluíndo a backup offering . . . . . . . . . . . . . . . . . . . . . . . 81
64 Iniciando a atribuição da VM à backup offering . . . . . . . . . . . . 81
65 Atribuindo a VM à backup offering . . . . . . . . . . . . . . . . . . . 82
66 Iniciando o backup manual da VM . . . . . . . . . . . . . . . . . . . 82
67 Fazendo o backup manual da VM . . . . . . . . . . . . . . . . . . . . 82
68 Iniciando o agendamento de backups . . . . . . . . . . . . . . . . . 82
69 Agendando os backups . . . . . . . . . . . . . . . . . . . . . . . . . . 83
70 Iniciando a remoção da VM da backup offering . . . . . . . . . . . . 83
71 Removendo a VM da backup offering . . . . . . . . . . . . . . . . . . 83
72 Selecionando um QoS type . . . . . . . . . . . . . . . . . . . . . . . . 84
73 Limitando a taxa de BPS . . . . . . . . . . . . . . . . . . . . . . . . . 86
74 Acessando menu de adição de um primary storage . . . . . . . . . 90
75 Detalhes de adição de um primary storage . . . . . . . . . . . . . . 91
76 Adição de um primary storage com NFS . . . . . . . . . . . . . . . . 92
77 Adição de um primary storage com Shared Mount Point . . . . . . . 93
78 Desabilitando um primary storage . . . . . . . . . . . . . . . . . . . 94
12
79 Habilitando o modo de manutenção . . . . . . . . . . . . . . . . . . 94
80 Habilitando o uso de local storage para VMs de sistema . . . . . . 96
81 Acessando a zona a ser editada . . . . . . . . . . . . . . . . . . . . 96
82 Acessando o menu de edição de zona . . . . . . . . . . . . . . . . . 97
83 Habilitando o uso de local storage para VMs de usuário . . . . . . 97
84 Adicionar oferta de computação com highlight em Storage Type . . 98
85 Adicionar oferta de disco com highlight em Storage Type . . . . . . 99
86 Migração a frio de volume para local storage . . . . . . . . . . . . . 100
87 Adicionando um novo secondary storage . . . . . . . . . . . . . . . 102
88 Detalhes de adição de um novo secondary storage . . . . . . . . . . 102
89 Migrando dados entre secondary storages . . . . . . . . . . . . . . . 103
90 Detalhes de migração de dados entre secondary storages . . . . . 103
91 Definindo um secondary storage como read only . . . . . . . . . . . 104
92 Definindo um secondary storage como read-write . . . . . . . . . . 104
93 Deletando um secondary storage . . . . . . . . . . . . . . . . . . . . 105
94 Confirmando deleção do secondary storage . . . . . . . . . . . . . . 105
95 Configuração global endpoint.url . . . . . . . . . . . . . . . . . . . . 114
96 Banner customizado . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
97 Rodapé customizado . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
98 Logo inteira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
99 Logo cortada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
100 Mini logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
101 Página de login customizada . . . . . . . . . . . . . . . . . . . . . . 128
102 Header estilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
103 Sidebar estilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
104 Sidebar fechada estilizada . . . . . . . . . . . . . . . . . . . . . . . . 131
105 Dashboard da conta root admin estilizado . . . . . . . . . . . . . . . 132
106 Dashboard da conta de usuário estilizado . . . . . . . . . . . . . . . 133
107 Listagem e links estilizados . . . . . . . . . . . . . . . . . . . . . . . 133
13
108 Um elemento definido . . . . . . . . . . . . . . . . . . . . . . . . . . 135
109 Mais de um elemento definido . . . . . . . . . . . . . . . . . . . . . 135
110 Link com ícone atribuído . . . . . . . . . . . . . . . . . . . . . . . . . 136
111 Acessando as configurações . . . . . . . . . . . . . . . . . . . . . . 138
112 Editando as configurações . . . . . . . . . . . . . . . . . . . . . . . . 139
113 Plugin Quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
114 Lista de tarifas ativas . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
115 Filtros da listagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
116 Formulário de criação de tarifa . . . . . . . . . . . . . . . . . . . . . 145
117 Detalhes da tarifa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
118 Ações possíveis para tarifas ativas . . . . . . . . . . . . . . . . . . . 146
119 Formulário de edição de tarifa . . . . . . . . . . . . . . . . . . . . . 147
120 Remoção de tarifa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
121 Lista de contas ativas . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
122 Formulário de adição/remoção de créditos . . . . . . . . . . . . . . 159
123 Lista de contas ativas . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
124 Filtros da listagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
125 Lista de templates de e-mail do Quota . . . . . . . . . . . . . . . . . 161
126 Editando o template de e-mail . . . . . . . . . . . . . . . . . . . . . . 162
127 Quota state para as contas admin e custom-account . . . . . . . . . 162
128 VM criada através da UI . . . . . . . . . . . . . . . . . . . . . . . . . 170
129 Identificando o comando enviado. . . . . . . . . . . . . . . . . . . . 170
130 Identificando o logid do processo desejado. . . . . . . . . . . . . . 171
131 Console Proxy Virtual Machine . . . . . . . . . . . . . . . . . . . . . . 182
132 Secondary Storage Virtual Machine . . . . . . . . . . . . . . . . . . . 182
133 Virtual Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
134 Visão dos health checks de determinado VR. . . . . . . . . . . . . . 184
135 Adicionando certificado SSL via UI . . . . . . . . . . . . . . . . . . . 196
136 Acessando a seção SSH key pairs . . . . . . . . . . . . . . . . . . . . 197
14
137 Criando um SSH key pair . . . . . . . . . . . . . . . . . . . . . . . . . 198
138 Criação da SSH key pair de forma automática . . . . . . . . . . . . . 199
139 Criando a chave SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
140 Criando instância e implementando a chave SSH . . . . . . . . . . 202
141 Virtualização KVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
142 Comparação de virtualizadores . . . . . . . . . . . . . . . . . . . . . 204
143 Exemplo de saída do comando virsh schedinfo . . . . . . . . . . . 211
144 Tela inicial da instalação do ESXi . . . . . . . . . . . . . . . . . . . . 215
145 Aceitar os termos de uso . . . . . . . . . . . . . . . . . . . . . . . . 215
146 Escolhendo o disco para instalar o sistema . . . . . . . . . . . . . . 216
147 Selecionando o layout do teclado . . . . . . . . . . . . . . . . . . . . 216
148 Criando senha root . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
149 Possível warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
150 Confirmar a instalação . . . . . . . . . . . . . . . . . . . . . . . . . . 217
151 Instalação do host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
152 Reiniciando o host . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
153 Login inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
154 Usuário padrão é o root, e a senha é aquela configurada durante
a instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
155 Seção Configure Management Network . . . . . . . . . . . . . . . . . 219
156 Seção IPv4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 220
157 IPv4 estático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
158 Aplicando alterações . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
159 Seção Troubleshooting Options . . . . . . . . . . . . . . . . . . . . . 221
160 Acesso ao shell do host . . . . . . . . . . . . . . . . . . . . . . . . . . 222
161 Acesso ao SSH do host . . . . . . . . . . . . . . . . . . . . . . . . . . 222
162 URL pra acesso à interface web . . . . . . . . . . . . . . . . . . . . . 223
163 Tela de login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
164 NICs disponíveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
15
165 Virtual switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
166 Configurando o novo virtual switch . . . . . . . . . . . . . . . . . . . 225
167 VM Kernel NICs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
168 Configurando o novo VM Kernel NIC . . . . . . . . . . . . . . . . . . 226
169 Datastores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
170 Tipos suportados de datastore. . . . . . . . . . . . . . . . . . . . . . 227
171 Configurando o novo datastore . . . . . . . . . . . . . . . . . . . . . 227
172 Finalize a configuração . . . . . . . . . . . . . . . . . . . . . . . . . . 228
173 Acessando a licença . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
174 Verificando se a licença é válida . . . . . . . . . . . . . . . . . . . . 229
175 Adicionando licença . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
176 Tipos de operações disponíveis . . . . . . . . . . . . . . . . . . . . . 231
177 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
178 Termos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
179 Tipos de deploy disponíveis . . . . . . . . . . . . . . . . . . . . . . . 232
180 Adicionando host ESXi . . . . . . . . . . . . . . . . . . . . . . . . . . 233
181 Adicionando a senha do root . . . . . . . . . . . . . . . . . . . . . . 233
182 Tamanho da infraestrutura . . . . . . . . . . . . . . . . . . . . . . . 234
183 Datastores disponíveis . . . . . . . . . . . . . . . . . . . . . . . . . . 234
184 Configurando a rede do vCenter . . . . . . . . . . . . . . . . . . . . 235
185 Finalizando a configuração do vCenter . . . . . . . . . . . . . . . . 235
186 Iniciando a configuração do PSC . . . . . . . . . . . . . . . . . . . . 236
187 Aplicando configurações básicas do appliance . . . . . . . . . . . . 236
188 Criando e configurando um novo SSO . . . . . . . . . . . . . . . . . 237
189 Programa de melhoria do VMWare . . . . . . . . . . . . . . . . . . 237
190 Finalizando a configuração . . . . . . . . . . . . . . . . . . . . . . . 238
191 Concluindo a instalação . . . . . . . . . . . . . . . . . . . . . . . . . 238
192 Tela inicial do vSphere . . . . . . . . . . . . . . . . . . . . . . . . . . 239
193 Tela de licenças . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
16
194 Adicionando a licença . . . . . . . . . . . . . . . . . . . . . . . . . . 240
195 Alterando o nome da licença . . . . . . . . . . . . . . . . . . . . . . 240
196 Finalizando a adição da licença . . . . . . . . . . . . . . . . . . . . . 241
197 Iniciando a adição de um novo datacenter/folder . . . . . . . . . . 242
198 Nomeando o novo datacenter . . . . . . . . . . . . . . . . . . . . . . 242
199 Adicionando um novo host ao datacenter . . . . . . . . . . . . . . . 243
200 Adicionando o IP do host . . . . . . . . . . . . . . . . . . . . . . . . . 243
201 Usuário e senha do host . . . . . . . . . . . . . . . . . . . . . . . . . 243
202 Resumo dos dados do host . . . . . . . . . . . . . . . . . . . . . . . 244
203 Licença do host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
204 Host lockdown mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
205 VM location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
206 Detalhes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
207 Adicionando datacenter VMWare . . . . . . . . . . . . . . . . . . . . 246
208 Configurando datacenter VMWare no Apache CloudStack . . . . . 247
209 Acessando os detalhes das redes físicas do Apache CloudStack . . 247
210 Atualizando as redes . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
211 Adicionando o mapeamento de redes do VMWare no Apache Cloud-
Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
212 Configurando o cluster VMWare no Apache CloudStack . . . . . . . 250
213 Mensagem de erro da tag na UI ao tentar adicionar o vCluster . . 251
214 Seleção da zona no vCenter . . . . . . . . . . . . . . . . . . . . . . . 252
215 Deleção do atributo cloud.zone . . . . . . . . . . . . . . . . . . . . . 253
216 Selecionando e apagando vCluster da database . . . . . . . . . . . 254
217 Acessando a view de Tools para fazer o import das VMs . . . . . . . 255
218 Vendo as VMs do cluster VMWare . . . . . . . . . . . . . . . . . . . 255
219 Importando uma VM para o Apache CloudStack . . . . . . . . . . . 256
220 Detalhes do import da VM . . . . . . . . . . . . . . . . . . . . . . . . 256
221 VM importada com sucesso . . . . . . . . . . . . . . . . . . . . . . . 257
17
Lista de Tabelas
1 Parâmetros createGuiTheme . . . . . . . . . . . . . . . . . . . . . . 120
2 Parâmetros listGuiThemes . . . . . . . . . . . . . . . . . . . . . . . 121
3 Parâmetros updateGuiTheme . . . . . . . . . . . . . . . . . . . . . 122
4 Atributos jsonconfiguration . . . . . . . . . . . . . . . . . . . . . . . 124
5 Atributos do plugin da jsonconfiguration . . . . . . . . . . . . . . . 124
6 Usage types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
18
Notas
• Este documento não abrange todos os tópicos, assuntos ou casos de uso
do Apache CloudStack. Portanto, caso não encontre o que está procu-
rando, faça uma solicitação de ajuste ou inclusão via GitLab.
• Este documento é atualizado periodicamente. Portanto, fique atento a
novas atualizações.
19
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 alterna-
tivas opensource 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, sendo algu-
mas delas: USP, UNICAMP, Dell, Deutsche Telekom, Apple, Planetel, Locaweb e
muitas outras.
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. Atualmente a SC Clouds atua auxiliando na gerência, planejamento, im-
plantação, suporte, correção de bugs e implementação de novas funcionalida-
des para empresas na Alemanha, Brasil, Itália, México e Suiça.
20
1.1. 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
no provimento de recursos de infraestrutura como serviço.
Figura 1: Computação em nuvem
1.1.1. Funcionalidades básicas
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:
21
• 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, VxLANS (Overlay Networks) e novas topologias;
– Definição de políticas de acesso e roteamentos;
– Gestão de 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;
– 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 SAML2 e OpenID Connect;
22
• Containers como serviço.
Das funcionalidades básicas de um sistema de orquestração de nuvem, o
Apache CloudStack possui limitações em relação a sistemas federados, visto
que suporta somente o protocolo SAML2.
1.2. História do Apache CloudStack
O projeto CloudStack teve seu início em 2008 como um projeto da startup
conhecida como VMOps. A companhia mudou seu nome para Cloud.com e
lançou uma versão estável do CloudStack em 2010, sob a licença GNU GPLv3
(General Public License version 3). Em 2011, a Cloud.com foi adquirida pela
Citrix, e em 2012 o projeto foi doado à fundação Apache. O CloudStack vem
crescendo nos últimos anos e tem se tornado uma ferramenta de orquestra-
ção de referência, sendo utilizado por diversas organizações, como a Globo,
RNP, UNICAMP, Universidade de São Paulo, Locaweb, CGEE, Apple, Dell, Nokia
e Disney.
23
2. Conceitos básicos do Apache CloudStack
Essa seção tem como objetivo apresentar conceitos básicos do Apache Cloud-
Stack, a sua organização lógica e os componentes que estruturam o orquestra-
dor.
A arquitetura do CloudStack está preparada para escalonamento tanto ver-
tical (aumento dos recursos de uma máquina) quanto horizontal (adição de
novas máquinas, sejam Management Servers ou CloudStack Agents).
Implantação com tolerância à falha
Balanceador
de carga 01
Balanceador
de carga 02
Management
Server 01
Management
Server 02
Management
Server 03
MariaDB
Galera 01
MariaDB
Galera 02
Interface
gráfica, CLI,
Rest API
Interface
gráfica, CLI,
Rest API
MariaDB
Galera 03
Figura 2: Exemplo de arquitetura do Apache CloudStack com tolerância à falhas
Um projeto mínimo de implantação do CloudStack consiste em Control Plane,
Compute Plane e Data Plane.
2.1. Control Plane
O Control Plane refere-se à camada composta de um conjunto de serviços
responsáveis por manter o controle dos recursos disponíveis na nuvem, como
servidores físicos, armazenamento e switches de rede. Além disso, é no Control
Plane que são realizadas as configurações e gerência de redes virtuais, rotea-
mento e load balancer. Entre os componentes básicos para a implantação do
Control Plane temos:
• Management Server: responsável pela gerência e orquestração dos re-
cursos disponíveis na infraestrutura, além de ser o responsável pelas APIs
REST e uma interface web para o gerenciamento. Pode ser duplicado/re-
plicado para prover uma estrutura de alta disponibilidade para API e UI,
24
porém, é necessário o uso de web proxy para esse setup e sticky session
para a UI.
• Load balancer: o CloudStack permite o uso de load balancer que provê
um IP virtual para realizar a distribuição da carga entre os Management
Servers e permitir o uso de sticky sessions. O administrador de ambiente
é responsável por criar as regras de load balancer para os Management
Servers de acordo com as necessidades do ambiente.
• Banco de dados: o CloudStack utiliza várias configurações que determi-
nam como a nuvem será gerenciada. Essas configurações são salvas em
um banco de dados (MariaDB ou MySQL), o qual pode ser manipulado
por usuários administradores
1
.
• Galera Cluster: no contexto de clustering de banco de dados, o Galera
Cluster é um cluster multi-primary de replicação virtual síncrona. Por ofe-
recer a funcionalidade de replicação síncrona e permitir a leitura e escrita
em qualquer nó do cluster, o Galera surge como uma forma de garantir
tolerância a falha e consistência entre todos os nós do banco de dados.
• Usage Server (opcional): além dos componentes essenciais para a implan-
tação, o Usage Server é um serviço opcional responsável por processar os
eventos de consumo de recursos na infraestrutura para possibilitar a co-
brança dos mesmos por agentes externos. Esse tópico será detalhado na
seção 6.1.
2.2. Compute Plane
O Compute Plane é estrutura responsável por sustentar a infraestrutura
oferecida como serviço, atuando na alocação de recursos computacionais e
1
Não recomendamos realizar alterações no banco de dados sem supervisão de um mem-
bro da SC Clouds ou conhecimento prévio, pois esse tipo de alteração pode ocasionar incon-
sistências nos fluxos e processos do CloudStack.
25
distribuição a carga de trabalho entre os hosts disponíveis no ambiente. É o
Compute Plane que lida com a criação, migração e monitoramento das VMs.
Servidores físicos destinados a esse serviço devem suportar virtualização, pois
neles serão alocadas as VMs criadas.
• CloudStack Agent: necessário apenas quando utilizando o hypervisor KVM,
o CloudStack Agent realiza a conexão entre o Management Server e o
KVM.
2.3. Data Plane
O Data Plane é um conjunto de elementos responsáveis pelo gerenciamento
de storages (appliances ou quando utilizados SDSs, e.g. Ceph/RBD). Os princi-
pais conceitos sobre storages serão abordados na seção 3.13.
2.4. Organização lógica do Apache CloudStack
A organização lógica utilizada pelo CloudStack pode ser dividida em:
• Region: maior unidade de implementação de uma nuvem. Agrupa uma
ou mais zones.
• Zone: representa um único datacenter que é composto por um ou mais
pods e secondary storages.
• Pod: representa um único rack no datacenter.
• Cluster: consiste em um ou mais hosts homogêneos e que compartilham
o mesmo primary storage. Idealmente, os hosts possuem a mesma família
de processadores, nivelado pelas funcionalidades da geração mais antiga.
• Host: um servidor onde serão executadas as VMs dos usuários. Em caso
de utilização do KVM como virtualizador, também possuirá o CloudStack
Agent instalado.
26
• Primary Storage: pode operar a nível host, cluster e zone. Ele é responsável
por armazenar os discos (também chamados de volumes) utilizados pelas
VMs.
• Secondary storage: opera a nível de zone, armazenando os templates das
VMs, ISOs, backups e snapshots.
Figura 3: Organização lógica do Apache CloudStack
Na figura 3, pode-se visualizar a hierarquia do ACS, na qual é possível obser-
var que o componente mais externo da estrutura é uma região que agrupa uma
ou mais zonas. As zonas, por sua vez, representam um datacenter composto
por pods, e estes são compostos por clusters que, por sua vez, são compostos
por hosts, os quais atuam como nós de processamento ativo.
2.5. Componentes do Apache CloudStack
A estrutura do CloudStack é formada pelos seguintes componentes:
1. Management Servers;
2. Hosts;
27
3. Network: rede que conecta os componentes do ACS. É recomendado fazer
uso de segregação de redes, de forma física e/ou virtual (via broadcast
domain), provendo mais segurança;
4. Primary storage;
5. Secondary storage;
6. Virtual router: System VM que emula um roteador, implementando os ser-
viços das redes guest. Possibilitando, por exemplo, acesso à internet;
7. Console proxy virtual machine: System VM responsável por apresentar uma
visão do console de uma VM qualquer via interface web;
8. Secondary storage virtual machine: System VM responsável por gerenciar os
secondary storages de uma zona. Disponibiliza funções como, por exem-
plo, download, registro e upload de volumes, templates e ISOs.
28
3. Funcionalidades do Apache CloudStack
Nessa seção serão introduzidas, de forma breve, as principais funcionalida-
des do Apache CloudStack voltadas para a operação do ambiente (usuários Ro
otAdmin) e como utilizá-las. Para informações voltadas ao consumo da plata-
forma como usuário final, consulte o documento Consumo da nuvem Apache
CloudStack.
3.1. Dashboard inicial
Esse é o dashboard padrão do Apache CloudStack, onde é possível visualizar
detalhes da infraestrutura.
Figura 4: Dashboard inicial
3.2. Configurações da VM
As VMs possuem configurações gerais e configurações específicas para o hy-
pervisor. É recomendado que certas configurações sejam mantidas para evitar
problemas, como as de uso interno.
Esta seção apresentará configurações que estão disponíveis apenas a nível
de operação. Para configurações de VMs disponíveis a nível de uso, acesse o
documento de uso do Apache CloudStack.
29
Para editar as configurações de uma VM, é necessário, primeiramente, pa-
rar a mesma. Em seguida, as configurações da VM podem ser modificadas
acessando a aba Settings.
Figura 5: Aba de configurações da VM
3.2.1. Configurações gerais
Configuração Descrição.
rootdisksize Define o tamanho do root disk da VM. Se a service offe-
ring tem o tamanho do root disk configurado, este pa-
râmetro é sobrescrito pela service offering.
rootDiskController Define o controlador de disco usado pelo root disk da
VM.
dataDiskController Define o controlador de disco usado pelos data disks da
VM.
nameonhypervisor Define o nome da VM no hypervisor.
30
3.2.2. Configurações diversas para uso interno
Configuração Descrição
cpuOvercommitRatio Define a relação de superalocação
de CPU que permite que mais nú-
cleos de CPU sejam atribuídos do
que estão fisicamente disponíveis
na máquina host.
memoryOvercommitRatio Define a relação de superalocação
de memória que permite que mais
memória seja atribuída do que está
fisicamente disponível na máquina
host.
Message.ReservedCapacityFreed.Flag Flag interna usada para indicar se os
recursos reservados para uma VM
foram liberados.
3.2.3. Configurações de VM específicas para KVM
Configuração Descrição
kvm.vnc.port Define a porta VNC usada pela VM em um ambiente KVM.
kvm.vnc.address Define o endereço IP usado para acessar a VM via VNC
em um ambiente KVM.
video.hardware Define o adaptador de vídeo virtual usado pela VM.
video.ram Define a quantidade de RAM de vídeo disponível para a
VM.
hline io.policy Define estratégia usada para tratar dados de E/S.
hline iothreads Permite o uso de threads específicas para E/S.
Ao adicionar a configuração video.hardware com o valor virtio, VMs Win-
dows passam a utilizar o driver do VirtIO possibilitando novas resoluções para
o console da VM. Mais informações relacionadas ao KVM podem ser encontra-
das na Seção 8.
31
3.2.4. Configurações de VM específicas para VMWare
Configuração Descrição
svga.vramSize Define a quantidade de memória de vídeo dispo-
nível para a VM.
nestedVirtualizationFlag Ativa ou desativa a virtualização aninhada dentro
da VM.
ramReservation Define a quantidade mínima de RAM alocada para
a VM.
Mais informações relacionadas ao KVM podem ser encontradas na seção 9.
3.2.5. Configurações específicas para uso interno do XenServer
Configuração Descrição
hypervisortoolsversion Define a versão do hypervisor usado pela VM.
platform Define o tipo de plataforma em que a VM está
sendo executada, como Linux ou Windows.
timeoffset Define o fuso horário da VM.
3.2.6. Configurações específicas para Mac OSX - Guest
Configuração Descrição
smc.present Ativa ou desativa o suporte a SMC na VM.
firmware Define o firmware utilizado pela VM.
3.2.7. Configurações globais para VMs
Além das configurações que afetam cada VM individualmente, o Apache
CloudStack disponibiliza algumas configurações globais relacionadas a VMs, de
forma a customizar o ambiente como um todo.
3.2.7.1. Restrição de acesso ao usuário
É possível restringir que contas do tipo user modifiquem certas configurações
das VMs. Existem duas opções de restrição, que são definidas através das se-
guintes configurações globais:
• user.vm.denied.details: impede a adição, edição e visualização de confi-
gurações;
32
• user.vm. readon ly. det ails: impede a adição e edição de configurações,
mas elas continuam visíveis aos usuários na aba de Settings.
Figura 6: Configurações globais
3.2.7.2. Metadados de configurações extras
É possível adicionar propriedades extras ao deployment de uma VM, contanto
que a configuração enable.additional.vm.configuration esteja habilitada (é pre-
ciso reiniciar o Management Server para que mudanças nesta configuração te-
nham efeito).
O administrador da nuvem pode, então, definir nas configurações globais a
seguir quais comandos os usuários podem adicionar nas suas VMs, de acordo
com os seus respectivos hypervisors.
• allow.additional.vm.configuration.list.kvm
Configurações adicionais para o KVM devem ser no formato XML, codifi-
cado como URL. Por exemplo:
<memoryBacking>
<hugepages/>
</memoryBacking>
Em URL:
%3CmemoryBacking%3E%0D%0A++%3Chugepages%2F%3E%0D%0A%3C%2FmemoryBacking%3E
• allow.additional.vm.configuration.list.vmware
Configurações adicionais para o VMware são pares chave=valor, codifica-
dos como URL. Por exemplo:
33
hypervisor.cpuid.v0=FALSE
Em URL:
hypervisor.cpuid.v0%3DFALSE
• allow.additional.vm.configuration.list.xenserver
Configurações adicionais para o XenServer são parâmetros do comando
vm-param-set, no formato de pares chave=valor, codificados como URL.
Por exemplo:
HVM-boot-policy=
PV-bootloader=pygrub
PV-args=hvc0w
Em URL:
HVM-boot-policy%3D%0APV-bootloader%3Dpygrub%0APV-args%3Dhvc0
3.2.7.3. Retenção de estatísticas das VMs
A retenção de estatísticas das VMs é regida por duas configurações globais:
• vm.sta ts.i nte rval: intervalo, em milissegundos, entre cada coleta. O valor
padrão da configuração é de 60000 milissegundos, equivalente a 1 mi-
nuto.
• vm.stats.max.retention.time: tempo de retenção, em minutos, dos dados
no banco de dados. O valor padrão da configuração é de 720 minutos,
equivalente a 12 horas.
A partir do valor definido nessas configurações, pode-se calcular a quanti-
dade máxima de registros de estatísticas presentes no banco de dados com a
seguinte fórmula:
espacoArmazenamento =
(retencao · 60000)
intervalo
· MSs · V Ms · tamanhoRegistro
• espacoArmazenamento: espaço, em bytes, necessário para armazenar
as estatísticas das VMs;
34
• retencao: valor da configuração vm.stats.max.retention.time;
• intervalo: valor da configuração vm.stats.interval;
• MSs: quantidade de Management Servers rodando no ambiente;
• VMs: quantidade de VMs rodando no ambiente;
• tamanhoRegistro: tamanho estimado, em bytes, de cada registro no banco
de dados.
Portanto, em um ambiente com 2 Management Servers e 1000 VMs, no qual
o tempo de retenção é de 10 minutos, o intervalo entre coletas é de 30 segun-
dos e o tamanho de cada registro é 400 bytes, a quantidade máxima de registros
no banco de dados será de 16 MB:
(10 · 60000)
30000
· 2 · 1000 · 400 = 16000000B = 16M B
Além disso, é possível acompanhar o crescimento físico da tabela com o
seguinte comando no banco de dados:
SELECT TABLE_NAME AS 'Tabela',
DATA_LENGTH AS 'Tamanho dos dados (B)',
INDEX_LENGTH AS 'Tamanho dos indices (B)',
ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024) AS 'Tamanho total (KiB)'
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'cloud'
AND TABLE_NAME = 'vm_stats';
Figura 7: Exemplo de retorno da query com o tamanho total da tabela vm_stats
Destaca-se, ainda, que o banco de dados MySQL apresenta alterações nos
valores a cada 16 KiB de dados. Com isso, considerando que cada registro
tenha um tamanho de 400 bytes, alterações nos valores serão observadas a
cada 40 registros, aproximadamente.
35
3.3. Gerência de volumes
Nessa seção serão abordados procedimentos relacionados com o cunho
operacional de gerência de volumes no ACS
2
.
3.3.1. Migração de volume com VM parada (migração a frio)
Por padrão, essa operação é permitida apenas para usuários root admin.
É importante notar que o host da VM deve ter acesso ao storage destino do
volume.
Figura 8: Migrando volume
2
Os demais procedimentos relacionados à gerência de volumes podem ser encontrados
no documento de uso do Apache CloudStack.
36
Figura 9: Confirmar a ação
3.3.2. Migração de volume com VM rodando (migração a quente)
Por padrão, essa operação é permitida apenas para usuários root admin.
Caso o hypervisor utilizado seja o KVM, para fazer migração de volume a quente,
é necessário migrar também a VM a qual o volume pertence. Mais detalhes
sobre as limitações da migração a quente encontram-se no próximo item.
Figura 10: Migrando a VM
37
Figura 11: Configurar a migração
3.3.3. Migração de volume via CLI
Existem duas situações possíveis para migração de volumes: migração de
volumes com a VM parada (migração a frio) e migração de volumes com a VM
rodando (migração a quente).
Na migração de volume a frio, o volume é primeiro copiado para o secondary
storage e depois para o primary storage. Enquanto na migração a quente, o
volume é migrado diretamente para o primary storage alvo, o que a torna mais
rápida e menos custosa para o ambiente.
Para migrar um volume a frio, basta usar o seguinte comando:
migrate volume volumeid=<id_do_volume> storageid=<id_do_storage_destino>
Já para fazer migração de volumes a quente, alguns detalhes são importan-
tes:
38
• Caso o hypervisor utilizado seja o VMware ou XenServer, basta utilizar o co-
mando explicado acima. Contudo, caso o hypervisor utilizado seja o KVM,
é necessário realizar uma migração de VM entre hosts em conjunto. O hy-
pervisor KVM possui uma feature chamada live block copy, a qual permite
migrar os volumes de uma VM rodando para outro storage sem a neces-
sidade de realizar a migração da VM para outro host. Após a migração,
o XML e o processo da VM são atualizados apontando para o novo sto-
rage. No entanto, essa funcionalidade não é utilizada no ACS atualmente.
Dessa forma, o ACS possui uma limitação que impede a migração apenas
dos volumes das VMs em execução no KVM; por consequência, a migra-
ção de volumes entre storages enquanto a VM está executando precisa ser
realizada em conjunto com uma migração da VM entre hosts, para que o
XML e o processo da VM sejam atualizados.
• Existe um problema conhecido no XFS, onde o mesmo pode acabar tendo
a partição corrompida durante a migração de hosts, sendo necessário,
nesse caso, executar um processo para recuperar esses volumes;
• Caso a VM possua data disks muito grandes, deve-se verificar as configu-
rações de timeout do ACS, uma vez que, volumes muito grandes podem
causar um timeout, resultando na falha do processo de migração;
• O KVM possui algumas configurações de timeout no que tange a migração
de VMs. Caso a VM possua uma quantidade muito grande de memória
RAM, o processo de migração pode falhar.
As principais configurações globais que afetam a migração são:
•
enable.storage.migration: Habilita a migração de volumes;
• secstorage.m ax.migrate.sessions: Máximo de tarefas de cópia de dados
que uma SSVM pode executar concorrentemente;
39
• secstorage.session.max: Máximo de requisições que uma SSVM pode ter
enfileirada. Quando este número é ultrapassado, uma nova SSVM é cri-
ada. Além disso, quando o número de requisições está longe desse valor
e existem SSVMs inativas, as mesmas serão destruídas;
• sto rage.pool.max.waitseconds: Timeout de espera de sincronização de
operações do storage pool;
• migratewait: Timeout de migração de VM. Após esse limite de tempo, a
migração é cancelada;
• kvm.storage.offline.migration.wait: Timeout de migração a frio de volume
(apenas para KVM), e
• k v m .storage.online.migration .wait: Timeout de migração a quente de vo-
lume (apenas para KVM).
As configurações do agente KVM podem ser alteradas no seguinte arquivo:
/etc/cloudstack-features/age n t / ag e n t. p r o pe r t ie s, sendo que as principais con-
figurações que afetam a migração são:
• vm.migrate.pauseafter: Tempo de espera para a migração a quente com-
pletar. Após esse limite, a VM é pausada para completar a migração;
• vm.migrate.downtime: Tempo que a VM ficará pausada para completar a
migração, e
• vm.migrate.speed: Velocidade (em MB/s) da migração. Por padrão, o ACS
tenta estimar a velocidade de transferência da rede.
Para realizar a migração de volume e VM, utilize o comando:
migrate virtualmachinewithvolume virtualmachineid=<id_da_vm> hostid=<id_do_host_destino> \
migrateto[0].volume=<id_do_volume> migrateto[0].pool=<id_do_storage_alvo>
40
3.3.4. Importação de volume para outra zona ou conta
Há situações nas quais é necessário importar volumes para outras zonas
e/ou contas. Via UI, isso é possível da seguinte forma:
1. Adquira o link de download de volume
3
;
2. Copie a URL e cole no campo URL do upload de volume via URL
4
;
3. Configure o volume para pertencer à zona e/ou conta desejadas.
Também é possível fazer esse procedimento via API. Para isso, siga os pas-
sos:
1. Utilize o seguinte comando para gerar a URL:
extract volume zoneid=<id_da_zona> id=<id_do_volume> mode=HTTP_DOWNLOAD
2. Para realizar a importação, utilize o comando
5
:
upload volume zoneid=<id_da_zona_destino> name=<nome_do_volume> format=<formato_do_volume> \
url=<URL_gerada_anteriormente> domainid=<id_do_dominio_destino> account=<nome_da_conta_destino>
3.4. Virtual router
Esta seção irá tratar exclusivamente de operações com virtual router. Para
informações relacionadas à rede guest, acesso o documento de uso do Apache
CloudStack.
Quando uma VM que utiliza as redes isolated e shared é criada, o Apache
CloudStack automaticamente cria um virtual router para elas.
3
Mais informações podem ser encontradas na seção Download de volume do documento
de uso do Apache CloudStack.
4
Mais informações podem ser encontradas na seção Upload de volume on-line via URL do
documento de uso do Apache CloudStack.
5
Os parâmetros domainid e account são opcionais, porém o parâmetro account depende
do domainid.
41
Figura 12: Indo até a aba de virtual routers
Figura 13: Verificando se o VR foi corretamente criado
42
3.4.1. Parada do virtual router
Figura 14: Navegando até os virtual routers
Figura 15: Parando o virtual router
43
Figura 16: Confirmando a ação
Aqui é importante prestar atenção na opção Force. Se selecionada, VMs que
utilizam esse router serão forçadas a parar. A recomendação é que essa opção
só seja utilizada caso tentar parar o router tenha resultado em erro.
Figura 17: Confirmando que o virtual router parou
3.4.2. Reinicialização do virtual router
Figura 18: Reiniciando o virtual router
44
3.4.3. Destruição de virtual router
É possível destruir um VR, mas o mesmo será recriado se a rede for rei-
niciada. Ao destruir um VR, todos os serviços por ele proporcionados serão
interrompidos, assim, caso existam VMs rodando que o utilizem, as mesmas
podem apresentar erros e falhas.
Figura 19: Destruindo o virtual router
Figura 20: Confirmando a ação
Figura 21: Confirmando a remoção do virtual router
3.4.4. Definição de offering padrão do virtual router
Na criação de uma nova rede, existe um fluxo bem estabelecido pelo Cloud-
Stack para definir qual offering (seção 3.11) o VR utilizará, sendo determinada
45
através dos seguintes passos:
1. Caso na network offering usada na criação da rede seja especificada uma
service offering, essa será utilizada na criação do VR. Do contrário, será
verificado o passo seguinte;
2. Caso a configuração router. service.offering, à nível de account, defina a
offering, essa será utilizada na criação do VR. Do contrário, será verificado
o passo seguinte;
3. Caso a configuração global router.service.offering defina a offering, essa
será utilizada na criação do VR. Do contrário, será verificado o passo se-
guinte;
4. A system offering default será utilizada (System Offering For Software Router
ou System Offering For Software Router - Local Storage).
Figura 22: Fluxo para definir offering padrão do virtual router
É importante verificar que, caso uma rede já existente seja atualizada para
usar uma nova network offering, ou uma rede seja reiniciada com clean up, os
VRs novos também seguirão esse mesmo fluxo para definir qual offering será
utilizada.
46
3.5. IPs públicos
Esta seção irá abordar apenas os tópicos relevantes a nível de operação de
IPs públicos. Para mais informações, acesse o documento de uso do Apache
CloudStack.
3.5.1. IP público reservado para system VMs
O CloudStack trabalha com IPs reservados para system VMs. Eles não são
restritos, portanto, caso só existam IPs públicos reservados para system VMs
livres, o ACS irá utilizá-los para VMs de usuários. Para alterar este comporta-
mento do ACS e restringir IPs públicos reservados para system VMs apenas para
elas, é necessário alterar a configuração global system.vm.public.ip.reservat io
n.mode.strictness para true.
3.6. Suporte a IPv6
O ACS tem suporte a IPv6 para redes shared e isolated, como também tiers
de VPCs. Atualmente, não é possível criar nenhuma das redes mencionadas
apenas com IPv6, todas precisam ser criadas com IPv4 + IPv6 dual-stack. As
próximas subseções detalham os requisitos e limitações em relação ao suporte
às redes shared e a redes isoladas/tiers de VPCs.
3.6.1. Redes isoladas e tiers de VPCs
Atualmente, o ACS apenas dá suporte a IPv6 através da configuração via
SLAAC, não suportando DHCPv6 stateless e stateful, sendo necessário adicionar
as rotas manualmente no roteador de borda para cada rede criada no ambi-
ente. A adição das rotas no roteador de borda só deverá ser realizada após a
criação da rede via ACS. Além disso, as redes públicas são alocadas utilizando
um bloco /64 inteiro para IPv6, sendo necessário que o prefixo seja menor ou
igual a /64. Os seguintes passos são obrigatórios para habilitar IPv6 em redes
isoladas/tiers de VPCs:
1. Habilitar a configuração global ipv6.offering.enabled.
47
2. Adicionar intervalo de IPv6 para a rede pública.
Figura 23: Iniciando a adição do intervalo IPv6 para a rede pública
Figura 24: Adicionando um intervalo IPv6 para a rede pública
Figura 25: Um prefixo /52 permite 4096 subredes IPv6 com bloco /64
48
3. Adicionar o prefixo IPv6, o mesmo deve ser menor ou igual que um /64.
Figura 26: Iniciando a adição do intervalo IPv6 para a rede guest
Figura 27: Adicionando um intervalo de IPv6 para a rede guest
Além disso, é necessário que sejam criadas ofertas para VPCs e para seus
tiers, especificando ambos os protocolos; o mesmo vale para as redes isoladas.
Abaixo, é apresentado o passo-a-passo para criação de tiers com suporte a IPv6.
1. Criar oferta de VPC com suporte a IPv6.
49
Figura 28: Criando oferta para VPCs com suporte a IPv6
2. Criar oferta de rede para tiers com suporte a IPv6.
Figura 29: Criando oferta para tier de VPCs com suporte a IPv6
50
3. A VM alocada à rede irá utilizar o protocolo SLAAC, atribuindo um IPv6
não utilizado para ela mesma.
Figura 30: Validação da autoconfiguração do IPv6 da VM (via SLAAC)
4. No roteador de borda, será necessário adicionar as rotas informadas via
UI ou via API.
Figura 31: Apresentação na UI das rotas que deverão ser adicionadas no roteador de borda
Figura 32: Apresentação via API das rotas que deverão ser adicionadas no roteador de borda
O processo para redes isoladas é similar, diferindo apenas no processo de
criação da oferta de rede.
51
1. Criar oferta de rede isolada com suporte a IPv6.
Figura 33: Criando oferta para rede isolada com suporte a IPv6
2. A VM alocada à rede irá utilizar o protocolo SLAAC, atribuindo um IPv6
não utilizado para ela mesma.
Figura 34: Validação da autoconfiguração do IPv6 da VM (via SLAAC)
3. No roteador de borda, será necessário adicionar as rotas informadas via
UI ou via API.
52
Figura 35: Apresentação na UI das rotas que deverão ser adicionadas no roteador de borda
Figura 36: Apresentação via API das rotas que deverão ser adicionadas no roteador de borda
3.6.2. Redes shared
Diferente de redes isoladas e tiers de VPCs, não é necessário realizar ne-
nhuma configuração pelo lado do ACS para utilização de redes shared com
IPv6, basta criar uma rede com o tipo shared especificando o gateway, CIDR e
a faixa de IPs utilizados pela rede. É necessário especificar essas informações
para ambas versões do protocolo IP, pois, atualmente, não é possível criar uma
rede utilizando apenas IPv6.
A gestão de redes shared é realizada diretamente no roteador da rede, sendo
realizada a parte da plataforma do ACS. As VMs também utilizarão o protocolo
SLAAC para a autoconfiguração do IPv6, dessa forma, é preciso que o gateway
53
esteja com o serviço de Router Advertisements habilitado, informando o prefixo
da rede IPv6. Com essas informações, a própria VM irá obter um IP válido na
rede. Abaixo, é apresentado um exemplo de criação de uma rede shared dual-
stack.
Figura 37: Criação de uma rede shared com os dados do IPv4
Figura 38: Criação de uma rede shared com os dados do IPv6
54
3.7. Host, storage e network tags
Host tags e storage tags, apesar do nome, não possuem relação com resource
tags e são uma funcionalidade para direcionar alocação de recursos, como em
qual host será feito deploy da VM ou em qual storage será criado o volume.
Existem diversos motivos para utilização de tags (como direcionar o volume
para um storage de melhor qualidade, de acordo com a offering). Cada tipo de
recurso possui um comportamento diferente para as tags.
Figura 39: Campos para atualizar storage tags e host tags de uma compute offering
3.7.1. Host tags
Host tags são responsáveis por direcionar as VMs para os hosts compatíveis.
Elas são validadas com as host tags informadas nas compute offerings (seção
3.11.1) ou nas system offerings (seção 3.12.1).
Para explicar o comportamento das host tags, serão demonstrados alguns
exemplos com dois hosts (Host1 e Host2):
1. Organização das tags:
• Host1: h1
• Host2: h2
• Offering: h1
55
Ao ser criada uma VM com a offering, o deploy será realizado no Host1,
pois é ele que possui a tag compatível com a da offering.
2. Organização das tags:
• Host1: h1
• Host2: h2,h3
• Offering: h3
Os hosts aceitam uma lista de tags, sendo a vírgula (,) o separador delas.
Portanto, nesse exemplo, o Host2 possui as tags h2 e h3. Ao ser criada
uma VM com a offering, o deploy será realizado no Host2, pois é ele que
possui a tag compatível com a da offering.
3. Organização das tags:
• Host1: h1
• Host2: h2,h3
• Offering: h2,h3
Diferente dos hosts, as offerings não aceitam uma lista de host tags, por-
tanto, nesse exemplo, na offering, h2,h3 é apenas uma tag. Nenhum dos
hosts possui tags compatíveis e não será possível realizar o deploy de uma
VM com a offering. Contudo, o CloudStack ignora esse comportamento
quando um host é manualmente selecionando e permite realizar o deploy.
4. Organização das tags:
• Host1: h1
• Host2: h2,h3
• Offering: (sem tag)
Quando a offering não possui tags, será possível realizar o deploy da VM
em qualquer host.
5. Organização das tags:
56
• Host1: (sem tag)
• Host2: h2
• Offering: h3
Nenhum dos hosts possui tags compatíveis e não será possível realizar
o deploy de uma VM com a offering. Contudo, o CloudStack ignora esse
comportamento quando um host é manualmente selecionando e permite
realizar o deploy.
Exemplo Host tags Offering tag Comportamento
1 Host1: h1
Host2: h2
h1 Deploy no Host1
2 Host1: h1
Host2: h2,h3
h3 Deploy no Host2
3 Host1: h1
Host2: h2,h3
h2,h3 Não será feito o deploy, a não
ser que seja selecionado um
dos hosts
4 Host1: h1
Host2: h2,h3
(sem tag) Deploy em qualquer host
5 Host1: (sem tag)
Host2: h2
h3 Não será feito o deploy, a não
ser que seja selecionado um
dos hosts
3.7.2. Storage tags
Storage tags são responsáveis por direcionar os volumes para os primary
storages compatíveis. Elas são validadas com as storage tags informadas nas
disk offerings
6
, compute offerings (seção 3.11.1) ou system offerings (seção 3.12.1).
Para explicar o comportamento das storage tags, serão demonstrados al-
guns exemplos:
1. Organização das tags:
• Storage: A
6
Informações sobre disk offerings podem ser encontradas na documentação de uso do Apa-
che CloudStack.
57
• Offering: A,B
O storage e a offering aceitam uma lista de tags, sendo a vírgula (,) o se-
parador delas. Portanto, nesse exemplo, a offering possui as tags A e B.
Nesse exemplo não será possível alocar o volume, pois todas as tags da
offering precisam existir no storage. Apesar de o storage ter a tag A, ele
não tem a tag B.
2. Organização das tags:
• Storage: A,B,C,D,X
• Offering: A,B,C
Nesse exemplo será possível alocar o volume, pois todas as tags da offe-
ring existem no storage.
3. Organização das tags:
• Storage: A,B,C
• Offering: (sem tag)
Nesse exemplo será possível alocar o volume, pois a offering não possui
nenhum requisito de tag.
4. Organização das tags:
• Storage: (sem tag)
• Offering: D,E
Nesse exemplo não será possível alocar o volume, pois o storage não pos-
sui tags, portanto não completa os requisitos da offering.
Exemplo Storage tags Offering tags Comportamento
1 A A,B O volume não será alocado
2 A,B,C,D,X A,B,C O volume será alocado
3 A,B,C (sem tag) O volume será alocado
4 (sem tag) D,E O volume não será alocado
58
Em resumo, se a offering possuir tags, o storage precisará ter todas as tags
para que o volume seja alocado. Caso a offering não possua tags, o volume
poderá ser alocado, independente do storage ter tag ou não.
3.7.3. Network tags
Network tags são responsáveis por direcionar as redes virtuais para as re-
des físicas compatíveis. Elas são validadas com as network tags informadas nas
network offerings
7
.
Serão demonstrados alguns exemplos para explicar o comportamento das
network tags:
1. Organização das tags:
• Physical network: A
• Offering: A,B
A physical network e a offering não aceitam uma lista de tags, ou seja, só
é possível atribuir uma única tag para cada recurso. Nesse caso, o valor
A,B atribuído na offering é apenas uma tag. Como a tag da offering e da
physical network são diferentes, não será possível direcionar a rede virtual
para a rede física.
2. Organização das tags:
• Physical network: B
• Offering: B
Nesse exemplo, a physical network e a offering possuem a mesma tag, por-
tanto será possível direcionar a rede virtual para a rede física.
3. Organização das tags:
• Physical network: C
7
Informações sobre network offerings podem ser encontradas na documentação de uso do
Apache CloudStack.
59
• Offering: (sem tag)
Será possível direcionar a rede virtual para a rede física, pois a offering
não possui nenhum requisito de tag.
4. Organização das tags:
• Physical network: (sem tag)
• Offering: D
Não será possível direcionar a rede virtual para a rede física, pois a physi-
cal network não possui tag e, consequentemente, não completa os requi-
sitos da offering.
Exemplo Network tag Offering tag Comportamento
1 A A,B Direcionamento não será feito
2 B B Direcionamento será feito
3 C (sem tag) Direcionamento será feito
4 (sem tag) D Direcionamento não será feito
Em resumo, o direcionamento da rede virtual para a rede física só não será
possível caso a offering possua uma tag diferente da tag da physical network. Se
a offering não possuir tag, o direcionamento poderá ser feito, independente-
mente da physical network ter tag ou não.
3.7.4. Tags flexíveis
Ao definir tags para um recurso (um host, por exemplo), as offerings com
essas tags serão direcionadas para esse recurso. No entanto, offerings sem
tags também podem ser direcionadas a ele. De forma que, mesmo depois de
adicionar tags em um recurso com a intenção de torná-lo exclusivo para deter-
minados tipos de offerings, essa exclusividade pode ser ignorada.
Além disso, o sistema padrão de tags permite apenas que o usuário informe
uma simples lista de tags, sem a possibilidade de criar regras mais complexas,
como verificar se a offering possui determinados pares de tags.
60
Para contornar essas situações, o ACS permite que hosts e storages possam
ter tags que são regras escritas em JavaScript, também conhecidas como tags
flexíveis. Com as tags flexíveis, o papel de direcionamento de tags é invertido,
ou seja, ao invés do host ou storage precisar ter a tag da offering para o dire-
cionamento ser feito, a offering que precisará ter a tag do recurso para o qual
ela será direcionada. Essa inversão faz com que offerings sem tags não possam
ser direcionadas para qualquer recurso. Desse modo, operadores podem ter
um controle mais fino sobre o direcionamento das VMs e volumes dentro do
ambiente.
A informação das regras nos hosts é realizada através da API updateHos
t, informando a regra no campo hostta gs. Por outro lado, a informação das
regras nos storages é feita a partir da API updateStoragePo ol, informando a
regra no campo tags. Para que a tag informada seja efetivamente interpretada
como JavaScript, é preciso declarar o parâmetro istagarule como true sempre
que utilizar uma das APIs apresentadas.
Vale ressaltar que as tags da compute offering ou disk offering são injetadas
no formato de lista. Assim, ao validar uma offering com as tags A,B, no proces-
samento, haverá a variável tags, onde tags[0] será a tag A, e a tags[1] será a tag
B.
Exemplo de uso da API updateHost para atualizar um host com uma tag em
JS:
update host id=3d7d8532-d0cf-476c-a36e-1b936d780abb istagarule=true hosttags="tags[0] == 'Premium'"
Via UI:
• Selecione o host e clique em editar:
61
Figura 40: Acessando a edição do host
• Crie a tag flexível:
Figura 41: Criando a tag flexível no host
Exemplo de uso da API updateStoragePool para atualizar um primary storage
com uma tag em JS:
update storagepool id=dc916dc7-cc1c-3f3d-905b-b198daf15a79 istagarule=true tags="tags.length == 0 ||
tags[0] === 'test'"
62