You are on page 1of 225

Pontifcia Universidade Catlica de So Paulo

PUC-SP

Everaldo Lopes Silva

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

Mestrado em tecnologias da inteligncia e design digital

So Paulo 2012

Pontifcia Universidade Catlica de So Paulo


PUC-SP

Everaldo Lopes Silva

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

Mestrado em tecnologias da inteligncia e design digital Dissertao apresentada Banca Examinadora da Pontifcia Universidade Catlica de So Paulo, como exigncia parcial para obteno do ttulo de Mestre em Tecnologias da Inteligncia e Design Digital sob a orientao do Prof. Dr. Demi Getschko.

So Paulo 2012

FICHA CATALOGRFICA

AUTORIZO A CPIA E DIVULGAO TOTAL OU PARCIAL DESTE DOCUMENTO PARA FINS DE ESTUDO OU ACADMICOS, 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. -- So Paulo, 2012. 225f.

Dissertao (Mestrado). rea de Concentrao: PUC-SP - TIDD.

1. Inteligncia 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 comunicao onde se executaria sistemas de inteligncia e Design Digital dentro do Programa de Estudos Ps-Graduados em Tecnologias da Inteligncia e Design Digital - TIDD, com rea de concentrao em Inteligncia Coletiva, da Pontifcia Universidade Catlica de So Paulo PUC/SP.

APROVADO em: __ / __ / __

_________________________

_________________________

_________________________

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

BRASIL

iv

A meus pais, por iniciarem-me no interesse pela leitura e estudo; OFEREO

Aos professores, colegas e a Edna da Secretaria do TIDD; DEDICO

AGRADECIMENTOS

Agradeo ao professor Dr. Demi Getschko pelos conselhos, sobretudo, os questionamentos que fizeram refletir sobre o contedo desse trabalho e o posicionamento do mesmo dentro do cenrio da Tecnologia da Informao atual.

vi

... buscai diligentemente e ensinai-vos uns aos outros palavras de sabedoria; sim nos melhores livros buscai palavras de sabedoria; procurai conhecimento, sim, pelo estudo e tambm pela f." Doutrina e Convnios 88:118 - Ano 1832

vii

RESUMO Esta dissertao visa identificar os aspectos tcnicos e tericos que envolvem a utilizao de cluster de computadores, tratando especialmente de plataformas com o sistema operacional Linux. Sero apresentados alguns modelos de cluster em Linux, reconhecendo suas vantagens e desvantagens e por fim indicando o modelo escolhido com a devida justificativa. Como parte do trabalho, proporemos um laboratrio com um agrupamento de dois equipamentos conectados com duas interfaces de rede gigabit ethernet em cada um e um computador trabalhando isoladamente. Executaremos programas de Inteligncia Artificial e Design Digital nesse cluster e compararemos o seu desempenho com apenas um computador executando esses mesmos programas. As medies e anlise serviro como base para anlise para a verificao se um cluster de Linux seria uma infraestrutura vivel em termos tcnicos e financeiros para aplicaes de Inteligncia Artificial e Design Digital. O mtodo de pesquisa ser naturalmente a pesquisa experimental e o mtodo de abordagem ser indutivo, pois atravs dos resultados da experimentao e da anlise tcnica se poder aplicar o conhecimento obtido em situaes semelhantes. Para contextualizar a atividade experimental abordaremos as teorias de pesquisa mais significativas e contemporneas para que se estabelea de maneira clara a abordagem cientfica que nortear o trabalho como um todo. Palavras-chave: Distribudo Computao, Redes, Sistemas Operacionais, Processamento

viii

ABSTRACT This dissertation has the objective of identifying the technical aspects that deal with the utilization of computer cluster, specially the platforms with Linux operational system. 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. As part of this work, we will propose a laboratory with a cluster of two equipments connected with two gigabit interfaces each one and one computer working stand-alone. It will run Artificial Intelligence and Digital Design programs in this cluster, comparing its performance with only one computer running the same programs. 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. The research method will be naturally the experimental and the approach method will be inductive, for through the results of the experimentation and technical analysis, it will be able to apply the knowledge achieved in others similar environments. 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. Keywords: Computation, Networking, Computation, Distributed Systems

ix

LISTA DE FIGURAS

Figura 1 - Codificao de sinal de udio analgico para sinal de udio digital Figura 2 - Intercmbio de pacotes em sistemas multimdia Figura 3 - Intercalamento de pacotes de dados e pacotes multimdia (Interleaving) Figura 4 - Organizao de arquivos multimdia no contguos em discos rgidos Figura 5 - Organizao de arquivos multimdia no contguos em discos rgidos Figura 6 - Comparao entre o modelo ISO/OSI o protocolo TCP-IP Figura 7 - Primitivas send e receive em passagem de mensagens (MPI) Figura 8 - Comunicao entre servidor e cliente em RPC Figura 9 - Memria Compartilhada Distribuda (DSM) Figura 10 - Comunicao entre servidor e cliente em Sockets Figura 11 - Diagrama de blocos simplificado de RPC em Sistema Microsoft Figura 12 - Diagrama de blocos de exemplo de exemplo de RPC em Sistema Microsoft Figura 13 - Digrama de explicativo de Race Passage Figura 14 - Representao de Grafos para resoluo do problema do Drink dos Filsofos Figura 15 - Representao da Multiprogamao N-way Figura 16 - Esquema lgico simplificado de um cluster Beowulf Figura 17 - Esquema lgico simplificado de um cluster OSCAR Figura 18 - Esquema lgico do laboratrio Figura 19 - Fotografia do laboratrio Figura 20 - Medio de banda disponvel via Iperf

Figura 21 - Execuo das aplicaes Breve e PovRay no N 00 Figura 22 - Evidncia de o cluster estar operacional Figura 23 - Medies de utilizao CPU, Memria e Rede no N 00 Figura 24 - Tempo de renderizao do Benchmark.pov no N 00 Figura 25 - Execuo da aplicao Breve no N 01 Figura 26 - Tempo de renderizao do Benchmark.pov no N 01 Figura 27 - Finalizao do teste de memria sem apresentar nenhum erro Figura 28 - Medio do uso da memria durante a execuo do memtester Figura 29 - Resultado do comando ps em ambiente monoprocessado com o Breve Figura 30 - Resultado do comando ps em cluster com o Breve

xi

LISTA DE GRFICOS Grfico 1 - Medio de desempenho utilizando Zlib Grfico 2 - Medio de desempenho utilizando Fibonacci Grfico 3 - Medio de desempenho utilizando MD5 Grfico 4 - Medio de desempenho utilizando SHA1 Grfico 5 - Medio de desempenho utilizando Blowfish Grfico 6 - Medio de desempenho utilizando Raytracing Grfico 7 - Medio de tempo de execuo do PovRay Grfico 8 - Instncias benchmark.pov em cluster Grfico 9 - Instncia benchmark.pov em computador standalone Grfico 10 - Grfico da quantidade de pesquisa sobre cluster, grid e cloud no Google

xii

LISTA DE TABELAS Tabela 1 - Arquivos criados na instalao do Kerrighed Tabela 2 - Valores para a implementao do cluster do laboratrio Tabela 3 - Valores para a contratao de servio de cloud Tabela 4 - Comparao dos custos de implementao do cluster e a contratao de cloud

xiii

LISTA DE FRMULAS Frmula 1 - Frmula para escalonamento para sistemas em tempo real peridicos Frmula 2 - Performance terica de pico Frmula 3 - Ganho de velocidade Frmula 4 - Frmula de Amdahl Frmula 5 - Variao da frmula de Amdahl

xiv

LISTA DE SIGLAS E ACRNIMOS 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: Fundao de Estudos e Pesquisas Agrcolas e Florestais FTP: File Transfer Protocol GPU: Graphics Processing Unit HPC: High-Performance Computing

xv

HTTP: Hypertext Transfer Protocol IA: Inteligncia 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: Vdeo on Demand VoIP: Voice over IP WFG: Wait-For-Graph XML: Extensible Markup Language

xviii

SUMRIO
FICHA CATALOGRFICA ........................................................................................................................... iii AGRADECIMENTOS ................................................................................................................................... vi RESUMO .................................................................................................................................................... viii ABSTRACT .................................................................................................................................................. ix LISTA DE FIGURAS ..................................................................................................................................... x LISTA DE GRFICOS ................................................................................................................................ xii LISTA DE TABELAS ................................................................................................................................... xiii LISTA DE FRMULAS .............................................................................................................................. xiv LISTA DE SIGLAS E ACRNIMOS ............................................................................................................ xv INTRODUO ............................................................................................................................................ 21 METODOLOGIA ......................................................................................................................................... 27 Captulo 1 Conceitos tericos sobre processamento Monoprocessado e Distribudo ............................. 28 Caractersticas de um Cluster de Computadores ................................................................................... 28 Fundamentos dos Sistemas Operacionais Convencionais ..................................................................... 33 Dificuldades na manipulao de processos num ambiente monoprocessado ....................................... 43 Escalonamento de processos ou threads ............................................................................................... 55 Escalonamento em sistemas em tempo real .......................................................................................... 62 Fundamentos de Sistemas Operacionais com Processamento Distribudo ........................................... 82 Redes de Computadores ........................................................................................................................ 82 Processos e Threads.............................................................................................................................. 87 RPC (Remote Procedure Call) e MPI (Message Passing Interface)....................................................... 88 Gerenciamento de Memria: .................................................................................................................. 93 Dispositivos de Entrada/Sada:............................................................................................................... 96 Arquivos: ................................................................................................................................................ 97 Chamadas de Sistema (System Calls) e Comunicao Interprocessos: ................................................ 99 Dificuldades na manipulao de processos num ambiente de processamento distribudo .................. 113 Aplicaes Multimdia em Sistemas Distribudos ................................................................................. 124 Concluso do Captulo ......................................................................................................................... 131 Captulo 2 Apresentao de Cluster em Linux na Modalidade HPC com nfase em Kerrighed ............ 132 Classificao de Michael J. Flynn (FLYNN, 1972) das arquiteturas de Computadores ....................... 132 Tipos de clusters .................................................................................................................................. 133 Cluster Beowulf: ................................................................................................................................... 134 Cluster OSCAR (Open Source Cluster Application Resources): .......................................................... 137 Projeto Rocks ....................................................................................................................................... 139 Cluster OpenMosix ............................................................................................................................... 141 Cluster Kerrighed.................................................................................................................................. 151 Concluso do Captulo ......................................................................................................................... 163 Captulo 3 Apresentao do Laboratrio ............................................................................................... 164 Descrio do hardware utilizado........................................................................................................... 164 Descrio do Sistema Operacional utilizado ........................................................................................ 168 Descrio da configurao do Cluster Kerrighed implementada .......................................................... 170

19

Descrio dos aplicativos para testes .................................................................................................. 171 Concluso do captulo .......................................................................................................................... 176 Captulo 4 Medies e anlises ............................................................................................................. 177 Performance terica de pico ................................................................................................................. 177 Performance das Aplicaes ................................................................................................................ 178 Performance da rede ............................................................................................................................ 179 Abordagem e ferramentas de anlise do desempenho do cluster........................................................ 180 Anlise geral dos resultados................................................................................................................. 181 Medio e anlise do throughput real das conexes de rede. ............................................................. 181 Estresse do cluster e anlise para confirmar a efetiva funcionalidade do mesmo................................ 182 Teste e medio de memria ............................................................................................................... 186 Medio e anlise do sistema em cluster e nos ns com ferramentas de benchmark apresentadas no aplicativo hardinfo................................................................................................................................. 188 Medio e anlise do sistema em cluster e monoprocessado utilizando um aplicativo de Design Digital (PovRay) .............................................................................................................................................. 192 Medio e anlise do sistema em cluster e monoprocessado utilizando um aplicativo de Inteligncia Artificial (Breve) .................................................................................................................................... 194 Captulo 5 Concluso............................................................................................................................. 196 Viabilidade Econmica do Cluster Kerrighed ....................................................................................... 199 Viabilidade Tcnica do cluster Kerrighed ............................................................................................. 203 Consideraes Finais ........................................................................................................................... 205 Captulo 6 - Um olhar para o presente e um olhar para o futuro da Tecnologia de Cluster ...................... 213 Um olhar para o presente ..................................................................................................................... 213 Um olhar para o futuro .......................................................................................................................... 216 Concluso do captulo .......................................................................................................................... 218 Referncias: .............................................................................................................................................. 219 GLOSSRIO ............................................................................................................................................. 222

20

INTRODUO Antes de adentrar na questo principal do trabalho, faz-se necessrio estabelecermos alguns conceitos relacionados ao tema e o mtodo de abordagem do mesmo. Quanto ao tema, importante salientar que estamos trabalhando no campo da tecnologia, mas precisamos circunscrever o significado de tecnologia em relao aos conceitos de cincia e engenharia, estabelecendo os limites e abrangncia de cada uma dessas atividades. Numa viso conceitual podemos estabelecer que cincia um corpo de conhecimento em determinada rea de pesquisa, que procura descrever o mundo fsico e suas propriedades atravs de uma metodologia. A engenharia busca solues para problemas de natureza mais geral, utilizando o conhecimento gerado pela cincia dados certos recursos e limites. E por fim a tecnologia que cincia e a engenharia aplicada visando proviso de solues para as necessidades humanas pontuais, usualmente utilizando o conhecimento construdo pela engenharia, mas em algumas ocasies, buscando as solues diretamente do repositrio de conhecimento da prpria cincia. Usando como exemplo o prprio tema da pesquisa, a cincia descobriu as propriedades dos semicondutores e sua aplicao em circuitos digitais, especialmente na criao de operaes de natureza binria e na transmisso de informaes em meios eltricos e ticos. A engenharia desenvolve computadores, softwares e equipamentos de comunicao de dados baseados nos conceitos cientficos, mas em ambiente de laboratrio e no em larga escala. A tecnologia desenvolve produtos para uso geral e em larga escala, baseados no conhecimento e tcnicas desenvolvidas pela engenharia, no nosso caso,

microcomputadores, sistemas operacionais, softwares e equipamentos de rede. Porm apesar da rea de pesquisa em questo ter uma ligao relativamente clara e interdependente entre a cincia, a engenharia e a tecnologia, isso no ocorre de modo geral, segundo Derek de Solla Price (PRICE, 1976). Ele coloca: Em termos gerais, a cincia no tem prestado grande auxlio tecnologia, embora, uma e outra vez, deparemos com eventos anmalos e traumatizantes, como os transistores e a penicilina. Importa ser cauteloso: trata-se de grandes excees, no a regra. Realmente existe um hiato muito grande entre essas duas atividades, onde atuam pessoas com perfil intelectual e psicolgico muito distinto, tambm com objetivos e motivaes muito diferentes.

21

Apesar da conscincia de que sou um tecnologista, com as caractersticas prprias desse perfil, procurarei nesse trabalho utilizar a metodologia e a viso cientfica para analisar a pesquisa proposta, pois acredito que uma abordagem cientfica baseada num trabalho emprico-indutivo, conseguir obter melhores resultados do que um simples benchmarking1. Estabelecido os conceitos, podemos seguir em frente com esse prlogo, abordando a agora a questo da metodologia indutiva. Apesar de adepto experimentao, para Hume (HUME, 1999) a experimentao e em seguida a concluso obtida atravs do mtodo indutivo, no seriam adequadas, pois, segundo ele, no pode haver argumentos lgicos vlidos que nos permitam afirmar que aqueles casos dos quais no tivemos experincia alguma se assemelham queles que j experimentamos anteriormente, consequentemente, mesmo aps observar uma associao constante ou frequente de objetos, no temos motivo para inferir algo que se refira a um objeto que no experimentamos. Em outras palavras, Hume no aceitava o mtodo indutivo, pois, no sua viso, essa concluso ser de natureza psicolgica, baseada no hbito de acreditar em leis, em assertivas que afirmam a regularidade de certos eventos.

Aqueles que j atuam e convivem no meio e em atividades relacionadas Tecnologia da Informao, sabem das dificuldades encontradas ao se traduzir algumas palavras ou termos em ingls para a Lngua Portuguesa, buscando o mesmo sentido que o original. Nesse trabalho iremos traduzir, segundo o nosso juzo, os termos em ingls com maior clareza e acuidade possvel, porm apresentaremos a palavra ou o termo em ingls caso percebamos que a traduo no reflete o significado original da palavra em sua plenitude. Palavras que j existem nos principais dicionrios da Lngua Portuguesa no sero destacadas nesse trabalho.

22

Popper (POPPER, 1994) questiona essa posio, mas tambm tem reservas ao mtodo indutivo e apresenta o que ele chama da teoria das conjecturas e refutaes onde estabelece que ao invs de esperar passivamente que as repeties nos imponham suas regularidades e, por conseguinte a induo, ns devemos, segundo ele, de modo ativo impor regularidades ao mundo, tentando identificar similaridades e interpret-las em termos da teoria que defendemos. Ele tambm estabelece que as teorias precisam ser testadas atravs de experimentos, mas no com o intuito de prov-las mas sim de refut-las. Como Popper coloca S a falsidade de uma teoria pode ser inferida da evidncia emprica, inferncia que puramente dedutiva. Kuhn (KUHN, 1978) na sua teoria da estrutura das revolues cientficas coloca que o princpio de falsificao de Popper semelhante ao que na sua teoria ele chama de experincias anmalas, isto , experincias que, ao evocarem crises, preparam o caminho para uma nova teoria. Porm, na viso de Kuhn se todo e qualquer fracasso na tentativa de adaptar teoria e dados fosse motivo para a rejeio de teorias, todas as teorias deveriam ser sempre rejeitadas. Apenas para encerrar essas consideraes sobre o mtodo experimental, gostaria de acrescentar apenas a viso de Kant (KANT, 1999), que afirma que, apesar da experincia produzir conhecimento, existe um conhecimento a priori que no derivado de nenhuma experincia que se contrape ao conhecimento emprico ou a posteriori. Diante dessas teorias e ideias, estabelecerei a minha estratgia de pesquisa. importante ressaltar que minha pesquisa est totalmente no domnio da tecnologia e que alguns conceitos at agora apresentados referem-se mais propriamente cincia. Apesar disso, considero salutar aplicar essas ideias e consideraes a minha pesquisa para que a mesma se torne mais consistente e circunspecta. Assim estarei atento quanto o grau de subjetividade na anlise dos testes experimentais mesmo que os mesmos resultados se repitam numa frequncia significativa assim como terei critrio ao inferir um resultado ou concluso, procurando faz-lo se realmente a similaridade dos elementos comparados seja significativa e clara. Tambm estabelecerei questionamentos que testem a falsidade das minhas proposies, mas dentro de limites para no invalidar de maneira precipitada a teoria como um todo.

23

Terei tambm cincia que iniciarei os trabalhos com um conhecimento a priori impuro, pois fruto de certo empirismo obtido na minha experincia tcnica. Estabelecidas as diretrizes metodolgicas da pesquisa, podemos introduzir o tema de minha pesquisa, que verificar empiricamente se um sistema de cluster de computadores com o sistema operacional Linux seria uma infraestrutura vivel para aplicaes de Design Digital e Inteligncia Artificial. Sem dvida que sistemas de cluster j so largamente usados tanto nas instituies acadmicas com nas corporaes, por exemplo, se acessarmos hoje o site www.top500.org que estabelece um ranking de computadores mais poderosos do mundo, segundo seus critrios, temos um cluster na quarta posio com 120.640 processadores instalado no NSCS (National Supercomputing Centre in Shenzhen) na China. Assim esse no o foco da pesquisa, a viabilidade dos sistemas de cluster de modo geral, mas verificar de maneira metdica o comportamento do mesmo ao executar aplicaes especialistas de Design Digital e Inteligncia Artificial com todas suas particularidades e caractersticas semelhantes em relao a aplicaes de outra natureza. A histria de cluster de computadores se confunde com a histria das prprias redes, pois apenas atravs de redes de comunicao que foi possvel computadores independentes trabalharem de maneira paralela como uma nica entidade. Os primeiros clusters comerciais foram o ARCnet desenvolvido pela Datapoint em 1977 e o VAX cluster desenvolvido pela DEC em 1984. Outros clusters que tiveram alguma notoriedade foram o Tandem Himalaya por volta de 1994 e o IBM S/390 Parallel Sysplex tambm no mesmo perodo.

24

Com o surgimento da PVM (Parallel Virtual Machine) a construo de cluster tornou-se mais acessvel por ser uma arquitetura aberta (open source) baseada em TCP-IP, podendo assim compor cluster com computadores heterogneos totalmente transparentes para o usurio final. Aps esse sucinto histrico da tecnologia, podemos apresentar como esse trabalho ser estruturado. No captulo 1, apresentaremos os conceitos de sistemas distribudos tendo como contraponto os sistemas monoprocessados. No captulo 2, abordaremos os principais modelos de cluster em sistemas operacionais Linux, esmiuando o que ser o foco do nosso estudo que Kerrighed. No captulo 3, apresentaremos o nosso laboratrio com uma descrio detalhada de cada item do mesmo, assim como as configuraes aplicadas aos computadores. Apresentaremos tambm as aplicaes que sero executadas nesse sistema e suas caractersticas bsicas no que concerne ao modo de processamento e alocao de recursos. No captulo 4, descreveremos os testes de execuo das aplicaes previamente escolhidas e a devida medio, que envolver em linhas gerais, utilizao de CPU, de memria, de banda nas conexes de rede, tempo de resposta, a carga em cada n do cluster, etc. Aps a execuo e medio dos programas, analisaremos os resultados tendo como referncia um computador com as mesmas caractersticas dos ns que compe o cluster, executando as mesmas aplicaes. No quinto captulo, a partir da anlise realizada no captulo anterior, chegaremos concluso ou pelo menos em indicaes sobre a viabilidade do uso do sistema Kerrighed na execuo de sistemas de Design Digital e Inteligncia Artificial que foram executados em laboratrio, utilizando como contraponto tecnologias alternativas de computao massiva como computao em grid e computao em cloud. No sexto e ltimo captulo ser apresentado como um anexo, casos que representaro o estado da arte em tecnologia de cluster com um olhar para o presente e um olhar para o futuro. A fundamentao terica desse trabalho visa ajudar aos pesquisadores e profissionais que no atuam com infraestrutura, subsdios para entender as especificidades tcnicas dessa matria, como suporte para a realizao de suas atividades, como por exemplo, o desenvolvimento de cdigos para Design Digital e Inteligncia Artificial. Apesar do foco desse trabalho sejam aplicaes de Design Digital e Inteligncia Artificial, as constataes e concluses apresentadas nesse trabalho podero ser aplicadas em outras reas da Tecnologia da Informao.

25

Uma proposio inicial seria que o sistema de cluster aumentaria a capacidade de processamento linearmente, isto , na mesma medida em que adicionamos computadores ao cluster, aumentaramos linearmente o desempenho do mesmo, a ponto de considerarmos um cluster de servidores Linux uma infraestrutura vivel para implementao de aplicaes de Inteligncia Artificial e Design Digital. Porm sabemos que essa proposio no corresponde realidade, assim consideraremos a agregao de 80% da capacidade computacional a cada novo n inserido ao cluster, prevendo alguma perda devido latncia da rede, dificuldade das aplicaes realizarem processamento paralelo, gerenciamento de memria em ambientes distribudos e os prprios recursos computacionais para as funcionalidades do cluster. Iremos testar essa hiptese com a realizao desse laboratrio. Inicialmente adotamos o projeto OpenMosix como sistema de cluster a ser utilizado no laboratrio idealizado para esse trabalho, porm o projeto foi encerrado em maro de 2008 pelo professor Moshe Bar. Iniciamos os trabalhos de implementao do projeto em laboratrio e ao consultar um dos autores mais proeminentes no Brasil em cluster em Linux, Marcos Pitanga, fomos aconselhados a trabalhar com o cluster Kerrighed que tambm SSI (Single System Image), sendo um projeto em franca atividade de implementao e aperfeioamento. Assim ao iniciarmos os trabalhos de laboratrio, optamos por utilizar pelo cluster em Linux Kerrighed. Objetivo final desse trabalho verificar se uma plataforma de baixo custo de hardware, utilizando software aberto vivel tcnica e financeiramente para a execuo de aplicaes HPC com nfase em Inteligncia Artificial e Design Digital.

26

METODOLOGIA

Trabalho baseado em uma abordagem emprica indutiva, buscando atravs de um laboratrio que consiste de um cluster Linux e aplicaes com nfase em Inteligncia Artificial e Design Digital, analisar a viabilidade da utilizao de cluster SSI em ambientes de pequeno e mdio porte que poder apresentar-se como uma opo vivel em termos tcnicos e financeiros para alojar esses tipos de aplicaes.

27

Captulo 1 Conceitos tericos sobre processamento Monoprocessado e Distribudo Consideraes iniciais do captulo Alm de apresentar as caractersticas bsicas de um sistema em cluster, esse captulo tem como objetivo apresentar os componentes, tecnologias e desafios intrnsecos da computao monoprocessada e distribuda, apontando diferenas, semelhanas e relaes. Acreditamos que essa fundamentao terica ser de grande valia ao estudarmos o foco desse trabalho em termos de soluo, que seria o sistema em cluster Kerrighed, que apesar de possuir tcnicas prprias para algumas das disciplinas da teoria da computao, como por exemplo, a alocao e o mapeamento de memria, as teorias convencionais sempre no serviro de base para o entendimento de novas abordagens seja por semelhana seja por contraponto.

Caractersticas de um Cluster de Computadores Tanenbaum2 (TANENBAUM, 1995) coloca que um sistema distribudo uma coleo de computadores independentes que parecem aos usurios do sistema como um s computador. Existem alguns autores como Gregory F. Pfister3 que fazem distino entre sistemas distribudos e clusters, mas nesse trabalho no faremos essa diferenciao, pois alm do tema ser controverso, em se tratando de cluster de alto desempenho, essa distino no se aplica a nossa abordagem do assunto.

Andrew Stuart Tanenbaum o chefe do Departamento de sistemas de computao, na Universidade Vrije, Amsterd nos Pases Baixos. Ele o autor do Minix, um sistema operacional baseado no Unix com propsito educacional, e bastante conhecido por seus livros sobre cincia da computao. Nasceu na cidade de Nova Iorque e cresceu em White Plains no estado de Nova Iorque. Recebeu o ttulo de bacharelado pelo MIT e o doutorado pela UC Berkeley em 1971. Atualmente ministra aulas sobre Organizao de Computadores e Sistemas Operacionais. 3 Gregory Y. Pfister obteve seu doutorado no MIT. Tendo sido instrutor nessa instituio, assim como professor assistente na Universidade da California, Berkeley. Por muitos anos, ele foi membro da equipe de Pesquisa e Desenvolvimento da IBM num nvel snior. Ele detm inmeras patentes em processamento distribudo. Autor do livro In Search of Clusters.

28

Apenas ttulo de registro Pfister (PFISTER, 1998) afirma que clusters so geralmente grupos de computadores homogneos em menor escala, dedicados a um nmero pequeno e bem definido de tarefas, nas quais o cluster atua como uma nica mquina, porm os clusters atualmente podem ser compostos de mquinas heterogneas e de um nmero grande de computadores, assim a definio de Pfister no se aplica ao nosso estudo e concepo de um cluster. Tanenbaum (TANENBAUM, 1995) identifica caractersticas essenciais no

desenvolvimento de sistemas distribudos que so: Transparncia Flexibilidade Confiabilidade Desempenho Escalabilidade Transparncia Transparncia capacidade do sistema em dar a impresso ao usurio de que ele est acessando apenas um computador convencional, quando na realidade h um cluster de computadores realizando as tarefas. A transparncia pode ser vista sob os seguintes aspectos: Transparncia de localizao: Os usurios no podem dizer onde os recursos esto localizados. Transparncia de migrao: Os recursos podem se mover a qualquer momento sem mudarem seus nomes. Transparncia de replicao: Os usurios no podem dizer quantas cpias dos recursos existem. Transparncia de concorrncia: Os usurios podem compartilhar os recursos automaticamente. Transparncia de paralelismo: As atividades ocorrem paralelamente sem os usurios o saberem.

29

Flexibilidade Podemos dizer que temos duas vertentes para o desenvolvimento de estruturas de sistemas operacionais distribudos. Temos os sistemas operacionais com o kernel monoltico e temos os sistemas operacionais com microkernel. O primeiro possuindo a maioria dos servios em si mesmo, tendo controle sobre sistemas de arquivos, conexo com a rede, etc. e o segundo realizando o mnimo de operaes possveis deixando que as outras tarefas necessrias para a obteno dos resultados desejados, sejam realizadas fora do kernel, em nvel de usurio do sistema. Diferentemente dos sistemas monolticos, o microkernel no prov um sistema de arquivo ou diretrios, gerenciamento completo dos processos ou um manuseio considervel de chamadas de sistema. Dessa maneira, os sistemas com microkernel so essencialmente mais flexveis, proporcionando um desenvolvimento modular de funes e servios, podendo os mesmos estar fisicamente em recursos computacionais diferentes. Alm disso, esse tipo de sistema torna a incluso e manuteno dos servios muito mais simples, pois no requer que o sistema seja parado para que se habilite um novo kernel com um novo servio. A vantagem de um kernel monoltico o desempenho, pois todas as instrues sero realizadas na velocidade do barramento interno do computador, no necessitando de utilizar uma estrutura de rede para essa atividade. O microkernel, na viso de Tanenbaum (TANENBAUM, 1995), seria a abordagem mais adequada para o desenvolvimento de sistemas distribudos. Segue algumas funes bsicas realizadas por sistemas microkernel: Mecanismo de comunicao interprocessos; Algum gerenciamento de memria; Pequena quantidade processos de baixo nvel responsveis por gerenciamento e scheduling; Entrada/Sada em baixo nvel;

30

Confiabilidade Um dos primeiros objetivos de se construir sistemas distribudos foi de faz-los mais confiveis que os sistemas monoprocessados. A ideia seria que se um computador ficasse fora de funcionamento, outro assumiria seu trabalho. Na teoria, a confiabilidade de um sistema distribudo seria uma operao lgica OU das confiabilidades das mquinas que o compe. Por exemplo, se tivermos trs servidores de arquivos com 0,95 de chance de estarem indisponveis, a probabilidade dos trs computadores estarem indisponveis ao mesmo tempo seria de (1 - 0,053) = 0,999875, muito melhor do que qualquer servidor individual. Na prtica a funo lgica E estaria mais prxima da realidade do que a operao OU, porque manter num sistema distribudo todos os processos, arquivos, usurios exatamente iguais em todos os computadores que o compe, uma tarefa rdua em termos tcnicos e financeiros, aspectos como disponibilidade, segurana, consistncia e tolerncia a falhas so desafios para os desenvolvedores de sistemas distribudos. Em geral os sistemas distribudos trabalham de modo a esconder do usurio do sistema que algum dos seus componentes no est disponvel em dado momento. Desempenho No tema de sistemas distribudos sempre teremos como pano de fundo o desempenho. Sempre buscaremos a condio de uma aplicao ser executada mais rapidamente num sistema distribudo do que num nico servidor com capacidade computacional de um dos componentes desse cluster. Infelizmente, na prtica a obteno desse objetivo no to fcil de ser alcanada. A primeira questo que na medio do desempenho (benchmarking), pode-se utilizar vrias mtricas como tempo de resposta, vazo (nmero de Jobs por hora), utilizao do sistema (recursos computacionais) e consumo da capacidade da rede. A consolidao dessas mtricas nem sempre uma atividade fcil de ser realizada assim como as concluses derivadas dessa consolidao. O tipo de operao escolhida tambm influencia em muitos nos resultados de um benchmarking, por exemplo, trabalhar com um experimento computacional que envolve um nmero grande de atividades de alto consumo de CPU ter um resultado muito diverso que trabalhar analisando um arquivo de grandes propores buscando algum padro.

31

A infraestrutura de rede sempre ser um elemento crtico num sistema distribudo. Uma comunicao entre duas mquinas na melhor das condies leva pelo menos um milissegundo, que comparado taxa de transferncia interna de um processador ou mesmo de um barramento de um computador, pode ser considerado um tempo extremamente longo, mesmo em conexes de LAN de 10 Gibabits. Quando falamos em desempenho em processamento distribudo temos que pensar na granularidade computacional. Utilizar um recurso computacional remoto de modo reduzido, como por exemplo, realizar uma operao lgica simples entre dois nmeros, no ser usualmente interessante em termos de desempenho num ambiente distribudo, devido ao overhead da comunicao de dados, por outro lado, se realizarmos uma tarefa que exija um longo processamento computacional para uma mesma massa de dados, usualmente um trabalho adequado para um processamento distribudo. Assim quando processos realizam poucas instrues e precisam comunicar-se muito, dizemos que so muitos granulares, quando realizam muitas instrues com pouca troca de informao, dizemos que so poucos granulares. Naturalmente num ambiente de processamento distribudo uma menor granularidade computacional, significa usualmente um melhor desempenho. Escalabilidade Falando em cluster em Linux temos na plataforma Beowulf no projeto Goddard Casse Flight Center, um cluster com 199 servidores e na Caltech um sistema com 140 ns de cluster. Um dos clusters da Yahoo (Apache Hadoop Cluster) tem 910 ns, porm esse um sistema de cluster apenas para executar as funcionalidades de um servidor web num modelo de grid, que um agrupamento de computadores visando um aumento de capacidade de processamento que esto geograficamente separados, porm podendo ou no estar disponveis, para a realizao de uma determinada tarefa computacional. O grande desafio da escalabilidade no seria a quantidade de ns que poderiam ser agregados a um cluster e sim o desenvolvimento de sistemas operacionais e aplicaes que usufruam devidamente desse tipo de configurao. Dessa maneira modelos convencionais de processamento centralizado no so adequados, em muitas situaes, para serem executados num sistema em cluster.

32

Seguem algumas caractersticas de sistemas adequados para trabalhar num cluster: Nenhuma mquina tem uma completa informao sobre o estado de todo o sistema. As mquinas tomam as decises baseadas na informao local. A falha numa mquina no afeta o funcionamento do sistema. No existe uma premissa implcita que exista um sistema global de sincronismo (clock). Sobre o ltimo tpico, estamos considerando o uso de cluster para fins gerais e no para sistemas multimdia distribudos que necessitam de um sincronismo adequado para operarem satisfatoriamente. A escalabilidade s faz sentido quando as aplicaes so compatveis com um modelo de cluster de computadores. No nosso trabalho, em especial, buscaremos aplicaes de inteligncia e Design Digital que satisfaam esses requisitos. Apesar dessas restries, os sistemas de cluster so tcnica e financeiramente viveis para uma grande quantidade de aplicaes. Fundamentos dos Sistemas Operacionais Convencionais Para que possamos melhor compreender os princpios utilizados no processamento distribudo precisamos conhecer alguns componentes do processamento tradicional, isto , computadores monoprocessados. O objetivo dessa apresentao apenas discorrer sobre os componentes e entidades do processamento convencional que necessitam ser adequadas ou pelo menos consideradas quando atuando com sistemas de processamento distribudo ou clusters. Sero abordados tambm os desafios que tecnologia enfrenta, de certa forma, inerentes aos prprios princpios que regem a computao convencional

contempornea que em regra geral tornam-se mais crticos e de mais difcil soluo ou mitigao quando tratados no domnio da computao distribuda.

33

Processos: Todo software executvel num computador, algumas vezes incluindo o prprio sistema operacional, organizado num nmero de processos sequenciais. Um processo um programa executvel, com determinados valores nos contadores, registros e variveis. Mesmo num sistema monoprocessado, temos a impresso de que os processos so executados paralelamente, mas na realidade eles compartilham uso da CPU em intervalos muito rpidos que nos do essa impresso de um pseudo-paralelismo. importante ressaltar que em sistemas monoprocessados no podemos precisar exatamente quanto tempo um processo durar, caso seja executado mais de uma vez, pois no saberemos quanto tempo ele ter para fazer uso da CPU em cada execuo. Essa falta uniformidade se acentua quando tratamos de sistemas distribudos, questo iremos tratar no transcorrer desse trabalho. Existem trabalhos recentes onde se trabalha com mecanismos de scheduler mesmo em ambientes monoprocessados, para que se tenha um maior controle do tempo de execuo de cada processo. Podemos citar o trabalho de Silviu S. Craciunas, Christoph M. Kirsch e Harald Rck4, que trabalha com scheduler de chamadas de sistema para alcanar essa uniformidade e melhor desempenho, baseando-se no princpio de Traffic Shaping utilizado em roteadores. Um processo sempre tem um espao de memria (address space) onde ele armazena as informaes que est manipulando que podem ser um programa executvel, dados de um programa ou a prpria pilha do processo. Tambm um processo sempre tem alguns registradores associados ao mesmo, que podem ser contadores, ponteiros de pilhas, registradores de hardware, etc. Usualmente um processo inicializado atravs de uma chamada de sistema (system call) que constituda de diretivas que so linhas de programao em C, se estamos falando em sistemas Unix e Linux, desenvolvidos para interagir com o sistema operacional e com a linguagem de mquina (Assembler), para realizar funes de baixo nvel e de interao com o prprio sistema operacional.

Autores do artigo I/O Resource Management through System Call Scheduling pela Universidade de Salzburg, Austria dentre outros trabalhos.

34

Quando um processo faz uma chamada para a execuo de outro processo, dizemos que o primeiro um processo pai do segundo, da a necessidade de comunicao interprocessos, que num ambiente monoprocessado que consideravelmente mais simples do que em sistemas distribudos. Threads Embora tenham algumas semelhanas. Processos e threads so entidades distintas com aplicaes distintas. Os processos tm como funo principal agrupar recursos e executar operaes com eles. Em algumas situaes interessante separar o agrupamento dos recursos do processamento dos mesmos. Nesse cenrio que temos as threads. Elas apenas executam operaes, possuindo um contador para ter um controle da execuo, um registrador que armazena as variveis de trabalho e uma pilha que contm um histrico da execuo. As threads acrescem aos processos a capacidade de realizar mltiplas execues num mesmo ambiente de processo, com um alto grau de independncia. Tendo mltiplas threads sendo executadas num mesmo processo seria semelhante a ter mltiplos processos sendo executados num mesmo computador. As primeiras compartilham espao de endereamento, arquivos abertos, etc. Os ltimos compartilham memria fsica, discos, impressoras, etc. Quando temos um cenrio de multi-thread, isto , mltiplas threads associadas a um nico processo, temos tambm a impresso de um paralelismo, porm como os processos, na computao convencional, cada thread executada por vez. Assim se tivermos trs threads sendo executadas sequencialmente por um processador, cada uma ter apenas um tero da capacidade do mesmo. Um motivo para utilizarmos threads seria aplicaes que necessitem de processos paralelos. Como as threads compartilham o mesmo espao de memria e os prprios dados, elas so ideais para aplicaes que necessitam dessa caracterstica, como, por exemplo, um servidor de arquivos numa rede local. Outra vantagem das threads que como elas no possuem nenhum recurso associado s mesmas, elas so criadas e finalizadas mais facilmente. Finalmente elas tm uma maior performance e tambm so mais apropriadas para ambientes multi-processados onde teremos um paralelismo real.

35

Gerenciamento de Memria: Todo sistema operacional precisa de uma memria principal onde os programas que esto sendo executados possam ser alojados. Em sistemas operacionais mais simples somente um programa por vez pode fazer usado no espao de memria. Nos sistemas mais sofisticados a memria pode ser compartilhada por mais de um programa, atravs da utilizao do conceito de endereamento de memria. Usualmente um processo tem um conjunto de endereos de memria com os quais ele pode trabalhar. Esse endereo pode ser de 32 ou 64 bits que significa respectivamente 232 e 264 bytes de tamanho de memria por endereo. Outro mecanismo para aumentar a quantidade de memria disponvel para os processos a memria virtual ou paginao que a gravao temporria dos dados da memria no disco rgido do computador, liberando a memria real para outras funes dos processos.

Dispositivos de Entrada/Sada: Todo o computador tem dispositivos de E/S (Entrada/Sada), como teclado, impressoras, monitores, etc. O sistema precisa gerenciar esses dispositivos na medida em que os processos e os programas solicitem uso de algum deles. Num sistema de cluster, tambm esses recursos tambm precisaro receber as requisies para o seu uso como que partissem de um nico computador.

Arquivos: Todo o sistema operacional possui um sistema de arquivos. Uma das principais funes de um sistema operacional realizar uma abstrao dos aspectos complexos do funcionamento real de um computador apresentando ao usurio ou mesmo programador uma interface amigvel. Assim com o sistema de arquivos. Os sistemas de arquivos so hierrquicos e tambm possuem o conceito de diretrios que um agrupamento de arquivos.

36

Todo arquivo num sistema de arquivos possui um caminho (path) que uma lista de todos os diretrios que necessita ser informada para acessar determinado arquivo. Todo processo tem um diretrio de trabalho que pode ser alterado atravs de uma chamada de sistema. Novamente, o gerenciamento de um sistema arquivos num ambiente

monoprocessado, apesar de ter certa complexidade no se compara s dificuldades em manter-se um sistema de arquivo num sistema de cluster, garantindo uma uniformidade e coerncia nos arquivos que esto espalhados entre os ns que compe o mesmo.

Chamadas de Sistema (System Call): A interface entre o sistema operacional e os programas dos usurios definida por um grupo de chamadas de sistemas previamente definidas. Apesar da maioria das chamadas de sistema ser altamente dependente das caractersticas do computador e usualmente escrita em linguagem de mquina (assembler), o desenvolvimento das mesmas foi simplificado atravs da criao de bibliotecas de procedimentos (procedures libraries) que facilitam esse trabalho por se poder utilizar linguagens de programao mais acessveis como a C. De forma simplificada podemos descrever os passos da execuo 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 parmetros fornecidos na respectiva pilha. A chamada de sistema executada com os parmetros fornecidos. A biblioteca de procedimentos a qual pertence chamada de sistema, que usualmente escrita em linguagem de mquina, coloca o nmero da chamada de sistema num registrador conforme estabelecido pelo sistema operacional.

37

Ocorre ento uma instruo conhecida como TRAP, que a mudana do modo usurio para o modo kernel (ncleo do Sistema Operacional) que inicia a execuo da chamada de sistema. O kernel verifica o nmero 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. Aps isso o sistema retorna para o modo usurio via instruo TRAP. O programa que executou a chamada de sistema limpa a pilha utilizada para colher os parmetros da mesma, procedimento usual nesse tipo de manipulao. 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 vrios servios realizados pelas chamadas de sistema temos como os mais relevantes o gerenciamento de processos, de arquivos e de sistema de arquivos e diretrios. Muitas das chamadas de sistemas em monoprocessamento podem ser usadas em processamento distribudo atravs de Remote Procedure Call (RPC). Os parmetros das chamadas de sistema ao invs de serem colocados num registrador, so colocados numa mensagem e o kernel envia a mensagem para a mquina que deseja que execute a chamada de sistema que retorna o resultado atravs de outra mensagem para o computador que requisitou a execuo remota, que do ponto de vista de RPC seria o client stub no processo e o executante o server stub. Existem outras abordagens para execuo de chamadas de sistemas remotamente, como o Kerrighed que realiza a execuo remota de chamadas de sistema atravs da migrao de processos entre os ns que compe um cluster.

38

Seguem agora alguns desafios que os desenvolvedores de sistemas operacionais enfrentam na implementao de processos e threads, considerando modelo computacional de Von Neumann5. IPC (Interprocess Communication) Um componente muito crtico seja na computao tradicional seja na computao distribuda, a comunicao entre processos. Um exemplo tpico de comunicao entre processos o comando pipeline no ambiente Unix, onde a sada de um processo alimenta a entrada do outro. Existem muitas linhas de programao seja em linguagem de mquina seja em linguagem de alto nvel para realizar esse comando que a primeira vista parece simples. Segue um exemplo de um cdigo que escuta a funo pipe. A funo 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;

John Von Neumann, nascido em Budapeste, 28 de dezembro de 1903 foi um matemtico hngaro de etnia judaica, naturalizado americano. Contribuiu na teoria dos conjuntos, anlise funcional, teoria ergdica, mecnica quntica, cincia da computao, economia, teoria dos jogos, anlise numrica, hidrodinmica das exploses, estatstica e muitas outras as reas da Matemtica. De fato considerado um dos mais importantes matemticos do sculo 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], "w" ) ) == 0 ) { perror( "fdopen failed" ); exit(1); } printf( "Please input a string:\n" ); while( scanf( "%s", token ) != EOF ) { if( fprintf( fout, "%s-Parent\n", token ) == EOF ) { perror( "fprintf failed" ); exit(1); } fflush( fout ); } close(1); /* fecha a referncia do pipe para enviar o EOF (End of File) */ wait(NULL); return(0); }

41

Vemos que o desenvolvimento de um cdigo para prover uma comunicao entre processo no trivial e envolve uma lgica considervel na comunicao em si, assim como na preveno de problemas inerentes a esse tipo de operao, como, por exemplo, ao realizar a comunicao, um processo no poder interferir na execuo do outro, necessitando assim que os processos sejam executados e troquem mensagens corretamente de modo a evitar conflitos na utilizao dos recursos computacionais. O propsito desse trabalho no ser entrar nos detalhes de programao, mas apenas para fins de exposio do princpio, vamos analisar de maneira no aprofundada o cdigo acima. Temos a diretiva include que usada para executar cdigos de programa previamente desenvolvidos, que so tratados pelo pr-processador antes da execuo do programa propriamente dito. Nesse caso temos, por exemplo, o cdigo stdio.h que responsvel por gerenciar os dispositivos padres de entrada/sada. Essas diretivas tambm so chamadas de bibliotecas da linguagem C. Dessas bibliotecas retiramos os comandos executados nos cdigos C. Aps as bibliotecas haverem sido carregadas em memria, algumas variveis so definidas, que para efeito de explanao do cdigo, nos ateremos apenas nas variveis p que seria de processo e pid que seriam o identificador de processo. A chamada de sistema pipe cria um tubo (pipe) entre um processo pai e um processo filho. Basicamente realizar a funo pipe seria usar a sada de padro de um processo como entrada para outro. O processo filho tem o processo nmero 1 que associado a um arquivo Pipe_newB. importante ressaltar o papel da funo dup2, que alm de fazer uma duplicao do processo filho original garante que o programa ter o uso da CPU sem interrupo, pela solicitao do kernel por algum outro processo, assim dizemos que esse processo torna-se atmico porque at o mesmo ser finalizado, o sistema como um todo no visualiza a alterao que est sendo realizada. Caso o processo falhe na sua execuo o sistema retorna a sua condio original. Retornando a funo pipe, em resumo, a sada da entrada padro (teclado) executado pelo programa pai escrita na entrada padro do processo filho (fd file descriptor) no arquivo Pipe_newB.

42

ponto

mais

importante

na

elucidao

desse

exemplo

de

comunicao

interprocessos conhecermos uma forma bsica de processos comunicarem-se, trocando parmetros e dados, assim como mostrar atravs de uma funo, o tratamento da questo de um processo interferir na execuo de outro, podendo gerar uma condio conhecida como race condition que veremos com mais detalhes frente. importante ressaltar que todas essas questes levantadas sobre a comunicao entre processos podem ser aplicadas tambm s threads.

Dificuldades na manipulao de processos num ambiente monoprocessado Mesmo no processamento convencional, existem desafios no desenvolvimento ou aperfeioamento de sistemas operacionais, no gerenciamento dos recursos da CPU, memria, dispositivos de E/S em face aos vrios processos que solicitam o uso dos mesmos, dando a impresso ao usurio que esses processos esto sendo executados paralelamente. Iremos abordar os principais problemas que so inerentes ao modelo computacional corrente e vivenciados na maioria das aplicaes. O objetivo conhecer essas dificuldades na computao monoprocessada que usualmente so acentuadas num ambiente de processamento distribudo. Vale a observao que estamos nos abstraindo nessa abordagem dos processadores que possuem dois ncleos (Dual-Core) ou mesmo os computadores multi-processados (com mais de um processador em seu barramento), pois essas tecnologias no so foco principal dessa anlise. Race Condition Race Condition quando dois ou mais processos esto lendo ou escrevendo em algum dado compartilhado e que o resultado vai depender do momento em que cada processo executado, podendo um sobrescrever a ao do outro, causando resultados inesperados e incorretos. A maneira bvia de se evitar essa distoro seria aplicar uma poltica de mtua excluso no acesso aos recursos.

43

A implementao de regies ou sees crticas para cada processo e a premissa que dois ou mais processos no podem acessar essas regies crticas ao mesmo tempo, ajudaria na minimizao do problema de race condition, mas no o evitaria para todas as situaes. Para podermos ter processos paralelos compartilhando os mesmos recursos de uma forma mais produtiva sem a race condition, sugere-se quatro condies: Dois processos no podem estar ao mesmo tempo em suas regies crticas. A no existncia de premissas sobre velocidade ou nmero de CPUs. Nenhum processo sendo executado fora da sua regio crtica pode bloquear outros. Nenhum processo pode esperar indefinidamente para entrar em sua regio crtica.

Deadlocks Deadlock um problema clssico na teoria e na prtica da computao. O deadlock tambm um problema inerente ao modelo de computao convencional relacionado alocao de recursos por um sistema operacional. 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. Por exemplo, se num banco de dados onde o processo um acessa o registro um e o processo dois acessa o registro dois e no prximo instante o processo um tenta acessar o registro dois e o processo dois tenta acessar o registro um, nesse momento os processos so bloqueados e ficaro nesse estado indefinidamente. Esse evento conhecido como deadlock. Coffman6 (COFFMAN, 1971) estabelece quatro condies para que ocorra um deadlock: Condio de excluso mtua. Cada recurso, ou est correntemente designado exatamente para um dado processo, ou est disponvel.

Eduard Grady Coffman professor de Cincia da Computao na Universidade de Columbia. Em 1994 ele foi nomeado membro da Association for Computing Machinery (ACM).

44

Condio de manuteno e espera. Processos que esto correntemente mantendo recursos anteriormente concedidos podem requisitar novos recursos. A falta de percepo de prioridade. Recursos previamente concedidos no podem ser forosamente tirados de um processo. Eles precisam ser explicitamente liberados pelo o processo que os mantm. Condio de espera circular. Deve haver uma corrente circular de dois ou mais processos, cada um esperando por um recurso mantido pelo prximo membro da corrente. Conseguiremos evitar o deadlock quando conseguirmos fazer com que uma dessas quatro condies no seja satisfeita. Existem vrias tcnicas e abordagens para a mitigao de deadlocks que no so foco do nosso trabalho, mas basta dizer que elas passam por uma poltica de alocao de recurso criteriosa assim como uma composio de tcnicas de deteco, anulao e preveno e aplicao de solues prticas com esse tipo abordagem, que evitariam, de modo eficiente, os deadlocks. (HOWARD JR.7, 1972).

John Hayes Howard Jr. autor do artigo Mixed solutions for the deadlock problem pela Universidade do Texas, Austin.

45

Problema do Jantar dos Filsofos Dijkstra8 (DIJKSTRA, 1971) elaborou um problema e concebeu uma soluo para situaes passveis de se ocorrer no acesso aos recursos pelos processos. A ilustrao bem simples. Temos cinco filsofos numa mesa de jantar com cinco pratos de espaguete e cinco garfos, porm o espaguete muito escorregadio, sendo necessrios dois garfos para poderem com-lo. primeira vista, a soluo do problema seria simples, teramos que ter apenas um algoritmo que testasse quando os dois garfos estivessem disponveis, assim o filsofo poderia utiliz-los. Infelizmente a soluo no to simples assim. Imaginem se os cinco filsofos ao mesmo tempo verificassem que os garfos esto disponveis e consequentemente tentam utiliz-los. Eles no tero os dois garfos disponveis para si e os processos entraro em deadlock. Podemos aprimorar essa soluo no exitosa colocando a premissa de que ao pegar o garfo ao lado esquerdo do prato, o filsofo verifica se o garfo ao lado direito est disponvel, caso negativo, ele devolve o garfo do lado esquerdo mesa. Essa parece ser uma boa abordagem para o problema, mas imagine se os cinco filsofos resolvam ao mesmo tempo pegar o garfo a sua esquerda e testar se o garfo a sua direita est disponvel. Eles iro constatar que o garfo a sua direita no est disponvel e devolvero mesa o garfo a sua esquerda. Essa situao continuar indefinidamente, entrando os processos numa condio conhecida como starvation quando os programas so executados continuamente, sem, porm, conseguir realizar qualquer progresso efetivo no andamento dos mesmos, em suma, o programa simplesmente no executado. Uma ideia seria os filsofos (processos) esperando um tempo aleatrio para pegar o garfo a sua esquerda, como feito em redes locais. Antes de pegar qualquer garfo, o filsofo entraria numa condio de down num semforo mutex (excluso mtua), assim nenhum outro filsofo (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 (filsofos).

Edsger Wybe Dijkstra um cientista neerlands em computao. Ele recebeu em 1972 o Turing Award por contribuies fundamentais para o desenvolvimento de linguagens de programao, detendo a Schlumberger Centennial Chair em Cincias da Computao na Universidade do Texas de 1984 a 2000.

46

Essa soluo previne efetivamente os deadlocks e starvation, porm no eficaz, pois considerando os recursos (pratos e garfos), dois filsofos poderiam comer ao mesmo tempo e nesse caso apenas um comeria por vez. Uma soluo mais eficaz para o problema do Jantar dos Filsofos seria utilizarmos um array que controla os estados dos filsofos que seriam: comendo, pensando ou com fome (tentando pegar os dois garfos). Um filsofo s poderia pegar os garfos se nenhum de seus vizinhos estiver comendo. Essa soluo contempla um array de semforos para cada filsofo. So definidas macros para identificar os vizinhos de cada filsofo. Por exemplo, se o processo do filsofo o dois, seu vizinho da direita seria 1 e o da esquerda 3. Segue um cdigo que aplica a soluo para o problema do Jantar dos Filsofos: #define N #define LEFT #define RIGHT #define THINKING #define HUNGRY #define EATING 5 /* nmero de filsofos */ (i+N1)%N /* nmero de i's esquerda do vizinho */ (i+1)%N /* nmero de i's direita do vizinho */ 0 /* filsofo est pensando */ 1 /* filsofo est tentando pegar os garfos */ 2 /* filsofo est comendo */ /* os semforos so tipos de especiais de int */

typedef int semaphore; int state[N];

/* array para verificar o estado de todos os filsofos */ /* mutual excluso para regio crticas */ /* um semforo por filsofo */

semaphore mutex = 1; semaphore s[N];

void philosopher (int i) /* i nmero de filsofo, de 0 a N1 */ { while (TRUE) { think(); /* repete indefinidamente*/ /* filsofo est pensando */

47

take_forks(i); eat(); put_forks(i); } } void take_forks(int i) { down(&mutex);

/* pega dois garfos ou bloqueia */ /* comendo espaguete */ /* coloca os garfos de volta mesa */

/* i nmero de filsofo, de 0 a N1 */

/* entra em regio crtica */ /* registra que o filsofo i est com fome */

state[i] = HUNGRY; test(i); up(&mutex); down(&s[i]); } void put_forks(i) { down(&mutex);

/* tenta pegar os dois garfos */ /* sai da regio crtica */ /* bloqueia se os garfos no foram pegos */

/* i nmero de filsofo, de 0 a N1 */

/* entra em regio crtica */

state[i] = THINKING; /* filsofo termina de comer */ test(LEFT); test(RIGHT); up(&mutex); } void test(i) { /* i nmero de filsofo, de 0 a N1 */ /* verifica se o vizinho da esquerda pode comer agora */ /* verifica se o vizinho da direita pode comer agora */ /* sai da regio crtica */

48

if (state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] != EATING) { state[i] = EATING; up(&s[i]); } } Os comentrios sobre cdigo acima so autoexplicativos, porm algumas linhas do cdigo valem ser ressaltadas. Temos um while principal com funes para as quatro atividades dos filsofos que so: pensando, pegando os garfos, comendo e colocando os garfos de volta na mesa. Na funo take_forks, vemos um teste para verificar se os garfos esto disponveis e a deciso de pegar os talheres ou no associadas colocao do semforo no estado de down ou up. Na funo put_forks vemos a execuo da funo test para verificar se o filsofo vizinho da direita ou d esquerda podem pegar os garfos, assim a funo test verifica se os vizinhos no esto comendo, para que o filsofo possa entrar do estado de EATING. Existem abordagens mais recentes para esse problema como Software Visualization que uma programao visual, baseada em semitica e os recursos de linguagens de programao como a Parlog86.

Problemas de leitores e escritores Esse problema est muito ligado ao acesso a banco de dados. Quando temos um banco de dados, podemos ter vrios acessos de leitura, mas apenas um de escrita por questes bvias, pois se tivermos vrios acessos de escrita mesmo em registros diferentes ou ainda no mesmo registro, mas em intervalos muito pequenos, teremos um banco de dados inconsistente, alm disso, essa condio seria muito propcia a deadlocks. A soluo clssica para esse problema relativamente simples. Temos dois semforos, um que poderia ser chamado db e outro mutex, o primeiro para controlar o acesso de escrita ao banco e o segundo para controlar os acessos de leitura. Quando o primeiro leitor acessar o banco, coloca em down o semforo db e incrementa o contador de leitores no semfora mutex.

49

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 condio do semforo 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 no tenhamos uma quantidade muito elevada de acessos de leitura ao banco, pois do contrrio, nunca ocorrer um acesso de escrita devido condio de mtua excluso entre os dois processos. Uma soluo para essa fragilidade do algoritmo seria quando um leitor for acessar o banco e j houver um processo de escrita esperando a liberao do mesmo, esse processo colocado em espera, sendo executado s aps a liberao e execuo do processo de escrita, dessa forma o escritor s esperaria pelos processos de leitura que j estivessem em execuo na sua chegada. Um ponto fraco dessa abordagem que, apesar dela diminuir a concorrncia entre processos, tem o desempenho comprometido. Segue o cdigo que apresenta a soluo 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 */ /* obtm acesso exclusivo ao 'rc' */ /* mais um leitor agora */ /* se esse o primeiro leitor */ /* os semforos so tipos de especiais de int */ /* controla o acesso ao 'rc' */ /* controla o acesso ao banco de dados */ /* nmero 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 */ /* obtm 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 */ /* regio no crtica */ /* obtm acesso exclusivo */ /* atualiza os dados */ /* libera acesso exclusivo ao 'rc' */ /* regio no-crtica */

/* libera acesso exclusivo */

Vale ressaltar que nesse cdigo a verificao feita pela funo if da ocorrncia de finalizao do ltimo processo de leitura, que libera o acesso exclusivo ao banco, colocando o semforo mutex em up, para que caso houver um escritor em condio de espera, o mesmo coloque o semforo em down (acesso exclusivo) e inicie a gravao no banco de dados. Existem variaes nesse cdigo justamente para privilegiar seja o controle de acesso aos recursos seja o desempenho do processo, como j discutido.

51

O cdigo acima no 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 situao. Temos uma barbearia com apenas um barbeiro, uma cadeira de barbeiro e n cadeiras de espera. Se no h clientes, o barbeiro senta na cadeira de barbeiro e dorme. Se um cliente chega, ele acorda o barbeiro que comea cortar o seu cabelo. Se outros clientes chegam enquanto o barbeiro est realizando um corte, eles sentam nas cadeiras de espera ou saem se no houver cadeiras de espera disponveis. O problema criar uma lgica de modo a programar o barbeiro e os clientes sem entrar numa condio de corrida (race condition). Esse problema similar a muitas situaes de controle de filas, como por exemplo, um software de controle de ligaes num Call Center. Uma soluo para esse problema utilizaria trs semforos: clientes que conta os clientes aguardando (excluindo o cliente na cadeira de barbeiro), barbeiros, nmero de barbeiros (0 ou 1) que pode ficar numa condio de ocioso (dormindo) ou trabalhando(cortando cabelo) e mutex que usado como excluso mtua. necessrio ainda a varivel waiting que conta tambm a quantidade de clientes esperando, que essencialmente uma cpia dos clientes. A razo para essa varivel a impossibilidade de ler um valor corrente de um semforo. Nessa soluo, um cliente que entra na barbearia tem de contar o nmero de clientes esperando. Se for menor que o nmero de cadeiras, ele permanece, caso negativo, ele deixa a barbearia.

52

Segue um cdigo que contempla a soluo 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); /* obtm o acesso varivel waiting */ /* entra no estado de dormindo se o nmero de clientes /* nmero de cadeiras para clientes esperando */ /* os semforos so tipos de especiais de int */ /* nmero de clientes esperando pelo servios */ /* nmero de barbeiros esperando por clientes */ /* para excluso mtua */ /* clientes esto esperando (no 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 regio crtica */ /* se no h cadeiras livres, saia */ /* um barbeiro est pronto para cortar um cabelo */ /* libera a varivel 'waiting' */ /* corta cabelo (fora da regio crtica) */

53

waiting = waiting + 1; /* incrementa a contagem de clientes esperando */ up(&customers); up(&mutex); down(&barbers); get_haircut(); } else { up(&mutex); } } Nesse cdigo podemos ressaltar os seguintes pontos: o cdigo barber que um loop que na medida em que se vai cortando o cabelo dos clientes vai decrementando o nmero dos mesmos e tambm liberando a funo waiting; o cdigo costumer que testa o nmero total de cadeiras para verificar se maior que o nmero de clientes esperando atravs do operador if, caso nmero de cadeira for menor ou igual ao nmero de clientes esperando, nega-se o acesso do cliente (processo) atravs do semforo mutex. Na teoria de sistemas operacionais existem vrias outras situaes usualmente ilustradas atravs de exemplos envolvendo objetos, pessoas e aes, que passam a ser elementos de uma representao de um problema de comunicao interprocessos. Apenas a ttulo de informao temos o problema dos fumantes (PATIL9, 1971) onde temos trs fumantes e um agente, onde cada fumante tem indefinidamente apenas dois dos trs elementos que os habilitaria a fumar, a saber, o papel, o tabaco e o fsforo. O agente em cada ciclo disponibiliza um elemento que compe um cigarro pronto para ser fumado. Por exemplo, se o agente disponibilizar o fsforo, o fumante que tiver o papel e o tabaco, toma o fsforo e compe o cigarro pronto para ser fumado. O mesmo processo ocorreria com os outros fumantes. /* a barbearia est cheia; no espere */ /* acorda o barbeiro se necessrio */ /* libera o acesso varivel 'waiting' */ /* dorme se o nmero de barbeiros livres 0 */ /* est sentado e atendido */

Dr. Suhas S. Patil nascido em 1944 em Jamshedpur, Jharkhand, India, um empreendedor no Silicon Valley, investidor e filantropo. Ele fundou a companhia Cirrus Logic. Recebeu seu bacharelado em engenharia no Indian Institute of Technology, mestrado e doutorado no MIT.

54

Nessa alegoria, o agente seria o sistema operacional e os fumantes processos ou threads. Esse problema resolvido, como usual, utilizando semforos, um para cada item do cigarro e um mutex. Podemos tambm citar o problema do Jantar dos Canibais, onde os canibais tm no caldeiro certa quantidade M de missionrios cozidos, quando o canibal est com fome, ele vai at o caldeiro e se o mesmo estiver provido de missionrios ele come, seno ele acorda o canibal cozinheiro para preparar mais missionrios cozidos. Nesse caso temos como soluo possvel, uma que utilizaria um semforo para controlar o caldeiro cheio, um semforo para controlar o caldeiro vazio e um semforo mutex. Eles so sincronizados adequadamente atravs de uma funo while. Os problemas apresentados at o momento em ambientes monoprocessados e suas respectivas solues adquirem novas facetas quando os tratamos em ambientes de processamento distribudo, com solues distintas, mas importante termos esses conceitos claros para podermos explorar com mais clareza os mecanismos de sincronizao e preveno da ocorrncia de deadlocks, race condition e starvation em ambiente de cluster.

Escalonamento de processos ou threads Um dos desafios em se desenvolver um sistema operacional estabelecer o escalonamento dos processos, isto , quando e por quanto tempo um processo far uso dos recursos da CPU. Para ns compreendermos o conceito de escalonamento precisamos conhecer que existem dois tipos de processos relacionados a esse tema, processos computer-bound e processos I/O bound, o primeiro possuindo longas rajadas de utilizao de CPU com espordicos usos de E/S e o segundo com curtas rajadas de uso de CPU e freqentes usos de E/S. Naturalmente os processos I/O bound possuem um melhor uso e desempenho de CPU, pois enquanto os processos esto utilizando algum dispositivo de E/S, a CPU pode tratar e executar outros processos.

55

A necessidade do escalonamento Na criao de um processo. Existe a deciso de quem ser tratado primeiro, o processo pai ou processo filho. Na necessidade de decidir qual processo ser tratado entre aqueles que esto prontos quando um processo deixa de utilizar os recursos. Quando um processo bloqueado por dispositivo de E/S, por um semforo ou por qualquer outra razo, outro processo precisa ser escolhido para ser executado em seu lugar. Quanto uma interrupo de E/S ocorre, o dispositivo de escalonamento precisa decidir se o processo que estaria esperando a interrupo de E/S ser executado ou outro processo ter a prioridade no uso da CPU. As decises tomadas pelo dispositivo de escalonamento ocorrem a cada ciclo de clock do processador. Temos tambm os conceitos de dispositivos de escalonamento preemptivos e no preemptivos. Um dispositivo de escalonamento no-preemptivo executa o processo indefinidamente at ele ser bloqueado, por exemplo, aguardando outro processo, ou quando ele libera o recurso voluntariamente. J o escalonamento preemptivo estabelece um tempo de execuo para cada processo, tendo a autonomia para parar o processo e para passar o tempo de acesso CPU para outro. Podemos considerar trs ambientes que requerem escalonamentos distintos: Em lote Interativo Tempo Real Existem algumas caractersticas que so desejveis para qualquer tipo de processamento que seriam equidade, o cumprimento da poltica estabelecida e o uso mximo de todos os recursos, isto , a CPU, memria, dispositivos de E/S (entrada e sada) que devem ser utilizados o maior tempo possvel.

56

Escalonamento em processamento em lote Esse tipo de processamento no muito utilizado ultimamente, a no ser em computadores de grande porte (mainframes). Porm podemos afirmar que renderizao de imagens pode ser considerada como um processamento batch, sendo uma das aplicaes das mais utilizadas em clusters com um desempenho satisfatrio. Provavelmente um dos mais simples algoritmos de escalonamento seria o primeiro que chega; primeiro a ser processado, por certo esse uma tcnica no preemptiva de escalonamento. O primeiro processo que requisita o uso da CPU, tem o uso da mesma at a finalizao ou bloqueio do mesmo para, por exemplo, acessar algum dispositivo de E/S. Quanto isso ocorre o processo que est na primeira posio numa fila passa a ser atendido. Esse algoritmo embora de simples implementao, tem uma srie de fragilidades e situaes em que teria um desempenho no satisfatrio. Outro algoritmo seria o menor job primeiro. Apesar de no ser preemptivo, ele prioriza os processos menores, fazendo assim que o sistema tenha um melhor desempenho como um todo. Porm o desempenho desse algoritmo depende da sequencia em que os processos chegam e so tratados. Uma verso preemptiva do menor job primeiro seria o menor tempo restante para ser finalizado, nesse caso o sistema precisa saber previamente qual o tempo restante de cada processo. Se um job chega e tem um tempo para ser finalizado menor do que est em execuo, o job em execuo bloqueado e o que chega executado. Com essa verso obtm-se um bom desempenho para pequenos jobs. Temos tambm o processo de escalonamento em trs nveis, onde um escalonador de admisso (admission scheduler) decide qual job ser aceito pelo sistema, os no aceitos naquele momento, so colocados numa fila de entrada at serem selecionados. O escalonador precisa distinguir entre jobs CPU-bound e jobs I/O bound. Esse mecanismo seria o primeiro nvel de escalonamento. Quando os jobs so colocados em fila, eles so convertidos em processos e postos em memria. Podemos chegar numa condio que no teremos mais espao em memria para colocar os processos em espera, dessa forma eles so armazenados em disco, mecanismo conhecido como swap de memria ou paginao.

57

O segundo nvel de escalonamento o decide qual processo ser colocado ou no em memria, tambm chamado de escalonamento de memria. O terceiro nvel de escalonamento o que decide qual processo em memria ser o prximo a ser executado. Existem outros algoritmos de escalonamento como o Backfilling que em linha geral procura executar alguns processos que no esto no topo da fila, visando um melhor aproveitamento da CPU. Temos tambm 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, que seria o tempo que o job estabelece para ser executado.

Escalonamento em Sistemas Interativos Quando pensamos em algoritmos para escalonamento em sistemas interativos, podemos utilizar os mesmos algoritmos para escalonamento de CPU em sistemas de processamento em lote. No conseguimos ter em sistemas interativos o processo de escalonamento em trs nveis, mas podemos ter dois nveis nesse tipo de sistema (escalonamento de memria e escalonamento de CPU). As tcnicas de escalonamento para Sistemas Interativos usualmente focam mais no escalonamento de CPU. Escalonamento round robin: Esse algoritmo um dos mais antigos, simples, imparcial e amplamente utilizado para escalonamento. Para cada processo dado um intervalo de tempo chamado quantum durante o qual o mesmo pode ser executado.

58

O nico parmetro com o qual se pode realizar algum ajuste a durao do quantum. Num raciocnio simples, se estabelecemos um quantum muito curto, teremos um chaveamento excessivo de processos, diminuindo a eficincia da CPU, pois a cada troca de processo, um tempo de CPU utilizado para liberar e alocar memria, registradores, tabelas, listas, etc. Ao passo que caso se estabelea um quantum muito longo teremos um tempo de resposta inaceitvel para processos de curta durao. Podemos pensar num quantum entre 20 a 50 milissegundos como um valor razovel para esse tipo de escalonamento. Escalonamento por prioridade: No escalonamento round robin partimos da premissa que todos os processos so igualmente importantes. No escalonamento por prioridade, atribuda uma prioridade para cada processo, assim o processo que est pronto para ser executado e com a maior prioridade, processado pela CPU. Como preveno contra processos sendo executados indefinidamente, a cada ciclo de clock a prioridade do processo decrementada ou pode-se tambm trabalhar com o conceito de quantum, quando tempo destinado ao processo acabar, o processo em espera com a maior prioridade executado. As prioridades poder ser atribudas esttica ou dinamicamente. Quando falamos de atribuio esttica de prioridade, estamos considerando o tipo de usurio ou atividade que requer maior ou menor prioridade. Por exemplo, se pensarmos num sistema em que os processos tratam de cifras, provavelmente os processos que trabalharem com os maiores valores tero uma prioridade maior. J na atribuio dinmica de prioridade, informaes sobre a caracterstica do processo, isto , se ele I/O-bound ou CPU- bound, assim como quanto tempo ele utiliza do quantum que alocado para ele, estabelecem a prioridade de cada processo.

59

Mltiplas filas Outra estratgia de escalonamento para sistemas interativos utilizar mltiplas filas, atribuindo certa quantidade de quantums para cada uma delas. O processo com a maior prioridade receber apenas um quantum no primeiro ciclo de processamento. No prximo ciclo receber dois quantums, no prximo ciclo, o processo com maior prioridade receber quatro quantums, assim por diante. Assim se um processo com a mais alta prioridade precisa de cem quantums para realizar um job, ele receber um quantum no seu primeiro ciclo de processamento, no prximo dois quantums, depois quatro, oito, dezesseis, trinta e dois, sessenta e quatro quantums at finalizar o seu job. Esse algoritmo evita que um processo monopolize a utilizao dos recursos, especialmente de CPU, quando tem uma alta prioridade. O prximo processo mais curto (Shortest Process Next) Esse algoritmo pode tambm ser usado em processos em lote, que utiliza a tcnica de executar os processos mais curtos primeiro que produz bons tempos mdios de resposta nesse tipo de processo. A ideia desse algoritmo utilizar a caracterstica de processos interativos onde temos sucessivas situaes de execuo de um comando e uma resposta para o mesmo. Podemos assim considerar essas execues como jobs separados e assim trat-los com prioridade. Mas precisa-se estabelecer um critrio ou uma tcnica para determinar a durao dos processos. Uma abordagem seria considerar o comportamento anterior do processo, calculando uma mdia ponderada dos tempos de execuo passados. Nessa tcnica pode-se escolher quantos processos j executados sero considerados no clculo. Essa tcnica utilizada em outras aplicaes, como, por exemplo, protocolos de rede, conhecida como aging. Escalonamento garantido Essa tcnica procura literalmente dividir o tempo de CPU entre os processos que esto em execuo em dado momento. Para fazer isso o sistema computa quanto tempo de CPU o processo consumiu na sua criao depois simplesmente divide esse tempo por n que seria o nmero de processos que esto em execuo. Assim dependendo da quantidade de processos em execuo, cada um deles receber igualitariamente ciclos de processamento da CPU, podendo assim receber menos ou mais tempo dependendo da quantidade dos processos concorrentes.

60

Escalonamento lotrico Embora efetivo em termos de resultados, o escalonamento garantido de difcil implementao. Assim surgiu outro algoritmo com os mesmos resultados previsveis, mas com uma implementao muito mais simples, conhecido Escalonamento Lotrico. A ideia simples, cada processo recebe uma quantidade de bilhetes que permitem acesso a CPU. Esses bilhetes so escolhidos aleatoriamente, dando o direito de ter 20 milissegundos de uso do processador. Para processos que precisam ter prioridade dado um nmero maior de bilhetes, aumentando assim a probabilidade dos mesmos serem escolhidos e automaticamente dando mais tempo de CPU para eles. Os processos podem trocar bilhetes num ambiente onde esto trabalhando em cooperao. Essa uma tcnica bastante responsiva e eficiente. Escalonamento de compartilhamento justo (Fair-Share Scheduling) Os algoritmos at aqui analisados consideraram apenas os processos em si mesmos, no considerando os usurios que os executam. Mas isso pode influir significamente num compartilhamento adequado de uma CPU. Por exemplo, se usurio ativa 9 processos e o outro 1 processo. O primeiro ter 90% do uso da CPU e o segundo apenas 10%. Para prevenir esse tipo de condio alguns sistemas consideram no escalonamento a quem pertencem os processos. Assim se for garantido para 2 usurios 50% da CPU, eles tero esse recurso contratado independente de quantos processos cada um colocar em execuo.

61

Escalonamento em sistemas em tempo real Sistemas em tempo real, usualmente recebem uma requisio a qual precisa ser respondida num intervalo de tempo muito curto, como por exemplo, a execuo de uma msica de um CD, uma resposta de um jogo de computador a uma ao de quem est o executando, etc. Eles podem ser divididos em hard real times que so aqueles totalmente rgidos em relao 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. Em linhas gerais, os processos em tempo real so conhecidos a - priori quanto ao comportamento e tempo de execuo, usualmente so de execuo curta no ultrapassando a um segundo. Os processos so 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. Os sistemas em tempo real podem ser peridicos que possuem intervalos regulares entre os processo e aperidicos em que os intervalos so imprevisveis. Obviamente os sistemas peridicos so mais fceis de serem implementados e podem ser calculados pela seguinte frmula:

Frmula 1 Onde m so os eventos peridicos onde o evento i ocorre no perodo Pi e requer Ci segundos para executar cada evento. Se um sistema em tempo real satisfizer as condies dessa frmula, dizemos que ele escalonvel (schedulable).

62

Quando falamos em sistemas em tempo real, podemos considerar o tema multimdia como central. Todos os sistemas multimdias requerem uma execuo dos processos em intervalos curtos e peridicos para garantir uma boa imagem e som como resultado. Assim os sistemas digitais encontrados nos CDs e especialmente nos DVDs so exemplos clssicos de dispositivos que demandam um processamento em tempo real. Temos como um avano uma tecnologia ainda em difuso que o Video on Demand (VoD) que apesar ser uma soluo muito interessante chega ainda a poucos lares de usurios, pelo menos no Brasil. O sistema consiste em servidores com uma capacidade significativa de disco, na ordem de Terabits, que armazenam arquivos de som e imagem nos mais diversos formatos, tendo conexes de relativa velocidade, pelo menos 1 Mbps (megabits por segundo) com os assinantes que podem assistir em tempo real o contedo dos Vdeos Servers. Como servidores VoD e IPTV podem ser implementados em clusters de Linux, abordaremos esses temas nesse trabalho. Em primeiro lugar, precisamos estabelecer a diferena entre as tecnologias. Enquanto o VoD seria um repositrio vdeos armazenados podendo ser comparado a uma grande biblioteca de DVDs transmitindo usualmente atravs pacotes unicasts que uma transmisso de pacotes um para um, a IPTV a transmisso de streams de vdeo podendo ser ao vivo atravs de multicast que uma transmisso de pacotes de um para muitos. Dessa forma IPTV consome muito menos banda passante do que a VoD devido a modo de transmisso que utiliza. Em termos de uso da populao em geral, o IPTV mostra-se mais difundido. Nos ltimos anos temos visto um crescimento mais consistente do uso dessa tecnologia, especialmente com a consolidao e difuso dos aparelhos IPTV. Estimase que teramos cerca de 60 milhes de usurios em todo o mundo que utilizaro essa tecnologia em 2009 (Parks Associates). Esse aumento de procura est ligado oferta de triple-play (Voz Telefone, Dados Internet e Imagem TV) por algumas operadoras e tambm a interatividade proporcionada pela IPTV. Alm disso, a tecnologia de IPTV est migrando para outras aplicaes como, por exemplo, IP Surveillance (Vigilncia), onde a IPTV uma componente dessa soluo, substituindo os tradicionais circuitos fechados de TV.

63

Avanando um pouco mais nas diferenas das tecnologias enquanto o VoD utiliza o RSTP (real-time streaming protocol) para a sinalizao e RTP (real-time protocol) para a transmisso do fluxo (stream) de vdeo que so protocolos originalmente utilizados em Voz sobre IP (VoIP), a IPTV utiliza o IGMP (Internet Group Management Protocol) que um protocolo para controle de multicast em redes locais. Apesar de diferenas significativas as duas tecnologias compartilham quase os mesmos problemas quando tratamos de qualidade de Voz e Imagem, que seria o atraso, a perda de pacotes e especialmente o jitter que seria a variao dos intervalos entre os pacotes de fluxo de vdeo e de voz que mais prejudicial qualidade do servio do que um atraso constante dos pacotes mesmo que sejam mais longos. Existem tcnicas na engenharia de redes para prover qualidade de servio para aplicaes sensveis ao tempo (QoS), que visam garantir prioridade e intervalos regulares entre esse tipo de trfego. Tambm esse tipo de prioridade tambm precisa ser garantida nos servidores que alojam esse tipo de aplicao, seja na computao convencional, seja em sistemas distribudos. Grande parte da tecnologia para sistemas em tempo real est no formato, compresso e correo de erros dos arquivos multimdia. Sem esses recursos seria impossvel termos capacidade de armazenagem e transmisso desses arquivos assim como uma qualidade de Voz e Imagem aceitveis. Para entendermos como so estruturados os arquivos multimdia, precisamos conhecer como eles so codificados, ou como a imagem e o som que a princpio so sinais analgicos so transformados em sinais digitais para que sejam tratados por computadores e sistemas de redes. Codificao de udio Em termos simples, a codificao de udio seria transformar um sinal eltrico analgico que corresponde a determinado som, numa sequencia de cdigos digitais, portanto 0s e 1s que correspondem tomadas por amostragem das amplitudes desse sinal no tempo (sampling). Usaremos a digitalizao de uma senide para ilustrar o conceito.

64

Figura 1 Na figura 1, no grfico a temos a escolha dos pontos de amostragem do sinal, no grfico b temos esses pontos transformados em cdigos binrios simbolizados pelas linhas verticais, no grfico c temos o resultado real de um processo de sampling que nunca corresponder exatamente ao sinal original, mas que para sensibilidade do ouvido humano corresponde a uma qualidade de udio muito prxima do sinal analgico original como ilustrado no grfico d. Podemos pensar em aumentar o nmero de amostragens, porm isso gera um tipo de distoro conhecida como rudo de quantizao. Como exemplos de codificao, podemos utilizar a codificao de telefonia analgica e de Compact Disks (CDs). A telefonia utiliza a tcnica de digitalizao de voz conhecida como PCM (Pulse Code Modulation) que utiliza amostragens de 7 bits (Estados Unidos e Japo dentre outros) e 8 bits (Europa e Brasil dentre outros) 8.000 vezes por segundo, gerando respectivamente canais digitais de Voz de 56 e 64 Kbps (kilobits por segundo). Com essa codificao sinais acima de 4 kHz so perdidos, porm apesar da faixa de frequncia audvel ser de 20 Hz a 20 kHz, conseguimos uma qualidade de Voz razovel com essa tcnica de codificao. Quando falamos em CDs temos 44.100 amostragens por segundo que nos d uma faixa de frequncia na ordem de 22 kHz, com certeza provendo uma qualidade de udio muito superior ao das ligaes telefnicas que utilizam canais digitais.

65

Temos tcnicas de compresso de Voz que proporciona economia em armazenagem e na transmisso desse tipo de arquivo como, por exemplo, os protocolos G.729 ou G.726 para telefonia e o muito conhecido MP3 (MPEG Layer 3) para compresso de msicas, falas, etc. De modo geral as tcnicas de compresso de Voz trabalham com a reduo da redundncia da informao atravs de mtodos como codificao, reconhecimento de padres e predio linear para reduzir o tamanho dos arquivos a serem executados ou pacotes a serem transmitidos. Codificao de vdeo Para entender a digitalizao de imagens precisamos conhecer os conceitos bsicos da transmisso e recepo eletrnica de vdeo, isto , o modo de processamento de imagens nos televisores e monitores convencionais de computador. Abstraindo-nos dos conceitos da eletrnica ao mximo possvel, pois no o foco de nosso trabalho, um televisor ou mesmo um monitor convencional possuem um Tubo de Raios Catdicos (CRT - Cathode Ray Tube). Numa TV temos o que chamamos varredura vertical e horizontal que seria a composio quadro a quadro das imagens, nos dando a impresso de movimento. O conhecido sincronismo vertical e horizontal determina em que ponto da tela a imagem est sendo composta, por isso quando dizemos que existe um problema de sincronismo, temos como resultado uma imagem indistinta ou at mesmo apenas faixas na tela. No sistema PAL temos uma frequncia de 25 quadros/sec. Com essa velocidade de troca de quadros temos uma imagem trmula. Os televisores utilizam a tcnica conhecida como intercalamento (interlacing), as linhas pares so transmitidas num quadro e as linhas mpares num outro. Assim temos uma frequncia de 50 quadros/sec que elimina a impresso de tremor da imagem aos olhos humanos. O desenho da imagem composto atravs do bombardeamento de eltrons numa superfcie fosforescente que gera um ponto brilhante na tela.

66

Esses pontos compem as imagens atravs do desvio de suas trajetrias por eletromagnetismo provido por um componente eletrnico conhecido como bobina defletora. Nos televisores coloridos temos 3 canhes de eltrons com as cores RGB (Red, Green, Blue) que conseguem compor todas as outras cores, curiosamente no sendo as cores conhecidas popularmente como primrias que seriam o vermelho, o azul e o amarelo, pelo menos nas artes plsticas. Apenas a ttulo de esclarecimento, o reconhecimento das cores primrias no um conceito fsico mais fisiolgico relacionado reao do olho em relao luz e seus diversos comprimentos de onda que compe um nmero quase infinito de cores. O olho humano tem trs receptores de luz conhecidos como cones, sendo que cada um deles respondem ao comprimento de onda das cores vermelha, verde e azul sendo essas consideradas como primrias tratando-se de fontes de luz, por isso que os tubos de imagem utilizam o padro RGB. Tratando-se de monitores de computador, apesar de possurem o mesmo aparato eletrnico dos televisores, diferentemente desses, eles traduzem sinais digitais em imagem. Os monitores de computador trabalham com o conceito de pixel que o menor elemento que compe uma imagem ou caractere num monitor de computador, por exemplo, se um cone tem 32 pixels de altura e 32 pixels de largura ele conter um total de 1024 pixels. As imagens so formadas nos computadores, atravs de variaes de cor e brilho, tambm conhecidos como crominncia e luminncia dos pixels. Para garantir a persistncia da imagem adequada ao olho humano, como j mencionado, precisamos ter pelos 25 quadros/sec utilizando a tcnica de intercalamento, porm como os computadores podem armazenar as imagens em memria, consegue-se obter uma frequncia de troca de quadros de 75 vezes por segundo, no necessitando assim do intercalamento. Assim dizemos que os monitores de computador utilizam um escaneamento progressivo.

67

Os monitores de computador tm o conceito de resoluo que seria quantas linhas o monitor teria na vertical e na horizontal, por exemplo, um monitor com resoluo 800x600 significa que tem 800 linhas na vertical e 600 linhas na horizontal. Obviamente quanto mais linhas ou quanto maior a resoluo, melhor a qualidade de imagem. Quantidade de bits para compor uma imagem usualmente alta, uma imagem num monitor com resoluo de 1024x768 tendo um pixel com tamanho de 24 bits, numa frequncia de 25 quadros/sec, necessitaria de 472 Mbps para ser transmitida. Da a obrigatoriedade tecnolgica de trabalhar com compresso de imagens nos computadores e nas redes. Compresso de Vdeo Todo sistema de compresso de arquivos de imagem precisa ter dois algoritmos: um de compresso e outro de descompresso, na literatura em geral, eles so chamados de codificao (encoding) e decodificao (decoding). Entre esses dois algoritmos temos o conceito de assimetria, por exemplo, se estivermos falando VoD, o sistema de codificao pode ser lento e despender um hardware mais poderoso e caro, porm o processo de decodificao precisa ser rpido e concebido para ser executado num hardware mais acessvel em termos de preo. Por outro lado, um sistema de vdeo conferncia precisa ter tanto a codificao e a decodificao em tempo real, necessitando assim de hardware e software apropriados para esse tipo de aplicao. Um segundo tipo de assimetria na compresso de vdeo, seria que a imagem originalmente codificada no precisa necessariamente ser exatamente igual quando a mesma for decodificada, de fato isso raramente ocorre, porm tal assimetria aceitvel em termos de acuidade do olho humano. H na maioria dos casos uma leve perda de qualidade entre a imagem original e a que visualizada aps ser descomprimida num determinado sistema, quando isso ocorre dizemos que o sistema lossy. De fato, os codificadores de uso geral e comercial so todos lossies, mas existem lossless codecs na compresso de vdeo.

68

Padro JPEG Um dos mais conhecidos padres de compresso de imagem o JPEG (Joint Photographic Experts Group). O processo de compresso do JPEG no trivial assim apresentaremos o mesmo de uma forma simples, de modo a satisfazer o propsito desse trabalho no que concerne codificao de imagem. Existem muitos padres para produzir-se esse tipo de arquivo, mas o mais utilizado o JFIF (JPEG File Interchange Format). Segue uma descrio sucinta desse processo de codificao: A representao das cores traduzida do padro RGB para YCbCr, que so modelos matemticos conhecidos como espaos de cores (Color Spaces) , sendo sistemas arbitrrios de cores, no utilizados na interpretao usual das mesmas. No caso do modelo YCbCr, o Y que o componente de luminncia representando o brilho e dois componentes de crominncia (Cb e Cr) representando a cor. Lembrando que esse padro utilizado na codificao das imagens de TV Digital e DVD, sendo similar ao padro PAL de televiso analgica. A resoluo da crominncia reduzida, normalmente pela metade. Isso reflete o fato que os olhos so menos sensveis a pequenas alteraes na cor do que pequenas alteraes no brilho. A imagem dividida em blocos de 8x8 pixels e cada bloco, dados os componentes Y, Cb e Cr dos mesmos, passam por uma transformada conhecida como DCT (Discrete Cosine Transform). Uma transformada DCT similar transformada de Fourier que produz um tipo de espectro de frequncia espacial. A razo de se utilizar esse recurso matemtico que trabalha com 3 dimenses (espacial) porque na codificao do JPEG temos 3 elementos, a representao YCbCr. Os componentes da amplitude da frequncia so quantizados, que a representao numrica de um sinal analgico. O olho humano muito mais sensvel a pequenas variaes de cor e brilho em reas amplas do que variaes em alta frequncia de brilho. Portanto, a magnitudes dos componentes de alta frequncia so armazenadas com menor acuidade do que componentes de baixa frequncia. A qualidade estabelecida no codificador (por exemplo, 50 ou 90 numa escala de 0 a 100 na biblioteca do Independente JPEG Group) afeta o quanto a resoluo de cada componente de frequncia ser reduzido. Se uma configurao de excessiva baixa qualidade for utilizada, todos os componentes de alta frequncia so descartados de uma vez.

69

Os dados resultantes dos blocos 8x8 so ainda comprimidos com um algoritmo lossless, uma variao da codificao de Huffman10, um algoritmo de codificao de entropia. Padro MPEG Toda essa teoria e conceitos at agora apresentados no que concerne padres tradicionais de transmisso e compresso de imagem, serviro de base terica para apresentarmos o padro de compresso de vdeo MPEG (Motion Picture Experts Group), que um dos principais padres de compresso de vdeo desde 1933. O MPEG1 foi concebido para a compresso de vdeo para o sistema NTSC numa taxa de 1.2 Mbps. O MPEG2 foi criado com uma compresso de broadcasting com qualidade, em taxas de 4 a 6 Mbps, podendo ser utilizado tanto no sistema PAL como no NTSC. As duas verses se beneficiam com duas redundncias existentes em filmes: espacial e temporal. A redundncia espacial alcanada apenas codificando cada quadro separadamente com JPEG. Uma compresso adicional pode ser obtida pelo fato que os quadros consecutivos so quase sempre idnticos (Redundncia Temporal). O Sistema de Vdeo Digital usado nas cmeras digitais utiliza o padro JPEG porque a codificao tem que ser feita em tempo real sendo muito mais rpida do que codificar cada quadro separadamente. Apesar das cmeras digitais terem uma velocidade menor do que os sistemas tradicionais de vdeo sem compresso, os ltimos tm uma qualidade de imagem muito aqum daquela proporciona pelo Vdeo Digital. Por exemplo, numa cena onde temos as imagens de fundo sem alteraes e um ou dois personagens movimentando-se lentamente, praticamente quase todos os pixels sero idnticos quadro a quadro. Por outro lado, se temos uma cena com ampliao e reduo da viso panormica das imagens de fundo, essa tcnica extremamente improdutiva. Da a necessidade de ter-se uma maneira de compensar essa movimentao nas imagens. Isso exatamente que o MPEG faz, sendo a grande diferena entre o MPEG e o JPEG. A sada do MPEG consiste de trs tipos diferentes de quadros que so processados pelo programa de visualizao:

10

David A. Huffman enquanto fazia o doutorado no MIT, publicou em 1952 o artigo A Method for the Construction of Minimum-Redundancy Codes.

70

Quadro I (Intracoded): Contendo codificao JPEG para imagens estticas. Quadro P (Predictive): Diferena bloco a bloco com o ltimo quadro. Quadro B (Bidirecional): Diferena entre o ltimo e o prximo quadro. O Quadro I apenas imagens estticas codificadas em JPEG, com resoluo de luminncia completa e a metade da resoluo de crominncia em cada eixo. necessrio ter Quadros I aparecendo periodicamente na sada do fluxo de imagem por trs razes. A primeira, o MPEG pode ser usado para TV Broadcasting, com os espectadores podendo sintonizar os canais segundo seu desejo. Se todos os quadros dependessem do seu predecessor voltar para o primeiro quadro da transmisso, qualquer um que perdesse o primeiro quadro nunca poderia decodificar qualquer quadro subsequente. Isso tornaria impossvel ao espectador sintonizar um filme depois que ele j tivesse iniciado. Segundo, se qualquer quadro estivesse tendo uma recepo com erro, no se poderia continuar com a decodificao. Terceiro, sem os Quadros I, ao realizar rpidos forward e rewind, o decodificador teria que calcular todo quadro transmitido para que ele soubesse exatamente onde ele havia parado. Como o Quadro I possvel saltar no forward e no rewind at que um Quadro I seja encontrado e iniciar-se a visualizao daquele ponto, o mesmo inserido na sada de vdeo uma a duas vezes por segundo. Os Quadros P, diferentemente, codifica a diferena entre os quadros. Eles so baseados na ideia de macroblocks (macrobloco) que cobrem 16x16 pixels em espao de luminncia e 8x8 pixels em espao de crominncia. Um macrobloco codificado para buscar quadros anteriores, visando diferena entre os blocos. O padro MPEG no especifica como buscar, at onde buscar ou o quanto o quadro est coerente com a busca. Isso fica a cargo de cada implementao. Por exemplo, uma implementao pode buscar por um macrobloco na posio corrente e nos quadros anteriores, realizando uma comparao entre os quadros encontrados. Para cada posio, o nmero de igualdades identificadas na matriz de luminncia pode ser computado. A posio com o maior escore seria declarada a vencedora, baseandose num parmetro previamente estabelecido. Caso esse parmetro no for alcanado poder-se-ia dizer que o macrobloco foi perdido. Naturalmente, existem algoritmos muito mais sofisticados para manusear macroblocos.

71

Se um macrobloco encontrado, ele codificado, considerando a diferena entre seu valor e do quadro anterior (para a luminncia e as duas crominncias). Essas matrizes de diferenas so ento submetidas codificao JPEG. O valor do macrobloco no fluxo de sada de vdeo ento o vetor de movimento (o quanto o macrobloco mudou de sua posio anterior em cada direo eixos x e y de crominncia), seguido pelas diferenas com o quadro anterior codificadas em JPEG. Se o macrobloco no est no quadro anterior, o valor corrente codificado em JPEG, como se fosse um Quadro I. O quadro B similar aos Quadros P, exceto que ele permite o macrobloco de referncia ser ou o quadro anterior ou o quadro posterior, num Quadro I ou um Quadro P. Essa liberdade adicional permite melhorar a compensao do movimento nas imagens, quando, por exemplo, objetos passam na frente ou atrs de outros objetos. Os Quadros B permite a um quadro ser baseado no quadro futuro. Para codificar um Quadro B, o codificador precisa manter trs quadros codificados na memria ao mesmo tempo, o anterior, o corrente e futuro. Para simplificar a decodificao, os quadros precisam estar presentes no fluxo do MPEG numa ordem de dependncia e no numa ordem de visualizao. Assim mesmo com uma temporizao perfeita, quando um vdeo assistido atravs de uma rede, requerido fazer uma buferizao (buffering) no computador do usurio para reordenar os quadros numa visualizao apropriada. Devido a essa diferena entre a ordem de dependncia e a ordem de visualizao, tentar reproduzir um filme de frente para trs no ser possvel sem um considervel buferizao e complexos algoritmos. Escalonamento de Processos em Sistemas Multimdia Sistemas Operacionais que suportam multimdia diferem dos tradicionais em trs principais aspectos: escalonamento de processos, sistema de arquivo e

escalonamento de disco. Escalonamento Homogneo de Processos O tipo mais simples de servidor de vdeo aquele que suporta a visualizao de um nmero fixo de filmes, todos utilizando a mesma taxa de quadros, resoluo, taxa de dados e outros parmetros tambm semelhantes. Sob essas circunstncias, um simples, mas efetivo algoritmo de escalonamento seria como segue:

72

Para cada filme, h um simples processo ou thread cujo job seria acessar o filme no disco, um quadro de cada vez e ento transmiti-lo para o usurio. Desde que todos os processos so igualmente importantes, teremos o mesmo volume de trabalho a fazer para cada quadro, bloqueando quando eles finalizarem o processo do quadro corrente. O escalonamento round robin plenamente adequado para esse tipo de processo. A nica adio necessria para um algoritmo padro de escalonamento seria o mecanismo de temporizao para garantir que cada processo seja executado na frequncia correta. Um modo de obter uma temporizao adequada possuir um relgio (clock) mestre que oscila, por exemplo, 30 vezes por segundo (para NTSC). A cada ciclo do relgio, todos os processos so executados sequencialmente, na mesma ordem. Quando o processo termina o seu trabalho, ele emite uma chamada de suspenso do sistema que libera a CPU at o prximo ciclo do relgio. At quando os processos so curtos o suficiente para que todo o trabalho seja feito dentro de um ciclo, o escalonamento round robin adequado.

Modelos Gerais de Escalonamento para Processos em Tempo Real Infelizmente o Escalonamento Homogneo de Processos raramente aplicvel vida real. Um nmero significativo usurios mudam como expectadores, tamanho de quadros variam consideravelmente devido natureza da compresso de vdeo (Quadros I so muito maiores que Quadros P e B) e filmes diferentes podem ter diferentes resolues. Como consequncia, processos diferentes precisam ser executados em frequncias diferentes, com diferentes quantidades de trabalho e com diferentes deadlines dentro dos quais o job deve ser efetuado. Essas consideraes levam a um modelo de mltiplos processos competindo pela CPU, cada um com sua prpria tarefa e tempo limite (deadline). Nesses modelos, assume-se que o sistema sabe a frequncia na qual cada processo deve ser executado, o quanto de trabalho tem de fazer, e qual o seu prximo tempo limite. Esse escalonamento de processos competindo entre si, alguns ou mesmo todos tendo tempos limites que devem ser cumpridos chamado escalonamento em tempo real.

73

Como vimos na pgina 62 desse captulo, sistemas peridicos de multimdia podem ter a alocao de CPU calculada atravs de uma somatria onde m o nmero de processos e Pi/Ci uma frao de CPU utilizada pelo processo i, sendo o sistema capaz de ser escalonado se a somatria for menor que 1. At agora estamos considerando sistemas com um processo por fluxo. De fato, poderia haver dois ou mais processos por fluxo. Por exemplo, um para udio e outro para vdeo. Eles podem ser executados em diferentes taxas e consumir diferentes quantidades de CPU por rajada. Adicionar o udio no sistema no muda o modelo no geral, desde que se assuma que existem n processos, cada um deles sendo executados numa frequncia fixa com uma quantidade fixa de trabalho necessrio em cada rajada de CPU. Em alguns sistemas em tempo real, os processos tm a capacidade de antecipar-se (preempo) e outros no tm essa funcionalidade. Em sistemas multimdia, os processos so geralmente capazes de antecipar-se, significando que o processo consegue perceber que estar excedendo o seu tempo limite, podendo assim interromper o que est sendo executado naquele momento antes de finalizar o seu o quadro, assim o processo anterior pode continuar. Usualmente os sistemas em tempo real tm melhores resultados utilizando a preempo, porm eles podem a apresentar problemas de jitter caso o buffer de transmisso acabe tendo o seu limite de tamanho excedido devido ao recebimento de vrias pequenas rajadas dos processos dentro de um tempo limite. Em outras palavras, 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 operao para o usurio requisitante. Os algoritmos de sistemas em tempo real podem se estticos ou dinmicos. Algoritmos estticos designam para cada processo uma prioridade pr-estabelecida e ento se trabalha com essas prioridades utilizando a preempo. Algoritmos dinmicos no utilizam prioridades fixas.

74

Escalonamento de Taxa Monotnica (Rate Monotonic Scheduling) O mais clssico de escalonamento algoritmo esttico para processos em tempo real peridicos e preemptivos o RMS (Rate Monotonic Scheduling). Ele pode ser utilizado para processos que satisfaam as seguintes condies: Cada processo peridico deve ser completado dentro do seu perodo; Nenhum pode ser dependente de outro; Cada processo precisa ter a mesma necessidade de CPU para sua rajada; Qualquer processo no peridico no deve ter tempo limite (deadline); O processo de preempo ocorre instantaneamente sem overhead; O RMS trabalha designando prioridades para cada processo baseado na frequncia em que cada um executado, por exemplo, se um processo tem uma frequncia de execuo a cada 30 milissegundos, resultando em 33 execues por segundo, sua prioridade ser 33. De acordo com o algoritmo, o sistema sempre escalona os processos com a maior prioridade prontos para serem executados utilizando a preempo, se necessrio.

75

Escalonamento Tempo Limite mais Exguo Primeiro (Earliest Deadline First) Esse um algoritmo de sistemas em tempo real dinmico, dessa forma eles no possuem uma periodicidade nem requerem um mesmo tempo de execuo para rajada de CPU. A qualquer momento em que um processo precisa de um tempo de CPU, ele anuncia sua presena e seu tempo limite. O algoritmo executa ento o primeiro processo da lista, que aquele mais prximo do seu tempo limite. A cada novo processo o sistema checa se o tempo limite do mesmo menor dos que j esto lista de processos prontos a serem executados, caso seu tempo limite seja o menor, ele executado primeiro. O algoritmo EDF (Earliest Deadline First) mais resiliente que o RMS (Rate Monotonic Scheduling), pois o se ltimo tiver a taxa de utilizao de CPU acima de 78% no prov uma garantia de perfeita funcionalidade.

Sistemas de Arquivos em ambientes multimdia Os sistemas tradicionais de armazenagem e acesso ao sistema de arquivo mostramse inadequados para sistemas multimdia, por razes como a necessidade da disponibilizao do arquivo dentro de uma mesma frequncia, sem atrasos e ainda necessitar-se ter funcionalidades como mover-se rapidamente para frente, mover-se rapidamente para trs e pausa. Assim um servidor de arquivos precisa atuar mais como um videocassete ou DVD Player do que um computador. Para que isso ocorra necessrio um mtodo acesso aos arquivos como um Push Server onde o servidor de arquivos aps receber as informaes para localizao e buferizao do arquivo empurra o mesmo para o usurio, podendo ento realizar as operaes de equipamentos tradicionais de multimdia como um VCR, diferentemente do acesso tradicional a arquivos onde o usurio aps localizar o arquivo que deseja abrir, o traz para o seu computador (Pull Server).

76

Figura 2

Pull Server

Push Server

Armazenagem de arquivos em Sistemas Multimdia Usualmente os arquivos multimdia so muito grandes, eles so na maioria das vezes escritos uma vez e lidos muitas, tendo a tendncia de serem acessados sequencialmente. Sua reproduo deve tambm alcanar critrios estritos de qualidade servio. Juntos, esses requerimentos sugerem um desenho diferente de sistema de arquivo daquele utilizado nos sistemas operacionais tradicionais. Temos modelos para um nico disco ou para vrios. Armazenagem de arquivos multimdias num nico disco O pr-requisito para ter-se uma reproduo de um arquivo multimdia de qualidade seria executar o mesmo na velocidade solicitada e sem jitter. Por esse motivo, teremse mltiplos acessos ao disco durante um quadro no desejvel. Uma forma de eliminar acessos ao disco durante a execuo de um arquivo multimdia o uso de arquivos contguos. Sendo essa forma de acesso apropriada apenas para arquivos de vdeo. Porm, como usual, se tivermos numa reproduo a presena de vdeo, udio e texto, se os mesmos estiverem gravados em arquivos contguos separados, haver uma alternncia no acesso aos arquivos de vdeo, udio e texto que poderia causar jitter.

77

Para minimizar esse efeito utiliza-se uma tcnica tambm usada em VoIP (Voice Over IP) conhecida como interleaving (intercalamento), onde arquivos de textos de igual tamanho so colocados entre os arquivos de udio e vdeo, mantendo assim a frequncia da reproduo e evitando o jitter.

Figura 3 Essa organizao de arquivo requer a utilizao mais recurso de E/S de disco e buffer, mas a qualidade da reproduo compensa essa utilizao adicional dos recursos de mquina. Vale tambm ressaltar que para esse modelo, o acesso randmico, moverse rapidamente para frente, mover-se rapidamente para trs no so possveis. Para arquivos no contguos contemplaremos duas organizaes de arquivos multimdia. A primeira delas conhecida como modelo de blocos pequenos. Nessa organizao o tamanho de bloco escolhido deve ser consideravelmente menor do que a mdia do tamanho de um quadro, mesmo para Quadros P e quadros B. A ideia ter numa estrutura de dados, um ndice de quadros por vdeo. Uma vez que os quadros tm tamanhos diferentes, o ndice deve conter tambm o tamanho do quadro em quantidade de blocos.

Figura 4

78

A outra forma organizao de arquivos multimdia para arquivos no contguos armazen-los em grandes blocos de disco. Nessa situao, mltiplos quadros so colocados num bloco. Um ndice ainda requerido, porm um ndice de blocos e no de quadros, ndice esse semelhante ao indexador de arquivos tradicionais, conhecido como i-node (index node) que um array que lista os atributos e endereo no disco dos blocos de arquivos. No caso de arquivos multimdia, uma informao adicional requerida, que seria qual quadro est no incio de cada bloco, fazendo assim a localizao dos mesmos. No modelo de blocos grandes temos duas variaes, uma em que os quadros no so separados entre os blocos e outra que eles so divididos entre os mesmos.

Figura 5 Podemos resumir as vantagens e desvantagens desses modelos da seguinte forma: Indexao por Quadro: Consumo alto de RAM, pequeno desperdcio de disco. Indexao por Bloco (Sem separao de quadros entre os blocos): Baixo consumo de CPU e maior desperdcio de espao em disco. Indexao por Bloco (Com separao de quadros entre os blocos) Baixo consumo de RAM, sem desperdcio de disco, mas com buscas extras por quadros.

79

A alternativa para minimizar os efeitos do uso excessivo de memria RAM seria a paginao, que armazenar em disco dados da memria RAM quando a mesma atinge o seu limite, o termo paginao tambm vem da ideia que a memria RAM dividida em pequenas parties facilitando assim o gerenciamento da mesma. Para facilitar e otimizar as buscas dos quadros quando falamos em indexao por blocos, onde teremos mais do que um quadro por bloco ou mesmo quadros divididos entre blocos, operao que requer quadros contguos, uma soluo seria usar uma buferizao circular ligeiramente maior que o tamanho do bloco, assim o bloco onde est quadro pretendido colocado em buffer, dessa forma a busca e transmisso do quadro em questo viabilizada, consumindo menos recursos. Cache em Sistemas Multimdia Uso tradicional do cache em Sistemas Multimdia seria sem propsito, isto , colocar um bloco em cache esperando que o mesmo seja reutilizado no seria produtivo tendo em vista a dinmica desse tipo de sistema. Porm quando falamos em dois espectadores assistindo um mesmo filme, com um deles iniciando 2 segundos aps o outro, a acessar o mesmo arquivo multimdia, a tecnologia e o propsito do cache passam a ser interessantes, porque um bloco acessado pelo primeiro, se colocado em cache ser acessado de maneira muito mais rpida e com mais performance que o segundo caso acessasse o disco novamente. Em suma, se temos dois usurios acessando um mesmo arquivo multimdia num intervalo muito pequeno, a tecnologia de cache pode ser utilizada para otimizar esse acesso. Outro uso para o cache de arquivos seria o fato dos arquivos de filmes, devido ao seu tamanho, serem armazenados em CDs e DVDs e apenas copiados para o disco quando solicitados. Esse processo, porm toma um tempo significativo. Assim os servidores mantm em disco uma cpia dos vdeos mais demandados para aperfeioar essa operao. Apesar de atualmente termos storages da ordem de Terabytes que evitaria a armazenagem de arquivos em mdias de acesso mais lento, eles ainda no so acessveis em termos de custos para todos os segmentos de negcio. Podemos tambm manter em disco os primeiros minutos de todos os vdeos disponveis, dando tempo assim para cpia dos mesmos na ntegra do CD ou DVD para o disco, quando solicitados.

80

Vale ressaltar que estamos abordando aqui duas modalidades de cache. A primeira o cache convencional que uma rea de armazenamento temporria de acesso mais rpido do que ao disco onde so colocados os dados mais frequentemente utilizados, que no caso dos sistemas multimdia usado com um propsito ou objetivo diferente dos sistemas tradicionais, como explanado acima. Na segunda modalidade o disco rgido considerado um cache para mdias de acesso mais lento como o CD ou o DVD. Escalonamento de acesso a disco em Sistemas Multimdia Diferentemente de sistemas convencionais o escalonamento esttico de acesso ao disco em sistema multimdia extremamente previsvel pois os quadros tem um tempo fixo para serem executados dentro das tcnicas de codificao de vdeo. Assim existe um ciclo para o acesso ao disco conhecido como rounds. Nesse intervalo de tempo, um quadro de cada fluxo de vdeo executado, podendo assim vrios vdeos acessar o disco ao mesmo tempo. Esse conceito vlido para vdeos com as mesmas caractersticas. Quando tratamos de resoluo e velocidade de quadros diferentes, precisamos de um mecanismo de alocao dinmica. Nesse caso, no momento da leitura do quadro ser necessrio saber quanto tempo o mesmo precisaria para ser executado, que o tempo limite (deadline). Como os fluxos de vdeo tm caractersticas diferentes, no possvel o acesso em paralelo de vrios quadros de fluxos de vdeo diferentes, assim o sistema precisa escolher qual bloco executar dentro de parmetros prestabelecidos. Dois fatores so considerados para realizar essa escolha: o deadline e o cilindro do disco. Manter a escolha no mesmo cilindro otimiza o tempo de busca em disco mas pode comprometer o tempo limite (deadline). Assim so necessrios algoritmos que equilibrem esses dois parmetros, como por exemplo, o scan-EDF.

81

Fundamentos de Sistemas Operacionais com Processamento Distribudo A apresentao dos conceitos referentes ao processamento convencional e executado em nico um computador, abstraindo-nos da tecnologia de multincleo e multiprocessadores, nos servir como fundamento terico para identificarmos as particularidades e funcionalidades de Sistemas Operacionais Distribudos, ressaltando novamente que por uma questo de abordagem do nosso trabalho, que no faremos aqui distino entre sistemas distribudos e clusters, como j explanado no incio do captulo.

Redes de Computadores Antes de avanarmos nos temas que so comuns aos ambientes monoprocessados e distribudos, precisamos abordar tecnologia responsvel pela comunicao entre os computadores que compe os sistemas distribudos que poderia ser chamada de Redes de Computadores. Tendo em vista a amplitude da disciplina, esse trabalho abordar apenas os conceitos e tecnologias que so foco dessa pesquisa. 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. Apesar de podermos dizer que o modelo ISO/OSI utilizado amplamente como diretriz para especificao e entendimento de elementos de rede, no podemos dizer que ele um padro de facto, com raras excees, como, por exemplo, o protocolo IS-IS (Intermediate System to Intermediate System) que um protocolo baseado puramente no padro, mas que na prtica muito pouco disseminado. Dessa forma, apresentaremos as camadas desse modelo mais como uma referncia que facilitar o entendimento dos princpios apresentados do que um modelo que seria implementado na prtica nas diversas aplicaes e tecnologias de redes.

82

Apesar de esse modelo ter uma aplicao prtica restrita, o mesmo muito didtico e tambm se tornou um meio eficaz de tornar mais claro e homogneo o discurso e o jargo utilizado pelos profissionais da rea, por exemplo, quando usamos o termo switch camada 3 qualquer profissional em redes j saber exatamente as vrias caractersticas e particularidades desse equipamento sem necessitar-se qualquer explicao adicional. Segue uma explanao de cada uma das camadas do modelo ISO/OSI, fazendo uma comparao do mesmo com o protocolo TCP-IP (Transport Control Protocol Internet Protocol) que um do modelo de facto e utilizado praticamente quase todas as comunicaes de rede atualmente: Camada Fsica: Responsvel pela transmisso de sinais digitais (bits) convertidos em sinais eltricos, ticos e mesmo ondas de rdio (wireless). Tambm responsvel pela padronizao de interfaces fsicas, especificaes eltricas, eletromagnticas e ticas. Por exemplo, o foco de nosso trabalho ser redes locais (LAN), utilizando cabeamento UTP (Unshielded Twisted Pair) com conectores RJ-45. Camada de Enlace: A camada de enlace trabalha com unidades de transmisso de dados chamadas de frames que usualmente so constitudos de algumas centenas ou mesmo alguns milhares de bytes, utilizando mecanismos de deteco e correo de erros, garantindo assim, um PDU (Protocol Data Unit) mais confivel e livre de erros para as camadas superiores. Na camada de enlace temos tambm o endereamento fsico dos elementos de rede, conhecido endereo MAC (Medium Access Control). Os PDUs so as unidades padro de cada uma das camadas do modelo OSI. Camada de Rede Essa camada responsvel pelo encaminhamento lgico dos pacotes (o nome da PDU nessa camada), atravs do que chamamos rotas. Essas rotas podem ser estticas, mantendo-se fixas mesmo com mudanas na rede ou dinmicas que se adaptam s mudanas na rede atravs de protocolos de roteamento. Nessa camada tambm tratado o endereamento lgico dos elementos da rede, como por exemplo, o endereamento IP. O endereamento IP uma notao constituda de quatro partes conhecidas como octetos e uma numerao complementar conhecida como mscara que determina as limitaes lgicas desse endereo, por exemplo, quantos elementos podem ser endereados pelo mesmo.

83

Essa camada abarca uma srie de tecnologias, equipamentos e fundamentao terica, podendo dizer que seria uma das mais relevantes camadas, especialmente quando falamos da funo correspondente dessa camada no TCP-IP. Camada de Transporte A principal funo da camada de transporte receber os dados da Camada de Sesso, dividi-los em unidades menores, chamadas segmentos, se necessrio, e entreg-los camada de rede garantindo que os mesmos cheguem corretamente do outro lado da comunicao. A camada de transporte tambm responsvel pela multiplexao da comunicao entre os elementos da rede, permitindo que numa mesma conexo em nvel de 3 (camada de rede) vrios servios possam comunicarem-se ao mesmo tempo. Em TCP-IP temos o conceito de comunicaes orientadas conexo e no orientadas a conexo, respectivamente conhecidas como TCP (Transport Control Protocol) e UDP (User Datagrama Protocol), a primeira garante o envio e o recebimento atravs de um sistema negociao, reconhecimento de chegada de segmentos e dispositivos de deteco e correo de erros, a segunda preocupada em apenas enviar os dados sem nenhuma garantia de chegada ao destino. A multiplexao garantida no protocolo TCP-IP atravs de um dispositivo conhecido como porta, assim tem-se portas de servios e aplicaes j conhecidas como o HTTP, FTP e Telnet que possuem um nmero padro, respectivamente portas 80, 21 e 23. Essas portas so conhecidas como well-known e ficam abaixo de nmero de porta 1024. Camada de Sesso Semelhante a camada de transporte a camada de sesso tambm gerencia a transmisso de dados, mas com algumas funes adicionais, atravs do estabelecimento de sesses entre os computadores. Um dos servios da camada de sesso seria estabelecer um controle do dilogo entre as mquinas, por exemplo, se o trfego fluir nas duas ou numa mesma direo ao mesmo tempo dentro de determinada sesso. Uma sesso pressupe uma conexo entre dois elementos por vez, por exemplo, para transferncia de arquivos ou mesmo num sistema de acesso remoto com tempo compartilhado. A camada de sesso tambm responsvel por controle de operaes dentro de determinados protocolos nos quais, por exemplo, no seria permitido os dois lados de a sesso realizarem uma operao ao mesmo tempo. Essa funcionalidade conhecida como token management.

84

Ela tambm responsvel pelo servio de sincronizao, no sentido de estabelecer pontos de controle e recuperao durante a sesso, caso ocorra uma interrupo no programada da mesma. O protocolo TCP-IP no contempla formalmente uma camada de sesso, mas possui protocolos que utilizam os princpios da mesma, como por exemplo, o NFS (Network File System) dos sistemas operacionais Unix ou Linux. Camada de Apresentao A camada de apresentao preocupa-se com a sintaxe e semntica dos dados transmitidos. Alm de serem agrupamentos de bits, os dados representam nomes, datas, valores financeiros, etc. Esses itens so convertidos em representaes e estruturas de dados. Os computadores podem ter padres diferentes de converso, por exemplo, quando tratamos de representao de caracteres (letras e nmeros em textos convencionais), os mesmos podem ser representados nos padres ASCII, EBCDIC ou mesmo Unicode. Em suma a camada de apresentao recebe os dados vindos da rede e os representam da maneira que o computador que recebe esses dados, os compreenda. O protocolo TCP-IP no tem formalmente uma camada de apresentao.

85

Camada de Aplicao importante ressaltar que quando abordamos o termo aplicao no modelo ISO/OSI estamos nos referindo a aplicaes de redes. Essas aplicaes so transferncia de arquivo, correio eletrnico, emulao de terminal, navegador de Internet, etc. Novamente teremos na prtica aplicaes do protocolo TCP-IP como FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), HTTP (HiperText Transfer Protocol), etc. Segue uma comparao entre o modelo ISO/OSI o protocolo TCP-IP:

Figura 6

86

Processos e Threads Apesar de termos vistos processos e threads separadamente, quando os abordamos no monoprocessamento, para fins didticos discutiremos os dois conceitos conjuntamente ao apresentarmos os fundamentos do processamento distribudo. Como vimos anteriormente, threads compartilham o mesmo espao de memria que faz o seu comportamento e uso diferir significamente dos processos. Podemos dizer que os processos esto para os computadores, assim como as threads esto para os processos. Assim podemos ter um processo manipulando mltiplas threads. Essa caracterstica faz as threads mais apropriadas para sistemas distribudos por possurem a funcionalidade intrnseca de paralelismo, podendo tambm utilizar primitivas blocking. Um exemplo de blocking seria quando uma thread ou mesmo um processo acessam o disco e precisam esperar a resposta do mesmo. Nesse momento eles entram num estado de blocking at receber os dados solicitados. Quanto o sistema est em blocking o processador fica inativo at receber a resposta do dispositivo que est executando a tarefa, nesse caso o disco e seu driver, perdendo assim em desempenho assim como em otimizao de recursos computacionais. Existem sistemas ou primitivas non-blocking em que enquanto a tarefa de determinada chamada de sistema est utilizando outro dispositivo que no o processador, o mesmo liberado para ser utilizado por outras threads ou processos. Primitivas non-blocking ou assncronas como tambm so conhecidas, apesar de apresentarem a princpio uma melhor performance, possuem dificuldades significativas de controle e implementao. Assim falando-se na utilizao de threads em ambientes distribudos, o conjunto de mltiplas threads e primitivas blocking seria o mais recomendado, pois chamadas de sistema blocking ou sncronas torna a programao mais simples e mltiplas threads possibilitam o paralelismo. Seguem outros argumentos que fazem as threads mais apropriadas para o processamento distribudo: Iniciar e controlar uma thread para uma requisio entrante muito menos onerosa para o sistema do que iniciar um processo. Quando temos mltiplas threads (Paralelismo) temos a possibilidade de

multiprocessamento seja atravs de um processador multincleo, seja atravs de um computador com mltiplos processadores ou atravs de mltiplos computadores num ambiente de computao distribuda.

87

Por sua caracterstica de paralelismo a implementao de threads possibilita a melhoria de desempenho nos sistemas. Programas com mltiplas threads tendem a ser menores e de mais fcil entendimento devido ao controle de fluxo simplificado. A maioria dos servidores demanda um alto uso de E/S, usando o sistema de bloqueio de chamadas (blocking) com as threads temos tambm uma simplificao dessa estrutura. RPC (Remote Procedure Call) e MPI (Message Passing Interface) Quando falamos em processamento distribudo, faz-se necessrio uma exposio sobre o meio pelo qual as threads ou mesmo os processos se comunicam nesse tipo de ambiente. Enquanto sistemas monoprocessados utilizam funes como pipeline ou fork para promover a comunicao e a passagem de parmetros entre processos ou threads, utilizando o barramento do computador e os componentes do processador para realizar essa tarefa, os sistemas distribudos utilizam as redes como meio de comunicao entre os processos, necessitando de uma abordagem totalmente distinta para a comunicao entre processos e threads. Temos duas tcnicas de comunicao interprocessos ou inter-threads11, a primeira conhecida como Passagem de Mensagem (Message Passing) adotada para uso em sistemas de distribudos no final da dcada de 70 e a Chamada Remota de Procedimento (Remote Procedure Call) sendo utilizada inicialmente em meados da dcada de 80. A Passagem de Mensagem originalmente uma troca de mensagem unidirecional entre processos sendo visveis ao programador, no possuindo a capacidade de responder diretamente a comandos executados num computador local por um computador remoto. Existem atualmente passagens de mensagem estruturadas que so bidirecionais.

11

Apesar do termo inter-thread ser utilizado quando abordamos a comunicao interprocessos, precisamos ter em mente que na maioria dos casos de computao distribuda teremos processos realizando a comunicao entre computadores distintos, processos esses que manipularo as threads localmente. Porm temos o cluster Kerrighed que se prope a realizar a migrao e comunicao de threads entre dois ou mais computadores.

88

Nesse contexto, uma mensagem uma coleo de objetos de dados consistindo de um cabealho de tamanho fixo e um campo de payload de tamanho varivel ou fixo, os quais podem ser gerenciados por um processo e entregues a seu destino. O tipo associado mensagem prov uma informao estrutural sobre como a mensagem deve ser identificada. Uma mensagem pode ser de qualquer tamanho e pode conter dados ou ponteiros para dados fora da poro contgua da mensagem. Uma das portas TCP e UDP utilizadas pelo sistema de passagem de mensagem a 3827, acima do range das portas well-known, conhecidas como registradas (registered) na nomenclatura do IANA (Internet Assigned Numbers Authority), rgo responsvel pelo controle e registro das portas TCP e UDP a nvel mundial, dentre outras atividades. A passagem de mensagens utiliza primitivas send e receive como mecanismos bsicos para sua operao. Segue um diagrama no tempo que descreve a execuo dessas primitivas:

Figura 7

89

Podemos ter vrias alternativas em virtude da semntica utilizada para as primitivas do modelo de Passagem de Mensagens: Portas de comunicao diretas ou indiretas; Primitivas blocking ou Non-blocking; Primitivas com ou sem buffers; Primitivas confiveis ou no confiveis; Formas estruturadas de Passagem de Mensagem baseada em primitivas; Abordando de modo sucinto essas variaes de implementao de Passagem de Mensagem, quando falamos de portas de comunicao direta estamos falando em identificarmos diretamente o destinatrio da mensagem ou a comunicao indireta que seria utilizar uma porta genrica para a qual a mensagem enviada, sendo colocada em buffer e utilizada pelo processo que teria a necessidade da mesma. Os conceitos de primitivas blocking ou sncronas e non-blocking ou assncronas j foram contemplados anteriormente. Falando de Passagem de Mensagem com ou sem buffer, seria a alternativa de buferizar ou no a mensagem, caso a primitiva receive no tiver sido ainda executada no destinatrio quando o mesmo receber uma mensagem. Primitivas confiveis e no confiveis, diz respeito ao uso ou no de dispositivos de verificao de recebimento e retransmisso da mensagem caso a mesma tenha sido perdida. Primitivas no confiveis no utilizam esse dispositivo, ao passo que primitivas as confiveis garantem a entrega da mensagem. Esses mecanismos que determinam as primitivas confiveis e no confiveis esto relacionados com o protocolo de rede TCP-IP, que utilizado usualmente na comunicao entre os computadores em sistemas distribudos. As primitivas no confiveis utilizariam conexes UDP e as confiveis conexes TCP. Formas estruturadas de Passagem de Mensagem so alcanadas pela distino de requisies e respostas, provida por um fluxo bidirecional de informaes.

90

A RPC (Remote Procedure Call) baseada no conceito fundamental de programao conhecido como chamada de procedimento. A conceituao mais geral do termo RPC seria um nvel de linguagem de chamada num computador local ser automaticamente executada no mesmo nvel de linguagem num computador remoto. A passagem da chamada invisvel ao programador, requerendo que o protocolo de transporte de rede suporte transmisso dos argumentos e resultados das chamadas. Em termos de TCP-IP cada fabricante e desenvolvedor estabeleceu portas TCP e UDP para suas verses do RPC, por exemplo, a SUN utiliza as portas UDP e TCP 111 e a Encore as portas TCP e UDP 121. A ideia da RPC muito simples e baseada no modelo onde o cliente envia uma requisio e ento entra em estado de blocking at o servidor remoto enviar uma resposta. Essa abordagem muito similar aos mecanismos well-known e wellunderstood referidos como chamadas de procedimento tambm conhecidas como LPC (Local Procedure Call). Assim, o objetivo de uma Chamada Remota de Procedimento permitir programas distribudos serem escritos no mesmo estilo dos programas convencionais para sistemas computacionais centralizados. Isso implica que a RPC deve ser transparente, que uma das principais vantagens dessa tcnica de comunicao: o programador no precisa saber se o procedimento chamado est sendo executado num computador remoto ou local. Num sistema que suporta uma chamada de procedimento convencional, por exemplo, uma rotina de leitura de uma determinada biblioteca (biblioteca da RPC) inserida trivialmente no programa. Esse procedimento, quando executado, primeiro coloca os parmetros em registradores e depois assume o controle do kernel, tendo como resultado a execuo de uma chamada de procedimento de leitura. Do ponto de vista do programador no h nada de especial nessa chamada de procedimento, basta inserir os parmetros numa pilha (registradores) e execut-los. Num sistema que suporta RPC, a rotina de leitura um procedimento remoto o qual ser executado no servidor do outro lado da comunicao. Nesse caso, outra chamada de procedimento, chamada client stub, da biblioteca de RPC, inserida no programa. Quando executada, ela tambm assume o controle do kernel. Entretanto, ao invs de colocar os parmetros num registrador, ela os empacota numa mensagem e executa a primitiva de envio, a qual faz que o sistema operacional os envie para o servidor. Na sequncia, ela chama a primitiva de recepo, entrando em blocking at ter de volta uma resposta. J no servidor o sistema operacional repassa a mensagem que recebeu para um server stub, a qual ligada ao servidor.

91

O stub entra em blocking waiting para mensagens, como resultado da execuo da primitiva de recepo. Os parmetros so desempacotados da mensagem recebida e um procedimento chamado na forma convencional. Assim, os parmetros e o endereo de retorno so colocados numa pilha, e o servidor no v que a chamada original foi criada num cliente remoto. O servidor executa a chamada de procedimento e retorna os resultados para um solicitante virtual, o server stub. O stub empacota os resultados numa mensagem, executando uma primitiva de envio para retornar os resultados. O stub vai para o incio do loop para executar a primitiva de recepo, e entra em blocking waiting para a prxima mensagem. A mensagem de resposta do servidor ao chegar ao cliente copiada no buffer do procedimento client stub. A mensagem desempacotada, os resultados extrados e copiados no sistema do cliente na forma convencional. Como resultado da chamada de leitura, o processo do cliente obtm os dados disponveis. O cliente desconhece que o procedimento foi realizado remotamente.

Figura 8

92

Apesar de o foco nosso trabalho ser em clusters baseados em Kerrighed e o mesmo no utilizar RPC (Remote Procedure Call) para realizar a execuo e migrao de processos, entendemos que o conhecimento dessa tcnica essencial do

processamento distribudo ir nos ajudar a compreender melhor a tcnica utilizada pelo Kerrighed para esse mesmo fim. Gerenciamento de Memria: Existem dois principais paradigmas no processamento distribudos o primeiro a execuo de remota de processos seja atravs de MPI seja atravs de RPC e o segundo paradigma seria o compartilhamento de memria, que uma tcnica de compartilhar as memrias de computadores distintos de modo que elas se comportem como uma memria convencional utilizada no monoprocessamento. Memria Compartilhada Distribuda: A DSM (Distributed Shared Memory) uma abstrao para compartilhar dados entre computadores que no utilizam uma mesma memria fsica. Os processos acessam a DSM, lendo e atualizando o que parece ser para eles uma memria convencional dentro do espao de memria reservado para os mesmos, mas de fato, h sistemas subjacentes que garantem de modo transparente que as mudanas realizadas numa DSM sejam atualizadas em todos os computadores que compe a mesma. Segue uma representao de uma memria compartilhada distribuda:

Figura 9 A DSM poupa o uso de Passagem de Mensagens na programao de sistemas distribudos em muitas situaes, no sendo apropriada para modelos cliente-servidor que possuem uma caracterstica intrnseca de requisio-resposta.

93

Comparando o uso de Passagem de Mensagens com DSM, enquanto na primeira as variveis precisam ser estabelecidas num lado da comunicao, enviadas pela rede e reorganizadas no lado que as recebe, na segunda as variveis so acessadas por ambos os computadores, no havendo a necessidade de uma transposio das mesmas. Em termos de sincronizao enquanto no modelo de passagem de mensagens, a mesma garantida atravs de primitivas que utilizam de tcnicas como a implementao de lock server, no caso da DSM sincronizao assegurada atravs de desenvolvimento convencional em memria compartilhada tais como os semforos. Devido a sua caracterstica de persistncia a DSM possui mais flexibilidade no concerne execuo operaes no tempo, por exemplo, um processo pode armazenar dados em certo espao de memria que outro poder acessar num perodo tempo frente, diferentemente da passagem de mensagens em que a troca de dados precisa ser imediata devido ao processo de blocking utilizado nessa tcnica. Em termos de eficincia sistemas baseados em DSM podem ser to eficientes como os desenvolvidos com passagem de mensagem, pelo menos quando falamos numa quantidade pequena de computadores. Existem alguns aspectos da implementao de DSM que devem ser considerados: Estrutura: Nesse contexto, estrutura a forma abstrata em que a DSM apresenta-se para as aplicaes. Seguem algumas abordagens mais comuns de estrutura em DSM: Sem Estruturao: A maioria dos sistemas de DSM no estrutura seu espao compartilhado de memria, sendo apenas um array linear de palavras. Estruturao atravs de tipo de dado: Nesse mtodo a memria compartilhada estruturada ou como uma coleo de objetos ou como uma coleo de variveis de uma linguagem. Estruturao como banco de dados: Nesse caso a memria estruturada como um banco de dados, sendo ordenada como uma memria associativa, isto , um endereamento de memria baseado, mas no contedo do que nomes ou endereos.

94

Sincronizao: Como nos sistemas convencionais de memria compartilhada a sincronizao tambm necessria em DSM, utilizando os controles usuais como lock e semforos. Esses dispositivos so aplicados atravs de passagem de mensagens. Consistncia: DSM um sistema de replicao de itens de dados compartilhados. Nesse sistema cpias desses itens compartilhados podem estar simultaneamente disponveis nas memrias principais de vrios computadores. Assim o desafio seria manter essas informaes coerentes e idnticas em todos os ns que compe o sistema distribudo. Para manuteno da consistncia da DSM temos dois modelos principais de propagao de atualizao ou replicao: write-update e write-invalidate. O primeiro que quando as atualizaes so feitas localmente por um processo, enviada uma rplica para todos os outros computadores que compe o sistema atravs de multicast (comunicao TCP-IP de um para muitos, organizada em grupos), provocando assim a atualizao da memria principal dos mesmos. O segundo, 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. Quando um processo que est compartilhando um item com outros, tenta escrever no mesmo, uma mensagem multicast enviada para todos os processos que possuem uma cpia desse item, invalidando a mesma, recebendo uma confirmao dessa operao antes da escrita ser realizada. Alm disso, qualquer processo que tenta acessar um item que est sendo atualizado bloqueado. Abordamos at agora tcnicas de replicao de atualizaes em DSM visando evitar a inconsistncia das informaes na memria compartilhada existente em cada n de um sistema distribudo. Veremos agora o principal modelo de consistncia para garantir essa condio, que o modelo de consistncia sequencial. A ideia desse modelo relativamente simples, no importa a ordem em que as operaes de leitura e escrita so consideradas conquanto que seja a mesma para todos os processos. Uma memria consistentemente sequencial prov uma semntica de uma cpia/ a mesma cpia, pois todos os processos que compartilham um dado espao de memria sempre veem exatamente o mesmo contedo armazenado nele. Essa seria a semntica mais intuitiva para lidar com esse tipo de necessidade de coerncia de dados.

95

Dispositivos de Entrada/Sada: A forma mais usual de manipulao de dispositivos de entrada/sada em sistemas distribudos seria atravs de sockets. O modelo de sistemas distribudos que mais utiliza a API de sockets o de cliente/servidor. Uma API (Application Programming Interface) um conjunto de rotinas e padres de uma determinada aplicao que so utilizados pelos sistemas e programas, de modo a poupar trabalho em desenvolvimento das funcionalidades realizadas por essa aplicao. Nesse caso, a API de sockets seja como integrante do sistema operacional, seja atravs de uma biblioteca, possibilita o acesso aos dispositivos de E/S em computadores remotos. Um socket apenas uma abstrao de E/S. A figura abaixo descreve o uso do mesmo num sistema cliente-servidor em ambiente UNIX, onde um processo do cliente requisita localmente uma conexo com um processo de um servidor remoto. Primeiro o servidor cria um socket e ento escuta a requisio do cliente. Como o cliente j criou tambm um socket com o qual requisita a conexo com servidor, o mesmo aceitar a requisio e estabelecer a conexo entre o servidor e o cliente.

Figura 10 Criar um socket muito semelhante a abrir um arquivo. Um programa pode ler e escrever dados de ou para um socket utilizando uma varivel integer fd (file descriptor) da mesma forma que realizaria um processo de E/S para um arquivo. A diferena que os dados so escritos por esse processo so enviados diretamente para um buffer do processo que tem o socket do outro lado da comunicao. Assim, uma conexo atravs de socket entre dois processo como um pipe bidirecional.

96

Modelo do Socket O modelo do socket consiste em 3 partes: a camada de socket, a camada de protocolo e a camada de dispositivo. Esse modelo em camadas designado para suportar as seguintes propriedades: Transparncia: A comunicao entre dois processos no deve depender dos processos estarem ou no no mesmo computador. Eficincia: A aplicabilidade de qualquer comunicao interprocessos limitada pelo seu desempenho. Compatibilidade: Processos j existentes que leem da entrada padro de um arquivo e escrevem na sada padro deve ser utilizvel num ambiente distribudo sem mudanas.

Arquivos: Um sistema distribudo de arquivos um componente chave para qualquer sistema de computao distribudo. A principal funo de um sistema de arquivos distribudo criar um sistema arquivos comum que pode ser compartilhado por clientes sendo executados em computadores autnomos num sistema de computao distribuda. Esse sistema deve armazenar programas e dados, fazendo-os disponveis quando necessrio. Tendo em vista que esses arquivos podem estar armazenados em qualquer parte do sistema distribudo, isso significa que sistemas de arquivos distribudos devem prover uma transparncia da localizao de arquivos. Isso significa que usurios, independente de sua localizao fsica, podem acessar os arquivos sem saber em que computador os mesmos esto armazenados. Para atingir esse objetivo um sistema de arquivo distribudo usualmente utiliza o modelo cliente-servidor. Ele tipicamente prov dois tipos de servios: servio de arquivo e servio de diretrio, que so implementados por um servidor de arquivo e um servidor de diretrio distribudos entre os ns da rede. Esses dois servidores podem ser implantados como um nico.

97

O sistema de arquivos distribudo mais utilizado em sistemas distribudos o PVFS (Parallel Virtual File System). A principal meta do PVFS prover um acesso de alto desempenho a arquivos em aplicaes de natureza paralela. O PVFS implementado em nvel de usurio, possuindo as seguintes caractersticas principais: Um consistente controle de nomes; Capacidade de distribuir dados entre os ns do sistema; Compatibilidade com os programas binrios existentes; Como o PVFS instalado em nvel de usurio, no so necessrias alteraes no ncleo do sistema operacional. Ele utiliza o TCP-IP para transmitir os dados sem dependncia de passagem de mensagens. O PVFS consiste de trs elementos: o processo (daemon) de gerenciamento que executado num nico n, os processos de E/S que so executados em todos os ns que executam E/S e a biblioteca de aplicao atravs da qual as aplicaes se comunicam com os processos do PVFS. O daemon de gerenciamento checa a permisso para as operaes de criao, abertura, fechamento e remoo de arquivos. O daemon de E/S controla todas as operaes de E/S sem a interveno do gerenciador. Em termos de arquivos de dados, eles so armazenados localmente em cada n de E/S. Os dados dos arquivos so distribudos entre os ns de E/S, possuindo um nico identificador para cada um dos arquivos como nos sistemas convencionais. O PVFS oferece suporte para os comandos de acesso, alterao e excluso de arquivos dos sistemas operacionais convencionais. Uma alternativa de armazenagem de metadados, que no contexto de sistemas de arquivos paralelos, seriam as informaes descrevendo as caractersticas dos arquivos, seria armazenar esses metadados num sistema arquivo NFS (Network File System) sistema de armazenamento distribudo de arquivos tradicional para sistemas Unix e Linux.

98

Chamadas de Sistema (System Calls) e Comunicao Interprocessos: Ao abordar processos e threads j vimos o meio pelo qual os sistemas distribudos realizam chamadas de sistema, seja atravs de Passagem de Mensagem seja atravs de RPC que so responsveis no contexto de processamento distribudo pela comunicao entre os processos. Para consolidar os conceitos apresentaremos uma implementao simples dos mesmos em cdigo: Passagem de Mensagem (MPI): #include "mpi.h" int main( int argc, char **argv ) { char message[20]; int myrank; MPI_Status status; MPI_Init( &argc, &argv ); MPI_Comm_rank( MPI_COMM_WORLD, &myrank ); if (myrank == 0) /* cdigo para o processo zero */ { strcpy(message,"Hello, there"); MPI_Send(message, strlen(message)+1, MPI_CHAR, 1, 99, MPI_COMM_WORLD); } else if (myrank == 1) /* cdigo para o processo 1 */ { MPI_Recv(message, 20, MPI_CHAR, 0, 99, MPI_COMM_WORLD, &status);

99

printf("received :%s:\n", message); } MPI_Finalize(); } Nesse exemplo, o processo zero (myrank = 0) envia uma mensagem para processar a operao de envio MPI_SEND. A operao especifica um buffer de envio na memria do remetente da mensagem do qual os dados da mensagem so retirados. No exemplo acima, o buffer de envio consiste de um armazenamento contendo a varivel message na memria do processo zero. A localizao, o tamanho e o tipo do buffer de envio so especificados pelos primeiros trs parmetros da operao de envio. A mensagem enviada ocupar 13 caracteres dessa varivel. Em adio, a operao de envio associa um envelope mensagem. Esse envelope especifica o destino da mensagem e contm informao que pode ser utilizada para a operao de recepo conseguir selecionar uma mensagem em particular. Os ltimos trs parmetros da operao de envio juntamente com o rank do remetente, especificam o envelope para a mensagem enviada. O processo um (myrank=1) recebe essa mensagem com a operao de recepo MPI_RECV. A mensagem a ser recebida selecionada de acordo com o valor do seu envelope e os dados da mensagem so armazenados no buffer de recepo. Nesse exemplo, o buffer de recepo consiste de um armazenamento contendo a string message na memria do processo um. Os primeiros trs parmetros da operao de recepo so usados para especificar a localizao, o tamanho e o tipo do buffer de recepo. Os prximos trs parmetros so utilizados para selecionar a mensagem entrante. O ltimo parmetro usado para informao de retorno sobre a mensagem recebida.

100

RPC: Segue uma aplicao standalone que ser convertida num RPC (Esse exemplo de RPC desenvolvido em ambiente Windows): // Arquivo Standalone.cpp #include <iostream> // Funo futura do Servidor. void Output(const char* szOutput) { std::count << szOutput << std::endl; } int main() { // Chamada futura do cliente Output ("Hello Lonely World!"); } Agora temos o cdigo para a gerao do IDL (Interface Definition Language) que uma linguagem para definio de interfaces. Podemos comparar a IDL como um cabealho de um programa em C com mais funcionalidades:

101

// Arquivo Example1.idl [ // Um identificador nico que distingue essa // interface das outras. uuid(00000001-EAF3-4A7A-A0F2-BCE4C30DA77E), // Essa a verso 1.0 dessa interface. version(1.0), // Essa interface ser usada como um suporte para // ligao implcita chamada hExample1Binding. implicit_handle(handle_t hExample1Binding) ] interface Example1 // A Interface chamada Example1 { // Uma funo que toma uma string terminada em zero. void Output( [in, string] const char* szOutput); } Para usar o IDL numa aplicao ns precisamos process-lo atravs de programas, como por exemplo, o midl.exe que traduzir o IDL para um client stub e um server stub que sero compilados posteriormente por um compilador C.

102

Figura 11 O prximo passo seria gerar os arquivos e coloc-los em uso na aplicao de servidor. // Arquivo Example1Server.cpp #include <iostream> #include "Example1.h" // Funo de Servidor. void Output(const char* szOutput) { std::count << szOutput << std::endl; }

int main() { RPC_STATUS status; // Usa o protocolo combinado com o endpoint para receber // remote procedure calls (RPC). status = RpcServerUseProtseqEp( reinterpret_cast<unsigned char*>("ncacn_ip_tcp"), // Uso do protocolo TCP/IP

103

RPC_C_PROTSEQ_MAX_REQS_DEFAULT, // Fila de tamanho do backlog para TCP/IP. reinterpret_cast<unsigned char*>("4747"), // Porta TCP utilizada. NULL); // Sem segurana. if (status) exit(status); // Registra a interface do Example1. status = RpcServerRegisterIf( Example1_v1_0_s_ifspec, // Interface to register. NULL, // Usa o vetor entry point gerado pelo MIDL. NULL); // Usa o vetor entry point gerado pelo MIDL. if (status) exit(status); // Comea a ouvir por RPCs em todas as interfaces registradas // Essa chamada no ser retornada at que o // RpcMgmtStopServerListening seja chamado. status = RpcServerListen( 1, // Nmero mnimo de threads recomendado. RPC_C_LISTEN_MAX_CALLS_DEFAULT, // Nmero //mximo de threads recomendado. FALSE); // Passa a efetivamente a ouvir por RPCs nesse momento. if (status) exit(status);

104

} // Funo de alocao de Memria para o RPC. // O runtimeusa essas duas funes para alocar/liberar // a memria suficiente para passar a string para o servidor. void* __RPC_USER midl_user_allocate(size_t size) { return malloc(size); } // Memory deallocation function for RPC. void __RPC_USER midl_user_free(void* p) { free(p); } Esse cdigo apesar de diferente da aplicao standalone, possui significativa semelhana a um processo sendo executado num mesmo computador. Existem alguns cdigos de inicializao para registrar a interface, mas a funo de sada permanece a mesma. Segue a aplicao cliente que conectar com o servidor: // Arquivo Example1Client.cpp #include <iostream> #include "Example1.h" int main() { RPC_STATUS status;

105

unsigned char* szStringBinding = NULL; // Cria-se uma string de manipulao de ligao. // Essa funo nada mais do que um printf. // A conexo no est ainda estabelecida. status = RpcStringBindingCompose( NULL, // UUID to bind to. reinterpret_cast<unsigned char*>("ncacn_ip_tcp"), // Uso do protocolo // TCP-IP. reinterpret_cast<unsigned char*>("localhost"), // Uso de endereo IP reinterpret_cast<unsigned char*>("4747"), // Uso da porta TCP. NULL, // O Protocolo depende da opo de rede utilizada. &szStringBinding); // String de ligao de sada. if (status) exit(status); // Valida o formato da string manipulao de ligao e a converte // para uma manipulao de ligao. // A conexo ainda no est estabelecida. status = RpcBindingFromStringBinding( szStringBinding, // A string de ligao a ser validade. &hExample1Binding); // Coloca o resultado numa manipulao // implcita de ligao definida no arquivo IDL. if (status) exit(status);

106

RpcTryExcept { // Chama a funo RPC. A manipulao de ligao hExample1Binding // usada implicitamente. // A conexo realizada nesse momento. Output("Hello RPC World!"); } RpcExcept(1) { std::cerr << "Runtime reported exception " << RpcExceptionCode() << std::endl; } RpcEndExcept // Libera a memria alocada pela string. status = RpcStringFree( &szStringBinding); // String a ser liberada. if (status) exit(status); // Libera os recursos de manipulao de ligao e desconecta-se do servidor. status = RpcBindingFree( &hExample1Binding); // Libera a manipulao implcita de ligao definida no // arquivo IDL. if (status)

107

exit(status); } // Funo de alocao de memria para o RPC. // O runtime usa essas duas funes para alocao/liberao // de memria suficiente para passar a string para o servidor. void* __RPC_USER midl_user_allocate(size_t size) { return malloc(size); } // Funo de liberao da memria para o RPC. void __RPC_USER midl_user_free(void* p) { free(p); } Resumindo, primeiro necessita-se processar o arquivo IDL para obter-se o client stub, o server stub e o arquivo comum de cabealho. O client stub e o server stub so compilados, como uma implementao de cliente e servidor. Faz-se o linkedit das duas aplicaes, executando as mesmas.

108

Figura 12

Tratando-se de plataforma Linux existem algumas variaes de implementao. A padronizao do formato dos dados que no ambiente Windows realizada atravs do cdigo IDL, no ambiente Linux utiliza-se o padro XDR (External Data Representation Standard) definido na RFC 1832. O objetivo dessa linguagem garantir a portabilidade do RPC em arquiteturas diversas. Segue uma especificao bsica do XDR: program NOMEDOPROGRAMA { version NOMEDAVERSAO { TIPO NOMEDOPROCEDIMENTO (TIPO ARGUMENTO) = X; } = Y; } = 123456789; TIPO = NOME; As palavras program e version no podem ser usadas para identificar os programas e procedimentos.

109

Seguido da palavra program dever conter o nome do programa, que ir agrupar uma ou mais verses de um ou mais procedimentos. Seguido da palavra version dever constar o nome da verso de um ou mais procedimentos. O nome de uma verso no pode ocorrer mais de uma vez no mesmo escopo de definio de um programa. O nome de um procedimento no pode ocorrer mais de uma vez numa mesma verso. Os identificadores dos programas ficam no mesmo espao de endereamento das definies dos tipos de dados e constantes utilizadas. Por conveno os nomes de programa, verso e procedimento devero ser escritos em letras maisculas. X um nmero inteiro positivo que identifica o nmero de um procedimento. Y um nmero inteiro positivo que identifica o nmero da verso do conjunto de procedimentos. TIPO um tipo de dado que um procedimento poder retornar ou receber como argumento. Poder ser: int, char, string, void, enum, bolean, float, double e structure. ARGUMENTO o nome do argumento que o procedimento ir receber. Ele dever ser de um TIPO especfico.

110

123456789 define o nmero do programa. Este nmero dever ser escrito na forma hexadecimal, 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.com definido pelo usurio transiente reservado reservado reservado reservado reservado

O primeiro grupo de nmeros administrado pela SUN MICROSYSTEMS e padronizado em todos os sistemas. O segundo grupo poder ser usado por alguma aplicao especfica. Se uma aplicao RPC desenvolvida for de interesse geral, poder requerer um nmero do primeiro grupo. O terceiro grupo utilizado pelas aplicaes que criam nmeros dinamicamente. Os demais grupos so reservados para uso futuro. Segue um exemplo simples protocolo utilizando a definio XDR: program PROGRAMAPING { /LTIMA VERSO DO PROGRAMA EM TESTE version PING_ULTIMAVERSAO { void PING_PROCEDIMENTO_NULL(void) = 0; int PING_PROCEDIMENTO_BACK(int NUM) = 1; } = 2; /VERSO ORIGINAL EM PRODUO Version PING_VERSAOORIGINAL {

111

void PING_PROCEDIMENTO_NULL(void) = 0; } = 1; } = 20000001 Nesse exemplo a definio estabelece duas verses distintas de procedimentos. Verso 2 para PING_ULTIMAVERSAO e verso 1 para PING_VERSAOORIGINAL. A verso PING_ULTIMAVERSAO possui dois procedimentos e a verso

PING_VERSAOORIGINAL apenas um. O programa PROGRAMAPING tem como identificao o nmero 20000001. Por conveno, o protocolo deve ser salvo com a extenso x. Esse programa pode ser compilado pelo programa rpcgen que est disponvel no pacote de compiladores GLIBC. Como a definio IDL do Windows ele gerar os seguintes cdigos em linguagem C: Um arquivo de cabealho com as definies comuns ao servidor e cliente. Um conjunto de rotinas XDR que traduzem os tipos definidos no arquivo de cabealho. Um programa base com as chamadas RPC para os servidores. Um programa base com as chamadas RPC para o cliente. Considerando que salvamos o cdigo acima como ping.x, o rpcgen gerar os seguintes arquivos: ping.h Cabealho com definies comuns ao servidor e cliente. ping_clnt.c Programa base com as chamadas de RPC para o cliente. ping_svc.c Programa base com as chamadas de RPC para o servidor. ping_xdr.c Filtros XDR para comunicao entre arquiteturas diferentes.

112

Dificuldades na manipulao de processos num ambiente de processamento distribudo Race Message Considerando um ambiente utilizando DSM (Distributed Shared Memory) podemos dizer que os desafios decorrentes de uma corrida (race) de processos so muito semelhantes aos enfrentados na computao monoprocessada, pois essa condio est relacionada ao compartilhamento de memria. Temos, porm, h outro tipo de race que ocorre em sistemas distribudos que utilizam passagem de mensagem, quando muitas requisies conflitantes de clientes competem para acessar o mesmo servidor. Podemos ilustrar messages races atravs do diagrama abaixo. Considere trs processos P1, P2 e P3. 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 assncronos. As mensagens trocadas entre os processos so representadas pelas flechas. O lado no pontiagudo da seta representa o envio da mensagem. O lado pontiagudo representa o recebimento da mensagem.

113

P1

P2

P3

Mensagem 1 Mensagem 2 b c

Figura 13 Devido a no previsibilidade em certos escalonamentos de processos e atrasos em mensagens, a ordem em que as mesmas so recebidas incerta. Por exemplo, a Mensagem 1 pode ter algum atraso, desse modo a Mensagem 2 pode ser recebida primeiro. Esse no determinismo causa um problema, mesmo executando o sistema com a mesma entrada no garantida a reproduo da execuo original. Seguem algumas caractersticas de uma message race: O efeito sobre o controle de fluxo do sistema. Uma message race pode causar que um sistema tome um caminho de execuo diferente, dependendo como o mesmo tratado. A severidade da corrida. Uma corrida benigna no causa efeito externo nos resultados do sistema. Uma corrida crtica afeta o resultado do sistema. Uma abordagem para detectar e minimizar os efeitos de race message de natureza preventiva, isto , ferramentas de testes e monitoramento que verificam a ocorrncia desse tipo de evento, antes que o sistema distribudo seja liberado para operao. Basicamente esses sistemas executam rotinas de troca de mensagem repetidamente para verificar se os resultados so os mesmos. Caso os resultados sejam diferentes temos um indcio de uma race condition crtica. Uma dessas ferramentas a TMT (Testing and Monitoring Tool) para sistemas distribudos desenvolvida pela Siemens AG da Alemanha.

114

Temos tambm o MPIRace-Check (PARK, 2007) desenvolvido por pesquisadores das Universidades de Chonnam e Gyeongsang.

Deadlocks em Sistemas Distribudos Deadlocks em sistemas distribudos so similares a deadlocks em sistemas monoprocessados, sendo usualmente de soluo mais onerosa, por serem mais difceis de serem evitados, detectados ou de terem uma preveno efetiva, devido aos dados estarem espalhados entre vrios processos e computadores. As quatro principais estratgias para manipular dealocks em sistemas distribudos so: Indiferena: Ignora-se o problema de deadlock. Deteco: Permite a ocorrncia de deadlocks, os detecta, tentando recuperar os processos. Preveno: Torna estatisticamente os deadlocks impossveis em termos estruturais. Evitao: Evita os deadlocks por alocar os recursos com cuidado. A indiferena ocorrncia de deadlocks popular tanto em sistemas

monoprocessados como em sistemas distribudos, muitas vezes deixando a atividade de manipular os deadlocks para as prprias aplicaes como, por exemplo, um banco de dados. A tcnica de deteco e recuperao popular porque a preveno e a evitao so de difcil implementao. A preveno de deadlocks possvel devido existncia de transaes atmicas, que tcnica de voltar as transaes para suas condies iniciais caso ocorra alguma indisponibilidade durante a execuo das mesmas. A evitao de deadlocks usada raramente pela dificuldade de saber-se a priori o quanto de recurso cada processo precisar numa dada transao. Como a preveno e evitao so de difcil implementao, a tcnica mais explorada na prtica seria a deteco, tendo como principal recurso as transaes atmicas.

115

A deteco de deadlocks utiliza uma tcnica conhecida como WFG (Wait-For-Graph), onde os processos so modelados em termos de grafos, estabelecendo que um n representa um processo, um arco representa um processo que est esperando por outro que mantm um recurso que ele deseja e um crculo que representa um deadlock. Quando tratamos de deteco de deadlocks em sistemas distribudos, uma das tcnicas utilizada seria a deteco centralizada de deadlocks que de certa forma segue a mesma linha de raciocnio utilizada nos sistemas monoprocessados. Nessa tcnica cada computador mantm um grafo de recursos prprios e o coordenador mantm um grafo de recursos para todo o sistema. O coordenador detecta um crculo, cancelando (kill) um dos processos para interromper o deadlock. Para que o coordenador mantenha um grafo de recursos do sistema global, um sistema de mensagens utilizado. Em termos de algoritmos que tratam as abordagens para resoluo do problema de deadlock, temos os algoritmos de deteno de Chandy-Misra-Haas (CHANDY, 1983) que permite que um processo possa esperar por mais de um recurso ao mesmo momento, havendo um sistema de troca de mensagens para verificar a existncia de crculos e consequentemente deadlocks. Para preveno temos os algoritmos Wait-die e Wound-wait, que trabalham com timestamp (tempo em que o processo comea a utilizar o recurso), tendo cada algoritmo uma abordagem e estratgias diferentes ao utilizarem essas informaes. Para a evitao temos o algoritmo do banqueiro desenvolvido por Edsger Dijkstra (DIJKSTRA, 1977) que trabalha com uma previso e controle dos recursos dos processos manipulados pelo mesmo.

116

O Problema do Drink dos Filsofos Ao abordar a questo de alocao de recursos em sistemas monoprocessados apresentamos alguns problemas clssicos para abordagem desse aspecto da computao, dentre eles o Jantar dos Filsofos. Temos uma variao desse problema aplicada para computao distribuda conhecida como o Drink dos Filsofos em que uma das solues proposta por K. M. Chandy12 (CHANDY, 1984) e J. Misra13 (MISRA, 1984), utiliza a abordagem de favorecer um dos processos em detrimento dos outros numa situao de conflito entre os mesmos. Esse problema uma generalizao do problema do Jantar dos Filsofos que como vimos, trabalha com a questo da sincronizao, que j abordamos nesse trabalho. Nesse caso, os processos so os filsofos, localizado nos vrtices do grafo G. Um filsofo pode estar em um de trs estados: (1) Tranquilo (2) Sedento (3) Bebendo. Os lados do tringulo seriam as garrafas de bebida. Um filsofo pode beber somente de garrafas (lados) que formam o seu vrtice. Um filsofo tranquilo pode tornar-se sedento. Um filsofo sedento precisa de garrafas cheias para ele saciar a sua sede. Ele pode necessitar de uma quantidade diferente de garrafas em diferentes rodadas de bebida. Ao manter e tomar todas as garrafas que o filsofo se apropria, ele entra num estado de filsofo bebendo, mantendo-se nesse estado at tomar toda bebida que necessita, retornando ao estado de filsofo tranquilo aps um tempo finito. O processo favorecido deve ter alguma propriedade que o distinga dos outros. Para garantir certa justia nessa escolha, a propriedade que distingue o processo escolhido no sempre a mesma. Uma implementao distribuda de um grafo de precedncia acclica, onde a profundidade do processo (a mais longa cadeia de predecessores) seria uma das propriedades distintivas, podendo garantir a rotatividade da escolha do processo favorecido. Uma simples regra de resoluo de conflito associada a um grafo acclico garante uma resoluo justa para todas as situaes dessa natureza segundo os autores.

12

Kanianthra Mani Chandy professor de Cincia da Computao no California Institute of Technology. Ele foi o Chefe Executivo do departamento por duas vezes e tambm professor na Caltech desde 1989. 13 Jayadev Misra detm a cadeira Schlumberger Centennial em Cincia da Computao, sendo tambm professor dessa disciplina.

117

Para entender o problema do Drink dos Filsofos, precisamos compreender alguns conceitos de modelos de grafos de conflito. Um sistema distribudo representado pelo grafo G com uma correspondncia um para um entre os vrtices (p, q e r) que correspondem a processos. Esse modelo no considera a precedncia dos processos em caso de conflito, no havendo uma distino entre eles. No modelo H existe uma precedncia entre os processos indicada pelas setas.

Grafo G Figura 14

Grafo H

A ttulo de ilustrao no caso do grafo H, p, q e r teriam como profundidade no que se refere a predecessores em relao a r, respectivamente 0, 1 e 2. Para garantir a justia na escolha dos processos que por ventura entrarem em conflito considerando o grafo H, necessrio, nesse caso, uma mudana de quantidade de predecessores dos processos participantes dos conflitos. Com essas informaes preliminares podemos agora abordar o problema do Drink dos Filsofos com mais propriedade. Um filsofo pode estar num estado tranquilo por um perodo de tempo arbitrrio. Dois filsofos so vizinhos se e somente se houver um lado entre eles no grafo G. Os vizinhos podem enviar mensagens um para o outro. As mensagens so entregues num tempo arbitrrio, mas finito. Os recursos, tal como as garrafas, so codificados e transmitidos como mensagens. O problema resolvido atravs de uma soluo no probabilstica que satisfaa as seguintes condies: Justia. Nenhum filsofo fica sedento para sempre.

118

Simetria. Todos os filsofos obedecem precisamente todas as regras para adquirir ou liberar garrafas. No h prioridade ou qualquer outra forma de aquisio parcial externamente especificada entre filsofos e garrafas. Economia. O Filsofo envia e recebe um nmero finito de mensagens entre as transies de estado. Em particular, um filsofo tranquilo no envia nem recebe um nmero infinito de mensagens. Concorrncia. A soluo no nega a possibilidade de beber-se simultaneamente de diferentes garrafas por diferentes filsofos. Ligao. Um nmero de mensagens em trnsito, a qualquer momento, entre qualquer par de filsofos uma ligao. Alm disso, o tamanho da mensagem tambm considerado uma ligao. O problema dos Filsofos Bebendo um paradigma geral para modelar conflitos entre processos. Filsofos vizinhos sero impedidos de beber simultaneamente se eles desejarem beber da mesma garrafa esse um modelo de situao conflito para acesso exclusivo para arquivos comum. Filsofos vizinhos podem beber simultaneamente de garrafas diferentes esse um modelo de situao para processos de gravao em diferentes arquivos. Deve-se prevenir o sistema de entrar em estados em que filsofos vizinhos so indistinguveis. Por exemplo, considere filsofos organizados num anel e o estado de cada filsofo de beber de sua garrafa esquerda filsofos no possuem uma caracterstica que possa distingui-los. Se todos os filsofos estiverem bebendo de suas bebidas esquerda e ento requererem as duas garrafas para prxima rodada, ento os filsofos permanecero sedentos para sempre porque um algoritmo determinstico no pode escolher entre filsofos indistinguveis. Entretanto, um estado do sistema certamente possvel seria quando todos os filsofos mantm sua garrafa esquerda. Se esse estado for proibido, estaramos proibindo um estado vivel com o qual estaramos obtendo algum sucesso, simplesmente para resolver um nico problema, proibir que um estado que vivel viole a condio de Concorrncia. Parece estarmos num dilema, pois as condies de processos simtricos, solues no probabilsticas e concorrncia so incompatveis nesse problema. A soluo seria implementar grafo de precedncia H utilizando recursos auxiliares especiais.

119

O grafo H sempre acclico. A profundidade do processo sua caracterstica de distino em relao aos outros. O grafo implementado utilizando a mesma abordagem dos garfos do problema do Jantar dos Filsofos. Dois processos compartilham um grafo se existe a possibilidade de conflito entre eles. A regra para resoluo do conflito seria: um processo u cede num conflito com um processo v se e somente se u no manter o garfo compartilhado com v. O algoritmo garante que se os processos v e u esto em conflito e u tiver precedncia sobre v no grafo de precedncia, ento a resoluo do conflito eventualmente resolver o conflito em favor de u. Essa mesma abordagem utilizada na resoluo problema dos Drink dos Filsofos.

120

Escalonamento de processos em sistemas distribudos As tcnicas de escalonamento usadas pelos sistemas operacionais em geral so baseadas em sua grande parte na premissa que os processos so independentes. Assume-se que as interaes entre os processos so mais excees do que a regra. Porm tratando-se de sistemas distribudos a independncia dos processos torna-se no vlida com o passar do tempo. Em sistemas multiprocessados, dentre eles os sistemas distribudos, tem-se sido encorajado um tipo de programao onde colees de processos cooperativos usam muitos processadores concorrentemente para realizar tarefas. Grupo de processos utilizado mesmo no monoprocessamento, por exemplo, no mecanismo de pipeline do Unix/Linux. Assim podemos assumir que os processos seriam criados em grupos e que a comunicao intragrupo seria muito mais frequente que a comunicao intergrupo. Podemos tambm considerar que um nmero significativo de processadores estar disponvel para tratar esses grupos de processos e que cada processador utilizar o mecanismo de executar mltiplas instrues num mesmo ciclo de clock conhecido como multiprogamao N-way.

Figura 15

121

John K Ousterhout14 (OUSTERHOUT, 1982) props alguns algoritmos para tratar o escalonamento em sistemas distribudos dentro do conceito que ele chamou coscheduling. Esse algoritmo considera os padres de comunicao interprocessos enquanto estabelece um escalonamento para garantir que todos os membros do grupo sejam executados ao mesmo tempo, como podemos ver na matriz representada pela Figura 15. Dessa forma, a coluna 4 consiste de todos os processos executados no processador 4. A linha 3 a coleo de todos os processos que so executados no time slot 3 de um dos oito processadores, iniciando com o processo do processador nmero 0. O essencial dessa ideia ter cada processador utilizando um algoritmo de escalonamento round robin, que seria um escalonamento sequencial sem retornar ao incio da sequencia ao final da varredura, tendo todos os processadores executando os processos no slot 0 num perodo fixo, ento tendo todos os processadores executando os processos no slot 1, assim por diante. Uma mensagem TCP-IP pode ser utilizada para informar para cada processador quando uma troca de processo ocorre, para manter a sincronizao dos time-slots. Assim, a melhor maneira de utilizar esse algoritmo ao manipular grupo de processos, seria colocar todos num mesmo time slot, para que sejam executados

simultaneamente, maximizando os recursos de comunicao interprocessos. Existem variaes desse modelo visando uma melhoria de desempenho, por exemplo, podemos separar as linhas da matriz e concaten-las de modo a criar uma nica longa linha. Nesse modelo um grupo de processos colocado nessa tabela contnua, a fim de ter cada processo do grupo alocado a um processador. Caso, num primeiro momento, isso no for possvel, 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. O escalonamento utiliza o mesmo mtodo de estabelecer-se uma janela que ir mover-se da esquerda para direita at que todos os processos sejam executados, quando isso ocorre, retorna-se para o lado esquerdo da tabela e inicia-se uma nova varredura para um novo grupo de processos.

14

John K. Ousterhout professor e pesquisador do departamento de Cincia da Computao na Universidade de Stanford. Ele tambm presidente da Electric Cloud, Inc. Ele provavelmente mais conhecido como o criador da linguagem de script Tcl. Obteve Mestrado em Fsica na Universidade de Yale e doutorado em Cincia da Computao na Universidade Carnegie Mellon.

122

Escalonamento em sistemas em tempo real em computao distribuda Comparado ao escalonamento em sistemas em tempo real em computao monoprocessada, o escalonamento de tarefas em tempo real em ambiente distribudo de implementao consideravelmente mais complexa. Temos visto que

escalonamento para sistemas monoprocessados, executando tarefas em tempo real, possui uma complexidade polinomial (Complexidade P). Entretanto, para determinar um sistema timo para tarefas em tempo real para sistemas distribudos necessitamos de resolver problemas de complexidade NP (Nondeterministic Polynomial Time). O escalonamento em sistemas distribudos consiste em dois subproblemas: alocao de tarefas aos processadores e escalonamento de tarefas em processadores individuais. O problema de designao de tarefa refere-se como particionar um grupo de tarefas e ento design-las aos processadores. Essa designao pode ser esttica ou dinmica. Enquanto que a designao esttica permanente, a dinmica varivel e as tarefas so designadas aos ns na medida em que surgem, podendo ter diferentes instncias de uma tarefa alocadas em diferentes ns. Depois que as tarefas so alocadas aos diferentes processadores, a dinmica passa ser semelhante ao escalonamento em ambientes monoprocessados, tendo cada n do sistema distribudo tratando dos processos a ele designado. Por suas caractersticas usualmente complexa, o escalonamento em tempo real em sistemas distribudos alcanado atravs de algoritmos heursticos. Um aspecto crtico nos sistemas distribudos em tempo real a temporizao (clock). Alm do uso tradicional do clock nos sistemas operacionais, nos sistemas distribudos o mesmo utilizado para timeout e timestamping. O timeout tem como funo principal determinar a falha na execuo de uma tarefa aps um tempo pr-determinado. Timestamping utilizado para informar na prpria mensagem o tempo no qual a mesma saiu de sua origem, para fins de reconhecimento da idade das mensagens e assim como a ordenao das mesmas. Problemas de sincronizao so especialmente crticos em sistemas distribudos por comprometerem a troca de mensagens que so o meio de comunicao entre processos nessa modalidade de processamento.

123

Aplicaes Multimdia em Sistemas Distribudos Os sistemas multimdia representam uma classe especial de sistemas complexos de computao. Como tal, seus projetos devem partir da premissa que necessitaro considerar como caracterstica principal uma quantidade imensa de dados que precisam ser processados e transmitidos de maneira contnua, cumprindo as exigncias relativas a sincronizao a fim de ter mensagens ntegras recebidas pelo usurio final. Outro aspecto essencial a qualidade de servio (QoS) que compreende itens como reserva de banda, latncia, jitter, etc. Nos sistemas multimdia, os requerimentos de QoS variam consideravelmente de uma mdia para outra, por exemplo, fluxos de vdeos requerem uma vazo consistentemente alta, mas tem certa tolerncia para certos nveis de jitter e erros de pacotes. Em contraste, as aplicaes de udio manipulam um volume muito menor de dados (portanto, no requerendo alta largura de banda), porm so mais sensveis a jitter e taxa de erros. Fluxos de mdia contnua tm duas propriedades importantes. A primeira seria sua fidelidade usualmente dependente da sequencia temporal dos dados. Essa propriedade temporal de mdias contnuas impe requerimentos que faz com que os cdigos que manipulam fluxos de mdia necessitem ser escalonados dentro de janelas de tempo aceitveis. A segunda propriedade seria que eles so normalmente tolerantes perda de contedo da informao, particularmente se conhecemos a caracterstica da informao (por exemplo, muitos modelos de compresso so estabelecidos baseados na percepo humana de sons e imagens para alcanar maiores taxas de compresso). Podemos dizer que em contraste a aplicaes convencionais, aplicaes multimdias so sensveis a variaes de tempo e no tanto exigentes perda de parte das informaes. Devido a isso os protocolos de transporte de voz e vdeo utilizam normalmente pacotes UDP, como por exemplo, o RTP (Real Time Protocol). Abordando o aspecto de redes, segue uma descrio dos principais protocolos que tratam de comunicao de sistemas multimdia, dando suporte aos processos de transmisso, recepo e execuo de aplicaes multimdias.

124

RTP (Real Time Protocol): O transporte de fluxos de mdia nas diversas aplicaes, na maioria dos casos implementado com RTP, o qual protocolo baseado em IP para transmisso de dados e voz. Ele um protocolo leve sem controle de erro e de fluxo, QoS e reserva de recurso. Para garantir sincronismo e a ordenao dos pacotes, o RTP prov dispositivos como timestamping, sequenciamento, dentre outros. Timestamping a uma das mais importantes informaes para aplicaes em tempo real. O remetente informa tempo quando pacote processado. O destinatrio usa o time stand para reconstruir a temporizao original. O RTP no por si mesmo responsvel pelo sincronismo, essa funo feita no nvel de aplicao. Os nmeros de sequencia so utilizados para determinar a ordem correta, pois o UDP no tem apenas essa funcionalidade. O sequenciamento tambm utilizado para deteco de perda de pacotes. O identificador de payload especifica o formato do mesmo assim como a codificao e compresso. Utilizando esse identificador, a aplicao sabe como interpretar e executar os dados do payload. Exemplos de especificaes seriam PCM, MPEG1 / MPEG2, etc. A identificao da origem permite que no recebimento do pacote a aplicao saiba de onde os mesmos esto vindo. Por exemplo, numa udio-conferncia, pelo identificador da origem possvel saber quem est entrando na mesma. RTCP (RTP Control Protocol): Protocolo de controle designado para trabalhar em conjuno com o RTP. Durante uma sesso RTP, os participantes periodicamente trocam pacotes RTCP para transmitir informaes sobre a qualidade da entrega dos dados e de participao em sesses.

125

RTSP (Real Time Streaming Protocol): O RTSP um protocolo de apresentao cliente-servidor para habilitar a entrega controlada de fluxos de multimdia em redes IP. O RTSP prov mtodos para executar comandos tais como play, fast-forward, fast-rewind, pause e stop, similar as funcionalidades oferecidas por aparelhos de CD e DVD. Ele um protocolo em nvel de aplicao designado para trabalhar com os protocolos de nvel mais baixo como RTP e o RSVP (Resource Reservation Protocol), agindo como um controle remoto para servidores de multimdia, utilizando TCP ou UDP. O RTSP pode ter um ou vrios fluxos de mdia contnuos. RSVP (Resource Reservation Protocol) O RSVP um protocolo de controle que permite um usurio do recurso multimdia requisitar uma qualidade de servio fim a fim para o seu fluxo de dados. Assim, uma aplicao em tempo real pode usar o RSVP para reservar os recursos necessrios ao longo de todo o encaminhamento dos pacotes, a banda requisitada atravs desse protocolo. Dentro da abordagem de sistemas multimdia distribudos, temos a utilizao de um sistema com mltiplos discos para armazenagem de objetos de som e vdeo. De fato, a tendncia utilizar mltiplos discos na maioria das aplicaes, seja para prover redundncia, seja para obter uma maior capacidade de armazenagem. A segunda opo seria a mais aplicvel aos sistemas multimdia distribudos que requerem um espao em disco considervel, especialmente quando estamos tratando de Vdeo on Demand (VoD). Podemos ter mltiplos discos num nico computador, num dispositivo dedicado a armazenagem (storage) ou discos espalhados numa rede computadores utilizando, por exemplo, PVFS (Parallel Virtual File System). Assumindo servidores de sistemas multimdia com mltiplos discos, os blocos de dados so alocados nos discos de maneira a distribuir a carga de uma execuo de um vdeo, por exemplo, igualmente entre os mesmos. Assim a forma de distribuir dos dados em conjuno com as tcnicas de escalonamento podem afetar a apresentao contnua e o desempenho dos servidores multimdias. A duas abordagens amplamente conhecidas de alocar blocos de objetos multimdia entre controladores de mltiplos discos so: restrita e irrestrita. Um exemplo tpico de alocao restrita de dados o acesso aos discos utilizando a tcnica round robin.

126

Um exemplo de alocao irrestrita de dados seria o acesso randmico aos discos. Baseados nas tcnicas de alocao e escalonamento de dados, ns podemos classific-las em quatro abordagens: Baseada em ciclos e alocao round robin; Controlada por deadline e alocao randmica; Baseada em ciclos e alocao randmica; Controlada por deadline e alocao round robin; Abordagem baseada em ciclos e alocao round robin: Muitos estudos investigaram a combinao escalonamento baseado em ciclos e alocao de dados em round robin. Com essa abordagem, um bloco recuperado de cada controladora de disco para exibio num certo perodo de tempo. A carga do sistema deve ser distribuda entre as controladoras dos discos de modo a prevenir gargalos. Essa carga pode intencionalmente atrasar a recuperao de um primeiro bloco de um objeto requisitado sempre que um gargalo surge num disco. Devido a harmonia da alocao de dados em round robin e a recuperao peridica de dados baseada em ciclos, essa abordagem prov a garantia de um servio determinstico livre de congelamento de imagem ou som num objeto multimdia, uma vez que sua recuperao iniciada. Essa abordagem maximiza a utilizao da largura de banda dos controladores de disco por distribuir a carga da exibio entre os discos igualmente. Assim, a vazo do sistema escala linearmente em funo do nmero de controladores de discos no sistema. A desvantagem dessa abordagem seria a latncia no incio de recuperao dos dados. Assim esse sistema seria mais adequado para aplicao que requer uma vazo alta e poderia tolerar uma latncia de incio longo, como por exemplo, os sistemas de filmes sob demanda. Abordagem controlada por deadline e alocao randmica: No muitos estudos tm investigado a abordagem com o escalonamento utilizando o conceito de deadline e a alocao randmica de dados. Atravs do controle dos deadlines para recuperao de blocos, essa abordagem pode prover uma latncia mais curta para o incio da recuperao dos dados do que a abordagem baseada em ciclos e round robin.

127

Dessa forma, essa abordagem mais apropriada para aplicaes que requerem uma latncia de incio curta tal como um sistema de editorao digital. Entretanto, essa abordagem pode permitir uma variao estatstica no nmero de recuperaes de blocos num disco. Devido natureza da alocao dinmica, um disco poderia receber mais requisies do que os outros. A formao de gargalo numa controladora de disco pode resultar na violao de deadlines estabelecidos nos blocos requisitados, causando congelamento na execuo. Essa probabilidade pode ser significativa, dependendo da carga do sistema. Abordagem baseada em ciclos e alocao randmica: A abordagem de escalonamento cclico e a alocao de dados randmica pode ser desconsiderada para uma anlise mais aprofundada, devido suas desvantagens. Primeira, essa abordagem no pode prover a garantia de um servio determinstico como com a baseada em ciclos e round robin, devido a alocao randmica dos dados. Segunda, essa abordagem no pode prover uma latncia de incio curta como a controlada por deadlines e randmica devido alocao cclica. Terceira essa abordagem resulta na baixa utilizao da velocidade do disco porque as requisies podem ser distribudas desigualmente entre os discos que finalizarem um ciclo mais cedo e assim ficarem inativos at que os outros discos terminem seus respectivos ciclos. Abordagem controlada por deadline e alocao round robin: De maneira similar, a abordagem de escalonamento controlado por deadline e alocao por round robin devido as suas desvantagens no convm ser considerada como uma alternativa vivel. Com ela, uma vez que um gargalo ocorre num controlador de disco, ele ocorrer repetidamente devido a alocao round robin e recuperao de dados sequencial na execuo de objetos multimdia. O gargalo s acabaria quando um ou mais participantes do mesmo finalizassem a execuo. Assumindo uma situao de filmes sob demanda, um gargalo poderia durar por o tempo de exibio do filme, no pior dos casos. Com a alocao dinmica, o gargalo resolvido mais rapidamente devido a carga ser distribuda baseada num padro aleatrio.

128

Video on Demand Um sistema de VoD (Video on Demand) pode ser usualmente considerado como um repositrio variado de objetos multimdia com um grande de nmero de usurios dispersos. Esses objetos devem ser servidos aos clientes sob sua demanda. Geralmente um Servidor de Fluxo de Mdia Distribudo que atua como um VoD posicionado numa rede com topologia hierrquica, com os Servidores Centralizados de Multimdia individuais como ns e os enlaces de rede como ligaes na hierarquia. Os ns so capazes de armazenar um nmero limitado de objetos multimdia e podem afluir um nmero finito desses objetos. Das aplicaes de multimdia distribudas, como VoD, esperado prover um servio para um nmero significativo de clientes, algumas vezes dispersos geograficamente. Utilizar um nico grande Servidor Centralizado de Sistemas Multimdia para suportar clientes distribudos resultaria numa alocao ineficiente de recursos e num projeto virtualmente impraticvel. A largura de banda necessria para implementar um VoD interativo com tal abordagem seria imensa. Por outro lado, utilizar um grupo distribudo mas independente de Servidores Centralizados de Sistemas Multimdia locais, isto , num desenho distribudo sem compartilhamento de recursos, tambm se tem mostrado ineficiente. De fato, a ideia de conectar recursos em redes, seja em redes privadas seja na Internet, foi originalmente motivada por esse problema. O real potencial econmico de aplicaes de multimdia distribudas no ser alcanado a menos que a efetividade dos custos da soluo seja alcanada para servir os usurios dos sistemas multimdia. O foco dessa anlise ser aplicao VoD porm os princpios aqui discutidos podero ser aplicados para outras aplicaes de multimdia. Para suportar aplicao de fluxos distribudos, existem pesquisas focadas em vrias tcnicas para, ou reduzir os requerimentos de banda de fluxos individuais de mdia, com mtodos tais como smoothing (utilizao de buferizao para reduzir as rajadas na transmisso de contedos de multimdia), staging (utilizao de servidores proxy colocados entre os clientes e os servidores de fluxos de multimdia) e negociao de banda, para reduzir o requerimento de banda como um todo via agregao ou a multiplexao estatstica, utilizando, por exemplo, batching (tcnica relacionada aos modelos hierrquicos de topologia de sistemas distribudos de multimdia) e multicasting.

129

Com uma soluo ortogonal, algumas pesquisas tm proposto uma distribuio de servios para gerenciar a disperso de clientes, por exemplo, empregando um nmero de Servidores Centralizados de Multimdia para atender clientes localizados em certos pontos e os conectando atravs de uma infraestrutura de rede de alta velocidade, para serem capazes de compartilhar ou intercambiar objetos de sistemas multimdia. importante notar que embora atender os clientes localmente resulte numa reduo dramtica de consumo de banda, a menos que os servidores sejam capazes de compartilhar objetos na rede, o enorme requerimento de capacidade de

armazenamento agregado dos servidores faz a abordagem de no compartilhamento impraticvel. Sistemas projetados com base na abordagem de compartilhamento dos objetos tm-se mostrado uma soluo eficiente, com um custo mnimo de transferncia de objetos armazenados para aplicaes de multimdia distribuda. Esses sistemas tm como uma das principais premissas a topologia hierrquica contemplando servidores e clientes. Alm da topologia hierrquica, esperado que os links das redes garantam os requerimentos de QoS (Quality of Service) da comunicao de sistemas multimdia. Temos algumas alternativas de infraestrutura de telecomunicaes que podem prover esse tipo de servio, como redes de circuitos comutados como o SONET (Synchronous Digital NETwork) que prov conexes fsicas e/ou lgicas dedicadas, redes de comutao de pacotes que suportam servios especficos como por exemplo o DiffServ do TCP-IP, emulando as caractersticas de circuitos dedicados atravs de garantia da qualidade do servio por meio de mecanismos estatsticos ou determinsticos. Temos atualmente as redes MPLS (Multi-protocol Label Switching) que tambm j possuem suporte para sistemas multimdias. Os ns nas folhas no sistema hierrquico em rvore, chamados head-ends so pontos de acesso para o sistema. Na prtica, os clientes so conectados aos headends atravs de redes de banda larga como xDSL e rede a cabo. Quando uma requisio de qualquer objeto chega ao head-end, se o objeto est disponvel na armazenagem local o head-end atende o cliente, seno a requisio ser enviada para os nveis mais altos da hierarquia e eventualmente algum outro n que tenha armazenado localmente o objeto, atendendo ao cliente, transmitindo o fluxo multimdia atravs da topologia hierrquica, chegando ao head-end e finalmente no prprio cliente.

130

Como apresentado at o momento, um Servidor de Fluxo de Mdia Distribudo deve tambm consistir-se de um componente de middleware para gerenciamento de recursos. Supe-se que esse midleware deva enderear dois diferentes problemas ortogonais: Alocao de objeto. Mapeamento esttico ou dinmico de objetos em ns de rede de Servidores de Fluxo de Mdia Distribudo (espao de armazenamento) para o custo total da comunicao de itens armazenados seja otimizado. Entrega de objetos. Sobre a demanda dos clientes em tempo real, posicionando rplicas de objetos dentro de uma rede de Servidores de Fluxo de Mdia Distribudo, selecionando uma rplica apropriada e os recursos do sistema de fluxos de mdia adequadamente (por exemplo, n e largura de banda de um link) para a entrega de objetos, provendo uma eficiente utilizao de recursos. Podemos perceber que os provedores de VoD precisam buscar o equilbrio entre o posicionamento e capacidade dos Servidores de Fluxo de Mdia Distribudo e a velocidade dos links que conectam esses servidores entre si e entre os usurios finais. Provedores de VoD tm trabalhado em tcnicas de codificao, decodificao e compresso de vdeos mantendo ainda assim uma boa definio. Alm disso, eles possuem tcnicas de levantamento do perfil dos usurios, recomendando contedos que sero migrados para Servidores de Fluxo de Mdia Distribudo mais prximos de cada usurio, minimizando assim custos. Concluso do Captulo Encerramos com esse captulo a apresentao de elementos conceituais nos ajudaro a avaliar e compreender os modelos e tipos de clusters que iremos apresentar nos prximos captulos desse trabalho.

131

Captulo 2 Apresentao de Cluster em Linux na Modalidade HPC com nfase em Kerrighed Consideraes iniciais do captulo Apresentaremos nesse captulo os principais sistemas de cluster de alto desempenho em Linux na nossa viso, entrando num maior detalhamento quando abordarmos o sistema de cluster Kerrighed que ser foco do nosso laboratrio. Usaremos como comparao e contraponto ao cluster Kerrighed, o projeto OpenMosix que infelizmente foi encerrado por seu idealizador. Segue o motivo oficial do encerramento do projeto: O crescimento do poder e disponibilidade de processadores de multincleo de baixo custo est fazendo que rapidamente a clusterizao com SSI (Single System Image) diminua sua importncia na computao. A direo da computao clara e as desenvolvedoras chaves esto migrando para novas abordagens de virtualizao e outros projetos. Apesar de respeitarmos a opinio do criador do projeto, ainda achamos que plataformas como o OpenMosix ainda so viveis tcnica e economicamente, desde que implementadas de modo adequado, identificando, corrigindo e melhorando os sistemas como todo, sobretudo identificando os gargalos, verificando o

comportamento e medindo o desempenho ao executar os diversos tipos de aplicaes nesses ambientes. O projeto do OpenMosix, pelo menos, no que tange ao conceito de migrao de processos tem sido continuado atravs do projeto LinuxPMI, porm sem ter um envolvimento efetivo da comunidade acadmica e tecnolgica. Classificao de Michael J. Flynn 15 (FLYNN, 1972) das arquiteturas de Computadores Michael Flynn concebeu uma classificao de arquiteturas de computadores atravs de modelos, baseada no nmero de fluxos de dados e de instrues existentes em cada instante que em sua concepo so quatro:

15

Michael J. Flynn um cientista da computao dos Estados Unidos, professor emrito da Universidade de Stanford. Graduou-se em engenharia em 1955 pela Manhattan College e concluiu o mestrado cinco anos mais tarde, pela Universidade de Syracuse. Em 1961, concluiu o doutorado pela Universidade de Purdue. Props a taxonomia de Flynn em 1966, uma forma de classificao de arquiteturas de computador de acordo com instruo e fluxo de dado.

132

Arquitetura SISD (Single Instruction, Single Data): o modelo mais simples, onde o computador processa sequencialmente, executando uma instruo por vez para cada dado enviado. a arquitetura tradicional de Von Neuman. Arquitetura MISD (Multiple Instruction Single Data): o modelo em que os computadores executam vrias instrues ao mesmo tempo sobre um nico dado. No existe um computador real nesse modelo, pelo menos, atualmente. O prprio Michael Flynn duvidou pudesse existir algum modelo como esse no mundo real. Arquitetura SIMD (Single Instruction Multiple Data): o modelo que usa o paralelismo de dados, onde uma simples instruo executada paralelamente utilizando vrios dados. Essa tecnologia utilizada em alguns processadores, conhecida como MMX (MultiMedia eXtension) e tambm nos computadores vetoriais, computadores usados para efetuar operaes aritmticas sobre vetores e matrizes de ponto flutuante. Arquitetura MIMD (Multiple Instruction, Multiple Data): o modelo de execuo paralela onde cada processador trabalha de maneira independente, ocorrendo mltiplos fluxos de instrues e mltiplos dados. Esse o modelo utilizado nos clusters de computadores, utilizando a variao arquitetura MIMD com memria distribuda, que nesse caso seria vrios computadores com seu prprio processador e memria executando mltiplas instrues com mltiplos dados conectados atravs de uma rede local. Tipos de clusters Podemos dividi-los em dois grupos, cluster de Alta Disponibilidade e cluster de Alta Performance de computao. Cluster de Alta Disponibilidade: Como o prprio nome j indica, o objetivo manter o sistema o maior tempo possvel na operao sem paradas no programadas, replicando os servios e servidores. Quando algum servio ou equipamento paralisar, os outros passam a responder automaticamente. Enquanto um servidor de boa qualidade, inclusive com redundncia de discos rgidos, apresenta uma disponibilidade de 99,5%, um sistema de cluster de Alta disponibilidade apresenta 99,9%.

133

Esses quatro dcimos podem parecer no muito significativos primeira vista, mas para sistemas crticos so inestimveis. Alguns sistemas de alta disponibilidade em Linux com o cdigo fonte aberto so: LVS (Linux Virtual Server), Eddiware e o TurboLinux Cluster. Cluster de Alta Performance de Computao Esse modelo tem como foco desenvolver um sistema que tenha a mesmo poder de computao de um supercomputador, atravs do agrupamento de computadores numa rede de alta velocidade e softwares que agregam capacidade de memria e processamento desses computadores como se fosse apenas uma mquina, podendo assim executar aplicaes que s seriam suportadas por supercomputadores ou computadores de grande porte. Nosso trabalho trata de Clusters de Alta Performance de Computao, sendo assim apresentaremos com mais detalhes alguns modelos que se enquadra nessa classe de agrupamento de computadores.

Cluster Beowulf: O nome desse sistema vem de um dos mais antigos picos da lngua Inglesa, onde o protagonista um cavaleiro ingls, de grande fora e coragem, em sua luta contra o monstro de Grendel. Esse modelo de cluster foi concebido pela NASA com intuito de alcanar e avanar na capacidade de processamento massivamente paralelo (Massively Parallel Processing) MPP e aplic-los para resoluo de problemas computacionais, especialmente na aerocincia e no projeto ESS (Earth and Space Sciences) a um baixo custo. Em 1994 o primeiro Cluster Beowulf foi finalizado com uma capacidade de processamento de 70 megaflops, que so setenta milhes de operaes em ponto flutuantes por segundo. Ponto flutuante uma forma de representao mais apropriada para computadores de nmeros com muitas casas decimais.

134

Segundo Marcos Pitanga16 (PITANGA, 2002), para um cluster de PC's ser considerado um Beowulf, precisa atender s seguintes caractersticas: Nenhum componente feito por encomenda; Independncia de fornecedores de hardware e software; Perifricos escalveis; Software livre de cdigo aberto; Uso de ferramentas de computao distribuda disponveis livremente com alteraes mnimas; Retorno comunidade do projeto e melhorias; O Beowulf tem como vantagem ser escalvel, transparente ao hardware e sem nenhum custo em termos de software. Os elementos essenciais de um cluster Beowulf so: Os ns; O sistema operacional; A rede local; Os protocolos de rede local, no caso o TCP-IP; Os Clusters Middleware, que a entidade que permite que os ns trabalhem como um recurso integrado, fornecendo ao usurio uma interface como se estivesse trabalhando num computador individual. As ferramentas de comunicao que usam como recurso o PVM (Parallel Virtual Machine), que permite a execuo de programas paralelos em ambientes heterogneos assim como o MPI (Message Passing Interface) que permitem a programao, atravs de troca de mensagens. Essas ferramentas tambm incluem APIs (Application Programing Interface).

16

Marcos Pitanga possui mais de 23 anos de experincia em TI no Brasil e no exterior, com formao em Sistemas de Informaes, com ps-graduao em Redes de Computadores e Segurana de Redes. Docente em algumas universidades nas cadeiras de Redes de Computadores, Sistemas Operacionais e Sistemas Distribudos e Segurana de Redes.

135

Sistema de arquivos paralelo que so bibliotecas de interfaces que permitem visualizar os discos rgidos dos ns como se fosse um nico disco virtual. Segue um esquema lgico simplificado de um cluster Beowulf:

Figura 16 O n controlador do cluster funciona como uma interface de sada para o acesso externo outra rede, seja ela uma rede local ou a prpria Internet. Os usurios se conectam nessa mquina para acessar os recursos do cluster. Os ns escravos so os computadores onde as aplicaes sero executadas de modo paralelo, compartilhando assim os recursos de memria, processador e disco rgido. Um problema no modelo Beowulf que se o n controlador se danificar, perde-se toda a base de usurios, assim como o acesso aos ns escravos. Nesse caso recomendase uma redundncia de disco nesse computador assim como uma poltica consistente de backup.

136

Cluster OSCAR (Open Source Cluster Application Resources): O OSCAR foi criado e mantido pelo Open Cluster Group

(www.openclustergroup.org), um grupo informal dedicado a simplificar a instalao e o uso de clusters, ampliando o seu uso. Ao longo dos anos muitas empresas tm suportado o Open Cluster Group, incluindo Dell, IBM, Intel, NCSA and ORNL, dentre outras. Como o OSCAR desenvolvido como uma soluo completa de clusterizao h muitas reas funcionais que precisam ser cobertas pelos componentes do mesmo. Essas reas incluem instalao, ambiente de processamento paralelo, gerenciamento de carga de trabalho, segurana e administrao e manuteno em geral. Para satisfazer o requerimento de cada rea, os componentes do software includos no OSCAR foram selecionados atravs da investigao das prticas de muitas implementaes independentes de computao em cluster. O resultado foi uma coleo de softwares que representam, segundo a proposta dos desenvolvedores do OSCAR, as melhores prticas para criar-se um exitoso ambiente de cluster. O OSCAR trabalha com o conceito de um servidor ou head e ns como indicado na figura abaixo. O servidor dual homed, isto , ele tem duas interfaces de rede. A interface conectada a rede externa chamada public. A interface private conecta-se a rede do cluster. O OSCAR em sua instalao ativa um servidor DHCP (Dynamic Host Configuration Protocol) na interface private para fornecer endereamento IP automtico para os ns.

Figura 17

137

O pacote de instalao do OSCAR dividido em trs partes principais: o core cuja instalao mandatria, pacotes que so distribudos como parte do OSCAR, mas a instalao facultativa e os pacotes de desenvolvedores terceiros. Existem seis pacotes principais no OSCAR que precisam ser instalados: Core: o pacote principal do OSCAR. C3: o grupo de ferramentas para administrao em linha de comando do cluster, para comandos e controle. Environmental Switcher: baseado em mdulo, sendo um script em linguagem Perl que permite o usurio fazer mudanas para futuros ambientes shells. Oda: uma aplicao de base de dados central para o OSCAR. Perl-qt: a interface Perl orientada a objeto para o kit de ferramenta Qt GUI. SIS (System Installation Suite): utilizado para instalar o sistema operacional em clientes. Provavelmente a parte mais difcil na criao com sucesso de um ambiente em cluster seria a instalao inicial do software responsvel por fazer mquinas independentes trabalharem juntas com um nico recurso computacional. Incluso no pacote do OSCAR temos o LUI (Linux Utility for cluster Install), que um projeto de software livre desenvolvido pelo Centro de Tecnologia de Linux da IBM. A principal razo de o LUI ter sido escolhido como mecanismo de instalao do OSCAR foi que ele no requer que os ns clientes j tenham o Linux instalado, nem requer uma imagem em disco para o n cliente como outras tcnicas de instalao requerem. O LUI apresenta uma srie de qualidades, como um banco de dados que contm todas as informaes para um n instalar-se e configurar-se no cluster, a utilizao de RPM (Red Hat Package Manager) e sua caracterstica heterognea, podendo ser instalado em hardwares e softwares diferentes. Tratando do processamento paralelo, o OSCAR suporta o conceito de passagem de mensagem e prov as implementaes mais comuns a MPI (Message Passing Interface) e a PVM (Parallel Virtual Machine). Em meio s vrias verses de MPI disponveis, os desenvolvedores do OSCAR optaram pela MPICH (MPICHamaleon).

138

Projeto Rocks O projeto Rocks teve incio em novembro de 2000, pelo SDSC (San Diego Supercomputer Center) que disponibilizou uma primeira verso conhecida como NPACI Rocks Cluster, que era um conjunto de ferramentas baseadas em Red Hat visando construo e administrao de maneira rpida e prtica de clusters para a comunidade cientfica. Apesar de havermos apresentado brevemente o conceito de grid na introduo desse trabalho, como o Rocks tem uma aplicao tambm em sistemas em grid, vale elucidar um pouco mais o tema, apesar de o mesmo no ser o foco desse trabalho. A computao em grid uma combinao de recursos computacionais de domnios administrativos mltiplos aplicados para uma tarefa comum, usualmente para soluo de problemas de natureza cientfica, tcnica ou corporativa que requer um grande nmero ciclos de processamento de computador ou necessite processar uma grande quantidade de dados. Uma das principais estratgias da computao em grid utilizar softwares para dividir e aportar partes de programas em muitos computadores e formar uma rede de processamento paralelo e distribudo. O tamanho de um grid pode variar de muito pequeno, confinado a uma rede de computadores dentro de uma corporao, por exemplo, ou muito grande, atravs de uma colaborao pblica entre muitas companhias e redes, usualmente utilizando a Internet como meio de comunicao. Dizemos que os sistemas em grid seria um cluster com computadores fracamente acoplados em termos de conexo de rede, pois no so recursos dedicados completamente formao desse computador virtual como no caso dos clusters convencionais em que os componentes so considerados fortemente acoplados. O que tambm distingue a computao em grid dos clusters convencionais seria a heterogeneidade de seus componentes assim como a disperso geogrfica dos mesmos. Retornando aos conceitos do Rocks, um cluster com essa tecnologia tem a mesma arquitetura bsica do OSCAR. O n head tambm conhecido como front end um servidor com duas interfaces de rede como ilustrado na Figura 17.

139

O cluster Rocks tem os seguintes elementos principais: Controlador de dispositivos HPC (High Performance Computing); Monitoramento e Gerenciamento do estado do cluster; Gerenciamento do software do cluster; Camada de comunicao e passagem de mensagem; Aplicaes para ambiente em cluster (Cdigos Paralelos, Grid, etc); O Rocks cluster completamente baseado em distribuio Linux Red Hat com pacotes adicionais e configurao programada para automatizar a implementao de um cluster Linux de alto desempenho. Escolha da distribuio Linux Red Hat, segundo os desenvolvedores, teve como motivo principal a existncia de dois mecanismos chaves, a saber: o software de manipulao de pacotes RPM e sua ferramenta baseada em script para instalao, especialmente dos ns da soluo (kickstart). Segundo os desenvolvedores, apesar do Rocks ter um foco num sistema rpido e flexvel de configurao e reconfigurao, o comportamento estvel do Rocks faz dele uma soluo de cluster de mercado como Beowulf e o prprio OSCAR. Uma das premissas do desenvolvimento do Rocks foi criar um software de instalao, gerenciamento e monitoramento facilitado mesmo para clusters de grande porte, tornando acessveis essas atividades mesmo para no especialistas. O mesmo possui um kit de ferramentas baseado na distribuio Red Hat, utilizando recursos de muitos projetos populares de grids e clusters. Adicionalmente, o Rocks permite que usurios finais adicionem seus prprios softwares atravs de um mecanismo chamado Rolls. Rolls que uma coleo de pacotes e detalhes de configurao que podem ser modularmente acrescidos na base de distribuio do Rocks.

140

Cluster OpenMosix O projeto Mosix (Multicomputer Operating System UnIX), um sistema operacional distribudo desenvolvido na Universidade Hebrew em Jerusalm, Israel. Sendo utilizado nos anos 80 pela Fora Area Americana, chegando numa verso final desse projeto em 1997 utilizando plataforma Intel e sistema operacional GNU/Linux. O cdigo do mesmo est disponvel em www.mosix.org, gratuitamente apenas para instituies acadmicas. O OpenMosix um extenso do projeto Mosix, baseado em licena de software livre GPLv2 (hoje j temos a GPLv3), iniciando em 10 de fevereiro de 2002, sob coordenao do Ph.D Moshe Bar, visando manter essa soluo de cluster como cdigo aberto, devido divergncias com a Universidade de Hebrew quanto a questo de direitos autorais. Durante a sua vigncia o OpenMosix teve o apoio tcnico e financeiro de muitas instituies privadas e pblicas. Tendo como principal desenvolvedor o Dr. Moshe Bar, teve tambm ampla colaborao da comunidade acadmica, destacando como membros do projeto, Dr. Maurizio Davini17, Dr. David Santo Orcero18, dentre outros. O OpenMosix uma extenso de kernel criando um sistema de cluster de imagem nica, sendo uma ferramenta para sistemas com kernel baseado em plataforma Unix, como o Linux, constituindo um algoritmo adaptativo de compartilhamento de recursos. Ele permite que mltiplas estaes monoprocessadas e mesmo multiprocessadas simetricamente executem o mesmo kernel, podendo trabalhar numa significativa cooperao. Isso alcanado atravs da migrao de processos de um n para outro de modo preemptivo e transparente, para balanceamento de carga e preveno de trashing em processos de paginao de memria. O objetivo seria o melhor desempenho de modo geral num sistema de cluster e a criao de um ambiente multiusurio e time-sharing para a execuo de aplicaes sequenciais e paralelas.

17 18

Consultor da equipe Ferrari de corridas e chefe do Departamento de Fsica da Universidade de Pisa. Consultor e professor da Universidade de Mlaga.

141

Assim o OpenMosix um sistema de cluster onde todos os recursos esto disponveis em todos os ns que o compe, podendo ser constitudo de computadores de baixa capacidade de processamento e em redes convencionais, mas tambm podendo ser utilizado em ambientes com servidores de alta performance e em redes de alta velocidade e baixa latncia. A granularidade no OpenMosix determinada pela migrao dos processos. Programas individuais podem criar processo ou processos que podem ser gerados atravs de mltiplos forks de um nico programa. Entretanto, se temos uma tarefa intensiva em termos computacionais que executada num simples processo, utilizando-se mltiplas threads, desde que no exista no prprio computador outro processador para compartilhar essa carga, esse processo seria elegvel para ser migrado para outro n do cluster. Naturalmente nem todos os processos so migrados num cluster OpenMosix. Por exemplo, se um processo dura poucos segundos, ele no ter tempo nem necessidade de ser migrado. Da mesma forma, mltiplos processos utilizando memria compartilhada, tais como servidores WEB, no so adequados para serem migrados, pois o OpenMosix no tem um sistema memria distribuda eficiente. Processos que atuam na manipulao direta de dispositivos de E/S tambm no migrados, porque o OpenMosix no possui um mecanismo de migrao baseado em sockets. Similarmente os processos que utilizam escalonamento em tempo real tambm no seriam a princpio migrados. Existe uma proposta de pesquisadores da Syracuse University (OH, 2005), que utiliza uma combinao do Resource Kernel do Linux e do Mosix para executar tarefas em tempo real, podendo assim ser entendida para o OpenMosix. Podemos ver que apesar de ser uma soluo elegante, especialmente no que diz respeito a no necessitar de um n controlador, como no cluster Beowulf, que sempre ser um ponto nico de falha e de gargalo, o OpenMosix tem suas limitaes e desvantagens. Assim ao utilizar essa plataforma h necessidade de escolher as aplicaes compatveis com a mesma. Seguem algumas diretrizes para um uso eficiente do OpenMosix.

142

Aplicaes que tm um bom desempenho com o OpenMosix: Processos CPU-bound. Processos com longo tempo de execuo e baixa utilizao dos recursos de rede, por exemplo, aplicaes cientficas, matemticas, de engenharia, etc. Compilaes extensas. Processos com moderada comunicao interprocessos. Processos de uso intenso de E/S em disco, utilizando o sistema de arquivos distribudos do OpenMosix. Bancos de dados que no utilizam memria compartilhada. Processos que podem ser migrados manualmente. Tecnologia do OpenMosix O OpenMosix constitudo de duas partes: o mecanismo PPM (Preempetive Process Migration) e um grupo de algoritmos para compartilhamento adaptativo de recursos. Ambas as partes so implementadas em nvel de kernel, utilizando mdulos carregveis (via RPM ou compilao direta do kernel), de tal forma que a interface do Sistema Operacional permanece inalterada, sendo completamente transparente em nvel de aplicao. O PPM pode migrar qualquer processo, a qualquer momento, para qualquer n disponvel. Usualmente as migraes so baseadas em informaes providas por algum dos algoritmos de compartilhamento de recursos, mas os usurios podem sobrepor qualquer sistema automtico de deciso e migrar seus processos manualmente. Cada processo tem um UHN (Unique Home-Node) gerado onde ele foi criado. Normalmente esse o n no qual o usurio executou o login. O modelo de imagem de sistema nico do OpenMosix coerente quanto ao cache, no qual cada processo aparenta estar sendo executado no seu prprio UHN e todos os processos de uma sesso de usurio compartilham o ambiente de execuo do UHN. Processos que migram para outro n usam os recursos locais (do n remoto) sempre que possvel, mas interagem com o ambiente do usurio atravs do UHN.

143

O PPM a principal ferramenta para os algoritmos de gerenciamento de recursos. Enquanto o requerimento de recursos, tais como utilizao de CPU e memria principal estiver abaixo de certos limites, os processos do usurio estaro confinados ao UHN. Quando os requerimentos de recursos excederem os nveis estabelecidos, ento algum processo pode ser migrado para algum outro n. O principal objetivo maximizar o desempenho atravs de uma utilizao eficiente dos recursos disponveis na rede. O OpenMosix no tem um controle central no modelo mestre/escravo. Cada n opera como um sistema autnomo, tomando as decises de controle baseado nos algoritmos de controle de recurso que so executados no mesmo. Esse cenrio permite a entrada e sada de ns com o mnimo impacto para o funcionamento do cluster como um todo. Essas funcionalidades permitem o sistema ser flexvel no que tange escalabilidade, operando com eficincia em pequenas e grandes instalaes. Essa escalabilidade alcanada porque a deciso de um n em migrar um dado processo baseia-se num conhecimento parcial sobre o estado dos outros ns, tendo assim uma natureza probabilstica. Algoritmos de Compartilhamento de Recursos Os principais algoritmos de compartilhamento de recursos do OpenMosix seria o balanceamento de carga e o uso de memria. O algoritmo dinmico de balanceamento procura continuamente reduzir a diferena de carga entre os ns. O nmero de processadores e sua velocidade um importante fator nas decises tomadas por esse algoritmo. Ele operar adequadamente at haver recursos disponveis no cluster como um todo. O algoritmo de uso memria atua na preveno do esgotamento na mesma, sendo projetado para alocar um nmero mximo de processos no agregado de memria RAM do sistema, evitando trashing e/ou excessivos swapping de processos. O algoritmo ativado quando se percebe que um n comea a ter excessivas paginaes devido ao esgotamento da memria, nesse caso o algoritmo de controle de memria, sobrepe-se ao algoritmo de balanceamento de carga e faz uma tentativa de migrar algum processo para um n com memria RAM disponvel.

144

Migrao de Processos O OpenMosix possui um processo preemptivo e completamente transparente de migrao de processos atravs do PPM. Depois da migrao, o processo continua interagir com seu ambiente de origem independente de sua localizao. Para a implementao do PPM, o processo de migrao dividido em dois contextos: contexto do usurio, que pode ser migrado e o contexto do sistema, que dependente do UHN e no pode ser migrado. O contexto do usurio, conhecido como remote contm o cdigo do programa, a pilha, os dados, o mapeamento de memria e o estado dos registradores do processo. O remote encapsula o processo quando o mesmo est sendo executado em nvel de usurio. O contexto do sistema, conhecido como deputy encapsula o processo quando ele est sendo executado em modo kernel. O deputy contm a descrio dos recursos que esto associados ao processo e a pilha do kernel para a execuo do cdigo do sistema referente ao mesmo. Ele mantm parte local do processo no contexto do sistema, permanecendo no UHN. O deputy nunca migrado. A interface entre o contexto do usurio e o contexto do sistema muito bem definida. Portanto possvel interceptar toda a interao entre os contextos e encaminhar essa interao atravs da rede. Essa implementao feita via camada de enlace sob o ponto de vista do modelo ISO/OSI. O tempo de migrao tem um componente fixo para estabelecer uma instncia do novo processo no n remoto, sendo um componente linear, ele proporcional ao nmero de pgina de memria a serem transferidas. Para minimizar o overhead da migrao apenas as tabelas das pginas e as pginas sujas (pginas de retiradas da memria fsica, mas que foram modificadas e precisam ser armazenadas no arquivo swap) so transferidas. Na execuo de um processo no OpenMosix, a transparncia de localizao alcanada pelo encaminhamento das chamadas de sistemas dependentes do kernel para o deputy no UHN. As chamadas de sistema so interaes sncronas entre dois contextos de processos.

145

Acesso a arquivos: O OpenMosix tem seu prprio sistema de arquivo para cluster em Linux que d uma viso na perspectiva de cluster de todos os sistemas de arquivos que o compe. O OpenMosix usa o DFSA (Direct File System Access). O DFSA foi projetado para reduzir o overhead para se executar chamadas de sistemas orientadas a E/S de processos migrados. Ele basicamente faz isso, migrando os processos para os computadores que tem uma maior demanda de E/S de disco, diferentemente de outros sistemas de arquivos distribudos como, como por exemplo, o NFS. Sistemas de Arquivos Para suportar o DFSA foi desenvolvido o oMFS (open Mosix File System) que prov uma sistema nico de localizao de arquivos, considerando o sistema de arquivos de cada n do cluster. A consistncia de cache obtida atravs da manuteno de um nico servidor de cache tendo os outros ns como clientes que apenas repassam as requisies de acesso ao cache desse servidor. A principal vantagem dessa abordagem seria a escalabilidade na consistncia de cache mesmo para um nmero significativo de processos. Infelizmente o oMFS foi retirado dos ltimos pacotes liberados pelo OpenMosix, segundo os desenvolvedores por questes de segurana. Mecanismos do Deputy e do Remote O deputy o representante do processo remote no UHN. Devido a todo espao de memria de usurio residir no n remoto, o deputy no possui nenhum mapeamento de memria prprio. Ao invs disso, ele compartilha o mapeamento principal do kernel de modo similar a uma thread. Em muitas atividades de kernel, tais como chamadas de sistema, necessria a transferncia de dados do espao do usurio para o kernel. No OpenMosix, qualquer operao de memria do kernel que envolva o acesso ao espao do usurio requer que o deputy se comunique com o remote para transferir-se os dados necessrios. Para minimizar o overhead de cpias de dados na comunicao entre contextos, um cache especial implementado visando a diminuio de cpias remotas, mantendo a quantidade de dados possvel no deputy em buffer no incio da chamada de sistema para serem enviados apenas no final da mesma.

146

Coleta de Informaes Estatsticas sobre o comportamento dos processos so coletadas regularmente, tais como todas chamadas de sistemas e todo o tempo em que o processo acessa dados de usurio. Essa informao utilizada para avaliar se o processo precisa ser migrado do UHN. Essa estatstica alterada no tempo, ajustando-se a processos que alteram seu perfil de execuo. API do OpenMosix: A API do OpenMosix foi originalmente implementada atravs de um grupo reservado de chamadas de sistemas que eram usadas para configurar, pesquisar e operar o OpenMosix. Seguindo a conveno atual do Linux, a API foi modificada para fazer interface com sistema de arquivo /proc. Isso evita possveis incompatibilidades de programas de usurios entre diferentes verses de Linux. A API foi implementada atravs da extenso da rvore do sistema de arquivo /proc com um novo diretrio: /proc/openMosix. As chamadas para o OpenMosix via /proc incluem: requisies de migrao sncronas e assncronas, lock de um processo contra migraes automticas; verificao de onde os processos esto correntemente sendo executados, identificao de restries para migraes, administrao do sistema, controle da coleta de estatsticas e informao sobre processos remotos. Segurana no OpenMosix: Devido a sua arquitetura e modus operandi, o OpenMosix possui algumas questes de segurana inerentes a plataforma, como por exemplo, a relao de confiana entre os ns do cluster, a necessidade de comunicao entre todos os ns de forma praticamente permanente, a facilidade de um invasor editar o mapeamento dos ns do cluster no arquivo openmosix.map e a prpria aplicao de descoberta automtica de ns omdiscd que trabalha com multicast, fazem o OpenMosix frgil nos limites que seus desenvolvedores chamam de parte interna (inside) do cluster. O prprio Dr. Moshe afirma que as polticas de segurana deveriam ser aplicadas no permetro do cluster e no dentro no mesmo, ao responder um questionamento sobre a vulnerabilidade do sistema a ataques de DoS (Denial of Service).

147

Tratando de mitigaes, existem algumas distribuies do OpenMosix como o CHAOS que substitui a aplicao em multicast do omdiscd pela aplicao tyd que trabalha com unicast como um gatekeeper num ambiente VoIP ou mesmo um servidor WINS da plataforma Microsoft. O tyd em si no implementa qualquer funcionalidade de segurana, mas como ele trabalha com pacotes unicast, o mesmo prov um ambiente mais acessvel para aplicar tecnologia como IPSec possibilitando a criao de VPNs entre os ns. Tendo apresentado uma soluo de contorno para prover certo nvel de segurana entre os ns do cluster, mesmo que ainda no completo, pois o tyd no possui nenhum dispositivo de autenticao, precisamos tambm analisar a questo da rede inside e a rede outside. Como j visto a rede inside a rede que prov a comunicao entre os ns que usualmente trabalha com as portas UDP 5000-5700 e TCP 723 e 4660. A rede outside a rede conectada ao mundo externo seja uma rede local onde o cluster estaria conectado, seja uma conexo direta com a Internet. Via de regra, o trfico inside no deve ser acessado pela rede outside sem um mnimo nvel de segurana. A soluo para manter essa separao lgica, seria colocar uma segunda interface de rede num dos ns do cluster conectado na rede outside, ativando a funcionalidade de firewall (Netfilter) no mesmo, para que atravs de filtros, o trfego interno no seja acessado externamente. Essa soluo no seria a mais adequada pois traria para o OpenMosix a mesma inconvenincia dos modelos de cluster com um n controlador, ou seja um ponto nico de falha e de gargalo. Solues mais elaboradas podem ser utilizadas colocando um firewall entre as duas redes que seriam confinadas atravs de VLAN (Virtual Local Area Network).

148

Iniciativas de melhorias do OpenMosix Durante seu ciclo de vida, o OpenMosix teve algumas iniciativas isoladas de melhorias visando, seja aprimorar funcionalidades, seja prover solues para deficincias intrnsecas do sistema. Podemos citar o grupo, na ocasio de estudantes da Universidade de Puna, ndia, Maya, Anu, Asmita, Snehal and Krushna (MAASK, 2003) que desenvolveram o MigShm um kernel patch ao OpenMosix visando otimizar a funcionalidades de memria compartilhada do mesmo. Uma das limitaes do OpenMosix executar aplicaes que utilizam memria compartilhada e multi-threads, pois elas no conseguem ser migradas, no podendo assim ser beneficiadas pela principal caracterstica do OpenMosix que a migrao de processos. O MigShm tem como pretenso realizar a migrao de memria compartilhada. Ele no exatamente um completo DSM (Distributed Shared Memory), mas suficiente para enderear algumas situaes de memria compartilhada no OpenMosix. Para o desenvolvimento do Migshm foi necessrio a criao de algumas chamadas de sistemas tais como shmget(), shmat(), shmdt() e shmctl(). Cada uma dessas funes disponibilizada transparentemente no remote e quando da necessidade da migrao de processos com memria compartilhada, essas chamadas acessam o mapeamento local de memria. Um mdulo de comunicao necessrio para obter-se uma comunicao entre o deputy e o remote para as tratativas do Migshm. O MAASK utilizou o Commlink para esse propsito, entretanto para garantir a comunicao entre dois processos em ns diferentes, elas tambm implementaram um daemon em cada n do OpenMosix chamado MigSharedMemD, que utiliza o port TCP 3418.

149

Diferentes processos utilizando mesma regio compartilhada podem migrar para diferentes ns, onde eles trabalham com cpias locais dessa memria compartilhada. A consistncia mantida entre as diferentes instncias cpias locais, atravs do modelo de consistncia Eager Release, que implementa um mecanismo onde cpias locais de pginas modificadas sero apenas escritas no processo que as originou quando o lock desse segmento de memria for liberado e no para qualquer escrita. Isso garante que o n originador da memria compartilhada sempre ter a cpia mais atual da mesma. Travis Frisinger do departamento de Cincia da Computao da Universidade de Wisconsin-Eau Claire que no seu artigo A Modification of OpenMosixs Process Migration prope um controle maior no processo de migrao OpenMosix, pois cada canal criado para esse fim consome uma quantidade significativa de recursos. Sua proposta seria reutilizar o canal para migrar mais de um processo por vez, economizando assim os recursos dos ns de um cluster OpenMosix. Apesar do ganho em desempenho, ser relativamente pequeno por n, em torno de 2%, segundo o autor, o mesmo ser mais significativo em clusters com uma quantidade significativa de computadores na ordem de centenas.

150

Cluster Kerrighed O cluster Kerrighed tem muitas similaridades com o OpenMosix, especialmente no que tange a ser um cluster de imagem nica (SSI) e tambm por trabalhar com a migrao de processos. Porm o cluster Kerrighed avanou em algumas funcionalidades as quais so ineficientes ou inexistentes no OpenMosix, como por exemplo, um compartilhamento de memria eficaz e a migrao de threads. O principal objetivo Kerrighed prover servios de alto nvel na execuo de aplicaes sequenciais e paralelas num sistema de cluster. No Kerrighed todos os recursos de cada n que o compe (processadores, memria, discos, etc) so globais e dinamicamente gerenciados. O gerenciamento global de recursos habilita uma distribuio transparente dos mesmos entre os ns e um uso adequado dos recursos do cluster como um todo, por aplicaes que os demandem. O gerenciamento dinmico dos recursos habilita uma reconfigurao transparente do cluster (adio e retirada de ns), causando nenhum impacto na execuo das aplicaes, mesmo em eventos de falha de algum n do cluster (Alta Disponibilidade). Em adio, um mecanismo de checkpointing provido para evitar a reinicializaro de aplicaes (pelo menos desde seu incio) quando uma falha de um n ocorre. O Kerrighed implementado como uma extenso de um sistema operacional padro em cada n, baseado em Linux kernel. No Kerrighed, processos e threads podem iniciar sua execuo em qualquer n, podendo ser migrados durante sua execuo. Mecanismos eficientes de

gerenciamento de processos so implementados no Kerrighed para prover um escalonamento global. O gerenciamento global de memria no Kerrighed baseia-se no conceito de container. Baseando-se em containers, os servios de alto nvel de um sistema operacional padro podem ser executados elegantemente de modo a prover segmentos de memria virtual, arquivo de cache corporativo, paginao remota e uma forma eficiente de se transferir o espao de memria de processos migrados. A camada de comunicao do Kerrighed baseada no novo conceito de Fluxos Dinmicos (Dynamic Streams), implementando o padro de interface em camadas que suportado pela maioria das aplicaes, provendo uma comunicao eficiente na migrao de processos.

151

Do ponto de vista dos desenvolvedores do Kerrighed, um SSI deve possuir quatro propriedades, a saber, distribuio transparente de recursos, oferecendo a iluso que todo recurso nico e compartilhado, alta desempenho, alta disponibilidade e escalabilidade. Segundo seus desenvolvedores essas propriedades existem no Kerrighed por meio de um gerenciamento global e dinmico de recursos. A principal vantagem da abordagem do Kerrighed a interface padro que cada n que o compe possui, interface essa familiar aos desenvolvedores de aplicaes. Assim aplicaes j existentes que so executadas em sistemas operacionais tradicionais, so migradas para o Kerrighed sem nenhuma modificao, podendo posteriormente ser otimizadas para usufrurem melhor das funcionalidades do cluster. O Kerrighed no um sistema operacional desenvolvido totalmente do incio, mas de fato, ele implementado como uma extenso do sistema operacional tradicional existente. O Kerrighed apenas atua nas atividades de natureza distribuda prprias do sistema de cluster, deixando para cada n a tarefa de gerenciar os recursos locais. Gerenciamento Global de Processos Caractersticas principais: Um processo que manipulado pelo Kerrighed passa a chamar-se de K-process. Todo o espao de memria utilizado por K-process est ligado aos containers. Esses K-process so migrados dentro do cluster para um melhor aproveitamento dos recursos e para igualizar a carga de trabalho entre os ns que compe o mesmo. Essa igualdade da carga de trabalho obtida atravs de uma escolha cuidadosa em qual n cada processo deve ser executado. A poltica de escalonamento do Kerrighed define como os processos so mapeados entre os ns, baseando esse mapeamento em alguns objetivos a serem alcanados como, por exemplo, balanceamento entre as CPUs. Ele tambm utiliza como parmetros a serem considerados nessa poltica, o uso de CPU por processo e o estado de cada n como, por exemplo, o nmero de processos que esto sendo executados em cada um deles. Assim o papel da poltica global de escalonamento manter o cluster num estado de equilbrio no que tange ao uso dos recursos, criando processos de maneira criteriosa ou migrando-os quando ocorrer algum desvio.

152

Mas, alm disso, um scheduler num cluster necessita ter a possibilidade de ser passvel de configurao quando ocorrer algum cenrio em termos de utilizao processamento ou de recursos no contemplados pela poltica de escalonamento do cluster ou que para o qual os algoritmos de escalonamento no conseguem prover resultados adequados. A poltica de escalonamento do Kerrighed pode ser facilmente alterada pelo administrador do mesmo, se necessrio. O scheduler do Kerrighed baseia-se num conjunto de mecanismos eficientes de gerenciamento de processos. Criao remota de processos e threads, migrao de processos e threads so usadas para diminuir a conteno de recursos locais assim como evitar a execuo de aplicaes em ns que necessitam ser desativados (para manuteno, por exemplo). O processo de checkpointing ajuda a diminuir a conteno global nos recursos por colocar em suspenso algumas aplicaes. Esses mecanismos so todos baseados nas funcionalidades e estados dos processos que so executados no sistema operacional local. Num sistema padro Linux, processos e threads podem ser criados usando interfaces fork e execv. Na interface padro de threads no Posix, permitida a criao e o gerenciamento das mesmas em aplicaes de memria compartilhada. No Kerrighed, esses mecanismos so ampliados atravs dos mecanismos de gerenciamento de processos para que aplicaes legadas desenvolvidas para computadores SMP (Symmetric Multiprocessing) possam obter vantagens na utilizao de clusters. Escalonamento Global altervel e modular: O Kerrighed prope um escalonamento global modular, composto de trs camadas: Probes do Sistema para coleta de informaes do mesmo, provendo assim uma viso do estado do cluster; Analisadores locais para detectar todos os problemas locais de escalonamento tais como alta conteno de recursos e falhas em dispositivos; Gerenciador global de escalonamento para ativar novos processos e resolver problemas de escalonamento; Essa arquitetura modular permite interagir separadamente com diferentes aspectos do escalonamento global, e assim facilitar modificaes na suas polticas.

153

Probes do Sistema, medindo, por exemplo, o uso de CPU ou memria constituem-se na primeira camada. Existem dois tipos de probes, passivas e ativas. Cada probe pode ser ligada a um grupo de analisadores locais, para os quais ela envia informao. Probes ativas so regularmente acionadas por um temporizador do sistema, enquanto probes passivas so acionadas por um evento do sistema. Existem dois diferentes eventos do sistema: eventos do kernel do Linux e eventos do scheduler global, esse ltimo coleta informaes locais. Quando uma probe passiva acionada por um evento do sistema, a probe envia a informao coletada para o analisador local com o qual ela est ligada. Por exemplo, uma probe ativa pode ser usada para verificar a utilizao de CPU (a CPU periodicamente verificada), enquanto que se utiliza uma probe passiva para detectar um ping-pong de pginas de memria entre duas threads de uma aplicao de memria compartilhada (quando uma pgina chega ao n, a probe acionada). O Kerrighed prov um conjunto de probes na sua implementao, podendo novas probes ser desenvolvidas por programadores de sistemas operacionais. Analisadores locais recebem as informaes das probes, as analisa e filtra, detectando algum estado anormal do sistema local. Essa camada tambm tem a funo de enviar as informaes das probes para gerenciador global de escalonamento. Um grupo de analisadores locais executado em cada n. Cada analisador local pode estar ligado a um conjunto de probes. Por exemplo, podemos ter uma probe para o consumo de CPU e outra para a temperatura da mesma. O analisador local ligado a essas duas probes pode detectar uma alta conteno local de CPU, assim como problemas locais de temperatura. Se um problema de CPU detectado, o analisador local envia uma requisio para o gerenciador global de escalonamento (o analisador local no tem uma viso geral do estado do cluster e, portanto, no pode tomar uma deciso nesse nvel).

154

Um gerenciador global de escalonamento executado em cada n, sendo ligado a um grupo de analisadores locais. Os gerenciadores globais de escalonamento executados em diferentes ns comunicam-se entre si para trocar informao do estado de cada n que compe o cluster. Essa camada a nica que tem uma viso global do mesmo. Essa viso global construda com as informaes das probes (por exemplo, probes de CPU), habilitando a deteco global de problemas de escalonamento. Para esse fim, cada gerenciador global de escalonamento implementa uma poltica global de escalonamento ( por exemplo, o balanceamento de CPU). Quando um problema de escalonamento detectado (por exemplo, CPUs locais com mais carga do que a mdia do cluster), o gerenciador global de escalonamento pode decidir migrar alguns processos ou acionar um checkpointing para alguma aplicao, de acordo com a poltica de escalonamento, a fim de obter um uso eficiente dos recursos do cluster. Essas trs camadas que compe o escalonamento global modular do Kerrighed podem ser configuradas usando arquivos XML. Diferentes probes, 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 aplicaes. Alm disso, cada camada prov uma estrutura de desenvolvimento para facilitar a programao de novos componentes, permitindo, de maneira simples, a criao de novas polticas de escalonamento global. Finalmente, o scheduler do kernel do Linux no modificado. O Kerrighed apenas adiciona ou remove processos no scheduler local.

155

Gerenciamento do estado dos processos Os schedulers do Kerrighed so baseados em trs mecanismos: estabelecimento, migrao e check-point/restart de processos. Para o estabelecimento, o Kerrighed prov dois mecanismos: criao remota de processos e duplicao remota de processos. A criao remota de processos utiliza uma interface dedicada semanticamente equivalente a um fork(), imediatamente seguido por um execv() no processo filho. A duplicao de processos utilizada na execuo de aplicaes quando um novo processo (usando fork) ou threads (usando pthread create) so criados, necessitando herdar o contexto da aplicao. Para estabelecer um novo processo, o sistema necessita extrair uma imagem do processo criador e transferi-lo para um n remoto, criando um clone que ser executado no mesmo. Similarmente para uma migrao remota de processo, essa migrao precisa extrair uma imagem do processo e transferi-la para o n remoto, criando um clone do mesmo, mas o processo original finalizado. O checkpointing de processo tambm necessita extrair uma imagem do mesmo e armazen-la no disco ou numa memria remota. A criao, duplicao e checkpoint/restart de um processo Kerrighed utilizam o mesmo mecanismo fundamental de extrao de processo. A extrao de um processo consiste na criao de um processo ghost (virtualizao de processo) composto dos seguintes componentes: espao de endereamento, arquivos abertos, Identificador de Processo (PID), registradores do processador e os prprios dados. Gerenciamento de espao de endereamento e arquivos abertos: De modo similar a um kernel padro do Linux, que necessita extrair todas as informaes de memria e arquivos abertos a fim de criar um processo ghost coerente, no Kerrighed o espao de endereamento e os arquivos abertos de um Kprocess so globalmente gerenciados. O espao de memria e arquivos

convencionais abertos so tratados pelos containers e os arquivos de stream por mecanismos de dynamic streams (fluxos dinmicos). Atravs dos containers tanto arquivos abertos como pginas de memria podem ser acessados por qualquer n do cluster, que viabiliza consideravelmente a migrao de processos.

156

Gerenciamento do Identificador de Processo (PID): No Linux padro as threads so implementadas por processos utilizando a biblioteca pthread. Ento, os processos so identificados por um Process Identifier (PID). As threads so distinguidas por identificadores internos na biblioteca pthread. O Kerrighed adiciona uma camada ao sistema. Para cada processo designado um Kerrighed Process Identifier (KPID), como o seu PID. Em nvel de kernel, o PID usado, enquanto que em nvel de usurio, apenas o KPID visualizado. Dessa forma um nico KPID designado para um processo em todo cluster. Para garantir a unicidade, um KPID composto do PID original e o identificador do n corrente. A biblioteca de thread do Kerrighed gerencia o identificador adicional de thread.

Gerenciamento Global de Memria O gerenciamento global de memria num cluster abrange muitos servios. Primeiro, a fim de suportar a execuo de aplicaes multi-thread e modelos usuais de programao em ambiente de memria compartilhada, um sistema de DSM (Distributed Shared Memory) necessrio, permitindo que processos e threads compartilhem segmentos de dados em qualquer n do cluster. Segundo, muito desejvel num cluster explorar a memria que est distribuda entre os ns, para aumentar a eficincia dos servios do sistema operacional. Existem duas reas chaves no gerenciamento de memria num cluster, um mecanismo remoto de paginao e um mecanismo cooperativo de arquivos de cache. Num sistema de DSM, os sistemas de paginao de memria e de arquivos de cache cooperativos baseiam-se em mecanismos comuns: localizar a cpia de uma pgina de memria no cluster, transferir pginas entre ns e gerenciar a coerncia de cpias de pginas replicadas. O Kerrighed implementa o conceito de container como um nico mecanismo para gerenciar globalmente as memrias fsicas do cluster. Todos os servios do sistema operacional que utilizam pginas de memria acessam a memria fsica atravs de containers.

157

Containers Num cluster, cada n executa o seu prprio kernel do sistema operacional, o qual pode ser dividido de modo grosseiro em duas partes: servios de sistema e gerenciadores de dispositivos. O Kerrighed prope um servio genrico inserido entre os servios de sistema e os gerenciadores de servios chamados de containers. Os containers so integrados ao kernel graas aos linkers que so partes de software inseridas entre os gerenciadores de dispositivos existentes, os servios de sistema e os containers. A ideia principal do container que ele d a iluso aos servios de sistemas que a memria fsica compartilhada como um computador SMP (Symmetric Multiprocessing). Um container um objeto que permite que o armazenamento e compartilhamento de dados em toda extenso do cluster. Ele atua em nvel de kernel, sendo completamente transparente em nvel de software de usurio. Os dados armazenados num container podem ser compartilhados e acessados pelo kernel de qualquer n do cluster. As pginas de um container podem ser mapeadas num espao de endereo de um processo, podendo assim ser utilizadas como entrada de arquivo de cache, dentre outras aplicaes. Por integrar esse mecanismo genrico de compartilhamento dentro do sistema, possvel dar a iluso para o kernel que ele est manipulando uma memria fsica. Sobre essa memria virtual compartilhada possvel estender ao cluster os servios tradicionais oferecidos por um sistema operacional padro. Isso permite manter a interface do sistema operacional j conhecida pelos usurios, tirando vantagem do gerenciamento de recursos locais de baixo nvel. O modelo oferecido pelos containers sequencialmente consistente, implementado com um protocolo write-invalidate. Linkers Muitos mecanismos num kernel apoiam-se no manuseio de pginas fsicas. Os linkers desviam esses mecanismos para garantir o compartilhamento atravs dos containers. Para cada container so associados um ou mais linkers de alto nvel chamados linkers de interface e linkers de baixo nvel chamados linkers de input/output. A funo do linker de interface desviar o acesso aos dispositivos de servios do sistema para os containers enquanto um linker de E/S permite o acesso a um gerenciador de dispositivo.

158

Os servios de sistemas so conectados aos containers graas aos linkers de interface. Um linker de interface muda a interface do container para faz-la compatvel com a interface de servios de sistema de alto nvel. Essa interface precisa dar a iluso para esses servios que eles se comunicam com gerenciadores de dispositivos tradicionais. possvel conectar vrios servios de sistema a um mesmo container. Durante a criao de um novo container, um linker de E/S associado ao mesmo. O container deixa de ser ento um objeto genrico para tornar-se um objeto de compartilhamento de dados, vindos do dispositivo ao qual ele est ligado. Design dos Servios de Sistema Distribudos Os containers e linkers so utilizados para implementar vrios servios que compe um cluster, dentre eles memria virtual compartilhada e servios de mapeamento de arquivos. Memria Virtual Compartilhada A memria virtual compartilhada no Kerrighed estende esse servio ao cluster por permitir que vrios processos ou threads sejam executados em ns diferentes, compartilhando dados atravs do seu espao de endereamento. Para que esse servio seja provido, so requeridas trs propriedades: compartilhamento de dados entre os ns, coerncia na replicao de dados e acesso simples a dados compartilhados. Os servios do container garantem as duas primeiras propriedades, enquanto que a terceira garantida pelo mapeamento do linker de interface. Assim, mapear um container de memria em espaos de memria virtual de vrios processos via um mapeamento de linker, leva a uma memria virtual compartilhada. Mapeamento de Arquivos O servio de mapeamento de arquivos de um sistema operacional convencional permite mapear um arquivo no espao de endereo de um ou mais processo, ou no espao de endereo compartilhado por um grupo de threads. Estendendo esse servio a um cluster considera-se o mapeamento de um arquivo no espao de endereo de um processo no importando onde ser sua execuo, seja em seu n do cluster seja numa memria compartilhada de um grupo de threads. Isso feito por mapear um arquivo de container num espao de memria virtual de um processo graas a um mapeamento de um linker de interface.

159

Dynamic Streams (Fluxos dinmicos) O Kerrighed implementa um balanceamento de cargas de trabalho compostas de aplicaes paralelas, baseando-se em memria compartilhada ou em modelos de programao de message passing. Um desafio migrar eficientemente processos utilizando message passing. Processos que se comunicam utilizando interfaces padro tais como sockets ou pipes devem ser capazes de serem transparentemente migrados num cluster. Alm disso, migrar processos no deveria alterar o desempenho de sua comunicao com outros processos. As interfaces padro de comunicao tais como pipes e sockets, utilizam um fluxo binrio para realizar a comunicao entre processos. O Kerrighed prope um conceito de fluxo dinmico, sobre o qual interfaces padro de comunicao so desenvolvidas. As extremidades desses fluxos so chamadas KerNet sockets e os mesmos podem ser migrados dentro do cluster. Fluxos dinmicos e KerNet sockets so implementados no topo de um sistema portvel de comunicao de alta performance, provendo uma interface de envio/recepo para transferir dados entre diferentes ns num cluster. Os fluxos dinmicos e o KerNet sockets so implementados na camada KerNet. Ela um servio distribudo que prov gerenciamento global de fluxos em todo cluster. Servio de Fluxo Dinmico Todos os clusters baseiam-se num sistema de comunicao ponto a ponto de baixo nvel. Na maioria das vezes, tais sistemas proveem propriedades tais como confiabilidade, alta performance e ordenao de mensagens. Assim, quando a migrao no ocorre, as aplicaes devem ser capazes de tirar vantagem dessas propriedades. O Kerrighed possui um sistema de comunicao de baixo nvel que confivel e mantm a ordem das mensagens enviadas entre dois ns. O fluxo dinmico KerNet uma abstrao de fluxo com dois ou mais KerNet sockets definidos e com nenhum n especificado. Quando necessrio, um KerNet socket temporariamente associado a um n. Por exemplo, quando dois KerNet sockets esto conectados, uma operao de envio/recepo pode ocorrer.

160

Seguem alguns dos principais parmetros do fluxo dinmico KerNet: Tipo de fluxo Nmero de sockets Nmero de sockets conectados Filtro de dados

Fluxos so controlados por um grupo de gerenciadores, cada um deles localizado num n do cluster. Estruturas de dados do kernel relacionadas com fluxos dinmicos so mantidas num diretrio global que distribudo entre os ns cluster. Dados como a localizao do n de um KerNet socket, so atualizados em todos ns ativos no fluxo. O servio de fluxos dinmicos responsvel por alocar KerNet sockets quando necessrio, assim como monitorar os mesmos. Quando um estado de um KerNet socket muda, o gerenciador de fluxo acionado e atualiza os outros KerNet sockets relacionados a esse fluxo. Com esse mecanismo, cada KerNet socket tem o endereo do socket de cada n correspondente num mapeamento. Quando conexo termina, o processo desconectado do fluxo. Dependendo do tipo de fluxo, o mesmo pode ser fechado. Implementao de Interfaces de Comunicao Padro usando Fluxos Dinmicos Aplicaes distribudas padro, obviamente no utilizam KerNet sockets. A fim de criar um ambiente padro baseado em fluxos dinmicos e KerNet sockets, uma camada de interface implementada em nvel de kernel. O principal objetivo desse mdulo gerenciar o protocolo de interface de comunicao padro, se necessrio. As interfaces KerNet so ligaes entre o sistema operacional Linux padro e o servio dinmico de comunicao do Kerrighed.

161

O sistema operacional do Kerrighed desenvolvido sobre um kernel levemente modificado de Linux. Todos os diferentes servios, incluindo a camada de comunicao, so implementados como mdulos do Linux. A camada de comunicao constituda de duas partes: um sistema de comunicao esttico de alto desempenho que prov um servio n para n e um servio de interface que substitui as funes padro para uma dada ferramenta de comunicao. Camada de comunicao de baixo nvel A arquitetura do KerNet projetada para sistemas operacionais distribudos tais como o Kerrighed. Por essa razo, foi natural desenvolver o KerNet no topo da camada de comunicao de baixo nvel provida pelo Kerrighed, chamada Gimli/Glon. Segue algumas caractersticas dessa camada de comunicao. Confiabilidade: Toda mensagem entregue sem qualquer alterao. Interface simplificada: Esse servio de comunicao baseado na ideia de canais e prov uma interface bsica envio/recepo. A camada Gimli prov uma API em nvel de kernel sobre a qual todos os servios do Kerrighed so executados, em especial o KerNet. A camada Gloin responsvel pela confiabilidade da comunicao (controle de erro, retransmisso de pacote, etc).

162

Concluso do Captulo Ao pesquisar sobre os modelos e tipos de clusters apresentados nesse captulo, pudemos chegar a algumas concluses preliminares que, no nosso juzo, deveriam ser registradas. Os sistemas de clusters que possuem um n controlador, como, por exemplo, o Beowulf, so de desenvolvimento mais simples e usualmente, possuem uma melhor performance que os clusters SSI (Single System Image), porm a arquitetura fsica e lgica de um elemento que gerencia os ns escravos, sendo a nica interface entre o ambiente externo e o cluster, produz uma condio intrnseca de um ponto nico de falha, que faz desse modelo de processamento distribudo no aderente a ambientes de alta disponibilidade. Apesar de haver solues de redundncia para o n mestre para clusters com essa caracterstica, provendo assim uma maior robustez ao sistema como um todo, essa soluo de contorno incide num custo maior na implementao do cluster, que vai de encontro com a nossa proposta de oferecer uma soluo no dispendiosa dessa tecnologia. Quanto aos clusters SSI, vemos neles uma soluo mais elegante e tecnicamente rica, pois se prope a tornar um grupo de computadores numa nica entidade, atravs de um sistema operacional que prov esse tipo de funcionalidade. Por certo, desenvolver um sistema dessa natureza um desafio, pois como descrevemos nesse captulo, trabalhar com elementos como threads, memria e espao de memria e sockets num ambiente de sistema de imagem nica, requer um maior grau de complexidade e consequentemente solues mais apuradas para implementar tais funcionalidades, que j esto consolidadas em ambientes de processamento monoprocessado. Assim um sistema de cluster seja qual o modelo e tecnologia utilizada no ser uma somatria simples do poder de processamento e funcionalidades dos ns que o compe, pois uma boa parte dos recursos desses ns sero utilizados para o estabelecimento e a manuteno do cluster.

163

Captulo 3 Apresentao do Laboratrio A apresentao do laboratrio considerar os seguintes aspectos: Descrio do hardware utilizado Descrio do Sistema Operacional utilizado Descrio da configurao do Cluster Kerrighed implementada Descrio dos aplicativos utilizados para anlise do ambiente em cluster e standalone, de acordo com a proposta desse trabalho. Descrio do hardware utilizado Segue um esquema lgico do laboratrio proposto:

Figura 18

164

Segue uma imagem dos equipamentos do laboratrio:

Figura 19

165

Descrio dos itens que compe o laboratrio: Switch Catalyst 3750E 24 Portas 10/100/1000 e 2 Portas 10 Gigabit Ethernet Desempenho: Capacidade de switching fabric 160 Gbps Taxa de transmisso 65,5 Mpps Principais funcionalidades: IEEE 802.1s IEEE 802.1w IEEE 802.1x IEEE 802.3ad IEEE 802.3af IEEE 802.3x full duplex on 10BASE-T, 100BASE-TX e 1000BASE-T IEEE 802.1D Spanning Tree Protocol IEEE 802.1p CoS Prioritization IEEE 802.1Q VLAN IEEE 802.3 10BASE-T IEEE 802.3u 100BASE-TX IEEE 802.3ab 1000BASE-T IEEE 802.3z 1000BASE-X 100BASE-FX 1000BASE-T 1000BASE-SX 1000BASE-LX/LH

166

Computadores Para facilitar a identificao passaremos a designar os computadores utilizados no laboratrio como N 00 e N 01 do cluster. N 00 Processador Memria Sistema Operacional
Controladora de Disco

Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz 2075 MB Debian GNU/Linux 5.0.4
Intel Corporation 82801GB/GR/GH

Disco Kernel Interface de Rede

ATA SAMSUNG HD322HJ

Linux 2.6.20-krg (i686)


2 x Broadcom Corporation NetXtreme BCM5700 Gigabit Ethernet

167

N 01: Processador Memria 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

Descrio do Sistema Operacional utilizado O Sistema Operacional utilizado o Linux na distribuio Debian na verso do GNU/Linux 5.0.4 com kernel 2.6.20 modificado para suporte ao Kerrighed. A escolha da distribuio Debian deu-se por a mesma ter uma melhor compatibilidade com Kerrighed e especialmente na instalao do mesmo. O Debian tambm se mostrou muito estvel e resiliente durante a implementao e testes do cluster. Seguem algumas caractersticas que contriburam para escolha do Debian: mantido por seus prprios usurios. Se alguma funcionalidade precisa ser aperfeioada, a prpria comunidade atua na melhoria. Suporte eficiente pela prpria comunidade. Mensagens enviadas s listas de discusso frequentemente so respondidas em cerca 15 minutos.

168

Pacotes bem integrados O Debian supera todas as outras distribuies no que se refere qualidade de integrao de seus pacotes. J que todo software organizado em grupos coerentes, no 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 dependncias complexas. Apesar de o formato deb ter algumas vantagens sobre o rpm , a integrao entre os pacotes que faz o sistema Debian mais robusto. Cdigo fonte Quantidade significativa de ferramentas de desenvolvimento, facilitando a incluso de funcionalidades ao sistema operacional. Estabilidade Os desenvolvedores do Debian afirmam que existe uma quantidade significativa de caso em que computadores executam a distribuio por um longo tempo, sem nenhuma indisponibilidade do sistema operacional. Pudemos verificar isso durante a implementao no laboratrio. Rpido e leve com a memria Por ser baseado em GNU/Linux o Debian mostra-se confivel e leve no que concerne ao uso de memria. Drivers para a maioria do hardware so escritos pelos usurios de GNU/Linux, no pelos fabricantes. Embora se possa considerar como uma deficincia 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 produo pelo fabricante ou da sada do mesmo do mercado. A experincia tem mostrado que drivers livres so normalmente melhores que os proprietrios.

169

Descrio da configurao do Cluster Kerrighed implementada Histrico do Kerrighed O projeto Kerrighed foi iniciado por Christine Morin19 em 1999 no INRIA, laboratrio nacional francs para pesquisa em cincia da computao. At 2006, o projeto foi desenvolvido no INRIA (Institut National de Recherche en Informatique et en Automatique) como prottipo 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 consrcio XtreemOS e um nmero crescente de colaboradores. Instalao do Kerrighed O Kerrighed foi instalado em dois ns atravs das instrues publicadas em www.kerrighed.org . Basicamente os fontes do Kerrighed e do kernel 2.6.20 so obtidos no GForge do INRIA, ambos so configurados e compilados. Os seguintes diretrios e arquivos precisam ser criados para que a instalao 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 smbolos do kernel do Kerrighed Mdulos do Kerrighed Script de servios do Kerrighed Configurao de Servios Pginas Man Ferramenta de administrao do cluster Ferramenta verificao de funcionalidades Ativao checkpoint/restart dos processos Ferramenta de migrao de processos

/usr/local/lib/libkerrighed-* Biblioteca do Kerrighed /usr/local/include/kerrighed Cabealhos da Biblioteca do Kerrighed Tabela 1 Depois da instalao basta editar o arquivo /etc/kerrighed.nodes para identificar ou ativar os ns dentro do cluster automaticamente no momento da inicializao.

19

Cientista Snior do Rennes - Bretagne Atlantique. Lder do grupo de pesquisa Myriads. Cofundadora do Kerlabs empresa criada para fornecer servios comerciais na tecnologia Kerrighed. Coordenadora cientfica do projeto europeu do XtreemOS.

170

O Kerrighed cria uma nova imagem de sistema que pode ser escolhida no momento da inicializao do Linux. Com o comando krgadm o cluster pode ser inicializado manualmente, podendo-se verificar se o mesmo est funcional e reconhecendo os ns.

Descrio dos aplicativos para testes PovRay Uma atividade computacional intensa a criao de imagens em trs dimenses em computadores. As empresas cinematogrficas tm usado cada vez mais esse recurso, seja para criar produes totalmente animadas digitalmente, seja para criar alguma imagem que seria dispendiosa ou mesmo impossvel de ser gerada, utilizando a criao tradicional de cenrios. Apesar dos sistemas em cluster em geral no serem, via de regra, apropriados para execuo aplicaes em tempo real, como por exemplo, VoD ou IPTV, eles so muito utilizados nos processos de renderizao de imagens, pois os mesmos necessitam de sistemas de grande poder de computao que podem ser provido pelos clusters. Iremos verificar se o Kerrighed apresenta bons resultados utilizando a aplicao de renderizao 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 iluminao, muito prximas de imagens reais. O ray-tracing um mtodo de gerar imagens a partir de uma descrio geomtrica de objetos. Ele uma tcnica de renderizao que calcula uma imagem de alguma cena atravs da simulao de raios de luz que viajam no mundo real. Entretanto esse trabalho feito de trs para frente. No mundo real a luz emitida de uma fonte e ilumina os objetos. A luz reflete nos objetos e passa atravs de objetos transparentes. Essa luz refletida atinge nossos olhos ou a lente de uma cmera, por exemplo. Como a vasta maioria dos raios nunca atinge um observador, gerar uma cena desse modo levaria um enorme tempo.

171

Programas como o PovRay simulam os raios de luz saindo por detrs da cena. O usurio especifica a localizao da cmera, as fontes de luz, os objetos, a textura das superfcies dos mesmos, seu interior (caso forem transparentes) e qualquer atmosfera como neblina, bruma ou fogo. Para cada pixel da imagem final, um ou mais raios visveis so disparados da cmera na cena, para verificar se eles interceptam algum objeto na mesma. Esses raios visveis originados pelo observador, representados por uma cmera, passam atravs de um espao visvel, gerando a imagem final. Em cada momento que um objeto atingido, a cor da superfcie do mesmo calculada. Por esse motivo raios so enviados de trs para frente, de cada fonte luz para determinar a quantidade de luminosidade vinda dessas fontes. Raios representando sombras so gerados para determinar se o ponto est nas sombras ou no. Se a superfcie reflexiva ou transparente, novos raios so configurados e traados para determinar a contribuio de luz refletida e refratada para cor final da superfcie. Para funcionalidades especiais como reflexo interdifusa, efeitos atmosfricos e reas de luz, faz-se necessrio disparar um nmero maior de raios na cena para cada pixel. Uma das verificaes que sero realizadas no laboratrio ser a renderizao de uma imagem e o consumo de tempo e recursos para realizar esse tipo de operao computacional. Naturalmente existem outros mtodos e ferramentas para renderizao de imagens. Podemos mencionar como mtodos rasterization e ray casting e como ferramentas Mental Ray e RenderMan. Segundo os desenvolvedores do PovRay a verso 3.7 (Beta) j suporta de maneira nativa processamento paralelo. Iniciaremos o nosso laboratrio com a verso 3.6 por ser a verso oficialmente consolidada. Aps fazer um download do arquivo binrio do PovRay em www.PovRay.org basta seguir as instrues para instalao apresentada no mesmo WEB site.

172

Breve: Um ambiente 3D para Simulao de Sistemas Descentralizados e Vida Artificial O Breve um ambiente em 3D destinado a simulao de sistemas descentralizados e de vida artificial. Enquanto ele conceitualmente similar aos sistemas j existentes tais como o Swarn e o StarLogo, sua implementao, que simula tanto tempo contnuo e espao contnuo em 3D, significamente diferente dos sistemas citados, tanto que o ambiente do Breve adequado para diferentes classes de simulaes. O Breve inclui uma linguagem interpretada orientada a objeto, a OpenGL, dispositivo de deteno de coliso, suporte experimental para corpos fsicos articulados e resoluo de coliso com frico esttica e dinmica. O principal objetivo desse sistema permitir a implementao rpida e fcil de simulaes descentralizadas ao mesmo tempo em que prov uma estrutura com muitos recursos que facilitam a construo de simulaes de vida artificial avanadas. O Breve um ambiente integrado de simulao o qual objetiva simplificar grandemente a implementao de sistemas descentralizados e simulaes avanadas de vida artificial. Ele destinado tanto para usurios que no programam como usurios com experincia em linguagem de programao, bibliotecas e programas. As simulaes do Breve so escritas numa linguagem simplificada orientada a objeto chamada steve. A linguagem steve, especialmente designada para simulaes em 3D, incluem coletores de lixo (garbage collection), suporte a listas, vetores de 3D nativos assim como grupo de classes que fazem interface com funcionalidades de simulao do sistema central (engine) do Breve. Ele tambm oferece uma arquitetura de plugin simples com a qual os usurios podem estabelecer interfaces com bibliotecas externas ou linguagens, acessando as mesmas atravs do steve. O steve uma linguagem procedural e muitas de suas funcionalidades parecero familiar aos usurios da linguagem C. A diferena que a sintaxe do mtodo de chamadas mais parecida com o Objetive-C. No steve, cada argumento de um mtodo de chamada associado a uma palavra chave. Isso significa que os argumentos no so identificados por sua ordem, mas por suas palavras chaves. O fato de steve ser uma linguagem interpretada que retm muitos tipos de verificaes e mtodos de busca at o momento da execuo do cdigo, pode causar algum problema de desempenho, mas na prtica, os gargalos das simulaes do Breve esto mais relacionadas a simulao fsica e a renderizao das imagens do que na execuo do cdigo do steve.

173

Classes hierrquicas gerais A interao com as funcionalidades nativas do Breve realizada da atravs de classes hierrquicas gerais. No topo dessa hierarquia temos a classe chamada Object que o pai de todos os objetos criados no Breve. A hierarquia dividida em classe Abstract e classe Real. A classe Abstract definida como classes que no possuem uma representao fsica no mundo simulado, enquanto a classe Real est associada a alguns tipos de objetos fsicos. A classe Real inclui objetos mveis e os objetos estacionrios. As funes dessas classes so simples: objetos mveis representam agentes que se movem durante o curso da simulao, enquanto os objetos estacionrios representam entidades que so imveis durante o curso da simulao, tais como o piso e obstculos. Os membros mais importantes da hierarquia Abstract so as classes Control e Data. A primeira que prov uma interface com o engine do Breve, controlando funcionalidades como cmera, ajuste de luminosidade, renderizao grfica e interface com usurio. A classe Data uma classe especial pode ser salva em disco ou em rede. Eventos e Escalonamento O comportamento dos agentes so escritos no steve como parte da definio de um objeto. Cada ao que o agente pode tomar pode ser escrita como um mtodo separado que chamado em resposta a certos eventos. H muitos modos de disparar eventos dentro de uma simulao no Breve: Eventos chamados por interao Eventos escalonados para um momento especfico Eventos disparados por notificaes Eventos disparados por colises Eventos disparados atravs da interface de usurio

174

Init e Destroy Se necessrio, os mtodos especiais init e destroy so automaticamente chamados, por exemplo, quando uma instncia criada e liberada, respectivamente. Assim esse mtodo permite manipular inicializao e a desativao de uma instncia, se necessrio. Execuo de Simulaes Cada simulao controlada por um simples objeto controlador uma instncia da classe nativa Control (ou algumas de suas subclasses). A instncia controladora definida no cdigo fonte da simulao, sendo a nica instncia que automaticamente criada quando uma simulao executada. Outras instncias podem, por sua vez, serem criadas pela instncia controladora atravs do mtodo init. A instncia controladora tambm recebe um nmero de retornos (callbacks) de objetos no mundo simulado ou selecionando itens de um menu, assim nesse caso, a instncia controladora pode ser considerada como o processo principal da simulao. Concluindo, o ambiente de simulao Breve nico, sendo adequado para simulaes de vida artificial e outros sistemas descentralizados. Sua principal nfase estabelecer como objetivo a implementao de simulaes de baixo nvel altamente realistas a fim de manipular comportamentos de alto nvel com o mesmo grau de realidade. As funcionalidades como a habilidade de simular e apresentar modelos de 3D contnuo, facilidade de uso de sua linguagem orientada a objeto, assim como a sua capacidade para realizao de simulao fsica, distingue o Breve dos pacotes de simulao atuais. Quanto ao processamento paralelo no existe nenhuma informao dos

desenvolvedores da aplicao sobre o tema, mas o OpenGL que realiza grande parte das funes do Breve prov suporte para processamento paralelo, assim inferimos que o mesmo seja beneficiado com esse modelo computacional. O software Breve pode ser obtido em http://www.spiderland.org/.

175

Concluso do captulo Apesar do ambiente provido para a medies e anlise ser de natureza singela em termos de quantidade de ns do cluster e das aplicaes que sero utilizadas no laboratrio, acreditamos que o objetivo desse trabalho ser alcanados tendo em vista que a proposio avaliar aplicao de Design Digital, no caso o PovRay e Inteligncia Artificial, o Breve num ambiente de cluster. Certamente outras aplicaes de mesma natureza tero comportamento e desempenho distintos, especialmente no que tange a utilizao dos recursos do processamento paralelo. importante ressaltar que o prprio cluster e suas funcionalidades inerentes podem tambm influenciar nos resultados obtidos. Acreditamos que a anlise nesse ambiente mais restrito, facilitar as medies, comparaes e concluses e ao mesmo tempo servir de arcabouo para uma abordagem mais abrangente do tema, realizando testes com outras aplicaes e em condies distintas, como por exemplo, um cluster com um nmero maior de ns.

176

Captulo 4 Medies e anlises Os sistemas em clusters sero mais plenamente aproveitados se as aplicaes que forem executadas pelos mesmos suportarem processamento paralelo que seria dividir tarefas e funes da aplicao entre os processadores que os compe. Em sistemas paralelos as principais mtricas so ganho de velocidade (speedup) e a capacidade de crescimento ou escalabilidade, visando sempre executar as aplicaes num tempo menor, se estamos tratando de HPC (High Performance computing). Quando falamos de escalabilidade estamos considerando o quanto uma determinada aplicao ser beneficiada com o aumento de ns num cluster, pois na maioria dos casos existe um ponto de saturao, quando a insero de um novo n no cluster passa a no corresponder a um aumento de desempenho. De fato, podemos ter casos em que o aumento de ns pode vir a degradar o desempenho da aplicao. Essa resposta em termos de desempenho depender de parmetros como velocidade de clock, tamanho do problema (granularidade), tempo de utilizao de CPU, uso do canal de comunicao, demanda por operaes de memria e E/S, dentre outros itens. Existem diversas abordagens e componentes para avaliao de desempenho de clusters, analisaremos algumas delas: Performance terica de pico Esse valor representa o mximo de operaes em ponto-flutuante por segundo, calculado pela seguinte frmula: P=N * C* F * R Frmula 2 Onde: P representa o desempenho medido em Mflops ou Gflops N o nmero de ns do cluster C identifica o nmero de CPUs por n F o nmero de operaes em ponto-flutuante por ciclos de clock R a velocidade de clock medido em ciclos por segundo

177

Performance das Aplicaes o nmero de operaes realizadas quando se est executando uma determinada aplicao, dividido pelo tempo de execuo. Esse tipo de medida feita atravs de programas de benchmark no correspondendo pelo menos em sua plenitude a uma aplicao de uso prtico. Execuo de Aplicaes Seria a medio do tempo de execuo de determinada aplicao numa condio predeterminada. No nosso caso utilizaremos essa abordagem ao analisar o PovRay. Ganho de velocidade Podemos medir o ganho de velocidade de uma determinada aplicao num cluster comparando o seu tempo de execuo com tempo de execuo da mesma aplicao num computador standalone. Segue a frmula:

Frmula 3 Lei de Amdahl20 A programao de aplicaes que utilizem o processamento paralelo ainda est num estgio incipiente, assim existem aplicaes que apenas parte das tarefas executada paralelamente e algumas em que as tarefas so totalmente serializadas. Amdahl criou uma expresso para medir a poro de processamento paralelo e a poro de processamento serializado numa dada aplicao.

20

Gene Myron Amdahl (16 de novembro de 1922) um projetista de computadores e empreendedor no ramo da alta tecnologia, mais conhecido por seu trabalho com mainframes na International Business Machines (IBM) e posteriormente por suas prprias empresas, particularmente a Amdahl Corporation. Ele talvez seja mais lembrado por ter formulado a Lei de Amdahl, uma teoria fundamental da computao paralela.

178

A frmula trivial:

Frmula 4 Onde: p representa o desempenho da poro serial em porcentagem T o tempo em segundos (1-p) representa a poro paralelizvel N o nmero dos ns do cluster

Somente a poro paralelizvel do programa que se beneficia com os processadores dos ns do cluster. Assim o ganho de processamento seria:

Frmula 5 Quanto mais a aplicao tiver tarefas que so processadas de modo paralelizado e quanto maior a quantidade de ns no cluster, maior ser o ganho de processamento segundo Amdahl. Performance da rede As conexes de rede so tambm um item essencial no desempenho do cluster como um todo. Seguem alguns quesitos importantes no que tange s redes que conectam os ns que compe um cluster:

179

Vazo (throughput): A quantidade efetiva de dados em bits por segundo que so transmitidos entre os ns. Apesar velocidade das interfaces de rede e do elemento onde elas esto conectadas (usualmente um switch) serem determinantes para o desempenho da rede, existem outros fatores que precisam ser considerados como, por exemplo, o desempenho dos ns em geral em termos de CPU, memria, cache, etc, assim como o barramento em que esto conectadas as interfaces de rede, os drivers dessas interface e latncia do sistema como um todo, dentre de outros fatores. Eficincia do protocolo TCP-IP: O protocolo TCP-IP comporta-se de maneira diferente em relao aos diferentes aplicativos e os parmetros 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 condies normais, sem nenhum ajuste de parmetros de TCP-IP nesses aplicativos. Overhead do TCP-IP e das camadas de rede inferiores: Existem uma quantidade significativa da banda das conexes de rede que so utilizadas para endereamento, multiplexao, deteco e correo de erros que no ser efetivamente utilizada para o trfego de dados e manuteno do cluster. Esse overhead impede de utilizarmos capacidade total de banda disponvel para trfego efetivo de dados. Abordagem e ferramentas de anlise do desempenho do cluster A nossa abordagem e estratgia de medio da performance ser a seguinte: Medio e anlise do throughput real das conexes de rede. Estresse do cluster e anlise, para confirmar a efetiva funcionalidade do mesmo. Teste e medio de memria. Medio e anlise do sistema em cluster e monoprocessado em ferramentas tradicionais de benchmark apresentadas no aplicativo hardinfo. Medio e anlise do sistema monoprocessado e em cluster utilizando um aplicativo de Design Digital (PovRay). Medio e anlise do sistema monoprocessado e em cluster utilizando um aplicativo de Inteligncia Artificial (Breve).

180

Anlise geral dos resultados Medio e anlise do throughput real das conexes de rede. Utilizamos o aplicativo iperf para medir o throughput real das conexes de rede e como esperado no foi alcanada a banda passante de 1 Gigabits/sec que a velocidade das interfaces de redes, pelos motivos explanados no incio desse captulo. Seguem as medies:

Figura 20 Percebemos que na transmisso unidirecional de pacotes obtemos a taxa de 644 Mbits/sec, 64% da banda nominal das interfaces de rede que so de 1 Gigabit Ethernet. Na transmisso 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 configurao de hardware superior, que confirma o fato que esse quesito pode ser determinante na taxa de transferncia de um sistema.

181

Consideramos uma taxa de transferncia de 644 Mbits/sec adequada para um cluster com apenas dois ns, no sendo um impedimento para a utilizao plena do mesmo. Essa afirmao ser verificada nas prximas medies e anlises.

Estresse do cluster e anlise para confirmar a efetiva funcionalidade do mesmo Para verificar o comportamento do cluster numa situao de estresse, estabelecemos o seguinte cenrio: N 00 Aplicaes executadas: Breve Creature.tz PovRay benchmark.pov

N 01 Aplicao executada: Breve Gatherers.tz PovRay benchmark.pov Utilizaremos a aplicao system monitor para medir a utilizao de CPU, memria e consumo de banda do cluster.

182

Telas N 00:

Figura 21 Execuo das aplicaes Breve e PovRay no N 00

Figura 22 Evidncia de o cluster estar operacional

183

Figura 23 Medies de utilizao CPU, Memria e Rede no N 00

Figura 24 Tempo de renderizao do Benchmark.pov no N 00

184

Tela N 01

Figura 25 Execuo da aplicao Breve no N 01

Figura 26 Tempo de renderizao do Benchmark.pov no N 01

185

Percebemos que apenas quando iniciamos a execuo da renderizao do arquivo benchmark.pov que a utilizao de CPU em ambos os computadores chegou a 100%, porm a utilizao de memria e o consumo de banda se mantiveram estveis e em nveis baixos. Podemos afirmar nessa primeira anlise que a renderizao de imagens pelo menos em se tratando do PovRay possui uma tendncia para utilizao intensa de CPU. O tempo total de renderizao do arquivo Benchmark.pov no n 01 foi de 3 minutos e 58 segundos numa condio de saturao das CPUs. A ttulo de esclarecimento, como os processadores dos ns so Core Duo, os mesmos so apresentados como 4 processadores pelo system monitor. Podemos tambm afirmar que nas condies de testes estabelecidas o consumo de banda foi muito baixo, como uma sinalizao que esse componente no ser um fator de estrangulamento no ambiente proposto. Pela utilizao consideravelmente baixa de memria durante a execuo dos aplicativos no teste de estresse proposto, decidimos fazer um teste especfico de memria para verificar o comportamento desse componente num cluster Kerrighed. Teste e medio de memria Utilizamos o aplicativo memtester para verificar as condies da memria do cluster, pois o seu uso durante a execuo das aplicaes PovRay e Breve foi muito reduzido. Esse aplicativo destina-se a verificar a integridade de memria RAM em Linux, realizando uma srie de verificaes. O comportamento do cluster Kerrighed nesse teste foi positivo, tendo em vista que o compartilhamento e a integridade da memria num cluster, uma DSM (Distributed Shared Memory), um dos grandes desafios dessa tecnologia. Porm no foi possvel utilizar 4.6 Gbytes nesse teste, apenas 2.4 Gbytes. Ao ultrapassarmos esse limite o cluster deixa de operar, necessitando-se uma reinicializao do mesmo. Seguem os resultados.

186

Telas N 01:

Figura 26 Medio do uso da memria durante a execuo do memtester

Figura 27 Finalizao do teste de memria sem apresentar nenhum erro

187

Tela N 00:

Figura 28 Medio do uso da memria durante a execuo do memtester Conclumos em primeiro lugar que o cluster Kerrighed realiza a agregao das memrias fsicas dos ns que o compe. Temos o n 00 com 2.075 MBytes de memria e o n 01 com o 2.594 MBytes e o system monitor indicou uma memria total de cerca 4.600 MBytes (4.6 Gbytes). Esse agregado de memria passou pelos testes do memtester sem apresentar nenhum erro, indicando consumo de memria configurado ao executar-se o comando, que foi de 2.3 Gbytes. Assim podemos concluir que as aplicaes PovRay e Breve nas condies em que foi realizado o teste de estresse do cluster realmente no demandam uma quantidade de memria significativa. Outra observao foi novamente a utilizao baixssima dos recursos de rede, em torno de 10 Kbps.

Medio e anlise do sistema em cluster e nos ns com ferramentas de benchmark apresentadas no aplicativo hardinfo Executamos as rotinas de benchmark do aplicativo hardinfo em cada n separadamente e no prprio cluster, seguem os resultados:

188

Grfico 1 O valor maior indica um melhor desempenho.

Grfico 2 Menor valor indica um melhor desempenho.

Grfico 3 Maior valor indica um melhor desempenho.

189

Grfico 4 Maior valor indica um melhor desempenho.

Grfico 5 Menor valor indica um melhor desempenho.

Grfico 6 Menor valor indica melhor desempenho.

190

Segue uma breve descrio dos testes de benchmark realizado pelo hardinfo: CPU Zlib - compresso de dados utilizando o algoritmo Zlib em 64 MBytes de dados. CPU Fibonacci - clculo do nmero 42 de Fibonacci. CPU MD5 - Gerao de hashing em MD5 para 312MB de dados. CPU SHA1- Gerao de hashing em SHA1 para 312MB de dados. CPU Blowfish Execuo do algoritmo de criptografia Blowfish FPU Raytracing Programa para renderizao de imagens utilizando a mesma tcnica do PovRay. Constatamos, mediante os valores levantados, que o desempenho do cluster menor (apesar de ser muito prximo) ao desempenho do N 00 que computador com a maior capacidade no cluster, pelo menos nas aplicaes utilizadas no benchmark do hardinfo. Baseado nessas informaes, podemos afirmar que o cluster SSI Kerrighed no seria uma infraestrutura vivel pelo menos no que concerne ao desempenho, para os testes realizados pela aplicao hardinfo. 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 contriburam com suas experincias com o cluster Kerrighed, elencaram as seguintes consideraes: Apenas aplicaes desenvolvidas para processamento paralelo iro se beneficiar em termos de desempenho ao utilizarem o Kerrighed. O Kerrighed ir apenas apresentar resultados prticos significativos quando executarmos vrios processos simultaneamente em todos os ns que compe o cluster. Quanto ao memtester, um dos pesquisadores disse que ao fazer testes em memrias non-ECC utilizando essa ferramenta em ns individuais de seu cluster, como o memtester faz um locking de memria no espao de usurio, ele no conseguiu testar toda a extenso da memria RAM. Ele sugeriu executar o memtester em todos os ns que compe o cluster simultaneamente.

191

Para obtermos uma constatao definitiva da viabilidade do cluster Kerrighed, dentro das premissas propostas em nosso trabalho, como uma opo para o processamento de aplicaes de Inteligncia e Design Digital, no nosso caso o Breve e o PovRay, executaremos essas aplicaes em ambiente standalone, verificando o

comportamento das mesmas em relao ao ambiente em cluster, considerando os resultados e conhecimento adquiridos atravs dos testes e medies realizadas at esse estgio do trabalho.

Medio e anlise do sistema em cluster e monoprocessado utilizando um aplicativo de Design Digital (PovRay) Medir o desempenho do aplicativo PovRay foi relativamente simples, pois o mesmo apresenta o tempo de execuo, ao finalizar uma renderizao. Assim executamos o arquivo benchmark.pov em cada n cluster em separado, executando o mesmo arquivo com cluster em operao. Executamos num primeiro momento o arquivo benchmark.pov em apenas um n do cluster, aps isso, executamos simultaneamente o arquivo nos dois ns que compe o mesmo. Utilizamos o menor tempo de execuo da renderizao entre os dois ns como referncia nessa medio. Algo digno de nota ao realizarmos a execuo do arquivo benchmark.pov em apenas um n do cluster, foi que o shell (terminal) foi aberto e executado num n do cluster e a imagem renderizada surgiu no outro n que compe o mesmo, comprovando a capacidade do cluster de migrar processos.

Tempo de execuo do benchmark.pov em segundos


350 300

250
200 150

100
50 0

N 00

N 01

Execuo em 1 Execuo em 2 Execuo em 2 N Ns Ns com alta Utilizao

Grfico 7

192

Constatamos que o tempo de execuo do arquivo do PovRay maior para cluster do que para o computador standalone com maior poder computacional que compe o mesmo. Percebemos tambm, que ao executarmos o arquivo benchmark.pov concorrentemente nos dois ns, houve uma diminuio do tempo de execuo, confirmando a tese que o cluster Kerrighed apresenta um melhor desempenho quando executamos vrios processos simultneos. Para reforar a validade dessa hiptese, executamos em ambos os ns a simulao do Breve Gatherers.tz, assim como o benchmark.pov. O desempenho do Kerrighed, ao executar esses processos simultaneamente, melhorou significantemente, atingindo o mesmo tempo do execuo do computador com melhor hardware que compe o cluster. Porm em nenhum momento o Kerrighed obteve um melhor desempenho que o n com a melhor configurao de hardware executando o mesmo arquivo do PovRay, trabalhando em modo standalone. Conclumos que o cluster Kerrighed executando renderizaes na aplicao PovRay, no prov um aumento de desempenho linearmente proporcional a quantidade de ns que compe o cluster, mas apenas nos beneficiamos dos recursos do Kerrighed quando executamos vrios processos ao mesmo tempo, podendo assim renderizar vrios arquivos numa mesma plataforma virtual de hardware. Ao tambm discutirmos o tema com Marcos Pitanga, um dos profissionais especializados em cluster Linux no Brasil, autor de livros abordando essa tecnologia, o mesmo tambm confirmou que clusters SSI (Single System Image), realmente teriam esse comportamento, de utilizarem todos os recursos de um n, at que os mesmos sejam exauridos, para que utilizem os recursos dos outros ns que compe o cluster.

193

Medio e anlise do sistema em cluster e monoprocessado utilizando um aplicativo de Inteligncia Artificial (Breve) A comparao entre o sistema em cluster e um n que compe o mesmo em modo standalone, utilizando o Breve, no foi to direta e simples como a abordagem utilizada com o PovRay, pois as simulaes do Breve so de execuo contnua. Assim a proposta para essa avaliao foi baseada na medio do consumo de processador e memria RAM que cada instncia do Breve consumiria no ambiente monoprocessado e em cluster, e por extrapolao verificar o aumento de capacidade de execuo de simulaes baseadas em IA realizadas pelo Breve no cluster. Ao iniciar os testes e medies, percebeu-se que como o Breve gera imagens em movimento no ambiente grfico do Linux (GNOME), muito do processamento era consumido por esse processo como se pode verificar no resultado do comando ps -eo pmem,pcpu,args | sort -k 1 -r | less abaixo:

Figura 29 - Resultado do comando ps em ambiente monoprocessado

Figura 30 - Resultado do comando ps em cluster

194

No ambiente com um computador standalone com 6 instncias do Breve sendo executadas tivemos 68,6% do processamento para a interface grfica e no cluster Kerrighed tambm com 6 instncias de Breve, tivemos 90,3% do processamento consumido para esse mesmo fim. Mesmo com essa utilizao acentuada de processador para a interface grfica, percebemos que a utilizao de processador para a execuo do Breve no cluster menor que a utilizao de processador no ambiente monoprocessado, indicando numa primeira anlise, uma maior capacidade execuo de instncias do Breve pelo cluster, pois esse percentual calculado sobre a capacidade total de processamento do cluster. Como se pode verificar nas figuras acima, temos uma mdia de 0,2% da utilizao total de processador para uma instncia do Breve no cluster contra 0,5% de utilizao total de processador no ambiente monoprocessado. Isso significa uma capacidade 150% maior de processamento de instncias Breve pelo cluster em relao ao computador standalone. Seguindo a mesma linha de raciocnio, ao analisar o consumo da capacidade total de memria nos dois ambientes, percebe-se que a capacidade de memria para execuo de instncias do Breve no cluster exatamente o dobro da capacidade do computador standalone. A realizao e a anlise dos testes corroboraram para a constatao que o cluster Kerrighed em relao ao computador standalone possui um maior poder de processamento e capacidade de memria, podendo assim realizar ao mesmo tempo mais instncias dessa aplicao, porm o tempo de resposta, isto , o tempo de execuo do Breve, foi praticamente o mesmo nos dois ambientes de teste.

195

Captulo 5 Concluso Durante a apresentao dos captulos anteriores, muitas consideraes j foram feitas, ou para dar maior consistncia a esse captulo, ou para facilitar a prpria leitura e anlise desse trabalho. Nesse captulo de fechamento, alm de pontuarmos as principais constataes obtidas durante a pesquisa e experimentao, iremos apresentar de maneira mais sistemtica e sinttica os resultados e interpretao dos mesmos. Podemos afirmar dentro do universo das experimentaes realizadas nesse trabalho, que existem constataes empricas e tericas que sinalizam que os clusters SSI no possuem uma correspondncia linear entre a quantidade de ns e o desempenho do cluster, mas sim, que esse tipo de cluster possui uma capacidade de executar mais instncias e processos ao mesmo tempo do que execut-los mais rapidamente. De fato, nossos experimentos mostraram que para esse ambiente de teste no houve nenhum ganho em termos de desempenho ao utilizarmos o cluster Kerrighed para se executar as aplicaes PovRay e Breve quando comparado ao ambiente monoprocessado e sim um aumento de capacidade. Salientamos que essa afirmao refere-se estritamente ao ambiente de teste proposto, implantado e medido, podendose assim ser utilizado como referncia ou motivao para pesquisas da mesma natureza, mas no o extrapolado diretamente para ambientes e modelos diferentes do que o apresentado nesse trabalho. Portanto, podemos concluir baseado em nossas experimentaes, que um cluster Kerrighed seria mais apropriado para situaes onde desejamos ter vrias execues de uma tarefa ao mesmo tempo do que ter uma tarefa isolada sendo executada mais rapidamente. Ressaltamos tambm que as aplicaes que utilizamos nesses testes no suportam processamento paralelo, que poderia prover um ganho de desempenho quando executado num cluster, conforme a Lei de Amdahl. Segue dois grficos que clarificam a questo do aumento de capacidade de processamento proporcionado por um cluster:

196

Cluster
350 300 Tempo de Resposta 250 200 150 100 50 0 1 2 3 4 5 6 7 8 9 10 Instncias Tempo de Resposta

Grfico 8

Computador Standalone
500 Tempo de Resposta 400 300 Instncias 200 100 0 1 2 3 4 5 6 7 8 9 10 Tempo de Resposta

Grfico 9 Ao observar o grfico 8, percebemos que a partir da execuo da terceira instncia do benchmark.pov no cluster, ocorreu uma estabilizao do tempo de resposta na ordem de 236 segundos at a execuo de 10 instncias desse arquivo do PovRay. Ao contrrio do computador standalone, apresentado no grfico 9, que aps a quinta instncia executada do benchmark.pov teve a sua estabilidade comprometida, necessitando-se esperar a finalizao de uma das instncias para iniciar uma nova, dobrando o tempo de execuo da sexta instncia devido a essa espera. Esse foi o comportamento do cluster Kerrighed em laboratrio.

197

Para esclarecer os termos capacidade e desempenho (performance) de computador ou cluster, seguem as definies de Michael Ley21 (LEY, 2011) membro do CMG (Computer Measurement Group): Desempenho: Quantidade de tempo que uma transao individual ou parte de uma tarefa leva para ser completada. Capacidade: Quantidade de trabalho que pode ser realizado num determinado perodo de tempo. 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 famlia no Pas de Gales, que seria cerca de 200 milhas (370 km). Capacidade o nmero de carros por hora que a rodovia M4 (Rodovia que liga Londres ao Pas de Gales) pode suportar. Ao analisar o caminho percorrido nessa pesquisa, conclumos que a prpria literatura sobre o tema pode levar a uma expectativa equivocada de que um cluster sempre prover um ganho de desempenho. A prpria denominao para esse tipo de cluster em contraponto ao cluster HA (High Availability) que HPC (High Performance Cluster), leva ao pesquisador a esperar resultados que no que podem no ser reproduzidos num ambiente de teste real. Vale recordar qual foi a questionamento inicial que serviu de norte para nossa pesquisa: Seria a Tecnologia de Clusters uma infraestrutura acessvel para a implementao de HPC com nfase em Inteligncia Artificial e Design Digital? A Tecnologia de Cluster uma infraestrutura acessvel e adequada para aplicaes HPC com nfase em Inteligncia Artificial e Design Digital, mas algumas observaes e concluses necessitam ser pontuadas. Dividiremos em trs tpicos: viabilidade econmica, viabilidade tcnica e consideraes finais sobre a pesquisa.

21

Michael Ley comeou trabalhando na rea de capacidade e desempenho desde 1980 na fabricante inglesa de computadores ICL onde se especializou em testes de modelagem e desempenho. Posteriormente ele trabalhou para o BACS (Servio de nacional de transferncia eletrnica de fundos no Reino Unido) onde se tornou Gerente de Capacidade. Hoje ele trabalha num dos maiores bancos da cidade de Londres. Michael Ley atualmente membro do Comit Executivo do CGM do Reino Unido, tendo por anos apresentado matrias sobre modelagem e processos. Ele tambm foi responsvel pelas propostas do CMG para o ITSMF do qual o padro ITIL oriundo.

198

Viabilidade Econmica do Cluster Kerrighed Para iniciarmos essa anlise faz-se necessrio introduzirmos dois conceitos de computao que no so o tema do nosso trabalho, mas que so indispensveis para analisarmos a viabilidade econmica da utilizao de clusters em geral e o cluster construdo para a realizao dessa pesquisa em particular. Esses temas so computao em grid e a computao em cloud. O motivo de introduzirmos esses conceitos seria a impossibilidade de analisarmos em termos econmicos a utilizao de tecnologia de cluster sem compar-la as tecnologias de grid e cloud, pois so plataformas alternativas para realizar uma tarefa computacional que demande uma capacidade de processamento significativa. J abordamos alguns conceitos de grid nessa pesquisa e cluster o nosso tema principal, porm apresentaremos novamente uma breve descrio dessas tecnologias para facilitar a comparao. Segundo Buyya22 (BUYYA, 2011), cluster um tipo de sistema paralelo e distribudo, que consiste de uma coleo de computadores interconectados operando

conjuntamente como um nico recurso computacional integrado. Buyya define grid como um tipo de sistema paralelo e distribudo que habilita o compartilhamento, seleo e agregao dinmica de recursos autnomos

geograficamente distribudos, dependendo assim da disponibilidade, capacidade, desempenho, custo e requerimentos de qualidade de servio desse sistema para que o mesmo seja utilizado. Segundo Buyya et al. cloud um tipo de sistema paralelo e distribudo que consiste de uma coleo de computadores conectados e virtualizados que so dinamicamente disponibilizados e a apresentados como um ou mais recursos de computao unificada baseada em SLA (Service-Level Agreement), estabelecido atravs de uma negociao entre o provedor do servio e o consumidor.

22

Rajkumar Buyya professor de Cincia da Computao e Engenharia de Software e diretor do laboratrio CLOUS (Cloud Computing and Distributed Systems) na Universidade de Melbourne, Austrlia. Ele tambm serve como fundador e presidente da Manjrasoft Pty Ltd., uma companhia iniciada na Universidade que comercializa inovaes em computao em Grid e Cloud.

199

Em um artigo Buyya (BUYYA, 2011) e colaboradores sugerem analisarmos a tendncia de busca atravs da WEB sobre essas trs tecnologias, nesse caso analisamos apenas os acessos realizados no Brasil. Segue o grfico:

Grfico 10 Podemos observar claramente no grfico a supremacia da computao em cloud em comparao ao cluster e grid no que tange pesquisa sobre o assunto e tambm a publicao de novos contedos sobre tema na WEB. Atribumos esse comportamento a dois fatores, primeiro o financeiro, pois a primeira vista, a contratao de um recurso computacional por um valor mensal seria mais barato do que se implantar um cluster ou mesmo um sistema de grid. O segundo fator seria o tcnico, pois ao se adquirir um recurso computacional via cloud, o sistema viria, em teoria, pronto para o uso. Vale ressaltar tambm que o acesso a informaes referentes computao em cloud no significa necessariamente a adoo efetiva da tecnologia, que por ser mais recente ter naturalmente mais pessoas buscando informao sobre a mesma.

200

Segue alguns valores mdios para analisarmos financeiramente. Sero apresentados alguns custos para a utilizao de clusters e computao em cloud. Nessa anlise, no incluiremos a computao em grid, pois a maioria de seus projetos envolve a computao voluntria tornando a anlise financeira dessa modalidade de computao invivel para os fins pretendidos. Consideramos assim a computao em grid, de modo geral, sem custos compatveis para serem comparados nessa anlise financeira. Temos cincia que qualquer soluo tecnolgica possui um custo de implantao e manuteno, mas como o uso de grid est muito restrito pesquisa cientfica e utilizao acadmica com subsdios e investimentos pblicos e privados, usualmente para implementao de sistemas de mdio e grande porte. A ttulo de registro temos iniciativas de computao em grid no Brasil como o BOINC (Berkeley Open Infrastructure for Network Computing). O custo para a implementao do sistema de cluster utilizado em nosso laboratrio foi em torno de R$ 3.250,00, no considerando o switch Catalyst 3750E utilizado nas experimentaes por ser um equipamento do lder de mercado que o torna no ideal para a nossa proposta de uma tecnologia acessvel no aspecto financeiro. Consideramos assim nessa precificao um switch de fabricao nacional com as mesmas funcionalidades necessrias para a montagem do cluster. Seguem os valores: Item Computador Switch Placas de Rede Chaveador de Servidor No-break 1.2 KVA Total Quantidade Valor Unitrio 2 1 2 1 1 R$ 999,00 R$ 689,00 R$ 59,00 R$ 169,00 R$ 275,60 Valor Total R$ 1.998,00 R$ 689,00 R$ 118,00 R$ 169,00 R$ 275,60 R$ 3.249,60

Tabela 2

201

Para fins de comparao consideramos a contratao de um servio de computao em cloud de um provedor de servios de Internet dentre os maiores do Brasil. Salientamos que o servio considerado caracteriza-se, a nosso ver, como um IaaS (Infrastructure as a Service), pois o produto apenas servidores com certa capacidade de processamento, armazenamento, memria e banda passante (troughtput), ficando ao encargo do cliente a instalao e customizao de aplicativos e sistemas. No provedor analisado no permitido se escolher exatamente as caractersticas do servidor contratado, assim a configurao de hardware que mais se aproximou das caractersticas do cluster utilizado nesse trabalho foi a que segue: 4 Core de Processador de 1.2 GHz 3 GBytes de Memria 10 Mbits de banda disponvel 50 Gbytes de Disco Rgido Seguem os valores mensais: Item Contratao do Servio de Cloud Contratao de acesso Banda Larga de 10 Mbps Valor R$ 589,00 R$ 69,00

Total R$ 658,00

Tabela 3 Considerando um ano de utilizao duas plataformas:


Custo do cluster com uma despesa anual de manuteno de 10% sobre o custo total da soluo Custo do anual do servio de cloud considerando um valor promocional nos 3 primeiros meses

R$ 3.574,56

R$ 7.011,00

Tabela 4

202

Salientamos que o nosso objetivo nessa anlise contempla apenas viabilidade econmica do cluster implementado, que o foco desse trabalho, nos abstraindo de questes e abordagens mais profundas do tema, como os custos fixos para a manuteno de um cluster, as caractersticas e custo dos profissionais que atuaro com as duas tecnologias (computao de cluster e computao em cloud), a taxa real de banda passante de um acesso banda larga, dentre outros temas. Diante dessa anlise financeira pontual podemos dizer que a implementao de um cluster nos moldes do que foi apresentado nesse trabalho vivel em termos financeiros mesmo considerando o ritmo acelerado da obsolescncia do hardware de recursos computacionais em geral. Alcanamos em cinco meses o ROI (Retorno de Investimento) do cluster implementado, quando confrontado contratao de um servio de computao em cloud. Viabilidade Tcnica do cluster Kerrighed Aps a pesquisa e experimentaes para elaborarmos esse trabalho, podemos afirmar que um cluster no pode ser considerado como uma nica entidade computacional exatamente como um computador multiprocessado. Os usurios dos mesmos precisaro ter cincia das particularidades e limitaes de alguns recursos, como por exemplo, o manuseio de memria e processos. Dessa maneira, a nosso ver, num ambiente de cluster de mdio a grande porte, ser necessrio ter-se um administrador dedicado integralmente gerncia e manuteno desse cluster. Em relao do cluster Kerrighed seguem alguns pontos que poderiam ser aprimorados ou analisados mais profundamente: Instabilidade ao utilizar ferramentas de monitorao e medio dos recursos do cluster, como o prprio hardinfo, vmstat e top. Ocasionalmente quando o cluster estava numa condio de estresse, ao utilizar-se essas ferramentas, o mesmo entrava num estado de travamento, sendo necessrio reinici-lo. O comando para desligar os ns do cluster krgadm cluster poweroff no desliga os ns, mas os reinicia.

203

O Kerrighed no possui uma ferramenta grfica nativa para o monitoramento e configurao do cluster. Existem scripts em Linux que facilitam a implementao e configurao de cluster em lote e ferramentas ainda em desenvolvimento para a monitorao dos componentes do Kerrighed. Existem tambm clusters Kerrighed monitorados pela ferramenta de uso geral Ganglia que um software de monitoramento para HPC (High Performance Computing). Apesar das deficincias acima serem importantes, elas no impediram em nenhum nvel a realizao dos testes propostos e necessrios para a concretizao desse trabalho. Fazendo uma comparao em termos operacionais e tcnicos entre o uso de cluster ou computao em cloud, vemos como ponto chave o acesso interface grfica nos dois ambientes, no ambiente de cloud teremos que utilizar e customizar a controladora de vdeo fornecida pelo provedor, alm de acessar a interface grfica do recurso computacional atravs de ferramentas de VNC (Virtual Network Computing), cuja qualidade da imagem usualmente inferior a que gerada diretamente na interface grfica do servidor. O tempo de resposta de tela usualmente maior num ambiente cloud caso no se tenha um acesso a Internet com uma velocidade considervel. Essas deficincias foram constatadas empiricamente ao utilizarmos um servio de computao em cloud para podermos ter um contato real com a tecnologia, porm no seriam totalmente proibitivas para a utilizao da computao em cloud para renderizao de imagens ou execuo de simulaes grficas de IA, pois poderamos salvar as imagens geradas pelo PovRay em formatos padro como JPEG, Bitmap e outros, assim como salvar os vdeos gerados pelo Breve em MPEG e desse para outros formatos. Tanto as imagens como os vdeos poderiam ser executados remotamente ou transferidos e executados localmente. No incio desse trabalho foi estabelecida uma hiptese que cada novo n do cluster agregaria 80% da capacidade computacional ao mesmo. Consideramos os ns com as mesmas caractersticas de hardware nessa hiptese. Ao analisarmos os valores de utilizao de recursos de memria e processamento nos testes realizados com o Breve, tivemos um aumento de 100% da capacidade computacional do cluster em relao ao computador standalone. Como explicamos, na apresentao dos testes com o Breve, esses valores foram obtidos por extrapolao e no por testes de estresse, porm mesmo assim, a nosso ver, mostraram-se muito promissores e interessantes.

204

Um aspecto tcnico crucial num ambiente de cluster seria a capacidade de migrao de processos, funcionalidade essa que apresentou timos resultados durante os testes de laboratrio. O dispositivo de probe padro do Kerrighed fornece mecanismos satisfatrios de migrao baseados em mtricas pr-determinadas, porm um processo pode ser manualmente migrado de um n para outro a qualquer momento. Por fim, aps devidamente instaladas as aplicaes PovRay e Breve foram executadas no cluster exaustivamente sem apresentar nenhum problema, salvo nas situaes de teste de estresse quando testamos a capacidade limite do cluster atravs da execuo concorrente de vrias instncias dessas aplicaes. Podemos assim afirmar empiricamente que o cluster Kerrighed vivel em termos tcnicos para suportar a instalao e execuo das aplicaes PovRay e Breve. Consideraes Finais Embora ao longo do trabalho j tenhamos apresentado resultados, anlises e pareceres sobre o tema central da pesquisa que uma anlise de natureza emprica da viabilidade da utilizao de cluster para a execuo aplicaes HPC, nessa seo sero apresentadas de maneira mais sistemtica essas constataes. Antes de apresentarmos essas argumentaes, acreditamos ser importante retomar nesse ponto, o tema da validade da experimentao e do mtodo de indutivo de anlise na cincia da computao. Gonzalo Gnova23 em seu artigo Is Computer Science Truly Scientific? no peridico Communications de julho de 2010 da ACM (Association for Computing Machinery), apresentou uma viso muito interessante do assunto, onde coloca que a especulao e a experimentao devem seguir juntas no caminho da pesquisa em Computao, citando exemplos de grandes personalidades nessa rea que tiveram seus trabalhos iniciados no campo do raciocnio, como Turing (Teoria da Computao), Neumann (Arquitetura dos Computadores), Dijkstra (Teoria da Programao e Algoritmos), dentre outros. Dessa forma, as consideraes aqui apresentadas sero baseadas apenas nos resultados obtidos e devidamente mensurados, mas tambm na anlise e interpretao desses resultados, segundo o nosso juzo. Seguem as constataes e anlise.

23

Professor de Engenharia de Software da Universidade Carlos III de Madrid na Espanha.

205

Tecnologia de Cluster em geral como uma alternativa vivel para execuo de aplicaes de HPC de mdio porte. A tecnologia de Cluster em geral adequada e vivel para aplicaes de processamento massivo pela capacidade de processamento para aplicaes monoprocessadas e pela melhoria de desempenho para aplicaes com

processamento paralelo. Mesmo para aplicaes monoprocessadas um sistema cluster ser vivel, pois prover um sistema nico e com alta disponibilidade para a execuo de vrias instncias das aplicaes ao mesmo tempo, dando usurio final a impresso de estar atuando em um nico recurso computacional de alta capacidade. A tecnologia de cluster vivel em termos financeiros em comparao a computao em cloud pelos seguintes motivos: Uma anlise financeira dentro do universo do nosso laboratrio demonstrou essa viabilidade. A relao custo-benefcio de clusters HPC usualmente favorvel, pois aplicaes que executadas so grande utilidade para a sociedade e para a comunidade cientfica. Os clusters podem ser heterogneos e inclusive compostos de computadores utilizados em sistemas legados. Cluster Kerrighed como uma alternativa vivel para execuo de aplicaes HPC de mdio porte. Apesar de desconhecido pela comunidade tecnolgica e cientfica do Brasil, pelo menos formalmente, pois temos apenas trs clusters no nosso pas registrados no site oficial do Kerrighed, o implantado na Faculdade do Senac em Pelotas outro localizado no Rio de Janeiro, o cluster Kerrighed mostrou-se eficiente, apresentando solues inteligentes para aspectos crticos no processamento em cluster, como o gerenciamento de memria, migrao de threads, preservao de processos mesmo com a indisponibilidade de algum n, atravs de dispositivos de checkpoint, dentre outras funcionalidades. Pode-se verificar o registro desses clusters implementados no Brasil atravs do link http://kerrighed.org/php/clusterslist.php.

206

A comunidade envolvida no projeto do Kerrighed est sempre disponvel para discutir e compartilhar informaes referentes a funcionalidades, dvidas e problemas de implementao ou manuteno do sistema. Aps os devidos ajustes e configuraes o cluster Kerrighed mostrou-se estvel mesmo quando atuou no limite de sua capacidade computacional. Tecnologias e aplicao de Computao em Cluster e Computao em Cloud Quando abordamos HPC e processamento massivo, que a natureza da computao de aplicaes de Inteligncia Artificial e Design Digital, estamos contemplando um sistema computacional com hardware, sistema operacional e aplicaes especficas para um uso restrito desses recursos. Dessa forma, apesar de termos servios HPC em computao em cloud j disponveis, consideramos uma tarefa rdua para esses provedores adaptar a sua infraestrutura para as necessidades e particularidades de cada um desses clientes de HPC. De fato temos no mercado americano um grande provedor de servios de computao em cloud oferecendo servios de HPC, porm esses servios so fornecidos em servidores virtualizados que at ento no conseguem prover um desempenho equivalente ao das aplicaes executadas diretamente no hardware de um computador multincleo ou em cluster. Por outro lado, temos um provedor de servios de cluster remoto que oferece hardware dedicado para cada cliente, atendendo assim s necessidades de processamento para rea cientfica e acadmica ao prover plataformas que suportam processamento paralelo real, GPU (Graphics Processing Unit), conexes de rede com alta velocidade e baixa latncia utilizando o padro Infiniband. Os pesquisadores do departamento de Cincias da Terra, Atmosfricas e Planetrias do MIT, Constantinos Evangelinos (EVANGELINOS, 2008) e Chris N. Hill (HILL, 2008) realizaram testes de benchmark utilizando os servios de HPC em cloud desse grande provedor norte americano mencionado acima. Segue algumas consideraes dos mesmos: O desempenho est abaixo do visto em centros de supercomputadores dedicados, entretanto a performance comparvel com sistemas de clusters de baixo custo. Uma significativa deficincia de desempenho surge onde latncia e largura de banda esto de uma a duas ordens de magnitude inferiores a um computador de porte. Entretanto, os resultados so encorajadores. possvel vislumbrar sistemas em cloud mais prximos dos objetivos das aplicaes de HPC, utilizando tecnologias como Myrinet e Infiniband. Em suma, apesar dos avanos significativos, a computao em cloud ainda no atende em sua plenitude s necessidades das aplicaes HPC de grande porte.

207

Assim temos trs alternativas para HPC, a saber, computao em cluster com hardware local, computao em cluster com hardware dedicado, porm remoto, oferecido como servio e computao em cloud. Ressaltando que no temos no Brasil, at esse momento, nenhum provedor de computao em cloud que fornea HPC. Obviamente que poderamos contratar esse servio de provedores de outros pases, mas teramos a necessidade de fazer todas as tratativas de contratao e suporte na lngua nativa desses provedores. Outra questo importante no que tange ao acesso desses servios via Internet a Segurana da Informao. Como o modelo que estamos utilizando como contraponto a computao em cluster seria o IaaS (Infrastructure as a Service), apresentaremos de forma pontual algumas questes referentes Segurana para essa modalidade de computao em cloud. Pela facilidade de contratao desse servio, necessitando apenas um nmero de carto de crdito, e-mail e em alguns casos um telefone, que pode ser um celular, com provedores fornecendo utilizao sem custo para avaliao, perpetradores de ataques em servios de Tecnologia de Informao utilizam esses recursos computacionais como base para realizao dos mais diversos ataques como Botnets, DDoS (Distributed Denial of Service), descoberta indevida de senhas e chaves, ataques ao prprio servio de cloud, acessando outros servidores atravs da estrutura da virtualizao, rainbow tables e solucionadores de CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart), dentre outros. Esses ataques poderiam com certeza ser tambm realizados em um Data Center privado, porm um hacker teria mais dificuldade em ter acesso completo ao um servidor virtualizado num Data Center privado do que num provedor de servio de cloud. Contratamos o servio de cloud de um provedor no Brasil e nos foi solicitado apenas um e-mail e um nmero de carto de crdito. O acesso ao portal WEB para a utilizao do servio requer apenas uma senha de acesso associada ao e-mail fornecido na contratao. Aps acessar o portal, foi provido o endereo IP do servidor virtual e pudemos acessar o mesmo via SSH (Secure Shell) com a possibilidade do uso do usurio root. Contratamos tambm o servio de cloud de um provedor norte americano, que realizou uma verificao da existncia de um usurio real atravs de uma ligao telefnica e durante o processo de contratao do servio proveu um arquivo para a gerao de chaves pblicas RSA para acesso SSH, mostrando um processo muito mais seguro e confivel do fornecimento de acesso ao seu servio.

208

Alm das questes citadas temos outras ameaas como o prprio acesso indevido aos servidores fsicos e virtualizados nas dependncias dos provedores de servio de cloud, pois apesar das polticas severas de segurana que devem ser aplicadas nos mesmos, a quantidade de pessoas a serem supervisionadas e recursos a serem protegidos significativa. Quando mencionamos dependncias no seria o acesso fsico s salas cofres onde os equipamentos esto instalados, mas sim a qualquer computador na rede que tenha alguma conectividade com esses recursos. Podemos dizer que base tecnolgica dos Data Centers de computao em cloud seria servidores com alta capacidade de processamento, redes de alta velocidade e baixa latncia e virtualizao. Dessa forma, a Segurana da Informao em computao em cloud est muito ligada aos ataques e mitigaes nos ambientes virtualizados. Neil MacDonald24 (MACDONALD, 2009) da empresa de Consultoria e Pesquisa Gartner colocou em 2009 A camada de virtualizao entre o sistema operacional e o hardware extremamente sensvel. Essa camada um software - software escrito por seres humanos e que tem vulnerabilidades. Os malfeitores so inteligentes e tm motivao financeira para atacar essa camada. Uma invaso o caso de quando e no de se". Para corroborar com essa previso do especialista Neil MacDonald apresentaremos algumas vulnerabilidades e exposies apresentadas pela National Vulnerability Database. Da empresa lder de mercado em virtualizao temos 32 registros de 2005 at o momento, onde: Dez so de alta severidade. Vinte so de mdia severidade. Dois so de baixa severidade.

24

Neil MacDonald um vice presidente e destacado analista e associado na Consultoria Gartner, locado em Stamford, Connecticut. Ele um membro da equipe de Segurana da Informao e Pesquisa sobre o tema de Privacidade em TI, focado em Sistemas Operacionais e Estratgias de Segurana em nvel de Aplicao.

209

Seguem a descrio de algumas dessas ocorrncias a ttulo de ilustrao e registro: CVE-2010-2189 TA10-162A O Adobe Flash Player antes da release 9.0.277.0 e na verso 10.x antes da release 10.1.53.64 e o Adobe AIR antes da verso 2.0.2.12610, quando em conjuno como as ferramentas VMWare na plataforma VMWare permite a agressores causar um denial of service (corrupo da memria) e possivelmente a execuo de um cdigo arbitrrio via vetores no especificados. 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.dll do VMware Movie Decoder antes da verso 6.5.3 build 185404, do VMware Workstation 6.5.x antes da verso 6.5.3 build 185404, do VMware Player 2.5.x antes da verso 2.5.3 build 185404 e do VMware ACE 2.5.x antes da verso 2.5.3 build 185404 no ambiente do Sistema Operacional Windows no manipula apropriadamente os contedos de vdeo de baixa altura, os quais podem permitir agressores remotos executarem cdigos arbitrrios via um arquivo AVI manipulado que pode provocar uma corrupo de pilha de memria. Publicado em 08/09/2009 CVSS (Common Vulnerability Scoring System) Severidade: 9.3 (Alta)

210

CVE-2009-0909 Estouro de buffer de pilha no Codec VNnc Codec na VMware Workstation 6.5.x antes da verso 6.5.2 build 156735, no VMware Player 2.5.x antes da verso 2.5.2 build 156735, no VMware ACE 2.5.x antes da verso 2.5.2 build 156735 e no VMware Server 2.0.x antes da verso 2.0.1 build 156745, permite que agressores executem cdigos arbitrrios via pgina WEB ou arquivo de vdeo manipulados, tambm conhecido como ZDI-CVE-435. Publicado em 06/04/2009 CVSS (Common Vulnerability Scoring System) Severidade: 9.3 (Alta)

CVE-2009-1147 Vulnerabilidade no especificada no arquivo vmci.sys na Virtual Machine

Communication Interface (VMCI) na VMware Workstation 6.5.1 e anteriores, no VMware Player 2.5.1 e anteriores, no VMware ACE 2.5.1 e anteriores e no VMware Server antes da verso 2.x build 156745 permite que usurios locais obtenham privilgios atravs de vetores desconhecidos Publicado em 06/04/2009 CVSS (Common Vulnerability Scoring System) Severidade: 7.2 (Alta) Esses registros mostram vulnerabilidades j identificadas e corrigidas, mas no possvel dizer que esse sistema de virtualizao de computadores no possui outras vulnerabilidades ainda no descobertas ou no divulgadas. Com certeza sistemas privados de computao tambm esto sujeitos a ataques e invases, mas nesse caso a responsabilidade pelas polticas e providncias no que tange Segurana da Informao recai sobre o detentor desses dados e no sobre a responsabilidade de terceiros.

211

A empresa de consultoria e pesquisa Gartner (MACDONALD, 2011) tambm afirma que em 2012, 60% dos servidores virtualizados estaro menos seguros que os servidores tradicionais que eles substituram. Apesar dos provedores de computao em cloud possurem, em tese, uma maior competncia em segurana, por terem mais recursos financeiros para investir em produtos alm de profissionais especialistas nessa disciplina, cremos que ainda h necessidade de mais maturidade nesse quesito no que tange computao em cloud que demandar pesquisa, tempo e experincia. A empresa de consultoria KPMG (CHUNG, 2010) tambm afirma que o principal obstculo para a adoo e implementao de computao em cloud a Segurana da Informao. Segue a declarao da mesma em seu documento From Hype to Future: Segurana o principal obstculo encontrado quando da implementao de computao em cloud, seguida das questes de conformidades, privacidade e temas legais. As organizaes esto preocupadas com segurana e privacidade no que tange ao uso de servios de computao em cloud na medida em que o mercado oferece uma garantia marginal nessas disciplinas. Alinhar os requerimentos internos de segurana com as medidas e controles dos provedores desse servio tem-se provado difcil na prtica, devido s discrepncias, falta de percebimento e expertise insuficiente. Pelos argumentos e informaes apresentadas podemos dizer que alm da questo financeira, ao fazermos uma comparao entre as tecnologias de Clouding e Clustering, em termos de capacidade de processamento massivo e Segurana da Informao, tambm conclumos que nesse momento a utilizao de computao em cluster seria mais vivel no cenrio apresentado nesse trabalho que seria uma plataforma com uma alta capacidade de processamento para aplicaes como HPC com nfase em Inteligncia Artificial e Design Digital.

212

Captulo 6 - 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 primeiro de um cluster Kerrighed implantado e mantido pelo Dr. A. J. Travis da Universidade de Aberdeen no Reino Unido para o Instituto Rowett de Nutrio e Sade, para o processamento de aplicaes e sistemas relacionados Nutrigenmica, o segundo ser o cluster no Kerrighed chamado TSUBAME 2.0 do Instituto de Tecnologia de Tquio que ocupa a quinta posio do site TOP500 Supercomputers. Temos um cluster da China na quarta posio no raking do TOP500, porm devido s caractersticas polticas desse pas, a busca de informaes foi infrutfera. Kitcat na Universidade de Aberdeen A Nutrigenmica representa o estudo da interao entre o genoma e nutrio. Atravs da introduo de novas ferramentas moleculares nos estudos clssicos de nutrio, essa nova cincia multidisciplinar e integrada almeja a compreenso de como a dieta influencia o genoma e consequentemente a sade e tambm como a variao gentica influencia a resposta s dietas. O Brasil possui uma Rede Brasileira de Nutrigenmica tendo como principais colaboradores a USP, a UNESP e a FEPAF (Fundao de Estudos e Pesquisas Agrcolas e Florestais). A organizao brasileira possui algum intercmbio 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. Travis como Kitcat. Atualmente esse cluster possui 61 ns com 202 processadores de 64 bits, com 854 Gigabytes de memria e 21 Terabytes de disco rgido, utilizando o software Onesis para criar um sistema de arquivos comum para todos os ns do cluster. A rede que suporta esse cluster composta de 10 switches Catalyst 2970 onde o trfego da aplicao separado do trfego do sistema para caso houver uma saturao da banda na rede da aplicao no venha comprometer o desempenho do sistema.

213

Seguem o endereamento IP do cluster: Sistema Operacional: 192.168.0.0/24 Aplicao: 192.168.1.0/24 Rede Local: 143.234.32.0/20 O cluster gerenciado pela ferramenta de monitoramento Ganglia que pode ser acessada atravs da seguinte URL: http://bioinformatics.rri.sari.ac.uk/ganglia

TSUBAME 2.0 do Instituto de Tecnologia de Tquio O TSUBAME 2.0 que significa engolir em japons um cluster composto de 1.442 ns com 2.852 processadores tradicionais e 4.264 GPU's (Graphic Processor Unit) provendo uma capacidade de processamento de 2.420 Teraflops com 103,9 Tbytes de memria RAM e uma capacidade de armazenagem de 11 Pbytes. Os Sistemas Operacionais utilizados so SUSE Linux Enterprise Server e Windows HPC Server 2008 R2 atuando em regime de batch alocando dinamicamente mais ns aos processos na medida em que forem necessrios atravs do sistema PBS (Portable Batch System) que um produto de mercado para alocao de recursos em ambientes HPC. As conexes de rede so realizadas atravs da tecnologia Infiniband, 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

Seguem algumas aplicaes que so executadas no TSUBAME 2.0: ABAQUS Discovery Studio Mathematica MATLAB PGI Compiler Intel Compiler

Seguem algumas atividades computacionais realizadas pelo TSUBAME 2.0: Novos algoritmos para processamento grfico Aplicaes HPC em larga escala utilizando GPU Desenvolvimentos de esquemas de alta acuidade numrica para dinmica de fludos Visualizaes em alta escala e em alta qualidade

Seguem algumas reas em que o TSUBAME 2.0 utilizado: Predio numrica do tempo Simulao em alta escala para fluxo multifsico Simulao da turbulncia nas ondas Large-Eddy Estudo sobre a interao das estruturas dos fludos Simulao de Tsunami

215

Um olhar para o futuro Apesar de ser um projeto inacabado cluster Blue Waters que tem como objetivo alcanar processamento em nvel de Petaflops (1015 flops) apresenta-se como um empreendimento tecnolgico e uma infraestrutura de computao massiva contnua que sinaliza uma nova abordagem de computao capaz de atingir nveis de capacidade e desempenho at ento no obtidos. O projeto financiado e apoiado pela NSF (National Science Foundation) e pela Universidade de Illinois que iniciaram parceria com a IBM, parceria essa encerrada em 08/08/2011. Embora numa condio de interrupo e redefinies tcnicas e financeiras, o projeto apresenta muitas funcionalidades e abordagens que contribuiro para o

desenvolvimento de HPC em nveis mais elevados dos que esto em atividade nesse momento. Seguem as mais significativas: Processador Power 7. O processador utilizado no projeto original do Blue Waters apresenta caractersticas que contribuem para o processamento massivo e paralelo. A idealizadora desse processador a IBM que em 2006 foi vencedora de um contrato da DARPA (Defense Advanced Research Projects Agency), utilizando o Power 7 como base do seu projeto de cluster apresentado em sua proposta. Dentre as vrias funcionalidades estabelecidas, uma das mais importantes seria o desenvolvimento de uma tabela de paginao e endereamento de memria de modo a ter uma memria compartilhada distribuda (DSM), tema j abordado nesse trabalho, que possibilita a viabilizao de clusters SSI que so mais acessveis em termos de interface ao usurio final do sistema. Outras caractersticas que fazem um Power 7 um dos processadores mais poderosos da atualidade j oferecido em escala comercial, seriam a quantidade efetiva de ncleos que podem chegar at oito por processador, a capacidade de processamento simultneo de threads conhecida como SMT (Simultaneous Multithreading) que seria 4 por ncleo totalizando 32 threads simultneas e o prprio projeto de arquitetura do microprocessador focado na otimizao da potncia eltrica utilizada pelo mesmo. Seguem as especificaes tcnicas principais do Power 7:

216

Mxima de velocidade de clock: 2.4 GHz a 4.25 GHz Tamanho mnimo de transistor: 45 nm Micro-arquitetura: Power ISA v.2.06 Ncleos: 4, 6 ou 8 Cache L1: 32+32 KB por ncleo Cache L2: 256 KB por ncleo Cache L3: 32 MB

Largura de banda nas interconexes do cluster. No foi possvel levantar qual tecnologia de rede foi utilizada para a conexo entre os componentes do cluster, apenas a velocidade das conexes: 192 Gigabit/Sec - Conexes internas de cada n 336 Gigabit/Sec - Conexo entre os ns no mesmo chassi. 240 Gigabit/Sec - Conexo entre o n local e n remoto no mesmo supernode. Um supernode composto por 4 chassis. 320 Gigabit/Sec - Conexo entre ns remotos 40 Gigabit/Sec - Conexo de E/S de uso geral

Desenvolvimento de programas e aplicaes. Para que se possa usufruir da capacidade e desempenho de clusters do porte do projeto Blue Waters, fazem-se necessrias linguagens e ferramentas de desenvolvimento, programao e

compilao compatveis com as demandas do processamento paralelo e massivo. Temos dois principais desafios quando abordamos o desenvolvimento de aplicaes na ordem de PetaFlops que seriam a programao em computao paralela e o refinamento automtico das aplicaes para diferentes ambientes e uso (autotunning).

217

Em relao ao primeiro desafio os idealizadores do Blue Waters visualizam duas frentes de trabalho. A primeira frente seria a utilizao e o refinamento de linguagens, aplicaes e bibliotecas para processamento paralelo e massivo de uso corrente como OpenMP, MPI, SHMEM, UPC e o CAF no Fortran 2008. A segunda frente seria a utilizao de novas linguagens de programao para HPC como a Chapel, X10 e Fortress. Quanto ao autotunning, em curto prazo o projeto trabalhar na substituio dos cdigos atuais por cdigos que utilizam o autotunning, que produziria pelo menos duas verses de cdigos distintas. Em longo prazo, eles trabalharo diretamente com os provedores dos compiladores para fomentar melhorias, promovero uma maior interao com os programadores para facilitar as mudanas dos cdigos e focaro no desenvolvimento cdigos baseados em vetores, dentre outras medidas. Consideramos o desenvolvimento de compiladores e cdigos compatveis com o HPC um maior desafio do que a construo de uma infraestrutura de hardware que suporte o processamento de PetaFlops contnuo, pois necessita de novas abordagens e padres de desenvolvimento e expertise, para aplic-los adequadamente no desenvolvimento de cdigos.

Concluso do captulo Apesar de termos um avano significativo no desenvolvimento de computadores, redes de computadores, sistemas operacionais, aplicaes, compiladores e

especialmente sistemas em cluster para atender esse segmento da Tecnologia da Informao, ainda temos muitos desafios estruturais, conceituais e tecnolgicos a serem sobrepujados, porm, pelos breves estudos de caso apresentados nesse captulo podemos concluir que a tecnologia de cluster HPC est em franco desenvolvimento, sendo uma das tecnologias computacionais que mais contribuir para o desenvolvimento das principais reas de pesquisa que traro benefcios humanidade em nossos tempos.

218

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

219

HUME, David. Os Pensadores. So Paulo: Ed Nova Cultural, 1999. Introduction to RPC. Disponvel em: Acesso em 24 mar. 2012.
http://www.codeproject.com/KB/IP/rpcintro1.aspx#Introduction0

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

220

PATIL, Suhas. Limitations and capabilities of Dijkstra's semaphore primitives for coordination among processes. USA. MIT, 1971. PFISTER, Gregory F. In Search of Cluster. USA. Ed Prentice Hall, 1998. PITANGA, Marcos. Computao em Cluster. Rio de Janeiro: Ed Brasport, 2004. PITANGA, Marcos. Construindo Supercomputadores com Linux. Rio de Janeiro: Ed Brasport, 2002. POPPER, Karl Raymond. Conjecturas e Refutaes. Braslia: Ed UNB, 1994. PRICE, Derek de Solla. A Cincia desde a Babilnia. Belo Horizonte: Ed Itatiaia, 1976. PROJETO openMosix. Disponvel em: http://openmosix.sourceforge.net/ Acesso em 04 nov. 2009. RIBEIRO, Uir. Sistemas Distribudos. Rio de Janeiro: Ed Axcel, 2005. RIGHI, Rodrigo da Rosa. et al. Infiniband: Alta eficincia no tratamento de grandes volumes de dados e na computao numrica de alto desempenho. Brasil. Universidade Federal do Rio Grande do Sul, 2004. SLOAN, Joseph D. High Performance Linux Clusters with OSCAR, Rocks, OpenMosix, and MPI. USA. Ed O'Reilly, 2004. SZEFER, Jakub.; LEE, Ruby B.: A Case for Hardware Protection of Guest VMs from Compromised Hypervisors in Cloud Computing. USA. Princeton University, 2011. TANENBAUM, Andrew S. Distributed Operating Systems. USA. Ed Prentice Hall, 1995. TANENBAUM, Andrew S. Modern Operating Systems Second Edition. USA. Prentice Hall, 2001. VRENIOS, Alex. Linux Cluster Architecture. USA. Ed SAMS, 2003.

221

GLOSSRIO
Aging Em redes aging o tempo que o endereo MAC dos dispositivos se mantm na tabela dos switches que so equipamentos que atuam na camada 2. Array Em programao de computadores, um array, tambm conhecido como vetor (para arrays unidimensionais) ou matriz (para arrays bidimensionais), uma das mais simples estruturas de dados. Os arrays mantm uma srie de elementos de dados, geralmente do mesmo tamanho e tipo de dados. Elementos individuais so acessados por sua posio no array. Benchmarking O processo de comparao do desempenho entre dois ou mais sistemas chamado de benchmarking, e as cargas usadas so chamadas de benchmark. Cluster Um cluster, ou aglomerado de computadores, formado por um conjunto de computadores, que se utiliza de um tipo especial de sistema operacional classificado como sistema distribudo. Coletor de Lixo Coletor de lixo (em ingls: garbage collector, ou o acrnimo GC) um processo usado para a automao do gerenciamento de memria. Com ele possvel recuperar uma rea de memria inutilizada por um programa, o que pode evitar problemas de vazamento de memria, resultando no

esgotamento da memria livre para alocao. Esse sistema contrasta com o gerenciamento manual de memria, em que o programador deve especificar explicitamente quando e quais objetos devem ser deslocados e retornados ao sistema. Entretanto, muitos sistemas usam uma combinao das duas abordagens. Complexidade NP Na teoria da complexidade computacional, NP o acrnimo em ingls para Tempo polinomial no determinstico (Non-Deterministic Polynomial time) que denota o conjunto de problemas que so decidveis em tempo polinomial por uma mquina de Turing no-determinstica. Uma definio equivalente o conjunto de problemas que podem ser verificados em tempo polinomial por uma mquina de Turing determinstica. Data Center Um Data Center uma modalidade de servio de valor agregado que oferece recursos de processamento e armazenamento de dados em larga escala para que organizaes de qualquer porte e mesmo profissionais liberais possam ter ao seu alcance uma estrutura de grande capacidade e flexibilidade, alta segurana, e igualmente capacitada do ponto de vista de hardware e software para processar e armazenar informaes. Empresas de grande porte podem e tm o seu prprio Data Center. Engine Programa de computador e/ou conjunto de bibliotecas, para simplificar e abstrair o desenvolvimento de jogos ou outras aplicaes com grficos em tempo real, para videogames e/ou computadores rodando sistemas operacionais. A funcionalidade tipicamente fornecida por um engine inclui: um motor grfico para renderizar grficos 2D e/ou 3D, um motor de fsica para simular a fsica ou simplesmente para fazer deteco de coliso, suporte a animao, sons, Inteligncia Artificial, networking, gerncia de memria, gerncia de arquivos, gerncia de linha de execuo, suporte a

222

grafos de cena e entidades e, suporte a uma linguagem de script. Firewall Firewall um dispositivo ou grupo de dispositivos designados a permitir ou negar o trfego de rede baseado em um grupo de regras, sendo usado comumente para proteger as redes de trfego no autorizado ou permitindo trfego legtimo. Sistemas Operacionais possuem firewalls baseados em software,

protegendo assim a estao de trabalho ou servidor. Roteadores podem tambm ter funcionalidades de firewall, da mesma forma que os firewalls possuem certas funcionalidades bsicas de roteamento. Grafo A teoria dos grafos um ramo da matemtica que estuda as relaes entre os objetos de um determinado conjunto. Grafo com 4 vrtices e 6 arestas. um grafo completo, conexo e planar. Grafo uma estrutura G(V,A) onde V um conjunto no vazio de objetos denominados vrtices e A um conjunto de pares no ordenados de V, chamado arestas. Dependendo da aplicao, arestas podem ou no ter direo, pode ser permitido ou no arestas ligarem um vrtice a ele prprio e vrtices e/ou arestas podem ter um peso (numrico) associado. Se as arestas tm uma direo associada (indicada por uma seta na representao grfica) temos um grafo direcionado, grafo orientado ou dgrafo. Um grafo com um nico vrtice e sem arestas conhecido como o grafo trivial ou "o ponto". Infiniband Infiniband um padro de comutao de frames em rede local utilizado para sistemas HPC e grandes Data Centers. Suas funcionalidades incluem alta vazo (throughput), baixa latncia, qualidade de servios e alta

disponibilidade. Ele tambm possui uma alta escalabilidade. A especificao da arquitetura do Infiniband define a conexo entre ns processadores e ns de alto desempenho de E/S como dispositivos de armazenamento. Interface gigabit ethernet Conexo de rede que consegue transmitir at 1.000.000.000 (10 ) bits por segundo. Jitter Jitter uma variao estatstica do atraso na entrega de dados em uma rede, ou seja, pode ser definida como a medida de variao do atraso entre os pacotes sucessivos de dados. Observa-se ainda que uma variao de atraso elevada produz uma recepo no regular dos pacotes. Memria non-ECC H dois tipos de memrias quando falamos de suporte para ECC (Error Correction Code). Assim h memrias ECC (com suporte para ECC) e nonECC (que no suportam ECC). O ECC ajuda a detectar e corrigir certos tipos de erros em transaes de memria, se eles ocorrerem. As memrias ECC tm um desempenho um pouco mais baixo devido ao tempo gasto na deteco e correo de erros. Memrias non-ECC so mais comuns, rpidas e baratas.
9

223

Myrinet

Myrinet uma tecnologia de rede local desenvolvida pela empresa Myricon. A tecnologia Myrinet surgiu de dois projetos de pesquisa: o MOSAIC, desenvolvido pelo grupo Caltech, e AtomicLA, desenvolvido pelo grupo USC (University Southern California). Membros dos dois grupos uniram-se e fundaram a Myricom, trazendo a tecnologia Myrinet para o mercado. A Myrinet um tecnologia muito popular, sendo muito utilizada na interconexo de clusters de computadores, devido a sua alta performance. Pesquisas efetuadas mostram que a Myrinet tecnologia de rede com melhor desempenho em clusters com mais de 32 ns.

Overhead

Uso adicional de recursos computacionais e/ou de rede para realizar determinada tarefa.

Parlog86

Lgica de programao da famlia do Prolog desenvolvida pela Imperial College em Londres com funcionalidades de programao concorrente para sistemas de processamento paralelo.

Pilha

Uma pilha uma das vrias estruturas de dados que permitem remoo de elementos e insero de novos elementos. Mais especificamente, uma pilha uma estrutura sujeita seguinte regra de operao: sempre que houver uma remoo, o elemento removido o que est na estrutura h menos tempo. Em outras palavras, o primeiro objeto a ser inserido na pilha o ltimo a ser removido. Essa poltica conhecida pela sigla LIFO (Last In First Out).

PVM

PVM a abreviao de Parallel Virtual Machine. Este um pacote de software que permite que uma rede heterognea de computadores de todos os tipos seja programada como se fosse apenas uma nica "Mquina Paralela Virtual". A programao baseada no paradigma de troca de mensagens. O PVM composto, basicamente, de trs partes: uma biblioteca de funes (em C e em FORTRAN77) que implementam para o usurio as diretivas de programao da Mquina Virtual (MV); um processo daemon que rodar em cada host participante da MV e um console de onde podem ser executadas algumas funes bsicas de controle (configurao da MV, gerenciamento de tarefas, etc...).
10

Rede 10 gigabit ethernet

Tecnologia de rede que consegue transmitir at 10.000.000.000 (10 ) bits por segundo.

Rede de computadores

Conjunto de equipamentos e cabeamento que prov a transmisso de dados entre computadores.

Roteador

Roteador um dispositivo que trabalha na camada 3 do modelo ISO/OSI. A principal caracterstica desses equipamentos determinar e escolher a rota mais apropriada para encaminhar os pacotes recebidos.

Storage

Dispositivo com uma alta capacidade de armazenagem de dados, composto usualmente de um agrupamento de discos rgidos.

Traffic Shaping

Tcnica utilizada em redes para priorizar certos tipos de trfego de natureza mais crtica ou sensvel a atrasos.

224

Voice Over IP (VoIP)

VoIP uma tecnologia de comunicao que permite a transmisso em tempo real de sinais de voz colocados em pacotes de dados sobre redes IP que empregam Transmission Control Protocol (TCP), Real-Time Transport Protocol (RTP), User Datagram Protocol (UDP) e Internet Protocol (IP). Nos sistemas de VoIP, os sinais analgicos de voz so digitalizados e transmitidos como um fluxo de pacotes sobre uma rede de dados

Write-invalidate

O write-invalidate componente do protocolo snooping tambm conhecido como bus-snooping protocol, que utilizado para manter a coerncia de cache em ambientes de multiprocessamento simtrico. No write-invalidate o processador que est escrevendo um dado, gera cpias desse dado em todos os caches dos outros processadores do sistema, que passa a ser invlido se a cpia local for alterada. O processador local faz isso enviando um sinal de invalidao no barramento, o que faz com que os outros caches verifiquem se sua cpia est invlida. Uma vez as cpias tenham sido invalidadas, o dado no processador local pode ser atualizado at que outro processador o requisite.

XML

XML (eXtensible Markup Language) uma recomendao da W3C para gerar linguagens de marcao para necessidades especiais. um subtipo de SGML (acrnimo de Standard Generalized Markup Language, ou Linguagem Padronizada de Marcao Genrica) capaz de descrever diversos tipos de dados. Seu propsito principal a facilidade de compartilhamento de informaes atravs da Internet. Entre linguagens baseadas em XML incluem-se XHTML (formato para pginas Web), RDF,SDMX ,SMIL, MathML (formato para expresses matemticas), NCL, XBRL, XSIL e SVG (formato grfico vetorial). A principal caracterstica do XML, de criar uma infraestrutura nica para diversas linguagens, que linguagens desconhecidas e de pouco uso tambm podem ser definidas sem maior trabalho e sem necessidade de serem submetidas aos comits de padronizao.

225

You might also like