Processamento Confiável no Amoeba
Transcrição
Processamento Confiável no Amoeba
Processamento Confiável no Amoeba Maysa Gomes Trindade Longo da Silva Francisco Vilar Brasileiro Laboratório de Sistemas Distribuídos - LSD Departamento de Sistemas e Computação - DSC Universidade Federal da Paraíba - UFPb/Campus II Av. Aprígio Veloso, 882 58109-970, Campina Grande - Pb E-mail: [email protected], [email protected] Em um sistema distribuído, falhas físicas podem ocorrer tanto no hardware que provê a infra-estrutura de processamento, quanto naquele que provê a infra-estrutura de comunicação. Diversos mecanismos foram desenvolvidos, sob uma variedade de ambientes, para garantir o tratamento e a tolerância a esses tipos de falhas. Quando a implementação destes mecanismos está a cargo da aplicação, a complexidade desta cresce. De fato, um dos principais problemas no projeto e implementação de aplicações distribuídas, reside justamente na dificuldade introduzida pela necessidade de se tratar e tolerar falhas. A complexidade dos mecanismos para tolerância a falhas reflete as considerações feitas sobre a semântica de falha do hardware onde a aplicação executa. Quanto mais restritiva a semântica de falhas do hardware, mais simples será a implementação dos mecanismos para tolerância a falhas. Levando-se essa consideração ao extremo, se o hardware nunca falha, não há necessidade de incorporar à aplicação quaisquer mecanismos para tolerância a falhas. Infelizmente, todo componente de hardware tem uma vida útil finita, e irá falhar, possivelmente de uma maneira imprevisível. A abordagem tomada pelos projetistas de um considerável número de sistemas distribuídos apresentados na literatura, é construir os sistemas assumindo que a infra-estrutura de hardware possui uma semântica de falha controlada, ou seja, apresenta uma semântica de falha bem definida e previsível. A semântica de falha do hardware, por sua vez, depende, não somente das características do hardware propriamente, mas também, entre outros fatores, dos requisitos de confiabilidade exigidos pela aplicação e da duração da execução da aplicação (tempo de missão). Embora tenha-se conhecimento que processadores convencionais podem falhar de uma maneira arbitrária, a probabilidade desse tipo de falha ocorrer é tão pequena, que é possível assumir uma semântica de falha controlada para estes processadores, e ainda assim, atender aos requisitos de confiabilidade de um grande número de aplicações. Entretanto, para um crescente número de aplicações, os requisitos de confiabilidade são tão altos, que não é possível assumir que processadores convencionais apresentem semântica de falha controlada. Para essas aplicações, faz-se necessário construir unidades de processamento (nodos), que, de fato, apresentem a semântica de falha requerida. Muitos sistemas tolerantes a falhas descritos na literatura, foram construídos assumindo que eles executam em nodos que falham de forma segura, ou seja, o nodo quando falha, pára, ao invés de realizar uma transição não especificada. Dois tipos de nodos representativos desta classe de nodos com falha controlada são os nodos com falha estável e os nodos com falha silenciosa. Outros sistemas assumem que os nodos nunca falham, desta forma eles devem executar em nodos que possam garantir esse comportamento por todo o tempo de missão da aplicação. Nodos que mascaram falhas formam uma outra classe de nodos com falha controlada, que são capazes de oferecer um serviço correto, com uma probabilidade arbitrariamente alta. Nodos com falha controlada podem ser construídos através do agrupamento de processadores convencionais redundantes, que falham de maneira independente. A computação é replicada e executada simultaneamente em cada um dos processadores formando um nodo. Os resultados da computação de cada um dos processadores são avaliados por um mecanismo apropriado (ex. comparação, votação majoritária, etc.) que garante a semântica de falha do nodo. Em [1] é apresentado uma forma eficiente de se construir diversos tipos de nodos com falha controlada, implementados por software. Diferentemente da abordagem tradicional de implementação por hardware, os nodos propostos em [1] não necessitam que os processadores tenham um comportamento determinista a cada ciclo de relógio, o que possibilita o uso de processadores convencionais. É possível, inclusive, utilizar-se processadores de diferentes fabricantes, o que permite a tolerância a falhas de projetos nos processadores. Além disso, a inexistência de mecanismos implementados por hardware, faz com que a atualização tecnológica desses nodos possa ser feita através de uma simples recompilação dos protocolos para a nova plataforma, obviando a necessidade (e o custo correspondente) do (re)projeto do sistema, obrigatório nas implementações por hardware. Na proposta descrita em [1], os protocolos são implementados por uma coleção de funções pertencentes a uma biblioteca, e que são ligadas ao código da aplicação. A aplicação então deve ser executada no número de processadores necessários para garantir o grau de confiabilidade requerido. Grande parte da gerência dos mecanismos para tolerância a falhas está a cargo do programador, o que além de ser trabalhoso, é susceptível à introdução de falhas de projeto. Esses problemas podem ser resolvidos, se o sistema operacional oferecer serviços que tornem esses mecanismos transparentes às aplicações. Sistemas operacionais distribuídos baseados em micro-núcleos fornecem a tecnologia ideal para a implementação destes mecanismos. O princípio básico dessa tecnologia é minimizar o tamanho da parte do sistema operacional que executa em modo supervisor (o micro-núcleo propriamente dito), com o objetivo de aumentar a flexibilidade do sistema. Todo o restante da funcionalidade do sistema operacional é provida por processos servidores que executam em modo usuário. Desta forma, os serviços providos por esses processos podem ser modificados/adaptados/configurados/etc. muito mais facilmente, atendendo às diferentes exigências das aplicações. A comunicação entre processos tem papel fundamental no funcionamento de micro-núcleos. Por conta disso, existe um cuidado especial no projeto desse serviço, e alguns micro-núcleos já oferecem serviços de comunicação com variado grau de confiabilidade. No entanto, esses sistemas praticamente não possuem serviços de processamento confiável, ou seja, o processamento é, no máximo, tão confiável quanto os nodos nos quais os sistemas executam. O Amoeba [3] é um exemplo de sistema operacional distribuído baseado em micro-núcleo. O micro-núcleo do Amoeba implementa apenas os serviços básicos de gerência de memória, processador e E/S, além de serviços de comunicação. O servidor de execução (Run Server) é o responsável pelo escalonamento de tarefas. O Run Server não provê nenhum mecanismo para tolerar falhas de processamento, ele simplesmente faz o balanceamento de carga de processamento para identificar quais processadores estão disponíveis para realizar determinada tarefa, levando em consideração parâmetros como a arquitetura de hardware, velocidade do processador, memória disponível, etc. Nossa proposta é estender a funcionalidade do Amoeba através da introdução de um servidor de processamento confiável, o FTRun Server, baseado nos protocolos de tolerância a falhas descritos em [1]. Aplicações executadas pelo FTRun Server podem, em tempo de execução, informar a semântica de falhas assumida para os nodos aonde irão executar (através de arquivos de configuração e/ou passagem de parâmetros). Por exemplo, uma aplicação poderá assumir que executará em nodos de falha silenciosa, e que o hardware falha de forma arbitrária. O FTRun Server deve então prover, de forma transparente, a semântica de falhas silenciosa a partir dos processadores com semântica de falhas arbitrária disponíveis. Além da introdução do FTRun Server, é necessário modificar o serviço de comunicação do micro-núcleo, de forma que este implemente as necessidades de comunicação dos protocolos de [1]. Quando a semântica de falha dos processadores disponíveis é pelo menos tão restritiva quanto a semântica de falha requerida pela a aplicação, o FTRun Server irá se comportar de forma semelhante ao Run Server. As principais vantagens da introdução do FTRun Server são: i) redução na complexidade de desenvolvimento de aplicações confiáveis, por aliviar o programador da carga de gerência dos mecanismos de tolerância a falhas; ii) flexibilidade de determinar em tempo de execução os requisitos de cada aplicação, os quais podem mudar ao longo do tempo, sem a necessidade nem mesmo de recompilação; iii) possibilidade de um maior controle da relação performance/confiabilidade em tempo de execução; e iv) distribuição do custo da tolerância a falhas proporcional aos serviços requeridos por cada aplicação. Este projeto está em fase de desenvolvimento no LSD/DSC da UFPb/Campus II como parte do projeto de pesquisa descrito em [2]. Referências [1] F. V. Brasileiro, "Constructing Fail-Controlled Nodes for Distributed Systems," Ph.D. Thesis, University of Newcastle upon Tyne, June 1995. [2] F. V. Brasileiro, "Implementando Aplicações Distribuídas Robustas Utilizando os Serviços para Tolerância a Falhas de Micro-núcleos Distribuídos", Projeto Individual de Pesquisa Submetido ao CNPq, fevereiro 1996. [3] S. J. Mullender, G. van Rossum, A. S. Tanenbaum, R. van Renesse, and H. van Staveren, "Amoeba A Distributed Operating System for the 1990s," IEEE Computer, Vol. 23, No. 5, pp 44-53, May 1990.
Documentos relacionados
Processamento Confiável no Ambiente Operacional Seljuk
semântica de falha requerida, liberando as aplicações desta tarefa. Além desses serviços, a plataforma também oferece outros serviços para tolerância a faltas, que podem ser usados pelos projetista...
Leia maisSeljuk : Um Ambiente para Suporte ao Desenvolvimento e à
componentes da infra-estrutura de execução [Cris91]. Neste trabalho, descrevemos a arquitetura do ambiente operacional Seljuk, cujo objetivo principal é facilitar o desenvolvimento e a execução de ...
Leia mais