Gestor de Processos Tolerante a Falhas para Aplicações Paralelas

Tamanho: px
Começar a partir da página:

Download "Gestor de Processos Tolerante a Falhas para Aplicações Paralelas"

Transcrição

1 Gestor de Processos Tolerante a Falhas para Aplicações Paralelas Oberdan Rocha Pinheiro, Josemar Rodrigues de Souza Resumo O desempenho computacional disponibilizado pelos sistemas paralelos resulta da capacidade de dividir o trabalho em partes menores e encaminhar cada uma delas para ser processada paralelamente em diferentes nós de um sistema distribuídos. A interrupção de uma das partes paralelizadas pode comprometer a computação, pois a aplicação depende do resultado de todos os componentes paralelizados. A investigação avalia o comportamento do componente GP (Gestor de Processos) que monitora o ambiente de execução das aplicações paralelas a fim de detectar falhas da classe fail stop em aplicações paralelas que utilizam MPI (Message Passing Interface), permitindo que as mesmas sejam reiniciadas automaticamente em outro nó disponível da computação distribuída para garantir o resultado do processamento na presença de falhas. Palavras chavess Computação de Alto Desempenho, Detectores de Falhas, MPI, Tolerância a Falhas I. INTRODUÇÃO A busca por computação de alto desempenho é cada vez maior nas áreas de aplicações científicas e de engenharia, pois essas áreas têm problemas assintoticamente complexos (em tempo e espaço), com características que facilitam a paralelização. Através da paralelização de aplicações, pode-se obter aumento de desempenho, realizando-se operações mais rapidamente ou processando-se maiores volumes de dados. As arquiteturas de computadores paralelos têm como principal objetivo o aumento da capacidade de processamento, utilizando o potencial oferecido por um grande número de recursos computacionais [1]. Os clusters baseados em passagem de mensagens foram construídos tendo-se como principal preocupação o provimento de um ambiente eficiente e portável, relegando a segundo plano a questão da tolerância a falhas. No caso de aplicações paralelas que utilizam varias máquinas e cuja execução se estende por muitas horas, a falha de uma única Artigo recebido em 03 de Fevereiro de Este artigo foi desenvolvido pelo Programa de Pós-Graduação da Faculdade SENAI CIMATEC. O.R.P. e J.R.S. estão no Centro Integrado de Manufatura e Tecnologia (SENAI-CIMATEC), Núcleo de Modelagem Computacional, Laboratório de HPC (High Performance Computing), Salvador, Bahia, Brasil, Tel , Fax: , J.R.S. está com a Universidade do Estado da Bahia - UNEB, Núcleo de Arquitetura de Computadores e Sistemas Operacionais - ACSO, Salvador, Bahia, Brasil, Tel. +55 (71) , 7 máquina neste período normalmente faz com que toda a computação já realizada seja perdida [2]. Ao longo do tempo, surgiram várias abordagens e ferramentas para a programação paralela e distribuída, sendo que, nos últimos anos, o uso do MPI tornou-se um padrão para comunicação em clusters. No entanto o padrão MPI não prevê mecanismo para monitoração do ambiente de execução e tratamento de falhas. Neste contexto, o presente trabalho tem como objetivo avaliar o desempenho do componente de software GP (Gestor de Processos) que é responsável pela monitoração do ambiente de execução das aplicações distribuídas a fim de detectar falhas da classe fail stop, onde os nós falham e não executam nenhuma operação após isso, restando ao nó monitor detectar a falha pela omissão de comunicações posteriores, permitindo que as mesmas sejam reiniciadas automaticamente em outro nó disponível do cluster para garantir a continuidade do processamento da aplicação na presença de falhas. O artigo está organizado da seguinte forma. A seção II descreve as considerações sobre tolerância a falhas, na seção III serão apresentadas as principais estratégias de monitoramento utilizadas por detectores de falhas, na seção IV serão apresentadas as principais características sobre qualidade de serviço de detecção de falhas, na seção V são apresentados alguns trabalhos relacionados na área de detectores de falhas, na seção VI é apresentada a solução proposta, na seção VII são apresentados os resultados experimentais e na seção VIII conclui-se a pesquisa. II. TOLERÂNCIA A FALHAS De acordo com Weber [2] o termo tolerância a falhas foi apresentado originalmente por Avizienis em Quando o sistema exige alta confiabilidade e alta disponibilidade, técnicas de tolerância a falhas devem ser utilizadas para garantir o funcionamento correto do sistema, mesmo na ocorrência de falhas, exigindo componentes adicionais ou algoritmos especiais. Tolerância a falhas tem como objetivo permitir que um sistema comporte-se de maneira bem definida durante a ocorrência de falhas, visando minimizar o aparecimento das mesmas ou então tratá-las quando ocorrerem. A. Modelos de Falhas em Sistemas Distribuídos Existem diversas possibilidades de uma aplicação distribuída falhar. Essas falhas podem ser categorizadas em modelos que descrevem como o sistema se comportará na

2 presença de falhas. O modelo de Cristian [3], ilustrado na Fig. 1, classifica as falhas em falhas por colapso, omissão, temporização, resposta e arbitrárias. O modelo de Schneider [4] estende esse modelo adicionando a classe fail-stop, que é um subconjunto da classe de falhas por colapso, e especializando as falhas de omissão em: falhas de omissão de envio e falhas de omissão de recepção. A classe de falhas fail-stop é a mais específica desses modelos e comporta as falhas que são detectadas antes que o processo que falhou possa causar alterações no restante da computação. Por exemplo, nesse modelo, um processador que apresente uma falha na execução de alguma operação deixará de funcionar em vez de fornecer resultados incorretos. A classe de falhas arbitrárias, também chamadas de Bizantinas, são as mais abrangentes. Nessa classe o processo que falhou pode apresentar um comportamento fora da sua especificação, totalmente imprevisível e podendo comprometer o restante da computação. Um sistema que assume o tratamento somente da classe fail-stop é bem mais simples de ser implementado do que um que trate também as falhas arbitrárias. FIG. 1. MODELOS DE FALHAS EM SISTEMAS DISTRIBUÍDOS. A computação em clusters depende de elementos centralizados para operar. Nodos de gerência são utilizados para o escalonamento de tarefas e monitoramento do ambiente. Nodos de armazenamento oferecem acesso a discos de grande capacidade e altas taxas de transferência. Nodos de front-end permitem que os usuários interajam com o sistema sem interferir no tempo de processamento dos nodos de computação. Devido à importância crítica desses componentes, e por eles representarem uma pequena fração da computação que eles compõem, é recomendado dedicar uma atenção especial a esses recursos. A forma mais comum de suporte a tolerância a falhas para componentes centralizados é a replicação da funcionalidade que pode ser feita de duas formas: replicação ativa e replicação passiva. Na replicação ativa, um processo secundário recebe uma cópia das entradas do processo primário e mantêm uma cópia idêntica do estado da computação em execução. Além disso, o processo secundário monitora o processo primário para detectar comportamentos 8 incorretos. Se o processo secundário detectar uma falha ele assume o comando da funcionalidade crítica do sistema [5]. Na replicação passiva, uma máquina secundária aguarda a falha do processo primário sem manter o estado do sistema. Tipicamente, essa máquina permanece inativa, porém com todo software necessário para substituir o processo primário quando necessário. Podem acontecer interrupções do serviço durante a substituição do processo primário pelo secundário dependendo do estado da réplica. O monitoramento das réplicas normalmente é implementado utilizando um dos dois mecanismos: heartbeat [6] [7] ou consenso Bizantino [8]. No monitoramento por heartbeat um processo monitor recebe mensagens periódicas dos componentes monitorados. Essas mensagens indicam que o componente funciona de forma correta o suficiente para conseguir enviá-las. Se o processo monitor deixa de recebê-las de um determinado componente além de um limite de tempo estabelecido o nodo é considerado falho. Uma variação do heartbeat utiliza protocolos epidêmicos ou hierárquicos [9] para a propagação das mensagens no sistema. Essas variantes permitem que o heartbeat escale com um número maior de nodos. No consenso Bizantino as réplicas votam por um resultado ou ação a ser tomada com base nas entradas observadas. Quando existe um desacordo entre os processos então os processos que tem minoria na votação são considerados falhos. Esse tipo de monitoramento consegue detectar falhas Bizantinas. No entanto, o custo de comunicação desse tipo de monitoramento é muito maior do que o monitoramento por heartbeat já que no pior caso do algoritmo é necessário que todos os nodos se comuniquem entre si. Apesar disso, para um pequeno número de réplicas, esse algoritmo ainda é aceitável. B. Sistemas de Arquivos Tolerantes a Falhas Um sistema de arquivos tolerante a falhas é importante em função de que os arquivos produzidos na computação distribuída serão armazenados e recuperados do mesmo. É importante que ele esteja sempre disponível para atender às requisições e, quando existirem, consiga atender o volume necessário em um tempo aceitável. Para garantir a tolerância a falhas e alta disponibilidade, algumas soluções podem ser empregadas. Algumas destas soluções são viabilizadas através de hardware, tais como a técnica de RAID (Redundant Array of Independent Disks), multiplexação de discos e replicação de primeira classe e outras viabilizadas por software como, por exemplo, a replicação de segunda classe [10] [11]. No caso da replicação de primeira classe, o servidor é replicado e, conseqüentemente, o sistema de arquivos também e na replicação de segunda classe utiliza-se a técnica conhecida como caching do cliente ou journal file system; são exemplos desta replicação os sistemas de arquivos CODA [11] [12]. A técnica empregada no RAID consiste em agrupar uma série de discos em um único local e disponibilizá-los na forma de uma imagem única de sistema de armazenamento e recuperação de informações [10]. Sua implementação pode ser viabilizada por hardware, ou seja, um dispositivo com

3 finalidade única de agrupar os discos e realizar o gerenciamento dos mesmos, estando este dispositivo ligado através de um barramento de alta velocidade aos nós de computação. O Sistema de Arquivos de Rede NFS (Network File System) da Sun Microsystems é considerado o padrão de fato para o compartilhamento de arquivos pela rede e é suportado nativamente na maioria das versões do UNIX e Linux, estando disponível para praticamente qualquer ambiente operacional e opera baseado no modelo cliente servidor [13]. O projeto original do NFS tinha o TCP/IP como base e assim pôde ser facilmente adaptado para conectar sistemas de arquivos geograficamente dispersos através da Internet e outras redes de longa distância. porém estas mensagens são do tipo query-response, também conhecidas como ping. O mecanismo ilustrado na Fig. 3 funciona da seguinte maneira: seja Worker o processo monitorado e Master o processo detector de falhas. O processo Master envia periodicamente uma query ( você está vivo?") para o processo Worker, que deve responder ( eu estou vivo!") em tempo hábil, porém, caso tal resposta não chegue num certo timeout, o Master assume que ocorreu uma falha do processo Worker. III. DETECÇÃO DE FALHAS EM SISTEMAS DISTRIBUÍDOS Grande parte dos problemas relacionados aos sistemas distribuídos requer algum tipo de coordenação entre os diversos componentes [14]. Em sistemas compostos por vários nodos a falha ou desconexão destes nodos é um evento freqüente e deve ser considerado. Desse modo, um requisito fundamental para a coordenação dos processos é que estes tenham os seus estados armazenados para posterior reconfiguração do sistema em caso de falhas. As principais estratégias de monitoramento utilizadas por detectores de falhas são a push e a pull. Numa abordagem push o processo monitorado toma um papel mais ativo, enquanto que numa abordagem pull, ele adota um papel mais passivo [15]. Segundo Satzger [15], detectores de falhas que utilizem o paradigma push possuem alguns benefícios se comparados àqueles que utilizem uma abordagem pull, necessitam de apenas a metade das mensagens para uma qualidade de detecção equivalente. A. Estratégia push O mecanismo ilustrado na Fig. 2 funciona da seguinte maneira: seja Worker o processo monitorado e Master o processo detector de falhas. O processo Worker envia periodicamente um heartbeat ( estou vivo") para o processo Master. Quando o Master recebe um heartbeat ele confia no Worker por um período de tempo, porém caso novas mensagens não cheguem até expirar este timeout, o Master assume que ocorreu uma falha do processo Worker. Naturalmente, o timeout deve ter um valor maior que o intervalo de heartbeat. FIG. 3. MONITORAMENTO POR PULL. IV. QUALIDADE DO SERVIÇO DE DETECÇÃO DE FALHAS Um detector de falhas pode ser definido por duas características: Completude é a garantia de que a falha em um membro do grupo é eventualmente detectada por cada outro membro não-falho. Eficiência significa que as falhas são detectadas rápida e precisamente. Algumas aplicações distribuídas confiam em um único ou mesmo poucos computadores centrais para a detecção de falhas ao longo da computação. Estes computadores são responsáveis por manter as informações ao longo de toda a computação e, portanto, a eficiência na detecção de uma falha depende do tempo em que a falha é inicialmente detectada por um membro não-falho. Gupta et al. [16] observou que mesmo na falta de um servidor central, a notificação de uma falha é tipicamente comunicada pelo primeiro membro a detectá-la a todo o grupo via broadcast. Portanto, mesmo sendo importante alcançar completude, uma eficiente detecção de falhas é mais comumente relacionada com o tempo da primeira detecção da falha. Chandra & Toueg [17] analisaram as propriedades dos detectores de falhas demonstrando porque é impossível para um algoritmo de detecção de falhas deterministicamente alcançarem ambas as características de completude e precisão estando numa rede assíncrona e não-confiável. Como conseqüência, a maioria das aplicações distribuídas tem optado por contornar esta impossibilidade ao confiar em algoritmos de detecção de falhas que garantam completude deterministicamente enquanto alcançam eficiência apenas probabilisticamente [16]. FIG. 2. MONITORAMENTO POR PUSH. B. Estratégia pull Esta estratégia é também baseada na troca de mensagens periódicas para suspeitar acerca de falhas em processos, 9 V. TRABALHOS RELACIONADOS Chen et al. [15] propõem um modelo baseado numa análise probabilística do tráfego de rede, utilizando amostragens dos tempos de chegada para calcular uma estimativa acerca do tempo de chegada da próxima mensagem. O timeout é

4 configurado de acordo com esta estimativa e é acrescida de uma margem de segurança constante α, que é calculada uma única vez. Hayashibara et al. [18] propuseram um detector de falhas accrual cuja particularidade é ajustar dinamicamente a escala onde o nível de suspeita é expresso às condições da rede. A distribuição das amostras recebidas anteriormente é utilizada como uma aproximação da distribuição probabilística das futuras mensagens de heartbeat. Satzger et al. [19] propuseram um novo detector accrual adaptativo, com características para aumentar a flexibilidade e diminuir os custos computacionais. É armazenado um histórico dos tempos de chegada entre mensagens, de maneira que é possível realizar uma estimativa da probabilidade de que nenhuma mensagem chegue após determinado atraso, ou seja, do processo ter falhado. Das et al. [20], apresenta um protocolo de gestão da composição de grupos, chamado SWIM. O protocolo SWIM é dividido em duas partes: um detector de falhas e um protocolo de disseminação da composição do grupo. Este detector de falhas foi proposto inicialmente em [16]. O detector utiliza uma estratégia de ping randomizado, onde cada processo periodicamente testa outro processo, selecionado aleatoriamente. Informações sobre a composição do grupo e falhas de processos são transmitidas nas próprias mensagens do detector de falhas, através de um mecanismo de piggybacking. VI. SOLUÇÃO PROPOSTA Informações sobre a situação operacional dos processos são freqüentemente necessárias para implementar aplicações confiáveis e distribuídas. O trabalho propõe um Gestor de Processos colaborativo para detectar e tratar falhas da classe fail stop em aplicações paralelas. O monitoramento dos processos é realizado através da estratégia push, e o timeout do heartbeat é fixado e deve ser ajustados conforme o ambiente onde este mecanismo será empregado. A fixação do valor desse parâmetro implica em um trade-off entre corretude e eficiência. Para não exceder o limite de tempo tão cedo, os valores de timeout poderiam ser determinados de forma conservadora, ou seja, valores muito grandes. No entanto, isto implica em uma demora na detecção de falhas, conseqüentemente acarretando em maior sobrecarga da aplicação. A orientação é definir os valores desses parâmetros tão grandes quanto necessários, mas tão pequenos quanto possíveis. A Fig. 4 apresenta os componentes que compõe a arquitetura do ambiente. A arquitetura do ambiente de computação tolerante a falhas foi projetada utilizando o paradigma SPMD (Single Program Multiple Data) implementado sob o esquema Master/Worker. No modelo SPMD o mesmo programa é executado em diferentes máquinas, entretanto esses programas manipulam um conjunto de dados diferentes. No esquema Master/Worker, o Master é o processo responsável por decompor o problema em diversas tarefas menores e distribuir essas tarefas entre os Workers. A. Arquitetura FIG. 4. ARQUITETURA DO AMBIENTE TOLERANTE A FALHAS. O Worker é o processo que recebe os trabalhos, processam e devolvem para o Master, que gerencia, organiza e controla os dados processados. A comunicação entre os processos (Master/Worker) é feita através de troca de mensagens realizadas por chamadas explícitas às rotinas da biblioteca MPI [21]. O SATF (Sistema de Arquivos Tolerante a Falhas) é o local de armazenamento confiável que utiliza o sistema de arquivos de rede NFS onde são registrados os dados para manter o cluster operante em caso de falha. Esse componente é imprescindível em razão de que os dados produzidos serão armazenados e recuperados do mesmo. As operações de E/S ao SAFT será realizada através do padrão MPI-IO que é um recurso útil para a criação e manipulação de arquivos paralelos [22]. O componente AP (Aplicação Paralela) representa o programa paralelizado, esse componente está presente tanto no grupo Master quanto no grupo Worker, o componente GP é o componente responsável pela monitoração do ambiente e gestão dos processos em caso de falhas, estando presente apenas no grupo Master. Esse componente é o responsável por aguardar o envio de pacotes periódicos heartbeat por parte dos Workers, quando o GP detectar que um Worker não enviou o pacote dentro do tempo estabelecido, então o mecanismo assume que o nó que parou de enviar os pulsos está indisponível. A Fig. 5 ilustra o funcionamento do ambiente de execução. Quando o processo Master escalonar um bloco de dados para um Worker um trigger será acionado para enviar uma solicitação ao GP para criar um backup do bloco de dados que será armazenado em um servidor de arquivos estável (SATF). Em seguida os blocos de dados serão enviados para os Workers realizarem o processamento da tarefa. 10

5 FIG. 5. INTERAÇÃO ENTRE OS COMPONENTES. O GP aguarda o envio de pacotes periódicos (heartbeat) por parte dos Workers, quando o GP detectar que um Worker não enviou o pacote dentro do tempo estabelecido, então o mecanismo assume que o Worker está indisponível e esse será excluído logicamente do cluster e não terá mais blocos de dados escalonados. Para permitir a continuidade da computação o GP recupera o bloco de dados destinado ao Worker que parou de funcionar através dos backups armazenados no servidor de arquivos, em seguida o bloco de dados recuperado é escalonado para o próximo Worker disponível dar continuidade ao processamento. B. Implementação Os componentes do serviço foram implementados utilizando a linguagem C++. A aplicação paralela utilizada para a validação do GP foi o programa de multiplicação de matrizes ilustrada na Fig. 6, por ser facilmente escalável tanto em cômputo quanto em comunicação. FIG. 7. ENVIO DO TIMEOUT VIA MPI_BCAST. Os processos são alocados de maneira estática e realizam atividades idênticas sobre um conjunto de dados distintos. É necessário que todos os Workers só comecem o processamento quando todos tiverem recebidos os seus respectivos timeout para envio de pacotes periódicos ao Master. Para a manipulação dos registros que contém o estado dos Workers armazenados no SAFT o GP utiliza o paradigma Single Process I/O que determina que apenas um processo realize o I/O. A Fig. 9 apresenta o mecanismo de acesso aos arquivos através do padrão MPI-IO. n a C = ij k = 1 FIG. 6. MULTIPLICAÇÃO DE MATRIZES. ik b kj A forma matemática de multiplicação de matrizes (1) consiste do somatório dos produtos entre os elementos da linha i de A pelos elementos da coluna j de B, com i variando de 1 até a quantidade de linhas de A e j de 1 até o número de colunas de B. O processo Master é responsável pela inicialização das matrizes A e B, envio dos blocos de dados para os Workers e sincronização dos dados para montagem da matriz C. Os Workers além de realizarem o produto dos vetores enviados pelo processo Master, também devem periodicamente enviar os pacotes heartbeat dentro do timeout determinado pelo Master. O timeout será comunicado aos Workers através da operação MPI_Bcast, essa rotina permite ao processo Master enviar dados para todos os processos Workers de um determinado grupo, conforme Fig. 7. (1) 11 FIG. 9. MECANISMO DE ACESSO AOS ARQUIVOS. Os Workers enviam os pacotes heartbeat para o GP e ele realiza o armazenamento dessas informações através das seguintes operações: MPI_File_open() para associar um file handle a um arquivo. MPI_File_read() para lê uma quantidade fixa de dados a partir da posição do ponteiro do arquivo. (não coletiva e bloqueante). MPI_File_write() para escrever uma quantidade fixa de dados a partir da posição do ponteiro do arquivo. (não coletiva e bloqueante). MPI_File_close() para fechar o arquivo. VII. AVALIAÇÃO E RESULTADOS EXPERIMENTAIS Para a avaliação do componente de software GP (Gestor de Processos) colaborativo foi utilizada a técnica de injeção de falhas por software por se tratar de um método eficiente para a validação de sistemas [23]. A abordagem visa à emulação de falhas de hardware, sem comprometer fisicamente o ambiente, e a análise do comportamento do sistema na presença destas falhas. Os experimentos foram realizados no laboratório de HPC (High Performance Computing) do Centro Integrado de

6 Manufatura e Tecnologia (SENAI CIMATEC). O ambiente consistiu de um cluster de computadores formado por 16 blades HP ProLiant DL120 G6 Quad core Intel Xeon HP X3450 (2.67GHz, 95W, 8MB, 1333, HT, Turbo), utilizandose do sistema operacional Ubuntu/Linux 64 bit, mpich que implementa todo o padrão MPI 1.1 e o compilador gnu gcc A rede de conexão utilizada segue o padrão Gigabit Ethernet. A. Tempo de Detecção de Falhas A decisão de quando a informação fornecida por um detector de falhas deve ser considerada verdadeira é de responsabilidade da aplicação [24]. Esta decisão envolve custos ao programa para realizar uma ação de reconfiguração do ambiente. O componente GP utiliza à variável timeout para representar o tempo máximo de espera por uma mensagem de heartbeat. A fixação dessa variável implica na eficiência da detecção das falhas nos nodos do cluster. A parametrização dessa variável com um valor muito longo implicaria em uma demora na detecção de falhas, o que comprometeria a eficiência do GP, determinar bons valores para esse parâmetro se torna um desafio. Nesse sentido, foram realizados experimentos onde alguns valores para o timeout foram testados a fim de avaliar o impacto dessa escolha no tempo da aplicação. Os resultados dos experimentos foram obtidos pela média dos resultados de três execuções. Os experimentos foram feitos em um ambiente com falhas, as falhas foram injetadas nos Workers forçando esses processos a não enviarem os dados do heartbeat apartir de um determinado momento ao processo GP. Nos experimentos os Workers foram configurados com valores do timeout iguais a 15, 30, 45 e 60 s, o cluster foi configurado com 21 processos, sendo 20 processos Workers e um processo Master. No primeiro experimento conforme Tabela 1 o valor do timeout foi de 15 s, no segundo experimento conforme Tabela 2 o valor do timeout foi de 30 s, no terceiro experimento conforme Tabela III o valor do timeout foi de 45 s e no quarto experimento conforme Tabela IV o valor do timeout foi de 60 s. TABELA I CENÁRIO DO PRIMEIRO EXPERIMENTO 4 03:19:50 03:20:07 00:00: :21:06 03:21:27 00:00: :25:47 03:26:15 00:00: :27:55 03:28:15 00:00: :30:26 03:30:52 00:00: :57:19 03:58:06 00:00: :56:39 03:57:31 00:00: :57:25 03:58:06 00:00:41 TABELA III CENÁRIO DO TERCEIRO EXPERIMENTO 4 04:39:46 04:41:03 00:01: :41:23 04:42:43 00:01: :43:02 04:44:23 00:01: :42:55 04:44:23 00:01: :45:23 04:46:53 00:01:30 TABELA IV CENÁRIO DO QUARTO EXPERIMENTO 4 04:45:15 04:46:39 00:01: :47:32 04:48:59 00:01: :49:02 04:50:50 00:01: :51:40 04:52:59 00:01: :53:15 04:54:59 00:01:44 O cenário do primeiro experimento configurado com um timeout de 15 s é quem apresenta um melhor resultado na detecção de falhas por realizar um monitoramento freqüente dos processos envolvidos na computação. Note que um freqüente monitoramento pode levar a um aumento no tempo de execução da aplicação e conseqüentemente irá levar mais tempo para completar o processamento da aplicação. Uma vez que em cada nó, os processos monitores compartilham um núcleo de processamento com um processo de aplicação. Na Fig. 10 observa-se que, em geral, quanto maior o valor do timeout, maior o tempo gasto na detecção da falha. Tempo de Detecção (s) Nº de processos timeout 15 s timeout 30 s timeout 45 s timeout 60 s FIG. 10. AVALIAÇÃO DO MONITORAMENTO PARA DIFERENTES VALORES DE TIMEOUT EM UM CENÁRIO COM DE FALHAS. TABELA II CENÁRIO DO SEGUNDO EXPERIMENTO 4 03:39:40 03:40:31 00:00: :55:33 03:56:21 00:00:48 Entretanto os valores de 45 s e 60 s segundos obtiveram resultados muito próximos na detecção de até oito processos. Também é possível observar uma estabilidade na detecção de falhas para o valor do timeout igual a 60 s. VIII. CONCLUSÃO Aplicações paralelas de alto desempenho são projetadas 12

7 para minimizar o tempo de execução, em geral, o padrão MPI de troca de mensagens tem sido utilizado para sua execução em diversas plataformas paralelas e distribuídas. Uma aplicação paralela pode necessitar de horas, dias ou meses de tempo de computação, sendo necessário protegê-la das falhas de componentes do cluster. O mecanismo de tolerância a falhas proposto mostrou-se eficiente na detecção de falhas da classe fail stop em aplicações paralelas que utilizam MPI, permitindo que as mesmas sejam reiniciadas em outro nó disponível do cluster para garantir a continuidade do processamento da aplicação na presença de falhas. Os processos Workers identificados como falhos foram excluídos logicamente do cluster e não tiveram mais blocos de dados enviados para processamento. Os blocos de dados enviados aos processos falhos foram recuperados do SATF e encaminhados ao próximo Worker disponível do cluster. A maior sobrecarga apresentada na solução aconteceu na camada de monitoramento quando o valor definido para o timeout foi muito baixo. Como trabalho futuro, uma análise mais aprofundada deve ser realizada em todos os experimentos com um maior número de nós. Uma estratégia hibrida de armazenamento e recuperação deverá ser adotada ao mecanismo, a fim de minimizar o tempo de reconfiguração do sistema, tratamento de falhas referente ao processo Master, isso poderá ser alcançado através dos backups armazenados no SATF. Por fim, o mecanismo de detecção de falhas proposto suporta múltiplas falhas ao mesmo tempo, se aproximando assim das reais situações de ocorrência de falhas em grandes clusters de computadores. REFERENCIAS BIBLIOGRÁFICAS [1] Sterling, Thomas L. Salmon, John. Becker, Donald J. e Savaresse, Daniel F. How to build a Beowulf: a guide to the implementation and aplication of PC clusters. Massachuset t s Institute of Technology [2] Weber, Taisy Silva, Um roteiro para exploração dos conceitos básicos de tolerância a falhas. Apostila do Programa de Pós- Graduação Instituto de Informática - UFRGS. Porto Alegre, [3] CRISTIAN, F. A Rigorous Approach to Fault-Tolerant Programming. IEEE Trans. Softw. Eng., Piscataway, NJ, USA, v.11, n.1, p.23 31, [4] SCHNEIDER, F. B. Abstractions for Fault Tolerance in Distributed Systems. Ithaca, NY, USA: [s.n.], [5] GOLDBERG, D. et al. The Design and Implementation of a Fault- Tolerant Cluster Manager. Tech. Rep., Xerox Systems Institute, [S.l.], [6] LEANGSUKSUN, C. B. et al. Achieving high availability and performance computing with an HA-OSCAR cluster. Future Gener. Comput. Syst., Amsterdam, The Netherlands, The Netherlands, v.21, n.4, p , [7] BAGCHI, S. et al. Chameleon: software infrastructure for adaptive fault tolerance. IEEE Transactions on Parallel and Distributed Systems, [S.l.], v.10, p , [8] LAMPORT, L.; PEASE, M. The Byzantine Generals Problem. ACM Trans. Program. Lang. Syst., New York, NY, USA, v.4, n.3, p , [9] COMPUTINA, I. et al. Algorithm-dependent Fault Tolerance for Distributed Computing [10] KRISTLER, James J Increasing File System Availability Through Second-Class Replication - Proceedings of the IEEE Workshop on Management of Replicated Data, (Nov. 1990), Houston, Texas. [11] SATYANARAYANAN, M CODA: A Highly Available File System for a Distributed Workstation Environment Proceedings of the Second IEEE Workshop on Workstation Operating Systems, (Set.1989), Pacific Grove, California. [12] CODA CODA File System. Disponível em (Jan. 2012). [13] DEITEL, Harvey M. e DEITEL, Paul J. e CHOFFNES,David R. Sistemas Operacionais Terceira Edição - Editora Pearson Prentice Hall, [14] Greve, F. G. P. (2005). Protocolos fundamentais para o desenvolvimento de aplicações robustas. SBRC 05. [15] Chen, W.; Toueg, S. & Aguilera, M. (2002). On the quality of service of failure detectors. IEEE Transactions on Computers, 51(5): [16] Gupta, I.; Chandra, T. D. & Goldszmidt, G. S. (2001). On scalable and efficient distributed failure detectors. In Proceedings of the 20 th annual ACM Symposium on Principles of Distributed Computing (PODC '01), pp , New York, NY, EUA. ACM. [17] Chandra, T. D. & Toueg, S. (1996). Unreliable failure detectors for reliable distributed systems. Journal of the ACM, 43(2): [18] Hayashibara, N.; Défago, X.; Yared, R. & Katayama, T. (2004). The accrual failure detector. In Proceedings of the 2004 IEEE Symposium on Reliable Distributed Systems, pp , Los Alamitos, CA, EUA. IEEE Computer Society [19] Satzger, B.; Pietzowski, A.; Trumler, W. & Ungerer, T. (2007). A new adaptive accrual failure detector for dependable distributed systems. In Proceedings of the 2007 ACM Symposium on Applied Computing (SAC '07), pp , New York, NY, EUA. ACM. [20] Das, A., Gupta, I., and Motivala, A. (2002). Swim: scalable weaklyconsistent infectionstyle process group membership protocol. In Proc. International Conference on Dependable Systems and Networks DSN 2002, pages [21] MPI FORUM. The MPI Message Passing Interface Standard. Knoxville: University of Tennessee, [22] T. M.-I. Committee. Mpi-io: A parallel file i/o interface for mpi version 0.5, [23] Juliano C. Vacaro, Taisy S. Weber, Injeção de Falhas na Fase de Teste de Aplicações Distribuídas. XX Simpósio Brasileiro de Engenharia de Software Florianópolis, SC, Brasil. [24] Stelling, P., DeMatteis, C., Foster, I., Kesselman, C., Lee, C., von Laszewski, G. A fault detection service for wide area distributed computations. Cluster Computing 2 (1999),

Um Modelo Computacional Tolerante a Falhas para Aplicações Paralelas Utilizando MPI

Um Modelo Computacional Tolerante a Falhas para Aplicações Paralelas Utilizando MPI Um Modelo Computacional Tolerante a Falhas para Aplicações Paralelas Utilizando MPI Oberdan R. Pinheiro 1, Josemar R. de Souza 1,2 1 Centro Integrado de Manufatura e Tecnologia (SENAI-CIMATEC) Salvador,

Leia mais

Um cluster de servidores de email pode ser usado para servir os emails de uma empresa.

Um cluster de servidores de email pode ser usado para servir os emails de uma empresa. CLUSTERS Pode-se pegar uma certa quantidade de servidores e juntá-los para formar um cluster. O serviço então é distribuído entre esses servidores como se eles fossem uma máquina só. Um cluster de servidores

Leia mais

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 6 - ALGORÍTIMOS PARALELOS MPI - Parallel Virtual Machine e PVM - Parallel Virtual Machine 1. INTRODUÇÃO Inicialmente é necessário conceber alguns conceitos para entendimento dos algoritmos paralelos:

Leia mais

Resumo. Introdução Classificação Fases Curiosidades

Resumo. Introdução Classificação Fases Curiosidades Tolerância à falha Resumo Introdução Classificação Fases Curiosidades Introdução Sistemas Tolerantes a Falhas são aqueles que possuem a capacidade de continuar provendo corretamente os seus serviços mesmo

Leia mais

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com Sistemas Operacionais 2014 Introdução Alexandre Augusto Giron alexandre.a.giron@gmail.com Roteiro Sistemas Operacionais Histórico Estrutura de SO Principais Funções do SO Interrupções Chamadas de Sistema

Leia mais

Resumo. Introdução Cluster Cluster Beowulf Curiosidades Conclução

Resumo. Introdução Cluster Cluster Beowulf Curiosidades Conclução Cluster Resumo Introdução Cluster Cluster Beowulf Curiosidades Conclução Introdução Sua empresa esta precisando fazer um grande processamento; As Nuvens existentes não são suficientes para sua empresa;

Leia mais

Detectores de Defeitos para Redes Wireless Ad Hoc

Detectores de Defeitos para Redes Wireless Ad Hoc Detectores de Defeitos para Redes Wireless Ad Hoc Giovani Gracioli e Raul Ceretta Nunes 1 GMICRO/CT Universidade Federal de Santa Maria (UFSM) Campus Camobi - 97105-900 Santa Maria/RS {giovani,ceretta}@inf.ufsm.br

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Introdução a Tolerância a Falhas

Sistemas Distribuídos: Conceitos e Projeto Introdução a Tolerância a Falhas Sistemas Distribuídos: Conceitos e Projeto Introdução a Tolerância a Falhas Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática / UFMA http://www.lsd.ufma.br

Leia mais

SAPOTI: Servidores de Aplicações confiáveis Tcp/Ip

SAPOTI: Servidores de Aplicações confiáveis Tcp/Ip SAPOTI: Servidores de Aplicações confiáveis Tcp/Ip Egon Hilgenstieler, Roverli Pereira Ziwich, Emerson Fabiano Fontana Carara, Luis Carlos Erpen De Bona, Elias Procópio Duarte Jr. Universidade Federal

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

Tipos de Sistemas Distribuídos (Cluster e Grid)

Tipos de Sistemas Distribuídos (Cluster e Grid) Tipos de Sistemas Distribuídos (Cluster e Grid) Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência

Leia mais

4 Computação Paralela 4.1. Introdução

4 Computação Paralela 4.1. Introdução 4 Computação Paralela 4.1. Introdução Nos últimos anos observa-se uma tendência cada vez maior do aumento da demanda computacional na resolução de grandes problemas. Exemplos de aplicações que exigem alto

Leia mais

Capítulo 8 Arquitetura de Computadores Paralelos

Capítulo 8 Arquitetura de Computadores Paralelos Capítulo 8 Arquitetura de Computadores Paralelos Necessidade de máquinas com alta capacidade de computação Aumento do clock => alta dissipação de calor Velocidade limitada dos circuitos => velocidade da

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos 1 de 9 Sistemas Distribuídos O que é um sistema distribuído? Um conjunto de computadores autonomos a) interligados por rede b) usando um software para produzir uma facilidade de computação integrada. Qual

Leia mais

Sistemas distribuídos:comunicação

Sistemas distribuídos:comunicação M. G. Santos marcela@estacio.edu.br Faculdade Câmara Cascudo - Estácio de Sá 16 de abril de 2010 Formas de comunicação Produtor-consumidor: comunicação uni-direccional, com o produtor entregando ao consumidor.

Leia mais

hvbacellar@gmail.com Palavras-chave Cluster; Beowulf; OpenMosix; MPI; PVM.

hvbacellar@gmail.com Palavras-chave Cluster; Beowulf; OpenMosix; MPI; PVM. Cluster: Computação de Alto Desempenho Hilário Viana Bacellar Instituto de Computação, Universidade Estadual de Campinas Av. Albert Einstein 1251, Cidade Universitária, CEP 13083-970 Campinas, SP, Brasil

Leia mais

Falha benigna. Sistema. Sistema Próprio. Interrompido. Restauração. Falha catastrófica. Falha catastrófica. Sistema. Impróprio

Falha benigna. Sistema. Sistema Próprio. Interrompido. Restauração. Falha catastrófica. Falha catastrófica. Sistema. Impróprio INE 5418 Segurança de Funcionamento Tipos de s Detecção de s Recuperação de s Segurança de Funcionamento Representa a confiança depositada em um determinado sistema em relação ao seu correto funcionamento

Leia mais

Sistemas Operacionais Carlos Eduardo Portela Serra de Castro

Sistemas Operacionais Carlos Eduardo Portela Serra de Castro Introdução Sistemas Operacionais 1 Sistema Operacional: Um conjunto de programas, executado pelo computador como os outros programas. Função: Controlar o funcionamento do computador, disponibilizando seus

Leia mais

IMPLANTAÇÃO DE UM AMBIENTE DE ALTA DISPONIBILIDADE DE REDE E MONITORAÇÃO DINÂMICA DE INFRAESTRUTURA EM SERVIDORES WEB.

IMPLANTAÇÃO DE UM AMBIENTE DE ALTA DISPONIBILIDADE DE REDE E MONITORAÇÃO DINÂMICA DE INFRAESTRUTURA EM SERVIDORES WEB. IMPLANTAÇÃO DE UM AMBIENTE DE ALTA DISPONIBILIDADE DE REDE E MONITORAÇÃO DINÂMICA DE INFRAESTRUTURA EM SERVIDORES WEB. Marllus de Melo Lustosa (bolsista do PIBIC/UFPI), Luiz Cláudio Demes da Mata Sousa

Leia mais

3. Comunicação em Sistemas Distribuídos

3. Comunicação em Sistemas Distribuídos 3. Comunicação em 3.1.Troca de mensagens As mensagens são objetos de dados cuja estrutura e aplicação são definidas pelas próprias aplicações que a usarão. Sendo a troca de mensagens feita através de primitivas

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Aula 6 Estrutura de Sistemas Operacionais Prof.: Edilberto M. Silva http://www.edilms.eti.br Baseado no material disponibilizado por: SO - Prof. Edilberto Silva Prof. José Juan Espantoso

Leia mais

Desenvolvimento de um Cluster de Alto Desempenho com PVM

Desenvolvimento de um Cluster de Alto Desempenho com PVM Desenvolvimento de um Cluster de Alto Desempenho com PVM Daniel Cândido de Oliveira 1, Yzaac Gonçalves da Silva 1, Madianita Bogo 1 1 Centro Universitário Luterano de Palmas Universidade Luterana do Brasil

Leia mais

Veritas Storage Foundation da Symantec

Veritas Storage Foundation da Symantec Veritas Storage Foundation da Symantec Gerenciamento de armazenamento heterogêneo on-line O Veritas Storage Foundation oferece uma solução completa para o gerenciamento de armazenamento heterogêneo on-line.

Leia mais

Cluster HPC High Performance Computing.

Cluster HPC High Performance Computing. Faculdade de Tecnologia de Guaratinguetá. doze, março de 2009. Cluster HPC High Performance Computing. Diogo Salles, Thiago Pirro, Camilo Bernardes, Paulo Roberto, Ricardo Godoi, Douglas, Fauzer. Sistemas

Leia mais

Sistemas Paralelos e Distribuídos. Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN

Sistemas Paralelos e Distribuídos. Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN Sistemas Paralelos e Distribuídos Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN Conceitos preliminares Paralelismo refere-se a ocorrência simultânea de eventos em um computador Processamento

Leia mais

Análise de Desempenho de um SGBD para Aglomerado de Computadores

Análise de Desempenho de um SGBD para Aglomerado de Computadores Análise de Desempenho de um SGBD para Aglomerado de Computadores Diego Luís Kreutz, Gabriela Jacques da Silva, Hélio Antônio Miranda da Silva, João Carlos Damasceno Lima Curso de Ciência da Computação

Leia mais

UM AMBIENTE COMPUTACIONAL TOLERANTE A FALHAS PARA APLICAÇÕES PARALELAS

UM AMBIENTE COMPUTACIONAL TOLERANTE A FALHAS PARA APLICAÇÕES PARALELAS SENAI CIMATEC PROGRAMA DE PÓS-GRADUAÇÃO EM MODELAGEM COMPUTACIONAL E TECNOLOGIA INDUSTRIAL Mestrado em Modelagem Computacional e Tecnologia Industrial Dissertação de mestrado UM AMBIENTE COMPUTACIONAL

Leia mais

SGBD x Disponibilidade

SGBD x Disponibilidade SGBD x Disponibilidade Objetivo Escopo Motivação Conceitos básicos Disponibilidade Redundância de software Redundância de hardware 1 Objetivo: Objetivo Discutir tecnologias e práticas operacionais utilizadas

Leia mais

Desempenho de um Cluster Virtualizado em Relação a um Cluster Convencional Similar

Desempenho de um Cluster Virtualizado em Relação a um Cluster Convencional Similar Desempenho de um Cluster Virtualizado em Relação a um Cluster Convencional Similar David Beserra 1, Alexandre Borba¹, Samuel Souto 1, Mariel Andrade 1, Alberto Araujo 1 1 Unidade Acadêmica de Garanhuns

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

Leia mais

Sistemas Distribuídos e Paralelos

Sistemas Distribuídos e Paralelos Sistemas Distribuídos e Paralelos Tolerância a Falhas Ricardo Mendão Silva Universidade Autónoma de Lisboa r.m.silva@ieee.org January 14, 2015 Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos

Leia mais

Programação Concorrente Processos e Threads

Programação Concorrente Processos e Threads Programação Concorrente Processos e Threads Prof. Eduardo Alchieri Processos O conceito mais central em qualquer sistema operacional é o processo Uma abstração de um programa em execução Um programa por

Leia mais

Sistema de Arquivos. Ciclo 5 AT1. Prof. Hermes Senger / Hélio Crestana Guardia

Sistema de Arquivos. Ciclo 5 AT1. Prof. Hermes Senger / Hélio Crestana Guardia Sistema de Arquivos Ciclo 5 AT1 Prof. Hermes Senger / Hélio Crestana Guardia Referência: Deitel Cap. 13 Nota O presente material foi elaborado com base no material didático do livro Sistemas Operacionais,

Leia mais

Roteiro. Sistemas Distribuídos. Sistemas de Arquivos Distribuídos. Sistema de arquivos distribuídos

Roteiro. Sistemas Distribuídos. Sistemas de Arquivos Distribuídos. Sistema de arquivos distribuídos Sistemas Distribuídos Sistemas de Arquivos Distribuídos Roteiro Sistema de arquivos distribuídos Requisitos Arquivos e diretórios Compartilhamento Cache Replicação Estudo de caso: NFS e AFS Sistemas Distribuídos

Leia mais

COMPUTAÇÃO EM GRID COM BANCO DE DADOS ORACLE 10g

COMPUTAÇÃO EM GRID COM BANCO DE DADOS ORACLE 10g COMPUTAÇÃO EM GRID COM BANCO DE DADOS ORACLE 10g Daniel Murara Barcia Especialista em Sistemas de Informação Universidade Federal do Rio Grande do Sul daniel@guaiba.ulbra.tche.br Resumo. Esse artigo aborda

Leia mais

4 Estrutura do Sistema Operacional. 4.1 - Kernel

4 Estrutura do Sistema Operacional. 4.1 - Kernel 1 4 Estrutura do Sistema Operacional 4.1 - Kernel O kernel é o núcleo do sistema operacional, sendo responsável direto por controlar tudo ao seu redor. Desde os dispositivos usuais, como unidades de disco,

Leia mais

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários.

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários. Os sistemas computacionais atuais permitem que diversos programas sejam carregados na memória e executados simultaneamente. Essa evolução tornou necessário um controle maior na divisão de tarefas entre

Leia mais

Introdução às Redes de Computadores. Por José Luís Carneiro

Introdução às Redes de Computadores. Por José Luís Carneiro Introdução às Redes de Computadores Por José Luís Carneiro Portes de computadores Grande Porte Super Computadores e Mainframes Médio Porte Super Minicomputadores e Minicomputadores Pequeno Porte Super

Leia mais

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos Introdução a Sistemas Distribuídos Definição: "Um sistema distribuído é uma coleção de computadores autônomos conectados por uma rede e equipados com um sistema de software distribuído." "Um sistema distribuído

Leia mais

Programação de Computadores

Programação de Computadores Programação de Computadores Aula 04: Sistema Operacional Material Didático do Livro: Introdução à Informática Capron,, H. L. e Johnson, J. A Pearson Education Sistemas Operacionais: Software Oculto Serve

Leia mais

Sistemas Operacionais. (Capítulo 3) INTRODUÇÃO À ENGENHARIA DA COMPUTAÇÃO. Professor: Rosalvo Ferreira de Oliveira Neto

Sistemas Operacionais. (Capítulo 3) INTRODUÇÃO À ENGENHARIA DA COMPUTAÇÃO. Professor: Rosalvo Ferreira de Oliveira Neto Sistemas Operacionais (Capítulo 3) INTRODUÇÃO À ENGENHARIA DA COMPUTAÇÃO Professor: Rosalvo Ferreira de Oliveira Neto Estrutura 1. Definições 2. Classificações 3. CPU 4. Memória 5. Utilitários O que se

Leia mais

LCAD. ALGORÍTMOS PARALELOS (Aula 6) Neyval C. Reis Jr. OUTUBRO/2004. Laboratório de Computação de Alto Desempenho DI/UFES.

LCAD. ALGORÍTMOS PARALELOS (Aula 6) Neyval C. Reis Jr. OUTUBRO/2004. Laboratório de Computação de Alto Desempenho DI/UFES. ALGORÍTMOS PARALELOS (Aula 6) Neyval C. Reis Jr. OUTUBRO/2004 LCAD Laboratório de Computação de Alto Desempenho DI/UFES Tópico 20 janeiro 27 janeiro 3 fev 10 fev 17 fev 24 fev 3 março Paradigma de Paralelismo

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Faculdades SENAC Análise e Desenvolvimento de Sistemas 1 de agosto de 2009 Conceitos Conança de Funcionamento (Dependability) Representa a conança depositada em um determinado sistema em relação ao seu

Leia mais

Arquitetura de Computadores. Professor: Vilson Heck Junior

Arquitetura de Computadores. Professor: Vilson Heck Junior Arquitetura de Computadores Professor: Vilson Heck Junior Agenda Conceitos Estrutura Funcionamento Arquitetura Tipos Atividades Barramentos Conceitos Como já discutimos, os principais componentes de um

Leia mais

Sistemas Operacionais Cap 2 Estruturas de Sistemas Computacionais

Sistemas Operacionais Cap 2 Estruturas de Sistemas Computacionais Estruturas de Sistemas Computacionais Por que estudar a arquitetura de sistemas computacionais? Talvez porque o comportamento de um sistema operacional está ligado aos mecanismos de E/S de um computador.

Leia mais

Arquitecturas Tolerantes a faltas em Sistemas Distribuídos

Arquitecturas Tolerantes a faltas em Sistemas Distribuídos Arquitecturas Tolerantes a faltas em Sistemas Distribuídos Replicação de Servidores Transacções Atómicas Protocolos de Replicação Replicação passiva vs. activa Replicação de máquinas de estados vs. Replicação

Leia mais

William Stallings Arquitetura e Organização de Computadores 8 a Edição

William Stallings Arquitetura e Organização de Computadores 8 a Edição William Stallings Arquitetura e Organização de Computadores 8 a Edição Capítulo 7 Entrada/saída Os textos nestas caixas foram adicionados pelo Prof. Joubert slide 1 Problemas de entrada/saída Grande variedade

Leia mais

Faculdade Integrada do Ceará FIC Graduação em Redes de Computadores

Faculdade Integrada do Ceará FIC Graduação em Redes de Computadores Faculdade Integrada do Ceará FIC Graduação em Redes de Computadores Disciplina - Sistemas Distribuídos Prof. Andrey Halysson Lima Barbosa Aula 8 Sistema de Arquivos Distribuído Sumário Problemas Solução

Leia mais

Infra estrutura da Tecnologia da Informação

Infra estrutura da Tecnologia da Informação Infra estrutura da Tecnologia da Informação Capítulo 3 Adaptado do material de apoio ao Livro Sistemas de Informação Gerenciais, 7ª ed., de K. Laudon e J. Laudon, Prentice Hall, 2005 CEA460 Gestão da Informação

Leia mais

SISTEMA DE ARQUIVOS DISTRIBUÍDOS

SISTEMA DE ARQUIVOS DISTRIBUÍDOS SISTEMA DE ARQUIVOS DISTRIBUÍDOS Sistemas Distribuídos 331 Arquivo: objeto que existe após criação, é imune a falhas temporárias e é persistente até que seja destruído Propósito de arquivos: armazenamento

Leia mais

Oracle Database em High Availability usando Microsoft Windows Clusters Server (MSCS) e Oracle Fail Safe

Oracle Database em High Availability usando Microsoft Windows Clusters Server (MSCS) e Oracle Fail Safe Oracle Database em High Availability usando Microsoft Windows Clusters Server (MSCS) e Oracle Fail Safe Objetivos: Apresentar conceitos do Microsoft Windows Clusters Server Apresentar a arquitetura do

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Introdução Redes de Computadores é um conjunto de equipamentos que são capazes de trocar informações e compartilhar recursos entre si, utilizando protocolos para se comunicarem e

Leia mais

Treinamento PostgreSQL Cluster de Banco de Dados - Aula 01

Treinamento PostgreSQL Cluster de Banco de Dados - Aula 01 Treinamento PostgreSQL Cluster de Banco de Dados - Aula 01 Eduardo Ferreira dos Santos SparkGroup Treinamento e Capacitação em Tecnologia eduardo.edusantos@gmail.com eduardosan.com 13 de Junho de 2013

Leia mais

Replicação de servidores

Replicação de servidores Arquiteturas Tolerantes a faltas em Sistemas Distribuídos Replicação de servidores Replicação: que benefícios nos dá? 1) Melhor desempenho e escalabilidade Replicar serviços permite que algumas operações

Leia mais

Princípios de TI - Computadores. Sistema Operacional. CECOMP Colegiado de Engenharia da Computação. Prof. Fábio Nelson. Slide 1

Princípios de TI - Computadores. Sistema Operacional. CECOMP Colegiado de Engenharia da Computação. Prof. Fábio Nelson. Slide 1 Sistema Operacional Slide 1 Sistema Operacional Um conjunto de programas que se situa entre os softwares aplicativos e o hardware: Gerencia os recursos do computador (CPU, dispositivos periféricos). Estabelece

Leia mais

Sistemas Operacionais. Alexandre Meslin meslin@inf.puc-rio.br

Sistemas Operacionais. Alexandre Meslin meslin@inf.puc-rio.br Sistemas Operacionais Alexandre Meslin meslin@inf.puc-rio.br Ementa Apresentação do curso Cap1 - Visão Geral Cap2 - Conceitos de Hardware e Software Cap3 - Concorrência Cap4 - Estrutura do Sistema Operacional

Leia mais

Organização de Computadores 1

Organização de Computadores 1 Organização de Computadores 1 SISTEMA DE INTERCONEXÃO (BARRAMENTOS) Prof. Luiz Gustavo A. Martins Arquitetura de von Newmann Componentes estruturais: Memória Principal Unidade de Processamento Central

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos LICENCIATURA EM COMPUTAÇÃO Prof. Adriano Avelar Site: www.adrianoavelar.com Email: eam.avelar@gmail.com O que veremos hoje... Evolução Histórica Motivação Conceitos Características

Leia mais

SISTEMAS OPERACIONAIS. Apostila 03 Estrutura do Sistema Operacional UNIBAN

SISTEMAS OPERACIONAIS. Apostila 03 Estrutura do Sistema Operacional UNIBAN SISTEMAS OPERACIONAIS Apostila 03 Estrutura do Sistema Operacional UNIBAN 1.0 O Sistema Operacional como uma Máquina Virtual A arquitetura (conjunto de instruções, organização de memória, E/S e estrutura

Leia mais

Sistemas Operacionais I Parte III Estrutura dos SOs. Prof. Gregorio Perez gregorio@uninove.br 2007. Roteiro. Componentes do Sistema

Sistemas Operacionais I Parte III Estrutura dos SOs. Prof. Gregorio Perez gregorio@uninove.br 2007. Roteiro. Componentes do Sistema Sistemas Operacionais I Parte III Estrutura dos SOs Prof. Gregorio Perez gregorio@uninove.br 2007 Roteiro Serviços Estrutura dos Sistemas Operacionais Funções do Sistema Operacional Chamadas do Sistema

Leia mais

Cluster de Alta Disponibilidade em um Sistema Administrativo Hospitalar

Cluster de Alta Disponibilidade em um Sistema Administrativo Hospitalar Cluster de Alta Disponibilidade em um Sistema Administrativo Hospitalar Julio Cezar Gross Junior 1, Msc. Eduardo Maronãs Monks 1 1 Faculdade de Tecnologia Senac (FATEC) Curso Superior de Tecnologia em

Leia mais

ARQUITETURA TRADICIONAL

ARQUITETURA TRADICIONAL INTRODUÇÃO Atualmente no universo corporativo, a necessidade constante de gestores de tomar decisões cruciais para os bons negócios das empresas, faz da informação seu bem mais precioso. Nos dias de hoje,

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais RAID Marcelo Diniz http://marcelovcd.wordpress.com/ O que é RAID? RAID RAID (Redundant Array of Independent Disks ) Matriz Redundante de Discos Independentes Recuperar informação

Leia mais

Adaptação dinâmica do Timeout para Detectores de Defeito usando Informações do Protocolo SNMP.

Adaptação dinâmica do Timeout para Detectores de Defeito usando Informações do Protocolo SNMP. Adaptação dinâmica do Timeout para Detectores de Defeito usando Informações do Protocolo SNMP. Francisco Carlos Vogt Raul Ceretta Nunes CT Centro de Tecnologia PPGEP Programa de Pós-Graduação em Engenharia

Leia mais

Arcserve Backup: Como proteger ambientes NAS heterogêneos com NDMP

Arcserve Backup: Como proteger ambientes NAS heterogêneos com NDMP Arcserve Backup: Como proteger ambientes NAS heterogêneos com NDMP Phil Maynard UNIDADE DE SOLUÇÕES DE GERENCIAMENTO DE DADOS PARA O CLIENTE FEVEREIRO DE 2012 Introdução Em todos os lugares, o volume de

Leia mais

Revista Eletrônica da FANESE ISSN 2317-3769

Revista Eletrônica da FANESE ISSN 2317-3769 REPLICAÇÃO E ALTA DISPONIBILIDADE NO SQL SERVER 2012 Renata Azevedo Santos Carvalho 1 RESUMO Neste artigo serão relatadas as novidades que o SQL Server 2012 vem trazendo nesta sua nova versão no que se

Leia mais

REPLICAÇÃO E AUTO DISPONIBILIDADE NO SQL SERVER

REPLICAÇÃO E AUTO DISPONIBILIDADE NO SQL SERVER FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE FANESE NÚCLEO DE PÓS-GRADUAÇÃO E EXTENSÃO NPGE CURSO DE PÓS-GRADUAÇÃO LATO SENSU ESPECIALIZAÇÃO EM BANCO DE DADOS REPLICAÇÃO E AUTO DISPONIBILIDADE NO SQL

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Curso de Tecnologia em Redes de Computadores Disciplina: Redes I Fundamentos - 1º Período Professor: José Maurício S. Pinheiro Material de Apoio VI PROTOCOLOS

Leia mais

SISTEMA DE GERÊNCIA - DmView

SISTEMA DE GERÊNCIA - DmView Sistema de Gerenciamento DmView O DmView é o Sistema de Gerência desenvolvido para supervisionar e configurar os equipamentos DATACOM, disponibilizando funções para gerência de supervisão, falhas, configuração,

Leia mais

RAID. Propõe o aumento da confiabilidade e desempenho do armazenamento em disco. RAID (Redundant Array of Independent Disks )

RAID. Propõe o aumento da confiabilidade e desempenho do armazenamento em disco. RAID (Redundant Array of Independent Disks ) RAID O que é um RAID? RAID RAID (Redundant Array of Independent Disks ) Matriz Redundante de Discos Independentes Propõe o aumento da confiabilidade e desempenho do armazenamento em disco. RAID Surgiu

Leia mais

Sistemas Operacionais

Sistemas Operacionais UNIVERSIDADE BANDEIRANTE DE SÃO PAULO INSTITUTO POLITÉCNICO CURSO DE SISTEMAS DE INFORMAÇÃO Sistemas Operacionais Notas de Aulas: Tópicos 7 e 8 Estrutura do Sistema Operacional São Paulo 2009 1 Sumário

Leia mais

Resumo até aqui. Gerenciamento Proteção Compartilhamento. Infra-estrutura de Software

Resumo até aqui. Gerenciamento Proteção Compartilhamento. Infra-estrutura de Software Resumo até aqui Complexidade do computador moderno, do ponto de vista do hardware Necessidade de abstrações software Sistema computacional em camadas SO como uma máquina estendida abstrações SO como um

Leia mais

Sistema de Arquivos Distribuídos

Sistema de Arquivos Distribuídos Sistema de Arquivos Distribuídos Sistema de Arquivos Distribuídos A interface cliente para um sistema de arquivos é composta por um conjunto de primitivas e operações em arquivos (criar, apagar, ler, escrever)

Leia mais

Capítulo VI Telecomunicações: Redes e Aplicativos

Capítulo VI Telecomunicações: Redes e Aplicativos Capítulo VI Telecomunicações: Redes e Aplicativos Uma rede nada mais é do que máquinas que se comunicam. Estas máquinas podem ser computadores, impressoras, telefones, aparelhos de fax, etc. Se interligarmos

Leia mais

Sistemas de Arquivos Distribuídos. Universidade Federal do ABC Prof. Dr. Francisco Isidro Massetto

Sistemas de Arquivos Distribuídos. Universidade Federal do ABC Prof. Dr. Francisco Isidro Massetto Sistemas de Arquivos Distribuídos Universidade Federal do ABC Prof. Dr. Francisco Isidro Massetto Conceitos Dois tipos Stateless Statefull Statefull Mantém informações de estado Nome do arquivo Ponteiro

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Entrada e Saída Drivers e s Norton Trevisan Roman Marcelo Morandini Jó Ueyama Apostila baseada nos trabalhos de Kalinka Castelo Branco, Antônio Carlos Sementille, Luciana A. F. Martimiano

Leia mais

O que são sistemas supervisórios?

O que são sistemas supervisórios? O que são sistemas supervisórios? Ana Paula Gonçalves da Silva, Marcelo Salvador ana-paula@elipse.com.br, marcelo@elipse.com.br RT 025.04 Criado: 10/09/2004 Atualizado: 20/12/2005 Palavras-chave: sistemas

Leia mais

Fundamentos de Sistemas Operacionais

Fundamentos de Sistemas Operacionais Fundamentos de Sistemas Operacionais Aula 16: Entrada e Saída: Estudo de Caso Diego Passos Última Aula Software de Entrada e Saída. Subsistema de E/S. Conjunto de camadas de abstração para realização de

Leia mais

Processos e Threads (partes I e II)

Processos e Threads (partes I e II) Processos e Threads (partes I e II) 1) O que é um processo? É qualquer aplicação executada no processador. Exe: Bloco de notas, ler um dado de um disco, mostrar um texto na tela. Um processo é um programa

Leia mais

SISTEMAS OPERACIONAIS

SISTEMAS OPERACIONAIS Universidade do Contestado Campus Concórdia Curso de Engenharia Ambiental Prof.: Maico Petry SISTEMAS OPERACIONAIS DISCIPLINA: Informática Aplicada DEFINIÇÃO É um programa de controle do computador. O

Leia mais

UM ESTUDO SOBRE TIPOS DE ALGORITMOS DE DISPATCHER PARA WEB CLUSTERS

UM ESTUDO SOBRE TIPOS DE ALGORITMOS DE DISPATCHER PARA WEB CLUSTERS REVISTA CIENTÍFICA ELETRÔNICA DE SISTEMAS DE INFORMAÇÃO - ISSN 1807-1872 P UBLICAÇÃO C IENTÍFICA DA F ACULDADE DE C IÊNCIAS J URÍDICAS E G ERENCIAIS DE G ARÇA/FAEG A NO II, NÚMERO, 04, FEVEREIRO DE 2006.

Leia mais

9º Congresso de Pesquisa O IMPACTO DO SERVIÇO DE NAT E FIREWALL NO ATENDIMENTO DE REQUISIÇÕES WEB

9º Congresso de Pesquisa O IMPACTO DO SERVIÇO DE NAT E FIREWALL NO ATENDIMENTO DE REQUISIÇÕES WEB 9º Congresso de Pesquisa O IMPACTO DO SERVIÇO DE NAT E FIREWALL NO ATENDIMENTO DE REQUISIÇÕES WEB Autor(es) JOSE LUIS ZEM 1. Introdução Atualmente é impensável o dia-a-dia sem o uso de computadores, principalmente

Leia mais

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com Última atualização: 20.03.2013 Conceitos Banco de dados distribuídos pode ser entendido como uma coleção de múltiplos bds

Leia mais

Arquitetura e Sistema de Monitoramento para

Arquitetura e Sistema de Monitoramento para Arquitetura e Sistema de Monitoramento para 1 Computação em Nuvem Privada Mestranda: Shirlei A. de Chaves Orientador: Prof. Dr. Carlos Becker Westphall Colaborador: Rafael B. Uriarte Introdução Computação

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Sistemas de Entrada/Saída Princípios de Software Sistema de Entrada/Saída Princípios de Software Tratadores (Manipuladores) de Interrupções Acionadores de Dispositivos (Device Drivers)

Leia mais

ENGENHARIAS E TECNOLOGIAS - Computação e Informática ESTUDO DE APLICABILIDADE DE SISTEMAS FRACAMENTE ACOPLADOS UTILIZANDO HARDWARE DE BAIXO CUSTO

ENGENHARIAS E TECNOLOGIAS - Computação e Informática ESTUDO DE APLICABILIDADE DE SISTEMAS FRACAMENTE ACOPLADOS UTILIZANDO HARDWARE DE BAIXO CUSTO ENGENHARIAS E TECNOLOGIAS - Computação e Informática ESTUDO DE APLICABILIDADE DE SISTEMAS FRACAMENTE ACOPLADOS UTILIZANDO HARDWARE DE BAIXO CUSTO Autor: HILÁRIO VIANA BACELLAR Co-autor: Matheus de Paula

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Sistemas de Entrada/Saída Princípios de Hardware Sistema de Entrada/Saída Visão Geral Princípios de Hardware Dispositivos de E/S Estrutura Típica do Barramento de um PC Interrupções

Leia mais

RMI: Uma Visão Conceitual

RMI: Uma Visão Conceitual RMI: Uma Visão Conceitual Márcio Castro, Mateus Raeder e Thiago Nunes 11 de abril de 2007 Resumo Invocação de Método Remoto (Remote Method Invocation - RMI) trata-se de uma abordagem Java para disponibilizar

Leia mais

Sistemas Operacionais. Prof. Pedro Luís Antonelli Anhanguera Educacional

Sistemas Operacionais. Prof. Pedro Luís Antonelli Anhanguera Educacional Sistemas Operacionais Prof. Pedro Luís Antonelli Anhanguera Educacional INTRODUÇÃO Sistema Operacional (S.O.) Aplicativos Formado por um conjunto de rotinas que oferecem serviços aos usuários, às aplicações

Leia mais

Premissas Básicas. Consideramos que uma grade é formada por um conjunto de processos que se comunicam por troca de mensagens.

Premissas Básicas. Consideramos que uma grade é formada por um conjunto de processos que se comunicam por troca de mensagens. Um Serviço Escalável e Robusto para Gerenciamento de Membros em Grades Computacionais de Grande Escala Fernando Castor-Filho 1, Rodrigo Castro 2, Augusta Marques 2, Francisco M. Soares-Neto 2, Raphael

Leia mais

TABELA DE EQUIVALÊNCIA FECOMP Curso de Engenharia de Computação

TABELA DE EQUIVALÊNCIA FECOMP Curso de Engenharia de Computação TABELA DE EQUIVALÊNCIA FECOMP Curso de Engenharia de Computação Disciplina A Disciplina B Código Disciplina C/H Curso Disciplina C/H Código Curso Ano do Currículo 66303 ESTRUTURA DE DADOS I 68/0 ENG. DE

Leia mais

Considerações no Projeto de Sistemas Cliente/Servidor

Considerações no Projeto de Sistemas Cliente/Servidor Cliente/Servidor Desenvolvimento de Sistemas Graça Bressan Graça Bressan/LARC 2000 1 Desenvolvimento de Sistemas Cliente/Servidor As metodologias clássicas, tradicional ou orientada a objeto, são aplicáveis

Leia mais

Cornell usa computação de alto desempenho para acelerar a pesquisa e ampliar o acesso a softwares

Cornell usa computação de alto desempenho para acelerar a pesquisa e ampliar o acesso a softwares Portfólio de produtos Microsoft para servidores Estudo de caso de solução do cliente Cornell usa computação de alto desempenho para acelerar a pesquisa e ampliar o acesso a softwares Visão geral País ou

Leia mais

Arquitetura e Organização de Computadores I

Arquitetura e Organização de Computadores I Arquitetura e Organização de Computadores I Interrupções e Estrutura de Interconexão Prof. Material adaptado e traduzido de: STALLINGS, William. Arquitetura e Organização de Computadores. 5ª edição Interrupções

Leia mais

Impacto de Métricas de QoS no Desempenho de Detectores Auto-gerenciáveis de Defeitos para Sistemas Distribuídos

Impacto de Métricas de QoS no Desempenho de Detectores Auto-gerenciáveis de Defeitos para Sistemas Distribuídos 742 Anais Impacto de Métricas de QoS no Desempenho de Detectores Auto-gerenciáveis de Defeitos para Sistemas Distribuídos Alirio Santos de Sá 1, Raimundo José de Araújo Macêdo 1 1 Laboratório de Sistemas

Leia mais

Claudivan C. Lopes claudivan@ifpb.edu.br

Claudivan C. Lopes claudivan@ifpb.edu.br Claudivan C. Lopes claudivan@ifpb.edu.br Por que redes de computadores? Tipos de redes Componentes de uma rede IFPB/Patos - Prof. Claudivan 2 Quando o assunto é informática, é impossível não pensar em

Leia mais

Revista Perspectiva em Educação, Gestão & Tecnologia, v.3, n.5, janeiro-junho/2014

Revista Perspectiva em Educação, Gestão & Tecnologia, v.3, n.5, janeiro-junho/2014 GERENCIAMENTO E ALTA DISPONIBILIDADE EM ARMAZENAMENTO DE BANCO DE DADOS Fabio dos Santos Canedo Gustavo César Bruschi Luis Alexandre da Silva Vitor de Oliveira Teixeira FATEC Bauru - SP e-mail: vitor.teixeira2@fatec.sp.gov.br

Leia mais

Capítulo 8. Sistemas com Múltiplos Processadores. 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos

Capítulo 8. Sistemas com Múltiplos Processadores. 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos Capítulo 8 Sistemas com Múltiplos Processadores 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos 1 Sistemas Multiprocessadores Necessidade contínua de computadores mais rápidos modelo

Leia mais

Profs. Deja e Andrei

Profs. Deja e Andrei Disciplina Sistemas Distribuídos e de Tempo Real Profs. Deja e Andrei Sistemas Distribuídos 1 Conceitos e Projetos de Sistemas Distribuídos Objetivos: Apresentar uma visão geral de processamento distribuído,

Leia mais