Consumo 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 consumo

da mesma.

Data de atualização: 9 de janeiro de 2026

Revision: a861aa100534f4f28acdbb7f732a7becb500075c

Conteúdo

1 Introdução 27

1.1 Plataformas de nuvem privada . . . . . . . . . . . . . . . . . . . . . 28

1.1.1 Funcionalidades básicas . . . . . . . . . . . . . . . . . . . . . 28

1.2 História do Apache CloudStack . . . . . . . . . . . . . . . . . . . . . 30

2 Funcionalidades do Apache CloudStack 31

2.1 Dashboard inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2 Gestão de acesso à nuvem . . . . . . . . . . . . . . . . . . . . . . . 31

2.2.1 Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2.1.1 Adição de account . . . . . . . . . . . . . . . . . . . 34

2.2.1.2 Visualização de detalhes de account . . . . . . . . 35

2.2.1.3 Deleção de account . . . . . . . . . . . . . . . . . . 36

2.2.1.4 Conﬁguração de acesso de uma account . . . . . . 36

2.2.1.5 Desabilitação de account . . . . . . . . . . . . . . . 38

2.2.1.6 Bloqueio de account . . . . . . . . . . . . . . . . . . 39

2.2.1.7 Restrição de acesso à API por IP . . . . . . . . . . . 40

2.2.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.2.2.1 Adição de role . . . . . . . . . . . . . . . . . . . . . 41

2.2.2.2 Visualização de detalhes de role . . . . . . . . . . . 42

2.2.2.3 Customização de uma role . . . . . . . . . . . . . . 43

2.2.2.4 Remoção de role . . . . . . . . . . . . . . . . . . . . 43

2.2.3 Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.2.3.1 Adição de domain . . . . . . . . . . . . . . . . . . . 46

2.2.3.2 Conﬁguração de domain . . . . . . . . . . . . . . . 47

2.2.3.3 Deﬁnição de acessos do domain . . . . . . . . . . . 48

2.2.3.4 Reestruturação da árvore de domínios . . . . . . . 49

2.2.4 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.2.4.1 Adição de user . . . . . . . . . . . . . . . . . . . . . 50

2.2.4.2 Edição de user . . . . . . . . . . . . . . . . . . . . . 52

2.2.4.3 Deleção de user . . . . . . . . . . . . . . . . . . . . 54

2.2.4.4 Desabilitação/habilitação de user . . . . . . . . . . 54

2.2.4.5 Políticas de senha . . . . . . . . . . . . . . . . . . . 55

2.2.4.6 Desabilitação de user por erro de senha . . . . . . 57

2.2.4.7 Gerência de chaves de API dos users . . . . . . . . 57

2.2.4.8 Uso das chaves de API no CloudMonkey . . . . . . 59

2.2.4.9 Autenticação de dois fatores . . . . . . . . . . . . . 59

2.2.4.10 Timezone . . . . . . . . . . . . . . . . . . . . . . . . . 64

2.2.5 Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

2.2.5.1 Adição de project . . . . . . . . . . . . . . . . . . . . 66

2.2.5.2 Interação entre domain admins e admins do pro-

jeto com project roles . . . . . . . . . . . . . . . . . 71

2.2.5.3 Adição de accounts e users ao project . . . . . . . . 71

2.2.5.4 Edição de project . . . . . . . . . . . . . . . . . . . . 75

2.2.5.5 Suspensão de project . . . . . . . . . . . . . . . . . 76

2.2.5.6 Deleção de project . . . . . . . . . . . . . . . . . . . 77

2.2.6 Observações e considerações . . . . . . . . . . . . . . . . . 78

2.2.7 Conﬁgurações de Contas e Domínios . . . . . . . . . . . . . 78

2.3 Gerência de VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

2.3.1 Adição de VM . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

2.3.1.1 Adição de VM como root admin . . . . . . . . . . . 80

2.3.1.2 Adição de VM como admin . . . . . . . . . . . . . . 82

2.3.1.3 Adição de VM como user . . . . . . . . . . . . . . . 85

2.3.1.4 Criação de VM com inicialização UEFI . . . . . . . . 87

2.3.2 Remoção de VM . . . . . . . . . . . . . . . . . . . . . . . . . . 91

2.3.3 Parada e início de VM . . . . . . . . . . . . . . . . . . . . . . 92

2.3.4 Reinício de VM . . . . . . . . . . . . . . . . . . . . . . . . . . 92

2.3.5 Acesso à VM via interface web . . . . . . . . . . . . . . . . . 93

2.3.6 Aumento de recursos computacionais da VM . . . . . . . . 94

2.3.7 Atribuição de VM a outra account . . . . . . . . . . . . . . . 97

2.3.8 Adição de user data script na VM . . . . . . . . . . . . . . . . 99

2.3.9 Conﬁgurações da VM . . . . . . . . . . . . . . . . . . . . . . 104

2.3.9.1 Conﬁgurações gerais . . . . . . . . . . . . . . . . . 105

2.3.9.2 Conﬁgurações para VM com compute oﬀering per-

sonalizada . . . . . . . . . . . . . . . . . . . . . . . . 105

2.3.9.3 Conﬁgurações diversas para uso interno . . . . . 106

2.3.9.4 Conﬁgurações para importação de VM com NIC,

disco e parâmetros personalizados para compute

oﬀering personalizada . . . . . . . . . . . . . . . . . 106

2.3.9.5 Adicionar conﬁgurações da VM via API . . . . . . . 106

2.3.10 Limite no consumo de rede para NICs de VMs de usuário . 107

2.4 Gerência de volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

2.4.1 Operações em data e root disks . . . . . . . . . . . . . . . . . 109

2.4.1.1 Vizualização de discos e volumes . . . . . . . . . . 109

2.4.1.2 Criação de volume . . . . . . . . . . . . . . . . . . . 109

2.4.1.3 Upload de volume local . . . . . . . . . . . . . . . . 110

2.4.1.4 Upload de volume local usando cURL . . . . . . . . 111

2.4.1.5 Upload de volume on-line via URL . . . . . . . . . . 113

2.4.1.6 Adição de volume a uma VM . . . . . . . . . . . . . 114

2.4.1.7 Remoção de volume de uma VM . . . . . . . . . . 115

2.4.1.8 Remoção e adição de volume ROOT . . . . . . . . 115

2.4.1.9 Redimensionamento de volume data disk . . . . . 116

2.4.1.10 Download de volume . . . . . . . . . . . . . . . . . 117

2.4.1.11 Snapshots recorrentes . . . . . . . . . . . . . . . . . 118

2.4.1.12 Deleção de volume . . . . . . . . . . . . . . . . . . 119

2.5 Redes guest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

2.5.1 Rede isolada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

2.5.1.1 Egress rules . . . . . . . . . . . . . . . . . . . . . . . 121

2.5.2 Network permissions . . . . . . . . . . . . . . . . . . . . . . . 121

2.5.3 Rede compartilhada . . . . . . . . . . . . . . . . . . . . . . . 121

2.5.4 Rede L2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

2.5.5 Operações com redes guest . . . . . . . . . . . . . . . . . . . 126

2.5.5.1 Adicionar rede guest . . . . . . . . . . . . . . . . . . 126

2.5.5.2 Acesso aos detalhes de uma rede guest . . . . . . 127

2.5.5.3 Exclusão de rede . . . . . . . . . . . . . . . . . . . . 127

2.5.5.4 Edição de rede . . . . . . . . . . . . . . . . . . . . . 128

2.5.5.5 Reinicialização de rede . . . . . . . . . . . . . . . . 128

2.5.5.6 Network permissions . . . . . . . . . . . . . . . . . . 128

2.6 IPs públicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

2.6.1 Operações com IPS públicos . . . . . . . . . . . . . . . . . . 131

2.6.1.1 Conﬁguração de ﬁrewall . . . . . . . . . . . . . . . 131

2.6.1.2 Habilitação de static NAT . . . . . . . . . . . . . . . 132

2.6.1.3 Habilitação de port forwarding . . . . . . . . . . . . 133

2.6.1.4 Habilitação de load balancing . . . . . . . . . . . . 135

2.6.2 Aquisição de IP público . . . . . . . . . . . . . . . . . . . . . 136

2.6.3 Quarentena de IPs públicos . . . . . . . . . . . . . . . . . . . 139

2.7 Virtual Private Cloud (VPC) . . . . . . . . . . . . . . . . . . . . . . . . 140

2.7.1 Operações com a VPC . . . . . . . . . . . . . . . . . . . . . . 140

2.7.1.1 Adição de VPC . . . . . . . . . . . . . . . . . . . . . 140

2.7.1.2 Reinicialização de VPC . . . . . . . . . . . . . . . . . 142

2.7.1.3 Remoção de VPC . . . . . . . . . . . . . . . . . . . . 143

2.7.1.4 Aquisição de IP público para uma VPC . . . . . . . 144

2.7.2 Tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

2.7.2.1 Adição de tiers à VPC . . . . . . . . . . . . . . . . . 146

2.7.2.2 Remoção de tiers da VPC: . . . . . . . . . . . . . . . 148

2.7.3 Network ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

2.7.4 Domain VPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

2.7.4.1 Alocação de IPs públicos em domain VPCs . . . . . 153

2.8 Virtual Private Network (VPN) . . . . . . . . . . . . . . . . . . . . . . . 154

2.8.1 Tipos de VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

2.8.2 Operações com VPN . . . . . . . . . . . . . . . . . . . . . . . 155

2.8.2.1 Criação de VPN . . . . . . . . . . . . . . . . . . . . . 155

2.8.2.2 Desabilitação de VPN para a VPC . . . . . . . . . . 157

2.8.2.3 Gerência de usuários . . . . . . . . . . . . . . . . . 158

2.8.2.4 Adição de usuário . . . . . . . . . . . . . . . . . . . 158

2.8.2.5 Deﬁnição da quantidade máxima de usuário da

VPN por conta . . . . . . . . . . . . . . . . . . . . . 159

2.8.2.6 Exclusão de usuário . . . . . . . . . . . . . . . . . . 159

2.8.2.7 Conexão à VPN pelo Linux . . . . . . . . . . . . . . 160

2.8.2.8 Conexão à VPN pelo Windows . . . . . . . . . . . . 162

2.8.3 S2S (Site-to-Site) VPNs . . . . . . . . . . . . . . . . . . . . . . 166

2.9 Assinatura de requisições HTTP . . . . . . . . . . . . . . . . . . . . 171

2.10 Templates e ISOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

2.10.1 Operações com templates/ISOs . . . . . . . . . . . . . . . . . 178

2.10.1.1 Vizualização . . . . . . . . . . . . . . . . . . . . . . . 178

2.10.1.2 Listagem . . . . . . . . . . . . . . . . . . . . . . . . . 180

2.10.1.3 Resgitro . . . . . . . . . . . . . . . . . . . . . . . . . 182

2.10.1.4 Upload . . . . . . . . . . . . . . . . . . . . . . . . . . 185

2.10.1.5 Edição . . . . . . . . . . . . . . . . . . . . . . . . . . 187

2.10.1.6 Edição de permissões de template/ISO . . . . . . . 189

2.10.1.7 Edição de compartilhamento do template . . . . . 190

2.10.1.8 Remoção de template/ISO . . . . . . . . . . . . . . 192

2.10.1.9 Criação de template baseado em uma VM existente193

2.11 Resource Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

2.12 Aﬃnity Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

2.12.1 Tipos de aﬃnity groups . . . . . . . . . . . . . . . . . . . . . . 196

2.12.2 Operações com aﬃnity groups . . . . . . . . . . . . . . . . . 197

2.12.2.1 Adição de aﬃnity group . . . . . . . . . . . . . . . . 197

2.12.2.2 Adição de VM ao aﬃnity group . . . . . . . . . . . . 198

2.12.2.3 Visualização de VMs no aﬃnity group . . . . . . . . 200

2.12.2.4 Exclusão de aﬃnity group . . . . . . . . . . . . . . . 201

2.13 Autoscale VM groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

2.13.1 Criação de um autoscale VM group . . . . . . . . . . . . . . . 202

2.13.1.1 Conﬁguração da scale-down policy . . . . . . . . . . 207

2.13.1.2 Conﬁguração dos detalhes do autoscale VM group 208

2.13.1.3 Criação do grupo . . . . . . . . . . . . . . . . . . . . 208

2.13.2 Teste de autoscaling . . . . . . . . . . . . . . . . . . . . . . . 209

2.13.3 Edição de autoscale VM group . . . . . . . . . . . . . . . . . . 210

2.13.4 Exclusão de autoscale VM group . . . . . . . . . . . . . . . . 214

2.14 Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

2.14.1 Versões suportadas do Kubernetes . . . . . . . . . . . . . . 216

2.14.2 Adição de ISO Kubernetes ao Apache CloudStack . . . . . . 216

2.14.3 Deleção de ISO Kubernetes . . . . . . . . . . . . . . . . . . . 218

2.14.4 Clusters Kubernetes . . . . . . . . . . . . . . . . . . . . . . . 219

2.14.4.1 Criando clusters Kubernetes . . . . . . . . . . . . . 220

2.14.4.2 Scaling de cluster Kubernetes . . . . . . . . . . . . 222

2.14.4.3 Upgrade de cluster Kubernetes . . . . . . . . . . . . 223

2.14.5 Acesso ao Kubernetes . . . . . . . . . . . . . . . . . . . . . . 223

2.14.6 Gerando Token para a Dashboard . . . . . . . . . . . . . . . 225

2.15 Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

2.15.1 Tipos de snapshot . . . . . . . . . . . . . . . . . . . . . . . . . 225

2.15.1.1 Snapshot de volume/disco . . . . . . . . . . . . . . 225

2.15.1.2 Snapshot de VM . . . . . . . . . . . . . . . . . . . . 226

2.15.2 Operações com snapshot . . . . . . . . . . . . . . . . . . . . 226

2.15.2.1 Snapshot de volume . . . . . . . . . . . . . . . . . . 227

2.15.2.2 Snapshot de VM . . . . . . . . . . . . . . . . . . . . 228

2.15.2.3 Visualização dos snapshots criados . . . . . . . . . 229

2.15.2.4 Criação de template a partir de uma snapshot de

volume . . . . . . . . . . . . . . . . . . . . . . . . . 230

2.15.2.5 Criação de volume a partir de uma snapshot de

volume . . . . . . . . . . . . . . . . . . . . . . . . . 231

2.15.2.6 Reversão de snapshot de volume . . . . . . . . . . 232

2.15.2.7 Deleção de snapshot de volume . . . . . . . . . . . 233

2.15.2.8 Criação de snapshot de volume a partir de uma

snapshot de VM . . . . . . . . . . . . . . . . . . . . . 233

2.15.2.9 Reversão de snapshot de VM . . . . . . . . . . . . . 235

2.15.2.10Deleção de snapshot de VM . . . . . . . . . . . . . 235

2.15.2.11Conﬁguração de snapshots recorrentes . . . . . . 236

2.16 Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

2.16.1 Níveis de eventos . . . . . . . . . . . . . . . . . . . . . . . . . 236

2.16.2 Busca e ﬁltro de eventos . . . . . . . . . . . . . . . . . . . . 236

2.16.3 Remoção ou arquivamento de eventos . . . . . . . . . . . . 237

2.17 Interface de usuário (UI) . . . . . . . . . . . . . . . . . . . . . . . . . 238

2.17.1 Uso de timezone do browser . . . . . . . . . . . . . . . . . . . 238

2.17.2 Documentação na UI . . . . . . . . . . . . . . . . . . . . . . . 239

2.18 Service oﬀerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

2.18.1 Disk oﬀerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

2.18.1.1 Criação de disk oﬀering . . . . . . . . . . . . . . . . 240

2.18.1.2 Edição de disk oﬀering . . . . . . . . . . . . . . . . . 243

2.18.1.3 Exclusão de disk oﬀering . . . . . . . . . . . . . . . 245

2.18.2 Compute oﬀerings . . . . . . . . . . . . . . . . . . . . . . . . . 246

2.18.2.1 Criação de compute oﬀering . . . . . . . . . . . . . 246

2.18.2.2 Edição de compute oﬀering . . . . . . . . . . . . . . 251

2.18.2.3 Exclusão de compute oﬀering . . . . . . . . . . . . . 252

2.18.2.4 Alteração de compute oﬀering da VM . . . . . . . . 253

2.18.3 Network oﬀerings . . . . . . . . . . . . . . . . . . . . . . . . . 255

2.18.3.1 Criação de network oﬀering . . . . . . . . . . . . . . 255

2.18.3.2 Edição de network oﬀering . . . . . . . . . . . . . . 259

2.18.3.3 Exclusão de network oﬀering . . . . . . . . . . . . . 261

2.18.4 VPC Oﬀerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

2.18.4.1 Criação de VPC oﬀering . . . . . . . . . . . . . . . . 262

2.18.4.2 Edição de VPC oﬀering . . . . . . . . . . . . . . . . . 264

2.18.4.3 Exclusão de VPC oﬀering . . . . . . . . . . . . . . . 266

3 CloudMonkey, API e outros 268

3.1 Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

3.2 Conﬁguração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

3.3 Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

4 Contabilização do consumo de recursos 275

4.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

4.1.1 Relatórios de uso de recursos . . . . . . . . . . . . . . . . . 275

4.2 Quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

4.2.1 Tarifas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

4.2.2 Relatórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

4.2.2.1 Créditos . . . . . . . . . . . . . . . . . . . . . . . . . 277

4.2.2.2 Uso de recursos . . . . . . . . . . . . . . . . . . . . 278

4.2.2.3 Balanço . . . . . . . . . . . . . . . . . . . . . . . . . 281

5 Cloud-init 284

5.1 Etapas de inicialização . . . . . . . . . . . . . . . . . . . . . . . . . . 284

5.2 Frequência de execução . . . . . . . . . . . . . . . . . . . . . . . . . 285

5.3 DataSources conhecidos . . . . . . . . . . . . . . . . . . . . . . . . . 286

5.4 Módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

5.5 Criação de uma imagem personalizada . . . . . . . . . . . . . . . . 287

5.6 Cloud-init no Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 290

5.7 Troubleshooting do cloud-init . . . . . . . . . . . . . . . . . . . . . . 290

5.8 Obrigação de troca de senha no primeiro login . . . . . . . . . . . 290

5.9 Auto incremento do tamanho do disco durante o boot . . . . . . . 291

5.10 Interação com o user-data . . . . . . . . . . . . . . . . . . . . . . . . 292

6 Conclusão 293

Apêndice A Terminologia 295

Lista de Figuras

1 Computação em nuvem . . . . . . . . . . . . . . . . . . . . . . . . . 28

2 Dashboard inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Diagrama de relacionamento entre contas, domínios, projetos e

usuários. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Navegando até a página de adição de accounts . . . . . . . . . . . 34

5 Adicionando uma nova account . . . . . . . . . . . . . . . . . . . . . 34

6 Navegando até a página de detalhes de uma account . . . . . . . . 35

7 Vendo os detalhes da account . . . . . . . . . . . . . . . . . . . . . . 35

8 Deletando uma account . . . . . . . . . . . . . . . . . . . . . . . . . 36

9 Conﬁrmando a remoção da account . . . . . . . . . . . . . . . . . . 36

10 Editando os limites de uma account . . . . . . . . . . . . . . . . . . 37

11 Editando as conﬁgurações de uma account . . . . . . . . . . . . . . 38

12 Desabilitando uma account . . . . . . . . . . . . . . . . . . . . . . . 38

13 Conﬁrmando a desabilitação da account . . . . . . . . . . . . . . . 39

14 Bloqueando uma account . . . . . . . . . . . . . . . . . . . . . . . . 39

15 Conﬁrmando o bloqueio da account . . . . . . . . . . . . . . . . . . 39

16 Deﬁnindo duas faixas IPv4 e uma IPv6 . . . . . . . . . . . . . . . . 40

17 Iniciando a criação de uma nova role . . . . . . . . . . . . . . . . . 41

18 Criando a nova role . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

19 Acessando a recém-criada role . . . . . . . . . . . . . . . . . . . . . 43

20 Customizando as regras da role . . . . . . . . . . . . . . . . . . . . 43

21 Iniciando a edição de uma role . . . . . . . . . . . . . . . . . . . . . 44

22 Editando a role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

23 Removendo uma role . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

24 Conﬁrmando a remoção da role . . . . . . . . . . . . . . . . . . . . 44

25 Acessando a página de domains . . . . . . . . . . . . . . . . . . . . 46

26 Criando um novo domain . . . . . . . . . . . . . . . . . . . . . . . . 46

27 Deﬁnindo o nome do novo domain . . . . . . . . . . . . . . . . . . 47

28 Visualizando o domain criado . . . . . . . . . . . . . . . . . . . . . . 47

29 Selecionando o domain criado . . . . . . . . . . . . . . . . . . . . . 47

30 Iniciando a edição do novo domain . . . . . . . . . . . . . . . . . . 48

31 Editando o domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

32 Navegando até a página de accounts . . . . . . . . . . . . . . . . . . 51

33 Selecione a account que o novo user fará parte . . . . . . . . . . . 51

34 Veja os users da account . . . . . . . . . . . . . . . . . . . . . . . . . 52

35 Adicionando um novo user . . . . . . . . . . . . . . . . . . . . . . . 52

36 Deﬁna os dados do novo user e salve as alterações . . . . . . . . . 52

37 Selecionando o user para editá-lo . . . . . . . . . . . . . . . . . . . 53

38 Iniciando a edição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

39 Editando o user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

40 Deletando um user . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

41 Conﬁrme a remoção do user . . . . . . . . . . . . . . . . . . . . . . 54

42 Desabilitando um user . . . . . . . . . . . . . . . . . . . . . . . . . . 54

43 Selecionando o user que deseja reabilitar . . . . . . . . . . . . . . . 55

44 Habilitando um user . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

45 Encontrando as conﬁgurações . . . . . . . . . . . . . . . . . . . . . 56

46 Mensagem exibida ao tentar realizar login com user desabilitado . 57

47 Gerar chaves de acesso para um usuário . . . . . . . . . . . . . . . 58

48 Mensagem de conﬁrmação para gerar chaves de acesso . . . . . 58

49 Conﬁgurando a autenticação de dois fatores. . . . . . . . . . . . . 60

50 Opções de provedores de autenticação de dois fatores. . . . . . . 61

51 Conﬁgurando a autenticação de dois fatores com TOTP. . . . . . . 61

52 Veriﬁcação com TOTP durante o login. . . . . . . . . . . . . . . . . . 62

53 Conﬁgurando a autenticação de dois fatores com static PIN. . . . . 62

54 Veriﬁcação com static PIN durante o login. . . . . . . . . . . . . . . 63

55 Desativando a autenticação de dois fatores. . . . . . . . . . . . . . 63

56 Conﬁgurando a autenticação de dois fatores no login. . . . . . . . 64

57 Exemplo de como o timezone afeta a interface do Apache Cloud-

Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

58 Editando o timezone do user . . . . . . . . . . . . . . . . . . . . . . . 65

59 Ativando a funcionalidade de timezone local . . . . . . . . . . . . . 65

60 Iniciando a criação de um novo project . . . . . . . . . . . . . . . . 66

61 Criando o novo project . . . . . . . . . . . . . . . . . . . . . . . . . . 67

62 Limites de recursos de um project . . . . . . . . . . . . . . . . . . . 67

63 Alterando os limites de recursos de um project . . . . . . . . . . . 69

64 Iniciando a criação de uma project role . . . . . . . . . . . . . . . . 70

65 Criando uma project role . . . . . . . . . . . . . . . . . . . . . . . . . 70

66 Deﬁnindo as regras da project role . . . . . . . . . . . . . . . . . . . 70

67 Iniciando a adição de membros no project . . . . . . . . . . . . . . 71

68 Adicionando uma account no project . . . . . . . . . . . . . . . . . . 72

69 Adicionando um user no project . . . . . . . . . . . . . . . . . . . . 72

70 Selecionando a view . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

71 Iniciando a edição do project . . . . . . . . . . . . . . . . . . . . . . 75

72 Editando o project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

73 Iniciando a suspensão do project . . . . . . . . . . . . . . . . . . . . 76

74 Suspendendo o project . . . . . . . . . . . . . . . . . . . . . . . . . . 76

75 Iniciando a exclusão do project . . . . . . . . . . . . . . . . . . . . . 77

76 Excluíndo o project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

77 Adicionando uma VM . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

78 Conﬁguração de atribuição, infra e template/ISO de VM como root

admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

79 Conﬁguração de compute oﬀering e da disk oﬀering como root admin 80

80 Conﬁguração da network, chave SSH e opções avançadas como

root admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

81 Conﬁguração de detalhes da VM como root admin . . . . . . . . . 81

82 Conﬁguração de atribuição, zona e template/ISO de VM como admin 82

83 Conﬁguração de compute oﬀering e da disk oﬀering como admin . 83

84 Conﬁguração da network, chave SSH e opções avançadas como

admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

85 Conﬁguração de detalhes da VM como admin . . . . . . . . . . . . 84

86 Conﬁguração de zona, template/ISO e compute oﬀering de VM como

user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

87 Conﬁguração de disk oﬀering e network como user . . . . . . . . . 86

88 Conﬁguração de chave SSH e opções avançadas como user . . . . 86

89 Conﬁguração de detalhes da VM como user . . . . . . . . . . . . . 87

90 Visualização das opções de inicialização . . . . . . . . . . . . . . . 89

91 Opções de inicialização no formulário de deploy de uma VM . . . 89

92 Conﬁguração ﬁnal da VM . . . . . . . . . . . . . . . . . . . . . . . . 90

93 Escolhendo a VM que será destruída . . . . . . . . . . . . . . . . . 91

94 Conﬁrmando a destruição da VM . . . . . . . . . . . . . . . . . . . . 92

95 Parando e iniciando uma VM . . . . . . . . . . . . . . . . . . . . . . 92

96 Escolhendo a VM que será reiniciada . . . . . . . . . . . . . . . . . 92

97 Reiniciando a VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

98 Botões de acesso e cópia de URL do console da VM . . . . . . . . . 93

99 Resposta da API createConsoleEndpoint . . . . . . . . . . . . . . . 94

100 Ativando dynamic scaling em uma VM . . . . . . . . . . . . . . . . . 95

101 Conﬁgurando dynamic scaling em um template . . . . . . . . . . . . 96

102 Escolhendo a VM que terá sua account migrada . . . . . . . . . . . 98

103 Migrando account da VM . . . . . . . . . . . . . . . . . . . . . . . . . 99

104 Criando um stored user data . . . . . . . . . . . . . . . . . . . . . . . 100

105 Formulário de criação de stored user data . . . . . . . . . . . . . . . 101

106 Selecionando o user data script para ver detalhes . . . . . . . . . . 102

107 Detalhes do user data script . . . . . . . . . . . . . . . . . . . . . . . 102

108 Adicionando a stored user data à uma VM . . . . . . . . . . . . . . . 103

109 Adicionando user data script na criação da VM . . . . . . . . . . . . 103

110 Alterando user data script na edição da VM . . . . . . . . . . . . . . 104

111 Veriﬁcando funcionalidade do user data script . . . . . . . . . . . . 104

112 Aba de conﬁgurações da VM . . . . . . . . . . . . . . . . . . . . . . 105

113 Visualizar todos os volumes . . . . . . . . . . . . . . . . . . . . . . . 109

114 Criar novo volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

115 Conﬁgurar novo volume . . . . . . . . . . . . . . . . . . . . . . . . . 110

116 Veriﬁcando novo volume . . . . . . . . . . . . . . . . . . . . . . . . 110

117 Upload de volume local . . . . . . . . . . . . . . . . . . . . . . . . . 110

118 Realizar upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

119 Fazendo upload de volume . . . . . . . . . . . . . . . . . . . . . . . 113

120 Conﬁgurando o upload de volume . . . . . . . . . . . . . . . . . . . 113

121 Acessando os detalhes do volume . . . . . . . . . . . . . . . . . . . 114

122 Adicionando o volume à VM . . . . . . . . . . . . . . . . . . . . . . . 114

123 Conﬁgurando a VM que receberá o novo volume . . . . . . . . . . 115

124 Removendo o volume da VM . . . . . . . . . . . . . . . . . . . . . . 115

125 Conﬁrmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

126 Redimensionar o volume . . . . . . . . . . . . . . . . . . . . . . . . 116

127 Conﬁgurar redimensionamento . . . . . . . . . . . . . . . . . . . . 117

128 Fazer download do volume . . . . . . . . . . . . . . . . . . . . . . . 117

129 Conﬁrmar download . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

130 Adicionando automatização de snapshots para um volume . . . . 118

131 Conﬁgurando a automatização das snapshots . . . . . . . . . . . . 118

132 Removendo o volume . . . . . . . . . . . . . . . . . . . . . . . . . . 119

133 Conﬁrmar a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

134 Rede isolada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

135 Rede isolada criada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

136 Conﬁgurando as egress rules . . . . . . . . . . . . . . . . . . . . . . 121

137 Criando rede shared - Parte 1 . . . . . . . . . . . . . . . . . . . . . . 123

138 Criando rede shared - Parte 2 . . . . . . . . . . . . . . . . . . . . . . 124

139 Rede shared criada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

140 Criando uma rede L2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

141 Rede L2 criada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

142 Navegando até a rede guest . . . . . . . . . . . . . . . . . . . . . . . 126

143 Acessando os detalhes de uma rede guest . . . . . . . . . . . . . . 127

144 Excluindo uma rede . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

145 Conﬁrmando a exclusão da rede . . . . . . . . . . . . . . . . . . . . 127

146 Editando uma rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

147 Reiniciando uma rede . . . . . . . . . . . . . . . . . . . . . . . . . . 128

148 Acessando a rede client-network. . . . . . . . . . . . . . . . . . . . 129

149 Adicionando uma conta em Add network permission. . . . . . . . 129

150 Após adição da network permission. . . . . . . . . . . . . . . . . . . 130

151 Acessando o IP público . . . . . . . . . . . . . . . . . . . . . . . . . . 130

152 Vendo os detalhes do IP público . . . . . . . . . . . . . . . . . . . . 131

153 Conﬁgurando o ﬁrewall . . . . . . . . . . . . . . . . . . . . . . . . . 131

154 Habilitando static NAT . . . . . . . . . . . . . . . . . . . . . . . . . . 132

155 Conﬁgurando o IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

156 Veriﬁcando a conﬁguração ﬁnal . . . . . . . . . . . . . . . . . . . . 133

157 Acessando e conﬁgurando as portas da aba de port forwarding . . 134

158 Escolhendo a VM que terá a porta mapeada . . . . . . . . . . . . . 134

159 Exemplo de conﬁguração de port forwarding com várias VMs . . . 134

160 Acessando e conﬁgurando as portas do load balancing . . . . . . . 135

161 Adicionando as VMs que serão gerenciadas pelo load balancer . . 135

162 Load balancer criado . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

163 Removendo o IP público . . . . . . . . . . . . . . . . . . . . . . . . . 136

164 Acessando os detalhes da rede . . . . . . . . . . . . . . . . . . . . . 137

165 Acesse os IPs públicos da rede . . . . . . . . . . . . . . . . . . . . . 137

166 Adquirir um novo IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

167 Lista de IPs disponíveis . . . . . . . . . . . . . . . . . . . . . . . . . . 138

168 Novo IP adquirido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

169 Criando uma nova VPC . . . . . . . . . . . . . . . . . . . . . . . . . . 140

170 Conﬁgurando a nova VPC . . . . . . . . . . . . . . . . . . . . . . . . 141

171 Veriﬁcando se a VPC foi corretamente criada . . . . . . . . . . . . . 141

172 Reiniciando uma VPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

173 Opções de reinicialização de uma VPC . . . . . . . . . . . . . . . . . 143

174 Removendo uma VPC . . . . . . . . . . . . . . . . . . . . . . . . . . 143

175 Conﬁrmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

176 Erro que ocorre ao tentar deletar uma VPC . . . . . . . . . . . . . . 144

177 Acessando a VPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

178 Acessando os IPs públicos da VPC . . . . . . . . . . . . . . . . . . . 145

179 Escolhendo um IP público . . . . . . . . . . . . . . . . . . . . . . . . 145

180 Acessando a VPC criada . . . . . . . . . . . . . . . . . . . . . . . . . 146

181 Veriﬁcando os detalhes da VPC . . . . . . . . . . . . . . . . . . . . . 146

182 Adicionando um novo tier . . . . . . . . . . . . . . . . . . . . . . . . 146

183 Criando um novo tier . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

184 Navegando até os tiers . . . . . . . . . . . . . . . . . . . . . . . . . . 148

185 Removendo um tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

186 Conﬁrmando a remoção do tier . . . . . . . . . . . . . . . . . . . . 148

187 Adicionando uma nova ACL . . . . . . . . . . . . . . . . . . . . . . . 149

188 Criando uma nova ACL . . . . . . . . . . . . . . . . . . . . . . . . . . 150

189 Navegando até a ACL criada . . . . . . . . . . . . . . . . . . . . . . . 150

190 Navegando até a criação de uma nova regra na ACL . . . . . . . . 150

191 Adicionando regra que permite o tráfego de entrada da porta 22

do protocolo TCP (SSH) . . . . . . . . . . . . . . . . . . . . . . . . . . 151

192 Adicionando regra que permite o tráfego de saída da porta 22 do

protocolo TCP (SSH) . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

193 Seleção da conta dona do tier . . . . . . . . . . . . . . . . . . . . . . 153

194 Seleção da conta no formulário de aquisição de IP público . . . . 154

195 Selecionando a VPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

196 Detalhes da VPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

197 Detalhes do public IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

198 Habilitando a VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

199 VPN habilitada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

200 Desabilitar a VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

201 Gerenciar usuários da VPN . . . . . . . . . . . . . . . . . . . . . . . 158

202 Iniciando adição de usuário à VPN . . . . . . . . . . . . . . . . . . . 158

203 Adicionando usuário à VPN . . . . . . . . . . . . . . . . . . . . . . . 159

204 Excluíndo usuário da VPN . . . . . . . . . . . . . . . . . . . . . . . . 159

205 Iniciando a adição de uma VPN no Linux . . . . . . . . . . . . . . . 160

206 Adicionando uma VPN no Linux . . . . . . . . . . . . . . . . . . . . 160

207 Informando a IPSec pre-shared key - Parte 1 . . . . . . . . . . . . . 161

208 Informando a IPSec pre-shared key - Parte 2 . . . . . . . . . . . . . 161

209 Desabilitando o protocolo EAP - Parte 1 . . . . . . . . . . . . . . . . 161

210 Desabilitando o protocolo EAP - Parte 2 . . . . . . . . . . . . . . . . 162

211 Adicionando uma VPN no Windows . . . . . . . . . . . . . . . . . . 162

212 Iniciando a adição de uma VPN no Windows . . . . . . . . . . . . . 163

213 Finalizando a adição de uma VPN no Windows . . . . . . . . . . . . 163

214 Alterando conﬁgurações do PPP . . . . . . . . . . . . . . . . . . . . 164

215 Habilitando o protocolo MS-CHAP v2 . . . . . . . . . . . . . . . . . 165

216 Desabilitando IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

217 Desabilitando o uso de gateway padrão na rede remota . . . . . . 166

218 Navegando até a aba VPN customer gateway . . . . . . . . . . . . . 166

219 Criando um VPN customer gateway . . . . . . . . . . . . . . . . . . . 167

220 Editando um VPN customer gateway . . . . . . . . . . . . . . . . . . 168

221 Deletando um VPN customer gateway . . . . . . . . . . . . . . . . . 168

222 Navegando até VPN gateway nos detalhes da VPC . . . . . . . . . . 169

223 Criando um VPN gateway . . . . . . . . . . . . . . . . . . . . . . . . 169

224 Navegando até VPN connection nos detalhes da VPC . . . . . . . . 170

225 Criando uma conexão VPN S2S . . . . . . . . . . . . . . . . . . . . . 170

226 Reiniciando uma conexão VPN S2S . . . . . . . . . . . . . . . . . . . 171

227 Removendo uma conexão VPN S2S . . . . . . . . . . . . . . . . . . 171

228 Gerando keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

229 Visualizando templates e ISOs . . . . . . . . . . . . . . . . . . . . . . 178

230 Acessando os detalhes do template . . . . . . . . . . . . . . . . . . 179

231 Detalhes do template . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

232 Acessando os detalhes da ISO . . . . . . . . . . . . . . . . . . . . . 180

233 Detalhes da ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

234 Filtros para listagem de ISOs e templates. . . . . . . . . . . . . . . . 182

235 Registrando o template . . . . . . . . . . . . . . . . . . . . . . . . . . 182

236 Conﬁgurando o template . . . . . . . . . . . . . . . . . . . . . . . . . 183

237 Registrando a ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

238 Conﬁgurando a ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

239 Fazendo upload do template . . . . . . . . . . . . . . . . . . . . . . . 185

240 Conﬁgurando o template . . . . . . . . . . . . . . . . . . . . . . . . . 186

241 Fazendo upload da ISO . . . . . . . . . . . . . . . . . . . . . . . . . . 186

242 Conﬁgurando a ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

243 Editando detalhes do template . . . . . . . . . . . . . . . . . . . . . 187

244 Editando o template . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

245 Editando detalhes da ISO . . . . . . . . . . . . . . . . . . . . . . . . 188

246 Editando a ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

247 Editando as permissões do template . . . . . . . . . . . . . . . . . . 189

248 Editando as permissões da ISO . . . . . . . . . . . . . . . . . . . . . 190

249 Editando permissões . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

250 Editando compartilhamento do template . . . . . . . . . . . . . . . 191

251 Editando compartilhamento da ISO . . . . . . . . . . . . . . . . . . 191

252 Editando opções de compartilhamento . . . . . . . . . . . . . . . . 191

253 Deletando o template . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

254 Deletando a ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

255 Navegando até as VMs . . . . . . . . . . . . . . . . . . . . . . . . . . 193

256 Indo até o volume da VM . . . . . . . . . . . . . . . . . . . . . . . . 194

257 Criando o template . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

258 Conﬁgurando o template . . . . . . . . . . . . . . . . . . . . . . . . . 195

259 Resource tags de um componente qualquer . . . . . . . . . . . . . 195

260 Navegando até os aﬃnity groups . . . . . . . . . . . . . . . . . . . . 197

261 Criando um aﬃnity group . . . . . . . . . . . . . . . . . . . . . . . . 197

262 Aﬃnity group criado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

263 Acessando a VM que será movida ao grupo . . . . . . . . . . . . . 198

264 Movendo a VM para um aﬃnity group . . . . . . . . . . . . . . . . . 199

265 Selecionando o grupo . . . . . . . . . . . . . . . . . . . . . . . . . . 199

266 Acessando o grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

267 Visualizando as VMs no grupo . . . . . . . . . . . . . . . . . . . . . 200

268 Lista de VMs no grupo . . . . . . . . . . . . . . . . . . . . . . . . . . 201

269 Excluindo o grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

270 Criando uma rede isolada . . . . . . . . . . . . . . . . . . . . . . . . 203

271 Acessando a aba de Public IP addresses . . . . . . . . . . . . . . . . 203

272 Adquirindo um novo IP público . . . . . . . . . . . . . . . . . . . . . 204

273 Adicionando uma regra de load balancing . . . . . . . . . . . . . . 204

274 Selecionando a rede isolada . . . . . . . . . . . . . . . . . . . . . . . 205

275 Selecionando a regra de load balancing . . . . . . . . . . . . . . . . 205

276 Conﬁgurando a scale-up policy . . . . . . . . . . . . . . . . . . . . . 207

277 Conﬁgurando a scale-down policy . . . . . . . . . . . . . . . . . . . . 207

278 Conﬁgurando os detalhes do autoscale VM group . . . . . . . . . . 208

279 Visualizando as instâncias do autoscale VM group . . . . . . . . . . 209

280 Instâncias do autoscale VM group . . . . . . . . . . . . . . . . . . . . 209

281 Instâncias do autoscale VM group após o scale-up . . . . . . . . . . 210

282 Instâncias do autoscale VM group após o scale-down . . . . . . . . . 210

283 Desativando o autoscale VM group . . . . . . . . . . . . . . . . . . . 211

284 Conﬁrmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

285 Editando os detalhes do grupo e parâmetros de deploy das VMs . 212

286 Diálogo de edição dos detalhes do grupo e parâmetros de deploy

das VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

287 Editando a scale-up policy do grupo . . . . . . . . . . . . . . . . . . 213

288 Editando a scale-down policy do grupo . . . . . . . . . . . . . . . . . 213

289 Ativando o autoscale VM group . . . . . . . . . . . . . . . . . . . . . 214

290 Conﬁrmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

291 Excluindo o autoscale VM group . . . . . . . . . . . . . . . . . . . . . 215

292 Conﬁrmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

293 Formulário de adição de versão Kubernetes . . . . . . . . . . . . . 218

294 Deletando ISO Kubernetes via UI . . . . . . . . . . . . . . . . . . . . 219

295 Conﬁrmar exclusão da ISO Kubernetes . . . . . . . . . . . . . . . . 219

296 Formulário de criação de cluster Kubernetes . . . . . . . . . . . . . 221

297 Formulário de scaling de cluster Kubernetes . . . . . . . . . . . . . 222

298 Formulário de upgrade de cluster Kubernetes . . . . . . . . . . . . 223

299 Acessando o Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . 224

300 Acessando os detalhes de uma VM . . . . . . . . . . . . . . . . . . 227

301 Tirando uma snapshot do Volume . . . . . . . . . . . . . . . . . . . 227

302 Escolhendo o volume que será tirada a snapshot . . . . . . . . . . 227

303 Conﬁgurando a snapshot . . . . . . . . . . . . . . . . . . . . . . . . 228

304 Tirando uma snapshot da VM . . . . . . . . . . . . . . . . . . . . . . 228

305 Conﬁgurando a snapshot . . . . . . . . . . . . . . . . . . . . . . . . 228

306 Acessando as snapshots . . . . . . . . . . . . . . . . . . . . . . . . . 229

307 Acessando as snapshots de volumes . . . . . . . . . . . . . . . . . . 229

308 Acessando as snapshots de VM . . . . . . . . . . . . . . . . . . . . . 229

309 Acessando os detalhes da snapshot . . . . . . . . . . . . . . . . . . 230

310 Criando o template . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

311 Conﬁgurando os dados do template . . . . . . . . . . . . . . . . . . 231

312 Criando o novo volume . . . . . . . . . . . . . . . . . . . . . . . . . 231

313 Conﬁgurando o novo volume . . . . . . . . . . . . . . . . . . . . . . 232

314 Revertendo para a snapshot . . . . . . . . . . . . . . . . . . . . . . . 232

315 Conﬁrmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

316 Deletando a snapshot de volume . . . . . . . . . . . . . . . . . . . . 233

317 Conﬁrmando a remoção . . . . . . . . . . . . . . . . . . . . . . . . . 233

318 Acessando os detalhes da snapshot da VM . . . . . . . . . . . . . . 233

319 Criando uma snapshot de volume a partir da snapshot da VM . . . 234

320 Conﬁgurando qual volume será extraído . . . . . . . . . . . . . . . 234

321 Criando uma snapshot de volume . . . . . . . . . . . . . . . . . . . 234

322 Revertendo a snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . 235

323 Conﬁrmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

324 Removendo a snapshot de VM . . . . . . . . . . . . . . . . . . . . . 235

325 Conﬁrmando a ação . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

326 Navegando pelos eventos . . . . . . . . . . . . . . . . . . . . . . . . 237

327 Arquivando ou deletando um evento . . . . . . . . . . . . . . . . . 237

328 Habilitando a conﬁguração . . . . . . . . . . . . . . . . . . . . . . . 238

329 Exemplo de popup com os ícones de ajuda . . . . . . . . . . . . . . 239

330 Iniciando a criação de uma nova disk oﬀering . . . . . . . . . . . . . 240

331 Criando a nova disk oﬀering . . . . . . . . . . . . . . . . . . . . . . . 241

332 Iniciando a edição da disk oﬀering . . . . . . . . . . . . . . . . . . . 243

333 Editando a disk oﬀering . . . . . . . . . . . . . . . . . . . . . . . . . . 244

334 Iniciando a atualização de acesso da disk oﬀering . . . . . . . . . . 244

335 Atualizando o acesso da disk oﬀering . . . . . . . . . . . . . . . . . 244

336 Alterando ordem da disk oﬀering . . . . . . . . . . . . . . . . . . . . 245

337 Iniciando a exclusão da disk oﬀering . . . . . . . . . . . . . . . . . . 245

338 Excluindo a disk oﬀering . . . . . . . . . . . . . . . . . . . . . . . . . 245

339 Iniciando a criação de uma nova compute oﬀering . . . . . . . . . . 247

340 Criando a nova compute oﬀering - 1 - continua . . . . . . . . . . . . 248

341 Iniciando a edição da compute oﬀering . . . . . . . . . . . . . . . . 251

342 Editando a compute oﬀering . . . . . . . . . . . . . . . . . . . . . . . 251

343 Iniciando a atualização de acesso da compute oﬀering . . . . . . . 252

344 Atualizando o acesso da compute oﬀering . . . . . . . . . . . . . . . 252

345 Alterando a ordem da compute oﬀering . . . . . . . . . . . . . . . . 252

346 Iniciando a exclusão da compute oﬀering . . . . . . . . . . . . . . . 252

347 Excluíndo a compute oﬀering . . . . . . . . . . . . . . . . . . . . . . 253

348 Iniciando a alteração da compute oﬀering . . . . . . . . . . . . . . . 253

349 Alterando a compute oﬀering . . . . . . . . . . . . . . . . . . . . . . 254

350 Alterando a compute oﬀering . . . . . . . . . . . . . . . . . . . . . . 254

351 Iniciando a criação de uma nova network oﬀering . . . . . . . . . . 256

352 Criando a nova network oﬀering - 1 - continua . . . . . . . . . . . . 256

353 Criando a nova network oﬀering - 2 . . . . . . . . . . . . . . . . . . . 258

354 Iniciando a edição da network oﬀering . . . . . . . . . . . . . . . . . 259

355 Editando a network oﬀering . . . . . . . . . . . . . . . . . . . . . . . 259

356 Iniciando a desabilitação da network oﬀering . . . . . . . . . . . . . 260

357 Desabilitando a network oﬀering . . . . . . . . . . . . . . . . . . . . 260

358 Iniciando a atualização de acesso da network oﬀering . . . . . . . . 260

359 Atualizando o acesso da network oﬀering . . . . . . . . . . . . . . . 261

360 Alterando ordem da network oﬀering . . . . . . . . . . . . . . . . . 261

361 Iniciando a exclusão da network oﬀering . . . . . . . . . . . . . . . . 262

362 Excluíndo a network oﬀering . . . . . . . . . . . . . . . . . . . . . . . 262

363 Iniciando a criação de uma nova VPC oﬀering . . . . . . . . . . . . . 263

364 Criando a nova VPC oﬀering . . . . . . . . . . . . . . . . . . . . . . . 264

365 Iniciando a edição da VPC oﬀering . . . . . . . . . . . . . . . . . . . 265

366 Editando a VPC oﬀering . . . . . . . . . . . . . . . . . . . . . . . . . . 265

367 Iniciando a desabilitação da VPC oﬀering . . . . . . . . . . . . . . . 265

368 Desabilitando a VPC oﬀering . . . . . . . . . . . . . . . . . . . . . . . 265

369 Iniciando a atualização de acesso da VPC oﬀering . . . . . . . . . . 266

370 Atualizando o acesso da VPC oﬀering . . . . . . . . . . . . . . . . . 266

371 Alterando a ordem da VPC oﬀering . . . . . . . . . . . . . . . . . . . 266

372 Iniciando a exclusão da VPC oﬀering . . . . . . . . . . . . . . . . . . 267

373 Excluíndo a VPC oﬀering . . . . . . . . . . . . . . . . . . . . . . . . . 267

374 Utilizando o autocomplete . . . . . . . . . . . . . . . . . . . . . . . . 270

375 Veriﬁcando o autocomplete para um comando especíﬁco . . . . . 271

376 Veriﬁcando o autocomplete para uma API especíﬁca . . . . . . . . 271

377 Utilizando o -h para obter ajuda . . . . . . . . . . . . . . . . . . . . 272

378 Realizando uma chamada . . . . . . . . . . . . . . . . . . . . . . . . 273

379 Fazendo deploy de uma VM via CloudMonkey . . . . . . . . . . . . 274

380 Listagem das tarifas ativas . . . . . . . . . . . . . . . . . . . . . . . . 276

381 Detalhes das tarifas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

382 Acessando detalhes e relatórios de uma conta . . . . . . . . . . . . 277

383 Listagem de créditos . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

384 Listagem de uso de recurso . . . . . . . . . . . . . . . . . . . . . . . 279

385 Listagem detalhada de uso de recurso . . . . . . . . . . . . . . . . 280

386 Listagem do balanço do Quota . . . . . . . . . . . . . . . . . . . . . 282

Lista de Tabelas

1 Conﬁgurações de autenticação de dois fatores . . . . . . . . . . . 60

2 Conﬁguração de criação de projeto para usuário regular . . . . . 66

3 Conﬁgurações de limite de recursos em projetos . . . . . . . . . . 68

4 Conﬁgurações de convite para projeto . . . . . . . . . . . . . . . . 73

5 Conﬁgurações de serviço de envio de email . . . . . . . . . . . . . 74

6 Conﬁgurações gerais de VM . . . . . . . . . . . . . . . . . . . . . . . 105

7 Conﬁgurações para VM com compute oﬀering personalizada . . . 105

8 Conﬁgurações de VM para uso interno . . . . . . . . . . . . . . . . 106

9 Conﬁgurações de VM com NIC, disco e paramêtros personaliza-

dos para compute oﬀering personalizada . . . . . . . . . . . . . . . 106

10 Quantidade máxima de volumes suportados por hypervisor . . . . 116

11 Conﬁguração do tamanho da chave IPSec compartilhada . . . . . 157

12 Conﬁguração de Limite de Usuário na VPN por Account . . . . . . 159

13 Parâmetros de tempo de expiração para chamadas à API . . . . . 176

14 Matriz de compatibilidade entre versões do ACS e do K8s . . . . . 217

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, ﬁque atento a

novas atualizações.

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, intensiﬁcando 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 eﬁciente 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 proﬁssionais 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.

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:

• 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 conﬁguração de redes compartilhadas e dedicadas;

– Criação de VLANS, VxLANS (Overlay Networks) e novas topologias;

– Deﬁniçã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 Deﬁned Storage), e.g. Ceph/RBD.

• Serviços de monitoramento de recursos

– Monitoramento de eventos;

– Apresentação dos recursos disponíveis e utilizados;

– Preciﬁcaçã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;

• 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.

2. Funcionalidades do Apache CloudStack

Nessa seção serão introduzidas, de forma breve, as principais funcionali-

dade do Apache CloudStack e como utilizá-las.

2.1. Dashboard inicial

Esse é o dashboard padrão do Apache CloudStack, onde é possível visualizar

a quantidade de recursos consumidos pelo usuário.

Figura 2: Dashboard inicial

2.2. Gestão de acesso à nuvem

O CloudStack permite que o administrador da nuvem deﬁna e gerencie com

precisão quais recursos estão disponíveis e para quem através de domínios,

contas, usuários, projetos e roles. Para tal, primeiramente é necessário enten-

der esses conceitos.

• Conta: uma conta representa um cliente do provedor de serviços da nu-

vem, podendo ser acessada, ou não, por diversos usuários. Nesse con-

texto uma conta deﬁne, por exemplo, um departamento de uma empresa

ou uma faculdade dentro de uma universidade, abrigando os usuários

desses setores.

• Usuário: o usuário, por sua vez, é um integrante da conta. Ele pertence

apenas à uma conta, possui acesso aos recursos de acordo com o tipo da

conta e recebe o mesmo nível de privilégios da conta que o abriga. Eles

são alias para a conta.

• Domínio: um domínio pode conter diversas contas que, geralmente, pos-

suem um relacionamento lógico entre si. São utilizados para limitar os

recursos que serão entregues aos usuários desse domínio.

• Projeto: projetos são uma forma de organizar contas e recursos. Os

usuários podem ser agrupados em projetos para compartilhar recursos

como VMs, snapshots, templates e endereços IP. Recursos criados em um

projeto pertencem apenas a ele, não à uma conta, e só podem ser usa-

dos dentro dele. Os membros do projeto podem visualizar e gerenciar os

recursos virtuais criados por qualquer conta dentro dele.

• Roles: deﬁnido a nível de conta e/ou de projeto, são conjuntos que deﬁ-

nem as permissões que as contas e os usuários terão no ambiente, como

criação, listagem e remoção de recursos.

A ﬁgura a seguir apresenta um diagrama de relacionamento entre contas,

domínios, projetos e usuários.

Figura 3: Diagrama de relacionamento entre contas, domínios, projetos e usuários.

2.2.1. Account

Representa um cliente que utiliza os serviços da nuvem. No CloudStack,

uma account pode ser utilizada por mais de um usuário, ao ponto em que uma

organização inteira pode utilizar a mesma conta. Ela pode ser dividida em três

tipos básicos para visualização dos recursos, sendo estes tipos deﬁnidos no

momento da criação da role:

• Admin: possui acesso a todos os recursos do ambiente, incluindo ele-

mentos de infraestrutura e conﬁgurações da plataforma. Essas contas

também são chamadas de root admin.

• DomainAdmin: possui acesso a todos os elementos alocados em seu

domínio, incluindo gestão de usuários.

• ResourceAdmin: possui acesso a todos os elementos alocados em seu

domínio, exceto gestão de usuários.

• User: possui acesso somente aos elementos alocados em sua conta.

O conjunto de permissões para cada tipo de conta é deﬁnido através das

roles; contudo, algumas ações, bem como o escopo dos recursos visualizados,

dependem do tipo da conta.

Uma account criada não pode ter seu tipo alterado, mas pode ter seu con-

junto de permissões alterado.

É possível realizar as seguintes operações sobre as accounts:

2.2.1.1. Adição de account

Figura 4: Navegando até a página de adição de accounts

Figura 5: Adicionando uma nova account

2.2.1.2. Visualização de detalhes de account

Figura 6: Navegando até a página de detalhes de uma account

Figura 7: Vendo os detalhes da account

Todas as operações abaixo detalhadas são realizadas nessa página.

2.2.1.3. Deleção de account

Figura 8: Deletando uma account

Ao tentar deletar uma account, um popup irá pedir a conﬁrmação dessa ação.

Durante esse processo de remoção, todos os usuários e recursos (VM, snapshots,

templates, volumes, etc) relacionados à account também serão removidos.

Figura 9: Conﬁrmando a remoção da account

2.2.1.4. Conﬁguração de acesso de uma account

Existem duas formas de conﬁgurar o acesso de uma account:

• Editar os limites da account: essa é a forma mais básica de conﬁgurar o

acesso de uma account, a qual o administrador do sistema deﬁne limites

de recursos que a mesma pode acessar.

Figura 10: Editando os limites de uma account

• Editar as settings da account: apresenta opções mais avançadas para con-

ﬁgurar o acesso dela.

Figura 11: Editando as conﬁgurações de uma account

2.2.1.5. Desabilitação de account

Essa opção impede os usuários da account de acessar e gerenciar qualquer

recurso, e automaticamente desliga as VMs criadas pelos mesmos. Ela pode

ser reabilitada posteriormente.

Figura 12: Desabilitando uma account

Figura 13: Conﬁrmando a desabilitação da account

2.2.1.6. Bloqueio de account

Opção semelhante à de desabilitar account, no entanto ela apenas impede os

usuários de criar e gerenciar novos recursos. Recursos já existentes não serão

afetados.

Figura 14: Bloqueando uma account

Figura 15: Conﬁrmando o bloqueio da account

2.2.1.7. Restrição de acesso à API por IP

Dentro das conﬁgurações globais, de account ou domain

, pode-se alterar o

parâmetro api.allowed.source.cidr.list para deﬁnir uma lista (separada por vír-

gula) dos únicos endereços IPv4 e IPv6 com permissão para acessar a API do

CloudStack. O valor padrão é 0.0.0.0/0,::/0, permitindo acesso por qualquer IP.

Se houver disparidade entre as conﬁgurações, a de account tem prioridade.

É preciso que a conﬁguração global api.source.cidr.checks.enabled seja true

para utilizar esta função.

Figura 16: Deﬁnindo duas faixas IPv4 e uma IPv6

O ACS utiliza o header X-Forwarded-For da requisição HTTP para identiﬁcar

o IP de origem das requisições à API. Isso permite a auditoria dos processos

realizados pelos usuários e a restrição de IP mencionada nesta seção. Este

header pode ser alterado pelo requisitante, portanto é necessário conﬁgurar

os ﬁrewalls e proxies que intermedeiam a comunicação com o ACS de forma

que isso seja identiﬁcado e o header repassado para o ACS contenha o IP de

origem real do requisitante.

2.2.2. Roles

Roles representam conjuntos de permissões que as contas possuem den-

tro da infraestrutura de nuvem. Além do conjunto de permissões, conforme

apresentado na Seção 2.2.1, roles deﬁnem os tipos das contas, que indicam o

escopo para gerenciamento dos recursos. Os tipos de conta são:

• Admin: possui acesso a todos os recursos do ambiente, incluindo ele-

mentos de infraestrutura e conﬁgurações da plataforma. Essas contas

Se a conﬁguração global enable.account.settings.for.domain for true.

também são chamadas de root admin.

• DomainAdmin: possui acesso a todos os elementos alocados em seu

domínio, incluindo gestão de usuários.

• ResourceAdmin: possui acesso a todos os elementos alocados em seu

domínio, exceto gestão de usuários.

• User: possui acesso somente aos elementos alocados em sua conta.

O CloudStack providencia roles padrões, as quais não podem ser editadas

ou removidas. Contudo, é possível criar roles personalizadas, as quais têm-se

completo acesso. O procedimento para realizar essa ação é o seguinte:

2.2.2.1. Adição de role

1. Navegue até Roles e adicione uma nova role.

Figura 17: Iniciando a criação de uma nova role

2. Adicione a conﬁguração básica da nova role:

Figura 18: Criando a nova role

O campo Based on é obrigatório. Ele pode se referir à tipos ou roles já

existentes. Ele é utilizado para determinar qual o tipo de account que

pode utilizar tal role. Exempo: uma role do tipo Admin apenas pode ser

alocada em accounts do tipo Admin.

Sobre as duas opções disponíveis:

• Type: deﬁne qual será o tipo de account que pode utilizar essa role.

• Role: utiliza uma role já existente para deﬁnir qual será o tipo de ac-

count que pode utilizar essa role e faz uma cópia das regras contidas

na mesma.

2.2.2.2. Visualização de detalhes de role

1. Navegue até os detalhes da role criada.

Figura 19: Acessando a recém-criada role

2.2.2.3. Customização de uma role

1. Customize as regras dessa role.

Figura 20: Customizando as regras da role

Para utilizar essa nova role é necessário criar uma nova account utilizando-a.

2.2.2.4. Remoção de role

1. Também é possível editar e remover roles, exceto por uma situação que

será melhor explicada adiante.

Figura 21: Iniciando a edição de uma role

Figura 22: Editando a role

Figura 23: Removendo uma role

Figura 24: Conﬁrmando a remoção da role

Algumas observações importantes:

• Roles que já estão associadas a uma account não podem ser editadas ou

deletadas, sendo necessário remover a account primeiro.

• Uma única role pode ser utilizada por várias accounts, mas uma account

pode utilizar apenas uma role.

• Apesar de roles associadas a accounts não poderem ser editadas ou dele-

tadas, ainda é possível alterar as regras que compõem essa role, seja as

editando, removendo ou adicionando.

2.2.3. Domains

Agregação de várias accounts, geralmente usado para uniﬁcar accounts com

diferentes roles, mas que fazem parte da mesma organização. Domains per-

mitem isolar e limitar o acesso aos recursos da nuvem para as accounts que o

compõem. A arquitetura padrão do CloudStack já possui um domain padrão,

chamado de ROOT, que é o “pai” de todos os outros domains, além de possuir

acesso total aos recursos da nuvem.

• O Domain ROOT:

O domain ROOT é considerado o domain padrão. Ele não pode ser dele-

tado e nem pode ter seu acesso aos recursos da nuvem reduzidos. Ape-

nas usuários que fazem parte de accounts que utilizam a role root admin

podem ter acesso à esse domain. A partir desse domain são conﬁgurados

os demais.

Figura 25: Acessando a página de domains

2.2.3.1. Adição de domain

• Ao adicionar um novo domain, ele será criado como subdomain (ﬁlho) do

domain atual. No exemplo apresentado, existe apenas um domain. Po-

rém, em organizações mais complexas, onde existem diversos domains,

é necessária atenção na criação da hierarquia.

Figura 26: Criando um novo domain

Figura 27: Deﬁnindo o nome do novo domain

Figura 28: Visualizando o domain criado

Figura 29: Selecionando o domain criado

2.2.3.2. Conﬁguração de domain

• Conﬁgurando o novo domain:

Por padrão, novos domains herdam do parent domain (pai) os privilégios

de acesso aos recursos. Porém, esses acessos podem ser alterados.

Figura 30: Iniciando a edição do novo domain

2.2.3.3. Deﬁnição de acessos do domain

• Deﬁnindo os novos acessos do domain:

Por padrão, o valor -1 indica limites inﬁnitos, ou seja, accounts desse do-

main podem utilizar todos os recursos da nuvem. O valor 0 indica que

elas não podem utilizar aquele recurso. Qualquer valor maior que 0 de-

ﬁne qual o valor máximo que as accounts daquele domain podem utilizar.

Figura 31: Editando o domain

Com o novo domain criado e conﬁgurado, o próximo passo é adicionar ac-

counts ao mesmo. Atualmente, não é possível migrar uma account de um do-

main para outro. Portanto, em estruturas nas quais os domains gerenciam a

nuvem, é necessário criá-los antes de criar as accounts.

2.2.3.4. Reestruturação da árvore de domínios

Para reestruturar a árvore de domínios, pode-se utilizar a API moveDomain

move domain domainid=<id_do_domain> parentdomainid=<id_do_parent_domain_destino>

É importante ressaltar que, para que o domain seja movido, é necessário seguir

as seguintes restrições:

• O domain e o parent domain devem estar ativos.

O parâmetro parentdomainid é opcional. Caso não seja informado, o domain será movido

para o parent domain ROOT.

• O novo parent domain não pode ser um subdomain do domain.

• Não deve existir um domain com o mesmo nome do domain a ser movido

no novo parent domain.

• O novo parent domain deve ter acesso a todos os recursos que o domain

e seus subdomains utilizam (redes shared e aﬃnity groups).

2.2.4. Users

Representa um usuário que faz parte de uma account e tem um username

único dentro do domain. Usuários dentro do mesmo domínio conseguem se

comunicar e ver o que outros usuários estão fazendo, mas não conseguem ter

acesso à usuários que fazem parte de outros domínios. Eles possuem os pri-

vilégios concedidos para a account e atuam dentro de um domínio deﬁnido.

Dependendo da account que o usuário faz parte, o mesmo terá privilégios di-

ferentes dentro do domínio. Por exemplo:

• Usuários sem privilégio de administrador podem apenas utilizar os recur-

sos disponíveis dentro do domínio, respeitando as limitações da account

do qual faz parte e as limitações da role utilizada pela account

• Usuários administradores podem gerenciar os recursos, além de também

poderem gerenciar accounts e usuários dentro do domínio.

É possível adicionar vários users à mesma account, cada um deles possu-

indo um nome e senha próprios. Também é possível editar ou deletar users

já criados. Porém, essas duas operações só são permitidas para um usuário

admin.

2.2.4.1. Adição de user

Os passos para adicionar um novo user são:

1. Vá até Accounts.

Figura 32: Navegando até a página de accounts

2. Selecione em qual account o novo user será adicionado.

Figura 33: Selecione a account que o novo user fará parte

3. Navegue até a página de users dessa account.

Figura 34: Veja os users da account

4. Adicione um novo user.

Figura 35: Adicionando um novo user

Figura 36: Deﬁna os dados do novo user e salve as alterações

2.2.4.2. Edição de user

Para editar um user:

1. Repita os passos 1, 2 e 3 da explicação anterior, mas dessa vez selecione

a account que contém o user que deseja editar.

2. Clique no user que deseja editar.

Figura 37: Selecionando o user para editá-lo

3. Clique em editar o user.

Figura 38: Iniciando a edição

4. Realize as alterações necessárias e salve.

Figura 39: Editando o user

2.2.4.3. Deleção de user

Para deletar um user:

1. Repita todos os passos (2) para chegar até a página de detalhes sobre o

user.

2. Remova o user.

Figura 40: Deletando um user

Figura 41: Conﬁrme a remoção do user

2.2.4.4. Desabilitação/habilitação de user

Também é possível desabilitar um user, impedindo-o de acessar e gerenciar

qualquer recurso.

Figura 42: Desabilitando um user

Para liberar o acesso novamente é necessário que um administrador do

Domain habilite o user desabilitado.

Figura 43: Selecionando o user que deseja reabilitar

Figura 44: Habilitando um user

2.2.4.5. Políticas de senha

A ﬁm de aumentar a segurança dos usuários do ambiente de nuvem, o opera-

dor pode habilitar políticas de senha (regras que a senha deve seguir), que po-

dem ser acessadas nas conﬁgurações globais. Vale ressaltar que essas regras

somente são impostas em senhas de usuários, outras senhas, por exemplo de

VMs, não são afetadas.

Atualmente existem 7 opções de políticas de senhas disponíveis:

• pass word.policy.allowPassw ordToContai nUsername: indica se a senha

pode conter o nome do usuário.

• pa ssword.policy.mi nimum.digits: quantidade mínima de dígitos presen-

tes.

• password.policy.minimum.length: tamanho mínimo.

• password.policy.minimum.lower case.letters: quantidade mínima de le-

tras minúsculas.

• password . p olicy.minimum.special.c h a racters: quantidade mínima de ca-

racteres especiais.

• password.pol icy.minimum.uppercase. letters: quantidade mínima de le-

tras maiúsculas.

• password.policy.regex: expressão regular que a senha deve seguir.

Figura 45: Encontrando as conﬁgurações

Por padrão, não há nenhuma restrição para a criação da senha, todas as

conﬁgurações mencionadas acima são deﬁnidas da forma mais abrangente

possível. Cabe ao operador identiﬁcar se há necessidade de implementar essas

medidas de segurança e conﬁgurar as políticas de senha de acordo.

2.2.4.6. Desabilitação de user por erro de senha

O ACS possui a funcionalidade de desabilitar um user por realizar muitas ten-

tativas incorretas de login. Por padrão, é necessário que o usuário erre a senha

5 vezes seguidas para ser desabilitado. Esse valor pode ser alterado na conﬁ-

guração global incorrect.login.attempts.allowed.

Para habilitá-lo novamente, siga os passos descritos na seção Desabilitar/Ha-

bilitar um user.

Figura 46: Mensagem exibida ao tentar realizar login com user desabilitado

2.2.4.7. Gerência de chaves de API dos users

Chaves de API são credenciais de acesso fornecidas de maneira a autorizar o

uso de funcionalidades especíﬁcas de uma ou mais APIs. Elas muitas vezes

atuam como um identiﬁcador único de autenticação de usuários. No Cloud-

Stack elas podem ser utilizadas para realizar operações e integrações (muitas

vezes de forma automatizada), acessar dados de uso e ferramentas especíﬁcas

do CloudStack para desenvolvimento, testes e integração.

O ACS permite que os usuários gerem suas próprias chaves e que adminis-

tradores criem e atualizem chaves de acesso para os seus usuários. Algumas

das operações possíveis com elas são:

1. registerUserKeys: Esse comando pede como entrada o ID do usuário para

qual será gerada as chaves de acesso, e como retorno apresenta a chave

da API e a chave secreta registrada para o ID informado.

2. getUserKeys: Retorna as chaves registradas para o ID de usuário infor-

mado na entrada.

3. updateUser: Dentro do contexto de chaves de acesso, o comando upd

ateUser permite que as chaves do usuário sejam atualizadas, para isso,

basta informar o ID do usuário e ambos os parâmetros userapikey e use

rsecretkey

Para gerar as chaves pela UI, é preciso editar o usuário para o qual deseja-se

gerá-las. Siga os passos descritos em Editar um user e clique no botão na parte

superior direita conforme a imagem ??.

Figura 47: Gerar chaves de acesso para um usuário

ﬁg:generate-keys

Após clicar no botão será apresentada uma janela solicitando a conﬁrmação

da ação.

Figura 48: Mensagem de conﬁrmação para gerar chaves de acesso

Basta conﬁrmar para que o par de chaves seja gerado e registrado para esse

usuário.

2.2.4.8. Uso das chaves de API no CloudMonkey

Para utilizar as chaves de acesso no CloudMonkey é possível deﬁni-las atuali-

zando diretamente no arquivo de conﬁguração

. Basta preencher os parâme-

tros apikey e secre tkey adequadamente no arquivo e salvá-lo. A próxima vez

que o CloudMonkey iniciar, ele irá utilizar as chaves conﬁguradas.

asyncblock = true

timeout = 1800

output = json

verifycert = true

profile = mylab

[mylab]

url = http://my-local-lab/client/api

domain = /

apikey = IsBXfV_Km9sgbc3zYsf6fiia2z19qCnB80S7quN2lSy0SvD97A

secretkey = crmgT-n820MGl8EYZ37yRvnjDjfQyV8FWHBb5EmFxN5JiqZg1ZHRk6vsNw

Outra forma de utilizar as chaves usando o CloudMonkey é conﬁgurar ma-

nualmente os parâmetros. Para isso, abra o CloudMonkey e execute os coman-

dos a seguir:

(mylab) > set username your-username

(mylab) > set domain your-domain

(mylab) > set apikey YOUR-API-KEY

(mylab) > set url https://your-lab/client/api

(mylab) > set secretkey YOUR-SECRET-KEY

Após ﬁnalizar esses passos execute um comando de sync para veriﬁcar se

as alterações surtiram o efeito desejado.

(mylab) > sync

Discovered 623 APIs

2.2.4.9. Autenticação de dois fatores

O CloudStack tem suporte à autenticação de dois fatores (2FA), na qual o se-

gundo fator utilizado pode ser o Google Authenticator, qualquer autenticador

com suporte ao algoritmo TOTP ou um PIN estático.

Este arquivo normalmente ﬁca na pasta home/.cmk/config ou em

home/snap/cloudmonkey/current/.cmk/config dependendo da forma como foi instalado.

Esta camada extra de segurança pode ser conﬁgurada para um domínio ou

globalmente pelo administrador através das seguintes conﬁgurações:

Conﬁguração Descrição Valor

Padrão

enable.user.2fa Determina se a autenticação de

dois fatores está hablitada.

false

mandate.user.2fa Determina se a autenticação de

dois fatores é obrigatória aos

usuários.

false

user.2fa.default.provider Provedor padrão de autenticação

de dois fatores.

totp

Tabela 1: Conﬁgurações de autenticação de dois fatores

Ao ativar a autenticação de dois fatores, os usuários podem conﬁgurar o

2FA acessando seus perﬁs.

Figura 49: Conﬁgurando a autenticação de dois fatores.

No pop-up, o usuário deve selecionar um dos provedores e realizar a res-

pectiva conﬁguração.

Figura 50: Opções de provedores de autenticação de dois fatores.

Ao escolher o Google Authenticator ou algum outro autenticador com su-

porte ao algoritmo TOTP, é necessário conﬁgurar a conta no respectivo aplica-

tivo escaneando o código QR ou utilizando a chave de conﬁguração fornecida

pelo CloudStack. Após a conﬁguração, o usuário deve fornecer o código gerado

pelo aplicativo para realizar o login.

Figura 51: Conﬁgurando a autenticação de dois fatores com TOTP.

Figura 52: Veriﬁcação com TOTP durante o login.

Ao escolher static PIN, o usuário deve fornecer durante o login o código ge-

rado pelo CloudStack no setup do 2FA.

Figura 53: Conﬁgurando a autenticação de dois fatores com static PIN.

Figura 54: Veriﬁcação com static PIN durante o login.

O usuário pode desativar o 2FA a qualquer momento em seu perﬁl

Figura 55: Desativando a autenticação de dois fatores.

Além disso, o administrador também pode tornar a autenticação de dois

fatores obrigatória através da conﬁguração mandate.user.2fa. Assim, os usuá-

rios deverão conﬁgurar a autenticação no próximo login.

Caso a conﬁguração mandate.user.2fa seja tr ue, o usuário deverá reconﬁgurar a autenti-

cação no próximo login.

Figura 56: Conﬁgurando a autenticação de dois fatores no login.

Caso seja necessário tornar o 2FA obrigatório para apenas um usuário, é

possível utilizar a API updateUser:

(mylab) > update user id=<id_do_usuario> mandate2fa=true

Caso um usuário perca o aplicativo de autenticação ou esqueça o PIN, ele

deverá contatar o administrador do sistema para desabilitar a autenticação de

dois fatores. Ela pode ser desativada acessando o perﬁl do usuário e selecio-

nando a opção Disable User Two Factor Authentication como explicado anterior-

mente.

Caso o próprio administrador perca o segundo fator, ele pode chamar a API

setupUserTwoFactorAuthentication utilizando secretkey e apikey

(mylab) > setup usertwofactorauthentication userid=<id_do_usuario_administrador> enable=false

Caso o administrador não possua secretkey e apikey conﬁguradas, é neces-

sário entrar em contato com o suporte para que a recuperação da conta seja

realizada.

2.2.4.10. Timezone

Ao criar um novo user, é necessário deﬁnir um timezone para o mesmo (vide

seção Adicionar um novo user). Esse parâmetro é responsável pelos horários

Ao utilizar secretkey e apikey, o 2FA é ignorado.

exibidos em diversas páginas da interface do Apache CloudStack, deixando as

informações de acordo com o fuso horário escolhido.

Figura 57: Exemplo de como o timezone afeta a interface do Apache CloudStack

É possível editar o timezone atual do user. Para isso, siga os passos em Editar

um user.

Figura 58: Editando o timezone do user

Por padrão, a interface do Apache CloudStack irá exibir os horários de acordo

com o fuso horário escolhido. Porém, existe a opção de mudar para o fuso ho-

rário local sem precisar editar o user. Para isso, basta ativar a opção "Use local

timezone" conforme ilustra a imagem abaixo:

Figura 59: Ativando a funcionalidade de timezone local

2.2.5. Projects

Projects servem para organizar recursos e agrupar accounts e users. Por pa-

drão, tanto users administradores quanto regulares podem criar um projeto,

sendo o criador automaticamente o administrador do mesmo. É possível al-

terar esse comportamento através da conﬁguração allow.user.cr eate.projec t

Conﬁguração Descrição Valor

Padrão

allow.user.create.projects Deﬁne se um usuário regular

pode criar um projeto.

true

Tabela 2: Conﬁguração de criação de projeto para usuário regular

2.2.5.1. Adição de project

Para criar um project:

Figura 60: Iniciando a criação de um novo project

Ao clicar no botão New Project, será aberto um formulário para preenchi-

mento das informações:

Figura 61: Criando o novo project

Projects possuem limites para alocação de recursos:

Figura 62: Limites de recursos de um project

Esses limites são herdados das conﬁgurações globais:

Conﬁguração Descrição Valor

Padrão

max.project.cpus Número máximo de CPU cores

que o projeto pode usar.

max.project.memory Número máximo de memória

(em MiB) que o projeto pode

usar.

40960

max.project.networks Número máximo de redes que

pode ser criado para o projeto.

max.project.primary.storage Número máximo de primary sto-

rage (em GiB) que o projeto pode

usar.

200

max.project.public.ips Número máximo de IPs que o

projeto pode consumir.

max.project.secondary.storage Número máximo de secondary

storage (em GiB) que o projeto

pode usar.

400

max.project.snapshots Número máximo de snapshots

que pode ser criado para o pro-

jeto.

max.project.templates Número máximo de templates

que pode ser criado para o pro-

jeto.

max.project.user.vms Número máximo de VMs de

usuário que podem ser feitas

deploy para o projeto.

max.project.volumes Número máximo de volumes que

pode ser criado para o projeto.

max.project.vpcs Número máximo de VPCs que

pode ser criado para o projeto.

Tabela 3: Conﬁgurações de limite de recursos em projetos

Porém, eles podem ser alterados em cada project:

Figura 63: Alterando os limites de recursos de um project

Projects também possuem roles, que são um subconjunto das permissões

da role da account. Project roles são em sua natureza restritivas, ou seja, são

usadas para restringir permissões no contexto do projeto e, por isso, não po-

dem ser usadas para conceder novas permissões. Elas possuem prioridade

sobre as roles de uma account. Caso uma account seja adicionada ao project

sem uma project role atribuída, a role da account entrará em vigor.

Por exemplo, se uma account possui a permissão de criar networks, ao ser

adicionada ao projeto sem ser atribuída a uma project role, ela manterá essa

permissão. Agora, se ela puder criar networks, e for adicionada a um projeto

atribuída à uma role que restringe essa permissão, a criação de networks não

será permitida no contexto do projeto.

Figura 64: Iniciando a criação de uma project role

Figura 65: Criando uma project role

Figura 66: Deﬁnindo as regras da project role

2.2.5.2. Interação entre domain admins e admins do projeto com project ro-

les

Apesar da natureza restritiva das project roles, caso a role da account seja do tipo

domain admin, a mesma possuirá acesso a todos os projetos de seu domínio,

independentemente de sua role no projeto.

Assim como, caso a account seja admin do projeto, o usuário possuirá per-

missões equivalentes as da role de sua account, ignorando restrições da project

role.

2.2.5.3. Adição de accounts e users ao project

Para adicionar accounts e users no project, basta preencher o formulário e en-

viar o convite:

Figura 67: Iniciando a adição de membros no project

Figura 68: Adicionando uma account no project

Figura 69: Adicionando um user no project

Ao ﬁnalizar a adição, a account ou o user farão parte do project, no entanto é

possível alterar esse comportamento para que seja necessário eles conﬁrma-

rem o convite, através de um e-mail, antes de participarem efetivamente. Para

isso, existem as seguintes conﬁgurações:

Conﬁguração Descrição Valor

Padrão

project.invite.required Deﬁne se a account ou o user ne-

cessitam aceitar o convite para o

projeto.

false

project.invite.timeout Tempo (em segundos) de expira-

ção do convite.

86400

Tabela 4: Conﬁgurações de convite para projeto

Para que seja possível enviar os e-mails de conﬁrmação, é necessário conﬁ-

gurar o serviço de envio de e-mails para projects:

Conﬁguração Descrição Valor

Padrão

project.email.sender Endereço que estará no header

From do e-mail de conﬁrmação.

null

project.smtp.enabledSecurity

Protocols

Protocolos de segurança para

envio de e-mail, separado por

espaços. Protocolos suporta-

dos: SSLv2Hello; SSLv3; TLSv1;

TLSv1.1; TLSv1.2; TLSv1.3.

project.smtp.host Endereço do servidor SMTP para

envio de e-mails.

null

project.smtp.password Senha para autenticação no ser-

vidor SMTP (apenas se a conﬁ-

guração project.smtp.useAuth es-

tiver como true).

null/false

project.smtp.port Porta que o servidor SMTP está

ouvindo.

465

project.smtp.useAuth Deﬁne se utilizará autenticação

para envio de e-mails.

null

project.smtp.username Usuário para autenticação no

servidor SMTP (apenas se a con-

ﬁguração project.smtp.useAuth

estiver como true)

null

project.smtp.useStartTLS Deﬁne se utilizará StartTLS

para proteger a conexão (ape-

nas se a conﬁguração pro-

ject.smtp.useAuth estiver como

true).

false

Tabela 5: Conﬁgurações de serviço de envio de email

Uma account ou um user podem estar em diversos projetos simultanea-

mente. Para que seja possível consumir e visualizar os recursos do projeto,

é necessário alterar a visualização:

Figura 70: Selecionando a view

Além das funcionalidades citadas, também é possível:

2.2.5.4. Edição de project

• Editar:

Figura 71: Iniciando a edição do project

Figura 72: Editando o project

2.2.5.5. Suspensão de project

• Suspender:

Figura 73: Iniciando a suspensão do project

Figura 74: Suspendendo o project

Se um project possuir recursos ao ser suspenso, eles serão desalocados.

2.2.5.6. Deleção de project

• E excluir:

Figura 75: Iniciando a exclusão do project

Figura 76: Excluíndo o project

Se um project possuir recursos ao ser excluído, eles serão desalocados.

Mais informações na documentação oﬁcial.

2.2.6. Observações e considerações

Há situações onde um usuário possui um domain com diversas accounts,

com roles distintas, que necessitarão compartilhar recursos. De acordo com a

arquitetura utilizada pelo CloudStack, há duas alternativas para que seja pos-

sível compartilhar recursos entre diferentes accounts:

• Através de projects, onde serão adicionadas as accounts e users que com-

partilharão os recursos. É possível também criar diferentes project roles,

limitando o acesso aos recursos compartilhados de cada um.

• Criando uma role para accounts, baseada no tipo DomainAdmin. Essa role

trabalhará no mesmo nível da DomainAdmin padrão, no entanto será pos-

sível limitar o acesso da role DomainAdmin criada através das regras de

acesso.

É importante notar que um projeto apenas pode conter accounts do mesmo

domain onde o projeto foi criado. Não sendo possível accounts de diferentes

domains serem adicionadas a um mesmo projeto.

2.2.7. Conﬁgurações de Contas e Domínios

As conﬁgurações no Apache CloudStack possuem escopo, afetando o com-

portamento da plataforma em diferentes níveis. Escopos indicam que as conﬁ-

gurações pertencentes a eles se aplicam a todos os recursos daquela categoria.

Conﬁgurações do escopo de menor nível sempre prevalecem sobre as conﬁgu-

rações do escopo de maior nível, já as conﬁgurações não deﬁnidas no menor

escopo serão atribuídas ao valor herdado do escopo maior. O ACS disponibi-

liza os seguintes escopos: Global, Zone, Cluster, Domain, Account, Manageme

ntServer, StoragePool e ImageStore.

Escopos indicam que as conﬁgurações pertencentes a eles se aplicam a to-

dos os recursos daquela categoria. Nesse documento, o foco será apenas nos

escopos de Domain e Account. Conﬁgurações do escopo de menor nível sem-

pre prevalecem sobre as conﬁgurações do escopo de maior nível, já as conﬁ-

gurações não deﬁnidas no menor escopo serão atribuídas ao valor herdado do

escopo maior.

Por exemplo, o escopo de Domain abrange o de Account, isso signiﬁca que,

caso seja alterada uma conﬁguração no escopo de Account, isso afetará apenas

a conta atual. Já se a mudança for feita no escopo de Domain, ela afetará todos

os membros desse domínio.

2.3. Gerência de VMs

É possível realizar as seguintes ações com VMs:

2.3.1. Adição de VM

Figura 77: Adicionando uma VM

Para adicionar uma VM, é necessário especiﬁcar algumas conﬁgurações, as

quais variam de acordo com o tipo de conta do usuário. É preciso atentar-se

também na existência de componentes que supram os requisitos de hardware

dessa VM, tanto em questão de CPU e RAM, quanto em questão de redes.

Para a implantação de uma VM baseada em uma ISO, o Apache CloudStack

utilizará o data disk para fazer o boot do OS. Com isso, o data disk será alterado

para root disk posteriormente. Sendo assim, apenas com a VM criada será

possível alocar um data disk de fato, uma vez que o volume inicial se tornará

o root disk para que a implementação do sistema operacional da VM ocorra.

2.3.1.1. Adição de VM como root admin

Figura 78: Conﬁguração de atribuição, infra e template/ISO de VM como root admin

Figura 79: Conﬁguração de compute oﬀering e da disk oﬀering como root admin

Figura 80: Conﬁguração da network, chave SSH e opções avançadas como root admin

Figura 81: Conﬁguração de detalhes da VM como root admin

2.3.1.2. Adição de VM como admin

Figura 82: Conﬁguração de atribuição, zona e template/ISO de VM como admin

Figura 83: Conﬁguração de compute oﬀering e da disk oﬀering como admin

Figura 84: Conﬁguração da network, chave SSH e opções avançadas como admin

Figura 85: Conﬁguração de detalhes da VM como admin

2.3.1.3. Adição de VM como user

Figura 86: Conﬁguração de zona, template/ISO e compute oﬀering de VM como user

Figura 87: Conﬁguração de disk oﬀering e network como user

Figura 88: Conﬁguração de chave SSH e opções avançadas como user

Figura 89: Conﬁguração de detalhes da VM como user

2.3.1.4. Criação de VM com inicialização UEFI

A UEFI (Uniﬁed Extensible Firmware Interface) permite ultrapassar as limitações

impostas pela BIOS. Uma diferença entre as duas formas de inicialização é que

UEFI armazena todos os dados sobre a inicialização em um arquivo .efi e não

no ﬁrmware. Abaixo se encontram algumas vantagens da UEFI em relação a

BIOS:

• Suporta tamanhos de unidade de até 9 zetabytes (Bios até 2,2 terabytes);

• Possui tempo de inicialização menor;

• Oferece segurança com “Secure Boot”, o que evita que a máquina faça boot

a partir de aplicações não autorizadas;

• Roda em 32 ou 64 bits (o que permite a navegação com o mouse), en-

quanto a BIOS utiliza 16 bits (navegação pelo teclado)

O Libvirt convencionalmente utiliza o BIOS como ﬁrmware padrão para a

inicialização de VMs guests. Para que o mesmo inicialize VMs com UEFI, é ne-

cessário instalar os pacotes ovmf no host onde serão implantadas as VMs, que

estão disponíveis na maioria dos repositórios Linux. Veriﬁque a existência do

pacote no host com o seguinte comando: dpkg -s ovmf. Caso o pacote não

exista, siga:

• 1. Para os sistemas baseados em Debian execute:

sudo apt install ovmf

• 2. Para sistemas baseados em RHEL, é necessário instalar o pacote edk2

-ovmf usando os seguintes comandos:

sudo dnf install edk2-ovmf

sudo yum install edk2-ovmf

• 3. Já para sistemas baseados em Arch Linux:

sudo pacman -S edk2-ovmf

Para o segundo passo é necessário que se empregue na VM um template

que suporte a inicialização UEFI.

Para a implementação da VM, certiﬁque-se de que o Cloudstack considera

apenas os hosts habilitados para UEFI, conforme registrado no banco de dados,

para alocação. Conﬁgure a máquina virtual conforme necessário, ajustando as

deﬁnições XML no caso de uso do KVM, para garantir a compatibilidade com

UEFI.

Figura 90: Visualização das opções de inicialização

Figura 91: Opções de inicialização no formulário de deploy de uma VM

Durante a criação de VMs, é possível observar os detalhes das conﬁgurações

ﬁnais da VM antes de criá-la:

Figura 92: Conﬁguração ﬁnal da VM

2.3.2. Remoção de VM

É possível realizar a remoção de uma VM através do CloudMonkey ou atra-

vés da UI. Ao realizar tal procedimento, deve-se atentar ao parâmetro expun

ge. Por padrão, ele possui o valor false, o que permite a recuperação da VM

excluída por parte do administrador. Caso ele receba o valor true, a VM é com-

pletamente removida e não poderá ser recuperada posteriormente.

Através da API, é possível usar o comando destroyVirtualMachine para colo-

car uma VM no estado Destroyed, marcando-a para exclusão deﬁnitiva após o

período deﬁnido pela conﬁguração global expunge.delay. O CloudStack realiza

veriﬁcações de expurgação de acordo com o intervalo deﬁnido na conﬁgura-

ção global expunge.interval. A API pode ser auxiliada pelo parâmetro expung

e. Vale ressaltar que contas com roles do tipo Admin sempre poderão informar

tal parâmetro; contas que possuem outra role terão acesso apenas caso a con-

ﬁguração allow.user.expunge.recover.vm (ao nível de conta) estiver como tru

(localcloud) > destroy virtualmachine id=<id da VM escolhida> expunge=<False or True>

Existe também a API expungeVirtualMachine, que pode ser executado para

remover deﬁnitivamente VMs que se encontram nos estados de Destroyed, Ex

punging ou Error.

(localcloud) > expunge virtualmachine id=<id da VM escolhida>

Ambos os processos podem ser realizados via UI, como mostrado a seguir:

Figura 93: Escolhendo a VM que será destruída

Figura 94: Conﬁrmando a destruição da VM

2.3.3. Parada e início de VM

Figura 95: Parando e iniciando uma VM

2.3.4. Reinício de VM

Para reiniciar uma VM, a mesma deve, obrigatoriamente, estar rodando.

Figura 96: Escolhendo a VM que será reiniciada

Figura 97: Reiniciando a VM

2.3.5. Acesso à VM via interface web

Atualmente, o ACS permite o acesso ao console de VM pelo navegador. Para

isso, existe um botão na UI que fornece este acesso em uma nova guia. Entre-

tanto, há um mecanismo que, por razões de segurança, restringe o acesso ao

console a um uso por vez. Assim, se o console estiver em uso, outro console da

mesma VM não pode ser aberto, apresentando a mensagem de erro: Failed to

connect to server / access t oken has expired. Para ﬁns de compartilhamento

e/ou acesso posterior ao console de VM, existe um botão ao lado que copia a

URL do console diretamente para a área de transferência.

Figura 98: Botões de acesso e cópia de URL do console da VM

Via CloudMonkey, o acesso ao console da VM é possível através do uso da

API createConsoleEndpoint, onde o parâmetro que deve ser passado é o ID da

VM, e, como retorno, apresenta a URL de acesso ao console pelo navegador.

Para obter acesso à URL via CloudMonkey, deve-se executar o comando a

seguir:

$ create consoleendpoint virtualmachineid=<id-da-VM>

Figura 99: Resposta da API createConsoleEndpoint

2.3.6. Aumento de recursos computacionais da VM

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 conﬁgurada como dynamically scalable;

• A compute oﬀering type da VM em questão precisa ser do tipo custom cons-

trained ou custom unconstrained;

• O sistema operacional da VM deve suportar dynamic scale dos recursos;

• 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;

• Não é possível diminuir os recursos da VM, apenas aumentar;

É preciso que conﬁguração global enable.dynamic.scale.vm, cujo valor pa-

drão é false, seja true.

Para conﬁgurar as VMs desejadas, é necessário que elas estejam paradas.

As deﬁnições necessárias para o dynamic scalling no KVM apenas são informa-

das no Document Object Model (DOM) no deploy da VM. Assim, não é possível

alterar essas deﬁnições com a VM em execução.

VMs já existentes que estão paradas podem ser conﬁguradas como dyna-

mically scalable:

Figura 100: Ativando dynamic scaling em uma VM

Também é possível conﬁgurar templates para que VMs criadas com eles se-

jam dynamically scalable desde o momento de sua criação:

Figura 101: Conﬁgurando dynamic scaling em um template

Finalmente, para aumentar os recursos computacionais de uma VM, basta

invocar o seguinte comando da API através do CloudMonkey:

scale virtualmachine id=<ID DA VM> serviceofferingid=<ID DA COMPUTE OFFERING>

details[0].memory=<NOVO VALOR DE MEMORIA> details[0].cpuNumber=<NOVO NUMERO

DE CPUS> details[0].cpuSpeed=<NOVA VELOCIDADE>

Por exemplo:

scale virtualmachine id=13661a05-6640-48d3-938f-2ba054356d0b

serviceofferingid=daa3225c-caa8-4a37-a534-cf53635aaaf9 details[0].memory=512

details[0].cpuNumber=2 details[0].cpuSpeed=1000

Alguns detalhes importantes na hora de executar o comando:

• Na API, os valores de memória (details[0].memory) e número de CPUs (d

etails[0].cpuNumber) são obrigatórios na API. Caso não se deseje alterar

a memória, basta informar o valor corrente e vice-versa;

• O valor de memória (details[0].memory) informado na API deve ser o valor

atual + algum número múltiplo de 128.

• No caso da VM possuir uma compute oﬀering do tipo custom unconstrained,

o valor de velocidade de CPU (details[0].cpuSpeed) também é obrigatório;

Dependendo do sistema operacional usado na VM, pode ser necessário ativar

as CPUs ou a RAM para que elas comecem a serem utilizadas. No Ubuntu, é

possível ativar a CPU da seguinte maneira:

1. Torne-se usuário root:

sudo su

2. Ative a CPU com o seguinte comando, mudando o número da CPU para

o desejado:

echo 1 > /sys/devices/system/cpu/cpu<NUMERO DA CPU>/online

3. Repita para as outras CPUs a serem ativadas.

No CentOS e no RHEL o seguinte procedimento é utilizado para ativar RAM:

1. Use este comando para checar se existe RAM desativada:

grep line /sys/devices/system/memory/*/state

2. Caso exista RAM desativada, ative-a com o comando;

echo online >/sys/devices/system/memory/memory[number]/state

Caso o usuário preﬁra, é possível aumentar os recursos computacionais da

VM via UI do CloudStack também, conforme explicado na seção 2.18.2.4 (Alte-

ração de compute oﬀering da VM).

2.3.7. Atribuição de VM a outra account

Por meio de usuários root admin ou domain admin é possível atribuir uma

VM de uma account para outra. Usuários root adm in poderão atribuir VMs

para accounts em qualquer domain, já usuários domain admin poderão apenas

atribuir VMs a accounts do mesmo domain e seus subdomains.

Para exempliﬁcar, considere a seguinte estrutura de domínios:

ROOT

-> domain1

-> subdomain1

-> subdomain2

-> domain2

-> subdomain1

Um usuário domain admin do domain1 poderá reatribuir VMs de/para ac-

counts nos domains R OOT/domain1, ROOT/domain1/subdom ain1 e RO OT/do

main1/subdomain2. No entanto, não poderá reatribuir VMs de/para accounts

no domain ROOT/domain2 e seus subdomains.

Além disso, este processo possui alguns pontos importantes:

• A VM precisa estar parada;

• A VM não pode ter snapshots;

• A account para a qual a VM está sendo migrada precisa ter acesso às re-

des que a VM utiliza. Neste sentido, é importante considerar que não é

possível migrar uma network entre accounts;

• Caso o NIC padrão esteja conectado a uma rede isolada, e a nova account

possua mais de uma rede isolada, será necessário especiﬁcar a rede;

• Os IPs da VM não podem ter regras de Port Forwarding/Load Balancing ou

serem Static Nat.

Figura 102: Escolhendo a VM que terá sua account migrada

Figura 103: Migrando account da VM

Também é possível fazer este processo usando o CloudMonkey, descrito na

seção 3, através do seguinte comando:

(localcloud) > assign virtualmachine virtualmachineid=<vm-id> domainid=<domain-id>

account=<account-name>

2.3.8. Adição de user data script na VM

O user data script é um script que executa no boot da VM, podendo ser adi-

cionado durante a criação da VM e também após, atualizando a deﬁnição da

mesma. Sua atribuição pode ser feita de duas formas, pelo CloudMonkey e

pela UI.

Pelo CloudMonkey, o script deve ser atribuído em formato de codiﬁcação

base64 (devido ao desenho do CloudMonkey, o base64 pode ter até 32768 ca-

racteres, ou, 32KB de tamanho), com o parâmetro userdata= e o script codiﬁ-

cado em seguida.

Exemplo de atribuição de user data script via CloudMonkey:

(localcloud) > deploy/update virtualmachine [...] userdata=IyEvYmluL2Jhc2gKCmVjaG8gInVzZXJkYXR

hIHRlc3QgLSAkKGRhdGUpIiA+IC90bXAvdXNlcmRhdGE=

Script acima decodiﬁcado:

#!/bin/bash

echo "userdata test - $(date)" > /tmp/userdata

Note que [...] foi usado apenas para melhor visualização do parâmetro user

data script, excluindo os outros parâmetros obrigatórios.

A API updateVirtualMachine utilizada no exemplo acima, além de alterar as

conﬁgurações de boot, também pode ser usada para alterar outras conﬁgura-

ções, como os valores de memória, número de CPUs e a velocidade da CPU.

Assim, para evitar que outras conﬁgurações possam ser alteradas pelos usuá-

rios ﬁnais, é necessário adicionar alguns valores na conﬁguração global user.v

m.denied.details.

Esses valores são os nomes das conﬁgurações separados por vírgula. Por

exemplo, para bloquear o usuário de alterar as conﬁgurações de memória e

CPU, a conﬁguração deverá ter o seguinte valor: cpuNumber, cpuSpeed, mem

ory. É importante ressaltar que essa conﬁguração tem como valor padrão: ro

otdisksize, cpuOvercommitRat i o , memor y O v e r c o m m it R a t i o , Mess a g e . Re s e r v e

dCapacityFreed.Flag.

Pela UI, o user data script pode ser adicionado de forma manual, pelo campo

de texto disponível na aba Manual Userdata Entry, ou selecionando um script

já conﬁgurado, disponível na aba Stored Userdata. Quando adicionado por

um campo de texto, a codiﬁcação não é necessária, pois o próprio CloudStack

codiﬁca ao enviar o script para o back-end.

Caso seja adicionado como stored user data, o limite aplicado é de 3069 ca-

racteres, que após a conversão atinge 4092 caracteres. Para a criação, são

necessários os seguintes passos:

Figura 104: Criando um stored user data

100

O seguinte formulário aparecerá:

Figura 105: Formulário de criação de stored user data

Os seguintes campos devem ser preenchidos:

• Name: Nome do seu user data script.

• Userdata: O conteúdo do seu user data script, contendo variáveis ou co-

mandos.

• Userdata parameters: Lista das variáveis criadas no conteúdo, separada

por vírgula. São necessárias apenas aquelas criadas pelo usuário.

• Domain: Opcional. Informa para qual domínio o user data script estará

disponível.

• Account: Opcional. Caso um domínio seja escolhido, pode-se escolher

uma Account para atribuir o user data script.

Após a criação, é possível acessar os detalhes da seguinte forma:

101

Figura 106: Selecionando o user data script para ver detalhes

Figura 107: Detalhes do user data script

No momento, não é possível editar um stored user data criado, sendo ne-

cessário a exclusão do atual e criação de um novo. Um script não pode ser

excluído enquanto houverem VMs que o implementam, sendo necessário rea-

lizar a parada da VM e remoção do user data ao selecionar a opção No thanks

na funcionalidade Reset Userdata on Instance da VM.

Apesar de não ser possível editar um stored user data em si, é possível editar

uma VM que o implemente, possibilitando a edição do user data script daquela

VM. Isso não aplica nenhuma mudança às demais VMs que também o imple-

mentem e nem ao script. Além disso, VMs que implementaram um stored user

data que posteriormente foi editado ainda contam como usuárias do user data

script, impossibilitando sua exclusão.

Para atribuir um stored user data na criação da VM, deve-se seguir esses

passos:

102

Figura 108: Adicionando a stored user data à uma VM

Se a opção desejada for a Manual Userdata Entry, o limite aplicado é de

24576 caracteres (24KB de tamanho), que após conversão atinge 32768 ca-

racteres (32KB de tamanho), tamanho máximo suportado pelo CloudStack. A

adição pode ser feita seguindo os passos 1 e 2 do exemplo anterior, e depois

preenchendo com o conteúdo, como no exemplo abaixo:

Figura 109: Adicionando user data script na criação da VM

Caso seja necessária a edição do user data script, essa pode ser realizada da

seguinte forma:

103

Figura 110: Alterando user data script na edição da VM

Com o user data script adicionado, pode-se veriﬁcar sua funcionalidade como

mostra o screenshot a seguir:

Figura 111: Veriﬁcando funcionalidade do user data script

2.3.9. Conﬁgurações da VM

Para editar as conﬁgurações de uma VM, é necessário primeiramente parar

a mesma. Em seguida, as conﬁgurações da VM podem ser modiﬁcadas aces-

sando a aba Settings.

104

Figura 112: Aba de conﬁgurações da VM

2.3.9.1. Conﬁgurações gerais

Conﬁguração Descrição.

keyboard Deﬁne o layout do teclado da VM.

cpu.corespersocket Deﬁne o número de núcleos de CPU por soquete.

nicAdapter Deﬁne o adaptador de rede virtual usado pela VM.

Tabela 6: Conﬁgurações gerais de VM

2.3.9.2. Conﬁgurações para VM com compute oﬀering personalizada

Conﬁguração Descrição

cpuNumber Número de núcleos de CPU atribuídos à VM.

cpuSpeed Velocidade do clock do processador atribuída à VM.

memory Quantidade de memória RAM atribuída à VM.

Tabela 7: Conﬁgurações para VM com compute oﬀering personalizada

105

2.3.9.3. Conﬁgurações diversas para uso interno

Conﬁguração Descrição

deployvm Ação para implantar uma nova VM.

SSH.PublicKey Chave pública SSH usada para autenticar o acesso à

VM.

password Senha usada para autenticar o acesso à VM.

Encrypted.Password Senha criptografada usada para autenticar o acesso à

VM.

conﬁgDriveLocation O local onde a unidade de conﬁguração da VM será

montada.

Tabela 8: Conﬁgurações de VM para uso interno

2.3.9.4. Conﬁgurações para importação de VM com NIC, disco e parâme-

tros personalizados para compute oﬀering personalizada

Conﬁguração Descrição

nic Adaptador de rede virtual usado pela VM.

network Rede virtual usada pela VM.

ip4Address Endereço IPv4 atribuído à VM.

ip6Address Endereço IPv6 atribuído à VM.

disk Disco virtual usado pela VM.

diskOﬀering Oferta de disco virtual usada pela VM.

conﬁgurationId ID de conﬁguração usada para implantar uma VM existente

em uma nova máquina host.

Tabela 9: Conﬁgurações de VM com NIC, disco e paramêtros personalizados para compute

oﬀering personalizada

2.3.9.5. Adicionar conﬁgurações da VM via API

Nem todas as conﬁgurações de VMs estão acessíveis por meio da UI. Contudo,

é possível efetuar modiﬁcações e adições por meio da API updateVirtualMachi

ne, como mostrado a seguir:

update virtualmachine id=<ID-da-VM> details[0].<propriedade1>=<valor1>

details[0].<propriedade2>=<valor2> <demais parametros>

Ao executar o comando updateVirtualMachine para atualizar as conﬁgura-

ções da VM, apenas as conﬁgurações passadas através do comando serão atri-

106

buídas à VM. As conﬁgurações existentes serão removidas caso não estejam

presentes no mesmo.

(admin) > update virtualmachine id=565f5741-315e-47ea-816b-3f4d98b49553

details[0].keyboard=us details[0].cpu.corespersocket=1

details[0].Message.ReservedCapacityFreed.Flag=true details[0].video.hardware=vga

details[0].io.policy=threads details[0].iothreads=enabled

É possível inserir conﬁgurações com um nome incorreto ou inexistente, mas

tais conﬁgurações não afetam o funcionamento da VM, pois são ignoradas. No

entanto, elas permanecem visíveis na aba de conﬁgurações da VM.

2.3.10. Limite no consumo de rede para NICs de VMs de usuário

A aplicação da limitação do consumo de rede guest para VMs de usuário

difere entre a NIC padrão e as demais NICs. Quando for aplicada ao consumo

da NIC padrão, o ACS utilizará o limite especiﬁcado na oferta de computação da

VM. Caso o limite não tenha sido especiﬁcado na oferta, o ACS utilizará o valor

deﬁnido na conﬁguração global vm.network.throttling.rate. Para as demais

NICs, o limite de consumo será deﬁnido pelo valor especiﬁcado na oferta de

rede de sua respectiva rede guest. Novamente, caso o limite não tenha sido

especiﬁcado na oferta, o ACS utilizará o valor deﬁnido na conﬁguração global

network.throttling.rate.

2.4. Gerência de volumes

Existem dois tipos de volumes que são utilizados pelas VMs:

• Root Disk: O disco que abriga o "núcleo" ou a "base" do sistema operaci-

onal de uma máquina virtual é conhecido como "root disk". Em sistemas

operacionais do tipo Unix, essa partição é geralmente designada como "/".

Cada máquina virtual contém um único root disk, não sendo possível que

VM contenha dois ou mais discos desse tipo.

• Data Disk: Refere-se a uma unidade de disco de dados que expande a ca-

pacidade de armazenamento disponível para uma máquina virtual. Uma

VM pode conter diversos data disks anexados; contudo, o número má-

ximo varia por hypervisor.

107

A diferença entre os dois tipos é a posição deles na VM. Um volume que está

marcado como Root Disk pode tornar-se um Data disk e vice-versa.

Além dos diferentes tipos de volumes, os mesmos podem se encontrar nos

seguintes estados:

• Ready: Volumes neste estado já existem no primary storage, podendo es-

tar tanto desvinculados e prontos para serem direcionados a uma VM,

quanto já sendo utilizados por uma VM, sendo possível veriﬁcar a por-

centagem de utilização de sua capacidade.

• Allocated: Representa que o volume ainda não existe ﬁsicamente, porém

os metadados do volume já estão armazenados no CloudStack.

• Uploade d: Ao fazer o upload do volume, ele ﬁca armazenado no secon-

dary storage. Ele apenas será copiado para o primary storage quando for

vinculado a uma VM. Neste estado, o volume pode somente ser anexado

a uma VM como um DATADISK

• Migr ating: Estado transicional que indica que o volume está migrando

entre storages.

• Destroy: O volume neste estado ainda pode ser recuperado ou deletado

deﬁnitivamente; neste estado o volume não pode ser vinculado a uma

VM.

• Expunging: Estado transicional que indica que o volume já passou do es-

tado Destroy, mas ainda está em processo de exclusão permanente.

Discos gerados por um hypervisor, como o KVM, não são compatíveis com

outros hypervisors devido à criação e ao reconhecimento de formatos de disco

especíﬁcos por parte de cada um deles.

Para maiores informações, consulte a seção 2.4.1.6

108

2.4.1. Operações em data e root disks

Nesta subseção são apresentadas algumas operações em root e data disks.

A seção 2.18.1 possui mais detalhes quanto às operações com root disks.

2.4.1.1. Vizualização de discos e volumes

Figura 113: Visualizar todos os volumes

2.4.1.2. Criação de volume

Figura 114: Criar novo volume

109

Figura 115: Conﬁgurar novo volume

Figura 116: Veriﬁcando novo volume

Todos os volumes criados serão do tipo Data Disks.

2.4.1.3. Upload de volume local

Figura 117: Upload de volume local

110

Figura 118: Realizar upload

Para realizar o upload de um volume, a disk oﬀering 2.18.1 deve ser do tipo

custom disk, visto que, durante o upload, o tamanho do disco é desconhecido.

2.4.1.4. Upload de volume local usando cURL

Utilizando CloudMonkey e cURL via terminal, também é possível realizar upload

de volumes locais. Para isso, deve-se reproduzir os seguintes passos:

111

1. No CloudMonkey, utilize o seguinte comando

para obter os parâmetros

que serão utilizados para o próximo passo:

get uploadparamsforvolume format=<Formato_do-volume> name=<nome> zoneid=<UUID_da_zona>

Um exemplo de saída do comando:

{

"getuploadparams": {

"expires": "2022-02-07T15:43:12.591Z",

"id": "41af6492-8695-4b08-b04b-170edfd4f092",

"metadata": "XsUP46nagJgEdN0ZVLHEBMFxJysHre6RtCtGh7+/4/nrK3LvslGsct44QcjIH0sheCig

N9NTn/MElyuv8uxx3V8cA1pc/3KFFZAv9Ycn3XWXBKdUQsKfYe3h/NLnzPv4klpPU35o4h8qjTi+BTTPT

hotakSWWVZybe0gcYKXZGVOHeZOLqL3PMsGC+TumrSFcvW79smfytdMAebNG2nhekVmf8Lwbqdhn0G9Cl

0Szv4NAl4ZIJValMBz+qL84Z/GDEw/V1Nq1EYVqQpoyftlA9ZkhPiitLGeQgJ7UzyHaoMG3vCu0EQgBDe

IgyoJdVRpkw23BR35WTvK2HSIijjOkm/fQJJbMzwBAdLRN1wW+4bPhzLQfc+Jf/ruVk1BDEA3RRDQLp5o

VDfqveV/fj6fpnkjUmyJJ3trDlitb5i/ZnqPGt+2VeJu/UJzNUtDorV/9KVUVf7SEHTL9B154ds1RNAiK

CLM3mfo",

"postURL": "https://172.16.200.99/upload/41af6492-8695-4b08-b04b-170edfd4f092",

"signature": "A8ElmOHx3gAC5xA43b0Kwa97qac="

}

2. Via terminal, utilize o comando curl para realizar o upload do volume:

curl -X POST "<postURL>" -H "X-signature:<signature>" -H "X-metadata:<metadata>" \

-H "X-expires:<expires>" -H "Expect:" \

-F "file=@<caminho_do_arquivo_a_ser_feito_upload>" -v --insecure

É importante notar que o header Ex pect deve estar vazio, caso contrário o

cURL esperará por um sinal da SSVM para fazer o upload, ocasionando em um

timeout, já que a SSVM não implementa esta função.

A operação de geração de um template utilizando um volume está descrita

na página 193.

São apenas apresentados os parâmetros obrigatórios. Existem outros que permitem con-

trolar melhor como o volume será criado. Por exemplo, o parâmetro account permite designar

o volume a uma conta (neste caso, o domainid também deve ser informado).

112

2.4.1.5. Upload de volume on-line via URL

Figura 119: Fazendo upload de volume

Figura 120: Conﬁgurando o upload de volume

113

2.4.1.6. Adição de volume a uma VM

Figura 121: Acessando os detalhes do volume

Figura 122: Adicionando o volume à VM

114

Figura 123: Conﬁgurando a VM que receberá o novo volume

2.4.1.7. Remoção de volume de uma VM

Figura 124: Removendo o volume da VM

Figura 125: Conﬁrmando a ação

2.4.1.8. Remoção e adição de volume ROOT

Via CLI, é possível fazer tanto a remoção quanto a adição de volumes ROOT,

desde que a VM esteja parada. Para fazer a remoção do volume, utilize o se-

guinte comando:

115

detach volume id=<id_do_volume>

Já para fazer adição do volume como ROOT, use o seguinte comando, deﬁ-

nindo o deviceid dele como 0:

attach volume id=<id_do_volume> virtualmachineid=<id_da_VM> deviceid=0

O dev iceid deﬁne qual a posição do volume na lista de devices. O volume

ROOT sempre tem a posição 0. Caso queira adicionar um volume que não seja

ROOT, pode-se omitir o parâmetro ou escolher um outro número. A quantidade

máxima de volumes que são suportados depende do hypervisor adotado:

Hypervisor Número de volumes

KVM 32

VMWare 13

XenServer 6

Tabela 10: Quantidade máxima de volumes suportados por hypervisor

2.4.1.9. Redimensionamento de volume data disk

Essa opção só é disponível para volumes criados pelo usuário, não estando

disponível para os que foram criados via upload.

Figura 126: Redimensionar o volume

116

Figura 127: Conﬁgurar redimensionamento

2.4.1.10. Download de volume

É importante notar que o download de volumes ROOT é possível somente se a

VM estiver parada.

Figura 128: Fazer download do volume

Figura 129: Conﬁrmar download

117

2.4.1.11. Snapshots recorrentes

Automatiza o processo de criação de snapshot de um volume. Na seção 2.15,

podem ser encontradas mais informações sobre as funcionalidades e utilida-

des de snapshots.

Figura 130: Adicionando automatização de snapshots para um volume

Figura 131: Conﬁgurando a automatização das snapshots

118

2.4.1.12. Deleção de volume

Figura 132: Removendo o volume

Figura 133: Conﬁrmar a ação

2.5. Redes guest

Redes guest são responsáveis pela comunicação interna das VMs, seja en-

tre si mesmas ou com seus respectivos gateways. Existem três tipos de rede,

cada um possibilitando diferentes serviços de acordo com as ofertas de rede

disponíveis; mais informações sobre as ofertas em 2.18.3).

2.5.1. Rede isolada

Também chamada de isolated, ela encapsula a comunicação e permite o

tráfego privado somente entre as VMs integrantes, utilizando um Virtual Router

(VR) para gerência da rede e como gateway do tráfego público. A conﬁguração

119

da rede isolada se dá através das suas Egress rules e das funcionalidades dos

seus IPs públicos. Mais informações sobre IPs públicos em 2.6.

Figura 134: Rede isolada

Figura 135: Rede isolada criada

120

2.5.1.1. Egress rules

As regras de saída da rede isolada podem ser conﬁguradas na aba Egress rules,

encontrada nos detalhes da rede.

Figura 136: Conﬁgurando as egress rules

• Source CIDR: Faixa de endereços da rede local a receber permissão de

acesso.

• Destination CIDR: Faixa de endereços externos à rede local que poderão

ser acessados.

• Protocol: TCP, UDP, ICMP ou todos

• Start port e End port: Primeira e última das portas a serem acessadas.

2.5.2. Network permissions

2.5.3. Rede compartilhada

Também chamada de shared, ela apresenta diferentes graus de visibilidade.

Normalmente, redes compartilhadas também possuem um VR dedicado, mas

ele não gerencia o tráfego público e não contém IPs públicos. Dessa forma,

costuma ser utilizada para reunir: diferentes redes isoladas; VMs de diferentes

contas; e/ou utilizar um gateway externo como a rede L2, sem abrir mão das

funcionalidades de DHCP estático e cloud-init.

121

A rede compartilhada possui o conceito de escopo, que pode ser receber

um dos seguintes valores, dependendo das permissões disponíveis ao dono

da rede:

• Account: visível apenas aos usuários de uma determinada conta, da mesma

maneira que a rede isolada;

• Domain: visível a todas as contas do domínio especiﬁcado, podendo-se

também optar se deveria também ser visível aos subdomínios;

• Project: embora presente na UI, atualmente não é possível criar uma rede

compartilhada por projeto;

• All: todos os usuários da nuvem têm acesso a redes criada com este es-

copo.

122

Figura 137: Criando rede shared - Parte 1

123

Figura 138: Criando rede shared - Parte 2

124

Figura 139: Rede shared criada

2.5.4. Rede L2

Permite que os serviços de rede sejam fornecidos e gerenciados por equi-

pamentos externos ao CloudStack. Como resultado, não utiliza Virtual Routers e

as VMs implantadas com esse tipo de rede obterão seus endereços IP e outros

serviços a partir de equipamentos externos.

Figura 140: Criando uma rede L2

125

Figura 141: Rede L2 criada

2.5.5. Operações com redes guest

Algumas das operações possíveis são:

2.5.5.1. Adicionar rede guest

Figura 142: Navegando até a rede guest

126

2.5.5.2. Acesso aos detalhes de uma rede guest

Figura 143: Acessando os detalhes de uma rede guest

2.5.5.3. Exclusão de rede

Só é possível se a rede não possuir VMs. Após retirar as VMs da rede, basta

navegar até os detalhes da rede que deseja excluir.

Figura 144: Excluindo uma rede

Figura 145: Conﬁrmando a exclusão da rede

127

2.5.5.4. Edição de rede

Figura 146: Editando uma rede

2.5.5.5. Reinicialização de rede

Essa opção só existe para redes do tipo isolated e shared.

Figura 147: Reiniciando uma rede

2.5.5.6. Network permissions

Por padrão, redes isoladas ou L2 são acessíveis somente pela conta dona da

rede. No entanto, é possível conceder a permissão de acesso a outras contas

e projetos dentro do mesmo domínio, através das network permissions.

Para demonstração, foram criados um domínio chamado client, duas con-

tas, client e client-users, e uma rede client-network.

• Ao acessar a aba Guest networks com a conta client-users, nenhuma rede

aparecerá.

Para permitir que a conta tenha acesso à essa rede, será necessário criar

uma nova network permission na rede client-network e adicionar a conta client

-users.

128

• Acesse o menu Guest networks, selecione a rede e clique em Add netwo

rk permissions

Figura 148: Acessando a rede client-network.

• Em seguida, adicione uma conta na network permission

Figura 149: Adicionando uma conta em Add network permission.

• Após ter adicionado a conta, a rede estará visível.

129

Figura 150: Após adição da network permission.

2.6. IPs públicos

As possíveis operações utilizando IPs públicos podem ser acessadas ao en-

trar nos detalhes do IP público desejado:

Figura 151: Acessando o IP público

130

Figura 152: Vendo os detalhes do IP público

2.6.1. Operações com IPS públicos

2.6.1.1. Conﬁguração de ﬁrewall

Um IP público vinculado a uma rede guest pode ter o ﬁrewall conﬁgurado para

receber comunicações.

Figura 153: Conﬁgurando o ﬁrewall

• Source CIDR: Faixa de endereços externos à rede local a receber permissão

de acesso.

131

• Protocol: TCP, UDP ou ICMP

• Start port e End port: Primeira e última das portas a serem abertas para a

faixa de endereços do source CIDR.

2.6.1.2. Habilitação de static NAT

Ao habilitar o Static NAT, é possível reservar o IP público para uma VM.

Figura 154: Habilitando static NAT

Figura 155: Conﬁgurando o IP

132

Figura 156: Veriﬁcando a conﬁguração ﬁnal

Com isso, a VM escolhida se torna visível e acessível na rede externa.

2.6.1.3. Habilitação de port forwarding

Ao habilitar o mapeamento de portas é possível alocar portas especíﬁcas para

o IP público que “redirecionam” o tráfego para uma outra porta de determinada

VM.

133

Figura 157: Acessando e conﬁgurando as portas da aba de port forwarding

Figura 158: Escolhendo a VM que terá a porta mapeada

Figura 159: Exemplo de conﬁguração de port forwarding com várias VMs

A grande vantagem do uso de port forwarding é tornar várias VMs acessíveis

a rede externa através de apenas um único IP, além de permitir um controle

134

de quais portas da VM podem ser acessíveis na rede externa.

2.6.1.4. Habilitação de load balancing

Ao habilitar essa opção, é possível realizar a operação de balanceamento de

carga entre diversas VMs através de apenas um IP público e de acordo com as

regras deﬁnidas pelo usuário.

Figura 160: Acessando e conﬁgurando as portas do load balancing

Figura 161: Adicionando as VMs que serão gerenciadas pelo load balancer

135

Figura 162: Load balancer criado

Uma vez que o load balancer esteja criado, é possível adicionar regras mais

complexas ao mesmo.

É importante frisar que todas as operações aqui apresentadas podem ser

facilmente desfeitas simplesmente removendo as conﬁgurações adicionadas

ao IP público ou ainda removendo o próprio IP público.

Figura 163: Removendo o IP público

2.6.2. Aquisição de IP público

Para poder realizar as operações com os IPs públicos em uma rede, é ne-

cessário que seja alocado um IP público para essa rede. Por padrão, redes

gerenciadas pelo ACS possuem pelo menos um IP, chamado Source NAT, que

não pode ser removido.

Redes guest com conserve mode igual a false na sua network oﬀering (seção

2.18.3) e tiers de uma VPC não suportam mais de um serviço no mesmo IP

público. Só podem ter uma função dentre Source Nat, Static Nat, Port Forwarding

e Load Balancing.

136

Dessa forma, o procedimento para adquirir um novo IP público em uma

rede é:

1. Navegar até a rede desejada:

Figura 164: Acessando os detalhes da rede

2. Navegar até a aba de IPs públicos:

Figura 165: Acesse os IPs públicos da rede

3. Adquirir um novo IP público para a rede:

Figura 166: Adquirir um novo IP

137

Figura 167: Lista de IPs disponíveis

Figura 168: Novo IP adquirido

Aqui é importante frisar que os IPs públicos disponíveis dependem de três

fatores:

(a) Faixa de IPs públicos alocada durante a criação da Zona no ACS;

138

(b) Quantidade de IPs públicos ainda disponíveis

uma faixa de IPs dedicados, além de a conﬁguração global use.syste

m.public.ips estar como true.

2.6.3. Quarentena de IPs públicos

No ACS, quando um IP público é liberado (via UI ou API disassociateIpAddr

ess) por um usuário, este pode ser alocado (via UI ou API associateIpAddress)

por qualquer outro usuário na nuvem. É possível restringir a realocação de IPs

públicos por meio da conﬁguração global public.ip.ad dress.quar antine.durati

on, cujo valor padrão é 0 (em minutos). Quando esta conﬁguração global está

habilitada (valor diferente de 0), ao liberar um IP público, este é movido para a

quarentena e somente o usuário anteriormente dono do IP poderá realocá-lo

durante o período de quarentena. Root admins e domain admins podem utilizar

as seguintes APIs para manipular/listar os IPs da quarentena:

• removeQuaran tinedIp: remove um IP público da quarentena, utilizando

como parâmetros id (o ID do IP público a ser removido) ou ipaddres s (o

próprio IP público a ser removido), e removalreason (o motivo da remo-

ção, sendo uma string não vazia).

• updateQuarantinedIp: atualiza a data de término da quarentena de um IP

público, utilizando como parâmetros i d (o ID do IP público a ter sua data

de término atualizada) e enddate (a data de término da quarentena).

• listQuarantinedIps: lista os IPs públicos em quarentena, exibindo o ID, as

datas de criação e término da quarentena, o próprio IP público, o ID e o

nome da conta anteriormente dona do IP público, o motivo da remoção

(se realizada via API), a data da remoção e o ID da conta que o removeu.

Não foram alocados para outras redes.

139

2.7. Virtual Private Cloud (VPC)

Uma VPC é um conjunto de redes guest isoladas, que nesse contexto são

chamadas de tiers e adquirem novas características. Todas elas são gerencia-

das através do mesmo roteador virtual e conectadas entre si através dele, de

acordo com a política de ACL deﬁnida. Dessa maneira, é possível estabelecer

uma topologia de rede virtual própria, simulando uma rede física real.

As operações possíveis usando VPCs e seus componentes são:

2.7.1. Operações com a VPC

2.7.1.1. Adição de VPC

Figura 169: Criando uma nova VPC

140

Figura 170: Conﬁgurando a nova VPC

Figura 171: Veriﬁcando se a VPC foi corretamente criada

Nesse ponto, é importante ressaltar alguns aspectos:

• CIDR: deﬁne o intervalo possível de IPs que essa rede virtual terá. Tiers

alocados dentro dessa rede deverão estar dentro desse intervalo. Além

disso, uma VPC não é acessível fora da zona na qual foi criada.

• VPC Oﬀering: As opções disponíveis são:

141

– Default VPC Oﬀering:

Suporta os serviços: VPN, DNS, Static Nat, Network ACL, User Data,

Source Nat, Lb,Port Forwarding, DHCP. Cria um virtual router, mas não

o torna redundante.

– Default VPC Oﬀering with Netscaler:

Realiza o mesmo que o Default VPC Oﬀering, porém, por utilizar Nets-

caler, acrescenta a possibilidade de realizar balanceamento de carga.

– Redundant VPC Oﬀering:

Realiza o mesmo que o Default VPC Oﬀering, porém cria um virtual

router redundante.

Por padrão, ao criar uma VPC, o Apache CloudStack cria automaticamente um

virtual router.

2.7.1.2. Reinicialização de VPC

É possível reiniciar a VPC, seja para aplicar alguma mudança mais complexa ou

para tentar solucionar algum problema. Ao realizar essa operação, é impor-

tante lembrar que VMs que utilizam tal VPC irão ﬁcar sem conexão durante o

tempo de reinicialização.

Figura 172: Reiniciando uma VPC

142

Figura 173: Opções de reinicialização de uma VPC

Sendo as opções possíveis:

• Clean up: irá tentar limpar elementos antigos da rede, caso houver.

• Make redundant: irá criar e iniciar um segundo virtual router em um dos

hosts da estrutura, preferencialmente um que seja diferente do que já

possui o primeiro virtual router. Essa opção só irá aparecer caso a VPC

não seja redundante.

2.7.1.3. Remoção de VPC

Ao remover uma VPC, é necessário remover os tiers que fazem parte dela. Os

virtual routers, entretanto, serão automaticamente deletados.

Figura 174: Removendo uma VPC

143

Figura 175: Conﬁrmando a ação

Figura 176: Erro que ocorre ao tentar deletar uma VPC

Uma descrição detalhada de como remover os tiers de uma VPC pode ser

encontrada na página 148. Uma vez que os tiers dessa VPC estejam devida-

mente removidos, basta repetir o processo.

2.7.1.4. Aquisição de IP público para uma VPC

Os passos para adquirir um IP público são:

Figura 177: Acessando a VPC

144

Figura 178: Acessando os IPs públicos da VPC

Figura 179: Escolhendo um IP público

Esses passos apenas alocam um IP público para a VPC, mas não o relacio-

nam com nenhuma VM. As possíveis operações com IPs públicos são descritas

na seção 2.6.

2.7.2. Tiers

Um tier funciona como uma rede isolada, vista na seção na seção 2.5, dentro

da VPC.

145

2.7.2.1. Adição de tiers à VPC

Figura 180: Acessando a VPC criada

Figura 181: Veriﬁcando os detalhes da VPC

Figura 182: Adicionando um novo tier

146

Figura 183: Criando um novo tier

É importante ressaltar que não é possível ter dois tiers com CIDRs que se so-

breponham (o que inclui CIDRs iguais) na mesma VPC.

Após adicionado um tier à VPC, é possível selecioná-lo durante a criação de

uma VM, da mesma maneira que uma rede comum.

147

2.7.2.2. Remoção de tiers da VPC:

Figura 184: Navegando até os tiers

Figura 185: Removendo um tier

Figura 186: Conﬁrmando a remoção do tier

148

Não é possível remover um tier que possua VMs, sendo necessário primeiro

remover a rede das VMs que a utilizam

2.7.3. Network ACL

Uma ACL (ou Network ACL/ACL list) é um conjunto de regras que permitem

ou bloqueiam o tráfego que passa pelos tiers. Estas regras podem ser utilizadas

para liberar ou restringir a comunicação entre a Internet e os tiers e entre os

próprios tiers.

Essencialmente, a ACL funciona como uma junção das egress rules de uma

rede guest com o ﬁrewall de um IP público, mas é destinada aos tiers. Cada tier

possui apenas uma ACL, mas uma ACL pode ser utilizada por vários tiers.

Por padrão, o CloudStack possui duas opções de ACLs que não podem ser

alteradas: defaul t_allow, a qual libera todo o tráfego de entrada e de saída, e

default_deny, a qual bloqueia todo o tráfego. Para adicionar um conjunto de

regras personalizadas, deve-se criar uma ACL:

Figura 187: Adicionando uma nova ACL

Esse processo é descrito na página 91.

149

Figura 188: Criando uma nova ACL

Figura 189: Navegando até a ACL criada

Figura 190: Navegando até a criação de uma nova regra na ACL

Para adicionar uma regra à ACL, é preciso preencher os seguintes campos:

• #Rule:

Número da regra. As regras são avaliadas do menor para o maior nú-

mero. Se deixado em branco, ele será deﬁnido automaticamente (auto-

incrementado).

150

• CIDR list:

Deﬁne o intervalo possível de IPs em que esta regra será aplicada.

• Action:

Deﬁne se a regra é de permissão ou restrição.

• Protocol:

As opções disponíveis são: TCP, UDP, ICMP, All e Protocol Number. Isso

permite uma alta ﬂexibilização em relação a criação das regras.

• Traﬃc Type:

Deﬁne o tipo de tráfego, se é de entrada ou saída.

• Description:

Descrição da regra.

A seguir, é demonstrado um exemplo de criação de regra para o funciona-

mento do comando SSH:

Figura 191: Adicionando regra que permite o tráfego de entrada da porta 22 do protocolo TCP

(SSH)

151

Figura 192: Adicionando regra que permite o tráfego de saída da porta 22 do protocolo TCP

(SSH)

Assim, ao criar um novo tier naquela VPC, é possível utilizar nele a ACL

recém-criada.

No momento de escrita deste documento, ao criar uma ACL pela UI do

CloudStack, ela só poderá ser utilizada por tiers que pertencem à VPC na qual

foi criada. No entanto, por meio da API createNetworkACLList, ao não informar

o parâmetro vpcId, também é possível às contas root admin criar ACLs globais

que, da mesma forma que as ACLs default_allow e default _deny, estarão dis-

poníveis para uso em todas as VPCs. Exemplo:

create networkacllist name=<nome_da_acl>

2.7.4. Domain VPC

Domain VPC é um recurso que permite que a VPC seja gerenciada por uma

conta e que os tiers de uma mesma VPC possam ser criados para diferentes

contas, possibilitando assim o compartilhamento de recursos.

Com a utilização da Domain VPC, diversas contas podem usar a mesma VPC

152

e consumir apenas um VR; cada tier continuará sendo isolado via broadcast

domain.

Para utilizar esta funcionalidade, basta selecionar uma conta para ser dona

do tier na criação do mesmo:

Figura 193: Seleção da conta dona do tier

Para que a criação do tier seja possível, a conta criando o tier e a conta dona

da VPC devem ter acesso à conta para qual o tier será criado. A conta criando

o tier também deve ter acesso à conta dona da VPC.

2.7.4.1. Alocação de IPs públicos em domain VPCs

Caso seja necessário alocar um IP público para ser utilizado em uma domain

VPC, o IP público deve ser adquirido à conta dona da tier que irá utilizá-lo, e não

à conta dona da domain VPC. Se ele for adquirido à conta dona da domain VPC,

somente a conta dona da domain VPC poderá utilizá-lo; as contas que possuem

153

tiers na VPC não. A seleção da conta é feita no formulário de aquisição de IP

público.

Figura 194: Seleção da conta no formulário de aquisição de IP público

2.8. Virtual Private Network (VPN)

2.8.1. Tipos de VPN

O CloudStack possibilita a criação de VPNs para que usuários acessem suas

VMs, sendo possível criar dois tipos de VPNs:

• C2S (Client-to-Site) VPNs: Permite ao usuário a criação de uma conexão se-

gura com a VPC, possibilitando a ele se conectar em suas VMs sem a ne-

cessidade de atribuir IPs públicos para as mesmas. O CloudStack utiliza o

protocolo IPSec para realizar as conexões. Ele realiza uma única conexão

por vez entre dois IPs públicos, portanto, nesse tipo de VPN, somente um

usuário por vez conseguirá se conectar com a VPC quando estes estive-

rem utilizando o mesmo IP público.

• S2S (Site-to-Site) VPNs: Permite ao usuário a criação de uma conexão se-

gura entre um datacenter e a VPC, por exemplo, conectar a rede de um

escritório na cloud.

154

2.8.2. Operações com VPN

2.8.2.1. Criação de VPN

• Para criar uma VPN, primeiramente é necessário ter uma VPC (seção 2.7)

com uma oﬀering (seção 2.18.4) que suporte o serviço de VPN. Caso ela já

exista, basta selecioná-la:

Figura 195: Selecionando a VPC

• Nos detalhes da VPC existirão diversas abas, no entanto a relacionada à

User VPN é a Public IP Addresses. As demais abas, Private Gateway, VPN

Gateway e VPN Connection, estão relacionadas à S2S VPN.

Figura 196: Detalhes da VPC

155

• As informações sobre as VPNs estarão no Public IP marcado como source-

NAT.

• Para conﬁgurar a VPN, deve-se navegar até a aba VPN do Public IP:

Figura 197: Detalhes do public IP

• Nessa aba existirá um botão (Enable Remote Access VPN) para habilitar a

VPN para aquela VPC:

Figura 198: Habilitando a VPN

Para habilitar a VPN, é necessário que as seguintes portas do protocolo

UDP estejam abertas:

1. 500 (IKE)

156

2. 1701 (L2TP)

3. 4500 (NAT-T)

• Então, o CloudStack irá habilitar a VPN para a VPC e gerar uma pre-shared

key para ser utilizada na conexão com IPSec, como no exemplo abaixo:

– VPN gateway: 192.168.100.52

– IPSec pre-shared key: kuNbGHMBvODUxztzUXtyDz7q

Figura 199: VPN habilitada

• O tamanho da IPSec pre-shared key pode ser alterado através das conﬁ-

gurações globais:

Nome Descrição Valor pa-

drão

remote.access.vpn.psk.length Tamanho da chave IPSec

compartilhada (min: 8, max:

256)

Tabela 11: Conﬁguração do tamanho da chave IPSec compartilhada

2.8.2.2. Desabilitação de VPN para a VPC

Após habilitada, é possível desabilitar a VPN para a VPC:

157

Figura 200: Desabilitar a VPN

2.8.2.3. Gerência de usuários

Para gerenciar os usuários basta navegar até os VPN users:

Figura 201: Gerenciar usuários da VPN

2.8.2.4. Adição de usuário

Para adicionar um usuário à VPN, clique no botão Add VPN user e preencha

as informações no formulário:

Figura 202: Iniciando adição de usuário à VPN

158

Figura 203: Adicionando usuário à VPN

2.8.2.5. Deﬁnição da quantidade máxima de usuário da VPN por conta

É possível conﬁgurar a quantidade máxima de usuários da VPN que cada

account pode ter através das conﬁgurações globais:

Nome Descrição Valor pa-

drão

remote.access.vpn.user.limit Máximo de usuários da VPN

por account

Tabela 12: Conﬁguração de Limite de Usuário na VPN por Account

2.8.2.6. Exclusão de usuário

Após criado, o usuário não poderá ser editado, apenas excluído:

Figura 204: Excluíndo usuário da VPN

159

Após conﬁgurar a VPN e adicionar o usuário, a conexão poderá ser esta-

belecida.

2.8.2.7. Conexão à VPN pelo Linux

Nas conﬁgurações de rede, deve ser adicionada uma nova VPN:

Figura 205: Iniciando a adição de uma VPN no Linux

O protocolo utilizado pelo CloudStack é o L2TP.

No formulário deverão ser informados o gateway da VPN, o usuário e a se-

nha cadastrados.

Figura 206: Adicionando uma VPN no Linux

Deve ser informada a IPSec pre-shared key:

160

Figura 207: Informando a IPSec pre-shared key - Parte 1

Figura 208: Informando a IPSec pre-shared key - Parte 2

Também deve ser desabilitado o protocolo EAP, pois o CloudStack não o

suporta:

Figura 209: Desabilitando o protocolo EAP - Parte 1

161

Figura 210: Desabilitando o protocolo EAP - Parte 2

Após adicionar a VPN, a conexão poderá ser estabelecida.

2.8.2.8. Conexão à VPN pelo Windows

Em conﬁgurações de rede e internet, vá até a aba VPN e adicione uma conexão

VPN:

Figura 211: Adicionando uma VPN no Windows

162

O seguinte formulário será aberto:

Figura 212: Iniciando a adição de uma VPN no Windows

Conﬁgurações importantes:

• Nome ou endereço do servidor: insira o gateway da VPN.

• Tipo de VPN: selecione a opção L2TP/IPSec com chave pré-compartilhada.

• Chave pré-compartilhada: informe a IPSec pre-shared key.

Figura 213: Finalizando a adição de uma VPN no Windows

163

No campo Tipo de informações de entrada, selecione a opção Nome de

usuário e senha e, em seguida, preencha os campos com o usuário e a senha

cadastrados anteriormente.

Após adicionar a VPN, é necessário realizar algumas conﬁgurações:

1. Vá até Network connections e abra as propriedades do adaptador da VPN.

2. Options → Properties → PPP settings → assinalar todas as opções.

Figura 214: Alterando conﬁgurações do PPP

3. Security → Allow these protocols → Microsoft CHAP Version 2 .

164

Figura 215: Habilitando o protocolo MS-CHAP v2

4. Networking → Desabilitar IPv6.

Figura 216: Desabilitando IPv6

5. Botão direito IPv4 → Properties → Advanced → Ip Settings →

Desabilitar "Use default gateway on remote network".

165

Figura 217: Desabilitando o uso de gateway padrão na rede remota

Por ﬁm, estabeleça a conexão com a VPN.

2.8.3. S2S (Site-to-Site) VPNs

Para conﬁgurar uma conexão VPN S2S, primeiramente é necessário criar

um VPN customer gateway:

Figura 218: Navegando até a aba VPN customer gateway

O seguinte formulário de criação será aberto:

166

Figura 219: Criando um VPN customer gateway

Basta informar o gateway, o CIDR (separados por vírgula caso tenha mais de

um) e a IPsec preshared-key do cliente. Também é possível alterar algumas con-

ﬁgurações de segurança no restante dos campos se necessário. Durante o uso

de múltiplos CIDRs, pode ser necessária a ativação da opção Split Connections,

podendo sua ausência ou má conﬁguração causar erros.

167

Caso o protocolo utilizado seja o IKEv1, é necessário implementar a conexão

utilizando o plugin Unity do strongSwan (o que não é realizado pelo ACS). Caso

a versão seja a IKEv2, dependerá se o par suporta múltiplas subnets. Pode-

se utilizar como exemplo a AWS, que suporta múltiplos CIDRs mas não lida

bem com múltiplas conexões, e o Fortinet, que não suporta múltiplos CIDRs na

mesma conexão e necessita da utilização da opção Split Connections.

Após criar um VPN customer gateway, é possível editá-lo:

Figura 220: Editando um VPN customer gateway

E, se o VPN customer gateway não ﬁzer parte de nenhuma conexão, também

é possível removê-lo:

Figura 221: Deletando um VPN customer gateway

O próximo passo é criar um VPN gateway para a VPC que fará parte da cone-

xão VPN S2S. Nos detalhes da VPC, navegue até a aba VPN gateway e procure

pelo botão Create site-to-site VPN gateway:

168

Figura 222: Navegando até VPN gateway nos detalhes da VPC

Ao clicar no botão, o CloudStack disponibilizará um endereço IP que será o

VPN gateway da VPC.

Figura 223: Criando um VPN gateway

Por último, deve-se criar uma conexão VPN S2S na VPC. Ainda nos detalhes

da VPC, vá até a aba VPN connection e procure pelo botão Create site-to-site VPN

connection:

169

Figura 224: Navegando até VPN connection nos detalhes da VPC

O seguinte formulário será aberto:

Figura 225: Criando uma conexão VPN S2S

Informe o VPN customer gateway e, caso a conexão seja entre duas VPCs,

marque a opção Passive na VPC que não iniciará a conexão.

Depois de criada a conexão, é possível reiniciá-la:

170

Figura 226: Reiniciando uma conexão VPN S2S

E também é possível removê-la:

Figura 227: Removendo uma conexão VPN S2S

2.9. Assinatura de requisições HTTP

A API do CloudStack requer um processo de assinatura ao enviar requisi-

ções HTTP, com o objetivo de autenticar o operador e autorizá-lo de forma

apropriada. Para que isso seja possível, o ACS permite a emissão de api keys e

secret keys, que serão usadas no corpo da request durante o procedimento.

• Emissão de keys via UI

171

Figura 228: Gerando keys.

• Emissão de keys via CloudMonkey

• Consulta de keys via CloudMonkey

172

get userkeys id=<id do usuário> filter=<filtro desejado>

As requests enviadas à API do CloudStack pode ser do tipo GET ou POST e

possuem o seguinte corpo:

• URL principal do CloudStack, por exemplo:

http://example.com:8080/client/api

• O comando que será executado, por exemplo: listUsers

• Parâmetros exigidos pelo comando

• A api key que será usada para identiﬁcar o usuário

• A assinatura(signature) que será usada para autenticar o usuário

• Exemplo de uma requisição

http://localhost:8080/client/api?

command=<comando>&

<parametro(s)>&

apiKey=<chave da api>&

signature=<assinatura>

Toda requisição terá o formato URL + Comando + Assi n atura; para gerar a

assinatura, siga os passos abaixo:

1. Separe cada campo da requisição com um & e aplique URL encode

2. Certiﬁque-se de que a string dos comandos esteja inteiramente em letras

minúsculas, por exemplo:

apikey=mivr6x7u6bn_sdahobpjnejpgest35exq-jb8cg20yi3yaxxcgpyuairmfi_ejtvwz0nukkjbpmy3y2bcikwfq&

command=deployvirtualmachine&

diskofferingid=1&serviceofferingid=1&

templateid=2&zoneid=4

3. Após isso, é necessário calcular o hash da string de comandos usando o

algorítimo de hashing SHA-1 com a secret key do usuário;

4. Por último codiﬁque a string resultante em Base64, o resultado ﬁnal será

semelhante ao exemplo abaixo:

173

http://localhost:8080/client/api?

command=deployVirtualMachine&serviceOfferingId=1&

diskOfferingId=1&

templateId=2&

zoneId=4&

apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&

signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1

Para ilustrar o processo de assinatura de requisições na prática, abaixo é

apresentado um passo a passo de como realizar o procedimento:

1. Realize a importação dos módulos utilizados

>>> import urllib2

>>> import urllib

>>> import hashlib

>>> import hmac

>>> import base64

2. Especiﬁque o endpoint do ACS, os comandos a serem executados e as

chaves do usuário:

>>> baseurl='http://localhost:8080/client/api?'

>>> request={}

>>> request['command']='listUsers'

>>> request['response']='json'

>>> request['apikey']=

'plgWJfZK4gyS3mOMTVmjUVg-X-jlWlnfaUJ9GAbBbf9EdM-kAYMmAiLqzzq1ElZLYq_u38zCm0bewzGUdP66mg'

>>> secretkey=

'VDaACYb0LV9eNjTetIOElcVQkvJck_J_QljX_FcHRj87ZKiy0z0ty0ZsYBkoXkY9b7eq1EhwJaw7FF3akA3KBQ'

3. Crie a string de requisição:

>>> request_str='&'.join(['='.join([k,urllib.quote_plus(request[k])]) for k in request.keys()])

4. Inicie o processo de encriptação da assinatura com HMAC, Base64 e URL

encoding:

>>> sig_str=

'&'.join(['='.join([k.lower(),urllib.quote_plus(request[k]).lower().replace('+','%20')])

for k in sorted(request.iterkeys())])

>>> sig_str

'apikey=

plgwjfzk4gys3momtvmjuvg-x-jlwlnfauj9gabbbf9edm-kaymmailqzzq1elzlyq_u38zcm0bewzgudp66mg&

command=listusers&

response=json'

>>> sig=hmac.new(secretkey,sig_str,hashlib.sha1)

>>> sig

<hmac.HMAC instance at 0x10d91d680>

>>> sig=hmac.new(secretkey,sig_str,hashlib.sha1).digest()

174

>>> sig

'M:]x0exafxfbx8fxf2yxf1px91x1ex89x8axa1x05xc4Axdb'

>>> sig=base64.encodestring(hmac.new(secretkey,sig_str,hashlib.sha1).digest())

>>> sig

'TTpdDq/7j/J58XCRHomKoQXEQds=n'

>>> sig=base64.encodestring(hmac.new(secretkey,sig_str,hashlib.sha1).digest()).strip()

>>> sig

'TTpdDq/7j/J58XCRHomKoQXEQds='

>>> sig=urllib.quote_plus(base64.encodestring(hmac.new(secretkey,sig_str,hashlib.sha1).digest())

.strip())

5. Por último monte a string e envie a requisição:

>>> req=baseurl+request_str+'&signature='+sig

>>> req

>>> 'http://localhost:8080/client/api?

apikey=plgWJfZK4gyS3mOMTVmjUVg-X-jlWlnfaUJ9GAbBbf9EdM-kAYMmAiLqzzq1ElZLYq_u38zCm0bewzGUdP66mg&

command=listUsers&

response=json&

signature=TTpdDq%2F7j%2FJ58XCRHomKoQXEQds%3D'

>>> res=urllib2.urlopen(req)

>>> res.read()

'{ "listusersresponse" :

{ "count":3 ,"user" :

[

{"id":"7ed6d5da-93b2-4545-a502-23d20b48ef2a",

"username":"admin",

"firstname":"admin",

"lastname":"cloud",

"created":"2012-07-05T12:18:27-0700",

"state":"enabled",

"account":"admin",

"accounttype":1,

"domainid":"8a111e58-e155-4482-93ce-84efff3c7c77",

"domain":"ROOT",

"apikey":

"plgWJfZK4gyS3mOMTVmjUVg-X-jlWlnfaUJ9GAbBbf9EdM-kAYMmAiLqzzq1ElZLYq_u38zCm0bewzGUdP66mg",

"secretkey":

"VDaACYb0LV9eNjTetIOElcVQkvJck_J_QljX_FcHRj87ZKiy0z0ty0ZsYBkoXkY9b7eq1EhwJaw7FF3akA3KBQ",

"accountid":"7548ac03-af1d-4c1c-9064-2f3e2c0eda0d"},

{"id":"1fea6418-5576-4989-a21e-4790787bbee3",

"username":"runseb",

"firstname":"foobar",

"lastname":"goa",

"email":"joe@smith.com",

"created":"2013-04-10T16:52:06-0700",

"state":"enabled",

"account":"admin",

"accounttype":1,

"domainid":"8a111e58-e155-4482-93ce-84efff3c7c77",

"domain":"ROOT",

"apikey":

"Xhsb3MewjJQaXXMszRcLvQI9_NPy_UcbDj1QXikkVbDC9MDSPwWdtZ1bUY1H7JBEYTtDDLY3yuchCeW778GkBA",

"secretkey":

"gIsgmi8C5YwxMHjX5o51pSe0kqs6JnKriw0jJBLceY5bgnfzKjL4aM6ctJX-i1ddQIHJLbLJDK9MRzsKk6xZ_w",

"accountid":"7548ac03-af1d-4c1c-9064-2f3e2c0eda0d"},

{"id":"52f65396-183c-4473-883f-a37e7bb93967",

"username":"toto",

"firstname":"john",

"lastname":"smith",

"email":"john@smith.com",

175

"created":"2013-04-23T04:27:22-0700",

"state":"enabled",

"account":"admin",

"accounttype":1,

"domainid":"8a111e58-e155-4482-93ce-84efff3c7c77",

"domain":"ROOT",

"apikey":

"THaA6fFWS_OmvU8od201omxFC8yKNL_Hc5ZCS77LFCJsRzSx48JyZucbUul6XYbEg-ZyXMl_wuEpECzK-wKnow",

"secretkey":

"O5ywpqJorAsEBKR_5jEvrtGHfWL1Y_j1E4Z_iCr8OKCYcsPIOdVcfzjJQ8YqK0a5EzSpoRrjOFiLsG0hQrYnDA",

"accountid":"7548ac03-af1d-4c1c-9064-2f3e2c0eda0d"} ] } }'

É importante mencionar que também é possível deﬁnir um tempo de ex-

piração para as chamadas da API. O servidor irá monitorar a faixa de tempo

especiﬁcada e em seguida rejeitará todas as requests enviadas após a expira-

ção. Para habilitar essa feature é necessário adicionar os seguintes parâmetros

à requisição:

Parâmetro Valor Descrição

signatureVersion 3 Se esse parâmetro não for

igual a 3 ou estiver vazio ele

será ignorado na request.

expires YYYY-MM-

DDThh:mm:ssZ(ISO 8601)

Especiﬁca a data em que a

assinatura presente na re-

quest irá expirar.

Tabela 13: Parâmetros de tempo de expiração para chamadas à API

Exemplo de uso:

• expires=2011-10-10T12:00:00+0530

• Exemplo de uma requisição com expiração:

http://<IPAddress>:8080/client/api?

command=listZones&

signatureVersion=3&

expires=2011-10-10T12:00:00+0530&

apiKey=

miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&

signature=

Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D

176

2.10. Templates e ISOs

Templates são imagens reutilizáveis que servem como modelo ou padrão

para a criação de VMs. Intrinsecamente, um template é uma imagem de um

disco virtual que contém de conﬁgurações básicas, como o sistema operaci-

onal, os usuários e as senhas padrões, até conﬁgurações avançadas, como

softwares previamente instalados e conﬁgurados. Vale ressaltar que os tem-

plates são dependentes do hypervisor que será utilizado.

No momento de criação do template o usuário irá deﬁnir se o mesmo será

público ou privado. Quando selecionado public, o template ﬁcará disponível

para todos os usuários que consigam acessar a zona onde o template foi arma-

zenado. O novo template ﬁcará visível no menu Templates quando o processo

de criação do template for concluído, isto é, quando o ACS terminar o download

e a preparação do mesmo. O template ﬁca então disponível ao criar uma nova

VM.

ISO refere-se a uma imagem de disco óptico, como um CD, DVD ou Blu-ray.

É um arquivo que contém uma cópia exata, ou imagem, de todo o conteúdo

de um disco óptico. Essas imagens são frequentemente usadas para distribuir

grandes programas e sistemas operacionais, permitindo que o usuário grave a

imagem em um disco físico ou a monte como um disco virtual em seu sistema

para acessar o conteúdo sem a necessidade de um disco físico.

Assim como os templates, as ISOs podem ser públicas ou privadas. Um

ponto importante é que as ISOs não dependem de hypervisors especíﬁcos, isto

é, pode-se montar a mesma imagem utilizando hypervisor distintos, diferente-

mente dos templates. VMs criadas com esse recurso precisam ser conﬁguradas

desde a instalação.

Semelhantes aos templates, as ISOs podem ser armazenadas, e disponibili-

zadas com certo nível de privacidade. No momento de registro o usuário irá

classiﬁcar a imagem como inicializável ou não inicializável. Sendo a inicializável

a que contém um sistema operacional.

177

2.10.1. Operações com templates/ISOs

O Apache CloudStack oferece diversas opções de operações com templates

e ISOs, sendo possível:

2.10.1.1. Vizualização

Figura 229: Visualizando templates e ISOs

• Template:

178

Figura 230: Acessando os detalhes do template

Figura 231: Detalhes do template

• ISO:

179

Figura 232: Acessando os detalhes da ISO

Figura 233: Detalhes da ISO

2.10.1.2. Listagem

Por padrão a interface gráﬁca envia o ﬁltro all (lista todos os elementos regis-

trados no ambiente) quando uma conta do tipo root admin ou domain admin

180

envia a requisição, quando trata-se de uma conta do tipo user a requisição é

enviada com o ﬁltro self (que lista as ISOs e templates que foram registradas

pelo usuário). Esses ﬁltros podem ser alterados clicando no campo de texto ao

lado do botão refresh.

Estão disponíveis para consulta os seguintes ﬁltros:

• featured: Retorna os elementos que foram marcados como destaque;

• self: Retorna os elementos registrados pelo usuário que enviou a requi-

sição;

• selfexecutable: Idem ao ﬁltro anterior, porém retorna apenas aqueles

que podem ser usados para instanciar novas VMs;

• sharedexecutable: Retorna os elementos que foram criados por outros

usuários, cuja permissão foi concedida para o usuário que enviou a requi-

sição;

• executable: Retorna os elementos que pertencem ao usuário que enviou

a requisição, bem como os elementos marcados como público e que po-

dem ser usados para instanciar novas VMs;

• community: Retorna os elementos marcados como público e que não

foram marcados como destaque;

• all: Retorna todos os elementos do ambiente (pode ser usado apenas por

administradores)

181

Figura 234: Filtros para listagem de ISOs e templates.

2.10.1.3. Resgitro

• Template:

Figura 235: Registrando o template

182

Figura 236: Conﬁgurando o template

– Direct download: se selecionado, o template será baixado diretamente

no primary storage na primeira vez que uma VM for criada. Após, ele

ﬁcará armazenado no primary storage como cache e só será remo-

vido quando todas as VMs que o utilizam forem destruídas. Assim,

somente será feito um novo download em caso de remoção de todas

as VMs que usam o template.

Templates marcados com essa opção possuirão o estado Bypassed

183

Secondary Storage, indicando que foram baixados diretamente para

o primary storage e que nunca estarão armazenados no secondary

storage.

• ISO:

Figura 237: Registrando a ISO

Figura 238: Conﬁgurando a ISO

É necessário indicar qual o tipo de sistema operacional do template/ISO, pois

essa informação será utilizada pelo hypervisor. Caso o sistema operacional es-

184

colhido for diferente do template/ISO, algumas inconsistências podem surgir

durante a criação de VMs.

2.10.1.4. Upload

• Template:

Figura 239: Fazendo upload do template

185

Figura 240: Conﬁgurando o template

• ISO:

Figura 241: Fazendo upload da ISO

186

Figura 242: Conﬁgurando a ISO

2.10.1.5. Edição

Navegue até os detalhes do template/ISO.

• Template:

Figura 243: Editando detalhes do template

187

Figura 244: Editando o template

• ISO:

Figura 245: Editando detalhes da ISO

188

Figura 246: Editando a ISO

2.10.1.6. Edição de permissões de template/ISO

Mudanças nas permissões dos templates/ISOs podem ser realizadas via UI e

API. Via API, utiliza-se o comando updateTemplatePermissions ou updateIsoP

ermissions, sendo possível remover, adicionar e redeﬁnir todas a permissões

dos templates/ISOs.

• Template:

Figura 247: Editando as permissões do template

• ISO:

189

Figura 248: Editando as permissões da ISO

Figura 249: Editando permissões

As opções de editação de permissões são as mesmas para templates e ISOs.

Sendo as possíveis operações:

• Add:

Usada para adicionar o template/ISO para determinada account ou pro-

jeto.

• Remove:

Usada para remover o template/ISO de determinada account ou projeto.

• Reset:

Reiniciar todas as permissões do template/ISO para o padrão.

2.10.1.7. Edição de compartilhamento do template

Navegue até os detalhes do template/ISO.

190

• Template:

Figura 250: Editando compartilhamento do template

• ISO:

Figura 251: Editando compartilhamento da ISO

Figura 252: Editando opções de compartilhamento

A conﬁguração global allow.user.view.all.domain.accounts, que possui valor

padrão false, faz com que os usuários regulares não vejam a lista de contas

existentes no domínio do qual ele faz parte, isso o obriga saber especiﬁcamente

o nome da conta destino ao qual ele estará compartilhando o template/ISO.

É apresentado ao usuário um campo que faz a requisição do nome da conta

destino.

191

As opções de editação de compartilhamento são as mesmas para templates

e ISOs.

2.10.1.8. Remoção de template/ISO

Templates/ISOs podem ser excluídos, mas existem algumas ressalvas. O com-

portamento padrão do CloudStack é recusar a exclusão do template/ISO quando

existem VMs o utilizando.

Após a exclusão de templates/ISOs, as instâncias de VMs (pertencentes à

zona) que utilizam a imagem não serão afetadas, isto é, continuarão em exe-

cução. No entanto, o template/ISO excluído não poderá ser utilizado em novas

instâncias.

• Template:

Figura 253: Deletando o template

• ISO:

192

Figura 254: Deletando a ISO

2.10.1.9. Criação de template baseado em uma VM existente

Para criar um template baseado em uma VM existente, ela precisa estar no

estado Stopped:

Figura 255: Navegando até as VMs

193

Figura 256: Indo até o volume da VM

Figura 257: Criando o template

194

Figura 258: Conﬁgurando o template

2.11. Resource Tags

Tags, ou resource tags, são pares no formato key:value que guardam meta-

dados sobre algum recurso para categorizá-lo.

É bastante útil para ﬁltrar listas e utilizar em relatórios do CloudStack Usage

(como em regras de ativação do Quota, seção 4) de forma personalizada.

Para adicionar ou remover tags:

• Via UI:

Figura 259: Resource tags de um componente qualquer

195

• Via CloudMonkey: Pode-se utilizar as chamadas de API listTags, createTa

gs e deleteT a g s. No deleteTags, pode-se omitir os parâmetros tags[0] se

for desejada a remoção de todas as tags.

Um host, um storage pool ou uma oﬀering também podem possuir resource

tags (que não devem ser confundidas com host tags ou storage tags.

2.12. Aﬃnity Groups

Aﬃnity groups é uma funcionalidade que permite ao usuário deﬁnir quais

VMs devem rodar, ou não, no mesmo host. Estes grupos podem ser utilizados,

por exemplo, para garantir uma conexão e uma baixa latência entre VMs ao

agrupar todas no mesmo host ou para aumentar a tolerância a falhas de um

sistema ao especiﬁcar que VMs que oferecem um mesmo serviço não devem

rodar no mesmo host, possibilitando assim que, caso algum host apresente

uma falha, as VMs que estão em outros hosts continuem rodando e oferecendo

o serviço normalmente.

Os aﬃnity groups não devem ser confundidos com os Instance Groups: estes

últimos servem apenas para o usuário organizar as VMs, agrupando-as, e não

inﬂuenciam em quais hosts as VMs irão rodar.

2.12.1. Tipos de aﬃnity groups

Existem quatro tipos de aﬃnity groups a partir da versão 4.18 do Cloud-

Stack

• Host aﬃnity (strict): especiﬁca que as VMs devem sempre rodar no mesmo

host. No entanto, se o host não possuir capacidade suﬁciente para rodar

todas as VMs do grupo, ocorrerá um erro na criação de novas instâncias.

• Host anti-aﬃnity (strict): especiﬁca que as VMs devem sempre rodar em

hosts diferentes. De maneira semelhante, se não existirem hosts suﬁcien-

tes para todas as VMs, ocorrerá um erro na criação de novas instâncias.

Em versões anteriores à 4.18, existem somente os tipos host aﬃnity e host anti-aﬃnity, que

equivalem aos tipos host aﬃnity (strict) e host anti-aﬃnity (strict).

196

• Host aﬃnity (non-strict): especiﬁca que as VMs devem rodar no mesmo

host sempre que possível. Se o host não possuir capacidade, novas ins-

tâncias serão criadas em algum outro host.

• Host anti-aﬃnity (non-strict): especiﬁca que as VMs devem rodar em

hosts diferentes sempre que possível. Se não há hosts suﬁcientes, novas

instâncias serão criadas em um host que já tem outras instâncias.

2.12.2. Operações com aﬃnity groups

2.12.2.1. Adição de aﬃnity group

Figura 260: Navegando até os aﬃnity groups

Figura 261: Criando um aﬃnity group

197

Figura 262: Aﬃnity group criado

2.12.2.2. Adição de VM ao aﬃnity group

A VM deve estar parada para que a opção de mover ao aﬃnity group apareça.

Figura 263: Acessando a VM que será movida ao grupo

198

Figura 264: Movendo a VM para um aﬃnity group

Figura 265: Selecionando o grupo

199

2.12.2.3. Visualização de VMs no aﬃnity group

Figura 266: Acessando o grupo

Figura 267: Visualizando as VMs no grupo

200

Figura 268: Lista de VMs no grupo

2.12.2.4. Exclusão de aﬃnity group

Figura 269: Excluindo o grupo

2.13. Autoscale VM groups

A funcionalidade de autoscale VM groups permite a criação de grupos de

VMs que automaticamente aumentam e reduzem em número conforme a de-

manda pelos recursos das VMs aumenta ou diminui. Esta funcionalidade pode

201

ser utilizada para, por exemplo, adicionar mais máquinas que oferecem um

serviço quando todas as existentes estiverem com um alto uso e removê-las

quando a demanda reduzir sem a necessidade da intervenção de um opera-

dor. Assim, ela possibilita um uso mais eﬁciente dos recursos de computação

e, consequentemente, a redução de custos.

Esta gerência automática de instâncias funciona através da criação de dois

conjuntos de regras: um que determina quando devem ser criadas novas VMs,

e outro que determina quando elas devem ser removidas. Por exemplo, pode-

se deﬁnir que serão adicionadas novas máquinas quando a média do uso de

CPU de todas as instâncias estiver acima de 70% e que elas serão removidas

quando a média estiver abaixo de 40%.

O CloudStack monitora as estatísticas de uso das instâncias fornecidas pelo

hypervisor

para realizar esta gestão. Além disso, ele usa um load balancer para

balancear o uso entre as VMs. Assim sendo, os grupos devem estar associados

à uma rede isolada ou à uma VPC com o serviço de load balancing ativado e

conﬁgurado.

2.13.1. Criação de um autoscale VM group

Antes de criar um autoscale VM group, é necessário criar uma rede isolada ou

uma VPC e conﬁgurar o serviço de load balancing. Abaixo, está exempliﬁcada a

conﬁguração de uma rede isolada:

1. Criar uma rede isolada:

Os hypervisors VMWare, XenServer e KVM suportam a funcionalidade de autoscale VM

groups.

202

Figura 270: Criando uma rede isolada

2. Acessar a aba Public IP addresses e adquirir um novo IP público para a

rede:

Figura 271: Acessando a aba de Public IP addresses

203

Figura 272: Adquirindo um novo IP público

3. No IP público, acessar a aba Load balancing e adicionar uma regra de load

balancing

Figura 273: Adicionando uma regra de load balancing

Com a rede isolada conﬁgurada, pode-se prosseguir ao menu de criação do

autoscale VM group:

1. Conﬁgurar as VMs do grupo por meio das conﬁgurações de zona, tem-

A conﬁguração AutoScale indica que a regra vai ser utilizada por um autoscale VMs group.

204

plate, compute oﬀering e data disk.

2. Selecionar a rede isolada criada:

Figura 274: Selecionando a rede isolada

3. Selecionar a regra de load balancing criada:

Figura 275: Selecionando a regra de load balancing

4. Conﬁgurar a scale-up policy:

A scale-up policy é um conjunto de regras que determina quando novas

máquinas devem ser adicionadas ao grupo. Ela possui as seguintes con-

ﬁgurações:

• Condition: regras que determinam quando adicionar mais VMs ao

205

grupo. Quando há mais de uma condition, todas devem ser verda-

deiras para acontecer o scale-up;

• Duration: tempo em segundos no qual as regras devem ser verdadei-

ras para serem adicionadas VMs;

• Quiet Time: após serem adicionadas VMs, tempo no qual a scale-up

policy não adicionará mais instâncias.

Cada condition possui os seguintes parâmetros:

• Counter: estatística das VMs do grupo a ser monitorada. Os counters

disponíveis são:

– VM CPU - average percentage: média de uso da CPU das VMs em

porcentagem (0 a 100);

– VM Memory - average percentage: média de uso da memória prin-

cipal das VMs em porcentagem (0 a 100);

– Public Network - mbps received per vm: média de dados sendo re-

cebidos pelas VMs em Mbps;

– Public Network - mbps transmit per vm: média de dados sendo

enviados pelas VMs em Mbps;

– Load Balancer - average connections per vm: média de conexões

por VM.

• Operator: operador utilizado para comparar os valores;

• Threshold: valor a ser comparado com o counter.

206

Figura 276: Conﬁgurando a scale-up policy

Na imagem, por exemplo, foi criada uma scale-up policy que adiciona no-

vas VMs quando a média do uso de CPU das atuais for maior que 10% por

30 segundos.

2.13.1.1. Conﬁguração da scale-down policy

A scale-down policy segue o mesmo conceito que a scale-up policy, mas

determina quando VMs devem ser removidas.

Figura 277: Conﬁgurando a scale-down policy

Na imagem, foi deﬁnida uma scale-down policy que remove VMs quando

a média do uso de CPU for menor que 10% por 60 segundos.

207

2.13.1.2. Conﬁguração dos detalhes do autoscale VM group

• As conﬁgurações são as seguintes:

– Name: nome do grupo;

– Expunge VM grace period : tempo em segundos a ser esperado

após um scale-down antes de remover as VMs. Este tempo é para

garantir que todas as sessões pendentes e transações sejam en-

cerradas.

– Max members: número máximo de VMs no grupo;

– Min members: número mínimo de VMs no grupo;

– Polling interval: intervalo em segundos no qual as conditions vão

ser conferidas.

Figura 278: Conﬁgurando os detalhes do autoscale VM group

2.13.1.3. Criação do grupo

Após a criação do grupo de autoscale VMs, as instâncias nele podem ser

visualizadas da seguinte forma:

208

Figura 279: Visualizando as instâncias do autoscale VM group

Figura 280: Instâncias do autoscale VM group

2.13.2. Teste de autoscaling

Com as instâncias criadas, é possível testar a funcionalidade de autoscaling.

Para forçar o aumento do uso da CPU e um scale-up, pode-se acessar as ins-

tâncias e executar o seguinte comando:

for i in 1 2 3 4; do while : ; do : ; done & done

Este comando irá criar quatro processos com loops inﬁnitos. Cada loop gera

100% de uso de um núcleo da CPU.

Após alguns minutos, será realizado o scale-up e o grupo terá atingido o

número máximo de instâncias.

209

Figura 281: Instâncias do autoscale VM group após o scale-up

Para realizar o scale-down, pode-se ﬁnalizar os processos:

sudo killall -9 bash

Assim, após alguns minutos, o número de instâncias terá reduzido ao mí-

nimo.

Figura 282: Instâncias do autoscale VM group após o scale-down

2.13.3. Edição de autoscale VM group

Para editar um autoscale VM group, é necessário desativá-lo antes:

210

Figura 283: Desativando o autoscale VM group

Figura 284: Conﬁrmando a ação

Enquanto o grupo estiver desativado, as VMs permanecerão rodando nor-

malmente. No entanto, não será realizado o scale-up, nem o scale-down do

grupo conforme a demanda.

Após desativado, é possível editar os detalhes do grupo, os parâmetros de

deploy das VMs e as scale-up e scale-down policies:

211

Figura 285: Editando os detalhes do grupo e parâmetros de deploy das VMs

Figura 286: Diálogo de edição dos detalhes do grupo e parâmetros de deploy das VMs

212

Figura 287: Editando a scale-up policy do grupo

Figura 288: Editando a scale-down policy do grupo

Após as edições, ative o grupo novamente:

213

Figura 289: Ativando o autoscale VM group

Figura 290: Conﬁrmando a ação

2.13.4. Exclusão de autoscale VM group

Também é possível excluir o autoscale VM group:

214

Figura 291: Excluindo o autoscale VM group

Figura 292: Conﬁrmando a ação

2.14. Kubernetes

O plugin Kubernetes Service adiciona a integração do Kubernetes ao Cloud-

Stack. Tal plugin vem desabilitado por padrão, e apenas usuários administrado-

res podem habilitá-lo através da conﬁguração global cloud.kubernetes.service

.enabled. Ele permite que os usuários executem serviços em contêiner usando

clusters do Kubernetes.

Desde a versão 4.16 do ACS, o plugin Kubernetes Service usa o template de

system VM padrão para implantação dos clusters Kubernetes. Além disso, é utili-

zada uma ISO para instalação dos binários do Kubernetes nos nós do cluster de

215

forma que, para cada versão do Kubernetes que se deseje utilizar, é necessário

prover uma ISO especíﬁca para o CloudStack.

Para implantação e conﬁguração do Kubernetes nos nós do cluster, o plugin

usa a ferramenta kubeadm do Kubernetes. O kubeadm é uma ferramenta de

linha de comando para provisionar facilmente um cluster Kubernetes em ser-

vidores físicos, em nuvem ou em máquinas virtuais. Por debaixo dos panos, os

nós de controle iniciam um cluster Kubernetes usando o comando kubeadm in

it com um token customizado e os nós workers ingressam nesse cluster Kuber-

netes usando o comando kubeadm join com o mesmo token. Mais informações

sobre o kubeadm podem ser encontradas na documentação oﬁcial. Para rote-

amento do cluster o plugin Weave Net CNI é utilizado. Mais informações sobre

o Weave Net CNI pode ser encontradas na documentação oﬁcial.

O plugin permite a criação de clusters Kubernetes usando a UI ou a API. Tanto

a UI quanto a API fornecem a capacidade de listar, excluir, dimensionar, atua-

lizar, parar e iniciar esses clusters.

2.14.1. Versões suportadas do Kubernetes

O ACS permite que o usuário mantenha diversas versões do Kubernetes,

para fazer upload de uma versão do Kubernetes, é necessária a criação de uma

ISO que possua certos arquivos dentro:

1. Arquivos binários do Kubernetes

2. Arquivos binários do CNI

3. Arquivos binários do CRICTL

4. Arquivos de conﬁguração de rede do Weave

5. Arquivos de conﬁguração do painel do Kubernetes

2.14.2. Adição de ISO Kubernetes ao Apache CloudStack

A comunidade disponibiliza algumas ISOs prontas. Os testes e exemplos

deste documento foram feitos com a ISO de versão 1.23.3. Porém, devido ao

rápido ciclo de releases de ISOs do Kubernetes, é recomendado o uso da versão

216

mais recente. É importante notar que operações sobre ISOs Kubernetes só

estão disponíveis para usuários root admin.

A matriz de compatibilidade entre as ISOs e o ACS se encontra abaixo:

K8s

ACS

4.18.0

< 1.23.3

1.24.0

1.25.0

1.26.*

1.27.*

1.28.4

Tabela 14: Matriz de compatibilidade entre versões do ACS e do K8s

A partir da versão 4.16, o Kubernetes começou a utilizar do template da

SystemVM (Debian) para o deploy dos clusters, e o usuário para SSH passou a

ser cloud.

Ao criar o cluster, o ACS permite nomes com letras maiúsculas, porém o Ku-

bernetes trabalha apenas com nomenclaturas em minúsculo. Sendo assim, ao

criar clusters Kubernetes é necessário informar o nome do cluster em minús-

culo. Caso contrário, ao tentar realizar operações que demandam comunica-

ção com o cloudstack, o Kubernetes não encontrará os nós do cluster.

Através da API addKubernetesSupporte dVersion é possível adicionar uma

ISO Kubernetes ao ACS.

add kubernetessupportedversion name=exemplo mincpunumber=2 minmemory=2048 semanticversion=1.23.3 \

url=<URL_de_download_da_ISO> zoneid=<ID_da_zona>

Também é possível fazer a mesma operação via UI, acessando a página Ku-

bernetes ISOs, no submenu imagens; clicando no botão “Adicionar versão Ku-

bernetes”, o formulário abaixo será aberto:

217

Figura 293: Formulário de adição de versão Kubernetes

2.14.3. Deleção de ISO Kubernetes

Através da API deleteKubernetesSupport edVersion é possível deletar uma

ISO Kubernetes do ACS.

delete kubernetessupportedversion id=<ID_da_ISO> filter=<opcional>

Também é possível fazer a mesma operação via UI, acessando a página Ku-

bernetes ISOs, no submenu Images; clicando na ISO a ser deletada; e clicando

no botão de delete.

218

Figura 294: Deletando ISO Kubernetes via UI

Figura 295: Conﬁrmar exclusão da ISO Kubernetes

2.14.4. Clusters Kubernetes

Um cluster Kubernetes consiste em dois principais componentes: o nó de

controle e os nós de trabalho. O nó de controle é responsável por organizar

e conﬁgurar o funcionamento do cluster, podendo haver réplicas para garantir

robustez ao sistema. Nos nós de trabalho, rodam as aplicações. Os nós podem

ser VMs ou máquinas físicas, os quais contêm pods, a menor unidade de um

cluster Kubernetes. Eles funcionam como templates de criação para um tipo de

container.

O plugin Kubernetes Service fornece a funcionalidade de criar e gerenciar

clusters Kubernetes, facilitando implantações em contêineres sem a necessi-

219

dade de conﬁgurar o Kubernetes em cada nó de contêiner manualmente. O

serviço provisionará automaticamente o número desejado de máquinas virtu-

ais de acordo com o tamanho do cluster, usando os binários correspondentes à

versão fornecida do Kubernetes. Além disso, o serviço fornece a funcionalidade

para atualizar e dimensionar clusters. Esses, quando em execução, podem ser

atualizados para uma versão minor ou patch mais recente do Kubernetes por

vez, como também podem ser ampliados ou reduzidos.

2.14.4.1. Criando clusters Kubernetes

O plugin fornece a funcionalidade de criar clusters Kubernetes para redes com-

partilhadas ou isoladas no CloudStack.

A API createKubernetesCluster permite que seja criado um cluster Kuberne-

tes, o uso dela está ilustrado abaixo.

create KubernetesCluster name=exemplo description=exemplo zoneid=<ID_da_zona> \

kubernetesversionid=<ID_da_ISO_Kubernetes> serviceofferingid=<ID_da_compute_offering> \

size=<numero_de_nodos_trabalhadores>

A mesma operação também está disponível na UI, acessando a página Ku-

bernetes, no submenu Compute; clicando no botão Create Kubernetes cluster, o

formulário abaixo será aberto:

220

Figura 296: Formulário de criação de cluster Kubernetes

Existem alguns pontos que devem ser atentados ao criar clusters Kuberne-

tes:

• Atualmente só é possível ter um único cluster Kubernetes por rede.

• As Kubernetes ISOs, ao serem criadas, possuem um requisito mínimo de

recursos como CPU cores e memória alocada. Por isso, é necessário que

tenha uma compute oﬀering que cumpra com todos esses requisitos.

• Ao criar um cluster Kubernetes, serão instanciadas, no mínimo, duas VMs

com a compute oﬀering selecionada: uma para o nó de controle e outra

para um nó de trabalho. O número aumenta com base no tamanho do

cluster usado na criação. Por isso, vale se atentar de que o gasto com

221

recursos será maior do que os requisitos mínimos.

• Para poder acessar os nós via SSH é preciso informar um par de chaves

SSH na criação de clusters Kubernetes. Além disso, o usuário para se co-

nectar via SSH é o cloud

2.14.4.2. Scaling de cluster Kubernetes

A API scaleKubernetesCluster permite que seja feito o scaling de um cluster

Kubernetes, aumentando ou diminuindo o número de nós trabalhadores, ou

mudando a oferta de computação utilizada no cluster. Entretanto, a oferta de

computação só pode ser aumentada e não diminuída. Um exemplo do uso da

API é mostrado abaixo.

scale KubernetesCluster id=<id_cluster_Kubernetes> size=<novo_tamanho_do_cluster> \

serviceofferingid=<id_da_compute_offering>

Essa mesma API pode ser chamada via UI, como ilustrado abaixo.

Figura 297: Formulário de scaling de cluster Kubernetes

Até a versão 4.16 do ACS, o usuário para conexão chamava-se core.

222

2.14.4.3. Upgrade de cluster Kubernetes

A API upgradeKubernetesCluster permite atualizar a versão minor ou patch de

um cluster Kubernetes em execução. Para isso, é necessário que uma ISO com

a versão desejada já esteja disponível no ACS.

upgrade kubernetescluster id=<id_cluster_Kubernetes> kubernetesversionid=<id_versao_kubernetes>

Essa mesma API pode ser chamada via UI, como ilustrado abaixo.

Figura 298: Formulário de upgrade de cluster Kubernetes

É importante observar que a atualização da versão do Kubernetes só pode

ser realizada entre versões patches da mesma versão minor ou de uma versão

minor para a próxima; não é possível pular versões. Essa restrição também se

aplica ao ACS.

2.14.5. Acesso ao Kubernetes

Enquanto o cluster Kubernetes é criado, automaticamente é gerada uma

interface de usuário para o cluster. A documentação do Kubernetes, disponível

neste link, apresenta mais informações sobre o dashboard do Kubernetes. A

UI disponibiliza uma aba Access com informações e o passo a passo de como

acessar o Kubernetes.

223

Figura 299: Acessando o Kubernetes

Essencialmente, um usuário precisa rodar primeiro um proxy local usando

kubectl e o arquivo kubeconﬁg para o cluster ter acesso ao dashboard. Por ques-

tão de segurança, não é permitido login com base no kubeconﬁg, sendo neces-

sário gerar um token de acesso e o kubectl para fazer a conexão. O comando

abaixo pode ser usado, com o path correto para o arquivo kubeconﬁg, para ro-

dar o proxy.

kubectl --kubeconfig /custom/path/kube.config proxy

Assim que o proxy estiver rodando, pode-se acessar o dashboard clicando

224

no link disponível. O token para o login pode ser obtido usando o seguinte

comando:

kubectl --kubeconfig /custom/path/kube.config describe secret $(kubectl --kubeconfig

/custom/path/kube.config get secrets -n kubernetes-dashboard |

grep kubernetes-dashboard-token | awk '{print $1}') -n kubernetes-dashboard

2.14.6. Gerando Token para a Dashboard

Um token de usuário default não pode ser utilizado para acessar o dashboard

do Kubernetes. Para acessá-lo, é necessário criar um token para o usuário kube

rnetes-dashboard no namespace kubernetes-dashboard e informá-lo no login.

O token pode ser criado usando o seguinte comando:

kubectl --kubeconfig <caminho-arquivo-kube.conf> create token kubernetes-dashboard -n kubernetes-dashboard

2.15. 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.

2.15.1. Tipos de snapshot

Existem dois tipos possíveis de snapshots:

2.15.1.1. Snapshot de volume/disco

Tira uma snapshot dos discos

da VM. O administrador da nuvem pode deﬁ-

nir um limite de snapshots que cada usuário pode ter. Usuários podem criar

volumes

e templates baseados em uma snapshot.

É possível realizar snapshots manualmente ou automaticamente, através de

conﬁgurações. Elas são criadas no Primary Storage e, se a conﬁguração glo-

bal snapshot.backup.to.secondary estiver como true

, quando ﬁnalizados, são

A seção 2.4 detalha melhor o assunto de discos de uma VM.

Usuários podem adicionar o volume criado a partir da snapshot na VM, cujo representará

uma unidade externa, a ﬁm de acessar arquivos sem a necessidade de restaurar o sistema

para a snapshot.

Recomendamos sempre utilizar essa conﬁguração como true

225

transferidos para o Secondary Storage, onde permanecerão até serem removi-

dos.

2.15.1.2. Snapshot de VM

Tira uma snapshot semelhante à de volume, no entanto essa contém opções

para incluir o estado da memória/CPU da VM. Esse procedimento pode facilitar

a restauração rápida de uma VM

. Esse tipo de snapshot suporta snapshots

incrementais. A partir da primeira snapshot de uma VM, as demais salvarão as

diferenças que ocorrerão em um arquivo delta

Algumas das limitações existentes sobre snapshots são:

• Alterações de volumes, CPU ou memória em uma VM que possui snapshots

podem ocasionar erros, seja ao tentar realizar essas alterações na VM ou

ao tentar restaurar a snapshot.

• Não é possível salvar uma cópia de dois volumes de uma VM na mesma

snapshot.

• Não é possível realizar snapshots de VM e de volume ao mesmo tempo.

• Apenas snapshots geradas através do CloudStack são gerenciados pelo

mesmo.

2.15.2. Operações com snapshot

As operações possíveis com snapshots são:

Desde que não seja realizada nenhuma alteração de memória/CPU nessa VM.

Essa função depende do virtualizador utilizado, para maiores informações, consulte a do-

cumentação do virtualizador.

226

2.15.2.1. Snapshot de volume

Figura 300: Acessando os detalhes de uma VM

Figura 301: Tirando uma snapshot do Volume

Figura 302: Escolhendo o volume que será tirada a snapshot

227

Figura 303: Conﬁgurando a snapshot

2.15.2.2. Snapshot de VM

Figura 304: Tirando uma snapshot da VM

Figura 305: Conﬁgurando a snapshot

228

2.15.2.3. Visualização dos snapshots criados

Figura 306: Acessando as snapshots

Figura 307: Acessando as snapshots de volumes

Figura 308: Acessando as snapshots de VM

229

2.15.2.4. Criação de template a partir de uma snapshot de volume

Figura 309: Acessando os detalhes da snapshot

Figura 310: Criando o template

230

Figura 311: Conﬁgurando os dados do template

2.15.2.5. Criação de volume a partir de uma snapshot de volume

Figura 312: Criando o novo volume

231

Figura 313: Conﬁgurando o novo volume

2.15.2.6. Reversão de snapshot de volume

Figura 314: Revertendo para a snapshot

Figura 315: Conﬁrmando a ação

232

2.15.2.7. Deleção de snapshot de volume

Figura 316: Deletando a snapshot de volume

Figura 317: Conﬁrmando a remoção

2.15.2.8. Criação de snapshot de volume a partir de uma snapshot de VM

Figura 318: Acessando os detalhes da snapshot da VM

233

Figura 319: Criando uma snapshot de volume a partir da snapshot da VM

Figura 320: Conﬁgurando qual volume será extraído

Figura 321: Criando uma snapshot de volume

234

2.15.2.9. Reversão de snapshot de VM

Figura 322: Revertendo a snapshot

Figura 323: Conﬁrmando a ação

2.15.2.10. Deleção de snapshot de VM

Figura 324: Removendo a snapshot de VM

235

Figura 325: Conﬁrmando a ação

2.15.2.11. Conﬁguração de snapshots recorrentes

Essa operação é descrita na página 118.

2.16. Eventos

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.

É possível utilizar os eventos para monitorar tasks, jobs ou processos do

CloudStack, incluindo possíveis erros, em cada um deles.

2.16.1. Níveis de eventos

Os níveis possíveis de evento são:

• INFO: informa quando o processo monitorado ocorreu corretamente.

• WARN: informa quando o processo monitorado encontrou algum pro-

blema, porém ele não é terminal.

• ERROR: informa quando ocorreu um erro terminal no processo monito-

rado.

2.16.2. Busca e ﬁltro de eventos

Para visualizar e buscar os eventos na interface web é necessário:

236

Figura 326: Navegando pelos eventos

A ﬁltragem de eventos por data não é suportada na interface web.

2.16.3. Remoção ou arquivamento de eventos

Ao selecionar o checkbox de um evento, também é possível removê-lo ou

arquivá-lo:

Figura 327: Arquivando ou deletando um evento

Independente da ação selecionada, um pop-up irá surgir para conﬁrmá-la.

237

2.17. Interface de usuário (UI)

Esse tópico tem como objetivo detalhar informações sobre a UI do Apache

CloudStack, além de prover dicas para facilitar a sua usabilidade.

2.17.1. Uso de timezone do browser

Todas as datas manipuladas pelo ACS são armazenadas no banco de dados

no padrão UTC, e, ao consultar os dados via API, os mesmos também retornam

em UTC. Para tornar a experiência do usuário mais agradável, na GUI existe a

opção Use local timezone, que, quando habilitada, faz com que as datas infor-

madas nas APIs e apresentadas para os usuários sejam convertidas para o fuso

horário do navegador.

Figura 328: Habilitando a conﬁguração

Um exemplo de uso dessa opção é na ﬁltragem de estatísticas de VMs. Com

a opção Use local timezone desabilitada, um usuário que esteja no horário de

Brasília, por exemplo, teria que inserir um intervalo de tempo num fuso horá-

rio diferente do dele para obter as estatísticas desejadas. Por exemplo, se o

usuário deseja buscar as estatísticas de uma VM e inserir o horário das 12:00h

às 17:00h sem habilitar a opção, ele receberá as estatísticas correspondentes

ao período das 9:00h às 14:00h, pois os horários seriam interpretados em UTC.

Com a opção habilitada, a UI realiza automaticamente a conversão para o fuso

horário do navegador, permitindo que o usuário busque e visualize as estatís-

ticas sem realizar conversões manuais de fuso horário.

238

Essa opção também inﬂuencia na manipulação das tarifas e relatórios do

Quota.

2.17.2. Documentação na UI

A maioria das telas e/ou páginas da interface web do CloudStack possui pe-

quenos ícones de ajuda, os quais ao passar o mouse por cima, pode-se obter

uma pequena descrição sobre aquele componente que pode ser bastante útil.

Também existem ícones em formato de ponto de interrogação (?) que quando

clicados abrem uma aba no navegador na seção da documentação oﬁcial do

CloudStack que aborda aquele componente.

Figura 329: Exemplo de popup com os ícones de ajuda

2.18. Service oﬀerings

Para que seja possível criar VMs, os virtualizadores exigem especiﬁcações

das características delas, como quantidade de CPU, tamanho da memória ou

do disco a ser alocado, entre outras deﬁnições. No CloudStack, essas caracte-

rísticas das VMs são agrupadas e padronizadas em forma de ofertas de serviço,

a ﬁm de facilitar a especiﬁcação das VMs, mapear o uso dos recursos e, se for

o caso, aplicar cobrança sobre a utilização dos mesmos. O CloudStack divide

as ofertas de serviços em dois segmentos:

• Disk oﬀerings

• Compute oﬀerings

239

2.18.1. Disk oﬀerings

Disk oﬀerings são as ofertas de serviço destinadas aos recursos de armaze-

namento de uma VM. Máquinas virtuais criadas a partir de um template uti-

lizarão as disk oﬀerings para criação de discos extras, já as criadas com ISOs

necessitarão de uma disk oﬀering para criação do root disk.

2.18.1.1. Criação de disk oﬀering

Para criar uma disk oﬀering:

Figura 330: Iniciando a criação de uma nova disk oﬀering

Ao clicar no botão Add Disk Oﬀering, será aberto um formulário para preen-

chimento das informações:

240

Figura 331: Criando a nova disk oﬀering

241

Explicação de alguns campos do formulário:

• Tipos de provisionamento:

1. Thin Provisioning: discos desse tipo serão alocados com o mínimo

necessário e poderão crescer, de acordo com a necessidade, até o

limite estabelecido.

2. Sparse Provisioning: discos desse tipo já iniciarão alocados com o ta-

manho estabelecido na oferta, no entanto, eles poderão conter da-

dos antigos. A criação dos mesmos será rápida, pois os dados antigos

não serão apagados ou sobrescritos, porém será necessário fazê-lo

antes de escrever novos dados. A performance desse tipo de disco

será baixa para as primeiras escritas.

3. Fat Provisioning: discos desse tipo já iniciarão alocados com o tama-

nho estabelecido na oferta e todo o espaço utilizado será sobres-

crito, apagando quaisquer dados que estejam nos blocos. Suas cria-

ções serão mais demoradas em relação ao sparse provisioning, devido

ao processo de limpeza dos dados antigos, no entanto, sua perfor-

mance nas primeiras escritas será superior.

• Disk Size Strictness: Quando o valor for verdadeiro, o tamanho do volume

não pode ser alterado.

• QoS Type: deﬁne o QoS para os discos. Para utilizar o QoS de hypervisor

ou de storage, é necessário que eles suportem essa funcionalidade.

1. None: Por padrão as ofertas não a implementam.

2. Hypervisor: Deﬁne taxas de leitura e escrita pelo hypervisor. Depen-

dendo do hypervisor, algumas deﬁnições de QoS podem não estar

implementadas, portanto, é necessário validá-las antes de aplicá-las

em produção.

3. Storage: Deﬁne um mínimo e um máximo de IOPS no lado do storage.

242

• Hypervisor Snapshot Reserve: Permite reservar espaços para snapshots além

do disco de dados. Medido em porcentagem em relação ao data disk, o

valor ﬁnal reservado é a porcentagem escolhida mais o tamanho do pró-

prio data disk. Isto não se aplica ao KVM.

• Storage Tags: As storage tags serão utilizadas para direcionar os volumes

para os storages compatíveis.

• Sobre o acesso:

1. Public: Deﬁne se a oferta de serviço estará disponível para todos os

domínios ou será de uso restrito. Selecione sim para o acesso em

todos os domínios.

2. Domain: Essa opção só aparecerá quando Public estiver desmarcado.

Essa opção determina os domínios que utilizarão a oferta.

3. Zone: Deﬁne em quais zonas a oferta estará disponível.

2.18.1.2. Edição de disk oﬀering

Após criada, poucos atributos da disk oﬀering podem ser alterados.

• Editar:

Figura 332: Iniciando a edição da disk oﬀering

243

Figura 333: Editando a disk oﬀering

• Atualizar acesso:

Figura 334: Iniciando a atualização de acesso da disk oﬀering

Figura 335: Atualizando o acesso da disk oﬀering

• Alterar ordem:

244

Figura 336: Alterando ordem da disk oﬀering

2.18.1.3. Exclusão de disk oﬀering

Para excluir uma disk oﬀering basta acessar a mesma e clicar no ícone de lixeira:

Figura 337: Iniciando a exclusão da disk oﬀering

Figura 338: Excluindo a disk oﬀering

Caso haja volumes com a disk oﬀering, eles continuarão funcionando nor-

malmente, bem como os processos de migração e reinício da VM, pois o Cloud-

Stack copia as características da disk oﬀering para o disco, no entanto não será

possível criar novos volumes com ela.

Mais informações na documentação oﬁcial.

245

2.18.2. Compute oﬀerings

Compute oﬀerings são as ofertas destinadas aos recursos computacionais

de uma VM, como CPU e memória RAM. Uma compute oﬀering também pos-

sui uma disk oﬀering, que deﬁne as características do root disk da VM (quando

criada a partir de um template).

No momento de criação de uma compute oﬀering, a mesma será asssoci-

ada a uma disk oﬀering. Este vínculo pode ocorrer de duas maneiras. Uma

delas é através de especiﬁcações dos discos, o tipo de armazenamento e as

tags, podendo ser incluídas diretamente na oferta de cálculo. A segunda forma

é conectar uma disk oﬀering a uma compute oﬀering, sendo assim a oferta de

disco será utilizada para o Root Disk durante a criação da instância. Vale ressal-

tar que os usuários poderão utilizar uma oferta de disco diferente para o root

disk durante o processo de criação da VM.

2.18.2.1. Criação de compute oﬀering

Para criar uma compute oﬀering:

246

Figura 339: Iniciando a criação de uma nova compute oﬀering

Ao clicar no botão Add Compute Oﬀering, será aberto um formulário para

preenchimento das informações:

247

Figura 340: Criando a nova compute oﬀering - 1 - continua

248

Explicação de alguns campos do formulário:

• Compute Oﬀering Type: trata-se de alternativas que controlam a autono-

mia com que o usuário ﬁnal tem para criar uma disk oﬀering. São três as

opções:

1. Fixed oﬀerings: são ofertas com valores de CPU (cores e velocidade) e

memória ﬁxos. Todas as VMs criadas com essa oferta terão a mesma

conﬁguração.

2. Custom constrained oﬀerings: nesse tipo de oferta o usuário ﬁnal

utilizará os recursos alocados dentro de uma faixa valores deﬁnida

pelo administrador. O usuário que utilizar essa oferta terá de sele-

cionar um valor entre os limites deﬁnidos para cada parâmetro no

momento da criação da VM.

3. Custom unconstrained oﬀerings: são ofertas sem limites. Qualquer

valor pode ser informado no momento de criação da VM, desde que

ele esteja dentro do disponível para uso.

• CPU cores: é a quantidade de núcleos alocados para atender uma VM

que utiliza essa oferta de serviço. Se a opção Custom co nstrained offe

rings estiver escolhida, é necessário determinar a quantidade mínima e

máxima de cores na criação da oferta. Se a opção Custom unconstrained

for escolhida, este campo não será exibido.

• CPU (in MHz): determina a velocidade dos núcleos. Essa deﬁnição só é

utilizada se o limite da CPU estiver ativo. Se a opção Custom Unconstrain

ed for escolhida, este campo não será exibido.

• Memory (in MB): deﬁne a quantidade de memória em megabytes que a

VM do sistema deve ser alocada. Se for selecionada a opção Custom co

nstrained, será necessário informar a quantidade mínima e máxima de

249

memória durante a criação da oferta. Se for selecionada Custom uncons

trained, este campo não aparecerá.

• Host tags: serão utilizadas para direcionar as VMs para os hosts compatí-

veis.

• Network Rate: deﬁne a transferência de dados em MB por segundo.

• Oﬀer HA: Se sim, a VM será monitorada e em caso de falha do host, ela

será reiniciada em outro host disponível.

• Dynamic Scaling Enabled: se escolhida, a CPU e a memória da instância

podem ser escalonadas dinamicamente.

• CPU Cap: limita o uso de CPU mesmo que haja recursos disponíveis.

• Volatile: VMs criadas com uma compute oﬀering volátil terão seus root

disks restaurados ao estado inicial toda vez que for realizado o boot das

mesmas.

• Deployment Planner: Algoritmo utilizado pelo o CloudStack para escolha

de qual host implantar VMs criadas com essa oferta de serviço.

1. First Fit: escolhe o host que tiver capacidade suﬁciente para suportar

os requisitos da instância.

2. User Dispersing: dispersa uniformemente as instâncias pertencen-

tes à mesma conta em diferentes clusters ou pods.

3. User Concentrated: concentra instâncias pertencentes à mesma conta

num único pod.

4. Implicit Dedication: implantará instâncias que são dedicadas a um

domínio ou conta especíﬁca. Se você escolher esse planejador, tam-

bém deverá escolher um valor para o parâmetro

planner mode.

5. Bare Metal: é usado com host bare metal.

250

• Planner Mode: esta opção só estará disponível se for selecionada implic

it dedication. O planner mode determinará como o deploy das instâncias

será feito na infraestrutura privada.

1. Strict: Um host não será compartilhado entre contas distintas.

2. Preferred: A instância será implantada em uma infraestrutura dedi-

cada, se possível. Caso contrário, a instância pode ser implementada

numa infraestrutura partilhada.

• GPU: Atribui uma GPU física, ou parte dela, à uma instância. Isso faz com

que aplicações gráﬁcas sejam executadas na VM. É mostrada uma lista de

GPU disponíveis.

2.18.2.2. Edição de compute oﬀering

Após criada a compute oﬀering, poucos atributos da mesma podem ser altera-

dos.

• Editar:

Figura 341: Iniciando a edição da compute oﬀering

Figura 342: Editando a compute oﬀering

251

• Atualizar acesso:

Figura 343: Iniciando a atualização de acesso da compute oﬀering

Figura 344: Atualizando o acesso da compute oﬀering

• Alterar ordem:

Figura 345: Alterando a ordem da compute oﬀering

2.18.2.3. Exclusão de compute oﬀering

Para excluir uma compute oﬀering basta acessar a mesma e clicar no ícone de

lixeira:

Figura 346: Iniciando a exclusão da compute oﬀering

252

Figura 347: Excluíndo a compute oﬀering

Caso haja VMs rodando com a compute oﬀering, elas continuarão funcio-

nando normalmente, pois o CloudStack copia as características da compute of-

fering para a VM, no entanto não será possível criar novas com ela. No live

scaling da VM que a utiliza, será necessário trocá-la.

2.18.2.4. Alteração de compute oﬀering da VM

Também é possível realizar a troca da compute oﬀering utilizada por uma VM

já existente. Há duas formas de realizar essa troca: via UI e via CloudMonkey,

sendo que em ambos os casos é necessário que a VM esteja parada.

• Via UI:

Figura 348: Iniciando a alteração da compute oﬀering

253

Figura 349: Alterando a compute oﬀering

Figura 350: Alterando a compute oﬀering

Após a realização desses passos a compute oﬀering da VM será atualizada.

• Via CloudMonkey: Pode-se utilizar as APIs scaleVirtualMachine ou chan-

geServiceForVirtualMachine

. Nessa situação, ambas possuem o mesmo

funcionamento e obterão o mesmo resultado. Basta utilizar o comando:

scale virtualmachine id=<VM id> serviceofferingid=<compute offering id>

A sintaxe utilizada pelas APIs é a mesma, trocando apenas a chamada de s c a l e virtualma

chine por change serviceforvirtualmachine.

254

Ao executar esse comando com sucesso, o resultado do mesmo apresen-

tará diversas informações relacionadas à VM alterada, inclusive a nova

compute oﬀering deﬁnida.

{

"virtualmachine": {

"account": "admin",

"affinitygroup": [],

"cpunumber": 1,

"cpuspeed": 1000,

"created": "2022-03-08T17:06:23+0000",

"details": {

"Message.ReservedCapacityFreed.Flag": "true",

"rootDiskController": "osdefault"

"displayname": "VM-ea2c34dd-a8a9-4b6a-b6c4-9404e034f3b7",

...

"serviceofferingid": "ab647165-7a0a-4984-8452-7bfceb036528",

"serviceofferingname": "Small Instance",

"state": "Stopped",

"tags": [],

"templatedisplaytext": "Macchinina - Light SO",

"templateid": "b81aab72-2c37-466e-b53f-bdaf398322fa",

"templatename": "Macchinina",

"userid": "af1818b9-26de-11ec-8dcf-5254005dcdac",

"username": "admin",

"zoneid": "8b2ceb16-a2f2-40ea-8968-9e08984bdb17",

"zonename": "sc-floripa-01"

}

Ao realizar a alteração da compute oﬀering de uma VM, é importante levar

em conta suas host tags e storage tags, além das tags da compute oﬀering dese-

jada. Isso porque serão apresentadas como opções para scale da VM apenas

as compute oﬀerings compatíveis, ou seja, apenas as compute oﬀerings que pos-

suam as mesmas tags que a VM ou que não possuam restrição de tags.

Mais informações na documentação oﬁcial.

2.18.3. Network oﬀerings

Network oﬀerings são as ofertas destinadas a recursos de rede, como DNS,

DHCP, ﬁrewall, load balancing, entre outros serviços.

2.18.3.1. Criação de network oﬀering

Para criar uma network oﬀering:

255

Figura 351: Iniciando a criação de uma nova network oﬀering

Ao clicar no botão Add Network Oﬀering, será aberto um formulário para

preenchimento das informações:

Figura 352: Criando a nova network oﬀering - 1 - continua

É possível criar três tipos de redes:

256

• Isolated: redes destinadas a apenas uma conta.

• L2: redes sem serviços. Ao utilizar esse tipo de rede, o usuário ﬁnal deve

realizar o gerenciamento de IPs ou devem ser utilizados IPs estáticos. Esse

tipo de rede possui uma limitação a nível lógico, a qual permite que ela

seja criada apenas para uma conta, contudo, quando é necessário que

diversas contas a utilizem, é possível criar uma rede do tipo shared e sem

serviços, simulando uma rede L2 (ao realizar a criação de uma rede com

essa oferta, os dados nos campos de IPv4 são obrigatórios pelo Cloud-

Stack, contudo eles não serão utilizados, portanto pode ser informado

qualquer coisa).

• Shared: redes que podem ser compartilhadas entre contas do mesmo

domínio.

A opção Specify VLAN permite que o administrador da nuvem atribua uma

VLAN especíﬁca à rede criada. É importante que esta VLAN especíﬁca não faça

parte da faixa disponível para alocação dinâmica, descrita na rede física de trá-

fego Guest (pode ser consultada na aba Physical network da zona correspon-

dente). Se não for marcada, o CloudStack atribuirá uma VLAN de maneira ale-

atória dentre as disponíveis quando a rede passar para o estado Implemented

e a removerá quando a rede não estiver mais em uso (estado Allocated). Para

redes L2, a VLAN é atribuída automaticamente.

Redes com Network oﬀerings marcadas como Persistent serão implementa-

das sem a necessidade de adicionar uma VM à rede.

257

Figura 353: Criando a nova network oﬀering - 2

• Com o Internet Protocol, é possível especiﬁcar qual versão de IP a oﬀe-

ring irá suportar. O CloudStack oferece duas opções: IPv4 (padrão) e Dual

Stack. O Dual Stack permite que a oﬀering suporte tanto IPv4 quanto IPv6.

• As opções Promiscuous Mode, MAC Address Changes e Forged Transmits são

destinadas à Nested Virtualization, no VMWare.

• Os Supported Services são os serviços disponíveis para seleção. Cada ser-

viço possui uma conﬁguração, sendo possível escolher o provedor para

cada um deles.

• A partir da compute oﬀering, é possível informar a service oﬀering que o

VR irá utilizar. Para conseguir usar essa funcionalidade, é preciso que ao

menos um dos serviços a seguir esteja habilitado na lista de Supported

Services: VPN, DHCP, DNS, Firewall, LB, UserData, SourceNat, StaticNat,

PortForwarding.

258

• Redes com Conserve Mode irão alocar os recursos somente quando a pri-

meira VM for criada.

• É possível marcar a opção Enable network oﬀering para que a network of-

fering criada já esteja pronta para uso. Caso contrário, será necessário

habilitá-la antes de utilizá-la.

2.18.3.2. Edição de network oﬀering

Após criada, poucos atributos da network oﬀering podem ser alterados.

• Editar:

Figura 354: Iniciando a edição da network oﬀering

Figura 355: Editando a network oﬀering

• Habilitar/desabilitar a oferta:

259

Figura 356: Iniciando a desabilitação da network oﬀering

Figura 357: Desabilitando a network oﬀering

Se houver alguma rede criada e a oferta for desabilitada, a rede continu-

ará funcionando normalmente, no entanto não será possível criar novas

redes.

• Atualizar acesso:

Figura 358: Iniciando a atualização de acesso da network oﬀering

260

Figura 359: Atualizando o acesso da network oﬀering

• Alterar ordem:

Figura 360: Alterando ordem da network oﬀering

2.18.3.3. Exclusão de network oﬀering

Para excluir uma network oﬀering basta acessar a mesma e clicar no ícone de

lixeira:

261

Figura 361: Iniciando a exclusão da network oﬀering

Figura 362: Excluíndo a network oﬀering

Caso haja redes com a network oﬀering ou ela for default, não será possível

excluí-la, no entanto é possível desabilitá-la.

Mais informações na documentação oﬁcial.

2.18.4. VPC Oﬀerings

VPC oﬀerings são as ofertas destinadas ao VPC (mais informações sobre VPC

na seção 2.7). Elas são similares à network oﬀerings (seção 2.18.3)

2.18.4.1. Criação de VPC oﬀering

Para criar uma VPC oﬀering:

262

Figura 363: Iniciando a criação de uma nova VPC oﬀering

Ao clicar no botão Add VPC Oﬀering, será aberto um formulário para preen-

chimento das informações:

263

Figura 364: Criando a nova VPC oﬀering

Os Supported Services são os serviços disponíveis para seleção. Cada serviço

possui uma conﬁguração, sendo possível escolher o provedor para cada um

deles. Em sua maioria, existe apenas o provedor VpcVirtualRouter.

O campo Compute oﬀering é explicado na Seção 2.18.3.

Em seguida, é possível marcar a opção Enable VPC oﬀering para que a VPC of-

fering criada já esteja pronta para uso. Caso contrário, será necessário habilitá-

la antes de utilizá-la.

2.18.4.2. Edição de VPC oﬀering

Após criada, poucos atributos da VPC oﬀering podem ser alterados.

• Editar:

264

Figura 365: Iniciando a edição da VPC oﬀering

Figura 366: Editando a VPC oﬀering

• Habilitar/desabilitar a oferta:

Figura 367: Iniciando a desabilitação da VPC oﬀering

Figura 368: Desabilitando a VPC oﬀering

265

Se houver algum VPC criado e a oferta for desabilitada, o VPC continuará

funcionando normalmente, no entanto não será possível criar novos.

• Atualizar acesso:

Figura 369: Iniciando a atualização de acesso da VPC oﬀering

Figura 370: Atualizando o acesso da VPC oﬀering

• Alterar ordem:

Figura 371: Alterando a ordem da VPC oﬀering

2.18.4.3. Exclusão de VPC oﬀering

Para excluir uma VPC oﬀering basta acessar a mesma e clicar no ícone de lixeira:

266

Figura 372: Iniciando a exclusão da VPC oﬀering

Figura 373: Excluíndo a VPC oﬀering

Caso haja VPCs com a VPC oﬀering ou ela for default, não será possível excluí-

la, no entanto é possível desabilitá-la.

267

3. CloudMonkey, API e outros

O CloudMonkey é uma ferramenta de linha de comando (Command Line

Interface - CLI) escrito em Go e utilizado para interação com a API do CloudStack.

O mesmo se trata de um projeto open-source, que pode ser acessado através

do seu github.

Os passos para a instalação, conﬁguração e uso do CloudMonkey se encon-

tram nas próximas subseções.

3.1. Instalação

O CloudMonkey possui duas formas de instalação distintas, uma para usuá-

rios de Linux/Mac e outra para usuários de Windows:

• Linux/Mac:

É necessário realizar o download da última release lançada, escolhendo o

binário correspondente à plataforma utilizada, e copiá-lo para um diretó-

rio que faça parte da variável $PATH, como /usr/local/bin. Via terminal:

sudo wget <file link> -O /usr/local/bin/cmk

sudo chmod +x /usr/local/bin/cmk

• Windows:

No link de releases citado anteriormente, é necessário realizar o download

do executável (.exe) correspondente à plataforma utilizada e copiá-lo para

um diretório que faça parte dos diretórios com executáveis do Windows,

como C:\Windows\System32\. Após, é necessário veriﬁcar a execução do

arquivo cmk.exe.

3.2. Conﬁguração

Por padrão, o CloudMonkey criará um perﬁl inicial que terá algumas cre-

denciais padrões do CloudStack. Para conﬁgurar o CloudMonkey, existe o co-

mando set:

268

$ cmk

Apache CloudStack CloudMonkey 6.1.0

Report issues: https://github.com/apache/cloudstack-cloudmonkey/issues

(localcloud) > set url http://myprovider.cloud/client/api

(localcloud) > set username myusername

(localcloud) > set password mypassword

(localcloud) > sync

Discovered 622 APIs

Caso se queira criar um novo perﬁl, pode-se usar o mesmo comando set:

(localcloud) > set profile newprofile

(newprofile) > set url http://myprovider.cloud/client/api

(newprofile) > set username myusername

(newprofile) > set password mypassword

(newprofile) > sync

Discovered 622 APIs

Pode ser necessário também desabilitar a conﬁguração de veriﬁcação de

certiﬁcado SSL caso seja usado HTTP e não HTTPS:

(localcloud) > set verifycert false

Ao realizar o login com outro usuário, é recomendado sempre utilizar o co-

mando sync, a ﬁm de buscar as APIs às quais esse usuário possui acesso. Para

retornar ao perﬁl anterior, basta executar o comando:

(newprofile) > set profile localcloud

3.3. Uso

O CloudMonkey realiza chamadas para a API do CloudStack, portanto, para

utilizá-lo, é necessário ter um conhecimento prévio do que se deseja fazer e

quais APIs serão necessárias. Para isso o CloudMonkey possui alguns facilita-

dores:

• Veriﬁcação das APIs disponíveis:

(localcloud) > list apis

{

"api": [

{

"description": "Creates VPC offering",

"isasync": true,

"name": "createVPCOffering",

"params": [

{

269

"description": "desired service capabilities as part of vpc offering",

"length": 255,

"name": "servicecapabilitylist",

"required": false,

"since": "4.4",

"type": "map"

...

}

"count": 622

}

• Autocomplete: ao utilizar a tecla TAB, é possível obter uma lista de suges-

tões de comandos.

Figura 374: Utilizando o autocomplete

270

Figura 375: Veriﬁcando o autocomplete para um comando especíﬁco

Figura 376: Veriﬁcando o autocomplete para uma API especíﬁca

• Detalhes sobre uma API: é possível obter uma descrição detalhada de

uma API especíﬁca com a ﬂag -h:

271

Figura 377: Utilizando o -h para obter ajuda

Ou através do comando help:

(localcloud) > help createAccount

Uma vez que sabe-se o que deve ser feito, basta realizar a chamada para

API via CloudMonkey:

272

Figura 378: Realizando uma chamada

273

Figura 379: Fazendo deploy de uma VM via CloudMonkey

Para informações mais detalhadas sobre o uso do CloudMonkey, consulte

a wiki do projeto.

274

4. 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) e contabilização de uso

(Quota), sendo o segundo complementar ao primeiro.

O mecanismo Usage realiza periodicamente a identiﬁcação e a coleta dos

dados de uso de recursos no ambiente. Já o mecanismo Quota é um plugin que

permite gerenciar um modelo de tarifas sobre o consumo de recursos compu-

tacionais.

Essa seção descreve como acessar os relatórios de uso de recursos do Usage,

e as tarifas ativas e os relatórios do Quota.

4.1. Usage

4.1.1. Relatórios de uso de recursos

Os relatórios de uso dos recursos poderão ser acessados através da API lis

tUsageRecords, como mostrado a seguir:

(admin) > list usagerecords startdate='yyyy-MM-dd'T'HH:mm:ssZ' enddate='yyyy-MM-dd'T'HH:mm:ssZ'

Esse comando irá retornar uma lista de diversos relatórios com a seguinte

estrutura:

...

{

"account": "<conta>",

"accountid": "<Identificador da conta>",

"description": "<Descrição do relatório>",

"domain": "<nome do dominio>",

"domainid": "<ID do dominio>",

"enddate": "yyyy-MM-ddTHH:59:59+0000",

"rawusage": "depende do usagetype",

"startdate": "yyyy-MM-ddTHH:00:00+0000",

"tags": [<conjunto de tags>],

"usage": "<depende do usagetype>",

"usagetype": <tipo de recurso contabilizado>,

"zoneid": "<ID da zona>"

...

Ao lançar um evento no Cloustack, ele não ﬁcará visível nessas tabelas de

requisição API de forma síncrona, e sim periodicamente, após a atualização dos

dados com base no tempo escolhido pelo operador nas conﬁgurações globais.

275

4.2. Quota

4.2.1. Tarifas

Para visualizar as tarifas ativas para a conta de usuário deve-se:

Figura 380: Listagem das tarifas ativas

Outras informações das tarifas, como nome, descrição e valor, podem ser

acessadas na página de detalhes de cada tarifa.

Figura 381: Detalhes das tarifas

4.2.2. Relatórios

Ao selecionar o sub-menu Summary e selecionar a conta de usuário de-

sejada, é possível visualizar os detalhes e os relatórios do Quota referentes a

conta.

276

Figura 382: Acessando detalhes e relatórios de uma conta

4.2.2.1. Créditos

Para visualizar o histórico de adição/remoção de créditos (quem adicionou,

quanto adicionou, quando adicionou), basta navegar até a aba Credits:

Figura 383: Listagem de créditos

Essa listagem também pode ser realizada via CloudMonkey. Exemplo:

(admin) > quota creditslist accountid=af16aaed-26de-11ec-8dcf-5254005dcdac domainid=52d83793-26de-11ec

-8dcf-5254005dcdac

{

277

"count": 3,

"credit": [

{

"credit": -192.87,

"creditedon": "2023-10-04T13:05:13+0000",

"creditorid": "af16aaed-26de-11ec-8dcf-5254005dcdac",

"creditorname": "admin",

"currency": "$",

"postingdate": "2023-10-04T13:05:06+0000"

{

"credit": 350,

"creditedon": "2023-10-04T13:20:24+0000",

"creditorid": "af16aaed-26de-11ec-8dcf-5254005dcdac",

"creditorname": "admin",

"currency": "$",

"postingdate": "2023-10-04T13:20:24+0000"

{

"credit": -25,

"creditedon": "2023-10-05T15:56:58+0000",

"creditorid": "af16aaed-26de-11ec-8dcf-5254005dcdac",

"creditorname": "admin",

"currency": "$",

"postingdate": "2023-10-05T15:56:58+0000"

}

]

}

4.2.2.2. Uso de recursos

A aba Quota usage apresenta dados de uso dos recursos no período ﬁltrado:

278

Figura 384: Listagem de uso de recurso

Via CloudMonkey a consulta deve ser realizada conforme o exemplo a se-

guir:

(admin) > quota statement account=admin domainid=52d83793-26de-11ec-8dcf-5254005dcdac startdate=2023-1

0-01T00:00:00+0000 enddate=2023-10-05T13:55:01+0000

{

"statement": {

"account": "admin",

"accountid": "af16aaed-26de-11ec-8dcf-5254005dcdac",

"currency": "$",

"domain": "52d83793-26de-11ec-8dcf-5254005dcdac",

"enddate": "2023-10-05T13:55:01+0000",

"quotausage": [

{

"name": "RUNNING_VM",

"quota": 0,

"type": 1,

"unit": "Compute*Month"

{

"name": "ALLOCATED_VM",

"quota": 195,

"type": 2,

"unit": "Compute*Month"

...outros recursos...

{

279

"name": "NETWORK",

"quota": 0,

"type": 30,

"unit": "Compute*Month"

{

"name": "BACKUP_OBJECT",

"quota": 0,

"type": 31,

"unit": "GB*Month"

}

"startdate": "2023-10-01T00:00:00+0000",

"totalquota": 202.64381816

}

Também é possível realizar a consulta detalhada do consumo:

Figura 385: Listagem detalhada de uso de recurso

Via CloudMonkey:

(admin) > quota statement account=admin domainid=52d83793-26de-11ec-8dcf-5254005dcdac startdate=2023-1

0-04T00:00:00+0000 enddate=2023-10-05T13:55:01+0000 showresources=true type=6

{

"statement": {

280

"account": "admin",

"accountid": "af16aaed-26de-11ec-8dcf-5254005dcdac",

"currency": "$",

"domain": "52d83793-26de-11ec-8dcf-5254005dcdac",

"enddate": "2023-10-05T13:55:01+0000",

"quotausage": [

{

"name": "VOLUME",

"quota": 7.64381816,

"resources": [

{

"displayname": "usage",

"quotaconsumed": 4.805108,

"removed": false,

"resourceid": "f710ed0f-c234-4c31-89ae-de23c9d8779f"

{

"displayname": "DATA-220",

"quotaconsumed": 2.83871016,

"removed": false,

"resourceid": "e4727094-2571-4ebb-aca7-5cc97778fde0"

}

"type": 6,

"unit": "GB*Month"

}

"startdate": "2023-10-04T00:00:00+0000",

"totalquota": 7.64381816

}\Figure{0.35}

}

4.2.2.3. Balanço

A aba

Daily Quota bal a nce apresenta os balanços diários (crédito + uso de re-

cursos) referentes ao período ﬁltrado. O balanço é fechado diariamente e re-

presenta um somatório dos dados anteriores, sendo o balanço mais recente

sempre referente ao dia anterior.

Exemplo: diariamente é gerado R$100,00 de uso de recurso. Ao ﬁnal do

primeiro dia, o balanço será -R$100,00. Ao ﬁnal do segundo dia, o balanço

será -R$200,00. Ao ﬁnal do terceiro dia, o balanço será -R$300,00 e assim por

diante. Ao realizar a busca ﬁltrando entre o terceiro e quinto dia, os balanços

retornados serão -R$300,00 (terceiro dia), -R$400,00 (quarto dia) e -R$500,00

(quinto dia).

281

Figura 386: Listagem do balanço do Quota

Via CloudMonkey:

(lab) > quota balance account=oliver domainid=7efa7a0c-8f43-4564-b8cc-d709424dc69a startdate=2022-04-1

0 enddate=2022-04-16

{

"balance": {

"currency": "$",

"dailybalances":

[

{

"balance": 99.67,

"date": "2022-04-10T00:00:00+0000"

{

"balance": 99.6,

"date": "2022-04-11T00:00:00+0000"

{

"balance": 99.53,

"date": "2022-04-12T00:00:00+0000"

{

"balance": 99.47,

"date": "2022-04-13T00:00:00+0000"

{

"balance": 94.23,

"date": "2022-04-14T00:00:00+0000"

{

"balance": 88.96,

282

"date": "2022-04-15T23:59:59+0000"

{

"balance": 83.7,

"date": "2022-04-16T23:59:59+0000"

}

]

}

283

5. Cloud-init

O cloud-init é um software open source criado para automatizar a iniciali-

zação e conﬁguração de sistemas operacionais durante o boot, com foco em

máquinas virtuais para nuvem. Dentre suas diversas funcionalidades estão:

gerência de senhas, injeção de chaves SSH e injeção de metadados de usuá-

rios. Ele é suportado pelos maiores sistemas de orquestração de nuvem, como

Azure, Google Compute Engine, OpenStack e CloudStack.

5.1. Etapas de inicialização

O cloud-init possui cinco etapas de inicialização, sendo elas:

• Generator: disponível apenas para sistemas que utilizam systemd, essa

etapa é a primeira a ser executada e deﬁne se o cloud-init deve ser exe-

cutado durante o boot. Para desabilitar a execução do cloud-init no boot

do sistema operacional, basta que exista o arquivo / etc/cloud/cloud-init.

disabled.

• Local: etapa que irá localizar os datasources locais e aplicar as conﬁgura-

ções de rede no sistema.

• Network: essa etapa é executada após a Local e requer que as conﬁgu-

rações de rede estejam funcionando. Nela serão processados todos os

módulos informados na seção cloud-init-modules do arquivo /etc/cloud/c

loud.cfg. Essa etapa realiza as conﬁgurações iniciais da máquina virtual,

como a deﬁnição do hostname e a execução do comando mount.

• Conﬁg: essa etapa é executada após a Network e nela serão processados

todos os módulos informados na seção cloud-conﬁg-modules do arquivo /

etc/cloud/cloud.cfg. Ela é destinada a módulos de conﬁguração indepen-

dentes, que não afetam outros módulos, como a troca de senha de um

usuário e a localidade e o fuso-horário do sistema operacional.

284

• Final: última etapa a ser executada no boot do sistema operacional. Nela

serão processados todos os módulos informados na seção cloud-ﬁnal-

modules do arquivo /etc/cloud/cloud.cfg. Ela é destinada a processos que

são geralmente executados pelo usuário, como atualização e instalação

de pacotes e execução de scripts.

Caso o usuário queira executar scripts próprios, ele deve colocar os mes-

mos no diretório /var/lib/cloud/scripts, o qual possui três subdiretórios

representando a frequência de execução dos mesmos:

– per-boot: scripts dentro desse diretório serão executados toda vez

que for feito boot no sistema operacional.

– per-instance: scripts dentro desse diretório serão executados apenas

na primeira vez que for feito boot no sistema operacional. Mais in-

formações na seção 5.2.

– per-once: scripts dentro desse diretório serão executados apenas na

primeira vez, mesmo se o sistema operacional sofrer alterações. Mais

informações na seção 5.2.

5.2. Frequência de execução

O cloud-init possui três frequências de execução dos módulos e scripts, sendo

elas:

• per-boot/always: executa toda vez que for feito boot.

• per-instance: executa apenas na primeira vez que for feito boot no sis-

tema operacional. Para determinar se é o primeiro boot do sistema ope-

racional, o cloud-init guarda um cache para futuras validações. Se o cache

existe, signiﬁca que o cloud-init já foi executado uma vez, portanto não é o

primeiro boot. Esse comportamento pode causar inconsistências quando

é feita uma imagem a partir dessa instância, portanto o cloud-init adota

um comportamento padrão, chamado check, o qual valida o atual instance

285

ID com o gravado no cache. Caso sejam diferentes, ele irá considerar como

primeiro boot. Também existe o comportamento trust, o qual não valida

os instance ID. O instance ID normalmente é deﬁnido pelo orquestrador

quando uma nova máquina virtual é criada. Também é possível limpar o

cache manualmente para redeﬁnir o primeiro boot.

• per-once: executa apenas na primeira vez que for feito boot no sistema

operacional, mesmo se houver alterações no instance ID. Esse compor-

tamento é similar ao trust da frequência per-instance. Recursos sob essa

frequência podem ser reexecutados caso seja feita limpeza manual do

cache e o reboot no sistema operacional.

Para limpar manualmente o cache do cloud-init, basta executar o comando:

cloud-init clean

5.3. DataSources conhecidos

O cloud-init possui integração com os maiores sistemas de orquestração de

nuvem, como Azure, Google Compute Engine, OpenStack e CloudStack (a lista

completa pode ser encontrada em known-sources). Cada um deles opera de

uma forma única e possui suas próprias conﬁgurações. Para o CloudStack, por

exemplo, ele necessita que a máquina virtual esteja em uma rede que possua

um virtual router, pois é dele que o cloud-init irá recuperar as informações e

metadados dos usuários.

5.4. Módulos

O cloud-init possui diversas funcionalidades, como gerência de senhas, in-

jeção de chaves SSH e injeção de metadados de usuários (a lista completa pode

ser encontrada em modules). Caso o usuário necessite de alguma funcionali-

dade que o cloud-init não possui, ele ainda pode criar scripts personalizados

(mais informações na seção 5.1). Para cada script é necessário informar, na

primeira linha, qual programa irá executá-lo. Por exemplo:

286

#!/bin/bash

É necessário estar atento às frequências de execução dos módulos aplica-

dos. Módulos como ssh e set-passwords executam, por padrão, na frequência

per-instance, ou seja, irão executar somente no primeiro boot. Caso seja neces-

sário alterar esta frequência, o cloud-init permite sobrescrevê-la da seguinte

forma:

...

cloud_init_modules:

...

- update_etc_hosts

- ca-certs

- rsyslog

- users-groups

- [ ssh, always ]

...

5.5. Criação de uma imagem personalizada

É possível criar uma imagem personalizada via CloudStack reproduzindo os

seguintes passos:

• Criar uma VM a partir de uma ISO, como descrito nas seções 2.10 e 2.3.

• Com o sistema operacional instalado e conﬁgurado, instalar o pacote do

cloud-init.

• Por padrão, o cloud-init tenta buscar dados de todos os datasources. Caso

ele não consiga por um, tenta por outro. No entanto, é possível limitar os

datasources que o cloud-init irá utilizar. Como essa imagem será desti-

nada ao CloudStack, os datasources serão limitados a ele. Para isso, no

diretório /etc/cloud/cloud.cfg.d/, deve ser criado o arquivo 99_cloudstack

.cfg com os seguintes dados:

datasource:

CloudStack: {}

None: {}

datasource_list: [CloudStack, None]

287

A conﬁguração limitará os datasources para CloudStack e None. Caso os

dados não sejam encontrados pelo CloudStack, eles não serão buscados

de mais nenhum. As demais conﬁgurações também podem ser criadas

no mesmo diretório e serão lidas em ordem alfabética pelo cloud-init, no

entanto, por padrão, elas serão deﬁnidas no arquivo /et c/cloud/cloud.cf

• No arquivo /etc/cloud/cloud.cfg, na seção users, podem ser deﬁnidos usuá-

rios a serem criados. Por padrão, já existe a entrada default, que refe-

rencia a entrada default_user, na seção system_info. Os valores do de-

fault_user podem ser alterados para condizerem com o usuário desejado.

• No arquivo /etc/cloud/cloud.cfg, ao ser instalado o pacote do cloud-init,

diversos módulos vêm pré-deﬁnidos. É possível adicionar, alterar pro-

priedades ou remover os módulos, de acordo com a necessidade. Mais

informações sobre módulos na seção 5.4.

Para alterar o nome do host, é necessário utilizar os módulos set_hostname,

update_hostname e update_etc_hosts. Para injetar chaves SSH, é necessário

utilizar o módulo ssh. Para atualizar a senha do default user, é necessário

utilizar o módulo set-passwords.

Segue exemplo de conﬁguração dos módulos e etapas:

# The modules that run in the 'init' stage

cloud_init_modules:

- migrator

- seed_random

- bootcmd

- write-files

- growpart

- resizefs

- disk_setup

- mounts

- set_hostname

- update_hostname

- update_etc_hosts

- ca-certs

- rsyslog

- users-groups

- [ssh, always]

# The modules that run in the 'config' stage

cloud_config_modules:

288

# Emit the cloud config ready event

# this can be used by upstart jobs for 'start on cloud-config'.

- emit_upstart

- snap

- ssh-import-id

- locale

- [set-passwords, always]

- grub-dpkg

- apt-pipelining

- apt-configure

- ubuntu-advantage

- ntp

- timezone

- disable-ec2-metadata

- runcmd

- byobu

# The modules that run in the 'final' stage

cloud_final_modules:

- package-update-upgrade-install

- fan

- landscape

- lxd

- ubuntu-drivers

- chef

- reset_rmc

- refresh_rmc_and_interface

- rightscale_userdata

- scripts-per-boot

- ssh-authkey-fingerprints

- keys-to-console

- phone-home

- power-state-change

• Ao executar o módulo ssh, o cloud-init também gerará novas chaves públi-

cas para o host. Caso o usuário salve as ﬁngerprints, ele poderá se deparar

com a seguinte mensagem e não conseguirá conectar, a menos que cor-

rija o problema:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that a host key has just been changed.

The fingerprint for the ECDSA key sent by the remote host is

...

Para evitar a situação, que ocorrerá toda vez que o usuário reiniciar a

VM, é possível adicionar uma conﬁguração no cloud-init para que ele não

gere novas chaves públicas ao executar o módulo ssh. Para isso, deve ser

criado o arquivo 49_hostkeys.cfg no diretório /etc/cloud/cloud.cfg.d/, com

o seguinte conteúdo:

289

ssh_deletekeys: false

• Para uma simples validação das conﬁgurações do cloud-init, é possível

desligar a máquina virtual, alterar o nome da mesma no CloudStack e

ligá-la novamente. Assim que iniciada, seu hostname deverá ser o mesmo

que o deﬁnido no CloudStack.

• Após validada as conﬁgurações, deve-se desligar a máquina virtual e criar

um template a partir do volume, como descrito na seção 2.10. O template

estará com o cloud-init conﬁgurado e pronto para ser utilizado.

5.6. Cloud-init no Windows

O cloud-init é uma solução desenvolvida para Linux, no entanto existe um

equivalente para Windows, chamado cloudbase-init. Ele também possui inte-

gração com o CloudStack, com suporte, mas não limitado, à alteração de host-

name, alteração de senha e injeção de chaves SSH.

5.7. Troubleshooting do cloud-init

Caso algum erro ocorra na execução dos módulos do cloud-init, é possível

iniciar o troubleshooting através dos logs escritos nos arquivos /va r/log/cloud-i

nit*.

5.8. Obrigação de troca de senha no primeiro login

Quando o cloud-init injeta a senha para o usuário default, é interessante,

por uma questão de segurança, obrigá-lo a trocá-la no primeiro login.

Para que isso aconteça, é necessário criar uma diretriz de usuário na VM

com o cloud-init instalado. Basta seguir os seguintes passos:

1. Acesse a VM com o cloud-init;

2. crie o arquivo da diretriz de usuário:

sudo touch /etc/cloud/cloud.cfg/reset_password.cfg

290

3. adicione os seguintes comandos dentro do arquivo criado (no lugar de <

usuario-padrao> deve ser informado o usuário padrão da VM):

#cloud-config

runcmd:

- echo "expirando a senha do usuário padrão para forçar a troca de senha no primeiro acesso"

- passwd --e <usuario-padrao>

Após esses passos, basta criar um template baseado nessa VM, conforme a

seção 2.10. A partir disso, todas as VM criadas com esse template irão obrigar

o usuário a trocar a senha no primeiro login.

5.9. Auto incremento do tamanho do disco durante o boot

O processo a seguir foi testado pela equipe da SC Clouds com o sistema ope-

racional Ubuntu 20.04 LTS, Cloud.init na versão 21.4, LVM na versão 2.03.07.

Não garantimos o pleno funcionamento para outros sistemas, bibliotecas

e componentes. Utilize essa seção somente como exemplo.

O redimensionamento automático de disco durante o boot é possível atra-

vés de um script que será executado per-boot pelo Cloud.init. Como requisito, é

necessário que a última partição do device seja conﬁgurada como um volume

group (VG) e um logical volume (LV) seja conﬁgurado dentro desse VG.

1. Acesse a VM com o cloud-init;

2. Crie um arquivo de script:

sudo touch /var/lib/cloud/scripts/per-boot/resizelvm.sh

3. O script a seguir expande o LV com todo o bloco disponível no ﬁnal do

disco, assumindo que:

(a) O device seja o

/dev/vda

(b) A partição que contém o VG seja a 3

#!/bin/bash

DEVICE="/dev/vda"

LVPARTITION="3"

LVPATH="/dev/vg0/lv0"

growpart "$DEVICE" "$LVPARTITION"

pvresize "$DEVICE""$LVPARTITION"

lvextend -l +100%Free "$LVPATH"

resize2fs "$LVPATH"

291

4. Garanta permissão de execução para esse script:

sudo chmod +x /var/lib/cloud/scripts/per-boot/resizelvm.sh

Com isso, a instância irá veriﬁcar se há espaço disponível para expandir o

LVM durante o processo de boot e, caso haja, a expansão será realizada alo-

cando os blocos disponíveis para a partição pre-conﬁgurada no script.

5.10. Interação com o user-data

É importante ter em mente a interação do cloud-init com o script de user-

data da VM. O user-data executa após o cloud-init. Sendo assim, caso o cloud-

init deﬁna a senha dos usuários:

chpasswd:

expire: false

users:

- name: ubuntu

password: cloudinit

type: text

- name: teste

password: cloudinit

type: text

E o script de user-data também:

#!/bin/bash

echo "ubuntu:userdata" > senhas

cat senhas | chpasswd

rm senhas

As conﬁgurações do cloud-init serão sobrescritas pelo user-data. No exem-

plo, a senha do usuário ubuntu será userdata, e a do usuário teste será cloudi

nit.

292

6. 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.

293

Apêndices

294

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 conﬁgurado.

– 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.

295