Towards Specification, Modelling and Analysis of Fault Tolerance in Self Managed Systems Jeff Magee Imperial College London, London, UK Tom Maibaum McMaster.

Apresentação em tema: "Towards Specification, Modelling and Analysis of Fault Tolerance in Self Managed Systems Jeff Magee Imperial College London, London, UK Tom Maibaum McMaster."— Transcrição da apresentação:

1 Towards Specification, Modelling and Analysis of Fault Tolerance in Self Managed Systems Jeff Magee Imperial College London, London, UK Tom Maibaum McMaster University, Hamilton, Ontario, Canada Vinicius Petrucci, IC/UFF julho, 2006

2 Introdução Modelagem e análise de mecanismos de tolerância a falhas em sistemas auto- gerenciáveis e auto-curáveis Especificação baseada em componentes, com mecanismos de coordenação –Construção de sistemas a partir dos componentes MAL (Modal Action Logic) + Operadores Deônticos –Formalismo para especificar comportamentos normais e anormais

3 Introdução Mecanismos de tolerância a falhas podem ser especificados em termos de: –Tipo de anormalidade encontrada –Caminho de recuperação desejado Modelos de programação abstratos –Especificações usando LTSA (ferramenta de modelagem baseada em álgebra de processo e máquina estados finitos) –Podem ser sistematicamente construídos a partir de um modelo de mais alto nível LTSA => permite verificação de propriedades em modelos (model checking)

4 Introdução Auto-gerenciamento (self management) –Capacidade do sistema/aplicação se recuperar de um comportamento anormal de forma autônoma, sem a intervenção externa Analogia a sistemas tolerantes a falhas –Reconhecer a ocorrência de situações anômalas (de certas categorias) –Prescrições para recuperação (parcial) dessas situações

5 Introdução Modelar tolerância a falhas, analisar tais modelos e implementar os modelos (via algoritmos de recuperação) –Ingredientes importantes para o entendimento de sistemas do tipo auto-gerenciáveis (self management) e auto-curáveis (self healing)

6 Modelagem Elementos chaves para especificação –Comportamento de componentes –Mecanismo de interação entre componentes (conectores e coordenação) –Configuração dos sistemas a partir de componentes e conectores –Caracterização de comportamento e estados considerados anormais

7 Método de Engenharia Passos principais: 1.Criar especificação baseada em arquitetura de software do sistema, baseada em requisitos bem definidos, incluindo mecanismos apropriados de tolerância a falhas (e auto-gerenciamento). Analisar a especificação. 2.Criar modelo LTSA da especificação (ou partes cruciais) como projeto intermediário. Analisar propriedades demonstrando que o modelo está de acordo com a especificação 3.Usar transformações para gerar programas a partir do modelo em alto nível. Analisar se o programa está de acordo com o modelo.

8 Método de Engenharia Muito trabalho ainda a ser feito para tornar essas idéias apropriadas Esse método se aplica para todo sistema onde é preciso distinguir entre comportamento normal e anormal Uma forma de caracterizar e analisar os mecanismos propostos, junto de possível padronização de implementação, via passos de modelagem e codificação Abordagem formal possui limitações práticas –Model checkers, como o LTSA –Provadores de teoremas

9 Modelo LTSA Concepção: processos – unidades de execução sequencial. Modelos: finite state processes (FSP) => para modelar os processos como sequências de ações (forma algébrica). labelled transition systems (LTS) => analisar, visualizar e simular comportamentos (forma gráfica). Prática: Threads Java

10 Modelo LTSA Modelo FSP de um sinal de trânsito: TRAFFICLIGHT = (red->orange->green->orange -> TRAFFICLIGHT). LTS gerado usando a ferramenta LTSA: Trace: red orange green orange red orange green …

11 Composição paralela (0,0)(0,1)(0,2)(1,2) (1,1)(1,0) from CONVERSE from ITCH 2 states 3 states 2 x 3 states

12 Interação - sincronização MAKE_A = (makeA->ready->used->MAKE_A). MAKE_B = (makeB->ready->used->MAKE_B). ASSEMBLE = (ready->assemble->used->ASSEMBLE). ||FACTORY = (MAKE_A || MAKE_B || ASSEMBLE).

13 CLIENT call request SERVER call replywait reply servicecontinue CLIENT = (call->wait->continue->CLIENT). SERVER = (request->service->reply->SERVER). ||CLIENT_SERVER = (CLIENT || SERVER) /{call/request, reply/wait}.

14 Exemplo O servidor principal faz copia de qualquer alteração feita pelo cliente em seu estado interno para o servidor secundário, antes de permitir ser executada qualquer outra operação Possível falha do servidor principal é dada por uma operação chamada failover –Tem o efeito de trocar os papeis dos servidores principal e secundário –Problema: se failover ocorrer depois de um write pelo principal e antes de um put no secundário

15 Exemplo

16 Abordagem usando MAL –Componente descrito em termos de memória local (atributos) e operações locais (ações) –Axiomas descrevem propriedades dos atributos e ações, assim como o efeito de ações sobre os atributos

17 component Client Attributes c_val:int, c_master:{a,b}, ready_to_write:bool, error:bool Actions c_init, c_write(int,c_master), c_read(int,c_master), switch, abort Axioms 1. [c_init](c_master=a ^ val=0 ^ ready_to_write ^ ¬error) 2. (ready_to_write ^ c_master=m ^ ¬error) [write(val,m)]¬ready_to_write 3. (¬ready_to_write ^ c_master=m ^ ¬error ^ val=x) [read(y,m)]((xy error) ^ (x=y (ready_to_write ^ val=x+1))) 4. c_master=a [switch]c_master=b 5. c_master=b [switch]c_master=a 6. ¬ready_to_write [switch](¬normal ^ Obl(abort)) 7. ¬normal [abort](ready_to_write ^ normal)

18 Exemplo ready_to_write: marca o fato de que um write ocorreu e um read agora precisa acontecer error: marca que um valor que foi lido não foi o último que foi escrito

19 component {a,b}.Server Attributes {a,b}.val:int, {a,b}.master:bool, {a,b}.updating:bool Actions {a,b}.init, {a,b}.write(int), {a,b}.read(int), {a,b}.put(int), {a,b}.get(int), {a,b}.failover Axioms 1. [a.init](a.master ^ ¬a.updating) (and for b.Server: [b.init](¬b.master ^ ¬b.updating) 2. (a.master ^ ¬a.updating) [a.write(val)](a.val=x ^ a.updating) 3. (a.master ^ a.updating) [a.put(val)]¬a.updating 4. a.master [a.failover]¬a.master 5. ¬a.master [a.get(x)]a.val=x 6. (For b.Server, we have axioms 2-5 with a replaced by b.)

20 Exemplo updating: se está no meio de uma transação write-put (write no servidor principal e put no secundário)

21 Coordenação Mecanismo de coordenação entre os componentes –Ações sincronizadas, como num envio de mensagens sincronizadas onde um envio feito por um componente é sincronizado com um recebimento em um outro Exemplo: ação switch do Cliente é sincronizada com a.failover em a.Server e com b.failover em b.Server

22 Coordenação Ações c_write(x,a) e c_read(x,a) do Cliente são sincronizadas com a.write(x) e a.read(x), respectivamente, em a.Server. –Analogamente para b.Server Servidores sincronizam a.put com b.get e vice-versa

23 Algumas Propriedades Se tudo ocorre bem, então normal é sempre verdade em Cliente e não temos um estado de erro (error). ( normal) ( ¬error) Se estamos num estado anormal, e nada mais de ruim acontece, em algum momento do futuro voltamos ao estado normal ¬normal ^ no_further_violation normal

24 Modelo LTSA LTSA (Labelled Transition System Analyzer) –Ferramenta de modelagem e verificação de sistemas representados por sistemas de transição –Sistema é modelado como um conjunto de processos descritos em FSP (Finite State Process), notação de álgebra de processo –Permite análise através de propriedades especificadas em lógica temporal linear fluente (FLTL)

25 Modelo LTSA const False = 0 const True = 1 range Bool = False..True range Int = 0..2 SERVER(M=0) = SERVER[M][0][0], SERVER[master:Bool][val:Int][updating:Bool] = ( when (master) write[v:Int]-> SERVER[master][v][True] | when (master && updating) put[val]-> SERVER[master][val][False] | when (master && !updating) read[val]-> SERVER[master][val][updating] | when (!master) get[u:Int]-> SERVER[master][u][updating] | failover -> SERVER[!master][val][False] ).

26 Modelo LTSA CLIENT = ({a,b}.write[v:Int] -> ({a,b}.read[u:Int] -> if (u != v) then ERROR else CLIENT| abort->ClIENT )). ||SYS = (a:Server(True) || b:Server(False) || CLIENT ) /{ a.put/b.get, b.put/a.get, failover/{a,b}.failover}.

27 Verificações Ação failover causa uma troca atômica do servidor principal para secundário, causando uma violação de consistência no Cliente Trace to property violation in CLIENT: a.write.1 failover b.read.0 Analysed in: 0ms

28 Verificações Ação failover causa uma troca atômica do servidor principal para secundário, causando uma violação de consistência no Cliente Trace to property violation in CLIENT: a.write.1 failover b.read.0 Analysed in: 0ms Como a troca é atômica, o estado como visto pelo cliente não é. Nesse caso, o cliente pode ler o estado do novo servidor principal antes de uma atualização ocorrer

29 Verificações Caracterizando a situação anterior em FLTL fluent UPDATING = assert BAD = (UPDATING && failover) UPDATING é verdade entre o ponto que uma ação write ocorreu mudando o estado do servidor principal e uma ação de put que registra a mudança no secundário –Se é verdade, então o sistema está num estado ¬normal

30 Verificações Proibir o sistema de entrar nesse estado, adicionando a seguinte restrição constraint NO_BAD = []! BAD ||CON_SYS = (SYS || NO_BAD). –O LTSA então gera um autômato para essa restrição

31 Verificações Uma alternativa é deixar o sistema entrar num estado ruim e então realizar alguma ação compensatória antes de o cliente colocar o sistema diretamente em um estado irrecuperável ERROR. constraint REC_BAD = [ ] (BAD -> X abort) || REC_SYS = (SYS || REC_BAD). –Se chegarmos ao estado BAD, então devemos imediatamente (próxima ação) abortar. –O operador Next (X) é usado para expressar a idéia de que uma ação de abort deve ser realizada antes de qualquer coisa

32 Conclusão Abordagem para modelagem e análise de mecanismos de tolerância a falhas (e auto- gerenciamento) em sistemas multicomponentes e distribuídos Formalismo de lógica modal de ação + operadores deônticos –Para descrever comportamentos normais e anormais Prover um modo sistemático de tornar essas especificações em (aproximados) modelos de programação abstratos