tendÊncias da pesquisa em sistemas distribuídos · externas (correio eletrônico, isdn, acesso a...

13
SBA: Controle & Automação, VoI. 1, NQ 4, pp. 264-276 TENDÊNCIAS DA PESQUISA EM SISTEMAS DISTRIBUíDOS Yves Deswarte INRIA - LAAS/CNRS 7, Avenue du Colonel Roche - Toulouse - FRANÇA Resumo Este trabalho visa descrever sucintamente as principais orientações da pesquisa sobre sistemas distribuídos e levantar tendências mais significativas para os proxlmos anos. São apresentadas as necessidades de suporte para aplicações distribuídas e os requisitos de qualidade 'destes serviços. O ciclo de vida de uma aplicação e as particularidades dos sistemas distribuídos em automação industrial são também objeto desta publicação. Research Trends in Distribllted Systems Abstract In this paper are briefly described the principal orientations on distributed systems researchs and the more relevant trends for next years. Support and quality requirements for distributed applications are also presented. At last, life cycle of such application and distributed system particularities in industrial manufacturing systems and process control are also addressed. A parte é dedicada aos suporte::; fornecidos às aplicações distribu!das: comunicações, modelos de aplicaçãg e sistemas operacionais. A terceira parte apresenta os serviços esperadQs do sistema distribuído, em partic4lar no que diz respeito à transparência da distribuição e à segurança de funcionamento. Cada vez que for possível, serão referenciados projetos de pesquisa ilustrando tendências, principalmente na na Europa (que o autor conhece melhor- ). primeira deste artigo histórico do distribuídos e e as direções razões as parte breve dos sistemas A apresenté;!. um tenta futuras. Este artigo visa descrever sucintamente as principais orientações da pesquisa sobre os sistemas distribuídos e levantar as tendências mais significativas para os próximos anos. 1. INTRODUÇÃO Os Sistemas Distribuídos são, desde alguns anos, o ponto de encontro de algumas disciplinas entre as mais ativas da informática: comunicações, redes, sistemas operacionais, linguagens, base de dados, controle de processos, modelização, tolerância a faltas, etc. Este fenômeno acompanha o desenvolvimento do mercado da informática distribuída que atinge um crescimento mundial da ordem de 75% ao ano (enquanto o mercado global da informática cresce somente 15% ao ano). 264

Upload: vuongkiet

Post on 09-Nov-2018

215 views

Category:

Documents


0 download

TRANSCRIPT

SBA: Controle & Automação, VoI. 1, NQ 4, pp. 264-276

TENDÊNCIAS DA PESQUISA EM SISTEMAS DISTRIBUíDOS

Yves Deswarte

INRIA - LAAS/CNRS7, Avenue du Colonel Roche

31~77 - Toulouse - FRANÇA

Resumo

Este trabalho visa descrever sucintamente as principais orientações

da pesquisa sobre sistemas distribuídos e levantar tendências mais

significativas para os proxlmos anos. São apresentadas as necessidadesde suporte para aplicações distribuídas e os requisitos de qualidade 'destes

serviços. O ciclo de vida de uma aplicação e as particularidades dos

sistemas distribuídos em automação industrial são também objeto destapublicação.

Research Trends in Distribllted Systems

Abstract

In this paper are briefly described the principal orientations on

distributed systems researchs and the more relevant trends for next

years. Support and quality requirements for distributed applications are

also presented. At last, life cycle of such application and distributedsystem particularities in industrial manufacturing systems and process

control are also addressed.

A §~gunda parte é dedicada aossuporte::; fornecidos às aplicaçõesdistribu!das: comunicações, modelos deaplicaçãg e sistemas operacionais.

A terceira parte apresenta os serviços

esperadQs do sistema distribuído, empartic4lar no que diz respeito àtransparência da distribuição e à segurançade funcionamento.

Cada vez que for possível, serãoreferenciados projetos de pesquisa

ilustrando ~stas tendências, principalmente

na Franç~ ~ na Europa (que o autor conhecemelhor- ).

primeira deste artigohistórico dodistribuídos e

e as direçõesrazõesas

partebreve

dos sistemas

Aapresenté;!. um

desenvol.vim~nto

tenta l~vªntar

futuras.

Este artigo visa descreversucintamente as principais orientações da

pesquisa sobre os sistemas distribuídos e

levantar as tendências mais significativaspara os próximos anos.

1. INTRODUÇÃO

Os Sistemas Distribuídos são, desde

alguns anos, o ponto de encontro de algumasdisciplinas entre as mais ativas da

informática: comunicações, redes, sistemas

operacionais, linguagens, base de dados,controle de processos, modelização,tolerância a faltas, etc. Este fenômenoacompanha o desenvolvimento do mercado dainformática distribuída que atinge um

crescimento mundial da ordem de 75% ao ano(enquanto o mercado global da informática

cresce somente 15% ao ano).

264

A quarta parte descreve o ciclo de

vida de uma aplicação distribuída e as

ferrar"entas e métodos que lhe são

associados: concepção, realização, operação.

homogêneas (fechadas = "propl~ietár.ias" ): na

IBM: SNA; na Honeywell-Bull: D5A; na DEC:

DNA,. etc.

Por fim, a última parte aborda certas

particularidades dos sistemas distribuídos

de automação industrial.

2. HISTÓRICO DOS SISTEMAS DISTRIBUíDOS

De 1960 a 1970

Com o desenvolvimento dos sistemas a

tempo compartilhado ("time-sharing"), oafastamento dos periféricos conduz ao

refinamento de técnicas de comunicação

ponto-a-ponto e multi-ponto (concentrador

de terminais) ao redor do computador

central,. bem como ao gerenciamento de

periféricos distantes ("remote batch

processing").

De 1980 a 1985

Assiste-se ao aparecimento dos

primeiros sistemas operacionais distribuídos

por interconexão de sistema~ homogêneos

(geralmente UNIX} com sistemas de

gerenciamento de arquivos distribuídos (Ex:

Newcastle Connection (Brownbridge et alii,

1982» ou permitindo a execução à distância

(Ex: LOCUS (Popek & Walker, 1985».

Por outro lado, a importância dos

organismos de normalização cresce: modelo

de referência das interconexões de sistemas

abertos (Open System Interconnection

Reference Model) da ISO (Zimmermann, 1980)

que permitem a comunicação do hardware (e

do software) de vários fornecedores.

Paralelamente, desenvolveram-se os

primeiros sistemas distribuídos com vários

computadores interligados por conexões

ponto-a-ponto, para aplicações muito

específicas (Sistema SAGE de vigilância do

território dos Estados Unidos, sistema SABRE

de reserva de passagens aéreas). Os

protocolos implementados são muito simples e

gerenciados diretamente pela aplicação.

Aparecem também as "redes digitais a

integração de serviços" (ISDN: Integrated

Service Digital Networks).

Tendência Atual

A tendência geral está na abertura:

trabalho com

recursos (arquivos,

De 1975 a 1980

De 1970 a 1975

Por outro lado, os principaisconstrutores desenvolvem suas próprias redes

Mas os trabalhos de normalização sãomuito lentos: são necessários v~rios anos

para obter uma norma aceitável. Para ganhartempo, os organismos de normalização têm

tendência a normalizar padrões "de fato"pré-existentes: por exemplo, Ethernet, 10anos após seu desenvolvimento 7 foinormalizado pela IEEE (IEEE 8~2.3) e depoispela ISO (ISO 8802). Além disso, amultiplicidade das necessidades dosusuarios

e das tecnologias dos fabricantes conduz a

uma multiplicação das"classes", o que leva anormas não-homogêneas. Para remediar este

- abertura dos fabricantes que tentam

aproximar suas arquiteturas de redes

aos padrões ISO ou éi:)S padrões "de

fato" (TCP/iP, Ethernet) ou aindadesenvolvem "gateways" para a

interconexão de redes heterogêneas

(Ex: DSA-SNA);

- abertura em direção de sistemas

operacionais "não-proprietários"; por

exemplo, os trabalhos de normalização

do UNIX pelo grupo X-Open.

o surgimento daso desenvolvimento

de

Estes anos vêemprimeiras redes locais e

das estaçõescompartilhamento deimpressoras).

Para reduzir o custo das comunicações,são concebidas redes gerais de grande

distância, fornecendo um serviço de

comunicação independente da aplicação: nos

Estados Unidos: ARPANET, na França: CYCLADES

e depois TRANSPAC. Estas redes necessitam de

protocolos mais complexos (comutação de

pacotes, roteamento, etc.) mas dão lugar a

novos serviços gerais (transferência de

arquivos).

265

3.2.1. Modelo Cliente-Servidor

3.2. Modelos de Aplicação Distribuída

utilização da difusão fornecida pelascamadas baixas dos protocolos.

Conceber uma aplicação distribuídaconsiste em imaginar e depois estruturar um

conjunto de ações ocorrendo em paralelo, emcooperação e/ou concorrência sobrecomputadores geograficamente distribuídos.

estruturação é facilitada pelade modelos. Classificaremos amodelos em quatro categorias,

certos modelos propostos possama várias categorias ao mesmo

Estautilizaçãoseguir osainda quepertencertempo.

É um dos primeiros modelos propostospara os sistemas distribufdos, emparticular para o compartilhamento dosrecursos (servidores de arquivos,servidores de impressora, etc.). Um servidorpode ser centralizado ou composto de váriasentidades equivalentes ou ainda ser, elemesmo, um cliente de outro servidor(Svoboda, 1984).

- aplicações de controle de processos,de supervisão, de segurança;

- aplicações de gerenciamento deestoques, de planificação;

- aplicações de gestão administrativa(comandos, faturas, pessoal);

- aplicações de estudo e desenvolviQento(CAD) ;aplicações de relações públicas;

-aplicações de relações internas eexternas (correio eletrônico, ISDN,acesso a banco de dados, transferência

eletrônica de dinheiro, etc.).

Orientações Futuras

É possível prever que, a mais ou menoslongo prazo, os sistemas distribuídos

integrarão aplicações distribuídasmúltiplas. Desta forma, sobre a(s) rede(s)de uma mesma empresa coabitarão e

cooperarão:

fato, "grandes" usuários tentam imporsub-conjuntos destas normas, adaptados asuas necessidades: por exemplo, GeneralMotors propõe MAP (GM, 1986), British

Aerospace associou-se a BMW, Aeritalia e aoutros usuários no projeto CNMA do programa

europeu ESPRIT (CNMA, 1986).

3. A PESQUISA SOBRE OS SUPORTES DEAPLICAÇÕES DISTRIBUíDAS 3.2.2. Modelo Transacional

3.1. Comunicação

A pesquisa nesta área é menos dinâmicaque há alguns anos atrás:

Este modelo foi inicialmente definidopara os acessos múltiplos a bases de dados(ex.: reserva de passagens de avião) (Gray,1978). Uma transação é um conjunto deoperações que têm as seguintes propriedades:

2) Sequencialidade: se várias transaçõessão executadas em paralelo, seuresultado é o mesmo que se elasfossem executadas sequencialmente numadeterminada ordem.

os problemas básicos das comunicações(qualidade do serviço, controle defluxo, etc.) foram solucionados deforma satisfatória:os métodos e ferramentas de concepçãoexistem e são normalmente utilizados,pelo menos para as camadas baixas dosprotocolos:

- as normas existentes são um freio àevolução.

1) Atomicidade: todas astransação são terminadasinicializada.

operações daou nenhuma é

Entretanto, pesquisas continuam emáreas como:

3) Permanência: quando umaterminada, seu resultado("commit" da transação).

transação éé mantido

- comunicações com taxa de transferênciamuito alta (várias Gbits/s);confidencial idade das comunicações(criptografia, fragmentação-dissemi­nação) ;

266

mesmo conteraninhadas).

o estadosalvo e

da transação

Uma transação pode ela

var1as transações (transaçõesPara permitir a atomicidade,inicial da transação deve sermantido durante toda a execução

para poder ser restituído:

em caso de deteção de erro (pontos de

recuperação);- em caso de interbloqueamento ("dead-

-lock").

A salvação-restauração do estadoinicial é facilitada pela utilização de"memória-estável" em disco (por exemplo,Tandem) ou em "memória rápida" (projetos

ENCHERES (Banatre et atlii, 1986a) e GOTHIC(Banatre et alii, 1986b)).

3.2.3. Atores (em CHORUS (Zimmermann etalii, 1984)) ou Módulos (em CONIC

(Kramer et alii, 1983))

Vários projetos de Sistemas

Distribuídos são baseados neste modelo:

- nos Estados Unidos: ARGUS (Liskov,1985), EDEN (Black, 1985), EMERALD(Black et alii, 1986), CLOUDS (Le

Blanc & Wilkers, 1985), etc.- na Europa: SOMIW (Shapiro, 1986), DASE

(DASE, 1986), COMANDOS (Balter, 1986),GUIDE, etc.

O modelo orientado-objeto é bemadaptado ao controle dos direitos de acesso.

A fronteira entre estes modelos ébastante difusa. Assim, a execução de umaoperação sobre um objeto pode serconsiderada como a execução de um serviço no

modelo cliente-servidor. Por outro lado, emcertos projetos, as opérações sobre osobjetos são "atômicas", o que permiteconstruir facilmente transações. Da mesma

forma, os "atores" podem ser consideradoscomo gerentes de objetos.

3.2.4. Modelo de Aplicação Orientado-Objeto

Neste modelo, toda entidade do sistemaé um objeto. Um objeto, designado por um~, possui um "estado" que pode serconsultado ou modificado por funções deacesso. O conjunto de objetos que têm asmesmas funções de acesso constitui umaclasse. Por exemplo, uma palavra-memória,uma pilha, um arquivo, um processo sãoobjetos.

São sequências de código ativadas pelachegada de mensagens e gerando outrasmensagens. As comunicações entre "atores"(ou módulos) se expressam da mesma forma,estejam eles na mesma estação ou em estaçõesdiferentes. Para tolerar as faltas,"reconfigurações" permitem reorientar asmensagens destinadas a um ator sobre umaestação em falha em direção de um "ator"equivalente de uma outra estação (Banino etalii, 1985a). Uma aplicação é entãoconstituída de execuções sucessivas de umconjunto de "atores" comunicando pormensagens.- O controle da aplicação pode serfacilitado pela utilização de "mensagens deatividade" (Banino et alii, 1985b).

O modelo orientado-objetovezes, implementado na formaabstratos": é a "programação-objeto".

é, muitasde "tiposorientada-

267

Nenhum destes modelos de aplicaçãodistribuída é especializado para uma classede aplicações dada, mesmo se alguns sãomelhor adaptados a determinadas classes (porexemplo, transações para os sistemas deb&ses de dados distribuídas). No entanto,nenhum destes modelos é reconhecido comosuficientemente geral p~ra ser adotado comomodelo de referência para servir de base àconstrução de aplicações distribuídasintegradas (no sentido dado no item I).Contudo, esta é a ambição do projeto ANSA(ANSA, 1987). Paralela~ente, a Comissão dasComunidades Européias organiza um grupo detrabalho, dirigido por Hubert Zimmermann,encarregadv de definir um "modelo dereferência do processamento distribuído"(Distributed Processing Reference Model:DPRM) , que deveria ser,o ao nível dasaplicações, o equivalente do OSI~RM aonível das comunicações.

3.3. Sistemas Operacionais Distribuídos

Os sistemas operacionais distribuídosvisam fornecer ao projetista de aplicaçãomecanismos que .~he permitam a realizaçãoeficaz dos modelos de ap~icação. Estesmecanismos podem ser mais ou menosevoluídos.

o primeiro (também o mais antigo e o

mais simples) destes mecanismos é atransferência de mensagens entre osprocessos de aplicação utilizando primitivas

tais como SEND e RECEIVE, síncronas ou não,com ou sem difusão. De fato, trata-se de ummecanismo de base sobre o qual pode-seconstruir todos os outros mecanismos.Numerosos sistemas fornecem um serviço destenível: CHORUS (Zimmermann et alii, 1984),CONIC (Kramer et alii, 1983), Amoeba(Mullender, 1985), Accent (Fitzgerald &Rashid, 1986), V-Kernel (Cheriton, 1984),

Mach-1 (Rashid, 1986), etc. Uma extensãodestes mecanismos de passagem de mensagem éconstituído pelos fluxos, generalização dos

"pipes" do UNIX.

Um mecanismo mais evoluído (mesmo queeste ponto seja asperamente discutido pelospartidários dos sistemas a passagem demensagens) é fornecido pela chamada de

procedimento remoto (RPC: "remote procedurecall"): isto consiste em fornecer uma

interface idêntica à chamada de procedimentoclássico, seja a execução local ou remota.A execução do RPC é bloqueante (síncrona)até o retorno do procedimento. O esquema deexecução é) consequentemente, simples, poisretoma o esquema clássico de execuçãosequencial. Alguns projetos tornam "atômica"a execução de procedimentos remotos,permitindo deste modo a construção simplesde aplicações tolerantes a faltas (projetos:CONCORDIA do programa ESPRIT, GOTHIC(Banatre et alii, 1986b), ARGUS (Liskov,

1985)) ou a construção de transações.Outras extensões do RPC consistem em torná­lo "não-bloqueante" (RSR: "remote servicerequest" do projeto DELTA-4 (Bonn et alii,1986)) para aumentar o paralelismo, ou apermitir as comunicações de m chamantes a nchamados ("multi-functions" (Banatre etalii, 1986b)).

Outros sistemas operacionaisdistribuídos implementam diretamente osmodelos orientados-objeto e as operaçõescorrespondentes da linguagem que os suporta(CLOUDS (Le Blanc & Wilkes, 1985), SOMIW(Shapiro, 1986)).

4. QUALIDADES EXIGIDAS PARA OS SISTEMASOPERACIONAIS DISTRIBUÍDOS

4.1. Transparência da Distribuição

268

O programador de uma aplicaçãodistribuída deseja geralmente não ter que

gerar o endereçamento das entidades quemanipula: ele designa essas entidades por um

~, cabendo ao sistema operacional oencargo de associar um endereço ao nomeconhecido da aplicação. Isto não exclui que

certas entidades (sensores, atuadores,periféricos, servidores especializados,etc.) sejam localizadas em estaçõespré-definidas. Mas isto permite que certaspartes da aplicação possam ser executadas

em estações não pré-definidas, ou ainda,migrar de uma estação a outra em curso deexecução, seja após uma falha(reconfiguração), seja para melhorar o

desempenho (repartição de carga) (Theimer etalii, 1985). Assim é possível chamar pelomesmo nome um conjunto de recursos ou "poolde servidores", com o sistema operacionalescolhendo neste pool o servidor menoscarregado ou o mais próximo do cliente.Este é o caso nos projetos "CambridgeDistributed Computing System" (Needham &Hebert, 1982), Amoeba (Mullender, 1985),SATURNE (Deswarte et alii, 1986a).

Em certos casos, o sistema operacionalfornecerá à aplicação uma interfaceidêntica à de um sistema centralizado. Istopode ser obtido gerando uma memória virtualou um espaço de endereçamento único sobretoda a rede (sistema Domain d'Apo110 (Leachet a1ii, 1983)), ou um sistema degerenciamento de arquivos (NewcastleConnection (Brownbridge et alii, 1982), NFS

(Lyon et alii, 1984)), ou ainda, fornecendoum interface sistema geral (Locus (Popek &Walker, 1985)).

Devemos notar que ,por razões detolerância a faltas ou de desempenho(proximidade), certas entidades (certosarquivos, por exemplo, ou ainda, tabelas deconfiguração ou de endereçamento) sãocopiadas no sistema distribuído, sen­do os diferentes exemplares designados pelo

mesmo nome. Em consequência, é importante

manter a coerência deste, apesar dos acessosparalelos aos vários exemplares e apesar dapresença possível de faltas (Locus (Popek &Walker, 1985), Saturne (Deswarte et a1ii,1986a)) .

4.2. Segurança de Funcionamento

A Segurança de Funcionamento("Dependability") pode definir-se como apropriedade de um sistema que permite

colocar uma confiança justificada no serviço

oferecido (Laprie, 1986). Segurança deFuncionamento é um termo genérico que visa

cobrir ao mesmo tempo:

- a confiabilidade ("reliability") ou

medida da continuidade do serviço:- a disponibilidade ("availability") ou

probabilidade de fornecer o serviçonum instante dado, levando em conta asaIternância.s entre os estados "em

serviço" e "fora de serviço";- a segurança ("safety") que mede a

resistência a faltas catastróficas.- a segurança ("security") que mede a

resistência a faltas intencionais(intrusões).

hidrometria, formação do pessoal de

operação, etc.)~

As técnicas de impedimento serão

desenvolvidas no item 4. Mas, qualquer queseja a "qualidade" do sistema, e portanto

para tão baixa que seja a taxa d~ falha dosseus elementos, as consequências destas

falhas poderiam ser de tal modo importantes

que pode-se tornar indispensável aintrodução de técnicas de tolerância a

faltas.

A tolerância a faltas é obtida pelaredundância, material e/ou temporal. Pode­se recorrer a duas técnicas para tolerar asfaltas: a deteção dos erros e a recuperaçãodestes ou o mascaramento dos erros.

faltas consiste emoperar o sistema dea probabilidade de

Os sistemas distribuídos colocam umtriplo problema do ponto de vista dasegurança de funcionamento:

Os dois outros pontos necessitam aimplementação de técnicas de impedimento afaltas ou de tole~ância a faltas no conjuntodo sistema distribuído, hardware esoftware.

- qualidade da concepção do hardware edo software (métodos e ferramentas deespecificação e de concepção);qualidade da realização (fabricação,componentes, integração, verificação);

- qualidade do ambiente de operação(alimentação elétrica, temperatura,

O mascaramento de erros consiste emutilizar redundâncias, de maneira a podercontinuar o tratamento mesmo em caso deerro: o estado do sistema é suficientementeredundante para permitir restabelecer umestado correto a partir do estado incorreto.O exemplo mais simples desta técnica é ovoto majoritário: o tratamento é efetuadonum número de exemplares suficiente paraque os exemplàres corretos sejam"majoritários"; os resultados dos diferentes

A deteção e arecu2eração dos erroscomporta uma fase de deteção com o auxíliode mecanismos integrados ou acrescentados aohardware e/ou software para efetuar ocontrole de verossimilhança sobre o estado

do hardware, do software e dos dados:verificação das durações ("watchdog"),verificação dos valores (códigos detetores,

deteção de código de instrução não-válido oude endereço inexistente, controle deverossimilhança da aplicação, programas detestes, etc.), verificação dos direitos (deum processo efetuar certas operações sobrecertos objetos).

Após deteção do erro, deve-se efetuarum diagnóstico dos elementos com falhas e,no caso da falta ser diagnosticada comopermanente, operar uma reconfiguração paraeliminar estes elementos e/ou acrescentarnovos elementos permitindo continuar otratamento. A seguir, é necessário corrigiro estado errôneo, seja por uma recuperação("roll-back") sobre um estado anterior salvo("backward recovery"), seja peloestabelecimento de um novo estado correto,por exemplo, por reinicialização ("forwardrecovery").

deem

é capaz

capazes deparasitc3s,

erros

1) as ligações físicas sãogerar erros (ruídos,etc. ) ;

2) a multiplicidade de equiparnentosaumenta

a probabilidade de falha e deintrusão;

3) a falha de um elementopropagar rapidamenteelementos sem falhas.

..O impedimento as

conceber, realizar eforma a minimizarocorrência de faltas:

O primeiro ponto pode geralmente serresolvido pelos protocolos de comunicação

(códigos detetores ou corretores de erro,repetição de mensagens, roteamentoadaptativo) ou, por dispositivos decomunicação redundantes (barramentoduplicado, anel duplicado, etc.)

269

exemplares são votados e os resultados

majoritários são considerados como corretos

(Deswarte et alii, 1986a). Esta técnica é

particularmente interessante para os

sistemas em tempo-real, visto que ostratamentos (e então as durações deexecução) são sempre os mesmos quer se tenhaou não erros. Devemos notar que a fronteira

entre "mascaramento" e "deteção +recuperação" não está clara mas depende doponto de vista do observador: um códigocorretor de erro corresponde ao mascaramento

ou à deteção-recuperação?

Nos sistemas distribuídos, é muitas

vezes tentador utilizar a redundância

intrínseca do sistema para tolerar asfaltas; a falha material de um elementopode não bloquear o conjunto do sistema, epode persistir um número suficiente deelementos corretos para continuar ostratamentos. Mas este princípio simples se

choca com dois problemas:

dominó" (Randell, 1975). Portanto, é

indispensável conceber o software de

aplicação em vista da recuperação e

estruturá-lo em função dosmecanismos disponíveis: transações,

conversação (Randell, 1975). Masesta estruturação prejudica atransparência e impõe restrições quepodem deteriorar o desempenho deforma significativa.

Por outro lado, existe uma classe defalhas "maliciosas" que devem geralmenteser levadas em conta na concepção de umsistema distribuído tolerante a faltas,pelo menos quandc se deseja atingir um alto

grau de segurança ("safety"): são as falhas"bizantinas" (do nome do problema dosgenerais bizantinos (Lamport et alii,1982) Isto pode somente ser feito ~s custasde uma redundância mais forte ou de umaconcepção específica (em particular dosmeios de comunicação) (Wensley et alii,1978) •

"recovery

Em cada etapa do ciclo de vida de umaaplicação,convêm prestar-se particular atenção

5. CONCEPÇÃO, REALIZAÇÃO E OPERAÇÃO DEAPLICAÇÕES DISTRIBUíDAS

É um dos pontos estudados dentro doprojeto SATURNE (Deswarte et alii, 1986a).

mesmo

deteção e recuperação:block" (Randell, 1975);

- mascaragem: programação em "N-versões"(Avizienis & Laprie, 1986).

A diversificação pode atéatingir a especificação funcional.

- da sua vulnerabilidade: é muitodifícil proteger fisicamente umsistema geograficamente extenso;

- da gravidade potencial ~as sabotagensou divulgações de informação.

Enfim, a segurança ("security") diantedas falhas intencionais ("intrusões") deveser particularmente estudada nos sistemasdistribuídos por causa:

As técnicas de tolerância a faltas a­plicam:-se evidentemente às falhas materiais,mas elas podem também ser adaptadas àsfalhas de concepção do software pelautilização da diversificação:

- por um lado, o mascaramento necessitade uma redundância forte, geralmentemais importante que aquela que poderiaser fornecida "gratuitamente" peloselementos inativos da rede (o projetoSATURNE (Deswarte et alii, 1986a) visautilizar, da melhor forma possível, oselementos inativos para aumentar aredundânc i a ;

- por outro lado, a deteção-recuperaçãonecessita de:* se precaver contra a propagação de

erros: os mecanismos de deteção não

têm geralmente uma cobertura de l~~h

e não atuam instantaneamente; osdispositivos de comunicação entreprocessos são, por conseguinte,susceptíveis de propagar erros e decontaminar outros processos, etc ;

* definir "estados" do sistema, sejapara salvar um estado em vista deuma recuperação ("backwardrecovery") seja para estabelecer umnovo estado sadio ("forwardrecovery"); ora, é muito difícilobservar um estado estável de umsistema distribuído, por causa doparalelismo elevado e daconcorrência-cooperação entreprocessos; além disso, é desejávelrealizar somente o recobrimento dosprocessos contaminados e deixarcontinuar os outros. Utilizar"brutalmente" as técnicas derecuperação pode levar ao "efeito

270

à qualidade de forma a evitar as falhas deconcepção e de interação. Este problema é

mais difícil para as aplicações distribuídasque para as aplicações sequenciais, pois oser humano tem dificuldade em conceber e

assimilar ações múltiplas que se desenvolvemem paralelo. As aplicações distribuídasapresentam maior complexidade ~

consequentemente, maior possibilidade de

erros.

5.1. Especificações funcionais

Partindo das especificações dosrequisi tos ("requirement specifications"), asespecificações funcionais são a primeira

etapa de concepção da aplicação distribuída.É uma etapa particularmente importante,poisuma falha de concepção, a este nível, te~á

consequências graves sobre as etapasseguintes e será tanto mais custosa decorrigir. Portanto, é conveniente verificartanto quanto possível estas especificaçõesfuncionais segundo dois tipos de critérios:

1) Adequação aos requisitos: é necessárioverificar que as especificaçõesfuncionais propostas satisfazem asexigências das especificações dosrequisitos:- sob o aspecto funcional (averificação pode ser manual);

- sob o aspecto do desempenho:precisão, desempenho temporal, ...(pode ser necessário o uso esimuladores);

- sob o aspecto da segurança defuncionamento (por cálculos préviosde confiabilidade, disponibilidade,etc, eventualmente utilizandoferramentas tais como programa SURFdesenvolvido no LAAS).

2) Coerência das especificaçõesfuncionais: deve-se verificar que asespecificações sejam implementáveis eque a implementação possa funcionar(ausência de inter-bloqueios, desaturação, .•. ) •

Estas duas classes de verificaçõesserão tanto mais fáceis e válidas quanto asespecificações sejam escritas formalmente.Existem numerosos métodos de especificaçãoformal; entretanto citaremos aqui apenastrês,particularmente adaptados aos sistemasdistribu'í,dos:

271

1) As Redes de Petri: é uma representaçãográfica de sistemas paralelos, mais

sintética que as máquinas de estadosfinitos (ou autômatas), mas com a

mesma potência de representação.Existem várias extensões das redes dePetri de base (redes de Petri

"coloridas", "temporizadas","estocásticas", •.• ) melhor adaptadas acertas classes de problemas ou de

verificação. Para verificar as redesde Petri podem ser utilizados doistipos de ferramentas:

- as ferramentas analíticas quepermitem verificar formalmentecertas propriedades tais como a

ausência de inter-bloqueio, aausência de saturação, etc.

- os simuladores ou interpretadoresque permitem verificar certascaracterísticas (temporais, porexemplo) .

2) Estelle (Courtiat et alii, 1987):linguagem de ~rogramaçao de algoritmos

distribuídos, em curso de normalizaçãopela ISO, é baseada sobre autômatoscomunicantes, mais no estilo de umalinguagem procedural de tipo Pascal.Esta linguagem serve de base a ummétodo de desenvolvimento queapresenta ferramentas:- de apoio à programação (manipulação

de descrições formais),- de verificação formal de algoritmos,- de ajuste e simulação,- de geração de código.

3) Lotos (ISO, 86): é outra linguagem emcurso de normalização pela ISO para adescrição de protocolos, mas baseadaem outro formalismo (CCS, lógicatemporal).

Estas duas linguagens são estudadas noprojeto SEDOS do programa ESPRIT. Elas podemservir à especificação funcional dealgoritmos distribuídos e à sua verificaçãoformal, como também podem servirdiretamente à programação e à geração decódigo.

Mesmo que as especificações funcionaisnãc sejam descritas formalmente, é possívelutilizar ferramentas de software paraverificar algumas das suas características.Assim o simulador SPHINX desenvolvido nocontexto do projeto SCORE (Le Lann, 1987)

5.2. Realização de Aplicações Distribuídas

Existem "Ambientes de Produção deSoftware" que permitem implementar, de formaeficaz, os algoritmos descritos por

especificações funcionais. Mas poucos deleslevam em conta as particularidades dossistemas distribuídos. Uma exceção é oprojeto SEDOScitado precedentemente.

permite a avaliação de

arquiteturas distribuídas.

desempenho de ainda por execução (interpretação)

direta das redes de Petri. A linguagemde especificação torna-se então uma"linguagem de muito alto nível" (VHLL- 'very high leveI language'). Este

tipo de interpretação dasespecificações formais pode igualmenteservir à deteção de erros por

comparação entre a execução doprograma real e da interpretação daespecificação (Ayache et alii, 1982):é uma utilização da diversificação do

software.

1) Ações de monitoração: convém monitoraro comportamento da aplicação, sejapara ajustar certos parâmetros deforma a melhorar o desempenho, sejapara detetar a presença de falhas deconcepção residuais e as diagnosticar.A implementação de observadores(Ayache et alii, 1982) facilita amonitoração das aplicaçõesdistribuídas ou dos protocolos.

3) É necessário igualmente realizarmedidas para verificar que o sistemasatisfaz às exigências das

especificações de requisitos:- medidas de desempenho, por simulação

do ambiente (ex: simulação de

tráfego); existem ferramentas geraispara este tipo de medidas dedesempenho, como LYNX, desenvolvidono contexto do projeto SCORE

(Le Lann, 1987);

medição de certos parâmetros dasegurança de funcionamento(cobertura, tempo de latência .•• ) everificação do comportamento dosistema na presença de falhas; paratal, usam-se "inj etores de falhas'~

tais como o sistema MESSALINEdesenvolvido no LAAS.

A fase de realização deve também serverificada por três tipos de validação:

1) Testes funcionais devem ser aplicadospara ajustar e verificar os módulosdesenvolvidos e sua integração. Oparalelismo e a impossibilidade de

observar o estado completo do sistematornam particularmente difíceis ostestes "exaustivos". Entretanto,algumas vezes, baterias de testespodem ser geradas automaticamente por

analisadores de especificação formal.Por outro lado, ferramentas de testesinterativos podem ser desenvolvidaspara realizar testes "representativos"ou testes "agressivos" (Deswarte et

alii, 1986b).

2) Devem ser efetuadas Verificações deconformidade com as especificaçõesfuncionais. Se as especificaçõesfuncionais foram expressas formalmentee se a linguagem de programação for

adequada, é possível imaginar oestabelecimento de "provas" deequivalência entre as duas formas dealgoritmos (especificação formal eprograma). A execução simbólica podepermitir a obtenção de tais provas.Entretanto, essas técnicas são, nomomento, apenas aplicáveis a programassequenciais simples. Resta a percorrermuito caminho antes que elas possamser aplicadas de forma eficaz aossistemas distribuídos assíncronos.

5.3. Operação

Na fase dedistribuída devemde ações:

operação de uma aplicação

ser previstos três. tipos

Portanto, é necessário recorrer amétodos mais formais como as "revisõesde programa" por equipes de revisores.

Uma outra via para garantir estaequivalência consiste em transformarautomaticamente as especificaçõesformais em programa executável. Isto épossível com Estelle)por exemplo, ou

2) Ações de manutenção: a deteção ecorreção de falhas residuais deconcepção conduz ao desenvolvimento denovas versões da aplicação. Estasversões devem ser validadas como osprogramas iniciais (ver ítem IV.2) e,também, podem ser verificadas portestes de "não-regressão" para

272

assegurar que nenhuma função presente

na versão precedente não esteja

ausente na nova versão. É desejável,

às vezes, fazer coabitar váriasversões da aplicação no sistema real

para terminar a validação das novas

versões (Deswarte et alii, 1986b).

3) Evolução da aplicação: é possível que,

no decorrer do uso, novas necessidades

surjam ou que o ambiente da aplicação

mude ou que o suporte material seja

modificado ou ainda que novasaplicações precisem ser integradas e

cooperar com a aplicação existente.

Isto pode levar a modificações

completas da aplicação, para as quais

o conjunto do desenvolvimento deve ser

retomado. Evidentemente, este trabalho

de modificação é facilitado quando te­nham sido utilizados metodos formais.

Por fim, é preciso ressaltar a

importância fundamental dos operadores

humanos (e do pessoal de manutenção) durante

a fase de operação. Muitas vezes, estas

pessoas são susceptíveis de cometer errosmais graves e sobretudo menos previsíveis

que as falhas materiais (Deswarte et alii,

1986b). É necessário então formá-los com

cuidado e facilitar seu trabalho por uma

interface amigável com o sistema. Deve-se

ressaltar que os operadores são responsáveispela grande maioria das intrusões na

transferência ilícita de fundos,- divulgaçãode informações confidenciais ou sabotagem.

Consequentemente, é primordial limitar e

verificar seus direitos sobre o sistema.

6. PARTICULARIDADES DOS SISTEMAS

DISTRIBUíDOS EM AUTOMAÇÃO INDUSTRIAL

Os Sistemas Distribuidos utilizados em

automação industrial implementam geralmente

os mesmos meios de comunicação, os mesmosmodelos de aplicação, as mesmas linguagens,as mesmas ferramentas de desenvolvimento que

os outros sistemas distribuídos. Entretanto,pelo menos para os mais críticos, sediferenciam pelas suas exigências em termosde tempo real.

"Um sistema é chamado 'tempo real' sealguma ou o conjunto das entidades sãoobrigadas a respeitar datas físicas para oinício e o fim de suas execuções e se odesrespeito destas datas constitui uma falhado sistema" (Le Lann, 1987).

273

Para respeitar estas datas físicas, os

Sistema Distribuídos Tempo Real impoem

geralmente limites máximos aos tempos de

acesso na rede de comunicação. Isto pode

conduzir a escolhas de alguns sub-conjuntos

de protocolos normalizados que privilegiam o

tempo de resposta (por exemplo, MAP

(GM, 1986)). Mas para aplicações que têm

exigências de confiabilidade e de segurança

('safety') rigorosas, estes limites devem

levar em conta as hipóteses de falhas (por

e~emplo, perda de ficha, reconfiguração, ••• )

o que pode levar a conceber protocolos

específicos. É o caso, por exemplo, do

protocolo 8~2.3D desenvolvido para o projeto

SCORE (Le Lann, 1987) que é compatível com a

norma IEEE 8~2.3 e Ethernet, mas que garante

tempo de acesso limitado.

A consideração de datas físicas, quetem que ser respeitadas,pode eerintegrada no

sistema operacional distribuído (por

exemplo, MARS (Kopetz et alii, 1982)). Mas

existe uma outra estrutura da aplicação que

é suscetível de se desenvolver no contexto

dos sistemas distribuídos tempo real:trata -se dos sistemas "reativos" e das

linguagens correspondentes (CCS, LCS, FP2,Esterel, .•• ) (Perrin, 1987).

Entretanto, na medida em que as

aplicações tempo real são somente uma parte

do sistema distribuído industrial, tendo porconseguinte que cooperar com outras

aplicações (gestão, planificação, CAD, ••. ),

é desejável adotar um modelo único para

todas estas aplicações e funções idênticasao nível dos sistemas operacionais

distribuídos.

7, CONCLUSÃO

A nossa intenção foi pintar umretrato da pesquisa atual a respeito dos

Sistema Distribuídos e tirar asprincipais orientações que devem determinar

sua evolução nos prOX1mos anos. Mas) se érelativamente fácil olhar para o passado eapresentar um histórico do desenvolvimentoda informática nesta área, é muito maisdifícil pretender tirar do atual universodifuso da pesquisa em Sistem.asDistribuídosas tendências que se solidificarão nofuturo. Somente o porvir permitirá julgar a

exatidão das nossas conjecturas.

Reconhecimento

Determinadas partes deste artigo e dabibliografia foram influenciad s por(Krakowiak, 1987) e (Balter, 1986).

8. REFERÊNCIAS

Black, A.P., (1985). "Supporting distributedoperations: experience with Eden". Proc.of the 1fl,lth ACM SIGO?S, Washington,December 1985.

Black, A. et alii, (1986). "Distributionand abstract types in Emerald". IEEETrans. on Software Engineering, December1986.

ANSA, (1987). ANSA: Advanced NetworkedSystems Architecture. "Building a newfuture for Information Systems".PR.26.07, January 1987, Cambridge, UK.

Avizienis, A. & Laprie, J.C., (1986)."Dependable computing: from concepts todesign diversity". Proceedings of theIEEE, vol.74, no.5, May 1986, pp.629­638.

Ayache, J.M. & Courtiat, J.P. & Diaz, M.,(1982). "Self-checking software indistributed systems". Proc. of the 3!"dIEEE Int. Conf. on Distributed ComputingSystems, Miami, October 1982, pp.163­170.

Bonn, G. & Martin, P. & Powell, D. &Seaton, D.T., (1986). "Delta-4: Overallsystem specificátion (Issue 1)". LAASReport no.86.276, August 1986.

Brownbridge, D.R. & Marshall, L.F. &Randell, B., (1982) • "The NewcastleConnection or UNIXes of the WorldUnite !". Software Practice anct.Experience, vol.12, 12, December 1982,pp.1147-1162.

Cheriton, D.R., (1984). "The V-kernel: asoftware base for distributed systems".IEEE Software, vol.l, 2, 1984, pp.19-42.

Balter, R., (1986). "Systemes distribues surreseau local: Analyse etclassification". BulI, DSG/CRG/OSI,decembre 1986.

CNMA, (1986). "CNMA: Communication Networkfor Manufacturing Applications". ESPRITProject 955, Proc. of the ESPRITTechnical Week, 1986, North-Holland.

Banatre, J.P. & Banatre, M. & Lapalme, G. &Ployette, F., (1986a). "The design andbuilding of Enchere, a distributedelectronic marketing system". Comm. ACM,vol. 29, 1, January 1986, pp.19-29.

Courtiat, J.P. & Dembinski, P. & Groz, R. &Jard, C., (1987). "ESTELLE: un langageISO pour les algorithmes distribues etles protocoles". T.S.I., vo1.6, no.2,1987, pp.89-1fl,l2.

Deswarte, Y. & Alami, K. & Tedaldi, O.,(l986b). "Realization, Validation andExploitation of a Fault-TolerantMultiprocessor: ARMURE". Proc. of the16th IEEE Int. Symposium on Fault­Tolerant Systems (FTCS-16), Vienna, July1986.

Deswarte, Y. & Fabre, J.C. & Laprie, J.C. &Powell, O., (1986a). "A saturationnetwork to tolerate faults andintrusions". Proc. of the 5th IEEE Int.Symposium on Reliability in DistributedSoftware and Database Systems, LosAngeles, January 1986, pp.74-81.

DASE , (1986) • "::.,.P.:;..r..;:.e.=l.=i.:.;cm:..::i::...nc.::.ac.::.r..>LY_--::d:.:;r-:;:a-=f:-.t:.....-.....:f::...o;:;..:r:.....-_T::..::.:RDase". ICL contribution to ECMA TC32­TG2, April 1986.

Svstem

Rozier, M.,

distributedactivity

Hawai

Banino, J.S. & Morisset, G. &(1985b). "Controllingprocessing with CHORUSmessages". Proc. 18thInternational Conference on

Banatre, J.P. & Banatre, M. & Ployette, F.,(1986b). "An overview of the Gothicdistributed operating system". ResearchReport no.284, INRIA-IRISA, January1986.

Banino, J.S. & Fabre, J.C. & Guillemont, M.& Morisset, G. & Rozier, M., (1985a)."Some Fault-Tolerance Aspects of theCHORUS Distributed System". Proc. of the5th IEEE Int. Conf. on DistributedComputing Systems, Denver, May 1985,pp.43fl,l-438.

Science, January 1985.

274

Fitzgerald, R. & Rashid, R. F . , (1986) •. "The

integration of virtual memory management

and interprocess communication in

Accent". ACM Trans. on Computer Systems,vol.4, 2, May 1986, pp.147- 177.

Le Lann, G., (1987). "Le proj et SCORE: les

systemes informatiques repartis

temps-reel". T.S.I., volo6, no.2, 1:987,pp.175-178.

General Motors, (1986). "MAP specifications

versions 2.1A & 2.2". August 1986.

Gray, J .• N., (1978). "Notes on databaseoperating systems". Operating Systems,

Lecture Notes in Computer Science no.60,Springer-Verlag, 1978, pp.393-481.

Liskov, B.H., (1985). t~e / Argus languageand system". Dist~ibuted Systems:

methods and tools". Ed. .M. Paul & H.J.Siegerteditors, Lecture Notes inComputer· Science no.190, Springer-Verlag, 1985.

ISO/TC97/SC21/WG16-1 DP8807, (1986). "Lotos:a formal description technique". July1986.

Lyon, B. et ali i, (1984). "Overview of theSUN Network File Svstem". SUNMicrosystems Inc, October 1984.

& Merker, W. &"The architecture

University of1982.

Kopetz, H. & Lohnert, F.Pauthner, G., (1982).of MARS". TechnicalBerlin, MA 82/2, April

Mullender, (1985) . "Principles ofDistributed Operating Systems Design".PhD Thesis Report, Mathematisch Centrum,Vrije Universiteit Amsterdam,Netherlands, October 1985.

Lamport, L.(1982) .problem".LanguagesJuly 1982,

structure forIEEE Trans.

volo SE-1 , 2,

Needham, R.M. & Herbert, A.J., (1982). "':ç,heCambridge Distributed Computing System~t.

Addison-Wesley ICS series, 1982.

Randell, B., (1975). "Systemsoftware fault-tolerance".on Software Engineering,June 1975, pp.220-232.

Perrin, G.R., (1987). "Programmatí-on. parallele: point de vue sur les langages

et les methodes" • T. S. L, volo 6, no.,2,1987, pp.1!ll3-113.

Popek, G. & Walker, B.J., (1985). "The Locúsdistributed system architecture". MITPress, 1985.

Magee, J. & Sloman, M. &(1983) . "CONIC: an

approach to distributedcontrol systems". IEE Proc.

Pt. E, no.1, January 1983,

& Shostak, R. & Pease, M.,"The Byzantine generalsACM Trans. on Programming

and Systems, vol.4, no.3,pp.382~4!ll1.

Kramer, J. &Lister, A.,integratedcomputer

vol.13!ll,pp.1-1!ll.

Krakowiak, S., (1987). "Les systemesd'exploitation repartis evolution

recente et tendances de la recherche".~., vol.6, no.2, 1987, pp.151-161.

Laprie, J.C., (1986). "Dependability: AUnifying Concept for Reliable Computing

and Fault-Tolerance". LAAS Reportno.86.357, December 1986.

Rashid, R.F.,system".pp.37.

(1986) • "Threads ofUnix Review, August

a new1986,

Leach, J.P. & Levine, P.H. & Douros, B.P. &Hamilton, J.A. & Nelson, D.L. &Stumpf, B.L., (1983). "The architectureof an integrated local network". IEEEJournal on Selected Areas inCommunications, November1983, pp.842­856.

LeBlanc, R. & Wilkes, T., (1985). "Systemsprogrammi~g with objects and actions".Proc. of the 5th IEEE Int. Conf. onDistributed Computing Svstems, Denver,May 1985.

Shapiro, M., {1986). "Structure andencapsulation in distributed systems:the proxyprinciple". Proc. of the 6thIEEE Int. Conf. on DistributedComputing, Boston, May 1986, pp.198-2!ll4.

Svoboda, L., (1984). "File servers fornetwork-based distributed systems". ACMComputing Surveys, volo16, 4, December1984, pp.353-398.

275

10th

"SIFT; thedesign and anaIysis of a fauIt-tolerantcomputer for aircraft control"..E'roc. ofthe IEEE" voL.66, nO.10, October 1978,pp.1255-1268.

Zimmermann, H., (1980).model tl • IEEE Trans. onApril 1980.