Como referido no capítulo3, existem três tipos de modelos de interação com o sistema. Estes correspondem à variante local, varianteproxye variante cloud. No fundo, um deles
utiliza diretamente aAPIdomiddleware, enquanto que os dois últimos acedem às varias operações remotamente, através deweb services. No entanto, nenhum dos dois clientes
disponíveis possui interface gráfica, sendo todas as operações invocadas a partir da linha de comandos, pois tal não se enquadrava no âmbito da presente dissertação. Na tabela
4.1 encontram-se os comandos necessários à invocação das 5 operações existentes. De notar que uma operação como o put parte do pressuposto que o utilizador está a indicar um caminho para o ficheiro através da diretoria corrente, que pode ser parametrizada no ficheiro de configuração da T-Stratus. Por outro lado, um get ou um searchretrieve também grava os ficheiros obtidos numa diretoria previamente parametrizada pelo utili- zador.
Operação Invocação
GET get <nome do ficheiro>
PUT put <nome do ficheiro>
REMOVE remove <nome do ficheiro>
SEARCH search <palavras chave (pc) separadas por espaço>
SEARCHRETRIEVE searchretrieve <pc separadas por espaço> Tabela 4.1: Invocação das operações disponíveis pela API do sistema
Por fim, a implementação do cliente remoto, bem como do servidor T-Stratus que aguarda pedidos do mesmo, foi concretizada através de uma framework de serviços
REST, disponível em Java, denominada Restlet4. Esta framework permite definir um
4. IMPLEMENTAÇÃO 4.10. Cliente Java para acesso à API do middleware
cliente e um servidorRESTpor meio de anotações específicas no código, nomeadamente nos métodos disponibilizados. Estas anotações podem ser de três tipos: @Get, @Put ou @Removee os métodos disponibilizados do lado do servidor têm de corresponder exata- mente àqueles existentes na interface que o cliente possui do seu lado, com as respetivas anotações.
5
Avaliação
Neste capítulo é feita a avaliação ao sistema implementado, no que diz respeito ao seu desempenho e garantias de segurança que oferece. Inicialmente, é feita uma comparação entre o uso direto das várias clouds públicas de armazenamento geridas por terceiros, não necessariamente seguras e confiáveis, face ao uso domiddlewarecomo intermediário na gestão de ficheiros armazenados de forma segura na cloud, tendo em mente as proprieda- des de segurança e privacidade dos dados que oferece. São analisadas as funcionalidades de inserção, obtenção e remoção de ficheiros. De seguida, é feito um estudo do impacto no sistema causado pela alteração de métricas como o tamanho dos fragmentos em que um objeto é repartido, bem como a análise do tempo de processamento consumido pelos vários componentes, face ao tempo total de execução de cada operação. Por fim, é anali- sado o impacto que o uso da cache tem no sistema face ao índice Riak [Ria], bem como o impacto das pesquisas com o aumento do número de ficheiros existentes no sistema.
5.1
Ambiente de testes
Nos testes realizados, o sistemamiddleware, bem como os quatro servidores bizantinos,
são executados na mesma máquina, com as seguintes características: • Sistema operativo: Microsoft Windows 8 Professional
• Tipo de arquitetura: 64 bit
• Processador: Intel Core2 Quad Q6600 @ 3.00GHz (Overclocked) • Número de cores físicos: 4
• Memória Física (RAM): 4,00 GB
5. AVALIAÇÃO 5.1. Ambiente de testes
Cada um desses servidores efetua escritas e leituras para uma, e apenas uma, das cloudsadotadas. Não existem, no entanto dois servidores a escrever ou ler para a mesma. À exceção da Dropbox, todas as clouds adotadas permitem a escolha da localização onde queremos que a nossa informação esteja alojada e para onde os pedidos são encaminha- dos. Tendo este aspeto em vista, foi escolhida a localização mais próxima do utilizador de teste, encontrando-se o mesmo em Portugal. A instância da Amazon S3 situa-se na Irlanda, assim como a da Google Cloud Storage. Já a Lunacloud possui um centro de dados em Portugal. Por fim, quanto à Dropbox, não foi encontrada informação a respeito da localização dos seus servidores, embora no final o armazenamento seja direcionado para a Amazon S3.
Omiddleware, por sua vez, comunica com a base de dadosNoSQLdistribuída Riak,
que se encontra a ser executada num servidor na cloud, numa instância Cloud Server da Lunacloud, com as seguintes características:
• Sistema operativo: Red Hat Enterprise Linux (Debian 6.0) • Tipo de arquitetura: 64 bit
• Processador: 1500 MHz • Número de cores físicos: 2 • Memória Física (RAM): 4,00 GB • Disco Rígido: 250 GB
• Largura de banda: 10240 Kbit/sec
De modo a melhor simular um ambiente distribuído, com várias instâncias do Riak, este encontra-se a ser executado com quatro nós, cada um responsável por uma dada partição das chaves existentes no sistema. Não obstante, essa partição é totalmente trans- parente para o utilizador, bem como as aplicações que fazem uso deste repositório do tipo chave-valor. Os vários nós executam na mesma máquina, descrita acima, e constituem oclusterpara onde os pedidos são encaminhados. O cliente é executado localmente, na mesma máquina domiddleware, numa rede com largura de banda de 30 Mbps de down-
load e 3 Mbps de upload. O cenário de avaliação, com base nos recursos mencionados, é aquele descrito na Figura3.2, como um serviço instalado num servidor dedicado, pró- ximo do utilizador. No entanto, o cliente não é remoto, efetuando pedidos diretamente ao sistema, sem a latência associada à comunicação utilizador-sistema.
Por fim, para uma melhor visualização dos dados obtidos, foi utilizada uma escala logarítmica na grande maioria dos gráficos. Não obstante, todos se fazem acompanhar de uma tabela onde é possível verificar os valores medidos com exatidão. Esta decisão partiu da necessidade de visualizar a evolução das diversas métricas, tanto para valores muito pequenos, como para valores elevados. Sem recorrer a este tipo de escala, esta observação torna-se menos percetível.