Cap. 03 – Processos
3.1 – Threads
3.1.1 Introdução às Threads
3.1.2 Threads em Sistemas Distribuídos
3.2 – Virtualização
3.2.1 Virtualização em Sistemas Distribuídos 3.2.2 Arquiteturas de Máquinas Virtuais
3.3 – Clientes
3.3.1 Interface do Usuário
Cap. 03 – Processos
3.3 - … …
3.4 – Servidores
3.4.1 Aspectos Gerais de Projeto 3.4.2 Clusters de Servidores
3.4.4 Gerenciamento de Clusters de Servidores
3.5 – Migração de Código
3.5.1 Abordagens para Migração de Código 3.5.2 Migração e Recursos Locais
Referências Bibliográficas
● Andrew S. Tanenbaum; Maarten van Steen - Distributed Systems: Principles and Paradigms, Prentice-Hall, 2007, ISBN-10:
0132392275, ISBN-13: 9780132392273
… Lectures dos autores Andrew S. Tanenbaum e Maarteen van Steen (“www.cs.vu.nl” e “www.distributed-systems.net/”)
● George Coulouris; Jean Dollimore; Tim Kindberg – Sistemas Distribuídos: Conceitos e Projeto, Bookman, 4th Edition, 2007, ISBN 9788560031498
Cap. 03 Processos – Introdução
Introdução
● “problema” - como diferentes tipos de processos desempenham
um papel crucial em sistemas distribuídos ?!
● … da perspectiva de sistemas operacionais, o gerenciamento e
escalonamento de processos é o aspecto mais importante para tratar … mas ao discutirmos este tópico em sistemas distribuídos estes aspectos e outros igualmente importantes emergem.
● … threads em sistemas distribuídos – permite que a comuni-
cação e processamento de clientes e servidores sejam sobre- postos, resultando em alto grau de performance.
● … virtualização – permite que uma aplicação e, possivelmente o
seu ambiente incluindo o sistema operacional, sejam executados concorrentemente com outra aplicação e de forma totalmente
3 Processos – 3.1 Threads
3.1 – Threads
● “processo” – … bloco base para sistemas distribuídos, por outro
lado a experiência mostra que a granularidade processo suportada pelos sistemas operacionais não é suficiente;
● … se um nível de granularidade mais fino (e.g., threads) for
contemplado, o desenvolvimento de aplicações distribuídas atinge níveis melhores de performance;
3 Processos – 3.1 Threads
3.1.1 – Introdução às Threads
● “processo” – programa em execução, ou seja, é um programa
que está sendo correntemente executado por um processador virtual do sistema operacional;
● … daí a necessidade do sistema operacional criar processadores
virtuais, cada qual para executar diferentes programas;
● … para rastrear estes processadores virtuais, o sistema
operacional mantém a Tabela de Processos contendo entradas para registradores do processador, mapa de memória, arquivos abertos, informações para bilhetagem, privilégios, etc.
● … fato de múltiplos processos compartilharem concorrentemente
3 Processos – 3.1 Threads
… 3.1.1 – Introdução às Threads
● Threads – … como um processo, a thread executa sobre o seu
código e independentemente de outras threads;
● … entretanto, em contraste com processos, nenhum esforço é
feito para prover transparência de concorrência.
● Implicações da abordagem de Múltiplas Threads:
● performance de aplicações multithreaded não necessita ser pior que as
aplicações “single threaded” - alias, em muitos casos “multithreaded” leva a ganho de performance;
● “threads” não são protegidas umas das outras, assim, esforço adicional
3 Processos – 3.1 Threads
… 3.1.1 – Introdução às Threads
● Antes de discutirmos o papel das threads em Sistemas Distribuí-
dos, vejamos o seu uso em Sistemas Tradicionais:
● … em sistema com uma única thread por processo, o processo será
inteiramente bloqueado sempre que o bloqueio de uma chamada de sistema for executado, logo, sistemas “multithreaded” podem contornar este problema disparando um outra thread;
● … uma outra vantagem do suporte a múltiplas threads é o fato de
podermos explorar o paralelismo quando executando um programa em sistemas multiprocessados;
● … sistemas “multithreaded” são também úteis no contexto de grandes
3 Processos – 3.1 Threads
… 3.1.1 – Introdução às Threads
● “multithreaded systems” - esta abordagem é típica em Ambiente
3 Processos – 3.1 Threads
… 3.1.1 – Introdução às Threads
● … pelo fato do IPC requerer intervenção do “kernel”, um processo
irá geralmente efetuar mudança de modo de execução (“user mode” para “kernel mode”) => mudança do mapa de memória (MMU) bem como decarga de dados da TLB.
● Finalmente, uma boa razão em Engenharia de Software para usar
3 Processos – 3.1 Threads
… 3.1.1 – Introdução às Threads
● “Thread Implementation” – há duas abordagens: “User Level
Threads” (ULT) e “Kernel Level Threads” (KLT).
● “User Level Threads” – executada inteiramente no modo usuário.
● todas as operações são executadas inteiramente no modo usuário =>
implementações podem ser extremamente eficientes;
● serviços providos pelo “kernel” em nome do processo que suporta a
“thread” => se o “kernel” bloquear a “thread” => processo é bloqueado;
● “threads” são utilizadas quando há muitos eventos externos (bloqueio de
3 Processos – 3.1 Threads
… 3.1.1 – Introdução às Threads
● “Kernel Level Threads” – executada inteiramente no modo kernel,
ou seja, todas as operações se comportam como “system calls”
● operações que bloqueiam a thread não mais são um problema – kernel
dispara um outra thread para atender o mesmo processo;
● tratamento de eventos externos – kernel, responsável por tratar todos os
eventos, escalona a thread associada ao evento;
● problema é (pode ser) a perda de eficiência – toda operação de thread
requer interrupção (trap) do kernel.
● Solução: união dos dois conceitos, normalmente referenciado
como “lightweight processes” (LWP).
● significado tradicional (Unix System V / Solaris) – executa no espaço do
3 Processos – 3.1 Threads
… 3.1.1 – Introdução às Threads
● Thread Implementation – há duas abordagens: “User Level
3 Processos – 3.1 Threads
3.1.2 – Threads e Sistemas Distribuídos
● Threads - possibilitam o bloqueio da chamada de sistema sem o
efetivo bloqueio de todo o processo que as suporta.
● … esta propriedade torna as “threads” particularmente atrativas
em sistemas distribuídos por tornar mais simples a comunicação;
● … ou seja, threads possibilitam a manutenção de múltiplas
conexões lógicas ao mesmo tempo (e.g., clientes “multithreaded”, servidores “multithreaded”).
3 Processos – 3.1 Threads
… 3.1.2 – Threads e Sistemas Distribuídos
● “Multithreaded Clients” – para proporcionar alto grau de
transparência, sistemas distribuídos que operam em redes amplas, devem esconder a demora na troca de mensagens;
● … modo usual para esconder a latência de comunicação é executar outras
tarefas logo após iniciar uma comunicação (e.g., troca de mensagens).
● e.g., Cliente Web – arquivos podem ser descarregados através de
várias threads, cada uma executando uma requisição “http” ...
3 Processos – 3.1 Threads
… 3.1.2 – Threads e Sistemas Distribuídos
● Multiple Request/Response Calls – cliente invoca várias
chamadas simultaneamente através de várias threads;
● … na sequência, aguarda pelos resultados.
● … se as chamadas forem atendidas por diferentes servidores, o
tempo para “download” é bem menor – por outro lado, exige suporte do cliente ao paralelismo real de fluxos (“streams”).
● … alternativas para melhorar a performance:
● thread – mais barato que criar um processo;
● servidores com múltiplas threads – tiram proveito dos multiprocessadores;
● escondendo a latência da rede – atender a uma nova requisição enquanto
3 Processos – 3.1 Threads
… 3.1.2 – Threads e Sistemas Distribuídos
● “Multithreaded Servers” - … não somente simplifica o código,
3 Processos – 3.1 Threads
… 3.1.2 – Threads e Sistemas Distribuídos
● e.g., considere um servidor de arquivo que ocasionalmente é
bloqueado para esperar pelo disco (operação de I/O);
● … dois projetos/abordagens são possíveis:
● servidor de arquivo “multithreaded”; ● servidor de arquivo “single threaded”.
● … que análise você faz destas abordagens ?! … que vantagens e
desvantagens há em cada uma das abordagens ?!
● Há alguma outra abordagem ?! … executar o servidor de arquivo
3 Processos – 3.1 Threads
… 3.1.2 – Threads e Sistemas Distribuídos
● Máquina de Estado Finito (Finite State Machine - FSM) – nesta
abordagem o servidor utiliza chamadas não bloqueantes para enviar e receber (replay/send), ou seja, …
● … para toda mensagem enviada/recebida (replay/request) o
3 Processos – 3.1 Threads
… 3.1.2 – Threads e Sistemas Distribuídos
● Qual a melhor estrutura ?
● … em servidores com altas demandas de entrada/saída, utiliza-se
simplesmente chamadas bloqueantes pois a estrutura dos servidores pode ser simplificada;
● … programas com suporte a múltiplas threads tendem a ser
3 Processos – 3.2 Virtualização
3.2 – Virtualização
● Processos e Threads possibilitam a concepção de programas que
se comportam como se fossem executados simultaneamente, ou seja, se rapidamente chaveados cria-se a ilusão do paralelismo.
● “resource virtualization” - camada de abstração entre o “hardware”
(processador, memória, disco, conexão, etc.) e a camada logo acima que consome estes recursos (e.g., aplicações).
● … objetivo é prover a separação do que é real e de fato está
3 Processos – 3.2 Virtualização
3.2.1 – Virtualização em Sistemas Distribuídos
● Na prática, todo sistema computacional (distribuído) disponibiliza
uma interface de programação no nível mais alto (Fig. a) …
● … em essência, virtualização estende ou substitui a interface tal
3 Processos – 3.2 Virtualização
… 3.2.1 – Virtualização em Sistemas Distribuídos
● 1970s - introdução da virtualização foi uma necessidade de
executar sistemas legados em “hardware” de “mainframes”;
● … software não incluia somente aplicações, mas de fato o próprio
sistema operacional para o qual o software foi projetado.
● Nas décadas seguintes, o cenário mudou em razão:
● hardware tornou-se mais barato;
● computadores com maior suporte computacional;
● nro de sistemas operacionais diminuiu;
3 Processos – 3.2 Virtualização
… 3.2.1 – Virtualização em Sistemas Distribuídos
● 1990s - … cenário no qual a virtualização é retomada.
● … enquanto hardware e software de camadas mais baixas
mudam razoavelmente rápido, software em camadas de alto nível de abstração são mais estáveis;
● … ou seja, software legados não mais podem ser mantidos no
mesmo passo das plataformas para as quais foram construídos.
● Papel da Virtualização – auxilia na portabilidade de interfaces
legadas para a nova plataforma bem como dá abertura para uma grande classe de aplicações correntes.
● Virtualização – oferece suporte a uma diversidade de plataformas
3 Processos – 3.2 Virtualização
3.2.2 – Arquiteturas de Máquinas Virtuais
● Virtualização pode ocorrer em diferentes níveis, mas é fortemente
dependente das interfaces disponibilizadas pelos componentes;
● … geralmente, um sistema computacional disponibiliza quatro
3 Processos – 3.2 Virtualização
… 3.2.2 – Arquiteturas de Máquinas Virtuais
● “machine instructions” - interface entre hardware e software
consistindo de instruções de máquina que podem ser invocadas por qualquer programa;
● “privileged machine instructions” - interface entre hardware e
software consistindo de instruções de máquinas que podem ser invocadas por programas com privilégio;
● “system calls” - interface entre sistema operacional e aplicação
consistindo de chamadas de sistema do sist. operacional;
● “library calls” - interface que consiste de chamadas de
3 Processos – 3.2 Virtualização
… 3.2.2 – Arquiteturas de Máquinas Virtuais
● Essência da Virtualização – imitar o comportamento das interfa-
ces, independente de onde estejam na arquitura de software.
● ... virtualização vem se tornando incrivelmente importante no que
tange a confiabilidade e segurança em sistemas distribuídos, ...
● justificativa - possibilitam a isolação completa da aplicação e do
seu ambiente, assim, uma falha causada por um erro ou por um ataque não irá afetar a máquina como um todo.
● Abordagens para prover Virtualização:
3 Processos – 3.2 Virtualização
… 3.2.2 – Arquiteturas de Máquinas Virtuais
● “Process Virtual Machine” - sistema que essencialmente provê
um conjunto de instruções abstrato (e.g., inst. interpretadas ou emuladas) utilizado para executar aplicações.
3 Processos – 3.2 Virtualização
… 3.2.2 – Arquiteturas de Máquinas Virtuais
● “Virtual Machine Monitor” - sistema implementado com uma
camada que blinda o hardware original, mas oferece o conjunto completo de instruções do hardware como uma interface.
3 Processos – 3.3 Clientes
3.3 – Clientes
● Discutimos nas seções prévias o Modelo Cliente/Servidor, seus
papéis e como interagem um com o outro.
● … na sequência, discutiremos a anatomia do Cliente e na próxima
3 Processos – 3.3 Clientes
3.3.1 – Interface do Usuário
● Máquina Cliente – tem como principal função oferecer os meios
pelos quais usuários interagem como servidores remotos;
● … grosseiramente, há duas abordagens através das quais estas
interações são suportadas:
3 Processos – 3.3 Clientes
… 3.3.1 – Interface do Usuário
● “Networked Application with its own Protocol” - para cada
serviço remoto, o cliente contempla em separado um componente que contacta o serviço remoto através da rede;
3 Processos – 3.3 Clientes
… 3.3.1 – Interface do Usuário
● e.g., Agenda em um PDA “Personal Digital Assistant” de Usuário
que deseja sincronizar seus dados em um repositório remoto;
● ... neste caso um protocolo no nível de aplicação irá manipular a
3 Processos – 3.3 Clientes
… 3.3.1 – Interface do Usuário
● “General Solution to allow Access” - acesso direto aos serviços
remotos através de interfaces convenientes de usuário.
● ... máquina cliente não tem necessidade de armazenar e nem
mesmo manter um protocolo dependente da aplicação;
● ... esta abordagem (“thin-client approach”) vem recebendo mais
3 Processos – 3.3 Clientes
… 3.3.1 – Interface do Usuário
● “General Solution to allow Access” - acesso direto aos serviços
remotos através de interfaces de usuário convenientes.
3 Processos – 3.3 Clientes
… 3.3.1 – Interface do Usuário
● “X Window System” - utilizado para controlar terminais
mapeados por “bit”, tais como: monitor, teclado e “mouse”;
● … pode ser vista como parte do sistema operacional que controla
3 Processos – 3.3 Clientes
… 3.3.1 – Interface do Usuário
● “X Window System” - aspecto interessante é o de que “X Kernel”
e Aplicações X não necessariamente residem na mesma máquina;
● … X Kernel – contém todos os “drivers” para terminanis especí-
ficos e, normalmente, é altamente dependente do hardware.
● … X Protocol – protocolo de comunicação no nível de aplicação
pelo qual uma instância Xlib pode trocar dados e eventos com “X Kernel”, ou seja, “X Kernel” reage aos eventos de teclado ou
mouse enviando pacotes de evento para o Xlib.
● Várias aplicações podem se comunicar ao mesmo tempo com o
3 Processos – 3.3 Clientes
3.3.2 – Lado Cliente para Trans. de Distribuição
● Em muitos casos, o software Cliente contempla mais do que
apenas Interface de Usuário, p.ex., parte do nível de dados e de processamento podem ser executados no lado cliente;
● ... nestes casos a interface do usuário é relativamente pequena
em contraste com o processamento e comunicação.
● … além da interface do usuário e software relacionado à aplica-
ção, o lado cliente compreende componentes para oferecer transparência de distribuição.
● … idealmente, um cliente não deveria estar ciente que está se
comunicando com um processo remoto;
● … já em servidores, a distribuição é frequentemente menos
3 Processos – 3.3 Clientes
… 3.3.2 – Lado Cliente para Trans. de Distribuição
● transparência de acesso – geralmente contemplada através da
geração de um apêndice no cliente a partir da interface do servidor, ou seja, da definição do que o servidor irá oferecer.
● ... o apêndice (“stub”) disponibiliza a mesma interface disponível
no servidor, mas esconde as possíveis diferenças de arquitetura de máquina bem como de comunicação;
● transparência de acesso – geração de um apêndice do lado
3 Processos – 3.3 Clientes
… 3.3.2 – Lado Cliente para Trans. de Distribuição
● transparência de localização e migração – permitir que o lado
cliente do software possa rastrear a localização do servidor;
● ... nestes casos é crucial a utilização de um conveniente sistema
3 Processos – 3.3 Clientes
… 3.3.2 – Lado Cliente para Trans. de Distribuição
● transparência de replicação – múltiplas invocações podem ser
tratadas pelo apêndice (“stub”) no cliente.
● ... lado cliente coleta de forma transparente todas as respostas e
3 Processos – 3.3 Clientes
… 3.3.2 – Lado Cliente para Trans. de Distribuição
● transparência de falha – mascarar falhas de comunicação e de
servidor através do “middleware” do cliente.
● ... “middleware” do cliente pode ser configurado para repetida-
mente reestabelecer a conexão com o servidor, ou talvez, tentar um outro servidor após “n” tentativas.
● transparência de concorrência – pode ser tratada através de
servidores especiais intermediários especiais – monitores de transações – o que requer menor suporte do cliente.
● transparência de persistência – frequentemente tratada inteira-
3 Processos – 3.4 Servidores
3.4 – Servidores
● servidor – processo que implementa serviço(s) específico(s) em
nome de um coleção de clientes e normalmente são organizados de modo que aguarda requisição(ões) do(s) cliente(s).
● ... em essência o servidor aguarda a requisição de um cliente e
na sequência garante que a mesma seja atendida, para em seguida esperar/aguardar pela próxima requisição;
● ... para estabelecer a comunicação, clientes enviam requisições
para um “end point” - (também chamado “port”) na máquina onde o processo servidor está executando.
3 Processos – 3.4 Servidores
3.4.1 – Aspectos Gerais de Projeto
● Classificação/Categorização dos Servidores:
● “interactive servers” - próprio servidor trata a requisição e, se
necessário, retorna a resposta para o cliente que requisitou;
● “concurrent servers” - não manipula diretamentea a requisição,
mas a repassa para um outro processo/thread;
● processo/thread passa o ser o responsável por responder e, na sequência,
servidor fica a espera da próxima requisição;
● e.g., servidor com suporte para múltiplas threads ou processos,
onde um processo é instanciado para atender a requisição.
● e.g., Sistema UNIX – thread ou processo que trata a requisição é
3 Processos – 3.4 Servidores
… 3.4.1 – Aspectos Gerais de Projeto
● Como um Cliente contacta um Servidor ?!
● … normalmente clientes enviam requisições para “end points” ou “ports”
que, normalmente estão associados a serviços bem conhecidos.
● ftp-data 20 File Transfer [Default Data]
● ftp 21 File Transfer Control
● telnet 23 Telnet
● … 24 any private mail service
● smtp 25 Simple Mail Transfer
● login 49 Login Host Protocol
3 Processos – 3.4 Servidores
… 3.4.1 – Aspectos Gerais de Projeto
● … “daemon” mantém informações do “end point” corrente para
cada serviço implementado pelo servidor local;
● … cliente inicialmente contacta o “daemon” para requerer o “end
3 Processos – 3.4 Servidores
… 3.4.1 – Aspectos Gerais de Projeto
● ... “daemon” mantém informações do “end point” corrente para
cada serviço implementado pelo servidor local;
● ... neste contexto, implementar cada serviço por um servidor em separado
(processo em separado) representa alto custo de recursos;
● ... outro cenário semelhante é o de vários servidores executando
simultaneamente, muitos deles esperando por uma requisição;
● ... em ambos os casos, é mais eficiente manter um único servidor
(possivelmente maior em capacidade - “superserver”) ouvindo cada um dos “end points” associados a cada um dos serviços;
● e.g., “inetd” (Internet Service Daemon) – é um “superserver
3 Processos – 3.4 Servidores
… 3.4.1 – Aspectos Gerais de Projeto
● “superservers” - servidores que ouvem em diversas portas, ou
seja, oferece vários serviços independentes;
● … é mais eficiente ter um único “superserver” ouvindo cada “end
3 Processos – 3.4 Servidores
… 3.4.1 – Aspectos Gerais de Projeto
● “superservers” - servidores que ouvem em diversas portas, ou
seja, oferece vários serviços independentes;
● e.g., “inetd” (Internet Service Daemon) – é um “superserver
daemom” em Sistemas UNIX responsável por gerenciar serviços Internet tais como: FTP, POP3 e Telnet.
● ... assim quando um segmento TCP ou UDP chega para uma
porta destino em particular, “inetd” instancia o servidor apropriado para tratar a conexão em curso;
● vantagem - para serviços que não espera que sejam executados
3 Processos – 3.4 Servidores
… 3.4.1 – Aspectos Gerais de Projeto
● Aspecto de Projeto – Interrupção de Servidor: e.g., como
interromper o “download” de arquivo grande de um Servidor FTP ?! ... finalizar abruptamente a aplicação ?!
● “out-of-band data” - permite o tratamento de interrupções na
comunicação, ou seja, dados “out-of-band” serão tratados pelo servidor antes de algum outro dado do cliente.
● “stateless server” - não mantém informação de estado dos seus
clientes e pode alterar o seu próprio estado sem necessidade de informar a qualquer cliente que houve mudanças.
● e.g., Servidor Web é um bom exemplo de servidor sem estado,
3 Processos – 3.4 Servidores
… 3.4.1 – Aspectos Gerais de Projeto
● ... uma forma particular de projeto “stateless” é quando o servidor
mantém o que é conhecido como “soft state” - mantém-se estado em favor de um cliente, mas por um tempo limitado.
● “stateful servers” - em contraste com os servidores “stateless”,
estes últimos geralmente mantém as informações por longos períodos, ou seja, as informações são persistentes.
● e.g., imagine um servidor de arquivo que permite ao cliente
manter a cópia local de um arquivo por razões de desempenho.
● Obs.: melhoria de performance sobre servidores “stateless” é fre-
3 Processos – 3.4 Servidores
… 3.4.1 – Aspectos Gerais de Projeto
● e.g., imagine um servidor de arquivo que permite ao cliente man-
ter a cópia local de um arquivo, até mesmo para desempenho de operações de atualização.
● ... esta abordagem pode melhorar o desempenho de operações
de leitura/escrita como percebido pelo cliente;
● ... este servidor poderá manter uma tabela com entradas para
“client, file” de modo a rastrear que cliente tem permissão de atualização sobre qual arquivo;
● ... se o servidor sofre alguma pane, o mesmo terá que recuperar
a tabela de “cliente, file” ou, diferentemente, não poderá garantir que as mais recentes atualizações de um dado arquivo;
3 Processos – 3.4 Servidores
3.4.2 Clusters de Servidores
● “server cluster” - coleção de máquinas conectadas através de
uma rede, onde cada máquina executa um ou mais servidores.
● … os clusters de servidores que iremos considerar aqui são
aqueles cujas máquinas estão interconectadas por uma LAN;
● … normalmente, clusters de servidores estão organizados em 03
camadas como qualquer arquitetura multicamadas.
● e.g., … muitos clusters de servidores contém servidores
3 Processos – 3.4 Servidores – 3.4.2 Clusters de Servidores
…
Organização Geral
● “server cluster” - logicamente organizados em três camadas:
3 Processos – 3.4 Servidores – 3.4.2 Clusters de Servidores
…
Organização Geral
● ... no entanto, nem todos os clusters de servidores seguem esta
separação estrita (03 camadas): “logical switch”; “application servers” e “database system”.
● e.g., fluxo de mídia por meio de cluster de servidores
normalmente acomoda arquitetura em duas camadas, pois cada máquina se comporta como um servidor dedicado de mídia.
● e.g., quando um cluster de servidores oferece muitos serviços,
pode acontecer que diferentes máquinas executem diferentes
3 Processos – 3.4 Servidores – 3.4.2 Clusters de Servidores
…
Organização Geral
● aspecto de projeto de cluster de servidores – esconder o fato
de que há múltiplos servidores, ou seja, aplicações cliente não precisam conhecer nada acerca da organização do cluster.
● … se considerarmos aspectos como escalabilidade e disponibi-
lidade, um cluster de servidores deve contemplar muitos pontos de acesso, com cada ponto de acesso implementado por uma máquina dedicada e em separado;
● … um modo padrão de acessar um cluster de servidores é esta-
3 Processos – 3.4 Servidores – 3.4.2 Clusters de Servidores
…
Organização Geral
● TCP handoff – mecanismo de repasse de responsabilidade no
qual um servidor que recebe uma solicitação de conexão a repassa para uma de suas réplicas;
● … cabe a esta máquina o dever de responder ao solicitante da
3 Processos – 3.4 Servidores – 3.4.2 Clusters de Servidores
…
Organização Geral
● TCP “handoff” - “as it is based on passing the duty of servicing
3. Processos – 3.4 Servidores – 3.4.2 Clusters de Servidores
Servidores Distribuídos
● Como discutido anteriormente, quando cluster de servidores
disponibilizam um único ponto de acesso, esconde-se do cliente como o mesmo está organizado (vantagem);
● ... mas por outro, se este ponto de acesso falha, o cluster
torna-se indisponível (desvantagem);
● Este problema pode ser eliminado oferendo vários pontos de
acesso bem como os seus respectivos endereços;
● ... e.g., DNS (Domain Name System) pode retornar vários
endereços, todos pertencentes ao mesmo “host”.
● ... ainda assim, nesta abordagem, será necessário novas
3. Processos – 3.4 Servidores – 3.4.2 Clusters de Servidores
… Servidores Distribuídos
● O que pode ser melhorado ? – adição de estabilidade e
flexibilidade neste caso tanto pelo cliente quanto pelo servidor;
● estabilidade – manutenção do ponto de acesso por um longo período;
● flexibilidade – flexibilidade na configuração do cluster de servidores.
● “servidor distribuído” - nada mais do que um conjunto dinâmico
de máquinas, como pontos de acesso que podem variar mas que aparecem para o mundo exterior como um máquina única.
● ... clientes podem se beneficiar deste modelo em razão da
estabilidade, robustez e alto desempenho do servidor.
● ... vamos nos concentrar como um ponto de acesso estável pode
3. Processos – 3.4 Servidores – 3.4.2 Clusters de Servidores
… Servidores Distribuídos
● resposta - podemos utilizar serviços de rede disponíveis como a
suporte a mobilidade no IPv6;
● ... um nó móvel está associado a rede nativa (“home network”) e
da qual recebeu um endereço estável (“home address” - HoA);
● ... a rede nativa (“home network”) tem um roteador conhecido por
“home agent” - responsável pelo tráfego para o nó móvel (“mobile node”) quando o mesmo está fora da rede nativa;
● ... quando um nó móvel se associa a rede que está visitando
3. Processos – 3.4 Servidores – 3.4.2 Clusters de Servidores
… Servidores Distribuídos
● Este princípio pode ser usado para oferecer um endereço estável
3. Processos – 3.5 Migração de Código
3.5 – Migração de Código
● Até agora, discutimos sistemas distribuídos nos quais a comuni-
cação está limitada a troca de dados;
● ... entretanto, há situações onde a troca de programas, ainda que estejam
sendo executados, pode simplificar o projeto dos sistema distribuído.
● Iniciaremos nossa discussão apresentado as diferentes formas
3. Processos – 3.5 Migração de Código
3.5.1 – Abordagens para Migração de Código
● Tradicionalmente, migração em sistemas distribuídos ocorre na
forma de migração de código – processo é completamente movido de um máquina para outra.
● ... trata-se de uma tarefa complexa e cara que normalmente exige
uma justificativa plausível para que seja realizada.
● motivação – desempenho de todo o sistema pode melhorar se
movermos processos de máquinas com alta carga de processa- mento para máquinas com baixa carga;
● ... assim fazem-se necessários algoritmos de distribuição de carga
3. Processos – 3.5 Migração de Código
… 3.5.1 – Abordagens para Migração de Código
● e.g., sistema cliente/servidor no qual servidores manipulam um
banco de dados com grande volume de dados;
● ... se o cliente precisa realizar muitas operações sobre o banco de
dados que involve um grande volume de dados, talvez seja melhor deslocar parte do cliente para o servidor;
● ... neste caso, a migração de código se baseia na suposição que
faz sentido processar os dados perto de onde os dados estão.
● Raciocínio análogo pode ser estabelecido para justificar a
migração de partes do servidor para o cliente.
● e.g., ... em aplicações interativas de banco de dados há a neces-
3. Processos – 3.5 Migração de Código
… 3.5.1 – Abordagens para Migração de Código
● Suporte à Migração de Código podem também melhorar o
desempenho explorando o paralelismo, mas sem os meandros relacionadas a programação paralela.
● ... mas além do desempenho, há outras razões para suportar a
migração de código – flexibilidade !!
● e.g., considerando que uma aplicação distribuída consiste em
3. Processos – 3.5 Migração de Código
… 3.5.1 – Abordagens para Migração de Código
● ... princípio de configuração dinâmica de um cliente para que
3. Processos – 3.5 Migração de Código
… 3.5.1 – Abordagens para Migração de Código
● vantagem deste modelo – cliente não necessita que todo o
software se encontre pré-instalado para invocar o servidor;
● ... por outro lado, é necessário que o protocolo de descarga e de
inicialização de código seja padronizado.
● Vantagem Adicional – tão logo um dada interface seja disponibi-
3. Processos – 3.5 Migração de Código
… 3.5.1 – Abordagens para Migração de Código
● Modelos para Migração de Código (Fuggetta et al. - 1998) –
estabelece que um processo é composto de três segmentos:
● código – conjunto de instruções que compõem o processo;
● recursos – recursos externos necessários ao processo;
● execução – estado corrente de execução (dados privados, stack, etc.)
● Neste contexto podemos então caracterizar:
● “weak mobility” - move-se código e recursos (reboot execution); ● “strong mobility” - move-se os três segmentos (código, recursos e
3. Processos – 3.5 Migração de Código
… 3.5.1 – Abordagens para Migração de Código
3. Processos – 3.5 Migração de Código
… 3.5.1 – Abordagens para Migração de Código
● “sender-initiated” - migração é iniciada na máquina onde o
código reside atualmente ou está sendo executado;
● … tipicamente, migração “sender-initiated” é realizada quando da
descarga - “uploading” de programas para um servidor;
● … outro exemplo, envio de um programa para um servidor de
banco de dados Web para realizar “queries” naquele servidor.
● “receiver-initiated” - iniciativa para a migração do código é da
máquina destino, ou seja, quando presente entre cliente e servidor, o cliente toma a iniciativa da migração;
● … tipicamente, migração “receiver-initiated” é realizada quando da
3. Processos – 3.5 Migração de Código
3.5.2 – Migração e Recursos Locais
● Em princípio o que torna tão difícil a migração de código é que o
segmento de recursos nem sempre pode ser simplesmente transferido junto com outros segmentos sem ser modificado;
● e.g., ... um processo aguarda uma resposta a uma requisição
numa porta TCP específica ?! ... em caso de migração, como informar ao remetente os novos dados ?!
● solução: ... processo abandona o “port” até então utilizado e
requisita um novo “port” no destino.
● ... em outros casos, transferir a referência não é um problema,
3. Processos – 3.5 Migração de Código
… 3.5.2 – Migração e Recursos Locais
● Para compreendermos esta sistemática, iremos distinguir três
tipos diferentes de associações de recursos a processos:
● “Object to Resource Binding” - nesta associação a referência de
um objeto é um identificador, valor ou tipo:
● “identifier” – objeto requer precisamente uma instância específica do
recurso (e.g., banco de dados; URL, IP)
● “value” – objeto requer apenas valor do recurso (e.g., entradas na cache);
● “type” – objeto requer que apenas seja especificado o tipo do recurso
independente de qual instância (e.g., monitor colorido).
● Obs.: ... quando da migração, frequentemente é necessário a
3. Processos – 3.5 Migração de Código
… 3.5.2 – Migração e Recursos Locais
● ... ações para serem tomadas com respeito as referências dos
3. Processos – 3.5 Migração de Código
… 3.5.2 – Migração e Recursos Locais
● Obs.: ... é importante entender que o estabelecimento de uma
referência global pode ser mais do que simplesmente utilizar uma URL pois o seu uso pode as vezes ser proibitivo.
● e.g., considere um programa que gera imagens de alta qualidade
para uma estação de trabalho de multimídia dedicada;
● ... gerar imagens de alta qualidade em tempo real requer muito
processamento e, portanto, o programa deve ser deslocado para o servidor de alto desempenho;
● ... estabelecer uma referência global para a estação multimídia significa
estabelecer um canal de comunicação entre o servidor e a estação;
● ... resultado na rede é que mover o programa para o servidor talvez não
3. Processos – 3.5 Migração de Código
… 3.5.2 – Migração e Recursos Locais
● Obs.: ... esta situação pode mudar se a associação é por valor. ● e.g., considere um processo no qual uma região específica da
memória pode ser compartilhada com outros processos;
● ... se estabelecermos uma referência global => será necessário
uma forma distribuída de compartilhamento de memória;
● ... nestes casos, efetua-se a cópia do objeto para a máquina onde
o código móvel irá ser executado, logo um grande volume de dados deverá ser copiado (e.g., dicionários, “thesauruses”);
3. Processos – 3.5 Migração de Código
… 3.5.2 – Migração e Recursos Locais
● Obs.: ... se os dados forem recursos não ligados - “unattached”,
a melhor solução é a cópia do recurso para o destino, a menos que ele seja compartilhado por muitos processos;
● ... neste caso pode estabelecer uma referência global (opção).
● Para a associação por tipo (“Binding by Type”) e independente do
mapeamento do recurso à máquina, a solução é óbvia =>
● ... reassociar o processo a uma nova instância de um recurso local –
3. Processos – 3.5 Migração de Código
3.5.2 – Migração em Sist. Heterogêneos
● Até o momento, assumimos que o código migrado pode facil-
mente ser executado na máquina destino – de fato é verdade se estamos lidando com máquinas homogêneas;
● ... mas considerando que sistemas distribuídos são normalmente construí-
dos sobre uma coleção sistemas heterogêneas com diferentes sistemas operacionais e arquitetura, adequações se fazem necessárias.
● Problema: ... processos/threads são altamente dependentes do
hardware local, sistema operacional e sistema de execução.
● Solução: utilização de máquina abstrata que implementa
diferentes plataformas - linguagens interpretadas – que
3. Processos – 3.5 Migração de Código
… 3.5.2 – Migração em Sist. Heterogêneos
● Razão para Migração de Ambientes Completos – permitir a
continuidade da operação do sistema enquanto uma dada máquina necessita de manutenção;
● .... motivação: manutenção de ambientes computacionais em
execução por longos períodos, assim como seus processos.
● ... e.g., migração de um sistema operacional de tempo-real
virtualizado – passível de ocorrer em um cluster de servidores;
● ... será necessário migrar a imagem de memória bem como todas
as associações para recursos locais – como resolvê-los ?!
● Migração – envolve a migração da imagem da memória bem
3. Processos – 3.5 Migração de Código
… 3.5.2 – Migração em Sist. Heterogêneos
● Abordagens para migrar a imagem de memória:
● empilhar-se as páginas da memória na nova máquina e reenvia aquelas
que serão modificadas durante a migração do processo;
● pare a VM corrente, migre a memória e instancie um nova VM;
● permita que nova VM solicite novas páginas quando necessário, ou seja,
novos processos serão iniciados na nova VM imediatamente e a medida do necessário efetue cópias de páginas da memória.
● ... a segunda e terceira abordagens podem conduzir a queda de
performance por demandarem muito tempo para serviços contínuos e prolongarem o período de migração;
3. Processos – 3.5 Migração de Código
… 3.5.2 – Migração em Sist. Heterogêneos
● Migração de “Bindings” aos Recursos Locais:
● ... esses problemas são menores se considerarmos o escopo em cluster
de servidores, e.g., anuncio de um novo endereço IP-MAC;
● ... e.g., migração de bindings de arquivos é também relativamente simples
se considerarmos que o banco de dados é a terceira camada;
● ... efeito geral é que em vez de migrarmos processos, o sistema