Tcnicas e Mecanismos de Atualizao Dinmica

Eduardo Cmara
23 de junho de 2011

Monografia da disciplina de seminrios de sistemas distribudos

Proposta
Esse trabalho tem o objetivo de apresentar algumas tcnicas e mecanismos de atualizao
dinmica abordados pela academia e compar-los em dois quesitos: localidade da atualizao e a
natureza da evoluo.

1. Introduo
Muitos sistemas de software nos dias de hoje precisam ficar disponveis durante 24 horas por
dia nos 7 dias da semana por diversos motivos: misso crtica, perda de receita para os negcios,
inconvenincia para o usurio e etc. Junto da necessidade de sempre estar disponvel, alguns softwares
esto em constante atualizao seja para corrigir bugs, introduzir novas funcionalidade ou otimizaes.
O conjunto dos softwares que esto em constante evoluo e mesmo assim precisam ficar disponveis o
tempo todo inspiram pesquisas de tcnicas e mecanismos de atualizao dinmica.
Atualizaes normalmente so feitas de duas maneiras: esttica e dinmica. A atualizao
esttica o mtodo tradicional de atualizao: a execuo do software interrompida, a aplicao da
atualizao feita e depois a execuo do software reiniciada. Atualizaes dinmicas permitem que
os sistemas sejam atualizados sem interromperem a execuo dos seus servios, aplicando a atualizao
em tempo de execuo.
Ao analisarmos as tcnicas e mecanismos de atualizao dinmica verificamos alguns desafios
comuns entre elas como apresentado em [8]:
1. Qual o melhor momento para atualizar?.................................................................................
Escolher o melhor momento para atualizar no tarefa fcil. Uma atualizao, dependendo
da granularidade, pode alterar um determinado mtodo F e caso F estiver em execuo
durante a atualizao difcil prever o comportamento esperado. necessrio ter cuidado
para no gerar inconsistncia no software que est sendo executado. Alguns autores [9]
sugerem a procura por um estado quiecente, um estado calmo, em que a parte que vai ser
atualizada no est sendo executada. Outros autores [6] definem safe-points que so
marcaes internas aonde o sistema indica em seu cdigo fonte qual seriam os pontos
seguros para se aplicar uma atualizao.
2. Como tratar chamadas durante a atualizao?...........................................................................
Como tratar chamadas durante a atualizao algo delicado. De acordo com o objetivo da
tcnica diversos caminhos podem ser traados: a execuo do software pode ficar suspensa;
as chamadas podem ser redirecionadas para outro lugar; as chamadas podem ser
armazenadas para uma futura execuo; ou as chamadas podem ocorrer normalmente caso
no forem afetadas pela atualizao.
3. O que fazer com o estado do software?.....................................................................................
preciso considerar se o estado do software importante ou pode ser ignorado. No caso de
ser importante preciso que na aplicao da atualizao o novo estado reflita as
informaes do estado antigo.
4. Como tratar alteraes de interface ou comportamento?.........................................................
Se o mecanismo permite alguma mudana no comportamento ou na interface do software,
necessrio tratar possveis mudanas na utilizao da parte atualizada. No caso da
atualizao alterar a interface ou comportamento de um pedao do software, preciso
alterar todos os cdigos clientes desse pedao ou ento tratar essa possvel
incompatibilidade.
Alguns objetivos comuns e prioritrios dessas tcnicas e mecanismos so explicitados em [6]:
1. Facilidade de uso.........................................................................................................................
Como os autores apresentam em [2], os principais problemas de atualizao so
representados por erros de configurao e erros no procedimento de atualizao.
Facilitando o uso evitaria erros no processo de atualizao e erros de configurao.
2. Robustez.
Utilizar mecanismos automticos para verificar e validar a atualizao afim de evitar erros
na atualizao seria perfeito, mas em alguns casos essa verificao pode ser um problema
NP-Completo [10].
3. Baixa sobrecarga de processamento.........................................................................................
O impacto do mecanismo deve ser o menor possvel no desempenho do sistema para
viabilizar o uso mesmo em sistemas de misso crtica.
4. Flexibilidade.
Possibilitar a atualizao de qualquer parte do software em execuo.

Tendo em vista os desafios encotrados pelas tcnicas e mecanismos, vamos avaliar alguns
trabalhos usando os critrios: localidade da atualizao; e natureza da evoluo.
O primeiro quesito identifica se o componente de software a ser atualizado acessado
localmente (no mesmo espao de endereamento do cliente) ou remotamente. J o segundo quesito
identifica se a evoluo do componente de software atualizado quebra a compatibilidade, no caso de
quebrar a compatibilidade existem dois cenrios que apareceriam: a evoluo dependente e a evoluo
idepentende. A evoluo dependente consiste na atualizao sncrona de todos os componentes que
seriam afetados pela quebra de compatibilidade gerada pela atualizao. A evoluo idependente
ocorre no caso em que a atualizao de todos os componentes afetados no possa ocorrer no mesmo
instante.
interessante analisar a localidade da atualizao para verificar como escolhido o melhor
momento para atualizar e se definido um isolamento do componente que vai ser atualizado. O
interessante na natureza da evoluo verificar qual como tratada quebra da compatibilidade e o
possvel protocolo utlizado para tratar a atualizao sincrona ou assncrona dos clientes do componente
atualizado.
Essa monografia apresenta alguns trabalhos na rea de atualizao dinmica e faz uma anlise
comparando esses trabalhos nos quesitos apresentados. No captulo 2 eu apresento as tcnicas e
mecanismos estudados e no captulo 3 uma anlise e concluso.
2.Tcnicas e Mecanismos de Atualizao Dinmica
Ginseng ( DSU ) [7]
O Ginseng um mecanismo composto de 3 entidades: um compilador, um gerador de patches e
um sistema de execuo. Para comear o programa tem uma verso inicial, v0.c, ento o compilador
gera um executvel atualizvel, v0, junto com alguns meta dados dessa verso inicial, d0. Primeiro o
programa na verso 0 comea a ser executado. Quando o programa muda para uma nova verso, v1.c, o
programador fornece o cdigo novo, v1.c , o cdigo antigo, v0.c , e os meta dados da verso em
execuo, d0 , para o gerador de patches que gera o patch , p1.c, que representa as diferenas entre as
verses. O patch criado, p1.c, enviado junto com os meta dados da verso em execuo, d0, para o
compilador que gera um patch dinmico para que o sistema de execuo carregue o patch dinmico no
programa em execuo completando a atualizao dinmica.

Figura 1: Processo de Atualizao do Ginseng
A escolha do momento certo em que o sistema de execuo ir carregar o patch dinmico
delegada aos programadores da aplicao, esses momentos so definidos como pontos seguros (safe-
points). O Mecanismo disponibiliza uma primitiva DSU_Update() que representa uma tentativa de
atualizao caso exista um patch a ser aplicado no sistema. Os autores avisam que tratamento de sinais
pode ser utilizado para forar uma atualizao a qualquer momento, mas advertem que pode haver
inconsistncia caso a atualizao altere alguma funo que esteja sendo executada.

Figura 2: Atualizao de uma funo B no Ginseng.
A granularidade das atualizaes no ginseng bem pequena visto que atualizaes so aplicadas
a mdulos individualmente e podemos alterar funes e tipos estruturados. Com essa granularidade
existe a possibilidade de alterarmos um mtodo, incluindo um novo parmetro, caso acontea isso os
cdigos que utilizam esse mtodo precisam tambm ser alterados para incluir o novo parmetro ou
pode haver alguma inconsistncia no sistema. Logo vemos que no caso do Ginseng a evoluo
depentende, aonde pode haver alterao em interface mas precisa ocorrer uma atualizao sncrona de
todos os clientes que sero impactados por essa alterao.
JVOLVE [3]
Bem similar ao Ginseng (DSU), o JVOLVE, atualiza o sistema em execuo atravs de patches
gerados com diff entre o cdigo da verso nova e o cdigo da verso antiga. O Mecanismo utiliza a
ferramenta UPT (Update Preparation Tool) para gerar os patches que sero aplicados no sistema. No
JVOLVE os autores estenderam uma mquina virtual Java (Jikes RVM) programada em Java para permitir
adicionar, editar e remover classes, mtodos, campos e alterar definies de interfaces de classes e
mtodos. A nica restrio de alterao que o JVOLVE tem a permutao na hierarquia das classes.
Assim como o Ginseng, o JVOLVE, utiliza o modelo de pontos seguros (safe-points) porm ele tenta
inferir quais seriam os pontos seguros da aplicao.
O JVOLVE entende como ponto seguro quando a mquina virtual no est executando nenhum
mtodo restrito, e mtodo restrito podem ser identificados pelos casos a seguir: mtodos alterados na
atualizao e mtodos especificados pelo usurio.

Figura 3: Processo de Atualizao do JVOLVE.
Ao gerar os patches de atualizao a mquina virtual espera um ponto seguro(safe-point),
quando esse ponto seguro encontrado, a mquina virtual dispara o coletor de lixo(garbage collector) e
aplica todas as modificaes necessrias para a atualizao. Assim como o ginseng a evoluo proposta
pelo JVOLVE dependente e toda alterao de interface gera uma atualizao sincrona dos clientes.
Figura 4: Atualizao de uma Classe no JVOLVE.
Imago [2]
Os autores do Imago apresentam o mecanismo como uma sada para atualizar dinamicamente e
evitar os erros de configurao e erros no procedimento de atualizao. Para alcanar isso o Imago
consiste em instalar a nova verso em um universo paralelo(U
new
, uma coleo de recursos diferente da
utilizada pela verso nova, seja com hardware diferente ou atravs de virtualizao) e transferindo os
dados persistidos, oportunisticamente, para a nova verso(U
new
). O mecanismo foi projetado para isolar
o sistema em produo(U
old
) da atualizao(U
new
). Quando a sincronizao os dados persistidos do
universo novo(U
new
) com o universo antigo(U
old
) termina, o Imago faz a transio do universo
antigo(U
old
) para o universo novo(U
new
).

Figura 5: Processo de Atualizao do Imago.
O Mecanismo assume alguns pontos bem fortes:
1. Pontos de Ingresso(I) e Egresso(E) fixos e conhecidos...................................................................
Com isso verificamos que nesse caso a ele s permite evoluo compatvel pois no h alterao
no ponto de entrada e sada do componente. Com a criao de outro universo e o interceptador
HTTP, podemos classificar o Imago no quesito localidade da atualizao como um remota.
2. A Carga de trabalho do sistema baseada na sua maioria em requisies de leitura
3. O Sistema prov ganchos para descarregar atualizaes em andamento e mecanismos para ler
objetos de dados armazenados no universo antigo(U
old
) sem atrapalhar o fluxo natural.
De acordo com os autores os pontos fortes do Imago so: Isolamento; Atomicidade e Fidelidade. O
isolamento obtido atravs do universo paralelo(U
new
) criado para a nova verso, assim a atualizao
no interfere na verso que est em execuo(U
old
). A atomicidade obtida pois como o sistema
baseado na sua maioria em requisies de leitura, o sistema consegue sincronizar todo os dados
persistidos e fazer o chaveamento do universo antigo(U
old
) para o universo novo(U
new
) e no ter as duas
verses rodando ao mesmo tempo. A Fidelidade feita com um estado de teste, quando os dados so
sincronizados o sistema vai para o estado de teste que ele pode utilizar tanto uma carga de teste
preparada ou as chamadas reais do sistema para comparar a saida gerada pelo universo antigo(U
old
)
com o universo novo(U
new
) e ver se a atualizao fiel ao sistema antigo.

Figura 6: Processo de chaveamento do Imago
O Imago assume que os dados persistidos representam o estado do sistema e que ele a nova
verso no precisa de nenhuma outra informao do sistema. A implementao do Imago consiste em 4
principais mdulos: Update driver, responsvel por transferir dados do universo antigo(U
old
) para o
universo novo(U
new
); Compare Engine que compara as saidas geradas na fase de testes; E interceptor,
que monitora o log do banco de dados para a sincronizao dos estados; e o I interceptor, que
intercepta as chamadas para o sistema.
Upstart [4]
O Upstart uma tcnica de atualizao dinmica cujo principal objetivo prover tolerncia a
falha para os objetos do sistema. Os autores caracterizam o sistema distribudo como uma coleo de
objetos que se comunicam atravs de RPC (Remote Procedure Call). A atualizao envolve seis
componentes: oldClass, a verso antiga do objeto a ser atualizado; newClass, a verso nova do objeto;
TF, uma funo de transformao que gera o estado da verso nova a partir do estado da verso velha;
SF, uma funo de agendamento que identifica o momento certo de aplica a atualizao; pastSO, um
objeto que d suporte a uma verso antiga do objeto; e futureSO, um objeto que d suporte a uma
verso futura do objeto. Caso o estado do objeto no seja importante, a funo de transformao pode
ser omitida. Se o Sistema no permite suporte a verses passadas ou futuras, os objetos de simulao
podem ser omitidos tambm.
Os objetos de simulao que do suporte a verso passada e a verso futura so simplesmente
objetos que adaptam a chamada dos mtodos e delegam a execuo para a verso certa no caso de
haver uma atualizao que altere a interface do objeto. O Sistema insere um proxy que recebe todas as
chamadas para aquele objeto, idependente de verso o objeto s possui 1 ponto de entrada. Todas as
chamadas de objetos so rotuladas com a verso, assim o proxy consegue identificar se deve enviar para
um objeto de simulao ou se deve enviar para o objeto real.
Um mtodo de atualizao ocorre da seguinte maneira: No incio existe um objeto na verso 1.
Ao iniciar o processo de atualizao instalado um objeto de simulao futuro para tratar chamadas
para a verso 2, aps o trmino da atualizao criado um objeto de simulao passado para tratar
chamadas a verso 1 e a verso do objeto chaveada da 1 para a 2.

Figura 7: Processo de Atualizao do Upstart
O Modelo ainda permite que suporte a verses antigas sejam desligados de acordo com a
necessidade do administrador do sistema. Com os mecanismos de objetos futuros e passados, o sistema
consegue dar suporte a diferentes verses do mesmo objeto mesmo se a interface do mesmo for
alterada sem precisar atualizar todos os clientes que utilizam ele. Com isso percebemos que essa tcnica
permite uma evoluo independente.
PKUAS [5]
O PKUAS se baseia em uma gerncia de verso em tempo de execuo, para isso todas as
chamadas possuem dois campos necessrios: a verso do componente; e uma flag que indica se a
verso necessria. Assim como no Upstart todo componente s possui um ponto de entrada,
idependente de verso, definido como Skeleton. Ao receber uma chamada o Skeleton do componente
encaminha essa chamada para a verso correspondente.

Figura 8: Gerncia de verso em tempo de execuo do PKUAS
O PKUAS possui dois mtodos de atualizao possveis:
1. Atualizao forada.....................................................................................................................
Nessa poltica, todas as instancias do componente sero atualizadas instantaneamente e no
final todas as verses antigas sero destruidas. Para componentes em que o estado no
importa, as chamadas em andamento continuam em execuo, as novas chamadas so
bloqueadas e quando as chamadas em andamento terminarem todas as instancias da
verso antiga so destruidas e a verso nova inicia a execuo. Para compoenentes em que
o estado no pode ser ignorado o mecanismo espera o estado quiescente que pode ser
definido pelo usurio no ciclo de vida do componente durante a implementao. Quando o
estado alcanado, utiliza uma funo de transformao para recuperar o estado do
componente na verso antiga e gera o estado da verso nova. Ento todas as instncias das
verses antigas so destruidas e a verso nova inicia a execuo.
2. Atualizao gradual.....................................................................................................................
Nessa poltica, todos as instancias do componente continuam rodando sem afetar os seus
clientes. Chamadas de verses antigas so direcionadas para verses antigas. Quando uma
chamada para uma verso nova ocorrer, a chamada encaminhada para a verso nova.
Adminsitradores do sistema podem desligar verses antigas quando elas no esto
executando chamadas.
Um detalhe interessante no PKUAS o flag enviado pelo cliente que identifica se a verso
necessria ou no. Caso a verso no seja necessria e no esteja em funcionamento a verso mais nova
que for compatvel com aquela chamada responde e envia para o cliente a verso que respondeu aquela
chamada, ento o cliente pode tomar a deciso de atualizar ou no o seu cdigo. Com isso verificamos
que o PKUAS da suporte a evoluo idependente.
Se existe ou como feito o sincronismo de estado entre diferentes verses que esto em
execuo, os autores no explicam.
3. Anlise e Concluso
Analisando a Localidade da atualizao:
No Ginseng aonde a atualizao dinmica feita por mdulos fica complicado para a tcnica ou
mecanismo identificar automaticamente quando que o mdulo no est sendo usado e pode ser
atualizado sem causar inconsistncia no sistema. Logo o mecanismo delega ao usurio a tarefa de
identificar os pontos seguros para atualizar.
No JVOLVE o mecanismo procura automaticamente o melhor momento para atualizar, para isso
ele identifica mtodos restritos que so os mtodos que no podem estar em execuo quando a
atualizao ocorrer. Apesar do mecanismo marcar os mtodos que esto sendo atualizados como
restrito, ele ainda necessita que o usurio marque outros mtodos que no esto sendo atualizados mas
so restritos para garantir que no ocorrer inconsistncia.
Ambos o Ginseng e o JVOLVE tratam com atualizao dinmica em componentes locais.
O Imago assume uma carga baseada somente em leitura, com isso ele pode fazer a transio da
verso antiga para a verso nova quando o estado das duas estiverem sincronizados. Com o
interceptador de requisies HTTP (I) ele tambm pode identificar se existem chamadas em andamento
e esperar elas terminarem para chegar a um estado quiescente.
Cada objeto no Upstart possui somente um ponto de entrada, assim como o Imago ele consegue
identificar se existem chamadas em andamento e achar o estado quiescente automaticamente. Porm
fica complicado quando o objeto nunca chega no estado quiestence. Ento alm disso ele permite que o
usurio fornea uma funo de agendamento (SF) que identifica o estado ao invs do sistema inferir
quando deve atualizar.
O PKUAS como o Upstart possui um nico ponto de entrada que o Skeleton do componente,
ele bloqueia as chamadas quando a atualizao forada e espera as chamadas em execuo
terminarem.
O Imago, Upstart e o PKUAS tratam com atualizao dinmica em componentes remotos.
Analisando a Natureza da atualizao:
O Ginseng permite alterar mtodos e tipos estruturados de C, mas para que o sistema no fique
inconsistente todo cdigo que utiliza os mtodos e os tipos estruturados que forem alterados precisam
ser atualizados. Logo o Ginseng possibilita uma Evoluo dependente pois precisa efetuar uma
atualizao sincrona em todo o cdigo cliente.
O JVOLVE tambm funciona como o Ginseng, porm permite adicionar, editar e remover
classes, mtodos, campos e alterar definies de interfaces de classes e mtodos. Mas para evitar
inconsistncia tambm precisa efetuar uma atualizao sincrona em todo o cdigo cliente.
Tanto o Ginseng e o JVOLVE permitem Evoluo Dependente.
O Imago no permite que o ponto de entrada, o ponto de sada e o comportamento do sistema
mude. Ele utiliza isso para verificar a fidelidade do sistema atualizado. Logo o Imago s permite Evoluo
Compatvel.
O Upstart
O PKUAS
Ambos Upstart e PKUAS permitem Evoluo Indepentente.

Tabela 1: Classificao
Tcnica ou Mecanismo Localidade da atualizao Natureza da evoluo
Ginseng (DSU) Local Evoluo Dependente
JVOLVE Local Evoluo Dependente
Imago Remota Evluo Compatvel
Upstart Remota Evoluo Independente
PKUAS Remota Evoluo Independente

Concluso
Ambos o Ginseng e o JVOLVE tratam com atualizao dinmica local. Os dois mecanismos
possuem um sistema de execuo, no Ginseng o sistema de execuo responsvel por aplicar o patch
dinmico e no JVOLVE o sistema de execuo a mquina virtual alterada, esse sistema de execu


4. Referncias
[1] T. Dumitra, E. Tilevich and P. Narasimhan. To Upgrade or Not to Upgrade: Impact of Online
Upgrades across Multiple Administrative Domains. ACM Onward! Conference, Oct. 2010
[2]T. Dumitras and P. Narasimhan. Why Do Upgrades Fail And What Can We Do About It? Toward
Dependable, Online Upgrades in Enterprise Systems. ACM/IFIP/USENIX Middleware Conference, Nov.-
Dec. 2009 (LNCS 5896)
[3] S. Subramanian, M. Hicks and K. S. McKinley. Dynamic software updates: A VM-centric approach.
ACM Conference on PLDI, pages 1-12, Jun 2009
[4] S. Ajmani, B. Liskov and L. Shrira. Modular software upgrades for distributed systems. ECOOP, Jul
2006.
[5] Z. Xiao, D. Cao, C. You, M. Zhou and H. Mei. Towards Dynamic Component Updating: A Flexible and
Lightweight Approach. 2009 33
rd
Annual IEEE International Computer Software and Applications
Conference, 2009.
[6] M. Hicks and S. Nettles. Dynamic software updating. ACM Transactions on Programming Languages
and Systems (TOPLAS), 27(6):1049-1096, Nov 2005.
[7] I. Neamtiu, M. Hicks, G.Stoyle and M. Oriol, Pratical dynamic software updating for C, in Proc. PLDI,
June 2006, pp. 72-83.
[8] R. Taylor, N. Medvidovic and P. Oreizy. Architectural styles for runtime software adaptation. Joint
Working IEEE/IFIP Conference on Software Architecture & European Conference on Software
Architecture, 2009.
[9] J. Kramer and J. Magee The evolving philosophers problem: dynamic change management, IEEE
Trans. Softw. Eng., vol. 16, no. 11, pp. 1293-1306, Nov. 1990.
[10] R. Di Cosmo. Report on formal management of software dependencies. Technical report, INRIA
EDOS Project Deliverable WP2-D2.1), Sep 2005.