SISTEMAS DISTRIBUÍDOS - CAP 1

Prévia do material em texto

SISTEMAS DISTRIBUÍDOSSISTEMAS DISTRIBUÍDOS
CONCEITOS INICIAISCONCEITOS INICIAIS
Autor: Dr. Sidartha Azevedo Lobo de Carvalho
Revisor : L izandro de Souza
IN IC IAR
introdução
Introdução
Nesta unidade, você vai aprender sobre os principais conceitos que permeiam o
mundo dos sistemas distribuídos, as principais características que são usadas
para classificar esses sistemas e como ocorre a comunicação entre os
processos que executam dentro dos programas do usuário e dos servidores.
Você vai entender como é feita a criação e identificação de processos e o
escalonamento destes dentro do sistema operacional. Além disso, vai aprender
sobre os principais modelos e padrões arquiteturais de comunicação para os
sistemas distribuídos. Por fim, vai entender o que é e como funciona o modelo
cliente-servidor, utilizado em todo o mundo.
Nesta seção, você vai aprender o que é um sistema distribuído e quais as
principais características desse tipo de sistema. Primeiramente, você sabe onde
pode usar um sistema distribuído? Os sistemas distribuídos compõem grandes
redes de computadores, como a internet, redes de fábricas, redes de telefones
móveis, dentre outras.
Em outras palavras, um sistema distribuído pode ser definido como:
[...] aquele no qual os componentes de hardware ou software,
localizados em computadores interligados em rede, comunicam-
se e coordenam suas ações apenas enviando mensagens entre
si. Essa definição simples abrange toda a gama de sistemas nos
quais computadores interligados em rede podem ser distribuídos
de maneira útil. (COULOURIS, 2013, p. 2)
Uma das principais motivações para que os sistemas distribuídos existam é a
necessidade do compartilhamento de recursos entre os elementos de uma rede
de computadores. Você pode entender recursos como um termo abstrato que
Características de umCaracterísticas de um
Sistema DistribuídoSistema Distribuído
permite caracterizar diversos itens, como arquivos de um computador, bancos de
dados, serviços de software, impressoras, componentes de hardware, dentre
outros.
Se você analisar os componentes de hardware, é possível compartilhar
impressoras, discos e processadores para reduzir custos. Porém, se observar
pela visão do usuário final do sistema, perceberá que este deseja compartilhar
informações em mais alto nível, como aquelas necessárias para o seu trabalho e
suas atividades sociais. Veja o exemplo a seguir: os usuários do sistema
possuem a necessidade de compartilhar informações sobre suas viagens ou
dados de uma tabela do banco de dados, não estando preocupados em
compartilhar discos ou processadores. Ou seja, essa abstração mais baixo nível,
como os processadores ou os servidores dos dados, não é importante ao
usuário final.
Os sistemas distribuídos estão presentes em diversos cenários. Então, imagine
dois cenários extremos: o compartilhamento de dados na internet entre duas
pessoas que não se conhecem, mas que compartilham do mesmo problema (e
um deles sabe como resolver esse problema); e, no outro extremo, pessoas que
trabalham lado a lado e utilizam os computadores para trocar informações que
estão nas máquinas locais. Ambos os cenários descritos anteriormente utilizam
sistemas distribuídos, mas com características distintas.
Percebe a diferença geográfica que há entre os cenários anteriores? Os
sistemas distribuídos devem oferecer mecanismos para tornar essa diferença
geográfica transparente, de forma que os usuários não saibam o caminho que a
requisição faz no navegador web até chegar à informação desejada, mesmo que
seja do outro lado do mundo.
Já o termo “serviço”, segundo Coulouris (2013, p. 15), é definido como:
[...] uma parte distinta de um sistema computacional que
gerencia um conjunto de recursos relacionados e apresenta sua
funcionalidade para usuários e aplicativos. Por exemplo,
acessamos arquivos compartilhados por intermédio de um
serviço de sistema de arquivos; enviamos documentos para
impressoras por meio de um serviço de impressão; adquirimos
bens por meio de um serviço de pagamento eletrônico. O único
acesso que temos ao serviço é por intermédio do conjunto de
operações que ele exporta. Por exemplo, um serviço de sistema
de arquivos fornece operações de leitura, escrita e exclusão dos
arquivos.
Perceba, na descrição de Coulouris (2013), que os serviços apresentam
restrições no acesso aos recursos, especificando um conjunto finito de
operações que podem ser realizadas por outro sistema ou usuário final. Essa
restrição reflete a organização dos sistemas distribuídos, destacando a
importância da comunicação entre os sistemas e permitindo que somente o que
realmente deve estar exposto seja acessado. Esse conjunto bem-definido
também auxilia na garantia da consistência e segurança dos dados dos
servidores.
Em complemento, Tanenbaum (2007, p. 1) define um sistema distribuído como
“um conjunto de computadores independente que se apresenta a seus usuários
como um sistema único e coerente”.
Atente-se para os termos destacados em negrito. O termo “único” reflete que o
sistema distribuído deve ser transparente, ou seja, não deve ser visível ao
usuário. Se você usa 1 ou 100 computadores interligados para prover o serviço
ao usuário, ele somente deve ter acesso ao serviço, não como as coisas são
feitas nos bastidores.
O termo “coerente” se deve à necessidade de sincronização e consistência dos
dados, pois não deve haver inconsistências (como informações desatualizadas)
entre os elementos que compõem o sistema distribuído. Por exemplo, imagine
um servidor de filmes que é composto por 2 computadores servidores, sendo
que em um computador há 100 filmes e, no outro, há somente 80; quando o
usuário tentar acessar um filme que não está presente no computador que tem
somente os 80 filmes, vai haver inconsistência de informações e o usuário não
irá receber o serviço desejado.
Dado o exposto, os sistemas distribuídos geralmente são classificados de acordo
com as seguintes características:
compartilhamento de recursos;
abertura;
concorrência;
escalabilidade;
tolerância a falhas;
disponibilidade;
transparência.
Cada uma dessas características será detalhada na seção a seguir.
Análise das Características
Dado o exposto, os sistemas distribuídos, geralmente, são classificados de
acordo com as seguintes características:
Compartilhamento de recursos: deve especificar quais recursos
estão disponíveis para serem acessados, como eles devem ser
acessados e modificados, como o seu compartilhamento deve ser
realizado dentro da rede e a implementação da interface de interação
com o recurso e/ou servidor.
Abertura: um sistema distribuído aberto oferece serviços com base em
regras e padrões conhecidos pela comunidade, permitindo que outros
sistemas que também conheçam esses padrões possam se comunicar
com ele. Abertura é a capacidade de interagir com outros sistemas
abertos (conhecem/implementam os mesmos protocolos). Um sistema
aberto é independente de hardware, plataformas ou linguagens de
programação; ele consegue abstrair esses conceitos para oferecer um
serviço que pode ser acessado de forma facilitada por outro sistema na
rede.
Concorrência: o termo “concorrente” se dá como uma característica
dos sistemas distribuídos que permitem que diversos
usuários/computadores possam acessar os recursos que estão sendo
compartilhados de forma simultânea, garantindo consistência na leitura
e modificação dos dados. Imagine um sistema distribuído de um banco
de dados que recebe pedidos de modificação dos dados de diversos
usuários diferentes e, enquanto isso, há diversos outros fazendo a
leitura desses mesmos dados. O sistema deve permitir que somente 1
usuário modifique os dados por vez, enquanto diversos outros podem
ler (não haverá inconsistência). Ao ser feita uma modificação, essa
alteração deve ser transmitida a todos os computadores que
armazenam esse banco de dados compartilhado, para que os usuários
que estão acessando recebam os dados atualizados.
Escalabilidade: a escalabilidade reflete o quão rápido um sistema
distribuídopode ser expandido. A escalabilidade pode ter diversos
aspectos, podendo ser: de distribuição, de replicação e de caching. A
escalabilidade de distribuição é a habilidade do sistema distribuído em
dividir dados/recursos entre as diversas máquinas que compõem o
sistema distribuído; a escalabilidade de replicação é a habilidade do
sistema distribuído em manter diversas cópias dos seus dados em
diversas outras máquinas da rede, mantendo os dados consistentes e
íntegros; por último, a escalabilidade de caching é a habilidade do
sistema distribuído em gerenciar e permitir que os usuários acessem
dados de forma local ou em servidores mais próximos ao usuário,
reduzindo o tempo de acesso do usuário ao recursos e reduzindo o uso
de rede de dados.
Tolerância a falhas: o sistema distribuído deve apresentar a
característica de ser tolerante a falhas, ou seja, ao entrar em estado de
falha, deve se recuperar de forma transparente, não permitindo que o
usuário saiba que ela aconteceu. Para possibilitar a transparência a
falhas, o sistema deve implementar mecanismos de identificação e
recuperação de falhas automatizados. Por exemplo, imagine que em
um computador que faz parte de um sistema distribuído o disco rígido
apresente problema e não consiga mais consultar os dados desejados
pelo usuário, a partir disso, o mecanismo automático de gerência do
sistema distribuído deve identificar essa falha e redirecionar as
requisições desse servidor para um outro servidor que possua os
mesmos dados. Tudo isso deve ser feito de forma transparente e
automática, sem a ciência do usuário sobre o problema.
Disponibilidade: a disponibilidade é outra importante característica dos
sistemas distribuídos. A disponibilidade é o tempo em que o sistema
está disponível, operando de forma correta. Um sistema tem alta
disponibilidade se possui pouco tempo em estado de falha ou se está
inoperante. Geralmente, os grandes sistemas, como Google e Amazon,
possuem disponibilidade de 99,99% do tempo, ou seja, passam poucos
segundos por ano inoperantes. Ter uma alta disponibilidade é custoso
para a organização, pois ela tem que investir no gerenciamento e
reparo automático de falhas, na replicação de máquinas de forma
distribuída geograficamente, hardware de alto desempenho etc.
Transparência: a transparência é uma meta importante dos sistemas
distribuídos, visto que é a habilidade de esconder o fato de que os
processos e recursos do sistema distribuído estão fisicamente
separados em vários computadores que integram o sistema distribuído.
Veja, a seguir, os principais tipos de transparências:
Acesso: o sistema distribuído não permite que o usuário saiba como os
dados são representados dentro do sistema distribuído, por exemplo, se
é usado um banco de dados relacional ou orientado a objetos, se é
usado tecnologia X ou Y, dentre outras informações.
Localização: o sistema distribuído não permite que o usuário do
sistema tenha conhecimento sobre a localização dos recursos, se ele é
fornecido por máquina X com IP 10.0.0.1, ou por máquina Y com IP
10.0.0.5, por exemplo. Como exemplo, lembre-se do sistema distribuído
para streaming de vídeos: quando o usuário acessa o sistema para
assistir a um filme, ele não tem conhecimento de qual servidor vai
fornecer o vídeo a ele, podendo ser até mais de um servidor (cada
servidor pode fornecer metade do filme).
Migração: a transparência de migração esconde do usuário final do
sistema que um recurso é movido de um servidor para outro; isso pode
acontecer em tempo de execução (nesse caso, se chama relocação). O
usuário não tem conhecimento da mudança de um recurso; por
exemplo, ao acessar um site a partir de um endereço URL, o usuário
não sabe a localização do servidor que armazena o site. Nesse cenário,
os administradores podem alterar o site de servidor e o usuário
continuará sendo redirecionado ao site (recurso), mesmo que fornecido
por outro servidor.
Relocação: a transparência de relocação é bem parecida com a de
migração, porém, diferencia-se pelo fato de o recurso usado ser movido
para outro local durante o uso pelo usuário final. Por exemplo, o usuário
está assistindo a um filme que é fornecido em um servidor X e, por
motivos de força maior, o funcionamento desse servidor precisa ser
interrompido. O vídeo (recurso do servidor), juntamente com a conexão
do usuário, é movido para um novo servidor, de forma transparente,
sem a ciência do usuário. Assim, o usuário não consegue perceber que
foi redirecionado para outro servidor.
Replicação: a transparência de replicação esconde do usuário quais e
quantas vezes determinado recurso está copiado/replicado pela rede,
em diversos computadores.
Concorrência: a transparência de concorrência de dados em sistemas
distribuídos é a habilidade do sistema em esconder do usuário que
diversos outros usuários estão usando o mesmo recurso de forma
simultânea. O sistema garante consistência no dado que está sendo
acessado e, com isso, provê a transparência.
Falha: a transparência de falha esconde do usuário final se o sistema
provedor do recurso está em estado de falha, permitindo a recuperação
da falha e manutenção do provimento do recurso para o usuário.
Persistência: a transparência de persistência esconde do usuário a
informação do armazenamento e, assim, o usuário não sabe se o
recurso que ele está acessando está armazenado em memória volátil
ou em um armazenamento não volátil. Por exemplo, ao acessar o
streaming de vídeo, os bytes são transmitidos pela rede para o usuário
que o requisitou; nesse cenário, o usuário não sabe se os bytes que ele
está recebendo estavam armazenados em um HD ou se estavam na
memória RAM do servidor de dados.
Dito isso, você conseguiu identificar diversas características que podem estar
presentes nos sistemas distribuídos? Percebeu como elas estão relacionadas? A
seguir, você vai aprender um pouco mais sobre a taxonomia de Flynn.
Taxonomia de Flynn
A taxonomia proposta por Flynn (1972), chamada de taxonomia de Flynn, é uma
classificação de arquiteturas para computadores. A taxonomia de Flynn é usada
na arquitetura e definição de funcionalidades de processadores modernos.
As quatro classificações propostas por Flynn são baseadas no número de
instruções concorrentes, diferenciando um fluxo de dados para instruções e
outro fluxo para dados. Veja as classificações a seguir:
Acesso
O não permite que o usuário saiba como os
dados são representados dentro do sistema.
Por exemplo, se é usado um banco de
dados relacional ou orientado a objetos, se é
usada tecnologia X ou Y, dentre outras
informações.
1. Single Instruction Single Data (SISD): quando o sistema utiliza
somente um fluxo de instruções e um fluxo único para os dados.
Exemplos dessa categoria é o computador de Von Neumann e os
computadores sequências de forma geral.
2. Single Instruction Multiple Data (SIMD): quando o sistema possui um
fluxo único de instruções e diversos fluxos para transferência de dados.
Nessa categoria, temos os computadores vetoriais.
3. Multiple Instruction Single Data (MISD): nessa categoria, o sistema
possui diversos fluxos de instruções, mas somente um fluxo para
transferência de dados. Essa categoria é bastante abstrata e não se
conhecem exemplos práticos de aplicação.
4. Multiple Instruction Multiple Data (MIMD): nessa abordagem, o
sistema possui diversos fluxos para a transferência de instruções e
diversos canais para a transferência de dados. Como exemplo dessa
categoria temos praticamente todos os computadores que possuem
mais de um processador, ou seja, os computadores multiprocessados.
Quadro 1.1 - Resumo da taxonomia de Flynn
Fonte: Elaborado pelo autor.
A taxonomia de Flynn pode ser usada no projeto de sistemas distribuídos,
definindo os canais de comunicação e de instrução. Isso auxilia no
gerenciamento da complexidade dos elementos que compõem o sistema
distribuído.
praticarVamos Praticar
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua, assinale a alternativacorreta:
a) Compartilhamento de recursos.
b) Abertura.
c) Concorrência.
d) Escalabilidade.
e) Disponibilidade.
Um processo é uma abstração de um programa em execução, englobando todos
os recursos necessários para que ele possa ser executado. As threads são
fluxos de execução dentro de um processo que utilizam o mesmo espaço de
memória do processo compartilhando variáveis e recursos do processo. As
threads permitem paralelismo (embora somente uma thread por vez seja
executada na CPU) dentro do processo com um pequeno overhead na troca de
contexto da CPU comparado à troca de contexto de um processo.
As threads podem existir tanto no lado do servidor como no lado do cliente. As
threads no lado do cliente auxiliam nas chamadas bloqueantes, evitando que o
fluxo de execução seja congelado enquanto aguarda pela resposta da
requisição. Veja o exemplo em um programa de edição de texto: 1 thread para
correção ortográfica (t1) e uma outra para salvar automaticamente (t2), ambas
dentro do processo Pi.
Já as threads no lado do servidor servem para auxiliar no paralelismo, permitindo
que mais requisições de clientes sejam respondidas com um atraso mínimo de
resposta. Uma thread é responsável por receber as requisições e criar uma nova
Comunicação entreComunicação entre
ProcessosProcessos
thread para tratar dessa nova requisição, voltando ao seu dever: receber e
encaminhar as requisições.
A seguir, vamos entender como acontece a criação e a identificação de
processos.
Criação e Identificação de Processos
O gerenciamento dos processos é realizado pelo sistema operacional. Assim,
para ser possível organizar esses processos, o SO atribui a cada processo três
conjuntos de informações:
identificação do processo;
quotas de recursos;
privilégios.
Vamos analisar cada uma das informações a seguir:
Identificação do processo: os processos podem ser identificados por
dois campos específicos: o identificador único do processo (Process
Identification - PID) e o criador do processo (Owner).
Quotas de recursos: esse campo de informações reúne os dados
sobre a quantidade de recursos que o processo poderá utilizar. Podem
ser informações sobre o tamanho máximo de memória, tamanho
máximo de arquivos abertos simultaneamente, ou outras informações
que possam limitar a execução do processo.
Privilégios: cada processo pode conter informações diferentes de
privilégios, que definem as permissões de acesso ao sistema. Esse
campo reúne as informações definidas pelo aplicativo. Por exemplo, um
processo pode ter permissão de acesso a arquivos de outros usuários,
enquanto outro processo pode estar restrito a um usuário apenas.
Sistemas operacionais baseados no Unix são os mais usados no mundo para
servidores de aplicações e dados. O sistema operacional Linux é um exemplo de
sistema Unix. No Linux, os processos são criados com o comando fork,
 enquanto as threads são criadas com o comando clone.
Porém, a nível de kernel, ambos utilizam a mesma função: o do_fork. A função
do_fork é capaz de criar um processo que compartilha os endereços com o
processo pai, ou novos endereços podem ser alocados exclusivamente para o
novo processo criado. Quando se usa o fork, garante-se que uma cópia
totalmente nova e desacoplada dos endereços de memória do processo pai será
criada.
Assim, a transição dos processos é organizada por meio de três estados
principais: Pronto, Execução ou Bloqueado. Quando um processo está no estado
Bloqueado, deve passar pelo estado de Pronto antes de retornar ao
processador; quando um processo deixa o processador por ter terminado o
tempo alocado (time slice), ele retorna ao estado de Pronto, aguardando na fila
para entrar novamente em Execução.
Vale ressaltar que a escolha dos processos concorrentes que irão ser
executados é realizada pelo escalonador. Esse é um componente integrante do
sistema operacional, que reúne uma série de critérios para o escalonamento e
seleção dos processos.
Quando um processo adquire o estado de Pronto, ele é alocado em uma fila de
processos que aguardam liberação do processador para iniciar sua execução.
Para realizar a escolha dos processos concorrentes, o sistema operacional conta
com um componente de seleção, denominado escalonador.
O escalonamento dos processos em estado Pronto é realizado com o auxílio de
um algoritmo que define os critérios de escolha do processo a ser executado.
Nessa tarefa de escolha, podemos nos deparar com dois tipos de
escalonamento: preemptivo ou não preemptivo.
Quando um sistema operacional utiliza o escalonamento preemptivo, é realizada
a interrupção de um processo em Execução para que outro seja alocado no
mesmo local. Essa interrupção para troca de processos é utilizada em sistemas
que trabalham com processos de alta prioridade e exigem respostas rápidas.
Já no caso do escalonamento não preemptivo, quando um processo é alocado
para execução, não há interrupção; assim, cada processo irá permanecer em
execução durante o período que for necessário para sua finalização. É um tipo
de escalonamento que não utiliza prioridades entre os processos e pode
ocasionar dois problemas: monopolização do processador por um grande
período de tempo e a espera de processos importantes que aguardam outros
menos importantes.
A escolha do tipo de escalonamento deverá ser realizada conforme as
necessidades do sistema operacional, devendo considerar os tipos de
prioridade: estática ou dinâmica.
A prioridade do tipo estática é aquela associada ao processo, sendo permanente
e definida pelo usuário de acordo com suas necessidades. Já a prioridade do
tipo dinâmica varia de acordo com a necessidade e desempenho do sistema.
Modelos e Arquitetura de Comunicação
Para entender melhor os modelos e arquiteturas de comunicação usadas nos
sistemas distribuídos, vamos estudar alguns exemplos a seguir.
Dando continuidade, alguns exemplos de arquiteturas de comunicação são:
comunicação por troca de mensagens, peer-to-peer, cliente-servidor, orientada a
serviços e orientada a dados (repositório e quadro negro). Veja as descrições a
seguir:
Arquitetura orientada por troca de mensagens: nesse tipo de
arquitetura, a comunicação é feita pelo envio e recebimento de
mensagens, geralmente usando as primitivas send() e receive(). Veja
um exemplo: há um processo A e um processo B; o processo A quer
acessar um dado que está disponível pelo processo B. Para conseguir
se comunicar, o processo A envia uma mensagem send(“Desejo
acessar o método X”), e o processo B está executando a primitiva
receive(), esperando uma nova requisição de chegada de mensagem.
Ao receber a mensagem, o processo B realiza o processamento devido
(executa o método desejado pelo processo A) e, então, retorna a
mensagem para o processo B. Após isso, o processo B volta a executar
a primitiva receive(), até receber uma nova mensagem.
Arquitetura peer-to-peer: também chamada de arquitetura ponto a
ponto, é um modelo de comunicação que não distingue os nós que
compõem a rede, ou seja, qualquer elemento da rede pode ser um
cliente ou um servidor de dados. Cada nó nesse tipo de rede mantém
seus próprios dados e endereços de outros nós da rede (endereços IP,
por exemplo). Nesse estilo de arquitetura, não há um ponto único de
falha, ou seja, se um nó apresentar problema, ele poderá ser excluído
da rede e, mesmo assim, a rede continuará a se comunicar com os nós
que estão funcionando corretamente. Porém, uma desvantagem desse
tipo de organização é o tempo de consulta por um dado; a mensagem
tem que ser transmitida em broadcast para os nós vizinhos e, então,
para os vizinhos dos vizinhos, até que se chegue ao nó desejado. Esse
procedimento de broadcast é muito custoso para a rede e consome
muitos recursos, podendo até inviabilizar o uso por consumir toda a
largura de comunicação da rede.
Arquitetura cliente-servidor: nessa arquitetura, há dois elementos
comunicantes principais: o cliente e o servidor. O cliente é a entidade
que requisita serviços ao servidor, e este último responde aos pedidos
de diversos clientes. Essaarquitetura apresenta um problema: possui
um ponto único de falha, ou seja, se o servidor não estiver disponível, a
rede para de funcionar. Os clientes não conseguem se comunicar entre
eles para trocar informações, como acontece no modelo peer-to-peer.
Por outro lado, a arquitetura cliente-servidor é mais simples de ser
implementada e é a mais utilizada em todo o mundo, para os mais
diversos serviços.
Arquitetura orientada a serviços: nessa arquitetura, há um baixo
acoplamento entre as entidades que fornecem os serviços, permitindo
maior distribuição da carga de processamento em uma infraestrutura de
computadores. Por conta disso, a complexidade de implementação é
aumentada, principalmente o desenho arquitetural do sistema.
Arquitetura orientada a dados: o foco não é nos elementos que
compõem a rede nem nos serviços oferecidos, mas nos dados em si.
Veja, a seguir, dois exemplos deste tipo de arquitetura:
Repositório: na arquitetura repositório, temos um banco de dados
compartilhado, ou seja, que é acessado por diversos clientes. Esse
banco de dados pode estar distribuído em diversos computadores
(sistema distribuído). Esse modelo permite integridade nos dados, pois
tem uma base de dados única e também fornece maior escalabilidade
tanto do banco de dados como da quantidade de clientes.
Quadro negro: nessa arquitetura, temos um nó gerenciador e diversos
nós operários. O nó controlador é responsável por mapear todos os
demais nós da rede que fornecem serviços/funcionalidades e quebrar o
problema a ser resolvido em diversos problemas menores e que podem
ser realocados para os nós específicos. Ao final, o nó controlador é
responsável por integrar todos os microrresultados dos nós específicos
e retornar a resposta final ao usuário que requisitou. Veja a ilustração a
seguir:
Troca de Mensagens
Na comunicação entre os elementos dos sistemas distribuídos, podemos ter
chamadas síncronas ou assíncronas. Nas chamadas síncronas, o usuário faz
uma requisição a um servidor e fica aguardando a resposta e, enquanto isso,
não pode fazer outro processamento, devendo ficar em modo de espera até
receber a mensagem de retorno. Em outras palavras, há dependência de
resposta do recebedor da mensagem, o que pode implicar perda de
desempenho por ociosidade de processamento útil.
A comunicação assíncrona traz a ideia daquilo que não ocorre simultaneamente,
ou seja, algo que não é sincronizado. Mas como isso se relaciona com
aplicações ricas? As chamadas assíncronas correspondem a um comando que
não precisa ser processado pelo servidor para que o usuário possa continuar a
navegação. Isso ocorre por ser possível enviar uma solicitação ao servidor e
fazer outras atividades enquanto a requisição é executada.
Para exemplificar esse assincronismo, imagine o uso de um armazenamento nas
nuvens (como Google Drive, OneDrive ou DropBox) em um navegador. Nesse
contexto, você deseja fazer o upload (carregamento) de um conjunto de novos
arquivos. Ao selecioná-los e solicitar o envio, a aplicação não exige que você
pare o que está fazendo enquanto os arquivos estão sendo carregados; desse
modo, você pode realizar outras atividades sem que essa solicitação interfira na
transferência de dados, uma vez que ela está sendo feita em segundo plano.
Essa capacidade enriquece a experiência do usuário e permite que os sistemas
distribuídos operem de forma otimizada, uma vez que permite a realização de
diferentes atividades.
Na comunicação por troca de mensagens, temos dois comandos que geralmente
são utilizados: o send() e o receive(). Na comunicação síncrona, a primitiva
send() é bloqueante, ou seja, o processo cliente aguarda, enquanto o núcleo
envia a mensagem para o processo servidor. Da mesma forma, a primitiva
receive() também é bloqueante para a comunicação síncrona, ou seja, o
processo servidor aguarda até que o destinatário receba uma mensagem
endereçada para aquele processo.
Já na comunicação assíncrona, a primitiva send() não é bloqueante, ou seja, o
processo cliente aguarda somente enquanto a mensagem é copiada para o
buffer de saída. A primitiva receive() pode ser: bloqueante ou não bloqueante.
Na bloqueante, o processo servidor aguarda por uma mensagem, enquanto na
não bloqueante o processo servidor simplesmente comunica o destinatário que
espera receber uma mensagem.
praticarVamos Praticar
A escolha da arquitetura que será utilizada para projetar um sistema distribuído é
essencial para o seu funcionamento e, dentre tantas opções, deve-se escolher a mais
adequada para cada tipo de problema a ser resolvido. Dito isso, assinale a alternativa
que apresenta qual estilo arquitetural possui uma arquitetura distribuída e não
apresenta ponto único de falha, além disso, permite que os nós da rede se comportem
como emissor e receptor de dados.
a) Peer-to-peer.
b) Cliente-servidor.
c) Quadro negro.
d) Repositório.
e) Orientada a serviços.
O modelo cliente-servidor é um dos modelos mais utilizados pelos sistemas
baseados em rede do mundo. A seguir, você vai compreender alguns exemplos
que destacam a importância e utilidade do modelo cliente-servidor, bem como os
principais protocolos utilizados para manter a comunicação entre o cliente e o
servidor.
Definição e Exemplos
A arquitetura cliente-servidor é, historicamente, a mais utilizada, e continua
sendo até os dias de hoje.
A Figura 1.3 ilustra uma estrutura simples de uso da arquitetura cliente-servidor.
Perceba que os clientes interagem (enviam e recebem mensagens) com o
servidor localizado em outro computador. Também é possível haver
comunicação de servidor para servidor.
Modelo Cliente/ServidorModelo Cliente/Servidor
Ademais, é possível perceber que o cliente requisita o servidor para acessar
algum recurso que deseja. Nessa comunicação, podem ser usados os
protocolos: TCP/IP para a camada de transporte; o Hypertext Transfer Protocol
(HTTP) para acessar páginas web, se esse servidor for um servidor web; o DNS
para resgatar o endereço IP de algum site a partir de sua Uniform Resource
Locator (URL) (caso este seja um servidor Domain Name System (DNS)); dentre
outros.
Ainda de acordo com a ilustração, os servidores podem ser servidores ou
clientes (pois um servidor pode requisitar um recurso de outro servidor). Veja o
exemplo a seguir: um servidor web, geralmente, é um cliente de um outro
servidor que armazena os arquivos dos sites.
saiba mais
Saiba mais
Para saber mais sobre os protocolos TCP, IP,
HTTP e DNS, consulte o livro de Coulouris
(2013), capítulo 3, Redes de computadores e
interligação de rede, a partir da página 81.
Bons estudos!
A C E S S A R
https://www.iana.org/
Em complemento, a maioria dos servidores web também são clientes dos
servidores de DNS, estabelecendo novamente a relação Servidor(Cliente)-
Servidor. Veja mais um exemplo:
Outro exemplo relacionado à Web diz respeito aos mecanismos
de busca, os quais permitem aos usuários pesquisar resumos de
informações disponíveis em páginas Web em sites de toda a
internet. Esses resumos são feitos por programas chamados
Web crawlers*, que são executados em segundo plano
(background) em um site de mecanismo de busca, usando
pedidos HTTP para acessar servidores Web em toda a internet.
Assim, um mecanismo de busca é tanto um servidor como um
cliente: ele responde às consultas de clientes navegadores e
executa Web crawlers que atuam como clientes de outros
servidores Web. Nesse exemplo, as tarefas do servidor
(responder às consultas dos usuários) e as tarefas do Web
crawler (fazer pedidos para outros servidores Web) são
totalmente independentes; há pouca necessidade de sincronizá-
las e elas podem ser executadas concomitantemente. Na
verdade, um mecanismo de busca típico, normalmente, é feito
por muitas threads concorrentes, algumas servindo seus clientes
e outras executando Web crawlers. (COULOURIS, 2013, p. 46)
Figura 1.3 - Exemplo de uso da arquitetura cliente-servidor
Fonte: Adaptada de Coulouris (2013, p. 47).
Dito isso, a seguir você vai aprender um pouco mais sobre os protocolos que
podem ser utilizadosna comunicação entre os clientes e servidores.
Protocolos
Um dos principais protocolos usados no modelo cliente-servidor é o protocolo de
requisição-resposta, que auxilia na definição de como as mensagens devem ser
trocadas entre as entidades comunicantes, ou seja, o cliente e o servidor. Esse
protocolo suporta a troca de mensagens e via dupla, permitindo ao cliente tanto
enviar como receber mensagens, e o mesmo se aplica ao servidor.
É possível definir três estilos para o protocolo de troca de mensagens requisição-
resposta (COULOURIS, 2013):
protocolo request (requisição) (R);
protocolo request-reply (requisição-resposta) (RR);
protocolo request-reply-acknowledge reply (requisição-resposta-
reconhecimento da resposta) (RRA).
No protocolo request, uma única mensagem de requisição é enviada do cliente
para o servidor. O protocolo request, geralmente, é utilizado quando não há
necessidade de o servidor retornar nenhum valor/dado/recurso para o cliente, ou
seja, pode ser usado para ativar algum mecanismo no servidor, como efetuar o
logout de uma conta em um site. Não há necessidade de confirmar ao cliente
que a operação foi realmente realizada e, por isso, não precisa de uma resposta
do servidor.
É importante destacar que esse estilo do protocolo não é bloqueante, ou seja, o
cliente pode realizar outros processamentos e não necessita ficar esperando por
um retorno do servidor. Geralmente, esse protocolo pode ser implementado
usando outros protocolos já conhecidos das redes de computadores, como o
UDP. Lembre-se de que o UDP não guarda estados como o TCP; é possível
enviar uma mensagem e não aguardar resposta, o que permite o envio de mais
mensagens por uma quantidade de tempo, mas pode sofrer por perdas de
mensagens durante a comunicação. Além disso, essas perdas não serão
detectadas, pois não há regras para garantia do recebimento.
O protocolo request-reply (requisição-resposta) é utilizado pela maioria dos
sistemas que são baseados no estilo arquitetural cliente-servidor. Geralmente, a
maioria das mensagens trafegadas no cliente-servidor é de requisição e
resposta, ou seja, o cliente envia uma requisição ao servidor e espera uma
resposta para completar o processamento. Além disso, embora se espere uma
resposta, não é necessária a confirmação do recebimento por parte do cliente.
Pode haver inconsistência na comunicação se a mensagem de resposta do
servidor por perdida na rede durante o transporte, e isso pode levar o cliente a
esperar sem receber a resposta. Há regras de segurança que previnem que o
cliente espere por tempo indeterminado, ou seja, após algum tempo, o cliente
pode assumir que a mensagem foi perdida e enviar uma nova requisição ao
servidor. As falhas de comunicação ocasionadas pela perda de datagramas UDP
podem ser mascaradas pela retransmissão das requisições pelo cliente e de
acordo com o registro das respostas recebidas.
O protocolo request-reply-acknowledge reply (requisição-resposta-
reconhecimento da resposta) é estruturado na troca de três mensagens: uma
mensagem de requisição, uma de resposta e, a última, de confirmação da
resposta. A última mensagem, a de reconhecimento da resposta, possui um
campo que identifica unicamente a mensagem que ela deseja confirmar,
geralmente um IdResposta. Para otimizar esse protocolo, assume-se que a
chegada de uma IdResposta representa a confirmação do recebimento de todas
as mensagens passadas a esse IdResposta, logo, a perda de uma mensagem
de confirmação não é tão prejudicial ao protocolo. Além disso, embora o
protocolo requisição-resposta-reconhecimento utilize uma mensagem a mais, o
cliente não precisa ficar bloqueado; ele primeiro recebe a mensagem e, só
então, envia a mensagem de confirmação.
A figura a seguir resume os conceitos apresentados sobre o protocolo de
requisição-resposta.
Para finalizar, lembre-se de que os sistemas distribuídos podem usar a
arquitetura cliente-servidor, peer-to-peer, ambas, ou outros estilos arquiteturais.
praticarVamos Praticar
Os protocolos de comunicação guiam como deve acontecer a comunicação entre as
entidades comunicantes. Além disso, os protocolos são essenciais para permitir que
entidades que não se conhecem possam se comunicar, dado que usam o mesmo
protocolo. Dito isso, o que caracteriza o protocolo requisição-resposta-reconhecimento
(request-reply-acknowledge)?
a) É enviada somente uma mensagem de requisição, geralmente para ativar
algum método no servidor, e se usa o UDP.
b) Há somente duas mensagens: uma que é requisição do cliente e outra que é
a resposta do servidor.
Figura 1.4 - Protocolos de requisição-resposta
Fonte: Adaptada de Coulouris (2013, p. 191).
c) Há uma mensagem que é enviada pelo cliente para afirmar que recebeu a
resposta do servidor.
d) Há uma única mensagem que é enviada pelo cliente usando o protocolo
TCP/IP.
e) Falta de mensagem de reconhecimento da resposta do servidor.
indicações
Material
Complementar
LIVRO
Sistemas operacionais modernos
Andrew S. Tanenbaum
Editora: Pearson Universidades
ISBN: 8543005671
Comentário: Este livro vai lhe ajudar a entender melhor
os conceitos básicos dos sistemas operacionais. Esses
conceitos servirão para auxiliar seu entendimento sobre
os sistemas distribuídos, principalmente os sistemas
operacionais distribuídos.
FILME
Star Trek Discovery
Ano: 2017-2019
Comentário: Este filme vai lhe ajudar a entender a
complexidade que existe em manter a comunicação entre
diversos sistemas em tempo real, uma dificuldade comum
aos sistemas distribuídos.
Para conhecer mais sobre o filme, acesse o trailer
disponível em:
TRAILER
conclusão
Conclusão
Nesta unidade, você aprendeu um pouco mais sobre os sistemas distribuídos.
Você conheceu as características que definem um sistema distribuído e como
analisá-las, bem como as características de escalabilidade, abertura, tolerância a
falhas, concorrência, transparência, dentre outras. Além disso, você entendeu
como se estrutura um sistema distribuído a partir de protocolos de comunicação,
o que são e como funcionam os processos dentro do sistema operacional que
gerencia os recursos da máquina (hardware) de um servidor ou cliente e como
identificar os processos. Por fim, você conheceu o modelo cliente-servidor e
suas principais características, como os elementos que o compõem e os
protocolos que são utilizados para comunicação.
referências
Referências
Bibliográficas
COULOURIS, G. Sistemas distribuídos: conceitos e projeto. São Paulo:
Bookman, 2013.
FLYNN, M. J. Some Computer Organizations and Their Effectiveness. IEEE
Transactions on Computers. C-21 (9). Sept/1972, p. 948-960. Disponível em:
https://pdfs.semanticscholar.org/4ed0/5370f6d622ee57bc79037e8fe940b73bec33.pdf.
Acesso em: 14 jan. 2020.
TANENBAUM, A. S. Sistemas distribuídos princípios e práticas. São Paulo:
Pearson Prentice Hall, 2007.
https://pdfs.semanticscholar.org/4ed0/5370f6d622ee57bc79037e8fe940b73bec33.pdf