Rua Lauro Müller, 116 sala 3902 Rio de Janeiro, RJ Brasil

Transcrição

1 Migração e persistência heterogêneas de computações em Lua Anolan Milanés 1, Noemi Rodriguez 12, Renato Maia 1 1 Departamento de Informática Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) R. Marquês de São Vicente, 225 RDC Rio de Janeiro RJ Brasil 2 Rede Nacional de Ensino e Pesquisa (RNP) Rua Lauro Müller, 116 sala 3902 Rio de Janeiro, RJ Brasil {anolan,noemi,maia}@inf.puc-rio.br Abstract. The lack of support for heterogeneous capture and restoration of computations in most current programming languages makes of migrating or persisting computations heterogeneously a dificult problem. When available, this support is offered through ad-hoc solutions that are difficult to adapt to different requirements. This paper describes a work in progress related to the implementation of persistence and migration in a real Lua application by extending the Lua language with support for capturing and restoration of executions. Resumo. Migrar ou persistir computações em um ambiente heterogêneo é um problema difícil devido à falta de suporte à captura e restauração heterogêneas de computações na maioria das linguagens atuais. Quando oferecido, este suporte consiste em soluções ad-hoc e é difícil de adaptar a diferentes necessidades. Este artigo descreve um trabalho em curso relacionado a implementação de persistência e migração numa aplicação Lua real através de uma extensão à linguagem Lua com suporte a captura e restauração de computações. 1. Introdução Este artigo descreve um trabalho em curso dedicado à implementação de migração e persistência de computações em execução. O problema a resolver consiste em como produzir uma nova computação, como conseqüência de um procedimento de mobilidade ou persistência, cujo estado de execução seja equivalente ao da computação original (computação aqui se refere a uma execução, seja na forma de processos, threads, agentes móveis, ou registros de ativação). Este problema é difícil de resolver em ambientes distribuídos nos quais as plataformas de origem e destino possam ser diferentes. A maioria das linguagens de programação atuais não oferece o suporte para a captura e restauração do estado de execução que a implementação de migração e persistência heterogêneas de computações precisa (veja o survey [Milanés et al. 2008]). Para superar essa limitação, os programadores são forçados, no nível da aplicação, a usar truques que afetam a portabilidade ou o desempenho, ou ambos. Ao acrescentar funcionalidades a uma linguagem de programação de propósito geral, deve-se manter a simplicidade da linguagem e evitar redundâncias e conflitos, mas Trabalho parcialmente apoiado pelo Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq)

2 ao mesmo tempo suportar tantas aplicações quanto for possível, privilegiando a generalidade. O ideal é que a linguagem ofereça mecanismos flexíveis, e não políticas específicas. Assim, projetar uma nova linguagem ou acrescentar uma linguagem com construções que permitam a captura e restauração heterogêneas do estado de execução deveria implicar na busca de mecanismos flexíveis que permitam oferecer este suporte. Entretanto, não são comuns as linguagens de programação seqüenciais com suporte flexível à captura e restauração heterogêneas. Pelo contrário, ele é tradicionalmente oferecido através de mecanismos que seguem uma semântica predeterminada. Na maioria dos casos, se trata de implementações ad-hoc focadas para um determinado domínio de aplicação e que não permitem a manipulação da representação da execução no nível da linguagem. Acreditamos que o suporte das linguagens à captura e restauração heterogêneas de computações deva ser baseado na manipulação explícita da representação das estruturas básicas que definem o estado do programa. Oferecendo as primitivas necessárias para manipular o estado da computação, a linguagem permite construir procedimentos customizados de captura e restauração. A nossa abordagem se baseia em dois mecanismos que chamaremos de reificação e instalação das estruturas da linguagem. A API de reificação e instalação de execuções foi implementada como uma extensão de Lua 5.1 [Ierusalimschy 2006] chamada de LuaNua. Várias facilidades reflexivas de Lua já oferecem algum suporte para captura e restauração. LuaNua estende o conjunto de funcionalidades reflexivas de Lua através da modificação e extensão da biblioteca de depuração. O restante do artigo está organizado da seguinte forma. A seção 2 discute a nossa abordagem para o problema da migração e persistencia heterogêneas flexível de computações, assim como a API implementada em LuaNua. A seção 3 descreve o MPA, um servidor de aplicações de automação de processos que é o caso de uso apresentado neste trabalho. A última seção se dedica às conclusões. 2. LuaNua: reificação e instalação em Lua A nossa abordagem é baseada na combinação de operações de reificação e instalação. O termo reificação se refere à disponibilizar, ao programa que está executando, as estruturas de dados do interpretador [Friedman and Wand 1984]. Chamaremos de instalação a operação oposta, que consiste em instalar valores obtidos, através de operações de reificação, no espaço de memória. Ao oferecer acesso à representação de cada componente do estado de execução (através de reificação) e permitir instalar esta representação, a linguagem oferece os meios para executar a captura e restauração heterogêneas de computações. A reificação e instalação, quando baseadas em representações navegáveis e componíveis, resultam em ferramentas poderosas permitindo a implementação de diferentes políticas. Em uma representação navegável, cada entidade que a compõe pode ser alcançável a partir de alguma outra entidade. A componibilidade permite suportar diferentes granularidades: altas granularidades seriam construídas a partir de granularidades pequenas. A capacidade de manipular o estado no nível da linguagem que estas operações permitem é o que provê a flexibilidade da proposta, permitindo mudanças seletivas no comportamento do programa durante a execução da computação. Por outro lado, ao deixar o programador no controle de cada aspecto do procedimento se afeta a usabilidade, sobrecarregando ao programador e levando facilmente a erros [Kennedy 2004]. Espera-

3 se que a API reflexiva seja usada através de bibliotecas de mais alto nível que permitem uma certa customização para determinados conjuntos de aplicações, enquanto as primitivas oferecidas pela linguagem continuam acessíveis para aplicações ou propósitos mais específicos. Nesta proposta, o procedimento comumente chamado de serialização está dividido em dois passos. O primeiro consiste na reificação (e instalação) das estruturas da execução. O segundo passo, que chamaremos de serialização (e o procedimento inverso de de-serialização), consiste na conversão dos valores reificados numa string de bytes a ser transmitida pela rede ou persistida Breve introdução a Lua Lua é uma linguagem interpretada, procedural, dinamicamente tipada, baseada em protótipos e com coleta de lixo. Os valores Lua podem ser de tipo nil, boolean, number, string, table, function, thread, lightuserdata e userdata. O suporte para concorrência é oferecido através de co-rotinas, que implementam suporte para multithreading cooperativo. A transferência de controle está baseada nas primitivas resume/yield. As tabelas Lua implementam arrays associativos, indexados usando qualquer valor da linguagem, exceto nil. Closures e co-rotinas são valores de primeira classe em Lua. Apesar de Lua não oferecer suporte a serialização de co-rotinas, é possível reificar e instalar funções Lua representadas como strings de bytes. Entretanto, esta representação não é facilmente navegável e não é portável, podendo requerer tradução em caso das arquiteturas origem e destino serem diferentes. Lua permite a carga dinâmica de código fonte ou bytecode e oferece outras funcionalidades reflexivas, que incluem o acesso ao ambiente e ao nome das variáveis locais. O fato de ser uma linguagem interpretada garante portabilidade para a informação representada no nível da linguagem. A simplicidade da concorrência em Lua evita a necessidade de tratar problemas de sincronização. Ter as co-rotinas como valores de primeira classe permite o tratamento homogêneo de valores e execuções na serialização, já que as co-rotinas encapsulam execuções API As funcionalidades genéricas que formam parte da API oferecida são implementadas pelas funções content e install. O nosso modelo de reificação é baseado no uso da função content, que recebe um valor Lua como argumento, e retorna a representação da sua estrutura. Esta primitiva aceita um segundo parâmetro na reificação de co-rotinas que é o nível do registro de ativação. A instalação é provida pela primitiva install. Esta função recebe como argumento a representação e o tipo ou um valor do tipo a ser reconstruído. Da mesma forma que o content, install recebe um parâmetro nível na instalação de co-rotinas. Uma invocação à função install deve retornar um valor do tipo especificado, em caso de sucesso. Para poder manipular a representação interna das computações como dados na linguagem, precisamos de uma estrutura de dados que facilite a composição e navegação. As tabelas Lua satisfazem esse requisito, pois podem ser indexadas com qualquer tipo de dado, facilitando a construção da representação, e também podem ser percorridas. Os valores estruturados são reificados em LuaNua como tabelas Lua. Isto permite manipu-

4 lar facilmente os valores e construir as representações progressivamente sob controle do programador. A representação devolvida por content contém somente valores atômicos (numbers, booleans, strings), e referências a abstrações estruturadas (tables, functions, upvalues, prototypes, threads, userdata). Isto permite controlar a extensão do fecho transitivo. A operação de reificação de co-rotinas consiste em reificar todos os frames, um por um, permitindo maior controle ao programador, que pode não estar interessado na co-rotina toda. A reificação e instalação são operações simétricas. As informações que somente fazem sentido para a co-rotina inteira (por exemplo, o status) devem ser extraídas e incorporadas pelo usuário como parte dos procedimentos usando as funcionalidades oferecidas com esse objetivo. A instalação precisa ter a capacidade de modificar execuções correntes, e não somente criar novas computações. Isto é necessário nos casos em que somente algumas co-rotinas da aplicação são modificadas, pois a criação de uma nova co-rotina gera uma nova referência que não irá coincidir com o valor referenciado pelas outras entidades do programa. Por este motivo, o install deve receber como parâmetro a co-rotina sobre a qual será feita a instalação, e deverá ter a capacidade de modificar ou acrescentar o conteúdo de uma pilha qualquer. A transferência de controle (reinício da execução) depois da instalação pode ser executada através das primitivas resume/yield. A restauração do ponto de execução durante o processo de instalação usando LuaNua está baseado nos mecanismos de suspensão/reativação de co-rotinas Lua. 3. Caso de Uso: MPA O MPA é um ambiente de desenvolvimento e implantação de controle automatizado de alto-nível para processos industriais. Idealmente, o MPA é utilizado por engenheiros de processo com pouca ou nenhuma experiência em programação de computadores para definir procedimentos automatizados utilizando uma linguagem visual baseada na notação de fluxograma. O MPA é extensível através de funções Lua definidas no arquivo de préconfiguração, que podem ser chamadas pelos fluxogramas. Todo o controle realizado pelo MPA é feito através de um conjunto de pontos de controle disponibilizados pelo sistema supervisório do processo. Os pontos de controle são variáveis que possuem um nome único, denominado tag e assumem valores do processo, tais como o valor de leitura de um sensor ou a abertura de uma válvula. Os fluxogramas do MPA manipulam os equipamentos do ambiente automatizado escrevendo e lendo os valores desses pontos. Uma aplicação MPA consiste basicamente na definição de um conjunto de fluxogramas e da lista de pontos de controle dos equipamentos manipulados. Essa definição é feita num aplicativo cliente de desenvolvimento que envia a aplicação a um servidor de aplicações MPA que executa num computador do ambiente de automação que tem acesso ao sistema supervisório do processo. Idealmente, uma instalação de um servidor MPA executa aplicações por vários meses ou anos sem interrupções. Isso é importante, pois muitas aplicações se baseiam na monitoração lenta e contínua dos eventos do processo para otimizar a automação. Dessa forma, eventuais paradas do servidor MPA exigem que as aplicações reiniciem o que pode causar perda de informações ou demoras custosas devido à verificação do estado do processo antes do início do controle.

5 Neste estudo de caso, propomos um mecanismo de persistência e migração automática do módulo de execução de aplicações do servidor MPA. Tal recurso é essencial para minimizar os períodos de falta dos serviços oferecidos pelas aplicações MPA devido a eventuais falhas nas manutenções rotineiras dos equipamentos que executam o servidor MPA. Nas próximas seções são apresentadas algumas das características principais da implementação do módulo de execução de aplicações do servidor MPA e do recurso proposto para persistência e migração da sua execução Executor de Aplicações Toda a implementação do servidor de aplicações do MPA é escrita em Lua, o que garante portabilidade, flexibilidade e facilidade de extensão. Basicamente, o servidor MPA oferece uma interface de controle CORBA para o módulo de execução de aplicações, denominado executor. Neste trabalho, nos concentraremos na persistência e migração apenas do executor e não do servidor MPA como um todo. O executor pode ser dividido em cinco partes, conforme ilustrado na figura 1. Figura 1. Estrutura do Executor de Aplicações MPA. chama executa funções Escalonador de Corotinas Fluxogramas Pré- Configuração chama operações Base de Equipamentos herda definições acessa pontos Ponte de Comunicação O restante desta seção descreve o Escalonador de co-rotinas e os Fluxogramas, que estão diretamente relacionados com o procedimento de migração. Fluxogramas Conjunto de grafos que descrevem máquinas de estado que implementam os fluxogramas que compõem a aplicação. Cada elemento gráfico do fluxograma corresponde a um estado implementado por uma função Lua que é chamada quando o estado é atingido. A transição entre os estados é feita com chamadas de cauda, de forma que possam ocorrer inúmeras transições sem que a pilha de execução cresça demasiadamente. O código da listagem 1 ilustra uma implementação de construtores de três elementos de fluxos: fluxos que são chamados como funções (linhas 1 10); iteração sobre equipamentos de uma classe (linhas 11 20); e execução de comandos (linhas 21 27). Em seguida, um fluxo que abre todas as válvulas cadastradas é criado usando esses construtores (linhas 29 33). A linha 35 cria uma nova linha de execução (i.e. thread) para executar o fluxo AbrirValvulas. As ações desempenhadas em cada estado do fluxo geralmente incluem chamadas às funções da pré-configuração ou operações dos equipamentos cadastrados na base, assim como chamadas a outros fluxos ou criação de novas linhas de execução (i.e. threads).

6 Listagem 1. Exemplo de máquina de estado implementando fluxograma. 1 function Flow ( s e l f ) 2 return function (... ) 3 local vars = setmetatable ({},{ i n d e x = G }) 4 for i = 1, select ( #,... ) do 5 vars [ s e l f. params [ i ] ] = select ( i,... ) 6 end 7 s e l f. s t a r t ( vars ) 8 return vars [ s e l f. r e s u l t ] 9 end 10 end 11 function I t e r a t i o n ( s e l f ) 12 return function ( vars ) 13 for, valve in pairs ( s e l f. set ) do 14 vars [ s e l f. var ] = valve 15 s e l f. step ( vars ) 16 end 17 vars [ s e l f. var ] = n i l 18 i f s e l f. next then return s e l f. next ( vars ) end 19 end 20 end 21 function Command( s e l f ) 22 local a c t i o n = assert ( loadstring ( s e l f. a c t i o n ) ) 23 return function ( vars ) 24 setfenv ( action, vars ) ( ) 25 i f s e l f. next then return s e l f. next ( vars ) end 26 end 27 end A b r i r V a l v u l a s = Flow{ params={ ABT }, 30 s t a r t = I t e r a t i o n { set=valvulas, var= V, 31 step = Command { a c t i o n = [ [ ok = V : moverabertura (ABT ) ] ], 32 next = Command{ a c t i o n = [ [ p r i n t ( Valvula aberta?, ok ) ] ] } }, 33 next = Command { a c t i o n = [ [ p r i n t ( Valvulas abertas ) ] ] } } } Scheduler : s t a r t ( A b r i r V a l v u l a s, 100) i n i c i a f l u x o A b r i r V a l v u l a s. Escalonador de Co-rotinas Módulo responsável por controlar a execução das diferentes linhas de execução dos fluxos representadas por co-rotinas. Tipicamente, uma linha de execução de um fluxograma transita continuamente entre diferentes estados, sendo que em alguns deles ocorrem esperas, que causa a suspensão temporária da linha de execução. Nesses momentos, a linha de execução é suspensa e o escalonador fica responsável por selecionar uma outra cujo período de suspensão tenha expirado para que ela retome sua execução. O escalonador mantém registro do estado de todas as linhas de execução, incluindo os tempos de suspensão que ficam armazenados numa fila de corotinas suspensas. Os fluxos ficam em espera basicamente por duas razões: (a) esperar a reação de um equipamento, como o tempo de movimentação da válvula após o comando de mudança de abertura; (b) esperar pela reação do processo após uma atuação nos equipamentos de controle desse processo. Por exemplo, quando a injeção de gás na tubulação de extração de petróleo é aumentada com o intuito de diminuir a peso da coluna de óleo nessa tubulação, é necessário aguardar um tempo (geralmente algumas dezenas de minutos) para que essa atuação surta efeito antes de medir a pressão de surgência de óleo resultante Persistência do Estado A implementação da captura do estado de execução do módulo de execução de aplicações do servidor MPA pode ser implementada inserindo uma chamada à função de captura dentro do escalonador:

7 scheduler : r e g i s t e r ( c o r o u t i n e. create ( function ( )... scheduler : capture ( ) os. e x i t ( ) end ) ) Para facilitar a captura e reificação usamos uma biblioteca de mais alto nível (seriallib), evitando o acesso direto à API de reificação/instalação (veja a seção 2). Esta biblioteca Listagem 2. Função de reificação de uma biblioteca para facilitar o uso da API. 1 function save ( value, saved ) 2 local t t y p e = type ( value ) 3 i f t t y p e == number or t t y p e == s t r i n g or 4 t t y p e == boolean or t t y p e == n i l then 5 return value 6 end 7 i f saved [ value ] then return saved [ value ] 8 else 9 local s = {}; saved [ value ] = s 10 i f t t y p e == f u n c t i o n then 11 s. env = getfenv ( value ) 12 s. env= ( s. env = G and save ( s. env, saved ) ) or n i l 13 value = debug. content ( value ) ; 14 e l s e i f t t y p e == thread then 15 local i = 0 16 s. c i = {} 17 repeat 18 s. c i [ i ] = debug. content ( value, i ) 19 i = i u n t i l ( s. c i [ i 1]== n i l ) 21 value = s 22 e l s e i f 0 u t r o s valores end 25 for k, v in pairs ( value ) do 26 k = save ( k, saved ) 27 s [ k ] = save ( v, saved ) 28 end 29 return s 30 end 31 end em particular oferece funções para a reificação (save, ilustrada na listagem 2) e instalação profunda de valores Lua (rebuild, ilustrada na listagem 3). A função save devolve o fecho transitivo completo do valor e não leva o estado global (linha 12), que será re-vinculado no destino (linha 15). A reificação de valores é feita através de chamadas à função content da API (linhas 13,18). A reificação de valores atômicos devolve o próprio valor (linhas 3-5). A reificação de valores estruturados devolve tabelas que são percorridas (linha 25) para reificar recursivamente todos valores estruturados aninhados (linhas 26,27) segundo o tipo, retornando uma representação completamente reificada. Os valores reificados são armazenados na tabela saved de forma a serem processados somente uma vez (linha 7). A reificação de threads é feita percorrendo os registros de ativação da co-rotina até atingir um nível não válido (linhas 17-20). A chamada a save se insere no código da função de captura (scheduler:capture()) da seguinte forma: local dump = s e r i a l l i b. save ( s e l f, saved ) Na restauração (no destino) é construída uma nova instância do escalonador a partir do estado capturado, já reificado pela função rebuild. local i n s t a l l = s e r i a l l i b. r e b u i l d ( t ) i n s t a l l : run ( )

8 A função rebuild (veja a listagem 3) instala recursivamente (de dentro para fora, valores mais internos primeiro) a representação passada como parâmetro. A instalação é executada segundo o tipo (devolvido pela função type de Lua, linha 2) através de chamadas à função install da API (linhas 8,14). A instalação de valores estruturados precisa da instalação prévia dos valores aninhados da representação (linhas 7-13). A instalação de funções inclui a restauração do ambiente, que no caso do ambiente global é feita como comentado por revinculação (linha 15). A instalação de uma co-rotina consiste na criação de uma nova co-rotina (linha 5), a instalação de cada registro de ativação (linhas 6-9) e a mudança do status da co-rotina para suspensa (linha 11) de forma a permitir sua ativação. Listagem 3. Função de instalação de uma biblioteca para facilitar o uso da API. 1 function r e b u i l d ( t, r e g i s t e r ) 2 local t t y p e = type ( t ) i f t. t t y p e == thread then 5 value = debug. newthread ( ) 6 for i = # t. ci, 0, 1 do 7 t. c i [ i ] = r e b u i l d ( t. c i [ i ], r e g i s t e r ) 8 value = debug. i n s t a l l ( t. c i [ i ], value, 0) 9 end debug. s e t s t a t u s ( value, s ) ; 12 e l s e i f t. t t y p e == f u n c t i o n then 13 for k, v in pairs ( t ) do t [ k ] = r e b u i l d ( v, r e g i s t e r ) end 14 value = debug. i n s t a l l ( t, f u n c t i o n ) ; 15 setfenv ( value, t. env or G ) 16 e l s e i f 0 u t r o s valores end 19 return value 20 end 4. Considerações finais Este trabalho está focado na implementação de migração heterogênea em uma aplicação real para validar as funcionalidades oferecidas por uma extensão à Lua com mecanismos de reificação e instalação de computações. Esta extensão permite a implementação de diferentes aplicações que precisam da capacidade de manipular computações, como é o caso da migração e persistência de execuções. Referências [Friedman and Wand 1984] Friedman, D. P. and Wand, M. (1984). Reification: Reflection without metaphysics. In LFP 84: Proceedings of the 1984 ACM Symposium on LISP and functional programming, pages , New York, NY, USA. ACM. [Ierusalimschy 2006] Ierusalimschy, R. (2006). Lua.Org. Programming in Lua, Second Edition. [Kennedy 2004] Kennedy, A. J. (2004). Functional Pearl: Pickler combinators. Journal of Functional Programming, 14(6): [Milanés et al. 2008] Milanés, A., Rodriguez, N., and Schulze, B. (2008). State of the art in heterogeneous strong computation migration. Concurrency and Computation: Practice & Experience. Accepted for publication.