Sunteți pe pagina 1din 14

Unidade 2: Conceitos, Projeto Classificaes de Sistemas Distribudos

Primeiras palavras

J que vimos o que e para que se destina um Sistema Distribudo, que tal comearmos a estud-lo com um pouco mais de profundidade, classificando um sistema distribudo de acordo com seu hardware, seu software e investigando como suas caractersticas influenciam no seu projeto.

Problematizando o tema
Neste captulo vamos estudar mais a fundo as caractersticas de um SD, classificando-o do ponto de vista de hardware e software (j que temos efetivamente duas diferentes vises em sua definio) e tambm como implementar efetivamente as suas caractersticas, atravs de uma viso de projeto de SD.

Conceitos de Hardware
Michael Flynn desenvolveu uma taxonomia (classificao) em 1972, baseada no nmero de fluxos de instruo (I) e no nmero de fluxos de dados (D). um esquema ainda muito utilizado e difundido que diferencia o fluxo de instrues e o fluxo de dados, dependendo das caractersticas esses fluxos so mltiplos ou no. Atravs disso podemos classificar os sistemas computacionais como de nica instruo (SI - Single Instruction) ou Mltiplas Instrues (MI Multiple Instruction) atuando sobre um nico dado (SD - Single data) ou mltiplos dados (MD Multiple Data). Tudo isso, resumidamente, quer dizer que: se congelarmos o estado de uma mquina, quantas instrues esto sendo executadas e quantos dados esto sendo manipulados naquele exato instante de tempo. A tabela a seguir ilustra alguns exemplos que sero explicados posteriormente (esta tabela baseada no nmero de instrues que so executadas e a quantidade de dados que so manipulados em um determinado instante de tempo)

Tabela 1: Taxonomia de Flynn (SD) Single Data SISD (SI) Single Instruction Mquinas de Newmann convencionais MISD (MI) Multiple Instruction Sem representante Multiprocessadores e (at o momento) Multicomputadores (nCUBE, Intel Paragon, Cray T3D) Von Mquinas Vetoriais (CM-2, MasPar) (MD) Multiple Data SIMD

MIMD

SISD: computadores com um nico processador. As mquinas convencionais um pouco mais antigas (hoje sistemas com um nico processador podem ser encontrados em celulares, alguns PDAs, smartphones, entre outros). O fluxo de instrues e dados o seguinte. Uma instruo (I) lida da memria (M), enviada para uma unidade de controle (C) e executada no processador (P), que pode fazer uso de endereos de memria (neste caso 1 nico endereo) para realizar sua operao

SIMD: computadores com processamento vetorial e matricial (mquinas que executam um grande nmero de operaes aritmticas em paralelo, cada uma com seus prprios dados). Neste caso uma mesma instruo armazenada em Cache e executada em vrios processadores que atuam sobre vrios endereos de memria distintos;

MISD: um esquema terico e ainda h uma certa controvrsia sobre este. Em tese, pode haver um conjunto de diferentes instrues executando sobre um mesmo endereo de memria (o que implicaria em um mecanismo de excluso mtua, que na prtica invalidaria o modelo). Entretanto alguns especialistas podem classificar este tipo de computador como uma mquina (ou conjunto de mquinas) que podem realizar vrias operaes sobre uma mesma entrada. Por exemplo, aplicao de vrios filtros diferentes em uma mesma imagem.

MIMD: Mltiplos processadores atuando de forma paralela sobre diferentes conjuntos de dados. neste modelo que efetivamente os sistemas distribudos so classificados quanto ao hardware. Isso se deve ao fato de termos mquinas independentes (cada uma com seu processador, sua memria local) executando diferentes instrues em diferentes endereos de memria.

Neste esquema, cada unidade de controle C recebe um fluxo de instrues prprio e envia-o para sua unidade processadora P. Os computadores MIMD ainda podem ser divididos em duas categorias: memria compartilhada (mquina multiprocessada) e memria distribuda (cluster ou grid), como detalharemos a seguir. Memria compartilhada: caracterizado pela presena de um nico espao de endereamento que ser usado de forma implcita para comunicao entre processadores. Ou seja, todos os processadores enxergam o mesmo espao de

endereamento, sendo ele uma nica mquina com um nico mdulo de memria e vrios processadores (por exemplo uma mquina paralela ou um processador com vrios ncleos). Memria distribuda: faz referencia a localizao fsica da memria, os mdulos de memria encontram-se distribudos por cada uma das mquinas. Cada mquina tem seu prprio mdulo de memria (isso est se aproximando da definio de Sistema Distribudo, no acha?). A memria total do sistema pode ser dada pela somatria dos mdulos individuais de memria de cada mquina. Exemplo: cluster.

Conceitos de Software
O software o elemento que determina a imagem que o sistema apresenta ao usurio e o modo como eles pensam sobre o sistema. Adicionalmente, o software e o hardware em conjunto definem a viso que o usurio tem do sistema e tambm sua organizao. Podemos classificar tipos de Sistemas Operacionais Distribudos com mltiplas CPUs atravs de dois itens: Fracamente Acoplados Fortemente Acoplados

O acoplamento em termos de hardware define o grau de dependncia dos componentes do sistema. Por exemplo, uma mquina com mltiplos processadores em uma mesma placa me considerada fortemente acoplada, pois, a ausncia de um processador impede o funcionamento da mquina. J uma rede de computadores considerada um hardware fracamente acoplado por no haver dependncia entre os computadores. Se um computador da rede se desligar, a rede continua em funcionamento. Vamos agora detalhar o software em termos de acoplamento.

Software Fortemente Acoplado - os diversos processadores do sistema cooperam na execuo das tarefas. Ex: Processamento de imagens.

Software Fracamente Acoplado - permite que as mquinas e usurios do sistema sejam independentes uns dos outros, interagindo em um grau limitado quando for necessrio. Ex: Um grupo de computadores pessoais, cada um com a sua prpria CPU, memria, disco rgido e S.O., compartilhando alguns recursos atravs de uma LAN. Bom, pensando nisso, podemos, agora, classificar os diferentes tipos de sistemas operacionais para mltiplos processadores:

Sistema Operacional de Redes


(Software fracamente acoplado em hardware fracamente acoplado) O Exemplo mais claro que temos o sistema operacional que executa em workstations independentes em uma rede local ou de longa distncia Cada usurio tem a sua estao de trabalho Cada estao de trabalho pode ter ou no disco rgido Cada estao de trabalho tem o seu prprio sistema operacional Todos os comandos so normalmente executados localmente Eventualmente possvel fazer uma conexo remota com outra estao de trabalho Forma mais conveniente de comunicao e compartilhamento de informao: Sistema de Arquivo Global Compartilhado (NFS) Implementado em uma ou mais mquinas chamadas Servidores de Arquivos Servidores de Arquivos aceitam requisies de programa de usurios (chamados clientes)

Sistemas Timesharing Multiprocessadores

(Tempo

compartilhado)

(Software Fortemente Acoplado em Hardware Fortemente Acoplado) Neste tipo de sistema temos mquinas para propsitos especficos, tais como bases de dados dedicadas e processamento de imagens (por exemplo). No entanto, a caracterstica principal justamente ser um nico computador equipado com vrias unidades processadoras. Algumas caractersticas destes sistemas: Todo o projeto pode ser centralizado: viso de um nico processador. Isso porque estamos efetivamente falando de uma nica mquina Existncia de uma nica fila de espera (processos que no esto bloqueados e prontos para execuo), uma vez que uma nica cpia do SO executando; Memria compartilhada por todos os processadores; nico sistema de arquivos;

Sistemas Distribudos
(Software fortemente acoplado em hardware fracamente acoplado) Efetivamente buscamos o melhor dos dois mundos (o que no nada fcil). O objetivo do sistema criar a iluso para os usurios de que a rede de computadores um nico sistema timesharing, em vez de um conjunto de mquinas distintas. Cada usurio tem a mesma imagem do sistema. Impresso de um nico processador Virtual, quando na verdade h vrios processadores, um (ou mais) em cada mquina Um mecanismo de comunicao entre processos nico e global - qualquer processo pode se comunicar com qualquer outro pelos mesmos mecanismos, independente de estarem localizados na mesma mquina ou em mquinas distintas;

Gerenciamento de processos precisa ser o mesmo no sistema todo (criao, destruio, comeo, interrupo de processos); nico conjunto de chamadas de sistema, o que permite que um processo seja executado em uma mquina a partir de outra; Sistema de arquivo tambm precisa ter as mesmas caractersticas, para que os diversos processos executando nas diferentes mquinas consigam manipular qualquer arquivo em outras mquinas; Cpias idnticas do kernel executam em todas as CPUs do sistema (escalonamento, swapping, paginao, etc), como uma conseqncia das caractersticas anteriores.

Em resumo, podemos gerar a seguinte tabela com as diferenas entre estes sistemas:

Tabela 2: Caractersticas dos diversos Sistemas para mltiplos processadores SO de Rede Sistema Distribudo Sistema Timesharing Multiprocessadores Parece um No nico processador virtual? Tem o mesmo No SO? Sim Sim

Sim

Sim

Nmero de N cpias do SO

Como sua Arquivos Mensagens comunicao? Compartilhados Protocolos Requeridos? Sim Sim

Memria Compartilhada No

Uma nica fila No de execuo?

No

Sim

Arquivos tem a Usualmente no Sim (para Sim mesma ter uma semntica? imagem nica do sistema)

Aspectos de Projetos
To importante quanto saber as caractersticas e vantagens de um SD, saber como implementar essas caractersticas e tambm como cada caracterstica influencia no comportamento global do sistema. Vamos discutir algumas caractersticas fundamentais para o projeto

Transparncia
Ok, sabemos o que a transparncia. Mas como conseguimos a transparncia? Como podemos obter tal imagem do sistema? Vamos tentar discutir dois diferentes nveis de transparncia: Ocultar do usurio final o fato deles estarem tratando com um sistema distribudo. o Ex: Make no UNIX (usado para compilar arquivos de um diretrio) o usurio no precisa ser informado que as compilaes podero ocorrer em vrias mquinas em paralelo para acelerar o tempo. Simplesmente o usurio digita make e o cdigo executvel gerado. Todo gerenciamento da distribuio feito pelo prprio sistema operacional. Transparncia para os programadores (nvel mais baixo) interface das chamadas do sistema pode ser projetada de tal forma que a existncia de mltiplos processadores no seja visvel. Isso significa que programadores podem desenvolver suas aplicaes realizando chamadas de sistema (disponveis atravs de bibliotecas) cuja implementao no ser realizada localmente, e sim em outra (ou outras) mquina(s).

Independente do nvel de transparncia, tais nveis podem ser aplicados aos diversos tipos transparncia (localizao, migrao, replicao, concorrncia e paralelismo)

Flexibilidade
Pode-se implementar um sistema distribudo fazendo uso dos recursos do SO disponveis. E isso obtido atravs da organizao do kernel do SO, especializando as mquinas ou tornado-as mais genricas. Tipos de Organizao do Kernel Kernel Monoltico - concentra todas as funcionalidades, embora no necessariamente sejam todas utilizadas (muito usado em sistemas de alto desempenho). Individualmente cada mquina pode se tornar um pouco inchada por abrigar recursos que na maior parte no seriam utilizados, porm, em caso de falha de um componente do sistema, qualquer outro capacitado a assumir a funo do elemento falho; Microkernel kernel que executa o mnimo de funes (I/O, criao e destruio de processos) para que mquinas com propsitos especficos sejam configuradas (mais flexvel). Isso muito usado em sistemas cujo objetivo final seja o desempenho. Pode-se configurar o kernel para que seja o mais enxuto possvel, porm mquinas com propsitos especficos devem ter mdulos adicionados. Se uma dessas mquinas eventualmente falhar, nenhuma outra pode substitu-la.

A discusso em torno do kernel monoltico e microkernel surge na necessidade dos seguintes aspectos: Se tivermos um kernel enxuto, o sistema pode render muito mais do que tendo funcionalidades que devero ser monitoradas, mas ao mesmo tempo, no sero usadas, desperdiando o uso da CPU.

Confiabilidade
Na Teoria - se uma mquina falha, qualquer outra realiza a sua tarefa. Na Prtica O mundo no to romntico assim. O funcionamento do sistema conta com a cooperao de

alguns servidores especficos para que um assuma o controle caso outro falhe, ou seja, um conjunto de servidores deve funcionar para que o sistema distribudo funcione como um todo. Portanto podemos definir Confiabilidade como sendo a probabilidade de um sistema estar operando normalmente em um intervalo de tempo. Para ser confivel, um sistema deve possuir alta disponibilidade e segurana (informaes sempre acessveis).

Disponibilidade
Frao de tempo que o sistema usvel. Disponibilidade pode ser aumentada por meio de redundncia: pores de hardware ou software podem ser replicados (multiplicados). Quanto maior o nmero de cpias de software, obviamente maior a disponibilidade, porm, maior a probabilidade de inconsistncias, pois o ideal que todas as rplicas sejam rigorosamente idnticas. Para tanto, dois recursos so fundamentais Segurana: proteo informaes, etc. contra violabilidade, integridade das

Tolerncia a Falhas: capacidade do sistema de esconder eventuais falhas dos usurios.

Desempenho
O desempenho de uma particular aplicao executando em um SD no deve ser pior que em um sistema centralizado. Medidas de desempenho: Tempo de resposta unidades de tempo (segundos, minutos, horas) Throughput (nmero de Jobs/tarefas por intervalo de tempo). Em resumo, quantos processos um sistema pode executar durante um intervalo de tempo Quantidade de recursos consumidos pela rede. J que a rede um fator impeditivo para o desempenho (ela compartilhada e pode ficar congestionada), um sistema que

faz uso muito intenso da rede pode ter seu desempenho afetado. Resultados de benchmarks. Benchmarks so aplicaes especficas para levar o sistema em condies extremas, seja fazendo uso intenso de CPU, disco, perifricos, rede, entre outros. Estas aplicaes geram dados estatsticos de suas execues que posteriormente so analisados para comprovar a eficincia do sistema.

A comunicao um fator bastante influente no desempenho dos sistemas distribudos, pois la relativamente lenta (1 mseg para enviar uma mensagem e receber uma resposta). Para minimizar essa influncia da rede de interconexo devemos tentar diminuir a quantidade de mensagens trocadas entre os ns e explorar o paralelismo das aplicaes. Vamos entender os tipos de paralelismo Paralelismo de granularidade fina - grande nmero de pequenas computaes, altamente interativas umas com as outras no apresenta bons resultados ao paralelizar; Paralelismo de granularidade grossa - grandes computaes, poucas interaes, poucos dados apresenta bons resultados ao paralelizar.

nesse ponto que o desafio torna-se maior. Como buscar aplicaes que processem muito e se comuniquem pouco? Como fazer com que o tempo de comunicao seja irrelevante se comparado com o tempo de processamento? Toda e qualquer aplicao tem essa caracterstica? Fica a reflexo.

Escalabilidade
O sistema pode funcionar bem com centenas de processadores e falhar para milhares de processadores. Normalmente, a escalabilidade inversamente proporcional a performance. No entanto, uma boa arquitetura deve permitir a escalabilidade sem que a performance seja linearmente diminuda. Existe inclusive uma brincadeira que costumamos fazer comparando Escalabilidade ao queijo suo.

Quanto mais queijo, mais buracos no queijo. E quanto mais buracos no queijo, menos queijo tem. Portanto, quanto mais queijo, temos menos queijo. claro que essa tentativa de inferncia lgica absurda, mas podemos tentar fazer o seguinte paralelo com o projeto de um SD Se precisarmos de mais desempenho, o ideal acoplarmos mais mquinas no sistema. Entretanto, o aumento de mquinas implica em um grau de congestionamento maior da rede. Congestionamentos na rede comprometem o desempenho (principalmente se a granularidade for afetada). Portanto, o feitio pode se virar contra o feiticeiro, caso o projeto de rede e a caracterstica da aplicao tiverem um grau mximo de crescimento (isso medido em muitos casos apenas com aplicaes especficas).

Consideraes Finais
No uma tarefa das mais simples projetar e implementar um Sistema Distribudo. Vimos vrias propostas de como tornar as caractersticas de um SD efetivas, porm muitas delas tem sua contrapartida. esse equilbrio que sempre devemos buscar e todos os questionamentos discutidos ao longo deste captulo so fundamentais para ampliar a viso do projetista de um SD.

S-ar putea să vă placă și