02 Processos em sistemas distribuídos

Prévia do material em texto

Processos em sistemas distribuídos
Apresentação
À medida que os sistemas distribuídos evoluem, as aplicações nesses ambientes tornam-se cada 
vez mais importantes e complexas. Dessa forma, é importante focar no desempenho desses 
sistemas. Os elementos básicos de execução em um sistema computacional são processos e thread. 
As threads viabilizam meios de aumentar o desempenho de um sistema distribuído explorando os 
recursos de hardware e software das arquiteturas computacionais atuais. Outro conceito importante 
é a virtualização que tem sido amplamente aplicada e utilizada em sistemas distribuídos, focando na 
reutilização de recursos sob demanda, apresentando diversas vantagens nos sistemas distribuídos, 
como maior flexibilidade e disponibilidade com menos custos.
Nesta Unidade de Aprendizagem, você vai aprender sobre processos e threads, especialmente 
sobre threads em sistemas distribuídos. Além disso, você vai compreender como o conceito de 
virtualização é aplicado em sistemas distribuídos. Por fim, vai conhecer exemplos de processos 
cliente e servidor em sistemas distribuídos.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Explicar a importância das threads em sistemas distribuídos.•
Descrever a aplicação de virtualização em sistemas distribuídos.•
Exemplificar processos cliente e servidor em sistemas distribuídos.•
Desafio
O mundo já passou por algumas pandemias, como a de Covid-19 e a de H1N1. Nesse contexto, 
recente o uso de assistentes virtuais passou a ser uma das soluções mais adotadas no atendimento 
ao cliente. Devido ao isolamento social imposto durante a quarentena da Covid-19, muitas 
empresas se viram com um número de funcionários reduzidos e foi preciso intensificar o uso de 
assistentes virtuais para as diferentes lacunas que o cenário representa.
Você é consultor em uma empresa de gerenciamento de TI chamada Virtual System Solutions, 
localizada em Porto Alegre, Rio Grande do Sul. Um dos principais produtos da empresa é fornecer 
frameworks que auxiliam no desenvolvimento e na implantação de assistentes virtuais de sistemas 
Web em geral.
Veja mais:
Sendo assim, responda: qual a possível solução para resolver esse problema?
Infográfico
Os dois elementos básicos de execução de um sistema computacional são processos e threads. Ao 
mesmo tempo que esses conceitos se relacionam e se complementam, apresentam diferenças e 
alguns aspectos como processamento, armazenamento, relacionamento e compartilhamento de 
recursos.
Neste Infográfico, veja as principais diferenças entre processos e threads.
Aponte a câmera para o 
código e acesse o link do 
conteúdo ou clique no 
código para acessar.
https://statics-marketplace.plataforma.grupoa.education/sagah/050f1315-ce5d-49cb-a37e-f62df0e95533/399d7edc-3b89-45e1-b780-fd2e9395a660.png
Conteúdo do Livro
Sem processos e threads seria inviável executar todo e qualquer tipo de aplicação em qualquer 
sistema computacional. Threads, também chamadas de processos leves, são segmentos de 
processos. Dessa forma, buscando explorar o hardware das arquiteturas atuais compostas de mais 
de uma unidade de processamento, a aplicação do conceito de threads em sistemas distribuídos é 
fundamental para o desempenho de uma grande maioria de aplicações. Contudo, os sistemas 
distribuídos estão cada vez mais heterogêneos e sobrecarregados. Por isso, o conceito de 
virtualização é importante, pois viabiliza a virtualização de recursos, tornando possível criar 
máquinas virtuais de forma totalmente desvinculada do hardware.
No capítulo Processos em sistemas sistribuídos, você vai ver algumas características dos elementos 
básicos de execução: processos e threads. Além disso, vai estudar sobre a aplicação de threads, 
especificamente, em sistemas distribuídos. Por fim, vai entender sobre os processos cliente e 
servidor em um sistema distribuído. 
Boa leitura.
SISTEMAS 
DISTRIBUÍDOS
Eduarda Rodrigues Monteiro
Processos em sistemas 
distribuídos
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Explicar a importância de threads em sistemas distribuídos.
 � Descrever a aplicação de virtualização em sistemas distribuídos.
 � Exemplificar processos de cliente e servidor em sistemas distribuídos.
Introdução
Um dos principais conceitos de sistemas operacionais (SO) é o de proces-
sos. Nessa área, processo é definido como uma abstração de um programa 
em execução. Na perspectiva de SO, o gerenciamento e o escalamento 
de processos são aspectos fundamentais. No paradigma de programação 
sequencial, um processo é um programa em execução considerando um 
único fluxo de controle. As arquiteturas de processadores convencionais 
atuais fornecem os recursos que viabilizam um processo a ter mais de 
um fluxo de controle (ou execução). A partir desse avanço tecnológico, 
os paradigmas de programação evoluíram e, atualmente, dependem da 
natureza da aplicação ou da sua complexidade para ser implementada, 
considerando os paradigmas de programação concorrente e/ou paralelos. 
Assim, grande parte dos programas atuais são constituídos por mais de 
um fluxo de execução e chamados de threads. 
Com o conceito de virtualização de recursos, as arquiteturas cons-
tituídas com apenas uma unidade de processamento aliadas aos SO 
atuais, providos de processos e threads, oferecem meios de execução 
para mais de uma tarefa simultaneamente. A virtualização viabiliza que o 
hardware execute várias instâncias, de diferentes sistemas, paralelamente 
e, dessa forma, aplicações passam rodar em SO distintos em uma mesma 
plataforma. 
Neste capítulo, você verá a função fundamental dos diferentes tipos 
de processos em sistemas distribuídos. Aprenderá sobre threads e seu 
respectivo papel nos sistemas distribuídos. Além disso, conhecerá o 
conceito de virtualização, seus tipos e como funcionam as diferentes 
modelagens em sistemas distribuídos. Por fim, você verá exemplos de 
processos cliente e servidor e sistemas distribuídos, bem como eles são 
modelados de forma independente. 
1 Aplicação de threads em sistemas distribuídos 
Thread é um fluxo de execução de processo, também conhecida como “pro-
cessos leves”. Seu principal objetivo em SO é auxiliar na execução de uma 
aplicação, associando vários fluxos de execução a um único processo. Aliado 
aos componentes de hardware, inerentes às arquiteturas de processadores 
atuais (multicore e multiprocessadas), uma das principais vantagens do uso 
de threads é o desempenho, pois podem acelerar a execução de tarefas simul-
tâneas que envolvem o mesmo programa. O conceito de processos e threads 
apresenta muitas similaridades e, por isso, serão apresentados a seguir de forma 
individual. Na sequência, a abordagem de threads em sistemas distribuídos 
será discorrida. 
Processos
Inicialmente é preciso compreender o que é um processo e como eles se 
relacionam e se comunicam em SO.
A execução de um programa em um sistema computacional convencional 
ocorre de forma independente, ou seja, para cada processo, o SO reserva um 
espaço de endereçamento na memória. No momento da execução de um pro-
cesso, o SO cria processadores virtuais, em que cada um tem a incumbência 
de executar um programa diferente. Sendo assim, há a necessidade de manter 
o controle entre os processos e os processadores virtuais. Para isso, cada um 
deles têm um bloco descritor de processo. A função desse bloco é armazenar 
informações importantes sobre todo contexto de execução do processo em 
questão. O bloco descritor de processos, portanto, inclui uma tabela que arma-
zena registros de diferentes contextos, como do gerenciamento de processos 
(registros, program counter [PC], ponteiro da pila, identificador do processo, 
Processos em sistemas distribuídos2
prioridade, entre outros), do gerenciamento de memória (ponteiros para seg-
mentos de memória que armazenam dados e informações sobre segmentos) 
e do gerenciamento de arquivos(informações sobre diretórios, descritores 
de arquivos que estão sendo utilizados pelo processo em questão e aspectos 
sobre permissões entre usuário e grupos).
Como, em geral, os processos são executados independentemente entre si, 
ressalta-se que o SO é responsável por garantir a concorrência entre diversos 
processos em execução e concorrendo por recursos compartilhados, tanto de 
software como de hardware, como variáveis, núcleos de execução, memória 
(considere o subsistema hierárquico que constitui um tradicional — registra-
dores, caches, memória principal e secundária) e elementos de entrada/saída. 
Threads
Os conceitos de processos e threads são muito similares, por isso, atualmente, 
os processadores de propósito geral e sistemas computacionais são multipro-
gramados, ou seja, capazes de executar mais de uma tarefa simultaneamente. 
Sistemas computacionais convencionais fornecem um espaço de armazena-
mento de memória para cada processo e, pelo menos, uma thread de controle. 
Em algumas aplicações é factível ter múltiplas threads de controle em um 
mesmo espaço de endereçamento, executadas de forma concorrente. 
Uma das principais motivações para o uso de threads é explorar o soft-
ware e o hardware, respectivamente. Em termos de software, a partir de 
uma análise prévia (do sistema e/ou do domínio da aplicação), identifica-se 
diversas aplicações e tarefas executadas ao mesmo tempo. Por outro lado, o 
uso de threads é importante para a exploração dos níveis de paralelismos que 
compõem as arquiteturas dos processadores atuais. Outro aspecto importante 
sobre threads é que, na maioria dos sistemas, o tempo de criar e destruir uma 
pode ser até 100 vezes mais rápido, quando comparado ao de um processo 
(TANENBAUM, 2010). O terceiro argumento, referente à importância das 
threads, é o desempenho. Além dos custos de manutenção de uma thread 
serem significativamente menores que os de um processo, seu modelo de 
programação envolve a decomposição de uma aplicação em múltiplas threads, 
as quais são executadas de forma independente. Em resumo, a utilidade das 
threads se destaca em ambientes compostos de múltiplos nodos (CPUs) nos 
quais é possível aplicar um paralelismo real, ou seja, em sistemas distribuídos. 
3Processos em sistemas distribuídos
Threads em sistemas distribuídos
As threads fornecem uma granularidade fina (COULOURIS et al., 2013), 
uma vez que múltiplas delas podem realizar o controle de um processo. Essa 
característica é muito útil para a criação de aplicações em ambientes distri-
buídos compostos de máquinas multithreads, em que o foco principal é a 
obtenção de desempenho. Ademais, threads são importantes em sistemas 
distribuídos porque auxiliam diretamente nos modelos estruturais de clientes 
e servidores, sobretudo em servidores, pois atualmente é muito difícil que eles 
sejam implementados sem o conceito de threads. Diferentemente de proces-
sos, as threads compartilham o mesmo espaço de armazenamento, portanto, 
o desenvolvimento de aplicações multithreads nativas torna-se mais complexo, 
uma vez que o desafio da concorrência fica mais evidente e requer mecanismos 
adicionais, como mão de obra especializada para prover o controle dos recursos 
compartilhados e da consistência dos dados resultantes das aplicações. 
Um aspecto relevante sobre o uso de threads refere-se à execução, pois 
elas permitem o bloqueio de chamadas de sistemas sem precisar do processo 
como um todo. Essa característica é útil para a comunicação em sistemas 
distribuídos, pois as threads viabilizam um meio de manter múltiplas conexões 
lógicas no momento. Por essa razão, serão descritos clientes e servidores 
multithreads a seguir. 
Clientes multithreads 
Ocultar tempos longos de propagação de mensagens entre processos em redes 
de alta e ampla disponibilidade é uma das motivações para o uso de clientes 
multithreads em sistemas distribuídos, pois, a partir desta característica, 
é possível prover um alto nível de transparência de distribuição. Ademais, 
ao lidar com comunicações de curso longo, devemos considerar que o tempo 
para conclusão de cada operação é, por vezes, significativo, o que se torna 
um possível problema. 
Processos em sistemas distribuídos4
Um exemplo típico de clientes multithreads são os navegadores web, 
os quais geralmente iniciam buscando uma página Hypertext Markup Lan-
guage (HTML) e as exibem posteriormente. Em geral, um documento web 
é formado de um arquivo HTML e, para realizar a busca de cada elemento, 
precisa de (TORRES, 2010): 
 � uma conexão Transmission Control Protocol (TCP)/Internet Protocol 
(IP); 
 � ler a entrada de dados; 
 � passar os dados para um componente de exibição. 
As etapas de configuração de uma conexão e da leitura dos dados recebi-
dos são, por padrão, operações bloqueantes. Focando em ocultar latências de 
comunicação, alguns navegadores web exibem os dados à medida que ainda 
estão chegando. Enquanto o texto é disponibilizado ao usuário, o navegador 
realiza a busca de outros arquivos que compõe a página em questão. 
Dessa forma, o usuário não precisa aguardar todos os componentes que 
formam a página serem buscados para obtê-la. Você pode observar que o na-
vegador web realiza mais de uma tarefa simultaneamente e, portanto, perceber 
que a implementação de um cliente multithread em um navegador web ajuda 
significativamente no desempenho da aplicação. Outra vantagem é que nave-
gadores web implementados como clientes multithreads viabilizam a abertura 
de diversas conexões ao mesmo tempo. Em resumo, a utilização de clientes 
multithreads considera que os dados podem ser distribuídos e replicados em 
vários servidores. Nesse cenário, a utilização de threads viabiliza os clientes 
estabelecerem conexões distintas com o objetivo de disponibilizar um docu-
mento único em paralelo, como resultado, o documento web inteiro é exibido 
em um tempo consideravelmente menor, quando comparado à utilização de 
servidor não replicado. Por essa razão, é importante realizar uma análise de 
implementação multithread de forma análoga ao servidor. 
5Processos em sistemas distribuídos
Servidores multithreads 
A implementação de mecanismos mutltithreads auxilia no desenvolvimento do 
servidor, provendo uma simplificação considerável no código e viabilizando 
meios que facilitam a exploração do paralelismo, com o intuito de obter o 
melhor desempenho possível. 
Como estudo de caso de servidores multithreads, considere um servidor 
de arquivos que, eventualmente, apresentará pedidos de bloqueio enquanto 
aguarda alguma operação no disco. O funcionamento básico de um sistema 
de arquivos acontece da seguinte maneira: 
 � aguarda por uma solicitação de operação em um arquivo (seja de leitura 
ou escrita); 
 � executa a solicitação;
 � envia os resultados requisitados.
A Figura 1 apresenta um diagrama de um servidor multithread.
Figura 1. Servidor multithread organizado segundo modelo despachante/operário.
Fonte: Adaptada de Tanenbaum e Van Steen (2007).
Thread despachante
Requisição despachada
para um thread operário Servidor
Thread operário
Sistema operacional
Requisição que está
chegando da rede
Processos em sistemas distribuídos6
No modelo ilustrado na Figura 1, a thread despachante (do inglês, dis-
patcher) (CARISSIMI; ROCHOL; GRANVILLE, 2009), lê as requisições 
vindas de clientes via rede referentes a possíveis operações em um arquivo. 
Após analisar essas solicitações, a thread despachante escolhe uma operária 
(do inglês, worker thread) ociosa para tratar de cada uma das requisições. 
Ao final, os resultados são enviados.
Outra alternativa de implementação desse estudo de caso é considerar a 
possibilidade de operar com uma thread (do inglês, single thread) e também 
conhecida como monothread. O principal laço do servidor de arquivos recebe 
uma requisição de um cliente, analisa e executa toda a solicitação até sua 
conclusão. Enquanto aguarda pelo disco, o servidor fica ocioso e não realiza 
nenhum processamento,ou recebe qualquer outra requisição. Portanto, ser-
vidores single threads não conseguem receber e tratar requisições de outros 
clientes enquanto realizam operações de entrada e saída (leitura de disco). 
Além disso, se o servidor de arquivos estiver executando em uma máquina 
dedicada (assim como ocorre nos e arquivos), a CPU ficará ociosa enquanto o 
servidor de arquivos espera pelo disco. Como resultado, verifica-se que número 
de solicitações tratadas por unidade de tempo é menor, quando comparado 
à implementação multithreads. Assim, fica evidente que o ganho em termos 
de desempenho é significativo na aplicação de threads nas implementações.
A terceira alternativa para implementar servidores é a partir do uso de 
máquina de estados finito (VAN STEEN; TANENBAUM, 2017), cuja imple-
mentação considera o modelo monothread, mas oferece operações de envio 
e recebimento (do inglês, send e receive, respectivamente) não bloqueantes. 
Essas três estratégias estão dispostas no Quadro 1. 
Fonte: Adaptado de Tanenbaum e Van Steen (2007).
Modelo Características
Threads Paralelismo, chamadas bloqueadoras de sistema
Processo monothread Sem paralelismo, chamadas bloqueadoras de 
sistema
Máquina de estado finito Paralelismo, chamadas de sistemas não bloqueadas
Quadro 1. Modos de construir um servidor
7Processos em sistemas distribuídos
A alternativa multithread apresenta como principal característica a explo-
ração do paralelismo com o bloqueio de chamadas de sistemas. Por outro lado, 
a estratégia monothread permite o bloqueio de chamadas de sistemas, mas não 
apresenta meios para exploração do paralelismo. Por fim, a implementação 
baseada em estados finitos apresenta um potencial relevante em termos de 
desempenho, por meio da exploração do paralelismo, mas o fato de não bloquear 
chamadas torna a implementação e o controle do sistema mais complexos, 
pois o processo inteiro que está executando a thread acaba sendo bloqueado. 
2 Virtualização
Considerando um sistema single-trhead, por exemplo, a execução simultânea 
é uma utopia, a sensação de que o paralelismo ocorre é porque os chavea-
mentos entre processos e threads é realizado rapidamente. A virtualização de 
recursos surge com o objetivo de fazer apenas uma CPU ser capaz de simular 
a existência de mais unidades de processamento, ou seja, a capacidade de 
simular vários núcleos de execução que podem se expandir e atender a outros 
recursos. Portanto, a ideia básica da virtualização de recursos é considerar 
que, hipoteticamente, há um recurso replicado no sistema. 
O conceito de virtualização de recursos existe há muitas décadas, mas tem 
obtido atenção crescente no desenvolvimento e na programação de sistemas 
computacionais, especialmente em ambientes distribuídos, os quais, ao longo 
do tempo, tornaram-se mais comuns e mais complexos. Em termos práticos, 
todo sistema computacional, principalmente distribuído, fornece uma interface 
de programação de software em um nível mais alto, uma vez considerados 
seus respectivos sistemas subjacentes de software e de hardware, conforme 
representado na Figura 2a. Há diferentes tipos de interfaces, abrangendo 
desde um conjunto básico de instruções oferecidas pela CPU, até uma ampla 
coleção para programação viabilizadas por muitos sistemas de middlewares 
atuais. Em geral, a proposta consiste em estender ou substituir uma interface 
existente, a fim de simular o comportamento de outro sistema, como ilustrado 
na Figura 2b.
Processos em sistemas distribuídos8
Figura 2. (a) Organização geral entre programa, interface e sistema. (b) Organização geral 
da virtualização do sistema A sobre o sistema B.
Fonte: Tanenbaum e Van Steen (2007, p. 48) e Van Steen e Tanenbaum (2017, p. 117). 
Virtualização em sistemas distribuídos
A virtualização foi introduzida na década de 1970 para reutilização de hard-
ware e componentes. O modelo IBM 370 e seus sucessores foram exemplos 
de sucesso da virtualização em sistemas distribuídos, uma vez que forneciam 
máquinas virtuais com diferentes SO. 
É importante ressaltar que, naquele período, à medida que o hardware ficava 
mais barato, os computadores ficavam mais potentes e a quantidade de tipos 
diferentes de SO diminuía, fazendo a virtualização deixar de ser um problema 
importante. Todavia, no final da década de 1990, ocorreram mudanças (VAN 
STEEN; TANENBAUM, 2017), porque enquanto componentes de hardware 
e software de baixo nível mudam com rapidez, os softwares que apresentam 
níveis mais altos de abstração, tendem a ser mais estáveis. 
Considerando que softwares legados não conseguem manter o ritmo das 
plataformas (em termos de alterações), as quais eles dependem hierarqui-
camente, o conceito de virtualização é muito importante, pois os auxilia a 
permanecer em novas plataformas, e cada aplicação ser portada e executada 
em sua respectiva máquina virtual, incluindo artefatos como bibliotecas e SO. 
Dessa forma, o processo de virtualização oferece algum grau de portabilidade 
e flexibilidade aos sistemas. Aliado a esses aspectos, além da portabilidade e 
da permissão de permanência de softwares legados, a virtualização também 
é auxilia na manutenção de middlewares. 
9Processos em sistemas distribuídos
Tipos de virtualização 
Para compreender as diferenças inerentes à virtualização, é importante reportar 
que os sistemas computacionais em geral fornecerem três tipos de interfaces: 
1. uma interface entre o software e o hardware, denominada instructions 
set architecture (ISA), formada de um conjunto de instruções de má-
quina que podem ser invocadas por qualquer programa e subdivididas 
em instruções gerais e privilegiadas;
2. uma interface que consiste basicamente em chamadas de sistemas, um 
dos mecanismos de comunicação entre processos (ou threads) em SO; 
3. uma interface chamada de bibliotecas, geralmente conhecidas como 
application programming interface (API).
Essas interfaces são divididas em quatro níveis, apresentados na Figura 3. 
Figura 3. Interfaces oferecidas por sistemas computacionais
Fonte: Adaptada de Tanenbaum e Van Steen (2007).
Aplicação
Biblioteca
Sistema operacional
Hardware
Funções de
biblioteca
Chamadas de
sistema
Instruções
privilegiadas
Instruções
gerais
Observando a Figura 3, pode-se perceber os quatro níveis distintos: aplica-
ção, biblioteca, SO e hardware, que abrangem três interfaces, já enumeradas 
anteriormente. A essência do processo de virtualização é simular o papel de 
cada uma delas em um ambiente virtual.
Processos em sistemas distribuídos10
A virtualização pode acontecer por meio de dois caminhos diferentes, 
representados na Figura 4. 
Figura 4. (a) Máquina virtual de processo. (b) Monitor de máquina virtual nativa. (c) Monitor 
de máquina virtual hospedeira.
Fonte: Adaptada de Van Steen e Tanenbaum (2017). 
Aplicação/bibliotecas Aplicação/bibliotecas
Aplicação/bibliotecas
Sistema em execução
Sistema
operacional
(a) (b) (c)
Sistema
operacional
Sistema
operacional
Sistema
operacional
Monitor de máquina
virtual
Monitor de máquina
virtual
Hardware Hardware Hardware
De acordo com a Figura 4a, a máquina virtual de processo consiste em 
desenvolver um sistema de tempo de execução que forneça um conjunto de 
instruções abstratas e que podem ser invocadas na execução das aplicações. 
Essas instruções podem ser interpretadas ou emuladas, por exemplo, o ambiente 
java runtime environment (JRE). 
Já a opção da Figura 4b representa um monitor de máquina virtual nativa, 
que consiste na implementação de um sistema sobre uma camada que emula 
o hardware original subjacente e, como interface de usuário, fornece um 
conjunto completo de instruções do mesmo ou de outro hardware. É chamada 
de máquina virtual nativa porque sua implementação é realizada diretamente 
na camada acima do hardware subjacente, ou seja, a máquina física (também 
conhecida como bare metal). O interessante dessa abordagem é a possibilidade 
de executar vários tipos de programas e SO (nesse contexto também conhecidoscomo guests) de forma independente e simultânea em uma mesma plata-
forma. Esse tipo de virtualização se aplica ao fundamento de infraestruturas 
hiperconvergentes (TORRES, 2010), nas quais, por exemplo, um servidor é 
11Processos em sistemas distribuídos
configurado em uma máquina virtual como se fosse um sistema computacio-
nal qualquer sem vínculo algum com o hardware e, a partir disso, torna-se 
possível movê-la para outro hardware, diminuindo os custos de inatividade 
do servidor. Por essa razão, essa estratégia de virtualização é importante em 
relação à segurança do sistema (principalmente no aspecto da confiabilidade) 
e portabilidade. Referente à segurança, essa estratégia propicia o isolamento 
completo de uma aplicação, evitando que uma falha (tanto por erro ou por 
ataques à segurança) não afete a máquina completamente. Por outro lado, 
em termos de portabilidade, possibilita que todo ambiente possa ser movido 
de uma máquina para outra, pois permite que hardware e software sejam 
manipulados de forma desvinculada um do outro. Uma possível desvantagem 
dessa estratégia é que, sabendo que um monitor de máquina virtual nativo 
necessita fornecer e controlar o acesso de diferentes recursos, dependendo do 
hardware e do SO em questão, pode haver a necessidade de implementação de 
drivers de alguns recursos, como aspectos de conectividade (redes, bluetooth) e 
dispositivos gráficos (placas gráficas dependendo do fabricante). Um exemplo 
típico dessa abordagem é o software VMWare EXXi e o uso de um monitor 
de máquina virtual hospedado, altamente popular em sistemas distribuídos 
modernos, como data centers e nuvens, além de fornecerem meios para criação 
de clusters de servidores.
Diante da possível necessidade de implementação de drivers de dispositivos, 
em caso de alguma eventual incompatibilidade entre o hardware original e a 
máquina virtual, há uma variação desse segundo tipo de virtualização (Figura 
4c). O monitor de máquina virtual hospedada, focando em suprir essa lacuna, 
é executado “em cima” de um SO hospedeiro. Em outras palavras, é uma 
camada que “roda” em cima do sistema instalado no host (máquina física), 
sendo considerado o processo do SO hospedeiro que viabiliza a criação de 
máquinas virtuais, nas quais várias instâncias de SO virtualizados podem 
ser instaladas. Nesse caso, o monitor de máquina virtual se beneficia das 
diversas facilidades propiciadas pelo SO hospedeiro. A partir disso, esse tipo 
de virtualização passa a receber privilégios especiais, pois o SO que recebe 
as solicitações é o hospedeiro. No entanto, como todas as máquinas virtuais 
compartilham o mesmo kernel e, assim, concorrem por recursos como qualquer 
outra aplicação, esse tipo de virtualização se torna uma alternativa adequada 
para a implementação de data centers, por exemplo. Um exemplo típico dessa 
estratégia de virtualização é o VMPlayer ou VirtualBox.
Processos em sistemas distribuídos12
3 Exemplos de processos cliente/servidor 
em sistemas distribuídos
Nesta seção, será apresentada uma descrição mais precisa de clientes e 
servidores. 
Clientes
A principal tarefa de uma máquina cliente é prover meios de interação entre 
usuários e seus servidores remotos. Para isso, existem duas estratégias pos-
síveis, ilustradas na Figura 5.
Figura 5. (a) Aplicação em rede com seu próprio protocolo. (b) Solução geral para permitir 
acesso a aplicações remotas.
Fonte: Adaptada de Tanenbaum e Van Steen (2007) e Van Steen e Tanenbaum (2017).
(a)
Máquina cliente
Protocolo
independente
de aplicação
Protocolo
independente
de aplicação
Aplicação
SO Local
Middleware
Máquina cliente
Aplicação
SO Local
Middleware
Máquina do servidor
Aplicação
SO Local
Rede Rede
Middleware
Máquina do servidor
Aplicação
SO Local
Middleware
(b)
A estratégia ilustrada na Figura 5a considera que, para cada serviço re-
moto, a máquina cliente deverá fornecer uma contraparte, ou seja, permitir a 
interação (contato) com o serviço via rede. Considere um exemplo típico dessa 
estratégia: uma agenda executando no smartphone de um cliente precisa estar 
devidamente sincronizada com uma agenda remota, perceba que essa agenda 
está possivelmente compartilhada, portanto, a sincronização será efetivada 
por um protocolo de nível de aplicação. 
A segunda estratégia apresentada (Figura 5b) é uma alternativa que inde-
pende de protocolo e provê o acesso direto aos serviços remotos, oferecendo 
somente interfaces de usuários coniventes. Em outras palavras, essa alternativa 
visa apresentar uma solução neutra, ou seja, independente de aplicação, por 
exemplo, nas quais a máquina cliente é utilizada apenas como um terminal 
13Processos em sistemas distribuídos
(sem a necessidade de armazenamento local) que repassa os comandos para que 
tudo seja executado e armazenado no servidor. Além disso, nessa estratégia é 
importante fornecer as informações inerentes a interface do usuário, mas que 
não tenha conhecimento do(s) servidor(es) ao(s) qual(is) ele está se conectando, 
ou seja, é de extrema relevância que a implantação do cliente oculte a comu-
nicação que ocorre com o servidor e mantenha um dos principais desafios de 
sistemas distribuídos: a transparência de acesso. Para isso, o middleware pode 
auxiliar ocultando a ocorrência de alteração de servidores que estão atendendo 
às requisições, provendo transparência de conexão e replicação. Garantindo 
diferentes transparências, o usuário não tem conhecimento da ocorrência de 
alguma perda de conexão com servidor durante a execução da aplicação. Essa 
abordagem, que consistem em terminais clientes minimizados (do inglês, 
thin clients), tem atenção crescente à medida que a conectividade da Internet 
cresce e dispositivos móveis estão cada vez potentes. 
Baseado nessa ideia, a literatura apresenta outro modelo importante em 
relação aos clientes, que considera o software como muito mais do que apenas 
uma interface com o usuário, mas que também é possível ter parte do proces-
samento e dados em uma aplicação cliente/servidor sendo executados no lado 
do cliente. Esse modelo é chamado de software cliente/servidor (do inglês, 
client/server software) e formado por dispositivos que abrangem softwares 
em cliente embarcado, como caixas eletrônicos, leitores de código de barras 
e decodificadores de televisões. Nessa modelagem, as interfaces de usuá-
rios são consideradas uma pequena parte do software cliente, em contraste 
com as facilidades de processamento local e comunicação (VAN STEEN; 
TANENBAUM, 2017). 
Servidores
A ideia geral de cada servidor é sempre organizada da mesma maneira, primeiro 
há a espera por uma requisição de um cliente, na sequência garante-se que a 
solicitação seja atendida e, depois disso, espera o próximo chamado. Um ser-
vidor implementa um serviço específico em nome de uma coleção de clientes. 
Existem dois tipos de servidores: iterativos e concorrentes. Um servidor 
iterativo gerencia as requisições e retorna o resultado ao cliente solicitante. 
Já um concorrente pode ser implementado com processos filhos ou threads 
dispachers, em que a manipulação das requisições são papéis desempenhados 
separadamente pelas threads ou por processos inerentes ao mesmo servidor. 
Processos em sistemas distribuídos14
Dessa forma, cada thread ou processo que gerencia as requisições é responsável 
por enviar a resposta ao cliente solicitante. Servidores concorrentes podem lidar 
com várias solicitações, principalmente na presença de operações bloqueantes 
(em discos ou em outros servidores). Nesse sentido, pode-se dizer que, uma vez 
considerada a implementação de um servidor com threads, o sistema atende 
às requisições separadamente e, esse servidor concorrente é um multihread. 
Outra questão interessante é como os clientes entram em contato com um 
servidor. Em geral, eles enviam solicitações para uma porta, na qual o servidor 
está executando e aguardando requisições (cada servidor escuta em uma porta 
específica). Aliado a esse cenário,os clientes precisam saber previamente em 
qual(is) porta(s) o servidor está executando. Uma das abordagens utilizadas é 
os serviços conhecidos atenderem em portas padrão. O Quadro 2 mostra que 
a maioria dos serviços estão vinculados a portas específicas.
Fonte: Adaptado de Van Steen e Tanenbaum (2017).
Nome do serviço Acrônimo Porta
File Transfer [Default Data] ftp-data 20
File Transfer [Control] ftp 21
Telnet telnet 23
Simple Mail Transfer smtp 25
Web (HTTP) www 80
Quadro 2. Serviços e portas vinculadas
Conhecendo as portas em que os servidores atendem na maioria dos ser-
viços, como listado no Quadro 2, os clientes precisam encontrar o endereço 
da máquina que estão utilizando, para isso, os nomes dos serviços podem ser 
utilizados com esse propósito. Existem muitos serviços que não requerem uma 
porta conhecida, por exemplo, um serviço que fornece o horário e pode utilizar 
uma porta dinâmica atribuída pelo seu próprio SO local. Visando soluções 
mais genéricas, duas estratégias que focam em vincular cliente/servidor são 
ilustradas na Figura 6. 
15Processos em sistemas distribuídos
Figura 6. (a) Vinculação de um cliente/servidor usando um daemon. (b) Vinculação 
cliente/servidor usando um supervisor.
Fonte: Adaptada de Tanenbaum e Van Steen (2007) e Van Steen e Tanenbaum (2017).
Máquina cliente
Cliente
Daemon
Servidor
Máquina do servidor
Porta
registradora
Tabela de
portas
(a)
Máquina do servidor
Servidor
propriamente
dito
Super-
servidor
Criar
servidor
para
serviço
requisitado
2. Requisitar
 serviço
1. Solicitar
 porta
2. Continuar
 serviço
1. Requisitar
 serviço
Cliente
Máquina cliente
(b)
A Figura 6a ilustra uma solução baseada em um daemon especial, que 
atuam em cada máquina que executa os serviços. O daemon controla a porta 
atual de cada serviço implementado por um servidor e executa em uma porta 
conhecida. Dessa forma, um cliente realizará o contato com o daemon e 
solicitará a porta, em seguida, conseguirá entrar em contato com o servidor 
específico. Portanto, o daemon funciona como um componente intermediário, 
executando em uma porta conhecida por todos os clientes e repassando as 
conexões para um servidor específico. 
Processos em sistemas distribuídos16
Vincular uma porta a um serviço específico é muito comum, no entanto, 
implementar cada serviço por meio de um servidor separado tende refletir 
em desperdício de recursos. Um exemplo desse cenário são sistemas Unix, os 
quais comumente tem uma quantidade significativa de servidores executando 
simultaneamente. Em vez de controlar o número elevado de processos, torna-se 
mais eficiente o uso de um superservidor, o qual executa cada porta vinculada 
a um serviço específico (Figura 6b). 
Existem, ainda, servidores sem estado (do inglês, stateless servers) e com 
estado (do inglês, stateful servers). Um servidor sem estado nunca mantém 
informações do status de seus clientes após processar uma solicitação, por 
exemplo, quando um arquivo é aberto para atender a uma determinada soli-
citação, ele não armazena esse registro e simplesmente fecha o arquivo após 
acessá-lo. Além disso, pode alterar seu próprio estado sem a necessidade de 
informar nenhum cliente. Uma alternativa ao projeto de servidores sem estado 
é conhecida como estado flexível (do inglês, soft state), a qual mantém o que 
é conhecido, isto é, o servidor garante conservar o estado de um cliente por 
um tempo restrito. Após esse período, o servidor descarta as informações 
que matinha do cliente vinculado. Um exemplo desse tipo de abordagem é 
quando o servidor precisa manter o cliente informado sobre atualizações por 
tempo limitado. 
Já um servidor com estado mantém as informações dos clientes, ou seja, 
elas devem ser removidas de forma explicitada. Um exemplo dessa abor-
dagem de implementação de servidor com estado é um de arquivos, que 
garante manter uma cópia local de determinado arquivo (mesmo depois de 
atualizado). Para isso, o servidor deve ter uma tabela formada por entradas 
(cliente e arquivo) que viabilize meios de monitorar e identificar os clientes 
que têm as devidas permissões para realizar atualizações em um determinado 
arquivo. Em contrapartida, se um servidor com estado falhar, perde todas as 
informações pertinentes e necessita resgatar o seu estado como era antes, 
para tanto, precisa recuperar a tabela de entradas para garantir as atualizações 
recentes dos arquivos. Além disso, é importante ressaltar que prover melhoria 
no desempenho de servidores sem estado é uma das principais motivações dos 
servidores com estado. Contudo, em caso de falhas em um servidor sem estado, 
nada precisa ser resgatado ou recuperado e nenhuma medida de contingência 
precisa ser adotada, é preciso apenas retomar sua funcionalidade e aguardar 
pelas requisições de clientes. 
17Processos em sistemas distribuídos
Nesse contexto, os estados podem ser divididos em: estado de sessão e 
estado permanente. O estado de sessão está associado à uma sequência de 
operações solicitadas por um único usuário, as quais devem ser mantidas por um 
tempo determinado. O estado de sessão é utilizado e mantido em arquiteturas 
clientes/servidor de três camadas, nas quais o servidor de aplicação necessita 
fazer uma série de consultas no banco de dados para conseguir responder à 
solicitação do cliente. Nesse caso, se o estado de sessão se perder, basta o cliente 
enviar novamente a mesma solicitação, a qual será recebida e processada sem 
acarretar nenhuma inconsistência. Por outro lado, quando se trata do estado 
permanente, as informações são geralmente persistidas no banco de dados. 
Para a maior parte dos sistemas distribuídos, manter o estado de sessão está 
diretamente relacionado ao projeto de um servidor com estado e, portanto, 
essa modelagem deve implantar medidas referentes à durabilidade de estado 
armazenada no servidor e ter como pré-requisito planos de contingência espe-
ciais na ocorrência de falhas. Por fim, ao projetar um servidor, as modelagens 
com e sem estado não devem influenciar nos serviços que oferece.
Cluster de servidores
Um cluster de servidores é um conjunto de nodos (máquinas) interconectados 
via rede de computadores, em que cada máquina pode executar um ou mais 
servidores simultaneamente. A estrutura típica de um cluster é organizada 
em três camadas, conforme demonstrado na Figura 7.
Figura 7. Organização geral de um cluster de servidores em três camadas.
Fonte: Tanenbaum e Van Steen (2007, p. 56) e Van Steen e Tanenbaum (2017, p. 142).
Comutador lógico
(possivelmente múltiplo)
Servidores de aplicação/
computação
Sistema distribuído
de arquivos/ banco
de dados
Requisição
despachadaRequisição
de cliente
Primeira camada Segunda camada Terceira camada
Processos em sistemas distribuídos18
Observando as camadas ilustradas na Figura 7, é possível observar que 
a primeira se refere a um computador lógico, responsável por distribuir as 
requisições dos clientes entre os servidores de aplicação, os quais realizarão 
as computações propriamente ditas (pertencem a segunda camada). Além 
disso, sabe-se que em qualquer arquitetura cliente/servidor multicamadas, 
vários clusters são formados de servidores dedicados aos processamentos de 
aplicações específicas, ao contrário de clusters convencionais, constituídos 
de computadores normais nos quais os servidores são tipicamente voltados 
para executar tarefas de alto desempenho. Entretanto, em clusters corporati-
vos, a capacidade de computação não é o foco principal, mas sim a garantia 
do acesso ao armazenamento. Nesse contexto, a ideia lógica dos clusters de 
servidores propõe a terceira camada, que concentra no processamento de 
dados, em especial, os de arquivos e bancos de dados. Visando atender essa 
demanda, dependendo do uso, os clusters de servidores podem rodar em 
máquinas especializadas e devidamente configuradas para garantir acesso de 
alta velocidade aos discos, considerando que são providos de caches potencial 
dearmazenamento de dados significativo do lado do servidor. 
É importante ressaltar que nem todos os clusters de servidores conse-
guirão efetivar esse gerenciamento sob demanda, pois muitos sistemas não 
conseguirão distinguir o serviço da aplicação. Dessa forma, nem todas as 
aplicações serão redirecionadas de forma correta para as máquinas adequadas 
e desenvolvidas explicitamente para atender à execução de uma natureza de 
aplicação explícita, é possível que máquinas diferentes executem aplicações 
diversas. Como consequência, dependendo do gerenciamento do cluster de 
servidores, pode-se perceber que ele é suscetível a permitir ociosidade de 
recurso, uma vez que podem haver nodos ociosos porque não há nenhuma 
aplicação exclusiva para a sua execução, ao passo que outros nodos podem 
apresentar uma elevada carga de trabalho a partir de muitas requisições para 
um único tipo de aplicação. Uma possível solução seria a virtualização focada 
em migração de código de uma máquina virtual para outra. 
19Processos em sistemas distribuídos
CARISSIMI, A. S.; ROCHOL, J.; GRANVILLE, L. Z. Redes de computadores. Porto Alegre: 
Bookman, 2009. (Série Livros Didáticos Informática UFRGS, v. 20).
COULOURIS, G. et al. Sistemas distribuídos: conceitos e projeto. 5. ed. Porto Alegre: 
Bookman, 2013. 
TANENBAUM, A. S. Sistemas operacionais modernos. 3. ed. São Paulo: Pearson, 2010.
TANENBAUM, A. S.; VAN STEEN, M. Sistemas distribuídos: princípios e paradigmas. 2. ed. 
Pearson Prentice Hall, 2007.
TORRES, G. Redes de computadores: curso completo. 2. ed. Rio de Janeiro: Novaterra, 2010. 
VAN STEEN, M.; TANENBAUM, A. S. Distributed systems. 3rd ed. [S. l.]: Createspace Inde-
pendent Publishing Platform, 2017.
Processos em sistemas distribuídos20
Dica do Professor
Considere uma arquitetura de um sistemas distribuído composta de diferentes compoenentes e 
tecnologias, tais como servidor Web, banco de dados, sistema de mensagens e orquestração. 
Houve um momento em que foi indentificada uma incompatibilidade entre alguns dos serviços 
providos pelos sistemas com a versão do sistema operacional. Esse problema acarretou a troca do 
sistema operacional atual por outro que garantia compatibilidade com todos os diferentes serviços. 
Posteriormente, os serviços começaram a apresentar problemas novamente, só que dessa vez o 
problema estava relacionado com a dependência de bibliotecas, cada serviço requeria uma 
biblioteca diferente com versões específicas. Então, a compatibilidade desses serviços e dessas 
bibliotecas com as depedências do sistema operacional também precisou ser analisada. De acordo 
com esse cenário, a arquitetura do sistema distribuído foi sendo modificada à medida que os 
problemas apareciam, isto é, troca de sistema operacional, substituição de componentes por 
 componentes com versões mais recentes, alteração de banco de dados, entre outros aspectos. Em 
suma, toda vez que algum componente ou alguma tecnologia é substituída, a equipe precisa passar 
pelo mesmo processo de verificação de compatibilidade entre os diferentes componentes e 
tecnologias com a infraestrutura do sistema.
Nesta Dica do Professor, conheça as estratégias denominadas containers e dockers, as quais têm 
sido amplamente utilizadas aliadas ao conceito de virtualização nos sistemas distribuídos atuais, 
que estão cada vez maiores, mais complexos e heterogêneos em diferentes aspectos.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
https://fast.player.liquidplatform.com/pApiv2/embed/cee29914fad5b594d8f5918df1e801fd/6d3e6700deca5e9e0f2a03de7fe40675
Exercícios
1) Considerando processos e threads, há diferentes formas de implementar um servidor, dentre 
elas: um servidor monothread (com um único fluxo de execução) e um servidor multithread 
(com mais de um fluxo de execução).
Existe alguma circunstância na qual um servidor monothread possa obter um melhor 
desempenho do que um servidor multithread?
A) Sim, muitas threads podem acarretar uma perda de desempenho.
B) Não, considerar apenas uma thread na implementação do servidor não apresenta melhor 
desempenho.
C) Sim, as threads necessitam de memória e requerem mais registradores, que são recursos mais 
caros.
D) Não, a implementação multithreads é a melhor alternativa para implementar um servidor 
independente da circunstância.
E) Sim, um servidor monothread não necessita controlar mais fluxos de execução e, por isso, 
podem obter um melhor desempenho.
2) Imagine um servidor Web que mantenha uma tabela na qual endereços IP de clientes sejam 
mapeados para as páginas Web acessadas mais recentemente. Quando um cliente se 
conecta ao servidor, o servidor consulta o cliente em sua tabela e, caso o encontre, retorna à 
página registrada.
Esse é um servidor:
A) com estado.
B) sem estado.
C) estado de sessão.
D) estado permanente.
E) com estado flexível.
3) A virtualização de recursos surge com o objetivo de fazer com que apenas uma CPU seja 
capaz de simular a existência de mais unidades de processamento, ou seja, a capacidade de 
simular vários núcleos de execução também pode se expandir de modo a atender outros 
recursos.
Quais das seguintes abordagens de gerenciamento de virtualização pode ajudar as 
organizações a manter a utilização ideal dos recursos de hardware ao longo do tempo?
A) Criando uma biblioteca de modelos de máquinas virtuais e copiando esses modelos para criar 
novas máquinas virtuais. 
B) Implementando várias cópias de máquinas virtuais em diferentes servidores hosts.
C) Colocando máquinas virtuais em computadores de rede virtual isolados.
D) Armazenando máquinas virtuais em uma SAN (Storage Area Network).
E) Reconfigurando automaticamente máquinas virtuais com base em estatísticas de 
desempenho.
4) A ideia básica da virtualização de recursos é considerar que hipoteticamente há um recurso 
replicado no sistema. Sobre as vantagens da virtualização, marque V para Verdadeiro e F 
para Falso. 
( ) Infraestrutura flexível por um custo mais baixo. 
( ) Maior eficiência no gerenciamento. 
( ) Maior disponibilidade. 
( ) Maior economia.
Assinale a alternativa correta:
A) V – V – F – V.
B) V – F – V – V.
C) F – V – V – F.
D) V – V – V – V.
E) V – V – F – V.
As threads são importantes em sistemas distribuídos porque auxiliam diretamente nos 
modelos estruturais de clientes e servidores. Principalmente em servidores, atualmente é 
5) 
muito difícil um servidor sem threads.
O principal objetivo de aplicar threads em um sistema distribuído é?
A) Transparência.
B) Concorrência.
C) Desempenho.
D) Segurança.
E) Escalabilidade.
Na prática
A virtualização foi introduzida na década de 70 e uma das razões mais importantes consiste na 
reutilização de hardware e componentes. Essa abordagem que consiste na virtualização de recursos 
tem obtido atenção crescente, principalmente em sistemas distribuídos, pois o processo de 
virtualização oferece um alto grau de portabilidade e flexibilidade aos sistemas.
Neste Na Prática, conheça o estudo de caso de uma empresa fictícia que manteve sua 
infraestrutura de servidores terceirizados. O conceito de virtualização começou a ser utilizado pela 
empresa no momento em que os usuários começaram a ter problemas com a instalação e conflitos 
de pacotes nos servidores.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para 
acessar.
https://statics-marketplace.plataforma.grupoa.education/sagah/39cf4f27-5bb8-42c0-b41e-eb5e4e938d77/866b4c67-90d2-40f4-8c65-0f4944101ab7.png
Saiba mais
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do professor:
SaaS, IaaS, PaaS (Modelos de Computação em Nuvem)
Assista ao vídeo a seguir que aborda os modelos de computação em nuvem SaSS, IaSS e PaSS.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Segurança na Internet do Futuro: Provendo Confiança 
Distribuída através de Correntes de Blocos na Virtualizaçãode 
Funções de Rede
Confira, neste artigo científico, os principais fundamentos de blockchain e virtualização e a relação 
desses conceitos com os desafios de pesquisa em segurança nas redes de nova geração.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Investigação dos Efeitos do Envelhecimento de Software na 
Plataforma Docker
Confira o artigo científico a seguir que aborda os efeitos de envelhecimento de software, focando 
na plataforma Docker.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
https://www.youtube.com/embed/-3W3AMNccms
https://www.gta.ufrj.br/ftp/gta/TechReports/RCS19.pdf
https://sol.sbc.org.br/index.php/wperformance/article/view/6478/6374?v=57157509
Análise de desempenho e segurança dos orquestradores 
Apache Mesos, Docker Swarm e Kubernetes em nuvens 
baseadas em OpenStack
Leia, neste artigo científico, um estudo que avalia o desempenho entre os orquestradores de 
containeres, Dockers Swarm, Kubernets e Apache Mesos em nuvens baseadas em OpenStack.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Descomplicando o Docker – O que é um container?
Veja, neste vídeo, um estudo que aborda características de containers e Dockers, os quais estão 
diretamente relacionados à virtualização de sistemas distribuídos.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
https://sol.sbc.org.br/index.php/eradrs/article/view/10769/10637?v=2133018911
https://www.youtube.com/embed/QFuOggpDAOw