Processos_Sistemas_Distribuidos

Prévia do material em texto

SISTEMAS DISTRIBUÍDOS 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
1 
 
- Aula 5 – 
 
PROCESSOS 
 
1. INTRODUÇÃO 
 
 Em sistemas distribuídos é importante examinar os diferentes tipos de processos e como 
eles desempenham seu papel. 
O conceito de um processo é originário do campo de sistemas operacionais no qual ele é 
definido como um programa em execução. Da perspectiva de Sistema Operacional, o 
gerenciamento e o escalonamento de processos são talvez as questões mais importantes. 
 
2. PROCESSOS 
 
Sistemas Operacionais modernos criam vários processadores virtuais, cada um para 
executar um programa. Para monitorar os processadores virtuais o sistema operacional tem uma 
tabela de processos que contém entradas para armazenar valores de registradores de CPU, 
mapas de memória, arquivos abertos, etc. 
Como visto os processos podem ser considerados programas em execução, na qual o 
Sistema Operacional é o responsável por assegurar que processos independentes não afetem 
(modos intencional, malicioso ou acidental) a correção do comportamento dos outros processos 
sendo executados. 
Nesta ótica deve também existir transparência no compartilhamento da mesma CPU e 
outros recursos de hardware. A transparência implica em custos como: 
- Criação de espaço de endereços completamente independente 
- Chavear a CPU entre dois processos 
- Salvar o contexto da CPU 
- Troca de informações entre disco e memória principal 
 
Neste sentido, em sistemas tradicionais, cada processo deve possuir o seu próprio espaço 
de endereçamento e um único fluxo de execução. No entanto, em alguns casos é desejável haver 
diversos fluxos de execução compartilhando um único espaço de endereçamento, ou seja, mesma 
região de memória. 
Em havendo um único fluxo de execução ocorre certa perda de desempenho. Como 
exemplo, um servidor de arquivos deve esperar por requisições feitas ao disco, visto que o fluxo 
de execução que fez a requisição é bloqueado aguardando a resposta. 
Com vários fluxos de execução existe melhor vazão (throughput) e ganho de desempenho. 
Seguindo o mesmo exemplo, se um servidor de arquivos é implementado usando diferentes fluxos 
de execução, outras requisições de clientes podem ser processadas, enquanto o primeiro fluxo 
aguarda a resposta do disco. 
Este é o princípio das threads . 
SISTEMAS DISTRIBUÍDOS 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
2 
 
3. THREADS 
 
 Embora processos formem um bloco de construção em sistemas distribuídos, a prática 
indica que a granularidade de processos proporcionada pelos sistemas operacionais sobre os 
quais os sistemas distribuídos são construídos não é suficiente. Em vez disso, observa-se que ter 
granularidade sob a forma de múltiplos threads de controle por processo facilita muito a 
construção de aplicações distribuídas e a obtenção de melhor desempenho. 
 
Figura 1 - Processo vs Thread 
 
 Cada um dos fluxos de execução de um processo é chamado de thread, ou seja, as threads 
podem ser vistas como mini-processos, onde cada thread executa sua própria porção de código. 
Cada thread compartilha a CPU do mesmo modo que diferentes processos compartilham 
(timesharing). 
 
3.1. Threads em sistemas não-distribuídos 
 
As threads que fazem parte de um mesmo processo não são independentes como no caso 
de diferentes processos. Todas as threads em um mesmo processo possuem a mesma região de 
memória e compartilhando as mesmas variáveis globais. Sendo assim, uma determinada thread 
pode ler, escrever ou mudar a pilha de dados de outra thread. Dessa forma, a proteção deve ser 
implementada na aplicação. 
As threads podem estar em diferentes estados: 
- Executando 
- Bloqueado 
- Pronto 
- Finalizado 
 
Dadas as características observa-se a seguinte diferença quanto ao conteúdo das threads e 
processos: 
 
SISTEMAS DISTRIBUÍDOS 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
3 
 
Quadro 1 – Itens da Thread e do Processo 
Itens por Thread Itens por Processo 
PC 
Pilha 
Registradores 
Threads Filhas 
Estado 
Espaço de endereçamento 
Variáveis Globais 
Arquivos abertos 
Processos filhos 
Sinais 
Timers 
Informações da Conta 
Semáforos 
 
3.1.1. VANTAGENS 
 
- Explorar paralelismo ao executar um programa em um sistema multiprocessador. Ex.: 
Cada thread é designado a uma CPU, enquanto dados compartilhados são armazenados em 
memória compartilhada. 
- Em grandes aplicações, desenvolvidas como um conjunto de programas cooperativos 
evita chaveamento entre diferentes processos devido comunicação através de Interprocess 
Communication (IPC). 
 
 
Figura 2 - Chaveamento de contexto como resultado de IPC 
 
Nas threads a comunicação pode ser feita com a utilização de dados compartilhados. 
O chaveamento ocorre entre espaços de usuário. 
 
3.1.2. IMPLEMENTAÇÃO DE THREADS EM SISTEMAS NÃO-DISTRIBUÍDOS 
 
Nível Usuário 
 
- As threads rodam sobre o runtime system – coleção de procedimentos que gerenciam as 
threads. 
SISTEMAS DISTRIBUÍDOS 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
4 
 
- Quando uma thread executa uma chamada de sistema, ela entra no estado de espera e 
opera um semáforo enquanto o runtime system verifica se o thread deve ser suspensa. 
- Existe um custo de criação e alocação da memória para a pilha. 
- Chaveamento de contexto de thread pode ser feito em apenas algumas instruções. Não 
há necessidade de mudar mapas de memória, descarregar o TLB (Translation Lookaside Buffer) 
- As threads precisam entrar em sincronia. 
 
 
Figura 3 - Implementação em nível de usuário 
A desvantagem de threads de nível de usuário está em como chamadas de sistemas 
bloqueantes são implementadas, como por exemplo, ler um pipe vazio, na qual a chamada de 
sistema acarretará em bloqueio de todas as threads. 
 
Nível Kernel 
 
 - A criação, encerramento e sincronização deverão ser feitos pelo kernel. 
- Chamadas de sistema deverão ser realizadas. 
- Chavear contextos de threads é tão caro quanto chavear contexto de processos. 
 
 
Figura 4 - Implementação em nível do Kernel 
 
 
 
 
 
SISTEMAS DISTRIBUÍDOS 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
5 
 
3.2. Threads em Sistemas Distribuídos 
 
 Na implementação de threads em sistemas distribuídos uma importante propriedade é que 
eles podem proporcionar um meio conveniente de permitir chamadas bloqueantes de sistema sem 
bloquear o processo inteiro. 
 
 As threads são particularmente atraentes para utilização em sistemas distribuídos, pois 
facilitam a comunicação na forma de manter múltiplas conexões lógicas ao mesmo tempo. 
 
3.2.1. CLIENTES MULTITHREADS 
 
 Os Sistemas distribuídos que operam em redes de longa distância escondem longos tempos 
de propagação de mensagens entre processos. A maneira de ocultar latências de comunicação é 
iniciar a comunicação e imediatamente prosseguir com outra atividade. 
 Em um browser web, o documento Web consiste em um texto, imagens, ícones, etc. Cada 
elemento, browser estabelece uma conexão TCP/IP, para ler os dados e passar ao monitor do 
usuário. Operações bloqueadoras fazem o estabelecimento da conexão e leitura de dados. Os 
browsers começam a exibir dados enquanto, à medida que novas informações chegam. Enquanto 
o texto está sendo disponibilizado para o usuário, incluindo as facilidades de rolamento, o browser 
continua buscando outros arquivos, como imagens. A vantagem é que o usuário não precisa 
esperar até que todos os componentes sejam buscados. 
Threads separados são ativados para se encarregar de buscar diferentes partes de uma 
página, assim caso o servidor esteja em sobrecarga, ter um cliente multithread possibilita 
estabelecer conexões com diferentes servidores, permitindo transmissão dos dados em paralelo, 
onde o cliente pode manipular fluxos de dados de entrada em paralelo, por meio de threads. 
 
 
3.2.2. SERVIDORES MULTITHREADS 
 
Um servidor de arquivos normalmenteespera pela entrada de uma requisição para uma 
operação de arquivo e, na seqüência, executa a requisição e então devolve a resposta. Com a 
utilização de threads é possível aumentar seu desempenho. 
Os servidores multithreads funcionam da seguinte maneira: 
- requisições são enviadas por clientes para uma porta no servidor. 
- Uma thread despachante lê requisições que entram para uma operação de arquivo. 
- O servidor escolhe uma thread operária. 
- Se o thread escolhido estiver suspenso, outro thread é selecionado para ser executado, 
como por exemplo, o thread despachante pode ser selecionado para adquirir mais trabalho. 
 
SISTEMAS DISTRIBUÍDOS 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
6 
 
 
Figura 5 - Servidor multithread organizado segundo modelo despachante/operário 
Se o servidor é inteiramente CPU-bound, não existe necessidade de diversos threads, 
ocorre um aumento de complexidade sem ganho de desempenho. 
 
4. VIRTUALIZAÇÃO 
 
 Threads e processos podem ser vistos como um modo de fazer diversas tarefas ao mesmo 
tempo. Em computadores monoprocessados, a execução simultânea é uma ilusão, pois possuem 
uma única CPU, ou seja, somente uma instrução de um único thread ou processo será executada 
por vez. 
A virtualização de recursos possibilita “fingir” que um determinado recurso está replicado 
no sistema. Dessa forma, estende ou substitui uma interface existente de modo a imitar o 
comportamento de outro sistema. 
 
 
Figura 6 - (a) Organização geral entre Programa, Interface e Sistema. (b) Organização geral da virtualização do 
sistema A sobre o B 
Na década de 1970 a virtualização foi aplicada com sucesso nos mainframes IBM, que 
ofereciam uma máquina virtual para executar softwares que incluíam aplicações e também os 
sistemas operacionais. 
SISTEMAS DISTRIBUÍDOS 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
7 
 
Softwares em nível mais alto são mais estáveis que o hardware e sistemas de software de 
baixo nível. Assim a virtualização pode ajudar transportando as interfaces de softwares para novas 
plataformas. As novas plataformas são capazes de executar softwares existentes anteriormente. 
 
4.1. Arquiteturas de Máquinas Virtuais 
 
Existem vários modos pelos quais a virtualização pode ser realizada na prática. Existem 
quatro tipos diferentes de interfaces em quatro níveis diferentes como representado na figura a 
seguir: 
 
 
Figura 7 - Várias interfaces oferecidas por sistemas de computadores 
 
A essência da virtualização é imitar o comportamento das interfaces (instruções de 
máquina, chamadas de sistema). 
 
4.2. Máquina Virtual de Processo 
 
 Aplicações desenvolvidas para um Sistema Operacional são executadas em outro Sistema 
Operacional. A virtualização é feita somente para um único processo. Funcionam como 
emuladores, com a finalidade de imitar chamadas de sistema. 
 
4.3. Monitor de Máquina Virtual 
 
 Fornece o conjunto de instruções completo do hardware. Vários sistemas operacionais 
diferentes executando independente e concorrentemente na mesma plataforma. Importantes no 
contexto de confiabilidade e segurança proporcionando isolamento de uma aplicação e seu 
ambiente. As falhas não afetam a máquina inteira. Exemplo: VMware, VirtualBox, VitualPC, etc. 
 
SISTEMAS DISTRIBUÍDOS 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
8 
 
 
Figura 8 - (a) Máquina Virtual de processos com várias aplicações (instâncias). (B) Monitor de Máquina Virtual com 
várias aplicações (instâncias) 
 
5. CLIENTES E SERVIDORES 
 
Uma tarefa muito importante de máquinas clientes é proporcionar aos usuários meios de 
interagir com servidores remotos. Isto pode se dar de duas formas: 
- Para cada serviço remoto, a máquina cliente terá um servidor separado, com o qual possa 
estabelecer contato. Algumas operações são feitas no próprio cliente. 
- Fornecer apenas uma interface de usuário conveniente. Máquina cliente é usada somente 
como um terminal sem nenhuma necessidade de armazenamento. 
 
 
Figura 9 - Soluções cliente-servidor 
 
5.1. Transparência na Distribuição no Cliente 
 
O software no lado cliente pode ser mais do que uma interface. Em alguns casos, parte do 
nível de processamento e dados são executadas no lado cliente. 
 
 
 
 
 
SISTEMAS DISTRIBUÍDOS 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
9 
 
5.1.1. TRANSPARÊNCIA DE MIGRAÇÃO 
 
Se um cliente já está vinculado a um servidor, ele pode ser informado quando o servidor 
mudar de localização. Um Middleware no cliente oculta do usuário a corrente localização do 
servidor. 
 
5.1.2. TRANSPARÊNCIA A FALHA 
 
O Middleware cliente pode ser configurado para tentar a conexão com um servidor 
repetidas vezes, ou tentar outro servidor após várias tentativas. O uso de cachê minimiza uma 
falha na conexão com o servidor. 
 
5.2. Servidores 
 
5.2.1. QUESTÕES DE PROJETO 
 
 Cada servidor é organizado do mesmo modo: 
- Espera por uma requisição de um cliente. 
- Assegura o atendimento. 
- Espera pela próxima requisição. 
 
5.2.2. TRATAMENTO DE REQUISIÇÕES 
 
Em um Servidor Iterativo, o próprio servidor manipula a requisição e, se necessário, 
retorna uma resposta ao cliente. 
Um Servidor Concorrente não manipula por si próprio a requisição. Como nos servidores 
multithreads e processos ou threads que devolvem a resposta ao cliente. 
 
5.2.3. REQUISIÇÃO DO CLIENTE 
 
Clientes enviam requisições a uma porta, na máquina em que o servidor está executando 
Para alguns serviços conhecidos (FTP,HTTP) existem portas pré-definidas. Para serviços que não 
requerem porta pré-determinada, uma opção é ter um daemon, onde o cliente o acessa e o 
sistema operacional informa dinamicamente uma porta. 
Outra maneira de manipular portas é o uso de superservidores. Para os casos onde 
diversos servidores que possuem uma porta específica estão rodando em uma mesma máquina. O 
monitoramento passa a ser realizado por um superservidor à escuta em cada porta associada com 
um serviço específico. Exemplo é o daemon inetd no Unix. 
 
SISTEMAS DISTRIBUÍDOS 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
10 
 
 
Figura 10 - (a) Daemon. (b) Supervisor 
 
5.2.4. INTERROMPENDO A COMUNICAÇÃO 
 
 Na abordagem mais simples o usuário sai abruptamente da aplicação cliente. O servidor 
encerrará a conexão antiga. 
Na abordagem mais completa são usados os dados “urgentes” (fora da banda). Pacotes 
TCP possuem no header o campo URG. O servidor ao receber um pacote com o campo URG 
setado é interrompido, através de um sinal. 
 
5.2.5. MANUTENÇÃO DE ESTADO 
 
 São três os estados: 
- Sem estado 
- Estado flexível 
- Com estado 
 
5.2.5.1. Servidores sem estado: 
 
Não mantém informações sobre os estados dos clientes e podem mudar seu próprio estado 
sem ter de informar a nenhum cliente, como por exemplo, o Servidor Web que, após processar 
uma requisição, esquece o cliente. Mesmo sem estado, servidor Web guarda informações de 
clientes. A perda não resulta na interrupção do serviço. 
SISTEMAS DISTRIBUÍDOS 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
11 
 
5.2.5.2. Servidores com estado flexível: 
 
 Servidor promete manter estado em nome do cliente, por um tempo limitado. Após o 
tempo limitado, o servidor descarta estas informações. Exemplo: Servidor promete manter um 
cliente informado sobre atualizações. 
 
5.2.5.3. Servidores com estado: 
 
 O servidor mantém as informações persistentes sobre seus clientes. As informações 
precisam ser explicitamente removidas pelo servidor. Exemplo: Servidor de arquivos que permite a 
um cliente manter cópia local de um arquivo. O servidor mantém uma tabela, com entradas 
(cliente, arquivo). Permite monitorar as permissões sobre um arquivo, etc. O problema aqui é a 
recuperação de Falhas. 
 
 
6. MIGRAÇÃO DE CÓDIGO 
 
Além a passagem de dados entre diferentes máquinas, em alguns casos é importante 
migrar códigode uma máquina para outra. A principal razão em se fazer a migração de código é 
obter um aumento de desempenho. 
 
6.1. Desempenho 
 
 O envio de processos de máquinas sobrecarregadas para máquinas com cargas mais leves 
evita grande quantidade de mensagens trocadas entre aplicações cliente-servidor. Exemplos: 
- Operações de banco de dados que envolvem uma grande quantidade de dados (aplicação 
cliente/servidor) 
- Formulários enviados do servidor para o cliente. 
 
6.2. Modelos para Migração de Código 
 
 A migração de código é algo muito mais amplo: podemos também migrar status de um 
programa, sinais pendentes e outras partes do ambiente. Um processo consiste em três 
segmentos: 
- Segmento de código: contém o conjunto de instruções que compõem o programa que 
está em execução. 
- Segmento de recursos: contém referências a recursos externos (arquivos, impressoras). 
-Segmento de execução: armazenar o estado em execução de um processo no momento 
da migração (dados privados, pilha, contador de programa). 
 
A mobilidade pode ser de dois tipos: 
- Mobilidade Fraca: possível transferir somente o segmento de código, junto com alguns 
dados de inicialização. Requer somente que a máquina-alvo possa executar o código 
(portabilidade). 
SISTEMAS DISTRIBUÍDOS 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
12 
 
- Mobilidade Forte: segmento de execução também pode ser transferido. O processo em 
execução pode ser parado e movido para uma outra máquina e retomar a execução no ponto 
original. 
Em relação do ponto de início da migração: 
- Iniciada pelo remetente: a migração é iniciada na máquina em que o código está em 
execução no momento em questão. Exemplo é enviar programa de busca pela Internet a um 
servidor de banco de dados para realização de pesquisas. 
- Iniciada pelo destinatário: Iniciativa da migração de código é tomada pela máquina-alvo. 
 
 
Figura 11 - Alternativas para migração de código 
 
6.3. Migração e Recursos Locais 
 
 Segmentos de recursos requerem uma atenção especial. Exemplo: A comunicação de um 
processo sendo feita através de uma porta TCP. Ao mudar de localização, este processo deverá 
devolver a porta e requisitar uma nova no destino. 
 Existem três tipos de vinculações do processo-recurso: 
- Vinculação por identificador: o processo requer exatamente o recurso referenciado (URL 
de um site). 
- Vinculação por valor: É necessário somente um valor. Se outro recurso fornece o mesmo 
valor, execução não é afetada (bibliotecas padronizadas) 
- Vinculação por tipo: Processo requer um recurso de um tipo específico (monitores, 
impressoras). 
 
Existem também três tipos de vinculações recurso-máquina: 
- Recursos não ligados: recursos podem ser movidos com facilidade entre maquinas 
diferentes (arquivos de dados). 
SISTEMAS DISTRIBUÍDOS 
Prof. Ricardo Rodrigues Barcelar 
http://www.ricardobarcelar.com.br 
 
 
13 
 
- Recursos amarrados: recursos podem ser movidos ou copiados, mas só a custo 
relativamente alto (banco de dados locais). 
- Recursos fixos: recursos estão intimamente vinculados a uma máquina ou ambiente 
especifico e não podem ser movidos (porta). 
- Referência global: Caso vários processos referenciem um recurso, uma alternativa é 
estabelecer uma referência global, que atravesse as fronteiras das máquinas. Exemplo: URL (baixa 
complexidade), Memória compartilhada entre processos (referência global significa memória 
compartilhada). 
Pode haver várias combinações entre vinculação processo-recurso e recurso-máquina. 
Exemplos: 
- Processo admite que a memória pode ser compartilhada entre processos (recurso fixo, 
vinculação de valor). 
- Bibliotecas de tempo de execução (recurso amarrado, vinculação de valor). 
 
A complexidade está ligada aos tipos de vínculo processo-recurso e recurso-máquina. 
- Recursos não ligados: Melhor solução é copiar ou mover o recurso para o novo destino. 
- Vinculações por tipo: A solução é vincular novamente o processo a um recurso do mesmo 
tipo disponível no local. 
 
6.4. Migração em Sistemas Heterogêneos 
 
A migração em sistemas heterogêneos requer segmento de código que possa ser 
executado em cada plataforma e um segmento de execução pode ser adequadamente 
representado em cada plataforma. O efeito global é migrar sistema operacional inteiro, em vez de 
migrar processos.