• Nenhum resultado encontrado

Cap. 03 Processos. 3.1 Threads. 3.2 Virtualização. 3.3 Clientes Introdução às Threads Threads em Sistemas Distribuídos

N/A
N/A
Protected

Academic year: 2021

Share "Cap. 03 Processos. 3.1 Threads. 3.2 Virtualização. 3.3 Clientes Introdução às Threads Threads em Sistemas Distribuídos"

Copied!
81
0
0

Texto

(1)

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

(2)

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

(3)

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

(4)

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

(5)

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;

(6)

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

(7)

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

(8)

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

(9)

3 Processos – 3.1 Threads

… 3.1.1 – Introdução às Threads

● “multithreaded systems” - esta abordagem é típica em Ambiente

(10)

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

(11)

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

(12)

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

(13)

3 Processos – 3.1 Threads

… 3.1.1 – Introdução às Threads

● Thread Implementation – há duas abordagens: “User Level

(14)

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

(15)

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

(16)

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

(17)

3 Processos – 3.1 Threads

… 3.1.2 – Threads e Sistemas Distribuídos

“Multithreaded Servers” - … não somente simplifica o código,

(18)

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

(19)

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

(20)

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

(21)

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á

(22)

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

(23)

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;

(24)

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

(25)

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

(26)

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

(27)

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:

(28)

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.

(29)

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.

(30)

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

(31)

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:

(32)

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;

(33)

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

(34)

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

(35)

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.

(36)

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

(37)

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

(38)

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

(39)

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

(40)

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

(41)

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

(42)

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-

(43)

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.

(44)

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 é

(45)

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

(46)

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

(47)

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

(48)

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

(49)

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

(50)

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,

(51)

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-

(52)

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;

(53)

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

(54)

3 Processos – 3.4 Servidores – 3.4.2 Clusters de Servidores

Organização Geral

“server cluster” - logicamente organizados em três camadas:

(55)

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

(56)

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-

(57)

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

(58)

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

(59)

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

(60)

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

(61)

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

(62)

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

(63)

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

(64)

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

(65)

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-

(66)

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

(67)

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

(68)

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-

(69)

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

(70)

3. Processos – 3.5 Migração de Código

… 3.5.1 – Abordagens para Migração de Código

(71)

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

(72)

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,

(73)

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

(74)

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

(75)

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

(76)

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

(77)

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 –

(78)

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

(79)

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

(80)

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;

(81)

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

Referências

Documentos relacionados

Para nível diário incluiu intercepto e 20 diferenças defasadas.. Para diferença diária incluiu 19

Mas existe grande incerteza sobre quem detém esses direitos em certas áreas do Brasil rural.. Esta é a posição do Brasil em relação à segurança de direitos de propriedade de

This infographic is part of a project that analyzes property rights in rural areas of Brazil and maps out public policy pathways in order to guarantee them for the benefit of

Este capítulo trata da modelagem utilizada para analisar e projetar sensores baseados em SMF com trecho afunilado. Será descrita a modelagem utilizada para esses tipos de

RESUMO: Este trabalho teve como cunho pedagógico mostrar para os alunos do 3º Ensino Médio da Escola Estadual Brandão de Amorim, no ano de 2015, a questão da história

a) dois sábados e dois dias úteis no período compreendido entre 1º de março de 2016 e 28 de fevereiro de 2017. As duas assembleias realizadas durante os dias úteis deverão ocorrer

(Valor: 0,8 ponto) Uma agência de viagens oferece aos seus primeiros clientes, na primeira semana do ano, três pacotes promocionais: Básico, Padrão e Luxo. No regulamento da

Com o intuito de separar o lixo para fins de reciclagem, uma instituição colocou em suas dependências cinco lixeiras de diferentes cores, de acordo com o tipo