You are on page 1of 225

Pontifícia Universidade Católica de São Paulo

PUC-SP

Everaldo Lopes Silva

Proposta de uma infraestrutura de baixo custo com multiprocessamento e utilizando software aberto

Mestrado em tecnologias da inteligência e design digital

São Paulo 2012

Pontifícia Universidade Católica de São Paulo
PUC-SP

Everaldo Lopes Silva

Proposta de uma infraestrutura de baixo custo com multiprocessamento e utilizando software aberto

Mestrado em tecnologias da inteligência e design digital Dissertação apresentada à Banca Examinadora da Pontifícia Universidade Católica de São Paulo, como exigência parcial para obtenção do título de Mestre em Tecnologias da Inteligência e Design Digital sob a orientação do Prof. Dr. Demi Getschko.

São Paulo 2012

FICHA CATALOGRÁFICA

AUTORIZO A CÓPIA E DIVULGAÇÃO TOTAL OU PARCIAL DESTE DOCUMENTO PARA FINS DE ESTUDO OU ACADÊMICOS, DESDE QUE CITADA A FONTE.

LOPES SILVA, Everaldo. Proposta de uma infraestrutura de baixo custo com multiprocessamento e utilizando software aberto / Everaldo Lopes Silva; orientador Demi Getschko. -- São Paulo, 2012. 225f.

Dissertação (Mestrado). Área de Concentração: PUC-SP - TIDD.

1. Inteligência Coletiva

CDD ___.___

iii

Everaldo Lopes Silva

PROPOSTA DE UMA INFRAESTRUTURA DE BAIXO CUSTO COM MULTIPROCESSAMENTO E UTILIZANDO SOFTWARE ABERTO

Este trabalho refere-se à infraestrutura que seria um conjunto computadores/rede de comunicação onde se executaria sistemas de inteligência e Design Digital dentro do Programa de Estudos Pós-Graduados em Tecnologias da Inteligência e Design Digital - TIDD, com área de concentração em “Inteligência Coletiva”, da Pontifícia Universidade Católica de São Paulo – PUC/SP.

APROVADO em: __ / __ / __

_________________________

_________________________

_________________________

PROF. DR. DEMI GETSCHKO PUC-SP (ORIENTADOR)

BRASIL

iv

por iniciarem-me no interesse pela leitura e estudo. colegas e a Edna da Secretaria do TIDD.A meus pais. DEDICO v . OFEREÇO Aos professores.

Demi Getschko pelos conselhos. os questionamentos que fizeram refletir sobre o conteúdo desse trabalho e o posicionamento do mesmo dentro do cenário da Tecnologia da Informação atual.AGRADECIMENTOS Agradeço ao professor Dr. vi . sobretudo.

" Doutrina e Convênios 88:118 . buscai diligentemente e ensinai-vos uns aos outros palavras de sabedoria. pelo estudo e também pela fé. procurai conhecimento..“..Ano 1832 vii . sim nos melhores livros buscai palavras de sabedoria. sim.

As medições e análise servirão como base para análise para a verificação se um cluster de Linux seria uma infraestrutura viável em termos técnicos e financeiros para aplicações de Inteligência Artificial e Design Digital. Como parte do trabalho. pois através dos resultados da experimentação e da análise técnica se poderá aplicar o conhecimento obtido em situações semelhantes. O método de pesquisa será naturalmente a pesquisa experimental e o método de abordagem será indutivo. Serão apresentados alguns modelos de cluster em Linux. Palavras-chave: Distribuído Computação. Sistemas Operacionais. tratando especialmente de plataformas com o sistema operacional Linux. Executaremos programas de Inteligência Artificial e Design Digital nesse cluster e compararemos o seu desempenho com apenas um computador executando esses mesmos programas.RESUMO Esta dissertação visa identificar os aspectos técnicos e teóricos que envolvem a utilização de cluster de computadores. Redes. reconhecendo suas vantagens e desvantagens e por fim indicando o modelo escolhido com a devida justificativa. Processamento viii . proporemos um laboratório com um agrupamento de dois equipamentos conectados com duas interfaces de rede gigabit ethernet em cada um e um computador trabalhando isoladamente. Para contextualizar a atividade experimental abordaremos as teorias de pesquisa mais significativas e contemporâneas para que se estabeleça de maneira clara a abordagem científica que norteará o trabalho como um todo.

ABSTRACT This dissertation has the objective of identifying the technical aspects that deal with the utilization of computer cluster. It will be presented some cluster models in Linux. recognizing its advantages and its disadvantages and finally indicating the chosen model with the due justification. The measuring and analysis will indicate if the Linux cluster would be a feasible infrastructure in technical and financial terms for AI and Digital Design application. Computation. Distributed Systems ix . we will propose a laboratory with a cluster of two equipments connected with two gigabit interfaces each one and one computer working stand-alone. As part of this work. specially the platforms with Linux operational system. Networking. For putting the experimental activity in the correct context. it will be used the more significant and contemporary research theories to establish in a clear way the scientific approach that it will lead the whole work. comparing its performance with only one computer running the same programs. It will run Artificial Intelligence and Digital Design programs in this cluster. for through the results of the experimentation and technical analysis. it will be able to apply the knowledge achieved in others similar environments. The research method will be naturally the experimental and the approach method will be inductive. Keywords: Computation.

Organização de arquivos multimídia não contíguos em discos rígidos Figura 5 .Representação de Grafos para resolução do problema do “Drink dos Filósofos” Figura 15 .Representação da Multiprogamação N-way Figura 16 .Digrama de explicativo de Race Passage Figura 14 .Medição de banda disponível via Iperf x .Esquema lógico simplificado de um cluster Beowulf Figura 17 .Diagrama de blocos de exemplo de exemplo de RPC em Sistema Microsoft Figura 13 .Comunicação entre servidor e cliente em RPC Figura 9 .Memória Compartilhada Distribuída (DSM) Figura 10 .Comunicação entre servidor e cliente em Sockets Figura 11 .Comparação entre o modelo ISO/OSI o protocolo TCP-IP Figura 7 .Intercalamento de pacotes de dados e pacotes multimídia (Interleaving) Figura 4 .Esquema lógico do laboratório Figura 19 .Organização de arquivos multimídia não contíguos em discos rígidos Figura 6 .Intercâmbio de pacotes em sistemas multimídia Figura 3 .LISTA DE FIGURAS Figura 1 .Primitivas send e receive em passagem de mensagens (MPI) Figura 8 .Esquema lógico simplificado de um cluster OSCAR Figura 18 .Codificação de sinal de áudio analógico para sinal de áudio digital Figura 2 .Diagrama de blocos simplificado de RPC em Sistema Microsoft Figura 12 .Fotografia do laboratório Figura 20 .

Medições de utilização CPU.pov no Nó 00 Figura 25 .Finalização do teste de memória sem apresentar nenhum erro Figura 28 . Memória e Rede no Nó 00 Figura 24 .Evidência de o cluster estar operacional Figura 23 .Tempo de renderização do Benchmark.pov no Nó 01 Figura 27 .Medição do uso da memória durante a execução do memtester Figura 29 .Tempo de renderização do Benchmark.Execução da aplicação Breve no Nó 01 Figura 26 .Execução das aplicações Breve e PovRay no Nó 00 Figura 22 .Resultado do comando “ps” em cluster com o Breve xi .Figura 21 .Resultado do comando “ps” em ambiente monoprocessado com o Breve Figura 30 .

Instância benchmark.Gráfico da quantidade de pesquisa sobre cluster.Medição de desempenho utilizando SHA1 Gráfico 5 .Medição de desempenho utilizando Zlib Gráfico 2 .pov em cluster Gráfico 9 . grid e cloud no Google xii .Medição de tempo de execução do PovRay Gráfico 8 .Medição de desempenho utilizando Fibonacci Gráfico 3 .Medição de desempenho utilizando Blowfish Gráfico 6 .pov em computador standalone Gráfico 10 .Medição de desempenho utilizando Raytracing Gráfico 7 .LISTA DE GRÁFICOS Gráfico 1 .Instâncias benchmark.Medição de desempenho utilizando MD5 Gráfico 4 .

Comparação dos custos de implementação do cluster e a contratação de cloud xiii .Valores para a contratação de serviço de cloud Tabela 4 .LISTA DE TABELAS Tabela 1 .Valores para a implementação do cluster do laboratório Tabela 3 .Arquivos criados na instalação do Kerrighed Tabela 2 .

LISTA DE FÓRMULAS Fórmula 1 .Performance teórica de pico Fórmula 3 .Fórmula para escalonamento para sistemas em tempo real periódicos Fórmula 2 .Fórmula de Amdahl Fórmula 5 .Ganho de velocidade Fórmula 4 .Variação da fórmula de Amdahl xiv .

LISTA DE SIGLAS E ACRÔNIMOS ACM: Association for Computing Machinery API: Application Programming Interface BOINC: Berkeley Open Infrastructure for Network Computing CAPTCHA: Completely Automated Public Turing test to tell Computers and Humans Apart CIFS: Common Internet File System CMG: Computer Measurement Group CRT: Cathode Ray Tube CVSS: Common Vulnerability Scoring System DARPA: Defense Advanced Research Projects Agency DCT: Discrete Cosine Transform DDoS: Distributed Denial of Service DFSA: Direct File System Access DHCP: Dynamic Host Configuration Protocol DoS: Denial of Service DSL: Digital subscriber Line DSM: Distributed Shared Memory EDF: Earliest Deadline First FEPAF: Fundação de Estudos e Pesquisas Agrícolas e Florestais FTP: File Transfer Protocol GPU: Graphics Processing Unit HPC: High-Performance Computing xv .

HTTP: Hypertext Transfer Protocol IA: Inteligência Artificial IaaS: Infrastructure as a Service IANA: Internet Assigned Numbers Authority IDL: Interface Definition Language IGMP: Internet Group Management Protocol INRIA: Institut National de Recherche en Informatique et en Automatique IPC: Interprocess Communication IS-IS: Intermediate System to Intermediate System ISO/OSI: International Standards Organization/Open Systems Interconnection JFIF: JPEG File Interchange Format JPEG: Joint Photographic Experts Group LUI: Linux Utility for cluster InstalI LVS: Linux Virtual Server MAC: Medium Access Control Mosix: Multicomputer Operating System UnIX MP3: MPEG Layer 3 MPEG: Motion Picture Experts Group MPI: Message Passing Interface MPLS: Multi-protocol Label Switching MPP: Massively Parallel Processing NBX: Nugo Black Box NFS: Network File System xvi .

NP: Nondeterministic Polynomial Time NSCS: National Supercomputing Centre in Shenzhen NSF: National Science Foundation NTSC: National Television System Committee NUGO: Nutrigenomics Organization OSCAR: Open Source Cluster Application Resources PAL: Phase Alternating Line PBS: Portable Batch System PCM: Pulse Code Modulation PCM: Pulse-Code Modulation PDU: Protocol Data Unit PovRay: Persistence of Vision Ray Tracer PPM: Preempetive Process Migration PVFS: Parallel Virtual File System PVFS: Parallel Virtual File System PVM: Parallel Virtual Machine QoS: Quality of Service RMS: Rate Monotonic Scheduling ROI: Return of Investment RPC: Remote Procedure Call RPM: Red Hat Package Manager RSTP: Real-time Streaming Protocol RSVP: Resource Reservation Protocol xvii .

RTCP: RTP Control Protocol RTP: Real Time Protocol RTP: Real-time Protocol RTSP: Real Time Streaming Protocol SDSC: San Diego Supercomputer Center SIS: System Installation Suite SLA: Service-Level Agreement SMP: Symmetric Multiprocessing SMT: Simultaneous Multithreading SMTP: Simple Mail Transfer Protocol SONET: Synchronous Digital NETwork SSI: Single System Image TCP-IP: Transport Control Protocol – Internet Protocol TMT: Testing and Monitoring Tool UDP: User Datagram Protocol UHN: Unique Home-Node UTP: Unshielded Twisted Pair VLAN: Virtual Local Area Network VNC: Virtual Network Computing VoD: Vídeo on Demand VoIP: Voice over IP WFG: Wait-For-Graph XML: Extensible Markup Language xviii .

............ viii ABSTRACT ................................................................. 137 Projeto Rocks .................. 28 Características de um Cluster de Computadores .........................SUMÁRIO FICHA CATALOGRÁFICA ................................................................ xiv LISTA DE SIGLAS E ACRÔNIMOS ..... Flynn (FLYNN................................................................................................................................................................................................................................................... 88 Gerenciamento de Memória: ......... 163 Capítulo 3 – Apresentação do Laboratório ........................................................................................................................ 132 Tipos de clusters .................................................................................. 82 Redes de Computadores ................................................................................................................................................................................................................................ 21 METODOLOGIA .......... 133 Cluster Beowulf: ................................................................................................................. xii LISTA DE TABELAS ...................................................................................................................................................... 131 Capítulo 2 – Apresentação de Cluster em Linux na Modalidade HPC com ênfase em Kerrighed ............................................................................ 99 Dificuldades na manipulação de processos num ambiente de processamento distribuído ..................................................................... 62 Fundamentos de Sistemas Operacionais com Processamento Distribuído ............................................................................................................................ 151 Conclusão do Capítulo ............................................................................................... 93 Dispositivos de Entrada/Saída:......................................................................................................................................................................................................... 139 Cluster OpenMosix ........................................................................................................................... 1972) das arquiteturas de Computadores .................................................................................................... 43 Escalonamento de processos ou threads ................................................................................... 168 Descrição da configuração do Cluster Kerrighed implementada .................................................................................................................................. 170 19 ....................................................... 28 Fundamentos dos Sistemas Operacionais Convencionais ................................................................................................................................................... 27 Capítulo 1 – Conceitos teóricos sobre processamento Monoprocessado e Distribuído ...................................................... xv INTRODUÇÃO ................................... 87 RPC (Remote Procedure Call) e MPI (Message Passing Interface)................................................................... iii AGRADECIMENTOS ............................................................................................. 164 Descrição do Sistema Operacional utilizado ................................................................................................................................................................................................... 96 Arquivos: ............................................................................................ 97 Chamadas de Sistema (System Calls) e Comunicação Interprocessos: ................................................................................ xiii LISTA DE FÓRMULAS .......................................................................................................................................................................................................................................................................................................................................................................... 113 Aplicações Multimídia em Sistemas Distribuídos .. 55 Escalonamento em sistemas em tempo real ........................................................................................................................................... 33 Dificuldades na manipulação de processos num ambiente monoprocessado ............................................ 82 Processos e Threads.......................... 124 Conclusão do Capítulo ...................... vi RESUMO .................. 164 Descrição do hardware utilizado............................................................................................................. ix LISTA DE FIGURAS ................................. 141 Cluster Kerrighed................................................................................................. 132 Classificação de Michael J............... 134 Cluster OSCAR (Open Source Cluster Application Resources): ..................................................................... x LISTA DE GRÁFICOS ................................................................................................................................................................

.......................................................................................................... .................................................................... 177 Performance teórica de pico ........................................................................................................................................................................... 188 Medição e análise do sistema em cluster e monoprocessado utilizando um aplicativo de Design Digital (PovRay) ................................................................................................................................................................................................................................................................................................................................................Descrição dos aplicativos para testes ............................... 176 Capítulo 4 – Medições e análises ....................................................................................................................................................... 222 20 ..................................... 194 Capítulo 5 – Conclusão......................... 213 Um olhar para o futuro ......................................................................................................................................................... 179 Abordagem e ferramentas de análise do desempenho do cluster.................................................................................................. 186 Medição e análise do sistema em cluster e nos nós com ferramentas de benchmark apresentadas no aplicativo hardinfo.... 213 Um olhar para o presente ............................................................................................ 205 Capítulo 6 ......................................................................................... 180 Análise geral dos resultados............................................................................................... 192 Medição e análise do sistema em cluster e monoprocessado utilizando um aplicativo de Inteligência Artificial (Breve) ................................................. 178 Performance da rede ......................................... 177 Performance das Aplicações ........................................................................................................................................................................................................................................................................................................... 219 GLOSSÁRIO ........................................ 181 Estresse do cluster e análise para confirmar a efetiva funcionalidade do mesmo..................................................................................................................................... 218 Referências: ........................................ 199 Viabilidade Técnica do cluster Kerrighed .... 203 Considerações Finais .................................................Um olhar para o presente e um olhar para o futuro da Tecnologia de Cluster ................................................ 216 Conclusão do capítulo ........................................................... 182 Teste e medição de memória ........................ 181 Medição e análise do throughput real das conexões de rede........................................................................................................................................... 171 Conclusão do capítulo ....................................... 196 Viabilidade Econômica do Cluster Kerrighed ...................................................................................................................................

estabelecendo os limites e abrangência de cada uma dessas atividades. E por fim a tecnologia que é ciência e a engenharia aplicada visando à provisão de soluções para as necessidades humanas pontuais. especialmente na criação de operações de natureza binária e na transmissão de informações em meios elétricos e óticos. 21 . A engenharia busca soluções para problemas de natureza mais geral. a engenharia e a tecnologia. softwares e equipamentos de rede. Usando como exemplo o próprio tema da pesquisa. Ele coloca: “Em termos gerais. uma e outra vez. que procura descrever o mundo físico e suas propriedades através de uma metodologia. sistemas operacionais. como os transistores e a penicilina. utilizando o conhecimento gerado pela ciência dados certos recursos e limites. no nosso caso. mas em ambiente de laboratório e não em larga escala. buscando as soluções diretamente do repositório de conhecimento da própria ciência. mas precisamos circunscrever o significado de tecnologia em relação aos conceitos de ciência e engenharia. Importa ser cauteloso: trata-se de grandes exceções. usualmente utilizando o conhecimento construído pela engenharia. baseados no conhecimento e técnicas desenvolvidas pela engenharia. A tecnologia desenvolve produtos para uso geral e em larga escala. softwares e equipamentos de comunicação de dados baseados nos conceitos científicos. microcomputadores. a ciência descobriu as propriedades dos semicondutores e sua aplicação em circuitos digitais. mas em algumas ocasiões.INTRODUÇÃO Antes de adentrar na questão principal do trabalho. segundo Derek de Solla Price (PRICE. Quanto ao tema. a ciência não tem prestado grande auxílio à tecnologia. 1976). também com objetivos e motivações muito diferentes. é importante salientar que estamos trabalhando no campo da tecnologia. Numa visão conceitual podemos estabelecer que “ciência” é um corpo de conhecimento em determinada área de pesquisa. Porém apesar da área de pesquisa em questão ter uma ligação relativamente clara e interdependente entre a ciência. A engenharia desenvolve computadores. isso não ocorre de modo geral. deparemos com eventos anômalos e traumatizantes.” Realmente existe um hiato muito grande entre essas duas atividades. onde atuam pessoas com perfil intelectual e psicológico muito distinto. não a regra. faz-se necessário estabelecermos alguns conceitos relacionados ao tema e o método de abordagem do mesmo. embora.

segundo ele. procurarei nesse trabalho utilizar a metodologia e a visão científica para analisar a pesquisa proposta. “mesmo após observar uma associação constante ou frequente de objetos. pois. podemos seguir em frente com esse prólogo. não temos motivo para inferir algo que se refira a um objeto que não experimentamos”. sabem das dificuldades encontradas ao se traduzir algumas palavras ou termos em inglês para a Língua Portuguesa. não seriam adequadas. Estabelecido os conceitos. Apesar de adepto à experimentação. 1999) a experimentação e em seguida a conclusão obtida através do método indutivo. não sua visão. porém apresentaremos a palavra ou o termo em inglês caso percebamos que a tradução não reflete o significado original da palavra em sua plenitude. 1 Aqueles que já atuam e convivem no meio e em atividades relacionadas à Tecnologia da Informação. pois acredito que uma abordagem científica baseada num trabalho empírico-indutivo. Nesse trabalho iremos traduzir.Apesar da consciência de que sou um tecnologista. Palavras que já existem nos principais dicionários da Língua Portuguesa não serão destacadas nesse trabalho. conseguirá obter melhores resultados do que um simples benchmarking1. pois. segundo o nosso juízo. consequentemente. buscando o mesmo sentido que o original. Hume não aceitava o método indutivo. 22 . Em outras palavras. baseada no hábito de acreditar em leis. com as características próprias desse perfil. não pode haver argumentos lógicos válidos que nos permitam afirmar que “aqueles casos dos quais não tivemos experiência alguma se assemelham àqueles que já experimentamos anteriormente”. os termos em inglês com maior clareza e acuidade possível. essa conclusão será de natureza psicológica. abordando a agora a questão da metodologia indutiva. para Hume (HUME. em assertivas que afirmam a regularidade de certos eventos.

por conseguinte a indução. 1999). 23 . É importante ressaltar que minha pesquisa está totalmente no domínio da tecnologia e que alguns conceitos até agora apresentados referem-se mais propriamente à ciência. Ele também estabelece que as teorias precisam ser testadas através de experimentos. mas dentro de limites para não invalidar de maneira precipitada a teoria como um todo. estabelecerei a minha estratégia de pesquisa. 1978) na sua teoria da estrutura das revoluções científicas coloca que o princípio de falsificação de Popper é semelhante ao que na sua teoria ele chama de experiências anômalas. isto é.Popper (POPPER. Diante dessas teorias e ideias. todas as teorias deveriam ser sempre rejeitadas”. preparam o caminho para uma nova teoria”. mas também tem reservas ao método indutivo e apresenta o que ele chama da teoria das “conjecturas e refutações” onde estabelece que ao invés de esperar passivamente que as repetições nos imponham suas regularidades e. 1994) questiona essa posição. de modo ativo impor regularidades ao mundo. Porém. Também estabelecerei questionamentos que testem a “falsidade” das minhas proposições. tentando identificar similaridades e interpretá-las em termos da teoria que defendemos. Como Popper coloca “Só a falsidade de uma teoria pode ser inferida da evidência empírica. mas não com o intuito de prová-las mas sim de refutá-las. nós devemos. Apesar disso. ao evocarem crises. procurando fazê-lo se realmente a similaridade dos elementos comparados seja significativa e clara. Apenas para encerrar essas considerações sobre o método experimental. que afirma que. segundo ele. existe um conhecimento “a priori” que não é derivado de nenhuma experiência que se contrapõe ao conhecimento empírico ou “a posteriori”. considero salutar aplicar essas ideias e considerações a minha pesquisa para que a mesma se torne mais consistente e circunspecta. Assim estarei atento quanto o grau de subjetividade na análise dos testes experimentais mesmo que os mesmos resultados se repitam numa frequência significativa assim como terei critério ao inferir um resultado ou conclusão. na visão de Kuhn “se todo e qualquer fracasso na tentativa de adaptar teoria e dados fosse motivo para a rejeição de teorias. inferência que é puramente dedutiva”. Kuhn (KUHN. “experiências que. apesar da experiência produzir conhecimento. gostaria de acrescentar apenas a visão de Kant (KANT.

por exemplo. A história de cluster de computadores se confunde com a história das próprias redes. Outros clusters que tiveram alguma notoriedade foram o Tandem Himalaya por volta de 1994 e o IBM S/390 Parallel Sysplex também no mesmo período.640 processadores instalado no NSCS (National Supercomputing Centre in Shenzhen) na China. a viabilidade dos sistemas de cluster de modo geral. podemos introduzir o tema de minha pesquisa. se acessarmos hoje o site www. Assim esse não é o foco da pesquisa.org que estabelece um ranking de computadores mais poderosos do mundo. Os primeiros clusters comerciais foram o ARCnet desenvolvido pela Datapoint em 1977 e o VAX cluster desenvolvido pela DEC em 1984. pois apenas através de redes de comunicação que foi possível computadores independentes trabalharem de maneira paralela como uma única entidade. 24 . Estabelecidas as diretrizes metodológicas da pesquisa. temos um cluster na quarta posição com 120.top500. que é verificar empiricamente se um sistema de cluster de computadores com o sistema operacional Linux seria uma infraestrutura viável para aplicações de Design Digital e Inteligência Artificial.Terei também ciência que iniciarei os trabalhos com um conhecimento “a priori” impuro. pois é fruto de certo empirismo obtido na minha experiência técnica. mas verificar de maneira metódica o comportamento do mesmo ao executar aplicações especialistas de Design Digital e Inteligência Artificial com todas suas particularidades e características semelhantes em relação a aplicações de outra natureza. Sem dúvida que sistemas de cluster já são largamente usados tanto nas instituições acadêmicas com nas corporações. segundo seus critérios.

Apresentaremos também as aplicações que serão executadas nesse sistema e suas características básicas no que concerne ao modo de processamento e alocação de recursos. No sexto e último capítulo será apresentado como um anexo. tempo de resposta. a carga em cada nó do cluster. assim como as configurações aplicadas aos computadores. que envolverá em linhas gerais. executando as mesmas aplicações. 25 . apresentaremos o nosso laboratório com uma descrição detalhada de cada item do mesmo. No capítulo 2.Com o surgimento da PVM (Parallel Virtual Machine) a construção de cluster tornou-se mais acessível por ser uma arquitetura aberta (open source) baseada em TCP-IP. de banda nas conexões de rede. as constatações e conclusões apresentadas nesse trabalho poderão ser aplicadas em outras áreas da Tecnologia da Informação. utilizando como contraponto tecnologias alternativas de computação massiva como computação em grid e computação em cloud. apresentaremos os conceitos de sistemas distribuídos tendo como contraponto os sistemas monoprocessados. No quinto capítulo. analisaremos os resultados tendo como referência um computador com as mesmas características dos nós que compõe o cluster. subsídios para entender as especificidades técnicas dessa matéria. casos que representarão o estado da arte em tecnologia de cluster com um olhar para o presente e um olhar para o futuro. como por exemplo. No capítulo 1. de memória. abordaremos os principais modelos de cluster em sistemas operacionais Linux. descreveremos os testes de execução das aplicações previamente escolhidas e a devida medição. No capítulo 4. Após esse sucinto histórico da tecnologia. como suporte para a realização de suas atividades. podendo assim compor cluster com computadores heterogêneos totalmente transparentes para o usuário final. A fundamentação teórica desse trabalho visa ajudar aos pesquisadores e profissionais que não atuam com infraestrutura. No capítulo 3. esmiuçando o que será o foco do nosso estudo que é “Kerrighed”. etc. podemos apresentar como esse trabalho será estruturado. Apesar do foco desse trabalho sejam aplicações de Design Digital e Inteligência Artificial. Após a execução e medição dos programas. a partir da análise realizada no capítulo anterior. o desenvolvimento de códigos para Design Digital e Inteligência Artificial. utilização de CPU. chegaremos à conclusão ou pelo menos em indicações sobre a viabilidade do uso do sistema “Kerrighed” na execução de sistemas de Design Digital e Inteligência Artificial que foram executados em laboratório.

assim consideraremos a agregação de 80% da capacidade computacional a cada novo nó inserido ao cluster. fomos aconselhados a trabalhar com o cluster “Kerrighed” que também é SSI (Single System Image). Assim ao iniciarmos os trabalhos de laboratório. optamos por utilizar pelo cluster em Linux “Kerrighed”. sendo um projeto em franca atividade de implementação e aperfeiçoamento. utilizando software aberto é viável técnica e financeiramente para a execução de aplicações HPC com ênfase em Inteligência Artificial e Design Digital. Objetivo final desse trabalho é verificar se uma plataforma de baixo custo de hardware. Porém sabemos que essa proposição não corresponde à realidade. Iremos testar essa hipótese com a realização desse laboratório. a ponto de considerarmos um cluster de servidores Linux uma infraestrutura viável para implementação de aplicações de Inteligência Artificial e Design Digital. isto é. aumentaríamos linearmente o desempenho do mesmo. dificuldade das aplicações realizarem processamento paralelo. na mesma medida em que adicionamos computadores ao cluster. gerenciamento de memória em ambientes distribuídos e os próprios recursos computacionais para as funcionalidades do cluster. Inicialmente adotamos o projeto “OpenMosix” como sistema de cluster a ser utilizado no laboratório idealizado para esse trabalho. porém o projeto foi encerrado em março de 2008 pelo professor Moshe Bar. prevendo alguma perda devido à latência da rede. Iniciamos os trabalhos de implementação do projeto em laboratório e ao consultar um dos autores mais proeminentes no Brasil em cluster em Linux.Uma proposição inicial seria que o sistema de cluster aumentaria a capacidade de processamento linearmente. 26 . Marcos Pitanga.

27 . analisar a viabilidade da utilização de cluster SSI em ambientes de pequeno e médio porte que poderá apresentar-se como uma opção viável em termos técnicos e financeiros para alojar esses tipos de aplicações.METODOLOGIA Trabalho baseado em uma abordagem empírica indutiva. buscando através de um laboratório que consiste de um cluster Linux e aplicações com ênfase em Inteligência Artificial e Design Digital.

Recebeu o título de bacharelado pelo MIT e o doutorado pela UC Berkeley em 1971. 28 . 3 Gregory Y. Pfister obteve seu doutorado no MIT. Por muitos anos. um sistema operacional baseado no Unix com propósito educacional. Acreditamos que essa fundamentação teórica será de grande valia ao estudarmos o foco desse trabalho em termos de solução. e bastante conhecido por seus livros sobre ciência da computação. em se tratando de cluster de alto desempenho. na Universidade Vrije. como por exemplo.Capítulo 1 – Conceitos teóricos sobre processamento Monoprocessado e Distribuído Considerações iniciais do capítulo Além de apresentar as características básicas de um sistema em cluster. apontando diferenças. as teorias convencionais sempre no servirão de base para o entendimento de novas abordagens seja por semelhança seja por contraponto. Atualmente ministra aulas sobre Organização de Computadores e Sistemas Operacionais. Tendo sido instrutor nessa instituição. Berkeley. semelhanças e relações. que apesar de possuir técnicas próprias para algumas das disciplinas da teoria da computação. esse capítulo tem como objetivo apresentar os componentes. pois além do tema ser controverso. Características de um Cluster de Computadores Tanenbaum2 (TANENBAUM. Pfister3 que fazem distinção entre sistemas distribuídos e clusters. tecnologias e desafios intrínsecos da computação monoprocessada e distribuída. Autor do livro “In Search of Clusters”. Amsterdã nos Países Baixos. a alocação e o mapeamento de memória. essa distinção não se aplica a nossa abordagem do assunto. Ele é o autor do Minix. que seria o sistema em cluster Kerrighed. 1995) coloca que “um sistema distribuído é uma coleção de computadores independentes que parecem aos usuários do sistema como um só computador”. Existem alguns autores como Gregory F. Ele detém inúmeras patentes em processamento distribuído. assim como professor assistente na Universidade da California. Nasceu na cidade de Nova Iorque e cresceu em White Plains no estado de Nova Iorque. ele foi membro da equipe de Pesquisa e Desenvolvimento da IBM num nível sênior. mas nesse trabalho não faremos essa diferenciação. 2 Andrew Stuart Tanenbaum é o chefe do Departamento de sistemas de computação.

A transparência pode ser vista sob os seguintes aspectos: Transparência de localização: Os usuários não podem dizer onde os recursos estão localizados. quando na realidade há um cluster de computadores realizando as tarefas. 1998) afirma que clusters são geralmente grupos de computadores homogêneos em menor escala. porém os clusters atualmente podem ser compostos de máquinas heterogêneas e de um número grande de computadores. nas quais o cluster atua como uma única máquina. dedicados a um número pequeno e bem definido de tarefas. 1995) identifica características essenciais no desenvolvimento de sistemas distribuídos que são: Transparência Flexibilidade Confiabilidade Desempenho Escalabilidade Transparência Transparência é capacidade do sistema em dar a impressão ao usuário de que ele está acessando apenas um computador convencional. Transparência de replicação: Os usuários não podem dizer quantas cópias dos recursos existem. assim a definição de Pfister não se aplica ao nosso estudo e concepção de um cluster. Tanenbaum (TANENBAUM. Transparência de migração: Os recursos podem se mover a qualquer momento sem mudarem seus nomes.Apenas título de registro Pfister (PFISTER. 29 . Transparência de concorrência: Os usuários podem compartilhar os recursos automaticamente. Transparência de paralelismo: As atividades ocorrem paralelamente sem os usuários o saberem.

Diferentemente dos sistemas monolíticos. tendo controle sobre sistemas de arquivos. O primeiro possuindo a maioria dos serviços em si mesmo. Pequena quantidade processos de baixo nível responsáveis por gerenciamento e scheduling. Segue algumas funções básicas realizadas por sistemas microkernel: Mecanismo de comunicação interprocessos. A vantagem de um kernel monolítico é o desempenho. em nível de usuário do sistema. gerenciamento completo dos processos ou um manuseio considerável de chamadas de sistema. conexão com a rede. Algum gerenciamento de memória. seria a abordagem mais adequada para o desenvolvimento de sistemas distribuídos. o microkernel não provê um sistema de arquivo ou diretórios. esse tipo de sistema torna a inclusão e manutenção dos serviços muito mais simples. O microkernel. 30 . Dessa maneira. na visão de Tanenbaum (TANENBAUM.Flexibilidade Podemos dizer que temos duas vertentes para o desenvolvimento de estruturas de sistemas operacionais distribuídos. Entrada/Saída em baixo nível. Além disso. etc. os sistemas com microkernel são essencialmente mais flexíveis. pois todas as instruções serão realizadas na velocidade do barramento interno do computador. Temos os sistemas operacionais com o kernel monolítico e temos os sistemas operacionais com microkernel. pois não requer que o sistema seja parado para que se habilite um novo kernel com um novo serviço. não necessitando de utilizar uma estrutura de rede para essa atividade. e o segundo realizando o mínimo de operações possíveis deixando que as outras tarefas necessárias para a obtenção dos resultados desejados. 1995). sejam realizadas fora do kernel. proporcionando um desenvolvimento modular de funções e serviços. podendo os mesmos estar fisicamente em recursos computacionais diferentes.

trabalhar com um experimento computacional que envolve um número grande de atividades de alto consumo de CPU terá um resultado muito diverso que trabalhar analisando um arquivo de grandes proporções buscando algum padrão. muito melhor do que qualquer servidor individual. utilização do sistema (recursos computacionais) e consumo da capacidade da rede. Por exemplo. Infelizmente. A consolidação dessas métricas nem sempre é uma atividade fácil de ser realizada assim como as conclusões derivadas dessa consolidação. Desempenho No tema de sistemas distribuídos sempre teremos como pano de fundo o desempenho. na prática a obtenção desse objetivo não é tão fácil de ser alcançada. consistência e tolerância a falhas são desafios para os desenvolvedores de sistemas distribuídos. Sempre buscaremos a condição de uma aplicação ser executada mais rapidamente num sistema distribuído do que num único servidor com capacidade computacional de um dos componentes desse cluster. segurança. 31 . A ideia seria que se um computador ficasse fora de funcionamento. se tivermos três servidores de arquivos com 0. outro assumiria seu trabalho. arquivos. usuários exatamente iguais em todos os computadores que o compõe. aspectos como disponibilidade.053) = 0. porque manter num sistema distribuído todos os processos. por exemplo.0. a confiabilidade de um sistema distribuído seria uma operação lógica “OU” das confiabilidades das máquinas que o compõe. O tipo de operação escolhida também influencia em muitos nos resultados de um benchmarking.999875. a probabilidade dos três computadores estarem indisponíveis ao mesmo tempo seria de (1 . Na teoria. A primeira questão é que na medição do desempenho (benchmarking). vazão (número de Jobs por hora).95 de chance de estarem indisponíveis. é uma tarefa árdua em termos técnicos e financeiros.Confiabilidade Um dos primeiros objetivos de se construir sistemas distribuídos foi de fazê-los mais confiáveis que os sistemas monoprocessados. Em geral os sistemas distribuídos trabalham de modo a esconder do usuário do sistema que algum dos seus componentes não está disponível em dado momento. Na prática a função lógica “E” estaria mais próxima da realidade do que a operação “OU”. pode-se utilizar várias métricas como tempo de resposta.

que comparado à taxa de transferência interna de um processador ou mesmo de um barramento de um computador. Quando falamos em desempenho em processamento distribuído temos que pensar na granularidade computacional. devido ao overhead da comunicação de dados. porém podendo ou não estar disponíveis. como por exemplo. um cluster com 199 servidores e na Caltech um sistema com 140 nós de cluster. não será usualmente interessante em termos de desempenho num ambiente distribuído.A infraestrutura de rede sempre será um elemento crítico num sistema distribuído. realizar uma operação lógica simples entre dois números. mesmo em conexões de LAN de 10 Gibabits. Assim quando processos realizam poucas instruções e precisam comunicar-se muito. quando realizam muitas instruções com pouca troca de informação. usualmente é um trabalho adequado para um processamento distribuído. O grande desafio da escalabilidade não seria a quantidade de nós que poderiam ser agregados a um cluster e sim o desenvolvimento de sistemas operacionais e aplicações que usufruam devidamente desse tipo de configuração. dizemos que são poucos granulares. para serem executados num sistema em cluster. se realizarmos uma tarefa que exija um longo processamento computacional para uma mesma massa de dados. 32 . pode ser considerado um tempo extremamente longo. Naturalmente num ambiente de processamento distribuído uma menor granularidade computacional. Escalabilidade Falando em cluster em Linux temos na plataforma Beowulf no projeto Goddard Casse Flight Center. Utilizar um recurso computacional remoto de modo reduzido. por outro lado. dizemos que são muitos granulares. em muitas situações. Uma comunicação entre duas máquinas na melhor das condições leva pelo menos um milissegundo. significa usualmente um melhor desempenho. Dessa maneira modelos convencionais de processamento centralizado não são adequados. Um dos clusters da “Yahoo” (Apache Hadoop Cluster) tem 910 nós. porém esse é um sistema de cluster apenas para executar as funcionalidades de um servidor web num modelo de grid. para a realização de uma determinada tarefa computacional. que é um agrupamento de computadores visando um aumento de capacidade de processamento que estão geograficamente separados.

buscaremos aplicações de inteligência e Design Digital que satisfaçam esses requisitos. No nosso trabalho. Serão abordados também os desafios que tecnologia enfrenta. As máquinas tomam as “decisões” baseadas na informação local. isto é. 33 . em especial. inerentes aos próprios princípios que regem a computação convencional contemporânea que em regra geral tornam-se mais críticos e de mais difícil solução ou mitigação quando tratados no domínio da computação distribuída. os sistemas de cluster são técnica e financeiramente viáveis para uma grande quantidade de aplicações. Fundamentos dos Sistemas Operacionais Convencionais Para que possamos melhor compreender os princípios utilizados no processamento distribuído precisamos conhecer alguns componentes do processamento tradicional. Sobre o último tópico. Apesar dessas restrições. O objetivo dessa apresentação é apenas discorrer sobre os componentes e entidades do processamento convencional que necessitam ser adequadas ou pelo menos consideradas quando atuando com sistemas de processamento distribuído ou clusters. Não existe uma premissa implícita que exista um sistema global de sincronismo (clock).Seguem algumas características de sistemas adequados para trabalhar num cluster: Nenhuma máquina tem uma completa informação sobre o estado de todo o sistema. estamos considerando o uso de cluster para fins gerais e não para sistemas multimídia distribuídos que necessitam de um sincronismo adequado para operarem satisfatoriamente. de certa forma. A escalabilidade só faz sentido quando as aplicações são compatíveis com um modelo de cluster de computadores. computadores monoprocessados. A falha numa máquina não afeta o funcionamento do sistema.

para realizar funções de baixo nível e de interação com o próprio sistema operacional.Processos: Todo software executável num computador. temos a impressão de que os processos são executados paralelamente. baseando-se no princípio de Traffic Shaping utilizado em roteadores. Podemos citar o trabalho de Silviu S. mas na realidade eles compartilham uso da CPU em intervalos muito rápidos que nos dão essa impressão de um “pseudo-paralelismo”. Essa falta uniformidade se acentua quando tratamos de sistemas distribuídos. Usualmente um processo é inicializado através de uma chamada de sistema (system call) que é constituída de diretivas que são linhas de programação em C. Também um processo sempre tem alguns registradores associados ao mesmo. que podem ser contadores. que trabalha com scheduler de chamadas de sistema para alcançar essa uniformidade e melhor desempenho. etc. pois não saberemos quanto tempo ele terá para fazer uso da CPU em cada execução. É importante ressaltar que em sistemas monoprocessados não podemos precisar exatamente quanto tempo um processo durará. dados de um programa ou a própria pilha do processo. se estamos falando em sistemas Unix e Linux. 34 . Craciunas. Mesmo num sistema monoprocessado. Austria dentre outros trabalhos. para que se tenha um maior controle do tempo de execução de cada processo. Existem trabalhos recentes onde se trabalha com mecanismos de scheduler mesmo em ambientes monoprocessados. é organizado num número de processos sequenciais. Um processo sempre tem um espaço de memória (address space) onde ele armazena as informações que está manipulando que podem ser um programa executável. registradores de hardware. 4 Autores do artigo “I/O Resource Management through System Call Scheduling” pela Universidade de Salzburg. ponteiros de pilhas. com determinados valores nos contadores. questão iremos tratar no transcorrer desse trabalho. caso seja executado mais de uma vez. Christoph M. algumas vezes incluindo o próprio sistema operacional. registros e variáveis. Kirsch e Harald Röck4. Um processo é um programa executável. desenvolvidos para interagir com o sistema operacional e com a linguagem de máquina (Assembler).

na computação convencional. um servidor de arquivos numa rede local. cada thread é executada por vez. elas são ideais para aplicações que necessitam dessa característica. dizemos que o primeiro é um processo pai do segundo. Threads Embora tenham algumas semelhanças. Assim se tivermos três threads sendo executadas sequencialmente por um processador. Processos e threads são entidades distintas com aplicações distintas. Em algumas situações é interessante separar o agrupamento dos recursos do processamento dos mesmos. As threads acrescem aos processos a capacidade de realizar múltiplas execuções num mesmo ambiente de processo. discos. Outra vantagem das threads é que como elas não possuem nenhum recurso associado às mesmas. Tendo múltiplas threads sendo executadas num mesmo processo seria semelhante a ter múltiplos processos sendo executados num mesmo computador. cada uma terá apenas um terço da capacidade do mesmo. Os últimos compartilham memória física. por exemplo. Elas apenas executam operações. Finalmente elas têm uma maior performance e também são mais apropriadas para ambientes multi-processados onde teremos um paralelismo real. Nesse cenário que temos as threads. que num ambiente monoprocessado que é consideravelmente mais simples do que em sistemas distribuídos.Quando um processo faz uma chamada para a execução de outro processo. um registrador que armazena as variáveis de trabalho e uma pilha que contém um histórico da execução. impressoras. daí a necessidade de comunicação interprocessos. possuindo um contador para ter um controle da execução. Como as threads compartilham o mesmo espaço de memória e os próprios dados. porém como os processos. 35 . isto é. Um motivo para utilizarmos threads seria aplicações que necessitem de processos paralelos. etc. temos também a impressão de um paralelismo. As primeiras compartilham espaço de endereçamento. múltiplas threads associadas a um único processo. Os processos têm como função principal agrupar recursos e executar operações com eles. Quando temos um cenário de multi-thread. arquivos abertos. elas são criadas e finalizadas mais facilmente. etc. como. com um alto grau de independência.

através da utilização do conceito de endereçamento de memória. Os sistemas de arquivos são hierárquicos e também possuem o conceito de diretórios que é um agrupamento de arquivos. Esse endereço pode ser de 32 ou 64 bits que significa respectivamente 232 e 264 bytes de tamanho de memória por endereço. liberando a memória real para outras funções dos processos. Arquivos: Todo o sistema operacional possui um sistema de arquivos. Outro mecanismo para aumentar a quantidade de memória disponível para os processos é a memória virtual ou “paginação” que é a gravação temporária dos dados da memória no disco rígido do computador. Nos sistemas mais sofisticados a memória pode ser compartilhada por mais de um programa. Assim é com o sistema de arquivos. como teclado. etc. 36 . O sistema precisa gerenciar esses dispositivos na medida em que os processos e os programas solicitem uso de algum deles. impressoras. Dispositivos de Entrada/Saída: Todo o computador tem dispositivos de E/S (Entrada/Saída). Usualmente um processo tem um conjunto de endereços de memória com os quais ele pode trabalhar. monitores. Num sistema de cluster.Gerenciamento de Memória: Todo sistema operacional precisa de uma memória principal onde os programas que estão sendo executados possam ser alojados. também esses recursos também precisarão receber as requisições para o seu uso como que partissem de um único computador. Em sistemas operacionais mais simples somente um programa por vez pode fazer usado no espaço de memória. Uma das principais funções de um sistema operacional é realizar uma abstração dos aspectos complexos do funcionamento real de um computador apresentando ao usuário ou mesmo programador uma interface amigável.

Todo arquivo num sistema de arquivos possui um caminho (path) que é uma lista de todos os diretórios que necessita ser informada para acessar determinado arquivo. Todo processo tem um diretório de trabalho que pode ser alterado através de uma chamada de sistema. Novamente, o gerenciamento de um sistema arquivos num ambiente

monoprocessado, apesar de ter certa complexidade não se compara às dificuldades em manter-se um sistema de arquivo num sistema de cluster, garantindo uma uniformidade e coerência nos arquivos que estão espalhados entre os nós que compõe o mesmo.

Chamadas de Sistema (System Call): A interface entre o sistema operacional e os programas dos usuários é definida por um grupo de chamadas de sistemas previamente definidas. Apesar da maioria das chamadas de sistema ser altamente dependente das características do computador e usualmente escrita em linguagem de máquina (assembler), o desenvolvimento das mesmas foi simplificado através da criação de bibliotecas de procedimentos (procedures libraries) que facilitam esse trabalho por se poder utilizar linguagens de programação mais acessíveis como a C. De forma simplificada podemos descrever os passos da execução de uma chamada de sistema como segue: A chamada de sistema pertencente à biblioteca de procedimentos é chamada. O programa que iniciou a chamada de sistema coloca os parâmetros fornecidos na respectiva pilha. A chamada de sistema é executada com os parâmetros fornecidos. A biblioteca de procedimentos a qual pertence à chamada de sistema, que é usualmente escrita em linguagem de máquina, coloca o número da chamada de sistema num registrador conforme estabelecido pelo sistema operacional.

37

Ocorre então uma instrução conhecida como TRAP, que é a mudança do modo usuário para o modo kernel (núcleo do Sistema Operacional) que inicia a execução da chamada de sistema. O kernel verifica o número da chamada de sistema e o envia para o devido manipulador de chamadas de sistema (system call handler). O manipulador de chamadas de sistema é executado. Após isso o sistema retorna para o modo usuário via instrução TRAP. O programa que executou a chamada de sistema limpa a pilha utilizada para colher os parâmetros da mesma, procedimento usual nesse tipo de manipulação. A quantidade de chamadas de sistema varia entre os sistemas operacionais. O Linux kernel 2.6, por exemplo, tem 271 chamadas de sistema. Dentre os vários serviços realizados pelas chamadas de sistema temos como os mais relevantes o gerenciamento de processos, de arquivos e de sistema de arquivos e diretórios. Muitas das chamadas de sistemas em monoprocessamento podem ser usadas em processamento distribuído através de Remote Procedure Call (RPC). Os parâmetros das chamadas de sistema ao invés de serem colocados num registrador, são colocados numa mensagem e o kernel envia a mensagem para a máquina que deseja que execute a chamada de sistema que retorna o resultado através de outra mensagem para o computador que requisitou a execução remota, que do ponto de vista de RPC seria o client stub no processo e o executante o server stub. Existem outras abordagens para execução de chamadas de sistemas remotamente, como o Kerrighed que realiza a execução remota de chamadas de sistema através da migração de processos entre os nós que compõe um cluster.

38

Seguem agora alguns desafios que os desenvolvedores de sistemas operacionais enfrentam na implementação de processos e threads, considerando modelo computacional de Von Neumann5. IPC (Interprocess Communication) Um componente muito crítico seja na computação tradicional seja na computação distribuída, é a comunicação entre processos. Um exemplo típico de comunicação entre processos é o comando pipeline no ambiente Unix, onde a saída de um processo alimenta a entrada do outro. Existem muitas linhas de programação seja em linguagem de máquina seja em linguagem de alto nível para realizar esse comando que a primeira vista parece simples. Segue um exemplo de um código que escuta a função pipe. A função fork é usada para criar um processo pai e um processo filho. #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <unistd.h> #include <sys/wait.h> int main() { char token[100]; FILE *fout; int p[2]; int pid;

5

John Von Neumann, nascido em Budapeste, 28 de dezembro de 1903 foi um matemático húngaro de etnia judaica, naturalizado americano. Contribuiu na teoria dos conjuntos, análise funcional, teoria ergódica, mecânica quântica, ciência da computação, economia, teoria dos jogos, análise numérica, hidrodinâmica das explosões, estatística e muitas outras as áreas da Matemática. De fato é considerado um dos mais importantes matemáticos do século XX. Foi professor na Universidade de Princeton e um dos construtores do ENIAC.

39

pipe( p ); /* “pipe” entre o pai e o filho */ if((pid = fork()) == 0) {/* executa o processo filho P1 */ close(p[1]); /* Fecha o fd (file descriptor) no final de escrita do pipe */ if(dup2(p[0], 0 ) == -1 ) /* Utiliza o stdin para ler o final do pipe */ { perror( "dup2 failed" ); _exit(1); } close(p[0]); /* fecha o fd de final de leitura do pipe */ execl("Pipe_newB","Pipe_newB","CHILD", 0); /* executa 'Pipe_newB' */ perror("execl Pipe_newB failed"); _exit(1); } else if(pid < 0) {/* fork() failed */ perror("fork CHILD failed"); exit(1); } /* parent executes */

close(p[0]); /* fecha o fd de final de leitura do pipe */

40

/* usa o fdopen() para associar o fluxo de escrita ao final de escrita do pipe entre o pai e filho */ if( ( fout = fdopen( p[1]. token ) == EOF ) { perror( "fprintf failed" ). } 41 . "%s-Parent\n". "w" ) ) == 0 ) { perror( "fdopen failed" ). exit(1). while( scanf( "%s". /* fecha a referência do pipe para enviar o ‘EOF” (End of File) */ wait(NULL). } fflush( fout ). return(0). } printf( "Please input a string:\n" ). token ) != EOF ) { if( fprintf( fout. } close(1). exit(1).

Após as bibliotecas haverem sido carregadas em memória. O propósito desse trabalho não será entrar nos detalhes de programação. ao realizar a comunicação. Retornando a função pipe. que são tratados pelo pré-processador antes da execução do programa propriamente dito. mas apenas para fins de exposição do princípio. assim dizemos que esse processo torna-se atômico porque até o mesmo ser finalizado. É importante ressaltar o papel da função “dup2”. vamos analisar de maneira não aprofundada o código acima. um processo não poder interferir na execução do outro. a saída da entrada padrão (teclado) executado pelo programa pai é escrita na entrada padrão do processo filho (fd – file descriptor) no arquivo “Pipe_newB”. nos ateremos apenas nas variáveis “p” que seria de processo e “pid” que seriam o identificador de processo. assim como na prevenção de problemas inerentes a esse tipo de operação. Essas diretivas também são chamadas de bibliotecas da linguagem C. o sistema como um todo não visualiza a alteração que está sendo realizada. o código “stdio. que para efeito de explanação do código.h” que é responsável por gerenciar os dispositivos padrões de entrada/saída. por exemplo. 42 . por exemplo. Caso o processo falhe na sua execução o sistema retorna a sua condição original. Temos a diretiva “include” que é usada para executar códigos de programa previamente desenvolvidos.Vemos que o desenvolvimento de um código para prover uma comunicação entre processo não é trivial e envolve uma lógica considerável na comunicação em si. Dessas bibliotecas retiramos os comandos executados nos códigos C. como. Basicamente realizar a função pipe seria usar a saída de padrão de um processo como entrada para outro. que além de fazer uma duplicação do processo filho original garante que o programa terá o uso da CPU sem interrupção. em resumo. A chamada de sistema pipe cria um tubo (pipe) entre um processo pai e um processo filho. algumas variáveis são definidas. pela solicitação do kernel por algum outro processo. O processo filho tem o processo número 1 que é associado a um arquivo “Pipe_newB”. Nesse caso temos. necessitando assim que os processos sejam executados e troquem mensagens corretamente de modo a evitar conflitos na utilização dos recursos computacionais.

Iremos abordar os principais problemas que são inerentes ao modelo computacional corrente e vivenciados na maioria das aplicações. Vale a observação que estamos nos abstraindo nessa abordagem dos processadores que possuem dois núcleos (Dual-Core) ou mesmo os computadores multi-processados (com mais de um processador em seu barramento). existem desafios no desenvolvimento ou aperfeiçoamento de sistemas operacionais. podendo um sobrescrever a ação do outro. dando a impressão ao usuário que esses processos estão sendo executados paralelamente.O ponto mais importante na elucidação desse exemplo de comunicação interprocessos é conhecermos uma forma básica de processos comunicarem-se. 43 . Race Condition Race Condition é quando dois ou mais processos estão lendo ou escrevendo em algum dado compartilhado e que o resultado vai depender do momento em que cada processo é executado. assim como mostrar através de uma função. no gerenciamento dos recursos da CPU. causando resultados inesperados e incorretos. trocando parâmetros e dados. pois essas tecnologias não são foco principal dessa análise. dispositivos de E/S em face aos vários processos que solicitam o uso dos mesmos. A maneira óbvia de se evitar essa distorção seria aplicar uma política de mútua exclusão no acesso aos recursos. Dificuldades na manipulação de processos num ambiente monoprocessado Mesmo no processamento convencional. memória. podendo gerar uma condição conhecida como race condition que veremos com mais detalhes à frente. o tratamento da questão de um processo interferir na execução de outro. É importante ressaltar que todas essas questões levantadas sobre a comunicação entre processos podem ser aplicadas também às threads. O objetivo é conhecer essas dificuldades na computação monoprocessada que usualmente são acentuadas num ambiente de processamento distribuído.

6 Eduard Grady Coffman é professor de Ciência da Computação na Universidade de Columbia. se num banco de dados onde o processo “um” acessa o registro “um” e o processo “dois” acessa o registro “dois” e no próximo instante o processo “um” tenta acessar o registro “dois” e o processo “dois” tenta acessar o registro “um”. O deadlock é também um problema inerente ao modelo de computação convencional relacionado à alocação de recursos por um sistema operacional. Coffman6 (COFFMAN. Nenhum processo sendo executado fora da sua região crítica pode bloquear outros. 1971) estabelece quatro condições para que ocorra um deadlock: Condição de exclusão mútua. Cada recurso.A implementação de regiões ou seções críticas para cada processo e a premissa que dois ou mais processos não podem acessar essas regiões críticas ao mesmo tempo. Um deadlock ocorre quando num mesmo instante dois processos tentam acessar um recurso tanto de hardware como de software que está sendo alocado pelo outro. Deadlocks Deadlock é um problema clássico na teoria e na prática da computação. mas não o evitaria para todas as situações. sugere-se quatro condições: Dois processos não podem estar ao mesmo tempo em suas regiões críticas. ajudaria na minimização do problema de race condition. Esse evento é conhecido como deadlock. ou está correntemente designado exatamente para um dado processo. ou está disponível. nesse momento os processos são bloqueados e ficarão nesse estado indefinidamente. A não existência de premissas sobre velocidade ou número de CPU’s. Para podermos ter “processos paralelos” compartilhando os mesmos recursos de uma forma mais produtiva sem a race condition. 44 . Por exemplo. Nenhum processo pode esperar indefinidamente para entrar em sua região crítica. Em 1994 ele foi nomeado membro da Association for Computing Machinery (ACM).

que evitariam. mas basta dizer que elas passam por uma política de alocação de recurso criteriosa assim como uma composição de técnicas de detecção. 7 John Hayes Howard Jr. é autor do artigo “Mixed solutions for the deadlock problem” pela Universidade do Texas. Deve haver uma corrente circular de dois ou mais processos. Eles precisam ser explicitamente liberados pelo o processo que os mantém. anulação e prevenção e aplicação de soluções práticas com esse tipo abordagem. cada um esperando por um recurso mantido pelo próximo membro da corrente. A falta de percepção de prioridade. de modo eficiente. Austin. Existem várias técnicas e abordagens para a mitigação de deadlocks que não são foco do nosso trabalho. (HOWARD JR.7. Conseguiremos evitar o deadlock quando conseguirmos fazer com que uma dessas quatro condições não seja satisfeita. 1972). Recursos previamente concedidos não podem ser forçosamente tirados de um processo. os deadlocks. Processos que estão correntemente mantendo recursos anteriormente concedidos podem requisitar novos recursos.Condição de manutenção e espera. 45 . Condição de espera circular.

assim nenhum outro filósofo (processo) tentaria pegar qualquer garfo até que o primeiro colocasse os garfos de volta à mesa e entrasse num estado de up liberando assim os recursos (garfos) para os outros processos (filósofos). em suma. entrando os processos numa condição conhecida como starvation quando os programas são executados continuamente. A ilustração é bem simples. Essa situação continuará indefinidamente. detendo a Schlumberger Centennial Chair em Ciências da Computação na Universidade do Texas de 1984 a 2000. 1971) elaborou um problema e concebeu uma solução para situações passíveis de se ocorrer no acesso aos recursos pelos processos. conseguir realizar qualquer progresso efetivo no andamento dos mesmos. caso negativo. o programa simplesmente não é executado. a solução do problema seria simples. ele devolve o garfo do lado esquerdo à mesa. Podemos aprimorar essa solução não exitosa colocando a premissa de que ao pegar o garfo ao lado esquerdo do prato. Imaginem se os cinco filósofos ao mesmo tempo verificassem que os garfos estão disponíveis e consequentemente tentam utilizá-los. Eles irão constatar que o garfo a sua direita não está disponível e devolverão à mesa o garfo a sua esquerda. Eles não terão os dois garfos disponíveis para si e os processos entrarão em deadlock. 8 Edsger Wybe Dijkstra é um cientista neerlandês em computação. 46 . assim o filósofo poderia utilizá-los. sendo necessários dois garfos para poderem comê-lo. Infelizmente a solução não é tão simples assim. porém. Ele recebeu em 1972 o Turing Award por contribuições fundamentais para o desenvolvimento de linguagens de programação. À primeira vista. Uma ideia seria os filósofos (processos) esperando um tempo aleatório para pegar o garfo a sua esquerda. como é feito em redes locais. Antes de pegar qualquer garfo. porém o espaguete é muito escorregadio.Problema do Jantar dos Filósofos Dijkstra8 (DIJKSTRA. Essa parece ser uma boa abordagem para o problema. o filósofo entraria numa condição de down num semáforo “mutex” (exclusão mútua). Temos cinco filósofos numa mesa de jantar com cinco pratos de espaguete e cinco garfos. sem. teríamos que ter apenas um algoritmo que testasse quando os dois garfos estivessem disponíveis. o filósofo verifica se o garfo ao lado direito está disponível. mas imagine se os cinco filósofos resolvam ao mesmo tempo pegar o garfo a sua esquerda e testar se o garfo a sua direita está disponível.

Uma solução mais eficaz para o problema do Jantar dos Filósofos seria utilizarmos um array que controla os estados dos filósofos que seriam: comendo. Segue um código que aplica a solução para o problema do Jantar dos Filósofos: #define N #define LEFT #define RIGHT #define THINKING #define HUNGRY #define EATING 5 /* número de filósofos */ (i+N−1)%N /* número de i's à esquerda do vizinho */ (i+1)%N /* número de i's à direita do vizinho */ 0 /* filósofo está pensando */ 1 /* filósofo está tentando pegar os garfos */ 2 /* filósofo está comendo */ /* os semáforos são tipos de especiais de int */ typedef int semaphore. de 0 a N−1 */ { while (TRUE) { think(). semaphore s[N]. se o processo do filósofo é o dois. dois filósofos poderiam comer ao mesmo tempo e nesse caso apenas um comeria por vez. pois considerando os recursos (pratos e garfos). Essa solução contempla um array de semáforos para cada filósofo. void philosopher (int i) /* i número de filósofo. /* repete indefinidamente*/ /* filósofo está pensando */ 47 . porém não é eficaz. /* array para verificar o estado de todos os filósofos */ /* mutual exclusão para região críticas */ /* um semáforo por filósofo */ semaphore mutex = 1. int state[N]. seu vizinho da direita seria 1 e o da esquerda 3. São definidas macros para identificar os vizinhos de cada filósofo. Um filósofo só poderia pegar os garfos se nenhum de seus vizinhos estiver comendo. Por exemplo.Essa solução previne efetivamente os deadlocks e starvation. pensando ou com fome (tentando pegar os dois garfos).

/* filósofo termina de comer */ test(LEFT). put_forks(i). up(&mutex). } void test(i) { /* i número de filósofo. de 0 a N−1 */ /* entra em região crítica */ /* registra que o filósofo i está com fome */ state[i] = HUNGRY. /* pega dois garfos ou bloqueia */ /* comendo espaguete */ /* coloca os garfos de volta à mesa */ /* i número de filósofo. eat(). test(i). de 0 a N−1 */ /* verifica se o vizinho da esquerda pode comer agora */ /* verifica se o vizinho da direita pode comer agora */ /* sai da região crítica */ 48 . } } void take_forks(int i) { down(&mutex). down(&s[i]). de 0 a N−1 */ /* entra em região crítica */ state[i] = THINKING. up(&mutex). /* tenta pegar os dois garfos */ /* sai da região crítica */ /* bloqueia se os garfos não foram pegos */ /* i número de filósofo.take_forks(i). test(RIGHT). } void put_forks(i) { down(&mutex).

Na função “take_forks”. podemos ter vários acessos de leitura. Temos dois semáforos. Temos um “while” principal com funções para as quatro atividades dos filósofos que são: pensando. assim a função “test” verifica se os vizinhos não estão comendo. Existem abordagens mais recentes para esse problema como Software Visualization que é uma programação visual. mas em intervalos muito pequenos. pegando os garfos. Quando o primeiro leitor acessar o banco. mas apenas um de escrita por questões óbvias. essa condição seria muito propícia a deadlocks. 49 . comendo e colocando os garfos de volta na mesa. vemos um teste para verificar se os garfos estão disponíveis e a decisão de pegar os talheres ou não associadas à colocação do semáforo no estado de down ou up. } } Os comentários sobre código acima são autoexplicativos. baseada em semiótica e os recursos de linguagens de programação como a Parlog86. Quando temos um banco de dados. pois se tivermos vários acessos de escrita mesmo em registros diferentes ou ainda no mesmo registro. up(&s[i]). teremos um banco de dados inconsistente. Problemas de leitores e escritores Esse problema está muito ligado ao acesso a banco de dados. coloca em down o semáforo “db” e incrementa o contador de leitores no semáfora “mutex”. porém algumas linhas do código valem ser ressaltadas.if (state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] != EATING) { state[i] = EATING. um que poderia ser chamado “db” e outro “mutex”. além disso. o primeiro para controlar o acesso de escrita ao banco e o segundo para controlar os acessos de leitura. Na função “put_forks” vemos a execução da função “test” para verificar se o filósofo vizinho da direita ou dá esquerda podem pegar os garfos. para que o filósofo possa entrar do estado de EATING. A solução clássica para esse problema é relativamente simples.

Na medida em que outros leitores foram acessando o banco de dados, o contador é incrementado, quando eles deixam de acessar o banco, o contador é decrementado. Quando o último leitor deixa o acesso, ele muda a condição do semáforo “db” para up e assim um escritor do banco de dados, caso exista algum nesse momento, está livre para fazer um acesso de escrita. Essa abordagem é eficiente caso não tenhamos uma quantidade muito elevada de acessos de leitura ao banco, pois do contrário, nunca ocorrerá um acesso de escrita devido à condição de mútua exclusão entre os dois processos. Uma solução para essa fragilidade do algoritmo seria quando um leitor for acessar o banco e já houver um processo de escrita esperando a liberação do mesmo, esse processo é colocado em espera, sendo executado só após a liberação e execução do processo de escrita, dessa forma o escritor só esperaria pelos processos de leitura que já estivessem em execução na sua chegada. Um ponto fraco dessa abordagem é que, apesar dela diminuir a concorrência entre processos, tem o desempenho comprometido. Segue o código que apresenta a solução descrita acima para o problema de acessos de leitura e escrita: typedef int semaphore; semaphore mutex = 1; semaphore db = 1; int rc = 0; void reader(void) { while (TRUE) { down(&mutex); rc = rc + 1; /* repete indefinidamente */ /* obtém acesso exclusivo ao 'rc' */ /* mais um leitor agora */ /* se esse é o primeiro leitor… */ /* os semáforos são tipos de especiais de int */ /* controla o acesso ao 'rc' */ /* controla o acesso ao banco de dados */ /* número de processos de leitura ou desejando ler */

if (re == 1) down(&db); up{&mutex);

/* libera o acesso exclusivo ao 'rc' */

50

read_data_base(); down(&mutex); rc = rc − 1;

/* acessa os dados */ /* obtém acesso exclusivo ao 'rc' */

/* um leitor a menos agora */

if (rc == 0) up(&db); /* se esse é o ultimo leitor… */ up(&mutex); use_data_read(); } } void writer(void) { while (TRUE) { think_up_data(); down(&db); write_data_base(); up(&db); } } /* repete indefinidamente */ /* região não crítica */ /* obtém acesso exclusivo */ /* atualiza os dados */ /* libera acesso exclusivo ao 'rc' */ /* região não-crítica */

/* libera acesso exclusivo */

Vale ressaltar que nesse código a verificação feita pela função “if” da ocorrência de finalização do último processo de leitura, que libera o acesso exclusivo ao banco, colocando o semáforo “mutex” em up, para que caso houver um escritor em condição de espera, o mesmo coloque o semáforo em down (acesso exclusivo) e inicie a gravação no banco de dados. Existem variações nesse código justamente para privilegiar seja o controle de acesso aos recursos seja o desempenho do processo, como já discutido.

51

O código acima não privilegia os acessos de escrita, pois eles necessitam esperar até o último acesso de leitura deixar o processo para poder assim acessar o banco de dados.

O Problema do Barbeiro Dormindo Esse problema é ilustrado pela seguinte situação. Temos uma barbearia com apenas um barbeiro, uma cadeira de barbeiro e “n” cadeiras de espera. Se não há clientes, o barbeiro senta na cadeira de barbeiro e dorme. Se um cliente chega, ele acorda o barbeiro que começa cortar o seu cabelo. Se outros clientes chegam enquanto o barbeiro está realizando um corte, eles sentam nas cadeiras de espera ou saem se não houver cadeiras de espera disponíveis. O problema é criar uma lógica de modo a programar o barbeiro e os clientes sem entrar numa condição de corrida (race condition). Esse problema é similar a muitas situações de controle de filas, como por exemplo, um software de controle de ligações num Call Center. Uma solução para esse problema utilizaria três semáforos: “clientes” que conta os clientes aguardando (excluindo o cliente na cadeira de barbeiro), “barbeiros”, número de barbeiros (0 ou 1) que pode ficar numa condição de ocioso (dormindo) ou trabalhando(cortando cabelo) e “mutex” que é usado como exclusão mútua. É necessário ainda a variável “waiting” que conta também a quantidade de clientes esperando, que é essencialmente uma cópia dos clientes. A razão para essa variável é a impossibilidade de ler um valor corrente de um semáforo. Nessa solução, um cliente que entra na barbearia tem de contar o número de clientes esperando. Se for menor que o número de cadeiras, ele permanece, caso negativo, ele deixa a barbearia.

52

Segue um código que contempla a solução para o problema do Barbeiro Dormindo: #define CHAIRS 5 typedef int semaphore; semaphore customers = 0; semaphore barbers = 0; semaphore mutex = 1; int waiting = 0; void barber(void) { while (TRUE) { down(&customers); 0 */ down(&mutex); /* obtém o acesso à variável ‘waiting’ */ /* entra no estado de ‘dormindo’ se o número de clientes é /* número de cadeiras para clientes esperando */ /* os semáforos são tipos de especiais de int */ /* número de clientes esperando pelo serviços */ /* número de barbeiros esperando por clientes */ /* para exclusão mútua */ /* clientes estão esperando (não tendo os cabelos cortados) */

waiting = waiting − 1; /* decrementa a contagem de clientes esperando */ up(&barbers); up(&mutex); cut_hair(); } } void customer(void) { down(&mutex); if (waiting < CHAIRS) { /* entra na região crítica */ /* se não há cadeiras livres, saia */ /* um barbeiro está pronto para cortar um cabelo */ /* libera a variável 'waiting' */ /* corta cabelo (fora da região crítica) */

53

waiting = waiting + 1. mestrado e doutorado no MIT. Patil nascido em 1944 em Jamshedpur. investidor e filantropo. 1971) onde temos três fumantes e um agente. nega-se o acesso do cliente (processo) através do semáforo “mutex”. O mesmo processo ocorreria com os outros fumantes. Apenas a título de informação temos o problema dos “fumantes” (PATIL9. caso número de cadeira for menor ou igual ao número de clientes esperando. down(&barbers). o código “costumer” que testa o número total de cadeiras para verificar se é maior que o número de clientes esperando através do operador “if”. onde cada fumante tem indefinidamente apenas dois dos três elementos que os habilitaria a fumar. é um empreendedor no Silicon Valley. se o agente disponibilizar o fósforo. India. Suhas S. get_haircut(). up(&mutex). Por exemplo. pessoas e ações. } } Nesse código podemos ressaltar os seguintes pontos: o código “barber” que é um loop que na medida em que se vai cortando o cabelo dos clientes vai decrementando o número dos mesmos e também liberando a função “waiting”. Jharkhand. /* a barbearia está cheia. } else { up(&mutex). Na teoria de sistemas operacionais existem várias outras situações usualmente ilustradas através de exemplos envolvendo objetos. /* incrementa a contagem de clientes esperando */ up(&customers). Ele fundou a companhia Cirrus Logic. O agente em cada ciclo disponibiliza um elemento que compõe um cigarro pronto para ser fumado. o fumante que tiver o papel e o tabaco. não espere */ /* acorda o barbeiro se necessário */ /* libera o acesso à variável 'waiting' */ /* dorme se o número de barbeiros livres é 0 */ /* está sentado e atendido */ 9 Dr. Recebeu seu bacharelado em engenharia no Indian Institute of Technology. a saber. 54 . o tabaco e o fósforo. que passam a ser elementos de uma representação de um problema de comunicação interprocessos. o papel. toma o fósforo e compõe o cigarro pronto para ser fumado.

ele vai até o caldeirão e se o mesmo estiver provido de missionários ele come. onde os canibais têm no caldeirão certa quantidade M de missionários cozidos. quando o canibal está com fome. Podemos também citar o problema do Jantar dos Canibais. 55 . utilizando semáforos. isto é. o primeiro possuindo longas rajadas de utilização de CPU com esporádicos usos de E/S e o segundo com curtas rajadas de uso de CPU e freqüentes usos de E/S. o agente seria o sistema operacional e os fumantes processos ou threads. pois enquanto os processos estão utilizando algum dispositivo de E/S. quando e por quanto tempo um processo fará uso dos recursos da CPU. Escalonamento de processos ou threads Um dos desafios em se desenvolver um sistema operacional é estabelecer o escalonamento dos processos. um para cada item do cigarro e um “mutex”. senão ele acorda o canibal cozinheiro para preparar mais missionários cozidos. Os problemas apresentados até o momento em ambientes monoprocessados e suas respectivas soluções adquirem novas facetas quando os tratamos em ambientes de processamento distribuído. uma que utilizaria um semáforo para controlar o caldeirão cheio. processos computer-bound e processos I/O – bound. a CPU pode tratar e executar outros processos. mas é importante termos esses conceitos claros para podermos explorar com mais clareza os mecanismos de sincronização e prevenção da ocorrência de deadlocks. Eles são sincronizados adequadamente através de uma função “while”. com soluções distintas. Nesse caso temos como solução possível. Esse problema é resolvido.Nessa alegoria. Naturalmente os processos I/O – bound possuem um melhor uso e desempenho de CPU. Para nós compreendermos o conceito de escalonamento precisamos conhecer que existem dois tipos de processos relacionados a esse tema. race condition e starvation em ambiente de cluster. como usual. um semáforo para controlar o caldeirão vazio e um semáforo “mutex”.

a CPU. por um semáforo ou por qualquer outra razão.A necessidade do escalonamento Na criação de um processo. 56 . outro processo precisa ser escolhido para ser executado em seu lugar. Já o escalonamento preemptivo estabelece um tempo de execução para cada processo. Quando um processo é bloqueado por dispositivo de E/S. o processo pai ou processo filho. Podemos considerar três ambientes que requerem escalonamentos distintos: Em lote Interativo Tempo Real Existem algumas características que são desejáveis para qualquer tipo de processamento que seriam equidade. Um dispositivo de escalonamento não-preemptivo executa o processo indefinidamente até ele ser bloqueado. isto é. aguardando outro processo. o cumprimento da política estabelecida e o uso máximo de todos os recursos. o dispositivo de escalonamento precisa decidir se o processo que estaria esperando a interrupção de E/S será executado ou outro processo terá a prioridade no uso da CPU. por exemplo. ou quando ele libera o recurso voluntariamente. dispositivos de E/S (entrada e saída) que devem ser utilizados o maior tempo possível. memória. Quanto uma interrupção de E/S ocorre. As decisões tomadas pelo dispositivo de escalonamento ocorrem a cada ciclo de clock do processador. Existe a decisão de quem será tratado primeiro. tendo a autonomia para parar o processo e para passar o tempo de acesso à CPU para outro. Temos também os conceitos de dispositivos de escalonamento preemptivos e não preemptivos. Na necessidade de decidir qual processo será tratado entre aqueles que estão prontos quando um processo deixa de utilizar os recursos.

Quanto isso ocorre o processo que está na primeira posição numa fila passa a ser atendido. onde um escalonador de admissão (admission scheduler) decide qual job será aceito pelo sistema. eles são convertidos em processos e postos em memória. Esse mecanismo seria o primeiro nível de escalonamento. por certo esse é uma técnica não preemptiva de escalonamento. Com essa versão obtém-se um bom desempenho para pequenos jobs. os não aceitos naquele momento. por exemplo. Quando os jobs são colocados em fila. são colocados numa fila de entrada até serem selecionados. dessa forma eles são armazenados em disco. Uma versão preemptiva do “menor job primeiro” seria o “menor tempo restante para ser finalizado”. mecanismo conhecido como swap de memória ou paginação. Porém podemos afirmar que renderização de imagens pode ser considerada como um processamento batch. nesse caso o sistema precisa saber previamente qual o tempo restante de cada processo. Porém o desempenho desse algoritmo depende da sequencia em que os processos chegam e são tratados. Outro algoritmo seria o menor job primeiro. tem uma série de fragilidades e situações em que teria um desempenho não satisfatório. sendo uma das aplicações das mais utilizadas em clusters com um desempenho satisfatório. a não ser em computadores de grande porte (mainframes). fazendo assim que o sistema tenha um melhor desempenho como um todo. Provavelmente um dos mais simples algoritmos de escalonamento seria o “primeiro que chega. Temos também o processo de escalonamento em três níveis.Escalonamento em processamento em lote Esse tipo de processamento não é muito utilizado ultimamente. Podemos chegar numa condição que não teremos mais espaço em memória para colocar os processos em espera. primeiro a ser processado”. 57 . Apesar de não ser preemptivo. tem o uso da mesma até a finalização ou bloqueio do mesmo para. O escalonador precisa distinguir entre jobs CPU-bound e jobs I/O bound. o job em execução é bloqueado e o que chega é executado. Esse algoritmo embora de simples implementação. acessar algum dispositivo de E/S. ele prioriza os processos menores. O primeiro processo que requisita o uso da CPU. Se um job chega e tem um tempo para ser finalizado menor do que está em execução.

As técnicas de escalonamento para Sistemas Interativos usualmente focam mais no escalonamento de CPU. também chamado de escalonamento de memória. O terceiro nível de escalonamento é o que decide qual processo em memória será o próximo a ser executado.O segundo nível de escalonamento é o decide qual processo será colocado ou não em memória. imparcial e amplamente utilizado para escalonamento. Não conseguimos ter em sistemas interativos o processo de escalonamento em três níveis. Existem outros algoritmos de escalonamento como o Backfilling que em linha geral procura executar alguns processos que não estão no topo da fila. Escalonamento em Sistemas Interativos Quando pensamos em algoritmos para escalonamento em sistemas interativos. mas podemos ter dois níveis nesse tipo de sistema (escalonamento de memória e escalonamento de CPU). Para cada processo é dado um intervalo de tempo chamado quantum durante o qual o mesmo pode ser executado. visando um melhor aproveitamento da CPU. 58 . podemos utilizar os mesmos algoritmos para escalonamento de CPU em sistemas de processamento em lote. simples. Escalonamento round robin: Esse é algoritmo é um dos mais antigos. que seria o tempo que o job estabelece para ser executado. Temos também o Earliest Deadline First (EDF) que organiza os jobs por prioridade. executando sempre o job com maior prioridade primeiro. A prioridade é inversamente proporcional ao deadline (tempo limite) do job.

pois a cada troca de processo. etc. Já na atribuição dinâmica de prioridade. Por exemplo. Quando falamos de atribuição estática de prioridade. registradores.bound. estabelecem a prioridade de cada processo. Ao passo que caso se estabeleça um quantum muito longo teremos um tempo de resposta inaceitável para processos de curta duração. um tempo de CPU é utilizado para liberar e alocar memória. tabelas. se ele é I/O-bound ou CPU. Escalonamento por prioridade: No escalonamento round robin partimos da premissa que todos os processos são igualmente importantes. As prioridades poder ser atribuídas estática ou dinamicamente. diminuindo a eficiência da CPU. o processo em espera com a maior prioridade é executado. No escalonamento por prioridade. assim o processo que está pronto para ser executado e com a maior prioridade. Num raciocínio simples. isto é. assim como quanto tempo ele utiliza do quantum que é alocado para ele. se estabelecemos um quantum muito curto. estamos considerando o tipo de usuário ou atividade que requer maior ou menor prioridade. 59 .O único parâmetro com o qual se pode realizar algum ajuste é a duração do quantum. quando tempo destinado ao processo acabar. listas. Podemos pensar num quantum entre 20 a 50 milissegundos como um valor razoável para esse tipo de escalonamento. se pensarmos num sistema em que os processos tratam de cifras. é processado pela CPU. a cada ciclo de clock a prioridade do processo é decrementada ou pode-se também trabalhar com o conceito de quantum. é atribuída uma prioridade para cada processo. informações sobre a característica do processo. teremos um chaveamento excessivo de processos. provavelmente os processos que trabalharem com os maiores valores terão uma prioridade maior. Como prevenção contra processos sendo executados indefinidamente.

assim por diante. Assim dependendo da quantidade de processos em execução. depois quatro. no próximo dois quantums. No próximo ciclo receberá dois quantums. O processo com a maior prioridade receberá apenas um quantum no primeiro ciclo de processamento. Essa técnica é utilizada em outras aplicações. Escalonamento garantido Essa técnica procura literalmente dividir o tempo de CPU entre os processos que estão em execução em dado momento. Podemos assim considerar essas execuções como jobs separados e assim tratá-los com prioridade. quando tem uma alta prioridade. por exemplo. no próximo ciclo. O próximo processo mais curto (Shortest Process Next) Esse algoritmo pode também ser usado em processos em lote. dezesseis. ele receberá um quantum no seu primeiro ciclo de processamento. calculando uma média ponderada dos tempos de execução passados. especialmente de CPU. Mas precisa-se estabelecer um critério ou uma técnica para determinar a duração dos processos. podendo assim receber menos ou mais tempo dependendo da quantidade dos processos concorrentes. sessenta e quatro quantums até finalizar o seu job. que utiliza a técnica de executar os processos mais curtos primeiro que produz bons tempos médios de resposta nesse tipo de processo. como. Nessa técnica pode-se escolher quantos processos já executados serão considerados no cálculo. o processo com maior prioridade receberá quatro quantums. Esse algoritmo evita que um processo monopolize a utilização dos recursos.Múltiplas filas Outra estratégia de escalonamento para sistemas interativos é utilizar múltiplas filas. trinta e dois. Uma abordagem seria considerar o comportamento anterior do processo. oito. Para fazer isso o sistema computa quanto tempo de CPU o processo consumiu na sua criação depois simplesmente divide esse tempo por “n” que seria o número de processos que estão em execução. 60 . Assim se um processo com a mais alta prioridade precisa de cem quantums para realizar um job. A ideia desse algoritmo é utilizar a característica de processos interativos onde temos sucessivas situações de execução de um comando e uma resposta para o mesmo. protocolos de rede. cada um deles receberá igualitariamente ciclos de processamento da CPU. atribuindo certa quantidade de quantums para cada uma delas. é conhecida como aging.

se usuário ativa 9 processos e o outro 1 processo. Para processos que precisam ter prioridade é dado um número maior de bilhetes.Escalonamento lotérico Embora efetivo em termos de resultados. Os processos podem trocar bilhetes num ambiente onde estão trabalhando em cooperação. mas com uma implementação muito mais simples. o escalonamento garantido é de difícil implementação. A ideia é simples. Essa é uma técnica bastante responsiva e eficiente. dando o direito de ter 20 milissegundos de uso do processador. 61 . Mas isso pode influir significamente num compartilhamento adequado de uma CPU. cada processo recebe uma quantidade de bilhetes que permitem acesso a CPU. não considerando os usuários que os executam. O primeiro terá 90% do uso da CPU e o segundo apenas 10%. conhecido “Escalonamento Lotérico”. Assim surgiu outro algoritmo com os mesmos resultados previsíveis. aumentando assim a probabilidade dos mesmos serem escolhidos e automaticamente dando mais tempo de CPU para eles. Para prevenir esse tipo de condição alguns sistemas consideram no escalonamento a quem pertencem os processos. eles terão esse recurso contratado independente de quantos processos cada um colocará em execução. Esses bilhetes são escolhidos aleatoriamente. Por exemplo. Assim se for garantido para 2 usuários 50% da CPU. Escalonamento de compartilhamento justo (Fair-Share Scheduling) Os algoritmos até aqui analisados consideraram apenas os processos em si mesmos.

uma resposta de um jogo de computador a uma ação de quem está o executando.priori” quanto ao comportamento e tempo de execução. usualmente recebem uma requisição a qual precisa ser respondida num intervalo de tempo muito curto. usualmente são de execução curta não ultrapassando a um segundo. etc. como por exemplo. a execução de uma música de um CD. Os sistemas em tempo real podem ser periódicos que possuem intervalos regulares entre os processo e aperiódicos em que os intervalos são imprevisíveis. Obviamente os sistemas periódicos são mais fáceis de serem implementados e podem ser calculados pela seguinte fórmula: Fórmula 1 Onde m são os eventos periódicos onde o evento i ocorre no período Pi e requer Ci segundos para executar cada evento. dizemos que ele é escalonável (schedulable). Se um sistema em tempo real satisfizer as condições dessa fórmula. os processos em tempo real são conhecidos “a . Eles podem ser divididos em hard real times que são aqueles totalmente rígidos em relação aos tempos de resposta (deadlines) e em soft real times significando que se pode ultrapassar o deadline algumas vezes sem comprometer as funcionalidades do sistema.Escalonamento em sistemas em tempo real Sistemas em tempo real. 62 . Em linhas gerais. Os processos são ativados de modo geral por um evento externo que solicita uma atividade a um controlador de processos (scheduler) que garante que cada processo seja realizado dentro do seu deadline.

a tecnologia de IPTV está migrando para outras aplicações como. pelo menos 1 Mbps (megabits por segundo) com os assinantes que podem assistir em tempo real o conteúdo dos Vídeos Servers. Estimase que teríamos cerca de 60 milhões de usuários em todo o mundo que utilizarão essa tecnologia em 2009 (Parks Associates). Em termos de uso da população em geral. na ordem de Terabits. a IPTV é a transmissão de streams de vídeo podendo ser “ao vivo” através de multicast que é uma transmissão de pacotes de um para muitos. por exemplo. pelo menos no Brasil. que armazenam arquivos de som e imagem nos mais diversos formatos. Dessa forma IPTV consome muito menos banda passante do que a VoD devido a modo de transmissão que utiliza.Quando falamos em sistemas em tempo real. IP Surveillance (Vigilância). Nos últimos anos temos visto um crescimento mais consistente do uso dessa tecnologia. Como servidores VoD e IPTV podem ser implementados em clusters de Linux. Dados – Internet e Imagem – TV) por algumas operadoras e também a interatividade proporcionada pela IPTV. 63 . Enquanto o VoD seria um repositório vídeos armazenados podendo ser comparado a uma grande “biblioteca” de DVD’s transmitindo usualmente através pacotes unicasts que é uma transmissão de pacotes um para um. O sistema consiste em servidores com uma capacidade significativa de disco. especialmente com a consolidação e difusão dos aparelhos IPTV. abordaremos esses temas nesse trabalho. tendo conexões de relativa velocidade. substituindo os tradicionais “circuitos fechados” de TV. o IPTV mostra-se mais difundido. Todos os sistemas multimídias requerem uma execução dos processos em intervalos curtos e periódicos para garantir uma boa imagem e som como resultado. Em primeiro lugar. Além disso. precisamos estabelecer a diferença entre as tecnologias. onde a IPTV é uma componente dessa solução. Temos como um avanço uma tecnologia ainda em difusão que é o Video on Demand (VoD) que apesar ser uma solução muito interessante chega ainda a poucos lares de usuários. podemos considerar o tema multimídia como central. Esse aumento de procura está ligado à oferta de triple-play (Voz – Telefone. Assim os sistemas digitais encontrados nos CD’s e especialmente nos DVD’s são exemplos clássicos de dispositivos que demandam um processamento em tempo real.

a perda de pacotes e especialmente o jitter que seria a variação dos intervalos entre os pacotes de fluxo de vídeo e de voz que é mais prejudicial à qualidade do serviço do que um atraso constante dos pacotes mesmo que sejam mais longos. precisamos conhecer como eles são codificados. portanto 0’s e 1’s que correspondem tomadas por amostragem das amplitudes desse sinal no tempo (sampling). 64 . Codificação de Áudio Em termos simples. compressão e correção de erros dos arquivos multimídia. Para entendermos como são estruturados os arquivos multimídia. a codificação de áudio seria transformar um sinal elétrico analógico que corresponde a determinado som. Grande parte da tecnologia para sistemas em tempo real está no formato. Existem técnicas na engenharia de redes para prover qualidade de serviço para aplicações sensíveis ao tempo (QoS).Avançando um pouco mais nas diferenças das tecnologias enquanto o VoD utiliza o RSTP (real-time streaming protocol) para a sinalização e RTP (real-time protocol) para a transmissão do fluxo (stream) de vídeo que são protocolos originalmente utilizados em Voz sobre IP (VoIP). que seria o atraso. Usaremos a digitalização de uma senóide para ilustrar o conceito. seja em sistemas distribuídos. a IPTV utiliza o IGMP (Internet Group Management Protocol) que um protocolo para controle de multicast em redes locais. Apesar de diferenças significativas as duas tecnologias compartilham quase os mesmos problemas quando tratamos de qualidade de Voz e Imagem. Sem esses recursos seria impossível termos capacidade de armazenagem e transmissão desses arquivos assim como uma qualidade de Voz e Imagem aceitáveis. que visam garantir prioridade e intervalos regulares entre esse tipo de tráfego. numa sequencia de códigos digitais. seja na computação convencional. ou como a imagem e o som que a princípio são sinais analógicos são transformados em sinais digitais para que sejam tratados por computadores e sistemas de redes. Também esse tipo de prioridade também precisa ser garantida nos servidores que alojam esse tipo de aplicação.

no gráfico “c” temos o resultado real de um processo de sampling que nunca corresponderá exatamente ao sinal original. podemos utilizar a codificação de telefonia analógica e de Compact Disks (CD’s). gerando respectivamente canais digitais de Voz de 56 e 64 Kbps (kilobits por segundo). no gráfico b temos esses pontos transformados em códigos binários simbolizados pelas linhas verticais. A telefonia utiliza a técnica de digitalização de voz conhecida como PCM (Pulse Code Modulation) que utiliza amostragens de 7 bits (Estados Unidos e Japão dentre outros) e 8 bits (Europa e Brasil dentre outros) 8. com certeza provendo uma qualidade de áudio muito superior ao das ligações telefônicas que utilizam canais digitais. Quando falamos em CD’s temos 44. Podemos pensar em aumentar o número de amostragens. no gráfico “a” temos a escolha dos pontos de amostragem do sinal.Figura 1 Na figura 1. Como exemplos de codificação.100 amostragens por segundo que nos dá uma faixa de frequência na ordem de 22 kHz. Com essa codificação sinais acima de 4 kHz são perdidos. 65 . conseguimos uma qualidade de Voz razoável com essa técnica de codificação. porém isso gera um tipo de distorção conhecida como “ruído de quantização”. mas que para sensibilidade do ouvido humano corresponde a uma qualidade de áudio muito próxima do sinal analógico original como ilustrado no gráfico “d”.000 vezes por segundo. porém apesar da faixa de frequência audível ser de 20 Hz a 20 kHz.

Assim temos uma frequência de 50 quadros/sec que elimina a impressão de tremor da imagem aos olhos humanos. falas. Com essa velocidade de troca de quadros temos uma imagem trêmula.729 ou G. os protocolos G. Abstraindo-nos dos conceitos da eletrônica ao máximo possível.726 para telefonia e o muito conhecido MP3 (MPEG Layer 3) para compressão de músicas.Cathode Ray Tube). nos dando a impressão de movimento. No sistema PAL temos uma frequência de 25 quadros/sec. por isso quando dizemos que existe um problema de sincronismo. De modo geral as técnicas de compressão de Voz trabalham com a redução da redundância da informação através de métodos como codificação. 66 . Os televisores utilizam a técnica conhecida como intercalamento (interlacing). por exemplo. o modo de processamento de imagens nos televisores e monitores convencionais de computador. temos como resultado uma imagem indistinta ou até mesmo apenas faixas na tela. Numa TV temos o que chamamos varredura vertical e horizontal que seria a composição quadro a quadro das imagens. um televisor ou mesmo um monitor convencional possuem um Tubo de Raios Catódicos (CRT . etc.Temos técnicas de compressão de Voz que proporciona economia em armazenagem e na transmissão desse tipo de arquivo como. isto é. reconhecimento de padrões e predição linear para reduzir o tamanho dos arquivos a serem executados ou pacotes a serem transmitidos. O “desenho” da imagem é composto através do bombardeamento de elétrons numa superfície fosforescente que gera um ponto brilhante na tela. Codificação de vídeo Para entender a digitalização de imagens precisamos conhecer os conceitos básicos da transmissão e recepção eletrônica de vídeo. pois não é o foco de nosso trabalho. O conhecido sincronismo vertical e horizontal determina em que ponto da tela a imagem está sendo composta. as linhas pares são transmitidas num quadro e as linhas ímpares num outro.

por isso que os tubos de imagem utilizam o padrão RGB. porém como os computadores podem armazenar as imagens em memória. consegue-se obter uma frequência de troca de quadros de 75 vezes por segundo. se um ícone tem 32 pixels de altura e 32 pixels de largura ele conterá um total de 1024 pixels. Os monitores de computador trabalham com o conceito de pixel que é o menor elemento que compõe uma imagem ou caractere num monitor de computador. Blue) que conseguem compor todas as outras cores. As imagens são formadas nos computadores. apesar de possuírem o mesmo aparato eletrônico dos televisores. curiosamente não sendo as cores conhecidas popularmente como primárias que seriam o vermelho. Nos televisores coloridos temos 3 canhões de elétrons com as cores RGB (Red. pelo menos nas artes plásticas. o reconhecimento das cores “primárias” não é um conceito físico mais fisiológico relacionado à reação do olho em relação à luz e seus diversos comprimentos de onda que compõe um número quase infinito de cores. também conhecidos como crominância e luminância dos pixels. Assim dizemos que os monitores de computador utilizam um escaneamento progressivo. não necessitando assim do intercalamento. Green. o azul e o amarelo. O olho humano tem três receptores de luz conhecidos como “cones”. precisamos ter pelos 25 quadros/sec utilizando a técnica de intercalamento. Tratando-se de monitores de computador. por exemplo. sendo que cada um deles respondem ao comprimento de onda das cores “vermelha”.Esses pontos compõem as imagens através do desvio de suas trajetórias por eletromagnetismo provido por um componente eletrônico conhecido como “bobina defletora”. “verde” e “azul” sendo essas consideradas como primárias tratando-se de fontes de luz. eles traduzem sinais digitais em imagem. Apenas a título de esclarecimento. 67 . Para garantir a persistência da imagem adequada ao olho humano. através de variações de cor e brilho. diferentemente desses. como já mencionado.

os codificadores de uso geral e comercial são todos lossies. por exemplo. Obviamente quanto mais linhas ou quanto maior a resolução. numa frequência de 25 quadros/sec. Um segundo tipo de assimetria na compressão de vídeo. um monitor com resolução 800x600 significa que tem 800 linhas na vertical e 600 linhas na horizontal. um sistema de vídeo conferência precisa ter tanto a codificação e a decodificação em tempo real. Entre esses dois algoritmos temos o conceito de assimetria.Os monitores de computador têm o conceito de resolução que seria quantas “linhas” o monitor teria na vertical e na horizontal. se estivermos falando VoD. o sistema de codificação pode ser lento e despender um hardware mais poderoso e caro. Compressão de Vídeo Todo sistema de compressão de arquivos de imagem precisa ter dois algoritmos: um de compressão e outro de descompressão. seria que a imagem originalmente codificada não precisa necessariamente ser exatamente igual quando a mesma for decodificada. quando isso ocorre dizemos que o sistema é lossy. 68 . uma imagem num monitor com resolução de 1024x768 tendo um pixel com tamanho de 24 bits. por exemplo. Há na maioria dos casos uma leve perda de qualidade entre a imagem original e a que é visualizada após ser descomprimida num determinado sistema. na literatura em geral. Por outro lado. necessitando assim de hardware e software apropriados para esse tipo de aplicação. melhor a qualidade de imagem. Quantidade de bits para compor uma imagem é usualmente é alta. eles são chamados de codificação (encoding) e decodificação (decoding). porém o processo de decodificação precisa ser rápido e concebido para ser executado num hardware mais acessível em termos de preço. Daí a obrigatoriedade tecnológica de trabalhar com compressão de imagens nos computadores e nas redes. porém tal assimetria é aceitável em termos de acuidade do olho humano. mas existem lossless codecs na compressão de vídeo. De fato. de fato isso raramente ocorre. necessitaria de 472 Mbps para ser transmitida.

A resolução da crominância é reduzida. A razão de se utilizar esse recurso matemático que trabalha com 3 dimensões (espacial) é porque na codificação do JPEG temos 3 elementos. sendo similar ao padrão PAL de televisão analógica. Isso reflete o fato que os olhos são menos sensíveis a pequenas alterações na cor do que pequenas alterações no brilho. Lembrando que esse padrão é utilizado na codificação das imagens de TV Digital e DVD. Se uma configuração de excessiva baixa qualidade for utilizada. normalmente pela metade. O processo de compressão do JPEG não é trivial assim apresentaremos o mesmo de uma forma simples. Os componentes da amplitude da frequência são quantizados. passam por uma transformada conhecida como DCT (Discrete Cosine Transform). O olho humano é muito mais sensível a pequenas variações de cor e brilho em áreas amplas do que variações em alta frequência de brilho. não utilizados na interpretação usual das mesmas. dados os componentes Y’. A imagem é dividida em blocos de 8x8 pixels e cada bloco. de modo a satisfazer o propósito desse trabalho no que concerne à codificação de imagem. 50 ou 90 numa escala de 0 a 100 na biblioteca do “Independente JPEG Group”) afeta o quanto a resolução de cada componente de frequência será reduzido. mas o mais utilizado é o JFIF (JPEG File Interchange Format). o Y’ que é o componente de luminância representando o brilho e dois componentes de crominância (Cb e Cr) representando a cor. Portanto. a magnitudes dos componentes de alta frequência são armazenadas com menor acuidade do que componentes de baixa frequência. que é a representação numérica de um sinal analógico. Uma transformada DCT similar à transformada de Fourier que produz um tipo de espectro de frequência espacial.Padrão JPEG Um dos mais conhecidos padrões de compressão de imagem é o JPEG (Joint Photographic Experts Group). 69 . todos os componentes de alta frequência são descartados de uma vez. Segue uma descrição sucinta desse processo de codificação: A representação das cores é traduzida do padrão RGB para Y’CbCr. Cb e Cr dos mesmos. sendo sistemas arbitrários de cores. Existem muitos padrões para produzir-se esse tipo de arquivo. No caso do modelo Y’CbCr. que são modelos matemáticos conhecidos como espaços de cores (Color Spaces) . a representação Y’CbCr. A qualidade estabelecida no codificador (por exemplo.

As duas versões se beneficiam com duas redundâncias existentes em filmes: espacial e temporal. servirão de base teórica para apresentarmos o padrão de compressão de vídeo MPEG (Motion Picture Experts Group). que é um dos principais padrões de compressão de vídeo desde 1933. 70 . Apesar das câmeras digitais terem uma velocidade menor do que os sistemas tradicionais de vídeo sem compressão. O MPEG1 foi concebido para a compressão de vídeo para o sistema NTSC numa taxa de 1. Por exemplo. sendo a grande diferença entre o MPEG e o JPEG. publicou em 1952 o artigo “A Method for the Construction of Minimum-Redundancy Codes”. A saída do MPEG consiste de três tipos diferentes de quadros que são processados pelo programa de visualização: 10 David A. um algoritmo de codificação de entropia. Daí a necessidade de ter-se uma maneira de compensar essa movimentação nas imagens. podendo ser utilizado tanto no sistema PAL como no NTSC. os últimos têm uma qualidade de imagem muito aquém daquela proporciona pelo Vídeo Digital. O MPEG2 foi criado com uma compressão de broadcasting com qualidade. essa técnica é extremamente improdutiva. em taxas de 4 a 6 Mbps.2 Mbps. Isso é exatamente que o MPEG faz. Uma compressão adicional pode ser obtida pelo fato que os quadros consecutivos são quase sempre idênticos (Redundância Temporal). Por outro lado. O Sistema de Vídeo Digital usado nas câmeras digitais utiliza o padrão JPEG porque a codificação tem que ser feita em tempo real sendo muito mais rápida do que codificar cada quadro separadamente. Huffman enquanto fazia o doutorado no MIT.Os dados resultantes dos blocos 8x8 são ainda comprimidos com um algoritmo lossless. A redundância espacial é alcançada apenas codificando cada quadro separadamente com JPEG. uma variação da codificação de Huffman10. numa cena onde temos as imagens de fundo sem alterações e um ou dois personagens movimentando-se lentamente. praticamente quase todos os pixels serão idênticos quadro a quadro. se temos uma cena com ampliação e redução da visão panorâmica das imagens de fundo. Padrão MPEG Toda essa teoria e conceitos até agora apresentados no que concerne padrões tradicionais de transmissão e compressão de imagem.

qualquer um que perdesse o primeiro quadro nunca poderia decodificar qualquer quadro subsequente. com resolução de luminância completa e a metade da resolução de crominância em cada eixo. Isso fica a cargo de cada implementação. baseandose num parâmetro previamente estabelecido. Isso tornaria impossível ao espectador sintonizar um filme depois que ele já tivesse iniciado. o decodificador teria que calcular todo quadro transmitido para que ele soubesse exatamente onde ele havia parado. ao realizar rápidos forward e rewind. É necessário ter Quadros I aparecendo periodicamente na saída do fluxo de imagem por três razões. Segundo. codifica a diferença entre os quadros. com os espectadores podendo sintonizar os canais segundo seu desejo. Terceiro. existem algoritmos muito mais sofisticados para manusear macroblocos. o mesmo é inserido na saída de vídeo uma a duas vezes por segundo. realizando uma comparação entre os quadros encontrados. A posição com o maior escore seria declarada a “vencedora”. diferentemente. 71 . se qualquer quadro estivesse tendo uma recepção com erro. Naturalmente. o número de igualdades identificadas na matriz de luminância pode ser computado. A primeira. O padrão MPEG não especifica como buscar. sem os Quadros I.Quadro I (Intracoded): Contendo codificação JPEG para imagens estáticas. não se poderia continuar com a decodificação. até onde buscar ou o quanto o quadro está coerente com a busca. Como o Quadro I é possível saltar no forward e no rewind até que um Quadro I seja encontrado e iniciar-se a visualização daquele ponto. uma implementação pode buscar por um macrobloco na posição corrente e nos quadros anteriores. Eles são baseados na ideia de macroblocks (macrobloco) que cobrem 16x16 pixels em espaço de luminância e 8x8 pixels em espaço de crominância. O Quadro I é apenas imagens estáticas codificadas em JPEG. Um macrobloco é codificado para buscar quadros anteriores. Quadro B (Bidirecional): Diferença entre o último e o próximo quadro. Por exemplo. Se todos os quadros dependessem do seu predecessor voltar para o primeiro quadro da transmissão. Os Quadros P. Caso esse parâmetro não for alcançado poder-se-ia dizer que o macrobloco foi perdido. o MPEG pode ser usado para TV Broadcasting. Para cada posição. Quadro P (Predictive): Diferença bloco a bloco com o último quadro. visando à diferença entre os blocos.

Para simplificar a decodificação. seguido pelas diferenças com o quadro anterior codificadas em JPEG. o valor corrente é codificado em JPEG. o corrente e futuro. por exemplo. num Quadro I ou um Quadro P. tentar reproduzir um filme de frente para trás não será possível sem um considerável buferização e complexos algoritmos. sistema de arquivo e escalonamento de disco. Devido a essa diferença entre a ordem de dependência e a ordem de visualização. considerando a diferença entre seu valor e do quadro anterior (para a luminância e as duas crominâncias). Escalonamento Homogêneo de Processos O tipo mais simples de servidor de vídeo é aquele que suporta a visualização de um número fixo de filmes. O valor do macrobloco no fluxo de saída de vídeo é então o vetor de movimento (o quanto o macrobloco mudou de sua posição anterior em cada direção – eixos x e y de crominância). Os Quadros B permite a um quadro ser baseado no quadro futuro. quando um vídeo é assistido através de uma rede. os quadros precisam estar presentes no fluxo do MPEG numa ordem de dependência e não numa ordem de visualização. O quadro B é similar aos Quadros P. Essa liberdade adicional permite melhorar a compensação do movimento nas imagens. Essas matrizes de diferenças são então submetidas à codificação JPEG. é requerido fazer uma buferização (buffering) no computador do usuário para reordenar os quadros numa visualização apropriada. objetos passam na frente ou atrás de outros objetos. exceto que ele permite o macrobloco de referência ser ou o quadro anterior ou o quadro posterior. como se fosse um Quadro I. o codificador precisa manter três quadros codificados na memória ao mesmo tempo. o anterior.Se um macrobloco é encontrado. resolução. todos utilizando a mesma taxa de quadros. um simples. ele é codificado. quando. taxa de dados e outros parâmetros também semelhantes. Escalonamento de Processos em Sistemas Multimídia Sistemas Operacionais que suportam multimídia diferem dos tradicionais em três principais aspectos: escalonamento de processos. Se o macrobloco não está no quadro anterior. Sob essas circunstâncias. Assim mesmo com uma temporização perfeita. mas efetivo algoritmo de escalonamento seria como segue: 72 . Para codificar um Quadro B.

assume-se que o sistema sabe a frequência na qual cada processo deve ser executado. Quando o processo termina o seu trabalho. Um número significativo usuários mudam como expectadores. e qual é o seu próximo tempo limite. Modelos Gerais de Escalonamento para Processos em Tempo Real Infelizmente o Escalonamento Homogêneo de Processos é raramente aplicável à vida real. Até quando os processos são curtos o suficiente para que todo o trabalho seja feito dentro de um ciclo. Nesses modelos. A cada ciclo do relógio. há um simples processo ou thread cujo job seria acessar o filme no disco. Essas considerações levam a um modelo de múltiplos processos competindo pela CPU. todos os processos são executados sequencialmente. 30 vezes por segundo (para NTSC). Esse escalonamento de processos competindo entre si. o quanto de trabalho tem de fazer. alguns ou mesmo todos tendo tempos limites que devem ser cumpridos é chamado escalonamento em tempo real. teremos o mesmo volume de trabalho a fazer para cada quadro. O escalonamento round robin é plenamente adequado para esse tipo de processo. Desde que todos os processos são igualmente importantes. ele emite uma chamada de suspensão do sistema que libera a CPU até o próximo ciclo do relógio. o escalonamento round robin é adequado. Como consequência. por exemplo. processos diferentes precisam ser executados em frequências diferentes. bloqueando quando eles finalizarem o processo do quadro corrente. tamanho de quadros variam consideravelmente devido à natureza da compressão de vídeo (Quadros I são muito maiores que Quadros P e B) e filmes diferentes podem ter diferentes resoluções. com diferentes quantidades de trabalho e com diferentes deadlines dentro dos quais o job deve ser efetuado. na mesma ordem. A única adição necessária para um algoritmo padrão de escalonamento seria o mecanismo de temporização para garantir que cada processo seja executado na frequência correta. Um modo de obter uma temporização adequada é possuir um relógio (clock) mestre que oscila. 73 .Para cada filme. cada um com sua própria tarefa e tempo limite (deadline). um quadro de cada vez e então transmiti-lo para o usuário.

74 . o buffer precisa estar ajustado de modo a receber todas as rajadas referentes ao tempo limite de um dado processo e enviá-lo numa única operação para o usuário requisitante. Em alguns sistemas em tempo real. Em sistemas multimídia. um para áudio e outro para vídeo. poderia haver dois ou mais processos por fluxo. Algoritmos estáticos designam para cada processo uma prioridade pré-estabelecida e então se trabalha com essas prioridades utilizando a preempção. significando que o processo consegue perceber que estará excedendo o seu tempo limite. assim o processo anterior pode continuar.Como vimos na página 62 desse capítulo. podendo assim interromper o que está sendo executado naquele momento antes de finalizar o seu o quadro. sistemas periódicos de multimídia podem ter a alocação de CPU calculada através de uma somatória onde m é o número de processos e Pi/Ci é uma fração de CPU utilizada pelo processo i. Até agora estamos considerando sistemas com um processo por fluxo. Eles podem ser executados em diferentes taxas e consumir diferentes quantidades de CPU por rajada. De fato. Em outras palavras. cada um deles sendo executados numa frequência fixa com uma quantidade fixa de trabalho necessário em cada rajada de CPU. Algoritmos dinâmicos não utilizam prioridades fixas. Por exemplo. os processos são geralmente capazes de antecipar-se. os processos têm a capacidade de antecipar-se (preempção) e outros não têm essa funcionalidade. desde que se assuma que existem “n” processos. Os algoritmos de sistemas em tempo real podem se estáticos ou dinâmicos. Adicionar o áudio no sistema não muda o modelo no geral. Usualmente os sistemas em tempo real têm melhores resultados utilizando a preempção. sendo o sistema capaz de ser escalonado se a somatória for menor que 1. porém eles podem a apresentar problemas de jitter caso o buffer de transmissão acabe tendo o seu limite de tamanho excedido devido ao recebimento de várias pequenas rajadas dos processos dentro de um tempo limite.

Nenhum pode ser dependente de outro. resultando em 33 execuções por segundo. Qualquer processo não periódico não deve ter tempo limite (deadline). O processo de preempção ocorre instantaneamente sem overhead. se um processo tem uma frequência de execução a cada 30 milissegundos.Escalonamento de Taxa Monotônica (Rate Monotonic Scheduling) O mais clássico de escalonamento algoritmo estático para processos em tempo real periódicos e preemptivos é o RMS (Rate Monotonic Scheduling). o sistema sempre escalona os processos com a maior prioridade prontos para serem executados utilizando a preempção. O RMS trabalha designando prioridades para cada processo baseado na frequência em que cada um é executado. Cada processo precisa ter a mesma necessidade de CPU para sua rajada. se necessário. De acordo com o algoritmo. por exemplo. Ele pode ser utilizado para processos que satisfaçam as seguintes condições: Cada processo periódico deve ser completado dentro do seu período. sua prioridade será 33. 75 .

Sistemas de Arquivos em ambientes multimídia Os sistemas tradicionais de armazenagem e acesso ao sistema de arquivo mostramse inadequados para sistemas multimídia. sem atrasos e ainda necessitar-se ter funcionalidades como mover-se rapidamente para frente.Escalonamento Tempo Limite mais Exíguo Primeiro (Earliest Deadline First) Esse é um algoritmo de sistemas em tempo real dinâmico. o traz para o seu computador (Pull Server). por razões como a necessidade da disponibilização do arquivo dentro de uma mesma frequência. caso seu tempo limite seja o menor. Para que isso ocorra é necessário um método acesso aos arquivos como um Push Server onde o servidor de arquivos após receber as informações para localização e buferização do arquivo “empurra” o mesmo para o usuário. O algoritmo EDF (Earliest Deadline First) é mais resiliente que o RMS (Rate Monotonic Scheduling). 76 . ele é executado primeiro. ele anuncia sua presença e seu tempo limite. mover-se rapidamente para trás e pausa. podendo então realizar as operações de equipamentos tradicionais de multimídia como um VCR. diferentemente do acesso tradicional a arquivos onde o usuário após localizar o arquivo que deseja abrir. pois o se último tiver a taxa de utilização de CPU acima de 78% não provê uma garantia de perfeita funcionalidade. O algoritmo executa então o primeiro processo da lista. Assim um servidor de arquivos precisa atuar mais como um videocassete ou DVD Player do que um computador. dessa forma eles não possuem uma periodicidade nem requerem um mesmo tempo de execução para rajada de CPU. A qualquer momento em que um processo precisa de um tempo de CPU. que é aquele mais próximo do seu tempo limite. A cada novo processo o sistema checa se o tempo limite do mesmo é menor dos que já estão lista de processos prontos a serem executados.

Porém.Figura 2 Pull Server Push Server Armazenagem de arquivos em Sistemas Multimídia Usualmente os arquivos multimídia são muito grandes. se os mesmos estiverem gravados em arquivos contíguos separados. Armazenagem de arquivos multimídias num único disco O pré-requisito para ter-se uma reprodução de um arquivo multimídia de qualidade seria executar o mesmo na velocidade solicitada e sem jitter. teremse múltiplos acessos ao disco durante um quadro não é desejável. 77 . áudio e texto. Temos modelos para um único disco ou para vários. tendo a tendência de serem acessados sequencialmente. se tivermos numa reprodução a presença de vídeo. Por esse motivo. áudio e texto que poderia causar jitter. como usual. Sendo essa forma de acesso apropriada apenas para arquivos de vídeo. Juntos. haverá uma alternância no acesso aos arquivos de vídeo. eles são na maioria das vezes escritos uma vez e lidos muitas. Sua reprodução deve também alcançar critérios estritos de qualidade serviço. esses requerimentos sugerem um desenho diferente de sistema de arquivo daquele utilizado nos sistemas operacionais tradicionais. Uma forma de eliminar acessos ao disco durante a execução de um arquivo multimídia é o uso de arquivos contíguos.

Vale também ressaltar que para esse modelo. mover-se rapidamente para trás não são possíveis. Nessa organização o tamanho de bloco escolhido deve ser consideravelmente menor do que a média do tamanho de um quadro. moverse rapidamente para frente. mas a qualidade da reprodução compensa essa utilização adicional dos recursos de máquina. mantendo assim a frequência da reprodução e evitando o jitter. um índice de quadros por vídeo. o índice deve conter também o tamanho do quadro em quantidade de blocos.Para minimizar esse efeito utiliza-se uma técnica também usada em VoIP (Voice Over IP) conhecida como interleaving (intercalamento). A primeira delas é conhecida como “modelo de blocos pequenos”. A ideia é ter numa estrutura de dados. Uma vez que os quadros têm tamanhos diferentes. o acesso randômico. onde arquivos de textos de igual tamanho são colocados entre os arquivos de áudio e vídeo. Figura 3 Essa organização de arquivo requer a utilização mais recurso de E/S de disco e buffer. mesmo para Quadros P e quadros B. Figura 4 78 . Para arquivos não contíguos contemplaremos duas organizações de arquivos multimídia.

uma informação adicional é requerida. pequeno desperdício de disco. 79 . mas com buscas extras por quadros. sem desperdício de disco. conhecido como “i-node” (index node) que é um array que lista os atributos e endereço no disco dos blocos de arquivos. Figura 5 Podemos resumir as vantagens e desvantagens desses modelos da seguinte forma: Indexação por Quadro: Consumo alto de RAM. Um índice é ainda requerido. índice esse semelhante ao indexador de arquivos tradicionais. fazendo assim a localização dos mesmos. que seria qual quadro está no início de cada bloco. múltiplos quadros são colocados num bloco. No “modelo de blocos grandes” temos duas variações. porém um índice de blocos e não de quadros. uma em que os quadros não são separados entre os blocos e outra que eles são divididos entre os mesmos. Nessa situação.A outra forma organização de arquivos multimídia para arquivos não contíguos é armazená-los em grandes blocos de disco. Indexação por Bloco (Com separação de quadros entre os blocos) Baixo consumo de RAM. Indexação por Bloco (Sem separação de quadros entre os blocos): Baixo consumo de CPU e maior desperdício de espaço em disco. No caso de arquivos multimídia.

porém toma um tempo significativo. onde teremos mais do que um quadro por bloco ou mesmo quadros divididos entre blocos. colocar um bloco em cache esperando que o mesmo seja reutilizado não seria produtivo tendo em vista a dinâmica desse tipo de sistema. assim o bloco onde está quadro pretendido é colocado em buffer.A alternativa para minimizar os efeitos do uso excessivo de memória RAM seria a “paginação”. Para facilitar e otimizar as buscas dos quadros quando falamos em indexação por blocos. uma solução seria usar uma buferização circular ligeiramente maior que o tamanho do bloco. que é armazenar em disco dados da memória RAM quando a mesma atinge o seu limite. Assim os servidores mantêm em disco uma cópia dos vídeos mais demandados para aperfeiçoar essa operação. consumindo menos recursos. se temos dois usuários acessando um mesmo arquivo multimídia num intervalo muito pequeno. 80 . a acessar o mesmo arquivo multimídia. com um deles iniciando 2 segundos após o outro. a tecnologia e o propósito do cache passam a ser interessantes. porque um bloco acessado pelo primeiro. devido ao seu tamanho. o termo paginação também vem da ideia que a memória RAM é dividida em pequenas partições facilitando assim o gerenciamento da mesma. se colocado em cache será acessado de maneira muito mais rápida e com mais performance que o segundo caso acessasse o disco novamente. serem armazenados em CD’s e DVD’s e apenas copiados para o disco quando solicitados. Outro uso para o cache de arquivos seria o fato dos arquivos de filmes. a tecnologia de cache pode ser utilizada para otimizar esse acesso. Cache em Sistemas Multimídia Uso tradicional do cache em Sistemas Multimídia seria sem propósito. Esse processo. eles ainda não são acessíveis em termos de custos para todos os segmentos de negócio. isto é. operação que requer quadros contíguos. dessa forma a busca e transmissão do quadro em questão é viabilizada. dando tempo assim para cópia dos mesmos na íntegra do CD ou DVD para o disco. Podemos também manter em disco os primeiros minutos de todos os vídeos disponíveis. quando solicitados. Em suma. Porém quando falamos em dois espectadores assistindo um mesmo filme. Apesar de atualmente termos storages da ordem de Terabytes que evitaria a armazenagem de arquivos em mídias de acesso mais lento.

precisamos de um mecanismo de alocação dinâmica. um quadro de cada fluxo de vídeo é executado. no momento da leitura do quadro será necessário saber quanto tempo o mesmo precisaria para ser executado. como explanado acima.Vale ressaltar que estamos abordando aqui duas modalidades de cache. Assim existe um ciclo para o acesso ao disco conhecido como rounds. como por exemplo. Dois fatores são considerados para realizar essa escolha: o deadline e o cilindro do disco. não é possível o acesso em paralelo de vários quadros de fluxos de vídeo diferentes. Quando tratamos de resolução e velocidade de quadros diferentes. Esse conceito é válido para vídeos com as mesmas características. A primeira é o cache convencional que é uma área de armazenamento temporária de acesso mais rápido do que ao disco onde são colocados os dados mais frequentemente utilizados. que é o tempo limite (deadline). Como os fluxos de vídeo têm características diferentes. o scan-EDF. assim o sistema precisa escolher qual bloco executar dentro de parâmetros préestabelecidos. Escalonamento de acesso a disco em Sistemas Multimídia Diferentemente de sistemas convencionais o escalonamento estático de acesso ao disco em sistema multimídia é extremamente previsível pois os quadros tem um tempo fixo para serem executados dentro das técnicas de codificação de vídeo. podendo assim vários vídeos acessar o disco ao mesmo tempo. que no caso dos sistemas multimídia é usado com um propósito ou objetivo diferente dos sistemas tradicionais. Manter a escolha no mesmo cilindro otimiza o tempo de busca em disco mas pode comprometer o tempo limite (deadline). Nesse intervalo de tempo. Na segunda modalidade o disco rígido é considerado um “cache” para mídias de acesso mais lento como o CD ou o DVD. Assim são necessários algoritmos que equilibrem esses dois parâmetros. 81 . Nesse caso.

como. esse trabalho abordará apenas os conceitos e tecnologias que são foco dessa pesquisa.Fundamentos de Sistemas Operacionais com Processamento Distribuído A apresentação dos conceitos referentes ao processamento convencional e executado em único um computador. que não faremos aqui distinção entre sistemas distribuídos e clusters. com raras exceções. abstraindo-nos da tecnologia de multinúcleo e multiprocessadores. nos servirá como fundamento teórico para identificarmos as particularidades e funcionalidades de Sistemas Operacionais Distribuídos. não podemos dizer que ele é um padrão “de facto”. apresentaremos as camadas desse modelo mais como uma referência que facilitará o entendimento dos princípios apresentados do que um modelo que seria implementado na prática nas diversas aplicações e tecnologias de redes. 82 . como já explanado no início do capítulo. Apesar de podermos dizer que o modelo ISO/OSI é utilizado amplamente como diretriz para especificação e entendimento de elementos de rede. ressaltando novamente que por uma questão de abordagem do nosso trabalho. o protocolo IS-IS (Intermediate System to Intermediate System) que é um protocolo baseado puramente no padrão. Dessa forma. Redes de Computadores Antes de avançarmos nos temas que são comuns aos ambientes monoprocessados e distribuídos. por exemplo. Tendo em vista a amplitude da disciplina. mas que na prática é muito pouco disseminado. Vamos partir do modelo ISO/OSI (International Standards Organization/Open Systems Interconnection) que foi publicado em 1984 com o objetivo de criar um modelo de camadas que visava facilitar o desenvolvimento e a homogeneidade dos equipamentos e produtos de redes. dentre outros motivos. precisamos abordar tecnologia responsável pela comunicação entre os computadores que compõe os sistemas distribuídos que poderia ser chamada de Redes de Computadores.

Segue uma explanação de cada uma das camadas do modelo ISO/OSI. fazendo uma comparação do mesmo com o protocolo TCP-IP (Transport Control Protocol – Internet Protocol) que é um do modelo “de facto” e utilizado praticamente quase todas as comunicações de rede atualmente: Camada Física: Responsável pela transmissão de sinais digitais (bits) convertidos em sinais elétricos. um PDU (Protocol Data Unit) mais confiável e livre de erros para as camadas superiores. conhecido endereço MAC (Medium Access Control). mantendo-se fixas mesmo com mudanças na rede ou dinâmicas que se adaptam às mudanças na rede através de protocolos de roteamento. Essas rotas podem ser estáticas. quando usamos o termo “switch camada 3” qualquer profissional em redes já saberá exatamente as várias características e particularidades desse equipamento sem necessitar-se qualquer explicação adicional. eletromagnéticas e óticas. O endereçamento IP é uma notação constituída de quatro partes conhecidas como octetos e uma numeração complementar conhecida como máscara que determina as limitações lógicas desse endereço. especificações elétricas. como por exemplo. quantos elementos podem ser endereçados pelo mesmo. Na camada de enlace temos também o endereçamento físico dos elementos de rede. óticos e mesmo ondas de rádio (wireless). o endereçamento IP. Nessa camada também é tratado o endereçamento lógico dos elementos da rede. Os PDU’s são as unidades padrão de cada uma das camadas do modelo OSI. garantindo assim. utilizando cabeamento UTP (Unshielded Twisted Pair) com conectores RJ-45. por exemplo. Camada de Rede Essa camada é responsável pelo encaminhamento lógico dos pacotes (o nome da PDU nessa camada).Apesar de esse modelo ter uma aplicação prática restrita. Camada de Enlace: A camada de enlace trabalha com unidades de transmissão de dados chamadas de frames que usualmente são constituídos de algumas centenas ou mesmo alguns milhares de bytes. 83 . por exemplo. Por exemplo. através do que chamamos rotas. Também responsável pela padronização de interfaces físicas. o mesmo é muito didático e também se tornou um meio eficaz de tornar mais claro e homogêneo o discurso e o jargão utilizado pelos profissionais da área. o foco de nosso trabalho será redes locais (LAN). utilizando mecanismos de detecção e correção de erros.

A camada de sessão é também responsável por controle de operações dentro de determinados protocolos nos quais. 84 . respectivamente portas 80. equipamentos e fundamentação teórica. por exemplo. reconhecimento de chegada de segmentos e dispositivos de detecção e correção de erros. A multiplexação é garantida no protocolo TCP-IP através de um dispositivo conhecido como porta. chamadas segmentos. para transferência de arquivos ou mesmo num sistema de acesso remoto com tempo compartilhado. se necessário. Uma sessão pressupõe uma conexão entre dois elementos por vez. especialmente quando falamos da função correspondente dessa camada no TCP-IP. assim tem-se portas de serviços e aplicações já conhecidas como o HTTP. 21 e 23. Um dos serviços da camada de sessão seria estabelecer um controle do “diálogo” entre as máquinas. respectivamente conhecidas como TCP (Transport Control Protocol) e UDP (User Datagrama Protocol). A camada de transporte é também responsável pela multiplexação da comunicação entre os elementos da rede. e entregá-los à camada de rede garantindo que os mesmos cheguem corretamente do outro lado da comunicação. FTP e Telnet que possuem um número padrão. através do estabelecimento de sessões entre os computadores. por exemplo. Essas portas são conhecidas como well-known e ficam abaixo de número de porta 1024. Camada de Sessão Semelhante a camada de transporte a camada de sessão também gerencia a transmissão de dados. Essa funcionalidade é conhecida como token management. por exemplo.Essa camada abarca uma série de tecnologias. a segunda preocupada em apenas enviar os dados sem nenhuma garantia de chegada ao destino. permitindo que numa mesma conexão em nível de 3 (camada de rede) vários serviços possam comunicarem-se ao mesmo tempo. Camada de Transporte A principal função da camada de transporte é receber os dados da Camada de Sessão. Em TCP-IP temos o conceito de comunicações orientadas à conexão e não orientadas a conexão. se o tráfego fluirá nas duas ou numa mesma direção ao mesmo tempo dentro de determinada sessão. não seria permitido os dois lados de a sessão realizarem uma operação ao mesmo tempo. mas com algumas funções adicionais. a primeira garante o envio e o recebimento através de um sistema negociação. podendo dizer que seria uma das mais relevantes camadas. dividi-los em unidades menores.

Além de serem agrupamentos de bits. os mesmos podem ser representados nos padrões ASCII. EBCDIC ou mesmo Unicode. por exemplo. no sentido de estabelecer pontos de controle e recuperação durante a sessão. valores financeiros. Camada de Apresentação A camada de apresentação preocupa-se com a sintaxe e semântica dos dados transmitidos. Esses itens são convertidos em representações e estruturas de dados. datas. caso ocorra uma interrupção não programada da mesma. Os computadores podem ter padrões diferentes de conversão. como por exemplo.Ela é também responsável pelo serviço de sincronização. O protocolo TCP-IP não tem formalmente uma camada de apresentação. mas possui protocolos que utilizam os princípios da mesma. etc. O protocolo TCP-IP não contempla formalmente uma camada de sessão. Em suma a camada de apresentação recebe os dados vindos da rede e os representam da maneira que o computador que recebe esses dados. os compreenda. os dados representam nomes. o NFS (Network File System) dos sistemas operacionais Unix ou Linux. 85 . quando tratamos de representação de caracteres (letras e números em textos convencionais).

emulação de terminal.Camada de Aplicação É importante ressaltar que quando abordamos o termo aplicação no modelo ISO/OSI estamos nos referindo a aplicações de redes. Segue uma comparação entre o modelo ISO/OSI o protocolo TCP-IP: Figura 6 86 . etc. HTTP (HiperText Transfer Protocol). navegador de Internet. correio eletrônico. Novamente teremos na prática aplicações do protocolo TCP-IP como FTP (File Transfer Protocol). SMTP (Simple Mail Transfer Protocol). etc. Essas aplicações são transferência de arquivo.

Processos e Threads Apesar de termos vistos processos e threads separadamente. Quando temos múltiplas threads (Paralelismo) temos a possibilidade de multiprocessamento seja através de um processador multinúcleo. quando os abordamos no monoprocessamento. Existem sistemas ou primitivas non-blocking em que enquanto a tarefa de determinada chamada de sistema está utilizando outro dispositivo que não o processador. Um exemplo de blocking seria quando uma thread ou mesmo um processo acessam o disco e precisam esperar a resposta do mesmo. 87 . Essa característica faz as threads mais apropriadas para sistemas distribuídos por possuírem a funcionalidade intrínseca de paralelismo. threads compartilham o mesmo espaço de memória que faz o seu comportamento e uso diferir significamente dos processos. o conjunto de múltiplas threads e primitivas blocking seria o mais recomendado. Assim falando-se na utilização de threads em ambientes distribuídos. Assim podemos ter um processo manipulando múltiplas threads. seja através de um computador com múltiplos processadores ou através de múltiplos computadores num ambiente de computação distribuída. perdendo assim em desempenho assim como em otimização de recursos computacionais. podendo também utilizar primitivas blocking. apesar de apresentarem a princípio uma melhor performance. Podemos dizer que os processos estão para os computadores. pois chamadas de sistema blocking ou síncronas torna a programação mais simples e múltiplas threads possibilitam o paralelismo. o mesmo é liberado para ser utilizado por outras threads ou processos. Como vimos anteriormente. possuem dificuldades significativas de controle e implementação. nesse caso o disco e seu driver. Nesse momento eles entram num estado de blocking até receber os dados solicitados. Seguem outros argumentos que fazem as threads mais apropriadas para o processamento distribuído: Iniciar e controlar uma thread para uma requisição entrante é muito menos onerosa para o sistema do que iniciar um processo. Quanto o sistema está em blocking o processador fica inativo até receber a resposta do dispositivo que está executando a tarefa. assim como as threads estão para os processos. Primitivas non-blocking ou assíncronas como também são conhecidas. para fins didáticos discutiremos os dois conceitos conjuntamente ao apresentarmos os fundamentos do processamento distribuído.

usando o sistema de bloqueio de chamadas (blocking) com as threads temos também uma simplificação dessa estrutura. necessitando de uma abordagem totalmente distinta para a comunicação entre processos e threads. Porém temos o cluster Kerrighed que se propõe a realizar a migração e comunicação de threads entre dois ou mais computadores. Temos duas técnicas de comunicação interprocessos ou inter-threads11. utilizando o barramento do computador e os componentes do processador para realizar essa tarefa. precisamos ter em mente que na maioria dos casos de computação distribuída teremos processos realizando a comunicação entre computadores distintos. Programas com múltiplas threads tendem a ser menores e de mais fácil entendimento devido ao controle de fluxo simplificado. RPC (Remote Procedure Call) e MPI (Message Passing Interface) Quando falamos em processamento distribuído. a primeira conhecida como Passagem de Mensagem (Message Passing) adotada para uso em sistemas de distribuídos no final da década de 70 e a Chamada Remota de Procedimento (Remote Procedure Call) sendo utilizada inicialmente em meados da década de 80.Por sua característica de paralelismo a implementação de threads possibilita a melhoria de desempenho nos sistemas. não possuindo a capacidade de responder diretamente a comandos executados num computador local por um computador remoto. 11 Apesar do termo inter-thread ser utilizado quando abordamos a comunicação interprocessos. A maioria dos servidores demanda um alto uso de E/S. Existem atualmente passagens de mensagem estruturadas que são bidirecionais. 88 . faz-se necessário uma exposição sobre o meio pelo qual as threads ou mesmo os processos se comunicam nesse tipo de ambiente. A Passagem de Mensagem é originalmente uma troca de mensagem unidirecional entre processos sendo visíveis ao programador. Enquanto sistemas monoprocessados utilizam funções como pipeline ou fork para promover a comunicação e a passagem de parâmetros entre processos ou threads. processos esses que manipularão as threads localmente. os sistemas distribuídos utilizam as redes como meio de comunicação entre os processos.

uma mensagem é uma coleção de objetos de dados consistindo de um cabeçalho de tamanho fixo e um campo de payload de tamanho variável ou fixo. Uma das portas TCP e UDP utilizadas pelo sistema de passagem de mensagem é a 3827. O tipo associado à mensagem provê uma informação estrutural sobre como a mensagem deve ser identificada. dentre outras atividades. Uma mensagem pode ser de qualquer tamanho e pode conter dados ou ponteiros para dados fora da porção contígua da mensagem. órgão responsável pelo controle e registro das portas TCP e UDP a nível mundial. acima do range das portas well-known. A passagem de mensagens utiliza primitivas send e receive como mecanismos básicos para sua operação. os quais podem ser gerenciados por um processo e entregues a seu destino. Segue um diagrama no tempo que descreve a execução dessas primitivas: Figura 7 89 . conhecidas como registradas (registered) na nomenclatura do IANA (Internet Assigned Numbers Authority).Nesse contexto.

As primitivas não confiáveis utilizariam conexões UDP e as confiáveis conexões TCP. 90 . Esses mecanismos que determinam as primitivas confiáveis e não confiáveis estão relacionados com o protocolo de rede TCP-IP.Podemos ter várias alternativas em virtude da semântica utilizada para as primitivas do modelo de Passagem de Mensagens: Portas de comunicação diretas ou indiretas. Falando de Passagem de Mensagem com ou sem buffer. Formas estruturadas de Passagem de Mensagem baseada em primitivas. Primitivas não confiáveis não utilizam esse dispositivo. caso a primitiva receive não tiver sido ainda executada no destinatário quando o mesmo receber uma mensagem. ao passo que primitivas as confiáveis garantem a entrega da mensagem. Primitivas confiáveis e não confiáveis. quando falamos de portas de comunicação direta estamos falando em identificarmos diretamente o destinatário da mensagem ou a comunicação indireta que seria utilizar uma porta genérica para a qual a mensagem é enviada. Primitivas confiáveis ou não confiáveis. provida por um fluxo bidirecional de informações. Primitivas com ou sem buffers. seria a alternativa de buferizar ou não a mensagem. diz respeito ao uso ou não de dispositivos de verificação de recebimento e retransmissão da mensagem caso a mesma tenha sido perdida. sendo colocada em buffer e utilizada pelo processo que teria a necessidade da mesma. Formas estruturadas de Passagem de Mensagem são alcançadas pela distinção de requisições e respostas. Primitivas blocking ou Non-blocking. que é utilizado usualmente na comunicação entre os computadores em sistemas distribuídos. Abordando de modo sucinto essas variações de implementação de Passagem de Mensagem. Os conceitos de primitivas blocking ou síncronas e non-blocking ou assíncronas já foram contemplados anteriormente.

da biblioteca de RPC. Do ponto de vista do programador não há nada de especial nessa chamada de procedimento. que é uma das principais vantagens dessa técnica de comunicação: o programador não precisa saber se o procedimento chamado está sendo executado num computador remoto ou local. Essa abordagem é muito similar aos mecanismos well-known e wellunderstood referidos como chamadas de procedimento também conhecidas como LPC (Local Procedure Call). a SUN utiliza as portas UDP e TCP 111 e a Encore as portas TCP e UDP 121. uma rotina de leitura de uma determinada biblioteca (biblioteca da RPC) é inserida trivialmente no programa.A RPC (Remote Procedure Call) é baseada no conceito fundamental de programação conhecido como chamada de procedimento. Nesse caso. Esse procedimento. A passagem da chamada é invisível ao programador. 91 . basta inserir os parâmetros numa pilha (registradores) e executá-los. requerendo que o protocolo de transporte de rede suporte à transmissão dos argumentos e resultados das chamadas. entrando em blocking até ter de volta uma resposta. chamada client stub. primeiro coloca os parâmetros em registradores e depois assume o controle do kernel. Em termos de TCP-IP cada fabricante e desenvolvedor estabeleceu portas TCP e UDP para suas versões do RPC. Entretanto. Já no servidor o sistema operacional repassa a mensagem que recebeu para um server stub. ao invés de colocar os parâmetros num registrador. a rotina de leitura é um procedimento remoto o qual será executado no servidor do outro lado da comunicação. ela os empacota numa mensagem e executa a primitiva de envio. A conceituação mais geral do termo RPC seria um nível de linguagem de chamada num computador local ser automaticamente executada no mesmo nível de linguagem num computador remoto. ela também assume o controle do kernel. Isso implica que a RPC deve ser transparente. a qual é ligada ao servidor. o objetivo de uma “Chamada Remota de Procedimento” é permitir programas distribuídos serem escritos no mesmo estilo dos programas convencionais para sistemas computacionais centralizados. tendo como resultado a execução de uma chamada de procedimento de leitura. quando executado. Num sistema que suporta RPC. Na sequência. ela chama a primitiva de recepção. por exemplo. Quando executada. outra chamada de procedimento. por exemplo. a qual faz que o sistema operacional os envie para o servidor. A ideia da RPC é muito simples e é baseada no modelo onde o cliente envia uma requisição e então entra em estado de blocking até o servidor remoto enviar uma resposta. é inserida no programa. Num sistema que suporta uma chamada de procedimento convencional. Assim.

O stub vai para o início do loop para executar a primitiva de recepção. os resultados extraídos e copiados no sistema do cliente na forma convencional. os parâmetros e o endereço de retorno são colocados numa pilha. como resultado da execução da primitiva de recepção. Assim.O stub entra em blocking waiting para mensagens. A mensagem é desempacotada. o server stub. e o servidor não vê que a chamada original foi criada num cliente remoto. o processo do cliente obtém os dados disponíveis. O servidor executa a chamada de procedimento e retorna os resultados para um solicitante virtual. e entra em blocking waiting para a próxima mensagem. O stub empacota os resultados numa mensagem. executando uma primitiva de envio para retornar os resultados. Figura 8 92 . O cliente desconhece que o procedimento foi realizado remotamente. A mensagem de resposta do servidor ao chegar ao cliente é copiada no buffer do procedimento client stub. Como resultado da chamada de leitura. Os parâmetros são desempacotados da mensagem recebida e um procedimento é chamado na forma convencional.

não sendo apropriada para modelos cliente-servidor que possuem uma característica intrínseca de requisição-resposta. Os processos acessam a DSM.Apesar de o foco nosso trabalho ser em clusters baseados em Kerrighed e o mesmo não utilizar RPC (Remote Procedure Call) para realizar a execução e migração de processos. há sistemas subjacentes que garantem de modo transparente que as mudanças realizadas numa DSM sejam atualizadas em todos os computadores que compõe a mesma. Memória Compartilhada Distribuída: A DSM (Distributed Shared Memory) é uma abstração para compartilhar dados entre computadores que não utilizam uma mesma memória física. que uma técnica de compartilhar as memórias de computadores distintos de modo que elas se comportem como uma memória convencional utilizada no monoprocessamento. entendemos que o conhecimento dessa técnica essencial do processamento distribuído irá nos ajudar a compreender melhor a técnica utilizada pelo Kerrighed para esse mesmo fim. Segue uma representação de uma memória compartilhada distribuída: Figura 9 A DSM poupa o uso de Passagem de Mensagens na programação de sistemas distribuídos em muitas situações. lendo e atualizando o que parece ser para eles uma memória convencional dentro do espaço de memória reservado para os mesmos. 93 . Gerenciamento de Memória: Existem dois principais paradigmas no processamento distribuídos o primeiro é a execução de remota de processos seja através de MPI seja através de RPC e o segundo paradigma seria o compartilhamento de memória. mas de fato.

estrutura é a forma abstrata em que a DSM apresenta-se para as aplicações. um endereçamento de memória baseado. Estruturação através de tipo de dado: Nesse método a memória compartilhada é estruturada ou como uma coleção de objetos ou como uma coleção de variáveis de uma linguagem. isto é. Devido a sua característica de persistência a DSM possui mais flexibilidade no concerne execução operações no tempo. sendo apenas um array linear de palavras. não havendo a necessidade de uma transposição das mesmas. na segunda as variáveis são acessadas por ambos os computadores. Em termos de eficiência sistemas baseados em DSM podem ser tão eficientes como os desenvolvidos com passagem de mensagem. mas no conteúdo do que nomes ou endereços. Estruturação como banco de dados: Nesse caso a memória é estruturada como um banco de dados. no caso da DSM sincronização é assegurada através de desenvolvimento convencional em memória compartilhada tais como os semáforos. 94 . sendo ordenada como uma memória associativa. a mesma é garantida através de primitivas que utilizam de técnicas como a implementação de lock server. diferentemente da passagem de mensagens em que a troca de dados precisa ser imediata devido ao processo de blocking utilizado nessa técnica. enviadas pela rede e reorganizadas no lado que as recebe. um processo pode armazenar dados em certo espaço de memória que outro poderá acessar num período tempo à frente. por exemplo. Seguem algumas abordagens mais comuns de estrutura em DSM: Sem Estruturação: A maioria dos sistemas de DSM não estrutura seu espaço compartilhado de memória. Em termos de sincronização enquanto no modelo de passagem de mensagens. enquanto na primeira as variáveis precisam ser estabelecidas num lado da comunicação. pelo menos quando falamos numa quantidade pequena de computadores. Existem alguns aspectos da implementação de DSM que devem ser considerados: Estrutura: Nesse contexto.Comparando o uso de Passagem de Mensagens com DSM.

Esses dispositivos são aplicados através de passagem de mensagens. uma mensagem multicast é enviada para todos os processos que possuem uma cópia desse item. Assim o desafio seria manter essas informações coerentes e idênticas em todos os nós que compõe o sistema distribuído. invalidando a mesma. 95 . Consistência: DSM é um sistema de replicação de itens de dados compartilhados. que é o modelo de consistência sequencial. é enviada uma réplica para todos os outros computadores que compõe o sistema através de multicast (comunicação TCP-IP de um para muitos. Quando um processo que está compartilhando um item com outros. A ideia desse modelo é relativamente simples. Essa seria a semântica mais intuitiva para lidar com esse tipo de necessidade de coerência de dados. qualquer processo que tenta acessar um item que está sendo atualizado é bloqueado. onde um item pode ser acessado como somente para leitura por um ou mais processos ou pode ser lido e escrito apenas por um único processo. Além disso. tenta escrever no mesmo. organizada em grupos). recebendo uma confirmação dessa operação antes da escrita ser realizada. Nesse sistema cópias desses itens compartilhados podem estar simultaneamente disponíveis nas memórias principais de vários computadores.Sincronização: Como nos sistemas convencionais de memória compartilhada a sincronização também é necessária em DSM. O segundo. Abordamos até agora técnicas de replicação de atualizações em DSM visando evitar a inconsistência das informações na memória compartilhada existente em cada nó de um sistema distribuído. O primeiro que quando as atualizações são feitas localmente por um processo. Veremos agora o principal modelo de consistência para garantir essa condição. utilizando os controles usuais como lock e semáforos. provocando assim a atualização da memória principal dos mesmos. não importa a ordem em que as operações de leitura e escrita são consideradas conquanto que seja a mesma para todos os processos. Para manutenção da consistência da DSM temos dois modelos principais de propagação de atualização ou replicação: write-update e write-invalidate. pois todos os processos que compartilham um dado espaço de memória sempre veem exatamente o mesmo conteúdo armazenado nele. Uma memória consistentemente sequencial provê uma semântica de uma “cópia/ a mesma cópia”.

onde um processo do cliente requisita localmente uma conexão com um processo de um servidor remoto. Figura 10 Criar um socket é muito semelhante a abrir um arquivo. Nesse caso. Um programa pode ler e escrever dados de ou para um socket utilizando uma variável integer fd (file descriptor) da mesma forma que realizaria um processo de E/S para um arquivo. A figura abaixo descreve o uso do mesmo num sistema cliente-servidor em ambiente UNIX. de modo a poupar trabalho em desenvolvimento das funcionalidades realizadas por essa aplicação. possibilita o acesso aos dispositivos de E/S em computadores remotos. O modelo de sistemas distribuídos que mais utiliza a API de sockets é o de cliente/servidor. 96 . seja através de uma biblioteca. Uma API (Application Programming Interface) é um conjunto de rotinas e padrões de uma determinada aplicação que são utilizados pelos sistemas e programas. Como o cliente já criou também um socket com o qual requisita a conexão com servidor.Dispositivos de Entrada/Saída: A forma mais usual de manipulação de dispositivos de entrada/saída em sistemas distribuídos seria através de sockets. o mesmo aceitará a requisição e estabelecerá a conexão entre o servidor e o cliente. Primeiro o servidor cria um socket e então “escuta” a requisição do cliente. uma conexão através de socket entre dois processo é como um pipe bidirecional. a API de sockets seja como integrante do sistema operacional. A diferença é que os dados são escritos por esse processo são enviados diretamente para um buffer do processo que tem o socket do outro lado da comunicação. Um socket é apenas uma abstração de E/S. Assim.

Esse modelo em camadas é designado para suportar as seguintes propriedades: Transparência: A comunicação entre dois processos não deve depender dos processos estarem ou não no mesmo computador. isso significa que sistemas de arquivos distribuídos devem prover uma transparência da localização de arquivos. Para atingir esse objetivo um sistema de arquivo distribuído usualmente utiliza o modelo cliente-servidor.Modelo do Socket O modelo do socket consiste em 3 partes: a camada de socket. Esses dois servidores podem ser implantados como um único. Arquivos: Um sistema distribuído de arquivos é um componente chave para qualquer sistema de computação distribuído. Esse sistema deve armazenar programas e dados. A principal função de um sistema de arquivos distribuído é criar um sistema arquivos comum que pode ser compartilhado por clientes sendo executados em computadores autônomos num sistema de computação distribuída. fazendo-os disponíveis quando necessário. Eficiência: A aplicabilidade de qualquer comunicação interprocessos é limitada pelo seu desempenho. podem acessar os arquivos sem saber em que computador os mesmos estão armazenados. a camada de protocolo e a camada de dispositivo. Isso significa que usuários. Compatibilidade: Processos já existentes que leem da entrada padrão de um arquivo e escrevem na saída padrão deve ser utilizável num ambiente distribuído sem mudanças. 97 . Tendo em vista que esses arquivos podem estar armazenados em qualquer parte do sistema distribuído. independente de sua localização física. que são implementados por um servidor de arquivo e um servidor de diretório distribuídos entre os nós da rede. Ele tipicamente provê dois tipos de serviços: serviço de arquivo e serviço de diretório.

seriam as informações descrevendo as características dos arquivos. Como o PVFS é instalado em nível de usuário. alteração e exclusão de arquivos dos sistemas operacionais convencionais. Compatibilidade com os programas binários existentes. O daemon de E/S controla todas as operações de E/S sem a intervenção do gerenciador. Uma alternativa de armazenagem de metadados. eles são armazenados localmente em cada nó de E/S. seria armazenar esses metadados num sistema arquivo NFS (Network File System) sistema de armazenamento distribuído de arquivos tradicional para sistemas Unix e Linux. O daemon de gerenciamento checa a permissão para as operações de criação. possuindo as seguintes características principais: Um consistente controle de nomes. não são necessárias alterações no núcleo do sistema operacional. Ele utiliza o TCP-IP para transmitir os dados sem dependência de passagem de mensagens. Os dados dos arquivos são distribuídos entre os nós de E/S. os processos de E/S que são executados em todos os nós que executam E/S e a biblioteca de aplicação através da qual as aplicações se comunicam com os processos do PVFS. A principal meta do PVFS é prover um acesso de alto desempenho a arquivos em aplicações de natureza paralela. abertura. fechamento e remoção de arquivos. O PVFS é implementado em nível de usuário. O PVFS consiste de três elementos: o processo (daemon) de gerenciamento que é executado num único nó. O PVFS oferece suporte para os comandos de acesso. Capacidade de distribuir dados entre os nós do sistema.O sistema de arquivos distribuído mais utilizado em sistemas distribuídos é o PVFS (Parallel Virtual File System). 98 . Em termos de arquivos de dados. possuindo um único identificador para cada um dos arquivos como nos sistemas convencionais. que no contexto de sistemas de arquivos paralelos.

&myrank ). 20. MPI_COMM_WORLD.h" int main( int argc. MPI_COMM_WORLD). there"). if (myrank == 0) /* código para o processo zero */ { strcpy(message. strlen(message)+1. 99. int myrank. MPI_CHAR. } else if (myrank == 1) /* código para o processo 1 */ { MPI_Recv(message. 99. MPI_CHAR. MPI_Init( &argc. 0. Para consolidar os conceitos apresentaremos uma implementação simples dos mesmos em código: Passagem de Mensagem (MPI): #include "mpi.Chamadas de Sistema (System Calls) e Comunicação Interprocessos: Ao abordar processos e threads já vimos o meio pelo qual os sistemas distribuídos realizam chamadas de sistema. char **argv ) { char message[20]."Hello. 1. MPI_Comm_rank( MPI_COMM_WORLD. 99 . MPI_Status status. &status). &argv ). MPI_Send(message. seja através de Passagem de Mensagem seja através de RPC que são responsáveis no contexto de processamento distribuído pela comunicação entre os processos.

Em adição. message). o buffer de envio consiste de um armazenamento contendo a variável “message” na memória do processo zero. O processo um (myrank=1) recebe essa mensagem com a operação de recepção MPI_RECV.printf("received :%s:\n". o tamanho e o tipo do buffer de envio são especificados pelos primeiros três parâmetros da operação de envio. A localização. } Nesse exemplo. O último parâmetro é usado para informação de retorno sobre a mensagem recebida. o tamanho e o tipo do buffer de recepção. especificam o envelope para a mensagem enviada. Os próximos três parâmetros são utilizados para selecionar a mensagem entrante. A operação especifica um buffer de envio na memória do remetente da mensagem do qual os dados da mensagem são retirados. A mensagem enviada ocupará 13 caracteres dessa variável. a operação de envio associa um envelope à mensagem. Os primeiros três parâmetros da operação de recepção são usados para especificar a localização. Esse envelope especifica o destino da mensagem e contém informação que pode ser utilizada para a operação de recepção conseguir selecionar uma mensagem em particular. o processo zero (myrank = 0) envia uma mensagem para processar a operação de envio MPI_SEND. Nesse exemplo. Os últimos três parâmetros da operação de envio juntamente com o rank do remetente. o buffer de recepção consiste de um armazenamento contendo a string “message” na memória do processo um. A mensagem a ser recebida é selecionada de acordo com o valor do seu envelope e os dados da mensagem são armazenados no buffer de recepção. 100 . } MPI_Finalize(). No exemplo acima.

cpp #include <iostream> // Função futura do Servidor. void Output(const char* szOutput) { std::count << szOutput << std::endl. } int main() { // Chamada futura do cliente Output ("Hello Lonely World!"). Podemos comparar a IDL como um cabeçalho de um programa em C com mais funcionalidades: 101 .RPC: Segue uma aplicação standalone que será convertida num RPC (Esse exemplo de RPC é desenvolvido em ambiente Windows): // Arquivo Standalone. } Agora temos o código para a geração do IDL (Interface Definition Language) que é uma linguagem para definição de interfaces.

// Essa é a versão 1. version(1.exe” que traduzirá o IDL para um client stub e um server stub que serão compilados posteriormente por um compilador C.0).idl [ // Um identificador único que distingue essa // interface das outras. string] const char* szOutput). uuid(00000001-EAF3-4A7A-A0F2-BCE4C30DA77E). como por exemplo. implicit_handle(handle_t hExample1Binding) ] interface Example1 // A Interface é chamada Example1 { // Uma função que toma uma string terminada em zero.// Arquivo Example1. } Para usar o IDL numa aplicação nós precisamos processá-lo através de programas.0 dessa interface. 102 . void Output( [in. // Essa interface será usada como um suporte para // ligação implícita chamada hExample1Binding. o “midl.

Figura 11 O próximo passo seria gerar os arquivos e colocá-los em uso na aplicação de servidor.h" // Função de Servidor. } int main() { RPC_STATUS status. // Uso do protocolo TCP/IP 103 . void Output(const char* szOutput) { std::count << szOutput << std::endl. status = RpcServerUseProtseqEp( reinterpret_cast<unsigned char*>("ncacn_ip_tcp"). // Arquivo Example1Server. // Usa o protocolo combinado com o “endpoint” para receber // remote procedure calls (RPC).cpp #include <iostream> #include "Example1.

NULL). // Número //máximo de threads recomendado. NULL). FALSE). NULL.RPC_C_PROTSEQ_MAX_REQS_DEFAULT. 104 . // Sem segurança. // Usa o vetor “entry –point” gerado pelo MIDL. // Número mínimo de threads recomendado. // Interface to register. reinterpret_cast<unsigned char*>("4747"). // Registra a interface do Example1. // Começa a ouvir por RPC’s em todas as interfaces registradas // Essa chamada não será retornada até que o // RpcMgmtStopServerListening seja chamado. // Fila de tamanho do backlog para TCP/IP. // Usa o vetor “entry –point” gerado pelo MIDL. if (status) exit(status). if (status) exit(status). // Porta TCP utilizada. status = RpcServerListen( 1. if (status) exit(status). RPC_C_LISTEN_MAX_CALLS_DEFAULT. status = RpcServerRegisterIf( Example1_v1_0_s_ifspec. // Passa a efetivamente a ouvir por RPC’s nesse momento.

} // Função de alocação de Memória para o RPC. void __RPC_USER midl_user_free(void* p) { free(p).h" int main() { RPC_STATUS status. } // Memory deallocation function for RPC. Existem alguns códigos de inicialização para registrar a interface. } Esse código apesar de diferente da aplicação standalone. // O “runtime”usa essas duas funções para alocar/liberar // a memória suficiente para passar a string para o servidor.cpp #include <iostream> #include "Example1. possui significativa semelhança a um processo sendo executado num mesmo computador. mas a função de saída permanece a mesma. void* __RPC_USER midl_user_allocate(size_t size) { return malloc(size). 105 . Segue a aplicação cliente que conectará com o servidor: // Arquivo Example1Client.

// Valida o formato da string manipulação de ligação e a converte // para uma manipulação de ligação. // O Protocolo depende da opção de rede utilizada. reinterpret_cast<unsigned char*>("localhost"). // Essa função nada mais é do que um “printf”. status = RpcBindingFromStringBinding( szStringBinding. status = RpcStringBindingCompose( NULL. &hExample1Binding). // Uso do protocolo // TCP-IP. // UUID to bind to. 106 .unsigned char* szStringBinding = NULL. // A conexão não está ainda estabelecida. // A string de ligação a ser validade. // Uso de endereço IP reinterpret_cast<unsigned char*>("4747"). // Cria-se uma “string” de manipulação de ligação. reinterpret_cast<unsigned char*>("ncacn_ip_tcp"). // Uso da porta TCP. NULL. // A conexão ainda não está estabelecida. // Coloca o resultado numa manipulação // implícita de ligação definida no arquivo IDL. if (status) exit(status). if (status) exit(status). &szStringBinding). // String de ligação de saída.

// A conexão é realizada nesse momento. Output("Hello RPC World!"). // Libera a manipulação implícita de ligação definida no // arquivo IDL.RpcTryExcept { // Chama a função RPC. A manipulação de ligação hExample1Binding // é usada implicitamente. if (status) exit(status). } RpcEndExcept // Libera a memória alocada pela string. // String a ser liberada. if (status) 107 . // Libera os recursos de manipulação de ligação e desconecta-se do servidor. status = RpcBindingFree( &hExample1Binding). status = RpcStringFree( &szStringBinding). } RpcExcept(1) { std::cerr << "Runtime reported exception " << RpcExceptionCode() << std::endl.

108 . void* __RPC_USER midl_user_allocate(size_t size) { return malloc(size). executando as mesmas. primeiro necessita-se processar o arquivo IDL para obter-se o client stub. como uma implementação de cliente e servidor.exit(status). // O “runtime” usa essas duas funções para alocação/liberação // de memória suficiente para passar a string para o servidor. o server stub e o arquivo comum de cabeçalho. O client stub e o server stub são compilados. } Resumindo. void __RPC_USER midl_user_free(void* p) { free(p). } // Função de liberação da memória para o RPC. Faz-se o linkedit das duas aplicações. } // Função de alocação de memória para o RPC.

Segue uma especificação básica do XDR: program NOMEDOPROGRAMA { version NOMEDAVERSAO { TIPO NOMEDOPROCEDIMENTO (TIPO ARGUMENTO) = X. 109 . no ambiente Linux utiliza-se o padrão XDR (External Data Representation Standard) definido na RFC 1832. A padronização do formato dos dados que no ambiente Windows é realizada através do código IDL. TIPO = NOME. } = 123456789. } = Y. As palavras “program” e “version” não podem ser usadas para identificar os programas e procedimentos.Figura 12 Tratando-se de plataforma Linux existem algumas variações de implementação. O objetivo dessa linguagem é garantir a portabilidade do RPC em arquiteturas diversas.

Por convenção os nomes de programa. Seguido da palavra “version” deverá constar o nome da versão de um ou mais procedimentos. ARGUMENTO é o nome do argumento que o procedimento irá receber. float. TIPO é um tipo de dado que um procedimento poderá retornar ou receber como argumento. bolean. string. enum. 110 .Seguido da palavra “program” deverá conter o nome do programa. char. Y é um número inteiro positivo que identifica o número da versão do conjunto de procedimentos. que irá agrupar uma ou mais versões de um ou mais procedimentos. void. X é um número inteiro positivo que identifica o número de um procedimento. O nome de uma versão não pode ocorrer mais de uma vez no mesmo escopo de definição de um programa. Poderá ser: int. versão e procedimento deverão ser escritos em letras maiúsculas. O nome de um procedimento não pode ocorrer mais de uma vez numa mesma versão. Os identificadores dos programas ficam no mesmo espaço de endereçamento das definições dos tipos de dados e constantes utilizadas. Ele deverá ser de um TIPO específico. double e structure.

/VERSÃO ORIGINAL EM PRODUÇÃO Version PING_VERSAOORIGINAL { 111 . } = 2.com definido pelo usuário transiente reservado reservado reservado reservado reservado O primeiro grupo de números é administrado pela SUN MICROSYSTEMS e padronizado em todos os sistemas. O terceiro grupo é utilizado pelas aplicações que criam números dinamicamente. Este número deverá ser escrito na forma hexadecimal. Se uma aplicação RPC desenvolvida for de interesse geral. int PING_PROCEDIMENTO_BACK(int NUM) = 1. de acordo com os ranges abaixo: 00000000 – 1fffffff 20000000 – 3ffffff 40000000 – 5fffffff 60000000 – 7fffffff 80000000 – 9fffffff a0000000 – bfffffff c0000000 – dfffffff e0000000 – ffffffff definido pelo rpc@sun. Os demais grupos são reservados para uso futuro. Segue um exemplo simples protocolo utilizando a definição XDR: program PROGRAMAPING { /ÚLTIMA VERSÃO DO PROGRAMA EM TESTE version PING_ULTIMAVERSAO { void PING_PROCEDIMENTO_NULL(void) = 0. O segundo grupo poderá ser usado por alguma aplicação específica.123456789 define o número do programa. poderá requerer um número do primeiro grupo.

o rpcgen gerará os seguintes arquivos: ping. Considerando que salvamos o código acima como ping. Um conjunto de rotinas XDR que traduzem os tipos definidos no arquivo de cabeçalho. Um programa base com as chamadas RPC para o cliente. 112 . Versão 2 para PING_ULTIMAVERSAO e versão 1 para PING_VERSAOORIGINAL.h – Cabeçalho com definições comuns ao servidor e cliente. o protocolo deve ser salvo com a extensão “x”. Por convenção.c – Programa base com as chamadas de RPC para o servidor. Um programa base com as chamadas RPC para os servidores. Esse programa pode ser compilado pelo programa “rpcgen” que está disponível no pacote de compiladores GLIBC. O programa PROGRAMAPING tem como identificação o número 20000001. } = 20000001 Nesse exemplo a definição estabelece duas versões distintas de procedimentos.void PING_PROCEDIMENTO_NULL(void) = 0. A versão PING_ULTIMAVERSAO possui dois procedimentos e a versão PING_VERSAOORIGINAL apenas um.c – Filtros XDR para comunicação entre arquiteturas diferentes. ping_clnt. ping_xdr.x. ping_svc. Como a definição IDL do Windows ele gerará os seguintes códigos em linguagem C: Um arquivo de cabeçalho com as definições comuns ao servidor e cliente. } = 1.c – Programa base com as chamadas de RPC para o cliente.

113 . Temos. Podemos ilustrar messages races através do diagrama abaixo. O lado não pontiagudo da seta representa o envio da mensagem.Dificuldades na manipulação de processos num ambiente de processamento distribuído Race Message Considerando um ambiente utilizando DSM (Distributed Shared Memory) podemos dizer que os desafios decorrentes de uma corrida (race) de processos são muito semelhantes aos enfrentados na computação monoprocessada. As mensagens trocadas entre os processos são representadas pelas flechas. Considere três processos P1. pois essa condição está relacionada ao compartilhamento de memória. O lado pontiagudo representa o recebimento da mensagem. há outro tipo de race que ocorre em sistemas distribuídos que utilizam passagem de mensagem. Evento a: P1 envia Mensagem 1 para P2 Evento b: P2 recebe a mensagem Evento c: P3 envia Mensagem 2 para P2 Evento d: P2 recebe a mensagem No diagrama abaixo as linhas verticais representam processos assíncronos. quando muitas requisições conflitantes de clientes competem para acessar o mesmo servidor. porém. P2 e P3.

dependendo como o mesmo é tratado. Basicamente esses sistemas executam rotinas de troca de mensagem repetidamente para verificar se os resultados são os mesmos. A severidade da corrida. a Mensagem 1 pode ter algum atraso.P1 P2 P3 a Mensagem 1 Mensagem 2 b c d Figura 13 Devido a não previsibilidade em certos escalonamentos de processos e atrasos em mensagens. Uma message race pode causar que um sistema tome um caminho de execução diferente. Esse não determinismo causa um problema. desse modo a Mensagem 2 pode ser recebida primeiro. Caso os resultados sejam diferentes temos um indício de uma race condition crítica. isto é. ferramentas de testes e monitoramento que verificam a ocorrência desse tipo de evento. Uma corrida benigna não causa efeito externo nos resultados do sistema. 114 . Uma dessas ferramentas é a TMT (Testing and Monitoring Tool) para sistemas distribuídos desenvolvida pela Siemens AG da Alemanha. a ordem em que as mesmas são recebidas é incerta. Seguem algumas características de uma message race: O efeito sobre o controle de fluxo do sistema. Por exemplo. mesmo executando o sistema com a mesma entrada não é garantida a reprodução da execução original. Uma corrida crítica afeta o resultado do sistema. Uma abordagem para detectar e minimizar os efeitos de race message é de natureza preventiva. antes que o sistema distribuído seja liberado para operação.

2007) desenvolvido por pesquisadores das Universidades de Chonnam e Gyeongsang.Temos também o MPIRace-Check (PARK. A indiferença à ocorrência de deadlocks é popular tanto em sistemas monoprocessados como em sistemas distribuídos. um banco de dados. Evitação: Evita os deadlocks por alocar os recursos com cuidado. por serem mais difíceis de serem evitados. A prevenção de deadlocks é possível devido à existência de transações atômicas. a técnica mais explorada na prática seria a detecção. A técnica de detecção e recuperação é popular porque a prevenção e a evitação são de difícil implementação. 115 . Deadlocks em Sistemas Distribuídos Deadlocks em sistemas distribuídos são similares a deadlocks em sistemas monoprocessados. devido aos dados estarem espalhados entre vários processos e computadores. As quatro principais estratégias para manipular dealocks em sistemas distribuídos são: Indiferença: Ignora-se o problema de deadlock. Prevenção: Torna estatisticamente os deadlocks impossíveis em termos estruturais. detectados ou de terem uma prevenção efetiva. sendo usualmente de solução mais onerosa. muitas vezes deixando a atividade de manipular os deadlocks para as próprias aplicações como. por exemplo. tendo como principal recurso as transações atômicas. os detecta. que é técnica de voltar as transações para suas condições iniciais caso ocorra alguma indisponibilidade durante a execução das mesmas. Como a prevenção e evitação são de difícil implementação. Detecção: Permite a ocorrência de deadlocks. A evitação de deadlocks é usada raramente pela dificuldade de saber-se “a priori” o quanto de recurso cada processo precisará numa dada transação. tentando recuperar os processos.

estabelecendo que um nó representa um processo. Em termos de algoritmos que tratam as abordagens para resolução do problema de deadlock. havendo um sistema de troca de mensagens para verificar a existência de círculos e consequentemente deadlocks. tendo cada algoritmo uma abordagem e estratégias diferentes ao utilizarem essas informações. cancelando (kill) um dos processos para interromper o deadlock. Para prevenção temos os algoritmos Wait-die e Wound-wait. 1983) que permite que um processo possa esperar por mais de um recurso ao mesmo momento.A detecção de deadlocks utiliza uma técnica conhecida como WFG (Wait-For-Graph). um arco representa um processo que está esperando por outro que mantém um recurso que ele deseja e um círculo que representa um deadlock. onde os processos são modelados em termos de grafos. Para a evitação temos o algoritmo do “banqueiro” desenvolvido por Edsger Dijkstra (DIJKSTRA. uma das técnicas utilizada seria a detecção centralizada de deadlocks que de certa forma segue a mesma linha de raciocínio utilizada nos sistemas monoprocessados. Nessa técnica cada computador mantém um grafo de recursos próprios e o coordenador mantém um grafo de recursos para todo o sistema. Para que o coordenador mantenha um grafo de recursos do sistema global. 116 . um sistema de mensagens é utilizado. temos os algoritmos de detenção de Chandy-Misra-Haas (CHANDY. 1977) que trabalha com uma previsão e controle dos recursos dos processos manipulados pelo mesmo. que trabalham com timestamp (tempo em que o processo começa a utilizar o recurso). O coordenador detecta um círculo. Quando tratamos de detecção de deadlocks em sistemas distribuídos.

Um filósofo sedento precisa de garrafas cheias para ele saciar a sua sede. que já abordamos nesse trabalho. 13 Jayadev Misra detém a cadeira Schlumberger Centennial em Ciência da Computação. Uma implementação distribuída de um grafo de precedência acíclica. Um filósofo tranquilo pode tornar-se sedento. O processo favorecido deve ter alguma propriedade que o distinga dos outros. trabalha com a questão da sincronização. retornando ao estado de “filósofo tranquilo” após um tempo finito. dentre eles o “Jantar dos Filósofos”. Ao manter e tomar todas as garrafas que o filósofo se apropria. 1984). sendo também professor dessa disciplina. Ele foi o Chefe Executivo do departamento por duas vezes e também professor na Caltech desde 1989. Uma simples regra de resolução de conflito associada a um grafo acíclico garante uma resolução justa para todas as situações dessa natureza segundo os autores. M. a propriedade que distingue o processo escolhido não é sempre a mesma. Ele pode necessitar de uma quantidade diferente de garrafas em diferentes rodadas de bebida. mantendo-se nesse estado até tomar toda bebida que necessita. Esse problema é uma generalização do problema do “Jantar dos Filósofos” que como vimos. Os lados do triângulo seriam as garrafas de bebida. Chandy12 (CHANDY. Misra13 (MISRA.O Problema do “Drink dos Filósofos” Ao abordar a questão de alocação de recursos em sistemas monoprocessados apresentamos alguns problemas clássicos para abordagem desse aspecto da computação. Um filósofo pode estar em um de três estados: (1) Tranquilo (2) Sedento (3) Bebendo. 1984) e J. 12 Kanianthra Mani Chandy é professor de Ciência da Computação no California Institute of Technology. utiliza a abordagem de favorecer um dos processos em detrimento dos outros numa situação de conflito entre os mesmos. onde a profundidade do processo (a mais longa cadeia de predecessores) seria uma das propriedades distintivas. Temos uma variação desse problema aplicada para computação distribuída conhecida como o “Drink dos Filósofos” em que uma das soluções proposta por K. 117 . Para garantir certa justiça nessa escolha. Um filósofo pode beber somente de garrafas (lados) que formam o seu vértice. localizado nos vértices do grafo G. ele entra num estado de “filósofo bebendo”. podendo garantir a rotatividade da escolha do processo favorecido. Nesse caso. os processos são os filósofos.

O problema é resolvido através de uma solução não probabilística que satisfaça as seguintes condições: Justiça. “q” e “r” teriam como “profundidade” no que se refere a predecessores em relação a “r”. precisamos compreender alguns conceitos de modelos de grafos de conflito.Para entender o problema do “Drink dos Filósofos”. Os vizinhos podem enviar mensagens um para o outro. não havendo uma distinção entre eles. Para garantir a justiça na escolha dos processos que por ventura entrarem em conflito considerando o grafo H. Um filósofo pode estar num estado tranquilo por um período de tempo arbitrário. respectivamente 0. Os recursos. nesse caso. tal como as garrafas. 1 e 2. Com essas informações preliminares podemos agora abordar o problema do “Drink dos Filósofos” com mais propriedade. Esse modelo não considera a precedência dos processos em caso de conflito. As mensagens são entregues num tempo arbitrário. são codificados e transmitidos como mensagens. “p”. q e r) que correspondem a processos. Dois filósofos são vizinhos se e somente se houver um lado entre eles no grafo G. Um sistema distribuído é representado pelo grafo G com uma correspondência um para um entre os vértices (p. 118 . mas finito. Grafo G Figura 14 Grafo H A título de ilustração no caso do grafo H. Nenhum filósofo fica sedento para sempre. uma mudança de quantidade de predecessores dos processos participantes dos conflitos. No modelo H existe uma precedência entre os processos indicada pelas setas. é necessário.

pois as condições de processos simétricos. Entretanto. um estado do sistema certamente possível seria quando todos os filósofos mantém sua garrafa à esquerda. soluções não probabilísticas e concorrência são incompatíveis nesse problema. Filósofos vizinhos podem beber simultaneamente de garrafas diferentes – esse é um modelo de situação para processos de gravação em diferentes arquivos. A solução seria implementar grafo de precedência H utilizando recursos “auxiliares” especiais. Deve-se prevenir o sistema de entrar em estados em que filósofos vizinhos são indistinguíveis. o tamanho da mensagem também é considerado uma ligação. entre qualquer par de filósofos é uma ligação. O problema dos “Filósofos Bebendo” é um paradigma geral para modelar conflitos entre processos. Ligação. um filósofo tranquilo não envia nem recebe um número infinito de mensagens. Não há prioridade ou qualquer outra forma de aquisição parcial externamente especificada entre filósofos e garrafas.Simetria. Em particular. Filósofos vizinhos serão impedidos de beber simultaneamente se eles desejarem beber da mesma garrafa – esse é um modelo de situação conflito para acesso exclusivo para arquivos comum. Além disso. Por exemplo. Se esse estado for proibido. Todos os filósofos obedecem precisamente todas as regras para adquirir ou liberar garrafas. 119 . então os filósofos permanecerão sedentos para sempre porque um algoritmo determinístico não pode escolher entre filósofos indistinguíveis. A solução não nega a possibilidade de beber-se simultaneamente de diferentes garrafas por diferentes filósofos. Parece estarmos num dilema. O Filósofo envia e recebe um número finito de mensagens entre as transições de estado. Se todos os filósofos estiverem bebendo de suas bebidas à esquerda e então requererem as duas garrafas para próxima rodada. considere filósofos organizados num anel e o estado de cada filósofo é de beber de sua garrafa à esquerda – filósofos não possuem uma característica que possa distingui-los. Economia. Concorrência. a qualquer momento. simplesmente para resolver um único problema. Um número de mensagens em trânsito. proibir que um estado que viável viole a condição de Concorrência. estaríamos proibindo um estado viável com o qual estaríamos obtendo algum sucesso.

O grafo é implementado utilizando a mesma abordagem dos “garfos” do problema do Jantar dos Filósofos. Essa mesma abordagem é utilizada na resolução problema dos “Drink dos Filósofos”. Dois processos compartilham um grafo se existe a possibilidade de conflito entre eles. A “profundidade” do processo é sua característica de distinção em relação aos outros. 120 . A regra para resolução do conflito seria: um processo “u” cede num conflito com um processo “v” se e somente se “u” não manter o garfo compartilhado com “v”.O grafo H é sempre acíclico. então a resolução do conflito eventualmente resolverá o conflito em favor de “u”. O algoritmo garante que se os processos “v” e “u” estão em conflito e “u” tiver precedência sobre “v” no grafo de precedência.

por exemplo. tem-se sido encorajado um tipo de programação onde coleções de processos cooperativos usam muitos processadores concorrentemente para realizar tarefas.Escalonamento de processos em sistemas distribuídos As técnicas de escalonamento usadas pelos sistemas operacionais em geral são baseadas em sua grande parte na premissa que os processos são independentes. Assim podemos assumir que os processos seriam criados em grupos e que a comunicação intragrupo seria muito mais frequente que a comunicação intergrupo. Assume-se que as interações entre os processos são mais exceções do que a regra. Figura 15 121 . Em sistemas multiprocessados. Grupo de processos é utilizado mesmo no monoprocessamento. Podemos também considerar que um número significativo de processadores estará disponível para tratar esses grupos de processos e que cada processador utilizará o mecanismo de executar múltiplas instruções num mesmo ciclo de clock conhecido como multiprogamação N-way. no mecanismo de pipeline do Unix/Linux. dentre eles os sistemas distribuídos. Porém tratando-se de sistemas distribuídos a independência dos processos torna-se não válida com o passar do tempo.

A linha 3 é a coleção de todos os processos que são executados no time slot 3 de um dos oito processadores. Existem variações desse modelo visando uma melhoria de desempenho. Esse algoritmo considera os padrões de comunicação interprocessos enquanto estabelece um escalonamento para garantir que todos os membros do grupo sejam executados ao mesmo tempo. Caso. retorna-se para o lado esquerdo da tabela e inicia-se uma nova varredura para um novo grupo de processos.John K Ousterhout14 (OUSTERHOUT. como podemos ver na matriz representada pela Figura 15. para que sejam executados simultaneamente. Ele é também presidente da Electric Cloud. assim por diante. 14 John K. Ele é provavelmente mais conhecido como o criador da linguagem de script Tcl. O escalonamento utiliza o mesmo método de estabelecer-se uma janela que irá mover-se da esquerda para direita até que todos os processos sejam executados. quando isso ocorre. 122 . que seria um escalonamento sequencial sem retornar ao início da sequencia ao final da varredura. tendo todos os processadores executando os processos no slot 0 num período fixo. Obteve Mestrado em Física na Universidade de Yale e doutorado em Ciência da Computação na Universidade Carnegie Mellon. Assim. Dessa forma. para manter a sincronização dos time-slots. podemos separar as linhas da matriz e concatená-las de modo a criar uma única longa linha. O essencial dessa ideia é ter cada processador utilizando um algoritmo de escalonamento round robin. o grupo é deslocado para uma nova janela da esquerda para a direita até encontrar uma sequencia de processadores livres que atendam a necessidade desse grupo. então tendo todos os processadores executando os processos no slot 1. Inc. seria colocar todos num mesmo time slot. Nesse modelo um grupo de processos é colocado nessa tabela contínua. a melhor maneira de utilizar esse algoritmo ao manipular grupo de processos. maximizando os recursos de comunicação interprocessos. por exemplo. Ousterhout é professor e pesquisador do departamento de Ciência da Computação na Universidade de Stanford. a fim de ter cada processo do grupo alocado a um processador. num primeiro momento. 1982) propôs alguns algoritmos para tratar o escalonamento em sistemas distribuídos dentro do conceito que ele chamou coscheduling. isso não for possível. a coluna 4 consiste de todos os processos executados no processador 4. iniciando com o processo do processador número 0. Uma mensagem TCP-IP pode ser utilizada para informar para cada processador quando uma troca de processo ocorre.

Essa designação pode ser estática ou dinâmica. tendo cada nó do sistema distribuído tratando dos processos a ele designado. Problemas de sincronização são especialmente críticos em sistemas distribuídos por comprometerem a troca de mensagens que são o meio de comunicação entre processos nessa modalidade de processamento. o escalonamento em tempo real em sistemas distribuídos é alcançado através de algoritmos heurísticos. Enquanto que a designação estática é permanente. O timeout tem como função principal determinar a falha na execução de uma tarefa após um tempo pré-determinado. Por suas características usualmente complexa. podendo ter diferentes instâncias de uma tarefa alocadas em diferentes nós. Temos visto que escalonamento para sistemas monoprocessados.Escalonamento em sistemas em tempo real em computação distribuída Comparado ao escalonamento em sistemas em tempo real em computação monoprocessada. para fins de reconhecimento da “idade” das mensagens e assim como a ordenação das mesmas. O escalonamento em sistemas distribuídos consiste em dois subproblemas: alocação de tarefas aos processadores e escalonamento de tarefas em processadores individuais. 123 . a dinâmica passa ser semelhante ao escalonamento em ambientes monoprocessados. possui uma complexidade polinomial (Complexidade P). executando tarefas em tempo real. para determinar um sistema ótimo para tarefas em tempo real para sistemas distribuídos necessitamos de resolver problemas de complexidade NP (Nondeterministic Polynomial Time). Depois que as tarefas são alocadas aos diferentes processadores. nos sistemas distribuídos o mesmo é utilizado para timeout e timestamping. O problema de designação de tarefa refere-se como particionar um grupo de tarefas e então designá-las aos processadores. Um aspecto crítico nos sistemas distribuídos em tempo real é a temporização (clock). o escalonamento de tarefas em tempo real em ambiente distribuído é de implementação consideravelmente mais complexa. Além do uso tradicional do clock nos sistemas operacionais. Entretanto. Timestamping é utilizado para informar na própria mensagem o tempo no qual a mesma saiu de sua origem. a dinâmica é variável e as tarefas são designadas aos nós na medida em que surgem.

seus projetos devem partir da premissa que necessitarão considerar como característica principal uma quantidade imensa de dados que precisam ser processados e transmitidos de maneira contínua. as aplicações de áudio manipulam um volume muito menor de dados (portanto. segue uma descrição dos principais protocolos que tratam de comunicação de sistemas multimídia.Aplicações Multimídia em Sistemas Distribuídos Os sistemas multimídia representam uma classe especial de sistemas complexos de computação. muitos modelos de compressão são estabelecidos baseados na percepção humana de sons e imagens para alcançar maiores taxas de compressão). latência. A primeira seria sua fidelidade usualmente dependente da sequencia temporal dos dados. etc. Em contraste. por exemplo. Devido a isso os protocolos de transporte de voz e vídeo utilizam normalmente pacotes UDP. 124 . Fluxos de mídia contínua têm duas propriedades importantes. jitter. particularmente se conhecemos a característica da informação (por exemplo. os requerimentos de QoS variam consideravelmente de uma mídia para outra. aplicações multimídias são sensíveis a variações de tempo e não tanto exigentes à perda de parte das informações. Abordando o aspecto de redes. não requerendo alta largura de banda). como por exemplo. mas tem certa tolerância para certos níveis de jitter e erros de pacotes. Outro aspecto essencial é a qualidade de serviço (QoS) que compreende itens como reserva de banda. porém são mais sensíveis a jitter e taxa de erros. Como tal. Nos sistemas multimídia. Podemos dizer que em contraste a aplicações convencionais. recepção e execução de aplicações multimídias. dando suporte aos processos de transmissão. cumprindo as exigências relativas a sincronização a fim de ter mensagens íntegras recebidas pelo usuário final. Essa propriedade temporal de mídias contínuas impõe requerimentos que faz com que os códigos que manipulam fluxos de mídia necessitem ser escalonados dentro de janelas de tempo aceitáveis. o RTP (Real Time Protocol). fluxos de vídeos requerem uma vazão consistentemente alta. A segunda propriedade seria que eles são normalmente tolerantes à perda de conteúdo da informação.

RTCP (RTP Control Protocol): Protocolo de controle designado para trabalhar em conjunção com o RTP. A identificação da origem permite que no recebimento do pacote a aplicação saiba de onde os mesmos estão vindo. sequenciamento. MPEG1 / MPEG2. Os números de sequencia são utilizados para determinar a ordem correta. O remetente informa tempo quando pacote é processado. Durante uma sessão RTP. pois o UDP não tem apenas essa funcionalidade. os participantes periodicamente trocam pacotes RTCP para transmitir informações sobre a qualidade da entrega dos dados e de participação em sessões. Por exemplo. o qual é protocolo baseado em IP para transmissão de dados e voz.RTP (Real Time Protocol): O transporte de fluxos de mídia nas diversas aplicações. etc. pelo identificador da origem é possível saber quem está entrando na mesma. QoS e reserva de recurso. Ele é um protocolo “leve” sem controle de erro e de fluxo. Utilizando esse identificador. 125 . a aplicação sabe como interpretar e executar os dados do payload. Para garantir sincronismo e a ordenação dos pacotes. dentre outros. O destinatário usa o time stand para reconstruir a temporização original. O RTP não é por si mesmo responsável pelo sincronismo. O identificador de payload especifica o formato do mesmo assim como a codificação e compressão. Timestamping é a uma das mais importantes informações para aplicações em tempo real. essa função é feita no nível de aplicação. o RTP provê dispositivos como timestamping. é na maioria dos casos implementado com RTP. O sequenciamento também é utilizado para detecção de perda de pacotes. Exemplos de especificações seriam PCM. numa áudio-conferência.

a banda requisitada através desse protocolo. Podemos ter múltiplos discos num único computador. O RTSP provê métodos para executar comandos tais como play. utilizando TCP ou UDP. Um exemplo típico de alocação restrita de dados é o acesso aos discos utilizando a técnica round robin. por exemplo. temos a utilização de um sistema com múltiplos discos para armazenagem de objetos de som e vídeo. Ele é um protocolo em nível de aplicação designado para trabalhar com os protocolos de nível mais baixo como RTP e o RSVP (Resource Reservation Protocol).RTSP (Real Time Streaming Protocol): O RTSP é um protocolo de apresentação cliente-servidor para habilitar a entrega controlada de fluxos de multimídia em redes IP. agindo como um controle remoto para servidores de multimídia. PVFS (Parallel Virtual File System). Assim. Dentro da abordagem de sistemas multimídia distribuídos. fast-rewind. A segunda opção seria a mais aplicável aos sistemas multimídia distribuídos que requerem um espaço em disco considerável. A duas abordagens amplamente conhecidas de alocar blocos de objetos multimídia entre controladores de múltiplos discos são: restrita e irrestrita. Assumindo servidores de sistemas multimídia com múltiplos discos. uma aplicação em tempo real pode usar o RSVP para reservar os recursos necessários ao longo de todo o encaminhamento dos pacotes. similar as funcionalidades oferecidas por aparelhos de CD e DVD. especialmente quando estamos tratando de Vídeo on Demand (VoD). a tendência é utilizar múltiplos discos na maioria das aplicações. De fato. os blocos de dados são alocados nos discos de maneira a distribuir a carga de uma execução de um vídeo. O RTSP pode ter um ou vários fluxos de mídia contínuos. 126 . seja para obter uma maior capacidade de armazenagem. fast-forward. pause e stop. igualmente entre os mesmos. RSVP (Resource Reservation Protocol) O RSVP é um protocolo de controle que permite um usuário do recurso multimídia requisitar uma qualidade de serviço fim a fim para o seu fluxo de dados. por exemplo. num dispositivo dedicado a armazenagem (storage) ou discos espalhados numa rede computadores utilizando. seja para prover redundância. Assim a forma de distribuir dos dados em conjunção com as técnicas de escalonamento podem afetar a apresentação contínua e o desempenho dos servidores multimídias.

127 . A desvantagem dessa abordagem seria a latência no início de recuperação dos dados. Devido a harmonia da alocação de dados em round robin e a recuperação periódica de dados baseada em ciclos. a vazão do sistema escala linearmente em função do número de controladores de discos no sistema. Controlada por deadline e alocação round robin. essa abordagem provê a garantia de um serviço determinístico livre de “congelamento” de imagem ou som num objeto multimídia. Essa abordagem maximiza a utilização da largura de banda dos controladores de disco por distribuir a carga da exibição entre os discos igualmente. os sistemas de filmes sob demanda. uma vez que sua recuperação é iniciada. Através do controle dos deadlines para recuperação de blocos. como por exemplo. Com essa abordagem. Assim esse sistema seria mais adequado para aplicação que requer uma vazão alta e poderia tolerar uma latência de início longo. Baseada em ciclos e alocação randômica. essa abordagem pode prover uma latência mais curta para o início da recuperação dos dados do que a abordagem baseada em ciclos e round robin. Abordagem baseada em ciclos e alocação round robin: Muitos estudos investigaram a combinação escalonamento baseado em ciclos e alocação de dados em round robin. Baseados nas técnicas de alocação e escalonamento de dados. Abordagem controlada por deadline e alocação randômica: Não muitos estudos têm investigado a abordagem com o escalonamento utilizando o conceito de deadline e a alocação randômica de dados. A carga do sistema deve ser distribuída entre as controladoras dos discos de modo a prevenir gargalos. Controlada por deadline e alocação randômica. nós podemos classificá-las em quatro abordagens: Baseada em ciclos e alocação round robin. Assim. um bloco é recuperado de cada controladora de disco para exibição num certo período de tempo.Um exemplo de alocação irrestrita de dados seria o acesso randômico aos discos. Essa carga pode intencionalmente atrasar a recuperação de um primeiro bloco de um objeto requisitado sempre que um gargalo surge num disco.

a abordagem de escalonamento controlado por deadline e alocação por round robin devido as suas desvantagens não convém ser considerada como uma alternativa viável. Essa probabilidade pode ser significativa. Com a alocação dinâmica. um gargalo poderia durar por o tempo de exibição do filme. Abordagem controlada por deadline e alocação round robin: De maneira similar. A formação de gargalo numa controladora de disco pode resultar na violação de deadlines estabelecidos nos blocos requisitados. Entretanto. ele ocorrerá repetidamente devido a alocação round robin e recuperação de dados sequencial na execução de objetos multimídia.Dessa forma. Assumindo uma situação de filmes sob demanda. essa abordagem não pode prover a garantia de um serviço determinístico como com a baseada em ciclos e round robin. Primeira. Abordagem baseada em ciclos e alocação randômica: A abordagem de escalonamento cíclico e a alocação de dados randômica pode ser desconsiderada para uma análise mais aprofundada. Segunda. uma vez que um gargalo ocorre num controlador de disco. essa abordagem não pode prover uma latência de início curta como a controlada por deadlines e randômica devido à alocação cíclica. causando congelamento na execução. essa abordagem pode permitir uma variação estatística no número de recuperações de blocos num disco. 128 . no pior dos casos. devido a alocação randômica dos dados. Com ela. O gargalo só acabaria quando um ou mais participantes do mesmo finalizassem a execução. dependendo da carga do sistema. Terceira essa abordagem resulta na baixa utilização da velocidade do disco porque as requisições podem ser distribuídas desigualmente entre os discos que finalizarem um ciclo mais cedo e assim ficarem inativos até que os outros discos terminem seus respectivos ciclos. essa abordagem é mais apropriada para aplicações que requerem uma latência de início curta tal como um sistema de editoração digital. o gargalo é resolvido mais rapidamente devido a carga ser distribuída baseada num padrão aleatório. devido suas desvantagens. um disco poderia receber mais requisições do que os outros. Devido à natureza da alocação dinâmica.

como VoD. A largura de banda necessária para implementar um VoD interativo com tal abordagem seria imensa. O foco dessa análise será aplicação VoD porém os princípios aqui discutidos poderão ser aplicados para outras aplicações de multimídia. com métodos tais como smoothing (utilização de buferização para reduzir as rajadas na transmissão de conteúdos de multimídia). Utilizar um único grande Servidor Centralizado de Sistemas Multimídia para suportar clientes distribuídos resultaria numa alocação ineficiente de recursos e num projeto virtualmente impraticável. 129 . existem pesquisas focadas em várias técnicas para. De fato. foi originalmente motivada por esse problema. staging (utilização de servidores proxy colocados entre os clientes e os servidores de fluxos de multimídia) e negociação de banda.Video on Demand Um sistema de VoD (Video on Demand) pode ser usualmente considerado como um repositório variado de objetos multimídia com um grande de número de usuários dispersos. é esperado prover um serviço para um número significativo de clientes. num desenho distribuído sem compartilhamento de recursos. seja em redes privadas seja na Internet. Das aplicações de multimídia distribuídas. algumas vezes dispersos geograficamente. a ideia de conectar recursos em redes. utilizar um grupo distribuído mas independente de Servidores Centralizados de Sistemas Multimídia locais. por exemplo. para reduzir o requerimento de banda como um todo via agregação ou a multiplexação estatística. Esses objetos devem ser servidos aos clientes sob sua demanda. Por outro lado. também se tem mostrado ineficiente. Geralmente um Servidor de Fluxo de Mídia Distribuído que atua como um VoD é posicionado numa rede com topologia hierárquica. ou reduzir os requerimentos de banda de fluxos individuais de mídia. O real potencial econômico de aplicações de multimídia distribuídas não será alcançado a menos que a efetividade dos custos da solução seja alcançada para servir os usuários dos sistemas multimídia. Os nós são capazes de armazenar um número limitado de objetos multimídia e podem afluir um número finito desses objetos. com os Servidores Centralizados de Multimídia individuais como nós e os enlaces de rede como ligações na hierarquia. Para suportar aplicação de fluxos distribuídos. utilizando. batching (técnica relacionada aos modelos hierárquicos de topologia de sistemas distribuídos de multimídia) e multicasting. isto é.

Temos algumas alternativas de infraestrutura de telecomunicações que podem prover esse tipo de serviço. emulando as características de circuitos dedicados através de garantia da qualidade do serviço por meio de mecanismos estatísticos ou determinísticos. É importante notar que embora atender os clientes localmente resulte numa redução dramática de consumo de banda. por exemplo. redes de comutação de pacotes que suportam serviços específicos como por exemplo o DiffServ do TCP-IP.Com uma solução ortogonal. Na prática. o enorme requerimento de capacidade de armazenamento agregado dos servidores faz a abordagem de não compartilhamento impraticável. é esperado que os links das redes garantam os requerimentos de QoS (Quality of Service) da comunicação de sistemas multimídia. para serem capazes de compartilhar ou intercambiar objetos de sistemas multimídia. Temos atualmente as redes MPLS (Multi-protocol Label Switching) que também já possuem suporte para sistemas multimídias. Esses sistemas têm como uma das principais premissas a topologia hierárquica contemplando servidores e clientes. Quando uma requisição de qualquer objeto chega ao head-end. se o objeto está disponível na armazenagem local o head-end atende o cliente. os clientes são conectados aos headends através de redes de banda larga como xDSL e rede a cabo. como redes de circuitos comutados como o SONET (Synchronous Digital NETwork) que provê conexões físicas e/ou lógicas dedicadas. a menos que os servidores sejam capazes de compartilhar objetos na rede. 130 . algumas pesquisas têm proposto uma distribuição de serviços para gerenciar a dispersão de clientes. chamados head-ends são pontos de acesso para o sistema. Os nós nas “folhas” no sistema hierárquico em árvore. senão a requisição será enviada para os níveis mais altos da hierarquia e eventualmente algum outro nó que tenha armazenado localmente o objeto. empregando um número de Servidores Centralizados de Multimídia para atender clientes localizados em certos pontos e os conectando através de uma infraestrutura de rede de alta velocidade. transmitindo o fluxo multimídia através da topologia hierárquica. com um custo mínimo de transferência de objetos armazenados para aplicações de multimídia distribuída. Sistemas projetados com base na abordagem de compartilhamento dos objetos têm-se mostrado uma solução eficiente. Além da topologia hierárquica. chegando ao head-end e finalmente no próprio cliente. atendendo ao cliente.

131 . eles possuem técnicas de levantamento do perfil dos usuários. provendo uma eficiente utilização de recursos. minimizando assim custos. Supõe-se que esse midleware deva endereçar dois diferentes problemas ortogonais: Alocação de objeto. posicionando réplicas de objetos dentro de uma rede de Servidores de Fluxo de Mídia Distribuído. nó e largura de banda de um link) para a entrega de objetos. selecionando uma réplica apropriada e os recursos do sistema de fluxos de mídia adequadamente (por exemplo. recomendando conteúdos que serão migrados para Servidores de Fluxo de Mídia Distribuído mais próximos de cada usuário. Podemos perceber que os provedores de VoD precisam buscar o equilíbrio entre o posicionamento e capacidade dos Servidores de Fluxo de Mídia Distribuído e a velocidade dos links que conectam esses servidores entre si e entre os usuários finais. decodificação e compressão de vídeos mantendo ainda assim uma boa definição. Sobre a demanda dos clientes em tempo real. Além disso. um Servidor de Fluxo de Mídia Distribuído deve também consistir-se de um componente de middleware para gerenciamento de recursos. Entrega de objetos. Mapeamento estático ou dinâmico de objetos em nós de rede de Servidores de Fluxo de Mídia Distribuído (espaço de armazenamento) para o custo total da comunicação de itens armazenados seja otimizado. Provedores de VoD têm trabalhado em técnicas de codificação.Como apresentado até o momento. Conclusão do Capítulo Encerramos com esse capítulo a apresentação de elementos conceituais nos ajudarão a avaliar e compreender os modelos e tipos de clusters que iremos apresentar nos próximos capítulos desse trabalho.

O projeto do OpenMosix. Flynn é um cientista da computação dos Estados Unidos. concluiu o doutorado pela Universidade de Purdue. 132 . baseada no número de fluxos de dados e de instruções existentes em cada instante que em sua concepção são quatro: 15 Michael J. identificando.” Apesar de respeitarmos a opinião do criador do projeto. verificando o comportamento e medindo o desempenho ao executar os diversos tipos de aplicações nesses ambientes. desde que implementadas de modo adequado. Flynn 15 (FLYNN. corrigindo e melhorando os sistemas como todo. Classificação de Michael J. Propôs a taxonomia de Flynn em 1966. professor emérito da Universidade de Stanford. pelo menos. Usaremos como comparação e contraponto ao cluster Kerrighed. A direção da computação é clara e as desenvolvedoras chaves estão migrando para novas abordagens de virtualização e outros projetos. 1972) das arquiteturas de Computadores Michael Flynn concebeu uma classificação de arquiteturas de computadores através de modelos. o projeto OpenMosix que infelizmente foi encerrado por seu idealizador. Graduou-se em engenharia em 1955 pela Manhattan College e concluiu o mestrado cinco anos mais tarde. no que tange ao conceito de migração de processos tem sido continuado através do projeto “LinuxPMI”. Em 1961. porém sem ter um envolvimento efetivo da comunidade acadêmica e tecnológica. ainda achamos que plataformas como o OpenMosix ainda são viáveis técnica e economicamente. entrando num maior detalhamento quando abordarmos o sistema de cluster Kerrighed que será foco do nosso laboratório. sobretudo identificando os gargalos.Capítulo 2 – Apresentação de Cluster em Linux na Modalidade HPC com ênfase em Kerrighed Considerações iniciais do capítulo Apresentaremos nesse capítulo os principais sistemas de cluster de alto desempenho em Linux na nossa visão. Segue o motivo oficial do encerramento do projeto: “O crescimento do poder e disponibilidade de processadores de multinúcleo de baixo custo está fazendo que rapidamente a clusterização com SSI (Single System Image) diminua sua importância na computação. pela Universidade de Syracuse. uma forma de classificação de arquiteturas de computador de acordo com instrução e fluxo de dado.

onde o computador processa sequencialmente. apresenta uma disponibilidade de 99. Arquitetura MISD (Multiple Instruction Single Data): é o modelo em que os computadores executam várias instruções ao mesmo tempo sobre um único dado. Multiple Data): é o modelo de execução paralela onde cada processador trabalha de maneira independente. computadores usados para efetuar operações aritméticas sobre vetores e matrizes de ponto flutuante. utilizando a variação arquitetura MIMD com memória distribuída. pelo menos.Arquitetura SISD (Single Instruction. Enquanto um servidor de boa qualidade. conhecida como MMX (MultiMedia eXtension) e também nos computadores vetoriais. que nesse caso seria vários computadores com seu próprio processador e memória executando múltiplas instruções com múltiplos dados conectados através de uma rede local. onde uma simples instrução é executada paralelamente utilizando vários dados. Arquitetura MIMD (Multiple Instruction. 133 . Single Data): é o modelo mais simples. Quando algum serviço ou equipamento paralisar. É a arquitetura tradicional de Von Neuman. atualmente.9%. Cluster de Alta Disponibilidade: Como o próprio nome já indica. Essa tecnologia é utilizada em alguns processadores. Não existe um computador real nesse modelo. Tipos de clusters Podemos dividi-los em dois grupos. os outros passam a responder automaticamente. Arquitetura SIMD (Single Instruction Multiple Data): é o modelo que usa o paralelismo de dados. o objetivo é manter o sistema o maior tempo possível na operação sem paradas não programadas. Esse é o modelo utilizado nos clusters de computadores. replicando os serviços e servidores. O próprio Michael Flynn duvidou pudesse existir algum modelo como esse no mundo real. executando uma instrução por vez para cada dado enviado. um sistema de cluster de Alta disponibilidade apresenta 99. ocorrendo múltiplos fluxos de instruções e múltiplos dados.5%. inclusive com redundância de discos rígidos. cluster de Alta Disponibilidade e cluster de Alta Performance de computação.

podendo assim executar aplicações que só seriam suportadas por supercomputadores ou computadores de grande porte. Cluster de Alta Performance de Computação Esse modelo tem como foco desenvolver um sistema que tenha a mesmo poder de computação de um supercomputador. através do agrupamento de computadores numa rede de alta velocidade e softwares que agregam capacidade de memória e processamento desses computadores como se fosse apenas uma máquina.Esses quatro décimos podem parecer não muito significativos à primeira vista. Alguns sistemas de alta disponibilidade em Linux com o código fonte aberto são: LVS (Linux Virtual Server). mas para sistemas críticos são inestimáveis. que são setenta milhões de operações em ponto flutuantes por segundo. Cluster Beowulf: O nome desse sistema vem de um dos mais antigos épicos da língua Inglesa. 134 . Eddiware e o TurboLinux Cluster. em sua luta contra o monstro de Grendel. Esse modelo de cluster foi concebido pela NASA com intuito de alcançar e avançar na capacidade de processamento massivamente paralelo (Massively Parallel Processing) MPP e aplicá-los para resolução de problemas computacionais. Ponto flutuante é uma forma de representação mais apropriada para computadores de números com muitas casas decimais. de grande força e coragem. especialmente na aerociência e no projeto ESS (Earth and Space Sciences) a um baixo custo. onde o protagonista é um cavaleiro inglês. Nosso trabalho trata de Clusters de Alta Performance de Computação. sendo assim apresentaremos com mais detalhes alguns modelos que se enquadra nessa classe de agrupamento de computadores. Em 1994 o primeiro Cluster Beowulf foi finalizado com uma capacidade de processamento de 70 megaflops.

Docente em algumas universidades nas cadeiras de Redes de Computadores. Software livre de código aberto. 2002). Sistemas Operacionais e Sistemas Distribuídos e Segurança de Redes. com pós-graduação em Redes de Computadores e Segurança de Redes. precisa atender às seguintes características: Nenhum componente feito por encomenda. Os protocolos de rede local. que permite a execução de programas paralelos em ambientes heterogêneos assim como o MPI (Message Passing Interface) que permitem a programação. Os elementos essenciais de um cluster Beowulf são: Os nós. transparente ao hardware e sem nenhum custo em termos de software. com formação em Sistemas de Informações. Periféricos escaláveis. Os Clusters Middleware. Retorno à comunidade do projeto e melhorias. A rede local. O sistema operacional. Essas ferramentas também incluem API’s (Application Programing Interface). Independência de fornecedores de hardware e software. O Beowulf tem como vantagem ser escalável. através de troca de mensagens. fornecendo ao usuário uma interface como se estivesse trabalhando num computador individual. As ferramentas de comunicação que usam como recurso o PVM (Parallel Virtual Machine). Uso de ferramentas de computação distribuída disponíveis livremente com alterações mínimas. 135 . 16 Marcos Pitanga possui mais de 23 anos de experiência em TI no Brasil e no exterior.Segundo Marcos Pitanga16 (PITANGA. que é a entidade que permite que os nós trabalhem como um recurso integrado. para um cluster de PC's ser considerado um Beowulf. no caso o TCP-IP.

Os nós escravos são os computadores onde as aplicações serão executadas de modo paralelo. Os usuários se conectam nessa máquina para acessar os recursos do cluster. assim como o acesso aos nós escravos. perde-se toda a base de usuários. Segue um esquema lógico simplificado de um cluster Beowulf: Figura 16 O nó controlador do cluster funciona como uma interface de saída para o acesso externo à outra rede. seja ela uma rede local ou a própria Internet. compartilhando assim os recursos de memória. Nesse caso recomendase uma redundância de disco nesse computador assim como uma política consistente de backup. processador e disco rígido. Um problema no modelo Beowulf é que se o nó controlador se danificar.Sistema de arquivos paralelo que são bibliotecas de interfaces que permitem visualizar os discos rígidos dos nós como se fosse um único disco virtual. 136 .

ele tem duas interfaces de rede. O resultado foi uma coleção de softwares que representam. Como o OSCAR é desenvolvido como uma solução completa de clusterização há muitas áreas funcionais que precisam ser cobertas pelos componentes do mesmo. A interface private conecta-se a rede do cluster. O OSCAR trabalha com o conceito de um servidor ou head e nós como indicado na figura abaixo. Intel. IBM. O servidor é dual homed. Figura 17 137 . os componentes do software incluídos no OSCAR foram selecionados através da investigação das práticas de muitas implementações independentes de computação em cluster. dentre outras. NCSA and ORNL. ambiente de processamento paralelo. um grupo informal dedicado a simplificar a instalação e o uso de clusters. A interface conectada a rede externa é chamada public. segundo a proposta dos desenvolvedores do OSCAR. incluindo Dell. “as melhores práticas” para criar-se um exitoso ambiente de cluster. ampliando o seu uso. Ao longo dos anos muitas empresas têm suportado o Open Cluster Group. O OSCAR em sua instalação ativa um servidor DHCP (Dynamic Host Configuration Protocol) na interface private para fornecer endereçamento IP automático para os nós. Essas áreas incluem instalação. segurança e administração e manutenção em geral. isto é. Para satisfazer o requerimento de cada área. gerenciamento de carga de trabalho.org).Cluster OSCAR (Open Source Cluster Application Resources): O OSCAR foi criado e é mantido pelo Open Cluster Group (www.openclustergroup.

sendo um script em linguagem Perl que permite o usuário fazer mudanças para futuros ambientes shells. nem requer uma imagem em disco para o nó cliente como outras técnicas de instalação requerem. pacotes que são distribuídos como parte do OSCAR. Tratando do processamento paralelo. podendo ser instalado em hardwares e softwares diferentes. Incluso no pacote do OSCAR temos o LUI (Linux Utility for cluster Install). Existem seis pacotes principais no OSCAR que precisam ser instalados: Core: o pacote principal do OSCAR. A principal razão de o LUI ter sido escolhido como mecanismo de instalação do OSCAR foi que ele não requer que os nós clientes já tenham o Linux instalado.O pacote de instalação do OSCAR é dividido em três partes principais: o core cuja instalação é mandatória. mas a instalação é facultativa e os pacotes de desenvolvedores terceiros. a utilização de RPM (Red Hat Package Manager) e sua característica heterogênea. Perl-qt: a interface Perl orientada a objeto para o kit de ferramenta “Qt GUI”. Provavelmente a parte mais difícil na criação com sucesso de um ambiente em cluster seria a instalação inicial do software responsável por fazer máquinas independentes trabalharem juntas com um único recurso computacional. que é um projeto de software livre desenvolvido pelo Centro de Tecnologia de Linux da IBM. Em meio às várias versões de MPI disponíveis. como um banco de dados que contém todas as informações para um nó instalar-se e configurar-se no cluster. para comandos e controle. SIS (System Installation Suite): utilizado para instalar o sistema operacional em clientes. C3: o grupo de ferramentas para administração em linha de comando do cluster. Oda: uma aplicação de base de dados central para o OSCAR. os desenvolvedores do OSCAR optaram pela MPICH (MPICHamaleon). Environmental Switcher: baseado em módulo. o OSCAR suporta o conceito de passagem de mensagem e provê as implementações mais comuns a MPI (Message Passing Interface) e a PVM (Parallel Virtual Machine). 138 . O LUI apresenta uma série de qualidades.

O tamanho de um grid pode variar de muito pequeno. usualmente utilizando a Internet como meio de comunicação. Uma das principais estratégias da computação em grid é utilizar softwares para dividir e aportar partes de programas em muitos computadores e formar uma rede de processamento paralelo e distribuído. através de uma colaboração pública entre muitas companhias e redes. O nó head também conhecido como front end é um servidor com duas interfaces de rede como ilustrado na Figura 17. O que também distingue a computação em grid dos clusters convencionais seria a heterogeneidade de seus componentes assim como a dispersão geográfica dos mesmos. A computação em grid é uma combinação de recursos computacionais de domínios administrativos múltiplos aplicados para uma tarefa comum. Apesar de havermos apresentado brevemente o conceito de grid na introdução desse trabalho. usualmente para solução de problemas de natureza científica. um cluster com essa tecnologia tem a mesma arquitetura básica do OSCAR. por exemplo. 139 . ou muito grande. vale elucidar um pouco mais o tema. pelo SDSC (San Diego Supercomputer Center) que disponibilizou uma primeira versão conhecida como NPACI Rocks Cluster. Retornando aos conceitos do Rocks. como o Rocks tem uma aplicação também em sistemas em grid. confinado a uma rede de computadores dentro de uma corporação. apesar de o mesmo não ser o foco desse trabalho. técnica ou corporativa que requer um grande número ciclos de processamento de computador ou necessite processar uma grande quantidade de dados. pois não são recursos dedicados completamente à formação desse computador virtual como no caso dos clusters convencionais em que os componentes são considerados “fortemente acoplados”.Projeto Rocks O projeto Rocks teve início em novembro de 2000. que era um conjunto de ferramentas baseadas em Red Hat visando à construção e administração de maneira rápida e prática de clusters para a comunidade científica. Dizemos que os sistemas em grid seria um cluster com computadores “fracamente acoplados” em termos de conexão de rede.

o comportamento estável do Rocks faz dele uma solução de cluster de mercado como Beowulf e o próprio OSCAR. tornando acessíveis essas atividades mesmo para não especialistas. Monitoramento e Gerenciamento do estado do cluster. Rolls que é uma coleção de pacotes e detalhes de configuração que podem ser modularmente acrescidos na base de distribuição do Rocks. Gerenciamento do software do cluster. o Rocks permite que usuários finais adicionem seus próprios softwares através de um mecanismo chamado “Rolls”.O cluster Rocks tem os seguintes elementos principais: Controlador de dispositivos HPC (High Performance Computing). Segundo os desenvolvedores. utilizando recursos de muitos projetos populares de grids e clusters. etc). Adicionalmente. Escolha da distribuição Linux Red Hat. teve como motivo principal a existência de dois mecanismos chaves. Grid. a saber: o software de manipulação de pacotes RPM e sua ferramenta baseada em script para instalação. gerenciamento e monitoramento facilitado mesmo para clusters de grande porte. O Rocks é cluster completamente baseado em distribuição Linux Red Hat com pacotes adicionais e configuração programada para automatizar a implementação de um cluster Linux de alto desempenho. Camada de comunicação e passagem de mensagem. 140 . segundo os desenvolvedores. Uma das premissas do desenvolvimento do Rocks foi criar um software de instalação. apesar do Rocks ter um foco num sistema rápido e flexível de configuração e reconfiguração. especialmente dos nós da solução (kickstart). O mesmo possui um kit de ferramentas baseado na distribuição Red Hat. Aplicações para ambiente em cluster (Códigos Paralelos.

Dr. Isso é alcançado através da migração de processos de um nó para outro de modo preemptivo e transparente. iniciando em 10 de fevereiro de 2002.org. David Santo Orcero18. 141 . visando manter essa solução de cluster como código aberto. Maurizio Davini17. O objetivo seria o melhor desempenho de modo geral num sistema de cluster e a criação de um ambiente multiusuário e time-sharing para a execução de aplicações sequenciais e paralelas. chegando numa versão final desse projeto em 1997 utilizando plataforma Intel e sistema operacional GNU/Linux.mosix. constituindo um algoritmo adaptativo de compartilhamento de recursos. Durante a sua vigência o OpenMosix teve o apoio técnico e financeiro de muitas instituições privadas e públicas. O código do mesmo está disponível em www. é um sistema operacional distribuído desenvolvido na Universidade Hebrew em Jerusalém. Sendo utilizado nos anos 80 pela Força Aérea Americana. para balanceamento de carga e prevenção de trashing em processos de paginação de memória. Consultor e professor da Universidade de Málaga. dentre outros. Dr. sob coordenação do Ph. O OpenMosix é uma extensão de kernel criando um sistema de cluster de imagem única. destacando como membros do projeto. baseado em licença de software livre GPLv2 (hoje já temos a GPLv3). gratuitamente apenas para instituições acadêmicas.Cluster OpenMosix O projeto Mosix (Multicomputer Operating System UnIX).D Moshe Bar. sendo uma ferramenta para sistemas com kernel baseado em plataforma Unix. Ele permite que múltiplas estações monoprocessadas e mesmo multiprocessadas simetricamente executem o mesmo kernel. teve também ampla colaboração da comunidade acadêmica. O OpenMosix é um extensão do projeto Mosix. Moshe Bar. Tendo como principal desenvolvedor o Dr. podendo trabalhar numa significativa cooperação. Israel. 17 18 Consultor da equipe Ferrari de corridas e chefe do Departamento de Física da Universidade de Pisa. como o Linux. devido divergências com a Universidade de Hebrew quanto a questão de direitos autorais.

A granularidade no OpenMosix é determinada pela migração dos processos. Naturalmente nem todos os processos são migrados num cluster OpenMosix. se temos uma tarefa intensiva em termos computacionais que é executada num simples processo. Da mesma forma. ele não terá tempo nem necessidade de ser migrado. Assim ao utilizar essa plataforma há necessidade de escolher as aplicações compatíveis com a mesma. tais como servidores WEB. desde que não exista no próprio computador outro processador para compartilhar essa carga. podendo assim ser entendida para o OpenMosix. que utiliza uma combinação do Resource Kernel do Linux e do Mosix para executar tarefas em tempo real. 142 . 2005). múltiplos processos utilizando memória compartilhada. utilizando-se múltiplas threads. Podemos ver que apesar de ser uma solução elegante. Processos que atuam na manipulação direta de dispositivos de E/S também não migrados. se um processo dura poucos segundos. esse processo seria elegível para ser migrado para outro nó do cluster. Por exemplo. Programas individuais podem criar processo ou processos que podem ser gerados através de múltiplos forks de um único programa. podendo ser constituído de computadores de baixa capacidade de processamento e em redes convencionais. porque o OpenMosix não possui um mecanismo de migração baseado em sockets.Assim o OpenMosix é um sistema de cluster onde todos os recursos estão disponíveis em todos os nós que o compõe. pois o OpenMosix não tem um sistema memória distribuída eficiente. Existe uma proposta de pesquisadores da Syracuse University (OH. especialmente no que diz respeito a não necessitar de um nó controlador. Similarmente os processos que utilizam escalonamento em tempo real também não seriam a princípio migrados. o OpenMosix tem suas limitações e desvantagens. como no cluster Beowulf. mas também podendo ser utilizado em ambientes com servidores de alta performance e em redes de alta velocidade e baixa latência. Seguem algumas diretrizes para um uso eficiente do OpenMosix. não são adequados para serem migrados. Entretanto. que sempre será um ponto único de falha e de gargalo.

para qualquer nó disponível. Bancos de dados que não utilizam memória compartilhada. Processos com longo tempo de execução e baixa utilização dos recursos de rede. Processos que migram para outro nó usam os recursos locais (do nó remoto) sempre que possível. mas os usuários podem sobrepor qualquer sistema automático de decisão e migrar seus processos manualmente. Usualmente as migrações são baseadas em informações providas por algum dos algoritmos de compartilhamento de recursos. sendo completamente transparente em nível de aplicação. aplicações científicas. de engenharia. por exemplo. matemáticas. Tecnologia do OpenMosix O OpenMosix é constituído de duas partes: o mecanismo PPM (Preempetive Process Migration) e um grupo de algoritmos para compartilhamento adaptativo de recursos. Cada processo tem um UHN (Unique Home-Node) gerado onde ele foi criado. utilizando o sistema de arquivos distribuídos do OpenMosix. de tal forma que a interface do Sistema Operacional permanece inalterada. mas interagem com o ambiente do usuário através do UHN. Processos de uso intenso de E/S em disco. a qualquer momento. etc. O PPM pode migrar qualquer processo.Aplicações que têm um bom desempenho com o OpenMosix: Processos CPU-bound. no qual cada processo aparenta estar sendo executado no seu próprio UHN e todos os processos de uma sessão de usuário compartilham o ambiente de execução do UHN. Ambas as partes são implementadas em nível de kernel. O modelo de imagem de sistema único do OpenMosix é coerente quanto ao cache. Compilações extensas. Processos com moderada comunicação interprocessos. 143 . utilizando módulos carregáveis (via RPM ou compilação direta do kernel). Normalmente esse é o nó no qual o usuário executou o login. Processos que podem ser migrados manualmente.

os processos do usuário estarão confinados ao UHN. 144 . evitando trashing e/ou excessivos swapping de processos. Esse cenário permite a entrada e saída de nós com o mínimo impacto para o funcionamento do cluster como um todo. tendo assim uma natureza probabilística. O algoritmo de uso memória atua na prevenção do esgotamento na mesma. Quando os requerimentos de recursos excederem os níveis estabelecidos. O número de processadores e sua velocidade é um importante fator nas decisões tomadas por esse algoritmo. Ele operará adequadamente até haver recursos disponíveis no cluster como um todo. O algoritmo é ativado quando se percebe que um nó começa a ter excessivas paginações devido ao esgotamento da memória. O algoritmo dinâmico de balanceamento procura continuamente reduzir a diferença de carga entre os nós. então algum processo pode ser migrado para algum outro nó. Algoritmos de Compartilhamento de Recursos Os principais algoritmos de compartilhamento de recursos do OpenMosix seria o balanceamento de carga e o uso de memória. tomando as decisões de controle baseado nos algoritmos de controle de recurso que são executados no mesmo. sendo projetado para alocar um número máximo de processos no agregado de memória RAM do sistema. Essas funcionalidades permitem o sistema ser flexível no que tange à escalabilidade. operando com eficiência em pequenas e grandes instalações. sobrepõe-se ao algoritmo de balanceamento de carga e faz uma tentativa de migrar algum processo para um nó com memória RAM disponível. O OpenMosix não tem um controle central no modelo mestre/escravo. Essa escalabilidade é alcançada porque a decisão de um nó em migrar um dado processo baseia-se num conhecimento parcial sobre o estado dos outros nós.O PPM é a principal ferramenta para os algoritmos de gerenciamento de recursos. O principal objetivo é maximizar o desempenho através de uma utilização eficiente dos recursos disponíveis na rede. nesse caso o algoritmo de controle de memória. tais como utilização de CPU e memória principal estiver abaixo de certos limites. Enquanto o requerimento de recursos. Cada nó opera como um sistema autônomo.

O tempo de migração tem um componente fixo para estabelecer uma instância do novo processo no nó remoto. ele é proporcional ao número de página de memória a serem transferidas. Para minimizar o overhead da migração apenas as tabelas das páginas e as páginas “sujas” (páginas de retiradas da memória física. o processo continua interagir com seu ambiente de origem independente de sua localização. Essa implementação é feita via camada de enlace sob o ponto de vista do modelo ISO/OSI. O contexto do sistema. a transparência de localização é alcançada pelo encaminhamento das chamadas de sistemas dependentes do kernel para o deputy no UHN. Na execução de um processo no OpenMosix. 145 . O remote encapsula o processo quando o mesmo está sendo executado em nível de usuário. mas que foram modificadas e precisam ser armazenadas no arquivo swap) são transferidas. O contexto do usuário. permanecendo no UHN. conhecido como remote contém o código do programa. o processo de migração é dividido em dois contextos: contexto do usuário. que pode ser migrado e o contexto do sistema.Migração de Processos O OpenMosix possui um processo preemptivo e completamente transparente de migração de processos através do PPM. Para a implementação do PPM. As chamadas de sistema são interações síncronas entre dois contextos de processos. a pilha. Depois da migração. sendo um componente linear. A interface entre o contexto do usuário e o contexto do sistema é muito bem definida. os dados. que é dependente do UHN e não pode ser migrado. O deputy contém a descrição dos recursos que estão associados ao processo e a pilha do kernel para a execução do código do sistema referente ao mesmo. Portanto é possível interceptar toda a interação entre os contextos e encaminhar essa interação através da rede. Ele mantém parte local do processo no contexto do sistema. conhecido como deputy encapsula o processo quando ele está sendo executado em modo kernel. O deputy nunca é migrado. o mapeamento de memória e o estado dos registradores do processo.

ele compartilha o mapeamento principal do kernel de modo similar a uma thread. A principal vantagem dessa abordagem seria a escalabilidade na consistência de cache mesmo para um número significativo de processos. O OpenMosix usa o DFSA (Direct File System Access). tais como chamadas de sistema. é necessária a transferência de dados do espaço do usuário para o kernel. segundo os desenvolvedores por questões de segurança. Em muitas atividades de kernel. Ao invés disso. qualquer operação de memória do kernel que envolva o acesso ao espaço do usuário requer que o deputy se comunique com o remote para transferir-se os dados necessários. como por exemplo. Devido a todo espaço de memória de usuário residir no nó remoto. A consistência de cache é obtida através da manutenção de um único servidor de cache tendo os outros nós como clientes que apenas repassam as requisições de acesso ao cache desse servidor. diferentemente de outros sistemas de arquivos distribuídos como. O DFSA foi projetado para reduzir o overhead para se executar chamadas de sistemas orientadas a E/S de processos migrados. mantendo a quantidade de dados possível no deputy em buffer no início da chamada de sistema para serem enviados apenas no final da mesma. Ele basicamente faz isso. Mecanismos do Deputy e do Remote O deputy é o representante do processo remote no UHN. No OpenMosix. um cache especial é implementado visando a diminuição de cópias remotas. considerando o sistema de arquivos de cada nó do cluster. o NFS. Sistemas de Arquivos Para suportar o DFSA foi desenvolvido o oMFS (open Mosix File System) que provê uma sistema único de localização de arquivos. Infelizmente o oMFS foi retirado dos últimos pacotes liberados pelo OpenMosix.Acesso a arquivos: O OpenMosix tem seu próprio sistema de arquivo para cluster em Linux que dá uma visão na perspectiva de cluster de todos os sistemas de arquivos que o compõe. migrando os processos para os computadores que tem uma maior demanda de E/S de disco. o deputy não possui nenhum mapeamento de memória próprio. 146 . Para minimizar o overhead de cópias de dados na comunicação entre contextos.

fazem o OpenMosix frágil nos limites que seus desenvolvedores chamam de parte interna (inside) do cluster. 147 . verificação de onde os processos estão correntemente sendo executados. O próprio Dr. lock de um processo contra migrações automáticas. administração do sistema. ajustando-se a processos que alteram seu perfil de execução. Isso evita possíveis incompatibilidades de programas de usuários entre diferentes versões de Linux. a API foi modificada para fazer interface com sistema de arquivo /proc. como por exemplo. API do OpenMosix: A API do OpenMosix foi originalmente implementada através de um grupo reservado de chamadas de sistemas que eram usadas para configurar. Essa estatística é alterada no tempo. controle da coleta de estatísticas e informação sobre processos remotos. As chamadas para o OpenMosix via /proc incluem: requisições de migração síncronas e assíncronas.map” e a própria aplicação de descoberta automática de nós “omdiscd” que trabalha com multicast. Moshe afirma que as políticas de segurança deveriam ser aplicadas no perímetro do cluster e não dentro no mesmo. ao responder um questionamento sobre a vulnerabilidade do sistema a ataques de DoS (Denial of Service). Segurança no OpenMosix: Devido a sua arquitetura e “modus operandi”. a relação de confiança entre os nós do cluster. o OpenMosix possui algumas questões de segurança inerentes a plataforma. a necessidade de comunicação entre todos os nós de forma praticamente permanente. Essa informação é utilizada para avaliar se o processo precisa ser migrado do UHN. a facilidade de um invasor editar o mapeamento dos nós do cluster no arquivo “openmosix. A API foi implementada através da extensão da árvore do sistema de arquivo /proc com um novo diretório: /proc/openMosix. identificação de restrições para migrações. pesquisar e operar o OpenMosix. Seguindo a convenção atual do Linux.Coleta de Informações Estatísticas sobre o comportamento dos processos são coletadas regularmente. tais como todas chamadas de sistemas e todo o tempo em que o processo acessa dados de usuário.

Via de regra. para que através de filtros. existem algumas distribuições do OpenMosix como o CHAOS que substitui a aplicação em multicast do “omdiscd” pela aplicação “tyd” que trabalha com unicast como um gatekeeper num ambiente VoIP ou mesmo um servidor WINS da plataforma Microsoft. o mesmo provê um ambiente mais acessível para aplicar tecnologia como IPSec possibilitando a criação de VPN’s entre os nós. ou seja um ponto único de falha e de gargalo. mas como ele trabalha com pacotes unicast. O “tyd” em si não implementa qualquer funcionalidade de segurança. seja uma conexão direta com a Internet. o tráfego interno não seja acessado externamente. A rede outside é a rede conectada ao mundo externo seja uma rede local onde o cluster estaria conectado. Como já visto a rede inside é a rede que provê a comunicação entre os nós que usualmente trabalha com as portas UDP 5000-5700 e TCP 723 e 4660. Soluções mais elaboradas podem ser utilizadas colocando um firewall entre as duas redes que seriam confinadas através de VLAN (Virtual Local Area Network). 148 . pois o “tyd” não possui nenhum dispositivo de autenticação.Tratando de mitigações. o tráfico inside não deve ser acessado pela rede outside sem um mínimo nível de segurança. mesmo que ainda não completo. Essa solução não seria a mais adequada pois traria para o OpenMosix a mesma inconveniência dos modelos de cluster com um nó controlador. precisamos também analisar a questão da rede inside e a rede outside. A solução para manter essa separação lógica. ativando a funcionalidade de firewall (Netfilter) no mesmo. Tendo apresentado uma solução de contorno para prover certo nível de segurança entre os nós do cluster. seria colocar uma segunda interface de rede num dos nós do cluster conectado na rede outside.

149 . Um módulo de comunicação é necessário para obter-se uma comunicação entre o deputy e o remote para as tratativas do Migshm. essas chamadas acessam o mapeamento local de memória. Ele não é exatamente um completo DSM (Distributed Shared Memory). O MigShm tem como pretensão realizar a migração de memória compartilhada.Iniciativas de melhorias do OpenMosix Durante seu ciclo de vida. Asmita. Anu. Snehal and Krushna (MAASK. Uma das limitações do OpenMosix é executar aplicações que utilizam memória compartilhada e multi-threads. seja prover soluções para deficiências intrínsecas do sistema. não podendo assim ser beneficiadas pela principal característica do OpenMosix que é a migração de processos. elas também implementaram um daemon em cada nó do OpenMosix chamado “MigSharedMemD”. Maya. seja aprimorar funcionalidades. Podemos citar o grupo. mas é suficiente para endereçar algumas situações de memória compartilhada no OpenMosix. que utiliza o port TCP 3418. o OpenMosix teve algumas iniciativas isoladas de melhorias visando. O MAASK utilizou o “Commlink” para esse propósito. entretanto para garantir a comunicação entre dois processos em nós diferentes. 2003) que desenvolveram o MigShm um kernel patch ao OpenMosix visando otimizar a funcionalidades de memória compartilhada do mesmo. na ocasião de estudantes da Universidade de Puna. pois elas não conseguem ser migradas. Para o desenvolvimento do Migshm foi necessário a criação de algumas chamadas de sistemas tais como “shmget()”. Cada uma dessas funções é disponibilizada transparentemente no remote e quando da necessidade da migração de processos com memória compartilhada. Índia. “shmdt()” e “shmctl()”. “shmat()”.

ser relativamente pequeno por nó.Diferentes processos utilizando mesma região compartilhada podem migrar para diferentes nós. pois cada canal criado para esse fim consome uma quantidade significativa de recursos. através do modelo de consistência “Eager Release”. onde eles trabalham com cópias locais dessa memória compartilhada. 150 . economizando assim os recursos dos nós de um cluster OpenMosix. segundo o autor. que implementa um mecanismo onde cópias locais de páginas modificadas serão apenas escritas no processo que as originou quando o lock desse segmento de memória for liberado e não para qualquer escrita. Isso garante que o nó originador da memória compartilhada sempre terá a cópia mais atual da mesma. Travis Frisinger do departamento de Ciência da Computação da Universidade de Wisconsin-Eau Claire que no seu artigo “A Modification of OpenMosix’s Process Migration” propõe um controle maior no processo de migração OpenMosix. Sua proposta seria reutilizar o canal para migrar mais de um processo por vez. o mesmo será mais significativo em clusters com uma quantidade significativa de computadores na ordem de centenas. em torno de 2%. A consistência é mantida entre as diferentes instâncias cópias locais. Apesar do ganho em desempenho.

etc) são globais e dinamicamente gerenciados. memória. O gerenciamento global de recursos habilita uma distribuição transparente dos mesmos entre os nós e um uso adequado dos recursos do cluster como um todo. causando nenhum impacto na execução das aplicações. por aplicações que os demandem. Mecanismos eficientes de gerenciamento de processos são implementados no Kerrighed para prover um escalonamento global. podendo ser migrados durante sua execução. como por exemplo. Porém o cluster Kerrighed avançou em algumas funcionalidades as quais são ineficientes ou inexistentes no OpenMosix. 151 . discos. processos e threads podem iniciar sua execução em qualquer nó. mesmo em eventos de falha de algum nó do cluster (Alta Disponibilidade). implementando o padrão de interface em camadas que é suportado pela maioria das aplicações. paginação remota e uma forma eficiente de se transferir o espaço de memória de processos migrados. baseado em Linux kernel. No Kerrighed todos os recursos de cada nó que o compõe (processadores. O principal objetivo Kerrighed é prover serviços de alto nível na execução de aplicações sequenciais e paralelas num sistema de cluster. O Kerrighed é implementado como uma extensão de um sistema operacional padrão em cada nó. No Kerrighed. arquivo de cache corporativo. os serviços de alto nível de um sistema operacional padrão podem ser executados elegantemente de modo a prover segmentos de memória virtual.Cluster Kerrighed O cluster Kerrighed tem muitas similaridades com o OpenMosix. um compartilhamento de memória eficaz e a migração de threads. O gerenciamento dinâmico dos recursos habilita uma reconfiguração transparente do cluster (adição e retirada de nós). Em adição. A camada de comunicação do Kerrighed é baseada no novo conceito de Fluxos Dinâmicos (Dynamic Streams). Baseando-se em containers. provendo uma comunicação eficiente na migração de processos. especialmente no que tange a ser um cluster de imagem única (SSI) e também por trabalhar com a migração de processos. um mecanismo de checkpointing é provido para evitar a reinicializarão de aplicações (pelo menos desde seu início) quando uma falha de um nó ocorre. O gerenciamento global de memória no Kerrighed baseia-se no conceito de container.

o número de processos que estão sendo executados em cada um deles. ele é implementado como uma extensão do sistema operacional tradicional existente. Esses K-process são migrados dentro do cluster para um melhor aproveitamento dos recursos e para igualizar a carga de trabalho entre os nós que compõe o mesmo. criando processos de maneira criteriosa ou migrando-os quando ocorrer algum desvio. são migradas para o Kerrighed sem nenhuma modificação. Essa igualdade da carga de trabalho é obtida através de uma escolha cuidadosa em qual nó cada processo deve ser executado. Assim aplicações já existentes que são executadas em sistemas operacionais tradicionais. baseando esse mapeamento em alguns objetivos a serem alcançados como. balanceamento entre as CPU’s. interface essa familiar aos desenvolvedores de aplicações. Assim o papel da política global de escalonamento é manter o cluster num estado de equilíbrio no que tange ao uso dos recursos. Todo o espaço de memória utilizado por K-process está ligado aos containers. A principal vantagem da abordagem do Kerrighed é a interface padrão que cada nó que o compõe possui. A política de escalonamento do Kerrighed define como os processos são mapeados entre os nós. deixando para cada nó a tarefa de gerenciar os recursos locais. O Kerrighed apenas atua nas atividades de natureza distribuída próprias do sistema de cluster.Do ponto de vista dos desenvolvedores do Kerrighed. Segundo seus desenvolvedores essas propriedades existem no Kerrighed por meio de um gerenciamento global e dinâmico de recursos. por exemplo. a saber. oferecendo a ilusão que todo recurso é único e compartilhado. mas de fato. um SSI deve possuir quatro propriedades. o uso de CPU por processo e o estado de cada nó como. podendo posteriormente ser otimizadas para usufruírem melhor das funcionalidades do cluster. O Kerrighed não é um sistema operacional desenvolvido totalmente do início. distribuição transparente de recursos. Ele também utiliza como parâmetros a serem considerados nessa política. por exemplo. alta desempenho. 152 . alta disponibilidade e escalabilidade. Gerenciamento Global de Processos Características principais: Um processo que é manipulado pelo Kerrighed passa a chamar-se de K-process.

um scheduler num cluster necessita ter a possibilidade de ser passível de configuração quando ocorrer algum cenário em termos de utilização processamento ou de recursos não contemplados pela política de escalonamento do cluster ou que para o qual os algoritmos de escalonamento não conseguem prover resultados adequados. Na interface padrão de threads no Posix. processos e threads podem ser criados usando interfaces “fork” e “execv”. provendo assim uma visão do estado do cluster. por exemplo). Esses mecanismos são todos baseados nas funcionalidades e estados dos processos que são executados no sistema operacional local. 153 . No Kerrighed. O processo de checkpointing ajuda a diminuir a contenção global nos recursos por colocar em suspensão algumas aplicações. Escalonamento Global alterável e modular: O Kerrighed propõe um escalonamento global modular. se necessário. Analisadores locais para detectar todos os problemas locais de escalonamento tais como alta contenção de recursos e falhas em dispositivos. A política de escalonamento do Kerrighed pode ser facilmente alterada pelo administrador do mesmo. O scheduler do Kerrighed baseia-se num conjunto de mecanismos eficientes de gerenciamento de processos. é permitida a criação e o gerenciamento das mesmas em aplicações de memória compartilhada.Mas. Criação remota de processos e threads. Num sistema padrão Linux. Essa arquitetura modular permite interagir separadamente com diferentes aspectos do escalonamento global. além disso. composto de três camadas: Probes do Sistema para coleta de informações do mesmo. Gerenciador global de escalonamento para ativar novos processos e resolver problemas de escalonamento. e assim facilitar modificações na suas políticas. migração de processos e threads são usadas para diminuir a contenção de recursos locais assim como evitar a execução de aplicações em nós que necessitam ser desativados (para manutenção. esses mecanismos são ampliados através dos mecanismos de gerenciamento de processos para que aplicações legadas desenvolvidas para computadores SMP (Symmetric Multiprocessing) possam obter vantagens na utilização de clusters.

Probes do Sistema. podendo novas probes ser desenvolvidas por programadores de sistemas operacionais. Cada analisador local pode estar ligado a um conjunto de probes. Analisadores locais recebem as informações das probes. esse último coleta informações locais. Existem dois diferentes eventos do sistema: eventos do kernel do Linux e eventos do scheduler global. o analisador local envia uma requisição para o gerenciador global de escalonamento (o analisador local não tem uma visão geral do estado do cluster e. 154 . detectando algum estado anormal do sistema local. Por exemplo. não pode tomar uma decisão nesse nível). passivas e ativas. por exemplo. Quando uma probe passiva é acionada por um evento do sistema. Se um problema de CPU é detectado. O Kerrighed provê um conjunto de probes na sua implementação. podemos ter uma probe para o consumo de CPU e outra para a temperatura da mesma. a probe é acionada). enquanto probes passivas são acionadas por um evento do sistema. Essa camada também tem a função de enviar as informações das probes para gerenciador global de escalonamento. medindo. a probe envia a informação coletada para o analisador local com o qual ela está ligada. Um grupo de analisadores locais é executado em cada nó. Por exemplo. o uso de CPU ou memória constituem-se na primeira camada. enquanto que se utiliza uma probe passiva para detectar um “ping-pong” de páginas de memória entre duas threads de uma aplicação de memória compartilhada (quando uma página chega ao nó. para os quais ela envia informação. as analisa e filtra. portanto. uma probe ativa pode ser usada para verificar a utilização de CPU (a CPU é periodicamente verificada). Probes ativas são regularmente acionadas por um temporizador do sistema. Existem dois tipos de probes. Cada probe pode ser ligada a um grupo de analisadores locais. O analisador local ligado a essas duas probes pode detectar uma alta contenção local de CPU. assim como problemas locais de temperatura.

de acordo com a política de escalonamento. Diferentes probes. Os gerenciadores globais de escalonamento executados em diferentes nós comunicam-se entre si para trocar informação do estado de cada nó que compõe o cluster. o scheduler do kernel do Linux não é modificado. sendo ligado a um grupo de analisadores locais. 155 . o gerenciador global de escalonamento pode decidir migrar alguns processos ou acionar um checkpointing para alguma aplicação. a criação de novas políticas de escalonamento global. Finalmente. o balanceamento de CPU). Essa camada é a única que tem uma visão global do mesmo. habilitando a detecção global de problemas de escalonamento. CPU’s locais com mais carga do que a média do cluster).Um gerenciador global de escalonamento é executado em cada nó. Além disso. Quando um problema de escalonamento é detectado (por exemplo. permitindo. probes de CPU). Essa visão global é construída com as informações das probes (por exemplo. Para esse fim. Essas três camadas que compõe o escalonamento global modular do Kerrighed podem ser configuradas usando arquivos XML. de maneira simples. analisadores locais e gerenciadores globais de escalonamento podem ser dinamicamente ativados e desativados sem a necessidade de se encerrar nem o sistema operacional nem as aplicações. cada gerenciador global de escalonamento implementa uma política global de escalonamento ( por exemplo. a fim de obter um uso eficiente dos recursos do cluster. cada camada provê uma estrutura de desenvolvimento para facilitar a programação de novos componentes. O Kerrighed apenas adiciona ou remove processos no scheduler local.

Para estabelecer um novo processo. A extração de um processo consiste na criação de um processo ghost (virtualização de processo) composto dos seguintes componentes: espaço de endereçamento. Através dos containers tanto arquivos abertos como páginas de memória podem ser acessados por qualquer nó do cluster. 156 . o Kerrighed provê dois mecanismos: criação remota de processos e duplicação remota de processos.Gerenciamento do estado dos processos Os schedulers do Kerrighed são baseados em três mecanismos: estabelecimento. registradores do processador e os próprios dados. migração e check-point/restart de processos. Identificador de Processo (PID). que viabiliza consideravelmente a migração de processos. O espaço de memória e arquivos convencionais abertos são tratados pelos containers e os arquivos de stream por mecanismos de dynamic streams (fluxos dinâmicos). A criação remota de processos utiliza uma interface dedicada semanticamente equivalente a um fork(). criando um clone do mesmo. que necessita extrair todas as informações de memória e arquivos abertos a fim de criar um processo ghost coerente. Gerenciamento de espaço de endereçamento e arquivos abertos: De modo similar a um kernel padrão do Linux. A criação. duplicação e checkpoint/restart de um processo Kerrighed utilizam o mesmo mecanismo fundamental de extração de processo. o sistema necessita extrair uma imagem do processo criador e transferi-lo para um nó remoto. imediatamente seguido por um execv() no processo filho. A duplicação de processos é utilizada na execução de aplicações quando um novo processo (usando fork) ou threads (usando pthread create) são criados. Para o estabelecimento. essa migração precisa extrair uma imagem do processo e transferi-la para o nó remoto. necessitando herdar o contexto da aplicação. no Kerrighed o espaço de endereçamento e os arquivos abertos de um Kprocess são globalmente gerenciados. arquivos abertos. criando um clone que será executado no mesmo. Similarmente para uma migração remota de processo. mas o processo original é finalizado. O checkpointing de processo também necessita extrair uma imagem do mesmo e armazená-la no disco ou numa memória remota.

O Kerrighed implementa o conceito de container como um único mecanismo para gerenciar globalmente as memórias físicas do cluster. O Kerrighed adiciona uma camada ao sistema. transferir páginas entre nós e gerenciar a coerência de cópias de páginas replicadas. um KPID é composto do PID original e o identificador do nó corrente. Existem duas áreas chaves no gerenciamento de memória num cluster. Segundo. os processos são identificados por um Process Identifier (PID). como o seu PID. os sistemas de paginação de memória e de arquivos de cache cooperativos baseiam-se em mecanismos comuns: localizar a cópia de uma página de memória no cluster. Em nível de kernel. Para cada processo é designado um Kerrighed Process Identifier (KPID). apenas o KPID é visualizado. enquanto que em nível de usuário. Dessa forma um único KPID é designado para um processo em todo cluster. As threads são distinguidas por identificadores internos na biblioteca pthread. um mecanismo remoto de paginação e um mecanismo cooperativo de arquivos de cache.Gerenciamento do Identificador de Processo (PID): No Linux padrão as threads são implementadas por processos utilizando a biblioteca pthread. é muito desejável num cluster explorar a memória que está distribuída entre os nós. a fim de suportar a execução de aplicações multi-thread e modelos usuais de programação em ambiente de memória compartilhada. 157 . para aumentar a eficiência dos serviços do sistema operacional. Para garantir a unicidade. Primeiro. um sistema de DSM (Distributed Shared Memory) é necessário. Então. permitindo que processos e threads compartilhem segmentos de dados em qualquer nó do cluster. Num sistema de DSM. Todos os serviços do sistema operacional que utilizam páginas de memória acessam a memória física através de containers. o PID é usado. Gerenciamento Global de Memória O gerenciamento global de memória num cluster abrange muitos serviços. A biblioteca de thread do Kerrighed gerencia o identificador adicional de thread.

Linkers Muitos mecanismos num kernel apoiam-se no manuseio de páginas físicas. Por integrar esse mecanismo genérico de compartilhamento dentro do sistema. Para cada container são associados um ou mais linkers de alto nível chamados linkers de interface e linkers de baixo nível chamados linkers de input/output. O Kerrighed propõe um serviço genérico inserido entre os serviços de sistema e os gerenciadores de serviços chamados de containers. cada nó executa o seu próprio kernel do sistema operacional. podendo assim ser utilizadas como entrada de arquivo de cache. tirando vantagem do gerenciamento de recursos locais de baixo nível. Os dados armazenados num container podem ser compartilhados e acessados pelo kernel de qualquer nó do cluster. o qual pode ser dividido de modo grosseiro em duas partes: serviços de sistema e gerenciadores de dispositivos. Os linkers desviam esses mecanismos para garantir o compartilhamento através dos containers.Containers Num cluster. Os containers são integrados ao kernel graças aos linkers que são partes de software inseridas entre os gerenciadores de dispositivos existentes. A ideia principal do container é que ele dá a ilusão aos serviços de sistemas que a memória física é compartilhada como um computador SMP (Symmetric Multiprocessing). Um container é um objeto que permite que o armazenamento e compartilhamento de dados em toda extensão do cluster. é possível dar a ilusão para o kernel que ele está manipulando uma memória física. os serviços de sistema e os containers. 158 . A função do linker de interface é desviar o acesso aos dispositivos de serviços do sistema para os containers enquanto um linker de E/S permite o acesso a um gerenciador de dispositivo. Isso permite manter a interface do sistema operacional já conhecida pelos usuários. Sobre essa memória virtual compartilhada é possível estender ao cluster os serviços tradicionais oferecidos por um sistema operacional padrão. Ele atua em nível de kernel. implementado com um protocolo write-invalidate. O modelo oferecido pelos containers é sequencialmente consistente. As páginas de um container podem ser mapeadas num espaço de endereço de um processo. dentre outras aplicações. sendo completamente transparente em nível de software de usuário.

Para que esse serviço seja provido. Memória Virtual Compartilhada A memória virtual compartilhada no Kerrighed estende esse serviço ao cluster por permitir que vários processos ou threads sejam executados em nós diferentes. compartilhando dados através do seu espaço de endereçamento. enquanto que a terceira é garantida pelo mapeamento do linker de interface. vindos do dispositivo ao qual ele está ligado. Um linker de interface muda a interface do container para fazê-la compatível com a interface de serviços de sistema de alto nível. Durante a criação de um novo container. seja em seu nó do cluster seja numa memória compartilhada de um grupo de threads. mapear um container de memória em espaços de memória virtual de vários processos via um mapeamento de linker. Assim. Isso é feito por mapear um arquivo de container num espaço de memória virtual de um processo graças a um mapeamento de um linker de interface. É possível conectar vários serviços de sistema a um mesmo container. Estendendo esse serviço a um cluster considera-se o mapeamento de um arquivo no espaço de endereço de um processo não importando onde será sua execução. Os serviços do container garantem as duas primeiras propriedades. coerência na replicação de dados e acesso simples a dados compartilhados. Mapeamento de Arquivos O serviço de mapeamento de arquivos de um sistema operacional convencional permite mapear um arquivo no espaço de endereço de um ou mais processo. ou no espaço de endereço compartilhado por um grupo de threads. um linker de E/S é associado ao mesmo. Design dos Serviços de Sistema Distribuídos Os containers e linkers são utilizados para implementar vários serviços que compõe um cluster. leva a uma memória virtual compartilhada. Essa interface precisa dar a ilusão para esses serviços que eles se comunicam com gerenciadores de dispositivos tradicionais. O container deixa de ser então um objeto genérico para tornar-se um objeto de compartilhamento de dados. dentre eles memória virtual compartilhada e serviços de mapeamento de arquivos. são requeridas três propriedades: compartilhamento de dados entre os nós. 159 .Os serviços de sistemas são conectados aos containers graças aos linkers de interface.

Os fluxos dinâmicos e o KerNet sockets são implementados na camada KerNet. quando a migração não ocorre. migrar processos não deveria alterar o desempenho de sua comunicação com outros processos. Processos que se comunicam utilizando interfaces padrão tais como sockets ou pipes devem ser capazes de serem transparentemente migrados num cluster. 160 . utilizam um fluxo binário para realizar a comunicação entre processos. Ela é um serviço distribuído que provê gerenciamento global de fluxos em todo cluster. O fluxo dinâmico KerNet é uma abstração de fluxo com dois ou mais KerNet sockets definidos e com nenhum nó especificado. quando dois KerNet sockets estão conectados. O Kerrighed possui um sistema de comunicação de baixo nível que é confiável e mantém a ordem das mensagens enviadas entre dois nós. uma operação de envio/recepção pode ocorrer. Por exemplo.Dynamic Streams (Fluxos dinâmicos) O Kerrighed implementa um balanceamento de cargas de trabalho compostas de aplicações paralelas. Além disso. sobre o qual interfaces padrão de comunicação são desenvolvidas. as aplicações devem ser capazes de tirar vantagem dessas propriedades. Serviço de Fluxo Dinâmico Todos os clusters baseiam-se num sistema de comunicação ponto a ponto de baixo nível. Fluxos dinâmicos e KerNet sockets são implementados no topo de um sistema portável de comunicação de alta performance. baseando-se em memória compartilhada ou em modelos de programação de message passing. Um desafio é migrar eficientemente processos utilizando message passing. alta performance e ordenação de mensagens. As extremidades desses fluxos são chamadas KerNet sockets e os mesmos podem ser migrados dentro do cluster. Quando necessário. tais sistemas proveem propriedades tais como confiabilidade. provendo uma interface de envio/recepção para transferir dados entre diferentes nós num cluster. um KerNet socket é temporariamente associado a um nó. As interfaces padrão de comunicação tais como pipes e sockets. Assim. Na maioria das vezes. O Kerrighed propõe um conceito de fluxo dinâmico.

161 . Quando um estado de um KerNet socket muda. O principal objetivo desse módulo é gerenciar o protocolo de interface de comunicação padrão. O serviço de fluxos dinâmicos é responsável por alocar KerNet sockets quando necessário. Dependendo do tipo de fluxo. A fim de criar um ambiente padrão baseado em fluxos dinâmicos e KerNet sockets. o processo é desconectado do fluxo. Implementação de Interfaces de Comunicação Padrão usando Fluxos Dinâmicos Aplicações distribuídas padrão. se necessário. Quando conexão termina. são atualizados em todos nós ativos no fluxo. As interfaces KerNet são ligações entre o sistema operacional Linux padrão e o serviço dinâmico de comunicação do Kerrighed. assim como monitorar os mesmos. Com esse mecanismo. cada um deles localizado num nó do cluster. uma camada de interface é implementada em nível de kernel. o mesmo pode ser fechado.Seguem alguns dos principais parâmetros do fluxo dinâmico KerNet: Tipo de fluxo Número de sockets Número de sockets conectados Filtro de dados Fluxos são controlados por um grupo de gerenciadores. Estruturas de dados do kernel relacionadas com fluxos dinâmicos são mantidas num diretório global que é distribuído entre os nós cluster. obviamente não utilizam KerNet sockets. Dados como a localização do nó de um KerNet socket. o gerenciador de fluxo é acionado e atualiza os outros KerNet sockets relacionados a esse fluxo. cada KerNet socket tem o endereço do socket de cada nó correspondente num mapeamento.

etc). em especial o KerNet. Por essa razão. Confiabilidade: Toda mensagem é entregue sem qualquer alteração. retransmissão de pacote. Todos os diferentes serviços. chamada “Gimli/Gloïn”. incluindo a camada de comunicação.O sistema operacional do Kerrighed é desenvolvido sobre um kernel levemente modificado de Linux. Interface simplificada: Esse serviço de comunicação é baseado na ideia de canais e provê uma interface básica envio/recepção. são implementados como módulos do Linux. Camada de comunicação de baixo nível A arquitetura do KerNet é projetada para sistemas operacionais distribuídos tais como o Kerrighed. Segue algumas características dessa camada de comunicação. foi natural desenvolver o KerNet no topo da camada de comunicação de baixo nível provida pelo Kerrighed. A camada “Gimli” provê uma API em nível de kernel sobre a qual todos os serviços do Kerrighed são executados. 162 . A camada “Gloin” é responsável pela confiabilidade da comunicação (controle de erro. A camada de comunicação é constituída de duas partes: um sistema de comunicação estático de alto desempenho que provê um serviço “nó para nó” e um serviço de interface que substitui as funções padrão para uma dada ferramenta de comunicação.

que já estão consolidadas em ambientes de processamento monoprocessado. essa solução de contorno incide num custo maior na implementação do cluster. Assim um sistema de cluster seja qual o modelo e tecnologia utilizada não será uma somatória simples do poder de processamento e funcionalidades dos nós que o compõe. por exemplo. Os sistemas de clusters que possuem um nó controlador. pois uma boa parte dos recursos desses nós serão utilizados para o estabelecimento e a manutenção do cluster. trabalhar com elementos como threads.Conclusão do Capítulo Ao pesquisar sobre os modelos e tipos de clusters apresentados nesse capítulo. possuem uma melhor performance que os clusters SSI (Single System Image). pois como descrevemos nesse capítulo. no nosso juízo. produz uma condição intrínseca de um ponto único de falha. como. Quanto aos clusters SSI. o Beowulf. requer um maior grau de complexidade e consequentemente soluções mais apuradas para implementar tais funcionalidades. memória e espaço de memória e sockets num ambiente de sistema de imagem única. através de um sistema operacional que provê esse tipo de funcionalidade. são de desenvolvimento mais simples e usualmente. provendo assim uma maior robustez ao sistema como um todo. deveriam ser registradas. que vai de encontro com a nossa proposta de oferecer uma solução não dispendiosa dessa tecnologia. porém a arquitetura física e lógica de um elemento que gerencia os nós escravos. vemos neles uma solução mais elegante e tecnicamente rica. 163 . sendo a única interface entre o ambiente externo e o cluster. que faz desse modelo de processamento distribuído não aderente a ambientes de alta disponibilidade. Por certo. pudemos chegar a algumas conclusões preliminares que. Apesar de haver soluções de redundância para o nó mestre para clusters com essa característica. pois se propõe a tornar um grupo de computadores numa única entidade. desenvolver um sistema dessa natureza é um desafio.

de acordo com a proposta desse trabalho.Capítulo 3 – Apresentação do Laboratório A apresentação do laboratório considerará os seguintes aspectos: Descrição do hardware utilizado Descrição do Sistema Operacional utilizado Descrição da configuração do Cluster Kerrighed implementada Descrição dos aplicativos utilizados para análise do ambiente em cluster e standalone. Descrição do hardware utilizado Segue um esquema lógico do laboratório proposto: Figura 18 164 .

Segue uma imagem dos equipamentos do laboratório: Figura 19 165 .

1s IEEE 802.1D Spanning Tree Protocol IEEE 802.3z 1000BASE-X 100BASE-FX 1000BASE-T 1000BASE-SX 1000BASE-LX/LH 166 .3x full duplex on 10BASE-T.3ad IEEE 802.1Q VLAN IEEE 802.1x IEEE 802.3af IEEE 802.3u 100BASE-TX IEEE 802.1w IEEE 802.3 10BASE-T IEEE 802. 100BASE-TX e 1000BASE-T IEEE 802.1p CoS Prioritization IEEE 802.3ab 1000BASE-T IEEE 802.Descrição dos itens que compõe o laboratório: Switch Catalyst 3750E – 24 Portas 10/100/1000 e 2 Portas 10 Gigabit Ethernet Desempenho: Capacidade de switching fabric – 160 Gbps Taxa de transmissão – 65.5 Mpps Principais funcionalidades: IEEE 802.

20-krg (i686) 2 x Broadcom Corporation NetXtreme BCM5700 Gigabit Ethernet 167 .93GHz 2075 MB Debian GNU/Linux 5.6.Computadores Para facilitar a identificação passaremos a designar os computadores utilizados no laboratório como Nó 00 e Nó 01 do cluster. Nó 00 Processador Memória Sistema Operacional Controladora de Disco Intel(R) Core(TM)2 Duo CPU E7500 @ 2.0.4 Intel Corporation 82801GB/GR/GH Disco Kernel Interface de Rede ATA SAMSUNG HD322HJ Linux 2.

Nó 01: Processador Memória Intel(R) Core(TM)2 CPU E7500 @ 2.93GHz 2334 MB

Sistema Operacional Debian GNU/Linux 5.0.4
Controladora de Disco Marvell Technology Group Ltd. 88SE6145 SATA II PCI-E controller

Disco Kernel Interface de Rede

Seagate Barracuda ST340014A 40GB Linux 2.6.20-krg (i686)
2 x Broadcom Corporation NetXtreme BCM5700 Gigabit Ethernet

Descrição do Sistema Operacional utilizado O Sistema Operacional utilizado é o Linux na distribuição Debian na versão do GNU/Linux 5.0.4 com kernel 2.6.20 modificado para suporte ao Kerrighed. A escolha da distribuição Debian deu-se por a mesma ter uma melhor compatibilidade com Kerrighed e especialmente na instalação do mesmo. O Debian também se mostrou muito estável e resiliente durante a implementação e testes do cluster. Seguem algumas características que contribuíram para escolha do Debian: É mantido por seus próprios usuários. Se alguma funcionalidade precisa ser aperfeiçoada, a própria comunidade atua na melhoria. Suporte eficiente pela própria comunidade. Mensagens enviadas às listas de discussão frequentemente são respondidas em cerca 15 minutos.

168

Pacotes bem integrados O Debian supera todas as outras distribuições no que se refere à qualidade de integração de seus pacotes. Já que todo software é organizado em grupos coerentes, não apenas pode-se encontrar todos os pacotes em um única fonte, mas pode-se assegurar de que já foram tratados os problemas no que tange às dependências complexas. Apesar de o formato deb ter algumas vantagens sobre o rpm , é a integração entre os pacotes que faz o sistema Debian mais robusto. Código fonte Quantidade significativa de ferramentas de desenvolvimento, facilitando a inclusão de funcionalidades ao sistema operacional. Estabilidade Os desenvolvedores do Debian afirmam que existe uma quantidade significativa de caso em que computadores executam a distribuição por um longo tempo, sem nenhuma indisponibilidade do sistema operacional. Pudemos verificar isso durante a implementação no laboratório. Rápido e leve com a memória Por ser baseado em GNU/Linux o Debian mostra-se confiável e leve no que concerne ao uso de memória. Drivers para a maioria do hardware são escritos pelos usuários de GNU/Linux, não pelos fabricantes. Embora se possa considerar como uma deficiência o tempo para que os novos dispositivos sejam suportados ou mesmo a falta de suporte para alguns deles, isso permite que o suporte ao hardware seja mantido até bem depois da parada de produção pelo fabricante ou da saída do mesmo do mercado. A experiência tem mostrado que drivers livres são normalmente melhores que os proprietários.

169

Descrição da configuração do Cluster Kerrighed implementada Histórico do Kerrighed O projeto Kerrighed foi iniciado por Christine Morin19 em 1999 no INRIA, laboratório nacional francês para pesquisa em ciência da computação. Até 2006, o projeto foi desenvolvido no INRIA (Institut National de Recherche en Informatique et en Automatique) como protótipo de pesquisa com pessoas do INRIA, EDF e Universidade de Rennes 1. Desde 2006, o Kerrighed é o fruto do projeto na comunidade PARIS, desenvolvido pelo Kerlabs, INRIA, parceiros do consórcio XtreemOS e um número crescente de colaboradores. Instalação do Kerrighed O Kerrighed foi instalado em dois nós através das instruções publicadas em www.kerrighed.org . Basicamente os fontes do Kerrighed e do kernel 2.6.20 são obtidos no GForge do INRIA, ambos são configurados e compilados. Os seguintes diretórios e arquivos precisam ser criados para que a instalação tenha sido exitosa: /boot/vmlinuz-2.6.20-krg /boot/System.map /lib/modules/2.6.20-krg /etc/init.d/kerrighed /etc/default/kerrighed /usr/local/share/man /usr/local/bin/krgadm /usr/local/bin/krgcapset /usr/local/bin/krgcr-run /usr/local/bin/migrate kernel do Kerrighed Tabela de símbolos do kernel do Kerrighed Módulos do Kerrighed Script de serviços do Kerrighed Configuração de Serviços Páginas Man Ferramenta de administração do cluster Ferramenta verificação de funcionalidades Ativação checkpoint/restart dos processos Ferramenta de migração de processos

/usr/local/lib/libkerrighed-* Biblioteca do Kerrighed /usr/local/include/kerrighed Cabeçalhos da Biblioteca do Kerrighed Tabela 1 Depois da instalação basta editar o arquivo /etc/kerrighed.nodes para identificar ou ativar os nós dentro do cluster automaticamente no momento da inicialização.

19

Cientista Sênior do Rennes - Bretagne Atlantique. Líder do grupo de pesquisa Myriads. Cofundadora do Kerlabs empresa criada para fornecer serviços comerciais na tecnologia Kerrighed. Coordenadora científica do projeto europeu do XtreemOS.

170

O Kerrighed cria uma nova imagem de sistema que pode ser escolhida no momento da inicialização do Linux. Com o comando “krgadm” o cluster pode ser inicializado manualmente, podendo-se verificar se o mesmo está funcional e reconhecendo os nós.

Descrição dos aplicativos para testes PovRay Uma atividade computacional intensa é a criação de imagens em três dimensões em computadores. As empresas cinematográficas têm usado cada vez mais esse recurso, seja para criar produções totalmente animadas digitalmente, seja para criar alguma imagem que seria dispendiosa ou mesmo impossível de ser gerada, utilizando a criação tradicional de cenários. Apesar dos sistemas em cluster em geral não serem, via de regra, apropriados para execução aplicações em tempo real, como por exemplo, VoD ou IPTV, eles são muito utilizados nos processos de renderização de imagens, pois os mesmos necessitam de sistemas de grande poder de computação que podem ser provido pelos clusters. Iremos verificar se o Kerrighed apresenta bons resultados utilizando a aplicação de renderização de imagens PovRay (Persistence of Vision Ray Tracer) que é uma ferramenta com recursos interessantes, com uma baixa complexidade no manuseio e apresentando imagens de ótima qualidade em termos de cores, detalhes e iluminação, muito próximas de imagens reais. O ray-tracing é um método de gerar imagens a partir de uma descrição geométrica de objetos. Ele é uma técnica de renderização que calcula uma imagem de alguma cena através da simulação de raios de luz que viajam no mundo real. Entretanto esse trabalho é feito de trás para frente. No mundo real a luz é emitida de uma fonte e ilumina os objetos. A luz reflete nos objetos e passa através de objetos transparentes. Essa luz refletida atinge nossos olhos ou a lente de uma câmera, por exemplo. Como a vasta maioria dos raios nunca atinge um observador, gerar uma cena desse modo levaria um enorme tempo.

171

bruma ou fogo. passam através de um espaço visível. um ou mais raios visíveis são disparados da câmera na cena. Esses raios visíveis originados pelo observador. Por esse motivo raios são enviados de trás para frente. Se a superfície é reflexiva ou transparente. 172 . as fontes de luz. Após fazer um download do arquivo binário do PovRay em www. Para cada pixel da imagem final. Raios representando sombras são gerados para determinar se o ponto está nas sombras ou não. O usuário especifica a localização da câmera. novos raios são configurados e traçados para determinar a contribuição de luz refletida e refratada para cor final da superfície.7 (Beta) já suporta de maneira nativa processamento paralelo. seu interior (caso forem transparentes) e qualquer atmosfera como neblina. gerando a imagem final. Em cada momento que um objeto é atingido. representados por uma câmera. Iniciaremos o nosso laboratório com a versão 3.org basta seguir as instruções para instalação apresentada no mesmo WEB site. Segundo os desenvolvedores do PovRay a versão 3. efeitos atmosféricos e áreas de luz. Podemos mencionar como métodos rasterization e ray casting e como ferramentas “Mental Ray” e “RenderMan”. os objetos. Para funcionalidades especiais como reflexão interdifusa. de cada fonte luz para determinar a quantidade de luminosidade vinda dessas fontes.6 por ser a versão oficialmente consolidada.PovRay.Programas como o PovRay simulam os raios de luz saindo por detrás da cena. a textura das superfícies dos mesmos. a cor da superfície do mesmo é calculada. Naturalmente existem outros métodos e ferramentas para renderização de imagens. Uma das verificações que serão realizadas no laboratório será a renderização de uma imagem e o consumo de tempo e recursos para realizar esse tipo de operação computacional. faz-se necessário disparar um número maior de raios na cena para cada pixel. para verificar se eles interceptam algum objeto na mesma.

sua implementação. suporte a listas. A linguagem steve. os gargalos das simulações do Breve estão mais relacionadas a simulação física e a renderização das imagens do que na execução do código do steve. cada argumento de um método de chamada é associado a uma palavra chave. No steve. Ele também oferece uma arquitetura de plugin simples com a qual os usuários podem estabelecer interfaces com bibliotecas externas ou linguagens. 173 . a OpenGL. é significamente diferente dos sistemas citados. vetores de 3D nativos assim como grupo de classes que fazem interface com funcionalidades de simulação do sistema central (engine) do Breve. dispositivo de detenção de colisão. pode causar algum problema de desempenho. O Breve inclui uma linguagem interpretada orientada a objeto. mas por suas palavras chaves. A diferença é que a sintaxe do método de chamadas é mais parecida com o Objetive-C. que simula tanto tempo contínuo e espaço contínuo em 3D. especialmente designada para simulações em 3D. As simulações do Breve são escritas numa linguagem simplificada orientada a objeto chamada steve. suporte experimental para corpos físicos articulados e resolução de colisão com fricção estática e dinâmica. O steve é uma linguagem procedural e muitas de suas funcionalidades parecerão familiar aos usuários da linguagem C. incluem coletores de lixo (garbage collection). Enquanto ele é conceitualmente similar aos sistemas já existentes tais como o Swarn e o StarLogo. bibliotecas e programas. acessando as mesmas através do steve. O Breve é um ambiente integrado de simulação o qual objetiva simplificar grandemente a implementação de sistemas descentralizados e simulações avançadas de vida artificial. Isso significa que os argumentos não são identificados por sua ordem. O principal objetivo desse sistema é permitir a implementação rápida e fácil de simulações descentralizadas ao mesmo tempo em que provê uma estrutura com muitos recursos que facilitam a construção de simulações de vida artificial avançadas. mas na prática.Breve: Um ambiente 3D para Simulação de Sistemas Descentralizados e Vida Artificial O Breve é um ambiente em 3D destinado a simulação de sistemas descentralizados e de vida artificial. tanto que o ambiente do Breve é adequado para diferentes classes de simulações. Ele é destinado tanto para usuários que não programam como usuários com experiência em linguagem de programação. O fato de steve ser uma linguagem interpretada que retém muitos tipos de verificações e métodos de busca até o momento da execução do código.

Os membros mais importantes da hierarquia Abstract são as classes Control e Data. enquanto os objetos estacionários representam entidades que são imóveis durante o curso da simulação. controlando funcionalidades como câmera.Classes hierárquicas gerais A interação com as funcionalidades nativas do Breve é realizada da através de classes hierárquicas gerais. Cada ação que o agente pode tomar pode ser escrita como um método separado que é chamado em resposta a certos eventos. A hierarquia é dividida em classe Abstract e classe Real. A classe Data é uma classe especial pode ser salva em disco ou em rede. A classe Abstract é definida como classes que não possuem uma representação física no mundo simulado. ajuste de luminosidade. Há muitos modos de disparar eventos dentro de uma simulação no Breve: Eventos chamados por interação Eventos escalonados para um momento específico Eventos disparados por notificações Eventos disparados por colisões Eventos disparados através da interface de usuário 174 . No topo dessa hierarquia temos a classe chamada Object que é o pai de todos os objetos criados no Breve. renderização gráfica e interface com usuário. tais como o piso e obstáculos. Eventos e Escalonamento O comportamento dos agentes são escritos no steve como parte da definição de um objeto. A primeira que provê uma interface com o engine do Breve. As funções dessas classes são simples: objetos móveis representam agentes que se movem durante o curso da simulação. A classe Real inclui objetos móveis e os objetos estacionários. enquanto a classe Real está associada a alguns tipos de objetos físicos.

o ambiente de simulação Breve é único. a instância controladora pode ser considerada como o processo principal da simulação. assim inferimos que o mesmo seja beneficiado com esse modelo computacional. Concluindo.Init e Destroy Se necessário. quando uma instância é criada e liberada. assim como a sua capacidade para realização de simulação física. mas o OpenGL que realiza grande parte das funções do Breve provê suporte para processamento paralelo. sendo a única instância que é automaticamente criada quando uma simulação é executada. respectivamente. A instância controladora é definida no código fonte da simulação. A instância controladora também recebe um número de retornos (callbacks) de objetos no mundo simulado ou selecionando itens de um menu. por exemplo. Assim esse método permite manipular inicialização e a desativação de uma instância. por sua vez. sendo adequado para simulações de vida artificial e outros sistemas descentralizados. se necessário.org/. serem criadas pela instância controladora através do método init. Sua principal ênfase é estabelecer como objetivo a implementação de simulações de baixo nível altamente realistas a fim de manipular comportamentos de alto nível com o mesmo grau de realidade. assim nesse caso. distingue o Breve dos pacotes de simulação atuais. O software Breve pode ser obtido em http://www. Quanto ao processamento paralelo não existe nenhuma informação dos desenvolvedores da aplicação sobre o tema.spiderland. os métodos especiais init e destroy são automaticamente chamados. 175 . facilidade de uso de sua linguagem orientada a objeto. Outras instâncias podem. Execução de Simulações Cada simulação é controlada por um simples objeto controlador – uma instância da classe nativa Control (ou algumas de suas subclasses). As funcionalidades como a habilidade de simular e apresentar modelos de 3D contínuo.

É importante ressaltar que o próprio cluster e suas funcionalidades inerentes podem também influenciar nos resultados obtidos. facilitará as medições. Certamente outras aplicações de mesma natureza terão comportamento e desempenho distintos. especialmente no que tange a utilização dos recursos do processamento paralelo. um cluster com um número maior de nós. o Breve num ambiente de cluster. no caso o PovRay e Inteligência Artificial. Acreditamos que a análise nesse ambiente mais restrito. acreditamos que o objetivo desse trabalho será alcançados tendo em vista que a proposição é avaliar aplicação de Design Digital. 176 . realizando testes com outras aplicações e em condições distintas. como por exemplo.Conclusão do capítulo Apesar do ambiente provido para a medições e análise ser de natureza singela em termos de quantidade de nós do cluster e das aplicações que serão utilizadas no laboratório. comparações e conclusões e ao mesmo tempo servirá de arcabouço para uma abordagem mais abrangente do tema.

dentre outros itens. Existem diversas abordagens e componentes para avaliação de desempenho de clusters. se estamos tratando de HPC (High Performance computing). demanda por operações de memória e E/S.Capítulo 4 – Medições e análises Os sistemas em clusters serão mais plenamente aproveitados se as aplicações que forem executadas pelos mesmos suportarem processamento paralelo que seria dividir tarefas e funções da aplicação entre os processadores que os compõe. pois na maioria dos casos existe um ponto de saturação. podemos ter casos em que o aumento de nós pode vir a degradar o desempenho da aplicação. tamanho do problema (granularidade). analisaremos algumas delas: Performance teórica de pico Esse valor representa o máximo de operações em ponto-flutuante por segundo. Em sistemas paralelos as principais métricas são ganho de velocidade (speedup) e a capacidade de crescimento ou escalabilidade. Essa resposta em termos de desempenho dependerá de parâmetros como velocidade de clock. tempo de utilização de CPU. quando a inserção de um novo nó no cluster passa a não corresponder a um aumento de desempenho. De fato. Quando falamos de escalabilidade estamos considerando o quanto uma determinada aplicação será beneficiada com o aumento de nós num cluster. calculado pela seguinte fórmula: P=N * C* F * R Fórmula 2 Onde: P representa o desempenho medido em Mflops ou Gflops N é o número de nós do cluster C identifica o número de CPU’s por nó F é o número de operações em ponto-flutuante por ciclos de clock R é a velocidade de clock medido em ciclos por segundo 177 . visando sempre executar as aplicações num tempo menor. uso do canal de comunicação.

particularmente a Amdahl Corporation. Segue a fórmula: Fórmula 3 Lei de Amdahl20 A programação de aplicações que utilizem o processamento paralelo ainda está num estágio incipiente. 178 . Ele talvez seja mais lembrado por ter formulado a Lei de Amdahl. No nosso caso utilizaremos essa abordagem ao analisar o PovRay. 20 Gene Myron Amdahl (16 de novembro de 1922) é um projetista de computadores e empreendedor no ramo da alta tecnologia. assim existem aplicações que apenas parte das tarefas é executada paralelamente e algumas em que as tarefas são totalmente serializadas.Performance das Aplicações É o número de operações realizadas quando se está executando uma determinada aplicação. mais conhecido por seu trabalho com mainframes na International Business Machines (IBM) e posteriormente por suas próprias empresas. dividido pelo tempo de execução. Execução de Aplicações Seria a medição do tempo de execução de determinada aplicação numa condição predeterminada. Esse tipo de medida é feita através de programas de benchmark não correspondendo pelo menos em sua plenitude a uma aplicação de uso prático. Amdahl criou uma expressão para medir a porção de processamento paralelo e a porção de processamento serializado numa dada aplicação. uma teoria fundamental da computação paralela. Ganho de velocidade Podemos medir o ganho de velocidade de uma determinada aplicação num cluster comparando o seu tempo de execução com tempo de execução da mesma aplicação num computador standalone.

A fórmula é trivial:

Fórmula 4 Onde: p representa o desempenho da porção serial em porcentagem T é o tempo em segundos (1-p) representa a porção paralelizável N é o número dos nós do cluster

Somente a porção paralelizável do programa que se beneficia com os processadores dos nós do cluster. Assim o ganho de processamento seria:

Fórmula 5 Quanto mais a aplicação tiver tarefas que são processadas de modo paralelizado e quanto maior a quantidade de nós no cluster, maior será o ganho de processamento segundo Amdahl. Performance da rede As conexões de rede são também um item essencial no desempenho do cluster como um todo. Seguem alguns quesitos importantes no que tange às redes que conectam os nós que compõe um cluster:

179

Vazão (throughput): A quantidade efetiva de dados em bits por segundo que são transmitidos entre os nós. Apesar velocidade das interfaces de rede e do elemento onde elas estão conectadas (usualmente um switch) serem determinantes para o desempenho da rede, existem outros fatores que precisam ser considerados como, por exemplo, o desempenho dos nós em geral em termos de CPU, memória, cache, etc, assim como o barramento em que estão conectadas as interfaces de rede, os drivers dessas interface e latência do sistema como um todo, dentre de outros fatores. Eficiência do protocolo TCP-IP: O protocolo TCP-IP comporta-se de maneira diferente em relação aos diferentes aplicativos e os parâmetros que o mesmo utiliza. Por exemplo, o protocolo NFS (Network File System) tende a ter uma melhor performance que o CIFS (Common Internet File System) em condições normais, sem nenhum ajuste de parâmetros de TCP-IP nesses aplicativos. Overhead do TCP-IP e das camadas de rede inferiores: Existem uma quantidade significativa da banda das conexões de rede que são utilizadas para endereçamento, multiplexação, detecção e correção de erros que não será efetivamente utilizada para o tráfego de dados e manutenção do cluster. Esse overhead impede de utilizarmos capacidade total de banda disponível para tráfego efetivo de dados. Abordagem e ferramentas de análise do desempenho do cluster A nossa abordagem e estratégia de medição da performance será a seguinte: Medição e análise do throughput real das conexões de rede. Estresse do cluster e análise, para confirmar a efetiva funcionalidade do mesmo. Teste e medição de memória. Medição e análise do sistema em cluster e monoprocessado em ferramentas tradicionais de benchmark apresentadas no aplicativo hardinfo. Medição e análise do sistema monoprocessado e em cluster utilizando um aplicativo de Design Digital (PovRay). Medição e análise do sistema monoprocessado e em cluster utilizando um aplicativo de Inteligência Artificial (Breve).

180

Análise geral dos resultados Medição e análise do throughput real das conexões de rede. Utilizamos o aplicativo iperf para medir o throughput real das conexões de rede e como esperado não foi alcançada a banda passante de 1 Gigabits/sec que é a velocidade das interfaces de redes, pelos motivos explanados no início desse capítulo. Seguem as medições:

Figura 20 Percebemos que na transmissão unidirecional de pacotes obtemos a taxa de 644 Mbits/sec, 64% da banda nominal das interfaces de rede que são de 1 Gigabit Ethernet. Na transmissão bi-direcional obtemos os valores de 279 Mbits/sec num sentido e 411 Mbits/sec no outro. Isso é um indicativo que um dos computadores tem um melhor throughput, que seria aquele que tem uma configuração de hardware superior, que confirma o fato que esse quesito pode ser determinante na taxa de transferência de um sistema.

181

Consideramos uma taxa de transferência de 644 Mbits/sec adequada para um cluster com apenas dois nós, não sendo um impedimento para a utilização plena do mesmo. Essa afirmação será verificada nas próximas medições e análises.

Estresse do cluster e análise para confirmar a efetiva funcionalidade do mesmo Para verificar o comportamento do cluster numa situação de estresse, estabelecemos o seguinte cenário: Nó 00 Aplicações executadas: Breve – Creature.tz PovRay – benchmark.pov

Nó 01 Aplicação executada: Breve – Gatherers.tz PovRay – benchmark.pov Utilizaremos a aplicação system monitor para medir a utilização de CPU, memória e consumo de banda do cluster.

182

Telas Nó 00: Figura 21 – Execução das aplicações Breve e PovRay no Nó 00 Figura 22 – Evidência de o cluster estar operacional 183 .

Figura 23 – Medições de utilização CPU. Memória e Rede no Nó 00 Figura 24 – Tempo de renderização do Benchmark.pov no Nó 00 184 .

pov no Nó 01 185 .Tela Nó 01 Figura 25 – Execução da aplicação Breve no Nó 01 Figura 26 – Tempo de renderização do Benchmark.

Percebemos que apenas quando iniciamos a execução da renderização do arquivo benchmark. Podemos afirmar nessa primeira análise que a renderização de imagens pelo menos em se tratando do PovRay possui uma tendência para utilização intensa de CPU. Podemos também afirmar que nas condições de testes estabelecidas o consumo de banda foi muito baixo.pov que a utilização de CPU em ambos os computadores chegou a 100%. uma DSM (Distributed Shared Memory). é um dos grandes desafios dessa tecnologia. como uma sinalização que esse componente não será um fator de estrangulamento no ambiente proposto. 186 . como os processadores dos nós são Core Duo. O comportamento do cluster Kerrighed nesse teste foi positivo. os mesmos são apresentados como 4 processadores pelo system monitor. decidimos fazer um teste específico de memória para verificar o comportamento desse componente num cluster Kerrighed. Esse aplicativo destina-se a verificar a integridade de memória RAM em Linux.pov no nó 01 foi de 3 minutos e 58 segundos numa condição de saturação das CPU’s. Ao ultrapassarmos esse limite o cluster deixa de operar. apenas 2. Teste e medição de memória Utilizamos o aplicativo memtester para verificar as condições da memória do cluster. porém a utilização de memória e o consumo de banda se mantiveram estáveis e em níveis baixos. A título de esclarecimento. necessitando-se uma reinicialização do mesmo.4 Gbytes. Seguem os resultados.6 Gbytes nesse teste. Pela utilização consideravelmente baixa de memória durante a execução dos aplicativos no teste de estresse proposto. Porém não foi possível utilizar 4. tendo em vista que o compartilhamento e a integridade da memória num cluster. O tempo total de renderização do arquivo Benchmark. pois o seu uso durante a execução das aplicações PovRay e Breve foi muito reduzido. realizando uma série de verificações.

Telas Nó 01: Figura 26 – Medição do uso da memória durante a execução do memtester Figura 27 – Finalização do teste de memória sem apresentar nenhum erro 187 .

Medição e análise do sistema em cluster e nos nós com ferramentas de benchmark apresentadas no aplicativo hardinfo Executamos as rotinas de benchmark do aplicativo hardinfo em cada nó separadamente e no próprio cluster. em torno de 10 Kbps. Temos o nó 00 com 2.Tela Nó 00: Figura 28 – Medição do uso da memória durante a execução do memtester Concluímos em primeiro lugar que o cluster Kerrighed realiza a agregação das memórias físicas dos nós que o compõe. indicando consumo de memória configurado ao executar-se o comando.6 Gbytes).3 Gbytes. que foi de 2.075 MBytes de memória e o nó 01 com o 2.594 MBytes e o system monitor indicou uma memória total de cerca 4. Outra observação foi novamente a utilização baixíssima dos recursos de rede. seguem os resultados: 188 . Assim podemos concluir que as aplicações PovRay e Breve nas condições em que foi realizado o teste de estresse do cluster realmente não demandam uma quantidade de memória significativa.600 MBytes (4. Esse agregado de memória passou pelos testes do memtester sem apresentar nenhum erro.

Gráfico 3 Maior valor indica um melhor desempenho.Gráfico 1 O valor maior indica um melhor desempenho. Gráfico 2 Menor valor indica um melhor desempenho. 189 .

190 . Gráfico 5 Menor valor indica um melhor desempenho.Gráfico 4 Maior valor indica um melhor desempenho. Gráfico 6 Menor valor indica melhor desempenho.

Geração de hashing em SHA1 para 312MB de dados. como o memtester faz um locking de memória no espaço de usuário. O Kerrighed irá apenas apresentar resultados práticos significativos quando executarmos vários processos simultaneamente em todos os nós que compõe o cluster.Geração de hashing em MD5 para 312MB de dados. Constatamos. para os testes realizados pela aplicação hardinfo. ele não conseguiu testar toda a extensão da memória RAM. pelo menos nas aplicações utilizadas no benchmark do hardinfo. podemos afirmar que o cluster SSI Kerrighed não seria uma infraestrutura viável pelo menos no que concerne ao desempenho. Ao discutir com a comunidade do Kerrighed o resultado dos testes realizados até esse momento do nosso trabalho. os profissionais ou pesquisadores (dentre eles profissionais da Kerlabs) que contribuíram com suas experiências com o cluster Kerrighed. Baseado nessas informações.compressão de dados utilizando o algoritmo Zlib em 64 MBytes de dados. Quanto ao memtester. Ele sugeriu executar o memtester em todos os nós que compõe o cluster simultaneamente. um dos pesquisadores disse que ao fazer testes em memórias non-ECC utilizando essa ferramenta em nós individuais de seu cluster. elencaram as seguintes considerações: Apenas aplicações desenvolvidas para processamento paralelo irão se beneficiar em termos de desempenho ao utilizarem o Kerrighed. CPU MD5 . CPU SHA1. mediante os valores levantados.Segue uma breve descrição dos testes de benchmark realizado pelo hardinfo: CPU Zlib .cálculo do número 42 de Fibonacci. que o desempenho do cluster é menor (apesar de ser muito próximo) ao desempenho do Nó 00 que é computador com a maior capacidade no cluster. 191 . CPU Fibonacci . CPU Blowfish – Execução do algoritmo de criptografia Blowfish FPU Raytracing – Programa para renderização de imagens utilizando a mesma técnica do PovRay.

considerando os resultados e conhecimento adquiridos através dos testes e medições realizadas até esse estágio do trabalho.pov em cada nó cluster em separado. executando o mesmo arquivo com cluster em operação. Tempo de execução do benchmark. Assim executamos o arquivo benchmark. Medição e análise do sistema em cluster e monoprocessado utilizando um aplicativo de Design Digital (PovRay) Medir o desempenho do aplicativo PovRay foi relativamente simples. comprovando a capacidade do cluster de migrar processos.pov em apenas um nó do cluster. após isso.Para obtermos uma constatação definitiva da viabilidade do cluster Kerrighed. executaremos essas aplicações em ambiente standalone. Executamos num primeiro momento o arquivo benchmark. Algo digno de nota ao realizarmos a execução do arquivo benchmark.pov em apenas um nó do cluster. executamos simultaneamente o arquivo nos dois nós que compõe o mesmo. foi que o shell (terminal) foi aberto e executado num nó do cluster e a imagem renderizada surgiu no outro nó que compõe o mesmo. no nosso caso o Breve e o PovRay. pois o mesmo apresenta o tempo de execução. como uma opção para o processamento de aplicações de Inteligência e Design Digital. ao finalizar uma renderização. Utilizamos o menor tempo de execução da renderização entre os dois nós como referência nessa medição.pov em segundos 350 300 250 200 150 100 50 0 Nó 00 Nó 01 Execução em 1 Execução em 2 Execução em 2 Nó Nós Nós com alta Utilização Gráfico 7 192 . dentro das premissas propostas em nosso trabalho. verificando o comportamento das mesmas em relação ao ambiente em cluster.

tz. Para reforçar a validade dessa hipótese. mas apenas nos beneficiamos dos recursos do Kerrighed quando executamos vários processos ao mesmo tempo. que ao executarmos o arquivo benchmark. podendo assim renderizar vários arquivos numa mesma plataforma virtual de hardware. executamos em ambos os nós a simulação do Breve Gatherers. autor de livros abordando essa tecnologia. Concluímos que o cluster Kerrighed executando renderizações na aplicação PovRay. 193 .pov concorrentemente nos dois nós. de utilizarem todos os recursos de um nó. confirmando a tese que o cluster Kerrighed apresenta um melhor desempenho quando executamos vários processos simultâneos. Percebemos também. O desempenho do Kerrighed. Porém em nenhum momento o Kerrighed obteve um melhor desempenho que o nó com a melhor configuração de hardware executando o mesmo arquivo do PovRay. ao executar esses processos simultaneamente. não provê um aumento de desempenho linearmente proporcional a quantidade de nós que compõe o cluster. realmente teriam esse comportamento. atingindo o mesmo tempo do execução do computador com melhor hardware que compõe o cluster.Constatamos que o tempo de execução do arquivo do PovRay é maior para cluster do que para o computador standalone com maior poder computacional que compõe o mesmo. trabalhando em modo standalone. para que utilizem os recursos dos outros nós que compõe o cluster. assim como o benchmark. até que os mesmos sejam exauridos.pov. um dos profissionais especializados em cluster Linux no Brasil. melhorou significantemente. houve uma diminuição do tempo de execução. Ao também discutirmos o tema com Marcos Pitanga. o mesmo também confirmou que clusters SSI (Single System Image).

Medição e análise do sistema em cluster e monoprocessado utilizando um aplicativo de Inteligência Artificial (Breve) A comparação entre o sistema em cluster e um nó que compõe o mesmo em modo standalone. e por extrapolação verificar o aumento de capacidade de execução de simulações baseadas em IA realizadas pelo Breve no cluster.args | sort -k 1 -r | less” abaixo: Figura 29 . pois as simulações do Breve são de execução contínua. muito do processamento era consumido por esse processo como se pode verificar no resultado do comando “ps -eo pmem.Resultado do comando “ps” em ambiente monoprocessado Figura 30 . percebeu-se que como o Breve gera imagens em movimento no ambiente gráfico do Linux (GNOME). não foi tão direta e simples como a abordagem utilizada com o PovRay. Ao iniciar os testes e medições.Resultado do comando “ps” em cluster 194 .pcpu. Assim a proposta para essa avaliação foi baseada na medição do consumo de processador e memória RAM que cada instância do Breve consumiria no ambiente monoprocessado e em cluster. utilizando o Breve.

tivemos 90.2% da utilização total de processador para uma instância do Breve no cluster contra 0.3% do processamento consumido para esse mesmo fim. o tempo de execução do Breve. Como se pode verificar nas figuras acima. A realização e a análise dos testes corroboraram para a constatação que o cluster Kerrighed em relação ao computador standalone possui um maior poder de processamento e capacidade de memória. Mesmo com essa utilização acentuada de processador para a interface gráfica. percebe-se que a capacidade de memória para execução de instâncias do Breve no cluster é exatamente o dobro da capacidade do computador standalone. foi praticamente o mesmo nos dois ambientes de teste. podendo assim realizar ao mesmo tempo mais instâncias dessa aplicação. indicando numa primeira análise. temos uma média de 0. pois esse percentual é calculado sobre a capacidade total de processamento do cluster.5% de utilização total de processador no ambiente monoprocessado. Seguindo a mesma linha de raciocínio. percebemos que a utilização de processador para a execução do Breve no cluster é menor que a utilização de processador no ambiente monoprocessado. uma maior capacidade execução de instâncias do Breve pelo cluster. 195 .6% do processamento para a interface gráfica e no cluster Kerrighed também com 6 instâncias de Breve. porém o tempo de resposta. Isso significa uma capacidade 150% maior de processamento de instâncias Breve pelo cluster em relação ao computador standalone.No ambiente com um computador standalone com 6 instâncias do Breve sendo executadas tivemos 68. isto é. ao analisar o consumo da capacidade total de memória nos dois ambientes.

implantado e medido. ou para dar maior consistência a esse capítulo. iremos apresentar de maneira mais sistemática e sintética os resultados e interpretação dos mesmos. que esse tipo de cluster possui uma capacidade de executar mais instâncias e processos ao mesmo tempo do que executá-los mais rapidamente. mas sim. que um cluster Kerrighed seria mais apropriado para situações onde desejamos ter várias execuções de uma tarefa ao mesmo tempo do que ter uma tarefa isolada sendo executada mais rapidamente. Segue dois gráficos que clarificam a questão do aumento de capacidade de processamento proporcionado por um cluster: 196 . muitas considerações já foram feitas. De fato. Portanto. podemos concluir baseado em nossas experimentações. ou para facilitar a própria leitura e análise desse trabalho. além de pontuarmos as principais constatações obtidas durante a pesquisa e experimentação. podendose assim ser utilizado como referência ou motivação para pesquisas da mesma natureza. Salientamos que essa afirmação refere-se estritamente ao ambiente de teste proposto. nossos experimentos mostraram que para esse ambiente de teste não houve nenhum ganho em termos de desempenho ao utilizarmos o cluster Kerrighed para se executar as aplicações PovRay e Breve quando comparado ao ambiente monoprocessado e sim um aumento de capacidade. que existem constatações empíricas e teóricas que sinalizam que os clusters SSI não possuem uma correspondência linear entre a quantidade de nós e o desempenho do cluster. Nesse capítulo de fechamento. Podemos afirmar dentro do universo das experimentações realizadas nesse trabalho.Capítulo 5 – Conclusão Durante a apresentação dos capítulos anteriores. mas não o extrapolado diretamente para ambientes e modelos diferentes do que o apresentado nesse trabalho. Ressaltamos também que as aplicações que utilizamos nesses testes não suportam processamento paralelo. conforme a Lei de Amdahl. que poderia prover um ganho de desempenho quando executado num cluster.

que após a quinta instância executada do benchmark.pov no cluster. percebemos que a partir da execução da terceira instância do benchmark. apresentado no gráfico 9. 197 .pov teve a sua estabilidade comprometida. Esse foi o comportamento do cluster Kerrighed em laboratório.Cluster 350 300 Tempo de Resposta 250 200 150 100 50 0 1 2 3 4 5 6 7 8 9 10 Instâncias Tempo de Resposta Gráfico 8 Computador Standalone 500 Tempo de Resposta 400 300 Instâncias 200 100 0 1 2 3 4 5 6 7 8 9 10 Tempo de Resposta Gráfico 9 Ao observar o gráfico 8. ocorreu uma estabilização do tempo de resposta na ordem de 236 segundos até a execução de 10 instâncias desse arquivo do PovRay. dobrando o tempo de execução da sexta instância devido a essa espera. Ao contrário do computador standalone. necessitando-se esperar a finalização de uma das instâncias para iniciar uma nova.

Ele também foi responsável pelas propostas do CMG para o ITSMF do qual o padrão ITIL é oriundo. Vale recordar qual foi a questionamento inicial que serviu de norte para nossa pesquisa: Seria a Tecnologia de Clusters uma infraestrutura acessível para a implementação de HPC com ênfase em Inteligência Artificial e Design Digital? A Tecnologia de Cluster é uma infraestrutura acessível e adequada para aplicações HPC com ênfase em Inteligência Artificial e Design Digital. leva ao pesquisador a esperar resultados que não que podem não ser reproduzidos num ambiente de teste real. Capacidade é o número de carros por hora que a rodovia M4 (Rodovia que liga Londres ao País de Gales) pode suportar. A própria denominação para esse tipo de cluster em contraponto ao cluster HA (High Availability) que é HPC (High Performance Cluster). Capacidade: Quantidade de trabalho que pode ser realizado num determinado período de tempo. Ao analisar o caminho percorrido nessa pesquisa. 2011) membro do CMG (Computer Measurement Group): Desempenho: Quantidade de tempo que uma transação individual ou parte de uma tarefa leva para ser completada. 21 Michael Ley começou trabalhando na área de capacidade e desempenho desde 1980 na fabricante inglesa de computadores ICL onde se especializou em testes de modelagem e desempenho.Para esclarecer os termos “capacidade” e “desempenho” (performance) de computador ou cluster. 198 . mas algumas observações e conclusões necessitam ser pontuadas. que seria cerca de 200 milhas (370 km). viabilidade técnica e considerações finais sobre a pesquisa. Michael Ley é atualmente membro do Comitê Executivo do CGM do Reino Unido. Posteriormente ele trabalhou para o BACS (Serviço de nacional de transferência eletrônica de fundos no Reino Unido) onde se tornou Gerente de Capacidade. Dividiremos em três tópicos: viabilidade econômica. seguem as definições de Michael Ley21 (LEY. concluímos que a própria literatura sobre o tema pode levar a uma expectativa equivocada de que um cluster sempre proverá um ganho de desempenho. tendo por anos apresentado matérias sobre modelagem e processos. Hoje ele trabalha num dos maiores bancos da cidade de Londres. Ele nos dá alguns exemplos de sua rotina no Reino Unido para ilustrar os conceitos: Desempenho é tempo que se leva para dirigir de Londres para a casa da família no País de Gales.

seleção e agregação dinâmica de recursos autônomos geograficamente distribuídos. porém apresentaremos novamente uma breve descrição dessas tecnologias para facilitar a comparação.. Ele também serve como fundador e presidente da Manjrasoft Pty Ltd. Austrália. cluster é um tipo de sistema paralelo e distribuído. mas que são indispensáveis para analisarmos a viabilidade econômica da utilização de clusters em geral e o cluster construído para a realização dessa pesquisa em particular. Buyya define grid como um tipo de sistema paralelo e distribuído que habilita o compartilhamento. 2011). 199 . Segundo Buyya22 (BUYYA.Viabilidade Econômica do Cluster Kerrighed Para iniciarmos essa análise faz-se necessário introduzirmos dois conceitos de computação que não são o tema do nosso trabalho. uma companhia iniciada na Universidade que comercializa inovações em computação em Grid e Cloud. O motivo de introduzirmos esses conceitos seria a impossibilidade de analisarmos em termos econômicos a utilização de tecnologia de cluster sem compará-la as tecnologias de grid e cloud. dependendo assim da disponibilidade. estabelecido através de uma negociação entre o provedor do serviço e o consumidor. pois são plataformas alternativas para realizar uma tarefa computacional que demande uma capacidade de processamento significativa. desempenho. Já abordamos alguns conceitos de grid nessa pesquisa e cluster é o nosso tema principal. capacidade. cloud é um tipo de sistema paralelo e distribuído que consiste de uma coleção de computadores conectados e virtualizados que são dinamicamente disponibilizados e a apresentados como um ou mais recursos de computação unificada baseada em SLA (Service-Level Agreement). que consiste de uma coleção de computadores interconectados operando conjuntamente como um único recurso computacional integrado. Esses temas são computação em grid e a computação em cloud. Segundo Buyya et al. 22 Rajkumar Buyya é professor de Ciência da Computação e Engenharia de Software e diretor do laboratório CLOUS (Cloud Computing and Distributed Systems) na Universidade de Melbourne. custo e requerimentos de qualidade de serviço desse sistema para que o mesmo seja utilizado.

pois ao se adquirir um recurso computacional via cloud.Em um artigo Buyya (BUYYA. Atribuímos esse comportamento a dois fatores. em teoria. 2011) e colaboradores sugerem analisarmos a tendência de busca através da WEB sobre essas três tecnologias. pronto para o uso. Segue o gráfico: Gráfico 10 Podemos observar claramente no gráfico a supremacia da computação em cloud em comparação ao cluster e grid no que tange à pesquisa sobre o assunto e também a publicação de novos conteúdos sobre tema na WEB. a contratação de um recurso computacional por um valor mensal seria mais barato do que se implantar um cluster ou mesmo um sistema de grid. primeiro o financeiro. 200 . nesse caso analisamos apenas os acessos realizados no Brasil. que por ser mais recente terá naturalmente mais pessoas buscando informação sobre a mesma. O segundo fator seria o técnico. pois a primeira vista. Vale ressaltar também que o acesso a informações referentes à computação em cloud não significa necessariamente a adoção efetiva da tecnologia. o sistema viria.

2 KVA Total Quantidade Valor Unitário 2 1 2 1 1 R$ 999.00 R$ 689.00 R$ 689. Nessa análise. Seguem os valores: Item Computador Switch Placas de Rede Chaveador de Servidor No-break 1. de modo geral. não considerando o switch Catalyst 3750E utilizado nas experimentações por ser um equipamento do líder de mercado que o torna não ideal para a nossa proposta de uma tecnologia acessível no aspecto financeiro.Segue alguns valores médios para analisarmos financeiramente. sem custos compatíveis para serem comparados nessa análise financeira.00.998.00 R$ 275.00 R$ 169. Serão apresentados alguns custos para a utilização de clusters e computação em cloud.00 R$ 59.00 R$ 275.249. usualmente para implementação de sistemas de médio e grande porte. Consideramos assim nessa precificação um switch de fabricação nacional com as mesmas funcionalidades necessárias para a montagem do cluster. mas como o uso de grid está muito restrito à pesquisa científica e utilização acadêmica com subsídios e investimentos públicos e privados.250. O custo para a implementação do sistema de cluster utilizado em nosso laboratório foi em torno de R$ 3. pois a maioria de seus projetos envolve a computação voluntária tornando a análise financeira dessa modalidade de computação inviável para os fins pretendidos.60 Tabela 2 201 . Temos ciência que qualquer solução tecnológica possui um custo de implantação e manutenção.00 R$ 118.00 R$ 169. A título de registro temos iniciativas de computação em grid no Brasil como o BOINC (Berkeley Open Infrastructure for Network Computing). não incluiremos a computação em grid.60 Valor Total R$ 1. Consideramos assim a computação em grid.60 R$ 3.

2 GHz 3 GBytes de Memória 10 Mbits de banda disponível 50 Gbytes de Disco Rígido Seguem os valores mensais: Item Contratação do Serviço de Cloud Contratação de acesso Banda Larga de 10 Mbps Valor R$ 589. assim a configuração de hardware que mais se aproximou das características do cluster utilizado nesse trabalho foi a que segue: 4 Core de Processador de 1.00 Total R$ 658.011.00 R$ 69. Salientamos que o serviço considerado caracteriza-se.Para fins de comparação consideramos a contratação de um serviço de computação em cloud de um provedor de serviços de Internet dentre os maiores do Brasil. a nosso ver. No provedor analisado não é permitido se escolher exatamente as características do servidor contratado.574. memória e banda passante (troughtput).00 Tabela 3 Considerando um ano de utilização duas plataformas: Custo do cluster com uma despesa anual de manutenção de 10% sobre o custo total da solução Custo do anual do serviço de cloud considerando um valor promocional nos 3 primeiros meses R$ 3.00 Tabela 4 202 .56 R$ 7. armazenamento. como um IaaS (Infrastructure as a Service). ficando ao encargo do cliente a instalação e customização de aplicativos e sistemas. pois o produto é apenas servidores com certa capacidade de processamento.

nos abstraindo de questões e abordagens mais profundas do tema. Em relação do cluster Kerrighed seguem alguns pontos que poderiam ser aprimorados ou analisados mais profundamente: Instabilidade ao utilizar ferramentas de monitoração e medição dos recursos do cluster. ao utilizar-se essas ferramentas. quando confrontado à contratação de um serviço de computação em cloud. Diante dessa análise financeira pontual podemos dizer que a implementação de um cluster nos moldes do que foi apresentado nesse trabalho é viável em termos financeiros mesmo considerando o ritmo acelerado da obsolescência do hardware de recursos computacionais em geral. as características e custo dos profissionais que atuarão com as duas tecnologias (computação de cluster e computação em cloud). o manuseio de memória e processos. o mesmo entrava num estado de travamento.Salientamos que o nosso objetivo nessa análise contempla apenas viabilidade econômica do cluster implementado. O comando para desligar os nós do cluster “krgadm cluster poweroff” não desliga os nós. Viabilidade Técnica do cluster Kerrighed Após a pesquisa e experimentações para elaborarmos esse trabalho. mas os reinicia. sendo necessário reiniciá-lo. como por exemplo. Os usuários dos mesmos precisarão ter ciência das particularidades e limitações de alguns recursos. como o próprio hardinfo. num ambiente de cluster de médio a grande porte. dentre outros temas. a nosso ver. como os custos fixos para a manutenção de um cluster. vmstat e top. a taxa real de banda passante de um acesso banda larga. Dessa maneira. 203 . podemos afirmar que um cluster não pode ser considerado como uma única entidade computacional exatamente como um computador multiprocessado. que é o foco desse trabalho. Alcançamos em cinco meses o ROI (Retorno de Investimento) do cluster implementado. Ocasionalmente quando o cluster estava numa condição de estresse. será necessário ter-se um administrador dedicado integralmente à gerência e manutenção desse cluster.

mostraram-se muito promissores e interessantes. Como explicamos. O tempo de resposta de tela é usualmente maior num ambiente cloud caso não se tenha um acesso a Internet com uma velocidade considerável. Fazendo uma comparação em termos operacionais e técnicos entre o uso de cluster ou computação em cloud. Existem scripts em Linux que facilitam a implementação e configuração de cluster em lote e ferramentas ainda em desenvolvimento para a monitoração dos componentes do Kerrighed. esses valores foram obtidos por extrapolação e não por testes de estresse. vemos como ponto chave o acesso à interface gráfica nos dois ambientes. cuja qualidade da imagem é usualmente inferior a que é gerada diretamente na interface gráfica do servidor. Tanto as imagens como os vídeos poderiam ser executados remotamente ou transferidos e executados localmente. 204 . Apesar das deficiências acima serem importantes. Consideramos os nós com as mesmas características de hardware nessa hipótese. tivemos um aumento de 100% da capacidade computacional do cluster em relação ao computador standalone. Bitmap e outros. Essas deficiências foram constatadas empiricamente ao utilizarmos um serviço de computação em cloud para podermos ter um contato real com a tecnologia. Ao analisarmos os valores de utilização de recursos de memória e processamento nos testes realizados com o Breve. assim como salvar os vídeos gerados pelo Breve em MPEG e desse para outros formatos. No início desse trabalho foi estabelecida uma hipótese que cada novo nó do cluster agregaria 80% da capacidade computacional ao mesmo. elas não impediram em nenhum nível a realização dos testes propostos e necessários para a concretização desse trabalho. no ambiente de cloud teremos que utilizar e customizar a controladora de vídeo fornecida pelo provedor. a nosso ver. porém mesmo assim. Existem também clusters Kerrighed monitorados pela ferramenta de uso geral Ganglia que é um software de monitoramento para HPC (High Performance Computing). além de acessar a interface gráfica do recurso computacional através de ferramentas de VNC (Virtual Network Computing). pois poderíamos salvar as imagens geradas pelo PovRay em formatos padrão como JPEG. na apresentação dos testes com o Breve.O Kerrighed não possui uma ferramenta gráfica nativa para o monitoramento e configuração do cluster. porém não seriam totalmente proibitivas para a utilização da computação em cloud para renderização de imagens ou execução de simulações gráficas de IA.

onde coloca que a especulação e a experimentação devem seguir juntas no caminho da pesquisa em Computação. Seguem as constatações e análise. Por fim. Podemos assim afirmar empiricamente que o cluster Kerrighed é viável em termos técnicos para suportar a instalação e execução das aplicações PovRay e Breve. Gonzalo Génova23 em seu artigo “Is Computer Science Truly Scientific?” no periódico “Communications” de julho de 2010 da ACM (Association for Computing Machinery). nessa seção serão apresentadas de maneira mais sistemática essas constatações. análises e pareceres sobre o tema central da pesquisa que é uma análise de natureza empírica da viabilidade da utilização de cluster para a execução aplicações HPC. O dispositivo de probe padrão do Kerrighed fornece mecanismos satisfatórios de migração baseados em métricas pré-determinadas. 23 Professor de Engenharia de Software da Universidade Carlos III de Madrid na Espanha. salvo nas situações de teste de estresse quando testamos a capacidade limite do cluster através da execução concorrente de várias instâncias dessas aplicações. Dessa forma. após devidamente instaladas as aplicações PovRay e Breve foram executadas no cluster exaustivamente sem apresentar nenhum problema. o tema da validade da experimentação e do método de indutivo de análise na ciência da computação. segundo o nosso juízo. apresentou uma visão muito interessante do assunto. 205 .Um aspecto técnico crucial num ambiente de cluster seria a capacidade de migração de processos. como Turing (Teoria da Computação). porém um processo pode ser manualmente migrado de um nó para outro a qualquer momento. Dijkstra (Teoria da Programação e Algoritmos). Considerações Finais Embora ao longo do trabalho já tenhamos apresentado resultados. Neumann (Arquitetura dos Computadores). citando exemplos de grandes personalidades nessa área que tiveram seus trabalhos iniciados no campo do raciocínio. acreditamos ser importante retomar nesse ponto. funcionalidade essa que apresentou ótimos resultados durante os testes de laboratório. mas também na análise e interpretação desses resultados. Antes de apresentarmos essas argumentações. as considerações aqui apresentadas serão baseadas apenas nos resultados obtidos e devidamente mensurados. dentre outros.

o implantado na Faculdade do Senac em Pelotas outro localizado no Rio de Janeiro. preservação de processos mesmo com a indisponibilidade de algum nó. pois aplicações que executadas são grande utilidade para a sociedade e para a comunidade científica. pois proverá um sistema único e com alta disponibilidade para a execução de várias instâncias das aplicações ao mesmo tempo. A tecnologia de cluster é viável em termos financeiros em comparação a computação em cloud pelos seguintes motivos: Uma análise financeira dentro do universo do nosso laboratório demonstrou essa viabilidade. apresentando soluções inteligentes para aspectos críticos no processamento em cluster. Os clusters podem ser heterogêneos e inclusive compostos de computadores utilizados em sistemas legados. o cluster Kerrighed mostrou-se eficiente.Tecnologia de Cluster em geral como uma alternativa viável para execução de aplicações de HPC de médio porte. como o gerenciamento de memória. Pode-se verificar o registro desses clusters implementados no Brasil através do link http://kerrighed. através de dispositivos de checkpoint. migração de threads. 206 . dentre outras funcionalidades. Cluster Kerrighed como uma alternativa viável para execução de aplicações HPC de médio porte.org/php/clusterslist. A tecnologia de Cluster em geral é adequada e viável para aplicações de processamento massivo pela capacidade de processamento para aplicações monoprocessadas e pela melhoria de desempenho para aplicações com processamento paralelo.php. Apesar de desconhecido pela comunidade tecnológica e científica do Brasil. dando usuário final a impressão de estar atuando em um único recurso computacional de alta capacidade. pelo menos formalmente. A relação custo-benefício de clusters HPC é usualmente favorável. Mesmo para aplicações monoprocessadas um sistema cluster será viável. pois temos apenas três clusters no nosso país registrados no site oficial do Kerrighed.

De fato temos no mercado americano um grande provedor de serviços de computação em cloud oferecendo serviços de HPC. Uma significativa deficiência de desempenho surge onde latência e largura de banda estão de uma a duas ordens de magnitude inferiores a um computador de porte. Constantinos Evangelinos (EVANGELINOS. atendendo assim às necessidades de processamento para área científica e acadêmica ao prover plataformas que suportam processamento paralelo real. estamos contemplando um sistema computacional com hardware. apesar de termos serviços HPC em computação em cloud já disponíveis. entretanto a performance é comparável com sistemas de clusters de baixo custo. Os pesquisadores do departamento de Ciências da Terra. Em suma. os resultados são encorajadores. que é a natureza da computação de aplicações de Inteligência Artificial e Design Digital. Tecnologias e aplicação de Computação em Cluster e Computação em Cloud Quando abordamos HPC e processamento massivo. a computação em cloud ainda não atende em sua plenitude às necessidades das aplicações HPC de grande porte. 2008) realizaram testes de benchmark utilizando os serviços de HPC em cloud desse grande provedor norte americano mencionado acima. consideramos uma tarefa árdua para esses provedores adaptar a sua infraestrutura para as necessidades e particularidades de cada um desses clientes de HPC. GPU (Graphics Processing Unit). sistema operacional e aplicações específicas para um uso restrito desses recursos. 207 . É possível vislumbrar sistemas em cloud mais próximos dos objetivos das aplicações de HPC. temos um provedor de serviços de cluster remoto que oferece hardware dedicado para cada cliente. Entretanto. Por outro lado. 2008) e Chris N. apesar dos avanços significativos. Atmosféricas e Planetárias do MIT. Após os devidos ajustes e configurações o cluster Kerrighed mostrou-se estável mesmo quando atuou no limite de sua capacidade computacional. Hill (HILL. dúvidas e problemas de implementação ou manutenção do sistema.A comunidade envolvida no projeto do Kerrighed está sempre disponível para discutir e compartilhar informações referentes a funcionalidades. utilizando tecnologias como Myrinet e Infiniband”. Dessa forma. Segue algumas considerações dos mesmos: “O desempenho está abaixo do visto em centros de supercomputadores dedicados. porém esses serviços são fornecidos em servidores virtualizados que até então não conseguem prover um desempenho equivalente ao das aplicações executadas diretamente no hardware de um computador multinúcleo ou em cluster. conexões de rede com alta velocidade e baixa latência utilizando o padrão Infiniband.

nenhum provedor de computação em cloud que forneça HPC. acessando outros servidores através da estrutura da virtualização. O acesso ao portal WEB para a utilização do serviço requer apenas uma senha de acesso associada ao e-mail fornecido na contratação. dentre outros. Outra questão importante no que tange ao acesso desses serviços via Internet é a Segurança da Informação. porém um hacker teria mais dificuldade em ter acesso completo ao um servidor virtualizado num Data Center privado do que num provedor de serviço de cloud. Após acessar o portal. que pode ser um celular. Como o modelo que estamos utilizando como contraponto a computação em cluster seria o IaaS (Infrastructure as a Service). perpetradores de ataques em serviços de Tecnologia de Informação utilizam esses recursos computacionais como base para realização dos mais diversos ataques como Botnets. Esses ataques poderiam com certeza ser também realizados em um Data Center privado. Ressaltando que não temos no Brasil. e-mail e em alguns casos um telefone. que realizou uma verificação da existência de um usuário real através de uma ligação telefônica e durante o processo de contratação do serviço proveu um arquivo para a geração de chaves públicas RSA para acesso SSH. rainbow tables e solucionadores de CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart). a saber. Contratamos também o serviço de cloud de um provedor norte americano. apresentaremos de forma pontual algumas questões referentes à Segurança para essa modalidade de computação em cloud. mostrando um processo muito mais seguro e confiável do fornecimento de acesso ao seu serviço. mas teríamos a necessidade de fazer todas as tratativas de contratação e suporte na língua nativa desses provedores. Pela facilidade de contratação desse serviço. necessitando apenas um número de cartão de crédito. com provedores fornecendo utilização sem custo para avaliação. ataques ao próprio serviço de cloud. porém remoto. computação em cluster com hardware dedicado. Obviamente que poderíamos contratar esse serviço de provedores de outros países. DDoS (Distributed Denial of Service). descoberta indevida de senhas e chaves. 208 . computação em cluster com hardware local. até esse momento. oferecido como serviço e computação em cloud. foi provido o endereço IP do servidor virtual e pudemos acessar o mesmo via SSH (Secure Shell) com a possibilidade do uso do usuário root. Contratamos o serviço de cloud de um provedor no Brasil e nos foi solicitado apenas um e-mail e um número de cartão de crédito.Assim temos três alternativas para HPC.

redes de alta velocidade e baixa latência e virtualização. 24 Neil MacDonald é um vice presidente e destacado analista e associado na Consultoria Gartner. a quantidade de pessoas a serem supervisionadas e recursos a serem protegidos é significativa. mas sim a qualquer computador na rede que tenha alguma conectividade com esses recursos. Dois são de baixa severidade. Uma invasão é o caso de ‘quando’ e não de ‘se’".software escrito por seres humanos e que tem vulnerabilidades. focado em Sistemas Operacionais e Estratégias de Segurança em nível de Aplicação. Ele é um membro da equipe de Segurança da Informação e Pesquisa sobre o tema de Privacidade em TI. Dessa forma. Quando mencionamos “dependências” não seria o acesso físico às salas cofres onde os equipamentos estão instalados. Para corroborar com essa previsão do especialista Neil MacDonald apresentaremos algumas vulnerabilidades e exposições apresentadas pela National Vulnerability Database. pois apesar das políticas severas de segurança que devem ser aplicadas nos mesmos. locado em Stamford. Podemos dizer que base tecnológica dos Data Centers de computação em cloud seria servidores com alta capacidade de processamento. Connecticut. a Segurança da Informação em computação em cloud está muito ligada aos ataques e mitigações nos ambientes virtualizados. Neil MacDonald24 (MACDONALD. Os malfeitores são inteligentes e têm motivação financeira para atacar essa camada. Vinte são de média severidade. onde: Dez são de alta severidade. 2009) da empresa de Consultoria e Pesquisa Gartner colocou em 2009 “A camada de virtualização entre o sistema operacional e o hardware é extremamente sensível. Essa camada é um software .Além das questões citadas temos outras ameaças como o próprio acesso indevido aos servidores físicos e virtualizados nas dependências dos provedores de serviço de cloud. Da empresa líder de mercado em virtualização temos 32 registros de 2005 até o momento. 209 .

5.x antes da versão 6. quando em conjunção como as ferramentas VMWare na plataforma VMWare permite a agressores causar um “denial of service” (corrupção da memória) e possivelmente a execução de um código arbitrário via vetores não especificados.x antes da release 10. Publicado em 15/06/2010 CVSS (Common Vulnerability Scoring System) Severidade: 9.3 (Alta) CVE-2009-2628 VU#444513 O codec VMnc no arquivo vmnc.12610.277.0 e na versão 10.0.0.2.3 (Alta) 210 . Publicado em 08/09/2009 CVSS (Common Vulnerability Scoring System) Severidade: 9.5.3 build 185404.dll do VMware Movie Decoder antes da versão 6.Seguem a descrição de algumas dessas ocorrências a título de ilustração e registro: CVE-2010-2189 TA10-162A O Adobe Flash Player antes da release 9.x antes da versão 2.x antes da versão 2.5.5.3 build 185404. do VMware Workstation 6.5. do VMware Player 2.1.64 e o Adobe AIR antes da versão 2.5.3 build 185404 no ambiente do Sistema Operacional Windows não manipula apropriadamente os conteúdos de vídeo de baixa altura.3 build 185404 e do VMware ACE 2. os quais podem permitir agressores remotos executarem códigos arbitrários via um arquivo AVI manipulado que pode provocar uma corrupção de pilha de memória.5.53.

0.5.1 e anteriores.x build 156745 permite que usuários locais obtenham privilégios através de vetores desconhecidos Publicado em 06/04/2009 CVSS (Common Vulnerability Scoring System) Severidade: 7.1 e anteriores. no VMware ACE 2. 211 .5. Com certeza sistemas privados de computação também estão sujeitos a ataques e invasões.5.x antes da versão 2. mas nesse caso a responsabilidade pelas políticas e providências no que tange à Segurança da Informação recai sobre o detentor desses dados e não sobre a responsabilidade de terceiros.5.1 e anteriores e no VMware Server antes da versão 2. Publicado em 06/04/2009 CVSS (Common Vulnerability Scoring System) Severidade: 9.2 (Alta) Esses registros mostram vulnerabilidades já identificadas e corrigidas. mas não é possível dizer que esse sistema de virtualização de computadores não possui outras vulnerabilidades ainda não descobertas ou não divulgadas.5. também conhecido como ZDI-CVE-435.0.sys na Virtual Machine Communication Interface (VMCI) na VMware Workstation 6.x antes da versão 2.5.5.5.x antes da versão 2. no VMware Player 2.3 (Alta) CVE-2009-1147 Vulnerabilidade não especificada no arquivo vmci.2 build 156735 e no VMware Server 2.5.x antes da versão 6. no VMware Player 2.CVE-2009-0909 Estouro de buffer de pilha no Codec VNnc Codec na VMware Workstation 6.2 build 156735. no VMware ACE 2.2 build 156735. permite que agressores executem códigos arbitrários via página WEB ou arquivo de vídeo manipulados.1 build 156745.

em tese. por terem mais recursos financeiros para investir em produtos além de profissionais especialistas nessa disciplina. As organizações estão preocupadas com segurança e privacidade no que tange ao uso de serviços de computação em cloud na medida em que o mercado oferece uma garantia marginal nessas disciplinas. 2011) também afirma que em 2012. cremos que ainda há necessidade de mais maturidade nesse quesito no que tange à computação em cloud que demandará pesquisa. em termos de capacidade de processamento massivo e Segurança da Informação. Alinhar os requerimentos internos de segurança com as medidas e controles dos provedores desse serviço tem-se provado difícil na prática. privacidade e temas legais. 60% dos servidores virtualizados estarão menos seguros que os servidores tradicionais que eles substituíram. falta de percebimento e expertise insuficiente”. Apesar dos provedores de computação em cloud possuírem. Segue a declaração da mesma em seu documento “From Hype to Future”: “Segurança é o principal obstáculo encontrado quando da implementação de computação em cloud. 2010) também afirma que o principal obstáculo para a adoção e implementação de computação em cloud é a Segurança da Informação. uma maior competência em segurança. seguida das questões de conformidades. ao fazermos uma comparação entre as tecnologias de Clouding e Clustering. A empresa de consultoria KPMG (CHUNG. devido às discrepâncias. 212 .A empresa de consultoria e pesquisa Gartner (MACDONALD. também concluímos que nesse momento a utilização de computação em cluster seria mais viável no cenário apresentado nesse trabalho que seria uma plataforma com uma alta capacidade de processamento para aplicações como HPC com ênfase em Inteligência Artificial e Design Digital. Pelos argumentos e informações apresentadas podemos dizer que além da questão financeira. tempo e experiência.

Travis como Kitcat. 213 . com 854 Gigabytes de memória e 21 Terabytes de disco rígido. para o processamento de aplicações e sistemas relacionados à Nutrigenômica. A.Um olhar para o presente e um olhar para o futuro da Tecnologia de Cluster Um olhar para o presente Abordaremos nessa parte dois projetos. O Brasil possui uma Rede Brasileira de Nutrigenômica tendo como principais colaboradores a USP. A organização brasileira possui algum intercâmbio com a NUGO (Nutrigenomics Organization) que patrocina o NBX (Nugo Black Box) que é o cluster Kerrighed apresentado nessa etapa do trabalho e chamado pelo Dr. Através da introdução de novas ferramentas moleculares nos estudos clássicos de nutrição.0 do Instituto de Tecnologia de Tóquio que ocupa a quinta posição do site TOP500 Supercomputers. utilizando o software Onesis para criar um sistema de arquivos comum para todos os nós do cluster. porém devido às características políticas desse país. a busca de informações foi infrutífera.Capítulo 6 . O primeiro de um cluster Kerrighed implantado e mantido pelo Dr. Kitcat na Universidade de Aberdeen A Nutrigenômica representa o estudo da interação entre o genoma e nutrição. a UNESP e a FEPAF (Fundação de Estudos e Pesquisas Agrícolas e Florestais). essa nova ciência multidisciplinar e integrada almeja a compreensão de como a dieta influencia o genoma e consequentemente a saúde e também como a variação genética influencia a resposta às dietas. o segundo será o cluster “não Kerrighed” chamado TSUBAME 2. Temos um cluster da China na quarta posição no raking do TOP500. Travis da Universidade de Aberdeen no Reino Unido para o Instituto Rowett de Nutrição e Saúde. Atualmente esse cluster possui 61 nós com 202 processadores de 64 bits. A rede que suporta esse cluster é composta de 10 switches Catalyst 2970 onde o tráfego da aplicação é separado do tráfego do sistema para caso houver uma saturação da banda na rede da aplicação não venha comprometer o desempenho do sistema. J.

168.0/24 Aplicação: 192.0 do Instituto de Tecnologia de Tóquio O TSUBAME 2.234.ac. As conexões de rede são realizadas através da tecnologia Infiniband. Os Sistemas Operacionais utilizados são SUSE Linux Enterprise Server e Windows HPC Server 2008 R2 atuando em regime de “batch” alocando dinamicamente mais nós aos processos na medida em que forem necessários através do sistema PBS (Portable Batch System) que é um produto de mercado para alocação de recursos em ambientes HPC.9 Tbytes de memória RAM e uma capacidade de armazenagem de 11 Pbytes.Seguem o endereçamento IP do cluster: Sistema Operacional: 192.uk/ganglia TSUBAME 2.264 GPU's (Graphic Processor Unit) provendo uma capacidade de processamento de 2.442 nós com 2.852 processadores tradicionais e 4.rri.0 que significa “engolir” em japonês é um cluster composto de 1.sari.32. utilizando os seguintes equipamentos: Switches Core: 12 Voltaire Grid Director 4700 Switches de Borda: 179 Voltaire Grid Director 4036 6 Voltaire Grid Director 4036e 214 .168.0/20 O cluster é gerenciado pela ferramenta de monitoramento Ganglia que pode ser acessada através da seguinte URL: http://bioinformatics.1.0.420 Teraflops com 103.0/24 Rede Local: 143.

0: Novos algoritmos para processamento gráfico Aplicações HPC em larga escala utilizando GPU Desenvolvimentos de esquemas de alta acuidade numérica para dinâmica de fluídos Visualizações em alta escala e em alta qualidade Seguem algumas áreas em que o TSUBAME 2.Seguem algumas aplicações que são executadas no TSUBAME 2.0 é utilizado: Predição numérica do tempo Simulação em alta escala para fluxo multifásico Simulação da turbulência nas ondas Large-Eddy Estudo sobre a interação das estruturas dos fluídos Simulação de Tsunami 215 .0: ABAQUS Discovery Studio Mathematica MATLAB PGI Compiler Intel Compiler Seguem algumas atividades computacionais realizadas pelo TSUBAME 2.

Embora numa condição de interrupção e redefinições técnicas e financeiras. Seguem as especificações técnicas principais do Power 7: 216 . que possibilita a viabilização de clusters SSI que são mais acessíveis em termos de interface ao usuário final do sistema. O processador utilizado no projeto original do Blue Waters apresenta características que contribuem para o processamento massivo e paralelo. uma das mais importantes seria o desenvolvimento de uma tabela de paginação e endereçamento de memória de modo a ter uma memória compartilhada distribuída (DSM).Um olhar para o futuro Apesar de ser um projeto inacabado cluster Blue Waters que tem como objetivo alcançar processamento em nível de Petaflops (1015 flops) apresenta-se como um empreendimento tecnológico e uma infraestrutura de computação massiva contínua que sinaliza uma nova abordagem de computação capaz de atingir níveis de capacidade e desempenho até então não obtidos. tema já abordado nesse trabalho. o projeto apresenta muitas funcionalidades e abordagens que contribuirão para o desenvolvimento de HPC em níveis mais elevados dos que estão em atividade nesse momento. Seguem as mais significativas: Processador Power 7. utilizando o Power 7 como base do seu projeto de cluster apresentado em sua proposta. seriam a quantidade efetiva de núcleos que podem chegar até oito por processador. parceria essa encerrada em 08/08/2011. a capacidade de processamento simultâneo de threads conhecida como SMT (Simultaneous Multithreading) que seria 4 por núcleo totalizando 32 threads simultâneas e o próprio projeto de arquitetura do microprocessador focado na otimização da potência elétrica utilizada pelo mesmo. A idealizadora desse processador é a IBM que em 2006 foi vencedora de um contrato da DARPA (Defense Advanced Research Projects Agency). O projeto é financiado e apoiado pela NSF (National Science Foundation) e pela Universidade de Illinois que iniciaram parceria com a IBM. Dentre as várias funcionalidades estabelecidas. Outras características que fazem um Power 7 um dos processadores mais poderosos da atualidade já oferecido em escala comercial.

Conexão entre o nó local e nó remoto no mesmo supernode. 320 Gigabit/Sec .4 GHz a 4.25 GHz Tamanho mínimo de transistor: 45 nm Micro-arquitetura: Power ISA v. Para que se possa usufruir da capacidade e desempenho de clusters do porte do projeto Blue Waters.06 Núcleos: 4.2. fazem-se necessárias linguagens e ferramentas de desenvolvimento. programação e compilação compatíveis com as demandas do processamento paralelo e massivo.Máxima de velocidade de clock: 2.Conexões internas de cada nó 336 Gigabit/Sec . 240 Gigabit/Sec . Não foi possível levantar qual tecnologia de rede foi utilizada para a conexão entre os componentes do cluster.Conexão entre nós remotos 40 Gigabit/Sec . Um supernode é composto por 4 chassis. 217 .Conexão de E/S de uso geral Desenvolvimento de programas e aplicações. apenas a velocidade das conexões: 192 Gigabit/Sec .Conexão entre os nós no mesmo chassi. Temos dois principais desafios quando abordamos o desenvolvimento de aplicações na ordem de PetaFlops que seriam a programação em computação paralela e o refinamento automático das aplicações para diferentes ambientes e uso (autotunning). 6 ou 8 Cache L1: 32+32 KB por núcleo Cache L2: 256 KB por núcleo Cache L3: 32 MB Largura de banda nas interconexões do cluster.

218 . aplicações e bibliotecas para processamento paralelo e massivo de uso corrente como OpenMP. pois necessita de novas abordagens e padrões de desenvolvimento e expertise. pelos breves estudos de caso apresentados nesse capítulo podemos concluir que a tecnologia de cluster HPC está em franco desenvolvimento. Consideramos o desenvolvimento de compiladores e códigos compatíveis com o HPC um maior desafio do que a construção de uma infraestrutura de hardware que suporte o processamento de PetaFlops contínuo. conceituais e tecnológicos a serem sobrepujados. aplicações. X10 e Fortress. A segunda frente seria a utilização de novas linguagens de programação para HPC como a Chapel. A primeira frente seria a utilização e o refinamento de linguagens. SHMEM. redes de computadores. Conclusão do capítulo Apesar de termos um avanço significativo no desenvolvimento de computadores. Quanto ao autotunning. UPC e o CAF no Fortran 2008. sendo uma das tecnologias computacionais que mais contribuirá para o desenvolvimento das principais áreas de pesquisa que trarão benefícios à humanidade em nossos tempos. compiladores e especialmente sistemas em cluster para atender esse segmento da Tecnologia da Informação. promoverão uma maior interação com os programadores para facilitar as mudanças dos códigos e focarão no desenvolvimento códigos baseados em vetores. que produziria pelo menos duas versões de códigos distintas. Em longo prazo. dentre outras medidas.Em relação ao primeiro desafio os idealizadores do Blue Waters visualizam duas frentes de trabalho. MPI. ainda temos muitos desafios estruturais. eles trabalharão diretamente com os provedores dos compiladores para fomentar melhorias. sistemas operacionais. para aplicá-los adequadamente no desenvolvimento de códigos. em curto prazo o projeto trabalhará na substituição dos códigos atuais por códigos que utilizam o autotunning. porém.

HILL. Ali E. John H. MISRA. USA: Computing Surveys.html Acesso em 04 nov. John. GROPP. COMMUNICATIONS of the ACM. Comunidade Beowulf. volume 57. on Computers.. KPMG’s 2010 Cloud Computing Survey. L.beowulf. Cyrus. DIJKSTRA. 144-156. M.. EVANGELINOS. volume 3. 1977. and reality for delivering computing as the 5th utility. Eduard G. M. HAAS.M. CHANDY. mai. p. et al: Cloud Computing: Principles and Paradigms. Atmospheric and Planetary Sciences. 2008. 2010. E. jul. Disponível em http://www. New York: ACM Trans. 1993. Michael. CHANDY. The Drinking Philosophers Problem. Streaming Media Server Design.. Netherlands. et al: Systems Deadlocks. BUYYA. p. ZIMMERMANN. USA. 1984. Constantinos. 2011. on Computer System. HOWARD JR. USA. Germany. MISRA. BUYYA. 2009. HERMANS. Ed Prentice Hall. set. New York: ACM. MIT. Moshe. Rajkumar. K. CHUNG. John Wiley & Sons. W. de 2010. 1972. J... 2003. 2003..Referências: BAR.: Some Computer Organizations and Their Effectiveness. Distributed Deadlock Detection. volume 1. et al: OpenMosix. M. K. Hierarchical ordering of sequential processes. 10th IEEE ACM International Conference on Cluster Cloud and Grid Computing. 112 p. 2011. University of Texas. DASHTI. COFFMAN. J. 1972. 219 . University of Texas at Austin..org/showcase/index. E. Mathematisch Centrum Eindhoven University of Technology. The mathematics behind the Banker’s Algorithm. 2010. W. Roger. n° 53. Cloud Computing for parallel Scientific HPC Applications: Feasibility of running Coupled Atmosphere-Ocean Climate Models on Amazon’s EC2. USA. From Hype to Future. USA: IEEE Trans. Rajkumar. volume C-21. et al: Cloud computing and emerging IT platforms: Vision. Netherlands. Department of Earth. 1971. FLYNN. William D: Enabling the Next Generation of Scalable Clusters. Mathematisch Centrum Eindhoven University of Technology. USA. junho de 1971. DIJKSTRA..: Mixed Solutions for Deadlock Problem. 948-960. SHAHABI. J. Future Generation Computer Systems. n° 2. hype. Linux-Kongress. Chris N.

codeproject.aspx#Introduction0 IPTV Subscribers to Number 60 Million by 2011. Gartner Says 60 Percent of Virtualized Servers Will Be Less Secure Than the Physical Servers They Replace Through 2012. Weijia. MACDONALD.cmg. 2011.com/KB/IP/rpcintro1.org/measureit/issues/mit55/m_55_4. Introduction to RPC. São Paulo: Ed Nova Cultural. et al: Distributed Multimedia System Design: A Holistic Perspective.: Scheduling Techniques for Concurrent Systems. 2005. USA. IEEE International Conference on Distributed Computing Systems. 2009. J..com/television/iptv-subscribers-to-number-60-million-by-2011484/ Acesso em 26 mar. Watson Research. JIA. 2002. IBM T. 2012. Korea. Os Pensadores. USA. India. Disponível em: Acesso em 24 mar. Michael. et al: MPIRace-Check: Detection of Message Races in MPI Programs.html Acesso em 15 ago. OH.HUME. et al: Kerrighed and Data Parallelism: Cluster Computing on Single Image Operating Systems. et al. Radu.marketingcharts. 2007. 1999. 2004. Christodorescu. Immanuel. RK+MOSIX: A Real-time Kernel with Automatic Task Migration Support. 220 . A Estrutura das Revoluções Científicas. 2005.com/it/page. São Paulo: Ed Perspectiva. MigShm: Shared memory over OpenMosix. Distributed Network Systems From Concepts to Implementations. BREVE: a 3D Environment for the Simulation of Decentralized Systems and Artificial Life. Disponível em: http://www. Wanlei. Carnegie Mellon University. Disponível em: http://www. SWEDEN. OUSTERHOUT. Os Pensadores. et al: Cloud Security Is Not (Just) Virtualization Security. MAASK.gartner. Thomas Samuel. David. Chalmers University of Technology and Göteborg University. PARK. LEY. Chonnam National University. MARCULESCU.jsp?id=1322414 Acesso em 08 out. Christine. Puna University. Performance & Other Confusing Terms. Capacity. IEEE International Conference on Cluster Computing. Syracuse University. MIHAI. Ed Springer. 1999. J. KANT. Mi-Young. http://www. MORIN. 1982. 1978. Disponível em: http://www. 2011. KLEIN. Jon. São Paulo: Ed Nova Cultural. 2004. 2012. Neil. KUHN. 2003. K. ZHOU. Jae C. USA.

LEE. 2003. Marcos. RIGHI. Rio de Janeiro: Ed Brasport. Modern Operating Systems – Second Edition. 1998. RIBEIRO. USA. Ruby B. Marcos. PROJETO openMosix. VRENIOS. Ed Prentice Hall.PATIL. Andrew S. 2004. 1994. Belo Horizonte: Ed Itatiaia. Suhas. Brasil. TANENBAUM. Uirá. Ed SAMS. Universidade Federal do Rio Grande do Sul. PRICE. Ed Prentice Hall. High Performance Linux Clusters with OSCAR.: A Case for Hardware Protection of Guest VMs from Compromised Hypervisors in Cloud Computing. Joseph D. Linux Cluster Architecture. A Ciência desde a Babilônia. TANENBAUM. Infiniband: Alta eficiência no tratamento de grandes volumes de dados e na computação numérica de alto desempenho. USA. Gregory F. and MPI. 2009. et al. MIT. 221 .. Derek de Solla. Sistemas Distribuídos.sourceforge. PITANGA. Disponível em: http://openmosix. 1971. SZEFER. 2004. 2004. POPPER. USA. Prentice Hall. OpenMosix. Andrew S. USA. Computação em Cluster. Ed O'Reilly. In Search of Cluster. Distributed Operating Systems. Jakub. 2001. 1976. Construindo Supercomputadores com Linux. Brasília: Ed UNB. 1995. Conjecturas e Refutações. Rocks. Rio de Janeiro: Ed Axcel. Rio de Janeiro: Ed Brasport. 2011. 2005. USA. 2002. Princeton University. PFISTER. PITANGA. SLOAN. Limitations and capabilities of Dijkstra's semaphore primitives for coordination among processes. Karl Raymond. Rodrigo da Rosa.net/ Acesso em 04 nov. USA. USA. Alex.

gerência de linha de execução. Complexidade NP Na teoria da complexidade computacional. Inteligência Artificial. NP é o acrônimo em inglês para Tempo polinomial não determinístico (Non-Deterministic Polynomial time) que denota o conjunto de problemas que são decidíveis em tempo polinomial por uma máquina de Turing não-determinística. Os arrays mantêm uma série de elementos de dados. Esse sistema contrasta com o gerenciamento manual de memória. para simplificar e abstrair o desenvolvimento de jogos ou outras aplicações com gráficos em tempo real. suporte a animação. resultando no esgotamento da memória livre para alocação. alta segurança.GLOSSÁRIO Aging Em redes aging é o tempo que o endereço MAC dos dispositivos se mantém na tabela dos switches que são equipamentos que atuam na camada 2. que se utiliza de um tipo especial de sistema operacional classificado como sistema distribuído. Empresas de grande porte podem e têm o seu próprio Data Center. Engine Programa de computador e/ou conjunto de bibliotecas. um motor de física para simular a física ou simplesmente para fazer detecção de colisão. Data Center Um Data Center é uma modalidade de serviço de valor agregado que oferece recursos de processamento e armazenamento de dados em larga escala para que organizações de qualquer porte e mesmo profissionais liberais possam ter ao seu alcance uma estrutura de grande capacidade e flexibilidade. gerência de arquivos. é formado por um conjunto de computadores. o que pode evitar problemas de vazamento de memória. muitos sistemas usam uma combinação das duas abordagens. em que o programador deve especificar explicitamente quando e quais objetos devem ser deslocados e retornados ao sistema. geralmente do mesmo tamanho e tipo de dados. Entretanto. um array. suporte a 222 . sons. Elementos individuais são acessados por sua posição no array. Com ele é possível recuperar uma área de memória inutilizada por um programa. Array Em programação de computadores. é uma das mais simples estruturas de dados. gerência de memória. ou o acrônimo GC) é um processo usado para a automação do gerenciamento de memória. e igualmente capacitada do ponto de vista de hardware e software para processar e armazenar informações. Uma definição equivalente é o conjunto de problemas que podem ser verificados em tempo polinomial por uma máquina de Turing determinística. Coletor de Lixo Coletor de lixo (em inglês: garbage collector. para videogames e/ou computadores rodando sistemas operacionais. A funcionalidade tipicamente fornecida por um engine inclui: um motor gráfico para renderizar gráficos 2D e/ou 3D. ou aglomerado de computadores. networking. também conhecido como vetor (para arrays unidimensionais) ou matriz (para arrays bidimensionais). Cluster Um cluster. e as cargas usadas são chamadas de benchmark. Benchmarking O processo de comparação do desempenho entre dois ou mais sistemas é chamado de benchmarking.

suporte a uma linguagem de script. Memórias non-ECC são mais comuns. chamado arestas. ou seja. O ECC ajuda a detectar e corrigir certos tipos de erros em transações de memória. Observa-se ainda que uma variação de atraso elevada produz uma recepção não regular dos pacotes. Grafo é uma estrutura G(V. As memórias ECC têm um desempenho um pouco mais baixo devido ao tempo gasto na detecção e correção de erros. A especificação da arquitetura do Infiniband define a conexão entre nós processadores e nós de alto desempenho de E/S como dispositivos de armazenamento. arestas podem ou não ter direção. pode ser definida como a medida de variação do atraso entre os pacotes sucessivos de dados. se eles ocorrerem. baixa latência.000. Grafo com 4 vértices e 6 arestas. pode ser permitido ou não arestas ligarem um vértice a ele próprio e vértices e/ou arestas podem ter um peso (numérico) associado. sendo usado comumente para proteger as redes de tráfego não autorizado ou permitindo tráfego legítimo. Se as arestas têm uma direção associada (indicada por uma seta na representação gráfica) temos um grafo direcionado. Memória non-ECC Há dois tipos de memórias quando falamos de suporte para ECC (Error Correction Code). da mesma forma que os firewalls possuem certas funcionalidades básicas de roteamento. Dependendo da aplicação. qualidade de serviços e alta disponibilidade.000 (10 ) bits por segundo. rápidas e baratas. conexo e planar. Infiniband Infiniband é um padrão de comutação de frames em rede local utilizado para sistemas HPC e grandes Data Centers.000. Roteadores podem também ter funcionalidades de firewall. Um grafo com um único vértice e sem arestas é conhecido como o grafo trivial ou "o ponto".grafos de cena e entidades e. protegendo assim a estação de trabalho ou servidor. Grafo A teoria dos grafos é um ramo da matemática que estuda as relações entre os objetos de um determinado conjunto. Jitter Jitter é uma variação estatística do atraso na entrega de dados em uma rede. Ele também possui uma alta escalabilidade.A) onde V é um conjunto não vazio de objetos denominados vértices e A é um conjunto de pares não ordenados de V. 9 223 . Suas funcionalidades incluem alta vazão (throughput). É um grafo completo. grafo orientado ou dígrafo. Interface gigabit ethernet Conexão de rede que consegue transmitir até 1. Assim há memórias ECC (com suporte para ECC) e nonECC (que não suportam ECC). Firewall Firewall é um dispositivo ou grupo de dispositivos designados a permitir ou negar o tráfego de rede baseado em um grupo de regras. Sistemas Operacionais possuem firewalls baseados em software.

000. A programação é baseada no paradigma de troca de mensagens. PVM PVM é a abreviação de Parallel Virtual Machine. O PVM é composto. sendo muito utilizada na interconexão de clusters de computadores. 224 . gerenciamento de tarefas. desenvolvido pelo grupo Caltech. Pilha Uma pilha é uma das várias estruturas de dados que permitem remoção de elementos e inserção de novos elementos. Parlog86 Lógica de programação da família do Prolog desenvolvida pela Imperial College em Londres com funcionalidades de programação concorrente para sistemas de processamento paralelo. Pesquisas efetuadas mostram que a Myrinet é tecnologia de rede com melhor desempenho em clusters com mais de 32 nós. Overhead Uso adicional de recursos computacionais e/ou de rede para realizar determinada tarefa. Rede de computadores Conjunto de equipamentos e cabeamento que provê a transmissão de dados entre computadores.000. trazendo a tecnologia Myrinet para o mercado. Este é um pacote de software que permite que uma rede heterogênea de computadores de todos os tipos seja programada como se fosse apenas uma única "Máquina Paralela Virtual". uma pilha é uma estrutura sujeita à seguinte regra de operação: sempre que houver uma remoção.Myrinet Myrinet é uma tecnologia de rede local desenvolvida pela empresa Myricon. Traffic Shaping Técnica utilizada em redes para priorizar certos tipos de tráfego de natureza mais crítica ou sensível a atrasos.. o primeiro objeto a ser inserido na pilha é o último a ser removido. etc. um processo daemon que rodará em cada host participante da MV e um console de onde podem ser executadas algumas funções básicas de controle (configuração da MV. basicamente. composto usualmente de um agrupamento de discos rígidos. o elemento removido é o que está na estrutura há menos tempo. Roteador Roteador é um dispositivo que trabalha na camada 3 do modelo ISO/OSI.). Em outras palavras. de três partes: uma biblioteca de funções (em C e em FORTRAN77) que implementam para o usuário as diretivas de programação da Máquina Virtual (MV). devido a sua alta performance. Storage Dispositivo com uma alta capacidade de armazenagem de dados. e AtomicLA. Essa política é conhecida pela sigla LIFO (Last In First Out). Membros dos dois grupos uniram-se e fundaram a Myricom. 10 Rede 10 gigabit ethernet Tecnologia de rede que consegue transmitir até 10.000 (10 ) bits por segundo. A tecnologia Myrinet surgiu de dois projetos de pesquisa: o MOSAIC. Mais especificamente. A principal característica desses equipamentos é determinar e escolher a rota mais apropriada para encaminhar os pacotes recebidos. A Myrinet é um tecnologia muito popular.. desenvolvido pelo grupo USC (University Southern California).

gera cópias desse dado em todos os caches dos outros processadores do sistema. XSIL e SVG (formato gráfico vetorial). NCL. Nos sistemas de VoIP. O processador local faz isso enviando um sinal de invalidação no barramento. No write-invalidate o processador que está escrevendo um dado. o dado no processador local pode ser atualizado até que outro processador o requisite.SDMX . XBRL. É um subtipo de SGML (acrônimo de Standard Generalized Markup Language. User Datagram Protocol (UDP) e Internet Protocol (IP). Entre linguagens baseadas em XML incluem-se XHTML (formato para páginas Web). 225 . MathML (formato para expressões matemáticas). ou Linguagem Padronizada de Marcação Genérica) capaz de descrever diversos tipos de dados. A principal característica do XML. de criar uma infraestrutura única para diversas linguagens. XML XML (eXtensible Markup Language) é uma recomendação da W3C para gerar linguagens de marcação para necessidades especiais. que é utilizado para manter a coerência de cache em ambientes de multiprocessamento simétrico.Voice Over IP (VoIP) VoIP é uma tecnologia de comunicação que permite a transmissão em tempo real de sinais de voz colocados em pacotes de dados sobre redes IP que empregam Transmission Control Protocol (TCP).SMIL. é que linguagens desconhecidas e de pouco uso também podem ser definidas sem maior trabalho e sem necessidade de serem submetidas aos comitês de padronização. RDF. Uma vez as cópias tenham sido invalidadas. os sinais analógicos de voz são digitalizados e transmitidos como um fluxo de pacotes sobre uma rede de dados Write-invalidate O write-invalidate é componente do protocolo snooping também conhecido como bus-snooping protocol. Seu propósito principal é a facilidade de compartilhamento de informações através da Internet. o que faz com que os outros caches verifiquem se sua cópia está inválida. que passa a ser inválido se a cópia local for alterada. Real-Time Transport Protocol (RTP).