correspondente aos dados do mesmo. Um pedido de remove também tem como único argumento o nome do ficheiro a eliminar (String). O mesmo é removido do índice e das quatro clouds públicas de armazenamento usadas. Não obstante, derivado dos modelos de custo dos vários provedores associados ao armazenamento, uma das vantagens do sistema é que não é necessário recorrer à remoção dos ficheiros em caso de cessação do uso de uma das quatro clouds, pois os dados nela presentes são ilegíveis por qualquer in- dividuo que possa vir a ter acesso aos mesmos. Por fim, o search e o searchretrieve correspondem a duas pesquisas idênticas que, como mencionado na subsecção anterior, diferem no tipo de resultado que retornam. Como argumento, qualquer um destes pe- didos recebe uma ou mais palavras a pesquisar nos metadados dos ficheiros contidos no sistema (String[]). O resultado das pesquisas já envolve uma estrutura de dados di- ferente, nomeadamente, um objeto capaz de apresentar uma lista dos vários resultados ordenados consoante a relevância (TStratusMessage).
3.2
Generalização do sistema numa arquitetura em cloud
Nas subsecções seguintes é descrita a transposição do sistemamiddleware, definido ante-
riormente segundo a sua varianteproxy, para a variante cloud.
3.2.1 Generalização do modelo inicial
O sistema, tal como se encontra definido na secção 3.1pressupõe uma instanciação do mesmo num servidor confiável (variante proxy, instalado na rede local do utilizador fi-
nal). Todas as propriedades de segurança e confiabilidade da solução são garantidas e o acesso às múltiplas clouds de armazenamento é intermediado por uma instância do
middleware descrito. Tal como foi dito ao longo deste capítulo, a visão final pressupõe
a instanciação do mesmo numa cloud privada, com total controlo do lado dos utilizado- res, onde várias instâncias do middleware seriam executadas. Generalizando o modelo
anterior, estas instâncias formam um ambiente distribuído de computação e gestão dos dados dos utilizadores. Visto ser uma generalização da solução anterior, esteclusterde
servidores de instâncias do middleware preserva todas as características de segurança e
confiabilidade anteriormente definidas. Os utilizadores podem ter acesso ao sistema de forma ubíqua a qualquer uma das instâncias disponíveis.
É esta variante em cloud, representada na Figura3.2.1, que associa metaforicamente a designação de stratus ao clusterde servidores que, por sua vez, comunica com as vá-
rias clouds públicas de armazenamento, bem como o índice distribuído. O sistema, visto como uma nuvem baixa (stratus, Figura3.91), uniforme, que cobre uma vasta extensão
horizontal, "esconde"as restantes nuvens heterogéneas, mais altas e que podem apresen- tar as mais variadas características. As clouds heterogéneas de armazenamento de dados poderiam ser caracterizadas como Cirrus, Cirrocumulus, Altocumulus, Altostratus, etc.
T-STRATUS Riak Amazon S3 Dropbox Google CS Luna Cloud
Figura 3.8: Visão geral do sistema, solução suportada num sistema distribuído por diver- sos nós (cluster) numa cloud privada
Figura 3.9: Tipos de nuvens, através das quais é caracterizado metaforicamente o sistema T-Stratus
3. MODELO E ARQUITETURA DO SISTEMA 3.2. Generalização do sistema numa arquitetura em cloud
3.2.2 Arquitetura da solução
A arquitetura aqui descrita consiste num sistema distribuído constituído por várias ins- tâncias do middleware definido na secção 3.1. No seu conjunto, formam um cluster de servidores, sendo que a replicação é feita por uma camada out of box, suportada pelo sis- tema de indexação Riak. Na verdade a utilização deste componente não é vista como um aspeto focado nos objetivos da dissertação, no entanto, por esta via, a formação deste
clusterpermite ter uma arquitetura cloud (Figura3.10). Os utilizadores têm acesso a uma
destas instâncias que, nesta visão, incorpora um novo módulo, responsável pela gestão concorrente de múltiplos utilizadores, bem como a distribuição uniforme dos mesmos pelos vários nós, de maneira a distribuir o processamento das várias instâncias e não so- brecarregar o sistema. Tal como descrito na arquitetura domiddleware, cada nó do sistema
Componente de Instância Middleware
Camada de replicação de serviços middleware
Componente de Instância Middleware
Componente de Instância Middleware
Figura 3.10: Visão arquitetural da variante cloud do sistema T-Stratus
possui a sua própria instância cliente de acesso ao índice Riak. Este, no entanto, é comum a todas as instâncias e poderá representar um papel chave (como será abordado na sub- secção 3.2.3) para o mecanismo de controlo de concorrência, através do seu modelo de consistência de dados. Os segredos criptográficos que asseguram a autenticidade, priva- cidade e pesquisa dos dados armazenados são distintos para cada utilizador. Este fator permite que um único índice, como o Riak (com vários nós que formam também umclus- terpróprio), possa suportar todo o armazenamento dos objetos associados aos ficheiros
introduzidos, num ambiente altamente escalável, tal como já suporta para uma instância domiddlewareapenas.
O novo módulo, visível na figura anterior, permite a comunicação entre as várias instâncias, de forma a assegurar as propriedades anteriormente definidas. É nesta visão final que todo o sistema pode operar num ambiente cloud, privado, onde o controlo da
base de confiança permanece do lado dos utilizadores finais, mantendo as clouds dos vários provedores apenas como outsourcing para o armazenamento dos dados.
3.2.3 Papel do componente Riak
Como mencionado em cima, a base de dados distribuída Riak [Ria] desempenha um pa- pel importante para atingir o objetivo da variante em cloud que se pretende. Consiste num sistema distribuído composto por vários nós, de forma a formar umcluster. Estes
nós podem ser distribuídos ao nível de servidores num único centro de dados, bem como ao nível de múltiplos centros de dados. Associado a esta distribuição dos vários consti- tuintes, torna-se uma solução altamente tolerante a falhas, correspondendo aos objetivos pretendidos.
Os dados armazenados, neste caso, objetos com informação associada aos ficheiros colocados pelos utilizadores finais, encontram-se replicados pelo menos por três nós di- ferentes (valor por defeito), podendo os mesmos pertencer a diferentes centros de da- dos. Este modelo de replicação é particularmente importante para a solução perspeti- vada pois garante a recuperação dos dados na eventualidade de falha de um ou mais nós que compõem o Riak. Neste cenário, um nó vizinho do que falhou (por razões ar- bitrárias) assume as operações de escrita e leitura deste último, enquanto o mesmo não for recuperado. Cada nó mantém os dados armazenados através do Bitcask [SSBT10], detalhado na secção2.1.2. Esta persistência dos dados assegura que a informação intro- duzida no Riak acerca dos vários ficheiros dos utilizadores está rapidamente acessível e com baixa latência2. Mesmo na eventualidade de falha, o modelo de replicação assegura
a sua recuperação.
O processamento dos pedidos de escrita e leitura pode ser feito por qualquer um dos nós existentes no sistema. Um utilizador pode requerer um pedido a um nó qualquer e, o próprio, na eventualidade de não possuir os dados pretendidos, reencaminha o pedido para um nó capaz de fornecer a resposta. Para garantir que o processamento é distri- buído de maneira uniforme, a distribuição das chaves é feita com recurso a funções de
hashconsistente. Assim, o uso do sistema T-Stratus por múltiplos utilizadores em simul-
tâneo, com acessos recorrentes ao índice, não sobrecarrega apenas um nó do sistema de indexação, pois qualquer um pode coordenar uma operação de leitura ou escrita.
Posto isto, o uso do Riak como índice persistente permite assegurar as propriedades do sistema atual e ainda dar suporte ao uso por parte de múltiplas instâncias, de forma transparente. É garantida uma elevada disponibilidade, bem como escalabilidade, pois o processo de adição de um nó ao sistema Riak é dinâmico e a distribuição do proces- samento e das chaves é feita de forma automática. Esta propriedade permite dotar o sistema de uma maior capacidade de resposta, caso se verifique que os servidores exis- tentes se começam a revelar ineficientes para poder dar resposta ao número de pedidos efetuados e à quantidade de informação armazenada.
2http://docs.basho.com/riak/1.2.0/tutorials/choosing-a-backend/Bitcask/ ace-
3. MODELO E ARQUITETURA DO SISTEMA 3.2. Generalização do sistema numa arquitetura em cloud
Contudo, outras abordagens como o Cassandra (descrito anteriormente) poderiam ser adotadas como índice distribuído para o sistema T-Stratus, não fosse a semântica e contexto do Riak preferencial para este caso. Assumindo que as operações predominan- tes no sistema são de leitura, que o modelo de tolerância a falhas é bastante importante, a disponibilidade permanente é fundamental e a escalabilidade pode ser facilmente con- trolada com a adição dinâmica de nós ao cluster, o Riak torna-se um forte candidato3.
Embora o Cassandra consiga dar resposta às propriedades anteriores, o seu desenho não é tão orientado a key-value-store (como o Riak), mas mais SQL-Like, característica que não é valorizada no sistema atual. No Cassandra, a agregação dos dados em colunas e famílias de colunas, com uma abordagem semelhante à de uma base de dados relacional, confere complexidade desnecessária ao modelo de dados em relação à solução que se pretende, de forma a satisfazer os objetivos pretendidos. O modelo de dados do Riak apresenta um conceito simples e familiar de chave-valor, ao passo que o Cassandra apresenta o seu próprio modelo de dados. No fundo, o Cassandra é mais orientado para uma solução Bigtable e não tanto Dynamo, como o Riak.
No entanto, o acesso concorrente não se resolve, por si só, com a utilização do Riak, dado o seu modelo de consistência. Se assumirmos que não existem escritas concorrentes sobre o mesmo ficheiro (single-writer multi-reader), o modelo de consistência do Riak (even- tual consistency) acaba por ser suficiente. No entanto, tendo como visão final a utilização do sistema por diversas aplicações, podendo as mesmas aceder concorrentemente aos mesmos dados, esta problemática tem de ser contornada com novas abordagens, sendo essa a discussão da subsecção3.3.1, em baixo.
3.2.4 Ambiente de interligação da cloud T-Stratus
De forma a garantir resposta em tempo útil, face à latência verificada entre as comuni- cações das várias instâncias do sistema como variante cloud, bem como o índice Riak e o protocolo de tolerância a falhas bizantinas, é aconselhável a utilização de canais de comunicação dedicados entre os mesmos. Estes devem ter capacidade e taxas de trans- ferência elevadas, preferencialmente, com ligações diretas de elevada performance não descartando, contudo, caminhos alternativos na eventualidade de falha de uma ou mais ligações.
No geral, o sistema forma uma rede corporativa (a proteção das comunicações pode fazer-se porSSLouTLS), pois é considerada a possibilidade de ataques às comunicações entre os vários nós. Não obstante, os servidores são confiáveis, tal como o eram na sua varianteproxy, agora generalizada. No final, obtém-se a nuvem de computação T-Stratus,
como uma base global de confiança dos utilizadores.
A rede poderá ser Internet, podendo ser adequada uma solução em que oclusterque
forma a nuvem T-Stratus é interligado por IPSec Tunneling por razões de usabilidade e eficiência, protegendo o tráfego entre dois pontos. No entanto, este ambiente e o seu
3http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redisacedido e verificado a
impacto não está no foco da dissertação, estando a mesma focada nos aspetos de perfor- mance, segurança e confiabilidade de uma instância domiddlewareda qual seria possível
a generalização para o sistema descrito ao longo desta secção.