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
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
Via UI:
• Selecione o primary storage e clique em editar:
Figura 42: Acessando a edição do primary storage
• Crie a tag flexível:
Figura 43: Criando a tag flexível no primary storage
63
É importante mencionar que as tags flexíveis não são compatíveis com as
regras de ativação do Quota.
3.8. Gerenciamento do deploy de instâncias com base em seus sistemas operacio-
nais
O Apache CloudStack provê duas funcionalidades para direcionar a aloca-
ção de instâncias com base em seus sistemas operacionais: preference OS e
flexible guest OS.
3.8.1. Preference OS dos hosts
Preference OS dos hosts é uma configuração que permite ao operador definir
um sistema operacional prioritário para um determinado host. Dessa forma,
hosts que tiverem essa prioridade configurada e possuírem o mesmo sistema
operacional da VM terão mais prioridade durante o processo de alocação. O
contrário também é válido, hosts que tiverem a configuração Preference OS defi-
nida e o sistema operacional da VM for diferente de seu valor, serão colocados
com menor prioridade em relação aos demais hosts do ambiente.
Entretanto, essa funcionalidade apenas define a ordem de prioridade de um
host durante a alocação, sendo permitido que VMs com sistema operacionais
divergentes das configurações dos hosts sejam alocadas a eles. Portanto, é
importante frisar que a configuração não possibilita o isolamento do host para
um determinado sistema operacional.
Para acessar a configuração via UI:
64
Figura 44: Acesso ao host a ser configurado
Figura 45: Acesso ao formulário de edição do host
Figura 46: Configuração da preference OS do host
65
3.8.2. Flexible guest OS
A funcionalidade flexible guest OS permite a criação de regras, escritas em
JavaScript, que filtrem instâncias com base em seus sistemas operacionais du-
rante o processo de alocação de VMs em um host. Portanto, a partir dessa
funcionalidade é possível dedicar um host para um ou vários sistemas opera-
cionais.
Para acessar a configuração via UI, acesse o formulário de edição do host:
Figura 47: Configuração da regra de guest OS do host
Para definição das regras, a variável vmGuestOs é disponibilizada e contém
o sistema operacional da instância a ser alocada, como uma string. Portanto,
para dedicar um host para VMs Windows, a seguinte regra pode ser adicionada:
vmGuestOs.toLowerCase().indexOf('windows') >= 0
Para dedicar o host para mais de um sistema operacional, pode-se utilizar
o operador lógico OR, || em JavaScript, como por exemplo:
// dedicar host para VMs Ubuntu e Debian
vmGuestOs.toLowerCase().indexOf('ubuntu') >= 0 ||
vmGuestOs.toLowerCase().indexOf('debian') >= 0
66
Também é possível adicionar regras para não permitir a alocação de instân-
cias de um determinado sistema operacional no host, como por exemplo:
// host aceita apenas VMs que não usam Ubuntu
vmGuestOs.toLowerCase().indexOf('ubuntu') === -1
3.9. Snapshots
Snapshots são pontos de recuperação de uma VM por completo ou apenas
de um disco. Elas podem ser utilizadas como uma forma de recuperação de fa-
lhas ou ainda para criação de template e novos volumes. Em alguns hypervisors,
como VMWare e KVM, elas se comportam como backups.
Nesta seção serão abordados apenas os tópicos a nível de operação. Para
informações relacionadas ao uso das Snapshots, veja a documentação de uso
do Apache CloudStack.
3.9.1. Configurações de snapshots
As principais configurações de snapshots são:
Configuração Descrição Valor padrão
max.account.snapshots Número máximo de
snapshots por account
20
max.domain.snapshots Número máximo de
snapshots por domain
Infinito
max.project.snapshots Número máximo de
snapshots por projeto
20
vmsnapshot.max Número máximo de
snapshots para uma VM
10
3.10. Auditoria de eventos e alertas
Eventos são gerados quando um usuário realiza alguma ação na nuvem ou
quando o estado de algum recurso, virtual ou físico, é alterado. Eventos base-
ados em política são chamados pelo CloudStack de alertas.
67
É possível utilizar os eventos para monitorar tasks, jobs ou processos do
CloudStack, incluindo possíveis erros, em cada um deles.
As principais configurações sobre eventos e alertas são:
Nome Descrição Valor Pa-
drão
event.purge.delay Dias até um evento criado ser removido.
O valor 0 indica que eventos nunca são
removidos
15
event.purge.interval Intervalo, em segundos, até ser criado
um job para remover eventos antigos
86400
∗
alert.purge.delay Dias até um alerta criado ser removido.
O valor 0 indica que alertas nunca são re-
movidos
0
alert.purge.interval Intervalo, em segundos, até ser criado
um job para remover alertas antigos
86400
alert.smtp.host Host no qual está rodando o servidor
SMTP
alert.smtp.password Senha do servidor SMTP
alert.smtp.port Porta do servidor SMTP
alert.smtp.username Usuário do servidor SMTP
alert.email.sender E-mail que aparecerá como emissor
alert.email.addresses Receptor dos e-mails, podendo ser uma
lista separada por vírgulas (,)
∗Valor, em segundos, de um dia inteiro.
3.10.1. E-mails de alertas
Por padrão, alertas, por serem considerados eventos críticos, podem ser
configurados para enviar e-mails para os administradores da nuvem. Os cená-
rios possíveis em que um e-mail de alerta será enviado para o administrador
da nuvem são:
• O Management Server está com pouca CPU, memória ou armazenamento;
• O Management Server está sem comunicação com um host por mais de
3 minutos;
• Um host está com pouca CPU, memória ou armazenamento.
68
3.10.2. Busca e filtro de alertas
Para visualizar e buscar os alertas na interface web é necessário:
Figura 48: Acessando os alertas
3.10.3. Remoção ou arquivamento de alertas
Ao selecionar o checkbox de um alerta, também é possível removê-lo ou
arquivá-lo:
Figura 49: Arquivando ou deletando um alerta
Independente da ação selecionada, um pop-up irá surgir para confirmá-la.
69
3.10.4. Automatização da remoção de eventos e alertas
O ACS possibilita automatizar a remoção de eventos e alertas através das
configurações globais event.purge.delay e alert.purge.delay, respectivamente.
O valor dessas configurações representa o número de dias até um evento/a-
lerta ser removido, a partir da sua data de criação.
Então, caso a configuração receba o valor 5, passando-se 5 dias da criação
de eventos/alertas, eles serão removidos automaticamente pelo ACS. O valor
padrão de event.purge.delay é 15 e de alert.purge.delay é 0. Caso elas sejam
configuradas para receber o valor 0, os eventos/alertas nunca serão removi-
dos.
É recomendado o aumento da retenção de eventos, para possibilitar a au-
ditoria do ambiente por períodos mais longos, como 90 ou 180 dias.
3.11. Service offerings
Para que seja possível criar VMs, os virtualizadores exigem especificações
das características delas, como quantidade de CPU, tamanho da memória ou
do disco a ser alocado, entre outras definições. No CloudStack, essas caracte-
rísticas das VMs são agrupadas e padronizadas em forma de ofertas de serviço,
a fim de facilitar a especificação das VMs, mapear o uso dos recursos e, se for
o caso, aplicar cobrança sobre a utilização dos mesmos.
3.11.1. Compute offerings
Compute offerings são as ofertas destinadas aos recursos computacionais
de uma VM, como CPU e memória RAM. Uma compute offering também pos-
sui uma disk offering, que define as características do root disk da VM (quando
criada a partir de um template).
Existem configurações que limitam alguns aspectos das compute offerings,
sendo elas:
70
Configuração Descrição Valor
Padrão
vm.serviceoffering.cpu.cores.max Valor máximo de CPU cores no
momento da criação de ofer-
tas ou da VM. 0 signfifica sem
limites.
0
vm.serviceoffering.ram.size.max Valor máximo de memória
RAM no momento da criação
de ofertas ou da VM. 0 significa
sem limites.
0
Para informações relacionadas ao uso das Compute Offerings, veja a docu-
mentação de uso do Apache CloudStack.
3.12. Network offerings - throttling
É o processo de controle do acesso à rede e uso de largura de banda com
base em certas regras. Este comportamento é controlado pelo CloudStack nas
guest networks por meio do parâmetro de taxa de rede (taxa de transferência
de dados padrão, em Mbps, permitida em uma rede guest). Este parâmetro
determina os limites máximos para utilização da rede; caso a utilização atual
seja maior que os limites impostos, o acesso não é concedido.
É possível controlar congestionamentos da rede e contas que utilizam a taxa
de rede acima dos limites impostos através da limitação da largura de banda.
A taxa de rede para a sua nuvem pode ser configurada da seguinte forma:
• Oferta de rede
• Oferta de serviço
• Configuração global
Se a taxa de rede for definida como NULL na oferta de serviço, o valor for-
necido no configuração global vm.network.throttling.ra te será aplicado. Se o
valor for definido como NULL para a oferta de rede, o valor fornecido no con-
figuração global network.throttling.rate será considerado.
71
Para as redes públicas, seja de armazenamento ou de gestão predefinida,
a taxa de rede é definida como 0, isto implica que possuem largura de banda
ilimitada por predefinição. Já para redes guest, a taxa de rede é definida com N
ULL.
A taxa de rede definida para uma oferta de rede que é utilizada por uma
rede específica no CloudStack, é utilizada para a política de modelagem de trá-
fego de um grupo de portas, ou seja, os VRs se conectaram a esse grupo de
porta e, por consequência, a instância dessa rede também se conectou. Toda-
via, uma instância que for implementada com uma compute offering que define
uma taxa de rede, será conectada ao grupo de portas impostas pela tal política
de modelagem de tráfego, na qual a taxa de rede é utilizada.
3.12.1. System offerings
System offerings são similares às compute offerings, mas destinadas às system
VMs: console proxy VMs, secondary storage VMs e virtual routers. Por padrão, o
CloudStack já possui algumas ofertas destinadas a cada uma dessas VMs. No
entanto, o usuário root admin pode criar novas ofertas e alterar qual delas uma
dessas máquinas está utilizando.
Um exemplo seria quando uma rede guest é criada, o novo virtual router uti-
liza a oferta do sistema na sua network offering. Para atender uma nova oferta
de rede é possível definir recursos que serão fornecidos pelo virtual router.
Sendo assim, todos os VRs dessa rede começarão a utilizar essa nova oferta
de serviço.
72
Figura 50: System offering padrões
3.12.1.1. Criação de system offering
Para adicionar uma nova system offering:
Figura 51: Iniciando a criação de uma nova system offering
Ao clicar no botão Add System Service Offering, será aberto um formulário
73
para preenchimento das informações:
Figura 52: Criando a nova system offering - 1 - continua
Via UI, a opção System VM Type apresenta somente os tipos Domain router,
Console proxy e Secondary storage VM. No entanto, via API, também é possível
criar ofertas do tipo internalloadbalancervm.
Figura 53: Criando a nova system offering - 2
74
• As host tags serão utilizadas para direcionar as system VMs para os hosts
compatíveis (ver seção 3.7.1).
• As storage tags serão utilizadas para direcionar os volumes para os stora-
ges compatíveis (ver seção 3.7.2).
3.12.1.2. Edição de system offering
Após criada a system offering, poucos atributos da mesma podem ser alterados.
• Editar:
Figura 54: Iniciando a edição da system offering
Figura 55: Editando a system offering
• Alterar ordem:
75
Figura 56: Alterando a ordem da system offering
3.12.1.3. Exclusão de system offering
Para excluir uma system offering, basta acessá-la e clicar no ícone de lixeira (as
ofertas padrões não podem ser excluídas):
Figura 57: Iniciando a exclusão da system offering
Figura 58: Excluindo a system offering
Caso haja system VMs rodando com a system offering, elas continuarão fun-
cionando normalmente, pois o CloudStack copia as características da system
offering para a system VM.
76
3.12.1.4. Alteração da system offering de uma system VM
É possível alterar a oferta que uma system VM utiliza por meio da API changeS
erviceForSystemVm. Com o root admin logado no CloudMonkey
89
:
stop systemvm id=<id_da_system_vm>
change serviceforsystemvm id=<id_da_system_vm> serviceofferingid=<id_da_system_offering>
start systemvm id=<id_da_system_vm>
No entanto, caso esta VM seja recriada, ela voltará a utilizar a oferta padrão.
Para alterar a system offering que uma system VM utiliza quando é criada, é ne-
cessário indicar o uuid da oferta nas configurações globais. O valor null indica
que a oferta padrão do CloudStack será utilizada.
Configuração Descrição Valor
Padrão
consoleproxy.service.offering uu id da oferta utilizada pelas con-
sole proxy VMs por padrão.
null
internallbvm.service.offering uuid da oferta utilizada pelas inter-
nal load balancer VMs por padrão.
null
router.service.offering uuid da oferta utilizada pelos virtual
routers por padrão
null
secstorage.service.offering uuid da oferta utilizada pelas secon-
dary storage VMs por padrão.
null
Após alterados os valores e reiniciados os Management Servers, ao destruir
as system VMs, o CloudStack irá recriá-las com as novas ofertas.
3.12.2. Backup offerings
Essas ofertas são destinadas à importação de ofertas de backup de prove-
dores externos ao CloudStack. Atualmente, o único provedor suportado é o
Veeam, para VMWare. O CloudStack possui um provedor fictício (Dummy) ape-
nas para atender aos requisitos lógicos, no entanto ao importar ofertas desse
provedor, nada acontecerá de fato.
8
Para alterar a service offering, é necessário que a system VM esteja parada. Ao ligá-la, ela já
estará utilizando a nova oferta.
9
Ao parar a system VM, ela irá iniciar automaticamente após um tempo. Para mantê-la
parada, é necessário desabilitar a zona.
77
3.12.2.1. Habilitação de backup offering
Para habilitar o recurso de ofertas de backup é necessário definir a configura-
ção global backup.frame work.enabled como true. Além desta, existem outras
configurações para esse recurso:
Configuração Descrição Valor
Padrão
backup.framework.enabled Define se o recurso backup of-
fering estará habilitado ou não.
false
backup.framework.provider.plugin Define qual provedor será uti-
lizado.
dummy
backup.framework.sync.interval Define o intervalo, em segun-
dos, de sincronização de tare-
fas entre o CloudStack e o pro-
vedor.
300
As configurações backup.framework.enabled e backup.framework.provid e
r.plugin funcionam no escopo de zona.
Também existem configurações específicas para o provedor Veeam:
Configuração Descrição Valor Padrão
backup.plugin.veeam.password Senha para acessar
o Veeam.
backup.plugin.veeam.request
.timeout
Timeout, em segun-
dos, das requisições
ao Veeam.
300
backup.plugin.veeam.url URL do Veeam. https://localhost:9398/api/
backup.plugin.veeam.username Usuário para aces-
sar o Veeam.
administrator
backup.plugin.veeam.validate
.ssl
Se estiver como
true, irá validar o
certificado SSL na
conexão https/ssl
com a API do Ve-
eam.
false
Ademais, o servidor do Veeam necessita ter o SSH instalado e rodando na
porta 22.
78
Também é importante ressaltar que ao utilizar o Veeam não deve ser feito
uso de templates do mesmo que contenham caracteres especiais. Isso porque
a utilização de Regex para tentar escapar de tais caracteres causa um erro no
Veeam.
São considerados caracteres especiais: espaço, \, #, $, (), *, +, ., ?, [], ^, {}, |
e letras acentuadas. Os caracteres “-" e “_" não são considerados especiais e
podem ser usados normalmente.
Com a configuração global backup.framework.enabled como true, ao reini-
ciar o CloudStack, uma nova sub-aba aparecerá na aba de Service Offerings:
Figura 59: Aba de backup offering
3.12.2.2. Importação de backup offering
Para importar uma backup offering:
79
Figura 60: Iniciando a importação de uma nova backup offering
Ao clicar no botão Import Backup Offering, será aberto um formulário para
preenchimento das informações:
Figura 61: Importando a nova backup offering
Os valores apresentados no campo External Id são referentes ao provedor
configurado na zona selecionada. Caso o campo Allow User Driven Backups es-
80
teja marcado, o usuário poderá agendar backups ou fazê-los manualmente.
3.12.2.3. Exclusão de backup offering
Não é possível editar uma backup offering, apenas excluí-la:
Figura 62: Iniciando a exclusão da backup offering
Figura 63: Excluíndo a backup offering
Não será possível excluir uma backup offering se ela já estiver sendo usada
por uma VM.
3.12.2.4. Utilização de backup offering
Para utilizar uma backup offering, basta selecionar a VM e:
Figura 64: Iniciando a atribuição da VM à backup offering
81
Figura 65: Atribuindo a VM à backup offering
Para realizar um backup manual, basta selecionar a opção Start Backup:
Figura 66: Iniciando o backup manual da VM
Figura 67: Fazendo o backup manual da VM
Para agendar um backup, basta selecionar a opção Configure Backup Sche-
dule:
Figura 68: Iniciando o agendamento de backups
82
3.12.3. Limitação de IOPS e BPS nas ofertas de discos
No processo de criação de uma disk offering, é possível limitar as taxas de
IOPS e BPS de volumes através da opção QoS type.
Figura 72: Selecionando um QoS type
Ao determinar limites para as taxas de IOPS e BPS de volumes, é importante
se atentar aos seguintes detalhes:
• Controle sobre o tamanho de operações I/O:
Quando o operador define limites para as taxas de IOPS, todas as ope-
rações de I/O (entrada e saída de dados), independentemente do seu ta-
manho, são tratadas de forma similar, como consequência, os usuários
podem se aproveitar disso para contornar os limites estipulados. Para
que isso não aconteça, o operador necessita especificar o tamanho do
84
bloco de cada operação. Supondo que o limite de IOPS para uma VM seja
de 1000, o virtualizador irá limitar a 1000 operações de I/O por segundo,
independentemente do tamanho da requisição de IO. Assim, requisições
com blocos maiores irão se beneficiar. Para ilustrar esse caso, realizamos
alguns testes com a ferramenta fio.
Foi realizado o deploy de uma VM com uma oferta de disco limitando seu
IOPS de escrita e leitura a 1000. Executamos o comando fio especificando
um tamanho de bloco de 64 KiB, em seguida, executamos o comando fi
o de novo especificando um tamanho de bloco de 128 KiB. Mesmo que o
número total de operações de IO seja diferente entre as duas execuções,
ambas realizaram cerca de 1000 IOPS. Isso se deve ao tempo de execu-
ção necessário para cada uma. Utilizando um bloco de escrita maior, foi
atingido o dobro de velocidade de escrita e leitura, mesmo que ambas
execuções estivessem no limite estipulado de 1000 IOPS. A tabela abaixo
apresenta sucintamente o comparativo dos valores discutidos.
Tamanho do bloco Leitura(IOPS) Leitura(MiB/s) Escrita(IOPS) Escrita(MiB/s)
64 KiB 1008 63 337 21.1
128 KiB 1016 127 346 43.3
Atualmente, o ACS não externaliza o tamanho do bloco da operação, en-
tretanto, é possível atingir o mesmo objetivo delimitando a quantidade
de escrita e leitura em BPS (parâmetros bytesreadrate e byteswriterate)
85
Figura 73: Limitando a taxa de BPS
Considerando o mesmo caso acima, especificando o diskBytesReadRat
e como 104857600 (100 MiB) e diskBy tesWriteRate como 31457280 (30
MiB), a utilização do tamanho de bloco de 128 KiB estaria limitado a es-
ses valores. Dessa forma, quando é definido um limite de BPS e IOPS, a
VM será limitada ao primeiro limite atingido. Nesse caso, ao utilizar um
tamanho de bloco de 128 KiB, o limite de BPS será atingido primeiro e,
portanto, a VM nunca atingirá 1000 IOPS. A limitação de BPS para o ta-
manho de bloco de 64 KiB não terá efeito algum, pois o limite de IOPS
será atingido primeiro. A tabela abaixo apresenta os dados mencionados
sucintamente.
86
Tamanho do bloco leitura(IOPS) Leitura(MiB/s) Escrita(IOPS) Escrita(MiB/s)
64 KiB 1008 63 337 21.1
128 KiB 710 88.8 242 30.3
Levando a situação acima em consideração, recomenda-se a utilização
dos parâmetros diskBy tesReadRate e diskBytesWriteRate em conjunto
aos limites de IOPS para limitar a velocidade de leitura e escrita de volu-
mes.
• I/O bursts;
Um burst é quando os limites de leitura e escrita são ultrapassados por um
certo período para possibilitar um maior desempenho durante atividades
intensas. Essa funcionalidade está presente no ACS, contudo, ela está
disponível apenas via API
10
(createServiceOffering e createDiskOffering).
Os parâmetros que possibilitam essas configurações são:
10
Para mais detalhes sobre como enviar requests diretamente à API ??
87
Parâmetro Descrição
bytesreadratemax Define o valor máximo de
leitura do burst em BPS
bytesreadratemaxlength Define o tempo máximo
do burst de leitura em se-
gundos
byteswritemax Define o valor máximo de
escrita do burst em BPS
byteswritemaxlength Define o tempo máximo
do burst de escrita em se-
gundos BPS
iopsreadratemax Define o valor máximo de
leitura do burst em IOPS
iopsreadratemaxlength Define o tampo máximo
do burst de leitura em se-
gundos IOPS
iopswriteratemax Define o valor máximo de
escrita do burst em IOPS
iopswritemaxlength Define o tempo máximo
do burst de escrita em se-
gundos
3.13. Gerência de storages no Apache CloudStack
Esse tópico tem como objetivo apresentar com mais detalhes qual a finali-
dade de cada tipo de storage presente no ACS, seus respectivos escopos, pro-
tocolos e provedores.
3.13.1. Primary storage
O primary storage é usado para armazenar os discos utilizados pelas máqui-
nas virtuais hospedadas. O mesmo pode operar a nível de host, cluster ou de
zone, sendo possível adicionar múltiplos primary storages a clusters e zones. É
necessário, pelo menos, um primary storage por cluster para o correto funcio-
namento do orquestrador.
O CloudStack foi projetado para funcionar com uma ampla variedade de
sistemas de armazenamento, também podendo aproveitar os discos locais nos
hosts dos virtualizadores, desde que haja suporte por parte do virtualizador se-
88
lecionado. O suporte ao tipo de armazenamento para discos virtuais depende
do virtualizador utilizado.
Tipo de armaze-
namento
XenServer vSphere KVM
NFS Suporta Suporta Suporta
iSCSI Suporta Suporta via
VMFS
Suporta via sis-
tema de arqui-
vos em cluster
Fiber Channel Suporta via sto-
rage repositories
Suporta Suporta via sis-
tema de arqui-
vos em cluster
Disco local Suporta Suporta Suporta
O ACS oferece suporte aos seguintes protocolos:
• NFS;
• Shared Mount Point;
• RDB;
• CLVM;
• Gluster;
• Linstor e
• Custom
O CloudStack permite que os administradores gerenciem os primary stora-
ges de acordo com as necessidades do ambiente de nuvem. Estes podem ser
adicionados, habilitados, desabilitados ou colocados em modo de manuten-
ção, onde cada um desses estados apresenta efeitos diferentes no gerencia-
mento do armazenamento.
89
3.13.1.1. Adição de primary storage
Antes de criar um primary storage é necessário definir o tipo de armazenamento
e o protocolo a serem utilizados
11
. Após isso, deve-se garantir o acesso dos
hosts aos storages e validar a escrita e leitura neles. Para acessar o menu de
adição de primary storage:
Figura 74: Acessando menu de adição de um primary storage
11
A Tabela 3.13.1 apresenta os tipos de armazenamento suportados por cada virtualizador.
90
Figura 75: Detalhes de adição de um primary storage
• Adição com o protocolo NFS:
Para trabalhar com NFS basta informar o endereço do servidor NFS e o
caminho exportado pelo servidor. Com esse protocolo, não é necessário
montar o primary storage no host manualmente, visto que o ACS fará esse
procedimento.
91
Figura 76: Adição de um primary storage com NFS
• Adição com o protocolo Shared Mount Point:
Um shared mount point é um caminho do sistema de arquivos local de
cada host em um dado cluster. O caminho deve ser o mesmo entre todos
os hosts no cluster, como /mnt/primary-storage. O ACS não montará o
primary storage como acontece com NFS, sendo assim necessário ao ope-
rador garantir que o storage esteja devidamente disponível.
92
Figura 77: Adição de um primary storage com Shared Mount Point
3.13.1.2. Desabilitação de primary storage
Ao desabilitar um primary storage, as VMs em execução que possuem volumes
nesse Storage Pool não serão afetadas, porém novos volumes e VMs criados
não serão alocados nele. A migração de volumes para um primary storage de-
sabilitado só é possivel via API, pois via UI o CloudStack irá mostrar o primary
storage como Not suitable. Já os volumes presentes em um primary storage
desabilitado podem ser migrados para fora deste tanto via API quanto UI.
93
Figura 78: Desabilitando um primary storage
3.13.1.3. Modo manutenção do primary storage
Ao colocar um primary storage em modo de manutenção, todas as VMs que
possuem volumes nele serão paradas e os volumes poderão ser migrados para
outro primary storage que esteja em estado Up. Além disso, não será possível
alocar novas VMs ou volumes nesse primary storage. Ao iniciar uma VM parada
que possui seu volume no primary storage em manutenção, o Apache Cloud-
Stack automaticamente migrará o volume para um primary storage apropriado.
É importante notar que o CloudStack Agent não desmontará o primary storage
em manutenção.
Figura 79: Habilitando o modo de manutenção
3.13.1.4. Comportamento após reinicialização do host
Se o CloudStack Agent for reiniciado e o primary storage estiver desabilitado
ou em modo de manutenção, ele não será montado automaticamente. Caso
o modo seja alterado após a reinicialização do CloudStack Agent, o primary
94
storage terá um dos seguintes comportamentos, dependendo do estado inicial:
• Modo de Manutenção: Se o primary storage sair do modo de manutenção,
ele será montado novamente.
• Desabilitado: se o primary storage for habilitado, será necessário reiniciar
o CloudStack Agent para que ele seja montado novamente. Caso seja do
interesse do usuário, ele pode habilitar a configuração mou n t .disabled.s
torage.pool que faz com que os storage pools desabilitados sejam monta-
dos automaticamente em caso de reboot do host.
3.13.1.5. Uso de local storage
Dentro das configurações globais existe o parâmetro system.vm.use.local.stor
age, que indica se as VMs de sistema (CPVM, SSVM, VR) devem usar disco local
ou compartilhado. Quando o valor desse parâmetro é verdadeiro, os dados
das VMs de sistema serão preservados em um disco local disponível e, caso
não hajam discos locais habilitados, o Management Server apresentará uma
mensagem de erro de capacidade insuficiente durante a inicialização das VMs
de sistema.
95
Figura 80: Habilitando o uso de local storage para VMs de sistema
Para utilização de local storage para VMs de usuário, é necessário habilitar a
funcionalidade por zona. Isso pode ser realizado acessando o menu de edição
de zona e habilitando a opção Enable local storage for user VMs.
Figura 81: Acessando a zona a ser editada
96
Figura 82: Acessando o menu de edição de zona
Figura 83: Habilitando o uso de local storage para VMs de usuário
Após realizar alterações nas configurações system.vm.use.local.storage e E
nable local storage for user VMs é necessário reiniciar os serviços dos Mana-
97
gement Servers. A seção 7.3.1 exemplifica tal processo com mais detalhes.
Para que uma nova instância faça uso de disco local, é necessário, além
de habilitar a configuração permitindo esse comportamento na zona, que as
service offerings utilizadas para criar essa instância também estejam marcadas
para utilizar discos locais e que hajam discos locais habilitados. Caso contrário,
uma mensagem erro de capacidade insuficiente será disparada por parte do
Management Server, já que não há recurso disponível para alocar para as ins-
tâncias. As ofertas de serviço não podem ser editadas diretamente, portanto,
é necessário que sejam criadas com a opção local storage marcada. As imagens
abaixo mostram onde fica essa opção durante a criação de uma nova oferta.
Figura 84: Adicionar oferta de computação com highlight em Storage Type
98
Figura 85: Adicionar oferta de disco com highlight em Storage Type
Com a opção Enable local storage for user VMs habilitada, os local storages
disponíveis estarão listados no menu "Infrastructure → Primary storage". Para
migração dos volumes de VMs paradas de usuário para local storage, é neces-
sário realizar a migração a frio dos volumes, selecionando os local storages dis-
poníveis, como demonstra a imagem abaixo. Já para migração dos volumes de
VMs em execução de usuário, é necessário realizar a migração a quente dos
volumes. Ambos processos são exemplificados com mais detalhes na seção
3.3.
99
Figura 86: Migração a frio de volume para local storage
Para as system VMs e virtual routers, é possível realizar a migração via API mi
grateVirtualMachineWithVolume, informando o ID da VM, o ID do host destino,
o ID do volume e o ID do storage destino. Por exemplo:
> migrate virtualmachinewithvolume virtualmachineid=<id-da-VM> hostid=<id-do-host>
migrateto[0].volume=<id-do-volume> migrateto[0].pool=<id-do-storage-alvo>
Para recuperar o ID dos volumes das system VMs, é preciso utilizar a API listVolu
mes informando os parâmetros listall e listsystemvms como true. Por exemplo:
> list volumes zoneid=<id-da-zona> listall=true listsystemvms=true
Portanto, é necessário que as configurações estejam alinhadas para que tanto
as VMs de sistema quanto as de usuário utilizem o recurso de local storage,
caso contrário, passarão a ocorrer erros de capacidade insuficiente ao tentar
alocar recursos para novas instâncias.
3.13.2. Secondary storage
Os itens no secondary storage estão disponíveis para todos os hosts que es-
tão no mesmo nível hierárquico desse storage, que é definido por zona. Esse
tipo de armazenamento é utilizado para armazenar:
100
• Templates: imagens de sistemas operacionais que podem ser usadas para
inicializar instâncias e podem incluir informações de configuração adicio-
nais, como aplicativos instalados.
• ISOs: imagens de disco contendo dados ou mídia inicializável para siste-
mas operacionais.
• Snapshots: cópias salvas de dados de alguma VM (tanto da VM inteira
quanto de volumes em específico) que podem ser usadas para recupe-
ração de dados ou para criar novos modelos.
Cada zona tem ao menos um secondary storage que por sua vez é compar-
tilhado entre todos os pontos de entrega nesta zona. O CloudStack oferece
a funcionalidade de automaticamente replicar o secondary storage através das
zonas de modo que haja tolerância à falha. O ACS também foi projetado para
funcionar com qualquer sistema de secondary storage escalável. O único requi-
sito é que o sistema de secondary storage suporte o protocolo NFS.
O CloudStack fornece plugins que permitem o armazenamento de objetos
do OpenStack Object Storage swift.openstack.org e do Amazon Simple Storage
Service (S3). Ao usar um desses plugins de armazenamento, é necessário con-
figurar o armazenamento Swift ou S3 para todo o CloudStack e, em seguida,
configurar um NFS secondary storage em cada zona. Um armazenamento NFS
deve ser mantido em cada zona, pois a maioria dos virtualizadores não é capaz
de montar diretamente um armazenamento do tipo S3. Este armazenamento
NFS atua em cada zona como uma área de preparação pela qual todos os tem-
plates e outros dados do secondary storage passam antes de serem encaminha-
dos para o Swift ou S3. O armazenamento Swift ou S3 atua como um recurso
em toda a nuvem, disponibilizando templates e outros dados para qualquer
zona na nuvem.
Estão disponíveis as seguintes operações de gerenciamento de secondary
storage:
101
3.13.2.1. Adição de secondary storage
Ao criar uma nova zona, o primeiro secondary storage é criado como parte do
processo. Caso necessário, o operador pode criar um novo secondary storage.
Figura 87: Adicionando um novo secondary storage
Figura 88: Detalhes de adição de um novo secondary storage
3.13.2.2. Migração de dados entre secondary storages
O CloudStack permite migrar dados de um secondary storage para outro, po-
dendo escolher entre duas políticas de migração:
• Complete: migra todos os dados de um secondary storage para outro;
102
• Balance: migra apenas uma parcela dos dados, de forma a manter os sto-
rages balanceados.
Figura 89: Migrando dados entre secondary storages
Figura 90: Detalhes de migração de dados entre secondary storages
3.13.2.3. Modo read-only do secondary storage
É possível definir um secondary storage como read only, impedindo que quais-
quer templates, ISOs e snapshots adicionais sejam armazenados nele.
103
Figura 91: Definindo um secondary storage como read only
3.13.2.4. Modo read-write do secondary storage
Caso esteja em modo read only , a opção para reativar o modo de leitura e es-
crita se torna disponível, sendo necessário reativá-lo caso queira realizar novos
armazenamentos no secondary storage.
Figura 92: Definindo um secondary storage como read-write
104
3.13.2.5. Deleção de secondary storage
Por fim, também é possível deletar secondary storages:
Figura 93: Deletando um secondary storage
Figura 94: Confirmando deleção do secondary storage
3.14. Alocação de recursos para o armazenamento secundário
O CloudStack possui uma funcionalidade denominada secondary storage se-
lectors que permite especificar para qual armazenamento secundário os tem-
plates, ISOs, volumes e snapshots de volumes serão alocados. Atualmente, só
é possível utilizar esse recurso enviando requests diretamente para a API atra-
vés do CloudMonkey. Os Secondary Storage Selectors, por meio do parâmetro
heuristicrule, utilizam como regra de ativação um bloco condicional que deve
ser escrito em JavaScript. É importante destacar que ao especificar uma regra
105
de ativação, os atributos do secondary storage estarão sempre presentes para
todos os tipos de recurso; em contrapartida, as variáveis de snapshot, ISO, tem-
plate e volume estarão apenas disponíveis para os respectivos tipos de acordo
com o parâmetro purpose da API createSecondaryStorageSelectors.
A tabela abaixo apresenta os possíveis valores para cada recurso disponível:
Recurso Atributos
Secondary Storage id, usedDiskSize, totalDis
kSize, protocol
Snapshot size, hypervisorType
ISO/TEMPLATE format, hypervisorType
Volume size, format
Para efetuar o uso dessa funcionalidade, primeiramente o operador neces-
sita criar um seletor usando a API create SecondaryStorag eSelector. O seletor
criado irá especificar o tipo de recurso (ISO, snapshot, template ou volume) no
qual a regra de ativação será validada ao realizar a alocação e a zona onde a
regra será aplicada. É importante destacar que só é possível haver uma regra
de ativação do mesmo tipo por zona. Abaixo, encontram-se alguns casos de
uso:
1. Alocando um tipo de recurso para um armazenamento secundário espe-
cifico:
function findStorageWithSpecificId(pool) {
return pool.id === '7432f961-c602-4e8e-8580-2496ffbbc45d';
}
secondaryStorages.filter(findStorageWithSpecificId)[0].id
2. Dedicando pools de armazenamento para um formato específico de tem-
plate;
function directToDedicatedQCOW2Pool(pool) {
return pool.id === '7432f961-c602-4e8e-8580-2496ffbbc45d';
}
function directToDedicatedVHDPool(pool) {
return pool.id === '1ea0109a-299d-4e37-8460-3e9823f9f25c';
}
if (template.format === 'QCOW2') {
secondaryStorages.filter(directToDedicatedQCOW2Pool)[0].id
106
} else if (template.format === 'VHD') {
secondaryStorages.filter(directToDedicatedVHDPool)[0].id
}
3. Direcionando uma snapshot de volume com o KVM para um armazena-
mento secundário específico;
if (snapshot.hypervisorType === 'KVM') {
'7432f961-c602-4e8e-8580-2496ffbbc45d';
}
4. Direcionando recursos para um domínio específico
if (account.domain.id == '52d83793-26de-11ec-8dcf-5254005dcdac') {
'1ea0109a-299d-4e37-8460-3e9823f9f25c'
} else if (account.domain.id == 'c1186146-5ceb-4901-94a1-dd1d24bd849d') {
'7432f961-c602-4e8e-8580-2496ffbbc45d'
}
A feature Secondary Storage Selectors possui 4 APIs: listSecondaryStorageSel
ectors, createSecondarySt o rageSelectors,updateSecondaryStorageSele ctors e
removeSecondaryStorageSelectors.
• A API listSeconda rySto rageSelectors tem a função de mostrar todos os
Secondary Storage Selectors disponíveis e possui os seguintes parâmetros:
Parâmetro Descrição Obrigatório Valor padrão
zoneid ID da zona utilizada na
busca dos seletores
Sim -
purpose O tipo de objeto utilizado
na busca. Opções válidas
são ISO, SNAPSHOT, TEM-
PLATE e VOLUME
Sim -
showRemoved Especifica se devem ser
listados seletores removi-
dos
Não false
• Exemplo de uso da API listSecondaryStorageSelectors
list secondarystorageselectors zoneid=<id da zona> purpose=<tipo de objeto>
107
• A API createSecondaryStorageSelectors tem a função de criar um Secon-
dary Storage Selector e possui os seguintes parâmetros:
Parâmetro Descrição Obrigatório
name O nome para identificar o
seletor
Sim
description A descrição do seletor Sim
zoneid A Zona em que o seletor
estará ativo
Sim
purpose O tipo de objeto em
que o seletor irá atuar.
Opções válidas são ISO,
SNAPSHOT, TEMPLATE e
VOLUME
Sim
heuristicRule A regra especificada
em JavaScript que irá
direcionar o objeto a
um armazenamento
secundário específico;
a regra deve obrigato-
riamente retornar um
texto contendo o UUID
de um armazenamento
secundário válido
Sim
• Exemplo de uso da API createSecondaryStorageSelectors
create secondarystorageselector name=<nome do seletor> description=<descrição> zoneid=<id zona>
heuristicrule=<regra de ativação> purpose=<tipo de objeto>
• A API updateSecondaryStorageSelectors tem a função de atualizar um Se-
condary Storage Selector e possui os seguintes parâmetros:
108
Parâmetro Descrição Obrigatório
id O identificador do seletor
do armazenamento se-
cundário
Sim
heuristicRule A nova regra especificada
em JavaScript; a regra
deve obrigatoriamente
retornar um texto con-
tendo o UUID de um
armazenamento secun-
dário válido
Sim
• Exemplo de uso da API updateSecondaryStorageSelectors
update secondarystorageselector id=<id do seletor> heuristicrule=<regra de ativação>
• A API removeSecondary StorageSelectors tem a função de excluir um Se-
condary Storage Selector e possui os seguintes parâmetros:
Parâmetro Descrição Obrigatório
id O identificador do seletor
a ser removido
Sim
• Exemplo de uso da API removeSecondaryStorageSelectors
remove secondarystorageselector id=<id do seletor>
109
4. Configurações do Apache CloudStack
Essa seção apresenta conceitos relacionados a configurações no ACS, bem
como configurações que são recorrentemente alteradas para a customização
do ambiente.
4.1. Escopos de configuração
Uma das principais características do Apache CloudStack é a sua flexibili-
dade em relação à configuração do ambiente. Essa flexibilidade é possibilitada,
além de outros motivos, pela utilização de escopos de configuração, que são
grupos de configurações que afetam o comportamento do CloudStack em di-
ferentes níveis. Isso permite uma maior flexibilidade na configuração do ACS e
ajuda a otimizar o desempenho e a eficiência do sistema como um todo.
O ACS disponibiliza configurações nos seguintes escopos: Global, Zone, Clu
ster, Domain, Account, ManagementServer, StoragePool e ImageStore.
O escopo Global é o mais amplo, abrangendo todas as configurações do
ambiente. As configurações definidas nesse escopo são aplicadas a todas as
subdivisões da nuvem, permitindo que os usuários personalizem as configura-
ções em todo o ambiente de maneira uniforme. De forma análoga, os outros
escopos indicam que as configurações pertencentes a eles se aplicam a todos
os recursos daquela categoria. Por exemplo, ao modificar o valor de uma con-
figuração com escopo de Account, essa mudança afetará a conta atual. Já se o
escopo fosse Domain, a mudança afetaria todos os membros desse domínio.
Além dos escopos de configuração, existem outras configurações úteis para
o processo de customização do ACS:
• ena bl e. ac co un t. se tt in gs .f or .d om ai n: Permite que as configurações de ní-
vel de conta sejam visíveis também a nível de domínio. Além disso, caso
uma configuração de conta tiver sido configurada pelo administrador,
este será o valor considerado. Caso contrário, será considerado o valor
110
do escopo do domínio. Se o valor do escopo do domínio não estiver confi-
gurado, o valor da configuração global será selecionado. Caso essa confi-
guração estiver configurada como false, se uma configuração de nível de
conta não for configurada pelo administrador, o valor considerado será o
da configuração global.
• enable. doma in.s etti ngs. for. child.domain: se habilitada, essa configura-
ção permite que os domínios filhos (subdomínios) possam herdar as con-
figurações definidas pelos domínios pais. Por exemplo, se um domínio pai
definir uma configuração específica para limitar o uso de CPU em 50%, to-
dos os domínios filhos herdarão essa configuração, a menos que tenham
uma configuração específica que substitua a do pai. Isso torna a configu-
ração de domínios e contas mais fácil e eficiente, permitindo que os ad-
ministradores definam configurações em um nível superior e as herdem
para os níveis inferiores. Por padrão, essa configuração vem desabilitada.
4.2. Configurações globais que regem o uso do primary storage
As seguintes configurações globais gerenciam o comportamento do Cloud-
Stack quando um storage estiver perto de esgotar sua capacidade de armaze-
namento:
111
Configuração Descrição Valor
Pa-
drão
cluster.storage.allocated.capacity.notificationthreshold Valor entre 0 e 1
para indicar o per-
centual de aloca-
ção de storage que
irá acionar o en-
vio de alertas so-
bre a baixa quanti-
dade de armazena-
mento disponível.
0.75
cluster.storage.capacity.notificationthreshold Valor entre 0 e 1
para indicar o per-
centual de utiliza-
ção de storage que
irá acionar o en-
vio de alertas so-
bre a baixa quanti-
dade de armazena-
mento disponível.
0.75
pool.storage.allocated.capacity.disablethreshold Valor entre 0 e 1
para indicar o per-
centual de aloca-
ção do storage que
acionará a desabili-
tação do mesmo.
0.85
pool.storage.capacity.disablethreshold Valor entre 0 e 1
para indicar o per-
centual de utiliza-
ção do storage que
acionará a desabili-
tação do mesmo.
0.85
Mais informações sobre o gerenciamento de primary storages podem ser
encontradas em 3.13.1.
112
4.3. Configurações para limitação de recursos
Configuração Descrição
max.account.public.ips Número máximo de IPs públicos para
uma account
max.account.snapshots Número máximo de snapshots para uma
account
max.account.templates Número máximo de templates para uma
account
max.account.user.vms Número máximo de VMs para uma ac-
count
max.account.volumes Número máximo de discos para uma ac-
count
max.template.iso.size Tamanho máximo de um template ou ISO
(GB)
max.volume.size.gb Tamanho máximo dos discos (GB)
max.account.cpus Número máximo de CPUs para uma ac-
count
max.account.ram Número máximo de RAM (MB) para uma
account
max.account.primary.storage Espaço máximo, em GB, no primary sto-
rage que pode ser usado por uma account
max.account.secondary.storage Espaço máximo, em GB, no secondary sto-
rage que pode ser usado por uma account
max.project.cpus Número máximo de CPUs para um pro-
jeto.
max.project.ram Número máximo de RAM (MB) para um
projeto
max.project.primary.storage Espaço máximo, em GB, no primary sto-
rage que pode ser usado por um projeto
max.project.secondary.storage Espaço máximo, em GB, no secondary sto-
rage que pode ser usado por um projeto
4.4. Configurações que regem o uso de Kubernetes
Esta seção irá abordar apenas as configurações globais necessárias para a
utilização de Kubernetes. Para informações relacionadas ao uso de Kuberne-
tes, acesse o documento de uso do Apache CloudStack.
4.4.1. Habilitação de integração com Kubernetes
Primeiramente, é preciso estar atento às versões adotadas tanto no Cloud-
Stack quanto no Kubernetes. Novas versões do Kubernetes são lançadas com
113
maior frequência em relação ao CloudStack, portanto, é possível que novas
versões do Kubernetes não funcionem como esperado na versão corrente do
CloudStack.
A integração com o Kubernetes está desabilitada por padrão. Para habilitá-
la, acesse as configurações globais e altere para true o valor da configuração c
loud.kubernetes.service.enabled, então, reinicie o Management Server.
Uma vez habilitada a integração, as novas APIs estarão disponíveis e novas
abas do Kubernetes aparecerão na UI.
4.4.2. Criação de clusters Kubernetes
Para criar um cluster Kubernetes, o Management Server deve ter acesso aos
IPs públicos das redes utilizadas para provisionamento de máquinas virtuais no
cluster. Para isso, é necessário alterar a configuração global en d p o int.url para
o domínio pelo qual o ACS é acessado, como demonstrado no exemplo abaixo:
Figura 95: Configuração global endpoint.url
Para que uma nova rede seja criada quando nenhuma tiver sido selecionada
durante a criação do Kubernetes, a configuração global cloud.kubernetes.clus
ter.network.offering deve ser definida, configurando-a com o nome da oferta
desejada por padrão.
114
5. Customização da UI
Essa seção apresenta como customizar a interface web do Apache Cloud-
Stack de diferentes maneiras e preferências.
5.1. Alteração de logo e outros elementos
Nota: esta é o modelo antigo de customização da GUI. Recomendamos o
uso do sistema de gerenciamento de temas (Seção 5.3) para maiores customi-
zações e melhor gestão das mesmas.
É possível alterar/personalizar alguns dos aspectos da interface web do Cloud-
Stack, como logo, banner, título da página, footers, entre outros. Nesta seção
será apresentado o processo de customização de logos e banners. É recomen-
dado realizar um backup do diretório que contém as configurações a seguir,
para caso seja necessário reverter as alterações feitas.
Para customizar logos e banners, o procedimento é:
1. Faça login no Management Server via ssh:
user@machine:~$ ssh username@ip-do-management
# Um exemplo prático:
user@machine:~$ ssh root@192.168.103.168
2. Navegue até o diretório /usr/share /cloudstac k-management/webapp/as
sets:
user@machine:~$ cd /usr/share/cloudstack-management/webapp/assets
# Caso ocorra algum erro do tipo "Permission denied", execute o comando:
user@machine:~$ sudo su
# E repita o processo de navegar até o diretório de logs do CloudStack.
3. Nesse diretório estão as imagens utilizadas pelo CloudStack. Caso deseje
apenas alterar o logo e banner, basta alterar os arquivos logo.svg e bann
er.svg e atualizá-los no arquivo de configurações config.json. Para alterar
essas imagens, o procedimento consiste em realizar o upload do logo e
banner do cliente para o Management Server via scp.
4. Repita esse processo em cada Management Server existente na infraes-
trutura.
115
5. Se qualquer um dos procedimentos no Management Server resultar em
algum erro do tipo Permission denied, execute o comando:
user@machine:~$ sudo su
E repita o processo que causou esse erro.
Algumas observações:
• No diretório / usr/s hare/cloudstack-manageme nt/we bapp existe um ar-
quivo chamado cloud.ico, responsável pelo ícone presente na aba de seu
navegador, que também pode ser alterado.
• Nesse mesmo diretório, existe um arquivo chamado config.json, que pode
ser utilizado para alterar o título da página, assim como o footer e outros
detalhes.
• A UI do CloudStack possuí um período de cache. Caso as mudanças não
estejam visíveis, é recomendado limpar o cache e realizar um novo teste
afim de visualizar as alterações feitas.
• Como a interface web do CloudStack, até a presente escrita desse docu-
mento, é relativamente nova e ainda está sendo desenvolvida, pode ser
necessário repetir esse procedimento quando a versão atual do Cloud-
Stack for atualizada.
Um exemplo de customização do CloudStack é:
{
"apiBase": "/client/api",
"docBase": "http://docs.cloudstack.apache.org/en/latest",
"appTitle": "SC Clouds",
"footer": "Bem-vindo (a) ao portal com aspectos customizados",
"logo": "assets/logo.svg",
"banner": "assets/banner.svg",
"error": {
"403": "assets/403.png",
"404": "assets/404.png",
"500": "assets/500.png"
},
// ...
}
116
Figura 96: Banner customizado
Figura 97: Rodapé customizado
5.2. Alteração de logo ao redimensionar a página
Quando o usuário redimensiona a página a um certo ponto, ou clica no bo-
tão para colapsar o menu lateral, o logo configurado no ambiente é cortado
para ajustar ao tamanho do menu.
O logo padrão do ACS possui um design de forma que ao ser cortada, fica
uma espécie de “mini logo”, já outras logos podem não seguir esse design, como
pode ser observado nas imagens a seguir:
Figura 98: Logo inteira
117
Figura 99: Logo cortada
Para customizar este comportamento de mudança de logo, as configura-
ções no arquivo /usr/share/cloudstack-management/webapp/config.json de-
vem ser alteradas em todos os Management Servers do ambiente.
As propriedades referentes a esse aprimoramento (mini logo) estão apre-
sentadas a seguir. Note que outras propriedades desse arquivo foram omitidas
com [...] para não poluir o documento:
{
[...]
"logo": "assets/logo.svg",
"minilogo": "assets/mini-logo.svg",
[...]
"theme": {
"@logo-background-color": "#ffffff",
"@mini-logo-background-color": "#ffffff",
[...]
"@logo-width": "256px",
"@logo-height": "64px",
"@mini-logo-width": "80px",
"@mini-logo-height": "64px",
}
}
Figura 100: Mini logo
Nota: Para surgimento dos efeitos, deve-se atualizar o cache da página.
118
5.3. Gerência de temas
Os temas são uma alternativa para a customização da UI do CloudStack.
Possuem funcionalidades e propósitos diferenciados, sendo destinados, mas
não se limitando, a atender às necessidades dos provedores de nuvem que
desejam implementar um modelo de revenda e fornecer um sistema de nu-
vem White Label. É possível gerenciar temas em diferentes níveis de aplicação,
permitindo uma maior liberdade de customização.
Essa funcionalidade permite gerenciar temas à nível de account, domain e
internet common name. É possível especificar regras CSS e atributos no formato
JSON que serão utilizadas para carregar o tema dinamicamente. Caso não te-
nha nenhum tema registrado, a GUI usará a configuração atual de ambiente.
Logo abaixo, estão as APIs que permitem o gerenciamento de temas:
5.3.1. Criação de tema
A API createGuiThe me é acessível apenas para contas do tipo root admin
e permite que sejam criados temas com diversos escopos. Essa API tem os
seguintes parâmetros:
Parâmetro Descrição Obrigatório Valor
padrão
name O nome para identificar o tema. Sim -
description A descrição para o tema. Não null
css O CSS a ser importado na GUI
para corresponder às configura-
ções de acesso ao tema.
Não null
jsonconfiguration O JSON com as configurações
a serem importadas na GUI
quando coincidirem com as
configurações de acesso ao
tema. Mais detalhes sobre as
configurações JSON podem ser
encontrados na Seção 5.3.3.2.
Não null
commonnames Um conjunto de internet common
names, separados por vírgulas,
que possuem acesso ao tema.
Não null
119
Parâmetro Descrição Obrigatório Valor
padrão
domainids Um conjunto de IDs, separados
por vírgulas, dos domínios que
possuem acesso ao tema.
Não null
accountsids Um conjunto de IDs, separados
por vírgulas, de contas que pos-
suem acesso ao tema.
Não null
ispublic Define se o acesso ao tema é libe-
rado para qualquer um, quando
apenas o commonnames é infor-
mado. Se os domainids ou accou
ntids são informados, é conside-
rado false.
Não true
Tabela 1: Parâmetros createGuiTheme
Se commonnames, domainids e accountids não forem informados, o tema
será considerado como o padrão; pode existir apenas um tema padrão e ele é
automaticamente público. Se não houver temas correspondentes, a GUI utili-
zará a configuração de ambiente atual como fallback.
Apesar de constar a não obrigatoriedade dos campos css e jsonconfigurati
on, é necessário que ao menos um dos campos seja informado para a criação
do tema.
A subseção 5.3.5 exemplifica a criação de temas e de personalizações mais
recorrentes da interface.
5.3.2. Listagem de temas
A API listGuiThemes é acessível para qualquer usuário e busca os temas de
acordo com os parâmetros e o acesso do usuário que a chamou. Ela tem os
seguintes parâmetros:
120
Parâmetro Descrição Obrigatório Valor
padrão
id ID do tema. Não null
name Nome do tema. Não null
commonname Internet common name a ser fil-
trado.
Não null
domainid ID do domínio a ser filtrado. Não null
accountid ID da conta a ser filtrada. Não null
listall Se irá listar todos os temas. Não false
listremoved Se irá listar os temas removidos. Não false
ispublic Se irá listar temas públicos. To-
dos serão listados por padrão.
Não true
listonlydefaulttheme Listar apenas o tema padrão. Se
o parãmetro for true, então todos
os outros parâmetros serão igno-
rados.
Não false
Tabela 2: Parâmetros listGuiThemes
Para permitir que o tema seja exibido na página de login, é possível chamar
esta API sem autenticação; no entanto, existem limitações sobre este caso de
uso. Uma chamada não autenticada à API listGuiThemes sempre recupera o
tema padrão ou o tema público mais recente e ativo que corresponder ao In-
ternet common name solicitado à API. Além disso, todos os parâmetros da API
serão ignorados.
Uma das formas de consulta possíveis é mostrada no exemplo abaixo:
(admin) > list guithemes listall=true
{
"count": 1,
"guiThemes": [
{
"created": "2023-09-15T16:20:18+0000",
"css": ".layout.ant-layout .header {background: purple;}",
"id": "a9a05158-2870-48b7-877a-626badde4b28",
"ispublic": true,
"jsonconfiguration": "{\"banner\":\
"https://res.cloudinary.com/sc-clouds/image/upload/v1645707938
/identidade/scclouds-logo_f56v2y.png\", \
"logo\":\"https://res.cloudinary.com/sc-clouds/image/upload/v1645707938
/identidade/scclouds-logo_f56v2y.png\", \"favicon\":\
"https://gitlab.scclouds.com.br/uploads/-/system/appearance/favicon
/1/scclouds-avatar.ico\"}",
"name": "exemplo-tema"
}
]
}
121
5.3.3. Atualização do tema
A API updateGuiTheme é acessível apenas por contas do tipo root admin e
permite a atualização de um tema já adicionado. Ela tem os seguintes parâme-
tros:
Parâmetro Descrição Obrigatório Valor
padrão
id ID do tema a ser atualizado. Sim -
name Um nome para identificar o tema. Não null
description Uma descrição para o tema. Não null
css O CSS a ser importado na GUI
quando as configurações de
acesso ao tema corresponde-
rem.
Não null
jsonconfiguration O JSON com as configurações
a serem importadas na GUI
quando as configurações de
acesso ao tema corresponde-
rem. Mais detalhes sobre as
configurações JSON podem ser
encontrados na Seção 5.3.3.2.
Não null
commonnames Um conjunto de intenet common
names, separados por vírgulas,
que podem obter o tema.
Não null
domainids Um conjunto de IDs, separados
por vírgulas, de domínios que po-
dem obter o tema.
Não false
accountids Um conjunto de IDs, separados
por vírgulas, de contas que po-
dem obter o tema.
Não false
ispublic É o parâmetro booleano que de-
fine se o acesso ao tema é libe-
rado para qualquer um, quando
apenas o commonnames é infor-
mado. Se os domainids ou accou
ntids são informados, é conside-
rado false.
Não true
Tabela 3: Parâmetros updateGuiTheme
Abaixo, é apresentado um exemplo de atualização do tema listado na se-
122
ção 5.3.2. Ressalta-se que as atualizações irão sobrescrever os campos css e
jsonconfiguration, como pode ser observado no retorno da chamada para a
API. Além disso, para remover um parâmetros, é necessário passá-lo explici-
tamente como uma string vazia.
(admin) > update guitheme id=a9a05158-2870-48b7-877a-626badde4b28
css='.layout.ant-layout .header {background: orange;}'
{
"guiThemes": {
"created": "2023-09-15T16:20:18+0000",
"css": ".layout.ant-layout .header {background: orange;}",
"id": "a9a05158-2870-48b7-877a-626badde4b28",
"ispublic": true,
"jsonconfiguration": "{\"banner\":\"https://res.cloudinary.com/sc-clouds/image
/upload/v1645707938/identidade/scclouds-logo_f56v2y.png\", \
"logo\":\"https://res.cloudinary.com/sc-clouds/image/upload/v1645707938
/identidade/scclouds-logo_f56v2y.png\", \"favicon\":\
"https://gitlab.scclouds.com.br/uploads/-/system/appearance/favicon/1
/scclouds-avatar.ico\"}",
"name": "exemplo-tema"
}
}
5.3.3.1. Campo css
Dentro do campo css, é possível adicionar estilos personalizados à UI do Cloud-
Stack, aplicado diretamente nas tags HTML ou dentro das tags <style>, usando
a linguagem CSS. Outra opção é utilizar o @import, com ele é possível adicionar
um estilo por meio de uma URL para um arquivo CSS.
@import <url|string> <lista-de-media-queries>
• url: Uma URL ou uma string que representa a localização do recurso a ser
importado. A URL pode ser absoluta ou relativa.
• media queries: Uma lista separada por vírgulas de consultas de mídia que
condicionam a aplicação das regras CSS definidas na URL vinculada.
Usar @import pode ser vantajoso para facilitar a adição de temas e ajudar
na organização dos mesmos, visto que o ACS não possui um mecanismo de
controle de arquivos CSS, o qual limita as possibilidades do operador. Por isso,
a importação em um sistema de versionamento é mais eficaz e simples, apesar
123
das pequenas desvantagens, como a necessidade de requisições HTTP adicio-
nais, os quais pouco interferem no desempenho.
5.3.3.2. Configuração JSON
As configurações JSON seguem o atual padrão do ACS config.json; todavia, limitando-
se a alguns atributos:
Atributo Descrição.
appTitle Título da página web.
favicon Favicon da página web.
footer Footer da página web.
loginFooter Footer do login da página web.
logo Link local ou externo da imagem a ser apresentada como a
logo na barra da esquerda.
minilogo Link local ou externo da imagem a ser apresentada como a
miniatura da logo na barra da esquerda, quando ela é colap-
sada.
banner Link local ou externo da imagem a ser apresentada como o
fundo na tela de login.
error.403 Link local ou externo de uma imagem a ser apresentada
quando se recebe o error 403.
error.404 Link local ou externo de uma imagem a ser apresentada
quando se recebe o error 404.
error.500 Link local ou externo de uma imagem a ser apresentada
quando se recebe o error 500.
plugins Um conjunto de objetos plugins.
Tabela 4: Atributos jsonconfiguration
A estrutura dos plugins é a seguinte:
Atributo Descrição
name Nome do plugin.
path Link para a página web a ser adicionado o plugin.
icon Ícone para o plugin.
isExternalLink Determina se o plugin se refere a um link externo.
Tabela 5: Atributos do plugin da jsonconfiguration
Exemplo de um jsonconfiguration:
124
{
"appTitle": "CloudStack",
"favicon": "cloud.ico",
"footer": "Licensed under the Apache License, Version 2.0.",
"loginFooter": "",
"logo": "assets/logo.svg",
"minilogo": "assets/mini-logo.svg",
"banner": "assets/banner.svg",
"error": {
"403": "assets/403.png",
"404": "assets/404.png",
"500": "assets/500.png"
},
"plugins": [
{
"name": "Apache CloudStack",
"path": "https://cloudstack.apache.org/",
"isExternalLink": "true",
"icon": "https://cloudstack.apache.org/images/favicon.ico"
}]
}
Se outros atributos forem especificados, eles serão ignorados.
5.3.4. Remoção de tema
A API removeGuiTheme é acessível apenas para contas do tipo root admin e
permite que eles removam um tema. É preciso passar o ID do tema em questão
para fazer a remoção, como mostrado no exemplo abaixo:
(admin) > remove guitheme id=a9a05158-2870-48b7-877a-626badde4b28
{
"success": true
}
5.3.5. Exemplos de personalizações comuns da UI
Esse tópico visa apresentar exemplos das personalizações mais comuns da
UI, além de prover dicas gerais para facilitar o processo de estilização.
5.3.5.1. Criação do tema com arquivo de estilização externo
Primeiramente, é necessário executar a API createGuiTheme via CloudMonkey
para criação do tema. Como citado no tópico 5.3.3.1, é recomendável que a @
import at-rule do CSS seja utilizada para configurar a estilização. Através dela,
é possível inserir as propriedades CSS em um arquivo separado ao invés de
inseri-las via terminal.
create guitheme name="theme" css="@import url('<url-arquivo-css>')"
125
5.3.5.2. Observações sobre conflitos entre estilos
Durante a estilização da interface do ACS, é comum que hajam conflitos entre
os estilos que estão sendo inseridos e os que já estão em uso. Eles ocorrem
quando dois ou mais seletores possuem estilos conflitantes aplicados em um
mesmo elemento.
Para solucionar esse problema, é necessário que a especificidade do seletor
que está sendo inserido seja a mais alta possível. Em últimos casos, pode-
se utilizar a rule !important. Os estilos declarados com ela terão preferência
em relação a qualquer outro estilo. Como será demonstrado nos exemplos
seguintes, a adoção do uso da regra acaba tornando-se recorrente.
5.3.5.3. Adição de fontes
Podem ser importadas fontes no CSS. Para esse exemplo, a fonte Poppins foi
utilizada.
@import url("<url-fonte>");
* {
font-family: 'Poppins' , Courier !important;
}
5.3.5.4. Uso de variáveis CSS
É recomendável que sejam adicionadas variáveis CSS que abstraiam valores
de propriedades e para que seja mantida uma consistência na estilização. Para
isso, elas podem ser inseridas normalmente no arquivo CSS, preferencialmente
no seletor :root. As variáveis que foram utilizadas nos exemplos são as seguin-
tes:
:root {
--main-verde: #3E7C59;
--main-vermelho: #ae0000;
--main-normal: #327355;
--main-primary-claro: #db4e2d22;
--main-primary-escuro: #db4e2d;
--main-secondary-claro: #E9782622;
--main-secondary-escuro: #E97826;
--main-gray-claro: #eee;
--main-linear-cora: #ddd;
--main-linear-corb: #ddd;
126
--main-image-menu: url("<url-imagem>");
--main-image-login: url("<url-imagem>");
--main-image-icon: url("<url-imagem>");
}
5.3.5.5. Página de login
/* Logo página de login */
.userLayout .user-layout-header {
min-height: 100px;
background-image: var(--main-image-login);
background-repeat: no-repeat;
background-size: 250px;
background-position: top center;
}
/* Esconder logo padrão do ACS */
.userLayout .user-layout-header > img {
display: none;
}
/* background-color da página, exceto do footer */
.ant-tabs-tab,
.user-layout {
background-color: var(--main-gray-claro) !important;
}
/*
background-color aplicado na tag HTML.
Porém, na prática, a propriedade será aplicada no footer da página de login
*/
html {
background-color: var(--main-secondary-escuro);
}
/* border contínua abaixo das tabs */
.ant-tabs-top-bar .ant-tabs-nav-scroll {
border-bottom: 3px solid var(--main-primary-escuro);
width: 90.5%;
margin: 0 auto;
}
/* Cor dos títulos das tabs ("Portal login", "Single sign-on", ...) */
.user-layout .ant-tabs-top-bar .ant-tabs-nav-scroll .ant-tabs-tab {
color: var(--main-primary-escuro);
border-bottom: 0px solid var(--main-primary-escuro);
}
/* border-bottom da tab ativa */
.user-layout .ant-tabs-top-bar .ant-tabs-nav-scroll .ant-tabs-tab.ant-tabs-tab-active {
border-width: 3px;
}
/* Estilos da tab quando :hover */
.user-layout .ant-tabs-top-bar .ant-tabs-nav-scroll .ant-tabs-tab:hover {
background-color: var(--main-secondary-escuro) !important;
color: #fff;
border-width: 3px;
}
/* Necessário para retirar border padrão ACS */
.ant-tabs-ink-bar.ant-tabs-ink-bar-no-animated {
display: none !important;
127
}
/* Todos botões, exceto para os quais possuem a classe .ant-btn-icon-only */
button.ant-btn:not(.ant-btn-icon-only){
background-color: var(--main-primary-escuro) !important;
color: #fff;
border: 0px;
}
/* Botões :hover */
button.ant-btn:not(.ant-btn-icon-only):hover {
background-color: var(--main-secondary-escuro) !important;
color: #fff;
}
/* Inputs */
.ant-input-affix-wrapper,
.ant-input-affix-wrapper input {
background-color: var(--main-gray-claro) !important;
}
/* Placeholder dos inputs */
.ant-input-search .ant-input-search.input-search input::placeholder {
color: #666;
}
Figura 101: Página de login customizada
5.3.5.6. Estilização do header
/* Cores do header */
.layout.ant-layout .header {
background: linear-gradient(var(--main-linear-cora), var(--main-linear-corb)) !important;
box-shadow: 0px 0px 10px #00000055;
128
}
/* Ícones do header */
.layout.ant-layout .header .user-menu > span *,
.layout.ant-layout .header .anticon-menu-unfold,
.layout.ant-layout .header .anticon-menu-fold {
color: #000 !important;
}
/* Ícones do header :hover */
.layout.ant-layout .header .anticon-menu-unfold:hover,
.layout.ant-layout .header .anticon-menu-fold:hover,
.layout.ant-layout .header .user-menu > span:hover {
background-color: var(--main-primary-escuro) !important;
color: #fff !important;
}
/* Ícones do menu do usuário :hover */
.layout.ant-layout .header .user-menu > span:hover * {
color: #fff !important;
}
/* Triggers dos dropdowns quando estão ativos */
.layout.ant-layout .header .user-menu > span.ant-dropdown-open {
background-color: var(--main-primary-claro) !important;
border-bottom: 5px solid var(--main-primary-escuro) !important;
}
Figura 102: Header estilizado
5.3.5.7. Estilização da sidebar
/* background sidebar */
aside {
background: linear-gradient(var(--main-linear-cora), var(--main-linear-corb)) !important;
}
.sider.light .ant-menu-light,
.sider.light .ant-menu-submenu > .ant-menu {
background-color: transparent;
}
/* Cor dos links de navegação */
.sider.light .ant-menu-light a,
.sider.light .ant-menu-submenu > .ant-menu-submenu-title {
color: #000 !important;
}
/* border-right para o link ativo */
.ant-menu-vertical .ant-menu-item::after,
.ant-menu-vertical-left .ant-menu-item::after,
.ant-menu-vertical-right .ant-menu-item::after,
.ant-menu-inline .ant-menu-item::after {
border-color: var(--main-primary-escuro) !important;
}
/* background do link ativo */
.ant-menu:not(.ant-menu-horizontal) .ant-menu-item.ant-menu-item-selected {
129
background-color: var(--main-primary-claro) !important;
}
/* background link :hover */
.ant-menu:not(.ant-menu-horizontal) .ant-menu-item:hover,
.ant-menu:not(.ant-menu-horizontal) .ant-menu-submenu div:hover {
background-color: var(--main-primary-escuro) !important;
}
/* Cor dos ícones :hover */
.ant-menu:not(.ant-menu-horizontal) span.ant-menu-title-content:hover .custom-icon path {
fill: #fff !important;
}
/* Cor dos links :hover */
.ant-menu:not(.ant-menu-horizontal) .ant-menu-item-active:hover a,
.ant-menu:not(.ant-menu-horizontal) .ant-menu-submenu span.ant-menu-title-content:hover{
color: #fff !important;
}
/* Logo sidebar */
.ant-layout-sider.light.ant-fixed-sidemenu > div > div{
height: 100px !important;
background-image: var(--main-image-menu);
background-repeat: no-repeat;
background-size: 200px;
background-position: 25px 25px;
margin-bottom: 20px;
}
/* Logo sidebar fechada */
.ant-layout-sider.light.ant-fixed-sidemenu.ant-layout-sider-collapsed > div > div{
height: 70px !important;
background-image: var(--main-image-icon);
background-repeat: no-repeat;
background-size: 30px;
background-position: 25px 20px;
}
/* Esconder logo padrão do ACS */
.ant-layout-sider img {
display: none;
}
130
Figura 103: Sidebar estilizada
Figura 104: Sidebar fechada estilizada
5.3.5.8. Estilização dos cards e dos gráficos do dashboard
/* Card "Running VMs" */
.usage-dashboard .ant-row .ant-col:nth-child(1) .ant-card.usage-dashboard-chart-card {
background-color: var(--main-verde) !important;
}
/* Card "Stopped VMs" */
.usage-dashboard .ant-row .ant-col:nth-child(2) .ant-card.usage-dashboard-chart-card {
background-color: var(--main-vermelho) !important;
131
}
/* Texto dos cards "RunningVMs" e "Stopped VMs" */
.usage-dashboard .ant-row .ant-col:nth-child(1) .ant-card.usage-dashboard-chart-card h2,
.usage-dashboard .ant-row .ant-col:nth-child(1) .ant-card.usage-dashboard-chart-card h3,
.usage-dashboard .ant-row .ant-col:nth-child(2) .ant-card.usage-dashboard-chart-card h2,
.usage-dashboard .ant-row .ant-col:nth-child(2) .ant-card.usage-dashboard-chart-card h3 {
color: #fff !important;
}
/* Porcentagem gráficos */
.ant-progress-circle.ant-progress-status-normal .ant-progress-text {
color: var(--main-normal) !important;
font-weight: bold;
}
/* Cor de preenchimento gráfico */
.ant-progress.ant-progress-status-normal path.ant-progress-circle-path {
stroke: var(--main-normal) !important;
}
/* Cor seção do gráfico não preenchida */
.ant-progress path.ant-progress-circle-trail{
stroke: var(--main-gray-claro) !important;
}
Figura 105: Dashboard da conta root admin estilizado
132
Figura 106: Dashboard da conta de usuário estilizado
5.3.5.9. Estilização dos links e listagens
/* Cor dos links */
a {
color: var(--main-primary-escuro);
}
/* Cor dos links :hover */
a:hover {
color: var(--main-secondary-escuro);
}
/* Cor dos links dos dropdowns */
.ant-dropdown .ant-dropdown-menu-item:hover {
background-color: var(--main-primary-claro) !important;
}
/* Cor dos links dos dropdowns :hover */
.ant-dropdown .ant-dropdown-menu-item:hover * {
color: #000;
}
/* Cor dos itens das listagens :hover */
.ant-table-tbody > tr:hover > td {
background: var(--main-secondary-claro) !important;
}
Figura 107: Listagem e links estilizados
133
5.4. Redirecionamento para links externos
Existem duas propriedades no arquivo de configurações config.json que de-
finem redirecionamentos para links externos.
A propriedade ex ternalLink consiste em uma lista de atributos title, link e i
con.
"externalLinksIcon: "",
"externalLink": [
{
"title": "Cloudstack",
"link": "https://cloudstack.apache.org",
"icon": myIcons/cloudstach.png
},
{
"title": "Apache",
"link": "https://apache.org",
"icon": "https://www.apache.org/icons/apache.png"
}
]
A feature de redirecionamento para links externos é regida pelas seguintes
regras:
• caso as propriedades não estejam definidas, o botão de redirecionamento
não será exibido ao usuário;
• o atributo link da propriedade externalLinks é obrigatório nesse contexto,
e os elementos dessa propriedade que estejam sem o atributo link ou com
ele vazio serão desconsiderados;
• os atributos title e icon são opcionais, caso ico n não esteja definido um
icone default será aplicado;
• quando o atributo title não estiver definido, o link será exibido em seu
lugar.
Uma vez que os atributos title, link e icon sejam informados, dois possíveis
comportamentos podem ser observados:
1. Apenas um elemento definido: nesse contexto será exibido um botão,
que, ao ser clicado, redirecionará o usuário para o link definido na confi-
guração;
134
Figura 108: Um elemento definido
2. Mais de um elemento definido: será exibida uma dropdown contendo os
links configurados.
Figura 109: Mais de um elemento definido
"externalLinksIcon: "",
"externalLinks": [
{
"title": "",
"link": "http://apache.org",
"icon": "https://www.apache.org/icons/apache.png"
},
{
"title": "Nao sera mostrado",
"link": "",
"icon": ""
},
{
"title": "CloudStack",
"link": "http://cloudstack.org",
"icon": "myIcons/cloudstach.png"
}
]
A propriedade externalLinksIcon, também opcional, define o ícone que será
utilizado para compor o botão apresentado quando informado mais de um link
externo. No exemplo acima, essa propriedade foi omitida, portanto, o ícone
default foi apresentado. Também é possível utilizar imagens locais no atributo
icon ou um link externo.
135
6. Contabilização do consumo de recursos
O módulo de contabilização do consumo de recursos computacionais é sub-
dividido em dois mecanismos: coleta de uso (Usage Server) e contabilização de
uso (Quota), sendo o segundo complementar ao primeiro.
O mecanismo Usage Server realiza periodicamente a identificação e a coleta
dos dados de uso de recursos no ambiente.
O mecanismo Quota é um plugin que permite gerenciar um modelo de ta-
rifas sobre o consumo de recursos computacionais, guiado por um relaciona-
mento um para muitos, possibilitando a definição de diversas tarifas para um
mesmo tipo de recurso. Em cada tarifa é utilizado o tipo de recurso, volume de
consumo e características do usuário para avaliar e calcular a estimativa dos
custos.
6.1. Usage Server
O Usage Server (serviço cloudstack-usage) é um componente opcional do
CloudStack, o qual é responsável por gerar registros sobre os recursos usa-
dos na infraestrutura, registros estes que são salvos em um banco de dados
separado, chamado cloud_usage.
Ele é utilizado para monitorar o consumo de recursos pelos usuários, per-
mitindo a implementação de serviços de cobrança (billing) ou de relatórios. Ele
funciona coletando dados dos eventos lançados pelo CloudStack e criando re-
latórios de uso dos recursos com eles.
6.1.1. Configuração do Usage Server
O comando para habilitar o serviço do Usage Server é:
user@scclouds:~$ systemctl enable cloudstack-usage.service
user@scclouds:~$ systemctl start cloudstack-usage.service
Após habilitado, é necessário realizar a configuração do mesmo no Cloud-
Stack:
• Acessando as configurações do CloudStack:
137
Figura 111: Acessando as configurações
As principais configurações são:
Configuração Descrição Valor Padrão
enable.usage.server Habilitar o serviço false
publish.usage.events Habilitar a publicação
de eventos de uso
usage.timezone Timezone usada pelo
Usage Server
GMT
usage.sanity.check.interval Intervalo em dias para
checar erros no Usage
Server
usage.snapshot.virtualsize.select Analisa o tama-
nho virtual(true)
ou físico(false) dos
snapshots
false
usage.stats.job.aggregation.range Intervalo em que os
dados serão agrega-
dos, em minutos
1440
usage.stats.job.exec.time Horário em que o job
de agregação come-
çará a ser executado
00:15
138
Figura 112: Editando as configurações
Assim que as configurações desejadas forem aplicadas e salvas, é neces-
sário reiniciar os serviços do Management Server e do Usage Server com os
comandos:
user@scclouds:~$ systemctl restart cloudstack-management.service
user@scclouds:~$ systemctl restart cloudstack-usage.service
6.1.2. Usage type
O Usage Server é utilizado para monitorar o consumo de diversos recursos,
e para diferenciar os registros, cada relatório será lançado junto com o parâ-
metro usage_type para indicar o tipo de recurso sendo contabilizado durante o
período de agregação.
Pode-se encontrar todos os usage_types via API, da seguinte maneira:
(admin) > list usagetypes
Tipo Nome Descrição
1 RUNNING_VM Verifica o tempo de execução de uma VM
durante o período de registro de uso. Se
a VM for atualizada durante o período,
você receberá um registro de uso sepa-
rado para a VM atualizada.
2 ALLOCATED_VM Verifica o tempo total em que a VM foi cri-
ada até o momento que foi destruída.
3 IP_ADDRESS Mostra o endereço IP público usado pela
account.
139
4 NETWORK_BYTES_SENT Verifica o número de bytes enviados pelas
VMs de uma account. O tráfego enviado
de cada VM individualmente não é rastre-
ado.
5 NETWORK_BYTES_RECEIVED Verifica o número de bytes recebidos pe-
las VMs de uma account. O tráfego rece-
bido de cada VM individualmente não é
rastreado.
6 VOLUME Verifica o tempo total em que um volume
de disco foi criado até o momento que foi
destruído.
7 TEMPLATE Verifica o tempo total que um tem-
plate (criado a partir de um snapshot ou
upload) foi criado até o momento em que
foi destruído. O tamanho do template
também é retornado.
8 ISO Verifica o tempo total de um ISO, desde
o upload até o momento em que foi des-
truído. O tamanho do ISO também é re-
tornado.
9 SNAPSHOT Verifica o tempo total em que uma
snapshot foi criada até o momento que
foi destruída.
10 SECURITY_GROUP Verifica o uso de security groups.
11 LOAD_BALANCER_POLICY Verifica o tempo total que uma regra do
load balancer foi criada até o momento
em que foi removida. Não é rastreado se
alguma VM utilizou essa regra.
140
12 PORT_FORWARDING_RULE Verifica o tempo em que uma regra de
encaminhamento de porta (port forwar-
ding) foi criada até o momento em que
foi removida.
13 NETWORK_OFFERING Verifica o tempo desde quando uma
network offering foi designada a uma VM
até o momento em que foi removida.
14 VPN_USERS Verifica o tempo desde a criação de um
usuário VPN até a sua remoção.
21 VM_DISK_IO_READ Mostra a quantidade de operações de lei-
tura do disco da VM.
22 VM_DISK_IO_WRITE Mostra a quantidade de operações de es-
crita do disco da VM.
23 VM_DISK_BYTES_READ Mostra a quantidade de bytes lidos do
disco da VM.
24 VM_DISK_BYTES_WRITE Mostra a quantidade de bytes escritos do
disco da VM.
25 VM_SNAPSHOT Mostra a quantidade de armazenamento
usada pelos snapshots da VM.
26 VOLUME_SECONDARY Mostra a quantidade de secondary sto-
rage usada pelos volumes da VM.
27 VM_SNAPSHOT_ON_PRIMARY Mostra a quantidade de primary storage
usada pelos snapshots da VM.
28 BACKUP Mostra o armazenamento usado para
Backups da VM.
29 VPC Verifica o tempo total em que uma VPC
foi criada até o momento que foi des-
truída
141
30 NETWORK Verifica o tempo total em que uma
network foi criada até o momento que foi
destruída.
31 BACKUP_OBJECT Mostra o armazenamento usado por ob-
jetos Backups.
Tabela 6: Usage types
Uma lista de possíveis configurações de limitações de recursos pode ser
acessada no 4.3.
6.2. Quota
O plugin Quota oferece um serviço que estende as funcionalidades do Usage
Server, possibilitando a atribuição de um valor monetário ao consumo dos re-
cursos computacionais sobre os relatórios de controle.
6.2.1. Configuração do Quota
As principais configurações desse serviço são:
Nome Descrição Valor
Padrão
quota.currency.symbol Símbolo da moeda usada
para mensurar o uso de re-
cursos.
$
quota.enable.service Habilitar o plugin Quota. false
quota.statement.period Intervalo em que os deta-
lhes do Quota serão envia-
dos via e-mail, sendo os pos-
síveis valores: bimensal(0),
mensal(1), trimestral(2), se-
mestral(3) e anual(4).
1
quota.usage.smtp.connection.timeout Timeout da conexão com o
servidor SMTP.
60
quota.usage.smtp.host Host no qual está o servidor
SMTP.
142
Nome Descrição Valor
Padrão
quota.usage.smtp.password Senha do servidor SMTP.
quota.usage.smtp.port Porta do servidor SMTP.
quota.usage.smtp.sender E-mail emissor.
quota.usage.smtp.useAuth Usar autenticação no servi-
dor SMTP.
quota.usage.smtp.user Usuário do servidor SMPT.
quota.enable.enforcement Indisponibiliza a manipula-
ção de recursos por parte
da conta quando a mesma
chega ao limite de Quota.
false
Após alterar as configurações, é necessário reiniciar os serviços do Mana-
gement Server e do Usage Server para que elas sejam aplicadas:
user@scclouds:~$ systemctl restart cloudstack-management.service
user@scclouds:~$ systemctl restart cloudstack-usage.service
Após o reinício, o menu Quota estará disponível na UI:
Figura 113: Plugin Quota
A partir dele será possível realizar o gerenciamento de tarifas, créditos, tem-
plates de e-mail do Quota e visualizar os relatórios.
6.2.2. Gerência de tarifas
No sub-menu Tariff é possível visualizar e gerenciar as tarifas do Quota. Ao
acessar o menu, será apresentada a lista de tarifas ativas no sistema:
143
Figura 114: Lista de tarifas ativas
Também é possível listar tarifas já removidas, bastando selecionar a opção
Removed no filtro, ou All para listar tudo:
Figura 115: Filtros da listagem
O operador pode criar novas tarifas ou editar/remover
12
tarifas já existen-
tes.
6.2.2.1. Criação de tarifas
Para criar uma nova tarifa, deve-se utilizar o botão Cr eate Quota tariff, o qual
abrirá o seguinte formulário:
12
Operação de edição e remoção só estão disponíveis para tarifas ativas.
144
Figura 116: Formulário de criação de tarifa
O operador obrigatoriamente deve informar os campos Name, Usage type
e Tariff value. Os demais campos são opcionais.
No campo Processing period, ao escolher a opção Monthly, irá aparecer um
novo campo Execute on, onde será necessário adicionar um dia do mês entre
1-28, indicando a data em que a tarifa será processada mensalmente.
É possível configurar regras para definir quando a tarifa deve ser aplicada.
A documentação sobre as regras de ativação pode ser encontrada na seção
Regras de ativação.
145
6.2.2.2. Detalhes das tarifas
Ao selecionar uma tarifa na listagem, é possível visualizar os detalhes da mesma
e as ações que poderão ser executadas:
Figura 117: Detalhes da tarifa
6.2.2.3. Edição de tarifas
Após criar as tarifas, o operador pode alterar algumas informações:
Figura 118: Ações possíveis para tarifas ativas
146
Figura 119: Formulário de edição de tarifa
As alterações realizadas na tarifa só terão efeito sobre os processamentos
posteriores à alteração.
6.2.2.4. Remoção de tarifas
Quando o operador julgar necessário, ele pode remover as tarifas para que
elas não sejam mais consideradas no processamento do Quota:
Figura 120: Remoção de tarifa
6.2.3. Regras de ativação
Regras de ativação são expressões lógicas utilizadas para definir se ou quais
tarifas serão aplicadas de acordo com os recursos que estão sendo utilizados,
147
podendo, inclusive, aplicar tarifas específicas para clientes específicos.
Através das regras de ativação, é possível utilizar resource tags como uma
forma de identificar diferentes tipos de recursos dentro de uma mesma cate-
goria e assim aplicar tarifas únicas para cada um (por exemplo, aplicar uma
tarifa maior caso o storage seja do tipo SSD).
Devido à maior facilidade de entendimento e escrita, comparada a outras
linguagens de programação, a linguagem JavaScript foi escolhida para criação
das regras de ativação. Portanto, as expressões devem ser escritas em código
JavaScript ECMAScript 5.1 especificamente e devem atender, além da sintaxe
da linguagem, as seguintes regras:
• O motor de processamento das expressões será instanciado apenas uma
vez por ciclo de processamento, portanto, ao criar regras de ativação, não
deve-se usar as palavras reservadas const, var ou let para declaração das
variáveis, pois isso gerará o erro Identifier has already
been declared e não será possível processar as regras. Ao invés de usar
const a = 1;, por exemplo, deve-se usar a = 1;.
• O ACS espera que o retorno dessas expressões seja um valor boolean (tru
e/false) ou um valor numérico. Ele irá inferir o tipo do resultado aplicando
as seguintes regras:
– se o resultado for um número, como 1, 2.5 e assim por diante, o
resultado será utilizado como o valor da tarifa, ao invés do valor con-
figurado no campo Tariff value;
– caso o resultado não seja um número, o ACS irá tentar converter o
resultado para boolean. Se o resultado for true, o valor configurado
no campo Tariff value será usado no cálculo. Caso contrário, se o
resultado for false ou a expressão não resulte em um boolean válido,
a tarifa não será aplicada no cálculo;
148
– caso a tarifa não possua expressões para serem avaliadas ou a ex-
pressão é vazia, a tarifa sempre será aplicada.
Algumas variáveis serão pré-criadas (elas serão referidas como preset ao
longo do texto) no contexto das expressões fornecer mais flexibilidade para os
operadores. Cada tipo de recurso terá uma série de presets correspondendo
às suas características:
6.2.3.1. Presets padrões para todos os tipos de recursos
Variável Descrição
account.id uuid da account dona do recurso.
account.name name da account dona do recurso.
account.role.id uuid da role da account dona do recurso (se exis-
tir).
account.role.name name da role da account dona do recurso (se exis-
tir).
account.role.type type da role da account dona do recurso (se exis-
tir).
domain.id uuid do domain da account dona do recurso.
domain.name name do domain da account dona do recurso.
domain.path path do domain da account dona do recurso.
project.id uuid do project dono do recurso (se existir).
project.name name do project dono do recurso (se existir).
resourceType type do recurso.
value.accountResources Lista dos demais recursos da account, do mesmo
tipo e válidos no mesmo período do que está
sendo processado.
zone.id uuid da zone da account dona do recurso.
zone.name name da zone da account dona do recurso.
processedData.id uuid do recurso.
processedData.name name do recurso.
processedData.startDate Data de início dos dados processados.
processedData.endDate Data final dos dados processados.
149
Variável Descrição
processedData.usageValue usage dos recursos durante o período.
processedData.aggregatedTariffs Agregação de todas as tarifas do Quota
aplicadas ao recurso durante o período.
processedData.tariffs.value Valor da tarifa.
processedData.tariffs.id uuid da tarifa.
processedData.tariffs.name name da tarifa.
lastTariffs Lista de objetos contendo os atributos i
d e value das tarifas anteriores à atual.
6.2.3.2. Presets para o tipo RUNNING_VM
Variável Descrição
value.host.id uuid do host no qual a VM está ro-
dando.
value.host.name name do host no qual a VM está
rodando.
value.host.tags Lista de tags do host no qual a VM
está rodando. Exemplo: ["a", "b"].
value.host.isTagARule Um boolean que indica se a tag uti-
lizada é uma regra ou não.
value.id uuid da VM.
value.name name da VM.
value.osName name do OS da VM.
value.computeOffering.customized Um boolean informando se a com-
pute offering da VM é customizável
ou não.
value.computeOffering.id uuid da compute offering da VM.
value.computeOffering.name name da compute offering da VM.
value.computingResources.cpuNumber Número corrente de vCPUs da
VM.
value.computingResources.cpuSpeed Velocidade corrente da CPU da VM
(em Mhz).
value.computingResources.memory Quantidade corrente de memória
da VM (em MiB).
value.tags Tags da VM, no formato key:value.
Exemplo: {"a":"b", "c":"d"}.
value.template.id uuid do template da VM.
value.template.name name do template da VM.
value.hypervisorType type do hypervisor da VM.
150
6.2.3.3. Presets para o tipo ALLOCATED_VM
Variável Descrição
value.id uuid da VM.
value.name name da VM.
value.osName name do OS da VM.
value.computeOffering.customized Um boolean informando se a compute
offering da VM é customizável ou não.
value.computeOffering.id uuid da compute offering da VM.
value.computeOffering.name name da compute offering da VM.
value.tags Tags da VM, no formato key:val ue.
Exemplo: {"a":"b", "c":"d"}.
value.template.id uuid do template da VM.
value.template.name name do template da VM.
value.hypervisorType type do hypervisor da VM.
6.2.3.4. Presets para o tipo VOLUME
Variável Descrição
value.diskOffering.id uuid da disk offering do volume.
value.diskOffering.name name da disk offering do volume.
value.id uuid do volume.
value.name name do volume.
value.provisioningType Tipo de provisionamento do recurso. Os valores
podem ser: thin, sparse ou fat.
value.storage.id uuid do storage onde o volume está.
value.storage.isTagARule Um boolean que indica se a tag utilizada é uma
regra ou não.
value.storage.name name do storage onde o volume está.
value.storage.scope scope do storage onde o volume está. Os valores
podem ser: ZONE ou CLUSTER.
value.storage.tags Lista de tags do storage onde o volume está.
Exemplo: ["a", "b"].
value.tags Tags do volume, no formato key:value. Exemplo:
{"a":"b", "c":"d"}.
value.size size do volume (em MiB).
value.volumeFormat O formato do volume. Os valores podem ser: RA
W, VHD, VHDX, OVA e QCOW2.
151
6.2.3.5. Presets para os tipos TEMPLATE e ISO
Variável Descrição
value.id uuid do template/ISO.
value.name name do template/ISO.
value.osName name do OS do template/ISO.
value.tags Tags do template/ISO, no formato key:value. Exemplo: {"a":"
b", "c":"d"}.
value.size size do template/ISO (em MiB).
6.2.3.6. Presets para o tipo SNAPSHOT
Variável Descrição
value.id uuid da snapshot.
value.name name da snapshot.
value.size size da snapshot (em MiB).
value.snapshotType type da snapshot. Os valores podem ser: MANUA
L, HOURLY, DAILY, WEEKLY ou MONTHLY.
value.storage.id uuid do storage onde o snapshot está.
value.storage.isTagARule Um boolean que indica se a tag utilizada é uma
regra ou não.
value.storage.name name do storage onde o snapshot está.
value.storage.scope scope do storage onde o snapshot está. Os valo-
res podem ser: ZONE ou CLUSTER.
value.storage.tags Lista de tags do storage onde o snapshot está.
Exemplo: ["a", "b"].
value.tags Tags da snapshot, no formato key:value. Exemplo:
{"a":"b", "c":"d"}.
value.hypervisorType hypervisor no qual o recurso foi implantado. Os
valores podem ser: XenServer, KVM, VMware, Hy
per-V, BareMetal, Ovm, Ovm3 e LXC.
Observações:
• Se a configuração global snapshot.backup.to.sec ondary estiver como fal
se, os dados das presets valu e.storage.i d e value.st orage.name serão do
primary storage. Caso contrário, serão do secondary storage.
152
• Hosts ou storages utilizando a funcionalidade de tag flexível terão a variá-
vel isTagARule como true e terão sua variável tag vazia.
• Se a configuração global snapshot.backup.to.secondary estiver como fals
e, os dados das presets value.storage.scope e value.storage.tags serão do
primary storage. Caso contrário, os dados não existirão.
6.2.3.7. Presets para os tipos NETWORK_OFFERING
Variável Descrição
value.id uuid da network offering.
value.name name da network offering.
value.tag tag da network offering.
6.2.3.8. Presets para o tipo VM_SNAPSHOT
Variável Descrição
value.id uuid da snapshot de VM.
value.name name da snapshot de VM.
value.tags Tags da snapshot de VM, no formato key:value.
Exemplo: {"a":"b", "c":"d"}.
value.vmSnapshotType typ e da snapshot de VM. Os valores podem ser: Di
sk ou DiskAndMemory.
value.hypervisorType hypervisor no qual o recurso foi implantado. Os va-
lores podem ser: X e n Server, KVM, VMware, Hyper
-V, BareMetal, Ovm, Ovm3 e LXC.
6.2.3.9. Presets para o tipo BACKUP
Variável Descrição
value.size size do backup.
value.virtualSize virtual size da VM.
value.backupOffering.id uuid da backup offering.
value.backupOffering.name name da backup offering.
value.backupOffering.externalId external id da backup offering.
Observações:
153
• A unidade das presets value.size e value.virtualSize varia para cada prove-
dor de backup. Por exemplo, os valores informados pelo Veeam são em
bytes.
6.2.3.10. Presets para o tipo NETWORK USAGE
Variável Descrição
value.id uuid da network.
value.name name da network.
value.state state da network. Os valores podem ser: Alocado, Configurado,
Implementando, Implementado, Desligado e Destruído.
6.2.3.11. Presets para o tipo BACKUP OBJECT
Variável Descrição
value.id uuid do backup_object.
value.name name da backup_object.
value.size size do recurso em MiB.
value.virtualSize virtual size do backup.
value.backupOffering.id uuid da backup offering.
value.backupOffering.name name da backup offering.
value.backupOffering.externalId external id da backup offering.
value.virtualMachine.id uuid da VM.
value.virtualMachine.name name da VM.
6.2.3.12. Verificação das presets via API
Pode-se fazer uma chamada via API, para verificar todas as presets de cada
recurso, apenas usuários Admin tem acesso a esse comando. Para isso, apenas
escolha uma usageType para checar o nome das variáveis e suas descrições,
como mostrado abaixo:
(admin) > quota listpresetvariables usagetype=<id_da_usageType>
6.2.3.13. Presets para os demais tipos de recurso
As presets específicas de cada tipo de recurso foram endereçadas baseadas em
casos de uso, portanto, nem todas as propriedades dos recursos estão presen-
154
tes, assim como nem todos os tipos de recursos possuem presets específicas,
apenas as presets padrões. Demais presets podem ser adicionadas a medida
que forem surgindo casos de uso.
6.2.3.14. Exemplos de expressões
Conforme descrito no início desta seção, as regras de ativação são expressões
lógicas em JavaScript desenvolvidas para casos de uso específicos. É recomen-
dável que o administrador do ambiente crie expressões próprias de acordo
com suas necessidades, se atentando às regras descritas no início da seção e à
sintaxe da linguagem. Os exemplos a seguir são apenas algumas demonstra-
ções do que é possível fazer com as regras de ativação.
1. Aplicar tarifa apenas para uma account (disponível para todos os tipos de
recursos):
if (account.id == 'b29e84da-ed2e-47dc-9785-49231de8ff07') {
true
} else {
false
}
Ou apenas:
account.id == 'b29e84da-ed2e-47dc-9785-49231de8ff07'
2. Aplicar tarifa se a account possuir em vigência mais de 20 recursos do
mesmo tipo (disponível para todos os tipos de recursos):
value.accountResources.filter(resource =>
resource.domainId == 'b5ea6ffb-fa80-455e-8b38-c9b7e3900cfd'
).length > 20
155
3. Retornar o valor da tarifa de acordo com a quantidade de recursos vigen-
tes que a account possuir (disponível para todos os tipos de recursos)
13
:
resourcesLength = value.accountResources.filter(resource =>
resource.domainId == 'b5ea6ffb-fa80-455e-8b38-c9b7e3900cfd'
).length
if (resourcesLength > 40) {
20
} else if (resourcesLength > 10) {
25
} else {
30
}
4. Aplicação da tarifa se ela for de um determinado OS (disponível para RUN-
NING_VM e ALLOCATED_VM):
['Windows 10 (32-bit)',
'Windows 10 (64-bit)',
'Windows 2000 Advanced Server'].indexOf(value.osName) !== -1
5. Validação das tags do storage (disponível para VOLUME e SNAPSHOT):
value.storage.tags.indexOf('SSD') !== -1
&& value.storage.tags.indexOf('NVME') !== -1
6. Validação das tags do host (disponível para RUNNING_VM):
value.host.tags.indexOf('CPU platinum') !== -1
13
Se o valor não for informado no else, a expressão pode resultar em undef ined e a tarifa
não será aplicada.
156
7. Validação de IPs públicos
14
. Se o primeiro IP público for livre de cobranças
para o usuário, é possível evitar a cobrança de source NAT IPs (disponível
para IP_ADDRESS):
resourceType !== 'SourceNat'
8. Retornar o valor da tarifa se o storage utilizado for do tipo HDD (disponível
para VOLUME e SNAPSHOT):
useHdd = false
if (value.storage) {
for (i = 0; i < value.storage.tags.length; i++) {
if (value.storage.tags[i].indexOf('hdd') !== -1) {
useHdd = true
break
}
}
}
if (useHdd) {
0.3
} else {
0
}
9. Um exemplo mais complexo, a expressão a seguir representa o custo de
licenciamento do OS Windows e possui algumas peculiaridades (disponível
para ALLOCATED_VM):
• A cobrança se dá pelo número de vCPUs atribuídas à VM;
• É cobrado um mínimo de 4 vCPUs;
14
IPs públicos estão ligados às VPCs ou redes isoladas (não diretamente à VM do usuário).
Todo primeiro IP público de uma VPC ou rede isolada é um source NAT; se o IP público for
alocado pelo usuário, a preset resourceType será null.
157
• Acima de 4 vCPUs, é cobrado em incremento de pares (2) vCPUs. Ou
seja, se o número de vCPUs for ímpar, a cobrança é arredondada
para um valor par acima. Por exemplo, a cobrança de 5 vCPUs é igual
a 6, de 7 vCPUs é igual a 8, e assim por diante;
• A cobrança é por mês.
TOTAL_CORES_PER_PACKAGES = 2;
MININUM_NUMBER_OF_PACKAGES_WINDOWS_LICENSES = 4;
OPERATING_SYSTEM_NAME = "windows";
windows_operating_system_monthly_price = 36;
calculate_number_of_license_packages = function (vcpus) {
return (vcpus + vcpus%TOTAL_CORES_PER_PACKAGES)/
TOTAL_CORES_PER_PACKAGES;
};
if (value.osName.toLocaleLowerCase().
indexOf(OPERATING_SYSTEM_NAME) >= 0) {
calculate_number_of_license_packages
(value.computingResources.cpuNumber) *
windows_operating_system_monthly_price
} else {
0
}
6.2.4. Gerência de créditos
No sub-menu Summary é possível visualizar os relatórios do Quota e geren-
ciar o crédito das contas.
158
Figura 121: Lista de contas ativas
6.2.4.1. Adição/remoção de créditos
Para adicionar/remover créditos de uma conta, deve-se utilizar o botão Add cr
edits, o qual abrirá o seguinte formulário:
Figura 122: Formulário de adição/remoção de créditos
Observações:
159
• Para remover créditos da conta, deve ser utilizado o operador - antes do
valor da tarifa, no campo Value.
• O campo Min Balance indica o limite mínimo de saldo da conta.
• Ao marcar o campo Enforce Quota, contas que chegarem ao seu limite de
saldo serão bloqueadas.
6.2.5. Contas ativas
No sub-menu Su mmary são apresentadas, por padrão, o estado atual das
contas ativas (último balanço + créditos):
Figura 123: Lista de contas ativas
Também é possível listar as contas já removidas, bastando selecionar a op-
ção Removed accounts no filtro, ou All para listar tudo:
Figura 124: Filtros da listagem
160
Via CloudMonkey essa consulta pode ser realizada da seguinte forma:
(admin) > quota summary account=admin domainid=52d83793-26de-11ec-8dcf-5254005dcdac listall=true
{
"count": 1,
"summary": [
{
"account": "admin",
"accountid": "af16aaed-26de-11ec-8dcf-5254005dcdac",
"accountremoved": false,
"balance": 124.49,
"currency": "$",
"domain": "/",
"domainid": "52d83793-26de-11ec-8dcf-5254005dcdac",
"domainremoved": false,
"enddate": "2023-10-06T12:00:00+0000",
"quota": 8.33871072,
"quotaenabled": true,
"startdate": "2023-10-01T12:00:00+0000",
"state": "ENABLED"
}
]
}
6.2.6. Gerência de templates de e-mail do Quota
Para o mecanismo Quota existe a possibilidade de definição de templates
de notificações, que serão enviadas para os usuários de acordo com quatro
situações pré-definidas. Para cada usuário é possível definir em quais situações
serão enviadas as notificações.
No sub-menu Email Template é possível visualizar e gerenciar os templates
dos e-mail que o plugin Quota enviará:
Figura 125: Lista de templates de e-mail do Quota
Por padrão, o plugin Quota enviará e-mails para uma account nos seguintes
cenários:
161
• Poucos créditos;
• Sem créditos;
• Créditos adicionados;
• Balanço de uso.
Para cada um dos cenários existe um template de e-mail que será enviado.
Para poder editar esses templates, basta selecionar na listagem:
Figura 126: Editando o template de e-mail
6.2.6.1. Observações sobre o uso do plugin Quota
1. Para que uma conta seja adicionada ao processamento do plugin Quota,
é necessário adicionar créditos para ela ao menos uma vez. Além disso, a
configuração a nível de conta quota.account.enabled deve estar definida
como true. O estado do Quota para uma determinada conta pode ser
acessado no sub-menu Summary na coluna Quota state.
Figura 127: Quota state para as contas admin e custom-account
162
2. Para que uma conta seja bloqueada quando seu saldo de créditos for me-
nor do que zero, é necessário que a configuração global quota.enable.enf
orcement seja true e, ao adicionar créditos na conta, seja utilizada a opção
Enforce Quota.
3. Uma conta bloqueada ainda possui acesso aos recursos já alocados. Ela
pode desalocá-los, contudo, não consegue alocar novos e nem realocar
antigos. Ou seja, caso o usuário tenha a sua conta bloqueada, o mesmo
pode destruir ou parar suas VMs, mas não pode iniciar/reiniciar elas. Caso
algum problema ocorra na VM (como um shutdown por falta de CPU ou
RAM), o usuário terá que adquirir mais créditos para poder reiniciar a VM.
4. A checagem de créditos da conta, seguida de bloqueio (caso seja a situ-
ação), é realizada em um intervalo definido pela variável usage.stats.job.
aggregation.range, cujo valor padrão é de um dia.
163
7. Operação
Essa seção apresenta algumas das principais operações básicas que os ope-
radores precisam saber realizar para resolver problemas no ACS.
7.1. Depuração de problemas e processo de troubleshooting
Existe uma série de situações que podem ocorrer no ACS. Aqui são aborda-
das algumas ações recomendadas para descobrir a origem da maior parte dos
problemas, pois muitas vezes os mesmos podem ser resolvidos sem a neces-
sidade de abrir um issue.
7.1.1. Depuração através dos logs
Geralmente, ao se deparar com um erro, o primeiro passo para resolução
do problema é buscar os arquivos de log dos componentes relevantes para a
ação que ocasionou o erro.
A leitura dos logs tende a revelar a causa de uma grande parte dos proble-
mas. Além disso, caso o problema não seja tratável no contexto de operação,
enviar os logs relevantes aos problemas facilita e agiliza a resolução deles ao
abrir um issue. A seção 7.1.4 descreve como encontrar os arquivos de log.
Eventualmente erros acontecem por falta de recursos. Por exemplo, um
erro ao criar um virtual router pode ser causado por falta de IPs disponíveis.
Esse tipo de situação usualmente é corrigida aumentando os recursos atuais,
ou reciclando outros que não são mais usados.
7.1.2. Depuração através da interface web
Quando erros acontecem pela interface web, é possível verificar quais co-
mandos da API estão sendo feitos, a partir disso, a busca pelo erro nos logs é
facilitada, já que os comandos que estão sendo chamados são conhecidos. As
etapas para fazer esse tipo de depuração são:
1. Abra o menu de ferramentas de desenvolvimento do seu navegador (ge-
ralmente o atalho é F12);
164
2. Selecione a aba Network;
3. Paralelamente, abra o arquivo de log do Management Server, usando o
comando tail -f;
4. Faça a ação que ocasiona o erro na interface web. Você verá todas as
chamadas sendo feitas na aba Network;
5. Selecione uma de interesse;
6. Na seção GET da aba de Network estará escrito o comando da API;
A partir disso, é possível acompanhar o fluxo de execução nos logs e depurar
o problema.
7.1.3. Depuração de problemas de rede
Por vezes, as rotas de algum dos componentes do ACS são alteradas, isso
pode impedir a comunicação entre componentes da estrutura. O comando ip
route é a principal forma de descobrir se as rotas foram alteradas, verificando
se os IPs condizem com a topologia adotada. Alternativamente, é possível uti-
lizar o comando arp para verificar se os pacotes estão passando pela interface
correta. A equipe da SC Clouds disponibiliza um documento com a topologia
adotada, que pode ser consultado para verificar se os IPs estão corretos.
7.1.4. Path dos arquivos de log
O arquivo de log do Management Server se encontra no seguinte caminho:
• /var/log/cloudstack/management/management-server.log
Caso o Usage Server esteja em uso, o seu arquivo de log se encontra no se-
guinte caminho:
• /var/log/cloudstack/usage/usage.log
Caso seja utilizado o hypervisor KVM, existirá o componente CloudStack Agent.
O arquivo de log dele se encontrará no seguinte caminho:
• /var/log/cloudstack/agent/agent.log
165
Os logs das system VMs se encontram nos seguintes caminhos:
• /var/log/cloud.log
• /var/log/cloud/cloud.out
7.1.5. Incremento de nível dos logs nos Management Servers e KVM Agents
Esta seção descreve como configurar o Log4j
15
de forma que logs importan-
tes do ACS não sejam perdidos. O Log4j organiza os logs da seguinte forma:
1. FATAL: Erros ocorridos que causam uma parada do sistema (crash). É
importante que esse tipo de mensagem seja reportada!
2. ERROR: Erros que interrompem uma tarefa, porém não causam a parada
completa do sistema. Geralmente, também é importante reportar esse
tipo de mensagem;
3. WARN: Avisos que não representam erros ocorridos, mas apontam even-
tos que podem causá-los no futuro;
4. INFO: Informações relevantes da ação efetuada. Mensagens desse tipo
relatam eventos normais do sistema, não erros;
5. DEBUG: Informações detalhadas da ação efetuada;
6. TRACE: Passo a passo detalhado da ação efetuada, sendo mais granular
que o nível DEBUG;
Já é conhecido que, atualmente, os logs do ACS possuem problemas de ca-
tegorização e clareza. Por exemplo, existem logs que deveriam ser registrados
em nível INFO ou ERROR, porém são registrados em nível DEBUG. A equipe
da SC Clouds vem trabalhando no aperfeiçoamento desses e outros aspectos
referentes aos logs do ACS. Entretanto, até que este trabalho seja concluído, é
necessário que o Log4j seja configurado de maneira adequada (em nível DE-
BUG) para facilitar troubleshootings.
15
Utilitário usado pelo ACS para registrar logs.
166
É possível configurar o Log4j para que ele registre apenas certos tipos de
logs, assim, o Log4j vai registrar todas as mensagens daquele tipo e mais seve-
ras. A hierarquia adotada é:
Configuração Níveis de log registrados
OFF Não registra logs.
FATAL FATAL
ERROR FATAL e ERROR
WARN FATAL, ERROR e WARN
INFO FATAL, ERROR, WARN e INFO
DEBUG FATAL, ERROR, WARN, INFO e DEBUG
TRACE FATAL, ERROR, WARN, INFO, DEBUG e TRACE
ALL FATAL, ERROR, WARN, INFO, DEBUG e TRACE
É possível configurar o appender
16
para aceitar um nível de log dentre os
apresentados acima. A configuração padrão atual dos Management Servers é
DEBUG; dos agents e system VMs é INFO. Portanto, o appender apenas regis-
trará logs do nível especificado ou mais graves, o que pode não ser suficiente
para detectar ou compreender certos problemas. É recomendado alterar essa
configuração de INFO para DEBUG em todos os agents, caso seja utilizado o
hypervisor KVM.
Para isso, edite os arquivos abaixo nos respectivos hosts utilizando um edi-
tor de texto:
• No agent:
sudo vim /etc/cloudstack/agent/log4j-cloud.xml
• No Management Server:
sudo vim /etc/cloudstack/management/log4j-cloud.xml
16
Parte do utilitário responsável por entregar os logs para seu destino.
167
• Nas system VMs:
sudo vim /usr/local/cloud/systemvm/conf/log4j-cloud.xml
Caso o hypervisor utilizado seja o VMware, o processo para acessar as sys-
tem VMs e editar o arquivo de configuração do log4j será diferente. A seção
acessando as System VMs apresenta mais detalhes sobre esse processo.
Mude a seguinte configuração:
...
<appender name="FILE" class="org.apache.log4j.rolling.RollingFileAppender">
...
<param name="Threshold" value="INFO"/>
...
Para:
...
<appender name="FILE" class="org.apache.log4j.rolling.RollingFileAppender">
...
<param name="Threshold" value="DEBUG"/>
...
Para limitar as fontes de log, o Log4j permite a criação de categorias, que
definem de qual lugar virão os logs, assim como o nível aceito. É importante
notar que a leitura do XML que define as configurações do Log4j é serial, por-
tanto a ordem das categorias é importante, pois se quisermos limitar os logs
de um pacote, mas ter logs de nível menos restritivo de um pacote dentro dele,
é preciso primeiro definir o nível menos restritivo da parte que queremos, e
após isso definir o nível de restrição do pacote como um todo.
Tendo isso em mente, recomendamos adicionar a seguinte categoria no
XML dos agents:
<category name="org.apache.cloudstack">
<priority value="DEBUG"/>
</category>
Essa categoria deve estar acima da org.apache, pelo motivo explicado anteri-
ormente. Por outro lado, se ao invés de criar essa categoria, fosse editado a
categoria org.apache para o nível DEBUG, isso criaria um flood grande demais
de mensagens de log que não são importantes.
168
Nos management servers essa categoria já existe, porém ela está mal posici-
onada, portanto basta mover ela para que fique acima da org.apache.
Também é necessário alterar a priority value da categoria com.cloud para o
nível DEBUG:
<category name="com.cloud">
<priority value="DEBUG"/>
</category>
Finalmente, é necessário mudar a configuração da categoria root, pois ela
dita o nível máximo que o logger aceitará, sem isso, nenhuma mudança anterior
surtirá efeito. Por padrão ela está configurada para INFO:
<root>
<level value="INFO"/>
<appender-ref ref="CONSOLE"/>
<appender-ref ref="FILE"/>
</root>
Basta mudar o level value de INFO para DEBUG.
7.1.6. Processo de troubleshooting
A análise de logs no CloudStack é extremamente útil e pode ser um ponto
chave em investigações, pois traz informações a respeito das etapas de pro-
cessos no ACS, erros, warnings, entre outras.
Para a análise eficaz dos logs do ACS é necessário filtrar as entradas de in-
teresse, e isso é feito através da identificação do log id ou job id atrelado a elas.
Caso a análise vá ser feita com os logs do Management Server e exista mais
de um Management Server em uso, é necessário realizar a busca em todos
eles. Isso porque os comandos executados podem ser balanceados entre os
mesmos.
A fim de demonstrar essa filtragem e análise trazemos em seguida um exem-
plo de processo de troubleshooting. Nesse exemplo iremos acompanhar a cri-
ação de uma nova VM, mas os passos expostos aqui podem ser seguidos para
investigar diversas outras ocorrências no CloudStack.
Para iniciar a análise foi criada uma VM via UI e foram seguidas as etapas
descritas abaixo:
169
Figura 128: VM criada através da UI
1. Para identificar o log id do processo que se deseja investigar, primeiro
é necessário encontrar uma entrada de log que contenha essa informa-
ção. Isso pode ser feito acompanhando no browser as requisições HTTP
que a UI encaminhou ao back-end ao realizar determinada ação solicitada
pelo usuário. Ao visualizar os detalhes de uma requisição HTTP é possível
identificar o comando que foi enviado. Utilizaremos esse comando para
buscar por entradas de log.
Figura 129: Identificando o comando enviado.
170
Para fazer essa busca, é necessário acessar o local onde os arquivos de
log estão armazenados e executar o comando
17
:
grep -r "<comando UI>" ./
No caso do exemplo apresentado o comando utilizado foi:
grep -r "command=deployVirtualMachine&response=json" ./
Assim, podemos identificar algumas entradas que trazem o comando bus-
cado. Nelas é possível visualizar o log id desejado. No caso deste exemplo
o ID é: logid:ef4bf833.
Figura 130: Identificando o logid do processo desejado.
2. Tendo o log id em mãos podemos filtrar as informações desejadas:
grep -r "<logid>" ./
Serão retornadas todas as entradas de log contendo esse log id:
./management-server.log:2022-03-15 12:38:40,334 DEBUG [c.c.a.ApiServlet]
(qtp1603198149-17:ctx-430e157a) (logid:ef4bf833) ===START=== 172.16.71.7 -- POST
command=deployVirtualMachine&response=json
[...]
./management-server.log:2022-03-15 12:38:41,471 DEBUG [c.c.v.UserVmManagerImpl]
(qtp1603198149-17:ctx-430e157a ctx-91e054dc) (logid:ef4bf833) Allocating in the DB for vm
./management-server.log:2022-03-15 12:38:41,545 INFO
[c.c.v.VirtualMachineManagerImpl] (qtp1603198149-17:ctx-430e157a ctx-91e054dc)
(logid:ef4bf833) allocating virtual machine from
template:b81aab72-2c37-466e-b53f-bdaf398322fa with hostname:i-2-119-VM and 1 networks
./management-server.log:2022-03-15 12:38:41,555 DEBUG
[c.c.v.VirtualMachineManagerImpl] (qtp1603198149-17:ctx-430e157a ctx-91e054dc)
(logid:ef4bf833) Allocating entries for VM: VM instance {id: "119", name:
"i-2-119-VM", uuid: "13fe0bce-a240-48e4-9d5b-081359fcf422", type="User"}
./management-server.log:2022-03-15 12:38:41,560 DEBUG
[c.c.v.VirtualMachineManagerImpl] (qtp1603198149-17:ctx-430e157a ctx-91e054dc)
(logid:ef4bf833) Allocating nics for VM instance {id: "119", name: "i-2-119-VM",
uuid: "13fe0bce-a240-48e4-9d5b-081359fcf422", type="User"}
./management-server.log:2022-03-15 12:38:41,568 DEBUG
[o.a.c.e.o.NetworkOrchestrator] (qtp1603198149-17:ctx-430e157a ctx-91e054dc)
(logid:ef4bf833) Allocating nic for vm VM instance {id: "119", name: "i-2-119-VM",
uuid: "13fe0bce-a240-48e4-9d5b-081359fcf422", type="User"} in network
Ntwk[211|Guest|11] with requested profile NicProfile[0-0-null-null-null]
./management-server.log:2022-03-15 12:38:41,653 DEBUG [c.c.n.NetworkModelImpl]
(qtp1603198149-17:ctx-430e157a ctx-91e054dc) (logid:ef4bf833) Service SecurityGroup
17
Também é possível substituir "./"no comando pelo path completo do diretório de logs.
Dessa forma não é necessário acessar o diretório para executá-lo
171
is not supported in the network id=211
./management-server.log:2022-03-15 12:38:41,660 DEBUG
[c.c.v.VirtualMachineManagerImpl] (qtp1603198149-17:ctx-430e157a ctx-91e054dc)
(logid:ef4bf833) Allocating disks for VM instance {id: "119", name: "i-2-119-VM",
uuid: "13fe0bce-a240-48e4-9d5b-081359fcf422", type="User"}
./management-server.log:2022-03-15 12:38:41,660 INFO [o.a.c.e.o.VolumeOrchestrator]
(qtp1603198149-17:ctx-430e157a ctx-91e054dc) (logid:ef4bf833) adding disk object
ROOT-119 to i-2-119-VM
./management-server.log:2022-03-15 12:38:41,700 DEBUG
[c.c.r.ResourceLimitManagerImpl] (qtp1603198149-17:ctx-430e157a ctx-91e054dc)
(logid:ef4bf833) Updating resource Type = volume count for Account = 2 Operation =
increasing Amount = 1
./management-server.log:2022-03-15 12:38:41,729 DEBUG
[c.c.r.ResourceLimitManagerImpl] (qtp1603198149-17:ctx-430e157a ctx-91e054dc)
(logid:ef4bf833) Updating resource Type = primary_storage count for Account = 2
Operation = increasing Amount = (50.00 MB) 52428800
./management-server.log:2022-03-15 12:38:41,962 DEBUG
[c.c.v.VirtualMachineManagerImpl] (qtp1603198149-17:ctx-430e157a ctx-91e054dc)
(logid:ef4bf833) Allocation completed for VM: VM instance {id: "119", name:
"i-2-119-VM", uuid: "13fe0bce-a240-48e4-9d5b-081359fcf422", type="User"}
./management-server.log:2022-03-15 12:38:41,962 DEBUG [c.c.v.UserVmManagerImpl]
(qtp1603198149-17:ctx-430e157a ctx-91e054dc) (logid:ef4bf833) Successfully
allocated DB entry for VM instance {id: "119", name: "i-2-119-VM", uuid:
"13fe0bce-a240-48e4-9d5b-081359fcf422", type="User"}
[...]
Podemos ver acima o horário em que o comando deployVirtualMachine foi
recebido (nesse caso 2022-03-15 12:38:40,334), além de diversas entradas
relacionadas à alocação de recursos para a criação da VM.
./management-server.log:2022-03-15 12:38:42,646 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(qtp1603198149-17:ctx-430e157a ctx-91e054dc) (logid:ef4bf833) submit async job-848, details:
AsyncJobVO {id:848, userId: 2, accountId: 2, instanceType: VirtualMachine, instanceId: 119, cmd
:org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin, cmdInfo:
{"iptonetworklist[0].networkid":"f8ce6644-6478-4770-84a7-834bd8a717a2","boottype":
"BIOS","httpmethod":"POST","templateid":"b81aab72-2c37-466e-b53f-bdaf398322fa","ctxAccountId":
"2","uuid":"13fe0bce-a240-48e4-9d5b-081359fcf422","cmdEventType":"VM.CREATE","startvm":
"true","bootmode":"LEGACY","serviceofferingid":"ab647165-7a0a-4984-8452-7bfceb036528",
"response":"json","ctxUserId":"2","zoneid":"8b2ceb16-a2f2-40ea-8968-9e08984bdb17",
"ctxStartEventId":"1499","id":"119","ctxDetails":"{\"interface com.cloud.dc.DataCenter\":
\"8b2ceb16-a2f2-40ea-8968-9e08984bdb17\",\"interface com.cloud.template.VirtualMachineTemplate
\": \"b81aab72-2c37-466e-b53f-bdaf398322fa\",\"interface com.cloud.offering.ServiceOffering\"
:\"ab647165-7a0a-4984-8452-7bfceb036528\",
\"interface com.cloud.vm.VirtualMachine\":\"13fe0bce-a240-48e4-9d5b-081359fcf422\"}",
"affinitygroupids":""}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0,
resultCode: 0, result: null, initMsid: 90520745551922, completeMsid: null,
lastUpdated: null, lastPolled: null, created: null, removed: null}
./management-server.log:2022-03-15 12:38:42,651 DEBUG [c.c.a.ApiServlet]
(qtp1603198149-17:ctx-430e157a ctx-91e054dc) (logid:ef4bf833) ===END===
172.16.71.7 -- POST command=deployVirtualMachine&response=json
Também podemos ver acima quando o comando foi finalizado
(2022-03-15 12:38:42,651). Um ponto importante a ser destacado é que
o tratamento da requisição demonstrado até aqui gera um job, que pode
ser processado por qualquer ACS Management Server do ambiente de
nuvem. Através da filtragem de entradas que contém o id desse job pode-
172
se obter mais informações a respeito da criação da VM (o mesmo se aplica
para outros processos do ACS). Na penúltima entrada de log exibida po-
demos ver que o job foi enviado às 2022-03 -1 5 12:38:42,646 e identificar
o job id que a requisição gerou: job-848.
3. Deve-se então buscar os logs contendo o job id encontrado, através do
comando:
grep -r "<job id>" ./
Dentre as informações retornadas, pode-se identificar o ID da thread que
processou o job:
[...]
./management-server.log:2022-03-15 12:38:42,647 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-5:ctx-c454c9f5 job-848) (logid:2f55511b) Executing AsyncJobVO
{id:848, userId: 2, accountId: 2, instanceType: VirtualMachine, instanceId: 119, cmd:
org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin, cmdInfo:
{"iptonetworklist[0].networkid":"f8ce6644-6478-4770-84a7-834bd8a717a2","boottype":
"BIOS","httpmethod":"POST","templateid":"b81aab72-2c37-466e-b53f-bdaf398322fa",
"ctxAccountId":"2","uuid":"13fe0bce-a240-48e4-9d5b-081359fcf422","cmdEventType":
"VM.CREATE","startvm":"true","bootmode":"LEGACY","serviceofferingid":
"ab647165-7a0a-4984-8452-7bfceb036528", "response":"json","ctxUserId":"2","zoneid":
"8b2ceb16-a2f2-40ea-8968-9e08984bdb17","ctxStartEventId":"1499","id":"119","ctxDetails":
"{\"interface com.cloud.dc.DataCenter\":\"8b2ceb16-a2f2-40ea-8968-9e08984bdb17\",
\"interface com.cloud.template.VirtualMachineTemplate\":\"b81aab72-2c37-466e-b53f-bdaf398322fa
\", \"interface com.cloud.offering.ServiceOffering\":\"ab647165-7a0a-4984-8452-7bfceb036528\",
\"interface com.cloud.vm.VirtualMachine\":\"13fe0bce-a240-48e4-9d5b-081359fcf422\"}",
"affinitygroupids":""}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0,
resultCode: 0, result: null, initMsid: 90520745551922, completeMsid: null,
lastUpdated: null, lastPolled: null, created: null, removed: null}
[...]
4. Finalmente, após sua identificação busca-se pelo ID da thread (logid:2f5
5511b) encontrado. É importante buscar por esse ID pois mais entradas
serão retornadas do que quando buscando pelo job id, o que torna o pro-
cesso de análise mais completo.
Utiliza-se o comando:
grep -r "<thread id>" ./
Dessa forma são obtidas diversas informações relacionadas à execução
do processo de criação da máquina virtual. Abaixo podemos ver, primei-
ramente, os logs relacionados à identificação do cluster e posteriormente
de um host onde a VM pode ser alocada. São checados os recursos exis-
tentes nas opções disponíveis e comparados com o que foi definido no
173
momento de criação da VM. Esse mesmo processo é repetido para ou-
tros hosts e, caso exista compatibilidade, eles são adicionados a uma lista
de hosts potenciais. A última entrada do log exibido abaixo, onde o host
31 é adicionada à lista, demonstra essa ação.
./management-server.log:2022-03-15 12:38:43,984 DEBUG [c.c.d.FirstFitPlanner]
(API-Job-Executor-5:ctx-c454c9f5 job-848 ctx-20458e85) (logid:2f55511b) Listing
clusters in order of aggregate capacity, that have (at least one host with) enough
CPU and RAM capacity under this Zone: 1
./management-server.log:2022-03-15 12:38:44,003 DEBUG [c.c.d.FirstFitPlanner]
(API-Job-Executor-5:ctx-c454c9f5 job-848 ctx-20458e85) (logid:2f55511b) Removing
from the clusterId list these clusters from avoid set: []
./management-server.log:2022-03-15 12:38:44,054 DEBUG
[c.c.d.DeploymentPlanningManagerImpl] (API-Job-Executor-5:ctx-c454c9f5 job-848
ctx-20458e85) (logid:2f55511b) Checking resources in Cluster: 1 under Pod: 1
./management-server.log:2022-03-15 12:38:44,078 DEBUG
[c.c.a.m.a.i.FirstFitAllocator] (API-Job-Executor-5:ctx-c454c9f5 job-848
ctx-20458e85 FirstFitRoutingAllocator) (logid:2f55511b) Looking for hosts in dc: 1
pod:1 cluster:1
./management-server.log:2022-03-15 12:38:44,091 DEBUG
[c.c.a.m.a.i.FirstFitAllocator] (API-Job-Executor-5:ctx-c454c9f5 job-848
ctx-20458e85 FirstFitRoutingAllocator) (logid:2f55511b) FirstFitAllocator has 3
hosts to check for allocation: [Host {"id": "31", "name": "cloudstack-lab-host-3",
"uuid": "2fd584d8-9fc3-4666-98f8-17f3e43e4348", "type"="Routing"}, Host {"id":
"30", "name": "cloudstack-lab-host-2", "uuid":
"3d7d8532-d0cf-476c-a36e-1b936d780abb", "type"="Routing"}, Host {"id": "29",
"name": "cloudstack-lab-host-1", "uuid": "11662552-8221-4081-92b5-a3f2c852754a",
"type"="Routing"}]
./management-server.log:2022-03-15 12:38:44,145 DEBUG
[c.c.a.m.a.i.FirstFitAllocator] (API-Job-Executor-5:ctx-c454c9f5 job-848
ctx-20458e85 FirstFitRoutingAllocator) (logid:2f55511b) Looking for speed=500Mhz, Ram=512 MB
./management-server.log:2022-03-15 12:38:44,146 DEBUG [c.c.c.CapacityManagerImpl]
(API-Job-Executor-5:ctx-c454c9f5 job-848 ctx-20458e85 FirstFitRoutingAllocator)
(logid:2f55511b) Host {id: 31, name: cloudstack-lab-host-3, uuid:
2fd584d8-9fc3-4666-98f8-17f3e43e4348} is KVM hypervisor type, no max guest limit check needed
./management-server.log:2022-03-15 12:38:44,173 DEBUG [c.c.c.CapacityManagerImpl]
(API-Job-Executor-5:ctx-c454c9f5 job-848 ctx-20458e85 FirstFitRoutingAllocator)
(logid:2f55511b) Host: 31 has cpu capability (cpu:6, speed:2394) to support
requested CPU: 1 and requested speed: 500
./management-server.log:2022-03-15 12:38:44,189 DEBUG [c.c.c.CapacityManagerImpl]
(API-Job-Executor-5:ctx-c454c9f5 job-848 ctx-20458e85 FirstFitRoutingAllocator)
(logid:2f55511b) Hosts's actual total CPU: 14364 and CPU after applying
overprovisioning: 14364
./management-server.log:2022-03-15 12:38:44,189 DEBUG [c.c.c.CapacityManagerImpl]
(API-Job-Executor-5:ctx-c454c9f5 job-848 ctx-20458e85 FirstFitRoutingAllocator)
(logid:2f55511b) Free RAM: (14.38 GB) 15444189184 , Requested RAM: (512.00 MB) 536870912
./management-server.log:2022-03-15 12:38:44,190 DEBUG [c.c.c.CapacityManagerImpl]
(API-Job-Executor-5:ctx-c454c9f5 job-848 ctx-20458e85 FirstFitRoutingAllocator)
(logid:2f55511b) Host has enough CPU and RAM available
./management-server.log:2022-03-15 12:38:44,191 DEBUG [c.c.c.CapacityManagerImpl]
(API-Job-Executor-5:ctx-c454c9f5 job-848 ctx-20458e85 FirstFitRoutingAllocator)
(logid:2f55511b) STATS: Can alloc MEM from host: 31, used: (256.00 MB) 268435456,
reserved: (0 bytes) 0, total: (14.63 GB) 15712624640; requested mem: (512.00 MB)
536870912, alloc_from_last_host?: false , considerReservedCapacity?: true
./management-server.log:2022-03-15 12:38:44,191 DEBUG
[c.c.a.m.a.i.FirstFitAllocator] (API-Job-Executor-5:ctx-c454c9f5 job-848
ctx-20458e85 FirstFitRoutingAllocator) (logid:2f55511b) Found a suitable host,
adding to list: 31
Nas próximas entradas pode-se verificar que é feita a busca por uma sto-
174
rage compatível, além da verificação da existência de potenciais hosts com
acesso ao storage.
./management-server.log:2022-03-15 12:38:45,069 DEBUG [c.c.s.StorageManagerImpl]
(API-Job-Executor-5:ctx-c454c9f5 job-848 ctx-20458e85) (logid:2f55511b) Found
storage pool storage-1-iscsi of type SharedMountPoint
./management-server.log:2022-03-15 12:38:45,069 DEBUG [c.c.s.StorageManagerImpl]
(API-Job-Executor-5:ctx-c454c9f5 job-848 ctx-20458e85) (logid:2f55511b) Total
capacity of the pool storage-1-iscsi with ID 5 is (50.00 GB) 53687091200
./management-server.log:2022-03-15 12:38:45,079 DEBUG [c.c.s.StorageManagerImpl]
(API-Job-Executor-5:ctx-c454c9f5 job-848 ctx-20458e85) (logid:2f55511b) Checking
pool: 5 for storage allocation , maxSize : (50.00 GB) 53687091200,
totalAllocatedSize : (9.20 GB) 9878175856, askingSize : (50.00 MB) 52428800,
allocated disable threshold: 0.85
./management-server.log:2022-03-15 12:38:45,090 DEBUG
[c.c.d.DeploymentPlanningManagerImpl] (API-Job-Executor-5:ctx-c454c9f5 job-848
ctx-20458e85) (logid:2f55511b) Trying to find a potenial host and associated
storage pools from the suitable host/pool lists for this VM
./management-server.log:2022-03-15 12:38:45,093 DEBUG
[c.c.d.DeploymentPlanningManagerImpl] (API-Job-Executor-5:ctx-c454c9f5 job-848
ctx-20458e85) (logid:2f55511b) Checking if host: 31 can access any suitable storage
pool for volume: ROOT
./management-server.log:2022-03-15 12:38:45,096 DEBUG
[c.c.d.DeploymentPlanningManagerImpl] (API-Job-Executor-5:ctx-c454c9f5 job-848
ctx-20458e85) (logid:2f55511b) Host: 31 can access pool: 5
Após todas as checagens realizadas, são identificados nas entradas de
log abaixo um host e storage que são compatíveis com a VM e, posterior-
mente, os mesmos utilizados para a sua criação.
./management-server.log:2022-03-15 12:38:45,100 DEBUG
[c.c.d.DeploymentPlanningManagerImpl] (API-Job-Executor-5:ctx-c454c9f5 job-848
ctx-20458e85) (logid:2f55511b) Found a potential host id: 31 name:
cloudstack-lab-host-3 and associated storage pools for this VM
./management-server.log:2022-03-15 12:38:45,103 DEBUG
[c.c.d.DeploymentPlanningManagerImpl] (API-Job-Executor-5:ctx-c454c9f5 job-848
ctx-20458e85) (logid:2f55511b) Returning Deployment Destination:
Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] :
Dest[Zone(1)-Pod(1)-Cluster(1)-Host(31)-Storage(Volume(117|ROOT-->Pool(5))]
[...]
./management-server.log:2022-03-15 12:38:59,918 DEBUG
[c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-11:ctx-b5892741
job-848/job-849 ctx-b5ac54d3) (logid:2f55511b) Start completed for VM, VM instance
{id: "119", name: "i-2-119-VM", uuid: "13fe0bce-a240-48e4-9d5b-081359fcf422",
type="User"}
./management-server.log:2022-03-15 12:38:59,923 DEBUG [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-11:ctx-b5892741 job-848/job-849 ctx-b5ac54d3) (logid:2f55511b)
Done executing VM work job:
com.cloud.vm.VmWorkStart{"dcId":1,"podId":1,"clusterId":1,"hostId":31,"rawParams":
{"VmPassword":"rO0ABXQADnNhdmVkX3Bhc3N3b3Jk"},"userId":2,"accountId":2,"vmId":119,
"handlerName":"VirtualMachineManagerImpl"}
[...]
Finalmente podemos ver o momento em que o processo foi finalizado
pelo ACS (2022-03-15 12:39:00,827).
[...]
./management-server.log:2022-03-15 12:39:00,585 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-5:ctx-c454c9f5 job-848
175
ctx-20458e85) (logid:2f55511b) Publish async job-848 complete on message bus
./management-server.log:2022-03-15 12:39:00,585 DEBUG
[o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-5:ctx-c454c9f5 job-848
ctx-20458e85) (logid:2f55511b) Wake up jobs related to job-848
./management-server.log:2022-03-15 12:39:00,585 DEBUG
[o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-5:ctx-c454c9f5 job-848
ctx-20458e85) (logid:2f55511b) Update db status for job-848
./management-server.log:2022-03-15 12:39:00,593 DEBUG
[o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-5:ctx-c454c9f5 job-848
ctx-20458e85) (logid:2f55511b) Wake up jobs joined with job-848 and disjoin all
subjobs created from job- 848
./management-server.log:2022-03-15 12:39:00,827 DEBUG
[o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-5:ctx-c454c9f5 job-848)
(logid:2f55511b) Done executing
org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin for job-848
./management-server.log:2022-03-15 12:39:00,827 INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-
Executor-5:ctx-c454c9f5 job-848) (logid:2f55511b) Remove job-848 from job monitoring
Assim, conforme demonstrado acima, a análise de logs do ACS foi utilizada
para investigar e acompanhar todo o ciclo de criação da VM. Os mesmos princí-
pios aplicados aqui podem ser adaptados e utilizados para explorar quaisquer
eventos.
É muito comum o uso dessa análise no CloudStack para investigar erros,
falhas, entre outros. O comando a seguir pode ser utilizado para buscar por
logs problemáticos:
grep -i -E 'exception|unable|fail|invalid|leak|warn|error' ./
Com tal análise é possível obter um grande volume de informações, tor-
nando o processo de troubleshooting bastante eficiente.
7.2. Failover de hosts
No ACS, existe uma função chamada host HA, onde o objetivo é garantir
que quando um host estiver apresentando alguma falha, ele será desligado (via
interface OOBM) e as VMs que estão rodando nele serão recriadas (reiniciadas)
em outro host que está disponível no ambiente.
A nomenclatura utilizada no ACS: host HA, ou host high availability, é errônea.
O conceito de high availability dita que quando um dos nós utilizados para pro-
ver um serviço para de funcionar, o usuário não percebe essa falha, pois existe
uma réplica dele pronta para uso em outro nó do ambiente. No entanto, não
é isso que ocorre com o host HA do ACS. As VMs dos usuários serão paradas
176
e recriadas em outro host, causando interrupções. Esse comportamento é ca-
racterizado como failover, e não HA.
Deve-se tomar cuidado ao parar os KVM Agents quando a configuração host
HA estiver habilitada, pois o ACS julgará que ouve uma falha e fará o shutdown
do host (via interface OOBM), causando um comportamento indesejado. Nes-
tes casos, o procedimento recomendado é:
1. Habilitar o modo manutenção do host;
2. Migrar todas as VMs;
3. Desabilitar o processo de HA para o host em manutenção;
4. Realizar a operação desejada;
5. Desabilitar o modo manutenção;
6. Reabilitar o processo de HA.
7.3. Gerenciamento dos serviços do Apache CloudStack
Nesta seção serão explicadas algumas operações básicas relacionadas ao
gerenciamento dos serviços cloudstack-management, cloudstack-agent (so-
mente para KVM) e cloudstack-usage.
7.3.1. Gerenciamento do cloudstack-management
Em alguns momentos do fluxo de trabalho, nas atualizações, por exemplo,
é necessário parar e iniciar novamente os Managements Servers para que as
alterações sejam aplicadas. Em outros, como em alterações de configurações,
é necessário apenas reiniciá-los. Para tais procedimentos, seguem os passos:
• Início: assim que realizado, o Management Server começará a carregar
os módulos. Ele só estará disponível assim que os módulos estejam car-
regados.
– Para iniciar o serviço do Management Server, basta executar o co-
mando:
systemctl start cloudstack-management.service
177
– Após iniciado, é possível verificar o status do serviço através do co-
mando:
systemctl status cloudstack-management.service
– É possível acompanhar o carregamento dos módulos através dos
logs:
tail -f /var/log/cloudstack/management/management-server.log
• Parada: assim que realizada, caso só exista uma instância do Manage-
ment Server, não será mais possível interagir com o orquestrador.
– Para parar o serviço do Management Server, basta executar o co-
mando:
systemctl stop cloudstack-management.service
– Após a parada do serviço, é possível verificar o status do mesmo atra-
vés do comando:
systemctl status cloudstack-management.service
• Reinício: realizará a parada e o início do Management Server. Terá o
mesmo comportamento do "início", quanto ao carregamento dos módu-
los.
– Para reiniciar o serviço do Management Server, basta executar o co-
mando:
systemctl restart cloudstack-management.service
– Após reiniciado, é possível verificar o status do serviço através do
comando:
systemctl status cloudstack-management.service
– É possível acompanhar o carregamento dos módulos através dos
logs:
178
tail -f /var/log/cloudstack/management/management-server.log
Esse processo não deve ser executado simultaneamente nos Management
Servers, pois caso todos estejam parados não será possível utilizar o Cloud-
Stack.
7.3.2. Gerenciamento do cloudstack-agent para hypervisor KVM
Em clusters onde o hypervisor utilizado é o KVM, existe o componente cha-
mado CloudStack Agent. Em alguns momentos do fluxo de trabalho, durante
atualizações, por exemplo, é necessário pará-los e iniciá-los novamente para
que as alterações sejam aplicadas. Em outros casos, como em alterações de
configurações, é necessário apenas reiniciá-los. Caso o host HA esteja ligado, é
recomendado desliga-lo antes de realizar a parada e o reinício. Para tais pro-
cedimentos, seguem os passos:
• Início: assim que realizado, o CloudStack Agent tentará se conectar ao
Management Server.
– Para iniciar o serviço do CloudStack Agent, basta executar o comando:
systemctl start cloudstack-agent.service
– Após iniciado, é possível verificar o status do serviço através do co-
mando:
systemctl status cloudstack-agent.service
– É possível acompanhar a inicialização do CloudStack Agent através
dos logs:
tail -f /var/log/cloudstack/agent/agent.log
• Parada: assim que realizada, todas as máquinas virtuais presentes no host
continuarão funcionando normalmente, no entanto o CloudStack não con-
seguirá gerenciá-las, nem criar novas instâncias.
179
– Para parar o serviço do CloudStack Agent, basta executar o comando:
systemctl stop cloudstack-agent.service
– Após parado o serviço, é possível verificar o status do mesmo através
do comando:
systemctl status cloudstack-agent.service
• Reinício: realizará a parada e o início do CloudStack Agent. Terá o mesmo
comportamento do "início", quanto à conexão com o CloudStack.
– Para reiniciar o serviço do CloudStack Agent, basta executar o co-
mando:
systemctl restart cloudstack-agent.service
– Após reiniciado, é possível verificar o status do serviço através do
comando:
systemctl status cloudstack-agent.service
– É possível acompanhar a inicialização do CloudStack Agent através
dos logs:
tail -f /var/log/cloudstack/agent/agent.log
7.3.3. Gerenciamento do cloudstack-usage
Em alguns momentos, como por exemplo ao alterar as configurações do
Usage Server, é necessário reiniciar o mesmo para que as alterações sejam
aplicadas. Para tais procedimentos, seguem os passos:
• Início:
– Para iniciar o serviço do Usage Server, basta executar o comando:
systemctl start cloudstack-usage.service
– Após iniciado, é possível verificar o status do serviço através do co-
mando:
180
systemctl status cloudstack-usage.service
• Parada:
– Para parar o serviço do Usage Server, basta executar o comando:
systemctl stop cloudstack-usage.service
– Após a parada do serviço, é possível verificar o status do mesmo atra-
vés do comando:
systemctl status cloudstack-usage.service
• Reinício: realizará a parada e o início do Usage Server.
– Para reiniciar o serviço do Usage Server, basta executar o comando:
systemctl restart cloudstack-usage.service
– Após reiniciado, é possível verificar o status do serviço através do
comando:
systemctl status cloudstack-usage.service
7.4. System VMs
Na arquitetura do Apache CloudStack, existem as chamadas system VMs,
que são instâncias criadas e gerenciadas pelo próprio ACS para auxiliar no pro-
visionamento de alguns serviços da nuvem. Cada instância possui um IP pú-
blico.
Por padrão, elas possuem apenas o usuário root, cuja senha é password.
É possível configurar o ACS para definir uma senha aleatória ao fazer boot da
system VM. A seção Randomizando a senha das System VMs descreve os deta-
lhes. Porém, vale destacar que não é possível acessar as system VMs via SSH
com usuário e senha. Para mais informações vá em 7.4.4
Existem três tipos de system VMs:
Console Proxy Virtual Machine(CPVM), Secondary Storage Virtual Machine(SSVM)
e Virtual Router(VR).
181
7.4.1. Console Proxy Virtual Machine
As CPVMs, identificadas no ACS pelo nome v-<id>-VM, fornecem acesso aos
consoles das VMs gerenciadas pelo CloudStack. Elas funcionam por meio de
Virtual Network Computing (VNC), que é um sistema de compartilhamento de in-
terfaces gráficas de usuário, o qual utiliza um protocolo chamado Remote Frame
Buffer (RFB) para transmitir o input do mouse e teclado de um computador a
outro enviando as atualizações da tela por meio de uma rede. O usuário se
conecta à CPVM, que então realiza uma conexão proxy com a VM selecionada
permitindo o acesso ao seu console remotamente.
Figura 131: Console Proxy Virtual Machine
7.4.2. Secondary Storage Virtual Machine
As SSVMs, identificadas no ACS pelo nome s-<id>-VM, possibilitam o pro-
cesso de registro de templates e ISOs, bem como download e upload de templa-
tes, ISOs, e volumes.
Figura 132: Secondary Storage Virtual Machine
182
7.4.3. Virtual Router
Os VRs, identificados no ACS pelo nome r-<id>-VM, são a interface entre as
VMs e o mundo, gerenciando as redes e permitindo a implementação de VPNs,
regras de firewall, port-forwarding e outros. Cada rede isolada, compartilhada
ou VPC criada no ACS terá um VR.
Figura 133: Virtual Router
7.4.3.1. Virtual Router health checks
O CloudStack oferece uma estrutura para verificações de integridade dos vir-
tual routers. Esses health checks são divididos em básicos e avançados para que
se possa atribuir intervalos de execução diferentes, com os avançados sendo
mais custosos do ponto de vista computacional e, portanto, executados com
menor frequência.
Além dos testes periódicos, também se pode forçar uma rodada de verifica-
ções através da chamada de API getRouterHealthCheckResults, contanto que
a configuração global router.health.checks.enabled esteja habilitada.
183
Figura 134: Visão dos health checks de determinado VR.
Os pontos testados são:
• Conectividade entre o virtual router e os Management Servers;
• Conectividade aos gateways das interfaces do virtual router;
• Espaço livre em disco;
• Utilização de CPU e memória;
• Status dos serviços de SSH, DNS, HAProxy e HTTP.
Com os avançados sendo:
• Versão do virtual router;
• Correspondência entre a configuração do DHCP/DNS e os metadados do
ACS;
184
• Correspondência entre a configuração do HAProxy e os metadados do
ACS;
• Correspondência entre as regras do iptables e os metadados do ACS.
Não é necessário realizar a configuração manual das tabelas do iptables,
sendo possível utilizar a API ou a própria interface web para isso. A edição e
atualização das tabelas será feita pelo CloudStack.
Os health checks podem ser ajustados através das seguintes configurações
globais:
185
Nome Descrição Valor
Padrão
router.alerts.check.interval Intervalo em segundos para veri-
ficar alertas no VR.
1800
router.health.checks.enabled Habilita ou desabilita os health
checks no VR.
true
router.health.checks.basic.
interval
Intervalo em minutos entre as
execuções de health checks bási-
cos. Se 0, nenhum teste será
agendado.
3
router.health.checks.advanced.
interval
Intervalo em minutos entre as
execuções de health checks avan-
çados. Se 0, nenhum teste será
agendado.
10
router.health.checks.config.
refresh.interval
Intervalo em minutos entre atu-
alizações da configuração dos
health checks no VR pelo Manage-
ment Server.
∗
10
router.health.checks.results.
fetch.interval
Intervalo em minutos entre
atualizações dos resultados dos
health checks nos Management
Servers. A cada atualização, os
Management Servers avaliam
a necessidade de recriar o VR
conforme a configuração router.
health.che cks.failures.to.r ecreat
e.vr.
∗
10
router.health.checks.failures.
to.recreate.vr
Falhas nos health checks defini-
dos por esta configuração cau-
sam a recriação do VR. Se esti-
ver vazio, a recriação não será
tentada para nenhuma falha de
health check.
router.health.checks.to.exclude Determina quais health checks
devem ser ignorados ao executar
verificações agendadas. Lista se-
parada por vírgulas de nomes de
scripts na pasta /root/health_che
cks/.
186
Nome Descrição Valor
Padrão
router.health.checks.free.disk.
space.threshold
Limite mínimo do espaço em
disco livre do VR em MB antes de
resultar em falha.
100
router.health.checks.max.
cpu.usage.threshold
Utilização máxima de CPU do VR
em porcentagem antes de resul-
tar em falha.
100
router.health.checks.max.
memory.usage.threshold
Utilização máxima de memória
do VR em porcentagem antes de
resultar em falha.
100
∗ Esse valor deve ser suficientemente maior que router.health.checks. ( basic/advanced).interv
al para que haja tempo entre a atualização e a geração de resultados.
7.4.4. Acesso às system VMs
Existem três formas de acessar a System VM via ssh, que dependem de qual
é o hypervisor utilizado:
1. Caso esteja utilizando KVM ou XenServer, o acesso ocorre via host no qual
a System VM está rodando:
ssh -i /root/.ssh/id_rsa.cloud -p 3922 root@<IP_INTERNO_SYSTEMVM>
2. Caso o hypervisor seja o KVM, também existe um alias para o comando
acima, facilitando seu uso:
cloudstack-ssh <IP_INTERNO_SYSTEMVM>
3. Por fim, caso o hypervisor seja o VMware, é necessário acessar através do
Management Server utilizando o comando:
ssh root@<IP_INTERNO_SYSTEMVM> -p 3922 -i /var/lib/cloudstack/management/.ssh/id_rsa
7.4.5. Randomização de senha das system VMs
Por questões de segurança, pode ser interessante randomizar a senha das
System VMs. É possível configurar o ACS para fazer tal tarefa sempre que as
System VMs forem inicializadas. Para isso, siga os passos:
1. Mude a configuração system.vm.random.password para true;
187
2. Reinicie o Management Server;
3. Para que as System VMs tenham suas senhas de root mudadas, é neces-
sário destruí-las para que o ACS as crie com a nova senha;
4. A senha gerada estará no parâmetro system.vm.password, que pode ser
verificado nas Global Settings.
A senha recuperada do parâmetro system.vm.password estará criptografada.
Para abrir a senha, siga os seguintes passos:
1. Acesse o Management Server;
2. Recupere a senha do ambiente utilizando o comando:
cat /etc/cloudstack/management/key
3. Verifique qual a versão do arquivo jasypt se encontra na pasta /usr/shar
e/cloudstack-common/lib/;
4. Descriptografe a senha com o comando:
java -classpath /usr/share/cloudstack-common/lib/jasypt-<versão>.jar \
org.jasypt.intf.cli.JasyptPBEStringDecryptionCLI \
input="<senha_a_ser_descriptografada>" password=<senha_do_ambiente> verbose="false"
É importante notar que uma vez configurada a senha, ela não será mais alte-
rada automaticamente pelo ACS. A senha criptografada que aparece no Global
Settings sempre será diferente em cada refresh da interface web, contudo, a se-
nha real será a mesma.
7.4.6. URL para consumo da CPVM e SSVM
Ao realizar o upload/download de volumes/templates/ISOs ou acessar o con-
sole de uma VM, os serviços são consumidos via uma URL. Essas URLs são de-
finidas de acordo com as seguintes configurações globais.
Configuração Descrição
consoleproxy.url.domain Domínio utilizado pelas console
proxy VMs.
secstorage.ssl.cert.domain Domínio utilizado pelas secon-
dary storage VMs.
188
Baseado nestas configurações, a URL para consumo dos serviços das System
VMs pode possuir três formatos:
• Vazio: o IP público da System VM é utilizado; por exemplo, 172.16.200.100.
• Estático (demo.com.br): o domínio é utilizado; nesse exemplo, demo.com.br.
Essa abordagem funciona quando há somente uma CPVM ou SSVM. Quando
há mais de uma, é necessário discriminar em qual VM ocorrerá o acesso
através do formato dinâmico.
• Dinâmico (*.demo.com.br): o IP público da System VM é utilizado em con-
junto com o domínio; por exemplo, 172-16-200-100.demo.com.br.
7.5. Habilitação do aumento de recursos computacionais das VMs
Apesar da funcionalidade ser suportada pelos virtualizadores VMware, Xen-
Server e KVM, a presente seção irá demonstrar somente como preparar o am-
biente com o virtualizador KVM para viabilizar a alteração de recursos compu-
tacionais (RAM e CPU) com a VM em execução. No contexto do virtualizador
KVM, essa funcionalidade existe com algumas ressalvas:
• A VM deve estar configurada como dynamically scalable;
• A compute offering type da VM em questão precisa ser do tipo custom cons-
trained ou custom unconstrained;
• O sistema operacional da VM deve suportar hot (un)plug de memória e
CPU, ou seja, deve possuir a funcionalidade de alocar e remover tais re-
cursos físicos em período de runtime;
18
• Não é possível trocar a família de vGPU nem de CPU da VM com a mesma
em execução, já que os sistemas operacionais em geral não suportam
esse tipo de substituição com a VM rodando;
18
Por padrão, o kernel do Linux e Windows já suportam essa funcionalidade.
189
• Não é possível diminuir os recursos da VM diretamente, apenas aumen-
tar. Porém, caso haja a necessidade de realizar o downgrade de uma VM,
o usuário pode pará-la e alterar a sua compute offering para uma oferta
menor;
Para ativar essa feature, é necessário mudar a configuração global enable.d
ynamic.scale.vm, cujo valor padrão é false, para true.
7.6. Overprovisioning
Overprovisioning é a função de ofertar mais recursos virtuais do que real-
mente há fisicamente. Isso existe devido a como o CloudStack considera os
recursos utilizados e como os virtualizadores trabalham com memória e CPU.
Vamos considerar uma situação em que há um storage de 100Gb (100%) e
será criada uma VM com uma oferta de disco de 20Gb (20%). Para o CloudStack,
o disco da VM estará consumindo 20Gb (20%) e o storage terá 80Gb (80%) livres.
No entanto, na maioria dos casos (depende do Provisioning Type da oferta de
disco), os discos serão alocados dinamicamente (criados com o mínimo possí-
vel de tamanho e aumentarão conforme a necessidade - até o limite proposto).
Ou seja, o CloudStack contará 20Gb (20%), mas o disco terá um tamanho va-
riável entre 0Gb e 20Gb. Em muitos casos o disco ofertado não é consumido
ao máximo pelo usuário, o que deixaria espaço livre para outros discos serem
alocados.
O CloudStack contabiliza 20Gb (20%) de disco para a VM e 80Gb (80%) livres
no storage, porém o valor real (nessa situação proposta) é de 10Gb (10%) de
disco para a VM e 90Gb (90%) livres no storage. Ao fim dos cálculos haverá
espaço livre no storage, porém não será possível utilizá-lo pois o CloudStack o
considera como alocado.
Para a situação descrita acima, é possível configurar o CloudStack para con-
siderar mais recursos do que há fisicamente. Configurando-o para 2x, o total
de storage que haveria seria de 200Gb (100%) e seria usado 20Gb dele (10%),
190
restando 180Gb livres (90%).
Para a questão de memória, o KVM possui a feature KSM, que realiza com-
partilhamento de blocos de memória. Assim, quanto mais homogêneos forem
as cargas de trabalho (VMs), maior será o ganho de otimização de memória.
Em uma situação onde existam 10 VMs com as mesmas configurações de
disco, sistema operacional, CPU e memória de 2Gb, por exemplo, o cálculo
de consumo de memória seria de 20Gb, no entanto, devido ao KSM, muitos
dos blocos são compartilhados e o valor final será menor, o que possibilitará
realizar um overprovisioning de memória.
Atualmente existem 5 configurações de overprovisioning, sendo elas:
Configuração Descrição Valor
Padrão
cpu.overprovisioning.factor Valor utilizado como fa-
tor de overprovisioning para
CPU. A CPU disponível ao fi-
nal do cálculo será a atual *
fator.
1.0
mem.overprovisioning.factor Valor utilizado como fa-
tor de overprovisioning para
memória. A memória dis-
ponível ao final do cálculo
será a atual * fator.
1.0
storage.overprovisioning.factor Valor utilizado como fa-
tor de overprovisioning para
storage. O storage disponí-
vel ao final do cálculo será
o atual * fator.
2.0
vm.min.cpu.speed.equals.cpu.speed.divided.
by.cpu.overprovisioning.factor
Quando utilizado over-
provisioning, o ACS
informa um valor mí-
nimo de CPU, sendo este
CPU/overprovisioning, in-
dependente de usar uma
oferta de serviço escalável.
Essa configuração controla
se esse comportamento
será executado.
true
191
Configuração Descrição Valor
Padrão
vm.min.memory.equals.memory.divided.by.
mem.overprovisioning.factor
Quando utilizado over-
provisioning, o ACS in-
forma um valor mínimo
de RAM, sendo este
RAM/overprovisioning,
independente de usar uma
oferta de serviço escalável.
Essa configuração controla
se esse comportamento
será executado.
true
Tanto para a configuração vm.min.cpu.speed.e quals.cpu.speed.div ided .b
y.cpu.overprovisioning.factor quanto para a vm.min.memory.equals.mem or
y.divided.by. mem.overprovisioning.factor o valor padrão é true para manter
o comportamento já existente, porém recomendamos a alteração para false,
pois entendemos que é um cálculo incoerente executado pelo CloudStack no
deploy e migração de VMs.
Exceto pela configuração storage.overprovisioning.factor, que funciona a
nível de Zone, todas as demais funcionam a nível de Cluster.
Em relação ao overprovisioning de CPU e memória, ao ser alterado o valor
das configurações, as VMs necessitam ser desligadas e ligadas novamente para
que o CloudStack calcule o valor alocado corretamente.
7.7. Atualização do Apache CloudStack
Periodicamente a versão LTS do Apache CloudStack é atualizada. Esta seção
discorrerá sobre os passos necessários para realizar a atualização. As mudan-
ças, pré-requisitos específicos e links para os pacotes da release se encontram
na seção Deployments > Releases do projeto no Gitlab.
7.7.1. Atualização entre major versions
Após cumpridos os pré-requisitos e feito o download dos arquivos, estes
são os passos para atualização do Management Server entre major versions:
192
1. Pare o serviço do Management Server:
systemctl stop cloudstack-management
2. Pare o serviço do Usage Server:
systemctl stop cloudstack-usage
3. Faça dump do banco cloud:
mysqldump -u root -p cloud > cloud-backup-before-update-`date '%Y-%m-%d-%H:%M:%S.%3N'`.sql
4. Faça dump do banco cloud_usage:
mysqldump -u root -p cloud_usage > \
cloud_usage-backup-before-update-`date +'%Y-%m-%d-%H:%M:%S.%3N'`.sql
5. Instale os novos pacotes do ACS Management Server (haverá um sufixo
da versão nos arquivos baixados):
• Para .deb:
apt install cloudstack-common~bionic_all.deb cloud-stack-management~bionic_all.deb \
cloudstack-usage~bionic_all.deb cloudstack-ui~bionic_all.deb
• Para .rpm:
yum install cloudstack-common.1.el7.centos.x86_64.rpm \
cloudstack-management.1.el7.centos.x86_64.rpm \
cloudstack-usage.1.el7.centos.x86_64.rpm cloudstack-ui.1.el7.centos.x86_64.rpm
6. Inicie o serviço do Management Server:
systemctl start cloudstack-management
7. Inicie o serviço do Usage Server:
systemctl start cloudstack-usage
Caso o hypervisor utilizado seja o KVM, siga os seguintes passos para a atu-
alização dos CloudStack Agents:
1. Pare o serviço do CloudStack Agent:
systemctl stop cloudstack-agent
2. Instale os novos pacotes do CloudStack Agent (haverá um sufixo da versão
nos arquivos baixados):
193
• Para .deb:
apt install cloudstack-common~bionic_all.deb cloudstack-agent~bionic_all.deb
• Para .rpm:
yum install cloudstack-common.1.el7.centos.x86_64.rpm \
cloudstack-agent.1.el7.centos.x86_64.rpm
3. Inicie o serviço do CloudStack Agent:
systemctl start cloudstack-agent
Para finalizar a atualização do Management Server:
8. Force o reinício das system VMs para elas subirem com o novo template. As
instruções para forçar o reinício das system VMs estão na documentação
oficial;
9. Reinicie o serviço do Management Server:
systemctl restart cloudstack-management
7.7.2. Atualização dentro da mesma major version
Para a instalação de uma atualização da mesma major version, é preciso ler
atentamente as releases para verificar se a atualização é referente ao Mana-
gement Server ou ao CloudStack Agent. Quando for um update referente ao
Management Server, basta seguir os passos 1 a 7 da atualização do Manage-
ment Server. Já quando a atualização for referente ao CloudStack Agent, basta
seguir os passos descritos na atualização do KVM Agent.
É sempre importante checar as releases no Gitlab, pois além de informa-
ções importantes sobre pré-requisitos e mudanças, também podem ser lança-
das notas sobre a versão, que devem ser lidas com atenção antes de iniciar o
processo da atualização para uma versão específica do ACS.
7.8. Atualização do certificado SSL no ambiente (nginx e ACS)
As etapas a seguir apresentam os passos necessários para realizar a atuali-
zação dos certificados SSL no nginx e o upload dos mesmos para o ACS.
194
7.8.1. Extração dos certificados intermediários e root
Nota: Este passo é necessário caso o cliente possua apenas o certificado
final.
Para realizar a extração dos certificados, é necessário dividir o certificado
final em dois arquivos: um contendo o certificado em si e o outro contendo a
chave privada. Após, o certificado intermediário é extraído com os comandos:
user@scclouds :~ $ openssl x509 -in <domain>.crt -text -noout | grep -i 'issuer'
Issuer: C = US, ST = TX, L = Houston, O = "cPanel, Inc.", CN = "cPanel, Inc.
Certification Authority"
CA Issuers - URI:http://crt.comodoca.com/cPanelIncCertificationAuthority.crt
user@scclouds :~ $ curl -o caIntermediate
http://crt.comodoca.com/cPanelIncCertificationAuthority.crt
user@scclouds :~ $ open x509 -inform DER -in caIntermediate -outform PEM -out
caIntermediate.crt
Com o certificado intermediário extraído, é necessário extrair o certificado
root:
user@scclouds :~ $ openssl x509 -in caIntermediate.crt -text -noout | grep -i 'issuer'
Issuer: C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN =
COMODO RSA Certification Authority
CA Issuers - URI:http://crt.comodoca.com/COMODORSAAddTrustCA.crt
user@scclouds :~ $ curl -o caRoot http://crt.comodoca.com/COMODORSAAddTrustCA.crt
user@scclouds :~ $ openssl x509 -inform DER -in caRoot -outform PEM -out caRoot.crt
7.8.2. Conversão de chave para PKCS#8:
user@scclouds :~$ openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in
<domain>.key -out <domain>.pkcs8.key
7.8.3. Adição de certificado no nginx
É necessário alterar os arquivos /etc/nginx/certificates/domain.com.br.crt e
/etc/nginx/certificates/domain.com.br.pem com o conteúdo do certificado e da
chave privada desejada. Após, basta reiniciar o serviço do ngin x com o co-
mando:
systemctl restart nginx.service
7.8.4. Adição de certificado no Apache CloudStack
A adição do certificado pode ser realizada via UI e via CloudMonkey:
Via UI:
195
Figura 135: Adicionando certificado SSL via UI
Via CloudMonkey, os certificados são adicionados com a API uploadCustom-
Certificate.
• Certificado root
Em um terminal, faça a chamada da API uploadCustomCertificate passando
os parâmetros id=1, name=root, domainsuff i x e certificate. O certificado
será carregado diretamente do arquivo via comando cat:
cloudmonkey upload customcertificate id=1 name=root domainsuffix="domain.com.br"
certificate="$(cat <caminho absoluto do certificado root>)"
• Certificado(s) Intermediário(s)
Em um terminal, faça a chamada da API uploadCustomCertificate passando
os parâmetros id, name, domainsuffix e certificate:
cloudmonkey upload customcertificate id=n name="intermediate<n-1>" domainsuffix="domain.com.br"
certificate="$(cat <caminho absoluto do certificado intermediário>)"
196
Este passo deve ser repetido para cada certificado intermediário, acres-
cendo a variável n em 1 a cada vez que for feito.
Nota: o nome dos certificados intermediários é n-1 pois o primeiro certi-
ficado intermediário inicia com o ID 2 (root é o 1º).
• Certificado do site
Em um terminal, faça a chamada da API uploadCustomCertificate passando
os parâmetros id, domainsuffix, certificate e privatekey:
cloudmonkey upload customcertificate id=n domainsuffix="domain.com.br"
certificate="$(cat <caminho absoluto do certificado do site>)" privatekey="$(cat <caminho
absoluto da chave privada do certificado>)"
Após enviar a requisição com a privatekey no certificado final, o ACS au-
tomaticamente irá reiniciar as System VMs, tanto via API, quanto via UI.
7.9. Pares de chaves SSH
O ACS possui uma funcionalidade que permite a injeção de chaves SSH pré
definidas nas VMs. Para criá-las, vá na seção Compute, em seguida clique em
SSH key pairs e depois em Create a SSH Key Pair.
Figura 136: Acessando a seção SSH key pairs
197
Figura 137: Criando um SSH key pair
Ao criar um par de chaves SSH por meio do SSH key pairs, é preciso estar
atento aos seguintes detalhes:
• Para que essa funcionalidade esteja disponível, o cloudinit ?? precisa estar
configurado na VM.
198
• Se o operador não especificar uma public key, o CloudStack irá gerar um
par de chaves automaticamente. A private key gerada será disponibilizada
imediatamente e não será armazenada pelo CloudStack. Desse modo, é
recomendado que o operador efetue o download do arquivo liberado.
Figura 138: Criação da SSH key pair de forma automática
• Caso não seja especificado um domínio na hora da criação, o par de cha-
199
ves será criado dentro do domínio do usuário que estiver logado.
• Ao especificar uma conta no campo account será necessário informar o
domainid do domínio onde ela se encontra.
Existem duas possibilidades de criação de SSH key pairs via CloudMonkey:
• Caso o operador queira que as chaves sejam criadas de forma automá-
tica:
create sshkeypair name=<nome_da_chave> domainid=<id_do_dominio> account=<nome_da_conta>
projectid=<id_do_projeto>
• Caso o operador queira definir um par de chaves próprio:
register sshkeypair name=<nome_da_chave> publickey=<valor_da_chave> domainid=<id_do_dominio>
account=<nome_da_conta> projectid=<id_do_projeto>
Após a criação do par de chaves, para injetar a public key em alguma VM,
basta seguir os passos descritos abaixo:
200
Figura 139: Criando a chave SSH
201
Figura 140: Criando instância e implementando a chave SSH
202
8. Virtualizador KVM
Kernel-based Virtual Machine (KVM) é uma tecnologia de virtualização open
source sobre licença GPL que permite transformar o Linux em um virtualizador,
convertendo-o para um hypervisor do tipo bare-metal, possibilitando que host
execute várias VMs, também chamadas guests.
O KVM é responsável por gerenciar o acesso à CPU e à RAM do host para
as guests. Para emular os outros componentes das VMs, como por exemplo
discos, placas gráficas e USBs, o QEMU é utilizado.
Figura 141: Virtualização KVM
Tendo sido projetado para soluções de nuvem, o KVM possui certas vanta-
gens sobre outros virtualizadores. Por exemplo, ele dá acesso direto a cada
host, sem a necessidade de passar por um elemento centralizador, como o
vCenter do VMware ou o nó master do XenServer. Facilitando o gerenciamento
dos mesmos pelos orquestradores de nuvem, como OpenStack ou CloudStack,
além de prover desempenho mais satisfatório.
Existem diversos prós e contras entre os hypervisors suportados pelo ACS:
203
Figura 142: Comparação de virtualizadores
Outra ferramenta utilizada em conjunto com o KVM é o Libvirt, que é um
conjunto de softwares que facilitam o gerenciamento de máquinas virtuais, in-
cluindo uma API, um daemon (libvirtd) e um CLI (virsh). O Libvirt é apenas um
facilitador e não deve ser confundido com o KVM em si.
8.1. Instalação do KVM e CloudStack Agent
O primeiro passo é instalar os seguintes softwares: o NFS
19
, NTP
20
, QEMU,
KVM e o Libvirt:
19
NFS é o protocolo utilizado para o storage
20
O NTP é necessário para sincronizar os relógios dos servidores na nuvem
204
apt-get update
apt-get install nfs-common
apt-get install openntpd
apt-get install qemu-kvm libvirt-bin python3-libvirt virtinst bridge-utils cpu-checker
Então, deve-se baixar os pacotes da release mais atual do ACS, estes se en-
contram na seção Deployments > Releases do projeto no GitLab. Em seguida,
deve-se instalar o CloudStack Agent (haverá um sufixo da versão nos arquivos
baixados):
• Para .deb:
apt install cloudstack-common_<versao-do-acs>-scclouds~bionic_all.deb \
cloudstack-agent_<versao-do-acs>-scclouds~bionic_all.deb
• Para .rpm:
yum install cloudstack-common-<versao-do-acs>-scclouds.1.el7.centos.x86_64.rpm \
cloudstack-agent-<versao-do-acs>-scclouds.1.el7.centos.x86_64.rpm
8.2. Configuração do KVM e Cloudstack Agent
O CloudStack permite configurar o modelo da CPU que é exposto às instân-
cias do KVM. Para isso, deve-se editar o arquivo /etc/cloudstack/agent/agent.p
ropertie s, manipulando as configurações guest. cpu.mode, guest.cp u.model e
guest.cpu.features.
Existem três possíveis valores para o guest.cpu.mode:
1. custom: Permite ao operador customizar o modelo da CPU. Neste caso,
o modelo deve ser especificado na configuração guest.cpu.mo del. Por
exemplo:
guest.cpu.mode=custom
guest.cpu.model=SandyBridge
A lista de modelos disponíveis para um determinado tipo de arquitetura
pode ser obtida através do comando:
virsh cpu-models <arquitetura>
Por exemplo:
205
$ virsh cpu-models x86_64
pentium
pentium2
pentium3
pentiumpro
coreduo
n270
core2duo
qemu32
kvm32
cpu64-rhel5
cpu64-rhel6
qemu64
(...)
Além disso, ressalta-se que o arquivo /usr/share/libvirt/cpu_map.xml con-
tém uma lista com todos os modelos e flags de CPU suportados.
2. host-model: Aqui o Libvirt identificará qual modelo em /usr/ share/libvir
t/cpu _map/ é mais parecido com o modelo da CPU do host. Esta opção
oferece uma boa performance, mantendo a possibilidade de migração
para um host com CPU da mesma microarquitetura.
3. host-passthrough: O Libvirt dirá ao KVM quais as características exatas
da CPU do host. A diferença para o host-model é que em vez de apenas
parear flags da CPU, todos os detalhes da CPU do host são pareados. Isso
oferece um desempenho melhor, mas tem um custo em relação à mi-
gração: o guest só pode ser migrado para um host com CPU exatamente
igual.
A configuração guest.cpu. f e atures, por sua vez, representa as flags da CPU
a serem aplicadas, separadas por espaço. Por exemplo:
guest.cpu.mode=custom
guest.cpu.model=SandyBridge
guest.cpu.features=aes mmx avx
Para configurar o Libvirt, edite o arquivo que se encontra em /etc/libvirt/lib
virtd.conf. Este é um exemplo de configuração utilizando o protocolo TCP, sem
autenticação e com as portas padrões:
listen_tls=0
listen_tcp=1
listen_addr = "0.0.0.0"
mdns_adv = 0
auth_tcp="none"
206
tcp_port="16509"
tls_port="16514"
auth_tls="none"
Além disso, o KVM precisa se comunicar com diversos outros componentes
através da rede, portando, as seguintes portas TCP devem estar abertas no
firewall:
1. 22 (ssh)
2. 16509 (libvirt)
3. 16514 (libvirt tls)
4. 8250 (ACS system VMs)
5. 5900-6100 (VNC)
6. 49152-49216 (tráfego de migração)
8.3. Operação do KVM
O Libvirt oferece uma gama de facilidades para operação do KVM. Por exem-
plo, usando o Libvirt, é possível descrever as VMs usando XML, tornando a cri-
ação manual e checagem de VMs mais fácil. Para obter o XML de uma VM que
está rodando, basta usar o comando:
virsh dumpxml <instance> >dump.xml
O arquivo resultante será parecido com isso:
<domain type='kvm' id='108'>
<name>r-1896-VM</name>
<uuid>c85d71db-3ce9-4c6f-98d3-b22f7e84058d</uuid>
<description>Debian GNU/Linux 5.0 (64-bit)</description>
<memory unit='KiB'>262144</memory>
<currentMemory unit='KiB'>262144</currentMemory>
<vcpu placement='static'>1</vcpu>
(...)
<sysinfo type='smbios'>
<system>
<entry name='manufacturer'>Apache Software Foundation</entry>
<entry name='product'>CloudStack KVM Hypervisor</entry>
<entry name='uuid'>c85d71db-3ce9-4c6f-98d3-b22f7e84058d</entry>
</system>
</sysinfo>
<os>
<type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type>
(...)
Caso queira criar uma nova VM a partir de um XML, basta rodar o comando:
207
virsh create <XML_da_VM>
Para editar as configurações de uma VM, pode-se usar o comando:
virsh edit <instance>
Deve-se notar, entretanto, que grande parte das modificações terão efeito
apenas após o reinício da VM.
Ademais, caso seja utilizado o XenServer, os seguintes comandos do Libvirt
são seus equivalentes:
virsh list = xe vm-list
virsh start = xe vm-start
virsh shutdown = xe vm-shutdown
Finalmente, caso o usuário julgue necessário, é possível utilizar o Virtual Ma-
chine Manager, que é uma interface gráfica para trabalhar com o Libvirt.
8.4. Topologia de CPU no KVM
Ao definir a CPU de uma VM, é possível definir a quantidade de vCPUs que
a VM terá ao iniciar (quantidade corrente) e também quantas vCPUs a mais é
possível adicionar à VM sem pará-la (quantidade máxima). Ao trabalhar com
fixed offerings (Seção 3.11.1), ambos os valores são iguais e no XML da VM há
apenas a definição da quantidade corrente. Exemplo da definição com uma
fixed offering de 4 vCPUs:
<vcpu placement='static'>4</vcpu>
Ao trabalhar com custom offerings (Seção 3.11.1), a quantidade corrente e
a quantidade máxima são distintas, sendo elas definidas no XML pela proprie-
dade curre nt e pelo valor da tag vcpu, respectivamente. Exemplo da definição
do XML de uma VM, com uma custom offering de valor inicial de 4 vCPUs e má-
ximo de 8:
<vcpu placement='static' current='4'>8</vcpu>
Ao definir a topologia da CPU de uma VM no KVM, é possível informar a
quantidade de sockets, cores e threads. O ACS mantém o número de threads
fixo em 1 e deriva a quantidade de sockets e cores com base na quantidade de
208
vCPUs. A multiplicação da quantidade de sockets, cores e threads deve resultar
na quantidade máxima de vCPUs que uma VM pode ter (valor da tag vcpu).
Por padrão, o ACS deriva a quantidade de sockets tentando dividir a quanti-
dade de cores por 6 ou por 4.
Exemplo 1: Em um cenário com uma custom offering iniciando com 4 vCPUs
e máximo de 24, o ACS tenta dividir a quantidade máxima (24) primeiramente
por 6. Caso o resto seja 0, ele utiliza o quociente e o divisor para definição
da topologia; nesse caso a topologia seria definida como 4 sockets com 6 cores
cada.
Exemplo 2: Já em um cenário com uma custom offering iniciando com 4 vCPUs
e máximo de 16, o ACS tenta dividir a quantidade máxima (16) primeiramente
por 6. Como o resto é diferente de 0, ele tenta dividir por 4; então, o quociente
e o divisor são utilizados para definição da topologia; nesse caso a topologia
seria definida como 4 sockets com 4 cores cada. Caso a divisão por ambos os
divisores não resulte em 0, a topologia não é definida.
Se a definição da topologia através da divisão por 6 ou por 4 não seja a ade-
quada para o contexto, também é possível sobrescrever esse comportamento
utilizando a configuração cpu.corespersocket em cada VM, que substituirá o
divisor no processo de definição.
Alguns exemplos de uso da configuração cpu.corespersocket:
Exemplo cpu.corespersocket max_vCPUs Resultado
1 12 24 2 sockets com 12 cores cada
2 8 32 4 sockets com 8 cores cada
3 1 12 12 sockets com 1 core cada
4 2 20 10 sockets com 2 cores cada
8.5. Controle da CPU no KVM
No CloudStack, o controle da CPU das VMs do KVM pode ser realizado utili-
zando os parâmetros do Libvirt listados abaixo:
209
• shares:
É um peso que indica a prioridade de cada vCPU no acesso à CPU do host
quando há concorrência no acesso à mesma. Por exemplo, se todas as
VMs tiverem shares definido como 1.000, todas terão a mesma priori-
dade. No entanto, se uma VM tiver um valor de 2.000, enquanto as ou-
tras tiverem um valor de 1.000, a VM com o valor de 2.000 terá duas vezes
mais prioridade no acesso à CPU. O intervalo aceito por esse parâmetro
depende da versão do cgroups no kernel do sistema operacional presente
no host. Ao utilizar o cgroups na versão 1, o valor da flag shares deve estar
entre 2 e 262.144; já na versão 2, o intervalo é de 1 a 10.000.
• period:
Especifica o intervalo de tempo (em microssegundos) em que cada vCPU
terá que respeitar o limite definido pelo parâmetro quot a. O valor deve
estar no intervalo entre 1.000 e 1.000.000 microssegundos.
• quota:
Define um limite de largura de banda para cada vCPU. period e quota de-
vem ser utilizados em conjunto para algum limite ser aplicado aos vCPUs
da VM. O valor deve estar no intervalo entre 1000 e 17592186044415 mi-
crossegundos). Quando o valor de quota for maior que o valor definido
pelo period, significa que os vCPUs poderão ter um consumo de largura
de banda de mais de um core físico. Um valor negativo significa que não
há limitação.
Para listar os valores desses parâmetros em uma determinada instância, pode-
se utilizar o seguinte comando:
virsh schedinfo <VM>
210
Figura 143: Exemplo de saída do comando virsh schedinfo
O valor destes parâmetros pode ser alterado via ACS durante a criação da
service offering, habilitando CPU cap, que permite limitar a quantidade de uso
de CPU de uma VM, independentemente da quantidade disponível no servidor.
Com esse parâmetro habilitado, o CloudStack calcula cpuQuotaPercentage =
Host.MaxSpeed
Vm.MaxSpeed
, em seguida o valor de quota é calculado multiplicando cpuQ
uotaPercentage pela variável D EFAULT_PERIOD que tem valor 10.000 fixo no
CloudStack. Vale ressaltar que o parâmetro quota tem valor mínimo 1.000,
caso a multiplicação mencionada acima retorne um valor inferior a isso (equi-
valente a 10% do DEFAULT_PERIOD), o CloudStack irá substituir o valor da mul-
tiplicação pelo valor mínimo.
Já o valor de period é calculado da seguinte forma period =
quota
cpuQuotaPercentage
,
esse valor é então comparado com a variável MAX_PERIOD que tem valor 1.00
0.000. Caso o resultado de divisão esteja acima do valor dessa variavel, perio
d será definido como MAX_ PERIOD, caso contrário, o valor original da divisão
será mantido.
O valor de shares é determinado utilizando os valores de vm.speed, vm
.minSpeed e v m.cp us, que são definidos na oferta de serviço. Caso o valor
de vm.minSpeed seja nul l, o valor do parâmetro será definido como shares =
vm.cpus×vm.speed. Caso contrário, se vm.minSpeed possuir um valor definido,
então o parâmetro será calculado da seguinte maneira: shares = vm.cpus ×
211
vm.minSpeed.
212
9. Virtualizador VMWare
A presente seção irá apresentar como adicionar o virtualizador VMWare na
infraestrutura do Apache CloudStack.
A instalação e configuração dos hosts ESXi, assim como a do vCenter, aqui
apresentadas, foram realizadas em um laboratório local, utilizando o virtuali-
zador KVM, assim, caso a presente seção seja utilizada para uma instalação em
hosts reais, alguns procedimentos podem diferir.
Além disso, as versões instaladas foram:
• VMWare ESXi 6.5.0 Build 14320405
• Ubuntu 20.04.2 LTS
9.1. Criação de datastores
Por ser utilizado um laboratório local, já existia uma VM que era utilizada
como storage. Essa VM utiliza o protocolo NFS, assim, foram exportados dois
novos paths para servir como datastores primário para os hosts ESXi e datastore
para deploy do vCenter.
Os novos paths criados foram:
• Primary Datastore: /mnt/vmware-primary-storage
• Deploy Datastore: /mnt/vmware-deply-vcenter
E os mesmos foram adicionados ao arquivo de configuração /etc/exports:
/mnt/vmware-primary-storage 192.168.31.0/24(rw,sync,no\_subtree\_check,no\_root\_squash)
/mnt/vmware-deply-vcenter 192.168.31.0/24(rw,sync,no\_subtree\_check,no\_root\_squash)
Em seguida, o serviço do NFS foi reiniciado com o comando:
systemctl restart nfs-server.service
213
9.2. Instalação dos hosts ESXi
Foi utilizado o instalador 6.5 do VMWare, além disso, as VMs criadas pos-
suíam cinco NICs, a saber:
• Rede public: usada para acessar os hosts através da rede externa. Essa
rede foi adicionada no laboratório para auxiliar a configuração dos hosts,
mas deve ser melhor analisada em um ambiente de produção, tendo em
mente que os hosts ESXi precisarão de acesso à rede externa para procu-
rar e aplicar atualizações do VMWare.
• Rede management: usada para comunicação com o ACS.
• Rede primary storage: usada para comunicação com o primary datastore.
• Rede secondary storage: usada para comunicação com o secondary datas-
tore.
• Rede guest: usada para a comunicação lateral das VMs.
O comando utilizado, no KVM, foi:
virt-install --name esxi1 --vcpus 2 --memory 11000 --disk size=20 --graphics \
vnc,port=9999,listen=0.0.0.0 --network network:public --network bridge:br-management \
--network bridge:br-pri-storage --network bridge:br-sec-storage --network bridge:br-guests --cdrom \
~/isos/VMware-VMvisor-Installer-201908001-14320405.x86_64.iso
21
Em seguida, a configuração dos hosts foi realizada utilizando o Remmina,
seguindo apenas a instalação padrão, descrita na subseção abaixo.
9.2.1. Instalação padrão dos hosts ESXi
1. Ao iniciar a instalação do host ESXi, simplesmente pressione Enter:
21
Aqui, é importante ressaltar que foi criado uma VM com 10 GB de RAM porque o VMWare
vCenter possui uma limitação na adição de hosts ESXi, onde o mesmo bloqueia a adição de
hosts com menos de 10 GB de memória RAM. Essa limitação, apesar de ter sido notada na
versão 6.5 do VMWare, pode estar presente também em versões mais recentes do mesmo.
214
Figura 144: Tela inicial da instalação do ESXi
2. Após ler e concordar, aceite os termos de uso pressionando F11:
Figura 145: Aceitar os termos de uso
3. Será realizado um scan dos discos existentes no host. No host usado nessa
documentação, existia apenas um disco, que foi utilizado para a instala-
ção. Em ambientes com mais de um disco, deve-se atentar para escolher
o disco correto:
215
Figura 146: Escolhendo o disco para instalar o sistema
4. Selecione o layout do teclado. Aqui, foi utilizado o layout brasileiro, mas o
padrão é o teclado estadunidense:
Figura 147: Selecionando o layout do teclado
5. Crie uma senha para o usuário root. Por padrão, a instalação do ESXi não
permite a criação de novos usuários:
Figura 148: Criando senha root
216
6. Esse warning ocorreu pelo fato da instalação estar ocorrendo em uma VM,
caso ocorra o mesmo em um ambiente de produção, pode-se prosseguir
com a mesma, ao pressionar Enter:
Figura 149: Possível warning
7. Confirme a instalação ao pressionar F11:
Figura 150: Confirmar a instalação
8. O processo de instalação irá, então, iniciar:
Figura 151: Instalação do host
9. Após o processo finalizar, será necessário reiniciar o host, ao pressionar
a tecla Enter:
217
Figura 152: Reiniciando o host
9.2.2. Configurações básicas dos hosts ESXi
Após a instalação finalizar, é recomendado fazer o login nos hosts e realizar
as seguintes configurações:
• Fazendo login no host, ao pressionar a tecla F2:
Figura 153: Login inicial
218
Figura 154: Usuário padrão é o root, e a senha é aquela configurada durante a instalação
• Configurando IP estático:
Vá até a seção de Configure Management Network.
Figura 155: Seção Configure Management Network
Em seguida, vá até a seção de IPv4 Configuration.
219
Figura 156: Seção IPv4 Configuration
Habilite o uso de IPv4 estático. Aqui é possível alterar o IP utilizado.
Figura 157: IPv4 estático
Ao pressionar ESC para voltar, será pedido uma confirmação das altera-
ções. Aceite-as.
220
Figura 158: Aplicando alterações
• Habilitar acesso ao SSH e ao shell:
Vá até a seção de Troubleshooting Options.
Figura 159: Seção Troubleshooting Options
Em seguida, habilite o acesso ao shell do host ao pressionar Enter.
221
Figura 160: Acesso ao shell do host
Também habilite o acesso ao SSH do host ao pressionar Enter.
Figura 161: Acesso ao SSH do host
222
9.2.3. Configurações avançadas dos hosts ESXi
Por padrão, os hosts ESXi possuem apenas um IP, mesmo possuindo vários
NICs, além de necessitarem terem suas licenças ativadas manualmente, dessa
forma, é necessário realizar configurações mais avançadas, que só são permi-
tidas na interface web disponibilizada pelos hosts.
O link de acesso a essa interface web se encontra na tela de login dos mes-
mos:
Figura 162: URL pra acesso à interface web
Realize o login usando a senha criada durante a configuração.
Figura 163: Tela de login
223
9.2.3.1. Adição de novos IPs
1. Vá para Networking → Physical NICs para visualizar os NICs disponíveis:
Figura 164: NICs disponíveis
2. Vá para Networking → Virtual switches e clique em Add standard vir-
tual switch:
Figura 165: Virtual switches
3. Configure o novo switch:
224
Figura 166: Configurando o novo virtual switch
Repita os passos 2 e 3 caso o host em questão tenha mais NICs.
4. Vá para Networking → VMkernel NICs e clique em Add VMkernel NIC:
Figura 167: VM Kernel NICs
5. Configure o novo VMkernel NIC:
225
Figura 172: Finalize a configuração
5. Repita para todos os datastores que devem ser adicionados no presente
host.
9.2.3.3. Adição de chave de licença
1. Vá para Manage → Licensing e clique em Assign license:
Figura 173: Acessando a licença
2. Digite a sua licença e a verifique:
228
Figura 174: Verificando se a licença é válida
3. Com a licença validada, adicione-a:
Figura 175: Adicionando licença
Repita para todos os hosts ESXi da infraestrutura.
9.3. Instalação do vCenter
Para realizar a instalação do vCenter, foi necessário criar uma VM Ubuntu
com interface gráfica. Apesar de, na documentação do VMWare, estar escrito
que é possível instalar o vCenter em hosts Linux utilizando o cli-installer, na
prática, toda vez que era feita uma tentativa de instalação no Linux, ocorria
um erro e uma mensagem genérica era exibida. Após muita pesquisa, a solu-
ção encontrada foi utilizar Linux com uma interface gráfica e, após instalar o
vCenter, remover a interface gráfica, para poupar recursos.
Os passos da instalação do vCenter foram:
1. Instalação da interface gráfica no Linux:
229
• Atualizar repositórios do Ubuntu:
apt update && apt upgrade
23
• Instalação do lightdm:
apt install lightdm
• Instalação do Desktop Environment
24
:
apt install ubuntu-desktop
• (OPCIONAL) Reiniciar o host:
reboot
2. Copiar .ISO do vCenter para a máquina em questão:
scp VMware-VCSA-all-6.5.0-18711281.iso user@vcenter-IP:~/
3. Montar o ISO
25
.
4. Acessar os arquivos montados no ISO, navegar para o diretório
ISO-MOUNT-POINT/vcsa-ui-installer/lin64/ e executar o script installer
26
:
5. Na interface gráfica, ao executar o script da etapa anterior, será iniciado
o processo de instalação do vCenter:
23
O upgrade é opcional.
24
Aqui pode-se utilizar outros Desktop Environments, como o XFCE, Mate, etc.
25
Pode ser feito via interface gráfica ou linha de comando
26
Pode ser feito via interface gráfica ou linha de comando
230
7. Aceite os termos de uso:
Figura 178: Termos de uso
8. Selecione o tipo de estrutura que será feita o deploy:
Figura 179: Tipos de deploy disponíveis
9. Adicione o mínimo de um host ESXi:
232
Figura 180: Adicionando host ESXi
Pode ocorrer um warning a respeito da validade do certificado do host.
Apenas o ignore.
10. Defina a senha do root no vCenter:
Figura 181: Adicionando a senha do root
11. Escolha o tamanho da infraestrutura que será feito deploy:
233
Figura 182: Tamanho da infraestrutura
12. Selecione um dos datastores do host:
Figura 183: Datastores disponíveis
13. Configure a rede utilizada pelo vCenter:
234
Figura 184: Configurando a rede do vCenter
14. Confirme os dados da instalação e a finalize:
Figura 185: Finalizando a configuração do vCenter
Será iniciado o processo de instalação do vCenter, sendo que esse pro-
cesso pode levar vários minutos para terminar. Caso ocorra algum erro,
recomenda-se alterar a rede utilizada pelo vCenter para que a mesma use
DHCP ao invés de IPv4 estático, e repetir o processo de instalação.
235
15. Agora, inicie a configuração do PSC:
Figura 186: Iniciando a configuração do PSC
16. Habilite ou desabilite o SSH e defina o modo de sincronização que será
utilizado, de acordo com suas preferências:
Figura 187: Aplicando configurações básicas do appliance
17. Crie e configure um novo SSO:
236
Figura 188: Criando e configurando um novo SSO
18. Participe, ou não, do programa de melhoria do VMWare:
Figura 189: Programa de melhoria do VMWare
19. Revise as configurações aplicadas e, se tudo estiver ok, prossiga com a
instalação:
237
Figura 190: Finalizando a configuração
20. Esse processo irá demorar alguns minutos, e, após o mesmo terminar,
será possível acessar a interface web do vCenter no endereço disponibili-
zado ao final da instalação:
Figura 191: Concluindo a instalação
O login padrão é administrator@<domain -definido -durante-a-instala cao
>, sendo a senha a mesma definida durante a instalação.
Após realizar o login, a tela exibida será essa:
238
Figura 192: Tela inicial do vSphere
9.3.1. Adição de chave de lincença
1. Vá para Menu → Administration → Licensing → Licenses e clique em
Add New Licenses:
Figura 193: Tela de licenças
2. Digite a licença:
239
Figura 194: Adicionando a licença
3. Renomeie a licença:
Figura 195: Alterando o nome da licença
4. Finalize a adição da licença:
240
Figura 196: Finalizando a adição da licença
9.3.2. Adição de múltiplos hosts ESXi
Na presente documentação, o deploy do vCenter foi realizado em um dos
hosts ESXi, assim, só será possível realizar a adição de um segundo host. Em um
ambiente de produção, é recomendado que o deploy do vCenter seja realizado
em uma VM própria para isso.
Dito isso, para adicionar hosts ESXi ao vCenter, é necessário seguir os pas-
sos:
1. Criar um Datacenter:
• Na barra lateral, clique com o botão direito no photon-machine.public
ou semelhante, e, em seguida, selecione New Datacenter:
241
Figura 197: Iniciando a adição de um novo datacenter/folder
• Nomeie o novo datacenter:
Figura 198: Nomeando o novo datacenter
2. Criar um novo Cluster: clique com o botão direito no novo Datacenter cri-
ado e, em seguida, clique em New Cluster. O procedimento será igual ao
da adição do Datacenter.
3. Com o novo cluster criado, clique com o botão direito em cima do mesmo
e, em seguida, clique em Add Host:
242
Figura 199: Adicionando um novo host ao datacenter
4. Informe o IP ou hostname do novo host:
Figura 200: Adicionando o IP do host
5. Informe o usuário e senha desse host:
Figura 201: Usuário e senha do host
Se houver algum aviso de certificado, aceite-o.
6. Confirme os dados do host:
243
Figura 202: Resumo dos dados do host
7. Escolha/confirme a licença do host:
Figura 203: Licença do host
8. Escolha o modo de lockdown do host:
Figura 204: Host lockdown mode
9. Confirme o local:
244
Figura 205: VM location
10. Confirme os detalhes finais:
Figura 206: Detalhes finais
E repita para cada host disponível e desejado.
9.3.3. Remoção da interface gráfica do Linux
Uma vez que o processo de instalação já tenha sido finalizado, não é mais
necessário o uso da interface gráfica no Linux. Os passos para a remover são:
• Remoção do lightdm:
apt remove lightdm
• Remoção do desktop environment:
apt remove ubuntu-desktop
• Remoção de possíveis pacotes que ficaram orfãos com a remoção da in-
terface gráfica:
245
apt autoremove
• (OPCIONAL) Reiniciar o host:
reboot
9.4. Adição de cluster VMWare no Apache CloudStack
Para adicionar um cluster VMWare no Cloudstack, é necessário que o ACS
possua acesso ao vCenter utilizado via rede de gerência. Além disso, depen-
dendo da estrutura implementada no VMWare, pode ser necessário criar, no
VMWare, novos switches para as redes guest e de storage utilizadas pelo ACS.
Finalmente, pode também ser necessário adicionar, no ACS, os datastores uti-
lizados pelo VMWare.
Uma vez que o deploy da estrutura VMWare estiver finalizada, é necessário
adicionar tal estrutura como um cluster no ACS. Para isso, os passos a serem
seguidos são:
1. Faça login no ACS e navegue até Infrastructure → Zones e acesse a zona
sobre a qual ficará o cluster VMWare.
2. Nessa zona, clique em Add VMware datacenter:
Figura 207: Adicionando datacenter VMWare
3. Configure o datacenter:
246
Figura 208: Configurando datacenter VMWare no Apache CloudStack
4. Ainda na zona, navegue até a aba Physical Network:
Figura 209: Acessando os detalhes das redes físicas do Apache CloudStack
5. Acesse cada uma das redes e, nos detalhes das mesmas, vá até a aba Traf-
fic Types, e clique em Update Traffic Labels:
247
Figura 210: Atualizando as redes
6. Atualize a label do virtualizador VMWare:
A sintaxe padrão aqui é:
[[“Nome do vSwitch/dvSwitch/EthernetPortProfile”][,“VLAN ID”[,“Tipo
do vSwitch”]]]
São exemplos possíveis:
• Vazio;
• dvSwitch0;
• dvSwitch0,200;
• dvSwitch1,300,vmwaredvs;
• myEthernetPortProfile„nexusdvs;
• dvSwitch0„vmwaredvs;
• vSwitch0„vmwaresvs
Onde cada campo é:
• Nome do vSwitch/dvSwitch/EthernetPortProfile:
Nome do switch virtual no vCenter (distribuído ou não), onde os va-
lores padrões dependem do tipo do virtual switch:
– vSwitch0: Se o switch é do tipo VMware vNetwork Standard virtual
switch;
248
– dvSwitch0: Se o switch é do tipo VMware vNetwork Distributed vir-
tual switch e
– epp0: Se o switch é do tipo Cisco Nexus 1000v Distributed virtual
switch
• VLAN ID: ID da VLAN, caso exista. Deve ser utilizada apenas na rede
pública.
• Tipo do vSwitch: os valores possíveis são:
– vmwaresvs: Quando o switch utilizado é o VMware vNetwork Stan-
dard virtual switch.
– vmwaredvs: Quando o switch utilizado é o VMware vNetwork dis-
tributed virtual switch.
– nexusdvs: Quando o switch utilizado é o Cisco Nexus 1000v distri-
buted virtual switch.
Figura 211: Adicionando o mapeamento de redes do VMWare no Apache CloudStack
249
7. Com as redes corretamente atualizadas, navegue até a seção de Clusters,
clique em Add Cluster e selecione o virtualizador VMWare. Isso irá habi-
litar uma nova gama de opções, onde deve ser informado o IP do vCenter
e outros dados, como nome do Datacenter, usuário e senha:
Figura 212: Configurando o cluster VMWare no Apache CloudStack
8. Finalmente, pode ser necessário alterar o valor de algumas configurações
globais, sendo elas:
(a) vmware.management.portgroup;
(b) vmware.service.console.
Aqui é importante ressaltar que o nome do Datacenter, do Cluster e dos Da-
tastores no VMWare precisam ser os mesmos no ACS, já que os nomes são
utilizados para a comunicação entre os dois.
250
9.5. Problemas na adição de cluster VMWare
Ao adicionar um cluster VMWare pela primeira vez em uma zona, o ACS in-
troduz uma tag customizável no vCenter indicando que este já está sendo ge-
renciado pelo ACS. Entretanto, caso ocorra algum erro no processo de adição
de tal vCenter, a tag não é removida, resultando em um erro nas próximas
tentativas de adição, já que um vCenter que já possui tal tag não pode ser "re-
adicionado"à gerência do ACS.
No caso descrito, a seguinte mensagem de erro é mostrada
Figura 213: Mensagem de erro da tag na UI ao tentar adicionar o vCluster
O processo de exclusão da tag para adição do vCluster é descrito a seguir:
251
1. Acesse o vCenter, selecione a zona, clique em Summary e na seção Custom
Attributes clique em Edit....
Figura 214: Seleção da zona no vCenter
2. Selecione o atributo cloud.zon e e clique no botão X acima para deletar o
atributo e em seguida clique em OK.
252
Figura 215: Deleção do atributo cloud.zone
3. Remoção do registro da zona VMWare da tabela vmware_data_center.
253
Figura 216: Selecionando e apagando vCluster da database
Após os passos anteriores, é necessário recriar a zona ou adicionar os clus-
ters e hosts manualmente.
Informações mais detalhadas sobre a adição do VMWare no Cloudstack po-
dem ser encontradas na documentação oficial do Apache CloudStack.
9.6. Importação de VMs do VMWare para o Apache CloudStack
Uma vez que o cluster VMWare esteja corretamente adicionado na infra-
estrutura do ACS, será possível importar (tanto via UI, quanto via API) as VMs
existentes no VMWare para serem gerenciadas pelo ACS .
9.6.1. Importação de VMs via UI
Na nova UI, com um cluster VMWare existente na infraestrutura do ACS, uma
view chamada Tools será exibida. Ao acessar essa view será possível realizar o
import de VMs do vCenter para o ACS:
• Acesse a view de Tools:
254
Figura 217: Acessando a view de Tools para fazer o import das VMs
• Nessa view, selecione a Zona, o Pod e o Cluster VMWare recém adicionado.
Com isso feito, serão listadas as VMs existentes no VMWare que não são
gerenciadas pelo ACS, assim como as VMs gerenciadas pelo ACS:
Figura 218: Vendo as VMs do cluster VMWare
• Para realizar o import das VMs, basta selecioná-las e, em seguida, pressi-
onar o botão de Import Instance:
255
Figura 219: Importando uma VM para o Apache CloudStack
• Será aberto um pop-up, requerindo alguns detalhes, os preencha de acordo
com sua necessidade:
Figura 220: Detalhes do import da VM
• Ao final do procedimento, caso o mesmo resulte em sucesso, a VM será
exibida na coluna de Managed Instances:
256
Figura 221: VM importada com sucesso
9.6.2. Importação de VMs via API
Para realizar o import via CloudMonkey, será utilizada a API importUnmana-
gedInstance:
• Essa API irá importar uma VM do VMWare para o CloudStack. Na chamada
da API são obrigatórios o ID do cluster no qual será inserida a VM, o seu
nome dentro do VMWare e a oferta de serviço que a representará. No
mais, é possível mapear ofertas de disco, redes, conta e domínio, entre
outras propriedades.
Exemplos:
import unmanagedinstance clusterid=55d19ae9-a26d-43e3-9cb4-83d989cc882c name=test1
serviceofferingid=7fd97738-57b9-4240-9680-3dca279fa9a6
import unmanagedinstance clusterid=55d19ae9-a26d-43e3-9cb4-83d989cc882c name=test2
serviceofferingid=7fd97738-57b9-4240-9680-3dca279fa9a6 datadiskofferinglist[0].disk=disk1
datadiskofferinglist[0].diskOffering=1ef110db-1247-463b-b2ed-14ba1582c075
datadiskofferinglist[1].disk=disk2 datadiskofferinglist[1].diskOffering=07b97faf-740f-4c71-aae5-
b8a42e465617
import unmanagedinstance clusterid=55d19ae9-a26d-43e3-9cb4-83d989cc882c name=test3
serviceofferingid=7fd97738-57b9-4240-9680-3dca279fa9a6 datadiskofferinglist[0].disk=disk1
datadiskofferinglist[0].diskOffering=1ef110db-1247-463b-b2ed-14ba1582c075
nicNetworkList[0].nic="nic1" nicNetworkList[0].network=b9683956-8e1d-4128-8063-d3a0d8a4ceae
• Os discos são informados em forma de vetor na opção datadiskofferin-
glist. O valor do disk deve ser condizente com o nome do disco nas con-
257
figurações da VM, que podem ser acessadas nos detalhes da mesma no
vCenter. Devem ser somente informados os discos extras da VM, pois o
volume root é importado automaticamente (o CloudStack assume que o
primeiro disco recuperado da VM é o root). A opção disk é o nome do
disco na VM e a opção diskOffering é o ID de uma oferta de disco com-
patível com o disco (não pode ter capacidade abaixo da do disco). Para
fazer o import de uma VM com vários discos, é possível passar uma lista
de discos a serem importados, por exemplo:
import unmanagedinstance name=test-unmanaged ... datadiskofferinglist[0].disk=51-2000
datadiskofferinglist[0].diskOffering=e9eb069f-2946-4e26-8d81-07aebba868d1
datadiskofferinglist[1].disk=52-2000 datadiskofferinglist[0].diskOffering=...
• As redes são informadas em forma de vetor na opção nicNetworkList, onde
a opção nic é o ethernet port e o network é o UUID da rede. Caso a rede da
VM, no VMWare, possua uma VLAN, é necessário que a rede informada
no ACS tenha a mesma VLAN. Também é possível informar os IPs de cada
rede, através da opção nicIpAddressList, onde a opção nic é o ethernet port
e o ip4Address é o IP reservado no CloudStack.
• Ao realizar o import de uma VM do VMWare para o ACS, deve-se tomar
cuidado em utilizar uma oferta de serviço que não ultrapasse as limita-
ções de memória da VM no VMWare. Mais detalhes sobre esse problema
podem ser encontrados nesse link.
258
10. Conclusão
Esse documento abordou, de forma geral, os principais conceitos e dúvidas
recorrentes sobre o Apache CloudStack e ferramentas auxiliares. Ambos são
extensos e complexos, portanto não é possível abordá-los em sua totalidade,
contudo, caso haja dúvidas ou sugestões de melhorias na documentação, pode
ser lançado um issue no GitLab.
259
Apêndices
260
Apêndice A. Terminologia
• Infrastructure-as-a-Service:
Infraestrutura como Serviço, em uma tradução livre, consiste em ofere-
cer recursos computacionais, como processamento, armazenamento e
acesso à redes, sobre demanda, usualmente tendo uma cobrança pelo
tempo de uso desses recursos.
• Hypervisor:
Consiste em um software responsável por criar e executar máquinas vir-
tuais (VMs). Um hypervisor permite que um computador host ofereça su-
porte a várias VMs guest, compartilhando virtualmente seus recursos, como
memória, armazenamento e processamento, permitindo, assim, um me-
lhor uso dos recursos disponíveis.
• VM:
Sigla de Virtual Machine, Máquina Virtual em português, trata-se de um
software que emula um computador real. Também chamada de guest, é
criada em outro computador, chamado de host, e utiliza uma parte dos
recursos do mesmo. As vantagens do uso de VMs são:
– Permite utilizar diferentes sistemas operacionais em um único com-
putador.
– Extremamente fáceis de gerenciar e manter.
– VMs podem ser facilmente criadas ou replicadas com um sistema
operacional já previamente instalado e configurado.
– Fácil migração de uma VM de um host para outro, sem perda de da-
dos.
• Placa de rede virtual:
Comumente referida como NIC, VNIC ou VIF. É um software que cumpre o
papel de uma placa de rede em um sistema virtual.
261
