Problemática específica sobre modelo de controlo de concorrência

Como foi inicialmente apresentado na introdução, a dissertação privilegia propor uma solução confiável, controlada pelos utilizadores, que permita a adoção de múltiplas clouds de armazenamento, tal como disponibilizadas por provedores Internet. O sistema T- Stratus (enquanto solução proposta) atuará como um conjunto de serviçosmiddleware,

vistos como um serviço “proxy” (ou no caso mais geral uma cloud “proxy”) intermedi- ando o acesso dos utilizadores às nuvens de armazenamento.

Tendo em conta esta direção, as múltiplas clouds (combinadas como solução de cloud de clouds) serão usadas como repositórios para manutenção de dados (ou fragmentos de dados), cifrados e replicados, tendo em vista estabelecer um modelo de proteção que

2. TRABALHO RELACIONADO 2.5. Análise crítica face aos objectivos da dissertação

garante as propriedades de segurança pretendidas bem como proteção contra falhas ou ataques bizantinos desencadeados independentemente sobre cada uma das clouds que sejam utilizadas. A utilização combinada de diferentes clouds (de acordo com as soluções disponibilizadas) permite, desde logo, beneficiar da sua heterogeneidade ou diversidade tecnológica como fator importante de mitigação de falhas ou de risco de ataques por intrusão.

Torna-se no entanto importante discutir o aspeto particular relacionado com os mode- los de concorrência disponibilizados pelas atuais clouds de armazenamento e como esta problemática se relaciona com a questão do suporte do controlo de concorrência ao nível da solução a propor.

As soluções de clouds de armazenamento hoje existentes permitem estabelecer uma base de suporte à solução pretendida que disponibiliza, na maior parte dos casos, um modelo de controlo de concorrência baseado numa semântica do tipo regular, isto é, ga- rantindo ao utilizador final um modelo de controlo de concorrência do tipo “single-writer – multi-reader”. Deve dizer-se no entanto que nem todas as clouds concretizam este mo- delo. Por razões de escalabilidade e elasticidade, em alguns casos, existem soluções que suportam outros modelos de concorrência de acesso, como é o caso da solução Ama- zon S3, que oferece consistência do tipo eventual, ou de semântica do tipo “read-after- write”16_{. Nestes casos, a base de controlo de concorrência torna-se heterogénea, pelo que}

a adaptação a diferentes clouds heterogéneas pode ter que lidar com este problema. A dissertação não pretende lidar com este tipo de problemática, tendo como orientação de implementação um sistema para utilização sem controlo de concorrência em escrita (que deverá ser concretizado pelo suporte específico das aplicações que utilizam o sistema T-Stratus). Deste modo, o sistemamiddlewarepreconiza uma utilização em que cada uti- lizador (ou cada aplicação externa) é executado numa instância de execução da solução

middlewareao nível dos serviços T-Stratus. Não obstante esta ser a orientação base para

implementação e avaliação da solução proposta, no capítulo 3 (secção 3.3.1) avança-se uma discussão de generalização da solução para lidar com este tipo de problemática.

Para todos os efeitos, a solução pretendida orienta-se para uma utilização com con- trolo de concorrência do tipo “single writer – multiple readers”, sendo usado enquanto sistema distribuído assíncrono, em que o sistemamiddlewareT-Stratus é usado como cli-

ente de múltiplas clouds. O acesso às clouds para leitura pode falhar arbitrariamente (já que as clouds individualmente podem falhar, funcionar com intermitência ou revelarem um comportamento bizantino em relação aos dados acedidos). Contudo, considera-se que as escritas só falharão por falhas (ou ataques) às clouds que impliquem a sua paragem (de acordo com um modelo “fail-stop”). Nos objetivos da dissertação não se consideram mecanismos ao nível da solução middleware para lidarem com problemas de falhas ar-

bitrárias durante os processos de escrita de dados (ou fragmentos de dados) nas clouds, embora estas falhas possam ser toleradas desde que um número adequado de réplicas

16_{http://aws.amazon.com/s3/faqs/#What_data_consistency_model_does_Amazon_S3_} employacedido e verificado a 25-03-2013

possa ter sido escrito com sucesso, tendo em conta a resiliência necessária (ou seja, f + 1 réplicas escritas com sucesso, para n clouds, em que f clouds falhem arbitrariamente). O não se pretender lidar com cenários de recuperação de falhas bizantinas durante opera- ções de escrita do lado das clouds, resulta do facto de se pretender garantir que a solução esteja adequada à utilização de clouds de armazenamento, isto é, clouds onde não se exe- cuta código. Para lidar com este tipo de problemas seria necessário executar código do lado das mesmas, o que não é considerado por se entender que esse código poderia ser objeto de ataques de intrusão bizantinos, de qualquer modo.

3

Modelo e arquitetura do sistema

Tal como se introduziu anteriormente, o sistema T-Stratus, foi concebido como sistema

middleware, permitindo assegurar um conjunto de serviços intermediários entre utiliza-

dores individuais (ou suas aplicações) e múltiplas clouds de armazenamento. A ideia é criar um ambiente confiável de cloud de clouds de armazenamento, com base em soluções de provedores destes serviços na Internet. A solução pretende aproveitar as vantagens dessas soluções, permitindo a manutenção e replicação de dados privados em múltiplos provedores Internet, como solução de outsourcing de dados, mas permitindo o controlo dos utilizadores da base de confiança que assegura as propriedades de segurança, priva- cidade e confiabilidade.

Tendo em vista um modelo de computação confiável de cloud de clouds, os serviços demiddlewarefornecidos pelo sistema T-Stratus foram ainda concebidos de forma a po-

der utilizar a solução com flexibilidade, nomeadamente: variante local, varianteproxye variante em cloud.

Variante Local. Nesta variante, o sistema é visto como suporte demiddlewarelocal, exe-

cutando num computador de um utilizador e intermediando de forma transparente o acesso das aplicações a múltiplas clouds de armazenamento utilizadas como repo- sitórios de dados;

Variante Proxy. Nesta variante o sistema é visto como serviço de proxy, executando re-

motamente num servidor confiável, estando este instalado na rede local do utili- zador final, e permitindo intermediar o acesso de aplicações de um utilizador às múltiplas clouds de armazenamento utilizadas. Esta arquitetura surge como uma generalização da anterior, permitindo por exemplo suportar aplicações baseadas

3. MODELO E ARQUITETURA DO SISTEMA 3.1. Solução Proxy

em dispositivos com poucos recursos de computação, onde apenas executam apli- cações finais;

Variante em Cloud. Neste caso a arquitetura do sistema é formada por um conjunto de

servidores que replicam os serviçosmiddlewarenuma arquitetura “core”, formando um ambiente distribuído de um grupo de servidores de computação e gestão de dados de controlo. Os servidores podem ser disponibilizados numa rede corpo- rativa de grande escala, sendo cada um deles um sistema confiável. Nesta última ideia, o sistema toma a forma de umclusterde servidores, atuando com vantagens

de escala e permitindo acesso ubíquo, podendo os utilizadores interagir com qual- quer um dos servidores. Estes formam assim uma cloud consistente de controlo de intermediação e acesso transparente às múltiplas clouds de armazenamento utili- zadas. É nesta última visão que a designação T-Stratus aparece associada a uma “nuvem baixa” de controlo, que permite a gestão confiável dos dados privados ar- mazenados de forma transparente nas nuvens de outsourcing (ou “nuvens altas”), correspondendo estas a repositórios de dados fragmentados e cifrados, distribuídos segundo um modelo de replicação bizantina pelos diferentes provedores Internet utilizados.

Nas próximas secções deste capítulo descreve-se o modelo de sistema, incluindo o modelo de segurança e discute-se a arquitetura de serviçosmiddlewareda seguinte forma:

na secção3.1o sistema será apresentado na varianteproxy, executando num servidor con- fiável acessível na rede local do cliente. Na secção3.2, a anterior visão será então genera- lizada para o modelo em cloud discutindo-se os componentes do sistema que suportam essa generalização.

3.1

Solução Proxy