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.