Transcript Processos (Clientes, Servidores e Migração)

Sistemas Distribuídos
Jorge Surian
[email protected]
Sistemas Distribuídos: Processos (Clientes, Servidores e Migração)
Processos
 Clientes (modelo Cliente-Servidor)
– Uma das tarefas mais importantes, atualmente, nas
máquinas clientes é proporcionar aos usuários meios
de interagir com servidores remotos.
– Primeiro Modo: 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.
Exemplo: Agenda remota compartilhada
2
2
Processos
 Clientes
– Segundo Modo: Fornecimento de uma interface de
usuário conveniente. Dessa maneira, a máquina
cliente é usada somente como um terminal sem
nenhuma necessidade de armazenamento.
Exemplo: Thin clients, nova (antiga...) tendência.
3
3
Processos
 Cliente - Um exemplo de cliente: Sistema X Windows
– Sistema X é baseado no modelo cliente-servidor.
» Servidor X é um programa que executa no sistema e é
responsável por todos os acessos ao hardware gráfico.
» Cliente se comunica com o servidor, enviando requisições
como 'desenhe uma linha' ou 'preste atenção na entrada do
teclado‘
» Solução pioneira, mas ainda muito usada pela adequação ao
modelo cliente servidor.
– Pode ser visto como parte de um sistema operacional
que controla o terminal.
4
4
Processos
 Cliente - Um exemplo de cliente: Sistema X Windows
– Cerne do sistema e formado pelo núcleo X, que
contém todos os drivers do dispositivo específicos do
terminal, usualmente fortemente dependente do
hardware.
– O núcleo X oferece uma interface de nível
relativamente baixo para controlar a tela e também
para capturar eventos do teclado e do mouse.
– Interface disponibilizada para as aplicações e definida
pela biblioteca Xlib.
5
5
Processos
 Cliente - Sistema X Window (modelo esquemático –
continuação exemplo)
6
6
Processos
 Cliente - Sistema X Window (continuação exemplo)
– Núcleo X e as aplicações X não precisam
necessariamente residir na mesma máquina
– X fornece o protocolo X, que é um protocolo de
comunicação de camada de aplicação pelo qual uma
instância de Xlib pode trocar dados e eventos com o
núcleo X. Por exemplo, Xlib pode enviar requisições
ao núcleo X para criar ou encerrar uma janela,
estabelecer cores e definir o tipo de cursor. O núcleo
X reagirá a eventos locais como entrada de teclado e
mouse devolvendo pacotes de eventos a Xlib.
– Núcleo X recebe requisições para manipular o visor
recebendo essas requisições de aplicações
geralmente remotas.
– Núcleo X age como um servidor, enquanto as
aplicações desempenham o papel de clientes.
7
7
Processos
 Cliente
– Clientes - Transparência de Distribuição
» 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.
» 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. Middleware no
cliente → oculta do usuário a corrente
localização do servidor.
8
8
Processos
 Cliente
– Clientes - Transparência de Distribuição
» Transparência a falha:
–Middleware cliente pode ser configurado para
tentar a conexão com um servidor repetidas
vezes, ou tentar um outro servidor depois de
fracassar determinado número de tentativas.
–Uso de cache: Uma falha na conexão com o
servidor é compensada pela exibição de dados
anteriormente armazenados no cache, como os
browsers Web podem fazer, por vezes gerando
inúmeros inconvenientes.
9
9
Processos
 Cliente
– Modelo Esquemático demonstrando situação onde
um cliente chama vários servidores, obtém várias
respostas e passa uma delas à aplicação cliente,
mantendo a transparência.
10
10
Processos
 Servidores
– Cada servidor, de maneira geral, é organizado do
mesmo modo:
» Espera por uma requisição de um cliente.
» Assegura o atendimento.
» Espera pela próxima requisição
– Questões de Projeto
»
»
»
»
Como tratar as requisições?
Como os clientes contatam um servidor?
Como interromper comunicação com o servidor?
Servidor deve guardar estado dos clientes?
11
11
Processos
 Servidores – Tratamento de Requisições
– Servidor Iterativo: Próprio servidor manipula a
requisição e, se necessário, retorna uma resposta ao
cliente
– Servidor Concorrente: Não manipula por si próprio a
requisição, como no Servidor multithread, onde
processos ou threads é que devolvem a resposta ao
cliente.
12
12
Processos
 Servidores – Forma de Organização
– Servidor Iterativo: Situação em que o próprio
servidor manipula a requisição e, se necessário,
retorna uma resposta ao cliente.
– Servidor Concorrente: Nessa situação o servidor
não manipula por si próprio a requisição. Os servidor
multithreads, são exemplos de servidores
concorrentes. Nos servidores concorrentes típicos do
ambiente Unix o processo ou threads que manipula a
requisição é também responsável por sua devolução
ao cliente.
13
13
Processos
 Servidores – Funcionamento
– Clientes enviam requisições a uma porta, na máquina
servidora.
– Para serviços conhecidos existem portas prédefinidas, por exemplo servidores que manipulam
requisições FTP na Internet, ouvem a porta TCP 21,
mas um servidor HTTP ouvirá sempre a porta 80.
– Para serviços que não requerem porta
prédeterminada, a opção mais usual é ter um daemon
(um programa executado automaticamente em um
computador a fim de executar um serviço para o
sistema operacional), fazendo com que o Cliente
acesse o daemon e o sistema operacional informará
dinamicamente uma porta livre.
14
14
Processos
 Servidores – Esquema de funcionamento
15
15
Processos
 Servidores e Superservidores
– Uma outra maneira de manipular portas é o uso de
superservidores, para se evitar desperdício de
recursos.
– Um caso típico é aquele onde muitos servidores ficam
esperando passivamente por uma requisição. Muitos
recursos seriam desperdiçados na monitoração
desses processos passivos.
– Se o monitoramento passar a ser realizado por um
superservidor à escuta em cada porta associada
com um serviço específico.
– Por exemplo, o daemom inetd no Unix ouve uma
quantidade de portas bem conhecidas para serviços
de internet. Quando chega uma requisição, o daemon
bifurca um processo para cuidar da requisição, que
será cancelado, findada a execução da requisição.
16
16
Processos
 Servidores – Superservidores – Esquema de Funcionamento
17
17
Processos
 Servidores – Como interromper um servidor?
Problema: O usuário resolve fazer um download de um
enorme arquivo para um servidor FTP. Repentinamente
descobre que o arquivo escolhido estava errado. O que
fazer para deter o processo?
Abordagem mais simples: usuário sai
abruptamente da aplicação cliente → servidor
encerrará a conexão antiga, em algum momento
admitindo falha do cliente.
18
18
Processos
 Servidores – Como interromper um servidor?
Abordagem mais completa: dados “urgentes” (fora
da banda) são enviados fazendo com que o servidor
possa inspecionar os dados e manipulá-los de
acordo com a necessidade, em acordo com o
esquema:
» Pacotes TCP possuem no header o campo URG.
» Servidor ao receber um pacote com o campo URG setado é
interrompido, através de um sinal.
» Servidor cancela o envio do arquivo errado.
19
19
Processos
 Servidores – Avaliação do Estado
– Os servidores podem estar num dos três estados
descritos: Sem, com ou flexível.
– Quando o servidor estiver sem estado, ele:
» Não mantém informações sobre os estados dos clientes.
» Pode mudar seu próprio estado sem ter que informar a nenhum
cliente.
» Por exemplo, servidor Web são sem estado, pois após processar
uma requisição, esquece o cliente.
» Mesmo sem estado, servidor Web guarda informações de clientes,
mas sua eventual perda não resulta na interrupção do serviço ou
numa falha. Simplesmente pode haver uma perda de desempenho.
20
20
Processos
 Servidores – Avaliação do Estado
– Quando o servidor estiver em estado flexível, ele:
» 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, mas depois de um determinado tempo o servidor
volta ao estado padrão (default) descartando quaisquer
informações que guardava em nome de um cliente associado.
21
21
Processos
 Servidores – Avaliação do Estado
– Quando o servidor estiver em com estado, ele:
» Mantém informações persistentes sobre seus clientes.
» Informações precisam ser explicitamente removidas pelo servidor.
22
22
Processos
 Servidores – Avaliação do Estado
– Quando o servidor estiver em com estado, ele:
Exemplo: Servidor de arquivos que permite a um cliente manter
cópia local de um arquivo. Servidor mantém uma tabela, com
entradas (cliente, arquivo). Permite monitorar as permissões sobre
um arquivo, etc.
» Vantagem: Desempenho percebido pelo cliente nas operações de
leitura e escrita.
» Problema: Recuperação de Falhas, pois o servidor tem que
recuperar sua tabela de entradas (cliente  arquivo), já que sem
isso deixará de garantir que processou as mais recentes
atualizações em um arquivo.
23
23
Processos
 Servidores – Clusters de Servidores
– Clusters de Servidores: Conjunto de máquinas
conectadas por uma rede, no qual cada máquina
executa um ou mais servidores. Essas máquinas
estão conectadas por uma rede local, com alta largura
de banda e baixa latência.
– Esquema geral de funcionamento de um cluster
de servidores (em três camadas)
24
24
Processos
 Servidores – Clusters de Servidores
– Comutador Lógico (1ª Camada)
» Forma o ponto de entrada para o cluster de servidores,
oferecendo um único endereço de rede.
» Considerando TCP, o comutador aceita requisições e as
transfere a um dos servidores.
» Identifica o melhor servidor a tratar a requisição.
25
25
Processos
 Servidores – Clusters de Servidores
– 2ª Camada
» Nos ambientes corporativos em geral as aplicações carecem
de máquinas de tecnologia relativamente baixa, porque a
capacidade de computação requerida não é o gargalo, mas
o acesso ao armazenamento. Assim, é possível e até
provável encontrarmos aplicações sendo executadas
diretamente na terceira ou na primeira camada, ou seja, o
ambiente se torna cliente-servidor “puro”.
26
26
Processos
 Servidores – Clusters de Servidores
– 3ª Camada
» Usualmente composta por servidores de processamento de
dados, especialmente servidores de arquivo e banco de
dados. Dependendo da utilização do cluster de servidores,
esses servidores podem executar em máquinas altamente
especializadas, configuradas para acesso de alta velocidade
a disco, normalmente com grandes caches do lado do
servidor.
» Esse modelo não é estanque. Pode ocorrer que máquinas
distintas ofereçam também diferentes servidores de
aplicação. Nessa situação cabe ao comutador distinguir
esses serviços, senão não será capaz de repassar as
requisições as máquinas adequadas.
27
27
Processos
 Servidores – Clusters de Servidores
– Por que migrar?
» Deve ser observado que a maioria das máquinas de
segunda camada executam apenas uma aplicação, até
porque aplicações diferentes tendem a ser gerenciadas por
administradores diferentes que preferem um não interferir
com o trabalho do outro.
» Nessa situação é usual que certas máquinas fiquem
temporariamente ociosas enquanto outras não.
» Algo útil seria migrar serviços temporariamente para
máquinas ociosas.
28
28
Processos
 Servidores – Cluster de Servidores
– Por que migrar?
» Analisando-se mais detalhadamente a primeira camada, mais
especificamente o comutador, podemos chegar a algumas
conclusões:
1. É fundamental num projeto de cluster de servidores que há de
fato vários servidores.
2. Nenhuma máquina cliente precisa saber nada da organização
do cluster.
3. A transparência de acesso é oferecida a partir de um único
ponto de acesso, portanto cada ponto de acesso é realizado
por uma máquina separada.
29
29
Processos
 Servidores – Cluster de Servidores
– Por que migrar?
4. Um modo padrão de acessar um cluster de servidores é
através de uma conexão TCP pela qual as requisições de
nível de aplicação sejam enviadas como parte de uma
sessão, que termina com o encerramento da conexão.
5. Um comutador de camada de transporte aceita requisições
de conexão TCP que entram e transferem tais conexões a um
dos servidores.
30
30
Processos
 Servidores – Cluster de Servidores
– Por que migrar?
6. Esse princípio, conhecido como TCP handoff é baseado no
fato do comutador identificar o melhor servidor para manipular
aquela requisição repassando-a a esse servidor que enviará um
reconhecimento diretamente o cliente requisitante, mas insere o
endereço IP do comutador como endereço de fonte no
cabeçalho do pacote IP que está transportando esse segmento
TCP.
7. Esse processo de falsificação, conhecido como spoofing, é
necessário para que o cliente continue executando o protocolo
TCP, pois ele está esperando uma mensagem de voltado do
comutador e não de um servidor do qual nunca ouviu falar...
31
31
Processos
 Servidores – Cluster de Servidores
– Princípio da transferência de IP
32
32
Processos
 Servidores – Cluster de Servidores Distribuídos
– Conjunto de máquinas que possivelmente muda
dinamicamente, com vários pontos de acesso
também possivelmente variáveis, mas se apresenta
ao mundo externo como um única e poderosa
máquina.
– Características:
» Vários pontos de acesso
» Estabilidade no acesso
 Alto desempenho
» Flexibilidade
33
33
Processos
 Migração de Código
– Somente será abordada a passagem de dados entre
diferentes máquinas.
– Observe-se que em alguns casos é importante migrar
código de uma máquina para outra.
– Mas... Por que migrar código?
Melhorar Desempenho!
34
34
Processos
 Migração de Código
– Como fazer esta tarefa em sistemas heterogêneos?
» Envio de processos de máquinas sobrecarregadas para
máquinas com cargas mais leves.
» Evitar grande quantidade de mensagens trocadas entre
aplicações cliente-servidor:
– Exemplo 1: Operações de banco de dados que
envolvem uma grande quantidade de dados(aplicação
cliente → servidor).
– Exemplo 2: Formulários enviados do
servidor → cliente.
35
35
Processos
 Migração de Código - Modelos para Migração de
Código
– Migração de código é algo muito amplo: podemos
também migrar status de um programa, sinais
pendentes e outras partes do ambiente.
– Processo consiste em três segmentos:
1. Segmento de código: contém o conjunto de instruções
que compõem o programa que está em execução.
2. Segmento de recursos: contém referências a recursos
externos (arquivos, impressoras).
3. Segmento de execução: armazenar o estado em
execução de um processo no momento da migração (dados
privados, pilha,contador de programa)
36
36
Processos
 Migração de Código - Modelos para Migração de
Código
– Mobilidade pode ser de dois tipos:
1. 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).
2. 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.
37
37
Processos
 Migração de Código
– 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.
38
38
Processos
 Migração e Recursos Locais
– Segmentos de recursos requerem uma atenção
especial
Exemplo: 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.
39
39
Processos
 Migração e Recursos Locais
– Três tipos de vinculações processo-recurso:
» Vinculação por identificador
• 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).
40
40
Processos
 Migração e Recursos Locais
– 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).
» 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).
41
41
Processos
 Migração e Recursos Locais
– Referência global
» Caso vários processos referenciem um recurso, uma
alternativa é estabelecer uma referência global, que
atravesse as fronteiras das máquinas.
» URL (baixa complexidade).
» Memória compartilhada entre processos (referência global
significa memória compartilhada).
42
42
Processos
 Migração e Recursos Locais
– Várias combinações entre vinculação processorecurso e recurso-máquina.
» Exemplo 1: Processo admite que a memória pode ser
compartilhada entre processos (recurso fixo,vinculação de
valor).
» Exemplo 2:Bibliotecas de tempo de execução (recurso
amarrado, vinculação de valor).
43
43
Processos
 Migração e Recursos Locais
– Complexidade está ligada aos tipos de vínculo
processo-recurso e recurso-máquina.
» Recursos não ligados: A 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.
44
44
Processos
 Migração em Sistemas Heterogêneos
– Requisitos:
» Segmento de código possa ser executado em cada
plataforma.
» Segmento de execução pode ser adequadamente
representado em cada plataforma.
» Efeito global: Migrar sistema operacional inteiro, em vez de
migrar processos.
45
45
Fonte:
Tanenbaum, Andrew S. e Steen, Marteen Van. Sistemas Distribuídos, São
Paulo: Prentice Hall, 2008.
Copyright © 2010 Prof. Jorge Surian
Todos direitos reservados. Reprodução ou divulgação total ou parcial deste documento é
expressamente proíbido sem o consentimento formal, por escrito, do Professor Surian.
46
46