As seções 5.3.1, 5.3.2, 5.3.3 e 5.3.4 discriminam algumas verificações básicas realiza- das no sistema prototipado. Elas representam os testes básicos das funcionalidades mais essenciais da solução proposta.
5.3.1 Ativação de um VAP
Considerando a arquitetura e os recursos disponibilizados pela solução arquitetura e prototipada neste trabalho, a ativação de um VAP é um dos processos mais simples e prático. Utilizando a interface do vapdeploy, o usuário consegue listar e escolher um dos VAPs, disponíveis no seu respectivo nível de permissão, do repositório global.
Etapas do processo, utilizando o vapdeploy:
1. listagem da relação de VAPs disponíveis ao usuário; 2. escolha do VAP desejado;
3. acionamento do daemon de cache para download do VAP;
4. cópia do VAP da cache para o diretório de trabalho do usuário, ou diretório tempo- rário do sistema;
5. inicialização do VAP.
O tempo de download e inicialização do VAP irá depender de diferentes fatores, como capacidade da rede e da máquina hospedeira. Considerando um caso simples, uti- lizando uma rede cabeada de 100 Mbps, duas máquinas X (cliente) e Y (repositório) com GNU/Linux e um VAP de 500 MB, o tempo de download, utilizando o wget, fica
em torno de 81 segundos. Já o tempo de ativação, considerando o Xen, fica em torno de 17 segundos, perfazendo um tempo total aproximadamente 100 segundos, conforme ilustrado graficamente na figura 5.6.
0 20 40 60 80 100 V500MB
Tempo (em segundos)
Virtual Appliance de 500 MB Tempo consumido por cada etapa
ativacao download
Figura 5.6: Tempo de download e ativação de um VAP de 500 MB
No caso do Collective, o processo é idêntico. Por outro lado, no caso do Scripts IBM há algumas intervenções manuais que são necessárias. Os itens 1, 2 e 3 não existem nessa solução. E o item 4 pode envolver comandos e ações manuais, pois o sistema não prevê o uso de um repositório central, por exemplo.
5.3.2 Ativação de VAPs com Instalação de MMVs
A ativação de VAPs com instalação de MMV é semelhante à ativação de um VAP, como apresentado na seção 5.3.1. Há apenas dois passos intermediários, como destacado a seguir.
1. listagem da relação de VAPs disponíveis ao usuário; 2. escolha do VAP desejado;
4. cópia do VAP da cache para o diretório de trabalho do usuário, ou diretório tempo- rário do sistema;
5. o usuário escolhe o MMV a ser instalado para satisfazer as exigências do VAP ; 6. o instalador de MMVs é acionado, procedendo a instalação, caso o usuário seja
autorizado, do novo MMV ; 7. inicialização do VAP.
A instalação de um novo MMV no sistema hospedeiro depende de permissões que são atribuídas pelos administradores do sistema aos usuários. Considerando um usuário autorizado, o daemon de instalação de MMVs irá realizar o download do pacote de dados e do script de instalação do novo MMV. Caso tudo ocorra sem problemas, o VAP será instanciado sem maiores problemas.
Com relação a esse exemplo, nem o Collective e nem os Scripts IBM contemplam a instalação automática de novos monitores de máquinas virtuais. A base do Collective é sobre o VMware, enquanto que os Scripts IBM foram projetados para VMware e Xen, sendo necessário um novo conjunto de scripts específicos para suportar novos MMVs. 5.3.3 Ativação de VAPs com Satisfação de Dependências
A instalação de VAPs com satisfação de dependências agrega mais uma funcionali- dade aos processos ilustrados nas seções 5.3.1 e 5.3.2. Além de verificar os dados neces- sários para a ativação do VAP selecionado pelo usuário, o vapdeploy também avalia as possíveis dependências do pacote. Caso hajam dependências, o usuário poderá escolher entre ativá-las ou não.
Caso o usuário optar por ativar também as dependências, o vapdeploy irá realizar o download e a ativação ordenada das dependências, conforme especificado no arquivo de configuração do VAP. Cada VAP presente na lista de dependências será ativada no sistema local. Ao final, a VAP original, escolhida pelo usuário, fechará o processo aberto pela requisição inicial do usuário.
Como podem haver vários níveis de dependência, o administrador do sistema pode configurar o nível máximo de análise. Sendo assim, o vapdeploy irá ir até o nível máximo definido no sistema.
O Collective suporta a configuração de dependência nos VAPs, de forma análoga ao FlexVAPs. O sistema da IBM, por outro lado, é desprovido de recursos para trabalhar com dependências de serviços, criando relações entre os virtual appliances.
5.3.4 Ativação de Grupos de VAPs
A ativação de grupos de VAPs é um processo diferenciado, visto que demanda a co- municação com grupos de hosts aonde serão ativados os VAPs. Um grupo de VAPs pode ser caracterizado como um conjunto de sistemas que serão inicializados para criar um de- terminado ambiente, normalmente com um fim definido. A exemplo, um grupo de VAPs pode criar um conjunto de pacotes, entre servidores e nós, destinados à criação de um cluster, ou um ambiente de computação distribuída.
Ao grupo de VAPs deve estar associado/definido um grupo de hosts. Os VAPs do grupo serão ativados nos respectivos hosts. Nesses termos, podem haver, por exemplo, VAPs servidores e clientes. Da mesma forma, podem existir hosts caracterizados como servidores, clientes ou quaisquer. VAPs servidores serão ativados em hosts servidores. VAPs clientes serão instanciados em hosts clientes. No caso dos hosts quaisquer, tanto VAPs servidores quanto clientes poderão ser instanciados.
Nem o Collective nem os Scripts IBM trabalham com grupos de VAPs. Esse re- curso não fora previsto nesses sistemas.