Cap. 03 – Processos - Faculdade de Computaçãofaina/BCC_Crs/GSI028-2014-1S/DL/DS-Ch03.pdf“processo” – … bloco base para sistemas distribuídos, por outro lado a experiência

Luís F. Faina - 2013 Pg. 1/81

Cap. 03 – Processos

3.1 – Threads3.1.1 Introdução às Threads3.1.2 Threads em Sistemas Distribuídos

3.2 – Virtualização3.2.1 Virtualização em Sistemas Distribuídos3.2.2 Arquiteturas de Máquinas Virtuais

3.3 – Clientes3.3.1 Interface do Usuário3.3.2 Lado Cliente para Transparência de Distribuição


Cap. 03 – Processos

3.3 - … …

3.4 – Servidores3.4.1 Aspectos Gerais de Projeto3.4.2 Clusters de Servidores3.4.4 Gerenciamento de Clusters de Servidores

3.5 – Migração de Código3.5.1 Abordagens para Migração de Código3.5.2 Migração e Recursos Locais3.5.3 Migração em Sistemas Heterogêneos


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

● Notas de Aula do Prof. Ricardo Anido do Instituto de Computação (IC) da UNICAMP - www.ic.unicamp.br/~ranido/

http://www.cs.vu.nl/


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 independente do “hardware” subjacente.


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;

● “solução” - nível de granularidade mais fino - “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 os recursos computacionais é transparente, ou seja, o sistema operacional garante a independência dos processos.



… 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 deve ser creditado aos desenvolvedores de aplicações.




● 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 aplicações, pelo fato de serem concebidas como uma coleção de programas, cada qual executado em um processo separado;




● “multithreaded systems” - esta abordagem é típica em Ambiente UNIX – cooperação entre programas é implementada por meio do Mecanismo IPC (InterProcess Communication).




● … 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 “threads” é o fato de que muitas aplicações podem ser facilmente estruturadas como uma coleção de “threads” cooperantes.




● “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 threads com base em eventos) => se o kernel não distinguir as threads não há como suportar eventos entre as mesmas.




● “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 usuário em cima de uma única thread do kernel e compartilha os recursos e espaço de endereçamento com outros LWPs dentro do mesmo processo.




● Thread Implementation – há duas abordagens: “User Level Threads” (ULT) e “Kernel Level Threads” (KLT).



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”).

● … na sequência discutiremos clientes e servidores “multithreaded”



… 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” ...

● … uma vez obtido os arquivos, o “browser” pode apresentá-los.




● 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 uma requisição anterior está sendo completada.




● “Multithreaded Servers” - … não somente simplifica o código, mas facilita o desenvolvimento de servidores que exploram o paralelismo para atingir alto desempenho até mesmo em sistemas monoprocessados.




● 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 com uma máquina de estados finitos !!




● 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 estado da solicitação é explicitamente salvo em tabelas para posteriormente ser recuperado.




● 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 menores e mais fáceis de serem compreendidos em razão do controle de fluxo simplificado.


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á disponível do que será apresentado para o usuário final.



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 que possa imitar o comportamento de um outro sistema (Fig. b).



… 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;

● … ou seja, virtualização tornou-se um problema menor.



… 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 e máquinas, permitindo que cada aplicação seja executada na sua própria máquina virtual com bibliotecas e sistema operacional.



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 diferentes tipos de interfaces.



… 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 bibliotecas, geralmente formada pelo que é conhecido por “application programming interface”.




● Essência da Virtualização – imitar o comportamento das interfaces, 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:

● “Process Virtual Machine”

● “Virtual Machine Monitor”




● “Process Virtual Machine” - sistema que essencialmente provê um conjunto de instruções abstrato (e.g., inst. interpretadas ou emuladas) utilizado para executar aplicações.

● … Java Virtual Machine (JVM)




● “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.

● … Vmware; VirtualBox


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 seção a anatomia do Servidor.



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:

● “Networked Application with its own Protocol”

● “General Solution to allow Access”



… 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;

● … tudo é processado e armazenado no servidor.




● 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 sincronização dos dados (como apresentado na Fig. abaixo).




● “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 atenção na medida que dispositivos móveis vem se tornando mais sofisticados e a conectividade na Internet aumentando.




● “General Solution to allow Access” - acesso direto aos serviços remotos através de interfaces de usuário convenientes.

● ... máquina cliente é utilizada apenas como terminal.




● “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 o terminal – coração do sistema (X Kernel).




● “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 “X Kernel”, mas uma o faz com permissões especiais (Window Manager) - “look and feel” do display.



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 transparente por razões de desempenho e correção.



… 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 cliente é dependente da interface que o servidor oferece.




● 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 de nomes que possibilite a localizaçã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 repassa uma única resposta à aplicaçã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 inteiramente no servidor por se tratar de armazenamento não volátil para recuperação posterior, caso necessário.


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.

● ... na prática, o mapeamento é 1-para-1 entre porta e serviço.



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 é responsável por retornar a resposta ao cliente requisitante.



… 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

● … no entanto, há serviços que não requerem um “end point” (já atribuído), e.g., “time-of-day server”.




● … “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 point” e na sequência contacta o servidor específico.




● ... “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 daemom” no UNIX responsável por gerenciar serviços Internet tais como: FTP, POP3 e Telnet.




● “superservers” - servidores que ouvem em diversas portas, ou seja, oferece vários serviços independentes;

● … é mais eficiente ter um único “superserver” ouvindo cada “end point” associado a um serviço específico.




● “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 com alta carga, este método é mais eficiente, pois o servidor específico é executado somente quando necessário.




● 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, pois o mesmo simplesmente responde a requisições HTTP.




● ... 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” é frequentemente um importante benefício de um projeto “stateful” !




● e.g., imagine um servidor de arquivo que permite ao cliente manter 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;

● … esta abordagem melhora a performance das operações.



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 dedicados para o processamento de aplicações.


3 Processos – 3.4 Servidores – 3.4.2 Clusters de Servidores

… Organização Geral

● “server cluster” - logicamente organizados em três camadas: “logical switch”; “application” e “database system”.




● ... 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 servidores de aplicação e, assim, é necessário que o “switch” seja capaz de distinguir os serviços para encaminhar as requisições.




● 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 é estabelecer uma conexão TCP e enviar requisições da camada de aplicação como parte de um sessão.




● 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 requisição, cuja requisição foi repassada.




● TCP “handoff” - “as it is based on passing the duty of servicing the TCP connection to the selected replica”.


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 tentativas pelos clientes, se um dos endereços falha.



… 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 ser mantido em um sistema distribuído ?!




● 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 (“foreign network”), ele irá receber um endereço temporário (“care-of address – CoA) através do qual é atingível.




● Este princípio pode ser usado para oferecer um endereço estável para o Servidor Distribuído – e.g., um único endereço de contato.


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 de migração de código e na sequência os recursos locais neces- sários na execução dos programas que sofreram migração.



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 processamento para máquinas com baixa carga;

● ... assim fazem-se necessários algoritmos de distribuição de carga que possibilitem a tomada de decisões quanto a redistribuição de tarefas relacionadas ao conjunto de processos.



… 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 necessidade do cliente preencher formulários que serão traduzidos em um série de operações de banco de dados.




● 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 fracionar a aplicação em diferentes partes, o suporte à migração de código torna possível a configuração dinâmica do sistema.




● ... princípio de configuração dinâmica de um cliente para que possa se comunicar com um servidor específico.




● 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- lizada, podemos alterar o protocolo entre cliente e servidor bem como a sua implementação.




● 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 execução/”status”) incluindo o de execução.




● Alternativas 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 descarga - “downloading” de programas para o cliente.



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, e.g., referência de um arquivo através de uma URL.



… 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 mudança de referência para recursos, no entanto, isto não muda a associação entre recurso e processo.




● ... ações para serem tomadas com respeito as referências dos recursos quando da migração de código para outra máquina.




● 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 seja uma boa idéia em função do alto custo da referência global.




● 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”);

● ... referência global => é a melhor alternativa !




● 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 – máquina para o qual o código foi deslocado.



3.5.2 – Migração em Sist. Heterogêneos

● Até o momento, assumimos que o código migrado pode facilmente 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 efetivamente necessitam de sua própria VM ou Virtual VMs.



… 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 como das associações a recursos locais.




● 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;

● alternativa – abordagem de pré cópia + primeira opção.




● 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 operacional inteiro pode ser movido entre máquinas.

Documents

Cap. 03 – Processos - Faculdade de Computaçãofaina/BCC_Crs/GSI028-2014-1S/DL/DS-Ch03.pdf“processo” – … bloco base para sistemas distribuídos, por outro lado a experiência