Estacio Redes: ARQ SISTEM DISTRIBUIDOS

A interface entre um programa aplicativo e os protocolos de comunicação em um sitema operacional é conhecida como Interface de Aplicativos, ou API. A API de sockets é um padrão de facto.

A comunicação realizada a partir da utilização de sockets é um mecanismo de comunicação entre processos – Inter Process Comunication (IPC) – através da rede, que pode ser utilizado em processos na mesma máquina.

Os protocolos de comunicação geralmente não especificam a API que as aplicações devem utilizar. Ao contrário disso, os protocolos especificam quais são as operações que devem ser fornecidas e permitem que cada sistema operacional defina a API específica wur uma aplicação deve usar para executar suas operações.

A API de sockets originou-se como parte do sistema operacional BSD UNIX. Tanto neste quanto nos sistemas que dele derivam, as funções de sockets são parte do próprio sistema operacional.

Para um programador, seu programa chama procedimentos de sockets, que são, então, providos por procedimentos do sistema operacional ou por rotinas de biblioteca.

Desse modo, um aplicativo que usa sockets pode ser copiado para um novo computador compilado, carregado junto com a biblioteca de sockets do computador, e então, executado.

Originalmente, os sockets foram desenvolvidos como parte do sistema operacional UNIX e utilizam diversos conceitos que são implementados em outras partes desse sistema.

Um programa vê os sockets como um mecanismo de entrada e saída de dados, pois eles seguem o paradigma open-read-write-close, usado pela maioria das operações de entrada e saída.

Sendo assim, um socket deve ser criado, usado e, só então, destruído. Por isso, quando uma aplicação se comunica através de uma rotina similar ao socket, forma um caminho para a aplicação transferir dados a um arquivo. Dessa forma, a compreensão dos sockets exige o entendimento das características de entrada e saída do UNIX.

Por exemplo, um aplicativo deve primeiro chamar open para preparar um arquivo para acesso. O aplicativo chama, então, read ou write para recuperar ou armazenar dados no arquivo. Finalmente, o aplicativo chama close para especificar que terminou de usar o arquivo.

A comunicação através de sockets utiliza também a abordagem de descritor. Quando a aplicação solicitar ao sistema operacional para criar um socket, o aplicativo passará o descritor como um argumento para a chamada de procedimentos na transferência de dados através da rede.

O sistema operacional fornece um único conjunto de descritores para arquivos, dispositivos, comunicação entre processos e comunicação de rede. Como resultado, procedimentos como read e write são bem gerais - uma aplicação pode usar o mesmo procedimento para enviar dados para outro programa ou um arquivo através de uma rede.

Em terminologia corrente, o descritor representa um objeto e o procedimento write, o método aplicado aquele objeto.

A programação por socket difere da entrada e saida convencional de dados porque um aplicativo deve especificar diversos detalhes para utilizar um socket.

Por exemplo, um aplicativo deve escolher um protocolo de transporte em particular, fornecer o endereço de protocolo de uma máquina remota e especificar se o aplicativo é cliente ou servidor.

Para acomodar todos os detalhes, cada socket tem diversos parâmetros e opções - um aplicativo pode fornecer valores para cada um deles.

Para evitar que exista uma única função de socket com argumentos separados para cada opção, os desenvolvedores das APIs de sockets definiram diversas funções. Essencialmente, um aplicativo cria um socket e, então, invoca funções para especificar, em detalhes, como ele será usado

A vantagem da abordagem de sockets respalda-se no fato de que a maioria das funções tem três ou menos argumentos.

A desvantagem, por sua vez, indica que um programador deve lembrar-se de chamar múltiplas funções sockets.

Conheça, agora, os procedimentos que implementam a API de sockets:

Procedimento Socket: cria um socket e retorna um descritor inteiro. Conheça o procedimento socket:

sockfd = socket (protofamily, type, protocol);

Procedimento bind: Uma vez que tenha um socket, você deve associá-lo a uma porta em sua máquina. Um servidor usa o procedimento bind para prover um número de porta de protocolo em que o servidor esperará por contato.

bind (sockfd, localaddr, addrlen);

Procedimento connect: os clientes usam o procedimento connect para estabelecer uma conexão com um servidor específico: connect (sockfd, saddress, saddresslen);

Procedimento Listen: Depois de especificar uma porta de protocolo, o servdor deve instruir o sitema operacional para colocar um socket em modo passivo, para que este possa ser usado para esperar pelo contato de clientes: listen(sockfd, backlog);

Procedimento Accept: Os servidores iniciam-se chamando socket (criar) e bind (especificar número de porta). Após executar as duas chamadas, o servidor que usa um protolo de transporte sem conexão está pronto para aceitar mensagens. No caso de o servidor utilizar um protocolo de transporte orientado a conexão, é necessário chamar o procedimento listen para colocar o socket em modo passivo, para só então aceitar uma conexão.

Accept (sockfd, caddress, caddresslen);

Procedimentos send, sendto e sendmsg: Os cliente e servidores precisam enviar informações. Geralmente, um cliente envía uma requisição e um servidor envia uma resposta. Se o socket está conectado, o procedimento send pode ser usado para transferir dados: send (sockfd, data, length, flags);

O procedimento sendto e sendmsg permite que o cliente ou servidor envie uma mensagem usando um socket não conectado, mas ambos exigem que um destino especificado. O sendto possui o endereço de destino como argumento.

sendto (sockfd, data, length, flags, destaddress, addresslen);

sendmsg (sockfd, msgstruct, flags)

Procedimento recv, recvfrom e recvmsg: O cliente e o servidor precisam receber dados enviados pelo outro. Para tal, a API de sockets fornece vários procedimentos que podem ser usados. Por exemplo, um aplicativo pode chamar recv para receber dados de um socket conectado.

recv (sockfd, buffer, length, flags)

recvfrom (sockfd, buffer, length, flags, sndraddr, sddrlen)

recvmsg (sockfd, msgstruct, flags)

Procedimento close: informa ao sistema para finalizar o uso do socket:

close (sockfd);

Comunicação UDP: socket, bind, recvfrom, sendto, close.

Comunicação TCP: socket, bind, listen, accept, recv, send, close.

Chamada de Procedimento Remoto (RPC): Além das tarefas habituais, o programador que constrói qualquer aplicação cliente-servidor deve, também, lidar com os detalhes complexos de comunicação.

Mesmo que muitas das funções necessárias sejam fornecidas por uma API padrão (como a interface de socket, por exemplo), é necessário que sejam especificados os nomes, os endereços, os protocolos e as portas, entre outros detalhes.

O ponto positivo é que muitos sistemas cliente-servidor seguem uma mesma lógica de arquitetura básica e usam a API de sockets para comunicação.

As similaridades entre as aplicações permitiram que um conjunto de ferramentas de software fosse criado para gerar, automaticamente, o código para muitas das tarefas de comunicação, deixando o programador livre para se concentrar em partes da programação que não podem ser automatizadas.

Paradigma de chamada remota de procedimento – Remote Procedure Call (RPC)

Muitos sistemas distribuídos são baseados em troca explícita de mensagens entre processos. Contudo, os procedimentos send e receive não escondem absolutamente nada da comunicação, o que é importante para obter transparência de acesso em sistemas distribuídos.

Esse problema é conhecido há muito tempo, mas pouco tinha sido feito para resolvê-lo, até que um artigo de autoria de Birrell e Nelson (1984) propôs um modo completamente diferente de manipular a comunicação. A proposta foi permitir que programas fossem capazes de chamar procedimentos localizados em outras CPUs.

Quando um processo em uma máquina chama um procedimento em uma máquina remota, o processo chamador (cliente) é suspenso, e a execução do procedimento chamado (servidor) ocorre na máquina remota.

A informação pode ser transportada, nos parâmetros, do cliente para o servidor e pode voltar no resultado do procedimento. Nenhuma troca de mensagem ou entrada e saída é visível ao programador e tem servido de base a muitos softwares para multicomputadores.

Em sua forma mais simples, para chamar um procedimento remoto, o programa cliente deve ser ligado a um pequeno procedimento de biblioteca chamado de stub do cliente, que representa o procedimento servidor no espaço de endereçamento do cliente. Da mesma maneira, o servidor é ligado a um procedimento denominado stub do servidor.

Esses procedimentos escondem o fato de uma chamada de procedimento do cliente para o servidor não ser local.

São componentes da RPC:

CLIENTE: Faz a chamada com o sistema remoto

STUB DO CLIENTE: Faz a interface com o runtime system (esconde chamadas de baixo nível da aplicação)

RPC RUNTIME: Comunicação entre dois computadores, que esconde os detalhes da comunicação de rede, retransmissões e comunicações, etc.

SERVIDOR: Faz o atendimento a requisição

STUB DO SERVIDOR: Faz o mesmo que o stub do cliente.

Tratamento de falhas com RPC:

O cliente não é capaz de localizar o servidor: isso ocorre devido a uma falha de hardware e em função de o servidor não estar efetivamente disponível. O tratamento específico desse erro elimina a transparência;

Perda de mensagem solicitando serviço: nesse caso, devemos usar um contador de tempo; se o tempo expirar e a resposta não chegar, retransmita a mensagem

Perda de mensagem com resposta: o que torna a mensagem idempotente

Quedas do servidor: definir semântica - mínimo uma vez que garante que a chamada remota ao procedimento será executada no mínimo uma vez ou no máximo uma vez que garante que a chamada remota foi executada no máximo uma única vez.

Queda do cliente: trata-se da situação em que o cliente manda uma requisição e, antes de receber a resposta, sai do ar. Essa situação causa dois problemas: a geração de processos órfãos (zombie) e o tempo de CPU gasto desnecessariamente pelo servidor.

Em relação à RPC, a localização física e a arquitetura do servidor são TRANSPARENTES.

1. Em relação à comunicação utilizando RPC, podemos afirmar que:
Assinale a opção CORRETA.

I – A troca de informações é realizada através de parâmetros da chamada.

III – Clientes chamam procedimentos remotos como se fossem locais.

IV – A localização física e a arquitetura do servidor são transparentes.

2. De acordo com a nossa aula, quando tratamos da comunicação utilizando sockets, qual é o procedimento que associa uma porta ao socket?
Assinale a opção CORRETA

4) Bind

3. Em relação à comunicação por sockets o procedimento close possui a seguinte função:

2) Encerra o socket ou a conexão

O modelo de comunicação Peer-to-Peer (P2P) é implementado em uma rede de computadores cuja comunicação não está baseada em servidores dedicados – como no modelo cliente-servidor –, e sim na comunicação direta entre cada nó da rede (peers).

Cada computador conectado tem a capacidade de atuar como servidor – realizando tarefas para outros usuários da rede – ou como cliente – requisitando a realização dessas tarefas.

Na comunicação P2P, indivíduos que constituem um grupo livre podem comunicar-se com outros participantes do grupo. Em princípio, toda pessoa pode se comunicar com uma ou mais pessoas – não existe qualquer divisão estrita entre clientes e servidores.

Diversos sistemas P2P – como o BitTorrent (COHEN, 2003) – não possuem qualquer informação centralizada. Ao contrário, esses sistemas mantêm suas informações locais e compartilham uma lista dos peers vizinhos que os compõem.

Quando uma nova consulta é realizada a um membro do sistema, é possível retornar com os nomes de seus outros membros, para que a busca por mais conteúdo e mais nomes seja possível. Esse processo de pesquisa pode ser repetido indefinidamente, até que se crie um grande banco de dados.

Normalmente, a comunicação P2P é usada para compartilhar diferentes tipos de arquivos. Essa comunicação alcançou o auge por volta do ano 2000, com a criação do Napster por Shawn Fanning para o compartilhamento de músicas entre amigos da faculdade.

Esse serviço foi encerrado depois daquilo que, provavelmente, foi a maior exposição sobre a violação de direitos autorais em toda a história da tecnologia.

REDES P2P: Há uma grande dificuldade em montar uma rede de entrega de conteúdo – Content Delivery Networks (CDN) – de 1000 nós no mundo inteiro para distribui-lo.

Na verdade, não é difícil alugar 1000 máquinas virtuais no mundo inteiro, devido à indústria de hospedagem bem desenvolvida e altamente competitiva. Entretanto, conseguir os nós é só o início da montagem de uma CDN.

Mas, felizmente, existe uma alternativa para o restante de nós, que é simples de usar e pode distribuir uma quantidade tremenda de conteúdo com uma rede P2P.

A tecnologia P2P pode ser usada de diversas maneiras. Com seu desenvolvimento e grande interesse por parte dos usuários, o tráfego P2P tornou-se, rapidamente, responsável por uma grande fração de todo o tráfego na internet.

Comunicação P2P: As redes P2P são autoescaláveis, e sua capacidade de upload útil cresce em conjunto com as demandas de download que podem ser feitas por seus usuários. Em certo sentido, essas redes sempre são grandes o suficiente, sem a necessidade de alguma infraestrutura dedicada. Ao contrário disso, a capacidade até mesmo de um site Web grande é fixa e será ora muito grande ora muito pequena.

Considere, por exemplo, um site com apenas 100 clusters, cada um capaz de trabalhar a 10 Gbps. Essa capacidade enorme não ajuda quando existe um pequeno número de usuários. O site não pode receber informações de N usuários em uma taxa mais rápida que N Mbps, pois o limite está nos usuários, e NÃO no site.

Quando existe mais de 1.000.000 de usuários a 1 Mbps, o site Web não pode bombear dados com rapidez suficiente para manter todos ocupados fazendo download. Esse pode parecer um número considerável de usuários, mas grandes redes BitTorrent (como, por exemplo, o Pirate Bay) afirmam ter mais de 10 milhões de usuários. De acordo com essa abordagem, isso significa algo em torno de 10 terabits/s.

Bittorrent: O protocolo BitTorrent foi desenvolvido por Brahm Cohen, em 2001, para permitir que um conjunto de peers compartilhasse arquivos rápida e facilmente. Existem dezenas de clientes disponíveis gratuitamente que entendem esse protocolo.

Em um sistema P2P típico, como o BitTorrent, cada um dos usuários tem a mesma informação, que pode ser de interesse de outros usuários. Essa informação pode ser um software gratuito, uma música, vídeos, fotografias etc.

Existem três problemas que precisam ser resolvidos para compartilhar o conteúdo nesse ambiente. Veja, a seguir, cada um deles.

O surgimento dos sistemas P2P: O surgimento das redes de compartilhamento de arquivos P2P motivou a comunidade de pesquisa. A essência dos sistemas P2P está no fato de que evitam as estruturas gerenciadas, de forma central, das CDNs e de outros sistemas. Essa pode ser uma vantagem significativa.

Quando o sistema fica muito grande, os componentes gerenciados de forma central tornam-se um gargalo e correspondem a um ponto de falha isolado. Contudo, os primeiros sistemas P2P eram apenas parcialmente descentralizados – se fossem totalmente descentralizados, seriam ineficazes.

Distributed Hash Tables (DHTs): Criar um índice de posse de cada um é simples, mas é centralizado. Fazer com que cada par mantenha seu próprio índice também não soluciona o problema. Entretanto, exige bastante trabalho para manter atualizados os índices de todos os peers – pois o conteúdo é movimentado pelo sistema –, o que não compensa o esforço.

A principal questão a ser respondida pela comunidade de pesquisa foi: seria possível criar índices P2P que fossem totalmente distribuídos, mas que possibilitassem um bom desempenho?

O bom desempenho pode ser interpretado da seguinte forma: Cada nó mantém apenas uma pequena quantidade de informação sobre outros nós, o que significa que não será caro manter o índice atualizado.

Cada nó pode pesquisar, rapidamente, entradas no índice. Caso contrário, esse não será um índice muito útil.

Cada nó pode usar o índice ao mesmo tempo, ainda que outros nós apareçam e desapareçam. Essa propriedade indica que o desempenho do índice aumenta com o número de nós.

A resposta para essa pergunta foi SIM. Para tal, foram desenvolvidas, em 2001, quatro soluções. São elas:

Chord (STOICA et al., 2001);

Can (RATNASAMY et al., 2001);

Pastry (ROWSTRON; DRUSCHEL, 2001);

Tapestry (ZHAO et al., 2004).

Essas soluções são conhecidas como Distributed Hash Tables (DHTs), pois a funcionalidade básica de um índice é mapear uma chave a um valor. Isso representa uma tabela de hash, e, naturalmente, as soluções são versões distribuídas.

As DHTs realizam seu trabalho impondo uma estrutura regular sobre a comunicação entre os nós. Esse comportamento é muito diferente daquele das redes P2P tradicionais, que usam quaisquer conexões que os peers façam.

Por esse motivo, as DHTs são chamadas de redes P2P estruturadas. Os protocolos P2P tradicionais montam redes P2P desestruturadas (ou não estruturadas).

Como exemplo, utilizaremos a solução DHT Chord. Vamos conhecê-la?

Pensando em um cenário, considere como substituir o tracker centralizado tradicionalmente – usado no BitTorrent – por um tracker totalmente distribuído. A solução DHT Chord pode ser usada para resolver esse problema.

Nesse cenário, o índice geral é uma listagem de todos os swarms aos quais o computador pode-se juntar para baixar conteúdo. A chave usada para pesquisar o índice é a descrição do conteúdo pela torrent. Ela identifica um swarm exclusivamente, do qual o conteúdo pode ser baixado como os hashes de todos os chunks de conteúdo.

O valor armazenado no índice para cada chave é a lista de peers que compreendem o swarm. Esses peers são os computadores que entram em contato para baixar o conteúdo. Uma pessoa que espera baixar conteúdo (como um filme, por exemplo) tem apenas a descrição da torrent.

A pergunta que a DHT precisa responder é: como, sem um banco de dados central, uma pessoa descobre de quais peers (entre os milhões de nós BitTorrent) ela deve copiar o conteúdo?

Uma DHT Chord consiste em N nós participantes. Eles são nós que executam BitTorrent em nosso cenário. Cada nó tem um endereço IP pelo qual pode ser comunicado.

O índice geral está espalhado pelos nós. Isso significa que cada um armazena bits e pedaços do índice para uso por outros. A parte central da Chord navega pelo índice usando identificadores em um espaço virtual, e não os endereços IP dos nós ou os nomes de conteúdo.

Para transformar um endereço de nó em um identificador, ele é mapeado para um número de M bits, usando uma função de hash. Sendo assim, podemos usá-lo para converter qualquer endereço IP em um número de 160 bits – chamado de identificador de nó.

Solução DHT Chord - Chave

Uma chave também é produzida pela execução do hashing de um nome de conteúdo com hash para gerar um número de 160 bits (nome = torrent). Sendo assim, para converter o arquivo de descrição de torrent para sua chave, calculamos: chave = hash(torrent).

Para iniciar um novo swarm, um nó precisa inserir um novo par chave-valor, que consiste no índice (torrent, meu-endereço-IP). Para conseguir isso, o nó pede ao sucessor – hash(torrent) – para armazenar meu-endereço-IP. Desse modo, o índice é distribuído pelos nós aleatoriamente.

Com a DHT construída, quando outro nó desejar encontrar uma torrent de modo a se juntar ao swarm e baixar o conteúdo, um nó pesquisará a torrent primeiro, calculando seu hash para obter a chave. Depois, esse nó usará o sucessor(chave) para encontrar o endereço IP do nó que armazena o valor correspondente.

Solução DHT Chord IP: Para possibilitar a localização do endereço IP do nó correspondente a certa chave, cada nó precisa manter determinadas estruturas de dados administrativas. Uma delas é o endereço IP de seu nó sucessor junto ao anel identificador de nó. Por exemplo, na apresentada anteriormente, o sucessor do nó 4 é 7, e o sucessor do nó 7 é 12.

Agora, a pesquisa pode prosseguir da seguinte forma:

O nó solicitante envia um pacote a seu sucessor, contendo seu endereço IP e a chave que está procurando. O pacote é propagado pelo anel até que localize o sucessor do identificador de nó procurado. Esse nó verifica se possui qualquer informação que combine com a chave; caso haja, ele retorna a informação diretamente ao nó solicitante, cujo endereço IP possui.

Entretanto, a busca linear de todos os nós é ineficaz com um grande sistema P2P, pois o número médio de nós exigido por consulta é N/2. Para agilizar a busca, cada nó também mantém o que a Chord chama de tabela de fingers, que contém M entradas, indexadas de 0 até M - l, cada uma apontando para um nó real diferente.

Visto que os nós entram e saem o tempo todo, o DHT Chord precisa de uma forma de lidar com essas operações. Assumimos que, quando o sistema iniciou sua operação, ele era pequeno o suficiente para que os nós pudessem apenas trocar informações diretamente para criar o primeiro anel e tabelas de fingers.

Depois disso, um procedimento automatizado é necessário.

Quando um novo nó (r) deseja-se conectar, ele precisa entrar em contato com um nó existente e pedir que este pesquise o endereço IP do sucessor(r) para ele. Em seguida, o novo nó pede o predecessor do sucessor(r). Por fim, o novo nó pede a ambos para inserir r entre eles e o anel.

Contudo, muitas tabelas de fingers podem estar erradas. Para corrigi-las, cada nó executa um processo em segundo plano que recalcula, periodicamente, cada finger, chamando o sucessor. Quando uma dessas consultas alcança um novo nó, a entrada de finger correspondente é atualizada.

Quando um nó sai de modo controlado, ele entrega suas chaves a seu sucessor e informa a seu predecessor sobre sua saída, para que ele possa se vincular ao sucessor do nó que está saindo.

Quando um nó falha, surge um problema, pois seu predecessor não tem mais um sucessor válido. Para aliviar esse problema, cada nó registra não apenas seu sucessor direto mas também seus sucessores diretos, para permitir que ele pule até s - l nós consecutivos (com falhas) e reconecte o anel – em caso de queda

Alguns clientes BitTorrent utilizam DHTs para fornecer um tracker totalmente distribuído do tipo que descrevemos. Grandes serviços de computação em nuvem, como o Dynamo da Amazon, por exemplo, também incorporam técnicas de DHT

1. O arquivo torrent possui os seguintes tipos de informação:

5) Tracker e chunks

2. O servidor que auxilia a comunicação entre dois computadores que utilizam o protocolo P2P BitTorrent é:

3) Tracker

3. A aplicação P2P que utiliza servidores centrais para a indexação de arquivos é:

1) Emule

Os sistemas de arquivos distribuidos (DFS) sao a vase para muitas aplicações distribuidas, já que permitem que vários processos compartilhem dados, de modo seguro e confiável, por longos pedíodos.

Um sistema de arquivos fornece serviços de arquivo para clientes. O componente primário de hardware que um servidor de arquivos controla é um conjunto de dispositivos locais de armazenamento secundário (geralmente, dicos magnéticos), nos quais arquivos são armazenados e recuperados, de acordo com as solicitações dos clientes. Em um DFS, a atividade de serviço deve ser realizada através da rede-

Esse sistema pode ser implementado como parte de um sistema operacional distribuido ou alternativamente por uma camada de software, cua tarefa é gerenciar a comunicação entre sistemas operacioais e convencionais e sistemas de arquivo.

As características que diferenciam um DFS são a multiplicidade e a autonomia de clientes e servidores no sistema.

Funções DFS: O DFS deve aparecer para seus clientes como um sistema de arquivos convencional centralizado. Portanto, é de sua responsabilidade localizar os arquivos e providenciar o transporte dos dados.

Essa transparência facilita a mobilidade do usuário, trazendo seu ambiente para onde quer que ele se conecte.

O referido sistema também possui, como importante medida de desempenho, a quantidade de tempo necessária para o atendimento das requisições de serviço.

Em sistemas convencionais, esse tempo consiste no tempo de acesso ao disco e em um pequeno intervalo de tempo de processamento da CPU.

Entretanto, em um DFS, um acesso remoto possui o overhead adicional atribuído à estrutura distribuída.

Por fim, o DFS gerencia um conjunto de dispositivos de armazenamento dispersos.

Um DFS fornece os seguintes serviços:

Serviço de Armazenamento: Serviço relacionado à alocação e ao gerenciamento de espaço e operações para armazenamento e recuperação de dados.

Serviço de Arquivo: Serviço que trata das operações com arquivos independentes, incluindo:

- Modos de acesso;

- Políticas de caching;

- Semântica de compartilhamento;

- Replicação;

- Controle de concorrência;

- Consistência dos dados etc.

Serviço de Nomeação: Serviço que fornece mapeamento entre nomes de arquivos e seus identificadores.

Nomeação e transparência

Em DFS, a nomeação é um mapeamento entre objetos lógicos e físicos. Já a transparência oculta o local em que o arquivo está localizado na rede.

Dado um nome de arquivo, o mapeamento retorna um conjunto de localizações dessas réplicas do arquivo.

Nessa abstração, ficam ocultas tanto a existência de múltiplas cópias quanto sua localização.

Estruturas de Nomeação

Veja, a seguir, as noções relacionadas aos mapeamentos de nomes em um DFS:

Transparência de localização – nesse caso, o nome de um arquivo não revela qualquer indicação de sua localização física de armazenamento;

Independência de localização – nesse caso, o nome de um arquivo não precisa ser alterado quando da mudança de sua localização física de armazenamento.

Um esquema de nomeação independente de localização é um mapeamento dinâmico, já que se pode mapear o mesmo nome de arquivo para diferentes locais em dois momentos distintos.

Portanto, a independência de localização é uma propriedade mais forte do que a transparência de localização.

Na prática, a maioria dos DFS atuais fornece um mapeamento estático e transparente de localização para nomes no nível do usuário. Entretanto, esses sistemas não suportam a migração de arquivos. Em outras palavras, a mudança automática da localização de um arquivo é impossível. Portanto, a noção de independência de localização é irrelevante para esses sistemas.

Os arquivos são associados permanentemente a um conjunto específico de blocos de disco. Arquivos e discos podem ser manualmente movimentados entre máquinas, mas a migração de arquivos implica uma ação automática iniciada pelo sistema operacional.

Esquemas de Nomeação

Abordagem mais simples

Nesse tipo de abordagem, o arquivo é identificado com alguma combinação de seu nome de host e seu nome local, o que garante um nome exclusivo em todo o sistema.

Esse esquema de nomeação não é transparente quanto à localização nem independente de localização. Entretanto, as mesmas operações de arquivo podem ser utilizadas tanto para arquivos locais quanto para arquivos remotos.

Abordagem popularizada pelo Network File System (NFS)

O NFS fornece um meio de anexar diretórios remotos a diretórios locais, dando, assim, a aparência de uma árvore de diretórios coerente.

Abordagem de única estrutura global de nomes

Nesta abordagem, uma única estrutura global de nomes abrange todos os arquivos do sistema.

A estrutura de sistema de arquivos composta é igual à estrutura de um sistema de arquivos convencional. Entretanto, na prática, os diversos arquivos especiais tornam esse objetivo difícil de ser atingido.

Modelos de acesso

A forma como uma requisição será tratada dependerá do modelo de acesso do sistema de arquivos que será dado aos arquivos.

Em um DFS, dois modelos de acesso podem ser utilizados:

Modelo de serviço remoto: um usuário solicira acesso a um arquivo remoto, o servidor armazena o arquivo será localizado pelo esquema de nomeação, e então, realizará a transferência dos dados. Uma das maneiras mais comuns para implementar o serviço remoto é o paradihma da RPC.

Modelo de Caching: Se os dados necessários para atender à solicitação de acesso ainda não estiverem armazenados em cache, uma cópia desses dados do servidor será trazida para o sistema cliente. Dessa forma, seus acessos serão executados na cópia do cache. A ideia é reter no cache blocos de disco recentemente acessados, de modo que acessos repetidos às mesmas informações possam ser manipulados localmente, sem tráfego de rede adicional.

Os arquivos ainda são identificados com uma cópia-mestra – residindo na máquina do servidor e mais cópias (ou partes) do arquivo disseminadas em diferentes caches. Quando uma cópia do cache for modificada, as mudanças precisarão se refletir na cópia-mestra para preservar a semântica de consistência relevante.

A granularidade dos dados do cache de um DFS pode variar de blocos de um arquivo a um arquivo inteiro.

Comparação entre armazenamento em cache e serviço remoto

Quando o armazenamento em cache é utilizado, o cache local pode manipular eficientemente um número substancial dos acessos remotos.

O aproveitamento da localidade nos padrões do acesso a arquivos torna o armazenamento em cache ainda mais atraente.

A maioria dos acessos remotos será atendida tão rapidamente quanto os acessos locais. Além disso, os servidores são contatados apenas ocasionalmente. Consequentemente, a carga no servidor e o tráfego na rede são reduzidos, e a possibilidade para a escalabilidade aumenta.

Por outro lado, quando o método de serviço remoto é utilizado, cada acesso remoto é manipulado através da rede. O prejuízo é associado ao aumento de tráfego na rede, à carga no servidor e à redução no desempenho.

Quando transmitimos grandes porções de dados (conforme é feito no armazenamento em cache), o overhead total da rede é mais baixo do que quando transmitimos séries de respostas a solicitações específicas (como no método de serviço remoto).

Além disso, as rotinas de acesso a disco no servidor podem ser mais otimizadas quando sabemos que as solicitações envolverão sempre grandes segmentos de dados contíguos – em vez de blocos aleatórios de disco.

O problema da consistência do cache é a principal desvantagem do armazenamento em cache. Quando os padrões de acesso exibem gravações não frequentes, o armazenamento em cache é superior.

Entretanto, quando as gravações são frequentes, os mecanismos empregados para resolver o problema da consistência incorrem em overhead significativo em termos de desempenho, tráfego na rede e carga no servidor.

Para que o armazenamento em cache traga benefícios, a execução deve ser levada a efeito em máquinas que tenham discos locais ou memórias principais de grande capacidade. O acesso remoto em máquinas com memória de pouca capacidade e sem discos deve ser realizado por meio do método de serviço remoto.

No armazenamento em cache, como os dados são transferidos em massa entre o servidor e o cliente – em vez de em resposta às necessidades específicas de uma operação de arquivo -, a interface de mais baixo nível entre máquinas é diferente da interface de mais alto nível do usuário.

Por outro lado, o modelo do serviço remoto é apenas uma extensão da interface local do sistema de arquivos através da rede. Sendo assim, a interface entre máquinas espelha a interface do usuário.

Stateful (serviço com estado) versus stateless (serviço sem estado)

Existem duas abordagens para o armazenamento de informações no lado do servidor, quando um cliente acessa arquivos remotos, quais sejam:

· O servidor busca cada arquivo que estiver sendo acessado pelo cliente; ou

· O servidor simplesmente fornece blocos conforme são solicitados pelo cliente, sem saber como esses blocos estão sendo utilizados.

No primeiro caso, o serviço fornecido tem estado (stateful); no outro, o serviço não tem estado (stateless).

Stateful (serviço com estado): No serviço de arquivos com estado, um cliente deve executar uma operação open () sobre um arquivo antes de acessá-lo. O servidor, então, extrai informações sobre o arquivo em seu disco, armazena essas informações em memória e fornece ao cliente um identificador de conexão único para o cliente e o arquivo aberto.

Em termos do UNIX, o servidor extrai o I-node e fornece ao cliente um descritor de arquivo, que serve como um índice para a tabela de inodes em memória.

No stateful, o servidor deve reclamar o espaço de memória principal utilizado pelos clientes que não estão mais ativos.

O ponto chave relacionado à tolerância a falhas em uma abordagem de serviço com estado é que o servidor mantém informações sobre seus clientes na memória principal.

Stateless (serviço sem estado): O serviço de arquivos sem estado evita informações de estado, tornando cada solicitação autossuficiente. Em outras palavras, cada solicitação identifica completamente o arquivo e sua posição no arquivo (para acessos de leitura e gravação).

No stateless, o servidor não precisa manter uma tabela de arquivos abertos na memória principal. Além disso, não há necessidade de estabelecer e terminar uma conexão por operações open () e close ().

Um processo-cliente abre um arquivo, e essa abertura não resulta no envio de uma mensagem remota.

Leituras e gravações são realizadas como mensagens remotas (ou consultas ao cache). O fechamento final pelo cliente, por sua vez, resulta novamente em apenas uma operação local.

Vantagens e distinção entre satateful e stateless

VANTAGENS: A vantagem de um serviço com estado sobre um serviço sem estado é o aumento do desempenho. Informações de arquivo são armazenadas em cache na memória principal e podem ser facilmente acessadas via identificador de conexão, evitando, assim, acessos ao disco.

Além disso, um servidor com estado sabe se um arquivo está aberto para acesso sequencial e pode, portanto, ler os próximos blocos à frente. Servidores sem estado não podem fazer isso, pois não conhecem o objetivo das solicitações do cliente.

DISTINÇÃO: distinção entre stateful e stateless torna-se mais evidente quando consideramos os efeitos de uma queda durante uma atividade de serviço. Nessa situação, um servidor com estado perde todos os seus estados voláteis.

A garantia de recuperação sem prejuízo desse servidor implica a restauração de seu estado, normalmente realizada por um protocolo de recuperação baseado em um diálogo com os clientes.

STATEFULL: Do ponto de vista do cliente, não há diferença entre um servidor lento e um servidor em recuperação. Se não receber resposta, o cliente continuará a retransmitir sua solicitação.

Em alguns ambientes, o stateful é uma necessidade. Se o servidor empregar o método iniciado para validação do cache, não poderá oferecer serviço sem estado, pois deverá manter um registro dos arquivos que foram armazenados em cache e dos clientes que os armazenaram.

STATELESS: Um problema diferente é causado por falhas dos clientes. O servidor precisa tornar-se consciente dessas falhas, de modo que possa reclamar o espaço alocado para registrar o estado dos processos-clientes que falharam.

O stateless evita esses problemas, pois um servidor recentemente recuperado pode responder a uma solicitação autossuficiente sem qualquer dificuldade. Portanto, os efeitos de falhas e de recuperações do servidor são quase imperceptíveis.

Replicação de arquivos

Replicação Explícita: Quando a responsabilidade fica a cargo do programador. Nesse caso, o serviço de diretórios pode permitir diversos índices de arquivos para cada arquivo.

Esse tipo de replicação é de difícil implementação e não permite a aplicação da transparência.

Replicação Atrasada (lasy): Quando apenas uma cópia é realizada em um servidor. Nesse caso, o servidor possui a responsabilidade de propagar as atualizações e de garantir que outro servidor responda no caso de sua impossibilidade.

Replicação em grupos: Quando a operação de escrita é realizada em todos os arquivos ao mesmo tempo (multicast atômico).

SEMÂNTICA DE COMPARTILHAMENTO

Na semântica Unix, as alterações são visíveis instantaneamente.

Em sistemas de um único processador, normalmente, a semântica declara que, quando uma operação read vem depois de uma operação write, aquela retorna o valor que acabou de ser escrito. Veja, a seguir, uma figura que representa uma semântica Unix:

De maneira semelhante, quando duas operações write ocorrem em rápida sucessão, seguidas por uma read, o valor lido é o valor armazenado pela última write. Na verdade, o sistema impõe uma ordenação de tempo absoluto a todas as operações e sempre retorna o valor mais recente.

Em um sistema distribuído, a semântica Unix pode ser alcançada com facilidade, contanto que haja somente um servidor de arquivos e que os clientes não os armazenem.

Todas as operações read e write vão diretamente para o servidor de arquivos, que as processa estritamente em sequência. Essa abordagem gera a semântica Unix, exceto pelo pequeno problema de que atrasos de rede podem fazer com que uma read que ocorreu em um microssegundo após uma write chegue antes ao servidor e, por isso, obtenha o valor antigo.

SEMÂNTICA DE SESSÃO: Em vez de requerer que uma read veja os efeitos de todas as operações write anteriores, podemos estabelecer uma nova regra em que: As alterações em um arquivo aberto sejam incialmente visíveis apenas para o processo, que modificou a maquina. As alterações devem ficar visíveis para outros processos ou máquinas, somente quando o arquivo for fechado.

Arquivos Imutáveis:

Um um sistema distribuído, uma abordagem completamente diferente da semântica de compartilhamento de arquivos é tornar imutáveis todos eles.

Dessa forma, não existe nenhum modo de abrir um arquivo para escrita. Na verdade, as únicas operações em arquivos são create e read.

O que se permite é criar um arquivo inteiramente novo e passá-lo para o sistema de diretório sob o nome de um arquivo previamente existente, que, agora, se tornará inacessível (ao menos sob esse nome).

Por isso, embora seja impossível modificar o arquivo específico, continua possível substituir, atomicamente, esse arquivo por um novo. Em outras palavras, embora arquivos não possam ser atualizados, os diretórios podem.

Uma vez decidido que os arquivos não podem ser alterados de jeito algum, o problema de como lidar com dois processos – como escrever em um arquivo e ler esse arquivo – simplesmente desaparece, o que simplifica, consideravelmente, o projeto.

Resta, então, o problema que ocorre quando dois processos tentam substituir o mesmo arquivo simultaneamente. Como acontece com a semântica de sessão, a melhor solução para esse caso seria permitir que um dos novos arquivos substituísse o antigo – seja este o último, seja a substituição não determinística.

Um problema um pouco mais desagradável diz respeito a como prosseguir se um arquivo for substituído enquanto outro processo estiver ocupado, lendo esse mesmo arquivo.

Uma solução é dar um jeito de o processo leitor continuar usando o arquivo antigo, mesmo que este não esteja mais em nenhum diretório, comparado ao modo como o Unix permite a um processo que tenha um arquivo aberto continuar a usá-lo, mesmo depois de esse arquivo ter sido apagado de todos os diretórios.

Outra solução é detectar se o arquivo foi alterado e fazer com que as tentativas subsequentes de ler esse arquivo falhem.

Network File System (NFS) : O padrão NFS mais recente é a Versão 4 que difere fundamentalmente das versões anteriores. Essa versão apresenta uma mudança significativa, em que o protocolo tem estado, o que significa que o servidor mantém o estado da sessão do cliente do momento em que o arquivo remoto é aberto até que ele seja fechado.

Sendo assim, o protocolo NFS fornece operações open() e close(). As versões anteriores do NFS – que não têm estado – não fornecem tais operações.

Além disso, as versões anteriores especificam protocolos separados para a montagem de sistemas de arquivos remotos e para o trancamento (lookup) desses arquivos. Em particular, o protocolo de montagem foi eliminado, permitindo que o NFS funcionasse com firewalls de rede.

A Versão 4 do NFS aprimorou a capacidade de os clientes armazenarem em cache local os dados dos arquivos, melhorando o desempenho do DFS, já que os clientes são capazes de resolver mais acessos a arquivos a partir do cache local do que passando pelo servidor.

Outro benefício dessa versão permite que os clientes solicitem locks de arquivos aos servidores. Se o servidor atender à solicitação, o cliente manterá o lock até que ele seja liberado ou que sua concessão expire.

Tradicionalmente, os sistemas baseados no Unix oferecem trancamento aconselhável de arquivos, enquanto os sistemas operacionais Windows utilizam o trancamento obrigatório.

Para permitir que o NFS funcione bem com sistemas não Unix, ele também fornece trancamento obrigatório.

Os novos mecanismos de trancamento e armazenamento em cache são baseados no conceito de delegação. O cliente delegado mantém em cache a versão corrente do arquivo, e outros clientes podem solicitar a ele o acesso ao lock e o conteúdo do arquivo, até que o cliente delegado desista do lock e da delegação.

Finalmente, enquanto as versões anteriores do NFS são baseadas no protocolo de rede UDP, a Versão 4 é baseada no TCP, que permite melhor adaptação a cargas variadas de tráfego na rede. A delegação dessas responsabilidades aos clientes reduz a carga no servidor e melhora a coerência do cache.

É desejável ocultar os detalhes de replicação dos usuários. O mapeamento de um nome de arquivo copiado em uma réplica específica é tarefa do esquema de nomeação.

A existência de réplicas deve ser invisível aos níveis mais altos. Nos níveis mais baixos, entretanto, as réplicas devem ser diferenciadas umas das outras por distintos nomes de mais baixo nível.

Outro requisito de transparência é fornecer controle de replicação nos níveis mais altos.

1. O armazenamento em cache com gravação direta é denominado:

R) Write-through

2. Quando o nome de um arquivo não revela qualquer indicação de sua localização física de armazena¬mento, podemos afirmar que o DFS implementa:

R) Transparência de localização

3. Com relação aos serviços com estado e os serviços sem estado, indique, dentre as afirmativas a seguir, quais são verdadeiras (V) e quais são falsas (F), assinalando a opção CORRETA:

I. No serviço com estado, o servidor fornece ao cliente um identificador de conexão utilizado para acessos subsequentes até que a sessão termine.

III. No serviço sem estado, o servidor não precisa man¬ter uma tabela de arquivos abertos na memória principal.

Os serviços web (web services) abrangem um conjunto de padrões relacionados que podem habilitar quaisquer duas aplicações de computador a se comunicarem e a trocarem dados, via internet, por meio de protocolos padrões.

Para um sistema distribuído funcionar corretamente, componentes de aplicações que executam em computadores diferentes por toda a rede devem poder comunicar-se.

Tecnologias como DCOM e CORBA habilitam a comunicação entre componentes distribuídos. Entretanto, impõem um custo para viabilizar essa comunicação. Muitas vezes, seus componentes se comunicam via uma ponte entre COM e CORBA.

Funcionamento: Os serviços web funcionam a partir do uso de padrões abertos (não proprietários).

Em outras palavras, teoricamente, esses serviços podem habilitar a comunicação entre quaisquer dois componentes de software – independentemente das tecnologias utilizadas para criar os componentes ou as plataformas nas quais residem (interoperabilidade).

Os web services fornecem, de forma mais genérica, uma interface de serviços para a interação com os servidores.

Sendo assim, as aplicações podem utilizar sua própria linguagem, que será traduzida para uma linguagem comum: o formato XML.

Os serviços web melhoram o desenvolvimento de software colaborativo, permitindo que desenvolvedores criem aplicações combinando códigos escritos em qualquer linguagem de qualquer plataforma.

Esses serviços também promovem programação modular. Cada função específica de uma aplicação pode ser apresentada como um serviço web separado.

Indivíduos ou empresas podem criar suas próprias aplicações exclusivas, mesclando e compatibilizando os web services que fornecem a funcionalidade de que precisam.

Arquitetura (SOA), caracterízada pela as seguintes propriedades: Visão Lógica, Orientação à mensagem, orientação à descrição, Granularidade, orientação à rede, plataforma neutra.

Componentes da arquitetura SOA

Os componentes da arquitetura SOA representam uma coleção de serviços que se comunicam da troca de mensagens XML:

Provedor de Serviço WEB: Responsável pela descrição das informações de conexão na chamada ao serviço e pela publicação e descrição do web service no registro dos serviços.

Registros de Serviços: Manutenção de diretório com as informações sobre os serviços. Na SOA, o padrão adotado para registro é o Universal Description, Discovery and Integration (UDDI).

Consumidor de Serviço: Responsável pela descoberta de um serviço, pelo recebimento de sua descrição e por sua utilização para a conexão a um provedor. Seu objetivo é chamar um serviço web.

Plataforma .NET da Microsoft

A iniciativa .NET inclui o ambiente de desenvolvimento integrado Visual Studio .NET, que habilita programadores a desenvolverem serviços web em uma variedade de linguagens – incluindo C++, C# e Visual Basic .NET.

Os serviços web .NET – fundamentais da iniciativa .NET – estendem o conceito de reutilização de software à internet, permitindo que desenvolvedores reutilizem componentes de software que residam em outras máquinas ou plataformas.

Empregando serviços web como blocos de construção reutilizáveis, os programadores podem-se concentrar em suas especialidades, sem ter de implementar cada componente de uma aplicação.

Por exemplo, uma empresa que está desenvolvendo uma aplicação de e-commerce pode assinar serviços web que processam pagamentos e autenticam usuários, o que habilita o programador a se concentrar em outros aspectos mais exclusivos daquela aplicação.

Em .NET, um serviço web é uma aplicação armazenada em uma máquina que pode ser acessada por uma outra através de uma rede.

Em sua forma mais simples, um serviço web criado em .NET é uma classe – ou um agrupamento lógico – de métodos de dados que simplificam a organização do programa.

As classes de serviço web da .NET contêm certos métodos – denominados métodos de serviços web – que são especificados como parte do web service. Esses métodos podem ser invocados remotamente, usando RPC.

O web service é definido pela W3C como um sistema de software projetado para fornecer INTEROPERABILIDADE entre máquinas em determinada rede.

1. A linguagem baseada em XML que descreve o que um web service pode fazer, onde ele reside e como chamá-lo é denominada:

R) WSDL

2. O protocolo baseado em XML para troca de informação estruturada com web services em redes de computadores é chamado de:

R) SOAP

3. A especificação para publicar e localizar informações sobre web services denomina-se:

R) UDDI

Computação ubiqua, que tem como foco operações voltadas para a tarefa, e não para a ferramenta. Nesse caso, a computação está embutida em nosso dia a dia.

De acordo com Loureiro: A computação ubiqua é um novo paradigma no qual dispositivos com capacidade de processamento e comunicação são embutidos nos elementos do dia a dia, provendo serviços de forma transparente aos usuários.

A computação ubíqua está posicionada entre a computação móvel e a computação pervasiva, conforme apresenta a figura ao lado:

Nesse tipo de computação, há:

Integração entre mobilidade e presença distribuída;

Inovação em interfaces – tendência para as interfaces naturais;

Determinados problemas, tais como de segurança, complexidade e

privacidade.

A computação ubíqua pode ser aplicada nos seguintes sistemas:

· Ambientes inteligentes;

· nterfaces hands-free (sem as mãos) – reconhecimento de voz, liveboards, pads e tabs;

· Consciência de contexto – além da interação física do usuário a partir da utilização de sensores;

· Computação de vestir (wearable) – tecnologia que utiliza acessórios como interfaces;

· Computação sensível à posição;

· Computação desagregada – reconfiguração automática;

· Realidade aumentada – combinação de computadores wearable com informações de sensores de posição;

· Interfaces sensíveis a objeto – Radio-Frequency IDentification (RFID).

Exemplos

Veja um exemplo de aplicação da computação ubíqua:

A computação em nuvens consiste na utilização de recursos de processamento e armazenamento de computadores compartilhados e interligados por meio da internet.

A cloud computing segue os moldes da computação em grid. Nesse caso, o acesso aos dados e às aplicações é permitido a partir de qualquer computador que tenha conexão com a internet, independente de sua plataforma.

Clique aqui para ver uma figura que apresenta as vantagens da computação em nuvem.

Serviços da computação em Nuvens

Os tipos de serviços em cloud computing podem ser classificados nos seguintes modelos:

Software as a Service (SaaS) – Software como Serviço

Trata-se do uso de um software através da internet. Em outras palavras, o usuário utiliza o software como serviço sem a necessidade de aquisição ou instalação local.

São exemplos do modelo SaaS:

Google Docs; HP SaaS;

Microsoft Sharepoint Online; IBM SaaS.

Os tipos de serviços em cloud computing podem ser classificados nos seguintes modelos:

Platform as a Service (PaaS) – Plataforma como Serviço

Trata-se da utilização apenas da plataforma como:

Um banco de dados;

Um web service;

Serviços para desenvolvimento, testes etc.

Normalmente, as aplicações desenvolvidas em uma PaaS ficam vinculadas ao fornecedor.

São exemplos do modelo PaaS: Windows Azure e Google App Engine.

Os tipos de serviços em cloud computing podem ser classificados nos seguintes modelos:

Trata-se de ferramentas de desenvolvimento utilizadas como:

Ferramentas compartilhadas;

Ferramentas de desenvolvimento web-based;

Serviços baseados em mashup.

Os tipos de serviços em cloud computing podem ser classificados nos seguintes modelos:

Infrastructure as a Service (IaaS) – Infraestrutura como Serviço

Trata-se da entrega de infraestrutura como serviço.

Em outras palavras, o foco está na estrutura do hardware ou de máquinas virtuais, no armazenamento, o que permite uma ampla diversidade de softwares.

São exemplos do modelo IaaS:

Amazon EC2;

GoGrid.

Os tipos de serviços em cloud computing podem ser classificados nos seguintes modelos:

Trata-se da solução terceirizada em comunicação.

Os fornecedores desse tipo de serviço são responsáveis pelo gerenciamento de hardwares e softwares, entregando serviços como VoIP e serviços de mensagens instantâneas, além da capacidade de gerenciar videoconferências.

Um exemplo do modelo CaaS é o Microsoft Lync.

Existem quatro tipos de implementação em cloud computing, quais sejam:

De acordo com o artigo da Computeworld (2008), há sete princípios de segurança em uma rede em nuvem. São eles:

Acesso privilegiado de usuários : A sensibilidade de informações confidenciais nas empresas as obriga a controlar o acesso dos usuários e a informação bem específica de quem terá privilégio de administrador.

O objetivo é que esse administrador possa controlar os referidos acessos.

Compliance com regulamentação: As empresas são responsáveis pela segurança, pela integridade e pela confidencialidade de seus próprios dados.

Sendo assim, os fornecedores de cloud computing devem estar preparados para auditorias externas e certificações de segurança.

Localização dos dados: A empresa que usa cloud provavelmente não sabe onde os dados estão, de fato, armazenados – talvez nem o país no qual as informações estejam guardadas.

Portanto, o fornecedor deve estar disposto a se comprometer a armazenar e a processar dados em jurisdições específicas, assumindo um compromisso – em contrato – de obedecer aos requerimentos de privacidade que o país de origem da empresa exige.

Segregação dos dados: Geralmente, uma empresa divide um ambiente com dados de diversos clientes.

Nesse caso, precisamos entender o que é feito para a separação de dados e que tipo de criptografia é seguro o suficiente para o funcionamento correto da aplicação.

Recuperação dos dados: O fornecedor em cloud deve saber onde estão os dados da empresa e o que é preciso para recuperá-los em caso de catástrofe.

Qualquer aplicação que não faça réplica dos dados e da infraestrutura em diversas localidades estará vulnerável à falha completa. Por isso, é importante ter um plano de recuperação completo e um tempo estimado para esse plano.

Apoio à investigação: A auditabilidade de atividades ilegais pode-se tornar impossível em cloud computing, uma vez que há uma variação de servidores em função do tempo em que estão localizados os acessos e os dados dos usuários.

Diante disso, é importante obter um compromisso contratual com a empresa fornecedora do serviço e uma evidência de sucesso no passado para esse tipo de investigação.

Viabilidade em longo prazo: No mundo ideal, o fornecedor de cloud computing jamais vai falir ou ser adquirido por uma empresa maior.

Por isso, a empresa precisa garantir que seus dados estarão disponíveis caso o fornecedor de cloud computing deixe de existir, ou seja, caso seja migrado para uma empresa maior.

Nesse sentido, é importante haver um plano de recuperação de dados e um formato específico para que esse plano possa ser utilizado em uma aplicação substituta.

1.São características da computação em nuvem, EXCETO:

R) Baixa escalabilidade

2. O uso de um software através da internet pode ser classificado como:

R) SaaS

O primeiro problema existe porque nem todos os peers terão todo o conteúdo, pelo

menos inicialmente.

A técnica usada no BitTorrent é a de que cada provedor de conteúdo possa criar uma

descrição de conteúdo – chamada torrent.

A torrent é muito menor que o conteúdo e é usada por um peer para verificar a

integridade dos dados que ele baixa de outros peers. Outros usuários que querem

baixar o conteúdo precisam primeiro obter a torrent, encontrando-a, digamos, em

uma página Web que anuncia o conteúdo.

A torrent é apenas um arquivo, em formato especificado, que contém dois tipos de

informação: o nome de um tracker e os chuncks

O arquivo de torrent contém o nome de cada chunk, dado como um hash

SHA-1 de 160 bits do chunk. Dado o tamanho dos chunks e dos hashes, o arquivo de torrent é,

pelo menos, três ordens de grandeza menor que o conteúdo, de modo que pode ser

transferido rapidamente.

Para realizar o download do conteúdo descrito em uma torrent, primeiramente, um

peer entra em contato com o tracker para a torrent. O tracker é um servidor que

mantém uma lista de todos os outros peers que estão ativamente fazendo download

e upload do conteúdo. Esse conjunto de peers é chamado de swarm.

Os membros do swarm entram em contato com o tracker regularmente para

informar que ainda estão ativos, bem como ao saírem do swarm. Quando um novo

peer entra em contato com o tracker para se juntar ao swarm, o tracker lhe informa

sobre outros peers no swarm.

Modelo de caching: esquema básico de armazenamento em cache

O armazenamento em cache do DFS poderia ser facilmente chamado de

memória virtual de rede.

Isso porque esse armazenamento atua de modo semelhante à memória virtual

paginada por demanda, exceto pelo fato de a memória de retaguarda não ser,

normalmente, um disco local, e sim um servidor remoto.

O NFS permite que o espaço de permuta seja montado remotamente. Dessa

forma, ele pode implementar, realmente, a memória virtual sobre uma rede,

apesar da perda em desempenho.

Caches em disco possuem uma clara vantagem sobre os caches na memória

principal: eles são confiáveis.

Se o cache for mantido em memória volátil, em caso de queda do sistema,

modificações nos dados do cache serão perdidas. Se os dados do cache forem

mantidos em disco, eles ainda estarão ali durante a recuperação, e não será

preciso extraí-los novamente.

Muitas implementações de acesso remoto podem ser pensadas como híbridos

de armazenamento em cache e serviço remoto.

No NFS, por exemplo, a implementação é baseada em serviço remoto, mas é

ampliada, por razões de desempenho, com o armazenamento em cache de

memória para clientes e servidores.

O protocolo NFS e a maioria das implementações não oferecem

armazenamento em cache de disco. Implementações recentes do NFS no Solaris (a partir do Solaris 2.6) incluem uma opção de armazenamento em

cache de disco no lado do cliente: o sistema de arquivos cachefs.

Tão logo o cliente NFS leia os blocos de um arquivo a partir do servidor, ele os

armazenará em cache na memória, assim como em disco. Se a cópia da

memória for removida ou mesmo se o sistema for reinicializado, o cache em

disco será referenciado.

Se um bloco requerido não estiver em memória nem no cachefs em disco, uma

RPC será enviada ao servidor para recuperar o bloco, que será gravado no

cache em disco e armazenado no cache da memória para utilização por parte

do cliente.

Modelo de caching: política de atualização de cache

A forma utilizada para gravar blocos de dados modificados na cópia-mestra do

servidor tem implicação direta sobre o desempenho e a confiabilidade do

sistema.

Conheça, a seguir, algumas maneiras de gravar blocos de dados:

Write-through (gravação direta)

A write-through (gravação direta) é a forma mais simples de gravar os dados

diretamente no disco tão logo sejam colocados em algum cache.

Sua vantagem é a confiabilidade: poucas informações são perdidas quando um

sistema-cliente cai.

É necessário que cada acesso de gravação espere até que as informações

sejam enviadas ao servidor, o que provoca um fraco desempenho de gravação.

O armazenamento em cache com gravação direta é equivalente ao uso do

serviço remoto para acessos de gravação e à exploração do cache somente

para acessos de leitura.

Write-back (gravação retardada)

Na write-back (gravação retardada), as atualizações na cópia-mestra são

adiadas.

As modificações são gravadas no cache para, então, serem gravadas no

servidor, em um momento posterior.

Essa política tem duas vantagens sobre a gravação direta, quais sejam:

 Em primeiro lugar, como as gravações são feitas no cache, os acessos

de gravação completam-se muito mais rapidamente;

 Em segundo lugar, os dados podem ser sobrepostos antes de serem

gravados de volta no servidor – caso em que apenas a última

atualização precisa ser completamente gravada.

Os esquemas de gravação retardada introduzem problemas de confiabilidade,

pois dados não gravados são perdidos sempre que uma máquina de usuário

cai.

As variações da política de gravação retardada diferem quanto ao momento

em que os blocos de dados modificados são descarregados para o servidor.

No NFS com cachefs, quando as gravações são executadas no servidor, elas

também são executadas na área de cache do disco local, para manter todas as

cópias consistentes.

Sendo assim, o NFS com cachefs melhora o desempenho em relação ao NFS

padrão em uma solicitação de leitura bem-sucedida do cache do cachefs, mas

diminui o desempenho para solicitações de leitura ou gravação, com uma

falha no cache.

Write on close (gravação ao encerrar a sessão)

Outra variação da gravação retardada é gravar os dados de volta no servidor

quando o arquivo é fechado.

Essa política de gravação ao encerrar a sessão (write on close) é utilizada no

Andrew File System (AFS).

Em caso de arquivos que sejam abertos por curtos períodos ou raramente

modificados, a referida política não reduz, de modo significativo, o tráfego na

rede.

A write on close requer que o processo de fechamento aguarde enquanto o

arquivo está sendo gravado por uma operação de gravação direta, o que reduz

as vantagens de desempenho das gravações retardadas.

Para arquivos que fiquem abertos por longos períodos e sejam modificados

com frequência, são claras as vantagens de desempenho dessa política em

relação à gravação retardada – com descargas mais frequentes.

Modelo de caching: consistências

Uma máquina-cliente enfrenta o problema de decidir se uma cópia dos dados

armazenada em cache local é consistente com a cópia-mestra.

Se a máquina-cliente determinar que seus dados no cache estejam

desatualizados, os acessos não poderão mais ser atendidos para esses dados.

Sendo assim, uma cópia atualizada dos dados precisará ser armazenada no

cache.

Existem duas abordagens para verificar a validade de dados no cache, quais

sejam:

Abordagem iniciada pelo cliente

Nesta abordagem, o cliente inicia uma verificação de validade, na qual

contata o servidor, e observa se os dados locais estão consistentes com a

cópia-mestra.

A frequência da verificação de validade é o ponto-chave dessa abordagem e

determina a semântica de consistência resultante.

Essa frequência pode variar de uma verificação antes de cada acesso a uma

verificação somente no primeiro acesso a um arquivo.

Dependendo de sua frequência, a verificação de validade pode sobrecarregar

tanto a rede quanto o servidor.

Abordagem iniciada pelo servidor

Nesta abordagem, o servidor registra, para cada cliente, os arquivos (ou

partes dos arquivos) armazenados em seu cache. Quando o servidor detectar

uma inconsistência, ele deverá reagir.

A ocorrência da inconsistência pode ser causada quando dois clientes

diferentes, em modalidades conflitantes, armazenam um arquivo em cache.

Se a semântica do UNIX for implementada, poderemos resolver a

inconsistência fazendo o servidor desempenhar um papel ativo.

O servidor deve ser notificado sempre que um arquivo for aberto, e a

modalidade pretendida (leitura ou gravação) deverá ser indicada para cada

abertura.

O servidor poderá agir, então, quando detectar que um arquivo foi aberto

simultaneamente em modalidades conflitantes, desabilitando o

armazenamento em cache para esse arquivo em particular

Como os peers encorajam uns aos outros para que façam upload do conteúdo

para outros, além do download de conteúdo para eles mesmos?

No terceiro problema, os nós da CDN são preparados exclusivamente para fornecer

conteúdo aos usuários. Os nós P2P, por sua vez, não o são. Esses nós são os

computadores dos usuários, que podem estar mais interessados em conseguir um

conteúdo específico do que em ajudar outros usuários com seus downloads.

Os nós que capturam recursos de um sistema sem contribuir com nada em troca são

chamados de free-riders ou leechers. Se houver muitos deles, o sistema não

funcionará bem. Os primeiros sistemas P2P eram conhecidos por hospedar os freeriders, de modo que o BitTorrent procurou minimizá-los (SAROIU et al., 2003).

A técnica usada nos clientes BitTorrent é recompensar os peers que mostram bom

comportamento de upload. Cada peer seleciona aleatoriamente os outros,

capturando seus chunks enquanto faz o upload de chunks para eles.

O peer continua a trocar chunks apenas com um pequeno número de peers que

oferecem o desempenho de download mais alto, embora também experimentem

aleatoriamente outros peers para encontrar bons parceiros. Esse experimento

aleatório também permite que os novos usuários obtenham chunks iniciais que

podem trocar com outros peers. Os peers com os quais um nó está trocando chunks

são considerados como unchoked.

Com o tempo, esse algoritmo deverá combinar peers, uns com os outros, com upload

comparável e taxas de download. Quanto mais um peer estiver contribuindo com os

outros, mais ele poderá esperar em retorno.

Usar um conjunto de peers também ajuda a saturar a largura de banda de um peer

para aumentar o desempenho. Ao contrário, se um peer não estiver fazendo upload

de chunck para outros peers ou se estiver fazendo isso muito lentamente, ele será,

mais cedo ou mais tarde, cortado ou choked.

Evolução:

Primeiros computadores: grandes e caros.

Anos 50-60: spooling, multiprogramação.

Início dos anos 60: sistemas time sharing.

Final dos anos 60 e início dos anos 70: surgimento de redes de computadores.

A partir dos anos 70: inicia-se a pesquisa em sistemas distribuídos.

Sistemas podem ser divididos em:

· Fortemente acoplados - quando os processadores compartilham uma mesma memória principal.

· Fracamente acoplados – os diversos processadores/estações presentes no sistema utilizam sua memória local individualmente.

· Sistemas centralizados - Multiprocessador de memória compartilhada é um sistema de computador no qual duas ou mais CPUs compartilham acesso total a uma memória principal comum. Multiprocessadores são populares e atrativos, porque oferecem um modelo de comunicação simples, e a sincronização é possível mediante o emprego de diversas técnicas bem definidas. Uma desvantagem é que os multiprocessadores de grande porte são difíceis de construir e, por isso, são caros.

· Sistemas distribuídos - Uma solução alternativa que tem sido empregada com sucesso para solucionar esse problema é a utilização de multicomputadores, que são CPUs que não compartilham memória principal. Cada CPU tem sua própria memória e é gerenciada por um sistema operacional individualmente. Esses sistemas também são conhecidos como cluster – COWS (cluster of workstations - aglomerados de estações de trabalho).

• Sistema distribuído permite uma nova forma de fazer ciência

–Teoria -> experimentos

–Teoria -> simulações

•Vantagens

–Possibilidade de repetição de eventos

–Manipulação de parâmetros

–Estudo de sistemas onde não há teorias exatas

•Problemas

–Muito grandes: modelagem da terra/clima, simulações de reservatórios de petróleo, problemas com grandes escalas (cosmologia).

–Muito pequenos: projeto de remédios, projetos de chips, biologia estrutural, física de partículas.

–Muito complexos: física de partículas, dinâmica de fluidos, modelagem de comportamento de pessoas.

–Muito caros: produção e exploração de petróleo, simulação de acidentes.

–Muito perigosos: tolerância a falhas em aviões, teste de dispositivos nucleares, simulação de estratégias de defesa.

PARALELISMO X COMPUTAÇÃO PARALELA

· Paralelismo

ü Projeto de uma CPU

ü Projeto de uma arquitetura paralela

ü E/S sobreposta ao processamento

· Computação paralela

ü Coleção de elementos de processamento

ü Trabalhando em conjunto para a realização de uma tarefa

Paralelismo

Dentro de um processador

1. Busca a informação

2. Decodifica Instrução

3. Busca Operandos

4. Executa Instrução

Clusters

Ø Definição: Conjunto de computadores independentes conectados, usados como recurso unificado para computação. Sistema com imagem única (SSI).

Ø Benefícios

o Custo/benefício: redução de custo para se obter processamento de alto desempenho.

o Escalabilidade: possibilidade de adição de novos computadores, sendo adicionados a medida que cresça a carga.

o Alto Desempenho: possibilidade de resolver problemas complexos através de programação e processamento paralelo.

o Independência de Fornecedores: utilização de hardware aberto, livre de uso de licenças.

o Tolerância a Falha: o aumento da confiabilidade do sistema como um todo, caso alguma parte falhe.

Computação centralizada

· Mainframe

Termo utilizado para se referenciar a um grande computador, normalmente produzido por uma grande empresa. O nome tem origem na forma com que estes computadores eram construídos. Todos os componentes (processador, memória...) do computador principal (main) são colocados em uma única estrutura (frame).

o Características

ü Sistemas multiusuários

ü Sistemas proprietários -> hardware, software, rede

ü Instalação e manutenção feita pelo fabricante -> confiabilidade X custo

· Microcomputadores e redes de computadores

Ampliação do parque computacional, em função de:

o Processadores mais rápidos e mais baratos.

o Redes mais rápidas e acessíveis.

o Liberdade de escolha.

o Menor custo de manutenção.

o Necessidade inerente de conectividade.

o Aplicação básica: compartilhamento de recursos.

Evolução: Os terminais foram sendo substituídos pelos primeiros microcomputadores que começavam a ficar obsoletos. Em geral, o uso de um programa emulador de terminais e de uma unidade de disquete era suficiente para que um simples PC-XT executasse essa tarefa, uma vez que só precisaria executar o emulador. A partir deste ponto, o micro passaria a se comportar como um terminal. Em alguns casos, era necessário o uso de uma placa que compatibilizasse a forma de comunicação serial entre os dois computadores.

· Sistemas Distribuidos

Utilização das redes de computadores para execução colaborativa e cooperativa de aplicações e não somente para compartilhamento de recursos.

Sistemas Distribuidos = computadores + rede + aplicação

o Conceito: É um sistema em que os computadores estão conectados em rede e coordenam suas ações através de troca de mensagens.

o Denifição de sistema distribuido:

Ø Colouris: Um sistema no qual os componentes de hardware ou software, localizados em computadores interligados em rede, se comunicam e coordenam suas ações apenas enviado mensagens entre sí.

Ø Tanenbaum: Um sistema distribuido é um conjundo de computadores independetes que se apresenta a seus usuários como um sistema único e coerente.

Ø Siberschatz: Coleção de processadores que não compartilham memória ou relógio.

o Principais motivações: necessidade pelo compartilhamento de recursos e

o Características de um sistema distribuído:

Ø baixo acoplamento e atrasos na comunicação;

Ø processos em sistemas computacionais distintos com probabilidade de falhas

Ø Comunicação geralmente não confiável, onde existem atrasos, variação de atrasos, perdas e, em alguns casos, baixas larguras de banda

Ø dificuldade em definir a ordem dos eventos e estado global do sistema, uma vez que a comunicação acontece pela troca de mensagens

Ø Ambiente geralmente marcado pela heterogeneidade

o Comparação com sistemas centralizados

Ø Vantagens

ü Melhor relação preço/desempenho

ü Capacidade de crescimento incremental (escalabilidade)

ü T olerância a falhas

Ø Desvantagens

ü Falta de padronização para desenvolvimento de software

ü Falta de uma divisão clara entre sistema/aplicação

ü Latência e possibilidade de congestionamento na rede

ü Redução da segurança

o Desafios da computação distribuida

Ø Ausência de fonte comum de tempo (relógio global)

Ø Ausência de memória compartilhada

Ø Compartilhamento de recursos

Surgimento de Sistemas distribuidos: A medida que a velocidade e a confidencialidade das redes de computadores aumentam, computadores do mundo inteiro estão cada vez mais conectados.

A comunicação remota via rede, originalmente reservada para grandes instalações de computadoes e ambientes acadêmicos, tem sido amplamente empregada. Em sistemas distribuidos, computadores remotos trabalham cooperativamente por meio da rede, de modo que seja visto como única maquina local.

Embora ofereçam muitas vantagens em relação a sistemas centralizados, os sistemas distribuidos podem ser complexos e de difícil implementação e gerenciamento. Por exmplo, os sistemas distribuidos tem de manipular atrados de comunicação e problemas de confiabilidade. É muito difícil gerenciar falhas de máquinas.

Desafios da Computação Distribuida

· Concorrência: A execução concorrente é uma característica intrínseca de um sistema distribuído, na qual os processos disputam pelos recursos compartilhados.

· Inexistência de relógio global: A coordenação dos processos depende de uma noção compartilhada do tempo em que as ações dos programas ocorrem.

· Falhas Independentes: Falhas na rede, nos sistemas ou nos processos demoram a ser percebidas nos sistemas distribuídos.

Falácia da computação distribuida: Os sistemas distribuidos são diferentes dos softwares tradicionais, porque seus componentes estão dispersos em uma rede.

Peter Deustch formulou esses erros como as seguintes premissas falsas adotadas em aplicação distribuida:

ü A rede é confiável

ü A rede é segura

ü A rede é homogênia

ü A topología não muda

ü A latência é zero

ü A largura de banda é infinita

ü O custo de transporte é zero

ü Há somente um administrador

Atributos dos sistemas distribuidos

· Latência: Tempo decorrido entre o início de uma operação e seu término. O termo latência é usado, normalmente, para comunicações entre partes de um sistema.

· Taxa de transmissão: Taxa que mede a capacidade de transmissão/recepção de informações por unidade de tempo.

· Speedup: Termo que significa ganho relativo de velocidade ou desempenho. Como exemplo de speedup podemos citar a razão dos tempos de execução sequencial e o paralelo.

· Boottleneck: Gargalo de rede.

· Escalabilidade: Capacidade de melhoria do desempenho do sistema distribuido conforme cresce o número de elementos processadores.

· Balanceamento de Carga: Característica que permite ao sistema distribuido dividir, adequadamente suas tarefas de modo que um elemento processador não fique mais sobrecarregado que os outros.

· Migração de dados: Medida de produtifidade de um sistema. Essa medida exprime, por unidade de tempo, a produção efetiva do sistema em termos de tarefas, transações, operações.

· Replicação: Característica do sistema que dá maior ou menor certeza de que vai funcionar a contento.

· Transparência: capacidade de o sistema sobreviver à falha de alguns de seus elementos.

· Disponibilidade: Característica que indica quanto tempo o sistema funcionará ininterruptamente sem ser afetado por falhas, manutenção preventiva ou corretiva, etc.

· Segurança: Garantia de o sistema fazer, de maneira correta e para os usuários corretos, aquilo para o qual foi projetado.

· Migração de tarefas: Transferencia da responsabilidade de execução de uma tarefa de um elemento para outro.

· Throughput: Transferência de dados de um elemento processador para outro

· Confiabilidade: Duplicação de recursos de um elemento processador em outro.

· Tolerância a falhas: Característica que esconde de usuário ou aplicativos detalhes de funcionamento do sistema distribuido, de tal forma que se tenha a impressào de que o sistema é centralizado.

Imagem única do sitema (SSI): É a propriedade de se ocultar a complexidade envolvida em uma natureza distribuida e heterogência de recursos disponíveis para os usuários e aplicações, de tal forma que estes visualizem o sistema como um recurso único.

· Benefícios:

Ø Os serviços podem ser requisitados a partir de qualquer nó do sistema

Ø A localização de dispositivos físicos pode ser totalmente transparente para o usuário

Ø O sitema apresenta disponibilidade em seus serviços

Ø O sistema permite ao usuário trabalhar com uma interface simplificada, com comandos que ajudem a administrar o cluster por inteiro, como se fosse uma única máquina.

Ø O sistema reduz rescos em erros operacionais e apresenta maior disponibilidade

Ø O sistema permite um modelo de processos com espaço globalizado para balanceamento de carga

Ø O sistema permite que diversos componentes de uma aplicação trabalhem, de forma cooperativa, para criar a imagem de uma única aplicaçao no sistema

Ø Quanto a concorrencia, os usuário não devem notar que existem outras pessoas utilizando o sistema.

O Brasil tem dois supercomputadores na lista do ranking dos computadores mais velozes do mundo: TUPI, GALILEU

Intranet: Redes corporativas que utilizam da tecnología e de infraestrutura de comunicação de dados da internet. Essa são utilizadas na comunicação interna da própria empresa e também na comunicação com outras empresas.

Computação em grade: A tecnologia por trás da computação em grade é um conjunto de softwares middleware que gerenciam recursos distribuidos e espalhados pela organização, disponibilizando os servidores e eventualmente, os desktops da empresa. A idéia básica é combinar os recursos disponíveis com as demandas computacionais das empresas. Computação em grade é uma maneira bastante eficiente de maximinizar recursos computacionais. Trata-se de uma consolidaçao virtual de servidores.

Computação Oportunista: Consiste em usar redes de computadores para resolver problemas computacionais. Popularizou com o projeto SET. Outro projeto é o BOINC.

Sistemas distribuídos e TI verde: A virtualização é a camada de abstração entre sistemas de hardware de computador e do software que roda nesses sistemas, proporcionando uma visão lógica dos recursos de computação. Trata-se de uma das formas de economizar recursos e praticar TI verde! A virtualização trata de estender ou substituir uma interface existente, de modo a imitar o comportamento de outro sistema. Uma das razões mais importantes para introduzir a virtualização na década de 1970 foi permitir que softwares herdados (aplicações e sistemas operacionais) executassem em hardwares de mainframe.

Virtualização e o sistema de conectividade: Essa conectividade exige dos administradores que um conjunto grande e heterogêneo de computadores servidores execute (cada um) diferentes aplicações utilizando diferentes recursos, que podem ser acessadas por diversos clientes.

A virtualização pode contribuir muito nesse sentido!

Em primeiro lugar, porque a diversidade de plataformas e máquinas pode ser reduzida.

Em segundo lugar, porque cada aplicação pode executar em sua própria máquina virtual, incluindo, possivelmente, suas bibliotecas e o sistema operacional (ambos relacionados), que estariam executando em uma plataforma comum

Supercomputadores e TI verde: Por décadas, a noção de performance tem sido sinônimo de velocidade. Esse enfoque especial levou ao surgimento de supercomputadores que consomem grandes quantidades de energia elétrica e produzem tanto calor que exigem enormes instalações de refrigeração.

Falha Parcial: É uma das características do sistema distribuido que distingue dos centralizados. Falha parcial pode acontecer quando um componente em um sistema distribuido não funciona. Essa falha pode afetar a operação adequada de outros componentes e, ao mesmo tempo, deixar totalmente ilesos. A falha em sistemas não distribuidos quase sempre é total, no sentido de que afeta todos os componentes e pode, facilmente, fazer o sistema inteiro cair. O sistema distribuido deve tolerar falhas e continuar a funcionar até certo ponto, mesmo na presença dessas falhas.

Tolerância a falhas: De acordo com Kopetz e Veríssimo, a confiabilidade abrange uma série de requisitos úteis para sistemas distribuidos:

· Disponibilidade: Consiste na propriedade de um sistema estar pronto para ser usado imediatamente. Trata-se da probabilidade de o sistema funcionar corretamente em qualquer momento determinado e estar disponivel para executar suas funções. Ex: se um sistema é desligado duas semanas em um mes tem alta confiabilidade, mas somente 96% de disponibilidade.

· Confiabilidade: Consiste na propriedade de um sistema poder funcionar continuamente sem falhas. Essa confiabilidade é definida em termos de um intervalo de tempo, e não de uma instante de tempo. Ex: se um sistema fica fora um milissegundo a cada hora, terá disponibilidade de 99,99%, mas sua confiabilidade ainda será muito baixa.

· Segurança: Se um sistema deixar de funcionar corretamente durante certo tempo, nada de catastrófico acontecerá. E o que acontece com sistemas de controle de processos usados em usinas de energia nuclear ou sistemas ara enviar pessoas ao espaço.

· Capacidade de Manutenção: Consiste na facilidade com que um sistema que falhou pode ser consertado. Com alta capacidade de manutenção podemos também ter alta disponibilidade.

O defeito acontece quando o sistema não pode cumprir o que foi especificado ou prometido.

O erro, por sua vez, representa o estado de um sistema que pode levar a uma falha.

Tipos de Falhas

As falhas são classificadas como:

· Transientes: As falhas transientes ocorrem uma vez, depois, desaparecem. Se a operação for repetida, a falha não acontecerá novamente. Por exemplo, um pássaro voando pelo feixe de um transmissor de microondas pode causar perda de bits em alguma rede.

· Intermitentes: As falhas intermitentes ocorrem e desaparecem por sua própria vontade. Depois, essas falhas reaparecem e assim por diante. Por exemplo, um conector com um contato frouxo causará, muitas vezes, uma falha intermitente.

· Permanentes: As falhas permanentes continuarão a existir até que o componente faltoso seja substituído. É o caso dos chips queimados e dos bugs de software.

Modelos de falhas

Diferentes tipos de falhas
Tipo de falha	Descrição
Falha por queda	O servidor para de funcionar, mas estava funcionando corretamente
Falha por omissão: Omissão de recebimento; Omissão de envio	O servidor não consegue responder a requisições que chegam
Falha de temporização	A resposta do servidor encontra-se for a do intervalo de tempo
Falha de Resposta: Falha de valor Falha de transição de estado	A resposta do servidor está incorreta O valor da resposta está errado.
Falha Arbitrária	Um servidor pode produzir resposas arbitrárias em momentos arbitrários.

Modelo de falhas em sistemas distribuidos

· Falha por queda: Um aspecto importante desta falha está baseado de que, uma vez que o servidor para, nada mais se ouve dele. Por exemplo quando o sistema operacional trava e para de funcionar.

· Falha por omissão: Várias são as possibilidade de erro na falha por omissão. Podemos indentificá-la, por exemplo, no caso em que a conexão entre um cliente e um servidor foi estabelecida corretamente, mas não havia nenhum thread ouvindo as requisições que chegavam. Falha por omissão de recebimento, em geral, não afeta o estado corrente do servidor, porque este não fica ciente de que qualquer mensagem foi enviada a ele/ Por exemplo quando o buffer de envio transborda e o servidor não está preparado para tal situação.

· Falha de temporização: A resposta do servidor se encontra for a do intervalo de tempo. Pois, se o fornecimento de daods for realizado muito cedo, poderá causar problemas para um receptor se não houver espaço de buffer suficiente para armazenar todos os dados que estão sendo recebidos.

· Falhas Arbitrárias: Conhecidas também como bizantinas, são falhas mais sérias. Em particular, um servidor pode estar produzindo saidas que nunca deveria ter produzido, mas que não podem ser detectadas como incorretas. Requisito importante quando se trata de sistemas confiáveis.

· Falha de Resposta: É um tipo sério de falha. Ela pode ocorrer de duas maneiras sejam:

o Falha de Valor: quando falha um mecanismo de busca que retorna sistematicamente páginas da web não relacionadas com qualquer uma das palavras de busca usadas.

o Falha de transição de estado: Quando um servidor recebe uma mensagem que não pode reconhecer, se não for tomada nenhuma providência para manipular tal mensagem, acontecerá uma galha de transição de estado.

Procedência do Compilador

Veja, a seguir, algumas técnicas de tratamento:

1. Mascaramento de falhas por redundância: Se um sistema deve ser tolerante a falhas, o melhor que ele pode fazer é tentar ocultar de outros processos a ocorrência de falhas. A tecnica fundamental para mascarar falhas é usar redundância. Os três tipos de redundância são:

Ø Redundância de Informação: Os bits extra são adicionados para permitir a recuperação de bits deteriorados. Por exemplo, codigo de Hamming pode ser adicionado a dados transmitidos para recuperá-los de ruido na linha de transmissão.

Ø Redundância de Tempo: Uma ação é realizada, e se for preciso, essa ação será executada novamente. Transações (banco de dados) usam essa abordagem. Se uma transação for abortada, ela pode ser refeita sem causar nenhum dano. Ë util para falhas transientes ou intermitentes.

Ø Redundância Física: São adicionados equipamentos ou processoas extras para possibilitar que o sistema como um todo tolere a perda ou o mau funcionamento de alguns componentes. A redundância física pode ser feita em hardware ou em software.

2. Mascaramento de falhas e replicação: Grupos de processos fazem parte da solução para contruir sistemas tolerantes a falha. Em particular, ter um grupo de processos idênticos permite-nos mascarar um ou mais processos faltosos àquele grupo. Podemos replicar processos e organizá-lo em um grupo para substituir um único processo (vulnerável) por um grupo (tolerante à falha).

De modo geral, em casos de tolerância a falha, a replicação ;e baseada na forma de um protocolo de primário e backup. Quando um servidor primário cai, os backups executam algúm algoritmo de eleição para escolher o novo primário.

3. Acordo em sistemas com falha: Organizar processos replicados em um grupo, ajuda a aumentar a tolerância à falha. Em geral, as coisas tornam-se mais complicadas se exigimos que um grupo de processos chegue a um acordo, o que é necessário em muitos casos.

O objetivo feral de algoritmos de acordo distribuidos é que todos os processos que não apresentam falha cheguem a um consenso sobre alguma questão e estabeleçam esse consenso dentro de um número finito de etapas.

4. Detecção de falha: A detecção de falhas é uma das bases da tolerância à falha em sistemas distribuídos.

No caso de um grupo de processos, os sistemas devem ser capazes de decidir quem ainda é um membro e quem não é, isto é, o sistema deve ser capaz de detectar quando um membro de um grupo falhou. Quando se trata de detectar falhas de processos, há, essencialmente, dois mecanismos:

ü Os processos enviam as mensagens ativamente uns aos outros;

ü Os processos esperam passivamente pela entrada de mensagens de processos diferentes.

5. Recuperação: Uma vez ocorrida a falha, é essencial que o processo em que a mesma aconteceu se possa recuperar para um estado correto. A recuperação de um erro é fundamental para a tolerância à falha! É bom lembrar que um erro é parte de um sistema que pode levar a falha. A idéria geral de recuperação de erro é substituir um estado errônio para um estado livre de erros.

Formas de recuperação de erro: Existem duas formas de recuperação de erro, quais sejam:

· Recuperação Retroativa: É trazer o sistema de seu estado com o erro presente para um estado anterior, que estava correto.

Para fazer isso, é necessário registrar o estado do sistema de tempos em tempos e restaurar tal estado registado quando ocorrer o erro.

· Recuperação para a frente: Quando o sistema entra em um estado de erro, em vez de retroagir para estado anterior correspondente a um ponto de verificação, realizá-se uma tentativa para levar o sistema a um novo estado correto, a partir do qual ele possa continuar a executar.

O principal problema dos mecanismos de recuperação para frente é que precisamos saber, de antemão, quais erros podem ocorrer. Só assim, é possível corrigir esses erros e passar para um novo estado.

A detecção de falha é uma base da tolerância a falha em sistemas distribuidos.

Taxonomia de Flynn: O esque consistia de quatro categorias baseadas em tipos diferentes de fluxos usados por processadores. Um processador aceita dois fluxos: um fluxo de instruções e um fluxo de dados.

Monoprocessador (SISD) – Único fluxo de dados e instrução. Trata-se da classificação do tipo mais simples: são monoprocessadores tradicionais, nos quis um único processador busca uma instrução por vez e a executa sobre um único item de dado. Podemos citar a arquitetura sequencial e a maquina de von-neumann.

Máquina Teórica (MISD) – Multiplo fluxo de instrução e único de dados. Esses tipos de computadores não são usados. Uma arquitetura MISD teria várias unidades de processamento que agiriam sobre um fluxo único de dados. Cada unidade executaria uma instrução diferente nos dados e passaria o resultado para a próxima unidade.

Máquinas Setorias (SIMD) – Único fluxo de instrução e multiplo fluxo de dados. Esse computadores emitem instruções que agem sobre vários itens de dados. Um computador SIMD consiste em uma ou mais unidades de processamento.

Sistemas Distribuidos (MIMD) – Múltiplos fluxos de dados e instrução. Trata-se de multiprocessadores, nos quais as unidades processadoras são completamente independetes e operam sobre fluxo de instruções separados. Entretando, esses sistemas normalmente contêm hardware que permite que os processadores se sincronizem uns com os outros quando necessário, como no caso de acessarem um dispositivo periférico compartilhado. Subdividido em fortemenet acoplado e fracamente acoplado.

Programação distribuida pode ser :

· Sequencial: composta por um conjunto de instruções que são executadas sequencialmente

· Concorrente: Permite execução concorrente de tarefas dentro de um mesmo processo ou entre processos que compartilham recursos.

· Paralela: Pressupõe a existencia de mais de uma CPU, pois é destinada à execução simultânea de tarefas de um mesmo processo.

Execução de uma tarefa: Existem 3 maneiras de executar uma tarefa de forma mais rápida, quais sejam:

· Aumento da velocidade da CPU: Algumas limitações estão associadas à aquisição de CPUs com maior poder de processamento, como o aumento de seu custo e a previsão para a velocidade dos processadores duplicarem a cada 18 meses (Lei de Moore), que tem sido mantida até os dias atuais. Mesmo com o aumento da frequência das CPUs, há a possibilidade de essas não atenderem à solução de alguns problemas.

· Otimização do Algoritmo: Geralmente, conseguimos aumentar o desempenho de um sistema com a melhora do algoritmo. Entretanto, esse sistema pode ser comprometido quando não há uma solução determinística para o problema.

· Colaboração: Quando pensamos em trabalhar com colaboração, devemos atentar para a diferença entre paralelismo e concorrência. Veja:

Ø Paralelismo - Execução de uma tarefa em mais de uma CPU (os processadores colaboram para execução dessa tarefa);

Ø Concorrência – Os processos disputam CPUs (uma ou mais).

Aspectos técnicos da programação distribuida

1. Interação da aplicação e do usuário com o ambiente distribuído em níveis diferentes

2. Suporte a plataforma heterogêneas através de uma camada de software entre kernel e a aplicação (middleware)

3. Problemas como custo e carência de produtos de software adequados

4. Programação paralela, utilizando bibliotecas de troca de mensagem (como, por exemplo, o MPI e o PVM) ou bibliotecas baseadas em memória compartilhada (como, por exemplo, Pthreads).

Os modelos de sistemas distribuidos podem ser classificados como:

· Arquiteturais: Aqueles que definem a forma como os componentes dos sistemas interagem.

· Fundamentais: Aqueles que definem o comportamento e as propriedades dos componentes.

Modelos de Arquitetura de Sistemas Distribuídos

A maior preocupação é tornar o sistema:

· Confiável

· Gerenciável

· Adptável

· Rentável

Em seguida, o referido modelo considera:

· O posicionamento dos componentes em uma rede de computadores, buscando definir padrões para a distribuição de dados e da carga de trabalho.

· Os inter-relacionamentos entre os componentes, isto é, seus papéis funcionais e os padrões de comunicação entre eles.

Características dos modelos de arquitetura:

Os modelos de arquitetura de um sistema distribuído apresentam estrutura em camadas de software de diferentes níveis de abstração, quais sejam: plataforma e middleware.

Os modelos de arquitetura classificam-se como:

• Cliente/servidor;

• Peer-to-peer;

• De variações.

Requisitos de projetos dos modelos de arquitetura

· Desempenho: Os desafios decorrentes da distribuição de recursos excedem a necessidade de gerenciamento das atualizações concorrentes. Os principais problemas associados a limitação finita da capacidade de recursos de processamento e de comunicação são: reatividade, throughput e balanceamento de carga.

· Qualidade de serviço: As principais propriedades não funcionais dos sistemas que afetam a qualidade dos serviços fornecidos aos clientes são:

o Confiabilidade

o Segurança

o Desempenho

o Adaptalidade

o Disponibilidade

· Replicação: os problemas de desempenho podem ser (em parte) solucionados através do uso de replicação de dados.

· Dependabilidade: Pode ser definida como correção, segurança e confiabilidade. Trata-se de um requisito necessário a maior parte dos domínios da aplicação.

1. É uma desvantagem dos sistemas distribuídos quando comparado aos sistemas centralizados:

R) Possibilidade de congestionamento na rede

2. É uma vantagem dos sistemas distribuídos quando comparado aos sistemas centralizados:

R) Relação custo/benefício

3. O termo escalabilidade por ser definido como:

R) Possibilidade de inclusão de novos componentes, que sejam adicionados à medida que cresça a carga de trabalho.

4. Dentre os vários tipos de transparência tratados na nossa aula, qual delas oculta a diferença na representação de dados e no modo de acesso a um recurso:

R) De acesso

5. Indique, a seguir, qual é a característica que permite ao sistema distribuído dividir, adequadamente, suas tarefas, de modo que um elemento processador não fique mais sobrecarregado que os outros:

R) Balanceamento de Carga

6. Assinale, a seguir, a opção que apresenta uma das oito falácias formuladas por Peter Deustch:

R) A topologia é estática.

7. Não é considerado como uma falha de resposta:

R) O servidor não responde às requisições.

8. É considerada uma redundância física para o tratamento de falhas:

R) Adição de equipamentos extras

9. A transmissão de mensagem multicast é considerada:

R) ordenada, assíncrona e com atraso limitado.

10. As formas de executar mais rapidamente uma tarefa são:

I. Trabalhar mais rápido.

II. Trabalhar de forma otimizada.

III. IV. Trabalhar com colaboração.

11. De acordo com a classificação de arquiteturas de acesso à memória, assinale a opção que indica a sigla INCORRETA:

R) Acesso não uniforme à memória com cache coerente – NUMA.

12. De acordo com a classificação de Flynn, assinale a opção que indica a sigla CORRETA:

R) Computadores de fluxo múltiplo de instruções e fluxo múltiplo de dados – MIMD.

13. Classificação de Flynn para os computadores de fluxo único de instruções e fluxo único de dados:

R) SISD

14. Arquitetura de multiprocessadores com acesso não uniforme à memória.

R) NUMA

15. Classificação de Flynn para os computadores de fluxo único de instruções e fluxo multiplo de dados

R) SIMD

16. O aplicativo que começa ativamente o contato é chamado de cliente, enquanto o aplicativo que espera passivamente por contato é denominado servidor.

17. Em geral, a interação cliente-servidor tem as mesmas características. Entretanto o software cliente:

R) É uma aplicação qualquer que se tornará um cliente temporariamente, quando o acesso remoto for necessário.

Executa localmente no computador pessoal de um usuário.

É diretamente invocado por um usuário e executa somente para uma sessão.

18. Quando um sistema permite que múltiplos aplicativos estejam ativos ao mesmo tempo, podemos afirmar que suporta:

R) Concorrência

19. Quando os desafios decorrentes da distribuição de recursos excedem a necessidade de gerenciamento das atualizações concorrentes, os principais problemas associados à limitação finita da capacidade de recursos de processamento e de comunicação são:

R) Reatividade, throughput e balanceamento de carga.

Estacio Redes

martes, 29 de mayo de 2012

ARQ SISTEM DISTRIBUIDOS

No hay comentarios:

Publicar un comentario