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 3.3.2 Lado Cliente para Transparência de Distribuição Pg. 1/81
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.5.3 Migração em Sistemas Heterogêneos Pg. 2/81
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/ Pg. 3/81
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 comunicação e processamento de clientes e servidores sejam sobrepostos, 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. Pg. 4/81
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. Pg. 5/81
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 os recursos computacionais é transparente, ou seja, o sistema operacional garante a independência dos processos. Pg. 6/81
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 deve ser creditado aos desenvolvedores de aplicações. Pg. 7/81
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 aplicações, pelo fato de serem concebidas como uma coleção de programas, cada qual executado em um processo separado; Pg. 8/81
3 Processos 3.1 Threads 3.1.1 Introdução às Threads multithreaded systems - esta abordagem é típica em Ambiente UNIX cooperação entre programas é implementada por meio do Mecanismo IPC (InterProcess Communication). Pg. 9/81
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 threads é o fato de que muitas aplicações podem ser facilmente estruturadas como uma coleção de threads cooperantes. Pg. 10/81
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 threads com base em eventos) => se o kernel não distinguir as threads não há como suportar eventos entre as mesmas. Pg. 11/81
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 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. Pg. 12/81
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). Pg. 13/81
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 ). na sequência discutiremos clientes e servidores multithreaded Pg. 14/81
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... uma vez obtido os arquivos, o browser pode apresentá-los. Pg. 15/81
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 uma requisição anterior está sendo completada. Pg. 16/81
3 Processos 3.1 Threads 3.1.2 Threads e Sistemas Distribuídos 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. Pg. 17/81
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 com uma máquina de estados finitos!! Pg. 18/81
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 estado da solicitação é explicitamente salvo em tabelas para posteriormente ser recuperado. Pg. 19/81
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 menores e mais fáceis de serem compreendidos em razão do controle de fluxo simplificado. Pg. 20/81
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. Pg. 21/81
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 que possa imitar o comportamento de um outro sistema (Fig. b). Pg. 22/81
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; ou seja, virtualização tornou-se um problema menor. Pg. 23/81
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 e máquinas, permitindo que cada aplicação seja executada na sua própria máquina virtual com bibliotecas e sistema operacional. Pg. 24/81
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 diferentes tipos de interfaces. Pg. 25/81
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 bibliotecas, geralmente formada pelo que é conhecido por application programming interface. Pg. 26/81
3 Processos 3.2 Virtualização 3.2.2 Arquiteturas de Máquinas Virtuais 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 Pg. 27/81
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. Java Virtual Machine (JVM) Pg. 28/81
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. Vmware; VirtualBox Pg. 29/81
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. Pg. 30/81
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: Networked Application with its own Protocol General Solution to allow Access Pg. 31/81
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; tudo é processado e armazenado no servidor. Pg. 32/81
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 sincronização dos dados (como apresentado na Fig. abaixo). Pg. 33/81
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 atenção na medida que dispositivos móveis vem se tornando mais sofisticados e a conectividade na Internet aumentando. Pg. 34/81
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.... máquina cliente é utilizada apenas como terminal. Pg. 35/81
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 o terminal coração do sistema (X Kernel). Pg. 36/81
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 X Kernel, mas uma o faz com permissões especiais (Window Manager) - look and feel do display. Pg. 37/81
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 transparente por razões de desempenho e correção. Pg. 38/81
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 cliente é dependente da interface que o servidor oferece. Pg. 39/81
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 de nomes que possibilite a localização. Pg. 40/81
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 repassa uma única resposta à aplicação. Pg. 41/81
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 repetidamente 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. Pg. 42/81
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. Pg. 43/81
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 é responsável por retornar a resposta ao cliente requisitante. Pg. 44/81
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 no entanto, há serviços que não requerem um end point (já atribuído), e.g., time-of-day server. Pg. 45/81
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 point e na sequência contacta o servidor específico. Pg. 46/81
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 daemom no UNIX responsável por gerenciar serviços Internet tais como: FTP, POP3 e Telnet. Pg. 47/81
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 point associado a um serviço específico. Pg. 48/81
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 com alta carga, este método é mais eficiente, pois o servidor específico é executado somente quando necessário. Pg. 49/81
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, pois o mesmo simplesmente responde a requisições HTTP. Pg. 50/81
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 é frequentemente um importante benefício de um projeto stateful! Pg. 51/81
3 Processos 3.4 Servidores 3.4.1 Aspectos Gerais de Projeto 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. Pg. 52/81
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 dedicados para o processamento de aplicações. Pg. 53/81
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. Pg. 54/81
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 servidores de aplicação e, assim, é necessário que o switch seja capaz de distinguir os serviços para encaminhar as requisições. Pg. 55/81
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 disponibilidade, 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. Pg. 56/81
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 requisição, cuja requisição foi repassada. Pg. 57/81
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 the TCP connection to the selected replica. Pg. 58/81
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. Pg. 59/81
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 ser mantido em um sistema distribuído?! Pg. 60/81
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 ( foreign network ), ele irá receber um endereço temporário ( care-of address CoA) através do qual é atingível. Pg. 61/81
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 para o Servidor Distribuído e.g., um único endereço de contato. Pg. 62/81